Find Communities by: Category | Product

1 2 Previous Next

工程师手记

23 Posts authored by: EMC备份恢复远程支持部

众所周知,NetWorker可以在备份组结束后自动发起克隆任务。这样对于有数据多份要求的客户有很多的便利,他们可以保证每次的备份数据都可以正常保存两份。而且他们不需要去单独配置克隆任务或者发起克隆命令。

 

那么NetWorker会根据什么设置去执行克隆作业呢?大家都知道在组属性中我们可以选择在备份执行后发起克隆,发起的方式有如下图两种:

 

克隆模式:

Start on each save set completion

Start on group completion

nw1.png

 

 

那么我们就根据这两种不同的配置来解释一下克隆的工作原理

Start on Group Completion

==========

1. 克隆任务在该组所有备份任务完成后发起。

2. nsrclone发起之前,备份服务器会去检查备份的媒体数据库来确认需要克隆哪些存储集

3. 备份服务器的媒体数据库通过这个检索规则来确认只有最近的备份数据才会被克隆任务执行:“save set start time” >= “save group start time”

4. 但检索媒体数据库完成,所有需要克隆的存储集的SSID都会被返回给nsrclone。如下面命令行:

nsrclone -s bdi-prd-nwk.corp.danamon.co.id -v -D 5 -b ddboost_sql_bsd_clone -C 1 -S -f < 497909124 514686338

 

所以我们需要明白克隆的完成需要同时参考客户端和服务器。“save set start time”这个参数是由备份客户端提供的,也就是客户端启动备份的时间。但是“save group start time” 这个参数则是由备份服务器提供。这个是备份组发起的时间。如果备份服务器和备份客户端之间的时间有差异,那么就可能会出现有些数据不会被克隆的情况。 也就是我们常说的数据丢失。

 

 

如果需要了解媒体数据库检索的具体情况,可以对nsrd开启-D5或者以上,结果会返回检索命令。

On Each Saveset Completion

==========

1. 在备份组发起的时候,克隆任务就发起来了。

2. 一个临时文件会创建出来作为克隆的源文件。默认路径是:\\nsr\\tmp\\sg\\<groupName>\\<.groupName>

3. 命令nsrclone会根据下面的参数来运行:

nsrclone -s bdi-prd-nwk.corp.danamon.co.id -v -D 5 -b ddboost_sql_bsd_clone -C 1 -i "D:\\Program Files\\EMC NetWorker\\nsr\\tmp\\sg\\PRD-Adhoc-SQL-Cumulative\\.PRD-Adhoc-SQL-Cumulative" -g PRD-Adhoc-SQL-Cumulative

4. 每当一个save任务运行结束,就会把SSID写入到\\nsr\\tmp\\sg\\<groupName>\\<.groupName>

5. 在备份组完成之后,这个临时文件就会被删除。

 

所以为了保证克隆精确完成,我们必须保证在组启动前这个临时文件不存在,同时在组备份成功完成后这个临时文件不再存在。同时如果我们对于克隆的存储集有疑问,也可以打开这个临时文件检查。

 

 

Mandy Xu

Technical Support Engineer, NetWorker

Dell EMC | Customer Service

 

NetWorker有一个非常重要的参数,就是索引。这个参数对于备份和恢复都起到很大的作用。客户基本都知道索引的概念,但是如何有效地管理索引,如何更好的利用索引,却很多客户不太清楚具体的流程和操作。这里就和大家简单的介绍一下索引。

 

索引在生活和工作的很多方面都存在,每个人都应该对索引感到不陌生。我们的图书馆系统就有庞大的索引系统。您需要借阅一本图书,可以在电脑里面简单的根据书名,作者或者其它信息搜索,搜索结果告诉您图书的数量,具体的存书位置,是否可以借阅,如果借出什么时候可以归还等等。所有借阅者可以简单的通过网络来了解图书馆庞大的藏书系统。

 

NetWorker的索引客户基本上无法接触,客户端文件索引是NetWorker服务器的控制文件数据库之一,其它两个是resmm,这些数据库跟踪客户端备份的每个文件(路径名),从而允许用户浏览特定时间点的文件备份。NetWorker服务器在每个物理客户端上创建并且维护一个CFI.

 

客户端的文件索引存储由备份客户端生成的有关客户端的备份文件和目录的信息。对于备份的每个文件和目录,CFI将包含其路径名,文件属性(如权限和所有权)以及表明何时备份包含该文件的存储集的时间戳,NetWorker的客户端将跟踪信息发送至各自的CFI,后者驻留在NetWorker服务器上。每台物理客户端有一个CFI

 

经常会有用户突然发现自己的磁盘空间突然满了,源头就是索引文件夹过大。这个时候往往客户就会有疑问:为什么一个索引文件夹可以达到几十个G?这往往有两个可能性:

1. 客户设置的浏览策略过长。这个浏览策略决定了文件在CFI里面的保留时间。这个浏览策略的设置如下:

4271.png

2. 存储集的文件系统过于复杂。如果碎文件过多,也会影响索引的大小。

 

对于索引文件过大,这个问题怎么解决呢?对于这个问题,我们的解决方案有很多种。下面给大家简单介绍一下各种方法的实用性。

1. 可以通过命令行来修改浏览时间。这个命令的格式如下:

4272.png

2. 可以在NMC -> Media下面去删除索引:

4273.png

3. 我们还有一个解决方案。就是可以把索引文件夹整体迁移到其它硬盘下面。这个操作可以在客户端属性下面配置:

4274.png

 

通过及时地管理和维护索引信息,我们既可以有效地实现定时恢复,也不会造成备份环境的故障。这样才能高效的管理我们复杂的备份环境。

 

Mandy Xu

NetWorker技术支持工程师

Data Protection and Availability Solution

EMC客户服务

简介

作为技术支持,我们遇到过很多备份/恢复慢的问题。导致慢的因素各种各样,最常见的是网络带宽。如何判断网络带宽是否为瓶颈,今天和大家介绍一款利器iperf iperf是一款可以测量最大网络带宽的工具, 支持多种协议比如TCP/UDP和多参数搭配。常用功能:

    

TCP and SCTP 

  • 测试网络带宽
  • 报告MSS/MTU

      

UDP

  • 客户端创建指定带宽的UDP
  • 测量丢包
  • 测量延迟
  • 支持多播

          

下载

Avamar 服务器上本身自带了iperf工具(默认执行路径 /usr/local/avamar/bin),不需要安装,直接打命令iperf就可以使用

Linux客户端: 可以直接从Avamar 服务器上将iperf拷贝到客户端使用

Windows客户端:https://linhost.info/2010/02/iperf-on-windows/

 

使用方法

iperf的自带帮助文档很强大,运行命令iperf --help 可以将具体的参数列出


 

命令行选项


 

 

描述


 

 

客户端与服务器共用选项


 

 

-f, --format [bkmaBKMA]


 

 

格式化带宽数输出。支持的格式有:

  'b' = bits/sec 'B' = Bytes/sec

  'k' = Kbits/sec 'K' = KBytes/sec

  'm' = Mbits/sec 'M' = MBytes/sec

  'g' = Gbits/sec 'G' = GBytes/sec

  'a' = adaptive bits/sec 'A' = adaptive Bytes/sec

  自适应格式是kilo-和mega-二者之一。除了带宽之外的字段都输出为字节,除非指定输出的格式,默认的参数是a。

  注意:在计算字节byte时,Kilo = 1024, Mega = 1024^2,Giga = 1024^3。通常,在网络中,Kilo = 1000, Mega = 1000^2, and Giga = 1000^3,所以,Iperf也按此来计算比特(位)。如果这些困扰了你,那么请使用-f b参数,然后亲自计算一下。


 

 

-i, --interval #


 

 

设置每次报告之间的时间间隔,单位为秒。如果设置为非零值,就会按照此时间间隔输出测试报告。默认值为零。


 

 

-l, --len #[KM]


 

 

设置读写缓冲区的长度。TCP方式默认为8KB,UDP方式默认为1470字节。


 

 

-m, --print_mss


 

 

输出TCP MSS值(通过TCP_MAXSEG支持)。MSS值一般比MTU值小40字节。通常情况


 

 

-p, --port #


 

 

设置端口,与服务器端的监听端口一致。默认是5001端口,与ttcp的一样。


 

 

-u, --udp


 

 

使用UDP方式而不是TCP方式。参看-b选项。


 

 

-w, --window #[KM]


 

 

设置套接字缓冲区为指定大小。对于TCP方式,此设置为TCP窗口大小。对于UDP方式,此设置为接受UDP数据包的缓冲区大小,限制可以接受数据包的最大值。


 

 

-B, --bind host


 

 

绑定到主机的多个地址中的一个。对于客户端来说,这个参数设置了出栈接口。对于服务器端来说,这个参数设置入栈接口。这个参数只用于具有多网络接口的主机。在Iperf的UDP模式下,此参数用于绑定和加入一个多播组。使用范围在224.0.0.0至239.255.255.255的多播地址。参考-T参数。


 

 

-C, --compatibility


 

 

与低版本的Iperf使用时,可以使用兼容模式。不需要两端同时使用兼容模式,但是强烈推荐两端同时使用兼容模式。某些情况下,使用某些数据流可以引起1.7版本的服务器端崩溃或引起非预期的连接尝试。


 

 

-M, --mss #[KM}


 

 

通过TCP_MAXSEG选项尝试设置TCP最大信息段的值。MSS值的大小通常是TCP/IP头减去40字节。在以太网中,MSS值 为1460字节(MTU1500字节)。许多操作系统不支持此选项。


 

 

-N, --nodelay


 

 

设置TCP无延迟选项,禁用Nagle's运算法则。通常情况此选项对于交互程序,例如telnet,是禁用的。


 

 

-V (from v1.6 or higher)


 

 

绑定一个IPv6地址。

  服务端:$ iperf -s –V

  客户端:$ iperf -c <Server IPv6 Address> -V

  注意:在1.6.3或更高版本中,指定IPv6地址不需要使用-B参数绑定,在1.6之前的版本则需要。在大多数操作系统中,将响应IPv4客户端映射的IPv4地址。


 

 

服务器端专用选项


 

 

-s, --server


 

 

Iperf服务器模式


 

 

-D (v1.2或更高版本)


 

 

Unix平台下Iperf作为后台守护进程运行。在Win32平台下,Iperf将作为服务运行。


 

 

-R(v1.2或更高版本,仅用于Windows)


 

 

卸载Iperf服务(如果它在运行)。


 

 

-o(v1.2或更高版本,仅用于Windows)


 

 

重定向输出到指定文件


 

 

-c, --client host


 

 

如果Iperf运行在服务器模式,并且用-c参数指定一个主机,那么Iperf将只接受指定主机的连接。此参数不能工作于UDP模式。


 

 

-P, --parallel #


 

 

服务器关闭之前保持的连接数。默认是0,这意味着永远接受连接。


 

 

客户端专用选项


 

 

-b, --bandwidth #[KM]


 

 

UDP模式使用的带宽,单位bits/sec。此选项与-u选项相关。默认值是1 Mbit/sec。


 

 

-c, --client host


 

 

运行Iperf的客户端模式,连接到指定的Iperf服务器端。


 

 

-d, --dualtest


 

 

运行双测试模式。这将使服务器端反向连接到客户端,使用-L 参数中指定的端口(或默认使用客户端连接到服务器端的端口)。这些在操作的同时就立即完成了。如果你想要一个交互的测试,请尝试-r参数。


 

 

-n, --num #[KM]


 

 

传送的缓冲器数量。通常情况,Iperf按照10秒钟发送数据。-n参数跨越此限制,按照指定次数发送指定长度的数据,而不论该操作耗费多少时间。参考-l与-t选项。


 

 

-r, --tradeoff


 

 

往复测试模式。当客户端到服务器端的测试结束时,服务器端通过-l选项指定的端口(或默认为客户端连接到服务器端的端口),反向连接至客户端。当客户端连接终止时,反向连接随即开始。如果需要同时进行双向测试,请尝试-d参数。


 

 

-t, --time #


 

 

设置传输的总时间。Iperf在指定的时间内,重复的发送指定长度的数据包。默认是10秒钟。参考-l与-n选项。


 

 

-L, --listenport #


 

 

指定服务端反向连接到客户端时使用的端口。默认使用客户端连接至服务端的端口。


 

 

-P, --parallel #


 

 

线程数。指定客户端与服务端之间使用的线程数。默认是1线程。需要客户端与服务器端同时使用此参数。


 

 

-S, --tos #


 

 

出栈数据包的服务类型。许多路由器忽略TOS字段。你可以指定这个值,使用以"0x"开始的16进制数,或以"0"开始的8进制数或10进制数。

  例如,16进制'0x10' = 8进制'020' = 十进制'16'。TOS值1349就是:

  IPTOS_LOWDELAY minimize delay 0x10

  IPTOS_THROUGHPUT maximize throughput 0x08

  IPTOS_RELIABILITY maximize reliability 0x04

  IPTOS_LOWCOST minimize cost 0x02


 

 

-T, --ttl #


 

 

出栈多播数据包的TTL值。这本质上就是数据通过路由器的跳数。默认是1,链接本地。


 

 

-F (from v1.2 or higher)


 

 

使用特定的数据流测量带宽,例如指定的文件。

  $ iperf -c <server address> -F <file-name>


 

 

-I (from v1.2 or higher)


 

 

-F一样,由标准输入输出文件输入数据。


 

 

杂项


 

 

-h, --help


 

 

显示命令行参考并退出 。


 

 

-v, --version


 

 

显示版本信息和编译信息并退出。


 

 

使用例子

我们以下面的环境为例展示如何测量Avamar客户端和Avamar服务器之间的最大带宽

Avamar 服务器:10.32.167.84

Avamar 客户端:10.32.198.93

  1. Avamar服务器上,运行iperf的服务器模式 (命令如下)

     iperf -s -i 1

     注释: '-s' 代表运行在服务器模式(接受数据); '-i 1' 代表以1秒为间隔做测试

   2.  Avamar客户端上运行客户端模式

     iperf -c 10.32.167.84 -i  1

   注释: '-c' 代表运行在客户端模式(发送数据); '-i 1' 代表以1秒为间隔做测试

Avamar服务器上看到的结果如下

1.png

Avamar客户端上看到的结果如下

2.png

从返回的结果,我们可以判断出这台客户端和Avamar服务器之间的最大平均带宽是51.6 Mbytes/sec; 换算成小时单位是 185760 MB/hour (181GB/hour)。也就是说这台服务器和Avamar客户端最大网络带宽是每小时181G。具体到Avamar,一般能用到最大带宽的50-70% 91--126GB/hour

    

附录

How to run iperf to compare performance between Avamar Server and client

https://support.emc.com/kb/305200

 

Jason Ma

Avamar技术支持工程师

Data Protection and Availability Solution

EMC客户服务

 

 

     1. DataDomain复制分为两种,一种由DataDomain控制(DataDomain Native Replication),另一种由备份软件控制(Managed File Replication)。

   

 

 

     2. 使用DataDomain复制需要在两端DataDomain设备安装复制授权许可(Replication License)。

 

 

 

     3. DataDomain复制的特点是带宽高效利用,因为
          1)它复制的是重复数据删除后并压缩过的数据;
          2)复制时源端设备发送复制数据的索引(Index)到目标端设备,如果索引已存在,那么目标端设备创建文件并引用现有索引;如果索引不存在,那么源端设备发送复制数据的字段(Segment)到目标端设备。
          3)发送索引只占用少量网络带宽。

 

 

 

     4. DataDomain控制的复制分为三类,分别是Directory,Mtree和Collection。它们复制的是整个目录或者文件系统。一旦配置并初始化,复制将自动运行。
          1)Directory Replication复制的是/data/col1/backup下的子目录;
          2)Mtree Replication复制的是除/data/col1/backup的其它Mtree;
          3)Collection Replication复制的是整个文件系统,包括backup和其它的Mtree。
          * 在DataDomain图形管理界面(Web GUI),复制VTL虚拟磁带池的复制被称为Pool Replication。如果虚拟磁带池使用兼容模式(Backwards Compatibility Mode),那么磁带路径为/data/col1/backup/vtc/<pool_name>/<tape_barcode>,复制实际为Directory Replication;如果虚拟磁带池使用Mtree模式,那么磁带路径为/data/col1/<pool_name>/.vtc/<tape_barcode>,复制实际为Mtree Replication。所有的Pool Replication在DD命令行(CLI)中显示为实际的复制类型(Directory Replication或Mtree Replication)。

 

 

 

     5. 备份软件控制的复制(Managed File Replication)有多种名称,比如在NetBackup中称为SLP(Storage Lifecycle Policy),在NetWorker中称为CCR(Clone Controlled Replication)。它们复制的对象是DDBoost Mtree下面的某个文件。在配置好以后,由备份软件发起,由DataDomain完成并通知备份软件结果。

 

 

 

     6. DataDomain复制支持多种结构,包括一对一(A->B),双向(A->B, B->A),一对多(A->B, A->C),多对一(A->C, B->C)和串联(A->B->C)等。不同的复制类型支持的结构略有不同。

 

 

 

     7. DataDomain控制的Directory Replication和Mtree Replication支持两端设备的DDOS版本差异为不超过两个版本(比如5.0.x和5.2.x),但是Collection Replication要求两端设备运行相同版本DDOS。备份软件控制的Managed File Replication要求目标端设备使用相同或者更高版本DDOS。

 

 

 

     8. Directory Replication
          1)通过复制日志顺序记录复制源目录的操作,包括创建,写入,修改,删除。
          2)系统每隔15分钟检测一次复制源目录是否有变动。
          3)在初始化(initialize)和重新同步(resync)的三个阶段的阶段一中(phase 1 of 3),源端目录不能被写入。
          4)在重新同步时,目标端设备需对目标目录现有数据创建快照并删除所有现有数据,如果现有数据为数量众多的小文件(数百万甚至更多),那么重新同步的阶段一周期将大幅延长直到删除完成(可以达到数小时)。建议在针对文件数量众多的目标端目录进行重新同步时,尽量安排在源端目录没有备份任务时进行。
          5)同一设备可配置多个Directory Replication。

 

 

 

     9. Mtree Replication
          1)通过快照(Snapshot)记录源端Mtree在特定时间的内容,并将快照发送到目标端端设备的目标Mtree。
          2)在复制全部完成的情况下,系统每隔15分钟为源端Mtree创建一个快照。
          3)如果发送上一个快照耗费超过15分钟,那么发送完成后系统立即创建下一个快照。如果没有,那在距离上一快照创建15分钟时,系统创建下一快照。
          4)如果有用户自定义生成的快照,那么系统将在发送完成上一个快照之后立即发送用户自定义快照,并且在发送用户自定义快照时,系统停止自动生成快照。
          5)在初始化(initialize)和重新同步(resync)的三个阶段的阶段一中(phase 1 of 3),源端目录可以被写入。
          6)同一设备可配置多个Mtree Replication。
          7)剩余同步数量(Pre-Comp Remaining)在初始化(initialize)和重新同步(resync)不准确,在完成立即更新正确的数值(即初始化或重新同步1TB数据时,看到的剩余同步数量可能为10TB)。

 

 

 

     10. Collection Replication
          1)通过块级别变动记录需要复制的内容。
          2)每当文件系统的某块有数据修改,那么源端设备立即发送该变动到目标端设备。
          3)不能被重新同步(resync)。
          4)同一设备只可配置一个Collection Replication。

 

 

 

    11. Manage File Replication
          1)由备份软件定义和发起。
          2)由DataDomain执行和返回结果。
          * 目前DDOS版本中,如备份软件中途停止Manage File Replication,备份软件会立即记录复制失败,但在DataDomain上,复制会继续运行直至当前文件全部传输完成并不能通过命令行或者图形管理界面终止,如果实在立即停止DataDomain复制该文件,可以考虑重启DataDomain文件系统或者关闭DDBoost功能(因影响整个文件系统和DDBoost功能,不建议使用)。如复制完成,目标端设备的备份文件不能被软件软件直接调用。

 

 

 

     12. DataDomain Replication Throttle
          1)DataDomain复制使用的网络带宽可由DataDomain Replication Throttle限制。
          2)DDOS 5.5以前,所有源端设备上的复制对(Replication pair/context)使用同一Throttle。
          3)从DDOS 5.5开始,不同目标的复制对可配置不同的Throttle。
          4)Throttle需要在源端设备配置,但如果目标端设备的Throttle设置为0(disabled),那么到该目标端设备的复制对将停止复制。
          5)Throttle对DataDomain Native Replication(Directory/Mtree/Collection)和Managed File Replication同样生效。
          6)Throttle是针对DataDomain设备的物理网络接口生效,如果复制使用的网络接口为虚拟网络接口(virtual network interface),那么Throttle应相应调低(比如复制只允许使用200Mbps带宽,而复制端口为4个物理网络接口聚合的LACP虚拟网络接口veth0,那么Throttle应该设置为50Mbps,而不是200Mbps)。

 

 

 

     13. 最佳实践
          1)备份到DataDomain和DataDomain之间的复制最好使用不同的网络接口。
          2)针对Directory和Mtree复制,将数据分散到尽量多的复制对进行复制,以提高效率。
          3)在网络带宽小于6Mbps时,可以启用Replication Low-Bandwidth-Optimization以减小网络数据量,改动将在下一次文件系统清洁完成后生效,但改动后的第一次文件系统清洁的周期将大幅度增加,比如几小时增加到十几小时。

 

 

 

     14. 复制类型和结构图例
1.jpg


2.jpg

 

3.jpg

 

4.jpg

5.jpg

 

 

Sam Li

DataDomain技术支持工程

Data Protection and Availability Solution

EMC客户服务

          VSSNetWorker备份中至关重要,对于Windows的文件系统备份,ExchangeSharepoint,SQL,Hyper-V等数据库备份都起到决定性的作用。可以说,VSS不正常,NetWorker就会处于无法备份几乎所有Windows相关数据的情况。

 

 

          那么VSS究竟是什么神秘的元素呢?它又是如何和NetWorker一起互动的呢?要理解这些,应该先来看看VSS的概念和组成。 VSSVolume Shadow Copy Service的缩写。这个服务是用来提供操作系统备份结构的重要服务,同时也是创建快照的服务。简单的说它由下面四大部分组成:

    • VSSservice         --Windows的服务之一,确保各个部件之间可以正常的通讯和工作
    • VSS requestor    ---申请系统创建快照。这个一般是由备份软件担当角色,比如我们的NetWorker就是扮演这个角色
    • VSS writer          ---用来确保我们有完整连续的数据可以备份
    • VSS provider      ---创建并且管理快照的组件

 

 

          这四个组件在备份的时候相互影响,相互通讯,通过协同合作,最终完成备份。那么他们之间的沟通和工作流程又是如何的呢?下面的图解比较详细地描述了VSS各个组件之间的关系:

1.png

   

 

          下面这个图则描述了NetWorker发生备份时,创建快照的过程:

 

2.png

      

          NetWorker根据备份的配置情况发起备份,同时对于需要处理的客户端申请快照。然后后续的工作就完全取决于客户端的VSS的各个组件的工作情况。也就是说这个过程就完全不再和备份软件相关。很多客户会说,我们的备份一直报错,而且错误都是由你们NetWorker报出来的,怎么会跟NetWorker软件没有关系呢?看到这个完整的快照之后您就会明白,NetWorker只是扮演了快照的角色中请求快照的角色。具体的实现和完成都不由NetWorker决定。具体的问题可能需要协同系统管理员,备份管理员以及微软来协同检查,发现问题所在。

 

          具体针对VSS的详细介绍,建议感兴趣的读者可以到微软的相关论坛阅读,里面还提供了针对VSS问题的一些解决建议和解决方案,对于我们备份管理员很有指导作用。

 

 

 

 

 

Mandy Xu

NetWorker技术支持工程

Data Protection and Availability Solution

EMC客户服务

         作为Avamar管理员,我们有时候会遇到这样的问题为什么Avamar有对文件系统的备份有时快有时慢,或者为什么同样大小的文件系统在某些主机上花费了更长的备份时间。我们知道,制约备份性能的因素有很多,例如,磁盘性能,CPU使用率、网络带宽以及文件系统的数据变化量。在工作中,我们也接到过很多关于备份性能的case,可以说大部分都是由于客户环境问题造成的。这篇文章主要介绍如何使用PerfMon,从磁盘性能和CPU使用率方面来诊断制约Avamar备份性能的原因。

         Windows PerfMon的全称是Windows Performance Monitor,是一个强大的性能诊断工具,其中可监控的条目包括CPU,内存,磁盘,应用程序等等。这里我们只关注与存储相关的Physical Disk和与CPU相关的Processor中的性能条目,深入介绍每个条目的含义。因为磁盘系统负责存储和处理主机上的数据和程序,而CPU的使用率决定了有多少可用资源可分配给avtar,磁盘和CPU的性能瓶颈会对备份速度产生极大的影响。

   使用PerfMon:

      打开PerfMon的方法很简单,在Windows桌面直接点击开始 运行 输入PerfMon。打开工具以后,从左侧选项栏选择Performance Monitor。点击右侧窗口上的绿色添加按钮,添加性能条目。在Available Counters处选择Physical Disk然后展开,Instance of Selected Object选择所需要查看的磁盘,点击Add。在截图中,我们添加了所有的物理磁盘性能指标。

1.png

       选择需要的性能指标和监控的磁盘以后,点击OKPerfMon开始对磁盘性能数据进行监控与采样。PerfMon为用户提供了三种不同的呈现方式:趋势图、柱状图和报表。实际上,图像的呈现方式对Avamar管理员来说并不重要,我们最需要关注的是图像下方Average栏提供的数据,如图:

 

2.png

          Physical Disk

从图中我们可以看出, Physical Disk中的性能条目包含:

5.png

    虽然Physical Disk所涉及的条目/指标众多,但是实际上,很多指标都是用不同的计算方法表示相同的概念。下面我们把这些性能条目按照存储系统中常用的性能指标Disk Response TimeDisk Queue Length进行分类,这样更加容易理解和区分。

       关于磁盘响应时间(Disk Response Time)条目:

  1. Avg. Disk sec/Transfer:显示了存储端处理的每个IO的平均时间。

  2. Avg. Disk sec/Read:显示了存储端处理的每个读IO的平均时间。

       3. Avg. Disk sec/Write:显示了存储端处理的每个写IO的平均时间。

    上述条目显示的单位都是毫秒ms。这些条目是需要在性能分析中最先查看的内容,Disk Response Time直接决定了存储系统对应用的服务水平,包括Avamar。通常用户感觉到性能问题,也是因为磁盘系统的Disk Response Time上升。下面以文件系统和数据库应用为例,给出一些Disk Response Time的阀值,如果磁盘响应在对应的范围内,则视为可以接受,否则需要进一步查看原因。当然根据生产环境的不同和应用的状况也需要区别对待。

     文件系统:

  • 0-10,比较理想
  • 0-20ms,可接受范围。
  • >20ms,会有性能问题,需要解决方案。

    数据库 (Exchange and SQL)

  • 0-10ms,可接受范围。
  • >10ms,需要优化。

       从下图我们可以看出,在空闲状态下Avg. Disk sec/Transfer的数值仅为0.004ms

3.png

关于队列长度(Disk Queue Length)的条目:

    1. Avg. Disk Queue Length:显示了当前磁盘队列长度,也就是有多少个IO在等待存储来处理。

    2. Avg. Disk Read Queue Length:显示了存储操作正在等待被存储做读处理的请求数目。

    3. Avg. Disk Write Queue Length:显示了存储操作正在等待被存储做写处理的请求数目。

           这几个值显示了磁盘队列长度的相关信息。所谓Disk Queue也就是服务器端 (主机) 发出的存储操作正在等待被存储处理的请求数目。这个条目也与Avamar的备份性能高度相关。举个例子,Avamar发出一条读请求,但是目标磁盘当时正在处理其他任务。那么这个新的读请求就会被放在磁盘队列里。这时候磁盘队列的值就是1。理论上讲,Avg. Disk Queue Length的值不应该大于1,如果看到采样期间,平均的Queue Length大于1,则说明在采样的某段时间存储无法完全响应应用端(Avamar)所发出的IO请求,也就是说在这段时间里,Avamar无法进行备份或者备份很慢。

  其他需要关注的性能条目:

       % idle time这个条目准确记录了磁盘在多少时间下保持在空闲状态。如果此数值低于20%,说明磁盘系统处于极度繁忙(饱和)状态。如果磁盘系统长期处于饱和状态,您可以考虑采用更快的磁盘系统取代现有的。

