Bereitstellen eines VPX-Hochverfügbarkeitspaares mit privaten IP-Adressen über verschiedene AWS-Zonen hinweg
Sie können zwei NetScaler VPX-Instanzen in zwei verschiedenen Subnetzen oder zwei verschiedenen AWS-Verfügbarkeitszonen unter Verwendung privater IP-Adressen im INC-Modus konfigurieren. Diese Lösung lässt sich leicht in das bestehende Multizonen-(/de-de/vpx/current-release/deploy-aws/vpx-ha-eip-different-aws-zones.html) integrieren. Daher können Sie beide Lösungen zusammen verwenden.
Weitere Informationen zur Hochverfügbarkeit finden Sie unter (/de-de/citrix-adc/current-release/system/high-availability-introduction.html). Weitere Informationen zu INC finden Sie unter (/de-de/citrix-adc/current-release/system/high-availability-introduction/configuring-high-availability-nodes-different-subnets.html).
Hinweis:
Diese Bereitstellung wird ab NetScaler Release 13.0 Build 67.39 unterstützt. Diese Bereitstellung ist mit AWS Transit Gateway kompatibel.
Hochverfügbarkeitspaar mit privaten IP-Adressen unter Verwendung einer nicht freigegebenen AWS-VPC
Voraussetzungen
Stellen Sie sicher, dass die IAM-Rolle, die Ihrem AWS-Konto zugeordnet ist, die folgenden IAM-Berechtigungen besitzt:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeAddresses",
"ec2:AssociateAddress",
"ec2:DisassociateAddress",
"ec2:DescribeRouteTables",
"ec2:DeleteRoute",
"ec2:CreateRoute",
"ec2:ModifyNetworkInterfaceAttribute",
"iam:SimulatePrincipalPolicy",
"iam:GetRole"
],
"Resource": "*",
"Effect": "Allow"
}
]
}
<!--NeedCopy-->
Bereitstellen eines VPX HA-Paares mit privaten IP-Adressen unter Verwendung einer nicht freigegebenen AWS-VPC
Im Folgenden finden Sie eine Zusammenfassung der Schritte zum Bereitstellen eines VPX-Paares in zwei verschiedenen Subnetzen oder zwei verschiedenen AWS-Verfügbarkeitszonen unter Verwendung privater IP-Adressen.
- Erstellen Sie eine virtuelle private Amazon Cloud.
- Stellen Sie zwei VPX-Instanzen in zwei verschiedenen Verfügbarkeitszonen bereit.
- Hochverfügbarkeit konfigurieren
- Richten Sie Hochverfügbarkeit im INC-Modus in beiden Instanzen ein.
- Fügen Sie die entsprechenden Routing-Tabellen in der VPC hinzu, die auf die Client-Schnittstelle verweist.
- Fügen Sie einen virtuellen Server in der primären Instanz hinzu.
Für die Schritte 1, 2 und 3b verwenden Sie die AWS-Konsole. Für die Schritte 3a und 3c verwenden Sie die NetScaler VPX GUI oder die CLI.
Schritt 1. Erstellen Sie eine Amazon Virtual Private Cloud (VPC).
Schritt 2. Stellen Sie zwei VPX-Instanzen in zwei verschiedenen Availability Zones mit der gleichen Anzahl von ENIs (Network Interface) bereit.
Weitere Informationen zum Erstellen einer VPC und zum Bereitstellen einer VPX-Instanz auf AWS finden Sie unter Bereitstellen einer eigenständigen NetScaler VPX-Instanz auf AWS und Szenario: eigenständige Instanz
Schritt 3. Konfigurieren Sie die ADC-VIP-Adressen, indem Sie ein Subnetz wählen, das sich nicht mit den Amazon VPC-Subnetzen überschneidet. Wenn Ihre VPC 192.168.0.0/16 ist, können Sie zur Konfiguration der ADC-VIP-Adressen ein beliebiges Subnetz aus diesen IP-Adressbereichen wählen:
- 0.0.0.0 - 192.167.0.0
- 192.169.0.0 - 254.255.255.0
In diesem Beispiel wurde das Subnetz 10.10.10.0/24 gewählt und VIPs in diesem Subnetz erstellt. Sie können jedes Subnetz außer dem VPC-Subnetz (192.168.0.0/16) wählen.
Schritt 4. Fügen Sie eine Route hinzu, die auf die Client-Schnittstelle (VIP) des primären Knotens aus der VPC-Routing-Tabelle zeigt.
Geben Sie in der AWS CLI den folgenden Befehl ein:
aws ec2 create-route --route-table-id rtb-2272532 --destination-cidr-block 10.10.10.0/24 --gateway-id <eni-client-primary>
<!--NeedCopy-->
Führen Sie in der AWS GUI die folgenden Schritte aus, um eine Route hinzuzufügen:
- Öffnen Sie die Amazon EC2-Konsole.
- Wählen Sie im Navigationsbereich Route Tables und dann die Routing-Tabelle aus.
- Wählen Sie Actions und klicken Sie auf Edit routes.
- Um eine Route hinzuzufügen, wählen Sie Route hinzufügen. Geben Sie für Ziel den Ziel-CIDR-Block, eine einzelne IP-Adresse oder die ID einer Präfixliste ein. Wählen Sie für die Gateway-ID die ENI einer Client-Schnittstelle des primären Knotens aus.
Routentabellen-Routen bearbeiten(/de-de/vpx/media/edit-routes.png)
Hinweis:
Sie müssen die Quell-/Zielprüfung auf der Client-ENI der primären Instanz deaktivieren.
Um die Quell-/Zielprüfung für eine Netzwerkschnittstelle über die Konsole zu deaktivieren, führen Sie die folgenden Schritte aus:
- Öffnen Sie die Amazon EC2-Konsole.
- Wählen Sie im Navigationsbereich Netzwerkschnittstellen aus.
- Wählen Sie die Netzwerkschnittstelle einer primären Client-Schnittstelle aus, wählen Sie Aktionen und klicken Sie auf Quell-/Zielprüfung ändern.
- Wählen Sie im Dialogfeld Deaktiviert aus und klicken Sie auf Speichern.
Quell-Ziel-Prüfung ändern(/de-de/vpx/media/change-source-dst-check.png)
Schritt 5. Hochverfügbarkeit konfigurieren. Sie können die NetScaler VPX CLI oder die GUI verwenden, um Hochverfügbarkeit einzurichten.
Hochverfügbarkeit über die CLI konfigurieren
-
Richten Sie Hochverfügbarkeit im INC-Modus in beiden Instanzen ein.
Auf dem primären Knoten:
add ha node 1 \<sec\_ip\> -inc ENABLED <!--NeedCopy-->Auf dem sekundären Knoten:
add ha node 1 \<prim\_ip\> -inc ENABLED <!--NeedCopy--><sec_ip> bezieht sich auf die private IP-Adresse der Management-NIC des sekundären Knotens.
<prim_ip> bezieht sich auf die private IP-Adresse der Management-NIC des primären Knotens.
-
Fügen Sie einen virtuellen Server auf der primären Instanz hinzu. Sie müssen ihn aus dem gewählten Subnetz hinzufügen, zum Beispiel 10.10.10.0/24.
Geben Sie den folgenden Befehl ein:
add \<server\_type\> vserver \<vserver\_name\> \<protocol\> \<primary\_vip\> \<port\> <!--NeedCopy-->
Hochverfügbarkeit über die GUI konfigurieren
-
Richten Sie auf beiden Instanzen Hochverfügbarkeit im INC-Modus ein.
-
Melden Sie sich am primären Knoten mit dem Benutzernamen
nsrootund der Instanz-ID als Kennwort an. -
Navigieren Sie zu Configuration > System > High Availability und klicken Sie auf Add.
-
Geben Sie im Feld Remote Node IP address die private IP-Adresse der Management-NIC des sekundären Knotens ein.
-
Wählen Sie auf dem eigenen Knoten den Modus Turn on NIC (Independent Network Configuration).
-
Fügen Sie unter Remote System Login Credential den Benutzernamen und das Kennwort für den sekundären Knoten hinzu und klicken Sie auf Create.
-
Wiederholen Sie die Schritte auf dem sekundären Knoten.
-
Fügen Sie einen virtuellen Server in der primären Instanz hinzu.
Navigieren Sie zu Configuration > Traffic Management > Virtual Servers > Add.

Bereitstellen eines VPX HA-Paares mit privaten IP-Adressen mithilfe von AWS Shared VPC
In einem AWS Shared VPC-Modell teilt das Konto, dem die VPC gehört (Eigentümer), ein oder mehrere Subnetze mit anderen Konten (Teilnehmern). Daher gibt es ein VPC-Eigentümerkonto und ein Teilnehmerkonto. Nachdem ein Subnetz freigegeben wurde, können die Teilnehmer ihre Anwendungsressourcen in den mit ihnen geteilten Subnetzen anzeigen, erstellen, ändern und löschen. Teilnehmer können keine Ressourcen anzeigen, ändern oder löschen, die anderen Teilnehmern oder dem VPC-Eigentümer gehören.
Informationen zu AWS Shared VPC finden Sie in der AWS-Dokumentation.
Hinweis:
Die Konfigurationsschritte für die Bereitstellung eines VPX HA-Paares mit privaten IP-Adressen mithilfe von AWS Shared VPC sind dieselben wie bei der Bereitstellung eines VPX HA-Paares mit privaten IP-Adressen mithilfe von AWS Non-Shared VPC mit folgender Ausnahme:
- Die Routing-Tabellen in der VPC, die auf die Client-Schnittstelle verweisen, müssen vom VPC-Eigentümerkonto hinzugefügt werden.
Voraussetzungen
-
Stellen Sie sicher, dass die IAM-Rolle, die der NetScaler VPX-Instanz im AWS-Teilnehmerkonto zugeordnet ist, die folgenden IAM-Berechtigungen besitzt:
"Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "ec2:DisassociateAddress", "iam:GetRole", "iam:SimulatePrincipalPolicy", "ec2:DescribeInstances", "ec2:DescribeAddresses", "ec2:ModifyNetworkInterfaceAttribute", “ec2:AssociateAddress”, "sts:AssumeRole" ], "Resource": "*" } ] } <!--NeedCopy-->Hinweis:
Die AssumeRole ermöglicht es der NetScaler VPX-Instanz, die kontoübergreifende IAM-Rolle zu übernehmen, die vom VPC-Eigentümerkonto erstellt wird.
-
Stellen Sie sicher, dass das VPC-Eigentümerkonto dem Teilnehmerkonto die folgenden IAM-Berechtigungen mithilfe einer kontoübergreifenden IAM-Rolle bereitstellt:
{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "ec2:CreateRoute", "ec2:DeleteRoute", "ec2:DescribeRouteTables" ], "Resource": "*" } ] } <!--NeedCopy-->
Kontoübergreifende IAM-Rolle erstellen
- Melden Sie sich bei der AWS-Webkonsole an.
- Navigieren Sie auf der Registerkarte IAM zu Rollen und wählen Sie dann Rolle erstellen.
-
Wählen Sie Anderes AWS-Konto.

- Geben Sie die 12-stellige Konten-ID des Teilnehmerkontos ein, dem Sie Administratorzugriff gewähren möchten.
Cross-Account-IAM-Rolle mithilfe der NetScaler CLI festlegen
Der folgende Befehl ermöglicht es der NetScaler VPX-Instanz, die Cross-Account-IAM-Rolle zu übernehmen, die im VPC-Eigentümerkonto vorhanden ist.
set cloud awsParam -roleARN <string>
<!--NeedCopy-->
Cross-Account-IAM-Rolle mithilfe der NetScaler GUI festlegen
-
Melden Sie sich bei der NetScaler Appliance an und navigieren Sie zu Configuration > AWS > Change cloud parameters.

-
Geben Sie auf der Seite Configure AWS Cloud Parameters den Wert für das Feld RoleARN ein.

Szenario
In diesem Szenario wird eine einzelne VPC erstellt. In dieser VPC werden zwei VPX-Instanzen in zwei Verfügbarkeitszonen erstellt. Jede Instanz verfügt über drei Subnetze – eines für die Verwaltung, eines für den Client und eines für den Backend-Server.
Die folgenden Diagramme veranschaulichen das NetScaler VPX-Hochverfügbarkeits-Setup im INC-Modus auf AWS. Das benutzerdefinierte Subnetz 10.10.10.10, das nicht Teil der VPC ist, wird als VIP verwendet. Daher kann das Subnetz 10.10.10.10 über Verfügbarkeitszonen hinweg verwendet werden.


Verwenden Sie für dieses Szenario die CLI, um die Hochverfügbarkeit zu konfigurieren.
-
Richten Sie Hochverfügbarkeit im INC-Modus auf beiden Instanzen ein.
Geben Sie die folgenden Befehle auf dem primären und dem sekundären Knoten ein.
Auf dem primären Knoten:
add ha node 1 192.168.4.10 -inc enabled <!--NeedCopy-->Hier bezieht sich 192.168.4.10 auf die private IP-Adresse der Management-NIC des sekundären Knotens.
Auf dem sekundären Knoten:
add ha node 1 192.168.1.10 -inc enabled <!--NeedCopy-->Hier bezieht sich 192.168.1.10 auf die private IP-Adresse der Management-NIC des primären Knotens.
-
Fügen Sie einen virtuellen Server auf der primären Instanz hinzu.
Geben Sie den folgenden Befehl ein:
add lbvserver vserver1 http 10.10.10.10 80 <!--NeedCopy--> -
Speichern Sie die Konfiguration.
-
Nach einem erzwungenen Failover:
- Die sekundäre Instanz wird zur neuen primären Instanz.
- Die VPC-Route, die auf die primäre ENI zeigt, migriert zur sekundären Client-ENI.
- Der Client-Traffic wird auf der neuen primären Instanz wieder aufgenommen.
AWS Transit Gateway-Konfiguration für HA-Lösung mit privater IP
Sie benötigen AWS Transit Gateway, um das private VIP-Subnetz innerhalb des internen Netzwerks, über AWS-VPCs, Regionen und On-Premises-Netzwerke hinweg routingfähig zu machen. Die VPC muss sich mit AWS Transit Gateway verbinden. Eine statische Route für das VIP-Subnetz oder den IP-Pool innerhalb der AWS Transit Gateway-Routingtabelle wird erstellt und auf die VPC gerichtet.

So konfigurieren Sie AWS Transit Gateway, gehen Sie wie folgt vor:
- Öffnen Sie die Amazon VPC-Konsole.
- Wählen Sie im Navigationsbereich Transit Gateway-Routingtabellen.
-
Wählen Sie die Registerkarte Routen und klicken Sie auf Statische Route erstellen.

-
Erstellen Sie eine statische Route, bei der CIDR auf Ihr privates VIPS-Subnetz und die Anbindung auf die VPC mit NetScaler VPX verweist.

- Klicken Sie auf Statische Route erstellen und wählen Sie dann Schließen.
Fehlerbehebung
Wenn bei der Konfiguration der HA-Lösung mit privaten IP-Adressen über Multizone-HA Probleme auftreten, überprüfen Sie die folgenden wichtigen Punkte zur Fehlerbehebung:
- Sowohl der primäre als auch der sekundäre Knoten verfügen über dieselben IAM-Berechtigungen.
- Der INC-Modus ist sowohl auf dem primären als auch auf dem sekundären Knoten aktiviert.
- Sowohl der primäre als auch der sekundäre Knoten verfügen über die gleiche Anzahl von Schnittstellen.
- Beachten Sie beim Erstellen einer Instanz die gleiche Reihenfolge beim Anfügen von Schnittstellen an primären und sekundären Knoten, basierend auf der Geräteindexnummer. Angenommen, an einem primären Knoten wird zuerst die Clientschnittstelle und dann die Serverschnittstelle angefügt. Befolgen Sie dieselbe Reihenfolge auch auf dem sekundären Knoten. Bei Abweichungen trennen Sie die Schnittstellen und fügen Sie sie in der richtigen Reihenfolge erneut an.
- Sie können die Reihenfolge der Schnittstellen über diesen Navigationspfad überprüfen: AWS-Konsole > Netzwerk & Sicherheit > ENI > Gerätexindexnummer.
Standardmäßig werden den folgenden Schnittstellen die folgenden Gerätexindexnummern zugewiesen:
- Managementschnittstelle – 0
- Clientschnittstelle – 1
- Serverschnittstelle – 2
-
Wenn die Reihenfolge der Gerätexindexnummern auf der primären ENI 0, 1, 2 ist, muss die sekundäre ENI ebenfalls dieselbe Reihenfolge der Gerätexindexnummern einhalten: 0, 1, 2.
Wenn es eine Diskrepanz in der Reihenfolge der Gerätexindexnummern gibt, werden alle nicht übereinstimmenden Routen an Index 0, die Managementschnittstelle, übertragen, um Routenverluste zu vermeiden. Sie müssen die Schnittstellen jedoch trotzdem trennen und in der richtigen Reihenfolge wieder anschließen, um die Verschiebung von Routen zur Managementschnittstelle zu vermeiden, da dies zu einer Überlastung des Datenverkehrs führen kann.
- Wenn kein Datenverkehr fließt, stellen Sie sicher, dass die Option „Source/dest. Check“ auf der Clientschnittstelle des primären Knotens zum ersten Mal deaktiviert ist.
- Stellen Sie sicher, dass der Befehl
cloudhadaemon(ps -aux | grep cloudha) in der Shell ausgeführt wird. - Stellen Sie sicher, dass die NetScaler-Firmware-Version 13.0 Build 70.x oder höher ist.
- Bei Problemen mit dem Failover-Prozess überprüfen Sie die Protokolldatei unter:
/var/log/cloud-ha-daemon.log