Списать или перепрофилировать аппаратное обеспечение?
В процессе миграции, особенно когда рабочие нагрузки виртуализованы, может возникнуть вопрос, звучащий примерно так: «Что теперь делать с голым железом, раз нагрузки перенесены?»
Вопрос весьма актуальный. Мне известно несколько случаев, когда миграция из физической среды в виртуальную была заблокирована по политическим соображениям, потому что не существовало четкого ответа на вопрос, что же теперь делать с дорогим сервером, купленным несколько лет назад. В некоторых организациях руководство считает, что дорогостоящее оборудование должно использоваться до тех пор, пока оно не развалится. И с этой точки зрения виртуализация рабочих нагрузок представляется несколько расточительной.
Подобно компаниям, которые не расстались с Windows Server 2003, не видя смысла заменять то, что работает, некоторые структуры продолжают использовать прежнее оборудование, ведь «оно по-прежнему работает, и мы постараемся извлечь из него как можно больше пользы».
Есть множество задач, которые вы можете решить на отработавшем свои нагрузки железе. В большинстве организаций отмечается хронический недостаток финансирования тестовых лабораторий. Перепрофилирование оборудования в тестовую среду позволяет расширить тестовые лаборатории без ощутимых затрат.
В качестве альтернативы, благодаря улучшениям, реализованным в SMB 3.0, компьютер, который в достаточной мере справляется с функцией файлового сервера при работе операционной системы Windows Server 2003, будет способен на большее с Windows Server 2012 или Windows Server 2012 R2.
Тот факт, что вы не можете перейти непосредственно с Windows Server 2003 на Windows Server 2012 R2, вовсе не означает, что, как только вы перенесли рабочие нагрузки с сервера, физически работающего с Windows Server 2003, вы не сможете установить свежую копию Windows Server 2012 R2, чтобы дать оборудованию новую жизнь.
Министерство национальной безопасности предупреждает о прекращении поддержки Windows Server 2003
US-CERT, компьютерная команда экстренной готовности США (United States Computer Emergency Readiness Team) напоминает о предстоящем прекращении расширенной поддержки Windows Server 2003. Данное предупреждение свидетельствует, что это не абстрактная проблема, касающаяся лишь небольшой части общества, а вопрос, который обсуждается на самых высоких уровнях власти.
В предупреждении говорится:
«Компьютерные системы, на которых установлено неподдерживаемое ПО, подвергаются повышенному риску, связанному с угрозами кибербезопасности, такими как вредоносные атаки и потери электронных данных.
У пользователей могут возникнуть проблемы с совместимостью программного обеспечения и аппаратных средств, поскольку новые приложения и оборудование не могут создаваться для Windows Server 2003.
Организации, чья деятельность регулируется нормативными обязательствами, не смогут соответствовать нормативным требованиям, работая под управлением Windows Server 2003».
Если у вас возникли трудности с тем, чтобы убедить сотрудников вашей компании, ответственных за поддержку Windows Server 2003, предпринять какие-то действия, покажите им критические замечания Министерства национальной безопасности, и, возможно, тогда они расставят верные приоритеты.
Текст предупреждения можно найти по адресу: https://www.us-cert.gov/ncas/alerts/TA14-310A
Представление об объединении
Когда был выпущен Windows Server 2003, развертывание инфраструктуры серверов Windows происходило главным образом не в виртуальной, а в физической среде. Когда большая часть рабочих нагрузок размещалась на «голом железе», организации в основном изолировали нагрузки. Производственный сервер будет размещать Exchange или SQL Server, но вы не будете устанавливать Exchange или SQL Server на одном и том же физическом сервере, который используется в производственной среде. Развертывая Exchange и SQL Server, вы держите их на отдельных серверах.
С приходом Windows Server 2012 и Windows Server 2012 R2 ожидается, что большинство развертываний будет виртуальным, а не физическим. Это означает, что если вы хотите, к примеру, развернуть Exchange и SQL Server на одной и той же виртуальной машине, вы, вероятно, развернете виртуальную машину с работающим Exchange и виртуальную машину с SQL Server на одном базовом сервере с виртуальными машинами.
Ключом к объединению рабочих нагрузок является понимание профиля использования ресурса каждой рабочей нагрузки. Вы стараетесь найти баланс на базовом сервере виртуализации таким образом, чтобы ни одна из комбинаций рабочих нагрузок в конечном итоге не монополизировала отдельный аппаратный ресурс, будь это процессор, RAM, хранилище или сеть. Например, если у вас несколько процессоров с интенсивными рабочими нагрузками, вы, вероятно, захотите избежать развертывания виртуальных машин на одном хосте виртуализации. Тем не менее, вы можете развернуть процессорную рабочую нагрузку, которая не требует большого объема ресурсов хранения, и нагрузку, выполняющую множество операций чтения и записи, но не требующую значительных процессорных ресурсов на одном хосте виртуализации.
В современной сложной среде вы можете использовать такие функции, как Performance and Resource Optimization, имеющиеся в комплексе System Center, которые посредством диспетчеров Operations Manager и Virtual Machine Manager помогают осуществлять миграцию виртуальных машин между узлами кластеров таким образом, чтобы распределение ресурсов было сбалансированным. Преимущество автоматического метода перемещения виртуальных машин, равно как и изменение необходимых ресурсов, заключается в том, что снижается вероятность неожиданных «всплесков» в распределении ресурсов, которые способны остановить рабочий процесс на хосте.
Миграция Windows Server 2003: местный хостинг или виртуальные машины в облаке?
При переносе рабочих нагрузок с Windows Server 2003 на Windows Server 2012 R2 следует разместить их локально в виртуальной машине на хосте виртуализации или в общем «облаке»?
У многих организаций уже есть серверы, устанавливаемые в стойку для использования в центрах обработки данных. Если ваши серверы Windows Server 2003 находятся здесь, перенос рабочих нагрузок в общее «облако» и запуск их как виртуальных машин на общедоступной платформе IaaS не будет шагом вперед. Вы всего лишь переходите от физического хостинга на чужом оборудовании к виртуальному хостингу опять же на чужом оборудовании.
Также важно понимать, что относительно «облака» нет необходимости руководствоваться принципом «все или ничего». Вы можете перенести некоторые рабочие нагрузки таким образом, чтобы установить их как виртуальные машины у поставщика услуг IaaS или в общем «облаке» на ресурсах платформы PaaS, а другие пока оставить локально.
Существует два типа нагрузок, которые не должны переноситься в «облако»:
- Рабочие нагрузки, которые вы не можете запустить в «облаке», к примеру, из-за организационных политик или законодательных требований.
- Рабочие нагрузки, которые не поддерживаются в «облаке». Есть рабочие нагрузки, которые просто не поддерживаются в «облачном» окружении. Многие организации могут выполнять рабочие нагрузки лишь тем способом, который поддерживается поставщиком.
У «облака» есть преимущество, но оно актуально не для каждой организации. Если вы уверены в том, что нагрузка должна быть перенесена в «облако», проведите сначала эксперимент, чтобы увидеть, насколько хорошо в данном случае подойдет «облачное» окружение. Если не получите результатов, вы всегда найдете другой способ развертывания обновленной рабочей нагрузки.