ASM_Oracle ASM的概念（概念）

2014-06-03 Created By BaoXinjia

1. 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不支持存放数据文件

2. 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奔溃后总是能复原的。

3. ASM冗余

ASM使用独特的镜像算法：不镜像磁盘，而是镜像盘区。作为结果，为了在产生故障时提供连续的保护，只需要磁盘组中的空间容量，而不需要预备一个热备(hot spare)磁盘。

不建议用户创建不同尺寸的故障组，因为这将会导致在分配辅助盘区时产生问题。

ASM将文件的主盘区分配给磁盘组中的一个磁盘时，它会将该盘区的镜像副本分配给磁盘组中的另一个磁盘。

给定磁盘上的主盘区将在磁盘组中的某个伙伴磁盘上具有各自的镜像盘区。ASM确保主盘区和其镜像副本不会驻留在相同的故障组中。

磁盘组的冗余可以有如下的形式：双向镜像文件(至少需要两个故障组)的普通冗余(默认冗余)和使用三向镜像(至少需要3个故障组)提供较高保护程度的高冗余。

一旦创建磁盘组，就不可以改变它的冗余级别。为了改变磁盘组的冗余，必须创建具有适当冗余的另一个磁盘组，然后必须使用RMAN还原或DBMS_FILE_TRANSFER将数据文件移动到这个新创建的磁盘组。

三种不同的冗余方式如下：

1. 外部冗余（external redundancy）：表示Oracle不帮你管理镜像，功能由外部存储系统实现，比如通过RAID技术；有效磁盘空间是所有磁盘设备空间的大小之和。

2. 默认冗余（normal redundancy）：表示Oracle提供2份镜像来保护数据，有效磁盘空间是所有磁盘设备大小之和的1/2 （使用最多）

3. 高度冗余（high redundancy）：表示Oracle提供3份镜像来保护数据，以提高性能和数据的安全，最少需要三块磁盘（三个failure group）；有效磁盘空间是所有磁盘设备大小之和的1/3，虽然冗余级别高了，但是硬件的代价也最高。

4. 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的冗余无效

5. ASM所提供的高可用性

ASM提供数据镜像以便从磁盘失败中恢复

用户可以选择EXTERNAL、NORMAL、HIGH三种冗余镜像

1. EXTERNAL即ASM本身不做镜像，而依赖于底层存储阵列资深实现镜像；在External下任何的写错误都会导致Disk Group被强制dismount。在此模式下所有的ASM DISK必须都存在健康，否则Disk Group将无法MOUNT

2. NORMAL 即ASM将为每一个extent创建一个额外的拷贝以便实现冗余；默认情况下所有的文件都会被镜像，这样每一个file extent都有2份拷贝。

若写错误发生在2个Disk上且这2个Disk是partners时将导致disk Disk Group被强制dismount。若发生失败的磁盘不是partners则不会引起数据丢失和不可用。

3. HIGH 即ASM为每一个extent创建两个额外的拷贝以便实现更高的冗余。2个互为partners的Disk的失败不会引起数据丢失，当然不能有更多的partners Disk失败了。

数据镜像依赖于failure group和extent partnering实现。ASM在NORMAL 或 HIGH 冗余度下可以容许丢失一个failure group中所有的磁盘。

6. 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 操作拷贝数据，这些工作是后台自动完成的。

7. 重新平衡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不会造成过度的影响

8. 性能方面

ASM会通过在DG中条带化文件extent分布以最大化可用的IO带宽

有2种可用条带化宽度：coarse粗糙条带化大小为1个AU，fine精细条带化为128K

即便是fine精细条带化仍采用普通大小的file extent，但是条带化以更小的片形式循环式地分布在多个extent上

ASM默认不让RDBMS去读备用的镜像拷贝extent，即使这样请放心IO还是均衡的

默认情况下RDBMS总是去读取主primary extent，从11.1开始可以通过PREFERRED_READ_FAILURE_GROUP参数设置让本地节点优先读取某个failure group中的extent; 该特性主要为extended distance RAC设计，不建议在常规ASM中使用

9. Disk Group

Disk Group”磁盘组” 是ASM管理的逻辑概念对象，一个Disk Group由多个ASM disk组成。

每一个Disk Group都是子描述的，如同一个标准的文件系统一样。所有关于该Diskgroup 空间使用信息的元数据均完整地包含在这个磁盘组中。

若ASM可以找到所有属于该ASM diskgroup的DISK则他不需要任何其他额外的元数据。

文件空间从Disk Group中分配。任何一个ASM文件总是完整地包含在一个单独的Disk Group中。

