vmware esxi erfahrung

ich hatte auch schon snapshot probleme weil ich zu nah am limit war, hatte beim ersten versuch auch nur 1mb blocksize eingestellt, die vdisks auf 255gb und konnte nichtmehr snapshotten weil dann ja der ram mitgezählt wird....

hat mich ordentlich genervt.

ich hab ein raid10 mit 4 wd black laufen mit bis zu 5 vms, backup läuft über ghettovcb script auf ein iscsi target. -> bin zufrieden, performance passt.
mit veeam bin ich nicht warm geworden.
 
hmm dann muss also erstmal die option 2mb getestet werden um zu schauen, was da bei rumkommt..
bock hab ich ja nicht gerade auf die chose aber "watt mutt datt mutt"
 
greyz schrieb:
mit veeam bin ich nicht warm geworden.
Zum Vergrößern anklicken....

Habe es vor einem Jahr verwendet weil mir zu viele Leute gesagt hatten das es besser als BackupExec funktioniert. In meiner aktuellen Firma verwenden wir allerdings BE und ich finde es super. Einzig die Wiederherstellung einzelner Dateien ist gefühlt langsamer. Aber vielleicht bilde ich mir das nur ein....

@bachmayeah wir haben auf allen Datastores 4 MB block size. Die sind 2 * 1,2 TB und 1 * 1,6 TB groß.
Wenn du 500 KB Daten hast muss er aber 4 MB lesen/schreiben.
http://communities.vmware.com/thread/144240 wenn ich das hier alles richtig verstehe. Einen Performance Unterschied habe ich bisher noch nicht feststellen können. Aber vielleicht betreiben wir dafür zu wenig VM´s...

Gruß Stephan
 
mal, schauen, werde eine platte einbauen und testen.
aber ich verstehs immer noch nich wirklich.
und der fakt, dass du keinen unterschied in der performance gemerkt hast... macht mich auch nicht glücklicher :D
wobei.. naja die performance der maschine an sich war ja okay.. nur darauf kopieren nicht..
 
Schau dir mal die aktuellen Netzwerkeinstellungen an, klingt sehr danach, dass die autonegotiation nicht richtig funzt und deine NIC im 100MBit Halfduplex betrieb läuft.

Wenn autoneg auf 1GBit nicht geht, force einfach auf Fullduplex und teste nochmal.
 
er bekommt ja nichtmal innerhalb der vm sinnvolle kopiergeschwindigkeiten bei großen files hin, wär seltsam wenn das am netzwerk liegt....
 
Oh sry, hab nicht alles genau durchgelesen. Würds aber trotzdem mal überprüfen, nicht dass da mehrere Probleme zusammenhängen
 
korrekt ;) übers Netzwerk auf in die vm eingebundene vm ginge ja relativ gut...
auf ne platte im datastore dauert es mehrere stunden für ne 16 gig Datei die im Netzwerk innerhalb von 10 Minuten kopiert wird...
switch vm und quellserver waren letzten Endes komplett auf 1Gb/s eingestellt...
 
Haben heute nen 2xXeon hp Server mit 6 gig RAM mit esxi 4.1 aufgesetzt.
Selbes Netzwerk. Dauer beim übertragen der bereits erwähnten 16 gb Datei auch bei verschiedenen Blocksizes 1-8Mb nie so performant wie im "echten" netz. 10 Minuten stehen da mindestens dem 3-4 fachen gegenüber.
Trotz schnellerer Platten .
Kann doch iwie nicht sein. Bin da relativ ratlos... Morgen wird mal esxi 5 angetestet..
 
bachmayeah schrieb:
... verschiedenen Blocksizes 1-8Mb nie so performant wie im "echten" netz. 10 Minuten stehen da mindestens dem 3-4 fachen gegenüber.
Trotz schnellerer Platten .
Zum Vergrößern anklicken....

Soll heißen der HP Server benötigt 30-40 Minuten und dein eigentlicher Server brauch für die 16 GB 10 Minuten?
Hattest du beide Server am selben Switch angeschlossen? Hat der HP ESX automatisch einen 1 G/Bit Link zum Netzwerk erkannt?
Welches Raid-Level hast du im HP Server eingerichtet?

Gruß Stephan
 
CC-Freak schrieb:
Mal kurz andere Frage ich mache gerade Aubildung im IT Bereich und ich suche noch ein Platz für ein 3 Wöchiges Praktikum im Sommer hat da jemand von euch in der Firma diese Möglichkeit ??
Zum Vergrößern anklicken....

Unsere Firma ist ca. 500 KM von dir entfernt...
Am besten verfolgst du mal den Beitrag und schaust nach den angesprochenen Punkten bei dir am Server.

Gruß Stephan
 
StephanR1 schrieb:
Soll heißen der HP Server benötigt 30-40 Minuten und dein eigentlicher Server brauch für die 16 GB 10 Minuten?
Hattest du beide Server am selben Switch angeschlossen? Hat der HP ESX automatisch einen 1 G/Bit Link zum Netzwerk erkannt?
Welches Raid-Level hast du im HP Server eingerichtet?

Gruß Stephan
Zum Vergrößern anklicken....

wie gesagt von hardwareserver zu hardware client ~10 Minuten für 16 GB
von hardwaresever zu vm auf dem abgegriffenen hp proliant server mit 10k platten und raid 5 bei verschiedenen blocksizes locker 40 minuten.
von hardwareserver auf unseren echten esxi definitiv wesentlich länger (auch raid 5).
derzeit wird ein esxi5 zwecks test aufgesetzt.
ich glaube aus div. foren gezogen zu haben, dass der esxi 4 allgemein nicht der schnellste ist.
aufsetzen einer vm (sowohl in unserem echten esxi als auch in unserem hp-test esxi geht zügig.)
 
ai will try...
derzeit kopier ich die datei von hardwareserver auf vm innerhalb des esxi 50 systems seit 09:52 - also schon gut doppelt so lange wie es mMn laufen sollte.

im übrigen: esxi 5.0 mit neuem aktuellerem datastorage bringts auch keine besserung, angestoßen um 11:19 (vor 15 minuten) und hat ca die hälfte.

aktuell mit veeam backup ist die rate auf dem hp mit esxi 5 aktuell bei 38 MB/s.

bei mir unter win7x64 wars ja die 16 gigdatei bei knapp 30 MB/s afair
beim esxi 4.1 live system mit laufenden vm´s waren es lummelige 3MB/s.

jetzt wird geschaut, ob es auf dem anderen server auch unter 4.1 zügig läuft.
sollte das so sein, liegts wohl am server iwo.

andere Vorschläge sind willkommen..

so um hier noch ein wenig vor mich hinzuspammen:

vorhin ja versucht ne 60gig platte via veeam vom echt-esxi 4.1 auf meinen win7x64 system zu kopieren --> 3 MB/s
nun versuch ich ne 20 gig platte platte via veeam vom echt-esxi 4.1 auf meinen win7x64 system zu kopieren --> 14-18 MB/s

--> ???

und zur ergänzung: auf dem hp raid 5 server mit den schnelleren platten auf dem esxi 5.0 lief wurde nun esxi 4.1 installiert -> transfrerrate von 10 MB/s


fazit(?): 5.0 scheint evtl schneller zu ein | auf dem esxi schwankt die rate je nach dateigröße (bzgl. rate reden wir aktuell nur von veeam-raten)
 
Zuletzt bearbeitet:
Beim HP sind es keine Traumwerte aber der FSC ist grauenvoll. Da ist meine Internetanbindung schneller :D
Die 38 MB/s beim HP sind vom Server auf deinen PC/Notebook oder vom PC auf den Server?
Ich hatte bei meinem alten Lenovo R61 mit einer 7200 U/Min HDD max. 27 MB/s vom Server auf das Notebook. Selber Server anderer Client ging es mit 85-90 MB/s...
Hast du zum Spaß einen anderen Switch zwischen HP Server und Client gehangen?

Gruß Stephan
 
StephanR1 schrieb:
Beim HP sind es keine Traumwerte aber der FSC ist grauenvoll. Da ist meine Internetanbindung schneller :D
Die 38 MB/s beim HP sind vom Server auf deinen PC/Notebook oder vom PC auf den Server?

