GSLB auf NetScaler VPX-Instanzen konfigurieren
NetScaler-Appliances, die für das globale Server-Lastenausgleich (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 die verbleibenden 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 Globaler Server-Lastenausgleich.
Sie können GSLB auf einer NetScaler VPX-Instanz in Azure in zwei Schritten konfigurieren:
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-Einrichtung über zwei Standorte – Standort 1 und Standort 2.
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: zur Bereitstellung von Management-Traffic
-
NIC 1/1: zur Bereitstellung von Client-seitigem 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 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"
Hinweis:
Die Mindestanforderung für eine VPX-Instanz sind 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
Eine 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 für sie spezifischen Parametern zu erstellen.
Ressourcengruppe erstellen
New-AzureRMResourceGroup -Name $RGName -Location $location
Speicherkonto erstellen
$prmStorageAccount=New-AzureRMStorageAccount -Name $prmStorageAccountName -ResourceGroupName $RGName -Type Standard_LRS -Location $location
Verfügbarkeitsgruppe erstellen
$avSet=New-AzureRMAvailabilitySet -Name $avSetName -ResourceGroupName $RGName -Location $location
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" -
Virtuelles Netzwerkobjekt hinzufügen.
$vnet=New-AzureRmVirtualNetwork -Name $vnetName -ResourceGroupName $RGName -Location $location -AddressPrefix 10.0.0.0/16 -Subnet $subnet1, $subnet2, $subnet3 -
Subnetze abrufen.
$frontendSubnet=$vnet.Subnets|?{$_.Name -eq $frontendSubnetName}
$backendSubnet1=$vnet.Subnets|?{$_.Name -eq $backendSubnetName1}
$backendSubnet2=$vnet.Subnets|?{$_.Name -eq $backendSubnetName2}
Ö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
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
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
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
VM-Konfigurationsobjekt erstellen
$vmName=$vmNamePrefix
$vmConfig=New-AzureRMVMConfig -VMName $vmName -VMSize $vmSize -AvailabilitySetId $avSet.Id
Anmeldeinformationen abrufen und Betriebssystemeigenschaften 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
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
Betriebssystemdatenträ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
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 | Konfiguriert als NSIP (Verwaltungs-IP) |
| 1/1 | 10.0.1.10 | PIP2 | Konfiguriert als SNIP/GSLB-Site-IP |
| - | 10.0.1.11 | - | Konfiguriert als LB-Server-IP. Eine ö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 | - | Konfiguriert als LB-Server-IP. Eine öffentliche IP ist nicht zwingend erforderlich. |
| 1/2 | 20.0.2.10 | - | Konfiguriert als SNIP zum Senden von Monitor-Probes an Dienste; eine öffentliche IP ist nicht zwingend erforderlich. |
Hier sind Beispielkonfigurationen für dieses Szenario, die die IP-Adressen und die 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]
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]
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:
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
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, die durch Naturkatastrophen oder von Menschen verursachte Ereignisse hervorgerufen wird. Katastrophen beeinträchtigen den Betrieb von Rechenzentren, wonach die am Katastrophenort verlorenen Ressourcen und Daten vollständig wiederhergestellt werden müssen. Der Datenverlust oder die Ausfallzeit im Rechenzentrum ist kritisch und gefährdet 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 sparen, die sie sonst für die Erweiterung ihrer eigenen Systeme aufwenden müssten.
-
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 es, die benötigte Compliance zu erreichen, anstatt eigene 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 zum Testen oder Vorbereitung einer neuen Umgebung vor der Produktionsbereitstellung.
-
Schnelles und effizientes Bereitstellen direkt in die Cloud.
-
Dabei die Einfachheit einer einzelnen Subnetzkonfiguration anstreben.