ASM 翻译系列第十四弹：ASM Internal Rebalancing act

原作者：Bane Radulovic

译者：    吴    栋

审核：    魏兴华

DBGeeK社群联合出品

Rebalancing act

在ASM中，每一个文件的extent都均匀的分布在它所在磁盘组的所有磁盘上，无论是在文件第一次创建或是文件创建之后的重新resize都是如此，这也意味着我们始终能保持磁盘组中的每一个磁盘上都有一个平衡的空间分配。

Rebalance operation

虽然文件在新建或是resize过程中都能保证空间的均匀分配，但是磁盘组在某些情况下会自动触发重平衡的操作，例如添加、删除和resize磁盘的操作（这些操作显然会让磁盘组变得不再平衡），再如，移动一个文件从磁盘的hot区到cold区。我们还可以通过命令 ALTER DISKGROUP ... REBALANCE手工触发rebalance。同时还可以通过给这个命令增加power子句来修改rebalance的并行度，在磁盘组因为任何理由变得不再平衡的时候，都可以运行这个命令来让磁盘组再次变得平衡。

译者注：由于ASM要求每个文件在ASM磁盘组的所有磁盘上都均匀分配，因此添加、删除磁盘一定会触发REBALANCE，这个特性可能在传统的卷管理软件上并不常见。还会有一些特例导致文件在ASM磁盘组的磁盘上空间分布不均匀，例如external模式下，磁盘组中的磁盘大小差异很大。

在ALTER DISKGROUP ... REBALANCE命令中，可以指定POWER子句，用来指定重平衡的并行度。这个参数可以指定为0，这时重平衡操作会被挂起，直到下一次手工或者自动触发重平衡操作。可以将POWER设置为一个较高的值，这样一定程度上可以加快重平衡的速度，缩短重平衡花费的时间。在执行ALTER DISKGROUP ... REBALANCE命令时，默认会马上返回执行成功，这样我们可以在窗口继续执行其他命令，但是重平衡的操作其实在后台继续执行。我们可以通过视图V$ASM_OPERATION查看重平衡的进度。

Three phase power

重平衡操作共分为三个阶段：第一阶段-rebalance plan，ASM会计算出重平衡的计划。计划取决于很多因素，例如磁盘组大小、磁盘组中的文件个数、磁盘的partnership是否需要调整等等。这个过程时间不会太长，一般不会超过几分钟。第二阶段-extent relocating，是真正干活的阶段，这个阶段，ASM的区会在磁盘组中的磁盘间移动，这个过程会花费大部分的时间。这个过程中，ASM会记录区的移动数量，以及实际的I/O性能，从而估算该过程需要花费的时间（GV$ASM_OPERATION.EST_MINUTES记录估算出的时间)。不过要注意的是，这只是估算的时间，真正的花费时间还取决于整体负载（特别是磁盘相关的负载）。如果重平衡是由于磁盘组中的一个或者多个磁盘损坏造成的，那么这个阶段还会对不满足冗余度要求的数据做镜像。

注意：磁盘组在rebalance过程中并不会去修复存在逻辑错误或物理错误的数据，在12C中通过新增的一个ASM-scrubbing功能可以做到这一点，请参考本系列的【ASM data scrubbing】篇。

第三阶段是磁盘的compacting阶段（ASM 11.1.0.7版本及以上支持），这个过程是将磁盘上存的数据尽可能的移动到磁盘的外圈磁道上去（机械盘的外圈速度更快），以提供更高的性能。需要注意的是，在这个阶段，GV$ASM_OPERATION.EST_MINUTES会一直显示为0，这个显示为0的“特性”将来可能会被优化。这个阶段所花费的时间，取决于磁盘组中磁盘的数量、重平衡的原因等等，一般情况下，这个阶段花费的时间会比第二阶段短很多。重平衡过程需要注意的点：

● 重平衡是以文件为基本操作单位的，跟过arb进程的跟踪文件可以观察到。● 一个正在进行的重平衡可能会被重启，例如存储的配置改变（我们修改了配置或者由于故障导致配置改变），如果是人为导致了重平衡的失败，那么需要手工的触发重平衡才行。● 在同一个集群中，每个实例只能有一个磁盘组在做重平衡操作。如果同时指定多个磁盘组做重平衡，那么ASM会尽量把重平衡动作在集群中可用节点上并行执行，如果没有其他可用节点了，那么就会串行执行。● 重平衡过程中，如果遇到ASM实例重启，那么实例起来后重平衡操作会继续进行。● 在执行ALTER DISKGROUP 命令对磁盘进行添加、删除、调整大小时，可以指定REBALANCE子句，以及相关的POWER值、WAIT/NOWAIT选项。

Tuning rebalance operations 

在以下两种个情况下，重平衡的并行度是ASM_POWER_LIMIT参数指定的值：● 执行ALTER DISKGROUP 进行磁盘组操作时，不指定POWER参数 ● 当隐式的触发重平衡时，如对磁盘组中磁盘进行添加/删除/调整大小我们可以动态的调整该参数，从而调整重平衡的并行度。高的并行度会缩短重平衡的花费时间，但是时间并不是随着并行度递增而线性减少，这取决于存储的整体负载、可用的吞吐量和底层磁盘的响应速度。在重平衡过程中，我们可以动态调整并行度。通过ALTER DISKGROUP ... REBALANCE POWER N命令来指定一个新的并行度。修改并行度，会停止当前的重平衡，然后根据新的POWER参数重新开始重平衡过程。

虽然修改并行度会导致停止当前的重平衡，开启新的重平衡，但是根据我的观察，重平衡可以增量进行，例如旧的重平衡已经完成了对100号文件的重平衡操作，那么下次重新启动重平衡会从101号文件开始，100号文件会被跳过，或者是在做一些检查后很快的跳过。

Relevant initialization parameters and disk group attributes

ASM_POWER_LIMIT这个参数是磁盘组进行重平衡操作时默认的并行度。在11.2.0.2之前它的取值范围是0-11，从11.2.0.2版本开始，它的取值范围是0-1024。当然这取决于磁盘组的属性COMPATIBLE.ASM的设定值（见下文）。ASM_POWER_LIMIT默认值是1，当你将这个值指定为0时，会禁止重平衡操作。● 将磁盘组的COMPATIBLE.ASM参数设置为11.2.0.2及以上，ASM_POWER_LIMIT的取值范围是0-1024。● 当COMPATIBLE.ASM参数被设置为11.2.0.2之前时，ASM_POWER_LIMIT的取值范围是0-11。● 当你通过ALTER DISKGROUP REBALANCE命令将POWER值指定为0时，会停止重平衡操作。（除非你触发 Bug 7257618）。_DISABLE_REBALANCE_COMPACT设置初始化参数_DISABLE_REBALANCE_COMPACT=TRUE会禁止磁盘组重平衡的第三个阶段（压缩阶段）。该参数对所有的磁盘组生效。_REBALANCE_COMPACT这是个隐含参数，设置_REBALANCE_COMPACT=FALSE会禁止磁盘组重平衡的第三个阶段（压缩阶段）。该参数指定单个磁盘组，对单磁盘组生效。_ASM_IMBALANCE_TOLERANCE这个隐含参数控制磁盘组中磁盘最大容忍的不平衡比例，默认值是3%。 比如同一个磁盘组中，A磁盘的使用率不会和B磁盘使用率相差超过3%，否则会触发自动重平衡。

Processes

下面这个表总体概括了重平衡过程中，涉及到的后台进程：

在重平衡过程中，ARBn进程会在后台进程dump文件目录生成trace文件，记录重平衡的过程。

Views

在ASM实例中，V$ASM_OPERATION视图会显示在本实例上执行的时间较长的ASM操作，GV$ASM_OPERATION视图会展示集群中的所有节点上的执行的时间较长的ASM操作。在重平衡的过程中，OPERATION字段会显示REBAL，STATE字段会显示重平衡操作的状态，POWER字段会显示重平衡的并行度，EST_MINUTES会显示重平衡操作还需要执行多长时间。视图V$ASM_DISK用来显示ASM磁盘的相关信息，在rebalance期间，视图的STATE列展示了rebalance期间磁盘的当前状态。

Is your disk group balanced

通过在ASM实例中执行下面的命令，可以得到磁盘组上面数据平衡的状态。

SQL> column "Diskgroup" format A30
SQL> column "Imbalance" format 99.9 Heading "Percent|Imbalance"
SQL> column "Variance" format 99.9 Heading "Percent|Disk Size|Variance"
SQL> column "MinFree" format 99.9 Heading "Minimum|Percent|Free"
SQL> column "DiskCnt" format 9999 Heading "Disk|Count"
SQL> column "Type" format A10 Heading "Diskgroup|Redundancy"
SQL> SELECT g.name "Diskgroup",
100*(max((d.total_mb-d.free_mb)/d.total_mb)-min((d.total_mbd.
free_mb)/d.total_mb))/max((d.total_mb-d.free_mb)/d.total_mb) "Imbalance",
100*(max(d.total_mb)-min(d.total_mb))/max(d.total_mb) "Variance",
100*(min(d.free_mb/d.total_mb)) "MinFree",
count(*) "DiskCnt",
g.type "Type"
FROM v$asm_disk d, v$asm_diskgroup g
WHERE d.group_number = g.group_number and
d.group_number <> 0 and
d.state = 'NORMAL' and
d.mount_status = 'CACHED'
GROUP BY g.name, g.type;
Percent Minimum
Percent Disk Size Percent Disk Diskgroup
Diskgroup Imbalance Variance Free Count Redundancy
------------------------------ --------- --------- ------- ----- ----------
ACFS .0 .0 12.5 2 NORMAL
DATA .0 .0 48.4 2 EXTERN
PLAY 3.3 .0 98.1 3 NORMAL
RECO .0 .0 82.9 2 EXTERN

注意：上面的查询摘录自Oracle Press book Oracle Automatic Storage Management, Under-the-Hood & Practical Deployment Guide, by Nitin Vengurlekar, Murali Vallath and Rich Long.

关于译者

吴栋，沃趣科技售前工程师，专注于数据库服务及高性能解决方案。

往期精彩

关于沃趣

杭州沃趣科技股份有限公司创建于2012年，创始团队为原阿里巴巴数据库及系统运维团队核心骨干，凭借着多年的运维经验，为行业客户提供专业数据库、系统相关的服务和产品；专注为用户提供基于高性能、高可用、可扩展的开放数据库云平台解决方案的国产厂商。

沃趣科技的产品已广泛应用于证券、保险、医疗、广电传媒、银行、电信、能源电力、快递物流、公共事业、大型企业等，为这些行业用户持续提供行业解决方案及服务支持。

研发中心位于杭州，同时在北京、上海、广州、南京、兰州、沈阳建立了分支机构,建立了辐射全国的销售和服务体系。

我们始终坚信，数据是驱动企业创新的源动力！坚持围绕企业数据库做好一件事

                      ——让高性能触手可及！