This content has been marked as final. Show 1 reply
ASM isn't intended as a direct replacement for RAID, although with ASM mirroring, the functionality can be similar - a lot of it is going to depend on your needs, your budget, your current disk configuration, and comfort in managing either solution.
To super-simplify some of the key points, you basically have 4 configuration options that are available to you:
ASM (External Redundancy) and Disk (non-RAID):
- You don't want to run in this configuration for any systems that require uptime. If ASM is set to "external", where there is no software redundancy, and the disks are not part of a RAID group, any failure of a single disk will cause a loss of data on the ASM diskgroup. (We don't even run this in our Lab environments, but it is possible - just not recommended).
ASM (Normal/High Redundancy) and Disk (non-RAID):
- Allows DBA to manage Failure Groups and file protection within ASM, which can be a great asset for an organization where there is no SAN management, but DBA is responsible for correct configuration to prevent outages during failures - and more importantly, responsible for monitoring failure groups to ensure adequate space for failure.
- Places the burden of mirroring on the Software, and therefore the cluster host(s).
- Loss of a disk relies on ASM (and proper Diskgroup/File Protection configuration!) to allow continued/uninterrupted processing (assuming the Failure group is not on the same physical device).
- Maximizes Capacity, but not necessarily I/O
ASM (External Redundancy) and Disk (RAID)
- Removes administrative overhead of managing Failure groups and file protection for the DBA, but DBA should work with Storage Admins to ensure protection exists at the storage layer (correct RAID configuration, hot spares, etc.)
- Places the burden of mirroring on the disk array/controller card. RAID controllers offload the mirroring/striping work from the cluster, usually allowing for a performance improvement when compared to ASM redundancy alone.
- Loss of a disk (in a properly configured RAID group) is transparent to ASM, the DBA, and the end-user, assuming the loss is only at the disk level within a RAID group, not a storage-device level loss or RAID group logical corruption.
- Depending on configuration (RAID-5 vs. 0+1, normally), capacity and/or I/O can be an issue - DBA should work with the Storage Admins to determine correct requirements.
- In my personal experience ONLY this is the most common setup I've seen.
ASM (Normal/High Redundancy) and Disk (RAID)
- Administrative overhead rests on BOTH the DBA and Storage Administrator - potential for great redundancy, but at a cost of more potential failure points.
- Processing overhead is doubled - Host CPU is utilized for ASM striping/mirroring, RAID controller utilized for RAID striping/mirroring. This will likely result in some degraded performance if not carefully managed/planned for.
- Best Redundancy available - If Failure groups are segregated into different RAID groups (or even storage controllers/SANs) properly, and RAID is properly configured, even total SAN outages (planned or unplanned) wouldn't impact the database availability.
- High cost of hardware - for example, assuming a full-sized failure group on ASM (2x disk) and RAID-10 (2x disk again), you're looking at a potentially cost-prohibitive configuration, especially when considering IOPS and throughput requirements, number of spindles, etc. - costs can get high very quickly.
Again, this is just a quick overview of ASM Failure Groups and RAID - ultimately, the decision will need to be based on your specific environment's needs, taking into account budget/costs, administrative abilities and overhead (do you have a storage admin? a 10-man SAN team? One DBA or 20?), database size, availability requirements, throughput/IOPs, etc.
Some more great info from Levi Pereira on ASM striping (with more links embedded within):
Re: Oracle 10.2 ASM on AIX 5.3 compatibility with IBM DS4300 & EXP700 storage