Ajánlott eljárások a vészhelyreállításhoz Azure File Sync
A Azure File Sync három fő területet érdemes figyelembe venni a vészhelyreállításhoz: magas rendelkezésre állás, adatvédelem/biztonsági mentés és adatredundancia. Ez a cikk az egyes területeket ismerteti, és segít eldönteni, hogy milyen konfigurációt használjon a saját vészhelyreállítási megoldásához.
Egy Azure File Sync üzemelő példányban a felhővégpont mindig tartalmazza az adatok teljes másolatát, míg a helyszíni kiszolgáló az adatok eldobható gyorsítótáraként tekinthető meg. Kiszolgálóoldali katasztrófa esetén egy új kiszolgáló kiépítésével, a Azure File Sync ügynök telepítésével és új kiszolgálóvégpontként való beállításával állíthatja be a helyreállítást.
Hibrid jellegéből adódóan néhány hagyományos kiszolgálói biztonsági mentési és vészhelyreállítási stratégia nem fog működni Azure File Sync. Bármely regisztrált kiszolgáló esetében a Azure File Sync nem támogatja a következőket:
Figyelmeztetés
Ezen műveletek bármelyikének végrehajtása problémákat okozhat a szinkronizálással vagy a rétegzett fájlokkal kapcsolatban, ami végső adatvesztést okozhat. Ha végrehajtotta az alábbi műveletek egyikét, forduljon Azure-támogatás, és győződjön meg arról, hogy az üzembe helyezés kifogástalan állapotban van.
- Lemezmeghajtók (kötet) átvitele/klónozása az egyik kiszolgálóról a másikra, miközben a kiszolgálóvégpont még aktív
- Visszaállítás operációs rendszer biztonsági másolatából
- Kiszolgáló operációs rendszerének klónozása egy másik kiszolgálóra
- Visszaállítás egy korábbi virtuálisgép-ellenőrzőpontra
- Rétegzett fájlok visszaállítása helyszíni (külső) biztonsági másolatból a kiszolgálóvégpontra
Magas rendelkezésre állás
Két különböző stratégiát használhat a helyszíni kiszolgáló magas rendelkezésre állásának eléréséhez. Konfigurálhat feladatátvevő fürtöt, vagy konfigurálhat egy készenléti kiszolgálót. A két konfiguráció közötti döntési tényező az, hogy mennyit hajlandó befektetni a rendszerbe, és ha a rendszer leállási idejének minimalizálása katasztrófa esetén megéri ezt a többletköltséget.
Feladatátvevő fürt esetén nem kell speciális lépéseket tennie a Azure File Sync használatához. Készenléti kiszolgáló esetén a következő konfigurációkat kell végeznie:
Rendelkeznie kell egy másodlagos kiszolgálóval, amely különböző kiszolgálóvégpontokkal rendelkezik, amelyek az elsődleges kiszolgálóval azonos szinkronizálási csoporttal szinkronizálnak, de nem engedélyezik a végfelhasználók számára a kiszolgálóhoz való hozzáférést. Ez lehetővé teszi az összes fájl szinkronizálását az elsődleges kiszolgálóról a készenléti kiszolgálóra. Érdemes lehet engedélyezni a csak névtérbeli rétegezést, hogy kezdetben csak a névtér legyen letöltve. Ha az elsődleges kiszolgáló meghibásodik, az DFS-N használatával gyorsan újrakonfigurálhatja a végfelhasználói hozzáférést a készenléti kiszolgálóhoz.
Adatvédelem/biztonsági mentés
A tényleges adatok védelme a vészhelyreállítási megoldás kulcsfontosságú összetevője. Ezt két fő módon teheti meg az Azure-fájlmegosztásokkal: biztonsági másolatot készíthet az adatokról a felhőben vagy a helyszínen. Javasoljuk, hogy készítsen biztonsági másolatot az adatokról a felhőben, mert a felhőbeli végpont az adatok teljes másolatát fogja tartalmazni, míg a kiszolgálóvégpontok csak az adatok egy részét tartalmazhatják.
Adatok biztonsági mentése a felhőben
A Azure Backup felhőbeli biztonsági mentési megoldásként kell használnia. Azure Backup kezeli többek között a biztonsági másolatok ütemezését, megőrzését és visszaállítását. Ha szeretné, manuálisan is készíthet megosztási pillanatképeket , és konfigurálhatja saját ütemezési és adatmegőrzési megoldását, de ez nem ideális. Másik lehetőségként külső megoldásokat is használhat az Azure-fájlmegosztások közvetlen biztonsági mentéséhez.
Ha katasztrófa történik, visszaállíthatja a megosztás pillanatképét, amely a fájlmegosztás csak olvasható másolata. Mivel ezek a pillanatképek írásvédettek, a zsarolóprogramok nem érintik őket. Olyan nagyméretű adathalmazok esetében, amelyekben a teljes megosztás visszaállítási műveletei hosszú időt vesznek igénybe, engedélyezheti a pillanatképhez való közvetlen hozzáférést, hogy a felhasználók a visszaállítás befejezésekor átmásolhassák a szükséges adatokat a helyi meghajtóra.
A pillanatképek tárolása közvetlenül az Azure-fájlmegosztásban történik, függetlenül attól, hogy manuálisan készíti-e el őket, vagy Azure Backup magával viszi őket. Ezért engedélyeznie kell a helyreállítható törlést , hogy megvédje a pillanatképeket a fájlmegosztás véletlen törlése ellen.
További információ: Tudnivalók az Azure-fájlmegosztások biztonsági mentéséről, vagy forduljon a biztonsági mentési szolgáltatóhoz, és ellenőrizze, hogy támogatják-e az Azure-fájlmegosztások biztonsági mentését.
Helyszíni adatok biztonsági mentése
Ha engedélyezi a felhőbeli rétegzést, ne valósítson meg helyszíni biztonsági mentési megoldást. Ha a felhőbeli rétegzés engedélyezve van, az adatoknak csak egy részhalmaza lesz helyileg tárolva a kiszolgálón, a többi adat a felhővégponton lesz tárolva. A helyi biztonsági mentéshez használt biztonsági mentési megoldástól függően a rétegzett fájlok a következők lehetnek:
- kihagyva, és nem készít biztonsági másolatot (az attribútumuk
FILE_ATTRIBUTE_RECALL_ONDATA_ACCESSmiatt), vagy - ezekről csak rétegzett fájlként készül biztonsági másolat, és előfordulhat, hogy az élő megosztás változásai miatt a visszaállításkor nem lesznek elérhetők, vagy
- A rendszer visszahívja őket a lemezre, ami magas kimenő forgalmat eredményez.
Ha helyszíni biztonsági mentési megoldás használata mellett dönt, a szinkronizálási csoportban lévő kiszolgálón le kell tiltani a felhőbeli rétegzést. Visszaállításkor használja a kötetszintű vagy fájlszintű visszaállítási beállításokat. A fájlszintű visszaállítási beállítással visszaállított fájlok szinkronizálódnak a szinkronizálási csoport összes végpontjával, a meglévő fájlok pedig a biztonsági másolatból visszaállított verzióra lesznek lecserélve. A kötetszintű visszaállítások nem helyettesítik a felhővégpont vagy más kiszolgálóvégpontok újabb fájlverzióit.
A kötet árnyékmásolata szolgáltatás (VSS) pillanatképei (beleértve az Előző verziók lapot) támogatottak olyan köteteken, amelyeken engedélyezve van a felhőbeli rétegzés. Ez lehetővé teszi, hogy önkiszolgáló visszaállításokat hajtson végre, ahelyett, hogy egy rendszergazdára támaszkodva végezhesse el a visszaállításokat. Azonban engedélyeznie kell a korábbi verziókompatibilitást a PowerShell-lel, ami növeli a pillanatkép-tárolási költségeket. A VSS-pillanatképek nem védenek a kiszolgálóvégponton bekövetkezett katasztrófák ellen, ezért csak a felhőoldali biztonsági mentésekkel együtt használhatók. Részletekért lásd: Önkiszolgáló visszaállítás a korábbi verziók és a VSS használatával.
Adatredundancia
A robusztus vészhelyreállítási megoldás biztosításához adjon hozzá valamilyen adatredundanciát az infrastruktúrához. Négy redundanciaajánlat érhető el a Azure Files: helyileg redundáns tárolás (LRS),zónaredundáns tárolás (ZRS),georedundáns tárolás (GRS) és georedundáns tárolás (GZRS).
- Helyileg redundáns tárolás (LRS): Az LRS-ben minden fájl háromszor van tárolva egy Azure-tárolófürtön belül. Ez megvédi az adatvesztést a hardverhibák, például a hibás lemezmeghajtók miatt. Ha azonban katasztrófa, például tűz vagy árvíz történik az adatközpontban, előfordulhat, hogy egy tárfiók LRS-t használó replikái elvesznek vagy helyreállíthatatlanok lesznek.
- Zónaredundáns tárolás (ZRS): A ZRS-ben az egyes tárolt fájlok három példánya van tárolva, azonban ezek a másolatok fizikailag el vannak különítve három különböző tárolófürtben, különböző Azure rendelkezésre állási zónákban. A rendelkezésre állási zónák egyedi fizikai helyek egy Azure-régióban. Minden zóna egy vagy több, független áramellátással, hűtéssel és hálózatkezeléssel felszerelt adatközpontból áll. A tárolóba történő írás csak akkor fogadható el, ha mind a három rendelkezésre állási zónában a tárolófürtökre van írva.
- Georedundáns tárolás (GRS): A GRS-ben két régióval rendelkezik, egy elsődleges és egy másodlagos régióval. A fájlok tárolása háromszor történik egy Azure Storage-fürtben az elsődleges régióban. Az írások aszinkron módon replikálódnak egy Microsoft által definiált másodlagos régióba. A GRS hat példányban biztosítja az adatok két Azure-régió közötti terjesztését.
- Geo-zónaredundáns tárolás (GZRS): A GZRS úgy képzelhető el, mintha ZRS-hez hasonló lenne, de georedundanciával. A GZRS-ben a fájlok három alkalommal vannak tárolva három különböző tárolófürtben az elsődleges régióban. Ezután a rendszer az összes írást aszinkron módon replikálja egy Microsoft által definiált másodlagos régióba.
A robusztus vészhelyreállítási megoldás érdekében a legtöbb ügyfélnek érdemes megfontolnia a ZRS-t. A ZRS a lehető legkisebb többletköltséggel jár a hozzáadott adatredundancia előnyeihez, és a szolgáltatáskimaradás esetén is a leggördülékenyebb. Ha a szervezet szabályzati vagy szabályozási követelményei georedundanciát igényelnek az adatokhoz, fontolja meg a GRS vagy a GZRS használatát.
Georedundancia
Ha a tárfiók GRS- vagy GZRS-replikációval van konfigurálva, a Microsoft kezdeményezi a Társzinkronizálási szolgáltatás feladatátvételét, ha az elsődleges régiót véglegesen helyreállíthatatlannak vagy hosszú ideig elérhetetlennek ítélik. Katasztrófa esetén nincs szükség beavatkozásra.
Bár manuálisan is kérheti a Storage Sync Service feladatátvételét a GRS- vagy GZRS-párosított régióba, nem javasoljuk, hogy ezt a nagy léptékű regionális kimaradásokon kívül tegye, mert a folyamat nem zökkenőmentes, és többletköltséggel járhat. A folyamat elindításához nyisson meg egy támogatási jegyet, és kérje meg, hogy az Azure-fájlmegosztást tartalmazó Azure-tárfiókok és a Storage Sync Szolgáltatás feladatátvétele is legyen.
Figyelmeztetés
Ha manuálisan kezdeményezi ezt a folyamatot, kapcsolatba kell lépnie az ügyfélszolgálattal, hogy kérje a Társzinkronizálási szolgáltatás feladatátvételét. Ha a másodlagos régióban ugyanazokkal a kiszolgálóvégpontokkal próbál létrehozni egy új társzinkronizálási szolgáltatást, az további adatokat eredményezhet a tárfiókban, mert a Azure File Sync korábbi telepítése nem törlődik.
A feladatátvételt követően a kiszolgálóvégpontok automatikusan átváltanak a felhővégponttal való szinkronizálásra a másodlagos régióban. A kiszolgálóvégpontoknak azonban egyeztetniük kell a felhőbeli végpontokkal. Ez fájlütközésekhez vezethet, mivel előfordulhat, hogy a másodlagos régióban lévő adatok nem kerülnek az elsődleges helyre.