Jump to content

NLB Cluster mit IGMP Multicast (Server 2016)


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

hi all

 

Mir ist unklar, warum von zwei NLB- Clustern (IGMP Multicast), welche auf zwei IIS (Server 2016) laufen, nur 1 von 2 NBL Clustern vom NB aus (VLAN10) per ping erreichbar ist?

 

Ganz grob erklärt, wie die Infrastruktur aussieht

-----------------------

produktives LAN

Netzwerk = 192.168.10.224 /27

VLAN = 10

 

In diesem Netzwerk sind alle Netzwerkgeräte (NBs, Workstations, Drucker, Servers, Firewall, Cisco Switches).
Auch die zwei Server 2016 Maschinen mit installiertem NLB Cluster haben jeweils eine NIC, welche unter anderem eine NIC mit dem VLAN10 konfiguriert haben.

------------------------

Zusätzlich habe ich noch div. VLANs eingerichtet

@ VLAN 11 VOIP Telefonie (funktioniert alles)

@ VLAN12 (für NLB Cluster und für eine LAB Umgebung (Umgebung für Übungen > 3 Maschinen)

@ VLAN13 (wäre als Management LAN für den einen Hyper-V Server gedacht)

------------------------

physikalisch ist das Netzwerk wie folgt verkabelt.

Bemerkung: Ich nenne nun die Aufführung in der Reihenfolge, wie die Geräte physikalisch verkabelt sind

 

Cisco SG350 (im EG des Hauses)

In Bezug dieser Problemstellung hier ist wohl nur relevant, dass an diesem eine Sophos XG Firewall hängt (1 NIC für das LAN und 1 NIC als VLAN Trunk - verbunden mit einem Cisco SG300 Switch im UG des Hauses) auf welcher auch der Sophos AP15 konfiguriert wird. Der Sophos AP hängt physikalisch an diesem Cisco SG350 im EG des Hauses.

Zusammenfassung Cisco SG350
@ ist im EG des Hauses installiert
@ hat zwei physikalische Geräte angeschlossen, nämlich einerseits die Sophos XG Firewall (mit jeweils einer NIC, eine für das LAN, über welche alle VLANs laufen und 1 NIC als VLAN Trunk, welche direkt mit dem zweiten Cisco SG300 im UG des Hauses physikalisch verbunden ist)
@ ein Sophos AP15
---------------------------
UG des Hauses
Da steht ein Cisco SG300 Switch, an welchem alle Server physikalisch angeschlossen sind. Konkret zwei Hyper-V Server (kein Server Cluster) und div. virtuelle VMs (z.B. Exchange, Webserver etc.)
Auch sind auf einem der beiden Hyper-V Server zwei Webserver (IIS) installiert, für welche ich ebenfalls einen NBL- Cluster eingerichtet habe.

Ohne im Moment weitere Details zu nennen, finde ich für die Schilderung des Problems noch folgenden Umstand wichtig zu wissen:
@ beide Webserver habe eine virtuellen Switch angehängt, welcher stellvertretend für zwei NICs ces Hyper-V Servers stehen, welche ich mit einem Teaming konfiguriert habe. Diesen virtuellen Switch habe ich LAN genannt.
@ beide Webserver besitzen zurzeit zwei NLB Cluster.
@ beide Webserver besitzen zwei Webseiten.
@ beide Webserver haben den gleichen GW in der Routing Tabelle (komme ich gleich noch etwas tiefer darauf ein)
@ beide Webserver habe eine NIC im VLAN10 (in den Netzwerkeinstellungen dieser NIC ist kein GW angegeben)
@ beide Webserver habe noch zusätzlich eine NIC, welche im VLAN12 konfiguriert sind (für die Bindung der NLB Cluster-IP an die Netzwerkkonfiguration des VLAN12)
@ die eine Webseite, nenne Sie hier www.webseite01.ch hat z.B. die NLB Cluster-IP 192.168.12.237 /27 (hierbei habe ich in den Netzwerkeinstellung des VLAN12 einen GW hinterlegt, 192.168.12.254)
@ die zweite Webseite, nenne sie hier www.webseite02.ch hat z.B. die NBL Cluster-IP 192.168.14.242 /27 (in den Netzwerkeinstellung dieser Netzwerkkonfiguration habe ich in der NIC KEINEN GW erfasst, da ich in der anderen NIC, mit den VLAN12 Netzwerkeinstellungen ja bereits in den Netzwerkeinstellungen einen GW hinterlegt habe

Wichtig hier ist zu wissen, wie die Netzwerkkonfiguration der oder des Webservers im Detail konfiguriert ist, da die NLB Cluster von mir in ein separates VLAN konfiguriert wurden)
Schaut man sich die Netzwerkkonfiguration eines Webservers aus, sieht die Konfiguration im Detail, kurz erklärt, wie folgt aus

NIC01 = VLAN10 = kein GW in den NIC Einstellungen hinterlegt
NIC02 = VLAN12 = ein GW in den NIC Einstellungen hinterlegt = an diese Netzwerkeinstellungen wurde auch die NLB Cluster-IP gebunden (192.168.12.237 /27)
NIC03 = VLAN14 = kein GW in den NIC Einstellungen hinterlegt

Bedeutet für das Routing aller Netzwerke, dass die Default Route demnach alle Pakete an den GW des VLAN12 schickt (192.168.12.254 = Sophos Firewall = virtuelle NIC im VLAN12)

So, sende ich nun vom Notebook im WLAN (VLAN10 mit der IP 192.168.10.248 /27 ein ICMP Paket (Ping) an die NLB-IP 192.168.12.237 (VLAN12 > www.webseite01.ch),
@ so wird das ICMP Paket an den GW geschickt, welche auf dem Notebook hinterlegt ist, nämlich die Sophos Firewall.
@ Die Sophos Firewall denkt, aha, ein Datenpaket für das VLAN12, das kenne ich, da ich auch eine virtuelle NIC im VLAN12 habe, wunderbar, dann sende ich das Datenpaket über meine VLAN12 NIC weiter.
@ Das Datenpaket wird physikalisch an den Cisco SG350 Switch über eine physikalische NIC der Sophos XG Firewall im EG des Hauses gesendet (VLAN Trunk mit VLAN10, VLAN12, VLAN14)
@ am Switch angekommen merkt der Switch, aha, ein Datenpaket für das VLAN12, da habe ich ja eine VLAN Trunk eingerichtet, über welchen unter anderem VLAN10, VLAN12, VLAN14 schlussendlich über eine anderen Switch Port physikalisch an die Leitung übergibt, welche in das UG des Hauses überführt wird.
@ auf dem Cisco SG300 Switch im UG angekommen merket der Switch, aha, ein Datenpaket für den NLB-Cluster (konfiguriert als IGMP Multicast) kommt daher und sendet dieses Multicast Paket an die VLAN12 NLB-IP 192.168.12.237 /27
@ prüft ich auf diesem Cisco SG300 Switch im UG unter dem Punkt Multicast/ MAC Group Addresses, so sehe ich, dass der Switch mitbekommen hat, wie die MAC Adresse des VLAN 12 NLB Clusters heisst und vermerkt diese dort in der Tabelle ebenfalls als 
01:00:5e:7f:0c:ed
@ der NLB Cluster für die Webseite www.webseite01.ch sendet die ICMP Antworten wieder zurück an die IP des Notebooks im EG des Hauses, welcher über das WLAN angeschlossen ist (im VLAN10) bzw. welches am Cisco SG350 hängt.
@ Resultat am Notebook, wenn ich ein Ping auf www.websiete01.ch absetze: Ich erhalte eine Antwort von der Cluster IP 192.168.12.237 /27 im VLAN12

Wiederhole ich dieses Spiel für die zweite Cluster IP, welche im VLAN14 konfiguriert ist, meiner Meinung nach genau gleich konfiguriert ist wie im VLAN12 Beispiel, erhalte ich beim Ping auf www.webseite02.ch (im VLAN14) KEINE Antwort (Zeitüberschreitung der Anforderung), dies, obwohl der Cisco SG300 Switch im UG des Hauses in der Multicast MAC Group Addresses interessanterweise auch, wie beim Beispiel vorher im VLAN12, die MAC Adresse der Cluster IP 192.168.14.242 ebenfalls bemerkt und gespeichert hat 
01:00:5e:7f:0e:f2

Zusammenfassung
@ Der Switch hat sowohl die MAC Adresse der Cluster-IP für das VLAN 12 wie auch die MAC Adresse für die Cluster-IP VLAN im VLAN14 gespeichert.
@ die Cluster-IP des VLAN12 kann ich pingen
@ die Cluster-IP des VLAN14 kann ich NICHT pingen (Zeitüberschreitung der Anforderung)
@ Unterschied der Netzwerkkonfiguration des VLAN12 und des VLAN14 sind: dass in den NIC Einstellungen auf Webserver1 als Beispiel (beide Webserver sind ja gleich konfiguriert, laufen auf dem physikalischen, gleichen Hpyer-V), dass nur für das VLAN12 ein GW hinterlegt ist. In den NIC 
Einstellungen für das VLAn14 ist kein GW hinterlegt. Somit, meiner Ansicht nach, werden Datenpakete wohl, welche an die Cluster IP 192.168.14.242 /27 gesendet werden, beim Zurücksenden an die Standardroute gesendet, nämlich 0.0.0.0 mask 0.0.0.0 GW 192.168.12.254 (IP der Sophos Firewall)
Da die Sophos Firewall aber alle VLANs kennt, so müsste meiner Ansicht nach auch die ICMP Pakete, welche an den NLB Cluster im VLAN14 gesendet werden, trotzdem den Rückweg zum Notebook im VLAN10 finden, was aber nicht der Fall ist.
Prüfe ich nämlich mit dem Netzwerkmonitor sowohl auf dem Notebook wie auch auf beiden Webservern, so stelle ich das gleiche fest, nämlich, dass die Webserver nur ICMP Requests erhalten, aber keine Antworten liefern bzw. senden :-( Warum?

Würde ich nun in den VLAN12 Einstellungen auf beiden Webservern für das 192.168.12.224 /27 Netz den GW entfernen und in der NIC für das VLAN14, ebenfalls auf dem gleichen Webserver eingerichtet, dort einen GW hinterlegen, also 192.168.14.254 /27 (welche auch auf die Sophos Firewall zeigt)
, so könnte ich die zweite Webseite pingen, jedoch dann die andere Webseite wiederum nicht mehr.
Mit anderen Worten, ich kann mit dieser Konstellation immer nur eine Webseite erreichbar machen, was mir so zurzeit unbegreiflich erscheint oder stehe ich gerade auf dem Schlauch? :-)

 

 

 

Link zu diesem Kommentar

Moin,

 

hui, sehr ausführlich ... nimm es mir nicht übel, aber ohne das alles durchzuarbeiten habe ich dazu vor allem eine Anmerkung: Niemals Windows-NLB. Das hat noch nie ordentlich funktioniert und wird es auch nie tun. Schon gar nicht im Zusammenhang mit Virtualisierung.

 

Rechne die Zeit, die du einsparst, in Budget um, und schau dich nach einer kommerziellen Lösung um, von der man weiß, dass sie funktioniert.

 

Gruß, Nils

 

Link zu diesem Kommentar

Hallo Nils

 

Oha, was für ein "Schlag in das Gesicht" aus Microsoft Sicht :-(
Also wenn ich so diverse Microsoft Artikel lese in Bezug NLB-Cluster, muss ich zugeben, noch keinen gefunden zu haben, welcher von einem Gebrauch eines NLB-Clusters in einer virtualisierten Umgebung abraten würde?!

 

Es interessiert mich brennend, wie Du zu einer solchen Aussage kommst - Gründe musst Du wohl haben, aber dessen Hintergrund/ Hintergründe würde ich sehr spannend finden :-)

Bemerkung: Wenn Du diese Lösung in dem Sinne nicht empfehlen möchtest/ kannst/ willst (warum auch immer), was sind deine Gegenvorschläge. Ich stelle mir eine Lösung vor, welche nach dem gleichen Prinzip funktioniert, aber demnach besser.

 

Denn die Technik, wie NLB technisch funktioniert, hat zumindest mein Interesse geweckt und ich finde, man hat sich schon was dabei überlegt (von der Grundidee her).

Muss aber auch ehrlicherweise zugeben, in diesem Bereich viel zu wenig bis praktisch keine Erfahrung nachweisen zu können. Ich bin lediglich durch Microsoft Foren/ Bücher auf diese Technik gekommen und dachte, super, wie schön auch immer die Theorie klingen mag, ich bin der Praktiker und will es auch testen und erfolgreich umsetzen.

 

cheers

André

Link zu diesem Kommentar

Glaub’s ihm einfach. Die nlb Komponente hatte die letzte wirkliche Änderung mit 2008 als igmp multicast dazu kam und die Probleme traten alle spätestens mit Beginn der virtualisierung auf. Aber auch ohne virtualisierung ist der Windows nlb Mist. Keine applikation awareness usw. hat einen Grund, warum ms bspw. Exchange nicht mehr mit der Windows nlb Möglichkeit bietet.

Link zu diesem Kommentar

Vielen Dank euch allen für diese rasche Antworten.
Ich nehme diese Antworten so gerne zur Kenntnis.

 

P.S.

@ Mich hat es halt irritiert, warum ich einen NBL Cluster via einen VLAN Hyper-V Switch (welcher stellvertretend für das physikalische Teaming zweier NICs steht) funktioniert.

@ füge ich auf einem dieser beiden Webserver im NLB Manager noch einen zweiten NLB Cluster hinzu und konfiguriere Ihn als IGMP Multicast (NLB Cluster IP ist in einem anderen VLAN als die andere NLB Cluster IP), so kann ich die zweite NLB Cluster IP nicht mehr pingen und somit auch die zweite Webseite nicht erreichen und dies hätte mich halt interessiert, warum und wieso.

 

Aber wenn natürlich die Bereitschaft zum Support diesbezüglich schon gar nicht erst vorhanden ist auf Grund von, ja sagen wir dem mal: "Desinteresse am NLB Produkt von Microsoft", kann ich auch nachvollziehen, warum bis jetzt noch gar Niemand Stellung genommen hat zu meiner doch sehr ausführlichen Schilderung.

 

Daraus habe ich soeben gelernt, zuerst einmal einen Einzeiler in das Forum schreiben und prüfen, ob das Interesse an der geschilderten Situation/ Konfiguration/ Produkt vorhanden ist und erst dann derart ausführlich die "Problematik" schildern. Die Zeit hätte ich mir demnach sparen können - tja …. Danke euch trotzdem und habt schöne Feiertage :-)

 

Nur so am Rande: im MCSA 2016 ist der NLB Cluster immer noch ein Bestandteil. Ich frage mich warum und wieso anscheinend Microsoft noch nicht gemerkt hat, dass dieses Produkt derart "sc***e" ist und es längst aus den Microsoft Prüfungen verbannt hat, würde ja sehr viel Sinn machen oder nicht? 

 

Nachtrag: ich konnte via Edge hier in diesem Forum warum auch immer im nachhinein nicht mehr die Sätze korrigieren, darum mache ich es halt im Nachgang :-)

