Planowanie wdrożenia usługi Azure File Sync

Wywiad i demonstracja przedstawiająca usługę Azure File Sync — wybierz opcję odtwarzania.

Azure File Sync to usługa, której można użyć do buforowania kilku udziałów plików Azure na lokalnym serwerze Windows Server lub maszynie wirtualnej w chmurze.

W tym artykule przedstawiono pojęcia i funkcje usługi Azure File Sync. Po zapoznaniu się z usługą Azure File Sync rozważ skorzystanie z przewodnika wdrażania usługi Azure File Sync , aby wypróbować tę usługę.

Pliki są przechowywane w chmurze w udziałach plików platformy Azure. Udziały plików platformy Azure można używać na dwa sposoby. Wybrana opcja wdrożenia zmienia aspekty, które należy wziąć pod uwagę podczas planowania wdrożenia.

  • Bezpośrednie instalowanie udziału plików platformy Azure przy użyciu protokołu bloku komunikatów serwera (SMB): Ponieważ usługa Azure Files zapewnia dostęp do protokołu SMB, udziały plików platformy Azure można zainstalować lokalnie lub w chmurze przy użyciu standardowego klienta SMB dostępnego w systemach Windows, macOS i Linux. Ponieważ zasoby plikowe Azure są bezserwerowe, wdrażanie ich w scenariuszach produkcyjnych nie wymaga zarządzania serwerem plików ani urządzeniem NAS (magazynu dołączonego do sieci). Ten wybór oznacza, że nie trzeba stosować poprawek oprogramowania ani wymieniać dysków fizycznych.

  • Buforowanie lokalnego udziału plików platformy Azure przy użyciu usługi Azure File Sync: dzięki usłudze Azure File Sync można scentralizować udziały plików organizacji w usłudze Azure Files, zachowując elastyczność, wydajność i zgodność lokalnego serwera plików. Usługa Azure File Sync przekształca lokalny lub chmurowy węzeł Windows Server w szybką pamięć podręczną udziału plików platformy Azure.

Pojęcia dotyczące zarządzania

Na platformie Azure zasób jest elementem, którym można zarządzać, który można utworzyć i skonfigurować w ramach subskrypcji platformy Azure i grup zasobów. Zasoby są oferowane przez dostawców zasobów, które są usługami zarządzania, które dostarczają określone typy zasobów. Aby wdrożyć usługę Azure File Sync, będziesz pracować z dwoma kluczowymi zasobami:

  • Konta magazynu oferowane przez dostawcę Microsoft.Storage zasobów. Konta magazynowe to zasoby najwyższego poziomu, które stanowią pulę współdzielonego magazynu, IOPS i przepustowości, które umożliwiają wdrożenie klasycznych udziałów plików lub innych zasobów magazynowych, w zależności od rodzaju konta. Wszystkie zasoby magazynu wdrożone na koncie magazynu współużytkują limity, które mają zastosowanie do tego konta magazynu. Klasyczne udziały plików obsługują protokoły udostępniania plików SMB i NFS, ale usługi Azure File Sync można używać tylko z udziałami plików SMB.

    Uwaga

    Usługa Azure Files obsługuje również wdrażanie udziałów plików jako zasobu najwyższego poziomu na platformie Azure za pośrednictwem dostawcy zasobów Microsoft.FileShares. Jednak ponieważ te udziały plików obecnie obsługują tylko protokół NFS, nie są one obsługiwane przez usługę Azure File Sync.

  • Usługi synchronizacji magazynu oferowane przez dostawcę Microsoft.StorageSync zasobów. Usługi Storage Sync działają jako kontenery zarządzania, które umożliwiają rejestrowanie Windows File Servers i definiowanie relacji synchronizacji dla Azure File Sync.

Pojęcia dotyczące zarządzania udziałami plików platformy Azure

Tradycyjne udziały plików lub te wdrażane na kontach magazynowych to klasyczna metoda wdrażania udziałów plików w usłudze Azure Files. Obsługują one wszystkie kluczowe funkcje obsługiwane przez usługę Azure Files, w tym warstwy SMB i NFS, SSD i HDD, każdy typ nadmiarowości i w każdym regionie. Aby dowiedzieć się więcej na temat klasycznych udziałów plików, zobacz klasyczne udziały plików.

Istnieją dwa główne rodzaje kont magazynu używanych do wdrożenia klasycznych udziałów plików:

  • Przydzielone konta magazynu: Przydzielone konta magazynu są rozróżniane przy użyciu FileStorage rodzaju konta magazynu. Aprowidowane konta magazynu umożliwiają wdrażanie zaaprowizowanych klasycznych udziałów plików na sprzęcie opartym na dyskach SSD lub HDD. Przydzielone konta magazynowe można używać tylko do przechowywania klasycznych udziałów plików i nie można ich używać do przechowywania innych zasobów, takich jak kontenery obiektów blob, kolejki i tabele. Zalecamy używanie provisionowanych kont magazynu dla wszystkich nowych wdrożeń udostępnień plików w klasycznym modelu.
  • Konta magazynowania z płatnością zgodnie z użyciem: Konta magazynowania z płatnością zgodnie z użyciem są rozróżniane przy użyciu StorageV2 rodzaju konta magazynowania. Konta magazynu z płatnością zgodnie z rzeczywistym użyciem umożliwiają wdrażanie udziałów plików z płatnością zgodnie z rzeczywistym użyciem na sprzęcie opartym na hdd. Konta przechowywania z płatnością zgodnie z rzeczywistym użyciem mogą być wykorzystywane do przechowywania klasycznych zasobów udostępnionych plików oraz innych zasobów przechowywania, takich jak kontenery obiektów blob, kolejki lub tabele.

Pojęcia dotyczące zarządzania usługą Azure File Sync

W ramach usługi synchronizacji magazynu można wdrożyć:

  • Zarejestrowane serwery, które reprezentują serwer plików systemu Windows, który posiada relację zaufania z usługą synchronizacji magazynu. Zarejestrowane serwery mogą być pojedynczym serwerem lub klastrem, jednak serwer/klaster można zarejestrować tylko w jednej usłudze synchronizacji magazynu jednocześnie.

  • Grupy synchronizacji definiujące relację synchronizacji między punktem końcowym chmury a co najmniej jednym punktem końcowym serwera. Punkty końcowe w ramach grupy synchronizacji są synchronizowane ze sobą. Jeśli na przykład masz dwa odrębne zestawy plików, którymi chcesz zarządzać za pomocą usługi Azure File Sync, należy utworzyć dwie grupy synchronizacji i dodać różne punkty końcowe do każdej grupy synchronizacji.

    • Punkty końcowe w chmurze, które reprezentują Azure file shares.
    • Punkty końcowe serwera, które reprezentują ścieżki na zarejestrowanych serwerach synchronizowanych z usługą Azure Files. Zarejestrowany serwer może zawierać wiele punktów końcowych serwera, jeśli ich przestrzenie nazw nie nakładają się na siebie.

Ważne

Możesz wprowadzić zmiany w przestrzeni nazw dowolnego punktu końcowego chmury lub punktu końcowego serwera w grupie synchronizacji i zsynchronizować pliki z innymi punktami końcowymi w grupie synchronizacji. Jeśli wprowadzisz bezpośrednio zmianę w punkcie końcowym chmury (udział plików platformy Azure), zadanie wykrywania zmian usługi Azure File Sync musi najpierw zidentyfikować zmiany. Zadanie wykrywania zmian dla punktu końcowego chmury jest uruchamiane tylko raz na 24 godziny. Aby uzyskać więcej informacji, zobacz Często zadawane pytania dotyczące usług Azure Files i Azure File Sync.

Liczba wymaganych usług synchronizacji danych magazynowych

Usługa synchronizacji magazynu danych to podstawowy zasób Azure Resource Manager dla usługi Azure File Sync. Zarządza relacjami synchronizacji między instalacjami systemu Windows Server a udziałami plików w Azure. Każda usługa synchronizacji przechowywania może zawierać wiele grup synchronizacji i wiele zarejestrowanych serwerów.

Każde wystąpienie systemu Windows Server można zarejestrować tylko w jednej usłudze synchronizacji plików. Po rejestracji serwer może uczestniczyć w wielu grupach synchronizacji w ramach tej usługi synchronizacji magazynu przy użyciu jednostki usługi Resource Manager w celu utworzenia punktów końcowych serwera na serwerze.

Podczas projektowania topologii synchronizacji plików Azure File Sync, należy wyraźnie odizolować dane na poziomie usługi synchronizacji magazynowej. Jeśli na przykład przedsiębiorstwo wymaga oddzielnych środowisk usługi Azure File Sync dla dwóch odrębnych jednostek biznesowych i potrzebujesz ścisłej izolacji danych między tymi grupami, należy utworzyć dedykowaną usługę synchronizacji magazynu dla każdej grupy. Unikaj umieszczania grup synchronizacji dla obu grup biznesowych w ramach tej samej usługi synchronizacji pamięci, ponieważ taka konfiguracja nie zapewni pełnej izolacji.

Aby uzyskać więcej wskazówek dotyczących izolacji danych przy użyciu oddzielnych subskrypcji lub grup zasobów na platformie Azure, zapoznaj się z tematem Dostawcy zasobów i typy platformy Azure.

Planowanie zrównoważonych topologii synchronizacji

Przed wdrożeniem jakichkolwiek zasobów należy zaplanować, które dane będą synchronizowane na serwerze lokalnym oraz z jakim udziałem plików w Azure. Planowanie pomaga określić, ile kont magazynowych, udziałów plików Azure i zasobów synchronizacji potrzebujesz. Te kwestie są istotne, nawet jeśli dane nie znajdują się aktualnie na instancji systemu Windows Server lub na serwerze przeznaczonym do długoterminowego użytku. Sekcja migracji tego artykułu może pomóc w ustaleniu odpowiednich ścieżek migracji w danej sytuacji.

W tym kroku określisz, ile potrzebnych udostępnionych zasobów plikowych platformy Azure. Pojedyncze wystąpienie systemu Windows Server (lub klaster) może synchronizować maksymalnie 30 udziałów plików Azure.

Być może masz w swoich woluminach więcej folderów, które obecnie udostępniasz lokalnie użytkownikom i aplikacjom jako udziały SMB. Najprostszym sposobem na wyobrażenie sobie tego scenariusza jest wyobrażenie sobie udziału lokalnego, mapując 1:1 na udostępnianie plików w usłudze Azure. Jeśli liczba udziałów jest wystarczająco mała, poniżej 30 na jedną instancję systemu Windows Server, zalecamy mapowanie 1:1.

