Jump to content

Best Practice: Einen zentralen SQL Server oder viele Kleine...


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo,

 

ich wollte mich einmal nach Meinungen umhören, ob es eine Best Practice gibt. Mir ist bewusst, dass die treffendste Antwort hier "Kommt auf eure Anforderungen an" ist. Ich würde mich aber trotzdem zumindest gerne orientieren, wie das andere umsetzen.

 

Wir betreiben einen "großen" SQL Server für zentrale Datenhaltung von ERP und anderen unternehmensweiten System. Jetzt gibt es serverseitig aber noch zahlreiche Dienste, die eine eigene Datenhaltung in einer Datenbank benötigen. Das beginnt beim Clientmanagement, über verschiedene Managementdienste (Virenschutz, Thin Clients, etc.) bis zur Datensicherungslösung. Jeder dieser Dienste läuft natürlich schön sauber in seiner eigenen VM und jeder bringt in der Regel seinen eigenen SQL Server Express mit. Es wird aber auch unterstützt, die Datenhaltung auf einem anderen (zentralen) SQL Server durchzuführen.

 

Wie geht ihr damit um? Installiere ich für jede Lösung einen eigenen SQL Express gewinne ich Unabhängigkeit, da die Lösung in Ihrer VM alleine lauffähig ist. Dafür habe ich zig SQL Server laufen, die Ressourcen fressen und einzeln gemanaged und gepatcht werden wollen.

 

Lege ich alles zentral, brauche ich dort natürlich mehr Ressourcen und generiere mir einen Single Point of Failure (und ggf. auch noch ein Sicherheitsrisiko), da alles von einer SQL Instanz abhängt. Dafür ist das Management etwas einfacher.

 

Was tun?

 

Danke und Gruß

Stephan

Link zu diesem Kommentar

Moin,

 

naja ... kommt auf eure Anforderungen an. :D

 

Wie du schon richtig sagst, musst du zwischen verschiedenen Einschränkungen abwägen. Weitere Aspekte wären z.B.:

  • Support-Einschränkungen durch den ERP-Hersteller
  • zentrales Backup

Da der Zoo von vielen kleinen SQL-Expressen in der Praxis dazu führt, dass diese Instanzen weder ordentlich abgesichert noch gepatcht noch gesichert werden, würde ich zusehen, dass ich möglichst wenige davon habe.

 

Gruß, Nils

Link zu diesem Kommentar

Moin,

 

es kommt nicht nur auf die Anforderungen an. Das Verhalten der Anwendungen, Lizenzierung, Delegierung der Administration, Wartungszugänge für Externe usw. sollten auch betrachtet werden.

Bei uns werden mehrere Varianten betrieben. Einige Anwendungen nutzen den selben SQL Cluster, andere Anwendungen haben ihren eigenen SQL Server/Cluster wiederum andere nutzen einen lokalen SQL Express

Link zu diesem Kommentar

Moin,

kann mich da nur Nils anschließen. :D  Kommt ganz darauf an!

Manche Hersteller Supporten nur, wenn Ihre Software exklusiv auf einem SQL läuft. Dabei ist es unerheblich, ob es sich um SQL Express oder eine Lizenzversion handelt!

Bei anderer Software ergibt sich der Betrieb eines lokalen SQL aus der Anforderung heraus. Für das Backup nutzen wir z.B. einen Standalone-Server. Läuft logischerweise auch ein SQL (Express) drauf, damit wir im DR-Fall auch ein voll funktionsfähigen Backupserver haben der unabhängig von der gesamten Infrastruktur funktioniert.

Hat Alles Seine individuellen Vor-und Nachteile.

 

Gruß

Dirk

Link zu diesem Kommentar

Vor ein paar Jahren hatten wir noch überall kleine (SQL Express) Sachen. Mittlerweile den Großteil zentral auf einem SQL Server Cluster. Die vielen kleinen Installationen wurden halt nie wirklich gepatcht und gepflegt und das Backup der Dinger war echt nervig. Dafür hat man halt eine größere Abhängigkeit von dem einen 'großen' SQL Server, außerdem können die Applikations-Admins nicht mehr machen was sie wollen ohne über den SQL Admin zu gehen. Sehe ich als Vorteil, kann aber zu hitzigen Diskussionen führen.

Link zu diesem Kommentar
  • 2 Wochen später...

Und auch hier, es kommt drauf an ...

 

Wir haben mehrere Cluster / Sammler mit verschiedenen Verfügbarkeits SLA, aber auch noch ein paar SQL Express.

 

Ich nutze den SQL Express gerne in den KON Umgebungen als lokale Instanz, VM runterfahren, Snap ziehen und dann die Updates usw testen, Einstellungen zerspielen und zum definierten Stand zurück :-)

Link zu diesem Kommentar

Hi,

wie aus deinem Eröffnungspost ersichtlich betreibt ihr ja schon eine zentrale SQL Instanz. Sofern ihr diese also geclustert habt ist die Wartung unkritisch. Im nächsten Moment ist es so, dass aus verschiedensten Gründen ich einen Hersteller niemals direkt an meinem produktiven SQL Server lassen würde. Egal wie viele Fehler er gerade produziert. Datenbanken können gesichert werden und nach einem getesteten Fix des Herstellers produktiv gefixt werden. Wenn der Hersteller Wert auf einen exklusiven SQL Server legt so kann es unter Umständen sein, dass dieser lediglich eine exklusive Instanz erwartet. Für alles andere das nunmal einen SQL Express vorraussetzt wirst du natürlich nie die Vorzüge deines Clusters ausspielen können, da es einfach nicht supportet ist. Am Ende des Tages sehe ich hier eigentlich nur eine Kostenentscheidung, da der Aufwand eine aktuelle Datensicherung einer SQL DB zu machen oder einen Snapshot einer Maschine zu erstellen nahezu dergleiche ist.

 

Meiner Meinung nach bin ich auch mit einem zentralen SQL Cluster unabhängig. Ja ok. Es sind zwei Maschinen die dann nicht ausfallen dürfen. Du musst aber auch bedenken, dass bei hoch kritischen Daten der Clusterpartner nicht direkt am selben Standort steht usw. ;-) 

 

Um mich meinem Vorredner anzuschließen: zum Spielen und testen ist SQL Express super und ich will ihn nicht missen, aber für die Produktion bitte immer einen SQL Cluster einrichten und dort alle wichtigen Daten ablegen und sichern. 

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...