Новая зонированная система хранения данных Clodo

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

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

    Базовым понятием новой СХД Clodo является «зона». Все облако мы разделили на «зоны», абсолютно независимые друг от друга. Зоны сравнительно невелики и содержат до 10 XEN-узлов (вычислительных серверов с ресурсами, которые используют виртуальные машины пользователей). Каждая зона имеет независимую от других систему хранения и передачи данных, свою систему кэширования.

    Состав зоны


    На схеме представлена архитектура одной зоны.


    Как видно из схемы, СХД подразумевает четыре уровня кэширования данных: по одному на пользовательской виртуальной машине и на вычислительном узле и два – на узле системы хранения.

    Архитектура узлов хранения подобрана так, чтобы оптимизировать самую сложную операцию – произвольную запись. Для того, чтобы чтение также выполнялось быстро, используется адаптивная версия технологии readahead.

    Характеристики СХД


    Ниже представлен график зависимости времени, в течение которого СХД выдерживает обращение на данной скорости от скорости обращения.



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

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

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

    Преимущества зонирования


    Разбиение всего облака на несколько зон имеет ряд преимуществ.

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

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

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

    Все новые виртуальные машины создаются на новой системе хранения данных. Часть старых клиентов уже также переведена на новую СХД. Постепенно будут переноситься и все остальные клиенты. Если вы — клиент Clodo и хотите перейти на новую систему, просто подайте заявку в техническую поддержку.

    В завершении мы хотели бы привести графики скорости дисковых операций. На графиках Clodo сравнивается с «обычным» облачным хостингом. Как и «обычный» хостинг, на время тестирования мы отключили шейпер, работающий в обычных условиях.



    P.S. Все желающие «переехать» на Clodo с «обычного» облачного или необлачного хостинга, могут рассчитывать на квалифицированную и бесплатную поддержку в настройке виртуального сервера и переносе данных.
    clodo.ru
    Компания

    Похожие публикации

    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

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

      +6
      А что такое «обычный облачный хостинг»? Отдельно взятый облачный провайдер, название которого не указывается или что?
        +11
        Это наверно Скалакси
        =))))))))
          +12
          Это как «обычный стиральный порошок». Никто их не видел, но сравнения хорошие.
          +1
          Существующие VPS'ы клиентов уже используют данную СХД или она только для новых?
            +1
            Все новые виртуальные машины создаются на новой системе хранения данных. Часть старых клиентов уже также переведена на новую СХД. Постепенно будут переноситься и все остальные клиенты. Если вы — клиент Clodo и хотите перейти на новую систему, просто подайте заявку в техническую поддержку.
              +4
              Клиент, хочу, подал :-)
                0
                пошел делать бекапы…
                  +2
                  Перед перенос мы делаем бэкап сами.
                    0
                    верю 100%, но бывают человеческий фактор, да и за последние пол года все равно бекапов нет у меня… *каюсь*
              0
              50 гигабайт в секунду на запись? Вы уверены?
              Также интересно, как быстро будет идти live-миграция между зонами. Диски тоже ведь нужно с зоны на зону мигрировать?
              Ну и инфинибэнд-коммутатор как, на каждой зоне свой?

              Вообще, технических подробностей тут так и не появилось толком, сплошной пресс-релиз (
                +4
                50 Гб/с это средняя скорость заполнения кеша через два Infiniband адаптера. Несколько Xen-нод вполне в силах дать такую нагрузку.
                Live миграция есть, естественно синхронизация дисков между зонами занимает некоторое время, но происходит достаточно быстро, всё по тому же Infiniband.

                Технические подробности скорее всего будут в следующих постах.
                  0
                  Мне сложно представить быструю синхронизацию 500Гб дисков и то, как это повлияет на клиентов на таргет-ноде (да и на соурс-ноде тоже). Это же очень, очень много рандомного чтения и записи именно на диски, а не в кеши.
                    +1
                    Линейного, но все равно много.
                      0
                      Да, прошу прощения, линейного.
                      0
                      Большой кеш на таргете сделан именно для сдерживания всплесков активности по I/O. Потом он с разумной скоростью скидывается на диски. Опять же вероятность таких всплесков на значительное время достаточно мала.
                        0
                        Даже 100Гб вряд ли влезет в кэш, не вытеснив оттуда всё и вся (хотя, конечно, зависит от ваших нод, может там четверть терабайта ОЗУ на каждой… Впрочем, графики говорят об обратном).
                        Держать образ диска ВМ целиком в кэше (или вообще держать часть только в кэше, пока она скидывается на диск) — это очень опасно, мне кажется. Малейший сбой, и клиент прощается с данными.
                        Также интересно, как при живой миграции машины между зонами это выглядит с т.з. мигрирующего инстанса. Чтение/запись не проседают, изменения (попадающие в кэш на старой ноде?) корректно дописываются?

                        Конечно, стоило бы дождаться хоть каких-то технических подробностей, но уж очень интересно.
                          +2
                          Live миграция между зонами в жизни VPS не должна происходить часто, только при кардинальной смене поведения на долгое время и только если мешает жить другим. Да, это дорогая и не быстрая операция, статистически такое происходит крайне редко. Скорость I/O при этом падает, но не более 50% в худшем случае.

                          Что бы не потерять данные из кешей мы делаем репликацию. И, как видно из графика, при наступлении голодания по кешам производительность хранилища упадёт на некоторое время. Чудес, как известно не бывает, но мы старались сделать жизнь лучше для среднего, наиболее вероятного случая нормальной работы.
                            +1
                            Репликацию для того, чтобы в памяти остались кеши? Можете подробнее рассказать?
                  0
                  А данные как реплицируются на две сторадж ноды?
                    +2
                    «А вот!» ;) (посредством md)
                      +1
                      А чем кэшируете в dom0?
                        +1
                        Скорее не кэшируем, а буферизуем. Более детально, некоторые технические аспекты мы, возможно, рассмотрим в последующих статьях.
                    +1
                    Интересно: насколько утилизируется полоса Infiniband при обращении виртуальных машин к дискам в своей «зоне»? И какая нагрузка на самом ядре Infiniband?
                      0
                      Тут ещё интересна архитектура Infiniband. Судя по схеме, в каждой зоне свой коммутатор, но они должны быть как-то связаны между собой и управляющим кластером => ещё один… Не многовато?
                      Или один коммутатор на всех, но это совсем не «абсолютно независимы».
                        0
                        Они же маленькие свитчики используют, отсюда более расточительная топология дерево и отсюда же зоны, так как между свитчами инфу особо не погоняешь. В Скалакси тоже ведь зонирование, просто размер зоны на порядок больше.
                      +4
                      Хороший ответ «обычному» облачному хостингу :)
                        +1
                        Кому это важно, на новой СХД сейчас доступен всего один автоматический бекап который заменяет ручной.
                          +3
                          Подождите немного, будет запущена новая система бэкапов. Как просили пользователи.
                          0
                          Привет, поздравляю с первым постом. :)
                          По теме как/чем вы делали кеширование на чтение?
                          35к иопсов кто получает? отдельная машина, или это общее на стор?
                          Как с гарантированнными iops на виртуалку?
                          Кто такой «обычный облачный»? :)
                          С селектелом производительность дисков сравнивал?
                            +2
                            Утро!
                            Тесты делались на нескольких виртуалках одновременно при средней загруженности стораж зоны с выключенными шейперами. В реальности шейперы будут ограничивать иопсы в зависимости от размера виртуалки. Так что 35к в графиках тестов именно на машину.

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

                            Про «обычный облачный» легко догадаться.
                            С Селектелом сравнение можно вывести из других статей на хабре. =)
                              0
                              А какая связь между размером виртуалки и иопсами?

                              Да, я там заметил уже, что 35к это на запись, ее всегда проще кешировать, а на чтение там 15к.

                              Ладно, будем ждать подробностей. И кеширование на чтение очень интересно.
                                +1
                                Связь в том, что 5 виртуалок по 5 гб диска должны суммарно получать иопсов столько же, сколько машина с диском на 25Гб, например. Ибо справедливо.
                                  0
                                  В чем справедливость? Эти пятеро хранят там свои домашние архивы, и потребляют сто иопсов в месяц, а я создал минимальную виртуалку, которая постоянно обрабатывает гигибайты полезных данных.
                                    0
                                    There is no justice there is only me…

                                    Я имел ввиду что в реальности вес для шейпера выставляется относительно объёма потребления ресурсов. Кроме диска есть ещё ряд параметров которые надо учесть и формула выглядит сложнее. Но это уже технические подробности не из этой статьи.
                                  0
                                  Кол-во иопсов напрямую зависит от денег которые клиент тратит на виртуальный сервер. И это справедливо.
                                    0
                                    Почему просто не продать иопсы? Если я их массово потребляю — я буду за них платить и не буду впустую покупать ненужное мне место на сторе, и наоборот, если мне надо много места но не нужны иопсы — оплачу только место.
                                      0
                                      Есть такое в планах.

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

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