Які недоліки роботи бази даних всередині віртуальної машини? Як я їх долаю? [зачинено]


66

Запуск чого-небудь всередині віртуальної машини буде мати певний рівень продуктивності, але наскільки це насправді впливає на роботу системи баз даних?

Я знайшов цей навчальний довідковий документ з цікавими орієнтирами, але це був обмежений тест, використовуючи лише Xen та PostgreSQL. Висновок полягав у тому, що використання VM "не приносить високої продуктивності" (хоча ви можете подумати, що фактичні дані говорять інакше).

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

Будь ласка, опублікуйте відповіді, які можуть бути підкріплені об’єктивними фактами, я не зацікавлений у спекуляціях чи будь-яких інших напіврелігійних аргументах (пристрасть до потвор, багато в чому хороша, але це нам тут не допоможе).

Це сумно,

  • Які проблеми з’являються під час роботи бази даних у віртуальній машині? (будь ласка, опублікуйте посилання)
  • Чи важливі ці питання?
    • Чи є вони значущими лише за певних сценаріїв?
  • Що таке обхідні шляхи?

+1 Мені насамперед цікаво почути відгуки про сценарії SQL Server та Windows 2008 R2
goodguys_activate

4
@Shane Madden - Чи можете ви, будь ласка, трохи пояснити закриття? Я сподіваюся, що мотивація була зумовлена ​​однією неспецифічною відповіддю (яка потім була зірвана з коментарів), а не самим питанням. Що стосується питання, то 44 голоси та 12 фаворитів протягом приблизно одного дня існування перед закриттям для мене означає, що це було гарне запитання з корисними відповідями / інформацією (особливо порівняно з тим, що здається типовим для трафіку питань ServerFault). Це те, на що спрямовані різні сайти SE. Ви б віддали перевагу більш конкретному формулюванню питання, а не вільному "як це погано?".
Russ

1
@ErikA, Shane, Womble, mikeyb, Ben - я змінив спільноту, що може зробити це питання більш конструктивним. Подумайте про повторне відкриття цього запитання або опублікуйте подібне запитання з нового / чистого питання.
goodguys_activate

Відповіді:


41

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

Ми запускаємо багато екземплярів Oracle 11g в Linux на вершині ESXi, і це, безумовно, можна отримати дуже хороші показники. Як і у випадку зі всім апаратним масштабуванням, вам просто потрібно переконатися, що хост віртуалізації має багато ресурсів (оперативної пам’яті, процесора) і що на вашому шарі диска поставлено завдання забезпечити будь-яку продуктивність IO, яка вам потрібна.


7
+1 Як зазначалося, критично, що ресурси відповідають завданням. Диск був для нас великим вузьким місцем і потрібно ретельне планування.
Дейв М

2
+1 Ви повинні зробити свою домашню роботу на базі використання заздалегідь. Якщо ваша фізична скринька забита вище 40% використання, то ваші переваги для вмивання її починають розсмоктуватися. Але, маючи на увазі, у нас є безліч маленьких ізольованих програм, що залежать від додатків, на VM без проблем. Але наші великі машини з великим рівнем експлуатації мають спеціальне обладнання через відсутність переваги.
Нейт

5
Однозначно винуватцем дискового IO є найбільший винуватець, і в тому, що віртуалізовані середовища, як правило, нечіткі.
рись

1
@lynxman - Погодився. Усі наші екземпляри Oracle ми запускаємо на наших SAN-дисках Tier 1, які є 15K SAS. З того, що я можу сказати, ми дуже близькі до майже рідного виступу.
EEAA

10
"Унція тесту варті вантажу здогадки."
Кріс Б. Беренс

21

Як каже Еріка, це стає все більш поширеним явищем. Я перебуваю в таборі SQL Server і особисто не маю жодної виробничої системи, що працює в VM, але я б не вагався (після трохи докладнішого вивчення цієї теми). Ви, безумовно, повинні враховувати деякі речі, перш ніж піти по цьому шляху (принаймні, для SQL Server). Дисковий IO (як уже згадували інші) і розподіл пам'яті - лише 2 приклади. Речі будуть різними і між різними гіпервізорами.

Brent Ozar - визнаний фахівець з віртуалізації SQL Server, зокрема в VMWare. Я б дуже рекомендував прочитати його матеріал.

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


11

Є може, і тоді має бути . Корвет може проїхати 150 миль / год, але чи варто вам на автомобільних дорогах загального користування? Ви можете собі нашкодити.

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

Що багато лічильників бобів, які вимагають віртуалізації, не впізнають, це те, що сервери баз даних як гостьові операційні системи пропонують свій власний рівень консолідації. Немає жодних причин, чому ви не можете перемістити консолідовані декілька екземплярів логічної бази даних на одному фізичному сервері, навіть до точки переміщення IP-адрес, встановлення додаткових імен хостів тощо ..., щоб забезпечити можливість цього природного об'єднання служб. І завдяки цій моделі ви не тільки зберігаєте економію витрат, яку керівництво наполягає на зменшенні кількості фізичних хостів, але ви зберігаєте блоковий доступ до фізичних ресурсів без перешкод довільному гіпервізору, який може приймати вигідні рішення іноді, а не інші.

Те саме стосується інших гостьових операційних систем, таких як Java. Рішення для віртуалізації, як правило, зайняті середовищем, і гіпервізор повинен приймати багато рішень щодо того, хто "отримує маркер" на ресурсі. Коли ви зможете усунути цей шар, вам буде краще.

З’єднайте кілька примірників, використовуючи спочатку природний гостьова операційна система. Шанси на те, що ви зможете легше досягти консолідації вашої платформи та цілей ефективності.


4
Цікаве визначення "гостьової операційної системи". Хоча ваша думка сприймається з точки зору чистої, непорушеної продуктивності, наскільки часто ваші бази даних дійсно вузькі місця в процесорі? Введення / виведення набагато ймовірніше, і для додатків з більш високою продуктивністю ви вже ділите час вводу / виводу в SAN. Я сподіваюся, що ви переглянете свою філософію віртуалізації, коли проблема безпеки за допомогою однієї програми компрометує всі хеші паролів вашої консолідованої бази даних або коли один процес, що працює у вашому JVM, споживає кожен байт наявного простору купи.
Шейн Мадден

5
Щоб було зрозуміло, я повністю погоджуюся, що тонко налаштований, масово зайнятий, високопродуктивний сервер баз даних повинен мати власне фізичне обладнання. Але це не є нормою, а інші переваги віртуалізації, як правило, переважують показник ефективності, який не відрізняється від більшості навантажень.
Шейн Мадден

3
Я не згоден з вашою думкою про те, щоб завжди спочатку переходити до існуючих консолідаційних шарів. Іноді це має сенс. Але погляньте, наприклад, на компроміс витрат за відновлення ресурсів між консолідацією декількох баз даних на одній ОС та консолідацією декількох комбінацій баз даних / ОС поверх гіпервізора. Перший - більш ефективний. Друге набагато простіше перебалансувати. Міграція та ОС / база даних на новий хост набагато менш руйнівна, ніж переміщення бази даних на нову ОС.
Джейк Ошинс

Мої коментарі походять від прямих на місцях спостережень за успішною та невдалою міграцією до рішень для віртуалізації за останнє десятиліття як інженера з ефективності. Там є багато поганих додатків для баз даних, розбещені можливості використання апаратних засобів маскують проблеми Додайте віртуалізацію, і ці питання з’являються на світ. Якщо у вас є додаток, який вимагає точного годинника для цілей часу або аудиту, тоді, коли годинник плаває у віртуалізації програмного забезпечення, ви не вдається полювати.
Джеймс Пуллі

1
Нічого собі, Джеймс. Я не маю часу і терпіння, щоб переробити всі пункти, які ви зробили у своїй відповіді та наступних коментарях, але я просто відчув, що мені потрібно тут залишити коментар для тих, хто може статися з цією відповіддю. Погляди Джеймса, власне, його власні, і не відображають того, що справді можливо. Якщо ви переплатили, то, звичайно , будете мати низьку продуктивність. Тому не переписуйте. Цілком можливо створити високоефективне середовище для віртуалізації. Нерозумно скласти проти нього рекомендацію, оскільки вона "погано працює".
EEAA

6

Тут можна усвідомити дві речі:

  • Одиниця продуктивності БД на одиницю апаратного забезпечення дещо нижча для віртуалізованого ДБ. Це означає, що вам потрібно придбати трохи більше обладнання, щоб отримати той же рівень продуктивності.
  • Це не означає, що той самий рівень або бажаний рівень продуктивності недоступний. Вигоди, які ви отримуєте від поліпшеного управління та інших переваг (наприклад, більш легкого НА), часто набагато більше, ніж компенсують незначно збільшені витрати на обладнання.

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


4

Запуск SQL Server - це VM, буде добре, за умови, що ви зможете забезпечити достатню кількість ресурсів для роботи із програмним забезпеченням. Якщо у фізичному світі вам потрібно 24 ядра та 256 Gigs оперативної пам’яті, тоді вам потрібно забезпечити 24 vCPU і 256 Gigs ОЗУ у віртуальному світі.

Я щойно писав статтю в журналах SQL Server за останні місяці про те, як працювати з SQL Server під vSphere VMware.


2

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

База даних PostgreSQL - це база даних для нашого інсценіруючого середовища, і тому вона бачить більш високу ефективність, ніж MySQL db. З цієї причини база даних знаходиться на локальному наборі RAID10, а DRBD реплікується на другий вузол кластера. Однак, з точки зору реального навантаження, ця база постановок взагалі не бачить дуже високого навантаження. Що, на мій погляд, робить доброго / великого кандидата на віртуалізацію.

Однією з переваг для нашої організації було зменшення споживання електроенергії, заощаджений простір у стійці та менша апаратна адміністративна витрата.

З іншого боку, наша основна виробнича база даних не можу уявити собі віртуальний ....


2

Я працюю з MSSQL та MySQL-серверами на багатьох серверах. Пару років тому я вагався почати налаштування SQL-серверів на віртуальних машинах, тому що чув про проблеми з продуктивністю роботи SQL-сервера на VM. Однак я здивувався, коли встановив свою першу пару SQL-серверів і не побачив зміни в продуктивності. Все більше серверів, над якими я працюю, перебувають на VM, і майже всі більші клієнтські підприємства, для яких я працюю, мають віртуалізовані SQL-сервери.

Так, VM додає деякі накладні витрати, і якщо ви збираєтеся розміщувати кілька VM в одному вікні, вам знадобиться хороший приємний сервер. Поширена проблема з ресурсами, на яку слід звернути увагу, - це додавання додаткових віртуальних машин та зменшення доступних ресурсів. Це звичайна практика планувати деякий ріст, але якщо ви купили сервер для розміщення 2 або 3 ВМ і тепер його працює 10 ВМ, ви, ймовірно, будете бачити результативність.

Я б брехав, якби сказав, що жодного разу не бачив проблем із продуктивністю під керуванням SQL-сервера на VM. Але я дізнався, що якщо ви бачите низьку ефективність роботи, напевно, щось не так із оточенням.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.