Запуск чего-либо внутри виртуальной машины снизит производительность, но насколько сильно действительно повлиять на производительность системы баз данных?
я нашел этот академический справочный документ с некоторыми интересными тестами, но это был ограниченный тест с использованием только Xen и PostgreSQL. Был сделан вывод, что использование виртуальной машины «не требует высокой производительности» (хотя вы можете подумать, что фактические данные говорят об обратном).
Какие технические, административные и другие недостатки связаны с запуском базы данных на виртуальной машине?
Пожалуйста, публикуйте ответы, которые могут быть подкреплены объективными фактами, меня не интересуют домыслы или другие полурелигиозные аргументы (страсть компьютерных фанатов хороша во многих отношениях, но здесь нам это не поможет).
Что, как говорится,
- Какие проблемы возникают при запуске базы данных на виртуальной машине? (размещайте ссылки)
- Эти проблемы значительны?
- Являются ли они значимыми только при определенных сценариях?
- Какие обходные пути?
Хотя многие поставщики БД не спешили с этим, почти все они теперь официально поддерживают свое программное обеспечение, работающее в виртуализированной среде.
Мы запускаем множество экземпляров Oracle 11g в Linux поверх ESXi, и, безусловно, можно получить очень хорошую производительность. Как и при любом масштабировании оборудования, вам просто нужно убедиться, что виртуализация хозяин имеет много ресурсов (ОЗУ, ЦП), и что ваш дисковый уровень может обеспечить любую требуемую производительность ввода-вывода.
Как говорит ErikA, это становится все более распространенным явлением. Я нахожусь в лагере SQL Server, и у меня лично нет производственных систем, работающих на виртуальных машинах, но я не колеблясь (после небольшого дополнительного изучения этой темы). Тем не менее, есть определенно некоторые вещи, которые следует принять во внимание, прежде чем идти по этому пути (по крайней мере, для SQL Server). Дисковый ввод-вывод (как уже упоминалось) и выделение памяти - это всего лишь 2 примера. В разных гипервизорах тоже все будет по-разному.
Брент Озар - признанный эксперт в виртуализации SQL Server, в частности, в VMWare. Я очень рекомендую прочитать его материал.
http://www.brentozar.com/community/virtualization-best-practices/
Там есть жестяная банка а потом есть должен. Корвет может разогнаться до 150 миль в час, но стоит ли ехать по дорогам общего пользования? Вы можете навредить себе без необходимости.
Базы данных - это гостевые операционные системы. По замыслу, при запуске они захватывают блоки ресурса и напрямую управляют им из соображений производительности. Как только вы сделаете основную операционную систему сервера базы данных гостевой в виртуализированной среде хостинга, вы разместите уровень арбитража с гипервизором между выделенным блоком элементом диска и ОЗУ и сервером базы данных. Это замедлится. Чем менее эффективны ваши запросы, тем медленнее они будут. Эта неэффективность сегодня может быть замаскирована на выделенном оборудовании, но как только вы введете арбитраж для своего зависимого ресурса, вы очень быстро это узнаете.
Многие счетчики компонентов, требующие виртуализации, не могут распознать, что серверы баз данных в качестве гостевых операционных систем предлагают собственный уровень консолидации. Нет причин, по которым вы не можете переместить объединение нескольких экземпляров логической базы данных на один физический сервер, даже до точки перемещения IP-адресов, настройки дополнительных имен хостов и т. Д., Чтобы обеспечить такое естественное объединение служб. И с помощью этой модели вы не только сохраняете экономию затрат, которую предлагает руководство для уменьшения количества физических хостов, но и сохраняете блокированный доступ к физическим ресурсам без вмешательства произвольного гипервизора, который иногда может принимать полезные решения, а не другие.
То же самое верно и для других гостевых операционных систем, таких как Java. Решения виртуализации обычно представляют собой загруженные среды, и гипервизору приходится принимать множество решений о том, кому «достается токен» на ресурсе. Каждый раз, когда вы можете удалить этот слой, вам будет лучше.
Сначала объедините несколько экземпляров, используя уровень естественной гостевой операционной системы. Скорее всего, вы сможете легче достичь целей по консолидации платформы и производительности.
Здесь нужно понять две вещи:
Тем не менее, там, где я работаю, наша установка Sql Server - это один из двух серверов, которые я не собираюсь виртуализировать в ближайшее время (другой - основной DC).
Запуск SQL Server на виртуальной машине будет нормальным при условии, что вы можете предоставить виртуальной машине достаточно ресурсов для запуска вашего приложения. Если в физическом мире вам нужно 24 ядра и 256 гигабайт оперативной памяти, тогда вам необходимо предоставить 24 виртуальных ЦП и 256 гигабайт оперативной памяти в виртуальном мире.
я просто написал статью в последние месяцы журнал SQL Server посвящен запуску SQL Server под VMware vSphere.
Я запускаю две базы данных, одну PostgreSQL, а другую MySQL, в виртуальной среде (Xen), где dom0s очень доступны. Все файловые системы domU расположены на iSCSI SAN LUN, разделенном на логические тома LVM2. База данных MySQL предназначена исключительно для Cacti, поэтому она практически не используется и также находится на iSCSI LUN.
База данных PostgreSQL - это база данных для нашей промежуточной среды, поэтому ее использование выше, чем у MySQL db. По этой причине база данных находится на локальном наборе RAID10, а DRBD реплицируется на второй узел кластера. Однако с точки зрения реальной нагрузки эта промежуточная база данных вообще не видит очень высокой нагрузки. Что, на мой взгляд, делает его хорошим / отличным кандидатом для виртуализации.
Некоторые из преимуществ для нашей организации заключались в снижении энергопотребления, экономии места в стойке и меньших административных накладных расходов на оборудование.
С другой стороны, я не могу представить, чтобы наша основная производственная база данных стала виртуальной ....
Я работаю с серверами MSSQL и MySQL на многих серверах. Пару лет назад я не решался начинать настройку SQL-серверов на виртуальных машинах, потому что слышал о проблемах производительности при запуске SQL-сервера на виртуальной машине. Однако я был удивлен, когда установил пару моих первых SQL-серверов и не увидел изменений в производительности. Все больше и больше серверов, над которыми я работаю, находятся на виртуальных машинах, и почти все крупные корпоративные клиенты, на которых я работаю, имеют виртуализированные серверы SQL.
Да, виртуальная машина увеличивает накладные расходы, и если вы собираетесь размещать несколько виртуальных машин в одном устройстве, вам понадобится хороший мощный сервер. Распространенная проблема с ресурсами, на которую следует обратить внимание, - это добавление дополнительных виртуальных машин и сокращение доступных ресурсов. Обычная практика - планировать некоторый рост, но если вы купили свой сервер для размещения 2 или 3 виртуальных машин, а теперь на нем работает 10 виртуальных машин, вы, вероятно, увидите снижение производительности.
Я бы солгал, если бы сказал, что никогда не видел проблем с производительностью при запуске SQL-сервера на виртуальной машине. Но я понял, что если вы видите низкую производительность, вероятно, что-то не так с окружающей средой.