Comments 25
Файлы разбиваются на чанки. CS хранят чанки (данные). MDS хранит информацию о чанках (метаданные). В метаданные входит следующая информация: таблица трансляции файла в реплики, набор чанков соответствующих репликам, местонахождение чанков, настройки домена отказоустойчивости, размер чанков и прочая информация. Также в функции MDS входит система lock’ов на запись в файл, система автоматического восстановления избыточности, балансировка данных на основании текущей нагрузки и заполненности дисков. MDS почти не принимает участие в I/O потоках, этот компонент просто управляет процессом.
Чтобы было понятнее: в случае запуска VM, открывается образ VM, то есть открывается файл на запись. Клиент (FUSE-mount) берёт lock на запись в этот файл. Если файл ещё нигде не открыт (VM нигде ещё не запущена) MDS разрешает эту операцию и отдаёт полный MAP на файл (информация о том, как файл разбит на куски и где они хранятся). Клиент, получив карту файла самостоятельно работает с CS-ами, читая и изменяя данные внутри чанков. Если файл вырос или уменьшился, клиент делает запрос к MDS на изменение MAP, в этом случае MDS освобождает свободные чанки или создает новые.
— метаданные реплицируются между MDS?
— если да, то синхронно?
— если синхронно, то как это влияет на производительность при горизонтальном масштабировании MDS?
— сколько требуется серверов метаданных и для каких размеров кластера?
Если поместить MDS на SSD, то он способен выдавать около 30K файловых операций в секунду (таких как открытие файла, выделение нового chunk и т.д.) на одно процессорное ядро. Этой производительности вполне достаточно для кластеров в несколько тысяч работающих VM и контейнеров. Объясню чуть подробнее почему. I/O работает независимо от MDS, кластер может выдавать миллионы IOPS, оказывая минимальную нагрузку на MDS. Файл на Virtuozzo Storage – это образы виртуальных машин и контейнеров, либо больше volumes для сервисов, таких как S3, iSCSI, NFS. То есть все они – это несколько больших файлы, которые редко переоткрываются. Работа c объектами/файлами пользовательского представления (фалы в VM, объекты в S3, файлы на NFS шаре) происходит на уровне выше и не затрагивает MDS.
Скачать можно бесплатно с официальной страницы: https://virtuozzo.com/products/virtuozzo-storage/ (только Storage без виртуализации) https://virtuozzo.com/products/virtuozzo/ (Storage+Виртуализация)
На почту придёт ссылка на iSO образ. Для тестирования можно использовать виртуальную машину.
Чтобы попробовать продукт лицензии не нужно. Без лицензии, прямо после установки с ISO, можно пользоваться полным функционалом до 1ТБ. Если хотите хранить больше 1ТБ, придётся приобрести лицензию через отдел продаж Virtuozzo.
Цены можно узнать на сайте www.virtuozzo.com — просто сделайте заявку и вас сориентируют.
Например задача тестовая среда. Штук 35-45 Виртуалок.
Количество серверов 4. Гипервизор Vmware.
На тестовой среде будет работать примерно 20 пользователей. Пользователи с использованием VGPU.
В инфраструктуре будет 2 карты Nvidia M60.
Зависит от задач и ресурсов на решение. Тут сложно дать универсальный рецепт. Если заходить в классические СХД начального уровня, то можно довольно быстро упереться в их лимит (например, большой down-time при падании одной «головы» СХД), и решением будет покупка СХД выше классом. В гиперконвергентной инфраструктуре рост происходит плавно (как технологически, так и финансово), и это одно из главных преимуществ.
По тестовой среде — это скорее сценарий VDI с виртуализацией GPU. То есть хранилище у вас тут как бы вторичную роль играет при описании задачи....
* 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) Какой размер чанка используется?
2) Какие метаданные хранят MDS? Что то вроде адресации расположения чанков, информация о монтировании логических томов и что еще (хотя бы крупными мазками)?
3) Сколько этих MDS рекомендовано и максимально возможно? В каком режиме они работают? Active-Active или Active-Passive? Какая защита от потери метаданных кластера?
4) Как организованы физические носители? Некий общий пул или как то иначе?
5) Как быть если есть SSD и не-SSD? Разные пулы? Или тиринг?
6) Если разные пулы, то есть возможность перемещать между ними логические тома? Что бы поднять например производительность для конкретного клиента? Online, т.е. прозрачно для клиента и без остановки I/O? Или нет?
7) Как выделяются логические тома (thin or thick)?
8) Как мапятся и монтируются логические тома к клиентам?
9) Есть снэпшотинг? Репликация?
А то статья больше на рекламу похожа.
Ну что же, давайте разбираться. :)
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.
Дело в производительности и оптимизациях. Для отдельных задач уже проведены тесты, и разница — как минимум в производительности. Об этом будет следующий пост.
С Ceph одна основная проблема. Если нет специалистов, способных с ним разобраться в компании, то и нет возможности его нормально использовать. Вендорские решения обычно не требуют глубоких знаний продукта для его разворачивания и использования, но стоят денег.
Есть еще одна проблема, что в случае Ceph вся ответственность за функционирование решения и сохранность данных лежит на IT-специалисте (или IT-отеделе) развернувшем Ceph. Не все IT-шники к такому готовы.
СХД организует избыточность на своём уровне (репликация/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, то система будет размещать не более одной реплики на стойку.
понятное дело, что в такой формулировке будет выбрана надёжность.
Virtuozzo: Каковы реальные преимущества распределенного хранилища?