Geode minta

Azure Cosmos DB

Helyezze üzembe a háttérszolgáltatások gyűjteményét földrajzi csomópontok halmazába, amelyek mindegyike bármely régió bármely ügyfelének bármely kérését ki tudja szolgálni. Ez az aktív-aktív megközelítés elosztja a kérelmek feldolgozását világszerte a késés javítása és a rendelkezésre állás növelése érdekében.

Kontextus és probléma

Számos nagy léptékű szolgáltatás sajátos kihívásokkal rendelkezik a földrajzi rendelkezésre állás és a skálázás körül. A klasszikus kialakítások gyakran úgy hozzák az adatokat a számításba , hogy adatokat tárolnak egy távoli SQL-kiszolgálón, amely az adatok számítási szintjeként szolgál, és a növekedés érdekében a vertikális felskálázásra támaszkodik.

A klasszikus megközelítés a következő problémákat okozhatja:

• Hálózati késési problémák a világ másik oldaláról érkező felhasználók számára az üzemeltetési végponthoz való csatlakozáshoz
• Az igénykitörések forgalomkezelése, amely egy régióban túlterhelheti a szolgáltatásokat
• Az alkalmazásinfrastruktúra példányainak több régióban történő üzembe helyezésének költséges összetettsége egy 24x7-szolgáltatáshoz

A modern felhőinfrastruktúra úgy alakult ki, hogy lehetővé tegye az előtérbeli szolgáltatások földrajzi terheléselosztását, miközben lehetővé teszi a háttérszolgáltatások földrajzi replikációját. A rendelkezésre állás és a teljesítmény szempontjából jó, ha az adatok közelebb kerülnek a felhasználóhoz. Ha az adatok földrajzilag el vannak osztva egy távoli felhasználói bázison, a földrajzilag elosztott adattárakat az adatokat feldolgozó számítási erőforrásokkal is együtt kell helyezni. A geodéziai minta a számítást az adatokhoz hozza.

Megoldás

Helyezze üzembe a szolgáltatást több, világszerte elosztott műholdas egységben, amelyek mindegyikét geode-nak nevezzük. A geodéziai minta kihasználja az Azure főbb funkcióit, hogy a forgalmat egy közeli geodétához vezető legrövidebb útvonalon keresztül irányíthassa, ami javítja a késést és a teljesítményt. Minden geode egy globális terheléselosztó mögött található, és egy georeplikált olvasási-írási szolgáltatást használ, például az Azure Cosmos DB-t az adatsík üzemeltetéséhez, biztosítva a geodéziai adatkonzisztenciát. Az adatreplikációs szolgáltatások biztosítják, hogy az adattárak azonosak legyenek a geodéziai adatok között, így az összes kérés kiszolgálható az összes földrajzi régióból.

A telepítési bélyeg és a geóda között az a fő különbség, hogy a geódák soha nem léteznek elszigetelten. Egy gyártási platformon mindig több geodának kell lennie.

A geódák következő jellemzőkkel rendelkeznek:

• Különböző típusú erőforrások gyűjteménye, amelyek gyakran sablonban definiálhatók.
• Nincsenek függőségei a geodéziai lábnyomon kívül, és önállóak. Egyetlen geode sem függ a másiktól, és ha az egyik meghal, a többiek továbbra is működnek.
• A rendszer lazán összekapcsolja a peremhálózatot és a replikációs háttérsíkot. Használhatja például az Azure Traffic Managert vagy az Azure Front Doort a geodéziák előtérbe helyezéséhez, míg az Azure Cosmos DB replikációs háttérsíkként is működhet. A geódák nem azonosak a fürtökkel, mivel közös replikációs háttérhálózatuk van, így a platform kezeli a kvórumproblémákat.

A geodéziai minta olyan big data-architektúrákban fordul elő, amelyek nyersanyag-hardvert használnak az ugyanazon a gépen tárolt adatok feldolgozására, a MapReduce pedig az eredmények összesítésére a gépek között. Egy másik alkalmazási terület a közeli él-számítás, amely közelebb hozza a számítást a hálózat intelligens pereméhez a válaszidő csökkentése érdekében.

