Ruhe – Veränderungen – Aussichten – Teil 1

Hier war es sehr lange Zeit sehr ruhig und ich möchte heute erzählen warum und wieso – und warum ich aus diesem Blog eigentlich jetzt einen Reiseblog machen könnte. 😉

Die Corona Pandemie hat die Welt verändert, nicht nur die große, sondern auch die Welt im persönlichen, sei es die Arbeitswelt, das private Umfeld, das familiäre Leben, alles hat sich in diesen (bisher) 2 Jahren verändert. Leider nicht immer unbedingt zum Positiven… auch bei mir hat sich Vieles verändert, was eigentlich mit dem Wechsel ins Home-Office begann bzw mit dem ersten Lockdown. Aber ich möchte mit einer Grundlage anfangen, nämlich einem der Hauptgründe für die letzten 3 Jahre. Ich wollte unbedingt wieder mehr Kundenkontakt, den Kunden direkt betreuen, mit dem Kunden am Tisch sitzen, gemeinsam vor einem Bildschirm Fehler analysieren oder am Whiteboard über Lösungen und Technologien diskutieren, ihn von der großartigen Produkten und Services in Microsoft Azure überzeugen.

Also startete ich im Mai 2019 meine Reise mit Kramer&Crew als Consultant für die Microsoft Data Platform & Azure, hier konnte und durfte ich mich bei Bestands- oder Neukunden in meinem Arbeitsbereich “austoben”. Natürlich bin ich (verhältnismäßig) viel durch Deutschland gereist, habe die unterschiedlichsten Kunden aus den verschiedensten Branchen mit unzähligen Ideen und Herausforderungen kennenlernen dürfen. Ich war eigentlich im Schnitt 3 Tage die Woche unterwegs, mal im Norden ohne Übernachtungen, mal im Süden mit einer oder mehr Nächten in Hotels oder Pensionen… ich war sehr glücklich, weil es genau das war, was ich wollte… es machte einfach Spaß!!!

Dann kam die Pandemie…

Es war natürlich nicht der eine Tag, aber für mich ist eine bestimmte Veranstaltung (mehr oder weniger) der Schlussstrich gewesen… alle waren glücklich, dass man sich noch einmal treffen konnte, die Veranstaltung so gerade eben noch nicht abgesagt wurde, alle waren verunsichert und vorsichtig… die SQLKonferenz 2020 der PASS in Darmstadt

SQLKonferenz 2020 Darmstadium - Blick ins Forum auf die Sponsoren-Stände

Kurz danach ging es den Lockdown und somit in das endgültige Home-Office, aber zumindest durfte ich hier meiner Leidenschaft noch einmal nachgehen, ich konnte die Azure Meetups mit einem Stand repräsentieren und auch einen Vortrag halten, so wie mit all den wunderbaren Menschen aus der Data-Plattform-Community lernen, plaudern, mich austauschen und feiern.

Durch die Pandemie, den Lockdown und die Ungewissheit wie es weiter gehen sollte, veränderte sich natürlich auch mein Alltag. Keine Vor-Ort-Termine mehr mit den Kunden, keine stundenlangen Fahrten zum Nachdenken und Ideen sammeln mehr, kein Erfahrungsaustausch mit den Kollegen in der Küchen mehr, alles fiel weg. Wenn die Arbeit (wie bei einigen Kunden) nicht komplett eingestellt wurde, so wurden doch zumindest sehr viele Projekte sehr weit zurückgefahren und man hatte plötzlich Zeit und manchmal auch Langeweile so “alleine” eingesperrt zuhause.

Man gewöhnte sich dran, man entwickelte neue Routinen und Tagesabläufe, denn die ganze Familie war ja plötzlich zuhause und musste sich umstellen. Jeder hat damit leider so seine Erfahrung machen müssen. Diese neuen Tagesabläufe haben – zumindest bei mir – dafür gesorgt, dass ich irgendwann anfing früher und länger zu arbeiten, lange liegengebliebene Inventuren machen, Dokumentationen fertigstellen, sich mit Weiterbildung beschäftigen, neue Technologien anschauen und kennenlernen, Kunden- und Community-Präsentationen neu erstellen und optimieren. Was man so halt alles im Home-Office macht bzw nicht macht => eben Pausen, sich Entspannen, sich Zeit nehmen, Durchatmen, gerade wenn man viel Freude an dem hat was man so macht…