Die sind via Veeam vom Server auf meinen PC

Ich hatte bei meinem alten Lenovo R61 mit einer 7200 U/Min HDD max. 27 MB/s vom Server auf das Notebook. Selber Server anderer Client ging es mit 85-90 MB/s...
Hast du zum Spaß einen anderen Switch zwischen HP Server und Client gehangen?

Nope, generell geht mir so langsam auch de Spass aus :D

Gruß Stephan
Zum Vergrößern anklicken....


meine idee war nun: 2. esxi 4.1 aufsetzen und vms dort auslagern.
auf dem livehost esxi 5.0 mit neuerem datastore aufsetzen und testen bzw. hoffen, dass es dort zu einer besseren, halbwegs vertretbaren performanz kommt... :heul:
 
Zuletzt bearbeitet:
einfache platte reingehängt und als datastore hinzugefügt ; datei geht relativ zügig rüber.
platten zu langsam oder raid controller? mal ein raid 1 versuchen?
 
Welche VM Version hast du jetzt auf dem FSC laufen? Noch 4.1?
Hängen die Platten am FSC D2616 Controller oder an dem (in nehme an) OnBoard Controller?
Zu dem D2616 gibt es bei FSJ ein Firmwareupdate --> ob es das besser macht kann ich dir nicht sagen. Ich ziehe immer die Systeme auf einen aktuellen Stand und dann gehts weiter...
http://support.ts.fujitsu.com/Download/ShowFiles.asp?LNG=DE
Dort gibt es auch von FSC angepasste VM Images. Da sind z.B. Controllertreiber eingebunden.
Wenn du das nicht magst findest du hier
http://downloads.vmware.com/d/details/esx4_lsi_megaraid_dt/ZHcqYnRlcHBidGR3#version_history
oder hier
http://downloads.vmware.com/d/details/dt_esxi50_lsi_2108_v534/dHRAYnRqZWRiZHAlJQ==
LSI Treiber bei VmWare. Wie bei FSC beschrieben baut der D2616 auf den LSI Chip 2108 auf.
Wenn du die FW am Controller flasht würde ich alle Platten abziehen.

Auf welchem Weg wurde das Raid erstellt? Bei Adaptec gibt es da verschiedene Modi und laut Adaptec wirkt sich der gewählte Modi auf die Schreibgeschwindigkeit aus. Falls du sowas wie "quick init" verwendet hast kannst du built/verify aber auch nachträglich ausfürhen. Wenn es bei LSI auch solche Modi gibt sollte es mich wundern wenn es nachträglich nicht funktioniert. Ich würde auf jeden Fall dazu die VM´s sichern. Du weißt ja eigentlich und sollte....
http://ask.adaptec.com/scripts/de_a...td_adp.php?p_faqid=10267&p_created=1065098797

Gruß Stephan
 
danke für dein feedback
mittlerweile läuft 5.0 von der vmware Seite.
die originalplatten hängen im raid 5 verband am d2616 controller.
dann wurde das dvd lw abgezogen und daran eine "normale" sata platte abgezogen.
diese dann ganz einfach als datastore im esxi angelegt, vm installiert, kopiert. 20 Minuten (ist annehmbar, wenn auch nicht die 10 Minuten die es im normalen netz dauert)
raid Controller sollte wohl auch up2date sein. das raid wurde über den integrierten wizard erstellt, wie es teilweise auch hier(Bild ist nicht von mir) zu sehen ist.
derzeit sind die vm´s schon ausgelagert auf nen potenten client pc und der fuji steht für weitere tests bereit.

kurze frage:
http://support.ts.fujitsu.com/Downl...NID=1&intlevel2=84957&intFehlercode=0&NavIDs=

was ist denn der unterschied zwischen installable oder embedded?

derzeit tendiere ich dazu den Fujitsu Custom Offline Bundle ESXi 5.0 anzutesten...
 
Zuletzt bearbeitet:
bachmayeah schrieb:
was ist denn der unterschied zwischen installable oder embedded?
Zum Vergrößern anklicken....
http://communities.vmware.com/message/1710273