但是，一个Disk Group可能包含了属于多个数据库的文件，一个单独的数据库的文件也可以存放在多个不同的Disk Group中。

在大多数实际的部署中，不会创建太多数量的Disk Groups，一般在3~4个。

Disk Group提供三种不同的redundancy冗余度，详见上文。

10. ASM Disk

一个ASM Disk是组成Disk Group的基本的持久的存储。当一个ASM Disk加入到Disk Group中时，它要么采用管理员指定的ASM Disk Name要么采用系统自动分配的Disk Name。

这不同于OS 给用于访问该设备的”艺名”。

在一个Cluster集群中，同一个Disk 可能在不同的节点上显示不同的Device Name设备名，例如在 Node1上的 /dev/sdc ，对应于Node2上的/dev/sdd。

ASM Disk必须在所有使用该Disk Group的实例上可用直接磁盘I/O访问。

实际上对于RDBMS Oracle而言访问ASM disk和访问普通的文件并没有什么不同，除非使用了ASMLIB(ASMLIB不是ASM必须的，再次强调！)。

常规情况下ASM Disk是OS上可见的LUN的partition，该分区覆盖了所有不被操作系统所保留的磁盘的空间。

大多数操作系统需要保留LUN的第一个block作为分区表(partition table)；由于ASM总是会写ASM Disk的第一个块，所以要保证ASM不会去覆盖前几个block上的分区表(partition table)，例如在Solaris上分区时不要把前几个柱面划给partition。

LUN可以是简单的物理JBOD，或者是由高级存储阵列管理的虚拟LUN。

既可以是直连的设备也可以是SAN。ASM Disk可以是任何被开发系统调用所访问的东西，除了本地文件系统。

甚至于NFS上的文件都可以被当做一个ASM Disk来用，这样便于喜欢NAS的用户使用ASM，当然比起NFS来我更建议干脆用ISCSI。

注意虽然可以使用普通logical Volume Manager LVM管理的logical volume作为ASM Disk，但是这并不是推荐组合，除非你想不到其他更好的办法。

即便你一定要这样用，但是注意也不要在LVM级别做镜像和条带化。

ASM将任何文件以AU大小均匀分布在Disk Group的所有Disk上。每一个ASM Disk均被维护以保持同样的使用比率。

这保证同一个Disk Group中的所有Disk的IO负载基本一致。由于ASM在一个Disk Group中的磁盘上的负载均衡，所以为同一个物理磁盘的不同区域划分为2个ASM Disk不会对性能有所影响；而同一个物理磁盘上划分2个不同分区置于不同的2个Disk Group则有效。

当ASM Disk Group启用冗余时单个ASM Disk仅是一个失败单元。

对于该ASM Disk的写失败在10g会自动从该Disk Group drop掉该Disk，前提是该Disk的丢失被容许。

11. Allocation Unit

每一个ASM Disk都被划分为许多个AU allocation units(单个AU 的大小在 1MB ~64MB，注意总是2的次方MB)。

而且AU allocation unit也是Disk Group的基本分配单元。一个ASM Disk上的可用空间总是整数倍个AU。

在每一个ASM Disk的头部均有一个表，该表的每一条记录代表该ASM Disk上的一个AU。

文件的extent指针(pointer)给出了ASM Disk Number磁盘号和AU号，这就描述了该extent的物理位置。由于所有的空间操作都以AU为单位，所以不存在所谓ASM碎片这样的概念和问题。

一个AU(1M~64M)足够小，以便一个文件总是要包含很多个AU，这样就可以分布在很多磁盘上，也不会造成热点。

一个AU又足够大以便能够在一个IO操作中访问它，以获得更加的吞吐量，也能提供高效的顺序访问。

访问一个AU的时间将更多的消耗在磁盘传输速率上而非花在寻找AU头上。对于Disk Group的重新平衡也是对每一个AU逐次做的。

12. 其他知识

并非RAC才能使用ASM，单节点同样可以从ASM哪里获得好处

节点上的一个ASM instance实例可以为多个RDBMS DB实例服务

RAC环境中的ASM必须也是集群化的，以便能够协调更新元数据

从11.2开始，ASM从RDBMS HOME分离出来，而和clusterware一起安装在GRID HOME下。

13. ASM和数据库实例结构图

14. Clustered ASM 结构图

Thanks and Regards

参考：红黑联盟 -http://cache.baiducontent.com

参考：诗坛软件- http://www.oracledatabase12g.com/archives/know-oracle-asm.html

posted on 2014-01-01 12:09 东方瀚海阅读(737) 评论(0) 编辑收藏举报