Първият прототип на обектни хранилища светът видя през 1996 година. Десет години по-късно Amazon Web Services стартира Amazon S3 и светът започна постепенно да полудява от плоското адресно пространство. Благодарение на работата с метаданни и способността си да мащабира, без да обеднява под натоварване, обектните хранилища бързо станаха стандарт за повечето услуги за съхранение на данни в облака и не само. Друга важна особеност е съвместимостта им за съхранение на архиви и подобни рядко използвани файлове. Всички, свързани със съхранението на данни, ликуваха и носеха новата технология на ръце.
Но човешките усти се пълнеха с слухове, че обектните хранилища са само за големи облаци, а ако не искате решения от проклетите капиталисти, ще е много трудно да създадете свое. За разгръщането на свое облако вече е написано много, но информацията относно създаването на т.н. S3-совместими решения е малко.
Затова днес ще разгледаме какви са вариантите "Да бъде като при възрастните, а не CEPH и по-голям чук", ще разгърнем един от тях, а проверката дали всичко работи ще направим с помощта на Veeam Backup & Replication. В него е обявена поддръжка за работа с S3-съвместими хранилища, и именно това заявление ще проверим.
А как е при другите?
Предлагам да започнем с малък обзор на пазара и вариантите за обектни хранилища. Обществено признатият лидер и стандарт е Amazon S3. Два от близките преследващи са Microsoft Azure Blob Storage и IBM Cloud Object Storage.
Наистина ли е само това? Наистина ли няма други конкуренти? Разбира се, има конкуренти, но някои вървят по свой път, като Google Cloud или Oracle Cloud Object Storage, с непълна поддръжка на S3 API. Някои използват стари версии на API, като Baidu Cloud. А други, като Hitachi Cloud, изискват прилагането на специална логика, което безспорно ще предизвика свои трудности. В края на краищата, всички ги сравняват с Amazon, който може да се смята за индустриален стандарт.
А в on-premise решенията изборът е много по-голям, затова нека определим важните за нас критерии. В принцип, стига ни само два: поддръжка на S3 API и използване на v4 подписи. Честно казано, за нас като бъдещи клиенти са интересни само интерфейсите за взаимодействие, а вътрешната логика на самото хранилище вече не ни интересува толкова много.
Под тези прости условия подхождат наистина много решения. Например, класическите корпоративни тежковъзи:
- DellEMC ECS
- NetApp S3 StorageGrid
- Nutanix Buckets
- Pure Storage FlashBlade и StorReduce
- Huawei FusionStorage
Има ниша от чисто софтови решения, работещи от кутията:
- Red Hat Ceph
- SUSE Enterprise Storage
- Cloudian
И дори онези, които обичат да шлифоват след събрание, не бяха пренебрегнати:
- CEPH в чист вид
- Minio (Linux версия, защото по много въпроси за Windows версията има много въпроси)
Списъкът далеч не е изчерпателен, може да се обсъди в коментарите. Само не забравяйте преди внедряване да проверявате освен съвместимостта на API и производителността на системата. Последното нещо, от което се нуждаете, е загубата на терабайти данни заради забавени заявки. Така че не се колебайте с натоварващите тестове. Всъщност целият възрастен софтуер, работещ с големи обеми данни, има поне доклади за съвместимост. В случая с Veeam има за взаимно тестване, позволяваща смело да заявим пълна съвместимост на нашите продукти с конкретно оборудване. Това е двустранна работа, не винаги бърза, но постоянно разширяваме тестуваните решения.
Събираме нашия стенд
Искам да поговоря малко за избора на опитния.
Първо, исках да намеря вариант, който веднага ще работи от кутията. Или поне с максимална вероятност, че ще заработи без необходимост от излишни усилия. Танците с бубни и ровенето в консолата през нощта са много привлекателни, но понякога искам да работи веднага. И общата надеждност на такива решения обикновено е по-висока. И да, в нас се изгуби духът на авантюризма, спряхме да лазим в прозорците на любимите жени и т.н. (с).
На второ място, ако сме честни, необходимостта от работа с обектни хранилища възниква при доста големи компании, така че това е именно онзи случай, в който да се насочат към решения от ниво enterprise не е срамно, а дори се насърчава. Във всеки случай, засега не знам примери, в които някой да е бил уволнен за покупка на подобни решения.
На базата на всичко казано дотук, моят избор падна на Dell EMC ECS Community Edition. Това е много интересен проект и считам за необходимо да ви разкажа за него.
Първото, което идва наум при виждането на добавка Community Edition — това не е просто копие на пълноценен ECS с някакви ограничения, които се премахват с покупката на лиценз. Не е така!
Запомнете:
!!!Community Edition е отделен проект, създаден за тестване, и без техническа поддръжка от Dell!!
И не може да се превърне в пълноценен ECS, дори ако много го желаете.
Нека да разберем
Много хора смятат, че Dell EMC ECS е почти най-доброто решение, ако имате нужда от обектно хранилище. Всички проекти под марката ECS, включително търговски и корпоративни, се основават на . Това е жест на добра воля от Dell. Освен софтуера, който работи на техните брандирани хардуерни решения, има и опенсорс версия, която може да се инсталира в облака, на виртуална машина, в контейнер или на всякакво собствено оборудване. Напредваме — има дори OVA версия, от която ще се възползваме.
Самата DELL ECS Community Edition е мини вариант на пълноценния софтуер, работещ на брандирани сървъри Dell EMC ECS.
Изведох четири основни отличия:
- Няма поддръжка на криптиране. Обидно е, но не критично.
- Липсва Fabric Layer. Това е компонентът, който отговаря за изграждането на клъстери, управление на ресурсите, актуализации, мониторинг и съхранение на Docker образи. Тук наистина е разочароващо, но Dell може да бъде разбрана.
- Най-неприятното последствие от предишната точка: размерът на нода не може да бъде увеличен след завършване на инсталацията.
- Няма техническа поддръжка. Това е продукт за тестване, който не е забранено да се използва в малки инсталации, но да вкарам там петабайти важни данни, лично аз не бих се осмелил. Въпреки това, технически никой не може да ви попречи да го направите.
А какво за по-голямата версия?
Нека бегло да прегледаме хардуерните решения, за да имаме по-пълна представа за екосистемата.
Няма да потвърдям или опровергавам твърдението, че DELL ECS е най-доброто on-prem обектно хранилище, но ако имате мнение по този въпрос, с удоволствие ще го прочета в коментарите. Във всеки случай, според Dell EMC уверено е сред петте лидери на пазара за OBS. Въпреки че там не се включват облачни решения, но това е отделен разговор.
От техническа гледна точка ECS е обектно хранилище, което осигурява достъп до данни чрез протоколи за облачно съхранение. Поддържа AWS S3 и OpenStack Swift. За файлово активни бакети, ECS поддържа NFSv3 за опцията за файлово експортиране.
Процесът на записване на информация е доста необичаен, особено след класическите системи за блочно съхранение.
- Когато постъпят нови данни, се създава нов обект, който има име, самите данни и метадата.
- Обектите се разделят на чанкове по 128 Мб, и всеки чанк се записва незабавно на три възли.
- Настъпва обновление на файла с индекса, където са записани идентификаторите и местата за съхранение.
- Обновява се файлът с журнала (лог записа) и той също се записва на три възли.
- На клиента се изпраща съобщение за успешен запис.
Всички три копия на данните се записват паралелно. Записът се счита за успешен само ако всички три копия са били записани успешно.
Четенето е малко по-просто:
- Клиентът заявява данните.
- В индекса се търси мястото за съхранение на данните.
- Данните се четат от един възел и се изпращат на клиента.
Сървърите са доста много, затова да погледнем най-малкия Dell EMC ECS EX300. Той започва от 60Тб, с възможност да се разрасне до 1,5Пб. А по-големият му брат Dell EMC ECS EX3000 позволява да се съхраняват цели 8,6Пб на шкаф.
Деплой
Технически, Dell ECS CE може да бъде разположен с каквато и да е големина. Във всеки случай, не намерих явно ограничения. Въпреки това, всичкото мащабиране е удобно да се направи чрез клониране на първия възел, за който ще ни трябват:
- 8 vCPU
- 64GB RAM
- 16GB за операционната система
- 1TB директно за съхранение
- Последният релиз на CentOS minimal
Това е вариант за случая, когато искате да инсталирате всичко сами от самото начало. За нас това не е актуален вариант, тъй като ще използвам OVA образ за разгръщане.
Но във всеки случай, изискванията са доста високи дори за един възел, а ако строго следвате буквално правилото, ще са необходими четири такива възела.
Въпреки това, разработчиците на ECS CE живеят в реалния свят и инсталацията минава успешно дори с един възел, а минималните изисквания са:
- 4 vCPU
- 16 GB RAM
- 16 GB за операционната система
- 104 GB самото хранилище
Точно такива ресурси са необходими за разгръщане на OVA образа. Вече е много по-хуманно и реалистично.
Самата инсталационна възел може да бъде взета от официалния . Там има подробна документация за деплой на всичко в едно, но можете също да прочетете на официалния . Затова няма да се задълбочаваме в разгръщането на OVA, в него няма изненади. Най-важното е да не забравите преди да го стартирате или да увеличите диска до необходимия размер, или да прикрепите необходимите.
Стартираме машината, отваряме конзолата и използваме най-добрите кредити по подразбиране:
- потребителско име: admin
- парола: ChangeMe
След това стартираме sudo nmtui и конфигурираме мрежовия интерфейс — IP/маска, DNS и гейт. Имайки предвид, че в CentOS minimal няма net-tools, проверяваме настройките чрез ip addr.
И тъй като морето покорява само смелите, правим yum update, след което reboot. Всъщност това е доста безопасно, тъй като всичкото разгръщане става чрез плейбуци, а всички важни пакети на докера са заковани на текущата версия.
Сега е време да редактираме инсталационния скрипт. Никакви красиви прозорци или псевдо UI — всичко през вашия любим текстов редактор. Чисто технически има два начина: можете да стартирате всяка команда на ръка или веднага да стартирате конфигуратора videploy. Той просто ще отвори конфигурацията в vim и при изход ще пусне проверка. Но умишлено да си опростявате живота не е интересно, така че ще изпълним две команди повече. Въпреки че в това няма смисъл, предупредих ви =)
Така, правим vim ECS-CommunityEdition/deploy.xml и правим оптимално минимални промени, за да се активира и работи ECS. Списъкът с параметри може да се съкрати, но направих по следния начин:
- licensed_accepted: true Може и да не променяте, тогава при деплоя явно ще ви помолят да го приемете и ще покажат мило съобщение. Може би това дори е такова яйце на Пасха.
- Да се разкоментират редовете autonames: и custom: Въведете поне едно желано име за нода — hostname ще бъде заменен с него по време на инсталацията.
- install_node: 192.168.1.1 Укажете реалния IP на нода. В нашия случай посочваме същия, който е в nmtui
- dns_domain: въвеждаме своя домейн.
- dns_servers: вписваме своя dns.
- ntp_servers: можете да укажете какъвто и да е. Аз взех първия попал се от пул 0.pool.ntp.org (това стана 91.216.168.42)
- autonaming: custom Ако не се разкоментира, луната ще се нарече Luna.
- ecs_block_devices:
/dev/sdb
По неведома причина тук може да се окаже несъществуващо блочно устройство /dev/vda - storage_pools:
members:
192.168.1.1 Тук отново указваме реалния IP на нода - ecs_block_devices:
/dev/sdb Повторяем операцию вырезания несуществующих устройств.
Целият файл е много подробно описан в , но кой ще го чете в такова неспокойно време. Там е написано, че минимално достатъчно е да се посочат IP и маска, но в лабораторията ми такъв набор се установяваше трудно и се наложи да се разшири до посоченото по-горе.
След излизането от редактора, трябва да стартирате update_deploy /home/admin/ECS-CommunityEdition/deploy.yml, и ако всичко е направено правилно, ще бъде съобщено явно за това.
След това все пак ще трябва да стартирате videploy, да изчакате обновяването на средата и можете да стартирате самата инсталация с командата ova-step1, а след успешното ѝ извършване командата ova-step2. Важно: не спирайте работата на скриптовете ръчно! Някои стъпки могат да отнемат значително време, да не се изпълняват от първия опит и да изглеждат така, сякаш всичко се е счупило. Във всеки случай трябва да изчакате завършването на скрипта по естествен начин. В края трябва да видите нещо подобно.
Сега най-накрая можем да отворим WebUI контролния панел на известния ни IP. Ако на етапа на конфигурация не сте правили промени, то дефолтната учетна запись ще бъде root/ChangeMe. Можете дори веднага да ползвате нашето S3-совместимо хранилище. То е достъпно на портове 9020 за HTTP и 9021 за HTTPS. Отново, ако не сте правили промени, то access_key: object_admin1 и secret_key: ChangeMeChangeMeChangeMeChangeMeChangeMe.
Но да не бързаме много напред и да започнем подред.
При първото влизане задължително ще бъдете помолени да смените паролата на адекватна, което е напълно правилно. Главният табло е изключително разбираем, така че да направим нещо по-интересно от обяснение на очевидни метрики. Например, да създадем потребител, който ще използваме за достъп до хранилището. В света на услугите такъв се нарича tenant. Това се прави в Manage > Users > New Object User.
При създаването на потребителя ни искат да посочим namespace. Технически, нищо не ни пречи да създаваме толкова, колкото потребители. И обратно. Това позволява да управляваме ресурсите независимо за всеки тенант.
Съответно, избираме необходимите функции и генерираме ключове за потребителя. На мен ми е достатъчно S3/Atmos. И не бива да забравяме да запазим ключа 😉
Потребителят е създаден, сега е време да му осигурим и бакет. Преминаваме в Manage > Bucket и попълваме необходимите полета. Тук всичко е просто.
Сега всичко е готово за нормална употреба на нашето S3 хранилище.
Настройваме Veeam
Така че, както помним, едно от основните приложения на обектните хранилища е дългосрочното съхранение на информация, до която рядко се обръщаме. Идеален пример е необходимостта от съхранение на резервни копия на отдалечено място. В Veeam Backup & Replication тази функция се нарича Capacity Tier.
Нека започнем настройката с добавянето на нашия Dell ECS CE в интерфейса на Veeam. На таба Backup Infrastructure стартираме мастера за добавяне на нов репозиторий и избираме опцията Object Storage.
Избираме това, за което всичко се прави — S3 Compatible.
В появилото се прозорче вписваме желаното име и преминаваме към стъпката Account. Тук трябва да посочим Service point във вида на , региона може да остане без промяна и да добавим създадения потребител. Гейт-сървър е необходим, ако вашето хранилище се намира на отдалечено място, но това е тема за оптимизация на инфраструктурата и отделна статия, така че тук може спокойно да пропуснем.
Ако всичко е посочено и настроено правилно, ще се появи предупреждение за сертификата и след това прозорец с бакета, в който можем да създадем папка за нашите файлове.
Изминаваме визарда до края и се наслаждаваме на резултата.
На следващата стъпка трябва или да създадем нов Scale-out Backup Repository, или да добавим нашия S3 в съществуващ, който ще бъде използван като Capacity Tier за архивно съхранение. В текущото издание няма функция за използване на S3-съвместими хранилища директно, като обикновен репозиторий. Има твърде много неочевидни проблеми, които трябва да се решат, но всичко е възможно.
Влизаме в настройките на репозитория и включваме Capacity Tier. Там всичко е прозрачно, но има интересен нюанс: ако искате всички данни да се изпращат на обектното хранилище за най-кратко време, просто задайте 0 дни.
След като преминете през визарда, ако не искате да чакате, можете да натиснете ctrl+клик на репозитория, да стартирате ръчно Tiering job и да наблюдавате как графиците започват да се движат.
За сега това е всичко. Смятам, че успях да покажа, че блочните хранилища не са толкова страшни, колкото се счита. Да, решенията и вариантите на изпълнение са много, но не можем да обхванем всичко в една статия. Затова нека споделяме опит в коментарите.
Източник: habr.com
