Oversigt #

Denne artikel beskriver en struktureret og sikker metode at migrere tjenester fra enhver tredjepartsleverandør af load balancer (hardware eller software) til RELIANOID Load Balancer.

Proceduren minimerer risikoen ved at adskille analyse, netværk, tjenesteoversættelse og endelig aktivering, samtidig med at den muliggør sameksistens under migreringsvinduet.

Migrationen er opdelt i følgende faser:

1. Opgørelse og vurdering af eksisterende tjenester
2. Målarkitektur og netværksdesign i RELIANOID
3. Forberedelse RELIANOID til migrering (API-adgang og isolering)
4. Anvendelse af netværkskonfiguration ved hjælp af noid-cli
5. Oversættelse og oprettelse af tjenester (L4, HTTP/HTTPS, GSLB)
6. Endelig servicehærdning og aktivering via web UI

Trin 1: Opgørelse og vurdering af eksisterende load balancer-tjenester #

Før du rører ved RELIANOID, dokumenter alt fra kildens load balancer.

Serviceopgørelsestabel #

Opret en inventarliste, herunder indgående (VIP) og udgående (backends eller rigtige servere) konfiguration:

Servicenavn	Type (L4, HTTP/S, GSLB)	Protokol (TCP, UDP, SCTP, ALL)	VIP	VIP-porte	Vedholdenhed	Backend 1 IP og port	Backend 2 IP og port	Backend 3 IP og port	Backend 4 IP og port	Avanceret konfiguration
web-prod-ssl	HTTPS	TCP	192.0.2.10	443	Cookie	10.0.1.10:80	10.0.1.11:80	10.0.1.12:80	-	WAF aktiveret, ved brug af SSL-certifikatet mycert.pem
api-l4	L4	TCP	192.0.2.20	8443	Kilde IP	10.0.2.5	10.0.2.6	-	-	-
dns-gslb	GSLB	UDP	192.0.2.40	53	Prioritet	23.3.3.3	53.3.3.3	-	-	-

Nøgleelementer at identificere #

For hver tjeneste skal du identificere:

• VIP'er og flydende IP'er
• Lytteporte og protokoller
• Backend-servere og sundhedstjek
• Persistensmetode (cookie, kilde-IP, header)
• SSL-certifikater
• Avancerede funktioner (WAF, hastighedsbegrænsning, header-omskrivning)
• DNS-afhængigheder (især for GSLB)

Denne beholdning vil blive direkte knyttet til RELIANOID objekter.

Trin 2: Design af målet RELIANOID Netværksarkitektur #

RELIANOID håndhæver en klar adskillelse mellem netværk og tjenester, hvilket forenkler migreringer.

Design af netværksgrænseflader #

Baseret på din beholdning:

• Frontend-netværk: hvor VIP'er vil blive eksponeret
• Backend-netværk: hvor rigtige servere befinder sig
• Valgfrit administrationsnetværk

Eksempel:

grænseflade	Formål	IP
eth0	Management	192.168.100.10
eth1	Frontend (VIP'er)	192.0.2.0/24
eth2	Bagende	10.0.0.0/16

Overvejelser vedrørende routing og høj tilgængelighed #

Sørg for symmetri i ruteføringen mellem RELIANOID og backend-servere.

For HA-opsætninger, bekræft:

• Virtuel IP-failover-adfærd
• Gratis ARP tilladt
• Firewallregler justeret med nye MAC/IP-adresser

Trin 3: Forberedelse RELIANOID til migration #

Under migreringen skal du aktivere og konfigurere API-nøglen til midlertidig adgang. API-adgang muliggør automatisering og gentagelsesnøjagtighed.

På hjemmesiden for oprettelse af en konto skal du indtaste postnummeret for dit service-eller faktureringsområde i feltet, der er markeret (A) på billedet ovenfor. Web UI:

1. Naviger til: System > Brugerindstillinger > API
2. Klik på Aktivér API-tilladelse
3. Indstil en API Key eller ansøg på Generer tilfældig nøgle
4. Opbevar nøglen sikkert
5. Klik på Aktivér API-tilladelse

Denne nøgle vil blive brugt af noid-cli.

Godkend noid-cli #

Opret derefter forbindelse via konsol eller SSH og godkend med API-nøglen i noid-cli.

root@noid3-82-1:~# noid-cli Load balancer API-nøgle: 

Dette er kun nødvendigt første gang noid-cli lanceres.

Trin 4: Konfigurer netværksgrænseflader #

Netværk bør altid konfigureres før oprettelse af tjenester.

noid-cli (localhost): netværksnic sæt eth0 -ip 192.168.100.10 -netmask 255.255.255.0 -gateway 192.168.100.1 noid-cli (localhost): netværksnic start eth0 noid-cli (localhost): netværksnic sæt eth1 -ip 192.0.2.5 -netmask 255.255.255.0 noid-cli (localhost): netværksnic start eth1 noid-cli (localhost): netværksnic sæt eth2 -ip 10.0.0.5 -netmask 255.255.255.0 noid-cli (localhost): netværksnic start eth2

Bekræft via web UI at konfigurationen er blevet anvendt i Netværk > NIC.

Test forbindelsen #

Test forbindelse med ping kommando mod netværksgrænsefladernes gateways:

Tabel 192.168.100.1

Tilføj virtuelle IP'er (VIP'er) #

Disse virtuelle IP-adresser vil blive brugt til load balancing-tjenester og vil flyttes mellem load balancing-klyngenoder.

noid-cli (localhost): netværk-virtuel create -name eth1:web0 -ip 192.0.2.10 noid-cli (localhost): netværk-virtuel start eth1:web0 noid-cli (localhost): netværk-virtuel create -name eth1:web1 -ip 192.0.2.11 noid-cli (localhost): netværk-virtuel start eth1:web1 noid-cli (localhost): netværk-virtuel create -name eth1:web2 -ip 192.0.2.12 noid-cli (localhost): netværk-virtuel start eth1:web2 noid-cli (localhost): netværk-virtuel create -name eth1:web3 -ip 192.0.2.13 noid-cli (localhost): netværk-virtuel start eth1:web3

Bekræft via web UI at konfigurationen er blevet anvendt i Netværk > Virtuelle grænseflader.

Trin 5: Upload af farm SSL-certifikater #

I web UI sektion LSLB > SSL-certifikater Upload SSL-certifikaterne i PEM-format, der skal bruges i de HTTPS-farme, der er anført i den tidligere oversigt over load balancing-tjenester.

Trin 6: Oversættelse af tjenester til RELIANOID #

Semiautomatiske CLI-kommandoer kan genereres ved hjælp af følgende skabeloner, så oprettelsen af ​​tjenester burde være meget nem og ligetil.

På ethvert tidspunkt udføres de samme kommandoer via noid-cli, kan anvendes via web UI også.

HTTP/HTTPS-tjenester #

1. Opret den nye HTTP/S-farm.
2. Indstil lytteren (HTTP eller HTTPS).
3. Tilføj SSL-certifikatet i farmen.
4. Opret en ny tjeneste (f.eks. standard) på gården.
5. Indstil tjenestens persistens ved Cookie og indstil backends til at levere applikationen i almindelighed HTTP.
6. Tilføj derefter 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

Endelig detaljerne om servicekonfigurationen, f.eks. Gårdværge til sundhedstjek og WAF konfigurationen kan konfigureres via web UI for at lette processen.

Lag 4 (TCP/UDP) tjenester #

1. Opret den nye L4-farm.
2. Indstil protokollen (TCP, UDP…), NAT tilstand (uden gennemsigtighed) og persistens ved kilde IP.
3. Tilføj derefter backends.

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

Bekræft og fuldfør til sidst konfigurationen i web UI om nødvendigt ved at tilføje en Gårdværge sundhedstjek eller sikkerhedspolitikker.

Trin 7: Konfigurer klyngetjenesten #

På dette tidspunkt er det et godt tidspunkt at fortsætte med konfigurationen af ​​klyngetjenesten mellem 2 load balancer-noder, hvis den ikke er oprettet endnu. Derefter udføres al konfigurationen i forhold til Virtuelle grænseflader og Gårde vil automatisk blive replikeret til den sekundære node.

Trin 8: Endelig servicekonfiguration via webgrænsefladen #

Nogle avancerede eller følsomme konfigurationer er bevidst færdiggjort i Web UI.

Avancerede HTTP-funktioner #

Konfigurer og gennemgå mulighederne for:

• Omskrivning af headere
• omdirigeringer
• WAF regler
• Tilpassede sundhedstjek

Validering før overgang #

Testtjenester ved hjælp af:

• Midlertidige DNS-poster
• Tilsidesættelser af værtsfiler
• Alternative porte

Monitor:

• Backend-sundhed
• Logs
• Session vedholdenhed

Trin 9: Nedskæring og nedlukning #

Når den er valideret:

1. Flyt produktionstrafik (DNS- eller routingændring)
2. Overvåg i mindst én konjunkturcyklus
3. Tilbagekald midlertidig API-nøgle
4. Afmonter ældre load balancer