 |
|
|
|
Инструменты миграции SharePoint на все случаи жизни
Инструменты миграции SharePoint на все случаи жизни Разбираемся в инструментарии создания резервных копий, переноса узлов и распространения решений SharePoint. Перенос портала MS SharePoint, а также отдельных его узлов и компонентов на другой сервер – задача, на первый взгляд, тривиальная. Однако, если над сайтами SharePoint успели хорошо поработать дизайнер и программист, возникают определенные сложности. К тому же версии Microsoft Office SharePoint Server 2007 (MOSS 2007) и Windows SharePoint Services (WSS) 3.0 соответственно предоставляют столь обширный инструментарий для переноса различных составляющих портала и распространения решений на базе SharePoint, что стоит разобраться в этом поподробнее. Немного об архитектуре Чтобы разобраться, как перенести ту или иную составляющую портала на другой сервер, нужно вспомнить, из чего состоит SharePoint (см. рис. 1).
Рисунок 1. Архитектура SharePoint и уровни миграции На этой схеме упрощенно представлена архитектура SharePoint. Уровень фермы серверов включает в себя конфигурационную базу данных и сайт центрального администрирования. Каждому веб-приложению соответствуют свои базы данных содержимого, кроме того, поставщик общих служб и служба поиска также имеют собственные базы данных. Примечание: в SharePoint Portal Server 2003 (SPS 2003) и WSS 2.0 вместо понятия «Семейство узлов» использовалось понятие «Узел верхнего уровня», структура хранения данных была другой. Разные инструменты позволяют осуществлять миграцию на разных уровнях, показанных на схеме (см. рис. 1). По ходу статьи и в сравнительной таблице для удобства я буду ссылаться на них. Под «элементами кастомизации» я имею в виду разработанные собственными или сторонними силами веб-части, шаблоны узлов и списков, действия узла (Site Actions), рабочие процессы и действия для рабочих процессов (Custom Workflow Actions), возможности (Features) и другие компоненты, которые придется переносить и переустанавливать отдельно, вне зависимости от того, какие из стандартных средств миграции/резервного копирования используются. Миграция портала SPS 2003 и его узлов Упомяну вкратце о способах миграции для предыдущих версий SharePoint. Версии SharePoint Portal Server 2003 и WSS 2.0 предлагают два основных инструмента для миграции портала. Сохранить и восстановить узлы верхнего уровня позволяют команды утилиты stsadm «backup/restore», которые остались актуальными и для новых версий SharePoint, поэтому о них я расскажу чуть позже. Отдельные подузлы (уровень 4 на схеме, рис. 1) можно переносить с помощью специальной утилиты smigrate, которая в новой версии более не поставляется, поэтому скажу о ней подробнее. Эта утилита находится там же, где и stsadm, т.е. в папке «%PROGRAMFILES%Common FilesMicrosoft Sharedweb server extensions60». Сохранить копию узла можно с помощью команды: smigrate -w http://server -f backup.fwp Восстановить с помощью: smigrate -r -w http://server -f backup.fwp Параметр w для восстановления должен указывать на уже существующий узел. Чтобы осуществить миграцию, нужно создать узел, но не применять к нему шаблон после создания (иначе во время восстановления может возникнуть ошибка). Переносить узлы WSS 2.0 можно также с помощью редактора Microsoft FrontPage, который, по сути, предоставляет графический интерфейс для утилиты smigrate. Наконец, в состав портала SPS 2003 входит специальная утилита для резервного копирования и восстановления с очень простым графическим интерфейсом, которая позволяет переносить весь портал целиком (см. рис. 2). Адрес для сохранения копии необходимо указывать в формате UNC (serverdirectory).
Рисунок 2. Утилита для резервного копирования и восстановления SPS 2003 О миграции WSS3 2.0/SPS 2003 на новую версию я уже писала [7]. Миграция портала MOSS 2007 Осуществить миграцию MOSS 2007 на другой сервер можно с помощью операций резервного копирования/восстановления, которые предполагают работу на уровне вплоть до баз данных (первые два уровня на схеме). Переносить отдельные узлы, списки, библиотеки или веб-части с помощью этих операций нельзя. Перед миграцией портала или отдельных его узлов на другой сервер не забудьте закрыть пользователям доступ на запись (либо полностью отключить портал/узлы) и остановить службу Windows SharePoint Services Timer во избежание потери данных. Сделать узлы доступными только для чтения можно в разделе «Приложения -> Квоты и блокировки семейства узлов» центра администрирования. В 2007-й версии SharePoint появилась возможность выполнять резервное копирование и восстановление с помощью веб-интерфейса. Команда доступна в разделе «Операции -> Резервное копирование и восстановление» центра администрирования портала (см. рис. 3).
Рисунок 3. Веб-интерфейс центра администрирования для резервного копирования портала С помощью веб-интерфейса центра администрирования можно выполнять миграцию на уровне:
Внимание! Восстановить резервную копию можно только на полностью идентичной версии SharePoint. То есть на новом сервере необходимо предварительно установить все те же сервис-паки и обновления, что и на исходном. Восстановить базу данных конфигурации и базу данных содержимого для сайта центрального администрирования возможно только на полностью идентичной или той же самой ферме серверов (включая название сервера), т.к. в этих базах данных содержится информация о конфигурации компьютера. При миграции всего портала на другой сервер необходимо после установки портала сначала создать базу данных конфигурации и сайт центрального администрирования (с помощью «Мастера настройки и установки SharePoint», который автоматически запускается после установки) [6], а затем осуществить восстановление из созданной копии. К сожалению, через веб-интерфейс центра администрирования нельзя настроить создание резервных копий по расписанию. В таком случае следует обратиться к утилите командной строки stsadm. Напомню, что она находится в директории «%PROGRAMFILES%Common FilesMicrosoft Sharedweb server extensions12» для WSS 3.0 и MOSS 2007 и в директории «%PROGRAMFILES%Common FilesMicrosoft Sharedweb server extensions60» для WSS 2.0 и SPS 2003. Утилита позволяет выполнять выборочное копирование одного из семейств узлов (уровень 3 на схеме, рис. 1) или же полную резервную копию всего портала. Формат команды для создания копии семейства узлов выглядит так: stsadm.exe -o backup -url -filename [-overwrite] Для создания полной резервной копии портала: stsadm.exe -o backup -directory -backupmethod [-item ] [-percentage ] [-backupthreads ] [-showtree] [-quiet] где:
Самые интересные параметры – showtree и item. Если указать параметр showtree, то бэкап выполняться не будет, а будет показано дерево структуры данного портала, такое же, как и в центре администрирования. Элементы, копирование которых невозможно, будут указаны в квадратных скобках. С помощью stsadm нельзя создать резервную копию конфигурационной базы данных и базы данных содержимого для сайта центрального администрирования. В параметре item можно указать для копирования некий элемент из этого дерева, тогда остальные элементы копироваться не будут. Если указать одновременно параметры item и showtree, то будет показано дерево, в котором элементы, которые не будут копироваться, будут помечены звездочкой (см. рис. 4).
Рисунок 4. Результат выполнения операции stsadm «backup» с параметром «showtree» Для создания резервных копий можно воспользоваться и встроенными средствами MS SQL-сервера. На схеме этому инструменту будут соответствовать уровни 1-2. Это удобно, когда есть возможность воспользоваться системами резервного копирования, работающими с MS SQL. Рекомендуемый алгоритм миграции/восстановления копии в этом случае выглядит так:
stsadm -o preparetomove -contentDB stsadm -o deletecontentdb -url –databasename stsadm -o addcontentdb -url -databasename -databaseserver Уточнить, какие базы данных содержимого использует то или иное веб-приложение, можно на сайте центра администрирования, в разделе «Управление приложениями -> Базы данных содержимого». Эту же операцию можно повторить для всех баз данных содержимого. Чтобы подключить перенесенную базу данных поставщика общих служб, воспользуйтесь кнопкой «Восстановить поставщика общих служб» в разделе «Управление приложениями -> Создание или настройка общих служб данной фермы» центра администрирования. Перенос отдельных узлов в MOSS 2007 Вместо smigrate в новой версии портала для миграции узлов (уровень 4 на схеме, рис. 1) можно воспользоваться специальными операциями утилиты stsadm «export/import». Операция export, строго говоря, не создает копию узла, а именно экспортирует содержимое. То есть после импорта списки и библиотеки получат новые идентификаторы. Это сопряжено с некоторыми проблемами, если над сайтом хорошо потрудился разработчик. О них я расскажу чуть позже, а пока немного подробнее об этой команде. Формат команды экспорта: stsadm.exe -o export -url -filename [-overwrite] [-includeusersecurity] [-haltonwarning] [-haltonfatalerror] [-nologfile] [-versions <1-4>] [-cabsize (default: 25)] [-nofilecompression] [-quiet] Параметр version может иметь значения:
Параметр -includeusersecurity означает, что будут скопированы группы прав доступа для узла, а также профили пользователей – членов этих групп. В результате работы команды формируется пакет содержимого – файл .cmp. Используя эту команду, нельзя выбрать, какие компоненты узлов экспортировать и импортировать, содержимое узла будет скопировано целиком. Импортировать содержимое можно как на несуществующий узел (в этом случае он будет создан), так и на уже имеющийся. Впрочем, в последнем случае возможно возникновение ошибок. Естественно, семейство узлов должно существовать обязательно. Формат команды импорта: stsadm.exe -o import -url -filename [-includeusersecurity] [-haltonwarning] [-haltonfatalerror] [-nologfile] [-updateversions <1-3>] [-nofilecompression] [-quiet] Параметр updateverions может обозначать:
Элементы кастомизации, или Если над сайтом поработал программист А теперь рассмотрим подробнее, что получится после переноса узла или портала, если над ним хорошенько поработал дизайнер или, еще хуже, программист. Во-первых, если на портале имеются веб-части собственной или сторонней разработки, их придется перенести и переустановить вручную. Во-вторых, если эти веб-части используют собственные ресурсы, их также необходимо скопировать вручную. Обычно ресурсы находятся в папке «%PROGRAMFILES%Common FilesMicrosoft Sharedweb server extensionswpresources», но некоторые хитрые разработчики обходят эту необходимость, складывая Java-скрипты и картинки в какую-нибудь библиотеку. В-третьих, если вы писали Custom Actions (собственные действия) для рабочих процессов или собственные рабочие процессы, их также необходимо перенести вручную, включая библиотеки .dll. Наконец, если использованы собственные шаблоны сайтов и списков, возможности (features) и некоторые другие варианты кастомизации, необходимо также скопировать так называемый «12 hive», т.е. папку «%PROGRAMFILES%Common FilesMicrosoft Sharedweb server extensions12». Некоторые из них, например features, необходимо будет затем заново развернуть с помощью stsadm, а некоторые также потребуют копирования соответствующих dll. По сути дела, на новом сервере понадобится провести заново процедуру их установки. Если вы переносите отдельный узел, например, с тестового сервера на рабочий, то может случиться другая неприятность – веб-части, списки и библиотеки при импорте получают новые идентификаторы, а в содержании страниц .aspx они останутся прежними. В результате ни одна из страниц, где есть представление данных (DataFormWebPart) или соединение веб-частей (SPWebPartConnections), работать не будет. Потребуется некий ремаппинг для восстановления полноценной работы узла. Решение этой проблемы – задача для программиста. Можно предложить следующий алгоритм: Шаг 1. Задача номер один – получить список идентификаторов с исходного сервера. Для этого можно воспользоваться веб-сервисом либо запустить на исходном сервере небольшую программку, которая создает xml-файл. В него мы запишем для списков – названия и идентификаторы, для веб-частей – идентификаторы, названия и страницы, на которых они располагаются. Библиотеки и рабочие процессы я не упоминаю намеренно, т.к. на самом деле они тоже являются списками с набором элементов. Метод для создания такого xml-файла может выглядеть, например, так: using Microsoft.SharePoint;using Microsoft.SharePoint.WebPartPages; using System.Xml; private static void makeXML(SPWeb web) { XmlDocument xml = new XmlDocument(); XmlElement xmlroot = xml.CreateElement("Data"); XmlElement elem_l = xml.CreateElement("Lists"); foreach (SPList list in web.Lists) { XmlElement listElem = xml.CreateElement("List"); ; listElem.SetAttribute("ID", list.ID.ToString().ToUpper()); listElem.SetAttribute("Title", list.Title); elem_l.AppendChild(listElem); } XmlElement elem_wp = xml.CreateElement("WebParts"); foreach (SPFile file in web.Files) { getWebParts(web, xml, file, ref elem_wp); } foreach (SPList list in web.Lists) { foreach (SPListItem item in list.Items) { if (item.File != null && item.File.Url.ToLowerInvariant().EndsWith(".aspx")) { getWebParts(web, xml, item.File, ref elem_wp); } } } xmlroot.AppendChild(elem_l); xmlroot.AppendChild(elem_wp); xml.AppendChild(xmlroot); //сохраняем xml-документ } private static void getWebParts (SPWeb web, XmlDocument xml, SPFile file, ref XmlElement elem) { SPLimitedWebPartManager wpColl; wpColl = web.GetLimitedWebPartManager(file.Url, System.Web.UI.WebControls.WebParts. PersonalizationScope.Shared); foreach (WebPart wp in wpColl.WebParts) { XmlElement wpElem = xml.CreateElement("WebPart"); ; wpElem.SetAttribute("ID", wp.ID.ToString()); wpElem.SetAttribute("Title", wp.Title); wpElem.SetAttribute("Page", file.Url); elem.AppendChild(wpElem); } } Шаг 2. Задача номер два – найти соответствующие идентификаторы на новом узле. Очевидно, что получить идентификаторы на новом узле можно аналогичным способом и, например, записать их в другой xml-файл. Как определить соответствие? В качестве ключа для поиска идентификатора списка можно использовать его название, а для поиска идентификатора веб-части – название плюс страница, где веб-часть находится. Для основных версий страниц эти ключи будут уникальными, для копий и черновиков пары идентификатор/ключ будут совпадать. Шаг 3. Самая интересная часть – заменить старые идентификаторы на новые. Для этого недостаточно просто загрузить страницы .aspx и заменить в них соответствующие подстроки. Дело в том, что описание веб-частей не хранится внутри страницы. Для доступа к описанию веб-части объектная модель предоставляет специальный объект SPLimitedWebPartManager (который мы собственно уже использовали для получения идентификаторов). К счастью, задача замены подстроки в описании веб-части за нас уже решена. Подробное описание решения можно найти на сайте MVP (Microsoft Most Valuable Professional) Gary Lapointe [4]. А можно просто скачать на том же сайте набор расширений для stsadm и воспользоваться для каждого идентификатора в нашем xml-файле командой: -o gl-replacewebpartcontent -url -searchstring -replacestring -scope Web Если такая задача возникает часто, подобную программу для ремаппинга перенесенного веб-узла при необходимости можно также оформить в виде расширения для stsadm [8]. Что доступно разработчику Все вышеуказанные операции по миграции может выполнять только администратор портала, причем в большинстве случаев ему понадобятся и административные права на сервере. Microsoft Office SharePoint Designer позволяет выполнять ряд операций по переносу содержимого разработчику или продвинутому пользователю, если он входит в группу администраторов данного узла или семейства узлов. С помощью инструментов в составе SP Designer можно создавать два вида пакетов для импорта/экспорта:
Создать пакет .fwp можно с помощью пункта меню «Файл -> Экспорт -> Личный веб-пакет», после чего можно выбрать, какие папки/файлы будут входить в пакет (см. рис. 5).
Рисунок 5. Создание пакета .fwp с помощью SharePoint Designer Соответственно импортировать пакет можно с помощью пункта меню «Файл -> Импорт -> Личный веб-пакет». Это далеко не самый лучший способ миграции. Во-первых, после переноса возникают проблемы с мастер-страницей, во-вторых, существенно измененные разработчиками узлы экспортироваться этим способом не хотят вообще. Пакет .fwp, созданный с помощью утилиты smigrate в WSS 2.0, нельзя импортировать в WSS 3.0. Создать пакет содержимого .cmp можно с помощью пункта меню «Узел -> Администрирование -> Создать резервную копию веб-узла». Восстановить из того раздела, пункт «Восстановить резервную копию веб-узла». Пакет .cmp при создании с помощью SP Designer не предоставляет никаких опций для выбора, не включает рабочие процессы, оповещения и корзину. Наконец, с помощью веб-интерфейса можно сохранить любой узел, библиотеку или список в виде шаблона (уровни 4 и 5 на схеме, рис. 1). Сделать это можно из меню «Параметры узла -> Сохранение узла в качестве шаблона» и «Параметры списка -> Сохранение списка в качестве шаблона» соответственно. Сохранять шаблон можно со всем содержимым или без него. Выбрать часть содержимого нельзя. После чего файл с шаблоном (Site Template, .stp) появится в галерее шаблонов узлов данного семейства. Галерея доступна на странице «Параметры узла/Шаблоны узлов» для верхнего узла семейства (см. рис. 6).
Рисунок 6. Галерея шаблонов узлов Отсюда файл с шаблоном можно сохранить, чтобы затем загрузить его в галерее шаблонов на другом сервере (для этого потребуются права администратора семейства узлов). В следующий раз при создании узла или списка можно будет выбрать этот шаблон из списка в подразделе «Настройка» (см. рис. 7).
Рисунок 7. Создание нового узла по шаблону На самом деле, очевидно, что этот способ предназначен для тиражирования решений с неким предварительным набором данных или же без него. Однако его можно использовать и для переноса. Недостаток этого метода по сравнению с операцией «stsadm import/export» заключается в том, что развернуть пакет типа .stp поверх уже существующего узла с сохранением предыдущих версий документов невозможно. Узел придется удалить и создать заново. Кроме того, не сохраняется информация о пользователях и их правах. Достоинство метода очевидно – его удобно использовать, когда с одного узла нужно создать много копий. Как и в случае с операцией «import/export», возникает та же проблема с идентификаторами списков и веб-частей, которая решается подобным же образом. Замечу также, что для программистов в API появился специальный интерфейс для доступа к операциям резервного копирования (пространство имен Microsoft.SharePoint.Administration.Backup). Это позволяет как сохранять копии различных составляющих портала в произвольном порядке, так и включать в стандартный backup новые элементы. Более подробную информацию можно найти в [1]. Решения сторонних разработчиков Обращу еще раз внимание на блог Gary Lapointe [4]. Блог целиком посвящен расширениям для stsadm, среди которых можно найти много команд, весьма полезных при миграции. Например, операция gl-moveweb позволяет быстро перемещать узел из одного семейства узлов в другое или из одного веб-приложения в другое в рамках одного сервера. Или операция «gl-convertsubsitetositecollection» – превращает узел в семейство узлов. Всего полезных команд в этом блоге на текущий момент целых 98. Самое интересное, что приведены они с исходным кодом и комментариями автора. Скачать все это удовольствие можно бесплатно. В Интернете можно найти и другие решения сторонних разработчиков для упрощения процедуры миграции. После миграции После миграции узла необходимо проверить его работоспособность, в частности корректность работы ссылок. Для этого можно воспользоваться отчетом в SharePoint Designer: «Узел -> Отчеты -> Гиперссылки -> Ошибки». Ошибочные ссылки можно исправить, например, с помощью операции «gl-applyupgradeareaurlmappings» все из тех же расширений stsadm Gary Lapointe [4]. Удобна она тем, что все ссылки можно предварительно записать в специальный список, а затем запустить замену по всем ссылкам сразу. Распространение решений Если на вашем портале много различных элементов кастомизации, для удобства установки и переноса их можно сгруппировать в «возможности» или «features». Feature – в не вполне удачном, на мой взгляд, официальном переводе «возможность» (разработчики фамильярно называют просто «фичей») – удобный способ распространения готовых решений. В одну «фичу» можно включить все необходимые веб-части, шаблоны списков, собственные типы содержимого, действия узла (Site Actions), Custom Actions для рабочих процессов, обработчики событий и некоторые другие вещи. Если вы запакуете в «фичу» все ваши собственные наработки, вам не придется отдельно и вручную переносить все вышеупомянутые компоненты. Feature представляет собой набор xml-файлов. Чтобы создать feature, нужно создать директорию в папке «%PROGRAMFILES%Common FilesMicrosoft Sharedweb server extensionsTEMPLATEFEATURES» и разместить в ней два xml-файла: feature.xml, который содержит описание, уникальный идентификатор и область действия, а также файл Elements.xml с описание элементов, которые входят в «фичу». Подробная информация с примерами приведена в [2]. Установить «фичу» можно с помощью операции: stsadm –o installfeature –filename После установки активировать ее можно в меню «Параметры узла -> Возможности узла» или с помощью операции: stsadm –o activatefeature –filename -url По работе с «фичами» обращу ваше внимание на полезный блог – Татьяны Сметаниной, сотрудника Microsoft Russia [5].
Рисунок 8. Сравнительная таблица по методам миграции Заключение Выбор того или иного инструмента зависит от конкретной ситуации: что, куда и при каких условиях нужно перенести. Отмечу еще раз, что новые версии SharePoint предоставляют необходимые интерфейсы, чтобы расширить стандартные инструменты и оптимизировать часто выполняемые операции по переносу.
|
НЕЛЛИ САДРЕТДИНОВА
| Комментарии |
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
