**** Go here for new version of UBER VSA **** What is better than UBER? UBER version 2. It has only been 19 days since the original release of the Celerra VSA UBER edition for the masses. The response has been overwhelming and encouraging. And out of that appreciation I am excited to present the Celerra VSA UBER V2 (version 2). It has a host of new features and now features the combined input of the vSpecialist team to put the shine on it. If you are not familiar with the original feature list with the first UBER version, then go here first. Here are the new features and enhancements in UBER Version 2: Even shorter initial setup Better network configuration. Removal of old style Control Center config from original VSA (Thanks to Eric Hollis & Kevin Z for help) Completely automated addition of storage. You heard that right… If you want to add more storage simply shutoff the VSA. Add as many hard drives as needed and turn back on. The VSA now detects the new VMDK’s, partitions, formats, mounts, performs Clariion configuration, and adds to storage pools. Gone are the days of manually having to configure. See video below for demo. (This by far was the biggest request) The VSA now includes a Rapid Configuration script for setting up CIFS, NFS, and Replication between 2 VSA’s. This script will accelerate the creation of a baseline working set of VSA’s. We highly recommend you use this after becoming familiar [...]
This post is inspired by this outstanding post by Chuck Hollis (@chuckhollis) and this one by Chad Sakac (@sakacc). Chuck mentions my favorite way to summarize what virtualization encompasses: “abstracts logical from physical”. What makes abstraction critical is that it breaks historical dependencies that develop as technologies are built over time. I have said this phrase hundreds of times over the last four years of my career and in my mind it translates into an incredible paradigm shift in data center approach over the next ten years. A good example of this is the push to service-oriented architecture design principles in the enterprise application space over the last decade. The whole gist was to enable business functionality to achieve independence and agility by breaking hard coded dependencies to platforms and systems. A loosely-integrated system can provide value to multiple business units by removing the overhead of inherited designs. Any ability to move quickly to market with business features brings competitive advantage. In simple terms, removing boundaries opens more opportunities. Virtualization is the same approach with the end goal of the four food groups (CPU, memory, storage, networking) becoming commodities that can used as needed and where needed. The status quo has been large CapEx investments in infrastructure where efficiency was limited by the boundaries of the physical needs and the return on labor cost to optimize. Even with a large team invested in tuning and sizing, the organic growth of the business can waste resources quickly as usage patterns change [...]
Image via Wikipedia Many times I have seen situations where an application or process grows incrementally to a point where it is no longer able to meet it’s SLAs (whether official or imaginary). The cause of this can vary but is usually: Overworked/Unbalanced teams - Too much effort dedicated to new feature-add and not enough to technical debt Poorly planned systems – Designs for immediate need without taking into account needs for things like instantiation or scaling of decoupled components. Poor maintenance/understanding – Lack of knowledge or effort to tune application/process to more effectively use resources. This can exist in both the application and infrastructure groups. Usually the performance degradation is known early on but accepted because the business users are not making a big enough stink; or at least not big enough to reduce the drive for new features. In addition, lack of monitoring and baselining of application performance is a critical problem. It eliminates the ability to effectively plan for growth and manage team resources. Eventually the impact reaches a point where someone significant (business executive) resets priorities to fix it (technical debt due date). Many options will be evaluated immediately, from trying to buy time by tuning components to finding misconfigurations. However if no easy answers exist, it usually comes down to two options. Optimize the application/process (Fix the code) Scale the application/process with faster hardware (Throw metal at it) Both of these options impact the same core factors: time and money. Depending on what time of [...]