Seems that a main use of the simulator is testing replication.
I have configured replication between a real NS20 and a simulated one. Everything is hosted on the real one and pushed towards the virtual. The problem I have is that the nas_replicate command does not work on the virtual. By 'not work', I mean that it never returns.
Everything works fine on the production (real) Celerra and data seems to be replicating fine. The interconnects validate properly from both sides.
I'm at a loss because nas_replicate -l returns almost immediately on the real box. The VM isn't consuming much RAM (435 MB out of 3 GB free), the CPU is under 20% utilized.
Does anyone know what this command is doing under the covers so I can figure out where the problem is?
Thanks!
FWIW, running 'ps l' shows that the process is sleeping and apparently waiting on something from the kernel..
I've seen some problems with replication lately. Let me first make sure of some things:
Is the MAC address of eth0 on both Simulators different? Does the MAC addres "agree" with the storage ID on both Simulators (the storage ID is derived from the MAC address on eth0)?
If those are ok, there could be some other problems.
I am replicating between a physical NS20 and the virtual Celerra, so the MACs are different
Yes, the storage ID on the simulator agrees with the MAC.
I was using the single DM version of the simulator. When I get a chance, I'm going to try again with the dual DM version. There is nothing in the logs to indicate that the command is doing anything -- I wondered if it was going out to query the second DM and never returning (?).
I know it isn't supposed to be there, but I was getting messages from BoxMonitor that both interfaces to the slot containing that missing DM were down.
I downloaded the single DM version from Powerlink, configured the storage as I needed it for replication, configured replication (iSCSI LUN), made sure everything synced up...
# Add new storage 1. Add new VMDK 2. New LUN comes in as /dev/sdb, partition it with fdisk 3. Format new partition as ext3 with mkfs.ext3 5. Add to /etc/fstab 6. mount -a
# Initialize the Clariion /nas/sbin/setup_clariion -init #if needed, update /nas/symapi/config/clarcnfg
#reboot the VM to see new storage # .. or could reboot just the DM w/ server_cpu ALL -reboot now reboot
#Fix hostname Add the following lines to /etc/sysconfig/network HOSTNAME=phx-lab-ns20v DOMAINNAME=itplab.local
#Fix the cshosts file /nas/site/cshosts replace 'localhost' with the hostname
#Configure NTP Add timeserver (172.16.20.15) to /etc/ntp.conf /etc/ntp/step-tickers
ln -sf /usr/share/zoneinfo/US/Arizona /etc/localtime chkconfig ntpd on service ntpd start
# create the cge2-eth2 binding / interface and configure it /opt/blackbird/tools/configure_nic server_2 -a eth2 reboot server_ifconfig server_2 -create -Device cge2 -name cge2 -protocol IP 172.16.254.78 255.255.255.0 172.16.254.255
#configure DNS on the datamover server_dns server_2 itplab.local 172.16.254.30 -option start
#Check status of LUN and replication (from target) server_iscsi server_2 -lun -info 1 -target phx-lab-ns20v-2
#check on replication (from source -- this works on the PHYSICAL source) nas_replicate -info SRM_LUN01 |grep Current watch -n 300 "nas_replicate -info SRM_LUN01 |grep 'Current .*Rate'"
Could you please collect support materials and put them on our ftp server (ftp.emc.com). Log in as anonymous, cd to /incoming and create a directory (CSrepV2) and put the support materials there. Post here when that is done so we can get them.
Will do. The single DM VM is currently offline as I work on the two DM VM. That one seems to be working. I just need to present some more storage to it to see if that breaks it. I will fire up the single DM one and pull the support info later this week.
Almost forgot -- whenever I run the nas_replicate -l command, I get messages on the console: "Protocol 0000 is buggy, dev eth2" and it repeats a total of 7 times per run of nas_replicate.
jimg5
1 Rookie
•
90 Posts
423
0
Posted October 12th, 2008 14:00
I've seen some problems with replication lately. Let me first make sure of some things:
Is the MAC address of eth0 on both Simulators different?
Does the MAC addres "agree" with the storage ID on both Simulators (the storage ID is derived from the MAC address on eth0)?
If those are ok, there could be some other problems.
Let me know what you find out.
Jim