Окей, ваш способ тоже работает. Но в условии когда у нас есть Nцать образов, с разными операционными системами, и тут у нас приехало на все(или на часть) обновление безопасности. Запустили все базовые виртуалки, к которым подключены образы, обновили всё, запустили подготовленный скрипт и идём пить чай.
И когда у нас много образов, экономия места внезапно становится очень существенной.
Кластеры это отдельная, большая тема. Там и с оборудованием есть заморочки, и с конкретными техническими реализациями. И тут всё зависит уже от специфики задач, цены, которую вы готовы вложить в оборудование и цены которую вы готовы вложить в персонал.
И «облака» в том виде, в котором они работают у некоторых компаний, по сути кластерами не являются ввиду отсутствия объединения мощностей нескольких серверов.
В общем если нужно что-то уровня простого мигрирования между отдельными серверами, возможно с общим хранилищем, каких то небольших наборов образов, то используйте уже существующие решения типа Cirtix XenServer, RHEV, Proxmox VE и подобных. А дальше идут уже совсем большие деньги, про которые писать особого смысла нет.
И эта статья является логическим завершением серии. Сейчас я расписал как получить базовую систему, которая позволяет просто запустить виртуальную машину, сделать её копию и развернуть её. Не более того.
Совершенно верно.
Кстати, сейчас появилось решение использующее именно cgroups для лимитирования ресурсов wiki.weldon.whipple.org/mod-cgroups я лично его не пробовал, но факт его наличия радует.
На текущий момент я бы не очень рекомендовал использовать blkio throttling, мне лично не понравилось как он работает, и это вызывает некоторые трудно диагностируемые проблемы как для виртуальной машины, так и для хост системы.
Применительно к процессорной нагрузке
У Xen есть внутренний механизм регулирования ресурсов про его качество работы ничего не могу сказать конкретного, если люди его используют значит он тоже неплохой, как мне кажется на его основе можно построить более чётку систему разграничений.
Мы используем нативный для Linux cgroups, который подходит для любого процесса в системе.
Сейчас я не берусь утверждать какой подход хуже или лучше, но ровно также Xen позволяет лимитировать ресурсы и через cgroups в том числе.
Ещё можно сделать типа изображение ключ, в котором хранится некоторая маска, которая по определённому алгоритму расшифровывает закриптованное изображение.
Во многих случаях велосипеды вполне обоснованы. Хотя бы тем что нужно встраивать что то новое в уже существующую инфраструктуру. Если понадобится, можно вполне мигрировать на другую инфраструктуру, но на это нужно время, деньги и люди.
Про «невозможно» я говорил касаясь конкретно libguestfs, там можно скопировать какие то участки с начала диска, но конкретно нужную часть вырезать у диска без примеренения нормальных языков, как раз невозможно.
«Не очень хорошо» касаясь того, что для собственных нужд bash очень хорошо подходит, а когда нужно сделать что то целостное, то лучше перенести всё это в какую-то одну сущность.
Про OpenStack знаю, спасибо, но в ближайшее время мы API открывать не будем. Позже — вполне возможно, но не прямо сейчас.
Ок.
Представим ситуацию, у нас есть N серверов, к которым у нас есть доступ через некоторое API, допустим SOAP, через который мы управляем конфигурацией хост машин, занимаемся деплойментом виртуальных машин, изменением их конфигураций, управлением этимим виртуалками. + Ко всему этому сбор статистики, нотификации и прочее.
И в самом низком уровне у вас лежит набор bash скриптов, которые вы дёргаете через exec с какими-либо параметрами?
Как то это не очень хорошо.
С известными извращениями на bash я даже делал генератор статического сайта(и один раз делал не очень статического), но зачем если всё тоже самое можно сделать намного проще, на тех языках, которые предназначены для этого.
Я с lvm и libguestfs особо не работал, но вообще действительно, для изменения раздела lvm нужны рутовые права.
Я для частных нужд советую использовать именно LVM, поскольку тогда не будет лишней прослойки в виде файловой системы и администратор может более гибко распределять ресурсы диска, а для нужд хостинга разумно использовать raw или qcow2 образы.
На bash реализовать клонирование невозможно, потому что при клонировании нужно копировать загрузочную запись. Нужно обязательно использовать более мощные языки.
+ API необходимо когда вы делаете некоторую более серьёзную работу с виртуалками, нежели обычное клонирование.
Когда будем предоставлять услуги Windows виртуалок, тогда напишу. Но в принципе в msdn должно быть написано что нужно менять, а вообще windows как мне кажется лучше ставить с установочного диска, а изменение размера вполне возможно для ntfs из linux.
Какие извращения? Берёте с сайта библиотеку, ставите и получаете результат.
Извращения со сборкой начинаются, когда нужно добавить какой-то функционал, да и то проблемы в основном при сборке из git. Из уже готовых архивов всё намного проще.
Для kpartx нужны рутовые права + у kpartx нет развесистого API для работы с кучей языков программирования. И по большому счёту libguestfs предоставляет возможность использовать её в том числе и для массовых манипуляций с конфигами виртуалок.
+ В составе libguestfs есть демон guestfsd, который можно запускать внутри системы и через канал в libvirt общаться с живой операционкой.
И когда у нас много образов, экономия места внезапно становится очень существенной.
И «облака» в том виде, в котором они работают у некоторых компаний, по сути кластерами не являются ввиду отсутствия объединения мощностей нескольких серверов.
В общем если нужно что-то уровня простого мигрирования между отдельными серверами, возможно с общим хранилищем, каких то небольших наборов образов, то используйте уже существующие решения типа Cirtix XenServer, RHEV, Proxmox VE и подобных. А дальше идут уже совсем большие деньги, про которые писать особого смысла нет.
И эта статья является логическим завершением серии. Сейчас я расписал как получить базовую систему, которая позволяет просто запустить виртуальную машину, сделать её копию и развернуть её. Не более того.
Кстати, сейчас появилось решение использующее именно cgroups для лимитирования ресурсов wiki.weldon.whipple.org/mod-cgroups я лично его не пробовал, но факт его наличия радует.
У Xen есть внутренний механизм регулирования ресурсов про его качество работы ничего не могу сказать конкретного, если люди его используют значит он тоже неплохой, как мне кажется на его основе можно построить более чётку систему разграничений.
Мы используем нативный для Linux cgroups, который подходит для любого процесса в системе.
Сейчас я не берусь утверждать какой подход хуже или лучше, но ровно также Xen позволяет лимитировать ресурсы и через cgroups в том числе.
А зелёный чай у меня обычно настолько крепкий, что лучше уж кофе :)
Во многих случаях велосипеды вполне обоснованы. Хотя бы тем что нужно встраивать что то новое в уже существующую инфраструктуру. Если понадобится, можно вполне мигрировать на другую инфраструктуру, но на это нужно время, деньги и люди.
«Не очень хорошо» касаясь того, что для собственных нужд bash очень хорошо подходит, а когда нужно сделать что то целостное, то лучше перенести всё это в какую-то одну сущность.
Про OpenStack знаю, спасибо, но в ближайшее время мы API открывать не будем. Позже — вполне возможно, но не прямо сейчас.
Представим ситуацию, у нас есть N серверов, к которым у нас есть доступ через некоторое API, допустим SOAP, через который мы управляем конфигурацией хост машин, занимаемся деплойментом виртуальных машин, изменением их конфигураций, управлением этимим виртуалками. + Ко всему этому сбор статистики, нотификации и прочее.
И в самом низком уровне у вас лежит набор bash скриптов, которые вы дёргаете через exec с какими-либо параметрами?
Как то это не очень хорошо.
С известными извращениями на bash я даже делал генератор статического сайта(и один раз делал не очень статического), но зачем если всё тоже самое можно сделать намного проще, на тех языках, которые предназначены для этого.
Я для частных нужд советую использовать именно LVM, поскольку тогда не будет лишней прослойки в виде файловой системы и администратор может более гибко распределять ресурсы диска, а для нужд хостинга разумно использовать raw или qcow2 образы.
На bash реализовать клонирование невозможно, потому что при клонировании нужно копировать загрузочную запись. Нужно обязательно использовать более мощные языки.
+ API необходимо когда вы делаете некоторую более серьёзную работу с виртуалками, нежели обычное клонирование.
Извращения со сборкой начинаются, когда нужно добавить какой-то функционал, да и то проблемы в основном при сборке из git. Из уже готовых архивов всё намного проще.
+ В составе libguestfs есть демон guestfsd, который можно запускать внутри системы и через канал в libvirt общаться с живой операционкой.