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

Soubory budou uloženy v cloudu ve sdílených složkách Azure. Sdílené složky Azure můžete použít dvěma způsoby: přímým připojením těchto sdílených složek Azure (SMB) bez serveru nebo ukládáním do mezipaměti sdílených složek Azure v místním prostředí pomocí Synchronizace souborů Azure. Zvolená volba nasazení 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 soubory azure poskytují přístup přes protokol smb, můžete sdílené složky Azure připojit místně nebo v cloudu pomocí standardního klienta SMB, který je dostupný v Windows, macOS a Linux. Vzhledem k tomu, že sdílené složky Azure jsou bez serveru, nasazení pro produkční scénáře nevyžaduje správu souborového serveru nebo zařízení NAS. To znamená, že nemusíte instalovat softwarové opravy ani odpínat fyzické disky.

• Ukládání sdílené složky Azure do mezipaměti v místním prostředí pomocí synchronizace souborů Azure: synchronizace souborů Azure umožňuje centralizovat sdílené složky ve vaší organizaci ve službě soubory Azure a zachovat tak flexibilitu, výkon a kompatibilitu místního souborového serveru. Synchronizace souborů Azure transformuje místní (nebo cloudové) Windows Server na rychlou mezipaměť 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 cloudová sdílená složka bez serveru, která poskytuje koncový bod cloudu relace synchronizace souborů Azure Sync. k souborům ve sdílené složce Azure se dá získat přímý přístup pomocí protokolu SMB nebo protokolu rest, ale doporučujeme, abyste k souborům v mezipaměti serveru Windows v případě, že sdílená složka Azure používáte s Synchronizace souborů Azure, nedoporučujeme přistupovat primárně. důvodem je to, že Azure Files dnes chybí účinný mechanismus pro detekci změn, jako je Windows Server má, takže změny ve sdílené složce Azure budou trvat déle, než se rozšíří zpátky do koncových bodů serveru.
• koncový bod serveru: cesta na serveru Windows, která se synchronizuje do sdílené složky Azure. Může se jednat o konkrétní složku na svazku nebo na kořen svazku. Pokud se jejich obory názvů nepřekrývají, můžou existovat na stejném svazku více koncových bodů serveru.
• Skupina synchronizace: objekt definující relaci 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řte dvě skupiny synchronizace a přidejte do každé skupiny synchronizace různé koncové body.

Koncepty správy Azure File Share

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ě se dá použít k nasazení několika sdílených složek a dalších prostředků úložiště, jako jsou kontejnery objektů blob, fronty nebo tabulky. Všechny prostředky úložiště, které jsou nasazené do účtu úložiště, sdílejí omezení vztahující se na tento účet úložiště. Omezení pro aktuální účet úložiště najdete v tématu škálovatelnost a cíle výkonnosti souborů Azure.

Existují dva hlavní typy účtů úložiště, které budete používat pro nasazení souborů Azure:

• Úč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 a na pevných discích (HDD). Kromě ukládání sdílených složek Azure můžou účty úložiště GPv2 ukládat i další prostředky úložiště, jako jsou kontejnery objektů blob, fronty nebo tabulky.
• Účty úložiště úložiště: účty úložiště úložiště umožňují nasadit sdílené složky Azure na hardware Premium/Solid-State (SSD) na disku (SSD). Účty úložiště souborů se dají použít jenom k ukládání sdílených složek Azure. v účtu úložiště úložiště se nedají nasadit žádné další prostředky úložiště (kontejnery objektů blob, fronty, tabulky atd.). Sdílené složky SMB i NFS můžou nasadit jenom účty úložiště souborů.

V Azure Portal, PowerShellu nebo rozhraní příkazového řádku se může nacházet několik dalších typů účtů úložiště. Dva typy účtů úložiště, účty úložiště BlockBlobStorage a BlobStorage, nemůžou obsahovat sdílené složky Azure. Další dva typy účtů úložiště, které se můžou zobrazovat, 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 Classic můžou obsahovat sdílené složky Azure, jsou většina nových funkcí služby Azure Files k dispozici pouze v účtech úložiště GPv2 a úložiště souborů. Proto doporučujeme, abyste pro nová nasazení používali jenom účty úložiště GPv2 a Storage a k upgradu GPv1 a klasických účtů úložiště, pokud už ve svém prostředí existují.

Koncepty správy Synchronizace souborů Azure

skupiny synchronizace se nasazují do služby Storage Sync, což jsou objekty nejvyšší úrovně, které registrují servery pro použití s Synchronizace souborů Azure a které obsahují vztahy skupiny synchronizace. prostředek služby Storage Sync je partnerským uzlem prostředku účtu úložiště a je možné ho podobně nasadit do skupin prostředků Azure. služba Storage sync může vytvořit skupiny synchronizace, které obsahují sdílené složky Azure v rámci více účtů úložiště a více registrovaných Windowsch serverů.

než budete moct vytvořit skupinu synchronizace ve službě Storage sync, musíte nejdřív zaregistrovat Windows Server se službou Storage sync. tím se vytvoří registrovaný objekt serveru , který představuje vztah důvěryhodnosti mezi serverem nebo clusterem a službou Storage Sync. pokud chcete zaregistrovat službu Storage Sync, musíte nejdřív na server nainstalovat agenta Synchronizace souborů Azure. v jednom okamžiku se dá registrovat jednotlivé servery nebo clustery jenom s jednou službou Storage Sync.

Skupina synchronizace obsahuje jeden koncový bod cloudu nebo sdílenou složku Azure a nejméně jeden koncový bod serveru. Objekt koncového bodu serveru obsahuje nastavení, která konfigurují schopnost vrstvení cloudu , která poskytuje možnosti 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 Storage sync.

vezměte v úvahu počet potřebných služeb Storage Sync.

