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.

About the author

Bloger i niezależny konsultant z wieloletnim doświadczeniem w branży IT. Specjalizujący się w wirtualizacji i cloud computingu. Posiada tytuły MCP, MCTS, VCP oraz VMware vExpert.
2 Responses
  1. 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.

Leave a Reply