SQL Server Always On Availability Groups is de nieuwste technologie van Microsoft om te voorzien in de behoeften op het gebied van hoge beschikbaarheid en noodherstel van organisaties die SQL Server gebruiken. Een groot voordeel van AlwaysOn is de mogelijkheid om zowel HA als DR in één implementatie aan te pakken. We hebben de volgende belangrijke voordelen van AlwaysOn ervaren:
We kunnen gerelateerde databases groeperen als onderdeel van een enkele beschikbaarheidsgroep en ze samen laten failoveren voor het geval dat nodig is. Dit is vooral handig voor toepassingen die afhankelijk zijn van meer dan één database, zoals Microsoft Office SharePoint, Microsoft Lync en Sage.
In vergelijking met SQL Server Failover Cluster Instances, zien we dat opslag als single point of failure is geëlimineerd sinds elke instance die een replica vormt krijgt zijn eigen opslag toegewezen.
Met AlwaysOn is het mogelijk om HA en DR tegelijk te configureren. Dit wordt bereikt door het creëren van een Multi-site Windows Failover Clusters als basis van uw AlwaysOn-configuratie. Het uitvoeren van een rolwisseling bij het gebruik van AlwaysOn is aanzienlijk eenvoudiger dan bij het gebruik van Transactielogboekverzending.
Computerobjecten
Active Directory (AD) is een enorm onderwerp en we zullen in dit artikel niet ingaan op de details. Zoals u kunt raden, is Active Directory de directoryservice van Microsoft. In termen van computernetwerken is een directoryservice een voorziening waarmee we alle objecten binnen een netwerk centraal kunnen registreren, identificeren en beheren. Vermeldingen in de directoryservices wijzen de namen van netwerkapparaten toe aan overeenkomstige IP-adressen en andere eigenschappen in de directory. De meest voorkomende objecten in een directoryservice (en in de AD van Microsoft) zijn gebruikers en computers. Net zoals elke gebruiker op het domein kan worden geregistreerd en beheerd vanuit Active Directory, kan elke computer op het domein ook worden beheerd vanuit Active Directory. Net zoals van elke gebruiker wordt verwacht dat hij een uniek account heeft in Active Directory, geldt dat ook voor elke computer.
In Active Directory worden niet alle computerobjecten toegewezen aan een fysieke computer. Een computerobject kan een fysieke computer (werkstation of server) vertegenwoordigen, maar kan ook iets vertegenwoordigen dat zich als een computer gedraagt, zoals de representatieve naam voor een Windows-cluster of de virtuele naam voor een clusterservice (rol). Dergelijke representaties zijn ook uniek in Active Directory, net als gewone computernamen.
CNO's en VNO's in WSFC
Wanneer u een Windows Failover Cluster installeert, maakt het installatieprogramma een entiteit in Active Directory genaamd een Computer Name Object (CNO). Deze CNO is de primaire entiteit die in Active Directory voor het cluster is gemaakt en vertegenwoordigt de "servernaam" van het hele cluster. Vervolgens worden andere objecten die bekend staan als Virtuele naamobjecten worden gemaakt door de CNO bij het uitvoeren van activiteiten zoals het maken van clusterrollen, Beschikbaarheidsgroepen, of Beschikbaarheidsgroepluisteraars . Aan deze CNO's en VNO's zijn IP-adressen gekoppeld. U kunt deze adressen opgeven wanneer u het cluster installeert of een nieuwe clusterrol of een luisteraar maakt. Voor elke cluster, rol en listener die u maakt, hebt u een unieke computernaam en een uniek IP-adres nodig. Fig. 1 toont de stap waarin u het clusternaamobject en het IP-adres opgeeft bij het configureren van een cluster.
De namen die je gebruikt bij het configureren van een cluster zijn volledig willekeurig. Ze moeten gewoon uniek zijn. Het wordt echter aangeraden om de naamgevingsconventies van uw organisatie voor gewone computers te volgen bij het maken van CNO's of VNO's - dit helpt het beheer eenvoudiger te houden. Het is ook logisch om een specifiek blok IP-adressen te gebruiken dat alle adresseringsbehoeften voor uw hele cluster dekt - de CNO en alle VNO's (rollen) die u van plan bent te maken.
Afb. 1 Naam-naar-adrestoewijzing in een cluster
De belangrijkste domeinrechten
De DBA of systeembeheerder die een clusterinstallatie uitvoert, moet toestemming hebben om Computerobjecten te maken in het Active Directory-domein. Op zijn beurt moet de domeinbeheerder, na het maken van het computernaamobject, de volgende machtigingen verlenen aan het computernaamobject, zodat rollen (die resulteren in virtuele naamobjecten) met succes kunnen worden gemaakt in het cluster:
Computerobjecten maken
Alle eigenschappen lezen
Zonder deze machtigingen krijgt u waarschijnlijk foutmeldingen zoals hieronder wanneer u probeert een rol aan te maken (in het geval van AlwaysOn FCI ) of een luisteraar (in het geval van AlwaysOn AG ):
Fout tijdens installatie van MS SQL Server Cluster:
Clusternetwerknaambron 'SQL-netwerknaam (EUK-SCCM-01)' kan het bijbehorende computerobject in domein 'domainname.com' om de volgende reden niet maken:kan geen computeraccount maken.
De tekst voor de bijbehorende foutcode is:Toegang is geweigerd.
Dit foutbericht wordt waargenomen in Logboeken omdat SQL Server op dit moment niet toegankelijk zou zijn. U kunt dit ook zien als u naar de SQL Error Log-bestanden navigeert in de LOG-map die zich in de installatiemap van SQL Server bevindt. De sleutelzin is "Toegang geweigerd ”.
Andere vereisten
Ik zou het concept van een domeincontroller moeten noemen. Een domeincontroller, of beter gezegd een reeks domeincontrollers, biedt belangrijke services voor Active Directory, zoals het registreren van objecten en het verifiëren van gebruikers en computers. Om een cluster of een AlwaysOn-listener met succes te kunnen configureren, moet een domeincontroller bereikbaar zijn vanaf de computer waarop u de configuratie uitvoert. Dit betekent dat communicatie van de computer naar de domeincontroller moet worden geopend op een reeks TCP- en UDP-poorten. Microsoft documenteert dit in detail in dit artikel . Dit kan in de meeste gevallen een gegeven zijn, maar bij het oplossen van verbindingsproblemen helpt het om te weten wat er werkelijk nodig is.
In een vorig artikel , heb ik ook gezegd dat het nodig is om machtigingen te verlenen aan de CNO van een cluster bij het configureren van een File Share Quorum.
Afb. 2 machtigingen voor een bestandsshare
Een opmerking over naamresolutie
Computerobjecten, CNO's en VNO's zijn afhankelijk van Domain Name Service om de naam op te lossen die wordt aangegeven bij het installeren van het cluster, het maken van een rol of het maken van een AlwaysOn-listener. Meestal krijgen clients deze computernamen om een verbinding met het cluster tot stand te brengen. Met andere woorden, het IP-adres is transparant voor hen, waardoor de clientconfiguratie eenvoudig wordt en failovers van de eindgebruikers worden geabstraheerd.
Afb. 3 AG Listener-eigenschappen voor luisteraar met twee IP-adressen
In een vorig artikel noemde ik een geval waarin dit scenario problemen kan veroorzaken. In ons multi-site cluster hadden we één luisteraar voor onze AlwaysOn-beschikbaarheidsgroep. Deze listener is geconfigureerd om te worden omgezet naar twee IP-adressen. Dit is nodig voor een cluster met meerdere sites dat meerdere subnetten omspant. In een dergelijke configuratie retourneert de naamserver beide IP-adressen die aan de luisteraar zijn toegewezen bij het uitgeven van een nslookup controleren (zie afb. 4). Wanneer u verbinding maakt, hebt u echter slechts toegang tot één van die IP-adressen tegelijk. Cluster Manager toont het andere IP-adres als Offline (zie Afb. 5).
Afb. 4 AG Listener-eigenschappen voor luisteraar met twee IP-adressen
Afb. 5 Eigenschappen voor clusterrol met twee IP-adressen in afzonderlijke subnetten
Dit is normaal. Als er een failover is naar de alternatieve site, begint de DNS-server na een paar minuten met het oplossen van het alternatieve IP-adres. De implicatie hiervan is dat de communicatie van de klant met de alternatieve locatie mogelijk moet zijn. Afb. 6 en Afb. 7 benadrukken dit verder.
Afb. 6 Communicatiepad met primaire replica in Dakar
Laten we eens goed kijken naar het pad dat de pakketten zullen doorlopen van de clientcomputers naar het cluster. Wanneer de primaire replica zich in Dakar bevindt, wordt de luisteraarnaam SQL-SVR-LNR omgezet naar het IP-adres 192.168.1.20 en WFCS stuurt op zijn beurt het verzoek naar de server 192.168.1.22 (merk op dat deze server ook zijn eigen computer naam). In het geval van een failover naar Nairobi, hebben we het communicatiepad via 192.168.2.20 en vervolgens naar 192.168.2.22. De implicatie is dat voor een naadloze klantervaring alle clients in alle datacenters communicatie moeten hebben toegestaan op alle betrokken firewalls die poort 1433 gebruiken.
Afb. 7 Communicatiepad met primaire replica in Nairobi
Conclusie
Hoewel Windows Failover Clustering, Active Directory en Domain Name Service buiten de rol van de databasebeheerder vallen, loont het om een basiskennis te hebben van hoe deze technologieën werken om AlwaysOn te kunnen bouwen en problemen op te lossen. Failoverclusterinstanties en AlwaysOn-beschikbaarheidsgroepen. Sommige organisaties hebben een strikte scheiding van taken tussen systeembeheerders en databasebeheerders, maar waar dit niet het geval is, moet de databasebeheerder zich om deze Windows-concepten kunnen oriënteren om als DBA te slagen.
Referenties
Overzicht van AlwaysOn-beschikbaarheidsgroepen
Windows Failover Clustering met SQL Server
Serviceoverzicht en netwerkpoortvereisten voor Windows
Computerobjecten beheren