Assignments

File System Types

Disk File Systems Flash File Systems Database File Systems Transactional File Systems Network File System Special Purpose File System Operating systems Linux UNIX Solaris Mac OS X Microsoft Windows HP-UX IBM-AIX VMware

File System
ext2, ext3, ext4, XFS, JFS, ReiserFS and btrfs UFS UFS,ZFS HFS Plus
FAT, NTFS, exFAT and ReFS

VxFS JFS VMFS

Block Protocols
Advanced Technology Attachment (ATA) Small Computer System Interface (SCSI) Single-Byte Command Code Set (SBCCS)

File Protocols
Network File System (NFS) Common Interface File System (CIFS) File Transfer Protocol (FTP) Hyper Text Transfer Protocol (HTTP)

Clariion Architecture

CX200, CX300, CX3-10 has one bus/loop CX400, CX500, CX600 has two bus/loops CX700, CX3-20, CX3-40, CX3-80 has 4 bus/loops. More bus / loops can anticipate more throughputs. T h e C l a r i i o n CX700s and the new CX3s & CX4s have more buses than the traditionalCX200, CX300, CX400 and CX500.All data from host goes to cache and is queued to be written on disk through this backend bus / loops. The speed of backend bus / loop on a CX series of machine is 2 GB, with CX3s it jumps up to 4 GB and with CX4s to 8GB per second. Also the bus/loop initiates at the SP level and goes up to the DAEs which have LCC (Link Control Cards). Each LCC i s where the bus / loop from the p r e v i o u s D A E / S P comes in and further daisy chains to the one above it, creating a true chained e n v i r o n m e n t a n d p r o t e c t i n g f r o m s i n g l e p o i n t s o f failure. All LCCs are connected (loop) using HSSDC (cables). These HSSDC cables and LCC cards are hot swappable which will not cause an outage on the machine. There are Power Supplies on each SPE, DAE, DPE allowing hot r e p l a c e m e n t s o n t h o s e while the machine is functional.

VNX Architecture

The EMC VNX series unified storage system models consists of VNX5300 mid-range/entry, VNX5500 mid-range, VNX5700 high-end/medium-capacity and VNX7500 high-end/large-capacity. They are unified storage platforms which combine Block array and the File serving components into a single unified Block and File, File only, or Block only storage solution. The VNX series storage systems uses famous Intel multi-core CPUs and PCI Express 2.0 interconnects to deliver uncompromising scalability and flexibility. Entry level VNX5100 which is only available in a Block only configuration (it's not too unified as it can't handle File storage and iSCSI) The VNX series implement a modular architecture concurrently supporting native NAS, iSCSI, FC and FCoE protocols for host connectivity and 6 GB SAS backend topology. The VNX5700 and VNX7500 utilize Storage Processor Enclosure (SPE) architecture and the mid-range models utilize Disk Processor Enclosure (DPE) architecture. A High End VNX can scale up to 60 CPU cores, there are 12 CPU cores dedicated to high performance Block serving using six core CPUs on two SP's. There can be up to 48 CPU cores dedicated to networked File system management and data sharing via six core CPUs on eight X-Blades. Block connectivity is via FC, FCoE, and iSCSI, and File is via NAS including NFS, CIFS, MPFS, pNFS. Like a CLARiiON each SP has an associated Management Module which provides the SP management connections via one Ethernet (RJ-45) port, another port is a service port for laptop connection. Management module also includes 2 RS-232 ports, one for service laptop connection and second one is for SPS connectivity. The VNX series includes SAS I/O module in slot 0 for connectivity to DAEs. Each port on this module represents a backend bus. The number of ports depends on system model. An 8 Gb FC I/O Module, located in slot 4 (VNX7500 and VNX5700), provide connectivity to the X-Blades (NAS head). They are factory installed in unified and file only systems. The rest of the I/O slots are used for block server access with a maximum number of configurable slots of three per SP on the VNX5700 and four per SP on the VNX7500. Note that the I/O modules must be symmetrical between SPs. The VNX series offers Block connectivity via 4 Frontend I/O Module options:

Two port 10GbE FCoE i/O module (SFP) Four port 1Gb BaseT iSCSI I/O module (RJ45) Two port 10 GbE iSCSI I/O module (SFP or Twinax Copper) Four port 2/4/8 Gb FC module (SFP)

The default mode for Block connectivity is ALUA (active/active), the path to the SP that owns the LUN is marked as Optimized and the other is marked as Non-Optimized. I/Os can be redirected to the nonowning SP via the CMI (inter SP link) as needed without requiring a LUN trespass. VNX DPE components include redundant SPs, two Power Supply/Cooling Modules, and the first set of drives for the VNX5500, VNX5300, and VNX5100 storage systems. The VNX DPE has the same management and service connections as the SPE based models. There are two RS-232 DB-9 serial ports, a Power LED and Fault LED, and two RJ-45 ports. The VNX series comes with 2 DAE options: a 2U DAE may contain up to 25 2.5 inch, 6Gbit SAS drives and a 3U DAE may contain up to 15 3.5 inch, 6Gb SAS drives. Both types of DAEs may be installed in the same array. Each DAE can contain a mixture of all drive types (Flash, SAS, and NL SAS). The DAEs are connected via a 4 lane, 6 GB/s per lane connection which results in a 24 GB/s SAS connection. The SAS lanes are similar to the lanes in a PCI bus.

The DAE includes the 15 disk drives, two Link Control Cards (LCC A and LCC B), and two Power Supply/Cooling Modules (PS A and PS B). The LCCs and Power Supplies are locked into place using captive screws to ensure proper connection to the midplane. The VNX series Data Mover Enclosure can contain one or two X-Blades. The X-Blades provide File connectivity via DART Operating System. The different VNX series models use the same DMEs and vary only in the maximum number of X-Blades, the maximum number of I/O Modules per X- Blade, and the X-Blade CPU speed and memory specifications. X-Blades include a four port 8 GB Fibre Channel I/O Module in slot 0. Two ports are for connectivity to the Storage Processors and two are for connectivity to a backup tape device. The rest of the I/O slots are used for File connectivity and there must be at least one network I/O Module in each X-Blade. The VNX series storage systems support X-Blade failover. By default, an X-Blade failover group includes one primary X-Blade and one standby X-Blade. The primary and standby X-Blades within a group must have identical I/O Module configurations. To act as a standby server, an X-Blade must first be configured as a standby for one or more primary X-Blades.

CX and VNX Best Practices

CX Best Practices
1. Host Best Practices a. Performance: Sequential, Random I/O I/O size I/O threading model b. Volume Managers Dedicated RAID groups Multisystem Cross c. HBAs d. File systems 2. Availability a. PowerPath b. ALUA c. Multipath I/O applications 3. Network Best Practices a. Performance iSCSI LAN b. Availability FC SAN iSCSI LAN 4. Storage System Best Practices a. Performance

Storage processor Vault drives RAID groups LUN provisioning Storage devices

VNX Best Practices

1. Host Best Practices a. Performance Application tuning Different I/O types Application buffering, and concurrency Host HBAs b. Availability PowerPath Other multipath I/O services (MPIO) Storage network attachment 2. Network Best Practices a. Performance iSCSI Data Mover networking b. Availability Fibre Channel FCoE protocol iSCSI protocol 3. Block Storage System Best Practices a. Performance RAID groups RAID group creation LUNs Pool capacity estimate b. Availability RAID groups Basic LUN availability Pool availability 4. Storage System Platform Best Practices a. Performance Front-end ports Storage processors Mirrored cache Back-end FAST Cache Physical Storage

CX and VNX Storage Provisioning

CX Storage Provisioning

Zone the Server to the CX Go to the connectivity status and register the server Verify the Raid groups having required size of LUN or else create new Raid group Right click on the Raid Group and Create the LUN Create the Storage Group Add the Server and LUN to storage Group

CX and VNX Local Replication Technologies (Snaps and Clones)

Local Replication Snap view Snapshots Snap View clones RecoverPoint CDP snapshots

CX and VNX Remote Replication Technologies

Remote Replication SAN Copy RecoverPoint CRR MirrorView/S MirrorView/A

Thin provisioning vs. Thick Provisioning