předchozí část popisuje základní prostředek, který se má nakonfigurovat pro Synchronizace souborů Azure: Storage synchronizace služby. Windows Server lze registrovat pouze do jedné služby Storage Sync. proto je často nejlepší nasadit jenom jednu službu synchronizace Storage a zaregistrovat všechny servery, na kterých se jedná.

můžete vytvořit několik služeb Storage Sync pouze v případě, že máte tyto služby:

• různé sady serverů, které nesmí vzájemně vyměňovat data. v takovém případě budete chtít navrhnout systém tak, aby vyloučil některé 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ě Storage sync. dalším způsobem, jak to sledovat, je to, že Windows servery zaregistrované do jiné služby synchronizace úložiště se nedají synchronizovat se stejnou sdílenou složkou Azure.
• musí mít více zaregistrovaných serverů nebo skupin synchronizace, než je jediná služba Storage sync může podporovat. Další podrobnosti najdete v části cíle synchronizace souborů Azure škálování .

Plánování topologií s vyváženou synchronizací

Než začnete s nasazením jakýchkoli prostředků, je důležité naplánovat, co budete synchronizovat na místním serveru, se kterou sdílenou složkou Azure. Naplánování vám pomůže určit, kolik účtů úložiště, sdílených složek Azure a prostředků synchronizace budete potřebovat. tyto požadavky jsou stále relevantní, i když vaše data aktuálně nejsou uložená na Windowsm serveru nebo na serveru, který chcete použít dlouhodobě. Oddíl Migration (migrace ) vám pomůže určit vhodné cesty migrace pro vaši situaci.

V tomto kroku zjistí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 s uživateli a aplikacemi. Nejjednodušším způsobem, jak si tento scénář představit, je představit si místní sdílení, které mapuje 1:1 na sdílené složky Azure. Pokud máte dostatečný malý počet sdílených složek pod 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ílené složky Azure je často zbytečné. Zvažte následující možnosti.

Seskupování sdílení

Pokud má například vaše oddělení lidských zdrojů 15 sdílených složek, můžete zvážit uložení všech dat o lidských zdrojích do jedné sdílené složky Azure. Uložením více místních sdílených složek do jedné sdílené složky Azure nezabráníte vytvoření obvyklých 15 sdílených složek SMB v místní instanci Windows Serveru. Znamená to jenom, že kořenové složky z těchto 15 sdílených složek uspořádáte jako podsložky ve společné složce. Potom tuto běžnou složku synchronizujte do sdílené složky Azure. Tímto způsobem je pro tuto skupinu místních sdílených složek potřeba jenom jedna sdílená složky Azure v cloudu.

Synchronizace svazků

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

Synchronizace kořenového adresáře svazku není vždy nejlepší možností. Synchronizace více umístění přináší výhody. To například pomůže snížit počet položek na obor synchronizace. Sdílené složky Azure a sdílené složky Synchronizace souborů Azure 100 milionů položek (souborů a složek) na jednu složku. Osvědčeným postupem je ale zkusit zachovat číslo nižší než 20 000 000 nebo 30 000 000 v jedné sdílené složce. Nastavení Synchronizace souborů Azure s menším počtem položek není pro synchronizaci souborů výhodné. Nižší počet položek také přináší podobné scénáře:

• Počáteční prohledávání cloudového obsahu může být rychlejší, což zase zkracuje čekání na zobrazení oboru názvů na serveru povoleném pro 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 se může významně zrychlit.
• Změny provedené přímo ve sdílené složce Azure (mimo synchronizaci) se dají detekovat a synchronizovat rychleji.

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 soubory Azure. Toto mapování bude informovat o počtu a které Synchronizace souborů Azure synchronizaci prostředků skupiny , které se budou zřizovat. Skupina synchronizace přiřazuje sdílenou složku Azure a složku na serveru společně a naváže připojení synchronizace.

Pokud chcete rozhodnout, kolik sdílených složek Azure potřebujete, prostudujte si následující omezení a osvědčené postupy. To vám pomůže optimalizovat mapu.

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

• Sdílená složka Azure je nasazená v účtu úložiště. Toto uspořádání vytváří účet úložiště jako cíl škálování pro čísla výkonu, jako jsou IOPS a propustnost.

  Jedna standardní sdílená složka Azure může teoreticky zvýšit maximální výkon, který může účet úložiště doručovat. Pokud v jednom účtu úložiště umístíte víc sdílených složek, vytváříte sdílený fond IOPS a propustnost pro tyto sdílené složky. Pokud máte v úmyslu k těmto sdíleným složkám připojit jenom Synchronizace souborů Azure, nevytvoří se v seskupení několika sdílených složek Azure do stejného účtu úložiště problém. Pokud chcete získat podrobnější přehled o relevantních metrikách, zkontrolujte výkonnostní cíle sdílené složky Azure. Tato omezení se nevztahují na premium storage, kde je výkon explicitně zřízen a zaručen pro každou sdílené složky.

  Pokud máte v plánu migovat aplikaci do Azure, která bude nativně používat sdílené složky Azure, možná budete potřebovat vyšší výkon sdílené složky Azure. Pokud je tento typ použití možný, i v budoucnu je nejlepší vytvořit jednu standardní sdílené složky Azure ve vlastním účtu úložiště.

• Pro každou oblast Azure platí limit 250 účtů úložiště na předplatné.

Osvědčeným postupem je udržovat nízký počet položek na obor synchronizace. To je důležitý faktor, který je třeba vzít v úvahu při mapování složek na sdílené složky Azure. Synchronizace souborů Azure testuje se 100 miliony položek (souborů a složek) na jednu složku. Často je ale nejlepší zachovat v jedné akcii počet položek pod 20 milionů nebo 30 milionů. Pokud začnete tato čísla překročit, rozdělte obor názvů do několika sdílených složek. Pokud zůstanete přibližně pod těmito čísly, můžete i nadále seskupovat více 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 může sada složek logicky synchronizovat se stejnou sdílenou složkou Azure (pomocí nového přístupu ke společné kořenové složce zmíněného dříve). Stále ale může být lepší znovu seskupit složky, aby se synchronizovaly se dvěma místo jedné sdílené složky Azure. Tento přístup můžete použít k udržení počtu souborů a složek na sdílení souborů napříč serverem. Můžete také rozdělit místní sdílené složky a synchronizovat je na další místní servery a přidat možnost synchronizace s více než 30 dalšími sdílenými složkami Azure na dalších serverech.

