ASM - to be or not to be ?

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

В книге Oracle Automatic Storage Management Bill Bridge пишет, что идея ASM возникла у него в 1996 году, когда он работал в проекте по внедрению Oracle Video Server. У них возникли проблемы с производительностью, из за того, что часть дисков оказалась перегружена, а часть простаивала. Тогда, идея, чтобы БД сама автоматически распределяла экстенты между всеми дисками показалась ему отличной.

В 1996 году еще не было Linux LVM (так думает википедея), SUN Microsystems еще не раздавала Solaris Volume Manager, а Windows еще не умела зеркалировать диски (так думаю я).

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

ASM дает нам возможность использовать кросс-платформенное средство хранения наших файлов Oracle (данные, redo, archive log, control, backup. Все кроме binaries). А значит, время вложенное в ASM для администратора не пропадет, при изменении платформы.

Если функции зеркалирования и балансировки нагрузки выполняет Ваш умный дисковый массив, стоит ли Вам использовать ASM ? Стоит, но разумно. Стоит поручить массиву работу, которую он выполнить лучше чем софтверное решение, и при этом не потребит CPU вашего сервера БД. Т.е. в ASM нужно выдать 1 lun и создать на нем одну группу external redundancy для данных (возможно еще одну для FRA). Почему все таки не создать на этом lun обычную файловую систему ? Как видно из картинки, ASM минует несколько уровней системных вызовов, а поэтому окажется эффективнее. По производительности ASM приближается к производительности сырых (raw) устройств.

Когда стоит не использовать ASM ? Если у Вас куплен, например, Veritas Storage Foundation, Oracle Disk Manager, у Вас всегда используется только одна ОС, накоплен многолетний опыт работы с Veritas, очень серьезная по нагрузке БД - я бы рекомендовал продолжить работать с Veritas. Там есть некоторые приятные возможности по работе с группами, которых нет в ASM. Хочу уточнить, что ASM бесплатен, в отличии от весьма серьезных затрат на лицензии Veritas.

Еще один аргумент в защиту ASM - если ваша single instance уже использует ASM, то переход в RAC или на Exadata для Вас будет значительно облегчен.

Можно построить даже extended cluster используя ASM, а не покупая дорогостоящих дисковых подсистем с опциями синхронизации между площадками.

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

Несколько фактов использования ASM (Статистика основана на нашей внутренней информации. Пользователи могу использовать или не использовать ASM не уведомляя Oracle):

• В промышленной эксплуатации с 2004 года
• 65% инсталляций RAC используют ASM
• 25% исталляций 10g используют ASM

Много VLDB баз данных объемом до 10TB используют ASM.

Примеры серьезных инсталляций:

• Sprint - 300 TB data
• Amazon – 150 TB data

Здесь вы найдете массу технических деталей по ASM.

Ребята из CERN озаботились, а вдруг что-то случиться с заголовками дисков, где ASM хранит свою конфигурацию и надо будет достать данные. И разобрались, что к чему.