Plánování nasazení Synchronizace souborů Azure

Synchronizace souborů Azure je služba, která umožňuje ukládat do mezipaměti několik sdílených složek Azure na místním windows serveru nebo cloudovém virtuálním počítači.

Tento článek vás seznámí s koncepty a funkcemi Synchronizace souborů Azure. Jakmile se seznámíte se Synchronizací souborů Azure, zvažte použití průvodce nasazením Synchronizace souborů Azure a vyzkoušejte si tuto službu.

Soubory se uloží v cloudu ve sdílených složkách Azure. Sdílené složky Azure je možné používat dvěma způsoby: přímým připojením těchto bezserverových sdílených složek Azure (SMB) nebo ukládáním sdílených složek Azure do mezipaměti místně pomocí Synchronizace souborů Azure. Kterou možnost nasazení zvolíte, změní aspekty, které je potřeba vzít v úvahu při plánování nasazení.

• Přímé připojení sdílené složky Azure: Vzhledem k tomu, že Azure Files poskytuje přístup smb, můžete připojit sdílené složky Azure místně nebo v cloudu pomocí standardního klienta SMB dostupného ve Windows, macOS a Linuxu. Vzhledem k tomu, že sdílené složky Azure nejsou bezserverové, nasazení v produkčních scénářích nevyžaduje správu souborového serveru nebo zařízení NAS. To znamená, že nemusíte používat softwarové opravy ani prohodit fyzické disky.

• Ukládání sdílené složky Azure do mezipaměti místně pomocí Synchronizace souborů Azure: Synchronizace souborů Azure umožňuje centralizovat sdílené složky vaší organizace ve službě Soubory Azure a zároveň zachovat flexibilitu, výkon a kompatibilitu místního souborového serveru. Synchronizace souborů Azure přeměňuje místní (nebo cloudový) Windows Server na rychlou vyrovnávací paměť sdílené složky souborů Azure.

Koncepty správy

Nasazení Synchronizace souborů Azure má tři základní objekty správy:

• Sdílená složka Azure: Sdílená složka Azure je bezserverové cloudové úložiště souborů, které poskytuje cloudový koncový bod vztahu synchronizace souborů Azure. K souborům ve sdílené složce Azure se dá přistupovat přímo pomocí protokolu SMB nebo FileREST, ale doporučujeme, abyste k souborům přistupovali primárně prostřednictvím mezipaměti Windows Serveru, když se sdílená složka Azure používá s Synchronizace souborů Azure. Je to proto, že služba Azure Files v současné době nemá efektivní mechanismus detekce změn, jako je Windows Server, takže změny sdílené složky Azure budou chvíli trvat, než se rozšíří zpět na koncové body serveru.
• Koncový bod serveru: Cesta na Windows Serveru, která se synchronizuje s účtem sdíleného úložiště Azure. Může se jednat o konkrétní složku na svazku nebo kořen svazku. Na stejném svazku může existovat více koncových bodů serveru, pokud se jejich obory názvů nepřekrývají.
• Skupina synchronizace: Objekt, který definuje vztah synchronizace mezi koncovým bodem cloudu nebo sdílenou složkou Azure a koncovým bodem serveru. Koncové body v rámci skupiny synchronizace se mezi sebou synchronizují. Pokud máte například dvě různé sady souborů, které chcete spravovat pomocí Synchronizace souborů Azure, vytvořili byste dvě skupiny synchronizace a přidali do každé skupiny synchronizace různé koncové body.

Koncepty správy sdílených složek Azure

Sdílené složky Azure se nasazují do účtů úložiště, což jsou objekty nejvyšší úrovně, které představují sdílený fond úložiště. Účty úložiště se dají použít k nasazení více sdílených složek a také k dalším prostředkům úložiště v závislosti na typu účtu úložiště. Všechny prostředky úložiště nasazené do účtu úložiště sdílejí limity, které platí pro tento účet úložiště. Aktuální limity účtu úložiště najdete v tématu Škálovatelnost a výkonnostní cíle služby Azure Files.

Existují dva hlavní typy účtů úložiště, které se používají pro nasazení služby Azure Files:

• Zřízené účty úložiště jsou rozlišovány podle typu účtu úložiště FileStorage. Zřízené účty úložiště umožňují nasadit zřízené sdílené složky na hardwaru založeném na disku SSD nebo HDD. Zřízené účty úložiště se dají použít jenom k ukládání sdílených složek Azure. Sdílené složky NFS je možné nasadit pouze ve zřízených účtech úložiště ve vrstvě médií SSD. Doporučujeme používat zřízené účty úložiště pro všechna nová nasazení služby Azure Files.
• Účty úložiště s průběžnou platbou: Účty úložiště s průběžnou platbou se rozlišují pomocí StorageV2 druhu účtu úložiště. Účty úložiště s průběžným platbou umožňují nasadit sdílené složky s průběžným platbám na hardware založený na hdd. Kromě ukládání sdílených složek Azure můžou účty úložiště GPv2 ukládat další prostředky úložiště, jako jsou kontejnery objektů blob, fronty nebo tabulky.

koncepty správy Synchronizace souborů Azure

Skupiny synchronizace se nasazují do služeb synchronizace úložiště, což jsou objekty nejvyšší úrovně, které registrují servery pro použití se Synchronizací souborů Azure a obsahují relace skupin synchronizace. Prostředek služby synchronizace úložiště je rovnocenný prostředku účtu úložiště a může být obdobně nasazen do skupin prostředků Azure. Služba synchronizace úložiště může vytvářet skupiny synchronizace, které obsahují sdílené složky Azure v několika účtech úložiště a více registrovaných Windows Serverech.

Než budete moct ve službě synchronizace úložiště vytvořit skupinu synchronizace, musíte nejprve zaregistrovat Windows Server ve službě synchronizace úložiště. Tím se vytvoří zaregistrovaný objekt serveru , který představuje vztah důvěryhodnosti mezi vaším serverem nebo clusterem a službou synchronizace úložiště. Pokud chcete zaregistrovat službu synchronizace úložiště, musíte nejprve nainstalovat agenta Synchronizace souborů Azure na server. Jednotlivé servery nebo clustery je možné najednou zaregistrovat pouze s jednou službou synchronizace úložiště.

Skupina synchronizace obsahuje jeden koncový bod cloudu nebo sdílenou složku Azure a alespoň jeden koncový bod serveru. Objekt koncového bodu serveru obsahuje nastavení, která konfigurují schopnost vrstvení cloudu, poskytující funkci ukládání do mezipaměti pro Azure File Sync. Aby se bylo možné synchronizovat se sdílenou složkou Azure, musí být účet úložiště, který obsahuje sdílenou složku Azure, ve stejné oblasti Azure jako služba synchronizace úložiště.

Důležité

V oboru názvů libovolného koncového bodu cloudu nebo serverového koncového bodu ve skupině synchronizace můžete provádět změny a vaše soubory budou synchronizovány s ostatními koncovými body ve skupině synchronizace. Pokud provedete změnu přímo na koncovém bodu služby cloud (sdílené složce Azure), musí být změny nejprve zaznamenány úlohou detekce změn Azure File Sync. Úloha detekce změn se spustí pro koncový bod cloudu pouze jednou za 24 hodin. Další informace najdete v tématu Nejčastější dotazy ke službě Azure Files.

Zvažte počet potřebných služeb synchronizace úložiště.

Služba synchronizace úložiště je kořenovým prostředkem ARM pro synchronizaci souborů Azure, který spravuje vztahy synchronizace mezi Windows servery a sdíleními souborů Azure. Každá služba synchronizace úložiště může obsahovat více skupin synchronizace a více registrovaných serverů.

Každý Windows Server je možné zaregistrovat pouze do jedné služby synchronizace úložiště. Po registraci se server může účastnit více skupin synchronizace v rámci této služby synchronizace úložiště vytvořením koncových bodů serveru na serveru pomocí instančního objektu ARM.

Při navrhování topologií Synchronizace souborů Azure se ujistěte, že data jasně izolujete na úrovni služby synchronizace úložiště. Pokud například vaše organizace vyžaduje samostatná prostředí Synchronizace souborů Azure pro dvě různé obchodní jednotky a potřebujete přísnou izolaci dat mezi těmito skupinami, měli byste pro každou skupinu vytvořit vyhrazenou službu synchronizace úložiště. Vyhněte se umístění skupin synchronizace pro obě obchodní skupiny ve stejné službě synchronizace úložiště, protože to nezajistí úplnou izolaci.

Další pokyny k izolaci dat pomocí samostatných předplatných nebo skupin prostředků v Azure najdete v následující dokumentaci k Azure: Další podrobnosti najdete v doprovodných materiálech k Azure .

Plánování vyvážených topologií synchronizace

Před nasazením prostředků je důležité naplánovat, co budete synchronizovat na místním serveru, se kterou sdílenou složkou Azure. Vytvoření plánu vám pomůže určit, kolik účtů úložiště, sdílených složek Azure a synchronizačních prostředků budete potřebovat. Tyto aspekty jsou stále relevantní, i když se vaše data aktuálně nenachází na Windows Serveru nebo na serveru, který chcete používat dlouhodobě. Část migrace vám může pomoct určit vhodné cesty migrace pro vaši situaci.

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 diskových svazcích můžete mít více složek, které v současnosti sdílíte lokálně jako SMB sdílené složky pro uživatele a aplikace. Nejjednodušším způsobem, jak si tento scénář představit, je představit si místní sdílenou složku, která mapuje 1:1 na sdílenou složku Azure. Pokud máte malý 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.

Sdílení skupiny

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 běžnou složku pak synchronizujete se sdílenou složkou Azure. Tímto způsobem je pro tuto skupinu lokálních sdílených složek zapotřebí jenom jedna sdílená složka Azure v cloudu.

Synchronizace hlasitosti

Azure File Sync podporuje synchronizaci kořenu svazku s Azure sdílenou složkou. Pokud synchronizujete kořen svazku, všechny podsložky a soubory se přesunou 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. Testujeme sdílení souborů Azure a Azure File Sync se 100 miliony položek (souborů a složek) na jedno sdílení. Osvědčeným postupem je ale snažit se zachovat číslo nižší než 20 milionů nebo 30 milionů v jednom podílu. Nastavení Synchronizace souborů Azure s nižším počtem položek není výhodné jenom pro synchronizaci souborů. Nižší početpoložekch

• Počáteční prohledávání cloudového obsahu může být dokončeno rychleji, což zase snižuje čekání na objevení oboru názvů na serveru s povolenou synchronizací souborů Azure.
• Obnovení ze snímku sdílené složky Azure na straně cloudu bude 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.

Návod

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

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í bude určovat, kolik prostředků a které prostředky synchronizační skupiny Azure File Sync 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 se chcete rozhodnout, kolik sdílených složek Azure potřebujete, projděte si následující omezení a osvědčené postupy. To vám pomůže s optimalizací mapy.

• 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é úložiště Azure je nasazeno v úč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 na účtu úložiště. Ideálně byste měli namapovat diskové sdílení 1:1 se skladovacími účty. Ale nemusí to být vždy možné kvůli různým limitům a omezením, jak z vaší organizace, tak z Azure. Pokud není možné mít nasazenou 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í, aby se zajistilo, že nejžhavější sdílené složky nebudou vloženy do stejného účtu úložiště.

  Pokud plánujete přesunout aplikaci do Azure, která bude používat sdílenou složku Azure nativně, možná budete potřebovat vyšší výkon z vašich sdílených složek Azure. 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.

Návod

Vzhledem k tomuto informacím je často nutné seskupit několik složek nejvyšší úrovně na svazcích do nového společného kořenového adresáře. Potom 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 synchronizace sdílených složek 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. Vaše ACL zůstanou tak, jak jsou. Stačí upravit všechny cesty ke sdíleným složkám (jako jsou 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 o cílech škálování synchronizace souborů Azure najdete zde.

Osvědčeným postupem je zachovat nízký počet položek v rozsahu synchronizace. To je důležitý faktor, který je potřeba vzít v úvahu při mapování složek na sdílené složky Azure. Synchronizace souborů Azure byla testována s 100 miliony položek (souborů a složek) pro jednu sdílenou složku. Často je ale nejlepší zachovat počet položek pod 20 milionů nebo 30 milionů v jedné sdílené složce. Pokud začnete tato čísla překročit, rozdělte obor názvů na několik sdílených složek. Pokud budete přibližně pod těmito čísly, můžete i nadále seskupit několik místních sdílených složek do stejné sdílené složky Azure. Tento postup vám poskytne prostor pro růst.

Je možné, že ve vaší situaci se sada složek může logicky synchronizovat se stejnou sdílenou složkou Azure (pomocí nového přístupu ke společné kořenové složce zmíněnému dříve). Přesto může být lepší znovu seskupit složky, aby se synchronizovaly se dvěma namísto jedním sdíleným úložištěm Azure. Tento přístup můžete použít k zachování počtu souborů a složek na sdílenou složku vyváženou na serveru. Můžete také rozdělit své místní sdílené složky a synchronizovat je mezi více místními servery, čímž získáte možnost synchronizovat se 30 dalšími sdílenými složkami Azure při přidání každého dalšího serveru.

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í)
1	Souborový server s více disky nebo svazky a více sdílenými soubory do stejného cílového sdíleného souboru 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ílem sdílené složky Azure. Začít největším diskem nebo svazkem pomůže splnit požadavky na úložiště v místním prostředí. Nakonfigurujte vrstvení cloudu tak, aby vrstvila všechna data do cloudu a uvolnila tak 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 jednotlivě v krocích, dokud nebudou všechna data přenesena do cloudu nebo migrována. 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 zopakujte celý proces. Poznámka: Může se vyžadovat opětovné instalace agenta. 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).
2	Souborový server s jedním svazkem a více sdílenými složkami do stejného cílového sdíleného úložiště Azure (konsolidace)	Ano	Nelze mít více koncových bodů serveru pro každý zaregistrovaný server synchronizujících se stejnou cílovou sdílenou složkou Azure (stejně jako výše).	Synchronizujte kořen svazku, který obsahuje více sdílených složek nebo složek nejvyšší úrovně. Další informace najdete v Seskupování sdílených složek – koncept a Synchronizace svazků.
3	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ě slouží ke škálování výkonu. Vstupně-výstupní operace za sekundu a propustnost se sdílí mezi sdílenými úložišti. Udržujte počet položek na skupinu synchronizace do 100 milionů položek (souborů a složek) na sdílenou složku. V ideálním případě je nejlepší zůstat pod 20 nebo 30 milionů za akcii.	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. Pokud máte na souborovém serveru více než 30 sdílených složek, použijte koncept seskupení sdílených složek a synchronizaci svazků , abyste snížili počet kořenových nebo nejvyšších složek na zdrojovém serveru. 3) Použijte další Synchronizace souborů servery v místním prostředí a rozdělte nebo přesuňte data na tyto servery, abyste mohli obejít omezení na zdrojovém serveru Windows.
4	Souborový server s více sdílenými složkami a/nebo svazky ke několika sdíleným složkám Azure v rámci různých účtů úložiště (mapování sdílení 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. V ideálním případě je nejlepší zůstat pod 20 nebo 30 milionů za akcii.	Stejný přístup jako výše uvedený
5	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) už nakonfigurovanou 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ů ve scénáři č. 1 výše s dodatečným zvážením zaměření se na jeden souborový server najednou.

Vytvořte tabulku mapování

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 při zřizování mnoha prostředků Azure najednou může být snadné ztratit podrobnosti o plánu mapování. Stáhněte si následující excelový soubor, který se použije jako šablona, aby vám pomohl vytvořit mapování.

Stáhněte šablonu mapování oboru názvů.

Důležité informace o souborových serverech Windows

Pokud chcete povolit funkci synchronizace na Windows Serveru, musíte nainstalovat Synchronizace souborů Azure agenta ke stažení. Agent Synchronizace souborů Azure poskytuje dvě hlavní komponenty: FileSyncSvc.exeslužbu windows na pozadí, která zodpovídá za monitorování změn na koncových bodech serveru a iniciování synchronizačních relací, a StorageSync.sysfiltr systému souborů, který umožňuje vrstvení cloudu a rychlé zotavení po havárii.

Požadavky na operační systém

Synchronizace souborů Azure se podporuje s následujícími verzemi Windows Serveru:

Verze	Podporované skladové položky	Podporované možnosti nasazení
Windows Server 2025	Azure, Datacenter, Essentials, Standard a IoT	Plná a základní
Windows Server 2022	Azure, Datacenter, Essentials, Standard a IoT	Plná a základní
Windows Server 2019	Datacenter, Essentials, Standard a IoT	Plná a základní
Windows Server 2016	Datacenter, Essentials, Standard a Skladový Server	Plná a základní
Windows Server 2012 R2*	Datacenter, Essentials, Standard a Skladový Server	Plná a základní

