Перший прототип об'єктних сховищ побачив світ у 1996 році. Через 10 років Amazon Web Services запустить Amazon S3, і світ почне планомірно божеволіти від плоского адресного простору. Завдяки роботі з метаданими та своєї можливості масштабуватися, не просідаючи під навантаженням, об'єктні сховища швидко стали стандартом для більшості сервісів зберігання даних у хмарах, і не тільки. Інша важлива особливість - це хороша пристосованість для зберігання архівів і подібних файлів, що рідко використовуються. Всі, хто був пов'язаний із зберіганням даних, тріумфували і носили нову технологію на руках.
Але людська чутка сповнювалась чутками, що об'єктні сховища — це лише про великі хмари, а якщо вам не потрібні рішення від проклятих капіталістів, то зробити своє буде дуже складно. Про розгортання своєї хмари вже написано багато, а ось про створення так званих S3-compatible рішень інформації замало.
Тому сьогодні ми розберемося, які є варіанти "Щоб як у дорослих, а не 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, вимагають застосування особливої логіки, що неодмінно викличе свої труднощі. У будь-якому випадку всіх порівнюють з Амазоном, який і можна вважати індустріальним стандартом.
А ось у 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 сумісності ще й продуктивність системи. Останнє, що вам потрібно — це втрата терабайтів даних через запити, що підвисли. Так що не соромтеся з тестами навантаження. Взагалі, весь дорослий софт, що працює з великими обсягами даних, має як мінімум звіти про сумісність. У випадку з Вім є із взаємного тестування, що дозволяє сміливо заявляти про повну сумісність наших продуктів із конкретним обладнанням. Це вже двостороння робота, яка не завжди швидка, але ми постійно розширюємо протестованих рішень.
Збираємо наш стенд
Хочеться трохи поговорити про вибір піддослідного.
По-перше, я хотів знайти варіант, який відразу працюватиме з коробки. Ну або хоча б з максимальною ймовірністю того, що він запрацює без необхідності здійснювати зайві рухи тіла. Танці з бубном та колупання консолі в ночі – це дуже захоплююче, але іноді хочеться, щоб працювало одразу. Та й загальна надійність таких рішень зазвичай вища. І так, у нас зник дух авантюризму, ми перестали лазити у вікна до коханих жінок і т.д. (с).
По-друге, якщо чесно, необхідність роботи з об'єктними сховищами виникає у досить великих компаній, так що це той самий випадок, коли дивитися у бік рішень 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 ринку. Хоча там не враховуються cloud-based рішення, але це окрема розмова.
З технічної точки зору ECS – це об'єктне сховище, що забезпечує доступ до даних протоколів хмарного зберігання. Підтримує AWS S3 та OpenStack Swift. Для file-enabled бакетів ECS підтримує NFSv3 для можливості пофайлового експорту.
Процес запису інформації досить незвичайний, особливо після класичних систем блокового зберігання.
- При надходженні нових даних створюється новий об'єкт, який має ім'я, самі дані і метадані.
- Об'єкти б'ються на чанки по 128 Мб, і кожен чанк записується відразу на три ноди.
- Відбувається оновлення файлу індексу, де записано ідентифікатори та місця зберігання.
- Оновлюється файл журналу (лог запису) і також записується на три ноди.
- Клієнту надсилається повідомлення про успішний запис
Усі три копії даних записуються паралельно. Запис вважається успішним, тільки якщо всі три копії були записані успішно.
Читання відбувається простіше:
- Клієнт запитує дані.
- В індексі шукається місце зберігання даних.
- Дані читаються з однієї ноди та відправляються клієнту.
Самих серверів досить багато, тому подивимося на найменшу Dell EMC ECS EX300. Він починається від 60Тб, маючи можливість зрости до 1,5 Пб. А його старший брат Dell EMC ECS EX3000 дозволяє зберігати аж 8,6 Пб на стійку.
Деплой
Технічно Dell ECS CE можна розгорнути як завгодно великим. Принаймні обмежень у явному вигляді я не знайшов. Однак все масштабування зручно робити методом клонування першої ноди, для якої нам знадобляться:
- 8 vCPU
- RAM 64GB
- 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 - все через ваш улюблений текстовий редактор. Чисто технічно є два шляхи: можна запускати кожну команду ручками або відразу запустити конфігуратор відеоплей. Він просто відкриє конфіг у 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:
Члени:
192.168.1.1 Тут знову вказуємо реальний IP ноди - ecs_block_devices:
/dev/sdb Повторюємо операцію вирізування неіснуючих пристроїв.
Взагалі весь файл дуже докладно описаний у , але хто її читати буде у такий неспокійний час. Там же написано, що мінімально-достатнє - це вказати IP і маску, але у мене в лабі такий набір заводився погано, і довелося розширити до вказаного вище.
Після виходу з редактора потрібно запустити update_deploy /home/admin/ECS-CommunityEdition/deploy.yml, і якщо все зроблено правильно, про це буде повідомлено у явному вигляді.
Потім все ж таки доведеться запустити videoploy, дочекатися оновлення оточення, і можна запускати саму інсталяцію командою 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