Партнерка на США и Канаду по недвижимости, выплаты в крипто

  • 30% recurring commission
  • Выплаты в USDT
  • Вывод каждую неделю
  • Комиссия до 5 лет за каждого referral

Четыре гостевых виртуальных машины, работающие одновременно, с перегруженными ресурсами ЦП

В сценарии с перегруженными процессорами для параллельной работы было настроено четыре гостевых виртуальных машины. Каждая виртуальная машина имела по четыре логических процессора, 14 ГБ ОЗУ, 12 ГБ из которых использовались SQL Server. Все четыре виртуальных машины имели одинаковые подсистемы хранения.

На рисунке 16 показаны результаты масштабируемости по мере роста рабочей нагрузки. График по мере роста рабочей нагрузки довольно плоский, он затухает в районе 90%. Работа четырех виртуальных машин, каждая из которых имела по четыре виртуальных процессора, привела к перегрузке ЦП: ресурсы 16 виртуальных процессоров при наличии только 8 физических ядер процессора стали ограничиваться ЦП.

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

Рисунок 20. Масштабируемость четырех виртуальных машин, работающих одновременно, с перегруженным ЦП

Сравнение параметров консолидации

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

НЕ нашли? Не то? Что вы ищете?

Таблица 6. Параметры консолидации

Несколько экземпляров SQL Server

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

Изоляция

Общий экземпляр Windows

Выделенный экземпляр Windows

Ресурсы ЦП

Кол-во процессоров, видимое экземпляром Windows

Максимум

    Windows 2008 — до 4 виртуальных процессоров Windows 2003 — до 2 виртуальных процессоров

Память

Лимит сервера

гибкий (max server memory)

Статически выделенный виртуальной машине

    Только изменения в автономном режиме Перегружать ресурсы памяти невозможно

Лимит в 64 ГБ на виртуальную машину

Лимит в 2 терабайта на базовый компьютер

Хранилище

Файлы данных SQL Server со стандартными параметрами хранилища

Файлы данных SQL Server с использованием дисков прямого доступа или виртуальных жестких дисков, выделенных виртуальной машине

Управление ресурсами

WSRM (уровень процесса)

Гостевая виртуальная машина Hyper-V

Кол-во экземпляров

50

Зависит от физических ресурсов компьютера

Поддержка

Применяются обычные правила

SQL Server 2008 и SQL Server 2005

Высокий уровень доступности

Применяются обычные правила

Кластеризация гостей поддерживается

Зеркальное отображение базы данных, доставка журналов (поддерживается)


Заключение

С точки зрения производительности, использование Hyper-V — это хороший вариант для сценариев консолидации SQL Server. Общая производительность экземпляра SQL Server, работающего в виртуализованной среде Hyper-V, достаточно высока в сравнении с равным по параметрам экземпляром в среде Windows Server 2008.

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

Далее приведены некоторые общие соображения и рекомендации в отношении работы SQL Server в среде Hyper-V.

Замечания

    В Hyper-V гостевые виртуальные машины могут иметь не более четырех ядер ЦП. В связи с этим устанавливать SQL Server на виртуальные машины в среде Hyper-V следует только в том случае, если для планируемой рабочей нагрузки достаточно четырех процессоров. В сравнении с физическими системами, имеющими сходные аппаратные ресурсы, одинаковой пропускной способности в гостевой виртуальной машине можно достичь за счет немного большего использования ЦП. В Hyper-V число логических ядер ЦП, выделенных всем виртуальным машинам, может превышать фактическое число физических процессоров, имеющихся на сервере. В этих случаях наблюдались большие издержки ЦП и снижение производительности при выполнении рабочих нагрузок SQL Server. Для производительности SQL Server важнейшее значение имеет подбор надлежащей аппаратной конфигурации. Совокупные ресурсы физических ЦП, установленных на сервере должны быть достаточными для удовлетворения потребностей гостевых виртуальных машин. Чтобы это проверить, следует протестировать рабочую нагрузку в планируемой виртуальной среде. В случае значительной сетевой активности при рабочей нагрузке издержки ЦП выше, что больше сказывается на производительности. Приведенные здесь сведения главным образом касаются вопросов производительности. В каждом конкретном случае следует также учитывать и вопросы функциональности (т. е., поддерживаемые конфигурации, параметры достижения высокой готовности и так далее). Дополнительные сведения, касающиеся общей функциональности Hyper-V и действующей политики поддержки, связанной с выполнением SQL Server в среде Hyper-V, приведены в Приложении к этому документу. При тестировании были отмечены минимальные издержки производительности ввода-вывода при работе SQL Server на гостевой виртуальной машине. Конфигурация с дисками прямого доступа обеспечивала лучшую производительность ввода-вывода, однако, и при работе на виртуальных жестких дисках фиксированного размера отмечались минимальные издержки. Решение о выборе конфигурации хранилища должно приниматься, исходя из того, что требуется для конкретной системы. Виртуальные машины на базе виртуальных жестких дисков проще перемещать, чем когда используются диски прямого доступа. При консолидации решение должно приниматься с учетом объема имеющихся ресурсов хранения, а также самого сценария. При тестировании производительность была приемлемой при использовании как общих, так и выделенных конфигураций. В любом случае, при выборе размера хранилища следует учитывать рабочую нагрузку и требуемое время ответа. Всегда следуйте рекомендациям в отношении подсистемы хранения в средах Hyper-V, как и при развертывании любой системы SQL Server. Дополнительные сведения см. в статье Рекомендации по предварительному развертыванию ввода-вывода для SQL Server.

Рекомендации

    В качестве подсистемы хранения гостевой виртуальной машины используйте диски прямого доступа или виртуальные жесткие диски фиксированного размера. Это наилучшие варианты для обеспечения производительности, поскольку они обеспечивают лучшие результаты для рабочих нагрузок SQL Server. По соображениям производительности использовать динамические виртуальные жесткие диски не рекомендуется. Избегайте использования эмулированных устройств, напротив необходимо установить компоненты интеграции для среды Hyper-V и использовать искусственные устройства ввода-вывода, сетевые устройства и так далее. Искусственные устройства обеспечивают наилучшую производительность при наименьших издержках ЦП. Возможность использовать некоторые из этих методов зависит от мощности аппаратных средств. Рекомендации по оптимизации сети для конкретной конфигурации в случае выполнения рабочих нагрузок со значительным использованием сетевых ресурсов см. в разделах «Виртуализация» и «Сеть» руководства «Настройка производительности Windows». Тестируйте производительность путем выполнения планируемой рабочей нагрузки, поскольку результаты для разных рабочих нагрузок могут значительно отличаться.

Дополнительные сведения

    Среда Hyper-V Windows Server Руководство по планированию и развертыванию среды Hyper-V Microsoft Assessment and Planning Toolkit 3.1 для Hyper-V Пошаговое руководство по началу работы с Hyper-V Рекомендации по настройке производительности для Windows Server 2008 (раздел виртуализации) Часто задаваемые вопросы по производительности Hyper-V Мониторинг Hyper-V (группа Windows — БЛОГ по вопросам производительности) Политика поддержки для установки SQL Server в средах Hyper-V Рекомендации по предварительному развертыванию ввода-вывода для SQL Server Диспетчер виртуальных машин центра систем

Приложение 1: Архитектура Hyper-V

Hyper-V — это технология виртуализации на базе гипервизора для Windows Server 2008. Гипервизор — это платформа виртуализации, работающая в сочетании с некоторыми процессорами, позволяющая нескольким изолированным операционным системам работать на одной аппаратной платформе.

Hyper-V поддерживает изоляцию в разделах. Раздел является поддерживаемой гипервизором логической единицей изоляции, в которой выполняются операционные системы. Гипервизору Microsoft требуется как минимум один родительский, или корневой, раздел, в котором установлена 64-разрядная версия ОС Windows Server 2008. Стек виртуализации работает в родительском разделе и имеет прямой доступ к аппаратным устройствам. После этого корневой раздел создает дочерние разделы, в которых будут работать гостевые операционные системы. Дочерние разделы корневой раздел создает при помощи прикладного программного интерфейса (API) гипервызовов.

Разделы не имеют доступа к физическому процессору, и не обрабатывают его прерываний. Вместо этого, у них есть виртуальное представление процессора, а выполняются они в области адреса виртуальной памяти, которая у каждого гостевого раздела своя. Гипервизор обрабатывает прерывания процессора и перенаправляет их в соответствующий раздел. Hyper-V может также обеспечить аппаратное ускорение передачи адреса между разными пространствами адресов гостевых виртуальных машин при помощи устройства управления памятью ввода/вывода (IOMMU), которое работает независимо от аппаратных средств управления памятью, используемых ЦП. IOMMU используется для переназначения адресов физической памяти адресам, которые используются дочерними разделами.

Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8