davidcoles/vc5Ein horizontal skalierbarer Direct-Server-Return-Layer-4-Load-Balancer für Linux mit XDP/eBPF
# VC5 <picture> <img src="https://assets.kitploit.com/production/public/readmes/9322/203eb45ff2205aa56eaf10f0d0ea7be21a35972366b34252c91fc6e78a40818c.png" width="25%"> </picture> **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](https://www.loadbalancer.org/blog/direct-server-return-is-simply-awesome-and-heres-why/)) für Linux mit [XDP/eBPF](https://www.datadoghq.com/blog/xdp-intro/). 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](https://github.com/facebookincubator/katran). Eine [Beispielkonfigurationsdatei für IPv6/L3](https://github.com/davidcoles/vc5/blob/main/doc/ipv6-l3.yaml) ist enthalten – bessere Dokumentation folgt. ## Über 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/](https://github.com/davidcoles/vc5/blob/main/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](https://github.com/xdp-project/xdp-project/blob/master/areas/drivers/README.org) verfügbar. ## Ziele/Status * ✅ Einfache Bereitstellung mit einer einzigen Binärdatei * ✅ Stabile Backend-Auswahl mit dem Maglev-Hashing-Algorithmus * ✅ Automatische Injektion von Routen-Health-Checks; keine Notwendigkeit, andere Software wie ExaBGP auszuführen * ✅ Minimalinvasiv; erfordert keine Änderung von iptables-Regeln auf dem Balancer * ✅ Keine Änderung an Backend-Servern außer dem Hinzufügen der VIP zu einem Loopback-Gerät/Tunnelabschluss bei L3-Verteilung * ✅ Health Checks werden gegen die VIP auf Backend-Servern ausgeführt, nicht gegen deren echte Adressen * ✅ Integrierte HTTP/HTTPS-, Half-Open-SYN-Probe- und UDP/TCP-DNS-Health-Checks * ✅ Paketvermittlung im Kernel mit eBPF/XDP; Treiber im nativen Modus vermeiden die sk_buff-Zuweisung * ✅ Unterstützung mehrerer VLANs * ✅ Unterstützung mehrerer NICs für Anwendungen mit geringerer Bandbreite/Entwicklung * ✅ Getaggte/gebondete Netzwerkgeräte zur Unterstützung von Hochverfügbarkeit/Hoher Bandbreite * ✅ Beobachtbarkeit über eine Weboberfläche, Elasticsearch-Logging (in Entwicklung) und Prometheus-Metriken * ✅ IPv6-Unterstützung und die Möglichkeit, IPv4- und IPv6-Backends mit beiden VIP-Typen zu mischen. * ✅ Layer-3-Datenverkehrsverteilung mit IP-in-IP-, GRE-, FOU- und GUE-Unterstützung. ## Schnellstart 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.git` * `cd vc5/cmd` * `cp config.sample.yaml config.yaml` (bearbeiten Sie config.yaml entsprechend Ihren Anforderungen) * `make` (lädt die [libbpf](https://github.com/libbpf/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) * Eine Weboberfläche ist standardmäßig auf Port 80 Ihres Lastverteiler-Servers verfügbar * Fügen Sie Ihre VIP zum Loopback-Gerät auf Ihren Backend-Servern hinzu (z. B.: `ip addr add 192.168.101.1/32 dev lo`) * Konfigurieren Sie Ihr Netzwerk/Ihren Client so, dass Datenverkehr für Ihre VIP an den Lastverteiler gesendet wird, entweder über BGP (siehe Konfigurationsdatei) oder statisches Routing 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](https://www.kernel.org/doc/Documentation/networking/scaling.txt)) 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](https://github.com/davidcoles/vc5/blob/main/doc/servers.md), 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` ## Hintergrund/weitere Informationen Eine gute Zusammenfassung der verwendeten Konzepte findet sich in [Patrick Shuffs Vortrag "Building a Billion User Load Balancer"](https://www.youtube.com/watch?v=bxhYNfFeVF4&t=1060s) und [Nitika Shirokovs Katran-Vortrag](https://www.youtube.com/watch?v=da9Qw7v5qLM) 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:  ## Leistung 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. ## Betrieb 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).
