[ESXi] WSFC CAB für SQL Server 2019 BAGs

[silverSl!DE]

Disclamer: Advanced Server Stuff // TL;DR below

Ich stehe vor einer Hereausforderung und bin mittlerweile soweit das Rabbit hole runter, dass ich fast wieder bei Australien rauskomme...
Worum es geht in Kürze:

Ich setze aktuell 2 neue SQL-Server Instanzen für eine Spezifische Software auf. Bisher haben wir 2 Instanzen im Morroring noch aus der Server 2008 Zeit (aktuell auf 2016 upgegraded; DBs ebenfalls auf Feature Level 2016). D. h. wir verwenden eine Instanz als Primary und eine als Secondary Mirror. Nun ist es ja schon seit SQL Server 2012 bekannt, dass Mirroring "irgendwann" seitens Microsoft bzw SQL nicht mehr supported wird.

Für die 2 neuen Instanzen haben wir uns also entschieden, direkt auf das neue System mit Avvailability Groups (AG) zu setzen. Jetzt ist halt Microsofts Dickmove, dass es die AGs ausschließlich in der SQL-Server ENTERPRISE Lizenz enthalten sind. Das allein würde heißen, dass wir PRO INSTANZ statt 1800EUR schlanke 25.000EUR ausgeben müssten! Ein SCHELM!
da gab es bei nicht umsonst richtig Radau kundenseitig. Long story short, Microsoft hat mit der SQL Server 2016er Version eine "Basic Availibility Group" (BAG) eingeführt. Das die meisten "coolen" Featuers der normalen AG weglässt. Es kann zb. nur eine DB beinhalten, nur 2 Instanzen gegenseitig failovern etc. sprich, von der Funktionsweise nahezu 1:1 das alte Mirroring. Technisch jedoch auf den AGs aufbauend. Was unser Problem ist.
denn um eine BAG aufzubauen, benötigt man das "Windows Server Failover Cluster" (WSFC)- Feature welches wiederum scheinbar "Shared Storages" (das kürze ich mal nicht ab ) voraussetzt, was aber wohl nicht zwingend ist und in meinen Augen auch unnötig komplexität reinbringt. schlimmer noch: Das shared Storage ist dann das "single point of failure" was in meinen Augen den Sinn eines Mirroring komplett aushebelt, wenn man 2 Server hat, die auf EINEM Speicher arbeiten. Siehe Grafik:



Laut mehreren Berichten braucht man das Shared Storage nicht für den SQL Server, allerdings laufe ich in ein Problem beim Anlegen/Validieren des WSFC:

Spoiler: Validation Report

Logge dich ein oder registriere dich jetzt. to view Spoiler content!

Scheinbar hat Der WSFC-Validator ein Problem mit den Platten der beiden VMs.
Aufbau:
Fujitsu Eternus DX200 Storages mit mehreren LUNs ==> via iSCSI an ESXi 7.0 Host mit VMs darauf und virtelle Platten als VMDKs auf einem der Datastores der Storage LUNs (also alles rel Standard)
das ganze 2x. Sprich, jede VM ist auf einem anderen Host, also Clustering across Boxes (CAB).

Das Problem ist, dass Sowohl Microsoft als auch VMWare UND Fujitsu jeder eigenes Marketingsprech für die SELBEN Technologien verwenden und ich aktuell bei der Problembeseitigung nicht so richtig weiterkomme.
Kostprobe Fujitsus Technikjargon:

GOOD!? ERNSTHAFT!? Wer hat das konstruhiert ein 6 Jähriger!?
Und SO ein Mist zieht sich durch das ganze Konfig-Menü der Fujitsu eternus Storages. KA-TA-STROPHE!


