Passaggi per migrare qualsiasi configurazione del Load Balancer a RELIANOID

Visualizza categorie

Passaggi per migrare qualsiasi configurazione del Load Balancer a RELIANOID

6 min letto

Panoramica #

Questo articolo descrive un metodologia strutturata e sicura per migrare i servizi da qualsiasi fornitore di bilanciatori di carico di terze parti (hardware o software) a RELIANOID Load Balancer.

La procedura riduce al minimo i rischi separando analisi, networking, traduzione del servizio e attivazione finale, consentendo al contempo la coesistenza durante la finestra di migrazione.

La migrazione si articola nelle seguenti fasi:

  1. Inventario e valutazione dei servizi esistenti
  2. Architettura di destinazione e progettazione di rete in RELIANOID
  3. Preparazione RELIANOID per la migrazione (accesso API e isolamento)
  4. Applicazione della configurazione di rete tramite noid-cli
  5. Traduzione e creazione di servizi (L4, HTTP/HTTPS, GSLB)
  6. Rafforzamento e attivazione del servizio finale tramite interfaccia utente Web

Fase 1: Inventario e valutazione dei servizi di bilanciamento del carico esistenti #

Prima di toccare RELIANOID, documentare tutto dal bilanciatore del carico di origine.

Tabella inventario servizi #

Crea un inventario che includa in entrata (VIP) and in uscita (backend o server reali) Configurazione:

Nome di Servizio Tipo (L4, HTTP/S, GSLB) Protocollo (TCP, UDP, SCTP, ALL) Pachetto VIP Porti VIP Persistenza Backend 1 IP e porta Backend 2 IP e porta Backend 3 IP e porta Backend 4 IP e porta Configurazione avanzata
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 abilitato, utilizzando il certificato SSL mycert.pem
api-l4 L4 TCP 192.0.2.20 8443 IP di origine 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 - - -

Elementi chiave da identificare #

Per ogni servizio, identificare:

  • VIP e IP fluttuanti
  • Porte e protocolli di ascolto
  • Server backend e controlli di integrità
  • Metodo di persistenza (cookie, IP sorgente, intestazione)
  • Certificati SSL
  • Funzionalità avanzate (WAF, limitazione della velocità, riscrittura dell'intestazione)
  • Dipendenze DNS (in particolare per GSLB)

Questo inventario verrà mappato direttamente su RELIANOID oggetti.

Fase 2: Progettazione del target RELIANOID Architettura di rete #

RELIANOID impone una netta separazione tra networking e servizi, semplificando le migrazioni.

Progettazione delle interfacce di rete #

In base al tuo inventario:

  • Rete frontend: dove saranno esposti i VIP
  • Rete/i backend: dove risiedono i server reali
  • Rete di gestione opzionale

Esempio:

Interfaccia Missione IP
eth0 Management 192.168.100.10
eth1 Frontend (VIP) 192.0.2.0/24
eth2 BACKEND 10.0.0.0/16

Considerazioni su routing e alta disponibilità #

Assicurare la simmetria di routing tra RELIANOID e server backend.

Per le configurazioni HA, confermare:

  • Comportamento del failover IP virtuale
  • ARP gratuito consentito
  • Regole del firewall allineate con i nuovi MAC/IP

Fase 3: Preparazione RELIANOID per la migrazione #

Durante la migrazione, abilita e configura la chiave API per l'accesso temporaneo. L'accesso API consente automazione e ripetibilità.

Dal Interfaccia utente Web:

  1. Passare a: Sistema > Impostazioni utenti > API
  2. Fare clic su Abilita l'autorizzazione API
  3. Imposta un API Key o applica su Genera chiave casuale
  4. Conservare la chiave in modo sicuro
  5. Fare clic su Abilita l'autorizzazione API

relianoid_configure_user_api_key

Questa chiave verrà utilizzata da noid-cli.

autenticare noid-cli #

Quindi, connettiti tramite console o SSH e autenticati con la chiave API nel noid-cli.

root@noid3-82-1:~# noid-cli Chiave API del bilanciatore del carico: 

Questo è richiesto solo la prima volta che noid-cli è lanciato.

relianoid_noid-cli

Passaggio 4: configurare le interfacce di rete #

La rete deve essere sempre configurata prima della creazione del servizio.

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

Conferma tramite interfaccia utente web che la configurazione è stata applicata in Rete> NIC.

Testare la connettività #

Testare la connettività con ping comando contro i gateway delle interfacce di rete:

ping 192.168.100.1

Aggiungi IP virtuali (VIP) #

Questi indirizzi IP virtuali verranno utilizzati per i servizi di bilanciamento del carico e si sposteranno tra i nodi del cluster di bilanciamento del carico.

noid-cli (localhost): network-virtual create -name eth1:web0 -ip 192.0.2.10 noid-cli (localhost): network-virtual start eth1:web0 noid-cli (localhost): network-virtual create -name eth1:web1 -ip 192.0.2.11 noid-cli (localhost): network-virtual start eth1:web1 noid-cli (localhost): network-virtual create -name eth1:web2 -ip 192.0.2.12 noid-cli (localhost): network-virtual start eth1:web2 noid-cli (localhost): network-virtual create -name eth1:web3 -ip 192.0.2.13 noid-cli (localhost): network-virtual start eth1:web3

Conferma tramite interfaccia utente web che la configurazione è stata applicata in Rete> Interfacce virtuali.

Passaggio 5: caricamento dei certificati SSL della farm #

Nel interfaccia utente web pagina LSLB> Certificati SSL caricare i certificati SSL in formato PEM da utilizzare nelle farm HTTPS elencate nel precedente inventario dei servizi di bilanciamento del carico.

Fase 6: Servizi di traduzione in RELIANOID #

È possibile generare comandi CLI semi-automatici utilizzando i seguenti modelli, in modo che la creazione del servizio risulti molto semplice e immediata.

In ogni fase, gli stessi comandi eseguiti tramite noid-cli, può essere applicato tramite interfaccia utente web come pure.

Servizi HTTP / HTTPS #

  1. Creare la nuova farm HTTP/S.
  2. Imposta l'ascoltatore (HTTP o HTTPS).
  3. Aggiungere il certificato SSL nella farm.
  4. Crea un nuovo servizio (ad es. difetto) nella fattoria.
  5. Imposta la persistenza del servizio tramite Cookies e imposta i backend che distribuiscono l'applicazione in modo semplice HTTP.
  6. Quindi, aggiungi i backend.
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 -porta 80

Infine, i dettagli sulla configurazione del servizio come Guardiano della fattoria per controlli sanitari e WAF la configurazione può essere configurata tramite interfaccia utente web per facilitare il processo.

Servizi di livello 4 (TCP/UDP) #

  1. Creare la nuova farm L4.
  2. Imposta il protocollo (TCP, UDP…), NAT modalità (senza trasparenza) e persistenza da IP di origine.
  3. Quindi, aggiungi i backend.
noid-cli (localhost): farm create -farmname api-l4 -profile l4xnat -vip 192.0.2.20 -vport 8443 noid-cli (localhost): farm set api-l4 -protocol tcp -nattype nat -persistence srcip noid-cli (localhost): farm-service-backend add api-l4 default_service -ip 10.0.2.5 noid-cli (localhost): farm-service-backend add api-l4 default_service -ip 10.0.2.6

Infine, confermare e completare la configurazione nel interfaccia utente web se richiesto aggiungendo un Guardiano della fattoria controllo sanitario o politiche di sicurezza.

Passaggio 7: configurare il servizio cluster #

A questo punto, è opportuno procedere con la configurazione del servizio di clustering tra 2 nodi del load balancer, nel caso in cui non sia ancora stato creato. Quindi, tutte le configurazioni eseguite per quanto riguarda Interfacce virtuali and Farms verrà replicato automaticamente sul nodo secondario.

Fase 8: Configurazione finale del servizio tramite interfaccia utente Web #

Alcune configurazioni avanzate o sensibili sono intenzionalmente finalizzate nel Interfaccia utente Web.

Funzionalità HTTP avanzate #

Configurare e rivedere le opzioni relative a:

  • Riscritture dell'intestazione
  • Reindirizzamenti
  • Regole WAF
  • Controlli sanitari personalizzati

Convalida prima del passaggio #

Servizi di test utilizzando:

  • Voci DNS temporanee
  • Sovrascritture dei file host
  • Porte alternative

Controllo:

  • Salute del backend
  • Registri
  • Persistenza della sessione

Fase 9: Cutover e dismissione #

Una volta convalidato:

  1. Spostare il traffico di produzione (modifica DNS o routing)
  2. Monitorare almeno un ciclo economico
  3. Revoca la chiave API temporanea
  4. Dismettere il bilanciatore di carico legacy

📄 Scarica questo documento in formato PDF #

    EMAIL: *

    Sviluppato da BetterDocs