Бұл мақала өзіңіз үшін дұрыс шешімді таңдауға және Gluster, Ceph және Vstorage (Virtuozzo) сияқты SDS арасындағы айырмашылықтарды түсінуге көмектесу үшін жазылған.
Мәтін белгілі бір проблемаларды егжей-тегжейлі ашатын мақалаларға сілтемелерді пайдаланады, сондықтан сипаттамалар қажетсіз түксіз негізгі тармақтарды және қаласаңыз, Интернеттен өз бетіңізше алуға болатын кіріспе ақпаратты пайдалана отырып, мүмкіндігінше қысқа болады.
Шындығында, әрине, көтерілген тақырыптар мәтіннің реңктерін талап етеді, бірақ қазіргі әлемде көп оқуды ұнатпайтындар көбейіп кетті))), сондықтан сіз тез оқып, таңдау жасай аласыз, егер бірдеңе болса анық емес, сілтемелерді орындаңыз немесе Google түсініксіз сөздер))), және бұл мақала толтыруды көрсететін осы терең тақырыптар үшін мөлдір қаптама сияқты - әрбір шешімнің негізгі түйінді нүктелері.
Жылтыр
Gluster-тен бастайық, оны виртуалды орталарға арналған ашық бастапқы код негізінде SDS бар гиперконвергентті платформаларды өндірушілер белсенді түрде пайдаланады және RedHat веб-сайтында сақтау бөлімінде табуға болады, онда екі SDS опциясын таңдауға болады: Gluster немесе Ceph.
Gluster трансляторлар стекінен тұрады – файлдарды таратудың барлық жұмысын орындайтын қызметтер және т.б. Brick - бұл бір дискіге қызмет көрсететін қызмет, Volume - бұл кірпіштерді біріктіретін көлем (пул). Содан кейін DHT (таратылған хэш кестесі) функциясын пайдаланып файлдарды топтарға тарату қызметі келеді. Біз Sharding қызметін сипаттамаға қоспаймыз, өйткені төмендегі сілтемелер онымен байланысты мәселелерді сипаттайды.
Жазу кезінде бүкіл файл кірпіште сақталады және оның көшірмесі бір уақытта екінші серверде кірпішке жазылады. Әрі қарай, екінші файл әртүрлі серверлерде екі кірпіштен (немесе одан да көп) екінші топқа жазылады.
Егер файлдардың өлшемі шамамен бірдей болса және көлемі тек бір топтан тұрса, онда бәрі жақсы, бірақ басқа жағдайларда сипаттамалардан келесі мәселелер туындайды:
- топтардағы бос орын біркелкі емес пайдаланылады, бұл файлдардың өлшеміне байланысты және топта файл жазу үшін орын жеткіліксіз болса, сіз қате аласыз, файл жазылмайды және басқа топқа қайта таратылмайды ;
- бір файлды жазу кезінде IO тек бір топқа өтеді, қалғандары бос;
- бір файлды жазу кезінде бүкіл томның IO-ны ала алмайсыз;
- және жалпы концепция деректерді блоктарға бөлудің болмауына байланысты өнімділігі төмен болып көрінеді, мұнда біркелкі тарату мәселесін теңестіру және шешу оңайырақ, ал қазір бүкіл файл блокқа кірмейді.
Ресми сипаттамадан біз сондай-ақ gluster классикалық RAID аппараттық құралының үстінде файлдарды сақтау ретінде жұмыс істейтінін еріксіз түсінеміз. Файлдарды блоктарға кесуге (бөлшектеу) әзірлеу әрекеттері болды, бірақ мұның бәрі бұрыннан бар сәулеттік тәсілге өнімділік жоғалтуына әкелетін қосымша, сонымен қатар Fuse сияқты өнімділік шектеулері бар еркін таратылатын компоненттерді пайдалану. Файлдарды блоктарға тарату кезінде жадтың өнімділігі мен ақауларға төзімділік мүмкіндіктерін шектейтін метадеректер қызметтері жоқ. Жақсырақ өнімділік көрсеткіштерін «Таратылған репликацияланған» конфигурациясымен байқауға болады және жүктемені оңтайлы бөлумен сенімді көшірме 6 ұйымдастыру үшін түйіндер саны кемінде 3 болуы керек.
Бұл тұжырымдар пайдаланушы тәжірибесінің сипаттамасымен де байланысты және салыстырғанда , сонымен қатар осы өнімдірек және сенімдірек конфигурацияны түсінуге әкелетін тәжірибенің сипаттамасы бар
Суретте екі файлды жазу кезінде жүктеменің таралуы көрсетілген, мұнда бірінші файлдың көшірмелері 0 том тобына біріктірілген алғашқы үш серверге таратылады, ал екінші файлдың үш данасы үш томның 1-ші томына екінші файлдың үш данасы орналастырылады. серверлер. Әрбір серверде бір диск бар.
Жалпы қорытынды: Gluster-ді қолдануға болады, бірақ өнімділік пен ақауларға төзімділікте шектеулер болатынын түсініп, гиперконвергиялық шешімнің белгілі бір жағдайында қиындықтар туғызады, мұнда ресурстар виртуалды орталардың есептеу жүктемелері үшін де қажет.
Сондай-ақ белгілі бір жағдайларда қол жеткізуге болатын Gluster өнімділік көрсеткіштері бар
Кеф
Енді мен жасай алған архитектуралық сипаттамалардан Цефті қарастырайық арасында салыстыру да бар , мұнда сіз Ceph-ті бөлек серверлерде орналастыру орынды екенін бірден түсіне аласыз, өйткені оның қызметтері жүктелген кезде барлық аппараттық ресурстарды қажет етеді.
сәулет Gluster-ге қарағанда күрделірек және метадеректер қызметтері сияқты қызметтер бар, бірақ құрамдастардың бүкіл стегі айтарлықтай күрделі және оны виртуалдандыру шешімінде пайдалану үшін өте икемді емес. Деректер блоктарда сақталады, олар өнімдірек көрінеді, бірақ барлық қызметтердің (компоненттер) иерархиясында белгілі бір жүктемелер мен төтенше жағдайлар кезінде жоғалтулар мен кешігулер болады, мысалы:
Архитектураның сипаттамасынан жүрек CRUSH болып табылады, соның арқасында деректерді сақтау орны таңдалады. Одан кейін PG келеді - бұл түсіну үшін ең қиын абстракция (логикалық топ). CRUSH тиімдірек ету үшін PG қажет. PG негізгі мақсаты ресурстарды тұтынуды азайту, өнімділікті және масштабтауды арттыру үшін объектілерді топтау болып табылады. Нысандарды PG-ге біріктірмей, тікелей, жеке-жеке адрестеу өте қымбатқа түседі. OSD - бұл әрбір жеке дискіге арналған қызмет.
Кластерде әртүрлі мақсаттарға және әртүрлі параметрлерге арналған бір немесе бірнеше деректер пулдары болуы мүмкін. Бассейндер орналастыру топтарына бөлінеді. Орналастыру топтары клиенттер қатынасатын нысандарды сақтайды. Бұл жерде логикалық деңгей аяқталады және физикалық деңгей басталады, себебі әрбір орналастыру тобына бір негізгі диск және бірнеше реплика дискілері тағайындалады (нақты саны пулдың репликация факторына байланысты). Басқаша айтқанда, логикалық деңгейде объект белгілі бір орналастыру тобында, ал физикалық деңгейде – оған бекітілген дискілерде сақталады. Бұл жағдайда дискілер физикалық түрде әртүрлі түйіндерде немесе тіпті әртүрлі деректер орталықтарында орналасуы мүмкін.
Бұл схемада орналастыру топтары бүкіл шешімнің икемділігі үшін қажетті деңгей сияқты көрінеді, бірақ сонымен бірге өнімділіктің жоғалуын еріксіз түрде болжайтын осы тізбектің қосымша буыны ретінде. Мысалы, деректерді жазу кезінде жүйе оны осы топтарға, содан кейін физикалық деңгейде негізгі дискіге және репликаларға арналған дискілерге бөлуі керек. Яғни, Хэш функциясы объектіні іздеу және кірістіру кезінде жұмыс істейді, бірақ жанама әсері бар - бұл хэшті қайта құруға (дискіні қосу немесе жою кезінде) өте жоғары шығындар мен шектеулер. Басқа хэш мәселесі - бұл өзгертуге болмайтын деректердің анық бекітілген орны. Яғни, егер қандай да бір түрде диск жоғары жүктемеде болса, жүйенің оған жазбау мүмкіндігі жоқ (басқа дискіні таңдау арқылы), хэш функциясы деректерді қаншалықты нашар болса да ережеге сәйкес орналастыруды міндеттейді. диск, сондықтан өзін-өзі сауықтыру немесе сақтауды ұлғайту жағдайында PG қайта құру кезінде Ceph көп жадты жейді. Қорытынды: Ceph жақсы жұмыс істейді (баяу болса да), бірақ масштабтау, төтенше жағдайлар немесе жаңартулар болмаған кезде ғана.
Әрине, кэштеу және кэшті бөлісу арқылы өнімділікті арттыру нұсқалары бар, бірақ бұл жақсы жабдықты қажет етеді және әлі де шығындар болады. Бірақ тұтастай алғанда, Цеф өнімділік үшін Глустерге қарағанда тартымды көрінеді. Сондай-ақ, осы өнімдерді пайдаланған кезде маңызды факторды ескеру қажет - бұл Linux жүйесіне үлкен назар аудара отырып, құзыреттің, тәжірибенің және кәсібиліктің жоғары деңгейі, өйткені барлығын дұрыс орналастыру, конфигурациялау және қолдау өте маңызды, бұл әкімшіге одан да көп жауапкершілік пен ауыртпалық жүктейді.
Сақтау орны
Архитектура одан да қызықты көрінеді , ол бірдей түйіндерде, сол жерде гипервизормен бірге қолданылуы мүмкін , бірақ жақсы өнімділікке жету үшін барлығын дұрыс конфигурациялау өте маңызды. Яғни, мұндай өнімді қораптан кез келген конфигурацияда архитектураға сәйкес ұсыныстарды ескермей орналастыру өте оңай, бірақ өнімді емес.
Kvm-qemu гипервизоры қызметтерінің жанында сақтау үшін не болуы мүмкін және бұл компоненттердің ықшам оңтайлы иерархиясы табылған бірнеше қызметтер ғана: FUSE арқылы орнатылған клиенттік қызмет (өзгертілген, ашық емес), MDS метадеректер қызметі (Метадеректер қызметі), физикалық деңгейде бір дискіге тең болатын Chunk сервисінің деректер блоктары қызметі. Жылдамдық тұрғысынан, әрине, екі репликасы бар ақауларға төзімді схеманы пайдалану оңтайлы, бірақ SSD дискілерінде кэштеу мен журналдарды пайдалансаңыз, қателерге төзімді кодтауды (кодтауды өшіру немесе raid6) компьютерде лайықты түрде үдетуге болады. гибридті схема немесе барлық жарқылда одан да жақсырақ. EC (кодтауды өшіру) кейбір кемшілігі бар: бір деректер блогын өзгерткен кезде паритет мөлшерлерін қайта есептеу қажет. Осы операциямен байланысты шығындарды айналып өту үшін, Ceph EC-ге кейінге қалдырылған түрде жазады және өнімділік мәселелері белгілі бір сұрау кезінде туындауы мүмкін, мысалы, барлық блоктарды оқу қажет болғанда және Virtuozzo Storage жағдайында өзгертілген блоктарды жазу жүзеге асырылады. паритеттерді есептеу шығындарын барынша азайтатын «лог-құрылымдық файлдық жүйе» тәсілін қолдану. Шамамен бағалау үшін ЭК-мен және онсыз жұмысты жеделдету нұсқалары бар – сандар жабдықты өндірушінің дәлдік коэффициентіне байланысты шамамен болуы мүмкін, бірақ есептеулердің нәтижесі конфигурацияны жоспарлауға жақсы көмектеседі.
Сақтау компоненттерінің қарапайым диаграммасы бұл компоненттер сіңірілмейді дегенді білдірмейді бірақ егер сіз барлық шығындарды алдын ала есептесеңіз, гипервизордың жанында ынтымақтастыққа сене аласыз.
Ceph және Virtuozzo сақтау қызметтерімен аппараттық ресурстарды тұтынуды салыстыру схемасы бар.
Егер бұрын Gluster және Ceph ескі мақалаларды пайдаланып, олардың ең маңызды жолдарын пайдалана отырып салыстыру мүмкін болса, Virtuozzo-мен бұл қиынырақ. Бұл өнім туралы мақалалар көп емес және ақпаратты тек құжаттамадан алуға болады немесе орыс тілінде Vstorage-ті кейбір компаниялардағы гиперконвергиялық шешімдерде қолданылатын қойма ретінде қарастырсақ және Acronis.
Мен осы архитектураның сипаттамасына көмектесуге тырысамын, сондықтан мәтін аздап көп болады, бірақ құжаттаманы өзіңіз түсіну үшін көп уақыт қажет, ал бар құжаттаманы кестені қайта қарау арқылы ғана анықтама ретінде пайдалануға болады. мазмұны немесе кілт сөз бойынша іздеу.
Жоғарыда сипатталған компоненттері бар гибридті аппараттық конфигурацияда жазу процесін қарастырайық: жазба клиент оны бастаған түйінге (FUSE орнату нүктесі қызметі) өте бастайды, бірақ метадеректер қызметі (MDS) негізгі компоненті, әрине, клиентті тікелей қалаған chunk қызметіне (сақтау қызметі CS блоктары) бағыттаңыз, яғни MDS жазу процесіне қатыспайды, жай ғана қызметті қажетті бөлікке бағыттайды. Жалпы, бөшкелерге су құйып жазуға ұқсастық беруге болады. Әрбір баррель 256 МБ деректер блогы болып табылады.
Яғни, бір дискі - мұндай бөшкелердің белгілі бір саны, яғни дискінің көлемі 256 МБ-қа бөлінген. Әрбір көшірме бір түйінге, екіншісі дерлік басқа түйінге параллель және т.б. таралады... Егер бізде үш көшірме болса және кэшке арналған SSD дискілері болса (журналдарды оқу және жазу үшін), онда жазуды растау жазудан кейін орын алады. журналды SSD-ге, ал SSD-ден параллельді қалпына келтіру HDD-де фондық режимдегідей жалғасады. Үш реплика жағдайында жазба үшінші түйіннің SSD растауынан кейін жасалады. Үш SSD дискісінің жазу жылдамдығының қосындысын үшке бөлуге болатын сияқты көрінуі мүмкін және біз бір көшірменің жазу жылдамдығын аламыз, бірақ көшірмелер параллель жазылады және желілік кідіріс жылдамдығы әдетте SSD жылдамдығынан жоғары, және шын мәнінде жазу өнімділігі желіге байланысты болады. Осыған байланысты, нақты IOPS көру үшін сіз бүкіл Vstorage файлын дұрыс жүктеуіңіз керек , яғни жад пен кэшті емес, нақты жүктемені сынау, мұнда деректер блогының дұрыс өлшемін, ағындар санын және т.б. ескеру қажет.
SSD-дегі жоғарыда аталған жазу журналы деректер енген бойда қызмет оны бірден оқып, HDD-ге жазатындай жұмыс істейді. Бір кластерге бірнеше метадеректер қызметтері (MDS) бар және олардың саны Paxos алгоритміне сәйкес жұмыс істейтін кворуммен анықталады. Клиенттің көзқарасы бойынша FUSE орнату нүктесі кластердегі барлық түйіндерге бір уақытта көрінетін кластерді сақтау қалтасы болып табылады, әрбір түйінде осы принцип бойынша бекітілген клиент бар, сондықтан бұл сақтау орны әрбір түйін үшін қолжетімді.
Жоғарыда сипатталған тәсілдердің кез келгенін орындау үшін жоспарлау және орналастыру кезеңінде желіні дұрыс конфигурациялау өте маңызды, мұнда біріктіру және дұрыс таңдалған желі арнасының өткізу қабілеті арқасында теңгерімдеу болады. Агрегацияда дұрыс хэштеу режимін және кадр өлшемдерін таңдау маңызды. Жоғарыда сипатталған SDS-тен өте күшті айырмашылық бар, бұл Virtuozzo Storage жүйесіндегі жылдам жол технологиясымен сақтандырғыш. Бұл модернизацияланған сақтандырғышқа қосымша, басқа ашық бастапқы шешімдерден айырмашылығы, IOPS-ті айтарлықтай арттырады және көлденең немесе тік масштабтаумен шектелмеуге мүмкіндік береді. Жалпы, жоғарыда сипатталған архитектуралармен салыстырғанда, бұл әлдеқайда күшті көрінеді, бірақ мұндай ләззат алу үшін, әрине, Ceph және Gluster сияқты лицензияларды сатып алу керек.
Қорытындылай келе, үштіктің жоғарғы жағын бөліп көрсетуге болады: Virtuozzo Storage архитектураның өнімділігі мен сенімділігі бойынша бірінші орынды, Ceph екінші орынды, ал Gluster үшінші орынды алады.
Virtuozzo Storage таңдалған критерийлер: бұл жылдам жолы, аппараттық конфигурациялардың икемді жиынтығы, ресурстарды аз тұтыну және есептеулермен бөлісу мүмкіндігі (есептеу/виртуализация) бар осы Fuse тәсілі үшін жаңартылған архитектуралық құрамдастардың оңтайлы жиынтығы, яғни ол бөлігі болып табылатын гиперконвергентті шешім үшін толығымен жарамды. Екінші орын - Ceph, өйткені ол блоктарда жұмыс істеуіне, сондай-ақ икемді сценарийлерге және үлкен кластерлерде жұмыс істеу мүмкіндігіне байланысты Gluster-пен салыстырғанда өнімдірек архитектура.
vSAN, Space Direct Storage, Vstorage және Nutanix Storage, HPE және Huawei жабдықтарында Vstorage сынағы, сондай-ақ Vstorage-ті сыртқы аппараттық сақтау жүйелерімен біріктіру сценарийлері арасында салыстыруды жазу жоспарлары бар, сондықтан мақала ұнаса, ол Сізден пікір алғаныма қуаныштымын, бұл сіздің пікірлеріңіз бен тілектеріңізді ескере отырып, жаңа мақалаларға мотивацияны арттыра алады.
Ақпарат көзі: www.habr.com