Det är ingen hemlighet att jag känner till Oracles databasklustringslösning ganska väl. Nyligen slutförde jag en SQL Server-klustringslösning med hög tillgänglighet som tog två år från den första designen till den slutliga implementeringen. Den processen innebar att dokumentera krav, fastställa alternativen, kartlägga krav till implementeringsdetaljer, budgetering, upphandling, installation, konfiguration och testning.
Nu när mitt projekt är klart tänkte jag ge några saker om SQL Servers klustring utifrån en Oracle RAC-killes perspektiv. Vi vet alla att SQL Server och Oracle båda är RDBMS-motorer och de kan ha vissa saker gemensamt. Men de är också helt olika varelser också. Så om du är bekväm med Oracles Grid Infrastructure och RAC och Data Guard, och funderar på att implementera en SQL Server HA-lösning, kanske detta kommer att ge dig bra information.
Vårt nuvarande produktionssystem är en primär databas för Oracle RAC med fyra noder. Detta ger hög tillgänglighet (och hög prestanda) inom vårt primära datacenter. Vi använder Data Guard för att transportera redo till en 3-nods RAC fysisk standby-databas. Även om SQL Server <> Oracle ville jag behålla vår konfiguration så lika som möjligt för att underlätta administrationen. Så vi distribuerade ett 2-nods SQL Server Failover Cluster på vår primära plats och en 1-nods "standby"-databas på vår DR-webbplats.
Nu till mina observationer, utan särskild ordning.
- SQL Servers HA-klustringslösning är aktiv/passiv. Oracle's är Active/Active vilket för mig är "bättre", och ja ... det är en subjektiv term. För vår aktiva/passiva implementering gillade jag inte idén med två fysiska servrar som sitter där med en i princip inaktiv hela tiden. Så vi har en fysisk server som är den "föredragna" noden och en virtuell server. Om den fysiska servern misslyckas, kommer klustring automatiskt att överta SQL Server-instansen till den virtuella servern och vi är i drift igen. Det här aktiva/passiva klustret räcker inte till med skalbarhet som Oracle RAC gör, men det ger mig högre tillgänglighet i vår primära miljö.
- Att implementera klustringen är superenkelt. Aktivera klustring på OS-nivå. Eftersom detta är en helt Microsoft-stack byggde de in kluster i operativsystemet. Den finns redan där för dig. Du behöver bara slå på den. Starta sedan upp Administrativa verktyg –> Failover Cluster Manager och guider leder dig genom installationen. Det är mycket enklare än att installera Grid Infrastructure. Men Oracle har att brottas med olika OS-plattformar vilket gör det svårare där. Det ska bli intressant att se hur SQL Server 2016 på Linux hanterar Failover Clustering.
- Oracle använder en delad diskmodell medan SQL Server är Shared Nothing. Men du behöver använda "delad disk" på ett sätt eftersom disken måste vara tillgänglig på båda noderna. Men MS Failover Clustering (MSFC) monterar den klustrade disken på den aktiva noden. När SQL Server flyttas till den andra noden, antingen automatiskt eller manuellt, kommer MSFC att avmontera disken på en nod och sedan montera den på den andra. Det är ganska konstigt att ha ett Windows Explorer-fönster öppet och se skivan antingen dyka upp eller försvinna under denna övergång.
- Grid Infrastructure använder röstskivan för kvorumoperationer. I MSFC kan du ha en kvorumdisk, använda en filresurs eller konfigurera utan kvorum. Om du använder det sistnämnda hindrar du din automatiska failover-förmåga.
- Jag är van vid att min primära har ett eget kluster och standby-läget ett eget kluster. Med SQL Server måste de primära noderna och standbynoderna vara en del av samma kluster. Tack och lov kan klustret korsa undernät vilket är annorlunda än Oracle GI. Att lägga till standbynoden var superenkelt, vi tog bara bort dess rösträtt och vi konfigurerade inte kvorumdisken för standbynoden. Detta var bra för oss eftersom vi vill att failover till standby ska vara en manuell operation.
- För en standby-databas kan du använda Databasspegling, Log Shipping eller AlwaysOn Availability Groups (AGs). De två första är på väg ut så jag följde med AGs. AG:er kräver att standbynoden är en del av samma kluster som den primära. Det finns en guide som hjälper dig att ställa in databaserna för att delta i AG. Det här är mycket enklare än att ställa in ett Oracle fysiskt standbyläge.
- För er som hatar Oracle-dokumentationen är det dags att vara tacksam. Många gånger under denna process upptäckte jag att MS-dokumentationen saknade mycket stora bitar. Till exempel fick jag aldrig reda på hur jag konfigurerar min standby-nod så att den inte har någon rösträtt. Som tur var kunde vi klicka oss igenom den.
När allt var sagt och gjort var det inte så svårt att få SQL Server-lösningen implementerad. Ibland var jag tvungen att lita på min kunskap om klustring. Andra gånger kom Microsofts terminologi i vägen. Till exempel, resten av världen kallar det "split brain" men MS kallar det "split cluster". Ibland var det största hindret att komma över lexikonskillnaderna.