Развертывание SharePoint 2010. Подготовка к обновлению до SharePoint 2010

Обновление до SharePoint 2010 будет непохоже на другие обновления, которые вы выполняли. Но еще перед началом планирования необходимо ознакомиться с системными требованиями для SharePoint 2010. В отличие от предыдущих версий SharePoint 2010 выпускается только в 64-разрядной версии. Там образом, необходимо устанавливать SharePoint 2010 на 64-рязрядной версии Windows Server 2008 или Windows Server 2008 R2.

SharePoint требуется база данных SQL Server, но она не обязательно должна находиться на том же сервере, что и SharePoint. SharePoint 2010 по-прежнему требует SQL Server, но корпорация Майкрософт внесла несколько важных изменений. SharePoint 2010 требует, чтобы базы данных работала с 64-разрядной версией SQL Server 2005 или 2008. Это справедливо вне зависимости от того, установлена ли база данных локально на сервере SharePoint.

Необходимо также задуматься об используемом веб-браузере, хотя это и не техническое требование. SharePoint2010 создан для того, чтобы оптимизировать использование веб-стандартов. Это означает, что пользователи смогут работать без перебоев независимо от используемого браузера: Explorer или Firefox (3.x или боле поздняя версия). Единственная тонкость заключается в том, что SharePoint 2010 обеспечивает ограниченную поддержку Internet Explorer 6. Пользователи IE6 не должны испытывать проблем с просмотром содержимого SharePoint, однако для создания содержимого потребуется IE7 или более поздняя версия (или Firefox 3.x или более поздняя версия).

Обновления поверх существующей системы

Как вы уже, наверное, слышали, SharePoint 2010 позволяет выполнять обновления поверх существующей системы Microsoft Office SharePoint Server (MOSS) 2007. Однако, поскольку SharePoint 2010 является 64-разрядной, можно выполнить обновление поверх существующей системы только в том случае, если MOSS 2007 запущен поверх 64-разрядной версии Windows Server 2008. Если ваши серверы SharePoint соответствуют необходимым системным требованиям, можно выполнить обновление поверх существующей системы на каждом сервере фермы SharePoint.

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

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

Проверка перед обновлением

Независимо от того, что вы выполняете – обновление поверх существующей системы или перенос, необходимо перед этим все спланировать и подготовиться. Одним из наиболее важных шагов в подготовке к обновлению до SharePoint 2010 является запуск программы предварительного анализа. Перед выпуском MOSS 2007 корпорация Майкрософт представила служебную программу Prescan.exe, которая поможет проверить состояние развертывания SharePoint перед обновлением до MOSS 2007.

Программа Prescan.exe в свое время была отличным средством, однако она не очень хорошо подходит для предварительного анализа SharePoint 2010. Вот почему корпорация Майкрософт выпустила программу предварительного анализа Pre-Upgrade Checker. Она намного совершеннее программы Prescan.exe. Начнем с того, что программа предварительного анализа Pre-Upgrade Checker предназначена только для чтения, поэтому не придется волноваться о внесении каких-либо изменений на серверы SharePoint.

Однако наиболее удобна Pre-Upgrade Checker именно тем, что выполняет куда более тщательную работу по поиску проблем, нежели Prescan.exe. Кроме того, она является расширенной. Она выпускается с набором правил, которые использует при анализе серверов SharePoint. Это правила в формате XML, следовательно, можно создавать свои правила, если это потребуется. Кроме того, использование правил на основе XML упрощает работу корпорации Майкрософт по обновлению программы предварительного анализа, если их рекомендации когда-нибудь изменятся.

Считается, что лучшее в этой программе – это информация, которую она собирает, но это утверждение спорно. Несмотря на том, что корпорация Майкрософт создавала ее как средство для подготовки к обновлению до SharePoint 2010, некоторые организации используют ее для других целей. Одна компания использует ее в рамках своего плана по восстановлению после сбоев. Программа предварительного анализа никоим образом не поможет спасти сервер SharePoint после сбоя, однако собранная ею информация может оказаться бесценной, если вам придется повторно собирать развертывание SharePoint (только обязательно запустите ее перед сбоем).

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

Так где же можно найти эту программу? Есть вероятность, что она у вас уже есть. Корпорация Майкрософт включила ее в MOSS 2007 с пакетом обновления 2 (SP2). Но, возможно, вопреки вашим ожиданиям, программа предварительного анализа не является изолированным средством. Корпорация Майкрософт встроила ее в служебную программу STSADM.EXE. Так уж получилось, что после применения пакета обновления 2 (SP2) мне пришлось перезагружать тестовый сервер несколько раз, пока Windows не позволила мне получить доступ к новым функциям STSADM.EXE.

Учитывая все вышесказанное, я хочу показать, как работает программа предварительного анализа. Как я уже говорил, она работает, анализируя файл правила на основе XML, а затем используя эти правила как основу для анализа развертывания SharePoint. Программа поставляется со встроенным набором правил. Эти правила, основанные на анализаторе соответствия рекомендациям, находятся в файле OssPreUpgradeCheck.xml. На него можно посмотреть на рис. 1.

