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

Обновлено: 2009-03-11

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

Что такое доступность?

Доступность характеризует степень готовности к работе среды продуктов и технологий 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

Что не входит в понятие доступности

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

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

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

• архивирование данных для коммерческих целей и соблюдения юридических или нормативных положений;

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

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

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

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

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

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

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

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

Затраты на доступность

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

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

• дополнительная сложность эксплуатации.

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

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

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

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

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

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

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

• В продуктах и технологиях SharePoint не используется зеркальное отображение SQL Server. Хотя рекомендуется использовать зеркальное отображение SQL Server в качестве методики обеспечения доступности, для этого требуется дополнительная автоматизация.

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

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

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

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

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

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

В случае утвердительного ответа на любой из этих вопросов организации требуется решение по обеспечению доступности.

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

Существует множество вариантов подхода к улучшению доступности, в том числе:

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

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

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

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

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

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

• версии SQL Server и все обновления;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сравнение стратегий обеспечения доступности для отдельной фермы: отказоустойчивость кластеров SQL Server и зеркальное отображение SQL Server с высоким уровнем доступности

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

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

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

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

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

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

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

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

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

"Растянутая" ферма

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

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

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

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

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

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

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

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

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

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

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

Примечание:
Зеркальное отображение SQL Server может использоваться только с одним зеркальным сервером, однако можно передать журнал на несколько дополнительных серверов.

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

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

Сервер или роль сервера	Предпочтительная основная стратегия обеспечения избыточности между фермами
SQL Server	Асинхронное зеркальное отображение базы данных SQL Server, доставка журналов SQL Server или другой асинхронный механизм репликации. Примечание: Не может использоваться для баз данных SSP, в которых хранятся данные поиска.
Интерфейсные веб-серверы	Выполните развертывание (в том числе и настроек) на обеих фермах.
Веб-сервер для средних ферм серверов (службы веб-приложений и запросов поиска )	Выполните развертывание на обеих фермах.
Индексирование поиска	Выполните развертывание на обеих фермах. Восстановите резервную копию с исходной фермы для переноса на резервную ферму.
Служба вычислений Excel	Выполните развертывание на обеих фермах. Если поставщик общих служб не содержит данных поиска, для переноса данных на резервную ферму можно использовать асинхронное зеркальное отображение базы данных, доставку журналов сервера SQL или другой механизм асинхронной репликации. Если поставщик общих служб также содержит данные поиска, необходимо восстановить резервную копию с исходной фермы для переноса.
Приложение Project	Развертывание на обеих фермах. Восстановите резервную копию с исходной фермы для переноса на резервную ферму.

Асинхронная репликация и поиск

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

Примечание:
Если поставщик общих служб не выполняет службу поиска или Project, можно использовать для переноса данных механизм асинхронной репликации.

Доступность поиска после сбоя

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

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

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

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

• Билла Баэра (Bill Baer), Microsoft Online Services, Hosted SharePoint (архитектор по технологиям)

• Джеймса Петроски (James Petrosky), Microsoft Consulting Services (старший консультант)

• Стива Пешка (Steve Peschka), Microsoft Consulting Services (старший архитектор IW)

• Дэна Винтера (Dan Winter), Microsoft Customer Support Services (инженер службы поддержки)

• Шона Ливингстона (Sean Livingston), Microsoft SharePoint Products and Technologies (руководитель программы)

• Майка Уотсона (Mike Watson) (архитектор по технологиям)

• Тодда Картера (Todd Carter), Microsoft Premier Field Engineering (ведущий инженер службы поддержки)

• Майка Пламли (Mike Plumley), Microsoft Office Project Server (автор)

• Кристофа Фиссенже (Christophe Fiessinger), Microsoft Office Project (старший технический менеджер продукта)

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

• Луку Бандинелли (Luca Bandinelli), Microsoft SharePoint Products and Technologies (руководитель программы)