Планирование доступности (Office SharePoint Server)

В этой статье описывается понятие доступности в целом, расходы и задачи, связанные с доступностью в среде продуктов и технологий SharePoint, а также стратегии и решения, которые можно использовать в этой среде. Эту статью следует прочитать, если в вашей ферме используется Microsoft Office SharePoint Server 2007. Можно загрузить и распечатать файл модель доступности сервера Office SharePoint Server 2007 (https://go.microsoft.com/fwlink/?linkid=122369&clcid=0x419) (на английском языке), прилагаемый к данной статье. В нем приведен краткий обзор содержимого данной статьи в виде плаката.

Обзор доступности

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

Одним из наиболее распространенных показателей доступности является процент времени безотказной работы, выражаемый количеством девяток — то есть процента времени, в течение которого заданная система является активной и рабочей. Например, система с процентом времени безотказной работы 99,999 обладает доступностью пяти девяток.

В следующей таблице сопоставляется количество девяток с эквивалентом в виде календарных дней.

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

% Uptime/year = 100 - (8760 - number of total hours down per year)/8760

% Uptime/month = 100 - ((24 * number of days in the month) - number of total hours down in that calendar month)/(24 * number of days in the month)

% Uptime/week = 100 - (168 - number of total hours down in that week)/168

Что не является доступностью

Доступность — это не защита и восстановление данных, это не восстановление после сбоев, хотя эти понятия взаимосвязаны, поскольку в системе с высокой доступностью должны существовать защита данных и планы восстановления в случае сбоев. Защита и восстановление данных — это общая бизнес-потребность, которая подчеркивает следующие конкретные бизнес-потребности:

• ведение и просмотр нескольких версий элемента или сайта;

• восстановление случайно удаленных элементов или сайтов;

• архивирование данных в соответствии с законодательными, нормативными и бизнес-требованиями;

• восстановление системы в случае неожиданного сбоя оборудования или программного обеспечения.

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

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

• четко задокументированные процедуры;

• внешнее хранилище основных бизнес-записей;

• четко обозначенные контакты;

• текущее обучение персонала;

• внешние механизмы восстановления.

Стоимость доступности

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

• дополнительное оборудование и программное обеспечение, часто подразумевающие сложные операции между программным обеспечением, например собственные сценарии для отработки отказа и восстановления;

• дополнительная сложность в управлении.

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

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

Задачи по обеспечению доступности в продуктах и технологиях SharePoint

При развертывании продуктов и технологий SharePoint возникают следующие проблемы, связанные с доступностью:

• Во время применения исправлений или обновления фермы ферма является недоступной.

• Не удается достичь избыточности сервера индекса путем установки роли индексирования на нескольких серверах. Чтобы решить проблему потери сервера индекса, потребуется переустановить сервер и либо выполнить восстановление из резервной копии, либо довольствоваться несколько устаревшими результатами, пока функция поиска производит повторный обход контента. Кроме того, можно воспользоваться одной из методик, описанных в разделах Доступность поиска внутри фермы и Доступность поиска среди ферм, чтобы уменьшить время, необходимое для восстановления функции поиска.

• Продукты и технологии SharePoint не поддерживают зеркало базы данных Microsoft SQL Server 2005. Несмотря на то, что рекомендуется рассмотреть возможность использования зеркала SQL Server в качестве способа обеспечения доступности для SharePoint, в этом случае требуется дополнительная автоматизация.

Когда необходимо рассматривать вопрос доступности

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

Определение требований по доступности

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

• Приведет ли недоступность веб-сайта, службы или фермы к тому, что сотрудники организации не смогут выполнять свои обычные должностные обязанности?

• Приведет ли недоступность веб-сайта, службы или фермы к остановке деятельности и сделок с клиентами и, как результат, убыткам и потере клиентов?

Если вы ответили да на какие-либо из приведенных вопросов, вам следует вложить средства в решение по обеспечению доступности.

Выбор стратегии доступности

Можно выбрать один из многих подходов к повышению доступности, включая:

• отказоустойчивость компонентов;

• избыточность и отработка отказа между ролями серверов и базами данных внутри фермы;

• избыточность и отработка отказа между фермами серверов.

Системные требования для обеспечения доступности

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

• версия операционной системы и все установленные обновления;

• версии сервера SQL и все установленные обновления;

• версии продуктов и технологий SharePoint и все установленные обновления.

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

• следует обеспечить полную избыточность систем, от которых зависит работоспособность инфраструктуры, например питания, охлаждения, сети, каталоги и SMTP.

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

  • Корпоративный дизайн для балансировки нагрузки (на английском языке) (https://go.microsoft.com/fwlink/?linkid=122194&clcid=0x419) (на английском языке)

  • Корпоративный дизайн для использования системы DNS (на английском языке) (https://go.microsoft.com/fwlink/?linkid=122196&clcid=0x419) (на английском языке)

Доступность внутри фермы

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

Отказоустойчивость компонентов

В любой системе рекомендуется работать с поставщиками оборудования для закупки отказоустойчивого оборудования, подходящего для системы, включая RAID-массивы. Рекомендации можно найти в разделе Планирование производительности и мощности (Office SharePoint Server).

При планировании отказоустойчивости компонентов необходимо учитывать следующее:

• полная избыточность всех компонентов внутри сервера может быть невозможной или непрактичной. Для обеспечения дополнительной избыточности используйте дополнительные серверы;

• попробуйте обеспечить избыточность компонентов для роли сервера индексирования, поскольку роль сервера индексирования невозможно сделать избыточной;

• убедитесь в том, что на серверах имеется несколько блоков питания, подключенных к различным источникам питания для обеспечения максимальной избыточности.

Избыточность и переключение между ролями серверов внутри фермы в случае сбоя

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

Избыточность внутри фермы с одним сервером

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

Дополнительные сведения см. в разделе Планирование избыточности (Office SharePoint Server).

Стратегии доступности баз данных для одной фермы

Доступность базы данных внутри фермы может быть обеспечена путем использования кластеризации SQL Server или зеркалирования SQL Server с высоким уровнем доступности (синхронного зеркалирования).

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

Сервер Office SharePoint Server 2007 ссылается на кластер в целом, поэтому отработка отказа производится автоматически и полностью с точки зрения продуктов и технологий SharePoint.

Синхронное зеркалирование базы данных Зеркалирование базы данных обеспечивает поддержку доступности, направляя транзакции непосредственно с основной базы данных и основного сервера в зеркальную базу данных и на зеркальный сервер во всех случаях, когда буфер журнала транзакции основной базы данных записывается на диск. Рекомендуется использовать зеркалирование базы данных с высоким уровнем доступности, называемое также режимом высокой безопасности, с автоматической отработкой отказа. В зеркалировании базы данных с высоким уровнем доступности принимают участие три экземпляра серверов: основной, зеркальный и следящий. Благодаря следящему серверу обеспечивается автоматическое аварийное переключение SQL Server с основного сервера на зеркальный. Аварийное переключение с основной базы данных на зеркальную занимает обычно всего несколько секунд.

Каждая технология имеет свои преимущества и недостатки. Кластеризация проще в плане внедрения, но может быть более дорогостоящей. Зеркалирование SQL Server не поддерживается для баз данных Microsoft Office Project Server 2007.

В следующей таблице сравниваются отказоустойчивые кластеры и зеркалирование SQL Server с высоким уровнем доступности.

Дополнительные сведения об использовании кластеризации см. в статье Настройка доступности в единственной ферме с помощью кластеризации SQL Server.

Дополнительные сведения об использовании синхронного зеркалирования см. в статьях Настройка доступности в ферме с помощью зеркального отображения баз данных SQL Server и Технический документ. Использование зеркального отображения базы данных (Office SharePoint Server).

Избыточность и переключение между близко расположенными центрами обработки данных, настроенных как единая ферма ("вытянутая" ферма)

Некоторые предприятия имеют центры обработки данных, расположенные близко друг от друга и подключенных друг к другу с использованием высоко широкополосных соединений, чтобы их можно было настраивать как единую ферму. Это называется "вытянутой" фермой. Чтобы вытянутая ферма работала, должна быть задержка не менее 1 миллисекунды между сервером SQL и веб-сервером в одном направлении и полоса пропускания не менее 1 гигабит в секунду.

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

• Обратитесь к поставщику сети хранения данных, чтобы определить, можно ли использовать репликацию SAN или другой поддерживаемый механизм для обеспечения доступности среди центров данных, например сервера SQL, запущенного на территориально распределенных кластерах серверов. Убедитесь в том, что решение репликации SAN обеспечивает достаточный уровень параллелизма и согласованности транзакций.

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

• нескольких серверов запросов;

• нескольких серверов, на которых работает Служба вычислений Excel.

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

Еще одной точкой отказа в данном сценарии является сервер проектов. Запланируйте создание резервных копий и восстановление баз данных сервера проектов.

"Вытянутая" ферма

Доступность поиска внутри фермы

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

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

Если предприятию требуется быстрая применимость поиска и доступность, можно использовать один из следующих методов:

• Архитектура одной фермы с двумя одинаковыми поставщиками общих служб.

  Примечание

  Если бизнес нуждается в быстром восстановлении применимости и доступности поиска и используются профили, то профили резервных поставщиков общих служб не синхронизированы с профилями основных поставщиков общих служб — они будут находиться в том же состоянии, в котором находились при первоначальном импорте. Чтобы поддерживать синхронизацию профилей всех поставщиков общих служб, необходимо использовать обработчик репликации профиля пользователя, который включен в 32-разрядный набор средств администрирования SharePoint (на английском языке) (https://go.microsoft.com/fwlink/?linkid=119535&clcid=0x419) (на английском языке) и в 64-разрядный набор средств администрирования SharePoint (на английском языке) (https://go.microsoft.com/fwlink/?linkid=119536&clcid=0x419) (на английском языке). Дополнительные сведения см. в описании Модуль репликации профилей пользователей (Office SharePoint Server).

• Центральная родительская ферма, на которой содержится поставщик общих служб поиска и другие поставщики. Служба поиска на центральной ферме осуществляет обход контента на всех других фермах. Такую архитектуру можно использовать для поддержки одной или нескольких ферм.

Одна ферма с двумя поставщиками общих служб

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

Одна ферма с двумя поставщиками общих служб

Подобная топология имеет следующие ограничения:

• на каждом сервере запросов требуется двойное пространство для индексов;

• требуется ручное переключение веб-приложения для использования резервного поставщика общих служб (для этого можно использовать сценарий);

• размер собрания документов, который можно обойти, уменьшается вдвое;

• По умолчанию, если профили включены, то профили на ферме резервных поставщиков общих служб не синхронизированы с профилями основных поставщиков общих служб. Они будут находиться в состоянии, в котором они были при первоначальном импорте. Чтобы поддерживать синхронизацию профилей всех поставщиков общих служб, необходимо использовать обработчик репликации профиля пользователя, который включен в 32-разрядный набор средств администрирования SharePoint (на английском языке) (https://go.microsoft.com/fwlink/?linkid=119535&clcid=0x419) (на английском языке) и в 64-разрядный набор средств администрирования SharePoint (на английском языке) (https://go.microsoft.com/fwlink/?linkid=119536&clcid=0x419) (на английском языке). Дополнительные сведения см. в разделе Модуль репликации профилей пользователей (Office SharePoint Server).

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

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

Централизованные фермы поставщиков общих служб

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

Данная топология обладает следующими преимуществами:

• управление поставщиками общих службы выполняется централизованно;

• сбой фермы не требует повторного обхода;

Централизованные фермы поставщиков общих служб

Подобная топология имеет следующие ограничения:

• для обхода контента в глобальной сети используется полоса пропускания;

• поддержание актуальных индексов может быть затруднено в средах с большими объемами данных и частыми изменениями;

• на скорость обработки запросов может влиять производительность каналов связи глобальной сети;

• По умолчанию, если профили включены, то профили на ферме резервных поставщиков общих служб не синхронизированы с профилями основных поставщиков общих служб. Они будут находиться в состоянии, в котором они были при первоначальном импорте. Чтобы поддерживать синхронизацию профилей всех поставщиков общих служб, необходимо использовать обработчик репликации профиля пользователя, который включен в 32-разрядный набор средств администрирования SharePoint (на английском языке) (https://go.microsoft.com/fwlink/?linkid=119535&clcid=0x419) (на английском языке) и в 64-разрядный набор средств администрирования SharePoint (на английском языке) (https://go.microsoft.com/fwlink/?linkid=119536&clcid=0x419) (на английском языке). Дополнительные сведения см. в разделе Модуль репликации профилей пользователей (Office SharePoint Server).

Избыточность и отказоустойчивость центров обработки данных с несколькими фермами

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

• На резервной ферме должны быть отдельная база данных настройки и база данных контента центра администрирования.

  Примечание

  Если для основной фермы настроено альтернативное сопоставление доступа, очень важно настроить их точно также на резервной ферме.

• Все настройки необходимо развертывать на обеих фермах.

• Исправления необходимо устанавливать отдельно на обеих фермах.

• Возможно успешное зеркалирование только баз данных контента или передача журнала на резервную ферму.

• Зеркальные базы данных или базы данных с доставкой журнала необходимо настроить на использование модели полного восстановления.

• Можно создавать резервные копии баз данных поставщиков общих служб, включая базы данных Office Project 2007, и восстанавливать их в резервной ферме.

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

Такая топология может повторяться среди многих центров обработки данных, если настроить передачу журнала сервера SQL на один или несколько дополнительных серверов обработки данных.

Основная и резервная фермы до отработки отказа

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

Доступность поиска между фермами

Поиск требует полной синхронизации между базой данных поиска, базой данных поставщика общих служб и индексом. В связи с этим требованием данные поиска нельзя реплицировать между фермами, используя механизм асинхронной репликации (асинхронное зеркалирование базы данных, передача журнала или асинхронная репликация SAN).

Чтобы обеспечить функцию поиска на резервной ферме, необходимо использовать один из следующих методов:

• Восстановление резервной копии поставщика общих служб поиска на резервной ферме.

• Использование централизованной родительской фермы, на которой находятся поставщики общих служб поиска и другие поставщики общих служб. Служба поиска центральной фермы обходит контент всех других ферм.

Сводка

Внимательно просмотрите требования по доступности. Чем выше уровень доступности и больше систем необходимо защитить, тем более сложным и дорогостоящим, вероятнее всего, будет решение.

Расходы на обеспечение доступности должны определяться на основе бизнес-потребностей. Не для всех решений в организации может требоваться одинаковый уровень доступности. Можно предложить различные уровни доступности различных сайтов и различных служб (например, для служб поиска и бизнес-аналитики) или других ферм.

Благодарности

Издательская группа по серверу Microsoft Office SharePoint Server благодарит следующих технических редакторов настоящего документа:

• Билла Байера, Интерактивные службы Microsoft, Hosted SharePoint, технологический архитектор

• Джеймса Петровски, Консультационная служба корпорации Майкрософт, старший консультант

• Стив Пешка, Консультационная служба корпорации Майкрософт, старший архитектор IW

• Дэна Винтера, Служба поддержки клиентов корпорации Майкрософт, инженер по эскалации

• Шона Ливингтона, Продукты и технологии Microsoft SharePoint, руководитель программы

• Майка Ватсона, технологический архитектор

• Тодда Картера, Microsoft Premier Field Engineering, старший инженер

• Майка Пламли, Microsoft Office Project Server, разработчик

• Кристофа Фиссингера, Microsoft Office Project, старший технический руководитель по проектам

• Сида Шаха, Microsoft Search, руководитель программы

• Люка Бандинелли, Продукты и технологии Microsoft SharePoint, руководитель программы

Загрузить эту книгу

Для упрощения чтения и печати эта тема включена в следующую загружаемую книгу:

• Планирование и архитектура для Office SharePoint Server 2007, часть 2

• Планирование и настройка доступности внутри фермы Office SharePoint Server 2007 (на английском языке)

  См. полный список доступных книг на сайте Загружаемые книги для Office SharePoint Server 2007.

См. также

Понятия

Настройка высокой степени доступности (Office SharePoint Server)