Live-Migration

[KiraSakuya 0]

Halllo,

ich habe 2 hyper-V Host, die zu eine Domäne gehören. Wenn ich versuche eine VMs zwischen Hosts über Shared Nothing Live-Migration übertragen, wird die Übertragungsrate nur von 700 mbit/s übertragen und nicht von eine 1 GB/s. Kann es sein das am Anfang der RAM und Festplatte im Blöcke überträgt wird? Weil am Schluss als die Konfigurationsdatei der VMs überträgt steigt der Durchsatz auf 950 mbit/s. Woran kann das  liegen?

Danke 

[testperson 1.677]

Hi,

 

wie ist denn dein Netzwerk aufgebaut? Gibt es eigene Adapter für Migration?

Wie ist die Live Migration konfiguriert (TCP/IP / Kompression / SMB)?

 

Generell sind deine Werte für eine GBit Leitung doch ganz okay.

 

Gruß

Jan

[KiraSakuya 0]

soory....ganz vergessen))

die Migration wird über eine separates Netz betrieben. Ich habe 3 Netze (Management, Kommunikation zwischen VMs und für die Migration). DerVerschiebungstyp ist Kompression. 

[testperson 1.677]

Sind das alles GBit Adapter?

Welches OS haben die Hosts?

 

Ggfs. auf SMB wechseln und das Management-Netz für SMB Multichannel mitnutzen / missbrauchen.

[KiraSakuya 0]

ja sind alle 1 GBit, habe 2 windwos server 2016 datacenter

[testperson 1.677]

Wenns schneller gehen soll, rüste auf 10GB Dual-Port NICs auf und nutze "Converged-Network".

Je nachdem wie viele Adapter du derzeit hast könntest du die auch alle in ein Team zusammenfügen und ebenfalls Richtung "Converged-Network".

Oder eben auf SMB switchen und  das Managementnetz mitnutze.

 

Wie viele VMs laufen denn pro Host, wie viele Daten müssen denn da verschoben werden und wie oft kommt das vor?

[KiraSakuya 0]

Leute danke für die antworten...aber ich will es nicht wissen, wie man es  optimieren kann ...sondern ob jemand weißt warum nicht der komplette Durchsatz durch das Netzwerk kommt...welche Gründe dafür sein können? 

[Nobbyaushb 1.471]

Moin,

ich sehe an der Stelle noch kein Problem, 70% ist doch kein schlechter Wert für Gigabit.

 

Ich denke, das deshalb der Hinweis von Jan kam.

 

Mich würde das jetzt nicht so irritieren - Windows halt.

bearbeitet 23. Februar 2018 von Nobbyaushb

[testperson 1.677]

Wie schon in der ersten Antwort und der von Norbert, deine Werte sind nicht wirklich schlecht (für GBit).

 

Hast du einen Switch dazwischen oder sind die Adapter direkt verbunden?

Hast du mal eine andere Option als "Kompression" getestet?

[Tektronix 21]

Hallo,

Netz-Performanz

Die Leistung eines Netzes bemisst sich an drei Grössen: Der Sicherheit, der Zuverlässigkeit und der Übertragungsrate. Die beiden erstgenannten Faktoren können lediglich erwähnt werden, ihre Erörterung würde den Rahmen dieser Darstellung sprengen.

Die Übertragungsrate muß in zwei Kategorien unterschieden werden: den tatsächlichen Durchsatz (Brutto-Datenrate) und die letztendliche Nutzdatenrate. Für den Anwender ist nicht so wichtig, wieviele Bit-Signale über das Medium jagen; ihn interessieren die Antwortzeiten für seine Applikationen.

Generell sei gesagt, dass die technisch bzw. physikalisch vorhandene (nominelle) Bandbreite von Standard-Ethernet nicht ausgeschöpft wird. Geht man nach der für den Endbenutzer sichtbaren Netzleistung, liegt diese oft weit unter 50 % der angebotenen nominellen Datenrate.

Für Ethernet ergeben sich Einschränkungen der Performanz durch verschiedene Einflüsse:

• Physikalische Bandbreite
  - Latenzzeiten
  - sendefreie Zeiten
  = Durchsatz
• Durchsatz
  - Protokoll-Overhead
  - Frame-Overhead
  - Kollisions-Overhead
  = Nutzdatenrate

Latenzzeiten und sendefreie Zeiten

Die Jabber-Funktion, die verhindert, dass eine Station das Medium länger als 30 mS am Stück belegt (Sendefenster = 30 KBit = ca. 4KB), führt dazu, dass die Übertragung grosser Dateien in mehreren Anläfen erfolgt. (Zeit-Multiplexing.) Muss bei hoher Netzlast zwischendurch jedesmal lange gewartet werden, wächst die Latenzzeit an.

Ferner haben etliche Netzwerkkomponenten, etwa Bridges, Router und Switches, ihre eigenen Latenzzeiten, die sich auf die Transferrate niederschlagen.

Sendefreie Zeiten entstehen, ausser durch fehlende Netz-Beanspruchung, durch verfahrensbedingte Verzögerungen wie etwa die Inter-Frame-Gap.

Protokoll-Overhead

Auch: Software-Overhead. Beim Datenfluss müssen die Protokollebenen des OSI-Referenzmodells softwaremässig aufeinander abgebildet werden; ein Datenpaket aus der Anwendungsschicht (Ebene 7) wird bis zum Übertragungsmedium sechsmal in einen Rahmen aus Adress- und Kontrollinformationen eingepackt. Dieser Protokoll-Overhead beansprucht einen Teil der Übertragungskapazität.

Frame-Overhead

Jedes Nutzdatenpaket (incl. Protokolloverhead) wird in der MAC-Schicht bei der Aufbereitung zum sendefähigen Frame mit 26 Byte Transferdaten umgeben. Das Nutzdatenfeld darf bei Ethernet zwischen 46 und 1500 Byte gross sein. An dem kleinstmöglichen Datenpaket von 72 Byte hat der Frame-Overhead einen Anteil von 36 %, an dem grösstmöglichen Paket von 1526 Byte einen Anteil von 1,7%. Der Frame-Overhead ist anteilig umso grösser, je kleiner die Datenpakete sind. Die Übertragung kleiner Datenpakete ist demnach ineffizient.

Kollisions-Overhead

Bei Ethernet kann immer nur eine Station auf einmal senden. Sendet eine Station, müssen die anderen im Empfangsmodus verharren (Halb-Duplex). Das Zugriffsverfahren CSMA/CD vermeidet zwar Daten-Zusammenstösse, räumt sie jedoch nicht gänzlich aus.

Die Slotzeit ist das zweifache der Zeit, die ein Datenpaket benötigt, um sich über die maximale Entfernung im Netz auszubreiten. Im schlechtesten Fall vergeht diese Zeitspanne, bis eine Station bemerkt, dass ihre Sendung mit einer anderen kollidiert ist. Die Collision-Detection-Funktion verringert verschenkte Wartezeiten und Übertragungskapazitäten, weil eine missglückte Übertragung bereits beim Empfang des Jam-Signals, nicht erst bei ausbleibender Quittung registriert (Detektionszeit) und frühzeitig abgebrochen wird. Mit wachsender Netzausdehnung nimmt andereseits die Slotzeit selbst zu und damit die Möglichkeit, dass Signale unnötig in das Netz eingespeist werden und nach ihrer Kollision wiederholt werden müssen.

Bei hohen Verkehrslasten stellt der Kollisions-Overhead eine zusätzliche, die Konfliktwahrscheinlichkeit erhöhende Last dar, da die Neubewerber und die aufgelaufenen Wiederholungsversuche sich gegenseitig die Übertragungskapazität streitig machen.

Die Wahrscheinlichkeit von Kollisionen steigt ihrerseits mit wachsender Netzlast. In Spitzenzeiten, wo viele Stationen Pakete versenden wollen, geht viel Zeit im Wartemodus (Backup) dahin.

[NorbertFe 2.034]

Wäre ja nett, wenn du auf die Quelle verlinkst, von der du kopierst.

[Tektronix 21]

Die Quelle ist:

Ethernet Performance

[NorbertFe 2.034]

Danke.

[KiraSakuya 0]

also es gibt mehrere gründen warum das ist))) danke 

eine andere Frage, während Live-Migration ....was wird zu erst Migriert und was zum Schluss? zuerst wird der RAM und virtuelle Disk und dann die VMs selbst (Konfigurationdatei)??

[magheinz 110]

ich möchte mal drauf losraten:

Der RAM ist das letzte da sonst zu viel zwischen den zwei VMs abgeglichen werden muss.

 

Also erst die metadaten, configfiles etc. Dann die Platten, die dann synchron gehalten werden und irgendwo dabei oder danach der RAM.