ASM or raw devices ?
Услышал очень емкую фразу про сравнение производительности ASM и сырых (raw) устройств:
"ASM не производит никаких операций ввода-вывода - поэтому сохраняет производительность сырых устройств"
Действительно (хотя я не смог явно найти этого в документации) регулярный ввод-вывод (т.е. то что делает DBWR или LGWR) как производился этим процессами так и производится. Другое дело, что ASM обеспечивает карту - т.е. куда именно следует записать. Картинка из презентации справа иллюсстрирует тоже самое.
Хорошее описание с правильным (я надеюсь) описанием также можно взять здесь:
AcingASM.pdf (application/pdf Object)
Из картинки мне кажется ясно следует, что только первоначальную разметку и создание/увеличение файлов делает ASM.
Раз так, то мне кажется нет смысла держать БД на raw устройствах.
Естественно, поскольку mirrroring & striping делается на прикладном уровне - это не очень быстро.
Так что если есть возможность - конечно лучше отдавать mirrroring & striping дисковому массиву. Опять таки статистики с массива по вводу выводу можно получить более разумные. Тут есть еще один не однозначный для меня ход :)
ASM всегда делает страйпинг. Таким образом если вы используете возможности массива в ваших дисковых группах должен быть всегда только 1 диск. В противном случае, если появится другой - начнется ребалансинг а затем и страйпинг. Добавление места должно осуществляться только путем расширения этого одного диска.
Опять таки, из-за того что ASM всегда делает страйпинг кажется, что если в дисковой группе будет два разных по объему диска, то будет использоваться только меньший объем. И даже больше - отличное замечание про размер дисков.
Другое дело - сравнение ASM с Volume Manager'ами.
Да, конечно в 11g появилось preferred mirror read, мы потихонечку догоняем функциональность VM, но пока только догоняем.
Мне также обещают прислать сравнение по скорости, где ASM выигрывает у Veritas VM.
Но по гибкости управления ASM все еще проигрывает. Опять таки в 11g в asmcmd появилась возможность копировать файлы данных между ASM и файловой системой.
Но те кто занимаются storage'ами конечно знают, что необходимо гораздо больше возможностей.
Но ASM бесплатно - а промышленные Volume Manager стоят существенные деньги.
Так что у каждого продукта свой круг пользователей.
Сообщения
Еще одно существенное преимущество у ASM - это до безобразия просто.
ОтветитьУдалитьКстати, практически никакой overhead на страйпинг нет и уж тем более нет никаких преимуществ в одном ASM диске по сравнению с 10-ю. ASM просто хранит карту всех экстентов и никакой разницы нет на одно они диске или на 10-ти.
Кстати, наоборот, часто есть преимущесва в разбитии на несколько дисков, хотя, это не из-за ASM.
Расширять ASM дисковую группу увеличением диска - это не самый лучший метод. Гораздо проще добавить диск и дать ASM сделать ребалансинг. Можно это отложить на время когда система менее нагружена. Если один ASM диск соответствуем физическому диску (а точнее двум в зеркале) то physical layout черезвычайно простая и гарантированно что производительночть у дисков одинакова. Добавить дисков в страйп-группу в дисковом массиве совсем не просто, если там кончилось место чтобы расширить "виртуальный" диск которй виден для хоста.
ASM пока не очень хорошо делает мирроринг. 11g должна кое что улучшить (fast re-silvering) но пока нет опыта как это работает в реальности.
Про ASM и увеличение диска.
ОтветитьУдалитьЯ вот что имел в виду.
Очень часто команда занимающаяся storage дает один lun на хост. Внутри уже все хорошо, зеркалировано, страйплено и т.д.
Ok.
И вот этот lun закончился. Естественно - покупается еще корзина, с нее дается еще один lun, только поменьше...
Вот этот поменьше и нельзя похоже добавлять в группу. Поскольку диски в группе должны быть одинаковыми чтобы прошел striping.
А нам striping вообще-то и не нежен, у нас его массив делает...
Мне кажется что с ASM надо очень очень внимательно все планировать если под ней лежать не обычные простые диски а массив.
А если обычнные диски - то я полностью согласен - ASM просто и удобно !
Каждый массив можно сконфигурить так, чтобы один LUN соответсвовал двум RAID1 дискам (mirrored). К сожалению, обычно массив конфигурится специалистом далеким от баз данных. :-( Особенно high-end и mid-range классы.
ОтветитьУдалитьНасчет размеров - это абсолютно верно. ASM делает динамический ребалансинг но на самом деле он не анализирует нагрузку на каждый диск а просто действует опираясь на несколько допущений:
- каждый диск имеет одинаковое быстродействие
- каждый диск одного размера
- IO распределен так что нет нескольких "горячих" одномегабайтных участков приходящихся на один диск (или 128Л для fine striping). Для Oracle пракически всегда это так.
Есть еще одно правило которое очень часто не соблюдается но не всегда нарушение приводит к катастрофе... скорее к пониженной утилизации:
- каждый диск должен быть независим друг от друга
Последнее часто не соблюдается когда ASM ставится поверх массива.
Кстати, например, в Linux увеличить размер диска не просто. Обычно это требует или рестарт машины или SCSI bus rescan что в приципе значит, что базу данных надо останавливать. К тому же надо расширать партицию - я бы не хотел с этим связываться.
Обычно мы заранее принимаем каким должен быть размер одного ASM диска - либо как раз размер физического диска или что-то искусственнрое, когда LUNs выделяются из большого пула RAID1+0.