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

Javaslatok a redundancia tervezéséhez

  • Cikk

Az Azure Well-Architected Framework megbízhatósági ellenőrzőlistájára vonatkozó javaslat:

RE:05 Redundancia hozzáadása különböző szinteken, különösen kritikus folyamatok esetén. Redundancia alkalmazása a számítási, adat-, hálózati és egyéb infrastruktúraszintekre az azonosított megbízhatósági céloknak megfelelően.

Kapcsolódó útmutatók: Magas rendelkezésre állású többrégiós kialakítás | rendelkezésre állási zónák és régiók használatával

Ez az útmutató ismerteti azokat a javaslatokat, amelyek a különböző számítási feladatok rétegeihez tartozó kritikus folyamatok redundanciájának hozzáadására szolgálnak, ami optimalizálja a rugalmasságot. A meghatározott megbízhatósági célok követelményeinek való megfeleléshez alkalmazza a megfelelő redundanciaszinteket a számítási, adat-, hálózatkezelési és egyéb infrastruktúraszintekre. Alkalmazza ezt a redundanciát, hogy a számítási feladat erős, megbízható alapot biztosítson a buildeléshez. Ha infrastruktúra-redundancia nélkül hozza létre a számítási feladatokat, a lehetséges hibák miatt nagy a kockázata a hosszabb állásidőnek.

Meghatározások

Időszak Definíció
Redundancia Egy számítási feladat összetevő több azonos példányának implementálása.
Többplatformos adattárolás A különböző tárolási technológiák ugyanazon alkalmazással vagy megoldással történő használatának fogalma az egyes összetevők legjobb képességeinek kihasználásához.
Adatkonzisztencia Egy adott adathalmaz szinkronizálásának vagy szinkronizáláson kívüli működésének mértéke több üzletben is elérhető.
Particionálás Az adatok külön adattárakba való fizikai felosztásának folyamata.
szegmens Horizontális adatbázisparticionálási stratégia, amely több, közös sémával rendelkező tárpéldányt támogat. Az adatok nem replikálódnak minden példányban.

Főbb tervezési stratégiák

A megbízhatóság kontextusában a redundancia használatával olyan problémákat tartalmazzon, amelyek egyetlen erőforrást érintenek, és győződjön meg arról, hogy ezek a problémák nem befolyásolják a teljes rendszer megbízhatóságát. Az egyes folyamatok redundanciához szükséges megalapozott döntések meghozatalához használja a kritikus folyamatokra és a megbízhatósági célokra vonatkozó információkat.

Előfordulhat például, hogy egyszerre több webkiszolgáló-csomópont is fut. Az általuk támogatott folyamat kritikussága megköveteli, hogy mindegyik replika készen álljon a forgalom elfogadására, ha a teljes készletet érintő probléma merül fel, például regionális kimaradás esetén. Alternatív megoldásként, mivel a nagy léptékű problémák ritkán fordulnak elő, és költséges a replikák teljes készletének üzembe helyezése, előfordulhat, hogy korlátozott számú replikát helyez üzembe, így a folyamat csökkentett állapotban működik, amíg meg nem oldja a problémát.

Ha a teljesítményhatékonyság kontextusában tervez redundanciát, ossza el a terhelést több redundáns csomópont között, hogy az egyes csomópontok optimálisan teljesíthessenek. A megbízhatóság kontextusában építsen tartalék kapacitást az egy vagy több csomópontot érintő hibák vagy meghibásodások elnyelésére. Győződjön meg arról, hogy a tartalék kapacitás az érintett csomópontok helyreállításához szükséges teljes időre képes elnyelni a hibákat. Ezt a különbséget szem előtt tartva mindkét stratégiának együtt kell működnie. Ha a forgalom két csomópont között oszlik el a teljesítmény szempontjából, és mindkettő 60 százalékos kihasználtsággal fut, és az egyik csomópont meghibásodik, a fennmaradó csomópont túlterheltté válik, mert nem működik 120 százalékon. Helyezze el a terhelést egy másik csomóponttal, hogy a teljesítmény- és megbízhatósági célok teljesüljenek.

Kompromisszumok:

  • A több számítási feladat redundancia több költséggel egyenlő. Körültekintően vegye fontolóra a redundancia hozzáadását, és rendszeresen tekintse át az architektúrát, hogy biztosítsa a költségek kezelését, különösen akkor, ha túlterjeszkedést használ. Ha rugalmassági stratégiaként túlterjeszkedést használ, egyensúlyozza ki azt egy jól definiált skálázási stratégiával a költséghatékonyság minimalizálása érdekében.
  • Nagy mértékű redundancia esetén teljesítménybeli kompromisszumok is lehetnek. A rendelkezésre állási zónákban vagy régiókban elterülő erőforrások például hatással lehetnek a teljesítményre, mert a forgalmat a redundáns erőforrások, például webkiszolgálók vagy adatbázispéldányok közötti nagy késésű kapcsolatokon keresztül kell elküldeni.
  • Az ugyanazon számítási feladaton belüli különböző folyamatok eltérő megbízhatósági követelményekkel rendelkezhetnek. A folyamatspecifikus redundanciatervek összetettebbé tehetik a teljes kialakítást.

