Nasi tureccy klienci poprosili nas o odpowiednią konfigurację kopii zapasowych dla ich centrum danych. Realizujemy podobne projekty w Rosji, ale tutaj historia dotyczyła raczej poszukiwania najlepszego sposobu, aby to zrobić.
Dane: istnieje lokalna pamięć masowa S3, istnieje Veritas NetBackup, która uzyskała nową, rozszerzoną funkcjonalność przenoszenia danych do pamięci obiektowej, teraz z obsługą deduplikacji, i występuje problem z wolną przestrzenią w tej lokalnej pamięci masowej.
Zadanie: zrobić wszystko tak, aby proces przechowywania kopii zapasowych był szybki i tani.
Właściwie wcześniej wszystko w S3 było po prostu plikami i były to kompletne rzuty krytycznych maszyn centrum danych. Oznacza to, że nie jest zbyt zoptymalizowany, ale na początku wszystko działało. Teraz czas to rozgryźć i zrobić to dobrze.
Zdjęcie pokazuje do czego doszliśmy:
Jak widać, pierwsza kopia zapasowa została wykonana powoli (70 Mb/s), a kolejne kopie zapasowe tych samych systemów były znacznie szybsze.
Właściwie w dalszej części znajduje się trochę więcej szczegółów na temat dostępnych funkcji.
Kopie zapasowe dzienników dla tych, którzy są gotowi przeczytać pół strony zrzutuPełne z ponownym skanowaniem
18 grudnia 2018 12:09:43 — Informacje o akceleratorze bpbkar (pid=4452) wysłały do serwera 14883996160 bajtów z 14883994624 bajtów, optymalizacja 0.0%
18 grudnia 2018 r., 12:10:07 - Informacje NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Raport=Statystyki PDDO (użyty strumień wielowątkowy) dla (NBCC): przeskanowano: 14570817 KB, wysłano CR: 1760761 KB, CR wysłano przez FC: 0 KB, dedup: 87.9%, pamięć podręczna wyłączona
pełny
18 grudnia 2018 12:13:18 — Informacje o akceleratorze bpbkar (pid=2864) wysłały do serwera 181675008 bajtów z 14884060160 bajtów, optymalizacja 98.8%
18 grudnia 2018 r., 12:13:40 - Informacje NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Raport=Statystyki PDDO dla (NBCC): przeskanowane: 14569706 KB, wysłane CR: 45145 KB, CR wysłane przez FC: 0 KB, deduplikacja: 99.7%, pamięć podręczna wyłączona
Przyrostowe
18 grudnia 2018 12:15:32 — Informacje o akceleratorze bpbkar (pid=792) wysłały do serwera 9970688 bajtów z 14726108160 bajtów, optymalizacja 99.9%
18 grudnia 2018 r., 12:15:53 - Informacje NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Raport=Statystyki PDDO dla (NBCC): przeskanowane: 14383788 KB, wysłane CR: 15700 KB, CR wysłane przez FC: 0 KB, deduplikacja: 99.9%, pamięć podręczna wyłączona
pełny
18 grudnia 2018 12:18:02 — Informacje o akceleratorze bpbkar (pid=3496) wysłały do serwera 171746816 bajtów z 14884093952 bajtów, optymalizacja 98.8%
18 grudnia 2018 r., 12:18:24 - Informacje NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Raport=Statystyki PDDO dla (NBCC): przeskanowane: 14569739 KB, wysłane CR: 34120 KB, CR wysłane przez FC: 0 KB, deduplikacja: 99.8%, pamięć podręczna wyłączona
Jaki jest problem
Klienci chcą jak najczęściej wykonywać kopie zapasowe i przechowywać je możliwie najtaniej. Najlepiej przechowywać je tanio w magazynach obiektowych takich jak S3, ponieważ są one najtańsze pod względem kosztów usługi w przeliczeniu na megabajt, skąd można przywrócić kopię zapasową w rozsądnym czasie. Kiedy kopii zapasowych jest dużo, nie staje się to zbyt tanie, ponieważ większość pamięci zajmują kopie tych samych danych. W przypadku HaaS tureckich kolegów pamięć można zagęścić o około 80-90%. Wiadomo, że dotyczy to konkretnie ich specyfiki, ale zdecydowanie liczyłbym na co najmniej 50% dziadka.
Aby rozwiązać ten problem, główni dostawcy od dawna tworzą bramy do Amazon S3. Wszystkie ich metody są kompatybilne z lokalnym S3, o ile obsługują Amazon API. W tureckim centrum danych tworzona jest kopia zapasowa na naszym S3, a także w „Kompresorze” T-III w Rosji, ponieważ ten schemat pracy sprawdził się w naszym przypadku.
A nasz S3 jest w pełni kompatybilny z metodami tworzenia kopii zapasowych Amazon S3. Oznacza to, że wszystkie narzędzia do tworzenia kopii zapasowych obsługujące te metody umożliwiają skopiowanie wszystkiego do takiej pamięci „od razu po wyjęciu z pudełka”.
Veritas NetBackup dodał funkcję CloudCatalyst:
Oznacza to, że między maszynami, których kopię zapasową należy utworzyć, a bramą znajduje się pośredni serwer Linux, przez który przechodzi ruch kopii zapasowych od agentów SRK i jest na bieżąco deduplikowany przed przesłaniem go do S3. Jeśli wcześniej istniało 30 kopii zapasowych po 20 GB z kompresją, teraz (ze względu na podobieństwo maszyn) ich objętość stała się o 90% mniejsza. Silnik deduplikacji używany jest w taki sam sposób, jak przy przechowywaniu na zwykłych dyskach za pomocą Netbackup.
Oto co dzieje się przed serwerem pośrednim:
Przetestowaliśmy i doszliśmy do wniosku, że po wdrożeniu w naszych centrach danych oszczędza to miejsce w pamięci S3 dla nas i dla klientów. Jako właściciel komercyjnych data center oczywiście rozliczamy się zależnie od zajmowanego wolumenu, ale i tak jest to dla nas bardzo opłacalne – bo zaczynamy zarabiać na bardziej skalowalnych miejscach w oprogramowaniu, a nie na wynajmie sprzętu. No i to jest redukcja kosztów wewnętrznych.
Dzienniki228 Zadań (0 w kolejce 0 aktywne 0 oczekujące na ponowną próbę 0 zawieszone 0 niekompletne 228 wykonane — wybrano 13)
(Zastosowano filtr [13])
Identyfikator zadania Typ Stan Szczegóły Stan Zasady zadania Harmonogram zadania Klient Media Server Czas rozpoczęcia Czas, który upłynął Czas zakończenia Jednostka pamięci Próba operacji Kilobajty Pliki Nazwa ścieżki % Ukończono (szacunkowo) PID zadania Właściciel Kopiuj Identyfikator zadania nadrzędnego KB/s Aktywny start Aktywny czas, który upłynął Aktywna sesja profilu Vault robota Nośnik identyfikacyjny do wyrzucenia ruchu danych Typ poza hostem Priorytet główny Szybkość deduplikacji Optymalizacja akceleratora transportu Instancja lub Host udziału bazy danych
— 1358 Wykonano migawkę 0 VMware — NGNCloudADC NBCC 18 grudnia 2018 12:16:19 00:02:18 18 grudnia 2018 12:18:37 STU_DP_S3_****kopia zapasowa 1 100% root 1358 18 grudnia 2018 12 :16:27 PM 00:02:10 Dysk natychmiastowego odzyskiwania Standard WIN-*********** 0
1360 Kopia zapasowa wykonana 0 VMware Full NGNCloudADC NBCC 18 grudnia 2018 12:16:48 00:01:39 18 grudnia 2018 12:18:27 STU_DP_S3_****kopia zapasowa 1 14,535,248 149654 100 23858 1358% 335,098 root 18 2018 12 16 grudnia , 48 00:01:39 0:99.8:99 Dysk natychmiastowego odzyskiwania Standard WIN-*********** XNUMX XNUMX% XNUMX%
1352 Wykonano migawkę 0 VMware - NGNCloudADC NBCC 18 grudnia 2018 12:14:04 00:02:01 18 grudnia 2018 12:16:05 STU_DP_S3_****kopia zapasowa 1 100% root 1352 18 grudnia 2018 12: 14:14 00:01:51 Dysk natychmiastowego odzyskiwania Standard WIN-*********** 0
1354 Kopia zapasowa wykonana 0 VMware Przyrostowa NGNCloudADC NBCC 18 grudnia 2018 12:14:34 00:01:21 18 grudnia 2018 12:15:55 STU_DP_S3_****kopia zapasowa 1 14,380,965 147 100 23617 1352% 500,817 root 18 2018 12 14 grudnia , 34 00:01:21 0:99.9:100 Dysk natychmiastowego odzyskiwania Standard WIN-*********** XNUMX XNUMX% XNUMX%
1347 Wykonano migawkę 0 VMware - NGNCloudADC NBCC 18 grudnia 2018 12:11:45 00:02:08 18 grudnia 2018 12:13:53 STU_DP_S3_****kopia zapasowa 1 100% root 1347 18 grudnia 2018 12: 11:45 00:02:08 Dysk natychmiastowego odzyskiwania Standard WIN-*********** 0
1349 Kopia zapasowa wykonana 0 VMware Full NGNCloudADC NBCC 18 grudnia 2018 12:12:02 00:01:41 18 grudnia 2018 12:13:43 STU_DP_S3_****kopia zapasowa 1 14,535,215 149653 100 23508 1347% 316,319 root 18 2018 12 12 grudnia , 02 00:01:41 0:99.7:99 Dysk natychmiastowego odzyskiwania Standard WIN-*********** XNUMX XNUMX% XNUMX%
1341 Wykonano migawkę 0 VMware - NGNCloudADC NBCC 18 grudnia 2018 12:05:28 00:04:53 18 grudnia 2018 12:10:21 STU_DP_S3_****kopia zapasowa 1 100% root 1341 18 grudnia 2018 12: 05:28 00:04:53 Dysk natychmiastowego odzyskiwania Standard WIN-*********** 0
1342 Kopia zapasowa wykonana 0 VMware Full_Rescan NGNCloudADC NBCC 18 grudnia 2018 12:05:47 00:04:24 18 grudnia 2018 12:10:11 STU_DP_S3_****kopia zapasowa 1 14,535,151 149653 100 22999 1341% 70,380 root 18 2018 12 05 grudzień 47 , 00 04:24:0 87.9:0:XNUMX Dysk natychmiastowego odzyskiwania Standard WIN-*************** XNUMX XNUMX% XNUMX%
1339 Wykonano migawkę 150 VMware - NGNCloudADC NBCC 18 grudnia 2018 11:05:46 00:00:53 18 grudnia 2018 11:06:39 STU_DP_S3_****kopia zapasowa 1 100% root 1339 18 grudnia 2018 11: 05:46 00:00:53 Dysk natychmiastowego odzyskiwania Standard WIN-*********** 0
1327 Wykonano migawkę 0 VMware - **********.**********.cloud NBCC 17 grudnia 2018 12:54:42 05:51:38 17 grudnia 2018 6:46:20 STU_DP_S3_****kopia zapasowa 1 100% root 1327 17 grudnia 2018 12:54:42 05:51:38 Dysk natychmiastowego odzyskiwania Standard WIN-*********** 0
1328 Kopia zapasowa wykonana 0 VMware Pełny **********.**********.cloud NBCC 17 grudnia 2018 12:55:10 05:29:21 17 grudnia 2018 6:24:31 STU_DP_S3_****kopia zapasowa 1 222,602,719 258932 100 12856 1327% 11,326 root 17 2018 12 55 grudnia 10 05:29:21 0:87.9:0 Dysk natychmiastowego odzyskiwania Standard WIN-*********** XNUMX XNUMX% XNUMX%
1136 Wykonano migawkę 0 VMware - **********.**********.cloud NBCC 14 grudnia 2018 4:48:22 04:05:16 14 grudnia 2018 8:53:38 STU_DP_S3_****kopia zapasowa 1 100% root 1136 14 grudnia 2018 4:48:22 04:05:16 Dysk natychmiastowego odzyskiwania Standard WIN-*********** 0
1140 Kopia zapasowa wykonana 0 VMware Full_Scan *******.**********.cloud NBCC 14 grudnia 2018 4:49:14 03:49:58 14 grudnia 2018 8:39:12 STU_DP_S3_****kopia zapasowa 1 217,631,332 255465 100 26438 1136% 15,963 root 14 2018 4 49 grudnia 14 03:49:58 0:45.2:0 Dysk natychmiastowego odzyskiwania Standard WIN-*************** XNUMX XNUMX% XNUMX%
Akcelerator pozwala na ograniczenie ruchu pochodzącego od agentów, ponieważ Przesyłane są tylko zmiany danych, co oznacza, że nawet pełne kopie zapasowe nie są przesyłane w całości, ponieważ serwer multimediów zbiera kolejne pełne kopie zapasowe z przyrostowych kopii zapasowych.
Serwer pośredni ma własną pamięć masową, w której zapisuje „pamięć podręczną” danych i utrzymuje bazę danych na potrzeby deduplikacji.
Kompletna architektura wygląda następująco:
- Serwer główny zarządza konfiguracją, aktualizacjami itp. i jest zlokalizowany w chmurze.
- Serwer multimediów (pośrednia maszyna *nix) powinien być zlokalizowany najbliżej systemów redundantnych pod względem dostępności sieci. Tutaj wykonywana jest deduplikacja kopii zapasowych ze wszystkich zarezerwowanych maszyn.
- Na komputerach objętych kopią zapasową znajdują się agenci, którzy zazwyczaj wysyłają do serwera multimediów tylko to, czego nie ma w jego pamięci.
Wszystko zaczyna się od pełnego skanowania - jest to pełnoprawna pełna kopia zapasowa. W tym momencie serwer multimediów pobiera wszystko, deduplikuje i przesyła do S3. Prędkość do serwera multimediów jest niska, ale z niego jest wyższa. Głównym ograniczeniem jest moc obliczeniowa serwera.
Poniższe kopie zapasowe są kompletne z punktu widzenia wszystkich systemów, ale w rzeczywistości są czymś w rodzaju syntetycznych pełnych kopii zapasowych. Oznacza to, że faktyczny transfer i zapis na serwerze multimediów następuje tylko w przypadku tych bloków danych, które nie występowały jeszcze wcześniej w kopiach zapasowych maszyn wirtualnych. I tylko te bloki danych, których hash nie znajduje się w bazie danych deduplikacji serwera multimediów, są przesyłane i zapisywane w S3. Mówiąc prościej, jest to coś, czego nigdy wcześniej nie widziano w żadnej kopii zapasowej pojedynczej maszyny wirtualnej.
Podczas przywracania serwer multimediów żąda od S3 niezbędnych zdeduplikowanych obiektów, ponownie je nawadnia i przesyła do agentów IRB, tj. podczas przywracania należy wziąć pod uwagę wielkość ruchu, która będzie równa rzeczywistej objętości przywracanych danych.
Oto jak to wygląda:
A oto kolejny kawałek logów169 Zadań (0 w kolejce 0 aktywne 0 oczekujące na ponowną próbę 0 zawieszone 0 niekompletne 169 wykonane — wybrano 1)
Identyfikator zadania Typ Stan Szczegóły Stan Zasady zadania Harmonogram zadania Klient Media Server Czas rozpoczęcia Czas, który upłynął Czas zakończenia Jednostka pamięci Próba operacji Kilobajty Pliki Nazwa ścieżki % Ukończono (szacunkowo) PID zadania Właściciel Kopiuj Identyfikator zadania nadrzędnego KB/s Aktywny start Aktywny czas, który upłynął Aktywna sesja profilu Vault robota Nośnik identyfikacyjny do wyrzucenia ruchu danych Typ poza hostem Priorytet główny Szybkość deduplikacji Optymalizacja akceleratora transportu Instancja lub Host udziału bazy danych
- 1372 Przywracanie wykonane 0 NBPR01 NBCC 19 grudnia 2018 1:05:58 00:04:32 19 grudnia 2018 1:10:30 1 14,380,577 1 100% 8548 ROOT 1372 70,567 19 grudnia 2018 1:06 :00 PM 00:04:30 WYGRAJ-*********** 90000
Integralność danych jest zapewniona przez ochronę samego S3 - istnieje tam dobra redundancja, która chroni przed awariami sprzętu, takimi jak martwe wrzeciono dysku twardego.
Serwer multimediów potrzebuje 4 TB pamięci podręcznej – jest to zalecana minimalna wielkość firmy Veritas. Więcej znaczy lepiej, ale tak właśnie zrobiliśmy.
Łączny
Kiedy partner wrzucił do naszego S3 20 GB, my przechowaliśmy 60 GB, bo zapewniamy potrójną georezerwację danych. Teraz ruch jest znacznie mniejszy, co jest dobre zarówno dla kanału, jak i taryf za przechowywanie.
W tym przypadku trasy są zamknięte poza „dużym Internetem”, ale można kierować ruchem przez VPN L2 przez Internet, ale lepiej zainstalować serwer multimediów przed wejściem dostawcy.
Jeśli jesteś zainteresowany poznaniem tych funkcji w naszych rosyjskich centrach danych lub masz pytania dotyczące wdrożenia w domu, zapytaj w komentarzach lub e-mailem [email chroniony].
Źródło: www.habr.com