Hallo,
mein ESXi 5 lief jetzt einige Wochen problemlos. Nun fehlte mir aber plötzlich ein datastorage, anschließend gingen einige VMs auf einem anderen DS flöten.
Thomas Krenn Server, SuperMicro Board, 3ware 9650 SATA-Kontroller.
DS1: WD Raptor als einzelne Platte
DS2: WD Raptor als einzelne Platte
DS3: 2 x 500GB als RAID0 für Sicherungen. Waren übrig, RAID0 weils als schneller Zwischenspeicher dienen sollte.
DS4 ist ein gemountetes NAS-Laufwerk für die Sicherung, NFS
DS5 ist eine 2 TB Platte angeschlossen über den onboard SATA Controller (MCP55)
Eine 64GB SSD an onboard SATA als HostCache
nun war also plötzlich das DS3 weg. Anschließend sind VMs auf dem DS1 und DS2 plötzlich mehrfach abgestürzt, liefen instabil, bis gar nichts mehr ging.
- habe einzelne Bemerkungen zum 9650 gefunden, die den Controller für problematisch und instabil in Zusammenhang mit dem ESXi halten. Ist da was dran?
- in der vmkernel.log finde ich Meldungen darüber, dass der swaps nicht angelegt werden konnten. Failed to extend swap....
Die SSD läuft als Hostcache. Nun hatte ich vor ein paar Tagen den Speicherort der VM-Auslagerungsdatei auf die SSD gelegt. Allerdings die Tage danach keinerlei Probleme festgestellt.
- finde auch mal Einträge zum 9650, dass die BBU zu heiß wäre. Kann da lokal aber nichts feststellen.
Wie kann ich das Problem/mehrere Probleme näher eingrenzen? Kann es auch an den Einstellungen des 9650 liegen? Performance, Cache aktiviert usw.
Viele Grüße
Alex
Hier ist die Logdatei:
http://ifile.it/8zracm1/vmkernel.log
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!
3W9650 RAID-Controller defekt? Lokalisation des Problems
Hallo,
[Edit: Controller verwechselt.]
Das Unangenehme an diesem Modell ist, dass es nach meinem Wissen weder einen CIM-Provider noch ein Kommandozeilen-Tool zur Wartung gibt. Wenn du also den Status des Contollers/RAID0 überprüfen willst, musst du die Maschine neu starten und im 3Ware-BIOS nachschauen.
Edit2: Ist die neueste Firmware (4.10.00.021) auf dem Controller?
[Edit: Controller verwechselt.]
Das Unangenehme an diesem Modell ist, dass es nach meinem Wissen weder einen CIM-Provider noch ein Kommandozeilen-Tool zur Wartung gibt. Wenn du also den Status des Contollers/RAID0 überprüfen willst, musst du die Maschine neu starten und im 3Ware-BIOS nachschauen.
Edit2: Ist die neueste Firmware (4.10.00.021) auf dem Controller?
Windows in VM?
kann ein Windows in einer VM auch darauf zugreifen? (wie ist der Zugriff zwischen Software und Raid-Controller technisch gelöst?)
Der direkte Zugriff wäre eine Verletzung der Trennung von virtueller und realer Hardware, die nur in beabsichtigter Form (DirectPath I/O) erlaubt ist.
Wie ich dies verstanden habe: In modernen Betriebssystemen wird die Hardware über Treiber (bzw. Kernel-Module) und HALs abstrahiert, so dass man keinen direkten Zugriff auf die Hardware hat. Die Software steuert dann die Hardware über Systemaufrufe (system calls) des Betriebssystems bzw. Treibers. Der direkte Zugriff auf Hardware (über Ports und Speicherbereiche) ist nicht völlig ausgeschlossen, aber sehr selten.
Wie ich dies verstanden habe: In modernen Betriebssystemen wird die Hardware über Treiber (bzw. Kernel-Module) und HALs abstrahiert, so dass man keinen direkten Zugriff auf die Hardware hat. Die Software steuert dann die Hardware über Systemaufrufe (system calls) des Betriebssystems bzw. Treibers. Der direkte Zugriff auf Hardware (über Ports und Speicherbereiche) ist nicht völlig ausgeschlossen, aber sehr selten.
-
Dayworker
- King of the Hill
- Beiträge: 13659
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
SATA wird offiziell von VMware nicht unterstützt, da es für den Businessbetrieb nicht über ausreichende Performance und Zuverlässigkeit verfügt.
Zur Datensicherheit einer einzelnen Platte oder einem Raid0 als DS brauchen wir wohl auch keine Worte mehr zu verlieren.
In die selbe Richtung tendiere ich zu deinem MCP55-Controller. nVidia-Chipsätze waren schon im normalen Desktopbetrieb nie ganz unproblematisch, litten unter ihrer lahmen PCI-Performance und waren von den relativ unkomplizierten AMD-/Intel-Chipsätzen meilenweit entfernt. Weshalb du noch einen Host-Cache über den Chipsatz eingerichtet hast, erschließt sich mir auch nicht. Ich wüßte nicht, daß nVidia jemals eine GC (Garbadge Collection) in seine SATA-Controller integriert hatte. Dazu sind deren Chipsätze einfach zu alt und SSDs ein extrem teurer Wunsch.
Vermutlich hat dein Server aber aufgrund von RAM-Mangel dann doch mal die SSD nutzen wollen und ist mangels Platz oder auch dem reinen Zugriff (SATA3-Gerät an SATA1-Controller) darauf gescheitert. Die Warnung "WARNING: Swap: 5495: Failed to extend swap file from 0 KB to 2097152 KB" erscheint ja mehrfach. Möglich wäre auch, daß der Host-Cache umfangreicher genutzt und die SSD komplett beschrieben wurde. Falls dem so sein sollte, brechen viele SSD auch schon mal auf 1/10tel der Ursprungsschreibperformance ein. Ob der ESXi diesen Performance-Einbruch in Form von hoher Schreiblatenz geloggt hat, habe ich auf die Schnelle nicht gesehen.
Zur Datensicherheit einer einzelnen Platte oder einem Raid0 als DS brauchen wir wohl auch keine Worte mehr zu verlieren.
In die selbe Richtung tendiere ich zu deinem MCP55-Controller. nVidia-Chipsätze waren schon im normalen Desktopbetrieb nie ganz unproblematisch, litten unter ihrer lahmen PCI-Performance und waren von den relativ unkomplizierten AMD-/Intel-Chipsätzen meilenweit entfernt. Weshalb du noch einen Host-Cache über den Chipsatz eingerichtet hast, erschließt sich mir auch nicht. Ich wüßte nicht, daß nVidia jemals eine GC (Garbadge Collection) in seine SATA-Controller integriert hatte. Dazu sind deren Chipsätze einfach zu alt und SSDs ein extrem teurer Wunsch.
Vermutlich hat dein Server aber aufgrund von RAM-Mangel dann doch mal die SSD nutzen wollen und ist mangels Platz oder auch dem reinen Zugriff (SATA3-Gerät an SATA1-Controller) darauf gescheitert. Die Warnung "WARNING: Swap: 5495: Failed to extend swap file from 0 KB to 2097152 KB" erscheint ja mehrfach. Möglich wäre auch, daß der Host-Cache umfangreicher genutzt und die SSD komplett beschrieben wurde. Falls dem so sein sollte, brechen viele SSD auch schon mal auf 1/10tel der Ursprungsschreibperformance ein. Ob der ESXi diesen Performance-Einbruch in Form von hoher Schreiblatenz geloggt hat, habe ich auf die Schnelle nicht gesehen.
Empfehlungen...
Hallo Dayworker,
vielen Dank für Deine Kommentare. Einiges davon ist mir bewußt und ist einfach durch das vorhandene Budget so wie es ist. Das RAID0 ist ja nur so ein schneller Parkplatz für Backups mit ghettovcb. Anschließend werden die VMs dann auf das NAS kopiert.
SATA ist nicht offiziell unterstützt? Es gibt doch aber haufenweise unterstützte Controller für ESXi in der HCL!?
Der 9650 ist kein top Teil. Allerdings kann ich mit nach 4jährigem Betrieb darauf, WindowsXP, VMware Server 2.0...nicht vorstellen, dass ein Datastore darauf mit wirklich geringer Last keine 6 Wochen durchhält und dass die Probleme auch auf mehreren LDs entstehen. Daher vermute ich andere Konfigurations- oder Hardwarefehler. Es laufen ein Eisfair Linuxserver und 2 Windows Server für Dokumentenmanagement (mit MySQL) und diverse Serverdienste, insgesamt ein Netz mit 12 Workstations. WinXP mit VMware Server 2.0 waren dafür ok auf der Hardware.
Dass der MCP55 Pro Spielzeug ist hätte ich in einem Supermicro Serverboard nicht unbedingt erwartet. Hatte im 4jährigen Betrieb unter WindowsXP damit keinerlei Probleme. Insgesamt scheine ich für ESXi aber einfach nen fetten Controller zu brauchen, egal wie.
300 GB für die VMs würden mir aktuell reichen, sprich 2 x 300 GB SAS-HDs. Als Alternative hab ich mit auch schon überlegt SSDs zu nehmen. Crosair PP oder andere für Server geeignete. Aber dafür ist der 9650 ungeeignet, weil kein SATA3.
Im Handbuch steht, dass die onboard SATA2 mit 3GB/s wären. Könnte die SSD als HostCache am SATA2 das Problem ausgelöst haben? Werde ich rausnehmen und testen. Allerdings hätte ich trotz begrenztem Maximaldurchsatz dadurch eine verbesserte Performance durch die kurzen Zugriffszeiten erwartet. Wieviel der Kapazität sollte maximal fürs Caching freigegeben werden? Eine Lösung für fehlendes TRIM gibt es wohl auch nicht...!?
Das H8DME-2 hat PCIe8x, allerdings finde ich keine Angabe zur Version. Gibt es einen vernünftigen RAID-Controller, der hier noch passt, aber auch in einem neuen Server in 1-2 Jahren Sinn machen würde?
SAS oder SSD? Hostcaching...(SSD-Caching über den Controller, OCZ Revodrive, MegaRAID CacheCade Pro 2.0 Software....alles Spielzeug?)
Vermutlich geht nix über ein SAS RAID1, ggf. mit SSD für Hostcaching,an nem SATA3-Controller
Gruß
Alex
vielen Dank für Deine Kommentare. Einiges davon ist mir bewußt und ist einfach durch das vorhandene Budget so wie es ist. Das RAID0 ist ja nur so ein schneller Parkplatz für Backups mit ghettovcb. Anschließend werden die VMs dann auf das NAS kopiert.
SATA ist nicht offiziell unterstützt? Es gibt doch aber haufenweise unterstützte Controller für ESXi in der HCL!?
Der 9650 ist kein top Teil. Allerdings kann ich mit nach 4jährigem Betrieb darauf, WindowsXP, VMware Server 2.0...nicht vorstellen, dass ein Datastore darauf mit wirklich geringer Last keine 6 Wochen durchhält und dass die Probleme auch auf mehreren LDs entstehen. Daher vermute ich andere Konfigurations- oder Hardwarefehler. Es laufen ein Eisfair Linuxserver und 2 Windows Server für Dokumentenmanagement (mit MySQL) und diverse Serverdienste, insgesamt ein Netz mit 12 Workstations. WinXP mit VMware Server 2.0 waren dafür ok auf der Hardware.
Dass der MCP55 Pro Spielzeug ist hätte ich in einem Supermicro Serverboard nicht unbedingt erwartet. Hatte im 4jährigen Betrieb unter WindowsXP damit keinerlei Probleme. Insgesamt scheine ich für ESXi aber einfach nen fetten Controller zu brauchen, egal wie.
300 GB für die VMs würden mir aktuell reichen, sprich 2 x 300 GB SAS-HDs. Als Alternative hab ich mit auch schon überlegt SSDs zu nehmen. Crosair PP oder andere für Server geeignete. Aber dafür ist der 9650 ungeeignet, weil kein SATA3.
Im Handbuch steht, dass die onboard SATA2 mit 3GB/s wären. Könnte die SSD als HostCache am SATA2 das Problem ausgelöst haben? Werde ich rausnehmen und testen. Allerdings hätte ich trotz begrenztem Maximaldurchsatz dadurch eine verbesserte Performance durch die kurzen Zugriffszeiten erwartet. Wieviel der Kapazität sollte maximal fürs Caching freigegeben werden? Eine Lösung für fehlendes TRIM gibt es wohl auch nicht...!?
Das H8DME-2 hat PCIe8x, allerdings finde ich keine Angabe zur Version. Gibt es einen vernünftigen RAID-Controller, der hier noch passt, aber auch in einem neuen Server in 1-2 Jahren Sinn machen würde?
SAS oder SSD? Hostcaching...(SSD-Caching über den Controller, OCZ Revodrive, MegaRAID CacheCade Pro 2.0 Software....alles Spielzeug?)
Vermutlich geht nix über ein SAS RAID1, ggf. mit SSD für Hostcaching,an nem SATA3-Controller
Gruß
Alex
Hallo,
ich würde dir bei deiner recht kleinen und doch "verbauten" Umgebung die all-in-one-Lösung von GEA empfehlen, hört sich erstmal recht eigenwillig an, aber funktioniert auch mit SATA und billigen Controllern, da das ZFS alle Sicherheitsmechanismen mitbringt und bei einem Mirror-set aus z.B. 6 HDDs + SSD auch die gewünschte Performance bietet.
Hier http://vmware-forum.de/viewtopic.php?t=22164&highlight=allinone und auf der Seite von GEA findest du Infos. Auch solltest du dich über ZFS informieren.
ich würde dir bei deiner recht kleinen und doch "verbauten" Umgebung die all-in-one-Lösung von GEA empfehlen, hört sich erstmal recht eigenwillig an, aber funktioniert auch mit SATA und billigen Controllern, da das ZFS alle Sicherheitsmechanismen mitbringt und bei einem Mirror-set aus z.B. 6 HDDs + SSD auch die gewünschte Performance bietet.
Hier http://vmware-forum.de/viewtopic.php?t=22164&highlight=allinone und auf der Seite von GEA findest du Infos. Auch solltest du dich über ZFS informieren.
Damit dir eine "Host Cache"-SSD wirklich etwas bringt, müssen eine Reihe von Voraussetzungen erfüllt sein:
- Das kombinierte vRAM all deiner Maschinen muss das physikalische RAM deutlich übersteigen (memory overcommitment).
- Die Maschinen müssen im laufenden Betrieb diesen vRAM auch beanspruchen und die konservativen Speicherwiedergewinnungsmechanismen (Balloning etc.) müssen nicht ausreichen, um mit dem physischen RAM auszukommen.
- Dann lagert ESX den Hauptspeicher der VMs auf die Swap-Dateien (*.vswap) auf dem jeweiligen Datastore aus. (Dieser sollte bei allen Maschinen keine SSD sein
).
- Statt dem vswap-File im (langsameren) Datastore benutzt ESXi 5.0 den konfigurierten Platz auf der SSD dafür.
Da der Platz auf der SSD für "Host Cache" fest zugewiesen wird und bleibt, sollte TRIM (zumindest dafür) kein Thema sein.
- Das kombinierte vRAM all deiner Maschinen muss das physikalische RAM deutlich übersteigen (memory overcommitment).
- Die Maschinen müssen im laufenden Betrieb diesen vRAM auch beanspruchen und die konservativen Speicherwiedergewinnungsmechanismen (Balloning etc.) müssen nicht ausreichen, um mit dem physischen RAM auszukommen.
- Dann lagert ESX den Hauptspeicher der VMs auf die Swap-Dateien (*.vswap) auf dem jeweiligen Datastore aus. (Dieser sollte bei allen Maschinen keine SSD sein
).
- Statt dem vswap-File im (langsameren) Datastore benutzt ESXi 5.0 den konfigurierten Platz auf der SSD dafür.
Da der Platz auf der SSD für "Host Cache" fest zugewiesen wird und bleibt, sollte TRIM (zumindest dafür) kein Thema sein.
Host-Caching
Hi thc,
das mit dem Host-Caching hab ich anders verstanden. Ich habe die halbe SSD fürs Hostcaching aktiviert. Des weiteren habe ich den Speicherort für VM-Auslagerungsdatei auch auf die SSD gelegt.
>- Dann lagert ESX den Hauptspeicher der VMs auf die Swap-Dateien (*.vswap) auf dem jeweiligen Datastore aus. (Dieser sollte bei allen Maschinen keine SSD sein Smile ).
Sowohl Linux als auch Windows tun das doch schon viel früher. Macht es Sinn einer VM bewußt die SWAP bzw. Auslagerungsdatei zu deaktivieren?
>- Statt dem vswap-File im (langsameren) Datastore benutzt ESXi 5.0 den konfigurierten Platz auf der SSD dafür.
Wenn Speicherort der Auslagerungsdatei auf "Datenspeicher im selben Speicher..." steht, dann landet das vswapfile im Datastore der VM. Andernfalls eben auf der gewählten SSD. Allerdings nicht im Verzeichnis des Hostcachings, weshalb die Größe des Hostcachings begrenzt werden sollte.
>Da der Platz auf der SSD für "Host Cache" fest zugewiesen wird und bleibt, sollte TRIM (zumindest dafür) kein Thema sein.
Ich dachte Hostaching wird betrieben, indem ähnlich wie bei Hybridlösungen (Synapse, Revodrive...) mehrfach gelesen und geschriebene Daten erstmal über die SSD gepuffert werden und dann in weiteren Schritten wieder mit dem langsameren DS gesynct werden. Liege ich da falsch?
Andernfalls gebe ich Dir absolut recht. Da macht ne SSD nur Sinn als DS bzw. als RAM-Ersatz/Ergänzung.
Gruß
Alex
das mit dem Host-Caching hab ich anders verstanden. Ich habe die halbe SSD fürs Hostcaching aktiviert. Des weiteren habe ich den Speicherort für VM-Auslagerungsdatei auch auf die SSD gelegt.
>- Dann lagert ESX den Hauptspeicher der VMs auf die Swap-Dateien (*.vswap) auf dem jeweiligen Datastore aus. (Dieser sollte bei allen Maschinen keine SSD sein Smile ).
Sowohl Linux als auch Windows tun das doch schon viel früher. Macht es Sinn einer VM bewußt die SWAP bzw. Auslagerungsdatei zu deaktivieren?
>- Statt dem vswap-File im (langsameren) Datastore benutzt ESXi 5.0 den konfigurierten Platz auf der SSD dafür.
Wenn Speicherort der Auslagerungsdatei auf "Datenspeicher im selben Speicher..." steht, dann landet das vswapfile im Datastore der VM. Andernfalls eben auf der gewählten SSD. Allerdings nicht im Verzeichnis des Hostcachings, weshalb die Größe des Hostcachings begrenzt werden sollte.
>Da der Platz auf der SSD für "Host Cache" fest zugewiesen wird und bleibt, sollte TRIM (zumindest dafür) kein Thema sein.
Ich dachte Hostaching wird betrieben, indem ähnlich wie bei Hybridlösungen (Synapse, Revodrive...) mehrfach gelesen und geschriebene Daten erstmal über die SSD gepuffert werden und dann in weiteren Schritten wieder mit dem langsameren DS gesynct werden. Liege ich da falsch?
Andernfalls gebe ich Dir absolut recht. Da macht ne SSD nur Sinn als DS bzw. als RAM-Ersatz/Ergänzung.
Gruß
Alex
Re: Host-Caching
Hi Alex,
Das ist genau doppelt-gemoppelt, siehe die VMWare-Doku.
Du verwechselt das Auslagern innerhalb der VM und außerhalb der VM, Das Auslagern auf der Ebene von ESX geschieht ohne "Wissen" der VM - sie hält ja "ihr" vRAM für "echtes" RAM, das ihr uneingeschränkt zur Verfügung steht, und kann nicht "wissen", dass da "draußen" ein Speicherengpaß herrscht.
Siehe die VMWare-Doku - das SSD-Host-Caching dient als Ersatz für die "langsamen" vswap-Dateien in den "langsamen" Datastores.
Äh - ja. Das "file buffering", das du meinst, findet nur auf Ebene der Betriebssysteme der Server-VMs statt. ESX "sieht", vereinfacht ausgedrückt, selbst nur SCSI-Kommandos der virtuellen SCSI-Hardware.
Gruß
~thc
sambu hat geschrieben:das mit dem Host-Caching hab ich anders verstanden. Ich habe die halbe SSD fürs Hostcaching aktiviert. Des weiteren habe ich den Speicherort für VM-Auslagerungsdatei auch auf die SSD gelegt.
Das ist genau doppelt-gemoppelt, siehe die VMWare-Doku.
sambu hat geschrieben:Sowohl Linux als auch Windows tun das doch schon viel früher. Macht es Sinn einer VM bewusst die SWAP bzw. Auslagerungsdatei zu deaktivieren?
Du verwechselt das Auslagern innerhalb der VM und außerhalb der VM, Das Auslagern auf der Ebene von ESX geschieht ohne "Wissen" der VM - sie hält ja "ihr" vRAM für "echtes" RAM, das ihr uneingeschränkt zur Verfügung steht, und kann nicht "wissen", dass da "draußen" ein Speicherengpaß herrscht.
sambu hat geschrieben:Wenn Speicherort der Auslagerungsdatei auf "Datenspeicher im selben Speicher..." steht, dann landet das vswapfile im Datastore der VM. Andernfalls eben auf der gewählten SSD. Allerdings nicht im Verzeichnis des Hostcachings, weshalb die Größe des Hostcachings begrenzt werden sollte.
Siehe die VMWare-Doku - das SSD-Host-Caching dient als Ersatz für die "langsamen" vswap-Dateien in den "langsamen" Datastores.
sambu hat geschrieben:Ich dachte Hostaching wird betrieben, indem ähnlich wie bei Hybridlösungen (Synapse, Revodrive...) mehrfach gelesen und geschriebene Daten erstmal über die SSD gepuffert werden und dann in weiteren Schritten wieder mit dem langsameren DS gesynct werden. Liege ich da falsch?
Äh - ja. Das "file buffering", das du meinst, findet nur auf Ebene der Betriebssysteme der Server-VMs statt. ESX "sieht", vereinfacht ausgedrückt, selbst nur SCSI-Kommandos der virtuellen SCSI-Hardware.
Gruß
~thc
Beispiel
Hi,
>Siehe die VMWare-Doku - das SSD-Host-Caching dient als Ersatz für die "langsamen" vswap-Dateien in den "langsamen" Datastores.
ok, also macht Host-Caching mittels SSD auf ESXi nur Sinn, wenn die Summe der VMs den physikalischen RAM überschreiten!?
Gibt es andere Verwendungsmöglichkeiten in dem ESXi? Als einzelnes Laufwerk, schnelles Datastore, ok, aber sonst?
ZFS hört sich auch interessant an. Dort würde die SSD als ZIL wohl helfen. Allerdings werde ich jetzt erstmal auf vernünftige SAS-Platten als RAID1 setzen.
Blättere gerade in diversen Servershops herum. 600 GB SAS II Hitachi 3,5" 15k? 2000 GB SAS II Seagate Constellation ES.2 3,5" 7.2k, lieber 2,5" SAS? Welchen Controller? Ein 8 x SAS hat 2 miniSAS-Anschlüsse. Lassen sich SATA und SAS in der Realität so problemlos mischen wie das die Hersteller behaupten?
Adaptec 6805 8x, LSI 9261-8i 8x?
LSI LSI00194 SAS9211-8i Single 8-Port?
DELL PERC 5/i 8-Port?
Wie lassen sich die Controller und alles was dranhängt am ESXi überwachen? Ist das nur an den 3ware ein Problem?
Gruß
Alex
>Siehe die VMWare-Doku - das SSD-Host-Caching dient als Ersatz für die "langsamen" vswap-Dateien in den "langsamen" Datastores.
ok, also macht Host-Caching mittels SSD auf ESXi nur Sinn, wenn die Summe der VMs den physikalischen RAM überschreiten!?
Gibt es andere Verwendungsmöglichkeiten in dem ESXi? Als einzelnes Laufwerk, schnelles Datastore, ok, aber sonst?
ZFS hört sich auch interessant an. Dort würde die SSD als ZIL wohl helfen. Allerdings werde ich jetzt erstmal auf vernünftige SAS-Platten als RAID1 setzen.
Blättere gerade in diversen Servershops herum. 600 GB SAS II Hitachi 3,5" 15k? 2000 GB SAS II Seagate Constellation ES.2 3,5" 7.2k, lieber 2,5" SAS? Welchen Controller? Ein 8 x SAS hat 2 miniSAS-Anschlüsse. Lassen sich SATA und SAS in der Realität so problemlos mischen wie das die Hersteller behaupten?
Adaptec 6805 8x, LSI 9261-8i 8x?
LSI LSI00194 SAS9211-8i Single 8-Port?
DELL PERC 5/i 8-Port?
Wie lassen sich die Controller und alles was dranhängt am ESXi überwachen? Ist das nur an den 3ware ein Problem?
Gruß
Alex
Re: Beispiel
sambu hat geschrieben:ok, also macht Host-Caching mittels SSD auf ESXi nur Sinn, wenn die Summe der VMs den physikalischen RAM überschreiten!?
Ja, immer dann wenn ESX intensiv auf die vswap-Dateien zugreifen muss.
sambu hat geschrieben:Wie lassen sich die Controller und alles was dranhängt am ESXi überwachen? Ist das nur an den 3ware ein Problem?
Das ist vom Hersteller und der Bereitstellung von CIM-Providern oder anderen Lösungen abhängig. Für LSI-Controller gibt es z.B. ein CLI für ESX. Für viele Modelle gibt es CIM-Provider und dazugehörige RAID-Manager, die ESX-Hosts verwalten können. Das geht dann auch aus einer VM heraus.
Zurück zu „vSphere 5 / ESXi 5 und 5.1“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 11 Gäste