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

В этой статье рассматриваются общие вопросы доступности в среде продуктов и технологий SharePoint, связанные с этим затраты и проблемы, а также стратегии и решения, которые можно использовать в этой среде. Сведения, изложенные в этой статье, будут полезны, если на ферме запущены службы Windows SharePoint Services 3.0 или установлена среда с высоким уровнем доступности Microsoft Office SharePoint Server 2007, Microsoft Office Forms Server 2007 или Microsoft Search Server 2008. Можно также загрузить и напечатать документ "Модель доступности 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

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

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

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

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

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

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

Кроме того, доступность не затрагивает управление непрерывностью бизнеса (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, и базовые стратегии избыточности, которые могут применяться для каждого сервера в ферме.

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

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

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

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

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

• В этом сценарии можно обеспечить избыточность баз данных с помощью синхронного зеркального отображения. В рамках растянутой фермы можно создать зеркальное отображение базы данных конфигурации и базы данных контента. Подробное описание использования растянутой фермы в одной компании см. в статье White paper: Case Study of High Availability for SharePoint using Database Mirroring.

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

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

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

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

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

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

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

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

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

  Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• вдвое сокращается объем возможного контента для обхода;

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

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

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

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

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

Преимущества данной топологии:

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

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

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

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

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

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

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

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

Сводка

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

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

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

Отдел публикации контента Microsoft Office SharePoint Server благодарит следующих технических редакторов этой статьи:

• Билл Байер, Microsoft Online Services, Hosted SharePoint, разработчик архитектуры

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

• Стив Пешка, Microsoft Consulting Services, ведущий разработчик-консультант

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

• Сеан Ливингстон, Microsoft SharePoint Products and Technologies, программный менеджер

• Майк Ватсон, разработчик архитектуры

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

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

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

• Сид Шах, Microsoft Search, программный менеджер

• Лука Бандинелли, Microsoft SharePoint Products and Technologies, программный менеджер