Какие технические критерии используют люди при проверке пригодности приложений для виртуализации? Я знаю, что несколько лет назад ситуация немного изменилась, поэтому мне хотелось бы узнать об опыте людей и их методологии при рассмотрении технической пригодности. Для справки я смотрю как на устаревшие, так и на новые приложения для сборки.
Размер
Загрузить
Ввод / вывод
и т.д...
Ура, Марк
Как бы я ни ненавидел модные словечки, я должен отстаивать то, что вы Целостный подход, вместо того, чтобы пытаться установить базовые метрики, по которым можно классифицировать ваши рабочие нагрузки для виртуализации.
Проще говоря, вы можете использовать следующие основные определяющие факторы:
Также будьте осторожны Опасности методологии. Виртуализация бизнес-среды требует навыков, опыта и немного творческого мышления для правильного выполнения, и вам придется вдумчиво объединить среду, которую вы можете предоставить, с рабочими нагрузками, которые вам необходимо поддерживать, в то же время объединяя целую кучу бизнес-требования и постепенное улучшение инфраструктуры. Вы жестяная банка напишите руководство для этого материала, но результат такого подхода не принесет максимальной пользы для бизнеса.
Обычно на песке не обязательно есть линия, которую вы пересекаете, и внезапно одно решение оказывается лучше другого. У виртуализации есть свои плюсы и минусы, и если да, то в облаке или дома.
Вам действительно нужно взять конкретный вариант использования, выяснить плюсы и минусы каждого решения по отношению к этому варианту использования, затем расставить приоритеты для каждого из плюсов и минусов для вашего клиента и выбрать решение. Для этого нет точной формулы, потому что один и тот же профессионал может спасти жизнь одному клиенту, в то время как один и тот же профессионал для одного и того же приложения может не иметь значения для другого. То же самое и с минусами: нарушение сделки для одной компании может не иметь значения для другой.
Конечно, пригодность приложения имеет значение, но когда возможны оба маршрута, это больше касается приоритетов преимуществ и недостатков, чем каких-либо магических чисел ввода-вывода / процессора / нагрузки.
Во-первых, я согласен с тем, что вам нужно убедиться, что поставщики поддерживают или даже разрешают виртуализацию своих приложений. У нас есть одно довольно важное приложение, которое допускает виртуализацию, но оставляет за собой право заставить нас загрузить приложение на физический сервер, если этого требует устранение неполадок. У нас есть другие приложения, которые вообще не поддерживают виртуализацию.
Во-вторых, какое оборудование хоста виртуализации вы ищете? Если у вас достаточно мощности, вы можете виртуализировать что угодно, но если у вас недостаточно мощности, вы можете вызвать серьезные проблемы с производительностью.
В-третьих, вас устраивает виртуализация критически важного программного обеспечения? Вы можете подумать о наличии кластера или нескольких виртуальных хостов, чтобы в случае отказа одного из хостов половина вашей инфраструктуры не была нарушена.
И, наконец, самый большой критерий для нас, когда речь идет о некритичных приложениях, - насколько мощным является оборудование, на котором в настоящее время установлено приложение? У нас было несколько мощных серверов, которые делали одну мелочь, и нам хорошо помогала виртуализация. Кроме того, здесь очень важна замена старого оборудования. В Sysinternals есть инструмент под названием disk2vhd, который создаст файл vhd (если вы используете Hyper-V или виртуальный сервер) с физического диска, и нам очень повезло с виртуализацией существующих физических экземпляров с его помощью.