Но даже если нам удастся повторить конфигурацию скалакси, конечно же это не пойдёт в продакшен.
Да и честно сказать, у нас нет столько бюджета и железок, чтобы строить нечто подобное.
SRP вполне реально использовать в «локальной» виртуализации, без строгих рамок отказоустойчивости.
В тех местах, где скорость важнее.
Спасибо!
Правда, Ваш ответ несколько перевернул моё представление об SRP.
Не могли бы вы дать ссылочку, где почитать про тонкую настройку SRP (SCST)?
На какой операционке изначально SCST разрабатывался? с какой лучше всего совместим?
Как, всё таки, организовать подключение к одному таргету(луну)(SCST) больше одного инициатора? (почитать, или если несложно на пальцах)
Большое спасибо за ссылку.
Теперь всё встало на свои места.
У вас замечательный проект.
Если позволите, ещё пару вопросов по SRP.
В терминологии той статьи:
VRT (ViRTualization) — бездисковые серверы виртуализации, на которых запущены клиентские виртуальные машины.
IBRP (IB Raid Proxy) — прокси-серверы системы хранения, задача которых обслуживать рейды.
IBRN (IB Raid Node) — узлы системы хранения, в которых находятся диски и кэши.
Как я понимаю, основной принцип построения не изменился и сегодня?
Тогда возникает вопрос — SRP(SCST) — это соединение «точка — точка», нельзя подключить к одному таргету(луну) несколько инициаторов. (или я не прав?)
Возьмём один IBRN, создадим на нём несколько SCST лунов, по количеству дисков, или массивов, если используются контроллеры.
Возьмём ещё один IBRN, и сделаем то же самое.
Возьмём IBRP, и подсоединим к нему наши луны с обоих IBRN через SRP. (вероятно, можно же запустить несколько инициаторов на одном сервере?)
Теперь соберём с помощью md массив 1 + 0 из из присоединённых лунов.
И разобьём с помощью LVM, получившийся диск, как нам нужно.
Итого: мы получили связку IBRP + 2 IBRN.
Теперь, повторим процесс нужное количество раз в формате 1 + 2, и получим несколько таких связок. (IBRP + 2 IBRN)
(надеюсь, до этого момента, я рассуждал правильно)
Теперь возьмем любой из наших IBRP и создадим на нём лун(SCST) из… из чего? (из локальной LVM группы? из отдельного тома?)
Сделаем то же самое на всех IBRP.
Возьмём VRT, и подсоединим его ко всем нашим IBRP по SRP. (точнее настроим multipath, чтобы VRT, в каждый момент времени видел только один IBRP)
Создадим виртуалку на VRT, в качестве диска укажем ей диск LVM на IBRP? или просто положим образ виртуалки на LVM раздел?
А теперь представим, что IBRN выключился по питанию… ОК, ничего страшного, у нас же массив, никто и не заметит.
А если выключился IBRP? Он ведь был единственной связующей точкой межу VRT и парой IBRN. Информация недоступна, как быть?
Значит должна быть некая репликация, но где она?
Подключить к каждой паре IBRN каждый IBRP мы не можем, SRP нам не даст подключить несколько инициаторов к одному таргету?
Сделать репликацию на уровне IBRP между собой? (и чем? кластерной FS?) Но это ещё как минимум в 2 раза снизит количество полезной ёмкости хранилищ.
Сделать некий механизм переключения SRP подключений и LVM? (например IBRP#1 был подключен к IBRN#1 и IBRN#2, IBRP#1 выключился, IBRP#2 автоматически подключается к IBRN#1 и IBRN#2 и настраивает у себя корректно md и LVM ?) (а мониторинг реализовать на основе fencing ?)
В общем главный вопрос, по сути — как же реализовать отказоустойчивость IBRP? (или я, просто, как-то неправильно понимаю всю схему работы SRP с прокси?)
Дело в том что был похожий проект, правда без миграции «на лету», и полученные данные по скорости и стабильности, прямо сказать, не впечатлили…
Наш кластер делался следующим образом:
Оборудование:
Supermicro
корзины со свитчами Infiniband QDR
лезвия с mezzanin Infiniband QDR
несколько Qloqic 12300 в качестве SM менеджеров.
Платформа:
Ovirt 3.3-3.5,
с поддержкой GlusterFS (с поддержкой RDMA)
Операционки для нод — Centos6.5
Драйверы: Mellanox, OFED, нативные.
Как видно, конфигурация очень похожая.
Было решено, что RDMA и IPoIB смешивать не стоит, одно другому не нужно.
(fail 1)
От идеи сразу же пришлось отказаться, дело в том что GlusterFS, создаёт свой RDMA кластер именно на основе IP адресов нод… Ovirt не поддерживает RDMA нативно, точнее никак не поддерживает, даже с трудом живёт с Infiniband интерфейсами, потому как создать мост между Ethernet и Infiniband он не может, да и созданный вручную, такой мост нормально не работает…
Тогда решили, пусть ноды живут через IPoIB, и GlusterFS пусть работает так же.
(fail 2)
Увы, тест с глубиной очереди хотя бы в 20 разрывал этот кластер (даже на соседних лезвиях в одной корзине), и он попросту разваливался, поэтому от хранения образов виртуалок в GlusterFS'е решено было отказаться…
ОК, решили построить SAN на базе сервера с несколькими QDR картами, и да, здесь был частичный успех, SRP заработал, но таргет удалось реализовать только на Debian7 с паченым/перепаченым ядром (SCST), и с инициатором было не меньше проблем — приходилось подгонять время инициирования подключения после ребута сервера, вручную.
Правда оно того стоило, icsci через RDMA без использования IP, скорость обращения к локальному SSD в лезвии и к такому же на таргете (такому же лезвию где-то в Infiniband сети), сравнялась.
(fail 3)
Но и тут ждало разочарование:
Одновременное подключение к одному таргету невозможно. Поэтому прицепить ферму виртуализации к такому SAN не получится (только одну ноду). Ovirt, не умеет работать с SRP, да с ним ничего не умеет нативно работать, поэтому настроить автоматическое пере подключение другой ноды, при падении подключенной, средствами Ovirt'a нельзя.
Отказоустойчивость реализуется только на стороне таргета, между Infiniband портами.
Параллельно решили по тестировать пропускную способность Infiniband QDR 40Гб/сек (в теории).
Тестовый стенд:
2 лезвия, Haswell + 128GB RAM + SSD + Infiniband QDR (mezzanin), в одной корзине, свитч в корзине QDR (упираться не во что).
После несчётных переустановок и тюнинга драйверов, результаты приблизительно следующие:
Ещё мы прорабатывали варианты с Proxmox/Cepf, OpenNebula/GlusterFS, XEN…
И везде всё то же самое:
«RDMA — нет не знаем»
«Infininiband — нет не поддерживаем»
«Ждите, может быть когда-нибудь»
В итоге:
1. Да, IPoIB.
2. Ноды видят друг друга и SANы через IPoIB.
3. На каждой ноде есть Ethernet интерфейс, виртуалки сбриджены к ним.
4. Роутеры Ethernet/Infiniband сервера с QDR картами, маршрутизация на уровне IP.
5. Работает, но 10Гб/сек при очень хорошей погоде в вакууме…
Возможно мы просто не умеем готовить Infiniband, но мне кажется, дело не только в этом…
Буду очень благодарен, если вы найдёте время прочесть это, и что-нибудь ответить, подозреваю, вы тоже сталкивались с подобными проблемами при построении своего облака.
Интересная статья. Но если честно, неочень информативная.
Если это не коммерческая тайна, не могли бы вы описать чуть подробнее:
1. Архитектуру вашей виртуализации (название платформы), поддерживает ли она уже сейчас RDMA без IPoIB?
2. Возможно вы используете некую кластерную FS, с поддержкой RDMA? если да, то какую?
3. Как вы измеряли пропускную способность FDR на вашем оборудовании, откуда взялась цифра в 5 раз?
4. Какое конечное оборудование используется?
5. Что выступает SM manager'ом? Коммерческая или openSM реализация? Как решена проблема отказоустойчивости SM?
6. Какие операционные системы и драйверы Infiniband используются(Mellanox или OFED)?
7. Какое SAN хранилище(а) у вас используется, интегрировано ли оно в виртуализацию? по RDMA (возможно SRP или iSER) или IPoIB(NFS)?
Увы без подробностей, это только красивая история… Спасибо.
Действительно процедура как мне кажется слишком длинная и сложная как для пользователей так и для сайта. Думаю, что абсолютное большинство размещающих объявления будут выбирать вариант без комментариев. Тот кто хочет что-то скрыть о продаваемом авто, от комментариев откажется и всё равно будет убеждать что машина в идеальном состоянии а комментарии он не включил т.к забыл, не знал и.т.п
И слабо представляю ситуацию когда покупатель проехал 300км, отказался от покупки выяснив что продавец обманул его, а продавец ещё согласиться с ним на пару рядом с авто сфотографироваться для доказательств.
И главное, что мешает после негативного отзыва удалить объявление и разместить заново с чистого листа?
Думаю такие комментарии невозможно будет нормально модерировать. Ведь проверить достоверность таких комментариев практически невозможно. Те же перекупщики будут писать кучу гадостей о машине. В итоге может получится, что честный человек разместит объявление о продаже хорошего автомобиля и получит кучу негативных комментариев от конкурентов продающих аналогичные авто, и перекупщиков которые хотят сбить цену.
Но даже если нам удастся повторить конфигурацию скалакси, конечно же это не пойдёт в продакшен.
Да и честно сказать, у нас нет столько бюджета и железок, чтобы строить нечто подобное.
SRP вполне реально использовать в «локальной» виртуализации, без строгих рамок отказоустойчивости.
В тех местах, где скорость важнее.
Правда, Ваш ответ несколько перевернул моё представление об SRP.
Не могли бы вы дать ссылочку, где почитать про тонкую настройку SRP (SCST)?
На какой операционке изначально SCST разрабатывался? с какой лучше всего совместим?
Как, всё таки, организовать подключение к одному таргету(луну)(SCST) больше одного инициатора? (почитать, или если несложно на пальцах)
Ещё раз, большое спасибо!
Теперь всё встало на свои места.
У вас замечательный проект.
Если позволите, ещё пару вопросов по SRP.
В терминологии той статьи:
VRT (ViRTualization) — бездисковые серверы виртуализации, на которых запущены клиентские виртуальные машины.
IBRP (IB Raid Proxy) — прокси-серверы системы хранения, задача которых обслуживать рейды.
IBRN (IB Raid Node) — узлы системы хранения, в которых находятся диски и кэши.
Как я понимаю, основной принцип построения не изменился и сегодня?
Тогда возникает вопрос — SRP(SCST) — это соединение «точка — точка», нельзя подключить к одному таргету(луну) несколько инициаторов. (или я не прав?)
Возьмём один IBRN, создадим на нём несколько SCST лунов, по количеству дисков, или массивов, если используются контроллеры.
Возьмём ещё один IBRN, и сделаем то же самое.
Возьмём IBRP, и подсоединим к нему наши луны с обоих IBRN через SRP. (вероятно, можно же запустить несколько инициаторов на одном сервере?)
Теперь соберём с помощью md массив 1 + 0 из из присоединённых лунов.
И разобьём с помощью LVM, получившийся диск, как нам нужно.
Итого: мы получили связку IBRP + 2 IBRN.
Теперь, повторим процесс нужное количество раз в формате 1 + 2, и получим несколько таких связок. (IBRP + 2 IBRN)
(надеюсь, до этого момента, я рассуждал правильно)
Теперь возьмем любой из наших IBRP и создадим на нём лун(SCST) из… из чего? (из локальной LVM группы? из отдельного тома?)
Сделаем то же самое на всех IBRP.
Возьмём VRT, и подсоединим его ко всем нашим IBRP по SRP. (точнее настроим multipath, чтобы VRT, в каждый момент времени видел только один IBRP)
Создадим виртуалку на VRT, в качестве диска укажем ей диск LVM на IBRP? или просто положим образ виртуалки на LVM раздел?
А теперь представим, что IBRN выключился по питанию… ОК, ничего страшного, у нас же массив, никто и не заметит.
А если выключился IBRP? Он ведь был единственной связующей точкой межу VRT и парой IBRN. Информация недоступна, как быть?
Значит должна быть некая репликация, но где она?
Подключить к каждой паре IBRN каждый IBRP мы не можем, SRP нам не даст подключить несколько инициаторов к одному таргету?
Сделать репликацию на уровне IBRP между собой? (и чем? кластерной FS?) Но это ещё как минимум в 2 раза снизит количество полезной ёмкости хранилищ.
Сделать некий механизм переключения SRP подключений и LVM? (например IBRP#1 был подключен к IBRN#1 и IBRN#2, IBRP#1 выключился, IBRP#2 автоматически подключается к IBRN#1 и IBRN#2 и настраивает у себя корректно md и LVM ?) (а мониторинг реализовать на основе fencing ?)
В общем главный вопрос, по сути — как же реализовать отказоустойчивость IBRP? (или я, просто, как-то неправильно понимаю всю схему работы SRP с прокси?)
Дело в том что был похожий проект, правда без миграции «на лету», и полученные данные по скорости и стабильности, прямо сказать, не впечатлили…
Наш кластер делался следующим образом:
Оборудование:
Supermicro
корзины со свитчами Infiniband QDR
лезвия с mezzanin Infiniband QDR
несколько Qloqic 12300 в качестве SM менеджеров.
Платформа:
Ovirt 3.3-3.5,
с поддержкой GlusterFS (с поддержкой RDMA)
Операционки для нод — Centos6.5
Драйверы: Mellanox, OFED, нативные.
Как видно, конфигурация очень похожая.
Было решено, что RDMA и IPoIB смешивать не стоит, одно другому не нужно.
(fail 1)
От идеи сразу же пришлось отказаться, дело в том что GlusterFS, создаёт свой RDMA кластер именно на основе IP адресов нод… Ovirt не поддерживает RDMA нативно, точнее никак не поддерживает, даже с трудом живёт с Infiniband интерфейсами, потому как создать мост между Ethernet и Infiniband он не может, да и созданный вручную, такой мост нормально не работает…
Тогда решили, пусть ноды живут через IPoIB, и GlusterFS пусть работает так же.
(fail 2)
Увы, тест с глубиной очереди хотя бы в 20 разрывал этот кластер (даже на соседних лезвиях в одной корзине), и он попросту разваливался, поэтому от хранения образов виртуалок в GlusterFS'е решено было отказаться…
ОК, решили построить SAN на базе сервера с несколькими QDR картами, и да, здесь был частичный успех, SRP заработал, но таргет удалось реализовать только на Debian7 с паченым/перепаченым ядром (SCST), и с инициатором было не меньше проблем — приходилось подгонять время инициирования подключения после ребута сервера, вручную.
Правда оно того стоило, icsci через RDMA без использования IP, скорость обращения к локальному SSD в лезвии и к такому же на таргете (такому же лезвию где-то в Infiniband сети), сравнялась.
(fail 3)
Но и тут ждало разочарование:
Одновременное подключение к одному таргету невозможно. Поэтому прицепить ферму виртуализации к такому SAN не получится (только одну ноду). Ovirt, не умеет работать с SRP, да с ним ничего не умеет нативно работать, поэтому настроить автоматическое пере подключение другой ноды, при падении подключенной, средствами Ovirt'a нельзя.
Отказоустойчивость реализуется только на стороне таргета, между Infiniband портами.
Параллельно решили по тестировать пропускную способность Infiniband QDR 40Гб/сек (в теории).
Тестовый стенд:
2 лезвия, Haswell + 128GB RAM + SSD + Infiniband QDR (mezzanin), в одной корзине, свитч в корзине QDR (упираться не во что).
После несчётных переустановок и тюнинга драйверов, результаты приблизительно следующие:
Обе ноды: Centos6.3(включен SDP)(Mellanox 1.5.3|OFED 1.8)
OFED тесты = 16Гб/с
scp = 400 Мб/с!!!
NFS копирование = 6.5 Гб/с…
Обе ноды: Centos6.5(SDP больше не поддерживается)(Mellanox 2.2|OFED 3.12)
OFED тесты = 14.6Гб/с
scp = 330 Мб/с!!!
NFS копирование = 4.8 Гб/с…
Обе ноды: Centos6.5(нативный драйвер)
OFED тесты = 12Гб/с
scp = 290 Мб/с!!!
NFS копирование = 4.1 Гб/с…
Обе ноды: Windows2012 (Mellanox)
Копирование: 9.8Гб/с (среднее значение)
FreeBSD9.1 (нативно) / Windows2008 (Mellanox)
samba копирование = 7.5Гб/с (среднее значение)
Ещё мы прорабатывали варианты с Proxmox/Cepf, OpenNebula/GlusterFS, XEN…
И везде всё то же самое:
«RDMA — нет не знаем»
«Infininiband — нет не поддерживаем»
«Ждите, может быть когда-нибудь»
В итоге:
1. Да, IPoIB.
2. Ноды видят друг друга и SANы через IPoIB.
3. На каждой ноде есть Ethernet интерфейс, виртуалки сбриджены к ним.
4. Роутеры Ethernet/Infiniband сервера с QDR картами, маршрутизация на уровне IP.
5. Работает, но 10Гб/сек при очень хорошей погоде в вакууме…
Возможно мы просто не умеем готовить Infiniband, но мне кажется, дело не только в этом…
Буду очень благодарен, если вы найдёте время прочесть это, и что-нибудь ответить, подозреваю, вы тоже сталкивались с подобными проблемами при построении своего облака.
Извиняюсь за много букаф!
Если это не коммерческая тайна, не могли бы вы описать чуть подробнее:
1. Архитектуру вашей виртуализации (название платформы), поддерживает ли она уже сейчас RDMA без IPoIB?
2. Возможно вы используете некую кластерную FS, с поддержкой RDMA? если да, то какую?
3. Как вы измеряли пропускную способность FDR на вашем оборудовании, откуда взялась цифра в 5 раз?
4. Какое конечное оборудование используется?
5. Что выступает SM manager'ом? Коммерческая или openSM реализация? Как решена проблема отказоустойчивости SM?
6. Какие операционные системы и драйверы Infiniband используются(Mellanox или OFED)?
7. Какое SAN хранилище(а) у вас используется, интегрировано ли оно в виртуализацию? по RDMA (возможно SRP или iSER) или IPoIB(NFS)?
Увы без подробностей, это только красивая история… Спасибо.
И слабо представляю ситуацию когда покупатель проехал 300км, отказался от покупки выяснив что продавец обманул его, а продавец ещё согласиться с ним на пару рядом с авто сфотографироваться для доказательств.
И главное, что мешает после негативного отзыва удалить объявление и разместить заново с чистого листа?