All work and no play makes Maciej a dull boy – ghettoVCB
Wieczór spędzałem nad lampką wyśmienitego tokajskiego wina. Błogość całej sytuacji podkreślała delikatnie szemrząca trąbka Terenca Blancharda ospale snująca się z głośników. Nie pozostawało nic innego, jak tylko to sakramentalnie spieprzyć…
Mam jedno takie biuro w terenie. Zajmują się obróbką czegoś, o czym nie mam zielonego pojęcia, w coś czego nie rozumiem, a znajduje się w… Piekle. Bo jak nazwać miejsce, do którego z najbliższego lotniska jedzie się 8h pociągiem, i tylko pociągiem bo drogi są zbyt często zasypane przez lawiny. Zimno, ciemno, brzydkie kobiety, obleśne jedzenie i kwaśne piwo. Jedyną wspólną cechą ich siedziby z hotelem Overlook z Lśnienia jest położenie, wszystko inne to kompletne przeciwieństwo. Barak na skale z serwerami w środku.
… i postanowiłem skonfigurować im kopie zapasowe. Otworzyłem portal i wpadłem w mroki konsoli.
Aby nie odwiedzać tego rozkosznego kompleksu turystycznego przy morzu Barentsa musiałem się skupić na wykorzystaniu już istniejącej tam infrastruktury. Po raz pierwszy chyba, nie w mrokach, a w przytulnym, ciepłym zakątku serwerowni…. na zapiecku, można by rzec, odnalazłem nie wykorzystywany już serwer. Poprosiłem o zainstalowanie na nim Ubuntu 12.04.1 LTS, na którym uruchomiłem demona NFS odpowiedzialnego za serwowanie miejsca na backupy dla rezydującego w tym uroczym zakątku ESX’a:
apt-get install nfs-common
apt-get install nfs-kernel-server
Następnie skonfigurowałem moje nowe zwierzątko. Konfiguracja była ekstremalnie prosta gdyż po pierwsze mieszkający tam zombie nie kombinują za dużo, a po drugie NFS znajdował się w innym VLAN’ie. Dokonałem tego poprzez edycję pliku /etc/default/nfs-kernel-server:
RPCNFSDCOUNT=8
RPCNFSDPRIORITY=0
RPCMOUNTDOPTS=–manage-gids
NEED_SVCGSSD=no
RPCSVCGSSDOPTS=
RPCNFSDOPTS=
NEED_IDMAPD=yes
NEED_GSSD=no
Oraz pliku /etc/idmapd.conf:
[General]
Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
[Translation]
Method = nsswitch
Dorzuciłem również który folder chcę udostępniać po NFS, poprzez dodanie w pliku /etc/exports następującej linii:
/backup 192.168.77.0/24(rw,fsid=0,insecure,no_subtree_check,async)
Po wszystkich tych operacjach zrestartowałem demona NFS za pomocą poniższej komendy, aby wszelkie zmiany weszły w życie.
/etc/init.d/nfs-kernel-server restart
Podłączenie do ESX to była już czysta przyjemność:
Nie pozostało nic więcej jak ściągnąć i rozpakować ghettoVCB. Oprogramowanie ,nie tylko z nazwy, nadaje się idealnie do tego typu działań. Jest za darmo i robi pełne kopie zapasowe VM. Skrpty jest darmowy, bez gwarancji, tak więc używamy go na własną odpowiedzialność… Nieprawdaż, że nie wyobrażacie sobie lepszego miejsca na zastosowanie go w produkcji, niż oddalone o setki kilometrów lodowe pustkowie?
Polecam ściągnąć i rozpakować go na serwerze docelowym i umieścić na zasobie NFS. A wywoływać go później z ESX’a poprzez crond… ale o tym za chwilę. Na początku edytujemy konfigurację samego ghettoVCB w pliku ghettoVCB.conf:
VM_BACKUP_VOLUME=/vmfs/volumes/backup/
DISK_BACKUP_FORMAT =thin
VM_BACKUP_ROTATION_COUNT=7
POWER_VM_DOWN_BEFORE_BACKUP=0
ENABLE_HARD_POWER_OFF=0
ITER_TO_WAIT_SHUTDOWN=3
POWER_DOWN_TIMEOUT=5
ENABLE_COMPRESSION=0
VM_SNAPSHOT_MEMORY=0
VM_SNAPSHOT_QUIESCE=0
ENABLE_NON_PERSISTENT_NFS=0
UNMOUNT_NFS=0
SNAPSHOT_TIMEOUT=15
EMAIL_LOG=0
EMAIL_DEBUG=0
Ten szereg parametrów oznacza, że nasze kopie będą się robić na /vmfs/volumes/backup/ (VM_BACKUP_VOLUME), format dysku będzie thin (DISK_BACKUP_FORMAT), będziemy zostawiali siedem ostatnich backupów (VM_BACKUP_ROTATION_COUNT), nie będziemy wyłączać VM przed zrobieniem kopii (POWER_VM_DOWN_BEFORE_BACKUP) nie włączamy kompresji (ENABLE_COMPRESSION), nie odłączamy NFS po wykonaniu kopii (UNMOUNT_NFS) i nie wysyłamy maili (EMAIL_LOG).
Następnie należało stworzyć plik vms_to_backup w którym powinna znaleźć się lista maszyn które chcemy backupować, czyli np.:
APP1
APP2
DB1
DC1
Następnie pozostaje nam skonfigurowanie crona. Potrzebny nam plik znajduje się w /var/spool/cron/crontabs/root, dorzucamy do niego jedną linijkę:
0 4 * * * /vmfs/volumes/backup/ghettoVCB-master/ghettoVCB.sh -f /vmfs/volumes/backup/ghettoVCB-master/vms_to_backup -g /vmfs/volumes/ backup /ghettoVCB-master/ghettoVCB.conf > /dev/null
Następnie, aby załadować nowy corntab musimy zrestartować demona. W 5.X robi się to następująco:
/bin/kill $(cat /var/run/crond.pid)
/bin/busybox crond
Po tym, o 4 rano, codziennie będzie uruchamiany ghettoVCB z konfiguracją z ghettoVCB.conf na VM z listy vms_to_backup. Więcej informacji o ghettoVCB znajdziecie na stronie http://communities.vmware.com/docs/DOC-8760. Oprogramowanie polecam, działa bardzo dobrze, a odzyskiwanie jest równie sprawne jak backup.
świetny opis, dodałbym jedynie – zawartość linijki z crona – wrzucić do osobnego pliku .sh i jego odpalać
Opis super. Zrobiłem backup wg niego wszystko ładnie pięknie ale jak dodam wiecej niż 1 maszynę do pliku vms_to_backup to dostaję info następującej tresci 2013-07-22 21:34:28 — info: ERROR: failed to locate and extract VM_ID for Mysql itd dla innych maszyn tak samo.
Jesli w pliku jest tylko ta jedna maszyna wszystko ładnie hula. Proszę o jakieś sugestie. Dodam tylko ze plik edytowany vi wiec nie ma śmieci wewnątrz pliku.