Backup w dużej skali z wykorzystaniem oprogramowania Bacula - Część III

radekk, wt., 2011-01-25 10:21

Zapraszam do lektury kolejnej, trzeciej już części cyklu artykułów opisujących wdrożenie oprogramowania Bacula w środowisku dużego dostawcy hostingowego. W części tej przedstawione zostaną szczegóły techniczne i architektoniczne wdrożonego Centralnego Systemu Backupowego opartego o oprogramowanie Bacula. Dzisiejsza część jest dosyć długa lecz obfituje w bardzo interesujące smaczki. Zapraszam.

Część III

Moje ostatnie dwie części wzbudziły spore zainteresowanie - tak duże, że moja skrzynka pocztowa została przeładowana ogromem wiadomości i pytań z całego świata. W związku z tym, niniejsza część przedstawi wam więcej szczegółów dotyczących naszej infrastruktury kopii zapasowych Bacula, natomiast w następnej przedyskutujemy naszą konfiguracją oprogramowania Bacula.
Na wstępie małe podsumowanie dla co bardziej niecierpliwych czytelników: nie stosowaliśmy absolutnie żadnego tuningu samego oprogramowania Bacula. Jednakże, dużo czasu i pracy włożyliśmy w to, aby dogłębnie zrozumieć w jaki sposób działa i jak się ma to działanie do zasobów jakie Bacula otrzymała w naszym środowisku. To był nasz główny klucz do pełnego sukcesu z wykorzystania oprogramowania Bacula.

Co więcej: jest coś niesamowitego w tym, że Bacula potrafi tak efektywnie dyrygować tak rozległym środowiskiem! Kern oraz jego zespół znają swój fach, to jest pewne.
Zalecam, abyś zanim będziesz czytał dalej, zaopatrzył się teraz w swój ulubiony napój, bo to całkiem długa historia.

Obecnie w naszej infrastrukturze kopii zapasowych Bacula mamy w sumie 9 serwerów: trzech Dyrektorów (Bacula Director), trzy Serwery składowania (Bacula Storage Daemon) i w końcu trzy serwery z bazami katalogowymi MySQL. Wynika z tego, że każdy z Dyrektorów “posiada” swój własny serwer składowania oraz bazę katalogową. Dyrektorzy uruchomieni są na serwerach z systemem operacyjnym Linux, natomiast serwery składowania, jak i bazy katalogowe działają pod systemem Solaris.

Teraz przedstawię Wam ogólne spojrzenie na nasze środowisko oprogramowania Bacula.

Sieć backupowa

Wszystkie nasze maszyny mają dostęp do specjalnej sieci, która jest fizycznie odseparowana od naszych różnych sieci produkcyjnych. Sieć ta w 100% dedykowana jest do wykonywania kopii zapasowych i odtwarzania. Mówimy tutaj o liczbie ponad 100 przełączników sieciowych, dedykowanych interfejsach sieciowych, kablach, światłowodach, itp. Każda z naszych szaf rackowych posiada dedykowany przełącznik sieciowy sieci backupowej. Wszystkie te przełączniki posiadają 2Gbit/s uplinki do głównej sieci szkieletowej o przepływności 30Gbit/s (3 przełączniki rdzeniowe z redundantnymi uplinkami 10Gbit/s każdy), która także w całości jest dedykowana do zadań backupowych. Ta sieć szkieletowa podłączona jest do naszej zdalnej lokalizacji poprzez odpowiednią liczbę łączy optycznych 10Gbit/s, które udostępniają połączenie sieciowe o przepływności 10Gbit/s dla każdego z naszych Baculowych serwerów składowania.

Operacje sieciowe są wykonywane niezwykle efektywnie; są też ciągle monitorowane zarówno w zakresie przepływności jak i osiąganego obciążenia. Traktujemy tą sieć na równi z innymi sieciami produkcyjnymi; solidny projekt architektury, wysoki stopień redundancji, dobrej jakości sprzęt i wykorzystany monitoring są bardzo ważne dla jej działania. Zarówno przepływność sieci jak i jej opóźnienia są ważną częścią wydajności naszego środowiska Bacula.

Serwery Składowania

Wszystkie nasze serwery składowania działają na systemie operacyjnym Solaris, a wszystkie wolumeny backupowe Baculi są składowane na trzech dużych pulach dyskowych ZFS. W tym miejscu muszę dodać, ze jestem zagorzałym zwolennikiem systemu Solaris. Mógłbym godzinami przemawiać o cudownych funkcjonalnościach ZFS, dtrace, COMSTAR, crossbow i tym podobnych, ale to rezerwuję sobie na inny czas. ZFS jest nowoczesnym systemem plików wymyślonym i zaprojektowanym przez nieistniejącą1 już firmę Sun. Jest systemem, który pozwala zamienić twój sprzęt w ekstremalnie efektywne i wysoce skalowalne rozwiązanie do przechowywania danych. Oferuje przy tym bezprecedensową ochronę danych i bogactwo zaawansowanych funkcjonalności.

ZFS

  • jest zawsze spójny na dysku (czyli: Nigdy więcej fsck.)
  • sumy kontrolne każdego bloku zapisywanego na dysku zabezpieczają przed ukrytymi błędami w danych
  • posiada właściwości samonaprawcze
  • wykorzystuje model puli zasobów dyskowych
  • posiada potokowy silnik I/O (masowo skalowalny)
  • nie ma odgórnie ustawionych limitów (wspiera nielimitowaną ilość filesystemów, plików, dowiązań, wpisów w katalogach, wielkości plików, itp.)
  • oferuje zaawansowane funkcjonalności (cacheowanie, wbudowana kompresja, wbudowane szyfrowanie, migawki, klony, repliakcję, itd.)
  • oferuje bardzo prosty model administracji

W ciągu ostatnich trzech lat widziałem bardzo wiele złych, naprawdę złych rzeczy, które przytrafiały się naszym serwerom przechowującym dane na systemie plików ZFS. Zaliczyliśmy: uszkodzone płyty główne, złe kable i kości pamięci, uszkodzone kontrolery i utratę ogromnych ilości uszkodzonych dysków. Wszystko co tylko możliwe, lecz bez utraty ani jednego bajtu danych. Jeśli zależy ci na danych powinieneś wybrać ZFS.

Teraz każdy serwer przechowywania posiada ponad 120 dysków w puli dyskowej RAID-Z2 składającej się z wielokrotności 7 dyskowych vdev’ów, zbudowanych z dysków typu SAS Nearline o szybkości 7200RPM. Każdy serwer posiada po trzy kontrolery typu PERC 6/E, które pozwalają nam podłączyć do 9 macierzy dyskowych typu MD1000. Wszystkie macierze dyskowe posiadają podwójne moduły I/O i włączoną wielościeżkowość.

Każdy klient platformy Bacula posiada swój własny, dedykowany system plików ZFS (jedna z właściwości ZFS, tzw. Nested Filesystems1), co pozwala nam kontrolować kompresję, poziom kwoty (quota), rezerwacji, szyfrowania itp. dla każdego klienta osobno. Na profilowanie demona składowania Baculi pod obciążeniem produkcyjnym przeznaczyłem dużo czasu. Dtrace i Solaris w ogólności dały mi fenomenalne wsparcie w obszarach wzorców i wielkości ruchu I/O, a także w poszukiwaniu sygnałów możliwych blokad, itp. Solaris w porównaniu do innych systemów operacyjnych udostępnia mnóstwo narzędzi do tego celu.

Wykorzystaliśmy ogrom tych informacji aby uruchomić symulacje i określić bazę referencyjną dla naszych dalszych testów. W trakcie tego odkryliśmy, że:

  1. Dodanie urządzeń do demona składowania Baculi zwiększa równoległość i w konsekwencji wydajność
  2. Nie było większych problemów z blokowaniem podczas działania nawet 100 aktywnych urządzeń (Kern miał pewne wątpliwości co spowodowało nasze testy)
  3. Demon składowania Baculi generuje asynchroniczne i sekwencyjne I/O
  4. Najbardziej efektywna wielkość rekordu (bloku systemu plików ZFS) to 64k, zarówno podczas operacji backupowych, jak i podczas operacji odtwarzania
  5. 16 GB DRAM dla pojedynczego serwera składowania było w zupełności wystarczające dla ZFS ARC (ang. Adaptive Replacement Cache1)
  6. Obciążenie procesora (CPU Utilisation) było akceptowalne

Solarisowa wersja demona składowania Baculi jest stabilna i działa ekstremalnie dobrze. Uruchamialiśmy po 100 zadań backupowych w jednym czasie dla każdego łańcucha Dyrektor—Demon Składowania—Katalog, pompując w sumie około 2GB/s do naszych demonów składowania. Obciążenie procesorów było mniejsze niż 90% (2 x 3 Ghz Quad XEON) i prawie równomiernie rozkładało się pomiędzy oprogramowanie Bacula oraz ZFS/Solaris.

Wszystkie trzy serwery składowania mają zaplanowaną wymianę na 48 rdzeniowe maszyny Dell R815. Jak tylko będziemy je mieli na miejscu oraz kiedy zrekonfigurujemy opisaną powyżej sieć backupową by wykorzystywała “jumbo frames”, powinniśmy być naprawdę blisko wykorzystania pełnych możliwości połączeń 10 Gbit.

Serwery Katalogowe MySQL

Nasze serwery katalogowe wykorzystują MySQL na Solarisie (głównie z tych samych powodów dla których na Solarisie działają nasze Serwery Składowania).
ZFS zapewnia nam: hybrydowe pule składowania zdolne do osiągnięcia ogromnych ilości operacji na sekundę (IOPS), niskie opóźnienia operacji I/O, łatwe i sprawne wykonania migawek naszych danych bazy MySQL oraz zdolność dopasowania wielkości rozmiaru rekordu systemu plików na ZFS do faktycznego rozmiaru I/O używanego przez InnoDB.
Dtrace dało nam wprost niewiarygodną ilość informacji, zarówno o tym co wykonują nasze bazy danych oraz jak zmiany konfiguracji wpływają na różne interesujące nas składowe, takie jak czasy zapytań bazodanowych, itp.

Sporo się ostatnio pisało na forach czy listach dyskusyjnych o działaniu oprogramowania Bac­ula  wraz z MySQL. Jeśli odetniemy się od wszystkich bzdur, od całej „religii” i uczuć osobistych, to zostają nam dwa pewniki:

  1. Schemat bazy katalogowej Bac­ula i powiązanych zapytań nie jest pisany / dedykowany pod wydajności bazy opartej na MySQL.
  2. Gdy mowa o wdrożeniach o dużej skali deweloperzy Bac­uli mają większe doświadczenie z Post­greSQL.

Jednakże, nie oznacza to że MySQL i  Bac­ula w dużej skali nie działają ze sobą. Mamy bowiem pewne ogromne zadania (15 milionów plików, i nawet więcej), które spisują się bardzo dobrze, zarówno przy operacjach backupu, jak i przy operacjach odtwarzania. Cóż, być może siła  MySQL jakoś szczególnie uwidoczniła się u nas? Ciekawych czytelników odsyłam do listy dyskusyjnej bacula-users, gdzie znajdziecie więcej informacji o konfiguracji naszych środowisk InnoDB i ZFS.

Wszystkie nasze serwery katalogowe na MySQL mają 2 Quad Core CPU i po 32 GB DRAM. Niższa, oparta o ZFS warstwa składowania składa się z 30 dysków Nearline SAS po 750 GB każdy w konfiguracji mirror (mirror bije RAID-Z jeśli chodzi o prędkość odczytu danych) oraz z kilku dysków SSD klasy Enterprise, które mają za zadanie usprawnienie synchronicznych operacji zapisu w ZFS. Od kiedy prawie wszystkie operacje zapisu w MySQL są synchroniczne, to efektywnie oznacza, że wszystkie zapisy generowane przez MySQL, kończą się na naszych SSD, zamiast pokrywać się rdzą w oczekiwaniu na powolne dyski.
Z niecierpliwością oczekujemy wydania GA bazy MySQL 5.5, która powinna dalece sprostać większości naszych przyszłych wyzwań związanych z wydajnością  i skalowaniem. Jak do tej pory baza MySQL obsługiwała nas dobrze, lecz YMMV (ang. Your Mileage May Vary - Możesz mieć odmienne zdanie). To podsumowuje naszą wycieczkę po infrastrukturze środowiska Bacula - następnym razem opiszemy konfigurację samego oprogramowania Bacula.

źródło: https://myunix.dk/2010/12/03/large-scale-disk-to-disk-backups-using-bacula-part-iii/

1) dopisek tłumacza