ASM – Automatic Storage Management Rastislav Hudák

ASM - motivácia Problémy so správou DB Rekonfigurácia diskov Hot spots Fragmentácia „Management gap“ Prístup Enterprise manager DBCA (Database Configuration Assistant) SQL*Plus ASM Command Line Interface (od v10.2) ASMLib (API pre dodávateľov HW)

ASM - overwiev Riešenie ASM (od verzie 10g) File systém a volume manager v jednom, špecificky navrhnutý pre oracle databázové súbory Snaha o rovnaké a jednoduché rozhranie nad server a storage platformami Virtualizuje databázové úložisko do tzv. disk groups Administrátor spravuje disk groups v rámci nich ASM samo rozkladá a pomenuváva databázové súbory rozkladá ich rovnomerne aby sa rozložila záťaž a zlepšila odozva online prehadzuje súbory ak sa nejaký disk pridá alebo odstraňuje (nemá taký striktný striping ako RAID, netreba všetky údaje „prestripovať“) podpora redundancie

ASM - vlastnosti I/O optimalizácia Súbory rozdelené na 1MB časti (veda!), tie sú rovnomerne rozložené na diskoch Umiestnenie súborov neudáva matematická funkcia (závislá na počte diskov) ale pointer => jednoduchá relokácia častí v prípade pridania- odobratia disku Fine-grained striping pre I/O-náročné súbory ako log, vo všeobecnosti špecifické pre typ súboru – nastavuje sa v disk group templates Mirroring žiadny - externý, dvojcestný, trojcestný Zrkadlí sa každá časť súboru (teda typicky každý 1MB) Možnosť vytvárať failure groups

ASM - internals ASM je samostatný proces Spravuje najmä mapu častí súborov – extent map Potrebuje asi 64MB priestoru 63 disk groups, 10000 diskov, ml súborov, 35TB súbor V architektúre RAC (Real Application Cluster) beží na každom uzle a spravuje všetky jeho disk groups, v koordinácii s ostatnými uzlami Keď databáza otvorí database file... ASM poskytne extent map pre daný súbor, DB potom pracuje priamo s časťami súboru na diskoch, ak sa mapa nemení Mapa sa mení iba ak: sa otvára nový súbor, pridáva alebo odoberá disk, zväčšuje tablespace Teda ASM musí bežať skôr než inštancia DB Jeden ASM môže obsluhovať viac databáz

ASM - administrácia Stav Môžme kontrolovať buď cez Enterprise manager-a alebo cez V$views Automatic... Málo nastaviteľných parametrov Při inštalácii je povinný iba INSTANCE_TYPE = ASM Stupeň mirroringu Failure groups Power limit (0-off, 1-low speed – 11-full throttle) Discovery string Na disky ktoré sú tu uvedené sa ASM pozerá aby z ich hlavičiek zistil, ktorý patrí do ktorej skupiny Napríklad v rozsiahlych systémoch nechceme kontrolovať každý disk Závislé na operačnom systéme

ASM - detaily Mirroring a Failure groups Keď raz vytvoríme disk groups s určitým stupňom mirroringu, nemôžeme ho dynamicky zmeniť. Musíme vytvoriť novú disk group, a údaje preniesť pomocou RMAN restore alebo DBMS_FILE_TRANSFER Príklad: máme diskové pole s dvoma trays, chceme aby výpadok jedného nebol kritický SQL> create diskgroup DATA_NRML normal redundancy Failure group flgrp1 disk ‘/dev/rdsk/c3t19d3s4’,‘/dev/rdsk/c3t19d4s4’,‘/dev/rdsk/c3t19d5s4’ Failure group flgrp2 disk ‘/dev/rdsk/c4t20d3s4’,‘/dev/rdsk/c4t20d4s4’,‘/dev/rdsk/c4t20d5s4’

ASM - detaily Mirroring a Failure groups Vždy sa číta primárny extent (sekundárne – mirrorované iba ak sa primárny prečítať nedá) Rozloženie primárnych a sekundárnych extentov je rovnomerné cez disky (kontra iné managery, ktoré majú primárny disk a sekundárny, na ktoromsú iba zrkadlené údaje) teda vyvažuje sa záťaž – číta sa rovnomerne zo všetkých diskov. Ak nevieme ako rozložiť failure groups necháme to na ASM (z best practices) – každý disk bude samostatná failure group, partnerské disky (so sekundárnymi extentmi) vyberie ASM

ASM - detaily Mirroring a Failure groups Rebalancing – ASM sleduje I/O chyby. Ak je situácia vážna, odpojí disk. Následne vytvára zo sekundárnych extentov primárne, medzičasom DB číta sekundárne, po skončení rebalancingu začne opäť čítať primárne. Ak strata disku spôsobí stratu dát, odpojí ASM celú disk group, aby ochránil integritu dát. Vo V$ASM_DISKGROUP sú stĺpce USABLE_FREE_SPACE (koľko máme miesta ak započítame mirroring) a REQUIRED_MB_FREE (koľko potrebujeme miesta na restore ak vypadne disk)

ASM - detaily Internals 3 podporné procesy: RBAL (balancing), ASMB (štatistiky), O001 – O0010 (process pool na komunikáciu DB s ASM – aby sa nezdržovalo při krátkych požiadavkách) Shutdown ASM bude čakať kým skončia všetky connections z DB. Ak dáme IMMEDIATE tak pustí SHUTDOWN IMMEDIATE aj na DB, ale vždy sa vypína až po DB. Ak ASM spadne, vykoná sa před štartom recovery z logov jednotlivých disk groups Allocation units a coarse vs fine grained distibution Rebalancing vykonávajú procesy ARBx, každý proces realokuje AU sériovo (drahá operácia). ARB procesov je presne toľko koľko udáva power limit (teda môže sa realokovať 11 AU paralelne). Radšej robiť off-peak. ASM allocates space in units called allocation units or AU. ASM always creates one-allocation-unit (AU) extents across all of the disks in a disk group19. For a diskgroup with similarly sized disks, there should be an equal number of AU extents on every disk. A database file is broken up into file extents. There are two types of file extent distributions: coarse and fine. For coarse distribution, each coarse grain extent file extent is mapped to a single allocation unit. With fine grain distribution, each grain is interleaved 128K across groups of 8 AUs. Fine distribution breaks up large sized I/O operations, into multiple 128K I/O operations that can execute in parallel, which benefits sequential I/Os. Coarse and fine grain attributes are pre-defined, as part of system templates, for all system related files; e.g., redo and archive log files are defined as fine grain, whereas, datafiles are coarse. The Rebalance process examines each file extent map, and the new extents are re-plotted on to the new storage configuration. For example, consider an 8-disk diskgroup, with a datafile with 40 extents (each disk will house 5 extents). When 2 new drives of same size are added, that datafile is rebalanced and spread across 10 drives, with each drive containing 4 extents. Only 8 extents need to move to complete the rebalance; i.e., a complete redistribution of extents is not necessary, only the minimum number of extents are moved to reach equal distribution The following is a typical process flow for ASM rebalancing: 1. On the ASM instance, a DBA adds (or drops) a disk to (from) a diskgroup. 2. This invokes the RBAL process to create the rebalance plan and then begin coordination of the redistribution 3. RBAL will calculate estimation time and work required to perform the task and then message the ARBx processes to actually handle the request. The number of ARBx processes invoked is directly determined by the asm_power_limit. 4. The Continuing Operations Directory (metadata) will be updated to reflect a rebalance activity. 5. Each extent to be relocated is assigned to an ARBx process. 6. ARBx performs rebalance on these extents. Each extent is locked, relocated, and unlocked. This is shown as Operation REBAL in V$ASM_OPERATION..

