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 Synchronizace souborů Azure znáte, 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ádat sdílenou složku 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ě Azure Files a současně zachovat flexibilitu, výkon a kompatibilitu místního souborového serveru. Synchronizace souborů Azure transformuje místní (nebo cloudový) Windows Server do rychlé mezipaměti sdílené složky 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á sdílená složka, která poskytuje koncový bod cloudu Synchronizace souborů Azure vztahu synchronizace. 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 se sdílenou složkou Azure. Může se jednat o konkrétní složku na svazku nebo kořen svazku. Pokud se jejich obory názvů nepřekrývají, může na stejném svazku existovat více koncových bodů serveru.
• 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ě. Tento fond úložiště lze použít k nasazení více sdílených složek a také k dalším prostředkům úložiště, jako jsou kontejnery objektů blob, fronty nebo tabulky. 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é budete používat pro nasazení služby Azure Files:

• Účty úložiště pro obecné účely verze 2 (GPv2): Účty úložiště GPv2 umožňují nasadit sdílené složky Azure na hardwaru založeném na standardu nebo pevném disku (založeném na pevných discích). 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.
• Účty úložiště FileStorage: Účty úložiště FileStorage umožňují nasadit sdílené složky Azure na hardwaru založeném na discích SSD (Premium/Solid-State Disk). Účty FileStorage je možné použít pouze k ukládání sdílených složek Azure; V účtu FileStorage není možné nasadit žádné jiné prostředky úložiště (kontejnery objektů blob, fronty, tabulky atd.). Sdílené složky SMB i NFS můžou nasazovat jenom účty FileStorage.

Na webu Azure Portal, PowerShellu nebo rozhraní příkazového řádku můžete narazit na několik dalších typů účtů úložiště. Dva typy účtů úložiště: BlockBlobStorage a účty úložiště BlobStorage nemůžou obsahovat sdílené složky Azure. Další dva typy účtů úložiště, které se můžou zobrazit, jsou obecné účely verze 1 (GPv1) a klasické účty úložiště, z nichž obě můžou obsahovat sdílené složky Azure. I když účty úložiště GPv1 a klasické úložiště můžou obsahovat sdílené složky Azure, většina nových funkcí služby Azure Files je dostupná jenom v účtech úložiště GPv2 a FileStorage. Proto doporučujeme používat pouze účty úložiště GPv2 a FileStorage pro nová nasazení a upgradovat účty úložiště GPv1 a klasické, pokud už ve vašem prostředí existují.

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í s Synchronizace souborů Azure a obsahují relace skupin synchronizace. Prostředek služby synchronizace úložiště je partnerský vztah prostředku účtu úložiště a dá se podobně nasadit 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í funkci vrstvení cloudu, která poskytuje možnost ukládání do mezipaměti Synchronizace souborů Azure. Aby bylo možné synchronizovat se sdílenou složkou Azure, musí být účet úložiště obsahující 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 koncového bodu serveru ve skupině synchronizace můžete provádět změny a synchronizovat soubory s ostatními koncovými body ve skupině synchronizace. Pokud přímo provedete změnu cloudového koncového bodu (sdílené složky Azure), je potřeba nejprve zjistit změny úlohou detekce změn Synchronizace souborů Azure. Ú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ě.

Předchozí část popisuje základní prostředek, který se má nakonfigurovat pro Synchronizace souborů Azure: službu synchronizace úložiště. Windows Server je možné zaregistrovat pouze do jedné služby synchronizace úložiště. Proto je často nejlepší nasadit jenom jednu službu synchronizace úložiště a zaregistrovat na ní všechny servery.

Vytvořte více služeb synchronizace úložiště jenom v případě, že máte:

• různé sady serverů, které nesmí nikdy vzájemně vyměňovat data. V takovém případě chcete navrhnout systém tak, aby vyloučil určité sady serverů pro synchronizaci se sdílenou složkou Azure, která se už používá jako koncový bod cloudu ve skupině synchronizace v jiné službě synchronizace úložiště. Dalším způsobem, jak se na to podívat, je to, že Windows Servery zaregistrované v jiné synchronizační službě úložiště se nemůžou synchronizovat se stejnou sdílenou složkou Azure.
• potřeba mít více registrovaných serverů nebo skupin synchronizace než jedna služba synchronizace úložiště může podporovat. Další podrobnosti najdete v cílech škálování Synchronizace souborů 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 svazcích můžete mít více složek, které aktuálně sdílíte místně jako sdílené složky SMB uživatelům a aplikacím. 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í seskupení

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 místních sdílených složek potřeba jenom jedna sdílená složka Azure v cloudu.

Synchronizace svazků

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 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. Otestujeme sdílené složky Azure a Synchronizace souborů Azure s 100 miliony položek (soubory a složky) na sdílenou složku. Osvědčeným postupem je ale snažit se zachovat číslo nižší než 20 milionů nebo 30 milionů v jedné sdílené složce. 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 zobrazení oboru názvů na serveru s povoleným Synchronizace souborů Azure.
• Obnovení na straně cloudu ze snímku sdílené složky Azure 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.

Tip

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í informuje o tom, kolik prostředků skupiny synchronizace Synchronizace souborů Azure, 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 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á 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é složky 1:1 s účty úložiště. Nemusí to ale 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 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 aplikaci do Azure, která bude používat sdílenou složku Azure nativně, možná budete potřebovat vyšší výkon ze sdílené složky 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.

Tip

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. Seznamy 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 najdete v cílech škálování Synchronizace souborů Azure.

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 testuje 100 milionů položek (souborů a složek) na 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 ale může být lepší znovu seskupit složky, aby se synchronizovaly se dvěma složkami místo jedné sdílené složky 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 místní sdílené složky a synchronizovat mezi další místní servery a přidat možnost synchronizace se 30 dalšími sdílenými složkami Azure na další server.

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í)
0	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)	No	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. 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 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 v krocích po druhém, dokud nebudou všechna data vrstvené do cloudu nebo migrace. 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, synchronizací a zopakováním procesu. 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é cílové sdílené složky Azure (konsolidace)	Ano	Nejde 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ýše)	Synchronizujte kořen svazku, který obsahuje více sdílených složek nebo složek nejvyšší úrovně. Další informace najdete v tématu Koncept seskupování sdílených složek 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ě je cílem škálování pro výkon. Vstupně-výstupní operace za sekundu a propustnost se sdílí mezi 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. V ideálním případě je nejlepší 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. 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 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. V ideálním případě je nejlepší zůstat nižší než 20 nebo 30 milionů na podíl.	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)	No	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 dalšími aspekty cílení na jeden souborový server najednou.

Vytvoření tabulky 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 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 Storage Server	Plná a základní
Windows Server 2012 R2*	Datacenter, Essentials, Standard a Storage 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.

Budoucí verze Windows Serveru budou přidány při jejich vydání.

Důležité

Doporučujeme udržovat všechny servery, které používáte s Synchronizace souborů Azure aktuální s nejnovějšími aktualizacemi z služba Windows Update.

Minimální systémové prostředky

Synchronizace souborů Azure vyžaduje server, fyzický nebo virtuální, s alespoň jedním procesorem, 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 Synchronizace souborů Azure synchronizační server pouze s minimálními požadavky. Další informace najdete v části Doporučené systémové zdroje .

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 oboru názvů se kvůli výkonu ukládají 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 zadali jak velikost oboru názvů, tak převod na kapacitu pro typické sdílené složky 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 oboru 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 Synchronizace souborů Azure cíle škálování.

Tip

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á četnost změn je 0,5 % změn v oboru názvů za den. V případě vyšších úrovní četnosti změn zvažte přidání dalších procesorů.

Rutina vyhodnocení

Před nasazením Synchronizace souborů Azure byste měli vyhodnotit, jestli je kompatibilní se systémem pomocí rutiny Synchronizace souborů Azure vyhodnocení. 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

Zobrazení výsledků ve sdíleném svazku clusteru:

$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; Systémy souborů ReFS, FAT, FAT32 a jiných systémů souborů se nepodporují.

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

Funkce	Stav podpory	Notes
Seznamy ACL	Plně podporovaná	Volitelné seznamy řízení přístupu ve stylu Windows se zachovají Synchronizace souborů Azure a vynucují se systémem Windows Server na koncových bodech serveru. Seznamy ACL je možné vynutit také při přímém připojení sdílené složky Azure, ale vyžaduje se další konfigurace. Další informace najdete v části Identita.
Pevná propojení	Přeskočena
Symbolické odkazy	Přeskočena
Přípojné body	Částečně podporováno	Přípojné body můžou být kořenem koncového bodu serveru, ale přeskočí se, pokud jsou obsaženy v oboru názvů koncového bodu serveru.
Křižovatek	Přeskočena	Například složky DfrsrPrivate distribuovaného systému souborů a DFSRoots.
Body rozboru	Přeskočena
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 už není při stažení změny řídký.
Alternativní datové Toky (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
Bravo	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. PŘIHRÁDKY	Složka
\SyncShareState	Složka pro synchronizaci
. SystemShareInformation	Složka pro synchronizaci ve sdílené složce 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:

• S povolenou vrstvení 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 volného místa svazku

• Při zakázaném vrstvení cloudu:

  • 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 zásady volného místa svazku na 20 %.

1. Ntfs přidělí velikost clusteru pro každý vrstvený soubor. 1 milion souborů * 4 velikost clusteru KiB = 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ářů) * 4 velikost clusteru 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 volného místa svazku je 20 %. 1000 GiB * 0,2 = 200 GiB

