My world of Unix and Storage

Guys, Have you ever thought of automating the RP replication status and send status via email or post it to any reporting platform. Since the splitter impacts the VMAX FA's and there is an overhead of 13% on the utilization its good idea to see if the replication is driving the utilization of vmax FA. There are ways of pulling iops/read/write using symstat but its utilization (Director CPU utilization etc) which plays a significant role. As it crosses 80% we start seeing the increase in device response time. However, to measure FA utilization we will have to go through SMAS UI then pull out the reports. Its manual effort. But there is a way to automate it through REST API. You can get the details what type of objects are supported by pointing to : https://smc server :8443/univmax/restapi Coming to the point, getting recoverpoint consistency group status fully automated doesn't seems to be tough. Lets get through the steps. 1. Hash your SSH keys of the unix host to ...

With flare 30, pool is the new feature.and mixed pool is something totally new. You can combine multiple disk type in a common raid configuration and put it inside the pool. Enable auto-tiering and you are promised for a good performance by moving data across different tiers, the catch (its not real time, unlike VMAX). If you have totally unpredicted I/O then by the time it is decided to move the data above or below the tiers the I/O profile gets completely changed. In the next version of he flare, you can have disks in different raid type inside a single pool. What goes inside the pool, how the data is striped or written is something internal to EMC. The very idea is to give customers a very comfortable way of handling the storage leaving the pain to EMC. However, things are always not green as it looks. This works well when you have predictable I/O, you know what is going inside and when. What if the dynamics changes every now and then and you do not have control over the I/O ...

Version 3 maintains persistent locks. When a file system is unshared and shared back the locks are not destroyed so the state remains the same as if nothing has changed. Version 4 removes any state once the file system is unshared. All the state information is removed and any attempt to access the file again once shared back results in I/O error. The state does not change if it was unshared for some share option changes. Pseudo file system name space is maintained in version 4. In version 3 clients must request for individual mount of the entire exported share. Version 4 client gets a seamless view of all the exported file system. Path traversal was not allowed in version 3. Version 4 supports volatile file handles apart from persistent file handle. Server generates a unique file handle to every file. The file handle will change if the file is deleted and replaced by another file however will remain the same if server reboots or file was renamed. In oracle version 4 client con...

If you have to transfer a huge number of files lets say 50000 over WAN as one time data copy. Each of the files are of 3-4 Mb. We have couple of options like tar (will need extra space; unless you pipe it through ssh), scp (will be sequential), or use rsync. What I have done here, is used the --files-from option of rsync which specifies which files to transfer. On the source, create the file list 50000 lines (huge number) with ls > /tmp/a, then split the files based on line count. The line count is the deciding factor, if you have DS3 or higher make it smaller. Smaller line count will determine the concurrency or the number of simultaneous sessions that can start. split -l 1000 /tmp/a This will create 50000/1000 number of files starting xaa (you can decide the starting prefix, this is default) in the present working directory assuming its /tmp. Once done use the below either as single commands or put them in a script and start your job. nohup /root/rsync/bin/rsync -avz -...

Have you come across very silly problem while mounting NFS share. It just comes out of no where and refuses to go. Hours of efforts are wasted when we find the exact issue and seems like banging our head on the doors. I have summarized some of them, I hope you might be having your set of goodies as well. If you are getting an error like permission denied on the client server (90% of the issue falls here), then check in sequence what has to be done: 1. If the server has multiple IP address, it can no surprises. Do a traceroute from the server to the client and see which interface is being used to connect. Of course please check first whether the client is pinging or not. Once you have the interface detail, this IP will be used on the clients to map the network share. 2. See if you can resolve the client IP address using DNS, if you can then use dns name in the share access list on the NFS server. 3. If the client has multiple interface, then do a traceroute to the IP found in 1...

It started on Friday evening, yes Friday for all but not for me. Waiting for the EMC engineer to do a webex and configure our Recoverpoint appliance. Normally, if you are planning for DR site (big project indeed) for the last 6 months; how much time will you give for the lifeline to work yes, data replication. 1 month would be a decent guess, we have to do in 2 days. Don't laugh, very serious. We had done the rack and stack and all the cabling beforehand. It started around 9 PM and went on till 1 AM. All set for the testing. We just cross checked whether every IP is reachable or not. Viola, the wan IP was not pinging. It was on a different VLAN and was not in the firewall rules. Called up firewall engineer, didn't picked up the call; another same result. Escalated to manager, his phone was busy. called up project manager, he was furious (had to be). Escalated to Director, Information security and he confirmed will do something. Never ending wait started, finally around 3...