«EMC® VNX™ Series Release 7.0 Managing Volumes and File Systems on VNX™ Manually P/N 300-011-808 REV A01 EMC Corporation Corporate Headquarters: ...»
The fsck utility should not be run on a server under heavy load to prevent the server from running out of resources. In most cases, the user is notified when sufficient memory is
unavailable to run fsck. In these cases, users can choose one of these options:
◆ Start fsck during off-peak hours.
◆ Restart the server and start fsck immediately.
◆ Run fsck on a different server if the file system is unmounted.
The fsck utility cannot run on a read-only file system. You do not need to run fsck for normal restart or shutdown operations. File system consistency is maintained through a logging mechanism and restart and shutdown operations cause no corruption.
The first step in the fsck process is to ensure that the corruption can be safely corrected without bringing down the server. The fsck process also corrects any inconsistencies in the Access Control List (ACL) database. The corrupted file system is unavailable to users during the fsck process. After the fsck utility finds and corrects the corruption, users regain access to the file system. While fsck is running, other file systems mounted on the same server are not affected and are available to users.
Volumes A volume is a virtual disk into which a file system places data. Volumes underlie the file system. Create volumes and metavolumes to assign storage space for a file system.
The VNX system supports the volume types listed in Table 3 on page 20. Each volume type provides different benefits to satisfy storage requirements. With the exception of system volumes, all volumes are initially available for data storage.
Volume configuration guidelines on page 29 provides additional information on common volume configurations and considerations associated with each volume type.
Disk volumes A disk volume is a physical storage unit that is exported from the storage system to the VNX for file. Disk volumes are the underlying storage of all other volume types.
A disk volume equates to a LUN as presented to the VNX for file by the storage system.
Each LUN is a usable storage-system volume that appears as a disk volume to the VNX system. Disk volumes are typically created by EMC support personnel during the initial installation and setup of the VNX system. After the initial installation and setup, configure disk volumes only when you add LUNs to the storage system.
Slice volumes A slice volume is a logical, nonoverlapping section cut from another volume component.
When you create a slice volume, you can indicate an offset. The offset is the distance in megabytes between the disk and the start of a slice volume. If an offset is not specified, the system places the slice in the first-fit algorithm (default), that is, the next available volume space. An offset is rarely specified.
You must first identify the volume from which the slice volume will be created. The root slice volumes that are created during installation appear when you list the volume configurations. However, to protect the system, you do not have access privileges to them, and therefore, cannot execute any commands against them.
Slice volumes can be configured to any size, but are typically used to create smaller, more manageable units of storage. The definition of a "more manageable" logical volume size depends on the system configuration and the type of data you are storing. Slicing is more common with EMC VNX for block storage systems because of the larger LUNs presented to the VNX for file.
Figure 1 on page 21 shows an 18 GB volume on which a 2 GB slice is defined.
2 GB 5 GB slice 18 GB 7 GB volume basic volume
Figure 1. Slice volumes A disk volume, stripe volume, or metavolume used as part of a business continuance volume (BCV) should not be sliced.
BCV on page 25 provides information on using BCVs.
You must configure slice volumes as part of a metavolume to store file system data on them.
Metavolumes on page 23 provides additional information.
Stripe volumes A stripe volume is a logical arrangement of participating disk volumes, slice volumes, or metavolumes organized, as equally as possible, into a set of interlaced stripes. Stripe volumes achieve greater performance and higher aggregate throughput because all participating volumes can be active concurrently.
Figure 2 on page 22 shows an example of a stripe volume. The stripe is created across four participating volumes of equal size.
Stripe volumes improve performance because, unlike disk volumes, slice volumes, and metavolumes, addressing within a stripe volume is conducted in an interlaced fashion across volumes, rather than sequentially.
In a stripe volume, a read request is spread across all component volumes concurrently.
Figure 3 on page 22 shows addressing within a stripe volume.
Data is interlaced within the stripe volume starting with stripe unit 0 on the first participating volume, continuing to stripe unit 1 on the next participating volume, and so on. As necessary, data wraps back to the first participating volume. This is controlled by stripe depth, which is the amount of data written to a participating stripe volume member before moving on to the next participating member. Stripe volume configuration considerations on page 30 provides guidelines to configure a stripe volume.
22 Managing Volumes and File Systems on VNX Manually 7.0 Concepts Metavolumes File systems can only be created and stored on metavolumes. A metavolume is an end-to-end concatenation of one or more disk volumes, slice volumes, stripe volumes, or metavolumes.
A metavolume is required to create a file system because metavolumes provide the expandable storage capacity needed to dynamically expand file systems. A metavolume also provides a way to form a logical volume larger than a single disk.
EMC recommends using only one type of volume within a metavolume. For example, you can create and combine stripe volumes, define them as a metavolume, and then create a file system with space from that metavolume.
Configuring a metavolume Metavolumes can be created from a disk volume, stripe volume, slice volume, or another metavolume. A file system is created on the metavolume.
You can expand a metavolume by adding additional disk volumes, stripe volumes, slice volumes, or metavolumes to it.
When you extend a file system that is on a metavolume, the metavolume is automatically extended. Figure 4 on page 23 shows a metavolume configuration that uses three disk volumes.
Addressing within a metavolume All information stored within a metavolume is arranged in addressable logical blocks and is organized in a sequential, end-to-end fashion. Figure 5 on page 24 shows metavolume addressing.
Figure 5. Metavolume addressing Metavolumes can be created by using slice and stripe volumes.
You can create a 12 GB metavolume on four disk volumes by creating 3 GB slices on each disk. You can then create your file system on the metavolume as shown in Figure 6 on page 24.
Create striped volumes over a specified number of disk volumes by defining a 32 KB stripe depth. Put these striped volumes together to create a striped metavolume. You can then create a file system on the metavolume as shown in Figure 7 on page 25.
Figure 7. Metavolume created from stripe volumes Note: The total capacity of a metavolume equals the sum of all volumes that compose the metavolume.
BCV BCVs are dedicated volumes that can be attached to a standard volume on which a file system resides. The TimeFinder/FS feature of the VNX system uses BCVs to create file system copies and mirror file systems dynamically. The EMC Customer Support Representative creates BCVs on the storage system before installing the VNX software.
Note: BCVs are supported only for Symmetrix storage systems.
When planning for BCVs, ensure that you have as many BCVs as standard disk volumes to be used by the largest file system. Figure 8 on page 25 shows the relationship between standard volumes and BCVs.
Note: In Figure 8 on page 25, size refers to a disk volume's geometry.
BCVs are based on the LUNs (entire disk volumes) that are presented to the VNX system.
BCVs should not use slice volumes because TimeFinder/FS operations are run against the entire disk volume. Disk volumes, stripe volumes, and metavolumes used in BCVs should not be sliced.
The TimeFinder/FS feature uses BCVs to create file system copies and mirror file systems
◆ With the file system copy function, you can create an exact copy of a file system to use as input to a backup or restore operation, for application development, or for testing.
◆ With the mirror function, you can create a file system copy in which all changes to the original file system are reflected in the mirrored file system.
After a BCV is created, use the fs_timefinder command to create a file system copy.
CAUTION: Do not attempt to use Symmetrix TimeFinder tools and utilities with file system copies created by VNX TimeFinder/FS. It might result in loss of data.
This section provides information that is helpful to plan file systems for the VNX system:
◆ Supported file system access protocols on page 27 ◆ File system size guidelines on page 28 ◆ NMFS on page 28 ◆ Volume configuration guidelines on page 29 ◆ Stripe volume configuration considerations on page 30 ◆ Integration considerations on page 30 Supported file system access protocols The VNX system supports access to file systems by using NFS, CIFS, FTP, TFTP, and MPFS protocols. Because the protocols used in your environment affect how users access file systems, it is important that you understand the types of users in your environment. The underlying volume structure for your file systems should support the protocols you use and allow users to access file systems in the normal manner.
The following documents contain more information on setting up and managing access to
a file system by using a particular protocol:
◆ Configuring NFS on VNX ◆ Configuring and Managing CIFS on VNX ◆ Managing a Multiprotocol Environment on VNX The VNX system lets you map Windows users and groups to UNIX user IDs (UIDs) and group IDs (GIDs) to provide users with seamless access to shared file system data.
Configuring VNX User Mapping provides additional information.
◆ Using FTP and TFTP on VNX FTP is a client/server protocol that operates over TCP/IP and allows file uploading and downloading across heterogeneous systems. FTP includes functions to log in to the remote system, list directories, and copy files.
A Trivial File Transfer Protocol (TFTP) is a simple, UDP-based protocol to read and write files. TFTP can be used to boot remote clients from a network server. TFTP does not authenticate users or provide access control.
◆ Using VNX Multi-Path File System A multi-path file system (MPFS) adds a thin, lightweight protocol known as the File Mapping Protocol (FMP) that works with VNX protocols such as NFS and CIFS to control metadata operations. FMP exchanges file layout information and manages sharing
conflicts between clients and VNX systems. The clients use the file layout information to read and write file data directly from and to the storage system.
File system size guidelines The size of file systems depends on a variety of factors within a business organization. Follow
these general guidelines when you create file systems in your environment:
◆ Consider the size of the PFS and plan the backup and restore strategy. Larger file systems might take more time to back up and restore. If a file system becomes inconsistent, larger file systems might take longer to run a consistency check.
◆ Consider the rate at which the data grows and plan to increase the space as the data increases.
◆ On each Data Mover, the total size of all file systems, the size of all SavVols used by SnapSure, and the size of all SavVols used by the EMC VNX Replicator feature must be less than the total supported capacity of the Data Mover.
The EMC E-Lab™ Interoperability Navigator available on the EMC Online Support website contains more information on file system size guidelines.
NMFS An NMFS allows you to manage a collection of component file systems as a single file system.
CIFS and NFS clients see component file systems as a single share or single export.
File system capacity is managed independently for each component file system. This means that you can increase the total capacity of the NMFS by extending an existing component file system or by adding new component file systems.
The number of NMFS or component file systems is limited only to the number of file systems allowed on a Data Mover. Hard links (NFS), renames, and simple moves are not possible from one component file system to another.
The VNX features that support NMFS are:
◆ SnapSure ◆ VNX Replicator ◆ Quotas ◆ Security policies ◆ Backup EMC Symmetrix Remote Data Facility (SRDF®) ◆
◆ File system migration ◆ FileMover EMC MirrorView™/Synchronous ◆ Volume configuration guidelines Volume configuration guidelines are helpful to plan the storage structure of file systems.
Table 4 on page 29 lists common volume configurations and considerations associated with each volume type.
Table 4. Volume configuration guidelines
Stripe volume configuration considerations
The following are guidelines to configure a stripe volume:
◆ The use of different stripe sizes depends on the applications you are using. The stripe depth must be specified in multiples of 8,192 bytes. EMC recommends a stripe size of 32,768 bytes (default) for file systems that run in a CIFS or NFS environment with a Symmetrix or VNX for block storage system. A 256 KB stripe size is recommended for MPFSi and MPFS environments, while RAID 3 and 64 KB stripe size are recommended for ATA-based file systems. For EMC FLARE® 24 and later, RAID 5 is recommended for ATA-based file systems with 64 KB stripe size.
◆ Consider the size of the stripe volume. After the stripe volume is created, its size remains fixed. However, you can extend a file system built on top of a stripe volume by combining or concatenating it with additional stripe volumes.
◆ For optimal performance, stripe across different volumes. While striping across a single volume is possible, it does not improve performance.
◆ Configure stripes as follows to use the maximum amount of disk space:
• The size of the participating volumes within the stripe should be uniform and evenly divisible by the size of the stripe.
• Each participating volume should contain the same number of stripes.
• Space is wasted if the volumes are evenly divisible by the stripe size but are unequal in capacity. The residual space is not included in the configuration and is unavailable for data storage.
◆ If eight or more volumes are available, building stripe volumes on multiples of eight volumes should give reasonable performance in most environments. If eight volumes do not provide sufficient file system capacity, combine as many sets of eight volumes as necessary into a single metavolume.