Migruj udziały plików SMB z Linuksa do hybrydowej chmury z Azure File Sync

✔️ Dotyczy: klasyczne udziały plików SMB utworzone za pomocą dostawcy zasobów Microsoft.Storage

✖️ Nie dotyczy: wszystkich udziałów plików NFS, w tym udziałów plików utworzonych przy użyciu dostawcy zasobów Microsoft.FileShares lub klasycznych udziałów plików utworzonych przy użyciu dostawcy zasobów Microsoft.Storage

Ten artykuł opisuje, jak migrować udziały plików SMB z serwera Linux z uruchomioną Sambą do instancji Windows Server oraz ustanowić hybrydowe wdrożenie w chmurze z Azure File Sync. Przewodnik obejmuje planowanie, aprowizację i korzystanie z Robocopy do przenoszenia plików przy minimalnym przestoju.

Zanim przejdziesz do tego przewodnika migracji, sprawdź, czy ma on zastosowanie w Twoim przypadku:

  • Źródło danych: lokalna pamięć masowa lub sieciowa pamięć masowa (NAS)
  • Ścieżka migracji: Linux Server z Samba ⇒ Windows Server 2016 lub nowszymi ⇒ synchronizacja z udziałami plików platformy Azure
  • Buforowanie plików lokalnych: Tak, ostatecznym celem jest wdrożenie usługi Azure File Sync.

Jeśli Twoja sytuacja jest inna, zapoznaj się z tabelą przewodników migracyjnych.

Usługa Azure File Sync działa na wystąpieniach systemu Windows Server z pamięcią bezpośrednio podłączoną (DAS). Nie obsługuje synchronizacji do i z klientami systemu Linux ani zdalnego udziału Server Message Block (SMB), ani udziałów Network File System (NFS).

W związku z tym przekształcenie wdrożenia usług plików w model hybrydowy wymaga migracji do systemu Windows Server. Ten artykuł przeprowadzi Cię przez proces planowania i wykonywania takiej migracji.

Cele migracji

Celem jest przeniesienie udziałów SMB na serwerze Linux Samba do instancji Windows Server, a następnie użycie Azure File Sync do wdrożenia w chmurze hybrydowej. Migracja ta musi być przeprowadzona w sposób gwarantujący integralność danych produkcyjnych i dostępność podczas migracji. Ten ostatni wymaga minimalnego przestoju, dzięki czemu może mieścić się w oknach obsługi lub tylko nieznacznie przekraczać regularne okna obsługi.

Omówienie migracji

Jak wspomniano w artykule Omówienie migracji usługi Azure Files, ważne jest użycie odpowiedniego narzędzia do kopiowania i podejścia. Serwer Samba systemu Linux udostępnia udziały SMB bezpośrednio w sieci lokalnej. Narzędzie Robocopy wbudowane w system Windows Server to najlepszy sposób przenoszenia plików w tym scenariuszu migracji.

Jeśli na serwerze z systemem Linux nie korzystasz z programu Samba i chcesz przeprowadzić migrację folderów do wdrożenia hybrydowego w systemie Windows Server, możesz użyć narzędzi do kopiowania systemu Linux zamiast narzędzia Robocopy. Należy pamiętać o możliwościach wierności narzędzia do kopiowania. Zapoznaj się z sekcją Podstawy migracji w artykule Omówienie migracji, aby dowiedzieć się, czego szukać w narzędziu do kopiowania.

Faza 1. Identyfikowanie liczby potrzebnych udziałów plików platformy Azure

W tym kroku określisz, jak wiele udziałów plików Azure jest potrzebnych. Pojedyncze wystąpienie systemu Windows Server (lub klaster) może synchronizować maksymalnie 30 udziałów plików 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 wyobrażenie sobie tego scenariusza jest wyobrażenie sobie lokalnego udziału, który jest mapowany 1:1 na udział plików w Azure. Jeśli masz małą 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ł 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 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 potrzebujesz tylko jednego udziału plików platformy Azure w chmurze dla tej grupy udziałów plików lokalnych.

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 przechodzą 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ższą w zakresie synchronizacji. Testujemy udziały plików platformy Azure i usługę Azure File Sync ze 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 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 w chmurze w późniejszym kroku należy utworzyć mapę między lokalnymi folderami a udziałami plików Azure. To mapowanie informuje o tym, ile i które zasoby grupy synchronizacji usługi Azure File Sync zostaną utworzone. Grupa synchronizacji łączy zasób udostępniony platformy Azure i folder na serwerze oraz ustanawia połączenie synchronizacji.

Aby zoptymalizować mapę i zdecydować, ile udziałów plików platformy Azure jest potrzebnych, 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 jest wdrażany na koncie przechowywania. Takie rozwiązanie powoduje, że konto magazynu staje się celem scalania pod kątem wydajności, takich jak IOPS i przepustowość.

    Zwróć uwagę na ograniczenia IOPS konta magazynu podczas wdrażania udziałów plików Azure. Najlepiej mapować udziały plików 1:1 przy użyciu kont magazynu. 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 najgorętszych udziałów plików na tym samym koncie magazynu.

    Jeśli planujesz przenieść aplikację na platformę Azure, która będzie natywnie korzystać z udziału plików Azure, możesz potrzebować większej wydajności tego udziału. Jeśli istnieje możliwość takiego użycia, nawet w przyszłości, najlepszym rozwiązaniem jest utworzenie jednego standardowego udziału plików Azure w jego własnym koncie magazynu.

  • Istnieje limit 250 kont magazynowania na subskrypcję na region Azure.

