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

[TPok 11]

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

[NilsK 2.934]

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

[Dunkelmann 96]

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

[Cybquest 36]

Wir gehen damit in etwa so um:

- Wenn machbar, dann auf den zentralen SQL-Server (SQL-Cluster, mehrere Instanzen)

- Wenn SW aktuelle SQL-Version nicht unterstützt -> Erst mal Hersteller intensiv anfragen ;-) sonst Express

[Nobbyaushb 1.471]

Moin, bei uns eine Mischung aus #3 und #4

 

;)

[monstermania 53]

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

[Doso 77]

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.

[OliverHu 19]

Der Nachteil eines "großen" SQL-Servers ist weiterhin, je Mehr Applikationen dort ihre Datenbanken hosten, umso größer ist Aufwand wenn man die Kiste mal durchbooten muss (zB durch Updates)...

[DocData 85]

Deswegen realisiert man sowas auch als Cluster.

[OliverHu 19]

Wobei sich nicht alle KMUs einen SQL-Cluster leisten ;)

[DocData 85]

Das ist schon klar, aber ohne Cluster macht so eine zentrale Instanz wenig Sinn. Vor allem wenn man bedenkt, wie sich Ausfallwahrscheinlichkeiten berechnen. ;)

[MrCocktail 192]

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 :-)

[PadawanDeluXe 75]

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.