Azure Traffic Manager az Azure Site Recovery-vel

Az Azure Traffic Managerrel szabályozhatja a forgalom elosztását az alkalmazásvégpontok között. A végpont egy, az Azure-on kívül vagy belül üzemeltetett, internetkapcsolattal rendelkező szolgáltatás.

A Traffic Manager a DNS használatával irányítja az ügyfélkéréseket a legmegfelelőbb végpontra a forgalomirányítási módszer és a végpontok állapota alapján. A Traffic Manager különböző forgalom-útválasztási módszereket és végpont-monitorozási lehetőségeket biztosít, hogy megfeleljen a különböző alkalmazások igényeinek és az automatikus feladatátvételi modelleknek. Az ügyfelek közvetlenül a kiválasztott végponthoz kapcsolódnak. A Traffic Manager nem proxy vagy átjáró, és nem látja az ügyfél és a szolgáltatás közötti forgalmat.

Ez a cikk azt ismerteti, hogyan kombinálhatja az Azure Traffic Monitor intelligens útválasztását az Azure Site Recovery hatékony vészhelyreállítási és migrálási képességeivel.

Helyszíni és Azure-beli feladatátvétel

Az első forgatókönyvben vegye figyelembe az A vállalatot, amely a helyszíni környezetben futó összes alkalmazásinfrastruktúrával rendelkezik. Üzletmenet-folytonossági és megfelelőségi okokból az A vállalat úgy dönt, hogy az Azure Site Recoveryt használja alkalmazásai védelmére.

Az A vállalat nyilvános végpontokkal futtat alkalmazásokat, és szeretné zökkenőmentesen átirányítani a forgalmat az Azure-ba egy katasztrófaeseményben. Az Azure Traffic Manager prioritási forgalom-útválasztási módszere lehetővé teszi az A vállalat számára, hogy egyszerűen implementálja ezt a feladatátvételi mintát.

A beállítás a következő:

• Az A vállalat létrehoz egy Traffic Manager-profilt.
• A prioritási útválasztási módszer használatával az A vállalat két végpontot hoz létre – elsődleges a helyszíni és a feladatátvételt az Azure-hoz. Az elsődleges prioritás az 1. prioritás, a feladatátvétel pedig a 2. prioritás.
• Mivel az elsődleges végpont az Azure-on kívül van üzemeltetve, a végpont külső végpontként jön létre.
• Az Azure Site Recovery esetében az Azure-hely nem rendelkezik a feladatátvétel előtt futó virtuális gépekkel vagy alkalmazásokkal. A feladatátvételi végpont tehát külső végpontként is létrejön.
• Alapértelmezés szerint a felhasználói forgalom a helyszíni alkalmazáshoz lesz irányítva, mert az adott végponthoz a legmagasabb prioritás tartozik. Ha az elsődleges végpont kifogástalan állapotú, a forgalom nem lesz átirányítva az Azure-ba.

Katasztrófaesemény esetén az A vállalat feladatátvételt indíthat el az Azure-ba, és helyreállíthatja az alkalmazásait az Azure-ban. Ha az Azure Traffic Manager azt észleli, hogy az elsődleges végpont már nem kifogástalan, automatikusan a feladatátvételi végpontot használja a DNS-válaszban, és a felhasználók csatlakoznak az Azure-ban helyreállított alkalmazáshoz.

Az üzleti követelményektől függően az A vállalat magasabb vagy alacsonyabb próbaidőt választhat a helyszíni és az Azure közötti váltáshoz egy katasztrófaesemény esetén, és minimális állásidőt biztosíthat a felhasználók számára.

Ha a katasztrófa bekövetkezik, az A vállalat feladat-visszavételt végezhet az Azure-ból a helyszíni környezetbe (VMware vagy Hyper-V) az Azure Site Recovery használatával. Most, amikor a Traffic Manager azt észleli, hogy az elsődleges végpont ismét kifogástalan állapotban van, automatikusan felhasználja az elsődleges végpontot a DNS-válaszokban.

Helyszíni migrálás az Azure-ba

A vészhelyreállítás mellett az Azure Site Recovery az Azure-ba történő migrálást is lehetővé teszi. Az Azure Site Recovery hatékony feladatátvételi képességeinek használatával az ügyfelek anélkül értékelhetik az alkalmazások teljesítményét az Azure-ban, hogy befolyásolnák a helyszíni környezetüket. Ha az ügyfelek készen állnak a migrálásra, dönthetnek úgy, hogy a teljes számítási feladatokat együtt migrálják, vagy úgy döntenek, hogy fokozatosan migrálnak és méreteznek.

Az Azure Traffic Manager súlyozott útválasztási módszere a bejövő forgalom egy részét az Azure-ba irányíthatja, a többség pedig a helyszíni környezetbe irányítható. Ez a megközelítés segíthet felmérni a skálázási teljesítményt, mivel továbbra is növelheti az Azure-hoz rendelt súlyt, miközben egyre több számítási feladatot migrál az Azure-ba.

A B vállalat például úgy dönt, hogy fázisokban migrál, áthelyezi az alkalmazáskörnyezet egy részét, miközben megtartja a többi helyszíni környezetet. A kezdeti szakaszokban, amikor a környezet nagy része helyszíni, a rendszer nagyobb súlyt rendel a helyszíni környezethez. A Traffic Manager egy végpontot ad vissza az elérhető végpontokhoz rendelt súlyok alapján.

A migrálás során mindkét végpont aktív, és a forgalom nagy része a helyszíni környezetbe irányul. A migrálás során nagyobb súly rendelhető hozzá a végponthoz az Azure-ban, és végül a helyszíni végpont inaktiválható a migrálás után.

Azure–Azure feladatátvétel

Ebben a példában vegye figyelembe a C vállalatot, amely az azure-t futtató összes alkalmazásinfrastruktúrával rendelkezik. Üzletmenet-folytonossági és megfelelőségi okokból a C vállalat úgy dönt, hogy az Azure Site Recoveryt használja alkalmazásai védelmére.

A C vállalat nyilvános végpontokkal futtat alkalmazásokat, és szeretné zökkenőmentesen átirányítani a forgalmat egy másik Azure-régióba egy katasztrófaeseményben. A prioritásos forgalom-útválasztási módszer lehetővé teszi , hogy a C vállalat egyszerűen implementálja ezt a feladatátvételi mintát.

A beállítás a következő:

• A C vállalat létrehoz egy Traffic Manager-profilt.
• A prioritási útválasztási módszer használatával a C vállalat két végpontot hoz létre – elsődlegest a forrásrégióhoz (Azure Kelet-Ázsia) és feladatátvételt a helyreállítási régióhoz (Azure Délkelet-Ázsia). Az elsődleges prioritás az 1. prioritás, a feladatátvétel pedig a 2. prioritás.
• Mivel az elsődleges végpont az Azure-ban van üzemeltetve, a végpont azure-végpontként is lehet.
• Az Azure Site Recovery esetében a helyreállítási Azure-hely nem rendelkezik a feladatátvétel előtt futó virtuális gépekkel vagy alkalmazásokkal. Így a feladatátvételi végpont külső végpontként is létrehozható.
• Alapértelmezés szerint a rendszer a felhasználói forgalmat a forrásrégió (Kelet-Ázsia) alkalmazásba irányítja, mivel a végponthoz a legmagasabb prioritás tartozik. Ha az elsődleges végpont kifogástalan állapotú, a forgalom nem lesz átirányítva a helyreállítási régióba.

Katasztrófaesemény esetén a C vállalat feladatátvételt indíthat el, és helyreállíthatja az alkalmazásait a helyreállítási Azure-régióban. Amikor az Azure Traffic Manager azt észleli, hogy az elsődleges végpont már nem kifogástalan, automatikusan használja a feladatátvételi végpontot a DNS-válaszban, és a felhasználók csatlakoznak a helyreállítási Azure-régióban (Délkelet-Ázsia) helyreállított alkalmazáshoz.

Az üzleti követelményektől függően a C vállalat magasabb vagy alacsonyabb próbaidőt választhat a forrás- és helyreállítási régiók közötti váltáshoz, és minimális állásidőt biztosíthat a felhasználók számára.

Ha a katasztrófa el van rejtve, a C vállalat feladat-visszavételt végezhet a helyreállítási Azure-régióból a forrás Azure-régióba az Azure Site Recovery használatával. Most, amikor a Traffic Manager azt észleli, hogy az elsődleges végpont ismét kifogástalan állapotban van, automatikusan felhasználja az elsődleges végpontot a DNS-válaszokban.

Többrégiós vállalati alkalmazások védelme

A globális vállalatok gyakran javítják az ügyfélélményt azáltal, hogy alkalmazásaikat a regionális igényeknek megfelelően alakítják ki. A honosítás és a késés csökkentése az alkalmazásinfrastruktúra régiók közötti felosztásához vezethet. A vállalatokra bizonyos területeken regionális adattörvények is vonatkoznak, és úgy döntenek, hogy alkalmazás-infrastruktúrájuk egy részét regionális határokon belül elkülönítik.

Vegyünk egy példát, ahol a D vállalat megosztotta az alkalmazásvégpontokat, hogy külön szolgálja Németországot és a világ többi részét. A D vállalat az Azure Traffic Manager földrajzi útválasztási módszerét használja a beállításhoz. A Németországból származó forgalom az 1. végpontra irányul, és a Németországon kívülről érkező forgalom a 2. végpontra lesz irányítva.

