文件系统安装维护规范

1、StorNext共享文件系统安装配置及维护规范目 录1. StorNext共享文件系统实现基础架构及其工作原理31.1 基于SAN的StorNext共享文件系统架构部署31.2 基于SAN的StorNext共享文件系统工作原理51.3 基于SAN&NAS的StorNext共享文件系统架构部署72. StorNext共享文件系统常用术语103. StorNext共享文件系统实施规范133.1 SNFS系统实施规划133.2 SNFS系统软件安装173.3 SNFS系统软件配置174. StorNext共享文件系统运行维护194.1 SNFS共享文件系统日常维护194.2 SNFS共享文件

2、系统故障处理224.2.1 SNFS共享文件系统常见故障224.2.2 SNFS共享文件系统故障检查及处理步骤234.2.3 SNFS共享文件系统故障售后处理步骤244.3 SNFS共享文件系统启动和停止254.4 SNFS共享文件系统日常维护常用命令27附件1 SNFS标签丢失及修复29附件2 使用cvfsck命令实现文件系统检测32附件3 StorNext产品服务内容及步骤371. StorNext共享文件系统实现基础架构及其工作原理美国昆腾公司的StorNext数据存储管理软件被广泛应用于广电、能源、科学计算、卫星勘测等领域，用于实现数据的虚拟化存储。StorNext数据存储管理软件包括

3、两部分，一是StorNex File System（StorNext共享文件系统，简称SNFS），用于实现异构SAN或LAN环境下共享文件系统；另一个是StorNext Storage Manager（简称SNSM）迁移管理软件。基于StorNext数据存储管理软件可为用户提供一个高性能、大容量的统一存储系统。以下我们主要简述在广电领域被大量应用的StorNext共享文件系统软件的架构部署及其工作原理。在本文我们将介绍两种类型的StorNext共享文件系统部署架构：l 基于SAN的StorNext共享文件系统存储架构l 基于SAN&NAS的StorNext共享文件系统存储架构1.1 基

4、于SAN的StorNext共享文件系统架构部署基于美国昆腾公司的StorNext共享文件系统（也称之为SNFS共享文件系统），可实现多台服务器（甚至是不同类型的服务器）并发共享访问同一个文件。作为一个基于SAN存储架构的共享文件系统，SNFS可以比传统直连存储模式在数据访问和管理方面提供明显的好处：l 分配存储资源更容易。通过取代以每个主机为单位供应和跟踪存储资源，StorNext FS实现了可以被许多主机同时访问的文件系统。可以集中进行存储资源分配、管理和保护数据等管理工作。l 一个共享文件系统消除了存储冗余度，因为很多主机不必保存同一文件的多个副本。这不仅提高了存储系统总体的利用率，而且降

5、低了数据备份和其他数据保护应用的负担。l 数据的可用性更好，因为数据不再绑定在某个单独的服务器上。如果一台主机不可用，其它主机依然可以访问共享数据。l 如果用户不再通过局域网在主机之间传输文件，将大大提高生产效率、降低网络带宽瓶颈。如上图所示，在一个通过SAN实现服务器与存储设备连接的生产环境中，服务器可通过光纤链路实现共享存储的基于BLOCK级的数据共享访问，但这种访问是基于物理层面的，而且往往是服务于数据库系统的。基于StorNext共享文件系统可使得这些服务器可实现文件级的逻辑层面的数据共享，同时这些文件数据的访问链路依旧是基于FC的。也就是说所有的服务器都可以通过FC链路直接共享访问这

6、些数据文件。因此采用SNFS共享文件系统能够有效利用SAN网络保证系统中的各服务器对共享磁盘阵列中数据访问的性能要求。如上图所示，在具体的系统部署中，我们通常将SNFS共享文件系统的管理节点，称之为元数据服务器（Metadata Server或Metadata Controller），在其他的拟实现基于FC链路访问共享存储中数据的服务器称之为SNFS SAN客户端（SAN Client）。在元数据服务器和其他SNFS客户端中部署SNFS软件，实现整个系统中的多台服务器共享存储在光纤磁盘阵列上的数据文件。由于SNFS元数据服务器对所有服务器实现数据访问集中控制。1.2 基于SAN的StorNex

7、t共享文件系统工作原理StorNext共享文件系统实现的数据存储管理是将存储的数据文件逻辑分为两部分，一是文件的基本属性，包括文件名、文件大小、文件创建及修改时间、文件存储位置等，这类信息我们称之为文件的元数据信息；另一个就是这个数据文件存储的数据内容，我们称之为文件的数据体。如上图所示，在一个基于SAN的StorNext共享文件系统中将部署两个网络：一个是用于实现元数据在元数据服务器和SAN客户端之间传输的以太网络，另一个就是用于文件内容存储访问的SAN存储网络。StorNext元数据服务器本身可不负责对数据文件数据体的访问，当一个SNFS SAN客户端服务器希望读取已经存储在共享文件系统中

