深入了解Oracle ASM(一):基础概念

ASM基础概念

 

 

Automatic Storage Management是Oracle 在版本10g中率先(对比其他RDBMS)提出的数据库存储自动解决方案，在版本11g中得到进一步升华。ASM提供了数据库管理所需要的一个简单、有效的存储管理接口，该接口实现了跨服务器和存储平台。 ASM是文件系统filesystem和volume manager卷管理软件的一体化，专门为Oracle的数据库文件锁设计的； ASM在保证如文件系统般管理简单的基础上提供高性能的异步Async IO。ASM的引入提高了数据库的可扩展容量，同时节约了DBA的时间，使其能够更敏捷、更高效地管理一个流动性较大的数据库环境。

 

ASM的出现是为RDBMS管理文件存储

• 注意ASM不会替代RDBMS去实施IO读写，很多对这一点存在误解，认为RDBMS发送IO request给ASM，ASM去做真正的IO操作，这是错误的。
• 真正的IO还是由RDBMS进程去实施，和不用ASM的裸设备一样
• 因此ASM不是IO的中间层，也就不存在因为ASM而出现所谓的IO瓶颈
• 对于ASM而言LUN DISK可以是裸设备也可以直接是块设备(10.2.0.2以后)
• 适合存放在ASM中的文件类型包括：数据文件datafile、控制文件controlfile、重做日志redolog、归档日志archivelog、闪回日志flashback log、spfile、RMAN备份以及block tracking file、datapump文件
• 从11gR2开始，ASM引入了ACFS特性可以存放任何类型的文件； 但是ACFS不支持存放数据文件

 

ASM基础概念：

• ASM的最小存储单位是一个”allocation unit”(AU)，通常为1MB，在Exadata上推荐为4MB
• ASM的核心是存储文件
• 文件被划分为多个文件片，称之为”extent”
• 11g之前extent的大小总是为一个AU，11g之后一个extent可以是1 or 8 or 64个AU
• ASM使用file extent map维护文件extent的位置
• ASM在LUN DISK的头部header维护其元数据，而非数据字典
• 同时RDBMS DB会在shared pool中缓存file extent map，当server process处理IO时使用
• 因为ASM instance使用类似于普通RDBMS的原理的instance/crash recovery，所以ASM instance奔溃后总是能复原的。

ASM存储以diskgroups的概念呈现：

• Diskgroup DG对RDBMS实例可见，例如一个DATA DG，对于RDBMS来说就是以’+DATA’表示的一个存储点， 可以在该DG上创建一个tablespace，例如： create tablespace ONASM datafile ‘+DATA’ size 10M。
• Diskgroup下面是一个或者多个failure group (FG)
• FG被定义为一组Disk
• Disk在这里可以是裸的物理卷、磁盘分区、代表某个磁盘阵列的LUN，亦或者是LVM或者NAS设备
• 多个FG中的disk不应当具备相同的单点故障，否则ASM的冗余无效

 

ASM所提供的高可用性：

• ASM提供数据镜像以便从磁盘失败中恢复
• 用户可以选择EXTERNAL、NORMAL、HIGH三种冗余镜像
• EXTERNAL即ASM本身不做镜像，而依赖于底层存储阵列资深实现镜像；在External下任何的写错误都会导致Disk Group被强制dismount。在此模式下所有的ASM DISK必须都存在健康，否则Disk Group将无法MOUNT
• NORMAL 即ASM将为每一个extent创建一个额外的拷贝以便实现冗余；默认情况下所有的文件都会被镜像，这样每一个file extent都有2份拷贝。若写错误发生在2个Disk上且这2个Disk是partners时将导致disk Disk Group被强制dismount。若发生失败的磁盘不是partners则不会引起数据丢失和不可用。
• HIGH 即ASM为每一个extent创建两个额外的拷贝以便实现更高的冗余。2个互为partners的Disk的失败不会引起数据丢失，当然不能有更多的partners Disk失败了。
• 数据镜像依赖于failure group和extent partnering实现。ASM在NORMAL 或 HIGH 冗余度下可以容许丢失一个failure group中所有的磁盘。

 

Failure Group镜像的使用

• ASM的镜像并不像RAID 1那样
• ASM的镜像基于文件extent的粒度，extent分布在多个磁盘之间，称为partner
• Partner disk会存放在一个或者多个分离的failure group上
• ASM自动选择partner并限制其数量小于10个
• 若磁盘失败，则ASM更新其extent map使今后的读取操作指向剩余的健康partner
• 在11g中，若某个disk处于offline状态，则对于文件的变更会被追踪记录这样当disk被重现online时则这些变化得以重新应用，前提是offline的时间不超过DISK_REPAIR_TIME所指定的时间(默认为3.6个小时). 这种情况常发生在存储控制器故障或者类似的短期磁盘故障：
• 这种对于文件变更的追踪基于一个发生变化的file extent的位图，该位图告诉ASM哪些extents需要从健康的partner哪里拷贝至需要修复的disk，该特性称之为fast mirror resync
• 在10g中没有fast mirror resync特性，若disk出现offline则直接自动被drop掉，不存在允许修复的周期
• 对于无法再online的disk，则必须被drop掉； 一个新的disk会被ASM选择并通过rebalancing 操作拷贝数据，这些工作是后台自动完成的。

 

重新平衡Rebalancing

• Rebalancing是在磁盘之间移动文件extent以实现diskgroup上的IO负载均衡的过程
• Rebalancing在后台异步发生，是可监控的
• 在集群环境中，一个diskgroup的重平衡只能在一个ASM instance上发生，不能通过集群多节点同时处理以加速
• 当disk被加入或移除时，ASM会自动在后台开始数据重新平衡工作
• 重平衡的速度和力度可以通过asm_power_limit参数控制
• asm_power_limit参数默认为1，其范围为0~11(从11.2.0.2开始是0-1024)，该参数控制实施重平衡后台进程的数量；Level 0表示不实施重新平衡
• 在重新平衡过程中IO性能(主要是吞吐量和响应时间)可能受到影响，其影响程度取决于存储本身的能力和重新平衡的力度，默认的asm_powner_limit=1不会造成过度的影响

 

性能方面

• ASM会通过在DG中条带化文件extent分布以最大化可用的IO带宽
• 有2种可用条带化宽度：coarse粗糙条带化大小为1个AU，fine精细条带化为128K
• 即便是fine精细条带化仍采用普通大小的file extent，但是条带化以更小的片形式循环式地分布在多个extent上