SQL Server Always On-Verfügbarkeitsgruppen ist die neueste Technologie von Microsoft zur Erfüllung der Hochverfügbarkeits- und Notfallwiederherstellungsanforderungen von Organisationen, die SQL Server verwenden. Ein großer Vorteil von AlwaysOn ist die Fähigkeit, sowohl HA als auch DR in einer Implementierung zu adressieren. Wir haben die folgenden Hauptvorteile von AlwaysOn erlebt:
Wir können zusammengehörige Datenbanken als Teil einer einzelnen Verfügbarkeitsgruppe gruppieren und für sie ein gemeinsames Failover durchführen, falls dies erforderlich ist. Dies ist besonders nützlich für Anwendungen, die von mehr als einer Datenbank abhängen, wie z. B. Microsoft Office SharePoint, Microsoft Lync und Sage.
Im Vergleich zu SQL Server-Failover-Cluster-Instanzen stellen wir fest, dass der Speicher als einzelner Fehlerpunkt eliminiert wurde, da jede Instanz ein Replikat darstellt wird ein eigener Speicher zugewiesen.
Mit AlwaysOn ist es möglich, HA und DR gleichzeitig zu konfigurieren. Dies wird durch die Erstellung von Windows-Failoverclustern mit mehreren Standorten als Grundlage Ihrer AlwaysOn-Konfiguration erreicht. Das Durchführen eines Rollenwechsels bei Verwendung von AlwaysOn ist erheblich einfacher als bei Verwendung des Transaktionsprotokollversands.
Computerobjekte
Active Directory (AD) ist ein riesiges Thema und wir werden in diesem Artikel nicht auf die Details eingehen. Wie Sie sich denken können, ist Active Directory der Verzeichnisdienst von Microsoft. In Bezug auf Computernetzwerke ist ein Verzeichnisdienst eine Einrichtung, die es uns ermöglicht, alle Objekte innerhalb eines Netzwerks zentral zu registrieren, zu identifizieren und zu verwalten. Einträge in den Verzeichnisdiensten ordnen die Namen von Netzwerkgeräten entsprechenden IP-Adressen und anderen Eigenschaften im Verzeichnis zu. Die häufigsten Objekte in einem Verzeichnisdienst (und in Microsofts AD) sind Benutzer und Computer. So wie jeder Benutzer in der Domäne über Active Directory registriert und verwaltet werden kann, kann auch jeder Computer in der Domäne über Active Directory verwaltet werden. Genauso wie von jedem Benutzer erwartet wird, dass er ein eindeutiges Konto in Active Directory hat, ist dies auch für jeden Computer der Fall.
In Active Directory werden nicht alle Computerobjekte einem physischen Computer zugeordnet. Ein Computerobjekt kann einen physischen Computer (Arbeitsstation oder Server) darstellen, kann aber auch etwas darstellen, das sich wie ein Computer verhält, wie z. B. der repräsentative Name für einen Windows-Cluster oder der virtuelle Name für einen Clusterdienst (Rolle). Solche Darstellungen sind in Active Directory ebenso eindeutig wie normale Computernamen.
CNOs und VNOs in WSFC
Wenn Sie einen Windows-Failover-Cluster installieren, erstellt das Installationsprogramm eine Entität in Active Directory namens Computer Name Object (CNO). Dieser CNO ist die primäre Entität, die in Active Directory für den Cluster erstellt wurde, und repräsentiert den „Servernamen“ des gesamten Clusters. Anschließend andere Objekte, die als Virtual Name Objects bekannt sind werden vom CNO erstellt, wenn Aktivitäten wie das Erstellen von Clusterrollen, Verfügbarkeitsgruppen durchgeführt werden oder Verfügbarkeitsgruppen-Listener . Diesen CNOs und VNOs sind IP-Adressen zugeordnet. Sie können diese Adressen angeben, wenn Sie den Cluster installieren oder eine neue Clusterrolle oder einen Listener erstellen. Für jeden von Ihnen erstellten Cluster, jede Rolle und jeden Listener benötigen Sie einen eindeutigen Computernamen und eine eindeutige IP-Adresse. Abb. 1 zeigt den Schritt, in dem Sie das Cluster Name Object und seine IP-Adresse angeben, wenn Sie einen Cluster konfigurieren.
Die Namen, die Sie beim Konfigurieren eines Clusters verwenden, sind völlig willkürlich. Sie müssen nur einzigartig sein. Es wird jedoch empfohlen, beim Erstellen von CNOs oder VNOs die Namenskonventionen Ihrer Organisation für normale Computer zu befolgen – dies hilft, die Verwaltung zu vereinfachen. Es ist auch sinnvoll, einen bestimmten Block von IP-Adressen zu verwenden, der alle Adressierungsanforderungen für Ihren gesamten Cluster abdeckt – den CNO und alle VNOs (Rollen), die Sie erstellen möchten.
Abb. 1 Zuordnung von Namen zu Adressen in einem Cluster
Die Schlüsseldomänenberechtigungen
Der DBA oder Systemadministrator, der eine Cluster-Installation durchführt, muss über die Berechtigung zum Erstellen von Computerobjekten verfügen in der Active Directory-Domäne. Nach dem Erstellen des Computernamensobjekts wiederum muss der Domänenadministrator dem Computernamensobjekt die folgenden Berechtigungen erteilen, damit Rollen (die zu virtuellen Namensobjekten führen) erfolgreich im Cluster erstellt werden können:
Computerobjekte erstellen
Alle Eigenschaften lesen
Ohne diese Berechtigungen erhalten Sie wahrscheinlich Fehlermeldungen ähnlich der folgenden, wenn Sie versuchen, eine Rolle zu erstellen (im Fall von AlwaysOn FCI ) oder ein Listener (im Falle der AlwaysOn AG ):
Fehler bei der Installation des MS SQL Server-Clusters:
Die Cluster-Netzwerknamensressource „SQL-Netzwerkname (EUK-SCCM-01)“ konnte das zugehörige Computerobjekt in der Domäne „Domänenname.com“ aus folgendem Grund nicht erstellen:Computerkonto konnte nicht erstellt werden.
Der Text für den zugehörigen Fehlercode lautet:Zugriff verweigert.
Diese Fehlermeldung wird in der Ereignisanzeige angezeigt, da auf SQL Server zu diesem Zeitpunkt nicht zugegriffen werden kann. Sie können dies auch sehen, wenn Sie zu den SQL-Fehlerprotokolldateien im LOG-Ordner navigieren, der sich im Installationsverzeichnis von SQL Server befindet. Der Schlüsselsatz lautet „Zugriff verweigert “.
Andere Anforderungen
Ich sollte das Konzept eines Domänencontrollers erwähnen. Ein Domänencontroller, oder genauer gesagt, eine Reihe von Domänencontrollern, stellt Schlüsseldienste für Active Directory bereit, z. B. das Registrieren von Objekten und das Authentifizieren von Benutzern und Computern. Um einen Cluster oder einen AlwaysOn-Listener erfolgreich zu konfigurieren, muss ein Domänencontroller von dem Computer aus erreichbar sein, auf dem Sie die Konfiguration durchführen. Das bedeutet, dass die Kommunikation vom Computer zum Domänencontroller auf einer Reihe von TCP- und UDP-Ports geöffnet werden muss. Microsoft dokumentiert dies ausführlich in diesem Artikel . Dies mag in den meisten Fällen eine Selbstverständlichkeit sein, aber bei der Fehlerbehebung von Verbindungsproblemen ist es hilfreich zu wissen, was tatsächlich benötigt wird.
In einem früheren Artikel , habe ich auch erwähnt, dass es notwendig ist, dem CNO eines Clusters Berechtigungen zu erteilen, wenn ein File Share Quorum konfiguriert wird.
Abb. 2 Berechtigungen für eine Dateifreigabe
Ein Hinweis zur Namensauflösung
Da es sich um Computerobjekte handelt, sind CNOs und VNOs vom Domain Name Service abhängig, um den angegebenen Namen aufzulösen, wenn der Cluster installiert, eine Rolle erstellt oder ein AlwaysOn-Listener erstellt wird. Normalerweise erhalten Clients diese Computernamen, um eine Verbindung zum Cluster herzustellen. Mit anderen Worten, die IP-Adresse ist für sie transparent, was die Client-Konfiguration vereinfacht und Failover von den Endbenutzern abstrahiert.
Abb. 3 AG-Listener-Eigenschaften für Listener mit zwei IP-Adressen
In einem früheren Artikel habe ich einen Fall erwähnt, in dem dieses Szenario Probleme verursachen kann. In unserem Multi-Site-Cluster hatten wir einen Listener für unsere AlwaysOn-Verfügbarkeitsgruppe. Dieser Listener wurde so konfiguriert, dass er in zwei IP-Adressen aufgelöst wird. Dies ist für einen Multi-Site-Cluster erforderlich, der sich über mehrere Subnetze erstreckt. In einer solchen Konfiguration gibt der Nameserver beide IP-Adressen zurück, die dem Listener zugeordnet sind, wenn ein nslookup ausgegeben wird überprüfen (siehe Abb. 4). Beim Verbinden können Sie jedoch jeweils nur auf eine dieser IP-Adressen zugreifen. Der Cluster-Manager zeigt die andere IP-Adresse als Offline an (siehe Abb. 5).
Abb. 4 AG-Listener-Eigenschaften für Listener mit zwei IP-Adressen
Abb. 5 Eigenschaften für Cluster-Rolle mit zwei IP-Adressen in separaten Subnetzen
Das ist normal. Bei einem Failover zum alternativen Standort beginnt der DNS-Server nach einigen Minuten mit der Auflösung der alternativen IP-Adresse. Daraus folgt, dass die Kommunikation der Clients mit dem alternativen Standort möglich sein muss. Abb. 6 und Abb. 7 verdeutlichen dies weiter.
Abb. 6 Kommunikationspfad mit Primärreplik in Dakar
Werfen wir einen genauen Blick auf den Pfad, den die Pakete von den Client-Computern zum Cluster durchlaufen. Wenn sich das primäre Replikat in Dakar befindet, wird der Listener-Name SQL-SVR-LNR in die IP-Adresse 192.168.1.20 aufgelöst und WFCS leitet seinerseits die Anfrage an den Server 192.168.1.22 weiter (beachten Sie, dass dieser Server auch einen eigenen hat Computername). Bei einem Failover nach Nairobi läuft der Kommunikationspfad über 192.168.2.20 und dann zu 192.168.2.22. Die Implikation ist, dass für ein nahtloses Kundenerlebnis alle Clients in allen Rechenzentren die Kommunikation auf allen beteiligten Firewalls über Port 1433 zulassen müssen.
Abb. 7 Kommunikationspfad mit Primärreplik in Nairobi
Schlussfolgerung
Während Windows Failover Clustering, Active Directory und Domain Name Service möglicherweise außerhalb der Rolle des Datenbankadministrators liegen, lohnt es sich, ein grundlegendes Verständnis der Funktionsweise dieser Technologien zu haben, um AlwaysOn erstellen und Fehler beheben zu können Failover-Cluster-Instanzen und AlwaysOn-Verfügbarkeitsgruppen. Einige Organisationen haben eine strikte Aufgabentrennung zwischen Systemadministratoren und Datenbankadministratoren, aber wo dies nicht der Fall ist, muss der Datenbankadministrator in der Lage sein, sich mit diesen Windows-Konzepten vertraut zu machen, um als DBA erfolgreich zu sein.
Referenzen
Übersicht über AlwaysOn-Verfügbarkeitsgruppen
Windows-Failover-Clustering mit SQL Server
Dienstübersicht und Anforderungen an Netzwerkports für Windows
Computerobjekte verwalten
