Привет! Это наш первый материал на Хабре. В нем мы собираемся рассказать о нашем опыте миграции сложного портала с применением метода Database Attach. Enjoy!
Немного о том, кому, скорее всего, будет интересно это читать
Решив поделиться своим опытом миграции одного портала, мы ориентировались, прежде всего, на тех, кто не спрашивает «Зачем мигрировать?», не задается вопросом «А может быть сразу на 2013?», а также на тех, кто знает не понаслышке ужасные слова Windows Workflow Foundation, Event Handlers, Jobs, Content Types, Future Receivers, различный Site, List и т.п. термины и думает, как сделать, чтобы это заработало в SharePoint 2010.
История портала
Статья основана на реальных событиях, а именно на результатах многолетнего сотрудничества EastBanc Technologies с крупной авиакомпанией. В течение пяти лет мы вместе с ИТ-отделом портала работали над проектом Virtual Sale Manager. Это нестандартный внутренний корпоративный портал на MOSS 2007, который автоматизирует рутинные финансовые и правовые аспекты работы дирекции продаж и, по сути, является бэк-офисом дирекции. Порталом пользуются все, от директората до кассиров. На нем функционирует несколько продуктов, которые автоматизируют такие процессы как заключение и расторжение агентского соглашения, регистрацию и аннулирование пункта продажи и т.д., огромное количество бизнес-процессов.
За пятилетнюю историю развития проект вырос в эффективную систему коммуникации компании со своей агентской сетью, в которую входит более 1200 контрагентов.
Чтобы вы могли оценить масштаб и размах, приводим цифры и факты:
Развитие портала началось в 2007 году и продолжается по сей день.
- На его создание потрачено более 35 000 человеко-часов.
- В разное время над проектом работало 28 человек.
- Ежедневно в системе работают более 1600 активных пользователей.
- Размер базы содержимого портала — 80 ГБ.
- География пользователей — вся Российская Федерация, СНГ, Юго-Восточная Азия, Европа.
- Система работает во всех часовых поясах.
Почему мы решили об этом написать
За прошедший год мы участвовали в миграции нескольких порталов с платформы SharePoint 2007 на платформу SharePoint 2010, в частности в миграции порталов компании Alawar и общественной приемной мэра г. Новосибирска.
Оба портала замечательны расширенной функциональностью, наличием специализированных модулей (Windows Workflow Foundation, Even Handlers, Jobs), интеграцией с различными BI-решениями (Reporting Services, Excel Services, Performance Point).
В рекламной продукции Microsoft процедура миграции выглядит очень просто:
- Проводим планирование инфраструктуры.
- Устанавливаем портал и конфигурируем его.
- Выбираем метод обновления портала до 2010.
- Обновляем и готово!
На практике все оказалось не так просто и не так быстро: мы столкнулись с тем, что почти все типы «custom»-решений требуют индивидуального подхода при миграции. А если учесть, что во главу угла ставится, конечно же, сохранение всего этого нестандартного добра, нажитого непосильным трудом, и минимизация времени отключения портала (!), то задача получается довольно амбициозной.
Такая же специфика (только пообъёмней) ждала нас и на миграции портала для компании, и мы снова укротили этого страшного зверя. А потом решили, что уже обладаем таким опытом, который может показаться интересным и полезным достопочтенной публике.
Ревизия или учет товарно-материальных ценностей
Начали мы с ревизии нашего многолетнего труда, связанного с разработкой VSM-портала. В ее ходе мы выяснили, что:
1. В проекте существует 16 видов различных custom-расширений портала:
- a. Windows Workflow Foundation — запущено бизнес-процессов в количестве 21 штука (например, такие как аннулирование точки продаж, внесение объемов полетов по корпоративному договору, вопрос от пользователя и т.д.). Некоторые процессы запущены в количестве 3000 экземпляров
- Шаблоны списков – 232 штуки
- Шаблоны сайтов
- Основной портал
- Новостная лента
- Портал агентов BSP
- Портал Бонусной программы кассиров
- Узел Конфиденциальных тарифов
- Узел помощи агенту (Запросы агентов)
- Больше 66 Custom Event Receivers и Feature Receivers
- Дизайны
- Для основного сайта
- Для Запросов агентов
- Для BSP
- Для Кассир-бонуса
- Jobs (штук 15)
- Computed fields (около 80)
- Custom Actions с кастомными контролами (около 30).
2. Проект интегрируется со следующими сторонними системами:
- система учета контрагентов;
- программное обеспечение ASIA NEXT — заказ стоков билетов, претензионная работа.
К миграции каждого из этих типов требуется собственный подход, который мы и сформировали, но об этом чуть позже, а сначала нужно:
- Собрать все исходники в одну кучу и создать новый проект в VS 2010, разместить их TFS.
- Сделать так, чтобы все собиралось (как оказалось, это не так сложно).
- Создать WSP для наката на портал.
- Пройти процедуру pre-upgrade check.
Вот здесь начинается самое интересное: у нас есть портал, в который установлены, казалось бы, скомпилированные исходные тексты, но он даже не открывается, что делать дальше спросите вы? Об этом далее.
Инфраструктура и подход к миграции
После ревизии настал ответственный момент — нужно было выбрать метод миграции. Чтобы мигрировать такой сложный портал, мы решили создать тестовую площадку, идентичную оригинальному порталу и постепенно оживить на ней весь функционал. Мы отказались от идеи выполнения резервной копии фермы, т.к. такой подход повлек бы за собой массу дополнительных работ по апгрейду системного ПО фермы заказчика, и выбрали подход «Database Attach». Таким образом, мы избавили себя от хлопот, связанных с тем, что новая и оригинальная инфраструктуры портала не совпадали.
В соответствии с этим подходом для полноценной работы тестовой инфраструктуры на своих серверах мы настроили шифрованные туннели до инфраструктуры заказчика, через которые подключили:
- Active Directory
- Web-сервисы для интеграции (пункт 3 из предыдущего раздела)
- Базу данных Oracle.
На этом этапе вместе с нами работали разные группы специалистов, в том числе администраторы и служба безопасности портала.
В итоге мы получили две тестовые площадки, каждая из которых состояла из SQL Server 2008 R2 и веб-сервера с SharePoint 2010. На этих площадках мы развернули оригинальные 80-гигабайтные контентовые базы. Тестовые площадки, как мы и задумывали, стали точной копией оригинала.
Итак, мы подготовились. На руках у нас оказался портал идентичный натуральному, можно было начинать тестировать бизнес-процессы. Близился час Икс, пора было делать первый шаг на пути миграции.
Первый шаг
Дальше мы запустили pre-upgrade check. Благодаря этому увидели много необходимых для установки фич. Подключили базу содержимого и перекомпилировали все наши DLL под SharePoint 2010.
Te фичи, которые были вне WSP, добавили в WSP. Их у нас в итоге у нас получилось 16 штук.
После очередного pre-upgrade check ошибок стало намного меньше, среди них — ни одной критической.
Следующим этапом мы добавили файлы *.config, *.sitemap, для конфигурации workflow и исходящих мэйлов из папки «C:inetpubwwwrootwssVirtualDirectories80» в корень сайта. Портал открылся, и мы смогли увидеть, то, что должно было мигрировать само по себе (библиотеки документов, структура сайтов, списки), но, к сожалению, можно было только посмотреть.
Второй шаг
Увидев портал, мы выписали check list того, что не работает. Предстояло сделать так, чтоб заработало. Можно себе представить, что чек-лист был не маленьким, мы брали каждую роль и составляли список доступных действий, например, «анонимный пользователь», «кассир», «авторизованный агент» и т.д.
Третий Шаг
Примус требовал починки:
- Custom-филды (выловили 45 штук), которые почему-то не захотели отображаться правильно. Решили, что чинить их будем как рекомендуют в руководствах к SharePoint 2010, т.е через XSLT-преобразование. Сработало!
- Множество кастомных Workflow, написанных в Visual Studio, и кастомных страниц, которые использовали Ajax. Раньше при переходе со страницы на страницу у нас передавался ViewState. После миграции на SharePoint 2010 он передаваться перестал. Мы долго пытались понять — почему? Оказалось, что в SharePoint 2010 поменялись Java-скрипты и поэтому при заходе на новую страничку у формы подменялся action-путь. Эту задачу мы решили следующим образом: написали на каждой такой страничке свой дополнительный скрипт, который запрещал менять этот custom-путь. И все заработало!
- Множество Windows Workflow Fondation со множеством различных версий DLL, которые постепенно добавлялись все эти годы, и в итоге накануне миграции у некоторых Workflow лежало по 3-4 версии DLL. Для того чтобы все эти DLL не переносить, а функционал использовать из новых DLL, мы их, во-первых, перекомпилировали под SharePoint 2010, а во-вторых, прописали в конфигурациях биндинги этих DLL. В результате, когда система запрашивала DLL одной версии, ей всегда отдавались DLL другой версии, которую мы определили. После этого также удалось избежать многих проблем: работающие Workflow продолжили работать, а новые запускались как нужно, с правильными версиями.
- Списки ASPX-страниц. После миграции начали очень медленно работать. Здесь мы на какое-то время встали в тупик. В итоге решили пересмотреть запросы к базе SharePoint SQL-профайлером и выяснить, что идет в базу. Выяснилось, что SharePoint пытается вытянуть все ASPX-страницы за раз. Попробовали создать новый список и написали скрипт, который скопировал страницы списка из старого листа в новый. На нем все работало быстро. После этого мы написали скрипт, который вернул все ASPX-страницы в старом списке к исходной версии сайта – все починилось.
- Большие списки точек продаж. SharePoint раздавал права на каждый их элемент по отдельности. Было порядка 15 тысяч точек продаж, на которые права были розданы по отдельности, поэтому списки страшно тормозили. Справились так: для каждого агента завели папку, на эту папку раздали права и перетащили туда точки продаж агента. У нас сократилось количество прав до количества агентов, и список стал работать существенно быстрее.
То же самое было со списком задач для Workflow.
Наконец, заработали все листы.
Четвертый шаг (скучная рутина)
А дальше в течение двух недель мы ходили по сайту, выясняли, что падает и чинили все требующие того custom-решения.
Например, требовалось исправить:
- Перевод представлений списков в XSL. Специально мы их не переводили, только несколько полей. Остальные списки у нас заработали как надо.
- Job и Handlers. Пришлось в классе джоба переопределить свойство «HasAdditionalUpdateAccess», чтобы появилась возможность создавать джоб из UI сайта.
- JQuery виджеты. Раньше метод $.ajax возвращал просто объект, а теперь стал складывать его внутрь объекта “d” (было data — стало data.d).
Пятый Шаг (тренировка)
Когда нам показалось, что все готово, мы развернули 2 виртуалки со старой базой авиакомпании и проделали весь путь заново (в чек-листе у нас было описано 16 шагов, которые надо было сделать, мы их повторили). Все восстановилось в том состоянии, в котором требовалось. Можно было готовить инфраструктуру и… миграцию!
Шестой шаг (готовим инфраструктуру заказчика)
При подготовке инфраструктуры нам было желательно сохранить старый портал, чтобы вернуться на него в случае неудачи. Поэтому было сделано резервное копирование старой инфраструктуры, что заняло около 4 часов.
Головоломности задаче добавляло также то, что у нас не было прямого доступа к инфраструктуре, а подготовка происходила ночью, когда техническую службу в случае проблем беспокоить не хотелось. Поэтому прибегли к использованию системы удаленного доступа ILO, с помощью которой установили операционную систему.
В пятницу, в 9 часов вечера по Москве, мы отключили сервера, сделали резервное копирование, убили все системы и включили на установку новые. Здесь и начались главные приключения: вместо часа система через ILO ставилась три часа! А на установку трех систем у нас ушло целых 7 часов, тогда как изначально мы планировали потратить не больше двух! С девизом «Не отступать и не сдаваться» на устах мы провели бессонную пятничную ночь.
Седьмой шаг (мы нажали на рубильник!)
Когда, наконец, в субботу в 6 утра все установилось, и у нас появился нормальный доступ через ремоутный десктоп, на системы поставили SharePoint 2010 и SQL, развернули базу, протестировали (см. Шаг Пятый) и подключили. Уже в субботу после обеда (через 12 часов после начала эпопеи) у нас появился на 90% рабочий портал.
И было всем счастье
Итак, подведем итоги.
На подготовку миграции мы потратили 4 недели, за которые было сделано всё, чтобы минимизировать downtime: была создана тестовая площадка, идентичная оригинальному порталу; с помощью этой площадки была проведена «тренировка» — тестовая миграция; на основе результатов теста был составлен подробный план «боевой» миграции.
Приготовления сработали — миграция прошла с минимальным временем отключения портала! А именно, портал не работал в течение 17 часов, включая 12-часовую перестановку операционных систем и настройку оборудования. Всё это происходило в выходные и почти не отразилось на работе агентов. В понедельник портал действовал в обычном режиме, мы победили!
Спасибо, что осилили этот эпический труд. Будем рады пообщаться на тему миграции, ответить на вопросы и поспорить (конструктивно!).
Автор: eastbanctech
