Szybkość wykonywanego backupu na maszynie wirtualnej.

Wysłane przez lukaszt 
Szybkość wykonywanego backupu na maszynie wirtualnej. 23 cze 2016 - 09:54:27

Send PM

Dzień dobry,

Postanowiłem zainstalować Baculę na maszynie wirtualnej Esxi 6.0.

Serwer (Director & Storage)
====================
System: ESXI 6
Sieć: e1000 z włączonym full duplex (emulująca kartę Intela)
Dysk: raid5 - 24TB
System plików: xfs
Pamięć: 4 GB
CPU: 2 rdzenie na hoście (Intel Xeon i5630 2.13 GHz)
Bacula: 7.0.5-7.el7 @epel-bacula7 z repozytorium
Maszyna wirtualna: CentOS 7 x86_64
Sieć lokalna: Gigabitowa
Vmtools
Bacula z MySQL utworzona tylko do backupu.

Plików do backupu ~ 2000000 różnej wielkości - nie mniej jednak są to pliki Office, pdf, sporadycznie zdjęcia itp. (raczej małe pliki).
Backup wykonuje się do pliku na dysk.

W pierwszej kolejności chciałem aby na jednej maszynie wirtualnej był director(z mysql) oraz storage. Klient to inny serwer w sieci lokalnej.
Efekt był taki że po 10 minutach od startu pełnego backupu na system Direcotor praktycznie nie można było się zalogować.
Prędkość wykonywania backupu w sieci lokalnej - gigabitowej fatalna:

Running Jobs:
JobId 1 Job ZeusJob.2016-06-23_08.19.40_03 is running.
Full Backup Job started: 23-cze-16 08:21
Files=920 Bytes=15,099,115,176 AveBytes/sec=5,331,608 LastBytes/sec=7,762,228 Errors=0
Bwlimit=0
Files: Examined=920 Backed up=920

Utworzyłem drugą maszynę wirtualną na tym samym hoście (Centos 7 - a na nim Director z Mysql) - rozdzieliłem Storage od Directora
Prędkości te same ! fatalne.

Zmieniłem silnik bazy danych na postgresa - niestety - prędkość jest taka sama.

Używam plików z dostarczonymi w paczkach domyślnymi plikami konfiguracyjnymi oczywiście delikatnie przeze mnie zmodyfikowanymi.
Kompresja jest wyłączona a w dyrektywie JOB dodana wartość SpoolAttributes = yes

wynik polecenia hdparm na storage:
[root@BArt453 ~]# hdparm -t /dev/mapper/viper-backup

/dev/mapper/bart-backup:
Timing buffered disk reads: 1878 MB in 3.00 seconds = 625.20 MB/sec

Sprawdziłem prędkości z klienta do storage:

iperf

Client connecting to 192.168.254.10, TCP port 9101
TCP window size: 19.3 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.254.240 port 32854 connected with 192.168.254.10 port 9101
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 2.0 sec 225 MBytes 943 Mbits/sec
[ 3] 2.0- 4.0 sec 223 MBytes 936 Mbits/sec
[ 3] 4.0- 6.0 sec 223 MBytes 936 Mbits/sec
[ 3] 6.0- 8.0 sec 222 MBytes 933 Mbits/sec
[ 3] 8.0-10.0 sec 224 MBytes 938 Mbits/sec
[ 3] 10.0-12.0 sec 223 MBytes 936 Mbits/sec
[ 3] 12.0-14.0 sec 223 MBytes 936 Mbits/sec
[ 3] 14.0-16.0 sec 224 MBytes 938 Mbits/sec
[ 3] 16.0-18.0 sec 223 MBytes 936 Mbits/sec
[ 3] 18.0-20.0 sec 224 MBytes 938 Mbits/sec
[ 3] 0.0-20.0 sec 2.18 GBytes 937 Mbits/sec


Testowo zostawiłem wykonywanie full backup który wykonywał się ~ 7 dni. Danych do backupowania ~6,6 TB.

Czy ktoś spotkał się z takim problemem ? Czy może wina leży po stronie wirtualki ? Chociaż transfery testowe na to nie wskazują.

Z góry dziękuję za odpowiedź.

Pozdrawiam
Re: Szybkość wykonywanego backupu na maszynie wirtualnej. 23 cze 2016 - 15:27:49

Send PM

Możliwości jest dużo. Poczynając od tego, że klient nie jest w stanie wygenerować odpowiedniego strumienia backupowego, a kończąc na tym że "buffered disk read" w hdparm to zazwyczaj ma zakończenie w RAM, a nie na dyskach fizycznych smiling smiley. Na początek wyłączył bym kompresję. To powinno zwiększyć ilość danych przesyłanych przez sieć ale nie powinno opóźniać ich wysyłki ze względu na czasochłonny proces kompresji. Po drodze będzie także kwestia tuningu bazy danych, buforów, itp.

--
Profesjonalne usługi Bacula: [www.bacula.com.pl]
Przykro nam, ale tylko zarejestrowane osoby mogą pisać na tym forum.

Kliknij żeby zalogować