Configurer le GSLB sur les instances NetScaler VPX
Les appliances NetScaler configurées pour l'équilibrage de charge global des serveurs (GSLB) assurent la reprise après sinistre et la disponibilité continue des applications en protégeant contre les points de défaillance dans un WAN. Le GSLB peut équilibrer la charge entre les centres de données en dirigeant les requêtes des clients vers le centre de données le plus proche ou le plus performant, ou vers les centres de données survivants en cas de panne.
Cette section décrit comment activer le GSLB sur les instances VPX sur deux sites dans un environnement Microsoft Azure, à l'aide de commandes Windows PowerShell.
Remarque :
Pour plus d'informations sur le GSLB, consultez Équilibrage de charge global des serveurs.
Vous pouvez configurer le GSLB sur une instance NetScaler VPX sur Azure, en deux étapes :
Remarque :
Pour plus d'informations sur la configuration de plusieurs cartes réseau et adresses IP, consultez : Configurer plusieurs adresses IP pour une instance NetScaler VPX en mode autonome à l'aide de commandes PowerShell
Scénario
Ce scénario comprend deux sites - Site 1 et Site 2. Chaque site dispose d'une machine virtuelle (VM1 et VM2) configurée avec plusieurs cartes réseau, plusieurs adresses IP et le GSLB.
Figure. Configuration GSLB implémentée sur deux sites - Site 1 et Site 2.
Dans ce scénario, chaque machine virtuelle dispose de trois cartes réseau - NIC 0/1, 1/1 et 1/2. Chaque carte réseau peut avoir plusieurs adresses IP privées et publiques. Les cartes réseau sont configurées aux fins suivantes.
-
NIC 0/1 : pour le trafic de gestion
-
NIC 1/1 : pour le trafic côté client
-
NIC 1/2 : pour communiquer avec les serveurs back-end
Paramètres
Voici des exemples de paramètres pour ce scénario dans ce document.
$location="West Central US"
$vnetName="NSVPX-vnet"
$RGName="multiIP-RG"
$prmStorageAccountName="multiipstorageaccnt"
$avSetName="MultiIP-avset"
$vmSize="Standard\_DS3\_V2"
Remarque :
La configuration minimale requise pour une instance VPX est de 2 vCPU et 2 Go de 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
Créer une machine virtuelle
Suivez les étapes 1 à 10 pour créer la machine virtuelle VM1 avec plusieurs cartes réseau et plusieurs adresses IP, à l'aide des commandes PowerShell :
Une fois que vous avez terminé toutes les étapes et commandes pour créer VM1, répétez ces étapes pour créer VM2 avec ses paramètres spécifiques.
Créer un groupe de ressources
New-AzureRMResourceGroup -Name $RGName -Location $location
Créer un compte de stockage
$prmStorageAccount=New-AzureRMStorageAccount -Name $prmStorageAccountName -ResourceGroupName $RGName -Type Standard_LRS -Location $location
Créer un groupe à haute disponibilité
$avSet=New-AzureRMAvailabilitySet -Name $avSetName -ResourceGroupName $RGName -Location $location
Créer un réseau virtuel
-
Ajouter des sous-réseaux.
$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" -
Ajouter un objet de réseau virtuel.
$vnet=New-AzureRmVirtualNetwork -Name $vnetName -ResourceGroupName $RGName -Location $location -AddressPrefix 10.0.0.0/16 -Subnet $subnet1, $subnet2, $subnet3 -
Récupérer les sous-réseaux.
$frontendSubnet=$vnet.Subnets|?{$_.Name -eq $frontendSubnetName}
$backendSubnet1=$vnet.Subnets|?{$_.Name -eq $backendSubnetName1}
$backendSubnet2=$vnet.Subnets|?{$_.Name -eq $backendSubnetName2}
Créer une adresse IP publique
$pip1=New-AzureRmPublicIpAddress -Name $pubIPName1 -ResourceGroupName $RGName -Location $location -AllocationMethod Dynamic
$pip2=New-AzureRmPublicIpAddress -Name $pubIPName2 -ResourceGroupName $RGName -Location $location -AllocationMethod Dynamic
Créer des cartes réseau
Créer NIC 0/1
$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
Créer NIC 1/1
$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
Créer NIC 1/2
$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
Créer un objet de configuration de VM
$vmName=$vmNamePrefix
$vmConfig=New-AzureRMVMConfig -VMName $vmName -VMSize $vmSize -AvailabilitySetId $avSet.Id
Obtenir les informations d'identification et définir les propriétés de l'OS
$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
Ajouter des NIC
$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
Spécifier le disque OS et créer la VM
$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
Remarque :
Répétez les étapes 1 à 10 énumérées dans « Créer des VM multi-NIC à l'aide de commandes PowerShell » pour créer la VM2 avec des paramètres spécifiques à la VM2.
Détails de la configuration IP
Les adresses IP suivantes sont utilisées.
Tableau 1. Adresses IP utilisées dans la VM1
| NIC | IP privée | IP publique (PIP) | Description |
|---|---|---|---|
| 0/1 | 10.0.0.10 | PIP1 | Configuré comme NSIP (adresse IP de gestion) |
| 1/1 | 10.0.1.10 | PIP2 | Configuré comme SNIP/adresse IP de site GSLB |
| - | 10.0.1.11 | - | Configuré comme adresse IP de serveur LB. L'adresse IP publique n'est pas obligatoire |
| 1/2 | 10.0.2.10 | - | Configuré comme SNIP pour l'envoi de sondes de surveillance aux services ; l'IP publique n'est pas obligatoire |
Tableau 2. Adresses IP utilisées dans la VM2
| NIC | IP interne | IP publique (PIP) | Description |
|---|---|---|---|
| 0/1 | 20.0.0.10 | PIP4 | Configuré comme NSIP (IP de gestion) |
| 1/1 | 20.0.1.10 | PIP5 | Configuré comme SNIP/IP de site GSLB |
| - | 20.0.1.11 | - | Configuré comme IP de serveur LB. L'IP publique n'est pas obligatoire |
| 1/2 | 20.0.2.10 | - | Configuré comme SNIP pour l'envoi de sondes de surveillance aux services ; l'IP publique n'est pas obligatoire |
Voici des exemples de configurations pour ce scénario, montrant les adresses IP et les configurations LB initiales telles que créées via l'interface CLI de NetScaler VPX pour VM1 et VM2.
Voici un exemple de configuration sur 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]
Voici un exemple de configuration sur 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]
Configurer les sites GSLB et d'autres paramètres
Effectuez les tâches décrites dans la rubrique suivante pour configurer les deux sites GSLB et d'autres paramètres nécessaires :
Voici un exemple de configuration GSLB sur VM1 et 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
Vous avez configuré GSLB sur des instances NetScaler VPX exécutées sur Azure.
Reprise après sinistre
Un sinistre est une interruption soudaine des fonctions commerciales causée par des catastrophes naturelles ou des événements d'origine humaine. Les sinistres affectent les opérations des centres de données, après quoi les ressources et les données perdues sur le site du sinistre doivent être entièrement reconstruites et restaurées. La perte de données ou les temps d'arrêt dans le centre de données sont critiques et compromettent la continuité des activités.
L'un des défis auxquels les clients sont confrontés aujourd'hui est de décider où implanter leur site de reprise après sinistre. Les entreprises recherchent la cohérence et la performance, quels que soient les défauts d'infrastructure ou de réseau sous-jacents.
Les raisons possibles pour lesquelles de nombreuses organisations décident de migrer vers le cloud sont :
-
Avoir un centre de données sur site est très coûteux. En utilisant le cloud, les entreprises peuvent libérer du temps et des ressources de l'expansion de leurs propres systèmes.
-
Une grande partie de l'orchestration automatisée permet une récupération plus rapide
-
Répliquer les données en offrant une protection continue des données ou des instantanés continus pour se prémunir contre toute panne ou attaque.
-
Prendre en charge les cas d'utilisation où les clients ont besoin de nombreux types différents de conformité et de contrôle de sécurité qui sont déjà présents sur les clouds publics. Cela facilite l'atteinte de la conformité dont ils ont besoin plutôt que de construire la leur.
Un NetScaler configuré pour le GSLB transfère le trafic vers le centre de données le moins chargé ou le plus performant. Cette configuration, appelée configuration active-active, améliore non seulement les performances, mais assure également une reprise après sinistre immédiate en acheminant le trafic vers d'autres centres de données si un centre de données faisant partie de la configuration tombe en panne. NetScaler permet ainsi aux clients d'économiser un temps et de l'argent précieux.
Déploiement Multi-NIC Multi-IP (trois cartes réseau) pour la reprise après sinistre
Les clients déploieraient potentiellement en utilisant un déploiement à trois cartes réseau s'ils déploient dans un environnement de production où la sécurité, la redondance, la disponibilité, la capacité et l'évolutivité sont critiques. Avec cette méthode de déploiement, la complexité et la facilité de gestion ne sont pas des préoccupations critiques pour les utilisateurs.
Déploiement Single-NIC Multi-IP (une carte réseau) pour la reprise après sinistre
Les clients déploieraient potentiellement en utilisant un déploiement à une carte réseau s'ils déploient dans un environnement non-production pour les raisons suivantes :
-
Mettre en place l'environnement pour les tests, ou ils préparent un nouvel environnement avant le déploiement en production.
-
Déployer directement dans le cloud rapidement et efficacement.
-
Tout en recherchant la simplicité d'une configuration de sous-réseau unique.