Documentation Produit
ADC
14.1 - Current Release 13.1 13.0 12.1
Voir PDF

Configurer GSLB sur des instances NetScaler VPX

August 11, 2023
Contributeur: 
C

Les appliances NetScaler configurées pour l’équilibrage global de la charge des serveurs (GSLB) assurent la reprise après sinistre et la disponibilité continue des applications en les protégeant contre les points de défaillance d’un réseau étendu. GSLB peut équilibrer la charge entre les centres de données en dirigeant les demandes 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 GSLB sur des instances VPX sur deux sites dans un environnement Microsoft Azure, à l’aide des commandes Windows PowerShell.

Remarque

Pour plus d’informations sur GSLB, consultez Global Server Load Balancing.

Vous pouvez configurer GSLB sur une instance NetScaler VPX sur Azure, en deux étapes :

  1. Créez une instance VPX avec plusieurs cartes réseau et plusieurs adresses IP, sur chaque site.
  2. Activez GSLB sur les instances VPX.

Remarque

Pour plus d’informations sur la configuration de plusieurs cartes réseau et adresses IP, voir : Configurer plusieurs adresses IP pour une instance NetScaler VPX en mode autonome àl’aide des commandes PowerShell

Scénario

Ce scénario inclut deux sites : le site 1 et le site 2. Chaque site possède une machine virtuelle (VM1 et VM2) configurée avec plusieurs cartes réseau, plusieurs adresses IP et GSLB.

Figure. Mise en place de la GSLB sur deux sites - le site 1 et le site 2.

Topologie VPX Azure GSLB

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.

  • Carte réseau 0/1 : pour le trafic de gestion
  • Carte réseau 1/1 : pour servir le trafic côté client
  • NIC 1/2 : pour communiquer avec les serveurs back-end

Pour plus d’informations sur les adresses IP configurées sur chaque carte réseau dans ce scénario, reportez-vous à la section Détails de la configuration IP .

Paramètres

Voici des exemples de paramètres de paramètres pour ce scénario dans ce document. Vous pouvez utiliser différents paramètres si vous le souhaitez.

$location="West Central US"

$vnetName="NSVPX-vnet"

$RGName="multiIP-RG"

$prmStorageAccountName="multiipstorageaccnt"

$avSetName="MultiIP-avset"

$vmSize="Standard_DS3_V2"

<!--NeedCopy-->

Remarque : La configuration minimale requise pour une instance VPX est de 2 processeurs virtuels et de 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
<!--NeedCopy-->

Créer une machine virtuelle

Suivez les étapes 1 à 10 pour créer VM1 avec plusieurs cartes réseau et plusieurs adresses IP, à l’aide des commandes PowerShell :

  1. Créer un groupe de ressources

  2. Créer un compte de stockage

  3. Créer un ensemble de disponibilités

  4. Création d’un réseau virtuel

  5. Créer une adresse IP publique

  6. Créer des cartes réseau

  7. Créer un objet de configuration de machine virtuelle

  8. Obtenir des informations d’identification et définir les propriétés du système d’exploitation pour la machine virtuelle

  9. Ajouter des cartes réseau

  10. Spécifier le disque du système d’exploitation et créer une machine virtuelle

Après avoir effectué toutes les étapes et commandes nécessaires à la création de VM1, répétez ces étapes pour créer une VM2 avec les paramètres qui lui sont spécifiques.

Créer un groupe de ressources 

New-AzureRMResourceGroup -Name $RGName -Location $location
<!--NeedCopy-->

Créer un compte de stockage 

$prmStorageAccount=New-AzureRMStorageAccount -Name $prmStorageAccountName -ResourceGroupName $RGName -Type Standard_LRS -Location $location
<!--NeedCopy-->

Créer un ensemble de disponibilités 

$avSet=New-AzureRMAvailabilitySet -Name $avSetName -ResourceGroupName $RGName -Location $location
<!--NeedCopy-->

Création d’un réseau virtuel

  1. Ajoutez 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"
<!--NeedCopy-->

  2. Ajoutez un objet réseau virtuel.

    $vnet=New-AzureRmVirtualNetwork -Name $vnetName -ResourceGroupName $RGName -Location $location -AddressPrefix 10.0.0.0/16 -Subnet $subnet1, $subnet2, $subnet3
<!--NeedCopy-->

  3. Récupérez des sous-réseaux.

    $frontendSubnet=$vnet.Subnets|?{$\_.Name -eq $frontendSubnetName}
$backendSubnet1=$vnet.Subnets|?{$\_.Name -eq $backendSubnetName1}
$backendSubnet2=$vnet.Subnets|?{$_.Name -eq $backendSubnetName2}
<!--NeedCopy-->

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
<!--NeedCopy-->

Créer des cartes réseau

Créer une carte réseau 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
<!--NeedCopy-->

Créer une carte réseau 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
<!--NeedCopy-->

Créer une carte réseau 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
<!--NeedCopy-->

Créer un objet de configuration de machine virtuelle 