A szolgáltatások tucatnyi vagy akár több száz geóda esetén használhatják ezt a mintát. Ezenkívül a teljes megoldás rugalmassága minden újabb geodé hozzáadásával nő, mivel bármelyik geodé átveheti a munkát, ha egy regionális kimaradás miatt egy vagy több geodé offline státuszba kerül.

A helyi rendelkezésre állási technikák, például a rendelkezésre állási zónák vagy a párosított régiók is bővíthetők a globális rendelkezésre állás geodéziai mintájával. Ez növeli a bonyolultságot, de akkor hasznos, ha az architektúrát egy olyan tárolómotor, például a blobtároló támogatja, amely csak párosított régióba replikálható. A geode-okat zonális (egy zónás), többzónás vagy regionális környezetben is telepítheti, a helyszínre vonatkozó szabályozási vagy késleltetési korlátozások figyelembevételével.

Problémák és megfontolandó szempontok

A minta megvalósításához használja az alábbi technikákat és technológiákat:

• Modern DevOps-eljárások és eszközök az azonos geodéziák nagy számú régióban vagy példányban történő előállításához és gyors üzembe helyezéséhez.
• Automatikus skálázás a geodén belüli számítási és adatbázis-átviteli sebességpéldányok vertikális felskálázásához. Minden geode egyenként skálázható fel a közös háttérsík-korlátozásokon belül.
• Egy olyan előtér-szolgáltatás, mint az Azure Front Door, amely dinamikus tartalomgyorsítást, optimális jelenléti ponton keresztüli útválasztást és a TCP felosztását végzi.
• Az adatkonzisztencia ellenőrzésére használjon olyan replikáló adattárat, mint amilyen az Azure Cosmos DB.
• Kiszolgáló nélküli technológiák, ahol lehetséges, a folyamatos üzembehelyezési költségek csökkentése érdekében, különösen akkor, ha a terhelés gyakran újraegyensúlyozódik világszerte. Ez a stratégia lehetővé teszi, hogy számos geódát telepítsünk minimális további befektetéssel. A szerver nélküli és a fogyasztásalapú számlázási technológiák megszüntetik a párhuzamos földrajzilag elosztott üzembe helyezések miatti pazarlást és költségeket.
• Az API Management nem szükséges a tervezési minta implementálásához, de hozzáadható minden olyan geodához, amely a régió Azure-függvényalkalmazását támogatja, hogy robusztusabb API-réteget biztosítson, lehetővé téve további funkciók, például a sebességkorlátozás megvalósítását.

A minta megvalósítása során az alábbi pontokat vegye figyelembe:

• Itt adhatja meg, hogy az egyes régiókban helyben dolgozza fel az adatokat, vagy az összesítéseket egyetlen geodéziai helyen szeretné-e elosztani, és replikálja az eredményt a világ minden táján. Az Azure Cosmos DB változáscsatorna-feldolgozója ezt a részletes vezérlést a bérlettároló koncepciójával, valamint a megfelelő Azure Functions-kötésben található leasecollectionprefixtel kínálja. Minden megközelítésnek különböző előnyei és hátrányai vannak.
• A Geodes az Azure Cosmos DB változáscsatorna és egy valós idejű kommunikációs platform, például a SignalR használatával képes párhuzamosan működni. A geodák távoli felhasználókkal kommunikálhatnak más geodákon keresztül egy hálós mintázat szerint, anélkül, hogy tudnák vagy érdekli őket, hogy hol található a távoli felhasználó.
• Ez a kialakítási minta implicit módon elválaszt mindent, ami ultra-nagy mértékben elosztott és leválasztott architektúrát eredményez. Fontolja meg, hogyan követheti nyomon ugyanazon kérés különböző összetevőit, amelyeket aszinkron módon hajthatnak végre a különböző példányokon. A megfelelő monitorozási stratégia elengedhetetlen. Az Azure Front Door és az Azure Cosmos DB is könnyen integrálható a Log Analyticsszel, az Azure Functionst pedig az Application Insights mellett kell üzembe helyezni, hogy robusztus monitorozási rendszert biztosítson az architektúra minden összetevőjénél.
• Az elosztott üzembe helyezések nagyobb számú titkokkal és belépési pontokkal rendelkeznek, amelyek biztonsági intézkedéseket igényelnek. A Key Vault biztonságos réteget biztosít a titkos kódok kezeléséhez, és az API-architektúra minden rétegét megfelelően védeni kell, hogy az API egyetlen bemeneti pontja az olyan előtér-szolgáltatás, mint az Azure Front Door. Az Azure Cosmos DB-nek korlátoznia kell az Azure-függvényalkalmazások és az Azure Front Doorba irányuló függvényalkalmazások forgalmát a Microsoft Entra-azonosító vagy az IP-korlátozáshoz hasonló eljárások használatával.
• A teljesítményre jelentős hatást gyakorol a telepített geódák száma, valamint az egyes geódák API technológiáira alkalmazott App Service-csomagok. A további geodák üzembe helyezése vagy a prémium szintek felé való mozgás megnövelt költségekkel jár a többlet memória és számítás miatt, de nem tranzakciónként. Fontolja meg az API-architektúra üzembe helyezését követően a terheléstesztelés végrehajtását, és hasonlítsa össze a geodézisek számának növelését a magasabb árkategóriákkal, hogy az Ön igényeinek leginkább megfelelő költséghatékony modellt válassza.
• Határozza meg az adatok rendelkezésre állási követelményeit. Az Azure Cosmos DB választható jelzőkkel rendelkezik a többrégiós írás, a rendelkezésre állási zónák és egyebek engedélyezéséhez. Ezek növelik az Azure Cosmos DB-példány rendelkezésre állását, és rugalmasabb adatréteget hoznak létre, de további költségekkel járnak.
• Az Azure különböző terheléselosztókat kínál, amelyek különböző funkciókat biztosítanak a forgalom elosztásához. A döntési fával kiválaszthatja az API előtérének megfelelő lehetőséget.

Mikor érdemes ezt a mintát használni?

Használja a következő mintát a következő helyzetekben:

• Nagy léptékű platform implementálása, amely a felhasználókat széles körben terjeszti.
• Minden olyan szolgáltatás esetében, amely rendkívül rendelkezésre állási és rugalmassági jellemzőket igényel, mivel a geodéziai mintán alapuló szolgáltatások egyszerre több szolgáltatási régió elvesztését is túlélhetik.

Lehet, hogy ez a minta nem alkalmas

• Olyan architektúrák, amelyek kényszerekkel rendelkeznek, így az összes geodéziai vonal nem lehet egyenlő az adattárolás során. Lehetnek például adattárolási követelmények, egy alkalmazás, amely egy adott munkamenet ideiglenes állapotát kell fenntartania, vagy a kérések nagy súlyozása egyetlen régió felé. Ebben az esetben fontolja meg az üzembehelyezési bélyegek használatát egy olyan globális útválasztási síkkal kombinálva, amely tisztában van a felhasználó adatainak helyével, például az üzembehelyezési bélyegek mintájában leírt forgalomirányítási összetevővel.
• Olyan helyzetek, amikor nincs szükség földrajzi eloszlásra. Ehelyett fontolja meg a rendelkezésre állási zónák használatát és a párosított régiókat a fürtözési stratégia szempontjából.
• Olyan helyzetek, amikor egy örökölt platformot utólag kell átalakítani. Ez a minta csak a natív felhőbeli fejlesztéshez működik, és nehéz lehet utólag is átalakítani.
• Egyszerű architektúrák és követelmények, ahol a georedundancia és a geoterjesztés nem szükséges vagy előnyös.