8、的数据文件时，它只需要首先通过以太网络（称之为元数据网络，我们建议此网络最好只用于元数据信息传输，私有网络将有助于提高SNFS共享文件系统的读写性能）向元数据服务器发出请求，由元数据服务器决定该文件是否可用并且该服务器的应用或用户是否有权访问此文件。如果此文件可被授权访问，则元数据服务器可将此数据在SAN存储设备中的存储位置发送回该服务器，该服务器就可以直接通过高速的光纤网络访问该文件了；对于新文件的创建，元数据服务器将根据策略在SAN存储设备中分配给这台请求存储空间的服务器足够的存储地址，在SNFS客户端得到这些地址信息后，将通过FC链路直接实现数据存储。在此数据存储操作完成后，元数据服务器

9、将及时更新各SAN节点（SNFS的SAN客户端）的共享文件系统的存储信息，以确保数据在所有SNFS节点间的数据访问同步。在具体StorNext共享文件系统的生产部署实现上，由于元数据服务器是整个系统的管理核心，因此我们通常建议客户部署两台服务器，实现主、备元数据服务器的存储结构，组成双机高可用系统，采用Fail-Over方式的双机高可用模式，如下图所示：以保证当正常运行在主元数据服务器的SNFS共享文件系统管理功能出现故障时，这一功能可在限定的时间内切换到另一台服务器中，不会对用户正在生产的业务系统运行产生任何影响。这两台服务器都可称之为元数据服务器，正在实现文件系统管理的服务器为主元数据服务

10、器，处于备援状态的服务器称之为备元数据服务器。采用以上存储架构可实现共享存储中的数据以文件形式实现访问，可实现基于工作流的数据存储管理服务，以提升部门之间、人员之间的协同工作能力，提升工作生产效率、数据访问及管理效率。同时，虚拟化的、文件级数据共享存储访问提高了数据存储资料的利用率，同时更为存储系统的按需扩充奠定了坚实基础。在基于SAN存储架构实现的StorNext共享文件系统中，用户需要针对每一个需要实现数据共享访问的SAN客户端实现授权管理，也就是说，每一个SAN客户端需要一个License，此License与所需的平台相关；同时为实现元数据服务器的高可用管理机制，也需要一个Failove

11、r Option以激活元数据服务器的高可用服务。1.3 基于SAN&NAS的StorNext共享文件系统架构部署在StorNext V3.0以后的版本，美国昆腾国际公司（以下简称昆腾公司）不仅提供了基于SAN共享的数据存储技术，同时也提供了一个优化、高性能的网络数据存储解决方案给StorNext共享文件系统客户。分布式 LAN 客户端是 StorNext 数据共享解决方案的一个重要补充，它能让需要断续访问或部分访问共享数据储存库的应用程序以更低的成本连接 StorNext 存储。分布式 LAN 客户端还通过改进的弹性、负载均衡和每数据流性能，消除了 NFS 和 CIFS 数据共享的实现

12、中一对多的数据访问限制。如上图所示，基于DLC模式的数据写入可通过多台SAN客户端节点实现，这些SAN客户端节点可称之为Cluster Gateways（网关服务器）。也就是说，在写入过程中如果一个实现数据写入的SAN客户端出现故障，这个写入请求还是可通过其他SAN客户端实现，也就是说从根本上消除了CIFS的单点故障。基于StorNext共享文件系统实现的SAN+NAS存储架构的不是非常简单，可直接将DLC分布式网络客户端模块安装在原有通过CIFS实现网络访问共享文件系统的服务器上，即可实现共享存储系统中数据访问的高性能并提高数据访问的可靠性。如下图所示：当某台DLC客户端服务器（LAN Cl

13、ients）需要访问存储在共享文件系统中的数据时，这台DLC客户端将首先发送该文件的元数据信息（文件存储位置信息）数据请求到元数据服务器，元数据服务器将相关的元数据信息反馈给这台DLC客户端，这台DLC客户端就将这些元数据信息通过以太网络转递给已经获取的可提供共享文件系统存取服务的网关服务器IO节点服务器（SAN客户端，Clustered Gateways），而后由这些IO节点服务器实现数据的存取。多个网关服务器，可同时为所有的网络客户端节点使用，从而可提供高速、并发的数据访问支持。同时，基于DLC访问模式，还可实现网络数据访问链路的冗余（Failover）和负载均衡（Load Balance

14、）。比较DLC分布式网络客户端访问模式与传统的NFS/CIFS服务模式，NFS/CIFS服务模式实现的一对多的连接模式，因此当NFS/CIFS服务器出现故障时，所有通过NFS/CIFS协议访问这台NFS/CIFS服务器的网络节点将不能继续工作；而如果是在网络节点服务器上采用了StorNext的DLC分布式网络客户端（LAN Clients），则可将多台IO节点服务器（SAN客户端服务器）作为可提供网络数据访问服务的服务器集群（Clustered Gateways）。此外基于DLC的数据写入模式，用户还可以根据写入数据类型，对单次输出的数据块长度进行优化，以便在提高数据传输有效性的同时，减少可能

