Рэнди Уильямс (RWilliams@synergyonline.com) — MVP по SharePoint Server, старший консультант в компании Synergy Corporate Technologies

В апреле 2012 года Microsoft SharePoint 2010 отметил двухлетие со дня выпуска. Я замечаю, что организации, использующие этот продукт в течение года или более, расширяют диапазон его применения. Многие начинали с использования SharePoint в качестве базового средства для совместной работы, однако постепенно становятся привычными и другие виды его применения: бизнес-аналитика (business intelligence, BI), управление корпоративным информационным содержимым (Enterprise Content Management, ECM) и социальные сети. Многие организации дополняют функциональность SharePoint с помощью сторонних продуктов или собственных разработок. Чем больше содержимого накапливается в SharePoint, тем больше места занимает его хранилище. Рост числа публикаций об управлении SharePoint показывает, что SharePoint становится все более зрелым решением.

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

-пользовательский код;

-очень большие базы данных содержимого;

-удаленное хранилище объемных двоичных объектов Remote BLOB Storage (RBS).

Судя по моему опыту, эти факторы чаще всего создают трудности в процессе восстановления. Кроме того, они же являются и основными направлениями, в которых происходит развитие зрелых систем SharePoint. Хотя информация, изложенная в данной статье, предназначена для среды SharePoint 2010, большая ее часть применима и к Windows SharePoint Services 3.0 (WSS) и Microsoft Office SharePoint Server 2007 (MOSS). WSS и MOSS не поддерживают RBS, но соответствующая форма, называемая External BLOB Storage (EBS), может использоваться в SharePoint 2007 Service Pack 1 (SP1) и более новых редакциях.

Влияние пользовательского кода на аварийное восстановление

Для меня наиболее впечатляющим свойством SharePoint как коробочного продукта является его гибкость. Мои коллеги часто сравнивают SharePoint с швейцарским армейским ножом или чудо-пластилином Play-Doh, и я с ними согласен. Это универсальный инструмент, который может принимать бесконечное число форм. Но удивительная гибкость SharePoint проистекает не из его богатого пользовательского интерфейса, а из лежащей в его основе технологической платформы. Объектная модель SharePoint (то есть программный интерфейс API) — технологическая платформа, позволяющая разработчикам строить мощные бизнес-решения. Подтверждением этой гибкости является целая «экосистема» независимых производителей и их продуктов, построенных на платформе SharePoint.

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

Допустим, вашей компании нужны заказные веб-части для использования в основанном на базе знаний решении, разрабатываемом для SharePoint. Команда разработчиков пишет код, тестирует веб-части и внедряет их в производственной среде. На каждом внешнем веб-сервере Web Front End (WFE) набор библиотек DLL копируется в глобальный кэш сборок, вносятся изменения в конфигурационные файлы web.config, необходимые для веб-частей файлы добавляются в корень SharePoint (в папку 14 — так называемый «куст SharePoint»). Несколько месяцев спустя один из внешних веб-серверов с балансировкой нагрузки выходит из строя и заменяется новым сервером, добавляемым в ферму. На следующий день пользователи сталкиваются с проблемами в работе с базой знаний. После пары часов поисков решения вы обнаруживаете, что проблемы возникают лишь при обращении к новому серверу. Только после этого вы вспоминаете, что на исходном сервере был размещен заказной пользовательский код. После ручного переноса всех необходимых файлов и обновления файла web.config проблема устраняется.

Однако для данного сценария имеется более удобное решение. Вместо размещения программного кода для автоматизации развертывания пользовательского кода вручную и внесения изменений в конфигурацию вы можете использовать пакеты решений SharePoint Solution Packages (WSP). Если вы применяете пакет решений для развертывания заказных веб-частей на сбалансированной ферме, пользовательский код развертывается автоматически после добавления в ферму сервера. Я рекомендую требовать создания WSP для каждого внедряемого заказного решения. А еще лучше по мере возможности разрабатывать заказной код в виде изолированного решения (которое тоже является пакетом WSP).

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

А что делать, если вы вручную вносите изменения в конфигурацию сервера? Например, изменяете файл docicon.xml для добавления поддержки значков PDF-документов или модифицируете файл web.config для веб-приложения, которое будет использовать проверку подлинности с помощью форм. В таких случаях лучше всего вести журнал, в котором будут зафиксированы все ручные изменения в настройках серверов. Храните этот журнал в таком месте, откуда его можно будет легко извлечь, не в SharePoint, поскольку вам может потребоваться доступ к нему, когда SharePoint недоступен. С помощью таких приемов, если придется заменить один из серверов, вы будете точно знать, что надо делать, и сбережете в процессе восстановления много времени и нервов. Если ваши интерфейсные веб-серверы виртуализованы, то у вас есть прекрасная возможность создания моментального снимка и восстановления из него. И, конечно, вы всегда можете сделать полную резервную копию всего сервера. Обязательно используйте какой-то из этих подходов как часть своей стратегии восстановления.

Влияние на аварийное восстановление больших баз данных содержимого

В июле 2011 года корпорация Microsoft выпустила переработанное руководство по управлению размером баз данных содержимого (документ «SharePoint Server 2010 capacity management: Software boundaries and limits» по адресу http://technet.microsoft.com/en-us/library/cc262787.aspx#ContentDB). Коротко говоря, предельный поддерживаемый размер отдельной базы данных увеличен до 4 Тбайт; при этом отсутствует явное ограничение на размер архивов документов, таких как центр записей Records Center. Заметим, что ряд выпущенных официальных уведомлений, включая возможные изменения в производительности на уровне хранилища баз данных и необходимость корректировки плана аварийного восстановления, применимы и к этим ограничениям.

Относительно аварийного восстановления проблема с большими базами данных содержимого заключается в том, как долго создается резервная копия и сколько по времени восстанавливаются данные. По мере развития среды SharePoint в организации его важность возрастает. Она обычно проявляется в более жестких требованиях к восстановлению. И действительно, я все чаще слышу о случаях, когда максимально допустимое время простоя recovery time objective (RTO) сокращается до нескольких минут. Однако учитывая, что большинство операций восстановления (включая, естественно, корзину) начинаются с восстановления базы данных содержимого, то как вы сможете удовлетворять требования соглашения об уровне обслуживания (SLA), если одно только восстановление базы данных занимает 6 часов?

Первое из возможных решений заключается в ограничении размера вашей базы данных. В большинстве сценариев я рекомендую поддерживать размер базы данных содержимого не более 200 Гбайт. В процессе структурирования наборов сайтов в базу данных содержимого анализируйте шаблоны использования и изолируйте некоторые особые шаблоны в отдельных базах данных. Например, не размещайте сайты групп с большим объемом записываемых данных в той же базе данных, в которой хранится корпоративный портал с информацией, доступной в режиме чтения. Раздел My Sites («Мои сайты») всегда должен храниться в отдельной базе данных (помните, что каждый узел «Мой сайт» представляет собой набор сайтов), и желательно, чтобы он был связан с отдельным веб-приложением для лучшего контроля того, в какой базе данных создаются новые узлы My Sites. Каждый из больших архивов, таких как центр записей или документов, также должен иметь отдельную базу данных содержимого. Используя такой подход, вы не только уменьшаете размер баз данных, но также можете реже делать резервные копии для менее важных баз данных содержимого или баз данных, предназначенных для использования в режиме чтения.

Другим решением является развертывание SP1 для SharePoint 2010. Одной из возможностей этого пакета обновлений является возможность хранения удаленных веб-сайтов в корзине (специальном наборе сайтов второго уровня). Теперь при случайном удалении какого-либо блог-сайта администратор набора сайтов может его легко восстановить. Данная возможность позволит вам сэкономить много времени и сил.

По мере роста объема содержимого вы все яснее осознаете, что встроенные в SharePoint средства резервного копирования и восстановления слишком ограничены. И часто для соответствия требованиям SLA необходимо обращаться к решениям сторонних разработчиков. Имеется ряд превосходных продуктов, которые окупают себя, если помогают быстро восстановить данные хотя бы после одной аварии. Эти инструменты также очень хороши при выполнении повседневных действий по восстановлению данных, например при восстановлении отдельных элементов; они позволяют вам соблюдать требования к допустимому времени простоя.

И, разумеется, средства обеспечения высокой доступности, такие как кластеризация Microsoft SQL Server, зеркалирование баз данных или новая функция SQL Server 2012, называемая AlwaysOn, должны стать частью вашей стратегии аварийного восстановления. Хотя эти средства не помогут при необходимости восстановления содержимого, они будут поддерживать ферму в рабочем состоянии при выходе из строя какого-либо сервера баз данных.

Влияние RBS на аварийное восстановление

С ростом объема баз данных содержимого растет и размер используемых хранилищ. При хранении баз данных на высокопроизводительном хранилище 1-го уровня стоимость управления этим хранилищем становится серьезной проблемой. Одним из решений является применение RBS для хранения документов вне базы данных, в более подходящем по стоимости хранилище, как показано на рисунке. При этом не только снижается стоимость хранилища, но и может ускориться работа ваших серверов SQL Server за счет избавления от необходимости выполнять запросы чтения/записи для документов.

 

Схема работы RBS
Рисунок. Схема работы RBS

Задача аварийного восстановления усложняется из-за того, что теперь у вас имеются две структуры для резервного копирования и восстановления: база данных содержимого и хранилище внешних документов, называемое хранилищем больших двоичных объектов (BLOB store). При использовании RBS в базе данных содержимого хранятся указатели, ссылающиеся на внешние двоичные BLOB-объекты, и эти ссылки нужно поддерживать в актуальном состоянии. Хотя данная задача может показаться сложной, на самом деле это необязательно. Давайте постараемся вникнуть в работу RBS и понять, почему это так.

Прежде всего, необходимо знать, что файлы в хранилище BLOB хранятся неизменными. При редактировании документа в SharePoint создается новый объект BLOB, а не замещается документ в существующем объекте. Этот процесс работает независимо от любых настроек управления версиями. Удаление документа из библиотеки (и из корзины) удаляет метаданные и помечает указатель как удаленный, но сам BLOB-объект хранится в течение определенного времени. Спустя некоторое время из BLOB-хранилища удаляются и сами файлы.

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

Наличие такого окна (официально называемого «временное окно сборки мусора») очень удобно в повседневных операциях восстановления при использовании RBS. Представим, например, что некий документ случайно был удален в понедельник утром. В SharePoint теперь отсутствуют метаданные этого документа, но соответствующий файл BLOB-объекта остается в хранилище. Просто восстанавливая воскресную резервную копию, вы легко восстанавливаете метаданные и указатель на BLOB-объект, который по-прежнему ссылается на существующий файл в BLOB-хранилище. Другими словами, у вас нет необходимости восстанавливать данные BLOB-хранилища.

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

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

Также стоит упомянуть, что многие поставщики хранилищ, такие как EMC и NetApp, позволяют зеркалировать хранилище BLOB. В таких случаях аварийное восстановление выполняется проще и быстрее, но не забудьте согласовать с вашим поставщиком хранилища необходимость наличия данной возможности.

Если вы решаете использовать RBS, то имейте в виду, что его возможности у разных производителей различны. Например, Microsoft предлагает бесплатное RBS-решение FILESTREAM. Если FILESTREAM работает в локальном режиме (то есть хранилище BLOB- размещено на локальном сервере SQL Server), то резервная копия базы данных включает в себя и BLOB-данные. Однако недостатками FILESTREAM являются сложная установка и обслуживание. При выборе поставщика обязательно заранее тщательно продумайте все аспекты своей среды, включая аварийное восстановление.

Заключительное замечание: RBS не может использоваться для расширения поддерживаемых Microsoft размеров базы данных содержимого. Например, расширение с помощью RBS базы данных содержимого размером 5 Тбайт, используемой для сайтов проектных групп, может создать неподдерживаемое решение. При планировании максимальных размеров баз данных не забывайте учитывать как внутреннее содержимое (действительный размер базы данных), так и внешнее BLOB-хранилище.

Более подробная информация о принципах работы RBS содержится в документе по Microsoft SQL Server: «Remote BLOB Storage» (http://go.microsoft.com/fwlink/?linkid=210422). RBS, его преимущества и тонкости использования хорошо описаны в технической статье компании AvePoint «Optimize SharePoint Storage with BLOB Externalization» (http://www.avepoint.com/assets/pdf/sharepoint_whitepapers/optimize_sharepoint_storage_with_blob_externalization.pdf).

Возьмите под контроль

Дозрела ли ваша среда SharePoint до того уровня, при котором внедряется пользовательский код, применяются большие базы данных содержимого, рассматривается использование RBS-решений? Если еще нет, то это вопрос времени. Когда я бываю на больших предприятиях и в компаниях среднего размера, я вижу, что у них одна из главных проблем — управление большими базами данных содержимого и обоснованность использования RBS. Большинство компаний также применяют заказной код, написанный либо в самой компании, либо сторонними разработчиками. Однако не стоит этого бояться: изложенные в данной статье идеи помогут вам установить контроль над SharePoint до того, как он установит контроль над вами.