VMware и базы данных

oMoses · Post by **oMoses** » 24 May 2007 02:28

Последнее время "родные" системщики стали сильно продвигать внедрение virtual machines (VM) вместо традиционных "железных" серверов для баз данных. Поделитесь личными впечатлениями от такого симбиоза (VM & databases)! Как Oracle DBA меня, в первую очередь, интересует комбинация VMware с Oracle9i/10g на любом из UNIX (Linux/Solaris - в частности).

Что может ожидать от подобного решения администратор баз данных? Пока больше всего смущает существенно ограниченная поддержка со стороны Оракла + некоторый performance downgrade.

PavelM · Post by **PavelM** » 24 May 2007 03:01

В текущем проекте из 160 серверов, процентов 60-70 - виртуализированы.
Общие наблюдения:

1. Падение производительности на 20-30 процентов
2. Ощутимые задержки ввода вывода, в т.ч. сетевого
3. Проблемы с некоторыми типами многопотоковых приложений (один веб сервер у нас просто умирал в виртуальной машине, причем не особо нагруженный)
4. Все основные загруженные сервера - файловые, почта, большие базы - все физические.
5. Ограниченная поддержка многими производителями, в стиле "попробуйте воспроизвести проблему на физическом сервере", что не всегда очевидно. Некоторые технологии, хардваре - просто не поддерживаются или не работают.
6. Безопасность - доп. головная боль с защитой данных сидящих в одном файле, причем архитектура безопасности в ESX 2.5 прямо скажем примитивная.
7. Доступность - доп. зависимость от виртуальной инфраструктуры, что м.б. важно если сервер критичен.

Выводы: Vmware хороша чтобы экономить на сотнях мелких серверов которые большую часть времени ничего не делают.

Кстати у Vmware есть тул по анализу парка и планированию переезда, некоторые рекомендации нам были полезны.

0xDEADBEEF · Post by **0xDEADBEEF** » 24 May 2007 03:13

А какая мотивация сего шага в приложении к Ораклу?
В нем самом все что надо вроде есть для разграничения:
1. Можно запустить много инстансов
2. Каждому можно указать сколько потреблять диска и памяти
3. Доступ пользователей к инстансам регламентируется без проблем

То есть... business case что-то не просматривается.

Обычно VMW используют для консолидации web и прочих app серверов. А IO intensive базы данных от такой прослойки только проиграют (много или мало это вопрос) и не получат ничего полезного.

KP580BE51 · Post by **KP580BE51** » 24 May 2007 03:19

PavelM wrote:7. Доступность - доп. зависимость от виртуальной инфраструктуры, что м.б. важно если сервер критичен.

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

0xDEADBEEF · Post by **0xDEADBEEF** » 24 May 2007 03:31

KP580BE51 wrote:Я читал что одно из приемуществ виртуальности - возможность перекидывать виртуальную машину с машины на машину практически без остановки.

Что то я сильно сомневаюсь что она сможет сетевые соединения на клиентах перевесить в другое место без обрыва. И вообще такие фокусы не для серьезных БД.
IMHO в данном случае IT шники "слышали звон"...

PavelM · Post by **PavelM** » 24 May 2007 03:35

KP580BE51 wrote:
PavelM wrote:7. Доступность - доп. зависимость от виртуальной инфраструктуры, что м.б. важно если сервер критичен.

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

Есть такое - Vmotion
Для этого надо иметь соответствующую лицензию и инфраструктуру - SAN и т.п. По наблюдениям - работает не всегда гладко.

PavelM · Post by **PavelM** » 24 May 2007 03:42

0xDEADBEEF wrote:IMHO в данном случае IT шники "слышали звон"...

У Vmware очень сильный маркетинг, поэтому не удивительно.
Многие "IT шники" даже не всегда понимают как оно работает унутре, так что иногда песни продавцов Вмваре перепеваются слаженным хором. :lol:

На деле же все не так розово, продукты сыроваты и надо тестировать.
Чисто для примера, Вмваре выпускает несколько релизов в год и насколько мне известно сильно ограничивает поддержку старых релизов. Т.о. в ходе проекта мы уже сменили 2 версии ESX. Согласитесь частая замена менеджера вртуальных машин - операция не из пустяковых.

DP · Post by DP » 24 May 2007 03:45

спросите ник dB13 ( http://forum.privet.com/profile.php?mod ... ile&u=4636 ) - он в VMWare работает.

тьфу-тьфу, сгинь нечистая сила - сделал 666 постов и "13" опять же... надо бы забанить от греха подальше.

KP580BE51 · Post by **KP580BE51** » 24 May 2007 03:47

PavelM wrote:Есть такое - Vmotion
Для этого надо иметь соответствующую лицензию и инфраструктуру - SAN и т.п. По наблюдениям - работает не всегда гладко.

Я про XEN читал.
http://en.wikipedia.org/wiki/Xen

dB13 · Post by **dB13** » 24 May 2007 09:30

PavelM wrote:У Vmware очень сильный маркетинг...

I wish it were true ...

Dmitry67 · Post by **Dmitry67** » 24 May 2007 09:32

Если кто запустит SQL server под VMware то пусть и сам его оптимизирует
Целая эпоха оптимизации файловых операций на низком уровне - и в помойку :angry:

KP580BE51 · Post by **KP580BE51** » 24 May 2007 09:38

Dmitry67 wrote:Если кто запустит SQL server под VMware то пусть и сам его оптимизирует
Целая эпоха оптимизации файловых операций на низком уровне - и в помойку

А какие проблемы vmware отдать физический раздел диска? У меня оно винду с /dev/hda1 пускает.

ЗЫ, никто не знает как ему запретить лезть на остальные разделы? Чтобы MBR был доступен как RO, /dev/hda1/ как RW, а остальные доступны не были, или как RO?

Dmitry67 · Post by **Dmitry67** » 24 May 2007 10:11

Я плохо понимаю в таких кернельных штучках, но SQL server использует какие то особенные операции IO, которые идут мимо кеша Windows, например. Известно, что можно выиграть сколько то процентов, если использовать Raw (unformatted) disks. (Хоть это и делают редко)

То есть общая идея - уменьшить количество слоев между SQL server и диском. VMware добавляет же уровень, и еще какой ! Вот скажите, пусть система внутри VMware читает страницу. Это транслировалось в физическое чтение на физическом компьютере. Будет ли он это кешировать? ЧТо происходит с длинными чтениями подряд? Он ведь в ряде случаев должен их рубить. Ну итд

Да, сейчас многое меняется, многие аксиомы баз данных начинают терять смысл. Увы, накручивают желехзо и не думают вообще. Сколько я видел серверов с памятью 8-16Gb, где пашет sql server без AWE 2gb) - а остальное неиспользуется вообще.

Или вкладывают для OLTP систем деньги в SAN EMC подобные системы, и производительность по writes оказывается такой же, как у моего ноутбука. Но как же, все ставят SAN. "we are inside the car - we are safe" (c)

KP580BE51 · Post by **KP580BE51** » 24 May 2007 10:16

Dmitry67 wrote:То есть общая идея - уменьшить количество слоев между SQL server и диском. VMware добавляет же уровень, и еще какой ! Вот скажите, пусть система внутри VMware читает страницу. Это транслировалось в физическое чтение на физическом компьютере. Будет ли он это кешировать? ЧТо происходит с длинными чтениями подряд? Он ведь в ряде случаев должен их рубить. Ну итд

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

Если длинное чтение и подряд то будет читаться, учитывая шедулер итд.

0xDEADBEEF · Post by **0xDEADBEEF** » 24 May 2007 13:26

Dmitry67 wrote:Или вкладывают для OLTP систем деньги в SAN EMC подобные системы, и производительность по writes оказывается такой же, как у моего ноутбука. Но как же, все ставят SAN. "we are inside the car - we are safe" (c)

Ага. Точно. Просто эпидемия какая-то. Унификация операций етить...

Привет

VMware и базы данных

VMware и базы данных

Re: VMware и базы данных