Недавно мы обсуждали с некоторыми нашими клиентами о том, что является лучшим способом хранения данных в базе данных Oracle. Разумеется, что фундамент должен быть основан на инфраструктуре EMC, но помимо этого, какой диспетчер томов и / или файловая система лучше всего подходят для лучшей производительности и других важных функций?
Существует много диспетчеров томов и множество доступных файловых систем, более или менее зависимых от того, какое оборудование и операционная система запускаете базу данных.
У некоторых уже есть длинный послужной список, некоторые из них – «новые парни с нашего двора». Некоторые из них являются частью операционной системы, другие - сторонними надстройками, для которых вам может потребоваться купить лицензии.
Одним из способов хранения данных в базе Oracle является Oracle ASM (Automatic Storage Management).
Oracle ASM - это диспетчер томов Oracle, специально разработанный для хранения данных СУБД Oracle. Он доступен с версии Oracle 10g и намного улучшен в версиях Oracle 11g релизов 1 и 2. Oracle использует ASM в своих производственных средах и является основным компонентом во многих собственных предложениях Oracle (таких как Oracle Exadata), когда требуется максимальная производительность.
ASM предлагает поддержку кластеров Oracle RAC без необходимости установки стороннего программного обеспечения, например, диспетчеров томов кластера или файловых систем.
Хотя ASM не является абсолютно необходимым для поддержки кластера Oracle RAC в системах EMC, мы настоятельно рекомендуем его использовать, поскольку он снижает риски, затраты, административные издержки и повышает производительность.
Oracle и другие производители разработали альтернативы управлению хранением данных в базе Oracle, такие как Oracle OCFS (и OCFS2), SUN / Oracle ZFS, IBM GPFS и другие. Однако не все из них поддерживают кластеризацию Oracle, и большинство этих файловых систем (и менеджеров томов) сложны в настройке и требуют интенсивной настройки для обеспечения хорошей производительности. Также может быть проблемой поддержка (от Oracle или поставщиков ОС).
Преимущества Oracle ASM
По сравнению с стандартными менеджерами томов и файловыми системами (как с кластеризованной, так и с единой системой), ASM имеет ряд преимуществ:
- Он не требует больших объемов памяти для кеша. При этом память, не задействованная для кеширования файловой системы, может быть сконфигурирована для Oracle memory (SGA), где она более эффективна (обратите внимание, что ASM требует, как правило, нескольких сотен мегабайт для внутреннего администрирования, общего для всех баз данных)
- ASM распределяет куски данных псевдослучайно по всем доступным логическим дискам в группе дисков, тем самым удаляя потенциальные «узкие точки» производительности
- ASM не выполняет никаких операций ввода-вывода, поэтому нет никаких «правил трансляции» для ввода / вывода Oracle в файлы данных в смещения блока диска. I/O из баз данных напрямую применяется к дисковым томам без изменений. Это снова снижает накладные расходы и повышает производительность.
- Поэтому ASM также не использует функции упреждающего чтения (например, как файловые системы) для считывания данных в кэш, которые никогда не используются базой данных.
- ASM не требует кропотливой настройки, включающей в себя назначение размеров фрагментов и настройку журналов файловой системы. При создании группы дисков ASM вам нужно только определить размер «куска» и указать, следует ли выполнять или не выполнять тонкое чередование. Если вы соблюдаете несколько простых правил конфигурации ASM, то маловероятно допустить ошибки в конфигурации, которые вызовут проблемы с производительностью.
- ASM не вызывает фрагментации. Вы можете решить, что балансировка ASM - это своего рода фрагментация. Однако единицы распределения достаточно велики (обычно это 1 МБ или более) для того, чтобы очень маленький диск осуществлял поиск для чтения нескольких последующих (обычно 8 КБ ) блоков
- ASM не разбивает большие I/O операции (т. е. 128K) на несколько меньших (4K или 8K), как это делают некоторые файловые системы. Один большой ввод-вывод работает быстрее, чем много мелких
- Для согласованности не требуется «журнал» (на подобии «журнала транзакций» и т. д.). Эта функция уже выполняется журналами повторного выполнения Oracle (redo logs) и поэтому не требуется дополнительных накладных расходов
- ASM можно управлять из инструментария Oracle и не требует знания администрирования Unix (это может быть преимуществом или недостатком в зависимости от обязанностей различных администраторов в организации).
- Добавление или удаление хранилища в / из ASM очень просто и не требует тщательного планирования (как в случае с менеджерами томов и файловыми системами). После добавления нового хранилища ASM автоматически «перебалансирует» исходное хранилище, поэтому все диски будут использоваться одинаково (равномерно). Это снова повышает производительность
- ASM работает во всех основных операционных системах, поэтому он независим от платформы
- SAP теперь поддерживает Oracle ASM!
- Наконец, EMC полностью поддерживает ASM, включая различные инструменты, которые интегрируются с Oracle (такими как Replication Manager, а также инструменты резервного копирования и создания отчетов).
Недостатки Oracle ASM
Теперь вспомним о недостатках Oracle ASM? Если сильно поморщить лоб, то можно выделить следующие «самые большие» недостатки, которые я определил:
- Миграция из устаревших файловых систем в ASM может быть проблемой и часто требует отключения системы (т.е. продакшен баз данных в том числе)
- Трудно (если не невозможно) просматривать содержимое ASM при помощи стандартных инструментов ОС. В некоторых случаях данные ASM могут быть случайно перезаписаны администраторами ОС, которые используют тома диска, которые (для них) кажутся пустыми. Однако существуют административные способы предотвратить это.
- Резервное копирование не может быть выполнено с помощью традиционных методов (это называется в Oracle “user managed backup”), которые просто копируют файлы ОС, поэтому вам нужны встроенные инструменты или используйте собственные инструменты Oracle (например, RMAN).
И последнее, но не менее важное: я столкнулся с несколькими ситуациями, когда балансировщики нагрузки ввода-вывода (multipath drivers) также испортили ввод-вывод с более высокого уровня. В частности, я видел, что встроенная многоканальная передача ввода-вывода в 64 или 128 Кбайт переводится в несколько 4Kбайт каналов. Все еще не знаю, является ли это ошибкой, недокументированной функцией или работает в соответствии с исходным замыслом программного обеспечения. Но это не помогает производительности Oracle. Мы заменили родной драйвер EMC Powerpath на наш собственный, и сразу же повысили производительность без дальнейшей настройки.
Удостоверьтесь, что вы понимаете стек ввода-вывода от начала до конца. Чем меньше сложность, тем проще (и риски ошибок в конфигурации тоже). Использование ASM (в идеале, с помощью EMC Powerpath) устраняет риск получения неправильно настроенных менеджеров томов, файловых систем и драйверов ввода-вывода.
Наконец, мы также обсудили с клиентами, которые планируют использовать возможности Oracle ASM для зеркалирования (опция “normal redundancy” в ASM) как инструмент аварийного восстановления и создания распределенных кластеров между дата-центрами. Хотя вы можете заставить работать такую конфигурацию, я настоятельно рекомендую не делать этого. Резервирование ASM предназначено для защиты от сбоев дисков, а не от сбоев дата-центров. Для этих целей можно найти лучшее решение, работающее с меньшими рисками.
