Управление емкостью и высокой доступностью в виртуальной среде (SharePoint Server 2010)

  • Статья

 

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

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

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

Содержание:

Обзор виртуализации

В Технология Windows Server 2008 Hyper-V и Microsoft Hyper-V Server 2008 реализована виртуализация сервера на базе аппаратного обеспечения (аппаратная виртуализация), в отличие от программной виртуализации. Низкоуровневая оболочка Hyper-V, в отличие от технологий программной виртуализации, обеспечивает возможность прямого взаимодействия с аппаратными компонентами физического сервера, что дает ощутимый выигрыш в производительности. Дополнительные сведения об архитектуре Hyper-V см. в статьях Представляем Hyper-V в Windows Server 2008 (https://go.microsoft.com/fwlink/?linkid=188006&clcid=0x419) и Мониторинг производительности технологии Hyper-V (Возможно, на английском языке) (https://go.microsoft.com/fwlink/?linkid=187746&clcid=0x419) (Возможно, на английском языке).

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

Программы и приложения столь же разнообразны, как и аппаратное обеспечение. Некоторые программы интенсивно используют ЦП, другие — память, третьи — жесткий диск. SharePoint Server, как и сервер IIS и SQL Server 2008, предъявляет собственные требования к емкости. Повторимся, важнейшую роль играет комплексное тестирование.

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

Управление емкостью

Процесс управления емкостью является логическим продолжением процесса планирования загрузки в рамках циклического подхода, подразумевающего непрерывные мониторинг и оптимизацию емкости развертывания SharePoint Server 2010 в соответствии с изменяющимися условиями и требованиями. Такой подход может применяться ко всем фермам SharePoint Server, в том числе и к полностью или частично виртуализованным. Обзор процесса управления емкостью см. в статье Capacity management and sizing for SharePoint Server 2010. Дополнительные материалы, посвященные управлению емкостью, можно найти на странице Управление емкостью в SharePoint Server 2010 (Возможно, на английском языке) (https://go.microsoft.com/fwlink/?linkid=194748&clcid=0x419) (Возможно, на английском языке) центра ресурсов.

Емкость и масштабирование сервера виртуализации

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

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

Примечание

При комплексном планировании и тестировании изменения в архитектуре и конфигурациях серверов могут потребоваться только в случае значительного и непрогнозируемого увеличения нагрузки на ферму или в связи с добавлением новых компонентов в решение SharePoint Server.

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

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

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

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

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

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

Важно!

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

Рекомендуем ознакомиться со сведениями на странице Вопросы и ответы по производительности Hyper-V, выпуск 2 (Возможно, на английском языке) (https://go.microsoft.com/fwlink/?linkid=187745&clcid=0x419) (Возможно, на английском языке), которые обновлены с использованием данных по емкости и производительности для Windows Server 2008 R2 и Windows Server 2008 с пакетом обновления 2 (SP2). На этой странице вопросов и ответов представлены ответы на распространенные вопросы по технологии Hyper-V, даны рекомендации и приведены ссылки на подробные статьи, которые можно использовать для определения собственных контрольных данных для узла виртуализации, виртуальных машин и сетей Windows.

Также рекомендуем ознакомиться со следующими публикациями, посвященными счетчикам производительности в Hyper-V:

Создание и оптимизация архитектур

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

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

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

  2. Анализ архитектур. Определение и получение любых сведений, которые отсутствуют или могут помочь усовершенствовать архитектуру развертываемой среды.

  3. Оптимизация архитектур. Оптимизация архитектуры на основе данных, собранных на шаге 2.

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

Создание архитектуры

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

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

  • Укажите индивидуальные требования к конфигурации каждой виртуальной машины (объем дискового пространства, память и число процессоров). Эти данные основываются на требованиях к емкости SharePoint Server.

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

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

  • Определите общие требования к сети и системам хранения данных.

  • Предусмотрите необходимость расширения с использованием узлов виртуализации и виртуальных машин (вертикальное или горизонтальное масштабирование).

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

Анализ архитектур

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

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

Важно!

Сервер виртуализации и масштабирование виртуальной машины описываются на этом рисунке исключительно в качестве примера.

Рис. 1. Предварительная архитектура

Топология виртуальной фермы SharePoint Server 2010

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

Анализ узла виртуализации

В следующих таблицах (HOST-1 и HOST-2) представлен анализ каждого из узлов виртуализации по критериям памяти, процессоров и масштабируемости. После анализа хоста выполняется анализ архитектуры.

HOST-1

Критерии Анализ

Память

После выделения 2 ГБ ОЗУ для операционной системы и выполнения требований к ОЗУ остается примерно 2 ГБ ОЗУ для будущего использования.

Процессоры

Соотношение между логическими и виртуальными процессорами составляет 8:10 (1:1,25), что означает незначительную переподписку ЦП и не приведет к возникновению проблем в тестовой среде.

Важно!

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

Масштабируемость

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

HOST-2

Критерии Анализ

Память

После выделения 2 ГБ ОЗУ для операционной системы и выполнения требований к ОЗУ остается примерно 6 ГБ ОЗУ для будущего использования.

Процессоры

Соотношение между логическими и виртуальными процессорами составляет 8:8 (1:1), что соответствует принятым рекомендациям.

Масштабируемость

В этом случае присутствует достаточно памяти для увеличения объема памяти, выделяемого для виртуальных машин. В этом случае достаточно емкости для добавления новой виртуальной машины с двумя процессорами и 4 ГБ ОЗУ. Это означает, что будет присутствовать незначительная переподписка ЦП узла виртуализации (8:10), но, как и в случае с узлом HOST-1, это не приведет к возникновению проблем в тестовой среде.

Анализ архитектуры

В примере архитектуры обычно демонстрируется степень высокой доступности для серверов фермы. Рассмотрим пример, в котором используется три интерфейсных веб-сервера, распределенных между узлами HOST-1 и HOST-2, а также кластеризованные или зеркалированные серверы баз данных, которые размещаются на отдельных узлах виртуализации или физических серверах. Высокая доступность на уровне узла виртуализации не реализована в рамках архитектуры, и отсутствует необходимая информация. Перед анализом архитектуры требуется собрать следующие сведения:

  • Размер базы данных

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

  • Подсистема хранения

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

  • Требования к сети

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

  • Конфигурации виртуальных жестких дисков

    Также требуется определить используемые конфигурации жестких дисков Hyper-V (например, фиксированный размер или транзитная). Дополнительные сведения см. в статьях Планирование дисков и хранилища (https://go.microsoft.com/fwlink/?linkid=188007&clcid=0x419) и в документе Производительность виртуальных жестких дисков: Windows Server 2008 / Windows Server 2008 R2 / Windows 7 (Возможно, на английском языке) (https://go.microsoft.com/fwlink/?linkid=186519&clcid=0x419) (Возможно, на английском языке).

По завершении анализа архитектуры выполняется ее оптимизация.

Оптимизация архитектуры

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

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

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

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

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

Рис. 2. Оптимизированная архитектура

Пересмотр виртуальной архитектуры

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

  • Примерный размер базы данных контента составляет 1 ТБ.

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

  • В качестве серверов баз данных в ферме используются физические серверы, которые могут поддерживать высокий уровень доступности за счет кластеризации или зеркалирования. Каждый сервер имеет 8 ядер, 16 ГБ ОЗУ и использует локальные диски для минимальной задержки.

Анализ узла виртуализации

В следующих таблицах (оптимизированные узлы HOST-1 и HOST-2) представлен анализ каждого из узлов виртуализации по критериям памяти, процессоров и масштабируемости. После анализа хоста выполняется анализ архитектуры.

Оптимизированный узел HOST-1

Критерии Анализ

Память

После выделения 2 ГБ ОЗУ для операционной системы и выполнения требований к ОЗУ остается примерно 2 ГБ ОЗУ для будущего использования.

Процессоры

Соотношение между логическими и виртуальными процессорами составляет 8:10 (1:1,25), что соответствует незначительной переподписке.

Масштабируемость

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

Оптимизированный узел HOST-2

Критерии Анализ

Память

После выделения 2 ГБ ОЗУ для операционной системы и выполнения требований к ОЗУ остается примерно 4 ГБ ОЗУ для будущего использования.

Процессоры

Соотношение между логическими и виртуальными процессорами составляет 8:12 (1:1,5), что соответствует переподписке на 50 процентов.

Масштабируемость

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

Анализ проекта

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

    • Диск C (50 ГБ) для установки Windows

    • Диск D (50 ГБ) для файлов SharePoint Server 2010

    • Диск E (300 ГБ) для веб-контента и файлов журналов

  • Конфигурация каждого интерфейсного веб-сервера включает в себя четыре виртуальных процессора и 8 ГБ ОЗУ. Такая конфигурация является минимально рекомендуемой для рабочей среды.

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

  • Два сервера приложений (App-1, App-2) обеспечивают высокий уровень доступности. На сервер App-1 размещается центр администрирования, компонент обхода контента для поиска, а также пассивный индекс для этого компонента. Число процессоров и объем памяти определены на основе предполагаемого размера базы данных контента.

    Сервер App-2 используется в качестве выделенного сервера поисковых запросов. На нем также размещается копия центра администрирования. Число процессоров и объем памяти определены на основе предполагаемого размера базы данных контента.

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

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

    Примечание

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

  • С точки зрения сети оба узла виртуализации настроены с двумя отдельными физическими сетевыми адаптерами с пропускной способностью 1 Гбит/с. Такой подход является рекомендуемым, поскольку в этом случае обеспечивается разделение трафика узла виртуализации и виртуальной машины, что позволяет повысить производительность и обеспечить определенный уровень резервирования сетевых адаптеров.

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

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

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

  • Увеличение емкости узла виртуализации с применением 16-ядерного компьютера с 48 или 64 ГБ ОЗУ.

  • Добавление одного или нескольких узлов виртуализации.

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

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

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

Совет

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

Следующие возможности позволят достичь повышения производительности:

  • Развертывание или приобретение серверов с процессорами с поддержкой технологии преобразования адресов второго уровня (SLAT). В процессорах Intel эта возможность называется вложенными таблицами страниц и доступна в процессорах серии Nehalem 55xx. В процессорах AMD эта возможность называется расширенными таблицами страниц (EPT).

  • Развертывание или приобретение серверов с поддержкой возможности выборочной приостановки ядра ЦП, благодаря которой технология Hyper-V может использовать минимально необходимое число процессоров, соответствующее текущей нагрузке.

  • Анализ возможности применения технологий переноса нагрузки с протокола TCP Chimney, запросов виртуальных машин (VMQ) и пакетов крупного размера. Эти возможности позволяют повысить производительность сети и снизить нагрузку на ЦП, что приводит к увеличению общей емкости системы.

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

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

    Важно!

    Объединение адаптеров реализуется с использованием стороннего решения и поддерживается только его поставщиком. Дополнительные сведения см. в статье Поддержка политики объединения сетевых карт для технологии Hyper-V корпорации Майкрософт (Возможно, на английском языке) (https://go.microsoft.com/fwlink/?linkid=194749&clcid=0x419) (Возможно, на английском языке).

Чтобы обеспечить высокий уровень доступности виртуальной среды, рекомендуется реализовать отказоустойчивую кластеризацию Windows Server 2008 R2 и динамическую миграцию Hyper-V следующим образом:

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

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

Дополнительные сведения см. в статьях Hyper-V: использование Hyper-V и отказоустойчивой кластеризации (Возможно, на английском языке) (https://go.microsoft.com/fwlink/?linkid=187967&clcid=0x419) (Возможно, на английском языке) и Hyper-V: использование динамической миграции с общими томами кластера в Windows Server 2008 R2 (https://go.microsoft.com/fwlink/?linkid=188009&clcid=0x419).