Руководство одобрило миграцию наших основных баз данных Oracle на платформу виртуальных машин.
Операторы говорят, что выделят мощное оборудование и будут запускать на нем виртуальные машины БД.
Я слышал, что запуск БД на виртуальной машине недопустим из-за дополнительного уровня (виртуальный io + физический io), но ребята из OPS говорят, что это сверхбыстрое оборудование, так что проблем нет.
Должен ли администратор баз данных быть слишком обеспокоен переходом на виртуальную среду?
спасибо / j-p.
"и запускать на нем только виртуальные машины БД"
Я работал в двух разных магазинах, где управлял Oracle на VMware, и в обоих сисадмины давали одно и то же обещание (и, в конце концов, они его не сдержали :)
Помимо предупреждения wzzrd о том, что Oracle не «официально» поддерживает экземпляры на виртуализированном оборудовании, если виртуальный сервер правильно настроен, достаточно мощный и не перегружен десятками других виртуальных машин, снижение производительности не должно быть действительно заметным для конечных пользователей.
Это также зависит от типа виртуализируемых баз данных. OLTP обычно лучше подходят для виртуализации, чем DSS / DWH, где производительность ввода-вывода критична.
Я настоятельно рекомендую вам попросить вашего менеджера позволить вам протестировать новые серверы перед переходом к производству, чтобы заранее выявить возможные проблемы с производительностью.
В любом случае, удачи.
Фрэн.
Я запускал базы данных в виртуальной машине без каких-либо серьезных проблем (как небольшие живые базы данных, так и большие тестовые / разработанные, хотя на сегодняшний день нет больших живых баз данных). Помимо потенциальной проблемы официальной поддержки, которую вы решаете, как и в случае с физическим сервером БД, будет производительность ввода-вывода и ОЗУ.
Что касается производительности ввода-вывода, мой опыт показывает, что виртуальный диск никогда не работает так хорошо, как заявляют заинтересованные стороны в технологиях, но никогда не бывает так плохо, как утверждают другие. Пока у вас есть хорошая физическая подсистема ввода-вывода, обслуживающая виртуальные машины (например, красивый блестящий массив быстрых дисков RAID10), все должно быть в порядке. Все обычные настройки производительности применимы к виртуальным машинам, такие как хранение данных и журналов на отдельных массивах (или на отдельных дисках, если используются отдельные диски вместо RAID) и временных данных (при условии, что Oracle имеет эквивалент MSSQL. tempdb на другом массиве (некоторые предлагают RAID0 для производительности, хотя я опасаюсь использования RAID0 в производстве даже для временных данных, поскольку я не хочу простоя при выходе из строя диска), если вы тоже можете. Сделайте свой RAID полностью аппаратным (с хорошо RAID-контроллер) или в программном обеспечении на физическом хост-компьютере. Как бы глупо это ни звучало, я видел, как люди рекомендуют вместо этого использовать RAID в виртуальных машинах ...
Что касается ОЗУ, просто предоставьте виртуальным машинам БД столько, сколько сможете, и убедитесь, что она предназначена для них и не будет заменена хостом.
ИМО: базы данных работают в виртуальных машинах и, безусловно, работают достаточно хорошо, если у вас есть оборудование для их обслуживания и не перегружайте оборудование (две базы данных с виртуальными машинами, которые видят значительную нагрузку, вызовут большую нагрузку ввода-вывода, чем один сервер базы данных, обрабатывающий тот же контент, поскольку два экземпляра не могут управлять ОЗУ и упорядочением ввода-вывода между собой, где один экземпляр сервера БД может манипулировать ресурсами между работами по мере необходимости).
В дополнении к @Franкомментарий, убедитесь, что ваше приложение продавец тоже поддержит его.
Я знаю, что поставщик, у которого я работал до моей текущей работы, не будет поддерживать весь продукт, если Oracle не установлен на «поддерживаемой» платформе. Это делает инструмент стоимостью в несколько миллионов долларов более или менее бесполезным, если вам нужна помощь.
Просто предупреждение :)
Пока ввод-вывод в базе данных достаточно быстрый и у вас есть доступ к достаточному количеству виртуальных ЦП и ОЗУ, все будет в порядке. Если у вас есть SAN за системами VMware, и вам нужна более высокая скорость, они могут представлять LUN напрямую гостю либо через iSCSI, либо через сопоставление необработанных устройств, где LUN предоставляется хостам, тогда хосты передают необработанное устройство гостю ОС напрямую. Это позволяет гостю форматировать LUN по своему усмотрению и убирает лишний уровень устройства.
(Это работает для всех баз данных.)
Не потому, что виртуальное оборудование, возможно, немного медленнее: это всего пара процентов, если мы можем верить специалистам по тестированию из Red Hat и VMware (и т. Д.) Или наброситься на нас.
Возможно, потому что Moloch Oracle не поддерживает виртуализированное оборудование под своими базами данных. Ото, я слышал, что их можно «принудить» поддержать при условии правильной тактики. Дайте нам знать, что вы в итоге делаете.
На самом деле у нас есть много баз данных Oracle, работающих на ESX, но это не производственные базы данных.
Если у вас есть возможность, попробуйте сохранить фактические данные и журналы на физическом диске. Помимо этого, используйте предложение wzzrd.