*Vyžaduje stažení a instalaci rozhraní WMF (Windows Management Framework) 5.1. Příslušný balíček ke stažení a instalaci pro Windows Server 2012 R2 je Win8.1AndW2K12R2-KB*******-x64.msu.

Důležité

Doporučujeme udržovat všechny servery, které používáte s Azure File Sync, aktualizované na nejnovější aktualizace ze služby Windows Update.

Minimální systémové prostředky

Synchronizace souborů Azure vyžaduje server, fyzický nebo virtuální, minimálně jeden procesor, minimálně 2 GiB paměti a místně připojený svazek formátovaný systémem souborů NTFS.

Důležité

Pokud je server spuštěný ve virtuálním počítači s povolenou dynamickou pamětí, měl by být virtuální počítač nakonfigurovaný minimálně s 2048 MiB paměti.

U většiny produkčních úloh nedoporučujeme konfigurovat server pro synchronizaci Azure File Sync pouze s minimálními požadavky. Další informace najdete v Doporučené systémové prostředky.

Doporučené systémové prostředky

Požadavky na systémové prostředky jsou pro Synchronizaci souborů Azure stejně jako u jakékoli jiné serverové funkce nebo aplikace dány škálováním nasazení. Větší nasazení na serveru vyžadují větší systémové prostředky. U Synchronizace souborů Azure je škálování určeno počtem objektů napříč koncovými body serveru a četností změn dat v datové sadě. Jeden server může mít koncové body serveru ve více skupinách synchronizace a počet objektů uvedených v následující tabulce zohledňuje celý obor názvů, ke kterému je server připojený.

Například koncový bod serveru A s 10 miliony objektů + koncový bod serveru B s 10 miliony objektů = 20 milionů objektů. V tomto příkladu nasazení doporučujeme 8 procesorů, 16 GiB paměti pro stabilní stav a (pokud je to možné) 48 GiB paměti pro počáteční migraci.

Data jmenného prostoru je kvůli výkonu ukládána do paměti. Z tohoto důvodu vyžadují větší obory názvů více paměti, aby se zachoval dobrý výkon. Větší četnost změn vyžaduje ke zpracování více procesorů.

V následující tabulce jsme uvedli jak velikost prostoru názvů, tak přepočet na kapacitu pro typická sdílení souborů pro obecné účely, kde průměrná velikost souboru je 512 KiB. Pokud jsou velikosti vašich souborů menší, zvažte pro stejnou kapacitu přidání další paměti. Konfiguraci paměti založte na velikosti oboru názvů.

Velikost prostoru názvů – soubory a adresáře (v milionech)	Typická kapacita (TiB)	Procesorová jádra	Doporučená paměť (GiB)
3	1.4	2	8 (počáteční synchronizace) / 2 (typická četnost změn)
5	2.3	2	16 (počáteční synchronizace) / 4 (typická četnost změn)
10	4.7	4	32 (počáteční synchronizace) / 8 (typická četnost změn)
30	14.0	8	48 (počáteční synchronizace) / 16 (typická četnost změn)
50	23,3	16	64 (počáteční synchronizace) / 32 (typická četnost změn)
100*	46,6	32	128 (počáteční synchronizace) / 32 (typická četnost změn)

*Nedoporučuje se synchronizace více než 100 milionů souborů a adresářů. Jedná se o doporučené omezení vycházející z námi testovaných prahových hodnot. Další informace najdete v tématu Cíle škálování synchronizace souborů Azure.

Návod

Počáteční synchronizace oboru názvů je náročná operace a doporučujeme přidělit více paměti, dokud se počáteční synchronizace nedokončí. To není nutné, ale může urychlit počáteční synchronizaci.

Typická fluktuace je 0,5 % změn v názvovém prostoru za den. V případě vyšších úrovní četnosti změn zvažte přidání dalších procesorů.

Vyhodnocovací cmdlet

Před nasazením Synchronizace souborů Azure byste měli vyhodnotit, zda je kompatibilní s vaším systémem pomocí evaluační rutiny Synchronizace souborů Azure. Tato rutina kontroluje potenciální problémy se systémem souborů a datovou sadou, jako jsou nepodporované znaky nebo nepodporovaná verze operačního systému. Tyto kontroly pokrývají většinu, ale ne všechny funkce uvedené níže; doporučujeme pečlivě si projít zbývající část této části, abyste měli jistotu, že nasazení proběhne hladce.

Zkušební rutinu je možné nainstalovat instalací modulu Az PowerShellu, který je možné nainstalovat podle těchto pokynů: Instalace a konfigurace Azure PowerShellu.

Využití

Nástroj pro vyhodnocení můžete vyvolat několika různými způsoby: můžete provádět kontroly systému, kontroly datových sad nebo obojí. Provedení kontrol systému i datové sady:

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

Testování pouze datové sady:

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

Testování pouze požadavků na systém:

Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name> -SkipNamespaceChecks

Pro zobrazení výsledků v CSV:

$validation = Invoke-AzStorageSyncCompatibilityCheck C:\DATA
$validation.Results | Select-Object -Property Type, Path, Level, Description, Result | Export-Csv -Path C:\results.csv -Encoding utf8

Kompatibilita systému souborů

Synchronizace souborů Azure se podporuje jenom u přímo připojených svazků NTFS. Přímé připojené úložiště nebo DAS na Windows Serveru znamená, že operační systém Windows Server vlastní systém souborů. DAS je možné poskytnout prostřednictvím fyzického připojení disků k souborovém serveru, připojení virtuálních disků k virtuálnímu počítači souborového serveru (například virtuálního počítače hostovaného technologií Hyper-V) nebo dokonce prostřednictvím iSCSI.

Podporují se pouze svazky NTFS; ReFS, FAT, FAT32 a další systémy souborů nejsou podporovány.

Následující tabulka uvádí stav spolupráce funkcí systému souborů NTFS:

Funkce	Stav podpory	Poznámky
Seznamy řízení přístupu (ACL)	Plně podporovaná	Diskreční seznamy řízení přístupu ve stylu Windows jsou zachovávány synchronizací souborů Azure a jsou vynucovány systémem Windows Server na koncových bodech serveru. ACL lze také vynutit při přímém připojení sdílené složky Azure, které však vyžaduje další konfiguraci. Další informace najdete v části Identita .
Pevná propojení	Přeskočeno
Symbolické odkazy	Přeskočeno
Přípojné body	Částečně podporováno	Přípojné body můžou být kořenem koncového bodu serveru, ale jsou přeskočeny, pokud jsou obsaženy v namespace koncového bodu serveru.
Přípojky	Přeskočeno	Například složky Distributed File System DfrsrPrivate a DFSRoots.
Body rozboru	Přeskočeno
Komprese NTFS	Částečně podporováno	Synchronizace souborů Azure nepodporuje koncové body serveru umístěné na svazku, který má komprimovaný adresář SVI (System Volume Information).
Zhuštěné soubory	Plně podporovaná	Synchronizace řídkých souborů (nejsou blokované), ale synchronizují se do cloudu jako plný soubor. Pokud se obsah souboru změní v cloudu (nebo na jiném serveru), soubor po stažení změny přestane být uložen jako řídký soubor.
Alternativní datové proudy (ADS)	Zachováno, ale nesynchronizuje se	Například značky klasifikace vytvořené infrastrukturou klasifikace souborů se nesynchronizují. Stávající značky klasifikace u souborů na jednotlivých koncových bodech serveru zůstanou nedotčené.

Synchronizace souborů Azure také přeskočí určité dočasné soubory a systémové složky:

Soubor nebo složka	Poznámka:
pagefile.sys	Soubor specifický pro systém
Desktop.ini	Soubor specifický pro systém
thumbs.db	Dočasný soubor pro miniatury
ehthumbs.db	Dočasný soubor pro miniatury médií
~$*.*	Dočasný soubor Office
*.Tmp	Dočasný soubor
*.laccdb	Soubor zámku přístupu k databázi
635D02A9D91C401B97884B82B3BCDAEA.*	Interní soubor synchronizace
\Informace o systémovém svazku	Složka specifická pro svazek
$RECYCLE. POPELNICE	Složka
\Stav_synchronizace_sdílené položky	Složka pro synchronizaci
. SystemShareInformation	Složka pro synchronizaci ve sdíleném úložišti Azure

Poznámka:

I když Synchronizace souborů Azure podporuje synchronizaci databázových souborů, databáze nejsou dobrou úlohou pro synchronizační řešení (včetně Synchronizace souborů Azure), protože soubory protokolů a databáze je potřeba synchronizovat společně a můžou se dostat ze synchronizace z různých důvodů, což může vést k poškození databáze.

Zvažte, kolik volného místa potřebujete na místním disku.

Při plánování použití Synchronizace souborů Azure zvažte, kolik volného místa potřebujete na místním disku, na který plánujete mít koncový bod serveru.

U Synchronizace souborů Azure budete muset vzít v úvahu následující zabírání místa na místním disku:

• Při aktivaci vrstvení v cloudu:

  • Spojovací body pro vrstvené soubory
  • databáze metadat Synchronizace souborů Azure
  • Synchronizace souborů Azure heatstore
  • Plně stažené soubory v horké mezipaměti (pokud existuje)
  • Požadavky na zásady pro volné místo ve svazku

• Když je vrstvení do cloudu zakázáno:

  • Plně stažené soubory
  • Synchronizace souborů Azure heatstore
  • databáze metadat Synchronizace souborů Azure

Pomocí příkladu si ukážeme, jak odhadnout množství volného místa na místním disku. Řekněme, že jste nainstalovali agenta Synchronizace souborů Azure na virtuální počítač Azure s Windows a plánujete vytvořit koncový bod serveru na disku F. Máte 1 milion souborů a chcete vrstvit všechny soubory, 100 000 adresářů a velikost diskového clusteru 4 KiB. Velikost disku je 1000 GiB. Chcete povolit vrstvení cloudu a nastavit politiku volného místa na svazku na 20 %.

1. Ntfs přidělí velikost clusteru pro každý vrstvený soubor. 1 milion souborů * 4 KiB clusterová velikost = 4 000 000 KiB (4 GiB)

   Poznámka:

   Pokud chcete plně využít výhod vrstvení cloudu, doporučujeme použít menší velikosti clusteru NTFS (menší než 64KiB), protože každý vrstvený soubor zabírá cluster. Navíc je prostor obsazený vrstvenými soubory přidělen systémem souborů NTFS. Proto se nezobrazí v žádném uživatelském rozhraní.

2. Metadata synchronizace zabírá velikost clusteru pro každou položku. (1 milion souborů + 100 000 adresářů) * velikost clusteru 4 KiB = 4 400 000 KiB (4,4 GiB)
3. Synchronizace souborů Azure heatstore zabírá 1,1 KiB na soubor. 1 milion souborů * 1,1 KiB = 1 100 000 KiB (1,1 GiB)
4. Zásada pro volné místo na svazku je 20 %. 1000 GiB * 0,2 = 200 GiB

V tomto případě by Synchronizace souborů Azure potřebovala pro tento namespace přibližně 209 500 000 KiB (209,5 GiB). Tuto částku přidejte do libovolného dalšího volného místa, které chcete, aby bylo možné zjistit, kolik volného místa je pro tento disk potřeba.

Clustering s podporou převzetí služeb při selhání

1. Převzetí služeb při selhání systému Windows Server (Failover Clustering) je podporováno službou Azure File Sync pro nasazení možnosti "Souborový server pro obecné použití". Další informace o tom, jak nakonfigurovat roli "Souborový server pro obecné použití" na clusteru s podporou převzetí služeb při selhání, najdete v tématu Nasazení clusterového serveru se dvěma uzly.
2. Jediným scénářem podporovaným Azure File Sync je cluster Windows Server s převzetím služeb při selhání a clusterovými disky.
3. Clustering s podporou převzetí služeb při selhání se nepodporuje na souborovém serveru se škálováním na více systémů pro data aplikací (SOFS) ani na sdílených svazcích clusteru nebo místních discích.

Poznámka:

Aby synchronizace fungovala správně, musí být agent synchronizace souborů Azure nainstalovaný na každém uzlu v clusteru pro převzetí služeb při selhání.

Odstranění duplicitních dat

Windows Server 2025, Windows Server 2022, Windows Server 2019 a Windows Server 2016
Podpora deduplikace dat je zajištěna bez ohledu na to, jestli je na jednom nebo více koncových bodech serveru na svazku povoleno nebo zakázáno vrstvení do cloudu pro Windows Server 2016, Windows Server 2019, Windows Server 2022 a Windows Server 2025. Povolení deduplikace dat na svazku s povoleným vrstvením cloudu vám umožní ukládat do mezipaměti více souborů místně, aniž byste museli zřídit další úložiště.

Pokud je odstranění duplicitních dat povoleno na svazku s povoleným vrstvením cloudu, soubory optimalizované pro odstranění duplicitních dat v umístění koncového bodu serveru se budou vrstvit podobně jako běžný soubor podle nastavení zásad vrstvení cloudu. Jakmile byly optimalizované soubory skonvertovány do vrstev pomocí deduplikace, úloha pro sběr nevyužitých dat deduplikace se spustí automaticky, aby uvolnila místo na disku odstraněním nepotřebných datových bloků, na které již neodkazují jiné soubory na svazku.

Všimněte si, že úspory objemu se vztahují pouze na server; vaše data ve sdílené složce Azure nebudou deduplikována.

Poznámka:

Pro podporu deduplikace dat na svazcích s povoleným vrstvením cloudu ve Windows Serveru 2019 musí být nainstalována aktualizace systému Windows KB4520062 - říjen 2019 nebo novější měsíční kumulativní aktualizace.

Windows Server 2012 R2
Synchronizace souborů Azure nepodporuje odstranění duplicitních dat a vrstvení cloudu na stejném svazku ve Windows Serveru 2012 R2. Pokud je deduplicace dat na svazku povolena, musí být cloudové vrstvení zakázáno.

Poznámky

• Pokud je odstranění duplicitních dat nainstalované před instalací agenta Synchronizace souborů Azure, vyžaduje se restartování pro podporu odstranění duplicitních dat a vrstvení cloudu na stejném svazku.

• Pokud je odstranění duplicitních dat na svazku povolené po povolení vrstvení cloudu, počáteční úloha optimalizace odstranění duplicitních dat optimalizuje soubory na svazku, který ještě není vrstvený a bude mít následující dopad na vrstvení cloudu:

  • Zásady volného místa budou dál vrstvit soubory podle volného místa na svazku pomocí heat mapy.
  • Zásada ukládání vynechá vrstvení souborů, které by jinak mohly být způsobilé pro vrstvení kvůli tomu, že proces optimalizace deduplikace přistupuje k souborům.

• U probíhajících úloh optimalizace deduplikace dat se vrstvení do cloudu podle zásady data zpozdí nastavením MinimumFileAgeDays, pokud soubor ještě není uložený ve vrstvě.

  • Příklad: Pokud je nastavení Minimální věk souboru (ve dnech) sedm dní a zásada datování vrstvení do cloudu je 30 dní, zásada datování bude vrstvit soubory po 37 dnech.
  • Poznámka: Jakmile je soubor zařazený do úrovně pomocí Azure File Sync, úloha optimalizace deduplikace soubor přeskočí.

• Pokud se server se systémem Windows Server 2012 R2 s nainstalovaným agentem Synchronizace souborů Azure upgraduje na Windows Server 2016, Windows Server 2019, Windows Server 2022 nebo Windows Server 2025, musíte provést následující kroky, abyste mohli podporovat odstranění duplicitních dat a vrstvení cloudu na stejném svazku:

  • Odinstalujte agenta Synchronizace souborů Azure pro Windows Server 2012 R2 a restartujte server.
  • Stáhněte agenta Synchronizace souborů Azure pro novou verzi operačního systému serveru (Windows Server 2016, Windows Server 2019, Windows Server 2022 nebo Windows Server 2025).
  • Nainstalujte agenta Synchronizace souborů Azure a restartujte server.

  Poznámka: Nastavení konfigurace Synchronizace souborů Azure na serveru se zachovají při odinstalaci a přeinstalaci agenta.

Systém distribuovaných souborů (DFS)

Synchronizace souborů Azure podporuje interoperabilitu s obory názvů DFS (DFS-N) a replikací DFS (DFS-R).

Obory názvů DFS (DFS-N): Synchronizace souborů Azure se plně podporuje s implementací DFS-N. Agenta Synchronizace souborů Azure můžete nainstalovat na jeden nebo více souborových serverů, abyste synchronizovali data mezi koncovými body serveru a koncovým bodem cloudu a pak pomocí dfs-N poskytli službu oboru názvů. Další informace najdete v tématu Přehled oborů názvů DFS a Obory názvů DFS se službou Azure Files.

Replikace DFS (DFS-R): Vzhledem k tomu, že DFS-R a Synchronizace souborů Azure jsou obě řešení replikace, doporučujeme ve většině případů nahradit DFS-R synchronizací souborů Azure. Existuje však několik scénářů, ve kterých byste chtěli společně používat DFS-R a Synchronizaci souborů Azure:

