Rooey wrote:
Guys,
Can you give me collateral that could help me doing a comparison between 3par Remote Copy and Peer Persistence with SAN Storage Virtualisation technologies such as VMware VSAN/Datacore/etc?
In the context of a vMSC deployment and non vMSC deployment.
Roo
Roo,
I've actually been thinking about this particular topic for quite a long time, and I wanted to thoroughly think it over before I responded to your post so that I could do it justice.
First, let's think about the whole vMSC vs traditional replication. Personally, I previously implemented a "vMSC" (such a thing was not a thing at the time, but I built a similar concept) using merged fabrics, stretched clusters, and HP EVA's with synchronous replication. The only difference between what I built, and the current "vMSC" (which again was not a thing at the time), is that the vMSC has automatic failover of the arrays, where HP EVA's didn't (and don't) do that. When I replaced the EVA's with 3PAR, I split the fabrics, switched to asyncronous replication over IP, and set up dedicated clusters in each site, and use SRM to orchestrate failover/failback.
Why? A number of reasons. For one, keeping a vMSC optimal is a MAJOR PITA. It is very easy for a VM to end up in one site, and it's storage to stay in the other for instance. This can lead to major performance issues depending on the distance between sites. Which brings me to problem number 2. I operate a private fiber ring. My two data centers are about 4 miles apart by car. In terms of the fiber run, I had about 9km in one direction around the ring, and about 60km in the other direction. Because of the nature of fiber, I was unable to obtain a 4Gbps FC SFP that would shoot 60km, and in order to do that I would have had to use active DWDM (Like a Cisco ONS15454 at the time) which was cost prohibitive. Which meant that even though I had two fabrics, both fabrics used the same fiber path, which means a single point of failure. NG. So now that I'm using IP instead of FC for my replication, this is no longer an issue, which means even though the speed is lower, my replication traffic is now
more robust, not less. Which brings me to my next point, networking. I don't know how much anybody here gets involved in networking, but I am deeply so. In this case, I have to agree with Ivan Pepelnjak (if anybody here follows him), that a VLAN, no matter how many big chassis switches you're using, represents a single failure domain. Further, layer 2 data center interconnect (DCI) actually makes things more complex, and more failure prone, not less. So now that I've gotten rid of all that (thanks to the ability of SRM to change the IP addresses of VM's during failover), my network is more stable, less complex, and easier to manage.
The long and the short of it regarding vMSC: It is hideously expensive to implement, hideously complex to operate, and in my humble opinion, quite failure prone due to the complexity, and the networking hacks (L2 DCI namely) that you need to implement to make it work. And what do you get in return for all this? The ability to migrate a VM from one DC to another, and a lower RTO. This is a case where you NEED to persuade your bosses to be realistic when it comes to their RTO's, and follow the sun VM mobility is frankly not all it's cracked up to be. Believe me, I've been to the mountaintop. It makes for cool demos, is impressive to the pencil pushers, but it literally never provided any benefit to my operations.
Now, let's talk a bit about hyper-convergence (AKA VSAN, EVO:RAIL, StoreVirtual VSA, Simplivity, Nutanix, HP 200-HC, etc etc). Hyper converged architectures are neat in that they provide all your compute, storage, and even networking depending on how you do it, in one neat box. The problem I have with hyper-converged stuff is that A) It is in some cases EXTREMELY expensive (I'm looking at YOU simplivity, nutanix, and HP 200-HC, all of you cost nearly or over 100k for a "brick"). The other big problem that I have with hyper-converged stuff is that it doesn't scale correctly. Now, if anyone on here has been drinking the kool-aid, please refrain from flaming me. I didn't say it doesn't scale, it does, I said it doesn't scale correctly. Let's look at the specs of an HP CS240-HC for instance. It includes 128 GB RAM per node, dual 8-core CPU's per node, 2x 10GbE and 2x 1GbE per node, and 28.8 TB shared storage (RAW. Usable is probably closer to 14-18 after RAID, ETC). let's say usable 18. Let's compare that to my current storage environment which includes 60 TB. That means I would need to scale out to 4 "bricks" to meet my storage needs. In that case I would be looking at a total of 32 ports of 10GbE, 32 Ports of 1 GbE, 2 TB of RAM, and 16 nodes. Holy overkill Batman!!! Why in the hell do I need all this compute? It is frankly, ridiculous. So my big beef with packaged hyper-convergence is that the specifications aren't aligned, and I end up with WAY WAY WAY more compute than I need just to get the storage that I need. Now you COULD build out your own "hyper-converged" platform using rackmounts, external storage shelves, and HP VSA/VMware VSAN, but if you're going to do that, it's honestly less expensive and less complex to just buy a real SAN, especially in the case of VMware VSAN which requires multicast to function properly, and a lot of networks DON'T implement multicast well at all. Plus, once you get into multiple sites, you're still using SRM, otherwise all the caveats I mentioned as it relates to vMSC apply.
Moving on to SAN virtualization!
This would be the more traditional use for DataCore SANsymphony. Some others here would include Netapp V-Series, HDS USP-V (which I think is called something else now), LSI had one, HP SVSP (R.I.P.), EMC vPLEX, blah blah blah. The story here is you put the hardware or software (depending on the vendor) in front of your arrays. Present the array storage from the array to the san virtualization appliance, and the hosts talk to the san virtualization solution. The thing I have against san virtualization is that I don't think I need it. At the end of the day, in my opinion, if you make good choices regarding your arrays, purchase well, and design well, you're not going to end up with a fractured environment with isolated silo's of storage wasting your space. So this is a classic case of evaluate your options well before you purchase, create a coherent, well-designed, well-engineered infrastructure plan, and implement that plan. If you do that, then san virtualization doesn't provide really any benefits to you.
Hope that all makes sense. Please don't flame me. These are my opinions based upon my 15 years of IT experience.
Anybody else have any thoughts?
EDIT: Holy wall of text! Sorry guys!
