davidcoles/vc5Ein horizontal skalierbarer Direct-Server-Return-Layer-4-Load-Balancer für Linux mit XDP/eBPF
Diese README wird derzeit aktualisiert, um die jüngsten Änderungen zu berücksichtigen – einige Informationen entsprechen möglicherweise nicht dem aktuellen Codestand. Diese Codeiteration ist noch nicht produktionsreif – für den Produktionseinsatz eine v0.2-Version verwenden
Ein horizontal skalierbarer Layer-4-Lastverteiler (L4LB) mit Direct Server Return (DSR) für Linux mit XDP/eBPF.
Wenn Sie glauben, dass dies nützlich sein könnte, oder Fragen/Anregungen haben, können Sie mich gerne unter [email protected] kontaktieren oder ein GitHub-Issue eröffnen.
Unterstützt jetzt IPv6 und Verteilung auf Schicht 3 (auch Tunneling genannt)! Die XVS-Bibliothek wurde aktualisiert, um diese Funktionen zu enthalten, und macht zudem die Notwendigkeit überflüssig, Health Checks aus einem Network Namespace auszuführen, was den Code erheblich vereinfacht. Dies beendet die Anforderung, dass alle Backends ein VLAN mit dem Lastverteiler teilen.
Aktuelle Codeeinschränkungen bedeuten, dass die Aktivierung von Tunneling
pro Dienst nicht unterstützt wird. Die Verwendung der Option -tunnel ermöglicht
ein global aktiviertes Layer-3-Tunneling mit einem einzigen Schema
(IP-in-IP, GRE, FOU oder GUE). In Zukunft wird der Code aktualisiert,
um Tunneling auf Dienstebene konfigurieren zu können.
Layer-2-Lastverteilung wird weiterhin unterstützt – der Hauptgrund für den Start des Projekts war das Fehlen von Layer-2-Unterstützung beim Lastverteiler von Facebook's Katran.
Eine Beispielkonfigurationsdatei für IPv6/L3 ist enthalten – bessere Dokumentation folgt.
VC5 ist ein Netzwerk-Lastverteiler, der als Ersatz für
legacy Hardware-Appliances entwickelt wurde. Er ermöglicht es, Dienste mit virtuellen
IP-Adressen (VIPs) auf Gruppen von Backend-("echten")
Servern zu verteilen. Echte Server können die Dienste selbst ausführen oder als
Proxys für eine weitere Serverebene fungieren (z. B. HAProxy als Layer-7-
HTTP-Router/SSL-Offload, wenn Entscheidungen auf Anwendungsebene getroffen werden
müssen). Die einzige Anforderung ist, dass VIPs auf einem
Loopback-Gerät auf jedem echten Server konfiguriert werden müssen, z. B.: ip addr add 192.168.101.1/32 dev lo
Dienste und echte Server werden in einer Konfigurationsdatei zusammen mit Health-Check-Definitionen angegeben. Wenn die Backend-Server die Prüfungen bestehen und genügend davon verfügbar sind, um einen Dienst bereitzustellen, werden die virtuellen IP-Adressen über BGP an Router angekündigt.
Die Verteilung von Datenverkehr auf sowohl Schicht 2 als auch Schicht 3 wird jetzt unterstützt. Die Verteilung auf Schicht 2 erfordert, dass echte Server ein VLAN mit dem Lastverteiler teilen; beim Empfang eines zu verteilenden Pakets aktualisiert der Lastverteiler die Ethernet-Hardwareadressen im Paket, um die MAC-Adresse des echten Servers als Ziel und seine eigene MAC-Adresse als Quelle zu verwenden, und leitet das Paket über die entsprechende Schnittstelle weiter, wobei die 802.1Q-VLAN-ID aktualisiert wird, wenn Pakete VLAN-getaggt sind.
Die Verteilung auf Schicht 3 erfordert, dass Pakete in einem Tunnelprotokoll gekapselt werden, das an die IP-Adresse des echten Servers adressiert ist, und über einen Router weitergeleitet wird (sofern Server und Lastverteiler kein VLAN teilen). Wenn ein gekapseltes Paket die maximale Netzwerkübertragungsgröße überschreitet, wird eine ICMP-Nachricht an die Quelle gesendet, mit einem Hinweis auf die geeignete MTU. Backend-Server müssen Pakete nur entkapseln – bidirektionales Tunneling mit Lastverteilern ist nicht erforderlich.
Ein Server mit einer 10-Gbit/s-Netzwerkschnittstelle sollte in der Lage sein, einen HTTP-Dienst mit einer Egress-Bandbreite von über 100 Gbit/s zu unterstützen, aufgrund der asymmetrischen Natur des meisten Internetverkehrs. Für kleinere Dienste dürften ein oder zwei bescheidene virtuelle Maschinen einen Dienst bewältigen, der einige Gigabit/s an Egress-Verkehr erzeugt.
Wenn eine Instanz nicht ausreicht, können weitere Server hinzugefügt werden, um die Kapazität horizontal zu skalieren (und Redundanz zu bieten), mithilfe der ECMP-Funktion Ihres Routers. 802.3ad-gebondete Schnittstellen und 802.1Q-VLAN- Trunking werden unterstützt (siehe Verzeichnis examples/).
Es werden keine Kernelmodule oder komplexen Einrichtungen benötigt, obwohl für beste Leistung ein Netzwerkkartentreiber mit nativer XDP-Modus-Unterstützung empfohlen wird (z. B.: mlx4, mlx5, i40e, ixgbe, ixgbevf, nfp, bnxt, thunder, dpaa2, qede). Eine vollständige Liste ist auf The XDP Project's driver support page verfügbar.
Für beste Ergebnisse sollten Sie irqbalance deaktivieren/deinstallieren.
Sie müssen eine primäre IP auswählen, die Sie dem Balancer übergeben. Diese wird für die BGP-Router-ID verwendet.
Ein einfaches Beispiel auf einem Server mit einer einzelnen, ungetaggten Ethernet-Schnittstelle:
apt-get install git make libelf-dev golang-1.20 libyaml-perl libjson-perl ethtool (oder das Äquivalent Ihrer Distribution)ln -s /usr/lib/go-1.20/bin/go /usr/local/bin/go (stellen Sie sicher, dass sich die Go-Binärdatei in Ihrem PATH befindet)git clone https://github.com/davidcoles/vc5.gitcd vc5/cmdcp config.sample.yaml config.yaml (bearbeiten Sie config.yaml entsprechend Ihren Anforderungen)make (lädt die libbpf-Bibliothek herunter, erstellt die Binärdatei und die JSON-Konfigurationsdatei)./vc5 10.1.10.100 config.json eth0 (passen Sie die IP-Adresse und Ethernet-Schnittstelle Ihres Servers an)ip addr add 192.168.101.1/32 dev lo)Es ist mit ziemlicher Sicherheit einfacher, die Binärdatei aus dem neuesten Github- Release (kompiliert für x86-64) zu verwenden. Diese wurde in der Produktion getestet und sollte daher zuverlässig sein. Stellen Sie sicher, dass Ihre Konfiguration mit dieser Version kompatibel ist, indem Sie das config.pl-Skript aus dem getaggten Release verwenden (oder Sie können natürlich Ihre eigene JSON-Konfiguration erstellen, wie Sie möchten).
Wenn Sie die YAML-Konfigurationsdatei aktualisieren und die JSON neu generieren (make config.json), können Sie die neue Konfiguration neu laden, indem Sie ein
SIGINT (Strg-C) oder SIGUSR2 an den Prozess senden. SIGQUIT (Strg-) oder SIGTERM
bewirken, dass der Prozess BGP-Verbindungen ordnungsgemäß beendet und
sich beendet.
Ein komplexeres Beispiel mit einem LACP-gebondeten Ethernet-Gerät bestehend aus zwei Schnittstellen (auf meinem Testserver 10Gbps Intel X520), mit aktiviertem nativen XDP-Treibermodus und getaggten VLANs:
config.yaml-Eintrag für vlans:
vlans:
10: 10.1.10.0/24
20: 10.1.20.0/24
30: 10.1.30.0/24
Kommandozeile:
./vc5 -n 10.1.10.100 config.json enp130s0f0 enp130s0f1
Das Binärprogramm erkennt Ihre VLAN-Schnittstellen, indem es nach Geräten mit IP-Adressen sucht, die in den VLAN-Präfixen in der Konfigurationsdatei enthalten sind. Wenn Sie separate ungetaggte physische Schnittstellen verwenden, sollte dies nun ohne zusätzliche Konfiguration transparent funktionieren; listen Sie einfach alle Schnittstellen in der Kommandozeile auf, sodass der eBPF-Code in jede davon geladen wird.
Da der Verbindungsstatus pro Kern verfolgt wird (BPF_MAP_TYPE_LRU_PERCPU_HASH), sollten Sie sicherstellen, dass RSS (Receive Side Scaling) Pakete eines Flows konsistent zum selben CPU-Kern weiterleitet, falls Ihr Switch bei einer Änderung der LACP-Topologie eine andere Schnittstelle wählt. Deaktivieren Sie irqbalance, stellen Sie sicher, dass die Kanaleinstellungen auf jeder Schnittstelle gleich sind (ethtool -l/-L) und dass die RSS-Flow-Hash- Indirektion übereinstimmt (ethtool -x/-X).
Das Setup kann getestet werden, indem Sie eine lang laufende Verbindung
(z. B. mit iperf und der Option -t) zu einer Gruppe von Backend-Servern starten und dann
das gewählte Backend mit einem Sternchen nach der IP-Adresse in der
Konfigurationsdatei deaktivieren, ermitteln, welche Schnittstelle
den Flow auf dem Lastverteiler empfängt (z. B. watch -d 'cat /proc/interrupts | grep enp130s0f' und nach dem schnell
ansteigenden IRQ-Zähler suchen) und diese Schnittstelle dann aus LACP entfernen
(ifenslave -d bond0 enp130s0f0). Sie sollten sehen, dass sich der Flow zur
anderen Netzwerkschnittstelle bewegt, aber weiterhin denselben Kern trifft.
Wenn Sie Backends in mehreren Subnetzen verwenden, sollten Sie für beste Leistung
sicherstellen, dass alle VLANs auf einer einzigen Trunk-Schnittstelle getaggt sind
(LACP-gebondet, wenn Sie mehr als eine physische Schnittstelle haben), wobei die
Subnetz-/VLAN-ID-Zuordnungen im Abschnitt vlans der Konfigurationsdatei angegeben sind.
Wenn dies nicht möglich ist (z. B. weil das Erstellen von Trunk-Schnittstellen auf vSphere nicht einfach ist), können Sie jedes Subnetz einer anderen ungetaggten Schnittstelle zuweisen:
./vc5 10.1.10.100 config.json eth0 eth1 eth2
Eine gute Zusammenfassung der verwendeten Konzepte findet sich in Patrick Shuffs Vortrag "Building a Billion User Load Balancer" und Nitika Shirokovs Katran-Vortrag
Eine grundlegende Weboberfläche und ein Prometheus-Metrikserver sind enthalten: 
Experimentelle Elasticsearch-Unterstützung für Logging (direkt zu Ihrem
Cluster, kein Scraping von Systemprotokollen erforderlich) ist jetzt enthalten. Jede Sonde
zu Backend-Servern wird protokolliert. Wenn also einer ausfällt, können Sie
genau sehen, welcher Fehler zurückgegeben wurde, sowie alle möglichen anderen
Bedingungen. Dies erfordert viel Verfeinerung und sinnvollere
Benennung der Protokollparameter usw. (wenn Sie Einblicke haben, melden Sie sich
gerne), aber es sollte zu guten Einblicken führen,
was im System vor sich geht – mein sehr ungeschickter erster
Versuch, ein Kibana-Dashboard als Beispiel zu erstellen: 
Dies wurde hauptsächlich mit Icecast-Backend-Servern getestet, wobei Clients eine Mischung aus niedrigen und hohen Bitraten-Streams abrufen (48kbps – 192kbps).
Es scheint, dass eine VMWare-Gastmaschine (4 Kerne, 8GB) mit dem generischen XDP-Treiber 100.000 gleichzeitige Clients, 380Mbps/700Kpps durch den Lastverteiler und 8Gbps Datenverkehr von den Backends direkt zu den Clients unterstützt.
Auf einer einzelnen (nicht virtualisierten) Intel Xeon Gold 6314U-CPU (2.30GHz, 32 physische Kerne, mit Hyperthreading für 64 logische Kerne) und einer Intel 10G 4P X710-T4L-t-Ethernet-Karte konnte ich 700K Streams mit 2Gbps/3,8Mpps eingehendem Datenverkehr und 46,5Gbps ausgehendem Datenverkehr ausführen. Der Server war zu mehr als 90 % im Leerlauf. Leider hatte ich nicht die Ressourcen, um mehr Clients/Server zu erstellen.
Es gibt drei Betriebsmodi: einfach, VLAN und Multi-NIC. Im einfachen Modus müssen sich alle Hosts im selben Subnetz wie die primäre Adresse des Lastverteilers befinden. Im VLAN-Modus (aktiviert durch Deklarieren von Einträgen unter dem Abschnitt "vlans" der YAML/JSON-Konfigurationsdatei) müssen Servereinträge einem VLAN/CIDR-Subnetzeintrag entsprechen. VLAN-getaggte Schnittstellen müssen im Betriebssystem erstellt werden und eine IP-Adresse innerhalb des Subnetzes zugewiesen haben. Im Multi-NIC-Modus erhalten Subnetze IDs auf die gleiche Weise wie VLANs, aber bpf_redirect() wird verwendet, um Datenverkehr über die entsprechend konfigurierte Schnittstelle zu senden (anstatt die VLAN-ID zu ändern und XDP_TX zu verwenden).
Im VLAN-Modus muss der gesamte Datenverkehr für den Lastverteiler auf einem getaggten VLAN erfolgen (kein Push oder Pop von 802.1Q wird durchgeführt – noch nicht).