Hujambo, hivi majuzi nilipata shida ya kupendeza: kusanidi uhifadhi wa kuhifadhi idadi kubwa ya vifaa vya kuzuia.
Kila wiki tunahifadhi nakala za mashine zote pepe kwenye wingu letu, kwa hivyo tunahitaji kuwa na uwezo wa kudumisha maelfu ya nakala na kuifanya haraka na kwa ufanisi iwezekanavyo.
Kwa bahati mbaya, usanidi wa kawaida RAID5, RAID6 katika kesi hii, hatutaruhusiwa kufanya hivyo, kwa kuwa mchakato wa kurejesha kwenye diski kubwa kama zetu utakuwa mrefu sana na uwezekano mkubwa hautaisha.
Wacha tuangalie ni njia gani mbadala zilizopo:
- Sawa na RAID5, RAID6, lakini kwa kiwango cha usawa kinachoweza kusanidiwa. Katika kesi hii, uhifadhi unafanywa sio kizuizi kwa kuzuia, lakini kwa kila kitu tofauti. Njia rahisi ya kujaribu kufuta usimbaji ni kupanua .
ni kipengele cha ZFS ambacho hakijatolewa kwa sasa. Tofauti na RAIDZ, DRAID ina kizuizi cha usawa kilichosambazwa na, wakati wa kurejesha, hutumia diski zote za safu mara moja, ambayo inafanya kuwa bora zaidi kuishi kushindwa kwa disk na kurejesha kwa kasi baada ya kushindwa.
Seva inapatikana Fujitsu Primergy RX300 S7 na processor Intel Xeon CPU E5-2650L 0 @ 1.80GHz, vijiti tisa vya RAM Samsung DDR3-1333 8Gb PC3L-10600R ECC Imesajiliwa (M393B1K70DH0-YH9), rafu ya diski Supermicro SuperChassis 847E26-RJBOD1, iliyounganishwa kupitia Kipanuzi cha LSI SAS2X36 mbili na diski 45 Seagage ST6000NM0115-1YZ110 juu ya 6TB kila mtu.
Kabla ya kuamua chochote, tunahitaji kwanza kupima kila kitu vizuri.
Ili kufanya hivyo, nilitayarisha na kupima usanidi mbalimbali. Ili kufanya hivyo, nilitumia minio, ambayo ilifanya kazi kama sehemu ya nyuma ya S3 na kuizindua kwa njia tofauti na idadi tofauti ya malengo.
Kimsingi, kesi ya minio ilijaribiwa katika erasure coding vs programu uvamizi na idadi sawa ya disks na usawa wa disks, na hizi ni: RAID6, RAIDZ2 na DRAID2.
Kwa marejeleo: unapozindua minio ukiwa na lengo moja pekee, minio hufanya kazi katika hali ya lango la S3, ikitoa mfumo wako wa faili wa ndani kwa njia ya hifadhi ya S3. Ukizindua minio inayobainisha shabaha kadhaa, modi ya Usimbaji wa Kufuta itawashwa kiotomatiki, ambayo itasambaza data kati ya malengo yako huku ikitoa uvumilivu wa hitilafu.
Kwa chaguo-msingi, minio hugawanya malengo katika vikundi vya diski 16, na sehemu 2 kwa kila kikundi. Wale. Disks mbili zinaweza kushindwa kwa wakati mmoja bila kupoteza data.
Ili kupima utendaji, nilitumia diski 16 za 6TB kila mmoja na kuandika vitu vidogo vya 1MB kwa ukubwa juu yao, hii ilielezea kwa usahihi mzigo wetu wa baadaye, kwani zana zote za kisasa za kuhifadhi hugawanya data katika vitalu vya megabytes kadhaa na kuziandika kwa njia hii.
Ili kutekeleza alama, tulitumia matumizi ya s3bench, iliyozinduliwa kwenye seva ya mbali na kutuma makumi ya maelfu ya vitu kama hivyo kwa minio katika mamia ya nyuzi. Baada ya hapo nilijaribu kuwaomba warudi kwa njia ile ile.
Matokeo ya kipimo yanaonyeshwa kwenye jedwali lifuatalo:
Kama tunavyoona, minio katika hali yake ya usimbaji ya kufuta hufanya kazi mbaya zaidi katika uandishi kuliko minio inayoendesha juu ya programu RAID6, RAIDZ2 na DRAID2 katika usanidi sawa.
Tofauti mimi test minio kwenye ext4 vs XFS. Kwa kushangaza, kwa aina yangu ya mzigo wa kazi, XFS iligeuka kuwa polepole sana kuliko ext4.
Katika kundi la kwanza la majaribio, Mdadm alionyesha ubora zaidi ya ZFS, lakini baadaye kwamba unaweza kuboresha utendaji wa ZFS kwa kuweka chaguzi zifuatazo:
xattr=sa atime=off recordsize=1Mna baada ya hapo majaribio na ZFS yakawa bora zaidi.
Unaweza pia kutambua kwamba DRAID haitoi faida nyingi za utendaji zaidi ya RAIDZ, lakini kwa nadharia inapaswa kuwa salama zaidi.
Katika vipimo viwili vya mwisho, nilijaribu pia kuhamisha metadata (maalum) na ZIL (logi) kwenye kioo kutoka kwa SSD. Lakini kuondoa metadata hakutoa faida nyingi katika kasi ya kurekodi, na wakati wa kuondoa ZIL, yangu gonga dari na utumiaji wa 100%, kwa hivyo ninaona mtihani huu kama kutofaulu. Sijatenga kwamba ikiwa ningekuwa na anatoa za haraka za SSD, basi labda hii inaweza kuboresha matokeo yangu, lakini, kwa bahati mbaya, sikuwa nayo.
Mwishowe, niliamua kutumia DRAID na licha ya hali yake ya beta, ni suluhisho la uhifadhi wa haraka na bora zaidi katika kesi yetu.
Niliunda DRAID2 rahisi katika usanidi na vikundi vitatu na vipuri viwili vilivyosambazwa:
# 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 errorsSawa, tumepanga hifadhi, sasa hebu tuzungumze kuhusu kile tutakachohifadhi nakala. Hapa ningependa kuzungumza mara moja juu ya suluhisho tatu ambazo nilifanikiwa kujaribu, na hizi ni:
- uma , suluhisho maalum la kuhifadhi nakala ya kifaa cha kuzuia, ina muunganisho thabiti na Ceph. Inaweza kuchukua tofauti kati ya vijipicha na kuunda nakala rudufu kutoka kwao. Inasaidia idadi kubwa ya uhifadhi wa nyuma, ikiwa ni pamoja na ndani na S3. Inahitaji hifadhidata tofauti ili kuhifadhi jedwali la reli ya kurudisha nyuma. Hasara: iliyoandikwa katika python, ina cli kidogo isiyojibika.
- uma , zana ya kuhifadhi nakala inayojulikana kwa muda mrefu na iliyothibitishwa, inaweza kuhifadhi data na kuitoa vizuri. Inaweza kuhifadhi nakala za ndani na kwa seva ya mbali kupitia scp. Inaweza kuzuia nakala rudufu ya vifaa ikiwa imezinduliwa na bendera --special, moja ya minuses: wakati wa kuunda hifadhi, hifadhi imefungwa kabisa, kwa hiyo inashauriwa kuunda hifadhi tofauti kwa kila mashine ya virtual, kwa kanuni hii sio tatizo, kwa bahati nzuri huundwa kwa urahisi sana.
ni mradi unaoendelea kikamilifu, ulioandikwa kwa kwenda, haraka sana na inasaidia idadi kubwa ya uhifadhi wa nyuma, ikiwa ni pamoja na uhifadhi wa ndani, scp, S3 na mengi zaidi. Tofauti, ningependa kutambua kuwa kuna iliyoundwa maalum kwa restic, ambayo hukuruhusu kusafirisha haraka hifadhi kwa matumizi ya mbali. Kati ya yote hapo juu, niliipenda zaidi. Inaweza kuhifadhi nakala kutoka kwa stdin. Ina karibu hakuna hasara zinazoonekana, lakini kuna vipengele kadhaa:
-
Kwanza, nilijaribu kuitumia katika hali ya jumla ya kuhifadhi kwa mashine zote za kawaida (kama Benji) na hata ilifanya kazi vizuri, lakini shughuli za kurejesha zilichukua muda mrefu sana, kwa sababu ... Kila wakati kabla ya kurejesha, restic hujaribu kusoma metadata ya chelezo zote. Tatizo hili lilitatuliwa kwa urahisi, kama ilivyo kwa borg, kwa kuunda hifadhi tofauti kwa kila mashine ya kawaida. Mbinu hii imeonekana kuwa nzuri sana kwa kusimamia chelezo pia. Hifadhi tofauti zinaweza kuwa na nenosiri tofauti la kufikia data, na pia hatupaswi kuogopa kwamba repo ya kimataifa inaweza kwa namna fulani kuharibika. Unaweza kuibua hazina mpya kwa urahisi kama vile kwenye chelezo ya borg.
Kwa hali yoyote, uondoaji unafanywa tu kuhusiana na toleo la awali la chelezo; chelezo ya hapo awali imedhamiriwa na njia ya chelezo maalum, kwa hivyo ikiwa unahifadhi nakala za vitu tofauti kutoka kwa stdin hadi hazina ya kawaida, usisahau kutaja chaguo
--stdin-filename, au taja chaguo kwa uwazi kila wakati--parent.
-
Pili, urejeshaji kwa stdout huchukua muda mrefu zaidi kuliko urejeshaji kwa mfumo wa faili kutokana na asili yake sambamba. Katika siku zijazo, tunapanga kuongeza usaidizi wa karibu wa nakala rudufu za vifaa vya kuzuia.
-
Tatu, kwa sasa inashauriwa kutumia , kwa sababu toleo la 0.9.6 lina hitilafu yenye urejeshaji wa muda mrefu wa faili kubwa.
Ili kujaribu ufanisi wa chelezo na kasi ya kuandika / kurejesha kutoka kwa nakala rudufu, niliunda hazina tofauti na kujaribu kuweka nakala rudufu ya picha ndogo ya mashine ya kawaida (GB 21). Hifadhi rudufu mbili zilitekelezwa bila kubadilisha asili, kwa kutumia kila suluhu zilizoorodheshwa ili kuangalia jinsi data iliyotolewa ilinakiliwa haraka/polepole.
Kama tunavyoona, Borg Backup ina uwiano bora wa awali wa ufanisi wa chelezo, lakini ni duni kwa suala la kuandika na kurejesha kasi.
Restic iligeuka kuwa haraka kuliko Hifadhi Nakala ya Benji, lakini inachukua muda mrefu kurejesha stdout, na, kwa bahati mbaya, bado haijui jinsi ya kuandika moja kwa moja kwa kifaa cha kuzuia.
Baada ya kupima faida na hasara zote, niliamua kutulia utulivu Ρ mapumziko-seva kama suluhisho rahisi zaidi na la kuahidi la chelezo.
Katika onyesho hili la skrini unaweza kuona jinsi chaneli ya gigabit 10 inatumiwa kabisa wakati wa shughuli kadhaa za chelezo zinazoendeshwa kwa wakati mmoja. Ni muhimu kuzingatia kwamba kuchakata diski hakupanda zaidi ya 30%.
Nilifurahishwa zaidi na suluhisho nililopokea!
Chanzo: mapenzi.com