Redundáns architektúratervezés

Redundáns architektúra tervezésekor két megközelítést érdemes figyelembe venni: aktív-aktív vagy aktív-passzív. Az infrastruktúra-összetevők által támogatott felhasználói folyamat és rendszerfolyamat kritikusságától függően válassza ki a megközelítést. A megbízhatóság szempontjából a többrégiós aktív-aktív kialakítás segít a lehető legmagasabb szintű megbízhatóság elérésében, de lényegesen drágább, mint az aktív-passzív kialakítás. A megfelelő földrajzi régiók kiválasztása lesz a következő kritikus döntés. Ezeket a tervezési módszereket egyetlen régióhoz is használhatja a rendelkezésre állási zónák használatával. További információ: Javaslatok magas rendelkezésre állású többrégiós tervezéshez.

Üzembehelyezési bélyegek és méretezési egységek

Függetlenül attól, hogy aktív-aktív vagy aktív-passzív modellben helyezi üzembe, kövesse az Üzembehelyezési bélyegek tervezési mintát , hogy a számítási feladatot megismételhető, skálázható módon helyezze üzembe. Az üzembehelyezési bélyegek olyan erőforrások csoportosítását képezik, amelyek szükségesek ahhoz, hogy a számítási feladatot az ügyfelek egy adott részhalmaza számára kézbesítse. Az alhalmaz lehet például egy regionális részhalmaz vagy egy olyan részhalmaz, amely ugyanazokat az adatvédelmi követelményeket támasztja, mint a számítási feladat. Az egyes bélyegeket skálázási egységnek tekintheti, amelyet duplikálhat a számítási feladatok horizontális skálázásához vagy kék-zöld környezetek végrehajtásához. Tervezze meg számítási feladatait üzembehelyezési bélyegekkel, hogy optimalizálja az aktív-aktív vagy aktív-passzív implementációt a rugalmasság és a felügyeleti terhek érdekében. A többrégiós felskálázás tervezése is fontos a régióban esetleges ideiglenes erőforrás-kapacitáskorlátok leküzdése érdekében.

Rendelkezésre állási zónák az Azure-régiókban

Akár aktív-aktív, akár aktív-passzív kialakítást helyez üzembe, használja ki az aktív régiók rendelkezésre állási zónáinak előnyeit a rugalmasság teljes optimalizálásához. Számos Azure-régió több rendelkezésre állási zónát is biztosít, amelyek egy régión belüli adatközpontok különálló csoportjai. Az Azure-szolgáltatástól függően kihasználhatja a rendelkezésre állási zónák előnyeit, ha a számítási feladat elemeit redundánsan helyezi üzembe zónák között, vagy az elemeket meghatározott zónákba rögzíti. További információkért tekintse meg a rendelkezésre állási zónák és régiók használatára vonatkozó javaslatokat.

Zónaredundancia megvalósítása számítási erőforrásokhoz

  • Válassza ki a számítási feladathoz megfelelő számítási szolgáltatást . A megtervezett számítási feladatok típusától függően több lehetőség is rendelkezésre áll. Vizsgálja meg az elérhető szolgáltatásokat, és ismerje meg, hogy mely számítási feladatok működnek a legjobban egy adott számítási szolgáltatáson. Az SAP számítási feladatai például általában az infrastruktúra szolgáltatásként (IaaS) nyújtott számítási szolgáltatásaihoz ideálisak. Tárolóalapú alkalmazások esetében határozza meg azokat a funkciókat, amelyek felett szabályoznia kell, hogy az Azure Kubernetes Service (AKS) vagy egy szolgáltatásként nyújtott platform (PaaS) megoldást használja-e. A felhőplatform teljes mértékben felügyel egy PaaS-szolgáltatást.

  • Ha a követelmények megengedik, használja a PaaS számítási beállításait. Az Azure teljes mértékben felügyeli a PaaS-szolgáltatásokat, ami csökkenti a felügyeleti terheket, és a redundancia dokumentált szintje be van építve.

  • Ha virtuális gépeket (virtuális gépeket) szeretne üzembe helyezni, használja az Azure-beli virtuálisgép-méretezési csoportokat. A virtuálisgép-méretezési csoportok segítségével automatikusan egyenletesen eloszthatja a számítást a rendelkezésre állási zónák között.

  • Tartsa távol a számítási réteget minden állapottól , mert a kéréseket kiszolgáló egyes csomópontok bármikor törölhetők, meghibásodhatnak vagy lecserélhetők.

  • Ha lehetséges, használjon zónaredundáns szolgáltatásokat, hogy nagyobb rugalmasságot biztosítson a működési terhelés növelése nélkül.

  • A kritikus erőforrások túlméretezése a redundáns példányok hibáinak csökkentése érdekében még az automatikus skálázási műveletek megkezdése előtt is, így a rendszer továbbra is működni fog egy összetevő meghibásodása után. Számítsa ki a hiba elfogadható hatását, ha a redundanciatervbe belefoglalja a túlterjedést. A redundancia-döntéshozatali folyamathoz hasonlóan a megbízhatósági célok és a pénzügyi kompromisszumos döntések határozzák meg, hogy mennyi szabad kapacitást ad hozzá a túlterjedéssel. A túlméretezés kifejezetten a horizontális felskálázásra utal, ami azt jelenti, hogy egy adott számítási erőforrástípushoz további példányokat kell hozzáadni ahelyett, hogy egyetlen példány számítási képességeit növelnék. Ha például egy virtuális gépet alacsonyabb szintű termékváltozatról magasabb szintű termékváltozatra módosít.

  • Az IaaS-szolgáltatásokat manuálisan vagy automatizálással helyezheti üzembe minden olyan rendelkezésre állási zónában vagy régióban, amelyben a megoldást implementálni szeretné. Egyes PaaS-szolgáltatások beépített képességekkel rendelkeznek, amelyek automatikusan replikálódnak a rendelkezésre állási zónák és régiók között.

Zónaredundancia megvalósítása adaterőforrásokhoz

  • Határozza meg, hogy szükség van-e szinkron vagy aszinkron adatreplikálásra a számítási feladat működéséhez. Ennek meghatározásához tekintse meg a rendelkezésre állási zónák és régiók használatára vonatkozó javaslatokat.

  • Vegye figyelembe az adatok növekedési ütemét. Kapacitástervezéshez tervezze meg az adatnövekedést, az adatmegőrzést és az archiválást annak érdekében, hogy a megbízhatósági követelmények teljesüljenek a megoldásban lévő adatok mennyiségének növekedésével.  

  • A földrajzilag honosított hibák hatásának minimalizálása érdekében terjessze el az adatokat földrajzilag, a szolgáltatás által támogatott módon.

  • Adatok replikálása földrajzi régiók között, hogy rugalmasságot biztosítson a regionális kimaradásokkal és a katasztrofális hibákkal szemben.

  • Automatizálhatja a feladatátvételt egy adatbázispéldány meghibásodása után. Az automatizált feladatátvételt több Azure PaaS-adatszolgáltatásban is konfigurálhatja. Nem szükséges automatizált feladatátvétel a többrégiós írást támogató adattárakhoz, például az Azure Cosmos DB-hez. További információ: Javaslatok vészhelyreállítási stratégia kialakításához.

  • Használja a legjobb adattárat az adataihoz. Használja a többplatformos adatmegőrzést vagy az adattártechnológiák kombinációját használó megoldásokat. Az adatok nem csak a tárolt alkalmazásadatokat tartalmazzák. Ide tartoznak az alkalmazásnaplók, események, üzenetek és a gyorsítótárak is.

  • Vegye figyelembe az adatkonzisztencia követelményeit, és használjon végleges konzisztenciát , ha a követelmények lehetővé teszik. Az adatok elosztásakor a megfelelő koordinációval kényszerítse ki az erős konzisztenciára vonatkozó garanciákat. A koordináció csökkentheti az átviteli sebességet, és szorosan összekapcsolhatja a rendszereket, ami törékenyebbé teheti őket. Ha például egy művelet két adatbázist frissít, ahelyett, hogy egyetlen tranzakciós hatókörbe helyezné, jobb, ha a rendszer képes a végleges konzisztenciára.

  • Particionálási adatok a rendelkezésre álláshoz. Az adatbázis particionálása javítja a méretezhetőséget, és javíthatja a rendelkezésre állást is. Ha az egyik szegmens leesik, a többi szegmens továbbra is elérhető. Egy szegmens meghibásodása csak a teljes tranzakciók egy részhalmazát zavarja meg.

  • Ha a horizontális skálázás nem lehetőség, a parancs- és lekérdezésfelelősségi szegregáció (CQRS) mintával elválaszthatja az írásvédett és írásvédett adatmodelleket. Adjon hozzá több redundáns írásvédett adatbázispéldányt, hogy nagyobb rugalmasságot biztosítson.  

  • Ismerje meg a használt állapotalapú platformszolgáltatások beépített replikációs és redundanciaképességeit. Az állapotalapú adatszolgáltatások konkrét redundanciaképességéről a Kapcsolódó hivatkozások című témakörben olvashat.