Processor

       我们用同样的方法,把Processor的性能条目添加到监控中,如图:

4.png

      在这诸多条目中,可能会影响Avamar备份性能的是% Processor TimeProcessor Queue Length

   1. % Processor Time:显示了处理器执行一个非空闲线程所花时间的百分比。如果这个数值大于85,则说明当前处理器过度使用。这种情况就可能导致avtarAvamar用来执行备份和恢复的进程)不能被分配到足够的CPU资源来进行备份工作。

       2. Processor Queue Length:显示了当前处理器队列中的线程数。如果在一段时间内,次数值两倍于CPU的数量,则说明CPU没有足够的处理能力。这时,主机可能就需要一个更快的处理器了。

 

Roy Tian

Avamar技术支持工程

Data Protection and Availability Solution

EMC客户服务

 

 

1. 相比传统备份,DataDomain ddboost备份的优势在于
1) 更快的备份速度(特别在备份带宽资源有限,备份服务器任务繁重,SAN资源有限(包括链路带宽,链路连接数,磁带机设备数,磁带机写入性能、磁带机操作速度)等情景下),
2) 更低的备份网络带宽需求(ddboost备份的源端重复数据删除功能(后称源端重删, DSP, Distributed-Segmentation-Processing)将减少90%以上的备份网络带宽使用;ddboost虚拟合成备份功能(VS backup, Virtual-Synthetic backup)只需在备份网络中传输小数据量的增量备份,随后DD将把该增量备份与上一次全备份合成为一个新的全备份),
3) 更快的异地同步 (DataDomain数据同步只在传输新字段时占用带宽,针对远端设备已存在的字段,同步将在远端设备中添加相应的索引),
4) 更高的备份成功率(ddboost备份通过ifgroup提供高级负载均衡以及故障转移(failover),即正在使用的备份网络(ifgroup成员之一)中断后,ddboost备份将自动切换到其它正常工作的备份网络(其它ifgroup成员)并继续运行。同时ddboost备份避免了在磁带备份方案中由磁带机机械故障、磁带介质故障引发的备份失败),
5) 更简单的日常管理(相对磁带备份方案,ddboost备份免去了众多的日常的磁带卷管理,包括调用,出库,运输,清点等),
6) 更少的备份服务器资源占用(比如,在NetWorker的client direct ddboost备份以及avamar ddboost备份中,备份数据不通过NetWorker存储节点或者Avamar节点,而直接由客户机发送到DD设备),
7) 更方便的远端设备冗余备份管理(基于备份软件管理的DD同步(MFR, Managed-File-Replication),将会使DD同步到远端设备的冗余备份直接被备份软件管理和调用;与之相对的是DD的传统同步(mtree/directory/pool/collection),备份软件不能直接从远端设备通过冗余备份恢复数据;目前,部分备份软件(例如, DDBEA, Data Domain Boost for Enterprise Application )支持直接从DD传统同步的冗余备份恢复数据)。

 

2. 总的来说,即使备份软件、ddboost插件以及DDOS的版本相同,ddboost备份在不同的环境里也可能有不同的性能。比如,ddboost备份在基于intel架构的平台上的性能最好(例如Windows和Linux),而在AIX和Solaris平台上的性能次之。

 

3. 备份性能一般由源端客户机数据读取性能,源端客户机(到备份服务器再)到存储系统的网络传输性能,备份软件处理性能,以及存储系统写入性能决定。
1) 源端客户机的数据读取性能可通过操作系统或者文件系统工具进行检查和判断,
2) 网络性能一般通过iperf工具进行测试和判断,
3) 备份软件处理性能一般由备份软件支持团队测试和判断,
4) DD存储系统写入性能可通过DD诊断工具ddpconnchk、devperf和ddboost_stress进行测试和判断,测试通常在直接写入到ddboost的主机上进行,比如NetWorker的存储节点/客户机,Avamar的客户机或者NetBackup的媒体服务器(media server)。

 

4. 通常情况下,ddboost备份的源端重删(DSP)为默认启用。该功能将”原本在DD上进行的重复数据删除工作(比如VTL备份方式)”放到备份客户机上完成,即客户机只通过网络发送重删后的数据字段给DD(备份网络带宽需求随之减小)。需要注意的是,从DDOS 5.4.x版本以后,针对Solaris的非intel平台,DDOS默认禁用DSP功能,这是因为老式Solaris Sparc架构硬件对DSP功能支持有限,启用DSP反而会降低ddboost备份性能。如果Solaris Sparc架构T4/T5硬件系统配合Solaris 11.1操作系统使用,那么DDOS注册表需要手动修改为启用DSP以提高ddboost备份性能。详情请见以下EMC知识库链接。
180703 : Solaris SPARC Backup Server Performance with DD Boost            
https://support.emc.com/kb/180703
203451 : Solaris 11.1 with T4/T5 hardware needs DSP to be enabled for better ddboost backup performance.            
https://support.emc.com/kb/203451

 

5. Ddboost插件程序一般在备份软件安装包中集成,安装备份软件时将一并安装ddboost插件程序。例外的是Symantec的NetBackup和Backup Exec软件,用户需要停止备份软件服务,并下载安装DataDomain提供的独立ddboost插件程序安装包,最后再启动备份软件服务。

 

6. Ddboost备份的ifgroup功能需要所有ifgroup的DD IP地址在同一子网,并且备份客户机能够连接DD的管理IP以及所有ifgroup IP的TCP 111和2049端口。如果不能连接管理IP,那么ddboost备份将失败;如果不能连接ifgroup IP,那么ddboost备份的ifgroup功能将失效,备份则会改在管理IP上运行。

 

7. 如果ddboost备份性能的瓶颈被诊断为DD存储系统写入性能,那么需要由DataDomain文件系统技术团队做进一步诊断,常见的问题包括但不限于”目录inode数目过多”,”目录碎片过多”和”目录OPAQUE KEY过多”等等。

我觉得技术支持Support工程师的工作是和医生是相近的,医生通过“望”、“闻”、“问”、“切”来诊断病情,提出最可靠适合于患者的诊疗方案,同理,Support也通过这四项中医基本方法来帮助客户解决Server的各项毛病。所以,作为一名稳重的技术支持工程师,往往都会先进行一些列的工作,“机器现在报什么错误”、“是否存在直观可见的性能问题,比如备份慢、内存CPU消耗大,或者硬件故障,比如闪灯等”、“详细询问问题故障发生前,机器是否有任何变动,包括服务器升级、机房网络故障、宕机等”、“详细检查相关系统日志,排查问题根源”,最终定位问题根源,提出可执行性解决方案。但是,在日常生活中,由于个人时间成本、医疗资源成本等原因,大家都渐渐培养出一项必备的生存技能,自己看病。这项技能一方面在某些情况下,比如青壮年发烧感冒拉肚子情况下,可以及时地便捷地达到好转及治愈的效果,另以方便,又可以帮助自身注重维护身体的健康,所谓“三分治,七分养”,关键在于平时。同理,对于我们的Avamar服务器,我们也可以通过平时的观察、初级故障排除,来维护Avamar服务器的健康状况。下面,我将介绍一些简单的检查方法,可以用来实时观察Avamar情况如何。

文中所举例子包括:

  1. Avamar  Gen4s-M1200,版本7.0.2,含有三个storage node, 后挂DD860;
  2. Avamar Gen4-3.9TB,版本6.0.2,含有三个storage node。


一、使用AVAMAR GUI监控系统

首先,我们可以通过GUI,也就是Avamar Administrator界面直观地得到Avamar当前状态信息,如下图1图2所示,图1是Avamar  Gen4s-M1200,版本7.0.2,图2是Avamar Gen4-3.9TB,版本6.0.2。

 

图1.png

图2.png

 

分别点击图1中标红部分,可以得到Avamar现在的问题,点击开就可以看到所有的问题。左侧红圈出点击开是关于backup相关报错,如下图3所示;右侧红圈出点击开是Avamar其他activity,比如CP、HFScheck、GC、硬件等相关报错如下图4所示:

图3.png

图4.png

 

有关backup错误,我们会在之后的文章中提到,本文主要介绍maintenance job(包括CP、HFScheck、GC)以及硬件相关错误识别、简单处理解决。

对于经常出现的错误,我们也来介绍一下,当遇见类似报错时,不用慌张,来看看下面的解决方法:

1)A checkpoint of server data is overdue.

这个是说CP超过24小时没有更新。这个在一般情况下,可以先观察一下,看之后几个小时内是否有CP完成,如果有,此报错可以忽略。因为,每天Avamar的工作流程是:

备份->GC(用来清除多余的数据)->  CP -> HFScheck -> CP -> 备份

由此可以看出,每一项工作顺序进行,同时,我们对于每一部分的工作时间也都有预设置,就是各种工作window,但是总会有某些时候各项工作不一定按时完成。比如去医院看病,我们拿拍片举例吧,相对来说,拍片的时间可控性可预见性更大,比如每个患者需要花费20分钟拍片,放射科一天工作8个小时(出去吃饭时间),总共可接待24人。也就是说,正常情况下,医生可以在中午12点左右进行个半天总结,但如果有个患者的情况特殊,花费更多的时间,那医生上半天总结就要延迟。同理地,如果Avamar其他工作由于某些特殊情况延长推迟,比如某天有太多数据要备份(备份时间增长),或者某天有太多数据要扫描删除(GC时间增长),都会导致在24小时内没有CP,也就是此处提到的错误。往往,CP在接下来的2-3个小时内都会完成,那么,这个报错是可容忍忽略的。所以,只要通过在接下来的几个小时内看CP是否完成,再做决定。

2)Data Integrity Alerts

这个报错是关于HFScheck。我们主要碰到的错误信息有:MSG_ERR_HFSCHECKERRORSMSG_ERR_DDR_ERRORMSG_ERR_CGSAN_FAILEDMSG_ERR_TIMEOUT

MSG_ERR_HFSCHECKERRORS主要是由于存储节点上stripes有问题导致的。具体错误可以参见我们的KB 127269 https://emc--c.na5.visual.force.com/apex/KB_Break Fix_Printable?id=kA17 00000000WpJCAU),根据GSAN的错误日志(/data01/cur/err.log)、HFScheck error日志(/data01/hfscheck/err.log)、对应CPlog/data01/ checklogs/cp.xxxxxxxxxxxxxx/err.log)里的具体报错再具体实行解决方案。

MSG_ERR_DDR_ERROR主要是由于和DD的链接、合作问题引起的,具体错误可以参见我们的KB 120996https://emc--c.na5.visual.force.com/apex/KB_BreakFix_1?id=kA1700000000VC8#,通过上面提到的HFScheck错误分析,以及DDR log/usr/local/avamar/var/ ddrmaintlogs/ddrmaint.log)中的错误分析,在具体实行解决方案。

MSG_ERR_CGSAN_FAILED主要是由于CGSAN进程中出现问题。具体错误可以参见我们的KB 165409https://emc--c.na5.visual.force.com/apex/KB_BreakFix_Printable?id= kA1700000000gmpCAA),其中,会牵扯到硬件、ASCD进程、各node间时间是否同步、是否配置正确的license、是否有RMCP进程在Gen3.3上等,这些问题都会导致HFScheck出错并报错MSG_ERR_CGSAN_FAILED

MSG_ERR_TIMEOUT,同MSG_ERR_CGSAN_FAILED类似,是由于硬件、是否有RMCP进程在Gen3.3上、单节点thread exhaustion具体错误可以参见我们的KB 172518https://emc--c.na5.visual.force.com/apex/KB_BreakFix_Printable?id=kA1700000000no5CAA)。

 

对于以上Data Integrity Alerts,不论是通过技术服务工程师或是server自动解决,都可以通过以下操作来清除这些alerts:

  1. 1.  通过命令行清除:

mccli event clear-data-integrity-alerts --reset-code=AVAMARDATAOK

  1. 2.  通过GUI界面清除
    1. a.  登录GUI,点击Administration
    2. b.  点击Event Management
    3. c.  点击Unacknowledged Events
    4. d.  点击Actions > Event Management > Clear Data Integrity Alert
    5. e.  输入code: AVAMARDATAOK

 

好了,我们已经介绍了GUI如何监控Avamar Serevr,尤其是maitenance jobs。通过本篇文章,大家应该对何如通过GUI监控Avamar maintenance job有一定的了解,并且熟悉一些报错信息。那么,接下来就需要大家在工作中慢慢发现体会Avamar GUI监控的便捷性和及时性,并一步步熟悉GUI



作者简介:

mandy xu.jpg

Mandy Xu 8年IT从业经验,2006至2009年在世界500强外企从事系统工程师一职。2009年加入EMC全球支持中心,服务于NetWorker技术支持团队。熟悉存储备份软件操作,熟悉存储备份相关原理。

对于很多入门级用户来说,在备份时,NetWorker软件如何选择设备或者说卷是一个很难理解的规则,这对于他们去配置备份的规则和策略会有很多影响。同时也可能最终会影响到客户的数据备份以及恢复。那么我们这边可以简单介绍一下NetWorker选择卷的规则。简单的说,NetWorker会从目标池中搜索可用的卷来做备份。这个道理很容易明白,当你将一个设备配置到NetWorker备份软件中,无论它是物理磁盘,磁带,还是当今最常使用的data domain,我们都需要配置如果让数据备份到这个设备中,以及如果合理的分配数据到不同的设备中去。所以当客户在NetWorker端配置设备的时候,就需要确认把设备放入哪个目标池使用。而当配置完成后,一旦备份开始进行,而目标池中有多个卷都可用,NetWorker则会依据下面的顺序来挑选卷书写数据:

 

  • NetWorker 首先会选择目标池中已经挂载好并且状态为‘可追加的’卷。但是可能出现在目标池中会有多个满足这个需求的卷,在这种情况下,NetWorker会根据下面规则使用磁带:

 

  1. 卷的可用性,也就是说会会选择当前会话最少的磁带。怎么去定义会话数呢?这个跟早前定义的存储集挂钩,一个独立的存储集就是一个独立的会话,多个会话可以同时写入到同一个卷。

 

  2. 卷被标签的时间。前面已经介绍过,一个设备需要配置到NetWorker上的时候,需要根据NetWorker的命名规则打标签。NetWorker在相同的情况下,会优先使用最早打标签的磁带。

N-1.png

 

  • 如果目标池当前没有状态为‘可追加’的卷,那么NetWorker会声称一个警告信息,提示目标池没有可以使用的卷,同时NetWorker会按照下面顺序来搜索可以使用的磁带:

 

  1. 目标池中有没有挂载的但是状态为‘可追加’的卷。同时‘自动设备管理’功能启用。NetWorker 会选择这种状态的卷来写入数据。如果有多个相同状态的卷满足需求,那么NetWorker会选择标签时间最长的卷来写入数据。
  2. NetWorker会选择已经是挂载状态为‘可回收’的卷。
  3. 在‘自动设备管理’打开的情况下,NetWorker会选择未挂载的并且状态为‘可回收’的卷。
  4. 在‘自动设备管理’打开的情况下,如果有其他的池子属性‘Recycle to other pools是勾上,同时目标池的属性上‘ Recycle from other pools’也是勾上的。那么就会选择其他池子里面的未挂载并且状态显示为‘可回收’的卷。

N-2.png

5. 在‘自动设备管理’启用的状态下,去找任何未挂载未标签的空白磁带。

 

总而言之,无论目标池中是否有可用的卷,NetWorker服务器仍然会根据规则去选择可用卷于备份。管理的时候应该尽量注意卷的分配。

作为一个Avamar的管理员或者使用者,我们都知道Avamar是有专门的管理控制台来控制和管理备份恢复操作的。而且随着版本的升级,Avamar控制台的界面也越来越人性化,管理操作起来也更容易了。对于Windows客户端来说,如果配置了DTLT,我们也是可以客户端管理备份恢复的。

 

但是呢,在实际工作中,我们还是会遇到一些需求,希望能在客户端通过命令行进行一些简单的备份恢复操作。作为一个习惯了使用图形界面工具的工程师,说实话,我个人是很不乐意通过命令行来执行一些任务的。不过既然有这种需求,作为一个勤劳的技术支持工程师,我还是帮大家搜集了一些常用命令并进行了一番测试来供大家参考。

 

使用过我们Avamar产品或者对它有一点了解的人,应该都听说过avtar这个进程。可以说avtar是我们Avamar的核心,我们数据传输都是通过它来进行的。所以我们这次的主题也肯定离不开avtar了。那么首先了解一下在Windows客户端我们使用avtar能做些什么基本操作呢?

  • 备份 --create or -c
  • 恢复 --extract or --get or -x
  • 删除备份 --delete
  • 列举备份 --backups
  • 列举备份内容 --list or -t
  • 验证一个备份 --validate
  • 显示备份日志--showlog

 

注意:

其中--backups, --list, --delete --showlog 可以运行在装有Avamar客户端插件的每个客户端或者Avamar服务器上面.

--create 此命令必须运行在您需要备份的客户端上面.

--extract 此命令必须运行在您需要恢复到的那台客户端上面.

 

另外,一些常用的参数:

用户名Username--id=

密码Password--ap= 或者 --password=

如果是在Avamar grid上面运行的话则不需要定义此参数。

Avamar服务器Server--server= 或者 --hfsaddr=

如果客户端注册在您需要联系的grid上面,此参数不需要定义。

客户端路径Client Path--account= 或者 --path=

生成日志路径--logfile=

备份的编号--labelnumber= or --sequencenumber=

  • 仅当使用—validate参数是需要定义
  • 如果没有定义的话,那么最近的备份会被使用

备份标签 --label=

这个是每个成功备份对应的标签,可以在Avamar控制台上面找到。

备份过期参数--expires=

用来定义备份什么时候过期

 

常见报错:

avtar Error <5126>: Login error 66: User not found in Avamar database

用户名不正确

 

avtar Error <5126>: Login error 69: Authentication failure  (Invalid password?  User disabled?)

密码不正确

 

avtar Error <5126>: Login error 74: Account not found in the Avamar database

  • 客户端路径不正确
  • 请使用您在Avamar GUI上面看到的全路径
  • 例如,客户端名字需要区分大小写

 

而且上面的报错都会导致最终报错如下:

avtar FATAL <5308>: Failed to initiate session with server

avtar Info <6149>: Error summary: 2 errors: 5308, 5126

avtar Info <5314>: Command failed (2 errors, exit code 10008: cannot establish connection with server (possible network or DNS failure))

 

下面是一些常用命令参考:

--create参考例子:

avtar --id=MCUser --ap=MCUser1 --path=/clients/server1 --create

这个命令将会备份server1所有文件系统到他注册到的Avamar grid.

 

avtar --id=MCUser --ap=MCUser1 --path=/clients/server1 --create C:\test

这个命令将会备份server1上面的C:\test文件夹到他注册到的Avamar grid 下面是基于此命令做的测试的日志:

日志参考附件:backup with create command.txt


备份完成后,Avamar控制台上显示如下(label 137),因为没有指定备份过期日期,他的retention显示为“N

1.png


如果指定了--expire参数,结果如下:

日志请参考附件:Backup with create & expire command.txt

2.png

 

--backup参考例子:

avtar --id=MCUser --ap=MCUser1 --path=/clients/server1 --backups

 

此命令将会返回类似下面的结果:

avtar Info <7377>: Backups for /clients/server1 as of 2013-11-06 15:47:12 Mountain Standard Time

Date      Time    Seq Label           Size     Plugin Working directory         Targets

---------- -------- ----- ----------------- ---------- -------- --------------------- -------------------

2013-11-06 15:19:07     2                           3K Windows  c:\avamartemp         c:\test

2013-11-06 15:17:09     1                           6K Windows  c:\avamartemp         c:\test

 

The “Seq” column lists the “sequencenumber” or “labelnumber”

具体日志信息参考下面测试结果:

日志请参考附件:avtar with backups flag.txt

 

--showlog参考例子:

avtar --id=MCUser --ap=MCUser1 --path=/clients/server1 --labelnumber=1 –showlog

日志请参考附件:avtar showlog flag.txt

 

  • 此命令将会把label1的备份日志输出到CMD窗口。
  • 日志最后不会有wrapup信息。
  • 为了更好查看日志信息,我们可以将结果输出到一个文件:

avtar --id=MCUser --ap=MCUser1 --path=/clients/server1 --labelnumber=1 --showlog > avtarlog.log

 

--list参考例子

avtar --id=MCUser --ap=MCUser1 --path=/clients/server1 --labelnumber=1 –list

此命令将会输出类似下面的结果:

c:\

c:\test\

c:\test\avtarfilelist.txt

c:\test\extensions.txt

c:\test\diff\

c:\test\diff\1.txt

c:\test\diff\3.txt

 

如果您只需要查看某个目录下面的文件,可以在命令最后定义目录,例如:avtar --id=MCUser --ap=MCUser1 --path=/clients/server1 --labelnumber=1 –list C:\test\diff

 

日志请参考附件:avtar list.txt


当然,我们还可以把结果导出到某个文件便于查看:avtar --id=MCUser --ap=MCUser1 --path=/clients/server1 --labelnumber=1 –list > filelist.txt

 

avtar list to file.PNG.png

 

 

--extract参考例子:

avtar --id=MCUser --ap=MCUser1 --path=/clients/server1 --labelnumber=1 –extract

此命令会将labelnumber1的备份的所有内容恢复到原来路径。

 

Microsoft Windows [Version 6.1.7601]

Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

 

 

C:\Windows\system32>cd C:\Program Files\avs\bin

 

 

C:\Program Files\avs\bin>avtar --id=MCUser --ap=MCUser1 --path=/REPLICATE/gen4s-

util.sh.lab.emc.com/Darlene93/cnrdlid20l1c.corp.emc.com --labelnumber=137 --extr

act

avtar Info <5551>: Command Line: avtar --exclude=C:\Training --id=MCUser --passw

ord=**************** --account=/REPLICATE/gen4s-util.sh.lab.emc.com/Darlene93/cn

rdlid20l1c.corp.emc.com --sequencenumber=137 --extract

avtar Info <7977>: Starting at 2015-03-24 12:50:49 China Standard Time [avtar Ju

n 12 2014 08:56:14 7.1.100-302 Windows 7 Enterprise Edition Service Pack 1 64-bi

t-AMD64]

avtar Info <10793>: Single Instance Store Groveler Service NOT installed - WSS S

IS Manager will not be started.

avtar Info <6555>: Initializing connection (Avamar Deduplication Engine v2.0.0)

avtar Info <5552>: Connecting to Avamar Server (10.32.167.93)

avtar Info <5554>: Connecting to one node in each datacenter

avtar Info <5583>: Login User: "MCUser", Domain: "default", Account: "/REPLICATE

/gen4s-util.sh.lab.emc.com/Darlene93/cnrdlid20l1c.corp.emc.com"

avtar Info <5580>: Logging in on connection 0 (server 0)

avtar Info <5582>: Avamar Server login successful

avtar Info <10632>: Using Client-ID='91f70987c265c2c25177b5ea5ed29653b0a5e92a'

avtar Info <5550>: Successfully logged into Avamar Server [7.2.0-316]

avtar Info <5373>: 1 user exclude pattern entered.

avtar Info <5295>: Starting restore at 2015-03-24 12:50:49 China Standard Time a

s "CORP\lid20" on "cnrdlid20l1c" (4 CPUs) [7.1.100-302]

avtar Info <19114>: --restoreshortnames flag not specified; 8.3 names (if availa

ble in the backup) will not be restored with files/dirs. If the target OS suppor

ts 8.3 names, then the OS will create 8.3 names automatically.

avtar Info <16346>: Backup #137 created by avtar version 7.1.100-302

avtar Info <5949>: Backup file system character encoding is 65001 (UTF-8).

avtar Info <8745>: Backup from Windows 7 Enterprise Edition Service Pack 1 64-bi

t host "/REPLICATE/gen4s-util.sh.lab.emc.com/Darlene93/cnrdlid20l1c.corp.emc.com

" (cnrdlid20l1c) with plugin 3001 - Windows Filesystem

avtar Info <19850>: Backup #137 timestamp 2015-03-24 12:33:33 China Standard Tim

e, 152 files, 531.1 KB

avtar Warning <19107>: Unable to determine if there is enough disk space for the

specified restore.

avtar Info <5259>: Restoring backup to directory ""

avtar Warning <6777>: Cannot translate path '' to full path, proceeding with ori

ginal path

avtar Info <7324>: Volume Type for "\" is "NTFS", Supports Compression=1, Encryp

tion=1, ACLS=1, DataStreams=1, Reparse=1, Sparse=1, Hardlinks=1

avtar Info <6694>: Not creating drive/volume/server designator 'C:'

avtar Info <5262>: Restore completed

avtar Info <7925>: Restored 0 bytes from selection(s) with 531.1 KB in 152 files

, 8 folders (531.1 KB in 152 files skipped)

avtar Info <7883>: Finished at 2015-03-24 12:50:49 China Standard Time, Elapsed

time: 0000h:00m:01s

avtar Info <6645>: Not sending wrapup anywhere.

avtar Info <5314>: Command completed (2 warnings, exit code 0: success)

 

 

C:\Program Files\avs\bin>

 

 

avtar --id=MCUser --ap=MCUser1 --path=/clients/server1 --labelnumber=1 --extract C:\test\diff

此命令会将labelnumber1的备份中的C:\test\diff目录的所有内容恢复到原来路径。

 

avtar --id=MCUser --ap=MCUser1 --path=/clients/server1 --labelnumber=1 --extract --target=c:\restore

  • 会将备份恢复到c:\restore
  • c:\restore下面会创建原来的路径,例如:c:\restore\C\test\...

 

注意:如果需要恢复到另外一个客户端,需要在恢复到的客户端上面运行恢复命令。此命令仅限于恢复到同一客户端的不同路径。

 

--overwrite选项:

Always:将会覆盖所以已存在的文件。

Modified:如果备份中的文件的date/time 值和客户端上面的一直,将不再恢复此文件。

Never:保护客户端文件不会被覆盖。

Newest:如果备份中文件的date/time stamp比客户端上面的新,将被恢复出来。

Newname:将文件进行恢复,但是赋予它新的名字。例如myfile.txt 将会变为 myfile(1).txt


如果我们需要找出一个备份是否包含某个文件:

avtar --id=MCUser --ap=MCUser1 --path=/clients/server1 --labelnumber=1 --list | find /i “searchstring”

  • searchstring替换为您需要找的文件名字,需要加引号
  • 这个名字可以不是文件的全名,但是不能使用通配符。
  • 当然,如果结果比较多,您可以将他们输出到文件中,然后通过文件编辑工具搜索您需要的文件:

avtar --id=MCUser --ap=MCUser1 --path=/clients/server1 --labelnumber=1 --list > backuplist.txt

 

高级恢复需求:

仅仅恢复有某些特定扩展名的文件:

  1. 1. 首先将所有.bat文件列出来导出到一个文件:

avtar --id=MCUser --ap=MCUser1 --path=/clients/server1 --labelnumber=1 --list | find /i “.bat” > batlist.txt

  1. 2. 编辑文件,把不需要恢复的文件移除
  2. 3. 然后运行以下命令恢复指定的文件:

avtar --id=MCUser --ap=MCUser1 --path=/clients/server1 --labelnumber=1 --extract --exclude=* --include-from=batlist.txt

 

使用 powershell仅仅恢复比某个特定日期新的文件:

考虑下面的场景:

  • 文件服务器crash了,但上面有上百万个文件.
  • 恢复所有文件需要花费很多时间。
  • 为了恢复快一些,在第一阶段客户只想恢复比某个特定时间早的文件
  • 然后后面有时间的话在恢复那些没有被恢复的文件

命令首先将符合条件的文件筛选出来并导入到某个文件:

& 'C:\Program Files\avs\bin\avtar.exe' '--id=MCUser' '--password=MCUser1‘'--path=/clients/server1' '--labelnumber=1' '--list' '--verbose=2' |  %{ $_.Split("%")[1]; } | %{ $_.Trimstart(); } | where {$_ -ge "2013-08-01"} | %{ $_.Split(':')[3]; } | %{ $_.Trimstart("\"); } | Set-Content newfiles.txt

然后进行恢复:

& 'C:\Program Files\avs\bin\avtar.exe' '--id=MCUser' '--password=MCUser1' '--path=/clients/server1' '--labelnumber=1' '--extract' '--exclude=*' '--include-from=newfiles.txt'

 

以上两个命令之后,会将2013-08-01 (yyyy-mm-dd)和比他们新的文件恢复到原来路径。

之后我们可以进行一个恢复,使用默认的覆盖选项“Never”,这样一来只有那些之前没被恢复的文件将会被恢复。

 

恢复系统信息:

avtar --id=MCUser --ap=MCUser1 --path=/clients/server1 --labelnumber=1 --extract --internal .system_info --target=c:\avtar_system_info

3.png

这个可以将Windows一些有用的系统信息恢复出来,比如:machine.xml, partitiontables.xml, sessionlog, and statsfile。那么什么时候我们需要恢复系统信息呢?首先可以看到恢复出来的文件有当时备份的session log,当时客户端的volume和基本配置信息等。由于默认我们备份日志在客户端只保留14天,有时候遇到恢复问题,我们需要验证当时备份状态,但没有日志可以查询,就可以将session  log恢复出来验证一下,或者我们做BMR恢复,忘了当时计算机有几块盘,每块盘的大小等,就可以参考volumes.xml等文件来配置。

 

由于通过avtar进行备份或者恢复,可以跳过和MCS通信的环节,直接和gsan进行通信

这些记录不会显示在Avamar activity控制台或者avagent.log里面。

 

希望上面这些信息能让大家更加了解我们备份恢复的一些简单过程。如果您对这些操作有任何的疑问,欢迎随时和我们讨论。谢谢!

话说早些日子,某人犯事了,就会大喊“我爸是李刚”。搞得“李刚”二字已经不是人名,变成了一块牌子,什么牌子?自然是免死金牌。是真金还是镀金,尚且不得知,只知道受到了诸多舆论的谴责。实际上,别说是“李刚”,你喊“李玉刚”,人家也不待见你啊。归根结底是那人觉得自己是含着金钥匙出生的,就可以为所欲为。

 

其实,我们avamar也是含着金钥匙诞生的产品,这可不是镀金的,那是真真的足金。以上抛砖引玉之后,各位仁兄,你们好,我们要进入主题开始Avamar的技术讨论了,今天我们要来告诉各位一个新玩意,那就是撬开Avamar的金钥匙。

 

在之前的版本中,我们经常说登录到Avamar之后,要运行”ssh-agent bash”,然后添加key”ssh-add ~/.ssh/dpnid”,然后我们就可以为所欲为不需要密码地登录到任何一台存储节点。那大家有没有回头来想过avamar到底是如何如火纯清地运用Key,体验到Key的好处呢?


在介绍Key之前,我们先来温习下什么是密钥?密钥在SSH的远程登录时候是如何工作的?


密钥(Key)顾名思义就是用来加密和解密的钥匙,如同一把锁,我们用钥匙把东西锁住,然后再用钥匙把东西解开。例如对一串字符进行加密后,就会变成一堆无法人类识别的字符码或者是乱码,这样没有key的话就无法解开这个加密,也无法获知里面的具体内容。因此市面上大量使用的有两种密钥:私用密钥和公共密钥。


对称加密算法在加密时和解密时使用的是同一个秘钥;而非对称加密算法需要两个密钥来进行加密和解密,这两个秘钥是公开密钥(public key,简称公钥)和私有密钥(private key, 简称私钥),公钥是可以对外发布和传输,而私钥是保存在拥有者的一方。


对称加密的原理图(加密和解密都是用同一个Key):

1.png

非对称加密原理图(私钥加密,公钥解密;公钥加密,私钥解密):

2.png

既然密钥有此等好处,那么就促成了常见的两种应用。


  1. 1. 加密发送数据。

比如用户A要给用户B发送加密的邮件,那么用户A使用用户B的公钥来加密,把加密后的邮件发送给用户B,用户B自然可以用自己的私钥来解密邮件,这样就可以防止邮件在网络传输过程中,被黑客截取之后直接读取里面的明文内容。这就是加密数据的一种应用。

 

  1. 2. 公钥验证。

公钥验证就是将要发送的数据进行数字签名,而接收方在收到数据后,便通过数字签名来验证数据是否属实,而且当中有没有被篡改过。因此公钥验证运用的最多就是数字签名。简而言之就是用户A用自己的私钥进行加密,把加密后的数据发送给用户B,用户B使用用户A的公钥来解密,如果能正确解密,那就说明数据确实是来自用户A,并且数据的内容没有篡改过。


接下来我们来介绍下SSH Key的原理。SSH是帮助我们用putty等工具来远程登录服务器的协议。正常情况下我们使用SSH命令来登录远端服务器,每次登录时候,我们需要手动输入账号和密码。但是对于Avamar产品来说,我们每次要在Utility Node上登录到Storage Node的时候不断输入账号和密码是非常头疼和不方便的事情。所以我们必须要借助Avamarkey来实现SSH无密码登录功能。


SSH采用基于公钥和私钥的加密技术来进行自动化认证。通常是通过ssh-keygen命令创建认证密钥。公钥必须放置在服务器中(将其加入文件~/.ssh/authorized_keys),与公钥对应的私钥放在客户机的~/.ssh目录中。因此公钥和私钥是非常重要的。

3.png


我们再来复习下下面图:

4.png


SSH无密码登录的过程如下:

  1. a. 客户端有一个私钥和自己的公钥,客户端的公钥被放在服务器端上。
  2. b. 当客户端登录服务器端的时候,服务器会生成一个随机的序号,然后用客户机的公钥加密。
  3. c. 客户机用私钥来机密,并把序号发回。
  4. d. 服务器就认证客户机成功,这样客户机就可以登录了。


所以我们的Avamar也是用这把金钥匙来实现在Utility NodeStorage Node之间的来回登录。那么我们Avamar是使用常规的SSH命令吗?答案当然不是的。Avamar自然有一套自己的登录妙招。


妙招一、ssh-agent bash

该命令是用来缓存需要解密的私钥。启用ssh之前的准备工作。


妙招二、ssh-add ~/.ssh/dpnid

DPN账号的私钥放入到缓存中,因此会自动把私钥给获取出来。


妙招三、ssh-add -l

此招是用来列出目前加载进来的所有密钥。


妙招四、ssn 0.*

我们可以在utility node上用ssn命令来登录任何一个storage node0.*storage nodeID号,如0.00.2等节点。由于Avamar目前只能最多有16个节点,因此第11个节点的ID0.A,而最大的节点的ID号是0.F


既然我们可以用ssn方式来任性地登录任何一个节点,我们可以查看Avamarnode上哪些文件是和SSH有关的?


  • /home/admin/.ssh 文件夹内容:

-r-------- 1 admin admin 744 May 31 2011 admin-id-2.dsa         ## admin账号的私钥

-r-------- 1 admin admin 951 May 31 2011 admin_key                ## admin账号的私钥

    -r--r--r-- 1 admin admin 223 May 31 2011 admin_key.pub       ## admin账号的公钥

-r-------- 1 admin admin 823 May 31 2011 authorized_keys2   ## 被允许登录这个节点的所有公钥

    -r-------- 1 admin admin 27 May 31 2011 config          ##admin的配置文件夹

    -r-------- 1 admin admin 668 May 31 2011 dpnid                  ## dpn的私钥

lrwxrwxrwx 1 admin admin 9 May 31 2011 id_rsa -> admin_key         ## adminrsa私钥的链接


  • /home/dpn/.ssh文件夹内容:

-r-------- 1 dpn admin 0 May 31 2011 authorized_keys2            ##被允许登录这个节点的所有公钥

-r-------- 1 dpn admin 27 May 31 2011 config           ## dpn账号的配置文件夹

-r-------- 1 dpn admin 668 May 31 2011 dpnid                  ## DPN账号的私钥

-r--r--r-- 1 dpn admin 600 May 31 2011 dpn_key.pub            ## DPN账号的公钥

lrwxrwxrwx 1 dpn admin 5 May 31 2011 id_rsa -> dpnid      ## DPN RSA私钥的链接


  • /root/.ssh文件夹内容:

    -r-------- 1 root root 1209 May 31 2011 authorized_keys2    ##被允许登录这个节点的所有公钥

    -r-------- 1 root root 27 May 31 2011 config                       ## 配置文件


接下来我们来看看私钥是长什么样子?其实对于我们人类来说就是看不懂的样子,因为是钥匙嘛,干嘛要看得懂里面写的是什么样子呢。


admin@gen4-util:~/>: cat /home/admin/.ssh/dpnid

-----BEGIN DSA PRIVATE KEY-----

MIIBuwIBAAKBgQCWUMSv1kpW6ekyej2CaRNn4uX0YJ1xbzp7s0xXgevU+x5GueQS

mS+Y+DCvN7ea2MOupF9n77I2qVaLuCTZo1bUDWgHFAzc8BIRuxSa0/U9cVUxGA+u

+BkpuepaWGW4Vz5eHIbtCuffZXlRNcTDNrqDrJfKSgZW2EjBNB7vCgb1UwIVANlk

FYwGnfrXgyXiehj0V8p9Mut3AoGANktxdMoUnER7lVH1heIMq6lACWOfdbltEdwa

/Q7OeuZEY434C00AUsP2q6f9bYRCdOQUeSC5hEeqb7vgOe/3HN02GRH7sPZjfWHR

/snADZsWvz0TZQuybs8dEdGh/ezGhiItCINFkVg7NvSXx85dMVsB5N9Ju0gDsZxW

/d41VXYCgYBH0zIlb3lvioedyZj2mKF6fycnCZIeeDnL8wZtZPStRht6i4PFTCX1

Y/Ogw0L0bhuthOx+VTgICB87r0TmXElNUDLSncsxuw7pmHa669idUkv43CjeDkH0

kGFEHt4QA6/xw1Xq9oNpRJTo62ZsFmv0Pwp3uE7up8s0LW1O6fr+OwIVAKCJZ8nm

UwIdhEc9aU7sBDTFijP+

-----END DSA PRIVATE KEY-----

admin@gen4-util:~/>: cat /home/admin/.ssh/admin_key

-----BEGIN RSA PRIVATE KEY-----

Proc-Type: 4,ENCRYPTED

DEK-Info: DES-EDE3-CBC,DFDBC4B8EF3708FC

f2/1GJu45AtuQBlhokUib9T3m4o54cehWHx5z/BdbUYpTqsf7420/Dsb2o69ALR0

....................................

TcPSa3ARIpbuoPzOkR4osl+gzZzTaSHXUTbMPh79d3E=

-----END RSA PRIVATE KEY-----

 

看过了私钥的样子,现在我们来看看公钥的样子:

admin@gen4-util:~/>: cat /home/admin/.ssh/authorized_keys2

  1. ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAsf14EqXZb6MtXwAbou+UWEBU0Rj3ZBwaJUzSAHgPdWj35wK9l/z7mUfw4hzAmHJ+v/AOSZ++WDg9zi9JrpiSUdbkOKcoWPjEqbYjGMYbwyyIkUaNevY3sFgkh/+46lh/DYSJqVcbeUo1rSoUCJ03T5BtXQo/KEp/O27fHyry3FU= dpn_admin_key àà admin_key.pub
  2. ssh-dss AAAAB3NzaC1kc3MAAACBAJZQxK/WSlbp6TJ6PYJpE2fi5fRgnXFvOnuzTFeB69T7Hka55BKZL5j4MK83t5rYw66kX2fvsjapVou4JNmjVtQNaAcUDNzwEhG7FJrT9T1xVTEYD674GSm56lpYZbhXPl4chu0K599leVE1xMM2uoOsl8pKBlbYSME0Hu8KBvVTAAAAFQDZZBWMBp3614Ml4noY9FfKfTLrdwAAAIA2S3F0yhScRHuVUfWF4gyrqUAJY591uW0R3Br9Ds565kRjjfgLTQBSw/arp/1thEJ05BR5ILmER6pvu+A57/cc3TYZEfuw9mN9YdH+ycANmxa/PRNlC7Juzx0R0aH97MaGIi0Ig0WRWDs29JfHzl0xWwHk30m7SAOxnFb93jVVdgAAAIBH0zIlb3lvioedyZj2mKF6fycnCZIeeDnL8wZtZPStRht6i4PFTCX1Y/Ogw0L0bhuthOx+VTgICB87r0TmXElNUDLSncsxuw7pmHa669idUkv43CjeDkH0kGFEHt4QA6/xw1Xq9oNpRJTo62ZsFmv0Pwp3uE7up8s0LW1O6fr+Ow== dpn@dpn41s àà dpn_key.pub.pub


可以看到公钥都放在了authorized文件里面。


那我们怎么判断密钥是不是匹配和正确呢?我们自然有妙招:

妙招五、ssh-keygen -y -f <private key file>

这样可以看得到的公钥是不是和真实的公钥一样。

例如我们用这个命令来计算出公钥,然后用真实的公钥来和我们计算出的公钥比较,如果一样,那就说明匹配,不然就不匹配。


admin@gen4-util:~/>: ssh-keygen -y -f /home/admin/.ssh/dpnid

