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

Былой опыт

Ранее несколько лет назад был 5 летний опыт работы с СУБД Oracle в среде RISC-овой архитектуры на базе IBM, c их очень хорошей юникс подобной ОС AIX c своим прекрасным инструментом smitty, и все это еще разворачивалось на аппаратной виртуализации PowerVM, где можно настраивать балансировку на базе двух VIOS и т.д.



За всем этим набором как-то надо было следить, особенно за БД, и у всех этих программ были свои средства мониторинга, но вдохновлял меня на тот момент самый красивый и имеющий дашборды для всех этих компонентов, инструмент под названием spotlight от компании Quest.

Как-то понадобилось интегрировать Росплатформу (Р-Виртуализацию и Р-Хранилище) с аппаратным СХД( 3PAR), и это может очень пригодится в различных сценариях.
 

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

Ранее такого рода интеграция тестировалась на лезвиях(Blade CH121 v5) блейд центра Huawei c СХД Dorado 5000 v3, где SDS(software-defined storage) Р-Хранилище Росплатформы поверх СХД показал себя довольно хорошо за счет all flash, но с Synergy, при наличии JBOD дисков с модуля D3940, все намного интереснее и гибче.

Как-то понадобилось интегрировать 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 дисками и встроенным коммутатором.

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

This article outlines the key features and differences of such software-defined storage (SDS) solutions as GlusterFS, Ceph, and Virtuozzo Storage. Its goal is to help you find a suitable storage platform.

Gluster

Let’s start with GlusterFS that is often used as storage for virtual environments in open-source-based hyper-converged products with SDS. It is also offered by Red Hat alongside Ceph.
GlusterFS employs a stack of translators, services that handle file distribution and other tasks. It also uses services like Brick that handle disks and Volume that handle pools of bricks. Next, the DHT (distributed hash table) service distributes files into groups based on hashes.
Note: We’ll skip the sharding service due to issues related to it, which are described in linked articles.



When a file is written onto GlusterFS storage, it is placed on a brick in one piece and copied to another brick on another server. The next file will be placed on two or more other bricks. This works well if the files are of about the same size and the volume consists of a single group of bricks. Otherwise the following issues may arise:

Данная статья написана для того, чтобы помочь выбрать для себя подходящее решение и понять отличия между такими SDS как Gluster, Ceph и Vstorage (Virtuozzo).

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

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

Gluster

Начнем с Gluster, который активно используется у производителей гиперконвергентных платформ с SDS на базе open source для виртуальных сред и его можно найти на сайте RedHat в разделе storage, где предлагается выбрать из двух вариантов SDS: Gluster или Ceph.

Gluster состоит из стека трансляторов – службы которые выполняют все работы по распределению файлов и т.д. Brick – служба которая обслуживает один диск, Volume – том(пул) – который объединяет эти brick’и. Далее идет служба распределения файлов по группам за счет функции DHT(distributed hash table). Службу Sharding включать в описание не будем так как в ниже выложенных ссылках будет описание проблем связанных с ней.



При записи файл целиком ложится в brick и его копия параллельно пишется на brick на втором сервере. Далее второй файл уже будет записываться в вторую группу из двух briсk(или более) на разных серверах.