Тази статия е написана, за да помогне да изберете подходящото решение за вас и да разберете разликите между SDS решенията, като Gluster, Ceph и Vstorage (Virtuozzo).
В текста са използвани линкове към статии с по-подробно разглеждане на някои проблеми, затова описанията ще бъдат максимално кратки, с акцент на ключовите моменти, без излишна информация, която можете да намерите в интернет, ако желаете.
Разбира се, обсъжданите теми изискват определен тон на текста, но в съвременния свят все повече хора не обичат да четат много))), затова можете да прегледате бързо и да вземете решение, а ако нещо не е ясно, да минете по линковете или да потърсите непознатите термини в интернет))), а тази статия е като прозрачен обвив, който показва основните ключови моменти на всяко от решенията.
Gluster
Започваме с Gluster, който активно се използва от производители на хиперконвергентни платформи, базирани на SDS с open source за виртуални среди, и можете да го намерите на сайта на RedHat в раздела за съхранение, където се предлага да изберете между два варианта на SDS: Gluster или Ceph.
Gluster се състои от стек от транслатори – услуги, които извършват всички операции по разпределение на файлове и т.н. Brick – услуга, която обслужва един диск, Volume – том (пул), който обединява тези brick'ове. Следва услуга за разпределение на файлове по групи чрез функцията DHT (разпределена хеш таблица). Няма да включваме услугата Sharding в описанието, тъй като по-долу ще намерите линкове с описание на свързани проблеми.
При запис файлът изцяло попада в brick, а втората копия паралелно се записва на brick на втория сървър. След това вторият файл вече ще бъде записан в втората група от два brick (или повече) на различни сървъри.
Ако файловете са с приблизително еднакъв размер и томът ще се състои само от една група, всичко е наред, но при други условия ще възникнат следните проблеми, описани по-долу:
- местата в групите се използват неравномерно, което зависи от размерите на файловете, и ако в групата няма достатъчно място за запис на файла – ще получите грешка, файлът няма да бъде записан и няма да бъде преразпределен в друга група;
- в процеса на запис на един файл IO се извършва само на една група, останалите не работят;
- не може да се получи IO от целия том при запис на един файл;
- и общата концепция изглежда по-малко продуктивна заради отсъствието на разпределение на данни по блокове, където е по-лесно да се осъществи балансиране и да се реши проблема с равномерното разпределение, вместо както сега файлът да се поставя в брик цялостно.
От официалното описание също така невольно идва разбиране, че gluster работи като файлово хранилище над класически апаратен RAID. Имаше опити за разработка на разрезане (Sharding) на файлове на блокове, но всичко това е допълнение, което налага загуби в производителността на вече съществуващия архитектурен подход, плюс използване на такива свободно разпространени компоненти с ограничение в производителността като Fuse. Няма услуги за метаданни, което ограничава възможностите за производителност и отказоустойчивост на хранилището при разпределение на файлове на блокове. По-добри показатели за производителност могат да се наблюдават при конфигурация “Distributed Replicated” и броят на нодовете трябва да бъде не по-малко от 6 за организиране на надеждна реплика 3 с оптимално разпределение на натоварването.
Тези изводи също са свързани с описанието на опита с и при сравнение с , както и описание на опита при достигане на разбирането за тази по-продуктивна и по-надеждна конфигурация
На картинката е показано разпределението на натоварването при запис на два файла, където копията на първия файл се разпределят по трите първи сървъра, които са обединени в групата volume 0, и трите копия на втория файл се поставят на втората група volume1 от три сървъра. Всеки сървър има един диск.
Общият извод е такъв, че Gluster може да се използва, но с разбирането, че в производителността и отказоустойчивостта ще има ограничения, които създават трудности при определени условия на хиперконвергентно решение, където ресурсите са нужни и за изчислителни натоварвания на виртуалните среди.
Има някои показатели за производителност на Gluster, които могат да се постигнат при определени условия, ограничени в
Ceph
Сега да разгледаме Ceph от описанията на архитектурата, които успях Има и сравнение между , където може веднага да се разбере, че Ceph трябва да се разгръща на отделни сървъри, тъй като на неговите услуги са необходими всички ресурси на хардуера при натоварвания.
Архитектура по-сложен от Gluster и има услуги като метаданни, но целият стек компоненти е доста сложен и не е особено гъвкаво за използване в решения с виртуализация. Данните се организират в блокове, което изглежда по-продуктивно, но в иерархията на всички услуги (компоненти) има загуби и забавяне при определени натоварвания и аварийни условия, например следното.
В описанието на архитектурата сърцето е CRUSH, благодарение на което се избира място за съхранение на данните. Следва PG — това е най-сложната абстракция (логическа група) за разбиране. PG са необходими, за да бъде CRUSH по-ефективен. Основното предназначение на PG е групиране на обекти за намаляване на потреблението на ресурси, повишаване на производителността и мащабируемостта. Адресацията на обекти директно, поотделно, без обединяване в PG би била много разходна. OSD е услуга за всеки отделен диск.
Кластерът може да има един или много пулове данни с различно предназначение и различни настройки. Пуловете се разделят на групи за разположение. В групите за разположение се съхраняват обекти, до които клиентите имат достъп. На този логически ниво завършва, и започва физически, тъй като за всяка група за разположение е зададен един основен диск и няколко диска-реплики (колко точно зависи от фактора на репликация на пула). С други думи, на логически ниво обектът се съхранява в конкретната група за разположение, а на физически — на дисковете, които са свързани с нея. В същото време дисковете физически могат да бъдат на различни възли или дори в различни дата центрове.
В тази схема групите за поставка изглеждат като необходим елемент за гъвкавостта на цялото решение, но същевременно и като ненужно звено в тази верига, което неминуемо навежда на мисли за загуба на производителност. Например, при запис на данни, системата трябва да ги разделя на тези групи и след това на физическо ниво на главния диск и на дисковете за реплики. Тоест, хеш функцията работи при търсене и поставяне на обекти, но има страничен ефект – много високи разходи и ограничения при пренастройка на хеша (при добавяне или изтриване на диск). Още един проблем на хеша е строго установеното местоположение на данните, които не могат да бъдат променяни. Тоест, ако някакъв диск изпитва повишено натоварване, системата няма възможност да не записва на него (избирайки друг диск), хеш функцията задължава разположението на данните по правило, независимо от това колко тежко е на диска, поради което Ceph изразходва много памет при пренастройване на PG в случай на самоизцеление или увеличаване на хранилището. Изводът е, че Ceph работи добре (въпреки че бавно), но само когато няма мащабиране, аварийни ситуации и актуализации.
Разбира се, има варианти за повишаване на производителността чрез кеширане и кеш-тиране, но в същото време е необходимо добро оборудване и все пак ще има загуби. Но като цяло Ceph изглежда по-привлекателно от Gluster за продуктивност. Също така, при използването на тези продукти е необходимо да се вземе предвид важен фактор – високото ниво на компетенции, опит и професионализъм с голям акцент върху Linux, тъй като е много важно всичко да бъде правилно разположено, настроено и поддържано, което налага още повече отговорност и натоварване на администратора.
Vstorage
Може би дори по-интересна изглежда архитектурата на , която може да се използва съвместно с хипервизора на същите узли, на същото , но е много важно всичко да бъде правилно конфигурирано, за да се постигне добра производителност. Тоест, разгръщайки такъв продукт от кутия на каквато и да е конфигурация без да се вземат предвид препоръките в съответствие с архитектурата ще бъде много лесно, но не и производително.
Какво може да съществува заедно с услугите на hypervisor kvm-qemu? Това са само няколко услуги, където е намерена компактна оптимална йерархия на компонентите: клиентска услуга, монтирана чрез FUSE (модифицирана, не open source), услуга за метаданни MDS (Metadata service), услуга за данни Chunk service, която на физическо ниво е равна на един диск и на това е всичко. По отношение на скоростта, разбира се, е оптимално да се използва отказоустойчива схема с две реплики, но ако се използват кеширане и журнали на SSD дискове, то корекцията на разрушителните кодирования (erase coding или raid6) може да бъде прилично ускорена на хибридна схема или дори по-добре на напълно флаш. При EC (erase coding) има някакъв недостатък: при промяна на един блок данни е необходимо да се преизчислят паритетните суми. За да избегне загубите при тази операция, Ceph пише в EC отложено и проблеми с производителността могат да възникнат при определено запитване, когато, например, е необходимо да се изчислят всички блокове, а в случая с Virtuozzo Storage, записът на променените блокове се извършва, като се използва подхода „логическа файлова система“, което минимизира разходите за изчисление на паритета. За да се преценят горе-долу вариантите с ускорение на работата при EC и без него, има – цифрите могат да бъдат приблизителни, в зависимост от коефициента на точност на производителя на оборудването, но резултатите от изчисленията помагат да се планира конфигурацията.
Простата схема на компонентите за съхранение не означава, че тези компоненти не консумират но ако предварително се изчислят всички разходи, може да се разчита на съвместна работа до hypervisor.
Има схема за сравнение на потреблението на ресурсите на Ceph и Virtuozzo Storage.
Ако по-рано можеше да се сравнява Gluster и Ceph по стари статии, използвайки най-важните редове от тях, с Virtuozzo е по-трудно. Статиите за този продукт не са толкова много и информацията може да се извлече само от документацията на или на руски, ако разглеждаме Vstorage като хранилище, използвано в някои хиперконвергентни решения в такива компании като и Акронис.
Ще опитам да помогна с описанието на тази архитектура, затова текстът ще бъде малко по-дълъг, но за да разбера сам документацията, е необходимо много време, а вече наличната документация може да се използва само като справочник с преглед на съдържанието или търсене по ключова дума.
Нека разгледаме процеса на запис в хибридна конфигурация на хардуера с описаните по-горе компоненти: записа започва на възела, от който е инициран от клиента (услугата за точка на монтиране FUSE), но компонентът на основната услуга за метаданни (MDS) разбира се ще насочи клиента директно към необходимата услуга за блоково съхранение (CS), т.е. MDS не участва в процеса на запис, а просто насочва към необходимата услуга за блокове. В общи линии, може да се направи аналогия с разливане на вода в бъчви. Всяка бъчва е блок данни с размер 256MB.
Т.е. един диск е определено количество от такива бъчви, т.е. обемът на диска разделен на 256MB. Всяка копия се разлива на един възел, втората почти паралелно на друг възел и т.н. Ако имаме три реплики и SSD дискове за кеш (за четене и записни журнали), то потвърждението на записа ще се случва след записването на журнала в SSD, а паралелното изхвърляне от SSD ще продължи на HDD, в известен смисъл на заден план. В случай на три реплики, потвърждението на записа ще е след потвърждението от SSD на третия възел. Може да изглежда, че скоростта на записа на трите SSD може да се раздели на три и ще получим скоростта на записа на едно копие, но записите на копия вървят паралелно и латентността на мрежата обикновено е по-висока от тази на SSD, и всъщност производителността на записа ще зависи от мрежата. Във връзка с това, за да видим реалните IOPS, е необходимо да се натовари правилно целия Vstorage по , т.е. да се тества реалната натовареност, а не паметта и кеша, където е необходимо да се вземе предвид правилния размер на блока данни, броя на потоковете и т.н.
Споменатият по-горе записващ журнал на SSD работи така, че веднага щом данни постъпят в него, се четат от услугата и се записват на HDD. Има няколко услуги за метаданни (MDS) на кластер, а техният брой се определя от кворума, който работи по алгоритъма Paxos. От гледна точка на клиента, точката на монтиране FUSE представлява папка на кластерното хранилище, която е видима за всички възли на клъстера. Всеки възел има монтиран клиент по този принцип, така че това хранилище е достъпно за всеки узел.
За производителността на който и да е от описаните по-горе подходи е изключително важно, по време на планирането и разгръщането, да се настрои мрежата правилно, където ще става балансиране чрез агрегация и правилно подбрана пропускателна способност на мрежовия канал. В агрегацията е важно да се подбере правилен режим на хеширане и размери на фреймовете. Има и значителна разлика от описаните по-горе SDS, а именно, fuse с технологията fast path във Virtuozzo Storage. Която, освен модернизирания fuse, в контекста на другите open source решения, значително увеличава IOPS и позволява да не се ограничавате до хоризонтално или вертикално мащабиране. Въобще, в сравнение с описаните архитектури, тази изглежда по-мощна, но за това удоволствие определено е необходимо да закупите лицензии, за разлика от Ceph и 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