Eindruck aus meinem Home-Office - Ausprobieren von Demos und Lerninhalten

Unter der Angst, dem Druck, der Ungewissheit der täglichen Nachrichten und Hiobsbotschaften und dem unsicheren Arbeitsumfeld – welche Kunden ziehen welche Projekte wieder zurück, wann muss ich in Kurzarbeit, wie geht es weiter… versucht man sich eben abzulenken und sitzt noch länger vor dem Computer und beschäftigt sich mit interessanten Aufgaben.

Und so kam es dann, dass ich im Sommer 2021 zwischen 50 und 60 Stunden in der Woche gearbeitet habe bzw mich in irgendeiner Art und Weise mit Arbeiten beschäftigt habe, glücklicherweise haben viele Kunden Ihre Projekte wieder hochgefahren bzw neue Projekte ins Leben gerufen, so dass es nie langweilig wurde und immer genügend zu tun war. Leider vernachlässigte ich durch diese Tagesabläufe, das viele Arbeiten meine Familie und mein Privatleben, man war gestresster, man war müde, ich kannte eigentlich nur noch noch “schlafen, arbeiten, fernsehen and repeat”, die Gesamtsituation machte mich immer unglücklicher und depressiver.

Eine Veränderung musste her…

Die ersten Gedanken – wie komme ich aus dieser Schleife raus – hatten ich bzw natürlich mit meiner Familie bereits im Frühjahr 2021, wir müssen was ändern. Arbeitstechnisch war ich glücklich (wenn ich denn zu Kunden gekonnt hätte), aber der Rest passte einfach nicht mehr. Ich war in einem Kundenprojekt “Einführung M365” und die Projektleiterin erzählte bei jeder Schulung den Teilnehmern, dass sie aus einer Generation kommt, der man beigebracht hatte, “je mehr du leistest, desto mehr bekommst du”. Auch diese Erziehung haben mir meine Eltern (wenn auch unbewusst) zukommen lassen, also spürte ich irgendwann irgendwie den Druck nicht mehr genug zu leisten, zu wenig auf der Arbeit zu machen => mein Chef könnte unzufrieden sein, meine Frau könnte unglücklich sein, weil ich so viel arbeite und ihr im Haushalt nicht helfe, mein Sohn könnte sich von mir distanzieren, weil ich keine Zeit mehr mit ihm verbringe, meine Eltern könnten unzufrieden sein, weil es nicht mehr weitergeht, was könnten meine Nachbarn denken, wenn nur noch ein Auto vor der Tür steht… ich setzte mich selber unter Druck bzw fühlte mich von der Gesellschaft unter Druck gesetzt, denn auch in der Nachbarschaft machte sich der Corona-Druck breit… Nachbarn fingen an sich gegenseitig auszuspionieren, wer trifft sich wann mit wem und mit wievielen, “oh, guck mal, der aus Nummer 8 ist in Quarantäne!”, man durfte zeitweise nur raus um mit dem Hund zu gehen… es fühlte sich wie permanenter Druck an und die Spirale drehte sich weiter…

Wir wollten im Grunde (auch wenn es einfach gesagt ist) nur noch “weg”, “raus” aus der Spirale…
Also hatte ich im Frühjahr 2021 angefangen nach einer neuen Arbeitsstelle im Ausland (Primärziel USA) zu suchen, wenn schon denn schon, war die Devise. Da es aber eine weltweite Pandemie ist, war dieser Wunsch dank der Reise- bzw Einreisebeschränkungen nicht ganz so einfach… es wurde Sommer und es war immer noch keine Möglichkeit zur “Flucht” vorhanden… also anders denken/handeln, eben verändern. 😉 Also haben wir uns erst einmal mit den folgenden Fragen beschäftigt:

  • Welche Möglichkeiten gibt es überhaupt zum Auswandern (mit oder ohne Arbeiten)?
  • Welche Möglichkeiten der Arbeit gibt es in dem Land?
  • Was kostet das Leben in dem Land?
  • Was brauchen wir um dort zu Leben?
  • Umziehen oder kompletter Neuanfang?
  • Wieviel Budget haben wir?
  • Was kann/macht unser Sohn?
  • Welche Möglichkeiten hat er in dem Land?
  • Ist es nur temporär oder können wir uns vorstellen für immer in dem Land zu bleiben?

