Sdílet prostřednictvím

Migrace ze služby Network Attached Storage (NAS) do hybridního cloudového nasazení s využitím Synchronizace souborů Azure

Tento článek o migraci je jedním z několika zahrnujících klíčová slova NAS a Synchronizace souborů Azure. Zkontrolujte, jestli se tento článek týká vašeho scénáře:

  • Zdroj dat: Síťové připojené úložiště (NAS)
  • Trasa migrace: NAS ⇒ Windows Server ⇒ nahrání a synchronizace se sdílenými složkami Azure
  • Ukládání souborů do mezipaměti místně: Ano, konečným cílem je nasazení Synchronizace souborů Azure.

Pokud se váš scénář liší, projděte tabulku migračních průvodců.

Azure File Sync funguje na místech s přímým připojením úložiště (DAS) a nepodporuje synchronizaci s místy síťově připojeného úložiště (NAS). Díky této skutečnosti je migrace souborů nezbytná a tento článek vás provede plánováním a provedením takové migrace.

Platí pro

Typ sdílené složky protokol SMB NFS
Sdílené soubory úrovně Standard (GPv2), LRS/ZRS Yes No
Standardní sdílené úložiště (GPv2), GRS/GZRS Yes No
Sdílené složky úrovně Premium (FileStorage), LRS/ZRS Yes No

Cíle migrace

Cílem je přesunout sdílené složky SMB na zařízení NAS na Windows Server a pak využít Synchronizace souborů Azure pro hybridní cloudové nasazení. Obecně platí, že migrace musí být provedeny způsobem, který zaručuje integritu produkčních dat a její dostupnost během migrace. Druhá možnost vyžaduje zachování výpadků na minimum, aby se vešla do časových intervalů pravidelné údržby nebo jen mírně překročila.

Přehled migrace

Jak je uvedeno v Migrace na soubory Azure SMB, je důležité použít správný nástroj pro kopírování a metodiku. Vaše zařízení NAS vystavuje sdílené složky SMB přímo v místní síti. Soubory můžete přesunout pomocí nástroje Azure Storage Mover nebo RoboCopy.

Fáze 1: Určete, kolik sdílených složek Azure potřebujete

V tomto kroku určíte, kolik sdílených složek Azure potřebujete. Jedna instance Windows Serveru (nebo cluster) může synchronizovat až 30 sdílených složek Azure.

Na svazcích můžete mít více složek, které aktuálně sdílíte místně jako SMB sdílené složky pro uživatele a aplikace. Nejjednodušší způsob, jak si tento scénář představit, je zobrazení lokální sdílené složky, která odpovídá 1:1 sdílené složce Azure. Pokud máte dostatečný počet sdílených složek, které jsou nižší než 30 pro jednu instanci Windows Serveru, doporučujeme mapování 1:1.

Pokud máte více než 30 sdílených složek, mapování místní sdílené složky 1:1 na sdílenou složku Azure je často zbytečné. Zvažte následující možnosti.

Seskupení pro sdílení

Pokud má například vaše personální oddělení 15 sdílených složek, můžete zvážit uložení všech dat lidských zdrojů do jedné sdílené složky Azure. Uložení několika místních sdílených složek do jedné sdílené složky Azure vám nebrání v vytváření obvyklých 15 sdílených složek SMB na místní instanci Windows Serveru. To znamená, že uspořádáte kořenové složky těchto 15 sdílených složek jako podsložky do společné složky. Tuto společnou složku pak synchronizujete do sdíleného úložiště Azure. Tímto způsobem potřebujete jenom jednu sdílenou složku Azure v cloudu pro tuto skupinu místních sdílených složek.

Synchronizace objemu

Synchronizace souborů Azure podporuje synchronizaci kořenového adresáře svazku se sdílenou složkou Azure. Pokud synchronizujete kořen svazku, všechny podsložky a soubory přejdou do stejné sdílené složky Azure.

Synchronizace kořenového adresáře svazku není vždy nejlepší volbou. Synchronizace více umístění má několik výhod. To například pomáhá udržet počet položek v nižším rozsahu synchronizace. Otestujeme sdílení souborů Azure a Azure File Sync se 100 miliony položek (soubory a složky) na jedno sdílení. Osvědčeným postupem je ale snažit se zachovat číslo nižší než 20 milionů nebo 30 milionů v rámci jednoho podílu.

Nastavení Synchronizace souborů Azure s nižším počtem položek není výhodné jenom pro synchronizaci souborů. Nižší počet položek také přináší výhody pro scénáře, jako jsou tyto:

  • Počáteční prohledávání cloudového obsahu se může dokončit rychleji, což zase snižuje čekání na zobrazení oboru názvů na serveru s povolenou synchronizací souborů Azure.
  • Obnovení ze sdílené složky Azure na straně cloudu je rychlejší.
  • Zotavení po havárii místního serveru může výrazně zrychlit.
  • Změny provedené přímo ve sdílené složce Azure (mimo synchronizaci) je možné detekovat a synchronizovat rychleji.

Tip

Pokud nevíte, kolik souborů a složek máte, podívejte se na nástroj TreeSize z JAM Software.

Strukturovaný přístup k mapě nasazení

Před nasazením cloudového úložiště v pozdějším kroku je důležité vytvořit mapu mezi místními složkami a sdílenými složkami Azure. Toto mapování informuje o tom, kolik prostředků skupiny synchronizace souborů Azure a které zřídíte. Skupina synchronizace spojuje sdílenou složku Azure a složku na vašem serveru a vytvoří synchronizační připojení.

Pokud chcete optimalizovat mapu a rozhodnout se, kolik sdílených složek Azure potřebujete, projděte si následující omezení a osvědčené postupy:

  • Server, na kterém je nainstalovaný agent Synchronizace souborů Azure, se může synchronizovat s až 30 sdílenými složkami Azure.

  • Sdílená složka Azure se nasadí do účtu úložiště. Díky tomuto uspořádání je účet úložiště cílem škálování pro čísla výkonu, jako jsou IOPS a propustnost.

    Při nasazování sdílených složek Azure věnujte pozornost omezením IOPS účtu úložiště. V ideálním případě byste měli namapovat sdílené soubory 1:1 s účty úložiště. Toto mapování ale nemusí být vždy možné kvůli různým omezením a omezením, a to jak z vaší organizace, tak z Azure. Pokud nemůžete nasadit jenom jednu sdílenou složku v jednom účtu úložiště, zvažte, které sdílené složky budou vysoce aktivní a které sdílené složky budou méně aktivní. Nesdílejte nejžhavější sdílené složky do stejného účtu úložiště.

    Pokud plánujete přenést aplikaci do Azure, která bude nativně využívat Azure sdílenou složku, možná budete potřebovat vyšší výkon z vaší Azure sdílené složky. Pokud je tento typ použití možnost, i v budoucnu, je nejlepší vytvořit jednu standardní sdílenou složku Azure ve svém vlastním účtu úložiště.

  • Existuje limit 250 účtů úložiště na předplatné na oblast Azure.

Tip

Na základě těchto informací je často nutné seskupit několik složek nejvyšší úrovně na svazcích do nového společného kořenového adresáře. Pak tento nový kořenový adresář a všechny složky, které jste do něj seskupili, synchronizujete s jednou sdílenou složkou Azure. Tato technika umožňuje zůstat v limitu 30 synchronizací sdílených souborů Azure na server.

Toto seskupení v rámci společného kořenového adresáře nemá vliv na přístup k vašim datům. Seznamy ACL zůstanou tak, jak jsou. Stačí upravit všechny cesty ke sdíleným složkám (například sdílené složky SMB nebo NFS), které můžete mít ve složkách místního serveru, které jste teď změnili na společný kořenový adresář. Nic jiného se nezmění.

Důležité

Nejdůležitější vektor škálování pro Synchronizace souborů Azure je počet položek (souborů a složek), které je potřeba synchronizovat. Další podrobnosti najdete v cílech škálování synchronizace souborů Azure .

Je možné, že ve vaší situaci se sada složek může logicky synchronizovat se stejnou sdílenou složkou Azure (pomocí společného kořenového přístupu uvedeného výše). Přesto ale může být lepší znovu seskupit složky, aby se synchronizovaly se dvěma sdílenými složkami Azure místo jedné. Tento přístup můžete využít k udržení počtu souborů a složek v rámci každé sdílené složky vyváženého na serveru. Můžete také rozdělit místní sdílené složky a synchronizovat mezi další místní servery a přidat tak možnost synchronizace se 30 dalšími sdílenými složkami Azure na další server.

Důležité

Nejdůležitější vektor škálování pro Synchronizace souborů Azure je počet položek (souborů a složek), které je potřeba synchronizovat. Další podrobnosti najdete v cílech škálování synchronizace souborů Azure.

Běžné scénáře synchronizace souborů a důležité informace

Scénář synchronizace Podporováno Důležité informace (nebo omezení) Řešení (nebo alternativní řešení)
Souborový server s více disky nebo svazky a více sdílenými složkami do stejné cílové sdílené složky Azure (konsolidace) Ne Cílová sdílená složka Azure (koncový bod cloudu) podporuje synchronizaci pouze s jednou skupinou synchronizace.

Skupina synchronizace podporuje pouze jeden koncový bod serveru na registrovaný server.		 1) Začněte synchronizací jednoho disku (jeho kořenového svazku) s cílovou sdílenou složkou Azure. Počínaje největším diskem nebo svazkem vám pomůže místní požadavky na úložiště. Nakonfigurujte vrstvení cloudu tak, aby vrstvila všechna data do cloudu, abyste mohli uvolnit místo na disku souborového serveru. Přesuňte data z jiných svazků nebo sdílených složek do aktuálního svazku, který se synchronizuje. Pokračujte v krocích po druhém, dokud nebudou všechna data vrstvené do cloudu nebo se migrují.
2) Cílí na jeden kořenový svazek (disk) najednou. Vrstvení cloudu slouží k vrstvení všech dat do cílové sdílené složky Azure. Odeberte koncový bod serveru ze skupiny synchronizace, znovu vytvořte koncový bod s dalším kořenovým svazkem nebo diskem, synchronizujte a opakujte proces. Mějte na paměti, že možná budete muset agenta přeinstalovat.
3) Doporučujeme použít více cílových sdílených složek Azure (stejný nebo jiný účet úložiště na základě požadavků na výkon).
Souborový server s jedním svazkem a více sdílenými složkami do stejné cílové sdílené složky Azure (konsolidace) Ano Nemůžete mít více koncových bodů serveru pro každou zaregistrovanou synchronizaci serveru se stejnou cílovou sdílenou složkou Azure (stejně jako v předchozím scénáři). Synchronizujte kořen svazku, který obsahuje více sdílených složek nebo složek nejvyšší úrovně.
Souborový server s více sdílenými složkami nebo svazky do více sdílených složek Azure v rámci jednoho účtu úložiště (mapování sdílených složek 1:1) Ano Jedna instance Windows Serveru (nebo cluster) může synchronizovat až 30 sdílených složek Azure.

