High availability mit Standard-Edition

P

Phoniex

Neuer Benutzer
Beiträge
2
Hi.

Wir sind dabei eine Business-Web-Anwendung von ASP.NET Webforms auf ASP.NET Core umzustellen. Damals vor 13 Jahren haben wir als einfachse und günstige Lösung Access-Datenbanken verwendet - für damals absolut ausreichend für die paar wenigen Kunden ;). Zu erwähnen wäre noch dass hier jeder Kunden seine eigene eigenständige Access-Datenbank hat.

Grundsätzlich sind für das neue System Firewall/Loadbalancer/physische Server/IIS redundant ausgelegt, weshalb natürlich der Wunsch nach einer Redundanz hinsichtlich MS-SQL auch vorhanden wäre. Aus Kostengründen können wir aber nur die Standard Edition nutzen und nicht die Enterprise.

Ich hab mir mal für den Start das Buch "SQL Server 2019 für Administratoren" (Rheinwerk Verlag) geholt. Mir ist natürlich bewusst, dass es mit dem Lesen eines Buches nicht so einfach getan ist ;). Allerdings wirft das Buch nun schon einige Fragen hinsichtlich der High Availability auf...

  • Es gibt keine SAN mit gemeinsamen Specher, jeder Server hat seinen eigenen lokalen SSD's. Damit fällt die Option für Failover-Cluster schonmal weg.

  • Datenbankspiegelgung > aufwendig wenn jede einzelne DB gespiegelt werden muss, außerdem wird es vom MS nicht mehr empfohlen

  • Always On > Standard Edition nur eine "Basic availability groups" verfügbar > pro Datenbank wäre eine eigene Group notwendig (wenn man überhaupt bliebig viele machen könnten). Also leider auch nicht praktikabel.

  • Im Buch wird dann noch eine Variante aus NLB und Replikation beschrieben. Allerdings sind Funktionen wie die Transaktionsreplikation (Updatable Subscriptions) und Peer-to-Peer Replikation dann auch wieder nur in der Enterprise Version enthalten. Im Buch wird noch die Bidirektionale Replikation "beschrieben" > 4 Zeilen und das wars, im Internet findet sich auch nicht wirklich brauchbares wie das nun genau funktioniert.
Ich habe auch schon mit bekannten Diskutiert die sich auf dem Gebiet auskennen, aber dort kommt immer Enterprise mit AlwaysOn zum Einsatz und die haben keine Erfahrung was Alternativen angeht.

Letzte Möglichkeit wäre natürlich alle Kundendaten in eine gemeinsame Datenbank zu werfen (Trennung mittels Schema usw.) und dann AlwaysOn zu nutzen - die Gründe warum wir das nicht wollen, würde hier alles sprengen.

Die Frage ist halt natürlich auch wie sinnvoll eine Hochverfügbarkeit als blutiger Anfänger überhaupt ist...

Jetzt stellt sich mir die Frage ob ohne Enterprise Edition überhaupt eine Hochverfügbarkeit (vernünftig) möglich ist, oder ob es noch eine weitere Lösung gäbe?
 
Werbung:
Phoniex schrieb:
Es gibt keine SAN mit gemeinsamen Specher, jeder Server hat seinen eigenen lokalen SSD's. Damit fällt die Option für Failover-Cluster schonmal weg.
Zum Vergrößern anklicken....

Du bist ja scheinbar auf die M$SQL-Schiene festgenagelt, aber z.B. im PostgreSQL-Umfeld erfolgt HA über shared-nothing. Normale Streaming Replication (1 Primary, N Replicas) kann sync oder async
erfolgen, bei Bedarf auch über große Entfernungen (dann bitte async). Unser BDR (BiDirectional Replication) kann auch in beiden Modes betrieben werden. PostgreSQL ist OpenSource (weil Du die Kosten erwähntest), BDR allerdings NICHT.
 
Phoniex schrieb:
  • Datenbankspiegelgung > aufwendig wenn jede einzelne DB gespiegelt werden muss, außerdem wird es vom MS nicht mehr empfohlen

  • Always On > Standard Edition nur eine "Basic availability groups" verfügbar > pro Datenbank wäre eine eigene Group notwendig (wenn man überhaupt bliebig viele machen könnten). Also leider auch nicht praktikabel.
Zum Vergrößern anklicken....

Was heißt da aufwändig? Mit entsprechenden Scripten / Automatismen ist es egal, ob du eine DB oder 1000 DB konfigurierst.
Ich würde mir die Always On Basic Availability Groups anschauen. Eine Replikation hat andere Ziele.
 
akretschmer schrieb:
Du bist ja scheinbar auf die M$SQL-Schiene festgenagelt
Zum Vergrößern anklicken....

Leider wurden die MS-SQL Lizenzen schon gekauft

Dukel schrieb:
Was heißt da aufwändig? Mit entsprechenden Scripten / Automatismen ist es egal, ob du eine DB oder 1000 DB konfigurierst.
Ich würde mir die Always On Basic Availability Groups anschauen. Eine Replikation hat andere Ziele.
Zum Vergrößern anklicken....

Möglich wäre es mittels Skripts ja, konnte ich soweit auch ein paar Beispiele finden. Die Frage ist nur wie hoch die Belastung im Netzwerk wird und wie sich hier dann CPU/RAM-Last verhalten...

Eine weitere Variante wäre noch Windows Datacenter zu verwenden und es mittels S2D und Always On Failover Cluster zu realisieren - sollte zumindest theoretisch auch so funktionieren.
 
Wenn Lizenzkosten ein Problem sind ist eine Lizenzkosten freie Datenbank aber nicht abwegig. Jetzt den Aufwand betreiben um mit einer Standard Version Features zu etablieren die eigentlich nicht vorgesehen sind mag zwar möglich sein, ist aber keine gute Zukunftsperspektive. Man könnte auch ein bischen Aufwand in Kauf nehmen und sich ein Wechsel zu Postgre überlegen. Eine bereits gekaufte Lizenz ist dann nicht das Problem, die kann man vielleicht woanders verwenden. Die großen Kosten stecken im Aufwand für die neue Lösung, Programmierung und darüber hinaus.
 
Also bei Hochverfügbarkeit und MS Produkten macht es bei mir irgendwie nicht Klick.
Ich verstehe auch nicht die große Bereitschaft, Marketingentscheidungen hinzunehmen und dann ständig seine Produkte umzubauen. (Man schaue sich beispielhaft die Geschichte von ODBC und allen "Ersatzlösungen" (oder wie man das nennen soll) an.
Das soll jetzt nicht zynisch klingen und hilft nicht weiter, aber was ist der Kaufpreis der Lizenzen im Vergleich zum Entwicklungsaufwand? (Besonders für die Umsetzung von Anforderungen (HA), die nachimplementiert werden müssen?
Man nimmt ja als Datenbank auch keine Textdatei, weil die Textverarbeitung so günstig ist und baut dann Transaktionen, Concurrency usw. dran.
 
Werbung:
Zurück
Oben