Megbízhatóság a Load Balancerben

Ez a cikk konkrét megbízhatósági javaslatokat tartalmaz a Load Balancerhez, valamint 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.

Az Azure megbízhatóságának architekturális áttekintéséért tekintse meg az Azure megbízhatóságát.

Megbízhatósági javaslatok

Ez a szakasz a rugalmasság és a rendelkezésre állás elérésére vonatkozó javaslatokat tartalmaz. Minden javaslat két kategória egyikébe tartozik:

• Az állapotelemek olyan területeket fednek le, mint a konfigurációelemek és az Azure-számítási feladatokat alkotó fő összetevők megfelelő működése, például az Azure-erőforrások konfigurációs beállításai, a más szolgáltatásoktól való függőségek stb.

• A kockázati elemek olyan területeket fednek le, mint a rendelkezésre állási és helyreállítási követelmények, a tesztelés, a monitorozás, az üzembe helyezés és egyéb olyan elemek, amelyek megoldatlan állapotban maradva növelik a környezeti problémák esélyét.

Megbízhatósági javaslatok prioritási mátrixa

Minden javaslat a következő prioritási mátrixnak megfelelően van megjelölve:

Kép	Prioritás	Leírás
	Magas	Azonnali javításra van szükség.
	Közepes	Javítás 3-6 hónapon belül.
	Alacsony	Felül kell vizsgálni.

Megbízhatósági javaslatok összefoglalása

Kategória	Prioritás	Ajánlás
Elérhetőség		Győződjön meg arról, hogy a Standard Load Balancer zónaredundáns
		Győződjön meg arról, hogy a háttérkészlet legalább két példányt tartalmaz
Rendszerhatékonyság		Nat Gateway használata kimenő szabályok helyett éles számítási feladatokhoz
		Standard Load Balancer termékváltozat használata

Elérhetőség

Győződjön meg arról, hogy a Standard Load Balancer zónaredundáns

A rendelkezésre állási zónákat támogató régióban a Standard Load Balancert zónaredundanciával kell üzembe helyezni. A zónaredundáns Load Balancer lehetővé teszi, hogy a forgalmat egyetlen előtérbeli IP-cím szolgálja ki, amely képes túlélni 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, zónától függetlenül. Ha egy rendelkezésre állási zóna meghibásodik, az adatútvonal megmaradhat mindaddig, amíg a régió többi zónája kifogástalan állapotban marad. További információ: Zónaredundáns terheléselosztó.

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers with with regional or zonal public IP Addresses
resources
| where type == "microsoft.network/loadbalancers"
| where tolower(sku.name) != 'basic'
| mv-expand feIPconfigs = properties.frontendIPConfigurations
| extend
    feConfigName = (feIPconfigs.name),
    PrivateSubnetId = toupper(feIPconfigs.properties.subnet.id),
    PrivateIPZones = feIPconfigs.zones,
    PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
    JoinID = toupper(id)
| where isnotempty(PrivateSubnetId)
| where isnull(PrivateIPZones) or array_length(PrivateIPZones) < 2
| project name, feConfigName, id
| union (resources
    | where type == "microsoft.network/loadbalancers"
    | where tolower(sku.name) != 'basic'
    | mv-expand feIPconfigs = properties.frontendIPConfigurations
    | extend
        feConfigName = (feIPconfigs.name),
        PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
        JoinID = toupper(id)
    | where isnotempty(PIPid)
    | join kind=innerunique (
        resources
        | where type == "microsoft.network/publicipaddresses"
        | where isnull(zones) or array_length(zones) < 2
        | extend
            LBid = toupper(substring(properties.ipConfiguration.id, 0, indexof(properties.ipConfiguration.id, '/frontendIPConfigurations'))),
            InnerID = toupper(id)
    ) on $left.PIPid == $right.InnerID)
| project recommendationId = "lb-4", name, id, tags, param1="Zones: No Zone or Zonal", param2=strcat("Frontend IP Configuration:", " ", feConfigName)

Győződjön meg arról, hogy a háttérkészlet legalább két példányt tartalmaz

A Load Balancer üzembe helyezése legalább két példánysal a háttérrendszerben. Egyetlen példány egyetlen meghibásodási pontot eredményezhet. A méretezés létrehozásához érdemes lehet párosítani a terheléselosztót a virtuálisgép-méretezési csoportokkal.

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers which only have 1 backend pool defined or only 1 VM in the backend pool
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend bep = properties.backendAddressPools
| extend BackEndPools = array_length(bep)
| where BackEndPools == 0
| project recommendationId = "lb-2", name, id, Param1=BackEndPools, Param2=0, tags
| union (resources
        | where type =~ 'Microsoft.Network/loadBalancers'
        | extend bep = properties.backendAddressPools
        | extend BackEndPools = array_length(bep)
        | mv-expand bip = properties.backendAddressPools
        | extend BackendAddresses = array_length(bip.properties.loadBalancerBackendAddresses)
        | where BackendAddresses <= 1
        | project recommendationId = "lb-2", name, id, tags, Param1=BackEndPools, Param2=BackendAddresses)

Rendszerhatékonyság

Nat Gateway használata kimenő szabályok helyett éles számítási feladatokhoz

A kimenő szabályok rögzített mennyiségű SNAT-portot foglalnak le egy háttérkészlet minden virtuálisgép-példányához. Ez a kiosztási módszer SNAT-portkimerüléshez vezethet, különösen akkor, ha az egyenetlen forgalmi minták miatt egy adott virtuális gép nagyobb mennyiségű kimenő kapcsolatot küld. Éles számítási feladatok esetén ajánlott a Standard Load Balancert vagy bármely alhálózati üzembe helyezést összekapcsolni az Azure NAT Gatewayrel. A NAT Gateway dinamikusan lefoglalja az SNAT-portokat az alhálózat összes virtuálisgép-példányában, és ezzel csökkenti az SNAT-portok kimerülésének kockázatát.

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers with Outbound rules configured
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend outboundRules = array_length(properties.outboundRules)
| where outboundRules > 0
| project recommendationId = "lb-3", name, id, tags, Param1 = "outboundRules: >=1"

Standard Load Balancer termékváltozat használata

A standard termékváltozatú Load Balancer támogatja a rendelkezésre állási zónákat és a zóna rugalmasságát, míg az alapszintű termékváltozat nem. Ha egy zóna lemegy, a zónaredundáns Standard Load Balancer nem lesz hatással, és az üzemelő példányok képesek ellenállni a zónahibáknak egy régión belül. Emellett a Standard Load Balancer támogatja a régiók közötti terheléselosztást, hogy az alkalmazás ne legyen hatással a régióhibákra.

Feljegyzés

Az alapszintű terheléselosztók nem rendelkeznek szolgáltatásiszint-szerződéssel (SLA).

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers using Basic SKU
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| where sku.name == 'Basic'
| project recommendationId = "lb-1", name, id, tags, Param1=strcat("sku-tier: basic")

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ával kapcsolatos további információkért tekintse meg a rendelkezésre állási zónák és régiók Javaslatok.

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.

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.

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.

Széf üzembehelyezé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 Javaslatok a vészhelyreállítási stratégia megtervezéséhez.

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:

• Több régióból származó bejövő forgalom.
• Azonnali globális feladatátvétel a következő optimális regionális üzembe helyezésre.
• A régiók közötti terheléselosztás a legközelebbi Azure-régióba ultra alacsony késéssel.
• Egyetlen végpont mögötti vertikális fel- és leskálázási lehetőség.
• Statikus bármely küldési globális IP-cím
• Ügyfél IP-címének megőrzése
• Meglévő terheléselosztó megoldás létrehozása tanulási görbe nélkül

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.

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.

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.

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

• Megbízhatóság az Azure-ban
• Lásd az oktatóanyagot: Régiók közötti terheléselosztó létrehozása az Azure Portal használatával régiók közötti terheléselosztó létrehozásához.
• További információ a régiók közötti terheléselosztóról.
• További információ az Azure Load Balancerről.