Nasi tureccy klienci poprosili nas o poprawne skonfigurowanie backupu dla centrum danych. Realizujemy takie projekty w Rosji, ale tutaj historia bardziej dotyczyła badania, jak najlepiej to wykonać.
Dane: istnieje lokalne przechowywanie S3, jest Veritas NetBackup, który zyskał nową rozszerzoną funkcjonalność przenoszenia danych do obiektowych magazynów z obsługą deduplikacji, oraz istnieje problem z wolnym miejscem w tym lokalnym magazynie.
Zadanie: tak skonfigurować proces przechowywania kopii zapasowych, aby był szybki i tani.
Wcześniej w S3 wszystko było przechowywane po prostu jako pliki, były to pełne kopie krytycznych maszyn centrum danych. To znaczy, nie było to szczególnie zoptymalizowane, ale działało od początku. Teraz nadszedł czas, aby to poprawić.
Na obrazku to, do czego doszliśmy:
Jak widać, pierwsza kopia zapasowa była wykonywana wolno (70 MB/s), a kolejne kopie zapasowe tych samych systemów były znacznie szybsze.
Właściwie, dalej znajdziesz więcej szczegółów na temat tych specyfik.
Logi kopii zapasowych dla tych, którzy są gotowi czytać pół strony zrzutuFull with rescan
18 gru, 2018 12:09:43 PM — Info bpbkar (pid=4452) accelerator wysłał 14883996160 bajtów z 14883994624 bajtów do serwera, optymalizacja 0.0%
18 gru, 2018 12:10:07 PM — Info NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Raport=Statystyki PDDO (użyty wielowątkowy strumień) dla (NBCC): skanowane: 14570817 KB, CR wysłane: 1760761 KB, CR wysłane przez FC: 0 KB, deduplikacja: 87.9%, cache wyłączone
Full
18 gru, 2018 12:13:18 PM — Info bpbkar (pid=2864) accelerator wysłał 181675008 bajtów z 14884060160 bajtów do serwera, optymalizacja 98.8%
18 gru, 2018 12:13:40 PM — Info NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Raport=Statystyki PDDO dla (NBCC): skanowane: 14569706 KB, CR wysłane: 45145 KB, CR wysłane przez FC: 0 KB, deduplikacja: 99.7%, cache wyłączone
Przyrostowa
18 gru, 2018 12:15:32 PM — Info bpbkar (pid=792) accelerator wysłał 9970688 bajtów z 14726108160 bajtów do serwera, optymalizacja 99.9%
18 gru, 2018 12:15:53 PM — Info NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Raport=Statystyki PDDO dla (NBCC): skanowane: 14383788 KB, CR wysłane: 15700 KB, CR wysłane przez FC: 0 KB, deduplikacja: 99.9%, cache wyłączone
Full
18 gru, 2018 12:18:02 PM — Info bpbkar (pid=3496) accelerator wysłał 171746816 bajtów z 14884093952 bajtów do serwera, optymalizacja 98.8%
18 gru, 2018 12:18:24 PM — Info NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Raport=Statystyki PDDO dla (NBCC): skanowane: 14569739 KB, CR wysłane: 34120 KB, CR wysłane przez FC: 0 KB, deduplikacja: 99.8%, cache wyłączone
W czym problem
Klienci chcą wykonywać kopie zapasowe tak często, jak to możliwe, przechowując je jak najtaniej. Najlepiej przechowywać je tanio w magazynach obiektowych typu S3, ponieważ mają najniższe koszty utrzymania za megabajt, z którego można szybko przywrócić kopię zapasową. Gdy jest wiele kopii zapasowych, staje się to dość drogie, ponieważ większość miejsca zajmują kopie tych samych danych. W przypadku HaaS tureckich kolegów można skompresować przechowywanie o około 80-90%. Oczywiście odnosi się to do ich specyfiki, ale przynajmniej 50% deduplikacji można byłoby z pewnością oczekiwać.
Aby rozwiązać ten problem, główni dostawcy już od dawna zbudowali bramki na S3 Amazon. Wszystkie ich metody są zgodne z lokalnymi S3, jeśli wspierają API Amazon. W tureckim centrum danych kopia zapasowa jest tworzona w naszej S3, tak samo jak w T-III „Kompresorze” w Rosji, ponieważ ten sposób działania sprawdził się u nas bardzo dobrze.
Nasza S3 jest całkowicie kompatybilna z metodami tworzenia kopii zapasowych w Amazon S3. Oznacza to, że wszystkie narzędzia do kopii zapasowych, które wspierają te metody, pozwalają na kopiowanie wszystkiego do podobnego magazynu „z pudełka”.
W Veritas NetBackup wprowadzono funkcjonalność CloudCatalyst:
Oznacza to, że pomiędzy maszynami, które należy zbackupować, a bramką stanowi pośredni serwer Linux, przez który przechodzi ruch kopii zapasowych z agentów SRK, a ich deduplikacja odbywa się „w locie” przed przesłaniem ich do S3. Jeśli wcześniej było 30 kopii zapasowych po 20 GB z kompresją, to teraz (z powodu podobieństwa maszyn) jest ich objętość o 90% mniejsza. Silnik deduplikacji jest ten sam, co przy przechowywaniu na zwykłych dyskach za pomocą Netbackup.
Oto co się dzieje przed pośrednim serwerem:
Przetestowaliśmy to i doszliśmy do wniosku, że wprowadzenie tego w naszych centrach danych przynosi oszczędności miejsca w magazynach S3 zarówno dla nas, jak i dla klientów. Jako właściciel komercyjnych centrów danych, oczywiście, naliczamy opłaty na podstawie zajmowanej objętości, ale nadal jest to bardzo korzystne także dla nas — ponieważ zaczynamy zarabiać na bardziej skalowalnych miejscach w oprogramowaniu, a nie na wynajmie sprzętu. No i to zmniejsza nasze wewnętrzne wydatki.
Logi228 Zadań (0 W kolejce 0 Aktywnych 0 Czeka na ponowną próbę 0 Wstrzymanych 0 Niekompletnych 228 Zrobionych — 13 wybranych)
(Zastosowany filtr [13])
Id zadania Typ Stan Szczegóły stanu Status Polityka zadania Harmonogram klienta Serwer Czas rozpoczęcia Czas upływu Czas zakończenia Jednostka pamięci Próbuj Operacja Kilobajty Pliki Ścieżka % Zrealizowane (szacunkowe) Id PID zadania Właściciel Kopiuj Id rodzica zadania KB/Sek Aktywny Rozpoczęty Aktywny czas Robot Profil Vault Id sesji Media do wyjęcia Ruch danych Typ off-host Mistrz Priorytet Wskaźnik deduplikacji Akcelerator transportu Optymalizacja Instancja lub baza danych Udostępnij host
— 1358 Migawka Zrobione 0 VMware — NGNCloudADC NBCC 18 grudnia 2018 12:16:19 00:02:18 18 grudnia 2018 12:18:37 STU_DP_S3_****backup 1 100% root 1358 18 grudnia 2018 12:16:27 00:02:10 Naprawa doraźna Dysk standardowy WIN-*********** 0
1360 Kopia Zrobiona 0 VMware Pełna NGNCloudADC NBCC 18 grudnia 2018 12:16:48 00:01:39 18 grudnia 2018 12:18:27 STU_DP_S3_****backup 1 14,535,248 149654 100% 23858 root 1358 335,098 18 grudnia 2018 12:16:48 00:01:39 Naprawa doraźna Dysk standardowy WIN-*********** 0 99.8% 99%
1352 Migawka Zrobiona 0 VMware — NGNCloudADC NBCC 18 grudnia 2018 12:14:04 00:02:01 18 grudnia 2018 12:16:05 STU_DP_S3_****backup 1 100% root 1352 18 grudnia 2018 12:14:14 00:01:51 Naprawa doraźna Dysk standardowy WIN-*********** 0
1354 Kopia Zrobiona 0 VMware Inkrementalna NGNCloudADC NBCC 18 grudnia 2018 12:14:34 00:01:21 18 grudnia 2018 12:15:55 STU_DP_S3_****backup 1 14,380,965 147 100% 23617 root 1352 500,817 18 grudnia 2018 12:14:34 00:01:21 Naprawa doraźna Dysk standardowy WIN-*********** 0 99.9% 100%
1347 Migawka Zrobiona 0 VMware — NGNCloudADC NBCC 18 grudnia 2018 12:11:45 00:02:08 18 grudnia 2018 12:13:53 STU_DP_S3_****backup 1 100% root 1347 18 grudnia 2018 12:11:45 00:02:08 Naprawa doraźna Dysk standardowy WIN-*********** 0
1349 Kopia Zrobiona 0 VMware Pełna NGNCloudADC NBCC 18 grudnia 2018 12:12:02 00:01:41 18 grudnia 2018 12:13:43 STU_DP_S3_****backup 1 14,535,215 149653 100% 23508 root 1347 316,319 18 grudnia 2018 12:12:02 00:01:41 Naprawa doraźna Dysk standardowy WIN-*********** 0 99.7% 99%
1341 Migawka Zrobiona 0 VMware — NGNCloudADC NBCC 18 grudnia 2018 12:05:28 00:04:53 18 grudnia 2018 12:10:21 STU_DP_S3_****backup 1 100% root 1341 18 grudnia 2018 12:05:28 00:04:53 Naprawa doraźna Dysk standardowy WIN-*********** 0
1342 Kopia Zrobiona 0 VMware Pełne Przeskanowanie NGNCloudADC NBCC 18 grudnia 2018 12:05:47 00:04:24 18 grudnia 2018 12:10:11 STU_DP_S3_****backup 1 14,535,151 149653 100% 22999 root 1341 70,380 18 grudnia 2018 12:05:47 00:04:24 Naprawa doraźna Dysk standardowy WIN-*********** 0 87.9% 0%
1339 Migawka Zrobiona 150 VMware — NGNCloudADC NBCC 18 grudnia 2018 11:05:46 00:00:53 18 grudnia 2018 11:06:39 STU_DP_S3_****backup 1 100% root 1339 18 grudnia 2018 11:05:46 00:00:53 Naprawa doraźna Dysk standardowy WIN-*********** 0
1327 Migawka Zrobiona 0 VMware — *******.********.cloud NBCC 17 grudnia 2018 12:54:42 05:51:38 17 grudnia 2018 18:46:20 STU_DP_S3_****backup 1 100% root 1327 17 grudnia 2018 12:54:42 05:51:38 Naprawa doraźna Dysk standardowy WIN-*********** 0
1328 Kopia Zrobiona 0 VMware Pełna *******.********.cloud NBCC 17 grudnia 2018 12:55:10 05:29:21 17 grudnia 2018 18:24:31 STU_DP_S3_****backup 1 222,602,719 258932 100% 12856 root 1327 11,326 17 grudnia 2018 12:55:10 05:29:21 Naprawa doraźna Dysk standardowy WIN-*********** 0 87.9% 0%
1136 Migawka Zrobiona 0 VMware — *******.********.cloud NBCC 14 grudnia 2018 16:48:22 04:05:16 14 grudnia 2018 20:53:38 STU_DP_S3_****backup 1 100% root 1136 14 grudnia 2018 16:48:22 04:05:16 Naprawa doraźna Dysk standardowy WIN-*********** 0
1140 Kopia Zrobiona 0 VMware Pełne Przeskanowanie *******.********.cloud NBCC 14 grudnia 2018 16:49:14 03:49:58 14 grudnia 2018 20:39:12 STU_DP_S3_****backup 1 217,631,332 255465 100% 26438 root 1136 15,963 14 grudnia 2018 16:49:14 03:49:58 Naprawa doraźna Dysk standardowy WIN-*********** 0 45.2% 0%
Akcelerator pozwala zmniejszyć ruch od agentów, ponieważ przesyłane są jedynie zmiany danych, co oznacza, że nawet pełne kopie zapasowe nie są przesyłane w całości, ponieważ serwer multimedialny zbiera kolejne pełne kopie zapasowe z inkrementalnych kopii zapasowych.
Serwer pośredniczący ma swoją pamięć, gdzie zapisuje 'cache' danych i przechowuje bazę do deduplikacji.
W pełnej architekturze wygląda to tak:
- Serwer główny zarządza konfiguracją, aktualizacjami i innymi rzeczami i znajduje się w chmurze.
- Serwer multimedialny (pośrednia maszyna *nix) powinien znajdować się jak najbliżej systemów, które będą rezerwowane, pod względem dostępności sieciowej. Tutaj odbywa się deduplikacja kopii zapasowych ze wszystkich systemów, które są rezerwowane.
- Na maszynach rezerwowanych są agenci, którzy w ogólnym przypadku przesyłają na serwer multimedialny tylko to, czego nie ma w jego pamięci.
Wszystko zaczyna się od pełnego skanowania — to prawdziwa pełna kopia zapasowa. W tym momencie serwer multimedialny zabiera wszystko, wykonuje deduplikację i przesyła do S3. Prędkość do serwera multimedialnego jest niska, od niego — wyższa. Główne ograniczenie to moc obliczeniowa serwera.
Kolejne kopie zapasowe są pełne z perspektywy wszystkich systemów, ale w rzeczywistości są one czymś w rodzaju syntetycznych pełnych kopii zapasowych. To znaczy, że faktyczny transfer i zapis na serwerze multimedialnym dotyczy jedynie tych bloków danych, które wcześniej nie były obecne w kopiach zapasowych VM. A transfer i zapis do S3 dotyczy jedynie tych bloków danych, których hash nie ma w bazie deduplikacji serwera multimedialnego. Mówiąc prościej — chodzi o to, co nie było obecne w żadnej kopii zapasowej żadnej VM wcześniej.
Podczas przywracania serwer multimedialny żąda potrzebnych obiektów deduplikowanych z S3, rehydryzuje je i przesyła do agentów SRK, co oznacza, że należy uwzględnić wolumen ruchu podczas przywracania, który będzie równy rzeczywistemu wolumenowi przywracanych danych.
Tak to wygląda:
I oto kolejny fragment logów169 Zadań (0 w kolejce 0 aktywnych 0 oczekujących na ponowne próbki 0 zawieszonych 0 niekompletnych 169 zrealizowanych - 1 wybrane)
Id zadania Typ Stan Szczegóły stanu Status Polityka zadania Harmonogram klienta Serwer Czas rozpoczęcia Czas upływu Czas zakończenia Jednostka pamięci Próbuj Operacja Kilobajty Pliki Ścieżka % Zrealizowane (szacunkowe) Id PID zadania Właściciel Kopiuj Id rodzica zadania KB/Sek Aktywny Rozpoczęty Aktywny czas Robot Profil Vault Id sesji Media do wyjęcia Ruch danych Typ off-host Mistrz Priorytet Wskaźnik deduplikacji Akcelerator transportu Optymalizacja Instancja lub baza danych Udostępnij host
— 1372 Przywracanie zrealizowane 0 nbpr01 NBCC 19 grudnia 2018 13:05:58 00:04:32 19 grudnia 2018 13:10:30 1 14 380 577 1 100% 8548 root 1372 70 567 19 grudnia 2018 13:06:00 00:04:30 WIN-*********** 90000
Integralność danych jest zapewniona dzięki zabezpieczeniom samego S3 - tam jest dobra redundancja chroniąca przed awariami sprzętowymi, takimi jak uszkodzony talerz dysku twardego.
Media-serwera potrzebne jest 4 TB cache — to rekomendacja Veritas dotycząca minimalnej pojemności. Lepiej więcej, ale robiliśmy dokładnie tak.
Podsumowanie
Kiedy partner przesyłał do naszego S3 20 GB, przechowywaliśmy 60 GB, ponieważ zapewniamy potrójne georedundancje danych. Teraz ruch jest znacznie mniejszy, co jest korzystne zarówno dla łącza, jak i dla rozliczeń za przechowywanie.
W tym przypadku trasy są zamknięte poza „wielkim Internetem”, ale można przesyłać ruch również przez VPN L2 przez Internet, ale lepiej umieścić serwer multimedialny przed wejściem dostawcy.
Jeśli chcesz się dowiedzieć więcej o tych funkcjach w naszych rosyjskich centrach danych lub masz pytania dotyczące implementacji u siebie — pytaj w komentarzach lub na adres ekorotkikh@croc.ru.
Źródło: habr.com