Entscheidungen treffen…

Weiter in Teil 2 😉

Azure Arc-enabled Data Services – Cloud Summit 2021

Auch gestern durfte ich wieder auf einer internationalen Community-Veranstaltung – dem Cloud Summit – über Azure Arc-enabled Data Services sprechen, natürlich in der Hauptsache wie man eine Azure SQL Managed Instance im eigenen Rechenzentrum betreiben kann. Wie bereits auf dem DataSaturday #14 in Oslo, habe ich bei den verschiedenen Möglichkeiten von Azure Arc begonnen und habe die einzelnen Komponenten der Umgebungen vorgestellt, was wird benötigt und wie kann man dies recht einfach deployen. Zum Ende hin gab es wieder eine ausführliche Demonstration wie man einen Data Controller auf Kubernetes deployen kann und wie man dann mittel Azure Data Studi eine Managed Instance oder PostgreSQL Hyperscale ausrollen kann.

Ich habe mich sehr gefreut ein Teil dieser mehrere Tage gehenden Veranstaltung Cloud Summit 2021 zu sein, der Vortrag selber war aus meiner Sicht ein sehr gelungener, alles hat funktioniert, die Zeit wurde etwas knapp aber auch daran kann man zukünftig arbeiten/nachbessern.

Ich wollte mit diesem kurzen Beitrag nur schnell die Slides online stellen und mich bei den Organisatoren und Sponsoren des Cloud Summits recht herzlich bedanken !

Cloud Summit 2021 – Bjoern Peters – Azure Arc-enabled data services

Data Saturday #14 – Oslo 2021 – Einführung in Azure Arc Data Services

Heute war es soweit – ich durfte endlich einmal auf dem Data Saturday (ehemals SQLSaturday) in Oslo sprechen… das endlich lag nicht an den Organisatoren sondern eher an mir bzw an der Pandemie, da ich mich bis 2020 nicht getraut hatte, Vorträge auf Englisch zu halten, hatte ich auch keine Sessions für Oslo eingereicht. Am liebsten wäre ich natürlich vor Ort gewesen, denn Norwegen bzw Oslo sind wunderschön, ich kenne mittlerweile auch mehrere Community-Member in der Region die ich nun auch schon lange Zeit nicht mehr gesehen habe, aber es musste dieses Jahr erst einmal virtuell bleiben, vielleicht ja im nächsten Jahr wieder in person.

Nun aber zu meinem Vortrag zur Einführung in Azure Arc bzw Azure Arc Data Services, um den es am Samstag, den 04. September 2021 um 9:45 ging. Azure Arc selber ist erst einmal eine Plattform, ein Service den Microsoft in Azure bereitstellt, um die Verwaltung von verschiedenen Umgebungen – Hardware, virtuelle Maschinen, Windows, Linux, AWS, GCP oder was auch immer – in einer zentralen Stelle zu verwalten und zu administrieren.

Einführung in Azure Arc

Damit kann man nun beispielsweise seine on-premise Windows oder Linux Server mit dem Azure Portal verbinden, um diese von dort aus zu administrieren. Oder auch von der Vielzahl an Services aus der Cloud wie zum Beispiel Security oder Compliance, diese Benefits bringt eben Azure Arc mit sich, in dem man seine on-premise Systeme in die Analysen dieser Azure-Services mit einbinden kann. Des weiteren kann man auch Automatisierungen wie zum Beispiel Patching oder Backups aus dem Azure Portal oder anderen Azure Services heraus erstellen und administrieren, was einen erhebliche Vorteil in der Vereinheitlichung der Systeme und Prozesse bedeutet.

Und das nicht nur mit on-premise Servern bzw Systemen sondern eben auch Multi-Cloud und auch “disconnected” Systemen, auch mit Kubernetes Clustern oder SQL Servern

  • Azure Arc-enabled servers
  • Azure Arc-enabled Kubernetes
  • SQL Server auf Azure Arc-enabled Servers
Alle Applikationen, Systeme und Umgebungen zentral vereint

Azure Arc Data Services

