Kubernetes очень сильно поменял подходы в отношении архитектуры ПО. Современное ПО строится из соображений что всегда что-то может пойти не так:
Ваше железо непременно умрёт (главное чтобы не одновременно).
Сеть будет лагать
Виртуалка - это средство изоляции, а не непотопляемый корабль.
Другими словами вам больше не нужна live-миграция и HA на уровне виртуальных машин. Теперь это достигается другими методами и инструментами.
Принцип KISS научил нас тому что чем система проще - тем стабильнее она работает. Когда появился Oauth2, он в большинстве случаев заменил LDAP именно из-за своей простоты и надёжности. Тоже сейчас происходит и с системами виртуализации.
Современные системы виртуализации всё чаще имплементируют более простой облачный паттерн, где отдельно взятая виртуалка может умереть и это не заафектит всю систему в целом. А если ваше приложение умеет работать в такой среде, то у вас получается простое и надёжное решение, которое выживет где угодно.
Я не говорю что VMware - это плохое решение, но похоже что настало время менять подходы и переходить на свободные технологии.
Наличие хотя бы одной резервной ноды — это хорошая практика, прежде всего потому, что необходимо иметь ресурсы, позволяющие вашей рабочей нагрузке переехать на другую ноду в случае отказа. На самом деле резервная нода не обязана постоянно находиться в режиме простаивания, она может функционировать как обычная нода в кластере. Я бы рекомендовал загружать ваши узлы не более чем на 75%-85% в зависимости от объёма самой ноды, чтобы оставался небольшой запас по ресурсам.
В этой схеме (как и в целом в Kubernetes) большинство компонентов запускается без сохранеия состояния. А значит их можно легко обновлять просто применив в кластер манифесты с новыми версиями.
Перекатывание воркеров происходит так же как и в любом облаке, путем удаления старых виртуалок и введения в кластер новых
Насчёт thin lvm соглашусь, но мы его и не поддерживаем. Если брать классический LVM, то потерять на нём данные нужно ещё постараться. Это же по сути просто раздел диска, чуть более динамический но всё же.
В ZFS файловую систему вообще разрабатывают исходя из принципа что "ваше железо непременно умрёт". Вон @gmelikov не даст соврать:
Одно дело развернуть кубер для своих внутренних сервисов. Совсем другое дело организовать систему которая позволит запускать кластера по клику, будет переносимой и поддерживать все функции облачного Kubernetes.
Без биллинга, конечно, никуда. И на данный момент мы не предлагаем решения для этой задачи.
Сейчас мы подразумеваем что у наших клиентов уже есть какой-никакой биллинг и веб-портал для заказа услуг. А наше решение является своего рода фреймворком, которое легко интегрируется и выступает в роли бэкенда:
Собственно статья больше о том, как такой бэкенд можно реализовать с использованием свободных технологий самостоятельно.
Это имеет смысл когда данные для бэкапа представляют собой не обычные файлы, а поток данных, который необходимо откуда-то выгрузить. Например: дампы баз данных, снапшоты блочных устройств и виртуальных машин, которые можно формировать и выгружать в систему бэкапирования на лету.
Конечно их можно предварительно выгрузить в виде фалов в файловую систему, а затем забэкапить их, но этот подход имеет определённые недостатки. Например для создания бэкапов из файлов вам понадобится свободное место во временной директории для сохранения этих файлов, а размер таких данных может спокойно достигать до десятков и сотен гигабайт. Кроме того при регулярности создания таких бэкапов расходуется ресурс накопителей на запись. Когда в случае создания бэкапа на лету, restic дедупдицирует одинаковые участки и даже не передаёт их по сети. Таким образом создание бэкапов из Stdin получается быстрее и эффективнее, так как не расходует место на файловой системе и ресурсы накопителей, сводя операции записи к минимуму.
В настоящее время в Международной системе единиц (СИ) принято следующее определение секунды: «одна секунда — это интервал времени, равный 9 192 631 770 периодам излучения, соответствующего переходу между двумя сверхтонкими уровнями основного квантового состояния атома цезия-133 в покое при 0 К».
Идея глобального времени мне импонирует, но тогда и секунду нужно брать более глобальную, скажем равную 10 000 000 00 периодам излучения, и всю метрическую систему поменять заодно, так как она основана на секунде как базовой единице.
Спасибо. В статье собрано действительно много полезной информации. Однако хочется услышать более подробно о том как у вас выстроен процесс реагирования на инциденты.
Есть мнение что когда алертов становится слишком много единой дашбордой уже не обойтись. Для этого лучше использовать полноценную IRM-систему (Grafana OnCall, PagerDuty, OpsGenie и другие)
Дело в том что недостаточно просто получить алерт, нужно уметь правильно на него отреагировать. Если у вас куча алертов и никто ими не занимается, то все эти алерты превращаются в бесполезный шум, который так и хочется замьютить.
Именно поэтому я считаю что на каждую систему должен быть назначен отвественный, которому эти алерты будут предназначены. IRM позволяет гибко настраивать дежурства, роутинг и оповещения для отвествнных лиц, и правильно эскалалировать инцидент в случае необходимости.
Критически важные алерты (например основной сервис компании лежит) будут будить дежурных всеми возможными методами: телеграм, смс, звонок на телефон и т.п., если не отвечают, то следующему инженеру дальше по цепочке.
С другой стороны некритичные алерты почём зря пиликать не должны. Но добавляется обязательная рутина: начинать каждое утро с разгребания инцидентов. К примеру, открываешь графану, смотришь, что за ночь в вашу команду упало 10 алертов, идёшь, смотришь и решаешь каждый.
Алерты которые приходится чинить слишком часто фиксятся на уровне приложения, в коде или автоматическими скриптами. Либо изменением самого алерта (когда алерт ложно-позитивный)
Общее блочное устройство для нескольких виртуальных машин можно создать с помощью открытого ПО. Главное соблюдать правило: в виртуальные машины диск передавать как устройство virtio-blk, а не virtio-scsi. Для QEMU в качестве backend-реализации можно использовать несжатый файл qcow2 (если все виртуальные машины на одном и том же физическом хосте), iSCSI-диск, Ceph RBD или аналогичные решения.
Формат qcow2 не поддерживает конкурентный доступ на чтение/запись из нескольких виртуальных машин одновременно. Даже если вы отключите page cache, он не защищён на изменение метаданных из разных источников. Если интересно, писал об этом тут.
а в качестве сервера для экспериментального стенда выбрали линуксовый nfsd. С точки зрения архитектуры эта комбинация выглядела привлекательно: в ней серверами данных (в терминологии pNFS) становились сервисы удаленных дисков SDS и оставалось только добавить в систему MDS.
А вы не тестировали возможность использования nfs-ganesha в такой же схеме с block layout?
В QEMU диск к виртуальной машине нужно подключать не как virtio-scsi, а как virtio-blk. В противном случае Linux будет пытаться использовать Block SCSI Layout вместо Block Volume Layout.
Подскажите чем это может быть черевато, ведь virtio-scsi быстрее и поддерживает TRIM.
В pNFS все эти процессы очень похожи на обычный NFS. Но для доступа к блокам данных клиент запрашивает у MDS схему размещения файла на DS-серверах, а затем выполняет чтение или запись, коммуницируя напрямую с DS-серверами.
Архитектурно pNFS Block Volume Layout лучше всего сочетается с SDS. Роль серверов данных выполняют сами удаленные диски. Фактически добавляется только одна новая сущность — сервер MDS.
То есть правильно-ли я понимаю что при наличии shared LUN, использование pNFS с блочным лейаутом можно рассматривать как альтернативу OCFS2 и GFS2?
Интересует возможность растянуть одну общую файловую систему поверх shared LUN, которая будет работать в ReadWriteMany. Внутри неё планируется создавать QCOW2-диски для отдельных виртуальных машин, которые поддерживают снапшоты и прочее.
Пока что подготовлена только альфа-версия дизайна. Твоя идея с экспоненциальным расширением выглядит здраво, поэтому добавил её на внутреннее обсуждение. Она будет рассмотрена чуть позже, когда мы непосредственно доберёмся до этой части.
Время сейчас такое, меняется софт и подходы.
Kubernetes очень сильно поменял подходы в отношении архитектуры ПО.
Современное ПО строится из соображений что всегда что-то может пойти не так:
Ваше железо непременно умрёт (главное чтобы не одновременно).
Сеть будет лагать
Виртуалка - это средство изоляции, а не непотопляемый корабль.
Другими словами вам больше не нужна live-миграция и HA на уровне виртуальных машин.
Теперь это достигается другими методами и инструментами.
Принцип KISS научил нас тому что чем система проще - тем стабильнее она работает.
Когда появился Oauth2, он в большинстве случаев заменил LDAP именно из-за своей простоты и надёжности. Тоже сейчас происходит и с системами виртуализации.
Современные системы виртуализации всё чаще имплементируют более простой облачный паттерн, где отдельно взятая виртуалка может умереть и это не заафектит всю систему в целом.
А если ваше приложение умеет работать в такой среде, то у вас получается простое и надёжное решение, которое выживет где угодно.
Я не говорю что VMware - это плохое решение, но похоже что настало время менять подходы и переходить на свободные технологии.
Наличие хотя бы одной резервной ноды — это хорошая практика, прежде всего потому, что необходимо иметь ресурсы, позволяющие вашей рабочей нагрузке переехать на другую ноду в случае отказа. На самом деле резервная нода не обязана постоянно находиться в режиме простаивания, она может функционировать как обычная нода в кластере. Я бы рекомендовал загружать ваши узлы не более чем на 75%-85% в зависимости от объёма самой ноды, чтобы оставался небольшой запас по ресурсам.
В этой схеме (как и в целом в Kubernetes) большинство компонентов запускается без сохранеия состояния. А значит их можно легко обновлять просто применив в кластер манифесты с новыми версиями.
Перекатывание воркеров происходит так же как и в любом облаке, путем удаления старых виртуалок и введения в кластер новых
Насчёт thin lvm соглашусь, но мы его и не поддерживаем. Если брать классический LVM, то потерять на нём данные нужно ещё постараться. Это же по сути просто раздел диска, чуть более динамический но всё же.
В ZFS файловую систему вообще разрабатывают исходя из принципа что "ваше железо непременно умрёт". Вон @gmelikov не даст соврать:
По крайней мере в случае чего эти данные всегда можно достать из backing storage обычным dd
Да имелось ввиду это, описывать и менеджить такой конфиг как код не удобно
И подхватила, проект был передан ControlPlane вместе со всей core-командой разработчиков.
По идее да, но такая возможность сильно не тестировалась, возможно столкнётесь с nodeAntiAffinity :)
Одно дело развернуть кубер для своих внутренних сервисов. Совсем другое дело организовать систему которая позволит запускать кластера по клику, будет переносимой и поддерживать все функции облачного Kubernetes.
Без биллинга, конечно, никуда. И на данный момент мы не предлагаем решения для этой задачи.
Сейчас мы подразумеваем что у наших клиентов уже есть какой-никакой биллинг и веб-портал для заказа услуг. А наше решение является своего рода фреймворком, которое легко интегрируется и выступает в роли бэкенда:
Собственно статья больше о том, как такой бэкенд можно реализовать с использованием свободных технологий самостоятельно.
С публикациями про Kubernetes? Возможно что да :)
Это имеет смысл когда данные для бэкапа представляют собой не обычные файлы, а поток данных, который необходимо откуда-то выгрузить. Например: дампы баз данных, снапшоты блочных устройств и виртуальных машин, которые можно формировать и выгружать в систему бэкапирования на лету.
Конечно их можно предварительно выгрузить в виде фалов в файловую систему, а затем забэкапить их, но этот подход имеет определённые недостатки. Например для создания бэкапов из файлов вам понадобится свободное место во временной директории для сохранения этих файлов, а размер таких данных может спокойно достигать до десятков и сотен гигабайт. Кроме того при регулярности создания таких бэкапов расходуется ресурс накопителей на запись. Когда в случае создания бэкапа на лету, restic дедупдицирует одинаковые участки и даже не передаёт их по сети.
Таким образом создание бэкапов из Stdin получается быстрее и эффективнее, так как не расходует место на файловой системе и ресурсы накопителей, сводя операции записи к минимуму.
Оно! И действительно, зачем привязываться к десятичной системе исчесления?
Слышал классный лайфхак:
Оказывается в Kubernetes можно сделать CronJob на 31 февраля, чтобы её было удобно запускать вручную:
Кто-то этим реально пользуется 😱
Идея глобального времени мне импонирует, но тогда и секунду нужно брать более глобальную, скажем равную 10 000 000 00 периодам излучения, и всю метрическую систему поменять заодно, так как она основана на секунде как базовой единице.
Ещё пока гуглил чему равна одна секунда наткнулся на Википедии на статью про десятичное время:
https://ru.m.wikipedia.org/wiki/Десятичное_время
Опубликовал перевод на английском:
The Evolution of Network Virtualization Technologies in Linux
Понял, большое спасибо за развернутый ответ!
Спасибо. В статье собрано действительно много полезной информации. Однако хочется услышать более подробно о том как у вас выстроен процесс реагирования на инциденты.
Есть мнение что когда алертов становится слишком много единой дашбордой уже не обойтись. Для этого лучше использовать полноценную IRM-систему (Grafana OnCall, PagerDuty, OpsGenie и другие)
Дело в том что недостаточно просто получить алерт, нужно уметь правильно на него отреагировать. Если у вас куча алертов и никто ими не занимается, то все эти алерты превращаются в бесполезный шум, который так и хочется замьютить.
Именно поэтому я считаю что на каждую систему должен быть назначен отвественный, которому эти алерты будут предназначены. IRM позволяет гибко настраивать дежурства, роутинг и оповещения для отвествнных лиц, и правильно эскалалировать инцидент в случае необходимости.
Критически важные алерты (например основной сервис компании лежит) будут будить дежурных всеми возможными методами: телеграм, смс, звонок на телефон и т.п., если не отвечают, то следующему инженеру дальше по цепочке.
С другой стороны некритичные алерты почём зря пиликать не должны. Но добавляется обязательная рутина: начинать каждое утро с разгребания инцидентов. К примеру, открываешь графану, смотришь, что за ночь в вашу команду упало 10 алертов, идёшь, смотришь и решаешь каждый.
Алерты которые приходится чинить слишком часто фиксятся на уровне приложения, в коде или автоматическими скриптами. Либо изменением самого алерта (когда алерт ложно-позитивный)
Крайне познавательно, спасибо :)
Формат qcow2 не поддерживает конкурентный доступ на чтение/запись из нескольких виртуальных машин одновременно. Даже если вы отключите page cache, он не защищён на изменение метаданных из разных источников. Если интересно, писал об этом тут.
А вы не тестировали возможность использования nfs-ganesha в такой же схеме с block layout?
Подскажите чем это может быть черевато, ведь virtio-scsi быстрее и поддерживает TRIM.
То есть правильно-ли я понимаю что при наличии shared LUN, использование pNFS с блочным лейаутом можно рассматривать как альтернативу OCFS2 и GFS2?
Интересует возможность растянуть одну общую файловую систему поверх shared LUN, которая будет работать в ReadWriteMany. Внутри неё планируется создавать QCOW2-диски для отдельных виртуальных машин, которые поддерживают снапшоты и прочее.
Пока что подготовлена только альфа-версия дизайна.
Твоя идея с экспоненциальным расширением выглядит здраво, поэтому добавил её на внутреннее обсуждение. Она будет рассмотрена чуть позже, когда мы непосредственно доберёмся до этой части.