Plánování nasazení služby Synchronizace souborů Azure

Plánování nasazení Synchronizace souborů Azure zahrnuje výběr serverů, které se mají synchronizovat, způsob uspořádání topologie synchronizace a konfiguraci sítě a vrstvení do cloudu. Použijte tento článek k rozhodnutí, poté se řiďte průvodcem nasazením a nastavte to.

Klíčová rozhodnutí:

  1. Které servery se synchronizují? On-premises Windows servery, Azure VM, nebo obojí? Viz úvahy o Windows souborovém serveru.
  2. Kolik synchronizačních skupin potřebujete? Mapujte své sdílené soubory a serverové složky do synchronizačních topologií.
  3. Budete používat vrstvení do cloudu? Uložit do mezipaměti jen hotové soubory lokálně, abyste ušetřili místo na disku, nebo si nechat plnou kopii? Viz úrovně úložiště.
  4. Jaká síťová konfigurace? Veřejné koncové body, soukromé koncové body nebo firewally? Viz Sítě.
  5. Jak se uživatelé ověří? Viz Identita.
  6. Jaké jsou specifikace Windows Server? Viz Doporučené systémové zdroje.

Koncepty správy

V Azure je prostředek spravovatelnou položkou, kterou vytvoříte a nakonfigurujete v rámci předplatných a skupin prostředků Azure. Prostředky nabízejí poskytovatelé prostředků, což jsou služby pro správu, které poskytují konkrétní typy prostředků. Pokud chcete nasadit Synchronizace souborů Azure, budete pracovat se dvěma klíčovými prostředky:

  • Účty úložiště, které Microsoft.Storage nabízí poskytovatel prostředků. Účty úložiště jsou prostředky nejvyšší úrovně, které představují sdílený fond úložiště, IOPS (vstupně-výstupních operací za sekundu) a propustnost, do kterého můžete podle typu účtu úložiště nasadit klasické sdílené složky nebo jiné prostředky úložiště. Všechny prostředky úložiště, které nasadíte do účtu úložiště, sdílejí limity, které platí pro tento účet úložiště. Klasické sdílené složky podporují protokoly sdílení souborů SMB i NFS, ale synchronizaci souborů Azure můžete používat jenom se sdílenými složkami SMB.

    Poznámka:

    Azure Files také podporuje nasazení sdílených disků jako prostředku Azure na nejvyšší úrovni prostřednictvím Microsoft.FileShares poskytovatele prostředků. Vzhledem k tomu, že tyto sdílené složky v současné době podporují pouze protokol NFS, Synchronizace souborů Azure je nepodporuje.

  • Služby synchronizace úložiště, které Microsoft.StorageSync nabízí poskytovatel prostředků. Služby synchronizace úložiště fungují jako kontejnery pro správu, které umožňují registrovat souborové servery Windows a definovat relace synchronizace pro Synchronizaci souborů Azure.

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

Klasické sdílené složky nebo sdílené složky nasazené v účtech úložiště představují tradiční způsob nasazení sdílených složek pro Azure Files. Podporují všechny klíčové funkce, které Azure Files podporují, včetně protokolů SMB a NFS, úrovní médií SSD a HDD, všech typů redundance a dostupnosti v každé oblasti. Další informace o klasických sdílených složkách najdete v tématu Klasické sdílené složky.

Klasická nasazení souborových sdílení používají dva druhy účtů úložiště:

  • Zřízené účty úložiště: Druh FileStorage účtu úložiště identifikuje zřízené účty úložiště. Klasická sdílení souborů zřízená předem můžete nasadit buď na hardware se SSD, nebo s HDD, a to pomocí předem zřízených účtů úložiště. K ukládání klasických sdílených složek můžete použít jenom zřízené účty úložiště. Nemůžete je použít pro jiné prostředky úložiště dat, jako jsou kontejnery objektů blob, fronty a tabulky. Pro všechna nová nasazení klasických sdílených složek používejte předem zřízené účty úložiště.

  • Účty úložiště s průběžným platbami: StorageV2 Druh účtu úložiště identifikuje účty úložiště s průběžným platbami. Sdílené složky v modelu průběžných plateb můžete nasadit na hardwaru založeném na HDD pomocí účtů úložiště v modelu průběžných plateb. Účty úložiště s průběžným platbami můžete použít k ukládání klasických sdílených složek a dalších prostředků úložiště, jako jsou kontejnery objektů blob, fronty nebo tabulky.

Koncepty správy synchronizace souborů Azure

V rámci služby synchronizace úložiště můžete nasadit:

  • Registrované servery, které představují Windows Server s vztahem důvěryhodnosti se službou synchronizace úložiště. Registrované servery můžou být buď jednotlivé servery, nebo cluster. Server nebo cluster je však možné zaregistrovat pouze v jedné službě synchronizace úložiště.

  • Skupiny synchronizace, které definují vztah synchronizace mezi koncovým bodem cloudu a jedním nebo více koncovými body serveru. Koncové body ve skupině synchronizace se vzájemně synchronizují. Pokud máte například dvě různé sady souborů, které chcete spravovat pomocí Synchronizace souborů Azure, vytvoříte dvě skupiny synchronizace a do každé skupiny synchronizace přidáte různé koncové body.

    • Koncové body cloudu, které představují sdílení souborů Azure.
    • Koncové body serveru, které představují cesty na registrovaných serverech, které jsou synchronizované se službou Azure Files. Registrovaný server může obsahovat více koncových bodů serveru, pokud se jejich obory názvů nepřekrývají.

Důležité

V oblasti názvů libovolného cloudového koncového bodu nebo serverového koncového bodu ve skupině synchronizace můžete provádět změny a synchronizovat soubory do ostatních koncových bodů ve skupině synchronizace. Pokud provedete změnu cloudového koncového bodu (sdílené složky Azure) přímo, úloha Synchronizace souborů Azure musí nejprve rozpoznat změny. Úloha detekce změn pro koncový bod cloudu se spustí jenom jednou za 24 hodin. Další informace najdete v tématu Nejčastější dotazy k Azure Files a Synchronizaci souborů Azure.

Počet potřebných synchronizačních služeb úložiště

Synchronizační služba úložiště je kořenový prostředek Azure Resource Manageru pro Synchronizaci souborů Azure. Spravuje vztahy synchronizace mezi instalacemi Windows Serveru a sdílenými složkami Azure. Každá synchronizační služba úložiště může obsahovat více skupin synchronizace a více registrovaných serverů.

