VMware snapshot + szabad hely, Veeam

Virtualizáció

Sziasztok
 

Kis parázsvita alakult ki több kolléga között, nem vagyok maximálisan jártas a témában, szeretném kérni a szakik segítségét.

Adott egy VMware 6.5-ös 3 node-os cluster. A közös storage-ban az egyik VM 5TB-s diszkkel rendelkezik. Állítólag egy nagyon érzékeny sql jellegű förmedvény van benne, amit szeretnénk konzisztens lementeni tokkal vonóval, mielőtt átalakítjuk. Nem állhat a szolgáltatás fél napot, míg lehúzzuk az 5TB-t.

Az ötlet: snapshot  -> export egy felcsatolt NFS datastore-ra és utána nyúlunk csak hozzá.
Válasz: nem lehet snapshotolni, mert +5TB-t akar lefoglalni.
(XenServernél találkoztam ilyennel, ott is a teljes diszket még1x le akarta foglalni, szemben a sima linux lvm-nél megszokott 0bájt majd folyamatosan növekedő snapshot mérettel).
Felmerült, hogy a Veeam jó lehet ide. De utánaolvasva viszont úgy látom, hogy az is vmware storage snapshotra támaszkodik, tehát bukónak tűnik.

Kérdések:

A VMware snapshot tényleg mégegyszer lefoglalja a teljes diszket? Le lehet erről beszélni?
A Veeam ugyanerre a snapshotra épül vagy valamit jobban csinál?
Veeam nélkül hogy szoktak VMware alól menteni automatizálva mondjuk hetente?

Köszönöm!

  • 223 megtekintés

( VincentV | 2021. 02. 08., h – 17:54 )

Szerkesztve: 2021. 02. 08., h – 17:59

Mond nekik, hogy orbitális hülyeség, a snapshot akkora lesz, amennyi változás kerül bele, ha nem ír a diskre a vm a snapshot készítése után, akkor 0 lesz a snapshot mérete (oké, talán valami header van az elején, ezt nem tudom). Hogy mennyi idő alatt mekkorára hízik, azt a vm-en belüli os/app gazdája fogja tudni megmondani. Itt nyilván figyelni kell rá, hogy legyen annyi hely a datastore-on.

A Veeam ugyanezt használja, igen, mást nem tud.

Az impact az 5TiB-es szörnyre nézve annyi lehet, hogy majd a snapshot eldobásakor (a merge ideje alatt) jobban lesz terhelve a disk, ami miatt lassul a vm-en belüli disk i/o is.

( mac1125 | 2021. 02. 08., h – 18:04 )

Szia.

 

Normál snapshot 16 MB-al kezdődik, utána az eredeti diszk változásaival nő(tehát ha minden blokk megváltozik akkor tényleg a duplája lesz a teljes foglaltság).(link)

Egy jó összefoglaló a snapshotról: link