Рис. 1.  Программа предварительного анализа использует файл правил на основе XML.

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

STSADM.EXE –O PreUpgradeCheck
[[-RuleFiles “<rule file name>”] [-ListRuleFiles]] [-LocalOnly]

Как можно видеть, существуют два обязательных параметра –O и слова PreUpgradeCheck. Параметр –RuleFiles является необязательным и используется только при необходимости указать файл правил вручную. Также можно использовать параметр –ListRuleFiles для отображения файлов правил, которые доступны. И, наконец, можно использовать параметр –LocalOnly для запуска этих правил только для местного сервера SharePoint.

Взгляните на рис. 2, который поможет представить, как работает программа предварительного анализа. Как видно на рисунке, я начинаю с того, что открываю окно командной строки и перехожу по адресу C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN. Оттуда я запускаю следующую команду:

STSADMIN.EXE –O PreUpgradeCheck]

Рис. 2 . Проверка программой предварительного анализа развертывания SharePoint.

Как можно видеть на рис. 2, программа предварительного анализа выполняет ряд различных тестов в развертывании SharePoint. Результаты каждой проверки имеют свой цвет. Красный указывает на сбой, зеленый – на то, что сервер прошел проверку. Информационные пункты обозначены желтым.

Выводные данные программы предварительного анализа, конечно же, не являются очень подробными. Снимок экрана на рис. 2 сообщает только о том, пройдена ли проверка; подробных сведений не выводится. Тем не менее, если взглянуть на нижнюю часть снимка экрана, можно заметить сообщение, в котором сказано, что можно просмотреть результаты в файле HTML, расположенном по адресу C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Logs.

Программа предварительного анализа создает три отдельных файла журнала при каждом запуске. Один из них – это файл HTML, адрес которого указан в конце проверки, два других – это файлы LOG и XML. Можно использовать любой из них, но файл HTML удобнее читать.

Как уже было сказано, программа предварительного анализа собирает множество информации. Следовательно, нет ничего странного в том, что окончательные файлы журнала слишком длинные для того, чтобы приводить их полностью. Можно, однако, получит общее представление о том, как выглядят файлы журнала в формате HTML, взглянув на рис. 3.

Рис. 3 . Результаты работы программы предварительного анализа можно просмотреть с помощью веб-браузера.

Определение пользовательских настроек

Еще один важный шаг в планировании обновления – определить пользовательские настройки серверов SharePoint. Неважно, что вы выполняете, – обновление поверх существующей системы или перенос, – можно нечаянно переписать пользовательские настройки. Следовательно, следует их задокументировать и сделать резервную копию только этих файлов, чтобы их можно было без проблем использовать после обновления, если потребуется.

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

Есть способ определить настройки – методика под названием поиск различий. Идея заключает в том, что можно установить резервный сервер MOSS 2007 (убедитесь в том, что на нем запущены те же исправления, что и на рабочих серверах) и воспользоваться программой для поиска различий, чтобы увидеть, какие файлы на рабочих серверах отличаются от файлов на неизмененном сервере SharePoint.

Корпорация Майкрософт рекомендует использовать, однако существуют и другие программы, многие из них имеют более обширные функции, нежели WinDiff.

Проверка процесса обновления

При подготовке к переходу на SharePoint 2010 неизбежно настанет момент, когда вы разработаете план выполнения обновления. Предположим, что вы решили все проблемы, найденные программой предварительного анализа. Значит, процесс обновления должен проходить относительно гладко. Тем не менее, его нужно тщательно контролировать.

Разверните MOSS 2007 в изолированной лабораторной среде и попробуйте реализовать план обновления в ней, прежде чем выполнять обновление на рабочих серверах. Лабораторная среда поможет ознакомиться с процессом обновления, а также определить проблемы, которые могут возникнуть в ходе настоящего обновления.

Лучший подход для предприятий малого и среднего бизнеса – установить несколько виртуальных серверов, а затем восстановить резервные копии рабочих серверов на серверах лабораторной среды. Это позволит вам проверить план обновления в среде, которая практически идентична производственной.

В более крупных организациях создавать точную копию производственного развертывания SharePoint, возможно, будет непрактично. В подобных ситуациях можно установить небольшую среду, настроенную так же, как и производственная среда. Можно также попробовать восстановить в лабораторной среде резервные копии — но не все — серверов SharePoint. В то время как этот подход может казаться очень перспективным, не забывайте о том, что вы, скорее всего, не будете переносить все развертывание в SharePoint 2010 за раз; вам потребуется сконцентрировать развертывание постепенно.

Проверка резервных копий

Последний шаг перед началом обновления до SharePoint 2010 – проверка, правильно ли работают резервные копии. Как раз на этой неделе мне пришлось помогать одному человеку, который считал, что старательно выполняет резервное копирование серверов, но обнаружил, что эти резервные копии никуда не годились. Не допускайте подобных ситуаций. Проверяйте резервные копии, необходимо убедиться в том, что их можно восстановить.