Unter Azure Arc Data Services versteht man nun die Möglichkeit eine Azure SQL Managed Instance oder eine Postgres Hyperscale auf einem “x-beliebigen” Kubernetes Cluster zu betreiben, ob dieses Kubernetes Cluster nun im eigenen Rechenzentrum oder in einer anderen Cloud steht, ist erst einmal egal, Hauptsache es handelt sich um ein CNCF-zertifiziertes Kubernetes-Cluster.

Um aber eben eine Managed Instance in seinem eigenen Rechenzentrum zu betreiben, muss man mehrere Schritte befolgen… zum einen sollte man das Kubernetes-Cluster zu einem Azure Arc eneabled Kubernetes machen, zum anderen muss man einen “Connector/Agent” auf diesem Cluster ausrollen, den Data-Controller. Dieser Data Controller stellt die Schnittstelle zwischen Azure, dem Azure Portal und der SQL Managed Instance her. Nun kann man über verschiedene Wege – Azure Portal, Azure CLI oder Azure Data Studio – auf diesem Cluster eine voll funktionsfähige SQL Managed Instance deployen und nutzen.

Deployment einer Azure SQL Managed Instance auf einem Data Controller
auf dem eigenen Kubernetes Cluster

Aus persönlicher Sicht, ist dies eine großartige Geschichte, einen zentralen Anlaufpunkt für alle genutzten Services und Applikationen zu haben und somit auch die zusätzlichen (Sicherheit bringenden) Features aus Azure auf allen Systemen zu nutzen. Alles in allem ein Zugewinn für das Unternehmen!

Meine Slides und weiterführende Links

DataSaturday-Oslo-2021-Azure-Arc-Data-Services.pdf

Microsoft Dokumentation

Wenn man selber diese Möglichkeit des Rollouts von Azure Data Services ausprobieren möchte, dann kann ich jedem nur empfehlen sich mit den Jumpstart Szeanarien von Microsoft zu beschäftigen, hier werden vorgefertige Umgebungen ausgerollt mit denen man dann problemlos testen kann, was wie wo funktioniert:

https://azurearcjumpstart.io/overview/

Bleibt mir nur noch DANKE an alle Zuhörer und die Organisatoren zu sagen, es war mir eine Freude und hat viel Spaß gemacht. #CommunityRocks

Warum “SQL aus Hamburg” oder “Nord DBA” ?

Eigentlich hätte ich diesen Beitrag schon vor Jahren mal schreiben sollen ;-), um die Historie bzw die Entstehungsgeschichte dieses Blogs zu beleuchten. Aber wie heißt es so schön… es ist nie zu spät.

Damals hatte ich meine ersten Initiativen und Aktivitäten mit der deutschen SQL Server Community unternommen, die ersten Veranstaltungen besucht und die ersten Kontakte geknüpft und musste leider feststellen, dass meine Kenntnis vom SQL Server auch nach mehr als 10 Jahren eher gering ausfiel. Dies gefiel mir selber nicht und ich habe mir das Ziel gesetzt mich mehr mit dem Produkt zu beschäftigen, also im Grunde genau die Geschichte warum ich in der Community aktiv bin. Zu der zeit war ich als Datenbank-Administrator beschäftigt und habe gemeinsam mit meinem Kollegen Thomas, die SQL Server unserer Kunden betreut. Thomas wusste aus anderen Bereich zum SQL Server viel und ich wusste ja auch schon viel, so haben wir uns wunderbar ergänzt. Gemeinsam wollten wir diesen Blog betreiben und über unsere täglichen Erlebnisse, Probleme oder Herausforderungen schreiben. Da wir beide – in einem größeren Team verteilt über Deutschland – aus Hamburg kamen und es um unsere Hauptaufgabe – den SQL Server – ging, war die Suche nach einem Namen relativ einfach…

Aufgrund meiner – damals noch aktiven Selbstständigkeit – war ich bereits im Besitz eines entsprechenden Webspace und die Domäne “SQL-aus-Hamburg.de” war schnell registriert. Der erste Blogbeitrag ließ auch nicht lange auf sich warten, dann wurde es etwas ruhiger 🙁
Wir hatten uns das wahrscheinlich einfacher vorgestellt, die Arbeit wurde mehr… ich kann nicht mehr genau sagen, warum wir nichts geschrieben haben… vielleicht war es oder wir damals einfach noch nicht so weit… Thomas hatte immer gute Ideen und hat mir sozusagen die Überschriften geliefert… aber leider nie selber geschrieben (soll kein Vorwurf sein!)… und dann kam alles anders… Leider ist Thomas unerwartet und plötzlich verstorben, ich musste und habe dann diesen Blog unter demselben Namen weitergeführt.

Für mich ist dieser Blog im Grunde immer noch, siehe die letzten Posts zum Azure SQL Database Refresh, nur ein Notizbuch, in dem ich meine eigenen Erfahrungen für mich selber Revue passieren lasse, um sie vielleicht irgendwann doch einmal herauszusuchen oder mich daran zu erinnern, wann ich was wie erfolgreich lösen konnte.

Warum SQL-aus-HH ???

In den sozialen Medien findet man mich entsprechend auch unter @SQL_aus_HH, für den deutschsprachigen Leser überhaupt kein Problem eine Verbindung zwischen Hamburg und HH zu ziehen… ursprünglich hatte ich auch nie mit dem Gedanken gespielt, dass ich irgendwann auch mal englischsprachige Beiträge schreibe oder sogar Vorträge auf internationalen Veranstaltungen halte… daher hier noch einmal zur Verdeutlichung für die “Ausländer”.

Hamburg ist eine Hansestadt und trägt daher auf dem deutschen KFZ-Nummernschild die Abkürzung HH für “Hansestadt Hamburg“.

Bereits im Mittelalter verdienten sich Kaufleute mit dem Fernhandel eine goldene Nase. Besonders erfolgreich war die Hanse. So nannte sich vor etwa 700 Jahren ein Bündnis aus Städten und Kaufmannsverbänden. Der Hansebund wurde geschlossen, um den Handel zwischen den Mitgliedern, den Hansestädten, zu vereinfachen. Damals erschwerten zahlreiche Zölle, verschiedene Währungen und Maßeinheiten den Fernhandel.
[…]
Letztendlich trugen nur noch Hamburg, Bremen und Lübeck offiziell den Titel einer Hansestadt. Hamburg und Bremen haben ihre hanseatische Eigenständigkeit zum Teil sogar bis heute bewahrt. Sie sind – neben Berlin – die einzigen deutschen Städte, die gleichzeitig ein eigenes Bundesland sind. Auch ihre Autokennzeichen weisen auf den mittelalterlichen Städtebund hin: HH steht für die Hansestadt Hamburg und HB für die Hansestadt Bremen.

http://stadtgeschichtchen.de/artikel/stadtgeschichte/was-ist-eine-hansestadt/

Da dieser Blog damals von zwei Personen geführt werden sollte, hatte ich mir auch Gedanken über einen Namen für meinen “persönlichen Auftritt” gemacht bzw wollte im Zusammenhang mit einem Favicon für den Blog etwas “kreativer” sein… als “Nord-DBA”… bitte fragt mich nicht nach den Gründen/Gedanken, die zu diesem Namen geführt haben… ich kann es schlicht weg nicht mehr sagen, aber seit gut 10 Jahren gibt es eben dieses Favicon als “Erkennungszeichen” für diesen Blog.

Solltet ihr noch Fragen zu der Entstehungsgeschichte meines Blogs haben… so schreibt mich einfach an.

Hochverfügbarkeit beim SQL Server – DBCC 2021 – Teil 1

Jeder meiner Kunden hat sich irgendwann mal die Frage gestellt oder zumindest sollte er sich diese Frage stellen, “brauche ich für meine SQL Server oder einen meiner SQL Server eine gewisse Hochverfügbarkeit”. Leider enden diese Überlegungen immer bei der Frage nach dem Budget… natürlich kosten solche HA-Lösungen mehr Geld, je nach Auswahl der Lösung und der Ausstattung der Umgebung müssen entsprechende Lizenzen zur Verfügung gestellt werden. Aber wenn man die im “worst-case” anfallenden Kosten während oder durch einen Ausfall dagegen rechnet, sollte man ganz klar zur Einsicht kommen, dass diese Kosten vertretbar sind.

Ich durfte heute auf der Data Blaster Community Conference 2021 einen Vortrag dazu halten (Vielen Dank liebe SQLPASS Deutschland), hier kommt eine kleine Zusammenfassung aus meinem Vortrag.

