| Oracle Automatic Storage Management |
| Петък, 12 Декември 2008 09:36 |
|
Ако се наложи да планираме по-мащабна инсталацията на Oracle Database, едно от най-важните решения ще бъде избора на механизъм за съхраняване на данните. Първото което трябва да обмислим относно начина на съхранение е дали ще използваме RAW устройства или файлова система. Ако използваме един диск като RAW устройство, то на практика заобикаляме операционната система, като достъпа и организацията на данните върху него се управляват директно от базата данни. Ако използваме файлова система, то базата данни съхранява данните във файлове, за чиято организация отговорност носи операционната система. Трябва внимателно да преценим съответните плюсове и минуси в зависимост от типа организация на данните, на която се спираме. При използването на дисковете като RAW устройства обикновено се постига по-висока производителност. Това е следствие от факта, че се елиминира двойното буфериране на данните (веднъж в базата данни и още веднъж на нивото на операционната система) и от липсата на заключващи механизми на нивото на файловата система. Също така при наличие на файлова система записите към един файл обикновено се сериализират (тоест извършват се един след друг), което не позволява паралелни дискови операции върху един и същи файл. Използването на RAW има също своите недостатъци. Най-голямото неудобство идва именно от управлението на организацията на данните. Най-малката област, с която оперираме е дисковия дял. Веднъж заделен, той не може да бъде разширяван. Тъй като дялът не е файлова система, върху него не могат да се прилагат стандартни файлови команди, нито да се съхраняват файлове (включително archive log файловете например). Нещо повече – той не може да се споделя от няколко TABLESPACE-а, а и архивирането му е по-специфично. За да се преодолеят част от недостатъците на директното използване на дискови дялове, често се прибягва до използването на Logical Volume Manager или LVM. Това е метод, при който множество дискови дялове се обединяват и управляват в един логически том. Това позволява по-лесно управление на капацитета, чрез добавяне и премахване на отделни дискови дялове. Въпреки че добавя още един допълнителен слой в архитектурата, за който да се грижим се счита, че ползите от LVM са повече от неудобствата по неговото администриране. Разбира се, използването на LVM не е ограничено само до RAW устройства. Върху логическите томове също може да се разположи файлова система, което ни води до точно четири избора на архитектура за организация на данните. Четирите варианта са изобразени на следната фигура:  Очевидно е, че ако се стремим към максимална производителност трябва да направим избор между гъвкавостта и допълнителните административни грижи. За да не се налага да правим подобен компромис, Oracle предлага собствено решение наречено Automatic Storage Management или ASM. Казано накратко ASM е файлова система и LVM, които работят директно на нивото на ядрото на базата данни. Неговото използване води до редица ползи. Като начало администраторите на базата данни работят с логически единици наречени „дискови групи“. Те могат да добавят или да изваждат физически дискове от групата, а за самото разполагане на данните и файловете върху тях базата данни се грижи автоматично. Когато работи с файлове, ASM се грижи всеки файл да бъде равномерно разпрострян върху физическите устройства в дисковата група. По този начин входно-изходните операции върху всеки един файл се разпределят между наличните физически дискове и обработката на данните се извършва в паралел. Automatic Storage Management поддържа и собствен алгоритъм за създаване на огледални копия на данните, с цел осигуряването на защита срещу повреда във физическите дискове. Това е полезна възможност, ако не използваме устройства поддържащи собствен RAID механизъм. За да може една база данни да използва ASM, предварително се стартира една по-специална инстанция наречена „ASM инстанция“. Тя не монтира база в смисъла на стандартната Oracle инстанция, а предоставя достъп до метаданни относно дисковите групи и разположението на файловете. След като ASM инстанцията е стартирана се стартира и стандартната инстанция на базата данни (на схемата наречена ORCL).  Важно е да знаем, че ORCL инстанцията не достъпва данните през ASM инстанцията. Тя единствено получава от нея информация къде и как са разположени те. В последствие операциите по четене и запис се извършват директно към дисковете. Комуникацията с ASM инстанцията от своя страна се извършва чрез процеса ASMB (съкращение от ASM Bridge), свързващ се към ASM като foreground процес (FG). ASM работи с логически блокове наречени allocation unit (AU). Системата се стреми всички блокове на даден файл да са равномерно разпределени върху всички налични физически устройства в групата. Когато се добави нов физически диск към групата се налага преместването само на такова количество данни, пропорционално на капацитета на добавения диск. За следенето на местоположението на блоковете се използва специална техника за индексиране. ASM инстанцията също работи директно с дисковите групи, тъй като тя има грижата да извършва процеса по преразпределяне на информацията, така че allocation unit-ите да бъде равномерно разположена върху физическите дискове. Този процес се нарича уравновесяване (rebalance) и се извършва от ARBn процесите. Тяхната работа се координира от отделен процес – RBAL. Въпреки, че идеята за втора инстанция единствено за целите на ASM може да звучи притеснително, трябва да имаме предвид няколко неща. Първо – ASM инстанцията е специален вид инстанция. Нейната System Global Area заема само 64 MB. При инсталации в RAC, ASM инстанция се инсталира върху всеки node на клъстера, като тя управлява дисковите групи използвани от node-а, координирайки автоматично работата си с другите ASM инстанции в клъстера. В допълнение ASM е интегриран с всички инструменти на Oracle базата данни. Той може да се управлява през Enterprise Manager, SQL*Plus, Database Configuration Assistant, Recovery Manager и така нататък.  Automatic Storage Management е безценно допълнение към всяка инсталация на Oracle Database, особено при работа в Real Application Cluster и при управлението на по-големи обеми от данни. Той дава възможност на администраторите на базите данни директен контрол върху достъпното пространство, като същевременно ги освобождава от нуждата сами да управляват отделните файлове на базата. Интегрираните възможности за резервиране чрез създаване на огледални копия и наличната интеграция с RMAN за целите на архивирането са още един допълнителен плюс, който не трябва да пренебрегваме. За повече информация относно ползването на ASM може да погледнете поредицата от практически статии [manchev.org], показващи инсталацията на Oracle Database 10g с ASM под Enterprise Linux 5 във виртуална машина. По този начин ще имате възможността да проследите процеса на инсталация и конфигуриране стъпка по стъпка. |
Коментари