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

Megbízhatóság az Azure Filesban

Ez a cikk az Azure Files megbízhatósági támogatását ismerteti. Az Azure Files teljes mértékben felügyelt fájlmegosztásokat biztosít a felhőben, amelyek az iparági szabványnak megfelelő kiszolgálói üzenetblokk (SMB) és hálózati fájlrendszer (NFS) protokollokkal érhetők el.

Az Azure használatakor a megbízhatóság közös felelősség. A Microsoft számos lehetőséget kínál a rugalmasság és a helyreállítás támogatására. Ön a felelős azért, hogy megértse, hogyan működnek ezek a képességek az összes használt szolgáltatáson belül, és válassza ki azokat a képességeket, amelyekre szüksége van az üzleti célok és az üzemidő céljainak eléréséhez.

Ez a cikk azt ismerteti, hogyan teheti rugalmassá az Azure Filest számos lehetséges kimaradás és probléma esetén, beleértve az átmeneti hibákat, a rendelkezésre állási zónák kimaradását és a régiókimaradásokat. Azt is ismerteti, hogyan használható biztonsági másolatok más típusú problémákból való helyreállításra, és kiemeli az Azure Files szolgáltatásiszint-szerződéssel (SLA) kapcsolatos legfontosabb információkat.

Megjegyzés:

Az Azure Files az Azure Storage platform része. Az Azure Files egyes funkciói számos Azure Storage-szolgáltatásban gyakoriak. Ebben a cikkben az Azure Storage használatával hivatkozunk ezekre a gyakori képességekre.

Termelési üzembe helyezési javaslatok

Ha meg szeretné tudni, hogyan helyezheti üzembe az Azure Filest a megoldás megbízhatósági követelményeinek támogatásához, és hogyan befolyásolja a megbízhatóság az architektúra egyéb aspektusait, tekintse meg az Azure Files azure-Well-Architected-keretrendszerének ajánlott architektúrával kapcsolatos ajánlott eljárásait .

A megbízhatósági architektúra áttekintése

A helyileg redundáns tárolás (LRS) a tárfiókokban lévő adatokat egy vagy több, a választott elsődleges régióban található Azure rendelkezésre állási zónába replikálja. Bár nincs lehetőség az előnyben részesített rendelkezésre állási zóna kiválasztására, az Azure áthelyezheti vagy kibővítheti az LRS-fiókokat a zónák között a terheléselosztás javítása érdekében. Nincs garancia arra, hogy az adatok el lesznek osztva a zónák között. A rendelkezésre állási zónákkal kapcsolatos további információkért lásd: Mik azok a rendelkezésre állási zónák?.

Diagram, amely bemutatja, hogyan replikálja az adatokat a rendelkezésre állási zónákban az LRS használatával.

A zónaredundáns tárolás (ZRS), a georedundáns tárolás (GRS) és a georedundáns tárolás (GZRS) további védelmet nyújt. Ez a cikk részletesen ismerteti ezeket a beállításokat.

Az Azure Files két médiaszinten érhető el:

  • A prémium szintű szint SSD-meghajtókat (SSD) használ a nagy teljesítmény érdekében. Ez a szint alacsony késést igénylő számítási feladatokhoz ajánlott.

  • A Standard szint támogatja a merevlemez-meghajtókat (HDD). A HDD-fájlmegosztások költséghatékony tárolási lehetőséget biztosítanak az általános célú fájlmegosztásokhoz.

További információt az Azure Files – Storage-szintek üzembe helyezésének tervezése című témakörben talál.

Az Azure Files a tárfiók szintjén valósítja meg a redundanciát, a fájlmegosztások pedig automatikusan öröklik ezt a redundanciakonfigurációt. A szolgáltatás több olyan redundanciamodellt támogat, amelyek eltérnek az adatvédelemmel kapcsolatos megközelítésüktől.

Rugalmasság átmeneti hibákhoz

Az átmeneti hibák rövid, időszakos meghibásodások a komponensekben. Gyakran előfordulnak elosztott környezetben, például a felhőben, és ezek a műveletek szokásos részei. Az átmeneti hibák rövid idő elteltével kijavítják magukat. Fontos, hogy az alkalmazások kezelni tudják az átmeneti hibákat, általában az érintett kérések újrapróbálásával.

Minden felhőalapú alkalmazásnak követnie kell az Azure átmeneti hibakezelési útmutatóját, amikor a felhőben üzemeltetett API-kkal, adatbázisokkal és egyéb összetevőkkel kommunikálnak. További információ: Átmeneti hibák kezelésére vonatkozó javaslatok.

Az átmeneti hibák Azure Files használatakor történő hatékony kezeléséhez konfigurálja a fájlműveletek időtúllépési értékeit a fájlméret és a hálózati feltételek alapján. A nagyobb fájlok hosszabb időtúllépést igényelnek, míg a kisebb műveletek rövidebb értékeket használhatnak a hibák gyors észleléséhez.

Annak érdekében, hogy csak biztonságos kapcsolatok legyenek létesítve az NFS-megosztáshoz, javasoljuk, hogy konfiguráljon egy privát végpontot a tárfiókhoz. A privát végpont az Azure Private Link használatával rendel hozzá egy statikus IP-címet a tárfiókhoz a virtuális hálózat privát címteréből. A privát végpontok segítenek megakadályozni a dinamikus IP-címváltozások csatlakozási megszakadását. További információ az NFS-megosztások biztonságáról: NFS-fájlmegosztások – Biztonság és hálózatkezelés.

Rugalmasság a rendelkezésre állási zóna hibáival szemben

A rendelkezésre állási zónák fizikailag különálló adatközpont-csoportok egy Azure-régión belül. Ha egy zóna meghibásodik, a szolgáltatások a fennmaradó zónák egyikére is át tudnak adni feladatokat.

Az Azure Files kétféle rendelkezésre állási zónát támogat:

Requirements

  • Régiótámogatás:

  • Fájlmegosztás-típusok:

    • ZRS: A ZRS-t minden fájlmegosztás-típus támogatja.

    • LRS zonális elhelyezéssel: A zónaelhelyezéssel rendelkező LRS az alábbi követelményeknek megfelelő tárfiókokhoz érhető el:

      • A prémium szintű tárolási szintet (SSD médiaszintet) kell használnia.
      • Csak klasszikus Azure-fájlmegosztások (a Microsoft.Storage erőforrás-szolgáltató használatával). A Zonal elhelyezés jelenleg nem lehetséges a Microsoft.FileShares erőforrás-szolgáltatóval (előzetes verzió) létrehozott fájlmegosztások esetében.

Költség

A költséghatás a rendelkezésre állási zóna által használt támogatás típusától függően eltérő:

  • ZRS: A zónaredundáns tárolás (ZRS) engedélyezésekor a többletreplikációs és tárolási többletterhelés miatt a helyileg redundáns tárolástól (LRS) eltérő díjat kell fizetnie.

  • LRS zonális elhelyezéssel: A zónaelhelyezéssel rendelkező LRS-t az LRS-sel azonos díjjal terheljük.

Részletes díjszabási információkért tekintse meg az Azure Files díjszabását.

A rendelkezésre állási zóna támogatásának konfigurálása

Viselkedés, ha minden zóna kifogástalan

Ez a szakasz azt ismerteti, hogy mire számíthat, ha egy fájltároló-fiók konfigurálva van a rendelkezésre állási zónák támogatásához, és az összes rendelkezésre állási zóna működőképes.

  • Forgalomirányítás zónák között:

    • ZRS: A zónaredundáns tárolással (ZRS) rendelkező Azure Storage automatikusan osztja el a kéréseket több rendelkezésre állási zónában lévő tárolófürtök között. A forgalomelosztás transzparens az alkalmazások számára, és nem igényel ügyféloldali konfigurációt.

    • LRS zonális elhelyezéssel: A helyileg redundáns tárolással (LRS) rendelkező Azure Storage automatikusan elosztja a kéréseket a kiválasztott rendelkezésre állási zónában lévő tárolófürtök között. A forgalomelosztás transzparens az alkalmazások számára, és nem igényel ügyféloldali konfigurációt.

  • Adatreplikálás zónák között:

    • ZRS: A ZRS-be írt összes írási művelet szinkron módon replikálódik a régió összes rendelkezésre állási zónája között. Az adatok feltöltése vagy módosításakor a művelet nem tekinthető befejezettnek, amíg az adatok sikeresen nem replikálódnak az összes rendelkezésre állási zónában. Ez a szinkron replikáció erős konzisztenciát és nulla adatvesztést biztosít a zónahibák során.

    • LRS zonális elhelyezéssel: Az LRS-be írt összes írási művelet szinkron módon replikálódik a zónán belüli több tárreplikán. Az adatok feltöltése vagy módosításakor a művelet nem tekinthető befejezettnek, amíg az adatok sikeresen nem replikálódnak az összes replika között.

Viselkedés zónahiba esetén

