To highlight a bold new feature brought to the Celerra line, the following are relevant points that may be questioned during an average “what does what” 3D conversation.  And of course all of this is spelled out clearly here, so don’t take my word for it. Onward…

You know its funny, never say never in this industry.  Here I shunned the use of 3D on primary storage but find myself completely drawn in by such a use case.NetApp has obviously long been the pacesetter in defining this trend and for that I commend them. But what makes their solution any better than the next? Always on/scheduled, compression/no compression, fixed/variable/file-level, file system size limitations, operability with existing feature sets, etc..all are approaches and design considerations that must be addressed and more importantly must mesh in your environment. So that being said any comments pertaining to why one way or the other works better compared to another (based on your experiences or testing) would be greatly appreciated.

• DART Code needed - 5.6.43 or later. Free upgrade assuming your support agreements are up to date.
• CD (Celerra Dedup) is an “always on” function as opposed to scheduled
• Celerra Replicator V1 in play for a file system? then no dedup. Dedup on a file system? Then no replicator V1. Of course V2 lifts these restrictions and implies the destination Celerra is also running the above DART or later.
• CD  will not process files less than 24KB.
• A filesystem enabled for dedup must have 1MB worth of free space
• CD minimizes CIFS timeouts by not modifying deduped files that are over 200MB. This however is the behavior tied to CIFS and not NFS.
• It goes without saying that dedup has the potential to negatively impact the system as a whole as any dedup solution. Although the Celerra does throttle this process once the processor (X-Blade) hits 75% usage to mitigate this risk. Additionally, dedup’s nature is to focus on files that have not been accessed recently, typically based on the following criteria:
  • Last accessed/modified time
  • min/max size
  • file type
  • dir name
• Max volume size with 3D is 16TB from the NX4 all the way to the NS-G8
• Configured on a per filesystem basis all GUI based with one click enablement
• iSCSI? No Dedup. CIFS and NFS only. No block.
• Deduplication in the Celerra sense equates to file level single instance storage and compression (greatly simplified) This ultimately extends the reach of available space savings beyond what 3D can provide alone, presumably up to 40%. Both of these methods were chosen to decrease storage consumption while minimizing resource overhead.
• Read operations do not require the dedup’d file to be decompressed on disk, only in memory
• SHA-1 hashing is how identical files are detected and used as part of the single instancing process
• NDMP Volume Based Backups does NOT cause an inflation or reduplication of dedup’d data as this operation occurs at the block level. However non-VBB NDMP backups that occurs over the network are reduplicated.
• 3D immediately releases blocks within the PFS (production file system). But in doing so, these released blocks get copied to the SavVol. The Celerra, by default, will terminate any 3D activity to prevent automatic SavVol extension.
• Full Celerra functionality support for the following: Celerra Manager, SnapSure, Replicator, NDMP, FileMover, and FLR

Related articles by Zemanta

Celerra shop? Excellent.  You’ve taken the necessary steps to invest in the most unified, performance driven platform on the market today. Now what? Well in most situations tweaking your array is not necessary, those fine individuals at EMC know what configurations are appropriate for specific types of access, read/write profiling, and plan accordingly. But there are a few optimizations that are worth a look and most pertinent to ESX.

So here is the performance study from EMC that details such findings, of which I highlight below. The uncached and prefetch recommendations are two I targeted here, back in September 2008. The others? Well lets say they are a bit more obvious.

Recommendation #1: Use the uncached option on Celerra file systems provisioned to the ESX Server as NAS datastore. This can improve the overall performance of the virtual machines. This should be considered particularly with random and mixed workloads that have write I/O.

Recommendation #2: When using random and mixed workloads without replication, consider disabling prefetch on the Celerra file system. This can improve the overall performance of virtual machines provisioned with Celerra NFS storage.

Recommendation #3: Align virtual machines that are provisioned with Celerra iSCSI storage as it can improve the overall performance of the virtual machines.

Recommendation #4: Do not align virtual machines that are provisioned with Celerra NFS storage because this may degrade the overall performance of the virtual machines.

Recommendation #5: Consider using an iSCSI HBA on the ESX Server with sequential workloads with Celerra iSCSI storage. This can improve the overall performance of virtual machines with such workloads.

Unification, confluence…the time for convergence is now.  Timely, you know? Multiprotocol and Multi-feature arrays are hotter than a stolen tamale, and why wouldn’t they be. CIFS, iSCSI, FC, NFS, 3D (dedup), and replication (of some flavor) just to spiff the fire all shelled within in a single iron frame. Its quite poetic if you ask me.

So what's igniting the fire for NAS and its tremendous growth? Strategic SMB focus and the right partnerships in the channel according to CRN (And by the way, check out below who the 2008 Enterprise Storage Champion is). If you look closely I have hinted at what product has fueled the top placement…loving it..answer here ; )



So what was recently announced? Honestly its dizzying what new features and efficiencies have been cooked into the refreshed celerra line. So lets cap on the most interesting ones, ok?

Cappy #1-Scalability People

NS-120-Drive count upped from 90 to 120. Other than that its functionally equivalent to the NS-20. Although I should say, if it isn’t blatantly obvious the backend for the entire line is the now the CX4.

