Virtualization is sweeping through data centers of all sizes and, as it does, it introduces levels of complexity that organizations are ill-equipped to handle. To mitigate this, reference architectures are emerging as a technique to standardize which hardware and software are deployed, under what circumstances, and how it is managed.
As reference architectures proliferate organizations must make a choice: acquire a pre-packaged configuration or build one that matches their specific requirements. While not an easy decision, early evidence suggests that building a reference architecture costs significantly less and better meets their needs than acquiring a pre-packaged solution.
Reference architectures provide data centers a proven template solution consisting of specified hardware and software to helps ensure the physical infrastructure that hosts virtualized applications is deployed, managed and scaled in a predictable manner. This is why hardware providers are taking their existing solutions and offering them as a pre-packaged reference architecture.
However shortcomings with this approach exist as these architectures use products which:
- Are not optimized for sharing.
- Are difficult to integrate as each has its own management console and API
- Are built on the assumption that they will be used by one client
- Create silos of compute power and storage capacity
These factors create the exact opposite of what organizations want: an inflexible data center. A pre-packaged reference architecture may require a large up-front investment for their hardware and software that become more expensive to scale over time. Further, organizations limit themselves to a specific provider that must certify all of the components used in its pre-packaged solution.
This limitation of using a single provider continues to inhibit organizations as they look to implement readily available, cost-effective technologies like CPU, memory, network and storage. These are needed to handle the data and storage growth that virtualized environments create as well as to take advantage of compression and deduplication technologies that optimize storage capacity.
However using a pre-packaged reference architecture these technologies may not be available as soon as an organization needs them and then when they are available, come at a price premium that puts them out of reach.
To avoid these drawbacks of pre-packaged reference architectures more organizations are looking to build their own. These offer the predictability and scalability that organizations want but without the pre-packaged lock-in or price premium. Further, building a reference architecture frees organizations to capitalize on readily available memory, processing and storage technologies more cost-effectively.
The caveat to organizations building their own reference architecture is that it is only economical and practical to do if it can be effectively managed. An ad hoc deployment of these technologies without a plan to manage them creates challenges that are even greater than the pre-packaged approach.
A build-your-own strategy therefore demands that organizations introduce the right mix of technologies into their data center infrastructure. To do so, organizations must thoughtfully deploy such a solution by beginning with a proof of concept. Genesis Hosting is one example of a company that has already done so.
Cloud hosting provider Genesis Hosting looked at both pre-packaged and in-house reference architectures as a means to build out its data center infrastructure. In examining them Genesis found that an in-house reference architectures provided it with the flexibility it needed, significant technology advantages over pre-packaged reference architectures and a more predictable pricing model.
Genesis early-on recognized the pitfalls of ad hoc so all new new hardware and/or software it considers for use in its data center must satisfy two criteria. They must demonstrate a technology advantage over competitive products and provide well-documented APIs.
Cutting edge technology is important to Genesis Hosting as it seeks to maintain its competitive edge but so is managing its infrastructure. So all solutions that Genesis considers for use must offer APIs that its management software can call before it qualifies as a candidate for use in its data center infrastructure. However assuming hardware and/or software meet these two criteria, Genesis then subjects it to a proof of concept.
It was NEC’s servers, Ethernet network switches and storage coupled with their APIs that recently led Genesis to do a proof of concept. NEC hardware was tested with the following:
- Blackball Search-in Software
- Nexenta storage software
- QLogic FC switches
- VMware vSphere
To safely test this mix of hardware and software, Genesis put it into a pseudo-production environment, virtualized the hardware and ran simulated production workloads against it. During this testing period Genesis also verified that its own management software could call the NEC’s hardware APIs to test the depth of their capabilities and feature functionality.
During this proof of concept Genesis measured how well NEC responded to Genesis’s requests for information about their products and technology. In this particular test, Genesis wanted access to the NEC product managers to gauge how candid they were in discussing what NEC’s equipment could and could not do.
While Genesis Hosting’s CEO Eric Miller was pleased with the performance, stability and robustness of the NEC hardware and software, NEC’s candor about what it could and could not deliver were equally pleasing to him. Genesis wants a reliable platform for hosting its customers’ applications and prefers a known quantity. Miller says, “NEC’s proven features and known limitations are better than promised features and untested capabilities of other solutions.”
It was what Genesis learned about the performance of NEC’s hardware coupled with the ability to access and manage its hardware from the proof of concept that led Genesis to ready NEC for use in its production environment.
Genesis Hosting’s high interest in the robustness of NEC’s equipment was directly tied to how it allocated hardware resources in its data centers. Genesis Hosting creates a virtual data center (VDC) within its physical data center for each of its clients. Each VDC can access and use any physical resource in the data center so long as the underlying hardware is both virtualized and addressable by Genesis Hosting’s management software.
To use NEC in this environment, Genesis Hosting’s configured its management software to call NEC’s equipment so each VDC would remain:
- Self-Managing. Any Genesis Hosting client can access its VDC at any time and independently provision physical resources or run applications without needing the help of Genesis
- Scalable. As its clients’ VDCs consume physical resources and need more, Genesis can non-disruptively provide it to them.
- Shared resources. Genesis shares its physical resources between its clients’ VDCs by using the APIs to monitor resource utilization and dynamically allocating them where they are most needed
- Secure. Genesis uses NEC’s storage software functions to ensure VDCs do not trespass on what belongs to another VDC
Organizations want the physical infrastructure that supports their ever growing virtual environments to provide the performance, predictability and stability they need. But to get these attributes organizations do
not have to feel obligated to
pay a premium for pre-packaged reference architectures.
As Genesis Hosting found when it completed its recent proof of concept, NEC’s technology and products provide what it needs to continue to readily grow its reference architecture. While it had to take the appropriate precautions by first putting NEC through a proof of concept, Genesis found that it could confidently build a viable reference architecture at a fraction of the price of pre-configured solutions and take this solution from testing into production without posing any risk to its clients’ VDCs.
To read more about how Genesis Hosting leveraged NEC’s hardware to first do a proof of concept and then build a reference architecture, click here.