Magas rendelkezésre állásra és vészhelyreállításra tervezett többrétegű webalkalmazás

Azure

Azure Arc

SQL Server

Windows

Ez a példaforgatókönyv minden olyan iparágra alkalmazható, amely magas rendelkezésre álláshoz és vészhelyreállításhoz készült, rugalmas, többtényezős alkalmazásokat kell üzembe helyeznie. Ebben a forgatókönyvben az alkalmazás három rétegből áll.

• Webes réteg: A legfelső réteg, beleértve a felhasználói felületet is. Ez a réteg elemzi a felhasználói interakciókat, és átadja a műveleteket a következő rétegnek feldolgozás céljából.
• Üzleti szint: Feldolgozza a felhasználói interakciókat, és logikus döntéseket hoz a következő lépésekről. Ez a réteg összekapcsolja a webes réteget és az adatréteget.
• Adatszint: Az alkalmazás adatait tárolja. Általában adatbázist, objektumtárolót vagy fájltárolót használnak.

A gyakori alkalmazási forgatókönyvek közé tartoznak a Windowson vagy Linuxon futó, kritikus fontosságú alkalmazások. Ez lehet egy polcon kívüli alkalmazás, például az SAP és a SharePoint, vagy egy egyéni üzletági alkalmazás.

Lehetséges használati esetek

Egyéb releváns használati esetek a következők:

• Rendkívül rugalmas alkalmazások, például az SAP és a SharePoint üzembe helyezése
• Üzletmenet-folytonossági és vészhelyreállítási terv tervezése üzletági alkalmazásokhoz
• Vészhelyreállítás konfigurálása és kapcsolódó részletezések végrehajtása megfelelőségi célokra

Architektúra

Töltse le az architektúra Visio-fájlját.

Workflow

• Ossza el az egyes szinteken lévő virtuális gépeket két rendelkezésre állási zónában a zónákat támogató régiókban. Más régiókban üzembe helyezheti a virtuális gépeket az egyes szinteken egy rendelkezésre állási csoportban.
• Az adatbázisszint konfigurálható Always On rendelkezésre állási csoportok használatára. Ezzel az SQL Server-konfigurációval a rendelkezésre állási csoportban egy elsődleges olvasási/írási replika legfeljebb nyolc másodlagos írásvédett replikával van konfigurálva. Ha probléma merül fel az elsődleges replikával kapcsolatban, a rendelkezésre állási csoport az elsődleges olvasási/írási tevékenységet az egyik másodlagos replikán nem tudja elvégezni, így az alkalmazás továbbra is elérhető marad. További információ: Always On rendelkezésre állási csoportok áttekintése az SQL Serverhez.
• Vészhelyreállítási forgatókönyvek esetén konfigurálhatja az SQL Always On aszinkron natív replikációt a vészhelyreállításhoz használt célrégióba. Az Azure Site Recovery replikációját a célrégióba is konfigurálhatja, ha az adatváltozási arány az Azure Site Recovery támogatott korlátain belül van.
• A felhasználók a traffic manager végpontján keresztül férnek hozzá az előtérbeli ASP.NET webes szinthez.
• A forgalomkezelő átirányítja a forgalmat az elsődleges nyilvános IP-végpontra az elsődleges forrásrégióban.
• A nyilvános IP-cím átirányítja a hívást az egyik webes szintű virtuálisgép-példányra egy nyilvános terheléselosztón keresztül. Minden webes szintű virtuálisgép-példány egy alhálózatban található.
• A webes szintű virtuális gépről a rendszer minden hívást egy belső terheléselosztón keresztül irányít át az üzleti réteg egyik virtuálisgép-példányára feldolgozás céljából. Minden üzleti szintű virtuális gép külön alhálózatban található.
• A művelet feldolgozása az üzleti szinten történik, és az ASP.NET alkalmazás egy háttérszinten csatlakozik a Microsoft SQL Server-fürthöz egy Azure-beli belső terheléselosztón keresztül. Ezek a háttérbeli SQL Server-példányok külön alhálózatban találhatók.
• A traffic manager másodlagos végpontja nyilvános IP-címként van konfigurálva a vészhelyreállításhoz használt célrégióban.
• Elsődleges régió megszakadása esetén meghívja az Azure Site Recovery feladatátvételét, és az alkalmazás aktívvá válik a célrégióban.
• A traffic manager végpontja automatikusan átirányítja az ügyfélforgalmat a célrégió nyilvános IP-címére.

Összetevők

• A rendelkezésre állási csoportok hibatűrési funkciók, amelyek biztosítják, hogy a virtuális gépek több elkülönített hardvercsomópont között legyenek elosztva egy fürtben. Ebben az architektúrában a rendelkezésre állási csoportok védelmet nyújtanak a hardver- és szoftverhibák ellen azáltal, hogy biztosítják, hogy a kimaradás csak a virtuális gépek egy részhalmazára legyen hatással. Ez a megközelítés fenntartja az alkalmazások rendelkezésre állását és működési folytonosságát a többrétegű alkalmazásokban.

• A rendelkezésre állási zónák különálló fizikai helyek egy Azure-régión belül, amelyek megvédik az alkalmazásokat és az adatokat az adatközpontok hibáitól. Ebben az architektúrában a rendelkezésre állási zónák nagyobb rugalmasságot biztosítanak azáltal, hogy virtuális gépeket osztanak szét több adatközpont között, független energiaellátással, hűtéssel és hálózati infrastruktúrával.

• Az Azure Load Balancer egy 4. rétegbeli terheléselosztó, amely a meghatározott szabályok és állapotminták alapján osztja el a bejövő forgalmat a nagy átviteli sebesség és az alacsony késés érdekében. Ebben az architektúrában a nyilvános terheléselosztó elosztja a bejövő ügyfélforgalmat a webes szintű virtuális gépek között, míg a belső terheléselosztók a webes szintről az üzleti szintre, az üzleti szintről pedig a háttérbeli SQL Server-fürtre irányítják a forgalmat.

• Az Azure Traffic Manager egy DNS-alapú forgalom terheléselosztó, amely elosztja a forgalmat a globális Azure-régiók között. Ebben az architektúrában a Traffic Manager globális terheléselosztást biztosít azáltal, hogy a felhasználói forgalmat a normál műveletek során az elsődleges régióba irányítja, és automatikusan átirányítja a forgalmat a vészhelyreállítási régióba a kimaradások során.

• A Site Recovery egy vészhelyreállítási szolgáltatás, amely lehetővé teszi a virtuális gépek replikálást egy másik Azure-régióba az üzletmenet folytonossága és a vészhelyreállítás érdekében. Ebben az architektúrában a Site Recovery lehetővé teszi a vészhelyreállítási képességeket azáltal, hogy a virtuális gépeket egy célrégióba replikálja az alkalmazás helyreállításához a forrásrégiók leállása során. Emellett rendszeres vészhelyreállítási próbákkal támogatja a megfelelőségi követelményeket.

Alternatívák

• A Windowst más operációs rendszerek is lecserélhetik, mert az infrastruktúrában semmi sem függ az operációs rendszertől.
• A Linuxhoz készült SQL Server lecserélheti a háttéradattárat.
• Az adatbázist bármely elérhető szabványos adatbázis-alkalmazás helyettesítheti.

Forgatókönyv részletei

Ez a forgatókönyv egy ASP.NET és a Microsoft SQL Servert használó több-bérlős alkalmazást mutat be. A rendelkezésre állási zónákat támogató Azure-régiókban üzembe helyezheti a virtuális gépeket egy forrásrégióban a rendelkezésre állási zónák között, és replikálhatja a virtuális gépeket a vészhelyreállításhoz használt célrégióba. A rendelkezésre állási zónákat nem támogató Azure-régiókban üzembe helyezheti a virtuális gépeket egy rendelkezésre állási csoportban , és replikálhatja a virtuális gépeket a célrégióba.

A régiók közötti forgalom irányításához globális terheléselosztóra van szükség. Két fő Azure-ajánlat létezik:

• Azure Front Door
• Azure Traffic Manager

Terheléselosztó kiválasztásakor vegye figyelembe a két ajánlat követelményeit és funkciókészletét. Milyen gyorsan szeretné elvégezni a feladatátvételt? Át tudja venni a TLS-kezelés többletterhelését? Vannak szervezeti költségkorlátozások?

A Front Door 7. rétegbeli képességei: SSL-kiszervezés, útvonalalapú útválasztás, gyors feladatátvétel, gyorsítótárazás és egyéb funkciók az alkalmazások teljesítményének és magas rendelkezésre állásának javítása érdekében. Gyorsabb csomagutazási időket tapasztalhat, mert az infrastruktúra hamarabb van előkészítve az Azure-hálózatra.

Mivel a Front Door új ugrást ad hozzá, további biztonsági műveletek is vannak. Ha az architektúra megfelel a jogszabályi követelményeknek, korlátozások lehetnek a további forgalmi TLS-végpontra vonatkozóan. A Front Door által kiválasztott TLS-titkosítási csomagoknak meg kell felelniük a szervezet biztonsági sávjának. Emellett a Front Door elvárja, hogy a háttérszolgáltatások a Microsoft megbízható hitelesítésszolgáltatói listájának részét képező tanúsítványokat használják.

Egy másik szempont a költség. Az architektúrának ki kell használnia a széles körű szolgáltatáskészletet (nem csak a feladatátvételt), hogy igazolja a hozzáadott költségeket.

A Traffic Manager egy DNS-alapú terheléselosztási szolgáltatás. Az egyensúly és a feladatátvétel csak DNS-szinten működik. Emiatt nem tud olyan gyorsan feladatátvételt végrehajtani, mint a Front Door, mert gyakori problémák merülnek fel a DNS-gyorsítótárazás és a DNS-TCL-ek tiszteletben nem álló rendszerei között.

Szükség esetén mindkét terheléselosztót kombinálhatja. Szeretné például a DNS-alapú feladatátvételt, de pop-felületet szeretne hozzáadni a forgalom által felügyelt infrastruktúra előtt.

Ez az architektúra a Traffic Managert használja, mert könnyű. A feladatátvétel időzítése elegendő szemléltető célokra.

Megfontolások

Ezek a szempontok implementálják az Azure Well-Architected Framework alappilléreit, amely a számítási feladatok minőségének javítására használható vezérelvek készlete. További információ: Well-Architected Framework.

Biztonság

A biztonság biztosítékokat nyújt a szándékos támadások és az értékes adatokkal és rendszerekkel való visszaélés ellen. További információkért lásd a Biztonsági terv felülvizsgálati ellenőrzőlistát.

Az előtérbeli alkalmazásszintre irányuló összes virtuális hálózati forgalmat hálózati biztonsági csoportok védik. A szabályok korlátozzák a forgalom áramlását, hogy csak az előtérbeli alkalmazásszintű virtuálisgép-példányok férhessenek hozzá a háttéradatbázis-szinthez. Az üzleti szintről vagy az adatbázisszintről nem engedélyezett kimenő internetes forgalom. A támadási lábnyom csökkentése érdekében nincsenek nyitva közvetlen távoli felügyeleti portok. További információ: Azure hálózati biztonsági csoportok.

A biztonságos forgatókönyvek tervezésével kapcsolatos általános útmutatásért tekintse meg az Azure biztonsági dokumentációját.

Költségoptimalizálás

A költségoptimalizálás a szükségtelen kiadások csökkentésére és a működési hatékonyság javítására összpontosít. További információt a Költségoptimalizálás tervezési felülvizsgálati ellenőrzőlistájában talál.

Az Azure-beli virtuális gépek vészhelyreállításának Azure Site Recovery használatával történő konfigurálása folyamatosan a következő díjakat fogja terhelni.

• Az Azure Site Recovery licencelési költsége virtuális gépenként.
• A hálózati kimenő költségek a forrás virtuálisgép-lemezekről egy másik Azure-régióba történő adatváltozások replikálásához. Az Azure Site Recovery beépített tömörítéssel körülbelül 50%-kal csökkenti az adatátviteli követelményeket.
• Tárolási költségek a helyreállítási helyen. Ez általában megegyezik a forrásrégió tárterületével, valamint a helyreállítási pontok helyreállítási pillanatképekként való fenntartásához szükséges további tárterületekkel.

Biztosítottunk egy költségkalkulátort egy háromrétegű alkalmazás vészhelyreállításának konfigurálásához hat virtuális gép használatával. Az összes szolgáltatás előre konfigurálva van a költségkalkulátorban. Annak megtekintéséhez, hogy az adott használati eset díjszabása hogyan változna, módosítsa a megfelelő változókat a költség becsléséhez.

Teljesítményhatékonyság

A teljesítményhatékonyság azt jelenti, hogy a számítási feladat hatékonyan képes méretezni a felhasználói igényeket. További információt a Teljesítményhatékonyság tervezési felülvizsgálati ellenőrzőlistájában talál.

A skálázási követelményeknek megfelelően minden szinten hozzáadhat vagy eltávolíthat virtuális gépeket. Mivel ez a forgatókönyv terheléselosztókat használ, további virtuális gépeket adhat hozzá egy szinthez anélkül, hogy az alkalmazás üzemidejét befolyásolná.

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerző:

• Sujay Talasila | Egyszerű termék érdeklődője

Következő lépések

• A Traffic Manager üzembe helyezése az Azure-ban
• Vészhelyreállítás beállítása Azure-beli virtuális gépekhez

Kapcsolódó erőforrások

További magas rendelkezésre állási és vészhelyreállítási referenciaarchitektúrákért lásd:

• Többrégiós terheléselosztás

Ez a példaforgatókönyv minden olyan iparágra alkalmazható, amely magas rendelkezésre álláshoz és vészhelyreállításhoz készült, rugalmas, többtényezős alkalmazásokat kell üzembe helyeznie. Ebben a forgatókönyvben az alkalmazás három rétegből áll.

• Webes réteg: A legfelső réteg, beleértve a felhasználói felületet is. Ez a réteg elemzi a felhasználói interakciókat, és átadja a műveleteket a következő rétegnek feldolgozás céljából.
• Üzleti szint: Feldolgozza a felhasználói interakciókat, és logikus döntéseket hoz a következő lépésekről. Ez a réteg összekapcsolja a webes réteget és az adatréteget.
• Adatszint: Az alkalmazás adatait tárolja. Általában adatbázist, objektumtárolót vagy fájltárolót használnak.

A gyakori alkalmazási forgatókönyvek közé tartoznak a Windowson vagy Linuxon futó, kritikus fontosságú alkalmazások. Ez lehet egy polcon kívüli alkalmazás, például az SAP és a SharePoint, vagy egy egyéni üzletági alkalmazás.

Lehetséges használati esetek

Egyéb releváns használati esetek a következők:

• Rendkívül rugalmas alkalmazások, például az SAP és a SharePoint üzembe helyezése
• Üzletmenet-folytonossági és vészhelyreállítási terv tervezése üzletági alkalmazásokhoz
• Vészhelyreállítás konfigurálása és kapcsolódó részletezések végrehajtása megfelelőségi célokra

Architektúra

Töltse le az architektúra Visio-fájlját.

Workflow

• Ossza el az egyes szinteken lévő virtuális gépeket két rendelkezésre állási zónában a zónákat támogató régiókban. Más régiókban üzembe helyezheti a virtuális gépeket az egyes szinteken egy rendelkezésre állási csoportban.
• Az adatbázisszint konfigurálható Always On rendelkezésre állási csoportok használatára. Ezzel az SQL Server-konfigurációval a rendelkezésre állási csoportban egy elsődleges olvasási/írási replika legfeljebb nyolc másodlagos írásvédett replikával van konfigurálva. Ha probléma merül fel az elsődleges replikával kapcsolatban, a rendelkezésre állási csoport az elsődleges olvasási/írási tevékenységet az egyik másodlagos replikán nem tudja elvégezni, így az alkalmazás továbbra is elérhető marad. További információ: Always On rendelkezésre állási csoportok áttekintése az SQL Serverhez.
• Vészhelyreállítási forgatókönyvek esetén konfigurálhatja az SQL Always On aszinkron natív replikációt a vészhelyreállításhoz használt célrégióba. Az Azure Site Recovery replikációját a célrégióba is konfigurálhatja, ha az adatváltozási arány az Azure Site Recovery támogatott korlátain belül van.
• A felhasználók a traffic manager végpontján keresztül férnek hozzá az előtérbeli ASP.NET webes szinthez.
• A forgalomkezelő átirányítja a forgalmat az elsődleges nyilvános IP-végpontra az elsődleges forrásrégióban.
• A nyilvános IP-cím átirányítja a hívást az egyik webes szintű virtuálisgép-példányra egy nyilvános terheléselosztón keresztül. Minden webes szintű virtuálisgép-példány egy alhálózatban található.
• A webes szintű virtuális gépről a rendszer minden hívást egy belső terheléselosztón keresztül irányít át az üzleti réteg egyik virtuálisgép-példányára feldolgozás céljából. Minden üzleti szintű virtuális gép külön alhálózatban található.
• A művelet feldolgozása az üzleti szinten történik, és az ASP.NET alkalmazás egy háttérszinten csatlakozik a Microsoft SQL Server-fürthöz egy Azure-beli belső terheléselosztón keresztül. Ezek a háttérbeli SQL Server-példányok külön alhálózatban találhatók.
• A traffic manager másodlagos végpontja nyilvános IP-címként van konfigurálva a vészhelyreállításhoz használt célrégióban.
• Elsődleges régió megszakadása esetén meghívja az Azure Site Recovery feladatátvételét, és az alkalmazás aktívvá válik a célrégióban.
• A traffic manager végpontja automatikusan átirányítja az ügyfélforgalmat a célrégió nyilvános IP-címére.

Összetevők

• A rendelkezésre állási csoportok hibatűrési funkciók, amelyek biztosítják, hogy a virtuális gépek több elkülönített hardvercsomópont között legyenek elosztva egy fürtben. Ebben az architektúrában a rendelkezésre állási csoportok védelmet nyújtanak a hardver- és szoftverhibák ellen azáltal, hogy biztosítják, hogy a kimaradás csak a virtuális gépek egy részhalmazára legyen hatással. Ez a megközelítés fenntartja az alkalmazások rendelkezésre állását és működési folytonosságát a többrétegű alkalmazásokban.

• A rendelkezésre állási zónák különálló fizikai helyek egy Azure-régión belül, amelyek megvédik az alkalmazásokat és az adatokat az adatközpontok hibáitól. Ebben az architektúrában a rendelkezésre állási zónák nagyobb rugalmasságot biztosítanak azáltal, hogy virtuális gépeket osztanak szét több adatközpont között, független energiaellátással, hűtéssel és hálózati infrastruktúrával.

• Az Azure Load Balancer egy 4. rétegbeli terheléselosztó, amely a meghatározott szabályok és állapotminták alapján osztja el a bejövő forgalmat a nagy átviteli sebesség és az alacsony késés érdekében. Ebben az architektúrában a nyilvános terheléselosztó elosztja a bejövő ügyfélforgalmat a webes szintű virtuális gépek között, míg a belső terheléselosztók a webes szintről az üzleti szintre, az üzleti szintről pedig a háttérbeli SQL Server-fürtre irányítják a forgalmat.

• Az Azure Traffic Manager egy DNS-alapú forgalom terheléselosztó, amely elosztja a forgalmat a globális Azure-régiók között. Ebben az architektúrában a Traffic Manager globális terheléselosztást biztosít azáltal, hogy a felhasználói forgalmat a normál műveletek során az elsődleges régióba irányítja, és automatikusan átirányítja a forgalmat a vészhelyreállítási régióba a kimaradások során.

• A Site Recovery egy vészhelyreállítási szolgáltatás, amely lehetővé teszi a virtuális gépek replikálást egy másik Azure-régióba az üzletmenet folytonossága és a vészhelyreállítás érdekében. Ebben az architektúrában a Site Recovery lehetővé teszi a vészhelyreállítási képességeket azáltal, hogy a virtuális gépeket egy célrégióba replikálja az alkalmazás helyreállításához a forrásrégiók leállása során. Emellett rendszeres vészhelyreállítási próbákkal támogatja a megfelelőségi követelményeket.

Alternatívák

• A Windowst más operációs rendszerek is lecserélhetik, mert az infrastruktúrában semmi sem függ az operációs rendszertől.
• A Linuxhoz készült SQL Server lecserélheti a háttéradattárat.
• Az adatbázist bármely elérhető szabványos adatbázis-alkalmazás helyettesítheti.

Forgatókönyv részletei

Ez a forgatókönyv egy ASP.NET és a Microsoft SQL Servert használó több-bérlős alkalmazást mutat be. A rendelkezésre állási zónákat támogató Azure-régiókban üzembe helyezheti a virtuális gépeket egy forrásrégióban a rendelkezésre állási zónák között, és replikálhatja a virtuális gépeket a vészhelyreállításhoz használt célrégióba. A rendelkezésre állási zónákat nem támogató Azure-régiókban üzembe helyezheti a virtuális gépeket egy rendelkezésre állási csoportban , és replikálhatja a virtuális gépeket a célrégióba.

A régiók közötti forgalom irányításához globális terheléselosztóra van szükség. Két fő Azure-ajánlat létezik:

• Azure Front Door
• Azure Traffic Manager

Terheléselosztó kiválasztásakor vegye figyelembe a két ajánlat követelményeit és funkciókészletét. Milyen gyorsan szeretné elvégezni a feladatátvételt? Át tudja venni a TLS-kezelés többletterhelését? Vannak szervezeti költségkorlátozások?

A Front Door 7. rétegbeli képességei: SSL-kiszervezés, útvonalalapú útválasztás, gyors feladatátvétel, gyorsítótárazás és egyéb funkciók az alkalmazások teljesítményének és magas rendelkezésre állásának javítása érdekében. Gyorsabb csomagutazási időket tapasztalhat, mert az infrastruktúra hamarabb van előkészítve az Azure-hálózatra.

Mivel a Front Door új ugrást ad hozzá, további biztonsági műveletek is vannak. Ha az architektúra megfelel a jogszabályi követelményeknek, korlátozások lehetnek a további forgalmi TLS-végpontra vonatkozóan. A Front Door által kiválasztott TLS-titkosítási csomagoknak meg kell felelniük a szervezet biztonsági sávjának. Emellett a Front Door elvárja, hogy a háttérszolgáltatások a Microsoft megbízható hitelesítésszolgáltatói listájának részét képező tanúsítványokat használják.

Egy másik szempont a költség. Az architektúrának ki kell használnia a széles körű szolgáltatáskészletet (nem csak a feladatátvételt), hogy igazolja a hozzáadott költségeket.

A Traffic Manager egy DNS-alapú terheléselosztási szolgáltatás. Az egyensúly és a feladatátvétel csak DNS-szinten működik. Emiatt nem tud olyan gyorsan feladatátvételt végrehajtani, mint a Front Door, mert gyakori problémák merülnek fel a DNS-gyorsítótárazás és a DNS-TCL-ek tiszteletben nem álló rendszerei között.

Szükség esetén mindkét terheléselosztót kombinálhatja. Szeretné például a DNS-alapú feladatátvételt, de pop-felületet szeretne hozzáadni a forgalom által felügyelt infrastruktúra előtt.

Ez az architektúra a Traffic Managert használja, mert könnyű. A feladatátvétel időzítése elegendő szemléltető célokra.

Megfontolások

Ezek a szempontok implementálják az Azure Well-Architected Framework alappilléreit, amely a számítási feladatok minőségének javítására használható vezérelvek készlete. További információ: Well-Architected Framework.

Biztonság

A biztonság biztosítékokat nyújt a szándékos támadások és az értékes adatokkal és rendszerekkel való visszaélés ellen. További információkért lásd a Biztonsági terv felülvizsgálati ellenőrzőlistát.

Az előtérbeli alkalmazásszintre irányuló összes virtuális hálózati forgalmat hálózati biztonsági csoportok védik. A szabályok korlátozzák a forgalom áramlását, hogy csak az előtérbeli alkalmazásszintű virtuálisgép-példányok férhessenek hozzá a háttéradatbázis-szinthez. Az üzleti szintről vagy az adatbázisszintről nem engedélyezett kimenő internetes forgalom. A támadási lábnyom csökkentése érdekében nincsenek nyitva közvetlen távoli felügyeleti portok. További információ: Azure hálózati biztonsági csoportok.

A biztonságos forgatókönyvek tervezésével kapcsolatos általános útmutatásért tekintse meg az Azure biztonsági dokumentációját.

Költségoptimalizálás

A költségoptimalizálás a szükségtelen kiadások csökkentésére és a működési hatékonyság javítására összpontosít. További információt a Költségoptimalizálás tervezési felülvizsgálati ellenőrzőlistájában talál.

Az Azure-beli virtuális gépek vészhelyreállításának Azure Site Recovery használatával történő konfigurálása folyamatosan a következő díjakat fogja terhelni.

• Az Azure Site Recovery licencelési költsége virtuális gépenként.
• A hálózati kimenő költségek a forrás virtuálisgép-lemezekről egy másik Azure-régióba történő adatváltozások replikálásához. Az Azure Site Recovery beépített tömörítéssel körülbelül 50%-kal csökkenti az adatátviteli követelményeket.
• Tárolási költségek a helyreállítási helyen. Ez általában megegyezik a forrásrégió tárterületével, valamint a helyreállítási pontok helyreállítási pillanatképekként való fenntartásához szükséges további tárterületekkel.

Biztosítottunk egy költségkalkulátort egy háromrétegű alkalmazás vészhelyreállításának konfigurálásához hat virtuális gép használatával. Az összes szolgáltatás előre konfigurálva van a költségkalkulátorban. Annak megtekintéséhez, hogy az adott használati eset díjszabása hogyan változna, módosítsa a megfelelő változókat a költség becsléséhez.

Teljesítményhatékonyság

A teljesítményhatékonyság azt jelenti, hogy a számítási feladat hatékonyan képes méretezni a felhasználói igényeket. További információt a Teljesítményhatékonyság tervezési felülvizsgálati ellenőrzőlistájában talál.

A skálázási követelményeknek megfelelően minden szinten hozzáadhat vagy eltávolíthat virtuális gépeket. Mivel ez a forgatókönyv terheléselosztókat használ, további virtuális gépeket adhat hozzá egy szinthez anélkül, hogy az alkalmazás üzemidejét befolyásolná.

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerző:

• Sujay Talasila | Egyszerű termék érdeklődője

Következő lépések

• A Traffic Manager üzembe helyezése az Azure-ban
• Vészhelyreállítás beállítása Azure-beli virtuális gépekhez

Kapcsolódó erőforrások

További magas rendelkezésre állási és vészhelyreállítási referenciaarchitektúrákért lásd:

• Többrégiós terheléselosztás