15、产生的碎片度。在此网络存储架构中的IO节点服务器就是SNFS的SAN客户端（Clustered Gateway）。为实现DLC网络共享存储方案，还需根据实际需要增加配置DLC分布式网络客户端模块，所需的模块个数将根据用户现有环境中需要通过SAN客户端基于CIFS实现共享的网络客户端，通常每个需要通过DLC方式访问共享文件系统的需要一个DLC客户端授权。综上所述，基于StorNext的SAN客户端模块和DLC分布式网络客户端模块可实现SAN+NAS的SNFS文件系统共享存储管理，可为SAN+NAS类型的客户应用提供更为高效便捷、可靠安全的数据存储管理服务。2. StorNext共享文件系统常用术

16、语本章将简述基于美国昆腾公司的StorNext数据存储管理软件实现的共享文件系统中常用的术语以及各自的功用，供参考。l SNFS共享文件系统，也常称之为StorNext共享文件系统、SAN共享文件系统等。它是指基于美国昆腾公司的StorNext数据存储管理软件中的StorNext File Systems模块基于SAN存储架构实现的、一个可被多主机共享访问的日志型文件系统。l 元数据服务器（Metadata Server、Metadata Controller），也称之为StorNext元数据服务器、SNFS元数据服务器等。它是指实现SNFS共享文件系统元数据管理服务的服务器。为实现元数据管理

17、的高可用性，通常配置两台，一主一备，以确保文件服务管理的访问可靠性和连续性。l 元数据，在SNFS共享文件系统中是指文件的基本属性信息，即文件的文件名、文件大小、文件属组、文件创建及修改时间、文件存储位置等信息，此类信息在SNFS共享文件系统中是被元数据服务器进行管理的。l 文件的数据体，是指文件存储的具体数据内容。在SNFS文件系统中，文件的数据体是可被所用的SAN客户端服务器直接访问的。l SNFS客户端，包括SNFS SAN客户端和SNFS DLC分布式网络客户端。n SNFS SAN客户端，简称为SAN客户端，SNFS SAN客户端是指通过SAN链路直接访问文件的服务器，亦即安装FC卡

18、通过FC SAN实现共享存储访问的服务器或安装网卡通过IP SAN实现共享存储访问的服务器。n SNFS DLC分布式网络客户端，简称DLC客户端，是指通过网络基于SNFS DLC管理协议实现SNFS共享文件系统中数据文件访问的客户端。l DLC网关服务器（DLC PROXY SERVER或DLC GATEWAY SERVER），也可称之集群网关服务器（Clustered Gateway）。这些客户端服务器就是SNFS的SAN客户端，只是在实现文件系统加载时，添加了一个Mount加载选项“diskproxy=server”（Linux客户端）或指明此服务器为DLC Proxy Server（W

19、indows客户端）。DLC分布式网络客户端就是通过这些服务器实现SNFS共享文件系统中数据存取的。l 元数据传输网络，在用于元数据传输独享时，也称之为私有元数据网络（Private Metadata LAN）。这一网络是指连接元数据服务器、SNFS客户端服务器（SAN客户端、DLC分布式网络客户端）的以太网络，用于实现元数据的在元数据服务器和SAN客户端间的元数据传输的。为确保元数据传输不被干扰，通常建议配置一个专用以太网络用于元数据传输。一个独享的100Mbps的网络就足够与元数据的传输。l DLC数据传输网络，此网络可用于DLC网络客户端与DLC网关服务器间进行数据交换。此网络并不是必须

20、的，如果无法在DLC分布式网络客户端和DLC网关服务器之间构建一个单独网络用于用户数据传输，也可以与与元数据传输网络共享使用，但为确保DLC客户端的数据访问性能，建议是一个共享的Gbits网络。l 数据卷在SNFS共享文件系统中，用于实现元数据、日志数据、用户数据存储的最小物理单元，根据存储数据的不同类型，包括：n 元数据卷，是指用于存储元数据的磁盘卷LUN，通常建议采用RAID1或RAID1+0方式实现磁盘卷的RAID保护。此磁盘卷LUN需要被元数据服务器共享。用于存储SNFS共享文件系统中文件的元数据信息。在存储设备中，应具备最高性能和最高安全性。n 日志数据卷，是指用于存储日志数据的磁盘

21、卷LUN，通常建议采用RAID1或RAID1+0方式实现磁盘卷的RAID保护。此磁盘卷LUN需要被元数据服务器共享。在存储设备中，应具备最高性能和最高安全性。非必须的磁盘卷，如果存储系统不具备创建单独RAID卷组实现日志数据存储，则日志数据和元数据可存储在同一元数据卷内。n 用户数据卷，是指存储用户数据的磁盘卷LUN，可能是多条，通常采用RAID5或RAID6方式实现磁盘卷的RAID保护。构成文件系统的磁盘卷LUN需要被加载此文件系统的所有SAN连接的服务器（SAN客户端，包括元数据服务器）共享。数据卷是用于存储用户数据文件数据体的物理设备。l SNFS磁盘卷标签，或称之为SNFS卷标，在创建

22、文件系统每一个SNFS共享文件使用的磁盘卷上都需要标记一个磁盘卷标签。此磁盘卷标签是用于该卷在SNFS文件系统启动时与此卷在操作系统中的物理设备名对应的，因此SNFS卷标完整性是SNFS文件系统可被正常加载的前提。l 条带化卷组是在SNFS共享文件系统中用于文件存储的最小逻辑单元，以磁盘卷组的形式提供磁盘卷的管理，包括以下几种不同类型的卷组类型：n 元数据条带化卷组，或称之为元数据卷组。在文件系统配置中，用于实现元数据存储的条带化卷组，称之为元数据条带化卷组。n 日志数据条带化卷组，或称之为日志数据卷组。在文件系统配置中，用于实现日志数据存储的条带化卷组，称之为日志数据条带化卷组。此为非必须的

23、磁盘卷组，如果存储系统不具备创建单独RAID卷组实现日志数据存储，则日志数据和元数据可存储在同一元数据卷组内。n 用户数据条带化卷组，也可称之为用户数据卷组或数据卷组。在文件系统配置中，用于实现用户数据文件的数据体数据的数据存储。l 其他常用的用于文件系统配置的参数，包括FsBlockSize、JournalSize、Journalsize、InodeExpanMin、InodeExpanInc、InodeExpanMax、这些参数与应用相关，我们通常不建议在实施过程中修改文件系统的缺省参数（缺省参数可参见/usr/cvfs/examples/example.cfg文件中的有关信息），如需修改

24、请咨询Quantum的专业服务顾问。3. StorNext共享文件系统实施规范本章将简述基于美国昆腾公司的StorNext共享文件系统模块构建的SNFS共享文件系统的实施规范，供参考。一个SNFS共享文件系统的实施可分为以下实施步骤：l SNFS系统实施规划l SNFS系统软件安装l SNFS系统配置3.1 SNFS系统实施规划在进行SNFS系统实施前需要进行充分规划，以避免实施的无序性，避免实施错漏和降低后期系统扩容（特别是SNFS共享文件系统扩容）的难度。规划内容包括：l 系统需要的、拟创建的SNFS文件系统的名称和容量及使用的磁盘卷设备。n 文件系统名称将建议采用更为直观的描述实现，例如

25、如果这个文件系统是存储高清数据的，可使用GAOQING或HD为文件系统的名称。n 文件系统容量定义是规划定义此文件系统需要捆绑多少条物理磁盘卷LUN构建这个文件系统，在这里我们不建议用户使用大容量磁盘卷卷来构建SNFS共享文件系统，特别是在多客户端并发写访问一个共享文件系统时。l 根据应用需求SNFS文件系统的容量进行共享存储系统（使用SAN连接的磁盘阵列设备）的规划，此规划主要是根据存储的最佳实践完成存储设备的Cache、磁盘卷（包括用于元数据、日志数据存储磁盘卷和用于用户数据存储磁盘卷）的规划和创建。这需要咨询所采用存储的厂商专家进行规划设计，以达到最高安全性和最佳性能。以上两步完成后，可

26、以列表的形式表述此规划。例如以下创建了一个名称为HD.cfg的共享文件系统，文件系统的元数据和日志数据存储在同一个元数据条带卷组，共有四个用于用户数据存储的磁盘卷组，每个条带卷组中包含两个磁盘卷：共享文件系统名称SNFS条带卷组SNFS条带卷组名称磁盘卷SNFS标识LUNHD.cfg元数据卷MetaJourFiles01HD_XP_MTJN013HD_XP_MTJN014013014用户数据卷DataFiles001HD_XP_DATA072HD_XP_DATA073072073用户数据卷DataFiles002HD_XP_DATA074HD_XP_DATA075074075用户数据卷Data

27、Files003HD_XP_DATA076HD_XP_DATA077076077用户数据卷DataFiles004HD_XP_DATA078HD_XP_DATA079078079备注：1. 以上系统设计的前提是两条磁盘卷的IO性能可满足用户应用存储带宽的需求，如果带宽不能满足，需要增加条带卷组中磁盘卷的条数。2. 建议磁盘卷的卷标和文件系统名称及磁盘卷的SNFS卷标相关联，以便丢失后易于回写。如上磁盘卷标识：HD_XP_DATA072中1) HD是指文件系统名称2) XP是指存储系统类型3) DATA是指用户数据磁盘卷、MTJN是指用于存储元数据和日志数据的磁盘卷4) 072是指此磁盘卷的LU

28、N号。l 拟访问共享文件系统的各服务器操作系统平台规划。这里涉及以下几点：n 一是指元数据服务器需要满足的最低配置，建议如下：总之，内存越大越好、CPU个数越多越好、磁盘空间越大越好。n 二是指规化SNFS安装的操作系统平台，在广电领域使用的服务器平台多为Windows平台，包括Windows 2003、Windows XP、Vista以及今后可能使用的Windows 7等，SNFS共享文件系统都对这些平台提供支持，但注意请这些平台的操作系统版本及必须的补丁程序的安装和配置，可参见下表。备注：我们建议用户在规划SNFS共享文件系统的元数据服务器平台是使用Linux操作系统而不是Windows操

29、作系统。n 三是规划数据卷大小，特别是元数据卷的大小以及使用的磁盘卷标签类型等。元数据卷大小定义是与存储文件的目录个数及目录下文件个数相关，请参见下表：磁盘卷所使用类型及操作系统平台要求如下（请注意在包含Windows XP的SNFS共享环境中，数据磁盘卷LUN的大小不能超过2TB）：备注：1. Metadata卷大小和设定的FsBlockSize及目录下的文件数量相关。2. 不建议metadata卷小于25GB，metadata卷的大小与文件目录数、文件数及FsBlockSize相关，建议文件系统配置参数FsBlockSize在16K-64K之间，FsBlockSize较大将有助于提高文件系

30、统启动及在主备系统间实现切换的速度。3. 在一个文件系统中，同一个StripeGroup中的Data磁盘LUN的大小需是一致的。建议用于存储数据的Data LUN为二或四的倍数，在一个文件系统中多StripeGroup模式将有助于提高文件系统的可靠性并减少磁盘碎片。4. 所有的Metadata磁盘和Journal磁盘，必须保证是整个存储中性能最优、安全性最好的磁盘，建议使用Raid10实现Metadata数据和Journal数据的存储保护。建议采用Raid 5实现Data磁盘的保护。其实这部分工作在系统设计阶段（售前）应该已经完成，但在实施阶段的规划将是将售前的系统规划进行定量化，为后续系统的

31、部署实施做好准备。以下为SNFS共享文件系统中可配置的条带化卷组、磁盘卷的最大值供参考：l 一个SNFS文件系统最多的卷组为256个。l 一个条带化卷组中最多的磁盘个数为128个。l 一个文件系统中最多的磁盘个数为512个。3.2 SNFS系统软件安装SNFS的软件安装非常简单，请参照SNFS的有关安装指南进行软件安装。需要关注的就是：请在操作系统平台完成安装配置后再安装SNFS共享文件系统管理软件；而不建议使用全盘“克隆”方式。3.3 SNFS系统软件配置SNFS的软件配置是整个SNFS系统实施过程中最为简单的，特别是在Windows平台的配置更是如此。唯一需要注意的主要有以下两点：l 一是

32、在完成标记磁盘卷的SNFS标签后，必须将磁盘卷SNFS标签状态记录到一个文件以便后续磁盘卷标签丢失后使用：n 在Linux元数据服务器平台可使用如下命令参见：#“/usr/cvfs/bin/cvlabel c > cvlabel.hostname_date +%F”n 在Windows元数据服务器平台可使用如下命令才：C:Program FilesStorNextbincvlabel c > cvlabel.outl 一是在客户端配置并加载文件系统后需要修改回收站属性，对于加载文件系统的盘符禁用回收站功能，即“删除文件直接删除而不移入回收站”。如下为一个英文操作系统平台的配置实例，

33、请参考：4. StorNext共享文件系统运行维护本章将简述基于美国昆腾公司的StorNext数据存储管理软件构建的SNFS共享文件系统的日常维护、故障处理及主要维护命令，请参考。4.1 SNFS共享文件系统日常维护对与SNFS共享文件系统的日常维护，最为重要的有以下几点：1. 查看主备元数据服务上加载的文件系统是否正常：1) 可使用cvadmin命令进行查看，如下图：上图表示当期的主元数据服务器的IP地址为6，备元数据服务器的IP地址为5；总共有三个SNFS文件系统music、video、sharefs。2) 维护时间：在客户日常有重要任务启动前。

34、3) 维护频度：一日一次。2. 查看主备元数据服务器中内存使用状况是否正常，我们不建议当已近使用SWAP空间时，还使用此服务器作为主元数据服务器，如果为主备高可用管理模式，且业务允许，可考虑将文件系统切换到备元数据服务器，重新启动主元数据服务器。以Linux平台为元数据服务器为例进行表述：1) 如下为当前主元数据服务器top命令的输出状态：如下为当前备元数据服务器top命令的输出状态：如生产允许，可重新启动当前的主元数据服务器，以便释放系统中占用的内存资源。2) 维护时间：每日最繁忙（最重要）任务启动前。3) 维护频度：随时监控3. 查看主元数据服务器中文件系统的元数据读写访问是否存在瓶颈，或

35、出现跳变。可通过如下命令遍历该文件系统的cvlog日志进行观测，通常建议将这些信息保留下来，以便跟踪日志中元数据卷的存储状态变化情况，及时掌握系统阶段运行情况（还是以Linux平台为例，查看文件系统video的工作状态）：1) 使用命令“grep "PIO HiPriWr" /usr/cvfs/data/video/log/cvlog | more”进行查看，如下：2) 维护时间：根据运维时间确定。3) 维护频度：每周一次或根据运维需求。4. 查看所有的数据卷标签是否正常。1) 使用命令（假定此前在系统完成配置后生成的文件是cvlabel.out）：# /usr/cvfs/

