Каковы недостатки работы базы данных внутри виртуальной машины? Как мне их преодолеть? [закрыто]

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

Я нашел этот академический справочник с некоторыми интересными тестами, но это был ограниченный тест с использованием только 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. Решения для виртуализации обычно представляют собой загруженные среды, и гипервизору приходится принимать множество решений о том, кто «получает токен» на ресурсе. В любое время вы можете устранить этот слой, вам будет лучше.

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

Здесь нужно понять две вещи:

• Единица производительности БД на единицу оборудования немного ниже для виртуализированной базы данных. Это означает, что вам нужно купить немного больше оборудования, чтобы получить тот же уровень производительности.
• Это не означает, что тот же уровень или желаемый уровень производительности недостижим. Выгоды вы получаете от улучшения управления и других преимуществ (например , проще HA) часто путем более чем компенсированы незначительно увеличились затраты на оборудование.

Тем не менее, там, где я работаю, наша установка 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. По этой причине база данных находится в локальном наборе RAID10, а DRBD реплицируется на второй узел кластера. Однако, с точки зрения реальной нагрузки, эта промежуточная база данных не видит очень высокую нагрузку вообще. Что, на мой взгляд, делает его хорошим кандидатом для виртуализации.

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

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

Я работаю с серверами MSSQL и MySQL на многочисленных серверах. Пару лет назад я не решался приступить к настройке серверов SQL на виртуальных машинах, потому что я слышал о проблемах производительности при запуске сервера SQL на виртуальной машине. Тем не менее, я был удивлен после того, как я установил свою первую пару SQL-серверов и не увидел изменений в производительности. Все больше и больше серверов работают на ВМ, и почти все крупные корпоративные клиенты, на которых я работаю, виртуализировали SQL-серверы.

Да, виртуальная машина добавляет некоторые накладные расходы, и если вы собираетесь разместить несколько виртуальных машин на одном компьютере, вам понадобится хороший мощный сервер. Распространенная проблема с ресурсами, на которую следует обратить внимание, - это добавление дополнительных виртуальных машин и сокращение доступных ресурсов. Обычная практика - планировать некоторый рост, но если вы купили свой сервер для размещения 2 или 3 виртуальных машин, а теперь он работает на 10 виртуальных машинах, вы, вероятно, увидите снижение производительности.

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