• Migrujete z nasazení DFS-R na nasazení Azure Synchronizaci souborů. Další informace najdete v tématu Migrace nasazení replikace DFS (DFS-R) na Azure File Sync.
• Ne každý místní server, který potřebuje kopii dat souboru, je možné připojit přímo k internetu.
• Pobočkové servery konsolidují data na jeden centrální server, a vy byste chtěli použít Azure File Sync.

Aby Synchronizace souborů Azure a DFS-R fungovaly vedle sebe:

1. Vrstvení cloudu pro synchronizaci souborů Azure musí být na svazcích s replikovanými složkami DFS-R zakázáno.
2. Koncové body serveru by se neměly konfigurovat ve složkách replikace pouze pro čtení DFS-R.
3. Pouze jeden koncový bod serveru se může překrývat s umístěním DFS-R. Více koncových bodů serveru, které se překrývají s jinými aktivními umístěními DFS-R, může vést ke konfliktům.

Další informace najdete v tématu Replikace DFS – přehled.

Sysprep

Použití nástroje Sysprep na serveru s nainstalovaným agentem Synchronizace souborů Azure se nepodporuje a může vést k neočekávaným výsledkům. Po nasazení image serveru a dokončení mini-setupu nástroje Sysprep by se měla provést instalace agenta a registrace serveru.

Vyhledávání ve Windows

Pokud je na koncovém bodu serveru povolené vrstvení cloudu, přeskočí se vrstvené soubory, které nejsou indexovány službou Windows Search. Nerozvrstvené soubory jsou správně indexovány.

Poznámka:

Klienti Windows způsobí připomenutí při vyhledávání ve sdílení souborů, pokud je na klientském počítači povoleno nastavení Vždy hledat názvy souborů a obsah. Toto nastavení je ve výchozím nastavení zakázané.

Další řešení správy hierarchického úložiště (HSM)

Synchronizace souborů Azure by neměla používat žádná jiná řešení HSM.

Výkon a škálovatelnost

Vzhledem k tomu, že agent Synchronizace souborů Azure běží na počítači s Windows Serverem, který se připojuje ke sdíleným složkám Azure, závisí efektivní výkon synchronizace na několika faktorech vaší infrastruktury: Windows Server a základní konfigurace disku, šířka pásma sítě mezi serverem a úložištěm Azure, velikost souboru, celková velikost datové sady a aktivita v datové sadě. Vzhledem k tomu, že Synchronizace souborů Azure funguje na úrovni souboru, charakteristiky výkonu Synchronizace souborů Azure řešení založeného na Synchronizace souborů Azure se lépe měří v počtu objektů (souborů a adresářů) zpracovaných za sekundu.

Změny sdílené složky Azure pomocí webu Azure Portal nebo protokolu SMB se okamžitě nezjistí a nereplikují, na rozdíl od změn koncového bodu serveru. Služba Azure Files nemá oznámení o změnách ani deníku, takže neexistuje způsob, jak automaticky zahájit relaci synchronizace při změně souborů. Na Windows Serveru používá Azure File Sync zápisník Windows USN k automatickému zahájení synchronizační relace při změně souborů.

Pokud chcete zjistit změny ve sdílené složce Azure, Synchronizace souborů Azure má naplánovanou úlohu označovanou jako úloha detekce změn. Úloha detekce změn vytvoří výčet všech souborů ve sdílené složce a pak ho porovná se synchronizovanou verzí daného souboru. Když úloha detekce změn zjistí, že se soubory změnily, Azure File Sync zahájí relaci synchronizace. Úloha detekce změn se spouští každých 24 hodin. Vzhledem k tomu, že úloha detekce změn funguje na základě výčtu všech souborů ve sdílené složce Azure, trvá detekce změn ve větších oborech názvů déle než v menších. U rozsáhlých oborů názvů může zjištění, které soubory se změnily, trvat déle než jednou za 24 hodin.

Další informace najdete v tématu Metriky výkonu Synchronizace souborů Azure a cíle škálování Synchronizace souborů Azure.

Identita

Synchronizace souborů Azure funguje se standardní identitou Active Directory bez jakéhokoli speciálního nastavení, kromě nastavení synchronizace. Když používáte Synchronizaci souborů Azure, obecně se očekává, že většina přístupů prochází servery pro ukládání do mezipaměti Synchronizace souborů Azure, nikoli přes sdílenou složku Azure. Vzhledem k tomu, že se koncové body serveru nacházejí na Windows Serveru a Windows Server už dlouho podporuje AD a ACL ve stylu Windows, není potřeba nic nad rámec toho, aby byly souborové servery Windows zaregistrované ve službě Storage Sync připojené k doméně. Synchronizace souborů Azure uloží seznamy ACL do souborů ve sdílené složce Azure a budou je replikovat do všech koncových bodů serveru.

I když změny provedené přímo ve sdílené složce Azure budou trvat déle při synchronizaci s koncovými body serveru ve skupině synchronizace, možná budete chtít také zajistit, že můžete v cloudu přímo na sdílené složce uplatnit svá oprávnění AD. Abyste toho dosáhli, musíte svůj účet úložiště připojit k vašemu lokálnímu Active Directory, stejně jako jsou k doméně připojené vaše souborové servery Windows. Další informace o připojení domény k účtu úložiště ke službě Active Directory vlastněné zákazníkem najdete v tématu Přehled ověřování založeného na identitě služby Azure Files pro přístup k protokolu SMB.

Důležité

K úspěšnému nasazení Synchronizace souborů Azure není vyžadováno propojení účtu úložiště se službou Active Directory. Jedná se o zcela volitelný krok, který umožňuje sdílené složce Azure prosazovat místní seznamy ACL, když uživatelé připojí sdílenou složku Azure přímo.

Sítě

Agent Synchronizace souborů Azure komunikuje se službou synchronizace úložiště a sdílenou složkou Azure pomocí protokolu SYNCHRONIZACE SOUBORŮ AZURE REST a protokolu FileREST, z nichž oba vždy používají HTTPS přes port 443. Protokol SMB se nikdy nepoužívá k nahrání nebo stahování dat mezi Windows Serverem a sdílenou složkou Azure. Vzhledem k tomu, že většina organizací povoluje provoz HTTPS přes port 443 jako požadavek na návštěvu většiny webů, není obvykle potřeba nasadit Synchronizace souborů Azure speciální síťovou konfiguraci.

Důležité

Synchronizace souborů Azure nepodporuje internetové směrování. Azure File Sync podporuje výchozí možnost síťového směrování, tedy směrování Microsoftu.

Na základě zásad vaší organizace nebo jedinečných zákonných požadavků můžete vyžadovat přísnější komunikaci s Azure, a proto Synchronizace souborů Azure poskytuje několik mechanismů pro konfiguraci sítí. Na základě vašich požadavků můžete:

• Tunel synchronizujte a soubory nahrávejte/stahujte přes ExpressRoute nebo Azure VPN.
• Využijte funkce azure Files a sítě Azure, jako jsou koncové body služeb a privátní koncové body.
• Nakonfigurujte Synchronizace souborů Azure pro podporu vašeho proxy serveru ve vašem prostředí.
• Omezte síťovou aktivitu z Synchronizace souborů Azure.

Návod

Pokud chcete komunikovat se sdílenou složkou Azure přes protokol SMB, ale port 445 je zablokovaný, zvažte použití protokolu SMB přes QUIC, který nabízí nulovou konfiguraci SMB VPN pro přístup ke sdíleným složkám Azure pomocí přenosového protokolu QUIC přes port 443. I když Služba Soubory Azure přímo nepodporuje protokol SMB přes QUIC, můžete vytvořit jednoduchou mezipaměť sdílených složek Azure na virtuálním počítači s Windows Serverem 2022 Azure Edition pomocí Synchronizace souborů Azure. Další informace o této možnosti najdete v tématu SMB přes QUIC pomocí Synchronizace souborů Azure.

Další informace o Synchronizaci souborů Azure a sítích najdete v tématu Důležité informace o sítích Synchronizace souborů Azure.

Šifrování

Při použití Azure File Sync je třeba vzít v úvahu tři různé vrstvy šifrování: šifrování dat uložených v neaktivním stavu na úložišti systému Windows Server, šifrování během přenosu mezi agentem Azure File Sync a Azure, a šifrování dat v klidovém stavu na sdíleném úložišti Azure.

Šifrování dat v klidu Windows Serveru

Existují dvě strategie šifrování dat na Windows Serveru, které obecně fungují s Synchronizace souborů Azure: šifrování pod systémem souborů, aby systém souborů a všechna data zapsaná do něj byla šifrovaná, a šifrování v samotném formátu souboru. Tyto metody se vzájemně nevylučují; v případě potřeby je možné je použít společně, protože účel šifrování se liší.

Aby poskytl šifrování jako součást vrstvy pod systémem souborů, Windows Server nabízí BitLocker. BitLocker je plně transparentní pro Azure File Sync. Primárním důvodem použití šifrovacího mechanismu, jako je BitLocker, je zabránit fyzické exfiltraci dat z vašeho místního datacentra tím, že někdo ukradne disky, a zároveň zabránit nahrání neoprávněného operačního systému, který by mohl provádět neoprávněné čtení a zápisy do vašich dat. Další informace najdete v přehledu nástroje BitLocker.

Produkty třetích stran, které fungují podobně jako BitLocker tím, že jsou pod svazkem NTFS, by měly podobně fungovat plně transparentně s Azure File Sync.

Druhou hlavní metodou šifrování dat je šifrování datového proudu souboru při uložení souboru aplikace. Některé aplikace to můžou provést nativně, ale obvykle tomu tak není. Příkladem metody pro šifrování datového proudu souboru je Azure Information Protection (AIP)/Azure Rights Management Services (Azure RMS)/Active Directory RMS. Primárním důvodem použití šifrovacího mechanismu, jako je AIP/RMS, je zabránit exfiltraci dat ze sdílené složky tím, že je lidé zkopírují do alternativních umístění, jako je flash disk, nebo e-mailem neautorizované osobě. Pokud je datový proud souboru zašifrovaný jako součást formátu souboru, bude tento soubor dál šifrován ve sdílené složce Azure.

Synchronizace souborů Azure nespolupracuje se systémem souborů NTFS Encrypted File System (NTFS EFS) ani šifrovacími řešeními třetích stran, která se nacházejí nad systémem souborů, ale pod datovým proudem souboru.

Šifrování během přenosu

Poznámka:

Služba Synchronizace souborů Azure odebrala podporu protokolu TLS1.0 a 1.1 1. srpna 2020. Všechny podporované verze agenta Synchronizace souborů Azure už ve výchozím nastavení používají protokol TLS1.2. K použití starší verze protokolu TLS může dojít, pokud je na vašem serveru zakázaný protokol TLS1.2 nebo se používá proxy server. Pokud používáte proxy server, doporučujeme zkontrolovat konfiguraci proxy serveru. Oblasti služby Synchronizace souborů Azure přidané po 1. květnu 2020 podporují pouze protokol TLS1.2. Další informace najdete v průvodci odstraňováním potíží.

Agent Synchronizace souborů Azure komunikuje se službou synchronizace úložiště a sdílenou složkou Azure pomocí protokolu SYNCHRONIZACE SOUBORŮ AZURE REST a protokolu FileREST, z nichž oba vždy používají HTTPS přes port 443. Synchronizace souborů Azure neodesílá nešifrované požadavky přes protokol HTTP.

Účty úložiště Azure obsahují přepínač pro vyžadování šifrování během přenosu, který je ve výchozím nastavení povolený. I když je přepínač na úrovni účtu úložiště zakázaný, což znamená, že jsou možná nešifrovaná připojení ke sdíleným složkám Azure, Synchronizace souborů Azure k přístupu ke sdílené složce budou dál používat jenom šifrované kanály.

Primárním důvodem zakázání přenášeného šifrování pro účet úložiště je podpora starší verze aplikace, která musí být spuštěna ve starším operačním systému, jako je Windows Server 2008 R2 nebo starší linuxová distribuce, která mluví přímo se sdílenou složkou Azure. Pokud starší verze aplikace komunikuje s mezipamětí windows serveru sdílené složky, přepnutí tohoto nastavení nebude mít žádný vliv.

Důrazně doporučujeme zajistit, aby bylo povolené šifrování přenášených dat.

Další informace o šifrování během přenosu najdete v tématu vyžadování zabezpečeného přenosu v úložišti Azure.

Šifrování neaktivních uložených sdílených složek Azure

Všechna data uložená ve službě Azure Files se šifrují v klidovém stavu pomocí šifrování služby Azure Storage (SSE). Šifrování služby Storage funguje podobně jako BitLocker ve Windows: data se šifrují pod úrovní systému souborů. Vzhledem k tomu, že data se šifrují pod systémem souborů sdílené složky Azure, protože jsou zakódovaná na disk, nemusíte mít přístup k základnímu klíči v klientovi, abyste mohli číst nebo zapisovat do sdílené složky Azure. Šifrování neaktivních uložených dat platí pro protokoly SMB i NFS.

Ve výchozím nastavení se data uložená ve službě Azure Files šifrují pomocí klíčů spravovaných Microsoftem. S klíči spravovanými Microsoftem uchovává Microsoft klíče k šifrování a dešifrování dat a zodpovídá za jejich pravidelné obměně. Můžete také zvolit správu vlastních klíčů, což vám dává kontrolu nad procesem rotace. Pokud se rozhodnete zašifrovat sdílené složky pomocí klíčů spravovaných zákazníkem, služba Azure Files má oprávnění k přístupu k vašim klíčům za účelem splnění požadavků na čtení a zápis od klientů. Pomocí klíčů spravovaných zákazníkem můžete tuto autorizaci kdykoli odvolat, ale to znamená, že sdílená složka Azure už nebude přístupná přes protokol SMB ani rozhraní FileREST API.

Služba Azure Files používá stejné schéma šifrování jako ostatní služby úložiště Azure, jako je Azure Blob Storage. Další informace o šifrování služby Azure Storage (SSE) najdete v tématu Šifrování úložiště Azure pro neaktivní uložená data.

Úrovně úložiště

Azure Files nabízí dvě různé úrovně úložiště, SSD (disky SSD) a HDD (pevné disky), které umožňují přizpůsobit sdílené složky podle požadavků na výkon a cenu vašeho scénáře:

• SSD (Premium):: Sdílené složky SSD poskytují konzistentní vysoký výkon a nízkou latenci v rámci jednociferných milisekund pro většinu vstupně-výstupních operací pro úlohy náročné na vstupně-výstupní operace. Sdílené složky SSD jsou vhodné pro širokou škálu úloh, jako jsou databáze, hostování webů a vývojová prostředí. Sdílené složky SSD je možné použít s protokoly SMB (Server Message Block) a NFS (Network File System). Sdílené složky SSD jsou k dispozici ve předem zřízeném fakturačním modelu v1. Sdílené složky SSD nabízejí smlouvu SLA s vyšší dostupností než sdílené složky HDD (viz Úroveň Azure Files Premium).

• HDD (standard):: Sdílené složky HDD poskytují nákladově efektivní možnost úložiště pro sdílené složky pro obecné účely. Sdílené složky HDD jsou dostupné se zřízeným modelem fakturace v2 a modelem průběžného placení, i když pro nová nasazení sdílených složek doporučujeme zřízený model verze 2. Informace o smlouvě SLA najdete na stránce smlouvy o úrovni služeb Azure (viz Účty úložiště).

Při výběru úrovně médií pro vaši úlohu zvažte požadavky na výkon a využití. Pokud vaše úloha vyžaduje jednocifernou latenci nebo používáte místní SSD úložné médium, je SSD sdílené úložiště pravděpodobně nejvhodnější. Pokud nízká latence není tak důležitá, například u týmových sdílených složek připojených místně z Azure nebo cacheovaných místně pomocí Azure File Sync, může být HDD úložiště vhodnější z hlediska nákladů.

Jakmile vytvoříte sdílenou složku v účtu úložiště, nemůžete ji přímo přesunout do jiné vrstvy médií. Pokud například chcete přesunout sdílenou složku HDD do vrstvy médií SSD, musíte vytvořit novou sdílenou složku SSD a zkopírovat data z původní sdílené složky do nové sdílené složky. Zobrazení migrace souborů z jedné sdílené složky do jiné

Další informace o úrovních médií SSD a HDD najdete v tématu Vysvětlení fakturace služby Azure Files a vysvětlení výkonu služby Azure Files.

dostupnost synchronizace souborů Azure v oblasti

Informace o regionální dostupnosti najdete v tématu Dostupné produkty v jednotlivých oblastech a vyhledejte účty úložiště.

Následující oblasti vyžadují, abyste před použitím Synchronizace souborů Azure požádali o přístup ke službě Azure Storage:

• Francie – jih
• Jižní Afrika – západ
• Spojené arabské emiráty – střed

Pokud chcete požádat o přístup k těmto oblastem, postupujte podle postupu v tomto dokumentu.

Nadbytečnost

Kvůli ochraně dat ve sdílených složkách Azure před ztrátou nebo poškozením dat ukládá služba Azure Files několik kopií jednotlivých souborů při jejich zápisu. V závislosti na vašich požadavcích můžete vybrat různé stupně redundance. Služba Azure Files v současné době podporuje následující možnosti redundance dat:

• Místně redundantní úložiště (LRS): S místní redundancí se každý soubor ukládá třikrát v clusteru úložiště Azure. To chrání před ztrátou dat kvůli hardwarovým chybám, jako je například chybná disková jednotka. Pokud však dojde k havárii, jako je požár nebo záplava v rámci datového centra, můžou být všechny repliky účtu úložiště využívajícího LRS ztraceny nebo neobnovitelné.
• Zónově redundantní úložiště (ZRS): Při redundanci zóny se ukládají tři kopie každého souboru. Tyto kopie jsou však fyzicky izolované ve třech různých clusterech úložiště v různých zónách dostupnosti Azure. Zóny dostupnosti jsou jedinečná fyzická umístění v rámci oblasti Azure. Každá zóna se skládá z jednoho nebo více datových center vybavených nezávislým napájením, chlazením a sítěmi. Zápis do úložiště se nepřijímá, dokud se nezapíše do clusterů úložiště ve všech třech zónách dostupnosti.
• Geograficky redundantní úložiště (GRS): S geografickou redundancí máte dvě oblasti, primární oblast a sekundární oblast. Soubory se ukládají třikrát v rámci clusteru úložiště Azure v primární oblasti. Zápisy se asynchronně replikují do sekundární oblasti definované Microsoftem. Geografická redundance poskytuje šest kopií vašich dat rozložených mezi dvěma oblastmi Azure. Pokud dojde k závažné havárii, například k trvalé ztrátě oblasti Azure kvůli přírodní katastrofě nebo jiné podobné události, Microsoft provede obnovení provozu. V tomto případě se sekundární stane primárním, který obsluhuje všechny operace. Vzhledem k tomu, že replikace mezi primárními a sekundárními oblastmi je asynchronní, pokud dojde k závažné havárii, data, která ještě nejsou replikována do sekundární oblasti, budou ztracena. Můžete také provést ruční převzetí služeb při selhání účtu geograficky redundantního úložiště.
• Geograficky zónově redundantní úložiště (GZRS): S redundancí GeoZone se soubory ukládají třikrát napříč třemi různými clustery úložiště v primární oblasti. Všechny zápisy se pak asynchronně replikují do sekundární oblasti definované Microsoftem. Proces failoveru pro redundanci GeoZone funguje stejně jako geo redundance.

Sdílené složky HDD podporují všechny čtyři typy redundance. Sdílené složky SSD podporují pouze LRS a ZRS.

Účty úložiště s průběžnými platbou poskytují dvě další možnosti redundance, které služba Azure Files nepodporuje: geograficky redundantní úložiště s podporou čtení (RA-GRS) a přístupná geograficky zónově redundantní úložiště s podporou čtení (RA-GZRS). Pomocí těchto možností můžete zřídit sdílené složky Azure v účtech úložiště, ale Služba Azure Files nepodporuje čtení ze sekundární oblasti. Sdílené složky Azure nasazené na úložné účty RA-GRS nebo RA-GZRS jsou účtovány jako Geo nebo GeoZone.

Důležité

Geograficky redundantní a geograficky zónově redundantní úložiště mají schopnost ručně přepnout úložiště do sekundární oblasti. Doporučujeme, abyste to nedělali mimo situaci havárie, pokud používáte Synchronizaci souborů Azure kvůli zvýšené pravděpodobnosti ztráty dat. V případě havárie, kdy chcete zahájit ruční převzetí služeb při selhání úložiště, budete muset otevřít požadavek podpory u Microsoftu, aby bylo možné obnovit synchronizaci pomocí služby Azure File Sync se sekundárním koncovým bodem.

Migrace

Pokud máte existující souborový server Windows 2012R2 nebo novější, můžete Synchronizace souborů Azure nainstalovat přímo, aniž byste museli přesouvat data na nový server. Pokud plánujete migrovat na nový souborový server s Windows jako součást přechodu na Synchronizace souborů Azure nebo pokud se vaše data aktuálně nacházejí v úložišti NAS (Network Attached Storage), existuje několik možných přístupů k migraci, které s daty používají Synchronizace souborů Azure. Který přístup k migraci byste měli zvolit, závisí na tom, kde se aktuálně nacházejí vaše data.

Pro podrobné pokyny si přečtěte článek o přehledu Synchronizace souborů Azure a migrace sdílených složek Azure.

Antivirový program

Vzhledem k tomu, že antivirová ochrana funguje vyhledáváním známých škodlivých kódů, může antivirový produkt způsobit vyvolání souborů uložených na vrstvách, což vede k vysokým poplatkům za přenos dat ven. Vrstvené soubory mají nastaven zabezpečený atribut systému Windows FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS, a proto doporučujeme poradit se s dodavatelem softwaru, abyste zjistili, jak nakonfigurovat jejich řešení tak, aby přeskočilo čtení souborů s tímto atributem (mnoho řešení to dělá automaticky).

Interní antivirová řešení Microsoftu, Windows Defender a System Center Endpoint Protection (SCEP) automaticky přeskočí čtení souborů, které mají tuto sadu atributů. Otestovali jsme je a identifikovali jsme jeden malý problém: když přidáte server do existující skupiny synchronizace, soubory menší než 800 bajtů se odvolají (stáhnou) na novém serveru. Tyto soubory zůstanou na novém serveru a nebudou vrstvené, protože nesplňují požadavek na velikost vrstvení (>64 KiB).

Poznámka:

Dodavatelé antivirové ochrany můžou zkontrolovat kompatibilitu mezi produktem a Synchronizací souborů Azure pomocí sady Testů kompatibility antivirové ochrany pro synchronizaci souborů Azure, která je k dispozici ke stažení na webu Stažení softwaru společnosti Microsoft.

Záloha

Pokud je povolené vrstvení cloudu, nepoužívejte řešení, která přímo zálohují koncový bod serveru nebo virtuální počítač, na kterém se nachází koncový bod serveru. Cloudové vrstvení způsobí, že na koncovém bodu serveru je uložena pouze podmnožina vašich dat, zatímco úplná datová sada je v úložišti souborů Azure. V závislosti na použitém řešení zálohování se vrstvené soubory buď přeskočí a nezazálohují (protože mají nastavený atribut FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS), nebo se obnoví na disk, což vede k vysokým poplatkům za výstupní přenos dat. K přímé zálohování sdílené složky Azure doporučujeme použít řešení cloudového zálohování. Další informace najdete v tématu Zálohování sdílených složek Azure nebo se obraťte na poskytovatele zálohování a zjistěte, jestli podporuje zálohování sdílených složek Azure.

Pokud raději používáte místní řešení zálohování, měly by se zálohy provádět na serveru ve skupině synchronizace, která má zakázané vrstvení cloudu, a ujistěte se, že neexistují žádné vrstvené soubory. Při obnovování použijte možnosti obnovení na úrovni svazku nebo na úrovni souboru. Obnovené soubory pomocí možnosti obnovení na úrovni souboru se budou synchronizovat se všemi koncovými body ve skupině synchronizace a stávající soubory se nahradí verzí obnovenou ze zálohy. Obnovení na úrovni svazku nenahrazuje novější verze souborů ve sdílené složce Azure ani v jiných koncových bodech serveru.

Poznámka:

Obnovení holého počítače (BMR), obnovení virtuálního počítače, obnovení systému (integrované obnovení operačního systému Windows) a obnovení na úrovni souborů s jeho vrstvenou verzí (k tomu dochází v případě, že zálohovací software zálohuje vrstvený soubor místo úplného souboru) může způsobit neočekávané výsledky a při povoleném vrstvení cloudu nejsou v současné době podporovány. Snímky VSS (včetně karty Předchozí verze) se podporují u svazků, u kterých je povolené vrstvení cloudu. Musíte však povolit kompatibilitu předchozích verzí prostřednictvím PowerShellu. Zjistěte, jak na to.

Klasifikace dat

Pokud máte nainstalovaný software pro klasifikaci dat, může povolení vrstvení cloudu vést ke zvýšení nákladů ze dvou důvodů:

1. Díky povolenému vrstvení cloudu se vaše nejžhavější soubory ukládají do mezipaměti místně a vaše nejchladnější soubory se vrství do sdílené složky Azure v cloudu. Pokud vaše klasifikace dat pravidelně kontroluje všechny soubory ve sdílené složce, musí se při kontrole odvolat soubory vrstvené do cloudu.

2. Pokud software pro klasifikaci dat používá metadata v datovém proudu souboru, musí být soubor plně obnoven, aby software mohl vidět klasifikaci.

Tyto nárůsty počtu odvolání a množství odvolaných dat můžou zvýšit náklady.

Zásady aktualizace agenta Synchronizace souborů Azure

Agent Synchronizace souborů Azure se pravidelně aktualizuje, aby přidal nové funkce a vyřešil problémy. Doporučujeme aktualizovat agenta Synchronizace souborů Azure, protože jsou k dispozici nové verze.

Hlavní verze vs. vedlejší verze agenta

• Hlavní verze agentů často obsahují nové funkce a mají rostoucí číslo jako první část čísla verze. Příklad: 18.0.0.0.0
• Menší verze agentů se také nazývají „opravy“ a vydávají se častěji než hlavní verze. Často obsahují opravy chyb a menší vylepšení, ale žádné nové funkce. Příklad: 18.2.0.0

Možnosti upgradu

Existuje pět schválených a otestovaných způsobů instalace aktualizací agenta Synchronizace souborů Azure.

1. K instalaci aktualizací agenta použijte funkci automatického upgradu agenta Synchronizace souborů Azure. Agent Synchronizace souborů Azure se automaticky upgraduje. Můžete vybrat, jestli chcete nainstalovat nejnovější verzi agenta, pokud je k dispozici nebo aktualizovat, když je aktuálně nainstalovaný agent blízko vypršení platnosti. Další informace najdete v tématu Automatická správa životního cyklu agenta.
2. Nakonfigurujte službu Microsoft Update tak, aby automaticky stáhla a nainstalovala aktualizace agenta. Doporučujeme nainstalovat každou aktualizaci Synchronizace souborů Azure, abyste měli přístup k nejnovějším opravám agenta serveru. Microsoft Update usnadňuje tento proces tím, že automaticky stahuje a instaluje aktualizace za vás.
3. Ke stažení a instalaci aktualizací agenta použijte AfsUpdater.exe. AfsUpdater.exe se nachází v instalačním adresáři agenta. Poklikáním na spustitelný soubor stáhněte a nainstalujte aktualizace agenta. V závislosti na verzi verze možná budete muset server restartovat.
4. Opravte existujícího agenta Synchronizace souborů Azure pomocí souboru opravy služby Microsoft Update nebo spustitelného souboru .msp. Nejnovější balíček aktualizace Synchronizace souborů Azure je možné stáhnout z katalogu služby Microsoft Update. Spuštění spustitelného souboru .msp aktualizuje instalaci služby Synchronizace souborů Azure pomocí stejné metody, jakou automaticky používá služba Microsoft Update. Při aplikaci opravy Microsoft Update dochází k upgradu na místě instalace služby Azure File Sync.
5. Stáhněte si nejnovější instalační program agenta Synchronizace souborů Azure z webu Microsoft Download Center. Pokud chcete upgradovat existující instalaci agenta Synchronizace souborů Azure, odinstalujte starší verzi a pak nainstalujte nejnovější verzi ze staženého instalačního programu. Nastavení agenta (registrace serveru, koncové body serveru atd.) se uchovávají při odinstalaci agenta Synchronizace souborů Azure.

Poznámka:

Downgrade agenta Azure File Sync není podporován. Nové verze často zahrnují zásadní změny ve srovnání se starými verzemi, takže proces downgradu není podporován. Pokud narazíte na problémy s aktuální verzí agenta, obraťte se na podporu nebo upgrade na nejnovější dostupnou verzi.

Automatická správa životního cyklu agenta

Agent Synchronizace souborů Azure se automaticky upgraduje. Můžete vybrat některý ze dvou režimů a určit údržbové okno, během kterého se server pokusí o provedení upgradu. Tato funkce je navržená tak, aby vám pomohla se správou životního cyklu agenta tím, že buď poskytuje ochranné mantinely bránící vypršení platnosti agenta, nebo umožňuje zachovat aktuální nastavení.

1. Výchozí nastavení se pokusí zabránit vypršení platnosti agenta. Do 21 dnů od uvedeného data vypršení platnosti agenta se agent pokusí provést samo-upgrade. Spustí se pokus o upgrade jednou týdně do 21 dnů před vypršením platnosti a ve vybraném časovém období údržby. Tato možnost eliminuje potřebu provádění běžných oprav služby Microsoft Update.
2. Volitelně můžete vybrat, že se agent automaticky upgraduje, jakmile bude dostupná nová verze agenta (aktuálně se nevztahuje na clusterované servery). K této aktualizaci dochází během vybraného časového období údržby a umožňuje serveru využívat nové funkce a vylepšení, jakmile budou obecně dostupné. Toto je doporučené bezstarostné nastavení, které poskytuje hlavní verze agenta a pravidelné aktualizační záplaty pro váš server. Každý vydaný agent je v kvalitě GA. Pokud vyberete tuto možnost, Microsoft vám poskytne nejnovější verzi agenta. Clusterované servery jsou vyloučené. Po dokončení testovací verze bude agent k dispozici také na webu Microsoft Update a webu Stažení softwaru.

Změna nastavení automatického upgradu

Následující pokyny popisují, jak po dokončení instalačního programu změnit nastavení, pokud potřebujete provést změny.

Otevřete konzolu PowerShellu a přejděte do adresáře, do kterého jste nainstalovali agenta synchronizace, a pak naimportujte rutiny serveru. Ve výchozím nastavení by to vypadalo přibližně takto:

cd 'C:\Program Files\Azure\StorageSyncAgent'
Import-Module -Name .\StorageSync.Management.ServerCmdlets.dll

Pomocí Get-StorageSyncAgentAutoUpdatePolicy můžete zkontrolovat aktuální nastavení zásad a určit, jestli ho chcete změnit.

Pokud chcete změnit aktuální nastavení zásad na zpožděnou trasu aktualizace, můžete použít:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

Pokud chcete změnit aktuální nastavení zásad na sledování okamžité aktualizace, můžete použít:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest -Day <day> -Hour <hour>

Poznámka:

Pokud už byla dokončena testovací fáze pro nejnovější verzi agenta a zásada automatické aktualizace agenta se změní na "InstallLatest", agent se nebude automaticky aktualizovat, dokud nebude uvolněna další verze agenta. Pokud chcete aktualizovat verzi agenta, která prošla testováním, použijte službu Microsoft Update nebo AfsUpdater.exe. Pokud chcete zkontrolovat, jestli je verze agenta aktuálně spuštěná, projděte si část podporované verze v poznámkách k verzi.

Záruky životního cyklu agenta a správy změn

Synchronizace souborů Azure je cloudová služba, která průběžně zavádí nové funkce a vylepšení. To znamená, že konkrétní verze agenta Synchronizace souborů Azure může být podporována pouze po omezenou dobu. Abyste usnadnili nasazení, následující pravidla vám zajistí dostatek času a oznámení pro přizpůsobení aktualizací nebo upgradů agentů v procesu správy změn:

• Podpora hlavních verzí agenta je poskytována minimálně po dobu 12 měsíců od data původního vydání.
• Zaručujeme, že podpora hlavních verzí agentů se překrývá alespoň na tři měsíce.
• Upozornění se vydávají pro registrované servery s využitím agenta, jehož platnost brzy vyprší, alespoň tři měsíce před vypršením platnosti. Můžete zkontrolovat, jestli registrovaný server používá starší verzi agenta, v části registrované servery služby Synchronizace úložiště.
• Životnost dílčí verze agenta je vázána na přidruženou hlavní verzi. Například když je nastavena platnost agenta verze 18.0.0.0, všechny verze agenta začínající 18.*.*.* vyprší společně.

Poznámka:

Při instalaci verze agenta s upozorněním na vypršení platnosti se zobrazí upozornění, ale instalace bude úspěšná. Pokus o instalaci nebo připojení s verzí agenta s vypršenou platností není podporovaný a bude blokovaný.

Další kroky

• Zvažte nastavení brány firewall a proxy serveru.
• Nasazení služby Azure Files
• Nasazení Synchronizace souborů Azure
• Monitorování synchronizace souborů Azure