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

Question

ИТ-отдел, в котором я работаю, пытается перейти на 100% виртуализированные серверы со всеми данными, хранящимися в сети SAN. Они еще этого не сделали, но план в конечном итоге предусматривает перемещение существующих физических машин SQL Server на виртуальные серверы.

Несколько месяцев назад я присутствовал на мероприятии по запуску Heroes Happen Here, и на одном из сеансов SQL Server попутно упомянул оратор, что это не очень хорошая идея для производственных систем.

Итак, я ищу несколько вещей:

1. Каковы конкретные причины, по которым это является или не является хорошей идеей? Мне нужны ссылки, или не отвечайте. Я мог бы придумать смутный ответ «I / O bound» самостоятельно через Google.
2. Одно только воспоминание спикера HHH, вероятно, не убедит наш ИТ-отдел изменить свое мнение. Кто-нибудь может указать мне прямо на что-то более авторитетное? И под «напрямую» я имею в виду нечто более конкретное, чем просто расплывчатый комментарий Books OnLine. Пожалуйста, сузьте это немного.

Answer 1

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

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

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

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

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

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

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

РЕДАКТИРОВАТЬ: В этом техническом документе на веб-сайте AMD обсуждаются некоторые тесты для виртуальной машины. Исходя из тестов в задней части, высокая нагрузка ввода-вывода и MMU действительно снижает производительность виртуальных машин. Их эталонный тест (который будет взят с крошкой соли, поскольку это статистика, предоставляемая поставщиком) предлагает 3,5-кратное снижение скорости по эталонному тесту OLTP. Пока это поставляется поставщиком, следует иметь в виду:

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

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

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

Answer 2

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

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

http://sswug.org в своей ежедневной новостной рассылке в последнее время заметили некоторые заметки

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

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

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

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

Answer 6

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

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

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

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

Answer 7

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

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

Программное обеспечение HP PolyServe для Microsoft SQL Server позволяет консолидировать несколько экземпляров Microsoft SQL Server на существенно меньшем количестве серверов и централизованном хранилище SAN. Уникальная архитектура «общих данных» HP PolyServe обеспечивает доступность корпоративного класса и гибкость, подобную виртуализации, на служебной платформе.

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

Answer 8

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

На самом сервере удивительно мало знаний о многих вещах в этой области, которые важны для производительности. Ядро ядра SQL Server предполагает такие вещи, как:

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

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

Answer 9

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

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

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

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

Answer 10

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

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

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

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