Кажется, что об этом знают уже все: 14 июля этого года официально прекращена поддержка Windows Server 2003/R2. А дискуссия о том, что нужно делать и стоит ли вообще что-то предпринимать, продолжается. Я же предлагаю взглянуть на сложившуюся ситуацию со стратегической точки зрения. Во-первых, разобраться, как это может повлиять на бизнес-процессы компании, и взглянуть на ситуацию с юридической (а также технической и экономической) точки зрения. Во-вторых, понять, для чего нужны консультанты по миграции со старой ОС на последние версии, в чём от них польза. И, наконец, облегчить жизнь многим компаниям, рассказав о практическом опыте миграции веб- сайтов, основанных на технологии IIS с помощью утилиты Web Deployment Tool.

Окончание поддержки Windows Server 2003/R2. Лирика

Что же значит для бизнеса «окончание поддержки WS2003/R2»? C первого взгляда, вероятно, может показаться, что это приведёт к:

1. Дополнительным расходам на лицензии и, возможно, новое оборудование (мы же их уже покупали 12 лет назад. Опять?!?!).
2. Проблемам с контролирующими органами (особенно для компаний, которые хранят персональные данные (а какие компании их не хранят?), так как WS2003/R2 более не получает обновлений безопасности, а это значит невыполнение требований по обеспечению сохранности персональных данных.
3. Несоответствию различным стандартам: как локальным, так и отраслевым, а это может ограничить возможность участия компании в ряде тендеров, привести к штрафным санкциям и пр.

Исходя из вышесказанного, может сложиться впечатление, что окончание поддержки WS2003/R2 — это негативное событие, ведущее к издержкам, проблемам и «снова это ИТ вместо того, чтобы помогать в кризис, просит денег». Ведь дополнительные проблемы, риски и затраты в сложный экономический период никому не нужны. К тому же, многие компании только сокращают бюджеты на ИТ и требуют от ИТ-отделов не только сокращения расходов, но повышения эффективности. Как же в таких условиях проводить миграцию и проводить ли её вообще? Может быть лучше всё оставить как есть «до лучших времён»?

Давайте разберёмся во всём по порядку. Разложим стандартную ситуацию в типовом ИТ-отделе на цели, требования и ограничения.

Цели:

1. Сокращение расходов на ИТ
2. Повышение эффективности

Требования:

1. Соответствие ожиданиям бизнеса
2. Решение и поддержка бизнес-задач со стороны ИТ

Ограничения:

1. Сокращённый ИТ-бюджет
2. Окончание поддержки WS2003/R2

Как мы видим, последний пункт — это лишь одна часть общей картины. И она дает отличную возможность пересмотреть всю ИТ-стратегию. Заново осмыслить ИТ-инфраструктуру компании. Посмотреть на неё под разными углами и понять, как её оптимизировать и адаптировать к новой реальности. А имеющиеся у вас проекты по модернизации, которые постоянно откладывались из-за различных технических, финансовых и прочих ограничений? Пришло время пересмотреть их и оценить заново!

Определимся, что есть в вашей инфраструктуре. Для этого в первую очередь получим ответы на такие вопросы, как:

• Сколько есть серверов? Какие ОС установлены на них?
• Какую нагрузку они испытывают и какими характеристиками/мощностями обладают?
• Есть ли у вас ОС Windows Server 2003/R2? Какие роли, сервисы и приложения на неё возложены?
• Какие из этих приложений используются? Кто их использует?
• Можно ли переместить роли, сервисы и приложения на другие сервера с последней ОС?

Помощь в получении этой информации может оказать приложение по планированию инфраструктуры Microsoft Assessment and Planning Toolkit. Результатом его работы будет отчёт с анализом имеющейся инфраструктуры и техническими рекомендациями по её оптимизации или переносу в облако MS Azure.



После того, как ответы на вопросы будут найдены, и проведен анализ существующей инфраструктуры, может оказаться, что:

1. У вас нет серверов с WS2003/R2.
2. У вас достаточно ресурсов, чтобы просто передать роли/службы/приложения с Windows Server 2003/R2 на другие, имеющиеся в наличии сервера с последней версией ОС и вывести их с поддержки.
3. Вы не используете максимально эффективно имеющиеся ресурсы, и есть возможность высвободить часть лицензий/оборудования.
4. То самое уникальное приложение для бухгалтерии нещадно устарело и имеет современный аналог, и уже не обязательно для него поддерживать 2003 сервер (обычно, современные приложения позволяют работать более эффективно, включают в себя новые функции и т.д.)

После того, как вы поняли, что имеете сейчас, и как это используется, пришла пора сверить своё видение дальнейшего развития ИТ с бизнесом, понять, что нужно бизнесу от ИТ:

• Каковы стратегические цели бизнеса?
• Какие у него планы на обозримую перспективу и какие ожидания от ИТ? Возможно, это повышение мобильности сотрудников? Или открытие новых филиалов по всему миру?

Оценив цели бизнеса, вы сможете выбрать максимально эффективный способ их достижения. Ведь обновляя инфраструктуру с видением перспективы, вы делаете большой задел для гибкости, масштабируемости и эффективности её дальнейшего использования. Пожалуй, здесь пришла пора вспомнить про консультантов по миграции. Для чего компании, и ИТ отделу в частности, может понадобиться внешний консультант по миграции? Ведь в ИТ-отделе есть классные специалисты, которые могут всё сделать сами.

Ниже в списке перечислены этапы миграции. Их длительность зависит от конкретной инфраструктуры и квалификации персонала, который будет их выполнять:

1. Анализ существующей инфраструктуры
2. Разработка плана миграции
3. Выбор оптимального решения
4. Внедрение решения (собственно, миграция)
5. Анализ и тестирование результата миграции

Теперь попробуйте оценить:

• есть ли в ИТ-отделе специалисты, способные выделить этому проекту требуемое время и обладают ли они достаточной квалификацией и опытом?
• как это скажется на текущей поддержке сервисов?
• если выполнять проект миграции без отрыва от производства, какие сроки в итоге получатся и с какой эффективностью?
• насколько качественно и продуманно будет проведена миграция и как это скажется на стабильности сервисов?

Если у вас:

• небольшие объёмы работы (менее 15 серверов);
• имеются свободные и достаточно квалифицированные ресурсы или мигрируемые сервисы/приложения не критичны,

то оптимальным решением будет выполнить проект по миграции своими силами.

Однако, если у вас:

• достаточно большая инфраструктура (более 15 серверов);
• есть бизнес-критичные сервисы/приложения;
• из-за ограничения «Сокращённый ИТ-бюджет» сотрудники ИТ-отдела загружены и не могут выделить нужное время для реализации проекта без вреда для оказываемых сервисов,

то рекомендуется выбрать компанию-консультанта по миграции, которая может либо выполнить все работы по миграции, либо реализует их часть. Например, проведет оценку существующей инфраструктуры и даст рекомендации по её модернизации, а внедрение полученных предложений вы реализуете своими силами.

Плюсы ИТ-аутсорсера в том, что это компания с высококвалифицированным профессионалом, который имеет за плечами не один законченный проект и прекрасно осведомлён о возможных «подводных камнях» и вероятных сложностях в процессе. Он поможет вам в формировании и реализации вашей ИТ-стратегии, синхронизированной со стратегией бизнеса.



Например, порекомендует внимательнее присмотреться к облачным решениям:

1. если в стратегической цели бизнеса есть пункт о повышении мобильности сотрудников, а у вас при этом есть 2003 сервер, на котором развернут MS Exchange, то может пригодиться облачное решение Office 365, вместо миграции на другой сервер.
2. если бизнес планирует открывать филиалы по всему миру, то здесь внимание уделим MS Azure.
3. возможно, также пришла пора присмотреться к гибридным облакам и рассмотреть возможность передачи ряда некритичных сервисов в публичное облако, а бизнес-критичные развернуть в частном облаке внутри организации?

На картинке ниже можно увидеть различные варианты предоставления облачных сервисов. Доводы «За» миграцию в публичное облако:

• Нет необходимости обслуживать и сопровождать сервера
• Есть возможность выбора подходящего варианта получения ресурсов и их объемов (IaaS, PaaS или SaaS)
• Высокая отказоустойчивость.

Если какие-либо приложения или сервисы нельзя передавать на хостинг в публичное облако, то можно построить гибридное облако на базе Windows Server 2012 R2 & System Center 2012 R2 & Windows Azure. Доводы «За» гибридное облако:

• Вы определяете и размещаете в своём частном облаке приложения и службы, которые не должны быть в публичном.
• У вас есть возможность использовать как ресурсы своего облака, так и MS Azure, что позволяет гибко управлять доступностью приложений или сервисов и количеством необходимых мощностей.

Наш опыт миграции сайтов с IIS 6.0

Имея немалый практический опыт миграции сайтов с IIS 6.0 на последние версии, я хочу поделиться руководством по такой миграции с помощью Web Deployment Tool.

Перед началом миграции убедитесь, что:

1. У вас есть бэкап.
2. Если сайт использует SQL базу, убедитесь, что она была заранее мигрирована на новый сервер.
3. У вас есть все необходимые логины и пароли.
4. Все порты необходимые для работы сайтов открыты на новом сервере.

Что можно мигрировать с помощью Web Deployment Tool?

• 1 или 1000 веб сайтов, включая их конфигурации, контент и сертификаты.
• Приложение.
• Весь сервер (все веб-сайты, пулы приложений, ключи регистра, контент и прочее).
• Пользовательский манифест, состоящий из сайтов, пула приложений, ключей регистра, контента и пр.

Для миграции у вас должен быть установлен .NET Framework 2.0 SP1 или выше и Web Deployment Tool. (Как установить web deployment tool можно посмотреть здесь (eng) или здесь (рус)).

Шаг 1. Проверьте зависимости сайта и найдите скрипты или установленные компоненты, которые он использует.

1. Проверить зависимости веб сайта можно с помощью следующей команды
   

   msdeploy -verb:getDependencies -source:metakey=lm/w3svc/1

   1 – это ID сайта
2. Посмотрите вывод зависимостей и определите, какие компоненты использует сайт. Например, если сайт использует авторизацию windows, вывод команды будет следующим:
   

   /<dependency name="WindowsAuthentication" />.

3. Если сайт наследует какие-либо скрипты, то их не будет в выводе списка зависимостей, наследуемые скрипты нужно будет проверить вручную.

Подробное описание анализа вывода команды getDependencies можно посмотреть здесь.

Шаг 2. Настройка целевого сервера

Согласно полученного в 1-м шаге списка зависимостей, установите необходимые компоненты. Например, если в вашем списке зависимостей есть компоненты:

• ASP.NET
• Windows Authentication
• Anonymous Authentication

Следовательно, на основе этого списка зависимостей вам необходимо будет установить соответствующие компоненты и модули.

Шаг 3. Миграция сайта с использованием архива

1. Всегда делайте бэкап сервера, на который планируете миграцию. Даже в случае тестирования. Это позволит вам быстро вернуть сервер в исходное состояние
   

   %windir%\system32\inetsrv\appcmd add backup “PreWebDeploy”

2. Чтобы создать файл с архивом сайта, на исходном сервере выполните команду:
   

   msdeploy -verb:sync  -source:metakey=lm/w3svc/1 -dest:package=c:\Site1.zip > WebDeployPackage.log

   1 – это ID сайта
3. Скопируйте полученный архив на целевой сервер.
4. Для проверки, что произойдёт при запуске синхронизации, на целевом сервере выполните команду
   

   msdeploy -verb:sync -source:package=c:\Site1.zip -dest:metakey=lm/w3svc/1 -whatif > WebDeploySync.log

   1 – это ID сайта
5. После проверки результатов выполнения команды, выполните её без ключа –whatif (разумеется, если вывод предыдущей команды был без ошибок)
   

   msdeploy -verb:sync -source:package=c:\Site1.zip -dest:metakey=lm/w3svc/1 > WebDeploySync.log

   1 – это ID сайта

Миграция сайта с использованием web deployment agent service

Если вы хотите использовать синхронизацию сайтов в режиме реального времени, то можно воспользоваться Web Deployment Agent Service.

1. Установите Web Deployment Agent Service на исходный или целевой сервер, или на оба для максимальной гибкости возможных сценариев синхронизации (агент может как принимать синхронизируемые данные от источника, так и отправлять их)
2. Запустите сервис
   

   net start msdepsvc

3. Запустите следующую команду, чтобы начать синхронизацию (отправку данных) с локального источника на удалённый сервер (Server1 замените именем своего сервера). Сначала рекомендуется запускать команду с флагом –whatif, а после проверки результатов её выполнения – без неё.
   

   msdeploy -verb:sync -source:metakey=lm/w3svc/1 -dest:metakey=lm/w3svc/1,computername=Server1 -whatif > msdeploysync.log

   1 – это ID сайта
4. Следующая команда запускает синхронизацию в режиме «приёма» данных с удалённого сервера
   

   msdeploy -verb:sync -source:metakey=lm/w3svc/1,computername=Server1 -dest:metakey=lm/w3svc/1 -whatif > msdeploysync.log

   1 – это ID сайта

На этом процесс миграции закончен, остаётся проверить работу сайта на целевом сервере. В случае проблем для поиска их решения можно воспользоваться Troubleshooting Web Deploy.

Важно помнить, что прогресс – это постоянное движение. Использование устаревших технологий очень часто означает ограничения в возможностях или отставание от прогресса, которое рано или поздно придётся навёрстывать, а чем больше отставание, тем больше усилий придётся приложить для его сокращения, не говоря уже о том, чтобы догнать лидеров.

Автор aleksjoke