Ich habe direkt am Anfang dargestellt, wie hoch solche Kosten sein können, hierzu habe ich mit Hilfe eines Online-Rechners von Percona eine beispielhafte Rechnung aufgemacht. Der SQL Server fällt für 1-2 Stunden aus, 5 Mitarbeiter sind an dem Restore beschöftigt, jeder von ihnen verdient 100.000 pro Jahr, 100 weitere Mitarbeiter können nicht richtig arbeiten, diese verdienen durchschnittlich 50.000 pro Jahr. Im folgenden Screenshot könnt ihr die Zahlen lesen, die unter Umständen während des Ausfalls, bei der Behebung und deren Nachwirkungen entstehen können.

Warum SQLServer Hochverfuegbarkeit sich rechnet - Percona Calculator

Bei Gesamtkosten von rund 8.000.000 Euro für einen Ausfall eines SQL Servers von rund 2 Stunden, würde ich mir schon vorher überlegen, ob ich z.B. 250.000 Euro im Rahmen der Installation mehr ausgebe, um einen zweiten Server hinzustellen und mit den jeweiligen Lizenzen auszustatten. Aber wie können solche Hochverfügbarkeiten im SQL Server Umfeld aussehen, dazu komme ich in den nächsten Abschnitten, aber erst einmal sollten wir die Überschriften klären… 😉

Hochverfügbarkeit vs Desaster Recovery

Die Definition von Hochverfügbarkeit auf wikipedia.de lautet wie folgt :

Hochverfügbarkeit (englisch high availabilityHA) bezeichnet die Fähigkeit eines Systems, trotz Ausfalls einer seiner Komponenten mit einer hohen Wahrscheinlichkeit (oft 99,99 % oder besser) den Betrieb zu gewährleisten. In Abgrenzung zur Fehlertoleranz kann es bei dem Betrieb im Fehlerfall zu einer Unterbrechung kommen.

https://de.wikipedia.org/wiki/Hochverf%C3%BCgbarkeit

Im Vergleich dazu die Definition von Desaster Recovery

Der englische Begriff Disaster Recovery (im Deutschen auch Katastrophenwiederherstellung oder Notfallwiederherstellung genannt) bezeichnet Maßnahmen, die nach einem Ausfall von Komponenten in der Informationstechnik eingeleitet werden. Dazu zählt sowohl die Datenwiederherstellung als auch das Ersetzen nicht mehr benutzbarer InfrastrukturHardware und Organisation. Umfassender als Disaster Recovery ist der Begriff Business Continuity, der nicht die Wiederherstellung der IT-Dienste, sondern unterbrechungsfreie Geschäftsabläufe in den Vordergrund stellt.

https://de.wikipedia.org/wiki/Disaster_Recovery

Bei der Hochverfügbarkeit geht es eben mehr darum, die eintretende Zeit des Ausfalls, also die Downtime möglichst gering zu halten, so dass alle angeschlossenen Systeme möglichst ohne Datenverlust und manuellen Eingriff schnellstmöglich weiterlaufen. Hierzu sollte man sich vor der Installation natürlich Gedanken zur Prozessgestaltung, den zu erreichenden Zielen und der Notwendigkeit zu machen.

  • Was braucht das Business?
  • Was kostet es das Business wenn sie nicht mehr arbeiten können?
  • Gibt es ggfs einen Kompromiss zwischen Technik und Business? Müssen es wirklich die minimalsten Ausfallzeiten (< 10 Sekunden) sein oder reichen vielleicht auch maximale Ausfallzeiten von kleiner einer Minute?
  • Was kann die Technik überhaupt abbilden? Wissen, Prozesse u.ä.
  • Welceh rechtlichen Rahmen müssen ggfs eingehalten werden?

Und erst wenn man diese Fragen vorher geklärt hat, kann man sich Gedanken über die eigentliche Hochverfügbarkeitslösung machen und wie diese implementiert werden kann/soll.

Das AlwaysOn Failover-Cluster (FCI)

Hochverfuegbarkeit - SQLServer - AlwaysOn Failover Cluster