Bei der Firmware vom Controller wäre ich mir nicht so sicher, die FW auf der FSC Seite ist vom 14.12.2011, also noch recht frisch. Auf welchem Weg das Raid erstellt wurde könntest du noch klären. Bei Adaptec gibt es eine Boot CD um alles sehr angenehm zu verwalten. Wobei das Raid Setup ohne die CD auch Narrensicher ist. Schau dir das mal an.

Gruß Stephan
 
hi,

das von dir beschriebene phänomen rührt definitiv von der platten. ideal ist eine getrennte umgebung (wo du ja mittlerweile bist) von wenigstens einer platte bpsw. am boardcontroller für die esxi-installation und einem weiteren (pci-e) controller mit nem raid für die vms.

im teureren bereich nutzen wir lokale hp-server mit fibre-channel oder iscsi-anbindung an bspw. eine voll bestückte msa-2000 inkl dualcontroller, ordentlich cache und natürlich nem batterypack.

solls etwas weniger kosten installier deinen esxi auf die lokale platte des fujitsu-servers und besorg dir ne vernünftige nas die iscsi-fähig ist (bpsw. thecus n4200eco). darein die ganzen platten, im esxi5 eingebunden (iscsi läuft da mittlerweile sehr gut) und die vms drauf.

noch billiger ginge es mit nem eigenbau nas und nem software-iscsi-tagetserver. als basis hierfür kann man nen alten proliant ml nehmen mit schnellen platten, win7 drauf, bspw. starwind drauf und schon hat man nen iscsi-server der zw. 20 und 50 mb/sec durchpumpt...

alles eine frage des geldes :cool:
 
enable mal den "write cache" auf deinem Raidcontroller. Der müsste im default eingetlich auf disable stehen.
denke aber, das deine Platten den kram nicht schnell genug wegschreiben.

welche switche setzt du ein. wenn cisco, dann kontrolliere mal die Portgeschwindigkeiten. Vielleicht mal kein "auto" verwenden.


Bei der s6 kannste die "normale" ESXi Version von VMware nehmen. Da sind alle Treiber drauf.
Brauchste nichts von FSC nehmen.
 
im raid1 gings gut, raid 5 wieder im us- mode -> UltraSlow ;)
cache auch von den platten aktivieren?

tipps bzgl:

• Write Policy: Specify the write policy for this virtual drive:
◊
◊
Note:
Write back: In this mode the controller sends a data transfer completion signal to the host when the controller cache has received all of the data in a transaction. This is the default.
Write through: In this mode the controller sends a data transfer completion signal to the host when the disk subsystem has received all of the data in a transaction.
The Write Policy depends on the status of the battery backup unit (BBU). If the BBU is not present or is bad, then the Write Policy will be Write through.


Access Policy: Select the type of data access that is allowed for this virtual disk.
◊ Read/Write: Allow read/write access. This is the default.
◊ Read Only: Allow read-only access.
◊ Blocked: Do not allow access.

read/write solute klar seine.
• Disk Cache Policy: Select a cache setting for this disk:
◊ Enable: Enable the disk cache. This is the default.
◊ Disable: Disable the disk cache.
◊ Unchanged: Leave the current disk cache policy unchanged.

• Stripe Size: Stripe sizes of 8, 16, 32, 64, and 128 Kbytes are supported. For more information, see the striping Glossary entry. The default is 64 Kbytes.
geht bei uns auch bis zu 1MB

• Read Policy: Specify the read policy for this virtual drive:
◊ Always read ahead: Read ahead capability allows the controller to read sequentially ahead of requested data and to store the additional data in cache memory, anticipating that the data will be needed soon. This speeds up reads for sequential data, but there is little improvement when accessing random data.
◊ No read ahead: Disables the read ahead capability. This is the default.
◊ Adaptive read ahead: When selected, the controller begins using read ahead if the two most recent disk accesses

schnelle oder vollständige Initialisierung?
 
Bitte beachte unsere Verhaltensregeln beim Antworten. Danke 🙂

Ähnliche Themen

crossie
a little story... or how to produce a bikemovie
2
Antworten
40
Aufrufe
8K
P.h.o.e.n.i.x
P.h.o.e.n.i.x
Zurück