Udostępnij za pośrednictwem

Migrowanie z magazynu dołączonego do sieci (NAS) 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 NAS 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: nas ⇒ Windows Server ⇒ przekazywania i synchronizowania z udziałami plików platformy Azure
  • Buforowanie plików lokalnych: Tak, ostatnim 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 lokalizacjach magazynu bezpośredniego dołączonego (DAS) i nie obsługuje synchronizacji z lokalizacjami magazynu dołączonego do sieci (NAS). Ten fakt sprawia, że migracja plików jest niezbędna, a ten artykuł przeprowadzi Cię przez planowanie i wykonywanie takiej migracji.

Dotyczy

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

Cele migracji

Celem jest przeniesienie udziałów plików SMB na urządzeniu NAS do systemu Windows Server, a następnie wykorzystanie usługi Azure File Sync do wdrożenia chmury hybrydowej. Ogólnie rzecz biorąc, migracje muszą być wykonywane w sposób, który gwarantuje integralność danych produkcyjnych i jej 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 Migrowanie do udziałów plików SMB platformy Azure, ważne jest użycie odpowiedniego narzędzia do kopiowania i podejścia. Urządzenie NAS ujawnia udziały SMB bezpośrednio w sieci lokalnej. Aby przenieść pliki, możesz użyć usługi Azure Storage Mover lub narzędzia RoboCopy.

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 that shows an example of a mapping table. Download the following file to experience and use the content of this image.

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.


Excel icon that sets the context for the download. Pobierz szablon mapowania przestrzeni nazw.

Faza 2. Aprowizuj odpowiedni lokalny system Windows Server

  • Utwórz maszynę wirtualną z systemem Windows Server 2022 lub Windows Server 2019 albo wdróż serwer fizyczny. Klaster trybu failover systemu Windows Server jest również obsługiwany.

  • Aprowizuj lub dodaj bezpośrednio dołączony magazyn (DAS w porównaniu z serwerem NAS, który nie jest obsługiwany).

    Ilość miejsca do aprowizowania może być mniejsza niż ilość miejsca, z którego korzystasz obecnie na urządzeniu NAS. 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ększego miejsca nas do mniejszego woluminu systemu Windows Server w fazie późniejszej należy pracować w partiach:

    1. Przenoszenie zestawu plików pasujących do dysku
    2. Angażowanie synchronizacji plików i obsługi 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 sekcji RoboCopy tego artykułu, 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ć. Użyj przełącznika /LFSM tylko wtedy, gdy miejsce docelowe migracji jest magazynem lokalnym. Nie jest obsługiwana, gdy miejsce docelowe jest zdalnym udziałem SMB.

    Można uniknąć tego podejścia do przetwarzania wsadowego, aprowizowanie równoważnego miejsca w systemie Windows Server zajmowanego przez pliki na urządzeniu NAS. Rozważ deduplikację w systemie NAS/Windows. Jeśli nie chcesz trwale zatwierdzać tej dużej ilości miejsca do 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 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 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żna zorientować się na mniejszą liczbę dla serwera, ale spodziewać 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 przewodnikuwdraż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 w systemie Windows Server

Zarejestrowany lokalny system Windows Server musi być gotowy i połączony 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 (gorące) dane są również buforowane lokalnie w celu uzyskania szybkiego dostępu. Obsługa warstw w chmurze to opcjonalna funkcja dla usługi Azure File Sync "punkt końcowy serwera".

Ostrzeżenie

Jeśli aprowizujesz mniej miejsca do magazynowania na woluminach serwera z systemem Windows niż dane używane na urządzeniu NAS, 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 na potrzeby migracji na 99% wolnego miejsca na woluminie. Pamiętaj, aby powrócić do ustawień obsługi warstw w chmurze po zakończeniu migracji i ustawić ją na bardziej długoterminowy poziom przydatny.

Powtórz kroki tworzenia grupy synchronizacji i dodawania pasującego folderu serwera jako punktu końcowego serwera dla wszystkich udziałów plików platformy Azure /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 obu lokalizacjach. W następnym kroku zaczniesz kopiować pliki do 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. Kopiowanie danych przy użyciu usługi Azure Storage Mover lub RoboCopy

Teraz możesz użyć usługi Azure Storage Mover lub RoboCopy, aby skopiować dane z urządzenia NAS do systemu Windows Server i przenieść dane do udziałów plików platformy Azure za pomocą usługi Azure File Sync. W tym przewodniku użyto narzędzia RoboCopy na potrzeby kopii początkowej. Aby zamiast tego użyć usługi Azure Storage Mover, zobacz Migrowanie do udziałów plików SMB platformy Azure przy użyciu usługi Azure Storage Mover.

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

  • Zidentyfikuj pierwszą lokalizację na urządzeniu NAS.
  • Zidentyfikuj pasujący folder w systemie Windows Server, który ma już skonfigurowaną usługę Azure File Sync.
  • Uruchom kopię.

