Anwendungsbereitstellung und -leistung

In diesem Artikel können Sie den richtigen Azure Lastenausgleichsdienst für Ihre Workload auswählen. Es vergleicht Azure Load Balancer, Anwendungsgateway und Azure Front Door für die regionale und globale Datenverkehrsverteilung. Außerdem wird erläutert, wann sie kombiniert werden. Für eine kürzere, dienst-für-dienst-Übersicht siehe Was ist Load Balancing und Inhaltslieferung?

Inhalt dieses Artikels

Anwendungslieferung umfasst, wie Ihr Netzwerk den Datenverkehr über Backend-Ressourcen verteilt, nachdem er am Netzwerkperimeter angekommen ist. Dieser Artikel behandelt Lastenausgleich auf Layer 4 und Layer 7 sowie globale Datenverkehrsbeschleunigung. Außerdem werden die Entscheidungskriterien für die Auswahl zwischen den drei primären Azure Lastenausgleichsdiensten behandelt.

Note

Dieser Artikel ergänzt Internet-Ingress: Stellen Sie Ihre Anwendung im Internet bereit, der sich darauf konzentriert, wie Datenverkehr in Ihr Netzwerk gelangt. Dieser Artikel behandelt, wie dieser Datenverkehr ausgeglichen und an die Anwendungs-Back-Ends weitergeleitet wird.

Wer diesen Artikel benötigt

Lesen Sie diesen Artikel, wenn Sie:

  • Hosten Sie Webanwendungen oder APIs, die eine hohe Verfügbarkeit auf mehrere Backend-Instanzen verteilt benötigen.
  • Benötigt SSL/TLS-Offload, URL-basiertes Routing oder Web Application Firewall (WAF)-Schutz für HTTP/HTTPS-Verkehr.
  • Verteilen des Datenverkehrs über mehrere Azure Regionen zur Leistung oder Notfallwiederherstellung.
  • Führen Sie Nicht-HTTP-Workloads (TCP/UDP) aus, die einen regionalen Ausgleich mit Integritätstests erfordern.
  • Möchten Sie verstehen, welcher Load Balancer zu Ihrem Datenverkehrstyp, Ihrem geografischen Umfang und Ihren Sicherheitsanforderungen passt.

Heben und Verschieben des Fokus: Viele neu gehostete interne Apps benötigen nur einen regionalen Lastenausgleich. Fügen Sie dienste für die Internetverbindung hinzu, wenn Sie eine App für Kunden veröffentlichen.

Modernisieren Sie den Fokus: Wählen Sie die Übermittlung nach App-Typ aus: Azure Front Door für globale Web-Apps und Traffic Manager für Nicht-Web-Apps, die aktiv-aktive regionale Endpunkte bereitstellen.

Cloudübergreifender Schwerpunkt: Ordnen Sie Load Balancer aus anderen Clouds den Azure-Entsprechungen zu (beispielsweise AWS ALB dem Application Gateway und NLB dem Azure Load Balancer) und stellen Sie sie über den Spoke hinter der Hub-Firewall bereit.

Azure Dienste und Features

In der folgenden Tabelle sind die drei primären Azure Lastenausgleichsdienste zusammengefasst.

