понедельник, 30 марта 2009 г.

"Композитная" виртуальная машина

Один из часто задаваемых вопросов касается "композитной" виртуальной машины. "Можно ли сделать так, чтобы ресурсы двух хостов ESX объединить в одну виртуальную машину?"

Нет, нельзя. Почему?

Кластерные суперкомпьютеры, которые позволяют "объединять" ресурсы множества узлов, строятся под задачи. ПО для работы на этих суперкомпьютерах разрабатывается специально, с учетом всех их особенностей.

Виртуальные машины в общем случае - это универсальное и неспециализированное ПО, которое даже понятия не имеет, что работает не на физическом железе. И ведет себя соответствующим образом.
Даже при использовании специальных высокоскоростных сетей, разработанных для суперкомпьютеров, задержки доступа составляют порядка микросекунды, в то время как задержка доступа к локальной памяти несколько наносекунд, т.е. объединение памяти физических машин в одну "композитную" выльется в 1000-кратное замедление скорости работы. Про процессорные шины и говорить не приходится. Да, пожалуй, если задаться подобной целью, то мы сможем в конечном итоге реализовать проект, который позволит на железе стоимостью сотни тысяч долларов создать виртуальную машину с производительностью на уровне 386 процессора. Извините, 32-процессорной машины с 386 процессорами.

Почему же все тогда говорят про "облако" и ресурсы по заказу? Все очень просто. Мы действительно может давать ресурсы по заказу и относиться к большому Fully automated DRS кластеру ESX как к облаку. Но при одном условии - каждая ВМ требует ресурсов, значительно меньших, чем ресурсы одного хоста. Как только уровень ресурсов становится сравним, облако рассеивается на отдельно стоящие хосты.

Виртуальные машины могут многое, и избавляют нас от многих забот, но они могут не все. И даже при всей автоматизации управления виртуальной инфраструктурой, не следует забывать то, что в первую очередь виртуальные машины - это консолидация серверов, деление ресурсов очень мощного хоста между виртуальными машинами. Если нам надо больше ресурсов для ВМ, чем есть у хоста, то вывод может быть только один - виртуализация здесь не нужна и проблемы с правильным проектированием, а не с недостатком возможностей платформы виртуализации.

4 комментария:

  1. Уважаемый Антон.
    Hyper-V делает 10Гит/с виртуальные LAN.
    Можно ли в VMWare'вских VM машинах с host-only LAN поднять скорость передачи более 1Гбит/с ?
    PS: На железных хостах установлены VMWare Server 1.0.8 или Server 2.0

    ОтветитьУдалить
  2. Для начала, сравнение VMware Server с Hyper-V некорректно. Сравнивать в данном случае надо VMware Server и Microsoft Virtual Server, или ESX с Hyper-V.

    Насколько мне известно, в ESX нет четкого ограничения скорости сети в 1Гбит/с, при использовании enhanced vmxnet прокачиваться через интерфейс будет столько, сколько способна "переварить" ВМ.

    ОтветитьУдалить
  3. При подключении Hyper-V VM к хосту по host-only LAN скорость чтения файла (большого) равна скорости винчестера.
    При подключение VMWare VM (Server 1.X/Server 2.0) к хосту по host-only LAN скорость чтения файла (большого) равна 45-55Mбайт/с. Такая же скорость при подключении VMWare VM с другого хоста к этому хосту ("железному" ПК). Такая же скорость при подключении другого компа к этому хосту. Такая же скорость при подключении VMWare VM по bridget LAN к хосту. Если адаптер, связанный с bridget LAN воткнуть в 100Мбит/с порт, то скорость падает до 9Мбайт/с.
    Т.е. скорость в host-only ограничена 1Гбит/с.
    PS: а что такое enhanced vmxnet? Стандартный сетевой адаптер из VMWare tools или отдельно надо скачивать?

    ОтветитьУдалить
  4. VMware Server - монитор виртуальных машин, аналог Microsoft Virtual Server 2005, с которым и должен сравниваться.

    Hyper-V - гипервизор, и сравнивать соотв. его нужно с VMware ESX/ESXi.

    Вот только что для примера померял скорость чтения файла с винчестера (новый, SATA) - около 100MB/s. Что является показателем в пределах возможностей 1Gbps сетевой карты.

    10 Gbps железа у меня в доступности нет, не могу проверить.

    ОтветитьУдалить