Re: Routing-Hilfe
Hallo,
Christoph Pleger <Christoph.Pleger@cs.tu-dortmund.de>:
>Der Vserver erbringt Dienste für verschiedene Subnetze, der Rechner hat
>also noch weitere Netzwerk-Interfaces.
Bereits hier muss man beachten, dass bei Linux-VServer alle VServer und
der Host stets eine gemeinsame Routingtabelle nutzen. Das heisst, im
Idealfall sollte jeder VServer in jedem lokalen Subnetz jeweils eine
eigene IP-Adresse haben. Notfalls kann man auch die entsprechende Host-
Adresse mitbenutzen, muss aber dann auf Portnummernkonflikte achten.
Sobald du etwas anderes willst, erfordert das Policy based Routing Regeln
und macht die Sache komplex.
>Neben dem Rechner (Master) steht
>ein zweiter Rechner (Slave), der per ucarp automatisch die Dienste des
>Masters übernimmt, wenn dieser ausfällt. Beide Rechner haben
>eine eigene, nur für sie bestimmte IP-Adresse (auf eth1), es gibt aber
>auch eine gemeinsame IP-Adresse (auf eth0): Wenn ein Rechner startet,
>überprüft er, ob die gemeinsame Adresse im Subnetz schon vorhanden ist,
>falls nicht, wird er zum Master, fährt eth0 und die anderen Interfaces
>hoch, gibt eth0 die gemeinsame IP-Adresse und startet den Vserver.
Ich kenne ucarp nicht, aber das massenhaft erprobte Standardtool für
die genannte Aufgabe ist meines Erachtens heartbeat. Bei einem
heartbeat-Cluster überprüft jeder Knoten ständig die Verfügbarkeit
des anderen Knoten und übernimmt bei Ausfall dessen Ressourcen (wozu
auch die virtuellen IP-Adressen gehören).
>Der Grund dafür, warum ich zwei Netzwerk-Interfaces im selben
>Subnetz verwende, ist folgender: Wenn der Master ausfällt und der
>Slave übernimmt, kann es aufgrund von ARP-Caches ziemlich lange
>dauern, bis im Subnetz bekannt ist, dass sich die der gemeinsamen
>IP-Adresse zugeordnete MAC-Adresse geändert hat.
Die übliche Lösung dafür ist das Versenden von Gratuitous ARP Paketen,
nachdem der Cluster geschwenkt hat. Heartbeat macht das automatisch,
wenn man zum Schwenken der IP-Adresse das mitgelieferte Ressourcenskript
verwendet.
>Dieses Problem versuche ich zu vermeiden, indem ich per ifconfig eine
>andere MAC-Adresse zuweise, sobald ein Rechner die Master-Rolle übernimmt.
Damit wird das Problem aber nur auf ein anderes verlagert, welches
unter Umständen noch kniffliger ist. Denn der Switch speichert die
Zuordnung, welche MAC Adresse über welchen Port erreichbar ist, auch
für eine bestimmte Zeit. Je nach verwendeten Switch-Typ kann es sein,
dass man darauf kaum oder gar keinen Einfluss hat.
>Das funktioniert
>aber nur vor der Aktivierung eines Netzwerk-Interfaces. eth1 muss aber
>auf jeden Fall beim Start des Rechners aktiviert werden, unabhängig
>davon, ob ein Rechner Master oder Slave ist. Daher brauche ich
>zwei Interfaces im selben Subnetz, so dass gleichzeitig eine
>Netzwerkverbindung besteht und die MAC-Adresse geändert werden kann.
Man kann durchaus auch auf einem physischen Interface mehrere MAC
Adressen benutzen, beispielsweise durch Verwendung von Linux Bridging.
Kurz gesagt, ich würde das Setup auf ein Heartbeat-Cluster umstellen
und dann auf dem jeweils aktiven Knoten den VServer starten. Als IP-
Adresse des VServers würde ich die von Heartbeat verwaltete Cluster-
Adresse verwenden, damit Heartbeat das Gratuitous ARP automatisch
handhabt. In der VServer Konfiguration muss das "nodev" Flag gesetzt
sein, damit beim Beenden des VServers die IP-Adresse nicht von VServer
gelöscht wird (sondern von heartbeat).
Wenn du wirklich bei dem Setup mit ucarp und den zwei Netzwerkkarten
bleiben willst, solltest du überlegen, ob Linux-VServer das richtige
Tool für dich ist. Mit Xen hat jede virtuelle Maschine ihren eigenen
Kernel und damit eine eigene Routingtabelle. Setups mit unterschiedlichem
Routing oder eigenen MAC Adressen sind damit kein Problem.
Gruß, Harald
Reply to: