Month: August 2014

EMC VNX – a quick introduction to Virtual Data Mover

Before we talk a little bit about Virtual Data Mover, I think it will be the best to explain what Data Mover itself is.

Data Mover

A Data Mover is a component that runs its own operating system (OS). This OPS retrieves data from a storage device and makes it available to a network client. It is basically a gateway to present NAS Storage to end-user. The Data Mover can use the NFS, CIFS and pNFS protocols.

The configuration and control data is stored in the root file system of a physical Data Mover.

Virtual Data Mover

A Virtual Data Mover (often called VDM) is software feature that enables the grouping of CIFS and/or NFS and servers into virtual containers. It is possible to separate CIFS (and/or NFS) from each other and from associated environment. For example, using two VDMs, you can attached different IP addresses, different replication scheme etc.

Each VDM storage its configuration information in its respective VDM root file system. The VDM configuration file is a subset of the configuration files on the physical Data Mover.

 

VDM root file systesms within Data Mover

VDM root file systesms within Data Mover

Picture above shows the Data Mover and 3 root file systems for VDMs. There are operations that can only be performed at the physical Data Mover level. Operations performed at the Data Mover level affect all VDMs!

These operations include:

  • Stop, start, delete services (eg. CIFS)
  • Data Mover failover
  • Parameter changes

 Antivirus

In addition to CIFS servers created on a VDM, a global CIFS server is required for antivirus functionality. It means you have to have one additional CIFS server, created on the physical Data Mover to use AntiVirus solution. In short future I will explain a little bit more regarding EMC CAVA.

VDM Replication

Sooner or later I will create a seperate post regarding EMC Replicator, in this paragraph I just want to make a quick introduction to the concept of replication. In order for a CIFS object to be fully functional and accessible on a remote VNX system, the administrator must copy the  complete CIFS working environment. That includes local groups, user mapping information, Kerberos objects, shares, event logs etc.. In addition you have to replicate the file systems associated with the CIFS server.

VDM replication accomodates the CIFS working environment by replicating the root file system of the VDM, which includes the CIFS working environment information. Using this form of replication, you will produce a point-in-time copy of a VDM than re-creates the CIFS environment at the destination.

The VDM root file replication does not include the replication of the filesystems mounted to that VDM! What does that mean? That if you replicate only the VDM root file, you will not be able to use your DR site, because the user data itself will not be replicated.

Failover procedure

The replication failover procedure verifies that the remote VNX Data Mover has matching network interface(s) [same name] as the interface(s) configured on the source VDM. This check is also applied for all interfaces attached to the VDM regardless of which protocol they are bound.

Source VDMs can be involved in replicating up to four destination VDMs concurrently. A destination VDM must be in a read-only state (called mounted, as opposed to lodaded state, which is in read-write state). A destination VDM can be a source for up to three other replications. Since a given VDM can ac as both a source and destination for multiple replications, it supports a one-to-many and cascade configuration.

 

EMC VNX – CIFS DR – part 2: Usermapper

Every (NAS/File) VNX user must be assigned a unique numeric UID and GID to indicate the ownership of directories and files. Like VNX, UNIX/Linux use UIDs and GIDs to identify users and groups. As a consequence, the VNX can use the UIDs and GIDs supplied by UNIX/Linux clients withouth requiring any additional mappings. However the situation is a little bit different with Windows. Windows doesn’t use numeric IDs to identify users. Instead, it uses strings called security identifiers (SIDs). That gives us a little bit of a challange, and before we configure Windows file-sharing service (CIFS server), the method of mapping Windows SIDS to UIDs/GIDs has to be selected. For info regarding this topic please read post EMC VNX – Usermapper in theory.

Usermapper

Our CIFS DR solutions describe Windows-only environment. The VNX Usermapper feature automatically assings UIDs and GIDs to Windows users and groups. This functionality is part of Data Mover’s software, so we do not have to install anything additionally.

Usermapper automatically generates UIDs and GIDs for Windows domain user and group SIDs and maintains the mapping in a database. The generated UID and GID values start at 32768 and increment for each new user and groups being mapped.

Usermapper roles

There are three usermapper roles: primary, secondary and client. Primary Usermapper is enabled by default and runs on Data Mvoer 2 on every VNX system. Only this role generates user mappings. In multiple VNXs environment only one primary usermapper can exist. Secondary Usermapper does not generate user mappings, but rather queries the Primary Usermapper for the mappings. In multi VNX environment there should be one secondary usermapper configured per each additional VNX. Finally we have Usermapper Client that should be configured on all other VNX Data Movers. Usermapper client query primary/secondary usermappers within their VNX for user mappings.

Secmap

Secure mapping (secmap / secmap cache) listens to mapping sources and records the mapping information provided. Secmap is designed to improve response time for a subsequent mapping request of a user or group that has already been mapped. Secmap doesnt generate user mapping – that’s what’s usermapper for.

EMC VNX – CIFS DR – part 1: Overview

I think that will be more than just one post. I would like to go thru the overview, design, and best practice with implementing CIFS DR solution using VNX Replicator. Let’s start from the beginning.

CIFS DR introduction

DR stands for Disaster Recovery, and it’s a plan to replicate and recover data (in case of a distaster). What does that exactly mean? Let’s assume you have two Data Centers – one for your production environment, with all users connecting to it, and second, maybe with a little bit cheaper hardware, DR Data Center. Once there is a failure in your primary DC (for example all power suppliers will fail, or there is a fire), to guarantee data continuity you have to switch your users to your DR site. This series of posts will explain step-by-step how to do it with CIFS (Windows users) servers for EMC VNX.

CIFS Replication

CIFS Replication

CIFS DR solution is asynchronus. It means that during the failure you will loose some data. Typically the data is replicated every 10  minutes, so in worst-case  scenario (using typical setting) you will lose up to 10 minutes of users work when losing primary DC. A point-in-time copy of a production environment can be replicated asynchronously to a remote VNX and, in the event of disaster, can be accessed using the same CIFS servers, share names and local groups.

There are two basic rules to implement this solution, first is: you have to use VNX Replicator. Second is – your CIFS servers have to be placed on Virtual Data Movers (VDM).

It’s a little bit more complex that the picture I above. Replicating CIFS data takes more than just replicating file systems. Sinces CIFS data is dependent on its environment, parts of the environment must be replicated as well. That’s why you have to use VDM. Virtual Data Mover is contained within a file system that can be replicated and contains the following CIFS information:

  • local groups database
  • CIFS server names and interfaces
  • Kerberos information
  • CIFS share database
  • home directories
  • event logs

To make CIFS data user accissible on remote site, you have to replicate both the file systems and associated VDMs.

CIFS DR configuration

There are a number of setup operations to be performed if you like to implement a CIFS DR solution using VNX replicator. The most important are:

  • You have to CIFS service running (obviously 🙂 ), Replicator and SnapSure licensed and enabled.
  • Ability to configure Control Station, Data Mover IP interfaces, routing, DNS and NTP network services.
  • If your VNX is windows-only environment it’s highly recommended to use Usermapper for user mapping method. You have to configure one primary usermapper service and one secondary usermapper service. It doesn’t mean that primary usermapper should be in your primary DC. Actually EMC gives you the choice, but best practice is to put in in your remote DR. I will write a seperate post regarding Usermapper.
  • VDMs have to be configured and data file systems have to be created, configured and mounted on the VDMs. Same with CIFS Servers – they have to be configured within VDMs as well.

Data Mover network interface configuration

As you know, CIFS servers are assigned to network interface names. with VNX Replicator, CIFS servers must be able to operate on the DR site. Without that there would be no option to direct end-users to your DR site. To make that possible the interface names used by CIFS servers must be identical on the Data Movers from both sites. I bet you wonder ‘OK, same interface name, what about IP?’ Great question.

Data  Movers can have different or the same IPs. When the interfaces on each site are configured with the same IP  address, there are some benefits and risks. First of all, DR site cannot have the interface up and online. With different IP address the interfaces on both sides can be up and online. There is no need for manual manipulation of the interfaces during a failover operation. However there is one risk as well – CIFS server will have a different IP address. If dynamic DNS is used, the records for the CIFS server will be updated automatically… But… Any clients having a DNS cache (with old-IP entry) will be unable to access the CIFS server until its DNS cache is flushed.

NTP Service configuration

I assume your CIFS servers are joined to Active Directory Domain. Both AD, and Replicator operations are time sensitive. AD authentication uses the Kerberos auth protocol – which requires a default time tolarance of 5 minutes. When configuring remote replication, Control Stations (primary and secondary site) must be within 10 minute time tolerance. The NTP service is used for maintaining system time synchronization. For redundancy purposes you should configure your VNX with at least two NTP servers. Remember, you configure both Data Mover, and Control Station with NTP service.