Virtuozzo: Каковы реальные преимущества распределенного хранилища?

    image

    Существует много технологий, которые позволяют сохранить важную информацию в случае выхода носителей из строя, а также ускорить доступ к важным данным. Но наше гиперконвергентное хранилище Virtuozzo Storage по ряду параметров опережает программно-определяемые решения с открытым исходным кодом, а также готовые системы SAN или NAS. И сегодня мы говорим об архитектуре системы и ее преимуществах.

    Для начала стоит сказать о том, что же такое Virtuozzo Storage (в среде разработчиков — VZ Storage). Решение представляет собой распределенное хранилище, использующее ту же самую инфраструктуру, на которой работают ваши виртуальные машины и контейнеры (так называемую, гиперконвергентную инфраструктуру — hyper-converged). Изначально продукт развивался вместе с виртуализацией Virtuozzo. Однако, если вам не нужна полноценная система виртуализации, теперь проект доступен и в виде отдельного распределенного хранилища, которое может работать с любыми клиентами.

    Если говорить в общем, то VZ Storage использует диски в тех же самых серверах, которые обслуживают систему виртуализации. Таким образом, у вас пропадает необходимость закупать отдельное оборудование, например, дорогостоящий контроллер SAN/NAS, чтобы создать сетевую среду хранения. Одна из отличительных особенностей VZ Storage заключается в выборе способа хранения данных (схему избыточности) для разных категорий данных. Временные логи, например, можно вообще не резервировать, а для важных данных предусмотрены различные технологии защиты – репликация (полное дублирование) или самовосстанавливающиеся коды (Erasure Coding).

    Железо

    Так как VZ Storage является гиперконвергентной системой хранения, она может быть развернута с использованием любых серверов стандартной архитектуры x86. Впрочем, чтобы работа системы была эффективной, в каждом сервере должно быть установлено как минимум три жестких диска не менее 100 Гб емкостью каждый, двухъядерный процессор (одно ядро отдаем хранилищу), и 2Гб оперативной памяти. В более мощных конфигурациях мы рекомендуем ставить одно процессорное ядро и 4ГБ памяти на каждые 8 жестких дисков. То есть, используя на узле, например, 15 дисков для создания хранилища, для поддержки работы кластера хранения вам потребуется всего 2 ядра и 8ГБ RAM.

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

    Архитектура

    Распределенная архитектура VZ Storage подразумевает, что мы устанавливаем разные компоненты системы на физические или виртуальные серверы: панель управления с графическим интерфейсом, сервер хранения данных (Chunk Server – CS), сервер метаданных (MetaData Server – MDS), монтирование хранилища для чтения/записи данных (Client). Один узел может запускать несколько компонент в любом сочетании. То есть, один сервер, например, может одновременно хранить и данные, и метаданные, и запускать виртуальные машины, и предоставлять панель управления кластером.

    image

    Все данные в кластере разбиваются на блоки фиксированного размера («chunks» — чанки). Для каждого «чанка» создается несколько реплик (его копий), причем размещаются они на различных машинах (чтобы обеспечить отказоустойчивость в случае выхода из строя целой машины). При установке кластера вы задаете параметр нормального и минимального количества реплик. Если какая-то машина выходит из строя или перестает работать диск, силами кластера все утраченные реплики будут воспроизведены на оставшихся – вплоть до параметра нормального количества (обычно 3). В это время система по-прежнему позволяет писать и часть данных без задержек. Но, если же из-за сбоя количество копий упало ниже минимального значения (обычно 2), то есть произошел одновременных отказ двух компонент, кластер позволяет только читать данные, а для записи клиентам придётся подождать пока не будет восстановлено хотя бы минимальное количество копий. Система восстанавливает такие чанки, с которыми идёт работа, с наивысшим приоритетом.

    Количество CS и MDS на каждом сервере определяется количеством физических дисков. VZ Storage привязывает один компонент к одному накопителю, создавая тем самым четкое разделение ресурсов и реплик между разным физическим оборудованием.

    В чем плюсы?

    Мы немного познакомились со структурой и требованиями VZ Storage, и теперь возникает вопрос, зачем все это нужно? Какие плюсы дает система? Самое главное преимущество VZ Storage – это надежность. Используя то же самое оборудование (возможно, добавив в него сетевые контроллеры и диски), вы получаете высокоэффективную легко-масштабируемую систему с отлаженным механизмом работы с данными, метаданными. VZ Storage позволяет обеспечить постоянное и надежное хранение данных, включая диски ВМ и данные контейнерных приложений для Docker, Kubernetes или Rancher.

    Второй плюс – это низкая стоимость владения (TCO). Кроме того, что для работы решения не нужно приобретать отдельное дорогостоящее «железо» и вы можете выбирать опции резервирования для различных данных, в VZ Storage имеется возможность использования erasure coding (кодов избыточности, таких как Reed-Solomon). Это позволяет снизить требования к общей емкости, сохраняя возможность восстановления данных в случае сбоя. Метод подходит для хранения больших объемов данных, когда высочайшая скорость доступа – это далеко не самое главное.

    Какие именно плюсы дает erasure coding (EC)? Erasure codding позволяет значительно сократить расход использования дискового пространства. Достигается это счёт специальной обработки данных.

    image

    При формуле избыточности M+N[/X], EC позволяет использовать намного меньше дискового пространства. Если M – это количество блоков данных, N – количество блоков специальных контрольных сумм («Parity»), а X – параметр допустимости записи (он характеризуется тем, сколько узлов системы хранения могут быть недоступны, когда клиент по-прежнему может записывать данные в свои файлы). Чтобы система работала, минимальное количество узлов в VZ Storage должно составлять 5 (в этом случае M=3,N=2, или “3+2”). На картинке изображен пример, где M=5, N=2 или “5+2”.

    На примере инсталляции системы с конфигурацией 5 + 2 и включенным EC, мы можем гарантировать дополнительную нагрузку на емкость лишь в 40%, создавая только 2Гб резервных данных на каждые 5Гб данных приложений).

    В этом случае для защищенного хранения 100 Тб данных вам потребуется всего 140 Тб емкости. Такой подход помогает оптимизировать бюджет или обеспечить хранение больших объемов данных в тех случаях, когда в кластер уже физически нельзя установить больше дисков, в стойку – больше серверов, в серверную – больше стоек. При этом мы сохраняем высокую доступность данных – даже при выходе из строя двух элементов системы хранения, оставшиеся узлы системы позволят восстановить все данные вплоть до бита, не останавливая работу приложения. В таблице приведены значения резервной емкости, и, как вы можете видеть, результаты использования erasure coding оказываются действительно впечатляющими, когда в кластере используется много машин. Например, в конфигурации 17+3 с erasure coding резервная емкость составляет всего 18%

    image

    Другое дело – производительность. Конечно, erasure coding повышает нагрузку на ЦП, но совершенно незначительно. За счёт SSE инструкций на современных процессорах одно ядро может обрабатывать до ~2GB/s данных.

    В том и плюс распределенной системы хранения, что вы можете задать разные типы резервирования для разных нагрузок. И в случае с прямыми репликами, кластер с большим количеством узлов, напротив, дает намного большую производительность. Впрочем, именно о производительности VZ Storage мы поговорим более подробно в следующем посте, так как измерения эффективности гиперконвергентной системы хранения данных зависят от огромного количества факторов, включая характеристики «железа», тип сетевой архитектуры, особенности нагрузки и так далее.

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

    Что вы считаете наиболее важной характеристикой современной системы хранения?

    • 6.8%Высокая производительность3
    • 52.2%Надежность хранения данных23
    • 9%Использование стандартного «железа»4
    • 2.2%Гиперконвергентность1
    • 6.8%Простота управления3
    • 22.7%Открытый исходный код10
    • 0%Интеграции с различными API и платформами (aka Kubernetes)0
    Virtuozzo
    39,44
    Разработчик ПО для контейнерной виртуализации
    Поделиться публикацией

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

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

      0
      Расскажите подробнее зачем нужны MDS и как клиенты ищут адрес нужного чанка.
        0

        Файлы разбиваются на чанки. CS хранят чанки (данные). MDS хранит информацию о чанках (метаданные). В метаданные входит следующая информация: таблица трансляции файла в реплики, набор чанков соответствующих репликам, местонахождение чанков, настройки домена отказоустойчивости, размер чанков и прочая информация. Также в функции MDS входит система lock’ов на запись в файл, система автоматического восстановления избыточности, балансировка данных на основании текущей нагрузки и заполненности дисков. MDS почти не принимает участие в I/O потоках, этот компонент просто управляет процессом.
        Чтобы было понятнее: в случае запуска VM, открывается образ VM, то есть открывается файл на запись. Клиент (FUSE-mount) берёт lock на запись в этот файл. Если файл ещё нигде не открыт (VM нигде ещё не запущена) MDS разрешает эту операцию и отдаёт полный MAP на файл (информация о том, как файл разбит на куски и где они хранятся). Клиент, получив карту файла самостоятельно работает с CS-ами, читая и изменяя данные внутри чанков. Если файл вырос или уменьшился, клиент делает запрос к MDS на изменение MAP, в этом случае MDS освобождает свободные чанки или создает новые.

          0
          Спасибо за развернутость. Еще несколько вопросов:
          — метаданные реплицируются между MDS?
          — если да, то синхронно?
          — если синхронно, то как это влияет на производительность при горизонтальном масштабировании MDS?
          — сколько требуется серверов метаданных и для каких размеров кластера?
            0
            Сервис MDS имеет высокую доступность; метаданные реплицируются между MDS. Один MDS выбирается master. Он принимает решения (например, обновление map для какого-то файла). Приняв решение, он коммитит его в свой журнал и рассылает его по slave MDS. MDS отправляет результат клиентам только после того как большинство(majority) MDS ответило о коммите транзакции в журнал. Кластер работает пока MDS majority остаётся on-line. Мы рекомендуем иметь 5 MDS в кластере, чтобы сохранить majority в случае выхода их строя одновременно двух MDS.
            Если поместить MDS на SSD, то он способен выдавать около 30K файловых операций в секунду (таких как открытие файла, выделение нового chunk и т.д.) на одно процессорное ядро. Этой производительности вполне достаточно для кластеров в несколько тысяч работающих VM и контейнеров. Объясню чуть подробнее почему. I/O работает независимо от MDS, кластер может выдавать миллионы IOPS, оказывая минимальную нагрузку на MDS. Файл на Virtuozzo Storage – это образы виртуальных машин и контейнеров, либо больше volumes для сервисов, таких как S3, iSCSI, NFS. То есть все они – это несколько больших файлы, которые редко переоткрываются. Работа c объектами/файлами пользовательского представления (фалы в VM, объекты в S3, файлы на NFS шаре) происходит на уровне выше и не затрагивает MDS.
        0
        интересна стоимость, есть калькуляторы, как вообще покупаются лицензии?
          0

          Скачать можно бесплатно с официальной страницы: https://virtuozzo.com/products/virtuozzo-storage/ (только Storage без виртуализации) https://virtuozzo.com/products/virtuozzo/ (Storage+Виртуализация)


          На почту придёт ссылка на iSO образ. Для тестирования можно использовать виртуальную машину.


          Чтобы попробовать продукт лицензии не нужно. Без лицензии, прямо после установки с ISO, можно пользоваться полным функционалом до 1ТБ. Если хотите хранить больше 1ТБ, придётся приобрести лицензию через отдел продаж Virtuozzo.


          Цены можно узнать на сайте www.virtuozzo.com — просто сделайте заявку и вас сориентируют.

          0
          А от какого количества серверов у гиперконвергентных хранилищ начинается преимущество перед класическими схд? Или все как всегда зависит от задач?
          Например задача тестовая среда. Штук 35-45 Виртуалок.
          Количество серверов 4. Гипервизор Vmware.
          На тестовой среде будет работать примерно 20 пользователей. Пользователи с использованием VGPU.
          В инфраструктуре будет 2 карты Nvidia M60.
            0

            Зависит от задач и ресурсов на решение. Тут сложно дать универсальный рецепт. Если заходить в классические СХД начального уровня, то можно довольно быстро упереться в их лимит (например, большой down-time при падании одной «головы» СХД), и решением будет покупка СХД выше классом. В гиперконвергентной инфраструктуре рост происходит плавно (как технологически, так и финансово), и это одно из главных преимуществ.


            По тестовой среде — это скорее сценарий VDI с виртуализацией GPU. То есть хранилище у вас тут как бы вторичную роль играет при описании задачи....

            +1
            Используем Ceph. Мысленно переманите меня на использование Virtuozzo Storage. Дайте доводы.
              0

              Мы как раз готовим пост об этом. :)

              +1
              Глючит как Virtuozzo 7?
                –3
                Уважаемый, VZ Storage поставляется в рамках платформы VZ 7, а также в виде standalone-продукта. А насчет глючит…
                  +2
                  То есть вы не знаете, глючит или нет?

                  * PSBM-67300
                  Kernel crash (NULL pointer dereference) in list_lru_destroy().

                  * PSBM-67221
                  Kernel crash (general protection fault) in cleanup_timers().

                  * PSBM-67076
                  Kernel deadlocks in try_charge().
                    –1

                    Я бы сказал, что и VZ 7 у множества клиентов не глючит. Вопрос настройки. Обратитесь в техподедржку — как мы можем это обудить здесь, на хабре?

                      +1
                      То есть ваша команда исправила 3 несуществующих бага? :-)

                      В поддержку конечно обращались. Благодаря нам и существуют эти 3 строчки в ченджлоге.
                        0

                        Ну и прекрасно! Рад, что теперь все хорошо, хотя к чему был вопрос — я так и не понял.

                +1

                Вроде бы и есть раздел озаглавленный "Архитектура", а самой архитектуры почти и нет.


                1) Какой размер чанка используется?
                2) Какие метаданные хранят MDS? Что то вроде адресации расположения чанков, информация о монтировании логических томов и что еще (хотя бы крупными мазками)?
                3) Сколько этих MDS рекомендовано и максимально возможно? В каком режиме они работают? Active-Active или Active-Passive? Какая защита от потери метаданных кластера?
                4) Как организованы физические носители? Некий общий пул или как то иначе?
                5) Как быть если есть SSD и не-SSD? Разные пулы? Или тиринг?
                6) Если разные пулы, то есть возможность перемещать между ними логические тома? Что бы поднять например производительность для конкретного клиента? Online, т.е. прозрачно для клиента и без остановки I/O? Или нет?
                7) Как выделяются логические тома (thin or thick)?
                8) Как мапятся и монтируются логические тома к клиентам?
                9) Есть снэпшотинг? Репликация?


                А то статья больше на рекламу похожа.

                  0

                  Ну что же, давайте разбираться. :)


                  1) Размер чанка по умолчанию — 256MB. Из большого размера чанка, видно, что система хранения ориентирована на большие файлы или volume, такие как образы виртуальных машин. Но размер чанка можно изменить, если потребуется. Либо мелкие файлы, такие как объекты в S3, упаковываются в большие файлы на уровне сервиса S3.


                  2) Про MDS уже ответили товарищу выше, но повторимся. Файлы разбиваются на чанки. CS хранят чанки (данные). MDS хранит информацию о чанках (метаданные). В метаданные входит следующая информация: таблица трансляции файла в реплики, набор чанков соответствующих репликам, местонахождение чанков, настройки домена отказоустойчивости, размер чанков и прочая информация. Также в функции MDS входит система lock’ов на запись в файл, система автоматического восстановления избыточности, балансировка данных на основании текущей нагрузки и заполненности дисков. MDS почти не принимает участие в I/O потоках, этот компонент просто управляет процессом.
                  Чтобы было понятнее: в случае запуска VM, открывается образ VM, то есть открывается файл на запись. Клиент (FUSE-mount) берёт lock на запись в этот файл. Если файл ещё нигде не открыт (VM нигде ещё не запущена) MDS разрешает эту операцию и отдаёт полный MAP на файл (информация о том, как файл разбит на куски и где они хранятся). Клиент, получив карту файла самостоятельно работает с CS-ами, читая и изменяя данные внутри чанков. Если файл вырос или уменьшился, клиент делает запрос к MDS на изменение MAP, в этом случае MDS освобождает свободные чанки или создает новые.


                  3) Рекомендации по MDS — иметь 5 штук. Их автоматическое восстановление и является защитой от потери метаданных.


                  4) Каждый физический носитель – это CS (chunk server).


                  5) Есть разные варианты. Можно использовать SSD для журналирования и кеширования данных, а можно, как вы предлашаете, выделить в отдельный тир или пул для работы с более "быстрыми" данными.


                  6) В системе есть tier'ы. Их всего 4. Они позволяют создать из более быстрых дисков более производительный сегмент хранилища. Вы в любой момент можете разместить на нем более ресурсоёмкую нагрузку, например, пользователя или базу данных.


                  7) Выделение томов происходит методом Thin provisioning. Все логические тома (как, например, iSCSI LUN) растут по мере фактического потребления емкости.


                  8) Про маппинг уже сказали выше


                  9) Что касается снэпшотов, они поисходят на уровне VM. На уровне файлов пока нет. такой функции, но она планируется. Возможность Гео-репликации поддерживается для хранилища S3.

                  +1
                  я думаю, что самый актуальный вопрос: чем оно лучше ceph? с первого взгляда то же самое, но за деньги.
                    0

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

                      +1

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


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

                      0
                      какие диски/контроллеры поддерживаются? поддерживается ли конфигурация с избыточностью на кодах Р/С и магнитных дисках? локальные диски должны быть в райде?
                        0

                        СХД организует избыточность на своём уровне (репликация/Erasure-coding). Рекомендуется использовать JBOD контроллер (pass-through), то есть подразумевается отсутствие RAID, и тут можно немного сэкономить.


                        Но если всё-таки используется RAID контроллер (например, если железо уже есть), все диски нужно сконфигурировать как отдельный RAID0-volume. Репликация/Erasure-coding на уровне СХД имеет такой параметр, как домен отказа (failure domain). Он может иметь значение: disk, host, rack, raw, room. То есть для одного nod можно задать failure domain disk и СХД будет раскладывать реплики (или Erasure-coding схему) по дискам, если rack, то система будет размещать не более одной реплики на стойку.

                        +1
                        опрос нечестный — как можно выбрать единственное требование к СХД?
                        понятное дело, что в такой формулировке будет выбрана надёжность.
                          0

                          Попробуем задать новый опрос в продолжении материала — где будем говорить про производительность.

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

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