Что собой представляет Oracle VM?

Виртуал бокс конечно же
Есть готовые образы, я там СУБД Oracle палочкой тыкаю

Ага. Меня DBA спросили что мы (амины) можем им предоставить виртуального сертифицированное ораклом, а в списке вирт. платформ только Oracle VM

Oracle VM — система виртуализации от Oracle, построенная на базе Xen. В качестве операционной системы домена 0 могут использоваться Oracle Enterprise Linux или RedHat Enterprise Linux. В гостевых системах могут работать те же системы, что и в обычном Xen. В состав Oracle VM входят: Oracle VM Manager Oracle VM Server

Ага. Меня DBA спросили что мы (амины) можем им предоставить виртуального сертифицированное ораклом, а в списке вирт. платформ только Oracle VM

vSphere ? oracle СУБД отлично работает под RHEL.

Можно запускать и OL, но от этой какашки лучше держаться подальше, часто появляются проблемы.

Мне кажется, или тут все обсуждают, как круто ставить БД на виртуалки?

А чем не круто? Уже года 4 минимум отлично работают

для разработки или практики - это самый верный путь

Потеря производительности на прослойке, сильное влияние других виртуалок. А плюсов от виртуализации толком и не получаем.

Конечно работать она будет. Но боевые базы на виртуалках держат только фанатики.

Мне кажется, или тут все обсуждают, как круто ставить БД на виртуалки?

Я тебя расстрою - ты проспал в криокамере слишком долго, ибо уже давно БД ставят на виртуалки или в контейнеры (зоны).

Конечно работать она будет. Но боевые базы на виртуалках держат только фанатики.

Ставят их на осноную ось для разработок только фанатики.

ибо уже давно БД ставят на виртуалки или в контейнеры (зоны).

И меня пожалуйста разморозьте какими-то вменяемыми фактами или факторами

Потеря производительности на прослойке,

У вас таки все БД - труЪ интырпрайз и жрут 100 % всех cpu p7 24/7/365 ? Оценивается производительность. Если её хватает - используем ВМ.

сильное влияние других виртуалок.

По-моему кто-то знаком с виртуализацией только по рассказам неудачников.

А плюсов от виртуализации толком и не получаем.

Если ты о них не знаешь - не используей виртуализацию :D

Зоны-то ладно. Там в локальную зону настоящее железо торчит :)

Но смысла делить мощности между базой и кем-то ещё я не вижу. Базы обычно самые жрущие и критичные.

А какие, собсно, плюсы от БД на виртуалке?

Зоны-то ладно.

Вот как раз зоны ИМХО неудачный вариант, т.к. действительно будет влияние производительности одной зоны на другую.

Там в локальную зону настоящее железо торчит :)

Соглашусь с no-dashi. Ты слишком долго проспал. В ESX процессор не виртуализуется. В KVM и Xen кстати тоже - если процессор с аппаратной поддержкой виртуализации

По-моему кто-то знаком с виртуализацией только по рассказам неудачников.

Ну, может наши виртуализаторы плохо старались. Или vmware (боже, спаси) для этих целей не подходит.

У вас таки все БД - труЪ интырпрайз и жрут 100 % всех cpu p7 24/7/365 ? Оценивается производительность. Если её хватает - используем ВМ.

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

А если на один сервер накатить KVM и откусить от базы пару гигов памяти и пару процессоров - пожалуйста. Только польза от такого дела сомнительная. Можешь приведёшь в пример более полезное применение?

Вот как раз зоны ИМХО неудачный вариант, т.к. действительно будет влияние производительности одной зоны на другую.

Я даже с KVM не доверю шарить базу с чем-то ресурсоёмким. Хоть там «у каждого свой процессор», косвенное влияние есть. Уже не раз сталкивался с неприятными мелочами.

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

Может напоследок накидаете показательные примеры высоконагруженных баз, крутящихся на виртуалках?

router no-dashi

Ну, может наши виртуализаторы плохо старались. Или vmware (боже, спаси) для этих целей не подходит.

Чем меньше знаешь ты - тем выше моя зарплата.

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

незнание принципов работы DRS ( если мы говорим о vmware vSphere )

Это как правило хорошо не заканчивается.

Незнание принципа работы vmotion

А если на один сервер накатить KVM и откусить от базы пару гигов памяти и пару процессоров - пожалуйста.

Гонять на одном хосте и БД в host системе, и виртуалки? Крайне сомнительно и попахивает нездоровой психикой

Можешь приведёшь в пример более полезное применение?

Гипервизоры стоят на голом железе. Все прикладные задачи - в ВМ. Все диски - SAN. Имеем всё то, что обещают маркетоиды. Повышение доступности, снижение времени даунтайма, рациональное использование ресурсов. При желании - отказоустойчивость.

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

А я видел профессоналов, у которых не создают проблем. Если руки из жопы и ничего не хочешь знать - проблемы будут.

Может напоследок накидаете показательные примеры высоконагруженных баз, крутящихся на виртуалках?

Гугл спроси. Ещё раз: фанатизм неуместен. Решение задачи выбирается исходя из ТЗ.

Какой-то поток неадеквата. Ты вообще не понимаешь, о чём я сейчас говорил.

Так. Давай-ка сначала. Я НЕ занимаюсь виртуализацией. Я вижу проблемы с базами на виртуалках. Я пытаюсь понять, а что же мы получаем за лишний слой абстракции (который в принципе не может сделать базу более производительной)? Тут приходишь ты, говоришь что у меня руки из жопы и что я ничего не хочу знать.

Пока-пока.

Я пытаюсь понять, а что же мы получаем за лишний слой абстракции

я уже сказал - абстрагирование от реального железа.

* выход из строя сервера с точки зрения ВМ - просто сбой по питанию. И ВМ запустится на другом сервер кластера автоматом.

* возможность создания fault tolerance ВМ. Отказ одного сервера она даже не заметит

* возможность назначить столько ресурсов, сколько реально потребляется. А остальные пустить на ВМ с другой БД, с технологическими сервисами и пр.

* возможность быстрого создания клона

* возможность создания точек отката ( snapshot'ов ). Создал, установил патчи на БД. Не понравилось - откатил снапшот.

Тут приходишь ты, говоришь что у меня руки из жопы и что я ничего не хочу знать.

Пока я говорил не лично про тебя, но раз ты настаиваешь ... :)

Пока-пока.

Скатертью по жопе

вменяемыми фактами

Ээээ, извини - но рассказ о том какие решения используются в каких компаниях это часто NDA. Но если хочется примеров каких-нибудь - http://www.vmware.com/solutions/business-critical-apps/oracle-virtualization/...

или факторами

Простота обслуживания, масштабирование по требованию, унификация. Например, можно сделать бездаунтаймовую миграцию, легкая замена и апгрейд оборудования и т.п.

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

Потому, потери на виртуализацию составляют 5-10% (в худшем случае), а типичная проблема производительности БД решается оптимизациями запросов с приростом в 150-1500%.

Кроме того, в случае БД под виртуалкой намного легче например апгредйнуть железо при необходимости.

Я НЕ занимаюсь виртуализацией.
Я вижу проблемы с <...> на виртуалках.

взаимоисключающие параграфы соблюдены, чо.. ;)

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

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

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

все это конечно в случае больших ДЦ а не на коленке в подвале, где база спокойно может отожрать все ресурсы самосборного пентиума

Oracle VM — система виртуализации от Oracle, построенная на базе Xen

virtualbox на базе xen?

В ESX процессор не виртуализуется. В KVM и Xen кстати тоже - если процессор с аппаратной поддержкой виртуализации

еще как виртуализируется. просто в ВМ пробрасываются фичеры железного процессора, все что виртуальный процессор не способен отработать превращается в vmexit, и через память уходит на обработку хосту.

где то это сделано совсем через задницу (привет Xen) где то не через задницу, но планировщик сам по себе дебильный (привет esx), но прямого проброса процессора в ВМ нет - все ВМ, если их не прибить гвоздями к определенному набору ядер, делятся между собой временем обработки

как круто ставить БД на виртуалки?

DBA нужно что-то обкатать, но при этом платформа должна быть официально поддерживаемой Ораклом иначе не будет тех. поддержки от Оракла.

Нет, ты не в теме. В ESX процессор не виртуализуется, ВМ получают доступ к реальному физическому ядру процессора. Но этот доступ ограничивается: либо используется аппаратная виртуализация, либо вытеснение гостевой ОС из ring 0

Мы говорим о разных вещах. Я имел в виду что процессор никак не эмулируется ( о отличие от QEMU-KVM, например ), а не о том что ВМ получает процессор в единоличное пользование

Я НЕ занимаюсь виртуализацией.

Напрасно. В данное время очень актуально и почти необходимо.
Даже для маленьких конторок.

* выход из строя сервера с точки зрения ВМ - просто сбой по питанию. И ВМ запустится на другом сервер кластера автоматом.

Выход из строя сервера - это и так «просто сбой по питанию». Именно этот, самый банальный «просто сбой по питанию» часто заставляет DBA срать кирпичами. Ничего не мешает автоматом запускать инстанс базы на другой железке когда первая упадет, ну за исключением страшной корявости решения. Иногда лучше сломаться и лежать, чем запускать что то автоматом.

* возможность создания fault tolerance ВМ. Отказ одного сервера она даже не заметит

А какой оверхед будет для этого самого fault tolerance учитывая что нужно синхронизировать память? В 100% случаях синхронная master-slave репликация средствами базы, со сменой мастера по аварии будет производительнее.

* возможность создания точек отката ( snapshot'ов ). Создал, установил патчи на БД. Не понравилось - откатил снапшот

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

Вобщем для нагруженных баз не особо много пользы от виртуализации.

Напрасно. В данное время очень актуально и почти необходимо.

Даже для маленьких конторок.

Перефразирую. Виртуализацией занимаюсь не я.

взаимоисключающие параграфы соблюдены, чо.. ;)

См. выше

У вас таки все БД - труЪ интырпрайз и жрут 100 % всех cpu p7 24/7/365 ? Оценивается производительность. Если её хватает - используем ВМ.

Так как раз в рекламных презенташках и пишут. Ничего что в какой то момент времени из за Leap second переклинит какой то mysql в соседней виртуалке или вдруг кто то на диск начнет писать. И тут как раз ваша вроде нагруженная по top в 10% OLTP база начнет запросы в 10 раз медленнее обрабатывать, а есть вещи которые просто по таймауту отваливаться начнут из-за увеличения задержки. Количество сессий к базе подпрыгнет, и процессор резко начнет использоваться больше.

В ESX процессор не виртуализуется, ВМ получают доступ к реальному физическому ядру процессора. Но этот доступ ограничивается: либо используется аппаратная виртуализация, либо вытеснение гостевой ОС из ring 0

вообще-то я очень в теме :) vmware использует binary translation когда нет расширений процессора, и HAV когда есть, так же как и Xen с HVM и KVM.

во всех решениях, принцип одинаковый - VT/AMD-V позволяет прямой доступ к набору инструкций процессора, а все запросы которые вне этих инструкций выполняются эмулятором или PV-девайсом.

Я имел в виду что процессор никак не эмулируется ( о отличие от QEMU-KVM, например )

а где в KVM эмулируется процессор? основная разница между KVM и VMKernel в том что в KVM виртуальный процессор для хоста просто процесс ядра, с особым доступом к определенному набору железа, и этим процессом управляет планировщик линукса, а в vmkernel планировщик свой, и процессы сгруппированы (gang scheduling, если совсем конкретно терминологию подбирать). Именно поэтому, если дать ВМ в ESXi 16 виртуальных ядер, и поставить в нее DOS, то несмотря на то что системе нужен только один процессор, хост не сможет дать этой ВМ время исполнения пока у него не появится слот с 16-ю свободными физическими ядрами. С KVM таких странностей нет (почему KVM давно на первых местах во всех тестах specvirt, a vmware перестали публиковать результаты)

вообще-то я очень в теме

ладно, это я неудачно выразился :)

а где в KVM эмулируется процессор?

в qemu-kvm, если используется выбрана другая архитектура ( например, arm ). Qemu будет эмулировать процессор целевой платформы, а esx/xen/kvm - предоставлять ограниченный доступ, но к реальному физическому ядру

Ничего что в какой то момент времени из за Leap second переклинит какой то mysql в соседней виртуалке или вдруг кто то на диск начнет писать.

Решение: выгнать ламеров, нанять профессионалов. Не использовать псевдовиртуализацию типа jail/containers , не пользоваться VPS

Нормальные системы виртуализации, при грамотной настройке, не допустят такого. В esx'ах можно гарантировать гостю определённо число процессорного времени ( reservation ), ограничить максимальное потребление ( limit ), а если limit больше reservation и есть несколько претендентов, ресурсы раздаются в соответствии с приоритетом ( shares )

Выход из строя сервера - это и так «просто сбой по питанию». Именно этот, самый банальный «просто сбой по питанию» часто заставляет DBA срать кирпичами. Ничего не мешает автоматом запускать инстанс базы на другой железке когда первая упадет, ну за исключением страшной корявости решения. Иногда лучше сломаться и лежать, чем запускать что то автоматом.

Необходимость бекапов - это отдельный разговор. Если не идёт постоянный бекап арклогов - это полный абзац и виртуализация ни при чём.

Виртуализация даёт тот плюс, что не нужно БЫСТРО решить проблему с оборудованием, пока благодарные пользватели матерят админа.

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

Именно корявости решения и плюс - наличия этого резервного оборудования. Цена резервирования в виртуальной инфраструктуре существенно ниже, т.к. эти «лишние» ресурсы резервируют существенно бОльшее число сервисов.

А какой оверхед будет для этого самого fault tolerance учитывая что нужно синхронизировать память? В 100% случаях синхронная master-slave репликация средствами базы, со сменой мастера по аварии будет производительнее.

Большой оверхед и плюс дополнительный линк / линки от гигабита и выше. Для хорошей БД ценность fault tolerance сомнительна, а для ПО которое не умеет кластеризоваться - существенно выше.

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

Странно слышать это от ДБА. База закрывается от пользователей, проводятся работы. Но в случае ВМ и snapshot'ов откат патча займёт существенно меньше времени, чем переустановка либо архивирование/разархивирование. И гораздо «дешевле» с точки зрения времени админа.

в qemu-kvm, если используется выбрана другая архитектура ( например, arm ). Qemu будет эмулировать процессор целевой платформы

верно, только это не qemu-kvm а qemu

kvm работает только с расширениями виртуализации, и пакет qemu-kvm это qemu в котором процесорную эмуляцию убрали и заменили на KVM. я к тому что это два разных пакета и два разных подхода, qemu != qemu-kvm

Oracle VM. Not to be confused with Oracle VM VirtualBox.

Виртуализация даёт тот плюс, что не нужно БЫСТРО решить проблему с оборудованием, пока благодарные пользватели матерят админа.

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

База закрывается от пользователей, проводятся работы. Но в случае ВМ и snapshot'ов откат патча займёт существенно меньше времени, чем переустановка либо архивирование/разархивирование.

Не всегда приемлемо закрывать базы от пользоватетей. А если downtime допустим - тут хоть lvm юзайте для снапшотов, тк снапшот виртуалки и не нужен. Польза таким образом нулевая от виртуализации в этом случае.

Необходимость бекапов - это отдельный разговор. Если не идёт постоянный бекап арклогов - это полный абзац и виртуализация ни при чём.

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

Цена резервирования в виртуальной инфраструктуре существенно ниже, т.к. эти «лишние» ресурсы резервируют существенно бОльшее число сервисов.

Так я вам про то и говорю - виртуализация это попытка мультиплексирования оборудования. Цена ниже, только и качество страдает. А базы данных весьма требовательны к качеству. Так что единственный плюс - экономия денег и то в случае множества легких виртуальных машин. Потому как в случае когда утилизация одним гостем приближается к производительности физического сервера, оказывается что мы теряем в деньгах на оверхеде. То есть как раз для баз данных плюсы виртуализации сомнительны.

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

Если ты сравниваешь ОДИН железный хост с БД + резерв и кластер гипервизоров для ОДНОЙ ВМ - да. Слова «масштаб» и «расчёт стоимости» о чём нибудь говорят? ;)

Не всегда приемлемо закрывать базы от пользоватетей. А если downtime допустим - тут хоть lvm юзайте для снапшотов, тк снапшот виртуалки и не нужен. Польза таким образом нулевая от виртуализации в этом случае.

Если даунтайм недопустим, патч на БД ты никак не поставишь. А если даунтайм допустим, то «кликнуть мышкой 2 раза» и «восстановить из LVM снапшота» - занимают несравнимое время. К тому же snapshot ВМ может включать содержимое памяти и ВМ будет восстановлена работающей.

В чем же плюс виртуализации если она точно так же допускает «просто сбой по питанию» который так же губителен для базы?Предлагаю убрать и этот пункт из плюсов относительно баз данных.

Тем, что в одном случае ВМ без проблем загрузится и останется только проверить БД / восстановить БД из бекапа, а в другом - сначала иметь секс с железом и «благодарных» за лишний даунтайм пользователей. Предложение отклоняется ;)

Так я вам про то и говорю - виртуализация это попытка мультиплексирования оборудования.

100 % успешная «попытка», годами работающая в production.

Цена ниже, только и качество страдает. А базы данных весьма требовательны к качеству.

От чего именно страдает качество?

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

Нечасто встречается БД, которая полностью потребит ресурсы ( особенно - по памяти ) современного сервера. Такая база, как правило, будет работать на физическом сервере без виртуализации. А всякие служебные БД (cmdb, wiki, bugtrack, LDAP/AD), разработческие БД, QAS БД, не говоря уже о не-БД'шных ВМ, в один сервер набиваются десятками и прекрасно себя чувствуют. Скриншоты, извини, приводить не буду, безопасники не разрешат.

А всякие служебные БД (cmdb, wiki, bugtrack, LDAP/AD), разработческие БД, QAS БД, не говоря уже о не-БД'шных ВМ, в один сервер набиваются десятками и прекрасно себя чувствуют.

Ты ещё sqlite на десктопе в пример приведи

Сдаётся мне, этот список вас огорчил? :)

Ну, пришли к тому, с чего начинали. Жрущие и критичные базы на физических машинах, а всякая мелочь на виртуалках.

Кстати, сколько сейчас в среднем памяти у «современного» сервера?)

Ну, пришли к тому, с чего начинали. Жрущие и критичные базы на физических машинах, а всякая мелочь на виртуалках.

К тому, о чём я уже говорил - без фанатизма, всё зависит от ТЗ и ожидаемой нагрузки. Большинство БД прекрасно себя чувствуют в ВМ ;)

Кстати, сколько сейчас в среднем памяти у «современного» сервера?)

96 Gb и выше. На одну ВМ - по-разному. От 256 Mb ( rhel 5 с чем -нибудь лёгким ) до 16 Гб под средней загруженности БД.

Oracle VM?

УГ, а все остальное не сертифицировано и/или требует лицензирования всего хоста.

сертификации можно менять, если достаточно клиентов надавят на оракл. они и RHEL не хотели сертифицировать, но ведь прогнулись