Virtualisierungsserver
- Ersteller spray
- Erstellt am
Zum virtualisieren wollte ich ESXi embedded laufen lassen:
1x Windows Server 2008 oder 2003 mit SQL Express und diversen Diensten
1x Windows Server 2008 oder 2003 als DC mit SQL__\
1x Windows Server 2008 oder 2003 mit Exchange____|----> Entwicklungsumgebung
1x Windows XP und oder Windows 7______________/
Die erste VM soll 24/7/365 laufen und der Rest auf Bedarf.
Mit der Zeit werden wohl noch nen paar VMs dazu kommen.
Was meinst du genau mit I/O Leistung? Wenn ich den SAS Controller maximal auslaste, dann hab ich doch auch gleichzeitig max I/O Leistung oder meinst du jetzt I/O z.B. ins Netzwerk?
.
EDIT :
.
Neues Setup. Damit kann ich auch endlich was mit den beiden PCI-X 2Gb/s FC Karten anfangen ^^ Die vier Festplatten lasse ich im RAID10 laufen.
Bekomme ich mit nem RAID1 mit 2 Plattem bessere Transferraten oder sind die gleich?
Kann mich nochmal einer in Bezug auf registered RAM aufklären? Wenns mein Board nicht unterstüztzt läuft die ganze Geschichte dann nicht? Bringts den Datenbanken was außer mehr Geld auszugeben?
an den Mod: sry für doppelpost :|
Zuletzt bearbeitet:
Allfred
Grand Admiral Special
Warum nimmst Du den SAS-Controller nicht onboard mit - billiger gehts nicht?
Bzgl. ECC: Wenn Du Dir eine evtl. Datenkorumption leisten kannst (da hilft auch kein RAID), weil es kein Produktivsystem ist, gespartes Geld. AMD Prozessoren machten das von Hause aus mit, ASUS hat das auch im BIOS immer eingepflegt.
Bzgl. ECC: Wenn Du Dir eine evtl. Datenkorumption leisten kannst (da hilft auch kein RAID), weil es kein Produktivsystem ist, gespartes Geld. AMD Prozessoren machten das von Hause aus mit, ASUS hat das auch im BIOS immer eingepflegt.
Ich würde mir bei der überschaubaren Anzahl an VM's mal den HP Micro-Server ansehen
Bei Reichelt für 160€
P212 Raid Controller mit 256 Cache + Batterie 300€
4x 1TB Samsung F3 1TB als Raid-Edition im Raid-10 250€
8GB DDR3 ECC Ram 100€?
Da gibt es sogar eine Remote-Karte für, damit kannst du dann auch per LAN auf die Console drauf.
Ca 50€ extra
ESXi auf USB Stick
Viel weniger knach und Stromsparend dazu.
Siehe hier : http://www.blazilla.de/index.php?/archives/1245-Testumgebung.html oder hier : http://www.hardwareluxx.de/community/f101/hp-proliant-n36l-microserver-752079.html
.
EDIT :
.
bzgl. I/O:
Ich lese 100MB sequentiell (kopiervorgang): vereinfacht 1 I/O Vorgang
Mehrere VM's booten oder kopieren parallel auf dem Server: Mehrere 100 I/O Vorgänge, die in Summe aber keine 10-20MB Transferrate ergeben. Hier kommt es dann drauf an, wieviele Platten im Raidverbindung, welche Geschwindigkeit die Platten selbst haben und welcher Raid-Level.
Meine Empfehlung zwecks maximalen Speed: Raid-10 über 4 Platten.
Bei Reichelt für 160€
P212 Raid Controller mit 256 Cache + Batterie 300€
4x 1TB Samsung F3 1TB als Raid-Edition im Raid-10 250€
8GB DDR3 ECC Ram 100€?
Da gibt es sogar eine Remote-Karte für, damit kannst du dann auch per LAN auf die Console drauf.
Ca 50€ extra
ESXi auf USB Stick
Viel weniger knach und Stromsparend dazu.
Siehe hier : http://www.blazilla.de/index.php?/archives/1245-Testumgebung.html oder hier : http://www.hardwareluxx.de/community/f101/hp-proliant-n36l-microserver-752079.html
.
EDIT :
.
bzgl. I/O:
Ich lese 100MB sequentiell (kopiervorgang): vereinfacht 1 I/O Vorgang
Mehrere VM's booten oder kopieren parallel auf dem Server: Mehrere 100 I/O Vorgänge, die in Summe aber keine 10-20MB Transferrate ergeben. Hier kommt es dann drauf an, wieviele Platten im Raidverbindung, welche Geschwindigkeit die Platten selbst haben und welcher Raid-Level.
Meine Empfehlung zwecks maximalen Speed: Raid-10 über 4 Platten.
mariahellwig
Grand Admiral Special
Lass dich nicht verrückt machen.
I/O Leistung ist erst wichtig, wenn du eine umfangreiche Datenbank hast die einer größere Anzahl User bedienen muss. Solange du im SQL-Express Bereich bist, vergiss es.
Wenn nicht alles über eine Festplatte läuft sind die Voraussetzungen wahrscheinlich erfüllt.
Wenn du mit Raid-Systemen arbeiten willst, geht kein Weg an einem dezidierten Controller vorbei. Ist das Board defekt, kommst du bei einem Onboard-Controller nicht mehr an deine Daten.
Bei deiner Konfiguration ist Hyper-V wahrscheinlich die bessere Wahl. Einfach weil die Treiberunterstützung breiter ist als bei ESXi und die Administration einfacher.
Ob nun AMD oder Intel ist Banane. Beide System laufen ohne Probleme out of the Box.
I/O Leistung ist erst wichtig, wenn du eine umfangreiche Datenbank hast die einer größere Anzahl User bedienen muss. Solange du im SQL-Express Bereich bist, vergiss es.
Wenn nicht alles über eine Festplatte läuft sind die Voraussetzungen wahrscheinlich erfüllt.
Wenn du mit Raid-Systemen arbeiten willst, geht kein Weg an einem dezidierten Controller vorbei. Ist das Board defekt, kommst du bei einem Onboard-Controller nicht mehr an deine Daten.
Bei deiner Konfiguration ist Hyper-V wahrscheinlich die bessere Wahl. Einfach weil die Treiberunterstützung breiter ist als bei ESXi und die Administration einfacher.
Ob nun AMD oder Intel ist Banane. Beide System laufen ohne Probleme out of the Box.
Allfred
Grand Admiral Special
Andererseits ist man so genau auf diesen RaidController angewiesen. Komplett HW unabhängig bist du erst mit einem Softraid. Kostet am wenigsten und läuft immer.
mariahellwig
Grand Admiral Special
Im Prinzip richtig. Was ich an einem guten Controller schätze ist die Robustheit und die Administration. Softraids unter Windows z.B. melden schon mal Probleme wo keine sind. Der Tausch einer defekten Platte ist auch nicht ohne. Das fängt schon mit dem identifizieren der defekten Platte an. Wenn das Gerät 24x365 laufen soll, braucht man da eine schnelle Lösung.
@ Supi
meinst nich, dass der hp server nen bisschen unterdimensioniert ist?
im mom laufen die datenbank, nen intranet server und diverse dienste auf nem einfachen windows xp rechner (2,93 GHz mit 4GB RAM) und der ist in letzter zeit immer öfter leicht ausgelastet...
meinst nich, dass der hp server nen bisschen unterdimensioniert ist?
im mom laufen die datenbank, nen intranet server und diverse dienste auf nem einfachen windows xp rechner (2,93 GHz mit 4GB RAM) und der ist in letzter zeit immer öfter leicht ausgelastet...
mariahellwig
Grand Admiral Special
Wie laufen sie denn? vmWare Worktstation oder Server?
Das mag zum testen OK sein. Einen Einblick auf die zu erwartende Performance erhält man damit aber nicht. Beide Produkte sind sehr ineffizient weil sie zu viel Overhead haben.
ESXi ist eine andere Liga.
Das mag zum testen OK sein. Einen Einblick auf die zu erwartende Performance erhält man damit aber nicht. Beide Produkte sind sehr ineffizient weil sie zu viel Overhead haben.
ESXi ist eine andere Liga.
april.shower
Commander
- Mitglied seit
- 16.12.2007
- Beiträge
- 183
- Renomée
- 6
bei 24/7 Betrieb empfiehlt sich auf jeden Fall ECC Ram, das hilft Speicherfehler und letztlich Datenkorruption zu vermeiden.
ECC Ram gibt es als Registered Ram (RDimms) und Unbuffered Ram (UDimms). Ob ein Board das eine, andere oder beides unterstützt, hängt vom verwendeten Chipsatz ab.
Ich hab jetzt nicht eigens nachgeschaut, aber der X58 Chipsatz unterstützt m.E. nur Unbuffered ECC Ram.
Ein Blick in die Speicherkompatibilitätsliste des Boards, an die man sich peinlich genau halten sollte, würde das aber klären.
Was mir an dem Board oben nicht schmeckt, sind diese alten mit nur 133MHz laufenden PCI-X Schnittstellen. Damit zieht man keine Wurst mehr vom Brot.
zum Storage-Subsystem. Ich weiß nicht, ob eine Virtualisierungsanwendung Festplatten-lastig ist. Was man in jedem Fall braucht, ist viel Ram, so zwischen 16 und 32 GB.
Aber wenn die Virtualisierungsanwendung ausserdem Festplatten-lastig ist, dann wird es nicht auf Transferraten (wie du vielleicht meinst) ankommen, sondern auf IO-Leistung.
Was ist der Unterschied zwischen Durchsatz/Transferleistung und IO-Leistung?
Am besten erklärt sich dieser Unterschied anhand von beispielhaften Anwendungen, bei denen das eine oder das andere zum Tragen kommt. Und das sind einerseits Streaming-/Video-Anwendungen und andererseits Datenbankanwendungen.
Eine Videoanwendung greift auf die Daten zu in langen sequentiellen reads und writes (long sequential reads/writes), die dann in MB/s gemessen werden. Das Maß für Transferleistung oder Durchsatz ist also MB/s. Zugriffe dieser Art sind für Festplatten eine ziemlich gemächliche Gangart. Die Köpfe brauchen im Wesentlichen einfach nur der Spur zu folgen und erzeugen einen langen Datenstrom. Da Daten dieser Art typischerweise auch ziemlich groß sind, passen zu solchen Video- oder Streamingdaten auch sehr große Platten im Terabyte-Bereich. Eine Erhöhung des Durchsatzes von solchen
Platten wird heutzutage vor allem durch Erhöhung der Datendichte der Platter erreicht. Bei gleicher Geschwindigkeit (von 5900 oder 7200 RPM) werden bei höherer Datendichte mehr Bytes pro Zeiteinheit gelesen.
Der Durchsatz ließe sich natürlich auch durch höhere Rotationsgeschwindigkeit erreichen. Doch dieser Weg führte zu ganz erheblichen zusätzlichen Kosten. Eine Platte mit 10000 oder 15000 RPM muss viel robuster konstruiert sein, sie muss mit Vibrationsdetektoren und zusätzlichen Korrekturmotoren ausgestattet sein, usw. Mehr Speicherplatz dagegen ist etwas, was ohnehin erforderlich ist, weil Daten immer größer und immer mehr werden. Daher schlägt man mit einer Erhöhung der Datendichte praktisch zwei Fliegen mit einer Klappe und hat, im Gegensatz zur Erhöhung der Geschwindigkeit, keine zusätzlichen Kosten, wenn es darum geht, die Transferleistung zu erhöhen.
Eine Datenbank andererseits greift völlig anders auf die Daten zu, nämlich in kurzen (typischerweise etwa 4K chunks) und vor allem zufälligen reads und writes. Solche Zugriffe werden nicht in MB/s gemessen, sondern in IOPS (input-output-operationen per second). Und diese Art Zugriff ist wesentlich anspruchsvoller und für die Mechanik der Platte, vor allem bei Dauerlasten, erheblicher Stress. Denn die Köpfe müssen in wilden zufälligen Mustern auf den Plattern hin und her springen, um nur sehr kleine Datenblöcke zu lesen oder zu schreiben. Und es ist klar, worauf es bei dieser Art
Zugriff ankommt, nämlich auf die seek-time und die damit zusammenhängende Drehgeschwindigkeit der Platte. Die allermeiste Zeit verbringt die Platte bei solchen Zugriffen mit dem Auffinden der Datenstelle (seek), die Übertragung der Daten zum Host geschieht dagegen in so kurzer Zeit, daß sie zu vernachlässigen ist. Daher kommt es in solchen Datenzugriffsszenarien nicht auf Transferleistung (MB/s), sondern darauf, wieviele Host-Kommandos eine Platte per Zeiteinheit bedienen kann (IOPS).
In einer solchen Umgebung verwendet man, vor allem wenn wirklich Lasten anstehen, besser keine einfachen Consumerplatten, die erstens zu langsam drehen und zweitens konstruktiv nicht für dauerhafte Lasten dieser Art ausgelegt sind. Für solchen Aufgaben nimmt man High Speed Platten mit 10000 oder 15000 RPM und SAS Interface. Platten für diese Zwecke brauchen auch nicht so groß zu sein, typischerweise sind sie zwischen etwa 100 und 400 GB, denn Datenbanken sind eben nicht so groß. Ausserdem lassen sich Einzelplatten auch zu Arrays (per SAS Raid Controller) zusammenschalten (stripen), wodurch dann praktisch beliebig große logische Volumes aus mehreren kleineren
Einzelplatten entstehen. Dies sorgt im Übrigen auch noch für eine Steigerung der IO-Leistung.
Die höchste Gesamt-IO-Leistung bezüglich Lesen und Schreiben von Datenblöcken produziert Raid-10. Raid-10 ist ein gestripter Mirror (wartet also mit Redundanz und daher Ausfallsicherheit auf) und benötigt mindestens 4 gleichartige Platten, ist sehr schnell (und bei 6 oder 8 Platten sehr sehr schnell) und auch sehr teuer, weil die Speichereffizienz
(wegen der Spiegelung) nur 50% beträgt. Andere Raid-Level, wie Raid-5, können zwar ähnlich schnell sein beim Lesen, fallen aber beim Schreiben von Daten hinter raid-10 zurück.
Wie errechnet sich die IO-Leistung einer Einzelplatte?
Das geht so:
man bilde (unter Berücksichtigung der Zeiteinheit) den Kehrwert aus (average seek time + average latency). (transfer rate spielt dabei überhaupt keine signifikante rolle, weil sie unerheblich ist relativ zu den anderen Einflüssen)
Die durchschnittliche seek time errechnet sich aus (seek time read + seek time write) / 2
Eine Platte mit seek read von 8,9ms und seek write von 10,9ms erreicht eine average seek time von 9,9ms
Die durchschnittliche Latenz errechnet sich aus dem Kehrwert der Umdrehungszahl, der Umrechnung der Zeiteinheit (RPM heißt "pro Minute", also pro 60s; die Zieleinheit ist zudem Millisekunden (ms), i.e 1s = 1000ms) und schließlich noch Berücksichtigung der "durchschnittlichen" seek time, was man durch Teilung der errechneten seek time durch 2 erreicht, denn zum Zeitpunkt des host commandos kann der schreib/lese-kopf noch eine ganze Umdrehung vom Beginn der Daten entfernt sein oder schon (zufäligerweise) am Beginn der Daten stehen oder sich irgendwo dazwischen aufhalten, so daß der Kopf durchschnittlich immer eine halbe Umdrehung vom Beginn von Daten entfernt ist)
eine Platte mit 7200 RPM erreicht so eine Latenz von 8,33ms und eine average latency von 8,33/2 = (rund) 4,2ms
die average seek time und die average latency ergeben zusammen eine random io-latency von 4,2 + 9,9 = 14,1ms
Da der Zugriff eines Einzellaufwerks auf die Daten nur ein (host-)command erfordert, ergibt der Kehrwert von 14,1ms (unter Berücksichtigung der Zeiteinheit Millisekunden) eine IO-Leistung von rund 71 IOPS (bei wohlgemerkt zufälligen Zugriffen)
Eine Platte mit 10000 RPM (etwa Seagate Savvio 10K.5), was zu einer average latency von 3ms führt,
und einer average seek time read 3,4ms und write 3,8ms, was zu einer average seek time von 3,6ms führt,
bringt es dagegen bereits auf eine IO-Leistung von rund 151 IOPS.
Bei der Errechnung dieser Werte ist noch keinerlei Cache, weder Platten-seitiger noch Controller-seitiger, berücksichtigt.
Oben wurde auf IO-Performance-Unterschiede beim Lesen und Schreiben aufmerksam gemacht. Wenn es um IO-Leistung von Einzelplatten geht, sind ja SSDs nicht zu schlagen, weil die seek-time praktisch hinfällig ist (etwas womit Hardisks die meiste Zeit verbringen müssen). Leider ist die Schreibperformance von SSDs nichts, weswegen man
einen Brief nach Hause schreiben würde. Das Schreiben ist der wunde Punkt von SSDs.
Was hat die Zugriffsweise von Datenbanken denn mit Virtualisierungsanwendungen zu tun? Das kommt eben darauf an, was man virtualisiert. Virtualisiert werden Anwendungen. Anwendungen welcher Art? Jede Art Software kann in einer virtuellen Maschine laufen, auch zb. Videosoftware. Wie ich sehe geht es hier um die Virtualisierung von
Systemen, Betriebssystemen. Betriebssysteme aber sind vom Typ der Datenzugriffe her als Datenbank-ähnliche Anwendungen anzusehen, da ein OS unter Last auf eine Vielzahl von sehr kleinen Daten zugreifen muss in zufälligen Mustern.
Ein System, das sehr sehr schnell und robust sein sollte, würde man auf einem raid-10 aufsetzen und mit reichlich Ram ausstatten.
Aber im Soho- oder reinen Homebereich ist ja immer die Frage, was man wie weit zu optimieren bereit ist (selbst wenn man es nicht unbedingt "braucht"), weil es eben keinen Return on Invest gibt, sondern das Ganze einfach eine Konsum-Ausgabe ist.
ECC Ram gibt es als Registered Ram (RDimms) und Unbuffered Ram (UDimms). Ob ein Board das eine, andere oder beides unterstützt, hängt vom verwendeten Chipsatz ab.
Ich hab jetzt nicht eigens nachgeschaut, aber der X58 Chipsatz unterstützt m.E. nur Unbuffered ECC Ram.
Ein Blick in die Speicherkompatibilitätsliste des Boards, an die man sich peinlich genau halten sollte, würde das aber klären.
Was mir an dem Board oben nicht schmeckt, sind diese alten mit nur 133MHz laufenden PCI-X Schnittstellen. Damit zieht man keine Wurst mehr vom Brot.
zum Storage-Subsystem. Ich weiß nicht, ob eine Virtualisierungsanwendung Festplatten-lastig ist. Was man in jedem Fall braucht, ist viel Ram, so zwischen 16 und 32 GB.
Aber wenn die Virtualisierungsanwendung ausserdem Festplatten-lastig ist, dann wird es nicht auf Transferraten (wie du vielleicht meinst) ankommen, sondern auf IO-Leistung.
Was ist der Unterschied zwischen Durchsatz/Transferleistung und IO-Leistung?
Am besten erklärt sich dieser Unterschied anhand von beispielhaften Anwendungen, bei denen das eine oder das andere zum Tragen kommt. Und das sind einerseits Streaming-/Video-Anwendungen und andererseits Datenbankanwendungen.
Eine Videoanwendung greift auf die Daten zu in langen sequentiellen reads und writes (long sequential reads/writes), die dann in MB/s gemessen werden. Das Maß für Transferleistung oder Durchsatz ist also MB/s. Zugriffe dieser Art sind für Festplatten eine ziemlich gemächliche Gangart. Die Köpfe brauchen im Wesentlichen einfach nur der Spur zu folgen und erzeugen einen langen Datenstrom. Da Daten dieser Art typischerweise auch ziemlich groß sind, passen zu solchen Video- oder Streamingdaten auch sehr große Platten im Terabyte-Bereich. Eine Erhöhung des Durchsatzes von solchen
Platten wird heutzutage vor allem durch Erhöhung der Datendichte der Platter erreicht. Bei gleicher Geschwindigkeit (von 5900 oder 7200 RPM) werden bei höherer Datendichte mehr Bytes pro Zeiteinheit gelesen.
Der Durchsatz ließe sich natürlich auch durch höhere Rotationsgeschwindigkeit erreichen. Doch dieser Weg führte zu ganz erheblichen zusätzlichen Kosten. Eine Platte mit 10000 oder 15000 RPM muss viel robuster konstruiert sein, sie muss mit Vibrationsdetektoren und zusätzlichen Korrekturmotoren ausgestattet sein, usw. Mehr Speicherplatz dagegen ist etwas, was ohnehin erforderlich ist, weil Daten immer größer und immer mehr werden. Daher schlägt man mit einer Erhöhung der Datendichte praktisch zwei Fliegen mit einer Klappe und hat, im Gegensatz zur Erhöhung der Geschwindigkeit, keine zusätzlichen Kosten, wenn es darum geht, die Transferleistung zu erhöhen.
Eine Datenbank andererseits greift völlig anders auf die Daten zu, nämlich in kurzen (typischerweise etwa 4K chunks) und vor allem zufälligen reads und writes. Solche Zugriffe werden nicht in MB/s gemessen, sondern in IOPS (input-output-operationen per second). Und diese Art Zugriff ist wesentlich anspruchsvoller und für die Mechanik der Platte, vor allem bei Dauerlasten, erheblicher Stress. Denn die Köpfe müssen in wilden zufälligen Mustern auf den Plattern hin und her springen, um nur sehr kleine Datenblöcke zu lesen oder zu schreiben. Und es ist klar, worauf es bei dieser Art
Zugriff ankommt, nämlich auf die seek-time und die damit zusammenhängende Drehgeschwindigkeit der Platte. Die allermeiste Zeit verbringt die Platte bei solchen Zugriffen mit dem Auffinden der Datenstelle (seek), die Übertragung der Daten zum Host geschieht dagegen in so kurzer Zeit, daß sie zu vernachlässigen ist. Daher kommt es in solchen Datenzugriffsszenarien nicht auf Transferleistung (MB/s), sondern darauf, wieviele Host-Kommandos eine Platte per Zeiteinheit bedienen kann (IOPS).
In einer solchen Umgebung verwendet man, vor allem wenn wirklich Lasten anstehen, besser keine einfachen Consumerplatten, die erstens zu langsam drehen und zweitens konstruktiv nicht für dauerhafte Lasten dieser Art ausgelegt sind. Für solchen Aufgaben nimmt man High Speed Platten mit 10000 oder 15000 RPM und SAS Interface. Platten für diese Zwecke brauchen auch nicht so groß zu sein, typischerweise sind sie zwischen etwa 100 und 400 GB, denn Datenbanken sind eben nicht so groß. Ausserdem lassen sich Einzelplatten auch zu Arrays (per SAS Raid Controller) zusammenschalten (stripen), wodurch dann praktisch beliebig große logische Volumes aus mehreren kleineren
Einzelplatten entstehen. Dies sorgt im Übrigen auch noch für eine Steigerung der IO-Leistung.
Die höchste Gesamt-IO-Leistung bezüglich Lesen und Schreiben von Datenblöcken produziert Raid-10. Raid-10 ist ein gestripter Mirror (wartet also mit Redundanz und daher Ausfallsicherheit auf) und benötigt mindestens 4 gleichartige Platten, ist sehr schnell (und bei 6 oder 8 Platten sehr sehr schnell) und auch sehr teuer, weil die Speichereffizienz
(wegen der Spiegelung) nur 50% beträgt. Andere Raid-Level, wie Raid-5, können zwar ähnlich schnell sein beim Lesen, fallen aber beim Schreiben von Daten hinter raid-10 zurück.
Wie errechnet sich die IO-Leistung einer Einzelplatte?
Das geht so:
man bilde (unter Berücksichtigung der Zeiteinheit) den Kehrwert aus (average seek time + average latency). (transfer rate spielt dabei überhaupt keine signifikante rolle, weil sie unerheblich ist relativ zu den anderen Einflüssen)
Die durchschnittliche seek time errechnet sich aus (seek time read + seek time write) / 2
Eine Platte mit seek read von 8,9ms und seek write von 10,9ms erreicht eine average seek time von 9,9ms
Die durchschnittliche Latenz errechnet sich aus dem Kehrwert der Umdrehungszahl, der Umrechnung der Zeiteinheit (RPM heißt "pro Minute", also pro 60s; die Zieleinheit ist zudem Millisekunden (ms), i.e 1s = 1000ms) und schließlich noch Berücksichtigung der "durchschnittlichen" seek time, was man durch Teilung der errechneten seek time durch 2 erreicht, denn zum Zeitpunkt des host commandos kann der schreib/lese-kopf noch eine ganze Umdrehung vom Beginn der Daten entfernt sein oder schon (zufäligerweise) am Beginn der Daten stehen oder sich irgendwo dazwischen aufhalten, so daß der Kopf durchschnittlich immer eine halbe Umdrehung vom Beginn von Daten entfernt ist)
eine Platte mit 7200 RPM erreicht so eine Latenz von 8,33ms und eine average latency von 8,33/2 = (rund) 4,2ms
die average seek time und die average latency ergeben zusammen eine random io-latency von 4,2 + 9,9 = 14,1ms
Da der Zugriff eines Einzellaufwerks auf die Daten nur ein (host-)command erfordert, ergibt der Kehrwert von 14,1ms (unter Berücksichtigung der Zeiteinheit Millisekunden) eine IO-Leistung von rund 71 IOPS (bei wohlgemerkt zufälligen Zugriffen)
Eine Platte mit 10000 RPM (etwa Seagate Savvio 10K.5), was zu einer average latency von 3ms führt,
und einer average seek time read 3,4ms und write 3,8ms, was zu einer average seek time von 3,6ms führt,
bringt es dagegen bereits auf eine IO-Leistung von rund 151 IOPS.
Bei der Errechnung dieser Werte ist noch keinerlei Cache, weder Platten-seitiger noch Controller-seitiger, berücksichtigt.
Oben wurde auf IO-Performance-Unterschiede beim Lesen und Schreiben aufmerksam gemacht. Wenn es um IO-Leistung von Einzelplatten geht, sind ja SSDs nicht zu schlagen, weil die seek-time praktisch hinfällig ist (etwas womit Hardisks die meiste Zeit verbringen müssen). Leider ist die Schreibperformance von SSDs nichts, weswegen man
einen Brief nach Hause schreiben würde. Das Schreiben ist der wunde Punkt von SSDs.
Was hat die Zugriffsweise von Datenbanken denn mit Virtualisierungsanwendungen zu tun? Das kommt eben darauf an, was man virtualisiert. Virtualisiert werden Anwendungen. Anwendungen welcher Art? Jede Art Software kann in einer virtuellen Maschine laufen, auch zb. Videosoftware. Wie ich sehe geht es hier um die Virtualisierung von
Systemen, Betriebssystemen. Betriebssysteme aber sind vom Typ der Datenzugriffe her als Datenbank-ähnliche Anwendungen anzusehen, da ein OS unter Last auf eine Vielzahl von sehr kleinen Daten zugreifen muss in zufälligen Mustern.
Ein System, das sehr sehr schnell und robust sein sollte, würde man auf einem raid-10 aufsetzen und mit reichlich Ram ausstatten.
Aber im Soho- oder reinen Homebereich ist ja immer die Frage, was man wie weit zu optimieren bereit ist (selbst wenn man es nicht unbedingt "braucht"), weil es eben keinen Return on Invest gibt, sondern das Ganze einfach eine Konsum-Ausgabe ist.
Zuletzt bearbeitet:
ESXi kann Page-Sharing, also wenn du 2 SRV08 hast, hält der ESXi die Windows DLL nur 1x im Ram.
Also bei dem mit meinem Beispiel reicht der HP durchaus für mehrere VM's. Zum ESXi ist vmware-forum.de hilfreich.
Alternativ würde ich halt nen i7-2600 nehmen, 16GB Ram, 1x System als Raid-1 und über Windows ein Raid-5 LW einrichten.
Dann auf dem SRV08 die Hyper-V Rolle aktivieren und die VM's unter Hyper-V laufen lassen.
Edit: Alternativ gibts bei Dell auch den PowerEdge T110 recht günstig ab 239€.
Alternativ 1066€ netto mit :
Core i5
16GB Ram ECC
4x250er SATA HDD Raid-5
Perc H200 Raid-Controller (
Halt ein richtiger Server.
Zuletzt bearbeitet:
april.shower
Commander
- Mitglied seit
- 16.12.2007
- Beiträge
- 183
- Renomée
- 6
... und das geht durch diese alte Schnittstelle? wow, unglaublich
da müssen dann aber ein Haufen bits pro Takt übertragen werden,
denn die taktet ja nur mit 133MHz, nicht wahr?
was für ne Karte haste denn da noch, LSI?
da müssen dann aber ein Haufen bits pro Takt übertragen werden,
denn die taktet ja nur mit 133MHz, nicht wahr?
was für ne Karte haste denn da noch, LSI?
Ist eine LSI 7102XP-LC.
Also auf nem normalen PCI Slot an unserem SAN in nem Testrechner (MB: P5QPL-AM), hat die ganze Geschichte 90 MB/s lesen und 45 MB/s schreiben (beides squentiell; ich poste morgen mal nen screener davon) gebracht. Ich hab noch nen alten Dell PowerEdge Server mit zwei PCI-X Slots. Leider bin ich zu diesem Test noch nicht gekommen. Aber die Werte dürften aufgrund des veralteten Chipsatzes nicht so aussagend sein.
"PCI-X 1 * 133 MHz * 64 Bit = 1064 MByte/s" Quelle: it-academy.cc
Keine Ahnung ob das stimmt. Aber ich nehme es mal so hin. Die Karte soll theoretisch 400MB/s im Voll-Duplex-Modus erbringen.
Wenn die bei VMware nicht auf der Kompatiblitätsliste ist, gibts wohl auch null Chance, dass die nacher auf ner VM anständig funktioniert oder?
FibrChannel hab ich jetzt fallengelassen. Das bringt einfach nichts, weils definitiv nicht ins Budget passt.
EDIT:
Langsam komme ich zur final config
final 1
final 2
einziger unterschied ist bei final 1 4x Volciraptor aber nur 2x 16GB RAM, bei final 2 isses anders rum
werd ich wohl nochmal überlegen ob mehr RAM und RAID 1 bzw RAID 0 oder weniger RAM und RAID 10 bzw RAID 0+1
sowohl mainboard als auch raid controller stehen aufer vmware hlc
Also auf nem normalen PCI Slot an unserem SAN in nem Testrechner (MB: P5QPL-AM), hat die ganze Geschichte 90 MB/s lesen und 45 MB/s schreiben (beides squentiell; ich poste morgen mal nen screener davon) gebracht. Ich hab noch nen alten Dell PowerEdge Server mit zwei PCI-X Slots. Leider bin ich zu diesem Test noch nicht gekommen. Aber die Werte dürften aufgrund des veralteten Chipsatzes nicht so aussagend sein.
"PCI-X 1 * 133 MHz * 64 Bit = 1064 MByte/s" Quelle: it-academy.cc
Keine Ahnung ob das stimmt. Aber ich nehme es mal so hin. Die Karte soll theoretisch 400MB/s im Voll-Duplex-Modus erbringen.
Wenn die bei VMware nicht auf der Kompatiblitätsliste ist, gibts wohl auch null Chance, dass die nacher auf ner VM anständig funktioniert oder?
FibrChannel hab ich jetzt fallengelassen. Das bringt einfach nichts, weils definitiv nicht ins Budget passt.
EDIT:
Langsam komme ich zur final config
final 1
final 2
einziger unterschied ist bei final 1 4x Volciraptor aber nur 2x 16GB RAM, bei final 2 isses anders rum
werd ich wohl nochmal überlegen ob mehr RAM und RAID 1 bzw RAID 0 oder weniger RAM und RAID 10 bzw RAID 0+1
sowohl mainboard als auch raid controller stehen aufer vmware hlc
Zuletzt bearbeitet:
