Ich habe eine Frage zu meinem Testlabor. Es geht mehr darum, das Konzept zu verstehen, als es in der Produktion anzuwenden:
Ich habe einen ESXi mit einigen konfigurierten Linux-/Windows-VMs und möchte zum Erstellen von Backups einen VMWare-Konverter verwenden.
Um den Vorgang zu beschleunigen, habe ich beschlossen, eine Windows-VM auf demselben ESXi-Host zu erstellen, auf dem ich Windows 7 und VMWare Converter installiert habe.
Der Host verfügt über eine Gigabit-Karte, die derzeit jedoch an einen 100-MB-FD-Port angeschlossen ist. Windows 7 erkennt, dass eine 1-GB-Karte angeschlossen ist.
Wenn ich das Backup mit dem VMWare-Konverter durchführe, gebe ich die Host-IP als Quelle und Ziel an, daher dachte ich, das Kopieren könnte schneller sein, als wenn ich meinen Laptop über das Netzwerk verwende.
Um es kurz zu machen: Ich habe eine furchtbare Leistung (4 Mbit/s). Das verwirrt mich ein bisschen, denn obwohl der Host 100 Mbit/s ausführt, sollte die Kommunikation zwischen VMs und Hosts keine Einschränkungen haben (korrigieren Sie mich, wenn ich falsch liege).
Ich habe Windows 7 optimiert, um die Netzwerkleistung zu verbessern, aber die Verbesserung war nur gering. Ich brauche immer noch 4 Stunden, um eine 50 GB (dünne) VM zu sichern.
Außerdem wollte ich fragen: Wäre Jumbo Frame dabei hilfreich? Ich weiß, dass Jumbo Frames durchgehend unterstützt werden müssen und der Netzwerk-Switch, mit dem der Host derzeit verbunden ist, dies nicht unterstützt, aber ich habe mich gefragt:
1) Unterstützt der ESXi-Host überhaupt Jumbo-Frames?
2) Kann ich es irgendwie aktivieren?
3) Wenn ich dies tue, würde sich vermutlich die Massenübertragung zwischen VMs und Host verbessern. Würde dies jedoch die Kommunikation über den realen Switch beeinträchtigen, da dieser keinen Jumbo-Switch unterstützt?
Danke fürs Lesen
Antwort1
Jumbo-Frames können einen gewissen Unterschied machen, aber Ihre Durchsatzprobleme deuten auf ein viel schwerwiegenderes Problem hin. Sie können Jumbo-Frames in ESXi aktivieren, aber dazu müssen Sie die vCLI-Befehlszeilentools verwenden. Genaue Anweisungen finden Sie hier.VMware ESXi-Konfigurationsdokument.
Es gibt einige mögliche Ursachen.
Möglicherweise gehen Ihre Daten in den ESXi-Host hinein und hinaus. In diesem Fall würde Converter die Daten aus der VM im ESXi-Host über Ihr physisches Netzwerk zurück zur Verwaltungsschnittstelle kopieren. Da es sich um einen 100-Megabit-Uplink handelt, würde ich dennoch erwarten, dass Sie ein paar Megabyte/s erhalten und nicht die 4 Megabit/s, die Sie melden.
Ihre ESX-Host-NICs handeln die 100 Mbit/s/Vollduplex-Einstellungen möglicherweise nicht richtig mit dem Switch aus. Stellen Sie sicher, dass sowohl der Switch als auch die pNIC-Einstellungen auf Ihrem ESXi-Host richtig eingestellt sind.
Der Konverter ist in Bezug auf den Durchsatz nicht besonders effizient, aber wenn Sie blockbasiertes Kopieren auf Datenträgern (anstatt auf Dateiebene) verwenden, ist es in Ordnung (die Übertragungsrate beträgt >50 % der maximalen Verbindungsbandbreite – sagen wir 4 Mbit/s in einem 100-Mbit/s-Netzwerk, 40 Mbit/s bei GigE). Wenn Sie beim Kopieren auf Dateiebene kopieren, geht alles viel langsamer.
All diese Aktivitäten belasten das Festplattensubsystem, auf dem Ihre VMs gespeichert sind, erheblich. Wenn Sie all dies auf einem relativ langsamen Speicher ausführen (sagen wir, einer Handvoll SATA-Laufwerke in RAID 5), ist es möglich, dass die Festplatte überlastet ist, aber für eine gesunde Speicherkonfiguration sollte dies kein Problem darstellen.
Ich denke jedoch, dass das Problem bei Ihrem virtuellen Netzwerk liegt. Wenn dies der Fall ist, sollten Sie Folgendes berücksichtigen:
Wenn sich Ihr ESXi-Verwaltungsport auf demselben virtuellen Switch befindet wie die Produktionsnetzwerk-Portgruppe Ihrer VM, sollte der Datenverkehr intern innerhalb des virtuellen Switches zurückgeleitet werden. Wenn dies nicht der Fall ist, würde ich prüfen, ob VLANs auf den Ports/Portgruppen konfiguriert sind oder ob Ihre IP-Adressierung den Datenverkehr glauben lässt, er müsse den Switch verlassen, bevor er wieder zurückkommt (z. B. wenn sich der Verwaltungsport in einem anderen Subnetz als das VM-Netzwerk befindet und Sie sich auf einen externen Router verlassen, um die Kommunikation zu ermöglichen). Wenn Sie vermuten, dass Ihr Netzwerk die oben genannten Punkte nicht korrekt ausführt, können Sie die Quell- und Ziel-VMs auf dasselbe Subnetz wie den Verwaltungsport setzen und sie mit einer VM-Portgruppe auf demselben vSwitch wie den Verwaltungsport verbinden. Dann sollte der Datenverkehr zwischen den verschiedenen Systemen (der Quelle, der Konverter-VM und dem ESX-Host) innerhalb der Grenzen des vSwitches bleiben. Verschieben Sie die VM-Portgruppen, anstatt am Management-Port herumzuspielen. Wenn Ihnen dabei ein Fehler unterläuft, müssen Sie zur Behebung des Problems zur physischen Konsole von ESXi zurückkehren und dabei sollten Sie kein Risiko eingehen.
Fahren Sie vor dem Start außerdem so viele Geräte wie möglich herunter, für den Fall, dass beispielsweise ein Sicherungsvorgang die gesamte Netzwerkbandbreite des Management-Ports usw. beansprucht.
Antwort2
Dieses Problem lässt sich umgehen, indem Sie die SSL-Verschlüsselung deaktivieren. So funktioniert es:
Open the converter-worker.xml configuration file. It is located in
"%ALLUSERSPROFILE%\VMware\VMware vCenter Converter Standalone"
folder for Windows Vista or newer or in
"%ALLUSERSPROFILE%\Application Data\VMware\VMware vCenter Converter Standalone"
for older Windows versions.
Set the key Config/nfc/useSsl to false and save the configuration file.
Restart "VMware vCenter Converter Standalone Worker" service.
D. h., es sollte so aussehen:
...
<nfc>
<readTimeoutMs>120000</readTimeoutMs>
<useSsl>false</useSsl>
...
„Starten Sie den Dienst „VMware vCenter Converter Standalone Worker“ neu.“