Vytvoření tabulky mapování

Pomocí předchozích informací zjistíte, kolik sdílených složek Azure potřebujete a které části vašich stávajících dat budou mít za následek to, ve které sdílené složce Azure.

Vytvořte tabulku, která bude zaznamená vaše myšlenky, abyste na ni mohli odkazovat, až budete potřebovat. Uspořádání je důležité, protože při zřizování mnoha prostředků Azure v jednom okamžiku může být snadné přijít na podrobnosti o plánu mapování. Stáhněte si následující excelový soubor, který použijete jako šablonu, abyste mohli vytvořit mapování.

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

pokyny pro Windows souborového serveru

chcete-li povolit funkci synchronizace na serveru Windows, je nutné nainstalovat Synchronizace souborů Azure agenta ke stažení. agent Synchronizace souborů Azure poskytuje dvě hlavní součásti: FileSyncSvc.exe , službu na pozadí Windows, která zodpovídá za sledování změn v koncových bodech serveru a zahájení relací synchronizace, a StorageSync.sys filtr systému souborů, který umožňuje tvorbu vrstev 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:

budoucí verze Windows serveru budou přidány při jejich vydání.

Minimální systémové prostředky

Synchronizace souborů Azure vyžaduje server (fyzický nebo virtuální) s minimálně jedním PROCESORem a minimálně 2 GiB paměti.

Pro většinu produkčních úloh nedoporučujeme konfigurovat Synchronizace souborů Azure Sync Server jenom s minimálními požadavky. Další informace najdete v tématu Doporučené systémové prostředky .

Doporučené systémové prostředky

Stejně jako u jakékoli serverové funkce nebo aplikace se požadavky na systémové prostředky pro Synchronizace souborů Azure určují v rozsahu nasazení. větší nasazení na serveru vyžaduje větší systémové prostředky. Pro Synchronizace souborů Azure se škála určuje podle počtu objektů v koncových bodech serveru a změn 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ích tabulkách účtů pro úplný obor názvů, ke kterému je server připojený.

Například koncový bod serveru A s 10 000 000 objekty a koncovým bodem serveru B s 10 000 000 objekty = 20 000 000 objekty. Pro tento příklad nasazení doporučujeme, abyste 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ů jsou ukládána v paměti z důvodů výkonu. Vzhledem k tomu, že větší obory názvů vyžadují více paměti, aby bylo možné udržet dobrý výkon a více změn vyžaduje více PROCESORů pro zpracování.

V následující tabulce jsme poskytovali jak velikost oboru názvů, tak i 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 souborů menší, zvažte přidání další paměti pro stejnou velikost kapacity. Založte konfiguraci paměti na velikost oboru názvů.

*Synchronizace více než 100 milionů souborů & adresářů se v tuto chvíli nedoporučuje. Jedná se o omezení na základě našich otestovaných prahových hodnot. Další informace najdete v tématu Synchronizace souborů Azure škálování cílů.

• Místně připojený svazek formátovaný systémem souborů NTFS.

Rutina vyhodnocení

Před nasazením Synchronizace souborů Azure byste měli vyhodnotit, jestli je kompatibilní s vaším systémem, pomocí 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. Její kontroly pokrývají většinu, ale ne všechny níže uvedené funkce. Doporučujeme, abyste si pečlivě přečetli zbývající část této části, abyste zajistili bezproblémové nasazování.

Zkušební rutinu můžete nainstalovat instalací modulu Az PowerShell, který můžete nainstalovat podle těchto pokynů: Instalace a konfigurace Azure PowerShell.

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í. Postup kontroly systému i datové sady:

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

Testování pouze datové sady:

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

Pouze pro testování 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 na přímo připojených svazcích NTFS. Přímé připojené úložiště (DAS) na Windows Serveru znamená, že operační systém Windows Server vlastní systém souborů. DAS je možné skytovat prostřednictvím fyzického připojení disků k souborového 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 jenom svazky NTFS. Systémy souborů ReFS, FAT, FAT32 a jiné se nepodporují.

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

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

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

Při plánování používání Synchronizace souborů Azure zvažte, kolik volného místa na místním disku plánujete mít na koncovém bodu serveru.

Při Synchronizace souborů Azure budete muset vzít v úvahu, že zachytáte na místním disku následující informace:

• S povoleným vrstvením cloudu:

  • Body rozboru pro vrstvené soubory
  • Synchronizace souborů Azure databáze metadat
  • Synchronizace souborů Azure heatstore
  • Plně stažené soubory v Hot cache (pokud existují)
  • Požadavky zásad pro volné místo svazku

• Se zakázanou vrstvou cloudu:

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

K ilustraci, jak se na místním disku bude potřebovat odhad množství volného místa, použijeme příklad. řekněme, že jste nainstalovali agenta Synchronizace souborů Azure na virtuální počítač Azure Windows a naplánujete vytvořit koncový bod serveru na disku F. Máte 1 000 000 souborů a chcete na ně navrstvit všechny složky, 100 000 adresářů a diskové clustery o velikosti 4 KiB. Velikost disku je 1000 GiB. Chcete povolit vrstvení cloudu a nastavit zásady pro volné místo svazku na 20%.

1. NTFS přiděluje velikost clusteru pro každý vrstvený soubor. 1 000 000 souborů * 4 KiB cluster Size = 4 000 000 KiB (4 GiB)

V takovém případě Synchronizace souborů Azure potřebovat přibližně 209 500 000 KiB (209,5 GiB) místa pro tento obor názvů. Tuto částku přidejte na jakékoli další volné místo, které je žádoucí k tomu, abyste zjistili, kolik volného místa se pro tento disk vyžaduje.

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

1. Windows Clustering s podporou převzetí služeb při selhání podporuje Synchronizace souborů Azure pro možnost nasazení souborový server pro obecné použití.
2. jediným scénářem, který podporuje Synchronizace souborů Azure, je Windows clusteru s podporou převzetí služeb při selhání serverem s clustery
3. Clustering s podporou převzetí služeb při selhání není podporován na Souborový server se škálováním na více systémů pro data aplikací (SOFS) nebo na sdílených svazcích clusteru (CSV) nebo na místních discích.

Odstranění duplicitních dat

Windows Server 2016 a Windows Server 2019
odstranění duplicitních dat se podporuje bez ohledu na to, jestli je na jednom nebo více koncových bodech serveru na tomto svazku povolená nebo zakázaná vrstva cloudu pro Windows Server 2016 a Windows server 2019. Povolení odstranění duplicitních dat u svazku s povoleným vrstvou cloudu umožňuje ukládat do mezipaměti více souborů bez nutnosti zajistit další úložiště.

Když je u svazku s povoleným vrstvou cloudu povolené odstranění duplicitních dat, bude v umístění koncového bodu serveru na základě nastavení zásad cloudu vyčištěné duplicitní soubory ve stejném umístění. Jakmile budou optimalizované soubory odstranění duplicit vrstveny, úloha uvolňování paměti při odstranění duplicitních dat se automaticky spustí, aby se uvolní místo na disku, a to odebráním nepotřebných bloků dat, na které už neodkazuje jiné soubory na svazku.

Všimněte si, že úspory svazku se vztahují jenom na server. vaše data ve sdílené složce Azure nebudou Odstraněná duplicitovaná.

Windows Server 2012 R2
Synchronizace souborů Azure nepodporuje odstranění duplicitních dat a vrstvení cloudu na stejném svazku v Windows Server 2012 R2. Pokud je u svazku povolené odstranění duplicitních dat, musí být vrstva cloudu zakázaná.

Poznámky

• Pokud se odstranění duplicitních dat nainstaluje před instalací agenta Synchronizace souborů Azure, vyžaduje se restart k podpoře odstranění duplicitních dat a vrstvení cloudu na stejném svazku.

• Pokud je odstranění duplicitních dat u svazku po povolení vrstvení cloudu povolené, bude úloha optimalizace prvotního odstranění duplicit optimalizovat soubory na svazku, které ještě nejsou vrstvené, a bude mít následující dopad na vrstvení cloudu:

  • Zásada volného místa bude pokračovat v souborech vrstev podle volného místa na svazku pomocí nástroje heatmapu.
  • Zásada data přeskočí vrstvení souborů, které mohly být jinak způsobilé pro vrstvení z důvodu úlohy optimalizace odstranění duplicitních dat při přístupu k souborům.

• V případě probíhajících úloh optimalizace odstranění duplicit se vrstvení cloudu se zásadami data po nastavení MinimumFileAgeDays odstranění duplicitních dat zpozdí, pokud soubor ještě není vrstvený.

  • Příklad: Pokud je nastavení MinimumFileAgeDays sedm dní a zásady pro datové vrstvy cloudu jsou nastavené na 30 dní, zásada data bude mít soubory na úrovni po 37 dnech.
  • Poznámka: když je soubor vrstvený Synchronizace souborů Azure, úloha optimalizace odstranění duplicit 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 nebo Windows server 2019, je nutné provést následující kroky, aby bylo možné podporovat odstranění duplicitních dat a vrstvení cloudu na stejném svazku:

  • odinstalujte agenta Synchronizace souborů Azure pro Windows Server 2012 R2 a restartujte Server.
  • stáhněte agenta Synchronizace souborů Azure pro novou verzi serverového operačního systému (Windows Server 2016 nebo Windows server 2019).
  • Nainstalujte agenta Synchronizace souborů Azure a restartujte server.

  Poznámka: nastavení konfigurace Synchronizace souborů Azure na serveru se uchovávají při odinstalaci a opětovné instalaci agenta.

Systém souborů DFS (Distributed File System) (DFS)

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

Obory názvů DFS (DFS-n): synchronizace souborů Azure se plně podporují na serverech DFS-N. Agenta Synchronizace souborů Azure můžete nainstalovat na jeden nebo více členů DFS-N a synchronizovat data mezi koncovými body serveru a koncovým bodem cloudu. Další informace najdete v tématu Přehled oborů názvů DFS.

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ářů, kdy chcete použít DFS-R a Synchronizace souborů Azure společně:

• Migrujete z nasazení systému souborů DFS-R do nasazení Synchronizace souborů Azure. 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, se může připojit přímo k Internetu.
• Servery větví konsolidují data na jeden hub Server, pro který chcete použít Synchronizace souborů Azure.

Pro Synchronizace souborů Azure a DFS-R pro práci vedle sebe:

1. Na svazcích s replikovanými složkami DFS-R musí být zakázané Synchronizace souborů Azure vrstvení cloudu.
2. Koncové body serveru by se neměly konfigurovat v replikačních složkách jen pro čtení DFS-R.

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

Sysprep

Použití nástroje Sysprep na serveru s nainstalovaným agentem Synchronizace souborů Azure není podporováno a může vést k neočekávaným výsledkům. Instalace agenta a registrace serveru by se měly vyskytnout po nasazení image serveru a dokončení zkrácené instalace nástroje Sysprep.

Windows Search

pokud je na koncovém bodu serveru povolené vrstvení cloudu, soubory, které jsou vrstveny, se přeskočí a neindexují Windows hledání. Soubory bez vrstev jsou indexovány správně.

