- •Введение в архитектуру ферм серверов
- •Что такое ферма серверов?
- •Типичные сферы применения
- •Масштабирование ферм серверов
- •Узкие места, связанные с оборудованием
- •Балансировка сетевой нагрузки для обеспечения масштабируемости
- •Достоинства и недостатки вертикального и горизонтального масштабирования
- •Рост доступности при использовании ферм серверов
- •Стоимость обеспечения доступности
- •Балансировка нагрузки для обеспечения доступности
- •Избыточность
- •Доступность базы данных
- •Повышение гибкости и управляемости ферм серверов
- •Добавочное расширение
- •Контроль обновлений
- •Делегированное администрирование
- •Дискуссия. Фермы серверов на предприятии
- •Вопросы для дискуссии
- •Топология фермы серверов
- •Роли серверов Windows SharePoint Services 3.0
- •Внешние веб-серверы
- •Серверы баз данных
- •Серверы поиска
- •Роли серверов Office SharePoint Server 2007
- •Серверы индексирования
- •Серверы запросов
- •Другие серверы приложений
- •Архитектура поставщика общих служб
- •Поставщики общих служб и веб-приложения
- •Услуги, предоставляемые поставщиком общих служб
- •Требования к внешним веб-серверам
- •Требования к веб-серверам
- •Требования к серверу баз данных Требования к аппаратному и программному обеспечению
- •Raid конфигурация
- •Требования к серверу приложений Серверы приложений Windows SharePoint Services
- •Серверы приложений Office SharePoint Server
- •Типичные схемы серверов для малых развертываний
- •Изолированная установка
- •Небольшая ферма серверов
- •Типичные схемы серверов для средних развертываний Средняя ферма серверов — Windows SharePoint Services 3.0
- •Средняя ферма серверов — Office SharePoint Server 2007
- •Типичные схемы серверов для больших развертываний Большая ферма серверов — Windows SharePoint Services 3.0
- •Большая ферма серверов — Office SharePoint Server 2007
- •Несколько поставщиков общих служб в ферме Почему используют нескольких поставщиков общих служб?
- •Создание нескольких поставщиков общих служб
- •Ассоциирование поставщика общих служб с веб-приложением
- •► Чтобы ассоциировать поставщика общих служб с веб-приложением
- •Общий доступ к поставщикам общих служб между фермами Причины, по которым необходим общий доступ к поставщику общих служб
- •Настройка системы межферменных общих служб
- •► Процедура обеспечения общего доступа к поставщику общих служб между фермами
- •Развертывание ферм серверов
- •Подготовка серверов
- •Серверы баз данных
- •Внешние веб-серверы и серверы приложений
- •Порядок установки
- •Рекомендованный порядок установки для Office SharePoint Server
- •Рекомендованный порядок установки для Office SharePoint Services
- •Выполнение развертывания Установка первого сервера
- •Добавление серверов в ферму
- •Перемещение веб-узла центра администрирования
- •► Процедура перемещения веб-узла центра администрирования
- •Установка с базами данных, созданными администраторами
- •Установки со сценариями
- •Типичные сценарии
- •Изменение файла конфигурации
- •Защита содержимого с помощью Microsoft Forefront
- •Опасности, характерные для продуктов и технологий SharePoint
- •Концепция «защита в глубину»
- •Развертывание Forefront Security для SharePoint
- •Управление Forefront Security для SharePoint
- •► Процедура применения обновлений к серверам
Избыточность
Если развертывание требует высокой степени доступности, то каждая возможная роль сервера в используемом приложении Office SharePoint Server должна быть запущена как минимум на двух серверах. Существуют некоторые роли, которые могут быть или не быть избыточными в SharePoint, например сервер индексирования.
Так, чтобы установить двухуровневое решение с уровнем внешнего веб-сервера и базы данных, понадобится ферма, в которой содержится не менее четырех серверов: два веб-сервера со сбалансированной нагрузкой и два кластерных или дублированных сервера базы данных. Внешние веб-серверы обычно также предоставляют службу запросов. Кроме того, не следует открывать доступ к Интернету веб-серверу или серверу приложений, на котором находится основной веб-узел администрирования. Для более широких развертываний можно добавить пятый сервер, исполняющий роль сервера приложений (в данном сценарии — это сервер, содержащий веб-узел администрирования, поставщиков общих служб и, возможно, роль сервера индексирования). Помните, что при планировании нагрузки всегда необходимо предусмотреть и сформировать избыточность.
Доступность базы данных
Отказоустойчивость кластеров — наиболее распространенный способ обеспечения высокой степени доступности базы данных для конкретного решения. Базу данных обычно устанавливают на общий дисковый массив, к которому могут иметь доступ два и более кластерных сервера баз данных. Клиенты подключаются к кластеру баз данных как к одному серверу. Можно настроить кластер так, что если один из серверов баз данных выдаст ошибку, все новые запросы будут распределены между остальными серверами. Однако при этом общий дисковый массив остается одной точкой сбоя.
SQL Server 2005 предоставляет альтернативный способ сохранения доступности базы данных в виде зеркального отображения базы данных. Зеркальное отображение базы данных осуществляется на уровне каждой базы данных и используется журналами транзакций SQL Server. Когда записи добавляются в журнал транзакций, эти записи посылаются на дублированный сервер. Дублированный сервер добавляет записи в свой журнал транзакций и исполняет команды, поддерживая, таким образом, дублированный сервер в синхронизации с сервером приложений почти в реальном времени.
Примечание. Зеркальное отображение базы данных можно использовать в сочетании с другими технологиями обеспечения высокого уровня доступности, например доставкой журнала транзакций. Для получения более подробной информации об использовании зеркального отображения базы данных с продуктами и технологиями SharePoint, см. документ Backup, Restore, and Disaster Recovery for Microsoft SharePoint Products and Technologies (Резервное копирование, восстановление и аварийное восстановление для продуктов и технологий SharePoint).
Повышение гибкости и управляемости ферм серверов
Если планируется развертывание масштабируемого решения, следует учитывать возможности управления при расширении в будущем. Необходимо также учитывать, как такое расширение повлияет на управляемость вашим решением. Подход к расширению на основе вертикального масштабирования и модель централизованного управления с ростом пользовательской базы и системных требований могут ограничить гибкость и управляемость используемых решений.