One of the design challenges of any VMware vSphere deployment is customer specialization. When designing a deployment,...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
administrators must ask themselves how much they should change the default ESXi settings and take into account how default settings factor into general vSphere design decisions. There are a number of basic design elements to consider when running a vSphere implementation to ensure that it runs as effectively as possible.
When choosing which elements to incorporate in your vSphere design, there are some nontraditional options you should keep in mind that offer clever fixes to common problems. The one drawback to these resolutions is they are often beyond the scope of small businesses, which usually lack an in-house IT department. Instead, these organizations must rely on external expertise to design, implement and operate their vSphere environments.
Cautionary vSphere design tales for small businesses
Recently, a friend of mine encountered an issue when running a vSphere deployment: He ran out of space on the iSCSI array that held his VM estate. To fix this problem, he outsourced the design, implementation and management of the virtualization platform. To limit the cost of the platform, his provider used a thin-provisioned array with thin-provisioned VMs, but neither party appeared to have closely monitored the array's free space. This resulted in a catastrophic space issue and a multi-day, complete VM outage. While the immediate cause was a lack of monitoring, the failure suggested there was a larger issue. The level of design complexity was too high for the on-site expertise. Although thin provisioning VMs on thin-provisioned storage may be a quick fix for an enterprise with a team available to monitor VMs, VM storage and arrays, the strategy is a risky, cost saving approach for a smaller organization with only an IT generalist.
Thin on thin provisioning isn't the only dangerous vSphere design decision. I've seen a customer whose distributed switches for networking and virtual storage formats were all deployed from a remote office in a manner that adds risk. They were forced to carry out any and all ESXi host or storage VM maintenance tasks in a specific order with checks along the way. If they did not follow this specific order, the virtual storage would become inaccessible, making every VM -- including vCenter -- unavailable.
With due diligence, the customer might have been able to avoid failure, but disaster inevitably struck. Unfortunately, even though the customer in question had an IT team, the staff member making changes was unfamiliar with the design choices, the level of complexity and the operational impact, which led to further issues.
Reducing complexity to avoid failure
The best way to avoid this kind of failure is to keep things simple. You can accomplish this by offering basic ESXi and storage system configurations that meet the bare minimum of a customer's needs. Rather than incorporating complex vSphere design elements, opt for the most obvious choice for each decision. Only add complexity if it very clearly benefits the customer.
As an outsourced expert who designs deployments for small business customers, there are a few things I like to keep in mind. First off, remember that the IT you are designing is not the core of your client's business, so they will likely forget what you told them. Smaller organizations seldom have good documentation, but when it does exist, they generally have a difficult time locating it. The things the customer is responsible for should be obvious.
Next, bear in mind that when the customer has a problem, you might not be personally available to help. If this situation occurs, a colleague -- who is probably unfamiliar with your client -- will be called upon to assist them in your place. The best way to avoid confusion between your customer and colleague is to adhere to standard troubleshooting procedures.
Complexity is only acceptable if it does not require management. One example of this is a hyper-converged platform in which the complexity of storage management is hidden from the user. There are a lot of moving parts in a hyper-converged platform, but the complexity is self-managed by the human-computer interaction platform, leading to an overall simpler system to manage.
For small and medium-sized businesses, a simple, easy to understand infrastructure is a must. The more basic your vSphere design, the more likely you will avoid unnecessary issues and survive the loss of operation processes. If you still insist on adding complex features, make sure they are self-managing, like a hyper-converged platform.
Finding a better approach for vSphere troubleshooting
The basic elements of VMware vSphere
VSphere's cost savings and benefits for small businesses