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 tartománynévrendszer (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 Recovery 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ású forgalom-útválasztási módszere lehetővé teszi az A vállalat számára, hogy könnyen 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ást, a feladatátvétel pedig a 2. prioritást kapja.
• 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 rendszer a felhasználói forgalmat a helyszíni alkalmazáshoz irányítja, mert az adott végponthoz a legmagasabb prioritás van társítva. Ha az elsődleges végpont kifogástalan állapotú, a forgalom nem lesz átirányítva az Azure-ba.

Vészesemény esetén az A vállalat feladatátvételt indíthat 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 állapotú, automatikusan a DNS-válasz feladatátvételi végpontot használja, é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 választhat egy magasabb vagy alacsonyabb mintavételi gyakoriságot a helyszíni és az Azure közötti váltáshoz vészhelyzet esetén, és minimális állásidőt biztosíthat a felhasználók számára.

A katasztrófa esetén 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 állapotú, 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 tesztfunkcióinak használatával az ügyfelek anélkül értékelhetik az alkalmazás teljesítményét az Azure-ban, hogy befolyásolnák a helyszíni környezetüket. Amikor 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 a migrálást és a skálázást fokozatosan választják.

Az Azure Traffic Manager súlyozott útválasztási módszere a bejövő forgalom egy részének az Azure-ba való irányítására használható, miközben a legtöbbet a helyszíni környezetbe irányítja. 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, az alkalmazáskörnyezet egy részét áthelyezi, 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 folytatásával 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-ból Azure-ba történő feladatátvétel

Ebben a példában vegye figyelembe a C vállalatot , amely az összes Azure-t futtató 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 Recovery használatával védi az alkalmazásokat.

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 a C vállalat számára, hogy könnyen 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ás útválasztási módszerét használva a C vállalat két végpontot hoz létre : elsődleges 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ást, a feladatátvétel pedig a 2. prioritást kapja.
• Mivel az elsődleges végpont az Azure-ban található, a végpont lehet Azure-végpont .
• 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. A feladatátvételi végpont tehát külső végpontként hozható létre.
• A felhasználói forgalom alapértelmezés szerint a forrásrégióba (Kelet-Ázsia) irányul, 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állalatfeladatátvételt indíthat el, és helyreállíthatja az alkalmazásait a helyreállítási Azure-régióban. Ha az Azure Traffic Manager azt észleli, hogy az elsődleges végpont már nem kifogástalan állapotú, automatikusan a DNS-válasz feladatátvételi végpontját használja, és a felhasználók a helyreállítási Azure-régióban (Délkelet-Ázsia) helyreállított alkalmazáshoz csatlakoznak.

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 bekövetkezik, 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 állapotú, 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 testre szabják. A honosítás és a késés csökkentése az alkalmazás-infrastruktú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, amikor a D vállalat felosztotta 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 , a Németországon kívülről érkező forgalom pedig a 2. végpontra lesz irányítva.

A beállítással az a probléma, hogy ha az 1. végpont valamilyen okból nem működik, 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érnek 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ás rugalmasságának biztosítása érdekében a D vállalatbeágyazott Traffic Manager-profilokat használ az Azure Site Recovery. Beágyazott profilok beállításakor a forgalom nem az egyes végpontokra, hanem más Traffic Manager-profilokra irányul. A beállítás működése a következőképpen működik:

• Ahelyett, hogy a földrajzi útválasztást egyes végpontokkal használná, a D vállalat a Traffic Manager-profilokkal rendelkező földrajzi útválasztást használja.
• Minden gyermek Traffic Manager-profil prioritási útválasztást használ egy elsődleges és egy helyreállítási végponttal, így a prioritási útválasztást a földrajzi útválasztásba ágyazva.
• Az alkalmazás rugalmasságának engedélyezéséhez minden számítási feladatelosztás az Azure Site Recovery használja a vészesemények alapján egy helyreállítási régióba történő feladatátvételhez.
• Amikor a szülő Traffic Manager kap egy DNS-lekérdezést, a rendszer a megfelelő gyermek Traffic Managerhez irányítja, amely egy elérhető végponttal válaszol a lekérdezésre.

Ha például a végpont Németország középső régiójában meghiúsul, 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 a felhasználók számára. Hasonlóképpen, a végpontkimaradások Nyugat-Európában is kezelhetők az alkalmazás számítási feladatainak észak-európai helyre történő helyreállításával, az Azure Traffic Manager pedig dns-átirányításokat kezel az elérhető végpontra.

A fenti beállítás kibontható úgy, hogy a szükséges számú régió- és végpontkombinációt tartalmazza. 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 nagyon megnehezíti a DNS-rekordok módosítását. A DNS-rekordokat más, DNS-infrastruktúrát kezelő csapatok vagy szervezetek dns-rekordjainak frissítéséhez szükséges idő szervezetenként változik, é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étel időpontjában 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.

Ha a megfelelő próbaidőt alapszintű vagy gyors időközön keresztül állítja be, az 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ányon belül. Minden DNS-rekordhoz hozzá van rendelve egy TTL. 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 akkor sem nő, ha az ügyfél és a mérvadó DNS-kiszolgáló között megnő a DNS-feloldók száma. A DNS-feloldók "visszaszámlálják" a TTL-t, és csak olyan TTL-értéket ad át, amely a rekord gyorsítótárazása óta eltelt időt tükrözi. Ez biztosítja, hogy a DNS-rekord frissüljön az ügyfélnél a TTL után, 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ének automatizálására vonatkozó helyreállítási tervekről .