Новая система хранения в облаке

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

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

    В момент, когда мы проектировали систему, а это был 2007 год, на рынке существовало 3 основных технологии для организации сетевых хранилищ: iSCSI по Ethernet 1/10 Гбит/с, FibreChannel 4 Гбит/с и Infiniband 40 Гбит/с. Проведя исследования, в том числе и по ценовым характеристикам, мы выбрали последний вариант с Infiniband. Это позволило нам использовать одну сетевую фабрику как для системы хранения, так и для передачи IP-данных. На первый взгляд это кажется странным, так как многие привыкли думать про Infiniband как об очень дорогой экзотичной технологии из мира суперкомпьютеров. Но простое сравнение цен показывает, что в данном случае Infiniband является очень экономичным.

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

    Касательно самих хранилищ, мы не нашли ни одного готового производительного решения способного работать с Infiniband; что-то было у LSI и DDN, но в очень сыром виде. Еще раз просчитав стоимость отказоустойчивых решений на базе iSCSI и FC, мы поняли, что по получившейся цене никто их покупать не будет.

    В тот момент к нашей компании присоединился Максим Лапань, имевший опыт работы с коммерческим продуктом фирмы IBM — кластерной файловой системой GPFS. Оказалось, что GPFS умеет напрямую работать с Infiniband, максимально задействуя все ее возможности, и имеет все инструменты для резервирования. Так и была создана первая версия системы хранения облака Скалакси. Использовались raid10 на узлах GPFS и двукратное резервирование самих узлов. Образы дисков виртуальных машин лежали в виде обычных файлов на GPFS.

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

    Мы стали думать над проблемой, пробовать разные решения. При этом, очень хотелось уйти от проприетарных и непредсказуемых технологий. Наткнулись на VastSky, разработку VA Linux Systems. Ее архитектура была очень похожа на то, к чему двигались мы — использование device-mapper драйвера для работы с пользовательскими образами. LVM также работает на базе этого драйвера и является по сути его управляющей утилитой. Однако VastSky еще не готов к использованию в продакшн системах.

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

    image

    В нашем облаке существует три типа серверов:

    VRT (ViRTualization) — бездисковые серверы виртуализации, на которых запущены клиентские виртуальные машины.
    IBRP (IB Raid Proxy) — прокси-серверы системы хранения, задача которых обслуживать рейды.
    IBRN (IB Raid Node) — узлы системы хранения, в которых находятся диски и кэши.

    Фото стойки c IBRN спереди:

    image

    Сзади:

    image

    Фото Infiniband свитча:

    image

    Работает это все следующим образом:

    — IBRN экспортируют свои диски по Infiniband SRP (SRP — SCSI over RDMA Protocol) используя драйвер SCST с кэшированием, самый быстрый открытый драйвер SCSI-таргетов. SCST вообще хорошая штука, её нам посоветовал все тот же Максим Лапань; разрабатывают ее русские парни. Она позволяет из любой коробки с Linux сделать хранилище уровня «энтерпрайз».
    — IBRP получают диски от IBRN, для каждой пары IBRN собирают raid10 с помощью md, чей код мы тщательно выверили на работоспособность в конкурентных условиях, создают на этом рейде LV-группу и экспортируют его опять через SCST уже без кэширования.
    — VRT получают диски от всех IBRP, драйвер multipath создает из них round-robin группу, таким образом распределяя нагрузку по всем IBRP.
    — При создании нового диска на одном из IBRP выполняется команда lvcreate, запоминается таблица device-mapper для созданого тома, через device-mapper устройство создается уже на VRT и отдается в Xen.
    — I/O операции на запись из клиентской виртуальной машины доходят до IBRP, попадают в md, md делает запись на обе IBRN и только после этого возращает наверх ответ о том, что операция прошла успешно. Таким образом, при падении любого узла I/O операция в клиентской машине обработается корректно.

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

    Далее мы составили список сценариев тестирования этой системы на отказоустойчивость и многократно их провели, ниже результаты:

    1. Зависание IBRN или падение по питанию.

    Тесты пройдены успешно. На некоторое время I/O на клиентских машинах замораживается, пока не сработает таймаут дисков на IBRP. Далее md на IBRP отключает диски упавшей IBRN и продолжает работу. После восстановления IBRN синхронизация md проходит успешно в течение суток.

    2. Остановка IBRN выгрузкой SCST драйвера.

    Тесты пройдены успешно. Ход событий аналогичен предыдущему тесту, только без таймаута.

    3. Зависание IBRP или падение по питанию.

    Тесты успешно пройдены. По таймауту разрывается SRP-сессия, и multipath на VRT удаляет путь. На клиентских машинах все I/O замораживается на время таймаута multipath.

    4. Остановка IBRP выгрузкой SCST драйвера.

    Тесты успешно пройдены. После выгрузки SCST корректно разрывается SRP-сессия, и multipath на VRT сразу помечает путь как failed. Для клиентов все выглядит прозрачно и без таймаутов.

    5. Сбойный диск в IBRN (выдергиваем диск на горячую).

    Тесты успешно пройдены. Диск исчезает в IBRN, сыплются ошибки, также сыплются ошибки на IBRP, а md постоянно редиректит на зеркало. После вставки диска обратно, синхронизация md проходит успешно в течение суток.

    6. Перезагрузка Infiniband свитча.

    Тесты успешно пройдены. Свитч отключался по питанию на пару секунд и включался обратно. При перезагрузке наблюдалось: падение и поднятие IB-линков, разрыв и восстановление SRP-сессий, временное падение путей multipathd на VRT. Клиентское I/O замораживается на время перезагрузки.

    7. Одновременное падение IBRP и IBRN.

    Тесты успешно пройдены.

    8. Одновременная остановка пары IBRN выгрузкой SCST драйверов.

    Тесты успешно пройдены. В ходе теста пара IBRN была остановлена, перезагружена и введена обратно в строй. Все это время I/O клиентских машин было заморожено, после окончания теста все клиентские машины разморозились, I/O операции возобновились. Вывод — одновременную остановку пары IBRN можно производить для обслуживания физических серверов IBRN в регламентное окно (с 2 ночи до 6 утра).

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

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

    Те, кто уже сейчас хочет проверить новую систему хранения, могут клонировать свои имеющиеся серверы (все новые диски создаются на новой системе), либо подождать до следующей недели, когда мы проведем окончательную миграцию. Тем, у кого еще нет серверов в Скалакси, самое время их завести, при регистрации для тестирования доступны 150 рублей.
    Оверсан
    39,05
    Компания
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 80

      +1
      Сколько у Вас всего IBRN? Секрет? :-)
        +3
        Несколько десятков.
        +2
        Скалакси больше не ведет свой блог? Или эта СХД к Скалакси не имеет отношения?
          0
          Скалакси — проект компании Оверсан.
            +1
            Ну это понятно. Вопрос в другом, СХД создавалось для Скалакси или для общих нужд Оверсан и Оверсан-Скалакси?
              0
              Для Скалакси.
            +3
            Оба блога Скалакси и Меркурия уже давно склеили в один, далее все новости и события будут только тут.
            +1
            www.oracle.com/us/products/servers-storage/sun-zfs-storage-family-ds-173238.pdf
            А это не рассматривали?
            Младшие модели стоит 10/20 тысяч долларов (с дисками).
            Старшие не могу сказать сколько, но в ней есть все!
            Компрессия, дедубликация, репликация, кластеризация, Infiniband из коробки и т.п.
              0
              Что бы эта штука стала действительно производительной нужно купить кэшей + желательно SSD кэшей и тогда оно становится дорогой.
                0
                Да, но в других системах вот это все есть? Компрессия? Dedup? Snapshotting (для хот бекапа незаменимо)?
                  +1
                  Снапшоттинг есть в lvm. Остальное гасит производительность. Бесспорно NetApp, EMC и другие системы хранения хороши, но их розничная стоимость столь высока, что мы как продавцы облачного хостинга вылетим с рынка. Объемы же российских заказов сегодня такие, что рассчитывать на закупку крупным оптом для получения нормальных скидок не приходится.
                    +2
                    А ваш мегасвич, если не секрет, сколько стоит?

                    Самое большое ib-оборудование, которое мне доводилось использовать, было циской на 128 DDR портов.

                    (Зато с ним шел цисковский ультрапроприетарный и инфернальнонадежный сабнет-менеджер, под который циска заставляла ставить два отдельных сервера, без всяких «но»)
                      +1
                      Около 6 млн рублей.
                      +1
                      Как человек «близкий к телу» могу вам сказать, что, допустим, NetApp сейчас очень интересны задачи, подобные решаемой вашей компанией, то есть облачный хостинг, так как в мире они довольно неплохо в нем представлены (тот же rackspace или yahoo, например), а в России — пока нет.
                      А раз так, то возможны очень, очень значительные скидки на такие как ваши применения.

                      Не спорю, вы проделали интереснейшую и нужную работу, особенно интересно будет, если вы сможете опубликовать подробности. И, надеюсь, поставленным задачам ваша система соответствует, а «делать новое» всегда интереснее чем «вливать мешок бабла» и покупать готовое.

                      Но если когда-нибудь вам в будущем будет интересен NetApp, то не стесняйтесь спрашивать. Цены на ваши задачи будут совсем-совсем не «по прайслисту». :)
                      Может быть и попадем в ваш бюджет. Тем более, повторюсь, нетаппу это направление очень интересно и важно и самому.
                        0
                        Пообщаемся? Напишите в личку свои контакты.
                          0
                          Передал заинтересованным людям.
                          А в СПБ с нетаппом по близкой тематике работает IT-Град, возможно вы их даже знаете. У них и оборудование в демо должно быть.
                      0
                      В NetApp все это есть. Все это и многое другое, что еще пока не скопировано в ZFS ;)
                      0
                      К тому же ZFS сама по себе намного шустрее работает и с кешем обращается лучше, чем многие иные FS.
                        +2
                        FS в нашем случае лишнее, нам нужен блочный доступ. Любая FS, даже ZFS, будет давать падение производительности. К тому же это опять проприетарное и непредсказуемое по/железо. Уж лучше тогда проверенные NetApp или EMC.
                    0
                    > нам удалось получить более 120 тысяч IOPS на запись с пары IBRN

                    Вы не сказали главное, на каком паттерне доступа и при каком размере блока.
                    А так — ну 120 тысяч IOPS. Видали и побольше, и не на Infiniband.

                      –1
                      Мы все подробно расскажем в следующем посте, когда опубликем тесты производительности дисковых систем разных облачных хостеров. 120Kiops — 4kb блоки, random write.
                        0
                        Каков был объем тестировочного блока данных по отношению к общей емкости хранилища?
                          +2
                          Поясню вопрос. От размера тестируемого объема сильно зависит результат в IOPS. На маленьком объеме можно достичь весьма высоки результатов даже без «революций».
                          Вот пример на системе 8-летней давности, на одном 4Gb FC, на 10 дисках и 2GB cache, при 8GB тестируемой области на паттерне OLTP Database (4KB block, 70/30 read/write, 100% random)



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

                          А так — 50K IOPS это «скорость провода» одного уже повсеместного, и все более дешевого 8Gb FC.
                          То есть 120K IOPS это всего лишь полностью загруженные 3 канала FC.
                          Стоило ли городить огород с инфинибендом? Пока, из вашего рассказа — неясно в чем цимес. Замах на рубль — удар на копейку, говорилось в моем детстве голозадом. :)
                            0
                            Целью это разсказа было показать, как именно устроена наша новая система хранения. Тесты на производительность, как я уже сказал, мы опубликуем в следующих постах, вместе с методикой.

                            3 загруженных канала FC, 3 порта в FC свитче, три оптических кабеля = $$. Infiniband делает все это в одном линке, также успешно справляясь с IP-траффиком и миграциями vm между вычислительными узлами, а стоимость порта у него не выше стоимости 1 порта FC.
                              0
                              Обратите внимание, что у Infiniband все совсем не так радужно, как обещают вендоры IB-оборудования.
                              chelsio.com/assetlibrary/Eight%20myths%20about%20InfiniBand%20WP%2009-10.pdf

                              Что, впрочем не означает автоматически, что все радужно у 10GB Ethernet, например. Но в случае 10GBE как-то больше перспектив пока видится.
                                0
                                Существуют ровно такие же документы с противоположными утверждениями. Я в этой ситуации верю прайсам, которые мы просчитывали с коллегами, и реальной практике использования вот уже на протяжении 2-ух лет. У 10GB никаких исправлений в плане архитектуры не было, это все тот же унылый Ethernet, перспективы исправиться есть только у 40GE и они уже воплощаются в жизнь.
                                0
                                Подскажите infiniband позволяет по одному подключению гонять разные протоколы? У Вас диски отдаются по scsi-rdma, а ip трафик между нодами ходит по IPoIB. Для IPoIB и RDMA используются  разные IB карточки или все через один порт подключения?
                                  0
                                  Все через один порт.
                          +1
                          GPFS поверх SRP выдавала, помнится, скорости в разы выше, чем GPFS самостоятельно использующая RDMA. Правда это решение было дико нестабильным — пришлось отказаться.

                          Не секрет, что и диски и ib куда быстрее дружат с блоками 0.5-2 мегабайта, а скорости при работе с блоками в 4кб получаются на порядок ниже. Вы не думали в сторону того чтобы использовать внутри виртуальных машин какую-нибудь ФС с большим размером блока?
                            0
                            Это не универсально, у нас ведь и Windows.
                              +1
                              Ну, виндовс — это вообще отдельная тема =)

                              А вот если ориентироваться не на массовую аудиторию (нагрузка от которой подозрительно кореллируется с графиком школьных каникул), а скажем на сопровождение крупных проектов, то можно ведь навязать в некоторых технических аспектах свои правила в пользу эффективности? В том числе отняв у клиента право принимать неверные технические решения?
                                +1
                                У нас при сопровождении проектов так и сделано, в плане неверных технических решений. Но нужно скорее всего и размер блока нижлежащего устройства менять, а это на всех клиентов подействует.
                                  +1
                                  Но массового потребителя можно ведь выделить в отдельную зону/зоопарк/домен «где жизнь течет совсем по иным правилам»? Одно облако под внятные проекты с деньгами и одно облачко под ширпотреб?
                            +3
                            > 6. Перезагрузка Infiniband свитча.
                            > Клиентское I/O замораживается на время перезагрузки.

                            А каким образом ведет себя при этом клиентское ПО, которое динамически создает свои обработчики (apache, как пример)? На сколько я могу понять по-логике, число процессов начнет расти, потребление памяти увеличиться… В итоге имеем — перерасход денег клиента за время простоя/перезапуска оборудования провайдера. Как Вы боретесь с этим? Или пока не сталкивались с такой проблемой?
                              +1
                              Это время равно минуте, и мы не будем перегруждать свитч. Здесь описана аварийная ситуация.
                              0
                              А каков процент попадания в кеш на СХДшках???
                                0
                                Пока они еще только запущены, то 90-95%, как заполнятся, можно будет получить более адекватную статистику.
                                  0
                                  Учитывая, что у большинста облачных хостеров состояние близко к «только запущены», тесты производительности дисковых система покажут, в основном, производительность сети и кэша.
                                    –1
                                    Это неверно, хранилища заполняются очень быстро. Мы будем проводить тестирование при полной загрузке пары IBRN.
                                      0
                                      Очень интересно, как вы снаружи можете определить заполняемость СХД у других хостеров? Утверждение «неверно» чем-то более весомым подкрепить сможете?
                                        –1
                                        Я уверен, что СХД rackspace или amazon заполнены достаточно, о своих же российских коллегах/конкурентах, которых мы будем тестировать, я знаю также достаточно.
                                          0
                                          Про rackspace и amazon возражений нет — учитывая их возраст и клиентскую базу, их реальная нагрузка более-менее близка к планируемой и является уже устоявшейся величиной.

                                          У российских коллег/конкурентов положение совершенно другое — по причине их молодости и холодности данного рынка вообще, востребованная сейчас мощность на порядки меньше установленной.
                                0
                                >— При создании нового диска на одном из IBRP выполняется команда lvcreate,
                                >запоминается таблица device-mapper для созданого тома, через device-mapper
                                >устройство создается уже на VRT и отдается в Xen.

                                То-есть на прокси и ксенах живет CLVM — верно?
                                  +2
                                  Нет, на Xen живет dm, а на прокси lvm, кластерный не нужен.
                                  0
                                  А что за сервера используются у вас для IBRN?
                                  Никогда раньше не видел что бы корзины для дисков были и спереди и сзади :)
                                  Даже после такой диковинки как Sun Fire X4500 где диски вертикально внутри корпуса, такое расположение кажется весьма интересным.
                                  0
                                  А что будет если IB-свитч поломается? Только не говорите, что это в принципе не возможно.
                                    +5
                                    Свитч модульный, хранилище подключено разными линками в разные модули (всего 9 модулей), 6 блоков питания, бэкплейн полностью пассивный. Соответственно может вылететь модуль, что легко будет пережито.
                                      0
                                      Т.е. вы хотите сказать, что у вас 1 модульный свитч? Выход из строя бекплейна хоть и редкая, но имеющая место штука.
                                        +1
                                        Шасси бывают двух видов, полностью пассивные и с активными компонентами. Активные шасси действительно время от времени могут выходить из строя (выгорел чип, кондер или еще что-нибудь). Данное шасси является полностью пассивным и представляет собой простую кремнивую пластину. Она может сгореть лишь при пожаре.
                                          0
                                          Ну, вообще-то, я говорил про пассивные компоненты. Был печальный опыт с 2-мя известными производителями оборудования, когда выходил из строя пассивный бекплейн. Хотя вопрос был больше о кол-ве коммутаторов :-)
                                            0
                                            Некоторые производители коммутаторов, в том числе известные, лгут о пассивности. Нужно просто осмотреть глазками. Те участки, где шасси действительно ненадежные естественно зарезервированны, например, коммутаторы и фаерволы Juniper, а также F5.
                                              0
                                              Ну я бы не стал так говорить, не думаю, что Во… ир единственная честная компания. Ладно время покажет… Главное удачи вам и бесперебойной работы.
                                        0
                                        а если корзина сломается? :)
                                          0
                                          Ответил в выше.
                                            0
                                            Ага :)
                                      0
                                      А правильно ли я понимаю, что вы ушли от использования GPFS??? Т.е. у вас каждая виртуальная машина лежит не на файловой системе образом, а на партиции/разделе?
                                        0
                                        Да, именно так.
                                          0
                                          А как на счет фрагментации свободных разделов (например когда виртуальные машины пересоздаются или удаляются) или вы экспортируете на IBRN образы, расположенные на файловой системе?
                                            0
                                            Все пространство с IBRN на IBRP объединяется в общую LVM группу, и выделением непосредственно места для клиентских образов занимается LVM на IBRP.
                                        +1
                                        Зачем тогда drbd есть, если можно два md запустить на разных машинах, экспортировав диски обоих серверов по iscsi? это проще чем drbd. конкуретные mdadm обязаны общаться, чтобы правильно собрать деградировавший массив, а они этого не умеют, потому что для этого не предназначены. или рядом сидит архитектор и разделяет?
                                          +1
                                          Рэйд восстанавливается только на одной машине.
                                            +1
                                            рассматривали ли вы split-brain сценарий разделения системы на две функционирующие половины, которые думают, что вторая половина умерла? в какой-то чудесный момент они могут встретиться. прорабатывали ли вы ситуации split-brain? если таковые невозможны, то почему?
                                              +1
                                              Промахнулся, ответ ниже.
                                          +2
                                          Split-brain возможен, если по какой-то причине (глюк в драйверах IB или SCST) на одной из проксей рэйд станет degraded, а на других нет. Сбойная прокси будет писать на одну половинку рейда, остальные на обе. В этот момент сработает мониторинг и инженер вручную выключит со всех проксей ту ноду, которая засбоила и введет ее обратно в строй. Никакие данные при этом не будут потеряны.

                                          Если такая ситуация будет случаться, то мы переключим политику multipath c round-robin на failover, что бы все I/O шло через один md, до тех пор пока он жив.
                                            +2
                                            узел с виртуалками получает данные с 2х проксей. одна из проксей считает, что одно из ее хранилищ сломалось, и работает (пишет и читает) только с одним из хранилищ. при этом вторая прокся считает, что оба хранилища рабочие. и работает (пишет и читает) с обоих из хранилищ. т.е. она может пытаться прочитать со второго хранилища то, что там должно быть, но чего нет в результате глюка на первой проксе. так? насколько я понимаю, теоретически оно может упасть за несколько секунд. раньше, чем любой из админов среагирует
                                            мы уже на такие грабли несколько раз наступали. если ты пытаешь софт одной направленности героически натянуть на процессы для которых он не предназначен что-то обязательно перечеркнет всю идею, возможно на последнем из этапов, когда ты уже вложился в это гиблое дело
                                              0
                                              Это очень хорошее замечание, спасибо. Подумаем как лучше это обработать.
                                                0
                                                В общем исправили уязвимость. На VRT серверах переконфигурировали multipath, что бы использовал failover алгоритм (переключаться, только при падении пути), балансировка путей рандомная, активный путь выбирается при запуске VRT сервера.

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

                                            Самое читаемое