• Поддержка High Avalability
• Поддержка кластеризации до 4 нод
• Максимальный полезный объем 400 ТБ (по 100ТБ на ноду в 4х нодовом кластере)

• Какие характеристики Block storage и File storage нужно учитывать, если хотите, чтобы при росте проекта система хранения выросла вслед за ним
• Почему отказоустойчивость на software уровне надежнее и дешевле, чем на hardware уровне
• Как правильно проводить тестирование, чтобы сравнивать «яблоки с яблоками»
• Как получить на порядок больше/меньше IOPS, поменяв всего один параметр

Кому интересна эта статья

Не так давно ребята из LINBIT представили свое новое SDS-решение — Linstor. Это полностью свободное хранилище в основе которого используются проверенные технологии: DRBD, LVM, ZFS. Linstor сочетает в себе простоту и хорошо проработанную архитектуру, что позволяет добиться стабильности и достаточно внушительных результатов.

Сегодня я хотел бы рассказать про него чуть подробнее и показать насколько просто его можно интегрировать с OpenNebula используя linstor_un — новый драйвер, который я разработал специально для этой цели.

Linstor в сочетании с OpenNebula позволяет построить быстрое и надежное облако, которое можно без проблем развернуть на собственной инфраструктуре.

Былой опыт

Конфигурация Synergy

TL;DR: Вводная статья с описанием разных вариантов хранения данных. Будут рассмотрены принципы, описаны преимущества и недостатки, а также предпочтительные варианты использования.

• посещаемость интернет-магазина может значительно колебаться в зависимости от времени суток или сезона;
• внутренние сервисы компаний могут «пустовать» неделями, а накануне сдачи квартального отчета их посещаемость резко подскочит.

Я люблю Ceph. Я работаю с ним уже 4 года (0.80.x — 12.2.6, 12.2.5). Порой я так увлечен им, что провожу вечера и ночи в его компании, а не со своей девушкой.
 Я сталкивался с различными проблемами в этом продукте, а с некоторыми продолжаю жить и по сей день. Порой я радовался легким решениям, а иногда мечтал о встрече с разработчиками, чтобы выразить свое негодование. Но Ceph по-прежнему используется в нашем проекте и не исключено, что будет использоваться в новых задачах, по крайней мере мной. В этом рассказе я поделюсь нашим опытом эксплуатации Ceph, в некотором роде выскажусь на тему того, что мне не нравится в этом решении и может быть помогу тем, кто только присматривается к нему. К написанию этой статьи меня подтолкнули события, которые начались примерно год назад, когда в наш проект завезли Dell EMC ScaleIO, ныне известный как Dell EMC VxFlex OS.

Это ни в коем случае не реклама Dell EMC или их продукта! Лично я не очень хорошо отношусь к большим корпорациям, и черным ящикам вроде VxFlex OS. Но как известно, всë в мире относительно и на примере VxFlex OS очень удобно показать каков Ceph с точки зрения эксплуатации, и я попробую это сделать.

Будучи инфраструктурным инженером в команде разработки облачной платформы, мне довелось поработать со многими распределенными системами хранения данных, в том числе и с теми, что указаны в заголовке. Кажется, что есть понимание их сильных и слабых сторон, и я попробую поделиться с вами своими мыслями на этот счет. Так сказать, посмотрим у кого хеш-функция длиннее.

Как-то понадобилось интегрировать Open vSwitch (OVS) c Р-виртуализацией плюс Р-хранилище(РП), может пригодится и не только с РП.

Текущая версия РП на момент статьи была 7.0.13-31, ядро в этой версии 3.10.0-1062.12.1.rv7.131.10.1, что соответствует версии RedHat 7.7, а версия OVS, который идет в составе репозитория РП была 2.0.0. Список функционала на OVS 2.0.0 можно посмотреть тут. Ключи для РП можно взять тут.

Цель была попробовать настроить VXLAN и виртуальный коммутатор в качестве альтернативы родным к технологии kvm-qemu и libvirt мостам. Если использовать голый OpenSource kvm-qemu, то там с OVS все в порядке, но захотелось это попробовать с РП, где не просто голый kvm-qemu+libvirt, а много патчей к этой связке и есть vstorage.

Железо

Для этого конечно нам понадобится железо. Минимальные требования РП это три сервера в каждом по три диска, можно конечно и два если все SSD, но в моем случае один SSD остальные HDD. Далее сеть не менее 10 гигабит два порта, в моем случае повезло было 20 гигабит два порта и дополнительный порт 5 гигабит для ввода в кластер тегированного трафика для OVS в обход классическим мостам или другими словами параллельное использование классических мостов Р-виртуализации с OVS. В общем в моем случае повезло в наличии был Synergy c 3 лезвиями, корзинами с JBOD дисками и встроенным коммутатором.

Gluster

The search for a suitable storage platform: GlusterFS vs. Ceph vs. Virtuozzo Storage

Gluster

В ИТ главное — это три буквы

Развитие гиперконвергентной инфраструктуры (HCI), возникшей как ответвление технологии хранения данных (SDS) действительно впечатляет.

Пример Люка Пруэна, сотрудника HPE по гиперконвергенции:

«Около 10 лет назад я работал в США с двумя крупными розничными компаниями. У одной из них было более 2600 торговых точек, у другой — 1200. Обе эти компании стремились уменьшить площади своих магазинов и при этом обеспечить максимальную эффективность и доступность. Управление и оркистрация при таком количестве объектов становятся серьезной задачей. В то время отрасль еще не знала понятия HCI — использовалась инфраструктура VMware Infrastructure 3 (vSphere еще не придумали), а HPE еще только приобрела компанию LeftHand Networks.

Я тесно сотрудничал с обеими компаниями, чтобы решить стоящие перед ними проблемы производительности, доступности и управления. Мы разработали решение для программно-определяемого хранения данных (SDS), которое обеспечило высокую доступность при небольшой площади и отличной производительности на площадках, централизованно управляемых с помощью сервера vCenter. Еще одной серьезной проблемой была модернизация площадок. Как эффективно модернизировать каждую площадку в автоматическом режиме? Сценарии! Мы разработали скрипты для отдельных компонентов решения, включая гипервизор ESXi, микропрограммное обеспечение и решение SDS. Чтобы максимально упростить процесс установки исправлений, оба заказчика стандартизировали единую аппаратную платформу для устранения различий между магазинами. Это позволило упростить и оптимизировать процессы управления, модернизации и устранения неисправностей на любой площадке.

Кажется это уже стало традицией: каждый раз, когда я выхожу на новое рабочее место, моя деятельность начинается с бенчмарков различных SDS-решений. Мой приход во «Флант» не стал исключением. Я попал в команду разработки Kubernetes-платформы Deckhouse, где решили развивать возможность запуска виртуальных машин в Kubernetes. Но для этого сначала потребовалось найти простое и надежное хранилище блочного типа, которое можно предложить клиентам платформы.

Я взял несколько свободных решений и протестировал, как они поведут себя в тех или иных условиях. В первую очередь интересовала производительность DRBD в различных конфигурациях и сравнение с Ceph.

Но рынок программно-определяемых хранилищ не стоит на месте и постоянно растёт. Появляются новые амбициозные проекты, включая недавно релизнутый Mayastor и pet-проект моего товарища-соратника Vitastor. Результаты оказались очень интересными.