Štítky

, , , , , , , , , , , , , , , ,

Tento článek je určen těm, kteří si koupili alespoň VMware vSphere Essential Plus, a kteří tudíž mají možnost vDP v základní verzi používat.

Článek vychází ze zkušeností z asi tříměsíčního testování.

Jednoduchý závěr, který lze po otestování říct je: Máte-li dost peněz, kupte si Veeam (nebo něco podobného).

V případě, že nemáte dost peněz, nebo máte skoupého finančního ředitele, můžete využít vDP, která od verze vSphere 5.1 nahradila předchozí „integrované“ zálohování. Je k tomu ovšem potřeba notná dávka drzosti, štěstí a bláhové odvahy. Jako nezbytné se jeví neustálé modlitby k nějakému vhodně vybranému bohu. Pro účely práce s vDP do finále postoupili dva – Mictlantecuhtli, Aztécký to bůh podsvětí a smrti (nominován díky svému oboru) jen těsně následovaný Xochipillim, bohem lásky, kukuřice, květin a her (nominován díky tomu, že bude patrně věčně zhulený a nic ho nerozhází). Pokud se naučíte správně třikrát za sebou vyslovit jméno vybraného boha, jistě vám bude naslouchat. Možná se vám bude sice jen smát, ale naslouchat určitě bude, tomu věřte.

Pokud se ptáte proč, pak vězte, že zálohovat s vDP není tak snadné, jak se zdá.

Nenechte se zlákat marketingovými sliby typu „nainstalujete appliance, připojíte ji do vCentra a dál se už o nic nestaráte“, popřípadě „zálohujete celé servery, obnovujete až na úroveň souborů“ a tak, vězte, že marketing je marketing a do křemíku zabudované záludnosti jsou život.

Proč vDP použít:

  • Nu, když už jste si koupili tu nejlevnější verzi vSphere, která licenci obsahuje, tak je to zadarmo.
  • Pokud funguje, funguje dobře. Dokud nedojde k chybě.
  • V základní verzi sice umí jen zálohy celých strojů, ale pro skutečně nouzové obnovení v případě závažné havárie to bohatě postačí.
  • Umí pracovat se změnami na úrovni bloků jednotlivých virtuálních disků, takže zálohování i velkého serveru může trvat jen pár minut.
  • Umí slušně deduplikovat.
  • Umí replikovat zálohy.
  • Pro použití opravdu stačí stáhnout appliance, nakonfigurovat a spustit.
  • Webové rozhraní pro správu záloh a obnov je skutečně jednoduché.
  • I bez vCentra lze obnovit data ze zálohy.
  • S trochou umu lze appliance monitorovat z nějakého jiného systému, než je vCenter.

Proč vDP nepoužívat:

  • Zálohování nelze monitorovat jinak než značně nepřehlednou emailovou zprávou, nebo se trápit s vlastními skripty.
  • Na 3TB úložiště potřebuje 8GB RAM. Více na: https://www.vmware.com/support/vdr/doc/vdp_555_releasenotes.html
  • Appliance musí mít možnost připnout si disky ze serverů, které zálohuje. Nedáte ji jen tak někam. Na jednom ESXi může běžet jen jedna Appliance.
  • Pokud dojde k chybě, je oprava na dlouhé hodiny.
  • Až k chybě dojde, poznáte to jen pokud se podíváte na webové rozhraní vDP, nebo do emailu o zálohách (ale ten je třeba číst dost pozorně).
  • K chybě dojde určitě alespoň jednou za měsíc.
  • Chyba při záloze často ponechá na zálohovaném serveru fantomový snapshot.
  • Při nevhodném vypnutí/restartu můžete přijít o poslední zálohy. Ne, to není žert – tedy ne ode mne.
  • Start a vypnutí appliance trvá průměrně deset až třicet minut.
  • To zatracené webové rozhraní je jedinou cestou jak konfigurovat či monitorovat zálohy.
  • File-level restore se spouští z klientské stanice či serveru přes internetový prohlížeč a vyžaduje flash (nikdy jsem ho nevyzkoušel).
  • Ta věc je napsaná v javě.

K čemu se vDP nehodí a k čemu se hodí:

  • Rozhodně se nehodí jako primární zálohování:
    • Jde o dost nespolehlivé zálohování.
    • Na zálohování na úrovni aplikací zapomeňte, pokud si nekoupíte advanced edici (ale kdo by ji k něčemu takovému kupoval…). Minimálně je tedy třeba mít navíc vyřešené zálohy SQL, SPS, Exchange, AD a podobných drobností, kde je občas potřeba mít po ruce nějakou historii, nebo kde je třeba odmazávat logy (jako v Ex).
    • Pokud appliance selže, např. pokud se neukončí správně v důsledku výpadku proudu, po startu se vrátí na nejbližší rollback checkpoint, což může být den, dva zpět. V klidu tak přijdete o poslední zálohy.
  • Může se hodit jako doplňkové zálohování pro případ obnovy po havárii.
    • Máte po ruce vcelku aktuální zálohy kompletních virtuálních serverů.
    • Můžete obnovit zálohu i bez vCentra, přímo z webového rozhraní appliance – nic moc, ale potěší to.
    • Můžete například, pokud máte serverovnu spojenou se záložní lokalitou rychlou linkou, posadit appliance na nějaké pole přímo v záložní lokalitě; ovšem předpokládá to, že si zálohovací pole připnete přes iSCSI či NFS přímo do vCentra a jeho nodů.
    • Můžete mít appliance na lokálním poli a replikovat zálohy do vzdálené lokality, pokud nemáte rychlou a stabilní linku, nebo pokud je lokalita opravdu vzdálená, že k ní neprotáhnete optiku.
  • Rozhodně se hodí k trápení administrátorů.

Jak vDP ovládat:

Tedy, kromě již zmíněného, roztomile jednoduchého webového rozhraní, které je vážně dobré jen pro naklikání zálohy a obnovy, popřípadě pro přehled záloh. Pokud se připojíte na konzoli (či ssh sešnu) appliancky, máte po ruce jen pár opravdu použitelných příkazů:

  • status.dpn, který vypíše aktuální stav zálohování, tvorbu checkpointů a stav služeb.
  • cplist, který vypíše seznam aktuálních checkpointů. V přehledu je hned za položkou „valid/invalid“ k dispozici údaj „rol/—“ který udává, zda se lze k tomuto checkpointu vrátit v případě chybného vypnutí.
  • avmaint pro ovládání služeb zálohy. Co bude asi nejvíce třeba, je sekvence:
    • avmaint sched stop –ava, který vypne scheduler
    • avmaint checkpoint –ava, který spustí výrobu „malého“ checkpointu
    • avmaint hfscheck –ava –full, který spustí výrobu kompletního checkpointu
    • avmaint sched start –ava, který scheduler zase zapne.
  • get-log, který sice není integrovaný příkaz, ale stačí si ho založit:
    • echo tail -f /space/avamarclient/var-proxy-*/*$1* >/usr/sbin/get-log
      chmod 755 /usr/sbin/get-log
    • potom přes get-log <jobname> můžete sledovat aktuální log zálohování příslušného jobu, aniž byste hledali který log je který, páč je jich neúrekom.

Jak vDP monitorovat:

Protože možnost monitoringu záloh a zdraví appliancky je zatím na takřka nulové úrovni, musíte se buď spokojit s tím, že budete pravidelně koukat do vCentrového rozhraní, nebo se můžete potrápit s alespoň základním monitoringem pomocí nějakého příjemnějšího nástroje – např. Zabbixu.

Protože appliance je postavena na Suse serveru, lze si přidat příslušné repozitáře a nainstalovat klienta monitorovacího softu dle libosti. Pozor ovšem, ve výchozím nastavení firewall blokuje většinu příchozích i odchozích spojení, takže porty pro monitorovací soft je třeba povolit.
Pokud monitor poběží pod samostatným uživatelem, je třeba nastavit i sudo, které také není potřeba doinstalovávat.

Asi nejdůležitější položky k monitoringu jsou:

  • Monitoring stáří posledního „rol“ checkpointu:

    D=`sudo /usr/bin/cplist | grep rol | cut -d ‚ ‚ -f 2-6 | sort | tail -1`;

    B=`date -d „$D“ +%s`;A=`date +%s`;

    echo $((($A – $B)/3600))         = stáří posledního rollup checkpointu v hodinách

  • Monitoring, zda běží či neběží integrity check:

    sudo /usr/local/avamar/bin/status.dpn | grep „Currently running task“ | grep -c hfscheck

    = 1 pokud běží integrity check

Jak monitorovat a opravovat divné stavy serverů při nezdařené záloze:

vDP pracuje celkem zajímavě. Při záloze vyrobí dva snapshoty zálohovaného stroje, ze snapshotu 1 server běží, snapshot 2 je paralelní k prvnímu. Disky ze snapshotu 2 se připnou k vDP appliance a z nich se zálohuje. Stát se mohou dvě věci:

  • Snapshot 2 se po dokončení zálohy neodpojí z appliancky.
    • Detekce (PowerCLI, lze zavést do monitoringu):
      (Get-VM vDP0001).HardDisks | ?{$_.FileName -notlike „*vDP0001*“}
      = vrátí disky, které appliance vDP0001 nepatří (za předpokladu, že se disky appliancky jmenují podle ní, samozřejmě)
    • Opravu je třeba udělat ručně – odpojit zmíněné disky z appliancky a na serverech pak pustit konsolidaci.
      (get-vm $SERVER).ExtensionData.ConsolidateVMDisks_Task()
  • Snapshot 1 se po dokončení zálohy nesmaže.
    • Problém je, že snapshot 1 je fantomový, takže není vidět v seznamu snapshotů.
    • Detekce (PowerCLI, lze zavést do monitoringu):
      get-vm | ? {$_.HardDisks | ?{$_.FileName -like „*[0-9][0-9][0-9][0-9][0-9].vmdk“} } | ? {-not (Get-Snapshot -VM $_.name) }
      = vrátí virtuální servery, které mají fantomový snapshot.
    • Opravu lze udělat ručně spuštěním konsolidace. Popřípadě jednoduchým PowerCLI příkazem:
      get-vm | ? {$_.HardDisks | ?{$_.FileName -like „*[0-9][0-9][0-9][0-9][0-9].vmdk“} } | ? {-not (Get-Snapshot -VM $_.name) } | % {$x=$_; if (-not (Get-Task | ?{$_.name -like „ConsolidateVMDisks_Task“} | ?{$_.ObjectId -like $x.id })) { $x.ExtensionData.ConsolidateVMDisks_Task() } }
      který konsolidaci spustí za vás

Bohůmžel se může stát, že některý ze snapshotů bude zamčený, takže pak to znamená hledat, která potvora si drží zámek a bez nějakého restartu se to asi neobejde. http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003397

Užitečné tipy

  • Je to sice nepříjemné, ale omezte počet zálohovaných serverů v jedné úloze na nutné minimum. Je lepší mít více jobů s méně servery; job s více servery snáze zkolabuje.
  • Rozhodně omezte počet aktivních „proxy“ účtů; ve výchozím stavu je jich osm, doporučuji maximálně tři:
    vi /usr/local/avamarclient/etc/avagent-list

    file=3
    image=3
    proxy-1:
    proxy-2:
    proxy-3:
    #proxy-4:…

  • Naučte se vyslovovat jméno příslušného Aztéckého boha, modlete se a popřípadě mu postavte sochu…