Azure File Sync – czym jest
Azure File Sync najprościej mówiąc jest to OneDrive do zastosowań profesjonalnych. Dowolny zasób serwerowy lub klastrowy synchronizujemy z zasobem chmurowym (Storage account w Azure), a dokładniej to mała usługa windowsowa pilnuje żeby wszystko było synchronizowane.
To gdzie są moje dane?
Mamy dwie opcje. Albo wszystkie dane są lokalnie i dodatkowo w Azure, albo ustawiamy że lokalnie trzymamy tylko najświeższe pliki, a te mniej używane leżą tylko w Azure i są dociągane gdy ktoś się do nich odwoła (dokładnie tak samo jak robi to OneDrive).
Przypadki użycia
1. Mam mały zasób na backupy, a backupów coraz więcej
Niech pierwszy rzuci kamieniem ten, któremu nigdy nie skończyło się miejsce 😉
Kupujemy dyski, szacujemy na parę lat do przodu ile tych backupów będzie na naszym klastrze na backupy, po czym rzeczywistość tworzy swoją własną matematykę i nic się nie zgadza. No ale kto powiedział że wszystkie backupy muszą być lokalnie? Jak będzie awaria to potrzebujemy tylko aktualnych, a nie tych z zeszłego miesiąca. A jak potrzebujemy z zeszłego miesiąca, to tylko jakiś mały wycinek a nie wszystkie, więc możemy poczekać żeby się dociągnęły z chmury.
Cloud Tiering
W swoich środowiskach ustawiłem na początek żeby lokalnie były trzymane tylko pliki z ostatnich 14 dni. Starsze kopie leżą tylko w chmurze. Dzięki temu zależnie jak długo trzymamy w różnych środowiskach kopie, odzyskujemy od kilku do kilkudziesięciu procent przestrzeni.
Na zasobie widzimy oczywiście wszystkie, tylko analogicznie jak w przypadku OneDrive, pliki które są tylko w chmurze lokalnie mają tylko metadate, a zawartość dociągnie się w przypadku dostępu do takiego pliku. Na przykład możemy spokojnie uruchomić odtwarzanie backupy bazy danych (który jest już tylko w chmurze), będzie on tylko trochę wolniejszy bo plik będzie strumieniowany przez internet.
2. Ransomware – chronić się kto może
W obecnych czasach ataki typu ransomware są największą zmorą wszystkich. Widziałem już takie środowiska gdzie wszystko zostało zaszyfrowane, łącznie z tym że zatrzymany został klaster MSSQL i zaszyfrowane wszystkie jego pliki.
Jedną z dróg minimalizacji zagrożenia jest minimalizowanie uprawnień osób które zajmują się takim środowiskiem, ale i tak nie zastąpi to dobrego backupy. Najlepiej takiego który w razie ataku nie zostanie zaszyfrowany, albo mamy kopię backupu, albo jeszcze kopię kopii backupu.
Świetnym rozwiązaniem wydaje się Azure File Sync. Wszystkie pliki automatycznie synchronizowane są z chmurą, a po stronie Azure dodatkowo konfigurujemy (np. codzienne) snapshoty. One są za darmo w przypadku backupów, bo tylko modyfikacje plików by nas kosztowały. W przypadku gdy ktoś nam zaszyfruje backupy, to poleci to synchronizacją do Azure, ale po stronie Azure mamy snapshoty które pozwalają nam dostać się do wersji plików przed szyfrowaniem.
Dostęp do zasobów po awarii
To jest prawdziwa wisienka na torcie. Nawet jak stracimy całe DC, całą firmę, wybuchnie pół planety (ale nie te pół z rejonem Azure gdzie trzymamy pliki), to zasób File Share który utworzyliśmy na naszym Storage Account, podpinamy jedną komendą jako zamapowany dysk gdziekolwiek. Tak, gdziekolwiek gdzie mamy dostęp do internetu, możemy nawet na własnym laptopie, jeżeli jest wystarczająco duży i ciężki.
W praktyce plan po takim najgorszym kataklizmie to postawienie najszybszych maszynek w Azure, w tym samym regionie gdzie nasze kopie, a następnie ich szybkie odtwarzanie w lokalnej Azurowej sieci.
Koszty
Same składowanie plików w Azure za darmo nie jest, musimy założyć Storage Account, utworzyć File Share, zdecydować na jakim poziomie HA i szybkości będziemy bazować.
Microsoft dodatkowo nie ułatwia szacowania, licząc użycie na podstawie swoich własnych metryk, których nie jesteśmy w stanie zmierzyć we własnym środowisku. Jedyna opcja to skonfigurowanie środowiska Proof of Concept i rozpoczęcia synchronizacji z mniejszym wolumenem danych. W ten sposób możemy poznać mniej więcej jakie to będą koszty.
Problemy
Nie ma róży bez kolców. Jeżeli w ogóle rozważamy taki mechanizm zabezpieczenia, to pewnie dlatego że mamy środowisko onprem, tzn. wszystkie serwery leżą w jakiejś kolokacji, albo u kogoś pod biurkiem?
1. Łącze internetowe, punkty wymiany ruchu, trasy
Potrzebujemy łącza, szybkiego, stabilnego, działającego. Nawet nie tylko łącza, potrzebujemy krótkiej trasy do regionu Azure który wybierzemy. Ale i to nie daje nam gwarancji, bo po drodze są operatorzy węzłów wymiany ruchu, a oni nie lubią jak im ktoś nagle zapycha sieć. Przekonałem się o tym boleśnie przy pierwszym lockdownie, gdy nagle okazało się, że za węzłem we Frankfurcie, w drodze do jednego z regionów Azure, ktoś mnie zaczął blokować do 200 Mbps. Równiutko 200 Mbps, jak od linijki. Przy produkcyjnym ruchu było to trochę mało. Ale na trasy BGP wpływu nie mamy.
Zasada pierwsza, wybieramy region który jest najbliżej. Aktualnie to region Azure we Frankfurcie, ale i tu coś lub ktoś potrafi nas przyblokować, aktualnie do 400-600 Mbps, mimo bezpośredniego wpięcia obu serwerowni (źródłowej i docelowej) bezpośrednio we Frankfurcie.
Jest na to obejście, możemy wykupić sobie Express Route i spiąć się bezpośrednio z Azure, powinno być szybciej. Nie testowałem, na razie przyjmuję te limity które spotkałem i zobaczymy co przyniesie przyszłość.
2. Ilość danych, szybkość dysków
Backupy robimy zwykle na dyski które szybko zapisują sekwencyjnie. No ale niektóre pliki są małe, więc podpadają bardziej pod kategorię dużej ilości operacji z małymi plikami. O ile zapis na klaster backupowy zwykle poleci przez jakiś cache SSD, więc będzie szybko, to synchronizacja może już z niego nie skorzystać.
No i się na tym przejechałem gdy okazało się, że odczytanie wszystkich plików przez komponent odpowiedzialny za synchronizację jest wolniejsze niż szybkość wpadania nowych plików…
Niecałe 40 mln plików backupów, 20 TB. Z tego 30 procent wymieniało się w ciągu tygodnia na świeże pliki, a Azure twierdził że potrzebuje na wstępną synchronizację 2 miesięcy.
Tyle że ja po 3 tygodniach nie miałem już tych plików z którymi zaczynałem… Rozwiązania? Wymieniamy dyski w macierzy na szybsze, albo musimy zrezygnować z części plików, albo podzielić zasób na kilka klastrów plikowych i osobno je synchronizować.
Podsumowanie
Jak widać każda technologia, obojętnie jak kolorowa zaprezentowana przez marketing, ma swoje kruczki i widzę tajemną do zdobycia. Ale nie można się zrażać, ze wszystkich dostępnych chmurowych zasobów na backup backupów, to jest najlepsze rozwiązanie. Nie ma innego, które w razie awarii będzie tak łatwe do podpięcia i użycia.