Сәлеметсіз бе, мен жақында қызықты мәселеге тап болдым: блоктық құрылғылардың көп санын сақтық көшірмелеу үшін жадты орнату.
Апта сайын біз бұлттағы барлық виртуалды машиналардың сақтық көшірмесін жасаймыз, сондықтан мыңдаған сақтық көшірмелерді сақтап, оны мүмкіндігінше тез және тиімді орындауымыз керек.
Өкінішке орай, стандартты конфигурациялар RAID5, RAID6 бұл жағдайда бізге мұны істеуге рұқсат берілмейді, өйткені біздікі сияқты үлкен дискілердегі қалпына келтіру процесі өте ұзақ болады және ешқашан аяқталмайды.
Қандай балама нұсқалар бар екенін қарастырайық:
— RAID5, RAID6 сияқты, бірақ теңшелетін теңдік деңгейі бар. Бұл жағдайда брондау блок бойынша емес, әрбір нысан бойынша бөлек орындалады. Өшіру кодтауын көрудің ең оңай жолы - кеңейту .
қазіргі уақытта шығарылмаған ZFS мүмкіндігі. RAIDZ-тен айырмашылығы, DRAID-де бөлінген теңдік блогы бар және қалпына келтіру кезінде массивтің барлық дискілерін бірден пайдаланады, бұл дискінің ақауларынан аман қалуға және сәтсіздіктен кейін тезірек қалпына келтіруге мүмкіндік береді.
Сервер қолжетімді Fujitsu Primergy RX300 S7 процессормен Intel Xeon CPU E5-2650L 0 @ 1.80 ГГц, тоғыз жедел жады Samsung DDR3-1333 8 Гб PC3L-10600R ECC тіркелген (M393B1K70DH0-YH9), диск сөресі Supermicro SuperChassis 847E26-RJBOD1, арқылы қосылған Қос LSI SAS2X36 кеңейткіш және 45 диск Seagage ST6000NM0115-1YZ110 туралы 6TB барлығы.
Біз бірдеңе шешпес бұрын, алдымен бәрін дұрыс сынап көруіміз керек.
Ол үшін мен әртүрлі конфигурацияларды дайындап, сынақтан өткіздім. Мұны істеу үшін мен S3 сервері ретінде әрекет ететін және оны әртүрлі нысандар санымен әртүрлі режимдерде іске қосқан minio-ны қолдандым.
Негізінен, минио корпусы дискілердің бірдей санымен және дискілер паритетімен бағдарламалық рейдке қарсы өшіру кодтауында сыналған және олар: RAID6, RAIDZ2 және DRAID2.
Анықтама үшін: minio бағдарламасын тек бір мақсатпен іске қосқан кезде, minio S3 шлюз режимінде жұмыс істейді, жергілікті файлдық жүйені S3 жады түрінде жеткізеді. Бірнеше мақсатты көрсете отырып, minio іске қоссаңыз, өшіру кодтау режимі автоматты түрде қосылады, ол қателерге төзімділікті қамтамасыз ете отырып, деректерді мақсаттарыңыз арасында таратады.
Әдепкі бойынша, minio мақсаттарды әр топқа 16 паритетпен 2 дискіден тұратын топтарға бөледі. Анау. Екі диск бір уақытта деректерді жоғалтпай істен шығуы мүмкін.
Өнімділікті тексеру үшін мен әрқайсысы 16 ТБ болатын 6 дискіні қолдандым және оларға өлшемі 1 МБ шағын нысандарды жаздым, бұл біздің болашақ жүктемемізді дәл сипаттады, өйткені барлық заманауи сақтық көшірме құралдары деректерді бірнеше мегабайттық блоктарға бөліп, оларды осылай жазады.
Эталонды жүргізу үшін біз қашықтағы серверде іске қосылған s3bench утилитасын қолдандық және жүздеген ағындардағы minio-ға он мыңдаған осындай нысандарды жібердік. Содан кейін мен оларды дәл осылай қайтаруға тырыстым.
Эталондық нәтижелер келесі кестеде көрсетілген:
Көріп отырғанымыздай, жеке өшіру кодтау режиміндегі minio бірдей конфигурацияда RAID6, RAIDZ2 және DRAID2 бағдарламалық жасақтамасының үстінде жұмыс істейтін minio бағдарламасына қарағанда жазуда айтарлықтай нашар жұмыс істейді.
Мені бөлек ext4 және XFS жүйесінде минионы сынау. Бір қызығы, менің жұмыс жүктемесінің түрі үшін XFS ext4-ке қарағанда айтарлықтай баяу болды.
Сынақтардың бірінші партиясында Mdadm ZFS-тен артықшылығын көрсетті, бірақ кейінірек келесі опцияларды орнату арқылы ZFS өнімділігін жақсартуға болады:
xattr=sa atime=off recordsize=1Mсодан кейін ZFS тестілері әлдеқайда жақсарды.
Сондай-ақ, DRAID RAIDZ-ге қарағанда өнімділікті арттыруды қамтамасыз етпейтінін атап өтуге болады, бірақ теориялық тұрғыдан ол әлдеқайда қауіпсіз болуы керек.
Соңғы екі сынақта мен метадеректерді (арнайы) және ZIL (журнал) айнаға SSD-ден тасымалдауға тырыстым. Бірақ метадеректерді жою жазу жылдамдығына көп пайда әкелмеді, ал ZIL жою кезінде менің 100% пайдалану арқылы төбеге жетті, сондықтан мен бұл сынақты сәтсіз деп санаймын. Менде жылдамырақ SSD дискілері болса, бұл менің нәтижелерімді айтарлықтай жақсартуы мүмкін екенін жоққа шығармаймын, бірақ, өкінішке орай, менде олар болмады.
Ақыр соңында, мен DRAID пайдалануды шештім және оның бета күйіне қарамастан, бұл біздің жағдайда ең жылдам және тиімді сақтау шешімі.
Мен қарапайым DRAID2 конфигурациясын үш топпен және екі бөлінген қосалқы бөлшектермен жасадым:
# 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 errorsЖарайды, біз жадты сұрыптадық, енді сақтық көшірмесін жасайтын нәрселер туралы сөйлесейік. Мұнда мен бірден сынап көрген үш шешім туралы айтқым келеді, олар:
- шанышқы , блок құрылғысының сақтық көшірмесін жасауға арналған мамандандырылған шешім Ceph-пен тығыз интеграцияға ие. Суреттер арасындағы айырмашылықтарды алып, олардан қосымша сақтық көшірме жасай алады. Жергілікті және S3 сияқты көптеген жад серверлерін қолдайды. Депликация хэш кестесін сақтау үшін бөлек дерекқорды қажет етеді. Кемшіліктері: питон тілінде жазылған, сәл жауапсыз cli бар.
- шанышқы , бұрыннан белгілі және дәлелденген сақтық көшірме құралы деректердің сақтық көшірмесін жасай алады және оларды жақсы қайталайды. Сақтық көшірмелерді жергілікті түрде де, scp арқылы қашықтағы серверге де сақтай алады. Жалаушамен іске қосылған болса, құрылғылардың сақтық көшірмесін блоктай алады --special, минустардың бірі: сақтық көшірме жасау кезінде репозиторий толығымен бұғатталған, сондықтан әрбір виртуалды машина үшін жеке репозиторий жасау ұсынылады, негізінен бұл проблема емес, бақытымызға орай, олар өте оңай жасалады.
белсенді дамып келе жатқан жоба, go режимінде жазылған, өте жылдам және жергілікті сақтауды, scp, S3 және т.б. қоса алғанда, көптеген сақтау серверлерін қолдайды. Арнайы құрылғанын бөлек атап өткім келеді қашықтан пайдалану үшін жадты жылдам экспорттауға мүмкіндік беретін restic үшін. Жоғарыда айтылғандардың ішінде маған бәрінен де ұнады. stdin-ден сақтық көшірме жасай алады. Оның айтарлықтай кемшіліктері жоқ, бірақ бірнеше ерекшеліктері бар:
-
Біріншіден, мен оны барлық виртуалды машиналар (Бенджи сияқты) үшін жалпы репозиторий режимінде қолдануға тырыстым және ол тіпті жақсы жұмыс істеді, бірақ қалпына келтіру операциялары өте ұзақ уақытқа созылды, өйткені... Қалпына келтірмес бұрын рестик барлық сақтық көшірмелердің метадеректерін оқуға тырысады. Бұл мәселе борг сияқты, әрбір виртуалды машина үшін жеке репозиторий жасау арқылы оңай шешілді. Бұл тәсіл сақтық көшірмелерді басқару үшін де өте тиімді болып шықты. Бөлек репозиторийлерде деректерге қол жеткізу үшін бөлек құпия сөз болуы мүмкін, сонымен қатар жаһандық репо қандай да бір түрде бұзылуы мүмкін деп қорқудың қажеті жоқ. Сіз жаңа репозиторийлерді борг сақтық көшірмесіндегі сияқты оңай жасай аласыз.
Қалай болғанда да, көшірме көшірменің алдыңғы нұсқасына қатысты ғана орындалады; алдыңғы сақтық көшірме көрсетілген сақтық көшірмеге арналған жолмен анықталады, сондықтан stdin-ден жалпы репозиторийге әртүрлі нысандардың сақтық көшірмесін жасасаңыз, келесіні көрсетуді ұмытпаңыз опция
--stdin-filename, немесе опцияны әр жолы анық көрсетіңіз--parent.
-
Екіншіден, stdout-ты қалпына келтіру файлдық жүйені қалпына келтіруге қарағанда, параллель сипатына байланысты әлдеқайда ұзағырақ уақыт алады. Болашақта біз блоктық құрылғылардың сақтық көшірмесін жасау үшін жақынырақ қолдауды қосуды жоспарлап отырмыз.
-
Үшіншіден, қазіргі уақытта оны пайдалану ұсынылады , өйткені 0.9.6 нұсқасында үлкен файлдарды ұзақ қалпына келтіру қатесі бар.
Сақтық көшірменің тиімділігін және сақтық көшірмеден жазу/қалпына келтіру жылдамдығын тексеру үшін мен жеке репозиторий жасап, виртуалды машинаның (21 ГБ) шағын кескінінің сақтық көшірмесін жасауға тырыстым. Түпнұсқаны өзгертпестен екі сақтық көшірме жасалды, қайталанатын деректердің қаншалықты жылдам/баяу көшірілгенін тексеру үшін аталған шешімдердің әрқайсысы қолданылды.
Көріп отырғанымыздай, Borg Backup ең жақсы бастапқы сақтық көшірме тиімділік коэффициентіне ие, бірақ жазу және қалпына келтіру жылдамдығы жағынан төмен.
Restic Бенджи резервтік көшірмеге қарағанда жылдамырақ болды, бірақ stdout-қа қалпына келтіру үшін ұзағырақ уақыт қажет және, өкінішке орай, ол блок құрылғысына тікелей жазуды әлі білмейді.
Барлық артықшылықтар мен кемшіліктерді өлшеп болғаннан кейін мен шешуге шешім қабылдадым демалыс с демалыс сервері ең қолайлы және перспективалы резервтік шешім ретінде.
Бұл скриншотта сіз бір уақытта орындалатын бірнеше сақтық көшірме операциялары кезінде 10 гигабиттік арнаның қалай толығымен пайдаланылғанын көре аласыз. Айта кету керек, дискіні қайта өңдеу 30% -дан аспайды.
Мен алған шешімге риза болдым!
Ақпарат көзі: www.habr.com