Service Was es bietet Wann wird es verwendet? Schlüsseleinschränkungen
Azure Load Balancer Standard Lastenausgleich der Ebene 4 (TCP/UDP) innerhalb einer Region. Zustandsprüfungen, Zonenredundanz, ausgehende SNAT-Regeln und HA-Ports für virtuelle Netzwerkappliances. Virtual Machine Scale Sets, interner AKS-Datenverkehr, nicht auf HTTP/HTTPS basierende regionale Workloads und NVA-Hochverfügbarkeit. Keine SSL/TLS-Beendigung; keine WAF; kein URL-basiertes Routing; Nur regionaler Bereich.
Azure Application Gateway Regionaler Lastenausgleich der Ebene 7 (HTTP/HTTPS). SSL/TLS-Beendigung, URL-pfadbasiertes Routing, Multisite-Hosting, cookiebasierte Sitzungsaffinität und optionale WAF-Integration. Regionale Webanwendungen, die SSL-Offload, URL-Routing, WebSocket-Unterstützung oder WAF-Schutz benötigen. Nur regional; erfordert ein dediziertes Subnetz; nicht für globale Routing- oder CDN-Szenarien geeignet.
Azure Front Door Globaler Anycast-Lastenausgleich und CDN. TLS-Abschluss am Rand, integrierte WAF, Integritätstests des Ursprungs, Aufteilung des Datenverkehrs und Caching über mehr als 190 globale Points of Presence (PoPs). Globale Webanwendungen, Aktiv/Aktiv-Bereitstellungen für mehrere Regionen, CDN und Caching sowie globale WAF-Erzwingung. Nur HTTP/HTTPS; Origins müssen öffentlich zugänglich oder über Private Link (Premium-Stufe) erreichbar sein.

Zonenredundanz

Zonenredundanz schützt Ihre Anwendungsübermittlungsebene vor Rechenzentrumsfehlern. Jeder Dienst behandelt Verfügbarkeitszonen unterschiedlich:

  • Load Balancer Standard (öffentlich) ist standardmäßig zonenredundant, da standardmäßig öffentliche IP-Adressen standardmäßig zonenredundant sind. Der Datenverkehr fließt auch dann weiter, wenn eine Verfügbarkeitszone fehlschlägt. Load Balancer Standard (intern) erfordert eine explizite zone-redundante Frontend-Konfiguration: Sie müssen mehrere Zonen auswählen, wenn Sie die Front-End-IP erstellen.
  • Anwendungsgateway v2 unterstützt Zonenredundanz, wenn Sie Instanzen in mehreren Verfügbarkeitszonen bereitstellen. Geben Sie die Zonen während der Bereitstellung an. Ein zonenredundantes Anwendungsgateway verteilt Instanzen über die von Ihnen ausgewählten Zonen, wobei die Verfügbarkeit beibehalten wird, wenn eine einzelne Zone offline geht.
  • Azure Front Door ist als globaler Anycast-Dienst von Haus aus zonenredundant. Seine mehr als 190 Edge-PoPs sind weltweit auf mehrere Regionen verteilt, sodass sich der Ausfall einer einzelnen Zone oder Region nicht auf die globale Verkehrslenkung auswirkt.

Automatische Skalierung

Jeder Dienst verarbeitet eine andere Skalierung:

  • Das Anwendungsgateway v2 (Standard_v2- und WAF_v2-Ebenen) unterstützt die automatische Skalierung basierend auf der Datenverkehrslast. Sie konfigurieren mindeste und maximale Instanzenanzahl und die Gatewayskalierung innerhalb dieser Grenzen. Die Preise verwenden Kapazitätseinheiten: ein zusammengesetztes Maß für neue Verbindungen pro Sekunde, persistente Verbindungen und Durchsatz. Legen Sie für Produktionsworkloads eine Mindestanzahl von zwei Instanzen fest, um Cold-Start-Latenzen bei Lastspitzen zu vermeiden.
  • Azure Front Door wird automatisch als verwalteter globaler Dienst skaliert. Sie benötigen keine Kapazitätsplanung oder Instanzgröße.
  • Load Balancer Standard wird ohne manuelle Eingriffe oder Konfigurationsänderungen auf Millionen von TCP/UDP-Flüssen skaliert. Es ist ein vollständig verwalteter Plattformdienst ohne Instanzkonzept.

Gesundheitsüberprüfungen

