Saltmätargatan 8A, 113 59 Stockholm

+46 (0) 8 410 55 700 info@middlecon.se

Kommer HADR att ersättas av pureScale?

Under sensommaren så har senaste uppgraderingen blivit tillgänglig för DB2 10.5, nämligen fixpack 4. Denna fixpack är så pass stor, och med så pass många nyheter att den har kallats för Cancun Release. Och vi på Middlecon håller med. Det finns så otroligt mycket nyheter som öka funktionaliteten av DB2 i denna fixpack att den lika gärna kunde fått ett nytt versionsnummer, såsom V10.7. När man sitter med en nybryggd kopp kaffe i handen sitter och läser igenom de tekniska specifikationerna, med ett stort leende på läpparna, så inser man att pureScale börjar närma sig och är på väg att köra över HADR. Hur ser framtiden ut för dessa funktioner? Kommer de överleva var för sig, eller tar pureScale över hela marknaden för högtillgänglighet?

Nyheter i HADR

När man detaljstuderar vilka nya funktioner som har kommit för HADR så inser vi att en efterlängtad funktion är att BLU tabeller supporteras i HADR. Fantastiskt, då enda lösning för högtillgänglighet sedan tidigare för BLU har varit traditionella failover kluster. Med stöd för BLU i HADR så har vi möjligheten att göra även DataWarehouse högtillgängliga. Äntligen!

 

Nyheter för pureScale

Otroligt många nyheter för pureScale har introducerats i V10.5.4, och vi tror att detta kommer att förändra hur marknaden ser på pureScale som koncept. Två av nyheterna som vi vill belysa lite extra är följande.

– pureScale stödjs på traditionellt 10GB Ethernet. Inget RoCE behövs länge
– Fullt stöd för virtualiserade miljöer.

Dessa två nyheter i kombination betyder att pureScale kan användas i t.ex VMWare installationer, och inga separata servrar behövs. Traditionella hårdvaror som redan finns på de flesta företag är nu det enda som behövs för att få igång ett pureScale cluster.

Så skillnaden mellan HADR och pureScale från ett systemperspektiv är att HADR inte behöver ha gemensamma filsystem mellan noderna, och att endast två noder behövs i HADR. pureScale klarar sig i och för sig också på två noder, men ur licenstekniska anledningar så rekommenderas att CF’erna installeras på separata noder, så totalt 4 noder. So far so good….

 

Migrera från HADR till pureScale?

Detta är en fråga som vi fick av en av våra kunder nyligen.

Skall vi migrera till pureScale och lämna HADR nu när de tekniska kraven är likvärdiga?

Det beror på kravet. Just denna kund har sin HADR standby server i en ”disaster” serverhall, med inget annat än vanliga WAN anslutningar mellan hallarna. Då kom nästa fråga direkt

Men är det något problem? Nu när vanligt Ethernet stödjs så har vi allt vi behöver ju!

Riktigt så enkelt är det inte. Förvisso så går det nu att köra pureScale utan RoCE över Ethernet, men tyvärr så stödjs det inte när det gäller ett GDPS (Geographically Dispersed pureScale cluster). Det krävs också ett gemensamt SAN mellan datorhallarna, och dedikerade fiber eller kanaler för att få prestanda vid mycket förändringar i databasen.

Avstånden är också så pass långa för denna kund att ett GDPS inte är möjligt. Varje kilometer i en fiber ger ca 5 mikrosekunders latency, villket för stora förbindelse kan bli så pass mycket att prestandan blir hårt påverkad.
Men ser det alltid ut såhär? Vad skall man tänka på när man skall välja högtillgänglighetslösning för DB2?

 

Att tänka på med HADR.

– Enkelt att konfigurera
– Enda aktiva högtillgänglighetslösningen med stöd för BLU
– Relativt kostnadseffektiv då standby maskinen endast kostar 100VU i licenser
– Flera standby maskiner stödjs, där en eller flera kan ligga efter i tiden.

 

Att tänka på med pureScale

– Möjlighet att skala till 128 members.
– Ingen failover, utan databasen är alltid tillgänglig. Vid ett eventuellt fel så genomförs en liten rollback för att lösa de lås som den kraschade DB2 membern hade.
– Traditionellt Ethernet stödjs inte vid GDPS, utan endast Ethernet med RoCE och Infiniband.
– Endast stöd för Linux och AIX

 

Kommer pureScale att ersätta HADR?

När det kommer till lösningar som är geografiskt skilda mellan varandra, och de enda man söker är en lösning som vid ett eventuellt fel startar upp databasen på den andra orten med samma kapacitet så är HADR fortfarande den enklaste och säkraste lösningen. Har man också BLU tabeller så är HADR egentligen det enda alternativ förutom cold-standby lösningar som är tillgängligt.

När utrustningen däremot står på samma ort, eller i samma byggnad (kan vara olika datorhallar) så är det en helt annan sak. Då kan pureScale, med sin skalbarhet och aktiv/aktiv lösning vara ett mycket attraktivt alternativ för högtillgänglighet.

 

Handling availability without Angst!