Cluster Heartbeat - best practice?

Hallo zusammen,

jedes Mal wenn Server in unseren Clustern Giftpillen schlucken, frage
ich mich, ob es nicht Optimierungsmöglichkeiten gibt...

Die Situation: 3 2-Server-Cluster, 2 unter NW65Sp8, 1 unter
OES2SP1/Linux. Die Server sind Blades und hängen LAN-mäßig direkt an
unserem zentralen Router. Storage und Booten über FC-SAN.

Den großen Vorteilen der Cluster (Schutz bei Hardwaredeffekt, Vermeidung
von Down-Zeit bei Wartungsarbeiten) steht ein "kleiner" Nachteil
gegenüber: erhöhte Empfindlichkeit gegenüber externen Problemen,
Down-Zeit wird zwar vermieden, aber die Zahl kurzer Verbindungsabbrüche
steigt.

Konkret: Jede Netzwerkunterbrechung, Router-Reboot wg. Firmwareupdate,
etc. führt zu einem Poison-Pill-Abend, und damit zu zwei
Verbindungsunterbrechungen der betroffenen Cluster-Ressourcen (inkl.
Failback).

Geplante/vorhersehbare solche Ereignisse kann man mit dem
Maintenance-Mode entschärfen - nicht zur Begeisterung unseres
Netz-Admins, der in entsprechenden Situationen nun auch daran noch
denken muss. Nicht geplante solche Ereignisse sind selten, aber - und
das ist der Punkt, auf den ich eigentlich hinaus will - in der Praxis
doch häufiger als die Hardwaredefekte, vor denen der Cluster schützen
soll, um genau zu sein: bei uns bisher unendlich mal häufiger.

Wo könnte man optimieren...?

Netzwerkdesign? Redundante Anbindung, nicht direkt am zentralen Router?
Wie ich es auch drehe und wende - eine wirklich überzeugende Lösung
fällt mir nicht ein. Es darf ja kein Fall eingeführt werden, wo ein
failover nicht stattfindet, obwohl er es sollte. Ein eigenes Subnetz für
den Heartbeat ist damit schon mal keine Lösung. Der Heartbeat müsste
redundante Wege zur Verfügung haben - der Client-Zugriff aber
entsprechend auch. Gibt es eine solche Lösung? (Ohne irrwitzigen
Aufwand, etwa mit mehr als zwei LAN-Ports pro Blade und/oder redundanten
Routern.)

Heartbeat Timeout hoch drehen?

Oder sich einfach damit abfinden und mit den gelegentlichen Abends leben?

Gruß,
Mirko
[ Auf dieses Posting antworten ]