Чисто технически, чтобы CRIU работал с lxc (или docker, или вообще с чем угодно) главным образом надо обучать lxc (docker, whatever) передавать в criu правильные аргументы, которые объяснят ему, как сконфигурированы "внешние связи". В ряде случаев CRIU может и сам их определить, но для восстановления всё равно понадобится кооперация с тем же lxc (docker, ...), так что целиком переложить всю работу на CRIU не получается.
А вот патчить lxc (docker, ...) невозможно силами только команды CRIU, нужна помощь от соответствующих сообществ, которая, к сожалению, не всегда поспевает вовремя.
Изначально Торвальдс действительно скептически относился к самой идее живой миграции, впрочем, как и многие… и да, решение задачи было очень непростым, пришлось много чего добавить в ядро, но в результате получился рабочий инструмент, который продолжает развиваться. И он эффективен для определенных целей, вот, например, для мейнфреймов. )
СХД организует избыточность на своём уровне (репликация/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) Размер чанка по умолчанию — 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.
Зависит от задач и ресурсов на решение. Тут сложно дать универсальный рецепт. Если заходить в классические СХД начального уровня, то можно довольно быстро упереться в их лимит (например, большой down-time при падании одной «головы» СХД), и решением будет покупка СХД выше классом. В гиперконвергентной инфраструктуре рост происходит плавно (как технологически, так и финансово), и это одно из главных преимуществ.
По тестовой среде — это скорее сценарий VDI с виртуализацией GPU. То есть хранилище у вас тут как бы вторичную роль играет при описании задачи....
На почту придёт ссылка на iSO образ. Для тестирования можно использовать виртуальную машину.
Чтобы попробовать продукт лицензии не нужно. Без лицензии, прямо после установки с ISO, можно пользоваться полным функционалом до 1ТБ. Если хотите хранить больше 1ТБ, придётся приобрести лицензию через отдел продаж Virtuozzo.
Цены можно узнать на сайте www.virtuozzo.com — просто сделайте заявку и вас сориентируют.
Файлы разбиваются на чанки. CS хранят чанки (данные). MDS хранит информацию о чанках (метаданные). В метаданные входит следующая информация: таблица трансляции файла в реплики, набор чанков соответствующих репликам, местонахождение чанков, настройки домена отказоустойчивости, размер чанков и прочая информация. Также в функции MDS входит система lock’ов на запись в файл, система автоматического восстановления избыточности, балансировка данных на основании текущей нагрузки и заполненности дисков. MDS почти не принимает участие в I/O потоках, этот компонент просто управляет процессом.
Чтобы было понятнее: в случае запуска VM, открывается образ VM, то есть открывается файл на запись. Клиент (FUSE-mount) берёт lock на запись в этот файл. Если файл ещё нигде не открыт (VM нигде ещё не запущена) MDS разрешает эту операцию и отдаёт полный MAP на файл (информация о том, как файл разбит на куски и где они хранятся). Клиент, получив карту файла самостоятельно работает с CS-ами, читая и изменяя данные внутри чанков. Если файл вырос или уменьшился, клиент делает запрос к MDS на изменение MAP, в этом случае MDS освобождает свободные чанки или создает новые.
Дело в производительности и оптимизациях. Для отдельных задач уже проведены тесты, и разница — как минимум в производительности. Об этом будет следующий пост.
Не предусмотрено конструкцией. :) Мы же опрос проводим о будущем, а не о прошлом. Буду признателен, если ответите, хотели бы еще поработать или "нетужки" :)
Название материала "день из жизни службы технической поддержки". То есть о жизни отдела. Ваши вопросы, кстати, тоже интересные. Попробуем и о них написать.
И кстати, помимо общей инфраструктуры эти серверы тоже нужны. Для многих инфраструктура на таких вот серверах это признак незрелости компании. В чем-то эта оценка правильная, но дело в том что это не инфраструктура — это личные тестовые сервера разработчиков, которых у нас очень много, и покупать под них стоечные сервера — очень дорого. Корпуса десктопов, хотя железо — серверное. А инфрастуктура у нас в стойках, просто она за кадром — в Москве и в Сиэтле.
Чисто технически, чтобы CRIU работал с lxc (или docker, или вообще с чем угодно) главным образом надо обучать lxc (docker, whatever) передавать в criu правильные аргументы, которые объяснят ему, как сконфигурированы "внешние связи". В ряде случаев CRIU может и сам их определить, но для восстановления всё равно понадобится кооперация с тем же lxc (docker, ...), так что целиком переложить всю работу на CRIU не получается.
А вот патчить lxc (docker, ...) невозможно силами только команды CRIU, нужна помощь от соответствующих сообществ, которая, к сожалению, не всегда поспевает вовремя.
Изначально Торвальдс действительно скептически относился к самой идее живой миграции, впрочем, как и многие… и да, решение задачи было очень непростым, пришлось много чего добавить в ядро, но в результате получился рабочий инструмент, который продолжает развиваться. И он эффективен для определенных целей, вот, например, для мейнфреймов. )
Попробуем задать новый опрос в продолжении материала — где будем говорить про производительность.
Ну и прекрасно! Рад, что теперь все хорошо, хотя к чему был вопрос — я так и не понял.
СХД организует избыточность на своём уровне (репликация/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) Размер чанка по умолчанию — 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.
Зависит от задач и ресурсов на решение. Тут сложно дать универсальный рецепт. Если заходить в классические СХД начального уровня, то можно довольно быстро упереться в их лимит (например, большой down-time при падании одной «головы» СХД), и решением будет покупка СХД выше классом. В гиперконвергентной инфраструктуре рост происходит плавно (как технологически, так и финансово), и это одно из главных преимуществ.
По тестовой среде — это скорее сценарий VDI с виртуализацией GPU. То есть хранилище у вас тут как бы вторичную роль играет при описании задачи....
Скачать можно бесплатно с официальной страницы: https://virtuozzo.com/products/virtuozzo-storage/ (только Storage без виртуализации) https://virtuozzo.com/products/virtuozzo/ (Storage+Виртуализация)
На почту придёт ссылка на iSO образ. Для тестирования можно использовать виртуальную машину.
Чтобы попробовать продукт лицензии не нужно. Без лицензии, прямо после установки с ISO, можно пользоваться полным функционалом до 1ТБ. Если хотите хранить больше 1ТБ, придётся приобрести лицензию через отдел продаж Virtuozzo.
Цены можно узнать на сайте www.virtuozzo.com — просто сделайте заявку и вас сориентируют.
Файлы разбиваются на чанки. CS хранят чанки (данные). MDS хранит информацию о чанках (метаданные). В метаданные входит следующая информация: таблица трансляции файла в реплики, набор чанков соответствующих репликам, местонахождение чанков, настройки домена отказоустойчивости, размер чанков и прочая информация. Также в функции MDS входит система lock’ов на запись в файл, система автоматического восстановления избыточности, балансировка данных на основании текущей нагрузки и заполненности дисков. MDS почти не принимает участие в I/O потоках, этот компонент просто управляет процессом.
Чтобы было понятнее: в случае запуска VM, открывается образ VM, то есть открывается файл на запись. Клиент (FUSE-mount) берёт lock на запись в этот файл. Если файл ещё нигде не открыт (VM нигде ещё не запущена) MDS разрешает эту операцию и отдаёт полный MAP на файл (информация о том, как файл разбит на куски и где они хранятся). Клиент, получив карту файла самостоятельно работает с CS-ами, читая и изменяя данные внутри чанков. Если файл вырос или уменьшился, клиент делает запрос к MDS на изменение MAP, в этом случае MDS освобождает свободные чанки или создает новые.
Я бы сказал, что и VZ 7 у множества клиентов не глючит. Вопрос настройки. Обратитесь в техподедржку — как мы можем это обудить здесь, на хабре?
Мы как раз готовим пост об этом. :)
Дело в производительности и оптимизациях. Для отдельных задач уже проведены тесты, и разница — как минимум в производительности. Об этом будет следующий пост.
Не предусмотрено конструкцией. :) Мы же опрос проводим о будущем, а не о прошлом. Буду признателен, если ответите, хотели бы еще поработать или "нетужки" :)
Pakos — спасибо за внимательность! :)
Ну не передергивайте. :) Компания старается сделать код лучше, но саппорту всегда есть работа. :)
На то оно и опрос, чтобы выбрать свои ответы. :) Тем не менее, саппортерам нередко приходится тоже работать с кодом.
Название материала "день из жизни службы технической поддержки". То есть о жизни отдела. Ваши вопросы, кстати, тоже интересные. Попробуем и о них написать.
Уже на месте. :)
И кстати, помимо общей инфраструктуры эти серверы тоже нужны. Для многих инфраструктура на таких вот серверах это признак незрелости компании. В чем-то эта оценка правильная, но дело в том что это не инфраструктура — это личные тестовые сервера разработчиков, которых у нас очень много, и покупать под них стоечные сервера — очень дорого. Корпуса десктопов, хотя железо — серверное. А инфрастуктура у нас в стойках, просто она за кадром — в Москве и в Сиэтле.