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

https://stackoverflow.com/questions/149318

02-07-2019
|

Вопрос

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

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

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

Каковы конкретные причины, по которым это хорошая идея?Мне нужны рекомендации, или не утруждайте себя ответом.Я мог бы самостоятельно придумать расплывчатый ответ "Связанный с вводом-выводом" через Google.
Одно только воспоминание о спикере HHH, вероятно, не убедит наш ИТ-отдел изменить свое мнение.Кто-нибудь может прямо указать мне на что-нибудь более авторитетное?И под "непосредственно" я подразумеваю нечто более конкретное, чем просто расплывчатый комментарий к книгам в Интернете.Пожалуйста, немного сузьте круг поисков.

Решение

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

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

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

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

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

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

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

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

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

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

Другие советы

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

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

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

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

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

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

Вот некоторые результаты тестирования VMWARE по этому поводу..http://www.vmware.com/files/pdf/SQLServerWorkloads.pdf

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

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

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

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

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

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

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

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

Некоторая информация по этому поводу есть в У Конора Каннингема статья в блоге Виртуализация баз данных - Маленький Грязный секрет, о котором никто не говорит....Процитировать:

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

все процессоры одинаково мощные

все процессоры обрабатывают инструкции примерно с одинаковой скоростью.

сброс на диск, вероятно, должен произойти за ограниченный промежуток времени.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow