- Panoramica
- Fase 1: Inventario e valutazione dei servizi di bilanciamento del carico esistenti
- Fase 2: Progettazione del target RELIANOID Architettura di rete
- Fase 3: Preparazione RELIANOID per la migrazione
- Passaggio 4: configurare le interfacce di rete
- Passaggio 5: caricamento dei certificati SSL della farm
- Fase 6: Servizi di traduzione in RELIANOID
- Passaggio 7: configurare il servizio cluster
- Fase 8: Configurazione finale del servizio tramite interfaccia utente Web
- Fase 9: Cutover e dismissione
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:
- Inventario e valutazione dei servizi esistenti
- Architettura di destinazione e progettazione di rete in RELIANOID
- Preparazione RELIANOID per la migrazione (accesso API e isolamento)
- Applicazione della configurazione di rete tramite noid-cli
- Traduzione e creazione di servizi (L4, HTTP/HTTPS, GSLB)
- 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:
- Passare a: Sistema > Impostazioni utenti > API
- Fare clic su Abilita l'autorizzazione API
- Imposta un API Key o applica su Genera chiave casuale
- Conservare la chiave in modo sicuro
- Fare clic su Abilita l'autorizzazione API

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.

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 #
- Creare la nuova farm HTTP/S.
- Imposta l'ascoltatore (HTTP o HTTPS).
- Aggiungere il certificato SSL nella farm.
- Crea un nuovo servizio (ad es. difetto) nella fattoria.
- Imposta la persistenza del servizio tramite Cookies e imposta i backend che distribuiscono l'applicazione in modo semplice HTTP.
- 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) #
- Creare la nuova farm L4.
- Imposta il protocollo (TCP, UDP…), NAT modalità (senza trasparenza) e persistenza da IP di origine.
- 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:
- Spostare il traffico di produzione (modifica DNS o routing)
- Monitorare almeno un ciclo economico
- Revoca la chiave API temporanea
- Dismettere il bilanciatore di carico legacy