Дадзены артыкул напісана для таго, каб дапамагчы абраць для сябе падыходнае рашэнне і зразумець адрозненні паміж такімі SDS як Gluster, Ceph і Vstorage (Virtuozzo).
У тэксце выкарыстоўваюцца спасылкі на артыкулы з больш дэталёвым раскрыццём тых ці іншых праблем, таму апісанні будуць максімальна кароткімі з выкарыстаннем ключавых момантаў без лішняй вады і уступнай інфармацыі, якую вы зможаце пры жаданні самастойна здабыць на прасторах інтэрнэту.
Насамрэч вядома закранутыя тэмы патрабуюць тоны тэксту, але ў сучасным свеце ўсё больш і больш людзі не любяць шмат чытаць))), таму можна бегла прачытаць і зрабіць выбар, а калі што незразумела прайсціся па спасылках або трошкі незразумелыя словы))), а гэты артыкул як празрыстая абгортка для гэтых глыбокіх тэм, якая паказвае начынне - галоўныя ключавыя моманты кожнага рашэння.
Бляск
Пачнём з Gluster, які актыўна выкарыстоўваецца ў вытворцаў гіперканвергентных платформаў з SDS на базе open source для віртуальных асяроддзяў і яго можна знайсці на сайце RedHat у падзеле storage, дзе прапануецца абраць з двух варыянтаў SDS: Gluster ці Ceph.
Gluster складаецца з стэка транслятараў - службы якія выконваюць усе працы па размеркаванні файлаў і г.д. Brick - служба якая абслугоўвае адзін дыск, Volume - том (пул) - які аб'ядноўвае гэтыя brick'і. Далей ідзе служба размеркавання файлаў па групах за рахунак функцыі DHT(distributed hash table). Службу Sharding уключаць у апісанне не будзем бо ў ніжэй выкладзеных спасылках будзе апісанне праблем злучаных з ёй.
Пры запісе файл цалкам кладзецца ў brick і яго копія раўналежна пішацца на brick на другім серверы. Далей другі файл ужо будзе запісвацца ў другую групу з двух brisk(ці больш) на розных серверах.
Калі файлы прыкладна аднаго памеру і тым будзе складацца толькі з адной групы, тое ўсё нармальна, але вось пры іншых умовах узнікнуць з апісанняў наступныя праблемы:
- месца ў групах утылізуецца нераўнамерна, гэта залежыць ад памераў файлаў і калі ў групе недастаткова месца для запісу файла - вы атрымаеце памылку, файл не будзе запісаны і не будзе пераразмеркаваны ў іншую групу;
- пры запісе аднаго файла IO ідзе толькі на адну групу, астатнія прастойваюць;
- нельга атрымаць IO усяго тома пры запісе аднаго файла;
- і агульная канцэпцыя выглядае меней прадукцыйней за рахунак адсутнасці размеркавання дадзеных па блоках, дзе прасцей ажыццявіць балансаванне і вырашыць праблему раўнамернага размеркавання, а не як цяпер файл кладзецца ў брык цалкам.
З афіцыйнага апісання таксама мімаволі прыходзіць разуменне, што gluster працуе як файлавае сховішча па-над класічным апаратным RAID. Былі спробы распрацоўкі нарэзаць (Sharding) файлы на блокі, але ўвесь гэты дадатак, якое накладвае страты прадукцыйнасці да ўжо існага архітэктурнага падыходу, плюс выкарыстанне такіх вольна якія распаўсюджваюцца кампанентаў з абмежаваннем у прадукцыйнасці як Fuse. Няма сэрвісаў метададзеных, што абмяжоўвае па магчымасцях прадукцыйнасці і адмоваўстойлівасці сховішча пры размеркаванні файлаў на блокі. Больш за добрыя паказчыкі прадукцыйнасці можна назіраць пры канфігурацыі "Distributed Replicated" і колькасць нод павінна быць не менш за 6 для арганізацыі надзейнай рэплікі 3 з аптымальным размеркаваннем нагрузкі.
Гэтыя высновы таксама злучаны з апісаннем досведу выкарыстання і пры параўнанні з , а таксама ёсць апісанне вопыту да прыходу разумення гэтай больш прадукцыйнай і больш надзейнай канфігурацыі
У малюнку паказана размеркаванне нагрузкі пры запісе двух файлаў, дзе копіі першага файла раскладваюцца па трох першых серверах, якія аб'яднаны ў volume 0 групу і тры копіі другога файла кладуцца на другую групу volume1 з трох сервераў. Кожны сервер мае адну кружэлку.
Агульная выснова такі, што выкарыстоўваць можна Gluster, але з разуменнем таго, што ў прадукцыйнасці і адмоваўстойлівасці будуць абмежаванні, якія ствараюць цяжкасці пры пэўных умовах гіперканвергентнага рашэння, дзе рэсурсы патрэбныя яшчэ і для вылічальных нагрузак віртуальных асяроддзяў.
Ёсць некаторыя таксама паказчыкі прадукцыйнасці Gluster, якіх можна дамагчыся пры вызначаных умовах абмяжоўваючыся ў
Сеф
Цяпер разгледзім Сeph з апісанняў архітэктуры, якія мне ўдалося Таксама ёсць параўнанне паміж , дзе можна адразу зразумець што Ceph пажадана разгортваць на асобных серверах, бо яго сэрвісам неабходны ўсе рэсурсы жалеза пры нагрузках.
Архітэктура больш складана чым Gluster і ёсць такія сэрвісы як службы метададзеных, але ўвесь стэк кампанентаў даволі няпросты і не вельмі гнуткі для выкарыстання яго ў рашэнні з віртуалізацыяй. Дадзеныя ўкладваюцца па блоках, што выглядае больш прадукцыйным, але ёсць у іерархіі ўсіх службаў (кампанентаў), страты і latency пры пэўных нагрузках і аварыйных умовах у прыклад наступная
З апісання архітэктуры сэрцам выступае CRUSH, дзякуючы якому выбіраецца месца для размяшчэння даных. Далей ідзе PG - гэта найбольш складаная абстракцыя (лагічная група) для разумення. PG патрэбныя для таго, каб CRUSH быў больш эфэктыўным. Асноўнае прызначэнне PG - групоўка аб'ектаў для зніжэння рэсурс-спажывання, павышэння прадукцыйнасці і маштабаванасці. Адрасаванне аб'ектаў на прамую, па асобнасці, без аб'яднання іх у PG была б вельмі затратнай. OSD - гэта сэрвіс для кожнага асобнага дыска.
Кластар можа мець адзін ці шмат пулаў дадзеных рознага прызначэння і з рознымі наладамі. Пулы дзеляцца на плэйсмент-групы. У плэйсмент-групах захоўваюцца аб'екты, да якіх звяртаюцца кліенты. На гэтым лагічны ўзровень сканчаецца, і пачынаецца фізічны, таму як за кожнай плэйсмент-групай замацаваны адзін галоўны дыск і некалькі дыскаў-рэплік (колькі менавіта залежыць ад фактара рэплікацыі пула). Іншымі словамі, лагічным узроўні аб'ект захоўваецца ў канкрэтнай плэйсмент-групе, а на фізічным – на дысках, якія за ёй замацаваныя. Пры гэтым дыскі фізічна могуць знаходзіцца на розных вузлах ці нават у розных датацэнтрах.
У гэтай схеме плэйсмент-групы выглядаюць як неабходны ўзровень для гнуткасці ўсяго рашэння, але ў той жа час і як лішняе звяно ў гэтым ланцужку, што мімаволі наводзіць думкі аб страце прадукцыйнасці. Напрыклад пры запісе дадзеных сістэме неабходна разбіваць іх на гэтыя групы і потым фізічна на галоўны дыск і на дыскі для рэплік. Гэта значыць Хэш функцыя працуе пры пошуку і ўстаўцы аб'екта, але ёсць пабочны эфект - гэта вельмі вялікія выдаткі і абмежаванні на перабудову хэша (пры даданні, выдаленні дыска). Яшчэ адна праблема хэша - гэта выразна прыбітае размяшчэнне дадзеных, якія нельга мяняць. Гэта значыць калі неяк дыск адчувае падвышаную нагрузку, то сістэма не мае магчымасці не пісаць на яго (выбраўшы іншы дыск), хеш функцыя абавязвае размяшчаць дадзеныя па правіле, незалежна ад таго наколькі дыску дрэнна, таму Ceph есць шмат памяці пры перастраенні PG у выпадку self-healing або павелічэння сховішчы. Выснова, што Ceph працуе добра(хоць і павольна), але толькі калі няма маштабавання, аварыйных сітуацый і абнаўленні.
Ёсць вядома варыянты падвышэння прадукцыйнасці за рахунак кэшавання і кэш-тырынга, але пры гэтым неабходна добрае жалеза і ўсё роўна будуць страты. Але ў цэлым Ceph выглядае павабней чым Gluster для прадуктыва. Таксама пры выкарыстанні гэтых прадуктаў неабходна ўлічваць немалаважны фактар - гэта высокі ўзровень кампетэнцый, вопыту і прафесіяналізму з вялікім акцэнтам на linux, так як вельмі важна ўсё правільна разгарнуць, наладзіць і падтрымліваць, што накладвае яшчэ больш адказнасці і нагрузкі на адміністратара.
Vstorage
Яшчэ цікавей выглядае архітэктура ў , якую можна выкарыстоўваць сумесна з гіпервізарам на тых жа вузлах, на тым жа , Але вельмі важна правільна ўсё сканфігураваць, каб дабіцца добрай прадукцыйнасці. Гэта значыць разгарнуўшы такі прадукт са скрынкі на які патрапіла канфігурацыі без уліку рэкамендацый у адпаведнасці з архітэктурай будзе вельмі лёгка, але не прадукцыйна.
Што ж можа суіснаваць для захоўвання побач з сэрвісамі гіпервізара kvm-qemu, а гэта ўсяго толькі некалькі службаў, дзе знойдзена кампактная аптымальная іерархія кампанентаў: сэрвіс кліента які мантуецца праз FUSE(мадыфікаваны, не open source), служба метададзеных MDS (Metadata service), служба блокаў дадзеных Chunk service, якая фізічна роўная аднаму дыску і на гэтым усё. Па хуткасці вядома аптымальна выкарыстоўваць адмоваўстойлівую схему ў дзве рэплікі, але калі задзейнічаць кэшаванне і часопісы на дыскі SSD, то помехоустойчивое кадаваньне (erase coding або raid6) можна прыстойна разагнаць на гібрыднай схеме ці нават лепш на all flash. З EC(erase coding) некаторы мінус: пры змене аднаго блока дадзеных неабходна пералічыць сумы цотнасці. Для абыходу страт на гэтую аперацыю Сeph піша ў EC адкладзена і праблемы з прадукцыйнасцю могуць адбыцца пры вызначаным запыце, калі напрыклад спатрэбяцца лічыць усе блокі, а ў выпадку з Virtuozzo Storage запіс змененых блокаў ажыццяўляецца выкарыстоўваючы падыход "log-structured file system", што мінімізуе выдаткі на вылічэнні цотнасці. Каб прыкінуць прыблізна варыянты з паскарэннем працы пры EC і без, ёсць - лічбы можна атрымаць прыблізныя залежыць ад каэфіцыента дакладнасці вытворцы абсталявання, але вынік вылічэнняў добра дапамагае запланаваць канфігурацыю.
Простая схема кампанентаў захоўвання гэта не значыць, што гэтыя кампаненты не паглынаюць але калі падлічыць усе выдаткі загадзя, то можна разлічваць на сумесную працу побач з гіпервізарам.
Ёсць схема параўнання спажывання рэсурсаў жалеза службамі Сeph і Virtuozzo storage.
Калі раней параўноўваць Gluster і Ceph можна было па старых артыкулах, выкарыстоўваючы найважнейшыя радкі з іх, то з Virtuozzo складаней. Артыкулаў па гэтым прадукце не так шмат і інфармацыю можна чэрпаць толькі з дакументацыі на ці на рускай калі разглядаць Vstorage у якасці сховішчы выкарыстоўванага ў некаторых гиперконвергентных рашэннях у такіх кампаніях як і Акроніс.
Паспрабую дапамагчы з апісаннем гэтай архітэктуры таму тэксту будзе крыху больш, але каб самому разабрацца ў дакументацыі неабходна шмат часу, а наяўную дакументацыю можна выкарыстоўваць толькі як даведнік з дапамогай перагляду зместа або пошук па ключавым слове.
Разгледзім працэс запісу ў гібрыднай канфігурацыі жалеза з вышэй апісанымі кампанентамі: запіс пачынае ісці на той вузел з якога яе ініцыяваў кліент (служба кропкі мантавання FUSE), але кампанент майстар службы метададзеных (MDS) вядома накіруе кліента на прамую да патрэбнага чанк сэрвісу (службе захоўвання блокаў CS), гэта значыць MDS не ўдзельнічае падчас запісаў, а проста накіроўвае на неабходны чанк сэрвіс. Увогуле можна прывесці аналогію запісу з разлівам вады па бочках. Кожная бочка, гэта блок даных у 256МБ.
Гэта значыць адзін дыск, гэта нейкая колькасць такіх бочак, гэта значыць аб'ём дыска падзяліць на 256МБ. Кожная копія разліваецца на адзін вузел, другая амаль паралельна ўжо на іншы вузел і г.д… Калі ў нас тры рэплікі і ёсць SSD дыскі, для кэша (пад чытанне і часопісы запісы), то пацверджанне запісу будзе адбывацца пасля запісу часопіса ў SSD, а раўналежны скід з SSD, будзе працягвацца на HDD, як бы ў фонавым рэжыме. У выпадку трох рэплік коміт запісу будзе пасля пацверджання ад SSD трэцяга вузла. Можа здацца, што суму хуткасці запісу трох SSD можна падзяліць на тры і мы атрымаем хуткасць запісу адной рэплікі, але запіс дзід ідзе раўналежна і хуткасць Latency сеткі звычайна вышэй, чым у SSD, і ў сутнасці прадукцыйнасць запісу будзе залежаць ад сеткі. У сувязі з гэтым, каб убачыць рэальныя IOPS неабходна правільна нагрузіць увесь Vstorage па , гэта значыць тэсціраваць рэальную нагрузку, а не памяць і кэш, дзе неабходна ўлічыць правільны памер блока дадзеных, колькасць патокаў і г.д.
Вышэй згаданы часопіс запісу на SSD, працуе так, што як толькі ў яго пападаюць дадзеныя, то адразу счытваюцца службай і пішуцца на HDD. Службаў метададзеных (MDS) некалькі на кластар і іх колькасць вызначаецца кворумам, які працуе па алгарытме Paxos. З пункта гледжання кліента кропка мантавання FUSE, гэта тэчка кластарнага сховішчы, якая адначасова бачная ўсім нодам кластара, кожная нода мае змантаванага кліента па такім прынцыпе таму кожнаму вузлу даступна гэтае сховішча.
Для прадукцыйнасці любога з вышэй апісанага падыходу вельмі важна, на этапе планавання і разгортванні, правільна наладзіць сетку, дзе будзе балансіроўка за кошт агрэгацыі і правільна падабраная прапускная здольнасць сеткавага канала. У агрэгацыі важна правільна падабраць рэжым хэшавання і памеры фрэймаў. Ёсць таксама вельмі моцнае адрозненне ад вышэй апісаных SDS, гэта fuse з тэхналогіяй fast path у Virtuozzo Storage. Які па міма мадэрнізаванага fuse у адрозненне ад астатніх open source рашэнняў, значна дадае IOPS-ов і дазваляе не абмяжоўвацца гарызантальным ці вертыкальным маштабаваннем. Увогуле ў параўнанні з вышэй апісанымі архітэктурамі гэтая выглядае больш магутны, але за такое задавальненне вядома ж неабходна купляць ліцэнзіі ў адрозненні ад Сeph і Gluster.
Падводзячы вынікі можна падкрэсліць топам з трох: першае месца па прадукцыйнасці і надзейнасці архітэктуры займае Virtuozzo Storage, другое Ceph і трэцяе Gluster.
Крытэрыі, па якім абраны Virtuozzo Storage: гэта аптымальны набор кампанентаў архітэктуры, мадэрнізаваны пад гэты падыход Fuse з fast path, гнуткі набор канфігурацыі жалеза, меншае спажыванне рэсурсаў і магчымасць сумеснага выкарыстання з compute(вылічэннямі/віртуалізацыі), гэта значыць цалкам падыходзіць для гіперканвергентнага рашэння , у складзе якога ён і ідзе. Другое месца Ceph, таму што гэта больш прадукцыйная архітэктура перад Gluster, за рахунак аперыравання блокамі, а таксама больш гнуткімі сцэнарамі і магчымасцю працы ў больш маштабных кластарах.
У планах ёсць жаданне напісаць параўнанне паміж vSAN, Space Direct Storage, Vstorage і Nutanix Storage, тэсціраванне Vstorage на абсталяванні HPE, Huawei, а таксама сцэнары інтэграцыі Vstorage са знешнімі апаратнымі СХД, таму калі артыкул вам спадабаўся, то нядрэнна было б атрымаць ад вас водгукі. , якія маглі б узмацніць матывацыю на новыя артыкулы з улікам вашых заўваг і пажаданняў.
Крыніца: habr.com