ErikM Geschrieben 9. August 2014 Geschrieben 9. August 2014 Hallöchen, ich betreibe einen Server mit folgender Ausstattung AMD Opteron 3365 8-Kerner16 GB ECC RAM2 * 1 TB HDD im Raid1 das ganze auf einem SuperMicro Board mit VMWare ESXi als Hypervisor Meine Frage ist jetzt folgende... Wieviele virtuelle Maschinen sollte man darauf laufen lassen :confused: ohne, dass das zuviel ist.. z.Z. laufen auf dem Gerät eine Router-VM (Debian 1 Kern, 512 MB)ein Webserver (Debian,4 Kerne, 4 GB RAM)eine OwnCloud (Debian, 1 Kern, 1GB RAM)ein Teamspeak-Minimalsystem (1 Kern, 256 MB RAM)ein Mailserver (Debian, 2 Kerne, 1 GB RAM) Arbeitsspeicher ist an sich ja noch genug vorhanden Zitieren
uenetz Geschrieben 10. August 2014 Geschrieben 10. August 2014 Servus! Ich weiss zwar nicht den Grund für Dein VM-Konzept, aber Du wirst Dir dabei wohl etwas gedacht haben .oO(vermute ich mal). Deine Frage ist in dieser Form nicht zu beantworten,da es auch 1. sehr stark von der Nutzung der Dienste (Anz. User), wie auch 2. von der Parametrierung der Dienste abhängig. Daher ist wohl nur ein Rat sinnvoll: TESTE die Grenzen der Belastung in Deinem Realbetrieb aus. Zitieren
Wuwu Geschrieben 10. August 2014 Geschrieben 10. August 2014 Putty zum Host -> ESXtop und auf die Zahlen oben schauen, ist noch alles unter 80-90 bist Du im gruenen Bereich. Ich lasse bei mir ca. ne Ratio 4-8 virtuelle pro physischen Core laufen und laste die CPU nichtmal ansatzweise aus. Zitieren
BerLan Geschrieben 11. August 2014 Geschrieben 11. August 2014 Mir drängt sich die Frage auf, ob die Platten schnell genug sind wenn da mehrere VMs random-io veranstalten. Zitieren
Eta_Carinae Geschrieben 11. August 2014 Geschrieben 11. August 2014 Angesichts der Kapazität werden das mit hoher Wahrscheinlich SATA Platten sein. SAS-NL wären auch denkbar. Bei RAID 1 kommen da so 70 bis 90 IOPS rum - nicht wirklich viel... Angesichts der CPU Auslastung: 8 CPU Kerne, 9 vCPUs. Das ist fast ein 1:1 Verhältnis. Die CPU Last an sich ist nicht mal das Problem, wichtiger sind %RDY und %CSTP mit in die Bewertung einzubeziehen. Ein %RDY von 5% und höher deutet auf Probleme hin. Da du aber nur eine 4 vCPU Maschine dabei hast, sollten sich die restlichen Maschinen noch geschmeidig einplanen lassen. Der Scheduler macht das schon. Hab einfach ein Auge auf %RDY und %CSTP und alles wird gut. Beide Werte kannst du am einfachsten per ESXTOP auslesen. Zitieren
Wuwu Geschrieben 11. August 2014 Geschrieben 11. August 2014 > Ein %RDY von 5% und höher deutet auf Probleme hin. Nein Performanceprobleme deuten auf ein Problem hin, schau Dir den NUMA Scheduler in 5.1 und hoeher an, es wird fuer NUMA Lokalitaet wesentlich mehr als 5% RDY erlaubt. Zitieren
Eta_Carinae Geschrieben 11. August 2014 Geschrieben 11. August 2014 Quelle? 5% pro vCPU gelten allgemein als vertretbarer Wert. Wenn du also bei einer 4 vCPU Maschine einen %RDY von 20% siehst, dann kann das noch im Rahmen sein. Zitieren
Wuwu Geschrieben 11. August 2014 Geschrieben 11. August 2014 (bearbeitet) Quelle? 5% pro vCPU gelten allgemein als vertretbarer Wert. Wenn du also bei einer 4 vCPU Maschine einen %RDY von 20% siehst, dann kann das noch im Rahmen sein. Willkommen bei ESXi 4.x ... Als naechstes moechtest Du mir erzaehlen, dass Du durch TPS auf dem Host im Schnitt 20% RAM sparst? Wenn Dein Workload keine Performanceeinbussen hat, koennen selbst 95% RDY noch vollkommen akzeptable sein. Ich habe auch schon Anwendungen auf der anderen Seite gesehn, die mit 2% Ready NICHT klargekommen sind. Es ist extrem Workloadspezifisch, ergo wenn Du keine messbaren Performanceeinbussen hast, braucht Dich der RDY Wert auch nicht wirklich interessieren. Nimm Dir einfach mal VMware KB: esxtop command showing high %RDY values for virtual machines running on NUMA enabled ESX/ESXi 4.1 hosts als Beispiel. Ja hohe RDY kann zu Performanceeinbussen fuehren, deaktivierst Du NUMA hast Du in den meisten Faellen die RDY sofort gesenkt und trotzdem absolut NICHTS gekonnt. Der Scheduler wird gerade bei VMs, die bestimmte Host Userworlds benoetigen (z.B. bei Traffic ueber die physische NIC) versuchen diese auf dem gleichen Socket zu schedulen (sogenannte Action Affinity), Last Level Cache lautet hier das Zauberwort. Dafuer wird durchaus in etwas hoehrere RDY Wert in Kauf genommen, wir vergleichen einfach mal 3%-5% (Zahlen komplett aus der Luft gegriffen) mehr RDY mit dem Unterschied der Zugriffszeit von CPU local Cache zum RAM und kommen ganz fix zu dem Ergebis, dass RDY auf einmal ein Wert ist, den wir gerne in Kauf nehmen http://www.vmware.com/files/pdf/techpaper/VMware-vSphere-CPU-Sched-Perf.pdf ab Seite 9 enthaelt die entsprechenden Informationen. Ansonsten kannst Du aber sicher eine offizielle VMware Quelle nennen, die die 5% RDY Schwelle beschreibt. Damit meine ich nicht private Blogs von VMware Mitarbeitern, sondern KB Artikel, offizielle VMware Blogs oder Whitepaper. > Angesichts der Kapazität werden das mit hoher Wahrscheinlich SATA Platten sein. SAS-NL wären auch denkbar. Bei RAID 1 kommen da so 70 bis 90 IOPS rum - nicht wirklich viel... Da hast Du wohl eher den Performancekiller gefunden Bearbeitet 11. August 2014 von Wuwu Zitieren
Eta_Carinae Geschrieben 12. August 2014 Geschrieben 12. August 2014 Willkommen bei ESXi 4.x ... Als naechstes moechtest Du mir erzaehlen, dass Du durch TPS auf dem Host im Schnitt 20% RAM sparst? Spar dir den Sarkasmus. Wenn Dein Workload keine Performanceeinbussen hat, koennen selbst 95% RDY noch vollkommen akzeptable sein. Ich habe auch schon Anwendungen auf der anderen Seite gesehn, die mit 2% Ready NICHT klargekommen sind. Es ist extrem Workloadspezifisch, ergo wenn Du keine messbaren Performanceeinbussen hast, braucht Dich der RDY Wert auch nicht wirklich interessieren. Natürlich muss man den Workload mit einbeziehen. Es schadet aber nicht, den %RDY im Auge zu behalten. Nimm Dir einfach mal VMware KB: esxtop command showing high %RDY values for virtual machines running on NUMA enabled ESX/ESXi 4.1 hosts als Beispiel. Ja hohe RDY kann zu Performanceeinbussen fuehren, deaktivierst Du NUMA hast Du in den meisten Faellen die RDY sofort gesenkt und trotzdem absolut NICHTS gekonnt. Willkommen bei vSphere 4.1... um es mit deinen Worten zu sagen. Der Scheduler wird gerade bei VMs, die bestimmte Host Userworlds benoetigen (z.B. bei Traffic ueber die physische NIC) versuchen diese auf dem gleichen Socket zu schedulen (sogenannte Action Affinity), Last Level Cache lautet hier das Zauberwort. Dafuer wird durchaus in etwas hoehrere RDY Wert in Kauf genommen, wir vergleichen einfach mal 3%-5% (Zahlen komplett aus der Luft gegriffen) mehr RDY mit dem Unterschied der Zugriffszeit von CPU local Cache zum RAM und kommen ganz fix zu dem Ergebis, dass RDY auf einmal ein Wert ist, den wir gerne in Kauf nehmen Soweit sind wir uns einig. Ansonsten kannst Du aber sicher eine offizielle VMware Quelle nennen, die die 5% RDY Schwelle beschreibt. Damit meine ich nicht private Blogs von VMware Mitarbeitern, sondern KB Artikel, offizielle VMware Blogs oder Whitepaper. Es gibt keine mir bekannte offizielle Quelle. Trotzdem werden sich Leute wie Duncan Epping oder Jason Boche etwas dabei gedacht haben. Auch sie schreiben, dass es vom konkreten Workload abhängt. Und ich halte es für durchaus vertretbar ihre Aussagen als Orientierung zu verwenden. Zumal sie sich mit meiner Erfahrung decken. Da Widerspreche ich dir auch nicht. %RDY Werte können aber einen Anhaltspunkt liefern, wenn man Performanceprobleme beobachtet. Da hast Du wohl eher den Performancekiller gefunden Um dich sinngemäß zu zitieren: Das hängt wohl vom konkreten Workload ab. Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.