Find Communities by: Category | Product

XtremIO介绍:

 

VNX,VMAX,ISILON 等混合阵列不同,XtremIO是全闪存阵列,主要应用环境为VDI,虚拟机和数据库。

2015年5月5日,EMC 全球大会上, EMC宣布推出XtremIO™ 4.0。

XtremIO 4.0被业界称为“野兽”, 采用XtremIO突破性的横向扩展架构,提供40TB X-Brick基本构件以及多达8个40TB X-Brick配置,密度比之前的XtremIO系统提高一倍多。XtremIO 4.0的非中断性能及容量扩展可自动再平衡数据,保持一致和可预测的亚毫秒级性能。

对现有的XtremIO v3.X阵列,EMC将提供免费的无中断软件升级

 

XtremIO系列产品自一年半以前上市以来,现已成长为EMC历史上销售最快的产品,也是全闪存阵列所占市场份额最多的产品。

 

在我们熟悉的Gartner固态存储魔力象限中, EMC XtremIO也位居领导者地位。

1.png

在我们熟悉的Gartner固态存储魔力象限中, EMC XtremIO也位居领导者地位。

2.png

这也是为什么EMC之前敢于发起“XtremIO 100万美金担保(XtremIO $1Million Guarantee)”的活动,EMC宣布第一个能够证明XtremIO存储系统联机的数据服务出现了关闭(switch off)、降速(throttled back)、后处理(post-processed)或者减低优先级(deprioritized)现象的用户,就可以免费获得100万美金的奖金。

 

 

远程变更管理XtremIO团队主要职责:

XtremIO团队主要负责XtremIO系列产品的版本升级以及升级的前期准备工作。亚太地区上海远程变更管理团队的工作时间统一为早上7点到晚上7点。

XtremIO 4.0已于近日发布,远程变更管理团队也将与近期接手XtremIO 4.0 的升级工作。

 

XtremIO升级介绍:

目前远程变更管理团队接受 XtremIO 2.x 版本内的升级以及XtremIO 3.0 版本内的升级.

暂不接受XtremIO 2.x 到XtremIO 3.x的跨版本升级。

将于近日开始接手XtremIO 3.x 至 XtremIO 4.x的升级。

 

 

 

XtremIO升级前准备介绍:

1.  预检工程师将会与客户协商升级日期、指定版本及升级连线方式(ESRS或Webex)等细节。

2.  预检工程师将会对指定升级阵列进行预检,以确保阵列符合升级要求。

3.  预检工程师将会安排指定升级代码上传至指定阵列等待升级。

 

XtremIO升级流程介绍:

1.  升级当天,升级工程师将会按照客户意愿通过ESRS或者Webex连接至指定升级阵列。

2.  升级工程师会在升级开始之前对指定升级阵列进行升级前的必要健康检查,以排除会干扰升级的因素。

3.  开始升级,目前远程变更管理团队所支持的升级全部为线上升级,不会产生宕机时间。

4.  升级过程中会分为两部分,先是XtremAPP升级而后是OS 的升级,会对XMS 和 Storage Controller逐一进行重启。

5.  升级结束后,升级工程师将会对升级阵列再做一次健康检查,以确保阵列能在升级之后正常工作。

 

 

联系方式:

如果有意愿对您的XtremIO阵列进行升级,请随时与RemoteProactive@emc.com 联系预约。

 

如果有任何问题请联系我们:

邮箱:RemoteProactive@emc.com

电话:+1-800-782-4362 x 6305555

网上在线支持: https://support.emc.com  Live chat

 

作者简介:

3.jpg

郑水亮(Derek Zheng

亚太地区上海远程变更管理团队(Remote Proactive Team)升级工程师, 负责XtremIO相关产品的升级工作。

随着VNXe第二代新产品VNXe 3200装机量的提升和客户需求的增加,VNXe的技术支持工程师常常接到客户的咨询,希望能在系统配置上得到推荐和指导,为性能调优。本文主要介绍EMC推荐的VNXe3200系统配置,希望能对这款产品的使用和管理人员带来帮助。


一、优化性能的几大原则

在进行具体的配置推荐之前,我们先来看看以下几条关于性能优化的基本原则:

1、闪存优先。众所周知,闪存盘(Flash Drives)在硬件性能上要优于其它类型的硬盘。因此,我们应当合理利用闪存盘,将性能最优的存储资源配置给最频繁使用的数据,以提升整体性能。

2、注意负载均衡,将负载合理分配到所有可用的硬件资源。

3、在规划存储时,应当注意硬件资源(如CPU、内存、硬盘)的利用率在70%及以下时性能更优。

4、在使用硬盘时,要避免同时处理不同类型的读写。

5、对VNXe的软件(操作系统)版本要及时升级。升级的相关操作可以在Unisphere中进行。


【在Unisphere进行版本升级】Settings --> More Configuration... --> Update Software

update software.png


二、对硬盘的利用

1、我们推荐将性能高的闪存盘分置在不同的总线。这种配置适用于至少有一个DAE的客户,因为DPE使用总线0Bus 0),第一个DAE使用总线1Bus 1),如果还有更多的DAE,则交替连接总线0和总线1

 

2、关于热备盘的规划

VNXe3200的系统中,任何未使用的非系统盘*都可以被用作热备盘。关于热备盘的规划,我们有以下推荐:

1)对某一种类型的硬盘,至少每30块硬盘必须配备一块热备盘。

*注:系统盘(DPE Disk 0 - DPE Disk 3)即DPE的前4块盘,不论是否已经使用,都不能用作热备盘。

 

【如何查看热备盘】在Unisphere中,可以从Storage --> Storage Configuration --> Spare Disks Hot Spare Policy页面)查看热备盘的情况。


hs.png


2)确保每种类型的硬盘都有相应的热备盘。

 

3)热备盘的大小需要等于或大于需要顶替的硬盘。


三、对可用性和连接性的配置

VNXe3200支持多种连接协议,包括FC, iSCSI, NFSCIFS。针对不同的协议,EMC支持网站http://support.emc.com 提供了相应的配置文档。

 

1FC连接

FC协议的连接要求VNXe3200上配有FC光纤I/O模块。针对FC协议的使用,我们有以下推荐:

1)建议每个存储控制器(SP)上使用多个光纤口,以平衡主机端口连接的负载。这是因为主机端口的连接会影响CPU内核的资源分配。


2)如果客户不使用光纤模块上全部的光纤口,请优先使用偶数号的端口(FC port 0/FC port 2),再使用奇数号的端口(FC port 1/ FC port 3)。

 

【查看端口状态】在Unisphere中,可以在Settings --> More Configuration… --> Port Settings中查看端口的状态

port.png

 

2iSCSI连接

iSCSI协议的连接需要用到板载的I/O模块,连接速度为100 Mb/, 1Gb/ 10 Gb/秒。

110Gb/秒的I/O模块性能最优。


2)在所有iSCSI端口上配置巨型帧(Jumbo Frames),即把MTU设置为9000

注:这种配置需要整个网络环境都支持巨型帧。

 

3)如果可以,应尽量为iSCSI的数据流量提供专有的存储网络。

 

3NAS连接

NAS的连接包括使用NFSCIFS协议进行连接,在硬件需求上与iSCSI连接一致,需要用到板载的I/O模块。同样,连接速度为100 Mb/, 1Gb/ 10 Gb/秒。

1)与上述的iSCSI连接相同,10Gb/秒的I/O模块性能最优。在所有NAS端口上也应配置巨型帧(Jumbo Frames),即把MTU设置为9000

 

2)对NAS的连接我们还推荐使用链路聚合和多路径,既能在故障出现时提供端口切换,又能为单边存储控制器的NAS服务器提供更高的带宽。


     A. 在某一边存储控制器上,可以为2个及其以上端口配置链路聚合(LACP)。

   【配置链路聚合】链路聚合可以在UnisphereSettings --> More configuration… --> Port Settings中配置。

lacp.png

 

   请注意,用作iSCSI协议连接的端口不支持链路聚合。如下图:

no lacp for iscsi.png


B.我们推荐在两边存储控制器的对应端口(比如:SP A Ethernet Port 2SP B Ethernet Port 2)使用完全相同的网络配置,这样可以保证跨存储控制器的网络冗余。

 

以上是关于VNXe3200系统配置的一些推荐,主要说明了提升性能的基本原则、存储硬盘的利用和使用不同协议连接的配置。针对具体的问题,请访问http://support.emc.com 进行搜索。


【作者简介】

 

Ying Huang

 

EMC技术支持工程师,目前就职于EMC VNXe远程支持团队。熟悉VNXe 1 Series和VNXe 2 Series产品架构及功能,对VNXe运维及排错有丰富的经验。

  大家好!最近,我们收到了很多客户们发来的问题,我们对几个常见问题进行了总结,希望对各位存储达人有所帮助!


  1. 如何重启SP的管理服务器?

方法一:使用管理界面来重启管理服务器

      1. 打开浏览器,在地址栏输入SPA的管理IP地址:http://<IP_Address_of_SPA>/setup
      2. 使用您登录Unisphere的账户进行登录1.jpg
      3. 点击“Restart Management Server”,选择“Yes”并点击“Submit”来重启SP的管理服务器。2.jpg
      4. 在地址栏中输入SPB的管理IP地址:http://<IP_Address_of_SPB>/setup,并重复步骤bc


方法二:也可以使用命令行界面(CLI)来重启:

      1. Navicli命令:
        > navicli -h  <SPA_IPaddress> networkadmin -restartcimom
        This operation will cause a management server restart!
        Do you wish to continue? (y/n) y


        > navicli -h  <SPB_IPaddress> networkadmin -restartcimom
        This operation will cause a management server restart!
        Do you wish to continue? (y/n) y

         
      2. Naviseccli命令:

> naviseccli -h <SPA_IPaddress> -user <user_name>-password <password> -scope 0 networkadmin -restartcimom
This operation will cause a management server restart!
Do you wish to continue? (y/n) y


> naviseccli -h <SPB_IPaddress> -user <user_name> -password <password> -scope 0 networkadmin -restartcimom
This operation will cause a management server restart!
Do you wish to continue? (y/n) y

注:重启管理服务器不会影响存储的业务以及访问。

 

 

  2. 在使用双控制站(Control Station)的环境中:

    1. 怎么判断哪台是主控制站(Primary Control Station)、哪台是备用控制站(Standby Control Station)?
      • 通过SSH登录到任意一台控制站中,并运行一下命令就能知道谁是主控制站了:

# /nasmcd/getreason

      • 在下面例子中,Control Station 0 Slot_0 是主控制站,Control  Station 1Slot_1)是备用控制站3.png

 

 

    b. 为什么可以通过主控制站的IP地址来访问Unisphere,而备用控制站的IP地址不行呢?

      • 在双控制站环境中,Unisphere以及其它的管理服务只会运行在主控制站上,所以只能通过主控制站的IP地址来访问Unisphere以及进行管理操作。

 

    c. 为什么之前都是通过Control Station 0IP地址来访问Unisphere,而现在突然需要通过Control Station 1IP地址来访问?

      • 如果主控制站因为任何原因离线,备用控制站(如果配置适当)将自动接管所有的控制站功能,并转变为主控制站。
      • 备用控制站不会使用出现故障的控制站的IP地址。每个控制站都配置了其自己的IP地址。*
      • 在这个问题中,由于一些原因Control Station 1 接管了主控制站的职责,而Control Station 0变为了备用控制站,所以Unisphere以及管理服务切换到了Control Station 1上。此时,我们就需要用Control Station 1IP地址来访问Unisphere。同时,需要排查一下Control Station 0是否有软硬件故障,并进行解决。

*备注:如果您配置了IP别名,便可以使用单个IP地址与主控制站进行通信,而不用考虑主控制站是Control Station 0还是Control Station 1。这个功能会在以后的文章中给大家介绍。


    d. 如果控制站出现故障,是否会影响数据访问?

      • 各个Data Mover会继续响应用户请求,不会受到影响
      • 用户对数据的访问不会中断

 

    e. 我们已经将Control Station 0上的故障排除了,怎么样才能将主控制站的职责从Control Station 1切换回Control Station 0

      • 有两种方法可以进行主控制器职责的切换:
        • 方法一:从备用控制站运行命令来接管主控制站职责。
          • 使用nasadmin身份,通过SSH登录到备用控制站
          • 使用su命令切换为root
          • 切换到从/nasmcd/sbin 目录:

                            # cd /nasmcd/sbin

          • 运行命令来接管主控制站职责:

                            # ./cs_standby -takeover

                                                       Taking over as Primary Control Station

                                                             Done

          • 具体请参考下面例子4.jpg


        • 方法二:从主控制站运行命令来切换为备用控制站,并激活原备用控制站为主控制站。
          • 使用nasadmin身份,通过SSH登录到主控制站
          • 使用su命令切换为root
          • 切换到从/nasmcd/sbin 目录:

                         # cd /nasmcd/sbin

          • 运行命令进行主备切换:

                         # ./cs_standby -failover

                                                       The system will reboot, do you wish to continue [yes or no]: y

                                                       Failing over from Primary Control Station

                                                       Broadcast message from root (pts/0)...

                                                       The system is going down for reboot NOW!!

          • 具体请参考下面例子:

                                        5.jpg

 

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


【作者简介】


Jason Zhang


EMC资深技术支持,目前就职于EMC VNX远程支持团队。拥有多年数据中心实施以及维护经验,熟悉数据中心标准与架构。对于VNX运维与排错有丰富经验。

    VNX2相比较VNX1有一些硬件与软件上的区别,比如两者的热备盘机制就有很大的不同。熟悉VNX1代的存储管理员或许会对VNX2代的热备盘管理大吃一惊——“热备盘都去哪儿啦!”嘿嘿不要紧张,本文就将针对两代VNX产品热备盘的机制做一个比较与梳理,相信你很快就能掌握啦。

 

1.热备盘的创建

 

    VNX1代需要手动创建热备盘,创建的方法是创建一个类型为”Hot Spare”Raid Group:

blog1.JPG.jpg

 

    VNX2代不需要手动创建热备盘,但是需要指定一个热备盘的策略:

blog2.JPG.jpg
 
  可选三种Hot Spare 策略:

 

    Recommended——系统默认的Hot Spare策略;

 

    Custom——客户指定的Hot Spare策略;

 

    No Hot Spares——不配置Hot Spare策略;

 

      需要注意的是,这三种策略都不会强制预留任何磁盘作为Hot Spare。如果用户在创建Raid Group/Pool的时候因为选择了过多的磁盘而违反了Hot Spare策略,系统仅仅会弹出告警窗口来做提示,用户可以选择放弃创建或者确认创建:

blog3.JPG.jpg

 

  另外“No Hot Spares”这种策略并不是说坏盘后不会有热备盘顶上,只是说即使当客户选择所有Unbound磁盘来创建Raid Group/Pool,系统也不会发出上述警告。

 

2.热备盘的时效性

  在VNX1中,热备盘是暂时性的,即当新的磁盘被更换上去后,热备盘会将数据拷回新磁盘(Equalization),原始的Raid Group结构不会发生变化。

 

    VNX2引入了永久热备盘的概念,即省略了Equalization的步骤,热备盘会永久参与Raid Group的结构,新换上的磁盘会处于Unbound的状态。

blog4.JPG.jpg

  上面两张图里面,原来的RG 00.0.0 0.0.1 0.0.2 0.0.3四块磁盘组成。之后磁盘0.0.1因为故障被移除,磁盘0.1.23被选作热备盘参与了数据重构并永久参与了RG 0的结构。

 

  永久热备盘虽然省略了Equalization的步骤,但还是可以通过naviseccli命令行的方式将永久热备上的数据拷回原来的磁盘,以此达到方便管理的目的。例如当前需要将上述0.1.23的数据拷回到0.0.1上,就可以使用以下的命令行:

naviseccli  copytodisk  0_1_23  0_0_1

 

3.热备盘被触发的时间

 

  在VNX1里面,当一块处于RG中的磁盘被拔出,热备盘会被立即触发做数据重构。

    VNX2引入了“5分钟等待”的概念。即当一块处于RG中的磁盘被拔出(无论是人为移除或者系统移除),系统会等待5分钟时间才会去找热备盘顶替这块磁盘。例如一块磁盘被误拔,只需要在5分钟内能插回,系统一不会触发热备盘,二只会对这5分钟内变化的数据做重构,这样很快就能恢复到之前的使用状态。

    VNX2通过磁盘的SN号来确定这块磁盘是否属于某个Raid Group, 结合“5分钟等待”的概念,给磁盘的位置移动带来了可能。之前提到永久热备盘的概念,如果想要保持之前的RG结构,可以通过naviseccli copytodisk的命令来调整。其实,我们还可以通过把两块磁盘分别拔出然后交换位置来实现这个目的,但是整个操作必须在5分钟之内完成。

  另外需要注意的是,千万不要交换和移动0.0.0 0.0.1 0.0.2 0.0.3四块系统盘的位置!VNX1VNX2之间的磁盘交换也不被支持。

4.有效热备盘的容量和类型

  只要RG里面数据量较小,VNX1允许用容量较小的磁盘替换同一种类型容量更大的磁盘。但是VNX2只允许容量相同、或者容量更大的磁盘去替换同一种类型的磁盘(不考虑磁盘的尺寸或者转速)。

  另外,VNX2采用了两种不同的SAS SSD盘。SAS Flash盘可以用来配置FAST CACHE或者FAST VP, SAS Flash VP盘只能用来配置FAST VP。然而SAS Flash SAS Flash VP的热备策略需要分别制定,互相不能做对方的热备:

blog5.JPG.jpg

  好啦,关于VNX1VNX2热备盘机制对比就说到这里,是不是很清晰明了呢?更加深入的一些内容大家可以参考EMC KB 170383,这里一并附上供大家参考。

【作者简介】

Andy Yi

EMC VNX/CLARiiON产品技术支持,从事远程技术支持3年,对VNX Block以及CLARiiON产品的故障排查与维修有丰富的经验,熟悉相关产品的硬件构架与功能特性。

我觉得技术支持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技术支持团队。熟悉存储备份软件操作,熟悉存储备份相关原理。

Filter Blog

By date:
By tag: