Восстановление SharePoint 2010 в аварийных ситуациях. Часть 2

В статье «Восстановление SharePoint 2010 в аварийных ситуациях, часть 1», опубликованной в Windows IT Pro/RE № 12 за 2011 год, я рассказал о типах аварийных ситуаций, которые могут угрожать вашему серверу Microsoft SharePoint Server, и о методах их предотвращения. .

Исходные данные

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

Также необходимо знать объективное время восстановления Recovery Time Objective (RTO), указывающее на то, как быстро вернется в строй SharePoint после потери работоспособности систем. Например, RTO может констатировать, что, когда SharePoint дает сбой, реально вернуть его в сеть можно не ранее чем через 4 часа. Четко прописанное время RTO помогает определить стратегию восстановления и подготовить пользователей.

Другой важный фактор успешного восстановления — это объективное время состояния после восстановления Recovery Point Objective (RPO), которое определяет состояние данных, доступных по сети после процедуры восстановления. В первой части статьи я рассказал об RPO с точки зрения версий документов, которые должны быть восстановлены. RPO определяет крайнее состояние, к которому процесс восстановления должен прийти.

Чтобы проиллюстрировать сказанное, приведу один пример. Предположим, ваш период RTO составляет 2 часа, а RPO — полночь предыдущего дня. Если кто-то звонит вам в 1:00 дня, чтобы сообщить о недостающем контенте, необходимо до 3:00 дня (так как ваш RTO составляет 2 часа) восстановить данные в состояние на полночь предыдущего дня (то есть ваш RPO).

Иметь четко заданные RTO и RPO при планировании стратегии процесса восстановления обязательно. Если вы запускаете копии только в полночь, а ваш RPO констатирует, что ваши пользователи не потеряют более 4 часов работы, возникает конфликт. Чтобы соответствовать RPO, нужно увеличить частоту создания копий — как минимум, это будет стоить денег и, возможно, производительности. Однако компромисс необходим для достижения ваших целей. В большинстве случаев, чем короче RTO или RPO, тем больше приходится тратить денег и времени на управление.

Простои из-за аварийной ситуации

Теперь, когда мы изучили основы, давайте перейдем к техническим аспектам процесса восстановления. Для восстановления после аварийной ситуации вы можете, как минимум, сделать копию баз данных. Как говорится, данные — это все: если у вас есть все копии баз данных, то у вас в руках весь контент. Удаленное хранилище больших файлов Remote Blob Storage (RBS) представляет проблему при резервировании базы данных; дополнительная информация об этом приведена во врезке «Удаленное хранилище влияет на копирование базы данных».

О процессе копирования всех баз данных SharePoint в случае аварийного отказа я подробно рассказываю в своем блоге «Программирование копирования SQL Server для SharePoint» на сайте www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=248. Пока вы будете читать блог, создавайте копии баз данных SQL Server. Они не займут много места, но будут у вас под рукой, если потребуется восстановить SQL Server с рабочей области. Вы можете использовать эти копии баз данных не только для восстановления индивидуальных элементов (я рассказывал об этом в первой части статьи). Вы также можете задействовать их для восстановления коллекций сайтов, веб-приложений, служебных приложений или всей фермы. Давайте подробно рассмотрим эти сценарии.

Аварийные отказы SharePoint. Предположим, у вас есть обычная маленькая ферма, состоящая из одной системы SQL Server и одного сервера SharePoint. Как хороший администратор SQL Server, вы каждый вечер делаете копии всех баз данных. В одно прекрасное утро вы приходите и слышите крики пользователей: «SharePoint рухнул!». Выпив чашечку кофе, вы пытаетесь подключиться к SharePoint и понимаете, что он действительно отказал. Причем не только SharePoint, но и весь сервер. Вы не можете подсоединиться к серверу через RDP, он не отвечает на запросы по ping — это явная смерть. Вы спешите в серверную комнату и видите, что сервер SharePoint застыл на экране загрузки, поскольку не может найти жесткий диск, с которого эта загрузка должна осуществляться. Какая бы дисковая подсистема ни была, один ли диск, RAID 1 или RAID 5, все это может сломаться. Сервер и весь контент на нем исчезли. Что вам делать, кроме как поискать в кармане флэшку со своим резюме?!

На самом деле это не такой уж серьезный тип аварийной ситуации, поскольку рухнул только ваш сервер SharePoint. Хотя сервер SharePoint и является важной частью системы SharePoint, сервер SQL Server не менее важен, поэтому вы можете воспользоваться преимуществом функционирования системы SQL Server для быстрого исправления ситуации. Вам нужно заставить сервер работать либо при помощи нового сервера, либо починив то, что сломалось в имеющемся сервере, а затем переустановить Windows и загрузить все обновления, выполнить настройки и присоединиться к домену. Затем требуется переустановить SharePoint. После того как все предварительные условия выполнены и файлы SharePoint установлены, следует запустить мастер SharePoint Products Configuration Wizard.

Вот именно здесь и происходит «волшебство». Вместо строительства новой фермы SharePoint вы можете просто подсоединиться к существующей ферме. Когда появится запрос, к какой ферме подсоединиться, укажите существующую систему SQL Server и базу данных конфигурации SharePoint, которую эта система содержит. Вооруженный информацией, содержащейся в базе данных конфигурации вашей фермы, вновь построенный сервер SharePoint может получить доступ к существующим веб-приложениям и начать их обслуживание практически немедленно. SharePoint использует плановые задания для создания той среды, которая необходима для обслуживания контента. Ваши веб-приложения будут созданы в Microsoft IIS при помощи этих плановых заданий. Решения, которые были установлены в вашей ферме, будут установлены на новый сервер при помощи этих заданий. Когда параметры конфигурации будут заданы, возможно, потребуется подчистить некоторые мелочи, но эти задачи — ничто по сравнению с выполненным восстановлением сервера после полного краха.

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

• любые заголовки хоста в IIS; SharePoint создает только заголовок, который был сконструирован при создании веб-приложения;
• любые сертификаты SSL, если ваш сайт SharePoint использует HTTPS;
• любые файлы, которые не были добавлены к корневому каталогу SharePoint (ветка 14) вместе с функцией или решением (например, значки документов);
• любые изменения, которые были сделаны в файлах web.config, такие как настройка аутентификации на базе форм.

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

Аварийный отказ SQL Server. Хотя рухнувший сервер SharePoint может быть худшей неприятностью за день, этой беде легко помочь, потому что большая часть того, что делает SharePoint таким ценным, — различные виды контента — на самом деле хранится на сервере SQL Server. Но что происходит, если рушится сервер SQL Server? Этот тип аварийной ситуации не очень сложен для восстановления, поскольку у вас есть копии. Если останавливается сервер SQL Server, SharePoint не сможет обслуживать какие-либо виды контента пользователей и предоставлять вам административный интерфейс. Но это не страшно, поскольку ваши попытки восстановления будут сосредоточены исключительно на SQL Server.

Серверы останавливаются по разным причинам, поэтому и методы восстановления различны. Представьте, что сама система SQL Server в порядке, но диски, на которых хранятся базы данных SharePoint, находятся в аварийном состоянии. Это может быть либо большое дорогое устройство SAN или NAS, либо пара внутренних дисков Serial ATA (SATA). SharePoint не будет работать, пока вы не вернете базы данных в оперативный режим. После решения проблем с системой хранения будут восстановлены и базы данных SharePoint на сервере SQL Server. Как только вы восстановите базы данных с их прежними именами, SharePoint должен просто подсоединиться к ним. Чтобы все заработало, вам может потребоваться перезагрузка систем SharePoint, в зависимости от состояния, в котором находились соединения. Многие процессы SharePoint сообщаются с сервером SQL Server, а внезапный разрыв этих соединений может вывести SharePoint из строя. Перезагрузка обычно устраняет любые неудобства.

А что если хранилище в порядке, а рухнула сама система SQL Server? Может быть, замкнул блок питания или, что еще хуже, вышла из строя материнская плата. И опять SharePoint будет готов ко всему. Если вы сможете отремонтировать сервер и восстановить его в прежнее состояние, SharePoint и не заметит, что были неполадки. Как и в предыдущем случае, перезагрузка поможет «все забыть».

А что если вы не можете вернуть свою систему SQL Server в прежнее состояние? Что если диск операционной системы разрушен, блок питания сгорел, конденсатор больше не выдает ток и вам нужно переустановить систему? А что если аварийный сервер выполнял Windows Server 2003 и SQL Server 2005? Переустановка этих программ в 2011 году кажется нелогичной. К счастью, ни один из этих вопросов не относится к SharePoint. Если SQL Server попал в аварийную ситуацию, вы можете заменить его, запустив на новой операционной системе, такой как Windows Server 2008 R2 SP1, последнюю версию сервера SQL Server. Как только новый экземпляр SQL Server и базы данных получат прежние имена, SharePoint вновь не будет волноваться. И опять: перезагрузка серверов SharePoint приведет ситуацию в норму.

А что если экземпляр SQL Server не может иметь то же самое имя? Может быть, с того времени, когда был развернут SQL Server для фермы SharePoint, ваша компания вложила массу времени и средств в мощную централизованную систему SQL Server. Если рухнула текущая система SQL Server, это будет наиболее подходящим моментом для перемещения всего, что есть, в новую систему. Однако имена экземпляров SQL Server различны, и вам, вероятно, надо будет перейти от экземпляра по умолчанию SQL Server (просто с именем системы SQL Server) к именованному экземпляру (системное имя SQL Server плюс имя экземпляра, например sql01\shpt), что еще более усложняет процесс. Такой сценарий может показаться вам невыполнимым, но, к счастью, это не так. Скрытый в SQL Server клиент Windows имеет возможность устанавливать псевдонимы SQL Server. Это делается на довольно низком уровне, так что сами приложения (в нашем случае это SharePoint) ничего не знают. Они продолжают считать, что связываются с той же самой системой SQL Server, но на самом деле SQL Server с псевдонимом посылает трафик к другой системе SQL Server.

Но не беспокойтесь, все гораздо проще, чем кажется. Однажды проделав это, вы сможете использовать эту технику в случаях менее опасных, чем глобальная авария. В данной статье я не смогу рассказать о псевдонимах SQL Server от начала до конца, но все-таки некоторые основы изложу. Если вам нужно более детальное описание процесса, вы можете обратиться к моему блогу «Перемещение SharePoint на другой сервер SQL server» на сайте www.toddklindt.com/blog/Lists/Posts/Post.aspx? ID=255.

Особенность псевдонимов SQL Server заключается в том, что они создаются на стороне клиента. Вам вовсе не нужно получать доступ к системе SQL Server. На каждом из своих серверов SharePoint введите псевдоним SQL Server, который указывает на новую систему SQL Server. Для того чтобы это сделать, выберите Start, Run и введите cliconfg. Нажмите Add, чтобы создать новый псевдоним. SharePoint использует TCP/IP для связи с SQL Server, поэтому необходимо выбрать TCP/IP, как показано на экране 1.

Экран 1. Создание нового псевдонима SQL Server

В текстовом окне Server alias введите имя своей старой системы SQL Server. Это та самая система SQL Server, на взаимодействие с которой был настроен SharePoint. На вкладке Connection parameters в текстовом окне Server name введите новое имя системы SQL Server. Нажмите OK для завершения процесса создания псевдонима. Если хотите, перезагрузите свои серверы SharePoint, чтобы восстановить все соединения SQL Server. Если у вас в ферме несколько серверов SharePoint, нужно создать один псевдоним на всех.

SharePoint 2010 имеет специфическую функцию для среды, которая использует зеркальные копии SQL Server. Далее в этой статье я расскажу о различных способах копирования ваших баз данных более подробно и объясню, что такое зеркальное копирование. Для каждой базы данных SharePoint можно указать зеркальный сервер. На экране 2 показаны настройки базы данных контента.

Экран 2. Настройки базы данных контента

Другие базы данных имеют похожий интерфейс. Настройка Failover Server — это то место, где вы определяете зеркальную копию. Если останавливается главная система SQL Server, а зеркальная копия задана, SharePoint автоматически подключается к ней. Отладив свою основную копию SQL Server, вы можете переподключиться и перестроить зеркало SQL Server. Это позволяет вам поддерживать SharePoint в оперативном режиме в процессе решения проблемы и оберегает от осады пользователей с факелами и вилами.

Отказы оборудования. SharePoint может быть очень гибким, когда рушатся отдельные элементы. Но что если все оборудование отказало? Где бы ни были расположены ваши серверы, есть ведь и «природные катаклизмы». Теперь, когда мы знаем, как восстанавливать индивидуальные элементы SharePoint, мы можем разобраться с тем, как предотвращать внезапный отказ их всех сразу.

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

В SharePoint 2010 у нас имеется возросшее количество данных в наших служебных приложениях баз данных. Определения наших соединений Business Connectivity Services хранятся в базе данных Business Connectivity Services. Наши наборы терминов хранятся в базе данных Managed Metadata. Наши теги и заметки хранятся в базе данных Social в User Profile Service. Мы можем не только присоединить базы данных контента к своей ферме восстановления, но и подправить некоторые служебные приложения баз данных. Этот процесс проходит не так гладко, как присоединение баз данных контента, но и без больших затруднений. По существу, нам нужно создать новое служебное приложение и нацелить его на базу данных восстановления с аварийной фермы. Когда SharePoint создает новое служебное приложение, это выглядит так, как будто бы база данных с именем, которое вы определили, существует. Если это так, то вместо создания новой базы данных SharePoint будет использовать существующую базу данных. Этот процесс работает со следующими служебными приложениями:

• управляемые метаданные;
• Business Connectivity Services;
• User Profile Service (поддерживается только для баз данных Social и Profile); создайте новую базу данных Sync, когда присоединитесь к существующим базам данных Social и Profile;
• Secure Store — вам нужно ввести ключ от своей старой фермы, прежде чем новое служебное приложение Secure Store сможет смонтировать вашу базу данных;
• некоторые служебные приложения (например, Excel Service) не имеют баз данных, поэтому нам не нужно беспокоиться о них; другие служебные приложения имеют базы данных (например, Search), которые не поддерживают присоединение к другой ферме.

Для использования фермы восстановления следует убедиться, что ферма построена на той же сборке или более новой по сравнению с той фермой, откуда происходит та или иная база данных. Если вы не знаете наверняка, какая сборка соответствует какому обновлению, можете заглянуть на мою страничку в блог, посвященный списку сборок SharePoint 2010 (www.toddklindt.com/blog/Lists/Posts/Post.aspx? ID=224).

Когда случается аварийный отказ, можно взять резервные копии служебных приложений баз данных и восстановить их на SQL Server в своей ферме восстановления. Если ферма восстановления уже имеет специфическое служебное приложение, вы можете удалить и вновь создать его или создать второй экземпляр. Также следует присоединить базы данных контента. Если вы хотите узнать больше о переименовании и перемещении баз данных, просмотрите статьи Microsoft TechNet «Переименование или перемещение баз данных служебных приложений (SharePointServer 2010)» по адресу technet.microsoft.com/en-us/library/ff851878.aspx и «План бесперебойной работы (SharePoint Server 2010)» по адресу technet.microsoft.com/en-us/library/cc748824.aspx.

Планы на будущее

Хотя я и указал на необходимость создания копий баз данных для фермы восстановления, но не объяснил четко, как это сделать. Любой метод, который копирует базы данных SQL Server, годится; метод, который вы используете, зависит от многих факторов. Наиболее важный фактор — это, вероятно, цена. Вариант с высокой готовностью, такой как зеркало, требует дополнительных лицензий SQL Server и времени для настройки. Однако за дополнительную цену вы получаете более низкие значения RTO и RPO и повышение устойчивости бизнеса. Зеркальное копирование баз данных — это функция SQL Server, которая отражает изменения, произведенные в базе данных на одной системе SQL Server, на соответствующей базе данных на другом SQL Server. SQL Server реализует эту функцию, копируя транзакции из вашей основной копии и повторяя их на зеркальной. Этот процесс синхронизирует ваши копии и снижает вероятность того, что вы потеряете данные, если ваша основная система SQL Server рухнет. Настройки зеркальных копий различаются: здесь все зависит от того, какую версию SQL Server вы запускаете.

Если у вашего предприятия нет потребности или резервов для развертывания зеркального варианта, вы можете использовать пересылку журнала транзакций другому экземпляру SQL Server. В этом случае при отказе можно будет восстановить базу данных и копии журнала транзакций на восстановительном экземпляре SQL Server. После того как SharePoint опять войдет в оперативный режим, вы можете использовать псевдоним SQL Server, чтобы указать ферме SharePoint новый экземпляр SQL Server. Если у вас нет копии журнала транзакций для восстановления, восстановленный экземпляр может быть заполнен последней копией базы данных. Конечно, все зависит от выбранных RPO. Суть в том, что как бы вы ни решили резервировать ваши базы данных, SharePoint будет работать по вашему варианту.

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

Тодд Клиндт (todd@sharepoint911.com) — консультант по SharePoint, имеет звание SharePoint MVP