Объектное хранилище в подсобке, или Как стать самому себе сервис-провайдером

Первый прототип объектных хранилищ мир увидел в 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 совместимости ещё и производительность системы. Последнее, что вам надо — это потеря терабайтов данных из-за подвисших запросов. Так что не стесняйтесь с нагрузочными тестами. Вообще весь взрослый софт, работающий с большими объёмами данных, имеет как минимум отчёты о совместимости. В случае с Veeam есть целая программа по взаимному тестированию, позволяющая смело заявлять о полной совместимости наших продуктов с конкретным оборудованием. Это уже двухсторонняя работа, не всегда быстрая, но мы постоянно расширяем список протестированных решений.

Собираем наш стенд

Хочется немного поговорить о выборе подопытного.

Во-первых, я хотел найти вариант, который сразу будет работать из коробки. Ну или хотя бы с максимальной вероятностью того, что он заработает без необходимости совершать лишние телодвижения. Танцы с бубном и ковыряние консоли в ночи — это очень увлекательно, но иногда хочется, чтобы работало сразу. Да и общая надёжность таких решений обычно повыше. И да, в нас пропал дух авантюризма, мы перестали лазить в окна к любимым женщинам и т.д.(с).

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

Исходя из всего вышесказанного, выбор мой пал на Dell EMC ECS Community Edition. Это очень интересный проект, и я считаю необходимым рассказать вам о нём.

Первое, что приходит в голову при виде дополнения Community Edition — что это просто калька с полноценного ECS с каким-то ограничениями, которые снимаются покупкой лицензии. Так вот нет!

Запомните:

!!!Community Edition — это отдельный проект, созданный для тестирования, и без техподдержки со стороны Dell!!
И его не превратить в полноценный ECS, даже если очень захочется.

Давайте разбираться

Многие считают, что Dell EMC ECS — чуть ли не самое лучшее решение, если у вас возникла необходимость в объектном хранилищe. Все проекты под маркой ECS, включая коммерческие и корпоративные, лежат на гитхабе. Этакий жест доброй воли от Dell. И помимо софта, который запускается на их брендовом железе, есть опенсорс-версия, которую можно развернуть хоть в облаке, хоть на виртуалке, хоть в контейнере, хоть на любом своём железе. Забегая вперёд — есть даже OVA версия, чем мы и воспользуемся.
Сам DELL ECS Community Edition — это мини-вариант полноценного софта, работающего на брендовых серверах Dell EMC ECS.

Я выделил четыре главных отличия:

• Нет поддержки шифрования. Обидно, но не критично.
• Отсутствует Fabric Layer. Эта штука отвечает за построение кластеров, менеджмент ресурсов, обновления, мониторинг и хранение Docker образов. Вот тут уже очень обидно, но Dell тоже можно понять.
• Самое противное следствие предыдущего пункта: размер ноды нельзя расширить после завершения инсталляции.
• Нет техподдержки. Это продукт для тестирования, который не возбраняется использовать в небольших инсталяциях, но заливать туда петабайты важных данных лично я бы не решился. Но технически помешать вам это сделать никто не может.

А что в большом варианте?

Галопом по Европам пробежимся по железным решениями, дабы иметь более полное представление об экосистеме.

Как-то подтверждать или опровергать утверждение, что DELL ECS — это лучшее on-prem объектное хранилище, я не буду, но если вам есть что сказать на эту тему, с удовольствием прочитаю в комментариях. Во всяком случае по версии IDC MarketScape 2018 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
• 64GB RAM
• 16GB для операционки
• 1TB непосредственно для хранения
• Последний релиз CentOS minimal

Это вариант для случая, когда вы хотите устанавливать всё сами с самого начала. Для нас это вариант не актуален, т.к. я буду использовать для деплоя OVA образ.

Но в любом случае требования весьма злые даже для одной ноды, а если строго следовать букве закона, то таких нод надо четыре.

Однако разработчики ECS CE живут в реальном мире, и инсталляция проходит успешно даже с одной нодой, а минимальные требования таковы:

• 4 vCPU
• 16 GB RAM
• 16 GB для операционки
• 104 GB само хранилище

Именно такие ресурсы нужны для развёртывания OVA образа. Уже намного гуманнее и реалистичней.

Саму установочную ноду можно взять в официальном github. Там же есть подробная документация по деплою всё-в-одном, но можно ещё почитать на официальном readthedocs. Поэтому подробно останавливаться на разворачивании 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 в виде https://your_IP:9021, регион можно оставить как есть, и добавить созданного пользователя. Гейт-сервер необходим, если ваше хранилище находится на удалённой площадке, но это уже тема оптимизации инфраструктуры и отдельной статьи, так что здесь можно смело пропустить.

Если всё указано и настроено верно, вылезет предупреждение о сертификате и затем окно с бакетом, где можно создать папку для наших файлов.

Проходим визард до конца и наслаждаемся результатом.

На следующем шаге нужно или создать новый Scale-out Backup Repository, или добавить наш S3 в существующий — он будет использован в качестве Capacity Tier для архивного хранения. Функции использовать S3-совместимые хранилища напрямую, как обычный репозиторий, в текущем релизе нет. Слишком много довольно неочевидных проблем для этого надо решить, но всё может быть.
Заходим в настройки репозитория и включаем Capacity Tier. Там всё прозрачно, но есть интересный нюанс: если хочется, чтобы все данные в кратчайшие сроки отправлялись на объектное хранилище, просто установите 0 дней.

После прохождения визарда, если не хочется ждать, можно нажать ctrl+ПКМ на репозитории, принудительно запустить Tiering job и наблюдать, как поползут графики.

На этом пока всё. Считаю, с задачей показать, что блочные хранилища — это не так страшно, как принято думать, я справился. Да, решений и вариантов исполнения вагон и маленькая тележка, но за одну статью всего не охватить. Поэтому давайте делиться опытом в комментариях.

Источник: habr.com