В интересное время живём: мне кажется что ещё пара лет максимум и всякие фуджитсу и хьюлет паккарды-эйдиэсы с их непробиваемыми change control и service request процедурами канут в лету и останутся в виде реселлеров железячного пространства. Уже сейчас народу гораздо легче сделать себе сервера при помощи Puppet/Chef или Fabric, чем запросить чтобы хостинг провайдер сделал это вручную, с ошибками и дорогими недочётами, содрав за это хорошие деньги.
По долгу службы приходится общаться с HP/EDS Эти индусские работяги предоставляют сервера для хостинга нашего софта. Все эти сервера виртуальные, но отношение к ним как к железякам. Вот, например, попросили мы дать нам ещё пару серверов точно таких-же, как уже работающие. Казалось бы, этот запрос делается в течение получаса, максимум: клонируется уже существующий и запускается. В реальности это занимает неделю: сначала пишутся бумаги, потом пинг-понг из емейлов на тему “что вы имели ввиду под термином ‘100% как уже существующие'” и потом мы выискиваем недочёты – так как сервера всё равно были сделаны “с нуля”. Или, вот ещё смехотворная ситуация: вместо того, чтобы сделать снапшот виртуального сервера перед деплойментом новой версии и откатиться на этот снапшот если что-то не получилось, эти весельчаки будут восстанавливать сервер из вчерашнего бэкапа. То есть никто не пользуется преимуществами виртуализации. Всё как по-старому, только работает медленнее.
Я, конечно, понимаю, что такая бодяга сделана только для того, чтобы максимизировать время, потраченное на производство работ, потому как работы оплачиваются по схеме time and materials. Но если раньше альтернативы не было, то сейчас есть. И бизнесы, покупающие “услуги” таких провайдеров, начинают оглядываться на альтернативы и разговаривать уже совсем по-другому. Так что даю пару лет на вымирание или на перевоплощение.
А я тем временем запустил под kvm/Ubuntu на обычном десктопе четыре Windows XP и подключил их к боевому билд серверу для запуска на них всяческих функциональных тестов. В режиме ожидания (это их обычное состояние) они отъедают каких-то 6-8% от четырёхядерного процессора.
Согласен со всем перечисленным. Однако не так все хорошо в этих cloud
environments. Мы пользуемся Terremark и первое что бросается в глаза, так это
совершенно отстойный IO performance. Приходится плясать с бубенами, чтобы
выжать как можно больше из предоставляемого их SANом сервиса. Проблему
усугубляет и еще то, что когда VMWare решает что ей нужно почистить память, то
она запускает свой bubble driver, который не только убивает IO, так еще и
отжырает CPU. И, кстати, не понятно почему, но Terremark не дает работать со
snapshot-ами, хотя эта проблема просто решается с ребилдином сервера и
запустанием на нем puppet agent.
Один из критериев выбора провайдеров теперь будет “сколько у вас виртуальных машин на один CPU” как чуть критерий у обычных провайдеров “сколько серверов на стойку”. :)
Согласен со всем перечисленным. Однако не так все хорошо в этих cloud
environments. Мы пользуемся Terremark и первое что бросается в глаза, так это
совершенно отстойный IO performance. Приходится плясать с бубенами, чтобы
выжать как можно больше из предоставляемого их SANом сервиса. Проблему
усугубляет и еще то, что когда VMWare решает что ей нужно почистить память, то
она запускает свой bubble driver, который не только убивает IO, так еще и
отжырает CPU. И, кстати, не понятно почему, но Terremark не дает работать со
snapshot-ами, хотя эта проблема просто решается с ребилдином сервера и
запустанием на нем puppet agent.
Один из критериев выбора провайдеров теперь будет “сколько у вас виртуальных машин на один CPU” как чуть критерий у обычных провайдеров “сколько серверов на стойку”. :)
Не уверен на счет этого критерия (vm per cpu), учитывая что провайдеры на vmware основе могут узать DRM (http://download3.vmware.com/demos/dpm/39848_DPMVideo_R4.html). CPU в нашем случает не является проблемой, а вот Disk IO сосет конкретно. Я слышал те же проблемы у амазона.
Не уверен на счет этого критерия (vm per cpu), учитывая что провайдеры на vmware основе могут узать DRM (http://download3.vmware.com/demos/dpm/39848_DPMVideo_R4.html). CPU в нашем случает не является проблемой, а вот Disk IO сосет конкретно. Я слышал те же проблемы у амазона.