GSLB auf NetScaler VPX-Instanzen konfigurieren
NetScaler-Appliances, die für Global Server Load Balancing (GSLB) konfiguriert sind, bieten Notfallwiederherstellung und kontinuierliche Verfügbarkeit von Anwendungen, indem sie vor Ausfallpunkten in einem WAN schützen. GSLB kann die Last über Rechenzentren hinweg ausgleichen, indem Client-Anfragen an das nächstgelegene oder leistungsstärkste Rechenzentrum oder im Falle eines Ausfalls an überlebende Rechenzentren weitergeleitet werden.
Dieser Abschnitt beschreibt, wie GSLB auf VPX-Instanzen an zwei Standorten in einer Microsoft Azure-Umgebung mithilfe von Windows PowerShell-Befehlen aktiviert wird.
Hinweis:
Weitere Informationen zu GSLB finden Sie unter Global Server Load Balancing.
Sie können GSLB auf einer NetScaler VPX-Instanz in Azure in zwei Schritten konfigurieren:
- Erstellen Sie an jedem Standort eine VPX-Instanz mit mehreren NICs und mehreren IP-Adressen.
- Aktivieren Sie GSLB auf den VPX-Instanzen.
Hinweis:
Weitere Informationen zum Konfigurieren mehrerer NICs und IP-Adressen finden Sie unter: Konfigurieren mehrerer IP-Adressen für eine NetScaler VPX-Instanz im Standalone-Modus mithilfe von PowerShell-Befehlen
Szenario
Dieses Szenario umfasst zwei Standorte – Standort 1 und Standort 2. Jeder Standort verfügt über eine VM (VM1 und VM2), die mit mehreren NICs, mehreren IP-Adressen und GSLB konfiguriert ist.
Abbildung. GSLB-Setup über zwei Standorte – Standort 1 und Standort 2 – implementiert.
In diesem Szenario verfügt jede VM über drei NICs – NIC 0/1, 1/1 und 1/2. Jede NIC kann mehrere private und öffentliche IP-Adressen haben. Die NICs sind für die folgenden Zwecke konfiguriert.
- NIC 0/1: für den Management-Traffic
- NIC 1/1: für den Client-seitigen Traffic
- NIC 1/2: zur Kommunikation mit Back-End-Servern
Informationen zu den auf jeder NIC in diesem Szenario konfigurierten IP-Adressen finden Sie im Abschnitt IP-Konfigurationsdetails.
Parameter
Im Folgenden finden Sie Beispielparameter-Einstellungen für dieses Szenario in diesem Dokument.
$location="West Central US"
$vnetName="NSVPX-vnet"
$RGName="multiIP-RG"
$prmStorageAccountName="multiipstorageaccnt"
$avSetName="MultiIP-avset"
$vmSize="Standard\_DS3\_V2"
<!--NeedCopy-->
Hinweis:
Die Mindestanforderung für eine VPX-Instanz beträgt 2 vCPUs und 2 GB RAM.
$publisher="citrix"
$offer="netscalervpx111"
$sku="netscalerbyol"
$version="latest"
$vmNamePrefix="MultiIPVPX"
$nicNamePrefix="MultiipVPX"
$osDiskSuffix="osdiskdb"
$numberOfVMs=1
$ipAddressPrefix="10.0.0."
$ipAddressPrefix1="10.0.1."
$ipAddressPrefix2="10.0.2."
$pubIPName1="MultiIP-pip1"
$pubIPName2="MultiIP-pip2"
$IpConfigName1="IPConfig1"
$IPConfigName2="IPConfig-2"
$IPConfigName3="IPConfig-3"
$IPConfigName4="IPConfig-4"
$frontendSubnetName="default"
$backendSubnetName1="subnet\_1"
$backendSubnetName2="subnet\_2"
$suffixNumber=10
<!--NeedCopy-->
VM erstellen
Führen Sie die Schritte 1–10 aus, um VM1 mit mehreren NICs und mehreren IP-Adressen mithilfe von PowerShell-Befehlen zu erstellen:
Nachdem Sie alle Schritte und Befehle zur Erstellung von VM1 abgeschlossen haben, wiederholen Sie diese Schritte, um VM2 mit den spezifischen Parametern zu erstellen.
Ressourcengruppe erstellen
New-AzureRMResourceGroup -Name $RGName -Location $location
<!--NeedCopy-->
Speicherkonto erstellen
$prmStorageAccount=New-AzureRMStorageAccount -Name $prmStorageAccountName -ResourceGroupName $RGName -Type Standard_LRS -Location $location
<!--NeedCopy-->
Verfügbarkeitsgruppe erstellen
$avSet=New-AzureRMAvailabilitySet -Name $avSetName -ResourceGroupName $RGName -Location $location
<!--NeedCopy-->
Virtuelles Netzwerk erstellen
-
Subnetze hinzufügen.
$subnet1=New-AzureRmVirtualNetworkSubnetConfig -Name $frontendSubnetName -AddressPrefix "10.0.0.0/24" $subnet2=New-AzureRmVirtualNetworkSubnetConfig -Name $backendSubnetName1 -AddressPrefix "10.0.1.0/24" $subnet3=New-AzureRmVirtualNetworkSubnetConfig -Name $backendSubnetName2 -AddressPrefix "10.0.2.0/24" <!--NeedCopy--> -
Virtuelles Netzwerkobjekt hinzufügen.
$vnet=New-AzureRmVirtualNetwork -Name $vnetName -ResourceGroupName $RGName -Location $location -AddressPrefix 10.0.0.0/16 -Subnet $subnet1, $subnet2, $subnet3 <!--NeedCopy--> -
Subnetze abrufen.
$frontendSubnet=$vnet.Subnets|?{$_.Name -eq $frontendSubnetName} $backendSubnet1=$vnet.Subnets|?{$_.Name -eq $backendSubnetName1} $backendSubnet2=$vnet.Subnets|?{$_.Name -eq $backendSubnetName2} <!--NeedCopy-->
Öffentliche IP-Adresse erstellen
$pip1=New-AzureRmPublicIpAddress -Name $pubIPName1 -ResourceGroupName $RGName -Location $location -AllocationMethod Dynamic
$pip2=New-AzureRmPublicIpAddress -Name $pubIPName2 -ResourceGroupName $RGName -Location $location -AllocationMethod Dynamic
<!--NeedCopy-->
NICs erstellen
NIC 0/1 erstellen
$nic1Name=$nicNamePrefix + $suffixNumber + "-Mgmnt"
$ipAddress1=$ipAddressPrefix + $suffixNumber
$IPConfig1=New-AzureRmNetworkInterfaceIpConfig -Name $IPConfigName1 -SubnetId $frontendSubnet.Id -PublicIpAddress $pip1 -PrivateIpAddress $ipAddress1 -Primary
$nic1=New-AzureRMNetworkInterface -Name $nic1Name -ResourceGroupName $RGName -Location $location -IpConfiguration $IpConfig1
<!--NeedCopy-->
NIC 1/1 erstellen
$nic2Name $nicNamePrefix + $suffixNumber + "-frontend"
$ipAddress2=$ipAddressPrefix1 + ($suffixNumber)
$ipAddress3=$ipAddressPrefix1 + ($suffixNumber + 1)
$IPConfig2=New-AzureRmNetworkInterfaceIpConfig -Name $IPConfigName2 -PublicIpAddress $pip2 -SubnetId $backendSubnet1.Id -PrivateIpAddress $ipAddress2 -Primary
$IPConfig3=New-AzureRmNetworkInterfaceIpConfig -Name $IPConfigName3 -SubnetId $backendSubnet1.Id -PrivateIpAddress $ipAddress3
nic2=New-AzureRMNetworkInterface -Name $nic2Name -ResourceGroupName $RGName -Location $location -IpConfiguration $IpConfig2, $IpConfig3
<!--NeedCopy-->
NIC 1/2 erstellen
$nic3Name=$nicNamePrefix + $suffixNumber + "-backend"
$ipAddress4=$ipAddressPrefix2 + ($suffixNumber)
$IPConfig4=New-AzureRmNetworkInterfaceIpConfig -Name $IPConfigName4 -SubnetId $backendSubnet2.Id -PrivateIpAddress $ipAddress4 -Primary
$nic3=New-AzureRMNetworkInterface -Name $nic3Name -ResourceGroupName $RGName -Location $location -IpConfiguration $IpConfig4
<!--NeedCopy-->
VM-Konfigurationsobjekt erstellen
$vmName=$vmNamePrefix
$vmConfig=New-AzureRMVMConfig -VMName $vmName -VMSize $vmSize -AvailabilitySetId $avSet.Id
<!--NeedCopy-->
Anmeldeinformationen abrufen und BS-Eigenschaften festlegen
$cred=Get-Credential -Message "Type the name and password for VPX login."
$vmConfig=Set-AzureRMVMOperatingSystem -VM $vmConfig -Linux -ComputerName $vmName -Credential $cred
$vmConfig=Set-AzureRMVMSourceImage -VM $vmConfig -PublisherName $publisher -Offer $offer -Skus $sku -Version $version
<!--NeedCopy-->
NICs hinzufügen
$vmConfig=Add-AzureRMVMNetworkInterface -VM $vmConfig -Id $nic1.Id -Primary
$vmConfig=Add-AzureRMVMNetworkInterface -VM $vmConfig -Id $nic2.Id
$vmConfig=Add-AzureRMVMNetworkInterface -VM $vmConfig -Id $nic3.Id
<!--NeedCopy-->
BS-Datenträger angeben und VM erstellen
$osDiskName=$vmName + "-" + $osDiskSuffix
$osVhdUri=$prmStorageAccount.PrimaryEndpoints.Blob.ToString() + "vhds/" +$osDiskName + ".vhd"
$vmConfig=Set-AzureRMVMOSDisk -VM $vmConfig -Name $osDiskName -VhdUri $osVhdUri -CreateOption fromImage
Set-AzureRmVMPlan -VM $vmConfig -Publisher $publisher -Product $offer -Name $sku
New-AzureRMVM -VM $vmConfig -ResourceGroupName $RGName -Location $location
<!--NeedCopy-->
Hinweis:
Wiederholen Sie die Schritte 1–10, die unter „Erstellen von Multi-NIC-VMs mithilfe von PowerShell-Befehlen“ aufgeführt sind, um VM2 mit VM2-spezifischen Parametern zu erstellen.
Details zur IP-Konfiguration
Die folgenden IP-Adressen werden verwendet.
Tabelle 1. In VM1 verwendete IP-Adressen
| NIC | Private IP | Öffentliche IP (PIP) | Beschreibung |
|---|---|---|---|
| 0/1 | 10.0.0.10 | PIP1 | Als NSIP (Verwaltungs-IP) konfiguriert |
| 1/1 | 10.0.1.10 | PIP2 | Als SNIP/GSLB-Site-IP konfiguriert |
| - | 10.0.1.11 | - | Als LB-Server-IP konfiguriert. Öffentliche IP ist nicht zwingend erforderlich |
| 1/2 | 10.0.2.10 | - | Als SNIP zum Senden von Monitor-Probes an Dienste konfiguriert; öffentliche IP ist nicht zwingend erforderlich |
Tabelle 2. In VM2 verwendete IP-Adressen
| NIC | Interne IP | Öffentliche IP (PIP) | Beschreibung |
|---|---|---|---|
| 0/1 | 20.0.0.10 | PIP4 | Als NSIP (Verwaltungs-IP) konfiguriert |
| 1/1 | 20.0.1.10 | PIP5 | Als SNIP/GSLB-Site-IP konfiguriert |
| - | 20.0.1.11 | - | Als LB-Server-IP konfiguriert. Öffentliche IP ist nicht zwingend erforderlich |
| 1/2 | 20.0.2.10 | - | Als SNIP zum Senden von Monitor-Probes an Dienste konfiguriert; öffentliche IP ist nicht zwingend erforderlich |
Hier sind Beispielkonfigurationen für dieses Szenario, die die IP-Adressen und anfänglichen LB-Konfigurationen zeigen, wie sie über die NetScaler VPX CLI für VM1 und VM2 erstellt wurden.
Hier ist eine Beispielkonfiguration auf VM1.
add ns ip 10.0.1.10 255.255.255.0 -mgmtAccess ENABLED
Add nsip 10.0.2.10 255.255.255.0
add service svc1 10.0.1.10 ADNS 53
add lb vserver v1 HTTP 10.0.1.11 80
add service s1 10.0.2.120 http 80
Add service s2 10.0.2.121 http 80
Bind lb vs v1 s[1-2]
<!--NeedCopy-->
Hier ist eine Beispielkonfiguration auf VM2.
add ns ip 20.0.1.10 255.255.255.0 -mgmtAccess ENABLED
Add nsip 20.0.2.10 255.255.255.0
add service svc1 20.0.1.10 ADNS 53
add lb vserver v1 HTTP 20.0.1.11 80
Add service s1 20.0.2.90 http 80
Add service s2 20.0.2.91 http 80
Bind lb vs v1 s[1-2]
<!--NeedCopy-->
GSLB-Sites und andere Einstellungen konfigurieren
Führen Sie die im folgenden Thema beschriebenen Aufgaben aus, um die beiden GSLB-Sites und andere notwendige Einstellungen zu konfigurieren:
Globales Server-Lastverteilung
Hier ist eine Beispiel-GSLB-Konfiguration auf VM1 und VM2.
enable ns feature LB GSLB
add gslb site site1 10.0.1.10 -publicIP PIP2
add gslb site site2 20.0.1.10 -publicIP PIP5
add gslb service site1_gslb_http_svc1 10.0.1.11 HTTP 80 -publicIP PIP3 -publicPort 80 -siteName site1
add gslb service site2_gslb_http_svc1 20.0.1.11 HTTP 80 -publicIP PIP6 -publicPort 80 -siteName site2
add gslb vserver gslb_http_vip1 HTTP
bind gslb vserver gslb_http_vip1 -serviceName site2_gslb_http_svc1
bind gslb vserver gslb_http_vip1 -serviceName site1_gslb_http_svc1
bind gslb vserver gslb_http_vip1 -domainName www.gslbindia.com -TTL 5
<!--NeedCopy-->
Sie haben GSLB auf NetScaler VPX-Instanzen konfiguriert, die auf Azure ausgeführt werden.
Notfallwiederherstellung
Eine Katastrophe ist eine plötzliche Unterbrechung der Geschäftsfunktionen, verursacht durch Naturkatastrophen oder von Menschen verursachte Ereignisse. Katastrophen beeinträchtigen den Betrieb von Rechenzentren, wonach Ressourcen und die am Katastrophenort verlorenen Daten vollständig wiederhergestellt werden müssen. Der Datenverlust oder Ausfallzeiten im Rechenzentrum sind kritisch und gefährden die Geschäftskontinuität.
Eine der Herausforderungen, vor denen Kunden heute stehen, ist die Entscheidung, wo sie ihren DR-Standort einrichten sollen. Unternehmen suchen nach Konsistenz und Leistung, unabhängig von zugrunde liegenden Infrastruktur- oder Netzwerkfehlern.
Mögliche Gründe, warum viele Organisationen sich für die Migration in die Cloud entscheiden, sind:
-
Ein lokales Rechenzentrum ist sehr teuer. Durch die Nutzung der Cloud können Unternehmen Zeit und Ressourcen freisetzen, die sonst für die Erweiterung ihrer eigenen Systeme aufgewendet würden.
-
Viele der automatisierten Orchestrierungen ermöglichen eine schnellere Wiederherstellung
-
Daten replizieren durch Bereitstellung von kontinuierlichem Datenschutz oder kontinuierlichen Snapshots, um sich vor Ausfällen oder Angriffen zu schützen.
-
Unterstützung von Anwendungsfällen, bei denen Kunden viele verschiedene Arten von Compliance- und Sicherheitskontrollen benötigen, die bereits in den öffentlichen Clouds vorhanden sind. Dies erleichtert das Erreichen der benötigten Compliance, anstatt eigene Lösungen zu entwickeln.
Ein für GSLB konfigurierter NetScaler leitet den Datenverkehr an das am wenigsten ausgelastete oder leistungsstärkste Rechenzentrum weiter. Diese Konfiguration, die als Active-Active-Setup bezeichnet wird, verbessert nicht nur die Leistung, sondern bietet auch eine sofortige Notfallwiederherstellung, indem der Datenverkehr an andere Rechenzentren geleitet wird, wenn ein Teil des Setups ausfällt. NetScaler spart Kunden dadurch wertvolle Zeit und Geld.
Multi-NIC Multi-IP (Drei-NIC)-Bereitstellung für die Notfallwiederherstellung
Kunden würden möglicherweise eine Drei-NIC-Bereitstellung verwenden, wenn sie in einer Produktionsumgebung bereitstellen, in der Sicherheit, Redundanz, Verfügbarkeit, Kapazität und Skalierbarkeit entscheidend sind. Bei dieser Bereitstellungsmethode sind Komplexität und einfache Verwaltung keine kritischen Bedenken für die Benutzer.
Single-NIC Multi-IP (Ein-NIC)-Bereitstellung für die Notfallwiederherstellung
Kunden würden möglicherweise eine Ein-NIC-Bereitstellung verwenden, wenn sie aus den folgenden Gründen in einer Nicht-Produktionsumgebung bereitstellen:
-
Einrichtung der Umgebung für Tests oder Staging einer neuen Umgebung vor der Produktionsbereitstellung.
-
Direkte, schnelle und effiziente Bereitstellung in der Cloud.
-
Auf der Suche nach der Einfachheit einer einzelnen Subnetzkonfiguration.