Кратко сравнение на SDS архитектура или търсене на подходяща платформа за съхранение (GlusterVsCephVsVirtuozzoStorage)

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

Текстът използва връзки към статии с по-подробно разкриване на определени проблеми, така че описанията ще бъдат възможно най-кратки, като се използват ключови точки без ненужни пух и уводна информация, която можете, ако желаете, да получите независимо в Интернет.

Всъщност, разбира се, повдигнатите теми изискват тоновете на текста, но в съвременния свят все повече хора не обичат да четат много))), така че можете бързо да прочетете и да направите избор и ако нещо е не е ясно, следвайте връзките или потърсете в Google неясни думи))) и тази статия е като прозрачна обвивка за тези дълбоки теми, показваща пълнежа - основните ключови точки на всяко решение.

Глъстер

Да започнем с 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 на отделни сървъри, тъй като услугите му изискват всички хардуерни ресурси под натоварване.

архитектура Ceph по-сложен от Gluster и има услуги като услуги за метаданни, но целият набор от компоненти е доста сложен и не е много гъвкав за използването му в решение за виртуализация. Данните се съхраняват на блокове, което изглежда по-продуктивно, но в йерархията на всички услуги (компоненти) има загуби и забавяне при определени натоварвания и аварийни условия, например следното статия.

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

Един клъстер може да има един или много набори от данни за различни цели и с различни настройки. Пуловете са разделени на групи за разположение. Групите разположения съхраняват обекти, до които имат достъп клиентите. Това е мястото, където свършва логическото ниво и започва физическото ниво, тъй като на всяка група за разположение се присвояват един основен диск и няколко реплики на диска (колко точно зависи от коефициента на репликация на пула). С други думи, на логическо ниво обектът се съхранява в определена група за разположение, а на физическо ниво - на дисковете, които са му присвоени. В този случай дисковете могат да бъдат физически разположени на различни възли или дори в различни центрове за данни.

В тази схема групите за разположение изглеждат като необходимо ниво за гъвкавостта на цялото решение, но в същото време като допълнителна връзка в тази верига, което неволно предполага загуба на производителност. Например, когато записвате данни, системата трябва да ги раздели на тези групи и след това на физическо ниво на основния диск и дискове за реплики. Тоест функцията Hash работи при търсене и вмъкване на обект, но има страничен ефект - това са много високи разходи и ограничения за възстановяване на хеша (при добавяне или премахване на диск). Друг проблем с хеша е ясно закованото местоположение на данни, които не могат да бъдат променени. Тоест, ако по някакъв начин дискът е под повишено натоварване, тогава системата няма възможност да не пише на него (чрез избор на друг диск), хеш функцията задължава данните да бъдат локализирани според правилото, независимо колко лошо е дискът е, така че Ceph изяжда много памет при възстановяване на PG в случай на самолечение или увеличаване на паметта. Изводът е, че Ceph работи добре (макар и бавно), но само когато няма мащабиране, аварийни ситуации или актуализации.

Има, разбира се, опции за увеличаване на производителността чрез кеширане и споделяне на кеш, но това изисква добър хардуер и пак ще има загуби. Но като цяло Ceph изглежда по-примамлив от Gluster за продуктивност. Също така, когато използвате тези продукти, е необходимо да се вземе предвид важен фактор - това е високо ниво на компетентност, опит и професионализъм с голям акцент върху Linux, тъй като е много важно да се внедри, конфигурира и поддържа всичко правилно, което натоварва още повече отговорността и тежестта върху администратора.

Vstorage

Архитектурата изглежда още по-интересна Virtuozzo съхранение (Vstorage), който може да се използва заедно с хипервайзор на същите възли, на същия жлеза, но е много важно да конфигурирате всичко правилно, за да постигнете добра производителност. Това означава, че внедряването на такъв продукт от кутията във всяка конфигурация, без да се вземат предвид препоръките в съответствие с архитектурата, ще бъде много лесно, но не и продуктивно.

Какво може да съществува едновременно за съхранение до услугите на хипервайзора kvm-qemu и това са само няколко услуги, при които е намерена компактна оптимална йерархия от компоненти: клиентска услуга, монтирана чрез FUSE (модифицирана, не с отворен код), услуга за метаданни MDS (Метаданни услуга), услуга Chunk услуга блокове данни, което на физическо ниво е равно на един диск и това е всичко. По отношение на скоростта, разбира се, оптимално е да се използва схема с устойчивост на грешки с две реплики, но ако използвате кеширане и регистрационни файлове на SSD устройства, тогава толерантното към грешки кодиране (изтриване на код или raid6) може да бъде прилично овърклокнато на хибридна схема или дори по-добре на всички флаш. Има някои недостатъци при EC (кодиране за изтриване): при промяна на един блок данни е необходимо да се преизчислят сумите за паритет. За да заобиколи загубите, свързани с тази операция, Ceph пише в EC по отложен начин и могат да възникнат проблеми с производителността по време на определена заявка, когато например всички блокове трябва да бъдат прочетени, а в случая на Virtuozzo Storage, запис на променени блокове се извършва с помощта на подхода на „лог-структурирана файлова система“, който минимизира разходите за изчисляване на паритета. За да оцените приблизително опциите с ускорение на работа с и без ЕК, има калкулатор. – цифрите могат да бъдат приблизителни в зависимост от коефициента на точност на производителя на оборудването, но резултатът от изчисленията е добра помощ при планирането на конфигурацията.

Една проста диаграма на компонентите за съхранение не означава, че тези компоненти не абсорбират железни ресурси, но ако изчислите всички разходи предварително, можете да разчитате на сътрудничество до хипервайзора.
Има схема за сравняване на потреблението на хардуерни ресурси от Ceph и Virtuozzo услуги за съхранение.

Ако по-рано беше възможно да се сравнят Gluster и Ceph с помощта на стари статии, използвайки най-важните редове от тях, тогава с Virtuozzo е по-трудно. Няма много статии за този продукт и информацията може да бъде извлечена само от документацията за него на английски или на руски, ако разглеждаме Vstorage като хранилище, използвано в някои хиперконвергирани решения в компании като Росплатформа и Acronis.

Ще се опитам да помогна с описание на тази архитектура, така че ще има малко повече текст, но отнема много време, за да разберете документацията сами, а съществуващата документация може да се използва само като справка чрез преразглеждане на таблицата на съдържание или търсене по ключова дума.

Нека разгледаме процеса на запис в хибридна хардуерна конфигурация с компонентите, описани по-горе: записът започва да отива към възела, от който клиентът го е инициирал (услугата за точка на монтиране FUSE), но главният компонент на услугата за метаданни (MDS), разбира се, ще насочете клиента директно към желаната част от услугата (услуга за съхранение CS блокове), тоест MDS не участва в процеса на запис, а просто насочва услугата към необходимата част. Като цяло можем да дадем аналогия на записа с наливането на вода в бъчви. Всеки барел е 256MB блок данни.

Тоест, един диск е определен брой такива варели, тоест обемът на диска, разделен на 256MB. Всяко копие се разпределя на един възел, второто почти паралелно на друг възел и т.н... Ако имаме три реплики и има 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, тестване на Vstorage на оборудване на HPE и Huawei, както и сценарии за интегриране на Vstorage с външни хардуерни системи за съхранение, така че ако ви хареса статията, ще бъде радвам се да получа обратна връзка от вас, което би могло да повиши мотивацията за нови статии, като се вземат предвид вашите коментари и желания.

Източник: www.habr.com