Ez a szakasz azt írja le, mire számíthatunk, ha egy fájltároló-fiók a rendelkezésre állási zónák támogatására van konfigurálva, és rendelkezésre állási zóna kimaradása következik be.

  • Észlelés és válasz:

    • ZRS: A Microsoft automatikusan észleli a zónahibákat, és helyreállítási folyamatokat kezdeményez. A zónaredundáns tárfiókokhoz (ZRS) nincs szükség ügyfélműveletre. Ha egy zóna elérhetetlenné válik, az Azure olyan hálózati frissítéseket hajt végre, mint a tartománynévrendszer (DNS) újrapontozása.

    • LRS zonális elhelyezéssel: Meg kell figyelnie egy rendelkezésre állási zóna elvesztését. Szükség esetén kezdeményezhet feladatátvételt egy másik rendelkezésre állási zónában előzetesen létrehozott másodlagos fájlmegosztásra.

  • Aktív kérések:

    • ZRS: Előfordulhat, hogy a repülés közbeni kérések a helyreállítási folyamat során elvesznek, és újra meg kell próbálkozni. Az alkalmazásoknak újrapróbálkozásos logikát kell implementálniuk az átmeneti megszakítások kezeléséhez.

    • LRS zonális elhelyezéssel: A rendszer elveti a repülés közbeni kérelmeket, és a zóna helyreállításakor újra meg kell próbálkoznia.

  • Várható adatvesztés:

    • ZRS: A zónahibák során nem történik adatvesztés, mert az adatok szinkron módon replikálódnak több zónára az írási műveletek befejezése előtt.

    • LRS zonális elhelyezéssel: Az érintett zónában lévő fájlmegosztásokra vonatkozó adatok nem érhetők el, amíg a zóna helyre nem áll.

  • Várható állásidő:

    • ZRS: Az automatikus helyreállítás során a forgalom kifogástalan állapotú zónákba való átirányítása során általában néhány másodpercnyi állásidő fordulhat elő. A ZRS-alkalmazások tervezésekor kövesse az átmeneti hibakezelés gyakorlatát, beleértve az újrapróbálkozási szabályzatok exponenciális visszalépéssel történő implementálását is.

    • LRS zonális elhelyezéssel: Az érintett zónában lévő fájlmegosztások mindaddig leállnak, amíg a rendelkezésre állási zóna helyre nem áll.

  • Forgalom átirányítása:

    • ZRS: Az Azure automatikusan átirányítja a forgalmat a fennmaradó kifogástalan rendelkezésre állási zónákba. A szolgáltatás teljes funkcionalitást biztosít a túlélő zónák használatával, ügyfél beavatkozás nélkül. Nincs szükség az Azure-fájlmegosztások újracsatlakoztatására a csatlakoztatott ügyfelekről.

    • LRS zonális elhelyezéssel: Ha szükséges, ön felel az kifogástalan állapotú zónákban lévő más fájltárfiókokra való váltásért.

Zóna helyreállítása

A zóna-helyreállítási viselkedés a fájltárfiók által használt replikáció típusától függ:

  • ZRS: A sikertelen rendelkezésre állási zóna helyreállításakor az Azure Storage automatikusan visszaállítja a normál műveleteket az összes rendelkezésre állási zónában. A szolgáltatás automatikusan biztosítja az adatok konzisztenciáját a kimaradás időszakában végrehajtott műveletek szinkronizálásával.

  • LRS zonális elhelyezéssel: Miután a zóna kifogástalan állapotú, a zónában lévő fájlmegosztások ismét elérhetők. Ön felel a számítási feladatokhoz szükséges zóna-helyreállítási eljárásokért és adatszinkronizálásért.

Zónahibák tesztelése

A zónaleállítási tesztelési lehetőségek a fájltárfiók által használt replikáció típusától függnek:

  • ZRS: Zónaredundáns tárolás (ZRS) használatakor az Azure Storage automatikusan kezeli a replikációt, a forgalomirányítást és a zónaleállítási válaszokat. Mivel ez a szolgáltatás teljes mértékben felügyelt, nem kell kezdeményeznie vagy ellenőriznie a rendelkezésre állási zónák meghibásodási folyamatait.

  • LRS zonális elhelyezéssel: A fájltárfiókot tartalmazó rendelkezésre állási zóna kimaradását nem lehet szimulálni. Manuálisan azonban konfigurálhatja a felsőbb rétegbeli alkalmazásokat, tűzfalakat, átjárókat vagy terheléselosztókat, hogy a forgalmat egy másik rendelkezésre állási zónában lévő másik fájltárfiókba irányítsák át.

Rugalmasság régiószintű hibákhoz

Az Azure Storage, többek között az Azure Blob Storage, az Azure Files, az Azure Table Storage és az Azure Queue Storage, számos georedundanciát és feladatátvételi képességet biztosít a különböző követelményeknek megfelelően.

