Пожалуйста, поделитесь своими советами и передовыми методами виртуализации SQL Server в VMWare ESX. Меня интересуют расширенные конфигурации и настройки.
Пожалуйста, объясните свои рекомендации
Изменить: Чтобы уточнить, у меня уже есть более 70 виртуальных серверов SQL в отдельных кластерах с использованием ISCSI equallogic San -
Что мне действительно нужно, так это такие расширенные конфигурации, как:
Как вы настроили свои диски / RDM
Вы используете такие настройки, как Mem.ShareScanGHz - http://communities.vmware.com/thread/143828 - которые плохо документированы
Обычно я ненавижу ссылки на официальные документы поставщиков, но VMware опубликовала на удивление хороший технический документ по этому поводу:
http://www.vmware.com/files/pdf/solutions/sql_server_virtual_bp.pdf
Там все важно, и я лично за многое могу поручиться. Меньше виртуальных процессоров действительно лучше, чем больше: если вы не загружаете 100% одного процессора, вам не нужно добавлять второй виртуальный процессор. Это связано с тем, как работает планирование ЦП VMware.
Единственное, что не определено явным образом в документе, - это использование нескольких путей. С ESX 3.5 и более ранними версиями вы не получите истинного активного / активного многопутевого обмена для вашей SAN. Если вам требуется более одного HBA полосы пропускания для одной виртуальной машины, он должен оставаться как физическая машина до выхода vSphere 4, и даже в этом случае вам необходимо получить первоклассную версию, чтобы получить настоящий многопутевый.
У нас есть кластер vmware с 3 узлами, каждый из которых представляет собой HP 365 (2xCPU, 4 ядра, 1,8 МГц), 32 ГБ ОЗУ на сервер и подключения Fibre Channel к большим дискам.
Мы поддерживаем более 20 виртуальных машин SQL (SQL2000, SQL2005 и SQL2008, live, dev и test), а также другие общие серверы Windows 2003 (iis6, приложение, файл и печать и т. Д.), И у нас есть как минимум вдвое больше, чтобы перейти на него, и я не Не ожидаю проблем с производительностью.
Эти три узла обеспечивают «максимальную» избыточность и отказоустойчивость. Если один узел выходит из строя (или для обслуживания), два других могут обеспечивать такую же производительность. Три - это роскошь (или лучшая практика, как они любят это называть), двух будет достаточно.
Фактические виртуальные машины довольно легкие. Обычно 1vCPU и 1GB RAM, и в них размещается 20 или 30 баз данных. Одна или две более загруженные виртуальные машины вдвое больше, но это обычно из-за плохо написанных приложений, использующих SQL Server в качестве игрушки (без использования хранимых процедур и т.д., но это до смерти обсуждается на "другом" сайте!;)
Виртуальная машина дает нам гибкость для создания большего количества «меньших» серверов со схожими шаблонами использования (держите движущихся большими данными подальше от легких систем веб-сайтов) и / или требований SLA (храните все важные вещи вместе с общими и стандартизованными методами работы. ).
Учитывая, что у нас много ОЗУ, ЦП и быстрого диска, нам не пришлось настраивать нашу систему на микроконтроллеры. ДИСК представляет собой несколько массивов RAID 10 (примерно разделенных между ОС, журналами транзакций и базой данных) с некоторым большим% RAID для резервного копирования и дампа.
Множество резервных сетевых подключений 1 ГБ в резервные граничные коммутаторы.
Эта тема была подробно рассмотрена в недавнем подкасте сообществ VMware. См. Здесь: http://blogs.vmware.com/vmtn/2009/03/virtualizing-sql-server-podcast-white-paper.html, и слушайте выпуск # 42 здесь: http://www.talkshoe.com/talkshoe/web/talkCast.jsp?masterId=19367