Kumusta, nakatagpo ako kamakailan ng isang kawili-wiling problema: pag-set up ng storage para sa pag-back up ng malaking bilang ng mga block device.
Bawat linggo ay bina-backup namin ang lahat ng virtual machine sa aming cloud, kaya kailangan naming mapanatili ang libu-libong mga backup at gawin ito nang mabilis at mahusay hangga't maaari.
Sa kasamaang palad, karaniwang mga pagsasaayos RAID5, RAID6 sa kasong ito, hindi kami papayagang gawin ito, dahil ang proseso ng pagbawi sa mga malalaking disk na tulad namin ay magiging masakit na mahaba at malamang na hindi na magtatapos.
Tingnan natin kung anong mga alternatibo ang mayroon:
β Katulad ng RAID5, RAID6, ngunit may configurable parity level. Sa kasong ito, ang reserbasyon ay isinasagawa hindi block sa pamamagitan ng block, ngunit para sa bawat bagay nang hiwalay. Ang pinakamadaling paraan upang subukan ang erasure coding ay ang pagpapalawak .
ay isang kasalukuyang hindi inilabas na tampok na ZFS. Hindi tulad ng RAIDZ, ang DRAID ay may distributed parity block at, sa panahon ng pagbawi, ginagamit ang lahat ng mga disk ng array nang sabay-sabay, na ginagawang mas mahusay na makaligtas sa mga pagkabigo sa disk at makabawi nang mas mabilis pagkatapos ng pagkabigo.
Available ang server Fujitsu Primergy RX300 S7 may processor Intel Xeon CPU E5-2650L 0 @ 1.80GHz, siyam na stick ng RAM Samsung DDR3-1333 8Gb PC3L-10600R ECC Registered (M393B1K70DH0-YH9), istante ng disk Supermicro SuperChassis 847E26-RJBOD1, konektado sa pamamagitan ng Dual LSI SAS2X36 Expander at 45 disc Seagage ST6000NM0115-1YZ110 sa 6TB lahat.
Bago tayo magdesisyon ng anuman, kailangan muna nating suriin nang maayos ang lahat.
Upang gawin ito, naghanda at sinubukan ko ang iba't ibang mga pagsasaayos. Upang gawin ito, gumamit ako ng minio, na kumilos bilang isang backend ng S3 at inilunsad ito sa iba't ibang mga mode na may iba't ibang bilang ng mga target.
Karaniwan, ang minio case ay sinubukan sa erasure coding vs software raid na may parehong bilang ng mga disk at parity ng mga disk, at ito ay: RAID6, RAIDZ2 at DRAID2.
Para sa sanggunian: kapag naglunsad ka ng minio na may isang target lang, gumagana ang minio sa S3 gateway mode, na naghahatid ng iyong lokal na file system sa anyo ng S3 storage. Kung maglulunsad ka ng minio na tumutukoy sa ilang target, awtomatikong mag-o-on ang Erasure Coding mode, na magpapakalat ng data sa pagitan ng iyong mga target habang nagbibigay ng fault tolerance.
Bilang default, hinahati ng minio ang mga target sa mga grupo ng 16 na disk, na may 2 parity bawat grupo. Yung. Maaaring mabigo ang dalawang disk sa parehong oras nang hindi nawawala ang data.
Upang subukan ang pagganap, gumamit ako ng 16 na disk na 6TB bawat isa at nagsulat ng maliliit na bagay na 1MB ang laki sa mga ito, ito ang pinakatumpak na inilarawan ang aming hinaharap na pagkarga, dahil ang lahat ng mga modernong backup na tool ay naghahati ng data sa mga bloke ng ilang megabytes at isulat ang mga ito sa ganitong paraan.
Upang isagawa ang benchmark, ginamit namin ang s3bench utility, na inilunsad sa isang malayong server at nagpapadala ng libu-libong mga naturang bagay sa minio sa daan-daang mga thread. Pagkatapos noon ay sinubukan kong hilingin silang muli sa parehong paraan.
Ang mga resulta ng benchmark ay ipinapakita sa sumusunod na talahanayan:
Gaya ng nakikita natin, ang minio sa sarili nitong erasure coding mode ay gumaganap nang mas malala sa pagsulat kaysa sa minio na tumatakbo sa ibabaw ng software na RAID6, RAIDZ2 at DRAID2 sa parehong configuration.
Hiwalay ako subukan ang minio sa ext4 vs XFS. Nakakagulat, para sa aking uri ng workload, ang XFS ay naging mas mabagal kaysa sa ext4.
Sa unang batch ng mga pagsubok, nagpakita si Mdadm ng higit na kahusayan sa ZFS, ngunit nang maglaon na maaari mong pagbutihin ang pagganap ng ZFS sa pamamagitan ng pagtatakda ng mga sumusunod na opsyon:
xattr=sa atime=off recordsize=1Mat pagkatapos nito ang mga pagsubok sa ZFS ay naging mas mahusay.
Maaari mo ring tandaan na ang DRAID ay hindi nagbibigay ng maraming pakinabang sa pagganap sa RAIDZ, ngunit sa teorya ay dapat itong maging mas ligtas.
Sa huling dalawang pagsubok, sinubukan ko ring ilipat ang metadata (espesyal) at ZIL (log) sa salamin mula sa SSD. Ngunit ang pag-alis ng metadata ay hindi nagbigay ng maraming pakinabang sa bilis ng pag-record, at kapag inalis ang ZIL, my pindutin ang kisame na may 100% na paggamit, kaya itinuturing kong nabigo ang pagsubok na ito. Hindi ko ibinubukod na kung mayroon akong mas mabilis na SSD drive, kung gayon marahil ito ay maaaring lubos na mapabuti ang aking mga resulta, ngunit, sa kasamaang-palad, wala ako sa kanila.
Sa huli, nagpasya akong gumamit ng DRAID at sa kabila ng beta status nito, ito ang pinakamabilis at pinakamabisang solusyon sa storage sa aming kaso.
Gumawa ako ng isang simpleng DRAID2 sa isang pagsasaayos na may tatlong grupo at dalawang ipinamamahaging ekstra:
# zpool status data
pool: data
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
draid2:3g:2s-0 ONLINE 0 0 0
sdy ONLINE 0 0 0
sdam ONLINE 0 0 0
sdf ONLINE 0 0 0
sdau ONLINE 0 0 0
sdab ONLINE 0 0 0
sdo ONLINE 0 0 0
sdw ONLINE 0 0 0
sdak ONLINE 0 0 0
sdd ONLINE 0 0 0
sdas ONLINE 0 0 0
sdm ONLINE 0 0 0
sdu ONLINE 0 0 0
sdai ONLINE 0 0 0
sdaq ONLINE 0 0 0
sdk ONLINE 0 0 0
sds ONLINE 0 0 0
sdag ONLINE 0 0 0
sdi ONLINE 0 0 0
sdq ONLINE 0 0 0
sdae ONLINE 0 0 0
sdz ONLINE 0 0 0
sdan ONLINE 0 0 0
sdg ONLINE 0 0 0
sdac ONLINE 0 0 0
sdx ONLINE 0 0 0
sdal ONLINE 0 0 0
sde ONLINE 0 0 0
sdat ONLINE 0 0 0
sdaa ONLINE 0 0 0
sdn ONLINE 0 0 0
sdv ONLINE 0 0 0
sdaj ONLINE 0 0 0
sdc ONLINE 0 0 0
sdar ONLINE 0 0 0
sdl ONLINE 0 0 0
sdt ONLINE 0 0 0
sdah ONLINE 0 0 0
sdap ONLINE 0 0 0
sdj ONLINE 0 0 0
sdr ONLINE 0 0 0
sdaf ONLINE 0 0 0
sdao ONLINE 0 0 0
sdh ONLINE 0 0 0
sdp ONLINE 0 0 0
sdad ONLINE 0 0 0
spares
s0-draid2:3g:2s-0 AVAIL
s1-draid2:3g:2s-0 AVAIL
errors: No known data errorsOkay, inayos na natin ang storage, ngayon ay pag-usapan natin kung ano ang iba-back up natin. Dito gusto kong agad na pag-usapan ang tungkol sa tatlong solusyon na nagawa kong subukan, at ito ay:
- tinidor , isang espesyal na solusyon para sa pag-backup ng block device, ay may mahigpit na pagsasama sa Ceph. Maaaring kumuha ng mga pagkakaiba sa pagitan ng mga snapshot at bumuo ng incremental na backup mula sa mga ito. Sinusuportahan ang isang malaking bilang ng mga backend ng storage, kabilang ang parehong lokal at S3. Nangangailangan ng hiwalay na database upang maiimbak ang deduplication hash table. Mga disadvantages: nakasulat sa python, may bahagyang hindi tumutugon na cli.
- tinidor , isang matagal nang kilala at napatunayang backup tool, ay maaaring mag-backup ng data at ma-deduplicate ito nang maayos. Magagawang mag-save ng mga backup sa parehong lokal at sa isang malayong server sa pamamagitan ng scp. Maaari bang i-backup ang mga device kung ilulunsad kasama ang bandila --special, isa sa mga minus: kapag lumilikha ng isang backup, ang repositoryo ay ganap na naharang, kaya inirerekomenda na lumikha ng isang hiwalay na imbakan para sa bawat virtual machine, sa prinsipyo hindi ito isang problema, sa kabutihang palad ay napakadali nilang nilikha.
ay isang aktibong umuunlad na proyekto, nakasulat sa go, medyo mabilis at sumusuporta sa isang malaking bilang ng mga backend ng storage, kabilang ang lokal na storage, scp, S3 at marami pang iba. Hiwalay, nais kong tandaan na mayroong isang espesyal na nilikha para sa restic, na nagbibigay-daan sa iyong mabilis na mag-export ng storage para magamit nang malayuan. Sa lahat ng nasa itaas, ito ang pinakanagustuhan ko. Maaaring mag-backup mula sa stdin. Ito ay halos walang kapansin-pansin na mga disadvantages, ngunit mayroong ilang mga tampok:
-
Una, sinubukan kong gamitin ito sa pangkalahatang repository mode para sa lahat ng virtual machine (tulad ng Benji) at gumana rin ito nang maayos, ngunit ang pagpapanumbalik ng mga operasyon ay tumagal ng napakatagal, dahil... Sa bawat oras bago i-restore, sinusubukan ni restic na basahin ang metadata ng lahat ng backup. Ang problemang ito ay madaling nalutas, tulad ng sa borg, sa pamamagitan ng paglikha ng isang hiwalay na imbakan para sa bawat virtual machine. Ang diskarte na ito ay napatunayang napakaepektibo para sa pamamahala ng mga backup din. Ang mga hiwalay na repository ay maaaring magkaroon ng hiwalay na password para sa pag-access ng data, at hindi rin namin kailangang matakot na ang pandaigdigang repo ay maaaring masira kahit papaano. Maaari kang mag-spawn ng mga bagong repository nang kasingdali ng sa borg backup.
Sa anumang kaso, ang pag-deduplication ay isinasagawa lamang na may kaugnayan sa nakaraang bersyon ng backup; ang nakaraang backup ay tinutukoy ng landas para sa tinukoy na backup, kaya kung magba-back up ka ng iba't ibang mga bagay mula sa stdin patungo sa isang karaniwang imbakan, huwag kalimutang tukuyin ang opsyon
--stdin-filename, o tahasang tukuyin ang opsyon sa bawat pagkakataon--parent.
-
Pangalawa, ang pagbawi sa stdout ay tumatagal ng mas matagal kaysa sa pagbawi sa file system dahil sa parallel na kalikasan nito. Sa hinaharap, plano naming magdagdag ng mas malapit na suporta para sa mga backup para sa mga block device.
-
Pangatlo, kasalukuyang inirerekumenda na gamitin , dahil ang bersyon 0.9.6 ay may bug na may mahabang pagbawi ng malalaking file.
Upang subukan ang pagiging epektibo ng backup at ang bilis ng pagsulat / pagpapanumbalik mula sa isang backup, lumikha ako ng isang hiwalay na imbakan at sinubukang i-backup ang isang maliit na imahe ng isang virtual machine (21 GB). Dalawang pag-backup ang isinagawa nang hindi binabago ang orihinal, gamit ang bawat isa sa mga nakalistang solusyon upang suriin kung gaano kabilis/kabagal ang pagkopya ng na-deduplicate na data.
Tulad ng nakikita natin, ang Borg Backup ay may pinakamahusay na paunang ratio ng kahusayan sa pag-backup, ngunit mas mababa ito sa mga tuntunin ng parehong bilis ng pagsulat at pag-restore.
Ang Restic ay naging mas mabilis kaysa sa Benji Backup, ngunit mas matagal bago maibalik sa stdout, at, sa kasamaang-palad, hindi pa nito alam kung paano direktang sumulat sa isang block device.
Matapos timbangin ang lahat ng mga kalamangan at kahinaan, nagpasya akong tumira nagpahinga Ρ rest-server bilang ang pinaka-maginhawa at promising backup na solusyon.
Sa screencast na ito makikita mo kung paano ganap na ginagamit ang isang 10-gigabit na channel sa ilang mga backup na operasyon na sabay-sabay na tumatakbo. Ito ay nagkakahalaga ng noting na ang disk recycling ay hindi tumaas sa itaas 30%.
Mas nasiyahan ako sa natanggap kong solusyon!
Pinagmulan: www.habr.com