další řešení hierarchické správy Storage Management (HSM)

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

Výkon a škálovatelnost

vzhledem k tomu, že agent Synchronizace souborů Azure běží na serveru Windows Server, který se připojuje ke sdíleným složkám Azure, výkon efektivní synchronizace závisí na několika faktorech v 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 a aktivita v datové sadě. Vzhledem k tomu, že Synchronizace souborů Azure pracuje na úrovni souboru, jsou výkonnostní charakteristiky řešení založeného na Synchronizace souborů Azure lépe měřeny v počtu objektů (souborů a adresářů) zpracovaných za sekundu.

Změny provedené ve sdílené složce Azure pomocí Azure Portal nebo SMB se hned nedetekuje a replikují jako změny koncového bodu serveru. Soubory Azure ještě nemají oznámení o změnách ani deníky, takže neexistuje způsob, jak automaticky iniciovat relaci synchronizace při změně souborů. na serveru Windows Synchronizace souborů Azure používá Windows deníku USN k automatickému zahájení relace synchronizace při změně souborů.

Pokud chcete zjistit změny sdílené složky Azure, Synchronizace souborů Azure má naplánovanou úlohu s názvem úloha detekce změn. Úloha detekce změn vytvoří výčet všech souborů ve sdílené složce a pak ji porovná s verzí synchronizace pro daný soubor. Když úloha zjišťování změn zjistí, že se soubory změnily, Synchronizace souborů Azure zahájí relaci synchronizace. Úloha zjišťování změn je zahájena každých 24 hodin. Vzhledem k tomu, že úloha zjišťování změn funguje při vytváření výčtu všech souborů ve sdílené složce Azure, zjišťování změn trvá déle než v menších oborech názvů. Pro velké obory názvů může trvat déle než jednou za 24 hodin, abyste zjistili, které soubory se změnily.

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

Identita

Synchronizace souborů Azure pracuje se standardní identitou založenou na službě AD bez jakéhokoli speciálního nastavení nad rámec nastavení synchronizace. Pokud používáte Synchronizace souborů Azure, obecně se předpokládá, že většina přístupů projde servery Synchronizace souborů Azure pro ukládání do mezipaměti, nikoli prostřednictvím sdílené složky Azure. vzhledem k tomu, že jsou koncové body serveru umístěny na serveru Windows a Windows server podporuje seznamy acl pro služby AD a Windows po dlouhou dobu, není k dispozici nic, než zajistíte, aby Windows souborové servery zaregistrované ve službě Storage Sync byly připojeny k doméně. Synchronizace souborů Azure budou ukládat do souborů ve sdílené složce Azure seznamy ACL a budou se replikovat do všech koncových bodů serveru.

I když změny provedené přímo ve sdílené složce Azure budou trvat déle, než se synchronizují s koncovými body serveru ve skupině synchronizace, možná budete chtít taky zajistit, abyste ve sdílené složce mohli vyhovět i oprávněním služby AD přímo v cloudu. abyste to mohli udělat, musíte účet úložiště připojit k vaší místní službě AD, stejně jako je to, jak jsou Windows souborové servery připojené k doméně. Další informace o tom, jak se doména připojuje k vašemu účtu úložiště ke službě Active Directory vlastněné zákazníkem, najdete v tématu Přehled služby Azure Files Active Directory.

Sítě

agent Synchronizace souborů Azure komunikuje s vaší službou Storage Sync a sdílenou složkou souborů Azure pomocí protokolu Synchronizace souborů Azure rest a protokolu rest, přičemž oba vždy používají protokol HTTPS přes port 443. protokol SMB se nikdy nepoužívá k nahrávání nebo stahování dat mezi Windows serverem a sdílenou složkou Azure. Vzhledem k tomu, že většina organizací umožňuje provoz HTTPS přes port 443, jako požadavek na návštěvu většiny webů, se k nasazení služby Synchronizace souborů Azure.

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ů pro konfiguraci sítě. Na základě vašich požadavků můžete:

• Tunnel synchronizace a nahrávání a stahování souborů přes ExpressRoute nebo Azure VPN.
• Využijte funkce Azure Files a Sítě Azure, jako jsou koncové body služby a privátní koncové body.
• Nakonfigurujte Synchronizace souborů Azure tak, aby podporovaly váš proxy server ve vašem prostředí.
• Omezení síťové aktivity z Synchronizace souborů Azure.

Další informace o sítích a Synchronizace souborů Azure najdete v tématu Synchronizace souborů Azure síťových aspektech.

Šifrování

Při použití Synchronizace souborů Azure je třeba vzít v úvahu tři různé vrstvy šifrování: šifrování v klidových úložišti Windows Serveru, šifrování během přenosu mezi agentem Synchronizace souborů Azure a Azure a šifrování zbývajících dat ve sdílené složky Azure.

Windows Šifrování serveru v klidových klidech

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

Pokud chcete zajistit šifrování pod systémem souborů, Windows Server doručenou poštu nástroje BitLocker. BitLocker je pro Synchronizace souborů Azure. Hlavním důvodem pro použití šifrovacího mechanismu, jako je BitLocker, je zabránit fyzickému exfiltraci dat z místního datacentra tím, že někdo odcizením disků odcizením disků a zabránit tomu, aby neoprávněný operační systém načetl neoprávněná čtení a zápisy do vašich dat. Další informace o BitLockeru najdete v tématu Přehled BitLockeru.

Produkty třetích stran, které fungují podobně jako BitLocker, v tom, že se nachází pod svazkem NTFS, by měly podobně fungovat plně transparentně s Synchronizace souborů Azure.