Jeśli masz więcej niż 30 udziałów, mapowanie udziału lokalnego 1:1 na udział plikowy Azure jest często niepotrzebne. Rozważ następujące opcje.

Grupowanie udziałów

Jeśli na przykład dział kadr (HR) ma 15 udziałów, możesz rozważyć przechowywanie wszystkich danych kadrowych w jednym udziale plików platformy Azure. Przechowywanie wielu udziałów na miejscu w jednym udziale plików Azure nie przeszkadza w tworzeniu zwykłych 15 udziałów SMB na lokalnym serwerze Windows Server. Oznacza to tylko, że foldery główne tych 15 udziałów są zorganizowane jako podfoldery w folderze wspólnym. Następnie zsynchronizuj ten wspólny folder z udziałem plików platformy Azure. W ten sposób potrzebujesz tylko jednego udziału plików Azure w chmurze dla tej grupy lokalnych udziałów plików.

Synchronizacja głośności

Usługa Azure File Sync umożliwia synchronizowanie katalogu głównego woluminu z udostępnionym zasobem plików w Azure. Jeśli zsynchronizujesz katalog główny woluminu, wszystkie podfoldery i pliki przechodzą do tego samego udziału plików platformy Azure.

Synchronizowanie korzenia woluminu nie zawsze jest najlepszą opcją. Istnieją korzyści wynikające z synchronizacji wielu lokalizacji. Na przykład, dzięki temu liczba elementów w obszarze synchronizacji jest mniejsza. Testujemy udziały plików platformy Azure i usługę Azure File Sync ze 100 milionami elementów (plików i folderów) na każdy udział. Najlepszym rozwiązaniem jest jednak utrzymanie liczby poniżej 20 milionów lub 30 milionów w jednym udziale.

Konfigurowanie usługi Azure File Sync z mniejszą liczbą elementów nie jest korzystne tylko w przypadku synchronizacji plików. Mniejsza liczba elementów również przynosi korzyści w takich scenariuszach:

  • Wstępne skanowanie zawartości w chmurze może zakończyć się szybciej, co z kolei zmniejsza oczekiwanie na wyświetlenie przestrzeni nazw na serwerze włączonym dla usługi Azure File Sync.
  • Przywracanie z migawki udostępniania plików na platformie Azure po stronie chmury jest szybsze.
  • Odzyskiwanie po awarii serwera lokalnego może znacznie przyspieszyć.
  • Zmiany wprowadzone bezpośrednio w udziale plików platformy Azure (poza synchronizacją) można wykrywać i synchronizować szybciej.

Wskazówka

Jeśli nie wiesz, ile plików i folderów masz, zapoznaj się z narzędziem TreeSize z narzędzia JAM Software.

Podejście strukturalne do mapy wdrożenia

Przed wdrożeniem magazynu danych w chmurze na późniejszym etapie należy utworzyć mapę między folderami lokalnymi a udziałami plików usługi Azure. To mapowanie informuje, ile i które zasoby grupy synchronizacji usługi Azure File Sync będą prowizowane. Grupa synchronizacji łączy udział plików Azure z folderem na serwerze i ustanawia połączenie synchronizacyjne.

Aby zoptymalizować mapę oraz zdecydować, ile udziałów plików platformy Azure potrzebujesz, zapoznaj się z następującymi limitami i najlepszymi praktykami.

  • Serwer, na którym jest zainstalowany agent usługi Azure File Sync, może synchronizować się z maksymalnie 30 udziałami plików platformy Azure.

  • Udział plików platformy Azure został wdrożony w koncie magazynowym. Takie rozwiązanie sprawia, że konto magazynu staje się punktem odniesienia dla skalowania wskaźników wydajności, takich jak liczba operacji we/wy na sekundę i przepływność.

    Zwróć uwagę na ograniczenia IOPS konta magazynu podczas wdrażania udziałów plików usługi Azure. Najlepiej mapować udziały plików 1:1 przy użyciu kont przechowywania. Jednak to mapowanie może nie zawsze być możliwe ze względu na różne limity i ograniczenia, zarówno z organizacji, jak i z platformy Azure. Jeśli nie można wdrożyć tylko jednego udziału plików na jednym koncie magazynu, rozważ, które udziały będą bardzo aktywne i które udziały będą mniej aktywne. Nie umieszczaj udziałów plików o największym obciążeniu na tym samym koncie przechowywania.

    Jeśli planujesz przenieść aplikację na platformę Azure, która będzie używać natywnie udziału plików Azure, możesz potrzebować większej wydajności od tego udziału plików. Jeśli ten typ użycia jest możliwy, nawet w przyszłości, najlepszym rozwiązaniem jest utworzenie standardowego udziału plików Azure w oddzielnym koncie magazynu.

  • Istnieje limit 250 kont magazynowych na subskrypcję w każdym regionie Azure.

Wskazówka

Na podstawie tych informacji często staje się konieczne pogrupowanie wielu folderów na najwyższym poziomie na woluminach w nowy, wspólny katalog główny. Następnie zsynchronizuj ten nowy katalog główny i wszystkie foldery zgrupowane w nim do pojedynczego udziału plików platformy Azure. Ta technika pozwala zachować limit 30 synchronizacji udziałów plików Azure na serwer.

Grupowanie według wspólnego korzenia nie wpływa na dostęp do Twoich danych. Listy ACL pozostają tak, jak są. Wystarczy dostosować wszystkie ścieżki udziału (takie jak udziały SMB lub NFS), które mogą być dostępne w folderach serwera lokalnego, które zostały teraz zmienione w wspólny katalog główny. Nic innego się nie zmienia.

Ważne

Najważniejszym wektorem skalowania usługi Azure File Sync jest liczba elementów (plików i folderów), które należy zsynchronizować. Aby uzyskać więcej informacji, przejrzyj cele skalowania usługi Azure File Sync .

Istnieje możliwość, że w twojej sytuacji zestaw folderów może logicznie synchronizować się z tym samym udziałem plików w usłudze Azure, używając wcześniej wspomnianego podejścia o wspólnym korzeniu. Jednak nadal może być lepiej przegrupować foldery tak, aby synchronizowały się z dwoma udziałami plików platformy Azure zamiast z jednym. Dzięki temu podejściu można zrównoważyć liczbę plików i folderów w zasobie plików na serwerze. Możesz również podzielić lokalne zasoby udostępnione i zsynchronizować je na dodatkowych serwerach lokalnych, aby dodać możliwość synchronizacji z dodatkowymi 30 zasobami udostępnionymi Azure na każdy dodatkowy serwer.

Ważne

Najważniejszym wektorem skalowania usługi Azure File Sync jest liczba elementów (plików i folderów), które należy zsynchronizować. Aby uzyskać więcej informacji, zapoznaj się z celami skalowania usługi Azure File Sync.

Typowe scenariusze i zagadnienia dotyczące synchronizacji plików

Scenariusz synchronizacji Obsługiwane Zagadnienia (lub ograniczenia) Rozwiązanie (lub obejście)
Serwer plików z wieloma dyskami/woluminami i wieloma udziałami do tego samego docelowego udziału plików platformy Azure (konsolidacja) Nie. Docelowy udział plików platformy Azure (punkt końcowy w chmurze) obsługuje synchronizację tylko z jedną grupą synchronizacji.

Grupa synchronizacji obsługuje tylko jeden punkt końcowy serwera na zarejestrowany serwer.		 1) Rozpocznij od zsynchronizowania jednego dysku (jego woluminu głównego) z docelowym udziałem plików Azure. Rozpoczęcie od największego dysku/woluminu pomoże spełnić wymagania dotyczące magazynu lokalnego. Skonfiguruj warstwowanie danych w chmurze, aby przenieść wszystkie dane do chmury i zwolnić miejsce na dysku serwera plików. Przenieś dane z innych woluminów/udziałów do bieżącego woluminu, który jest synchronizowany. Wykonuj poszczególne kroki, aż wszystkie dane zostaną przeniesione do chmury lub zmigrowane.
2) Skup się na jednym woluminie głównym (dysku) naraz. Użyj warstwowania w chmurze, aby przesunąć wszystkie dane do wyższej warstwy udostępnionego zasobu plików Azure. Usuń punkt końcowy serwera z grupy synchronizacji, utwórz punkt końcowy z użyciem następnego woluminu głównego/dysku, synchronizuj, a następnie powtórz proces. Pamiętaj, że może być konieczne ponowne zainstalowanie agenta.
3) Zaleca się używanie wielu docelowych udziałów plików Azure (tego samego lub innego konta magazynowego na podstawie wymagań dotyczących wydajności).
Serwer plików z jednym woluminem i wieloma zasobami udostępnionymi do tego samego docelowego zasobu współdzielonego na platformie Azure (konsolidacja) Tak Nie można mieć wielu punktów końcowych serwera dla zarejestrowanego serwera, synchronizujących się z tym samym docelowym udziałem plików Azure (podobnie jak w poprzednim scenariuszu). Zsynchronizuj katalog główny woluminu, który zawiera wiele udziałów lub folderów najwyższego poziomu.
Serwer plików z wieloma udziałami i/lub woluminami do wielu udziałów plików platformy Azure w ramach jednego konta magazynu (mapowanie udziału 1:1) Tak Pojedyncze wystąpienie systemu Windows Server (lub klaster) może synchronizować maksymalnie 30 udziałów plików Azure.

Konto magazynu jest elementem umożliwiającym skalowanie wydajności. Liczba operacji we/wy na sekundę i przepustowość są współdzielone między udziałami plików.

Zachowaj liczbę elementów na grupę synchronizacji w granicach 100 milionów elementów (plików i folderów) na zasób udostępniony. Najlepiej pozostać poniżej 20 lub 30 milionów na akcję.		 1) Użyj wielu grup synchronizacji (liczba grup synchronizacji równa się liczbie udostępnionych plików na platformie Azure do synchronizacji).
2) W tym scenariuszu można zsynchronizować tylko 30 udziałów. Jeśli masz więcej niż 30 udziałów na tym serwerze plików, użyj grupowania udziałów i synchronizacji woluminów, aby zmniejszyć liczbę folderów głównych lub najwyższego poziomu w źródle.
3) Skorzystaj z dodatkowych serwerów Azure File Sync w środowisku lokalnym i podziel lub przenieś dane na te serwery, aby ominąć ograniczenia narzucone przez źródłowe wystąpienie systemu Windows Server.
Serwer plików z wieloma udziałami i/lub woluminami do wielu udziałów plików platformy Azure w ramach innego konta magazynu (mapowanie udziału 1:1) Tak Pojedyncza instancja Windows Server (lub klaster) może synchronizować maksymalnie 30 udziałów plików Azure (tego samego lub innego konta magazynu).

Zachowaj liczbę elementów na grupę synchronizacji w obrębie 100 milionów elementów (plików i folderów) na udział. Najlepiej pozostać poniżej 20 lub 30 milionów na akcję.		 Tak samo jak w przypadku poprzedniego podejścia.
Wiele serwerów plików z jednym woluminem głównym lub udziałem w tym samym docelowym udziale plików platformy Azure (konsolidacja) Nie. Grupa synchronizacji nie może używać punktu końcowego w chmurze (udziału plików platformy Azure), który jest już skonfigurowany w innej grupie synchronizacji.

Mimo że grupa synchronizacji może mieć punkty końcowe serwera na różnych serwerach plików, pliki nie mogą być odrębne.		 Postępuj zgodnie ze wskazówkami w pierwszym scenariuszu, z dodatkowym uwzględnieniem, aby koncentrować się na jednym serwerze plików naraz.
Topologia międzydzierżawowa (z wykorzystaniem tożsamości zarządzanej między dzierżawami) Nie. Usługa synchronizacji magazynu, zasób serwera (serwer z włączonym Azure Arc lub maszyna wirtualna Azure), tożsamość zarządzana i przypisania RBAC na koncie magazynu muszą znajdować się w tej samej dzierżawie Microsoft Entra. Topologie między tenancjami nie są obsługiwane. Ustawienia między dzierżawcami kończą się niepowodzeniem próby uwierzytelnienia i autoryzacji, a serwer nie może ustanowić połączenia. Aby kontynuować, upewnij się, że wszystkie zasoby (usługa synchronizacji, serwer, zarządzana tożsamość oraz przypisania RBAC) zostały utworzone w tej samej dzierżawie Microsoft Entra.

Tworzenie tabeli mapowania

Diagram przedstawiający przykład tabeli mapowania. Pobierz następujący plik, aby zapoznać się z treścią tego obrazu.

Użyj wcześniejszych informacji, aby określić, ile udziałów plików Azure potrzebujesz i które części istniejących danych trafią do którego udziału plików Azure.

Utwórz tabelę, która rejestruje myśli, aby można było odwoływać się do niej w razie potrzeby. Utrzymanie organizacji jest ważne, ponieważ utrata szczegółów planu mapowania może się zdarzyć łatwo, gdy aprowizujesz wiele zasobów platformy Azure jednocześnie.

Zagadnienia dotyczące serwerów plików systemu Windows

Aby włączyć funkcję synchronizacji w systemie Windows Server, należy zainstalować agenta do pobrania usługi Azure File Sync. Agent usługi Azure File Sync udostępnia dwa główne składniki:

  • FileSyncSvc.exe, usługa w tle systemu Windows odpowiedzialna za monitorowanie zmian w punktach końcowych serwera i inicjowanie sesji synchronizacji
  • StorageSync.sys, filtr systemu plików, który umożliwia warstwowanie chmurowe i szybkie odzyskiwanie po awarii

Wymagania dotyczące systemu operacyjnego

Usługa Azure File Sync jest obsługiwana w następujących wersjach systemu Windows Server:

Wersja Wersja RTM Obsługiwane wersje Obsługiwane opcje wdrażania
Windows Server 2025 26100 Azure, Datacenter, Essentials, Standard i IoT Pełne i podstawowe
Windows Server 2022 20348 Azure, Datacenter, Essentials, Standard i IoT Pełne i podstawowe
Windows Server 2019 17763 Datacenter, Podstawowa, Standard, i IoT Pełne i podstawowe
Windows Server 2016 14393 Datacenter, Essentials, Standard i Storage Server Pełne i podstawowe

Zalecamy aktualizowanie wszystkich serwerów używanych z usługą Azure File Sync z najnowszymi aktualizacjami usługi Windows Update.

Minimalne zasoby systemowe

Usługa Azure File Sync wymaga serwera fizycznego lub wirtualnego ze wszystkimi następującymi atrybutami:

  • Co najmniej jeden CPU.
  • Co najmniej 2 GiB pamięci. Jeśli serwer jest uruchomiony na maszynie wirtualnej z włączoną pamięcią dynamiczną, skonfiguruj maszynę wirtualną z co najmniej 2048 MiB pamięci.
  • Wolumin dołączony lokalnie sformatowany przy użyciu systemu plików NTFS.

W przypadku większości obciążeń produkcyjnych nie zalecamy konfigurowania serwera synchronizacji w usłudze Azure File Sync tylko z minimalnymi wymaganiami.

Podobnie jak każda funkcja serwera lub aplikacja, skala wdrożenia określa wymagania dotyczące zasobów systemowych dla usługi Azure File Sync. Większe wdrożenia na serwerze wymagają większych zasobów systemowych.

W przypadku usługi Azure File Sync liczba obiektów w punktach końcowych serwera i współczynnik zmian w zestawie danych określa skalę. Pojedynczy serwer może mieć punkty końcowe serwera w wielu grupach synchronizacji. Liczba obiektów wymienionych w poniższej tabeli oznacza pełną przestrzeń nazw dołączoną do serwera.

Na przykład punkt końcowy serwera A z 10 milionami obiektów i punktem końcowym serwera B z 10 milionami obiektów = 20 milionów obiektów. Na potrzeby tego przykładowego wdrożenia zalecamy użycie 8 procesorów CPU, 16 GiB pamięci w celu zapewnienia stałego stanu i (jeśli to możliwe) 48 GiB pamięci na potrzeby wstępnej migracji.

Dla zwiększenia wydajności dane przestrzeni nazw są przechowywane w pamięci. Ze względu na tę konfigurację większe przestrzenie nazw wymagają większej ilości pamięci, aby zachować dobrą wydajność. Więcej rotacji wymaga więcej procesorów.

Poniższa tabela przedstawia zarówno rozmiar przestrzeni nazw, jak i konwersję na pojemność dla typowych udziałów plików do ogólnego użytku, gdzie średni rozmiar pliku wynosi 512 KiB. Jeśli rozmiary plików są mniejsze, rozważ dodanie większej ilości pamięci dla tej samej pojemności. Konfiguracja pamięci powinna bazować na rozmiarze przestrzeni nazw.

Rozmiar przestrzeni nazw — pliki i katalogi (miliony) Typowa pojemność (TiB) Rdzenie procesora Zalecana pamięć (GiB)
3 1.4 2 8 (synchronizacja początkowa)/2 (typowy współczynnik zmian danych)
5 2.3 2 16 (synchronizacja początkowa)/4 (typowy współczynnik zmian danych)
10 4.7 4 32 (synchronizacja początkowa)/8 (typowy współczynnik zmian danych)
30 14,0 8 48 (synchronizacja początkowa)/16 (typowy współczynnik zmian danych)
50 23,3 16 64 (synchronizacja początkowa)/32 (typowy współczynnik zmian danych)
100* 46,6 32 128 (synchronizacja początkowa)/32 (typowy współczynnik zmian danych)

*Synchronizacja ponad 100 milionów plików i katalogów nie jest zalecana. Jest to miękki limit oparty na naszych przetestowanych progach. Aby uzyskać więcej informacji, zobacz Cele skalowania usługi Azure File Sync.

Wskazówka

Początkowa synchronizacja przestrzeni nazw to intensywna operacja. Zalecamy przydzielanie większej ilości pamięci do momentu ukończenia synchronizacji początkowej. Takie podejście nie jest wymagane, ale może przyspieszyć synchronizację początkową.

Typowa rotacja to zmiana 0,5% przestrzeni nazw dziennie. W przypadku wyższych poziomów współczynnika zmian rozważ dodanie większej liczby CPU.

Polecenie cmdlet oceniające

Przed wdrożeniem usługi Azure File Sync należy ocenić, czy jest ona zgodna z systemem przy użyciu polecenia cmdlet oceny usługi Azure File Sync. To cmdlet sprawdza potencjalne problemy z systemem plików i zestawem danych, takie jak nieobsługiwane znaki lub nieobsługiwana wersja systemu operacyjnego. Te testy obejmują większość (ale nie wszystkie) funkcji wymienionych w tym artykule. Zalecamy dokładne zapoznanie się z resztą tej sekcji, aby upewnić się, że wdrożenie przebiega bezproblemowo.

Polecenie cmdlet ewaluacji można zainstalować, instalując moduł PowerShell Az. Aby uzyskać instrukcje, zobacz Instalowanie programu Azure PowerShell.

Użycie

Narzędzie do oceny można wywołać, wykonując kontrole systemu, sprawdzanie zestawu danych lub oba te elementy. Aby wykonać testy systemu i zestawu danych:

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

Aby przetestować tylko zestaw danych:

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

Aby przetestować tylko wymagania systemowe:

Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name> -SkipNamespaceChecks

Aby wyświetlić wyniki w pliku .csv:

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

Zgodność systemu plików

Usługa Azure File Sync jest obsługiwana tylko na bezpośrednio dołączonych woluminach NTFS. Pamięć bezpośrednio podłączona (DAS) w systemie Windows Server oznacza, że system operacyjny Windows Server zarządza systemem plików. Można zapewnić DAS przez fizyczne podłączanie dysków do serwera plików, podłączanie dysków wirtualnych do maszyny wirtualnej serwera plików (takiej jak maszyna wirtualna hostowana przez Hyper-V), a nawet przy użyciu interfejsu iSCSI.

Obsługiwane są tylko woluminy NTFS. Systemy plików ReFS, FAT, FAT32 i inne systemy plików nie są obsługiwane.

W poniższej tabeli przedstawiono stan współdziałania funkcji systemu plików NTFS:

Funkcja Stan wsparcia Uwagi
Listy kontroli dostępu (ACL) W pełni wspierane Usługa Azure File Sync zachowuje uznaniowe listy ACL w stylu systemu Windows. System Windows Server wymusza te listy ACL w punktach końcowych serwera. Listy ACL można również wymusić podczas bezpośredniego instalowania udziału plików platformy Azure, ale ta metoda wymaga dodatkowej konfiguracji. Aby uzyskać więcej informacji, zobacz sekcję Tożsamość w dalszej części tego artykułu.
Łącza stałe Pominięty
Łącza symboliczne Pominięty
Punkty montowania Częściowo obsługiwane Punkty instalacji mogą być katalogiem głównym punktu końcowego serwera, ale są pomijane, jeśli przestrzeń nazw punktu końcowego serwera je zawiera.
Skrzyżowania Pominięty Przykłady to rozproszony system plików (DFS) DfrsrPrivate i DFSRoots foldery.
Punkty ponownej analizy Pominięty
Kompresja NTFS Częściowo obsługiwane Usługa Azure File Sync nie obsługuje punktów końcowych serwera znajdujących się na woluminie, który kompresuje katalog informacji o woluminie systemowym (SVI).
Pliki rozrzedłe W pełni wspierane Synchronizacja plików rozrzednych (nie są blokowane), ale są one synchronizowane z chmurą jako pełny plik. Jeśli zawartość pliku zmieni się w chmurze (lub na innym serwerze), plik nie będzie już rozrzedzony po pobraniu zmiany.
Alternatywne strumienie danych (ADS) Zachowane, ale nie zsynchronizowane Na przykład tagi klasyfikacji tworzone przez infrastrukturę klasyfikacji plików nie są synchronizowane. Istniejące tagi klasyfikacji plików w każdym z punktów końcowych serwera są nietknięte.

Uwaga

Kompresja NTFS z obsługą warstw w chmurze

Użycie kompresji NTFS w plikach warstwowych może spowodować znaczący wpływ na wydajność. Zaleca się, aby nie używać wartwowania w chmurze ze skompresowanymi plikami.

Jeśli skompresowane pliki zostały już podzielone na warstwy, muszą zostać zdekompresowane po przywróceniu danych z chmury, wykonując polecenie:

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

Użycie kompresji NTFS w plikach warstwowych może spowodować znaczący wpływ na wydajność. Zaleca się, aby nie używać wartwowania w chmurze ze skompresowanymi plikami.

Pliki można rozpakować za pomocą polecenia compact.

W systemie Windows Server 2019 lub nowszym polecenie compact pomija pliki hierarchiczne, więc najpierw należy przywrócić plik do lokalnego dostępu, zanim zostanie zdekompresowany.

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

Jeśli wycofanie pliku prowadzi do problemów z małą ilością miejsca na dysku, należy poczekać na rozpoczęcie działania mechanizmu warstwowego w tle i przywrócić plik do wyższej warstwy przed wycofaniem większej liczby plików lub przywrócić plik do wyższej warstwy po rozpakowaniu, uruchamiając polecenie cmdlet.

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

Usługa Azure File Sync pomija również niektóre pliki tymczasowe i foldery systemowe:

Plik/katalog Uwaga
pagefile.sys Plik specyficzny dla systemu
Desktop.ini Plik specyficzny dla systemu
thumbs.db plik tymczasowy dla miniatur
ehthumbs.db Plik tymczasowy miniatur multimediów
~$*.* plik tymczasowy pakietu Office
*.tmp plik tymczasowy
*.laccdb Uzyskiwanie dostępu do pliku blokowania bazy danych
635D02A9D91C401B97884B82B3BCDAEA.* plik synchronizacji wewnętrznej
\System Volume Information Folder specyficzny dla określonego woluminu
$RECYCLE.BIN Folder
\SyncShareState folder do synchronizacji
.SystemShareInformation Folder do synchronizacji w udziale plików platformy Azure

Uwaga

Mimo że usługa Azure File Sync obsługuje synchronizowanie plików bazy danych, bazy danych nie są dobrym obciążeniem dla rozwiązań synchronizacji (w tym usługi Azure File Sync). Pliki dziennika i bazy danych muszą być synchronizowane razem i mogą one wyjść z synchronizacji z różnych powodów, które mogą prowadzić do uszkodzenia bazy danych.

Wolne miejsce na dysku lokalnym

Podczas planowania korzystania z usługi Azure File Sync należy wziąć pod uwagę ilość wolnego miejsca potrzebnego na dysku lokalnym dla punktu końcowego serwera.

W usłudze Azure File Sync należy uwzględnić następujące elementy, które zajmują miejsce na dysku lokalnym:

  • Po włączeniu tieringu w chmurze:

    • Punkty ponownego analizowania dla plików stopniowanych
    • Baza danych metadanych usługi Azure File Sync
    • Magazyn tymczasowy usługi Azure File Sync
    • W pełni pobrane pliki w gorącej pamięci podręcznej (jeśli istnieją)
    • Wymagania polityki dotyczące wolnego miejsca na woluminie

  • Gdy warstwowanie w chmurze jest wyłączone:

    • W pełni pobrane pliki
    • Magazyn tymczasowy usługi Azure File Sync
    • Baza danych metadanych usługi Azure File Sync

W poniższym przykładzie pokazano, jak oszacować ilość wolnego miejsca potrzebnego na dysku lokalnym. Załóżmy, że na maszynie wirtualnej z systemem Windows platformy Azure zainstalowano agenta usługi Azure File Sync i planujesz utworzyć punkt końcowy serwera na dysku F. Masz 1 milion plików (i chcesz umieścić wszystkie z nich w warstwie), 100 000 katalogów i rozmiar klastra dysku o rozmiarze 4 KiB. Rozmiar dysku to 1000 GiB. Chcesz włączyć tiering w chmurze i ustawić politykę wolnej przestrzeni na woluminie na 20%.

  • System plików NTFS przydziela rozmiar klastra dla każdego z plików warstwowych:

    1 milion plików * 4 KiB rozmiar klastra = 4 000 000 KiB (4 GiB)

    Aby w pełni korzystać z obsługi warstw w chmurze, zalecamy użycie mniejszych rozmiarów klastrów NTFS (mniej niż 64 KiB), ponieważ każdy plik warstwowy zajmuje klaster. Ponadto system plików NTFS przydziela miejsce zajmowane przez pliki o wielopoziomowym dostępie. To miejsce nie jest wyświetlane w żadnym interfejsie użytkownika.

  • Metadane synchronizacji zajmują przestrzeń o wielkości klastra dla każdego elementu.

    (1 milion plików + 100 000 katalogów) * 4 Rozmiar klastra KiB = 4400 000 KiB (4,4 GiB)

  • Azure File Sync heatstore zajmuje 1,1 KiB na plik:

    1 milion plików * 1,1 KiB = 1,100,000 KiB (1.1 GiB)

  • Zasady wolnego miejsca na woluminie wynoszą 20%.

    1000 GiB * 0,2 = 200 GiB

W takim przypadku usługa Azure File Sync potrzebuje około 209 500 000 KiB (209,5 GiB) miejsca dla tej przestrzeni nazw. Dodaj tę ilość do dowolnego wolnego miejsca, które według ciebie może być potrzebne na tym dysku.

Klaster awaryjny

Usługa Azure File Sync obsługuje klaster Windows Server w trybie failover dla opcji wdrożenia serwera plików do ogólnego użytku. Aby uzyskać więcej informacji na temat konfigurowania serwera plików do ogólnych zastosowań w klastrze awaryjnego przełączania, zobacz Wdrażanie klastrowanego serwera plików z dwoma węzłami.

Jedynym scenariuszem obsługiwanym przez usługę Azure File Sync jest klaster przełączania awaryjnego Windows Server z dyskami klastrowymi. Klaster trybu failover nie jest obsługiwany na serwerze plików Scale-Out, udostępnionych woluminach klastra (CSV) ani dyskach lokalnych.

Aby synchronizacja działała prawidłowo, agent usługi Azure File Sync musi być zainstalowany w każdym węźle w klastrze trybu failover.

Deduplikacja danych

Windows Server 2025, Windows Server 2022, Windows Server 2019 i Windows Server 2016

Deduplikacja danych jest obsługiwana niezależnie od tego, czy obsługa warstw w chmurze jest włączona, czy wyłączona w co najmniej jednym punkcie końcowym serwera na woluminie dla systemu Windows Server 2025, Windows Server 2022, Windows Server 2019 i Windows Server 2016. Włączenie deduplikacji danych na woluminie z włączoną obsługą warstwowania w chmurze umożliwia buforowanie większej liczby plików na miejscu bez rezerwacji dodatkowego miejsca na magazyn.

Po włączeniu deduplikacji danych na woluminie z włączoną obsługą warstw w chmurze, pliki zoptymalizowane dla deduplikacji w lokalizacji punktu końcowego serwera są przenoszone między warstwy w podobny sposób jak normalne pliki, na podstawie ustawień zasad obsługi warstw w chmurze. Po dokonaniu warstwowania plików zoptymalizowanych pod kątem deduplikacji, zadanie oczyszczania zbędnych danych deduplikacji jest uruchamiane automatycznie. Odzyskuje miejsce na dysku, usuwając niepotrzebne fragmenty, do których nie odwołują się już inne pliki na woluminie.

W niektórych przypadkach, gdy zainstalowana jest deduplikacja danych, dostępne miejsce na woluminie może wzrosnąć bardziej niż oczekiwano po uruchomieniu zbierania śmieci deduplikacji. W poniższym przykładzie opisano działanie przestrzeni woluminu.

  1. Polityka wolnego miejsca dla segmentacji pamięci chmurowej ustawiono na 20%.
  2. Usługa Azure File Sync jest powiadamiana, gdy wolna przestrzeń jest niewystarczająca (powiedzmy 19%).
  3. Tierowanie określa, że 1% więcej miejsca należy zwolnić, ale chcesz mieć dodatkowe 5%, więc tierujesz do 25% (na przykład 30 GiB).
  4. Pliki są warstwowe, dopóki nie osiągniesz 30 GiB.
  5. W ramach współdziałania z deduplikacją danych usługa Azure File Sync inicjuje zbieranie śmieci na końcu sesji warstwowania.

Oszczędności z tytułu wolumenu dotyczą wyłącznie serwera. Dane w udziale plików platformy Azure nie są deduplikowane.

Uwaga

Aby obsługiwać deduplikację danych na woluminach z włączonym warstwowaniem w chmurze w systemie Windows Server 2019, należy zainstalować aktualizację systemu Windows KB4520062 — październik 2019 lub późniejszą miesięczną aktualizację zbiorczą.

Windows Server 2012 R2

Usługa Azure File Sync nie obsługuje deduplikacji danych i umieszczania w chmurze na jednym woluminie w systemie Windows Server 2012 R2. Jeśli włączysz deduplikację danych na woluminie, musisz wyłączyć tiering w chmurze.

Uwagi

  • W przypadku zainstalowania deduplikacji danych przed zainstalowaniem agenta usługi Azure File Sync wymagane jest ponowne uruchomienie w celu obsługi deduplikacji danych i obsługi warstw w chmurze na tym samym woluminie.

  • Jeśli włączysz deduplikację danych na woluminie po włączeniu obsługi warstw w chmurze, początkowe zadanie optymalizacji deduplikacji optymalizuje pliki na woluminie, który nie jest jeszcze warstwowy. To zadanie ma następujący wpływ na klasyfikację w chmurze:

    • Polityka zarządzania wolnym miejscem nadal ustawia pliki w warstwy zgodnie z wolnym miejscem w danym woluminie przy użyciu mapy cieplnej.
    • Polityka dotycząca dat pomija podział na warstwy plików, które mogłyby być zakwalifikowane do tej operacji, ponieważ zadanie optymalizacji deduplikacji uzyskuje dostęp do plików.

  • W przypadku bieżących zadań optymalizacji deduplikacji, ustawienie MinimumFileAgeDays opóźnia tiering w chmurze przy użyciu polityki danych, jeśli plik nie został jeszcze przydzielony do warstwy.

    • Na przykład, jeśli ustawienie MinimumFileAgeDays wynosi 7 dni, a polityka danych dotycząca tieringu w chmurze to 30 dni, pliki są przenoszone do wyższej warstwy po 37 dniach.
    • Po przeprowadzeniu przez usługę Azure File Sync klasyfikacji pliku, zadanie optymalizacji deduplikacji pomija plik.

  • Jeśli serwer z systemem Windows Server 2012 R2 z zainstalowanym agentem usługi Azure File Sync zostanie uaktualniony do systemu Windows Server 2025, Windows Server 2022, Windows Server 2019 lub Windows Server 2016, należy wykonać następujące kroki, aby obsługiwać deduplikację danych i obsługę warstw w chmurze na tym samym woluminie:

    1. Odinstaluj agenta usługi Azure File Sync dla systemu Windows Server 2012 R2 i uruchom ponownie serwer.
    2. Pobierz agenta usługi Azure File Sync dla nowej wersji systemu operacyjnego serwera (Windows Server 2025, Windows Server 2022, Windows Server 2019 lub Windows Server 2016).
    3. Zainstaluj agenta usługi Azure File Sync i uruchom ponownie serwer.

    Serwer zachowuje ustawienia konfiguracji usługi Azure File Sync po odinstalowaniu i ponownym zainstalowaniu agenta.

rozproszony system plików

Usługa Azure File Sync obsługuje współdziałanie z przestrzeniami nazw systemu plików DFS (DFS-N) i replikacją systemu plików DFS (DFS-R).

DFS-N

Usługa Azure File Sync jest w pełni obsługiwana z implementacją DFS-N. Agent usługi Azure File Sync można zainstalować na co najmniej jednym serwerze plików, aby zsynchronizować dane między punktami końcowymi serwera a punktem końcowym w chmurze, a następnie użyć systemu plików DFS-N, aby zapewnić usługę przestrzeni nazw. Aby uzyskać więcej informacji, zobacz Omówienie przestrzeni nazw systemu plików DFS i Przestrzenie nazw systemu plików DFS w usłudze Azure Files.

DFS-R

Ponieważ DFS-R i Azure File Sync to rozwiązania replikacji, w większości przypadków zalecamy zastąpienie DFS-R usługą Azure File Sync. Należy jednak używać DFS-R i usługi Azure File Sync razem w następujących scenariuszach:

  • Przeprowadzasz migrację z wdrożenia systemu plików DFS-R do wdrożenia usługi Azure File Sync. Aby uzyskać więcej informacji, zobacz Migrowanie wdrożenia DFS-R do usługi Azure File Sync.
  • Nie każdy serwer lokalny, który wymaga kopii danych plików, może być połączony bezpośrednio z Internetem.
  • Serwery oddziałów konsolidują dane do jednego serwera centralnego, dla którego chcesz użyć Azure File Sync.

Aby usługi Azure File Sync i DFS-R działały obok siebie:

  • Warstwowanie w chmurze usługi Azure File Sync musi być wyłączone na woluminach z folderami replikowanymi w usłudze DFS-R.
  • Punkty końcowe serwera nie powinny być konfigurowane na folderach replikacji tylko do odczytu DFS-R.
  • Tylko pojedynczy punkt końcowy serwera może nakładać się na lokalizację systemu plików DFS-R. Wiele punktów końcowych serwera nakładających się na inne aktywne lokalizacje systemu plików DFS-R może prowadzić do konfliktów.

Aby uzyskać więcej informacji, zobacz Omówienie przestrzeni nazw systemu plików DFS i replikacji systemu plików DFS.

Sysprep

Korzystanie z narzędzia Sysprep na serwerze z zainstalowanym agentem usługi Azure File Sync nie jest obsługiwane i może prowadzić do nieoczekiwanych wyników. Instalacja agenta i rejestracja serwera powinny zostać wykonane po wdrożeniu obrazu serwera i zakończeniu mini-konfiguracji Sysprep.

Jeśli obsługa warstw w chmurze jest włączona w punkcie końcowym serwera, usługa Windows Search pomija pliki warstwowe i nie indeksuje ich. Usługa Windows Search prawidłowo indeksuje pliki, które nie są segmentowane na warstwy.

Klienci Windows powodują przypomnienia podczas wyszukiwania w zasobie plików, jeśli na komputerze klienta aktywowane jest ustawienie Zawsze wyszukuj nazwy plików i zawartość. To ustawienie jest domyślnie wyłączone.

Inne rozwiązania HSM

W usłudze Azure File Sync nie należy używać żadnych innych rozwiązań do zarządzania magazynem hierarchicznym (HSM).

Wydajność i skalowalność   

Ponieważ agent usługi Azure File Sync działa na maszynie z systemem Windows Server, która łączy się z udziałami plików platformy Azure, efektywna wydajność synchronizacji zależy od tych czynników w infrastrukturze:

  • Windows Server i podstawowa konfiguracja dysku
  • Przepustowość sieci między serwerem a usługą Azure Storage
  • Rozmiar pliku
  • Całkowity rozmiar zestawu danych
  • Działanie w zestawie danych

Usługa Azure File Sync działa na poziomie pliku. Charakterystyka wydajności rozwiązania opartego na usłudze Azure File Sync jest lepiej mierzona w liczbie obiektów (plików i katalogów) przetwarzanych na sekundę.

Aby uzyskać więcej informacji, zobacz Metryki wydajności usługi Azure File Sync i cele skalowania usługi Azure File Sync

Tożsamość

Administrator rejestrujący serwer i tworzący punkt końcowy w chmurze musi być członkiem roli zarządzania Azure File Sync Administrator, właścicielem lub współpracownikiem usługi synchronizacji magazynu. Możesz skonfigurować tę rolę w obszarze Kontrola dostępu (IAM) na stronie Azure Portal dla usługi synchronizacji magazynu.

Podczas przypisywania roli administratora usługi Azure File Sync wykonaj następujące kroki, aby zapewnić najmniejsze uprawnienia.

  1. Na karcie Warunki wybierz opcję Zezwalaj użytkownikom na przypisywanie wybranych ról tylko do wybranych administratorów (z mniejszymi uprawnieniami).

  2. Kliknij Wybierz role i podmioty, a następnie wybierz Dodaj akcję w Warunku 1.

  3. Wybierz Utwórz przypisanie roli, a następnie kliknij Wybierz.

  4. Wybierz pozycję Dodaj wyrażenie, a następnie wybierz pozycję Żądanie.

  5. W obszarze Źródło atrybutu wybierz pozycję Identyfikator definicji roli w obszarze Atrybut, a następnie wybierz pozycję ForAnyOfAnyValues:GuidEquals w obszarze Operator.

  6. Wybierz Dodaj role. Dodaj role Czytelnik danych, Współautor danych plików magazynu i Współautor konta magazynu, a następnie wybierz pozycję Zapisz.

Usługa Azure File Sync współpracuje ze standardową tożsamością opartą na usłudze Active Directory bez żadnej specjalnej konfiguracji poza konfigurowaniem synchronizacji. W przypadku korzystania z usługi Azure File Sync ogólne oczekiwania polegają na tym, że większość dostępu przechodzi przez serwery buforowania usługi Azure File Sync, a nie za pośrednictwem udziału plików platformy Azure. Ponieważ punkty końcowe serwera znajdują się w systemie Windows Server, a system ten obsługuje usługi Active Directory i listy ACL w stylu Windows, wystarczy jedynie zapewnić, że serwery plików Windows zarejestrowane w usłudze synchronizacji magazynu są przyłączone do domeny. Usługa Azure File Sync przechowuje listy ACL w plikach w udziale plików platformy Azure i replikuje te listy ACL do wszystkich punktów końcowych serwera.

Nawet jeśli zmiany wprowadzone bezpośrednio w dysku sieciowym Azure mogą zająć więcej czasu na synchronizację z punktami końcowymi serwera w grupie synchronizacji, warto również zadbać o możliwość wymuszenia uprawnień Active Directory bezpośrednio w chmurze na dysku sieciowym. Aby wykonać tę konfigurację, musisz dołączyć konto Storage do lokalnego wystąpienia usługi Active Directory, tak jak do domeny są przyłączone serwery plików Windows. Aby dowiedzieć się więcej o przyłączaniu konta magazynu do domeny usługi Active Directory należącej do klienta, zobacz Omówienie uwierzytelniania opartego na tożsamości usługi Azure Files na potrzeby dostępu za pomocą protokołu SMB.

Ważne

Łączenie konta magazynu do domeny Active Directory nie jest wymagane do pomyślnego wdrożenia usługi Azure File Sync. Jest to opcjonalny krok, który umożliwia udziałowi plików Azure egzekwowanie lokalnych list ACL, gdy użytkownicy bezpośrednio zamontują udział plików Azure.

Networks

Agent usługi Azure File Sync komunikuje się z usługą synchronizacji plików i udziałem plików platformy Azure przy użyciu protokołu REST Azure File Sync i protokołu FileREST. Oba te protokoły zawsze używają protokołu HTTPS przez port 443. Protokół SMB nigdy nie jest używany do przesyłania lub ściągania danych między wystąpieniem systemu Windows Server i udziałem plików usługi Azure. Ponieważ większość organizacji zezwala na ruch HTTPS przez port 443 jako wymóg odwiedzania większości witryn internetowych, specjalna konfiguracja sieci zwykle nie jest wymagana do wdrożenia usługi Azure File Sync.

Ważne

Funkcja Azure File Sync nie obsługuje routingu internetowego. Usługa Azure File Sync obsługuje domyślną opcję routingu sieciowego, routing firmy Microsoft.

Na podstawie zasad organizacji lub unikatowych wymagań prawnych może być wymagana bardziej restrykcyjna komunikacja z platformą Azure. Usługa Azure File Sync udostępnia kilka mechanizmów konfigurowania sieci. Na podstawie wymagań można wykonywać następujące czynności:

  • Synchronizacja tunelu i przekazywanie/pobieranie ruchu za pośrednictwem usługi Azure ExpressRoute lub wirtualnej sieci prywatnej platformy Azure (VPN).
  • Korzystaj z funkcji usługi Azure Files i sieci platformy Azure, takich jak punkty końcowe usługi i prywatne punkty końcowe.
  • Skonfiguruj usługę Azure File Sync, aby obsługiwać serwer proxy w danym środowisku.
  • Ogranicz aktywność sieciową z usługi Azure File Sync.

Jeśli chcesz komunikować się z udziałem plików platformy Azure za pośrednictwem protokołu SMB, ale port 445 jest zablokowany, rozważ użycie SMB przez QUIC. Ta metoda oferuje VPN bez konieczności konfiguracji, umożliwiając dostęp SMB do udostępnionych zasobów plikowych na platformie Azure za pośrednictwem protokołu transportowego QUIC przez port 443. Chociaż Azure Files nie obsługuje bezpośrednio protokołu SMB za pośrednictwem QUIC, możesz utworzyć uproszczoną pamięć podręczną udziałów plików Azure na maszynie wirtualnej z systemem Windows Server 2022 Azure Edition, korzystając z usługi Azure File Sync. Aby dowiedzieć się więcej na temat tej opcji, zobacz protokół SMB over QUIC.

Aby dowiedzieć się więcej o usłudze Azure File Sync i sieciach, zobacz Zagadnienia dotyczące sieci dla usługi Azure File Sync.

Szyfrowanie

Usługa Azure File Sync oferuje trzy warstwy szyfrowania: szyfrowanie danych w spoczynku na Windows Server, szyfrowanie podczas przesyłania między agentem Azure File Sync a platformą Azure oraz szyfrowanie danych przechowywanych w udziale plików Azure.

Szyfrowanie danych w spoczynku w systemie Windows Server

Dwie strategie szyfrowania danych w systemie Windows Server działają ogólnie z usługą Azure File Sync:

  • Szyfrowanie pod systemem plików, tak aby system plików i wszystkie zapisane w nim dane zostały zaszyfrowane
  • Szyfrowanie w samym formacie pliku

Te metody nie wykluczają się wzajemnie. Możesz użyć ich razem, ponieważ cel szyfrowania jest inny.

Aby zapewnić szyfrowanie pod systemem plików, system Windows Server udostępnia skrzynkę odbiorczą funkcji BitLocker. Funkcja BitLocker jest w pełni niewidoczna dla usługi Azure File Sync. Podstawowymi przyczynami korzystania z mechanizmu szyfrowania, takiego jak funkcja BitLocker, są:

  • Zapobiegaj fizycznej eksfiltracji danych z lokalnego centrum danych przez kogoś kradnącego dyski.
  • Uniemożliwienie ładowania nieautoryzowanego systemu operacyjnego w celu wykonywania nieautoryzowanych operacji odczytu i zapisu danych

Aby dowiedzieć się więcej, zobacz Omówienie funkcji BitLocker.

Produkty partnerskie, które działają podobnie do funkcji BitLocker, czyli znajdują się poniżej woluminu NTFS, powinny działać całkowicie i transparentnie z usługą Azure File Sync.

Drugą główną metodą szyfrowania danych jest szyfrowanie strumienia danych pliku podczas zapisywania pliku przez aplikację. Niektóre aplikacje mogą wykonywać to zadanie natywnie, ale zwykle nie.

Przykładowe metody szyfrowania strumienia danych pliku to Azure Information Protection, Azure Rights Management (Azure RMS) i Active Directory Rights Management Services. Głównym powodem korzystania z mechanizmu szyfrowania, takiego jak Azure Information Protection lub Azure RMS, jest zapobieganie eksfiltracji danych z udziału plików przez osoby, które kopiują je do alternatywnych lokalizacji (takich jak dysk flash) lub wysyłając je pocztą e-mail do nieautoryzowanej osoby. Gdy strumień danych pliku jest zaszyfrowany w ramach formatu pliku, ten plik będzie nadal szyfrowany w udziale plików platformy Azure.

Usługa Azure File Sync nie współdziała z systemem plików NTFS Encrypted ani rozwiązaniami szyfrowania partnerów, które znajdują się nad systemem plików, ale poniżej strumienia danych pliku.

Szyfrowanie podczas transferu

Agent usługi Azure File Sync komunikuje się z usługą synchronizacji magazynu i udziałem plików platformy Azure przy użyciu protokołu REST usługi Azure File Sync i protokołu FileREST. Oba te protokoły zawsze używają protokołu HTTPS przez port 443. Usługa Azure File Sync nie wysyła niezaszyfrowanych żądań za pośrednictwem protokołu HTTP.

Konta usługi Azure Storage zawierają przełącznik umożliwiający wymaganie szyfrowania podczas przesyłania. Ten przełącznik jest domyślnie włączony. Nawet jeśli przełącznik na poziomie konta magazynu jest wyłączony, a połączenia niezaszyfrowane z udziałami plików platformy Azure są możliwe, usługa Azure File Sync nadal używa tylko zaszyfrowanych kanałów, aby uzyskać dostęp do udziałów plików.

Głównym powodem wyłączenia szyfrowania danych w ruchu dla konta magazynu jest wsparcie starszej aplikacji, która komunikuje się bezpośrednio z udziałem plików platformy Azure. Taka aplikacja musi być uruchamiana w starszym systemie operacyjnym, takim jak Windows Server 2008 R2 lub starsza dystrybucja systemu Linux. Jeśli starsza aplikacja łączy się z pamięcią podręczną udziału plików systemu Windows Server, zmiana tego ustawienia nie ma żadnego wpływu.

Zdecydowanie zalecamy włączenie szyfrowania danych przesyłanych. Aby uzyskać więcej informacji na temat szyfrowania podczas przesyłania, zobacz Wymagaj bezpiecznego transferu w celu zapewnienia bezpiecznych połączeń.

Uwaga

Usługa Azure File Sync usunęła obsługę protokołów TLS 1.0 i 1.1 w dniu 1 sierpnia 2020 r. Wszystkie obsługiwane wersje agenta usługi Azure File Sync domyślnie używają już protokołu TLS 1.2. Być może używasz wcześniejszej wersji protokołu TLS, jeśli na serwerze wyłączono protokół TLS 1.2 lub jeśli używasz serwera proxy.

Jeśli używasz serwera proxy, zalecamy sprawdzenie konfiguracji serwera proxy. Regiony usługi Azure File Sync dodane po 1 maja 2020 r. obsługują tylko protokół TLS 1.2. Aby uzyskać więcej informacji, zobacz przewodnik rozwiązywania problemów.

Szyfrowanie udziałów plików platformy Azure w stanie spoczynku

Wszystkie dane przechowywane w usłudze Azure Files są szyfrowane w spoczynku za pomocą szyfrowania po stronie usługi Azure Storage (SSE). Funkcja SSE działa podobnie do funkcji BitLocker w systemie Windows: dane są szyfrowane poniżej poziomu systemu plików.

Ponieważ dane są szyfrowane pod systemem plików udziału plików platformy Azure, gdy są kodowane na dysku, nie musisz mieć dostępu do klucza podstawowego na kliencie, aby odczytywać lub zapisywać w udziale plików platformy Azure. Szyfrowanie danych w spoczynku dotyczy protokołów SMB i NFS.

Domyślnie dane przechowywane w usłudze Azure Files są szyfrowane przy użyciu kluczy zarządzanych przez firmę Microsoft. W przypadku kluczy zarządzanych przez firmę Microsoft firma Microsoft przechowuje klucze do szyfrowania i odszyfrowywania danych. Firma Microsoft jest odpowiedzialna za regularne obracanie tych kluczy.

Możesz również zarządzać własnymi kluczami, co zapewnia kontrolę nad procesem rotacji. Jeśli zdecydujesz się zaszyfrować udziały plików przy użyciu kluczy zarządzanych przez klienta, usługa Azure Files ma autoryzację dostępu do kluczy w celu realizacji żądań odczytu i zapisu od Twoich klientów. Za pomocą kluczy zarządzanych przez klienta można w dowolnym momencie odwołać tę autoryzację. Jednak bez tej autoryzacji ten udział plików Azure nie jest już dostępny za pośrednictwem protokołu SMB ani interfejsu API FileREST.

Usługa Azure Files używa tego samego schematu szyfrowania co inne usługi Azure Storage, takie jak Azure Blob Storage. Aby dowiedzieć się więcej na temat usługi Azure Storage SSE, zobacz Szyfrowanie usługi Azure Storage dla danych magazynowanych.

Warstwy magazynowania

Azure Files oferuje dwie warstwy pamięci masowej: dysk SSD i dysk twardy (HDD). Te warstwy umożliwiają dostosowanie udziałów do wymagań dotyczących wydajności i cen w scenariuszu:

  • SSD (premium): udziały plików SSD zapewniają spójną wysoką wydajność i niskie opóźnienia, w pojedynczych milisekundach dla większości operacji I/O, na potrzeby obciążeń intensywnego I/O. Udziały plików SSD są odpowiednie dla wielu różnych obciążeń, takich jak bazy danych, hosting witryn internetowych i środowiska programistyczne.

    Udziały plików SSD można używać zarówno z protokołami SMB, jak i NFS. Udziały plików SSD są dostępne w przydzielonych modelach rozliczeń w wersji 2 i wersji 1. Udziały plików SSD oferują wyższe SLA dostępności niż udziały plików HDD.

  • HDD (standard): Udziały plików HDD oferują opłacalną opcję przechowywania dla udziałów plików ogólnego przeznaczenia. Udziały plików HDD są dostępne w przypadku zaaprowizowanych modeli rozliczeń w wersji 2 i modelu rozliczeń z płatnością zgodnie z rzeczywistym użyciem , chociaż zalecamy aprowizowany model w wersji 2 dla nowych wdrożeń udziałów plików. Aby uzyskać informacje o umowie SLA, zobacz stronę umowy SLA platformy Azure dotyczącą usług online.