Terhelés tervezés

Az építészeknek értékelniük kell, hogyan használható a Geode-minta a számítási feladat kialakításában az Azure Well-Architected Framework pilléreiben foglalt célok és alapelvek kezelésére. Példa:

Alappillér	Hogyan támogatja ez a minta a pillércélokat?
A megbízhatósági tervezési döntések segítenek a számítási feladatnak ellenállóvá válni a hibás működéssel szemben, és biztosítani, hogy a hiba bekövetkezése után teljesen működőképes állapotba kerüljön.	Ez a minta adatreplikálással támogatja azt az ideális megoldást, amelyet bármely ügyfél bármely földrajzi példányhoz csatlakoztathat, és így segít a számítási feladatnak ellenállni egy vagy több regionális kimaradásnak. - RE:05 Magas rendelkezésre állású többrégiós kialakítás - RE:05 Régiók és rendelkezésre állási zónák
A teljesítményhatékonyság a skálázás, az adatok és a kód optimalizálásával segíti a számítási feladatok hatékony kielégítését .	Ezzel a mintával az alkalmazást az elosztott felhasználói bázishoz legközelebb eső régióból is kiszolgálhatja. Ez csökkenti a késést azáltal, hogy megszünteti a távolsági forgalmat, és mivel az infrastruktúrát csak olyan felhasználók között osztja meg, amelyek jelenleg ugyanazt a földrajzi régiót használják. - PE:03 Szolgáltatások kiválasztása

Mint minden tervezési döntésnél, fontolja meg az ezzel a mintával bevezethető többi pillér céljaival szembeni kompromisszumokat.

Példák

• A Windows Active Directory ennek a mintának egy korai változatát implementálja. A több elsődleges replikáció azt jelenti, hogy elméletileg az összes frissítés és kérés kiszolgálható az összes szervizelhető csomópontról, de a rugalmas egy főkiszolgálós (FSMO) szerepkörök azt jelentik, hogy az összes geodéta nem egyenlő.

Helyezze üzembe a háttérszolgáltatások gyűjteményét földrajzi csomópontok halmazába, amelyek mindegyike bármely régió bármely ügyfelének bármely kérését ki tudja szolgálni. Ez az aktív-aktív megközelítés elosztja a kérelmek feldolgozását világszerte a késés javítása és a rendelkezésre állás növelése érdekében.

Kontextus és probléma

Számos nagy léptékű szolgáltatás sajátos kihívásokkal rendelkezik a földrajzi rendelkezésre állás és a skálázás körül. A klasszikus kialakítások gyakran úgy hozzák az adatokat a számításba , hogy adatokat tárolnak egy távoli SQL-kiszolgálón, amely az adatok számítási szintjeként szolgál, és a növekedés érdekében a vertikális felskálázásra támaszkodik.

A klasszikus megközelítés a következő problémákat okozhatja:

• Hálózati késési problémák a világ másik oldaláról érkező felhasználók számára az üzemeltetési végponthoz való csatlakozáshoz
• Az igénykitörések forgalomkezelése, amely egy régióban túlterhelheti a szolgáltatásokat
• Az alkalmazásinfrastruktúra példányainak több régióban történő üzembe helyezésének költséges összetettsége egy 24x7-szolgáltatáshoz

A modern felhőinfrastruktúra úgy alakult ki, hogy lehetővé tegye az előtérbeli szolgáltatások földrajzi terheléselosztását, miközben lehetővé teszi a háttérszolgáltatások földrajzi replikációját. A rendelkezésre állás és a teljesítmény szempontjából jó, ha az adatok közelebb kerülnek a felhasználóhoz. Ha az adatok földrajzilag el vannak osztva egy távoli felhasználói bázison, a földrajzilag elosztott adattárakat az adatokat feldolgozó számítási erőforrásokkal is együtt kell helyezni. A geodéziai minta a számítást az adatokhoz hozza.

Megoldás

