Kraftzwerg 10 Geschrieben 6. Oktober 2010 Melden Teilen Geschrieben 6. Oktober 2010 Hallo zusammen, Wie in anderen Beiträgen schon angsprochen sind wir hier gerade am testen mit Windows Server 2008 R2 mit Failovercluster und Hyper-V. Aufbau: 2x Dell R710 als physikalische Knoten zu einem Failovercluster zusammengefasst. OS: 2008R2 Enterprise. 1x NIC am lokalen LAN, 1xNIC am iSCSI-Netzwerk ohne kommunikation zur Außenwelt. Auf der lokalen NIC wurde ein virtuelles Netzwerk erzeugt. Innerhalb des Failoverclusters laufen mehrere virtuelle Terminalserver deren vhds auf dem iSCSI liegen. Sie sind in einem NLB-Cluster mit Sessionbroker zusammengefasst.Zugriff aufs Netzwerk erfolgt über das virtuelle Netzwerk der Hostsysteme. Nach dem Aufbau der Testumgebung wurden die physikalischen Server in ein eigenes Subnetz verschoben. Soweit alles stabil und wie erwartet. Haben die bisherigen Probleme ja mit Onkel google und eurer Hilfe in den Griff bekommen. Dafür nochmal Danke! Das aktuelle Problem bzw. die Merkwürdigkeit ist folgende: Wir haben in unserem jugendlich Leichtsinn gleich mal die Live Migration getestet. Vor dem Verschieben in das Subnetz lief diese schonmal. Beim Umbau am Switch müssen wohl Kabel vertauscht worden sein, so dass das lokale Netz beim ersten Server auf Port 1 hing und beim zweiten Server auf Port 2. iSCSI genau umgedreht. IP-Einstellungen waren jedoch richtig, so dass beide Rechner richtig kommuniziert haben. Wir haben auch die NICs in den Hostsystemen identisch benannt. Also die beiden an denen das lokale Netzwerk hing als "lokal" und die beiden die am iSCSI hängen mit "iSCSI". Wenn man nun die Livemigration startete lief sie auf einen Fehler. Im Log stand was davon, dass nicht alle Ressourcen vollständig off- oder online geschaltet werden konnten. Genaueres Nachforschen ergab, dass die Netzwerkkarte des Gastsystems nicht zwischen den Failoverclusterknoten umgeschaltet werden konnte. Mehr durch Zufall haben wir gemerkt, dass der Gerätename der NICs (nicht der Name den man selbst ändern kann) ,an denen jeweils das lokale LAN hängt und auf die das virtuelle Netzwerk aufbaut, an den beiden physikalischen Servern unterschiedlich waren. Z.B. "Realtek" und "Realtek#2" Jetzt haben wir die Konfiguration der physikalischen Karten an einem Knoten getauscht, so dass die Gerätenamen auf beiden Hosts identisch sind. Nun funktioniert die Live Migration fehlerfrei. M.E. bedeutet das, dass man immer identische NICs in den Hyper-V knoten benötigt oder kann man diese Gerätenamen irgendwie angleichen? Kann mir nich vorstellen, dass das so sein muss wie wir es gelöst haben:) Gruß Zitieren Link zu diesem Kommentar
zahni 554 Geschrieben 6. Oktober 2010 Melden Teilen Geschrieben 6. Oktober 2010 Lies Dir zuerst vielleicht mal Hyper-V: Using Live Migration with Cluster Shared Volumes in Windows Server 2008 R2 durch. Beachte dort auf jeden all die Empfehlungen zur Netzwerk-Konfig. U.a. sollte für Live Migration ein dediziertes Netz über dedizierte NIC's verwendet werden. -Zahni Zitieren Link zu diesem Kommentar
TheDonMiguel 11 Geschrieben 6. Oktober 2010 Melden Teilen Geschrieben 6. Oktober 2010 Zahni hat ein sehr wichtiger Link und ein MUSS bei der LM Konfiguration. Auch lesenswert: How-To: Verwaltung eines Cluster Shared Volume (CSV) | Server Talk und faq-o-matic.net Mehr Hinweise und Notizen zu Hyper-V Ach ja - Das Problem mit der NIC ist mir so nicht bekannt... Gruss Michel Zitieren Link zu diesem Kommentar
Kraftzwerg 10 Geschrieben 7. Oktober 2010 Autor Melden Teilen Geschrieben 7. Oktober 2010 Morgen, jo, die Empfehlung zur dedizierten NIC ist mir bekannt. Hab mich auch vertan. Sind nur R210 zum Testen. R710 werden die produktiven. Die R210 haben eben nur 2 NICs, so dass wir gezwungen waren es erstmal so zu versuchen. Werd mir die Links mal zu Gemüte führen. Danke! Gruß Zitieren Link zu diesem Kommentar
Gadget 37 Geschrieben 7. Oktober 2010 Melden Teilen Geschrieben 7. Oktober 2010 Hi Kraftzwerg, das a und o beim Hyper-V Cluster sind ihmo wirklich die ordentliche Planung der Netzwerk-Struktur und die ausreichende Zahl der NIC's. Außerdem ist eine Trennung der Netze mittels VLAN angebracht. Ich selbst hab mich vor nem halben Jahr eingearbeitet und muss sagen, das es doch deutlich mehr zu beachten gibt als man Anfangs denkt. 1. Video's anschauen: server virtualisation episodes Off Campus Videos–Hyper-V Virtual Network Manager 2. Best Practices lesen NetApp Storage Best Practices For Microsoft Virtualization (sehr gutes Howto auch wen man keine NetApp hat) http://media.netapp.com/documents/tr-3702.pdf 3. Wichtige Patches installieren Hyper-V R2 Hotfix Rollup – Hyper-V blog by Hans Vredevoort Hyper-V IT Core Blog lg Gadget Zitieren Link zu diesem Kommentar
Kraftzwerg 10 Geschrieben 7. Oktober 2010 Autor Melden Teilen Geschrieben 7. Oktober 2010 Hallo, hatten uns zuvor auch eingelesen und die Einrichtung anhand von Literatur durchgeführt. Unser Handycap war einfach, dass wir zum Testen nur die beiden "kleinen"Server;) bekommen haben. Dort ist nicht mal ein Raiser drin auf dem man noch zusätzliche NICs verbauen könnte. Sonst hätten wir das weiter aufgeteilt. Dass das für den Produktivbetrieb nicht geeignet ist, ist mir klar. Habe die Umgebung ja auch nur beschrieben, damit es einfacher nachzuvollziehen ist. Mich hat einfach gewundert, dass der Gerätename identisch sein musste, damit die Livemigration läuft. Für die spätere Produktivumgebung haben wir die Struktur ausführlich geplant und werden uns auch Unterstützung von einem Systemhaus holen. Die Tests machen wir nur, damit wir selbst Erfahrungen sammeln und nicht dort stehen wie das Kind beim Dreck, wenn es ernst wird. Danke für die zahlreichen Links und Anmerkungen. Bin fleißig am Lesen;) Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 7. Oktober 2010 Melden Teilen Geschrieben 7. Oktober 2010 Moin, Mich hat einfach gewundert, dass der Gerätename identisch sein musste, damit die Livemigration läuft. die Namen der vSwitches müssen nicht nur für Live Migration identisch sein., sondern auch für Failover, Import/Export usw. Das ist die einzige Möglichkeit, auf unterschiedlichen Servern zweifelsfrei identisch zu identifizieren, wofür ein Netzwerk da ist. Gruß, Nils Zitieren Link zu diesem Kommentar
Kraftzwerg 10 Geschrieben 7. Oktober 2010 Autor Melden Teilen Geschrieben 7. Oktober 2010 Hallo Nils, die Namen der Switches und der NICs sind identisch. Dann hätte ich mich nicht gewundert. Aber in unserem Fall mussten die Gerätenamen identisch sein. M.E. ein Wert den man nicht so einfach ändern kann. Gruß Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 7. Oktober 2010 Melden Teilen Geschrieben 7. Oktober 2010 (bearbeitet) Moin, ??? kannst du bitte mal genau ausführen, was du meinst? EDIT: Okay, hast du ja oben schon getan. Was auch immer da falsch gelaufen ist, es gibt kein Erfordernis von Seiten Hyper-V, dass der Gerätename nicht unterschiedlich sein dürfte. Da wird was anderes im Argen gewesen sein. Gruß, Nils bearbeitet 7. Oktober 2010 von NilsK Wer lesen kann ... jaja. Zitieren Link zu diesem Kommentar
Kraftzwerg 10 Geschrieben 7. Oktober 2010 Autor Melden Teilen Geschrieben 7. Oktober 2010 Hm dacht das hätte ich ;) Also die Umgebung steht ja oben. Livemigration schlug fehl. Dann ist uns aufgefallen, dass bei der Benennung der NICs Unterschiede bestehen. Wenn man die Ansicht unter "Adaptereinstellungen" auf Details setzt steht in der ersten Spalte der Name (den man ändern kann), in der zweiten der Status und in der dritten der Gerätename. Auf beiden Hyper-V Hostservern gibt es zwei physikalische NICs. Eine davon hat den Gerätenamen z.b. "Realtek" und die zweite "Realtek#2". Nun war auf dem ersten Hyper-V Hostserver das iSCSI-Netzwerk auf "Realtek" konfiguriert und der vSwitch, der auf das loakle LAN verweist, auf "Realtek2#". Am zweiten Hyper-V Hostserver war es umgedreht. Die Namen (erste Spalte) waren jedoch identisch. Dennoch schlugen die Migrationen fehl. Jetzt haben wir die Konfiguration der NICs am ersten Hostserver so verändert, dass iSCSI-Netzwerk auf "Realtek#2" liegt und der vSwitch auf der lokale LAN auf "Realtek". Nun funktioniert die Migration scheinbar. Hoffe das war verständlich. Ist schwer in Worte zu fassen, weil net ganz so alltäglich:) Gruß Zitieren Link zu diesem Kommentar
Lian 2.421 Geschrieben 7. Oktober 2010 Melden Teilen Geschrieben 7. Oktober 2010 weil net ganz so alltäglich:)Beim Clustering schon ;) Der Name der Netzwerkverbindung (NIC) muss identisch sein, der Cluster Dienst kümmert sich auch bei einem fertig eingerichteten Cluster darum, daß die Namen synchron bleiben. Ich stimme also Nils zu. Die Enumeration der Gerätenamen einer Netzwerkverbindung (NIC) kann abweichen, da beim Windows Setup nicht immer das selbe Interface den selben Gerätenamen bekommt. Wen man mal dutzende identische Nodes aufsetzt, wird einem auffallen, daß der Gerätename abweicht... Zitieren Link zu diesem Kommentar
Kraftzwerg 10 Geschrieben 7. Oktober 2010 Autor Melden Teilen Geschrieben 7. Oktober 2010 Servus, jo schon klar, dass die Gerätenamen abweichen können. Passiert uns ja öfter. Nur bislang kams deswegen nie zu Fehlern. Wie auch immer, ich fass mal zusammen. die Namen der NICs und vSwitches müssen identisch sein, die Gerätenamen nicht. Danke an alle! Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.