Vue d'ensemble #

Cet article décrit un méthodologie structurée et sûre migrer les services depuis tout fournisseur d'équilibrage de charge tiers (matériel ou logiciel) à RELIANOID Load Balancer.

Cette procédure minimise les risques en séparant l'analyse, la mise en réseau, la traduction des services et l'activation finale, tout en permettant la coexistence pendant la période de migration.

La migration est divisée en plusieurs phases :

1. Inventaire et évaluation des services existants
2. Architecture cible et conception de réseau dans RELIANOID
3. Préparation RELIANOID pour la migration (accès API et isolation)
4. Application de la configuration réseau à l'aide de noid-cli
5. Traduction et création de services (L4, HTTP/HTTPS, GSLB)
6. Renforcement final du service et activation via l'interface utilisateur Web

Étape 1 : Inventaire et évaluation des services d'équilibrage de charge existants #

Avant de toucher RELIANOID, documentez tout à partir de l'équilibreur de charge source.

Tableau d'inventaire des services #

Créer un inventaire comprenant Entrant (VIP) sortant (serveurs backend ou serveurs réels) configuration:

Nom du service	Type (L4, HTTP/S, GSLB)	Protocole (TCP, UDP, SCTP, TOUS)	VIP	Ports VIP	Persistence	Adresse IP et port du serveur dorsal 1	Adresse IP et port du serveur dorsal 2	Adresse IP et port du serveur dorsal 3	Adresse IP et port du serveur dorsal 4	Une configuration avancée
web-prod-ssl	HTTPS	TCP	192.0.2.10	443	Cookies	10.0.1.10:80	10.0.1.11:80	10.0.1.12:80	-	WAF activé, utilisant le certificat SSL mycert.pem
API-L4	L4	TCP	192.0.2.20	8443	IP source	10.0.2.5	10.0.2.6	-	-	-
dns-gslb	GSLB	UDP	192.0.2.40	53	Priorité	23.3.3.3	53.3.3.3	-	-	-

Éléments clés à identifier #

Pour chaque service, identifier :

• VIP et adresses IP flottantes
• Ports et protocoles d'écoute
• Serveurs backend et contrôles de santé
• Méthode de persistance (cookie, adresse IP source, en-tête)
• Les certificats SSL
• Fonctionnalités avancées (WAF, limitation du débit, réécriture d'en-tête)
• Dépendances DNS (en particulier pour GSLB)

Cet inventaire sera directement associé à RELIANOID objets.

Étape 2 : Conception de la cible RELIANOID Architecture de réseau #

RELIANOID impose une séparation claire entre le réseau et les services, ce qui simplifie les migrations.

Conception des interfaces réseau #

En fonction de votre inventaire :

• Réseau frontal : là où les VIP seront exposés
• Réseau(x) backend : où résident les serveurs physiques
• réseau de gestion optionnel

Exemple :

Interface	Interet	IP
eth0	Direction	192.168.100.10
eth1	Interface utilisateur (VIP)	192.0.2.0/24
eth2	backend	10.0.0.0/16

Considérations relatives au routage et à la haute disponibilité #

Assurez la symétrie du routage entre RELIANOID et les serveurs backend.

Pour les configurations HA, veuillez confirmer :

• Comportement de basculement d'adresse IP virtuelle
• ARP gratuit autorisé
• Règles de pare-feu alignées sur les nouvelles adresses MAC/IP

Étape 3 : Préparation RELIANOID pour les migrations #

Lors de la migration, activez et configurez la clé API pour un accès temporaire. L'accès API permet l'automatisation et la reproductibilité.

Extrait du Interface Web:

1. Accédez à: Système > Paramètres utilisateur > API
2. Cliquez sur Autorisation d'accès à l'API
3. Définissez un clé API ou postuler sur Générer une clé aléatoire
4. Conservez la clé en toute sécurité
5. Cliquez sur Autorisation d'accès à l'API

Cette clé sera utilisée par noid-cli.

Authentifier noid-cli #

Ensuite, connectez-vous via la console ou SSH et authentifiez-vous avec la clé API dans le noid-cli.

root@noid3-82-1:~# Clé API de l'équilibreur de charge noid-cli : 

Cela n'est requis que la première fois que noid-cli est lancé.

Étape 4 : Configurer les interfaces réseau #

La configuration réseau doit toujours être effectuée avant la création du service.

noid-cli (localhost) : network-nic set eth0 -ip 192.168.100.10 -netmask 255.255.255.0 -gateway 192.168.100.1 noid-cli (localhost) : network-nic start eth0 noid-cli (localhost) : network-nic set eth1 -ip 192.0.2.5 -netmask 255.255.255.0 noid-cli (localhost) : network-nic start eth1 noid-cli (localhost) : network-nic set eth2 -ip 10.0.0.5 -netmask 255.255.255.0 noid-cli (localhost) : network-nic start eth2

Confirmer via interface utilisateur Web que la configuration a été appliquée dans Réseau> NIC.

Tester la connectivité #

Tester la connectivité avec ping commande contre les passerelles d'interfaces réseau :

ping 192.168.100.1

Ajouter des adresses IP virtuelles (VIP) #

Ces adresses IP virtuelles seront utilisées pour les services d'équilibrage de charge et seront déplacées entre les nœuds du cluster d'équilibrage de charge.

noid-cli (localhost) : création de l'interface virtuelle eth1:web0 -ip 192.0.2.10 noid-cli (localhost) : démarrage de l'interface virtuelle eth1:web0 noid-cli (localhost) : création de l'interface virtuelle eth1:web1 -ip 192.0.2.11 noid-cli (localhost) : démarrage de l'interface virtuelle eth1:web1 noid-cli (localhost) : création de l'interface virtuelle eth1:web2 -ip 192.0.2.12 noid-cli (localhost) : démarrage de l'interface virtuelle eth1:web2 noid-cli (localhost) : création de l'interface virtuelle eth1:web3 -ip 192.0.2.13 noid-cli (localhost) : démarrage de l'interface virtuelle eth1:web3

Confirmer via interface utilisateur Web que la configuration a été appliquée dans Réseau> Interfaces virtuelles.

Étape 5 : Téléchargement des certificats SSL de la ferme #

Dans l' interface utilisateur Web Certificats LSLB> SSL Veuillez télécharger les certificats SSL au format PEM qui seront utilisés dans les fermes HTTPS répertoriées dans l'inventaire précédent des services d'équilibrage de charge.

Étape 6 : Services de traduction vers RELIANOID #

Des commandes CLI semi-automatisées peuvent être générées à l'aide des modèles suivants, ce qui devrait rendre la création du service très simple et directe.

À n'importe quelle étape, les mêmes commandes exécutées via noid-cli, peut être appliqué via interface utilisateur Web également.

Services HTTP/HTTPS #

1. Créer la nouvelle ferme HTTP/S.
2. Configurer l'écouteur (HTTP ou HTTPS).
3. Ajoutez le certificat SSL à la ferme.
4. Créer un nouveau service (ex. défaut) à la ferme.
5. Configurez la persistance du service par Cookies et configurez les backends pour qu'ils fournissent l'application en clair HTTP.
6. Ensuite, ajoutez les backends.

noid-cli (localhost) : farm create -farmname web-prod -profile http -vip 192.0.2.10 -vport 443 noid-cli (localhost) : farm set web-prod -listener https noid-cli (localhost) : farm-certificate add web-prod -file example.pem noid-cli (localhost) : farm-service add web-prod -id default noid-cli (localhost) : farm-service set web-prod default -persistence COOKIE -sessionid ASP.SessionId -httpsb false noid-cli (localhost) : farm-service-backend add web-prod default -ip 10.0.1.10 -port 80 noid-cli (localhost) : farm-service-backend add web-prod default -ip 10.0.1.11 -port 80 noid-cli (localhost) : farm-service-backend add web-prod default -ip 10.0.1.12 -port 80

Enfin, les détails concernant la configuration du service, tels que : Gardien de ferme pour les bilans de santé et WAF La configuration peut être configurée via interface utilisateur Web pour faciliter le processus.

Services de couche 4 (TCP/UDP) #

1. Créer la nouvelle ferme L4.
2. Définir le protocole (TCP, UDP…), NAT mode (sans transparence) et persistance par IP source.
3. Ensuite, ajoutez les backends.

noid-cli (localhost) : création de la ferme -farmname api-l4 -profile l4xnat -vip 192.0.2.20 -vport 8443 noid-cli (localhost) : configuration de la ferme api-l4 -protocole tcp -nattype nat -persistence srcip noid-cli (localhost) : ajout du service de la ferme api-l4 default_service -ip 10.0.2.5 noid-cli (localhost) : ajout du service de la ferme api-l4 default_service -ip 10.0.2.6

Enfin, confirmez et terminez la configuration dans le interface utilisateur Web si nécessaire, en ajoutant un Gardien de ferme Contrôle sanitaire ou politiques de sécurité.

Étape 7 : Configurer le service de cluster #

À ce stade, il est opportun de procéder à la configuration du service de clustering entre deux nœuds d'équilibrage de charge, s'il n'a pas encore été créé. Ensuite, toute la configuration relative à Interfaces Virtuelles Fermes sera répliqué automatiquement sur le nœud secondaire.

Étape 8 : Configuration finale du service via l’interface Web #

Certaines configurations avancées ou sensibles sont intentionnellement finalisées dans le Interface Web.

Fonctionnalités HTTP avancées #

Configurez et réexaminez les options concernant :

• Réécritures d'en-tête
• Les redirections
• Règles WAF
• Bilans de santé personnalisés

Validation avant la mise en service #

Services de test utilisant :

• Entrées DNS temporaires
• remplacement du fichier hosts
• Ports alternatifs

Moniteur:

• Santé du backend
• Journaux
• Persistance de session

Étape 9 : Basculement et mise hors service #

Une fois validé :

1. Déplacer le trafic de production (modification DNS ou de routage)
2. Surveiller pendant au moins un cycle économique
3. Révoquer la clé API temporaire
4. Mise hors service de l'ancien équilibreur de charge