As an infrastructure manager I used to get annoyed at vendors who would tell me about products that were the best at solving problems I didn’t have. Some of those products solved problems that nobody has. I refer to this behavior as vendor noise, and it really frustrates me.
The industry as a whole seems to be becoming more sensitive to vendor claims (BTW, I have no data to back this claim!), but I still see an awful lot of vendors claiming that: “you need this feature”, rather than the outcome the feature delivers.
For an example in the consumer world consider the Apple MacBook Pro and its “Unibody Enclosure”. Amazing! You definitely need a frame built from materials found on fighter jets that can fit a big battery and keep the overall device structure rigid and robust.
Or do you?
Actually what I *need* in a laptop is a good battery life, lightweight for portability, and strong enough such that it doesn’t break if I bump it the wrong way.
So what just happened to me? Apple convinced me with their noise that I needed “features” that they had, and they mapped their features to needs that I could relate to (good battery, light weight, strong). If I went to another laptop vendor and asked for a Unibody enclosure because I need it, they would consider me a common sucker.
Funnily enough, this scenario happens in the enterprise IT world all the time. Many vendors convince people that they need features in a ploy to sell a product. IT professionals are forgetting that they only need the feature to address a deeper problem; a problem that can likely be addressed by different features as well.
So how do you know what’s real and what’s noise?
It’s actually very simple, work out what you need before you speak to a vendor about features, then tell them. They may try to change your need to match their product, but if you’re conscious of this, you’ll survive the ordeal and you will very soon learn which of your vendors are partners and which are leeches.
In the context of storage: Do you need storage efficiency? What does storage efficiency mean to you? Low cost per usable GB? Low cost per IO per second? Low cost per TB per floor tile?
Avoid the noise!
Travers
. Everyone started grabbing at cables, connecting systems, opening terminal sessions to devices, and just geeked out. We all got so excited it is actually quite funny looking back at it now.
Don’t Panic : Mirror Positions
What happens to a VM that is hosted on a VMFS datastore when you physically remove both of the mirrored drives from the array? Kernel panic/blue screen right?
What if you were replicating that LUN to another site using array based replication? Would the VM still crash?
Not if you’re using Symmetrix Remote Data Facility, Synchronous mode (SRDF-S).
Let’s rewind a bit. One of the main architectural attributes that distinguish an enterprise array from a mid-range array is the connectivity and cache model. In a midrange array you will typically see an active/passive controller from a LUN path ownership perspective, while an enterprise array provides an active/active controller model for because the front-end adapters don’t “own” the LUN per-se (Yes, I’m oversimplifying this a wee bit, but only to skip past this detail and get to my point!).
This kind of abstraction, much like the server abstraction provided by VMware ESX, is a key enabler for much of the genius that occurs in all shared storage platforms.
In the world of Symmetrix, a mirror-position is a device in the system that a segment of cache refers to. When a write occurs, it is acknowledged by cache, then the system will deliver the write to all of the necessary mirror-positions. If it is a “2 Way Mirror” (RAID1) it will write to mirror-position 1 (first RAID1 device) and mirror-position 2 (second RAID1 device).
When you create a RAID1 configuration on a Symmetrix DMX or VMAX the system refers to it as a “2-Way-Mir” (two way mirror). That is the systems way of saying that each cache segment responsible for staging IO within this volume has two positions to write to – each of which are on a physical device (this architecture allows RAID1 volumes to stretch far beyond the capacity limits of a single drive – neato!) (By the way, with Virtual Provisioning technology implemented in the VMAX, the virtual pool’s device is the mirror position, and the pool takes care of RAID – the idea here is still the same though).
What if you wanted a “3-Way-Mir”? Well technically, that’s what SRDF-S is; it’s a three-way mirrored volume. The first two mirror positions are local devices, and the third is a device on the remote array.
So what happens when you simultaneously remove both of the drives in a two drive two way mirror with SRDF-S configured?
Your VMs stay online. Read latency will suffer as reads are now being serviced by the remote site, but writes are the same speed because they were limited by the inter-site latency anyway.
How awesome is that?