So, you’ve decided to build a private IaaS cloud. Great idea! By encouraging self-service IT in your organization, you’ve made your support staff happier by reducing their workload and you’ve made your users happier by giving them instant access to the resources they want. Now your users won’t be hounding the IT department (as much) to provision a VM or implement a firewall rule change. Happiness abounds!

How to build a cloud? Know the 4 elements of an IaaS

.

The first step in building a cloud is understanding that the four elements of an IaaS cloud are the cloud management system, compute, storage and networking. From a business perspective, the most cost effective way to build a cloud would be to use elements that will linearly scale out (adding new nodes to increase capacity) rather than scaling up (buying bigger machines to increase capacity). Following a scale-out model will allow your cloud deployment to grow as needed and your cloud can be right-sized rather than future-sized. An added benefit would be a reduction of capex costs…or at a minimum, delaying capex costs until necessary. Building the concept of “scale-out” in cloud deployments is how large service providers can offer a VM for only pennies per hour.

Cloud & scale-out storage options
If you’re a regular reader of SiliconAngle, you’re probably familiar with all the different cloud management systems. The choices are OpenStack and its offspring (Piston, RackSpace, Nebula, StackOps, CloudScaling, Ubuntu, Redhat, etc), Citrix’ CloudStack, Eucalyptus, and VMware’s vCloud. As for compute, you’ll need to pick a hypervisor. The choices would be KVM, Xen and VMware’s vSphere.

For scale-out options on storage, quite a few options abound. The most popular software options are Ceph, Gluster, and OpenStack Swift. Ceph offers a file, object, and block storage platform. Gluster, owned by RedHat, has a block storage option. OpenStack Swift, can also do object storage quite nicely. These software choices will run on commodity x86 boxes and act as a single storage cluster. As for hardware choices, SolidFire has an intriguing SSD-based solution for performant block storage. Since “cloud storage” is a big dollar opportunity, every major storage vendor is working on competing options.

Networking, networking, networking

Now, let’s discuss networking. In a traditional network, there are devices that handle networking roles like firewalling, NAT, port forwarding, load balancing, etc. A standard method of scaling these networking roles is by scaling up, which means buying bigger devices as demand increases. While this might be okay for a traditional environment, replacing devices in a functioning network greatly increases the odds of a service interruption. When you’re running a cloud whose apps are home to thousands of end users, the impact of causing a service interruption of even ten minutes can be a significant expense to your company.

Another non-scalable factor of using traditional networking in the cloud is the human costs. In order to do almost any changes to a traditional network, it takes highly trained, very expensive network engineers to design, implement and test the change before making the change go live. To build a truly scalable, low-cost cloud, the human costs need to be reduced as much as possible and a person shouldn’t be needed to add more capacity or change a firewall rule or provision a VPN service.

One more point where scale can break traditional network is network isolation. The most popular way to handle network isolation is by using VLANs. The upper limit of the number of VLANs in a network is 4096. In a reasonably-sized, moderately-used enterprise private cloud, there can easily be more than 4096 independent projects and best practices dictate that each independent project should be on it’s own virtual private network.

The promise of overlay-based network virtualization

.

Enter overlay-based network virtualization. Overlay-based network virtualization allows the cloud user to create “virtual networks” that are complex and feature-rich without requiring anything more of the underlying physical network than standard IP connectivity. This virtual network topology creation is enabled by the ability to tunnel Ethernet frames in IP over the physical network. Examples of tunneling protocols are GRE, NVGRE, VXLAN, and STT. With an overlay-based network virtualization approach, all that’s required of the physical network is that the tunnel endpoints have IP connectivity. The higher-level network intelligence, like virtual switching, virtual routing, and virtual load balancing, shift from the physical arena and are handled at the endpoints of the tunnel.

Overlay-based network virtualization allows the cloud operator to scale out capacity incrementally as needed without causing service interruptions The size of the cloud can expand or contract at any point and existing services wouldn’t be affected. Overlay-based network virtualization also vastly reduces the human overhead to managing, configuring and scaling the virtual network services. Of course, network engineers are a necessity and will still need to be around to manage the physical network, but every service in the virtual networking realm can scale and be configured without human interaction. As for limitations regarding VLANs, with network virtualization, there is no limit as to the number of unique isolated private networks than can be allocated.

In addition to these scaling benefits, there are additional benefits to overlay-based network virtualization that are unfeasible in a traditional network such as:

• Creating complex network topologies in a cloud environment
• Virtually “tapping” a tenant’s virtual port and sending that traffic into a DDOS or IDS device
• Offering Amazon VPC-type functionality
• Programmatically shutting down a tenant’s network access across all VM’s
• Easily metering a tenant’s network usage

As you can see, overlay-based network virtualization is a necessary element to build a fully featured, truly scalable IaaS cloud. As enterprises adopt cloud-networking en-masse, overlay-based network virtualization technologies will be a must-have addition.

About the Author

Ben Cherian is a serial entrepreneur who loves playing in the intersection of business and technology. He’s currently the Chief Strategy Officer at Midokura, a network virtualization company. Prior to Midokura, he was the GM of Emerging Technologies at DreamHost, where he ran the cloud business unit. Prior to that, Ben ran a cloud-focused managed services company.