At Packet, we’re always interested in hearing about new technologies that make bare metal infrastructure more usable, secure and automatable. Last month I stumbled upon Hyper, which offers a super lightweight virtualization engine specifically geared at powering containers.
At Packet, we’re always interested in hearing about new technologies that make bare metal infrastructure more usable, secure and automatable. In the past few months, we’ve run into a ton of new container-related services and tech, from networking projects like Project Calico to container management platforms like Rancher and ContainerShip. Last month I stumbled upon Hyper, which offers a super lightweight virtualization engine specifically geared at powering containers. Hyper addresses some key issues for production container workloads by melding the concept of application containers with virtualization. You can get a good feeling for where Hyper fits in by checking out the comparison table from their website, which I’ve included below:
|Isolation||Weak, Shared Kernel||Strong, HW-enforced||Strong, HW-enforced|
|Portability||Yes||No, Hypervisor dependent||Yes, hypervisor agnostic and portable image|
|Boot Time||Fast, sub-second||Slow, tens of seconds or more||Fast, sub-second|
|Performance||Great||OK||Good, minimal resource footprint and overhead|
|Immutable||Yes||No, configuration management required||Yes, guest os is gone|
|Image Size||Small (MB's)||Big (GBs)||Small, MBs|
|Backward Compatibility||No, brand new world||Great, everything still works||Good, it is still a "Machine", much less changes|
|Maturity||No||Yes, production ready, SDN, SDS, Live Migration, etc||Yes, just plug-&-play|
|ROI||Low, rebuild everything with containers in mind||N/A||High, seamless integration with your virtual infrastructure|
Hyper brings an interesting alternative to the whole “containerize everything” mantra that is being discussed at most meetups today -- and presents a nice middle ground. You get:
- super fast boot times;
- immutable style infrastructure;
- the ability to run Docker or APPC containers with security and isolation
Bonus: you can also leverage similar underlying infrastructure for your non-container or VM-specific workloads. Neat! To demonstrate the concept, let’s see how to get things set up with Hyper and put it through the paces.
Setting Up Hyper
Installing Hyper can be quite easy -- simply install a few dependencies and execute the sample install script. Installation on a bare metal server at Packet is even simpler. Taking advantage of the user data functionality provided in the portal or API, you can quickly deploy a server with Hyper pre-installed and running before ever logging into the machine. Here is how:
- Step #1: Login to the Packet portal at https://app.packet.net/
- Step #2: Click the Deploy button and you’ll be at the server deploy page
- Step #3: Simply select the Project you wish to deploy your server(s) to and then configure the hostname for either a Type 1 or Type 3 server instance.
- Step #4: Then, click on the "User Data” tab for that server and you’ll be presented with the following modal:
- Step #5: Simply paste your cloud-config compatible user data (careful of your line breaks!) into the space provided and click “Save & Continue”. I’ve provided the cloud config data I’ve used below:
#!/bin/bash apt-get -y install qemu wget -qO- https://get.docker.com/ | bash curl -sSL https://hyper.sh/install | bash
- Step #6: Click Deploy and within a few minutes, you’ll have a shiny new Packet bare metal server running Hyper and ready for your VM and container workload.
Hyper Performance (on Packet!)
The Hyper team was kind enough to do some benchmarking of their platform on Packet’s bare metal, including our Type 1 server and our Type 3 server instances. You can see the full details on the Hyper website under the Performance section. Some of the stats that impressed me the most were:
|Packet Config||Max # Pod (Hyper)||Max # Traditional VMs (KVM)||DMIPS CPU Benchmark (Hyper)|
The chart above illustrates how Hyper is significantly more efficient than simply using traditional KVM/Qemu. Needless to say you’re able to obtain a much higher density per machine than you ever could on some of your pre-existing hypervisor machines.
Deploying a Pod takes just 376 ms on type-1 servers and slightly longer on type-3 baremetal servers. Replacing an existing Pod with a new one takes only half of that time, meaning that redeploys require even less time!
Hyper allows you to efficiently run Docker containers while adding security and removing the need for a guest OS to run containers. They have kept the relatively new App Container spec in mind while architecting Hyper, which allows for Hyper to be used today while ensuring good support for evolving standards in the future.
If you have existing investments in hypervisors or are struggling with security and isolation concerns around containers, running Hyper on Packet's on-demand baremetal servers is something worth a considering.