Cluster mit 2 Nodes mit mehreren Instanzen

[jesada 0]

Guten Morgen zusammen,

 

wir würden einen SQL Cluster aufsetzen wollen mit zwei Knoten. Auf diesen Knoten würden wir dann die jeweiligen Instanzen für die Abteilungen betreiben wollen.

Macht es hier Sinn die Rollen immer auf die gleichen Clustervolumes zu betreiben oder sollte jede instanz ein eigenes Volume erhalten? 

 

Beispiel:
Instanz 01 auf CSV 1 DB, Backup,Log
Instanz 02 auf CSV 1 DB, Backup,Log

 

Oder die alternative:

Instanz 01 auf CSV 1 DB, Backup,Log

Instanz 02 auf CSV 2 DB, Backup,Log

 

Danke und schönen Tag euch 

 

Grüße Jesada

[Dukel 436]

Ich würde generell keine mehreren Instanzen von SQL aufsetzen sondern (wenn es keine wirklichen! Gründe gibt) alles in einer SQL Instanz aufsetzen.

[jesada 0]

Danke für deine Antwort, die Argumente dafür wie auch dagegen sind mir bekannt. Wir betreiben jedoch verschiedene Instanzen (Kritisch bis unkritisch) für mehrere Mandanten, diese betreibe ich ungern in einer Instanz. 

Das Memorymanagement ist dann halt immer händisch zu machen. 

[NilsK 2.785]

Moin,

 

was würde denn aus deiner Sicht für getrennte CSVs sprechen? Mir kommt schon die Idee exotisch vor.

 

Gruß, Nils

 

[jesada 0]

vor 1 Stunde schrieb NilsK:

Moin,

 

was würde denn aus deiner Sicht für getrennte CSVs sprechen? Mir kommt schon die Idee exotisch vor.

 

Gruß, Nils

 

Hallo Nils,

danke für deine Antwort. Wäre es denn Sinnvoll, je Funktion eine CSV anzulegen. Ergo eine 

CSV01 - Backup

CSV02 - Log

CSV03 - Database

 

Und beide Nodes mit mehreren SQL Instanzen so arbeiten zu lassen? Also mehrere SQL Instanzen legen jeweils Ihre SQL Daten auf die CSVs.

Macht sowas Sinn? 

[NilsK 2.785]

Moin,

 

die Frage ist, was du damit erreichen willst. Technisch betrachtet, kannst du das tun. Eine pauschale Empfehlung dafür kann man aber nicht aussprechen, weil so eine Aufteilung wohl nur in sehr speziellen Szenarien Vorteile brächte.

 

Am Ende sind CSVs normale LUNs aus dem Storage. Anders als diese können aber mehrere Server gleichzeitig darauf zugreifen, eben die Cluster-Nodes. Es muss dabei sicher gestellt sein, dass diese nicht dieselben Daten verwenden. Rein technisch könnte man also durchaus die Dateien so aufteilen, wie du es angibst, denn es greift ja jede Instanz nur auf ihre Dateien zu.

 

Bleibt aber die Frage, warum man das tun sollte. Interessant könnte das evtl. sein, wenn etwa das Log-CSV viel schneller im Zugriff wäre als das DB-CSV. Das dürfte allerdings bei den meisten Storage-Systemen gar nicht der Fall sein. Außerdem geht es dann evtl. nach hinten los, wenn mehrere Datenbanken ihre Logs auf demselben CSV haben und damit dann um die Zugriffe konkurrieren. 

 

Zudem ist das CSV die Failover-Einheit, aber da das eher die Verwaltung betrifft als die laufenden Zugriffe, ist das eher weniger relevant.

 

Es ist eine Frage, die im Gesamtdesign des Systems zu beantworten ist, aber keinesfalls pauschal.

 

Gruß, Nils

 

[cj_berlin 1.138]

Moin,

für die exklusive Nutzung eines CSV durch eine SQL-Instanz spricht in erster Linie die Möglichkeit, diese dann jeweils zusammen zu verschieben. Ich könnte jetzt auf einem falschen Dampfer sein, meine aber, Compute und Storage auf verschiedenen Knoten kann nur Hyper-V, nicht aber andere Cluster-Rollen.

Dafür, DB und Logs zu trennen, spricht heutzutage sehr selten etwas.

OK, supported wäre es zwar, ich würde es mir dennoch 2x überlegen.

[jesada 0]

Danke für die Antworten. Vom Systemdesign haben wir keinen Bedarf an so einem Konstrukt, es ging mir nur allgemein um die Möglichkeit der Umsetzung. Werde dann in der Umgebung wie MS das angibt ein CSV (DB,LOG,Backup) für eine Instanz einrichten. 

 

Besten Dank 

[NilsK 2.785]

Moin,

 

vor 44 Minuten schrieb cj_berlin:

Compute und Storage auf verschiedenen Knoten

 

das wäre hier gar nicht gegeben. Ein CSV ist ja eine LUN aus einem (separaten) Storage-System. Die Zuordnung zu einem Knoten dient nur der Koordination der Zugriffe durch verschiedene Systeme. Möglicherweise verwechselst du das grad mit S2D.

 

Gruß, Nils

 

[cj_berlin 1.138]

Nein, ich verwechsel das gerade mit SQL vor 2014. Dort konnte man CSV gar nicht verwenden, sondern nur "normale" Storage Volumes im Cluster, und die waren halt nicht Shared. 

 

Dennoch würde ich bei Datenbanken zusehen, dass der Host, der die Instanz ausführt, auch der Koordinator für den Storage dieser Datenbank ist. 

[t-sql 17]

vor 21 Stunden schrieb jesada:

Wir betreiben jedoch verschiedene Instanzen (Kritisch bis unkritisch) für mehrere Mandanten, diese betreibe ich ungern in einer Instanz. 

Wenn ihr das so macht, ist das erstmal ein Designfehler. Man sollte die kritischen in EINER Instanz bündeln, die unkritischen in einer anderen und diese selbstredend auf zwei verschiedenen Clustern betreiben. Wenn denn bei den unkritischen überhaupt ein Cluster notwendig ist. Eure Idee macht es einfach nur unnötig kompliziert, Wartung ist viel zu aufwendig, Resourcenverteilung  usw. Es spricht eigentlich nichts für eure Idee. Es sei denn ihr habt kein Geld um es gscheit zu machen. Für Mandanten braucht man auch keinerlei eigene Instanzen, es sei denn es muss systemweit eine Einstellung gemacht werden. Die Trennung der Mandanten erfolgt logischerweise über das Berechtigungsmanagement des SQL Servers. Aber seis drum. Manche Leute wollens halt möglichst kompliziert haben.