Každou instanci Windows Serveru je možné zaregistrovat pouze do jedné synchronizační služby ú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ě pomocí instančního objektu Resource Manageru k vytvoření koncových bodů serveru na serveru.

Když navrhujete topologie Synchronizace souborů Azure, izolujte data jasně 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é organizační jednotky a potřebujete přísnou izolaci dat mezi těmito skupinami, vytvořte pro každou skupinu vyhrazenou synchronizační službu ú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 tato konfigurace nezajistí úplnou izolaci.

Další pokyny k izolaci dat pomocí samostatných předplatných nebo skupin prostředků v Azure najdete v tématu o poskytovatelích a typech prostředků Azure.

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

Před nasazením jakýchkoli prostředků si naplánujte, co budete synchronizovat na místním serveru a které sdílení souborů Azure použijete. Plánování vám pomůže určit, kolik účtů úložiště, sdílených složek a synchronizačních prostředků potřebujete. Tyto aspekty jsou relevantní, i když se vaše data aktuálně nenachází v instanci Windows Serveru nebo na serveru, který chcete používat dlouhodobě. Část migrace tohoto článku vám pomůže 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 dostatečně malý počet sdílených složek, méně než 30 pro jednu instanci systému Windows Server, 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 potřebujete jenom jednu sdílenou složku Azure v cloudu pro tuto skupinu místních sdílených složek.

Synchronizace hlasitosti

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

Synchronizace kořenového adresáře svazku není vždy nejlepší volbou. Synchronizace více umístění má několik výhod. To například pomáhá udržet počet položek v nižším rozsahu synchronizace. Testujeme sdílení souborů Azure a Synchronizace souborů Azure 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 se může dokončit rychleji, což zase snižuje čekání na zobrazení prostoru názvů na serveru, kde je povolena synchronizace souborů Azure.
  • Obnovení ze sdílené složky Azure na straně cloudu je rychlejší.
  • Zotavení po havárii místního serveru může výrazně zrychlit.
  • Změny provedené přímo ve sdílené složce Azure (mimo synchronizaci) je možné detekovat a synchronizovat rychleji.

Návod

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

Strukturovaný přístup k mapě nasazení

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

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

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

  • Sdílené ú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.

    Dávejte pozor na omezení IOPS úložného účtu při nasazování sdílených složek Azure. Ideálně byste měli namapovat diskové sdílení 1:1 se skladovacími účty. Toto mapování ale nemusí být vždy možné kvůli různým limitům a omezením, jak ve vaší organizaci, tak v Azure. Pokud nemůžete nasadit jenom jednu sdílenou složku v jednom účtu úložiště, zvažte, které sdílené složky budou vysoce aktivní a které sdílené složky budou méně aktivní. Nedávejte nejžhavější sdílené soubory 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

Na základě těchto informací je často nutné seskupit několik složek nejvyšší úrovně na svazcích do nového společného kořenového adresáře. Pak tento nový kořenový adresář a všechny složky, které jste do něj seskupili, synchronizujete s jednou sdílenou složkou Azure. Tato technika umožňuje zůstat v limitu 30 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 (například sdílené složky SMB nebo NFS), které můžete mít ve složkách místního serveru, které jste teď změnili na společný kořenový adresář. Nic jiného se nezmění.

Důležité

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

Je možné, že ve vaší situaci se sada složek může logicky synchronizovat se stejnou sdílenou složkou Azure (pomocí společného kořenového přístupu uvedeného výše). Přesto ale může být lepší znovu seskupit složky, aby se synchronizovaly se dvěma sdílenými složkami Azure místo jedné. Tento přístup můžete 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 tak možnost synchronizace se 30 dalšími sdílenými složkami Azure na další server.

Důležité

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

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

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

Skupina synchronizace podporuje pouze jeden koncový bod serveru na registrovaný server.
1) Začněte synchronizací jednoho disku (jeho kořenového svazku) s cílovou sdílenou složkou Azure. Začnete-li s největším diskem nebo svazkem, pomůže to splnit požadavky na úložiště v rámci on-premises řešení. Nakonfigurujte vrstvení cloudu tak, aby vrstvila všechna data do cloudu, abyste mohli uvolnit místo na disku souborového serveru. Přesuňte data z jiných svazků nebo sdílených složek do aktuálního svazku, který se synchronizuje. Pokračujte krok za krokem, dokud nebudou všechna data přesunuta 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 opakujte proces. Mějte na paměti, že možná budete muset agenta přeinstalovat.
3) Doporučujeme použít více cílových sdílených složek Azure (stejný nebo jiný účet úložiště na základě požadavků na výkon).
Souborový server s jedním svazkem a více sdílenými složkami do stejné cílové sdílené složky Azure (konsolidace) Ano Nemůžete mít více koncových bodů serveru pro každý zaregistrovaný server, které synchronizují se stejnou cílovou sdílenou složkou Azure (podobně jako v předchozím scénáři). Synchronizujte kořen svazku, který obsahuje více sdílených složek nebo složek nejvyšší úrovně.
Souborový server s více sdílenými složkami nebo svazky do více sdílených složek Azure v rámci jednoho účtu úložiště (mapování sdílených složek 1:1) Ano Jedna instance Windows Serveru (nebo cluster) může synchronizovat až 30 sdílených složek Azure.

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

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

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

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

Vytvořte tabulku mapování

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

Vytvořte tabulku, která zaznamenává vaše myšlenky, abyste na ni mohli odkazovat, když potřebujete. Udržování přehledu je důležité, protože ztráta podrobností o plánu mapování může probíhat snadno, když zřizujete mnoho prostředků Azure najednou.

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.exe, služba windows na pozadí, která zodpovídá za monitorování změn na koncových bodech serveru a inicializování synchronizačních relací
  • StorageSync.sys, filtr systému souborů, který umožňuje úrovňové ukládání dat v cloudu a rychlou obnovu systému po havárii

Požadavky na operační systém

Synchronizace souborů Azure podporuje následující verze Windows Server:

Verze Verze RTM Podporované edice Podporované možnosti nasazení
Windows Server 2025 26100 Azure, Datacenter, Essentials, Standard a IoT Plná a základní
Windows Server 2022 20348 Azure, Datacenter, Essentials, Standard a IoT Plná a základní
Windows Server 2019 17763 Datacenter, Essentials, Standard a IoT Plná a základní
Windows Server 2016 14393 Datacenter, Essentials, Standard a Skladový Server Plná a základní

Udržujte 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í, se všemi těmito atributy:

  • Alespoň jeden procesor.
  • Minimálně 2 GiB paměti. Pokud server běží na virtuálním počítači s povolenou dynamickou pamětí Hyper-V, nakonfigurujte virtuální počítač minimálně s 2 048 MiB paměti.
  • Místně připojený svazek formátovaný systémem souborů NTFS.

U většiny produkčních úloh nekonfigurujte synchronizační server v Synchronizace souborů Azure pouze s minimálními požadavky.

Stejně jako u jakékoli funkce serveru nebo aplikace určuje měřítko nasazení požadavky na systémové prostředky pro Synchronizace souborů Azure. Větší nasazení na serveru vyžadují větší systémové prostředky.

U Synchronizace souborů Azure určuje škálování počet objektů napříč koncovými body serveru a míra změn datové sady. Jeden server může mít koncové body serveru ve více skupinách synchronizace. Počet objektů uvedených v následující tabulce představuje úplný 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ů. Pro toto nasazení potřebujete 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. Kvůli této konfiguraci vyžadují větší obory názvů více paměti, aby se zachoval dobrý výkon. Více churn vyžaduje více procesorů k zpracování.

Následující tabulka obsahuje velikost prostoru názvů i převod na kapacitu pro typické sdílené úložiště pro běžné účely, kde průměrná velikost souboru je 512 KiB. Pokud jsou vaše soubory menší, zvažte přidání další paměti pro stejnou kapacitu. Konfiguraci paměti založte na velikosti oboru názvů.

Velikost jmenného prostoru – soubory a adresáře (miliony) 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 měkký limit na základě 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 prostoru názvů je náročná operace. Přidělit více paměti, dokud nebude dokončena počáteční synchronizace. Tento přístup není nutný, ale může urychlit počáteční synchronizaci.

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

Poznámka:

Agent Synchronizace souborů Azure vyžaduje na Windows Server .NET Framework 4.7.2 nebo novější. Windows Server 2019 a pozdější mají ve výchozím nastavení .NET Framework 4.7.2. U Windows Server 2016 si ověřte, že je nainstalován .NET Framework 4.7.2 nebo novší, než nainstalujete Synchronizace souborů Azure.

Vyhodnocovací cmdlet

Před nasazením Synchronizace souborů Azure vyhodnoťte, jestli je kompatibilní s vaším 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) funkcí uvedených v tomto článku. Pokud chcete zajistit, aby nasazení proběhlo hladce, projděte si zbytek této části.

Zkušební rutinu můžete nainstalovat tak, že nejprve nainstalujete modul Az PowerShell. Pokyny najdete v tématu Instalace Azure PowerShellu.

Využití

Vyvoláte nástroj pro vyhodnocení, který provede kontroly systému, kontroly datových sad nebo obojí. Provádění systémových kontrol i kontrol datových sad:

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ů v souboru .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římo připojené úložiště (DAS) na Windows Serveru znamená, že operační systém Windows Server vlastní systém souborů. Das můžete poskytnout tím, že fyzicky připojíte disky k souborovém serveru, připojíte virtuální disky k virtuálnímu počítači souborového serveru (například virtuální počítač hostovaný Hyper-V) nebo dokonce pomocí iSCSI.

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

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

Funkce Stav podpory Poznámky
Seznamy řízení přístupu (ACL) Plně podporovaná Synchronizace souborů Azure zachovává diskrétní seznamy řízení přístupu (ACL) ve stylu Windows. Windows Server vynucuje tyto seznamy ACL na koncových bodech serveru. Seznamy ACL můžete vynutit také při přímém montování sdílené složky Azure, ale tato metoda vyžaduje další konfiguraci. Další informace najdete v části Identita dále v tomto článku.
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 přeskočí se, pokud je obsahuje obor názvů koncového bodu serveru.
Přípojky Přeskočeno Mezi příklady patří systém souborů DFS (Distributed File System) DfrsrPrivate a DFSRoots složky.
Body rozboru Přeskočeno
Komprese NTFS Částečně podporováno Synchronizace souborů Azure nepodporuje koncové body serveru umístěné na svazku, který komprimuje adresář SVI (System Volume Information).
Zhuštěné soubory Plně podporovaná Řídké soubory se synchronizují (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, které infrastruktura klasifikace souborů vytváří, se nesynchronizují. Stávající značky klasifikace u souborů na jednotlivých koncových bodech serveru nejsou nedotčené.

Komprese NTFS s využitím vrstvení cloudu

Použití komprese NTFS u vrstvených souborů může způsobit významný dopad na výkon. Nepoužívejte vrstvení cloudu s komprimovanými soubory.

Pokud už jsou komprimované soubory vrstvené, musí být po odvolání dat z cloudu nekomprimované spuštěním následujícího příkazu:

Invoke-StorageSyncFileRecall -FilePath <path>
compact /U /S <filepath>

Soubory můžete také rozkomprimovat pomocí příkazu compact .

Na Windows Server 2019 nebo novějším příkaz compact přeskočí vrstvené soubory, takže před zrušením komprimace musíte soubor nejprve odvolat:

Import-Module "C:\Program Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll"
Invoke-StorageSyncFileRecall -FilePath <path>
compact /U /S <filepath>

Pokud načítání souborů vede k problémům s nedostatkem místa na disku, počkejte, až se spustí vrstvení na pozadí a přesune soubor zpět do nižší vrstvy, než začnete načítat další soubory. Případně můžete soubor po dekomprimaci přesunout zpět do vrstvy spuštěním následujícího cmdletu:

Import-Module "C:\Program Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll"
Invoke-StorageSyncCloudTiering -Path <path>

Přeskočeny soubory a složky

Synchronizace souborů Azure přeskočí následující 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 Zamykání souboru databáze Accessu
635D02A9D91C401B97884B82B3BCDAEA.* Interní soubor synchronizace
\System Volume Information Složka specifická pro svazek
$RECYCLE.BIN Složka
\SyncShareState Složka pro synchronizaci
.SystemShareInformation Složka pro synchronizaci v souborovém sdílení Azure

Poznámka:

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

Volné místo na místním disku

Pokud plánujete používat Synchronizace souborů Azure, zvažte, kolik volného místa potřebujete na místním disku pro koncový bod serveru.

U Synchronizace souborů Azure je potřeba vzít v úvahu následující položky, které zabírají místo na místním disku:

  • Když je povolen cloud tiering:

    • 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ý prostor na svazku
  • Při zakázání vrstvení cloudu:

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

Následující příklad ukazuje, jak odhadnout množství volného místa, které potřebujete na místním disku. Předpokládejme, že nainstalujete agenta Synchronizace souborů Azure na virtuální počítač Azure Windows a plánujete vytvořit koncový bod serveru na disku F. Máte 1 milion souborů (a chcete je všechny vrstvit), 100 000 adresářů a velikost diskového clusteru 4 KiB. Velikost disku je 1 000 GiB. Chcete povolit cloudové škálování a nastavit zásady pro volné místo na svazku na 20 %.

  • Ntfs přiděluje velikost clusteru pro každý vrstvený soubor:

    1 milion souborů * 4 KiB velikost clusteru = 4 000 000 KiB (4 GiB)

    Pokud chcete plně využít vrstvení cloudu, použijte menší velikosti clusteru NTFS (menší než 64 KiB), protože každý vrstvený soubor zabírá cluster. Systém souborů NTFS také přiděluje prostor, který vrstvené soubory zabírají. Toto místo se nezobrazuje v žádném uživatelském rozhraní.

  • 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)

  • Synchronizace souborů Azure heatstore zabírá 1,1 KiB na soubor.

    1 milion souborů * 1,1 KiB = 1 100 000 KiB (1,1 GiB)

  • Pravidlo pro volné místo na svazku je 20 %

    1000 GiB * 0,2 = 200 GiB

V tomto případě Synchronizace souborů Azure pro tento obor názvů potřebuje asi 209 500 000 KiB (209,5 GiB). Tuto částku přidejte do libovolného volného místa, které si myslíte, že pro tento disk budete potřebovat.

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

Synchronizace souborů Azure podporuje clustering s podporou převzetí služeb při selhání Windows Serveru pro souborový server pro možnost nasazení 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 souborového serveru se dvěma uzly.

Synchronizace souborů Azure podporuje pouze jeden scénář: cluster Windows Serveru s podporou převzetí služeb při selhání a clusterovanými disky. Clustering s podporou převzetí služeb při selhání není podporován na souborových serverech Scale-Out, sdílených svazcích clusteru nebo místních discích.

Aby synchronizace fungovala správně, musíte agenta Synchronizace souborů Azure nainstalovat na každý uzel v clusteru pro převzetí služeb při selhání.

Odstranění duplicitních dat

Když na svazku se zapnutým vrstvením do cloudu povolíte deduplikaci dat, můžete v místním prostředí uchovávat v mezipaměti více souborů, aniž byste museli zřídit další úložiště. Systém přesouvá soubory optimalizované deduplikací v umístění koncového bodu serveru do vrstev stejně jako běžný soubor na základě nastavení zásad pro cloudové vrstvení. Po vrstvení souborů optimalizovaných pro odstranění duplicitních dat se úloha uvolňování paměti pro odstranění duplicitních dat spustí automaticky. Uvolní místo na disku odebráním nepotřebných bloků dat, na které už ostatní soubory na svazku nebudou odkazovat.

V některých případech, kdy je nainstalována deduplikace dat, se může po spuštění vyčištění nevyužitých dat v rámci deduplikace dostupné místo na svazku zvýšit více, než se očekávalo. Následující příklad popisuje, jak funguje místo na svazku:

  1. Zásady volného prostoru pro vrstvení úložiště v cloudu jsou nastavené na 20%.
  2. Služba Synchronizace souborů Azure je upozorněna, když je málo volného místa (řekněme 19%).
  3. Vrstvení určuje, že je třeba uvolnit o 1 % více místa, ale vy chcete 5 % navíc, takže navýšíte vrstvu až na 25 % (například 30 GiB).
  4. Soubory jsou uspořádány podle úrovní, dokud nedosáhnete 30 GiB.
  5. V rámci interoperability s Deduplikací dat synchronizace souborů Azure zahájí odklízení nepotřebných dat na konci relace vrstvení.

Úspory objemu platí jenom pro server. Vaše data ve sdíleném svazku Azure nejsou deduplikována.

Poznámka:

Windows Server 2025, Windows Server 2022, Windows Server 2019 a Windows Server 2016 podporují deduplikaci dat bez ohledu na to, zda je na jednom nebo více koncových bodech serveru na svazku povoleno nebo zakázáno vrstvení do cloudu. Na Windows Server 2019 nebo Windows Server 2016 musíte nainstalovat aktualizaci Windows KB4520062 – říjen 2019 nebo novější měsíční kumulativní aktualizaci.

Poznámky

  • Pokud před instalací agenta Synchronizace souborů Azure instalujete odstranění duplicitních dat, je potřeba restartovat, aby bylo podporováno odstranění duplicitních dat a vrstvení cloudu na stejném svazku.
  • Pokud povolíte odstranění duplicitních dat na svazku po povolení vrstvení cloudu, počáteční úloha optimalizace odstranění duplicitních dat optimalizuje soubory na svazku, který ještě není vrstvený. Tato úloha má následující dopad na vrstvení cloudu:
    • Zásady volného místa nadále vrství soubory podle volného místa na svazku pomocí heat mapy.
    • Zásada ohledně data vynechává vrstvení souborů, které by mohly být způsobilé pro vrstvení, protože úloha deduplikace má přístup k souborům.
  • U probíhajících úloh optimalizace deduplikace nastavení deduplikace dat MinimumFileAgeDays zpožďuje přesun do cloudové vrstvy podle zásad pro data, pokud soubor ještě není do cloudové vrstvy přesunut.
    • Pokud je například nastavení MinimumFileAgeDays na 7 dní a zásady pro vrstvení dat v cloudu jsou na 30 dní, soubory se budou vrstvit po 37 dnech.
    • Po přesunutí souboru pomocí služby Synchronizace souborů Azure úloha optimalizace deduplikace tento soubor přeskočí.

systém souborů DFS (Distributed File System)

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

DFS-N

