1
MS-SQL (auf realer Hardware vs. ESX mit SAN)
ist eine Meinungs(um)frage, die mir vielleicht neue Gesichtspunkte zur Bewertung bringen soll
Hallochen,
nach der sogenannten reinen Lehre sollte ein SQL sauber strukturiert sein und für alle Betriebsvorfälle ein eigenes Laufwerk haben
d.h.
Laufwerk 1 - Betriebssystem,
Laufwerk 2 - Swap/Auslagerungsdatei,
Laufwerk 3 - Programminstallation,
Laufwerk 4 - Database
Laufwerk 5 - Transactionslogs
Laufwerk 6 - Backup (Dump der DB)
so sollte man das auf realer Hardware aufsetzen
wie ist es, wenn das nun auf einer geclusterten (mehrere ESX-Hosts) Umgebung mit exclusivem SAN (mehrere LUNs) redundant angebunden installiert werden soll?
Fall 1 auf mehrere LUNs verteilen
Fall 2 auf eine LUN packen (meinetwegen auch mit verschiedenen vDisks)
Eure Meinungen mit einer kleinen Begründung wären mir wichtig...
Danke
24
Hallochen,
nach der sogenannten reinen Lehre sollte ein SQL sauber strukturiert sein und für alle Betriebsvorfälle ein eigenes Laufwerk haben
d.h.
Laufwerk 1 - Betriebssystem,
Laufwerk 2 - Swap/Auslagerungsdatei,
Laufwerk 3 - Programminstallation,
Laufwerk 4 - Database
Laufwerk 5 - Transactionslogs
Laufwerk 6 - Backup (Dump der DB)
so sollte man das auf realer Hardware aufsetzen
wie ist es, wenn das nun auf einer geclusterten (mehrere ESX-Hosts) Umgebung mit exclusivem SAN (mehrere LUNs) redundant angebunden installiert werden soll?
Fall 1 auf mehrere LUNs verteilen
Fall 2 auf eine LUN packen (meinetwegen auch mit verschiedenen vDisks)
Eure Meinungen mit einer kleinen Begründung wären mir wichtig...
Danke
24
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: 137829
Url: https://administrator.de/forum/ms-sql-auf-realer-hardware-vs-esx-mit-san-137829.html
Ausgedruckt am: 24.12.2024 um 19:12 Uhr
1 Kommentar
Moin,
das kommt ganz aufs SAN an. Wenn du ein SAN hast bei dem die Festplatten eh schneller als die Anbindung ans Netz ist dann wäre es zimlich latte was du mit den Platten machst.
Nehmen wir aber an du hast eine Anbindung die deutlich schneller ist als deine Festplatten. Jetzt kommt es auf das SAN selbst an. Erstmal: Wie verteilt er die LUNs usw.? Kannst du da mehrere Arrays bauen die dann auch wirklich auf verschiednen Platten liegen? Es bringt dir ja wenig wenn du zwar sagst das du dein SAN in "3 Platten" aufgeteilt haben willst - und der dann intern trotzdem fröhlich alles auf den großen RAID abbildet.
Dann kommt es auf die Ausstattung deines SAN an. Die schnellsten Platten bringen dir nichts wenn das System nicht wirklich parallel arbeiten kann. Ich nehme mal den extremen Fall: Du hättest deine DB auf super-schnellen 15000er Platten - dein TS-Log auf einer guten alten 200 MB-Platte mit 5400 Umdrehungen. Jetzt bringt es dir wenig das aufzuteilen -> deine DB schreibt zwar wie teufel - aber muss immer erst darauf warten das deine TS-Log sagt "Ok, is alles da, darfst weitermachen". Und schon sind die 15000er Platten "fürn Moars"
Und natürlich kommt es auf die DB selbst an. Egal ob du nen MS, nen My-Sql oder Oracle usw. nimmst. Es gibt nicht DEN einzigartigen und perfekten Aufbau. Machst du damit nur zuhause dein Haushaltsbuch (ok, SAN + MS-SQl is dafür etwas oversized.. ;)) dann kann dir das ganze zimlich egal sein. Baust du richtige HA-Datenbanken mit mehreren Knoten dann geht die Kiste richtig ab. Jetzt brauchst du nämlich nicht nur nen SAN sondern auch gleich noch parallel einige Systeme für die Nodes. Hier würdest du mit einem SAN dir vermutlich gleich den Strick um den Hals legen (SAN weg - alle Nodes tot...). Und selbst beim FC-Switch hast du dann schon spass. Nimm 10 Nodes an (richtige DB, wir wollen was ernsthaftes ;) - Haushaltsbuch deluxe halt ;) ) die richtig Traffic haben. Davor nen guter Load-Balancer der die Anfragen auch ordentlich verteilt. Leider muss jetzt jeder Node warten bis das SAN für den bereitsteht (FC-Switch schaltet den Port, Festplatten haben den Datensatz gefunden,...). Schon wäre die AUFTEILUNG der Festplatte egal - solang du nur ein SAN-System drin hast wäre es definitiv ne Bremse.
Von daher ist meine Meinung immer: Bei Datenbanken gibt es nicht DEN Entwurf (weder für den Tabellenaufbau noch für den Hardware-Aufbau usw.). Hier ist in erster Linie wichtig: WAS will ich erreichen und wieviel Geld hab ich zur Verfügung. Die Schnittmenge aus beiden macht dann den Entwurf aus ;)
das kommt ganz aufs SAN an. Wenn du ein SAN hast bei dem die Festplatten eh schneller als die Anbindung ans Netz ist dann wäre es zimlich latte was du mit den Platten machst.
Nehmen wir aber an du hast eine Anbindung die deutlich schneller ist als deine Festplatten. Jetzt kommt es auf das SAN selbst an. Erstmal: Wie verteilt er die LUNs usw.? Kannst du da mehrere Arrays bauen die dann auch wirklich auf verschiednen Platten liegen? Es bringt dir ja wenig wenn du zwar sagst das du dein SAN in "3 Platten" aufgeteilt haben willst - und der dann intern trotzdem fröhlich alles auf den großen RAID abbildet.
Dann kommt es auf die Ausstattung deines SAN an. Die schnellsten Platten bringen dir nichts wenn das System nicht wirklich parallel arbeiten kann. Ich nehme mal den extremen Fall: Du hättest deine DB auf super-schnellen 15000er Platten - dein TS-Log auf einer guten alten 200 MB-Platte mit 5400 Umdrehungen. Jetzt bringt es dir wenig das aufzuteilen -> deine DB schreibt zwar wie teufel - aber muss immer erst darauf warten das deine TS-Log sagt "Ok, is alles da, darfst weitermachen". Und schon sind die 15000er Platten "fürn Moars"
Und natürlich kommt es auf die DB selbst an. Egal ob du nen MS, nen My-Sql oder Oracle usw. nimmst. Es gibt nicht DEN einzigartigen und perfekten Aufbau. Machst du damit nur zuhause dein Haushaltsbuch (ok, SAN + MS-SQl is dafür etwas oversized.. ;)) dann kann dir das ganze zimlich egal sein. Baust du richtige HA-Datenbanken mit mehreren Knoten dann geht die Kiste richtig ab. Jetzt brauchst du nämlich nicht nur nen SAN sondern auch gleich noch parallel einige Systeme für die Nodes. Hier würdest du mit einem SAN dir vermutlich gleich den Strick um den Hals legen (SAN weg - alle Nodes tot...). Und selbst beim FC-Switch hast du dann schon spass. Nimm 10 Nodes an (richtige DB, wir wollen was ernsthaftes ;) - Haushaltsbuch deluxe halt ;) ) die richtig Traffic haben. Davor nen guter Load-Balancer der die Anfragen auch ordentlich verteilt. Leider muss jetzt jeder Node warten bis das SAN für den bereitsteht (FC-Switch schaltet den Port, Festplatten haben den Datensatz gefunden,...). Schon wäre die AUFTEILUNG der Festplatte egal - solang du nur ein SAN-System drin hast wäre es definitiv ne Bremse.
Von daher ist meine Meinung immer: Bei Datenbanken gibt es nicht DEN Entwurf (weder für den Tabellenaufbau noch für den Hardware-Aufbau usw.). Hier ist in erster Linie wichtig: WAS will ich erreichen und wieviel Geld hab ich zur Verfügung. Die Schnittmenge aus beiden macht dann den Entwurf aus ;)