Fontos

A georedundáns tárolás (GRS) csak az Azure párosított régióiban működik. Ha a tárfiók régiója nincs párosítva, fontolja meg az egyéni többrégiós megoldások használatát a rugalmasság érdekében.

Georedundáns tárolás párosított régiókhoz

Az Azure Storage több típusú GRS-t biztosít párosított régiókban. Bármelyik típusú GRS-t is használja, a másodlagos régióban lévő adatok mindig helyileg redundáns tárolással (LRS) replikálódnak. Ez a megközelítés védelmet nyújt a másodlagos régión belüli hardverhibák ellen.

Fontos

Az Azure Files csak a georedundancia (GRS vagy GZRS) használatát támogatja a standard (HDD) fájlmegosztásokhoz.

Az Azure Files nem támogatja az olvasási hozzáférésű georedundáns tárolást (RA-GRS) vagy az olvasási hozzáférésű földrajzi zóna szerinti redundáns tárolást (RA-GZRS). Ha egy tárfiók RA-GRS vagy RA-GZRS használatára van konfigurálva, a standard (HDD) fájlmegosztások GRS vagy GZRS formátumban vannak konfigurálva és számlázva.

Átállás típusai

Az Azure Storage három feladatátvételi típust támogat különböző helyzetekben.

  • Ügyfél által felügyelt nem tervezett feladatátvétel: Ha régiószintű tárolási hiba történik az elsődleges régióban, ön kezdeményezi a helyreállítást.

  • Ügyfél által felügyelt tervezett feladatátvétel: Ön a felelős a helyreállítás elindításáért, ha a megoldás egy másik része meghibásodik az elsődleges régióban, és a teljes megoldást át kell állítania egy másodlagos régióra. Tervezett feladatátvételt akkor használjon, ha a tárolás továbbra is működőképes marad az elsődleges régióban, de a teljes megoldást egy másodlagos régióra kell átvennie, például a megfelelőségi és naplózási követelmények biztosítására tervezett vészhelyreállítási gyakorlatokhoz.

  • Microsoft által felügyelt feladatátvétel: Kivételes körülmények között a Microsoft feladatátvételt kezdeményezhet az adott régióban található összes georedundáns tárfiók (GRS) esetében. A Microsoft által felügyelt feladatátvétel azonban végső megoldás, és várhatóan csak hosszabb üzemkimaradás után lesz végrehajtva. Nem szabad a Microsoft által felügyelt feladatátvételre támaszkodnia.

A GRS-fiókok ezen feladatátvételi típusok bármelyikét használhatják. Nem kell előre konfigurálnia egy tárfiókot a feladatátvételi típusok előzetes használatához.

Requirements

  • Csak standard fájlmegosztások: Az Azure Files csak a georedundancia (GRS vagy GZRS) használatát támogatja a standard (HDD) fájlmegosztásokhoz. A prémium szintű (SSD) fájlmegosztásoknak LRS-t vagy ZRS-t kell használniuk. Ha prémium szintű fájlmegosztásokkal rendelkezik, és az adatokat régiók között szeretné replikálni a nagyobb rugalmasság érdekében, tekintse meg az egyéni többrégiós megoldásokat a rugalmasság érdekében.

  • CSAK GRS és GZRS: Az Azure Files nem támogatja az olvasási hozzáférésű georedundáns tárolást (RA-GRS) vagy az olvasási hozzáférésű georedundáns tárolást (RA-GZRS). Ha egy tárfiók RA-GRS vagy RA-GZRS használatára van konfigurálva, a standard (HDD) fájlmegosztások GRS vagy GZRS formátumban vannak konfigurálva és számlázva.

Megfontolások

A többrégiós Azure Files megvalósításakor vegye figyelembe a következő fontos tényezőket:

  • Aszinkron replikáció késése: A másodlagos régióba történő adatreplikálás aszinkron, ami azt jelenti, hogy az adatok elsődleges régióba történő írása és a másodlagos régióban való elérhetővé válása között eltérés van. Ez az késés potenciális adatvesztést okozhat, ha az elsődleges régió hibája a legutóbbi adatok replikálása előtt következik be. Az adatvesztést a helyreállítási pont célkitűzése (RPO) méri. A replikáció késése várhatóan kevesebb, mint 15 perc, de ez az idő becslés, és nem garantált.

    A Last Sync Time tulajdonságban ellenőrizheti, hogy mennyi adat veszhet el, ha a tárfiók nem tervezett feladatátvételt futtat.

  • Utolsó szinkronizálási idő: Az Azure Files esetében az utolsó szinkronizálási idő a másodlagos régió legújabb rendszerpillanatképén alapul.

    Az utolsó szinkronizálási idő számítása időtúllépést okozhat, ha egy tárfiókban több mint 100 fájlmegosztás található. Az időtúllépések elkerülése érdekében javasoljuk, hogy minden tárfiókhoz 100 vagy kevesebb fájlmegosztást telepítsen.

  • Másodlagos régióhoz való hozzáférés: A másodlagos régió nem érhető el olvasáshoz, amíg feladatátvétel nem történik.

  • Funkciókorlátozások: Egyes Azure Files-funkciók nem támogatottak, vagy korlátozások vonatkoznak a GRS vagy az ügyfél által felügyelt feladatátvétel használatára. Ezek a korlátozások konkrét fájlmegosztási típusokat, hozzáférési szinteket, valamint felügyeleti eszközöket és műveleteket tartalmaznak. A georedundancia megvalósítása előtt tekintse át a funkciók kompatibilitási dokumentációját .

Költség

A többrégiós Azure Storage-fiókkonfigurációk további költségekkel járnak a régiók közötti replikációhoz és a másodlagos régióban történő tároláshoz. Az Azure-régiók közötti adatátvitelt a standard régiók közötti sávszélesség alapján számítjuk fel.

Részletes díjszabási információkért tekintse meg az Azure Files díjszabását.

Többrégiós támogatás konfigurálása

  • Hozzon létre egy új georedundáns tárfiókot (GRS). GRS-fiók létrehozásához tekintse meg a Tárfiók létrehozása című témakört , és válassza a GRS, az olvasási hozzáférésű georedundáns tárolás (RA-GRS), a geo-zónaredundáns tárolás (GZRS) vagy az olvasási hozzáférésű geo-zónaredundáns tárolás (RA-GZRS) lehetőséget a fiók létrehozása során.

  • Georedundancia engedélyezése meglévő fájltároló-fiókon. Meglévő fájltároló-fiók GRS-sé alakításához lásd: Az Azure Files redundanciakonfigurációjának módosítása.

    Figyelmeztetés

    Miután a fiók georedundanciára van konfigurálva, jelentős ideig tarthat, amíg az új elsődleges régióban lévő meglévő adatok teljes mértékben át lesznek másolva az új másodlagos régióba.

    A jelentős adatvesztés elkerülése érdekében ellenőrizze a Legutóbbi szinkronizálási idő tulajdonság értékét, mielőtt nem tervezett feladatátvételt kezdeményez. A lehetséges adatvesztés kiértékeléséhez hasonlítsa össze az utolsó szinkronizálási időt az új elsődleges régióba való adatírás utolsó időpontjával.

  • Georedundancia letiltása. A GRS-fiókokat konvertálja vissza egyrégiós konfigurációkká (LRS vagy ZRS) ugyanazon redundanciakonfiguráció-módosítási folyamaton keresztül.

Viselkedés, ha minden régió kifogástalan

Ez a szakasz azt ismerteti, hogy mire számíthat, ha egy tárfiók georedundanciára van konfigurálva, és minden régió működőképes.

  • Forgalomirányítás régiók között: Az Azure Files aktív-passzív megközelítést használ, ahol az összes olvasási és írási művelet az elsődleges régióba lesz irányítva.

  • Régiók közötti adatreplikálás: Az írási műveletek először a konfigurált redundanciatípus (GRS-hez készült LRS vagy A GZRS-hez készült ZRS) használatával kerülnek az elsődleges régióba. Az elsődleges régió sikeres befejezése után az adatok aszinkron módon replikálódnak a másodlagos régióba, ahol az LRS használatával vannak tárolva.

    A régiók közötti replikáció aszinkron jellege azt jelenti, hogy az adatok elsődleges régióba való írása és a másodlagos régióban való rendelkezésre állása között általában késés áll fenn. A replikációs időt az Utolsó szinkronizálási idő tulajdonság használatával figyelheti.

Viselkedés régióhiba esetén

Ez a szakasz azt ismerteti, hogy mire számíthat, ha egy tárfiók georedundanciára van konfigurálva, és kimaradás történik az elsődleges régióban.

  • Ügyfél által felügyelt feladatátvétel (nem tervezett): Nem tervezett feladatátvételt használjon, ha az elsődleges régióban nem érhető el a tároló.

    • Észlelés és válasz: Abban a valószínűtlen esetben, ha a tárfiók nem érhető el az elsődleges régióban, érdemes lehet kezdeményezni egy ügyfél által felügyelt, nem tervezett feladatátvételt. A döntés meghozatalához vegye figyelembe a következő tényezőket:

      • Azt jelzi, hogy az Azure Resource Health problémákat mutat-e az elsődleges régió tárfiókjához való hozzáféréssel kapcsolatban

      • Azt jelzi, hogy a Microsoft javasolja-e a feladatátvételt egy másik régióba

      Figyelmeztetés

      A nem tervezett feladatátvétel adatvesztést okozhat. Mielőtt elindít egy ügyfél által felügyelt feladatátvételt, döntse el, hogy a szolgáltatás visszaállítása indokolja-e az adatvesztés kockázatát.

    • Aktív kérések: A feladatátvételi folyamat során mind az elsődleges, mind a másodlagos tárfiók végpontja ideiglenesen elérhetetlenné válik mind az olvasás, mind az írás esetében. Előfordulhat, hogy az aktív kérések elvethetők, és az ügyfélalkalmazásoknak újra kell próbálkoznia a feladatátvétel befejezése után.

    • Várható adatvesztés: Az adatvesztés gyakori a nem tervezett feladatátvétel során az aszinkron replikáció késése miatt, ami azt jelenti, hogy a legutóbbi írások nem replikálhatók. A Legutóbbi szinkronizálási idő tulajdonságban ellenőrizheti, hogy mennyi adat veszhet el egy nem tervezett feladatátvétel során. A várt adatvesztést gyakran helyreállítási pont célkitűzésnek (RPO) is nevezik. Az RPO általában kisebb, mint 15 perc, de ezt az időt nem garantálják.

    • Várható állásidő: A várható állásidőt gyakran helyreállítási időkorlátnak (RTO) is nevezik. Az ügyfél által felügyelt feladatátvétel általában 60 percen belül befejeződik a fiók méretétől és összetettségétől függően.

    • Forgalom átirányítása: A feladatátvétel befejeződése után az Azure automatikusan frissíti a tárfiók végpontjait, hogy az alkalmazásokat ne kelljen újrakonfigurálni. Ha az alkalmazás gyorsítótárazza a tartománynévrendszer (DNS) bejegyzéseit, szükség lehet a gyorsítótár törlésére annak biztosítása érdekében, hogy az alkalmazás forgalmat küldjön az új elsődleges régióba.

    • Feladatátvétel utáni konfiguráció: A nem tervezett feladatátvétel befejezése után a célrégióban lévő tárfiók a helyileg redundáns tárolási (LRS) szintet használja. Ha újra georeplikálásra van szüksége, újra engedélyeznie kell a georedundáns tárolást (GRS), és meg kell várnia, amíg az adatok replikálódnak az új másodlagos régióba.

    További információ az ügyfél által felügyelt feladatátvétel kezdeményezéséről: Hogyan működik az ügyfél által felügyelt (nem tervezett) feladatátvétel , és hogyan kezdeményezhet tárfiók feladatátvételt.

  • Ügyfél által felügyelt feladatátvétel (tervezett): Tervezett feladatátvételt akkor használjon, ha a tárolás továbbra is működőképes marad az elsődleges régióban, de más okból át kell adnia a teljes megoldást egy másodlagos régióba. Előfordulhat például, hogy egy másik Azure-szolgáltatás problémát tapasztal, és át kell váltania egy másodlagos régió használatára a teljes megoldáshoz. Vagy használhatja a tervezett feladatátvételt katasztrófa utáni helyreállítási (DR) próbafuttatás elvégzésére megfelelőségi és auditálási célokra.

    • Észlelés és válasz: Ön a felelős az automatikus átállásról való döntésért. Ezt a döntést általában akkor hozod meg, ha régiók közötti feladatátvételre van szükség, annak ellenére, hogy a tárfiók kifogástalan állapotú. Előfordulhat például, hogy feladatátvételt indít el, ha egy másik alkalmazásösszetevő jelentős leállását nem tudja helyreállítani az elsődleges régióban.

    • Aktív kérések: A feladatátvételi folyamat során mind az elsődleges, mind a másodlagos tárfiók végpontja ideiglenesen elérhetetlenné válik mind az olvasás, mind az írás esetében. Előfordulhat, hogy az aktív kérések elvethetők, és az ügyfélalkalmazásoknak újra kell próbálkoznia a feladatátvétel befejezése után.

    • Várható adatvesztés: Nem várható adatvesztés, mert a feladatátvételi folyamat csak az összes adat szinkronizálása után fejeződik be, ami nulla RPO-t eredményez.

    • Várható állásidő: A feladatátvétel általában 60 percen belül fejeződik be, ami azt jelenti, hogy a várt RTO 60 perc, a fiók méretétől és összetettségétől függően. A feladatátvételi folyamat során mind az elsődleges, mind a másodlagos tárfiók végpontja ideiglenesen elérhetetlenné válik mind az olvasás, mind az írás esetében.

    • Forgalom átirányítása: A feladatátvétel befejeződése után az Azure automatikusan frissíti a tárfiók végpontjait, hogy az alkalmazásokat ne kelljen újrakonfigurálni. Ha az alkalmazás gyorsítótárazza a DNS-bejegyzéseket, szükség lehet a gyorsítótár törlésére annak biztosítása érdekében, hogy az alkalmazás forgalmat küldjön az új elsődleges régióba.

    • Feladatátvétel utáni konfiguráció: A tervezett feladatátvétel befejezése után a célrégióban lévő tárfiók továbbra is georeplikált lesz, és a GRS-szinten marad.

    Az ügyfél által felügyelt feladatátvétel elindításáról további információt az ügyfél által felügyelt (tervezett) feladatátvétel működése és a tárfiók feladatátvételének kezdeményezése című témakörben talál.

  • Microsoft által felügyelt feladatátvétel: Olyan súlyos katasztrófa esetén, amikor a Microsoft megállapítja, hogy az elsődleges régió véglegesen helyreállíthatatlan, automatikus feladatátvételt kezdeményezhet a másodlagos régióba. A Microsoft kezeli a teljes folyamatot, és nincs szükség ügyfélműveletre. A feladatátvétel előtt eltelt idő a katasztrófa súlyosságától és a helyzet értékeléséhez szükséges időtől függ.

    Fontos

    Használja az ügyfél által felügyelt feladatátvételi lehetőségeket a DR-csomagok fejlesztéséhez, teszteléséhez és implementálásához. Ne támaszkodhat a Microsoft által felügyelt feladatátvételre, amely csak szélsőséges körülmények között használható. A Microsoft által felügyelt feladatátvételt valószínűleg egy teljes régióban kezdeményezik. Nem kezdeményezhető egyéni tárfiókok, előfizetések vagy ügyfelek számára. Az átváltás különböző időpontokban történhet a különböző Azure-szolgáltatások esetében. Javasoljuk, hogy az ügyfél által felügyelt feladatátvételt használja.

Régió helyreállítása

A feladat-visszavételi folyamat jelentősen eltér a Microsoft által felügyelt és az ügyfél által felügyelt feladatátvételi forgatókönyvek között.

  • Ügyfél által felügyelt feladatátvétel (nem tervezett): A nem tervezett feladatátvétel után a tárfiók helyileg redundáns tárolással (LRS) van konfigurálva. A feladat-visszavételhez újra létre kell hoznia a georedundáns tárolási (GRS) kapcsolatot, és várnia kell az adatok replikálására.

  • Ügyfél által felügyelt feladatátvétel (tervezett): A tervezett feladatátvétel után a tárfiók georeplikált marad. Kezdeményezhet egy másik, ügyfél által felügyelt feladatátvételt az eredeti elsődleges régióba való visszavételhez. Ugyanezek a feladatátvételi szempontok érvényesek.

  • Microsoft által felügyelt feladatátvétel: Ha a Microsoft feladatátvételt kezdeményez, valószínű, hogy jelentős katasztrófa történt az elsődleges régióban, és előfordulhat, hogy az elsődleges régió nem lesz helyreállítható. Az ütemtervek vagy helyreállítási tervek a regionális katasztrófa- és helyreállítási erőfeszítések mértékétől függenek. Kísérje figyelemmel az Azure Service Health-kommunikációt a részletekért.

Régióhibák tesztelése

GRS-fiókok esetén a karbantartási időszakokban tervezett feladatátvételi műveleteket hajthat végre a teljes feladatátvételi és feladat-visszavételi folyamat teszteléséhez. A tervezett feladatátvétel nem jár adatvesztéssel, de a feladatátvétel és a feladatvisszavétel során is állásidővel jár.

Egyéni többrégiós megoldások a rugalmasság érdekében

Előfordulhat, hogy az Azure Storage régióközi feladatátvételi képességei a következő okok miatt nem megfelelőek:

  • A tárfiók egy nem párosított régióban található.

  • Az üzleti üzemidejű célok nem teljesülnek a beépített feladatátvételi lehetőségek által biztosított helyreállítási idő vagy adatvesztés miatt.

  • Olyan régióba kell átváltania, amely nem képezi párját az elsődleges régiónak.

  • Aktív/aktív konfigurációra van szükség a régiók között.

  • Olyan fájlmegosztás-típusokat használ, amelyek nem támogatják a georedundanciát.

