Sds

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

Развертывание РП

Краткая инструкция по установке:

• 1. Устанавливаем первую ноду, в анаконде назначаем IP хосту и из этой же подсети виртуальный IP для управления Р-виртуализации, и IP для управления Р-хранилищем. Дисков как минимум должно быть 3, один для хоста (ОС/гипервизор) в моем случае HDD, второй и третий диск уже настроим через управление Р-хранилищем, где один SSD под кэш и другой под чанк сервер. На втором интерфейсе назначаем IP из другой подсети для сети хранения без шлюза.
• 2. После установки заходим через браузер хром по IP адресу управления Р-хранилищем, далее выбираем раздел серверы и нажимаем на вопросик с прямоугольником, и выбираем раздел сеть, в нем назначаем роли для интерфейса с адресом подсети управления(роли ssh, управление, web cp) и для интерфейса с подсетью для хранения назначаем роли (ssh, хранилище).
• 3. Далее нажимаем создать кластер вводим его имя автоматом должен подключится интерфейс с ролью хранения и выбрать подробные настройки, убедится что система правильно распределила роли на дисках, один должен быть системный, другой служба метаданных плюс кэш если это SSD и далее третий диск HDD в роли хранения (чанк сервер).
• 4. Параллельно с установкой первой ноды можно устанавливать две последующие, назначить каждой по два IP адреса один для подсети управления Р-виртуализации, на втором интерфейсе из подсети хранения. Если оставить поля регистрации на сервере управления Р-виртуализации и управления Р-хранилище пустыми то, можно продолжить установку без указания IP адресов управления, а регистрацию выполнить потом.
• 5. После того как последующие ноды установлены пройти по IP адресу этих хостов через ssh в cli и выполнить регистрацию, где IP это адрес управления Р-хранилищем и токен можно скопировать с веб управления р-хранилищем при нажатии добавить ноду.
• 6. После того как обе ноды появятся в веб управлениии Р-хранилище выполнить те же действия что в пункте 2-3 только вместо создания кластера выбрать присоединить.
• 7. Далее после создания кластера появится пункт сервисы в нем создать хранилище датастор в зависимости наличия дисков и узлов можно делать реплику 2 или 3 и т.д. если узла 3 то, реплика 2, остальное все по умолчанию.
• 8. Далее проходим по IP адресу управления Р-виртуализации нажимаем добавить если физ. сервер если не добавлен и добавляем остальные, далее устанавливаем триал лицензию, далее в настройках хоста выполнить Изменение настроек хоста для виртуальных сред выбрать вместо локальной папки по умолчанию можно для всех пунктов(для первого раза лучше так) выбираем наш датастор который создавали в Р-хранилище и ставим галочку применить на все хосты.
• 9. После это мигрируем vstorage-ui и va-nm на любой другой хост, время может занять некоторое потому что это миграция с локальных носителей на кластерные.
• 10. После этого открываем ssh консоли всех трех узлов и вводим команду включения HA на каждом узле, где IP адрес сети хранения, после этого необходимо проверить командой #shaman stat
  
• 11. После этого можно приступать к созданию ВМ, где я в качестве гостевой установил CentOS 7.

команда регистрации ноды к выше описанному пункту 5:

#/usr/libexec/vstorage-ui-agent/bin/register-storage-node.sh -m 10.43.10.14 -t ec234873

комнда включения HA к пункту 10:

#hastart -c имя кластера -n 192.168.10.0/24 

и проверка HA, где вывод должен быть примерно такой:

[root@n3 ~]# shaman statCluster 'rptest'Nodes: 3Resources: 7    NODE_IP           STATUS     ROLES                RESOURCES    192.168.10.10     Active     VM:QEMU,CT:VZ7       0 CT, 0 VM    192.168.10.11     Active   VM:QEMU,CT:VZ7       0 CT, 0 VM*M 192.168.10.12     Active     VM:QEMU,CT:VZ7       2 CT, 0 VM

Установка и настройка OVS

На первой и третей ноде кластера были установлены OVS следующей командой:

#yum install openvswitch 

После установки можно проверить командой

#ovs-vsctl show 

Вывод будет примерно следующий:

[root@node1 ~]# ovs-vsctl show180c5636-2d3d-4e08-9c95-fe5e47f1e5faovs_version: "2.0.0"[root@node1 ~]#

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

# ovs-vsctl add-br ovsbr0 

Имя моста назовем так чтобы было понятно, что это экземпляр одного виртуального коммутатора.
Далее можем создать тегированный мост для добавления к определенной ВМ.

#ovs-vsctl add-br brlv140 ovsbr0 140 

Тег при этом может быть не привязан к какому-то реальному тегу с физического порта, это только в рамках виртуального коммутатора.
Далее назначаем его ВМ к виртуальной сети, где предварительно создаем xml файл:

<network> <name>ovsvl</name> <forward mode='bridge'/> <bridge name='brlv140'/> <vlan>  <tag id='140'/></vlan><virtualport type='openvswitch'/></network>

К сожалению веб ui Р-управления пока не поддерживает настройки с OVS, но их можно сделать через cli. Для создания и добавления виртуальных сетевых адаптеров к ВМ я воспользовался веб ui, но далее уже через cli подменил привязку этих адаптеров к ovsvl и ovsvl2 вместо Bridged. Главное потом не забыть, что изменения в сетевые настройки оборудования ВМ уже вносить через cli иначе веб ui не зная про OVS вернет Bridged.
Для просмотра существующих сетей используем команду:

#virsh net-list --all 

Для добавления нашей сети:

#virsh net-define ovsvl.xml 

Далее необходимо ее запустить/активировать

#virsh net-start ovsvl

И прописать в автостарт

#virsh net-autostart ovsvl

Далее необходимо добавить эту сеть к ВМ

#virsh edit имяВМ 

Находим необходимые строки с интерфейсами, редактируем их или добавляем свои по аналоги существующих меняя мак адрес и номер порта(слот):

<interface type='bridge'>      <mac address='00:1c:42:c6:80:06'/>

  <vlan>    <tag id='140'/>  </vlan>  <virtualport type='openvswitch'>    <parameters interfaceid='5a70be5b-5576-4734-9f61-61cdfc4a884a'/>  </virtualport>  <target dev='vme001c42c68006'/>  <model type='virtio'/>  <boot order='2'/>  <alias name='net0'/>  <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/></interface>

Редактирование осуществляется командами редактора vi
Далее после редактирования необходимо выключить и запустить ВМ для применения текущих настроек:

#prlctl stop имя ВМ

#prlctl start имя ВМ

Для проверки можно ввести команду:

#virsh dumpxml имяВМ | grep имясети 

После этого можно приступать к настройкам сети изнутри гостя ВМ или добавить сетевые порты в коммутатор для связи с другим кластером по VXLAN overlay:

#ovs-vsctl add-port ovsbr0 vxlan0 -- set Interface vxlan0 type=vxlan options:remote_ip=10.43.11.12 

где IP адрес это адрес той ноды на которой произведены такие же настройки как показано выше. Прямая связь между этими адресами может быть, как через роутеры, так и через VPN, и из разных подсетей, главное, чтобы между ними был настроен маршрут. Но еще главнее, чтобы интерфейс физического порта на котором назначен это адрес, был настроен MTU больше чем 1500 для пропускания пакетов с большим размером, так как vxlan добавляет свои данные, заголовок в несколько байт, но я не стал заморачиваться считать все байты и просто назначил 2000.
Например:

#ip link set mtu 2000 dev ens3f0

сам мост зависящий от этого интерфейса тоже должен быть с mtu2000, но он может не сразу его наследовать и возможно понадобиться его перезапустить.

На стороне второго кластера выполнить на ноде с адресом 10.43.11.12 как описано выше те же настройки только в vxlan назначить адрес ноды первой настройки в моем случае

#ovs-vsctl add-port ovsbr0 vxlan0 -- set Interface vxlan0 type=vxlan options:remote_ip=10.43.11.10

Далее также настроить mtu.
Если у вас все правильно настроено то, пойдут пинги и возможно делать подключения по ssh, если предварительно например, изнутри ВМ задать адреса из одной подсети. Если выполнить анализ сети:

#tcpdump i ens3f0 | grep 4789``` то можно увидеть пакеты с vxlan или c тегами vlan ```bash#tcpdump -ee -vvv -i ens3f0 | grep vlan

Далее можно настроить более удобный вариант настройки сети без мостов через функционал виртуального коммутатора portgroup.
Для этого необходимо создать xml сети со следующим:

 <network><name>ovsvl2</name><forward mode='bridge'/><bridge name='ovsbr0'/><virtualport type='openvswitch'/><portgroup name='vlan-120'>    <vlan>      <tag id='120'/>    </vlan>  </portgroup></network>

Можно создать новую сеть или отредактировать предыдущую с этими параметрами, но
В моем случае добавляю еще одну сеть
Как описано выше, а в ВМ уже следующим образом:

<interface type='bridge'>      <mac address='00:1c:42:c8:f1:cd'/>

  <vlan>    <tag id='120'/>  </vlan>  <virtualport type='openvswitch'>    <parameters interfaceid='ef717aa4-23b3-4fbe-82bb-193033f933b1'/>  </virtualport>  <target dev='vme001c42c8f1cd'/>  <model type='virtio'/>  <boot order='3'/>  <alias name='net1'/>  <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/></interface>

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

#ovs-vsctl set port ens3f4 trunks=120,130#ovs-vsctl add-port ovsbr0 ens3f4  

И можно добавить порт с тегом 120 для ВМ:

#ovs-vsctl add-port ovsbr0 vlan120 tag=120 -- set interface vlan120 type=internal

На стороне другого виртуального коммутатора на другой ноде другого кластера, где нет транка от физического коммутатора добавить точно также этот порт то есть:

#ovs-vsctl add-port ovsbr0 vlan120 tag=120 -- set interface vlan120 type=internal

Плюс добавить сеть как описано выше.

Пример вывода настроек OVS и ВМ

Вывод команды #ovs-vsctl show на первой ноде. Порты и интерфейсы с именем начинающимся с vme являются виртуальными интерфейсами ВМ, которые автоматически попадают в конфиг при запуске ВМ подключенному к OVS.

Вывод команды #ovs-vsctl show на третей ноде

Вывод команды virsh net-list содержит 4 вида сети, где Bridged и Host-Only это стандартные классические варианты от Р-виртуализации по дефолту, а ovsvl и ovsvl2 это то, что мы добавили по инструкции выше. Ovsvl получается для варианта с тегированным мостом tag 140 поверх моста OVS, а ovsvl2 это вариант с группой портов portgroup состоящей из одного порта с tag 120. Portgroup очень удобен и в него можно добавлять больше одного порта используя только одну сеть вместо большого количества сетей в классическом варианте Р-виртуализации с мостами под которыми разные VLAN интерфейсы. Далее вывод команды #virsh net-dumpxml ovsvl и ovsvl2 показывающие содержимое настроек этих сетей.

Здесь кусок конфига ВМ, где сетевые интерфейсы по команде:

 #virsh dumpxml имяВМ

Тесты

При тестировании OVS была проверена совместимость с запущенным networkmanager(NM), выше описанные сценарии работают нормально, но при автозапуске службы NM может выдавать сообщения по интерфейсам виртуального коммутатора, которыми не может управлять, NM можно выключить, но на функциональность сети это не влияет.

Еще имеются дополнения для управления OVS через NM, но в этом случае функционал OVS ограничен. Поэтому возможна параллельная работа, либо с отключением NM при необходимости.

Также были успешно проверены живые миграции ВМ с сетями от OVS, если на каждой ноде имеется экземпляр сети вместе с OVS то, проблем с миграцией нет, так же как и в стандартной конфигурации кластера Р-виртуализации с дополнительными сетями для ВМ.

На рисунке выше был запущен ping изнутри ВМ в сторону ВМ из внешней сети и выполнена живая миграция ВМ с одной ноды с установленным OVS на другую ноду с установленным OVS, красным помечена задержка во время этой миграции ВМ. Параметры ВМ были следующие 4 vCPU, 8GB RAM, 64GB disk.

Точно такая же задержка происходит и в классике с мостами, то есть для ВМ ничего не поменялось, а сетевой стек теперь работает через OVS.

По мимо этого производились успешные подключения по ssh с разными ВМ расположенными на разных нодах между туннелем vxlan и с ВМ за физическим коммутатором. Для проверки работы выключали туннель или анализировали пакеты через tcpdump как описано выше. Если не назначить MTU как описано выше то, будут проходить только ping, а через ssh не получится подключится.

Описание сценариев

Ниже показан стандартный классический с мостами вариант настройки кластера из трех нод Р-виртуализация плюс Р-хранилища без OVS.

На схеме опущена и не показана сеть Р-хранилища, она обычно идет отдельным интерфейсом предназначенного только для блочного уровня и в этом тесте не участвует. Ее можно настраивать без мостов, и как вариант ее тоже можно задействовать через OVS. Например настроить на OVS агрегацию для Р-хранилища.
Далее схема с использованием вместе с мостами OVS.

Тут уже может быть одна сеть с OVS и одна с мостом. С OVS можно добавлять порты с разными тегами в portgroup и выводить уже на разные ВМ.

Если вернемся к тестируемому сценарию то, его можно увидеть на следующей картинке

В моем случае было в рамках одного кластера, но это может быть и между разными кластерами за счет туннелей vxlan. Попытаемся представить себе, что это ноды двух разных кластеров.
Туннель поднят на специально выделенном порту одного из серверов каждого кластера. Через туннель выполняется проброс определенного vlan120 в котором определенное количество ВМ со всего кластера рассчитанное на ширину пропускного канала, где средствами OVS можно определить QoS для трафика каждой ВМ. Локальные ВМ этого узла видны через локальный OVS, а ВМ с других узлов видны через физический коммутатор каждого кластера.

Отказоустойчивость OVS обеспечивается за счет добавления в скрипт службы HA(shaman) команд по перебросу туннеля vxlan на другую ноду с OVS, которая будет выбрана по дефолтному алгоритму drs,round-robin за счет службы shaman от Р-Хранилища. Отказоустойчивость и балансировку порта сервера можно обеспечить за счет агрегации bonding в режиме LACP(802.3ad) c хэшированием layer2+3 или layer3+4, которую также можно настроить средствами OVS.

Как работает классический br0 я описывать не буду, ovsbr0 работает со IP стеком ОС, который на этой картинке определен для br0, то есть экземпляр виртуального коммутатора в виде ovsbr0 работает в данном случае через br0. Другими словами статический IP адрес ноды назначен на классический br0 и весь трафик, который направлен в эту подсеть с виртуального коммутатора проходит через br0, так же как это работает для всех приложений этой ноды. С точки зрения настройки в этом случае никаких cli назначений на br0 со стороны виртуального коммутатора не производилось кроме настройки vxlan интерфейса с option, соответственно если у ноды есть второй классический br1 c другим IP адресом и подсетью висящий на другом физическом порту например eth2 или eth3 то, с виртуального коммутатора за счет стека ОС и его таблицы mac-ов можно направить пакеты в эти подсети назначив какой либо порт виртуального коммутатора в эту подсеть и подключить к ВМ, адрес подсети будет непосредственно назначаться внутри ВМ или в ее настройках.

Благодаря такому принципу виртуальный коммутатор работает как обычная программа на хосте через его сетевой стек не мешая классическим мостам, но конечно при условии что вы не сконфигурируете одинаковые настройки на обоих инструментах (на мостах и OVS).

У виртуального коммутатора есть своя таблица маков.

У каждого созданного мною виртуального коммутатора есть какой-то набор интерфейсов (разрешая влан на каком-то интерфейсе мы добавляем порт в определенный виртуальный коммутатор), а также таблица соответствия mac адресов и портов (ее мы смотрим командой ovs-appctl fdb/show ovsbr0). Ручное назначение мак адресов внутри коммутатора не производилось. Portgoup это группа портов в которой на данный момент есть порт vlan120 к которому подключена ВМ.

Теоретически мы можем представить, что когда в какой-то порт коммутатора прилетает фрейм с VLAN тегом, то решение о дальнейшей отправке фрейма принимается на основании таблицы mac адресов соответствующего виртуального коммутатора. Если получен фрейм с тегом 120, то соответственно приниматься решение о форвардинге данного фрейма будет на основании mac таблицы виртуального коммутатора с тегом 120.

Что касаемо VXLAN то, в этом случае static (Unicast). Самый простой вариант это статичное указание удаленных интерфейсов по типу vxlan. Все сводится к тому, что в конфигурации VNI(vlan vxlan) надо статически задать адреса всех удаленных интерфейсов vxlan, которые терминируют клиентов в указанном VNI. В таком сценарии vxlan будет указывать в IP заголовке как адреса назначения адреса указанных вручную vxlan. Естественно, если vxlan-ов будет больше двух, то точек назначения пакета при флуде будет уже как минимум две. Указать в IP заголовке нескольких получателей не получится, поэтому самым простым решением будет репликация VxLAN пакета на исходящем интерфейсе vxlan и отправка их юникастом на удаленные интерфейсы vxlan, указанные в конфигурации. Получив данный пакет, удаленный vxlan его декапсулирует, определяет какому VNI данный пакет относится и далее рассылает его во все порты в данном VNI. Помимо этого, так как мы все в курсе, что mac адреса изучаются коммутаторами на основании поля source mac, то после декапсуляции VxLAN пакета интерфейс vxlan ассоциирует mac адрес, указанный как исходящий в оригинальном ethernet заголовке с тоннелем до интерфейса vxlan, от которого данный пакет получен. Как и было сказано ранее VxLAN тоннель коммутатор воспринимает как простой транковый порт.

Минусы данного подхода очевидны это увеличенная нагрузка на сеть, так как BUM трафик реплицируется на исходящем интерфейсе vxlan и юникастом рассылается всем указанным в конфигурации нейборам, плюс к этому при добавлении или удалении интерфейса vxlan придется править конфиги на всех остальных интерфейсах vxlan-ах и руками удалить или добавить нейбора (нейборов) или в авторежиме средствами скриптов шамана в случае аварии узла. В век автоматизации конечно как-то странно использовать статическое указание нейборов. Но все равно данный подход имеет право на жизнь, например OVS умеет работать только со статически заданным нейбором, во всяком случае на данный момент.

Для работы данного режима необходимо только наличие связности между лупбеками всех интерфейсов vxlan.
Static (Unicast) VxLAN проста как валенок и безотказна, как автомат Калашникова. Ломаться тут нечему.
здесь все более подробно описано по определению маков и flood&Learn в OVS.

Заключение

При выполнении настроек OVS понравилась простота, удобносто, сразу чувствуется что работаешь с коммутатором, а не просто с мостами))) В общем есть смысл его использовать хотя бы параллельно с классическими мостами в РП.

Перед выше описанной интеграцией по мимо использованных в ней ссылок изучал еще следующие статьи:
1)https://www.sidorenko.io/post/2018/11/openstack-networking-open-vswitch-and-vxlan-introduction/
2) https://blog.remibergsma.com/2015/03/26/connecting-two-open-vswitches-to-create-a-l2-connection/
3)http://mx54.ru/nastrojka-setevyx-interfejsov-v-kvm-dlya-virtualnyx-mashin/
4) https://kamaok.org.ua/?p=2677
5)https://kashyapc.fedorapeople.org/virt/add-network-card-in-guest.txt
6)https://costiser.ro/2016/07/07/overlay-tunneling-with-openvswitch-gre-vxlan-geneve-greoipsec/#.XuZ960UzaM_

storage.cloud.croc.ru/c2-multimedia/habr_PR/ModifyIOPS_UI.gif

Практически любой бизнес сталкивается с плавающей нагрузкой: то тишина, то шквал. За примерами далеко ходить не надо:

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

Под катом поговорим о том, как мы помогли клиентам решить эту проблему, внедрив новый уровень хранения с настраиваемыми показателями IOPS.

Пара слов о дисках

Все наши клиенты хотят плюс-минус одного получить надежную, соответствующую требованиям бизнес-процессов инфраструктуру по хорошей цене. Соответственно, перед нами как перед облачным провайдером стоит задача построить услуги и сервисы таким образом, чтобы для каждого клиента мы могли без труда подобрать оптимальное решение.
Ранее у нас было два уровня хранения данных: st2 и gp2. Цифра 2 в нашей внутренней терминологии означает более новую, улучшенную версию.

st2: Standard (HDD) неторопливые и недорогие носители на SAS HDD. Отлично подходят для сервисов, где IOPS не имеют решающего значения, но важна пропускная способность.
Параметры у них следующие: время отклика не более 10 мс, производительность дисков размером до 2000 ГБ 500 IOPS, от 2000 ГБ 1000 IOPS, а пропускная способность растет с каждым гигабайтом и доходит до 500 МБ/с на тех же 2000 ГБ.

gp2: Universal (SSD) более дорогие и быстрые накопители на SAS SSD. Подходят заказчикам, чьи приложения более требовательны к количеству операций ввода-вывода в секунду. Например базы данных интернет-магазинов.

Параметры gp2 указаны в SLA. Производительность в IOPS рассчитывается по объему на 1 ГБ приходится 10 IOPS. Верхняя планка 10000 IOPS. А время отклика таких дисков уже не более 2 мс. Это довольно высокая производительность, способная закрыть 97% бизнес-задач.

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

Можно смоделировать простой злободневный кейс. В период пандемии одной компании потребовалось оформить пропуска для сотрудников. Чтобы они спокойно по Москве ездили. Штат большой, две тысячи человек. Вышел приказ срочно обновить личные данные в корпоративной CRM-системе. Сказано сделано. Больше тысячи человек одновременно бросились актуализировать информацию. Но CRM-кой занимались экономные люди. Мощностей выделили мало. Никто же не ожидал, что в нее больше десяти человек одновременно полезет! Все упало и еще сутки не могло подняться. Бизнес-процессы нарушились, люди сидят по домам и боятся штрафов. А если бы существовала возможность гибко подкрутить производительность дисков в облаке подняли бы IOPS ненадолго, а потом вернули, как было, исключив или значительно сократив время простоя CRM.

С одной стороны, ситуация гротескная, процент заказчиков с такими потребностями не очень велик. Маленький провайдер и вовсе принял бы их существование за статистическую аномалию и не предпринимал бы никаких действий. С другой организация нового уровня хранения позволит нам повысить гибкость услуг для всех клиентов. Значит, делать надо.

Если вы давно следите за нашим блогом, то наверняка помните статью, в которой мы рассказывали о череде экспериментов над Dell EMC ScaleIO (ныне PowerFlex OS) и его внедрении в Облако КРОК. Как бы то ни было, рекомендуем вам ознакомиться с ней для общего понимания.

В общих чертах скажем: ScaleIO (DellEMC переименовал ScaleIO сначала в VxFlex OS, а c 25 июня 2020 года в PowerFlex OS) супер универсальный и надежный Software-Defined Storage, SDS. У нас надежность это требование 0. Поэтому каждый узел, составляющий часть Storage Poolа установлен в отдельную стойку, что исключает возможность потери данных при частичной потере электропитания в ЦОД или локально в стойке.

Если из строя выйдет диск, сервер или целая стойка, у нас будет достаточно времени, чтобы отреплицировать данные на другие хосты и в последствии заменить сбойный элемент. Если умрут сразу две стойки, все равно ничего не потеряется. В этой ситуации кластер перейдет в аварийный режим, запись и чтение данных с дисков будет ограничено, но после восстановления связности с упавшей стойкой PowerFlex OS сам займется процессом Rebuildа данных и восстановления работы кластера. Такой процесс, кстати, чаще всего занимает не более пары минут.

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

С точки зрения универсальности PowerFlex OS (бывш. ScaleIO) также идеально подходит под наши требования. Фактически это конструктор, готовый к приему любых нагрузок и способный принимать и медленные SATA/SAS HDD диски, и быстрые SSD, и ультра-скоростные NVME накопители. И это действительно правда проверено на многочисленных stage- и testing-стендах команд разработки и эксплуатации, собрать кластер можно практически из говна и палок любого старого железа.

Музыка с пяти до шести

Давайте рассмотрим один из сценариев, в которых заказчику может потребоваться гибкая производительность, на реальном примере. Среди наших клиентов есть сеть магазинов музыкальных инструментов. Технические специалисты компании отслеживают, сколько посетителей посещают их сайт в каждый день и час. Это отражено даже в нашем SLA: с 17:00 до 18:00 магазин получает максимальное количество покупателей, поэтому никаких технических работ или простоев быть не должно.

Стандартная практика расчетов когда 100% нагрузки делятся 24 часа. Выходит примерно 4% на каждый час. У сети музыкальных магазинов этот конкретный час весит не 4, а 10% это десятки тысяч посетителей и покупателей.

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

Теперь у нас появилась возможность в самые нагруженные часы выдавать клиентам хоть 30, хоть 50 тысяч IOPS, а в остальное время держать производительность на обычном уровне. Такой тип хранения мы назвали io2: Ultimate (SSD). Время отклика дисков на основе этого типа хранения уже не более 1 мс!

И снова о надежности: st2, gp2 и новый io2 это самостоятельные, независимые друг от друга Storage Poolы в кластере PowerFlex.

Если раньше клиент выбирал диск и получал фиксированную производительность, то теперь он может ее, производительность, выбирать и настраивать. Вне зависимости от объема. Философия здесь следующая: получить огромный и быстрый диск можно у большого количества провайдеров, но готовы ли вы платить за него 100% времени?

Как управлять

Управлять производительностью можно двумя способами: по старинке, через веб-интерфейс, и с помощью API. Это дает возможность написать простые скрипты, которые по расписанию будут ускорять или замедлять диски и, соответственно, экономить ваши ресурсы.

Если раньше мы могли принять любую нагрузку, требующуюся клиенту, теперь мы можем сделать это по оптимальной цене.

Вот, как это выглядит на практике

Повышение адаптивности облачной инфраструктуры это актуальный и очень правильный тренд. Нельзя говорить заказчику: бери, что дают, а то и этого не будет!. Он должен иметь возможность решать, какие ресурсы, когда и в каком объеме ему требуются. Именно за такими гибкими и надежными решениями будущее.

За свои сервисы мы ручаемся: все параметры прописаны в SLA, и вы можете рассчитывать на то, что бумажные цифры с реальными не разойдутся.
А как проверить своего облачного провайдера, мы уже писали в предыдущей статье.

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

Былой опыт

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



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


Дашборд Spotlight

Прошло время пришлось работать с другими технологиями, как и многие попал в течение тенденций в сторону открытого ПО, где проприетарный spotlight конечно не очень котируется. Избалованный всякими простыми, платными удобностями, сквозь негативные эмоции, пользовался средствами от разработчиков свободного ПО и иногда ностальгировал по spotlight. Например Zabbix как-то не особо привлекал к себе внимание, но как только услышал про Grafana с Prometheus, само название меня уже заинтересовало, а когда увидел дашборды то, вспомнил про Spotlight. Хотя наверно и в Zabbix можно добиться такого же эффекта или даже использовать его через тот же Grafana, но изначально как я понял без особой персонализации красивых дашбордов там нет, с таким же наборов возможностей, впрочем как и в простом Prometheus.

Соблазнительно-таинственный grafana+prometheus

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



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



На самом деле для Grafana и Prometheus уже есть много разработанных готовых дашбордов и экспортеров метрик от различных систем, что делает его простым и удобным для использования, но когда идет речь о чем-то своеобразном то, необходимо немного заморачиваться и хорошо если разработчики постарались, написали метрики к своим сервисам, а бывает что приходится самому варганить эти метрики. Тогда уже может невольно прийти желание использовать другие средства мониторинга, например как в Росплатформе если недостаточно встроенных предлагается Zabbix, это лучше чем возится с разработкой метрик каждого сервиса под Prometheus.

Мониторинг Росплатформы

В Росплатформе конечно есть еще и свои встроенные средства мониторинга, например в веб UI для SDS vstorage или для гипервизора с виртуальными средами или для таких сервисов на экспорт как s3, iscsi.


Главный дашборд SDS-а(Р-хранилище) Росплатформы


Дашборд одной из нод кластера Росплатформы(в Р-хранилище)


Дашборд Росплатфомы для s3 в Р-хранилище


Мониторинг виртуальной машины Росплатформы(В Р-управлении виртуализации)

Есть даже CLI мониторинг SDS(Р-хранилища) сердце Росплатформы #vstorage c имякластера top

Мониторинг SDS(Р-хранилища) Росплатформы через CLI

Но когда необходим более детальный мониторинг по каждому сервису/службе то, тут уже необходимо что-то другое, а в Росплатформе как в инфраструктурной экосистеме, сервисов немало. И разработчики как оказалось работают в этом направлении и можно даже увидеть результат их деятельности, если в развернутом кластере Росплатформы посмотреть на сервисы SDS через команду #netstat tunap | grep имясервиса, где имя сервиса например cs служба чанк сервера.
И мы можем увидеть вывод:



Где есть адрес 0.0.0.0 и порт 37548 который можно прослушать через команду

#curl localhost: 37548/metrics

И мы увидим целую кучу метрик, которые как раз подходят для Prometheus и для рисования графиков с привлекательным интерфейсом в Grafana.



По мимо этих просто чудо метрик есть конечно возможность использовать обычные доступные всем экспортеры для Prometheus, потому что под капотом Росплатформы модифицированный гипервизор kvm-qemu плюс libvirt и операционная система на базе linux ядра. Разработчики Росплатформы также планируют добавить в свой репозиторий эти экспортеры с модификацией под новую версию, но можно не дожидаясь воспользоваться уже сейчас выше описанными. В этой статье попробую описать все таки как можно работать с чудо метриками отдельных сервисов так как это оказалось более сложнее чем просто готовые экспортеры.