Další hlavní metodou šifrování dat je šifrování datového streamu souboru, když aplikace soubor uloží. Některé aplikace to mohou dělat nativně, ale obvykle tomu tak není. Příkladem metody šifrování datového proudu souboru je Azure Information Protection (AIP) / Azure Rights Management Services (Azure RMS) / Active Directory RMS. Hlavním důvodem pro použití šifrovacího mechanismu, jako je AIP/RMS, je zabránit exfiltraci dat ze sdílené složky lidmi, kteří je kopírují do alternativních umístění, například na flash disk, nebo je poslat e-mailem neautorizované osobě. Když je datový proud souboru zašifrovaný jako součást formátu souboru, bude tento soubor dál zašifrovaný ve sdílené složky Azure.

Synchronizace souborů Azure systému souborů NTFS (NTFS Encrypted File System) ani s řešeními šifrování třetích stran, která jsou nad systémem souborů, ale pod datovým proudem souboru, vzájemně spolupracuje.

Šifrování během přenosu

Synchronizace souborů Azure agent komunikuje s vaší synchronizační službou Storage a sdílením souborů Azure pomocí protokolu Synchronizace souborů Azure REST a protokolu FileREST, z nichž obě vždy používají HTTPS přes port 443. Synchronizace souborů Azure neodesíleje 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í k vašim sdílených složek Azure, Synchronizace souborů Azure bude pro přístup ke sdílené složky nadále používat jenom šifrované kanály.

Hlavním důvodem pro zákaz šifrování během přenosu pro účet úložiště je podpora starší verze aplikace, která musí běžet ve starším operačním systému, jako je Windows Server 2008 R2 nebo starší distribuce Linuxu, a přímé rozhovory se sdílením souborů Azure. Pokud starší verze aplikace hovoří Windows server mezipaměti sdílené složky, nebude mít přepínání tohoto nastavení žádný vliv.

Důrazně doporučujeme zajistit povolení šifrování dat během přenosu.

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

Šifrování sdílené složky Azure v klidové době

Všechna data uložená v souborech Azure jsou v klidovém stavu zašifrovaná 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 se data šifrují pod systémem souborů sdílené složky Azure, protože je zašifrovaná na disk, nemusíte mít přístup k základnímu klíči v klientovi, aby bylo možné číst a zapisovat do sdílené složky Azure. Šifrování v klidovém umístění platí pro protokoly SMB i NFS.

Ve výchozím nastavení se data uložená v souborech Azure šifrují pomocí klíčů spravovaných Microsoftem. V případě klíčů spravovaných Microsoftem uchovává společnost Microsoft klíče pro šifrování a dešifrování dat a zodpovídá za pravidelné střídání. Můžete se také rozhodnout, že budete spravovat vlastní klíče, což vám umožní řídit proces otáčení. Pokud se rozhodnete šifrovat sdílené složky pomocí klíčů spravovaných zákazníkem, soubory Azure budou mít autorizaci pro přístup k vašim klíčům, aby mohli plnit požadavky na čtení a zápis z vašich 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 nebo rozhraní REST API.

Služba soubory Azure používá stejné schéma šifrování jako jiné 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í Azure Storage proneaktivní neaktivní data.

Úrovně úložiště

Azure Files nabízí čtyři různé úrovně úložiště, Premium, optimalizované pro transakce, horkou a studenou úroveň, které umožňují přizpůsobit sdílené složky požadavkům vašeho scénáře na výkon a cenu:

• Premium: Sdílené složky úrovně Premium jsou zálohovány disky SSD (solid-state drives) a poskytují konzistentní vysoký výkon a nízkou latenci pro většinu V/V operací v řádu milisekund pro úlohy náročné na V/V. 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) i NFS (Network File System).
• Optimalizované pro transakce: Sdílené složky optimalizované pro transakce umožňují úlohy náročné na transakce, které nepožádá latenci nabízenou sdílené složky úrovně Premium. Sdílené složky optimalizované pro transakce se nabízejí na standardním hardwaru úložiště, který je zálohovaný pevnými disky (PEVNÉ DISKY). Optimalizace transakcí se v minulosti označuje jako "standardní", ale odkazuje na typ média úložiště spíše než na samotnou vrstvu (horká a studená jsou také "standardní" úrovně, protože jsou na standardním hardwaru úložiště).
• Horká: Horké sdílené složky nabízejí úložiště optimalizované pro scénáře sdílení souborů pro obecné účely, jako jsou týmové sdílené složky. Horké sdílené složky se nabízejí na hardwaru standardního úložiště s disky HDD.
• Studená: Studené sdílené složky nabízejí nákladově efektivní úložiště optimalizované pro scénáře online archivního úložiště. Studené sdílené složky se nabízejí na standardním hardwaru úložiště s disky HDD.

Sdílené složky úrovně Premium se nasadí v typu účet úložiště FileStorage a jsou k dispozici pouze v modelu zřízené fakturace. Další informace o zřízené 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. Standardní sdílené složky, včetně transakce optimalizované, horké a studené sdílené složky, se nasazují v typu účtu úložiště pro obecné účely verze 2 (GPv2) a při fakturaci jsou k dispozici prostřednictvím průběžných plateb.

Při výběru vrstvy úložiště pro vaše úlohy zvažte požadavky na výkon a využití. Pokud vaše úloha vyžaduje latenci s jednou číslicí nebo používáte úložné médium SSD místně, je pravděpodobně nejlepší přizpůsobit úroveň Premium. Pokud se nízká latence nevejde do značné míry, například u týmových sdílených složek, které jsou místně připojené z Azure nebo v místní mezipaměti pomocí Synchronizace souborů Azure, může být úložiště úrovně Standard lépe vhodné z hlediska nákladů.

Jakmile vytvoříte sdílenou složku v účtu úložiště, nemůžete ji přesunout do vrstev výhradně na různé typy účtů úložiště. Například pro přesunutí transakce optimalizované sdílené složky do úrovně Premium musíte v účtu úložiště úložiště vytvořit novou sdílenou složku a zkopírovat data z původní sdílené složky do nové sdílené složky v účtu úložiště. K kopírování dat mezi sdílenými složkami Azure doporučujeme používat AzCopy, ale můžete použít také nástroje jako robocopy ve Windows nebo rsync pro MacOS a Linux.

