Log in


Tags » ‘EMC’

Robocopy fails when coping to EMC Celerra

Categories: EMC Robocopy Storage
March 25th, 2010 by Scott

A colleague of mine sent me this interesting issue he ran into during a migration to EMC Celerra.  Thought I would share.

The Problem:

If a file exists on both the source and destination, by default Robocopy copies the file if the two files have different time stamps or different sizes. However, Robocopy fails to copy only modified data from an NTFS volume on a BXL server to the Celerra.

What was happening is that when he was doing a Robocopy with the /mirror or /E /purge options the Robocopy always found the source file newer then the destination file on the Cellera and copied it, even if a Robocopy was run a minute earlier. 

The reason this was happening was due to a variation in the EMC implementation of CIFS.  The NTFS date and time stamp is a 64-bit variable, which DART doesn’t deal with.  So Celerra uses the FAT timestamp format instead. 

The Resolution:

To get around this issue it is recommended to use the /FFT switch in RoboCopy.  /FFT switch stands for Fat Format Timestamps.  For more information on Robocopy switches go to http://ss64.com/nt/robocopy.html. 

In addition, I parameter can be set to make Celerra round up the time to the nearest second. This makes robocopy believe the files on Celerra have newer time and therefore does not copy the files.

[nasadmin@Harrison ~]$ server_param server_2 -f cifs -i nanoroundoff –v
server_2 :

name = nanoroundoff
facility_name = cifs
default_value = 0
current_value = 0
configured_value = 0
user_action = restart Service
change_effective = restart Service
range = (0,1)

description = Roundup the time information to the next second detailed_description Cifs protocol is able to set time using 64 bits value (time set in 100th of nano second since January 1, 1601 in Gegorian calendar. In Dart we do not have this granularity. This means time value read after set could be different (older). This parameter when set, is roundup the time value to the next second in order to not confused some application if the file is olderthan the time application has stored localy as the last update. Typical

application is profile storage on the DM. Setting this param improve performance at log off time, as the application will not try to flush again profile information seeing the last modification date is not older than the time info it has stored localy as the last modification date.

[nasadmin@Harrison ~]$ server_param server_2 -f cifs -m nanoroundoff -v 1
server_2 : done

Special Thanks to Keith for sharing this interesting tidbit.

Tags:
2 Comments »

Disappearing NetApp LUNs when moving to EMC?

Categories: EMC Exchange Server Microsoft Related NetApp Storage Windows 2008
March 10th, 2010 by Scott

I was at a client site yesterday in the process of moving them off a NetApp Storage array and onto EMC Storage.  My colleague and I ran into a very interesting problem and have no idea why it was happening.  If anyone has any ideas please, do share.

The setup was two Windows 2008 Servers with Exchange 2007 CCR split between two datacenters.  The servers were using Snap Manager for Exchange and Snap Manager.   There were four LUNs from the NetApp presented, three for databasae and one for the logs.  The LUNs were attached via iSCSI. 

Since the Exchange CCR environment was running in the HQ Datacenter we started by getting the EMC agents installon the the Server in the DR Datacenter.  The iSCSI LUNs from the NetApp were presented via Drive letters, there were four, three for the database and one for the logs.  If you’re not familar with deploying EMC apps the first app to deploy is the EMC NaviHostAgent.  When I installed the agent the server requested for a reboot.  This is where things got really funky.  When the server came back from a reboot the iSCSI disk drives from the NetApp were gone!  No idea why.  We scratched our heads and couldn’t figure out what happened.  According to the NetApp management console the LUNs were presented.  When we tried to remap the LUNs via Snap Manager it would state that the volume was already mapped to a drive on the server, but the Server could not see them!  This was odd.  We backed out the EMC NaviHostAgent and the LUNs reappeared but the drives were off line.  I brought the drives back on line and everything worked again.

We then started by reinstalling the EMC NaviHostAgent, no reboot was required this time and installed the EMCPowerPath application.  When we came back from a reboot the drives from the NetApp were off line again, I brought them back on line and had both the EMC and the NetApp storage provisioned.  Great, this is nice.  We presented the EMC LUNs as mount points and started up replication again from the HQ Exchange Server.  Once replication was caught up moved the cluster to the DR server to begin the same process on the HQ server thinking we had a fluke.

Well, the exact same thing happened!  When we installed NaviHostAgent no reboot was required.  We then installed PowerPath, Had to reboot the server and the NetApp LUNs vanished!  WTF right?  Not again!  We did the same procedure I mentioned above, removed PowerPath, removed NaviHostAgent, rebooted the Server in HQ.  When it came back the NetApp LUNs were gone!  No drive letters, no detection.  Checked the iSCSI Initator configuration, and it was perfect, it was seeing the iSCSI targets for both the NetApp and the EMC.  From the NetApps perspective the LUNs were provisioned.  What in Windows 2008 was preventing the LUNs from being seen?  I checked the Network settings via IPCONFIG and there was a “Local Area Connection 9″ that was there along with a Prod network and a iSCSI network.  Looking at the network configuration only two NICs were active for the machine.  No idea where the third NIC was coming from and by this time I was too tired to try to figure it out.  Anyone out there have thoughts on that one? 

Anyway, after troubleshooting for about 5 hours between the two servers I proposed a Plan B.  Since we had the NetApp storage (Thank God) and the EMC storage on the DR server I could create new Storage Groups and Databases on the DR server to the new EMC LUNs.  Create new EMC LUNs on the HQ Exchange Server to reflect what was in DR and let CCR take care of the rest.  Once the Storage Group and Databases were created I enabled replication only for the EMC Storage Groups (since the NetApp was off line on the HQ Server I couldn’t re-enable CCR) and started moving mailboxes.  This worked fine, disaster averted. 

I was glad Plan B worked, but more complexing is why did the NetApp LUNs disappear?  Anyone have an idea what may have happened with it?  Again this was a Windows 2008 Server with Exchange 2007.  The iSCSI network was correct, the NetApp was presenting the LUNs, when going into snap manager the LUNs said they were mapped.  I tried to do a rescan of disks, nothing.  Tried to take away the LUN and remap the LUN via NetApp management console and nothing worked.  The Windows Firewall was turned off, disabled AV Software, nothing worked.  Nothing would bring those LUNs back to the Windows 2008 server.  Has anyone seen anything like this?  Anyone have an idea on what happened?  Please do share!

Thanks,

Tags:
No Comments »