A legfontosabb ezzel kapcsolatban: a snapshot nem backup!
Persze lehetőséged van rá hogy a memóriát is lementsd, de az a VM részére stun-al jár, amit kérdés hogy hogyan visel a nagyon érzékeny sql.
Lehetőséged van arra is, hogy szólj a guestnek(ha van integrációd) hogy snapshot jön, csendesítse el magát, de ennek hatékonysága kérdéses.
Az sql förmedvényeknél sokszor előfordult már, hogy az adatbázisban az adatok rendben vannak, csak mégsem az van benne amit kellene(pl. az egyik táblára kiment a commit, a hozzá kapcsolódó tábla meg nem változott meg.(Az egy későbbi commit lett volna)

A Veeam Backup & Replication-ből elég kevesen használják ki a Replication részt, akár jó is lehet neked, de visszatértünk oda hogy milyen az az sql förmedvény. A Veeam sokféleképpen működhet, licensz és környezettől föggően. Van VMware snapshotoss része, lehet storage snapshotos része, agent alapú, de több sql-hez van integrációja is.

A legoptimálisabb az lenne, ha a förmedvényhez értő valaki tudna egy jó dumpot készíteni, ahol az adatbázisban tényleg minden rendben van, konzisztens.
Ha nincs ilyened akkor én le szoktam állítani a gépet, és úgy csinálok mentést, vagy snapshotot.  A mentés a jobban javasolt. Amennyiben mégis snapshotolsz akkor nagyon nagyon vigyázz a szabad helyre. Ha elfogy, akkor a géped megáll.
Főleg vicces tud lenni thick provisioning és snapshot kombó.

( debtamas88 | 2021. 02. 08., h – 19:13 )

Szia!

MS SQL?
Van saját beépített "Backup" megoldása, jobb mint az összes "kívűéről belenyúlúnk lementjük a diszket" megoldások - mert nem elég lementeni a diszket, az adatbázis nem lesz konzisztens.
Továbbá, be kell állítani a "full transaction log backup" -t, amire lehet építeni további differencia backup-ot.
pl.:  "full transaction log backup" naponta, és napközben 2 óránként egy diff. backup - ez már tervezés kérdése - visszaállítás is gyorsabban megy.

Az MS SQL server-be ezeket ütemezni lehet, ami kirakja fájlokba pl.: D:\ meghajtó diszkre - ezt kell menteni "kívűről belenyúlúnk lementjük a diszket" megoldással.

Ebben a témában én laikus vagyok, a kolléga így nyilatkozott:

TSQL by Microsoft, szóval egy nagy öt TB-s mdf az adatbázis
Lockolja a szerver a transact loggal együtt. A gép snapshotja nem sokat ér. Észreveszi és nem indul el.
Másodpercenként több száz, vagy akár ezer műveletet végez.

Az SQL kiváltására több törekvés is volt (MSSQL, PostgreSQL), de későn kaptak észbe, addigra mamuttá nőtte ki magát és így már nehéz kezelni.
Az első cél a konzisztens mentés, a másik, hogy offline megvizsgáljuk és próbáljunk valamit kezdeni vele, mert így nem fenttartható.

Kicsit kiegészítve ( nem tudtam szerkeszteni).

(MSSQL) A bekapcsolni "full transaction log backup" -t, amire lehet építeni további "differencia-backup" -t.
pl.:  "full transaction log backup" (napi 1x) és napközben 2 óránként egy differencia-backup - ez már tervezés kérdése - visszaállítás is gyors így (rollback).

Az MS SQL Server-be ezeket ütemezni lehet (JOB), ami kirakja fájlokba pl.: D:\ meghajtó diszkre - ezt kell menteni "kívűlről belenyúlúnk lementjük a diszket" megoldással - így a mentés is gyors lesz:

(Veeam)
Veeam esetében is kell egy "full-backup" (pl.: heti 1x ), amihez jön (napi 1x) egy Veeam "diff-backup" a VM- diszkről - így lesz gyors a mentés, és nem foglal sokat.

 

Két rétegben kell menteni.

A TSQL valamilyen adatbázis motor? Én úgy tudtam, a T-SQL a Microsoft SQL nyelv kiterjesztése.

Az MSSQL VSS alapú (mdf alapján ez is lehet az), így elcsendesített VM pillanatkép konzisztens. A Veeamnek külön VSS motorja is van.

Ha nem VSS alapú, akkor kézi elcsendesítéssel kell játszani: https://helpcenter.veeam.com/docs/backup/vsphere/backup_job_vss_scripts…

Én a replikációt javasolnám, mert akkor ott lesz indulásra készen egy állapot.

Másik opció tároló szinten készíteni egy pillanatképet (vm pillanatkép -> tároló pillanatkép -> vm pillanatkép törlése -> tároló pillanatkép becsatolása, ...)

TSQL by Microsoft, szóval egy nagy öt TB-s mdf az adatbázis

SharePoint ?

MS ezt olyan jól megtervezte, hogy minden fájlt/fájlverziót adatbázisban tárol, nem pedig fájlrendszeren, így gyorsan meghízik, ezért kell neki MS-SQL Standard és nem elég neki az MS-SQL Express.

Ha erre van valami "megoldás" ne hízzon ennyire - az engem is érdekelne :)

( debtamas88 | 2021. 02. 08., h – 19:55 )

A TSQL valamilyen adatbázis motor?

MS által implementált SQL-nyelv (Transact-SQL)