Helyezze üzembe a szolgáltatást több, világszerte elosztott műholdas egységben, amelyek mindegyikét geode-nak nevezzük. A geodéziai minta kihasználja az Azure főbb funkcióit, hogy a forgalmat egy közeli geodétához vezető legrövidebb útvonalon keresztül irányíthassa, ami javítja a késést és a teljesítményt. Minden geode egy globális terheléselosztó mögött található, és egy georeplikált olvasási-írási szolgáltatást használ, például az Azure Cosmos DB-t az adatsík üzemeltetéséhez, biztosítva a geodéziai adatkonzisztenciát. Az adatreplikációs szolgáltatások biztosítják, hogy az adattárak azonosak legyenek a geodéziai adatok között, így az összes kérés kiszolgálható az összes földrajzi régióból.

A telepítési bélyeg és a geóda között az a fő különbség, hogy a geódák soha nem léteznek elszigetelten. Egy gyártási platformon mindig több geodának kell lennie.

A geódák következő jellemzőkkel rendelkeznek:

• Különböző típusú erőforrások gyűjteménye, amelyek gyakran sablonban definiálhatók.
• Nincsenek függőségei a geodéziai lábnyomon kívül, és önállóak. Egyetlen geode sem függ a másiktól, és ha az egyik meghal, a többiek továbbra is működnek.
• A rendszer lazán összekapcsolja a peremhálózatot és a replikációs háttérsíkot. Használhatja például az Azure Traffic Managert vagy az Azure Front Doort a geodéziák előtérbe helyezéséhez, míg az Azure Cosmos DB replikációs háttérsíkként is működhet. A geódák nem azonosak a fürtökkel, mivel közös replikációs háttérhálózatuk van, így a platform kezeli a kvórumproblémákat.

A geodéziai minta olyan big data-architektúrákban fordul elő, amelyek nyersanyag-hardvert használnak az ugyanazon a gépen tárolt adatok feldolgozására, a MapReduce pedig az eredmények összesítésére a gépek között. Egy másik alkalmazási terület a közeli él-számítás, amely közelebb hozza a számítást a hálózat intelligens pereméhez a válaszidő csökkentése érdekében.

A szolgáltatások tucatnyi vagy akár több száz geóda esetén használhatják ezt a mintát. Ezenkívül a teljes megoldás rugalmassága minden újabb geodé hozzáadásával nő, mivel bármelyik geodé átveheti a munkát, ha egy regionális kimaradás miatt egy vagy több geodé offline státuszba kerül.

A helyi rendelkezésre állási technikák, például a rendelkezésre állási zónák vagy a párosított régiók is bővíthetők a globális rendelkezésre állás geodéziai mintájával. Ez növeli a bonyolultságot, de akkor hasznos, ha az architektúrát egy olyan tárolómotor, például a blobtároló támogatja, amely csak párosított régióba replikálható. A geode-okat zonális (egy zónás), többzónás vagy regionális környezetben is telepítheti, a helyszínre vonatkozó szabályozási vagy késleltetési korlátozások figyelembevételével.

Problémák és megfontolandó szempontok

A minta megvalósításához használja az alábbi technikákat és technológiákat:

• Modern DevOps-eljárások és eszközök az azonos geodéziák nagy számú régióban vagy példányban történő előállításához és gyors üzembe helyezéséhez.
• Automatikus skálázás a geodén belüli számítási és adatbázis-átviteli sebességpéldányok vertikális felskálázásához. Minden geode egyenként skálázható fel a közös háttérsík-korlátozásokon belül.
• Egy olyan előtér-szolgáltatás, mint az Azure Front Door, amely dinamikus tartalomgyorsítást, optimális jelenléti ponton keresztüli útválasztást és a TCP felosztását végzi.
• Az adatkonzisztencia ellenőrzésére használjon olyan replikáló adattárat, mint amilyen az Azure Cosmos DB.
• Kiszolgáló nélküli technológiák, ahol lehetséges, a folyamatos üzembehelyezési költségek csökkentése érdekében, különösen akkor, ha a terhelés gyakran újraegyensúlyozódik világszerte. Ez a stratégia lehetővé teszi, hogy számos geódát telepítsünk minimális további befektetéssel. A szerver nélküli és a fogyasztásalapú számlázási technológiák megszüntetik a párhuzamos földrajzilag elosztott üzembe helyezések miatti pazarlást és költségeket.
• Az API Management nem szükséges a tervezési minta implementálásához, de hozzáadható minden olyan geodához, amely a régió Azure-függvényalkalmazását támogatja, hogy robusztusabb API-réteget biztosítson, lehetővé téve további funkciók, például a sebességkorlátozás megvalósítását.

