Кратка споредба на SDS архитектурата или наоѓање на вистинската платформа за складирање (GlusterVsCephVsVirtuozzoStorage)

Оваа статија е напишана за да ви помогне да го изберете вистинското решение за себе и да ги разберете разликите помеѓу SDS како што се Gluster, Ceph и Vstorage (Virtuozzo).

Текстот користи линкови до написи со подетално откривање на одредени проблеми, така што описите ќе бидат што е можно пократки, користејќи клучни точки без непотребни флуктуации и воведни информации што можете, доколку сакате, самостојно да ги добиете на Интернет.

Всушност, се разбира, покренатите теми бараат тонови на текстот, но во современиот свет сè повеќе луѓе не сакаат да читаат многу))), така што можете брзо да читате и да направите избор, а ако нешто е не е јасно, следете ги врските или прогуглајте нејасни зборови))), и овој напис е како проѕирна обвивка за овие длабоки теми, покажувајќи го пополнувањето - главните клучни точки на секоја одлука.

Гластер

Да почнеме со Gluster, кој активно го користат производителите на хиперконвергирани платформи со SDS базирани на отворен код за виртуелни средини и може да се најде на веб-страницата RedHat во делот за складирање, каде што можете да изберете од две SDS опции: Gluster или Ceph.

Gluster се состои од куп преведувачи - услуги кои ја вршат целата работа на дистрибуција на датотеки итн. Brick е услуга која сервисира еден диск, Volume е волумен (базен) што ги обединува овие цигли. Следува услугата за дистрибуција на датотеки во групи користејќи ја функцијата DHT (дистрибуирана хеш табела). Ние нема да ја вклучиме услугата Sharding во описот бидејќи врските подолу ќе ги опишат проблемите поврзани со неа.

При пишување, целата датотека се чува во тула и нејзината копија истовремено се запишува во тула на вториот сервер. Следно, втората датотека ќе биде напишана во втората група од две тули (или повеќе) на различни сервери.

Ако датотеките се приближно со иста големина и волуменот се состои од само една група, тогаш сè е во ред, но под други услови следниве проблеми ќе произлезат од описите:

• просторот во групи се користи нерамномерно, зависи од големината на датотеките и ако нема доволно простор во групата за да напишете датотека, ќе добиете грешка, датотеката нема да биде напишана и нема да биде редистрибуирана во друга група ;
• кога пишувате една датотека, IO оди само во една група, останатите се неактивен;
• не можете да добиете IO од целиот волумен кога пишувате една датотека;
• и генералниот концепт изгледа помалку продуктивен поради недостатокот на дистрибуција на податоци во блокови, каде што е полесно да се балансира и реши проблемот со униформа дистрибуција, а не како сега целата датотека оди во блок.

Од официјалниот опис архитектура ние, исто така, неволно сфаќаме дека gluster работи како складирање датотеки на врвот на класичниот хардверски RAID. Имаше обиди за развој да се исечат (Sharding) датотеките во блокови, но сето ова е додаток кој наметнува загуби во перформансите на веќе постоечкиот архитектонски пристап, плус употребата на такви слободно дистрибуирани компоненти со ограничувања на перформансите како што е Fuse. Нема услуги за метаподатоци, што ги ограничува перформансите и можностите за толеранција на грешки на складиштето при дистрибуција на датотеки во блокови. Показателите за подобри перформанси може да се забележат со конфигурацијата „Дистрибуирано реплицирано“ и бројот на јазли треба да биде најмалку 6 за да се организира сигурна реплика 3 со оптимална распределба на оптоварување.

Овие наоди се поврзани и со описот на корисничкото искуство Гластер и кога ќе се спореди со Цеф, а има и опис на искуството што води до разбирање на оваа попродуктивна и посигурна конфигурација „Реплицирано дистрибуирано“.


Сликата ја прикажува дистрибуцијата на оптоварување при пишување две датотеки, каде копии од првата датотека се дистрибуираат низ првите три сервери, кои се комбинираат во групата том 0, а три копии од втората датотека се ставаат на втората група том 1 од три сервери. Секој сервер има еден диск.

Општ заклучок е дека можете да го користите Gluster, но со разбирање дека ќе има ограничувања во перформансите и толеранцијата на грешки што создаваат потешкотии под одредени услови на хиперконвергирани решенија, каде што се потребни ресурси и за пресметковните оптоварувања на виртуелните средини.

Исто така, постојат некои индикатори за изведба на Gluster што може да се постигнат под одредени услови, ограничени на толеранција на грешки.

Цеф

Сега да го погледнеме Ceph од описите на архитектурата што можев да ги направам најдете. Постои и споредба помеѓу Глустерфс и Кеф, каде што можете веднаш да разберете дека е препорачливо да се распореди Ceph на посебни сервери, бидејќи неговите услуги бараат сите хардверски ресурси под оптоварување.

архитектура Цеф покомплексен од Gluster и има услуги како што се услугите за метаподатоци, но целиот куп компоненти е прилично сложен и не е многу флексибилен за користење во решение за виртуелизација. Податоците се складираат во блокови, што изгледа попродуктивно, но во хиерархијата на сите услуги (компоненти), има загуби и латентност при одредени оптоварувања и итни услови, на пример следново статија.