Ez a szakasz magas szintű áttekintést nyújt néhány megfontolandó megközelítésről. Az Azure Storage többrégiós üzembehelyezési topológiáinak átfogó áttekintése nem tartozik a cikk hatókörébe.

Vegye figyelembe a következő gyakori, magas szintű megközelítéseket:

  • Több tárfiók: Az Azure Files több régióban is üzembe helyezhető, ha minden régióban külön tárfiókokat használ. Ez a megközelítés rugalmasságot biztosít a régiók kiválasztásában, a nem használt régiók használatát, valamint részletesebb vezérlést biztosít a replikáció időzítése és az adatok konzisztenciája felett. Ha több tárfiókot implementál régiók között, régiók közötti adatreplikálást kell konfigurálnia, terheléselosztási és feladatátvételi szabályzatokat kell implementálnia, valamint biztosítania kell az adatok régiók közötti konzisztenciáját.

  • Alkalmazásszintű replikáció: Egyéni replikációs logika implementálása az Azure Data Factory vagy az AzCopy használatával a különböző régiókban lévő fájlmegosztások közötti adatszinkronizáláshoz. Ez a megközelítés egyéni fejlesztési és ütközéskezelési mechanizmusokat igényel.

  • Az Azure File Sync használatával fájlokat replikálhat egy másik Azure-régióban lévő fájlmegosztásba. Az Azure File Sync használatával szinkronizálhat egy SMB Azure-fájlmegosztás (felhővégpont), egy helyszíni Windows-fájlkiszolgáló és egy csatlakoztatott fájlmegosztás között, amely egy másik Azure-régióban ( DR-kiszolgálóvégponton) futó virtuális gépen (VM-en) fut.

    Ehhez a megközelítéshez több fájlmegosztást és egy virtuális gépet kell üzembe helyeznie a szinkronizálási folyamat koordinálásához.

    Ha ezt a módszert használja többrégiós fájlreplikációs célokra:

    • Tiltsa le a felhőbeli rétegzést, hogy minden adat helyileg legyen jelen a fájlkiszolgálón.

    • Elegendő tárterület kiépítése az Azure-beli virtuális gépen a teljes adatkészlet tárolásához.

    • A fájlok elérése és módosítása a kiszolgálóvégponton és nem az Azure-ban, annak érdekében, hogy a módosítások gyorsan replikálódjanak a másodlagos régióba.

Biztonsági mentés és visszaállítás

Az Azure Files biztonsági mentése egy natív integráció az Azure Files és az Azure Backup között, amelynek célja az adatok védelme a véletlen törlés, a sérülés és a zsarolóprogramok elleni támadások ellen.

Az Azure Files biztonsági mentése megosztási szintű pillanatképeket hoz létre, amelyeket ugyanabban a tárfiókban tárol. Ez a funkció lehetővé teszi az egyes fájlok és a teljes fájlmegosztások gyors helyreállítását. A biztonsági mentési szabályzatok használatával hosszú megőrzési időtartamokat is megadhat testre szabható biztonsági mentési gyakorisággal.

A pillanatképeket kétféleképpen hozhatja létre és tárolhatja:

  • Share-level storage: Működési és rövid távú helyreállítási forgatókönyvek esetén létrehozhat megosztási szintű pillanatképeket, és tárolhatja őket ugyanabban a tárfiókban. A megosztási szintű pillanatképek lehetővé teszik az egyes fájlok vagy teljes fájlmegosztások gyors helyreállítását az eredeti vagy egy másik helyre.

  • Tárolóalapú biztonsági mentési tároló: Tárolóalapú biztonsági mentéssel napi pillanatképeit egy Azure Recovery Services-tárolóba másolhatja. A biztonság növelése érdekében ez a széf el van különítve, és levegőréssel el van választva az elsődleges tárolófióktól.

    Ha párosított Azure-régiót használ, és a tárolót GRS használatára konfigurálja, a tároló replikálja az adatokat a párosított régióba. Ez a replikáció támogatja a régiók közötti helyreállítást és a dr. munkafolyamatokat.

Szolgáltatásiszint-szerződés

Az Azure Storage szolgáltatásszintű szerződése (SLA) leírja a szolgáltatás várható rendelkezésre állását és azokat a feltételeket, amelyeket teljesíteni kell a rendelkezésre állási elvárás eléréséhez. A rendelkezésre állási SLA, amelyre jogosult, a tárolási szinttől és a használt replikációs típustól függ. További információ: SLA-k online szolgáltatásokhoz.

Kapcsolódó tartalom

  • Last updated on