A minta megvalósítása során az alábbi pontokat vegye figyelembe:

• Itt adhatja meg, hogy az egyes régiókban helyben dolgozza fel az adatokat, vagy az összesítéseket egyetlen geodéziai helyen szeretné-e elosztani, és replikálja az eredményt a világ minden táján. Az Azure Cosmos DB változáscsatorna-feldolgozója ezt a részletes vezérlést a bérlettároló koncepciójával, valamint a megfelelő Azure Functions-kötésben található leasecollectionprefixtel kínálja. Minden megközelítésnek különböző előnyei és hátrányai vannak.
• A Geodes az Azure Cosmos DB változáscsatorna és egy valós idejű kommunikációs platform, például a SignalR használatával képes párhuzamosan működni. A geodák távoli felhasználókkal kommunikálhatnak más geodákon keresztül egy hálós mintázat szerint, anélkül, hogy tudnák vagy érdekli őket, hogy hol található a távoli felhasználó.
• Ez a kialakítási minta implicit módon elválaszt mindent, ami ultra-nagy mértékben elosztott és leválasztott architektúrát eredményez. Fontolja meg, hogyan követheti nyomon ugyanazon kérés különböző összetevőit, amelyeket aszinkron módon hajthatnak végre a különböző példányokon. A megfelelő monitorozási stratégia elengedhetetlen. Az Azure Front Door és az Azure Cosmos DB is könnyen integrálható a Log Analyticsszel, az Azure Functionst pedig az Application Insights mellett kell üzembe helyezni, hogy robusztus monitorozási rendszert biztosítson az architektúra minden összetevőjénél.
• Az elosztott üzembe helyezések nagyobb számú titkokkal és belépési pontokkal rendelkeznek, amelyek biztonsági intézkedéseket igényelnek. A Key Vault biztonságos réteget biztosít a titkos kódok kezeléséhez, és az API-architektúra minden rétegét megfelelően védeni kell, hogy az API egyetlen bemeneti pontja az olyan előtér-szolgáltatás, mint az Azure Front Door. Az Azure Cosmos DB-nek korlátoznia kell az Azure-függvényalkalmazások és az Azure Front Doorba irányuló függvényalkalmazások forgalmát a Microsoft Entra-azonosító vagy az IP-korlátozáshoz hasonló eljárások használatával.
• A teljesítményre jelentős hatást gyakorol a telepített geódák száma, valamint az egyes geódák API technológiáira alkalmazott App Service-csomagok. A további geodák üzembe helyezése vagy a prémium szintek felé való mozgás megnövelt költségekkel jár a többlet memória és számítás miatt, de nem tranzakciónként. Fontolja meg az API-architektúra üzembe helyezését követően a terheléstesztelés végrehajtását, és hasonlítsa össze a geodézisek számának növelését a magasabb árkategóriákkal, hogy az Ön igényeinek leginkább megfelelő költséghatékony modellt válassza.
• Határozza meg az adatok rendelkezésre állási követelményeit. Az Azure Cosmos DB választható jelzőkkel rendelkezik a többrégiós írás, a rendelkezésre állási zónák és egyebek engedélyezéséhez. Ezek növelik az Azure Cosmos DB-példány rendelkezésre állását, és rugalmasabb adatréteget hoznak létre, de további költségekkel járnak.
• Az Azure különböző terheléselosztókat kínál, amelyek különböző funkciókat biztosítanak a forgalom elosztásához. A döntési fával kiválaszthatja az API előtérének megfelelő lehetőséget.