Од описот на архитектурата, срцето е CRUSH, благодарение на што се избира локацијата за складирање на податоци. Следува PG - ова е најтешката апстракција (логичка група) за разбирање. PG се потребни за да се направи CRUSH поефективен. Главната цел на PG е да групира објекти за да ја намали потрошувачката на ресурси, да ги зголеми перформансите и приспособливоста. Адресирањето на објектите директно, поединечно, без нивно комбинирање во ПГ би било многу скапо. OSD е услуга за секој поединечен диск.

Кластерот може да има еден или повеќе базени на податоци за различни цели и со различни поставки. Базените се поделени во групи за сместување. Групите за поставување складираат објекти до кои клиентите пристапуваат. Овде завршува логичкото ниво, а започнува физичкото ниво, бидејќи на секоја група за поставување ѝ е доделен еден главен диск и неколку дискови со реплики (колку точно зависат од факторот за репликација на базенот). Со други зборови, на логичко ниво објектот се чува во одредена група за поставување, а на физичко ниво - на дисковите што му се доделени. Во овој случај, дисковите може физички да се лоцираат на различни јазли или дури и во различни центри за податоци.

Во оваа шема, групите за поставување изгледаат како неопходно ниво за флексибилност на целото решение, но во исто време, како дополнителна алка во овој синџир, што неволно сугерира губење на продуктивноста. На пример, кога пишувате податоци, системот треба да ги подели на овие групи, а потоа на физичко ниво на главниот диск и дискови за реплики. Односно, функцијата Hash работи при пребарување и вметнување на објект, но има несакан ефект - тоа се многу високи трошоци и ограничувања за обнова на хашот (при додавање или отстранување на диск). Друг проблем со хашот е јасно прикована локација на податоците што не може да се промени. Односно, ако некако дискот е под зголемено оптоварување, тогаш системот нема можност да не пишува на него (со избирање друг диск), функцијата хаш ги обврзува податоците да се лоцираат според правилото, без разлика колку е лошо дискот е, така што Ceph јаде многу меморија кога го обновува PG во случај на само-заздравување или зголемување на складирањето. Заклучокот е дека Ceph работи добро (иако бавно), но само кога нема скалирање, итни ситуации или ажурирања.

Се разбира, постојат опции за зголемување на перформансите преку кеширање и споделување на кешот, но за ова е потребен добар хардвер и сепак ќе има загуби. Но, генерално, Ceph изгледа попримамливо од Глустер за продуктивност. Исто така, при користење на овие производи, неопходно е да се земе предвид важен фактор - ова е високо ниво на компетентност, искуство и професионализам со голем акцент на Linux, бидејќи е многу важно да се распореди, конфигурира и одржува сè правилно, што на администраторот му наметнува уште поголема одговорност и оптоварување.

Vstorage

Архитектурата изгледа уште поинтересна Складирање Virtuozzo (Vstorage), кој може да се користи заедно со хипервизор на истите јазли, на истите жлезда, но многу е важно да конфигурирате сè правилно за да постигнете добри перформанси. Односно, распоредувањето на таков производ од кутијата на која било конфигурација без да се земат предвид препораките во согласност со архитектурата ќе биде многу лесно, но не и продуктивно.

Што може да коегзистира за складирање до услугите на хипервизорот kvm-qemu, а ова се само неколку услуги каде што е пронајдена компактна оптимална хиерархија на компоненти: услуга за клиент монтирана преку FUSE (изменета, не со отворен код), услуга за метаподатоци MDS (Услуга за метаподатоци), сервисни блокови на податоци за услуги, кои на физичко ниво се еднакви на еден диск и тоа е сè. Во однос на брзината, се разбира, оптимално е да се користи шема толерантна за грешки со две реплики, но ако користите кеширање и логови на SSD-дискови, тогаш кодирањето толерантно на грешки (избришете кодирање или raid6) може пристојно да се оверклокира на хибридна шема или уште подобро на сите блицови. Има одреден недостаток со EC (избришете кодирање): кога менувате еден блок на податоци, неопходно е повторно да се пресметаат износите на паритет. За да се заобиколат загубите поврзани со оваа операција, Ceph пишува до EC одложено и може да се појават проблеми со изведбата при одредено барање, кога, на пример, сите блокови треба да се прочитаат, а во случајот на Virtuozzo Storage, се врши пишување на променети блокови користејќи го пристапот „датотечен систем структуриран со дневник“, кој ги минимизира трошоците за пресметка на паритет. Приближно да се проценат опциите со забрзување на работата со и без ЕЗ, постојат калкулатор. – бројките можат да бидат приближни во зависност од коефициентот на точност на производителот на опремата, но резултатот од пресметките е добра помош при планирањето на конфигурацијата.

Едноставен дијаграм на компоненти за складирање не значи дека овие компоненти не апсорбираат железни ресурси, но ако однапред ги пресметате сите трошоци, можете да сметате на соработка до хипервизорот.
Постои шема за споредување на потрошувачката на хардверски ресурси од услугите за складирање Ceph и Virtuozzo.