Sdílené složky nasazené v rámci účtů úložiště GPv2 se dají přesouvat mezi standardními úrovněmi (transakce optimalizovaná, horká a studená) bez vytvoření nového účtu úložiště a migrace dat, ale při změně úrovně se vám budou účtovat náklady za transakce. Když přesunete sdílenou složku z vrstvy Hotter do úrovně chladicího počítače, bude se účtovat poplatek za transakci zápisu na úrovni chladicích souborů pro každý soubor ve sdílené složce. Když přesunete sdílenou složku z úrovně chladicích souborů na úroveň Hotter, bude se účtovat poplatek za transakce čtení ve studené vrstvě pro každý soubor ve sdílené složce.

Další informace najdete v tématu Principy fakturace služby soubory Azure .

Regionální dostupnost

Standardní sdílené složky s 100 kapacitou TiB mají určitá omezení.

• V současné době jsou podporovány pouze místně redundantní úložiště (LRS) a účty redundantního úložiště (ZRS).
• Po povolení velkých sdílených složek nemůžete převádět účty úložiště do geograficky redundantního úložiště (GRS) nebo účtů GZRS (GEO-Zone-redundantní úložiště).
• Jakmile povolíte velké sdílené složky, nemůžete ji zakázat.

Dostupnost oblastí Synchronizace souborů Azure

Informace o regionální dostupnosti najdete v tématu Dostupné produkty v rámci oblasti.

Následující oblasti vyžadují, abyste si vyžádali přístup k Azure Storage, než s nimi budete Synchronizace souborů Azure používat:

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

Pokud chcete požádat o přístup pro tyto oblasti, postupujte podle procesu v tomto dokumentu.

Redundance

Aby se data ve sdílených složek Azure chránila před ztrátou nebo poškozením dat, ukládají všechny sdílené složky Azure během zápisu několik kopií každého souboru. V závislosti na požadavcích vaší úlohy můžete vybrat další stupně redundance. Azure Files v současné době podporuje následující možnosti redundance dat:

• Místně redundantní úložiště (LRS): Při 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 ale v datovém centru dojde k havárii, jako je požár nebo zahlcení, může dojít ke ztrátě nebo obnovení všech replik účtu úložiště pomocí LRS.
• Zónově redundantní úložiště (ZRS): Se zónově redundantním úložištěm jsou tři kopie každého uloženého souboru, ale tyto kopie jsou 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 nachází v jednom nebo více datových centrech vybavených nezávislým napájením, chlazením a sítí. 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): V případě GRS máte dvě oblasti– primární 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í vašich dat rozložených mezi dvě oblasti 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í a sekundární se stane primární oblastí, která bude sloužit všem operacím. Vzhledem k tomu, že replikace mezi primární a sekundární oblastí je asynchronní, v případě závažné havárie se data, která ještě nereplikují do sekundární oblasti, ztratí. 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 myslet, jako by to bylo jako ZRS, ale s geografickou redundancí. S GZRS se soubory ukládají třikrát napříč třemi různými úložnými clustery 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 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. Premium Sdílené složky Azure podporují pouze LRS a ZRS.

Účty úložiště pro obecné účely verze 2 (GPv2) poskytují dvě další možnosti redundance, které Azure Files nepodporuje: geograficky redundantní úložiště s přístupem pro čtení, často označované jako RA-GRS a geograficky zónově redundantní úložiště s přístupem pro čtení, často označované jako RA-GZRS. V účtech úložiště můžete zřídit sdílené složky Azure s těmito nastavenými možnostmi, Azure Files ale nepodporuje čtení ze sekundární oblasti. Sdílené složky Azure nasazené do účtů geograficky nebo geograficky zónově redundantního úložiště s přístupem pro čtení se budou účtovat jako geograficky redundantní nebo geograficky zónově redundantní úložiště.

Migrace

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

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

Antivirus

Vzhledem k tomu, že antivirový program funguje tak, že v souborech naskenuje známý škodlivý kód, může antivirový produkt způsobit odvolání vrstvené soubory, což vede k vysokým poplatkům za přenos dat. Ve verzích 4.0 a novějších pro agenta Synchronizace souborů Azure mají vrstvené soubory nastavený zabezpečený atribut Windows FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS zabezpečení. Doporučujeme poradit si s dodavatelem softwaru, abyste se dozvěděli, jak nakonfigurovat své řešení tak, aby přeskočili čtení souborů s touto sadu atributů (mnoho z nich to dělají automaticky).

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

Backup

Pokud je povolené vrstvení cloudu, neměla by se používat řešení, která přímo zálohují koncový bod serveru nebo virtuální počítač, na kterém se nachází koncový bod serveru. Vrstvení cloudu způsobí, že se do koncového bodu serveru uloží jenom podmnožina vašich dat, takže se celá datová sada nachází ve sdílené složky Azure. V závislosti na použitém řešení zálohování se vrstvené soubory buď přeskočí a nebudou zálohovat (protože mají nastavený atribut FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS), nebo se odvolaly na disk, což vede k vysokým poplatkům za výchozí přenos dat. K přímému 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 podívejte se, jestli podporuje zálohování sdílených složek Azure.

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

Klasifikace dat

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

1. Při povoleném vrstvení cloudu se vaše nejaktuálenější soubory ukládá do místní mezipaměti a nejchytřejší soubory se vrství do sdílené složky Azure v cloudu. Pokud klasifikace dat pravidelně kontroluje všechny soubory ve sdíleném souboru, musí se soubory vrstvené do cloudu při každém prohledávání odvolat.

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

