Виртуализированный SQL Server: почему бы и нет?

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

Вот статья об этом для MS SQL. Не уверен в вашей ситуации, поэтому не могу выделить какие-либо важные моменты.

http://www.microsoft.com/sql/howtobuy/virtualization.mspx

SQL Server поддерживается в виртуальной среде. Фактически, я бы порекомендовал это, видя, что один из вариантов лицензирования - на сокет. Это означает, что вы можете разместить столько экземпляров SQL Server в виртуализированной системе (например, Windows 2008 Server Datacenter), сколько захотите, и платить только за сокет процессора, который есть на машине.

Это лучше, потому что DataCenter лицензируется на сокет с неограниченным количеством лицензий на виртуальные машины.

Я бы порекомендовал кластеризовать Hyper-V на двух машинах, чтобы в случае сбоя одного из них другой мог компенсировать провал.

SAN - конечно, и кластеризация, но что касается виртуализации - вы получите удар по производительности (может вам это того стоить, а может и нет):

http://blogs.technet.com/andrew/archive/2008/05/07/virtualized-sql-server.aspx

В последнее время у http://sswug.org были заметки об этом в ежедневном информационном бюллетене.

Вот несколько тестов VMWARE на нем .. http://www.vmware.com/files/pdf/SQLServerWorkloads.pdf

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

В настоящее время мы запускаем SQL Server 2005 в среде VMWARE. НО, это очень слабо загруженная база данных, и это здорово. Бегает без проблем.

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

Возможно, вам удастся убедить ИТ-отдел провести хорошее тестирование, прежде чем слепо внедрять его.

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

Это нормально для разработки. Возможно даже тестирование (исходя из теории, что если он отлично работает под нагрузкой на виртуальном боксе, он будет нормально работать и при производстве), но не в производстве.

На самом деле это здравый смысл. Вы хотите, чтобы на вашем оборудовании работали две операционные системы и сервер sql или одна операционная система и сервер sql?

Редактировать: Мой опыт повлиял на мою реакцию. Я работал с большими базами данных при постоянной большой нагрузке. Если у вас небольшая база данных при небольшой нагрузке, виртуализация может вам подойти.

Я могу сказать это по личному опыту, потому что я занимаюсь именно этой проблемой, пока мы говорим. Место, где я сейчас работаю подрядчиком, имеет такую ​​среду для своих систем разработки SQL Server. Я пытаюсь разработать довольно скромный Б.И. система в этой среде и действительно борется с проблемами производительности.

Промахи TLB и эмулируемый ввод-вывод очень медленны на простой виртуальной машине. Если ваша операционная система поддерживает паравиртуализацию (которая еще не является зрелой технологией в Windows), вы используете паравиртуализированный ввод-вывод (по сути, драйвер устройства, который подключается к API в виртуальной машине). В последних версиях Opteron есть поддержка вложенных таблиц страниц, что устраняет необходимость эмуляции MMU в программном обеспечении (что очень медленно).

Таким образом, приложения, которые работают с большими наборами данных и выполняют множество операций ввода-вывода, такие как (скажем) процессы ETL, преодолевают ахиллесову пяту виртуализации. Если у вас есть что-то вроде системы хранилища данных, которая может сильно загружать память или дисковый ввод-вывод, вам следует подумать о другом. Для простого транзакционного приложения они, вероятно, подходят.

В перспективе системы, которые я использую, работают на блейд-серверах (сервер IBM) в сети SAN с 4-мя 2-гигабитными каналами F / C. Это SAN среднего уровня. Виртуальная машина имеет 4 ГБ ОЗУ IIRC и теперь два виртуальных процессора. В лучшем случае (когда сеть SAN не работает) это всего лишь половина скорости моего XW9300, который имеет 5 дисков SCSI (система, tempdb, журналы, данные, данные) на 1 шине U320 и 4 ГБ ОЗУ.

Ваш опыт может отличаться, но я бы рекомендовал использовать системы рабочих станций, подобные той, которую я описал, для разработки любых операций ввода-вывода, а не виртуальных серверов в SAN. Если ваши требования к использованию ресурсов не выходят за рамки этого набора (в этом случае они все равно выходят за рамки виртуального сервера), это гораздо лучшее решение. Оборудование не такое уж дорогое - конечно, намного дешевле, чем SAN, блейд-шасси и лицензирование VMWare. Версия для разработчиков SQL Server поставляется с V.S. Pro и выше.

Это также имеет то преимущество, что ваша команда разработчиков вынуждена заниматься развертыванием с самого начала - вам нужно придумать архитектуру, которую легко развернуть «одним щелчком мыши». Это не так сложно, как кажется. Redgate SQL Compare Pro - ваш друг здесь. Ваши разработчики также получают базовые практические знания по администрированию баз данных.

Быстрое путешествие на Веб-сайт HP принесло мне прейскурантную цену около 4600 долларов за XW8600 (их текущая модель на базе xeon) с четырехъядерным чипом xeon, 4 ГБ оперативной памяти и жесткими дисками SAS 1x146 и 4x73 ГБ 15k. Уличная цена, вероятно, будет несколько меньше. Сравните это с ценой на SAN, блейд-шасси и лицензию VMware, а также со стоимостью резервного копирования для этой установки. Для резервного копирования вы можете предоставить общий сетевой ресурс с резервным копированием, куда люди могут при необходимости сбросить сжатые файлы резервных копий БД.

