Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Ten artykuł dotyczący migracji jest jednym z kilku, które odnoszą się do słów kluczowych Azure File Sync i Azure Data Box. Sprawdź, czy ten artykuł ma zastosowanie do twojego scenariusza:
- Źródło danych: System Windows Server 2012 R2 lub nowszy, w którym zostanie zainstalowana usługa Azure File Sync i wskaż oryginalny zestaw plików.
- Trasa migracji: Windows Server 2012 R2 lub nowszy ⇒ Data Box ⇒ udział plików Azure ⇒ synchronizacja z oryginalną lokalizacją pliku na serwerze Windows
- Buforowanie plików lokalnych: Tak, ostatecznym celem jest wdrożenie usługi Azure File Sync, które synchronizuje pliki z lokalizacji, z której są teraz.
Użycie usługi Azure Data Box to realna ścieżka do przenoszenia większości danych z lokalnego systemu Windows Server w celu oddzielenia udziałów plików platformy Azure, a następnie, opcjonalnie, dodania usługi Azure File Sync na oryginalnym serwerze źródłowym.
Dostępne są różne ścieżki migracji. Ważne jest, aby postępować zgodnie z jedną z następujących czynności:
- Dane są przechowywane w systemie Windows Server 2012 R2 lub nowszym i planujesz zainstalować usługę AFS na tym serwerze i zsynchronizować oryginalną lokalizację. W tym scenariuszu nie chcesz przekazywać wszystkich plików i zamiast tego używać urządzenia Data Box, a następnie używać synchronizacji plików do bieżących zmian. Jeśli jest to Twój scenariusz, w tym artykule opisano ścieżkę migracji.
- Masz dane dotyczące źródła, na którym nie będziesz lub nie możesz zainstalować AFS. Serwer NAS (pamięć masowa podłączona do sieci) albo inny serwer. Wolisz utworzyć nowy, pusty serwer i użyć usługi Azure File Sync na tym serwerze. Jeśli jest to twój scenariusz, nie jest to odpowiedni przewodnik po migracji. Zamiast tego sprawdź: Migrowanie z serwera NAS za pośrednictwem urządzenia Data Box do usługi Azure File Sync lub znalezienie najlepszego przewodnika dla danego scenariusza na stronie przeglądu migracji .
- W przypadku wszystkich innych scenariuszy zapoznaj się z tabelą przewodników migracji udziału plików platformy Azure. Ta strona przeglądu zawiera dobry punkt wyjścia dla wszystkich scenariuszy migracji.
Omówienie migracji
Proces migracji składa się z kilku faz. Należy wykonać następujące czynności:
- Wdróż konta storage i zasoby plikowe.
- Wdróż co najmniej jedno urządzenie Azure Data Box, aby przenieść dane z systemu Windows Server 2012 R2 lub nowszego.
- Konfigurowanie usługi Azure File Sync przy użyciu autorytatywnego przekazywania.
W poniższych sekcjach szczegółowo opisano fazy procesu migracji.
Wskazówka
Jeśli wrócisz do tego artykułu, użyj nawigacji po prawej stronie ekranu, aby przejść do fazy migracji, w której została przerwana.
Faza 1. Określanie liczby potrzebnych udziałów plików platformy Azure
W tym przewodniku dotyczącym migracji musisz nadal korzystać z wewnętrznego dysku twardego (DAS), który zawiera twoje pliki. Urządzenie Data Box będzie zasilane z tej lokalizacji, a usługa Azure File Sync zostanie również skonfigurowana w tej lokalizacji. Serwer NAS (magazyn dołączony do sieci) nie działa z tą ścieżką migracji.
Określasz synchronizacje, konfigurując grupy synchronizacji usługi Azure File Sync, które określają, gdzie zestaw plików jest synchronizowany. Każda grupa synchronizacji ma co najmniej jedną lokalizację serwera, nazywaną punktem końcowym serwera i jednym udziałem plików platformy Azure, nazywanym punktem końcowym chmury.
Można synchronizować ścieżki podrzędne zestawu plików z ich własnymi udziałami plików Azure. Oznacza to skonfigurowanie kilku grup synchronizacji w celu całkowitego objęcia zestawu plików. W pozostałej części sekcji opisano opcje. Jeśli musisz zrestrukturyzować dane, powinieneś to zrobić jako pierwszy krok, przed dalszym postępowaniem zgodnie z tym przewodnikiem, zamówienie Data Box lub konfiguracja synchronizacji.
Ostrzeżenie
Przed rozpoczęciem migracji niezbędne jest, aby struktura twoich plików i folderów była taka, jaką chcesz mieć na dłuższą metę. Unikaj niepotrzebnej restrukturyzacji folderów podczas migracji. Spowoduje to zmniejszenie pozytywnych skutków używania urządzenia Azure Data Box do początkowego, zbiorczego transportu plików na platformę Azure.
W tym kroku określisz, ile udziałów plików w Azure potrzebujesz. Pojedyncza instancja 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 dyskach, które obecnie udostępniasz lokalnie użytkownikom i aplikacjom jako zasoby SMB. Najprostszym sposobem na wyobrażenie sobie tego scenariusza jest wyobrażenie lokalnego udziału, który odwzorowuje się 1:1 na udział plików w Azure. Jeśli masz niewielką liczbę udziałów, poniżej 30 dla jednej instancji 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 na platformie Azure nie uniemożliwia tworzenia zwyczajowych 15 udziałów SMB na lokalnym serwerze Windows Server. Oznacza to tylko, że foldery główne tych 15 udziałów są zorganizowane jako podfoldery w folderze wspólnym. Następnie zsynchronizuj ten wspólny folder z zasobem plików Azure. W ten sposób dla tej grupy udziałów lokalnych jest wymagany tylko jeden udział plików Azure w chmurze.
Synchronizacja głośności
Usługa Azure File Sync umożliwia synchronizowanie katalogu głównego woluminu z udostępnionym zasobem plików w Azure. Jeśli zsynchronizujesz katalog główny woluminu, wszystkie podfoldery i pliki zostaną umieszczone w tym samym udziale plików platformy Azure.
Synchronizowanie rootu woluminu nie zawsze jest najlepszą opcją. Istnieją korzyści wynikające z synchronizacji wielu lokalizacji. Na przykład, dzięki temu liczba elementów w ramach zakresu synchronizacji jest niższa. Testujemy udziały plików platformy Azure i usługę Azure File Sync z liczbą 100 milionów elementów (plików i folderów) na jeden udział. Najlepszym rozwiązaniem jest jednak utrzymanie liczby poniżej 20 milionów lub 30 milionów w jednym udziale. Konfigurowanie usługi Azure File Sync z mniejszą liczbą elementów nie jest korzystne tylko w przypadku synchronizacji plików. Mniejsza liczba elementów również przynosi korzyści w takich scenariuszach:
- Wstępne skanowanie zawartości w chmurze może zakończyć się szybciej, co z kolei zmniejsza oczekiwanie na wyświetlenie przestrzeni nazw na serwerze włączonym dla usługi Azure File Sync.
- Przywracanie z poziomu chmury z migawki udostępnionego pliku w 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.
Wskazówka
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 przechowywania w chmurze w późniejszym kroku należy utworzyć mapę między folderami lokalnymi a udziałami plików Azure. To mapowanie określi, ile i które zasoby grupy synchronizacji usługi Azure File Sync będziesz aprowizować. Grupa synchronizacji łączy udostępniony zasób plików platformy Azure i folder na serwerze oraz ustanawia synchronizację.
Aby zdecydować, ile udziałów plików platformy Azure jest Ci potrzebnych, zapoznaj się z następującymi limitami i najlepszymi praktykami. 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 przechowywania. Takie rozwiązanie sprawia, że konto magazynu staje się punktem odniesienia dla skalowania wskaźników wydajności, takich jak liczba operacji we/wy na sekundę i przepływność.
Zwróć uwagę na ograniczenia IOPS konta magazynu podczas wdrażania udziałów plików w Azure. Najlepiej mapować udziały plików 1:1 przy użyciu kont przechowywania. 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. Gdy nie jest możliwe wdrożenie tylko jednego udziału plików na koncie magazynu, należy rozważyć, które udziały będą wysoce aktywne, a które mniej aktywne, aby upewnić się, że najbardziej aktywne udziały plików nie zostaną umieszczone razem na tym samym koncie magazynu.
Jeśli planujesz przenieść aplikację na platformę Azure, która będzie natywnie używać udziału plików Azure, może być konieczna większa wydajność tego udziału. Jeśli ten typ użycia jest możliwy, nawet w przyszłości, najlepszym rozwiązaniem jest utworzenie pojedynczego standardowego udostępnienia plików platformy Azure na własnym koncie magazynowym.
Istnieje limit 250 kont magazynowania na subskrypcję na region Azure.
Wskazówka
Biorąc pod uwagę te dane, często konieczne jest zgrupowanie wielu folderów najwyższego poziomu w obrębie woluminów w nowy wspólny katalog główny. Następnie zsynchronizuj ten nowy katalog główny oraz wszystkie foldery zgrupowane w nim do pojedynczego udziału plików na platformie Azure. Ta technika pozwala na utrzymanie się w limicie 30 synchronizacji zasobów udostępniania plików platformy Azure na serwer.
Grupowanie według wspólnego korzenia nie wpływa na dostęp do Twoich danych. Twoje listy ACL pozostają bez zmian. Wystarczy dostosować wszystkie ścieżki udostępniania (jak udostępnienia SMB lub NFS), które masz w folderach serwera lokalnego, a teraz przekształciłeś 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 .
Najlepsza praktyka to utrzymywanie niewielkiej liczby elementów w ramach zakresu synchronizacji. Jest to ważny czynnik, który należy wziąć pod uwagę podczas mapowania folderów do udziałów plików na platformie Azure. Usługa Azure File Sync została przetestowana na 100 milionach elementów (plików i folderów) na udział dyskowy. Ale często najlepiej jest utrzymać liczbę pozycji poniżej 20 milionów lub 30 milionów w jednym udziale. Podziel przestrzeń nazw na wiele części, jeśli zaczniesz przekraczać te liczby. Możesz nadal grupować wiele lokalnych udziałów w tym samym udziale plikowym usługi Azure, jeśli pozostaniesz mniej więcej poniżej tych wartości. Ta praktyka zapewni Ci miejsce na rozwój.
Istnieje możliwość, że w Państwa sytuacji zestaw folderów może logicznie synchronizować się z tym samym zasobem plików w platformie Azure, przy użyciu nowej metody wspólnego folderu głównego wspomnianej wcześniej. Jednak nadal lepiej jest przegrupować foldery, aby synchronizowały się do dwóch zamiast jednego udziału plików na platformie Azure. Dzięki temu podejściu można zrównoważyć liczbę plików i folderów w zasobie plików na serwerze. Możesz również podzielić udziały na serwerach lokalnych i zsynchronizować je na więcej serwerów lokalnych, co umożliwia synchronizację z 30 dodatkowymi udziałami plików platformy Azure na każdy dodatkowy serwer.
Typowe scenariusze i zagadnienia dotyczące synchronizacji plików
# | Scenariusz synchronizacji | Wsparte | Zagadnienia (lub ograniczenia) | Rozwiązanie (lub obejście) |
---|---|---|---|---|
1 | Serwer plików z wieloma dyskami/woluminami i wieloma udziałami zasobów do tej samej docelowej usługi udostępniania plików na platformie Azure (konsolidacja) | Nie. | Docelowy zasób plików platformy Azure (punkt końcowy w chmurze) umożliwia 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 (jego woluminu głównego) z docelowym udziałem plików 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, zwalniając tym samym miejsce na dysku serwera plików. Przenieś dane z innych woluminów/udziałów do bieżącego woluminu, który jest synchronizowany. Kontynuuj wykonywanie kroków jeden po drugim, dopóki wszystkie dane nie zostaną przeniesione do chmury/zmigrowane. 2) Skup się na jednym woluminie głównym (dysku) naraz. Skorzystaj z warstwowania w chmurze, aby przenieść wszystkie dane do docelowego udziału plików w usłudze Azure. Usuń punkt końcowy serwera z grupy synchronizacji, ponownie utwórz punkt końcowy z użyciem następnego woluminu głównego/dysku, zsynchronizuj i powtórz proces. Uwaga: Może być wymagane ponowne zainstalowanie agenta. 3) Zaleca się użycie wielu docelowych zasobów udostępniania plików w Azure (czy to na tym samym, czy na innym koncie magazynowania, w zależności od wymagań wydajnościowych) |
2 | Serwer plików z pojedynczym woluminem i wieloma zasobami skierowanymi do tego samego zasobu plików Azure (konsolidacja) | Tak | Nie można mieć wielu punktów końcowych serwera na jednym zarejestrowanym serwerze, które synchronizują się z tym samym docelowym udziałem plików w Azure (takim samym jak powyżej). | Zsynchronizuj folder główny woluminu zawierającego wiele udziałów lub folderów najwyższego poziomu. Aby uzyskać więcej informacji, zobacz Koncepcję grupowania udziałów i synchronizację woluminów. |
3 | Serwer plików z wieloma udziałami i/lub woluminami, który jest połączony z wieloma udziałami plików na platformie Azure w ramach jednego konta magazynu (mapowanie 1:1 udziałów) | Tak | Pojedyncza instancja systemu Windows Server (lub klaster) może synchronizować maksymalnie 30 udziałów plików platformy Azure. Konto przechowywania służy jako cel skalowania pod kątem wydajności. Liczba operacji we/wy na sekundę i przepływność są dzielone pomiędzy udziały plików. Utrzymuj liczbę elementów na każdą grupę synchronizacji w granicach 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 równa się liczbie udostępnionych plików na platformie Azure do synchronizacji). 2) W tym scenariuszu można zsynchronizować tylko 30 udziałów. Jeśli masz więcej niż 30 udziałów na tym serwerze plików, użyj 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. |
4 | Serwer plików z wieloma udziałami i/lub woluminami do wielu udziałów plików platformy Azure w ramach różnych kont magazynowych (odwzorowanie udziałów 1:1) | Tak | Pojedyncza instancja systemu Windows Server (lub klaster) może synchronizować maksymalnie 30 udostępnionych zasobów plików w Azure z tego samego lub innego konta magazynowego. Utrzymuj liczbę elementów na każdą grupę synchronizacji w granicach 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) skierowanym do tego samego docelowego udziału plików na platformie 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 skoncentrowania się na jednym serwerze plików naraz. |
Tworzenie tabeli mapowania
Użyj poprzednich informacji, aby określić, ile potrzebujesz udziałów plików na platformie Azure oraz które części istniejących danych znajdą się w każdym z tych udziałów.
Utwórz tabelę, która rejestruje swoje przemyślenia, aby można było odwoływać się do niej, gdy zajdzie taka potrzeba. Utrzymanie organizacji jest ważne, ponieważ można łatwo utracić szczegóły planu mapowania podczas aprowizowania wielu zasobów platformy Azure jednocześnie. Pobierz następujący plik programu Excel, aby użyć go jako szablonu, aby ułatwić tworzenie mapowania.
![]() |
Pobierz szablon mapowania przestrzeni nazw. |
Faza 2. Wdrażanie zasobów usługi Azure Storage
W tej fazie zapoznaj się z tabelą mapowania z fazy 1 i użyj jej do przygotowania prawidłowej liczby kont magazynu platformy Azure oraz udziałów plików w ramach tych kont.
Udział plików 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 bardzo aktywne udziały (udziały używane przez wielu użytkowników i/lub aplikacje), dwa udziały plików Azure mogą przekroczyć limit wydajności konta magazynu.
Najlepszą praktyką jest wdrożenie kont pamięci, z których każde ma jeden udział plików. Możesz połączyć wiele udziałów plików na platformie Azure z tym samym kontem magazynowania, jeśli masz udziały archiwalne lub spodziewasz się w nich niskiej codziennej aktywności.
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ę znajdować.
W poprzedniej fazie określono odpowiednią liczbę udziałów. W tym kroku masz mapowanie kont magazynowych do udziałów plików. Teraz wdróż odpowiednią liczbę kont usługi Azure Storage z odpowiednią liczbą udziałów plików Azure w nich.
Upewnij się, że region każdego konta magazynu jest taki sam i odpowiada regionowi wdrożonego już zasobu usługi synchronizacji magazynu.
Ostrzeżenie
Jeśli tworzysz udział plików w Azure z limitem 100 TiB, ten udział może używać tylko opcji lokalnej nadmiarowości lub nadmiarowości strefowej magazynu. Przed użyciem zasobów plikowych o pojemności 100 TiB, należy wziąć pod uwagę potrzeby nadmiarowości przechowywania danych.
Udziały plików platformy Azure są nadal tworzone z limitem 5 TiB domyślnie. Wykonaj kroki opisane w sekcji Tworzenie udziału plików platformy Azure, aby stworzyć duży udział plików.
Innym aspektem podczas wdrażania konta magazynu jest redundancja usługi 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 3. Określanie liczby potrzebnych urządzeń Azure Data Box
Rozpocznij ten krok dopiero po zakończeniu poprzedniej fazy. Zasoby usługi Azure Storage (konta magazynu i udziały plików) powinny zostać utworzone w tym momencie. W przypadku zamawiania urządzenia Data Box należy określić konta magazynu, do których urządzenie Data Box przenosi dane.
W tej fazie należy zamapować wyniki planu migracji z poprzedniej fazy na limity dostępnych opcji urządzenia Data Box. Te kwestie pomogą Ci zaplanować, którą opcję urządzenia Data Box wybrać i ile ich potrzebujesz, aby przenieść udziały NAS na udziały plików w Azure.
Aby określić liczbę potrzebnych urządzeń i ich typów, należy wziąć pod uwagę następujące ważne limity:
- Każde urządzenie Data Box może przenosić dane na maksymalnie 10 kont magazynowych.
- Każda opcja urządzenia Data Box ma własną pojemność do wykorzystania. Zobacz Opcje urządzenia Data Box.
Zapoznaj się z planem migracji, aby znaleźć liczbę kont magazynu, które chcesz utworzyć, i udziały w każdym z nich. Następnie przyjrzyj się rozmiarowi poszczególnych udziałów na serwerze NAS. Połączenie tych informacji pozwoli zoptymalizować proces i zdecydować, które urządzenie powinno wysyłać dane do których kont magazynowych. Dwa urządzenia Data Box mogą przemieszczać pliki do tego samego konta magazynu, ale nie dzielą zawartości pojedynczego udziału plików między dwa urządzenia Data Box.
Opcje urządzenia Data Box
W przypadku migracji standardowej wybierz jedną lub kombinację tych opcji urządzenia Data Box:
- Dysk Data Box. Firma Microsoft wyśle do Ciebie od jednego do pięciu dysków SSD, które mają pojemność 8 TiB każdy, do maksymalnej łącznej pojemności 40 TiB. Pojemność do wykorzystania wynosi około 20 procent mniej ze względu na obciążenie związane z szyfrowaniem i systemem plików. Aby uzyskać więcej informacji, zobacz dokumentację urządzenia Data Box Disk.
- Skrzynka danych. Ta opcja jest najbardziej powszechna. Firma Microsoft wyśle do ciebie ruggedizowane urządzenie Data Box, które działa podobnie jak urządzenie NAS. Ma pojemność do wykorzystania 80, 120 lub 525 TiB, w zależności od wybranej jednostki SKU. Aby uzyskać więcej informacji, zobacz dokumentację urządzenia Data Box.
- Ciężkie urządzenie Data Box. Ta opcja oferuje odporne urządzenie Data Box na kołach, które działa podobnie jak w przypadku serwera NAS. Ma pojemność 1 PiB. Pojemność do wykorzystania wynosi około 20 procent mniej ze względu na obciążenie związane z szyfrowaniem i systemem plików. Aby uzyskać więcej informacji, zobacz dokumentację urządzenia Data Box Heavy.
Uwaga / Notatka
W przypadku usług Data Box i Data Box Heavy obsługiwane jest kopiowanie tylko danych za pośrednictwem protokołu SMB. Kopiowanie danych za pośrednictwem usługi kopiowania danych nie jest obsługiwane, ponieważ nie zachowuje wierności plików.
Faza 4. Kopiowanie plików na urządzenie Data Box
Po nadejściu urządzenia Data Box należy skonfigurować je z nieskrępowaną łącznością sieciową z urządzeniem NAS. Postępuj zgodnie z dokumentacją konfiguracji dla typu urządzenia Data Box, który zamówiłeś.
- Konfigurowanie urządzenia Data Box.
- Konfigurowanie urządzenia Data Box Disk.
- Konfigurowanie urządzenia Data Box Heavy.
W zależności od typu urządzenia Data Box narzędzia do kopiowania urządzenia Data Box mogą być dostępne. Na tym etapie nie zalecamy użycia ich do migrowania plików do udziałów plików platformy Azure, ponieważ nie kopiują one plików do urządzenia Data Box z pełną dokładnością. Zamiast tego użyj narzędzia Robocopy.
Po nadejściu urządzenia Data Box będą dostępne wstępnie aprowidowane udziały SMB dla każdego konta magazynu określonego podczas jego zamówienia.
- Jeśli Twoje pliki trafią do udziału plików Azure w warstwie Premium, będzie jeden udział SMB na każde konto magazynowe "File Storage" w tej warstwie.
- Jeśli pliki przechodzą do konta magazynu w warstwie Standardowa, będą istnieć trzy udziały SMB na konto magazynu w warstwie Standardowa (GPv1 i GPv2). Tylko udziały plików, które kończą się na
_AzFiles
, są istotne dla migracji. Ignoruj udziały dotyczące blobów blokowych i stronicowych.
Wykonaj kroki opisane w dokumentacji usługi Azure Data Box:
- Nawiązywanie połączenia z usługą Data Box.
- Kopiowanie danych do urządzenia Data Box.
- Przygotuj urządzenie Data Box do przekazania na platformę Azure.
Połączona dokumentacja urządzenia Data Box określa polecenie Robocopy. To polecenie nie jest odpowiednie do zachowania pełnej wierności pliku i folderu. Zamiast tego użyj tego polecenia:
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 narzędzia 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 usługą Azure Files wskazują, że wartości między 8 a 20 zapewniają zrównoważoną wydajność podczas początkowego przebiegu kopiowania. Kolejne /MIR uruchomienia są stopniowo dotknięte dostępną przepustowością obliczeniową oraz sieciową. Aby zoptymalizować kolejne uruchomienia, dokładniej dopasuj liczbę wątków do liczby rdzeni procesora oraz 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 n razy przed trwałym niepowodzeniem kopiowania pliku podczas uruchomienia. Możesz zoptymalizować wydajność działania: wybierz wartość dwóch lub trzech, jeśli uważasz, że przekroczenia limitu czasu spowodowały niepowodzenia w przeszłości. Może to być bardziej typowe w przypadku łączy sieci WAN. Jeśli uważasz, że plik nie został skopiowany, ponieważ był aktywnie używany, wybierz brak ponawiania prób 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, które mają otwarte pliki, mogą potrzebować jeszcze kilku godzin. W takim przypadku, zaakceptowanie faktu, że plik nie został jeszcze skopiowany i próba przechwycenia go w jednym z kolejnych, zaplanowanych przebiegów Robocopy, może ostatecznie doprowadzić do pomyślnego skopiowania pliku. Pomaga to w szybszym zakończeniu bieżącego procesu bez konieczności przedłużania go przez liczne ponowne próby, które ostatecznie w większości kończą się błędami kopiowania z powodu nadal otwartych plików po upływie czasu oczekiwania na ponowienie próby. |
/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 do Azure Files, upewnij się, że montujesz udział plików Azure przy użyciu klucza dostępu do konta magazynu zamiast tożsamości domeny. Jeśli tego nie zrobisz, komunikaty o błędach mogą nie prowadzić intuicyjnie do rozwiązania problemu. |
/MIR |
(Odwzorowuje źródło do miejsca docelowego.) Umożliwia programowi Robocopy kopiowanie tylko delt pomiędzy źródłem a miejscem 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 docelowego. 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 spowoduje usunięcia i ponowne kopiowanie na dużą skalę. |
/IT |
Zapewnia zachowanie wierności w pewnych scenariuszach lustrzanych.
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 elementu /IT zmiana ACL może zostać pominięta przez narzędzie Robocopy i nie zostać 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 = NTFS ACLs, O = Informacje o właścicielu, U = Informacje o audycie. W udziale plików platformy Azure nie można przechowywać informacji o inspekcji. |
/DCOPY:[copyflags] |
Wierność przy kopiowaniu 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, że nazwy katalogów nie są rejestrowane. Poprawia wydajność kopiowania. |
/XD |
Określa katalogi, które mają być wykluczone. Podczas uruchamiania Robocopy na poziomie głównym woluminu rozważ wykluczenie ukrytego System Volume Information katalogu. Jeśli są używane zgodnie z projektem, wszystkie zawarte tam informacje odnoszą się do konkretnego woluminu w tym konkretnym systemie i można je odtworzyć 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 status w pliku dziennika jako Unicode. (Zastępuje istniejący dziennik). |
/L |
Tylko do testów Pliki powinny być tylko wymienione na liście. Nie zostaną one skopiowane, usunięte ani oznaczone sygnaturą czasową. Często używane z /TEE do wyjścia konsoli. Może być konieczne usunięcie flag z przykładowego skryptu, takiego jak /NP , /NFL i /NDL , w celu uzyskania prawidłowych udokumentowanych wyników testu. |
/LFSM |
Tylko dla miejsc docelowych z pamięcią masową o strukturze warstwowej. Nie jest obsługiwane, gdy miejscem docelowym jest zdalny udział SMB.
Określa, że narzędzie Robocopy działa w trybie "niskiego stanu wolnego miejsca". Ten przełącznik jest przydatny tylko w przypadku obiektów docelowych z warstwową pamięcią masową, któremu może zabraknąć miejscowej pojemności przed zakończeniem działania narzędzia Robocopy. Został on dodany specjalnie do użytku z obiektem docelowym z obsługą warstwowania 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 , nMB lub nGB . Jeśli /LFSM jest określony bez podania jawnej wartości minimalnej, minimum jest ustawione na 10 procent rozmiaru wolumenu docelowego. Tryb małej ilości wolnego miejsca nie jest zgodny z elementami /MT , /EFSRAW lub /ZB . Obsługa dla /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 |
Kopiuje pliki w trybie ponownego uruchamiania. Ten przełącznik jest zalecany tylko w niestabilnym środowisku sieciowym. Znacznie zmniejsza wydajność kopiowania z powodu dodatkowego logowania. |
/ZB |
Używa trybu ponownego uruchamiania. W przypadku odmowy dostępu ta opcja używa trybu tworzenia kopii zapasowej. Ta opcja znacznie pogarsza 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 5. Wdrażanie zasobu w chmurze usługi Azure File Sync
Przed kontynuowaniem pracy z tym przewodnikiem poczekaj, aż wszystkie pliki dotarły do odpowiednich udziałów plików platformy Azure. Proces wysyłania i pozyskiwania danych urządzenia Data Box zajmie trochę czasu.
Aby wykonać ten krok, potrzebne są poświadczenia subskrypcji platformy Azure.
Podstawowy zasób, który należy skonfigurować dla usługi Azure File Sync, nazywa się usługą synchronizacji Storage. 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 synchronizacji danych 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 będzie obejmować zasoby do synchronizacji i przechowywania.
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 6. Wdrażanie agenta usługi Azure File Sync
W tej sekcji zainstalujesz agenta usługi Azure File Sync na instancji 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ń. Upewnij się, że zainstalujesz pełny moduł oraz 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. Możliwość korzystania z serwera proxy w celu uzyskania dostępu do internetu jest również wspierana. 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.
Jeśli konfiguracja serwera proxy oznacza, że musisz otworzyć zapory sieciowe 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 zakończenie kreatora instalacji serwera otworzy się kreator rejestracji serwera. Zarejestruj serwer w zasobie Azure swojej usługi Storage Sync 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 Storage Sync w portalu Azure. W menu po lewej stronie przejdź do pozycji Zarejestrowane serwery. Zobaczysz tam swój serwer.
Faza 7. Konfigurowanie usługi Azure File Sync w istniejącym systemie 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 instancji systemu Windows Server podczas poprzednich kroków.
- Zaloguj się do witryny Azure Portal.
- Znajdź zasób usługi Storage Sync Service.
- Utwórz nową grupę synchronizacji w ramach usługi Storage Sync dla każdego udziału plików 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 udostępnionego zasobu plikowego Azure o tej samej nazwie.
- Gdy utworzysz grupę synchronizacji, pojawi się dla niej wiersz na liście grup synchronizacji. Wybierz nazwę (link), aby wyświetlić zawartość grupy synchronizacji. Zobaczysz udostępnianie plików usługi Azure w obszarze Punkty końcowe chmury.
- Znajdź przycisk Dodaj punkt końcowy serwera . Folder utworzony na lokalnym serwerze stanie się ścieżką dla tego punktu końcowego serwera.
Po wejściu do kreatora Tworzenie punktu końcowego serwera użyj podanego pola wyboru poniżej ścieżki folderu. Wybierz tę opcję tylko wtedy, gdy wprowadzono ścieżkę wskazującą tę samą strukturę plików i folderów, którą można znaleźć w udziale plików Azure (gdzie usługa Data Box przeniosła pliki i foldery do tej przestrzeni nazw).
Jeśli istnieje niezgodność hierarchii folderów, będzie ona przedstawiać się jako różnice, których nie można automatycznie rozpoznać. Unikaj niezgodności, ponieważ wszelkie inwestycje w proces urządzenia Data Box nie przyniosą Ci żadnych korzyści. Wszystkie dane zostaną usunięte w udziale plików platformy Azure. Wszystkie dane muszą zostać przekazane z serwera lokalnego. Struktury katalogów muszą być zgodne, aby uzyskać korzyści z migracji zbiorczej za pomocą usługi Azure Data Box i bezproblemowej aktualizacji udziału w chmurze przy użyciu najnowszych zmian z serwera.
Uwaga / Notatka
Włączenie tego pola wyboru spowoduje ustawienie trybu synchronizacji początkowej na autorytatywne zastępowanie plików i folderów w udziale plików platformy Azure zawartością w ścieżce tego serwera. Ta opcja jest dostępna tylko dla pierwszego punktu końcowego serwera w grupie synchronizacji.
Po skonfigurowaniu autorytatywnego przesyłania dla tego punktu końcowego serwera można opcjonalnie włączyć warstwowanie w chmurze.
Warstwowanie w chmurze to funkcja usługi Azure File Sync, która pozwala serwerowi lokalnemu mieć mniejszą pojemność dysku niż w chmurze, ale nadal mieć pełny dostęp do przestrzeni nazw. Lokalnie interesujące dane są również buforowane lokalnie w celu uzyskania szybkiej wydajności dostępu. Warstwowanie w chmurze jest opcjonalne. Można ustawić je indywidualnie dla każdego punktu końcowego serwera usługi Azure File Sync. Użyj tej funkcji, aby uzyskać stały rozmiar magazynu w środowisku lokalnym, a jednocześnie zapewnić użytkownikom lokalną pamięć podręczną o wysokiej wydajności oraz przechowywać mniej używane dane w chmurze.
Aby dowiedzieć się więcej, zapoznaj się z omówieniem obsługi warstw w chmurze lub przyjrzyj się bliżej różnym zasadom obsługi warstw w chmurze , których można użyć, aby dostroić zawartość buforowaną/warstwową na serwerze lokalnym.
Ukończ migrację
Po utworzeniu punktu końcowego serwera synchronizacja działa. Jednak synchronizacja musi wyliczać (odnajdywać) pliki i foldery przeniesione za pośrednictwem urządzenia Azure Data Box do udziału plików platformy Azure. W zależności od rozmiaru przestrzeni nazw może upłynąć dużo czasu, zanim najnowsze zmiany serwera zostaną zsynchronizowane z chmurą. Użytkownicy nie są dotknięci i mogą bez przeszkód kontynuować pracę z danymi na serwerze. Ta strategia zapewnia migrację do chmury bez przestojów.
W przypadku wszystkich udziałów plików/lokalizacji serwera platformy Azure, które należy skonfigurować do celów synchronizacji, powtórz kroki tworzenia grup synchronizacji i dodaj pasujące foldery serwera jako punkty końcowe serwera. Użyłeś Azure Data Box, aby przenieść pliki do kilku udziałów plików platformy Azure. Migracja zostanie ukończona po utworzeniu wszystkich punktów końcowych serwera łączących dane lokalne z tymi udziałami plików platformy Azure.
Dalsze kroki
Jest jeszcze wiele do odkrycia na temat udziałów plików platformy Azure i usługi Azure File Sync. Poniższe artykuły ułatwią zrozumienie zaawansowanych opcji i najlepszych praktyk. Zapewniają one również pomoc w rozwiązywaniu problemów. Te artykuły zawierają linki do dokumentacji udziału plików Azure, gdzie jest to odpowiednie.