6
Zentralen SQL Server aufsetzt? Weg von Insel Lösungen?!
Hallo zusammen,
wie das in vielen Unternehmen so ist wächst die IT Infrastruktur. Wir haben unterschiedliche Anwendungen mit unterschiedlichen SQL Server Version installiert. (von Express bis zur Enterprise)
Wir verfügen über eine VM Infrastruktur. Ich denke da an einen zentralen SQL Server kenne jedoch nicht die Vor- und Nachteile.
- Macht es Sinn einen zentralen SQL Server in der VM Landschaft aufzusetzen?
- Wird die Performance nicht beeinträchtigt? Denn dann greifen alle VM Server auf eine Datenbank übers Netzwerk!
- Gibt es sonst Nachteile?
Wie macht Ihr dass in Eurem Unternehmen?
Danke schon mal vorab für Eure Unterstützung.
wie das in vielen Unternehmen so ist wächst die IT Infrastruktur. Wir haben unterschiedliche Anwendungen mit unterschiedlichen SQL Server Version installiert. (von Express bis zur Enterprise)
Wir verfügen über eine VM Infrastruktur. Ich denke da an einen zentralen SQL Server kenne jedoch nicht die Vor- und Nachteile.
- Macht es Sinn einen zentralen SQL Server in der VM Landschaft aufzusetzen?
- Wird die Performance nicht beeinträchtigt? Denn dann greifen alle VM Server auf eine Datenbank übers Netzwerk!
- Gibt es sonst Nachteile?
Wie macht Ihr dass in Eurem Unternehmen?
Danke schon mal vorab für Eure Unterstützung.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 195255
Url: https://administrator.de/contentid/195255
Ausgedruckt am: 22.11.2024 um 17:11 Uhr
6 Kommentare
Neuester Kommentar
Hallo,
naja das mehrere Clients auf eine Datenbank zugreifen ist ja nichts ungewöhnliches.
Bei dir eher auf einen DB Server aber verschiedene Datenbanken.
Grundsätzlich macht das aus meiner Sicht schon sinn. Nur kommt es auch auf die Anwendungen an ob Sie für die von dir eingesetzter Version freigegeben sind.
Bzw. wenn irgendwas nicht funktioniert reden sich Softwarehersteller gerne drauf raus das ein eigener SQL die Probleme nicht hätte.
naja das mehrere Clients auf eine Datenbank zugreifen ist ja nichts ungewöhnliches.
Bei dir eher auf einen DB Server aber verschiedene Datenbanken.
Grundsätzlich macht das aus meiner Sicht schon sinn. Nur kommt es auch auf die Anwendungen an ob Sie für die von dir eingesetzter Version freigegeben sind.
Bzw. wenn irgendwas nicht funktioniert reden sich Softwarehersteller gerne drauf raus das ein eigener SQL die Probleme nicht hätte.
Hallo auch,
um eine vernünftige Aussage treffen zu können fehlt ein ganzer Haufen von Infos.
U.a.:
- Vorhandene Hardware am zentralen und den jeweils externen Standorten
- Netzwerkstruktur (Domäne oder keine, jeweils ne eigene an jedem Standort, sollen diese Sachen dann auch zentralisiert werden, etc.pp)
- Internetanbindungen der einzelnen Standorte
Grundsätzlich ist eine zentralisierte Lösung (Also auch File, AD, etc.) in der Hauptstelle ein schönes Ding.
Mit Replikation kann man dann auch noch arbeiten...
Die Performancefrage hängt u.a. von den Internetleitungen ab.
Wie hoch ist denn das Budget?
Mit einberechnen müsst ihr auch: Wenn ihr alles ohne replikation und ohne Ausfallsicherung zentralisiert und die Internetleitung in der Zentrale fällt aus stehen eure Standorte ohne SQL- und sonstige Server da.
Was kostet also ggf. jeder Tag an dem die Standorte dann nicht arbeiten können?
Bitte aber ohne Gruß
um eine vernünftige Aussage treffen zu können fehlt ein ganzer Haufen von Infos.
U.a.:
- Vorhandene Hardware am zentralen und den jeweils externen Standorten
- Netzwerkstruktur (Domäne oder keine, jeweils ne eigene an jedem Standort, sollen diese Sachen dann auch zentralisiert werden, etc.pp)
- Internetanbindungen der einzelnen Standorte
Grundsätzlich ist eine zentralisierte Lösung (Also auch File, AD, etc.) in der Hauptstelle ein schönes Ding.
Mit Replikation kann man dann auch noch arbeiten...
Die Performancefrage hängt u.a. von den Internetleitungen ab.
Wie hoch ist denn das Budget?
Mit einberechnen müsst ihr auch: Wenn ihr alles ohne replikation und ohne Ausfallsicherung zentralisiert und die Internetleitung in der Zentrale fällt aus stehen eure Standorte ohne SQL- und sonstige Server da.
Was kostet also ggf. jeder Tag an dem die Standorte dann nicht arbeiten können?
Bitte aber ohne Gruß
Hallo zusammen
danke für Eure Hilfe..
- Wir setzen HP Sanmelody von DataCore inkl 8TB Storage ein
- Eine AD mit 2008 Servern ist vorhanden
- Um den zweiten Standort mache ich mir keine Sorgen, da die gesamte Serverinfrastruktur zentralisiert ist und Igle Clients zum Einsatz kommen.
Es wuchs halt aus der Historie, dass man immer wieder eine Applikation aufgesetzt hat mit einer „kleinen“ SQL DB.
Jetzt überlege ich einen zentralen SQL Server (VM-Ware) aufzusetzen wo alle SQL Datenbanken liegen.
Die Frage, die ich mir jetzt stelle, ob technisch irgendwas dagegen spricht und wie Ihr das in Eurem Unternehmen gelöst habt.
Die Frage zu Performance konnte ich mir gerade selbst beantworten denn wenn ich die DB Zentralisiere, müssten auch die Files (zu der jeweiligen DB) zentraleren die im Moment auf unterschiedlichen Servern liegen.
danke für Eure Hilfe..
Zitat von @Philtaer:
- Vorhandene Hardware am zentralen und den jeweils externen Standorten
- Netzwerkstruktur (Domäne oder keine, jeweils ne eigene an jedem Standort, sollen diese Sachen dann auch zentralisiert
werden, etc.pp)
- Internetanbindungen der einzelnen Standorte
- Vorhandene Hardware am zentralen und den jeweils externen Standorten
- Netzwerkstruktur (Domäne oder keine, jeweils ne eigene an jedem Standort, sollen diese Sachen dann auch zentralisiert
werden, etc.pp)
- Internetanbindungen der einzelnen Standorte
- Wir setzen HP Sanmelody von DataCore inkl 8TB Storage ein
- Eine AD mit 2008 Servern ist vorhanden
- Um den zweiten Standort mache ich mir keine Sorgen, da die gesamte Serverinfrastruktur zentralisiert ist und Igle Clients zum Einsatz kommen.
Es wuchs halt aus der Historie, dass man immer wieder eine Applikation aufgesetzt hat mit einer „kleinen“ SQL DB.
Jetzt überlege ich einen zentralen SQL Server (VM-Ware) aufzusetzen wo alle SQL Datenbanken liegen.
Die Frage, die ich mir jetzt stelle, ob technisch irgendwas dagegen spricht und wie Ihr das in Eurem Unternehmen gelöst habt.
Die Frage zu Performance konnte ich mir gerade selbst beantworten denn wenn ich die DB Zentralisiere, müssten auch die Files (zu der jeweiligen DB) zentraleren die im Moment auf unterschiedlichen Servern liegen.
Obs geht musst du im hinblick auf die eingesetzten aplikationen klären, da können wir dir schlecht was zu sagen.
Hallo,
grundsätzlich geht das. Wir haben hier auch einige Instanzen und verschiedene Editionen / Versionen auf einem Server. Allerdings entwickeln und supporten wir darauf nur Kundensysteme und benötigen keine Ausfallsicherheit / Wartungsfenster etc.
Mögliche Probleme:
- Wartung (neustart)
- single Point of failure insb. bei Updates, Softwareproblemen, unerwarteter Auslastung, Deadlocks
- sehr hoher i/o, Auslastungsspitzen
- individuelle Einstellungen (Rekrusive Trigger, individuelle instanzierte Parameter, was die zentrale Nutzung bestimmter Editionen verhindert)
- Chaos bei Replikationszenarien
- Zeitfenster für Wartungspläne (Überlagerung)
- Auslastungsspitzen bei Recovery von Datenbanken.
- Zugrif und Rechtekonzept
- Eindeutige Nomenklatur in allen Fällen (DB auf Instanzname statt wie bisher "die einzige DB unter der ip xxx")
Unter Berücksichtigung oben genannter Punkte kann ein inkrementelles zentralisieren erfolgen. D.h. nach und nach Datenbanken übernehmen und zentralisieren - dabei Pufferzeiten einbauen und evaluieren. Eine Konsolidierung der Instanzen ist nicht immer sinnvoll.
Gruss
Grinskeks
grundsätzlich geht das. Wir haben hier auch einige Instanzen und verschiedene Editionen / Versionen auf einem Server. Allerdings entwickeln und supporten wir darauf nur Kundensysteme und benötigen keine Ausfallsicherheit / Wartungsfenster etc.
Mögliche Probleme:
- Wartung (neustart)
- single Point of failure insb. bei Updates, Softwareproblemen, unerwarteter Auslastung, Deadlocks
- sehr hoher i/o, Auslastungsspitzen
- individuelle Einstellungen (Rekrusive Trigger, individuelle instanzierte Parameter, was die zentrale Nutzung bestimmter Editionen verhindert)
- Chaos bei Replikationszenarien
- Zeitfenster für Wartungspläne (Überlagerung)
- Auslastungsspitzen bei Recovery von Datenbanken.
- Zugrif und Rechtekonzept
- Eindeutige Nomenklatur in allen Fällen (DB auf Instanzname statt wie bisher "die einzige DB unter der ip xxx")
Unter Berücksichtigung oben genannter Punkte kann ein inkrementelles zentralisieren erfolgen. D.h. nach und nach Datenbanken übernehmen und zentralisieren - dabei Pufferzeiten einbauen und evaluieren. Eine Konsolidierung der Instanzen ist nicht immer sinnvoll.
Gruss
Grinskeks
Zitat von @Philtaer:
Obs geht musst du im hinblick auf die eingesetzten aplikationen klären, da können wir dir schlecht was zu sagen.
Richtig, es fängt damit an das z.B. der Hersteller A sagt "SP2 für SQL ist freigeben und sollte installiert werden". Der Hersteller B sagt "bitte kein SP2 installieren, ist nicht freigeben. So was machste nun?!Obs geht musst du im hinblick auf die eingesetzten aplikationen klären, da können wir dir schlecht was zu sagen.
Was ich sagen möchte, im Zeitalter wo hinter fast allem eine DB hängt wird dein Vorhaben auf Dauer ziemliche zeitaufwendig. Vorallem darfst du nie den Überblick verlieren!
Grüße,
Dani
