blog.virtualtacit.com

The semantics behind software releases is somewhat confusing to us normal folk. What each, seemingly relevant, number means to the vendor means something totally different to the layman. So here is a quick curiosity post on Clariion FLARE release numbers and what they mean. Now don’t take this as law, as some of the releases specifically on the 1st and 2nd Gen CX’s were not so straightforward. But from the CX3 on this looks to be pretty accurate.  One more thing, the “5″, noted below, is still a bit of a mystery to me, it does carry across all FLARE releases though, back to Release 7. Anyone know?

For those of you that have not gone the route of NFS, specifically NFS on Celerra, for your VI, then listen up here a few benefits of such a design..

Note: Keep in mind that each environment is different and that no one solution is ideal for everyone. I am by no means promoting NFS for all performance situations but rather informing you of the capabilities of the Celerra and how NFS fits into the equation. NFS has its challenges in itself just like every other storage protocol so be diligent and work through the numbers as to what works best for you.

Celerra Virtual Provisioning/Automatic File Extension

Allocating based on actual disk consumption rather than projected pre-allocated capacities. The days of fat or over provisioning are over, additional storage is allocated on a per file system basis only when needed. When the amount of used storage hits a predefined threshold or watermark the file system is automatically extended to compensate. NFS datastores can quickly and dynamically be expanded without jumping through hoops.

 Advanced Networking Options for High Availability

• Failsafe-Active-Passive configuration across CGE ports, across separate switches. All connections in this pairing share the same MAC address, if the active link fails the passive link becomes active and therefore assumes the identify of what was the active link. A couple of things with FSN’s:
  • Here is what is cool, FSN can include single GigE ports, channel devices or LACP devices, although no more than 4 per FSN. So in certain situations, you could configure two separate virtual devices, one configured as a Etherchannel device and one configured as LACP device and then FSN between the two, remember only one device will be active at one time.
  • On Cisco switches, enable portfast for each DM port
  • FSN’s do not rely on any specific switch functionality so it truly is the most neutral solution across switch vendors.
• Etherchannel- I won’t go into the specifics on Etherchannel as that is common knowledge, but I will say this will not increase bandwidth, it exists to provide HA across a single switch, so a port failure. Single MAC address for the channel applies, static configured channels only no PAgP.
• LACP- Much like Etherchannel but the number of links in the aggregation is not required to be in multiples of 2 like EC. LACP is certainly more robust as it relates to failure detection than the latter.

What else with AN? Statistical LB..

Well I did allude to the fact that all of these mechanisms (EtherC and LACP) are purely for HA, but technically you could use Statistical Load Balancing on a per DM basis. This allows for distribution of frames across links in the channel by using a portion of the source and destination MAC address to determine the link to transmit down.  You can configure SLB by IP, TCP ports and IP address. Here is the command:

$ server_param server_2 -facility trunk -modify LoadBalance -value TCP (change the value according to what LB method you want to use, available options are TCP, IP (default) and mac)

 

   

SnapSure checkpoints

The ability to recover a VM in its entirety from a CIFS share holds some weight with me. Celerra SnapSure gives you just that, Point in Time accessibility of NFS filesystems via a CIFS share divulged via the .ckpt shared hidden directory, ie. \\cifs_server_name\share_name\.ckpt. This my friends is the essence of ultra near-line recovery, and has saved me hours in full VM recovery time. I haven’t seen this process video documented anywhere so I may take a stab at it in the future.

Additional benefits and tips to assist the cause…

NFS Performance Tuning

• Leverage the uncached and no prefetch mount options on the Celerra DM to enhance write performance:
  • server_mount server_2 -o uncached fs_name mount_point
  • server_mount server_2 -o noprefetch fs_name mount_point

Furthermore, the uncached write option enhances performance of applications with many connections to large files. Could produce an increase in performance up to 30%. Turn on for all NFS specific filesystem’s, if replicating make sure you turn on this option on both the primary and replicated file system.

• Avoid virtual machine swapping to NFS volumes. Edit virtual machine config file to add sched.swap.dir place swap on local storage (supported inline with VMotion in ESX 3.5)
• 8 NFS mounts per ESX Server allowed by default adjust “NFS.MaxVolumes” , note:raising it to 32 increases the amount of physical memory needed, so size appropriately.
• NFS client read/write size, set NFS.ReceiveBufferSize and NFS.SendBufferSize to a multiple of 32k ensure both are identical

NFS Security

• Separation of traffic through the use of VLAN’s
• Limiting access to certain host IP addresses
• Limiting access to certain user accounts
• ESX provides the use of a non-root account called a delegate account to mount the NFS files system. This will avoid exporting the file system with root access.

Creating an NFS Datastore via Celerra Manager

Why mess with a good thing, video on said title, http://www.youtube.com/watch?v=B5Qn4EMgbDc. Remember, considering you are using the Celerra file system for your datastore most Celerra features apply such as SnapSure, Celerra Replicator, SRDF and Quotas.

