Megosztás a következőn keresztül:

Megbízhatóság a Load Balancerben

  • Cikk

Ez a cikk részletes információkat tartalmaz a Load Balancer regionális rugalmasságáról rendelkezésre állási zónákkal, valamint régiók közötti vészhelyreállítással és üzletmenet-folytonossággal.

Rendelkezésre állási zóna támogatása

Az Azure rendelkezésre állási zónái legalább három fizikailag különálló adatközpont-csoport az egyes Azure-régiókban. Az egyes zónákban lévő adatközpontok független energiaellátási, hűtési és hálózati infrastruktúrával rendelkeznek. Helyi zónahiba esetén a rendelkezésre állási zónák úgy vannak kialakítva, hogy az egy zóna érintettsége esetén a fennmaradó két zóna támogassa a regionális szolgáltatásokat, a kapacitást és a magas rendelkezésre állást.

A hibák a szoftver- és hardverhibáktól az olyan eseményekig terjedhetnek, mint a földrengések, árvizek és tűzesetek. A hibáktól való tolerancia az Azure-szolgáltatások redundanciával és logikai elkülönítésével érhető el. Az Azure-beli rendelkezésre állási zónákkal kapcsolatos részletesebb információkért tekintse meg a Régiók és a rendelkezésre állási zónák című témakört.

Az Azure rendelkezésre állási zónákkal kompatibilis szolgáltatások a megfelelő megbízhatósági és rugalmassági szintet biztosítják. Ezek kétféleképpen konfigurálhatók. Ezek lehetnek zónaredundánsak, a zónák közötti automatikus replikációval vagy a zónák közötti automatikus replikációval, egy adott zónába rögzített példányokkal. Ezeket a megközelítéseket kombinálhatja is. A zónaredundáns és a zónaredundáns architektúráról további információt a rendelkezésre állási zónák és régiók használatára vonatkozó javaslatok című témakörben talál.

Az Azure Load Balancer támogatja a rendelkezésre állási zónák forgatókönyveit. A Standard Load Balancerrel a teljes forgatókönyvben növelheti a rendelkezésre állást az erőforrások zónák közötti igazításával és elosztásával. Tekintse át ezt a dokumentumot, és ismerje meg ezeket a fogalmakat és az alapvető forgatókönyv-tervezési útmutatókat.

Bár ajánlott zónaredundanciával üzembe helyezni a Load Balancert, a Load Balancer lehet zónaredundáns, zónaredundáns vagy nem zónaredundáns. A terheléselosztó rendelkezésre állási zónájának kiválasztása megegyezik az előtérbeli IP-cím zónakijelölésével. A nyilvános terheléselosztók esetében, ha a terheléselosztó előtérének nyilvános IP-címe zónaredundáns, akkor a terheléselosztó zónaredundáns is. Ha a terheléselosztó előtérének nyilvános IP-címe zonális, akkor a terheléselosztó is ugyanahhoz a zónához lesz kijelölve. A terheléselosztó zónafüggő tulajdonságainak konfigurálásához válassza ki a szükséges előtértípust.

Feljegyzés

Nem szükséges minden zónához terheléselosztóval rendelkeznie, hanem egyetlen terheléselosztóval, amely több előtérrel (zónaredundáns vagy zónaredundáns) van társítva a megfelelő háttérkészletekhez.

Előfeltételek

  • Ha rendelkezésre állási zónákat szeretne használni a Load Balancerrel, létre kell hoznia a terheléselosztót egy olyan régióban, amely támogatja a rendelkezésre állási zónákat. Annak megtekintéséhez, hogy mely régiók támogatják a rendelkezésre állási zónákat, tekintse meg a támogatott régiók listáját.

  • A rendelkezésre állási zónák támogatásához használja a standard termékváltozatot a terheléselosztóhoz és a nyilvános IP-címhez.

  • Az alapszintű termékváltozat típusa nem támogatott.

  • Az erőforrás létrehozásához hálózati közreműködői szerepkörre van szükség vagy magasabb szintűre.

Korlátozások

  • A zónák nem módosíthatók, nem frissíthetők és nem hozhatók létre az erőforráshoz a létrehozás után.
  • Az erőforrások nem frissíthetők zonálisról zónaredundánsra, vagy fordítva a létrehozás után.

Zónaredundáns terheléselosztó

A rendelkezésre állási zónákkal rendelkező régiókban a Standard Load Balancer zónaredundáns lehet egyetlen IP-cím által kiszolgált forgalommal. Egyetlen előtérbeli IP-cím túléli a zónahibát. Az előtérbeli IP-cím használható az összes (nem érintett) háttérkészlet-tag elérésére, a zónától függetlenül. Legfeljebb egy rendelkezésre állási zóna hiúsulhat meg, és az adatútvonal megmarad, amíg a régióban lévő fennmaradó zónák kifogástalan állapotban maradnak.

Az előtér IP-címét egyszerre több független infrastruktúra-üzembe helyezés szolgálja ki több rendelkezésre állási zónában. Az újrapróbálkozások vagy újrapróbálkozások a zónahiba által nem érintett más zónákban is sikeresek lesznek.

Az ábra egy zónaredundáns standard terheléselosztót ábrázol, amely három különböző zónában irányítja a forgalmat egy zónaredundáns konfiguráció három különböző alhálózatára.

Feljegyzés

Az 1., 2. és 3. virtuális gépek ugyanahhoz az alhálózathoz tartozhatnak, és nem feltétlenül kell külön zónákban lenniük, mint a diagram javaslatai.

A terheléselosztó háttérkészletének tagjai általában egyetlen zónához, például zonális virtuális gépekhez vannak társítva. Az éles számítási feladatokhoz gyakran több zonális erőforrás szükséges. Például az 1., 2. és 3. zónából származó virtuális gépek zónaredundáns előtérrel rendelkező terheléselosztó háttérrendszerében való elhelyezése megfelel ennek a tervezési elvnek.

Zonal load balancer

Dönthet úgy, hogy az előtér garantáltan egyetlen zónára van garantálva, amelyet zonálisnak neveznek. Ebben a forgatókönyvben egy régió egyetlen zónája az összes bejövő vagy kimenő folyamatot kiszolgálja. A frontend osztja a sorsot a zóna egészségével. Az adatelérési utat nem érintik a nem a garantált zónákban fellépő hibák. A zonális előtérrendszerekkel közzétehet egy IP-címet rendelkezésre állási zónánként.

Emellett az egyes zónákon belüli terheléselosztásos végpontokhoz közvetlenül használható zonális előtér is támogatott. Ezzel a konfigurációval zónánkénti terheléselosztású végpontokat tehet elérhetővé az egyes zónák egyenkénti monitorozásához. Nyilvános végpontok esetén integrálhatja őket egy DNS-terheléselosztási termékkel, például a Traffic Managerrel , és egyetlen DNS-nevet használhat.

Az ábra három zonális standard terheléselosztót ábrázol, mindegyik egy zónában három különböző alhálózatra irányítja a forgalmat egy zonális konfigurációban.

Nyilvános terheléselosztó előtér esetében zónaparamétert kell hozzáadnia a nyilvános IP-címhez. Erre a nyilvános IP-címre a vonatkozó szabály által használt előtérbeli IP-konfiguráció hivatkozik.

Belső terheléselosztó előtér esetén adjon hozzá egy zónaparamétert a belső terheléselosztó előtérbeli IP-konfigurációjába. A zonális előtér garantálja az alhálózatban lévő IP-címet egy adott zónára.

Nem zonális terheléselosztó

A Terheléselosztók nem zóna típusú előtér használatával is létrehozható nem zónaalapú konfigurációban. Ezekben az esetekben a nyilvános terheléselosztó nyilvános IP-címet vagy nyilvános IP-előtagot használna, a belső terheléselosztó pedig privát IP-címet használna. Ez a beállítás nem garantálja a redundanciát.

Feljegyzés

Az alapszintű termékváltozatról standard termékváltozatra frissített összes nyilvános IP-cím "no-zone" típusú lesz. Megtudhatja, hogyan frissíthet nyilvános IP-címeket az Azure Portalon.

SLA-fejlesztések

Mivel a rendelkezésre állási zónák fizikailag különállóak, és eltérő áramforrást, hálózatot és hűtést biztosítanak, az SLA-k (szolgáltatásiszint-szerződések) növekedhetnek. További információt az online szolgáltatások szolgáltatásiszint-szerződéseit (SLA) ismertető cikkben talál.

Erőforrás létrehozása engedélyezett rendelkezésre állási zónával

