silverSl!DE
Teammitglied
- Mitglied seit
- 7. Juni 2005
- Beiträge
- 14.695
- Alter
- 39
- Ort
- Düren
- Website
- www.drivers-forum.de
- Fahrzeug(e)
- 2006er BMW E90 325i
2011er BMW F25 X3
- Garagenstellplatz1
- [1]
- Garagenstellplatz2
- [2]
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:
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?
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:
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?
Zuletzt bearbeitet: