Find Communities by: Category | Product

在大多数的CelerraVNXData Mover配置中,出于高可用性的需求,最常见的配置都会配置至少一个备用Data Mover,当主DM发生了问题或者因为管理维护需要而重启的时候,主备切换就可能发生以保证用户的数据访问。然而Data Mover的主备切换到底是做了什么?对用户又有什么样的影响?需要花多长时间才能完成呢?下文就这3个问题做了一定程度的解析。

DM发生failover的过程:

  1. Data mover上发生failure
  2. CS检测到这个failure
  3. CS重新配置系统以使备用的DM接管发生问题的DM的业务和身份(包括名字,ipMAC地址等各种配置);并且CS还将发生问题的DM重启,然后载入一个基本的配置(没有load任何配置或挂载任何文件系统),这么做是为了避免两个DMload配置尝试去接管生产从而发生“精神分裂”的情况。
  4. 寂寞地等待了许久的备份DM,终于等到主DM发生问题,可以大展拳脚,于是它顶掉了原配,开始首先初始化一些自身的配置(例如转载各种driver,打开自己的网卡,给它们分配好IP地址,根据parameter配置文件设置各种参数等),紧接着初始化一些外部部署的配置(包括挂载文件系统,设置CIFS server等)。
  5. 此时DMfailover算是完成了。理论上用户即应该可以访问数据。取决于用户的客户端(以及使用的协议),failover所花的时间可能会对用户体验造成不同的影响。例如windows用户势必需要重新login一次share(当然如果用户是使用应用程序在访问或者映射了网络盘,这个重新登录的过程会由应用程序或操作系统自动完成,而用户只感到顿卡),重新login的原因是备份的DM只会继承配置文件中的配置,而不会继承用户之前loginshare时记录在DM内存里的缓存,这些缓存会随着DM重启而消失;而对于Linux的用户,默认的mount方式会不断的尝试通过NFS将文件系统mount起来,因而经历过几次timeout之后,Linux用户就又恢复使用了。

 

总的来说,failover得快,Windows用户可能遭遇顿卡而后恢复,Linux用户比较可能毫无知觉(除非一直持续读写,或failover的瞬间正在读写)。

failover得慢,windows用户可能遭遇的就是OS或应用程序的timeout/最终网盘挂掉等待手工mount,而Linux用户可能就要被卡死,等待操作系统不断的mount这个NFS share直到用户决定终止。

 

Failover所花的时间似乎颇为神秘,使得其对用户体验的影响难以估计,有的存储管理员也不敢轻易使用,生怕failover花的时间长了,给用户带来长时间的DU而接到抱怨。

 

由于触发failover的原因不同(DM panic,手动触发,DM被物理移除等),计算failover所需时间的方法也不同。并且由于各种变量(文件系统数量,配置量)还有各种常量(NBS服务由备用DM提供的切换过程使用的时间),甚至变化的常量(随着各个OE版本变化而改变的一些值譬如初始化ipDM独立配置的时间),我们无法给出一个具体的时间,但是可以提供的是一个大概的计算方法以估计failover的时间。

 

总的来说,failover的完成需要3部分的时间:

  1.   检测到问题所需要的时间。
    • (a) 对于手动failover,这段时间主要相当于正常关闭一台DM所需的时间。因为是用户手动触发,系统需要首先正常关机当前的主DM,然后重启它,才能开始真正的failover的过程。而正常关机所花的时间又因为各种变量而不同,取决于当前DM有多少客户端连接,当前打开的文件数量,lock的情况,文件系统数量,需要flush到客户端或后端阵列的缓存的数据量等等。那就是另外一个话题了。
    • (b) 而对于最大可能的failover,则是由于DM panic造成的自动failover,基本会在12秒内检测到panic,然后约10秒之内生成dump文件以便事后分析RCA。如果是panic的话,这段时间大约就是2+10=12秒左右。
    • (c) 如果DMCS的两条内部网络128.221.252.0/24128.221.253.0/24都断开(无法ping通),那么也会发生failover,而这个情况需要12秒的时间检测到。由于两条内部网络4秒检测一次,当3次检测都失败,则触发failover
    • (d) 还有其他情况也会触发failover,不过相比前者都不容易遇到,就不一一赘述,可以查看high availability的白皮书。
  2.   一段固定的时间开销,根据OE版本的不同而不同。在比较老的5.06.0版本需要花费至少15秒,而在新版的7.07.1只需6
  3. 一段变量的时间,究竟需要多久取决于DM需要mount的文件系统的数据加上快照的数据以及DM mount它们的速度。文件系统和快照越多,所需时间越长;DM mount的速度越快,所需时间越短。