Podczas wybierania warstwy pamięci dla obciążenia roboczego należy wziąć pod uwagę wymagania dotyczące wydajności i użytkowania. Jeśli obciążenie wymaga bardzo niskiego opóźnienia lub używasz lokalnego nośnika pamięci SSD, udziały plików SSD są prawdopodobnie najlepszym rozwiązaniem. Jeśli niskie opóźnienia nie są priorytetem, udostępnianie plików na HDD może być lepszym wyborem z perspektywy kosztów. Na przykład, niska latencja może być mniej istotna w przypadku zasobów współdzielonych zespołu wdrożonych na miejscu z Azure lub buforowanych lokalnie poprzez Azure File Sync.

Po utworzeniu udziału plików na koncie magazynowym nie można bezpośrednio przenieść go do innej warstwy pamięci masowej. Aby na przykład przenieść udział plików HDD do warstwy nośników SSD, należy utworzyć nowy udział plików SSD i skopiować dane z oryginalnego udziału do nowego udziału plików.

Więcej informacji o warstwach multimediów SSD i HDD można znaleźć w temacie Omówienie modeli rozliczeń usługi Azure Files oraz Omówienie i optymalizowanie wydajności udziału plików platformy Azure.

Dostępność regionów usługi Azure File Sync

Aby uzyskać dostępność regionalną, zobacz Dostępność produktu według regionu i wyszukaj Konta magazynowe.

Następujące regiony wymagają zażądania dostępu do usługi Azure Storage przed użyciem usługi Azure File Sync:

  • Francja Południowa
  • Zachodnia Republika Południowej Afryki
  • Środkowe Zjednoczone Emiraty Arabskie

Aby zażądać dostępu do tych regionów, postępuj zgodnie z procesem w tym artykule.

Redundancja

Aby chronić dane w udziałach plików platformy Azure przed utratą lub uszkodzeniem danych, usługa Azure Files przechowuje wiele kopii każdego pliku podczas ich zapisywania. W zależności od Twoich wymagań, możesz wybrać stopień nadmiarowości. Usługa Azure Files obsługuje obecnie następujące opcje nadmiarowości danych:

  • Magazyn lokalnie nadmiarowy (LRS): w przypadku nadmiarowości lokalnej każdy plik jest przechowywany trzy razy w klastrze usługi Azure Storage. Takie podejście pomaga chronić przed utratą danych z powodu błędów sprzętowych, takich jak zły dysk. Jeśli jednak w centrum danych wystąpi awaria, taka jak pożar lub powódź, wszystkie repliki konta magazynu korzystającego z LRS mogą zostać utracone lub niemożliwe do odzyskania.

  • Magazyn strefowo nadmiarowy (ZRS): dzięki nadmiarowości strefowej przechowywane są trzy kopie każdego pliku. Jednak te kopie są fizycznie izolowane w trzech odrębnych klastrach magazynu w strefach dostępności platformy Azure. Strefy dostępności to unikatowe lokalizacje fizyczne w regionie świadczenia usługi Azure. Każda strefa składa się z co najmniej jednego centrum danych wyposażonego w niezależne zasilanie, chłodzenie i sieć. Zapis w magazynie nie jest akceptowany, dopóki nie zostanie zapisany w klastrach magazynu we wszystkich trzech strefach dostępności.

  • Magazyn geograficznie nadmiarowy (GRS): w przypadku nadmiarowości geograficznej masz region podstawowy i region pomocniczy. Pliki są przechowywane trzy razy w klastrze usługi Azure Storage w regionie podstawowym. Zapisy są asynchroniczne replikowane do regionu pomocniczego zdefiniowanego przez firmę Microsoft.

    Nadmiarowość geograficzna zapewnia sześć kopii danych rozmieszczonych między dwoma regionami świadczenia usługi Azure. Jeśli wystąpi poważna awaria, taka jak trwała utrata regionu świadczenia usługi Azure z powodu klęski żywiołowej lub innego podobnego zdarzenia, firma Microsoft wykonuje przejście w tryb failover. W takim przypadku serwer pomocniczy staje się serwerem podstawowym i obsługuje wszystkie operacje.

    Ponieważ replikacja między regionem podstawowym a pomocniczym jest asynchroniczna, w przypadku wystąpienia poważnej katastrofy dane, które nie zostały jeszcze zreplikowane do regionu pomocniczego, mogą zostać utracone. Możesz również wykonać ręczne przejście w tryb failover konta magazynu geograficznie nadmiarowego.

  • Magazyn geograficznie nadmiarowy (GZRS): w przypadku nadmiarowości strefy geograficznej pliki są przechowywane trzy razy w trzech odrębnych klastrach magazynu w regionie podstawowym. Wszystkie operacje zapisu są następnie asynchronicznie replikowane do regionu pomocniczego zdefiniowanego przez firmę Microsoft. Proces przełączania w tryb failover dla nadmiarowości strefy geograficznej działa tak samo, jak w przypadku nadmiarowości geograficznej.

Udziały plików HDD obsługują wszystkie cztery typy nadmiarowości. Udziały plików SSD obsługują tylko magazyny replikacji LRS i ZRS.

Konta magazynu z płatnością zgodnie z rzeczywistym użyciem zapewniają dwie inne opcje nadmiarowości, których usługa Azure Files nie obsługuje: magazyn geograficznie nadmiarowy z dostępem do odczytu (RA-GRS) i magazyn geograficznie-strefowo nadmiarowy z dostępem do odczytu (RA-GZRS). Udziały plików platformy Azure można aprowizować na kontach magazynu z ustawionymi tymi opcjami, jednak usługa Azure Files nie obsługuje odczytu z regionu wtórnego. Udziały plików platformy Azure wdrożone na kontach magazynowych RA-GRS lub RA-GZRS są rozliczane odpowiednio jako nadmiarowe geograficznie lub strefowo geograficznie nadmiarowe.

Ważne

Magazyn geograficznie nadmiarowy i strefowo nadmiarowy geograficznie może ręcznie przejąć magazyn w tryb failover do regionu pomocniczego. Nie zalecamy tego podejścia (poza awarią) w przypadku korzystania z usługi Azure File Sync ze względu na zwiększone prawdopodobieństwo utraty danych. Jeśli wystąpi awaria i chcesz zainicjować ręczne przełączenie awaryjne magazynu, musisz otworzyć zgłoszenie do pomocy technicznej Microsoft, aby usługa Azure File Sync wznowiła synchronizację z pomocniczym punktem końcowym.

Migracja

Jeśli masz istniejący serwer plików w systemie Windows Server 2012 R2 lub nowszym, możesz bezpośrednio zainstalować usługę Azure File Sync. Nie trzeba przenosić danych na nowy serwer.

Jeśli planujesz przeprowadzić migrację do nowego serwera plików systemu Windows w ramach wdrażania usługi Azure File Sync lub jeśli dane znajdują się obecnie na serwerze NAS, istnieje kilka możliwych podejść migracji do korzystania z usługi Azure File Sync z tych danych. Które podejście do migracji należy wybrać, zależy od tego, gdzie obecnie znajdują się twoje dane.

Aby uzyskać szczegółowe wskazówki, zobacz Migracja do udziałów plików SMB platformy Azure.

Antywirus

Ponieważ oprogramowanie antywirusowe działa przez skanowanie plików pod kątem znanego złośliwego kodu, produkt antywirusowy może spowodować wycofanie plików warstwowych i wysokich opłat za ruch wychodzący. Pliki warstwowe mają ustawiony bezpieczny atrybut systemu Windows FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS. Zalecamy skonsultowanie się z dostawcą oprogramowania, aby dowiedzieć się, jak skonfigurować jego rozwiązanie, aby pominąć odczytywanie plików, które mają ten zestaw atrybutów. Wiele robi to automatycznie.

Podczas skanowania na żądanie rozwiązania antywirusowe Microsoft Defender i System Center Endpoint Protection automatycznie pomijają odczytywanie plików z tym zestawem atrybutów. Przetestowaliśmy je i zidentyfikowaliśmy jeden drobny problem: po dodaniu serwera do istniejącej grupy synchronizacji pliki mniejsze niż 800 bajtów zostaną odwołane (pobrane) na nowym serwerze. Te pliki pozostają na nowym serwerze i nie są warstwowe, ponieważ nie spełniają wymagań dotyczących rozmiaru warstw (ponad 64 KiB).

Uwaga

Usługi Microsoft Defender i System Center Endpoint Protection pomijają odczytywanie wyłącznie podczas skanowania na żądanie. Nie dotyczy to ochrony w czasie rzeczywistym (RTP).

Dostawcy oprogramowania antywirusowego mogą sprawdzić zgodność swoich produktów i usługi Azure File Sync przy użyciu pakietu testów zgodności oprogramowania antywirusowego usługi Azure File Sync w Centrum pobierania Microsoft.

Backup

Jeśli włączysz warstwowanie w chmurze, unikaj rozwiązań, które bezpośrednio tworzą kopię zapasową punktu końcowego serwera lub maszyny wirtualnej zawierającej punkt końcowy serwera.

Warstwowanie w chmurze powoduje, że tylko podzbiór danych jest przechowywany w punkcie końcowym serwera. Pełny zestaw danych znajduje się w udziale plików platformy Azure. W zależności od używanego rozwiązania do tworzenia kopii zapasowych pliki warstwowe są następujące:

  • Pominięto i nie utworzono kopii zapasowej, ponieważ mają one ustawiony ten atrybut FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS
  • Przywrócenie na dysk, co skutkuje wysokimi opłatami za ruch wychodzący

Zalecamy użycie rozwiązania do tworzenia kopii zapasowych w chmurze, aby bezpośrednio zabezpieczać udział plików platformy Azure. Aby uzyskać więcej informacji, zobacz Informacje o kopii zapasowej usługi Azure Files. Możesz też zapytać dostawcę kopii zapasowej, czy obsługuje tworzenie kopii zapasowych udziałów plików platformy Azure.

Jeśli wolisz używać lokalnego rozwiązania do tworzenia kopii zapasowych, wykonaj kopie zapasowe na serwerze w grupie synchronizacji z wyłączoną obsługą warstw w chmurze. Upewnij się, że nie ma plików warstwowych.

Podczas przywracania użyj opcji przywracania na poziomie woluminu lub na poziomie pliku. Pliki przywrócone za pomocą opcji przywracania na poziomie pliku są synchronizowane ze wszystkimi punktami końcowymi w grupie synchronizacji. Istniejące pliki są zastępowane wersją przywróconą z kopii zapasowej. Przywracanie na poziomie woluminu nie zastępuje nowszych wersji plików w udziale plików platformy Azure lub innych punktach końcowych serwera.