Thick Provisioning Lazy Zeroed: Allocates the disk space statically (no other volumes can take the space), but doesnt write zeros to the blocks until the first write takes place to that block during runtime (which includes a full disk format). Thick Provisioning Eager Zeroed: Allocates the disk space statically (no other volumes can take the space), and writes zeros to all the blocks. Thin Provisioning: Allocates the disk space only when a write occurs to a block, but the total volume size is reported by VMFS to the OS. Other volumes can take the remaining space. This allows you to float space between your servers, and expand your storage when your size monitoring indicates theres a problem. Note that once a Thin Provisioned block is allocated, it remains on the volume regardless if youve deleted data, etc. By definition, you would expect Thick Provisioning Eager Zeroed to be the fastest.

FAST-VP
Fully Automated Storage Tiering (FAST) with sub-LUN automated tiering on CLARiiON CX4 series and Celerra family platforms (block only).

With the release of the VNX unified storage platform, FAST was extended to support sub-LUN automated tiering for file systems and renamed to FAST VP. FAST VP offers the following cost and performance benefits: Customers can set policies to automatically tier data based on I/Os, avoiding the pre-provisioning tasks of determining on which tiers to assign data. Customers can choose to have data placed on the highest or lowest available tier, ensuring that performance and cost commitments are met. Customers can define data movement schedules to minimize FAST management responsibilities. FAST can run on two or more drive types, optimizing an investment in Flash, SAS (performance), and/or NL-SAS (capacity) drives. With granular tiering, FAST VP makes it possible to reduce storage acquisition costs while at the same time improving performance and response time. Because FAST VP is fully automated and policy driven, there is no manual intervention required to make this happen, so you save on operating costs as well. FAST VP is ideal if you have a mixed workload of applications and dont have time or resources to manually analyze and tier each application.

FAST-Cache
FAST can benefit from FAST cache to enhance storage performance. FAST cache can be easily expanded as operational needs evolve. This incremental approach allows customers to start with only a small initial investment. FAST cache uses enterprise Flash drives to extend existing cache capacities up to 2 terabytes. FAST cache monitors incoming I/O for access frequency and automatically copies frequently accessed data from the back-end drives into the cache. FAST cache is simply configured and easy to monitor. FAST cache accelerates performance to address unexpected workload spikes. FAST and FAST cache are a powerful combination, unmatched in the industry, that provides optimal performance at the lowest possible cost.

Understanding File based protocols (CIFS and NFS)

CIFS

The Common Internet File System (CIFS) is the standard way that computer users share files across corporate intranets and the Internet. An enhanced version of the Microsoft open, cross-platform Server Message Block (SMB) protocol, CIFS is a native file-sharing protocol in Windows 2000. CIFS defines a series of commands used to pass information between networked computers. The redirector packages requests meant for remote computers in a CIFS structure. CIFS can be sent over a network to remote devices. The redirector also uses CIFS to make requests to the protocol stack of the local computer. The CIFS messages can be broadly classified as follows: Connection establishment messages consist of commands that start and end a redirector connection to a shared resource at the server. Namespace and File Manipulation messages are used by the redirector to gain access to files at the server and to read and write them.

Printer messages are used by the redirector to send data to a print queue at a server and to get status information about the print queue. Miscellaneous messages are used by the redirector to write to mail slots and named pipes. Some of the platforms that CIFS supports are: Microsoft Windows 2000, Microsoft Windows NT, Microsoft Windows 98, Microsoft Windows 95 Microsoft OS/2 LAN Manager Microsoft Windows for Workgroups UNIX VMS Macintosh IBM LAN Server DEC PATHWORKS Microsoft LAN Manager for UNIX 3Com 3+Open MS-Net CIFS complements Hypertext Transfer Protocol (HTTP) while providing more sophisticated file sharing and file transfer than older protocols, such as FTP NFS A Network File System (NFS) allows remote hosts to mount file systems over a network and interact with those file systems as though they are mounted locally. This enables system administrators to consolidate resources onto centralized servers on the network. Currently, there are three versions of NFS. NFS version 2 (NFSv2) is older and is widely supported. NFS version 3 (NFSv3) has more features, including 64bit file handles, Safe A sync writes and more robust error handling. NFS version 4 (NFSv4) works through firewalls and on the Internet, no longer requires portmapper, supports ACLs, and utilizes stateful operations. Red Hat Enterprise Linux supports NFSv2, NFSv3, and NFSv4 clients, and when mounting a file system via NFS, Red Hat Enterprise Linux uses NFSv3 by default, if the server supports it. All versions of NFS can use Transmission Control Protocol (TCP) running over an IP network, with NFSv4 requiring it. NFSv2 and NFSv3 can use the User Datagram Protocol (UDP) running over an IP network to provide a stateless network connection between the client and server. When using NFSv2 or NFSv3 with UDP, the stateless UDP connection under normal conditions has less Protocol overhead than TCP which can translate into better performance on very clean, non-congested networks. The NFS server sends the client a file handle after the client is authorized to access the shared volume. This file handle is an opaque object stored on the server's side and is passed along with RPC requests from the client. The NFS server can be restarted without affecting the clients and the cookie remains intact. However, because UDP is stateless, if the server goes down unexpectedly, UDP clients continue to saturate the network with requests for the server. For this reason, TCP is the preferred protocol when connecting to an NFS server. NFSv4 has no interaction with portmapper, rpc.mountd, rpc.lockd, and rpc.statd, since protocol support has been incorporated into the v4 protocol. NFSv4 listens on the well-known TCP port (2049) which eliminates the need for the portmapper interaction. The mounting and locking protocols have been incorpated into the V4 protocol which eliminates the need for interaction with rpc.mountd and rpc.lockd.

File Local Replication Technologies (SnapSure)

EMC SnapSure is an EMC VNX software feature that enables you to create and manage checkpoints, which are point-in-time, logical images of a Production File System. SnapSure uses a "copy on first modify" principle. A PFS consists of blocks. When a block within the PFS is modified, a copy containing the blocks original contents is saved to a separate volume called the SavVol. Subsequent changes made to the same block in the PFS are not copied into the SavVol. The original blocks from the PFS in the SavVol and the unchanged PFS blocks remaining in the PFS are read by SnapSure according to a bitmap and block map data-tracking structure. These blocks combine to provide a complete point-in-time image called a checkpoint. A checkpoint reflects the state of a PFS at the point in time the checkpoint is created. SnapSure supports two types of checkpoints: Read-only checkpoint Read-only file system created from a PFS. Writeable checkpoint Read/write file system created from a read-only checkpoint. SnapSure can maintain a maximum of 96 read-only checkpoints and 16 writeable checkpoints per PFS while allowing PFS applications continued access to real-time data.

File Remote Replication Technologies Celerra Replicator: Celerra replicator is a software Celerra Replicator integrates with Celerra writeable snapshot functionality, so whenever there has been a change to the environment, it is a simple process to generate a writeable snap at the remote location, bring up the new environment, and validate the disaster recovery process. Complete testing methodologies involving full failover and disaster recovery process testing can easily be accommodated by forcing a failover. Using Celerra Replicator to maintain a complete copy of the data in a local or remote location allows for business continuity and dramatically speeds the recovery process. When a disaster recovery is required, Celerra Replicator ensures that all your mission-critical information has been captured and sent to one or more remote sites. For data recovery, the secondary copy can be made read/write, and production can continue at the remote site. If the primary system becomes available, incremental changes at the secondary copy can be played back to the primary with the resynchronization function. Using replicas rather than tape means you can be up and running in hours as opposed to days. SAN Copy:
SAN Copy is a storage-based software product that can be used for copying content of the source LUN to destination LUN in local storage or remote storage systems without host intervention. A key feature of SAN Copy is that it can copy data between CLARiiON and multi-vendor storage systems (including IBM, HP, Hitachi Data Systems, and Sun storage arrays). The source LUN for a SAN Copy session can be the production LUN or SnapView clone of the production LUN. SAN Copy supports full and incremental copies of a source LUN. The initial copy synchronization requires a full copy replication of the source LUN. After the initial full copy of the source LUN, the incremental SAN Copy feature can be used to perform a bitwise-refresh of the destination LUN(s) with just the blocks that have changed since the last copy of a source LUN. This significantly reduces the time needed to refresh the destination LUN. The incremental SAN Copy feature requires sufficient storage space in the reserved LUN pool on the source array. Applications where performance is a critical factor should consider clones of the source LUNs to drive the incremental SAN Copy sessions instead of the source LUN. SAN Copy gives its best performance if the source and destination arrays are connected through multiple front-end sources to destination pairs. SAN Copy typically utilizes Fibre Channel between primary and secondary arrays. As

of FLARE release 26, SAN Copy data replications can also be provided by using the built-in iSCSI ports on CX3 FC/iSCSI systems.

MirrorView
MirrorView is a storage-based replication software product that can replicate SQL Server database LUNs to remote locations for disaster recovery. MirrorView replication is transparent to the host Remote replication facilitates failover by restarting the secondary mirror image on the recovery site in case the production host or the production storage system fails. Fracturing stops MirrorView replication from the primary image to the secondary image. Promoting the image involves an administrator changing an images role from secondary to primary in order to mount the image to the secondary host. MirrorView can integrate with SnapView to create SnapView snapshots of a secondary image that can be used for product testing and data verification at the remote site. Clones of the secondary image can also be created to maintain a usable copy (gold copy) of the primary image at the secondary site. As of FLARE release 26, MirrorView data replications can also be done by using the built-in iSCSI ports on CX3 FC/iSCSI systems. MirrorView allows bidirectional replication that facilitates failback of production from the secondary to production site once the production site is back online. The MirrorView consistency group feature can maintain write ordering across LUNs at the remote recovery site in the event of a failure of the writeorder dependent LUNs on the source, or the mirroring connections. MirrorView software offers two complementary mirroring products: MirrorView/S and MirrorView/A.

MirrorView/S:
MirrorView/S is a replication software product that can mirror data images of a production host LUN synchronously in real time to secondary storage at a remote site. Synchronous mirroring offers zero data loss in the event of the failure of a production site. The mirror image of the production data at remote sites can be used to restart production at the recovery site in the case of primary site failure. Bandwidth and latency of the MirrorView/S interconnect are critical to successful deployments with SQL Server replication. Sufficient bandwidth must exist to initialize the remote mirror and sustain active mirroring operations. The greater the distance is between the production site and the remote protection site, the greater the propagation latency. Latency must remain low enough to prevent database and application bottlenecks that could ripple through to the end user. High bandwidth and low latency requirements restrict the use of MirrorView/S for long-distance replication. MirrorView/S is primarily targeted for short-distance (metropolitan/campus) replication.

MirrorView/A:
MirrorView/A is an asynchronous replication software that offers long-distance replication based on a periodic incremental-update model. It periodically updates the remote copy of the data with all the changes that occurred on the local copy since the last update. This can result in minutes of data loss in case of the failure of the primary site. The performance of MirrorView/A depends on: The distance between production and recovery sites Latency and bandwidth characteristics of the connecting link The amount of data transfer Duration of the update Because of these performance factors, user must properly size the replication requirements before deploying MirrorView/A for SQL Server disaster recovery. MirrorView/A is generally suited for replicating images with lower rates of data changes over long distance on lower bandwidth links.

File Migration Technologies Robocopy:

Robocopy is a 32 -bit command-line tool used for file replication. This tool helps maintain identical copies of a directory structure on a single computer or in separate network locations. Using Robocopy, you can copy a single directory, or you can recursively copy a directory and its subdirectories. The tool classifies files by whether they exist in the source directory, in the destination directory, or in both. In the latter case, the tool further classifies files by comparing time stamps and file sizes between the source file and the corresponding destination file. You control which classes of files are copied. If a file exists in both the source and destination locations, by default Robocopy copies the file only if the two versions have different time stamps or different sizes. This saves time if the source and destination are connected by a slow network link. You can also specify that copies are restarted in the event of a failure, which saves even more time when your network links are unreliable. Robocopy allows you to do the following: Use file names, wildcard characters, paths, or file attributes to include or exclude source files as candidates for copying. Exclude directories by name or by path. Delete source files and directories after copying (that is, move rather than copy them). Delete destination files and directories that no longer exist in the source. Control the number of times the program retries an operation after encountering a recoverable network error. Schedule copy jobs to run automatically. Specify when copying is to be performed. Monitor a directory tree for changes. Selectively copy file data

EMCOPY:
EMCOPY lets you copy a file or directory (and included subdirectories) from and to an NTFS partition, keeping security the same on the copy as on the original. EMCOPY allows you to back up the file and directory securityACLs, owner information, and audit informationfrom a source directory to a destination directory without copying the file data. EMCOPY, however, does not copy the local groups database from one computer to another. LGDUP first copy the local groups database. Therefore, when the /lg or /lu option is specified, EMCOPY initially checks whether all of the source servers local groups exist on the target server. If at least one group is missing, EMCOPY stops and notifies you to use LGDUP first.