And finally, Feature Set Comparison to Storage Protocols

And if you in doubt here is how each protocol lines up to applicable feature sets.

Is this really a surprise to any of you? I mean come on, your wife gets ousted a few months early, you know the taste in Mendel’s mouth was growing sour. That is four high profile positions lost in the last three months, noted here, here and here. Is VMware choking on its own tongue, where do they go from here, what will be announced at VMworld next week to calm the masses? It goes without saying that is the beginning of a new era for VMware, the fate of one company is not hinged on one man. As long as innovation continues to drip from the pores of VMware, they will continue to thrive in an ever changing market. As always thanks to virtualization.info for cracking this story first. Prepare for a wild ride on Wall Street today my friends, this won’t be pretty…or will it?

The use of writable checkpoints has many uses in today’s organization. Whether it is used for disaster recovery, application stage testing, or database mining, this technology has extreme value and usability. With the release of DART 5.6, the Celerra now adds the capability to write to what was always a read only checkpoint. This writable checkpoint is nothing more than incremental changes layered on a read only checkpoint notably named a baseline checkpoint. Any changes to the writable ckpt’s are saved to the same location as the read only ckpt’s, the SavVol. Comparatively, a writable ckpt can be served up to NFS, CIFS and FTP clients over the network just as the  standard ckpt can. Here is a quick visual to explain…

So as with any technology there are inherent limitations, without further a do here are WC’s…

• Duck Test rules apply…A writable checkpoint is ultimately a filesystem so don’t think it won’t count against the overall per Data Mover and per cabinet limitations. Which –if you’re wondering– are 2048 FS’s per blade across the Celerra line and 2048 FS’s per cabinet for the NX4 and NS20. However, 4096 per cabinet for NS40, NS90 and NSX models. For each primary file system you can have up to 16 writable snapshots.
• Refreshing a writable checkpoint requires a refresh of the baseline, read-only checkpoint
• Finally, here are a few FS operations that are not allowed with writable checkpoints although may be with production file systems:
• CDMS (Celerra Data Migration Service)
• CVFS (Checkpoint Virtual File System)
• Extending file systems, a writable checkpoint takes on the characteristics of the PFS therefore changing that is taboo.
• MirrorView
• SnapSure creates, refreshes, or scheduling are not permitted on a writable checkpoint..get over it..
• SRDF (Symmetrix Remote Data Facility)
• VTLU (Virtual Tape Library Unit) no, no on using a WC as a backup target
• and TimeFinder

<<Next are a few addressable questions that  always came to mind with checkpoints, hopefully they will bring clarity to your situation>>

How do I Size SAVVOL?

With any ckpt on the Celerra, appropriate sizing of the SAVVOL is important but more so when implementing WC’s. You must now be able to predict and plan for future writes as this has direct implications on your size requirements. Your crutch, of course, is the automatic SAVVOL extension feature but be prudent, do the math, and plan for what’s to come.

To assist you with how SnapSure calculates the SAVVOL, here is a quick rundown of the defaults..

• If PFS > 10 GB, then SavVol = 10 GB.
• If (PFS < 10 GB) and (PFS > 64 MB), then SavVol = PFS size.
• If PFS < 64 MB, then SavVol = 64 MB, which is the minimum SavVol size.

Keep in mind, this sizing only takes into account your baseline checkpoint, don’t forget your client writes. Relax..I know you won’t..

What performance implications can I expect, I heard there are no write penalties with NetApp FlexClones?

The mechanisms behind snapshotting, right or wrong, take a different form as engineered by EMC and NetApp. Whether your tackling  the ” Sequential read after random write” (NetAPP) performance problems of WAFL or the “Copy on First Write” (EMC-RLP) amercement,  you as a customer must decide which penalty is more of an issue. BTW, here is some great info on comparing the two here, read up very interesting stuff.

Ultimately, the performance experienced with the WC will depend largely upon how the production file system is laid out and its SavVol. Generally you can expect the same performance as with a read-only checkpoint as arbitrary as that sounds, but as a side note remember..creating, refreshing, restoring, or deleting a checkpoint can pause writes to the PFS for a few seconds. So plan accordingly for even the most simplest of operations.

To conclude, although writable checkpoints are not the be all do all to application/DR testing, they do provide an effective and storage efficient means to addressing today’s business and technical perplexities. For more information, please see the links below. And one more thing…Happy Snapshotting!

–Light Reading–

Using SnapSure on Celerra

EMC Celerra Version 5.6 Technical Primer:File System, Application, and Disaster Recovery Testing using Writable Snapshots (Checkpoints)

Here is a quick video I did on the >FREE< Flex Profile Kit. I knew little to nothing on this framework until I started doing research for this video, but have been blown away with what it is capable of. Generally, VDI seems to be the most natural environment for this but let me know what you think…