Účet úložiště se používá ke škálování výkonu. IOPS a propustnost se sdílí napříč sdílenými složkami.

Udržujte počet položek na skupinu synchronizace do 100 milionů položek (souborů a složek) na sdílenou složku. Nejlepší je zůstat nižší než 20 nebo 30 milionů na podíl.		 1) Použijte více skupin synchronizace (počet skupin synchronizace = počet sdílených složek Azure k synchronizaci).
2) V tomto scénáři je možné synchronizovat pouze 30 sdílených složek najednou. Pokud na souborovém serveru máte více než 30 sdílených složek, snižte počet kořenových nebo nejvyšších složek na zdrojovém serveru pomocí seskupování sdílených složek a synchronizace svazků.
3) Použijte další místní servery Synchronizace souborů Azure a rozdělte nebo přesuňte data na tyto servery, abyste mohli obejít omezení zdrojové instance Windows Serveru.
Souborový server s několika sdílenými složkami nebo svazky do několika sdílených složek Azure v rámci jiného účtu úložiště (mapování sdílených složek 1:1) Ano Jedna instance Windows Serveru (nebo cluster) může synchronizovat až 30 sdílených složek Azure (stejný nebo jiný účet úložiště).

Udržujte počet položek na skupinu synchronizace do 100 milionů položek (souborů a složek) na sdílenou složku. Nejlepší je zůstat nižší než 20 nebo 30 milionů na podíl.		 Stejné jako u předchozího přístupu.
Několik souborových serverů s jedním kořenovým svazkem nebo sdílenou složkou do stejné cílové sdílené složky Azure (konsolidace) Ne Skupina synchronizace nemůže použít koncový bod cloudu (sdílenou složku Azure), který je už nakonfigurovaný v jiné skupině synchronizace.

Přestože skupina synchronizace může mít koncové body serveru na různých souborových serverech, soubory se nedají odlišit.		 Postupujte podle pokynů v prvním scénáři s dalšími aspekty cílení na jeden souborový server najednou.
Topologie napříč tenanty (použití spravované identity napříč tenanty) Ne Služba synchronizace úložiště, prostředek serveru (server s podporou Azure Arc nebo virtuální počítač Azure), spravovaná identita a přiřazení RBAC v účtu úložiště musí být ve stejném tenantovi Microsoft Entra. Topologie napříč tenanty se nepodporují. Nastavení mezi tenanty při ověřování a autorizaci dojde k selhání a server se nemůže připojit. Pokud chcete pokračovat, ujistěte se, že jsou všechny prostředky (synchronizační služba, server, spravovaná identita a přiřazení RBAC) vytvořeny ve stejném tenantovi Microsoft Entra.

Vytvořte tabulku mapování

Diagram znázorňující příklad tabulky mapování Stáhněte si následující soubor, abyste si mohli prožít obsah tohoto obrázku a použít ho.

Pomocí předchozích informací určete, kolik sdílených složek Azure potřebujete a které části stávajících dat skončí ve které sdílené složce Azure.

Vytvořte tabulku, která zaznamenává vaše myšlenky, abyste na ni mohli odkazovat, když potřebujete. Udržování přehledu je důležité, protože ztráta podrobností o plánu mapování může probíhat snadno, když zřizujete mnoho prostředků Azure najednou. Stáhněte si následující excelový soubor, který se použije jako šablona, aby vám pomohl vytvořit mapování.


Ikona Aplikace Excel, která nastaví kontext pro stažení Stáhněte šablonu mapování oboru názvů.

Fáze 2: Zřízení vhodného místního Windows Serveru

  • Vytvořte virtuální počítač s Windows Serverem 2022 nebo Windows Serverem 2019 nebo nasaďte fyzický server. Podporován je také cluster pro převzetí služeb při selhání systému Windows Server.

  • Zřízení nebo přidání úložiště s přímým přístupem (DAS ve srovnání s NAS, což se nepodporuje).

    Množství úložiště, které zřídíte, může být menší, než jaké aktuálně používáte na zařízení NAS. Tato volba konfigurace vyžaduje, abyste také využili funkci vrstvení cloudu služby Azure File Sync. Když ale soubory zkopírujete z většího prostoru NAS na menší svazek Windows Serveru v pozdější fázi, budete muset pracovat v dávkách:

    1. Přesuňte sadu souborů, která se vejde na disk
    2. Nechat synchronizaci souborů a organizaci dat v cloudu se aktivovat
    3. Když na svazku vytvoříte více volného místa, pokračujte další dávkou souborů. Případně si projděte příkaz RoboCopy v části RoboCopy tohoto článku, kde najdete nový /LFSM přepínač. Použití /LFSM může výrazně zjednodušit úlohy RoboCopy, ale není kompatibilní s některými dalšími přepínači RoboCopy, na kterých byste mohli záviset. Přepínač použijte /LFSM pouze v případech, kdy je cílem migrace místní úložiště. Není podporováno, pokud je cílem vzdálená sdílená složka SMB.

    Tomuto přístupu dávkování se můžete vyhnout vyhrazením ekvivalentního prostoru na Windows Serveru, který vaše soubory zabírají na NAS zařízení. Zvažte odstranění duplicitních dat v NAS nebo Windows. Pokud nechcete na Windows Server trvale vyhradit tuto velkou kapacitu úložiště, můžete po migraci a před úpravou zásad vrstvení cloudu snížit velikost svazku. Tím se vytvoří menší místní mezipaměť sdílených složek Azure.

Konfigurace prostředků (výpočetní prostředky a paměť RAM) nasazeného Windows Serveru závisí hlavně na počtu položek (souborů a složek), které budete synchronizovat. Pokud máte nějaké obavy, doporučujeme použít konfiguraci vyššího výkonu.

Zjistěte, jak nastavit velikost Windows Serveru na základě počtu položek (souborů a složek), které potřebujete synchronizovat.

Poznámka:

Dříve propojený článek představuje tabulku s rozsahem pro paměť serveru (RAM). Můžete se orientovat na menší číslo serveru, ale očekáváte, že počáteční synchronizace může trvat výrazně déle.

Fáze 3: Nasazení cloudového prostředku Synchronizace souborů Azure

K dokončení tohoto kroku potřebujete přihlašovací údaje k předplatnému Azure.

Základní prostředek, který se má nakonfigurovat pro Synchronizace souborů Azure, se nazývá služba synchronizace úložiště. Doporučujeme nasadit jenom jeden pro všechny servery, které teď nebo v budoucnu synchronizují stejnou sadu souborů. Vytvořte více služeb synchronizace úložiště pouze v případě, že máte různé sady serverů, které nesmí nikdy vyměňovat data. Můžete mít například servery, které nesmí nikdy synchronizovat stejnou sdílenou složku Azure. V opačném případě je osvědčeným postupem použití jedné služby synchronizace úložiště.

Zvolte oblast Azure pro službu synchronizace úložiště, která je blízko vaší polohy. Všechny ostatní cloudové prostředky musí být nasazené ve stejné oblasti. Pro zjednodušení správy vytvořte ve svém předplatném novou skupinu prostředků, ve které jsou prostředky synchronizace a úložiště.

Další informace najdete v části věnované nasazení služby synchronizace úložiště v článku o nasazení Synchronizace souborů Azure. Postupujte pouze v této části článku. V dalších krocích budou odkazy na další části článku.

Fáze 4: Nasazení prostředků úložiště Azure

V této fázi si projděte tabulku mapování z fáze 1 a použijte ji ke zřízení správného počtu účtů úložiště Azure a sdílených složek v nich.

Sdílená složka Azure je uložená v cloudu v účtu úložiště Azure. Tady platí další úroveň aspektů výkonu.

Pokud máte vysoce aktivní sdílené složky (sdílené složky používané mnoha uživateli nebo aplikacemi), můžou dvě sdílené složky Azure dosáhnout limitu výkonu účtu úložiště.

Osvědčeným postupem je nasadit účty úložiště s jednou sdílenou složkou. Pokud máte archivní sdílené složky nebo očekáváte nízkou denní aktivitu, můžete sloučit více sdílených složek Azure do stejného účtu úložiště.

Tyto aspekty platí více pro přímý přístup ke cloudu (prostřednictvím virtuálního počítače Azure) než pro Synchronizace souborů Azure. Pokud plánujete používat pouze Synchronizace souborů Azure u těchto sdílených složek, seskupení několika do jednoho účtu úložiště Azure je v pořádku.

Pokud jste vytvořili seznam svých sdílení, měli byste každé sdílení namapovat na účet úložiště, ve kterém bude.

V předchozí fázi jste určili odpovídající počet akcií. V tomto kroku máte mapování účtů úložiště na sdílení souborů. Teď nasaďte odpovídající počet účtů úložiště Azure s odpovídajícím počtem sdílených složek Azure.

Ujistěte se, že je oblast každého z vašich účtů úložiště stejná a odpovídá oblasti prostředku služby synchronizace úložiště, který jste už nasadili.

Upozornění

Pokud vytvoříte sdílenou složku Azure s limitem 100 TiB, může tato sdílená složka používat pouze místně redundantní úložiště nebo možnosti redundance zónově redundantního úložiště. Před použitím 100 sdílených složek TiB zvažte redundanci úložiště.

Sdílené složky Azure se ve výchozím nastavení vytvářejí s limitem 5 TiB. Postupujte podle kroků v Vytvoření sdílené složky Azure k vytvoření velkého sdílení souborů.

Dalším aspektem při nasazování účtu úložiště je redundance služby Azure Storage. Viz možnosti redundance služby Azure Storage.

Důležité jsou také názvy vašich prostředků. Pokud například seskupíte více sdílených složek pro personální oddělení do účtu úložiště Azure, měli byste účet úložiště pojmenovat odpovídajícím způsobem. Podobně když pojmenujete sdílené složky Azure, měli byste použít názvy podobné těm, které se používají pro jejich místní protějšky.

Fáze 5: Nasazení agenta Synchronizace souborů Azure

V této části nainstalujete agenta Synchronizace souborů Azure na instanci Windows Serveru.

Průvodce nasazením vysvětluje, že je potřeba vypnout konfiguraci rozšířeného zabezpečení aplikace Internet Explorer. Toto bezpečnostní opatření se nevztahuje na Synchronizace souborů Azure. Vypnutím této možnosti se můžete ověřit v Azure bez jakýchkoli problémů.

Otevřete PowerShell. Pomocí následujících příkazů nainstalujte požadované moduly PowerShellu. Až se zobrazí výzva, nezapomeňte nainstalovat celý modul a poskytovatele NuGet.

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

Pokud máte problémy s připojením k internetu ze serveru, je teď čas je vyřešit. Synchronizace souborů Azure používá jakékoli dostupné síťové připojení k internetu. Vyžadování proxy serveru pro přístup k internetu je také podporováno. Proxy server pro celý počítač teď můžete nakonfigurovat nebo během instalace agenta zadat proxy server, který bude používat jenom Synchronizace souborů Azure.

Pokud pro vás otevření brány firewall pro server znamená konfiguraci proxy, může být tento přístup přijatelný. Na konci instalace serveru po dokončení registrace serveru se v sestavě připojení k síti zobrazí přesné adresy URL koncových bodů v Azure, se kterými Synchronizace souborů Azure musí komunikovat pro vybranou oblast. Zpráva vám také řekne, proč je komunikace potřeba. Sestavu můžete použít k omezení přístupu serveru pomocí firewallu na určité adresy URL.

Můžete také využít konzervativnější přístup, ve kterém neotevřete brány firewall zcela. Místo toho můžete server omezit na komunikaci s obory názvů DNS vyšší úrovně. Další informace najdete v tématu nastavení synchronizace souborů Azure proxy serveru a brány firewall. Postupujte podle vlastních osvědčených postupů pro sítě.

Na konci průvodce instalací serveru se otevře průvodce registrací serveru. Zaregistrujte server ke zdroji Azure ve vaší službě Storage Sync z předchozí části.

Tyto kroky jsou podrobněji popsány v průvodci nasazením, který obsahuje moduly PowerShellu, které byste měli nainstalovat jako první: instalaci agenta Azure File Sync.

Použijte nejnovějšího agenta. Můžete si ho stáhnout z webu Microsoft Download Center: Synchronizace souborů Azure Agent.

Po úspěšné instalaci a registraci serveru můžete ověřit, že jste tento krok úspěšně dokončili. Na webu Azure Portal přejděte k prostředku služby synchronizace úložiště. V nabídce vlevo přejděte na Registrované servery. Zobrazí se tam váš server.

Fáze 6: Konfigurace Synchronizace souborů Azure na Windows Serveru

Pro tento proces musí být zaregistrovaný místní Windows Server připravený a připojený k internetu.

Tento krok spojuje všechny prostředky a složky, které jste nastavili v instanci Windows Serveru během předchozích kroků.

  1. Přihlaste se k portálu Azure.
  2. Vyhledejte prostředek služby synchronizace úložiště.
  3. Vytvořte novou skupinu synchronizace v rámci prostředku služby synchronizace úložiště pro každou sdílenou složku Azure. V Synchronizace souborů Azure terminologii se sdílená složka Azure stane koncovým bodem cloudu v topologii synchronizace, kterou popisujete vytvořením skupiny synchronizace. Když vytvoříte skupinu synchronizace, dejte jí známý název, abyste rozpoznali, která sada souborů se tam synchronizuje. Ujistěte se, že odkazujete na sdílenou složku Azure s odpovídajícím názvem.
  4. Po vytvoření skupiny synchronizace se v seznamu skupin synchronizace zobrazí řádek. Vyberte název (odkaz) a zobrazte obsah skupiny synchronizace. Sdílenou složku Azure uvidíte v části Koncové body cloudu.
  5. Vyhledejte tlačítko Přidat koncový bod serveru. Složka na místním serveru, který jste zřídili, se stane cestou pro tento koncový bod serveru.

Důležité

Vrstvení cloudu je funkce Synchronizace souborů Azure, která umožňuje místnímu serveru mít menší kapacitu úložiště, než je uložená v cloudu, ale mít k dispozici úplný obor názvů. Místně zajímavá (horká) data se také ukládají místně do mezipaměti pro rychlý přístup. Vrstvení cloudu je volitelná funkce v rámci Azure File Sync "serverový koncový bod".

Varování

Pokud jste na svazcích s Windows Serverem zřídili méně úložiště než data použitá na zařízení NAS, je cloudové vrstvení povinné. Pokud vrstvení cloudu nezapnete, server nebude uvolnit místo pro ukládání všech souborů. Nastavte zásady vrstvení dočasně pro migraci na 99 % volného místa svazku. Po dokončení migrace se nezapomeňte vrátit k nastavení vrstvení cloudu a nastavit ji na užitečnější úroveň.

Opakujte kroky vytvoření skupiny synchronizace a přidání odpovídající složky serveru jako koncového bodu serveru pro všechny sdílené složky Azure nebo umístění serveru, která je potřeba nakonfigurovat pro synchronizaci.

Po vytvoření všech koncových bodů serveru funguje synchronizace. Můžete vytvořit testovací soubor a zobrazit synchronizaci z umístění serveru do připojené sdílené složky Azure (jak je popsáno koncovým bodem cloudu ve skupině synchronizace).

Obě umístění, složky serveru i sdílené složky Azure, jsou jinak prázdná a čekají na data, která mohou přijít z jednoho z těchto umístění. V dalším kroku začnete kopírovat soubory do Windows Serveru, aby je služba Azure File Sync přesunula do cloudu. Pokud jste povolili vrstvení cloudu, server začne vrstvit soubory, pokud na místních svazcích dojde k výpadku kapacity.

Fáze 7: Kopírování dat pomocí nástroje Azure Storage Mover nebo RoboCopy

Teď můžete pomocí nástroje Azure Storage Mover nebo RoboCopy zkopírovat data ze zařízení NAS na Windows Server a pomocí Synchronizace souborů Azure přesunout data do sdílených složek Azure. Tato příručka používá RoboCopy pro počáteční kopírování. Pokud chcete místo toho použít nástroj Azure Storage Mover, přečtěte si téma Migrace do sdílených složek Azure SMB pomocí nástroje Azure Storage Mover.

Spusťte první místní kopii do cílové složky Windows Serveru:

  • Určete první umístění na zařízení NAS.
  • Identifikujte odpovídající složku na Windows Serveru, která už má Synchronizace souborů Azure nakonfigurovaná.
  • Spusťte kopírování.

Následující příkaz RoboCopy zkopíruje soubory z úložiště NAS do cílové složky Windows Serveru. Windows Server ho synchronizuje se sdílenými složkami Azure.

Pokud jste na Windows Serveru zřídili méně úložiště, než zabírají vaše soubory zařízení NAS, nakonfigurovali jste vrstvení cloudu. S tím, jak se místní svazek Windows Serveru zaplní, se vrstvení cloudu spustí a vrství soubory, které se už úspěšně synchronizovaly. Vrstvení cloudu vygeneruje dostatek místa k tomu, aby bylo možné pokračovat v kopírování z NAS zařízení. Vrstvení cloudu kontroluje jednou za hodinu, aby zjistilo, co se synchronizovalo, a uvolnilo místo na disku, abyste dosáhli 99% volného místa na svazku.

Je možné, že RoboCopy přesouvá soubory rychleji, než je možné synchronizovat do cloudu a ukládat lokálně, což vede k vyčerpání místního úložného prostoru. V tomto případě RoboCopy selže. Doporučujeme pracovat se sdílenými složkami v posloupnosti, která tomu brání – například nespouštět úlohy kopírování pro všechny sdílené složky najednou nebo přesouvat jenom sdílené složky, které se vejdou do aktuálního množství volného místa na Windows Serveru.

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>
Přepínač Význam
/MT:n Umožňuje, aby nástroj Robocopy běžel ve více vláknech. Výchozí hodnota je n 8. Maximum je 128 vláken. I když vysoký počet vláken pomáhá saturovat dostupnou šířku pásma, neznamená to, že migrace bude vždy rychlejší s více vlákny. Testy se službou Soubory Azure ukazují, že 8 až 20 testů poskytuje vyvážený výkon při počátečním spuštění kopírování. Následná /MIR spuštění jsou postupně ovlivněná dostupnými výpočetními prostředky a dostupnou šířkou pásma sítě. U následných spuštění slaďte hodnotu počtu vláken více s počtem jader procesoru a počtem vláken na jádro. Zvažte, jestli musí být jádra vyhrazená pro jiné úlohy, které může mít produkční server. Testy se službou Azure Files ukázaly, že až 64 vláken vede k dobrému výkonu, ale pouze v případě, že je procesory můžou udržovat naživu najednou.
/R:n Maximální počet opakování pro soubor, který se při prvním pokusu nepodaří zkopírovat. Robocopy se pokusí n krát, než se kopírování souboru během spuštění trvale nezdaří. Můžete optimalizovat výkon běhu: Zvolte hodnotu dvou nebo tří, pokud se domníváte, že problémy s vypršením časového limitu způsobily dřívější selhání. To může být častější přes propojení WAN. Pokud se domníváte, že se soubor nepodařilo zkopírovat, protože se aktivně používal, zvolte bez opakování nebo hodnotu jedna. Zkoušení znovu o několik sekund později nemusí být dostatečná doba, aby se stav užívání souboru změnil. Uživatelé nebo aplikace, které mají soubor otevřený, můžou potřebovat víc času. Pokud přijmete skutečnost, že soubor nebyl zkopírován, a zachytíte ho při některém z vašich plánovaných následných spuštění Robocopy, může se nakonec podařit jej úspěšně zkopírovat. To pomáhá aktuálnímu procesu dokončit se rychleji, aniž by byl prodloužen mnoha opakováními, která nakonec vedou k většině selhání kopírování kvůli souborům, které jsou stále otevřené po uplynutí časového limitu pro opakování.
/W:n Specifikuje čas, kdy nástroj Robocopy čeká před pokusem o zkopírování souboru, který se během předchozího pokusu nepodařilo zkopírovat. n je počet sekund čekání mezi opakovanými pokusy. /W:n se často používá společně s /R:n.
/B Spustí nástroj Robocopy ve stejném režimu jako zálohovací aplikace. Tento přepínač umožňuje nástroji Robocopy přesouvat soubory, pro které nemá aktuální uživatel oprávnění. Přepínač zálohování závisí na spuštění příkazu Robocopy v konzole správce se zvýšenými oprávněními nebo v okně PowerShellu. Pokud používáte Robocopy pro Azure Files, ujistěte se, že sdílenou složku Azure připojíte pomocí přístupového klíče účtu úložiště a identity domény. Pokud to neuděláte, nemusí vás chybové zprávy intuitivně vést k vyřešení problému.
/MIR (Udělat zrcadlovou kopii zdroje do cíle.) Umožňuje nástroji Robocopy kopírovat pouze rozdíly mezi zdrojem a cílem. Zkopírují se prázdné podadresáře. Položky (soubory nebo složky), které se změnily nebo neexistují v cíli, se zkopírují. Položky, které existují v cíli, ale ne ve zdroji, se vyprázdní (odstraní) z cíle. Při použití tohoto přepínače musí být struktury zdrojové a cílové složky naprosto stejné. Porovnávání znamená kopírování ze správné úrovně zdroje a složky na odpovídající úroveň složky v cíli. Pouze tehdy může být kopírování pro dohnání úspěšné. Pokud dojde k neshodě zdroje a cíle, použití /MIR povede k rozsáhlým odstraněním a kopírováním.
/IT Zajišťuje zachování věrnosti v určitých zrcadlových scénářích.
Pokud například soubor zaznamená změnu seznamu ACL a aktualizaci atributu mezi dvěma spuštěními Robocopy, označí se jako skrytý. Bez /IT, změna seznamu ACL může být opomenuta nástrojem Robocopy a nebude přenesena do cílového umístění.
/COPY:[copyflags] Věrnost kopie souboru. Výchozí hodnota: /COPY:DAT. Kopírovat příznaky: D= Data, A= Atributy, T= Časová razítka, S= Zabezpečení = seznamy ACL SYSTÉMU SOUBORŮ NTFS, O= Informace vlastníka, U= Auditing information. Informace o auditování nelze ukládat ve sdílené složce Azure.
/DCOPY:[copyflags] Zachování věrnosti při kopírování adresářů. Výchozí hodnota: /DCOPY:DA. Kopírovat příznaky: D= Data, A= Atributy, T= Časová razítka.
/NP Specifikuje, že průběh kopírování se nebude zobrazovat pro každý soubor a složku. Zobrazení průběhu výrazně snižuje výkon kopírování.
/NFL Specifikuje, že se neprotokolují názvy souborů. Zlepšuje výkon kopírování.
/NDL Specifikuje, že se neprotokolují názvy adresářů. Zlepšuje výkon kopírování.
/XD Určuje adresáře, které se mají vyloučit. Při spuštění Nástroje Robocopy v kořenovém adresáři svazku zvažte vyloučení skryté System Volume Information složky. Pokud se používá tak, jak je navrženo, všechny informace v tomto přesném systému jsou specifické pro přesný objem a lze je znovu vytvořit na vyžádání. Kopírování těchto informací nebude užitečné v cloudu nebo když se data někdy zkopírují zpět do jiného svazku Windows. Ponechání tohoto obsahu by nemělo být považováno za ztrátu dat.
/UNILOG:<file name> Zapíše stav do souboru protokolu jako Unicode. (Přepíše existující protokol.)
/L Pouze pro testovací spuštění
Soubor pouze zobrazí seznam. Nebudou zkopírovány, nebudou odstraněny a nebudou opatřeny časovým razítkem. Často se používá s /TEE pro výstup konzole. Příznaky z ukázkového skriptu, jako je například /NP, /NFL a /NDL, možná bude potřeba odebrat, abyste dosáhli řádně zdokumentovaných výsledků testu.
/LFSM Pouze pro cíle s vrstveným úložištěm. Když je cílem vzdálená sdílená složka SMB, není to podporováno.
Určuje, že Robocopy funguje v "režimu s nízkým volným místem". Tento přepínač je užitečný jenom pro cíle s vrstveným úložištěm, kterým může před dokončením Robocopy dojít místní kapacita. Byl přidán speciálně pro použití s úložištěm, u kterého je povoleno cloudové vrstvení ve službě Azure File Sync. Dá se použít nezávisle na Synchronizaci souborů Azure. V tomto režimu se nástroj Robocopy zastaví pokaždé, když kopie souboru způsobí, že volné místo cílového svazku klesne pod hodnotu dolní meze. Tuto hodnotu lze zadat ve /LFSM:n formě příznaku. n Parametr je určen v základu 2: nKB, nMBnebo nGB. Pokud je /LFSM zadána bez explicitní hodnoty dolní hranice, je dolní hranice nastavena na 10 procent velikosti cílového svazku. Režim nedostatku volného místa není kompatibilní s /MT, /EFSRAWnebo /ZB. Podpora pro /B byla přidána do systému Windows Server 2022. Další informace o související chybě a alternativním řešení najdete v části Windows Server 2022 a RoboCopy LFSM níže.
/Z Používejte opatrně
Kopíruje soubory v režimu restartu. Tento přepínač se doporučuje pouze v nestabilním síťovém prostředí. Výrazně snižuje výkon kopírování kvůli dodatečnému protokolování.
/ZB Používejte opatrně
režim restartování. Pokud se přístup odepře, použije tato možnost režim zálohování. Tato možnost výrazně snižuje výkon kopírování kvůli kontrolním bodům.

Důležité

Doporučujeme použít Windows Server 2022. Při použití Windows Serveru 2019 se ujistěte, že je nainstalovaná nejnovější úroveň oprav nebo alespoň aktualizace operačního systému KB5005103 . Obsahuje důležité opravy pro určité scénáře Robocopy.

Fáze 8: Přechod uživatele na nový systém

Když poprvé spustíte příkaz RoboCopy, uživatelé a aplikace stále přistupují k souborům na serveru NAS a můžou je potenciálně změnit. Je možné, že RoboCopy zpracoval adresář, přejde na další a pak uživatel ve zdrojovém umístění (NAS) přidá, změní nebo odstraní soubor, který se teď v tomto aktuálním spuštění RoboCopy nezpracuje. Toto chování se očekává.

Prvním spuštěním je přesun velké části dat do Windows Serveru a do cloudu prostřednictvím Synchronizace souborů Azure. Tato první kopie může trvat dlouho v závislosti na těchto:

  • šířka pásma stahování
  • šířka pásma nahrávání
  • rychlost místní sítě a jak optimálně tomu odpovídá počet vláken RoboCopy
  • počet položek (souborů a složek), které je potřeba zpracovat nástrojem RoboCopy a Synchronizace souborů Azure

Po dokončení počátečního spuštění spusťte příkaz znovu.

Druhý čas se dokončí rychleji, protože potřebuje pouze přenést změny, ke kterým došlo od posledního spuštění. Během tohoto druhého spuštění se mohou stále nahromadit nové změny.

Tento proces opakujte, dokud nebudete spokojeni s tím, že doba potřebná k dokončení RoboCopy pro konkrétní umístění spadá do přijatelného okna pro výpadky.

Pokud zvažujete přijatelný výpadek, musíte odebrat uživatelský přístup ke sdíleným složkám založeným na NAS. Můžete to udělat libovolným postupem, který uživatelům brání ve změně struktury souborů a složek a obsahu. Příkladem je nasměrování oboru názvů DFS na neexistující umístění nebo změna kořenových seznamů ACL ve sdílené složce.

Spusťte poslední kolo RoboCopy. Vyzvedne všechny změny, které mohly být zmeškané. Jak dlouho tento poslední krok trvá, závisí na rychlosti skenování RoboCopy. Dobu (která se rovná výpadku) můžete odhadnout změřením toho, jak dlouho trvalo předchozí spuštění.

Vytvořte sdílené umístění na složce Windows Serveru a případně upravte nasazení DFS-N tak, aby na něj odkazovalo. Nezapomeňte nastavit stejná oprávnění na úrovni sdílené složky jako u sdílené složky SMB na serveru NAS. Pokud jste měli NAS připojené k doméně podnikové třídy, identifikátory SID uživatelů se automaticky shodují, protože uživatelé existují ve službě Active Directory a RoboCopy kopírují soubory a metadata v plné věrnosti. Pokud jste na serveru NAS používali místní uživatele, musíte tyto uživatele znovu vytvořit jako místní uživatele Windows Serveru a namapovat stávající identifikátory SID RoboCopy přesunuté na identifikátory SID vašeho nového místního systému Windows Server.

Dokončili jste migraci sdílené složky nebo skupiny sdílených složek do společného kořenového adresáře nebo svazku. (V závislosti na mapování z fáze 1)

Můžete se pokusit spustit několik těchto kopií paralelně. Doporučujeme zpracovat rozsah jedné sdílené složky Azure najednou.

Varování

Jakmile přesunete všechna data z vašeho serveru NAS na Windows Server a migrace se dokončí: Vraťte se do všech skupin synchronizace na webu Azure Portal a upravte objem vrstvení cloudu v procentech volného místa na něco vhodnějšího pro využití mezipaměti, například 20 %.

Zásady volného prostoru pro třídení v cloudu působí na úrovni jednoho svazku s potenciálně několika koncovými body serveru, které se synchronizují z jednoho svazku. Pokud zapomenete upravit volné místo na jednom koncovém bodu serveru, synchronizace bude dál používat nejvíce omezující pravidlo a pokusí se zachovat 99% volné místo na disku, takže místní mezipaměť nebude fungovat tak, jak byste mohli očekávat. Pokud vaším cílem je pouze mít obor názvů pro svazek, který obsahuje jen zřídka využívaná archivní data a zbytek prostoru úložiště si rezervujete pro jiný scénář.

Odstraňování potíží

Nejpravděpodobnějším problémem, na který můžete narazit, je, že příkaz RoboCopy selže s hláškou "Volume full" na straně Windows Serveru. Vrstvení cloudu se spouští jednou za hodinu, aby odstranilo obsah z disku na serveru Windows, který se synchronizoval. Jeho cílem je dosáhnout 99% volného místa na svazku.

Nechte synchronizaci a vrstvení dat do cloudu uvolnit místo na disku. Můžete si toho všimnout v Průzkumníku souborů na Windows Serveru.

Pokud má váš Windows Server dostatečnou dostupnou kapacitu, vyřešte problém opětovně spuštěním příkazu. Nic se nepokazí, když se dostanete do této situace, a můžete se pohybovat vpřed s jistotou. Jediným nepříjemným důsledkem je nutnost opětovného spuštění příkazu.

Informace o řešení Synchronizace souborů Azure problémů najdete na odkazu v následující části.

Další kroky

Následující články vám pomůžou porozumět možnostem nasazení, osvědčeným postupům a krokům pro řešení potíží.

  • Last updated on