I’m going to mainly concentrate on the zoning of EMC arrays here, but to go broader I think its worth while noting that “single initiator single target” is defiantly the way to go.

In almost every site which I go into, I will find alias names setup for a CLARIION as shown below.

cx4_spa0 or often ill see cx4_spa_port0

There is absolutely nothing wrong with this and it gives you all the information you need such as the Array Type, Storage Processror and Port which is connected. This works well when you have single array, but often people get stuck with additional alias names when they have a second array of the same type. There are of course a number of ways you can go about differentiating the arrays but few keep things tidy and consistent.

The convention I use will depend on how their existing Aliases are configured eg;

vnx_spa_port0 or vnx_spa0 or vnx_spa_port_0 (all of which are examples I have seen in the field). 

So what will I use ? I will configure vnx_3ea13252_spa_0 or  vnx_3ea13252_spa_port0 again depending on existing configurations.

So where does the 3ea13252 come from ? Well every time you zone an array the wwn will be different and that’s the point. I’ve created a diagram below to show a typical CLARRION / VNX wwn which you would expect to see when you go looking on the array or on the switch after connecting it.

As soon as you see the first 3 octets of 50:06:01 then you know it’s an EMC CLARIION array, the next octet is the Storage Processor Port, and the last 4 octets is the unique array ID assigned to the array.

While my alias might not be the most attractively constructed Alias you’ve ever seen, its does give me a very clear path for adding additional VNX arrays to the same switched network as the array ID will never be the same.

vnx_3ea13252_spa_port0

vnx_1ca19253_spa_port0

If I come back and need to either add an additional array yet again, or make zoning changes, It’s really clear and hard to get wrong. Most of all I like it because its tidy and consistent, maybe it might be a touch on the obsessive compulsive side, and one might argue that port descriptions can be used to get around this….. well I have a golden rule of never trusting port descriptions as they are often out of date. (which means wrong).

This is not EMC best practice, this is just my own way of doing things which works well for me.

Firstly vSphere 5.0 has been released, I opened my email Monday morning to find a tone of marketing emails from VMware about the launch.

Secondly, it seems Lady GaGa is in Sydney at the same time I am.

I was sitting in my hotel room the other night watching some TV when I heard screaming and shouting, it sounded like a large group of people (mob), at the time I figured it must have been Lady GaGa leaving her hotel room causing mass fan hysteria.

Well today after a mate txt me asking about VMware’s new licensing scheme, I rushed back to the hotel to download the licensing guide and to be honest im now not sure the screaming was GaGa fans, It may well have been VMware customers walking down the street with pitch forks and machete’s protesting the new licensing scheme.

I have had a really quick read over the document and ill be honest, my first impressions I admit were quite cynical, but to be fair im going to read over the document properly and try to get my head around it.

The reason I am cynical about the change initially is because over the last couple of years I have seen a common trend where customers (and myself included) have replaced ESX host hardware with the same number of physical CPU sockets, but doubled or tripled the amount of memory per host. This was something which came about when the Nehalem CPU was released, the result was more logical cores and more VM’s you could run per core.

In the meantime if your interested in seeing a couple of good examples of how the changes might not be as bad as everyone’s saying it is, check out this post by Gabe of Gabes’s Virtual World.

After downloading all available docs from Powerlink, I went and opened the document titled “Licensing Guide“ which you would think should cover VADP licensing right ? ….. Wrong!.

Next I went and looked at “EMC NetWorker VMware Integration Guide“, I was hopeful this would contain the information I was after, but after reading the section “Licensing NetWorker support for VMware” I felt very much like I did when I saw the movie Mulholland Drive for the first time. 

However, today I was glad to receive an email from a colleague who found the following post on the NetWorker Community site by Eric Carter at EMC helping to clear up some of the misleading/confusing statements regarding licensing for VADP in 7.6 SP2 documentation.

Hopefully it wont be too long till we see updated documentation on Powerlink. (I’m also hoping the VADP licensing information gets added to the licensing guide document)

(click on the image below to enlarge)

I’ve got a number of posts about this coming up, but for the moment, just a quick one to say it’s here, and to list some of the published features.

It’s fair to say that existing NetWorker customers have been waiting for VADP support for a considerable time now, so its great to finally see it arrive. However without putting a damper on things I would like to suggest customers do not rush off and upgrade without reading the release notes and considering there are still a number of open escalation’s in this build which are logged for issues with VADP.

VMware: vStorage API for Data Protection (VADP)

• Integrated with vStorage API for Data Protection (VADP)
• Change block tracking (CBT) support (file-based)
• Single-step image-level backups & restores
• Support for file level recovery from Windows VMs

 Flexible Single Step VM Recovery

• To the original, new, or configure a new virtual machine
• Recover the VM to the same/different vCenter, ESX Server, or ESX datastore

 NetWorker VADP proxy options

• Physical or virtual servers
• Windows Server 2008 R2, Windows Server 2008 or Windows Server 2003

DD Boost or Avamar Grid deduplication backups

• DD Boost on VADP Proxy with Dedicated NetWorker Storage Node
• Support for Global Encryption and Compression Directives for  NTFS image and file level backups
• VMware VADP and In-Guest backups of the same UNIX/Linux based virtual machine

The Problem :

The symptoms I saw were as follows;

• Enabling the first mirror of a LUN per SP showed no issues, the LUN replicated and showed to be in a consistent state.
• Enabling additional mirrors of LUNS on the same SP caused the initial mirror to re synchronize, (but would never complete).
• Enabling  additional mirrors caused the hosts average read/write queue times to shoot through the roof causing huge performance problems.

Fix:

The arrays I was working on were running flare version 04.30.000.5.004 which needed to be upgraded to 04.30.000.5.517. After the upgrade I initiated a sync on all mirrors and everything starting working as expected.

The first link below is to one of Chad’s latest posts covering the latest release of the VMware vCenter plugin.

The second link goes to PowerLink where you can read more on the new features and support in Replication Manager 5.3 SP2.

EMC vCenter Plugin update-VNX/VNXe support

EMC Replication Manager 5.3 SP2 VNX/VNXe support

The comment will display as “EMC-SNAS:T<Dart Version>” shown below as “EMC-SNAS:T6.0.36.4“

To stop this from happening you can typically handle this two ways.

#1. On an existing CIFS server: Run the following command as user nasadmin

server_cifs <vdm> -add compname=cifs server>,domain=<domain>,interface=<interface name> -comment ” “

You can see from the command I run that I’m using a virtual data mover, if you’re not then replace this with <server_x>

#2. When creating a new CIFS server: One of the benefits of creating a CIFS server from the command line is you can add the switch -comment ” “ at the time of creation which gets around this problem from word go.

If you’ve mapped drives prior to the change then mapped drives will still show the default CIFS comment because windows caches it in the registry. I did a search for EMC-SNAS and found it in the following location (shown below).

Just delete the entry from the registry and at next login the mapped drive will appear without the comment.

The symptoms with the NS120′s was quite different to that of the gateway, the NS120′s gave a clear blatant certificate error which let you know the certificate was not valid and basically stated to please come back 3 hours in the future for then the certificate would be valid and accepted.

The VG2 gateway install was completely different and manifested its self to look more like a browser compatibility issue. When launching Unisphere the pop up window would launch but the login prompt would not appear.

The NS120′s were deployed in the afternoon and I didn’t have the need to login immediately so I packed up and left it for the next day. The next day I turned up and logged in without an issue as the certificate was now valid.

The VG2 gateway was more like a day out of sync and I thought id login, correct the time on the control station and try to re-generate the SSL certificates using the command /nas/sbin/nas_config -ssl but this unfortunately did not work.

I did some searching in PowerLink hoping to find something related and found the following knowledge base article;

emc257320 “After NAS 6.0 fresh installation, unable to log in to Unisphere”

While searching PowerLink I found another article related to the Clariion, but almost identical in nature. The fix for the Clariion was nicer as it allowed you to put your clock forward, login, then generate a new certificate and then put your time/date back to the corect time.

emc247504 ”Certificate date and time error prevents access to CX4 storage system after upgrade to Release 30.”

The problem seems to be present in both FLARE 30 and DART 6.0 and can show up during install or upgrade.

Hopefully anyone with the same problem might find this post before spending hours thinking it’s a browser or java issue.

Hope this helps.

Question #1   “Whats all this Unified Storage Hooey about?” 

Probably a good place to start for people who are not overly familiar with the term “Unified Storage” is to define it. In my own words “Unified Storage” is about being able to present and manage storage using multiple protocols e.g. BLOCK (FC), NFS, iSCSI and CIFS from the same storage array.

It’s no secret that most of us (myself included) have adopted the mind-set ”Virtualize Everything” and with that I don’t need to explain where BLOCK, NFS and iSCSI have a place in the virtualization world as they are all widely used and proven.