V tomto případě by Synchronizace souborů Azure potřeboval pro tento obor názvů 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. Clustering s podporou převzetí služeb při selhání systému Windows Server podporuje Synchronizace souborů Azure pro možnost nasazení Souborový server pro obecné použití. Další informace o tom, jak nakonfigurovat roli Souborový server pro obecné použití v 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 Synchronizace souborů Azure je cluster windows serveru s podporou převzetí služeb při selhání s 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 s podporou převzetí služeb při selhání.

Odstranění duplicitních dat

Windows Server 2022, Windows Server 2019 a Windows Server 2016
Odstranění duplicitních dat se podporuje bez ohledu na to, jestli je na svazku pro Windows Server 2016, Windows Server 2019 a Windows Server 2019 a Windows Server 2022 povolené nebo zakázané vrstvení cloudu. Povolení odstranění duplicitních dat na svazku s povolenou vrstvení cloudu umožňuje ukládat do mezipaměti více souborů místně bez zřízení dalšího úložiště.

Pokud je odstranění duplicitních dat na svazku s povolenou vrstvení cloudu, budou se soubory optimalizované pro odstranění duplicitních dat v umístění koncového bodu serveru vrstvit podobně jako u normálního souboru na základě nastavení zásad vrstvení cloudu. Po vrstvení optimalizovaných souborů odstranění duplicitních dat se úloha uvolňování paměti pro odstranění duplicitních dat spustí automaticky, aby uvolnila místo na disku odebráním nepotřebných bloků dat, na které už ostatní soubory na svazku odkazují.

Všimněte si, že úspory svazků platí pouze pro server; vaše data ve sdílené složce Azure nebudou odstraněna.

Poznámka:

Pro podporu odstranění duplicitních dat na svazcích s povolenou vrstvení cloudu ve Windows Serveru 2019 musí být nainstalovaná aktualizace Windows Update 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 odstranění duplicitních dat na svazku povolené, musí být vrstvení cloudu zakázané.

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 data přeskočí vrstvení souborů, které mohly mít jinak nárok na vrstvení kvůli úloze optimalizace odstranění duplicitních dat přistupující k souborům.

• U probíhajících úloh optimalizace odstranění duplicitních dat se vrstvení cloudu pomocí zásad data zpozdí nastavením MinimumFileAgeDays odstranění duplicitních dat, pokud soubor ještě není vrstvený.

  • Příklad: Pokud je nastavení MinimumFileAgeDays sedm dní a zásada data vrstvení cloudu je 30 dní, zásady data budou vrstvit soubory po 37 dnech.
  • Poznámka: Po vrstvení souboru Synchronizace souborů Azure úloha optimalizace odstranění duplicitních dat soubor přeskočí.

• Pokud je server se systémem Windows Server 2012 R2 s nainstalovaným agentem Synchronizace souborů Azure upgradován na Windows Server 2016, Windows Server 2019 nebo Windows Server 2022, je potřeba provést následující kroky pro podporu 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 nebo Windows Server 2022).
  • 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 spolupráci s obory názvů DFS (DFS-N) a Replikací DFS (DFS-R).

Obory názvů DFS (DFS-N):Synchronizace souborů Azure je plně podporována 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 Synchronizace souborů Azure. Existuje však několik scénářů, ve kterých byste chtěli použít dfs-R a Synchronizace souborů Azure společně:

• Migrujete z nasazení DFS-R do Synchronizace souborů Azure nasazení. Další informace najdete v tématu Migrace nasazení replikace DFS (DFS-R) do Synchronizace souborů Azure.
• Ne každý místní server, který potřebuje kopii dat souboru, je možné připojit přímo k internetu.
• Pobočkové servery konsoliduje data na jeden centrální server, pro který chcete použít Synchronizace souborů Azure.

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

1. Synchronizace souborů Azure vrstvení cloudu musí být na svazcích s replikovanými složkami DFS-R zakázané.
2. Koncové body serveru by se neměly konfigurovat ve složkách replikace jen pro čtení DFS-R.
3. Pouze jeden koncový bod serveru se může překrývat s umístěním DFS-R. Konflikty můžou vést k několika koncovým bodům serveru překrývajícím se s jinými aktivními umístěními DFS-R.

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.

Windows Search

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

Poznámka:

Klienti Windows způsobí odvolání při vyhledávání ve sdílené složce, pokud je na klientském počítači povolené 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)

S Synchronizace souborů Azure by se neměly 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 replikují, jako jsou změny 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ů. Synchronizace souborů Azure v systému Windows Server používá zaznamenávání do deníku Windows USN k automatickému zahájení relace synchronizace 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, Synchronizace souborů Azure 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 Synchronizace souborů Azure metrik výkonu a Synchronizace souborů Azure cílů škálování.

Identita

Synchronizace souborů Azure funguje se standardní identitou založenou na AD bez jakéhokoli speciálního nastavení nad rámec nastavení synchronizace. Když používáte Synchronizace souborů Azure, obecně se očekává, že většina přístupů prochází servery Synchronizace souborů Azure ukládáním do mezipaměti, nikoli prostřednictvím sdílené složky Azure. Vzhledem k tomu, že se koncové body serveru nacházejí na Windows Serveru a Windows Server už dlouho podporuje seznamy ACL a seznamy ACL ve stylu Windows, není potřeba nic nad rámec toho, aby souborové servery s Windows zaregistrované ve službě synchronizace úložiště byly 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ž se změny provedené přímo ve sdílené složce Azure budou synchronizovat s koncovými body serveru ve skupině synchronizace, můžete také chtít zajistit, abyste u sdílené složky přímo v cloudu vynutili svá oprávnění AD. Abyste to mohli udělat, musíte svůj účet úložiště připojit k místní službě AD, stejně jako když jsou vaše souborové servery Windows připojené k doméně. Další informace o připojení domény k účtu úložiště ke službě Active Directory vlastněné zákazníkem najdete v přehledu služby Azure Files Active Directory.

Důležité

K úspěšnému nasazení Synchronizace souborů Azure se nevyžaduje připojení k účtu úložiště ke službě Active Directory. Jedná se o přísně volitelný krok, který umožňuje sdílené složce Azure vynutit 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í. Synchronizace souborů 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:

• Synchronizace tunelu a nahrávání a stahování provozu 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.

Tip

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. Přestože 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 s Synchronizace souborů Azure.

Další informace o Synchronizace souborů Azure a sítích najdete v tématu Synchronizace souborů Azure aspekty sítí.

Šifrování

Při použití Synchronizace souborů Azure existují tři různé vrstvy šifrování, které je potřeba vzít v úvahu: šifrování neaktivního úložiště Windows Serveru, šifrování přenášeného mezi agentem Synchronizace souborů Azure a Azure a šifrování neaktivních dat ve sdílené složce Azure.

Šifrování neaktivních uložených dat 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ší.

K zajištění šifrování pod systémem souborů poskytuje Windows Server doručenou poštu BitLockeru. Nástroj BitLocker je plně transparentní pro Synchronizace souborů Azure. Primárním důvodem použití šifrovacího mechanismu, jako je BitLocker, je zabránit fyzickému exfiltraci dat z vašeho místního datacentra tím, že někdo ukradne disky, a aby zabránil zkušebnímu načtení neoprávněného operačního systému, aby mohl provádět neoprávněné čtení a zápisy do vašich dat. Další informace o Nástroji BitLocker najdete v přehledu nástroje BitLocker.

Produkty třetích stran, které fungují podobně jako Nástroj BitLocker, ve které se nacházejí pod svazkem NTFS, by měly podobně fungovat plně transparentně s Synchronizace souborů Azure.

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í mechanismu šifrování, 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 neoprávněné 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:

Synchronizace souborů Azure služba 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. Synchronizace souborů Azure oblasti služeb přidané po 1. 5. 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 obměně. 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 a HDD, 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 Úrovně Premium používají jednotky SSD (Solid-State Drive) a 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 Úrovně Premium jsou vhodné pro širokou škálu úloh, jako jsou databáze, hostování webů a vývojová prostředí. Sdílené složky Úrovně Premium je možné použít s protokoly SMB (Server Message Block) a NFS (Network File System). Sdílené složky Úrovně Premium se nasazují v druhu účtu úložiště FileStorage a jsou k dispozici pouze ve zřízeném fakturačním modelu. Další informace o zřízeném fakturačním modelu pro sdílené složky úrovně Premium najdete v tématu Principy zřizování sdílených složek úrovně Premium. Sdílené složky úrovně Premium nabízejí smlouvu SLA s vyšší dostupností než standardní sdílené složky (viz Úroveň Azure Files Premium).

• HDD (Standard):: Sdílené složky úrovně Standard používají pevné disky (HDD) a poskytují nákladově efektivní možnost úložiště pro sdílené složky pro obecné účely. Sdílené složky úrovně Standard se nasazují v typu účtu úložiště pro obecné účely verze 2 (GPv2). Informace o smlouvě SLA najdete na stránce smlouvy o úrovni služeb Azure (viz Účty úložiště). Standardní sdílené složky používají model průběžných plateb, který poskytuje ceny založené na využití. Úroveň přístupu sdílené složky umožňuje upravit náklady na úložiště oproti nákladům na vstupně-výstupní operace za sekundu, abyste optimalizovali celkovou fakturu:

  • Transakční optimalizované sdílené složky nabízejí nejnižší ceny transakcí za transakce s velkým zatížením, které nevyžadují nízkou latenci nabízenou sdílenými složkami úrovně Premium. Doporučuje se při migraci dat do služby Azure Files.
  • Horké sdílené složky nabízejí vyvážené ceny úložiště a transakcí pro úlohy, které mají dobrou míru obojího.
  • Studené sdílené složky nabízejí cenově nejvýhodnější ceny úložiště pro úlohy náročné na ú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 latenci s jednou číslicí nebo používáte místní médium úložiště SSD, je úroveň Premium pravděpodobně nejvhodnější. Pokud nízká latence není tak velká část zájmu, například u týmových sdílených složek připojených místně z Azure nebo místně uložených v mezipaměti pomocí Synchronizace souborů Azure, může být úložiště úrovně Standard vhodnější z hlediska nákladů.

Jakmile vytvoříte sdílenou složku v účtu úložiště, nemůžete ji přesunout na vrstvy exkluzivní pro různé druhy účtů úložiště. Pokud například chcete přesunout transakční optimalizovanou sdílenou složku na úroveň Premium, musíte vytvořit novou sdílenou složku v účtu úložiště FileStorage a zkopírovat data z původní sdílené složky do nové sdílené složky v účtu FileStorage. Ke kopírování dat mezi sdílenými složkami Azure doporučujeme použít AzCopy, ale můžete také použít nástroje jako robocopy ve Windows nebo rsync pro macOS a Linux.

Další informace najdete v tématu Vysvětlení fakturace služby Azure Files.

Regionální dostupnost

V současné době mají standardní sdílené složky s povolenými velkými sdílenými složkami (až 100 kapacit TiB) určitá omezení.

• Podporují se pouze místně redundantní úložiště (LRS) a účty zónově redundantního úložiště (ZRS).
• Jakmile povolíte velké sdílené složky v účtu úložiště, nemůžete účet úložiště převést na geograficky redundantní úložiště (GRS) nebo geograficky zónově redundantní úložiště (GZRS).
• Jakmile povolíte velké sdílené složky, nemůžete je zakázat.

Pokud chcete použít GRS nebo GZRS se standardními sdílenými složkami SMB Azure, podívejte se na geografickou redundanci služby Azure Files pro velké sdílené složky ve verzi Preview.

Dostupnost oblasti synchronizace souborů Azure

Informace o regionální dostupnosti najdete v tématu Dostupné produkty v jednotlivých oblastech.

Následující oblasti vyžadují, abyste si před použitím Synchronizace souborů Azure s nimi vyžádali 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.

Redundance

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):U LRS se každý soubor ukládá třikrát v rámci 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 použití ZRS 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):U GRS 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. GRS poskytuje šest kopií dat rozložených mezi dvěma oblastmi Azure. V případě závažné havárie, jako je trvalá ztráta oblasti Azure kvůli přírodní katastrofě nebo jiné podobné události, Microsoft provede převzetí služeb při selhání. 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í, v případě závažné havárie se data ještě nereplikují do sekundární oblasti. 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):: GZRS si můžete představit jako ZRS, ale s geografickou redundancí. S GZRS 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 převzetí služeb při selhání pro GZRS funguje stejně jako GRS.