$vmName=$vmNamePrefix
$vmConfig=New-AzureRMVMConfig -VMName $vmName -VMSize $vmSize -AvailabilitySetId $avSet.Id
<!--NeedCopy-->

Obtenir des informations d’identification et définir les propriétés du système d’exploitation 

$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-->

Ajouter des cartes réseau 

$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-->

Spécifier le disque du système d’exploitation et créer une machine virtuelle 

$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-->

Remarque

Répétez les étapes 1 à 10 répertoriées dans « Créer des machines virtuelles multi-cartes réseau à l’aide des commandes PowerShell » pour créer VM2 avec des paramètres spécifiques à VM2.

Détails de la configuration IP

Les adresses IP suivantes sont utilisées.

Tableau 1 Adresses IP utilisées dans VM1

Carte d’interface réseau IP privée Adresse IP publique (PIP) Description
0/1 10.0.0.10 PIP1 Configuré en tant que NSIP (IP de gestion)
1/1 10.0.1.10 PIP2 Configuré en tant qu’adresse IP du site SNIP/GSLB
- 10.0.1.11 - Configuré en tant qu’adresse IP du serveur LB. L’adresse IP publique n’est pas obligatoire
1/2 10.0.2.10 - Configuration en tant que SNIP pour l’envoi de sondes de moniteur aux services ; une IP publique n’est pas obligatoire

Tableau 2. Adresses IP utilisées dans VM2

Carte d’interface réseau IP interne Adresse IP publique (PIP) Description
0/1 20.0.0.10 PIP4 Configuré en tant que NSIP (IP de gestion)
1/1 20.0.1.10 PIP5 Configuré en tant qu’adresse IP du site SNIP/GSLB
- 20.0.1.11 - Configuré en tant qu’adresse IP du serveur LB. L’adresse IP publique n’est pas obligatoire
1/2 20.0.2.10 - Configuration en tant que SNIP pour l’envoi de sondes de moniteur aux services ; une IP publique n’est pas obligatoire

Voici des exemples de configurations pour ce scénario, montrant les adresses IP et les configurations LB initiales créées via l’interface de ligne de commande 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]
<!--NeedCopy-->

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]
<!--NeedCopy-->

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 les autres paramètres nécessaires :

Équilibrage de charge de serveur global

Pour plus d’informations, consultez cet article de support :https://support.citrix.com/article/CTX110348

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
<!--NeedCopy-->

Vous avez configuré GSLB sur des instances NetScaler VPX exécutées sur Azure.

Récupération d’urgence

La catastrophe est une perturbation soudaine des fonctions commerciales causée par des catastrophes naturelles ou des événements d’origine humaine. Les catastrophes 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 datacenter sont critiques et réduit la continuité de l’activité.

L’un des défis auxquels les clients sont confrontés aujourd’hui est de décider où placer leur site de reprise après sinistre. Les entreprises recherchent la cohérence et les performances indépendamment des défaillances de l’infrastructure sous-jacente ou du réseau.

Les raisons possibles pour lesquelles de nombreuses entreprises décident de migrer vers le cloud sont les suivantes :

  • Disposer d’un centre de données sur site coûte très cher. En utilisant le cloud, les entreprises peuvent libérer du temps et des ressources pour étendre leurs propres systèmes.

  • La plupart des orchestrations automatisées permettent une restauration plus rapide

  • Répliquez les données en fournissant une protection continue des données ou des instantanés continus pour vous prémunir contre toute panne ou attaque.

  • Prenez en charge les cas d’utilisation dans lesquels les clients ont besoin de différents types de contrôles de conformité et de sécurité déjà présents sur les clouds publics. Ils leur permettent d’atteindre plus facilement la conformité dont ils ont besoin plutôt que de créer leur propre solution.

Un NetScaler configuré pour 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 est en panne. NetScaler permet ainsi aux clients d’économiser du temps et de l’argent.

Déploiement de plusieurs cartes réseau et de plusieurs adresses IP (trois cartes réseau) pour la reprise après sinistre

Les clients peuvent déployer à l’aide d’un déploiement à trois cartes réseau s’ils effectuent un déploiement dans un environnement de production où la sécurité, la redondance, la disponibilité, la capacité et l’évolutivité sont essentielles. 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 d’une seule carte réseau et de plusieurs adresses IP (une carte réseau) pour la reprise après sinistre

Les clients sont susceptibles de procéder à un déploiement à l’aide d’une seule carte réseau s’ils le déploient dans un environnement hors production pour les raisons suivantes :

  • Ils configurent l’environnement à des fins de test, ou ils mettent en place un nouvel environnement avant le déploiement en production.

  • Déploiement rapide et efficace directement dans le cloud.

  • Tout en recherchant la simplicité d’une configuration de sous-réseau unique.

Configurer GSLB sur des instances NetScaler VPX
August 11, 2023
Contributeur: 
C
August 11, 2023
Contributeur: 
C

Dans cet article

Commentaires sur le site | Your privacy choices footer linkVos préférences de confidentialité | Confidentialité et conditions légales | Préférences de cookies | Paramètres de consentement | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.