Migracja do chmury: strategia przesyłania plików
Zaplanuj strategię przesyłania plików przy migracji do chmury. Zminimalizuj przestoje, zapewnij integralność danych i zoptymalizuj przepustowość łącza.
Strategia przesyłania plików podczas migracji do chmury zależy od trzech decyzji: ścieżki transportu (internet publiczny, Direct Connect lub fizyczne urządzenie), modelu cutoveru (big-bang, fazowy lub równoległy) i mechanizmów weryfikacji integralności, którym zamierzasz ufać. Dla zasobu 50 TB na łączu 1 Gbps oczekuj około 5 dni czystego czasu transferu z prędkością kabla — mniej jeśli kompresujesz, więcej jeśli łącze jest współdzielone. Planuj sekwencję przed planowaniem narzędzi i zabudżetuj 20% zapasu na próby ponowne i uzgodnienie.
Inwentaryzacja zbioru danych przed dotknięciem kabla
Zanim wybierzesz AWS DataSync, Azure AzCopy lub Google Storage Transfer Service, zinwentaryzuj, co faktycznie masz. Uruchom du -sh na udziałach plików, zapytaj katalogi baz danych o liczbę wierszy i wyeksportuj manifesty object store. Firma z sektora MŚP, którą audytowałem, myślała, że ma 8 TB na NAS; rzeczywista liczba wynosiła 34 TB gdy policzyłeś snapshoty i ukryte pliki blokady Office ~$.
Sklasyfikuj inwentarz według trzech osi: rozmiar, częstość zmian i waga regulacyjna. Pliki poniżej 1 MB przenoszą się powoli na bajt ze względu na narzut per-obiekt — bucket z 200 milionami małych plików może zająć więcej czasu niż jeden z 10 TB wideo. Rankuj gorące dane (zmieniające się codziennie) osobno od zimnych danych (archiwa .pdf, faktury z 2017 roku). Zimne dane mogą być wysłane tygodnie wcześniej; gorące dane potrzebują logiki synchronizacji-aż-do-cutoveru.
Wybór transportu dopasowanego do harmonogramu
Dla poniżej 10 TB z przyzwoitym łączem światłowodowym, transfer online przez TLS 1.3 zazwyczaj wygrywa. Między 10 TB a 500 TB, zarezerwuj przepustowość lub zaprowizjonuj AWS Direct Connect / Azure ExpressRoute, żeby nie nasycić firmowej sieci WAN. Powyżej 500 TB, fizyczne zasilanie bije internet: AWS Snowball Edge mieści 80 TB, Snowmobile przenosi eksabajty w kontenerze, a Azure Data Box Heavy przechowuje 1 PB.
Przelicz uczciwie. Przy 1 Gbps (125 MB/s pełna prędkość, realistycznie 80 MB/s po narzutach), 100 TB zajmuje około 14 dni nieprzerwanego transferu. Jeśli okno operacyjne to 48 godzin, kabel nie wchodzi w grę — wysyłaj dyski. Uwzględnij egress: przeniesienie 100 TB od starszego dostawcy za 0,09 USD/GB kosztuje 9 000 USD zanim dotkniesz miejsca docelowego.
Integralność: ufaj, ale sumuj kontrolnie
Każda migracja potrzebuje weryfikacji integralności end-to-end, nie tylko TLS na warstwie transportowej. Generuj hashe SHA-256 lub xxHash64 w źródle, przesyłaj obok ładunku i re-hashuj w miejscu docelowym. AWS DataSync robi to domyślnie; rsync z --checksum wymusza to; rclone obsługuje --check-first i backendy crypt.
Dla workloadów compliance zachowaj manifest — CSV ze ścieżką, liczbą bajtów i hashem — przez pełny okres retencji. Podmioty objęte HIPAA powinny logować każdy obiekt zgodnie z mechanizmami integralności 45 CFR 164.312(c)(1), a art. 5 ust. 1 lit. f RODO wymaga zademonstrowania, że pliki nie były zmienione w locie. Jeden nieprawidłowy bajt w badaniu DICOM może sprawić, że przeglądarka radiologa odmówi jego otwarcia.
Minimalizacja przestojów przez synchronizację delta
Cutoovery big-bang to wróg snu. Zamiast tego zrób wstępną kopię masową tygodnie wcześniej, a potem uruchamiaj inkrementalne delty nocami aż do okna cutoveru. Narzędzia takie jak Rclone (--update --use-server-modtime), AzCopy (--overwrite=ifSourceNewer) i gsutil rsync -d od Google wykrywają zmienione pliki przez mtime lub hash i przenoszą tylko deltę.
Bazy danych potrzebują własnego planu. Dla instancji PostgreSQL 2 TB użyj pg_basebackup plus wysyłanie WAL; dla MySQL skonfiguruj replikę w miejscu docelowym i promuj ją podczas cutoveru. Delty systemu plików przez rsync mogą skrócić końcową synchronizację z godzin do minut, co zazwyczaj mieści się w oknie serwisowym sobotniej nocy.
Kształtowanie przepustowości i transfery o określonych porach
Migracje pożerające każdy bit WAN kończą się źle — zanim wstanie dzień, help desk jest zasypany zgłoszeniami. Ograniczaj agresywnie. AzCopy przyjmuje --cap-mbps, rclone obsługuje --bwlimit 50M:100M dla stawek dziennych/nocnych, a DataSync harmonogramuje zadania z limitami przepustowości na godzinę. Rozsądna polityka: 30% łącza w godzinach pracy, 90% nocą, 100% w weekendy.
Segmentuj ruch też na firewallu. Taguj przepływy migracji wartością DSCP, żeby polityki QoS nie zagładzały połączeń Zoom. Jeśli używasz MPLS do oddziałów, rozważ SD-WAN breakout, żeby ruch migracji wychodził lokalnie zamiast trombonować przez centralę.
Obsługa wrażliwych danych w tranzycie
Każda migracja zawierająca dane osobowe, PHI lub dane posiadacza karty potrzebuje szyfrowania spełniającego stosowny standard. TLS 1.3 to minimum; dla plików w spoczynku podczas stagingu, owijaj AES-256-GCM przed uploadem. PCI DSS 4.0 Wymóg 4.2.1 nakazuje silną kryptografię dla danych posiadacza karty w sieciach publicznych, a RODO (które w Polsce egzekwuje UODO) de facto wymaga szyfrowania dla danych osobowych w tranzycie.
Dla jednorazowych transferów małych partii podczas migracji (np. konsultant eksportujący tabelę Salesforce lub DBA przenoszący vault z danymi uwierzytelniającymi), narzędzia szyfrowane end-to-end trzymają klucze poza zasięgiem dostawcy transportu. HexaTransfer obsługuje to czysto dla jednorazowych plików podczas migracji — szyfrowanie następuje w przeglądarce zanim cokolwiek dotknie serwera.
Testowanie cutoveru przed cutoverem
Przećwicz migrację na podzbiorze. Wybierz jeden dział — powiedzmy 300 GB dysku współdzielonego Marketingu — i uruchom pełny pipeline: inwentaryzacja źródła, transfer, weryfikacja sumy kontrolnej, mapowanie uprawnień i failover aplikacji. Zmierz każdy krok i udokumentuj, co się posypało.
Typowe niespodzianki: ACL systemu NTFS, które nie mapują się czysto na polityki bucketu S3, dowiązania symboliczne, które rclone traktuje jak pliki, ścieżki udziałów SMB osadzone w konfigurach aplikacji i różnice czułości na wielkość liter między miejscami docelowymi Windows i Linux. Napraw to w stagingu, nie o 2 w nocy w noc go-live. Próba generalna trwająca tydzień oszczędza rollback trwający miesiąc.
Uzgodnienie po migracji
Ogłoś sukces dopiero po uzgodnieniu. Porównaj liczbę obiektów, całkowitą liczbę bajtów i losową 1% próbkę hashową między źródłem a miejscem docelowym. Zapytaj metryki aplikacji — jeśli system zarządzania dokumentami raportował 4,2 miliona plików, a miejsce docelowe pokazuje 4,19 miliona, znajdź brakujące 10 000 zanim wyłączysz źródło.
Utrzymuj źródło tylko-do-odczytu przez co najmniej 30 dni po cutoverze. Użytkownicy nieuchronnie będą szukać pliku, który nie zmigrował, bo był w ~/Desktop/stare_rzeczy/ zamiast na zinwentaryzowanym udziale. Zabudżetuj na to, nie bądź tym zaskoczony i napisz runbook rollbacku zanim go potrzebujesz.
Wypróbuj na hexatransfer.com — bezpłatnie, bez konta, do 10 GB.
Wysyłaj duże pliki bezpiecznie z szyfrowaniem end-to-end
Przesyłaj pliki do 10 GB za darmo z szyfrowaniem end-to-end. Bez rejestracji. Twoje pliki są szyfrowane w przeglądarce przed przesłaniem — nikt inny nie może ich odczytać.
Wyślij plik