Planowanie wdrażania usługi Azure File Sync
Azure File Sync to usługa, która umożliwia buforowanie kilku udziałów plików platformy Azure na lokalnej maszynie wirtualnej z systemem Windows Server lub 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 będą przechowywane w chmurze w udziałach plików platformy Azure. Udziały plików platformy Azure można używać na dwa sposoby: bezpośrednio instalowania tych bezserwerowych udziałów plików platformy Azure (SMB) lub buforowania udziałów plików platformy Azure lokalnie przy użyciu usługi Azure File Sync. Wybrana opcja wdrożenia zmienia aspekty, które należy wziąć pod uwagę podczas planowania wdrożenia.
Bezpośrednia instalacja udziału plików platformy Azure: Ponieważ usługa Azure Files zapewnia dostęp do protokołu SMB, można zainstalować udziały plików platformy Azure lokalnie lub w chmurze przy użyciu standardowego klienta SMB dostępnego w systemach Windows, macOS i Linux. Ponieważ udziały plików platformy Azure są bezserwerowe, wdrażanie w scenariuszach produkcyjnych nie wymaga zarządzania serwerem plików ani urządzeniem NAS. Oznacza to, że nie trzeba stosować poprawek oprogramowania ani wymieniać dysków fizycznych.
Buforowanie lokalnego udziału plików platformy Azure za pomocą usługi Azure File Sync: usługa Azure File Sync umożliwia scentralizowanie udziałów plików organizacji w usłudze Azure Files przy jednoczesnym zachowaniu elastyczności, wydajności i zgodności lokalnego serwera plików. Usługa Azure File Sync przekształca lokalny (lub w chmurze) system Windows Server w szybką pamięć podręczną udziału plików platformy Azure.
Pojęcia dotyczące zarządzania
Wdrożenie usługi Azure File Sync ma trzy podstawowe obiekty zarządzania:
- Udział plików platformy Azure: udział plików platformy Azure to bezserwerowy udział plików w chmurze, który zapewnia punkt końcowy chmury relacji synchronizacji usługi Azure File Sync. Dostęp do plików w udziale plików platformy Azure można uzyskać bezpośrednio za pomocą protokołu SMB lub FileREST, chociaż zachęcamy przede wszystkim do uzyskiwania dostępu do plików za pośrednictwem pamięci podręcznej systemu Windows Server, gdy udział plików platformy Azure jest używany z usługą Azure File Sync. Dzieje się tak dlatego, że obecnie usługa Azure Files nie ma wydajnego mechanizmu wykrywania zmian, takiego jak system Windows Server, więc bezpośrednie propagowanie zmian w udziale plików platformy Azure do punktów końcowych serwera zajmie trochę czasu.
- Punkt końcowy serwera: ścieżka w systemie Windows Server, który jest synchronizowany z udziałem plików platformy Azure. Może to być określony folder na woluminie lub katalogu głównym woluminu. Wiele punktów końcowych serwera może istnieć na tym samym woluminie, jeśli ich przestrzenie nazw nie nakładają się na siebie.
- Grupa synchronizacji: obiekt, który definiuje relację synchronizacji między punktem końcowym w chmurze lub udziałem plików platformy Azure i 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.
Pojęcia dotyczące zarządzania udziałami plików platformy Azure
Udziały plików platformy Azure są wdrażane na kontach magazynu, które są obiektami najwyższego poziomu reprezentującymi udostępnioną pulę magazynu. Ta pula magazynu może służyć do wdrażania wielu udziałów plików, a także innych zasobów magazynu, takich jak kontenery obiektów blob, kolejki lub tabele. Wszystkie zasoby magazynu wdrożone na koncie magazynu współużytkują limity, które mają zastosowanie do tego konta magazynu. Aby uzyskać informacje o bieżących limitach kont magazynu, zobacz Cele dotyczące skalowalności i wydajności usługi Azure Files.
Istnieją dwa główne typy kont magazynu, których będziesz używać na potrzeby wdrożeń usługi Azure Files:
- Konta magazynu ogólnego przeznaczenia w wersji 2 (GPv2): konta magazynu GPv2 umożliwiają wdrażanie udziałów plików platformy Azure na standardowym/twardym sprzęcie (opartym na dyskach TWARDYCH). Oprócz przechowywania udziałów plików platformy Azure konta magazynu GPv2 mogą przechowywać inne zasoby magazynu, takie jak kontenery obiektów blob, kolejki lub tabele.
- Konta magazynu FileStorage: konta magazynu FileStorage umożliwiają wdrażanie udziałów plików platformy Azure na sprzęcie opartym na dyskach ssd (ssd). Konta FileStorage mogą być używane tylko do przechowywania udziałów plików platformy Azure; na koncie FileStorage nie można wdrożyć żadnych innych zasobów magazynu (kontenerów obiektów blob, kolejek, tabel itp.). Tylko konta FileStorage mogą wdrażać udziały plików SMB i NFS.
Istnieje kilka innych typów kont magazynu, które można napotkać w witrynie Azure Portal, programie PowerShell lub interfejsie wiersza polecenia. Dwa typy kont magazynu BlockBlobStorage i BlobStorage magazynu nie mogą zawierać udziałów plików platformy Azure. Pozostałe dwa typy kont magazynu, które mogą być widoczne, to konta ogólnego przeznaczenia w wersji 1 (GPv1) i klasyczne konta magazynu, które mogą zawierać udziały plików platformy Azure. Mimo że konta GPv1 i klasyczne konta magazynu mogą zawierać udziały plików platformy Azure, większość nowych funkcji usługi Azure Files jest dostępna tylko na kontach magazynu GPv2 i FileStorage. Dlatego zalecamy używanie tylko kont GPv2 i FileStorage dla nowych wdrożeń oraz uaktualniania kont GPv1 i klasycznych kont magazynu, jeśli już istnieją w danym środowisku.
Pojęcia dotyczące zarządzania usługą Azure File Sync
Grupy synchronizacji są wdrażane w usługach synchronizacji magazynu, które są obiektami najwyższego poziomu, które rejestrują serwery do użycia z usługą Azure File Sync i zawierają relacje grup synchronizacji. Zasób usługi synchronizacji magazynu jest elementem równorzędnym zasobu konta magazynu i można go również wdrożyć w grupach zasobów platformy Azure. Usługa synchronizacji magazynu może tworzyć grupy synchronizacji zawierające udziały plików platformy Azure na wielu kontach magazynu i wiele zarejestrowanych serwerów z systemem Windows.
Przed utworzeniem grupy synchronizacji w usłudze synchronizacji magazynu należy najpierw zarejestrować system Windows Server w usłudze synchronizacji magazynu. Spowoduje to utworzenie zarejestrowanego obiektu serwera , który reprezentuje relację zaufania między serwerem lub klastrem a usługą synchronizacji magazynu. Aby zarejestrować usługę synchronizacji magazynu, należy najpierw zainstalować agenta usługi Azure File Sync na serwerze. Pojedynczy serwer lub klaster można zarejestrować tylko w jednej usłudze synchronizacji magazynu jednocześnie.
Grupa synchronizacji zawiera jeden punkt końcowy w chmurze lub udział plików platformy Azure i co najmniej jeden punkt końcowy serwera. Obiekt punktu końcowego serwera zawiera ustawienia, które umożliwiają konfigurowanie możliwości obsługi warstw w chmurze, co zapewnia możliwość buforowania usługi Azure File Sync. Aby można było przeprowadzić synchronizację z udziałem plików platformy Azure, konto magazynu zawierające udział plików platformy Azure musi znajdować się w tym samym regionie świadczenia usługi azure co usługa synchronizacji magazynu.
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), najpierw należy odnaleźć zmiany za pomocą zadania wykrywania zmian usługi Azure File Sync. Zadanie wykrywania zmian jest inicjowane dla punktu końcowego chmury tylko raz co 24 godziny. Aby uzyskać więcej informacji, zobacz Często zadawane pytania dotyczące usługi Azure Files.
Rozważ liczbę wymaganych usług synchronizacji magazynu
W poprzedniej sekcji omówiono podstawowy zasób do skonfigurowania dla usługi Azure File Sync: usługi synchronizacji magazynu. System Windows Server można zarejestrować tylko w jednej usłudze synchronizacji magazynu. Dlatego często najlepiej jest wdrożyć tylko jedną usługę synchronizacji magazynu i zarejestrować na nim wszystkie serwery.
Utwórz wiele usług synchronizacji magazynu tylko wtedy, gdy masz:
- odrębne zestawy serwerów, które nigdy nie muszą wymieniać danych ze sobą. W takim przypadku chcesz zaprojektować system, aby wykluczyć niektóre zestawy serwerów do synchronizacji z udziałem plików platformy Azure, który jest już używany jako punkt końcowy w chmurze w grupie synchronizacji w innej usłudze synchronizacji magazynu. Innym sposobem na przyjrzenie się temu jest to, że serwery z systemem Windows zarejestrowane w innej usłudze synchronizacji magazynu nie mogą synchronizować się z tym samym udziałem plików platformy Azure.
- musi mieć więcej zarejestrowanych serwerów lub grup synchronizacji niż może obsługiwać pojedyncza usługa synchronizacji magazynu. Aby uzyskać więcej informacji, przejrzyj cele skalowania usługi Azure File Sync.
Planowanie zrównoważonych topologii synchronizacji
Przed wdrożeniem jakichkolwiek zasobów należy zaplanować synchronizację na serwerze lokalnym, za pomocą którego udziału plików platformy Azure. Utworzenie planu ułatwi określenie, ile kont magazynu, udziałów plików platformy Azure i zasobów synchronizacji będzie potrzebnych. Te zagadnienia są nadal istotne, nawet jeśli dane nie znajdują się obecnie na serwerze z systemem Windows Server lub serwerze, którego chcesz użyć w dłuższej perspektywie. Sekcja migracji może pomóc w ustaleniu odpowiednich ścieżek migracji w danej sytuacji.
W tym kroku określisz, ile potrzebnych udziałów plików platformy Azure. Pojedyncze wystąpienie systemu Windows Server (lub klaster) może synchronizować maksymalnie 30 udziałów plików platformy Azure.
Być może masz więcej folderów na woluminach, które obecnie udostępniasz lokalnie jako udziały SMB użytkownikom i aplikacjom. Najprostszym sposobem na zniesienie tego scenariusza jest przewidywanie udziału lokalnego mapowania 1:1 na udział plików platformy Azure. Jeśli masz wystarczającą liczbę udziałów poniżej 30 dla pojedynczego wystąpienia systemu Windows Server, zalecamy mapowanie 1:1.
Jeśli masz więcej niż 30 udziałów, mapowanie udziału lokalnego 1:1 na udział plików platformy 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 lokalnych w jednym udziale plików platformy Azure nie uniemożliwia tworzenia zwykłych 15 udziałów SMB w lokalnym wystąpieniu systemu 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 dla tej grupy udziałów lokalnych jest wymagany tylko jeden udział plików platformy Azure w chmurze.
Synchronizacja woluminów
Usługa Azure File Sync obsługuje synchronizowanie katalogu głównego woluminu z udziałem plików platformy Azure. Jeśli zsynchronizujesz katalog główny woluminu, wszystkie podfoldery i pliki trafią do tego samego udziału plików platformy Azure.
Synchronizowanie katalogu głównego woluminu nie zawsze jest najlepszą opcją. Istnieją korzyści wynikające z synchronizacji wielu lokalizacji. Na przykład pomaga zachować liczbę elementów niższych na zakres synchronizacji. Testujemy udziały plików platformy Azure i usługę Azure File Sync z 100 milionami elementów (plików i folderów) na 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 po stronie chmury z migawki udziału plików platformy Azure będzie 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.
Napiwek
Jeśli nie wiesz, ile plików i folderów masz, zapoznaj się z narzędziem TreeSize firmy JAM Software GmbH.
Ustrukturyzowane podejście do mapy wdrożenia
Przed wdrożeniem magazynu w chmurze w późniejszym kroku należy utworzyć mapę między folderami lokalnymi i udziałami plików platformy Azure. To mapowanie poinformuje o tylu zasobach grupy synchronizacji usługi Azure File Sync, które zostaną aprowizowania. Grupa synchronizacji łączy udział plików platformy Azure i folder na serwerze razem i ustanawia połączenie synchronizacji.
Aby zdecydować, ile potrzebnych udziałów plików platformy Azure, zapoznaj się z następującymi limitami i najlepszymi rozwiązaniami. Pomoże to zoptymalizować mapę.
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 jest wdrażany na koncie magazynu. Takie rozwiązanie sprawia, że konto magazynu jest celem skalowania dla liczb wydajności, takich jak liczba operacji we/wy na sekundę i przepływność.
Zwróć uwagę na ograniczenia liczby operacji we/wy na sekundę konta magazynu podczas wdrażania udziałów plików platformy Azure. Najlepiej mapować udziały plików 1:1 przy użyciu kont magazynu. Jednak może to 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 jest możliwe wdrożenie tylko jednego udziału plików na jednym koncie magazynu, rozważ, które udziały będą wysoce aktywne i które udziały będą mniej aktywne, aby upewnić się, że najgorętsze udziały plików nie zostaną umieszczone na tym samym koncie magazynu.
Jeśli planujesz podnieść aplikację na platformę Azure, która będzie używać natywnie udziału plików platformy Azure, może być potrzebna większa wydajność z udziału plików platformy Azure. Jeśli ten typ użycia jest możliwy, nawet w przyszłości, najlepszym rozwiązaniem jest utworzenie pojedynczego standardowego udziału plików platformy Azure na własnym koncie magazynu.
Istnieje limit 250 kont magazynu na subskrypcję na region świadczenia usługi Azure.
Napiwek
Biorąc pod uwagę te informacje, często konieczne jest zgrupowanie wielu folderów najwyższego poziomu 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 pozostać w limicie 30 synchronizacji udziałów plików platformy Azure na serwer.
To grupowanie w typowym katalogu głównym nie ma wpływu na dostęp do 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.
Najlepszym rozwiązaniem jest utrzymywanie niskiej liczby elementów na zakres synchronizacji. Jest to ważny czynnik, który należy wziąć pod uwagę podczas mapowania folderów do udziałów plików platformy Azure. Usługa Azure File Sync jest testowana przy użyciu 100 milionów elementów (plików i folderów) na udział. Ale często najlepiej zachować liczbę pozycji poniżej 20 milionów lub 30 milionów w jednym udziale. Podziel przestrzeń nazw na wiele udziałów, jeśli zaczniesz przekraczać te liczby. Możesz nadal grupować wiele udziałów lokalnych w tym samym udziale plików platformy Azure, jeśli pozostaniesz mniej więcej poniżej tych liczb. Ta praktyka zapewni Ci miejsce na rozwój.
Istnieje możliwość, że w twojej sytuacji zestaw folderów może logicznie synchronizować się z tym samym udziałem plików platformy Azure (przy użyciu nowego wspólnego podejścia do folderu głównego wymienionego wcześniej). Jednak nadal lepiej jest przegrupować foldery, więc synchronizują się z dwoma zamiast z jednym udziałem plików platformy Azure. Za pomocą tego podejścia można zachować równowagę liczby plików i folderów na udział plików na serwerze. Możesz również podzielić udziały lokalne i zsynchronizować je na więcej serwerów lokalnych, dodając możliwość synchronizacji z 30 więcej udziałów plików platformy Azure na dodatkowy serwer.
Typowe scenariusze i zagadnienia dotyczące synchronizacji plików
| # | Scenariusz synchronizacji | Obsługiwane | Zagadnienia (lub ograniczenia) | Rozwiązanie (lub obejście) |
|---|---|---|---|---|
| 1 | 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 tylko synchronizację z jedną grupą synchronizacji. Grupa synchronizacji obsługuje tylko jeden punkt końcowy serwera na zarejestrowany serwer. |
1) Rozpocznij od zsynchronizowania jednego dysku (woluminu głównego) z docelowym udziałem plików platformy Azure. Rozpoczęcie od największego dysku/woluminu pomoże spełnić wymagania dotyczące magazynu lokalnego. Skonfiguruj warstwy w chmurze, aby warstwować wszystkie dane do chmury, zwalniając w ten sposób miejsce na dysku serwera plików. Przenieś dane z innych woluminów/udziałów do bieżącego woluminu, który jest synchronizowany. Wykonaj kroki jeden po drugim, dopóki wszystkie dane nie będą warstwowe do chmury/zmigrowane. 2) Docelowy jeden wolumin główny (dysk) naraz. Obsługa warstw w chmurze umożliwia warstwowanie wszystkich danych w celu kierowania udziału plików platformy Azure. Usuń punkt końcowy serwera z grupy synchronizacji, ponownie utwórz punkt końcowy z następnym woluminem głównym/dyskiem, synchronizacją i powtórz proces. Uwaga: Może być wymagane ponowne zainstalowanie agenta. 3) Zaleca się używanie wielu docelowych udziałów plików platformy Azure (tego samego lub innego konta magazynu na podstawie wymagań dotyczących wydajności) |
| 2 | Serwer plików z pojedynczym woluminem i wieloma udziałami do tego samego docelowego udziału plików platformy Azure (konsolidacja) | Tak | Nie można mieć wielu punktów końcowych serwera na zarejestrowany serwer synchronizacji z tym samym docelowym udziałem plików platformy Azure (takim samym jak powyżej) | Synchronizuj katalog główny woluminu zawierającego wiele udziałów lub folderów najwyższego poziomu. Aby uzyskać więcej informacji, zobacz Share grouping concept and Volume sync (Udostępnianie koncepcji grupowania i synchronizacja woluminów). |
| 3 | Serwer plików z wieloma udziałami i/lub woluminami do wielu udziałów plików platformy Azure w ramach pojedynczego 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 platformy Azure. Konto magazynu jest celem skalowania pod kątem wydajności. Liczba operacji we/wy na sekundę i przepływność są współużytkowane przez udziały plików. 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ę. |
1) Użyj wielu grup synchronizacji (liczba grup synchronizacji = liczba udziałów plików platformy Azure do synchronizacji z). 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 koncepcji grupowania udziałów i synchronizacji woluminów, aby zmniejszyć liczbę folderów głównych lub najwyższego poziomu w źródle. 3) Użyj dodatkowych serwerów usługi File Sync w środowisku lokalnym i podziel/przenieś dane na te serwery, aby obejść ograniczenia dotyczące źródłowego serwera z systemem Windows. |
| 100 | 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 | Pojedyncze wystąpienie systemu Windows Server (lub klaster) może synchronizować maksymalnie 30 udziałów plików platformy 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ę. |
Takie samo podejście jak powyżej |
| 5 | Wiele serwerów plików z jednym (woluminem głównym lub udziałem) do tego samego docelowego udziału plików platformy Azure (konsolidacja) | Nie. | Grupa synchronizacji nie może używać punktu końcowego w chmurze (udziału plików platformy Azure) już skonfigurowanego 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 scenariuszu nr 1 powyżej z dodatkowym uwzględnieniem określania wartości docelowej dla jednego serwera plików naraz. |
Tworzenie tabeli mapowania
Użyj poprzednich informacji, aby określić, ile potrzebnych udziałów plików platformy Azure i które części istniejących danych zostaną utworzone w którym udziale plików platformy Azure.
Utwórz tabelę, która rejestruje swoje przemyślenia, aby można było odwoływać się do niej, gdy zajdzie taka potrzeba. Utrzymanie organizacji jest ważne, ponieważ można łatwo utracić szczegóły planu mapowania podczas aprowizowania wielu zasobów platformy Azure jednocześnie. Pobierz następujący plik programu Excel, aby użyć go jako szablonu, aby ułatwić tworzenie mapowania.
|
Pobierz szablon mapowania przestrzeni nazw. |
Zagadnienia dotyczące serwera 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ługę w tle systemu Windows, która jest odpowiedzialna za monitorowanie zmian w punktach końcowych serwera i inicjowanie sesji synchronizacji oraz StorageSync.sys, filtr systemu plików, który umożliwia obsługę warstw w chmurze 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 | Obsługiwane jednostki SKU | Obsługiwane opcje wdrażania |
|---|---|---|
| Windows Server 2025 | Azure, Datacenter, Essentials, Standard i IoT | Pełne i podstawowe |
| Windows Server 2022 | Azure, Datacenter, Essentials, Standard i IoT | Pełne i podstawowe |
| Windows Server 2019 | Centrum danych, Podstawy, Standardowa i IoT | Pełne i podstawowe |
| Windows Server 2016 | Datacenter, Essentials, Standard i Storage Server | Pełne i podstawowe |
| Windows Server 2012 R2* | Datacenter, Essentials, Standard i Storage Server | Pełne i podstawowe |
*Wymaga pobrania i zainstalowania programu Windows Management Framework (WMF) 5.1. Odpowiedni pakiet do pobrania i zainstalowania dla systemu Windows Server 2012 R2 to Win8.1AndW2K12R2-KB*******-x64.msu.
Przyszłe wersje systemu Windows Server zostaną dodane w miarę ich wydawania.
Ważne
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 z co najmniej jednym procesorem CPU, co najmniej 2 GiB pamięci i woluminem dołączonym lokalnie sformatowanym w systemie plików NTFS.
Ważne
Jeśli serwer jest uruchomiony na maszynie wirtualnej z włączoną pamięcią dynamiczną, należy skonfigurować maszynę wirtualną z co najmniej 2048 MiB pamięci.
W przypadku większości obciążeń produkcyjnych nie zalecamy konfigurowania serwera synchronizacji usługi Azure File Sync tylko z minimalnymi wymaganiami. Aby uzyskać więcej informacji, zobacz Zalecane zasoby systemowe.
Zalecane zasoby systemowe
Podobnie jak w przypadku innych funkcji lub aplikacji na serwerze, wymagania dotyczące zasobów systemowych dla usługi Azure File Sync są określane przez skalę wdrożenia: większe wdrożenia na serwerze wymagają więcej zasobów systemowych. W przypadku usługi Azure File Sync skala jest określana przez liczbę obiektów w punktach końcowych serwera i współczynnika zmian w zestawie danych. Pojedynczy serwer może mieć punkty końcowe serwera w wielu grupach synchronizacji i liczba obiektów wymienionych w poniższej tabeli zalicza się do pełnej przestrzeni nazw dołączonej do serwera.
Na przykład punkt końcowy serwera A z 10 milionami obiektów + punkt końcowy 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.
Dane przestrzeni nazw są przechowywane w pamięci ze względu na wydajność. W związku z tym większe przestrzenie nazw wymagają większej ilości pamięci, aby zachować dobrą wydajność, a większy współczynnik zmian danych wymaga do przetwarzania większej liczby procesorów CPU.
W poniższej tabeli podano zarówno rozmiar przestrzeni nazw, jak i konwersję na pojemność dla typowych udziałów plików ogólnego przeznaczenia, gdzie średni rozmiar pliku to 512 KiB. Jeśli rozmiary plików są mniejsze, rozważ dodanie dodatkowej pamięci dla tej samej pojemności. Konfiguracja pamięci powinna bazować na rozmiarze przestrzeni nazw.
| Rozmiar przestrzeni nazw — liczba plików i katalogów (w milionach) | Typowa pojemność (TiB) | Rdzenie procesora CPU | 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 progach, które przetestowaliśmy. Aby uzyskać więcej informacji, zobacz Cele skalowania usługi Azure File Sync.
Napiwek
Początkowa synchronizacja przestrzeni nazw jest operacją intensywnie korzystającą i zalecamy przydzielanie większej ilości pamięci do momentu ukończenia synchronizacji początkowej. Nie jest to wymagane, ale może przyspieszyć synchronizację początkową.
Typowy współczynnik zmian danych to zmiana 0,5% przestrzeni nazw dziennie. W przypadku wyższych współczynników zmian danych rozważ dodanie większej liczby procesorów CPU.
Polecenie cmdlet oceny
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 polecenie cmdlet sprawdza potencjalne problemy z systemem plików i zestawem danych, takie jak nieobsługiwane znaki lub nieobsługiwana wersja systemu operacyjnego. Te kontrole obejmują większość, ale nie wszystkie funkcje wymienione poniżej; Zalecamy dokładne zapoznanie się z resztą tej sekcji, aby upewnić się, że wdrożenie przebiega bezproblemowo.
Polecenie cmdlet oceny można zainstalować, instalując moduł Az programu PowerShell, który można zainstalować, postępując zgodnie z instrukcjami podanymi tutaj: Instalowanie i konfigurowanie programu Azure PowerShell.
Użycie
Narzędzie do oceny można wywołać na kilka różnych sposobów: można przeprowadzić kontrole systemu, testy zestawu danych lub oba te metody. Aby sprawdzić zarówno system, jak i zestaw 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. Bezpośrednio dołączony magazyn lub DAS w systemie Windows Server oznacza, że system operacyjny Windows Server jest właścicielem systemu plików. DAS można dostarczać za pomocą fizycznego dołączania dysków do serwera plików, dołączania dysków wirtualnych do maszyny wirtualnej serwera plików (takiej jak maszyna wirtualna hostowana przez funkcję Hyper-V), a nawet za pośrednictwem 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 międzyoperajności funkcji systemu plików NTFS:
Usługa Azure File Sync pomija również niektóre pliki tymczasowe i foldery systemowe:
| Plik/folder | 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 | plik umożliwiający blokowanie dostępu do bazy danych |
| 635D02A9D91C401B97884B82B3BCDAEA.* | plik synchronizacji wewnętrznej |
| \System Volume Information | Folder specyficzny dla woluminu |
| $RECYCLE. BIN | Folder |
| \SyncShareState | folder do synchronizacji |
| . SystemShareInformation | Folder do synchronizacji w udziale plików platformy Azure |
Uwaga
Chociaż usługa Azure File Sync obsługuje synchronizowanie plików baz danych, bazy danych nie są dobrym obciążeniem dla rozwiązań synchronizacji (w tym usługi Azure File Sync), ponieważ pliki dziennika i bazy danych muszą być synchronizowane razem i mogą one wyjść z synchronizacji z różnych powodów, co może prowadzić do uszkodzenia bazy danych.
Rozważ ilość wolnego miejsca potrzebnego na dysku lokalnym
Podczas planowania korzystania z usługi Azure File Sync należy wziąć pod uwagę ilość wolnego miejsca na dysku lokalnym, na którym planujesz mieć punkt końcowy serwera.
W usłudze Azure File Sync należy uwzględnić następujące zajmowanie miejsca na dysku lokalnym:
Po włączeniu obsługi warstw w chmurze:
- Ponowne analizy punktów dla plików warstwowych
- Baza danych metadanych usługi Azure File Sync
- Magazyn ciepła usługi Azure File Sync
- W pełni pobrane pliki w gorącej pamięci podręcznej (jeśli istnieją)
- Wymagania dotyczące zasad wolnego miejsca na woluminie
Po wyłączeniu obsługi warstw w chmurze:
- W pełni pobrane pliki
- Magazyn ciepła usługi Azure File Sync
- Baza danych metadanych usługi Azure File Sync
Użyjemy przykładu, aby zilustrować, 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 zaplanujemy utworzenie punktu końcowego serwera na dysku F. Masz 1 milion plików i chcesz warstwować wszystkie z nich, 100 000 katalogów i rozmiar klastra dysku 4 KiB. Rozmiar dysku to 1000 GiB. Chcesz włączyć obsługę warstw w chmurze i ustawić zasady wolnego miejsca na wolumin na 20%.
- System plików NTFS przydziela rozmiar klastra dla każdego z plików warstwowych. 1 milion plików * 4 Rozmiar klastra KiB = 4 000 000 KiB (4 GiB)
Uwaga
Aby w pełni korzystać z obsługi warstw w chmurze, zaleca się użycie mniejszych rozmiarów klastrów NTFS (mniej niż 64KiB), ponieważ każdy plik warstwowy zajmuje klaster. Ponadto miejsce zajmowane przez pliki warstwowe jest przydzielane przez system plików NTFS. W związku z tym nie będzie on widoczny w żadnym interfejsie użytkownika.
- Metadane synchronizacji zajmują rozmiar klastra na element. (1 milion plików + 100 000 katalogów) * 4 Rozmiar klastra KiB = 4400 000 KiB (4,4 GiB)
- Magazyn ciepła usługi Azure File Sync 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 to 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 dodatkowego wolnego miejsca, które jest wymagane, aby ustalić, ile wolnego miejsca jest wymagane dla tego dysku.
Klaster trybu failover
- Klaster trybu failover systemu Windows Server jest obsługiwany przez usługę Azure File Sync dla opcji wdrażania "Serwer plików do użytku ogólnego". Aby uzyskać więcej informacji na temat konfigurowania roli "Serwer plików do użytku ogólnego" w klastrze trybu failover, zobacz Wdrażanie klastrowanego serwera plików z dwoma węzłami.
- Jedynym scenariuszem obsługiwanym przez usługę Azure File Sync jest klaster trybu failover systemu Windows Server z dyskami klastra
- Klaster trybu failover nie jest obsługiwany na serwerze plików skalowalnym w poziomie dla danych aplikacji (SOFS) ani na klastrowanych udostępnionych woluminach (CSV) ani na dyskach lokalnych.
Uwaga
Aby synchronizacja działała prawidłowo, agent usługi Azure File Sync musi być zainstalowany na 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 2016, Windows Server 2019, Windows Server 2022 i Windows Server 2025. Włączenie deduplikacji danych na woluminie z włączoną obsługą warstw w chmurze umożliwia buforowanie większej liczby plików lokalnych bez aprowizacji większej ilości miejsca do magazynowania.
Gdy funkcja deduplikacji danych jest włączona na woluminie z włączoną obsługą warstw w chmurze, pliki zoptymalizowane pod kątem deduplikacji w lokalizacji punktu końcowego serwera będą warstwowe podobne do normalnego pliku na podstawie ustawień zasad obsługi warstw w chmurze. Po warstwie zoptymalizowanych pod kątem deduplikacji plików zadanie odzyskiwania pamięci deduplikacji danych zostanie uruchomione automatycznie w celu odzyskania miejsca na dysku przez usunięcie niepotrzebnych fragmentów, które nie są już przywoływane przez inne pliki na woluminie.
Zwróć uwagę, że oszczędności woluminu mają zastosowanie tylko do serwera; Dane w udziale plików platformy Azure nie zostaną zdeduplikowane.
Uwaga
Aby obsługiwać deduplikację danych na woluminach z włączoną obsługą warstw w chmurze w systemie Windows Server 2019, należy zainstalować aktualizację systemu Windows update KB4520062 — październik 2019 r. lub nowszą miesięczną aktualizację zbiorczą.
Windows Server 2012 R2
Usługa Azure File Sync nie obsługuje deduplikacji danych i obsługi warstw w chmurze na tym samym woluminie w systemie Windows Server 2012 R2. Jeśli funkcja deduplikacji danych jest włączona na woluminie, obsługa warstw w chmurze musi być wyłączona.
Uwagi
Jeśli deduplikacja danych jest zainstalowana 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 funkcja deduplikacji danych jest włączona na woluminie po włączeniu obsługi warstw w chmurze, początkowe zadanie optymalizacji deduplikacji zoptymalizuje pliki na woluminie, który nie jest jeszcze warstwowy i będzie miał następujący wpływ na obsługę warstw w chmurze:
- Zasady wolnego miejsca będą nadal warstwować pliki zgodnie z ilością wolnego miejsca na woluminie przy użyciu mapy cieplnej.
- Zasady daty pomijają obsługę warstw plików, które mogły w inny sposób kwalifikować się do obsługi warstw ze względu na zadanie optymalizacji deduplikacji, które uzyskuje dostęp do plików.
W przypadku bieżących zadań optymalizacji deduplikacji obsługa warstw w chmurze z zasadami daty zostanie opóźniona przez ustawienie MinimumFileAgeDays deduplikacji danych, jeśli plik nie jest jeszcze warstwowy.
- Przykład: jeśli ustawienie MinimumFileAgeDays wynosi siedem dni, a zasady daty obsługi warstw w chmurze to 30 dni, zasady daty będą warstwy plików po 37 dniach.
- Uwaga: gdy plik jest warstwowy przez usługę Azure File Sync, zadanie optymalizacji deduplikacji spowoduje pominięcie pliku.
Jeśli serwer z systemem Windows Server 2012 R2 z zainstalowanym agentem usługi Azure File Sync zostanie uaktualniony do systemu Windows Server 2016, Windows Server 2019, Windows Server 2022 lub Windows Server 2025, w celu obsługi deduplikacji danych i obsługi warstw w chmurze na tym samym woluminie:
- Odinstaluj agenta usługi Azure File Sync dla systemu Windows Server 2012 R2 i uruchom ponownie serwer.
- Pobierz agenta usługi Azure File Sync dla nowej wersji systemu operacyjnego serwera (Windows Server 2016, Windows Server 2019, Windows Server 2022 lub Windows Server 2025).
- Zainstaluj agenta usługi Azure File Sync i uruchom ponownie serwer.
Uwaga: ustawienia konfiguracji usługi Azure File Sync na serwerze są zachowywane po odinstalowaniu i ponownym zainstalowaniu agenta.
Rozproszony system plików (DFS)
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).
Przestrzenie nazw systemu plików DFS (DFS-N): usługa Azure File Sync jest w pełni obsługiwana z implementacją systemu plików 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.
Replikacja systemu plików DFS (DFS-R): ponieważ usługi DFS-R i Azure File Sync są rozwiązaniami replikacji, w większości przypadków zalecamy zastąpienie systemu plików DFS-R usługą Azure File Sync. Istnieje jednak kilka scenariuszy, w których należy razem używać usług DFS-R i Azure File Sync:
- 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 replikacji systemu plików DFS (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 konsoliduje dane na jednym serwerze koncentratora, dla którego chcesz użyć usługi Azure File Sync.
Aby usługi Azure File Sync i DFS-R działały obok siebie:
- Obsługa warstw w chmurze usługi Azure File Sync musi być wyłączona na woluminach z folderami replikowanymi w systemie plików DFS-R.
- Punkty końcowe serwera nie powinny być konfigurowane w folderach replikacji tylko do odczytu systemu plików 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 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 nastąpić po wdrożeniu obrazu serwera i zakończeniu miniinstalowania programu sysprep.
Usługa Windows Search
Jeśli obsługa warstw w chmurze jest włączona w punkcie końcowym serwera, pliki warstwowe są pomijane i nie są indeksowane przez usługę Windows Search. Pliki niewarstwowe są prawidłowo indeksowane.
Uwaga
Klienci systemu Windows będą powodować odwołania podczas przeszukiwania udziału plików, jeśli ustawienie Zawsze wyszukuje nazwy plików i zawartość jest włączone na maszynie klienckiej. To ustawienie jest domyślnie wyłączone.
Inne rozwiązania do zarządzania magazynem hierarchicznym (HSM)
Żadne inne rozwiązania HSM nie powinny być używane z usługą Azure File Sync.
Wydajność i skalowalność
Ponieważ agent 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 wielu czynników w infrastrukturze: systemu Windows Server oraz konfiguracji dysku, na którym jest zainstalowany, przepustowości sieci między serwerem a magazynem platformy Azure, rozmiaru pliku, całkowitego rozmiaru zestawu danych i aktywności na zestawie danych. Ponieważ usługa Azure File Sync działa na poziomie pliku, cechy wydajności rozwiązania opartego na usłudze Azure File Sync są lepiej mierzone w liczbie obiektów (plików i katalogów) przetwarzanych na sekundę.
Zmiany wprowadzone w udziale plików platformy Azure przy użyciu witryny Azure Portal lub protokołu SMB nie są natychmiast wykrywane i replikowane, takie jak zmiany w punkcie końcowym serwera. Usługa Azure Files nie ma powiadomień ani dzienników zmian, więc nie ma możliwości automatycznego inicjowania sesji synchronizacji po zmianie plików. W systemie Windows Server usługa Azure File Sync używa dziennika USN systemu Windows do automatycznego inicjowania sesji synchronizacji po zmianie plików.
Aby wykrywać zmiany w udziale plików platformy Azure, usługa Azure File Sync ma zaplanowane zadanie nazywane zadaniem wykrywania zmian. Zadanie wykrywania zmian wylicza każdy plik w udziale plików, a następnie porównuje go z synchronizowaną wersją dla tego pliku. Gdy zadanie wykrywania zmian ustali, że pliki zostały zmienione, usługa Azure File Sync zainicjuje sesję synchronizacji. Zadanie wykrywania zmian jest inicjowane co 24 godziny. Zadanie wykrywania zmian działa przez wyliczanie każdego pliku w udziale plików platformy Azure, dlatego wykrywanie zmian trwa dłużej w większych przestrzeniach nazw niż w mniejszych. W przypadku dużych przestrzeni wykrywanie zmienionych plików może następować rzadziej niż raz na 24 godziny.
Aby uzyskać więcej informacji, zobacz Metryki wydajności usługi Azure File Sync i cele skalowania usługi Azure File Sync
Tożsamość
Usługa Azure File Sync współpracuje ze standardową tożsamością opartą na usłudze AD 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 Windows Server obsługuje listy ACL ad i windows stylu przez długi czas, nic nie jest potrzebne poza zapewnieniem, że serwery plików systemu Windows zarejestrowane w usłudze synchronizacji magazynu są przyłączone do domeny. Usługa Azure File Sync będzie przechowywać listy ACL w plikach w udziale plików platformy Azure i replikuje je do wszystkich punktów końcowych serwera.
Mimo że zmiany wprowadzone bezpośrednio w udziale plików platformy Azure będą trwać dłużej, aby synchronizować się z punktami końcowymi serwera w grupie synchronizacji, możesz również upewnić się, że możesz wymusić uprawnienia usługi AD w udziale plików bezpośrednio w chmurze. Aby to zrobić, należy dołączyć konto magazynu do lokalnej usługi AD, podobnie jak w przypadku przyłączania serwerów plików systemu Windows do domeny. Aby dowiedzieć się więcej na temat dołączania domeny do konta magazynu do usługi Active Directory należącej do klienta, zobacz Omówienie usługi Azure Files Active Directory.
Ważne
Domena łącząca konto magazynu z usługą Active Directory nie jest wymagana do pomyślnego wdrożenia usługi Azure File Sync. Jest to ściśle opcjonalny krok, który umożliwia udziałowi plików platformy Azure wymuszanie lokalnych list ACL, gdy użytkownicy bezpośrednio zainstalują udział plików platformy Azure.
Sieć
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, które zawsze używają protokołu HTTPS przez port 443. Protokół SMB nigdy nie jest używany do przekazywania lub pobierania danych między systemem Windows Server i udziałem plików platformy Azure. Ponieważ większość organizacji zezwala na ruch HTTPS przez port 443, zgodnie z wymaganiami dotyczącymi 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. Domyślna opcja routingu sieciowego, routing firmy Microsoft, jest obsługiwana przez funkcję Azure File Sync.
Na podstawie zasad organizacji lub unikatowych wymagań prawnych może być konieczne bardziej restrykcyjne komunikowanie się z platformą Azure, dlatego 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 ExpressRoute lub sieci VPN platformy Azure.
- Korzystaj z usług Azure Files i Azure Networking, 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.
- Ograniczanie aktywności sieciowej z usługi Azure File Sync.
Napiwek
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 protokołu SMB over QUIC, który oferuje zero-config "SMB VPN" dla dostępu SMB do udziałów plików platformy Azure przy użyciu protokołu transportowego QUIC przez port 443. Chociaż usługa Azure Files nie obsługuje bezpośrednio protokołu SMB za pośrednictwem rozwiązania QUIC, możesz utworzyć uproszczoną pamięć podręczną udziałów plików platformy Azure na maszynie wirtualnej z systemem Windows Server 2022 Azure Edition przy użyciu usługi Azure File Sync. Aby dowiedzieć się więcej na temat tej opcji, zobacz SMB over QUIC with Azure File Sync (Protokół SMB over QUIC with Azure File Sync).
Aby dowiedzieć się więcej na temat usługi Azure File Sync i sieci, zobacz Zagadnienia dotyczące sieci usługi Azure File Sync.
Szyfrowanie
W przypadku korzystania z usługi Azure File Sync istnieją trzy różne warstwy szyfrowania, które należy wziąć pod uwagę: szyfrowanie w magazynie magazynowym systemu Windows Server, szyfrowanie podczas przesyłania między agentem usługi Azure File Sync i platformą Azure oraz szyfrowanie danych magazynowanych w udziale plików platformy Azure.
Szyfrowanie w spoczynku systemu Windows Server
Istnieją dwie strategie szyfrowania danych w systemie Windows Server, które działają ogólnie z usługą Azure File Sync: szyfrowanie poniżej systemu plików, tak aby system plików i wszystkie zapisane w nim dane były szyfrowane i szyfrowanie w samym formacie pliku. Te metody nie wykluczają się wzajemnie; Można ich używać razem, jeśli jest to konieczne, 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. Głównym powodem korzystania z mechanizmu szyfrowania, takiego jak funkcja BitLocker, jest zapobieganie fizycznemu eksfiltracji danych z lokalnego centrum danych przez osobę kradnąc dyski, oraz zapobieganie ładowaniu bezpośredniemu nieautoryzowanemu systemowi operacyjnemu do wykonywania nieautoryzowanych operacji odczytu/zapisu w danych. Aby dowiedzieć się więcej na temat funkcji BitLocker, zobacz Omówienie funkcji BitLocker.
Produkty innych firm, które działają podobnie jak funkcja BitLocker, w tym, że znajdują się pod woluminem NTFS, powinny podobnie działać w pełni w sposób niewidoczny dla usługi Azure File Sync.
Drugą główną metodą szyfrowania danych jest szyfrowanie strumienia danych pliku podczas zapisywania pliku przez aplikację. Niektóre aplikacje mogą to zrobić natywnie, jednak zwykle tak nie jest. Przykładem metody szyfrowania strumienia danych pliku jest usługa Azure Information Protection (AIP)/Azure Rights Management Services (Azure RMS)/Active Directory RMS. Głównym powodem korzystania z mechanizmu szyfrowania, takiego jak AIP/RMS, jest zapobieganie eksfiltracji danych z udziału plików przez osoby kopiujące je do alternatywnych lokalizacji, takich jak dysk flash, lub wysyłanie ich 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 File System (NTFS EFS) ani rozwiązaniami szyfrowania innych firm, które znajdują się nad systemem plików, ale poniżej strumienia danych pliku.
Szyfrowanie podczas transferu
Uwaga
Usługa Azure File Sync usunęła obsługę protokołów TLS1.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 TLS1.2. Użycie wcześniejszej wersji protokołu TLS może wystąpić, jeśli protokół TLS1.2 został wyłączony na serwerze lub jest używany serwer proxy. Jeśli używasz serwera proxy, zalecamy sprawdzenie konfiguracji serwera proxy. Regiony usługi Azure File Sync dodane po 1.05.2020 obsługują tylko protokół TLS1.2. Aby uzyskać więcej informacji, zobacz przewodnik rozwiązywania problemów.
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, które 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 wymagający szyfrowania podczas przesyłania, który jest domyślnie włączony. Nawet jeśli przełącznik na poziomie konta magazynu jest wyłączony, co oznacza, że połączenia niezaszyfrowane z udziałami plików platformy Azure są możliwe, usługa Azure File Sync będzie nadal używać tylko zaszyfrowanych kanałów dostępu do udziału plików.
Głównym powodem wyłączenia szyfrowania podczas przesyłania dla konta magazynu jest obsługa starszej aplikacji, która musi być uruchomiona w starszym systemie operacyjnym, takim jak Windows Server 2008 R2 lub starsza dystrybucja systemu Linux, bezpośrednia rozmowa z udziałem plików platformy Azure. Jeśli starsza aplikacja komunikuje się z pamięcią podręczną udziału plików systemu Windows Server, przełączenie tego ustawienia nie będzie miało żadnego wpływu.
Zdecydowanie zalecamy włączenie szyfrowania przesyłanych danych.
Aby uzyskać więcej informacji na temat szyfrowania podczas przesyłania, zobacz wymaganie bezpiecznego transferu w usłudze Azure Storage.
Szyfrowanie udziałów plików platformy Azure magazynowanych
Wszystkie dane przechowywane w usłudze Azure Files są szyfrowane w spoczynku przy użyciu szyfrowania usługi Azure Storage (SSE). Szyfrowanie usługi Storage 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, ponieważ są szyfrowane na dysku, nie musisz mieć dostępu do klucza bazowego na kliencie, aby odczytywać lub zapisywać w udziale plików platformy Azure. Szyfrowanie magazynowane 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/odszyfrowywania danych i jest odpowiedzialna za ich regularne rotacje. 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 spełnienia żądań odczytu i zapisu od klientów. Za pomocą kluczy zarządzanych przez klienta można w dowolnym momencie odwołać tę autoryzację, ale oznacza to, że udział plików platformy Azure nie będzie 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 magazynu platformy Azure, takie jak Azure Blob Storage. Aby dowiedzieć się więcej na temat szyfrowania usługi Azure Storage (SSE), zobacz Szyfrowanie usługi Azure Storage dla danych magazynowanych.
Warstwy magazynowania
Usługa Azure Files oferuje dwie różne warstwy multimediów magazynu, dysków SSD i HDD, które umożliwiają dostosowanie udziałów do wymagań wydajności i cen scenariusza:
SSD (Premium): udziały plików w warstwie Premium używane przez dyski półprzewodnikowe (SSD) i zapewniają spójną wysoką wydajność i małe opóźnienia w ciągu jednej cyfry w milisekundach dla większości operacji we/wy w przypadku obciążeń intensywnie korzystających z operacji we/wy. Udziały plików w warstwie Premium są odpowiednie dla wielu różnych obciążeń, takich jak bazy danych, hosting witryn internetowych i środowiska programistyczne. Udziały plików w warstwie Premium mogą być używane zarówno z protokołami bloku komunikatów serwera (SMB) i sieciowego systemu plików (NFS). Udziały plików w warstwie Premium są wdrażane w rodzaju konta magazynu FileStorage i są dostępne tylko w modelu rozliczeń aprowizowania. Aby uzyskać więcej informacji na temat aprowizowanego modelu rozliczeniowego dla udziałów plików w warstwie Premium, zobacz Omówienie aprowizacji udziałów plików w warstwie Premium. Udziały plików w warstwie Premium oferują umowę SLA o wyższej dostępności niż standardowe udziały plików (zobacz "Warstwa Premium usługi Azure Files").
HDD (Standardowa): Standardowe udziały plików używają dysków twardych (HDD) i zapewniają ekonomiczną opcję magazynowania dla udziałów plików ogólnego przeznaczenia. Standardowe udziały plików są wdrażane w ramach konta magazynu ogólnego przeznaczenia w wersji 2 (GPv2). Aby uzyskać informacje o umowie SLA, zobacz stronę umów dotyczących poziomu usług platformy Azure (zobacz "Konta magazynu"). Standardowe udziały plików korzystają z modelu płatności zgodnie z rzeczywistym użyciem, który zapewnia ceny oparte na użyciu. Warstwa dostępu udziału plików umożliwia dostosowanie kosztów magazynu względem kosztów operacji we/wy na sekundę w celu zoptymalizowania łącznego rachunku:
- Udziały plików zoptymalizowane pod kątem transakcji oferują najniższe ceny transakcji dla dużych obciążeń transakcji, które nie wymagają małych opóźnień oferowanych przez udziały plików w warstwie Premium. Zalecane podczas migrowania danych do usługi Azure Files.
- Gorące udziały plików oferują zrównoważony magazyn i ceny transakcji dla obciążeń, które mają dobrą miarę obu.
- Chłodne udziały plików oferują najbardziej ekonomiczne ceny magazynu dla obciążeń intensywnie korzystających z magazynu.
Podczas wybierania warstwy multimediów dla obciążenia należy wziąć pod uwagę wymagania dotyczące wydajności i użycia. Jeśli obciążenie wymaga opóźnienia jednocyfrowego lub używasz lokalnego nośnika magazynu SSD, warstwa Premium jest prawdopodobnie najlepsza. Jeśli małe opóźnienie nie jest tak duże, na przykład w przypadku udziałów zespołu zainstalowanych lokalnie z platformy Azure lub buforowanych lokalnie przy użyciu usługi Azure File Sync, magazyn standardowy może być lepszym rozwiązaniem z perspektywy kosztów.
Po utworzeniu udziału plików na koncie magazynu nie można przenieść go do warstw wyłącznych na różne rodzaje kont magazynu. Aby na przykład przenieść udział plików zoptymalizowany pod kątem transakcji do warstwy Premium, należy utworzyć nowy udział plików na koncie magazynu FileStorage i skopiować dane z oryginalnego udziału do nowego udziału plików na koncie FileStorage. Zalecamy używanie narzędzia AzCopy do kopiowania danych między udziałami plików platformy Azure, ale możesz również używać narzędzi, takich jak robocopy w systemie Windows lub rsync macOS i Linux.
Aby uzyskać więcej informacji, zobacz Omówienie rozliczeń usługi Azure Files.
Dostępność regionów usługi Azure File Sync
Aby uzyskać dostępność regionalną, zobacz Dostępność produktów według regionów.
Następujące regiony wymagają zażądania dostępu do usługi Azure Storage przed rozpoczęciem korzystania z usługi Azure File Sync z nimi:
- 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 dokumencie.
Nadmiarowość
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 wymagań można wybrać różne stopnie nadmiarowości. Usługa Azure Files obecnie obsługuje następujące opcje nadmiarowości danych:
- Magazyn lokalnie nadmiarowy (LRS): W przypadku magazynu LRS każdy plik jest przechowywany trzy razy w klastrze usługi Azure Storage. Chroni to przed utratą danych z powodu błędów sprzętowych, takich jak uszkodzony dysk. Jeśli jednak w centrum danych wystąpi awaria, taka jak pożar lub powodzia, wszystkie repliki konta magazynu korzystającego z magazynu LRS mogą zostać utracone lub nieodwracalne.
- Magazyn strefowo nadmiarowy (ZRS): w przypadku magazynu ZRS przechowywane są trzy kopie każdego pliku. Jednak te kopie są fizycznie odizolowane w trzech różnych klastrach magazynu w różnych 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 magazynu GRS istnieją dwa regiony, 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. Magazyn GRS udostępnia sześć kopii danych rozmieszczonych między dwoma regionami świadczenia usługi Azure. W przypadku poważnej awarii, takiej jak trwała utrata regionu świadczenia usługi Azure z powodu klęski żywiołowej lub innego podobnego zdarzenia, firma Microsoft przeprowadzi przejście w tryb failover. W takim przypadku pomocnicza staje się podstawową obsługą wszystkich operacji. Ponieważ replikacja między regionami podstawowymi i pomocniczymi jest asynchroniczna, w przypadku poważnej awarii dane, które nie są jeszcze replikowane do regionu pomocniczego, zostaną utracone. Możesz również wykonać ręczne przejście w tryb failover konta magazynu geograficznie nadmiarowego.
- Magazyn geograficznie nadmiarowy (GZRS): magazyn GZRS można traktować jako magazyn ZRS, ale z nadmiarowością geograficzną. W przypadku magazynu GZRS pliki są przechowywane trzy razy w trzech różnych klastrach magazynu w regionie podstawowym. Wszystkie operacje zapisu są następnie asynchronicznie replikowane do regionu pomocniczego zdefiniowanego przez firmę Microsoft. Proces trybu failover dla magazynu GZRS działa tak samo jak magazyn GRS.
Standardowe udziały plików platformy Azure do 5 TiB obsługują wszystkie cztery typy nadmiarowości. Standardowe udziały plików większe niż 5 TiB obsługują tylko magazynY LRS i ZRS. Udziały plików platformy Azure w warstwie Premium obsługują tylko magazynY LRS i ZRS.
Konta magazynu ogólnego przeznaczenia w wersji 2 (GPv2) udostępniają dwie inne opcje nadmiarowości, których usługa Azure Files nie obsługuje: dostępny do odczytu magazyn geograficznie nadmiarowy (RA-GRS) i dostępny magazyn geograficznie strefowo nadmiarowy (RA-GZRS). Udziały plików platformy Azure można aprowizować na kontach magazynu przy użyciu tych opcji ustawionych, jednak usługa Azure Files nie obsługuje odczytu z regionu pomocniczego. Udziały plików platformy Azure wdrożone na kontach magazynu RA-GRS lub RA-GZRS są rozliczane odpowiednio jako MAGAZYN GRS lub GZRS.
Ważne
Magazyn geograficznie nadmiarowy i strefowo nadmiarowy ma możliwość ręcznego przełączania magazynu w tryb failover do regionu pomocniczego. Zalecamy, aby nie robić tego poza awarią w przypadku korzystania z usługi Azure File Sync z powodu zwiększonego prawdopodobieństwa utraty danych. W przypadku awarii, w której chcesz zainicjować ręczne przejście w tryb failover magazynu, należy otworzyć zgłoszenie do pomocy technicznej z firmą Microsoft, aby usługa Azure File Sync wznowiła synchronizację z pomocniczym punktem końcowym.
Migracja
Jeśli masz istniejący serwer plików systemu Windows 2012R2 lub nowszy, usługę Azure File Sync można zainstalować bezpośrednio bez konieczności przenoszenia danych na nowy serwer. Jeśli planujesz migrację do nowego serwera plików z systemem Windows w ramach wdrażania usługi Azure File Sync lub jeśli dane znajdują się obecnie w magazynie dołączonym do sieci (NAS), istnieje kilka możliwych metod migracji do korzystania z usługi Azure File Sync z tym danymi. Które podejście do migracji należy wybrać, zależy od tego, gdzie obecnie znajdują się twoje dane.
Szczegółowe wskazówki można znaleźć w artykule Azure File Sync and Azure file share migration overview (Omówienie migracji udziałów plików platformy Azure i udziału plików platformy Azure).
Antywirus
Ponieważ program antywirusowy działa przez skanowanie plików pod kątem znanego złośliwego kodu, produkt antywirusowy może spowodować wycofanie plików warstwowych, co powoduje wysokie opłaty za ruch wychodzący. Pliki warstwowe mają bezpieczny zestaw atrybutów FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS systemu Windows i zalecamy skonsultowanie się z dostawcą oprogramowania, aby dowiedzieć się, jak skonfigurować rozwiązanie, aby pominąć odczytywanie plików z tym zestawem atrybutów (wiele robi to automatycznie).
Wewnętrzne rozwiązania antywirusowe firmy Microsoft, usługi Windows Defender i programu System Center Endpoint Protection (SCEP) automatycznie pomijają odczytywanie plików, które mają ten zestaw 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 pozostaną na nowym serwerze i nie zostaną warstwowe, ponieważ nie spełniają wymagań dotyczących rozmiaru warstw (>64 kb).
Uwaga
Dostawcy oprogramowania antywirusowego mogą sprawdzić zgodność między swoim produktem a usługą Azure File Sync przy użyciu pakietu testów zgodności programu antywirusowego usługi Azure File Sync, który jest dostępny do pobrania w Centrum pobierania Microsoft.
Wykonywanie kopii zapasowej
Jeśli obsługa warstw w chmurze jest włączona, nie należy używać rozwiązań, które bezpośrednio tworzą kopię zapasową punktu końcowego serwera lub maszyny wirtualnej, na której znajduje się punkt końcowy serwera. Obsługa warstw w chmurze powoduje przechowywanie tylko podzestawu danych w punkcie końcowym serwera z pełnym zestawem danych znajdującym się w udziale plików platformy Azure. W zależności od używanego rozwiązania do tworzenia kopii zapasowych pliki warstwowe zostaną pominięte i nie zostaną utworzone kopie zapasowe (ponieważ mają FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS zestaw atrybutów) lub zostaną odwołane do dysku, co spowoduje wysokie opłaty za ruch wychodzący. Zalecamy użycie rozwiązania do tworzenia kopii zapasowych w chmurze w celu utworzenia kopii zapasowej udziału plików platformy Azure bezpośrednio. Aby uzyskać więcej informacji, zobacz Informacje o kopii zapasowej udziału plików platformy Azure lub skontaktuj się z dostawcą kopii zapasowych, aby sprawdzić, czy obsługują tworzenie kopii zapasowych udziałów plików platformy Azure.
Jeśli wolisz używać lokalnego rozwiązania do tworzenia kopii zapasowych, kopie zapasowe powinny być wykonywane na serwerze w grupie synchronizacji z wyłączoną obsługą warstw w chmurze i upewnij się, że nie ma plików warstwowych. Podczas przywracania użyj opcji przywracania na poziomie woluminu lub na poziomie pliku. Pliki przywrócone przy użyciu opcji przywracania na poziomie pliku zostaną zsynchronizowane ze wszystkimi punktami końcowymi w grupie synchronizacji, a istniejące pliki zostaną zastąpione wersją przywróconą z kopii zapasowej. Przywracanie na poziomie woluminu nie spowoduje zastąpienia nowszych wersji plików w udziale plików platformy Azure ani w innych punktach końcowych serwera.
Uwaga
Przywracanie bez systemu operacyjnego (BMR), przywracanie maszyny wirtualnej, przywracanie systemu (wbudowane przywracanie systemu operacyjnego Windows) i przywracanie na poziomie plików z wersją warstwową (dzieje się tak, gdy tworzenie kopii zapasowej pliku warstwowego zamiast pełnego pliku) może spowodować nieoczekiwane wyniki i nie są obecnie obsługiwane w przypadku włączenia obsługi warstw w chmurze. Migawki usługi VSS (w tym karta Poprzednie wersje) są obsługiwane na woluminach z włączoną obsługą obsługi warstw w chmurze. Należy jednak włączyć zgodność z poprzednią wersją za pomocą programu PowerShell. Dowiedz się, jak to zrobić.
Data Classification
Jeśli masz zainstalowane oprogramowanie do klasyfikacji danych, włączenie obsługi warstw w chmurze może spowodować zwiększenie kosztów z dwóch powodów:
Po włączeniu obsługi warstw w chmurze najgorętsze pliki są buforowane lokalnie, a najfajniejsze pliki są warstwowe do udziału plików platformy Azure w chmurze. Jeśli klasyfikacja danych regularnie skanuje wszystkie pliki w udziale plików, pliki warstwowe w chmurze muszą zostać odwołane 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 widziało klasyfikację.
Te wzrosty zarówno liczby odwołań, jak i ilości odwołanych danych 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 agentów często zawierają nowe funkcje i mają coraz większą liczbę jako pierwszą część numeru wersji. Na przykład: 17.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: 17.2.0.0
Ścieżki uaktualniania
Istnieje pięć zatwierdzonych i przetestowanych sposobów instalowania aktualizacji agenta usługi Azure File Sync.
- Użyj funkcji automatycznego uaktualniania agenta usługi Azure File Sync, aby zainstalować aktualizacje agenta. Agent usługi Azure File Sync zostanie automatycznie uaktualniony. Możesz wybrać, aby zainstalować najnowszą wersję agenta, jeśli jest dostępna lub aktualizowana, gdy aktualnie zainstalowany agent jest bliski wygaśnięcia. Aby dowiedzieć się więcej, zobacz Automatyczne zarządzanie cyklem życia agenta.
- Skonfiguruj usługę Microsoft Update, aby automatycznie pobierać i instalować aktualizacje 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 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. Najnowszy pakiet aktualizacji usługi Azure File Sync można pobrać z wykazu usługi Microsoft Update. Uruchomienie pliku wykonywalnego msp spowoduje uaktualnienie instalacji 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 spowoduje przeprowadzenie uaktualnienia w miejscu instalacji usługi Azure File Sync.
- Pobierz najnowszy instalator agenta usługi Azure File Sync z Centrum pobierania Microsoft. Aby uaktualnić istniejącą instalację agenta usługi Azure File Sync, odinstaluj starszą wersję, a następnie zainstaluj najnowszą wersję pobranego instalatora. Rejestracja serwera, grupy synchronizacji i wszystkie inne ustawienia są obsługiwane przez instalatora usługi Azure File Sync.
Uwaga
Obniżenie poziomu agenta usługi Azure File Sync nie jest obsługiwane. Nowe wersje często obejmują zmiany powodujące niezgodność w porównaniu ze starymi wersjami, dzięki czemu proces zmiany na starszą wersję nie jest obsługiwany. Jeśli wystąpią problemy z bieżącą wersją agenta, skontaktuj się z pomocą techniczną lub uaktualnij do najnowszej dostępnej wersji.
Automatyczne zarządzanie cyklem życia agenta
Agent usługi Azure File Sync zostanie automatycznie uaktualniony. Można wybrać jeden z dwóch trybów i określić okno obsługi, w którym próba uaktualnienia zostanie podjęta 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 umożliwiając bezproblemową obsługę bieżącego ustawienia.
- Ustawienie domyślne spróbuje zapobiec wygaśnięciu agenta. W ciągu 21 dni od opublikowanej daty wygaśnięcia agenta agent podejmie próbę samodzielnego uaktualnienia. Rozpocznie próbę uaktualnienia raz w tygodniu w ciągu 21 dni przed wygaśnięciem i w wybranym oknie obsługi. Ta opcja nie eliminuje potrzeby stosowania regularnych poprawek usługi Microsoft Update.
- Opcjonalnie możesz wybrać, że agent automatycznie uaktualni się natychmiast po udostępnieniu nowej wersji agenta (obecnie nie dotyczy serwerów klastrowanych). Ta aktualizacja zostanie wykonana podczas wybranego okna obsługi i umożliwi serwerowi korzystanie z nowych funkcji i ulepszeń, gdy tylko staną się one ogólnie dostępne. Jest to zalecane, bezpłatne ustawienie, które zapewni główne wersje agentów, a także regularne poprawki aktualizacji na serwerze. Każdy zwolniony agent jest w wysokiej jakości. Jeśli wybierzesz tę opcję, firma Microsoft wyświetli najnowszą wersję agenta. Serwery klastrowane są wykluczone. Po zakończeniu lotu agent stanie się również dostępny w witrynie Microsoft Update i Centrum pobierania Microsoft.
Zmiana ustawienia automatycznego uaktualniania
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 będzie to wyglądać mniej więcej tak:
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 pakiet testowy został już ukończony dla najnowszej wersji agenta, a zasady automatycznej aktualizacji agenta zostaną zmienione na InstallLatest, agent nie zostanie automatycznie uaktualniony do momentu, gdy kolejna wersja agenta zostanie zaktualizowana. Aby zaktualizować wersję agenta, która została ukończona, użyj usługi Microsoft Update lub AfsUpdater.exe. Aby sprawdzić, czy wersja agenta jest obecnie testowa, sprawdź sekcję obsługiwane wersje w informacjach o wersji.
Gwarancja cyklu życia agenta i zarządzania zmianami
Azure File Sync to usługa w chmurze, która stale wprowadza nowe funkcje i ulepszenia. Oznacza to, że określona 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ą wystarczającą ilość czasu i powiadomienia, aby uwzględnić aktualizacje/uaktualnienia agenta w procesie zarządzania zmianami:
- Wersje głównych agentów są obsługiwane przez co najmniej sześć miesięcy od daty wydania początkowego.
- Gwarantujemy, że między obsługą głównych wersji agentów występuje nakładanie się co najmniej trzech miesięcy.
- Ostrzeżenia są wydawane dla zarejestrowanych serwerów przy użyciu agenta, który wkrótce wygaśnie co najmniej trzy miesiące przed wygaśnięciem. Możesz sprawdzić, czy zarejestrowany serwer korzysta ze starszej wersji agenta w sekcji zarejestrowanych serwerów usługi synchronizacji magazynu.
- Okres istnienia wersji pomocniczej agenta jest powiązany ze skojarzoną wersją główną. Na przykład gdy agent w wersji 17.0.0.0 ma wygasać, wszystkie wersje agenta 17.*.*.* zostaną ustawione na wygaśnięcie razem.
Uwaga
Zainstalowanie wersji agenta z ostrzeżeniem o wygaśnięciu spowoduje wyświetlenie ostrzeżenia, ale powiedzie się. Próba zainstalowania lub nawiązania połączenia z wygasłą wersją agenta nie jest obsługiwana i zostanie zablokowana.