Mit dem ersten Satz bei P.S. @ wollte ich eigentlich erwähnen, dass ich ohne Probleme einen NLB Cluster erfolgreich mit IGMP Multicast konfigurieren konnte, jedoch einen zweiten halt nicht.

Woran es gescheitert hat, hätte mich halt interessiert, das wollte ich damit eigentlich zum Ausdruck bringen :-)

Link zu diesem Kommentar

So, habe nun betreffend dem  Phänomen, dass ich von zwei NLB-Clustern nur einen pingen kann, anscheinend das Problem herausgefunden - die Lösung allerdings noch nicht?!

Die Ursache des Problems scheint im Routing zu liegen.

 

Einstellungen Webserver:

@ eine NIC im VLAN10 = damit der Webserver im LAN im produktiven LAN erreichbar ist (kein GW in den Netzwerkeinstellungen konfiguriert)
@ eine NIC im VLAN12 = damit www.beispielwebseite-eins.ch (die Cluster-IP) in einem separaten VLAN läuft (hat einen GW in den Netzwerkeinstellungen konfiguriert)
@ eine NIC im VLAN14 = damit www.beispielwebseite-zwei.ch (die Cluster-IP) in einem separaten VLAN läuft (kein GW in den Netzwerkeinstellungen konfiguriert)

