Некоторые коллеги предлагают схему балансировки веб-нагрузки с несколькими веб-серверами (IIS7) на разных виртуальных машинах, работающих на одном оборудовании.
Действительно ли это выгодная установка? Все машины 64-битные, поэтому адресация памяти не должна быть проблемой.
Я вижу это следующим образом: с помощью виртуализации вы помещаете в песочницу некоторые ресурсы обработки. Вы разделяете веб-серверы на отдельные блоки; вы можете модернизировать сервер, пока другой будет управлять им, и можете перенаправить запросы, если возникнет проблема.
Вы можете сделать снимок виртуальной машины для отката от производственных проблем.
Вы можете более легко перенести виртуальные машины на отдельное оборудование, когда / если вы его получите, поэтому вместо переноса настроек с нуля (настройте полностью новый веб-сервер) вы можете просто переместить виртуальную машину на новую машину, или если вы настроили " «правильный» кластер - ваша виртуальная машина будет в хорошем состоянии, чтобы просто запустить ее в производство, а не перенастраивать с нуля.
При необходимости вы можете настроить отдельные VSwitches для сетевых адаптеров для управления потоком трафика.
Я думаю, что это обеспечивает большую гибкость и возможности в будущем иметь несколько машин на хосте виртуальной машины, обслуживающих ваш веб-сайт.
С другой стороны, если у вас только один хост, у вас могут возникнуть проблемы с точкой отказа. Если у вас есть как минимум два сетевых адаптера, это помогает смягчить его (например, вы можете выделить сетевой адаптер для конкретной виртуальной машины, в зависимости от ваших потребностей и настроек), и в зависимости от конфигурации вашего хоста некоторые проблемы будут более выраженными. Например, если объем вашего диска не является оптимальным, производительность будет снижена из-за конфликтов ввода-вывода, и вашему процессору, конечно же, придется разделить ресурсы между виртуальными машинами.
На самом деле сильная сторона виртуализации для меня - это более легкий путь управления и миграции в будущем. Я думаю, что намного проще отделить оборудование от машины, тогда, когда будет приобретено что-то лучше / больше / быстрее, вы сможете перенести установленную рабочую настройку на это оборудование с меньшим временем простоя и сложностями конфигурации. Или вы можете балансировать машины между хостами. И в нашем случае, если у нас есть проблема, есть возможность, если мы абсолютно должен был это сделать запускайте серверы как виртуальные машины на рабочих станциях до тех пор, пока для наших хост-серверов не будут получены запасные части, используя гипервизор во временной настройке, и пользователи не заметят разницы.
А моментальные снимки (в нашем случае) отлично подходят для того, чтобы убедиться, что обновления не превращают наши системы в пресс-папье при перезагрузке. Снимок, обновление (или изменение конфигурации), перезагрузка, проверка и удаление снимка, если все идет хорошо.
Так есть ли в этом смысл? Если ваш сайт интенсивно посещаем, может быть, нет, потому что у вас будет конкуренция за ввод-вывод. Если ваш сайт менее загружен и вы думаете, что в будущем получите другой хост, я настоятельно рекомендую это сделать. Я думаю, что абстрагирование от виртуализации помогает упростить добавление машин и изменение конфигурации с течением времени, но если вы ухудшаете производительность, эти накладные расходы, связанные с виртуализацией, могут немного повредить.
Вы понесете больше накладных расходов, чем запуск только одного экземпляра. Единственное преимущество будет заключаться в том, что если одна виртуальная машина выйдет из строя, у вас будет другая, готовая действовать в качестве аварийного переключения. Конечно, ваша надежность была бы лучше, если бы у вас было больше оборудования.
Одним из возможных преимуществ этого является то, что позже вы можете переместить виртуальные машины на другое оборудование и подписать больше ресурсов, но вы можете получить такое же преимущество, просто добавив больше серверов для балансировки нагрузки по мере увеличения емкости.
Я говорю да, так как это также даст вам возможность отключить одну из виртуальных машин для обслуживания, в то время как другая работает и обслуживает контент для конечных пользователей.
Не так-то просто ответить ... Он полагается на тысячи вещей ;-)
Если не учитывать все узкие места ввода-вывода (совместно используемая память, диск, сеть, процессор), то мы действительно перешли к последней части:
Для вашего Apache может быть более эффективно запускать «5 экземпляров на 100 подключениях», чем «1 экземпляр на 500 подключений», но это также может быть заархивировано, просто запуская несколько apache, или может быть лучше решить, отсортировав там apache, поместив nginx или около того впереди (намного лучше опрос соединения, все еще есть apache для запуска вашего приложения); -) ...
Кроме того: наличие «одного виртуального сервера» на хост-узле делает клонирование, резервное копирование и восстановление после сбоя более простым.
Несколько виртуальных машин, выполняющих одно и то же, скорее всего, не принесут никакой пользы (или выгоды, которую вы можете архивировать лучше другими способами)
Единственным исключением является отказоустойчивость, поэтому наличие двух виртуальных машин на одном оборудовании может помочь против SoftwareFails (segfault только на одном apache), но для этого потребуется приличная настройка.
-
Общее:
«витализация» ДА! резервные копии, клоны, перемещение
'запуск одного и того же образа несколько раз на одном оборудовании' НЕТ (да, есть также случаи, когда это может иметь смысл)
Производительность: есть чем заняться
FaultTolerance: только программное обеспечение не работает, ничего невозможного monint