Multi-cloud

    VMware Avi vs. NSX Advanced LB: Der Architektur Deep Dive 2026

    TechLeague Editorial··14 Min. Lesezeit

    Im Jahr 2026 ist der hardwarezentrierte Load Balancer offiziell ein Relikt; wenn Sie immer noch Traffic über ein Paar physischer F5 BIG-IP-Appliances schicken, um Microservices durch Load Balancing zu verteilen, verlieren Sie operationale Effizienz und erzeugen unnötige Latenz. Die Entwicklung von VMware Avi (jetzt konsequent als NSX Advanced Load Balancer neu gebrandet) hat die Control Plane grundlegend von der Data Plane entkoppelt, auf eine Weise, die traditionelle ADC-Anbieter nur schwer ohne massive technische Schulden replizieren konnten.

    Die Architektur der Trennung: Controller vs. Service Engine

    Die Kernbrillianz von Avi liegt in seiner 100% softwaredefinierten Architektur. Im Gegensatz zu traditionellen Hardware-Anbietern, die ihren Stack nur "virtualisiert" haben, indem sie ein monolithisches OS (wie TMOS) in einen VMX/OVA-Container gepackt haben, wurde Avi auf einer Distributed Systems-Philosophie aufgebaut. Der Avi Controller fungiert als zentrales Gehirn – er orchestriert, analysiert und verwaltet – während die Service Engines (SEs) die kurzlebigen Data Plane Worker sind.

    In einer Standard-Bereitstellung von 2026 sehen wir drei Controller, die für Hochverfügbarkeit in einem Cluster konfiguriert sind. Diese Controller kommunizieren über REST APIs mit Ihrer Infrastruktur (vCenter, AWS, Azure oder OpenShift). Wenn Sie einen Virtual Service (VS) definieren, pusht der Controller nicht nur eine Konfiguration; er platziert diesen Service intelligent auf einer SE. Wenn der Traffic ansteigt, automatisiert der Controller das Scale-Out, startet zusätzliche SEs und verwendet gratuitous ARP (GARP) oder BGP-Updates, um die Last zu verteilen. Dies ist nicht nur "Auto-Scaling" – es ist prädiktives Kapazitätsmanagement.

    # Beispiel: SE-Status über Avi CLI überprüfen
    shell> show serviceengine 10.10.40.52 runtime
    +-------------------------+---------------------------------------+
    | Field                   | Value                                 |
    +-------------------------+---------------------------------------+
    | uuid                    | se-005056b1a23c                       |
    | status.state            | OPERATIONAL                           |
    | num_virtualservices     | 14                                    |
    | cpu_usage               | 22%                                   |
    | memory_usage            | 4096MB                                |
    +-------------------------+---------------------------------------+

    Warum F5 BIG-IP den Data Center Edge verliert

    Das Argument für F5 beruhte historisch auf Hardware-ASICs für die SSL/TLS-Offload. Im Jahr 2026 haben Intels neueste Ice Lake und Sapphire Rapids CPUs – kombiniert mit DPDK (Data Plane Development Kit) – dedizierte SSL-Hardware für alle bis auf die extremsten 100-Gbit/s+-Single-Flow-Anwendungsfälle weitgehend irrelevant gemacht. Avi Service Engines nutzen DPDK, um den Kernel-Stack zu umgehen und erreichen auf standardmäßiger x86-Hardware nahezu Line-Rate-Performance.

    Darüber hinaus ist der operative Aufwand von F5 iRules im Vergleich zu Avi DataScripts ein klarer Sieg für Avi. iRules sind notorisch schwer zu debuggen und können den TMM-Prozess zum Absturz bringen, wenn sie schlecht geschrieben sind. Avi DataScripts verwenden Lua und bieten eine sicherere, sandboxed Umgebung für die Traffic-Manipulation. Beim Vergleich der Gesamtbetriebskosten (TCO) sollte man bedenken, dass ein Paar F5 i5800-Serien-Appliances leicht über 120.000 US-Dollar kosten können, bevor der Support hinzugefügt wird. Umgekehrt erlaubt AVIS flexible Lizenzierung, Kapazität zwischen Ihrer Private Cloud und Public Cloud (AWS/Azure) zu verschieben, ohne Hardware-Durchsatz erneut kaufen zu müssen.

    Advanced WAF: Jenseits des Signatur-Matches

    Traditionelle WAFs sind "laut" und erfordern einen Vollzeit-Sicherheitsingenieur, nur um False Positives zu verwalten. Die NSX Advanced Load Balancer WAF nutzt einen Pipeline-basierten Ansatz:

    • Allowlist/Blocklist: Schnelles Verwerfen bekannter bösartiger IPs.
    • Positives Sicherheitsmodell: Erlernen des Anwendungsverhaltens und nur Zulassen gültiger Schemata (JSON/XML).
    • Signatur-Matching: Verwendung des Core Rule Set (CRS) für die OWASP Top 10.
    • Bot-Management: Fingerprinting von Clients, um zwischen Googlebot und einem Credential-Stuffing-Skript zu unterscheiden.

    Da der Controller alle Telemetriedaten sieht, bietet er einen Security Insight Score. Sie können sofort sehen, welche spezifische WAF-Regel von einer bestimmten Client-IP ausgelöst wird, einschließlich der vollständigen Request/Response-Header, ohne Logs in ein separates SIEM wie Splunk dumpen zu müssen, nur um zu verstehen, warum die Anmeldung eines Benutzers blockiert wurde.

    GSLB: Der Global Traffic Manager neu gedacht

    Global Server Load Balancing (GSLB) in Avi ist eine transformative Veränderung gegenüber der Ära des "F5 GTM/Big-IP DNS". Früher wurde GSLB als separates DNS-basiertes Produkt verwaltet. In Avi ist GSLB eine integrierte Funktion. Wenn Sie eine Anwendung in us-east-1 (AWS) und On-Premise in Ihrem Rechenzentrum in Denver betreiben, führt AVIS GSLB von beiden Standorten aus Gesundheitsüberwachung durch.

    Die "Site Steering"-Intelligenz ist weitaus überlegen. Durch die Verwendung von EDNS Client Subnet (ECS) kann Avi den tatsächlichen Standort des Endbenutzers und nicht nur den Standort seines DNS-Resolvers bestimmen. Dies verhindert das Problem der "suboptimalen Weiterleitung", bei dem ein Benutzer in Tokio an einen Server in London weitergeleitet wird, weil er einen globalen DNS-Anbieter in Europa nutzt.

    # GSLB Konfigurationsausschnitt (JSON via API)
    {
      "name": "app-global.techleague.io",
      "domain_names": ["app.techleague.io"],
      "members": [
        { "ip": "192.168.100.10", "ratio": 1, "enabled": true },
        { "ip": "10.0.1.50", "ratio": 1, "enabled": true }
      ],
      "algorithm": "GSLB_ALGORITHM_ROUND_ROBIN"
    }

    Kubernetes Ingress: AKO und der moderne Stack

    Der Avi Kubernetes Operator (AKO) ist die Brücke zwischen der Welt von YAML und der Welt des Networkings. In einer Standard-K8s-Umgebung würden Sie NGINX Ingress oder HAProxy verwenden. Obwohl diese funktional sind, mangelt es ihnen an zentralisierter Sichtbarkeit und sie erfordern ein separates Management für Enterprise-Grade-Funktionen wie WAF oder GSLB.

    Mit AKO beobachtet AKO über den API-Server, wenn ein Entwickler ein Ingress-Objekt in Kubernetes erstellt, und weist den Avi Controller automatisch an:

    1. Einen Virtual Service auf einer Service Engine bereitzustellen.
    2. Eine Virtual IP (VIP) vom IPAM-Provider zuzuweisen.
    3. Den SE zu konfigurieren, um über die Pod-IPs hinweg ein Lastenausgleich durchzuführen (wobei kube-proxy und seine ineffizienten iptables/ipvs-Regeln umgangen werden).
    4. TLS-Zertifikate von K8s Secrets mit dem Avi Controller zu synchronisieren.

    Dies ermöglicht eine einheitliche Netzwerkstrategie sowohl für VM-basierte Legacy-Apps als auch für containerisierte Microservices. Weitere Informationen zur Integration in das breitere Software-Defined Networking finden Sie in unserem Deep Dive über VMware VCF und NSX-T Integrationsstrategien.

    Die Analyse-Engine: Echtzeit-Transparenz

    Das "Killer-Feature" von Avi, das F5 endgültig ablöst, ist die App Analytics. Jede einzelne TCP-Verbindung wird nachverfolgt. Sie können die Round-Trip-Time (RTT) für Client-zu-LB, LB-zu-Server und die Anwendungsantwortzeit (die Zeit, die die Backend-Anwendung für die Bearbeitung der Anfrage benötigte) sehen. Dies beendet das "das Netzwerk ist langsam"-Schuldzuweisen. Wenn die "App Response"-Leiste lang und die "Data Transfer"-Leiste kurz ist, liegt das Problem in der SQL-Abfrage oder dem Java-Code, nicht im Netzwerk.

    Lizenzierung und die Broadcom-Realität

    Nach der Übernahme durch Broadcom hat sich die Lizenzierung für NSX Advanced Load Balancer in Richtung der VCF (VMware Cloud Foundation)-Integration verlagert. Obwohl Sie Avi immer noch eigenständig betreiben können, liegt der größte Wert in der Bündelung mit VCF. Rechnen Sie mit einer Bezahlung basierend auf "Service Engine Units" (vCPUs). Ein typisches mittelständisches Unternehmen könnte 20-40 vCPUs Kapazität bereitstellen, was eine hochverteilte Architektur ermöglicht, die weitaus widerstandsfähiger ist als zwei massive Hardware-Boxen, die in einem Rechenzentrumsschrank stehen.

    Fazit: Das Urteil

    Wenn Sie für 2026 planen, ist die Wahl eindeutig. Der Hardware-ADC ist ein lokalisierter Engpass in einer verteilten Welt. VMware Avi bietet die Elastizität eines Cloud-nativen Load Balancers (wie AWS ALB), aber mit den Enterprise-Grade-Funktionen (WAF, GSLB, Scripting), die für komplexe regulierte Umgebungen erforderlich sind. Hören Sie auf, Appliances zu verwalten, und beginnen Sie, Services zu verwalten.

    Bei TechLeague sind wir spezialisiert auf die Migration komplexer Legacy-ADC-Umgebungen zu softwaredefinierten Architekturen. Ob Sie 15 Jahre alte iRules entwirren oder eine Multi-Cloud-GSLB-Strategie entwerfen, unsere Ingenieure waren an vorderster Front. Sehen Sie sich unsere Beratungs- und Schulungspakete auf techleague.io an, um Ihre Infrastrukturmodernisierung noch heute zu beschleunigen.

    Häufige Fragen

    Was ist der primäre Architekturunterschied zwischen Avi und F5 BIG-IP?+

    Avi trennt die Control Plane (Controller) von der Data Plane (Service Engines). Dies ermöglicht dem Load Balancer, horizontal zu skalieren, indem mehr SEs über verschiedene Clouds hinzugefügt werden, während F5 traditionell eine monolithische Appliance ist, bei der Control und Data Plane dieselben Ressourcen und Hardware teilen.

    Wie integriert sich Avi in Kubernetes-Cluster?+

    Der Avi Kubernetes Operator (AKO) synchronisiert K8s Ingress-Ressourcen mit dem Avi Controller. Dies umgeht die Notwendigkeit von NodePorts oder standardmäßigen ClusterIP-basierten Ingress, indem der Traffic direkt von der Service Engine zur Pod-IP geleitet wird, für bessere Performance und Sichtbarkeit.

    Sind AVIS DataScripts gleichwertig mit F5 iRules?+

    Avi DataScripts basieren auf der Programmiersprache Lua. Sie werden in einer Sandbox-Umgebung auf den Service Engines ausgeführt und bieten eine viel höhere Sicherheit und einfachere Fehlersuche im Vergleich zu F5s Tcl-basierten iRules.

    Kann ein softwaredefinierter LB wie Avi 100 Gbit/s Traffic bewältigen?+

    Service Engines (SEs) verwenden DPDK, um eine Hochgeschwindigkeits-Paketverarbeitung im User Space durchzuführen, wodurch der Linux-Kernel umgangen wird. In Kombination mit moderner Intel/AMD CPU-Krypto-Beschleunigung (AES-NI) können sie die Leistung von Hardware-ASIC für fast alle Enterprise-TLS/SSL-Workloads erreichen.

    Welche Vorteile bietet Avi GSLB in einer Multi-Cloud-Umgebung?+

    Avi GSLB bietet integriertes DNS, Gesundheitsüberwachung und Site Steering basierend auf EDNS Client Subnet-Daten. Es ermöglicht automatisiertes Failover zwischen On-Premise-Rechenzentren und Public Clouds wie AWS oder Azure über eine einzige Verwaltungsoberfläche.

    Wie unterscheidet sich die NSX Advanced LB WAF von traditionellen WAFs?+

    Die Avi WAF verwendet eine Pipeline aus Allowlists, positiven Sicherheitsmodellen (Lernen) und signaturbasierten Regeln. Sie liefert Echtzeit-Analysen darüber, warum bestimmte Anfragen blockiert wurden, was wesentlich intuitiver ist als die manuelle Protokollanalyse, die bei älteren WAF-Lösungen erforderlich ist.