Sdílené složky Azure úrovně Standard až 5 TiB podporují všechny čtyři typy redundance. Standardní sdílené složky větší než 5 TiB podporují pouze LRS a ZRS. Sdílené složky Azure úrovně Premium podporují pouze LRS a ZRS.

Účty úložiště pro obecné účely verze 2 (GPv2) 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é do účtů úložiště RA-GRS nebo RA-GZRS se účtují jako GRS nebo GZRS.

Důležité

Geograficky redundantní a geograficky zónově redundantní úložiště mají možnost ručně provést převzetí služeb při selhání úložiště do sekundární oblasti. Pokud používáte Synchronizace souborů Azure kvůli zvýšené pravděpodobnosti ztráty dat, doporučujeme to udělat mimo havárii. V případě havárie, ve které chcete zahájit ruční převzetí služeb při selhání úložiště, budete muset otevřít případ podpory s Microsoftem, abyste získali Synchronizace souborů Azure k obnovení synchronizace 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.

Podrobné pokyny najdete v článku s přehledem migrace sdílených složek Azure a Synchronizace souborů Azure a sdílených složek Azure.

Antivirus

Vzhledem k tomu, že antivirová ochrana funguje vyhledáváním známých škodlivých kódů, může antivirový produkt způsobit odvolání vrstvených souborů, což vede k vysokým poplatkům za výchozí přenos dat. Vrstvené soubory mají zabezpečenou sadu atributů FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS Systému Windows a doporučujeme poradit se s dodavatelem softwaru, abyste zjistili, jak nakonfigurovat řešení tak, aby přeskočovalo čtení souborů s touto sadou atributů (mnoho z nich 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 zjistili jsme jeden malý problém: když přidáte server do existující skupiny synchronizace, soubory menší než 800 bajtů se na novém serveru odvolají (stáhnou). Tyto soubory zůstanou na novém serveru a nebudou vrstvené, protože nesplňují požadavek na velikost vrstvení (>64 kB).

Poznámka:

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

Backup

Pokud je povolené vrstvení cloudu, řešení, která přímo zálohují koncový bod serveru nebo virtuální počítač, na kterém se nachází koncový bod serveru, by neměla být použita. Vrstvení cloudu způsobí, že se v koncovém bodu serveru uloží jenom podmnožina vašich dat s úplnou datovou sadou ve sdílené složce 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í FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS nastavený atribut), nebo se připomenou na disk, což vede k vysokým poplatkům za výchozí 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 nejsou 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álohovaný 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 se v současné době nepodporují. 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.

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ě odvolán, aby software viděl 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. podverze agenta

• Hlavní verze agentů často obsahují nové funkce a jako první část čísla verze mají rostoucí číslo. Příklad: 14.0.0.0.0
• Podverze 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: 14.1.0.0

Cesty 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 lze stáhnout z katalogu služby Microsoft Update. Spuštění spustitelného souboru .msp upgraduje vaši Synchronizace souborů Azure instalaci pomocí stejné metody, kterou automaticky používá služba Microsoft Update. Instalace opravy služby Microsoft Update provede místní upgrade instalace Synchronizace souborů Azure.
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. Instalační program Synchronizace souborů Azure udržuje registraci serveru, skupiny synchronizace a všechna další nastavení.

Poznámka:

Downgrade agenta Synchronizace souborů Azure se nepodporuje. 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 časové období údržby, ve kterém se upgrade pokusí na serveru. 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 data vypršení platnosti agenta se agent pokusí provést samoobslužný 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). Tato aktualizace bude probíhat během vybraného časového období údržby a umožní serveru využívat nové funkce a vylepšení, jakmile budou obecně dostupné. Toto je doporučené nastavení bez obav, které bude poskytovat hlavní verze agenta a také běžné opravy aktualizací na váš server. Každý vydaný agent je ve verzi 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 také k dispozici na webu Microsoft Download Center aka.ms/AFS/agent.

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

Spuštěním můžete Get-StorageSyncAgentAutoUpdatePolicy 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>

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:

• Hlavní verze agenta se podporují nejméně šest měsíců od data počáteční verze.
• Zaručujeme, že se mezi podporou hlavních verzí agentů překrývají aspoň 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 synchronizační služby úložiště.
• Životnost podverze agenta je vázána na přidruženou hlavní verzi. Pokud je například nastavena platnost agenta verze 14.0.0.0, nastaví se platnost agenta verze 14.*.*.* na vypršení platnosti společně.

Poznámka:

Při instalaci verze agenta s upozorněním na vypršení platnosti se zobrazí upozornění, ale 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
• Sledování služby Synchronizace souborů Azure