Adatközpont-migráció nyilvános IP-cím módosításokkal: tervezés, kockázatcsökkentés és BGP-lehetőségek

Egy vállalati adatközpont áthelyezése ritkán egyszerű feladat. A szervezetek számos okból költöztetik az infrastruktúrájukat – például a létesítmények korszerűsítése, a működési költségek csökkentése vagy a környezetek konszolidációja egyesülések után.

Az egyik legösszetettebb kihívás ebben a folyamatban a nyilvános IP-címek változásainak kezelése.

Sok éles rendszer statikus nyilvános IP-címeket használ a tűzfalak engedélyezőlistáihoz, a SaaS hozzáférési szabályzatokhoz, a partnerintegrációkhoz és az API biztonsági szabályaihoz. Ha ezek az IP-címek váratlanul megváltoznak a migráció során, még egy jól megtervezett infrastruktúra-áthelyezés is szolgáltatáskiesést okozhat.

Ez az útmutató ismerteti, hogyan kell kezelni az adatközpontokba történő migrációt nyilvános IP-címek módosításával, beleértve a hálózattervezési lehetőségeket, a BGP-alapú stratégiákat és a hálózati mérnökök által az állásidő minimalizálására használt gyakorlati technikákat.

• 1. rész: Megtartható ugyanaz a nyilvános IP-cím egy adatközpont áthelyezésekor?
• 2. rész: BGP több adatközpontú migráció /32 útvonalinjektálással
• 3. rész: A tűzfal munkamenetének megszakadásának megakadályozása a migráció során
• 4. rész: Korábbi alkalmazások kezelése fixen kódolt IP-címekkel
• 5. rész: Vállalati adatközpont migrációs ellenőrzőlista

1. rész: Megtartható ugyanaz a nyilvános IP-cím egy adatközpont áthelyezésekor?

A tervezés első és legfontosabb kérdése a következő: Megtarthatja-e a szervezet a meglévő nyilvános IP-címeit?

A válasz attól függ, hogy az IP-címtartomány szolgáltatófüggetlen (PI) vagy szolgáltatóhoz rendelt (PA).

Szolgáltatótól független (PI) IP-terület

Ha a szervezete birtokolja a nyilvános IP-blokkot, és autonóm rendszerszámot (ASN) üzemeltet, az IP-címek Önnel együtt áthelyezhetők.

• Ugyanez az IP-előtag bejelenthető az új adatközpontból is.
• A BGP-t az útvonalak upstream szolgáltatókhoz való hirdetésére használják.
• A külső rendszerek továbbra is ugyanazokat a címeket használják.

Ez a megközelítés biztosítja a legnagyobb rugalmasságot a hosszú távú infrastrukturális változásokhoz.

Szolgáltató által kiosztott (PA) IP-terület

Ha a nyilvános IP-címek a jelenlegi internetszolgáltatóhoz tartoznak, akkor általában nem vihetők át új szolgáltatóhoz.

Új létesítménybe vagy internetszolgáltatóhoz való áttéréskor a szervezeteknek általában a következőket kell tenniük:

• Új IP-tartomány beszerzése
• Szerverek és szolgáltatások újraszámozása
• Partneri tűzfalszabályok frissítése
• DNS-rekordok módosítása

Ezekben a környezetekben az adatközponti migráció nyilvános IP-címének módosítása elkerülhetetlen, és gondos tervezésre van szükség.

2. rész: BGP több adatközpontú migráció /32 útvonalinjektálással

Az IP-területüket birtokló szervezetek zökkenőmentes migrációt hajthatnak végre a BGP útvonalspecifitásának használatával.

Példaforgatókönyv: egy vállalat egy /24-es nyilvános alhálózattal rendelkezik.

Egy általános migrációs stratégia a következőképpen működik:

1. Jelentse be a /24 előtagot mind a régi adatközpontban (DC1), mind az új adatközpontban (DC2).
2. Amikor egy szervert áthelyeznek a DC2-be, hirdesse meg a DC2-ből származó /32-es állomásútvonalát.
3. A BGP a legspecifikusabb előtagot részesíti előnyben, így a bejövő forgalom automatikusan DC2-re vált.
4. Ismételje meg a folyamatot szerverről szerverre.
5. Miután a migráció befejeződött, vonja vissza a /24-es bejelentést a DC1-ből.

Mielőtt bejelentenéd az új helyszínről induló útvonalakat, ne felejtsd el frissíteni a felhatalmazó levelet (LOA) az upstream szolgáltatókkal, hogy elfogadják az új BGP hirdetéseket.

3. rész: A tűzfal munkamenetének megszakadásának megakadályozása a migráció során

Az áthelyezés során az egyik leginkább figyelmen kívül hagyott probléma az aszimmetrikus útvonaltervezés.

Ez akkor fordulhat elő, ha a bejövő forgalom egy adatközpont tűzfalán keresztül érkezik, de a visszatérő forgalom egy másikon keresztül távozik.

Mivel a vállalati tűzfalak állapotalapú ellenőrzést használnak, a visszatérési csomag érvénytelen munkamenet-állapot miatt eldobható.