В общем сама Grafana умеет только рисовать, а для сбора метрик она использует различные сборщики, одним из которых является выше описанный Prometheus. Он конечно сам умеет рисовать графики и имеет свой веб ui, но это далеко от Grafana.


Веб ui от Prometheus


Дашборд Grafana

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

Service Discovery

Изначально мне показалось, что всего этого будет достаточно чтобы замутить свой мониторинг на базе этих прекрасных инструментов, но не тут-то было. Дело в том, что например для микросервисов SDS-а нет готовых экспортеров, для каждой его службы, да и вряд ли появятся, так как сервис работающий для одного диска может появляться и исчезать, если этот диск например заменить или добавить новые диски, или сервисы s3/iscsi при масштабировании могут плодится и т.д. И что получается каждый новый сервис прописывать в экспортере или в конфиге Prometheus, где для каждого свой уникальный порт?

Можно конечно написать целую программу под это дело, но это уже другая история, и хочется как-то менее рутинным и более легким путем. Покапавшись в гугле узнал, что есть еще программы service discover и одна из самых популярных для Prometheus это Сonsul.



Насмотревшись про него видео и изучив его возможности оказалось, что в нем можно просто зарегистрировать/ отрегистрировать сервисы с их портами для последующей передачи Prometheus, но сам он конечно ничего не ищет, как это описывают на первый взгляд в многих статьях и документации этого инструмента. То есть искать он может разными способами (DNS, HTTP API, RPC) уже у себя внутри среди зарегистрированных в нем сервисах.

В результате можно вернутся к нашей команде #netstat, и выполнять эту команду через Ansible или написать скрипт под планировщик задач с помощью которого будут сканироваться наши сервисы netstat-ом. Далее каждый найденный сервис наш скрипт будет регистрировать в Сonsul командой

#curl --request PUT --data @services.json localhost:8500/v1/agent/service/register

Где файл services.json это описание сервиса в этом формате:

 {  "services":[{  "name":"cs",  "tags":["csid=1026"],  "address":"127.0.0.1",  "port":33074},{  "name":"mds",  "address":"127.0.0.1",  "tags":["mdsid=2"],  "port": 9100}]}

В данном примере описываются два сервиса это чанк сервер cs и служба метаданных SDS Росплатформы mds.
Отрегистрировать также можно устроить с помощью одного и того же скрипта, который будет проверять доступность метрик от этого сервиса по его порту и в случае пустого ответа выкидывать этот сервис из Consul по команде:

#curl --request PUT http://127.0.0.1:8500/v1/agent/service/deregister/my-service-id

Есть конечно еще путь эмулировать API Consul, чтобы Prometheus думал, что он обращается к Consul, а на самом деле к ngnix, где ему подкладывал бы в формате json список сервисов этот же скрипт. Но это уже опять другая история, близкая к разработке. Можно оставить сам консул, который идет в виде отдельно выполняемого файла, в связи с чем его можно расположить на SDS для отказоустойчивости вместо его кластерной настройки, которую также можно осуществить, но это усложняет инструкцию и выходит за рамки этого описания.

Далее после того как у нас запущен Consul с необходимыми зарегистрированными сервисами, надо установить и настроить Prometheus. Можно это сделать в виртуальной среде, а на каждой ноде только его экспортер. Например в Росплатформе он уже предустановлен в контейнере vstorage-ui управления SDS-ом(Р-хранилище), остается только установить экспортеры на ноды и прописать их в конфиге Prometheus.

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

Если пройти в раздел explore то, можно проверить нашу работу, нажав на кнопку метрики, где у вас появится меню/список с разделами метрик.

Установка настройка Consul

В выше описанной краткой инструкции я опустил настройку конфигурационного файла Prometheus,
но для начала установим и запустим сам Consul на одной из нод кластера Росплатформы(Р-виртуализации):
Можно скачать его следующей командой

#wget  https://releases.hashicorp.com/consul/1.9.1/сonsul_1.9.1_linux_amd64.zip

Распаковываем его

# unzip сonsul_1.9.1_linux_amd64.zip

B сразу можно запустить проверить

#./consul v

Для начала чтобы не заморачиваться со автоскриптом по поиску и регистрации сервисов служб SDS-а Росплатформы в Consul, описанным выше, попробуем просто создать папку с прописанными службами в файле json.

#mkdir consul.d

И внутри этой папки создадим файл

#vi services.json

Со следующим содержимом

{  "services":[{  "name":"cs",  "tags":["csid=1026"],  "address":"127.0.0.1",  "port":33074},{  "name":"mds",  "address":"127.0.0.1",  "tags":["mdsid=2"],  "port": 9100}]}

Где 1026 это id службы чанк сервера, которую можно увидеть по команде

#vstorage c имя_вашего_кластера list-services

По ней также можно увидеть mdsid

Порты можно посмотреть через #netstat tunap | grep cs или mds в строке с адресом 0.0.0.0 с протоколом tcp.
После этого можно проверить запустить наш Consul

#consul agent -dev -enable-script-checks -config-dir=./consul.d

На экран будут выводится сообщения, можно это окно закрыть consul продолжит работать в фоновом режиме, для его перезагрузки можно воспользоваться командой

#consul reload

Можно проверить работу Consul через команду

#curl localhost:8500/v1/catalog/services

Он должен вывести наши зарегистрированные сервисы



И можно еще проверить каждый сервис:

Установка настройка Prometheus

Теперь можно установить Prometheus прям на ноду чтобы пока не возится с Prometheus в vstorage-ui

#wget https://github.com/prometheus/prometheus/releases/download/v2.23.0/prometheus-2.23.0.linux-amd64.tar.gz#mkdir /etc/Prometheus#mkdir /var/lib/Prometheus#tar zxvf prometheus-2.23.0.linux-amd64.tar.gz#cd prometheus-*.linux-amd64#cp prometheus promtool /usr/local/bin/#cp -r console_libraries consoles prometheus.yml /etc/Prometheus#useradd --no-create-home --shell /bin/false Prometheus#chown -R prometheus:prometheus /etc/prometheus /var/lib/Prometheus#chown prometheus:prometheus /usr/local/bin/{prometheus,promtool}

Как запустить и прописать в автозапуск в виде сервиса смотрим здесь
Редактируем наш конфиг файл Prometheus:

#vi /etc/systemd/system/prometheus.service

global:  scrape_interval:     1m  evaluation_interval: 1malerting:  alertmanagers:  - static_configs:    - targets:      - localhost:9093rule_files:- /var/lib/prometheus/rules/*.rules- /var/lib/prometheus/alerts/*.rules  - job_name: consul    honor_labels: true    consul_sd_configs:    - server: '127.0.0.1:8500'  #адрес и порт Consul       datacenter: 'dc1'   # к какому датацентру Consul относится - опционально      scheme: http  # по какому протоколу/схеме взаимодействие    relabel_configs:    - source_labels: [__address__]      regex: (.*)[:].+      target_label: instance      replacement: '${1}'    - source_labels: [__meta_consul_service]      target_label: 'job'    - source_labels: [__meta_consul_node]      target_label: 'node'    - source_labels: [__meta_consul_tags]      regex: ',(?:[^,]+,){0}([^=]+)=([^,]+),.*'      target_label: '${1}'      replacement: '${2}' 

Здесь
Нам в помощь дока про конфиг, а в самом примере здесь некоторые строки с комментарием.
Теперь можно запустить Prometheus проверить его работоспособность

#systemctl start prometheus.service#systemctl status prometheus.service

Пройти через браузер по адресу адрес_ноды_где_установлен_Prometheus:9090


И потом пройти в меню status -> targets



И провалится например по ссылке 127.0.0.1:33074 /metrics где мы увидим наши метрики от службы чанк сервера


К каждой строке есть комментарий

Установка настройка Grafana

Далее устанавливаем grafana
Я установил у себя на ноутбуке на windows 10 и зашел через браузер по адресу localhost:3000
Далее подключился к серверу к ноде с установленным Prometheus


Теперь проходим в меню manage и создаем наш новый дашборд.


Выбираем добавить новую панель

Можно ее назвать например memory use, для того чтобы попробовать отобразить использование памяти сервера нашей выше описанной службы чанк сервер.
На вкладе query выбрать из выпадающего списка datasource Prometheus, который мы ранее настроили на наш сервер(Р-виртуализации) Росплатформы с прослушивающим портом 9090.
Далее в поле metrics мы должны вставить метрику, ее можно подобрать из списка всех метрик по описанию после слова HELP.



Находим process_swap_bytes использование swap в байтах. Еще можно взять process_resident_memory_bytes из комментария видно, что это использование памяти сервера.
И дополнительно взять process_swapin_delay_seconds задержка при передачи памяти swap в резидентную память.
В Grafana в дашборде можно создать переменную:



После этого редактируем панель

• 1. Название панели memory use.
• 2. Выбираем data sources в нашем случае это Prometheus.
• 3. Добавляем описание например общий объем памяти и памяти подкачки, занятой CS, а также процент времени, затраченного на ожидание передачи памяти swap в резидентную память.
• 4. Пишем первый запрос с именем метрики process_swap_bytes{job=cs,csid=$cs}, где указываем службу cs и переменную его id.
• 5. Имя определения.
• 6. Разрешение.

Добавляем еще query и прописываем туда аналогично как мы прописывали для swap,
Только в поле напротив metrics где B будет process_resident_memory_bytes{job=cs,csid="$cs"}, а в С будет instance:process_swapin_delay_seconds:rate5m{job=cs,csid="$cs"}


Здесь настраиваем цвет и шкалу графика


В результате должен получится вот такой график



На этом пока все, надеюсь это как-то поможет тем, кто интересуется настройкой своего мониторинга на базе Grafana и Prometheus плюс Consul для Росплатформы или других похожих систем.

Полезные ссылки:

• Наборы дашбордов Grafana https://grafana.com/grafana/dashboards
• Различные экспортеры Prometheus https://prometheus.io/docs/instrumenting/exporters/
• Экспортер для libvirt https://github.com/kumina/libvirt_exporter
• Экспортер для Linux https://github.com/prometheus/node_exporter
• Документация консула https://www.consul.io/docs/intro
• Статья про Consul http://personeltest.ru/aways/habr.com/ru/post/278085/ и http://personeltest.ru/aways/habr.com/ru/post/266139/
• Вторая статья про работу с Consul https://dotsandbrackets.com/using-consul-service-discovery-ru/
• третья статья Consul про регистрацию https://www.airpair.com/scalable-architecture-with-docker-consul-and-nginx
• установка, настройка Prometheus https://www.dmosk.ru/instruktions.php?object=prometheus-linux или https://eax.me/prometheus-and-grafana/
• Подробнее о Prometheus http://personeltest.ru/aways/habr.com/ru/company/selectel/blog/275803/
• Как писать свои метрики для Prometheus https://eax.me/golang-prometheus-metrics/
• статья про настройку связки Grafana с Prometheus https://devconnected.com/monitoring-linux-processes-using-prometheus-and-grafana/#a_Installing_Pushgateway или https://rtfm.co.ua/grafana-sozdanie-dashboard/

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

Зачем это все?

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

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

Хранение данных

Под хранением обычно понимают запись данных на некоторые накопители данных, с целью их (данных) дальнейшего использования. Опустим исторические варианты организации хранения, рассмотрим подробнее классификацию систем хранения по разным критериям. Я выбрал следующие критерии для классификации: по способу подключения, по типу используемых носителей, по форме хранения данных, по реализации.

По способу подключения есть следующие варианты:

• Внутреннее. Сюда относятся классическое подключение дисков в компьютерах, накопители данных устанавливаются непосредственно в том же корпусе, где и будут использоваться. Типовые шины для подключения SATA, SAS, из устаревших IDE, SCSI.

подключение дисков в сервере

• Внешнее. Подразумевается подключение накопителей с использованием некоторой внешней шины, например FC, SAS, IB, либо с использованием высокоскоростных сетевых карт.

дисковая полка, подключаемая по FC

По типу используемых накопителей возможно выделить:

• Дисковые. Предельно простой и вероятно наиболее распространенный вариант до сих пор, в качестве накопителей используются жесткие диски
• Ленточные. В качестве накопителей используются запоминающие устройства с носителем на магнитной ленте. Наиболее частое применение организация резервного копирования.
• Flash. В качестве накопителей применяются твердотельные диски, они же SSD. Наиболее перспективный и быстрый способ организации хранилищ, по емкости SSD уже фактически сравнялись с жесткими дисками (местами и более емкие). Однако по стоимости хранения они все еще дороже.
• Гибридные. Совмещающие в одной системе как жесткие диски, так и SSD. Являются промежуточным вариантом, совмещающим достоинства и недостатки дисковых и flash хранилищ.

Если рассматривать форму хранения данных, то явно выделяются следующие:

• Файлы (именованные области данных). Наиболее популярный тип хранения данных структура подразумевает хранение данных, одинаковое для пользователя и для накопителя.
• Блоки. Одинаковые по размеру области, при этом структура данных задается пользователем. Характерной особенностью является оптимизация скорости доступа за счет отсутствия слоя преобразования блоки-файлы, присутствующего в предыдущем способе.
• Объекты. Данные хранятся в плоской файловой структуре в виде объектов с метаданными.

По реализации достаточно сложно провести четкие границы, однако можно отметить:

• аппаратные, например RAID и HBA контроллеры, специализированные СХД.

RAID контроллер от компании Fujitsu

• Программные. Например реализации RAID, включая файловые системы (например, BtrFS), специализированные сетевые файловые системы (NFS) и протоколы (iSCSI), а также SDS

пример организации LVM с шифрованием и избыточностью в виртуальной машине Linux в облаке Azure

Давайте рассмотрим более детально некоторые технологии, их достоинства и недостатки.

DAS

Direct Attached Storage это исторически первый вариант подключения носителей, применяемый до сих пор. Накопитель, с точки зрения компьютера, в котором он установлен, используется монопольно, обращение с накопителем происходит поблочно, обеспечивая максимальную скорость обмена данными с накопителем с минимальными задержками. Также это наиболее дешевый вариант организации системы хранения данных, однако не лишенный своих недостатков. К примеру если нужно организовать хранение данных предприятия на нескольких серверах, то такой способ организации не позволяет совместное использование дисков разных серверов между собой, так что система хранения данных будет не оптимальной: некоторые сервера будут испытывать недостаток дискового пространства, другие же не будут полностью его утилизировать:

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

SAN

Storage area network, она же сеть хранения данных, является технологией организации системы хранения данных с использованием выделенной сети, позволяя таким образом подключать диски к серверам с использованием специализированного оборудования. Так решается вопрос с утилизацией дискового пространства серверами, а также устраняются точки отказа, неизбежно присутствующие в системах хранения данных на основе DAS. Сеть хранения данных чаще всего использует технологию Fibre Channel, однако явной привязки к технологии передачи данных нет. Накопители используются в блочном режиме, для общения с накопителями используются протоколы SCSI и NVMe, инкапсулируемые в кадры FC, либо в стандартные пакеты TCP, например в случае использования SAN на основе iSCSI.

Давайте разберем более детально устройство SAN, для этого логически разделим ее на две важных части, сервера с HBA и дисковые полки, как оконечные устройства, а также коммутаторы (в больших системах маршрутизаторы) и кабели, как средства построения сети. HBA специализированный контроллер, размещаемый в сервере, подключаемом к SAN. Через этот контроллер сервер будет видеть диски, размещаемые в дисковых полках. Сервера и дисковые полки не обязательно должны размещаться рядом, хотя для достижения высокой производительности и малых задержек это рекомендуется. Сервера и полки подключаются к коммутатору, который организует общую среду передачи данных. Коммутаторы могут также соединяться с собой с помощью межкоммутаторных соединений, совокупность всех коммутаторов и их соединений называется фабрикой. Есть разные варианты реализации фабрики, я не буду тут останавливаться подробно. Для отказоустойчивости рекомендуется подключать минимум две фабрики к каждому HBA в сервере (иногда ставят несколько HBA) и к каждой дисковой полке, чтобы коммутаторы не стали точкой отказа SAN.

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

NAS

Network attached storage, или сетевое файловое хранилище, представляет дисковые ресурсы в виде файлов (или объектов) с использованием сетевых протоколов, например NFS, SMB и прочих. Принципиально базируется на DAS, но ключевым отличием является предоставление общего файлового доступа. Так как работа ведется по сети сама система хранения может быть сколько угодно далеко от потребителей (в разумных пределах разумеется), но это же является и недостатком в случае организации на предприятиях или в датацентрах, поскольку для работы утилизируется полоса пропускания основной сети что, однако, может быть нивелировано с использованием выделенных сетевых карт для доступа к NAS. Также по сравнению с SAN упрощается работа клиентов, поскольку сервер NAS берет на себя все вопросы по общему доступу и т.п.

Unified storage

Универсальные системы, позволяющие совмещать в себе как функции NAS так и SAN. Чаще всего по реализации это SAN, в которой есть возможность активировать файловый доступ к дисковому пространству. Для этого устанавливаются дополнительные сетевые карты (или используются уже существующие, если SAN построена на их основе), после чего создается файловая система на некотором блочном устройстве и уже она раздается по сети клиентам через некоторый файловый протокол, например NFS.

SDS

Software-defined storage программно определяемое хранилище данных, основанное на DAS, при котором дисковые подсистемы нескольких серверов логически объединяются между собой в кластер, который дает своим клиентам доступ к общему дисковому пространству.

Наиболее яркими представителями являются GlusterFS и Ceph, но также подобные вещи можно сделать и традиционными средствами (например на основе LVM2, программной реализации iSCSI и NFS).

N.B. редактора: У вас есть возможность изучить технологию сетевого хранилища Ceph, чтобы использовать в своих проектах для повышения отказоустойчивости, на нашем практическим курсе по Ceph. В начале курса вы получите системные знания по базовым понятиям и терминам, а по окончании научитесь полноценно устанавливать, настраивать и управлять Ceph. Детали и полная программа курса здесь.

Пример SDS на основе GlusterFS

Из преимуществ SDS можно построить отказоустойчивую производительную реплицируемую систему хранения данных с использованием обычного, возможно даже устаревшего оборудования. Если убрать зависимость от основной сети, то есть добавить выделенные сетевые карты для работы SDS, то получается решение с преимуществами больших SAN\NAS, но без присущих им недостатков. Я считаю, что за подобными системами будущее, особенно с учетом того, что быстрая сетевая инфраструктура более универсальная (ее можно использовать и для других целей), а также дешевеет гораздо быстрее, чем специализированное оборудование для построения SAN. Недостатком можно назвать увеличение сложности по сравнению с обычным NAS, а также излишней перегруженностью (нужно больше оборудования) в условиях малых систем хранения данных.

Гиперконвергентные системы

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

Облака и эфемерные хранилища

Логическим продолжением перехода на виртуализацию является запуск сервисов в облаках. В предельном случае сервисы разбиваются на функции, запускаемые по требованию (бессерверные вычисления, serverless). Важной особенностью тут является отсутствие состояния, то есть сервисы запускаются по требованию и потенциально могут быть запущены столько экземпляров приложения, сколько требуется для текущей нагрузки. Большинство поставщиков (GCP, Azure, Amazon и прочие) облачных решений предлагают также и доступ к хранилищам, включая файловые и блочные, а также объектные. Некоторые предлагают дополнительно облачные базы, так что приложение, рассчитанное на запуск в таком облаке, легко может работать с подобными системами хранения данных. Для того, чтобы все работало, достаточно оплатить вовремя эти услуги, для небольших приложений поставщики вообще предлагают бесплатное использование ресурсов в течение некоторого срока, либо вообще навсегда.

Из недостатков: могут заблокировать аккаунт, на котором все работает, что может привести к простоям в работе. Также могут быть проблемы со связностью и\или доступностью таких сервисов по сети, поскольку такие хранилища полностью зависят от корректной и правильной работы глобальной сети.

Заключение

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

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

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

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

Перед тем как начать подготовку к тестам, нужно понять какие задачи мы решим, чтобы достичь цели.

Задачи

1. Оценить минимальную задержку обработки операций. Насколько быстро работает хранилище в идеальных условиях.
2. Оценить максимальную глубину очереди операций до достижения лимитов. Как только производительность клиента начинает деградировать из-за достигнутых лимитов это и есть максимальная глубина очереди.
3. Оценить предельное количество одновременно работающих максимально эффективных клиентов до начала деградации производительности.
4. Оценить скорость деградации кластера при большом количестве клиентов.

Подготовка

Клиенты

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

Идеально, если можно создать реальную, а не синтетическую нагрузку. Менее идеально, но тоже очень хорошо знать профиль нагрузки для создания синтетических тестов на его основе. Так, например, поступили ребята из Facebook при тестировании дисков.

Лимиты

Определиться с лимитами на клиентские операции нужно еще до начала тестирования. Любая система должна иметь лимит на пользовательские операции, в ином случае обязательно найдется клиент, который поглотит все доступные ресурсы.

На хранилище может быть установлено два типа лимитов:

1. Лимиты на количество операций (IOPS).
2. Лимиты на количество переданных данных (MB/s).

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

Определяться с лимитами следует на этапе планирования, основываясь на потребностях клиента. Заданные лимиты во время тестирования производительности играют роль этакого SLO (Service Level Objective целевой уровень сервиса) на ресурсы это граничные пределы, в которых клиенты будут работать. Эти же лимиты послужат ограничениями, в пределах которых проводятся тесты.

Набор тестов

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

В качестве основного инструмента используется FIO. Фактически это индустриальный стандарт для тестирования блочных устройств. FIO запускается внутри VM. В роли тестового файла выступает файл, расположенный в корневой файловой системе. Мы делаем так, чтобы учесть нюансы работы стандартной для многих файловой системы ext4, включая работу журнала. Все остальные параметры теста касаются настроек FIO.

Мы отталкиваемся от предположения, что наиболее требовательный к задержкам клиент будет работать с диском синхронно. Значит, что на каждую операцию записи будет поступать операция синхронизации кеша(flush). И только дождавшись завершения такой операции, клиентское ПО будет считать запись успешной. Так работают, например, классические БД с WAL (Write-Ahead Log).

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

В таких тестах лучше всего не брать в расчет кеш страниц гостевой ОС. Это слой, который нам не нужен, так как мы тестируем хранилище, которое предоставляет диск виртуальной машине, а не скорость записи в кеш или чтения из него. В то же время мы используем библиотеку libaio, как наиболее популярную среди требовательного к скорости работы дисков ПО, а она для адекватной работы требует флага O_DIRECT при открытии файла, чтобы миновать кеш страниц.

Запись и чтение тестируются разными размерами блока 4КиБ и 4МиБ. Маленький размер блока позволяет нагрузить кластер большим количеством операций, а большой объемом передаваемых данных. Так мы проверяем его работу в двух крайностях. Можно добавлять и промежуточные варианты размеров блока, так как различное ПО оперирует разным размером блока.

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

Статистика

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

Понадобится статистика со всех элементов системы:

• гипервизоров,
• серверов хранилища,
• самого софта,
• сетевого оборудования.

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

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

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

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

1. Авария вызвана нагрузкой. В таком случае хорошо, что мы получим оповещение и сможем выявить узкие и проблемные места перед запуском.
2. Авария не вызвана нагрузкой. В таком случае хорошо, что мы сможем остановить тестирование и запустить его заново после устранения аварийной ситуации.

В любом случае сбор статистики поможет корректно интерпретировать результаты тестов, а мониторинг позволит уменьшить время, потраченное на тестирование.

Окружение

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

Примеры того, что нужно собрать:

• версия ОС;
• версия ядра;
• версия используемых драйверов;
• версия софта хранилища;
• модель, количество и частота процессоров;
• модель, количество, объем и частота оперативной памяти;
• модель материнской платы;
• модель сетевых карт и сетевая топология;
• модель и количество дисков;
• количество хостов в кластере;
• количество гипервизоров;
• количество и характеристики VM.

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

Тестирование

Пустой кластер

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

Заполнение

На этом этапе нужно знать целевую заполненность кластера. Понятно, что очень редко кластер с данными заполняется на 99-100%, ведь в этом случае его становится практически невозможно обслуживать и разработчиками наверняка неосознанно заложены дополнительные спецэффекты на такой случай. Поэтому, с учетом экономики проекта, нужно заранее определить целевой процент заполненности кластера, который не стоит превышать, но до которого система будет заполнена данными.

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

Первый тест

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

Оценка задержки

Для оценки минимальной задержки используется тест на синхронную случайную запись с глубиной очереди 1, запускаемый на одном клиенте. После этого проводится такой же тест на чтение. В результате мы узнаем скорость работы хранилища в идеальных условиях для одного клиента. Этот показатель будет ориентиром во всех будущих тестах. По отклонению значения задержки (latency) операции от этого значения можно будет оценить деградацию производительности.

Выбор эталонной глубины очереди

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

1. Cкорость обработки каждой операции.
2. Количество параллельно выполняемых операций.

С точки зрения клиента мы не можем повлиять на скорость обработки конкретных операций, но можем увеличивать параллелизм. Следовательно, максимально эффективный клиент, это тот клиент, который использует максимальный параллелизм при работе с диском, при этом укладывается в доступные ему ресурсы (IOPS / MB/s). Это значит, что для поиска такого клиента нам нужно запускать каждый тест из набора с разной глубиной очереди. В результате мы получим информацию о том, на какой глубине очереди каждый из тестов работает наиболее эффективно.

По результатам тестов нужно строить графики, показывающие распределение latency и IOPS. Задача найти такую глубину очереди, при которой распределение задержки еще не растет, при этом показатели IOPS или MB/s уже находятся максимально близко к заданному лимиту. Максимальная эффективная глубина очереди для тестов с разными параметрами может отличаться. Берем ее за эталон для тестов и используем на следующем этапе. Это и есть наши самые эффективные клиенты.

Тестирование кластера

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

По результатам нужно дать оценку для каждого теста:

1. Максимальное количество максимально эффективных клиентов до деградации производительности кластера.
2. Скорость деградации производительности при дальнейшем росте количества клиентов.

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

Сопровождение процесса

Подконтрольный запуск

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

1. Тест упал сразу после запуска по причине неправильной конфигурации.
2. Тест упал в середине работы из-за нехватки какого-либо ресурса.
3. Тест частично упал или частично не запустился.
4. Автоматизированные тесты наложились один на другой.

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

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

Узкие места

Во время и после тестов, важно внимательно изучать статистику состояния ресурсов и промежуточные результаты тестов. Популярная ошибка это запуск большого количества тестов последовательно, не глядя на результаты. В таком случае часто случается:

1. Клиенты конкурировали за локальный ресурс. Например, CPU гипервизора.
2. Локальные перегрузки на сети из-за неудачной балансировки.
3. Что угодно, что могло быть замечено в процессе теста или сразу после первого прогона и влияет на результат.

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

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

Документирование

Необходимо документировать все. Все успешные результаты тестов должны сохраняться на будущее в исходном формате. Это даст возможность повторно построить какие-то графики в будущем, если возникнет такая необходимость.

Структуру хранения результатов так же стоит продумать заранее, она не должна сильно изменяться в будущем. Например, разделить по каталогам по номеру задачи, с подкаталогами по названию теста, далее по количеству клиентов, а ссылки на задачи держать в Wiki. Четкая структура сильно облегчает обращение к историческим данным, например для построения сравнительных графиков нескольких кластеров.

Интерпретация результатов

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

Если же с увеличением количества клиентов добиться деградации качества обслуживания не удалось, то возможно стоит подумать над увеличением лимитов.

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

1. Утилизация CPU, как на хостах хранилища, так и у клиентов. Нужно смотреть не только общую нагрузку, но и распределение нагрузки по ядрам, отсутствия длительного ожидания в очереди на CPU. Что происходит, когда система начинает деградировать? Не ошибка ли это в выборе железа или количества сервисов на хост? Или CPU тратит время в ожидании какого-то ресурса?
2. Утилизация и перегрузка сети. Раз мы работаем с сетевым хранилищем, то стоит посмотреть, не оказалась ли сеть бутылочным горлышком. Потери пакетов, ошибки и утилизация основные параметры.
3. Утилизация и latency дисков. Опять же это ведь хранилище. В идеальном мире самым медленным элементом системы должен быть конечный элемент. Т.е. не должно быть узких мест, система должна быть настроена так, чтобы реализовать потенциал дисков. В реальности, во-первых, нужно опять-таки учитывать профиль нагрузки, а во-вторых, реализовать потенциал дисков иногда невозможно.

По каждому из этих пунктов можно написать отдельную статью, или даже книгу, поэтому нужно понимать, что это лишь вводные, с которых можно начать.

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

В итоге

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

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

1. Собираем статистику и подключаем мониторинг. Эти две вещи сэкономят время на тестировании и помогут с интерпретацией результатов.
2. Описываем окружение и чем точнее, тем лучше.
3. Перед запуском тестов определеяемся с целевым заполнением кластера и заполняем его данными до этой отметки, если это возможно. Необходимость в этом зависит от используемой системы и временных затрат.
4. Перед любыми тестами проводим инициирующую запись, чтобы получить реальное значение производительности, которое будет у активных клиентов.
5. Делаем простой тест для определения скорости работы хранилища в идеальных условиях. После этого, проводим поиск максимально эффективного клиента, последовательно увеличивая глубину очереди. Когда такой клиент найден, запускаем тестирование кластера, прогоняя тесты с одновременной работой нескольких максимально эффективных клиентов, количество которых последовательно увеличиваем.

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

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

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

Полезные ссылки:

• Ceph
• FioSynth: A representative I/O benchmark and data visualizer for data center workloads
• fio Flexible I/O tester
• Блог автора этой статьи