Ha szeretné megtudni, hogyan lehet terheléselosztani a virtuális gépeket egy zónán vagy több zónán belül egy Load Balancerrel, tekintse meg a virtuális gépek terheléselosztásához használható nyilvános terheléselosztó létrehozását ismertető rövid útmutatót.

Feljegyzés

  • A zónák nem módosíthatók, nem frissíthetők és nem hozhatók létre az erőforráshoz a létrehozás után.
  • Az erőforrások nem frissíthetők zonálisról zónaredundánsra, vagy fordítva a létrehozás után.

Hibatűrés

A virtuális gépek feladatátvételt végezhetnek egy fürt egy másik kiszolgálóján, és a virtuális gép operációs rendszere újraindul az új kiszolgálón. Tekintse meg a vészhelyreállítás feladatátvételi folyamatát, gyűjtse össze a virtuális gépeket a helyreállítási tervezés során, és futtasson vészhelyreállítási próbákat a hibatűrési megoldás sikerességének biztosítása érdekében.

További információkért tekintse meg a site recovery folyamatait.

Zónaleállási élmény

A zónaredundancia nem jelenti a találat nélküli adatsíkot vagy vezérlősíkot. A zónaredundáns folyamatok bármilyen zónát használhatnak, és a folyamatok egy régió összes kifogástalan zónáját használják. Zónahiba esetén a forgalom nem befolyásolja az kifogástalan állapotú zónákat használó forgalmat.

A zónahiba idején zónát használó forgalomfolyamatokat érinthet, de az alkalmazások helyreállhatnak. A forgalom a régió kifogástalan állapotú zónáiban folytatódik az újraküldéskor, amikor az Azure konvergensen halad a zónahiba körül.

Tekintse át az Azure felhőtervezési mintáit az alkalmazás meghibásodási forgatókönyvekkel szembeni rugalmasságának javítása érdekében.

Több előtérrendszer

Több előtér használata lehetővé teszi a forgalom terheléselosztását több porton és/vagy IP-címen. Az architektúra tervezésekor győződjön meg arról, hogy a zónaredundancia hogyan működik együtt több előtérrel. Ha a cél az, hogy mindig minden frontend ellenálljon a hibáknak, akkor minden előtérként hozzárendelt IP-címnek zónaredundánsnak kell lennie. Ha egy előtérkészletet egyetlen zónához kívánnak társítani, akkor az adott csoport minden IP-címét hozzá kell társítani az adott zónához. Nincs szükség terheléselosztóra az egyes zónákban. Ehelyett minden egyes zonális előtér vagy zonális előtércsoport társítható a háttérkészlet azon virtuális gépeivel, amelyek az adott rendelkezésre állási zónához tartoznak.

Biztonságos üzembe helyezési technikák

Tekintse át az Azure felhőtervezési mintáit az alkalmazás meghibásodási forgatókönyvekkel szembeni rugalmasságának javítása érdekében.

Migrálás a rendelkezésre állási zónák támogatására

Abban az esetben, ha egy régiót kibővítenek rendelkezésre állási zónákkal, a meglévő IP-címek nem zonálisak maradnak, mint a terheléselosztó előtérrendszereihez használt IP-címek. Annak érdekében, hogy az architektúra kihasználhassa az új zónákat, javasoljuk, hogy hozzon létre egy új előtérbeli IP-címet. A létrehozás után lecserélheti a meglévő nem zónaredundáns előtérrendszert egy új zónaredundáns előtérre. Ha tudni szeretné, hogyan migrálhat egy virtuális gépet a rendelkezésre állási zónák támogatásához, olvassa el a Load Balancer áttelepítése a rendelkezésre állási zónák támogatásához című témakört.

Régiók közötti vészhelyreállítás és üzletmenet-folytonosság

A vészhelyreállítás (DR) a nagy hatású események, például a természeti katasztrófák vagy az állásidőt és adatvesztést eredményező sikertelen üzemelő példányok helyreállításáról szól. A katasztrófa okától függetlenül a legjobb megoldás egy jól definiált és tesztelt DR-terv, valamint egy olyan alkalmazásterv, amely aktívan támogatja a DR-t. Mielőtt elkezdene gondolkodni a vészhelyreállítási terv létrehozásáról, tekintse meg a vészhelyreállítási stratégia tervezésére vonatkozó javaslatokat.