ASM - detaily Príklad: Môžme sledovať postup rebalancingu “Session1 SQL”> alter diskgroup DATA add disk '/dev/rdsk/c3t19d39s4' rebalance power 11 Môžme sledovať postup rebalancingu “Session2 SQL”> select * from v$asm_operation Rebalancing beží na pozadí, ale niekedy je lepšie/nutné počkať kým skončí (ak pridáme 100GB, nemôžme počas rebalancingu vytvoriť 80GB tablespace) Vďaka rebalancingu je pridávanie a odoberanie diskov iba otázkou naplánovania rebalancingu, ale pri použití failure groups sa treba aj zamyslieť ASM allocates space in units called allocation units or AU. ASM always creates one-allocation-unit (AU) extents across all of the disks in a disk group19. For a diskgroup with similarly sized disks, there should be an equal number of AU extents on every disk. A database file is broken up into file extents. There are two types of file extent distributions: coarse and fine. For coarse distribution, each coarse grain extent file extent is mapped to a single allocation unit. With fine grain distribution, each grain is interleaved 128K across groups of 8 AUs. Fine distribution breaks up large sized I/O operations, into multiple 128K I/O operations that can execute in parallel, which benefits sequential I/Os. Coarse and fine grain attributes are pre-defined, as part of system templates, for all system related files; e.g., redo and archive log files are defined as fine grain, whereas, datafiles are coarse. The Rebalance process examines each file extent map, and the new extents are re-plotted on to the new storage configuration. For example, consider an 8-disk diskgroup, with a datafile with 40 extents (each disk will house 5 extents). When 2 new drives of same size are added, that datafile is rebalanced and spread across 10 drives, with each drive containing 4 extents. Only 8 extents need to move to complete the rebalance; i.e., a complete redistribution of extents is not necessary, only the minimum number of extents are moved to reach equal distribution The following is a typical process flow for ASM rebalancing: 1. On the ASM instance, a DBA adds (or drops) a disk to (from) a diskgroup. 2. This invokes the RBAL process to create the rebalance plan and then begin coordination of the redistribution 3. RBAL will calculate estimation time and work required to perform the task and then message the ARBx processes to actually handle the request. The number of ARBx processes invoked is directly determined by the asm_power_limit. 4. The Continuing Operations Directory (metadata) will be updated to reflect a rebalance activity. 5. Each extent to be relocated is assigned to an ARBx process. 6. ARBx performs rebalance on these extents. Each extent is locked, relocated, and unlocked. This is shown as Operation REBAL in V$ASM_OPERATION..

ASM - detaily Vďaka za pozornosť ASM allocates space in units called allocation units or AU. ASM always creates one-allocation-unit (AU) extents across all of the disks in a disk group19. For a diskgroup with similarly sized disks, there should be an equal number of AU extents on every disk. A database file is broken up into file extents. There are two types of file extent distributions: coarse and fine. For coarse distribution, each coarse grain extent file extent is mapped to a single allocation unit. With fine grain distribution, each grain is interleaved 128K across groups of 8 AUs. Fine distribution breaks up large sized I/O operations, into multiple 128K I/O operations that can execute in parallel, which benefits sequential I/Os. Coarse and fine grain attributes are pre-defined, as part of system templates, for all system related files; e.g., redo and archive log files are defined as fine grain, whereas, datafiles are coarse. The Rebalance process examines each file extent map, and the new extents are re-plotted on to the new storage configuration. For example, consider an 8-disk diskgroup, with a datafile with 40 extents (each disk will house 5 extents). When 2 new drives of same size are added, that datafile is rebalanced and spread across 10 drives, with each drive containing 4 extents. Only 8 extents need to move to complete the rebalance; i.e., a complete redistribution of extents is not necessary, only the minimum number of extents are moved to reach equal distribution The following is a typical process flow for ASM rebalancing: 1. On the ASM instance, a DBA adds (or drops) a disk to (from) a diskgroup. 2. This invokes the RBAL process to create the rebalance plan and then begin coordination of the redistribution 3. RBAL will calculate estimation time and work required to perform the task and then message the ARBx processes to actually handle the request. The number of ARBx processes invoked is directly determined by the asm_power_limit. 4. The Continuing Operations Directory (metadata) will be updated to reflect a rebalance activity. 5. Each extent to be relocated is assigned to an ARBx process. 6. ARBx performs rebalance on these extents. Each extent is locked, relocated, and unlocked. This is shown as Operation REBAL in V$ASM_OPERATION..