Когда НЕ использовать виртуализацию?

Когда виртуализация была новой, мы пытались виртуализировать все, но затем мы заметили случаи использования, когда наши виртуальные машины работали намного медленнее, чем голые металлы.

Для нас мы используем следующие правила при принятии решения не виртуализировать:

  • Сетевые приложения с интенсивным вводом-выводом (то есть со многими прерываниями / пакетами)
  • Приложения с интенсивным дисковым вводом-выводом (если не в хранилище SAN)
  • Объем оперативной памяти (это самый ценный ресурс)

У нас был такой опыт работы с Xen и DRDB, а Hyper-V делился ничем с DAS. Это относится ко всем гипервизорам?

Какие (другие) показатели мне следует искать при принятии решения о виртуализации приложения / сервера или нет?

Источник

2 ответа

Решение

Вы затронули основные показатели в своем вопросе:

  • Сетевой ввод-вывод
    Вы хотите быть уверены, что предлагаемая рабочая нагрузка по виртуализации не приведет к насыщению сетевого подключения вашей хост-системы. В наши дни для 10-гигабитных сетевых адаптеров это не проблема для крупных предприятий, и малые предприятия часто могут получить необходимую производительность от гигабитных (или объединенных / агрегированных гигабитных) сетевых адаптеров.

  • Дисковый ввод-вывод
    Вы хотите быть уверены, что ваша дисковая подсистема (локальные диски, SAN, NAS) может обрабатывать дисковый ввод-вывод, который вы предлагаете.
    При определении этого размера имейте в виду, что ваша фабрика SAN (коммутаторы и т. Д.) Должна быть в состоянии справиться и с нагрузкой - у вас может быть система хранения über-SAN, которая может выдавать терабит в секунду на свои диски, но если этот монстр подключен к отвратительной 100-мегабитной матрице iSCSI, которую вы насытите своей сетью до того, как устройство хранения данных сломается

  • баран
    В частности, "активная" оперативная память (потому что неактивный материал может быть заменен гипервизором, и никто не заметит). В идеале у вас достаточно физической оперативной памяти, чтобы вашему гипервизору не приходилось менять местами. В действительности вы, вероятно, найдете счастливую среду чрезмерной приверженности.

Некоторые другие, чтобы рассмотреть:

  • ЦП (и шаблоны рабочей нагрузки)
    Если у вас есть несколько систем, которые выполняют задачи с интенсивным использованием ЦП, у вас могут возникнуть проблемы, если все они требуют одновременной загрузки процессора хост-системы. (например, если у вас 1 хост-процессор и 3 виртуальные машины, которые хотят сократить число в полночь, каждая виртуальная машина увидит только ~1/3 производительности центрального процессора, поскольку гипервизор пытается разделить оспариваемый ресурс между ними).
    С другой стороны, если у вас есть несколько систем, которые выполняют задачи с интенсивным использованием ЦП в разное время (например, в полночь, 3:00 и 6:00, и всегда заканчивают работу до того, как следующий парень начнет работу), вы можете виртуализировать их, и они никогда не будут знать разницу.

  • Изготовленное на заказ оборудование
    Некоторые гипервизоры (например, VMWare) разрешают PCI и Storage Pass-thru. Другие не могут.
    Если вам нужен доступ к оборудованию на хосте (например, графическая карта или прямой доступ к диску), вам необходимо учитывать это при планировании виртуализации.

  • Хронометраж
    Гипервизоры преуспели в этом, но задачи точного хронометража все еще лучше подходят для выделенных физических серверов. Например, основным NTP-сервером вашей организации должен быть физический хост (или маршрутизатор, если ваши маршрутизаторы способны выступать в качестве NTP-серверов).

  • Вещи, которые обычно не виртуализируются хорошо
    По этому поводу есть много анекдотических данных, поэтому проведите небольшое исследование, прежде чем что-то виртуализировать.
    В качестве нескольких примеров, проблемы хронометража, о которых я упоминал выше, системы VOIP (например, Asterisk PBX) и интенсивно используемые базы данных, как правило, являются плохими кандидатами для виртуализации (первые два из-за проблем точности хронометража, базы данных, как правило, потому что они вызывают, и страдают от нехватки ресурсов больше, чем другие нагрузки).
    Каждая компания собирает локальный список вещей, которые, как они знают, они не могут виртуализировать - поскольку вы находите свои товары, обязательно документируйте их (включая причину, если в один прекрасный день вы получите гипервизор, который решит проблему).

Источник

Как было отмечено в комментариях, не все программное обеспечение для виртуализации одинаково.

http://wiki.openvz.org/FAQ

Каковы потери производительности? Около нуля. Там нет уровня эмуляции, только изоляция безопасности, и вся проверка выполняется на уровне ядра без переключения контекста.

Каковы ожидания производительности? Пиковая производительность достигается, когда только один контейнер имеет активные задачи. В этом случае он может использовать 100% доступных ресурсов: все процессоры, всю физическую память, всю пропускную способность диска и сети. OpenVZ не ограничивает вас виртуальной машиной с одним ЦП.

Хотя это может показаться не отвечением: нет общих условий, в которых вы не должны использовать виртуализацию. Теперь у меня есть привычка развертывать оборудование с помощью всего одного контейнера OpenVZ: их очень легко перенести с помощью предоставленных инструментов из-за абстракции оборудования, которую обеспечивает виртуализация. Как небольшой побочный эффект, стоимость лицензий на программное обеспечение, как правило, тоже дешевле.

Источник
Другие вопросы по тегам