Synchronizace souborů Azure plně funguje s implementací DFS-N. Agenta Synchronizace souborů Azure můžete nainstalovat na jeden nebo více souborových serverů a synchronizovat data mezi koncovými body serveru a koncovým bodem cloudu. Potom použijte DFS-N k poskytování služby 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.

DFS-R

Vzhledem k tomu, že DFS-R i Synchronizace souborů Azure jsou řešení replikace, ve většině případů nahraďte DFS-R Synchronizace souborů Azure. V následujících scénářích ale společně používejte DFS-R a Synchronizace souborů Azure:

  • Migrujete z nasazení DFS-R na nasazení Azure Synchronizaci souborů. Další informace najdete v tématu Migrace nasazení 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 konsolidují data do jednoho centrálního serveru, pro který chcete použít Synchronizace souborů Azure.

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

  • U svazků se složkami replikovanými pomocí DFS-R musíte zakázat vrstvení do cloudu služby Synchronizace souborů Azure.
  • Neměli byste konfigurovat koncové body serveru ve složkách replikace DFS-R jen pro čtení.
  • 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. Toto omezení zahrnuje jakoukoli situaci, kdy server po instalaci agenta Synchronizace souborů Azure naklonujete nebo z něj vytvoříte bitovou kopii. Nainstalujte agenta a po nasazení image serveru zaregistrujte server a dokončete miniinstalování nástroje Sysprep.

Pokud povolíte vrstvení cloudu na koncovém bodu serveru, Windows Vyhledávání přeskočí vrstvené soubory a neindexuje je. Windows Search správně indexuje soubory, které nejsou vrstvené.

Klienti Windows při hledání v síťové sdílené složce vyvolávají opakované dotazy, pokud je na klientském počítači povoleno nastavení Vždy prohledávat názvy a obsah souborů. Toto nastavení je ve výchozím nastavení zakázané.

Další řešení HSM

Nepoužívejte žádná jiná hierarchická řešení správy úložiště (HSM) s Synchronizace souborů Azure. Jiná HSM řešení mohou kolidovat s cloudovým tieringem Synchronizace souborů Azure a mohou způsobit nekonzistence dat nebo neočekávané chování.

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, efektivní výkon synchronizace závisí na těchto faktorech ve vaší infrastruktuře:

  • 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
  • Aktivita u datové sady

Synchronizace souborů Azure funguje na úrovni souborů. Změříte charakteristiky výkonu řešení na základě Synchronizace souborů Azure počtem objektů (souborů a adresářů) zpracovaných za sekundu.

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

Identita

Správce, který zaregistruje server a vytvoří koncový bod cloudu, musí být členem role správce synchronizace souborů Azure, vlastníka nebo přispěvatele pro synchronizační službu úložiště. Tuto roli můžete nakonfigurovat v části Řízení přístupu (IAM) na stránce webu Azure Portal pro službu synchronizace úložiště.

Synchronizace souborů Azure také vyžaduje další oprávnění účtu úložiště pro operace vytváření a aktualizace koncového bodu cloudu. Uživatelé, kteří dříve měli oprávnění ke čtení jenom účtu úložiště, už nemůžou vytvářet ani aktualizovat koncové body cloudu.

V případě nasazení nespravované identity musí mít správce roli, která zahrnuje:

  • Microsoft.Storage/storageAccounts/listKeys/action
  • Microsoft. Storage/storageAccounts/ListAccountSas/action

Pro nasazení se spravovanou identitou se ujistěte, že spravovaná identita Synchronizace souborů Azure nebo instanční objekt služby má přiřazené požadované role pro účet úložiště, například Reader and Data Access nebo Storage File Data Privileged Contributor, podle potřeby.

Při přiřazování role správce Synchronizace souborů Azure následujícím postupem zajistíte nejnižší oprávnění pro přiřazení rolí, která Synchronizace souborů Azure vytvoří v účtu úložiště.

  1. Na kartě Podmínky vyberte Povolit uživatelům přiřadit vybrané role pouze vybraným hlavním aktérům s menšími oprávněními.

  2. Klikněte na Vybrat role a uživatele a poté vyberte Přidat akci pod Podmínka č. 1.

  3. Vyberte Vytvořit přiřazení role a klepněte na tlačítko Vybrat.

  4. Vyberte Přidat výraz a pak vyberte Požadavek.

  5. V části Zdroj atributů vyberte ID definice role v části Atribut a pak v části Operátor vyberte ForAnyOfAnyValues:GuidEquals.

  6. Vyberte Přidat role. Přidejte role Čtenář a Přístup k datům, Privilegovaný přispěvatel pro data souboru úložiště, a Přispěvatel účtu úložiště a pak vyberte Uložit.

Synchronizace souborů Azure funguje se standardní identitou založenou na službě služba Active Directory bez jakéhokoli speciálního nastavení nad rámec nastavení synchronizace. Když používáte Synchronizaci souborů Azure, obecně se očekává, že většina přístupů prochází servery ukládání do mezipaměti Synchronizace souborů Azure, nikoli prostřednictvím sdílené složky Azure. Vzhledem k tomu, že koncové body serveru jsou na Windows Serveru a Windows Server podporuje seznamy ACL ve stylu služba Active Directory a Windows, nepotřebujete 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 ukládá seznamy ACL do souborů ve sdílené složce Azure a replikuje tyto seznamy ACL do všech koncových bodů serveru.

I když změny provedené přímo ve sdílené složce Azure trvají delší dobu, než se synchronizují s koncovými body serveru ve skupině synchronizace, můžete také zvážit, zda zajistíte vynucení oprávnění služba Active Directory ke své sdílené složce přímo v prostředí cloudu. Pokud chcete tuto konfiguraci provést, musíte účet úložiště připojit k místní instanci služby Active Directory, stejně jako to, jak jsou vaše souborové servery s Windows připojené k doméně. Další informace o připojení vašeho účtu úložiště k instanci služba Active Directory, kterou vlastní zákazník, najdete v tématu Přehled ověřování identity 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 připojení účtu úložiště k doméně v služba Active Directory. Jedná se o volitelný krok, který umožňuje sdílenému úložišti Azure vynucovat lokální seznamy řízení přístupu (ACL), když uživatelé připojují sdílené úložiště Azure přímo.

Networks

Agent Synchronizace souborů Azure komunikuje se službou synchronizace úložiště a sdílenou složkou Azure pomocí protokolu REST Synchronizace souborů Azure a protokolu FileREST. Oba tyto protokoly vždy používají HTTPS přes port 443. Protokol SMB se nikdy nepoužívá k nahrání nebo stahování dat mezi vaší instancí Windows Serveru 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 Synchronizaci souborů Azure speciální konfiguraci sítě.

Důležité

Synchronizace souborů Azure nepodporuje internetové směrování. Synchronizace souborů Azure podporuje výchozí možnost směrování sítě, 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. Synchronizace souborů Azure poskytuje několik mechanismů konfigurace sítí. Na základě vašich požadavků můžete:

  • Synchronizace tunelu a nahrávání a stahování souborů přes Azure ExpressRoute nebo virtuální privátní síť 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.

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. Tato metoda nabízí VPN s nulovou potřebou konfigurace pro přístup SMB ke sdíleným složkám Azure prostřednictvím QUIC transportního protokolu přes port 443. Ačkoliv Azure Files přímo nepodporuje SMB přes QUIC, můžete vytvořit lehkou cache svých Azure sdílených souborů na Windows Server Datacenter: Azure Edition VM pomocí Synchronizace souborů Azure. Pro více informací o této možnosti navštivte SMB přes QUIC.

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

Důležité

Nezadávejte IP adresu účtu úložiště napevno do souborů hosts, DNS ani do pravidel brány firewall. Během failoveru nebo při migraci účtu do jiného tenanta či regionu se mohou IP adresy Azure Storage Accountu změnit. Neplatná IP adresa naruší připojení, způsobí selhání synchronizace a znemožní načítání souborů. Nechte agenta vyřešit endpoint přes DNS nebo použijte soukromý endpoint s jeho privátní DNS zónou, pokud potřebujete soukromé směrování.

Šifrování

Synchronizace souborů Azure nabízí tři vrstvy šifrování: šifrování v neaktivním úložišti Windows Serveru, šifrování přenášeného mezi agentem Synchronizace souborů Azure a Azure a šifrování neaktivních uložených dat ve sdílené složce Azure.

Šifrování dat v klidu Windows Serveru

Při synchronizaci souborů Azure obecně fungují dvě strategie šifrování dat na Windows Serveru:

  • Šifrování pod systémem souborů, aby systém souborů a všechna data zapsaná do systému souborů byly zašifrovány.
  • Šifrování v samotném formátu souboru

Tyto metody se vzájemně nevylučují. Můžete se rozhodnout, že je budete používat společně, protože účelem šifrování je jiné.

K zajištění šifrování na úrovni nižší než systém souborů poskytuje Windows Server funkci BitLocker. Nástroj BitLocker je pro Synchronizaci souborů Azure plně transparentní. Hlavními důvody použití šifrovacího mechanismu, jako je BitLocker, jsou:

  • Zabránit fyzickému exfiltraci dat z místního datacentra tím, že někdo ukradne disky
  • Zabraňte načtení neoprávněného OS z neoficiálního zdroje k provádění neoprávněného čtení a zápisu do vašich dat

Další informace najdete v přehledu nástroje BitLocker.

Partnerské produkty, které fungují podobně jako BitLocker, v tom, že leží pod svazkem NTFS, by měly plně a transparentně fungovat 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 můžou tuto úlohu provádět nativně, ale obvykle ne.

Ukázkové metody šifrování datového proudu souboru jsou Azure Information Protection, Azure Rights Management (Azure RMS) a služba Active Directory Rights Management Services. Primárním důvodem použití mechanismu šifrování, jako je Azure Information Protection nebo Azure RMS, je zabránit exfiltraci dat ze sdílené složky lidmi, kteří je zkopírují do alternativních umístění (jako je flash disk) nebo je pošlete 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 ani partnerskými šifrovacími řešeními, která se nacházejí nad systémem souborů, ale pod datovým proudem souboru.

Šifrování během přenosu

Agent Synchronizace souborů Azure komunikuje se službou synchronizace úložiště a sdílenou složkou Azure pomocí protokolu REST Synchronizace souborů Azure a protokolu FileREST. Oba tyto protokoly 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. Tento přepínač je ve výchozím nastavení povolený. I když je přepínač na úrovni účtu úložiště zakázaný a jsou možná nešifrovaná připojení k vašim sdíleným složkám Azure, Synchronizace souborů Azure stále pro přístup ke sdílené složce používá 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á komunikuje přímo se sdílenou složkou Azure. Taková aplikace musí být spuštěná ve starším operačním systému, jako je Windows Server 2008 R2 nebo starší linuxová distribuce. Pokud se starší verze aplikace připojí k mezipaměti windows Serveru sdílené složky, změna tohoto nastavení nemá žádný vliv.

Povolte šifrování přenášených dat. Další informace o šifrování během přenosu najdete v tématu Vyžadovat zabezpečený přenos, aby se zajistila zabezpečená připojení.

Poznámka:

Služba Synchronizace souborů Azure odebrala podporu protokolu TLS 1.0 a 1.1 1. srpna 2020. Všechny podporované verze agenta Synchronizace souborů Azure už ve výchozím nastavení používají protokol TLS 1.2. Pokud jste na serveru zakázali protokol TLS 1.2 nebo používáte proxy server, možná používáte starší verzi protokolu TLS.

Pokud používáte proxy server, zkontrolujte konfiguraci proxy serveru. Oblasti služby Synchronizace souborů Azure přidané po 1. květnu 2020 podporují pouze protokol TLS 1.2. Další informace najdete v průvodci odstraňováním potíží.

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

Azure Files používá stejné schéma šifrování jako ostatní služby úložiště Azure, například Azure Blob Storage. Všechna data uložená v Azure Files se šifrují v klidovém stavu prostřednictvím šifrování na straně služby (SSE), která funguje podobně jako BitLocker na Windows.

Vzhledem k tomu, že data se šifrují pod systémem souborů sdílené složky Azure, protože jsou zakódovaná na disk, nepotřebujete přístup k základnímu klíči v klientovi pro čtení nebo zápis 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 pro šifrování a dešifrování dat. Microsoft zodpovídá za pravidelné obměně těchto klíčů.

