Az egyes Azure-szolgáltatások rugalmasságára vonatkozó ellenőrzőlista

  • Cikk

A rugalmasság a rendszer azon képessége, hogy a hibák után helyreálljon, és folytassa a működést. Minden technológia saját meghibásodási módokkal rendelkezik, amelyeket figyelembe kell vennie az alkalmazás tervezésekor és megvalósításakor. Ezzel az ellenőrzőlistával áttekintheti az egyes Azure-szolgáltatások rugalmassági szempontjait. A rugalmas alkalmazások tervezésével kapcsolatos további információkért lásd : Megbízható Azure-alkalmazások tervezése.

App Service

Használja a Standard vagy a Premium szintet. Ezek a szintek támogatják az átmeneti tárolóhelyeket és az automatikus biztonsági mentéseket. További információ: Azure-alkalmazás szolgáltatáscsomagok részletes áttekintése

Kerülje a fel- vagy leskálázást. Ehelyett válasszon ki egy olyan réteget és példányméretet, amely megfelel a teljesítménykövetelményeknek a tipikus terhelés alatt, majd skálázza fel a példányokat a forgalommennyiség változásainak kezeléséhez. A fel- és leskálázás elindíthatja az alkalmazás újraindítását.

A konfiguráció tárolása alkalmazásbeállításokként. Az alkalmazásbeállítások használatával alkalmazásbeállításokként tárolhatja a konfigurációs beállításokat. Adja meg a Resource Manager-sablonok beállításait, vagy használja a PowerShellt, hogy azokat egy automatizált üzembe helyezési/frissítési folyamat részeként alkalmazza, amely megbízhatóbb. További információ: Webalkalmazások konfigurálása Azure-alkalmazás Szolgáltatásban.

Hozzon létre külön App Service-csomagokat az éles környezethez és a teszteléshez. Ne használjon tárolóhelyeket az éles környezetben a teszteléshez. Az ugyanabban az App Service-csomagban lévő összes alkalmazás ugyanazokat a virtuálisgép-példányokat használja. Ha ugyanabban a csomagban helyezi üzembe az éles és tesztelési üzemelő példányokat, az negatív hatással lehet az éles üzembe helyezésre. A terheléses tesztek például ronthatják az élő éles telephelyet. Ha a teszttelepítéseket külön csomagba helyezi, elkülöníti őket az éles verziótól.

Különítse el a webalkalmazásokat a webes API-któl. Ha a megoldás webes előtérrel és webes API-val is rendelkezik, érdemes lehet külön App Service-alkalmazásokba bontani őket. Ez a kialakítás megkönnyíti a megoldás számítási feladatok szerinti felbontását. A webalkalmazást és az API-t külön App Service-csomagokban futtathatja, így egymástól függetlenül skálázhatók. Ha elsőre nincs szüksége ilyen szintű méretezhetőségre, az alkalmazásokat ugyanabba a csomagba helyezheti, és szükség esetén később külön csomagokba helyezheti őket.

Zónaredundáns App Service-csomagok üzembe helyezése. A támogatott régiókban az App Service-csomagok zónaredundánsként telepíthetők, ami azt jelenti, hogy a példányok automatikusan el vannak osztva a rendelkezésre állási zónák között. Az App Service automatikusan osztja el a forgalmat a zónák között, és kezeli a feladatátvételt, ha egy zóna leállást tapasztal. További információ: Az App Service migrálása a rendelkezésre állási zónába támogatás.

Kerülje az App Service biztonsági mentési funkciójának használatát az Azure SQL-adatbázisok biztonsági mentéséhez. Ehelyett használja az SQL Database automatikus biztonsági mentéseit. Az App Service biztonsági mentése exportálja az adatbázist egy SQL BACPAC-fájlba, amely dTU-kba kerül.

Deploy to a staging slot. Hozzon létre egy üzembehelyezési pontot az előkészítéshez. Helyezze üzembe az alkalmazásfrissítéseket az előkészítési ponton, és ellenőrizze az üzembe helyezést, mielőtt felcseréli őket az éles környezetbe. Ez csökkenti az éles környezetben történő rossz frissítés esélyét. Emellett biztosítja, hogy az összes példány felmelegedjön, mielőtt felcserélnénk őket az éles környezetbe. Számos alkalmazásnak jelentős bemelegítési és hidegindítási ideje van. További információ: Átmeneti környezetek beállítása webalkalmazásokhoz Azure-alkalmazás Szolgáltatásban.

Hozzon létre egy üzembehelyezési pontot az utolsó ismert jó (LKG) üzemelő példány tárolásához. Amikor üzembe helyez egy frissítést az éles környezetben, helyezze át az előző éles üzembe helyezést az LKG-pontba. Ez megkönnyíti a rossz üzembe helyezés visszaállítását. Ha később problémát észlel, gyorsan visszatérhet az LKG-verzióra. További információ: Alapszintű webalkalmazás.

Diagnosztikai naplózás engedélyezése, beleértve az alkalmazásnaplózást és a webkiszolgáló-naplózást. A naplózás fontos a monitorozás és a diagnosztika szempontjából. Lásd: Diagnosztikai naplózás engedélyezése webalkalmazásokhoz a Azure-alkalmazás Szolgáltatásban

Jelentkezzen be a Blob Storage-ba. Ez megkönnyíti az adatok gyűjtését és elemzését.

Hozzon létre egy külön tárfiókot a naplókhoz. Ne használja ugyanazt a tárfiókot naplókhoz és alkalmazásadatokhoz. Ez segít megakadályozni, hogy a naplózás csökkentse az alkalmazás teljesítményét.

Monitorozza a teljesítményt. Egy teljesítményfigyelő szolgáltatás, például a New Relic vagy az Application Elemzések használatával monitorozza az alkalmazás teljesítményét és viselkedését terhelés alatt. A teljesítményfigyelés valós idejű betekintést nyújt az alkalmazásba. Lehetővé teszi a problémák diagnosztizálását és a hibák kiváltó okának elemzését.

Azure Load Balancer

Válassza a Standard termékváltozatot. A Standard Load Balancer olyan megbízhatósági dimenziót biztosít, amelyet az Alapszintű nem – a rendelkezésre állási zónák és a zóna rugalmassága. Ez azt jelenti, hogy ha egy zóna lemegy, a zónaredundáns Standard Load Balancer nem lesz hatással. Ez biztosítja, hogy az üzemelő példányok ellenálljanak a régión belüli zónahibáknak. A Standard Load Balancer emellett támogatja a globális terheléselosztást is, így az alkalmazást sem érintik a régióhibák.

Legalább két példány kiépítése. Helyezze üzembe az Azure LB-t legalább két példánnyal 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 LB-t a virtuálisgép-méretezési csoportokkal.

Használjon kimenő szabályokat. A kimenő szabályok biztosítják, hogy az SNAT-portok kimerülése miatt ne legyen kapcsolati hibákkal szembesülni. További információ a kimenő kapcsolatokról. Bár a kimenő szabályok segítenek a kis és közepes méretű üzemelő példányok megoldásának javításában, az éles számítási feladatok esetében javasoljuk a Standard Load Balancer vagy bármely alhálózati üzembe helyezés összekapcsolását a VNet NAT-jával.

Application Gateway

Legalább két példány kiépítése. Helyezze üzembe az Application Gatewayt legalább két példánnyal. Egyetlen példány egyetlen meghibásodási pont. Használjon két vagy több példányt a redundancia és a méretezhetőség érdekében. Ahhoz, hogy jogosult legyen az SLA-ra, két vagy több közepes vagy nagyobb példányt kell kiépítenie.

Azure Cosmos DB

Zónaredundancia konfigurálása. Zónaredundancia használata esetén az Azure Cosmos DB szinkron módon replikálja az összes írást a rendelkezésre állási zónák között. Zónakimaradás esetén automatikusan meghiúsul. További információ: Magas rendelkezésre állás elérése az Azure Cosmos DB-vel.

Replikálja az adatbázist régiók között. Az Azure Cosmos DB lehetővé teszi, hogy tetszőleges számú Azure-régiót társítson egy Azure Cosmos DB-adatbázisfiókhoz. Egy Azure Cosmos DB-adatbázis egy írási régióval és több olvasási régióval rendelkezhet. Ha az írási régióban hiba történt, egy másik replikából olvashat. Ezt az ügyféloldali SDK automatikusan kezeli. Az írási régiót másik régióba is átadhatja. További információ: Globális adatterjesztés az Azure Cosmos DB-vel.

Event Hubs

Használjon ellenőrzőpontokat. Az eseményfelhasználónak meg kell írnia az aktuális pozícióját az állandó tárolóba bizonyos előre meghatározott időközönként. Így, ha a fogyasztó hibát tapasztal (például a fogyasztó összeomlik, vagy a gazdagép meghibásodik), akkor egy új példány folytathatja a stream olvasását az utolsó rögzített pozícióból. További információ: Eseményfelhasználók.

Ismétlődő üzenetek kezelése. Ha egy eseményfogyó meghibásodik, az üzenetfeldolgozás az utolsó rögzített ellenőrzőpontról folytatódik. Az utolsó ellenőrzőpont után már feldolgozott üzenetek újra feldolgozásra kerülnek. Ezért az üzenetfeldolgozási logikának idempotensnek kell lennie, vagy az alkalmazásnak képesnek kell lennie az üzenetek deduplikálására.

Kivételek kezelése. Az eseményfelhasználók általában egy hurokban dolgoznak fel egy üzenetköteget. A feldolgozási ciklusban lévő kivételeket úgy kell kezelnie, hogy ne veszítsen el egy teljes üzenetköteget, ha egyetlen üzenet kivételt okoz.

Használjon üzenetsort. Ha egy üzenet feldolgozása nem átmeneti hibát eredményez, helyezze az üzenetet egy kézbesítetlen üzenetsorba, hogy nyomon tudja követni az állapotot. A forgatókönyvtől függően később újrapróbálkozhat, kompenzáló tranzakciót alkalmazhat, vagy más műveletet hajthat végre. Vegye figyelembe, hogy az Event Hubs nem rendelkezik beépített üzenetsor-funkcióval. Használhatja az Azure Queue Storage-t vagy a Service Bust a kézbesítetlen levelek üzenetsorának implementálásához, vagy használhatja az Azure Functionst vagy más esemény-kezelési mechanizmust.

Zónaredundancia konfigurálása. Ha a zónaredundancia engedélyezve van a névtérben, az Event Hubs automatikusan replikálja a módosításokat több rendelkezésre állási zóna között. Ha egy rendelkezésre állási zóna meghibásodik, a feladatátvétel automatikusan megtörténik. További információ: Rendelkezésre állási zónák.

Vészhelyreállítás megvalósítása másodlagos Event Hubs-névtérbe való feladatátvételsel. További információ: Azure Event Hubs Geo-vészhelyreállítás.

Azure Cache for Redis

Zónaredundancia konfigurálása. Ha a zónaredundancia engedélyezve van a gyorsítótárban, az Azure Cache for Redis elterjeszti a gyorsítótárat üzemeltető virtuális gépeket több rendelkezésre állási zónában. A zónaredundancia magas rendelkezésre állást és hibatűrést biztosít adatközpont-kimaradás esetén. További információ: Zónaredundancia engedélyezése az Azure Cache for Redishez.

Georeplikációs konfigurálás. A georeplikálás két prémium szintű Azure Cache for Redis-példány összekapcsolására szolgál. Az elsődleges gyorsítótárba írt adatok másodlagos írásvédett gyorsítótárba lesznek replikálva. További információ: Georeplikálás konfigurálása az Azure Cache for Redishez

Adatmegőrzés konfigurálása. A Redis-adatmegőrzés lehetővé teszi, hogy megőrizze a Redisben tárolt adatokat. Pillanatképeket is készíthet, és biztonsági másolatot készíthet az adatokról, amelyeket hardverhiba esetén tölthet be. További információ: Adatmegőrzés konfigurálása prémium szintű Azure Cache for Redishez

Ha az Azure Cache for Redist ideiglenes adatgyorsítótárként használja, és nem állandó tárolóként, előfordulhat, hogy ezek a javaslatok nem érvényesek.

Több replika kiépítése. Használjon legalább két replikát magas rendelkezésre állású olvasáshoz, vagy háromat az olvasási-írási magas rendelkezésre álláshoz.

Zónaredundancia használata. A Cognitive Search-replikákat több rendelkezésre állási zónában is üzembe helyezheti. Ez a megközelítés abban segít, hogy a szolgáltatás akkor is működőképes maradjon, ha adatközpont-kimaradások történnek. További információ: Megbízhatóság az Azure Cognitive Searchben

Indexelők konfigurálása többrégiós üzemelő példányokhoz. Ha többrégiós üzembe helyezéssel rendelkezik, fontolja meg az indexelés folytonosságának lehetőségeit.

  • Ha az adatforrás georeplikált, általában az egyes regionális Azure Cognitive Search szolgáltatás minden indexelőjét a helyi adatforrásreplikára kell mutatnia. Ez a megközelítés azonban nem ajánlott az Azure SQL Database-ben tárolt nagy adathalmazokhoz. Ennek az az oka, hogy az Azure Cognitive Search nem tud növekményes indexelést végezni másodlagos SQL Database-replikákból, csak elsődleges replikákból. Ehelyett mutasson az összes indexelőre az elsődleges replikára. Feladatátvétel után az Azure Cognitive Search indexelőit az új elsődleges replikára kell mutatni.

  • Ha az adatforrás nem georeplikált, mutasson több indexelőt ugyanarra az adatforrásra, hogy az Azure Cognitive Search szolgáltatás több régióban folyamatosan és függetlenül indexelje az adatforrást. További információkért tekintse meg az Azure Search teljesítményével és optimalizálási szempontjaival kapcsolatos szempontokat.

Service Bus

Prémium szintű használat éles számítási feladatokhoz. A Service Bus Premium Messaging dedikált és fenntartott feldolgozási erőforrásokat és memóriakapacitást biztosít a kiszámítható teljesítmény és az átviteli sebesség támogatásához. A prémium szintű üzenetkezelési szint olyan új funkciókhoz is hozzáférést biztosít, amelyek először csak a prémium ügyfelek számára érhetők el. Az üzenetkezelési egységek számát a várt számítási feladatok alapján határozhatja meg.

Ismétlődő üzenetek kezelése. Ha egy közzétevő közvetlenül az üzenet elküldése után meghiúsul, vagy hálózati vagy rendszerproblémákat tapasztal, előfordulhat, hogy hibásan nem rögzíti az üzenet kézbesítését, és ugyanazt az üzenetet kétszer is elküldheti a rendszernek. A Service Bus a duplikált észlelés engedélyezésével képes kezelni ezt a problémát. További információ: Duplikált észlelés.

Kivételek kezelése. Az üzenetkezelési API-k kivételeket hoznak létre felhasználói hiba, konfigurációs hiba vagy egyéb hiba esetén. Az ügyfélkódnak (feladóknak és fogadóknak) kezelnie kell ezeket a kivételeket a kódjukban. Ez különösen fontos a kötegfeldolgozásban, ahol a kivételkezeléssel elkerülhető egy teljes üzenetköteg elvesztése. További információ: Service Bus üzenetkezelési kivételek.

Próbálkozzon újra a szabályzattal. A Service Bus lehetővé teszi, hogy a legjobb újrapróbálkozési szabályzatot válassza az alkalmazásokhoz. Az alapértelmezett szabályzat a 9 maximális újrapróbálkozási kísérlet engedélyezése, és 30 másodpercig várni, de ez tovább módosítható. További információ: Újrapróbálkozési szabályzat – Service Bus.

Használjon üzenetsort. Ha egy üzenet nem dolgozható fel vagy nem kézbesíthető egyetlen fogadónak sem több újrapróbálkozás után, akkor a rendszer áthelyezi egy üzenetsorba. Implementáljon egy folyamatot, amely beolvassa a kézbesítetlen levelek üzenetsorából érkező üzeneteket, megvizsgálja őket, és elhárítja a problémát. A forgatókönyvtől függően előfordulhat, hogy újrapróbálkozza az üzenetet, módosítja és újrapróbálkozza, vagy elveti az üzenetet. További információ: A Service Bus kézbesítetlen levelek üzenetsorainak áttekintése.

Zónaredundancia használata. Ha a zónaredundancia engedélyezve van a névtéren, a Service Bus automatikusan replikálja a módosításokat több rendelkezésre állási zóna között. Ha egy rendelkezésre állási zóna meghibásodik, a feladatátvétel automatikusan megtörténik. További információ: Ajánlott eljárások az alkalmazások Service Bus-kimaradások és katasztrófák elleni szigetelésével kapcsolatban.

Geo-vészhelyreállítás használata. A georedundáns helyreállítás biztosítja, hogy az adatfeldolgozás továbbra is egy másik régióban vagy adatközpontban működjön, ha egy teljes Azure-régió vagy adatközpont katasztrófa miatt elérhetetlenné válik. További információ: Azure Service Bus Geo-vészhelyreállítás.

Storage

Zónaredundáns tárolás használata. Zónaredundáns tárolás (ZRS( – A ZRS az adatokat szinkron módon másolja három rendelkezésre állási Azure-zónában az elsődleges régióban. Ha egy rendelkezésre állási zóna leállást tapasztal, az Azure Storage automatikusan átesik egy másik zónába. További információ: Azure Storage-redundancia.

Georedundáns használata esetén konfigurálja az olvasási hozzáférést. Ha többrégiós architektúrát használ, a globális redundancia számára megfelelő tárolási szintet használjon. Az RA-GRS vagy az RA-GZRS használatával az adatok egy másodlagos régióba lesznek replikálva. Az RA-GRS helyileg redundáns tárolást (LRS) használ az elsődleges régióban, míg az RA-GZRS zónaredundáns tárolást (ZRS) használ az elsődleges régióban. Mindkét konfiguráció írásvédett hozzáférést biztosít az adatokhoz a másodlagos régióban. Ha az elsődleges régióban tárkimaradás van, az alkalmazás beolvassa az adatokat a másodlagos régióból, ha ezt a lehetőséget tervezte. További információ: Azure Storage-redundancia.

Virtuálisgép-lemezek esetén használjon felügyelt lemezeket.A felügyelt lemezek jobb megbízhatóságot biztosítanak a rendelkezésre állási csoportban lévő virtuális gépek számára, mivel a lemezek egymástól megfelelően el vannak különítve, hogy elkerüljék az egyes meghibásodási pontokat. Emellett a felügyelt lemezekre nem vonatkoznak a tárfiókban létrehozott virtuális merevlemezek IOPS-korlátai. További információ: Windows rendszerű virtuális gépek rendelkezésre állásának kezelése az Azure-ban.

A Queue Storage esetében hozzon létre egy biztonsági mentési üzenetsort egy másik régióban. A Queue Storage esetében az írásvédett replika korlátozottan használható, mert az elemek várólistára helyezése és lekérdezése nem lehetséges. Ehelyett hozzon létre egy biztonsági mentési üzenetsort egy másik régióban lévő tárfiókban. Azure Storage-leállás esetén az alkalmazás használhatja a biztonsági mentési üzenetsort, amíg az elsődleges régió újra elérhetővé nem válik. Így az alkalmazás továbbra is feldolgozhatja az új kéréseket a kimaradás során.

SQL Database

Használja a Standard vagy a Premium szintet. Ezek a szintek hosszabb időponthoz kötött visszaállítási időszakot (35 napot) biztosítanak. További információkért tekintse meg az SQL Database beállításait és teljesítményét.

Engedélyezze az SQL Database naplózását. A naplózással rosszindulatú támadásokat vagy emberi hibákat diagnosztizálhat. További információ: Ismerkedés az SQL Database naplózásával.

Az Aktív georeplikációs funkcióval az aktív georeplikációs funkcióval egy olvasható másodlagost hozhat létre egy másik régióban. Ha az elsődleges adatbázis meghibásodik, vagy egyszerűen offline állapotba kell helyezni, végezzen manuális feladatátvételt a másodlagos adatbázisba. A feladatátvételig a másodlagos adatbázis írásvédett marad. További információ: SQL Database Active GeoReplikációs szolgáltatás.

Használjon horizontális skálázást. Fontolja meg horizontális horizontális particionálást az adatbázis horizontális particionálásához. A horizontális skálázás hibaelkülönítést biztosít. További információ: Horizontális felskálázás az Azure SQL Database-lel.

Az időponthoz kötött visszaállítás használata az emberi hiba utáni helyreállításhoz. Az időponthoz kötött visszaállítás visszaadja az adatbázist egy korábbi időpontra. További információ: Azure SQL-adatbázis helyreállítása automatikus adatbázis-biztonsági másolatok használatával.

A szolgáltatáskimaradásból való helyreállítás georeduktúra-visszaállítással. A georedundáns visszaállítás georedundáns biztonsági másolatból állítja vissza az adatbázist. További információ: Azure SQL-adatbázis helyreállítása automatikus adatbázis-biztonsági másolatok használatával.

Azure Synapse Analytics

Ne tiltsa le a geo-biztonsági mentést. A Synapse Analytics alapértelmezés szerint 24 óránként készít teljes biztonsági másolatot az adatokról dedikált SQL-készletben vészhelyreállítás céljából. Nem ajánlott kikapcsolni ezt a funkciót. További információ: Geo-biztonsági mentések.

Virtuális gépen futó SQL Server

Biztonsági másolatot készít az adatbázisról. Ha már az Azure Backupot használja a virtuális gépek biztonsági mentéséhez, fontolja meg az Azure Backup használatát AZ SQL Server számítási feladataihoz a DPM használatával. Ezzel a megközelítéssel a szervezetnek egyetlen biztonsági mentési rendszergazdai szerepköre van, valamint egy egységes helyreállítási eljárás a virtuális gépekhez és az SQL Serverhez. Ellenkező esetben használja az SQL Server felügyelt biztonsági mentését a Microsoft Azure-ba.

Traffic Manager

Manuális feladat-visszavétel végrehajtása. A Traffic Manager feladatátvétele után végezze el a manuális feladat-visszavételt ahelyett, hogy automatikusan meghiúsult. A feladat-visszalépés előtt ellenőrizze, hogy az összes alkalmazásalrendszer kifogástalan állapotban van-e. Ellenkező esetben létrehozhat egy olyan helyzetet, amelyben az alkalmazás oda-vissza tükröz az adatközpontok között. További információ: Virtuális gépek futtatása több régióban a magas rendelkezésre állás érdekében.

Állapotadat-mintavételi végpont létrehozása. Hozzon létre egy egyéni végpontot, amely az alkalmazás általános állapotáról számol be. Ez lehetővé teszi, hogy a Traffic Manager feladatátvételt végezze el, ha bármelyik kritikus útvonal meghibásodik, és nem csak az előtérben. A végpontnak HTTP-hibakódot kell visszaadnia, ha bármely kritikus függőség nem kifogástalan vagy nem érhető el. Ne jelentse azonban a nem kritikus szolgáltatások hibáit. Ellenkező esetben előfordulhat, hogy az állapotadat-mintavétel feladatátvételt vált ki, ha nincs rá szükség, hamis pozitív értékeket hozva létre. További információ: Traffic Manager-végpontfigyelés és feladatátvétel.

Virtual Machines

Ne futtasson éles számítási feladatot egyetlen virtuális gépen. Egyetlen virtuálisgép-üzembe helyezés nem rugalmas a tervezett vagy nem tervezett karbantartással szemben. Ehelyett helyezzen több virtuális gépet egy rendelkezésre állási csoportba vagy virtuálisgép-méretezési csoportba egy terheléselosztóval.

Adja meg a rendelkezésre állási csoportot a virtuális gép kiépítésekor. Jelenleg nem lehet virtuális gépet hozzáadni egy rendelkezésre állási csoporthoz a virtuális gép üzembe helyezése után. Ha új virtuális gépet ad hozzá egy meglévő rendelkezésre állási csoporthoz, mindenképpen hozzon létre egy hálózati adaptert a virtuális géphez, és adja hozzá a hálózati adaptert a terheléselosztó háttércímkészletéhez. Ellenkező esetben a terheléselosztó nem irányítja a hálózati forgalmat az adott virtuális gépre.

Helyezze az egyes alkalmazásszinteket egy külön rendelkezésre állási csoportba. N szintű alkalmazásokban ne helyezze a különböző szintekről származó virtuális gépeket ugyanabba a rendelkezésre állási csoportba. A rendelkezésre állási csoportban lévő virtuális gépek tartalék tartományokban (FD-k) és frissítési tartományokban (UD) vannak elhelyezve. Az FD-k és az UD-k redundancia előnyének eléréséhez azonban a rendelkezésre állási csoportban lévő összes virtuális gépnek képesnek kell lennie ugyanazon ügyfélkérések kezelésére.

Virtuális gépek replikálása az Azure Site Recovery használatával. Amikor Azure-beli virtuális gépeket replikál a Site Recovery használatával, a rendszer folyamatosan replikálja az összes virtuálisgép-lemezt a célrégióba aszinkron módon. A helyreállítási pontok néhány percenként jönnek létre. Ez percek alatt egy helyreállítási pont célkitűzést (RPO) biztosít. A vészhelyreállítási próbákat tetszőleges alkalommal elvégezheti anélkül, hogy az hatással lenne az éles alkalmazásra vagy a folyamatban lévő replikációra. További információ: Vészhelyreállítási gyakorlat futtatása az Azure-ban.

Válassza ki a megfelelő virtuálisgép-méretet a teljesítménykövetelmények alapján. Meglévő számítási feladatok Azure-ba való áthelyezésekor kezdje a helyszíni kiszolgálókhoz legközelebbi virtuálisgép-mérettel. Ezután mérje meg a tényleges számítási feladat teljesítményét a PROCESSZOR, a memória és a lemez IOPS-jával kapcsolatban, és szükség esetén módosítsa a méretet. Ez segít biztosítani, hogy az alkalmazás a várt módon viselkedjen egy felhőkörnyezetben. Ha több hálózati adapterre is szüksége van, vegye figyelembe az egyes méretek hálózati adaptereinek korlátját.

Felügyelt lemezek használata virtuális merevlemezekhez.A felügyelt lemezek jobb megbízhatóságot biztosítanak a rendelkezésre állási csoportban lévő virtuális gépek számára, mivel a lemezek egymástól megfelelően el vannak különítve, hogy elkerüljék az egyes meghibásodási pontokat. Emellett a felügyelt lemezekre nem vonatkoznak a tárfiókban létrehozott virtuális merevlemezek IOPS-korlátai. További információ: Windows rendszerű virtuális gépek rendelkezésre állásának kezelése az Azure-ban.

Az alkalmazásokat ne az operációsrendszer-lemezre, hanem egy adatlemezre telepítse. Ellenkező esetben elérheti a lemezméret korlátját.

Az Azure Backup használatával készítsen biztonsági másolatot a virtuális gépekről. A biztonsági másolatok védelmet nyújtanak a véletlen adatvesztés ellen. További információ: Azure-beli virtuális gépek védelme Recovery Services-tárolóval.

Diagnosztikai naplók engedélyezése. Alapszintű állapotmetrikákat, infrastruktúranaplókat és rendszerindítási diagnosztikát is tartalmazhat. A rendszerindítási diagnosztika segíthet diagnosztizálni a rendszerindítási hibát, ha a virtuális gép nem indítható állapotba kerül. További információ: Az Azure diagnosztikai naplóinak áttekintése.

Konfigurálja az Azure Monitort. Gyűjtse össze és elemezze az Azure-beli virtuális gépek monitorozási adatait, beleértve a vendég operációs rendszert és a benne futó számítási feladatokat, lásd az Azure Monitort és az Azure Monitor rövid útmutatót.

Virtual Network

A nyilvános IP-címek engedélyezéséhez vagy letiltásához adjon hozzá egy hálózati biztonsági csoportot az alhálózathoz. Tiltsa le a rosszindulatú felhasználók hozzáférését, vagy csak olyan felhasználók hozzáférését engedélyezze, akik rendelkeznek jogosultsággal az alkalmazáshoz való hozzáféréshez.

Egyéni állapotadat-mintavétel létrehozása. A Load Balancer állapotmintái HTTP-t vagy TCP-t is tesztelhetnek. Ha egy virtuális gép HTTP-kiszolgálót futtat, a HTTP-mintavétel jobb állapotmutató, mint a TCP-mintavétel. HTTP-mintavételhez használjon egy egyéni végpontot, amely az alkalmazás általános állapotát jelenti, beleértve az összes kritikus függőséget is. További információkért tekintse meg az Azure Load Balancer áttekintését.

Ne tiltsa le az állapotmintát. A Load Balancer Health-mintavételt egy ismert IP-címről küldi a rendszer, 168.63.129.16. Ne tiltsa le az IP-címre irányuló vagy onnan érkező forgalmat tűzfalszabályzatokban vagy hálózati biztonsági csoportszabályokban. Az állapotadat-mintavétel blokkolásával a terheléselosztó eltávolítja a virtuális gépet a forgatásból.

Engedélyezze a Load Balancer naplózását. A naplók azt mutatják, hogy a háttérrendszeren hány virtuális gép nem fogad hálózati forgalmat a sikertelen mintavételi válaszok miatt. További információ: Log Analytics for Azure Load Balancer.