A DR-ről a Microsoft a megosztott felelősségi modellt használja. Egy megosztott felelősségi modellben a Microsoft biztosítja, hogy az alapinfrastruktúra és a platformszolgáltatások elérhetők legyenek. Ugyanakkor számos Azure-szolgáltatás nem replikálja automatikusan az adatokat, vagy egy meghibásodott régióból visszaesik egy másik engedélyezett régióba történő keresztreplikáláshoz. Ezekért a szolgáltatásokért Ön felel a számítási feladathoz használható vészhelyreállítási terv beállításáért. Az Azure-platformon szolgáltatásként (PaaS) futó szolgáltatások többsége funkciókkal és útmutatással támogatja a DR-t, és szolgáltatásspecifikus funkciókkal támogatja a gyors helyreállítást a dr. csomag fejlesztéséhez.

Az Azure Standard Load Balancer támogatja a régiók közötti terheléselosztást, lehetővé téve a georedundáns magas rendelkezésre állású forgatókönyveket, például:

A régiók közötti terheléselosztó előtérbeli IP-konfigurációja statikus, és a legtöbb Azure-régióban meghirdetve van.

Régiók közötti terheléselosztó diagramja.

Feljegyzés

A régiók közötti terheléselosztón a terheléselosztási szabály háttérportjának meg kell egyeznie a terheléselosztási szabály előtérportjának/bejövő nat-szabályának a regionális standard terheléselosztón.

Vészhelyreállítás többrégiós földrajzi területen

Regionális redundancia

A regionális redundancia konfigurálásához zökkenőmentesen csatolhat régiók közötti terheléselosztót a meglévő regionális terheléselosztókhoz.

Ha egy régió meghibásodik, a forgalom a következő legközelebbi egészséges regionális terheléselosztóhoz lesz irányítva.

A régiók közötti terheléselosztó állapotadat-mintavétele 5 másodpercenként gyűjt információkat az egyes regionális terheléselosztók rendelkezésre állásáról. Ha egy regionális terheléselosztó a rendelkezésre állását 0-ra csökkenti, a régióközi terheléselosztó észleli a hibát. A regionális terheléselosztót ezután a forgásból veszik ki.

Globális régió forgalmi nézetének diagramja.

Rendkívül alacsony késés

A földrajzi közelség terheléselosztási algoritmusa a felhasználók földrajzi helyén és a regionális üzemelő példányokon alapul.

Az ügyfélről indított forgalom eléri a legközelebbi részt vevő régiót, és a Microsoft globális hálózati gerinchálózatán haladva éri el a legközelebbi regionális üzembe helyezést.

Például rendelkezik egy régiók közötti terheléselosztóval, amely standard terheléselosztókkal rendelkezik az Azure-régiókban:

  • USA nyugati régiója
  • Észak-Európa

Ha egy folyamat Seattle-ből indul, a forgalom az USA nyugati régiójába kerül. Ez a régió Seattle legközelebbi résztvevő régiója. A forgalom a legközelebbi régió terheléselosztójához van irányítva, amely az USA nyugati régiója.

Az Azure régiók közötti terheléselosztója geo-közelségi terheléselosztási algoritmust használ az útválasztási döntéshez.

A regionális terheléselosztók konfigurált terheléselosztási módja a végső útválasztási döntés meghozatalára szolgál, ha több regionális terheléselosztót használnak a földrajzi közelséghez.

További információ: Az Azure Load Balancer terjesztési módjának konfigurálása.

A kimenő forgalom a regionális terheléselosztókon beállított útválasztási beállításokat követi.

Vertikális fel- és leskálázás egyetlen végpont mögött

Ha egy régióközi terheléselosztó globális végpontját teszi elérhetővé az ügyfelek számára, megszakítás nélkül hozzáadhat vagy eltávolíthat regionális üzembe helyezéseket a globális végpont mögött.

Statikus bármely küldési globális IP-cím

A régiók közötti terheléselosztó statikus nyilvános IP-címmel rendelkezik, amely biztosítja, hogy az IP-cím változatlan maradjon. A statikus IP-címről további információt itt talál

Ügyfél IP-címének megőrzése

A régiók közötti terheléselosztó egy 4. rétegbeli átmenő hálózati terheléselosztó. Ez a továbbítás megőrzi a csomag eredeti IP-címét. Az eredeti IP-cím elérhető a virtuális gépen futó kód számára. Ez a megőrzés lehetővé teszi az IP-címekre jellemző logika alkalmazását.

Nem fix IP-cím

A lebegő IP-cím globális és regionális IP-szinten is konfigurálható. További információkért látogasson el az Azure Load Balancer több előtérbeli felületére

Fontos megjegyezni, hogy az Azure régióközi Load Balancerben konfigurált lebegő IP-cím a háttérbeli regionális terheléselosztók lebegő IP-konfigurációitól függetlenül működik. Ha a régióközi terheléselosztón engedélyezve van a lebegő IP-cím, a megfelelő visszacsatolási felületet hozzá kell adni a háttérbeli virtuális gépekhez.

Állapottesztek

Az Azure régiók közötti Load Balancer a háttérbeli regionális terheléselosztók állapotát használja ki, amikor eldönti, hogy hová szeretné terjeszteni a forgalmat. A régiók közötti terheléselosztó állapot-ellenőrzése 5 másodpercenként automatikusan megtörténik, mivel a felhasználó állapotteszteket állított be a regionális terheléselosztón.

Régiók közötti megoldás létrehozása a meglévő Azure Load Balancerre

A régiók közötti terheléselosztó háttérkészlete egy vagy több regionális terheléselosztót tartalmaz.

Adja hozzá meglévő terheléselosztó-üzemelő példányait egy régiók közötti terheléselosztóhoz egy magas rendelkezésre állású, régiók közötti üzembe helyezéshez.

Az otthoni régióban a globális réteg régióközi terheléselosztója vagy nyilvános IP-címe van üzembe helyezve. Ez a régió nem befolyásolja a forgalom irányítását. Ha egy otthoni régió leáll, a forgalom nem változik.

Otthoni régiók

  • Az USA középső régiója
  • Kelet-Ázsia
  • USA 2. keleti régiója
  • Észak-Európa
  • Délkelet-Ázsia
  • Az Egyesült Királyság déli régiója
  • USA-beli államigazgatás – Virginia
  • Nyugat-Európa
  • USA nyugati régiója

Feljegyzés

A régióközi terheléselosztót vagy a nyilvános IP-címet csak a felsorolt otthoni régiók egyikében helyezheti üzembe globális szinten.

A résztvevő régióban hirdetik meg a terheléselosztó globális nyilvános IP-címét.

A felhasználó által indított forgalom a legközelebbi részt vevő régióba utazik a Microsoft maghálózatán keresztül.

A régiók közötti terheléselosztó a forgalmat a megfelelő regionális terheléselosztóhoz irányítja.

Több régió globális forgalmának diagramja.

Résztvevő régiók

  • Kelet-Ausztrália
  • Délkelet-Ausztrália
  • Közép-India
  • Az USA középső régiója
  • Kelet-Ázsia
  • USA keleti régiója
  • USA 2. keleti régiója
  • Kelet-Japán
  • USA északi középső régiója
  • Észak-Európa
  • USA déli középső régiója
  • Délkelet-Ázsia
  • Az Egyesült Királyság déli régiója
  • US DoD – középső régió
  • US DoD – keleti régió
  • USA-beli államigazgatás – Arizona
  • USA-beli államigazgatás – Texas
  • USA-beli államigazgatás – Virginia
  • USA nyugati középső régiója
  • Nyugat-Európa
  • USA nyugati régiója
  • USA 2. nyugati régiója

Feljegyzés

A háttérbeli regionális terheléselosztók bármely nyilvánosan elérhető Azure-régióban üzembe helyezhetők, és nem csak a részt vevő régiókra korlátozódnak.

Korlátozások

  • A régiók közötti előtérbeli IP-konfigurációk csak nyilvánosak. A belső előtér jelenleg nem támogatott.

  • A privát vagy belső terheléselosztó nem adható hozzá a régiók közötti terheléselosztó háttérkészletéhez

  • A NAT64 fordítás jelenleg nem támogatott. Az előtérbeli és a háttérbeli IP-címnek azonos típusúnak kell lennie (v4 vagy v6).

  • Az UDP-forgalom nem támogatott az IPv6 régióközi Terheléselosztóján.

  • A 3. port UDP-forgalma nem támogatott a régiók közötti terheléselosztón

  • A kimenő szabályok nem támogatottak a régiók közötti Load Balancerben. Kimenő kapcsolatok esetén használja a kimenő szabályokat a regionális terheléselosztón vagy a NAT-átjárón.

Díjszabás és SLA

A régiók közötti terheléselosztó a standard terheléselosztó SLA-jával rendelkezik.

Következő lépések