ssh-dss AAAAB3NzaC1kc3MAAACBAJZQxK/WSlbp6TJ6PYJpE2fi5fRgnXFvOnuzTFeB69T7Hka55BKZL5j4MK83t5rYw66kX2fvsjapVou4JNmjVtQNaAcUDNzwEhG7FJrT9T1xVTEYD674GSm56lpYZbhXPl4chu0K599leVE1xMM2uoOsl8pKBlbYSME0Hu8KBvVTAAAAFQDZZBWMBp3614Ml4noY9FfKfTLrdwAAAIA2S3F0yhScRHuVUfWF4gyrqUAJY591uW0R3Br9Ds565kRjjfgLTQBSw/arp/1thEJ05BR5ILmER6pvu+A57/cc3TYZEfuw9mN9YdH+ycANmxa/PRNlC7Juzx0R0aH97MaGIi0Ig0WRWDs29JfHzl0xWwHk30m7SAOxnFb93jVVdgAAAIBH0zIlb3lvioedyZj2mKF6fycnCZIeeDnL8wZtZPStRht6i4PFTCX1Y/Ogw0L0bhuthOx+VTgICB87r0TmXElNUDLSncsxuw7pmHa669idUkv43CjeDkH0kGFEHt4QA6/xw1Xq9oNpRJTo62ZsFmv0Pwp3uE7up8s0LW1O6fr+Ow==

root@gen4-util:~/>: cat /home/dpn/.ssh/dpn_key.pub

ssh-dss AAAAB3NzaC1kc3MAAACBAJZQxK/WSlbp6TJ6PYJpE2fi5fRgnXFvOnuzTFeB69T7Hka55BKZL5j4MK83t5rYw66kX2fvsjapVou4JNmjVtQNaAcUDNzwEhG7FJrT9T1xVTEYD674GSm56lpYZbhXPl4chu0K599leVE1xMM2uoOsl8pKBlbYSME0Hu8KBvVTAAAAFQDZZBWMBp3614Ml4noY9FfKfTLrdwAAAIA2S3F0yhScRHuVUfWF4gyrqUAJY591uW0R3Br9Ds565kRjjfgLTQBSw/arp/1thEJ05BR5ILmER6pvu+A57/cc3TYZEfuw9mN9YdH+ycANmxa/PRNlC7Juzx0R0aH97MaGIi0Ig0WRWDs29JfHzl0xWwHk30m7SAOxnFb93jVVdgAAAIBH0zIlb3lvioedyZj2mKF6fycnCZIeeDnL8wZtZPStRht6i4PFTCX1Y/Ogw0L0bhuthOx+VTgICB87r0TmXElNUDLSncsxuw7pmHa669idUkv43CjeDkH0kGFEHt4QA6/xw1Xq9oNpRJTo62ZsFmv0Pwp3uE7up8s0LW1O6fr+Ow== dpn@dpn41s

 

然后我们登录到一台storage node上,我们会发现所有只要通过SSH登录成功的机器,他们的公钥都会存在每个账号的known_lists里面的。因为avamar有三个系统账号:admindpnroot。因此只要用哪个账号来ssh登录过的,在这个账号的known_lists里面就会有这个账号的公钥:

admin@gen4-data1:~/.ssh/>: cat known_hosts

 

  1. 10.32.167.88 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA49Ueggi8WrdvTP+1cenYNSSrPv8GMJyiFqcsmDyqOQuQiLxiirtORm7P633JZrW4vzpHQZzdd0Q4ASybYXbaHB2F+S3UMl9x9OGaWigk06SgWLF6Kh9kbjFgFYCIIpZW1RTo75N7r7f+rUmLCCmrYYi3Cy1XhEEMedKB948WnG0=
  2. 10.32.167.84 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAsV1RM7h5RDT7EfBktWbU0Ezm96QlHYZoq6JbbMJkThzleOzX+GzO5qqIBXUiDvIP08jSNuDlfCO9aTEQivYmZZoHpYdsPpxW/YZIw0a4+Pa+mzwqFkmwwZGe+ck/nUjJ+3tfpiDtNbMBg+cAJGrrkUyo4drL7SW0D5qfg5cU/0c=
  3. 192.168.255.1 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA74EBveMGzDU5laPV2vBhaAODFOPHUO33hacBIzotX+mBnyq+jhBBuuFU12PstkBleUUWOz6JrefT/HPaTXojyzqQWdVD+j97RZg9EZY3JqwRjFrcjEZ89JfNY43T7lJGx8tKLAt2HB2gg9CU82QLvOOdgTuewh6736G3CVu1LI0=
  4. 10.32.167.135 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA7mZB7Eksd6S2SZGbm/yp/caQsSKi+bUItDog4uh12GuT5oxe6hFZtM2gJEMlGQvbqQMw+gMpUckrrYINWB7iaNXgzdK08YCd4/EUP8E74WvbG2h3WCqsYJ8FoP2qR3DXPzzoUQkwyNoTsGL3NDcVqRnylYDarRyWlHCfXCVNJNM=
  5. 10.32.167.99 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA74EBveMGzDU5laPV2vBhaAODFOPHUO33hacBIzotX+mBnyq+jhBBuuFU12PstkBleUUWOz6JrefT/HPaTXojyzqQWdVD+j97RZg9EZY3JqwRjFrcjEZ89JfNY43T7lJGx8tKLAt2HB2gg9CU82QLvOOdgTuewh6736G3CVu1LI0=
  6. gen4-util ssh-rsa

AAAAB3NzaC1yc2EAAAABIwAAAIEA74EBveMGzDU5laPV2vBhaAODFOPHUO33hacBIzotX+mBnyq+jhBBuuFU12PstkBleUUWOz6JrefT/HPaTXojyzqQWdVD+j97RZg9EZY3JqwRjFrcjEZ89JfNY43T7lJGx8tKLAt2HB2gg9CU82QLvOOdgTuewh6736G3CVu1LI0=

 

如上面的案例,我们可以发现该storage nodeadmin账号里,有多个其他节点包括Utility Node的公钥。


我们再来介绍最后两个有用的妙招:

妙招六、ssn --user=root 0.<node ID>

我们可以通过root账号来登录到任何一个节点。如下面的例子:

5.png


妙招七、mapall命令

这个命令可以帮助我们同时列出多个节点上的信息。但是前提是需要ssh-agent bashssh ~/.ssh/dpnid来加载key后,通过ssh的方式来使用。

6.png

如使用这个命令,我们可以通过SSH的方式同时列出所有节点的online的天数。当然这个命令还可以搭配别的参数来使用。这个以后我们还可以详细来介绍。


怎么样?今天对我们的SSHkey有所了解了吧?下次我们将介绍SSH KeyDD上的使用以及如何来排错和纠正SSH Key的错误?SSH Key是非常重要的东东,因为我们在《如何给Avamar航班做个高效的飞行体检》中讲到过如何使用proactive check脚本来检查整个avamar系统,而使用这个脚本的前提就是要加载SSH的密钥,不然这个脚本也无法运行。

有了Avamar的这把金钥匙,我们就可以“任性”地在任何节点上来回穿梭和干活。当下流行“有钱就任性”,在我们Avamar的产品中,“有Key就任性”!

我们遇到很多客户对于NetWorker的日志和警报有一些疑问,有一些客户工作比较繁忙,没有办法长时间在NetWorker Management Console面前来监控备份的情况,在备份失败的时候如果及时作出响应,从而导致备份数据无法恢复的后果。同时NetWorker的备份日志数据量非常大,也无法直接通过文本方式打开查看,这给很多普通用户造成了困扰。许多客户都有一些疑问,我们的NetWorker备份软件是不是可以像大部分硬件存储产品一样,一旦出现异常状况,可以发出自动报警。而备份管理员在收到报警信息之后就可以及时作出处理。比如重新备份,检查备份设备,测试恢复等等。

 

同时我们也有一些客户有一些比较特别的需求。比如说他们希望在磁带出现警报信息可能有潜在故障的时候出现报警信息。他们可能希望每次bootstrap备份结束都可以自动发送通知,这样当NetWorker出现灾难故障的时候,他们可以比较轻易地找到需要恢复的数据所在的磁带或者磁盘。

 

为了满足客户的各种不同的需求,我们NetWorker提供了一个强大的通知功能。这个功能可以满足客户各种不同的需要,并且还提供了客户自定义的功能来满足一些客户的特殊需求。

 

我们的通知分两种类型,一种是系统自定义的。下面的截图就显示了所有NetWorker系统自定义的通知。

 

brs1.png

 

 

同时客户也可以根据自己的需求来创建新的通知。通过选择具体的事件,优先级和行为来确认该通知可以实现的功能。

 

brs2.png

 

介绍完通知的类型,我们还需要了解通知的实现形式。我们的通知有两种实现方法,一种是记录到日志里面。大部分系统自定义的通知都是通过这种方法实现的。我们的管理员手册里面提供了详细的介绍,这边就不复述了。还有另外一种实现方法就是邮件通知的方法。这个大部分需要客户完成信息的补充。要使NetWorker将通知自动发送到某个邮箱,可以双击打开该通知的属性,在操作栏中输入:

 

smtpmail -h <mail server> -s "<Subject line of email>" <recipient email address>

 

例如:smtpmail -h notification.emc.com -s "Savegroup Completion Failed" admin@emc.com

 

<mail server>是邮箱服务器的地址,"Savegroup completion failed"是邮件的标题,<recipient email address>是想要发送到的邮箱。

 

然后点击“确定”。这里可以根据需要修改参数或者添加收件人。灵活的运用可以让客户不用打开备份软件管理界面,同样轻松得管理备份,恢复等操作。同时在需要实现灾备恢复的时候,通过邮件的方法尽快地寻找出需要恢复的数据,可以极大的节约客户的时间和精力。如果有兴趣,您可以在备份环境测试通知功能。

 

本文作者简介:

mandy xu.jpg

Mandy Xu

8IT从业经验,20062009年在世界500强外企从事系统工程师一职。2009年加入EMC全球支持中心,服务于NetWorker技术支持团队。熟悉存储备份软件操作,熟悉存储备份相关原理。

对于备份和恢复,除了关心数据是否真正能够被备份和恢复之外,我们也会比较关心它的速度,也就是所谓的性能,毕竟时间就是金钱嘛。况且不能数据都变化很多了,我们备份还一直在跑,这样也没有意义。

 

现在我就根据自己的经验来介绍一下可能会影响Avamar备份性能的因素,这样大家在以后的工作中遇到问题,可以简单的排查一下,从而有利于我们快速解决问题。

 

备份过程,简单来说就是客户端通过网络发送数据给Avamar服务器。

 

brs1.png

但是在这三部分,又有各种小的细节会影响备份速度。总体来说,影响备份性能的因素如下:

  1. cache文件不够大。
  2. 未被充分利用的CPU
  3. 客户端和Avamar服务器之间连接过慢(网络方面)。
  4. 客户端磁盘性能不好(磁盘I/O)。
  5. 内存过低(<3gb)。
  6. Avamar服务器性能问题。

 

Avamar备份通常定义的标准速度是

  • 文件系统备份 = 大约一百万文件每小时
  • 数据库备份 = 大约100GB每小时

当然初次备份不算哦~~

 

下面我们来具体看一下:

  • cache文件不够大

首先请了解我们客户端主要有两种cache文件。f_cache主要用于文件系统备份,p_cache主要用于数据库类型备份。f_cache默认的总大小是物理RAM1/8p_cache是物理RAM1/16。另外,cache文件的大小是成倍增长的,而不是一点一点增加。比如当前的cache文件大小是300MB的话,下一次增长它的大小就是600MB

 

同时,我们都知道,Avamar是前端去重备份机制,它主要是基于cache文件来去重的。在之前“浅谈Avamar备份如何处理文件”这篇文章里面我们讲到备份开始的时候Avamar会对比本地文件和cache文件来决定哪些数据需要通过网络发送给Avamar服务器,哪些是已经备份过的数据,而不需要再次发送。

 

brs2.png

 

基于以上信息,如果默认的或者您限定的cache文件总的大小过小,从而导致它无法继续增长,备份速度就会受到很大影响。这时候我们就需要检查当前cache文件大小和它总的大小,决定是否更改其原来的值,从而改善备份速度。从备份日志里面,我们可以根据以下信息判断cache文件大小是否足够:

F_cache:

2014-02-04 06:34:37 avtar Warning <6562>: CAPACITY WARNING: The file cache is full; filecachemax=256MB, 2097150 entries overflowed.

P_cache;

<HASH_CACHE>entries=2097152,added=709614, overflow=56849</HASH_CACHE>

 

改变方法:登录到客户端,在c:\Program files\avs\var目录下,编辑或者创建avtar.cmd文件,添加以下参数:

--filecachemax=<size in MB> or <size in fraction>

--hashcachemax=<size in MB> or <size in fraction>

注意:cache文件大小不要超过物理RAM1/4,因为这样也会影响性能。

 

  • 未被充分利用的CPU

例子:2013-02-07 08:12:59 avtar Info <8688>: Status 2013-02-07 08:12:59, 7,758,607 files, 156,089 folders, 380.4 GB (3,821,086 files, 128.5 GB, 33.80% new) 623MB  4% CPU  X:\images\IMAGES29\3704\

 

从上面备份结果我们看出备份过程CPU利用率只有4%。这种情况一般说明客户端比较忙(运行其他程序)或者磁盘性能有问题。

 

另外,一些第三方杀毒软件也会影响备份速度。

一般杀毒软件工作机制是如果有个程序打开某个文件,它就会去扫描一下这个文件以确保没有病毒。这种情况下,如果每个被备份的文件都被扫描,备份速度看起来就会很慢。所以,如果您需要备份某个客户端,请确保将avtar.exe加入到杀毒软件的安全列表中。

 

  • 客户端和Avamar服务器之间连接过慢(网络方面)。

这种情况下,我们看到日志通常会有以下内容:

2013-03-08 02:33:20 avtar Info <8688>: Status 2013-03-08 02:33:20, 2,713 files, 695 folders, 1.198 GB (56 files, 809.2 KB, 0.06% new) 33MB   0% CPU  C:\Documents and Settings\cnwhite\ntuser.dat.LOG

2013-03-08 02:35:23 avtar Info <7694>: Server(mkeavbak05.mke.ra.rockwell.com) not responding (possible network congestion?) (600 seconds)

2013-03-08 02:39:39 avtar Info <7695>: Server(mkeavbak05.mke.ra.rockwell.com) is back (855 seconds)

2013-03-08 02:44:39 avtar Info <7694>: Server(mkeavbak05.mke.ra.rockwell.com) not responding (possible network congestion?) (300 seconds)

 

其实如果真的是网络问题所引起的性能缓慢,就已经不是我们Avamar技术支持人员要参与的操作了,但是为了帮助客户了解形势,我们一般也会帮助客户做一些基本测试(当然最好是能够有专门的网络工程师帮忙测试了^_^这需要客户的配合)。我们通常会使用iperf测试客户端和服务器之间的网络带宽。具体步骤如下:

  • 登录到客户端,打开putty并连接到Avamar  Server
  • 然后在putty上面运行命令:iperf -s -i 1
  • 在命令运行的同时,也在客户端上面运行以下iperf命令:
  • iperf -c AvamarServerIP -i 1
  • 命令运行一段时间后中断操作然后查看结果。

 

我们也会运行备份测试,使用randchunk 参数来生成日志从而检测备份时使用的带宽:

avtar -c --randchunk=10000 --compress=none  --status=60  --comstats –nocache --logfile=c:\randchunk.log  --id=MCUser

--ap=MCUser1 --server=Avamar.emc.com --path=/clients/DaveTemplin.emc.com

 

如果是要测试网络延迟和丢包的话,可以使用常pingtcpdump来检测。

 

  • 客户端磁盘性能不好(磁盘I/O)。

其实,一般performance问题做下来,都是客户端磁盘性能不够好,但是一般客户最开始时候都不愿接受这种结果。所以我们通常会经过一系列的备份测试帮助客户去检查并了解情况,最终找到根本原因。

 

对于磁盘性能的测试,说实话,我们更希望客户自己能检查,毕竟我们在这方面的经验没有系统维护工程师或者存储管理员有经验丰富(囧)。但是我们还是会尽力滴,作为参考我们会采取以下措施去判断问题:

  1. 利用windows自带的performance测试工具performance monitor去观察磁盘性能。
  2. 手动从客户端复制文件到另外一个客户端看其花费的时间是否正常。
  3. 运行一个备份测试,加上—degenerate参数,例如:

avtar -c --degenerate --compress=none  --nocache --logfile=c:\degenerate.log

--id=MCUser  --ap=MCUser1 --server=Avamar.emc.com --path=/clients/DaveTemplin.emc.com  E:\testdata

有了这个参数,数据是不会真正通过网络被发送到Avamar服务器去的,这样我们可以通过备份速度来判断客户端这边是否有性能问题。

 

  • 内存过低(<3gb)。

这个就是客户端系统资源的问题了。如果系统资源过少,Avamar运行时能用的memory就会很少从而影响备份速度。

 

  • Avamar服务器性能问题。

这里也会涉及到很多,比如Avamar服务器很忙,某个节点的性能不好,gsan或者msc问题等等。

如果是这种情况的话,您所有的备份都可能会受到影响,或者至少大部分备份都会有问题,这时候,就放心交给我们来检查吧。

 

当然,我们也会单纯的从Avamar角度进行日志分析,然后大概判断问题所在。经典的做法就是:

1.       登录到客户端,打开C:\Program Files\avs\var文件夹。

2.       创建并编辑avtar.cmd文件,加入以下参数:

--stats

--status=60

--comstats

3.       保存此文件然后再次发起一个备份。等备份再次失败之后,收集日志并分析。

 

那么这些参数有什么用呢?

  • comstats 参数用于诊断avtargsan之间通信问题(每秒)
  • Avtar comstats 说明:

avtar Stats <0000>: 2013-10-11 06:18:20 COMSTATS:0 sent= 84 recv[0]= 84  pending= 1/ 5 int= 0/50 send= 0 bytes= 9408+ 17711 sleepms= 0 delay=(0.008 [0.000..0.210] sd=0.030 n= 53) (0.022 [0.000..0.324] sd=0.066 n= 31)

此条信息显示客户端数据发送量和服务器接受量,等待的数据量和数据延迟时间。通常我们会根据此信息判断是客户端数据发送不过来还是服务器太忙从而无法接受客户端发的数据,已经接收数据是否有延迟。

--status=60参数会每个60秒输出出来当前在备份哪个文件,目前为止扫描了多少文件,大小是多少,新增的数据量等等。

 

上面说了这么多,也不是说一有备份性能问题就由大家自己去检查,我们完全置身事外。只是希望在大家的配合下,我们能更快速有效的解决问题。

 

更具体的东西我就不介绍了,因为太深入或者太多的日志分析也会让大家觉得很烦。希望这些信息能给大家一个初步印象,那就是备份性能不是某一方面的因素决定的。

 

如果大家的工作中遇到任何问题,欢迎随时联系我们,一如既往,我们是很乐意和大家共同来处理分析并解决问题的。

各位,马年好啊。老朋友,我们又见面了。那次的“乾坤大挪移”,不知道您练到第几级了?估摸着应该学到个八九成了吧,借着马年的新气象,我也借用一句“马上复制”。您可要问了,什么是“马上复制”?不是马上有钱,万马奔腾吗?这话不错,可要搁到我们Avamar 7.0上,我们就要说马年啦,“马上复制”,“马上备份”,“马上恢复”,才会“马到成功”。

                小的我就不用肺来说话了,咱们马上进入正题。

                今儿,我们要学习Avamar 7.0Replication复制功能。Avamar 7.0到底有什么新的变化呢?

                先来个破题,什么是ReplicationReplication顾名思义,就是把数据噌噌地从一台Avamar机子上备份到另外一台机子上,所以原先的Avamar服务器,我们称之为源端服务器(the source grid),目标的Avamar机子称为目标服务器(the target grid)。万一一个不当心,源端的数据挂了,您还可以用目标端的数据来恢复。

                那您会问,7.0之后,Avamar的复制到底有了什么功能呢?

  1. 更方便,更人性,更简单的GUI可视化操作。可以支持多达10个的复制任务同时独立地运行。可以在目标服务器上配置独立的Retention策略。可以配置在同一个复制任务中,客户端复制的优先级。
  2. Avamar的单节点或者utility node (如果您的机子是多节点的话,将会有一个控制数据节点的节点)上运行单一的进程。
  3. GUI的监控视图也得到了改善

   7.0之前的Avamar的复制是使用脚本模式,而7.0之后的Avamar可以支持脚本模式,也可以支持插件模式。

1.png

哇塞?上面这张图是神书?别担心,看不懂,正常。小的我写个文章,不容易呀,总也要弄个什么“高端大气上档次”的图片来秀下。其实我给您简单解释下,您就懂了。

左边是使用计划脚本任务的复制模式(7.0之前的复制模式),右边是使用基于插件的复制模式(7.0之后的新复制方法)。

基于任务脚本的模式,是通过配置repl_cron.config的文件,来调用系统的crontab进程,从而调用avtar进程来复制。您可能会不信,我明明也是在管理控制台上面或者EMSweb界面上去设定什么目标服务器,需要备份什么客户端的。其实从控制台上也好,从web上也好,最终都会把配置信息写入到repl_cron.cfg(位于/usr/local/avamar/etc里面)。您要是不信,自个儿回头去查下呗。

基于插件模式的复制,是通过加载管理控制台的数据库,然后Scheduler会出发工作流,来调用avrepl,从而触发avtar进程来复制。

懂了吧?那您会问什么是avtar进程?您的客户端的备份会用到这个进程,我们复制也会用到这样一个进程,如果想简单理解的话,就相当于把您源端上的数据,备份到目标上去,这就是复制。

 

那我们来看下使用插件复制和使用脚本来复制的区别。

区别一:

2.png

上面这张表好看多了吧,总算是不接“天气”,接“地气”了。一个是脚本配置,一个是插件配置。一个是在脚本中列入需要复制的客户端,一个是可以在每个任务中去配置客户端。

区别二:

3.png

现在我们来讲下新的地方:

 

一、更人性的可视化窗口

4.png

是不是多了一个复制的菜单了吧?不用每次为了一个复制窗口找半天了。

理论固然有用,但是还不如真枪实弹来的实惠。下面小的来教你下,如何用插件来简单配置一个复制。

Step1:添加一个Avamar的目标端。

打开源端服务器的UI

5.png

点击“replication”。

找到“Destinations”的tab键:

7.png

点击“New Destination.

Step2: 配置目标服务器。

8.png

输入目标服务器的IP和凭证。

Step3:创建组

点击如下黄色部分的图标:

9.png

输入组名

10.png

选择客户端和备份。

如下图,选择需要复制的备份:

11.png

选择目标服务器:

12.png

自行设定备份过期的时间:

13.png

                下面设定任务时间:

14.png

完成,搞定。


Step4:运行一个复制

16.png

Step5:查看复制的情况

17.png

二、复制的多样化

                啥也不说,先求图,求真像:

18.png

                厉害吧!我们可以支持多对一,一对多,交叉复制,链式复制。当然我们的Avamar还不止以上的复制方式,我们还支持root-root的复制模式,常规的基本复制,会把源端的备份放到/REPLICATE目录下,但是root-root的复制模式,会让目标服务器和源端服务器看上去一模一样,适合灾难恢复等。您要问我了?那root-root的复制,怎么弄呢?在这里,小编我卖个关子,想知道吧,您得“马上筹钱”,找我们专业服务团队来帮您弄呗。

 

                在这辞旧迎新之际,Avamar7.0的可视化复制操作,是不是让您很心动啊?您也许会说Avamar真的很“感人”,那您“马上”实施吧,您的行动一定让我们觉得“更感人”!

                最近马航事件扑朔迷离,好好的一架飞机说没就没了,是驾驶员恶意破坏,还是被人Hijack,亦或是机械故障导致失踪?在没有找到证据之前,一切都只是猜测。但是法航447事件,却可以知道事故的责任是机器故障+人为处理不当。由于皮托管测速仪在高空结霜,飞机除冰失败,造成数据不准,以致于两位副机长各自采取了不正确的方式,最后导致飞机是机头朝上爬升姿势掉入深深的大西洋中。人祸自然是主要因素,但是机械故障也是诱发事故的主要因素。通过空难的思考,在我们的备份系统中,也要未雨绸缪,在机器没有出现重大问题的时候,要预先给机器做个健康检查。

                虽说航空总体来说还是比较安全可靠的,但也会出现故障,更不要说我们平时使用的机器和系统。如今都进入了大数据时代,什么云计算,云数据等,数据都在天上飞,云中翔,那我们的Avamar航班如何带领您遨游云数据的天空?如何在遨游云天空的时候,保护您的飞机(即您的Avamar航班,简称A航)?今天敝人不才,暂且把自己比作A航的乘务人员,教大家如何体验A航的安全之旅。

飞机会遇到各种故障,我们的A航也会遇到故障+人祸的现象。举个简单的例子,如果某天Avamar一下子遇到许多不重复的新数据,Avamar的空间使用率就会邹然上升,而系统管理员发现空间,就自己删除了一些旧数据,而在界面上随意启动Garbage Collection(俗称旧数据回收),虽然会帮助我们系统清除旧数据,但是他却没有意识此时的Avamar操作系统的Checkpoint空间占用率会上升,从而渐渐占满整个操作系统,然后导致Garbage Collection因为操作系统空间不够而失败,也会让整个系统没有可用空间的悲剧。

以上只是一个案例,平时使用中会有各种截然不同的案例。因此在问题出现之前,何不给我们的Avamar系统做个安全检查呢?这样就可以让我们预知A航存在哪些隐患问题,在这些问题诱发别的大问题之前,我们把诱因扼杀在摇篮之中。

总而言之,让Avamar的航班号在给您的重要数据护航保驾时候,做些必要而又简单的飞行安全体检是非常有必要的。否则遇到数据解体,硬盘损坏就后悔莫及。

 

体检项目一:总体故障检查

必用工具:Proactive Check工具

体检报告:hr_results文件

体检实施步骤:

 

准备步骤:提前创建Proactive Check的目录并导入您的Admin账号key

                Putty或者任何可用的SSH工具登录到Avamar系统,建议您使用admin账号登录,密码是您设置的,或者默认密码。如果您习惯用root账号登录(这将被视为一种不安全的登录方式),请切换到admin账号,方法:su - admin

                Admin账号登录完毕之后,这就意味着您进入了A航的机舱,然后要启动密钥机制。

                如下图:

              ScreenHunter_01 Jun. 27 09.57.gif

                不但输出了节点的在线时间,也可以看到一共有几个节点。如本次航班中,有3个节点。然后接下来我们要创建一个文件夹,专门用来存放我们的体检工具。

                如:mkdir Proactive_Check (当然是位于/home/admin目录里)下面我们就可以正式做体检了。

 

步骤一、获取和下载Proactive Check工具

ftp://avamar_ftp:anonymous@ftp.avamar.com/software/scripts/proactive_check.pl

可以通过以上链接得到最新的Proactive Check工具。

 

Option A

                如果您的A航可以连通到Internet网络的话,就直接在您的班机中下载上面链接。

                命令:

                cd /home/admin/Proactive_Check (该目录之前已经创建)

curl -o ftp://avamar_ftp:anonymous@ftp.avamar.com/software/scripts/proactive_check.pl

 

Option B

                用您自己的桌面机去下载工具,然后用winscp之类的工具上传到Avamar/home/admin/Proactive_Check

 

步骤二、设置正确的权限

因为A航的系统默认是不允许运行perl脚本,所以我们要更改其权限,如下:

admin@gen4-util:~/Proactive_Check/>: chmod u+x proactive_check.pl

然后我们就可以运行这个脚本了:

admin@gen4-util:~/Proactive_Check/>: perl proactive_check.pl

一般如果您得到的输出结果都是Passed,表示各项指标都正常了。如果有Failed的话,那么需要关注。

 

                我们来举个样本例子:以下是本次A航的样本结果。

[样本]

admin@gen3-single:~/jason/>: perl check.pl

 

proactive_check.pl 3.092 (Fri Apr  4 12:13:45 2014)

 

Latest script version           DISABLED

Avamar Hostname                 gen3-single.sh.lab.emc.com

Avamar Server Version           6.1.0-402

GSAN Version                    6.1.0-402

MCS Version                     6.1.0-402 (8ad82f96dce58b8b9be30e098af974c4)

System ID                       1328224578@00:24:E8:56:32:5A

Hardware Manufacturer           dell

Operating System                redhat

Node Type                       Single Node 1.0TB Gen3

Datadomain                      SH-DD690.dd.com  Vers:5.1.0.9-282511

Data Domain Patches            *FAILED*

Registered Media Access Nodes   DETECTED

Replication Partner             Target for 10.76.179.27

Replication Partner             Target for single.avamar.lab

Version Supported               PASSED

MC flush in past 24 hours       PASSED

EM flush in past 24 hours       PASSED

HFSCheck in past 36 hours       PASSED

Checkpoint Status               PASSED

Ethernet Settings               PASSED

GSAN status                    *FAILED*

MCS status                      PASSED

EMS status                      PASSED

Backup Scheduler running       *FAILED*

Desktop/Laptop running          PASSED

Maintenance scheduler running   PASSED

Cron jobs enabled              *FAILED*

Unattended startup             *FAILED*

  1. Status.dpn                     *FAILED*

Duplicate IP                    PASSED

License                         PASSED

Mandatory Client Upgrades      *FAILED*

ATO Check                      *FAILED*

Data Domain Version             PASSED

/etc/profile                    PASSED

IPMI Check                      PASSED

Bonding Configuration           WARNING

Data Domain gcoob.pl           *FAILED*

ascd status                     PASSED

Cron Running                    PASSED

Checkpoint Retention            PASSED

Config Settings                 WARNING

HFSCheck overtime allowed       PASSED

Swap space                      PASSED

File Permissions                PASSED

  1. Checkpoint.xml Perms            PASSED

Bug 13252 O/S reserved space    PASSED

HFSCheck run time               PASSED

Replication Cron Setup          PASSED

Operating System Updates        PASSED

perftriallimit setting          PASSED

Mandatory Upgrades              PASSED

GSAN Patches                   *FAILED*

MCS Patches                    *FAILED*

Dell Open Manage Tools          PASSED

Dell Virtual Media Disabled     PASSED

Dell log rotate                 PASSED

Hitachi Disk NCQ                PASSED

Disk Controller Driver Version  INFO

Disk Controller Status          PASSED

Disk Cache Disabled             PASSED

Disk Firmware                   PASSED

Dell Patrol Read Disabled       PASSED

Dell Block Update              *FAILED*

Dell Hardware Status            PASSED

 

See detailed ERROR information in hc_results.txt

 

FINISHED

 

[分析]

喔!这个航班的机器故障隐患真是多啊!

下面是对各项输出的解释:

名称

分析

重要性

Avamar Hostname

本次航班的机器名

☆☆☆☆☆

Avamar Server Version

Avmar Server的型号

★☆☆☆☆

GSAN Version

GSAN的版本号,GSAN是用来做备份的进程。

★☆☆☆☆

MCS Version

MCS的版本,可以理解为您的Avamar的控制台版本。

★☆☆☆☆

System ID

系统的ID号

★★☆☆☆

Hardware Manufacturer

制造提供商

☆☆☆☆☆

Operating System

操作系统类型

★☆☆☆☆

Node Type

节点类型,一般分为多节点和单节点。

★☆☆☆☆

Datadomain

如果含有DataDomain的话,显示DataDomain的信息

★☆☆☆☆

Data Domain Patches

DataDomain的Patch缺少。

★★☆☆☆

Registered Media Access Nodes

Media Access节点

★☆☆☆☆

Replication Partner

如果配置了复制,复制的信息

★★☆☆☆

MC flush in past 24 hours

MC的数据库是否在24小时内备份否

★★★☆☆

EM flush in past 24 hours 

EM的数据库是否在24小时内备份

★★★☆☆

HFSCheck in past 36 hours

HFScheck的数据库是否在24小时内备份

★★★☆☆

Checkpoint Status

CP是否制作

★★★★☆

Ethernet Settings

网络设置是否正确

★★★☆☆

GSAN status

GSAN的程序是否正确,如果是Failed,是个危险的警告

★★★★★

MCS status

MCS的状态

★★★★☆

EMS status

EMS的状态

★★★★☆

Backup Scheduler running

Backup的服务是否启动

★★★★☆

Desktop/Laptop running  

DTLT的服务

★★★☆☆

Maintenance scheduler running

Maintenance的服务是否启动

★★★★☆

Cron jobs enabled

Crontab的计划任务是否启动

★★★☆☆

Unattended startup 

单节点会用到的gsan开机启动服务

★☆☆☆☆

  1. Status.dpn

总体状态

★★★★☆

Duplicate IP

是否IP冲突

★★★☆☆

License

序列号是否正确

★★★★★

Mandatory Client Upgrades 

客户端是否升级

★★★☆☆

ATO Check

如果有磁带库的话,状态是否正确

★★★☆☆

Data Domain Version

DD的版本

★☆☆☆☆

/etc/profile

环境变量是否正确

★★☆☆☆

Bonding Configuration

端口绑定是否正确

★★☆☆☆

Data Domain gcoob.pl

GCOOB,运用于DD的数据清理

★★☆☆☆

ascd status   

ASCD状态,用于节点通信

★★★★☆

Cron Running

Cron的服务

★★★☆☆

Checkpoint Retention

CP的数量是否正确

★★★★☆

Config Settings 

Avamar设置是否正确

★★★☆☆

HFSCheck overtime allowed

HFScheck是否允许超时

★★☆☆☆

Swap space 

内存SWAP是否正常

★★☆☆☆

File Permissions

文件系统权限是否正确

★★☆☆☆

  1. Checkpoint.xml Perms 

CP配置文件的权限

★★☆☆☆

HFSCheck run time 

HFScheck的运行状态

★★★☆☆

Replication Cron Setup

Replication是否配置正确

★★★☆☆

Operating System Updates

OS是否需要升级

★★☆☆☆

Mandatory Upgrades

avamar是否需要升级

★★☆☆☆

GSAN Patches

GSAN是否需要安装补丁

★★☆☆☆

MCS Patches

MCS是否需要补丁

★★☆☆☆

Dell Open Manage Tools

Dell管理工具是否安装

★☆☆☆☆

Dell Virtual Media Disabled

Dell的VM是否使用

★☆☆☆☆

Dell log rotate

Dell的日志是否满

★☆☆☆☆

Hitachi Disk NCQ 

磁盘是否正确

★★☆☆☆

Disk Controller Driver Version

存储Controller的版本

★☆☆☆☆

Disk Controller Status 

存储Controller的状态

★★★☆☆

Disk Cache Disabled

Cache状态

★★☆☆☆

Disk Firmware

磁盘固件版本是需要升级

★★☆☆☆

Dell Block Update  

Dell Block Update是否需要升级

★★☆☆☆

Dell Hardware Status 

硬件是否有问题,如磁盘,电源等。

★★★★☆

 

GSANstatus.dpn是航班的引擎,负责最主要的任务,因此算是Avamar的核心。

像本例中的GSAN状态不正确,说明GSAN的程序有问题,是一个比较严重的问题,我们在体检项目四中会分析。同时Backup Scheduler running  这个failed,表示备份的服务可能遇到问题,也是不容忽视的问题。因此三个以上的问题,需要联系航班的维修工程师(Avamar的技术工程师)来维修。

 

体检项目二:系统容量检查

这个项目主要是检查操作系统的空间是否安全,我们可以用一个简单的命令来检查:

admin@gen4-util:~/>: avmaint nodelist|grep fs-per

        fs-percent-full="18.6"

        fs-percent-full="17.6"

        fs-percent-full="17.5"

        fs-percent-full="17.8"

        fs-percent-full="17.8"

        fs-percent-full="17.4"

        fs-percent-full="18.3"

        fs-percent-full="17.5"

        fs-percent-full="17.5"

上面列出了各个分区的占用比例,单位自然为百分比,如果只要有任何一项超过85%,那么就是一个危险的警告。因为如果有一个分区超过85%,那么平时日常的预定的Garbage Collection就会报失败,而失败的理由就是Disk Full。这个时候就要检查A航的CheckpointHfscheck是否每天正常工作,当然这是检查的一个主要方面,也有可能其他因素导致OS的占用率过高。敝人之前遇到过某个分区中含有一些测试的日志文件或者别的什么大量文件,然后需要删除这些数据,并重新制作Checkpoint和运行HFScheck

 

 

体检项目三:检查日常的CheckpoingHFScheck

如果遇到体检项目二中的故障,那么就要检查这个体检项目。我们通常使用如下的两个命令:

admin@gen4-util:~/>: cplist –lscp

  1. cp.20140403040034 Thu Apr  3 12:00:34 2014   valid hfs ---  nodes   3/3 stripes  12581
  2. cp.20140403052139 Thu Apr  3 13:21:39 2014   valid --- ---  nodes   3/3 stripes  12581

默认正常的情况,每天应该有两个CheckpointCP)和一个经过验证的CheckpointCheckpoint的作用主要是用来“复制”(其实和真实的复制是有差别的,为了便于您的理解,我们暂用复制来理解)一份正确的先前数据,当数据出现错误的时候,就可以用之前的Checkpoint来回滚和还原。

下表分析了上面输出的结果。

名称

作用

  1. cp.20140403040034

Checkpoint的名字,一般以制作CP的时间命名

Thu Apr  3 12:00:34 2014

生成CP的时间

valid

Valid说明CP是制作成功。Invalid说明CP是无法获取或者有问题,通常情况下如果您的DataDomain上的CP有问题,那么这里会显示Invalid

hfs/rol/-

HFS/rol:说明这个CP是经过HFSCHECK校验。-表示这个CP没有经过HFSCHECK验证。

nodes   3/3

表示总共对三个节点做CP。如果有一个节点down掉,那么数字会显示2/3。

stripes  12581

表示总共有的stripe的数量。

如果每天的CP不正确,需要联系航班的维修工程师,即Avamar的技术工程师来维修。

 

体检项目四:检查Avamar的服务状态

必用命令:status.dpn

admin@gen3-single:~/jason/>: status.dpn

Fri Apr  4 13:13:29 CST 2014  [gen3-single] Fri Apr  4 05:13:29 2014 UTC (Initialized Thu Feb  2 23:16:18 2012 UTC)

Node   IP Address     Version   State   Runlevel  Srvr+Root+User Dis Suspend Load UsedMB Errlen  %Full   Percent Full and Stripe Status by Disk

  1. 0.0    10.32.167.88  6.1.0-402  ONLINE fullaccess mhpu+0hpu+0000   2 false   4.03 5798 18653680  61.8%  65%(onl:755) 60%(onl:764) 60%(onl:762) 60%(onl:770)

Srvr+Root+User Modes = migrate + hfswriteable + persistwriteable + useraccntwriteable

 

All reported states=(ONLINE), runlevels=(fullaccess), modes=(mhpu+0hpu+0000)

System-Status: ok

Access-Status: admin

 

Last checkpoint: cp.20140404051128 finished Fri Apr  4 13:11:58 2014 after 00m 30s (OK)

Last GC: finished Fri Apr  4 08:18:31 2014 after 03m 24s >> recovered 230.93 MB (OK)

Last hfscheck: finished Fri Apr  4 13:10:51 2014 after 06m 47s >> checked 642 of 642 stripes (OK)

 

Maintenance windows scheduler capacity profile is active.

  The maintenance window is currently running.

  Next backup window start time: Fri Apr  4 21:00:00 2014 CST

  Next blackout window start time: Sat Apr  5 08:00:00 2014 CST

Next maintenance window start time: Sat Apr  5 13:00:00 2014 CST

                从上面可以看到Access-Status的状态为admin状态,如果是在做CP或者启动HFScheck的时候会这样,那就是正常的,如果在backup的时候,显示这个状态,说明可能备份空间不足或者节点有问题。正常的状态应该是FULL

                而且我们可以看到下次备份和做维护的时间。关于更多的这个命令的分析和解释,我们会在以后的文章中给大家做解释。

 

体检项目五:检查所有的服务

必用命令:dpnctl status

输出结果:

admin@gen3-single:~/jason/>: dpnctl status

dpnctl: INFO: gsan status: degraded

dpnctl: INFO: MCS status: up.

dpnctl: INFO: EMS status: up.

dpnctl: INFO: Backup scheduler status: down.

dpnctl: INFO: dtlt status: up.

dpnctl: INFO: axionfs status: up.

dpnctl: INFO: Maintenance windows scheduler status: enabled.

dpnctl: INFO: Unattended startup status: disabled.

分析:

列出了所有的服务:GSAN状态,MCS服务,EMS服务,备份服务,dtlt的服务,和maint服务等。一般正常状态是UP,表示服务正常启动,down/disabled/suspended表示服务没启动或者挂起,甚至服务损坏。

 

检查妙招:

                上面介绍了我们常用对飞机体检的项目,现在我来教大家一招看破系统状态。

                第一步、运用“体检项目四”,查看Avamar的总体状态,查看最高的百分比是否达到65%,如果达到65%,那么GUI上会报100%,说明备份空间满。关于status.dpn的详细介绍,我们会在以后的文章中着重描述。我们需要确保Access-Statusfull和百分比没有查过65%

                第二步、确认“体检项目五”中的所有服务是否UP

                第三步、确认“体检项目二”中的百分比是否超过85%,应该要低于85%

                第四步、确认“体检项目三”中,确认每天是否有两个CP和一个校验的CP

                第五步、在以上都确认正常的情况下,可以运行“体检项目一”中的工具,做个整体检查。

 

           以上是快速简单排查航班是否有故障的简洁方法,如果上述检查有问题的话,需要联系Avamar航班的维修工程师,我们将竭诚为您提供最优质的服务。感谢各位阅读这次敝人给您做的A航的安全科普知识介绍。我们准备启航了:

                “女士们,先生们,欢迎你乘坐EMC Avamar航空公司航班888号,本次航班将前往数据安全备份港……

Filter Blog

By date:
By tag: