Az egyes Azure-szolgáltatások rugalmasságára vonatkozó ellenőrzőlista
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 automatizált biztonsági mentéseket. További információ: Azure App Service csomagok részletes áttekintése
Kerülje a vertikális 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 vertikális fel- és leskálázás elindíthatja az alkalmazás újraindítását.
Tárolja a konfigurációt alkalmazásbeállításokként. Alkalmazásbeállítások használata a konfigurációs beállítások alkalmazásbeállításként való tárolásához. Definiálja a Resource Manager sablonok beállításait, vagy használja a PowerShellt, hogy azokat egy megbízhatóbb, automatizált üzembe helyezési/frissítési folyamat részeként alkalmazza. További információ: Webalkalmazások konfigurálása Azure App Service.
Hozzon létre külön App Service terveket az éles környezethez és a teszteléshez. Ne használjon tárolóhelyeket az éles környezetben a teszteléshez. Az ugyanazon App Service csomagban lévő összes alkalmazás ugyanazokat a virtuálisgép-példányokat használja. Ha az éles és tesztelési üzemelő példányokat ugyanabban a csomagban helyezi üzembe, az negatív hatással lehet az éles üzembe helyezésre. A terheléses tesztek például ronthatják az élő éles üzem helyét. Ha a teszttelepítéseket egy 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 először nincs szüksége erre a skálázhatósági szintre, üzembe helyezheti az alkalmazásokat ugyanabban a csomagban, é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 App Service csomagok zónaredundánsként helyezhetők üzembe, ami azt jelenti, hogy a példányok automatikusan el vannak osztva a rendelkezésre állási zónák között. App Service automatikusan elosztja 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ó: App Service migrálása a rendelkezésre állási zónába támogatás.
Ne használja az App Service biztonsági mentési funkciót Azure SQL adatbázisok biztonsági mentéséhez. Ehelyett használjon SQL Database automatikus biztonsági mentéseket. App Service biztonsági mentés egy SQL BACPAC-fájlba exportálja az adatbázist, amely dTU-kba kerül.
Az üzembe helyezést egy előkészítési ponton végezze. Hozzon létre egy üzembehelyezési pontot az előkészítéshez. Telepítse 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. Azt is biztosítja, hogy az összes példány felmelegedjön, mielőtt éles környezetbe váltanak. Számos alkalmazás rendelkezik jelentős bemelegítési és hidegindítási idővel. További információ: Átmeneti környezetek beállítása webalkalmazásokhoz Azure App Service.
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-tárolóhelyre. Ez megkönnyíti a rossz üzembe helyezés visszaállítását. Ha később észlel problémát, gyorsan visszaállíthatja az LKG-verziót. 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 App Service
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 a naplókhoz és az alkalmazásadatokhoz. Ez segít megakadályozni, hogy a naplózás csökkentse az alkalmazás teljesítményét.
Teljesítmény monitorozása. Egy teljesítményfigyelő szolgáltatás, például a New Relic vagy az Application Insights használatával monitorozza az alkalmazások teljesítményét és viselkedését terhelés alatt. A teljesítménymonitorozá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áltozat lehetőséget. 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. Emellett standard Load Balancer támogatja a globális terheléselosztást, így az alkalmazásra sem lesz hatással 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ánysal a háttérrendszerben. Egyetlen példány egyetlen meghibásodási pontot eredményezhet. A méretezéshez érdemes lehet párosítani az LB-t Virtual Machine Scale Sets.
Kimenő szabályok használata. A kimenő szabályok biztosítják, hogy az SNAT-port elfogyása miatt ne ütközzenek csatlakozási hibákba. További információ a kimenő kapcsolatokról. Bár a kimenő szabályok segítenek javítani a megoldást a kis és a közepes méretű üzemelő példányok esetében, az éles számítási feladatok esetében javasoljuk, hogy kapcsolják össze standard Load Balancer vagy bármely alhálózati üzembe helyezést a VNet NAT-tal.
Application Gateway
Legalább két példány kiépítése. Helyezze üzembe a Application Gateway legalább két példánysal. 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. Az SLA-ra való jogosultsághoz 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álatakor 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 a rendszer automatikusan feladatátvételt hajt végre. 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énik, egy másik replikából olvashat. Ezt az ügyféloldali SDK automatikusan kezeli. Az írási régiót egy másik régióba is átadhatja. További információ: Globális adatterjesztés az Azure Cosmos DB-vel.
Event Hubs
Ellenőrzőpontok használata. Az eseményfelhasználónak meg kell írnia 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 fel lesznek dolgozva. Ezért az üzenetfeldolgozási logikának idempotensnek kell lennie, vagy az alkalmazásnak képesnek kell lennie az üzenetek deduplikációjára.
Kivételek kezelése. Az eseményfelhasználók általában egy hurokban dolgoznak fel egy üzenetköteget. Az ebben a feldolgozási ciklusban lévő kivételeket kell kezelnie, hogy ne veszítsen el egy teljes üzenetköteget, ha egyetlen üzenet kivételt okoz.
Használjon kézbesíthetetlen üzenetsort. Ha egy üzenet feldolgozása nem átmeneti hibát eredményez, helyezze az üzenetet egy kézbesíthetetlen üzenetsorba, hogy nyomon tudja követni az állapotot. A forgatókönyvtől függően később újrapróbálkozhat az üzenettel, kompenzáló tranzakciót alkalmazhat, vagy egyéb műveletet hajthat végre. Vegye figyelembe, hogy az Event Hubs nem rendelkezik beépített kézbesíthetetlen üzenetsor-funkciókkal. Az Azure Queue Storage vagy a Service Bus használatával kézbesíthetetlen üzeneteket tartalmazó üzenetsort implementálhat, vagy használhat Azure Functions vagy más eseményvezérelt mechanizmust.
Zónaredundancia konfigurálása. Ha a zónaredundancia engedélyezve van a névtéren, 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 történő 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, Azure Cache for Redis a gyorsítótárat üzemeltető virtuális gépeket több rendelkezésre állási zónában is elosztja. A zónaredundancia magas rendelkezésre állást és hibatűrést biztosít adatközpont-leállás esetén. További információ: Zónaredundancia engedélyezése Azure Cache for Redis.
Georeplikáció konfigurálása. A georeplikáció 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áció konfigurálása Azure Cache for Redis
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 betölthet. További információ: Adatmegőrzés konfigurálása prémium szintű Azure Cache for Redis
Ha a Azure Cache for Redis ideiglenes adat-gyorsítótárként használja, és nem állandó tárolóként, előfordulhat, hogy ezek a javaslatok nem érvényesek.
Cognitive Search
Több replika kiépítése. Használjon legalább két replikát az olvasási magas rendelkezésre állá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. Ezzel a módszerrel a szolgáltatás akkor is működőképes marad, ha az adatközpont kimarad. További információ: Megbízhatóság a Azure Cognitive Search
Indexelők konfigurálása többrégiós üzemelő példányokhoz. Ha többrégiós üzemelő példánysal rendelkezik, fontolja meg az indexelés folytonosságának lehetőségeit.
Ha az adatforrás georeplikálva van, általában az egyes regionális Azure Cognitive Search szolgáltatások minden indexelőjét a helyi adatforrás-replikára kell mutatnia. Ez a megközelítés azonban nem ajánlott az Azure SQL Database-ben tárolt nagyméretű adathalmazokhoz. Ennek az az oka, hogy Azure Cognitive Search nem végezhet növekményes indexelést 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 mutasson a Azure Cognitive Search indexelőkre az új elsődleges replikára.
Ha az adatforrás nincs georeplikálva, mutasson több indexelőt ugyanarra az adatforrásra, hogy a Azure Cognitive Search több régióban lévő szolgáltatásokat folyamatosan és az adatforrástól függetlenül indexelje. További információ: Az Azure Search teljesítményével és optimalizálásával kapcsolatos szempontok.
Service Bus
Prémium szint használata é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 szintű ügyfelek számára érhetők el. Az üzenetküldé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ő azonnal meghiúsul egy üzenet elküldése után, 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 kétszer is elküldheti ugyanazt az üzenetet a rendszernek. A Service Bus képes kezelni ezt a problémát a duplikált elemek észlelésének engedélyezésével. 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 (a feladóknak és a fogadóknak) kezelnie kell ezeket a kivételeket a kódban. Ez különösen fontos a kötegelt feldolgozá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 segítségével kiválaszthatja az alkalmazásokhoz legmegfelelőbb újrapróbálkozési szabályzatot. Az alapértelmezett szabályzat az, hogy 9 maximális újrapróbálkozási kísérletet engedélyezzen, és várjon 30 másodpercet, de ez tovább módosítható. További információ: Újrapróbálkozési szabályzat – Service Bus.
Használjon kézbesíthetetlen üzenetsort. Ha egy üzenet többszöri újrapróbálkozás után nem dolgozható fel vagy nem kézbesíthető egyetlen fogadónak sem, a rendszer áthelyezi a kézbesítetlen levelek várólistára. Implementáljon egy folyamatot, amely beolvassa az üzeneteket a kézbesítetlen levelek üzenetsorából, megvizsgálja őket, és orvosolja a problémát. A forgatókönyvtől függően előfordulhat, hogy újrapróbálkozhat az üzenetsel, módosításokat hajthat végre, majd újrapróbálkozhat, vagy elvetheti az üzenetet. További információ: A Service Bus kézbesíthetetlen ü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ókért lásd: Ajánlott eljárások az alkalmazások Service Bus-kimaradások és katasztrófák elleni szigetelésével kapcsolatban.
Használja a Geo-Disaster Recoveryt. A georedundáns vészhelyreá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 katasztrófa miatt egy teljes Azure-régió vagy -adatközpont elérhetetlenné válik. További információ: Azure Service Bus Geo-vészhelyreállítás.
Tárolás
Használjon zónaredundáns tárolást. A zónaredundáns tárolás (ZRS) szinkron módon másolja az adatokat három Azure rendelkezésre állási zónába az elsődleges régióban. Ha egy rendelkezésre állási zóna szolgáltatáskimaradást tapasztal, az Azure Storage automatikusan átvesz egy másik zónát. További információ: Azure Storage-redundancia.
Georedundancia használatakor konfigurálja az olvasási hozzáférést. Ha többrégiós architektúrát használ, használjon megfelelő tárolási szintet a globális redundancia érdekében. 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ó csak olvasási hozzáférést biztosít az adatokhoz a másodlagos régióban. Ha az elsődleges régióban tárterületkimaradá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 megfelelően el vannak különítve egymástól az egyes meghibásodási pontok elkerülése érdekében. Emellett a felügyelt lemezekre nem vonatkoznak a tárfiókban létrehozott VHD-k 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 várólistát egy másik régióban. A Queue Storage esetében az írásvédett replika használata korlátozott, mert nem tud elemeket várólistára vagy lekérdezni. Ehelyett hozzon létre egy biztonsági mentési üzenetsort egy másik régióban lévő tárfiókban. Azure Storage-szolgáltatáskimaradá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 szolgáltatáskimaradás során.
SQL Database
Használja a Standard vagy a Prémium szintet. Ezek a szintek hosszabb időponthoz kötött visszaállítási időszakot biztosítanak (35 nap). További információ: SQL Database lehetőségek és teljesítmény.
Engedélyezze SQL Database naplózást. A naplózással rosszindulatú támadásokat vagy emberi hibákat diagnosztizálhat. További információ: Ismerkedés az SQL-adatbázis naplózásával.
Aktív georeplikáció használata Az Active Geo-Replication használatával létrehozhat egy olvasható másodlagost 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 aktív georeplikáció.
Horizontális skálázás használata. Fontolja meg horizontális particionálás használatát az adatbázis horizontális particionálásához. A horizontális skálázás hibaelkülönítést biztosíthat. További információ: Horizontális felskálázás Azure SQL Database használatával.
Az időponthoz kötött visszaállítás használata az emberi hibák 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 mentések használatával.
Szolgáltatáskimaradás utáni helyreállítás georedundáns visszaállítással. A georedundáns visszaállítás visszaállít egy adatbázist egy georedundáns biztonsági másolatból. További információ: Azure SQL-adatbázis helyreállítása automatikus adatbázis-biztonsági mentések használatával.
Azure Synapse Analytics
Ne tiltsa le a georedundáns biztonsági mentést. Alapértelmezés szerint a Synapse Analytics 24 óránként készít teljes biztonsági másolatot az adatokról a vészhelyreállításhoz. Nem ajánlott kikapcsolni ezt a funkciót. További információ: Georedundáns biztonsági mentések.
virtuális gépen futó SQL Server
Replikálja az adatbázist. Az adatbázis replikálásához használja SQL Server Always On rendelkezésre állási csoportokat. Magas rendelkezésre állást biztosít, ha egy SQL Server példány meghibásodik. További információ: Windows rendszerű virtuális gépek futtatása N szintű alkalmazáshoz
Biztonsági másolatot készít az adatbázisról. Ha már Azure Backup használ a virtuális gépek biztonsági mentéséhez, fontolja meg a Azure Backup használatát SQL Server számítási feladatokhoz a DPM használatával. Ezzel a megközelítéssel egy biztonsági mentési rendszergazdai szerepkör áll rendelkezésre a szervezet számára, valamint egy egységes helyreállítási eljárás a virtuális gépekhez és a SQL Server. Ellenkező esetben használja SQL Server Felügyelt biztonsági mentést 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 az automatikus feladat-visszavétel helyett. A feladat-visszaállás előtt ellenőrizze, hogy az összes alkalmazásalrendszer kifogástalan állapotban van-e. Ellenkező esetben olyan helyzetet hozhat létre, amikor az alkalmazás oda-vissza vált 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.
Hozzon létre egy állapotadat-mintavételi végpontot. Hozzon létre egy egyéni végpontot, amely jelentést készít az alkalmazás általános állapotáról. Ez lehetővé teszi, hogy a Traffic Manager feladatátvételt végezzen el, ha valamelyik kritikus útvonal meghibásodik, 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égpont monitorozása és feladatátvétele.
Virtual Machines
Ne futtasson éles számítási feladatot egyetlen virtuális gépen. Egyetlen virtuális gép üzembe helyezése nem rugalmas a tervezett vagy nem tervezett karbantartásokkal szemben. Ehelyett helyezzen több virtuális gépet egy rendelkezésre állási csoportba vagy virtuálisgép-méretezési csoportba, előtte egy terheléselosztóval.
A virtuális gép kiépítésekor adjon meg egy rendelkezésre állási csoportot. Jelenleg nem lehet virtuális gépet hozzáadni egy rendelkezésre állási csoporthoz a virtuális gép kiépítése után. Amikor ú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. Az 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ányok (FD-k) és frissítési tartományok (UD) között vannak elhelyezve. Az FD-k és 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. Ha azure-beli virtuális gépeket replikál 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 biztosít helyreállítási időkorlátot (RPO). A vészhelyreállítási próbákat annyiszor végezheti el, amennyit csak szeretne, anélkül, hogy az hatással van az éles alkalmazásra vagy a folyamatban lévő replikációra. További információ: Vészhelyreállítási próbák futtatása az Azure-ban.
Válassza ki a megfelelő virtuálisgép-méretet a teljesítménykövetelmények alapján. Egy meglévő számítási feladat Azure-ba való áthelyezésekor kezdje a virtuálisgép-mérettel, amely a legközelebb esik a helyszíni kiszolgálókhoz. 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ának figyelembevételével, é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 VHD-khez.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 megfelelően el vannak különítve egymástól az egyes meghibásodási pontok elkerülése érdekében. Emellett a felügyelt lemezekre nem vonatkoznak a tárfiókban létrehozott VHD-k IOPS-korlátai. További információ: Windows rendszerű virtuális gépek rendelkezésre állásának kezelése az Azure-ban.
Telepítse az alkalmazásokat egy adatlemezre, ne az operációsrendszer-lemezre. Ellenkező esetben elérheti a lemezméretkorlátot.
A virtuális gépek biztonsági mentéséhez használja a Azure Backup. 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úra-naplókat és rendszerindítási diagnosztikát is tartalmazhat. A rendszerindítási diagnosztikák segíthetnek diagnosztizálni a rendszerindítási hibákat, 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: Azure Monitor és rövid útmutató: Azure Monitor.
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. Load Balancer állapottesztek HTTP- vagy TCP-teszteket is tesztelhetnek. Ha egy virtuális gép HTTP-kiszolgálót futtat, a HTTP-mintavétel jobb állapotmutatója, mint a TCP-mintavételnek. 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ó: Azure Load Balancer áttekintés.
Ne tiltsa le az állapotadat-mintavételt. Az Load Balancer állapotadat-mintavétel egy ismert IP-címről (168.63.129.16) érkezik. A tűzfalszabályzatokban és a hálózati biztonsági csoportok szabályaiban ne tiltsa le az IP-címre irányuló vagy onnan érkező forgalmat. Az állapotadat-mintavétel blokkolása miatt a terheléselosztó eltávolítja a virtuális gépet a rotációból.
Engedélyezze Load Balancer naplózást. A naplók azt mutatják, hogy a háttérrendszer virtuális gépei közül hány nem fogad hálózati forgalmat a sikertelen mintavételi válaszok miatt. További információ: Log Analytics for Azure Load Balancer.