Just Be Better...

VPLEX is quite a unique beast in that there are numerous failure opportunities (as I like to call them) a host can walk away from unscathed. There are also some it cannot. I have gotten this question a lot lately and sometimes to the bewilderment of the intended receiver. As magical as VPLEX is, in a lot of cases failover is not automated which implies why VMware SRM integration is in the not so distant future. Below I have gathered information from a few sources that speak on the topic so just maybe we can all get it straight in our head. 

To preface that, I wanted to mention two types of volumes from a VPLEX Metro configuration, they are Distributed Virtual Device/Volumes and a Virtual Volumes with remote access. The two are very different. DVV’s as we’ll call them have two copies of the data, one leg at each site. The VV is only one copy of the data, at Site A or Site B, the remote access allows you to make visible that data to hosts at the opposite location to where the data lives. Meaning if you have a VV at Site A you can enable remote access so hosts at Site B can access that VV over the VPLEX transport. In this scenario, you could lose an entire array at Site B and still maintain host uptime because the data is being served up from Site A. 

With DVV’s, hosts are actually accessing their local leg for data access, but its done at the head level for the DVV. Considering the two volumes that make up the DVV are mirrored and identical, you could lose either volume, one or the other, not both, and still maintain host connectivity. Where it gets squirrelly is at the loss of VPLEX itself. In single engine scenarios your SPoF is now that single engine. Yes there are two directors within each engine, but loss of a single engine would most likely cause data unavailability depending on what site it failed at. There are a few ways around that. As I mentioned earlier by zoning all hosts at Site A to Site B’s mirror leg and providing standby pathing access, you could survive the loss of a Site A VPLEX engine. Models like such get incredibly complex, especially from a zoning perspective, so be careful out there. 

Consider the loss of each from the hosts POV, if there are other scenarios you would like clarification on let me know…

• VPLEX IO Module Failure – Consider the modules themselves. Front End, Back End and WAN COM. Assuming you have zoned correctly and all paths are redundant. You could lose multiple IO modules in a director and still maintain host uptime. 
• VPLEX Director Failure – Two directors themselves. Again assuming you have zoned correctly and all paths are redundant, you could lose a director and still maintain host uptime. 
• VPLEX Engine Power and Fan Failure – Both are redundant and could sustain a single loss on a per engine basis. 
• VPLEX Engine Failure – If you’re running a single engine to which all local hosts are zoned to. You will sustain a host failure. There are ways around this in a Metro config, by zoning all your hosts to the secondary cluster and utilizing those paths as standby’s is an option. 
• VPLEX Management Server Failure – Loss of a management server will not interrupt services to those hosts attached to VPLEX. 
• VPLEX Cluster Failures – All DVOLs have a detach rule (Third site witness aside). If you lose a Cluster (meaning all engines at one site), the winning site (that to which your detach rules are set to) will remain read/write assuming the cluster that failed was not that site. The other site will detach and IO will suspend if that site is not set as the winning site. In another wards, the hosts utilizing VPLEX storage from a site who’s cluster fails will loose access to its storage unless it is zoned to the other clusters DVOL leg.  
• VPLEX Inter-cluster Link Failures (WAN COM) - Traditionally VPLEX has no way of distinguishing between a cluster failure or a inter-cluster communication issue, detach rules are limited. Therefore, the non-winning site would always suspend IO until inter-cluster communications was reestablished. VPLEX Witness can distinguish between both scenarios, by accessing both clusters from a third location. In this case it can automatically resume IO on the non-winning site depending on the failure that took place. Otherwise this is a manual process. 

On Saturday I made my way to the first TEDx event in the Wilmington area, dub as TEDxHampstead. Hampstead is a small community north of Wilmington, to which a few of the cofounders and board members live. TEDxWilmington happened to be taken (damn you Delaware), hence the name. What has always grabbed me about the TED(x) movement is the notion of life long learning. Its part of the human makeup. Being highly social and curious creatures, we have a thirst for knowledge. This thirst has no age limit, although you’ll see below, perhaps the younger generation needs a little push…

The general flow of the event was as follows below. There are number of guidelines the charter has to adhere to to be legit. I imagine this will be the same format in your area if you attend. 

• Introductory Remarks
• TED Video
• First Speaker
• Break
• Second Speaker
• Third Speaker
• Break
• TED Video 
• Fourth Speak 
• Closing Remarks

The speakers themselves were very diverse which added to the appeal and interest. From a Communications Professor at UNCW to one of the cofounders of the Full Belly Project, all had a message and their experiences to bring. The audience, frankly, was sparse. Filled mostly with geriatrics, distinguished suits, a smattering of College ed’s and me (I certainly didn’t hit the crowd demographic) Maybe 30 to 40 with crew and speakers. After each speaker there was Q&A which rounded out each speech to around 20 to 25 minutes a piece. 

Formality’s aside, what brought me there was the speaker David Pell. I somehow stumbled upon his communal contributions, of which he humbly calls a Taste of Guitar, a few months ago. Which in turn led me to TEDx. His vision is to create a forum for young musicians to showcase their talents. Beginning and advanced musicians must audition to perform, preferably solo, with several songs premiered. This free event brought together elder musicians in the area who provided sound equipment and mentorship. Also as part of the event was a guest artist, usually someone of stature and relevance in the music industry, who would play and teach. 

So I guess at this point you are trying to make sense of the Subject of this post, “1+1 can be”. Pell’s speech was called “Being Creative” and drew upon his/this recipe for creativity. As a teacher, he explains, his students today are only interested in mimicking   their musical idols. The creativity to create their own music seems..well distant, unobtainable. Its with this background that he created “1+1 can be”. The idea is simple, when you look at this (1+1) what do see? Do you see the number 2? Or do you see ||||, or 1 > 1 or 1 < 1. All at their root are 4 lines. Think about how many different patterns and variations there are with 4 lines. Its with this, he explains how every element, every song can be broken down into its core elements. Its from these elements, creativity is alive. 

All in all, if you looking to have your soul stirred in this soul stew we call life, TEDx fits the bill. But if you are looking to be more creative, then focus on all the wonderful ways 1+1 can be…

If you’re like me the word DevOps may seem quite foreign, although it shouldn’t. To simplify the explanation, its nothing more than tighter collaboration and communication between Development and Operations within an organization. With this tighter collaboration,  comes greater efficiencies and reduction in risk when deploying software products and services. Development/Developers are paid change agents. Their job is to respond quickly to a businesses’ needs. Counter to that is Operations. Their job is to resist change for fear of instability. And their lies the problem. These different organizational structures, goals, mindsets and tools all lead to silos of frustration between both sides. 

What really put this in perspective for me is this article by Damon Edwards at dev2ops.org. The name of the post says it all, “DevOps is not a technology problem. DevOps is a business problem”. Without proper collaboration between all business entities, the process of a taking an idea from inception, to market literally becomes an up hill battle. This the very essence of DevOps, business enablement. Without the business, we’re all nothing more than glorified hobbyists. 

The 3 primary principles of DevOps as defined by Gene Kim, founder of the IT Revolution Press and Tripwire fame are as follows…

• Approach the performance of the system holistically. Never pass defection downstream. Local optimization at the risk of global degradation is never allowed. 
• Instantiate right to left feedback loops. 
• The third way and I will quote is, “…about creating a culture that fosters at two things:  continual experimentation, which requires taking risks and learning from success and failure; and understanding that repetition and practice is the prerequisite to mastery…The outcomes of the Third Way include allocating time for the improvement of daily work, creating rituals that reward the team for taking risks, and introducing faults into the system to increase resilience.”

Do you work in an environment where these principles are working?