Zónaredundancia megvalósítása hálózati erőforrásokhoz

  • Megbízható és méretezhető hálózati topológia kiválasztása. Küllős modell vagy Azure Virtual WAN-modell használata a felhőinfrastruktúra logikai mintákban való rendszerezéséhez, amely megkönnyíti a redundancia kialakítását és méretezését.

  • Válassza ki a megfelelő hálózati szolgáltatást a kérelmek régiókon belüli vagy régiók közötti elosztásához és átirányításához. Ha lehetséges, használjon globális vagy zónaredundáns terheléselosztási szolgáltatásokat a megbízhatósági célok eléréséhez.

  • Győződjön meg arról, hogy elegendő IP-címteret foglalt le a virtuális hálózatokban és alhálózatokban a tervezett használat figyelembe vételéhez, beleértve a vertikális felskálázási követelményeket is.

  • Győződjön meg arról, hogy az alkalmazás méretezhető a választott alkalmazás-üzemeltetési platform portkorlátjai között. Ha egy alkalmazás több kimenő TCP- vagy UDP-kapcsolatot kezdeményez, az kimerítheti az összes elérhető portot, és gyenge alkalmazásteljesítményt okozhat.

  • Válassza ki az SKU-kat, és konfiguráljon olyan hálózati szolgáltatásokat, amelyek megfelelnek a sávszélességre és a rendelkezésre állásra vonatkozó követelményeknek. A VPN-átjáró átviteli sebessége az SKU-juktól függően változik. A zónaredundancia támogatása csak bizonyos terheléselosztó termékváltozatokhoz érhető el.

  • Győződjön meg arról, hogy a DNS kezelésére szolgáló kialakítás a rugalmasságra összpontosít, és támogatja a redundáns infrastruktúrát.

Az Azure megkönnyítése

Az Azure-platform segít optimalizálni a számítási feladatok rugalmasságát, és redundanciát hozzáadni a következők segítségével:

DNS-specifikus Azure-beli könnyítés

  • Belső névfeloldási forgatókönyvek esetén használja az Azure DNS privát zónáit, amelyek beépített zónaredundanciával és georedundanciával rendelkeznek. További információ: Azure DNS privát zóna rugalmassága.

  • Külső névfeloldási forgatókönyvekhez használja az Azure DNS nyilvános zónáit, amelyek beépített zónaredundanciával és georedundanciával rendelkeznek.

  • A nyilvános és privát Azure DNS-szolgáltatások olyan globális szolgáltatások, amelyek ellenállnak a regionális kimaradásoknak, mivel a zónaadatok globálisan elérhetők.

  • A helyszíni és a felhőkörnyezetek közötti hibrid névfeloldási forgatókönyvekhez használja az Azure DNS Private Resolvert. Ez a szolgáltatás támogatja a zónaredundanciát, ha a számítási feladat olyan régióban található, amely támogatja a rendelkezésre állási zónákat. A zónaszintű kimaradás nem igényel műveletet a zóna helyreállítása során. A szolgáltatás automatikusan öngyógyít és kiegyensúlyoz, hogy kihasználja az egészséges zónát. További információ: Rugalmasság az Azure DNS Private Resolverben.

  • Egy hibapont kiküszöbölése és a régiók közötti rugalmasabb hibrid névfeloldás érdekében helyezzen üzembe két vagy több Privát Azure DNS-feloldót a különböző régiókban. A DNS-feladatátvétel feltételes továbbítási forgatókönyvben egy feloldó elsődleges DNS-kiszolgálóként való hozzárendelésével érhető el. Rendelje hozzá a másik feloldót egy másik régióban másodlagos DNS-kiszolgálóként. További információ: DNS-feladatátvétel beállítása privát feloldók használatával.

Példa

Többrégiós redundáns üzembe helyezésre példa: Alapkonfiguráció– magas rendelkezésre állású zónaredundáns webalkalmazás.

Az alábbi ábrán egy másik példa látható:

A referencia-implementáció architektúráját bemutató diagram.

A redundanciával kapcsolatos további információkért tekintse meg a következő erőforrásokat:

Megbízhatósági ellenőrzőlista

Tekintse meg a javaslatok teljes készletét.

Megbízhatósági ellenőrzőlista