Kommen wir zu einer der möglichen Lösungen zur Realisierung der Hochverfügbarkeit des SQL Servers innerhalb des eigenen Rechenzentrums, das Windows Failover Cluster (im Grunde identisch zu einem Linux Failover Cluster, hier sollte man sich an die Angaben/Dokumentation der jeweiligen Distribution und eingesetzten Cluster-Software halten).

Initial erstellt man aus zwei Windows Servern mit dem zusätzlich installierten Failover-Cluster Feature ein Windows Failover Cluster, grob gesagt, man verbindet beide Server logisch (und im AD) miteinander. Beide kennen sich und wissen nun, dass sie zusammengehören und tauschen mehrere entsprechenden Health-Status Informationen untereinander aus. Dieses Windows Failover Cluster erhält eine eigene IP und einen eigenen DNS Namen, sowie ein Cluster-Named-Object im AD, dieses CNO “steuert” später das Cluster im AD.

Zu den notwendigen Storage-Requirements kann ich hier wenig sagen, da dies von den jeweiligen Umgebungen abhängt… SAN, NAS, NFS, HCI oder ähnliches, auf jeden Fall muss es sich um einen Storage handeln, der in der Lage ist beiden Servern Zugriff zu gewähren. Microsoft schreibt dazu folgendes:

Storage

Im Gegensatz zur Verfügbarkeitsgruppe muss eine FCI freigegebenen Speicher zwischen allen Knoten der FCI für Datenbank und Protokolle verwenden. Der freigegebene Speicher kann die Form von WSFC-Clusterdatenträgern, direkten Speicherplätzen (Storage Spaces Direct, S2D), Datenträgern auf einem SAN oder Dateifreigaben auf einem SMB aufweisen. Auf diese Weise verfügen alle Knoten in der FCI immer dann über die gleiche Sicht der Instanzdaten, wenn ein Failover auftritt. Dies bedeutet jedoch, dass der freigegebene Speicher das Potenzial hat, die einzelne Fehlerquelle zu sein. Die FCI hängt zudem von der zugrunde liegenden Speicherlösung ab, um Datenschutz sicherzustellen.

https://docs.microsoft.com/de-de/sql/sql-server/failover-clusters/windows/always-on-failover-cluster-instances-sql-server?view=sql-server-ver15&WT.mc_id=DP-MVP-5002576#Recommendations

Nun kann man mit der eigentlichen Installation des SQL Servers beginnen, auf dem Node 1 wird die Basis-Installation für das SQL Server Failover Cluster geschaffen “Erstellung eines Failover-Clusters”, während auf dem Node 2 “nur” ein Knoten zu einem bestehenden SQL Server Cluster hinzugefügt wird.

Je nach Ausgestaltung dieses Cluster – nur eine Instanz oder mehrere Instanzen – müssen SQL Server Lizenzen beschafft werden. Hierbei kann man zwischen zwei Betriebsmodis unterscheiden, aktiv/passiv oder aktiv/aktiv. Bei aktiv/passiv dürfen die SQL Server Instanzen immer nur auf einem Knoten des Clusters laufen, im Fehlerfall für einen begrenzten Zeitraum auch auf beiden Knoten. Bei aaktiv/aktiv können beide Knoten gleichermaßen und zeitlich unbegrenzt voll genutzt werden, was gerade bei mehreren Instanzen unter Umständen Sinn machen kann, da man so eine gewisse Last-Aufteilung vornehmen kann.

Sollte nun ein Knoten im Cluster ausfallen, so kann der zweite Knoten vereinfacht gesagt nicht mehr der anderen Seite kommunizieren und versucht schnellstmöglich die ausgefallenen Services auf seine Seite zu holen und dort zu starten.

Ein hybrides Szenario ist hierbei leider nicht möglich, da es keine Möglichkeit der gesharten Ressourcen zwischen on-premise und Cloud gibt. Aber man kann alternativ auch ein Failover-Cluster in der Azure Cloud aufbauen. Hierzu benötigt man eine Proximity Placement Group, entsprechende Managed Disks mit aktiviertem “Shared Storage” Feature und die beschriebenen zwei virtuellen Maschinen, die eigentliche Installation und Betrieb ist im Grunde identisch.

Hochverfügbarkeit Azure SQLServer Failover Cluster - DBCC2021

Mehr zu Hochverfügbarkeiten des SQL Servers kommt demnächst in einem zweiten Beitrag.