NS-480-Drive count upped from 240 to 480. Data mover count jumps from 2 to 4 and the usable storage capacity teeters from 128TB to 192TB per system.



NS-960-Bring it..Drive count upped from 480 to 960. Data mover count jumps from 4 to 8 and the usable storage capacity? A whopping spread from 384TB to 760TB per system.

NS-G8-Clever name…2 to 8 blades. Can front end Clariion or Symmetrix. 896TB max usable IP storage capacity per system.

Cappy #2-Celerra 3D, no not that 3-D

Oh this is too sweet..now you have no reason to buy from NetApp : ) Although a bit late to the game in offering, EMC has moved forth with 3D on both primary and archived file systems on the Celerra line. The techniques used are a combination of File-level dedup and compression. The goal here was to maximize storage savings while keeping resource overhead at a minimum. Furthermore, both are made possible by using mechanisms found within EMC Recoverpoint’s compression engine and EMC Avamar’s file identification algorithms. 

Dedupe as positioned by EMC has a number of other benefits as opposed to their competitors, here are a few that light up the sky…

• One-click checkbox enablement of dedup within Celerra Manager


• File and directory level granularity


• Always on, configurable based on file size, name, age, etc.


• 16TB FS size across entire platform


• Automatically throttles CPU when it reaches 75% on X-Blades

Also, looking for a way to calculate potential dedup savings check this out.

How about a quick demo of dedup in play, check it here..

Quick visual of what’s in store?



 Cappy #3- File Level Retention

This is optional DART code functionality that  adds WORM capability to CIFS and NFS. What you get is the ability to prevent file level modification (changes or deletions) based on specific retention periods. There are actually two flavors of  FLR.

FLR-E for Enterprise level, lacks SEC level compliancy requirements

OR

FLR-C for Compliancy or SEC 17a-4(f) level requirements.

Here is a quick graph to described the workflow behind this feature…  



Well there you have it, more engineering ingenuity at its finest, more to come on this purpose built luminary for sure.

For more info follow up here…

Refreshing Celerra: New Models + New Features (Dave Graham)

Unified Storage: File System Deduplication (Storagezilla)

 

 

 

Related articles by Zemanta

For those Celerra based CIFS servers that receive "Unable to join CIFS Server to Active Directory / Domain Controller" during domain additions, or any of the following, a simple fix exists..

• server_x:201:2119:E: server_cifs server_x -Join compname=mycifsserver domain=mydomain.com admin=administrator: failed to complete command


• LDAP: 3:  Ldap bind: LDAP server is down
  LDAP: 3:  LdapClient::connect: error message: Server down, (error code 81)
  SMB: 3:  DomainJoin::findServer: Unable to contact any domain controller in domain mydomain.com
  ADMIN: 3:  Command failed:  domjoin compname=mycifsserver domain=mydomain.com admin=administrator password=********************** init

Beyond the normal fat fingering of a password and incorrect domain or DNS settings the above commonly is revealed when the DC you are pointing to has NIC teaming or Load Balancing enabled. What follows is a brief example noted in EMC Primus #emc150780....

"In the example below, there are two NIC's in the team on the DC: the team "leader", which has a MAC address ending in 5c, and another team member which has a MAC address ending in 5b.

1. The Data Mover gets the IP of the DC from the DNS server. That IP resolves to the MAC address of the primary, or leader in the NIC team, which is 5c.


2. The Data Mover sends the SYN to the DC.


3. The NIC team "leader" and the teaming software will then assign a different NIC, 5b, in the team to respond with a SYN,ACK to the Data Mover.


4. The Data Mover then replies to the SYN,ACK with an ACK.


5. The Data Mover replies with the ACK back to the same MAC address, 5b, that it received the SYN,ACK from. See the example below.

Data Mover (SYN)                                     -->               Domain Controller (5c MAC address obtained from DNS)
Domain Controller ('5b') (SYN,ACK)        -->               Data Mover
Data Mover (ACK)                                    -->               Domain Controller (5b)

Here are the retransmits in the tcpdump. The Data Mover doesn't get a response from this point onwards from the Domain Controller:

Data Mover (ACK)                                    -->               Domain Controller (5b) Retransmit
Data Mover (ACK)                                    -->               Domain Controller (5b) Retransmit
Data Mover (ACK)                                    -->               Domain Controller (5b) Retransmit
Data Mover (FIN,ACK)                             -->               Domain Controller (5b)

The Data Mover finally gives up waiting for a response and sends the FIN,ACK to end the conversation to the Domain Controller.

The reason this has happened is because MAC address 5b is receiving packets from the Data Mover and does not know what to do with them. As far as the Domain Controller is concerned, the Data Mover should be talking to MAC address 5c. MAC address 5b ignores the packets received from the Data Mover."

To rectify such a problem, simply run the following command on the data mover where the CIFS server exists..no reboot required.

server_param server_2 -facility ip -modify reflect -value 0

You be the judge. Great video supporting the casualness of celerra installs...

[youtube=http://www.youtube.com/watch?v=sZH7zCrustc]