You might say that typically people tend to pick one protocol and stick with it and you wouldn’t be wrong, but think about being able to tier storage by protocol rather than how you normally associate tiering in the storage world which tends to centered around disk type e.g EFD, FC, SATA. If you look at the cost of FC switch ports and HBA’s compared to Ethernet ports and adapters, it makes total sence that you might consider putting tier 1 production systems on FC storage while placing your test and development systems on IP storage such as NFS or iSCSI.

Question #2   “What good is CIFS to me in a predominantly Virtual world”

When virtualization started taking off years ago we all went mad, it was all about server consolidation and In most cases we virtualized anything that responded to a ping request. What happened often was people virtualized file servers and ended up with virtual machines with huge .vmdk or rdm’s which generally did two things.

• Used huge amounts of valuable storage
• Caused huge bottle necks and backup windows blew out

 So I’ll address those two points and try to also cover some other key points which in my mind, make putting file data on the Celerra a no brainer.

De-Duplication: This feature is actually single instance plus compression. People are always sceptical about the figures which storage vendors put out in the market as they are often not achievable, but I can tell you that I have personally seen 1TB file systems reduce by 50% and in some cases 60% with Celerra De-Duplication enabled.

NDMP Backup: File systems containing user data tend to be quite dense, typically this causes traditional backup systems grief and a full backup window can end up being 4-5 days with large amounts of data. NDMP backups using EMC NetWorker can be configured to pull the data over the network or directly to a fibre connected device (tape or VTL drive) for LAN free backup. Celerra NVB (block based backup) handles dense file systems really well, Ive seen backup windows shrink from days to hours.

Snapshots: If you’ve ever been a backup administrator for a large organization you’ll know that on a bad week you can end up spending way to much time recovering user data. Celerra allows you to configure scheduled snapshots of file systems which are then available via the windows previous version tab built into XP service pack 3 and above operating systems.

Archiving: How much of that user data has actually been accessed in the last 6 months ? Introduce EMC’s File Management Appliance (Rainfinity) and you have the ability to move data from expensive FC disk to cheaper SATA storage while being transparent to users accessing the data.

I could go on and on about the other features such as High Availability, Replication, File Level retention, File Filtering, etc, etc but I think this post might end being too much of a mammoth read so I might pick some of these and elaborate more in up coming posts.

I’m not saying it’s a mistake to virtualize file servers because in certain cases there are advantages e.g. being able to replicate and protect using VMware Site Recovery Manager is a good example where its advantageous, but I am saying the larger the amount of data, the more beneficial it is to consider moving to the Celerra.

For the last couple of years the majority of the Celerra’s Ive deployed have been shipped with DART 5.6 code and the backend Clariion flare version has typically been what we refer to as 28,29 and most recently flare 30.

One of the first things you learn when deploying Celerra’s is you need to read the NAS Matrix guide to determine which RAID configurations are supported because although you may be able to create certain RAID types with x number of disks on the backend Clariion, It doesn’t mean the Celerra will let you use it… this is typically where people sit for 20-30 mins performing multiple “rescan storage” operations hoping that storage will magically appear.

One of the biggest changes in Flare 30 was the introduction of storage Pools which is quite different to the traditional “Raid Group” concept which has been around for donkeys years. If you want to read a bit more in-depth information about Storage Pools, then check out Matt Hensleys post here.

What I couldnt find in the latest NAS Matrix guide or in any of the documentation I found was conformation that I could present storage from the Clariion storage pool to the Celerra, so after carving a LUN from the storage pool made up of 10 FC disks, I presented it through to the Celerra and performed a rescan…… rescan…… and one more for good luck…..rescan, but unfortunately no luck and no LUN.

At this stage I remembered often performing tasks from the command line on the control station often spits out more debug information so I thought id give it a shot.

And that confirmed it. ” Fully provisioned CLARIION pool device was not marked because it is not supported in this realease”

The answer to this problem in the end was “thin provisioning”. I created a thin provisioned LUN from the Clariion Pool, added the LUN to the Celerra storage group and performed a rescan and there was my LUN.

In the end I found the following primus solution EMC241591 which outlines 3 conditions that will cause this error, fully provisioned LUNs was one of them along with Auto Tier and Compression being enabled.

Cause : Certain new CLARiiON FLARE Release 30 features are not supported by Celerra and the initial 6.0 NAS code release.  CLARiiON LUNs containing the following features will not be diskmarked by the Celerra, resulting in diskmark failures similar to those described in the previous Symptom statements:

• CLARiiON FAST Auto-Tiering is not supported on LUNs used by Celerra.
• CLARiiON Fully Provisioned Pool-based LUNs (DLUs) are not supported on LUNs used by Celerra.
• CLARiiON LUN Compression is not supported on LUNs used by Celerra.