Auswertung der Ping Analyse
@
vom Notebook im VLAN10 aus (192.168.10.224 /27) kann ich z.B. die Webseite www.beispielwebseite-eins.ch (Cluster-IP = 192.168.12.x) nur pingen, wenn in dessen Netzwerkeinstellungen eine GW Adresse hinterlege.
@ entferne ich in den Netzwerkeinstellungen der NIC (VLAN12) den GW und konfiguriere dafür in der NIC des VLAN14 einen Standard Gateway, so kann ich wie gewünscht die zweite Webseite www.beispielwebseite-zwei.ch vom Notebook aus dem VLAN10 pingen, jedoch die andere Webseite lässt ein ping nicht mehr zu (nachdem ich den Gateway entfernt habe).

Also wäre es ja logisch, wenn ich zwei Webseiten habe, welche ich im LAN erreichbar machen möchte, ich demzufolge auf jedem Webserver für jede NIC, an welche jeweils die Cluster-IPs Ihrer Webseite gebunden ist, für diese NICs in den Netzwerkeinstellungen auch einen Standard Gateway konfigurieren.

Nur ist das Problem, ein Webserver bzw. ein Host kann allgemein nur eine Default Route haben.

temporäre Lösung gefunden
Damit ich nun temporär von meinem Notebook aus beide Webseiten erreichen kann, habe ich halt temporär auf beiden Webservern in der Routingtabelle eine Host Route hinzugefügt, im Sinne von
192.168.10.xy mask 255.255.255.255 192.168.14.254 (VLAN14 IP der Firewall).

