VMware и базы данных
-
- Уже с Приветом
- Posts: 1255
- Joined: 01 Jun 1999 09:01
- Location: Irkutsk.RU -> Hamden, CT-> Princeton, NJ, USA
VMware и базы данных
Последнее время "родные" системщики стали сильно продвигать внедрение virtual machines (VM) вместо традиционных "железных" серверов для баз данных. Поделитесь личными впечатлениями от такого симбиоза (VM & databases)! Как Oracle DBA меня, в первую очередь, интересует комбинация VMware с Oracle9i/10g на любом из UNIX (Linux/Solaris - в частности).
Что может ожидать от подобного решения администратор баз данных? Пока больше всего смущает существенно ограниченная поддержка со стороны Оракла + некоторый performance downgrade.
Что может ожидать от подобного решения администратор баз данных? Пока больше всего смущает существенно ограниченная поддержка со стороны Оракла + некоторый performance downgrade.
[b]"Счастье для всех, даром, и пусть никто не уйдет обиженный!"[/b]
[i]А. и Б. Стругацкие, "Пикник на обочине"[/i]
[i]А. и Б. Стругацкие, "Пикник на обочине"[/i]
-
- Уже с Приветом
- Posts: 13316
- Joined: 13 Jun 1999 09:01
- Location: Yekaterinburg -> Montreal
В текущем проекте из 160 серверов, процентов 60-70 - виртуализированы.
Общие наблюдения:
1. Падение производительности на 20-30 процентов
2. Ощутимые задержки ввода вывода, в т.ч. сетевого
3. Проблемы с некоторыми типами многопотоковых приложений (один веб сервер у нас просто умирал в виртуальной машине, причем не особо нагруженный)
4. Все основные загруженные сервера - файловые, почта, большие базы - все физические.
5. Ограниченная поддержка многими производителями, в стиле "попробуйте воспроизвести проблему на физическом сервере", что не всегда очевидно. Некоторые технологии, хардваре - просто не поддерживаются или не работают.
6. Безопасность - доп. головная боль с защитой данных сидящих в одном файле, причем архитектура безопасности в ESX 2.5 прямо скажем примитивная.
7. Доступность - доп. зависимость от виртуальной инфраструктуры, что м.б. важно если сервер критичен.
Выводы: Vmware хороша чтобы экономить на сотнях мелких серверов которые большую часть времени ничего не делают.
Кстати у Vmware есть тул по анализу парка и планированию переезда, некоторые рекомендации нам были полезны.
Общие наблюдения:
1. Падение производительности на 20-30 процентов
2. Ощутимые задержки ввода вывода, в т.ч. сетевого
3. Проблемы с некоторыми типами многопотоковых приложений (один веб сервер у нас просто умирал в виртуальной машине, причем не особо нагруженный)
4. Все основные загруженные сервера - файловые, почта, большие базы - все физические.
5. Ограниченная поддержка многими производителями, в стиле "попробуйте воспроизвести проблему на физическом сервере", что не всегда очевидно. Некоторые технологии, хардваре - просто не поддерживаются или не работают.
6. Безопасность - доп. головная боль с защитой данных сидящих в одном файле, причем архитектура безопасности в ESX 2.5 прямо скажем примитивная.
7. Доступность - доп. зависимость от виртуальной инфраструктуры, что м.б. важно если сервер критичен.
Выводы: Vmware хороша чтобы экономить на сотнях мелких серверов которые большую часть времени ничего не делают.
Кстати у Vmware есть тул по анализу парка и планированию переезда, некоторые рекомендации нам были полезны.
-
- Уже с Приветом
- Posts: 1811
- Joined: 22 Jul 2004 14:00
Re: VMware и базы данных
А какая мотивация сего шага в приложении к Ораклу?
В нем самом все что надо вроде есть для разграничения:
1. Можно запустить много инстансов
2. Каждому можно указать сколько потреблять диска и памяти
3. Доступ пользователей к инстансам регламентируется без проблем
То есть... business case что-то не просматривается.
Обычно VMW используют для консолидации web и прочих app серверов. А IO intensive базы данных от такой прослойки только проиграют (много или мало это вопрос) и не получат ничего полезного.
В нем самом все что надо вроде есть для разграничения:
1. Можно запустить много инстансов
2. Каждому можно указать сколько потреблять диска и памяти
3. Доступ пользователей к инстансам регламентируется без проблем
То есть... business case что-то не просматривается.
Обычно VMW используют для консолидации web и прочих app серверов. А IO intensive базы данных от такой прослойки только проиграют (много или мало это вопрос) и не получат ничего полезного.
-
- Уже с Приветом
- Posts: 15007
- Joined: 14 Jun 2005 11:50
- Location: Ukraine
-
- Уже с Приветом
- Posts: 1811
- Joined: 22 Jul 2004 14:00
KP580BE51 wrote:Я читал что одно из приемуществ виртуальности - возможность перекидывать виртуальную машину с машины на машину практически без остановки.
Что то я сильно сомневаюсь что она сможет сетевые соединения на клиентах перевесить в другое место без обрыва. И вообще такие фокусы не для серьезных БД.
IMHO в данном случае IT шники "слышали звон"...
-
- Уже с Приветом
- Posts: 13316
- Joined: 13 Jun 1999 09:01
- Location: Yekaterinburg -> Montreal
KP580BE51 wrote:PavelM wrote:7. Доступность - доп. зависимость от виртуальной инфраструктуры, что м.б. важно если сервер критичен.
Я читал что одно из приемуществ виртуальности - возможность перекидывать виртуальную машину с машины на машину практически без остановки.
Есть такое - Vmotion
Для этого надо иметь соответствующую лицензию и инфраструктуру - SAN и т.п. По наблюдениям - работает не всегда гладко.
-
- Уже с Приветом
- Posts: 13316
- Joined: 13 Jun 1999 09:01
- Location: Yekaterinburg -> Montreal
0xDEADBEEF wrote:IMHO в данном случае IT шники "слышали звон"...
У Vmware очень сильный маркетинг, поэтому не удивительно.
Многие "IT шники" даже не всегда понимают как оно работает унутре, так что иногда песни продавцов Вмваре перепеваются слаженным хором.
На деле же все не так розово, продукты сыроваты и надо тестировать.
Чисто для примера, Вмваре выпускает несколько релизов в год и насколько мне известно сильно ограничивает поддержку старых релизов. Т.о. в ходе проекта мы уже сменили 2 версии ESX. Согласитесь частая замена менеджера вртуальных машин - операция не из пустяковых.
-
- Уже с Приветом
- Posts: 17361
- Joined: 24 Jan 1999 10:01
- Location: Pittsburgh, PA, USA
спросите ник dB13 ( http://forum.privet.com/profile.php?mod ... ile&u=4636 ) - он в VMWare работает.
тьфу-тьфу, сгинь нечистая сила - сделал 666 постов и "13" опять же... надо бы забанить от греха подальше.
тьфу-тьфу, сгинь нечистая сила - сделал 666 постов и "13" опять же... надо бы забанить от греха подальше.
Last edited by DP on 24 May 2007 03:47, edited 1 time in total.
-
- Уже с Приветом
- Posts: 15007
- Joined: 14 Jun 2005 11:50
- Location: Ukraine
PavelM wrote:Есть такое - Vmotion
Для этого надо иметь соответствующую лицензию и инфраструктуру - SAN и т.п. По наблюдениям - работает не всегда гладко.
Я про XEN читал.
http://en.wikipedia.org/wiki/Xen
-
- Уже с Приветом
- Posts: 1494
- Joined: 08 May 2001 09:01
- Location: Silicon Valley
-
- Уже с Приветом
- Posts: 28283
- Joined: 29 Aug 2000 09:01
- Location: SPB --> Gloucester, MA, US --> SPB --> Paris
-
- Уже с Приветом
- Posts: 15007
- Joined: 14 Jun 2005 11:50
- Location: Ukraine
Dmitry67 wrote:Если кто запустит SQL server под VMware то пусть и сам его оптимизирует
Целая эпоха оптимизации файловых операций на низком уровне - и в помойку
А какие проблемы vmware отдать физический раздел диска? У меня оно винду с /dev/hda1 пускает.
ЗЫ, никто не знает как ему запретить лезть на остальные разделы? Чтобы MBR был доступен как RO, /dev/hda1/ как RW, а остальные доступны не были, или как RO?
-
- Уже с Приветом
- Posts: 28283
- Joined: 29 Aug 2000 09:01
- Location: SPB --> Gloucester, MA, US --> SPB --> Paris
Я плохо понимаю в таких кернельных штучках, но 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)
То есть общая идея - уменьшить количество слоев между SQL server и диском. VMware добавляет же уровень, и еще какой ! Вот скажите, пусть система внутри VMware читает страницу. Это транслировалось в физическое чтение на физическом компьютере. Будет ли он это кешировать? ЧТо происходит с длинными чтениями подряд? Он ведь в ряде случаев должен их рубить. Ну итд
Да, сейчас многое меняется, многие аксиомы баз данных начинают терять смысл. Увы, накручивают желехзо и не думают вообще. Сколько я видел серверов с памятью 8-16Gb, где пашет sql server без AWE 2gb) - а остальное неиспользуется вообще.
Или вкладывают для OLTP систем деньги в SAN EMC подобные системы, и производительность по writes оказывается такой же, как у моего ноутбука. Но как же, все ставят SAN. "we are inside the car - we are safe" (c)
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
-
- Уже с Приветом
- Posts: 15007
- Joined: 14 Jun 2005 11:50
- Location: Ukraine
Dmitry67 wrote:То есть общая идея - уменьшить количество слоев между SQL server и диском. VMware добавляет же уровень, и еще какой ! Вот скажите, пусть система внутри VMware читает страницу. Это транслировалось в физическое чтение на физическом компьютере. Будет ли он это кешировать? ЧТо происходит с длинными чтениями подряд? Он ведь в ряде случаев должен их рубить. Ну итд
Если гостевой системе отдать просто раздел диска, то как я понимаю он ничего не кеширует. Гостевая система сама работает с диском и данными на нем.
Если длинное чтение и подряд то будет читаться, учитывая шедулер итд.
-
- Уже с Приветом
- Posts: 1811
- Joined: 22 Jul 2004 14:00
-
- Уже с Приветом
- Posts: 13316
- Joined: 13 Jun 1999 09:01
- Location: Yekaterinburg -> Montreal
dB13 wrote:PavelM wrote:У Vmware очень сильный маркетинг...
I wish it were true ...
Не знаю как изнутри, а снаружи создается именно такое впечатление из-за:
1. Встреченного числа "одурманеных" виртуализацией всего
и вся, без малейшего понимания сути и соотв. затрат.
2. Не всегда добросовестной рекламы, н-р ESX подается под девизом "mainframe-class control on Intel servers", "mainframe-style partitioning" - что честно говоря откровенное вранье. Или реклама такого продукта как ACE подаваемого как "security solution", чья концепция безопасности ущербна изначально. Всякие спекуляции с TCO и т.п. Отказ предоставить сертификации по безопасности несмотря на упоминания таковых сертификаций в рекламе и т.п.
3. Что совсем смешно, отрицание возможности софтовых багов в менеджере виртуализации и вытекающих проблем.
и т.п.
Может слово "сильный" для маркетинга тут не очень, но эффект на лицо - " народ валом валит на картину".
-
- Уже с Приветом
- Posts: 2424
- Joined: 02 Feb 2007 03:59
- Location: USA
dB13 wrote:PavelM wrote:У Vmware очень сильный маркетинг...
I wish it were true ...
Ну я не знаю, но только наблюдаю ситуацию "Заставь дурака богу молиться -- он и лоб расшибёт."...
Наткнулась на ситуацию, когда один из Production SQL серверов и его fall over SQL server оба Virtual machines -- находятся на ОДНОЙ и той же физической машине...
Я обожаю Virtual machines, когда могу осчастливить QA можеством testing environments refreshed on demand
-
- Уже с Приветом
- Posts: 63377
- Joined: 03 Nov 2004 05:31
- Location: RU -> Toronto, ON
Dmitry67 wrote:Я плохо понимаю в таких кернельных штучках, но SQL server использует какие то особенные операции IO, которые идут мимо кеша Windows, например. Известно, что можно выиграть сколько то процентов, если использовать Raw (unformatted) disks. (Хоть это и делают редко)
не верю приведите ссылку.
я могу поверить что, к примеру, заводится какой-нибудь кэш в памяти с залоченными страничками, и через него идет быстрый обмен с более медленной файловой системой, но чтобы делать file system bypass, это 100% гарантия получить нестабильную систему.
-
- Уже с Приветом
- Posts: 63377
- Joined: 03 Nov 2004 05:31
- Location: RU -> Toronto, ON
PavelM wrote:3. Что совсем смешно, отрицание возможности софтовых багов в менеджере виртуализации и вытекающих проблем.
вот даже так? совсем недавно в руки попала статья об исследовании проблемы "синей и красной таблетки" с разными виртуализаторами, и как их можно эффективно валить их и выполнять произвольный код на реальном хосте из виртуализованного приложения. VMWare был в их числе.
-
- Уже с Приветом
- Posts: 28283
- Joined: 29 Aug 2000 09:01
- Location: SPB --> Gloucester, MA, US --> SPB --> Paris
Flash-04 wrote:не верю приведите ссылку.
я могу поверить что, к примеру, заводится какой-нибудь кэш в памяти с залоченными страничками, и через него идет быстрый обмен с более медленной файловой системой, но чтобы делать file system bypass, это 100% гарантия получить нестабильную систему.
File system bypass делается для Raw devices:
Из BOL:
Using Raw Partitions
Microsoft® SQL Server™ 2000 supports the use of raw partitions for creating database files. Raw partitions are disk partitions that have not been formatted with a Microsoft Windows NT® file system, such as FAT and NTFS. In some cases, using databases created on raw partitions can yield a slight performance gain over NTFS or FAT. However, for most installations the preferred method is to use files created on NTFS or FAT partitions.
Что касается обычных партиций, то он работает через fily system, но использует какие то особые команды. Я в этом плохо понимаю. Какой то бит writethru или чтото такое. Короче, все эти чтения идет помимо кэша файловой системы (но не помимо файловой системы).
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
-
- Уже с Приветом
- Posts: 18862
- Joined: 30 Aug 2001 09:01
- Location: 3rd planet
-
- Уже с Приветом
- Posts: 63377
- Joined: 03 Nov 2004 05:31
- Location: RU -> Toronto, ON
-
- Уже с Приветом
- Posts: 15007
- Joined: 14 Jun 2005 11:50
- Location: Ukraine
Boriskin wrote:А я вот чего не понимаю - зачем ставить продакшн сервер на VM, когда можно достаточно дешево купить нормальную тачку и иметь stand-alone сервак на ней... Минимизация server-racks и охлаждения оных чтоль?
Когда серверов много, когда загрузка низкая итд. Кроме того в идиале оно как я понял движется к полной виртуализации в виде когда к примерк 1000 серверов крутится на клястере из 300 компютеров, которые можно по необходимости включать/выключать, апгрейдеть итд.
-
- Уже с Приветом
- Posts: 1255
- Joined: 01 Jun 1999 09:01
- Location: Irkutsk.RU -> Hamden, CT-> Princeton, NJ, USA
Мои худшие подозрения оправдываются.PavelM wrote:В текущем проекте из 160 серверов, процентов 60-70 - виртуализированы.
Общие наблюдения:
1. Падение производительности на 20-30 процентов
2. Ощутимые задержки ввода вывода, в т.ч. сетевого
3. Проблемы с некоторыми типами многопотоковых приложений (один веб сервер у нас просто умирал в виртуальной машине, причем не особо нагруженный)
4. Все основные загруженные сервера - файловые, почта, большие базы - все физические.
5. Ограниченная поддержка многими производителями, в стиле "попробуйте воспроизвести проблему на физическом сервере", что не всегда очевидно. Некоторые технологии, хардваре - просто не поддерживаются или не работают.
6. Безопасность - доп. головная боль с защитой данных сидящих в одном файле, причем архитектура безопасности в ESX 2.5 прямо скажем примитивная.
7. Доступность - доп. зависимость от виртуальной инфраструктуры, что м.б. важно если сервер критичен.
Спасибо...
Про базы мои системщики беспокояться в последнею очередь. Им места в data room не хватает, провода заели... Но реально об этом не говорят, а кивают на better manageability and flexibility.0xDEADBEEF wrote:А какая мотивация сего шага в приложении к Ораклу?
...
То есть... business case что-то не просматривается.
Понимаю о чем ты, Дима. Сочувствую...Dmitry67 wrote:Если кто запустит SQL server под VMware то пусть и сам его оптимизирует
Целая эпоха оптимизации файловых операций на низком уровне - и в помойку
И это - тоже...Boriskin wrote:Минимизация server-racks и охлаждения оных чтоль?
[b]"Счастье для всех, даром, и пусть никто не уйдет обиженный!"[/b]
[i]А. и Б. Стругацкие, "Пикник на обочине"[/i]
[i]А. и Б. Стругацкие, "Пикник на обочине"[/i]
-
- Уже с Приветом
- Posts: 1494
- Joined: 08 May 2001 09:01
- Location: Silicon Valley
0xDEADBEEF wrote:KP580BE51 wrote:Я читал что одно из приемуществ виртуальности - возможность перекидывать виртуальную машину с машины на машину практически без остановки.
Что то я сильно сомневаюсь что она сможет сетевые соединения на клиентах перевесить в другое место без обрыва. И вообще такие фокусы не для серьезных БД.
Может-может:
http://www.vmware.com/products/vi/vc/vm ... rview.html
http://www.vmware.com/pdf/usenix_vmotion.pdf
In order for a migration to be transparent
all network connections that were open before a
migration must remain open after the migration
completes. The VMware ESX Server virtual
networking architecture makes this possible.
A virtual Ethernet network interface card (VNIC) is
provided as part of the virtual platform. Like a physical
NIC, the VNIC has a MAC address that uniquely
identifies it on the local network. Each VNIC is
associated with one or more physical NICs that are
managed by the vmkernel. The VNICs of many VMs
can be attached to the same physical NIC.
Since each VNIC has its own MAC address that is
independent of the physical NIC’s MAC address,
virtual machines can be moved while they are running
between machines and still keep network connections
alive as long as the new machine is attached to the same
subnet as the original machine.