Обновлено: Этот технический документ на веб-сайте AMD обсуждает некоторые тесты на виртуальной машине. Судя по тестам на задней панели, тяжелая рабочая нагрузка ввода-вывода и MMU действительно снижает производительность виртуальной машины. Их тест (который следует воспринимать с недоверием, поскольку это статистика, предоставленная поставщиком) предполагает 3,5-кратное снижение скорости в тесте OLTP. Хотя это предоставляется поставщиком, следует иметь в виду:

• Он тестирует наивную виртуализацию и сравнивает его с паравиртуализированное решение, а не производительность на чистом металле.

• Тест OLTP будет иметь больше рабочая нагрузка ввода-вывода с произвольным доступом и будет тратить больше времени на ожидание диска ищет. Более последовательный диск схема доступа (характеристика запросы к хранилищу данных) будут иметь более высокий штраф и тяжелая память операции (например, SSAS - это библейский боров памяти), имеющий большое количество промахов TLB также нести дополнительные штрафы. Этот означает, что замедление на этом тип обработки, вероятно, будет более выражен, чем OLTP эталонный штраф, указанный в техническом документе.

Здесь мы увидели, что TLB пропускает, а ввод-вывод для виртуальной машины очень дорого обходится. Хорошая архитектура с паравиртуализированными драйверами и аппаратной поддержкой в ​​MMU смягчит некоторые или все это. Однако я считаю, что Windows Server 2003 вообще не поддерживает паравиртуализацию, и я не уверен, какой уровень поддержки предоставляется на сервере Windows 2008. По моему опыту, виртуальная машина радикально замедляет работу сервера при работе с процессом ETL и сборками куба SSAS по сравнению с относительно скромными техническими характеристиками «голого железа».

Мы без проблем запускаем систему расчета заработной платы для 900+ человек на VMWare. Это было в производстве уже 10 месяцев. Что касается БД, это нагрузка среднего размера, и мы заранее выделили дисковое пространство в виртуальной машине, чтобы предотвратить проблемы с вводом-выводом. Для поддержания приемлемой производительности необходимо регулярно дефрагментировать как узел виртуальной машины, так и фрагмент виртуальной машины.

Я бы подумал, что вероятность того, что с данными случится что-то плохое, слишком велика.

В качестве мертвого простого примера предположим, что вы запустили сервер SQL Server в Virtual Server 2005 R2 и были включены диски отмены (таким образом, основной "дисковый" файл остается прежним, а все изменения вносятся в отдельный файл, который можно очистить. или объединены позже). Затем что-то происходит (обычно вы сталкиваетесь с лимитом в 128 ГБ или любым другим размером), и какой-то невежественный администратор посреди ночи должен перезагрузиться и выясняет, что он не может этого сделать, пока не удалит диски отмены. Вы облажались - даже если он хранит файлы на диске отмены для последующего анализа, возможности объединения данных довольно невелики.

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

Информация об этом содержится в статье блога Конора КаннингемаВиртуализация баз данных - маленький грязный секрет, о котором никто не говорит .... Цитировать:

Within the server itself, there is suprisingly little knowledge of a lot of things in this area that are important to performance. SQL Server's core engine assumes things like:

1. all CPUs are equally powerful
2. all CPUs process instructions at about the same rate.
3. a flush to disk should probably happen in a bounded amount of time.

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

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

Наша компания (более 200 SQL-серверов) в настоящее время развертывает HP Polyserve на некоторых из наших серверов:

HP PolyServe Software for Microsoft SQL Server enables multiple Microsoft SQL Server instances to be consolidated onto substantially fewer servers and centralized SAN storage. HP PolyServe's unique "shared data" architecture delivers enterprise class availability and virtualization-like flexibility in a utility platform.

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

Также следует учитывать вопросы безопасности, которые могут возникнуть при работе с Vitalization. Безопасность виртуализации - хорошая статья от PandaLabs, в которой рассматриваются некоторые проблемы.

Я хотел добавить эту серию статей Брента Озара:

• Почему ваш системный администратор хочет виртуализировать ваши серверы
• Зачем вам виртуализировать SQL Server?
• Причины, по которым не следует виртуализировать SQL Server

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

Вы смотрите на это под неправильным углом. Во-первых, вы не найдете официальных документов от поставщиков, почему вам «не следует» виртуализировать или почему вам следует виртуализировать.

Каждая среда отличается, и вам нужно делать то, что работает в вашей среде. С учетом сказанного, есть некоторые серверы, которые идеально подходят для виртуализации, а есть некоторые, которые не следует виртуализировать. Например, если ваш SQL Server / s выполняет миллионы и миллионы транзакций в секунду, например, если ваш сервер находится на NYSE или NASDAQ и от него зависят миллионы и миллионы долларов, вам, вероятно, не следует его виртуализировать. Убедитесь, что вы понимаете последствия виртуализации SQL-сервера.

Я видел, как люди виртуализируют SQL снова и снова только потому, что виртуализация - это круто. Затем пожаловаться позже, когда сервер виртуальной машины не работает должным образом.

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

Старый вопрос со старыми ответами

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

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

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