Confuse 0 Geschrieben 26. Januar 2014 Melden Teilen Geschrieben 26. Januar 2014 Guten Tag zusammen, Ich lese gerade das Buch Hyper-V und System Center um mich in die Thematik des Clusteraufbaus unter Server 2012 zu fuchsen. Hintergrund ist, dass ich eine Testumgebung aufbauen möchte, für die ich die folgende Hardware zur Verfügung habe: 1 Domain Controller für die Clusternodes mit Server 2012R22 Cluster Nodes beide mit Server 2012R22 Netgear Switches GS724TP (Nicht stackable)1 QNAP TS-879U-RP das als ISCSI Ziel genutzt werden soll Die Clusternodes haben jeweils 6 NICs bzw. Ports (2 onboard und jeweils eine Intel Quadport I340-T4) und das QNAP hat 2 NICs. Die Clusterknoten sollen jeweils einen NIC Port für ISCSI bekommen, und dann auf beide Switches verteilt werden. Nun zu meiner Frage: Da im Buch öfter die Rede von der redundanten Anbindung der Knoten an das ISCSI Ziel ist, und dies halt nicht per Teaming sondern per MPIO vorgenommen werden soll, frage ich mich ob dies in meinem Szenario überhaupt greift. Ich habe ja pro Knoten nur einen NIC Port für ISCSI, ist MPIO in diesem Fall notwendig? Wenn ja muss das Feature auf meinen Clusterknoten und im ISCSI Ziel aktiv sein? Gruß Confuse http://files.qnap.com/news/pressresource/product/How_to_connect_to_iSCSI_targets_on_QNAP_NAS_using_MPIO_on_Windows_2008.pdf Diese Anleitung von QNAP beschreibt das Szenario mit einem Server der 2 NICs hat, aber wie läuft es mit der Cluster Konfiguration? Lege ich die 2 benötigten IP Adressen einfach auf die NICs der beiden Knoten, oder wäre das eine Fehlkonfiguration? Zitieren Link zu diesem Kommentar
Necron 71 Geschrieben 26. Januar 2014 Melden Teilen Geschrieben 26. Januar 2014 Hi,schau dir folgendes HowTo an. Das sollte deine Fragen beantworten. :)-> http://www.hyper-v-server.de/management/aufbau-und-einrichtung-eines-failovercluster-unter-windows-server-2012/ Zitieren Link zu diesem Kommentar
alexabexi 0 Geschrieben 26. Januar 2014 Melden Teilen Geschrieben 26. Januar 2014 Hallo Ist es Absicht, dass in der Grafik Management-Netz und VM-Netz denselben IP-Bereich haben, aber darunter steht " Management-Netz: Dieses Netzwerk ist für die Kommunikation des Cluster-Knoten mit der Domäne zuständig. Auf diesem Interface wird keine VM-Kommunikation betrieben, der Adapter steht exklusiv dem Knoten zur Verfügung. VM-Netz: Bei diesem Netzwerk ist es genau anders herum," Das verstehe ich nicht.? Tschüß Zitieren Link zu diesem Kommentar
Confuse 0 Geschrieben 26. Januar 2014 Autor Melden Teilen Geschrieben 26. Januar 2014 Hallo Necron, vielen Dank für die schnelle Rückmeldung. Leider kenne ich den Artikel bereits und werde trotzdem nicht ganz schlau daraus. Bei 2 Netzwerkkarten pro Clusterknoten arbeitet man ja laut dem Artikel mit 2 Subnetzen für ISCSI 1 und ISCSI 2 (192.168.212.0 und 192.168.213.0), was ja zur Folge hätte das ich dem QNAP auf seinen NICs auch ebenfalls eine Adresse aus jedem IP Adressbereich geben müsste. Allerdings ist auf dem QNAP "Port Trunking" aktiv bzw. steht es so in der Anleitung des Herstellers für die Nutzung von MPIO und in diesem Fall stellen ja beide NICs zusammen eine IP Adresse dar. Eigentlich kann ich die Frage auch vereinfachen: Ist es möglich MPIO zu nutzen wenn ich pro Server nur eine Karte zur Verbindungsherstellung des SANs habe? Also quasi die Multipfad Verbindung auf 2 Server aufteile? Gruß Confuse Zitieren Link zu diesem Kommentar
Necron 71 Geschrieben 26. Januar 2014 Melden Teilen Geschrieben 26. Januar 2014 Port-Trunking auf der QNAP mit iSCSI ist von der Performance schlechter als wenn man bei beiden NICs unterschiedliche Subnetze nutzt und MPIO verwendet. Ich kann da bei meinem Lab aus Erfahrung sprechen. MPIO kann man nicht auf zwei Server aufteilen. In gewissen Konfigurationen ist MPIO in einem Subnetz möglich, aber hier braucht man immer noch zwei NICs pro Server. Besser ist aber mit zwei unterschiedlichen Subnetzen. Zitieren Link zu diesem Kommentar
Confuse 0 Geschrieben 26. Januar 2014 Autor Melden Teilen Geschrieben 26. Januar 2014 Hallo Necron, Vielen Dank! Das ist die Information die ich gebraucht habe. Jetzt kann ich meine Planung anpassen, eigentlich hätte ich gerne 2 NICs für mein VM Netzwerk gehabt und diese Adapter dann im Team betrieben, aber da es sich zuerst um eine Testumgebung handelt, und ich leider von der Hardware auf 6 NICs pro Server angewiesen bin, muss vorerst eine NIC für das VM Netzwerk reichen. Ich meine gelesen zu haben dass eine 1:5 Regel gilt, das heißt ich kann ja 5 vNics per vSwitch an einen physikalischen Adapter koppeln, mehr VMs sollten es auch nicht werden. Eine kleine Frage hätte ich aber noch :) : Wie sieht es mit der VLAN Konfiguration bei MPIO aus? Müssen die Switches Port Aggregation können um die beiden Karten als gemeinsame Verbindung (LAG) zu erkennen, oder muss für beide ISCSI Subnetze ein VLAN erstellt werden? Gruß Confuse Kurze Rückmeldung: Ich lese immer wieder das Link Aggregation (LACP, 802.3ad bzw. LACP 802.1ax-2008), als dynamisches Teaming, also eigentlich nur im Zusammenhang mit NIC-Teaming eingesetzt wird. Außerdem wird im Hyper-V und Systemcenter Buch beschrieben, dass für die ISCSI Anbindung kein Teaming unterstützt wird bzw. diese mit MPIO stattfinden soll. Richtet man für MPIO also grundsätzlich keine LAGs ein? Leider ist die Konfiguration von VLANs auf physischen Switchen nur sehr rudimentär beschrieben. Wahrscheinlich bin ich einfach noch zu grün hinter den Ohren um das zu verstehen :confused: Zitieren Link zu diesem Kommentar
Dunkelmann 96 Geschrieben 26. Januar 2014 Melden Teilen Geschrieben 26. Januar 2014 Moin, wenn Du 6 NICs je Server hast, reicht es doch: 2x iSCSI per MPIO 2x Host OS, Cluster und Live Migration als Team 2x VM als Team Wenn Du iSCSI MPIO mit zwei Subnetzen verwendest, solltest Du auch 2 VLANs dafür auf den Switches einrichten. iSCSI wird serverseitig grundsätzlich ohne Link Aggregation betrieben - dafür gibt es Multipathing. Es gibt zwar auch Setups, die LACP-Teaming und Subinterfaces oder vNICs für iSCSI ermöglichen. Für Deine Umgebung dürfte das jedoch nicht relevant sein. Zitieren Link zu diesem Kommentar
Confuse 0 Geschrieben 26. Januar 2014 Autor Melden Teilen Geschrieben 26. Januar 2014 Vielen Dank für die Infos! Ich poste morgen mal was ich Netzwerkkonfigurationstechnisch vorhabe. Vielleicht könnt Ihr dann ja kurz eure Meinung dazu äußern. Ich wollte mich so nah wie möglich an den Microsoft Best Practize Empfehlungen orientieren bzw. am Buch Hyper-V und System Center, da ich halt noch nicht sehr viel Erfahrung in dem Bereich habe. Deswegen wundert mich die Empfehlung das Management OS Cluster/CSV und Live Migration an ein Team zu koppeln, aber wie gesagt bin ich noch nicht sehr erfahren mit der Cluster Geschichte und freue mich immer wenn ich etwas dazulernen kann. Morgen mehr... Schönen Abend noch! Zitieren Link zu diesem Kommentar
Dunkelmann 96 Geschrieben 26. Januar 2014 Melden Teilen Geschrieben 26. Januar 2014 Schau Dir mal den Blog von Keith Mayer an: http://blogs.technet.com/b/keithmayer/archive/2013/04/01/build-your-private-cloud-in-a-month-new-article-series.aspx Da wird im Abschnitt 'Networking' auch das Thema mit dem Host/Cluster/LM Team behandelt. Zitieren Link zu diesem Kommentar
IT-Shrek 13 Geschrieben 27. Januar 2014 Melden Teilen Geschrieben 27. Januar 2014 Hallo, das ist immer eine Geschmacksfrage. Ich erstelle in dieser Situation ein großes Team für Host/Cluster/VM-Traffic und trenne logisch via QoS, aber wie schon gesagt wurde, hier gibt es kein richtig oder falsch. Beste Grüße, Shrek Zitieren Link zu diesem Kommentar
Confuse 0 Geschrieben 27. Januar 2014 Autor Melden Teilen Geschrieben 27. Januar 2014 Guten Abend zusammen, Ich habe jetzt für mein Projekt noch 2 Switches (Netgear GS724TS) zur Verfügung, was sich wohl positiv auf die VLAN Konfiguration auswirken dürfte, da diese im Gegensatz zu den Vorgängern stackable sind. Zur Netzwerkkonfiguration habe ich mir jetzt folgendes überlegt: 2 NICs pro Node für ISCSI (Unterschiedliche IP Adressbereiche) für die Multipfad Anbindung an das QNAP über 2 VLANs 1 NIC für das Management OS 1 NIC für das VM Netzwerk1 NIC für CSV und Heartbeat 1 NIC für Live Migration Ich hätte jetzt noch ein paar Fragen zu den virtuellen Switches auf den Servern. Nach meinem Verständnis benötige ich doch nur einen virtuellen Switch der an die NIC des VM Netzwerks gekoppelt wird (Gemeinsames Verwenden mit dem Hostsystem ist nicht gesetzt, mein Hostsystem soll ja keine Verbindung zu den VMs haben sondern eine IP Adresse aus dem Bereich der Domäne die die Cluster verwaltet), um den Uplink über die physikalische Netzwerkkarte in LAN herzustellen, oder muss ich noch weitere virtuelle Switches für die NICs erstellen? Gruß Confuse Zitieren Link zu diesem Kommentar
Dukel 451 Geschrieben 27. Januar 2014 Melden Teilen Geschrieben 27. Januar 2014 Wozu gerade die Storage Redundant aufbauen und den Rest nicht? Braucht es in der Testumgebung einen Redundanten Aufbau? Und wenn ja, wieso nicht alles wichtige Redundant, wie Dunkelman in #7 vorgeschlagen hat? Zitieren Link zu diesem Kommentar
Dunkelmann 96 Geschrieben 27. Januar 2014 Melden Teilen Geschrieben 27. Januar 2014 Ich hätte jetzt noch ein paar Fragen zu den virtuellen Switches auf den Servern. Nach meinem Verständnis benötige ich doch nur einen virtuellen Switch der an die NIC des VM Netzwerks gekoppelt wird (Gemeinsames Verwenden mit dem Hostsystem ist nicht gesetzt, mein Hostsystem soll ja keine Verbindung zu den VMs haben sondern eine IP Adresse aus dem Bereich der Domäne die die Cluster verwaltet), um den Uplink über die physikalische Netzwerkkarte in LAN herzustellen, oder muss ich noch weitere virtuelle Switches für die NICs erstellen? Hallo, so kannst Du es - erstmal - auch aufbauen. Bei dem Setup brauchst Du nur einen virtuellen Switch für die VMs, das Host OS ist ja direkt mit den anderen 5 NICs verbunden. Wenn Du dann später mal Lust auf Teaming hast, versuch' es mal ohne Downtime von Host-Cluster oder VMs umzustellen :D Es geht. Zitieren Link zu diesem Kommentar
Confuse 0 Geschrieben 28. Januar 2014 Autor Melden Teilen Geschrieben 28. Januar 2014 @ Dukel: Es ist zwar im ersten Schritt eine Testumgebung, diese dient aber dazu, Erfahrungen zu sammeln um später auch produktive VMs darauf zu betreiben. Meinst du mit der Redundanz der anderen Netzwerke, alle anderen NICs als Team zu konfigurieren? Wie gesagt habe ich noch keinerlei Erfahrungen mit dem Aufbau und orientiere mich am Hyper-V und System Center Buch, dort steht beschrieben dass man möglichst pro Netzwerk eine eigene NIC bzw. für das VM Netzwerk ein Team einsetzen sollte. Gerade die NIC für das Management OS wird angepriesen. Habe ich keine Nachteile wenn ich zum Beispiel alle Cluster relevanten Netze (CSV, Heartbeat und Live Migration bzw. sogar noch das Management Netz) auf einen Adapter bzw. ein Adapter-Team konfiguriere? Wie verhält sich das mit den virtuellen Switches bei dieser Konfiguration? Gruß Confuse.. Zitieren Link zu diesem Kommentar
Dunkelmann 96 Geschrieben 28. Januar 2014 Melden Teilen Geschrieben 28. Januar 2014 Moin, wie Shrek oben schon geschrieben hat, vieles ist Geschmackssache oder hängt von konkreten Vorgaben für die Umgebung ab. Es spricht absolut nichts dagegen, zum Üben und Kennenlernen einen simplen Cluster ohne Teaming und sonstige Extras aufzubauen. Das Gute an einer Testumgebung ist ja, dass Du Dein individuelles Tempo und Deine Präferenzen umsetzen kannst. Wenn es Dir dann nicht mehr gefällt, kannst Du es plattmachen und neu anfangen. In einer Produktivumgebung ist das etwas schwieriger. Ohne Teaming hast Du keine Netzwerkredundanz. Der Switch oder die Netzwerkkarte wird zum Single Point of Failure; und genau das ist in einer hochverfügbaren Umgebung nicht gewünscht. Natürlich hat Teaming auch Nachteile: Es muss richtig konfiguriert werden und verursacht etwas Overhead im Host OS. Mit vernünftiger Hardware und PowerShell ist das aber kein Problem :cool: 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.