Det er ingen hemmelighed, at jeg kender Oracles databaseklyngeløsning ret godt. For nylig afsluttede jeg en SQL Server-klyngeløsning med høj tilgængelighed, der tog to år fra det første design til den endelige implementering. Denne proces involverede dokumentation af krav, fastlæggelse af muligheder, kortlægning af krav til implementeringsdetaljer, budgettering, indkøb, installation, konfiguration og test.
Nu hvor mit projekt er færdigt, tænkte jeg, at jeg ville give et par punkter om SQL Servers klyngedannelse fra en Oracle RAC-mands perspektiv. Vi ved alle, at SQL Server og Oracle begge er RDBMS-motorer, og de kan have nogle ting til fælles. Men de er også helt forskellige skabninger. Så hvis du er fortrolig med Oracles Grid Infrastructure og RAC og Data Guard og overvejer at implementere en SQL Server HA-løsning, vil dette måske give dig nogle gode oplysninger.
Vores nuværende produktionssystem er en 4-node Oracle RAC primær database. Dette giver høj tilgængelighed (og høj ydeevne) i vores primære datacenter. Vi bruger Data Guard til at transportere redo til en 3-node RAC fysisk standby database. Selvom SQL Server <> Oracle, ønskede jeg at holde vores konfiguration så ens som muligt for at lette administrationen. Så vi implementerede en 2-node SQL Server Failover Cluster på vores primære websted og en 1-node "standby"-database på vores DR-websted.
Nu til mine observationer, uden nogen særlig rækkefølge.
- SQL Servers HA-klyngeløsning er aktiv/passiv. Oracle's er Active/Active, hvilket for mig er "bedre", og ja ... det er et subjektivt udtryk. For vores aktive/passive implementering kunne jeg ikke lide ideen om to fysiske servere, der sad der med en i det væsentlige inaktiv hele tiden. Så vi har én fysisk server, som er den ’foretrukne’ node og én virtuel server. Hvis den fysiske server svigter, vil clustering automatisk failover SQL Server-instansen til den virtuelle server, og vi er operationelle igen. Denne aktive/passive klynge kan ikke håndtere skalerbarhed, som Oracle RAC gør, men den giver mig højere tilgængelighed i vores primære miljø.
- Implementering af clustering er super nemt. Slå clustering til på OS-niveau. Fordi dette er en helt Microsoft-stak, indbyggede de klyngedannelse i OS. Den er der allerede for dig. Du skal bare tænde den. Start derefter Administrative Tools –> Failover Cluster Manager og guider fører dig gennem opsætningen. Det er meget nemmere end at installere Grid Infrastructure. Men Oracle skal kæmpe med forskellige OS-platforme, hvilket gør det sværere der. Det bliver interessant at se, hvordan SQL Server 2016 på Linux håndterer Failover Clustering.
- Oracle bruger en Shared Disk-model, hvorimod SQL Server er Shared Nothing. Men du skal bruge "delt disk" på en måde, fordi disken skal være tilgængelig på begge noder. Men MS Failover Clustering (MSFC) monterer den klyngede disk på den aktive node. Når SQL Server flyttes til den anden node, enten automatisk eller manuelt, vil MSFC afmontere disken på den ene node og derefter montere den på den anden. Det er lidt mærkeligt at have et Windows Stifinder-vindue åbent og se disken enten dukke op eller forsvinde under denne overgang.
- Grid Infrastructure bruger stemmedisken til kvorumsoperationer. I MSFC kan du have en Quorum-disk, bruge en fildeling eller konfigurere uden kvorum. Hvis du går med sidstnævnte, hæmmer du din automatiske failover-evne.
- Jeg er vant til, at min primære har sin egen klynge og standbyen sin egen klynge. Med SQL Server skal de primære noder og standby-knuderne være en del af den samme klynge. Heldigvis kan klyngen krydse undernet, hvilket er anderledes end Oracle GI. Det var super nemt at tilføje standby-knuden, vi fjernede lige dens stemmerettigheder, og vi konfigurerede ikke kvorumdisken til standby-knuden. Det var fint for os, da vi ønsker, at failover til standby skal være en manuel operation.
- For en standby-database kan du bruge Database Mirroring, Log Shipping eller AlwaysOn Availability Groups (AG'er). De to første er på vej ud, så jeg gik med AG'erne. AG'er kræver, at standby-knuden er en del af den samme klynge som den primære. Der er en guide til at lede dig gennem opsætningen af databaserne for at deltage i AG. Dette er meget nemmere end at konfigurere en Oracle fysisk standby.
- For dem af jer, der hader Oracle-dokumentationen, er det tid til at være taknemmelig. Mange gange under denne proces fandt jeg ud af, at MS-dokumentationen manglede meget store dele. For eksempel fandt jeg aldrig ud af, hvordan jeg konfigurerer min standby-knude til ikke at have stemmeret. Heldigvis kunne vi klikke os igennem det.
Når det hele var sagt og gjort, var det ikke så svært at få implementeret SQL Server-løsningen. Nogle gange måtte jeg stole på min viden om klyngedannelse. Andre gange kom Microsofts terminologi i vejen. For eksempel kalder resten af verden det "split hjerne", men MS kalder det "split klynge". Nogle gange var det at komme over leksikonforskellene den største hindring.