Fortgeschritten: ucarp-Cluster im LAN

Barungar

Well-known member
Hallo zusammen,

ab einer gewissen Größe und "Bedeutung" des eigenen LANs möchte man sich immer weniger in die Fänge von SPoFs (Single Point of Failure) begeben.

Ein SPoF ist ein Punkt im eigenen Netz, der durch einen Ausfall das ganze System zum Wanken bringt. In den meisten Fällen ist das z.B. im heimischen LAN der Router. Es können aber auch weitere Geräte hinzukommen. Am längsten behält diesen Titel aber in der Regel der heimische Router.

In vielen Fällen kann bei der Beiseitigung von SPoF das ucarp oder carp behilflich sein. CARP bedeutet Common Address Redundancy Protocol, frei übersetz übliches Adress-Redundanz-Protokoll. Das CARP ist dabei eine enger Verwandter des VRRP (Virtual Router Redundancy Protocol), das bei Routern zum Einsatz kommt.

Die theoretische Funktionsweise von CARP ist dabei, dass man n (>1) an Systemen hat, die eine gemeinsame Aufgabe erledigen können und sollen. Dabei wird durch CARP keine aktiv-aktiv Redundanz geschaffen, sondern lediglich eine aktiv-passiv Redundanz. Das bedeutet von den n-Dienstanbietern (z.B. Servern) ist immer nur einer aktiv und bearbeitet alle Anfragen. Die restlichen (n-1) Teilnehmer am CARP-Cluster warten nur darauf, dass der aktive Knoten ausfällt, um dann erst einzuspringen.

Möchte man lieber ein aktiv-aktiv Cluster, so muss man auf Lastverteilung (load balancing) setzen. Dieses Verfahren ist aber noch ein wenig komplexer.

Als Beispiel nehmen wir einfach mal an, dass wir das DNS in unserem lokalen Netz ausfallsicherer machen möchten. Nun kann man natürlich einfach zwei DNS-Server betreiben. Das rettet alle Clients, die mehr als DNS-Server in ihrer Konfiguration verarbeiten können. Es gibt aber auch Fälle, wo Geräte auf Grund von Einschränkunen nur einen DNS-Server beherrschen. Fällt dieser eine DNS aus, dann sind diese Systeme bis zu einem manuellen Eingriff oder der Wiederherstellung des ausgefallenen DNS-Servers von den DNS-Diensten abgeschnitten.

Praktisch könnte man diese Redundanz mit CARP so umgesetzen.

Nehmen wir an, wir möchten unser DNS durch ein einfaches CARP-System mit zwei Knoten, A und B, absichern. Das könnten z.B. zwei kleine Raspberry Pi mit pihole sein. Der Knoten A hat die IP 192.168.23.21 und der Knoten B hat die IP 192.168.23.22. Damit haben wir nun genau das oben beschriebene Szenario von zwei getrennten DNS-Servern. Das CARP bringt nun eine dritte, die virtuelle CARP-IP ins Spiel. In diesem Spiel wäre es die 192.168.23.23.

Folgende Parameter werden für die CARP-Konfiguration benötigt
  • die Schnittstelle
    ist der Name des Netzwerkadapters im System z.B. eth0 oder enp2s0
  • die Quelle-IP
    ist die (echte) IP-Adresse des Knoten selber
  • die CARP-IP
    ist die gemeinsam zu nutzende virtuelle IP-Adresse des CARP
  • die virtuelle Gruppen-ID
    kennzeichnet eindeutig einen CARP-Cluster
  • die Frequenz
    wie oft sendet der aktive Cluster-Knoten seinen Heartbeat
  • der Schiefstand (skew)
    ein Abweichungswert, der zusammen mit der Frquenz die Cluster-Priorität dieses Knotens ergibt
  • ein Passwort
    zur Absicherung der CARP-Gruppe sollte auch ein Passwort definiert werden
Nimmt man nun Knoten A und B, so teilen sich diese typischer Weise die folgenden die CARP-IP (192.168.23.23), die virtuelle Gruppen-ID (23), die Frequenz (1) und das Passwort (geheim). Individuell sind die Schnittstelle, die Quell-IP und der Schiefstand. Die virtuelle Gruppen-ID ist, zwischen 1 ... 255, frei wählbar, sie muss aber für jeden CARP-Cluster eineindeutig sein!

Für Knoten A könnten die Werte sein: eth0, 192.168.23.21, 192.168.23.23, 23, 1, 0, geheim.
Für Knoten B könnten die Werte sein: eth0, 192.168.23.22, 192.168.23.23, 23, 1, 100, geheim.

Damit wäre, wenn beide Systeme online wären Knoten A der aktive Knoten, weil seine Cluster-Priorität aus Freuqenz & Schiefstand den geringsten Wert hat. Knoten A würde nun also die CARP-IP 192.168.23.23 als zusätzliche IP-Adresse (secondary ip address) an seine vorgegebene Netzwerkschnittstelle binden.

Fällt der aktive Knoten A aus, so übernimmt in unserem Beispiel Knoten B die CARP-IP. Wird Knoten A, zu einem späteren Zeitpunkt wiederhergstellt, so wird er wieder der aktive Knoten, weil seine Cluster-Priorität weiterhin besser ist als die von Knoten B. Es findet somit eine automatisch Rückübernahme der CARP-IP statt.

Im Normal-Zustand hat man in dieser Konstellation nun DNS-Dienste unter den folgenden IPs: 192.168.23.21, 192.168.23.22 und 192.168.23.23 - abgesichert ist die .23
 
Nur der Vollständigkeit halber (nicht, dass hier falsche Hoffnungen geweckt werden) - da Du Pi-Hole erwähnt hast - man erreicht dann zwar eine Failover-Lösung über "eine" IP (ähnlich einem vorgeschalteten Loadbalancer), ein Abgleich zwischen 2 Pi-Hole-Instanzen findet aber nicht statt. Somit hat weiterhin jede Instanz eigene Logs, Statistiken, eigene DNS-Einträge, etc.

Will man da auch noch alles einheitlich haben, müsste man sich noch darum kümmern, dass diese Dinge auch abgeglichen werden. Nach kurzer Suche gibt es für die Pi-Hole-Installationen wohl auch ein entsprechendes Script pihole-gemini - Two-way Pi-hole lists sync, habe es aber nicht getestet, setze auch kein Pi-Hole ein 🙃

Alternativ kann man natürlich auch hingehen und die 2 Pi-Hole-Instanzen als DNS1 + DNS2 an die Geräte im Netz verteilen und alternativ dazu kann man sich - falls man es z.B. sowieso schon laufen hat - auch einfach z.B. haproxy/etc. als Loadbalancer bedienen (womit die Verteilung dann allerdings von einem 3. System abhängt (der Loadbalancer-Instanz)).
 
Alternativ kann man natürlich auch hingehen und die 2 Pi-Hole-Instanzen als DNS1 + DNS2 an die Geräte im Netz verteilen
Das löst aber nicht alle Probleme. Wie ich z.B. beschrieben habe, kann der DHCP von der Fritz.box nur einen DNS. Und selbst wenn man über eine anderen DHCP zwei DNS verteilen läßt, kann das nicht jeder Client.

Du hast recht, was Logs und Regeln angeht. Aber der 2. pihole läuft ideal NIE aktiv. Da ist das zu verschmerzen.
 
Achja, die Fritzbox... Das Ding im Netz, welches gerne einfach für alles (und vor allem "alleine") zuständig sein möchte - mein Fehler - hab die Rechnung wieder ohne die Tücken einer Fritzbox aufgemacht 😁 Alternativ nutzen (habe ich zumindestens gelesen, nutze den Pi-Hole nicht selbst) wohl viele den Pi-Hole auch als DHCP-Server. Der dürfte dann doch wohl theoretisch 2 DNS-Server verteilen können?
 
Warum macht man daraus keine Anleitung für die Hauptseite? Hier im Forum geht es irgendwann unter.
 
Der dürfte dann doch wohl theoretisch 2 DNS-Server verteilen können?
Alles schön und gut, aber gerade IoT-Geräte und viele Androiden nehmen nur EINEN DNS-Server aus der DHCP-Konfig. Da hat man mit zwei DNS-Servern deutlich weniger Ausfallsicherheit als wie mit einer CARP Lösung.
 
aber gerade IoT-Geräte und viele Androiden
Keine Ahnung, mein Android-Tablet hat brav mehrere drin (und nutzt bei bedarf auch mehrere), meine Telefone, IP-Cams, etc. ebenso. Bin aber auch kein IoT-Spezi 😇

EDIT: Hast Du dafür irgendeine Referenz, ich finde da leider nix zu :unsure: (Ist nicht so, als würde ich das in Frage stellen, es interessiert mich nur, da ich sowas bisher noch nie gehört/gesehen habe ☺️)
 
Zuletzt bearbeitet:
CARP kommt ursprünglich aus der OpenBSD Ecke und ist deren freie und sichere alternative zu VRRP.
Beim lesen ist mir nicht klar geworden das ucarp eine Implementierung von CARP ist. Während mir VRRP in Form von keepalivd und nahe Verwandte in Form von MetalLB in der Vergangenheit oft über den Weg gelaufen ist, kenne ich CARP tatsächlich erst seit OPNsense.
 

Zurzeit aktive Besucher

Letzte Anleitungen

Statistik des Forums

Themen
5.801
Beiträge
56.669
Mitglieder
5.718
Neuestes Mitglied
Vossberger
Zurück
Oben