Migrálás Linuxról hibrid felhőbeli üzembe helyezésre az Azure File Sync használatával

Ez a migrálási cikk az NFS és az Azure File Sync kulcsszavakat is magában foglaló számos témakör egyike. Ellenőrizze, hogy ez a cikk vonatkozik-e a forgatókönyvre:

• Adatforrás: Network Attached Storage (NAS)
• Migrálási útvonal: Linux Server SAMBA ⇒ Windows Server 2012R2 vagy újabb verzióval ⇒ szinkronizálás az Azure-fájlmegosztásokkal
• Fájlok gyorsítótárazása a helyszínen: Igen, a végső cél az Azure File Sync üzembe helyezése.

Ha a forgatókönyv eltér, tekintse át a migrálási útmutatók táblázatát.

Az Azure File Sync közvetlen csatlakoztatott tárolóval (DAS) rendelkező Windows Server-példányokon működik. Nem támogatja a Linux-ügyfelekkel vagy távoli kiszolgálói üzenetblokkokkal (SMB) vagy hálózati fájlrendszerbeli (NFS) megosztásokkal való szinkronizálást.

Ennek eredményeképpen a fájlszolgáltatások hibrid üzembe helyezéssé alakítása szükségessé teszi a Windows Serverre való migrálást. Ez a cikk végigvezeti egy ilyen migrálás tervezésén és végrehajtásán.

A következőre érvényes:

Fájlmegosztás típusa	SMB	NFS
Standard szintű fájlmegosztások (GPv2), LRS/ZRS
Standard szintű fájlmegosztások (GPv2), GRS/GZRS
Prémium fájlmegosztások (FileStorage), LRS/ZRS

Migrálási célok

A cél az, hogy a Linux Samba-kiszolgálón lévő megosztásokat egy Windows Server-példányra helyezze át. Ezután használja az Azure File Syncet egy hibrid felhőbeli üzembe helyezéshez. Ezt a migrálást úgy kell elvégezni, hogy az garantálja az éles adatok integritását és a rendelkezésre állást a migrálás során. Az utóbbi megköveteli az állásidő minimális szinten tartását, hogy elférjen vagy csak kis mértékben haladja meg a rendszeres karbantartási időszakokat.

Az áttelepítés áttekintése

Ahogy az Azure Files áttelepítési áttekintési cikkében is említettük, fontos a megfelelő másolási eszköz és megközelítés használata. A Linux Samba-kiszolgáló közvetlenül a helyi hálózaton teszi ki az SMB-megosztásokat. A Windows Serverbe beépített Robocopy a legjobb módja a fájlok áthelyezésének ebben a migrálási forgatókönyvben.

Ha nem a Linux-kiszolgálón futtatja a Samba-t, és inkább a mappákat szeretné áttelepíteni egy hibrid telepítésre a Windows Serveren, a Robocopy helyett Linux-másolási eszközöket használhat. Ügyeljen a másolási eszköz hűségképességére. A migrálás áttekintési cikkének migrálási alapjai című szakaszában megtudhatja, hogy mit kell keresnie egy másolási eszközben.

1. fázis: A szükséges Azure-fájlmegosztások számának azonosítása

Ebben a lépésben meghatározza, hogy hány Azure-fájlmegosztásra van szüksége. Egyetlen Windows Server-példány (vagy fürt) legfeljebb 30 Azure-fájlmegosztást szinkronizálhat.

Előfordulhat, hogy több mappája van a köteteken, amelyeket jelenleg helyben oszt meg SMB-megosztásként a felhasználók és alkalmazások számára. Ennek a forgatókönyvnek a legegyszerűbb módja, ha egy helyszíni megosztást képzel el, amely 1:1-et képez le egy Azure-fájlmegosztásra. Ha elegendő számú megosztással rendelkezik, egyetlen Windows Server-példány esetén 30 alatt, 1:1-es leképezést javasoljuk.

Ha több mint 30 megosztást használ, a helyszíni megosztások 1:1-et azure-fájlmegosztásra való leképezése gyakran szükségtelen. Vegye figyelembe az alábbi lehetőségeket.

Megosztási csoportosítás

Ha például az emberierőforrás-részleg 15 megosztással rendelkezik, érdemes lehet az összes HR-adatot egyetlen Azure-fájlmegosztásban tárolnia. Ha több helyszíni megosztást tárol egy Azure-fájlmegosztásban, az nem akadályozza meg a szokásos 15 SMB-megosztás létrehozását a helyi Windows Server-példányon. Ez csak azt jelenti, hogy a 15 megosztás gyökérmappáit almappákként rendezi egy közös mappában. Ezután szinkronizálja ezt a gyakori mappát egy Azure-fájlmegosztással. Így csak egyetlen Azure-fájlmegosztásra van szükség a felhőben a helyszíni megosztások ezen csoportjához.

Kötetszinkronizálás

Az Azure File Sync támogatja a kötet gyökerének azure-fájlmegosztással való szinkronizálását. Ha szinkronizálja a kötet gyökerét, az összes almappája és fájlja ugyanarra az Azure-fájlmegosztásra kerül.

A kötet gyökerének szinkronizálása nem mindig a legjobb megoldás. Több hely szinkronizálása számos előnnyel jár. Ez például segít csökkenteni az elemek számát szinkronizálási hatókörönként. Az Azure-fájlmegosztásokat és az Azure File Syncet megosztásonként 100 millió elem (fájl és mappa) használatával teszteljük. Az ajánlott eljárás azonban az, hogy a számot egyetlen részvényben 20 millió vagy 30 millió alatt kell tartani. Az Azure File Sync alacsonyabb számú elemhez való beállítása nem csak a fájlszinkronizálás szempontjából előnyös. A kisebb számú elem az alábbihoz hasonló forgatókönyveket is előnyben részesül:

• A felhőtartalom kezdeti vizsgálata gyorsabban befejeződhet, ami csökkenti a névtér megjelenésének várakozását az Azure File Sync számára engedélyezett kiszolgálón.
• Az Azure-fájlmegosztási pillanatképek felhőoldali visszaállítása gyorsabb lesz.
• A helyszíni kiszolgáló vészhelyreállítása jelentősen felgyorsítható.
• Az Azure-fájlmegosztásokban (a szinkronizáláson kívül) végrehajtott módosítások gyorsabban észlelhetők és szinkronizálhatók.

Tipp.

Ha nem tudja, hány fájlja és mappája van, tekintse meg a TreeSize eszközt a JAM Software GmbH-tól.

Az üzembehelyezési térkép strukturált megközelítése

Mielőtt egy későbbi lépésben üzembe helyezené a felhőtárhelyet, fontos, hogy térképet hozzon létre a helyszíni mappák és az Azure-fájlmegosztások között. Ez a leképezés tájékoztatja, hogy hány és melyik Azure File Sync szinkronizálási csoport erőforrásait fogja kiépíteni. A szinkronizálási csoport összekapcsolja az Azure-fájlmegosztást és a kiszolgálón lévő mappát, és létrehoz egy szinkronizálási kapcsolatot.

Annak eldöntéséhez, hogy hány Azure-fájlmegosztásra van szüksége, tekintse át az alábbi korlátozásokat és ajánlott eljárásokat. Ez segít optimalizálni a térképet.

• Egy kiszolgáló, amelyre az Azure File Sync-ügynök telepítve van, legfeljebb 30 Azure-fájlmegosztással szinkronizálható.

• Egy Azure-fájlmegosztás egy tárfiókban van üzembe helyezve. Ez az elrendezés skálázási célként teszi a tárfiókot olyan teljesítményszámokhoz, mint az IOPS és az átviteli sebesség.

  Az Azure-fájlmegosztások telepítésekor ügyeljen a tárfiók IOPS-korlátaira. Ideális esetben az 1:1 fájlmegosztásokat tárfiókokkal kell megfeleltetnie. Ez azonban nem mindig lehetséges a szervezet és az Azure különböző korlátai és korlátozásai miatt. Ha nem lehet egyetlen fájlmegosztást üzembe helyezni egy tárfiókban, fontolja meg, hogy mely megosztások lesznek rendkívül aktívak, és mely megosztások lesznek kevésbé aktívak annak biztosítása érdekében, hogy a legforróbb fájlmegosztások ne legyenek ugyanabban a tárfiókban együtt.

  Ha olyan alkalmazást szeretne az Azure-ba emelni, amely natív módon fogja használni az Azure-fájlmegosztást, előfordulhat, hogy nagyobb teljesítményre van szüksége az Azure-fájlmegosztásból. Ha ez a fajta használat lehetőség, még a jövőben is érdemes egyetlen szabványos Azure-fájlmegosztást létrehozni a saját tárfiókjában.

• Előfizetésenként legfeljebb 250 tárfiók lehet Azure-régiónként.

Tipp.

Ezen információk alapján gyakran szükségessé válik több legfelső szintű mappa csoportosítása a köteteken egy új gyakori gyökérkönyvtárba. Ezután szinkronizálja ezt az új gyökérkönyvtárat és az összes ebbe csoportosított mappát egyetlen Azure-fájlmegosztásba. Ez a technika lehetővé teszi, hogy a kiszolgálónkénti 30 Azure-fájlmegosztás-szinkronizálási korláton belül maradjon.

Ez a közös gyökér alatt történő csoportosítás nem befolyásolja az adatokhoz való hozzáférést. Az ACL-ek továbbra is megmaradnak. Csak azokat a megosztási útvonalakat (például az SMB- vagy NFS-megosztásokat) kell módosítania, amelyek a helyi kiszolgálómappákban már általános gyökérként módosultak. Semmi más nem változik.

Fontos

Az Azure File Sync legfontosabb méretezési vektora a szinkronizálandó elemek (fájlok és mappák) száma. További részletekért tekintse át az Azure File Sync méretezési céljait .

Ajánlott eljárás a szinkronizálási hatókörönkénti elemek számának alacsony szinten tartása. Ezt fontos figyelembe venni a mappák Azure-fájlmegosztásokhoz való leképezésében. Az Azure File Syncet megosztásonként 100 millió elem (fájl és mappa) teszteli a rendszer. De gyakran a legjobb, ha egyetlen részvényben 20 millió vagy 30 millió alatt tartjuk az elemek számát. Ha túllépi ezeket a számokat, ossza fel a névteret több megosztásra. Továbbra is csoportosíthat több helyszíni megosztást ugyanabba az Azure-fájlmegosztásba, ha nagyjából ezek alatt a számok alatt marad. Ez a gyakorlat teret biztosít a növekedéshez.

Előfordulhat, hogy az Ön esetében egy mappakészlet logikailag szinkronizálható ugyanahhoz az Azure-fájlmegosztáshoz (a korábban említett új gyakori gyökérmappa-megközelítéssel). De még mindig jobb lehet a mappák újracsoportosítása, hogy egy Azure-fájlmegosztás helyett kettőre szinkronizáljanak. Ezzel a módszerrel a fájlmegosztásonkénti fájlok és mappák számát egyensúlyban tarthatja a kiszolgálón. A helyszíni megosztásokat és szinkronizálást több helyszíni kiszolgálóra is feloszthatja, így további kiszolgálónként 30 további Azure-fájlmegosztással szinkronizálhat.

Gyakori fájlszinkronizálási forgatókönyvek és szempontok

#	Szinkronizálási forgatókönyv	Támogatott	Szempontok (vagy korlátozások)	Megoldás (vagy kerülő megoldás)
0	Több lemezzel/kötettel és több megosztással rendelkező fájlkiszolgáló ugyanazon cél Azure-fájlmegosztáshoz (konszolidálás)	Nem	A cél Azure-fájlmegosztás (felhővégpont) csak egy szinkronizálási csoporttal támogatja a szinkronizálást. A szinkronizálási csoportok regisztrált kiszolgálónként csak egy kiszolgálóvégpontot támogatnak.	1) Először szinkronizáljon egy lemezt (annak gyökérkötetét) az Azure-fájlmegosztás megcélzásához. A legnagyobb lemezzel/kötettel kezdődően a helyszíni tárolási követelmények segítenek. A felhőbeli rétegzést úgy konfigurálhatja, hogy az összes adatot felhőbe rétegezhesse, ezáltal szabadítson fel helyet a fájlkiszolgáló lemezén. Adatok áthelyezése más kötetekből/megosztásokból a szinkronizált aktuális kötetbe. Folytassa a lépéseket egyenként, amíg az összes adat fel nem lesz sorolva a felhőbe vagy migrálva. 2) Egyszerre egy gyökérkötetet (lemezt) célozzon meg. A felhőbeli rétegzés használatával az összes adat rétegzésével megcélozza az Azure-fájlmegosztást. Távolítsa el a kiszolgálóvégpontot a szinkronizálási csoportból, hozza létre újra a végpontot a következő gyökérkötettel/lemezzel, szinkronizálja és ismételje meg a folyamatot. Megjegyzés: Előfordulhat, hogy az ügynök újratelepítése szükséges. 3) Javasolt több cél Azure-fájlmegosztás használata (ugyanaz vagy más tárfiók a teljesítménykövetelmények alapján)
2	Egy kötettel és több megosztással rendelkező fájlkiszolgáló ugyanazon cél Azure-fájlmegosztáshoz (konszolidálás)	Igen	Nem lehet több kiszolgálóvégpont regisztrált kiszolgálónként szinkronizálva ugyanahhoz a cél Azure-fájlmegosztáshoz (ugyanaz, mint fent)	A több megosztást vagy legfelső szintű mappákat tartalmazó kötet gyökérmappájának szinkronizálása. További információt a Megosztás csoportosítási koncepciója és a Kötetszinkronizálás című témakörben talál.
3	Több megosztást és/vagy kötetet tartalmazó fájlkiszolgáló több Azure-fájlmegosztáshoz egyetlen tárfiókban (1:1 megosztásleképezés)	Igen	Egyetlen Windows Server-példány (vagy fürt) legfeljebb 30 Azure-fájlmegosztást szinkronizálhat. A tárfiókok a teljesítmény skálázási célértékei. Az IOPS és az átviteli sebesség meg van osztva a fájlmegosztások között. A szinkronizálási csoportonkénti elemek száma megosztásonként 100 millió elemet (fájlokat és mappákat) tartalmaz. Ideális esetben a legjobb, ha részvényenként 20 vagy 30 millió alatt marad.	1) Több szinkronizálási csoport használata (szinkronizálási csoportok száma = a szinkronizálni kívánt Azure-fájlmegosztások száma). 2) Ebben a forgatókönyvben egyszerre csak 30 megosztás szinkronizálható. Ha több mint 30 megosztással rendelkezik a fájlkiszolgálón, használja a Megosztási csoportosítási koncepciót és a Kötetszinkronizálást a forrás gyökér- vagy legfelső szintű mappáinak számának csökkentéséhez. 3) Használjon további helyszíni fájlszinkronizálási kiszolgálókat, és ossza fel/helyezze át az adatokat ezekre a kiszolgálókra, hogy megkerülje a forrás Windows-kiszolgáló korlátait.
4	Több megosztást és/vagy kötetet tartalmazó fájlkiszolgáló több Azure-fájlmegosztáshoz különböző tárfiókban (1:1 megosztásleképezés)	Igen	Egyetlen Windows Server-példány (vagy fürt) legfeljebb 30 Azure-fájlmegosztást szinkronizálhat (azonos vagy eltérő tárfiók). A szinkronizálási csoportonkénti elemek száma megosztásonként 100 millió elemet (fájlokat és mappákat) tartalmaz. Ideális esetben a legjobb, ha részvényenként 20 vagy 30 millió alatt marad.	Ugyanaz a megközelítés, mint fent
5	Több olyan fájlkiszolgáló, amely egyetlen (gyökérkötettel vagy megosztással) rendelkezik ugyanahhoz a cél Azure-fájlmegosztáshoz (konszolidálás)	Nem	A szinkronizálási csoportok nem használhatják a másik szinkronizálási csoportban már konfigurált felhővégpontot (Azure-fájlmegosztást). Bár a szinkronizálási csoport különböző fájlkiszolgálókon rendelkezhet kiszolgálóvégpontokkal, a fájlok nem lehetnek különállóak.	Kövesse a fenti 1. forgatókönyv útmutatását, és további szempontokat is figyelembe véve, hogy egyszerre csak egy fájlkiszolgálót céloz meg.

Leképezési tábla létrehozása

Az előző információk alapján meghatározhatja, hogy hány Azure-fájlmegosztásra van szüksége, és hogy a meglévő adatok mely részei lesznek az Azure-fájlmegosztások.

Hozzon létre egy táblázatot, amely rögzíti a gondolatait, hogy szükség esetén hivatkozhasson rá. A rendszerezés fontos, mert könnyen elveszítheti a leképezési terv részleteit, ha egyszerre sok Azure-erőforrást épít ki. Töltse le a következő Excel-fájlt sablonként a leképezés létrehozásához.

Töltse le a névtérleképezési sablont.

2. fázis: Megfelelő Helyszíni Windows Server-példány kiépítése

• Hozzon létre egy Windows Server 2022-példányt virtuális gépként vagy fizikai kiszolgálóként. A Minimális követelmény a Windows Server 2012 R2. A Windows Server feladatátvevő fürtje is támogatott.

• Közvetlen csatlakoztatott tároló (DAS) kiépítése vagy hozzáadása. A hálózati csatlakoztatású tároló (NAS) nem támogatott.

  A kiosztott tárterület kisebb lehet, mint amit jelenleg a Linux Samba-kiszolgálón használ, ha az Azure File Sync felhőalapú rétegzési funkcióját használja.

A kiosztott tárterület kisebb lehet, mint amit jelenleg a Linux Samba-kiszolgálón használ. Ehhez a konfigurációs beállításhoz az Azure File Sync felhőalapú rétegzési funkcióját is használnia kell. Ha azonban egy későbbi fázisban a nagyobb Linux Samba-kiszolgálótérről a kisebb Windows Server-kötetre másolja a fájlokat, akkor kötegekben kell dolgoznia:

1. Helyezze át a lemezre illeszkedő fájlokat.
2. A Fájlszinkronizálás és a felhőbeli rétegzés használatának engedélyezése.
3. Ha több szabad terület jön létre a köteten, folytassa a következő fájlkötettel. Másik lehetőségként tekintse át a RoboCopy parancsot a közelgő RoboCopy szakaszban az új /LFSM kapcsoló használatához. A használat /LFSM jelentősen leegyszerűsítheti a RoboCopy-feladatokat, de nem kompatibilis más RoboCopy-kapcsolókkal, amelyektől függhet.

Ezt a kötegelési módszert elkerülheti, ha kiépít egy megfelelő helyet azon a Windows Server-példányon, amelyet a fájlok a Linux Samba-kiszolgálón foglalnak el. Fontolja meg a deduplikáció engedélyezését Windows rendszeren. Ha nem szeretné véglegesen véglegesíteni ezt a nagy mennyiségű tárterületet a Windows Server-példányra, csökkentheti a kötet méretét az áttelepítés után, és a felhőbeli rétegzési szabályzatok módosítása előtt. Ez egy kisebb helyszíni gyorsítótárat hoz létre az Azure-fájlmegosztásokról.

Az üzembe helyezendő Windows Server-példány erőforráskonfigurációja (számítása és RAM-értéke) leginkább a szinkronizálandó elemek (fájlok és mappák) számától függ. Ha aggályai vannak, javasoljuk, hogy nagyobb teljesítményű konfigurációt használjon.

Megtudhatja, hogyan méretezhet egy Windows Server-példányt a szinkronizálni kívánt elemek (fájlok és mappák) száma alapján.

Feljegyzés

A korábban csatolt cikk egy kiszolgálómemória (RAM) tartományával rendelkező táblázatot mutat be. A kiszolgáló kisebb száma felé is eligazodhat, de a kezdeti szinkronizálás jelentősen több időt vehet igénybe.

3. fázis: Az Azure File Sync felhőerőforrás üzembe helyezése

A lépés végrehajtásához szüksége lesz az Azure-előfizetés hitelesítő adataira.

Az Azure File Synchez konfigurálni kívánt alapvető erőforrást Storage Sync Service-nek nevezzük. Javasoljuk, hogy csak egyet telepítsen az összes olyan kiszolgálóra, amely most vagy a jövőben szinkronizálja ugyanazt a fájlkészletet. Csak akkor hozzon létre több tárolási szinkronizálási szolgáltatást, ha különböző kiszolgálókészletekkel rendelkezik, amelyeknek soha nem szabad adatokat cserélniük. Előfordulhat például, hogy olyan kiszolgálói vannak, amelyeknek soha nem kell szinkronizálnia ugyanazt az Azure-fájlmegosztást. Ellenkező esetben az ajánlott eljárás egyetlen tárolási szinkronizálási szolgáltatás használata.

Válasszon egy Azure-régiót a tartózkodási helyéhez közeli Storage Sync Szolgáltatáshoz. Minden más felhőerőforrást ugyanabban a régióban kell üzembe helyezni. A felügyelet egyszerűsítése érdekében hozzon létre egy új erőforráscsoportot az előfizetésében, amely szinkronizálási és tárolási erőforrásokat tárol.

További információkért tekintse meg az Azure File Sync üzembe helyezéséről szóló cikkben a Storage Sync szolgáltatás üzembe helyezéséről szóló szakaszt. Csak a cikk ezen szakaszát kövesse. A cikk további szakaszaira mutató hivatkozások a későbbi lépésekben lesznek.

4. fázis: Azure Storage-erőforrások üzembe helyezése

Ebben a fázisban tekintse meg az 1. fázis leképezési tábláját, és használja a megfelelő számú Azure-tárfiók és fájlmegosztás kiépítéséhez.

Az Azure-fájlmegosztásokat a felhőben tárolja egy Azure Storage-fiók. Itt egy másik teljesítménybeli szempontot is figyelembe kell venni.

Ha nagyon aktív megosztásokkal rendelkezik (sok felhasználó és/vagy alkalmazás által használt megosztásokkal), két Azure-fájlmegosztás elérheti a tárfiókok teljesítménykorlátját.

Ajánlott eljárás a tárfiókok üzembe helyezése egyenként egy fájlmegosztással. Több Azure-fájlmegosztást is össze lehet készletezni ugyanabba a tárfiókba, ha rendelkezik archiválási megosztásokkal, vagy ha alacsony napi szintű tevékenységre számít bennük.

Ezek a szempontok jobban vonatkoznak a közvetlen felhőbeli hozzáférésre (azure-beli virtuális gépen keresztül), mint az Azure File Syncre. Ha csak az Azure File Syncet szeretné használni ezeken a megosztásokon, több azure-tárfiókba való csoportosítása rendben van.

Ha készített egy listát a megosztásokról, minden megosztást le kell képeznie arra a tárfiókra, amelyben szerepelni fog.

Az előző fázisban meghatározta a részvények megfelelő számát. Ebben a lépésben leképezi a tárfiókokat a fájlmegosztásokra. Most helyezze üzembe a megfelelő számú Azure-tárfiókot a megfelelő számú Azure-fájlmegosztással.

Győződjön meg arról, hogy az egyes tárfiókok régiója megegyezik, és megegyezik a már üzembe helyezett Storage Sync Service-erőforrás régiójával.

Figyelemfelhívás

Ha 100 TiB-korlátot tartalmazó Azure-fájlmegosztást hoz létre, a megosztás csak helyileg redundáns tárolási vagy zónaredundáns tárolási redundanciabeállításokat használhat. 100 TiB-fájlmegosztás használata előtt fontolja meg a tárolási redundanciaigényeket.

Az Azure-fájlmegosztások alapértelmezés szerint 5 TiB-korláttal jönnek létre. Nagy méretű fájlmegosztás létrehozásához kövesse az Azure-fájlmegosztás létrehozása című témakörben leírt lépéseket.