DM上文件系统的数量和快照的数量对于每个用户来说是固定的,而DM mount文件系统和快照的速度则随着OE版本的变化而有所改进,就笔者所知7.0.45File OE速度约为每秒20+个文件系统。Mount 1700个文件系统大约要65秒左右。

 


 

 

因此failover所需的时间=检测故障的时间(1+ 根据OE版本固定的时间开销(2+  mount文件系统和快照所需的时间(3)(文件系统+快照的数据量/DM mount的速度)

 

注意:failover完成后表示DM已经available了,但是并不代表用户就一定立即可用,在不同的用户环境,有可能还会有各种各样外部的延迟导致用户并不是立刻访问到数据,例如备份的DM起来之后和DNS服务器和DC,或者CAVA还有其他种种相关服务的交互,还有客户端主机重新登录share的各种时间开销都有可能延长服务恢复的等待时间。

 

以上就是Data Moverfailover中的所作所为以及每一部分操作大约的时间消耗,也许对于估算一个确切的值没有什么用(还无法做到),但是相信对于技术支持回答客户问题,以及存储管理员预估failover对生产的影响的判断,还是能起到一定的支持作用。

上个月的“CLARiiON/VNX技术支持常见问题解答”一文列举了CLARiiON/VNX十个常见问题,想必大家都已经烂熟于心了吧!但这些问答肯定远远无法涵盖存储设备丰富多彩的功能与特性,各位存储达人是否又遇到新问题了呢?那我们来看看以下六个问题是否正中各位下怀吧!


1.橙色灯是否一定说明有硬件故障呢?


一般来说,我们可以通过观察阵列上是否有橙色灯来判断阵列上是否有硬件问题。但是这个判断标准在CLARiiON CX4-120 / CX4-240 /CX4-480上并不一定成立,请看下图:

1.JPG.jpg

若你使用的是CLARiiON CX4-120 / CX4-240 /CX4-480的阵列,可能会在控制器下方看到如上图所示的LED指示灯,他们位于CPU主板把手处。这组LED灯的分布样式在日常使用中是固定的,存在于比较老的一批CPU组件上,用于显示SPPOST阶段的状态。新批次的CPU组件已经将这组指示灯去掉了,所以没有这组灯也是正常的哦。

 

2.Unisphere/Navisphere为何无法正常显示?


Unisphere/Navisphere是用户管理阵列的图形界面,但在某些电脑上它们却不能正常显示,比如下图这种情况:

2.JPG.jpg


在这种情况下,请查看一下本机的Java版本:

3.JPG.jpg


若计算机安装了Java 1.7的版本,请Java控制面板上将”Enable the next-generation Java Plug-in”前的勾去掉,重启浏览器后重试:

5.JPG.jpg


若还是无法访问Unisphere,请卸载掉Java 1.7版本并安装1.6版本后重试。

 

3.卸载了一个盘柜后,为何还能在图形界面看到这个盘柜呢?


有的时候,你可能需要安装新的盘柜做一些测试或者数据分布调整,等调试完毕后需要再把这些盘柜卸载掉。然而当卸载完盘柜后,你可能会发现图形界面上依然存在者着这些盘柜,同时系统警报灯常亮,而且还会源源不断地接收到类似以下的报警信息,暗示卸载盘柜的操作有误:

7.JPG.jpg

请你务必在卸载盘柜前后做以下的步骤:


卸载前:

  1. Delete这些盘柜上的LUN
  2. Delete 这些盘柜上的Raid

卸载后:重启两个SPManagement Server

 

若你在删除相关LUN以及Raid组前就把盘柜卸载了,请把它们重新连接后按照正确步骤再操作一遍。若已经无法找到卸载下来的盘柜,请联系EMC800技术支持中心协助处理该问题。

 


4.向Raid Group或者Pool中加盘的操作对于CLARiiONVNX有何不同?


存储管理员在对存储日常维护中,或许希望能够向Raid Group或者Pool里面加盘来增加磁盘并发读写性能或者增大空间。CLARiiONVNX在这个问题上略有一些不同,请参加以下表格:


产品


CLARiiON


VNX


是否可以向Raid组中加盘


Y


N


是否可以向Pool中加盘


Y


Y


备注


1.不能对Raid 6, Raid 1, Raid 3,Single Disk以及HSRaid组中加盘;

2.Raid组中最多只能容纳16块盘


R32开始,Pool里面每个Tier (Capacity/Performance/Extreme
  Performance)可以配置不同的Raid Level

 

5.为何HP-UX的主机在图形界面显示没有”Logged In”,但是却能够正常使用?


HP-UXHBA卡只有在有IO、并且IO持续时间足够长的情况下才会在Unisphere/Navisphere上显示”Logged
In”。可以通过以下方式来测试HP-UX是否和存储的连接正常:


A.HP-UX主机上运行以下dd命令(其中c#t#d#是一个存储上的设备)

# dd if=/dev/rdsk/c#t#d# of=/dev/null bs=512
count=10000000

10000000+0 records in
10000000+0 records out


B.刷新存储Initiators的状态,此时应该能看到HBA卡的状态是“Logged In”的。

 


6.为何每次收集性能日志只能收到最近的一份Nar File? 或者为何收集了几天就自动停止了?


在开启收集性能日志的”Data Logging”窗口上,有一些参数需要注意:

8.JPG.jpg


A. Real Time Interval:

若阵列上安装了UnisphereAnalyzer/NavisphereAnalyzer Enabler, 你就可以调整这个参数。Real Time Interval设定的是实时性能监控的采样间隔,数值越小,采样频率越高,对阵列性能影响越大(若你的阵列上没有安装Analyzer Enabler,则该项目呈现灰色,无法设置);


B. Archive Interval:

这个参数设定的是归档性能监控的采样间隔,数值越小,采样频率越高,对阵列性能影响越大。一份完整的性能日志(.nar/ .naz文件)包含155个采样点,若将采样间隔设定成120s,那完成一份性能日志的时间就是5小时10分钟;


C. Periodic Archiving:

若没有勾选这个选项,无论收集多久的性能数据,你都只会收集到最近的一份性能日志。因此若需要收集一段时间跨度较长的性能日志,请务必将这个项目勾选上;


D. Stop Automatically After:

该选项用来设定自动停止性能数据收集的时间,可选范围是1~30天。需要注意的是,这个参数只能在停止性能数据采集的时候才能设置.

 

 

好了,这次的CLARiiON/VNX六大常见问题分享就到这里,希望大家能够有所收获。若你有其他希望了解的问题或者疑问,可以通过跟帖的方式提出,并请继续关注本博客,我们会在下次的文章中为你解答。

本文列举了Clariion/VNX用户和EMC现场支持经常咨询的一些问题,掌握了这些可以帮助存储管理员更加得心应手的管理、维护存储,帮助EMC现场支持更加便捷的维修故障。

 

 

1.如何通过NaviCLI快速获得磁盘的备件号TLA part number呢?

用下列命令行:

输入:naviseccli -h 10.32.106.174 getdisk 1_0_0 -tla

输出:Bus 1 Enclosure 0  Disk 0

Clariion TLA Part Number: 005049274

 

 

2. 如果更改LUN重建和后台校验的速度呢?

对于传统 traditional LUNs来说,更改Rebuild Priority 和 Verify Priority。

方法一、从网页管理界面,选择LUN,右击选择属性,修改Rebuild Priority。

2013-8-13 13-52-49.png

 

方法二、用命令行navicli h  <SP_ IP_address>  getlun  <ALU_number>查看当前优先级。

然后用命令行navicli h <SP_IP_address> chglun  l  <ALU_number>  -r  <Priority>  配置新的优先级。

 

 

3. 如果更改Meta LUN的扩展速度呢?

方法一、从网页管理界面,选择LUN,右击选择属性,修改Rebuild Priority。

2013-8-13 13-53-12.png

 

方法二、命令行 metalun -modify

 

 

4.  在Thin LUN上运行的文件系统上我已经删除了一些文件,为什么在Unisphere界面里却看不见有剩余的空间呢?

“删除文件”这个操作时文件系统层面的操作。VNX不能识别文件系统层面的操作,所以被删除的空间实际上并没有被释放。也就是说Thin LUN在删除文件后并不会自动压缩。想要将空间释放的办法是,删除原来的大的LUN,并创建一个新的LUN。

 

 

5. 磁盘柜的位置是如何确定的呢?

1) CLARiiON阵列的 磁盘柜类别是DAE2P/3P, 用户或者EMC工程师按着LCC的按键即可以手动设置磁盘的位置。如下图所示,也就是说经过人为设置,总线Bus1 可以有磁盘柜Enc标号0和2,没有标号1也无妨。

2013-8-13 13-53-25.png

 

2) VNX阵列使用磁盘柜类别是 DAE6S,LCC上没有按键。 SAS总线会扫描阵列后端的布局,并自动决定磁盘柜的位置。如下图所示,这个位置通过LED灯的形式显示在DAE上。

2013-8-13 13-53-37.png

 

 

6. 为什么在某些LUN上无法创建镜像或者添加次要镜像呢?

如果LUN上运行有其他的复制软件时,我们无法在删除LUN,或者在上创建镜像。

1) 先用下列命令行查看LUN上配置是否配置有复制软件:

navicli -h <IP_address> getlun -messner <LUN_number> -stack

2) 然后用下列命令可以删除LUN上的软件:

naviseccli  -h <SP_IP_address> mirror -async -setfeature -off -lun <LUN_number> 或者 naviseccli  -h <SP_IP_address> mirror -sync -setfeature -off -lun <LUN_number>

 

详情请参考EMC知识库文章emc287481/emc120515

 

 

7. 如何将Thick LUN转变成Thin LUN呢?

目前还不支持将Thick LUN直接转变成Thin LUN,但是我们可以将从Thick LUN上的数据迁移至Thin LUN。

下面是不同类别的LUN互相转换的表格。

FeatureSource LUN  类别Dest LUN类别注明
迁移Migration
Traditional/Thick/Thin/Meta
Traditional/Thick/Thin/Meta没有限制
克隆CloneTraditional/Thick/Thin/MetaTraditional/Thick/Thin/Meta没有限制
压缩CompressionTraditional/Thick/Thin/MetaThin
镜像 MirrorViewTraditional(>=R29)/Thick/Thin/MetaTraditional(>=R29)/Thick/Thin/Meta如果Secondary是Thin LUn的话,需要保证Pool有足够的容量
预留空间 Reserved LUN PoolTraditional/Thick LUN Onlyn/a推荐RAID类别为RAID1/0, RAID5
克隆Private LUNTraditional LUN Onlyn/a>=1GB
镜像Mirrorview WILTraditional LUN Onlyn/a>=128MB

 

 

8. Trespass mine和trespass all这两个命令有什么区别吗?

naviseccli –h spa trespass all                       //所有的用户LUN都会被trespass到SPA上

naviseccli  -h spa trespass mine                 //默认SP Owner属于SPA的用户LUN才会被trespass到SPA上

 

 

9. VNX的网络管理端口和服务端口在什么部位呢?

下面是VNX的后视图。可以看到有两个网络端口。左边有I标志的是服务端口,右边的是网络管理端口。

2013-8-13 13-53-55.png

 

 

10. 更换磁盘时,如何查看LUN的Rebuilding进度?

右击LUN,选择属性。

2013-8-13 13-54-07.png

 

 

以后我们会陆续汇总一些常见问答、维护存储的经验分享,请继续关注本博客。

 

 

附录:

1. 更多clariion/VNX命令行,请参考Navisphere Command Line Interface (CLI) Reference

2. 更多VNX硬件介绍,请参考 VNX Introduction

Filter Blog

By date:
By tag: