Monthly Archives: October 2017

Historically, organizations had “racked and stacked” hardware, and then installed and configured software and applications for their IT needs. With advent of cloud computing, IT organizations could start taking advantage of virtualization to enable the on-demand provisioning of compute, network, and storage resources. By using the CLI or GUI, users have been able to manually provision these resources. However, with manual provisioning, you carry the following risks:

Inconsistency due to human error, leading to deviations from the defined configuration.

Lack of agility by limiting the speed at which your organization can release new versions of services in response to customer needs.

Difficulty in attaining and maintaining compliance to corporate standards due to the absence of a repeatable process

Infrastructure as Code (IAC) solutions address these issues by allowing you to automate the entire configuration and provisioning process. In its essence, this concept allows IT teams to treat infrastructure the same way application developers treat their applications – with code. The definition of the infrastructure is in human readable software code. The code allows to script, in a declarative way, the final state that you want for your environment and when executed, your target environment is automatically provisioned. A recent blog on this topic by my colleague David Jasso referred to IAC paradigm as IT As Developer. For additional information on IAC, read the two Forrester reports: How A Sysadmin Becomes A Developer (Chris Gardner and Robert Stroud; Forrester Research; March 2017); Lead The I&O Software Revolution With Infrastructure-As-Code (Chris Gardner and Richard Fichera; Forrester Research; September 2017)

In this blog post I will show you how by using Terraform and VMware Integrated OpenStack (VIO), you describe and execute your target infrastructure configuration using code. Terraform allows developers to define their application infrastructure via editable text files ending in .tf extension. You can write Terraform configurations in either Terraform format (using the .tf extension) or in JSON format (using the .tf.json extension). When executed, Terraform consumes the OpenStack API services from the VIO (OpenStack distribution from VMware) to provision the infrastructure as you have defined. As a result, you can use these provisioning tools, in conjunction with VIO, to implement Infrastructure as code.

For those not familiar with VIO, VIO differentiates from upstream distribution in by making install, upgrade and maintenance operations simple, and leveraging VMware enterprise-grade infrastructure to provide the most stable release of OpenStack in the market. In addition to OpenStack distribution, VIO is also helping bridge gaps in traditional OpenStack management monitoring and logging by making VMware enterprise-grade tools such as vRealize Operations Manager and Log Insight OpenStack aware with no customization.

Standard DefCore Compliant OpenStack Distribution delivered as an OVA

End to end support by VMware, OpenStack and SDDC infrastructure.

The best foundational Infrastructure for IaaS is available with vSphere Compute (Nova), NSX Networking (Neutron), vSphere Storage (Cinder / Glance)

OpenStack endpoint management and logging is simple and easy to perform with VMware vRealize Operations Manager for management, vRealize Log Insight for logging, and vRealize Business for chargeback analysis

Best way to leverage existing VMware investment in People, Skills, and Infrastructure

Let’s look at the structure of code that makes IAC possible. The first step in defining the configuration is defining all the variables a user needs to provide within the Terraform configuration – see example below. The variables can have default values. Putting as much site specific information as possible into variables (rather than hardcoding the configuration parameters) makes the code more reusable. Please note that the code below is for illustration only. Complete example can be downloaded from here.

The next step in defining the configuration is identifying the provider. Terraform leverages multiple providers to talk to services such as AWS, Azure or VIO (OpenStack distribution from VMware). In the example below we specify that the provider is OpenStack, using the variables that you defined earlier.

Next you define the resource configuration. Resources are the basic building blocks of a Terraform configuration. In the example code below (please use it as an illustration), you use Terraform code, which in turn leverages VIO, to create the compute and network resource instances and then assigns network ID to the compute instance to stand a networked compute instance. As you will see in the example, the properties of a resource created may be passed as arguments to the instance creation step of the next resource, such as using Network ID from the ‘network’ resource created, when creating the resource ‘subnet’ in the code below.

Infrastructure as a code allows you to treat all aspects of operations as software and manage almost everything in code, including servers, storage, networks, log files, automated tests, deployment processes, and so on. The concept extends to making configuration changes as well. When you want to make any infrastructure configuration changes, you can check out the configuration code files from your code repository management system such as git, edit it to make the changes you want, check-in that new version. So you can use git to make and track changes to your configuration code – just as developers do.

Summary:

In this blog post, we have shown how you can implement IAC paradigm by using Terraform, running on VIO. Download 60-day VIO evaluation now and get started, or try out VIO 4.0 based VMware Integrated OpenStack Hands-on Lab, no installation required.

As computing demands increase, server resources must “grow” or “scale” to meet those requirements. There are two basic ways to scale computing resources. The first is to add more VMs or “horizontally scale.” Say a web front end is using 90% of the allocated computing capacity. If traffic to the site increases, the current VM may not have enough CPU, memory, or disk available to keep up. The site administrator could deploy an additional VM to support the growth in the workload.

Not all applications scale horizontally. NFV workloads such as virtual routers or gateways may need to “vertically scale”. For example, a virtual machine with 2 vCPU / 4 G memory may need to double it’s vCPU and memory rather than adding a second virtual machine. While the OpenStack ecosystem offers many tools for horizontal scaling (Heat, Terraform, etc.), options for scaling up are much more limited. The Nova project has a long-pending proposal for live resize (Hot Plug). Unfortunately, this feature still hasn’t been implemented. Without live-resize, to increase Memory/CPU/Disk of an instance, OpenStack must first power down the VM, migrate to a VM flavor that offers more CPU/Memory/Disk, finally power up the VM. VM power down impacts SLA and can trigger cascading failure for NFV based workloads (route convergence, loops, etc.)

By leveraging the existing OpenStack resize API and recommendations introduced in the upstream live-resize specification, VMware Integrated OpenStack (VIO) 4.0 offers the ability to resize any machine, as long as the GuestOS supports it, without the need to power down the system. OpenStack users would issue the standard OpenStack resize request. The VMDK driver examines the CPU/memory/disk changes specified by the flavor, and the setting of the virtual machine to determine whether the operation can be performed. If the guest OS supports live-resize, resources will be added without power down. If guest OS cannot support live-resize, then traditional Nova instance resize operation takes place (which powers off the instance).

Best Practice Recommendations:

When implementing live-resize in your environment, be sure to follow the following recommendations:

Cloud Admins or Application owners would need to indicate the GuestOS can handle live resize for a specific resource using image metadata “os_live_resize= <resource>.” List of guest OS that supports hot plug / live-resize can be found here. Available resource options are disk, memory or vCPU. You can live-resize the VM based on any combination of the resource types.

Add CPU resources to the virtual machine

Add memory resource to the virtual machine.

Increase virtual disk size of the virtual machine

Add CPU and Memory, CPU and Disk, or Memory and Disk

Increase CPU, Memory, and Disk

Hot removal of CPU/Memory not supported

If a resized VM exceeds the capacity of a host, VMware DRS can move the VM to another host within the cluster where resources are available. DRS is simple to configure and extremely powerful. My colleague Mathew Mayer wrote an excellent blog on Load balancing vSphere Clusters with DRS, be sure to take a look.

Image Metadata updates for disk resize:

Linked clone must set to false. This is because vCenter cannot live resize linked cloned disks

Disk adapter must be Non-IDE. This is because IDE disks do not support hot-swap/add.

See diagram below:

4). VMware supports memory resize of 4G and above. Resize below 4G should work in most cases, but not officially supported by VMware.

In my previous blog I wrote about VMware’s involvement in open source. The proliferation of open source projects in recent years has influenced how people think about technology, and how technology is being adopted in organizations, for a few reasons. First, open source is more accessible – developers can download projects from github to their laptops and quickly start using them. Second, open source delivers cutting edge capabilities, and companies leverage that to increase the pace of innovation. Third, developers love the idea that they can influence, customize and fix the code of the tools they’re using. Many companies are now adopting the “open source first” strategy with the hope that they will not only speed up innovation but also cut costs, as open source is free.

However, while developers increasingly adopt open source, it often doesn’t come easy to DevOps and IT teams, who carry the heavy burden of bringing applications from developer laptop to production. These teams got to think about stability, performance, security, upgrades, patching and the list goes on. In those cases, enterprises are often happy to pay for an enterprise-grade version of the product, for which all those things mentioned are already taken care of.

When applications are ready to move to production…

OpenStack is a great example. Many organizations are keen to run their applications on top of an open source platform, also known to be the industry standard. But that doesn’t come without deployment and manageability challenges. That’s where VMware provides more value to customers.

VMware Integrated OpenStack (VIO) makes it easier for IT to deploy and run an OpenStack cloud on top of their existing VMware infrastructure. Combining VIO with the enterprise-grade capabilities of the VMware stack provides customers with the most reliable and production ready OpenStack solution. There are three key reasons for this statement: a) VMware provides best-of-breed, production ready OpenStack-compatible infrastructure; b) VIO is fully tested for both – business continuity and compatibility; and c) VMware delivers capabilities for day 2 operations. Let me go into details for each of the three.

Best-of-breed OpenStack-compatible infrastructure

First, VMware Integrated OpenStack is optimized to run on top of VMware Software Defined Data Center (SDDC), leveraging all the enterprise-grade capabilities of VMware technologies such as high availability, scalability, security and so on.

VMware NSX for Neutron: advanced networking services with massive scale and throughput, and with rich set of capabilities such as private networks, floating IPs, logical routing, load balancing, security groups and micro-segmentation.

VMware vSAN/3rd party storage for Cinder/Glance: VIO works with any vSphere-validated storage (we have the largest hardware compatibility list in the industry). VIO also brings Advanced Storage Policies through VMware vSAN.

Battle hardened and tested

OpenStack can be deployed on many combinations of storage, network, and compute hardware and software, and from multiple vendors. Testing all combinations is a challenge and often times customers who choose the DIY route will have to test their combination of hardware and software for production workloads. VMware Integrated OpenStack, on the other hand, is battle-hardened and tested against all VMware virtualization technologies to ensure the best possible user experience from deployment to management (upgrades, patching, etc.) to usage. In addition, VMware provides the broadest hardware compatibility coverage in the industry today (that has been tested in production environments).

Finally, to add to all of this, another benefit is that our customers only have one vendor and support number to call to in case of a problem. No finger pointing, no need to handle different support plans. Easy!