Udostępnij za pośrednictwem

Migrowanie z systemu Linux do wdrożenia chmury hybrydowej za pomocą usługi Azure File Sync

  • Artykuł

Ten artykuł migracji jest jednym z kilku z udziałem słów kluczowych NFS i Azure File Sync. Sprawdź, czy ten artykuł ma zastosowanie do twojego scenariusza:

  • Źródło danych: magazyn dołączony do sieci (NAS)
  • Trasa migracji: System Linux Server z ⇒ windows Server 2012R2 lub nowszym ⇒ synchronizacji z udziałami plików platformy Azure
  • Buforowanie plików lokalnych: Tak, ostatecznym celem jest wdrożenie usługi Azure File Sync.

Jeśli twój scenariusz jest inny, zapoznaj się z tabelą przewodników migracji.

Usługa Azure File Sync działa w wystąpieniach systemu Windows Server z bezpośrednim dołączonym magazynem (DAS). Nie obsługuje synchronizacji z klientami systemu Linux ani zdalnego udziału bloku komunikatów serwera (SMB) ani udziałów sieciowego systemu plików (NFS).

W związku z tym przekształcenie usług plików w wdrożenie hybrydowe powoduje, że migracja do systemu Windows Server jest niezbędna. Ten artykuł przeprowadzi Cię przez proces planowania i wykonywania takiej migracji.

Dotyczy

Typ udziału plików SMB NFS
Udziały plików w warstwie Standardowa (GPv2), LRS/ZRS Tak Nie
Udziały plików w warstwie Standardowa (GPv2), GRS/GZRS Tak Nie
Udziały plików w warstwie Premium (FileStorage), LRS/ZRS Tak Nie.

Cele migracji

Celem jest przeniesienie udziałów na serwerze Samba systemu Linux do wystąpienia systemu Windows Server. Następnie użyj usługi Azure File Sync do wdrożenia chmury hybrydowej. Ta migracja musi odbywać się w sposób gwarantujący integralność danych produkcyjnych i dostępności 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, 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

Diagram przedstawiający przykład tabeli mapowania. Pobierz następujący plik, aby użyć zawartości tego obrazu i go użyć.

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.


Ikona programu Excel, która ustawia kontekst pobierania. Pobierz szablon mapowania przestrzeni nazw.

Faza 2. Aprowizuj odpowiednie wystąpienie systemu Windows Server lokalnie

  • Utwórz wystąpienie systemu Windows Server 2022 jako maszynę wirtualną lub serwer fizyczny. Windows Server 2012 R2 jest minimalnym wymaganiem. Klaster trybu failover systemu Windows Server jest również obsługiwany.

  • Aprowizuj lub dodaj bezpośrednio dołączony magazyn (DAS). Magazyn dołączony do sieci (NAS) nie jest obsługiwany.

    Ilość miejsca do aprowizacji może być mniejsza niż ilość miejsca, z którego korzystasz obecnie na serwerze Samba systemu Linux, jeśli używasz funkcji obsługi warstw w chmurze usługi Azure File Sync.

Ilość aprowiznego magazynu może być mniejsza niż to, czego obecnie używasz na serwerze Samba systemu Linux. Ten wybór konfiguracji wymaga również korzystania z funkcji obsługi warstw 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, aby użyć nowego /LFSM przełącznika. Użycie /LFSM może znacznie uprościć zadania narzędzia RoboCopy, ale nie jest zgodne z innymi przełącznikami RoboCopy, od których może zależeć.

Można uniknąć tego podejścia wsadowego, aprowizuj równoważne miejsce w wystąpieniu systemu Windows Server, które pliki zajmują na serwerze Samba systemu Linux. Rozważ włączenie deduplikacji w systemie Windows. Jeśli nie chcesz trwale zatwierdzać tej dużej ilości miejsca do wystąpienia systemu Windows Server, możesz zmniejszyć rozmiar woluminu po migracji i przed dostosowaniem zasad obsługi warstw w chmurze. Spowoduje to utworzenie mniejszej lokalnej pamięci podręcznej udziałów plików platformy Azure.

Konfiguracja zasobów (obliczenia i pamięć RAM) wdrożonego wystąpienia systemu Windows Server zależy głównie od liczby elementów (plików i folderów), które będą synchronizowane. 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 należy zsynchronizować.

Uwaga

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

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

Aby wykonać ten krok, potrzebne są poświadczenia subskrypcji platformy Azure.

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 magazynu tylko wtedy, gdy masz różne zestawy serwerów, które nigdy nie muszą 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 synchronizacji magazynu jest najlepszym rozwiązaniem.

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, która zawiera zasoby synchronizacji i magazynu.

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 zapoznaj się z tabelą mapowania z fazy 1 i użyj jej do aprowizacji prawidłowej liczby kont magazynu platformy Azure i udziałów plików w nich.

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 platformy Azure mogą osiągnąć limit wydajności konta magazynu.

Najlepszym rozwiązaniem jest wdrożenie kont magazynu z jednym udziałem plików. Możesz połączyć wiele udziałów plików platformy Azure z tym samym kontem magazynu, jeśli masz udziały archiwalne lub spodziewasz się w nich niskiej aktywności dnia.

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 zamapować każdy udział na konto magazynu, w którym będzie on znajdować się.

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.

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

Uwaga

Jeśli tworzysz udział plików platformy Azure z limitem 100 TiB, ten udział może używać tylko opcji nadmiarowości magazynu lokalnie nadmiarowego lub strefowo nadmiarowego magazynu. Przed użyciem 100 udziałów plików TiB należy wziąć pod uwagę potrzeby nadmiarowości magazynu.

Udziały plików platformy Azure są nadal tworzone z limitem 5 TiB domyślnie. Wykonaj kroki opisane w temacie Tworzenie udziału plików platformy Azure, aby utworzyć duży udział plików.

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

Nazwy zasobów są również ważne. Jeśli na przykład pogrupujesz wiele udziałów dla działu kadr na konto usługi Azure Storage, należy odpowiednio nazwać konto magazynu. Podobnie podczas nadawania nazw udziałom plików platformy Azure należy używać nazw podobnych do 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 w wystąpieniu systemu Windows Server.

W przewodniku wdrażania wyjaśniono, że należy wyłączyć konfigurację zwiększonych zabezpieczeń programu Internet Explorer. Ta miara zabezpieczeń nie ma zastosowania w usłudze Azure File Sync. Wyłączenie go umożliwia uwierzytelnianie na platformie Azure bez żadnych problemów.

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 po wyświetleniu monitu o to.

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. Wymagane jest również skontaktowanie się z Internetem przez serwer proxy. 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 oznacza, że musisz otworzyć zapory dla serwera, takie podejście może być 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 rozwiązaniami dotyczącymi sieci.

Na końcu kreatora instalacji serwera zostanie otwarty kreator rejestracji serwera. Zarejestruj serwer w zasobie platformy Azure usługi synchronizacji magazynu z wcześniejszej wersji.

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: Agent 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 synchronizacji magazynu w witrynie Azure Portal. W menu po lewej stronie przejdź do pozycji Zarejestrowane serwery. Zobaczysz tam serwer.

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

Zarejestrowane lokalne wystąpienie systemu Windows Server musi być gotowe i połączone z Internetem na potrzeby tego procesu.

Ten krok łączy wszystkie zasoby i foldery skonfigurowane w wystąpieniu systemu Windows Server podczas poprzednich kroków.

  1. Zaloguj się w witrynie Azure Portal.
  2. Znajdź zasób usługi synchronizacji magazynu.
  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 udział plików platformy Azure stanie się punktem końcowym chmury w topologii synchronizacji, którą opisujesz podczas tworzenia grupy 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 zostanie wyświetlony wiersz na liście grup synchronizacji. Wybierz nazwę (link), aby wyświetlić zawartość grupy synchronizacji. Zobaczysz udział plików platformy 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

Obsługa warstw w chmurze to funkcja usługi Azure File Sync, która umożliwia serwerowi lokalnemu mniej miejsca do magazynowania niż jest przechowywana w chmurze, ale ma pełną przestrzeń nazw. Lokalnie interesujące dane są również buforowane lokalnie w celu uzyskania szybkiej wydajności dostępu. Obsługa warstw w chmurze to opcjonalna funkcja dla każdego punktu końcowego serwera usługi Azure File Sync.

Ostrzeżenie

Jeśli aprowizujesz mniej miejsca na woluminach systemu Windows Server niż dane używane na serwerze Samba systemu Linux, obsługa warstw w chmurze jest obowiązkowa. Jeśli nie włączysz obsługi warstw w chmurze, serwer nie zwolni miejsca do przechowywania wszystkich plików. Ustaw zasady obsługi warstw tymczasowo dla migracji na 99% wolnego miejsca dla woluminu. Pamiętaj, aby powrócić do ustawień obsługi warstw w chmurze po zakończeniu migracji i ustawić zasady na bardziej przydatny poziom dla dłuższego okresu.

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 lokalizacji serwera, które należy skonfigurować do synchronizacji.

Po utworzeniu wszystkich punktów końcowych serwera synchronizacja działa. Możesz utworzyć plik testowy i zobaczyć, jak jest synchronizowany z lokalizacji serwera z połączonym udziałem plików platformy 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 pasujący folder w wystąpieniu systemu Windows Server, który ma już skonfigurowaną usługę Azure File Sync.
  3. Uruchom kopię przy użyciu narzędzia Robocopy.

Następujące polecenie Robocopy spowoduje skopiowanie plików z magazynu serwera Samba systemu Linux do folderu docelowego systemu Windows Server. System Windows Server zsynchronizuje go z udziałami plików platformy Azure.

Jeśli aprowizowaliśmy mniej miejsca w wystąpieniu systemu Windows Server niż pliki zajmują się serwerem Samba systemu Linux, skonfigurowano obsługę warstw w chmurze. W miarę jak lokalny wolumin systemu Windows Server jest pełny, obsługa warstw w chmurze rozpocznie pliki i warstwy, które zostały już pomyślnie zsynchronizowane. Obsługa warstw w chmurze wygeneruje wystarczającą ilość miejsca, aby kontynuować kopię z serwera Samba systemu Linux. Sprawdzanie warstw w chmurze raz na godzinę w celu sprawdzenia, co zostało zsynchronizowane, i zwolnienia miejsca na dysku w celu osiągnięcia zasad 99 procent wolnego miejsca dla woluminu.

Możliwe, że narzędzie Robocopy przenosi pliki szybciej niż można zsynchronizować z chmurą i warstwą lokalnie, co powoduje brak miejsca na dysku lokalnym. Narzędzie Robocopy zakończy się niepowodzeniem. Zalecamy pracę z udziałami w sekwencji, która zapobiega problemowi. Rozważmy na przykład, aby nie uruchamiać zadań robocopy dla wszystkich udziałów 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, o ile używasz następującej opcji dublowania/przeczyszczania:

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 wielowątkowe uruchomienie narzędzia Robocopy. 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 usługą Azure Files wskazują między 8 a 20 pokazuje zrównoważoną wydajność początkowego przebiegu kopiowania. Kolejne /MIR uruchomienia są stopniowo dotknięte dostępną przepustowością obliczeniową a dostępną przepustowością sieci. W przypadku kolejnych przebiegów dokładniej dopasuj liczbę wątków do liczby rdzeni procesora i liczby wątków na rdzeń. Zastanów się, czy trzeba zarezerwować rdzenie dla innych zadań serwera produkcyjnego. 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 udało się skopiować przy pierwszej próbie. Narzędzie Robocopy spróbuje czasy n przed trwałym niepowodzeniem kopiowania pliku w przebiegu. Możesz zoptymalizować wydajność przebiegu: wybierz wartość dwóch lub trzech, jeśli uważasz, że problemy z przekroczeniem limitu czasu spowodowały błędy w przeszłości. Może to być bardziej typowe w przypadku łączy sieci WAN. Jeśli uważasz, że plik nie może skopiować pliku, ponieważ był aktywnie używany, wybierz wartość bez ponawiania prób. 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ć więcej godzin. W takim przypadku zaakceptowanie pliku nie zostało skopiowane i przechwycenie go w jednym z planowanych przebiegów narzędzia Robocopy może zakończyć się pomyślnie skopiowaniem pliku. Pomaga to w szybszym zakończeniu bieżącego przebiegu bez przedłużania przez wiele ponownych prób, które ostatecznie kończą się w większości błędów kopiowania z powodu plików nadal otwartych poza limitem czasu ponawiania prób.
/W:n Określa czas, przez który narzędzie Robocopy czeka, zanim podejmie 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órego użyłaby aplikacja do tworzenia kopii zapasowych. Ten przełącznik umożliwia narzędziu Robocopy przenoszenie plików, do 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 udział plików platformy Azure został zamontowany przy użyciu klucza dostępu do konta magazynu w porównaniu z tożsamością domeny. Jeśli tego nie zrobisz, komunikaty o błędach mogą nie prowadzić intuicyjnie do rozwiązania problemu.
/MIR (Duplikuj źródło do miejsca docelowego) Umożliwia programowi Robocopy kopiowanie tylko różnic między obiektem źródłowym i docelowym. Puste podkatalogi zostaną skopiowane. Elementy (pliki lub foldery), które uległy zmianie lub nie istnieją w miejscu docelowym, zostaną skopiowane. Elementy, które istnieją w miejscu docelowym, ale nie ma ich w źródle, zostaną wyczyszczone (usunięte) z miejsca docelowego. W przypadku korzystania z tego przełącznika dokładnie dopasuj strukturę folderu źródłowego i docelowego. Dopasowanie oznacza skopiowanie z poprawnego poziomu źródła i folderu do pasującego poziomu folderu w obiekcie docelowym. Tylko wtedy tworzenie kopii na zasadzie „nadrobienia zaległości” może zakończyć się powodzeniem. Gdy źródło i cel są niezgodne, użycie /MIR metody spowoduje usunięcie i ponowne usunięcie na dużą skalę.
/IT Zapewnia zachowanie wierności w pewnych 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 /ITelementu zmiana listy 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= Informacjeo diting u. W udziale plików platformy Azure nie można przechowywać informacji o inspekcji.
/DCOPY:[copyflags] Wierność kopii katalogów. Wartość domyślna: /DCOPY:DA. Flagi kopiowania: D= Dane, A= Atrybuty, T= Znaczniki czasu.
/NP Określa brak wyświetlania postępu kopiowania dla każdego pliku i folderu. Wyświetlanie postępu znacznie obniża wydajność kopiowania.
/NFL Określa brak rejestrowania nazw plików. Poprawia wydajność kopiowania.
/NDL Określa brak rejestrowania nazw katalogów. Poprawia wydajność kopiowania.
/XD Określa katalogi, które mają być wykluczone. Podczas uruchamiania narzędzia Robocopy w katalogu głównym woluminu rozważ wykluczenie ukrytego System Volume Information folderu. Jeśli są one używane zgodnie z projektem, wszystkie informacje w nim są specyficzne dla dokładnego woluminu w tym dokładnym systemie i można je ponownie skompilować na żądanie. 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 stan w pliku dziennika jako Unicode. (Zastępuje istniejący dziennik).
/L Tylko w przypadku uruchomienia testowego
pliki mają być wyświetlane tylko. Nie zostaną one skopiowane, usunięte ani oznaczone sygnaturą czasową. Często używane w /TEE przypadku danych wyjściowych konsoli. 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 miejsc docelowych z magazynem warstwowym. Nieobsługiwane, gdy miejsce docelowe jest zdalnym udziałem SMB.
Określa, że narzędzie Robocopy działa w trybie "małej ilości wolnego miejsca". Ten przełącznik jest przydatny tylko w przypadku obiektów docelowych z magazynem warstwowym, który może zabraknąć lokalnej pojemności przed zakończeniem działania narzędzia Robocopy. Został on dodany specjalnie do użytku z miejscem docelowym z obsługą warstw w chmurze usługi Azure File Sync. Można go używać niezależnie od usługi Azure File Sync. W tym trybie działanie narzędzia Robocopy zostanie wstrzymane za każdym razem, gdy skopiowanie pliku spowodowałoby przekroczenie wartości progowej dla wolnego miejsca na woluminie docelowym. 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 określono wartość bez jawnej podłogi, podłoga jest ustawiona na 10 procent rozmiaru woluminu docelowego. Tryb małej ilości wolnego miejsca nie jest zgodny z elementami /MT, /EFSRAWlub /ZB. /B Dodano obsługę systemu 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
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 rejestrowania.
/ZB Należy ostrożnie
używać trybu ponownego uruchamiania. W przypadku odmowy dostępu ta opcja używa trybu tworzenia kopii zapasowej. Ta opcja znacznie zmniejsza wydajność kopiowania z powodu tworzenia punktów kontrolnych.

Ważne

Zalecamy używanie systemu Windows Server 2022. W przypadku korzystania z systemu Windows Server 2019 upewnij się, że zainstalowano najnowszą wersję poprawki lub co najmniej KB5005103 aktualizacji systemu operacyjnego. Zawiera ważne poprawki dla niektórych scenariuszy narzędzia Robocopy.

Faza 8. Przecięcie 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 wystąpienia systemu Windows Server i do chmury za pośrednictwem usługi Azure File Sync. Ta pierwsza kopia może zająć dużo czasu, w zależności od:

  • Przepustowość pobierania.
  • Przepustowość przekazywania.
  • Szybkość sieci lokalnej i liczba optymalnych dopasowań wątków robocopy.
  • Liczba elementów (plików i folderów), które muszą być przetwarzane przez narzędzie Robocopy i usługę Azure File Sync.

Po zakończeniu początkowego przebiegu ponownie uruchom polecenie.

Kończy się szybciej po raz drugi, ponieważ musi transportować tylko zmiany, które wystąpiły od ostatniego uruchomienia. Podczas tego drugiego przebiegu nowe zmiany mogą nadal gromadzić się.

Powtórz ten proces, dopóki nie zostanie spełniony czas potrzebny na ukończenie operacji robocopy dla określonej lokalizacji w akceptowalnym przedziale czasu przestoju.

Jeśli rozważasz akceptowalny przestój i chcesz przejąć lokalizację systemu Linux w tryb offline, możesz zmienić listy ACL w katalogu głównym udziału, tak aby użytkownicy nie mogli już uzyskać dostępu do 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. Spowoduje to odebranie wszelkich zmian, które mogły zostać pominięte. Czas wykonywania tego ostatniego kroku zależy od szybkości skanowania za pomocą narzędzia Robocopy. Możesz oszacować czas (który jest równy przestojowi), mierząc czas poprzedniego uruchomienia.

Utwórz udział w folderze systemu Windows Server i ewentualnie dostosuj wdrożenie systemu plików DFS-N, aby wskazywało go. Pamiętaj, aby ustawić te same uprawnienia na poziomie udziału co w udziałach SMB serwera Samba systemu 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 SI, które robocopy przeniósł się do wystąpienia systemu Windows Server do identyfikatorów SI nowych użytkowników lokalnych systemu Windows Server. Jeśli użyto kont usługi Active Directory i list ACL, narzędzie Robocopy przeniesie je w następujący sposób i nie będzie konieczne żadne dalsze działania.

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

Możesz spróbować uruchomić kilka z tych kopii równolegle. Zalecamy przetwarzanie zakresu jednego udziału plików platformy Azure jednocześnie.

Ostrzeżenie

Po przeniesieniu wszystkich danych z serwera Samba systemu Linux do wystąpienia systemu Windows Server i zakończeniu migracji wróć do wszystkich grup synchronizacji w witrynie Azure Portal. Dostosuj wartość procentową wolnego miejsca dla woluminu obsługi warstw w chmurze, aby lepiej dopasować się do wykorzystania pamięci podręcznej, na przykład 20 procent.

Zasady dotyczące wolnego miejsca w woluminie obsługi warstw w chmurze działają na poziomie woluminu, a potencjalnie wiele punktów końcowych serwera jest synchronizowanych z nim. Jeśli zapomnisz dostosować wolne miejsce na nawet jednym punkcie końcowym serwera, synchronizacja będzie nadal stosować najbardziej restrykcyjną regułę i próbować zachować wolne miejsce 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 problemów

Najczęstszym problemem jest to, że polecenie Robocopy kończy się niepowodzeniem z woluminem pełnym po stronie systemu Windows Server. Obsługa warstw w chmurze działa co godzinę, aby ewakuować zawartość z lokalnego dysku systemu Windows Server, który został zsynchronizowany. Jego celem jest osiągnięcie wolnego miejsca 99 procent na woluminie.

Niech synchronizacja postęp i obsługa warstw w chmurze zwolni miejsce na dysku. Możesz zauważyć, że w Eksplorator plików w systemie Windows Server.

Jeśli wystąpienie systemu Windows Server ma wystarczającą ilość dostępnej pojemności, ponowne uruchomienie polecenia rozwiąże problem. Nic nie łamie, gdy wejdziesz w tę sytuację, i możesz iść do przodu z ufnością. Niedogodności związane z ponownym uruchomieniem polecenia są jedyną konsekwencją.

Zapoznaj się z linkiem w poniższej sekcji, aby rozwiązać problemy z usługą Azure File Sync.

Następne 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.