U Azure klasických sdílených složek můžete data zašifrovat pomocí klíčů spravovaných zákazníkem. Pokud zvolíte klíče spravované zákazníkem, Azure Files má oprávnění přistupovat k vašim klíčům za účelem splnění požadavků na čtení a zápis od vašich klientů. Pomocí klíčů spravovaných zákazníkem můžete tuto autorizaci kdykoli odvolat. Bez této autorizace už ale vaše sdílená složka Azure není přístupná přes protokol SMB ani rozhraní FileREST API.

Úrovně úložiště

Azure Files nabízí dvě úrovně úložiště médií: disk SSD (Solid-State Disk) a pevný disk (HDD). Tyto úrovně umožňují přizpůsobit sdílené složky vašim požadavkům 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 můžete používat s protokoly SMB i NFS. Sdílené složky SSD jsou k dispozici ve zřízených modelech fakturace verze 2 a zřízených modelech fakturace verze 1. Sdílené složky SSD nabízejí smlouvu SLA s vyšší dostupností než sdílené složky HDD.

  • 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 k dispozici se zřízenými modely fakturace v2 a průběžnými platbami , i když pro nová nasazení sdílených složek doporučujeme zřízený model verze 2. Informace o této sla najdete na stránce Azure SLA pro online služby.

Když pro úlohu vybíráte vrstvu médií, 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á, může být sdílené úložiště HDD vhodnější z hlediska nákladů. Například nízká latence může být menším problémem u týmových sdílených jednotek připojených místně na místě z Azure nebo uložených v mezipaměti na místě prostřednictvím Synchronizace souborů Azure.

Když 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.

Další informace o úrovních médií SSD a HDD najdete v tématu Vysvětlení fakturačních modelů služby Azure Filesa vysvětlení a optimalizace výkonu sdílených složek Azure.

dostupnost synchronizace souborů Azure v oblasti

Informace o regionální dostupnosti najdete v tématu Dostupnost produktů podle oblastí 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 článku.

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 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. Tento přístup pomáhá chránit 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 datacentru, můžou být ztraceny nebo neobnovitelné všechny repliky účtu úložiště, který používá LRS.

  • 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 zónách dostupnosti Azure. Zóny dostupnosti jsou jedinečná fyzická umístění v oblasti Azure. Každá zóna se skládá z jednoho nebo více datacenter 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 primární oblast a sekundární oblast. Soubory se ukládají třikrát v 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ému výpadku regionu Azure kvůli přírodní katastrofě nebo jiné podobné události, Microsoft provede failover. V tomto případě se sekundární stane primárním a 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é katastrofě, 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í geografické zóny 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 redundanci geografických zón funguje stejně jako u geografické redundance.

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

Účty úložiště s průběžnou platbou poskytují dvě další možnosti redundance, které služba Azure Files nepodporuje: geograficky redundantní úložiště s přístupem pro čtení (RA-GRS) a geograficky zónově redundantní úložiště s přístupem pro č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 RA-GRS nebo RA-GZRS účtů úložiště se účtují jako geograficky redundantní nebo geograficky zónově redundantní.

Důležité

Geograficky redundantní a geograficky zónově redundantní úložiště může ručně převést úložiště na sekundární oblast. Tento přístup (mimo havárii) nepoužívejte, pokud používáte Synchronizace souborů Azure kvůli zvýšené pravděpodobnosti ztráty dat. Pokud dojde k havárii a chcete zahájit ruční převzetí úložiště po selhání, musíte otevřít případ podpory s Microsoftem, aby Synchronizace souborů Azure mohla pokračovat v synchronizaci se sekundárním koncovým bodem.

Migrace

Pokud máte existující souborový server v Windows Server 2016 nebo novějším, můžete přímo nainstalovat Synchronizace souborů Azure. Data nemusíte přesouvat na nový server.

Pokud plánujete migrovat na nový souborový server s Windows jako součást přechodu na Synchronizaci souborů Azure nebo pokud se vaše data aktuálně nacházejí na serveru NAS, existuje několik možných přístupů k migraci pro použití Synchronizace souborů Azure s daty. 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 tématu Migrace do sdílených složek Azure SMB.

Antivirový program

Vzhledem k tomu, že antivirový software funguje vyhledáváním souborů se známým škodlivým kódem, antivirový produkt může způsobit odvolání vrstvených souborů a vysoké poplatky za výchozí přenos dat. Vrstvené soubory mají nastavenou zabezpečenou sadu atributů FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS Systému Windows. Obraťte se na dodavatele softwaru a zjistěte, jak nakonfigurovat jeho řešení tak, aby přeskočila čtení souborů, které mají tuto sadu atributů. Mnoho dodavatelů to zpracovává automaticky.

Během kontrol na vyžádání antivirová řešení Microsoft Defender a System Center Endpoint Protection automaticky přeskočí čtení souborů, které mají tento atribut nastavený. 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 odvolají (stáhnou) na novém serveru. Tyto soubory zůstanou na novém serveru a nejsou vrstvené, protože nevyhovují požadavkům na velikost vrstvení (více než 64 KiB).

Poznámka:

Microsoft Defender a System Center Endpoint Protection přeskočí čtení jenom během kontrol na vyžádání. Toto pravidlo se nevztahuje na ochranu v reálném čase (RTP).

Dodavatelé antivirové ochrany můžou zkontrolovat kompatibilitu mezi svými produkty a Synchronizací souborů Azure pomocí Sady testů kompatibility antivirové ochrany synchronizace souborů v centru Microsoft Download Center.

Backup

Pokud povolíte vrstvení cloudu, nepoužívejte řešení, která přímo zálohují koncový bod serveru nebo virtuální počítač, který obsahuje koncový bod serveru.

Vrstvení cloudu způsobí, že se v koncovém bodu serveru uloží jenom podmnožina vašich dat. Úplná datová sada se nachází ve sdílené složce Azure. V závislosti na použitém řešení zálohování jsou vrstvené soubory:

  • Jsou vynechány a nezazálohovány, protože mají atribut FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS nastavený.
  • Načítání z disku, což vede k vysokým poplatkům za odchozí přenos dat.

Pomocí řešení cloudového zálohování můžete zálohovat sdílenou složku Azure přímo. Další informace viz O zálohování Azure Files. Nebo se zeptejte svého zprostředkovatele zálohování, jestli podporuje zálohování sdílených složek Azure.

Pokud raději používáte místní řešení zálohování, proveďte zálohy na serveru ve skupině synchronizace, která má zakázané vrstvení cloudu. Ujistěte se, že neexistují žádné vrstvené soubory.

Při obnovení použijte možnost obnovení na úrovni svazku nebo na úrovni souboru. Soubory obnovené prostřednictvím možnosti obnovení na úrovni souboru se synchronizují se všemi koncovými body ve skupině synchronizace. Existují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:

Úplné obnovení, 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í může způsobit neočekávané výsledky. (Obnovení na úrovni souboru probíhá, když záložní software zálohuje vrstvený soubor místo úplného souboru.) V současné době se nepodporují, když je povolené vrstvení cloudu.

Snímky služby Stínová kopie svazku (VSS), včetně karty Předchozí verze, jsou podporovány u svazků, které mají povolené vrstvení cloudu. Musíte však povolit kompatibilitu s předchozí verzí prostřednictvím PowerShellu. Zjistěte, jak na to.

Klasifikace dat

Pokud instalujete software pro klasifikaci dat, povolení vrstvení cloudu zvyšuje náklady ze dvou důvodů:

  • Při povoleném vrstvení cloudu jsou vaše nejčastěji používané soubory k dispozici v mezipaměti místně. Vaše méně často přistupované soubory jsou přesunuty do cloudového úložiště Azure. Pokud vaše klasifikace dat pravidelně prohledává všechny soubory ve sdílené složce, musí být soubory uložené do cloudu vyžádány zpět pokaždé, když jsou kontrolovány.
  • Pokud software pro klasifikaci dat používá metadata v datovém proudu souboru, musí být soubor úplně stažen, aby software detekoval klasifikaci.

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

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. Například: 18.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.

Aktualizace cest

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

  • K instalaci aktualizací agenta použijte funkci automatické aktualizace Synchronizace souborů Azure: Agent Synchronizace souborů Azure se automaticky aktualizuje. Nejnovější verzi agenta můžete nainstalovat, když je dostupná, nebo aktualizovat, když je aktuálně nainstalovaný agent blízko vypršení platnosti. Další informace najdete v další části Automatická správa životního cyklu agenta.
  • Nakonfigurujte službu Microsoft Update tak, aby automaticky stahovala a instalovala aktualizace agenta: Doporučujeme nainstalovat všechny aktualizace 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.
  • Ke stažení a instalaci aktualizací agenta použijte AfsUpdater.exe: Soubor 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.
  • 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 si můžete stáhnout z katalogu služby Microsoft Update. Spuštění spustitelného souboru .msp aktualizuje instalaci Synchronizace souborů Azure stejnou metodou, jakou Microsoft Update používá automaticky. Instalace opravy služby Microsoft Update provádí místní aktualizaci instalace Synchronizace souborů Azure.
  • Stáhněte si nejnovější instalační program agenta Synchronizace souborů Azure: Instalační program můžete získat na webu Microsoft Download Center. Pokud chcete aktualizovat 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 (například registrace serveru a koncové body serveru) se udržuje při odinstalaci agenta Synchronizace souborů Azure.

Poznámka:

Downgrade agenta Synchronizace souborů Azure není podporován. Nové verze často obsahují zásadní změny, když se porovnávají se starými verzemi, takže proces downgradu není podporovaný. Pokud narazíte na problémy s aktuální verzí agenta, obraťte se na podporu nebo aktualizaci na nejnovější dostupnou verzi.

Automatická správa životního cyklu agenta

Agent Synchronizace souborů Azure se aktualizuje automaticky. Můžete vybrat některý z následujících režimů a zadat časové období údržby, ve kterém se aktualizace 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 mantinely, které brání vypršení platnosti agenta, nebo umožňuje bezproblémové a aktuální nastavení.

  • Výchozí nastavení se pokusí zabránit vypršení platnosti agenta. Do 21 dnů po datu vypršení platnosti agenta se agent pokusí provést samostatnou aktualizaci. Spustí pokus o aktualizaci jednou týdně do 21 dnů před vypršením platnosti a ve vybraném časovém období údržby. Mějte na paměti, že tato možnost neeliminuje potřebu provádět pravidelné záplaty služby Microsoft Update.

  • Můžete vybrat, že se agent automaticky aktualizuje, jakmile bude k dispozici nová verze agenta. Tato možnost se v současné době 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 doporučené, bezproblémové nastavení poskytuje hlavní verze agenta a pravidelné aktualizační opravy na váš server. Každý vydaný agent je v kvalitě GA.

    Pokud vyberete tuto možnost, Microsoft vám nasadí nejnovější verzi agenta. Clusterované servery jsou vyloučené. Po dokončení testovací verze bude agent také k dispozici ve službě Microsoft Update a na webu Microsoft Download Center.

Změna nastavení automatické aktualizace

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í tato akce vypadá přibližně jako v následujícím příkladu:

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ž je nasazení dokončeno pro nejnovější verzi agenta a zásada automatické aktualizace agenta se změní na hodnotu InstallLatest, agent se automaticky neaktualizuje, dokud není nasazena další verze agenta. Pokud chcete aktualizovat verzi agenta, která dokončila testovací verzi, použijte službu Microsoft Update nebo AfsUpdater.exe. Pokud chcete zkontrolovat, jestli je verze agenta aktuálně v testovací fázi, zkontrolujte část Podporované verze v poznámkách k vydání.

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í. Konkrétní verzi agenta Synchronizace souborů Azure je možné podporovat pouze po omezenou dobu. Abyste usnadnili nasazení, následující pravidla zaručují, že máte dostatek času a oznámení pro přizpůsobení aktualizací 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í.
  • Mezi podporou hlavních verzí agentů se překrývají aspoň 3 měsíce.
  • Upozornění se vydávají pro registrované servery prostřednictvím agenta, kterému brzy vyprší platnost, nejméně 3 měsíce před vypršením platnosti. V části o registrovaných serverech v synchronizační službě úložiště můžete zkontrolovat, jestli zaregistrovaný server používá starší verzi agenta.
  • Životnost dílčí verze agenta je vázána na přidruženou hlavní verzi. Pokud je například stanoveno, že agent verze 18.0.0.0 má vypršet platnost, vyprší platnost agentů verze 18.*.*.* společně.

Poznámka:

Instalace agenta s prošlou verzí zobrazí upozornění, ale proběhne úspěšně. Pokus o instalaci nebo připojení s verzí agenta s vypršenou platností není podporovaný a je zablokovaný.