Skip to content

Hosting Providers

В интересное время живём: мне кажется что ещё пара лет максимум и всякие фуджитсу и хьюлет паккарды-эйдиэсы с их непробиваемыми change control и service request процедурами канут в лету и останутся в виде реселлеров железячного пространства. Уже сейчас народу гораздо легче сделать себе сервера при помощи Puppet/Chef или Fabric, чем запросить чтобы хостинг провайдер сделал это вручную, с ошибками и дорогими недочётами, содрав за это хорошие деньги.

По долгу службы приходится общаться с HP/EDS Эти индусские работяги предоставляют сервера для хостинга нашего софта. Все эти сервера виртуальные, но отношение к ним как к железякам. Вот, например, попросили мы дать нам ещё пару серверов точно таких-же, как уже работающие. Казалось бы, этот запрос делается в течение получаса, максимум: клонируется уже существующий и запускается. В реальности это занимает неделю: сначала пишутся бумаги, потом пинг-понг из емейлов на тему “что вы имели ввиду под термином ‘100% как уже существующие'” и потом мы выискиваем недочёты – так как сервера всё равно были сделаны “с нуля”. Или, вот ещё смехотворная ситуация: вместо того, чтобы сделать снапшот виртуального сервера перед деплойментом новой версии и откатиться на этот снапшот если что-то не получилось, эти весельчаки будут восстанавливать сервер из вчерашнего бэкапа. То есть никто не пользуется преимуществами виртуализации. Всё как по-старому, только работает медленнее.

Я, конечно, понимаю, что такая бодяга сделана только для того, чтобы максимизировать время, потраченное на производство работ, потому как работы оплачиваются по схеме time and materials. Но если раньше альтернативы не было, то сейчас есть. И бизнесы, покупающие “услуги” таких провайдеров, начинают оглядываться на альтернативы и разговаривать уже совсем по-другому. Так что даю пару лет на вымирание или на перевоплощение.

А я тем временем запустил под kvm/Ubuntu на обычном десктопе четыре Windows XP и подключил их к боевому билд серверу для запуска на них всяческих функциональных тестов. В режиме ожидания (это их обычное состояние) они отъедают каких-то 6-8% от четырёхядерного процессора.

  • Ksibilev

    Согласен со всем перечисленным. Однако не так все хорошо в этих cloud
    environments. Мы пользуемся Terremark и первое что бросается в глаза, так это
    совершенно отстойный IO performance. Приходится плясать с бубенами, чтобы
    выжать как можно больше из предоставляемого их SANом сервиса. Проблему
    усугубляет и еще то, что когда VMWare решает что ей нужно почистить память, то
    она запускает свой bubble driver, который не только убивает IO, так еще и
    отжырает CPU. И, кстати, не понятно почему, но Terremark не дает работать со
    snapshot-ами, хотя эта проблема просто решается с ребилдином сервера и
    запустанием на нем puppet agent.

    • Ctpeko3a

      Один из критериев выбора провайдеров теперь будет “сколько у вас виртуальных машин на один CPU” как чуть    критерий у обычных провайдеров “сколько серверов на стойку”. :)

  • Ksibilev

    Согласен со всем перечисленным. Однако не так все хорошо в этих cloud
    environments. Мы пользуемся Terremark и первое что бросается в глаза, так это
    совершенно отстойный IO performance. Приходится плясать с бубенами, чтобы
    выжать как можно больше из предоставляемого их SANом сервиса. Проблему
    усугубляет и еще то, что когда VMWare решает что ей нужно почистить память, то
    она запускает свой bubble driver, который не только убивает IO, так еще и
    отжырает CPU. И, кстати, не понятно почему, но Terremark не дает работать со
    snapshot-ами, хотя эта проблема просто решается с ребилдином сервера и
    запустанием на нем puppet agent.

    • Ctpeko3a

      Один из критериев выбора провайдеров теперь будет “сколько у вас виртуальных машин на один CPU” как чуть    критерий у обычных провайдеров “сколько серверов на стойку”. :)

  • Ksibilev

    Не уверен на счет этого критерия (vm per cpu), учитывая что провайдеры на vmware основе могут узать DRM (http://download3.vmware.com/demos/dpm/39848_DPMVideo_R4.html). CPU в нашем случает не является проблемой, а вот Disk IO сосет конкретно. Я слышал те же проблемы у амазона.

  • Ksibilev

    Не уверен на счет этого критерия (vm per cpu), учитывая что провайдеры на vmware основе могут узать DRM (http://download3.vmware.com/demos/dpm/39848_DPMVideo_R4.html). CPU в нашем случает не является проблемой, а вот Disk IO сосет конкретно. Я слышал те же проблемы у амазона.