Load-Balancer-Verwaltung

Um einen funktionierenden Load Balancer zu implementieren, müssen Sie die folgenden Elemente beachten:

• Für einen öffentlichen Load Balancer in einer Region mit mehreren Availability-Domains benötigen Sie ein VCN mit einem öffentlichen regionalen Subnetz oder mindestens zwei öffentlichen AD-spezifischen Subnetzen. Im letzteren Fall muss sich jedes AD-spezifische Subnetz in einer separaten Availability-Domain befinden. Weitere Informationen zu Subnetzen finden Sie unter VCN- und Subnetzverwaltung und Öffentliche IP-Adressbereiche.
  Hinweis
  
  Sie können kein privates Subnetz für einen öffentlichen Load Balancer angeben.
• Für einen öffentlichen Load Balancer in einer Region mit nur einer Availability-Domain benötigen Sie ein VCN mit mindestens einem öffentlichen Subnetz.
• Für einen privaten Load Balancer in einer beliebigen Region benötigen Sie ein VCN mit mindestens einem privaten Subnetz.
• Auf mindestens zwei Backend-Servern (Compute-Instanzen) werden Anwendungen ausgeführt. Weitere Informationen zu Compute-Instanzen finden Sie unter Instanzen erstellen.

Zum Zwecke der Zugriffskontrolle müssen Sie das Compartment angeben, in dem sich der Load Balancer befinden soll. Wenn Sie nicht sicher sind, welches Compartment Sie verwenden sollen, wenden Sie sich an einen Administrator in Ihrer Organisation. Informationen zu Compartments und zur Zugriffskontrolle finden Sie unter Compartments verwalten.

Wenn Sie einen Load Balancer innerhalb eines VCN erstellen, erhalten Sie eine öffentliche oder private IP-Adresse und die bereitgestellte gesamte Bandbreite. Wenn Sie eine weitere IP-Adresse benötigen, können Sie einen zusätzlichen Load Balancer erstellen.

Ein privater Load Balancer erfordert nur ein Subnetz, um den primären Load Balancer und einen Standby-Load Balancer zu hosten. Die private IP-Adresse ist dem Subnetz lokal zugeordnet. Auf den Load Balancer kann nur über das VCN zugegriffen werden, in dem sich das zugehörige Subnetz befindet. Der Zugriff kann durch die Sicherheitslistenregeln weiter eingeschränkt werden. Der Load Balancer kann Datentraffic an jeden Backend-Server weiterleiten, der über das VCN erreichbar ist.

Ein öffentlicher Load Balancer, der in einem öffentlichen regionalen Subnetz erstellt wird, belegt zwei private IPv4-Adressen aus dem Hostsubnetz. Der primäre und der sekundäre Load Balancer befinden sich im selben Subnetz. Jeder Load Balancer erfordert eine private IPv4-Adresse aus diesem Subnetz. Der Load-Balancer-Service weist eine öffentliche Floating-IPv4-Adresse zu, die nicht aus dem Hostsubnetz stammt. Wenn der Load Balancer für IPv6 aktiviert ist, erhält er eine IPv6-Adresse aus dem Hostsubnetz.

Ein öffentlicher Load Balancer, der in zwei öffentlichen AD-spezifischen Subnetzen erstellt wird, belegt zwei private IP-Adressen - jeweils eine aus jedem Hostsubnetz. Der primäre und der sekundäre Load Balancer befinden sich in unterschiedlichen Subnetzen. Jeder Load Balancer erfordert eine private IP-Adresse aus seinem Hostsubnetz. Der Load-Balancer-Service weist eine öffentliche Floating-IPv4-Adresse zu, die nicht aus den Hostsubnetzen stammt. Wenn der Load Balancer für IPv6 aktiviert ist, wird ihm eine IPv6-Adresse aus dem Hostsubnetz zugewiesen.

Ein privater Load Balancer, der in einem einzelnen Subnetz erstellt wird, belegt drei private IP-Adressen aus dem Hostsubnetz. Der primäre und der sekundäre Load Balancer befinden sich im selben Subnetz. Jeder Load Balancer erfordert eine private IP-Adresse aus diesem Subnetz. Die private Floating-IP-Adresse stammt ebenfalls aus dem Hostsubnetz. Die Internetkommunikation mit einem Load Balancer, der für IPv6 aktiviert und in einem privaten Subnetz erstellt wurde, ist nicht zulässig. In einem privaten Subnetz können Sie keinen für IPv6 aktivierten Load Balancer erstellen, der global geroutet werden kann.

Bei einem ausgeführten Load Balancer führen einige Konfigurationsänderungen zu Serviceunterbrechungen. Die folgenden Richtlinien helfen Ihnen, die Auswirkung von Änderungen am Load Balancer zu verstehen.

• Vorgänge, bei denen ein Backend-Server hinzugefügt, entfernt oder geändert wird, führen nicht zu Unterbrechungen des Load-Balancer-Service.
• Vorgänge, bei denen eine vorhandene Health Check Policy bearbeitet wird, führen nicht zu Unterbrechungen des Load-Balancer-Service.
• Vorgänge, bei denen eine Neukonfiguration des Load Balancers ausgelöst wird, können zu einer kurzen Unterbrechung des Service führen, wobei möglicherweise einige Verbindungen beendet werden.

Load Balancer mit TCP-basierten Listenern können die Proxyprotokollfunktion verwenden, um Quell- und Ziel-IP-Adressen und -Ports über Layer der Network Address Translation (NAT) oder TCP-Proxys an ihre Backend-Server zu senden. Verwenden Sie das Proxyprotokoll, um Netzwerkanforderungen wie Anwendungssicherheit (IP-ACLs) und Complianceprotokollierung zu unterstützen.

Wenn Sie beim Erstellen eines Load Balancers die Proxyprotokolloption auswählen (oder einen vorhandenen aktualisieren), werden Sie aufgefordert, eine der folgenden Optionen auszuwählen:

• Version 1: Unterstützt ein menschenlesbares Headerformat (Text) und ist in der Regel eine einzelne Zeile eines Logeintrags. Verwenden Sie diese Option für das Debugging während der frühen Einführungsphase, wenn nur wenige Implementierungen vorhanden sind.

• Version 2: Kombiniert die Unterstützung für den menschenlesbaren Header aus Version 1 mit einer binären Codierung des Headers, um die Effizienz beim Produzieren und Parsen zu erhöhen. Verwenden Sie diese Option für IPv6-Adressen, die im ASCII-Formular nur schwer generiert und geparst werden können. Version 2 unterstützt auch benutzerdefinierte Erweiterungen besser.

Beide Versionen implementieren das Protokoll als analysierbaren Header, den der Verbindungsinitiator zu Beginn jeder Verbindung platziert. Das Protokoll erwartet nicht, dass der Absender auf den Empfänger wartet, bevor er den Header sendet. Es wartet auch nicht darauf, dass der Empfänger etwas zurückschickt.

Das Proxyprotokoll für Load Balancer unterstützt nur die Option PP2 Type Authority für die Unterstützung von Transport Layer Security (TLS) Server Name Indication (SNI). Diese Unterstützung ist nützlich, wenn der Load Balancer die SSL-Verbindung und nicht die Backend-Server beendet. Diese Funktionalität ähnelt der Option "X-Forwarded-Host" für TCP.

Stellen Sie sicher, dass die Backend-Anwendungen den Header der Proxyprotokollversion 2 erwarten und parsen können, bevor Sie das Proxyprotokoll auf dem Load Balancer aktivieren. Weitere Informationen zu Proxyprotokollversion 2 erhalten Sie auf der Website HAProxy.

Wenn Sie über Berechtigungen zum Erstellen einer Ressource verfügen, sind Sie auch berechtigt, Freiformtags auf diese Ressource anzuwenden. Um ein definiertes Tag anzuwenden, benötigen Sie die Berechtigungen zum Verwenden des Tag-Namespace. Weitere Informationen zum Tagging finden Sie unter Ressourcentags. Wenn Sie nicht sicher sind, ob Tags angewendet werden sollen, überspringen Sie diese Option, oder fragen Sie einen Administrator. Sie können Tags später anwenden.