A beállítással az a probléma, hogy ha az 1. végpont bármilyen okból leáll, a forgalom nem lesz átirányítva a 2. végpontra. A Németországból származó forgalom továbbra is az 1. végpontra irányítja a végpont állapotától függetlenül, így a német felhasználók nem férhetnek hozzá a D vállalat alkalmazásához. Hasonlóképpen, ha a 2. végpont offline állapotba kerül, a forgalom nem lesz átirányítva az 1. végpontra.

A probléma elkerülése és az alkalmazások rugalmasságának biztosítása érdekében a D vállalat beágyazott Traffic Manager-profilokat használ az Azure Site Recoveryvel. Beágyazott profilok beállításakor a forgalom nem az egyes végpontokra, hanem más Traffic Manager-profilokra lesz irányítva. A beállítás működése a következőképpen működik:

• A földrajzi útválasztás egyéni végpontokkal való használata helyett a D vállalat a Traffic Manager-profilokkal rendelkező földrajzi útválasztást használja.
• Minden gyermek Traffic Manager-profil elsődleges és helyreállítási végponttal használja a prioritási útválasztást, így a prioritási útválasztás a földrajzi útválasztáson belül van beágyazva.
• Az alkalmazás rugalmasságának engedélyezéséhez minden számítási feladat-disztribúció az Azure Site Recoveryt használja a helyreállítási régióba való feladatátvételhez katasztrófaesemények esetén.
• Amikor a szülő Traffic Manager kap egy DNS-lekérdezést, a rendszer átirányítja azt a gyermek Traffic Managerhez, amely egy elérhető végponttal válaszol a lekérdezésre.

Ha például a közép-németországi végpont meghibásodik, az alkalmazás gyorsan helyreállítható Északkelet-Németországba. Az új végpont minimális állásidővel kezeli a Németországból származó forgalmat. Hasonlóképpen a nyugat-európai végpontkimaradások is kezelhetők az alkalmazás számítási feladatainak Észak-Európába való helyreállításával, és az Azure Traffic Manager dns-átirányításokat kezel az elérhető végpontra.

A fenti beállítás kibontható úgy, hogy annyi régió- és végpontkombinációt tartalmazzon, amennyi szükséges. A Traffic Manager legfeljebb 10 szintű beágyazott profilt tesz lehetővé, és nem engedélyezi a hurkokat a beágyazott konfigurációban.

Helyreállítási idő célkitűzésének (RTO) szempontjai

A legtöbb szervezetben a DNS-rekordok hozzáadását vagy módosítását egy külön csapat vagy a szervezeten kívüli személy kezeli. Ez nagy kihívást jelent a DNS-rekordok módosítása során. A DNS-rekordok más csapatok vagy dns-infrastruktúrát kezelő szervezetek általi frissítéséhez szükséges idő szervezetenként eltérő, és hatással van az alkalmazás RTO-jára.

A Traffic Manager használatával előre betöltheti a DNS-frissítésekhez szükséges munkát. A tényleges feladatátvételkor nincs szükség manuális vagy szkriptelt műveletre. Ez a megközelítés segít a gyors váltásban (és ezáltal az RTO csökkentésében), valamint a vészesemények költséges, időigényes DNS-változási hibáinak elkerülésében. A Traffic Managerrel még a feladat-visszavételi lépés is automatizált, amelyet egyébként külön kell kezelni.

A megfelelő próbaidő beállítása alapszintű vagy gyors időközi állapotellenőrzéssel jelentősen csökkentheti az RTO-t a feladatátvétel során, és csökkentheti a felhasználók állásidejét.

Emellett optimalizálhatja a DNS Élettartam (TTL) értékét a Traffic Manager-profilhoz. A TTL az az érték, amelynek dns-bejegyzését egy ügyfél gyorsítótárazza. Rekord esetén a DNS-t nem kérdezi le kétszer a TTL tartományán belül. Minden DNS-rekordhoz egy TTL van társítva. Ennek az értéknek a csökkentése több DNS-lekérdezést eredményez a Traffic Manager számára, de a kimaradások gyorsabb felderítésével csökkentheti az RTO-t.

Az ügyfél által tapasztalt TTL nem nő, ha az ügyfél és a mérvadó DNS-kiszolgáló közötti DNS-feloldók száma nő. A DNS-feloldók leszámolják a TTL-t, és csak olyan TTL-értéket adnak át, amely a rekord gyorsítótárazása óta eltelt időt tükrözi. Ez biztosítja, hogy a DNS-rekord a TTL után frissüljön az ügyfélnél, függetlenül a lánc DNS-feloldóinak számától.

Következő lépések

• További információ a Traffic Manager útválasztási módszereiről.
• További információ a beágyazott Traffic Manager-profilokról.
• További információ a végpontfigyelésről.
• További információ az alkalmazás feladatátvételét automatizáló helyreállítási tervekről.