Wskazówka

Na podstawie tych informacji często konieczne jest zgrupowanie wielu folderów najwyższego poziomu na woluminach w nowy katalog główny, który jest wspólny dla wszystkich. Następnie zsynchronizuj ten nowy katalog główny i wszystkie foldery zgrupowane w nim do pojedynczego udziału plików platformy Azure. Ta metoda pozwala pozostać w granicy 30 synchronizacji udziałów plików Azure na jeden serwer.

Grupowanie pod wspólnym korzeniem nie ma wpływu na dostęp do twoich danych. Reguły ACL pozostają tak, jak są. Wystarczy dostosować wszystkie ścieżki udziałów (takie jak udziały SMB lub NFS), które możesz mieć w folderach serwera lokalnego, które teraz zmieniłeś na 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 Azure (przy użyciu wcześniej wspomnianego podejścia wspólnego katalogu głównego). Jednak nadal może być lepiej zorganizować ponownie foldery tak, aby synchronizowały się z dwoma udziałami plików platformy Azure zamiast z jednym. Za pomocą tego podejścia można na serwerze utrzymać zrównoważoną liczbę plików i folderów w każdym udziale plików. Możesz również podzielić udziały lokalne i zsynchronizować je na większej liczbie serwerów lokalnych, aby dodać możliwość synchronizacji z dodatkowymi 30 udziałami plików platformy 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ługiwany 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 (woluminu głównego) z docelowym udostępnianiem plików Azure. Rozpoczęcie od największego dysku/woluminu pomoże spełnić wymagania dotyczące magazynu lokalnego. Skonfiguruj warstwowanie 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 kroki jeden po drugim, dopóki wszystkie dane nie zostaną przeniesione do chmury lub całkowicie zmigrowane.
2) Docelowy jeden wolumin główny (dysk) naraz. Użyj warstwowania w chmurze, aby przenosić wszystkie dane do docelowego udziału plików Azure. Usuń punkt końcowy serwera z grupy synchronizacji, ponownie utwórz punkt końcowy używając następnego woluminu głównego/dysku, zsynchonizuj, 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 platformy Azure (tego samego lub innego konta magazynu na podstawie wymagań dotyczących wydajności).
Serwer plików z jednym woluminem i wieloma udziałami do tego samego docelowego udziału plików platformy Azure (konsolidacja) Yes Nie można mieć wielu punktów końcowych serwera dla każdego zarejestrowanego serwera synchronizujących się z tym samym docelowym udziałem plików platformy Azure (tak samo 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) Yes Pojedyncze wystąpienie systemu Windows Server (lub klaster) może synchronizować maksymalnie 30 udziałów plików Azure.

Konto magazynowe jest docelowym punktem skalowania dla wydajności. Liczba operacji we/wy na sekundę (IOPS) i przepustowość są współdzielone przez udziały plikowe.

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 zsynchronizowania).
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) Użyj dodatkowych serwerów Azure File Sync w środowisku lokalnym i podziel lub przenieś dane na te serwery, aby obejść ograniczenia związane z wystąpieniem źródłowym 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) Yes Pojedyncza instancja systemu Windows Server (lub klaster) może synchronizować do 30 udziałów plików 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 skupienia 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 doświadczyć i używać zawartości tego obrazu.

Użyj poprzednich informacji, aby określić, ile udziałów plików platformy Azure potrzebujesz i które części istniejących danych trafią do konkretnego udziału plików platformy 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.

Faza 2: Przygotuj odpowiednie wystąpienie systemu Windows Server w siedzibie

  • Utwórz instancję Windows Server jako maszynę wirtualną lub serwer fizyczny. Windows Server 2016 to minimalny wymóg. Proces migracji obsługuje również klaster przełączania awaryjnego systemu Windows Server.
  • Skonfiguruj lub dodaj bezpośrednio podłączoną pamięć (DAS) do serwera Windows. Azure File Sync nie obsługuje korzystania z sieciowej pamięci masowej (NAS) w punkcie końcowym serwera.

Ilość przydzielonego przechowywania może być mniejsza niż to, czego obecnie używasz na serwerze Samba działającym na systemie Linux. Ten wybór konfiguracji wymaga również korzystania z funkcji tieringu w chmurze usługi Azure File Sync. Jednak podczas kopiowania plików z większej przestrzeni serwera Samba systemu Linux do mniejszego woluminu systemu Windows Server w fazie późniejszej należy pracować w partiach:

  1. Przenieś zestaw plików pasujących do dysku.
  2. Zaangażuj usługę File Sync i obsługę warstw w chmurze.
  3. Po utworzeniu większej ilości wolnego miejsca na woluminie przejdź do następnej partii plików. Alternatywnie, zapoznaj się z poleceniem Robocopy w nadchodzącej sekcji Robocopy pod kątem użycia nowego /LFSM przełącznika. Użycie /LFSM może znacznie uprościć zadania Robocopy, ale nie jest kompatybilne z innymi przełącznikami Robocopy, na których możesz polegać.

Można uniknąć tego podejścia wsadowego, aprowizując równoważną przestrzeń na wystąpieniu serwera Windows, którą zajmują Państwa pliki na serwerze Samba działającym na systemie Linux. Rozważ włączenie deduplikacji w systemie Windows. Jeśli nie chcesz trwale przeznaczać tej dużej ilości miejsca na instancję systemu Windows Server, możesz zmniejszyć rozmiar woluminu po migracji i przed dostosowaniem polityk chmurowego deponowania. Spowoduje to utworzenie mniejszej lokalnej pamięci podręcznej dla udziałów plików Azure.

Konfiguracja zasobów (moc obliczeniowa i pamięć RAM) instancji Windows Server, którą wdrażasz, zależy głównie od liczby elementów (plików i folderów), które będziesz synchronizować. Jeśli masz jakiekolwiek problemy, zalecamy przejście z konfiguracją o wyższej wydajności.

Dowiedz się, jak określić rozmiar wystąpienia systemu Windows Server na podstawie liczby elementów (plików i folderów), które chcesz zsynchronizować.

Uwaga

Wcześniej połączony artykuł przedstawia tabelę z zakresem pamięci serwera (RAM). Możesz zorientować się na mniejszą liczbę w przypadku serwera, ale spodziewaj się, że początkowa synchronizacja może zająć znacznie więcej czasu.

Faza 3. Wdrażanie zasobu w chmurze usługi Azure File Sync

Podstawowy zasób do skonfigurowania dla usługi Azure File Sync jest nazywany usługą synchronizacji magazynu. Zalecamy wdrożenie tylko jednego dla wszystkich serwerów, które synchronizują ten sam zestaw plików teraz lub w przyszłości. Utwórz wiele usług synchronizacji danych tylko wtedy, gdy masz różne zestawy serwerów, które nigdy nie powinny wymieniać danych. Na przykład mogą istnieć serwery, które nigdy nie muszą synchronizować tego samego udziału plików platformy Azure. W przeciwnym razie użycie pojedynczej usługi Storage Sync Service jest najlepszą praktyką.

Wybierz region platformy Azure dla usługi synchronizacji magazynu, który znajduje się blisko twojej lokalizacji. Wszystkie inne zasoby w chmurze muszą zostać wdrożone w tym samym regionie. Aby uprościć zarządzanie, utwórz nową grupę zasobów w ramach subskrypcji na zasoby synchronizacji i magazynowania.

Aby uzyskać więcej informacji, zobacz sekcję dotyczącą wdrażania usługi synchronizacji magazynu w artykule dotyczącym wdrażania usługi Azure File Sync. Postępuj zgodnie z tą sekcją artykułu. W kolejnych krokach będą dostępne linki do innych sekcji artykułu.

Faza 4. Wdrażanie zasobów usługi Azure Storage

W tej fazie skonsultuj się z tabelą mapowania z fazy 1, aby przydzielić odpowiednią liczbę kont pamięci Azure i udostępnień plików w ich obrębie.

Udział plików platformy Azure jest przechowywany w chmurze na koncie usługi Azure Storage. W tym miejscu ma zastosowanie kolejny poziom zagadnień dotyczących wydajności.

Jeśli masz wysoce aktywne udziały (udziały używane przez wielu użytkowników i/lub aplikacje), dwa udziały plików Azure mogą osiągnąć limit wydajności konta magazynowego.

Najlepszą praktyką jest wdrożenie kont magazynowych z jednym udziałem plikowym. Możesz połączyć wiele udziałów plików Azure do tego samego konta magazynowego, jeśli masz archiwalne udziały lub spodziewasz się niskiej codziennej aktywności w nich.

Te zagadnienia dotyczą bardziej bezpośredniego dostępu do chmury (za pośrednictwem maszyny wirtualnej platformy Azure) niż do usługi Azure File Sync. Jeśli planujesz używać tylko usługi Azure File Sync w tych udziałach, grupowanie kilku na jednym koncie usługi Azure Storage jest w porządku.

Jeśli utworzono listę udziałów, należy przypisać każdy udział do konta magazynu, w którym będzie się on znajdować.

W poprzedniej fazie określono odpowiednią liczbę udziałów. W tym kroku przedstawiono mapowanie kont magazynu na udziały plików. Teraz wdróż odpowiednią liczbę kont usługi Azure Storage z odpowiednią liczbą udziałów plików platformy Azure. Szczegóły dotyczące kroków znajdziesz w artykule Utwórz klasyczny udział plików.

Upewnij się, że region każdego konta magazynu jest taki sam i odpowiada regionowi wdrożonego już zasobu usługi synchronizacji magazynu.

Klasyczne udostępnienia plików mogą mieć do 256 TiB przy modelu rozliczeniowym provisioned v2 lub 100 TiB przy provisioned v1 i pay-as-you-go. Limity według modelu rozliczeń znajdziesz w artykule Skalowalność i docelowa wydajność usługi Azure Files.

Innym zagadnieniem podczas wdrażania konta magazynowego jest nadmiarowość Azure Storage. Zobacz Opcje nadmiarowości usługi Azure Storage.

