Назад | Перейти на главную страницу

Лучшая практика для установки нескольких экземпляров MS SQL 2008r2 на Windows server 2008r2 (работает на esxi)

Я не хотел переносить свой sql-сервер на виртуальную платформу (Vsphere, esxi 4.1). Вот мой план, как мне его установить:

Ядра оперативной памяти и процессора будут добавляться по мере необходимости.

Есть ли способ отслеживать и графически отображать использование ЦП, ОЗУ и ввод-вывод dik в течение, скажем, 24 часов, чтобы получить некоторую информацию о нагрузке на сервер (с помощью встроенных инструментов Windows).

Будет ли это работать нормально и есть ли у вас какие-нибудь особые советы и рекомендации? С уважением, Примоз.

РЕДАКТИРОВАТЬ


Я попробовал простую тестовую настройку всего с двумя дисками C: для установки и D: для данных и журналов, а также с 2 виртуальными ЦП и 6 ГБ оперативной памяти. В моем тестовом наборе я увеличил использование процессора до 90% +, а использование оперативной памяти до 98%. Полагаю, это означает, что диск достаточно быстрый, а я ограничен ЦП и ОЗУ?

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

Встроенный Монитор производительности (PerfMon) - это именно тот инструмент, который вы хотите использовать для записи журналов в гостевой виртуальной машине. Свобода Анализ производительности журналов Инструмент может помочь вам разрезать журналы PerfMon, чтобы получить хороший анализ собранных данных.

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

Я использую почти ту же методологию. Я использую встроенные инструменты Windows perfmon для мониторинга своих физических ящиков и встроенные графики мониторинга, доступные в vSphere (я думаю, что и в ESXi) для моих виртуальных ящиков. Я разрешаю включать свои данные SQL и журналы в наши снимки. Это зависит от среды, поэтому вы можете протестировать оба способа.

РЕДАКТИРОВАТЬ - единственная проблема, о которой я могу думать, - это таблицы SQL временных типов. Возможно, их придется вручную переместить на новый диск. http://www.sqlteam.com/article/moving-the-tempdb-database

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