CCcam Server Lastverteilung: Einrichtung& Konfigurationshandbuch

\n\n

Das Betreiben mehrerer CCcam-Server klingt einfach, bis man die schwierige Aufgabe erkennt: Tausende von Clientverbindungen gleichmäßig auf sie zu verteilen, ohne die Stabilität zu verlieren.CCcam Server Lastverteilung ist die Praxis, eingehende Verbindungen auf mehrere Backend-Server aufzuteilen, um zu verhindern, dass eine einzelne Instanz zum Flaschenhals wird. Es ist keine Funktion, die in CCcam selbst integriert ist – sie muss auf Proxy- oder Client-Ebene hinzugefügt werden.

\n\n

Wenn Sie über einen einzelnen Server hinaus skalieren, behandelt dieser Leitfaden die tatsächlichen Architekturen, Konfigurationsdateien und Fehlersuche, die Sie tatsächlich benötigen. Wir überspringen das Marketing-Geschwätz und konzentrieren uns darauf, was funktioniert, was nicht funktioniert und warum.

\n\n

Was ist CCcam Lastverteilung und warum ist sie wichtig

\n\n

CCcam hat kein natives Multi-Server-Cluster. Jede CCcam-Instanz läuft unabhängig.CCcam Server Lastverteilung ist die Schicht, die Sie darüber aufbauen, um den Verkehr zu verteilen – entweder auf Proxy-Ebene (nginx, HAProxy, die vor mehreren CCcam-Instanzen sitzen) oder auf Client-Ebene (Clients, die mit mehreren Serveradressen konfiguriert sind und eine auswählen).

\n\n

Ein einzelner CCcam-Server verarbeitet typischerweise 500–1500 gleichzeitige Verbindungen, abhängig von CPU-Kernen, RAM, Kartenanzahl und ECM-Komplexität. Erreichen Sie diese Obergrenze, werden neue Clients entweder abgelehnt oder müssen warten, was unspielbare Kanäle oder Zeitüberschreitungen verursacht.

\n\n

Hier ist, was die Leute falsch verstehen: Lastverteilung macht Kanäle nicht schneller. Sie verhindert eine Sättigung. Die Geschwindigkeit wird durch die langsamste Karte in Ihrem Stapel und die Netzwerkverzögerung bestimmt. Aber Lastverteilung macht drei Dinge gut: Sie verhindert, dass ein Benutzer alle verfügbaren Verbindungen verbraucht, ermöglicht es Ihnen, mehr gleichzeitige Clients zu bedienen, und bietet Failover – wenn ein Server ausfällt, wird der Verkehr auf die anderen umgeleitet.

\n\n

Unterschied zwischen lokaler Lastverteilung und verteilter Lastverteilung

\n\n

Lokale Lastverteilung erfolgt auf der Client-Seite: Jeder Benutzer fügt mehrere CCcam-Server zu seiner Client-Konfiguration hinzu, und der Client wählt einen aus (in der Regel den ersten verfügbaren). Keine zentrale Orchestrierung. Es ist grob – alle Clients greifen auf den ersten Server zu, bis er ausfällt, dann wechseln sie zum zweiten.

\n\n

Verteilte Lastverteilung verwendet einen Proxy (nginx, HAProxy oder ein benutzerdefiniertes Gateway), der zwischen Clients und allen Backend-CCcam-Instanzen sitzt. Jede eingehende Verbindung trifft zuerst den Proxy, der sie basierend auf Last, Gesundheitsstatus oder Sticky-Regeln an ein Backend weiterleitet. Dies bietet Sichtbarkeit und Kontrolle.

\n\n

Wenn ein einzelner CCcam-Server zum Flaschenhals wird

\n\n

Achten Sie auf diese Anzeichen: CPU erreicht 90 %+ unter normaler Last, Verbindungszeitüberschreitungsfehler in den Client-Protokollen, ECM-Antwortzeiten verschlechtern sich während der Spitzenzeiten oder Benutzer berichten von eingefrorenen Kanälen, wenn andere streamen.

\n\n

An diesem Punkt hilft es nicht, mehr CPU hinzuzufügen – Sie haben die Verbindungsobergrenze erreicht. Sie müssen die Last auf mehrere Server verteilen.

\n\n

Auswirkungen auf die Stabilität des Card Sharings und die Qualität der Clientverbindungen

\n\n

Eine unausgeglichene Last verursacht kaskadierende Ausfälle. Ein langsamer Client, der eine einzelne Karte überlastet, kann ECM-Anfragen für alle anderen auf dieser Karte blockieren. Verteilen Sie die Last, und Sie compartmentalisieren das Problem – andere Clients bleiben unberührt.

\n\n

Die Stabilität verbessert sich, da der Ausfall eines einzelnen Servers nur einen Bruchteil der Benutzer betrifft, nicht alle. Geplante Wartungsarbeiten werden machbar: Entleeren Sie einen Server sanft, starten Sie ihn neu und bringen Sie ihn wieder online, während andere den Verkehr bedienen.

\n\n

Häufige Missverständnisse über Lastverteilung in CCcam-Umgebungen

\n\n

Mythos 1: Mehr Server bedeutet immer schnellere Geschwindigkeiten. Falsch. Wenn jeder Server schwache Karten oder hohe Latenz zum Kartenquelle hat, verbreitet das Hinzufügen von Servern nur das langsame Problem weiter.

\n\n

Mythos 2: Lastverteilung ist automatisch. Ist sie nicht. Sie müssen sie konfigurieren – entweder in den Client-Konfigurationen oder über einen Proxy.

\n\n

Mythos 3: DNS-Round-Robin funktioniert großartig für CCcam. Tut es nicht. DNS-Caches auf der Client-Ebene für Minuten oder Stunden, sodass alle Verbindungen von einem Benutzer weiterhin denselben Server erreichen. Round-Robin hilft nur, wenn verschiedene Benutzer zu unterschiedlichen Zeiten auflösen.

\n\n

Mythos 4: Ein Balancer kann eine fehlerhafte Kartenkonfiguration beheben. Wenn Ihre Karten den Durchsatz nicht bewältigen können, verteilt das Balancieren nur den Fehler auf mehr Server.

\n\n

Lastverteilungsarchitekturen für CCcam

\n\n

Es gibt fünf praktische Möglichkeiten,CCcam-Serverlastverteilungzu gestalten. Die meisten Setups verwenden eine der ersten drei.

\n\n

Reverse-Proxy-Ansatz (Nginx, HAProxy, Varnish)

\n\n

Ein Reverse-Proxy sitzt auf Port 12000 (oder einem anderen öffentlichen Port) und hört auf eingehende Clientverbindungen. Er leitet jede Verbindung an eine Backend-CCcam-Instanz weiter (die auf Port 12001, 12002 usw. läuft, entweder auf derselben Box oder auf verschiedenen Servern). Der Client kennt nur die IP und den Port des Proxys.

\n\n

Dies ist leistungsstark, da der Proxy gesamten Verkehr sieht, Verbindungsgrenzen pro Backend durchsetzt, aktive Gesundheitsprüfungen durchführt (Backend alle 10 Sekunden abfragt, um zu sehen, ob sie aktiv sind) und den Verkehr umverteilen kann, wenn ein Backend langsam oder ausgefallen ist.

\n\n

Der Kompromiss: Der Proxy selbst wird zu einem einzelnen Ausfallpunkt. Wenn er abstürzt, verlieren alle Clients die Verbindung, selbst wenn alle Backends in Ordnung sind. Sie bräuchten doppelte Proxys mit IP-Failover (keepalived), um das zu beheben.

\n\n

Client-seitige Lastverteilung (Mehrere Serveradressen in der Client-Konfiguration)

Der Client jedes Benutzers listet mehrere CCcam-Server in seiner Konfiguration auf. Der Client versucht den ersten. Wenn dieser fehlschlägt (Zeitüberschreitung oder abgelehnte Verbindung), versucht er den zweiten.

Es wird keine Infrastruktur benötigt – kein Proxy zu verwalten. Aber die Verkehrsverteilung ist schrecklich. Alle Clients belasten Server 1, bis Server 1 ausfällt. Dieser Ansatz skaliert auf ~100 Benutzer, bricht aber darüber hinaus zusammen.

Einige Client-Versionen unterstützen Randomisierung (Verbindung zu einem zufälligen Server aus der Liste beim Start), was die anfängliche Last besser verteilt. Aber einmal verbunden, bleibt der Client auf diesem Server, bis er gezwungen wird, zu wechseln.

DNS-Round-Robin-Methode und ihre Einschränkungen

Weisen Sie Clients auf einen DNS-Namen hin, der auf mehrere IPs auflöst (z.B. cccam.example.com → 192.168.1.10, 192.168.1.11, 192.168.1.12). DNS gibt alle drei IPs zurück, und die Clients wählen eine aus.

Theoretisch verteilt sich die Last gleichmäßig. In der Praxis werden DNS-Antworten zwischengespeichert. Ihr Client könnte einmal auflösen und diese zwischengespeicherte IP stundenlang wiederverwenden. In der Zwischenzeit lösen andere Clients zu unterschiedlichen Zeiten auf und treffen zufällig auf unterschiedliche IPs. Am Ende haben Sie eine zufällige Verteilung, nicht eine ausgewogene.

TTL (Time-to-Live)-Anpassungen helfen: Setzen Sie die DNS-TTL auf 10–30 Sekunden, damit Caches häufig aktualisiert werden. Aber das erhöht die DNS-Abfragebelastung und garantiert keine Verteilung.

Lassen Sie diesen Ansatz für CCcam aus. Er ist unzuverlässig.

Dedizierte CCcam-Proxy/Gateway-Lösungen

Einige Administratoren schreiben benutzerdefinierte Python- oder Bash-Skripte, die als Proxy-Schicht fungieren. Diese können spezifischer auf die CCcam-Protokollspezifika zugeschnitten sein als generische Proxys.

Beispiel: Ein Python-Skript lauscht auf Port 12000, akzeptiert eingehende Client-Verbindungen, liest die Anfrage des Clients, entscheidet, an welches Backend basierend auf der aktuellen Last weitergeleitet werden soll, proxy die Anfrage und gibt die Antwort zurück.

Vorteil: Sie kontrollieren die genaue Logik. Nachteil: Es ist benutzerdefinierter Code – Debugging, Testen und Wartung liegen bei Ihnen.

Für die meisten Administratoren ist nginx oder HAProxy einfacher und erprobt.

Hybrid-Ansätze, die Proxy + Client-Failover kombinieren

\n\n

Best Practice für große Setups: Verwenden Sie einen Proxy als primären Einstiegspunkt (Clients zeigen auf die Proxy-IP), konfigurieren Sie jedoch auch die Clients mit einer Fallback-Liste von Backend-IPs (für den Fall, dass der Proxy selbst ausfällt).

\n\n

Clients greifen auf den Proxy zu → der Proxy verteilt an die Backends. Wenn der Proxy ausfällt, können sich die Clients direkt mit einer Backend-IP aus ihrer Fallback-Liste verbinden.

\n\n

Dies erhöht die Komplexität, beseitigt jedoch das Problem des einzelnen Ausfallpunkts.

\n\n

Konfiguration von Nginx/HAProxy als CCcam-Lastenausgleich

\n\n

Lassen Sie uns ein echtesCCcam-Server-LastenausgleichSetup mit Nginx erstellen. Wir haben drei CCcam-Backends (Ports 12001, 12002, 12003) und Nginx als öffentlich zugänglichen Proxy auf Port 12000.

\n\n

Grundlegende Nginx-Upstream-Konfiguration für das CCcam-Protokoll

\n\n

Öffnen Sie Ihre Nginx-Konfiguration (typischerweise /etc/nginx/nginx.conf oder eine Site-Konfiguration in /etc/nginx/sites-enabled/). Fügen Sie diesen Upstream-Block hinzu:

\n\n

upstream cccam_backends {\n least_conn;\n server 192.168.1.10:12001 weight=1 max_fails=3 fail_timeout=30s;\n server 192.168.1.11:12002 weight=1 max_fails=3 fail_timeout=30s;\n server 192.168.1.12:12003 weight=1 max_fails=3 fail_timeout=30s;\n}\n\nserver {\n listen 12000;\n proxy_pass cccam_backends;\n proxy_connect_timeout 10s;\n proxy_timeout 300s;\n}

\n\n

least_conn sagt Nginx, neue Verbindungen an das Backend mit den wenigsten aktiven Verbindungen zu leiten. Dies ist besser als einfaches Round-Robin für zustandsbehaftete Protokolle wie CCcam.

\n\n

max_fails=3 fail_timeout=30s bedeutet: Wenn ein Backend 3 Verbindungsversuche innerhalb von 30 Sekunden fehlschlägt, markieren Sie es für 30 Sekunden als ausgefallen und hören Sie auf, Verkehr dorthin zu senden.

\n\n

proxy_timeout 300s ist kritisch – CCcam-Verbindungen sind langlebig (Benutzer sehen stundenlang fern). Lassen Sie Nginx die Verbindungen nicht nach wenigen Sekunden abbrechen. 300 Sekunden sind angemessen; passen Sie es basierend auf Ihrer Netzwerkverzögerung an.

\n\n

Laden Sie Nginx neu:nginx -s reload. Überprüfen Sie zuerst die Syntax:nginx -t.

\n\n

HAProxy Backend-Pool-Setup mit Gesundheitsprüfungen

\n\n

HAProxy ist funktionsreicher für protokollspezifisches Balancing. Hier ist eine grundlegende Konfiguration (/etc/haproxy/haproxy.cfg):

\n\n

global\n maxconn 10000\n log /dev/log local0\n chroot /var/lib/haproxy\n stats socket /run/haproxy/admin.sock mode 660 level admin\n stats timeout 30s\n daemon\n\ndefaults\n log global\n mode tcp\n maxconn 5000\n timeout connect 10s\n timeout client 300s\n timeout server 300s\n\nfrontend cccam_in\n bind *:12000\n default_backend cccam_servers\n\nbackend cccam_servers\n balance leastconn\n option tcp-check\n tcp-check connect port 12001\n server backend1 192.168.1.10:12001 check inter 10s fall 3 rise 2 weight 1 maxconn 1000\n server backend2 192.168.1.11:12002 check inter 10s fall 3 rise 2 weight 1 maxconn 1000\n server backend3 192.168.1.12:12003 check inter 10s fall 3 rise 2 weight 1 maxconn 1000

\n\n

balance leastconn verwendet die gleiche Strategie wie nginxs least_conn.

\n\n

check inter 10s fall 3 rise 2 bedeutet: Überprüfen Sie jeden Backend alle 10 Sekunden. Wenn 3 Überprüfungen fehlschlagen, markieren Sie es als ausgefallen. Wenn 2 aufeinanderfolgende Überprüfungen erfolgreich sind, markieren Sie es als wiederhergestellt. Dies erkennt Ausfälle in 20–30 Sekunden.

\n\n

maxconn 1000 begrenzt die Verbindungen zu jedem Backend auf 1000. Wenn ein Backend diese Obergrenze erreicht, wartet HAProxy auf neue Verbindungen, bis eine geschlossen wird. Passen Sie dies basierend auf der Kapazität Ihres CCcam-Servers an.

\n\n

Neu laden:systemctl reload haproxy. In Echtzeit überwachen:echo "show stat" | socat - /run/haproxy/admin.sock (wenn Sie den Statistik-Socket konfiguriert haben).

\n\n

Verbindungs-Persistenz und Überlegungen zur Sitzungsbindung

\n\n

CCcam ist zustandsbehaftet. Wenn sich ein Client verbindet und authentifiziert, erstellt der CCcam-Server eine Sitzung mit den Anmeldeinformationen und Kartenzuweisungen dieses Benutzers. Wenn die Verbindung während der Sitzung zu einem anderen Backend wechselt, verliert der Client diesen Zustand und muss sich erneut authentifizieren.

\n\n

Deshalb sind Sticky Sessions wichtig. Sobald ein Client mit Backend 1 verbunden ist, sollten nachfolgende Verbindungen von diesem Client zu Backend 1 gehen (bis Backend 1 ausfällt, dann auf ein anderes umschalten).

\n\n

In nginx aktivieren Sie Sticky Sessions mit ip_hash:

\n\n

upstream cccam_backends {\n ip_hash;\n server 192.168.1.10:12001;\n server 192.168.1.11:12002;\n server 192.168.1.12:12003;\n}

\n\n

ip_hash verwendet die IP des Clients, um zu bestimmen, welches Backend die Verbindungen dieses Clients erhält. Alle Verbindungen von derselben IP treffen konsequent dasselbe Backend.

\n\n

In HAProxy verwenden Sie Quell-basierte Sticky Sessions:

\n\n

backend cccam_servers\n balance source\n server backend1 192.168.1.10:12001 check inter 10s fall 3 rise 2\n server backend2 192.168.1.11:12002 check inter 10s fall 3 rise 2\n server backend3 192.168.1.12:12003 check inter 10s fall 3 rise 2

\n\n

balance source verwendet die Quell-IP als Hash-Schlüssel, genau wie nginxs ip_hash.

\n\n

Kompromiss: Sticky Sessions reduzieren echtes Lastenausgleich (ein gesprächiger Client bleibt bei einem Backend), sind aber notwendig für das zustandsbehaftete Protokoll von CCcam. Akzeptieren Sie diese Einschränkung.

\n\n

Gewichtsverteilung (Ungleichmäßige Serverkapazitätsbehandlung)

\n\n

Wenn Backend 1 4 Karten und Backend 2 8 Karten hat, geben Sie ihnen kein gleiches Gewicht. Setzen Sie das Gewicht von Backend 2 höher, um mehr Verkehr dorthin zu leiten.

\n\n

Nginx-Syntax:

\n\n

upstream cccam_backends {\n ip_hash;\n server 192.168.1.10:12001 weight=1;\n server 192.168.1.11:12002 weight=2;\n server 192.168.1.12:12003 weight=1;\n}

\n\n

Das sagt nginx: Für jede 1 Verbindung, die an Backend 1 gesendet wird, senden Sie 2 an Backend 2 und 1 an Backend 3. Das kombinierte Verkehrsverhältnis beträgt 1:2:1.

\n\n

HAProxy-Syntax (in der Serverzeile):

\n\n

server backend2 192.168.1.11:12002 check inter 10s fall 3 rise 2 weight 2 maxconn 2000

\n\n

Hinweis: Auch die maxconn auf 2000 für den schwereren Server erhöht.

\n\n

Wie berechnet man Gewichte? Beginnen Sie mit Kapazitätsverhältnissen. Wenn Backend 2 doppelt so viel CPU und doppelt so viele Karten hat, versuchen Sie Gewicht 2. Überwachen Sie 24 Stunden lang. Überprüfen Sie die Protokolle, um die tatsächliche Verbindungsverteilung zu sehen. Wenn Backend 2 immer noch unterversorgt ist, erhöhen Sie das Gewicht auf 3. Dies ist ein Versuch-und-Irrtum—es gibt keine Formel.

\n\n

Timeout- und Verbindungsgrenzen-Tuning

\n\n

Timeouts sind kritisch. CCcam-Clients können stundenlang untätig sein (Fernsehen schauen, keine ECMs abrufen). Setzen Sie die Leerlauf-Timeouts nicht unter 30 Minuten.

\n\n

In nginx:

\n\n

server {\n listen 12000;\n proxy_pass cccam_backends;\n proxy_connect_timeout 10s;\n proxy_send_timeout 300s;\n proxy_read_timeout 300s;\n}

\n\n

proxy_connect_timeout: wie lange gewartet werden soll, wenn eine Verbindung zu einem Backend geöffnet wird (10s ist angemessen).

\n\n

proxy_read_timeout undproxy_send_timeout: wie lange gewartet werden soll, bis ein Backend antwortet, bevor die Verbindung als tot betrachtet wird. 300s (5 Minuten) verhindert das Töten von inaktiven Verbindungen. Erhöhen Sie auf 1800s (30 Minuten), wenn Sie mehr Toleranz wünschen.

\n\n

Verbindungsgrenzen (Dateideskriptoren): Linux begrenzt die offenen Dateideskriptoren pro Prozess standardmäßig auf 1024. Nginx benötigt 2 Dateideskriptoren pro proxied Verbindung (einen zum Client, einen zum Backend). Bei 500 Clients sind Sie bei ~1000 Dateideskriptoren—erreichen Sie die Grenze.

\n\n

Erhöhen Sie die Grenze in der nginx-Konfiguration:

\n\n

worker_processes auto;\nworker_rlimit_nofile 65536;

\n\n

Überprüfen Sie die aktuellen Grenzen:ulimit -n zeigt das Limit pro Shell,cat /proc/sys/fs/file-max zeigt das systemweite Limit. Permanently in /etc/security/limits.conf setzen:

\n\n

nginx soft nofile 65536\nnginx hard nofile 65536

\n\n

Neuladen:systemctl restart nginx.

\n\n

Überwachung und Protokollierung des Lastenausgleichsverkehrs

\n\n

Aktivieren Sie die Zugriffsprotokolle in nginx, um den Verkehrsfluss zu sehen:

\n\n

access_log /var/log/nginx/cccam_access.log;\nerror_log /var/log/nginx/cccam_error.log warn;

\n\n

Protokolle analysieren, um zu sehen, welcher Backend-Verkehr erhält. Beispiel: Zähle Verbindungen pro Backend-IP:

\n\n

tail -f /var/log/nginx/cccam_access.log | awk '{print $3}' | sort | uniq -c

\n\n

Dies zeigt, wie viele Protokolleinträge (Verbindungen/Anfragen) jede Backend-IP erreicht.

\n\n

Für HAProxy gehen die Protokolle an syslog. Überprüfen Sie sie:

\n\n

tail -f /var/log/syslog | grep haproxy

\n\n

Überwachen Sie Echtzeitstatistiken mit der Web-UI von HAProxy (optionale Konfiguration) oder der Befehlszeile:

\n\n

echo "show stat" | socat - /run/haproxy/admin.sock | column -t -s,

\n\n

Dies gibt den Backend-Status, aktive Verbindungen, Bytes und Ergebnisse der Gesundheitsprüfung aus.

\n\n

Client-seitige Lastverteilungskonfiguration

\n\n

Wenn Sie keinen Proxy bereitstellen, können Sie die Last dennoch verteilen, indem Sie Clients mit mehreren Servern konfigurieren. Es ist grober, erfordert jedoch keine Infrastruktur.

\n\n

Hinzufügen mehrerer Servereinträge zu cclient.conf

\n\n

Die Client-Konfigurationsdatei (typischerweise /etc/CCcam/cclient.conf auf Linux-Boxen oder config in der Client-App) listet CCcam-Server auf. Standardformat:

\n\n

CServer = server.example.com 12000 benutzername passwort\nCServer = 192.168.1.10 12001 benutzername1 passwort1\nCServer = 192.168.1.11 12002 benutzername2 passwort2\nCServer = 192.168.1.12 12003 benutzername3 passwort3

\n\n

Jede Zeile ist ein Servereintrag. Der Client liest sie der Reihe nach. Beim Start versucht er, sich mit dem ersten Server zu verbinden. Wenn dies fehlschlägt (Zeitüberschreitung oder verweigerte Verbindung), versucht er den nächsten.

\n\n

Sobald eine Verbindung zu einem Server hergestellt ist, bleibt der Client dabei. Eine erneute Verbindung erfolgt nur bei Netzwerkfehlern oder einem Neustart des Benutzers.

\n\n

Client-seitige Failover-Reihenfolge und Priorität

\n\n

Die Reihenfolge ist wichtig. Setzen Sie Ihren schnellsten/zuverlässigsten Server an die erste Stelle, damit die Clients ihn bevorzugen. Setzen Sie die Backups an die letzte Stelle.

\n\n

Einige Client-Versionen beachten die Reihenfolge nicht – sie wählen bei jedem Neustart zufällig aus der Liste aus. Überprüfen Sie die Dokumentation oder den Quellcode Ihres Clients.

\n\n

Wenn Ihr Client dies unterstützt, können Sie auch die Priorität oder das Gewicht pro Server angeben (die Syntax variiert je nach Client-Typ).

\n\n

Randomisierung vs. sequenzielle Serverauswahl

\n\n

Sequenzielle Auswahl: Versuchen Sie Server 1, wenn dieser fehlschlägt, versuchen Sie Server 2 usw. Dies ist die Standardeinstellung. Alle Clients landen auf Server 1, bis dieser ausfällt, dann wechseln sie zu Server 2. Schlechte Lastverteilung.

\n\n

Randomisierung: Bei jedem Client-Neustart wird ein zufälliger Server aus der Liste ausgewählt. Dies verteilt die anfängliche Last besser. Aber es ist immer noch keine echte Lastverteilung – einmal verbunden, bleibt der Client auf diesem Server.

\n\n

Wenn Ihr Client es unterstützt, aktivieren Sie die Randomisierung. Es hilft, aber erwarten Sie, dass 80 % der Clients auf Ihrem schnellsten Server und 20 % auf anderen verteilt sind.

\n\n

Auswirkungen auf die Leistungskennzahlen beim Kartenteilung

\n\n

Eine unausgeglichene Verteilung auf der Client-Seite verschlechtert die Leistung unter Last. Wenn 80 Clients auf einen Server drängen und 20 sich auf zwei andere verteilen, wird der stark belastete Server für alle darauf langsamer, während andere unterausgelastet sind.

\n\n

Sie werden ungleichmäßige ECM-Antwortzeiten sehen: Einige Clients berichten von 100 ms Latenz, andere von 1000 ms, alles weil sie auf unterschiedlichen Servern mit unterschiedlichen Lastniveaus sind.

\n\n

Deshalb skaliert das Client-seitige Balancing nicht gut über ~100 Benutzer hinaus.

\n\n

Aktualisierung mehrerer Server ohne Unterbrechung des Clients

\n\n

Wenn Sie die cclient.conf aktualisieren müssen (Server hinzufügen/entfernen), übertragen Sie die neue Konfiguration an alle Clients. Methoden:

\n\n

1. Direkte Dateiübertragung (wenn Sie die Client-Maschinen kontrollieren):scp cclient.conf benutzer@clientip:/etc/CCcam/.

\n\n

2. Konfigurationsserver: Richten Sie einen einfachen HTTP-Server ein, der die Konfiguration bereitstellt. Clients holen sie regelmäßig ab. Erfordert Client-Unterstützung für externe Konfigurations-URLs (nicht alle CCcam-Clients unterstützen dies).

\n\n

3. Dokumentation: Informieren Sie die Benutzer, dass sie ihre Konfigurationsdateien manuell aktualisieren sollen.

\n\n

Bei der Aktualisierung sollten Sie sowohl die alten als auch die neuen Servereinträge für 24 Stunden beibehalten und dann die alten entfernen. Dies verhindert, dass Clients während des Übergangs die Verbindung verlieren.

\n\n

Überwachung und Fehlersuche bei Lastverteiltem CCcam

\n\n

Ein ausgewogenes Setup bleibt nur dann ausgewogen, wenn Sie es überwachen und Probleme beheben, sobald sie auftreten.

\n\n

Gesundheitsprüfungsstrategien (Ping, Verbindungsprüfungen, ECM-Timeout-Überwachung)

\n\n

Einfacher TCP-Check: Der Proxy öffnet eine Verbindung zum Port des Backends und schließt sie wieder. Wenn die Verbindung erfolgreich ist, ist das Backend aktiv. Dies erkennt vollständige Abstürze, übersieht jedoch Leistungsabfälle (langsame Backends, ECM-Timeouts, hängende Prozesse).

\n\n

Besserer Ansatz: Aktives Überwachen der ECM-Antwortzeiten. Jedes CCcam-Backend protokolliert ECM-Zugriffe und Antwortzeiten. Analysiere diese Protokolle, um die durchschnittliche Latenz pro Backend über ein 5-Minuten-Fenster zu berechnen. Wenn die Latenz eines Backends einen Schwellenwert überschreitet, markiere es als beeinträchtigt und reduziere sein Gewicht oder nehme es offline.

\n\n

Noch besser: Implementiere ein benutzerdefiniertes Gesundheitsprüfskript, das sich mit jedem Backend verbindet, eine Test-ECM-Anfrage sendet, die Antwortzeit misst und den Status meldet.

\n\n

Beispiel für ein Bash-Skript (sehr einfach):

\n\n

#!/bin/bash\n\nBACKENDS=("192.168.1.10:12001" "192.168.1.11:12002" "192.168.1.12:12003")\n\nfor backend in "${BACKENDS[@]}"; do\n host=$(echo $backend | cut -d: -f1)\n port=$(echo $backend | cut -d: -f2)\n \n timeout 3 bash -c "cat< /dev/null > /dev/tcp/$host/$port" 2>/dev/null\n if [ $? -eq 0 ]; then\n echo "$backend: AKTIV"\n else\n echo "$backend: INAKTIV"\n fi\ndone

\n\n

Führe dies alle 10 Sekunden über Cron oder eine Daemon-Schleife aus. Analysiere die Ausgabe und passe die Proxy-Konfiguration basierend auf den Ergebnissen an.

\n\n

Identifizierung überlasteter Backend-Server in Protokollen

\n\n

Jeder CCcam-Server protokolliert seine Aktivitäten. Überprüfe das Hauptprotokoll (oft /etc/CCcam/cccam.log oder journalctl für systemd-Dienste):

\n\n

tail -f /etc/CCcam/cccam.log | grep ECM

\n\n

Achte auf Muster: Steigende ECM-Antwortzeiten, Fehlermeldungen über Karten-Timeouts oder Reader-Disconnects oder erreichte Verbindungsgrenzen.

\n\n

Zähle aktive Verbindungen auf einem Backend (vom Backend-Server selbst):

\n\n

netstat -an | grep :12001 | grep ESTABLISHED | wc -l

\n\n

Ersetze 12001 durch den Port des Backends. Dies zeigt die gleichzeitigen Verbindungen an. Wenn es konstant an deinem maxconn-Limit (z.B. 1000) liegt, ist das Backend gesättigt.

\n\n

Detailliertere Socket-Informationen:

\n\n

ss -tnp | grep :12001

\n\n

Listet alle Verbindungen auf Port 12001 mit Prozessinformationen. Achten Sie auf Verbindungen im Zustand CLOSE_WAIT (Verbindungen hängen, schließen nicht richtig – ein Zeichen für blockierte CCcam-Prozesse).

\n\n

Ungleichmäßige Verbindungsverteilung Ursachen und Lösungen

\n\n

Wenn Ihr Proxy 90% der Verbindungen auf einem Backend und 10% auf anderen zeigt, sind mögliche Ursachen:

\n\n

1. Gewichtsmisconfiguration: Überprüfen Sie die Proxy-Konfiguration und vergewissern Sie sich, dass die Gewichte Ihrem beabsichtigten Verhältnis entsprechen. Beispiel für einen Tippfehler: weight=0 deaktiviert versehentlich ein Backend.

\n\n

2. Sticky Sessions defekt: Wenn Sie Quell-IP-Hashing verwenden, aber alle Clients von derselben IP kommen (NAT, Unternehmensfirewall), landet der gesamte Verkehr auf einem Backend. Lösung: Wechseln Sie zu Round-Robin oder least-conn (aber dann wird der Sitzungsstatus des Clients verstreut – Kompromiss).

\n\n

3. Ein Backend ist viel schneller: Wenn Backend 1 auf neuerer Hardware und Backend 2 älter ist, bevorzugen die Clients natürlich Backend 1 (geringere Latenz, schnellere Antworten). Reduzieren Sie das Gewicht von Backend 1, um etwas Last auf Backend 2 zu zwingen, oder rüsten Sie Backend 2 auf.

\n\n

4. Gesundheitsprüfungen denken, dass ein Backend ausgefallen ist: Überprüfen Sie die Proxy-Protokolle, um zu sehen, ob irgendwelche Backends aufgrund fehlgeschlagener Gesundheitsprüfungen als ausgefallen markiert sind. Selbst ein fehlgeschlagener Test kann eine Markierung als ausgefallen auslösen. Lösung: Lockern Sie die Schwellenwerte für die Gesundheitsprüfung (erhöhen Sie fail_timeout oder rise/fall-Parameter).

\n\n

5. Client-seitige Konfiguration nicht aktualisiert: Wenn Sie die Gewichte im Proxy geändert haben, die Clients jedoch weiterhin eine fest codierte Serverliste haben, überschreibt der Client-seitige Failover die Proxy-Balancierung. Lösung: Aktualisieren Sie die Client-Konfigurationen.

\n\n

Erkennung von Verbindungslecks und hängenden Sitzungen

\n\n

Ein Verbindungsleck ist, wenn Verbindungen geöffnet, aber nie richtig geschlossen werden. Sie verbleiben im Zustand CLOSE_WAIT oder TIME_WAIT und verbrauchen Systemressourcen.

\n\n

Achten Sie auf: Die Anzahl der Verbindungen des Backend-Servers steigt stetig an, ohne zu sinken, selbst wenn die Last stabil ist. Nach 1 Woche wächst sie von 100 auf 500 Verbindungen (kein Benutzerwachstum). Das ist ein Leck.

\n\n

Diagnose:

\n\n

ss -tnp | grep :12001 | grep CLOSE_WAIT | wc -l

\n\n

Zählen Sie die CLOSE_WAIT-Verbindungen. Wenn dies im Laufe der Zeit zunimmt, gibt es ein Leck (CCcam-Prozess schließt Sockets nicht richtig oder der Client trennt die Verbindung ohne ordnungsgemäßen Schließhandshake).

\n\n

Vorübergehende Lösung: Backend neu starten. Dauerhafte Lösung: CCcam-Protokolle auf Fehler oder Patches für Verbindungsprobleme untersuchen. Kontaktieren Sie den CCcam-Anbieter oder überprüfen Sie Community-Foren auf bekannte Probleme.

\n\n

Hängende Sitzungen: Verbindungen, die offen, aber blockiert sind (Client sendete Daten, Backend antwortet nie). Aus der Sicht des Backends sind dies ETABLIERTE Verbindungen, die einen Slot verbrauchen, aber keinen Fortschritt machen.

\n\n

Überwachen Sie die ECM-Timeout-Fehler in den Protokollen. Wenn sie häufig auftreten, deutet dies darauf hin, dass Backends bei Kartenlesungen hängen. Erhöhen Sie die Timeouts in der Proxy-Konfiguration oder fügen Sie einen Verbindungs-Leerlauf-Timeout hinzu (schließen Sie Verbindungen, die X Minuten lang keine Daten senden).

\n\n

Zu verfolgende Metriken: Antwortzeiten, ECM-Erfolgsquote, Verbindungsanzahl pro Server

\n\n

Wichtige Metriken:

\n\n

ECM-Antwortzeit: Zeit vom Client-Antrag bis zur Backend-Antwort. Analysieren Sie die CCcam-Protokolle: Jeder ECM-Eintrag protokolliert einen Zeitstempel und die Antwortzeit. Berechnen Sie den Durchschnitt pro 5-Minuten-Fenster pro Backend. Alarmieren Sie, wenn der Durchschnitt 500 ms überschreitet.

\n\n

Verbindungsanzahl: führen Sienetstat -an | grep :port | grep ESTABLISHED | wc -l jede Minute aus und zeichnen Sie es auf. Achten Sie auf stetiges Wachstum (Leck) oder einen Anstieg auf maxconn (Sättigung).

\n\n

ECM-Erfolgsquote: Prozentsatz der ECM-Anfragen, die eine gültige Antwort zurückgegeben haben (im Vergleich zu Timeout oder Fehler). Protokolle analysieren: zählen Sie "ECM gefunden" gegen "ECM-Timeout"-Nachrichten. Ziel >95%.<95% bedeutet, dass Karten langsam sind oder die Netzwerkverzögerung hoch ist.

\n\n

Backend-Verfügbarkeit: Prozentsatz der Zeit, in der jedes Backend als aktiv markiert war (nicht aufgrund von Gesundheitsprüfungsfehlern außer Betrieb). Zeichnen Sie dies über Tage/Wochen auf. Wenn ein Backend auf 50% Verfügbarkeit sinkt, untersuchen Sie, warum die Gesundheitsprüfungen fehlschlagen.

\n\n

Tool-Vorschlag: Verwenden Sie Prometheus (kostenlos, Open Source), um Metriken von einem einfachen Python/Bash-Exporter-Skript, das Sie schreiben, abzurufen. Visualisieren Sie mit Grafana. Oder verwenden Sie einen einfacheren Ansatz: Bash-Skript, das Metriken in CSV protokolliert, dann mit gnuplot grafisch darstellen.

\n\n

Tools zur Echtzeit-Lastüberwachung (netstat, ss, benutzerdefinierte Skripte)

\n\n

netstat -an | grep :port zeigt alle Verbindungen an einem Port. Fügen Sie Filter hinzu:

\n\n

netstat -an | grep ESTABLISHED | grep :12001 | wc -l # zählt etablierte Verbindungen am Port 12001\nnetstat -an | grep CLOSE_WAIT | grep :12001 | wc -l # zählt blockierte Verbindungen

\n\n

ss -tnp | grep :port | sort -k4 -rn zeigt Verbindungen sortiert nach Zustand, nützlich um herauszufinden, welche IPs verbunden sind.

\n\n

lsof -i :port listet offene Dateien (einschließlich Sockets) an einem Port mit Prozessinformationen:lsof -i :12001 | tail -5 zeigt die letzten 5 Verbindungen.

\n\n

Erstellen Sie ein Überwachungsskript in Bash/Python, das alle 60 Sekunden ausgeführt wird und Metriken in eine Datei protokolliert oder an einen Überwachungsdienst sendet. Beispiel-Shell-Schleife:

\n\n

while true; do\n echo "$(date): $(netstat -an | grep :12001 | grep ESTABLISHED | wc -l) Verbindungen"\n sleep 60\ndone > /var/log/cccam_monitor.log

\n\n

Dann grafisch darstellen oder basierend auf Schwellenwerten alarmieren.

\n\n

Gewichtsbasierte Verteilung für heterogene Server

\n\n

Echte Setups haben keine identischen Server. Sie könnten eine neuere 4-Kern-Maschine und eine ältere 2-Kern-Maschine haben. Oder eine mit 8 Karten, eine mit 4.

\n\n

Warum Server unterschiedliche Kapazitäten haben (CPU, Kartenanzahl, Netzwerk)

\n\n

Hardware altert. Sie fügen Server schrittweise hinzu und kaufen, was verfügbar ist. Die Netzwerkverbindung variiert (ein Server ist 10Mbps von der Kartenquelle entfernt, ein anderer 100ms). Die Kartenzuweisungen sind ungleichmäßig (ein Server erhält schnelle Karten, ein anderer langsame).

\n\n

Gleiches Gewicht (1:1) wird den schwächeren Server sättigen, während der stärkere unterausgelastet bleibt.

\n\n

Gewichte in Nginx und HAProxy festlegen

\n\n

Nginx (im Upstream-Block):

\n\n

upstream cccam_backends {\n ip_hash;\n server 192.168.1.10:12001 weight=1; # älterer 2-Kern\n server 192.168.1.11:12002 weight=2; # neuer 4-Kern\n}

\n\n

HAProxy (in der Serverzeile, Backend-Abschnitt):

\n\n

backend cccam_servers\n balance leastconn\n server backend1 192.168.1.10:12001 weight=1 maxconn 500\n server backend2 192.168.1.11:12002 weight=2 maxconn 1000

\n\n

Hinweis: maxconn ebenfalls proportional anpassen. Wenn das Gewicht 2x ist, sollte maxconn 2x sein.

\n\n

Berechnung optimaler Gewichtungsverhältnisse

\n\n

Beginnen Sie mit der Kapazitätsschätzung:

\n\n

CPU: Zählen Sie die Kerne. 4 Kerne = ungefähr 2x Durchsatz von 2 Kernen. Gewichtungsverhältnis = 2:1.

\n\n

Karten: Zählen Sie die Anzahl der Karten. 8 Karten = 2x Karten von 4 Karten (wenn die Karten ähnliche Geschwindigkeiten haben). Gewichtungsverhältnis = 2:1.

\n\n

Kombinieren: Wenn Server B 2x Kerne und 2x Karten im Vergleich zu Server A hat, Gewichtungsverhältnis = 2:1.

\n\n

Netzwerklatenz: Wenn Server A in einem 10ms LAN und Server B in einem 100ms WAN ist, kann Server A ECMs schneller verarbeiten. Reduzieren Sie das Gewicht von Server B leicht (z.B. 1,5:1 anstelle von 2:1).

\n\n

Formel-ähnlich:

\n\n

weight_B / weight_A = (cores_B / cores_A) * (cards_B / cards_A) * (latency_A / latency_B)\n

\n\n

Passen Sie dann empirisch an.

\n\n

Gewichte basierend auf der realen Leistung anpassen

\n\n

Bereitstellen mit geschätzten Gewichten. 24 Stunden überwachen. Überprüfen Sie die Proxy-Protokolle, um die tatsächliche Verbindungsverteilung zu sehen:

\n\n

tail -100000 /var/log/nginx/cccam_access.log | awk '{print $3}' | sort | uniq -c

\n\n

Wenn die Verteilung 1000 Verbindungen auf Server A und 3000 auf Server B beträgt, aber Sie das Gewicht 1:2 eingestellt haben, funktioniert der Proxy korrekt. Überprüfen Sie, ob Server B damit umgeht (CPU, ECM-Latenz immer noch gut). Wenn ja, sind die Gewichte richtig. Wenn Server B Schwierigkeiten hat, reduzieren Sie sein Gewicht auf 1,5.

\n\n

Wenn die Verteilung 2000 auf A und 1000 auf B mit Gewicht 1:2 beträgt, werden die Gewichte nicht eingehalten – überprüfen Sie die Proxy-Konfiguration oder starten Sie den Proxy neu, um die Konfiguration neu zu laden.

\n\n

Überwachen Sie die ECM-Antwortzeiten pro Backend. Wenn beide Backends trotz ungleicher Last identische Latenzen aufweisen, könnten die Gewichte zu gleich sein (Verbreitung erhöhen). Wenn die Latenz eines Backends trotz geringerer Last viel höher ist, könnte es langsamere Karten oder ein langsames Netzwerk haben – reduzieren Sie sein Gewicht.

\n\n

Häufige Fehler: Gleiches Gewicht für ungleiche Hardware

\n\n

Der größte Fehler: einen neuen 16-Kern-Server neben einem alten 8-Kern-Server bereitzustellen und beide auf Gewicht=1 zu setzen. Der alte Server wird überlastet, während der neue zu 50 % untätig ist.

\n\n

Ein weiterer: Latenz ignorieren. Ein Server in der Nähe der Kartenquelle (5 ms) sollte mehr Gewicht erhalten als einer, der weit entfernt ist (50 ms), selbst wenn beide die gleichen Kerne/Karten haben.

\n\n

Drittens: Gewichte nicht anpassen, wenn sich die Hardware ändert. Sie rüsten Server A von 4 Kernen auf 8 Kerne auf, vergessen jedoch, sein Gewicht von 1 auf 2 zu aktualisieren. Er ist jetzt unterausgelastet.

\n\n

Failover- und Redundanzmuster

\n\n

Lastverteilung geht nicht nur um Verteilung – es geht darum, Serverausfälle zu überstehen.

\n\n

Aktiv-Passiv vs. Aktiv-Aktiv Failover-Modi

\n\n

Aktiv-Passiv: Ein Server ist primär (bearbeitet den gesamten Verkehr), die anderen sind Backup (inaktiv). Wenn der Primärserver ausfällt, wechselt der Verkehr zu einem Backup. Einfach, aber Sie zahlen für Hardware, die ungenutzt bleibt.

\n\n

Typische Konfiguration: Server A (aktiv) und Server B (passiv). Alle Clients/Proxy leiten zu A. Überwachen Sie Server A. Wenn er ausfällt, leitet der Administrator manuell oder automatisch (über ein Skript) den Verkehr zu B um. Die Clients verbinden sich erneut, erleben eine kurze Unterbrechung und setzen auf B fort.

\n\n

Aktiv-Aktiv: Alle Server sind online und bedienen gleichzeitig den Verkehr. Kein inaktives Backup. Wenn ein Server ausfällt, übernehmen die verbleibenden Server den verlorenen Verkehr. Effizientere Ressourcennutzung.

\n\n

Trade-off: CCcam ist zustandsbehaftet (Sitzung an Server gebunden), daher erfordert echtes aktives-aktives entweder Sitzungsreplikation (komplex) oder sticky sessions (Client kehrt immer zum gleichen Server zurück, sodass bei einem Failover der Zustand verloren geht).

\n\n

Die meisten Implementierungen verwenden aktives-aktives mit sticky sessions und sanftem Failover: Clients akzeptieren eine kurze Wiederverbindung, wenn ihr Server ausfällt.

\n\n

Überwachungsintervalle und Ausfallerkennungszeit

\n\n

Proxy-Gesundheitsprüfungen laufen alle N Sekunden (z. B. 10s). Wenn eine Prüfung fehlschlägt, wird sie als ein Fehler markiert. Nach M aufeinanderfolgenden Fehlern (z. B. 3) wird das Backend als ausgefallen markiert und aus der Rotation entfernt. Minimale Erkennungszeit = Prüfintervall * M = 10s * 3 = 30 Sekunden.

\n\n

Schnelle Erkennung: Prüfintervall auf 5s setzen und Fehlerschwelle auf 2. Erkennungszeit = 10s. Clients erleben 10s Ausfallzeit vor dem Failover.

\n\n

Trade-off: Häufige Prüfungen erhöhen die Last auf den Backends und führen zu Fehlalarmen (vorübergehendes Netzwerkproblem markiert Backend fälschlicherweise als ausgefallen).

\n\n

Konservativ: Intervall 30s, Schwelle 3. Erkennungszeit = 90s. Toleranter gegenüber Netzwerkproblemen, aber der Benutzer erlebt 90s Ausfallzeit während eines echten Ausfalls.

\n\n

Empfehlung: Beginnen Sie mit einem Intervall von 10s und 3 Fehlern. Überwachen Sie auf Fehlalarme. Wenn es wenige Fehlalarme gibt, reduzieren Sie auf ein Intervall von 5s und 2 Fehlern.

\n\n

Sanftes Herunterfahren des Servers ohne Clients zu trennen

\n\n

Wenn Sie ein Backend neu starten müssen, töten Sie es nicht einfach. Lassen Sie es sanft auslaufen:

\n\n

1. Setzen Sie sein Gewicht im Proxy auf 0. Dadurch werden neue Verbindungen zu ihm gestoppt, aber bestehende bleiben bestehen.

\n\n

2. Warten Sie, bis bestehende Verbindungen geschlossen sind (beobachten Sie den Rückgang der Verbindungsanzahl über netstat). Typischerweise 5–30 Minuten, abhängig vom Benutzerverhalten.

\n\n

3. Sobald die Verbindungsanzahl 0 erreicht, stoppen Sie den CCcam-Prozess.

\n\n

4. Führen Sie Wartungsarbeiten durch (Aktualisierung, Neustart usw.).

\n\n

5. Starten Sie CCcam. Stellen Sie das Gewicht auf den normalen Wert wieder her.

\n\n

Nginx: Konfiguration bearbeiten, Gewicht auf 0 setzen, neu laden:nginx -s reload. Überwachen:watch -n 1 'netstat -an | grep :12001 | grep ESTABLISHED | wc -l'. Sobald 0, CCcam neu starten.

\n\n

HAProxy: Verwenden Sie den Admin-Socket über die Kommandozeile:echo "set server cccam_servers/backend1 weight 0" | socat - /run/haproxy/admin.sock. Dann wie oben fortfahren. Kein Reload erforderlich.

\n\n

Verhalten bei Wiederverbindung nach Serverwiederherstellung

\n\n

Wenn ein ausgefallenes Backend wieder online kommt:

\n\n

Wenn Clients gewaltsam von ihm getrennt wurden, verbinden sie sich wieder mit dem Proxy/Lastenausgleich (nicht mit dem spezifischen Backend). Der Lastenausgleich leitet sie basierend auf den aktuellen Ausgleichsregeln weiter. Sie landen wahrscheinlich auf einem anderen Backend (es sei denn, es sind sticky Sessions aktiviert und das alte Backend ist ihr sticky Ziel).

\n\n

Wenn Clients auf dem Backend waren, als es ausfiel, erleben sie einen Verbindungsabbruch und müssen sich erneut verbinden. Besseres Verhalten: Verwenden Sie einen sanften Drain (Gewicht auf 0), damit die Clients natürlich fertig werden und sich erneut verbinden, anstatt abrupt getrennt zu werden.

\n\n

Wiederherstellung der Gesundheitsprüfung: Sobald ein Backend wieder online gebracht wird und die erste Gesundheitsprüfung bestanden hat, markiert der Proxy es als "aktiv" und fügt es wieder zur Rotation hinzu. Zweite und nachfolgende Prüfungen müssen ebenfalls bestehen (basierend auf dem "rise"-Parameter, z.B. rise=2 bedeutet 2 aufeinanderfolgende Bestehen). Nach Bestehen des rise ist es vollständig aktiv.

\n\n

Backup-Server-Konfiguration und -Test

\n\n

Für Hochverfügbarkeitskonfigurationen auch einen Backup-Proxy konfigurieren. Wenn Ihr primärer Proxy (nginx) ausfällt, gehen alle Clientverbindungen verloren, obwohl die Backends in Ordnung sind.

\n\n

Dual-Proxy-Setup mit keepalived (virtuelle IP-Fehlertoleranz):

\n\n

Zwei nginx-Instanzen (nginx-primary und nginx-backup) auf verschiedenen Servern teilen sich eine virtuelle IP (z.B. 192.168.1.200). Clients verbinden sich mit der virtuellen IP. Keepalived überwacht den primären nginx-Prozess. Wenn er ausfällt, wechselt keepalived die virtuelle IP zum Backup-nginx. Clients werden automatisch innerhalb weniger Sekunden auf das Backup umgeleitet.

\n\n

Setup (grobe Skizze):

\n\n

1. Installieren Sie keepalived auf beiden Servern:apt-get install keepalived.

\n\n

2. Konfigurieren Sie /etc/keepalived/keepalived.conf auf dem primären Server, um nginx zu überwachen und die virtuelle IP zu bewerben.

\n\n

3. Konfigurieren Sie das Backup ähnlich, jedoch mit niedrigerer Priorität.

\n\n

4. Beide führen identische nginx-Konfigurationen aus.

\n\n

5. Starten Sie keepalived auf beiden. Der primäre Server übernimmt die virtuelle IP. Wenn der primäre nginx abstürzt, erkennt keepalived dies und verschiebt die IP zum Backup.

\n\n

Testen: Beenden Sie den primären nginx, während Sie die virtuelle IP überwachen (ping -c 1000 192.168.1.200 und auf eine kurze Unterbrechung achten). Wenn nginx abstürzt, wird keepalived die IP innerhalb von ~3 Sekunden zum Backup verschieben. Die Clients erleben einen kurzen Ping-Verlust und verbinden sich dann erneut mit dem Backup.

\n\n

Dies erhöht die Komplexität, beseitigt jedoch den Proxy als einzelnen Fehlerpunkt.

\n\n

FAQ

\n\n