Egy másik szempont a tárfiók üzembe helyezésekor az Azure Storage redundancia. Tekintse meg az Azure Storage redundanciabeállítását.

Az erőforrások neve is fontos. Ha például több megosztást csoportosít a HR-részleg számára egy Azure-tárfiókba, akkor a tárfiókot megfelelően kell neveznie. Hasonlóképpen, amikor elnevezi az Azure-fájlmegosztásokat, a helyszíni társaikhoz használt nevekhez hasonló neveket kell használnia.

5. fázis: Az Azure File Sync-ügynök üzembe helyezése

Ebben a szakaszban az Azure File Sync-ügynököt telepíti a Windows Server-példányra.

Az üzembe helyezési útmutató ismerteti, hogy ki kell kapcsolnia az Internet Explorer fokozott biztonsági konfigurációját. Ez a biztonsági mérték nem alkalmazható az Azure File Sync esetében. A kikapcsolásával probléma nélkül végezhet hitelesítést az Azure-ban.

Nyissa meg a PowerShellt. Telepítse a szükséges PowerShell-modulokat az alábbi parancsokkal. Amikor a rendszer erre kéri, telepítse a teljes modult és a NuGet-szolgáltatót.

Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync

Ha bármilyen problémája van az internet kiszolgálóról való elérésekor, itt az ideje, hogy megoldja őket. Az Azure File Sync bármilyen elérhető hálózati kapcsolatot használ az internethez. Az is támogatott, ha proxykiszolgálót igényel az internet eléréséhez. Most már konfigurálhat egy gépre kiterjedő proxyt, vagy az ügynök telepítése során megadhatja azt a proxyt, amelyet csak az Azure File Sync fog használni.

Ha a proxy konfigurálása azt jelenti, hogy meg kell nyitnia a tűzfalakat a kiszolgáló számára, ez a megközelítés elfogadható lehet Önnek. A kiszolgáló telepítésének végén, a kiszolgálóregisztráció befejezése után egy hálózati kapcsolati jelentés megjeleníti azOkat a végponti URL-címeket az Azure-ban, amelyekkel az Azure File Syncnek kommunikálnia kell a kiválasztott régióban. A jelentés azt is ismerteti, hogy miért van szükség kommunikációra. A jelentés használatával zárolhatja a kiszolgáló körüli tűzfalakat adott URL-címekre.

Olyan konzervatívabb megközelítést is alkalmazhat, amelyben nem nyitja meg szélesen a tűzfalakat. Ehelyett korlátozhatja a kiszolgálót, hogy magasabb szintű DNS-névtérekkel kommunikáljon. További információ: Azure File Sync proxy és tűzfalbeállítások. Kövesse saját hálózatkezelési ajánlott eljárásait.

A kiszolgálótelepítési varázsló végén megnyílik egy kiszolgálóregisztrációs varázsló. Regisztrálja a kiszolgálót a Storage Sync Service Azure-erőforrásában a korábbiakból.

Ezeket a lépéseket részletesebben az üzembe helyezési útmutató ismerteti, amely tartalmazza azokat a PowerShell-modulokat, amelyeket először telepítenie kell: Az Azure File Sync-ügynök telepítése.

Használja a legújabb ügynököt. Letöltheti a Microsoft Letöltőközpontból: Azure File Sync Agent.

A sikeres telepítés és kiszolgálóregisztráció után ellenőrizheti, hogy sikeresen végrehajtotta-e ezt a lépést. Nyissa meg a Storage Sync Service erőforrást az Azure Portalon. A bal oldali menüben lépjen a Regisztrált kiszolgálók elemre. Itt láthatja a kiszolgálót.

6. fázis: Az Azure File Sync konfigurálása a Windows Server üzemelő példányán

A regisztrált helyszíni Windows Server-példánynak készen kell állnia, és csatlakoznia kell az internethez ehhez a folyamathoz.

Ez a lépés összekapcsolja a Windows Server-példányon az előző lépések során beállított összes erőforrást és mappát.

1. Jelentkezzen be az Azure Portalra.
2. Keresse meg a Storage Sync Service-erőforrást.
3. Hozzon létre egy új szinkronizálási csoportot a Storage Sync Service-erőforráson belül minden Azure-fájlmegosztáshoz. Az Azure File Sync terminológiájában az Azure-fájlmegosztás felhővégponttá válik a szinkronizálási csoport létrehozásával leírt szinkronizálási topológiában. A szinkronizálási csoport létrehozásakor adjon neki egy ismerős nevet, hogy felismerje, mely fájlok szinkronizálódnak ott. Győződjön meg arról, hogy egyező névvel hivatkozik az Azure-fájlmegosztásra.
4. A szinkronizálási csoport létrehozása után egy sor jelenik meg a szinkronizálási csoportok listájában. Válassza ki a nevet (egy hivatkozást) a szinkronizálási csoport tartalmának megjelenítéséhez. Az Azure-fájlmegosztás a felhővégpontok alatt jelenik meg.
5. Keresse meg a Kiszolgálóvégpont hozzáadása gombot. A kiépített helyi kiszolgálón lévő mappa lesz ennek a kiszolgálóvégpontnak az elérési útja.

Fontos

A felhőbeli rétegzés az Azure File Sync szolgáltatás, amely lehetővé teszi, hogy a helyi kiszolgálónak kevesebb tárkapacitása legyen, mint amennyit a felhőben tárol, de a teljes névtér elérhető. A helyileg érdekes adatok helyileg is gyorsítótárazva lesznek a gyors hozzáférés érdekében. A felhőbeli rétegzés opcionális funkció minden Azure File Sync-kiszolgálóvégponthoz.

Figyelmeztetés

Ha kevesebb tárterületet létesített a Windows Server-köteteken, mint a Linux Samba-kiszolgálón használt adatok, akkor a felhőbeli rétegzés kötelező. Ha nem kapcsolja be a felhőbeli rétegzést, a kiszolgáló nem szabadít fel helyet az összes fájl tárolásához. Állítsa be a rétegzési szabályzatot ideiglenesen a migráláshoz, és állítsa be a kötet 99 százalékos szabad területére. A migrálás befejezése után mindenképpen térjen vissza a felhőbeli rétegzési beállításokhoz, és állítsa a szabályzatot hosszú távon hasznosabb szintre.

Ismételje meg a szinkronizálási csoport létrehozásának lépéseit, és adja hozzá a megfelelő kiszolgálómappát kiszolgálóvégpontként minden olyan Azure-fájlmegosztáshoz és kiszolgálóhelyhez, amelyet konfigurálni kell a szinkronizáláshoz.

Az összes kiszolgálóvégpont létrehozása után a szinkronizálás működik. Létrehozhat egy tesztfájlt, és megtekintheti, hogy szinkronizálja a kiszolgáló helyéről a csatlakoztatott Azure-fájlmegosztásra (a szinkronizálási csoport felhővégpontjai szerint).

A két hely, a kiszolgálómappák és az Azure-fájlmegosztások egyébként üresek, és adatokra várnak. A következő lépésben fájlokat fog átmásolni az Azure File SyncHez készült Windows Server-példányba, hogy felvehesse őket a felhőbe. Ha engedélyezte a felhőbeli rétegzést, a kiszolgáló megkezdi a fájlok rétegzését, ha elfogy a kapacitás a helyi köteteken.

7. fázis: Robocopy

Az alapvető migrálási módszer a Robocopy használata fájlok másolására és az Azure File Sync használatával a szinkronizálásra.

Futtassa az első helyi példányt a Windows Server-célmappába:

1. Azonosítsa a Linux Samba-kiszolgálón található első helyet.
2. Azonosítsa azon a Windows Server-példányon található egyező mappát, amelyen már konfigurálva van az Azure File Sync.
3. Indítsa el a másolatot a Robocopy használatával.

Az alábbi Robocopy-parancs fájlokat másol a Linux Samba-kiszolgáló tárolójából a Windows Server célmappájába. A Windows Server szinkronizálja az Azure-fájlmegosztásokkal.

Ha kevesebb tárterületet létesített a Windows Server-példányon, mint amennyit a fájlok a Linux Samba-kiszolgálón vesznek fel, akkor a felhőbeli rétegzést konfigurálta. A helyi Windows Server-kötet megteltével a felhőbeli rétegzés elindul, és a már sikeresen szinkronizált fájlokat rétegzi. A felhőbeli rétegzés elegendő helyet hoz létre a másolás folytatásához a Linux Samba-kiszolgálóról. A felhőbeli rétegzés óránként egyszer ellenőrzi, hogy mi szinkronizált, és szabadítson fel lemezterületet a kötet 99 százalékos szabad területének elérése érdekében.

Lehetséges, hogy a Robocopy gyorsabban helyezi át a fájlokat, mint amennyit helyileg szinkronizálhat a felhőbe és a rétegbe, ami miatt elfogy a helyi lemezterület. A Robocopy ezután sikertelen lesz. Javasoljuk, hogy a megosztásokat olyan sorrendben dolgozza át, amely megakadályozza a problémát. Fontolja meg például, hogy ne indítsa el a Robocopy-feladatokat az összes megosztáshoz egyszerre. Vagy fontolja meg olyan megosztások áthelyezését, amelyek a Windows Server-példány aktuális szabad területéhez igazodnak. Ha a Robocopy-feladat nem sikerül, a parancsot mindig újrafuttathatja, amíg a következő tükrözési/törlési lehetőséget használja:

robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName> 

Switch	Értelmezés
/MT:n	Engedélyezi a Robocopy használatát a többszálas futtatáshoz. Az alapértelmezett érték a n 8. A maximális érték 128 szál. Bár a magas szálszám segít a rendelkezésre álló sávszélesség telítődésében, ez nem jelenti azt, hogy a migrálás mindig gyorsabb lesz több szállal. Az Azure Files-teszt 8 és 20 közötti kiegyensúlyozott teljesítményt jelez a kezdeti másolási futtatáshoz. A későbbi /MIR futtatásokat fokozatosan befolyásolja a rendelkezésre álló számítási és a rendelkezésre álló hálózati sávszélesség. Az ezt követő futtatások esetében válasszon a processzormagok számához és a szálak magonkénti számához közelebb eső szálszámértéket. Gondolja át, hogy kell-e magokat lefoglalni az éles kiszolgálókon esetleg elvégzendő egyéb feladatokhoz. Az Azure Files tesztjei azt mutatják, hogy akár 64 szál is jó teljesítményt nyújt, de csak akkor, ha a processzorok egyszerre tudják életben tartani őket.
/R:n	Maximális újrapróbálkozási szám abban az esetben, ha a fájl másolása sikertelen az első kísérlet alkalmával. A Robocopy kipróbálja n azokat az időpontokat, amikor a fájl végleges másolása nem sikerül a futtatás során. Optimalizálhatja a futtatás teljesítményét: Válasszon két vagy három értéket, ha úgy véli, hogy az időtúllépési problémák a múltban hibákat okoztak. Ez a WAN-hivatkozásoknál gyakoribb lehet. Ha úgy véli, hogy a fájl másolása sikertelen volt, ne próbálkozzon újra, vagy adjon meg egy értéket, mert aktívan használatban volt. Előfordulhat, hogy néhány másodperccel később újrapróbálkozhat, hogy a fájl használaton kívüli állapota megváltozzon. Előfordulhat, hogy a megnyitott fájlt tartalmazó felhasználóknak vagy alkalmazásoknak több órára van szükségük. Ebben az esetben a fájl elfogadása nem lett másolva, és az egyik tervezett, későbbi Robocopy-futtatás során történő elfogása sikeres lehet a fájl sikeres másolásában. Ez segít az aktuális futtatás gyorsabb befejezésében anélkül, hogy sok újrapróbálkozással meghosszabbítanák, amelyek végül a másolási hibák többségében végződnek, mivel a fájlok még mindig megnyílnak az újrapróbálkozási időtúllépés után.
/W:n	Meghatározza azt az időtartamot, amíg a Robocopy várakozik, mielőtt megpróbál egy olyan fájlt másolni, amelynek másolása korábban meghiúsult. n az újrapróbálkozások közötti várakozási másodpercek száma. /W:n gyakran használják együtt /R:n.
/B	Ugyanabban a módban futtatja a Robocopyt, amelyben egy biztonsági mentési alkalmazás használná. Ezzel a kapcsolóval a Robocopy áthelyezheti azokat a fájlokat, amelyekhez az aktuális felhasználónak nincs megfelelő jogosultsága. A biztonsági mentési kapcsoló a Robocopy parancs rendszergazdai emelt szintű konzolon vagy PowerShell-ablakban való futtatásától függ. Ha a Robocopyt használja az Azure Fileshoz, győződjön meg arról, hogy az Azure-fájlmegosztást a tárfiók hozzáférési kulcsával és egy tartományi identitással csatlakoztatja. Ha nem, előfordulhat, hogy a hibaüzenetek nem vezetnek intuitív módon a probléma megoldásához.
/MIR	(Forrás tükrözése a célra.) Lehetővé teszi, hogy a Robocopy csak a forrás és a cél közötti eltéréseket másolja. A rendszer átmásolja az üres alkönyvtárakat. A rendszer átmásolja azokat az elemeket (fájlokat vagy mappákat), amelyek megváltoztak vagy nem léteznek a célhelyen. A célhelyen megtalálható, de a forrásban nem szereplő elemek törlődnek a célhelyről. Ha ezt a kapcsolót használja, a forrás- és a célmappa struktúrájának pontosan egyeznie kell. Az egyezés azt jelenti, hogy a megfelelő forrás- és mappaszintről a célnak megfelelő mappaszintre másol. Az egyeztető másolás csak így lehet sikeres. Ha a forrás és a cél nem egyezik, a használat /MIR nagy léptékű törléshez és újramásoláshoz vezet.
/IT	Biztosítja a pontosság fenntartását bizonyos tükrözési forgatókönyvekben. Ha például egy fájl ACL-módosítást és attribútumfrissítést tapasztal két Robocopy-futtatás között, az rejtettként van megjelölve. E nélkül /ITelőfordulhat, hogy a Robocopy kihagyja az ACL-módosítást, és nem továbbítja a célhelyre.
/COPY:[copyflags]	A fájl másolásának pontossága. Alapértelmezett: /COPY:DAT. Copy flags: D= Data, A= Attributes, T= Timestamps, S= Security = NTFS ACL, O= Owner information, U= Auditing information. A naplózási információk nem tárolhatók Azure-fájlmegosztásokban.
/DCOPY:[copyflags]	A könyvtárak másolatának hűsége. Alapértelmezett: /DCOPY:DA. Másolásjelzők: D= Adatok, A= Attribútumok, T= Időbélyegek.
/NP	Meghatározza, hogy az egyes fájlok és mappák másolási folyamatállapota ne jelenjen meg. Az állapot megjelenítése jelentősen csökkenti a másolási teljesítményt.
/NFL	Meghatározza, hogy a fájlnevek ne legyenek naplózva. Javítja a másolási teljesítményt.
/NDL	Meghatározza, hogy a könyvtárnevek ne legyenek naplózva. Javítja a másolási teljesítményt.
/XD	Megadja a kizárandó könyvtárakat. Ha a Robocopyt a kötet gyökerén futtatja, fontolja meg a rejtett System Volume Information mappa kizárását. Ha a kialakításnak megfelelően használják, a benne található információk pontosan a pontos mennyiségre vonatkoznak ezen a rendszeren, és igény szerint újraépíthetők. Az adatok másolása nem lesz hasznos a felhőben, vagy ha az adatok valaha vissza lesznek másolva egy másik Windows-kötetre. A tartalom hátrahagyása nem tekinthető adatvesztésnek.
/UNILOG:<file name>	Az állapotot Unicode formátumban írja a naplófájlba. (Felülírja a meglévő naplót.)
/L	Csak tesztfuttatás esetén a fájlok csak a listára kerülnek. Nem lesznek másolva, törölve, sem időbélyeggel ellátva. Gyakran használják konzolkimenethez /TEE . Előfordulhat, hogy a mintaszkriptből származó jelzőket el /NP/NFL/NDLkell távolítani a megfelelő dokumentált teszteredmények eléréséhez.
/LFSM	Csak többrétegű tárolással rendelkező célhelyekhez. Nem támogatott, ha a cél távoli SMB-megosztás. Azt adja meg, hogy a Robocopy "alacsony szabad terület módban" működik." Ez a kapcsoló csak olyan rétegzett tárterülettel rendelkező célok esetén hasznos, amelyek a Robocopy befejeződése előtt elfogyhatnak a helyi kapacitásból. Kifejezetten az Azure File Sync felhőbeli rétegzési engedéllyel rendelkező célokkal való használathoz lett hozzáadva. Az Azure File Synctől függetlenül használható. Ebben a módban a Robocopy szünetel, amikor egy fájlmásolás miatt a célkötet szabad területe egy minimális érték alá csökken. Ez az érték a /LFSM:n jelölő formájában adható meg. A paraméter n a 2. alapban van megadva: nKB, nMBvagy nGB. Ha /LFSM explicit padlóérték nélkül van megadva, a padló a célkötet méretének 10 százalékára van beállítva. Az alacsony szabad terület mód nem kompatibilis az /MT, /EFSRAWvagy /ZB. A Támogatás a /B Windows Server 2022-ben lett hozzáadva. A Windows Server 2022 és a RoboCopy LFSM alábbi szakaszában további információt talál, beleértve a kapcsolódó hibákkal és kerülő megoldásokkal kapcsolatos részleteket.
/Z	Óvatosan másolja a fájlokat újraindítási módban. Ez a kapcsoló csak instabil hálózati környezetben ajánlott. Az extra naplózás miatt jelentősen csökkenti a másolási teljesítményt.
/ZB	Óvatosan használja az újraindítási módot. A hozzáférés megtagadása esetén áttér a biztonsági mentési mód használatára. Az ellenőrzőpontok használata miatt jelentősen csökkenti a másolási teljesítményt.

Fontos

Windows Server 2022 használatát javasoljuk. Windows Server 2019 használata esetén győződjön meg arról, hogy a legújabb javításszinten vagy legalább az operációsrendszer-frissítési KB5005103 telepítve van. Fontos javításokat tartalmaz bizonyos Robocopy-forgatókönyvekhez.

8. fázis: Felhasználói leépítés

Amikor első alkalommal futtatja a Robocopy parancsot, a felhasználók és az alkalmazások továbbra is hozzáférnek a Linux Samba-kiszolgálón lévő fájlokhoz, és esetleg módosítják őket. Lehetséges, hogy a Robocopy feldolgoz egy könyvtárat, és továbblép a következőre, majd a forráshelyen (Linux) egy felhasználó hozzáad, módosít vagy töröl egy fájlt, amely most nem lesz feldolgozva ebben az aktuális Robocopy-futtatásban. Ez várt működés.

Az első futtatás az adatok nagy részének áthelyezése a Windows Server-példányra és a felhőbe az Azure File Syncen keresztül. Ez az első példány a következőtől függően hosszú időt vehet igénybe:

• A letöltési sávszélesség.
• A feltöltési sávszélesség.
• A helyi hálózati sebesség és a Robocopy-szálak számának optimális száma.
• A Robocopy és az Azure File Sync által feldolgozandó elemek (fájlok és mappák) száma.

A kezdeti futtatás befejezése után futtassa újra a parancsot.

A második alkalommal gyorsabban fejeződik be, mert csak az utolsó futtatás óta történt módosításokat kell szállítani. A második futtatás során az új módosítások továbbra is halmozódhatnak.

Ismételje meg ezt a folyamatot, amíg meg nem győződik arról, hogy egy adott hely Robocopy-műveletének elvégzéséhez szükséges idő az állásidő elfogadható időszakán belül van.

Ha elfogadhatónak tartja az állásidőt, és készen áll arra, hogy offline állapotba állítsa a Linux-helyet, módosíthatja a megosztás gyökerében lévő ACL-eket, hogy a felhasználók többé ne férhessenek hozzá a helyhez. Vagy bármilyen más megfelelő lépést is elvégezhet, amely megakadályozza, hogy a tartalom megváltozjon ebben a mappában a Linux-kiszolgálón.

Futtasson egy utolsó Robocopy-kört. A program felveszi az esetlegesen kihagyott módosításokat. Az utolsó lépés időtartama a Robocopy-vizsgálat sebességétől függ. Az előző futtatás időtartamának mérésével megbecsülheti az időt (ami egyenlő az állásidővel).

Hozzon létre egy megosztást a Windows Server mappában, és esetleg módosítsa az elosztott fájlrendszerbeli üzembe helyezést, hogy arra mutasson. Ügyeljen arra, hogy ugyanazokat a megosztási szintű engedélyeket állítsa be, mint a Linux Samba server SMB-megosztásokon. Ha helyi felhasználókat használt a Linux Samba-kiszolgálón, ezeket a felhasználókat windowsos helyi felhasználókként kell újra létrehoznia. Le kell képeznie azokat a meglévő SID-ket is, amelyeket a Robocopy áthelyezett a Windows Server-példányra az új Helyi Windows Server-felhasználók SID-jéhez. Ha Active Directory-fiókokat és ACL-eket használt, a Robocopy az aktuális módon helyezi át őket, és nincs szükség további műveletekre.

Befejezte egy megosztás vagy megosztáscsoport áttelepítését egy közös gyökérbe vagy kötetbe (az 1. fázisból való leképezéstől függően).

Megpróbálhat néhány példányt párhuzamosan futtatni. Javasoljuk, hogy egyszerre egy Azure-fájlmegosztás hatókörét dolgozza fel.

Figyelmeztetés

Miután áthelyezte az összes adatot a Linux Samba-kiszolgálóról a Windows Server-példányra, és az áttelepítés befejeződött, térjen vissza az Azure Portal összes szinkronizálási csoportjához. Állítsa be a felhőbeli rétegzési kötet szabad területének százalékos arányát a gyorsítótár-kihasználtsághoz jobban megfelelő értékre, például 20 százalékra.

A felhőbeli rétegzési kötet szabad területére vonatkozó szabályzat kötetszinten működik, és valószínűleg több kiszolgálóvégpont szinkronizálódik belőle. Ha még egy kiszolgálóvégponton is elfelejti módosítani a szabad területet, a szinkronizálás továbbra is alkalmazza a legkorlátozóbb szabályt, és megkísérli 99 százalékon tartani a szabad lemezterületet. Előfordulhat, hogy a helyi gyorsítótár nem a várt módon fut. A teljesítmény akkor lehet elfogadható, ha a cél egy olyan kötet névtere, amely csak ritkán használt archiválási adatokat tartalmaz, és a többi tárhelyet egy másik forgatókönyvhöz szeretné lefoglalni.

Hibaelhárítás

A leggyakoribb probléma az, hogy a Robocopy parancs meghiúsul, és a kötet megtelt a Windows Server oldalán. A felhőbeli rétegzés óránként egyszer működik, hogy kiürítse a tartalmat a szinkronizált helyi Windows Server-lemezről. A cél a kötet 99 százalékos szabad területének elérése.

A szinkronizálási folyamat és a felhőbeli rétegzés szabadítson fel lemezterületet. Ezt megfigyelheti a Windows Server Fájlkezelő.

Ha a Windows Server-példány elegendő kapacitással rendelkezik, a parancs újrafuttatása megoldja a problémát. Semmi sem törik meg ebben a helyzetben, és magabiztosan haladhat előre. A parancs ismételt futtatásának kellemetlensége az egyetlen következmény.

Az Azure File Sync hibáinak elhárításához tekintse meg a következő szakaszban található hivatkozást.

Következő lépések

Az alábbi cikkek az Azure File Sync speciális lehetőségeit, ajánlott eljárásait és hibaelhárítási súgóját tartalmazzák.

• Az Azure File Sync áttekintése
• Az Azure File Sync üzembe helyezése
• Az Azure File Sync hibaelhárítása