Mikor érdemes ezt a mintát használni?

Használja a következő mintát a következő helyzetekben:

• Nagy léptékű platform implementálása, amely a felhasználókat széles körben terjeszti.
• Minden olyan szolgáltatás esetében, amely rendkívül rendelkezésre állási és rugalmassági jellemzőket igényel, mivel a geodéziai mintán alapuló szolgáltatások egyszerre több szolgáltatási régió elvesztését is túlélhetik.

Lehet, hogy ez a minta nem alkalmas

• Olyan architektúrák, amelyek kényszerekkel rendelkeznek, így az összes geodéziai vonal nem lehet egyenlő az adattárolás során. Lehetnek például adattárolási követelmények, egy alkalmazás, amely egy adott munkamenet ideiglenes állapotát kell fenntartania, vagy a kérések nagy súlyozása egyetlen régió felé. Ebben az esetben fontolja meg az üzembehelyezési bélyegek használatát egy olyan globális útválasztási síkkal kombinálva, amely tisztában van a felhasználó adatainak helyével, például az üzembehelyezési bélyegek mintájában leírt forgalomirányítási összetevővel.
• Olyan helyzetek, amikor nincs szükség földrajzi eloszlásra. Ehelyett fontolja meg a rendelkezésre állási zónák használatát és a párosított régiókat a fürtözési stratégia szempontjából.
• Olyan helyzetek, amikor egy örökölt platformot utólag kell átalakítani. Ez a minta csak a natív felhőbeli fejlesztéshez működik, és nehéz lehet utólag is átalakítani.
• Egyszerű architektúrák és követelmények, ahol a georedundancia és a geoterjesztés nem szükséges vagy előnyös.

Terhelés tervezés

Az építészeknek értékelniük kell, hogyan használható a Geode-minta a számítási feladat kialakításában az Azure Well-Architected Framework pilléreiben foglalt célok és alapelvek kezelésére. Példa:

Alappillér	Hogyan támogatja ez a minta a pillércélokat?
A megbízhatósági tervezési döntések segítenek a számítási feladatnak ellenállóvá válni a hibás működéssel szemben, és biztosítani, hogy a hiba bekövetkezése után teljesen működőképes állapotba kerüljön.	Ez a minta adatreplikálással támogatja azt az ideális megoldást, amelyet bármely ügyfél bármely földrajzi példányhoz csatlakoztathat, és így segít a számítási feladatnak ellenállni egy vagy több regionális kimaradásnak. - RE:05 Magas rendelkezésre állású többrégiós kialakítás - RE:05 Régiók és rendelkezésre állási zónák
A teljesítményhatékonyság a skálázás, az adatok és a kód optimalizálásával segíti a számítási feladatok hatékony kielégítését .	Ezzel a mintával az alkalmazást az elosztott felhasználói bázishoz legközelebb eső régióból is kiszolgálhatja. Ez csökkenti a késést azáltal, hogy megszünteti a távolsági forgalmat, és mivel az infrastruktúrát csak olyan felhasználók között osztja meg, amelyek jelenleg ugyanazt a földrajzi régiót használják. - PE:03 Szolgáltatások kiválasztása

Mint minden tervezési döntésnél, fontolja meg az ezzel a mintával bevezethető többi pillér céljaival szembeni kompromisszumokat.

Példák

• A Windows Active Directory ennek a mintának egy korai változatát implementálja. A több elsődleges replikáció azt jelenti, hogy elméletileg az összes frissítés és kérés kiszolgálható az összes szervizelhető csomópontról, de a rugalmas egy főkiszolgálós (FSMO) szerepkörök azt jelentik, hogy az összes geodéta nem egyenlő.