Без биллинга, конечно, никуда. И на данный момент мы не предлагаем решения для этой задачи.
Сейчас мы подразумеваем что у наших клиентов уже есть какой-никакой биллинг и веб-портал для заказа услуг. А наше решение является своего рода фреймворком, которое легко интегрируется и выступает в роли бэкенда:
Собственно статья больше о том, как такой бэкенд можно реализовать с использованием свободных технологий самостоятельно.
Это имеет смысл когда данные для бэкапа представляют собой не обычные файлы, а поток данных, который необходимо откуда-то выгрузить. Например: дампы баз данных, снапшоты блочных устройств и виртуальных машин, которые можно формировать и выгружать в систему бэкапирования на лету.
Конечно их можно предварительно выгрузить в виде фалов в файловую систему, а затем забэкапить их, но этот подход имеет определённые недостатки. Например для создания бэкапов из файлов вам понадобится свободное место во временной директории для сохранения этих файлов, а размер таких данных может спокойно достигать до десятков и сотен гигабайт. Кроме того при регулярности создания таких бэкапов расходуется ресурс накопителей на запись. Когда в случае создания бэкапа на лету, 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-диски для отдельных виртуальных машин, которые поддерживают снапшоты и прочее.
Пока что подготовлена только альфа-версия дизайна. Твоя идея с экспоненциальным расширением выглядит здраво, поэтому добавил её на внутреннее обсуждение. Она будет рассмотрена чуть позже, когда мы непосредственно доберёмся до этой части.
не подходил ли вместо всего выше описаного в статье 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, которые помогли с редактурой статьи и проверкой фактов
Без биллинга, конечно, никуда. И на данный момент мы не предлагаем решения для этой задачи.
Сейчас мы подразумеваем что у наших клиентов уже есть какой-никакой биллинг и веб-портал для заказа услуг. А наше решение является своего рода фреймворком, которое легко интегрируется и выступает в роли бэкенда:
Собственно статья больше о том, как такой бэкенд можно реализовать с использованием свободных технологий самостоятельно.
С публикациями про 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-диски для отдельных виртуальных машин, которые поддерживают снапшоты и прочее.
Пока что подготовлена только альфа-версия дизайна.
Твоя идея с экспоненциальным расширением выглядит здраво, поэтому добавил её на внутреннее обсуждение. Она будет рассмотрена чуть позже, когда мы непосредственно доберёмся до этой части.
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, которые помогли с редактурой статьи и проверкой фактов