Het is geen geheim dat ik Oracle's databaseclusteringsoplossing redelijk goed ken. Onlangs heb ik een SQL Server-clusteringsoplossing met hoge beschikbaarheid voltooid die twee jaar duurde van het eerste ontwerp tot de uiteindelijke implementatie. Dat proces omvatte het documenteren van vereisten, het bepalen van de opties, het toewijzen van vereisten aan implementatiedetails, budgettering, inkoop, installatie, configuratie en testen.
Nu mijn project is voltooid, dacht ik dat ik een paar items zou geven over de clustering van SQL Server vanuit het perspectief van een Oracle RAC-man. We weten allemaal dat SQL Server en Oracle beide RDBMS-engines zijn en dat ze enkele dingen gemeen kunnen hebben. Maar het zijn ook totaal verschillende wezens. Dus als u vertrouwd bent met Oracle's Grid Infrastructure en RAC en Data Guard, en u overweegt een SQL Server HA-oplossing te implementeren, biedt dit misschien goede informatie voor u.
Ons huidige productiesysteem is een primaire Oracle RAC-database met 4 knooppunten. Dit zorgt voor een hoge beschikbaarheid (en hoge prestaties) binnen ons primaire datacenter. We gebruiken Data Guard om redo te transporteren naar een RAC fysieke standby-database met 3 knooppunten. Hoewel SQL Server <> Oracle, wilde ik onze configuratie zo gelijk mogelijk houden om het beheer te vergemakkelijken. Daarom hebben we een 2-node SQL Server Failover Cluster geïmplementeerd op onze primaire site en een 1-node "stand-by" database op onze DR-site.
Nu verder met mijn observaties, in willekeurige volgorde.
- De HA-clusteroplossing van SQL Server is actief/passief. Oracle's is Active/Active, wat voor mij "beter" is, en ja ... dat is een subjectieve term. Voor onze Active/Passive-implementatie hield ik niet van het idee van twee fysieke servers die daar stonden met één in wezen de hele tijd inactief. We hebben dus één fysieke server die het 'voorkeursknooppunt' is en één virtuele server. Als de fysieke server uitvalt, zal clustering automatisch de SQL Server-instantie naar de virtuele server overzetten en zijn we weer operationeel. Dit Active/Passive cluster doet niets om schaalbaarheid aan te pakken zoals Oracle RAC doet, maar het geeft me wel een hogere beschikbaarheid in onze primaire omgeving.
- Het implementeren van de clustering is supereenvoudig. Schakel clustering in op OS-niveau. Omdat dit een volledig Microsoft-stack is, hebben ze clustering in het besturingssysteem ingebouwd. Het is er al voor je. Je hoeft het alleen maar aan te zetten. Start vervolgens Systeembeheer -> Failover Cluster Manager en wizards leiden u door de installatie. Het is veel eenvoudiger dan het installeren van Grid Infrastructure. Maar Oracle heeft wel te kampen met verschillende OS-platforms, wat het daar moeilijker maakt. Het zal interessant zijn om te zien hoe SQL Server 2016 op Linux omgaat met Failover Clustering.
- Oracle gebruikt een Shared Disk-model, terwijl SQL Server Shared Nothing is. Maar u moet "gedeelde schijf" op een bepaalde manier gebruiken omdat de schijf op beide knooppunten beschikbaar moet zijn. MS Failover Clustering (MSFC) koppelt de geclusterde schijf echter aan het actieve knooppunt. Wanneer SQL Server automatisch of handmatig naar het andere knooppunt wordt verplaatst, ontkoppelt MSFC de schijf op het ene knooppunt en koppelt het vervolgens aan het andere. Het is een beetje vreemd om een Windows Verkenner-venster te openen en de schijf te zien verschijnen of verdwijnen tijdens deze overgang.
- Grid Infrastructure gebruikt de Voting Disk voor quorumbewerkingen. In MSFC kunt u een Quorum-schijf hebben, een bestandsshare gebruiken of configureren zonder quorum. Als u voor het laatste kiest, belemmert u uw automatische failover-capaciteit.
- Ik ben eraan gewend dat mijn primaire een eigen cluster heeft en de standby een eigen cluster. Bij SQL Server moeten de primaire knooppunten en de standby-knooppunten deel uitmaken van hetzelfde cluster. Gelukkig kan het cluster subnetten kruisen, wat anders is dan Oracle GI. Het toevoegen van het standby-knooppunt was supereenvoudig, we hebben zojuist de stemrechten verwijderd en we hebben de quorumschijf voor het standby-knooppunt niet geconfigureerd. Dit was prima voor ons omdat we willen dat failover naar de stand-by een handmatige bewerking is.
- Voor een standby-database kunt u Database Mirroring, Log Shipping of AlwaysOn-beschikbaarheidsgroepen (AG's) gebruiken. De eerste twee zijn onderweg naar buiten, dus ik ging met de AG's mee. AG's vereisen dat het standby-knooppunt deel uitmaakt van hetzelfde cluster als het primaire. Er is een wizard die u begeleidt bij het opzetten van de databases om deel te nemen aan de AG. Dit is veel eenvoudiger dan het opzetten van een fysieke stand-by van Oracle.
- Voor degenen onder jullie die de Oracle-documentatie haten, is het tijd om dankbaar te zijn. Tijdens dit proces ontdekte ik vaak dat de MS-documentatie hele grote stukken miste. Ik ben er bijvoorbeeld nooit achter gekomen hoe ik mijn standby-node zo moet configureren dat deze geen stemrecht heeft. Gelukkig konden we ons er een weg doorheen klikken.
Toen het allemaal gezegd en gedaan was, was het niet zo moeilijk om de SQL Server-oplossing te implementeren. Soms moest ik vertrouwen op mijn kennis van clustering. Andere keren stond de terminologie van Microsoft in de weg. De rest van de wereld noemt het bijvoorbeeld 'split brain', maar MS noemt het 'split cluster'. Soms was het overwinnen van de lexiconverschillen de grootste hindernis.