Это сложный вопрос, так как я очень мало знаю об этой теме. Пожалуйста, потерпите меня.
С моей точки зрения, поддерживая относительно небольшое количество машин, концепция виртуализации имеет одно интригующее преимущество: независимость от оборудования. Возможно, это неправильный способ сказать это, но мне действительно нравится идея взять всю машину и перенести ее на любое подходящее оборудование.
Конечно, я знаю, что это возможно, но с виртуальными дисками и производительностью все становится непросто. Если вы используете сквозную передачу на диск, ваша виртуальная машина по-прежнему привязана к определенному оборудованию.
Существуют ли сегодня технологии, позволяющие легко упаковать машину и ее диски и перенести их на другое оборудование таким образом, чтобы не сильно повлиять на производительность ввода-вывода? Так же просто, как скопировать образ виртуального диска на новую машину? Возможно ли это с бесплатными решениями от VMware, Microsoft и т.п.?
(Когда я говорю о производительности, я не говорю ни о чем серьезном ... просто о стандартных решениях для малого и среднего бизнеса: ERP, почта и т. Д.)
Аппаратная независимость - это как раз правильный взгляд на это: разделение сервисов, на которые вы полагаетесь, от аппаратного обеспечения - главное преимущество виртуализации.
Ваш вопрос о переносимости и производительности ввода-вывода не совсем ясен, но я думаю, что понимаю, к чему вы клоните.
Практически все гипервизоры, конечно, все основные (VMware, Microsoft, Xen, KVM) позволяют без проблем выключить виртуальную машину и переместить ее в другое хранилище или на совершенно другой хост, ваша единственная проблема будет связана с тот факт, что вы обычно копируете очень большой объем данных. У большинства поставщиков есть несколько гипервизоров, и в целом довольно просто переместить виртуальную машину с (скажем) VMware Workstation на VMware Server на VMware ESX. Перемещение между поставщиками гипервизоров немного сложнее и потребует некоторого преобразования, но, опять же, все основные производители в той или иной степени поддерживают это. В общем, если виртуальная машина выключена, ее можно переместить без проблем, чем скопировать большой файл.
Переместить виртуальные машины с минимальным временем простоя (или без него) намного сложнее, но все основные поставщики предоставляют некоторую версию этого сейчас. В VMware это называется VMotion, Microsoft - Live Migration, Citrix (Xen) - XenMotion или Live Motion. Все это требует общего хранилища (SAN или NAS) и налагает довольно жесткие ограничения на разнообразие оборудования, которое вы можете иметь в своем кластере, но они позволят вам переместить работающую виртуальную машину с одного хоста на другой в управляемом кластере с близкое к нулю (диапазон миллисекунды \ субмиллисекунды) прерывание обслуживания. Это очень желательная функция и, как правило, требует дорогих лицензий, как указал Барт Сильверстрим в своем ответе, но Microsoft HyperV 2008 R2 Server позволяет создавать такой кластер, используя только бесплатные (как в пиве) компоненты, что довольно интересно так как сделать Citrix . Самые дешевые лицензии от VMware, которые поддерживают это, стоят около 2 тысяч долларов за процессор, если я правильно помню, но вы не можете спорить с ценой Citrix или Microsoft, если хотите создать что-то небольшое. VMware, пожалуй, лучшая из всех, но чтобы получить от нее все, вам придется заплатить немало. Xen более зрелый, чем Hyper-V, но Microsoft добилась огромного прогресса за последние 18-24 месяца, поэтому не стоит сбрасывать со счетов. Vmotion \ Live Migration не оказывает существенного влияния на производительность дискового ввода-вывода.
Вариант VMotion \ Live Migration включает в себя оставление виртуальной машины работающей на том же хосте, но перемещение базового хранилища без остановки виртуальной машины. Это еще более дорогой вариант лицензирования от VMware (они называют его Storage VMotion). У Microsoft есть «Быстрая миграция хранилища», которая похожа, но, насколько мне известно, не совсем гладкая. Обратите внимание, что процесс копирования по-прежнему занимает много времени, и он окажет влияние, возможно, значительно повлияет на общую производительность хранилища во время миграции.
Что касается производительности жесткого диска виртуальной машины, вы должны помнить несколько вещей. Все гипервизоры довольно хороши - вы должны ожидать увидеть 80% + собственной производительности даже в экстремальных условиях, и по большей части, если у вас нет очень странных шаблонов ввода-вывода хранилища, вы можете с уверенностью предположить, что 95% или выше. По сути, хорошо спланированную реализацию с хорошей подсистемой хранения трудно отличить от собственного решения. Вам нужно знать, какая производительность потребуется вашей виртуальной машине, а затем вы должны предоставить ее, а также любую дополнительную производительность, необходимую для предоставления чего-либо дополнительного (например, Live Migration \ отказоустойчивость и т. Д.). Как и в случае с чем-либо другим (ЦП, память, пропускная способность сети), если вы не можете обеспечить достаточную емкость хранилища (последовательная пропускная способность, пространство, IOPS), ваше решение будет плохо работать. Лучший способ подойти к планированию для этого - получить хорошее представление об общих характеристиках хранилища, которые вам нужны (опять же, ГБ полезного пространства, пиковое общее количество операций ввода-вывода в секунду, пиковая пропускная способность) добавить все, что вам нужно для неминуемого роста, и убедиться, что решение для хранения то, что вы вводите, может обеспечить это.
Как правило, для сред размещения виртуальных машин тратятся деньги на память, убедитесь, что у вас достаточно мощности процессора и для хранения (по крайней мере, пока мы не получим дешевое хранилище SSD), купите хороший RAID-контроллер \ SAN \ NAS и постарайтесь купить столько дисков, сколько вы можете - 2 ТБ хранилища, которые поступают из дисков 8x250 ГБ, будут существенно превосходить диски 2x1 ТБ при прочих равных условиях.
Я не думаю, что вы спрашиваете о функциях живой миграции, таких как VMotion. Я думаю, вы просто спрашиваете:
Как мне делать такие вещи, как открывать необработанные блочные устройства / LUN для моих виртуальных машин («IO pass through»), что, как я слышал, дает лучшую производительность, чем использование файлов виртуальных дисков внутри файловых систем, управляемых гипервизором, без отказа от оборудования - независимый характер моих виртуальных машин?
Вы нашли компромиссный вариант. Удаление слоев абстракции жестяная банка заставить вещи работать быстрее, но при этом вы отказываетесь от преимуществ абстракции. Если вы обнаружите, что вы необходимость чтобы предоставить виртуальным машинам доступ к необработанному блочному устройству для ваших виртуальных машин по соображениям производительности, затем либо планируйте «привязку» к этим блочным устройствам, либо используйте что-то вроде репликации на уровне SAN, чтобы получить некоторую независимость от устройства на более низком уровне (возможно, со своим собственным набором производительности компромиссы).
Лично я бы старался как можно больше оставаться в комфортном мире виртуальных дисков. Абстракция дает значительные преимущества.
VMWare ESXi распространяется бесплатно. Тем не менее, конкретные требования к оборудованию. Большинство из них.
Xen можно настроить для полуавтоматического аварийного переключения. (Я имею в виду Xen, а не продукт на базе xen от Citrix ... здесь имеется в виду использование Heartbeat и fencing, а также множество ручных действий с Linux, чтобы получить поддержку аварийного переключения).
Все зависит от того, чего вы ожидаете от «быстрого переезда». Vmotion оплачивается как надстройка от VMWare, и это недешево, но позволяет беспрепятственно перемещать виртуальные машины с сервера 1 на сервер 2 без перерыва и обычно требует некоторых средств общего хранилища между двумя серверами.
У нас есть система для относительно быстрого включения серверов, но она включает в себя копирование снимков наших виртуальных машин в другое место и запуск VMWare оттуда. Копирование (резервное копирование) занимает несколько часов, и я обычно отключаю серверы на часть выходных, чтобы сделать это. Однако природа наших серверов позволяет нам отключаться от сети на этот период времени. Если вы говорите о чем-то, что должно работать круглосуточно, это точно не сработает.
Для недорогой установки вы можете попробовать собрать пару серверов «белого ящика» (Google - ваш друг) по цене ~ 500 долларов за штуку, которая будет совместима с VMWare ESXi, чтобы запустить ее бесплатно, затем вы можете работать над решением для резервного копирования для копирования виртуальных машин между эти два периодически (у Veeam было несколько бесплатных утилит для копирования, хотя не знаю, требовала ли VMWare их отключения для продукта ESXi к настоящему времени). Затем, если у вас аппаратный сбой, вы можете быстро перенести в оперативный режим недавнюю резервную копию. Или, если у вас есть быстрое внешнее хранилище, вы можете использовать его для совместного использования между двумя серверами, поэтому, если сервер умер, вы можете довольно быстро запустить второй.
Большинство известных мне решений для максимального времени безотказной работы, такие как VMotion, оплачиваются в решениях на основе Xen и VMWare. Корпоративные функции приносят им прибыль. Плавное перемещение виртуальных машин - это как раз тот рынок, который готов платить за эти функции. В любом случае у вас должен быть хороший план для резервного копирования, будь то сами виртуальные машины или в сочетании с агентами резервного копирования на виртуализированных серверах, чтобы как минимум вы могли создать новые чистые серверы на другой виртуальной машине и восстанавливать с ваших резервных виртуальных серверов как если бы они были голым металлом. При использовании общего хранилища вы должны запланировать хорошие резервные копии на случай сбоя диска.
Вы должны ожидать аналогичной производительности диска, особенно при использовании необработанных LUN в SAN.
Распространенный сценарий, когда производительность диска снижается, - это невыровненный раздел. Windows 2003 и более ранние версии сделали некоторые вещи с повреждением мозга при создании нового раздела, он начинался с 64-го сектора. Результатом является смещение раздела ОС с физическим томом. В результате отдельные кластеры пользовательских данных записываются на несколько страйповых блоков RAID. Затрагивается каждая n-я операция (n зависит от размера единицы размещения файлов (кластера) и размера страйпа). Все это достаточно хорошо документировано как на веб-сайтах VMWare, так и на веб-сайтах Microsoft.
Нередко повышение производительности на 20-40% при правильном выравнивании разделов.
Вы также можете повысить производительность, используя больший размер единицы распределения NTFS, например 8 КБ. Но вы должны использовать 4k для системного раздела (где находится ntldr).
Больше информации:
http://msdn.microsoft.com/en-us/library/dd758814.aspx
Также обратите внимание на новую функцию Windows 7 / Windows 2008 R2, загрузку с vhd: