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


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

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

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

Пожалуйста, размещайте ответы, которые могут быть подкреплены объективными фактами, меня не интересуют спекуляции или любые другие полурелигиозные аргументы (страсть к geek хороша во многих отношениях, но это не поможет нам здесь).

Что, как говорится,

  • Какие проблемы возникают при запуске базы данных в виртуальной машине? (пожалуйста, напишите ссылки)
  • Являются ли эти проблемы значительными?      
    • Являются ли они важными только при определенных сценариях?
  • Каковы обходные пути?

64
2017-09-01 14:03


Источник


+1 Мне в первую очередь интересно услышать отзывы о сценариях SQL Server и Windows 2008 R2 - AccidentallyObtuse
@Shane Madden - Не могли бы вы немного объяснить закрытие? Я ожидаю, что мотивация была обусловлена ​​одним неспецифическим ответ (который затем был сорван в комментариях), а не сам вопрос. Что касается вопроса, 44 голоса и 12 избранных в течение примерно одного дня существования перед закрытием подразумевают, что это был хороший вопрос с полезными ответами / информацией (особенно по сравнению с тем, что кажется типичным для трафика вопросов ServerFault). Это то, на что нацелены различные сайты SE. Вы предпочли бы более конкретную формулировку вопроса, а не свободную «насколько это плохо?». - Russ
@ErikA, Shane, Womble, mikeyb, Ben - я создал редактирование сообщества, которое может сделать этот вопрос более конструктивным. Подумайте о повторном открытии или отправке аналогичного вопроса по новому / чистому вопросу. - AccidentallyObtuse


Ответы:


Хотя многие поставщики БД очень медленно это делали, почти все они теперь официально поддерживают свое программное обеспечение, работающее в виртуализованной среде.

Мы запускаем множество экземпляров Oracle 11g в Linux поверх ESXi, и, безусловно, можно получить очень хорошую производительность. Как и при всем аппаратном масштабировании, вам просто нужно убедиться, что виртуализация хозяин имеет большое количество ресурсов (ОЗУ, ЦП), и что ваш уровень диска соответствует задаче доставки любой требуемой производительности ввода-вывода.


41
2017-09-01 14:35



+1 Как отмечено, критически важно, чтобы ресурсы соответствовали задаче. Диск был большим узким местом для нас, и требуется тщательное планирование. - Dave M
+1 Вам нужно сделать домашнее задание в базе данных Применение досрочно. Если ваш физический бокс забит более 40% -ным использованием, ваши преимущества для vm'ing его начинают растворяться. Это говорит о том, что у нас есть тонны изолированных изолированных sql-приложений, работающих на vm без проблем. Но наши большие машины с большим объемом использования имеют специальное оборудование из-за отсутствия преимуществ. - Nate
Определенно диск IO является большим виновником, и то, что виртуализованная среда, как правило, flaky. - lynxman
@lynxman - Согласен. Мы запускаем все наши экземпляры Oracle на наших SAN-дисках уровня 1, которые составляют 15 тыс. SAS. Из того, что я могу сказать, мы получаем очень рядом с близкими характеристиками. - EEAA♦
«Унция теста стоит фунта догадки». - Chris B. Behrens


Как говорит ErikA, это становится все более распространенным явлением. Я нахожусь в лагере SQL Server и лично не имею каких-либо производственных систем, работающих в виртуальных машинах, но я бы не стал колебаться (после небольшого исследования по этой теме). Есть некоторые вещи, которые нужно учитывать, прежде чем идти по этому пути (хотя бы для SQL Server). Диск IO (как указывали другие) и распределение памяти - всего лишь 2 примера. Между различными гипервизорами будут разные вещи.

Брент Озар является признанным экспертом в области виртуализации SQL Server, в частности, в VMWare. Я бы очень рекомендовал прочитать его материал.

http://www.brentozar.com/community/virtualization-best-practices/


21
2017-09-01 15:00





Там есть Можно и тогда должен, Корвет может идти 150 миль в час, но должны ли вы на общественные дороги? Вы можете причинить себе вред без необходимости.

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

То, что многие счетчики бобов, которые требуют виртуализации, не могут распознать, - это то, что серверы баз данных, как гостевые операционные системы, предлагают свой собственный уровень консолидации. Нет причин, по которым вы не можете перемещать консолидированные экземпляры нескольких логических баз данных на одном физическом сервере, вплоть до перемещения IP-адресов, создания дополнительных имен хостов и т. Д., Чтобы это происходило при естественном объединении сервисов. И с этой моделью вы не только сохраняете экономию средств, которую руководство нажимает на меньшее количество физических хостов, но вы сохраняете доступ к блокам с физическими ресурсами без ущерба для произвольного гипервизора, что иногда может принимать полезные решения, а не другие.

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

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


11
2017-09-01 18:01



Интересное определение «гостевой операционной системы». В то время как ваша точка зрения касается чистой, безупречной производительности, как часто ваши базы данных на самом деле являются узким местом в процессоре? I / O гораздо более вероятен, и для приложений с более высокой производительностью вы уже используете время ввода-вывода в SAN. Я надеюсь, что вы пересмотрели свою философию виртуализации, когда проблема безопасности с одним приложением ставит под угрозу все хэши паролей ваших консолидированных баз данных или когда один процесс, запущенный в вашей JVM, потребляет каждый байт доступного пространства кучи. - Shane Madden♦
Чтобы быть ясным, я полностью согласен с тем, что тонко настроенный, массово загруженный высокопроизводительный сервер базы данных должен иметь свое собственное физическое оборудование. Но это не норма, а другие преимущества виртуализации, как правило, перевешивают хит производительности, который неотличим с большинством рабочих нагрузок. - Shane Madden♦
Я не согласен с вашей точкой зрения о том, чтобы в первую очередь перейти к существующим уровням консолидации. Иногда это имеет смысл. Но посмотрите, например, на компромисс затрат на перебалансировку ресурсов между объединением нескольких баз данных в одной ОС и объединением нескольких комбинаций баз данных и ОС поверх гипервизора. Первый более эффективен. Второе - намного легче перебалансировать. Миграция и ОС / база данных на новый хост намного менее разрушительны, чем перенос базы данных в новую ОС. - Jake Oshins
Мои комментарии исходят из непосредственных наблюдений за успешными и неудачными переходами к решениям виртуализации за последнее десятилетие в качестве инженера-исполнителя. Там есть множество плохих приложений баз данных, чье беспорядочное использование проблем с производительностью аппаратных масок. Добавьте виртуализацию, и эти проблемы выявляются. Если у вас есть приложение, которое требует точных часов для синхронизации или аудита, то с помощью поплавка часов в виртуализации программного обеспечения вы находитесь вне охоты. - James Pulley
Вау, просто вау Джеймс. У меня нет времени и терпения, чтобы уничтожить все моменты, которые вы сделали в своем ответе и последующих комментариях, но я просто почувствовал, что мне нужно оставить комментарий здесь для всех, кто может произойти после этого ответа. Взгляды Джеймса, ну, его собственные, и не отражают того, что действительно возможно. Если вы переполнены, тогда конечно у вас будет низкая производительность. Так что не переписывайте. Совершенно возможно иметь очень высокопроизводительную среду виртуализации. Глупо делать рекомендацию против нее, потому что она «плохо работает». - EEAA♦


Здесь есть две вещи:

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

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


6
2017-09-01 15:11





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

я просто написал статью в последние месяцы журнал SQL Server рассказывает о запуске SQL Server под VMware vSphere.


4
2017-09-02 00:26





Я запускаю две базы данных, одну PostgreSQL и другую MySQL, в виртуальной среде (Xen), где dom0s доступны. Все файловые системы domU расположены на iSCSI SAN LUN, вырезанных логическими томами LVM2. База данных MySQL предназначена исключительно для Cacti, поэтому она почти не видна и находится на iSCSI LUN.

База данных PostgreSQL является базой данных для нашей промежуточной среды и, следовательно, имеет более высокий уровень использования, чем MySQL db. По этой причине база данных расположена на локальном наборе RAID10, а DRBD реплицируется на второй узел кластера. Однако, с точки зрения реальной нагрузки, эта промежуточная база данных вообще не видит очень высокой нагрузки. Что, на мой взгляд, делает его хорошим / отличным кандидатом на виртуализацию.

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

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


2
2017-09-01 19:00





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

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

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


2
2017-09-02 03:26