Пока что подготовлена только альфа-версия дизайна. Твоя идея с экспоненциальным расширением выглядит здраво, поэтому добавил её на внутреннее обсуждение. Она будет рассмотрена чуть позже, когда мы непосредственно доберёмся до этой части.
не подходил ли вместо всего выше описаного в статье Cinder CSI driver?
Cinder CSI driver позволяет общаться с опенстэком для заказа томов и подключения их к вирталкам запущенным внутри него, тем самым полностью перекладывая ответственность по менеджменту физических томов на плечи OpenStack.
Мы же имеем желание заменить OpenStack, а также предоставить эффективный способ утилизации SAN-хранилищ в Kubernetes в первую очередь на bare-metal серверах.
В современных дистрибутивах cLVM был заменён на более современный lvmlockd, у которого есть два бэкенда: pacemaker и sanlock. Sanlock позволяет относительно легко реализовать блокировки без необходимости настройки Pacemaker и Corosync.
Очень советую эту статью, чтобы понимать как работает кластерный LVM.
У вас размер тесового файла 1гб, у меня 100гб, полагаю что в вашем кейсе во время теста весь гигабайт успел быстро преаллоцироваться (LVM выделил под него эктенты), вся дальнейшая запись велась в пределах него :)
Думаю, мне будет проще объяснить это на примере того как работает дисковая подсистема.
В хостовой системе QEMU представляет из себя обычный процесс юзерского пространства, работающий с файлами и сетевыми сокетами.
Если вы запускаете виртуалку и отдаёте ей виртуальный диск (допустим, это отдельный файл, созданный в файловой системе хоста). То ядру хостовой системы, а именно драйверу файловой системы и драйверу реального устройства хранения, по прежнему приходится обрабатывать все запросы на чтение/запись полученные от QEMU, точно также как и от любого другого пользовательского процесса в хостовой ОС.
Последние технологии, основанные на vDPA, приносят для этого единый интерфейс в ядро, что, как side effect, добавляет довольно интересную возможность использовать их не только для виртуальных машин но и для контейнеров. Как раз об этом и будет моя следующая статья. Подписывайтесь чтобы не пропустить ;)
Когда у вас есть потребность запускать виртуальные машины вы всегда ищите наиболее эффективные методы виртуализации оборудования, в первую очередь для того чтобы получить более быстрые сеть и хранилище внутри виртуальных машин.
Эта статья делает детальный обзор на то как появлялись и как работают различные методы виртуализации оборудования.
И если сначала такие устройства эмулировались гипервизором полностью. То сейчас большинство методов основаны на том чтобы отказаться от необходимости эмулировать реальные устройства и максимально заоффлоадить I/O из виртуалок чтобы миновать гипервизор, а по возможности и ядро хостовой системы.
Нынче ChatGPT очень помогает с переводами подобных статей, иногда подключал Google Translate, каждое утверждение проверялось на действительность из моего опыта и с фактами доступными в открытых источниках.
Плюс огромное спасибо редакторской команде Фланта и персонально @TimurTukaev, которые помогли с редактурой статьи и проверкой фактов
В итоге у нас есть свой форк, который мы поддерживаем и патчи, которые сопровождаем в актуальном состоянии в соответсвии с нашим форком.
Единственное что мы не законтрибьютили, это ipam и vmi-router позволяющий строить роуты к виртуалкам из vmCIDRs. Так как на данный момент это скорее компонент Deckhouse, а не KubeVirt. В дальнейшем все эти изменения, включая наше API и router планируется вынести в отдельный независимый virtualization-controller.
Про virtlink не слышал, спасибо, выглядит очень интересно ?
Но у меня куча вопросов:
Написали свой маленький runtime shim для собственного runtimeClass
Ого. А виртуалки-то в итоге в подах запускаются? Есть где посмотреть/почитать на эту тему?
Слышал подобное можно реализовать через VirtualKubelet. На DevConf.cz был безумный доклад, где чел запускал Google Chrome на Raspberry PI через Kubernetes :)
Оказалось, что OCI-hook'ов достаточно, чтобы запровиженить блочные устройства и macvtap. CNI у нас на основе OpenvSwitch - macvtap пробрасывается на порты в нём.
А где сами диски хранятся? Я правильно понимаю что CSI-плагин в вашей схеме не задействован?
1) ClusterVirtualMachineImage шаблоны хранятся в реджистри, скачиваются когда из них создаётся VirtualMachineDisk. Позже будет добавлен VirtualMachineImage (неймспейсед аналог для пользователей) и возможность кэширования имаджей в кластере
2) Это по сути тот же podCIDR но определенный для виртуалок. Маршруты для него прописываются автоматически, так что это может быть любой неиспользуемый рейндж
Думаю на данный момент нет варианта с репликацией быстрее чем DRBD. А в случае если репликация не требуется (например если база умеет самостоятельно в репликацию), можно создавать неотказоучтойчивые тома с одной лишь репликой.
Пока что подготовлена только альфа-версия дизайна.
Твоя идея с экспоненциальным расширением выглядит здраво, поэтому добавил её на внутреннее обсуждение. Она будет рассмотрена чуть позже, когда мы непосредственно доберёмся до этой части.
Cinder CSI driver позволяет общаться с опенстэком для заказа томов и подключения их к вирталкам запущенным внутри него, тем самым полностью перекладывая ответственность по менеджменту физических томов на плечи OpenStack.
Мы же имеем желание заменить OpenStack, а также предоставить эффективный способ утилизации SAN-хранилищ в Kubernetes в первую очередь на bare-metal серверах.
В современных дистрибутивах cLVM был заменён на более современный lvmlockd, у которого есть два бэкенда: pacemaker и sanlock.
Sanlock позволяет относительно легко реализовать блокировки без необходимости настройки Pacemaker и Corosync.
Очень советую эту статью, чтобы понимать как работает кластерный LVM.
У вас размер тесового файла 1гб, у меня 100гб, полагаю что в вашем кейсе во время теста весь гигабайт успел быстро преаллоцироваться (LVM выделил под него эктенты), вся дальнейшая запись велась в пределах него :)
Пока что нет, но скорее всего сделаю.
Думаю, мне будет проще объяснить это на примере того как работает дисковая подсистема.
В хостовой системе QEMU представляет из себя обычный процесс юзерского пространства, работающий с файлами и сетевыми сокетами.
Если вы запускаете виртуалку и отдаёте ей виртуальный диск (допустим, это отдельный файл, созданный в файловой системе хоста). То ядру хостовой системы, а именно драйверу файловой системы и драйверу реального устройства хранения, по прежнему приходится обрабатывать все запросы на чтение/запись полученные от QEMU, точно также как и от любого другого пользовательского процесса в хостовой ОС.
Да, всё так, спасибо, поправил.
Последние технологии, основанные на vDPA, приносят для этого единый интерфейс в ядро, что, как side effect, добавляет довольно интересную возможность использовать их не только для виртуальных машин но и для контейнеров. Как раз об этом и будет моя следующая статья. Подписывайтесь чтобы не пропустить ;)
Когда у вас есть потребность запускать виртуальные машины вы всегда ищите наиболее эффективные методы виртуализации оборудования, в первую очередь для того чтобы получить более быстрые сеть и хранилище внутри виртуальных машин.
Эта статья делает детальный обзор на то как появлялись и как работают различные методы виртуализации оборудования.
И если сначала такие устройства эмулировались гипервизором полностью. То сейчас большинство методов основаны на том чтобы отказаться от необходимости эмулировать реальные устройства и максимально заоффлоадить I/O из виртуалок чтобы миновать гипервизор, а по возможности и ядро хостовой системы.
Нынче ChatGPT очень помогает с переводами подобных статей, иногда подключал Google Translate, каждое утверждение проверялось на действительность из моего опыта и с фактами доступными в открытых источниках.
Плюс огромное спасибо редакторской команде Фланта и персонально @TimurTukaev, которые помогли с редактурой статьи и проверкой фактов
Привет из 2023, тут наконец такой интерфейс разработали, у нас всё хорошо :-)
https://habr.com/ru/companies/flant/articles/751746/
Спасибо за обмен опытом, с удовольствием буду следить за вашей активностью ?
Мы законтрибьютили в апстрим, но на данный момент наши ПР'ы повисли на стадии рассмотрения:
https://github.com/kubevirt/kubevirt/pull/7648
https://github.com/kubevirt/kubevirt/pull/7768
Патчи силиума тоже не прошли по тем или иным причинам:
https://github.com/cilium/cilium/pull/24098
https://github.com/cilium/cilium/pull/23712
В итоге у нас есть свой форк, который мы поддерживаем и патчи, которые сопровождаем в актуальном состоянии в соответсвии с нашим форком.
Единственное что мы не законтрибьютили, это ipam и vmi-router позволяющий строить роуты к виртуалкам из vmCIDRs. Так как на данный момент это скорее компонент Deckhouse, а не KubeVirt. В дальнейшем все эти изменения, включая наше API и router планируется вынести в отдельный независимый virtualization-controller.
Про virtlink не слышал, спасибо, выглядит очень интересно ?
Но у меня куча вопросов:
Ого. А виртуалки-то в итоге в подах запускаются? Есть где посмотреть/почитать на эту тему?
Слышал подобное можно реализовать через VirtualKubelet. На DevConf.cz был безумный доклад, где чел запускал Google Chrome на Raspberry PI через Kubernetes :)
А где сами диски хранятся? Я правильно понимаю что CSI-плагин в вашей схеме не задействован?
Здравствуйте,
1) ClusterVirtualMachineImage шаблоны хранятся в реджистри, скачиваются когда из них создаётся VirtualMachineDisk. Позже будет добавлен VirtualMachineImage (неймспейсед аналог для пользователей) и возможность кэширования имаджей в кластере
2) Это по сути тот же podCIDR но определенный для виртуалок. Маршруты для него прописываются автоматически, так что это может быть любой неиспользуемый рейндж
Дельное замечание, спасибо, поправил
Все таки под бд LINSTOR норм заходит.
Думаю на данный момент нет варианта с репликацией быстрее чем DRBD. А в случае если репликация не требуется (например если база умеет самостоятельно в репликацию), можно создавать неотказоучтойчивые тома с одной лишь репликой.
Превосходно! Помнится одно время игрался с GameBoy Camera, был такой девайс:
Меня всегда завораживали получаемые картинки, вот тут есть немного моего творчества.
Хотя конкретно эти фотки сделаны не на GameBoy Camera, а на уже поздней Nintendo DS с дополнительным фильтром.
На всякий случай скажу что в open source есть уже готовое решение:
https://github.com/LINBIT/linstor-gateway
LINSTOR можно накатить поверх ZFS и получить отказоустойчивый сторадж с репликацией, снапшотами, автоматическими бэкапами и прочими плюшками
Браво! Это нейронка написала? Отличная паста! :)