36、bin/cvlabel c > cvlabel.tmp# diff cvlabel.tmp cvlabel.out2) 维护时间：在存储系统有任何改动操作前后或需要增添新的服务器前后。3) 维护频度：按需操作。5. 监控是否在ras中有任何异常信息：1) 维护命令：“tail f /usr/cvfs/ras/raslog”2) 维护频度：有任何文件系统故障时。4.2 SNFS共享文件系统故障处理4.2.1 SNFS共享文件系统常见故障通常SNFS文件系统故障主要包含以下几类：l SNFS客户端无法实现文件系统中数据存取n 所有客户端都无法存取某一文件系统数据，可能原因是元数据服务器（或F

37、SNAMESERVER）通信故障或共享存储设备故障（全部或部分数据LUN无法访问）导致这些客户端故障。n 仅部分客户端无法存取文件系统数据，可能原因是这些客户端与元数据服务器（或FSNAMESERVER）通信故障或与此文件系统相关的数据LUN无法访问而致。l 元数据服务器中通过cvadmin命令发现某个文件系统未被加载。可能原因有两个n 一是与此文件系统相关的磁盘卷出现丢失，需检查是否为硬件故障或磁盘上的SNFS标签丢失所致。n 二是此元数据服务器出现故障，需要重新启动。l SNFS客户端访问某一文件系统中数据时，性能低。可能原因在于：n 元数据服务器加载文件过多或内存资源损耗过大导致服务器出

38、现性能瓶颈。n 元数据卷的存储存在性能瓶颈，可检查cvlog中的“PIO HiPriWr”中的sysavg数值与此前记录数据进行比对分析。n SNFS客户端到元数据服务器（或FSNAMESERVER）的通信链路存在问题，可登录运行cvadmin命令，而后使用latency-test进行检查，以上输出信息可和此前系统完成安装后取得的latency-test数据结果进行比对。4.2.2 SNFS共享文件系统故障检查及处理步骤在发现与SNFS共享文件系统相关的故障后的处理过程如下：l 第一，检查Metadata LAN的通信是否正确。l 第二，检查出现故障的文件系统的磁盘LUN的识别是否有问题。l

39、第三，检查MDC服务器及SNFS客户端上的SNFS服务进程是否启动正确。检查方法如下：1. 检查Metadata LAN可使用ping命令进行，即在故障客户端或MDC服务器上使用ping命令检查网络状态。2. 使用cvlabel l 命令检查所有的磁盘LUN及的磁盘LUN的SNFS标签LABEL是正确的。3. 如果某台SNFS客户端不能访问此前加载的所有SNFS文件系统，则也可能是这台客户端SNFS进程存在问题，重新启动SNFS服务进程或重新启动系统以便排除。经过以上处理方法如果还没有解决问题则需要采集日志信息，开一个SR，交由美国昆腾公司的售后专家负责处理，其所需信息及处理流程如下。4.2.

40、3 SNFS共享文件系统故障售后处理步骤在需要获取美国昆腾公司的售后服务支持时，请确定该系统是在昆腾公司的保修服务期内。如果已经出了服务保修期限，需在购买服务后，才能享受昆腾提供的技术支持服务，有关服务的购买请与销售人员联系。用户可通过昆腾提供的网上服务支持系统OSR或使用电话拨打我公司提供的免费服务电话108007121495（使用网通线路的客户）或108001201495（使用电信线路的客户）直接联系美国昆腾国际公司的亚太呼叫中心的技术人员进行报修服务：1. 在进行故障报告前，须准备如下信息（相关客户安装地点等信息应该与原注册信息一致）：l 序列号，此序列号为在申请软件永久授权时的产品序列

41、号。l 故障处理联系人、电话及邮件地址。l 所使用产品型号、基本配置等信息，包括元数据服务器类型、HA架构、客户端类型、数量，以及元数据服务器的cvfsid。l 故障描述及已完成处理过程，并进行SNFS共享文件系统日志信息采集：n 在Windows元数据服务器上，通过cvgather命令采集故障及系统运行的相关信息。C:Program FilesStorNextbin>cvgather -f 文件系统名请注意在运行以上命令后，会在当前目录下生成一个：文件系统名.out的文件，此文件即为采集的日志信息。n 在Linux或Unix元数据服务器上，通过cvgather命令采集故障及系统运行的相

42、关信息。# /usr/cvfs/bin/cvgather -f 文件系统名请注意在运行以上命令后，会在当前目录下生成一个：Linux_主机名_文件系统名.tgz的文件，此文件即为采集的日志信息。n 对于HA系统，需采集两台元数据服务器的信息。2. 将采集的日志信息，根据此后与维护人员联系的昆腾技术专家的要求发送到指定位置，并根据昆腾技术专家要求进行故障处理。3. 在完成故障处理后，关闭SR。此外用户也可通过OSR方式获取服务帮助。有关通过OSR方式申请SR可直接获得昆腾技术支持（需要具备internet连接。此方式为首选方式，在开SR时可直接提供相关信息，以便更快得到服务支持，请正确填写所有必

43、填信息，以避免任何错误导致的服务延误），可参见附件3。4.3 SNFS共享文件系统启动和停止为确保存储在SNFS共享文件系统中数据的安全可靠性，用户的系统管理员才能实施涉及SNFS共享文件系统的运行管理操作，通常执行SNFS共享文件系统启动和停止操作的目的主要有系统维护或故障处置。l 如需关闭任何SNFS客户端，可直接关闭服务器或给该服务器断电。l 如果元数据服务器断电或关闭，则整个文件系统就不能被访问。l 对于SNFS共享文件系统的正常应用来讲，在启动任何SNFS客户端实现文件系统加载前，必须确定至少有一台元数据服务器已经启动，并实现了该客户端拟加载文件系统的启动和激活。l 在客户端SNFS

44、服务出现故障时也需要考虑重新启动SNFS服务进程。如下为Linux元数据服务器重新启动SNFS服务进程的示例：rootdqhmd02 #rootdqhmd02 # /etc/init.d/cvfsUSAGE: /etc/init.d/cvfs start | stop | restart | fullstoprootdqhmd02 #以下为重新停止和启动服务进程的例子，供参考：rootdqhmd02 # /etc/init.d/cvfs fullstopInitiating stop of ADIC PSE componentInitiating fullstop of ADIC DSM co

45、mponentUnmounting SNFS filesystemsStopping SNFS DaemonsStopping SNFS PortMapperWaiting for FSMs to finish.SNFS Stop OK Unloading SNFS module 'cvfs'.SNFS Unload OK rootdqhmd02 #rootdqhmd02 #rootdqhmd02 # /etc/init.d/cvfs startInitiating start of ADIC DSM componentInitializing StorNext Filesys

46、tem (SNFS)Loading SNFS modulesnet.core.rmem_max = 1048576Starting /usr/cvfs/bin/.core.rmem_max = 131071Starting /usr/cvfs/bin/cvfsd.Mounting SNFS filesystemsSNFS Initialized OK rootdqhmd02 #在Windows平台停止或启动SNFS服务进程可通过如下步骤进行：停止：Start à All Program à StorNext File System à Stop

47、File System Services启动：Start à All Program à StorNext File System à Start File System Services4.4 SNFS共享文件系统日常维护常用命令以下简述几个SNFS共享文件系统日常维护中经常使用的命令，供参考：cvadmin用于SNFS共享文件系统的日常维护管理可以以交互方式或直接命令行方式提供。语法：cvadmin -H FSMHostName -F FileSystemName -f filename -e command1 -e command2 常用交互命令：start

48、 FileSystemName# 启动指定文件系统activateFileSystemName# 激活指定文件系统stopFileSystemName# 停止指定文件系统selectFileSystemName# 选定一个文件系统stat# 显示当期文件系统状态show long# 显示文件系统配置情况who# 查看选定文件系统的客户端连接情况disks# 显示所有SNFS可用的磁盘LUN信息paths# 显示磁盘卷可用的链路。failSNFS文件系统# 完成指定文件系统的切换latency-test# 测试FSM到客户端的网络等待时间quit# 退出cvlabel用于磁盘卷的SNFS磁盘标签

49、的管理常用语法：cvlabel l 或 cvlabel c 或 cvlabel cvlabel.out其主要用户可参见附件1l 以短格式输出此服务器可识别磁盘卷信息，包括磁盘卷设备名、大小、SNFS标签名称等，命令格式：cvlabel -ll 输出此服务器可识别磁盘卷信息，包括磁盘卷设备名、大小、SNFS标签名称、磁盘的LUN信息等，命令格式：cvlabel c l 写磁盘卷标签，首先使用“cvlabel c > cvlabel.out”命令生成一个文件，编辑这个文件，给每个共享文件系统所需的LUN添加一个SNFS标签，而后再使用命令“cvlabel cvlabel.out”将此SNFS

50、标签写到LUN上。cvfsck用于SNFS共享文件系统检测的命令。常用命令用法可参见附件2中描述。cvfsid此命令用于获得SNFS授权使用的主机ID信息。cvversion此命令用于获得当前安装的StorNext版本。cvcpSNFS系统提供的多线程快速拷贝命令，与cp的用法类似。snfsdefrag用于磁盘碎片检测和文件的磁盘碎片整理。常用命令格式：snfsdefrag c 文件名# 输出文件的碎片个数snfsdefrag e 文件名# 输出文件的碎片大小snfsdefrag 文件名# 实现指定文件的碎片整理附件1 SNFS标签丢失及修复近期遇到SNFS系统中所使用的SNFS磁盘卷标签丢失

51、故障。本文就是对这一现象的成因进行分析，并对处理方法进行了描述，请参照执行。磁盘卷SNFS LABEL丢失成因分析：SNFS标签占据了磁盘自0字节到1M字节的位置。也就是说，如果有其他程序修改或覆盖了这个区域中的数据，就会造成SNFS磁盘卷标签丢失。在SNFS系统中，只有通过GUI界面或一个命令行程序修改磁盘卷的SNFS标签：GUI界面是以交互方式提供标签修改操作的，命令行程序是“cvlabel”，其他应用程序只会发生读取磁盘卷SNFS标签的操作。常见的发生磁盘卷SNFS标签丢失现象多与Windows操作系统的工作环境相关。如果一台未安装SNFS客户端软件的Windows操作系统在接入SAN环

52、境时，当Windows服务器发现系统中的磁盘卷不是使用NTFS标记过的，则Windows操作系统将要求对此磁盘卷进行标记，如果应答了“Yes/确认”，则此磁盘卷就会被Windows操作系统使用NTFS格式进行标记。此标记过程将会造成已经写了SNFS标签的磁盘卷上的SNFS标签被覆盖。确保磁盘卷SNFS LABEL安全的手段：在Windows操作系统启动或操作过程中，如果出现需要对磁盘进行格式化的界面时，请务必小心点按“Yes/确定”键，必须确定此磁盘卷是否为SNFS使用的磁盘卷，如果是SNFS使用并标记过的，则必须点按“No/取消”键。还有一个简单的处理方法是：在安装配置Windows操作系统

53、，先将光纤线拔掉，而后再进行操作系统或其他软件的安装。只有在完成了SNFS软件安装后，再连接光纤线，进行后续与SNFS系统配置相关的操作。磁盘卷SNFS LABEL丢失后的处理手段：磁盘卷的SNFS LABEL丢失后，一般不会造成任何数据损失。通常的磁盘卷SNFS LABEL丢失有两种情况：n 情况一：数据卷的SNFS LABEL丢失：l SNFS LABEL标签的丢失将不影响正在进行数据存取的SAN客户端操作，而且数据读写都是正确的。但如果此SAN客户端进行重新启动，则SNFS文件系统就不能正常加载了。n 情况二：元数据卷/日志数据卷的SNFS LABEL丢失：l 由于元数据服务器不能识别到

54、元数据卷了，因此此卷相关的文件系统将不能正常访问，并导致所有的SAN客户端都不能访问这个文件系统上的数据了。这两种情况，只要不破坏磁盘卷上的数据体，即未覆盖或修改了磁盘卷由开始位置1M字节以后的数据，而后只需将磁盘卷标签SNFS LABEL重新写回原来的位置，SNFS系统将依旧可正常运行。但请注意如果将标签的位置写错了，整个SNFS文件系统的完整性就被破坏了，以下是几中可能的情况：n 写错了元数据或日志卷标签：整个文件都将不可用。如果进行了cvfsck，理论上是无法进行系统恢复的了。n 写错了数据卷标签：文件系统将是可用的。但是如果写入了数据，则问题非常严重的数据，会出现损失现象。l 例如，如

55、果有两个数据卷，他们的SNFS LABEL是data_001和data_002，如果将这两个卷标签写错了，同时又有数据写入，则就会破坏已经写入磁盘卷上的数据。防患于未然的SNFS标签保护：在完成SNFS软件安装及系统配置后，有一个非常重要的工作需要完成，必须采用如下命令“cvlabel -c” 输出磁盘卷的信息到一个文件，假定文件名称为“cvlabel-c.out”。在此文件中，如下行所示：data002 /dev/sdle 4292737024 VTOC # host 6 lun 1 sectors 4292737024 sector_size 512 inquiry HP HSV210 6

56、220 serial 600508B4000AF0F50002800002330000n 第一列是磁盘卷的SNFS标签：data002n 第二列是磁盘卷在系统中的设备名（启动时或存储系统修改配置后，可能会改变）：/dev/sdlen 第三列是磁盘卷的容量：4292737024个块（512字节/块）n 第九列是磁盘卷的LUN号（永远不会改变，除非修改了存储系统中该卷的配置）：1n 第十九列式磁盘卷在存储系统中的标识：600508B4000AF0F50002800002330000如果在完成系统设计后记录了以上信息，那么当SNFS标签丢失后，维护人员即可根据这个文件中每条LUN的记录，根据LUN号

57、填入正确的SNFS标签，而后通过cvlabel命令写回去就好了。附件昆腾SNFS售后专家对有关SNFS LABEL丢失现象进行测试后的回复1. Is StorNext software caused the SNFS label lost?Stornext will not overwrite the label without user intervention via GUI (need to unmount & stop the FS before you can relabel the LUN) or via command “cvlabel”Anyway, if the LUNs being used by SNFS are able to detect and access by other system or application, then it is possible the SNFS label get overwritten by other systems.Example: These LUNs no longer have valid SNFS l