Następujące polecenie RoboCopy spowoduje skopiowanie plików z magazynu NAS 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 systemie Windows Server niż pliki zajmują urządzenie NAS, skonfigurowano obsługę warstw w chmurze. Ponieważ lokalny wolumin systemu Windows Server jest pełny, obsługa warstw w chmurze będzie uruchamiać pliki warstwowe, które zostały już pomyślnie zsynchronizowane. Obsługa warstw w chmurze spowoduje wygenerowanie wystarczającej ilości miejsca, aby kontynuować kopiowanie z urządzenia NAS. Obsługa warstw w chmurze sprawdza raz na godzinę, aby zobaczyć, co zostało zsynchronizowane, i zwolnić miejsce na dysku w celu osiągnięcia 99% wolnego miejsca na woluminie.

Możliwe, że narzędzie RoboCopy przenosi pliki szybciej niż można zsynchronizować z chmurą i warstwą lokalnie, w związku z czym zabraknie miejsca na dysku lokalnym. W takim przypadku narzędzie RoboCopy zakończy się niepowodzeniem. Zalecamy pracę z udziałami w sekwencji, która uniemożliwia to — na przykład nie uruchamiaj zadań kopiowania dla wszystkich udziałów w tym samym czasie lub przenosi tylko udziały, które mieszczą się w bieżącej ilości wolnego miejsca w systemie Windows Server.

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 NAS i mogą je potencjalnie zmieniać. Możliwe, że narzędzie RoboCopy przetworzyło katalog, przechodzi do następnego, a następnie użytkownik w lokalizacji źródłowej (NAS) 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 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 narzędzia RoboCopy
  • liczba elementów (plików i folderów), które muszą być przetwarzane przez narzędzia RoboCopy i usługę Azure File Sync

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

Po raz drugi zakończy się szybciej, ponieważ musi tylko transportować 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 będziesz mieć pewność, że czas potrzebny na ukończenie narzędzia RoboCopy dla określonej lokalizacji mieści się w akceptowalnym przedziale czasu przestoju.

Jeśli weźmiesz pod uwagę akceptowalny przestój, musisz usunąć dostęp użytkownika do udziałów opartych na nas. Można to zrobić, wykonując wszystkie kroki, które uniemożliwiają użytkownikom zmianę struktury plików i folderów oraz zawartości. Przykładem jest wskazanie przestrzeni nazw systemu plików DFS na nieistnieną lokalizację lub zmianę głównych list ACL w udziale.

Uruchom jedną ostatnią rundę narzędzia 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 udziale SMB nas. Jeśli masz serwer NAS przyłączony do domeny klasy przedsiębiorstwa, identyfikatory SID użytkownika będą automatycznie zgodne, ponieważ użytkownicy istnieją w usłudze Active Directory i RoboCopy kopiuje pliki i metadane w pełnej wierności. Jeśli używasz użytkowników lokalnych na serwerze NAS, musisz ponownie utworzyć tych użytkowników jako użytkowników lokalnych systemu Windows Server i mapować istniejące identyfikatory SID RoboCopy przeniesione do systemu Windows Server do identyfikatorów SID nowych użytkowników lokalnych systemu Windows Server.

Zakończono migrację udziału/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 NAS do systemu Windows Server i zakończeniu migracji: Wróć do wszystkich grup synchronizacji w witrynie Azure Portal i dostosuj wartość procentu wolnego miejsca do warstwy w chmurze, aby lepiej dopasować się do wykorzystania pamięci podręcznej, na przykład 20%.

Zasady wolnego miejsca na woluminie 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 nawet w jednym punkcie końcowym serwera, synchronizacja będzie nadal stosować najbardziej restrykcyjną regułę i próbuje zachować 99% wolnego miejsca na dysku, dzięki czemu lokalna pamięć podręczna nie będzie działać zgodnie z oczekiwaniami. Chyba że twoim celem jest posiadanie tylko przestrzeni nazw dla woluminu, który zawiera tylko rzadko używane, archiwizowane dane i rezerwujesz pozostałą część miejsca do magazynowania w innym scenariuszu.

Rozwiązywanie problemów

Najbardziej prawdopodobnym problemem, który można napotkać, jest to, że polecenie RoboCopy kończy się niepowodzeniem z komunikatem "Wolumin pełny" 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 99% wolnego miejsca 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 system Windows Server ma wystarczającą dostępną pojemność, 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 ułatwią zrozumienie opcji wdrażania, najlepszych rozwiązań i kroków rozwiązywania problemów.