8
SQL Server - mehrere VMs oder Instanzen?
Hallochen allerseits!
Seit Microsoft den SQL Server auch für Linux bereitstellt, erweitern sich die Möglichkeiten für die Installation des SQL Servers, weil die Lizenzkosten für das Server-OS damit an Bedeutung verloren haben (Ausnahme: Features, die es nur unter Windows-Installationen gibt). Zudem verbraucht eine VM mit beispielsweise einem Ubuntu Server (ohne DB) relativ wenig Plattenplatz (<< 10GB).
Sollen mehrere eigenständige Datenbanken gehostet werden, stellt sich die Frage: pro Datenbank eine VM oder mehrere Instanzen (Docker) auf einer VM.
Was sind die grundsätzlichen Vor- und Nachteilen zwischen diesen beiden Varianten für den Betrieb von SQL Server und die Performance? Also welche Erfahrungswerte aus der Praxis gibt es, die sinnvollerweise in die Planung einbezogen werden sollten?
Klar ist, dass bei einer Aufteilung auf mehrere VM's etwaige Wartungsarbeiten oder ein Reboot die jeweils anderen VM's nicht erfasst. Hingegen müssen aber mehrere VM's gewartet werden, was den Aufwand erhöhen kann.
Vorab schon vielen Dank für Eure Antworten.
Seit Microsoft den SQL Server auch für Linux bereitstellt, erweitern sich die Möglichkeiten für die Installation des SQL Servers, weil die Lizenzkosten für das Server-OS damit an Bedeutung verloren haben (Ausnahme: Features, die es nur unter Windows-Installationen gibt). Zudem verbraucht eine VM mit beispielsweise einem Ubuntu Server (ohne DB) relativ wenig Plattenplatz (<< 10GB).
Sollen mehrere eigenständige Datenbanken gehostet werden, stellt sich die Frage: pro Datenbank eine VM oder mehrere Instanzen (Docker) auf einer VM.
Was sind die grundsätzlichen Vor- und Nachteilen zwischen diesen beiden Varianten für den Betrieb von SQL Server und die Performance? Also welche Erfahrungswerte aus der Praxis gibt es, die sinnvollerweise in die Planung einbezogen werden sollten?
Klar ist, dass bei einer Aufteilung auf mehrere VM's etwaige Wartungsarbeiten oder ein Reboot die jeweils anderen VM's nicht erfasst. Hingegen müssen aber mehrere VM's gewartet werden, was den Aufwand erhöhen kann.
Vorab schon vielen Dank für Eure Antworten.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 361267
Url: https://administrator.de/contentid/361267
Printed on: April 20, 2024 at 04:04 o'clock
8 Comments
Latest comment
Moin,
der einzige Vorteil, der mir einfallen würde, sind die dedizierten Ressourcen der VM's. Nachteilig sehe ich nichtmal die Verwaltung der VM's sondern die Verwaltung mehrer SQL-Server. Allein das Updaten mehrer Server würde ich mir ersparen.
Gruß, V
Moin,
das kommt auf auf viele Faktoren an und kann pausschal nur schwer entschieden werden.
Hast Du viele kleine Datenbanken kannst Du das auf einem einzigen Server (freie Version) gut einbinden.
Hast Du viele, große Datenbanken mit vielen Zugriffen und vielen "Bewegungen" kann es sinnvoll sein, die DBs auf mehrere Server zu verteilen oder eben auch hier nur einen, dafür aber sehr großen und performanten Server, zu nutzen.
Gruss
das kommt auf auf viele Faktoren an und kann pausschal nur schwer entschieden werden.
Hast Du viele kleine Datenbanken kannst Du das auf einem einzigen Server (freie Version) gut einbinden.
Hast Du viele, große Datenbanken mit vielen Zugriffen und vielen "Bewegungen" kann es sinnvoll sein, die DBs auf mehrere Server zu verteilen oder eben auch hier nur einen, dafür aber sehr großen und performanten Server, zu nutzen.
Gruss
@Voiper / @sabines: Das sind auch genau die Gedanken, die mir bisher eingefallen sind.
Hintergrund dessen ist, dass die Datenbanken (Version 2014) bisher auf einem einzigen Win-Server (2008R2) in eigenen Instanzen gehostet werden. Die Anzahl der gleichzeitigen Zugriffe ist eher unbedeutend. Aber es gibt zwei Datenbanken, die automatisiert laufend mit Daten gefüllt werden und die dabei größere / wachsende Tabellen haben. Ferner ist eine ASP.NET-Anwendung vorhanden, bei der vergleichsweise selten neue Daten erfasst werden, dafür aber die Datenabfrage sehr schnell sein soll, um eine angenehme Benutzererfahrung zu haben [hängt natürlich ganz entscheidend auch von Datenbankdesign ab, das ständig überarbeitet/optimiert wird]. Es gibt auch noch ein, zwei ... künftige Projekte, bei denen automatisiert Daten ausgewertet und strukturiert erfasst werden sollen - mit durchaus größeren Datenmengen.
Um hier etwaige Flaschenhälse durch das Hosten auf nur einem Server zu vermeiden / zu beseitigen, war eine Überlegung, dass SQL Server die Ressourcen der VM immer nur bechränkt nutzt. Bei der Einrichtung von mehreren Instanzen vervielfacht sich der Ressourcenbedarf entsprechend und es können ausbremsende Konkurrenzen auftreten. Hingegen könnte die Verwendung mehrerer VM's per se zu einer besseren Ressourcenverteilung bei parallelen Aktivitäten der Datenbanken führen. Allerdings bringt jede VM auch einen gewissen zusätzlichen Overhead an Leistungsbedarf mit sich.
Mithin also: Wie erfasse ich am besten die Leistungsdaten der einzelnen Instanzen am besten, um über einen gewissen Zeitraum solche Werte wie Min, Max, Avg ... bezüglich RAM, Prozessoren, Warteschlangen etc. erfassen und dann detailliert auswerten zu können?
Hintergrund dessen ist, dass die Datenbanken (Version 2014) bisher auf einem einzigen Win-Server (2008R2) in eigenen Instanzen gehostet werden. Die Anzahl der gleichzeitigen Zugriffe ist eher unbedeutend. Aber es gibt zwei Datenbanken, die automatisiert laufend mit Daten gefüllt werden und die dabei größere / wachsende Tabellen haben. Ferner ist eine ASP.NET-Anwendung vorhanden, bei der vergleichsweise selten neue Daten erfasst werden, dafür aber die Datenabfrage sehr schnell sein soll, um eine angenehme Benutzererfahrung zu haben [hängt natürlich ganz entscheidend auch von Datenbankdesign ab, das ständig überarbeitet/optimiert wird]. Es gibt auch noch ein, zwei ... künftige Projekte, bei denen automatisiert Daten ausgewertet und strukturiert erfasst werden sollen - mit durchaus größeren Datenmengen.
Um hier etwaige Flaschenhälse durch das Hosten auf nur einem Server zu vermeiden / zu beseitigen, war eine Überlegung, dass SQL Server die Ressourcen der VM immer nur bechränkt nutzt. Bei der Einrichtung von mehreren Instanzen vervielfacht sich der Ressourcenbedarf entsprechend und es können ausbremsende Konkurrenzen auftreten. Hingegen könnte die Verwendung mehrerer VM's per se zu einer besseren Ressourcenverteilung bei parallelen Aktivitäten der Datenbanken führen. Allerdings bringt jede VM auch einen gewissen zusätzlichen Overhead an Leistungsbedarf mit sich.
Mithin also: Wie erfasse ich am besten die Leistungsdaten der einzelnen Instanzen am besten, um über einen gewissen Zeitraum solche Werte wie Min, Max, Avg ... bezüglich RAM, Prozessoren, Warteschlangen etc. erfassen und dann detailliert auswerten zu können?
Zitat von @HansDampf06:
Mithin also: Wie erfasse ich am besten die Leistungsdaten der einzelnen Instanzen am besten, um über einen gewissen Zeitraum solche Werte wie Min, Max, Avg ... bezüglich RAM, Prozessoren, Warteschlangen etc. erfassen und dann detailliert auswerten zu können?
Mithin also: Wie erfasse ich am besten die Leistungsdaten der einzelnen Instanzen am besten, um über einen gewissen Zeitraum solche Werte wie Min, Max, Avg ... bezüglich RAM, Prozessoren, Warteschlangen etc. erfassen und dann detailliert auswerten zu können?
Hier würde ich eine Performance Messung machen (lassen), google das mal, das ist ein seeeehr weites Feld.
Gerade beim SQL Server gibt es gefühlte 1000 Optionen, bis hin zu Kleinigkeiten wie das Ansprechen des Servers über die IP
Moin,
Des Weiteren macht die Trennung auf verschiedene VMs sinn, wenn die jeweilige Anwendung von verschiedenen Teams betreut werden. Da sind Instanzen meiner Meinung nach der falsche Weg.
Gruß,
Dani
der einzige Vorteil, der mir einfallen würde, sind die dedizierten Ressourcen der VM's.
nicht nur... es geht um um das Dilemma bezüglich der Service bzw. Cumulative Packs. Der eine Hersteller möchte immer den aktuellen SP/CU. Der nächstes nicht, weil die Anwendung noch nicht kompatibel ist. Das Spiel macht man anfangs gerne mit, weil man Ressourcen schont. Aber irgendwann ist man es leid.Des Weiteren macht die Trennung auf verschiedene VMs sinn, wenn die jeweilige Anwendung von verschiedenen Teams betreut werden. Da sind Instanzen meiner Meinung nach der falsche Weg.
Gruß,
Dani
Guter Einwand ;) Gestern gerade beim Kunden mit eigener Software erfahren dürfen...("jaaaa, das ist auf jedenfall mit Version 2016 kompatibel....")
Gruß, V
Gruß, V
Hallochen!
In den letzten Tagen habe ich einen Ubuntu Server 16.04 mit SQL Server Express aufgesetzt (AD-Member) und die eine automatisch zu befüllende Datenbank transferiert. Abgesehen von der Änderung der integrierten Windows-Anmeldung auf die SQL-Serveranmeldung bestand kein weiterer Anpassungsbedarf. Die Datenbank läuft und ich habe den Eindruck, dass sie sogar ein ganzes Stück schneller ist: Konfiguration 1 vCPU und 2048 MB RAM = die Mindestanforderungen. Der bisherige Server erscheint auch performanter, seitdem er diese Aufgabe des SQL Servers los ist - geblieben ist bei ihm die steuernde Web-Anwendung.
Damit bestätigt sich eine theoretischen Überlegung beim Einsatz von VM's. Die einzige Instanz muss sich die VM nicht mit anderen Instanz teilen. Hierdurch gibt es keinerlei Rangeleien um die Ressourcen dieser VM und die verbundenen Fragen und Probleme der Verteilung / Zuordnung dieser Ressourcen. Ob seitens der VM mehr RAM oder eine weitere vCPU benötigt wird, kann leicht überwacht werden (z.B. Swap-Memory-Nutzung). Im Verhältnis zu anderen VM's bietet Hyper-V in den Prozessoreinstellungen probate Mittel ... Jedenfalls erscheint mir diese Feinsteuerung einfacher und durchsichtiger als die ungeahnten Phänomene zweier/mehrerer konkurrierender SQL-Instanzen auf einer VM.
Das kommt auch meiner grundsätzlichen Einstellung, eher auf "Spezialisten" als auf "Generalisten" zu setzen, viel näher. Lediglich dann, wenn auf Windows Server als Betriebssystem gesetzt werden muss, spielen die entsprechenden Lizensierungskosten eine relevante Rolle.
@Dani: Die von Dir benannten Aspekt muss ich Gott sei Dank derzeit nicht berücksichtigen.
In den letzten Tagen habe ich einen Ubuntu Server 16.04 mit SQL Server Express aufgesetzt (AD-Member) und die eine automatisch zu befüllende Datenbank transferiert. Abgesehen von der Änderung der integrierten Windows-Anmeldung auf die SQL-Serveranmeldung bestand kein weiterer Anpassungsbedarf. Die Datenbank läuft und ich habe den Eindruck, dass sie sogar ein ganzes Stück schneller ist: Konfiguration 1 vCPU und 2048 MB RAM = die Mindestanforderungen. Der bisherige Server erscheint auch performanter, seitdem er diese Aufgabe des SQL Servers los ist - geblieben ist bei ihm die steuernde Web-Anwendung.
Damit bestätigt sich eine theoretischen Überlegung beim Einsatz von VM's. Die einzige Instanz muss sich die VM nicht mit anderen Instanz teilen. Hierdurch gibt es keinerlei Rangeleien um die Ressourcen dieser VM und die verbundenen Fragen und Probleme der Verteilung / Zuordnung dieser Ressourcen. Ob seitens der VM mehr RAM oder eine weitere vCPU benötigt wird, kann leicht überwacht werden (z.B. Swap-Memory-Nutzung). Im Verhältnis zu anderen VM's bietet Hyper-V in den Prozessoreinstellungen probate Mittel ... Jedenfalls erscheint mir diese Feinsteuerung einfacher und durchsichtiger als die ungeahnten Phänomene zweier/mehrerer konkurrierender SQL-Instanzen auf einer VM.
Das kommt auch meiner grundsätzlichen Einstellung, eher auf "Spezialisten" als auf "Generalisten" zu setzen, viel näher. Lediglich dann, wenn auf Windows Server als Betriebssystem gesetzt werden muss, spielen die entsprechenden Lizensierungskosten eine relevante Rolle.
@Dani: Die von Dir benannten Aspekt muss ich Gott sei Dank derzeit nicht berücksichtigen.
Moin,
vielen Dank für den Feedback. Wenn alles geklärt ist, setz die Frage bittte auf gelöst.
Gruß,
Dani
vielen Dank für den Feedback. Wenn alles geklärt ist, setz die Frage bittte auf gelöst.
Gruß,
Dani