Ако претходно беше можно да се споредат Глустер и Цеф користејќи стари статии, користејќи ги најважните линии од нив, тогаш со Virtuozzo е потешко. Нема многу написи за овој производ и информации може да се соберат само од документацијата Англиски или на руски ако го сметаме Vstorage како складирање што се користи во некои хиперконвергирани решенија во компании како што се Росплатформа и Акронис.

Ќе се обидам да помогнам со опис на оваа архитектура, така што ќе има малку повеќе текст, но потребно е многу време да ја разберете документацијата сами, а постоечката документација може да се користи само како референца со ревизија на табелата на содржината или пребарување по клучен збор.

Ајде да го разгледаме процесот на снимање во хибридна хардверска конфигурација со компонентите опишани погоре: снимањето почнува да оди до јазолот од кој клиентот го иницирал (услугата точка за монтирање FUSE), но главната компонента на услугата за метаподатоци (MDS) секако ќе насочете го клиентот директно до саканата услуга за парче (услуга за складирање CS блокови), односно MDS не учествува во процесот на снимање, туку едноставно ја насочува услугата до бараниот дел. Во принцип, можеме да дадеме аналогија на снимањето со истурање вода во буриња. Секоја буре е блок на податоци од 256 MB.

Тоа е, еден диск е одреден број на такви буриња, односно волуменот на дискот поделен со 256 MB. Секоја копија се дистрибуира до еден јазол, втората речиси паралелно со друг јазол итн... Ако имаме три реплики и има SSD-дискови за кеш (за читање и пишување логови), тогаш потврдата за запишувањето ќе се случи по пишувањето дневникот на SSD, а паралелното ресетирање од SSD ќе продолжи на HDD, како во позадина. Во случај на три реплики, записот ќе биде извршен по потврда од SSD на третиот јазол. Можеби изгледа дека збирот на брзината на запишување на три SSD може да се подели со три и ќе ја добиеме брзината на запишување на една реплика, но копиите се пишуваат паралелно и брзината на латентност на мрежата е обично поголема од онаа на SSD, а всушност перформансите за пишување ќе зависат од мрежата. Во овој поглед, за да видите вистински IOPS, треба правилно да го вчитате целиот Vstorage методологија, односно тестирање на вистинското оптоварување, а не на меморијата и кешот, каде што е неопходно да се земе предвид точната големина на блокот на податоци, бројот на нишки итн.

Горенаведениот дневник за снимање на SSD-то работи на таков начин што штом податоците ќе влезат во него, сервисот веднаш го чита и се запишува на HDD. Постојат неколку услуги за метаподатоци (MDS) по кластер и нивниот број се одредува со кворум, кој работи според алгоритмот Паксос. Од гледна точка на клиентот, точката за монтирање FUSE е папка за складирање на кластерот која е истовремено видлива за сите јазли во кластерот, секој јазол има монтиран клиент според овој принцип, така што ова складирање е достапно за секој јазол.

За извршување на кој било од горенаведените пристапи, многу е важно, во фазата на планирање и распоредување, правилно да се конфигурира мрежата, каде што ќе има балансирање поради агрегација и правилно избраниот пропусен опсег на мрежниот канал. Во агрегација, важно е да се избере вистинскиот режим на хаширање и големини на рамки. Исто така, има многу силна разлика од SDS опишаната погоре, ова е осигурувач со технологија за брза патека во Virtuozzo Storage. Што, покрај модернизираниот осигурувач, за разлика од другите решенија со отворен код, значително го зголемува IOPS и ви овозможува да не бидете ограничени со хоризонтално или вертикално скалирање. Во принцип, во споредба со архитектурите опишани погоре, оваа изгледа помоќна, но за такво задоволство, се разбира, треба да купите лиценци, за разлика од Ceph и Gluster.

Да резимираме, можеме да го истакнеме врвот од трите: Virtuozzo Storage го зазема првото место во однос на перформансите и доверливоста на архитектурата, Ceph го зазема второто место, а Gluster го зазема третото место.

Критериумите според кои е избран Virtuozzo Storage: тоа е оптимален сет на архитектонски компоненти, модернизирани за овој Fuse пристап со брза патека, флексибилен сет на хардверски конфигурации, помала потрошувачка на ресурси и можност за споделување со пресметување (пресметување/виртуелизација), односно, тој е целосно погоден за хиперконвергирани решенија, од кои тој е дел. Второто место е Ceph бидејќи е попродуктивна архитектура во споредба со Gluster, поради неговата работа во блокови, како и пофлексибилните сценарија и можноста за работа во поголеми кластери.

Се планира да се напише споредба помеѓу vSAN, Space Direct Storage, Vstorage и Nutanix Storage, тестирање на Vstorage на опрема HPE и Huawei, како и сценарија за интегрирање на Vstorage со надворешни системи за складирање на хардвер, па ако ви се допадна статијата, ќе биде убаво е да добивам повратни информации од вас, што би можело да ја зголеми мотивацијата за нови написи, земајќи ги предвид вашите коментари и желби.

Извор: www.habr.com