A probléma elkerülése érdekében a mérnököknek szimmetrikus útvonaltervezést kell alkalmazniuk a migráció során.

BGP közösségek használata szimmetrikus útválasztás fenntartására

Egy gyakori megoldás a BGP közösségek kombinálása a helyi preferencia útválasztási szabályzatokkal.

1. Minden adatközpontból induló útvonalakat egyedi BGP közösségek használatával címkézhet.
2. Rendelje hozzá ezeket a közösségeket a helyi preferenciaértékekhez.
3. Győződjön meg arról, hogy a kimenő forgalom ugyanabban az adatközpontban lép ki, ahol a munkamenet elkezdődött.

Ez a módszer a forgalmat a megfelelő tűzfal-munkamenetállapothoz igazítja, és megakadályozza a kapcsolati hibákat.

4. rész: Korábbi alkalmazások kezelése fixen kódolt IP-címekkel

Még megfelelő útválasztási tervezés esetén is a migráció hibát okozhat azokban az alkalmazásokban, amelyek fixen kódolt IP-címekre támaszkodnak a DNS-hosztnevek helyett.

Cél NAT (DNAT)

Ideiglenes megoldásként használhat cél NAT-ot vagy porttovábbítást.

A régi IP-címre küldött forgalom átirányítható az új infrastruktúrára.

Load Balancer Route Health Injection

Egy másik lehetőség egy terheléselosztó elhelyezése a szolgáltatás elé. Egyes terheléselosztók támogatják a Route Health Injectiont (RHI), amely lehetővé teszi, hogy egy virtuális IP aktív maradjon, miközben a háttérszerverek különböző címeket használnak.

DNS csökkentett TTL-lel

Ha az alkalmazások DNS-re támaszkodnak, a rendszergazdáknak jóval a migrációs időszak előtt csökkenteniük kell a DNS TTL-értékeit. Az alacsonyabb TTL-értékek biztosítják, hogy a kliensek gyorsan frissítsék a gyorsítótárazott rekordokat az IP-cím változása után.

5. rész: Vállalati adatközpont migrációs ellenőrzőlista

Egy strukturált migrációs terv jelentősen csökkenti a működési kockázatot.

1. Nyilvános IP-függőségek leltározása

Azonosítsa az összes olyan rendszert, amely fix nyilvános IP-címeket használ, beleértve a partnerintegrációkat, a SaaS hozzáférés-vezérlést és az API biztonsági szabályzatokat.

2. Építsen ki kapcsolatokat az adatközpontok között

Hozzon létre egy ideiglenes adatközpont-összeköttetést (DCI) olyan technológiák használatával, mint az MPLS áramkörök, a sötét szál vagy a VXLAN átfedések.

3. Útválasztási és BGP-szabályzatok előkészítése

Olyan útválasztási szabályzatok meghatározása, amelyek biztosítják a szimmetrikus forgalmi útvonalakat és a megfelelő BGP útvonalhirdetéseket.

4. Csökkentse a DNS és ARP időzítőket

A DNS TTL és ARP gyorsítótár időzítőinek csökkentése segít a gazdagépeknek gyorsan megtanulni az új útvonalakat a migráció során.

5. Fázisos migráció végrehajtása

A szolgáltatásokat fokozatosan helyezze át egyetlen nagy átállás helyett. A folytatás előtt ellenőrizze az egyes fázisokat.

6. Monitoring és leszerelés

Az áttelepítés után figyelje a forgalmi mintákat, erősítse meg az alkalmazások elérhetőségét, és győződjön meg arról, hogy a régi infrastruktúra leszerelése előtt ne legyen folyamatos forgalom a régi adatközpontban.

Megtartható ugyanaz a nyilvános IP-cím egy adatközpont áthelyezésekor?

Igen, de csak akkor, ha a szervezet szolgáltatótól független IP-címhellyel és autonóm rendszerszámmal rendelkezik. Ebben az esetben az IP-előtagot az új adatközpontból BGP segítségével lehet bejelenteni.

Miért szakadnak meg a tűzfal-munkamenetek az adatközpontba való migrálás során?

Aszimmetrikus útválasztás esetén a tűzfal munkamenetei megszakadnak. Ha a forgalom az egyik tűzfalon keresztül érkezik, a másikon pedig kilép, a visszatérő csomag eldobható, mivel a tűzfal nem ismeri fel a munkamenet állapotát.

Mi a legbiztonságosabb stratégia a szerverek adatközpontok közötti migrálására?

A BGP útvonalspecifitását, ideiglenes összekötő kapcsolatokat és gondos monitorozást alkalmazó szakaszos migráció jellemzően a legbiztonságosabb megközelítés vállalati környezetekben.

Vállalati hálózati berendezésekért és infrastruktúra-megoldásokért látogasson el a következő oldalra: Router-switch vagy fedezze fel az árképzési eszközöket a következő címen: IT-árTovábbi hálózati dokumentációért lásd a Cisco hivatalos weboldala.