Uwaga

Przywracanie systemu z poziomu bare-metal, przywracanie maszyn wirtualnych, przywracanie systemu (wbudowane przywracanie systemu operacyjnego Windows), oraz przywracanie na poziomie plików z wersjonowaniem warstwowym może spowodować nieoczekiwane wyniki. (Przywracanie na poziomie pliku odbywa się, gdy oprogramowanie kopii zapasowej wykonuje kopię zapasową pliku warstwowego zamiast pełnego pliku). Nie są obecnie obsługiwane, gdy włączone jest warstwowanie w chmurze.

Migawki usługi VSS (Kopia w tle), w tym karta Poprzednie wersje, są obsługiwane na woluminach z włączonym warstwowaniem w chmurze. Należy jednak włączyć zgodność z poprzednią wersją za pomocą programu PowerShell. Dowiedz się, jak to zrobić.

Klasyfikacja danych

Jeśli masz zainstalowane oprogramowanie do klasyfikacji danych, włączenie warstwowania danych w chmurze zwiększa koszty z dwóch powodów:

  • Po włączeniu funkcji warstwowania w chmurze, najbardziej aktywne pliki są buforowane lokalnie. Najbardziej użyteczne pliki są przenoszone do warstwy udziału plików Azure w chmurze. Jeśli klasyfikacja danych regularnie skanuje wszystkie pliki w udziale plików, pliki przeniesione do chmury muszą zostać ponownie pobrane przy każdym skanowaniu.
  • Jeśli oprogramowanie do klasyfikacji danych używa metadanych w strumieniu danych pliku, należy w pełni odwołać plik, aby oprogramowanie wykryło klasyfikację.

Te wzrosty, zarówno w liczbie odwołań, jak i ilości danych, które są odwoływane, mogą zwiększyć koszty.

Zasady aktualizacji agenta usługi Azure File Sync

Agent usługi Azure File Sync jest regularnie aktualizowany w celu dodania nowych funkcji i rozwiązania problemów. Zalecamy zaktualizowanie agenta usługi Azure File Sync, ponieważ są dostępne nowe wersje.

Wersje agentów głównych i pomocniczych

  • Główne wersje programu agenta często zawierają nowe funkcje i mają coraz wyższą liczbę jako pierwszą część numeru wersji. Na przykład: 18.0.0.0.
  • Wersje agentów pomocniczych są również nazywane poprawkami i są wydawane częściej niż wersje główne. Często zawierają poprawki błędów i mniejsze ulepszenia, ale nie są to nowe funkcje. Na przykład: 18.2.0.0.

Aktualizowanie ścieżek

Istnieje pięć zatwierdzonych i przetestowanych sposobów instalowania aktualizacji agenta usługi Azure File Sync:

  • Użyj funkcji automatycznej aktualizacji usługi Azure File Sync, aby zainstalować aktualizacje agenta: agent usługi Azure File Sync jest automatycznie aktualizowany. Możesz wybrać, aby zainstalować najnowszą wersję agenta, gdy jest dostępna lub aktualizowana, gdy aktualnie zainstalowany agent jest bliski wygaśnięcia. Aby dowiedzieć się więcej, zobacz następną sekcję Automatyczne zarządzanie cyklem życia agenta.
  • Skonfiguruj usługę Microsoft Update w celu automatycznego pobierania i instalowania aktualizacji agenta: zalecamy zainstalowanie każdej aktualizacji usługi Azure File Sync, aby upewnić się, że masz dostęp do najnowszych poprawek agenta serwera. Usługa Microsoft Update sprawia, że ten proces jest bezproblemowy przez automatyczne pobieranie i instalowanie aktualizacji.
  • Użyj AfsUpdater.exe, aby pobrać i zainstalować aktualizacje agenta: AfsUpdater.exe plik znajduje się w katalogu instalacyjnym agenta. Kliknij dwukrotnie plik wykonywalny, aby pobrać i zainstalować aktualizacje agenta. W zależności od wersji może być konieczne ponowne uruchomienie serwera.
  • Stosowanie poprawek istniejącego agenta usługi Azure File Sync przy użyciu pliku poprawki usługi Microsoft Update lub pliku wykonywalnego msp: możesz pobrać najnowszy pakiet aktualizacji usługi Azure File Sync z katalogu usługi Microsoft Update. Uruchomienie pliku wykonywalnego msp aktualizuje instalację usługi Azure File Sync przy użyciu tej samej metody, która jest używana automatycznie przez usługę Microsoft Update. Zastosowanie poprawki usługi Microsoft Update wykonuje aktualizację w miejscu instalacji usługi Azure File Sync.
  • Pobierz najnowszy instalator agenta usługi Azure File Sync: instalator można pobrać w Centrum pobierania Microsoft. Aby zaktualizować istniejącą instalację agenta usługi Azure File Sync, odinstaluj starszą wersję, a następnie zainstaluj najnowszą wersję pobranego instalatora. Ustawienia agenta (na przykład rejestracja serwera i punkty końcowe serwera) są zachowywane po odinstalowaniu agenta usługi Azure File Sync.

Uwaga

Obniżenie poziomu agenta usługi Azure File Sync nie jest obsługiwane. Nowe wersje często zawierają zmiany powodujące niezgodność, gdy są porównywane ze starymi wersjami, co sprawia, że proces zmiany na starszą wersję nie jest obsługiwany. Jeśli wystąpią jakiekolwiek problemy z bieżącą wersją agenta, skontaktuj się z pomocą techniczną lub zaktualizuj do najnowszej dostępnej wersji.

Automatyczne zarządzanie cyklem życia agenta

Agent usługi Azure File Sync jest aktualizowany automatycznie. Możesz wybrać jeden z następujących trybów i określić okno obsługi, w którym podjęto próbę aktualizacji na serwerze. Ta funkcja została zaprojektowana tak, aby ułatwić zarządzanie cyklem życia agenta, zapewniając barierę chroniącą przed wygaśnięciem agenta lub pozwalającą na bezproblemowe zachowanie bieżącego ustawienia.

  • Ustawienie domyślne próbuje zapobiec wygaśnięciu agenta. W ciągu 21 dni od wyznaczonej daty wygaśnięcia agenta agent próbuje się zaktualizować. Rozpoczyna próbę aktualizacji raz w tygodniu w ciągu 21 dni przed wygaśnięciem i w wybranym oknie obsługi. Należy pamiętać, że ta opcja nie eliminuje potrzeby stosowania regularnych poprawek usługi Microsoft Update.

  • Możesz wybrać, że agent automatycznie aktualizuje się natychmiast po udostępnieniu nowej wersji agenta. Ta możliwość nie ma obecnie zastosowania do serwerów klastrowanych.

    Ta aktualizacja występuje w wybranym oknie obsługi i umożliwia serwerowi korzystanie z nowych funkcji i ulepszeń, gdy tylko staną się one ogólnie dostępne. To zalecane, bezproblemowe ustawienie zapewnia główne wersje agentów i regularne aktualizacje dla serwera. Każdy zwolniony agent jest w jakości GA.

    Jeśli wybierzesz tę opcję, firma Microsoft udostępni Tobie najnowszą wersję agenta. Serwery klastrowane są wykluczone. Po zakończeniu lotu agent staje się również dostępny w usłudze Microsoft Update i Centrum pobierania Microsoft.

Zmienianie ustawienia automatycznej aktualizacji

W poniższych instrukcjach opisano sposób zmiany ustawień po ukończeniu instalatora, jeśli musisz wprowadzić zmiany.

Otwórz konsolę programu PowerShell i przejdź do katalogu, w którym zainstalowano agenta synchronizacji, a następnie zaimportuj polecenia cmdlet serwera. Domyślnie ta akcja wygląda podobnie do następującego przykładu:

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

Możesz uruchomić polecenie Get-StorageSyncAgentAutoUpdatePolicy , aby sprawdzić bieżące ustawienie zasad i określić, czy chcesz go zmienić.

Aby zmienić bieżące ustawienie zasad na opóźnione śledzenie aktualizacji, można użyć:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

Aby zmienić bieżące ustawienie zasad na ścieżkę natychmiastowej aktualizacji, możesz użyć:

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

Uwaga

Jeśli proces wprowadzania najnowszej wersji agenta został już ukończony, a polityka automatycznej aktualizacji agenta zostanie zmieniona na InstallLatest, agent nie zostanie automatycznie zaktualizowany do momentu, gdy kolejna wersja agenta zostanie udostępniona do testów. Aby zaktualizować wersję agenta, która zakończyła etap testowy, użyj usługi Microsoft Update lub AfsUpdater.exe. Aby sprawdzić, czy wersja agenta jest obecnie wdrażana, zapoznaj się z sekcją Obsługiwane wersje w uwagach do wydania.

Gwarancja cyklu życia agenta i zarządzania zmianami

Azure File Sync to usługa w chmurze, która stale wprowadza nowe funkcje i ulepszenia. Konkretna wersja agenta usługi Azure File Sync może być obsługiwana tylko przez ograniczony czas. Aby ułatwić wdrażanie, następujące reguły gwarantują, że masz wystarczająco dużo czasu i powiadomienia, aby uwzględnić aktualizacje agenta w procesie zarządzania zmianami:

  • Główne wersje agenta są obsługiwane przez co najmniej 12 miesięcy od daty pierwszego wydania.
  • Istnieje częściowe nakładanie się co najmniej 3 miesięcy między obsługą głównych wersji agentów oprogramowania.
  • Ostrzeżenia są wydawane dla zarejestrowanych serwerów za pośrednictwem agenta wkrótce wygasającego, z co najmniej 3-miesięcznym wyprzedzeniem przed wygaśnięciem. Możesz sprawdzić, czy zarejestrowany serwer używa starszej wersji agenta w sekcji dotyczącej zarejestrowanych serwerów w usłudze synchronizacji magazynu.
  • Okres istnienia pomniejszej wersji agenta jest powiązany ze skojarzoną wersją główną. Na przykład gdy agent w wersji 18.0.0.0 jest ustawiony na wygaśnięcie, wszystkie wersje agenta w wersji 18.*.*.* wygasają razem.

Uwaga

Zainstalowanie wygasłej wersji agenta wyświetla ostrzeżenie, ale kończy się powodzeniem. Próba zainstalowania lub nawiązania połączenia z wygasłą wersją agenta nie jest obsługiwana i jest blokowana.

Treści powiązane

  • Last updated on