Tyto nárůsty počtu odvolávání i objemu svoláných dat mohou zvýšit náklady.

Zásady aktualizace agenta Synchronizace souborů Azure

Agent Synchronizace souborů Azure se pravidelně aktualizuje, aby bylo možné přidat nové funkce a vyřešit problémy. Doporučujeme, abyste nakonfigurovali Microsoft Update, abyste získali aktualizace pro agenta Synchronizace souborů Azure, jak jsou k dispozici.

Hlavní verze agentů vs.

• Hlavní verze agenta často obsahují nové funkce a v první části čísla verze se zvyšuje číslo. Příklad: * 2. * .**
• Dílčí verze agenta se také nazývají "opravy" a jsou vydávány častěji než hlavní verze. Často obsahují opravy chyb a menší vylepšení, ale žádné nové funkce. Příklad: * * . 3.**

Cesty upgradu

Existují čtyři schválené a testované způsoby, jak nainstalovat aktualizace agenta Synchronizace souborů Azure.

1. Doporučeno Nakonfigurujte Microsoft Update pro automatické stažení a instalaci aktualizací agenta.
   Vždycky doporučujeme, abyste provedli každou aktualizaci Synchronizace souborů Azure, abyste měli jistotu, že máte přístup k nejnovějším opravám pro agenta serveru. Microsoft Update tento proces plynule provede automatickým stažením a instalací aktualizací.
2. Pomocí AfsUpdater.exe stáhnout a nainstalovat aktualizace agenta.
   AfsUpdater.exe se nachází v instalačním adresáři agenta. Dvakrát klikněte na spustitelný soubor ke stažení a instalaci aktualizací agenta.
3. Opravte stávajícího agenta Synchronizace souborů Azure pomocí souboru Microsoft Update opravy nebo spustitelného souboru. msp. Nejnovější balíček aktualizace Synchronizace souborů Azure lze stáhnout z katalogu Microsoft Update.
   Spuštění souboru. msp provede upgrade instalace Synchronizace souborů Azure stejným způsobem použitým automaticky pomocí Microsoft Update v předchozí cestě upgradu. Použití opravy Microsoft Update provede místní upgrade instalace Synchronizace souborů Azure.
4. Stáhněte si nejnovější Synchronizace souborů Azure instalátor agenta 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. Služba Synchronizace souborů Azure Installer udržuje registraci serveru, skupiny synchronizace a všechna ostatní nastavení.

Automatické řízení životního cyklu agentů

S agentem verze 6 zavedl tým synchronizace souborů funkci automatického upgradu agenta. Můžete vybrat kterýkoli ze dvou režimů a určit časové období údržby, ve kterém se upgrade na serveru bude pokoušet. Tato funkce je navržená tak, aby vám pomohla se správou životního cyklu agentů tím, že poskytuje guardrail, který brání vašemu vypršení platnosti vašeho agenta, nebo umožňuje neaktuální nastavení.

1. Výchozí nastavení se pokusí zabránit agentovi v vypršení platnosti. Během 21 dní od data vypršení platnosti agenta se agent pokusí provést upgrade sami. Spustí se pokus o upgrade jednou týdně během 21 dnů před vypršením platnosti a ve vybraném časovém období údržby. Tato možnost neeliminuje nutnost provádět běžné Microsoft Update opravy.
2. Volitelně můžete vybrat, že se bude agent automaticky upgradovat, jakmile bude k dispozici nová verze agenta (aktuálně neplatí pro clusterované servery). Tato aktualizace proběhne během vybraného časového období údržby a umožní vašemu serveru využívat nové funkce a vylepšení, jakmile budou všeobecně dostupné. Toto je doporučené nastavení bez obav, které bude poskytovat hlavní verze agentů, stejně jako běžné aktualizace na váš server. Každý vydaný agent má kvalitu GA. Pokud vyberete tuto možnost, Microsoft zabere nejnovější verzi agenta. Servery v clusteru jsou vyloučené. Po dokončení letu 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 změnit nastavení po dokončení instalačního programu, pokud potřebujete provést změny.

Otevřete konzolu PowerShellu a přejděte do adresáře, kam jste nainstalovali agenta synchronizace, a pak importujte 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

Můžete spustit, Get-StorageSyncAgentAutoUpdatePolicy Pokud chcete kontrolovat aktuální nastavení zásad a určit, jestli ho chcete změnit.

Chcete-li změnit aktuální nastavení zásad na záznam opožděné aktualizace, můžete použít:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

Chcete-li změnit aktuální nastavení zásad na okamžitou stopu aktualizace, můžete použít:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest

Životní cyklus agenta a záruky správy změn

Synchronizace souborů Azure je cloudová služba, která průběžně přináší nové funkce a vylepšení. To znamená, že konkrétní verzi agenta Synchronizace souborů Azure lze podporovat pouze po dobu omezeného času. V zájmu usnadnění nasazení vám následující pravidla zaručují dostatek času a oznámení, aby bylo možné v procesu správy změn zajišťovat aktualizace a upgrady agenta:

• Hlavní verze agenta se podporují aspoň po dobu šesti měsíců od data prvotní verze.
• U podpory hlavních verzí agentů garantujeme, že se překrývá aspoň tři měsíce.
• Upozornění se vydávají pro registrované servery s použitím již neplatného agenta, který uplyne nejméně tři měsíce před vypršením platnosti. Můžete zjistit, jestli registrovaný Server používá starší verzi agenta v části registrované servery služby synchronizace úložiště.
• Životnost dílčí verze agenta je svázána s přidruženou hlavní verzí. Například když se uvolní Agent verze 3,0, verze agenta 2. * nastaví se tak, aby vyprší dohromady.

Další kroky

• Zvážení nastavení brány firewall a proxy serveru
• Nasazení služby Soubory Azure
• Nasazení Synchronizace souborů Azure
• Sledování služby Synchronizace souborů Azure