Das Problem scheint also im Routing zu liegen, nämlich, wenn ich mit meinem Notebook aus dem VLAN10 einen Ping auf die Cluster-IP 192.168.12.x ausführe, der Ping nur an meinen Notebook den Web zurück findet, wenn auf den Webservern in der VLAN12 NIC auch ein GW hinterlegt ist.

Da aber die Cluster-IP für die zweite Webseite im VLAN14 in den NIC Einstellungen der Webservern keinen GW hinterlegt hat und ich von meinem Notebook aus dem VLAN10 einen ping absetze, auf die Cluster-IP 192.168.14.x, der Ping beim Webserver den Rückweg in das VLAN10 zu meinem Notebook nicht findet.

Der Webserver mit der Cluster-IP im VLAN14 schaut ja dann in seiner Routingtabelle nach und stellt fest, ich habe eine Default Route für das VLAN12, also 192.168.12.x und sendet wohl die Antwort der ICMP Pakete an diesen GW (Firewall, Schnittstelle VLAN12) und die Firewall scheint damit nichts anfangen zu können, das ist meine Annahme, seht Ihr das auch so bzw. wie löse ich das Problem?

Eine statische Route auf der Firewall erfassen oder wie?
Ich verstehe nicht, warum ein Ping auf die Cluster-IP im VLAN14 (192.168.14.x) vom Webserver keine Rückantwort erfolgt oder erfolgen kann?
Das ICMP Pakete könnte oder müsste der Webserver doch an die Default Route schicken, sprich, an meine Firewall, welche ja alle VLANs kennt und somit sollte doch schlussendlich der Ping trotzdem wieder bei meinem Notebook ankommen oder wie jetzt?

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...