Alle drei Dienste verwenden Integritätssonden, um fehlerhafte Back-Ends zu erkennen und das Routing des Datenverkehrs an sie zu beenden:

  • Load Balancer Standard unterstützt TCP-, HTTP- und HTTPS-Integritätssonden. Konfigurieren Sie Testintervalle und Schwellenwerte für Fehlerzustände, um die Failover-Geschwindigkeit zu steuern. Kürzere Intervalle erkennen Fehler schneller, generieren aber mehr Prüfdatenverkehr.
  • Application Gateway verwendet HTTP/HTTPS-Integritätsprüfungen mit anpassbaren Pfaden, Hostnamen und dem Abgleich von Antworten. Mit benutzerdefinierten Prüfpunkten können Sie die Anwendungslogik überprüfen (z. B. einen /health Endpunkt überprüfen, der die Datenbankkonnektivität überprüft).
  • Front Door verwendet HTTP/HTTPS-Integritätssonden gegen Ursprünge. Es unterstützt konfigurierbare Prüfpunktpfade, -Intervalle und Antwortcodeabgleich. Front Door testet Ursprünge aus mehreren PoPs und ermöglicht so eine verteilte Integritätsprüfung.

Wie man auswählt

Das folgende Flussdiagramm fasst den primären Entscheidungspfad für die Auswahl eines Azure Lastenausgleichsdiensts zusammen.

Flussdiagramm zur Auswahl eines Azure-Lastausgleichsdiensts mit Verzweigung nach HTTP- oder Nicht-HTTP-Datenverkehr sowie nach einzelner Region oder globaler Bereitstellung.

Verwenden Sie die folgenden Entscheidungstabellen, um den richtigen Lastenausgleichsdienst für Ihr Szenario auszuwählen.

Welchen Lastenausgleich benötige ich?

Ich muss... Verwendung
TCP/UDP-Datenverkehr innerhalb einer einzelnen Region per Lastausgleich verteilen Azure Load Balancer Standard: Layer-4-Verteilung mit Integritätstests, Zonenredundanz und HA-Ports.
Beenden von SSL/TLS, Routen nach URL-Pfad oder Hostnamen und Hinzufügen von WAF für eine regionale Web-App Azure Application Gateway: regionaler Lastenausgleich auf Ebene 7 mit integrierter WAF (v2 SKU).
HTTP/HTTPS-Verkehr global weiterleiten, die Latenz mit Edge-Caching reduzieren oder regionenübergreifendes Failover ermöglichen Azure Front Door: Globales Anycast mit CDN, WAF und Integritätstests des Ursprung für mehrere Regionen.

Vergleich von Schlüsseleinschränkungen

Service Ebene Geltungsbereich Schlüsseleinschränkung
Standard-Lastenausgleich Schicht 4 (TCP/UDP) Länderspezifisch Kein Anwendungsbewusstsein: HTTP-Header, URLs oder Cookies können nicht überprüft werden.
Application Gateway Schicht 7 (HTTP/HTTPS) Länderspezifisch Erfordert ein dediziertes Subnetz (/24 empfohlen); Datenverkehr kann nicht global weitergeleitet werden.
Front Door Schicht 7 (HTTP/HTTPS) Global Origins müssen öffentlich sein oder über Private Link erreichbar sein (nur im Premium-Tarif); keine Unterstützung für TCP/UDP.

Kombinieren von Diensten

Viele Produktionsarchitekturen kombinieren mehrere Lastenausgleichsdienste in einer Kette. Jeder Dienst behandelt, was am besten funktioniert:

  • Front Door + Application Gateway: Verwenden Sie Front Door für die globale Verteilung des Datenverkehrs und Edge-WAF, und leiten Sie den Datenverkehr dann an regionale Application Gateway-Instanzen für pfadbasiertes URL-Routing und die Verwaltung von Back-End-Pools weiter. Front Door Premium kann über Private Link eine Verbindung mit dem Anwendungsgateway herstellen und das Anwendungsgateway privat halten. Dieses Muster eignet sich für Multiregion-Bereitstellungen, bei denen jede Region komplexe URL-Routinganforderungen aufweist.
  • Front Door + Load Balancer: Verwenden Sie Front Door für die globale HTTP/HTTPS-Verteilung, mit einem internen Load Balancer Standard dahinter, um den Datenverkehr über Virtual Machine Scale Sets oder NVAs innerhalb einer Region zu verteilen. Front Door verarbeitet globales Routing und Caching, während Load Balancer Layer 4-Verteilung für die Berechnung von Instanzen bereitstellt.
  • Anwendungsgateway + Load Balancer: Verwenden Des Anwendungsgateways für die HTTP/HTTPS-Datenverkehrsverwaltung am Frontend und Load Balancer für Nicht-HTTP-Back-End-Ebenen (Datenbanken, Nachrichtenwarteschlangen) in derselben Bereitstellung. Dieser Ansatz belässt die Layer-7-Intelligenz am Netzwerkrand und setzt intern auf eine leichtgewichtige Layer-4-Verteilung.

Routingfunktionen

Wenn Sie die Routingfunktionen verstehen, können Sie Ihre Wahl einschränken:

Fähigkeit Standard-Lastenausgleich Application Gateway Front Door
Pfadbasiertes URL-Routing Nein Ja Ja
Hostheader-basiertes Routing für mehrere Websites Nein Ja Ja
Cookiebasierte Sitzungsaffinität Nein Ja Ja
Gewichtete Datenverkehrsaufteilung Nein Nein Ja
Geografisches Routing Nein Nein Ja
SSL/TLS-Auslagerung Nein Ja Ja
WebSocket-Unterstützung Pass-Through Ja Ja
HTTP/2-Unterstützung Nein Ja Ja

Tip

Das Anwendungsgateway v2 wird automatisch zwischen einer Minimal- und maximaler Instanzenanzahl skalieren, und Sie zahlen mindestens die Mindestkapazität, auch wenn der Datenverkehr im Leerlauf ist. Legen Sie die Mindestanzahl der Instanzen auf Ihre Grundlast fest, nicht auf Ihre Spitzenlast, und lassen Sie Lastspitzen von der automatischen Skalierung abfangen. Die Überbereitstellung des Minimums ist eine häufige Quelle für vermeidbare Anwendungsgateway-Kosten.

Überlegungen zum Entwurf

Designfokus für die lift-and-shift-Anwendungsbereitstellung

  • Verwenden Sie einen internen Azure-Load-Balancer für den Ost-West-Datenverkehr zwischen den Ebenen einer erneut gehosteten App, sodass er dem Lastenausgleich entspricht, auf den die App bereits angewiesen war.
  • Fügen Sie öffentliche Zustellungsdienste nur für Apps hinzu, die Sie für das Internet verfügbar machen. viele migrierte interne Workloads benötigen keine.
  • Halten Sie das Bereitstellungsdesign beim anfänglichen Rehosting einfach und auf eine einzelne Region beschränkt.
  • Leiten Sie jeden eingehenden Internetdatenverkehr über die Hubfirewall weiter, bevor er die Workload erreicht.

Den Fokus auf das Design der Anwendungsbereitstellung modernisieren

  • Wählen Sie nach Anwendungstyp: Azure Front Door für globale Web-Apps (Edge-Beendigung, WAF) und Azure Traffic Manager für Nicht-Web-Apps, die DNS-basierte regionale Verteilung benötigen.
  • Stellen Sie eine Aktiv-Aktiv-Bereitstellung über mehrere Regionen hinweg bereit und verteilen Sie den Datenverkehr an den öffentlichen Endpunkt jeder Region hinter der Hub-Firewall, die SNAT und DNAT übernimmt.
  • Verwenden Sie Application Gateway für regionales Layer-7-Routing und TLS-Terminierung hinter Front Door, wenn Sie globale Zustellung benötigen.
  • Stellen Sie nicht sowohl Front Door als auch Traffic Manager für denselben Datenverkehr bereit; entscheiden Sie sich je nachdem, ob es sich bei der App um eine Web-App oder eine Nicht-Web-App handelt, für eine der beiden Optionen.

Designfokus für die cloudübergreifende Anwendungsbereitstellung

  • Ordnen Sie Bereitstellungsdienste aus anderen Clouds Azure zu: AWS Application Load Balancer oder Google Cloud Application Load Balancing zu Azure Application Gateway sowie Netzwerk-Load-Balancer zu Azure Load Balancer.
  • Hosten Sie die Layer-7-Bereitstellung (Application Gateway mit WAF) im Spoke-Netzwerk und vermeiden Sie es, öffentliche IP-Adressen direkt virtuellen Computern zuzuweisen.
  • Leiten Sie den öffentlichen eingehenden Datenverkehr über die Firewall des gesicherten Hubs, bevor er die migrierten Workloads erreicht.
  • Verwenden Sie Front Door oder Traffic Manager für die Bereitstellung mehrerer Regionen, sobald Workloads in mehr als einer Azure Region ausgeführt werden.

Prerequisites

Bevor Sie Anwendungsübermittlungsdienste implementieren:

  • Bereitgestelltes virtuelles Netzwerk: Sie benötigen mindestens ein virtuelles Netzwerk mit Subnetzen. Informationen zur Subnetzplanung finden Sie unter "Virtuelles Netzwerk und Subnetzdesign ".
  • Typ des Workload-Datenverkehrs identifiziert: Wissen Sie, ob Ihre Workload HTTP/HTTPS (Layer 7) oder TCP/UDP (Layer 4) verwendet. Dieser Verkehrstyp bestimmt Ihre primäre Wahl des Load Balancers.
  • Geografischer Bereich definiert: Bestimmen Sie, ob sich Ihre Benutzer in einer einzelnen Region befinden oder global verteilt sind. Die globale Nutzerbasis profitiert von der Anycast-Beschleunigung durch Front Door.
  • Subnetzkapazität für Anwendungsgateway: Für das Anwendungsgateway ist ein dediziertes Subnetz ohne andere Ressourcen erforderlich. Ein /24-Subnetz unterstützt bis zu 125 Instanzen plus fünf Azure-reservierte Adressen.

Sicherheitsüberlegungen

Lastenausgleichsdienste sind Teil Ihres Sicherheitsperimeters. Sie sind die ersten Komponenten, die eingehenden Datenverkehr verarbeiten, wodurch ihre Sicherheitskonfiguration kritisch ist. Befolgen Sie diese Methoden, um ihre Anwendungsbereitstellungsstufe zu schützen.

Web Application Firewall (WAF)

Aktivieren Sie WAF im Präventionsmodus in Application Gateway oder Front Door für alle Webworkloads in der Produktion. Der Erkennungsmodus protokolliert nur Bedrohungen, ohne sie zu blockieren. Verwenden Sie sie während der ersten Optimierung, um False Positives zu identifizieren, und wechseln Sie dann vor dem produktionsbezogenen Datenverkehr in den Präventionsmodus.

WAF schützt vor allgemeinen Web-Exploits, einschließlich:

  • SQL-Einfügung und websiteübergreifendes Skripting (XSS)
  • Protokollanomalien und Request-Schmuggel
  • Bots und Crawler (mit Bot-Schutzregeln)
  • OWASP Top 10 Sicherheitsanfälligkeiten durch verwaltete Regelsätze

Sowohl Application Gateway WAF als auch Front Door WAF verwenden dieselbe Regel-Engine, unterscheiden sich jedoch im Einsatzbereich. Application Gateway WAF schützt eine regionale Bereitstellung, während Front Door WAF Richtlinien am globalen Netzwerkrand durchsetzt, bevor der Datenverkehr einen Ursprungsserver erreicht. Ausführliche Informationen zur WAF-Optimierung und Regelsatzkonfiguration finden Sie unter Web Application Firewall.

DDoS-Schutz

Aktivieren Sie Azure DDoS Protection auf allen öffentlichen IP-Adressen, die mit Ihren Lastverteilungsdiensten verknüpft sind. Die öffentlichen Front-End-IP-Adressen von Load Balancer Standard und die öffentlichen IP-Adressen von Application Gateway sind Hauptziele für volumetrische Angriffe. Diese IPs stellen die Einstiegspunkte Ihrer Anwendung dar.

Azure DDoS Protection bietet Folgendes:

  • Always-on-Datenverkehrsüberwachung mit adaptiver Optimierung.
  • Automatische Angriffsminderung, wenn der Datenverkehr einen Schwellenwert überschreitet.
  • Angriffstelemetrie und Warnung durch Azure Monitor.
  • Kostenschutz (Servicegutschrift) für Ressourcenskalierung, die durch DDoS-Angriffe ausgelöst wird.

Informationen zur DDoS-Schutzplanung und -konfiguration finden Sie unter DDoS-Schutz.

Azure Front Door Premium unterstützt Private-Link-Konnektivität zu Ursprüngen. Diese Funktion entfernt die Notwendigkeit für öffentlich zugängliche Back-End-Server. Front Door verbindet sich mit Ihrem Ursprung über das Azure Backbone-Netzwerk anstelle des öffentlichen Internets. Verwenden Sie Private Link Ursprünge in folgenden Fällen:

  • Ihre Back-Ends sind interne Dienste, die keine öffentlichen IP-Adressen haben sollten.
  • Sie müssen den Ursprungszugang nur für den Front-Door-Datenverkehr sperren.
  • Complianceanforderungen verbieten öffentliche Endpunkte auf Anwendungsservern.
  • Sie möchten die Angriffsfläche eines öffentlich exponierten Ursprungsservers reduzieren.

Zu den unterstützten Private Link Ursprüngen gehören App Service, Azure Storage, Anwendungsgateway, interne Load Balancer Standard und benutzerdefinierte Ursprünge mit Private Link Dienst.

Informationen zu Private Link Architekturmustern finden Sie unter "Privater Zugriff auf Azure PaaS-Dienste".

Important

Die Front Door Standard-Ebene unterstützt Private Link zu Ursprüngen nicht. Nur Front Door Premium bietet diese Funktion.

Beidseitiges TLS (mTLS)

Application Gateway v2 unterstützt gegenseitiges TLS für die Back-End-Authentifizierung. Verwenden Sie mTLS, wenn Für Ihre Back-End-Server eine zertifikatbasierte Clientauthentifizierung vom Gateway erforderlich ist. Diese Authentifizierung fügt eine Ebene der Vertrauensüberprüfung hinzu. Das Backend kann bestätigen, dass der Datenverkehr von der legitimen Application Gateway-Instanz ankommt und nicht von einem schlechten Akteur, der das Gateway umgangen hat.

Weitere Informationen

Nächste Schritte

Tip

Auf eigene Faust erkunden? Kehren Sie zum Übersichtsnavigator zurück, um Ihren nächsten Artikel nach Funktion zu finden.

Als Nächstes in Ihrer Lift-and-Shift-Reise:

Steuern des ausgehenden Internetdatenverkehrs: Zentralisieren des ausgehenden Zugriffs über Ihre Hubfirewall und Deaktivieren des standardmäßigen ausgehenden Datenverkehrs.

Als Nächstes in Ihrer Modernisierungsreise:

Richten Sie private Konnektivität mit PaaS-Diensten ein: Erstellen Sie Private Link Subnetze in jedem Speichen-VNet für Ihre AKS-, ASE- und verwalteten Datenbankworkloads.

Als Nächstes in Ihrer cloudübergreifenden Reise:

Sichern Sie Ihren cloudübergreifenden Transitpfad: Stellen Sie Azure Firewall in Ihrem sicheren virtuellen Hub bereit, um den gesamten cloudübergreifenden und internetgebundenen Datenverkehr zu prüfen.

  • Last updated on