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

Применимо к: SharePoint Foundation 2010, SharePoint Server 2010

Последнее изменение раздела: 2016-11-30

В этой статье описываются ключевые решения при выборе стратегий обеспечения доступности для среды Microsoft SharePoint Server 2010.

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

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

Содержание

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

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

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

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

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

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

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

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

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

% времени работоспособности/год = 100 - (8760 - общее число часов простоя в год)/8760

% времени работоспособности/месяц = 100 - ((24 x число дней в месяце) - общее число часов простоя в данном календарном месяце)/(24 x число дней в месяце)

% времени работоспособности/неделя = 100 - (168 - общее число часов простоя за данную неделю)/168

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

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

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

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

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

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

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

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

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

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

При положительном ответе на любой из этих вопросов следует инвестировать в решение по обеспечению доступности.

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

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

• Повышение отказоустойчивости аппаратных компонентов сервера.

• Увеличение избыточности ролей серверов в ферме.

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

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

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

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

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

Избыточность в пределах фермы

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

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

Доступность в пределах фермы серверов

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

Стратегии доступности баз данных

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

Отказоустойчивость кластера SQL Server

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

SharePoint Server ссылается на кластер как на единое целое, поэтому отработка отказа выполняется автоматически и незаметно для SharePoint Server.

Подробные сведения о кластере отработки отказа см. в статье, посвященной началу работы с кластерами отработки отказа SQL Server 2008 (https://go.microsoft.com/fwlink/?linkid=102837&clcid=0x419), и в статье Configure availability by using SQL Server clustering (SharePoint Server 2010).

Зеркальное отображение SQL Server с высоким уровнем доступности

Зеркальное отображение базы данных — это технология SQL Server, которая может обеспечить избыточность базы данных отдельно для каждой базы данных. При зеркальном отображении базы данных транзакции отправляются из основной базы данных и с соответствующего сервера прямо в зеркальную базу данных и на соответствующий сервер, когда буфер журнала транзакций основной базы данных записывается на диск. SQL Server Enterprise Edition предоставляет дополнительные функциональные возможности, улучшающие эффективность зеркального отображения базы данных. Дополнительные сведения см. в статье Продукты SQL Server 2008 R2 и SharePoint 2010: эффективная совместная работа (технический документ) (SharePoint Server 2010).

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

Отличие от предыдущих версий состоит в том, что SharePoint Server поддерживает зеркальное отображение. После настройки зеркального экземпляра базы данных SQL Server воспользуйтесь центром администрирования SharePoint или командлетами Windows PowerShell для указания расположения зеркального сервера баз данных базам данных конфигурации, контента или приложения-службы. Настройка расположения базы данных отработки отказа добавляет в строку подключения параметр, используемый SharePoint Server для подключения к SQL Server. При возникновении события тайм-аута SQL Server происходит следующее:

1. Следящий сервер, настроенный для зеркального отображения SQL Server, автоматически меняет местами роли основной и зеркальной баз данных.

2. SharePoint Server пытается автоматически связаться с сервером, определенным как база данных отработки отказа.

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

Общие сведения о зеркальном отображении базы данных см. в статье, посвященной зеркальному отображению баз данных (https://go.microsoft.com/fwlink/?linkid=180597&clcid=0x419).

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

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

Стратегии избыточности для приложений-служб

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

Приложения-службы, хранящие данные вне базы данных

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

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

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

Следующие приложения-службы хранят данные вне базы данных.

• Службы Access

• Приложение-служба Excel

Приложения-службы, хранящие данные в базах данных

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

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

2. Настройте кластеризацию или зеркальное отображение SQL Server для защиты данных.

Следующие приложения-службы хранят данные в базах данных.

• Приложение-служба поиска, включая следующие базы данных:

  • Администрирование поиска

  • Обход контента

  • Свойство

    Примечание

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

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

  • Профили

  • Социальная

  • Синхронизация

    Примечание

    Зеркальное отображение базы данных синхронизации не поддерживается.

• Приложение Служба подключения к бизнес-данным

• Приложение-служба реестра приложений

  Не рекомендуется использовать зеркальное отображение для базы данных реестра приложений, так как она используется только при обновлении каталога бизнес-данных Microsoft Office SharePoint Server 2007 до SharePoint Server 2010.

• Приложение-служба сбора данных об использовании и исправности

  Примечание

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

• Приложение-служба управляемых метаданных

• Приложение-служба безопасного хранения

• Приложение-служба состояний

• Приложение-служба веб-аналитики, включая следующие базы данных:

  • База данных отчетов

  • Промежуточная

    Примечание

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

• Приложение-служба Word Automation Services

• Служба параметров подписки Microsoft SharePoint Foundation

• PerformancePoint Services

Стратегии избыточности поиска в пределах фермы

Только сервер

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

Приложение службы поиска с избыточностью

• Сервер запросов. На сервере запросов размещаются компоненты запросов и разделы индекса.

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

    Примечание

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

  • Разделы индексов — это группы компонентов запросов, каждый из которых содержит подмножество полнотекстового индекса и возвращает результаты поиска. Каждый раздел индекса связан с конкретной базой данных свойств, содержащей метаданные, связанные с конкретным набором обходимого контента. Определить, какие серверы фермы будут обрабатывать запросы, можно, создавая компонент запроса на этом сервере. Если нужно сбалансировать нагрузку обработки запросов среди нескольких серверов фермы, добавьте компоненты запросов в раздел индекса и свяжите их с серверами, которые должны обрабатывать запросы. Дополнительные сведения см. в статье Add or remove a query component. Избыточность раздела индекса можно обеспечить, добавляя в раздел индекса зеркальные компоненты запросов и размещая их на различных серверах запросов.

• Сервер обхода контента. На сервере обхода контента размещаются компоненты обхода и компонент администрирования поиска.

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

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

• Серверы баз данных. На серверах баз данных размещаются базы данных обхода контента, базы данных свойств, база данных администрирования поиска и другие базы данных SharePoint Server 2010.

  • База данных обхода контента

    Базы данных обхода контента содержат данные, связанные с расположением источников контента, расписаниями обходов и другими сведениями, специфическими для операций обхода контента, связанных с конкретным приложением службы поиска. Нагрузку на базы данных можно распределить, добавляя базу данных обходов на другие компьютеры, на которых выполняется SQL Server. Базы данных обходов контента связаны с компонентами обходов и могут быть назначены конкретным узлам с помощью создания правил распределения узлов. Дополнительные сведения о компонентах обхода контента см. в статье Add or remove a crawl component (SharePoint Server 2010). Дополнительные сведения о правилах распределения узлов см. в статье Add or remove a host distribution rule. Базы данных обхода контента являются избыточными, если для них настроено зеркальное отображение или они развернуты в кластере отработки отказа SQL Server.

  • База данных свойств

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

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

  • База данных администрирования поиска

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

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

Дополнительные сведения об избыточности поиска см. в статье Manage search topology (SharePoint Server 2010).

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

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

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

"Растянутая" ферма показана на следующем рисунке.

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