Skalowanie Bacula na przykładach

Klienci często mnie pytają czy Bacula Enterprise jest dla nich odpowiednio skalowalna. Jako skalowanie mają na myśli dwa podstawowe elementy: ilość możliwych do obsłużenia klientów (generalnie zadań backupowych) oraz ilość obsługiwanych plików w pojedynczej bazie katalogowej. W przypadku oprogramowania Bacula Enterprise zarówno ilość obsługiwanych klientów (zadań), jak i ilość obsługiwanych plików nie jest technicznie ograniczona i w rzeczywistych środowiskach zależy głównie od dostępnych zasobów serwera na którym działają Bacula Director oraz bazy katalogowe. Specjalnie w poprzednim zdaniu użyłem liczby mnogiej, gdyż Bacula Enterprise ma możliwość jednoczesnej obsługi większej ilości baz katalogowych, które przechowują informacje o backupach poszczególnych klientów. Faktycznie działające instalacje na świecie moga poszczycić się ponad 130M plików obsługiwanych w pojedynczej bazie katalogowej oraz obsługę ponad 2000 klientów przez pojedynczy Bacula Director. To sporo, może nawet lepiej niż komercyjna konkurencja. Jednak opisywanie i chwalenie się usłyszanymi (nawet formalnymi referencjami) nie jest tak przekonujące jak własne doświadczenia. Postanowiłem więc wykonać kilka testów do których zmobilizował mnie jeden z klientów (pozdrawiam koleżankę Gosię :)) chcący mieć potwierdzenie, że skalowalność Bacula nie jest tylko mityczna.

Test jaki chciałem wykonać to wykonanie backupu oraz budowanie drzewa odtwarzania dla środowiska zawierającego ponad 6M plików backupowanych w pojedynczym zadaniu. Na początek specyfikacja środowiska:

Jako serwer testowy posłuży nam maszyna wirtualna o poniższych parametrach:

# lscpu
Architecture:          x86_64
CPU op-mode(s):        64-bit
CPU(s):                2
Thread(s) per core:    1
Core(s) per socket:    1
CPU socket(s):         2
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 2
Stepping:              3
CPU MHz:               3411.978
Hypervisor vendor:     KVM
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
L2 cache:              4096K

# free
             total       used       free     shared    buffers     cached
Mem:       2061392    1656472     404920          0        684     896068
-/+ buffers/cache:     759720    1301672
Swap:       385016        420     384596

Jest to więc niewielkie środowisko testowe o bardziej niż ograniczonych zasobach. Backupowane zasoby to katalog /data/test o wspomnienej wcześniej ilości plików:

# find /data/test -print|wc -l
6040201

Uruchamiamy zadanie.

| jobid | name          | starttime           | type | level | jobfiles  | jobbytes | jobstatus |
+-------+---------------+---------------------+------+-------+-----------+----------+-----------+
|     1 | BackupClient1 | 2012-03-28 11:11:03 | B    | F     | 6,040,201 |        0 | T         |

Zadanie wykonane, teraz rozpoczynamy procedurę testów budowy drzewa odtwarzania. Wybieramy wykonane wcześniej zadanie i już po niecałej 1,5min możemy dowoli wybierać pliki (poniższe logi zostały przycięte wyłącznie do interesujacych informacji):

# time echo "restore jobid=1" | bconsole
You have selected the following JobId: 1

Building directory tree for JobId(s) 1 ...  +++++++++++++++++++++++++++++++++++++++++++++++++
6,000,000 files inserted into the tree.

cwd is: /
$
real    1m23.276s
user    0m0.008s
sys     0m0.000s

We wskazanym powyżej zadaniu Bacula musiała wykonać dwa czasochłonne kroki: najpierw pobrać z bazy danych wszystkie pliki należące do wskazanego zadania a następnie w pamięci zbudować drzewo katalogów tak aby możliwe było bardzo szybkie przeglądanie i wybieranie plików do odtworzenia. Szybkość może wynikać z tego, że w bazie katalogowej znajduje się tylko 6M plików, zróbmy więc kolejny backup i test odtwarzania:

# time echo restore jobid=2|bconsole
You have selected the following JobId: 2

Building directory tree for JobId(s) 2 ...  +++++++++++++++++++++++++++++++++++++++++++++++++
6,000,000 files inserted into the tree.

cwd is: /
$
real    1m57.407s
user    0m0.016s
sys     0m0.000s

Jak widać czas się nieznacznie wydłużył i w dalszym ciągu czas budowania jest relatywnie niewielki. Sprawdzmy także czy ilość danych w bazie wpłynęła na inne backupy, np. bardzo małe:

# time echo restore jobid=5|bconsole
You have selected the following JobId: 5

Building directory tree for JobId(s) 5 ...  ++++++++++++++++++++++++++++++++++++++
115 files inserted into the tree.

cwd is: /
$
real    0m0.048s
user    0m0.008s
sys     0m0.000s

Jak widać absolutnie nie wpływa. To potwierdza, że czas budowania drzewa odtwarzania zależy w głównej mierze od ilości plików w danym zadaniu backupowym a nie od ilości plików w całej bazie katalogowej. Sprawdźmy także jak wygląda budowanie drzewa dla zadań Full + Incremental (w naszym przykładzie incr zmienił ok. 20k plików):

# time echo restore jobid=2,6|bconsole
You have selected the following JobIds: 2,6

Building directory tree for JobId(s) 2,6 ...  +++++++++++++++++++++++++++++++++++++++++++++++++
6,000,000 files inserted into the tree.

cwd is: /
$
real    2m11.753s
user    0m0.008s
sys     0m0.004s

Troszkę dłużej niż w sam backup Full. To może kolejne przyrostowe???

# time echo restore jobid=2,6,7|bconsole
You have selected the following JobIds: 2,6,7

Building directory tree for JobId(s) 2,6,7 ...  +++++++++++++++++++++++++++++++++++++++++++++++++
6,000,000 files inserted into the tree.

cwd is: /
$
real    2m19.992s
user    0m0.008s
sys     0m0.016s

# time echo restore jobid=2,6,7,8|bconsole
You have selected the following JobIds: 2,6,7,8

Building directory tree for JobId(s) 2,6,7,8 ...  +++++++++++++++++++++++++++++++++++++++++++++++++
6,000,000 files inserted into the tree.

cwd is: /
$
real    2m5.344s
user    0m0.008s
sys     0m0.004s

Z powyższych przykładów widać, że backupy przyrostowe nie za bardzo zmieniają uzyskane czasy i są one praktycznie stałe.

Podstawowym czynnikiem ograniczającym wydajność procesu budowania drzewa odtwarzania jest wielkość pamieci serwera i pamięci przydzielonej dla silnika bazodanowego. W przykładowym teście PostgreSQL otrzymał 1024MB pamięci dzielonej co przy 2GB fizycznej pamięci dla serwera skutkowało niewielkim swapowaniem (swap ok. 15MB-20MB). Poza tym środowisko nie było praktycznie tuningowane ani optymalizowane. Parametry testowego serwera były niewiele lepsze od dostępnych aktualnie na rynku tabletów czy smartfonów. Mimo tego osiągnięte wyniki są rewelacyjne!