Nazwy twoich zasobów są również ważne. Na przykład, jeśli pogrupujesz wiele udostępnionych zasobów dla działu kadr w konto magazynu w usłudze Azure Storage, powinieneś odpowiednio nazwać to konto magazynu. Podobnie, podczas nadawania nazw udziałom plików na platformie Azure, warto stosować nazwy zbliżone do tych używanych dla ich lokalnych odpowiedników.

Faza 5. Wdrażanie agenta usługi Azure File Sync

W tej sekcji zainstalujesz agenta usługi Azure File Sync na swoim wystąpieniu systemu Windows Server. Azure File Sync obsługuje Windows Server 2016, 2019, 2022 i 2025 (patrz wymagania systemu operacyjnego). Zainstaluj najnowszą wersję agenta wymienioną w notatkach do wydania Azure File Sync.

Przewodnik po wdrożeniu wyjaśnia, że należy wyłączyć Internet Explorer Enhanced Security Configuration na każdym serwerze, w tym na każdym węźle klastra failover, dla początkowej rejestracji serwera. Możesz go ponownie włączyć po zarejestrowaniu serwera i możesz pominąć ten krok w Windows Server Core.

Otwórz program PowerShell. Zainstaluj wymagane moduły programu PowerShell przy użyciu następujących poleceń. Pamiętaj, aby zainstalować pełny moduł i dostawcę NuGet, gdy zostaniesz o to poproszony.

Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync

Jeśli masz jakiekolwiek problemy z dotarciem do Internetu z serwera, nadszedł czas, aby je rozwiązać. Usługa Azure File Sync używa dowolnego dostępnego połączenia sieciowego z Internetem. Użycie serwera proxy do uzyskania dostępu do Internetu jest również obsługiwane. Możesz teraz skonfigurować serwer proxy dla całej maszyny lub podczas instalacji agenta określić serwer proxy, który będzie używany tylko przez usługę Azure File Sync.

W przypadku konfigurowania serwera proxy, jeśli wymaga to otwarcia zapór sieciowych dla serwera, takie podejście może być dla Ciebie akceptowalne. Na końcu instalacji serwera po zakończeniu rejestracji serwera raport łączności sieciowej wyświetli dokładne adresy URL punktów końcowych na platformie Azure, z którymi usługa Azure File Sync musi komunikować się z wybranym regionem. Raport informuje również, dlaczego komunikacja jest potrzebna. Raport umożliwia zablokowanie zapór wokół serwera pod określonymi adresami URL.

Można również zastosować bardziej konserwatywne podejście, w którym nie otwierasz zapór. Zamiast tego można ograniczyć serwer do komunikowania się z przestrzeniami nazw DNS wyższego poziomu. Aby uzyskać więcej informacji, zobacz Ustawienia serwera proxy i zapory usługi Azure File Sync. Postępuj zgodnie z własnymi najlepszymi praktykami dotyczącymi sieci.

Na końcu kreatora instalacji serwera otworzy się kreator rejestracji serwera. Zarejestruj serwer w zasobie platformy Azure twojej usługi synchronizacji magazynu wspomnianym wcześniej.

Te kroki opisano bardziej szczegółowo w przewodniku wdrażania, który zawiera moduły programu PowerShell, które należy zainstalować najpierw: instalacja agenta usługi Azure File Sync.

Użyj najnowszego agenta. Możesz pobrać go z Centrum pobierania Microsoft: agenta usługi Azure File Sync.

Po pomyślnej instalacji i rejestracji serwera możesz potwierdzić, że ten krok został pomyślnie ukończony. Przejdź do zasobu usługi Azure Storage Sync w portalu Azure. W menu po lewej stronie przejdź do pozycji Zarejestrowane serwery. Zobaczysz tam serwer na liście.

Faza 6. Konfigurowanie usługi Azure File Sync we wdrożeniu systemu Windows Server

Zarejestrowane lokalne oprogramowanie systemu Windows Server musi być gotowe i połączone z Internetem do tego procesu.

Ten krok łączy wszystkie zasoby i foldery skonfigurowane na instancji systemu Windows Server z poprzednich etapów.

  1. Zaloguj się do witryny Azure Portal.
  2. Znajdź zasób usługi Storage Sync Service.
  3. Utwórz nową grupę synchronizacji w ramach zasobu usługi synchronizacji magazynu dla każdego udziału plików platformy Azure. W terminologii usługi Azure File Sync zasób plików Azure stanie się punktem końcowym chmury w topologii synchronizacji, którą opisujesz, tworząc grupę synchronizacji. Podczas tworzenia grupy synchronizacji nadaj jej znaną nazwę, aby rozpoznać, który zestaw plików jest tam synchronizowany. Upewnij się, że odwołujesz się do udziału plików platformy Azure o pasującej nazwie.
  4. Po utworzeniu grupy synchronizacji, wiersz dla niej pojawi się na liście grup synchronizacji. Wybierz nazwę (link), aby wyświetlić zawartość grupy synchronizacji. Będziesz widzieć udział plików Azure w obszarze Punkty końcowe chmury.
  5. Znajdź przycisk Dodaj punkt końcowy serwera . Folder na serwerze lokalnym, który został zaaprowizowany, stanie się ścieżką dla tego punktu końcowego serwera.

Ważne

Warstwowanie w chmurze to funkcja usługi Azure File Sync, która umożliwia serwerowi lokalnemu mieć mniejszą pojemność magazynową niż ta przechowywana w chmurze, a mimo to mieć dostępne pełne nazewnictwo. Lokalnie interesujące dane są również buforowane lokalnie w celu uzyskania szybkiej wydajności dostępu. Warstwowanie w chmurze to opcjonalna funkcja dla każdego punktu końcowego serwera w Azure File Sync.

Ostrzeżenie

Jeśli przydzieliłeś mniej miejsca na woluminach Windows Server niż ilość danych przechowywana na serwerze Samba z systemem Linux, obsługa warstw w chmurze jest obowiązkowa. Jeśli nie włączysz tieringu w chmurze, serwer nie zwolni miejsca na przechowywanie wszystkich plików. Ustaw tymczasowo zasadę tieringu na 99% wolnego miejsca dla woluminu w czasie migracji. Pamiętaj, aby powrócić do ustawień tieringu w chmurze po zakończeniu migracji i ustawić politykę na bardziej odpowiedni poziom na dłuższą metę.

Powtórz kroki tworzenia grupy synchronizacji i dodanie pasującego folderu serwera jako punktu końcowego serwera dla wszystkich udziałów plików platformy Azure i wszystkich lokalizacji serwerów, które trzeba skonfigurować do synchronizacji.

Po utworzeniu wszystkich punktów końcowych serwera synchronizacja działa. Stwórz plik testowy i zobacz, jak jest synchronizowany z lokalizacji serwera do połączonego udziału plików Azure (zgodnie z opisem punktu końcowego chmury w grupie synchronizacji).

Obie lokalizacje, foldery serwera i udziały plików platformy Azure są w przeciwnym razie puste i oczekują na dane. W następnym kroku zaczniesz kopiować pliki do wystąpienia systemu Windows Server dla usługi Azure File Sync, aby przenieść je do chmury. Jeśli włączono obsługę warstw w chmurze, serwer zacznie warstwować pliki, jeśli zabraknie pojemności na woluminach lokalnych.

Faza 7. Robocopy

Podstawową metodą migracji jest użycie narzędzia Robocopy do kopiowania plików i synchronizowania za pomocą usługi Azure File Sync.

Uruchom pierwszą kopię lokalną do folderu docelowego systemu Windows Server:

  1. Zidentyfikuj pierwszą lokalizację na serwerze Samba systemu Linux.
  2. Zidentyfikuj odpowiadający folder na instancji systemu Windows Server, który ma już skonfigurowaną usługę Azure File Sync.
  3. Uruchom kopię przy użyciu narzędzia Robocopy.

Poniższe polecenie Robocopy kopiuje pliki z pamięci Twojego serwera Linux Samba do folderu docelowego Windows Server. Windows Server synchronizuje je z udziałami plików platformy Azure.

Jeśli przydzieliłeś mniej miejsca na dysku w instancji Windows Server, niż zajmują twoje pliki na serwerze Samba w systemie Linux, skonfigurowano warstwowanie w chmurze. Gdy lokalny wolumin systemu Windows Server się zapełnia, rozpoczyna się warstwowanie w chmurze, które przenosi warstwowo pliki, które zostały już pomyślnie zsynchronizowane. Tiering do chmury generuje wystarczająco dużo miejsca, aby kontynuować kopiowanie z serwera Samba Linux. Warstwowa synchronizacja w chmurze odbywa się raz na godzinę, aby sprawdzić, co zostało zsynchronizowane i zwolnić miejsce na dysku, aby osiągnąć politykę 99 procent wolnego miejsca dla woluminu.

Możliwe, że narzędzie Robocopy przenosi pliki szybciej niż można je zsynchronizować z chmurą i tierować lokalnie, co może powodować brak miejsca na lokalnym dysku. Działanie Robocopy kończy się niepowodzeniem. Zalecamy pracę nad udziałami w takiej kolejności, która zapobiega problemowi. Nie uruchamiaj na przykład zadań Robocopy dla wszystkich zasobów współdzielonych w tym samym czasie. Możesz też rozważyć przeniesienie udziałów, które mieszczą się w bieżącej ilości wolnego miejsca w wystąpieniu systemu Windows Server. Jeśli zadanie Robocopy zakończy się niepowodzeniem, zawsze można ponownie uruchomić polecenie, pod warunkiem że użyjesz następującej opcji lustrzanej/przeczyszczającej:

robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>
Przełącznik Znaczenie
/MT:n Umożliwia uruchomienie Robocopy w trybie wielowątkowym. Wartość domyślna to n 8. Maksymalna liczba wątków to 128. Chociaż duża liczba wątków pomaga usycić dostępną przepustowość, nie oznacza to, że migracja zawsze będzie szybsza z większą liczbą wątków. Testy z Azure Files wskazują, że dla początkowego przebiegu kopiowania pomiędzy 8 a 20 jednostek wydajności zapewnia zrównoważoną pracę. Kolejne /MIR uruchomienia są stopniowo dotknięte dostępną wydajnością obliczeniową w porównaniu do dostępnej przepustowości sieci. W przypadku kolejnych przebiegów dopasuj wartość liczby wątków bardziej do liczby rdzeni procesora i liczby wątków na rdzeń. Zastanów się, czy rdzenie muszą być zarezerwowane dla innych zadań, które może mieć serwer produkcyjny. Testy w usłudze Azure Files wykazały, że maksymalnie 64 wątki generują dobrą wydajność, ale tylko wtedy, gdy procesory mogą utrzymać je w tym samym czasie.
/R:n Maksymalna liczba ponownych prób dla pliku, którego nie można skopiować podczas pierwszej próby. Robocopy spróbuje n razy, zanim plik zostanie uznany za trwały błąd kopiowania w przebiegu. Możesz zoptymalizować wydajność przebiegu: wybierz wartość dwa lub trzy, jeśli uważasz, że problemy z przekroczeniem limitu czasu spowodowały awarie w przeszłości. Może to być bardziej typowe w przypadku łączy sieci WAN. Jeżeli uważasz, że plik nie skopiował się, ponieważ był aktywnie używany, wybierz brak prób ponowienia lub wartość jeden. Próba ponownie kilka sekund później może nie być wystarczająca do zmiany stanu w użyciu pliku. Użytkownicy lub aplikacje z otwartym plikiem mogą potrzebować dodatkowych godzin. W takim przypadku przyjęcie, że plik nie został skopiowany i zauważenie tego w jednym z zaplanowanych, późniejszych uruchomień Robocopy, może doprowadzić do ostatecznego pomyślnego skopiowania pliku. Pomaga to w szybszym zakończeniu bieżącego procesu, bez znacznego opóźniania go przez liczne ponowne próby, które często prowadzą do błędów kopiowania z powodu plików, które pozostają otwarte po przekroczeniu limitu czasu na ponowne próby.
/W:n Określa czas oczekiwania narzędzia Robocopy przed próbą skopiowania pliku, który nie został pomyślnie skopiowany podczas poprzedniej próby. n to liczba sekund oczekiwania między ponowną próbą. /W:n jest często używany razem z /R:n.
/B Uruchamia narzędzie Robocopy w tym samym trybie, który będzie używany przez aplikację do tworzenia kopii zapasowych. Ten przełącznik umożliwia programowi Robocopy przenoszenie plików, dla których bieżący użytkownik nie ma uprawnień. Przełącznik kopii zapasowej zależy od uruchomienia polecenia Robocopy w konsoli z podwyższonym poziomem uprawnień administratora lub w oknie programu PowerShell. Jeśli używasz narzędzia Robocopy dla usługi Azure Files, upewnij się, że montujesz udział plików Azure za pomocą klucza dostępu do konta magazynu zamiast używać tożsamości domeny. Jeśli tego nie zrobisz, komunikaty o błędach mogą nie prowadzić intuicyjnie do rozwiązania problemu.
/MIR (Tworzenie lustrzanego odbicia źródła na element docelowy). Umożliwia programowi Robocopy kopiowanie tylko różnic między elementem źródłowym i docelowym. Puste podkatalogi zostaną skopiowane. Elementy (pliki lub foldery), które zostały zmienione lub nie istnieją w obiekcie docelowym, zostaną skopiowane. Elementy, które istnieją w obiekcie docelowym, ale nie w źródle, zostaną przeczyszczone (usunięte) z obiektu docelowego. Gdy używasz tego przełącznika, dokładnie dopasuj struktury folderów źródłowych i docelowych. Dopasowanie oznacza skopiowanie z poprawnego poziomu źródła i folderu do odpowiadającego poziomu folderu docelowego. Tylko wtedy może zakończyć się powodzeniem kopia "nadrobienia zaległości". Gdy występuje niezgodność między źródłem a celem, użycie /MIR doprowadzi do usunięć i ponownych kopii na dużą skalę.
/IT Zapewnia zachowanie wierności w niektórych scenariuszach dublowania.
Jeśli na przykład plik napotyka zmianę listy ACL i aktualizację atrybutu między dwoma przebiegami narzędzia Robocopy, jest on oznaczony jako ukryty. Bez /IT elementu zmiana ACL może zostać pominięta przez narzędzie Robocopy i nie zostanie przeniesiona do lokalizacji docelowej.
/COPY:[copyflags] Wierność kopii pliku. Wartość domyślna: /COPY:DAT. Flagi kopiowania: D= Dane, A= Atrybuty, T= Znaczniki czasu, S= Zabezpieczenia = LISTY ACL NTFS, O= Informacje o właścicielu, U= Informacje o audycie. Nie można przechowywać informacji inspekcji w udziale plików platformy Azure.
/DCOPY:[copyflags] Wierność kopii katalogów. Wartość domyślna: /DCOPY:DA. Flagi kopiowania: D= Dane, A= Atrybuty, T= Znaczniki czasu.
/NP Określa, że postęp kopiowania dla każdego pliku i folderu nie będzie wyświetlany. Wyświetlanie postępu znacznie obniża wydajność kopiowania.
/NFL Określa, że nazwy plików nie są rejestrowane. Poprawia wydajność kopiowania.
/NDL Określa, że nazwy katalogów nie są rejestrowane. Poprawia wydajność kopiowania.
/XD Określa katalogi, które mają być wykluczone. Podczas uruchamiania Robocopy w katalogu głównym woluminu rozważ wykluczenie folderu ukrytego System Volume Information. Jeśli są używane zgodnie z zamierzeniem, wszystkie informacje tam zawarte są specyficzne dla danego wolumenu w tym systemie i można je odtworzyć na życzenie. Kopiowanie tych informacji nie będzie przydatne w chmurze ani kiedy dane są kiedykolwiek kopiowane z powrotem do innego woluminu systemu Windows. Pozostawienie tej zawartości nie powinno być traktowane jako utrata danych.
/UNILOG:<file name> Zapisuje status w pliku dziennika jako Unicode. (Zastępuje istniejący dziennik).
/L Tylko do testowania
Pliki mają być jedynie wyświetlone na liście. Nie zostaną skopiowane, nie zostaną usunięte ani oznaczone znacznikiem czasu. Często używane z /TEE do danych wyjściowych na konsolę. Może być konieczne usunięcie flag z przykładowego skryptu, takiego jak /NP, /NFLi /NDL, w celu uzyskania prawidłowych udokumentowanych wyników testu.
/LFSM Tylko dla celów z magazynowaniem warstwowym. Nieobsługiwane, kiedy miejsce docelowe to zdalny udział SMB.
Określa, że narzędzie Robocopy działa w trybie małej dostępności przestrzeni dyskowej. Ten przełącznik jest przydatny tylko w przypadku docelowych zasobów z magazynem warstwowym, w którym może zabraknąć lokalnej pojemności przed zakończeniem działania narzędzia Robocopy. Dodano ją specjalnie do użycia z celem obsługującym warstwowanie w chmurze usługi Azure File Sync. Można go używać niezależnie od usługi Azure File Sync. W tym trybie narzędzie Robocopy zostanie wstrzymane za każdym razem, gdy kopia pliku spowoduje, że wolne miejsce na woluminie docelowym spadnie poniżej określonej wartości "floor". Tę wartość można określić za pomocą /LFSM:n formularza flagi. Parametr n jest określony w bazie 2: nKB, nMBlub nGB. Jeśli /LFSM nie określono jawnej wartości minimalnej, to minimalna wartość zostanie ustawiona na 10 procent rozmiaru woluminu docelowego. Tryb małej ilości wolnego miejsca nie jest zgodny z elementami /MT, /EFSRAWlub /ZB. Obsługa /B została dodana w Windows Server 2022. Zobacz sekcję Windows Server 2022 i RoboCopy LFSM poniżej, aby uzyskać więcej informacji, w tym szczegółowe informacje na temat powiązanej usterki i obejścia.
/Z Używaj ostrożnie
Kopiuje pliki w trybie ponownego uruchamiania. Ten przełącznik jest zalecany tylko w niestabilnym środowisku sieciowym. Znacznie zmniejsza wydajność kopiowania z powodu dodatkowego dziennikowania.
/ZB Używaj ostrożnie
Używa trybu ponownego uruchamiania. Jeśli dostęp zostanie odrzucony, ta opcja używa trybu tworzenia kopii zapasowej. Ta opcja znacznie zmniejsza wydajność kopiowania z powodu tworzenia punktów kontrolnych.

Ważne

Jeśli to możliwe, użyj Windows Server 2022 lub nowszego. Jeśli używasz Windows Server 2019, zainstaluj najnowszą aktualizację kumulatywną lub przynajmniej aktualizację systemu operacyjnego KB5005102, która zawiera ważne poprawki dla niektórych scenariuszy Robocopy.

Narzędzie RoboCopy może zgłaszać, że pliki zostały skopiowane nawet wtedy, gdy transfer danych nie był konieczny. Takie zachowanie występuje, ponieważ narzędzie Robocopy ocenia zarówno dane pliku, jak i zmiany metadanych podczas tworzenia danych wyjściowych. Aby poprawnie interpretować wyniki, przejrzyj stan pliku w danych wyjściowych polecenia:

  • Nowsze: dane pliku są kopiowane do miejsca docelowego.
  • Zmodyfikowane: tylko metadane są aktualizowane; dane pliku nie są kopiowane.

W obu przypadkach narzędzie RoboCopy może zgłaszać liczbę bajtów tak, jakby dane zostały przesłane. To zachowanie może prowadzić do nieporozumień podczas walidacji operacji kopiowania.

Faza 8: Przełączenie użytkownika

Po uruchomieniu polecenia Robocopy po raz pierwszy użytkownicy i aplikacje nadal uzyskują dostęp do plików na serwerze Samba systemu Linux i potencjalnie je zmieniają. Możliwe, że narzędzie Robocopy przetworzyło katalog i przechodzi do następnego, a następnie użytkownik w lokalizacji źródłowej (Linux) dodaje, zmienia lub usuwa plik, który nie będzie teraz przetwarzany w tym bieżącym uruchomieniu narzędzia Robocopy. To zachowanie jest oczekiwane.

Pierwszy przebieg polega na przeniesieniu większości danych do instancji Windows Server i do chmury za pośrednictwem usługi Microsoft Azure File Sync. To pierwsze kopiowanie może zająć sporo czasu, w zależności od:

  • Twoja przepustowość pobierania
  • Prędkość wysyłania
  • Prędkość sieci lokalnej i to, na ile liczba wątków Robocopy jest do niej dopasowana
  • Liczba elementów (plików i folderów), które Robocopy i Azure File Sync muszą przetworzyć

Po zakończeniu początkowego uruchomienia wykonaj polecenie ponownie. Kończy się szybciej po raz drugi, ponieważ musi przesyłać tylko zmiany, które wystąpiły od ostatniego uruchomienia. Podczas tego drugiego przebiegu nowe zmiany mogą nadal gromadzić się.

Powtarzaj ten proces, dopóki nie będziesz usatysfakcjonowany, że czas potrzebny na ukończenie operacji Robocopy dla określonej lokalizacji mieści się w akceptowalnym zakresie przestoju.

Jeśli uważasz przestój za akceptowalny i jesteś gotów przejść do trybu offline dla lokalizacji Linux, możesz zmienić listy kontroli dostępu w katalogu głównym udziału, aby użytkownicy nie mogli już uzyskać dostępu do tej lokalizacji. Możesz też wykonać dowolny inny odpowiedni krok, który uniemożliwia zmianę zawartości w tym folderze na serwerze z systemem Linux.

Uruchom jedną ostatnią rundę robocopy. Rejestruje wszelkie zmiany, które mogły zostać przeoczone. Czas wykonywania tego ostatniego kroku zależy od szybkości skanowania za pomocą narzędzia Robocopy. Możesz oszacować czas (który odpowiada Twojemu przestojowi), mierząc, ile trwało poprzednie uruchomienie.

Utwórz zasób udostępniony w folderze systemu Windows Server i ewentualnie dostosuj wdrożenie DFS-N, aby na niego wskazywało. Pamiętaj, aby ustawić te same uprawnienia na poziomie udziału jak na udziałach SMB serwera Samba na systemie Linux. Jeśli używasz użytkowników lokalnych na serwerze Samba systemu Linux, musisz ponownie utworzyć tych użytkowników jako użytkowników lokalnych systemu Windows Server. Należy również zamapować istniejące identyfikatory SID, które Robocopy przeniósł na Twoje wystąpienie systemu Windows Server, do identyfikatorów SID nowych lokalnych użytkowników systemu Windows Server. Jeśli używałeś kont Active Directory i ACL, Robocopy przenosi je w obecnej formie i nie jest potrzebna dalsza akcja.

Zakończono migrację udziału lub grupy udziałów do wspólnego katalogu głównego lub woluminu (w zależności od mapowania z fazy 1).

Spróbuj uruchomić kilka takich kopii równolegle. Zalecamy przetwarzanie jednego zakresu udziału plików platformy Azure jednocześnie.

Ostrzeżenie

Po przeniesieniu wszystkich danych z serwera Samba działającego na systemie Linux do instancji Windows Server i zakończeniu migracji, wróć do wszystkich grup synchronizacji w Azure Portal. Dostosuj wartość procentową wolnego miejsca dla woluminu warstwowego w chmurze, aby lepiej odpowiadało wykorzystaniu pamięci podręcznej, na przykład 20 procent.

Zasady dotyczące wolnego miejsca w woluminie warstwowania w chmurze działają na poziomie woluminu, a z niego może być synchronizowanych wiele punktów końcowych serwera. Jeśli zapomnisz zmienić wolną przestrzeń choćby na jednym punkcie końcowym serwera, synchronizacja nadal stosuje najbardziej restrykcyjną zasadę i stara się utrzymać wolną przestrzeń na dysku na poziomie 99 procent. Lokalna pamięć podręczna może nie działać zgodnie z oczekiwaniami. Wydajność może być akceptowalna, jeśli twoim celem jest posiadanie przestrzeni nazw dla woluminu, który zawiera tylko rzadko używane dane archiwalne, i rezerwujesz pozostałą część miejsca do magazynowania w innym scenariuszu.

Rozwiązywanie błędów z powodu pełnego woluminu

Najczęstszym problemem jest to, że polecenie Robocopy kończy się niepowodzeniem z komunikatem Volume full po stronie Windows Server. Warstwowanie w chmurze uruchamia się co godzinę, aby wycofać zsynchronizowaną zawartość z dysku lokalnego na serwerze Windows. Jego celem jest osiągnięcie 99 procent wolnego miejsca na woluminie.

Pozwól, aby postęp synchronizacji i tiering w chmurze zwolniły miejsce na dysku. Obserwuj postęp w Eksploratorze plików w systemie Windows Server.

Jeśli instancja systemu Windows Server ma wystarczającą ilość dostępnej pojemności, ponowne wykonanie polecenia rozwiąże problem. Nic się nie psuje, gdy wejdziesz w tę sytuację, i możesz iść do przodu z pewnością siebie. Niedogodności związane z ponownym uruchomieniem polecenia są jedyną konsekwencją.

Dodatkową pomoc można znaleźć w artykule Azure File Sync troubleshooting.

Dalsze kroki

Poniższe artykuły zawierają zaawansowane opcje, najlepsze rozwiązania i pomoc dotyczącą rozwiązywania problemów dla usługi Azure File Sync.

  • Ostatnia aktualizacja o