Kennt jemand aus der SQL- oder der Windows Server Failover-Ecke diesen Fehler und kann mir mal ne Richtung weisen. Aktuell stocher ich auf breiter Front iwie ins leere. 1000de Suchtreffer, aber wenn es um details geht, dann haben die "nur" ihr storage neu formattiert oder NUR eine andere Virtualisierung verwendet oder NUR alles bare mattel gemacht oder NUR alles auf Fiber Channel umgestellt oder, men pers. Favorit, NUR DIE ENTERPRISE-LIZENZEN GEHOLT!
JA DANKE! Wir haben da Produktivserver und unsere MessdatenDBs drauf laufen die über 22TB groß sind. Tollerierbare Downtime ist Tagesformabhängig 10-25Min. das reicht so gerade für einen Sauberen reboot, aber KEINE erweiterte Wartung. (DARUM JA DAS MIRRORING) Mit Shared Storage ists da Essig. funktioniert nicht.

Bei den ganzen Manuals der Hersteller oder Tutorials wird auf dieses Problem nicht eingegangen und immer als "Vorgabe definiert".

TL;DR
Mirroring einer SQL Server DB auf 2 Servern wird nicht mehr supported. Nachfolger der SQL Server Standard Edition sind die Basic Availability Groups, die Windows Server Failover Cluster nutzen, diese lassen sich wegen einem Validation Error der Disks nicht einrichten. Kennt jemand das Problem bzw kann sagen, wo ich nach der Lösung suchen muss?

 

[Itrocket]

Also das Storage unten drunter (ob Fujitsu oder sonst was) sollte Wurst sein. Dafür ist rein der Hypervisor verantwortlich. Windows selbst sollte die Laufwerke als physikalische Disk sehen, alles unten drunter sollte Wurst sein, es sei denn ihr nutzt Herstellerspezifische Tools, wie ich damals mit Datacore (hat mir öfter in die Suppe gespuckt, seit dem nur noch Windows standard tools).

Die VMDKs hängen aber standardmäßig an einem virtuellen SCSi Adapter der VM, nix mit pass through oder so was? Also irgendwelche Fujitsu spezifischen overlays, welche ins Betriebssystem direct als Tool zum Einbinden von Disks genutzt wird.

Wir haben diverse SQL DAG, allerdings auf Hyper V, kann das Problem mal am Montag mit meinem SQL Spezi besprechen. Aber shared storage braucht man definitiv nicht, wir haben die zum Teil über 3 RZ verteilt. Allerdings nur im LAB als BAG, ansonsten haben wir uns die leicht zu teure Lizenz "gegönnt".

Bin momentan etwas angeheitert und somit wenig hilfreich.

Eventuell vertrauliche Dinge per PN.

 

[silverSl!DE]

Vielen Dank schonmal.
Jep ist nichts extravagantes. bewusst alles bei den Standardsachen belassen. Pass throug hab ich ebenfalls nicht gemacht. alles ganz normal über vSCSi Adapter an den VMs.

kann das Problem mal am Montag mit meinem SQL Spezi besprechen.

Das wäre Mega!

Aber shared storage braucht man definitiv nicht, wir haben die zum Teil über 3 RZ verteilt.

Genau DAS wollte ich hören . wir sind nämlich dabei den Hardwareumzug zum neuen Standort zu planen und da brauchen wir das Mirroring, bzw BAG ohne shared storage, damit wir knotenweise ohne Downtime umziehen können.

ansonsten haben wir uns die leicht zu teure Lizenz "gegönnt".

Joa das haben wohl viele ;-)
für uns leider keine Option...

Rest per PN

 

[silverSl!DE]

Sooooo Es läuft endlich!
evtl sucht ja jemand mal was ähnliches, aber haupsachlich dient der Post dem Rubber Ducking bzw der Zusammenfassung davon um es besser zu behalten. ==> Rubber Duck Debugging
Nach dem Korrigieren der VM in vSphere (DICKES Danke an @Itrocket für die wertvollen Tipps) Waren zumindest die Grundvoraussetzung gelegt:
- VMs dürfen NICHT geklont sein, da beim Klonen die GUID der Virtuellen HDDS NICHT geändert wird und der Cluster Manager dann plötzlich mehrere HDDs mit der selben Unique ID sieht, was logischerweise zu einem undefinierten Zustand führen kann.
- Die VMDKs (Virtuellen HDDs) MÜSSEN Thick provisioned UND eagerly zeroed sein! WICHTIG! Oberflächensprache auf ENGLISCH(!!!) umstellen. In deutsch ist (mal wieder) ein grober Übersetzungsfehler:

deutsch:


Des Weiteren müssen auf den VMs lokale AdminUser angelegt werden, die auf allen VMs identisch sind. Mit diesem User richtet man das WSFC ein und lässt den SQL-Service laufen. dadurch ist man nicht mehr vom Active Directory abhängig.
Man braucht dennoch zwingend einen DNS server für das Netz, worüber das Cluster Läuft bzw. die SQLserver kommunizieren und die DBs syncen. Für den Anfang gingen auch einträge in die HOST files, aber das ist schon dirty und steigert den Aufwand mit jeder IP (und davon gibt es im Clusterservice EINIGE) exponentiell.
Um das Cluster fehlerfrei ans laufen zu bringen, musste ich mein Büronetz-Netzwerkadapter (also das Produktivnetz, von welchem die Software clients der User auf den Server zugreifen) auf allen VMs erst deaktivieren. erst dann konnte ich die MGMT und Clusternetze konfigurieren und das Cluster fehlerfrei onlinebringen. bei der erstellung sucht der automatisch nach einem Domänennetzwerk und nimmt automatisch dann das netz. und akzeptiert auch keine anderen lokalen Netze. Sehr ärgerlich, wenn man es nicht will.
Wenn alles wie gewünsch eingerichtet ist darf man aber noch NICHT dsa Produktivnetz zuschalten. bei mir löste es dann direkt ERROR Event ID 1258 heraus: DNS Fehler. "It's ALWAYS DNS!" Jedoch konnte jeder jeden pingen, sehen und FW-Ports waren alle offen. Schaltete ich das Produktivnetz ab, lief wieder alles. Hintergrund ist wohl dass er meherer DNS-Server sieht und sich dann nicht entscheiden kann was er für welches netz nimmt. Wichtig an der Stelle den DNS server für das Cluster Netz auch nur das Clusternetz Interface zu verwalten und alles andere zu ignorieren. Die Meldung ist: dass in dem Clusternetz zwar ein DNS Server da ist, aber ein Standard-Gateway fehlt. Wenn man das Gateway hinzufügt, rastet der KOMPLETT aus, weil er plötzlich mehrere Standardgateways hat
Meine Lösung war das system ohne produktivnetz fehlerfrei über das Wochenende laufen zu lassen. anschl kamen paar windows updates und ein reboot. danach lief es auch mit aktivierdem Produktivnetz. Vermutlich hing irgendwo etwas, was einen weiteren reboot brauchte oder es gab einen Bugfix diesbezüglich in den windows server updates, glaube aber eher nicht daran...

Der rest war rel easy.
Sqlserver STANDALONE(!!!) instanz installieren. NICHT die clustered Instance Installation!
SQL-Server wie gewünscht und benötigt installieren, jedeoch den SQL-Service/DB-Engine mit dem anfangs erstellten Cluster-User laufen lassen und diesem so wie den gewünschten, lokalen Admins DB-Admin-rechte gewähren/eintragen. Für eine bessere Security kann man das nach wunsch anpassen. aber man sollte sich sicher sein, was man tut ;-)
Nach der Installation einen SMB-Share einrichten und dem Clusteruser rechte darauf erteilen. dieses Share wird von allen VMs genutzt.
Jetzt erstellt man (oder der Installer der verwendeten Client-Software) die DB auf dem Primary SQL-Server
Nun unter Avalability Groups eine neue BAG erstellen. Backupmode muss FULL with Transaction Logs sein. Als Secondary dann den 2. server eintragen und das SMB-Cluster-Share angeben. DAS BAG nutzt es um die DB auf den Secondary Server zu replizieren.
Nicht zwingend, aber empfehlenswert ist es einen BAG-Listender Für diese BAG anzulegen. Man vergibt dem Listener einen eigenen DNS-Namen und IP. Diese kann man dann von der Software verwenden, statt der Server-IP und hat dann eine Automatisch ausfallsicherheit, da das BAG dann von sich auf den jeweilig aktiven Primary weiterleitet. Man kann aber auch weiterhin wie beim alten Mirroring direkt die ServerIPs nehmen muss dann aber beim failovern immer daran denken auf Clientseite die Configs anzupassen.
Damit das Failovern auch zuverlässig läuft, sollte man den commit mode von Asynchron auf Synchron umstellen.
Failovern kann man nun nicht mehr über das alte mirror > Failover, sondern über Availability Groups, die gewünschte BAG auswählen (Immer nur eine DB pro BAG ;-)) und dann failover to Secondary.

Das war's.
easy.

 

[Ursus]

Hä? Bahnhof, Abfahrt, welches Gleis?

 

[*Chris*]

Hä? Bahnhof, Abfahrt, welches Gleis?

Bin auch froh in meiner Arbeit nur 10 verschiedene zahlen tippen zu müssen, muss ich wenigstens nicht denken

 

[Ursus]

Ach, und wenn ich Rubber Duck höre, dann denke ich an ihn hier

Aber ich bin ja auch schon alt

 

[BMW-Claus]

Ach, und wenn ich Rubber Duck höre, dann denke ich an ihn hier

Aber ich bin ja auch schon alt

Ich bin auch schon alt und erinnere mich noch sehr genau an den guten Rubber Duck! Und wenn ich im Posting von Silberschlitten "STANDALONE" lese, denke ich eher an STALLONE

 

[Itrocket]

Sooooo Es läuft endlich!
evtl sucht ja jemand mal was ähnliches, aber haupsachlich dient der Post dem Rubber Ducking bzw der Zusammenfassung davon um es besser zu behalten. ==> Rubber Duck Debugging
Nach dem Korrigieren der VM in vSphere (DICKES Danke an @Itrocket für die wertvollen Tipps) Waren zumindest die Grundvoraussetzung gelegt:
- VMs dürfen NICHT geklont sein, da beim Klonen die GUID der Virtuellen HDDS NICHT geändert wird und der Cluster Manager dann plötzlich mehrere HDDs mit der selben Unique ID sieht, was logischerweise zu einem undefinierten Zustand führen kann.
- Die VMDKs (Virtuellen HDDs) MÜSSEN Thick provisioned UND eagerly zeroed sein! WICHTIG! Oberflächensprache auf ENGLISCH(!!!) umstellen. In deutsch ist (mal wieder) ein grober Übersetzungsfehler:
Anhang anzeigen 16437
deutsch:
Anhang anzeigen 16438

Des Weiteren müssen auf den VMs lokale AdminUser angelegt werden, die auf allen VMs identisch sind. Mit diesem User richtet man das WSFC ein und lässt den SQL-Service laufen. dadurch ist man nicht mehr vom Active Directory abhängig.
Man braucht dennoch zwingend einen DNS server für das Netz, worüber das Cluster Läuft bzw. die SQLserver kommunizieren und die DBs syncen. Für den Anfang gingen auch einträge in die HOST files, aber das ist schon dirty und steigert den Aufwand mit jeder IP (und davon gibt es im Clusterservice EINIGE) exponentiell.
Um das Cluster fehlerfrei ans laufen zu bringen, musste ich mein Büronetz-Netzwerkadapter (also das Produktivnetz, von welchem die Software clients der User auf den Server zugreifen) auf allen VMs erst deaktivieren. erst dann konnte ich die MGMT und Clusternetze konfigurieren und das Cluster fehlerfrei onlinebringen. bei der erstellung sucht der automatisch nach einem Domänennetzwerk und nimmt automatisch dann das netz. und akzeptiert auch keine anderen lokalen Netze. Sehr ärgerlich, wenn man es nicht will.
Wenn alles wie gewünsch eingerichtet ist darf man aber noch NICHT dsa Produktivnetz zuschalten. bei mir löste es dann direkt ERROR Event ID 1258 heraus: DNS Fehler. "It's ALWAYS DNS!" Jedoch konnte jeder jeden pingen, sehen und FW-Ports waren alle offen. Schaltete ich das Produktivnetz ab, lief wieder alles. Hintergrund ist wohl dass er meherer DNS-Server sieht und sich dann nicht entscheiden kann was er für welches netz nimmt. Wichtig an der Stelle den DNS server für das Cluster Netz auch nur das Clusternetz Interface zu verwalten und alles andere zu ignorieren. Die Meldung ist: dass in dem Clusternetz zwar ein DNS Server da ist, aber ein Standard-Gateway fehlt. Wenn man das Gateway hinzufügt, rastet der KOMPLETT aus, weil er plötzlich mehrere Standardgateways hat
Meine Lösung war das system ohne produktivnetz fehlerfrei über das Wochenende laufen zu lassen. anschl kamen paar windows updates und ein reboot. danach lief es auch mit aktivierdem Produktivnetz. Vermutlich hing irgendwo etwas, was einen weiteren reboot brauchte oder es gab einen Bugfix diesbezüglich in den windows server updates, glaube aber eher nicht daran...

Der rest war rel easy.
Sqlserver STANDALONE(!!!) instanz installieren. NICHT die clustered Instance Installation!
SQL-Server wie gewünscht und benötigt installieren, jedeoch den SQL-Service/DB-Engine mit dem anfangs erstellten Cluster-User laufen lassen und diesem so wie den gewünschten, lokalen Admins DB-Admin-rechte gewähren/eintragen. Für eine bessere Security kann man das nach wunsch anpassen. aber man sollte sich sicher sein, was man tut ;-)
Nach der Installation einen SMB-Share einrichten und dem Clusteruser rechte darauf erteilen. dieses Share wird von allen VMs genutzt.
Jetzt erstellt man (oder der Installer der verwendeten Client-Software) die DB auf dem Primary SQL-Server
Nun unter Avalability Groups eine neue BAG erstellen. Backupmode muss FULL with Transaction Logs sein. Als Secondary dann den 2. server eintragen und das SMB-Cluster-Share angeben. DAS BAG nutzt es um die DB auf den Secondary Server zu replizieren.
Nicht zwingend, aber empfehlenswert ist es einen BAG-Listender Für diese BAG anzulegen. Man vergibt dem Listener einen eigenen DNS-Namen und IP. Diese kann man dann von der Software verwenden, statt der Server-IP und hat dann eine Automatisch ausfallsicherheit, da das BAG dann von sich auf den jeweilig aktiven Primary weiterleitet. Man kann aber auch weiterhin wie beim alten Mirroring direkt die ServerIPs nehmen muss dann aber beim failovern immer daran denken auf Clientseite die Configs anzupassen.
Damit das Failovern auch zuverlässig läuft, sollte man den commit mode von Asynchron auf Synchron umstellen.
Failovern kann man nun nicht mehr über das alte mirror > Failover, sondern über Availability Groups, die gewünschte BAG auswählen (Immer nur eine DB pro BAG ;-)) und dann failover to Secondary.

Das war's.
easy.

Der Übersetzungsfehler ist ja ekelhaft. Ich weiß weshalb ich alles nur englisch lasse.

Schön dir etwas geholfen zu haben. War ein steiniger Weg. Wird leider nicht einfacher.

 

[silverSl!DE]

Der Übersetzungsfehler ist ja ekelhaft. Ich weiß weshalb ich alles nur englisch lasse.

Same here, aber vSphere UI nimmt ja gerne die Browser Sprache. Muss es immer wieder, wenn ich Mal den Browsercache geleert habe neu setzen und da es halt mal aus bequemlichkeit nicht gemacht. Sehr bitter.

Schön dir etwas geholfen zu haben. War ein steiniger Weg. Wird leider nicht einfacher.

Das ist korrekt, aber wenn alles so easy peasy lemon squeezy ist, hab ich da auch kein bock drauf. Da lass ich lieber die Azubis lernen.
So komplexe themen machen RICHTIG bock. Vor allem wenn ich mich wochenlag grün ärgere und mich richtig durchwühle und es am ende doch geht. DAS boostet so richtig die Motivation!

Vor allem wenn selbst ChatGPT mit overload error aufgibt
Deutsch:

Englisch hat es zumindest die grundlagen noch angefangen



Nach etwas training gestern und heute kamen auch sch recht gute und detailierte antworten. Jedoch sind nach wie vor immer wieder techn. Fehler drin.

Aber wenn man mitarbeiter freundlich anflaumen will, ist das ding SPITZE!