Hallo ich bin ESX-Neuling und hätte eine Frage:
worauf kommt es bei der Dimensionierung eines ESX-Servers in erster Linie an. Auf CPU-Leistung oder auf den RAM.
Habe in der Anschaffung die Auswahl zwischen zwei Servertypen, einmal mit zwei 3,6GHz-Prozessoren und 4 GB RAM und einen anderen mit zwei 2,6GHz Prozessoren und 6GB RAM. Beide basieren auf der selben HW-Plattform und haben nur unterschiedliche Prozessorhersteller.
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Dimensionierung RAM und CPU-Leistung
...immer diese allgemeinen fragen.
aber klare antwort: kommt drauf an.
´s einfachste wird sein du guckst dir an, was auf den esx soll. also welche phys.Server willst du migrieren...oder neu aufsetzen...dann hast du ja schon mal´n grobes lastprofil.
wenn das auch nicht zum ziel führt ist einfacher zusätzlich ram in die 3.6Kiste zu stecken, also neue prozessoren in die 2.6Kiste. davon abgesehen, daß du dann 2cpus übrig hast.
ich hoffe du kannst mit dieser ersten näherung zu deinem problem was anfangen.
grüße thorsten
aber klare antwort: kommt drauf an.
´s einfachste wird sein du guckst dir an, was auf den esx soll. also welche phys.Server willst du migrieren...oder neu aufsetzen...dann hast du ja schon mal´n grobes lastprofil.
wenn das auch nicht zum ziel führt ist einfacher zusätzlich ram in die 3.6Kiste zu stecken, also neue prozessoren in die 2.6Kiste. davon abgesehen, daß du dann 2cpus übrig hast.
ich hoffe du kannst mit dieser ersten näherung zu deinem problem was anfangen.
grüße thorsten
zur kalkulation:
ich bin hin gegangen und hab mal messungen gemacht zu unserem Exchange, DC, und Fileserver. Daran hab ich dann meine Dimensionierung gemacht. Grundsätzlich habe ich alle Maschinen so gekauft dass ich immer noch zusätzlich CPU's und RAM hinzufügen kann.
Beispiel: HP DL580 gekauft mit 8GB Ram und 2 Proz. Erweitern kann ich den DL580 auf 4 Proz und 32GB Ram.
Hier nun meine Messergebnisse bei ca. 900 Benutzer:
Exchange2003 Entp.: 15-25% eines 3,0GHz CPU
DC2003: 5-8% eines 2,8 GHz CPU
FileServer: 25-35% GHz
Das ganze ist natürlich immer noch davon abhängig wieviel Mails verschickt werden, wie häufig der Mailserver verwendet wird und so weiter. Die Werte sind gut bemessen.
-bas-
Beispiel: HP DL580 gekauft mit 8GB Ram und 2 Proz. Erweitern kann ich den DL580 auf 4 Proz und 32GB Ram.
Hier nun meine Messergebnisse bei ca. 900 Benutzer:
Exchange2003 Entp.: 15-25% eines 3,0GHz CPU
DC2003: 5-8% eines 2,8 GHz CPU
FileServer: 25-35% GHz
Das ganze ist natürlich immer noch davon abhängig wieviel Mails verschickt werden, wie häufig der Mailserver verwendet wird und so weiter. Die Werte sind gut bemessen.
-bas-
VMWare Sizer
Hallo, auf der amerikanischen HP Seite gibt es einen VM Sizer bei welchem du die zu migrierenden Server (HW CPU Auslastung /RAM Auslastung / Disk IO) angeben kannst und dir der Sizer danach den richtigen Zielserver angibt. Bei mir hätte ich 18 DL380 G1/G2 auf zwei neue DL380 G4 oder alle auf einen DL585 mit 4 CPUs migrieren können.
Re: VMWare Sizer
stephan hat geschrieben:Hallo, auf der amerikanischen HP Seite gibt es einen VM Sizer bei welchem du die zu migrierenden Server (HW CPU Auslastung /RAM Auslastung / Disk IO) angeben kannst und dir der Sizer danach den richtigen Zielserver angibt. Bei mir hätte ich 18 DL380 G1/G2 auf zwei neue DL380 G4 oder alle auf einen DL585 mit 4 CPUs migrieren können.
Coole Sache....wenn ich es nur finden würde....
Hat jemand nen link ?
Danke und greez
Franci
Standardantwort: "im Prinzip ja" aber...wenn dein 32bit-rechenknecht die EM64T-Funktion kann, dann kann er auch mehr als 32Bit (also 4GB speicher verwalten).
wenn ich allerdings länger drüber nachdenke...wir haben bei uns´ne 8wege kiste mit 16gb ram...ein win2003 mit irgendso´nem erweiterungsfeature kann auch mehr als 4gb verwalten.
das wird wohl daran liegen, daß die hardware zwar mehr als 16gb zu verfügung stellt...diese dann über segment und pagetabellen angesprochen werden kann, aber die software (also ein anwendungsprogramm; ein Prozess; ein dienst) nur max 4GB selbst ansprechen kann.
grüße thorsten
wenn ich allerdings länger drüber nachdenke...wir haben bei uns´ne 8wege kiste mit 16gb ram...ein win2003 mit irgendso´nem erweiterungsfeature kann auch mehr als 4gb verwalten.
das wird wohl daran liegen, daß die hardware zwar mehr als 16gb zu verfügung stellt...diese dann über segment und pagetabellen angesprochen werden kann, aber die software (also ein anwendungsprogramm; ein Prozess; ein dienst) nur max 4GB selbst ansprechen kann.
grüße thorsten
tja...der ESX ist halt clever...wir haben hier ´ne 32GB kiste rumstehen...mit der kann der ESX ohne probleme...nur die Gäste bekommen nur max.4gb (also 3.6GB + overhead). der esx mapped dann die pages (4k-blöcke) jedes gastes auf einen freien bereich im realen speicher...der gast denk er hätte linearen speicher von 0 bis 3.6GB...diese seiten können aber physikalisch quer durch den realspeicher liegen. (konzept: virtueller speicher). so kann esx auch page-sharing machen...zwei pages der gäste kommen auf einer physikalischen seite zum liegen. braucht man halt segment/page-tabellen. aber das hat jedes vernünftige betriebssystem an bord.
grüße thorsten
grüße thorsten
Ich würde sagen: je mehr RAM desto besser die Performance.
Ich beschreibe es mal an einem praktischen Beispiel:
wir haben´ne ibm x445 mit 8x2ghz cpus und 24gb ram. auf der laufen 40gäste. u.a. auch 3fileserver. wir haben ca. 1000user am tag die sich mit den fileservern connecten. Alle gäste (produktion+test) zusammen verbraten ca.43GB RAM. Durch Memory-Sharing (ShareScanTotala=10000 ;ShareScanVM=1000) kommt diese Maschine mit den 24GB Real-Speicher aus.
Nachteil: sowohl der gesamt CPU-Bedarf als auch die Latenzzeiten steigen. Da der ESX Speicherseiten zusammenfaßt (ShareScan-Option) muß er bei Änderungen am Seiteninhalt (User meldet sich irgendwo neu an; Sicherungen starten; alles was sich am statischen Verhalten eines VM-Gastes ändert) erst mal neue Seiten suchen, diese vielleicht durch Auslagern alter Seiten befriedigen; oder ungenutzten Speicher dafür reservieren. Auf jeden Fall muß der ESX dafür Code durchlaufen, der diese Aufgabe übernimmt. Und das dauert. Man kann sich vorstellen, daß das länger dauert, als wenn der Speicher schon vorhanden und nutzbar wäre.
Deshalb meine Aussage: je menr Speicher, desto besser die Performance.
Auf der anderen Seite darf man dabei aber auch nicht den Kostenfaktor aus den Augen verlieren. Viel RAM kostet viel Geld.
Nicht vergessen sollte man, daß beispielsweise der BetriebssystemCode der Gäste (angenommen gleicher Patch-Level, gleiches Betriebssystem) identisch ist.
Um auf deine Frage zurückzukommen:
wenn du Server hast, die immer das Gleiche machen, wenig Schwankungen hinsichtlich ihres RAM-Bedarfs haben, dann kommst du mit "wenig RAM" aus...wenn du allerdings einen sehr dynamischen Workload hast, und auf beste Antwortzeiten angewiesen bist, dann hilft nur eins: viele SpeicherChips kaufen.
Grüße Thorsten
Ich beschreibe es mal an einem praktischen Beispiel:
wir haben´ne ibm x445 mit 8x2ghz cpus und 24gb ram. auf der laufen 40gäste. u.a. auch 3fileserver. wir haben ca. 1000user am tag die sich mit den fileservern connecten. Alle gäste (produktion+test) zusammen verbraten ca.43GB RAM. Durch Memory-Sharing (ShareScanTotala=10000 ;ShareScanVM=1000) kommt diese Maschine mit den 24GB Real-Speicher aus.
Nachteil: sowohl der gesamt CPU-Bedarf als auch die Latenzzeiten steigen. Da der ESX Speicherseiten zusammenfaßt (ShareScan-Option) muß er bei Änderungen am Seiteninhalt (User meldet sich irgendwo neu an; Sicherungen starten; alles was sich am statischen Verhalten eines VM-Gastes ändert) erst mal neue Seiten suchen, diese vielleicht durch Auslagern alter Seiten befriedigen; oder ungenutzten Speicher dafür reservieren. Auf jeden Fall muß der ESX dafür Code durchlaufen, der diese Aufgabe übernimmt. Und das dauert. Man kann sich vorstellen, daß das länger dauert, als wenn der Speicher schon vorhanden und nutzbar wäre.
Deshalb meine Aussage: je menr Speicher, desto besser die Performance.
Auf der anderen Seite darf man dabei aber auch nicht den Kostenfaktor aus den Augen verlieren. Viel RAM kostet viel Geld.
Nicht vergessen sollte man, daß beispielsweise der BetriebssystemCode der Gäste (angenommen gleicher Patch-Level, gleiches Betriebssystem) identisch ist.
Um auf deine Frage zurückzukommen:
wenn du Server hast, die immer das Gleiche machen, wenig Schwankungen hinsichtlich ihres RAM-Bedarfs haben, dann kommst du mit "wenig RAM" aus...wenn du allerdings einen sehr dynamischen Workload hast, und auf beste Antwortzeiten angewiesen bist, dann hilft nur eins: viele SpeicherChips kaufen.
Grüße Thorsten
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 4 Gäste