Jump to content
Sign in to follow this  
TPok

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

Recommended Posts

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte überlege Dir, ob es nicht sinnvoller ist ein neues Thema zu erstellen.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

Werbepartner:



×
×
  • Create New...