INAP IS NOW HORIZONIQ.
Click here to LEARN more.

Feb 26, 2015

Bare Metal vs. Hypervisor: The Evolution of Dedicated Servers

Paul Painter, Director, Solutions Engineering

With the “cloudification” of IT, new terms have appeared across the hosting industry. Some of the most popular terms are bare metal and hypervisor. But what are these? Let’s clarify the bare metal first. To answer simply, a bare metal server is your traditional dedicated server with a hip new name for the cloud generation! Let’s have a look at what a dedicated/bare metal server is.

What is Bare Metal?

Bare metal is a single tenant server. This means only you are taking the resources of the server. The server belongs to you and you only. Compared to the cloud model where multiple users (multi-tenancy) reside on the same physical server, the bare metal server only has one customer on the server.

Single tenancy allows you to avoid the noisy neighbor effect, which is described as a user impacting the performance and stability of other users within the same server. With bare metal, since you are the sole user, you will not witness the noisy neighbor effect.

From a financial perspective, the bare metal server is typically billed per month. This means no surprise on your bill at the end of the month. However, with the “cloudification” of hosting, bare metal is also available in hourly billing, so keep in mind that costs are variable when selecting an hourly usage plan.

Bare metal supports multiple types of operating systems on top of it, including hypervisors. This brings us to our next point—the difference between bare metal and hypervisors.

What is a Hypervisor?

How does hypervisor differ from bare metal? A hypervisor is an operating system that can create virtual machines (VM) within a bare metal server.

A traditional bare metal server: The operating system (CentOS, Debian, Redhat, SUSE, Ubuntu, Windows Server, etc.) is installed directly on the server, and applications are running natively in the operating system.

A bare metal server installed with a hypervisor provides the user with a management suite to create virtual machines on the server. The hypervisor should not run applications natively; rather, its purpose is to virtualize your workloads into separate virtual machines to gain the flexibility and reliability of virtualization.

Multiple hypervisors exist on the market. We have reached a point with virtualization technology where the ecosystem is very mature and all options are very similar. So the choice of a hypervisor relies mainly on the following points: your current familiarity with a vendor, your current infrastructure technologies, your staff certifications, and of course, the cost of ownership.

Make sure to understand what features you are looking for and which vendor offers the best solution based on your budget and compatibility with your current infrastructure to avoid painful migration and unexpected issues.

As for the bare metal selection, be certain to choose the proper billing method that fits your budget and your needs. If you require on-the-fly resources that will likely be shut down within hours or weeks, then hourly billing is probably the way to go. However, if you are looking to deploy a steady workload that will run for multiple months, then monthly billing is likely the best choice.

As for the hardware itself, leverage the hourly billing of bare metal to test your application on the server of your choice, and run tests for a few days or weeks until you find the right bare metal configuration for your performance requirements.

Bare Metal or Hypervisor? Making the Choice

In the end, there is no single story for the bare metal server with native workload versus bare metal with a hypervisor and virtualized workloads. Both bare metal and hypervisor have their advantages, and nothing would stop a small development firm from leveraging bare metal servers with hypervisors. It simply is a matter of selecting which technology best fits your needs, and what you feel most comfortable with.

Start with a proof of concept with an hourly bare metal server (with a hypervisor or running your application natively on the bare metal), and see how your application performs. Evaluate the impact on your infrastructure and service management, and move forward according to your findings and experience. There’s nothing like giving it a spin to get the feel of it!

Explore HorizonIQ
Bare Metal

LEARN MORE

About Author

Paul Painter

Director, Solutions Engineering

Read More
Jul 30, 2013

Bare-metal cloud use cases: Let’s get physical

Ansley Kilgore

The cloud hasn’t always been the ideal choice for performing large, resource-intensive workloads. Scenarios that require high disk I/O and large amounts of compute resources are generally better suited for physical, dedicated servers. While the automation and self-service capabilities of the cloud are valuable, the virtualization layer can take up space that could be used to process your workload. The bare-metal cloud offers a best-of-both-worlds approach – a dedicated environment without the overhead of virtualization, but without sacrificing the flexibility of the cloud (tweet this).

Bare-metal servers do not run a hypervisor and are not virtualized, and can be delivered on a cloud-like service model. This balances the scalability of the cloud with the performance capabilities found in monthly dedicated server hosting plans. The hardware is fully dedicated to the customer, including any additional storage that may be required. Bare-metal instances can be provisioned and decommissioned as needed, providing access to high-performance dedicated servers on demand. Depending on the application and use case, a single bare-metal server can support greater workloads than multiple similarly sized VMs.

Bare-metal servers work well for high-performance use cases such as media encoding and render farms, operations that require short-term data-intensive functions without latency or overhead delays.

Use Case: Media Transcoding
Many sites with user-generated content need media transcoding for publishing to an origin-store Content Delivery Network (CDN). When a user uploads a video, the site needs to transcode the video file into a common format viewable by site visitors. The transcoding software for both audio and video are processor-intensive, and if located on the same machine as the web server or used in a multi-tenant environment, performance may suffer. While a site can send the original file to a remote server for processing and have dedicated resources available to the task, a traditional monthly dedicated server may sit idle during slow traffic periods or be overextended during peak traffic. Bare-metal cloud allows this site to take advantage of the cloud-like flexibility of on-demand provisioning while maintaining the dedicated processing resources of a physical server.

Use Case: Render Farm
Many commercial 3D animation and CAD software support a “render farm” mode, where a regular desktop workstation can be turned into a node in a rendering cluster. This was used by animation companies to develop original media assets during the day, and turn their workstations into a rendering cluster after hours to process their files. With bare-metal cloud, a designer could maintain a single always-on “master” node to submit rendering jobs. This master node would then interact with other hardware nodes for processing the individual frames that need to be rendered. These hardware nodes could be provisioned by design staff as needed to process large or small jobs, or the master node software could be adapted to provision additional instances as needed through a provisioning API.

By combining non-virtualized, physical resources with the service delivery and automation capabilities of the cloud, bare-metal servers can focus all their computing power on your use case. This increases your operational efficiency and provides better performance for smaller investment.

Explore HorizonIQ
Bare Metal

LEARN MORE

About Author

Ansley Kilgore

Read More
Jun 4, 2013

Private cloud vs. virtualization

Ansley Kilgore

Private Cloud vs VirtualizationWith all the hype around cloud these days, figuring out where cloud fits and where it doesn’t can be challenging. Private cloud and virtualization often get confused with each other, but in fact, virtualization is usually a component of cloud, whether public or private. Let’s consider a couple of real-world examples to illustrate the difference between virtualization and a true private cloud deployment.

Example 1 – Virtualization
An IT department, continually installing/reinstalling new servers, implements a virtualization solution so they can provision infrastructure faster and consolidate servers. They virtualize servers using their hypervisor of choice along with management tools. They upload ISO files into their management software so they can install new OSes into a new virtual machine. They’re connected to the local network in order to manage the virtual machines or the orchestration software used for provisioning. And if they are charging back capacity to their internal customers’ budgets (Marketing, Sales, Engineering, etc.), they’re probably just splitting the cost between each group, or maybe tracking how many virtual machines they deploy for each department.

Is this cloud? Not really. This is known as server consolidation, data center automation, etc. and the solution doesn’t meet all five characteristics of cloud computing:

  1. On-demand self-service (IT still has to provision virtual machines for their internal customers).
  2. Broad, network access (this deployment is only available for internal customers on the network)
  3. Resource pooling (this is where virtualization fits, so yes, this requirement is met)
  4. Rapid elasticity (IT still has to provision VMs individually by installing the OS and software, and they don’t necessarily scale fast)
  5. Measured service (IT is charging costs back to other departments based on traditional budgeting, not based on actual usage)

Example 2 – Private Cloud
A company’s headquarters includes a central IT staff that supports company-wide and departmental applications. They also have several branch offices each with a local IT staff that focuses on break/fix repair of local desktops and network services. The branch offices may occasionally set up a local server and install software at a manager’s request, but they may prefer to ask central IT to provide supported servers or applications from HQ. Central IT is looking to provide better support for their branch offices without hiring more staff, speed up turnaround time when provisioning services for supported applications and even allow quick, easy servers on-demand to their branch offices for local, unsupported applications. So they install their hypervisor of choice, deploy storage in their preferred manner and add some management software. However, in addition to providing ISO files for VM installation, they also prepare some disk images with pre-installed, supported OSes.

The management software allows multiple users of different access levels to perform tasks such as launching virtual machines, installing VMs from supported images or from unsupported ISOs, or rebooting machines or reconfiguring virtual networks between VMs. Now the Marketing department in a branch office can try out some new analytics software by logging into a portal, provisioning a new server, installing the trial software and using it for a few days. If they don’t like it, they turn it off and delete the VM. Engineering may deploy multiple VMs to set up a production application, but also spin up a few additional VMs to use as development and staging environments or continuous integration servers. They no longer have to put in capital budget requests for servers, or search through old supply closets for dusty old desktops to repurpose when needed.

Is this a private cloud? Yes!

This company is still using virtualization, but now they’ve added a level of self-service for branch offices. The service can be accessed using a VPN connection over the Internet or an SSL/TLS web-based portal (broad network access). Branch employees or local IT staff can spin up additional capacity quickly and turn it off just as fast (rapid elasticity). As a result, central IT can now meter actual usage of each service by various departments on a monthly or even hourly basis and charge those departments accordingly.

So, while virtualization tends to be a component and enabler of cloud services, true cloud services provide specific benefits to both the consumers and the IT departments deploying them.

Explore HorizonIQ
Bare Metal

LEARN MORE

About Author

Ansley Kilgore

Read More