Build Your Own Cloud Sandbox
Part 3: Defining Cloud Resources
By José De Jesús, Apurv Johar, Michael Nassar
Introduction
This article continues our discussion from Parts 1 and 2 of this series on how to build and configure your own cloud sandbox using a Workload Deployer virtual appliance. After securing Workload Deployer, as covered in Part 2, you are ready to continue configuring the appliance. This article explains how to define cloud resources such as IP groups, cloud groups, hypervisors, and environment profiles.
NOTE: As illustrated in Parts 1 and 2 of this series, the terms Virtual Pattern Kit for Developers (VPKD), IWD, and Workload Deployer are used interchangeably.
Workload Deployer supports a “bring your own cloud” model, which means it leverages existing infrastructure and existing resources. The physical network and storage resources that comprise the cloud environment must be available and ready for use prior to defining the cloud resources in the appliance.
Creating Cloud Resources
The following are the main activities involved in configuring cloud resources in Workload Deployer:
1. Create IP Groups
2. Create Cloud Groups
3. Define Hypervisors
4. Create Environment Profiles (optional)
Let us first level set with some definitions within Workload Deployer:
- IP groups are sets of IP addresses that can be dynamically assigned to virtual machines at deployment time.
- Cloud groups are collections of configured hypervisors of a certain type (e.g. ESX).
- Hypervisors are configured connections to platform virtualization servers (hypervisors) capable of provisioning and running virtual machines.
- Environment profiles are configured deployment targets which specify environment-specific policies for virtual machine placement, naming conventions, and resource constraints.
Configuring these cloud resources allows you to create cloud environments that are customized for different types of users, such as developers and testers.
This article walks you through the process of creating a relatively simple cloud that is logically partitioned into two separate environments: development and test, as illustrated below:
Gathering information about your network
Before you can create IP groups, you must gather some important information about the network environment. Specifically, you will need the following information about the network for each IP group that you plan to create (recall that many of these values were determined in Steps 9–11 of Part 1 in this series):
- Subnet address
- Subnet mask
- Gateway address
- Domain Name Server (DNS) address(es)
- Range of IP addresses that are available for use (these should also be registered with their hostnames in the DNS server(s))
If you did not set up the network that you plan to use, you will need to get this information from your network administrator.
Alternatively, if you are planning to use the same subnet for your IP group that the Workload Deployer virtual appliance uses and you have administrative access to the virtual appliance, you can also get information about the network from the Workload Deployer virtual appliance console. You can access the Workload Deployer virtual appliance console either from the VMWare vSphere Client (console connections to a virtual machine can be opened from the Summary or Console tabs for the virtual machine) or by opening an SSH connection to the virtual machine that is running the VPKD. You will need to login with the administrator user ID (e.g. cbadmin) to access the console.
Once connected, you can use the netif show, show status netif, and get-dns-servers commands from the command console to determine network information for each of the virtual appliance’s configured network interfaces.
As depicted below, you can run the netif show command to determine the configured network interfaces available to Workload Deployer.
The netif show interface console command shown below displays the default gateway address and displays the Classless InterDomain Routing (CIDR) prefix at the end of the IP address as configured for the specified network interface (e.g. eth0).
Recall from Step 9 in Part 1 of this article series that you can use the CIDR prefix to determine the subnet mask (e.g. “/25” is equivalent to 255.255.255.128). Also recall that you can determine the subnet address from the subnet mask and IP address (e.g. for subnet mask 255.255.255.128 and IP address 9.51.153.201 the subnet address is 9.51.153.128) and determine the range of IP addresses in the subnet. If you are not the network administrator, you will need to check with your network administrator as to which IP addresses have been allocated for use in your subnet.
If you do not want to calculate the subnet mask from the CIDR prefix or just want to verify your subnet mask calculation is correct, it is also possible to directly obtain the subnet mask (and other information about the network interface) from the show status netif interface console command. This command displays the status of the specified network interface:
Finally, you can use the get-dns-servers console command to determine the DNS servers that are available for the network:
Once you have gathered the appropriate network settings for each available network that you plan to use for your cloud environment, you should now be ready to set up IP groups.
However, it is important to note that only one IP group can be mapped to each virtual network provided by the hypervisor. Depending on how you plan to partition your cloud for different groups of users, you may also determine that you (or your network administrator) first need to set up additional virtual networks in the hypervisor environment to be able to use all of the IP groups. Therefore, prior to discussing the creation of IP groups, we will first go over an example of setting up a virtual network in the ESX hypervisor in the next section.
Create additional ESX hypervisor virtual networks (optional)
If you determine that your hypervisor does not have enough virtual networks defined for the number of IP groups that you plan to create, you will need to create additional virtual networks in the hypervisor environment. If you do not need to do this, you can skip this section.
For VMWare ESX hypervisors, you can create virtual networks (also known as port groups in VMWare) using the VMWare vSphere Client. The steps below illustrate how to create an additional virtual machine network on an ESX hypervisor. More information about ESX server networking configuration is available in the VMWare vSphere Networking Guide.
Note: The discussion in the remainder of this section covers an example of adding a virtual network to an existing vSphere standard switch and adapter. It is important to note that it is also possible to create a separate network on a different standard switch. In that case, a different network adapter is used and a new VLAN id can also be added. That option is available from the “Add Networking …” link at the top right of the Networking configuration panel of the VMWare vSphere Client (you may have to scroll to the right to see it).
The process of creating a separate virtual network on a different switch and network adapter is outside the scope of this article, but is very similar to the process described in the remainder of this section. If you need to set up a virtual network using a different switch in your environment, you can review the VMWare vSphere Networking Guide.
Using the VMWare vSphere Client, go to the Configuration tab for the ESX server and click on Networking in the menu on the left side. This displays information about the configured switches, adapters, and virtual networks that have been configured. It also displays which virtual machines are currently registered in each virtual network:
Click on the “Properties…” link above an existing network switch to view and edit the Networking properties for the switch:
On the Ports tab, click on the “Add…” button to add a new network:
Leave the Virtual Machine option selected to specify that the network is for virtual machine traffic. Click the Next button:
A unique network label is generated by default. You can edit the label name if necessary. You can also optionally select an existing Virtual Local Area Network (VLAN) identifier that is appropriate to use for your virtual machine network environment. In networks, VLANs are used to segment network resources into different broadcast domains. This allows network administrators to either logically isolate or group together different network resources based on requirements and attributes other than just physical location. In our example, we just use the same VLAN identifier for both virtual machine port groups but you may want to configure different VLANs to use for each port group in your network depending on your resource isolation requirements. See below:
Click the Next button to view the Summary screen:
Review the settings and click the Finish button to complete the updates. You will see the new network port group in the list and can select it to see its properties:
Review the properties and click the Close button to return to the Networking configuration page, which now also displays the new network, as shown here:
Creating IP Groups
An IP group contains subnet configuration information and a list or range of IP addresses that you can select to use with specific hypervisors. The IP addresses in an IP group will be dynamically assigned at deployment time to the virtual machines that get provisioned to the hypervisor virtual network that uses the IP group.
You can segment your available IP addresses into separate IP groups for use by different sets of users. For example, you could potentially split 100 available IP addresses into four sets of 25 IP addresses to be used by four different departments in your organization. Although these 100 IP addresses might be all on the same subnet, creating the IP groups allows you to logically isolate them. You can then ensure that each IP group is only used for a particular purpose and by a particular group of users.
As previously mentioned, in this article we will go through the process of creating a simple cloud that is logically partitioned into separate “development” and “test” environments. Therefore, we will create two separate IP groups (one for each environment). If you do not need to partition your sandbox cloud environment, then you only need to create a single IP group if your available IP addresses are all on the same subnet.
In order to administer IP groups, you must have either cloud administration full permissions or appliance administration full permissions.
To start creating IP groups, navigate to Cloud > IP Groups in the VPKD web interface.
On the IP Groups page, click the green plus (+) icon to add a new IP group:
In the dialog, enter the IP group name and the appropriate network settings that you collected earlier (In our example, we are creating an IP group named “IPGroup_ESX_Dev” indicating that the IP group is for our development environment). In the IP Group dialog, click the Create button to add the IP group:
The IP group is created and the properties are displayed. In the IP Addresses section, you can add either a range of IP addresses or a list of hostnames that represent the available servers in the IP group.
In the IP Addresses section, specify the IP addresses or hostnames that will comprise the available servers in the IP group and click the Add button. The IP group properties will then display the addresses available, as show below:
To create the “IPGroup_ESX_Test” IP group for the test environment, we can follow the same sequence of steps that were used to create the “IPGroup_ESX_Test” IP group. Note that to ensure logical isolation, the set of IP addresses or host names must be unique to each IP group (i.e. no overlap of IP addresses or host names among different IP groups is allowed). Figure 18 shows the IP Groups page with both IP groups created.
IP group properties and maintenance
After the IP groups are created, you can manage and update the IP groups as needed throughout their lifecycles. Each configured IP group has a set of properties, most of which are editable. IP groups also have action links available that you can use to either refresh or delete the IP group. The tables below provide a listing of the different actions that are available and the different IP group properties:
Creating Cloud Groups
A cloud group is a collection of hypervisors. Though a hypervisor can belong to only one cloud group, a cloud group can contain one or more hypervisors. Each cloud group can only contain hypervisors of the same type, meaning from a single vendor. In the VPKD, clouds groups are deployment targets for virtual pattern deployments.
Cloud groups can be one of two types: managed or custom. Managed cloud groups are sets of hypervisor systems that are managed by a single administrative endpoint outside of Workload Deployer, such as by the VMWare VirtualCenter Server for VMWare ESX hypervisors. In managed cloud groups, the available hypervisor systems are discovered when the cloud group is created. Custom cloud groups are collections of configured hypervisor connections that are created and maintained in the VPKD. In custom cloud groups, the hypervisor systems are not automatically discovered when the cloud group is created; you must define them separately and add them to the cloud group.
In order to administer cloud groups, you must have either cloud administration full permissions or appliance administration full permissions.
To start creating cloud groups, navigate to Cloud > Cloud Groups in the VPKD web interface.
In the Cloud Groups page, click the green plus (+) icon to add a new cloud group.
Here is what the dialog to add a cloud group looks like:
In the window, add a name and optional description for the cloud group. Also specify the hypervisor type, which is ESX in our case (ESX, PowerVM, and z/VM are the currently supported hypervisor types). With ESX hypervisors, you can also specify whether the deployments of virtual images to the hypervisors in the cloud group will be managed by an instance of VMWare VirtualCenter or whether they will be managed by Workload Deployer (i.e. a managed cloud group vs. a custom cloud group). If you have VirtualCenter deployed in your environment to manage a group of ESX servers, you can select the “Managed by a Virtual Center” option and specify the connection properties for the VirtualCenter server. Upon cloud group creation, Workload Deployer will discover the available hypervisors, storage, and network connections from the VirtualCenter instance. In this article, we will go down the path of creating a custom cloud group. Click the Create button to complete the cloud group creation.
The cloud group is created and its properties are displayed, as shown here:
Note that the cloud group type is “Custom cloud group”, which indicates that Workload Deployer manages its hypervisor connections. A custom cloud group was created because we did not select the “Managed by a Virtual Center” option on the previous dialog. There is also a warning message indicating that no hypervisors have been added to the cloud group. We will resolve that after we create our hypervisor connection in the “Set up Hypervisors” section.
After a cloud group is created, the administrative user who created the cloud group is its owner and has all access rights. You will likely also want to grant read access to the users and/or user groups that will be allowed to use the cloud group as a deployment target when deploying patterns to the cloud. You can use the “Add more…” selector in the Access granted to section of the cloud group properties page to add any users or user groups that should have access to the cloud group. In our example, we grant read access to the “DevUsers” and “TestUsers” user groups, as shown here:
Cloud group properties and maintenance
After the cloud groups are created, you can manage and update the cloud groups as needed throughout their lifecycles. Each configured cloud group has a set of properties, many of which are editable. Cloud groups also have action links available that you can use to either refresh or delete the cloud group, similar to what you see under the IP groups action links. The following two tables provide a listing of the different actions that are available and the different cloud group properties:
Defining the Hypervisors
A hypervisor is platform virtualization software that allows multiple operating systems to run on a host computer concurrently. For example, VMWare ESX/ESXi is a hypervisor platform that supports running multiple concurrent operating systems on the platform. The primary roles of hypervisor systems in a cloud environment are to provision and host the virtual machines that run the deployed software applications, middleware, and operating systems.
Whenever you are using a custom cloud group, you must also create and start at least one hypervisor connection that the custom cloud group will use. In order to administer hypervisors, you must have either cloud administration full permissions or appliance administration full permissions.
To start creating hypervisor connections, navigate to Cloud > Hypervisors in the VPKD web interface.
On the Hypervisors page, click the green plus (+) icon to add a new hypervisor. This will open the dialog to add a hypervisor connection:
In the dialog, specify a name for the hypervisor, select its type (ESX in our case), and specify the host name (can be the IP address) and login parameters. Click OK to request the creation of the hypervisor.
If the Workload Deployer virtual appliance can successfully connect to the hypervisor using the connection properties that you provided, you will then be prompted to accept the hypervisor’s security certificate:
This stores the hypervisor’s security certificate in the Workload Deployer virtual appliance’s local storage and allows the Workload Deployer virtual appliance to subsequently communicate with the hypervisor server securely in a trusted manner. Click the Accept button to store the certificate.
The Workload Deployer virtual appliance will then communicate with the hypervisor server to discover its available networks and storage devices. This may take several seconds. You can click the Refresh button to refresh the hypervisor status.
After the discovery completes, the hypervisor connection will initially appear in Maintenance mode:
This allows you to edit its properties. Before you can start the hypervisor, you must configure the network and storage settings.
Expand the Storage devices section to view available storage devices and select the ones that can be used. Select the “In use” checkbox next to each storage device that you plan to use:
Clicking the Refresh button should indicate that you still need to configure the hypervisor networks to use.
Expand the Networks section to view the available hypervisor networks and select the ones that can be used. Select the “In use” checkbox next to each network that you plan to use and specify the IP group to use for each network. You should specify the IP group(s) that you created earlier:
Clicking the Refresh button should now indicate that the hypervisor still needs to be added to a cloud group before it can be started.
To add the hypervisor to a cloud group, go back to the Cloud Groups page at Cloud > Cloud Groups and select the cloud group that you created earlier. In the Hypervisors section of the cloud group properties, click the “Add more” option to select the hypervisor connection (see the two figures below):
The cloud group properties should refresh with a new warning message indicating that you must start at least one hypervisor before being able to deploy virtual systems to the cloud. You can click on the link for the configured hypervisor connection to return to its properties page and start it:
On the hypervisor properties page, you should now see that the hypervisor is a member of the cloud group and that the Start link is now enabled:
Click the Start link to start the hypervisor connection. The status should change to Started. Once the hypervisor connection is started, it is able to receive virtual pattern deployment requests from IBM Workload Deployer.
At this point, your cloud environment is ready to accept virtual pattern deployment requests. However, depending on your resource constraints and usage needs, it may also be beneficial to create deployment policies and resource constraints for pattern deployments in your configured environments (e.g. “development” and “test” environments in our example). This is done by creating environment profiles, which can add the benefits of providing control over resource usage in the environments and better resource isolation. Information about configuring environment profiles is provided in the “Set up Environment Profiles” section.
Hypervisor properties and maintenance
After the hypervisor configurations are created, you can manage and update the configured hypervisors as needed throughout their lifecycles. Each configured hypervisor has a set of properties, many of which are editable. In most cases, the hypervisor must be in maintenance mode before you can change the properties. Configured hypervisors also have several action links available that you can use to change the hypervisor state or to perform various activities on the hypervisor. Here are the action links available on the top right of a hypervisor’s properties page:
The following table provides a listing of the different actions that are available:
The table below lists the different hypervisor properties. Most editable properties can only be modified when the hypervisor is in maintenance mode. The properties that can be edited when the hypervisor is started are noted in their respective descriptions.
Creating Environment Profiles (optional)
An environment profile is a configured deployment target which allows you to specify environment-specific policies for virtual machine placement, virtual machine naming conventions, and resource limits. As a deployment target, an environment profile provides you with a more advanced level of control and flexibility over virtual machine configuration and placement than a cloud group provides.
While in this article our simple sandbox cloud environment only contains one cloud group, a larger cloud environment could potentially contain multiple cloud groups. An environment profile allows you to specify multiple cloud groups and IP groups that can be used for virtual machine deployments. If an environment profile contains multiple cloud groups and IP groups, a pattern deployer using the environment profile as the deployment target can place different parts of a virtual system pattern in different cloud groups and IP groups at deployment time. This provides the flexibility to deploy, for example, the web tier, application tier, and data tier of an application in different segments of the cloud. This can be important for patterns that contain components that should be isolated or separated across different network segments.
Environment profiles also give you the flexibility to attempt to optimize cloud resource usage in your cloud environments based on requirements, expected usage patterns, and resource constraints for each environment. When a virtual pattern is deployed using an environment profile, the Workload Deployer virtual appliance will verify whether the deployment of the virtual pattern instance can occur within the specified resource limits and constraints in the target environment.
To learn more about planning for optimizing resource usage in your cloud environment, Bobby Wolf’s developerWorks article, “Managing application runtime environments in IBM PureApplication System” (http://www.ibm.com/developerworks/websphere/library/techarticles/1210_woolf/1210_woolf.html) provides an excellent primer. Although that article is written for cloud environments using IBM PureApplication Systems, most of the information is also relevant for cloud environments using Workload Deployer.
In the previous sections, we went through the process of creating a simple cloud that is logically partitioned into separate “development” and “test” environments. Therefore, we will also create two separate environment profiles (one for each environment).
In order to create environment profiles, you must have either create new environment profiles permission or appliance administration full permissions. Access to each individual environment profile is restricted to the owner (i.e. creator) of the environment profile and to any users or user groups to which the owner has granted access.
To start creating environment profiles, navigate to Cloud > Environment Profiles in the VPKD web interface.
On the Environment Profiles page, click the green plus (+) icon to add a new environment profile.
The figure below shows the dialog to add an environment profile. In the dialog, specify the environment profile name, an optional description, hypervisor type (ESX in our case), and environment type. The environment type is used to group environment profiles by the type of environment. During pattern deployment, the deployer can then choose to filter deployment targets by environment type. In this case, we are creating an environment profile for the “development” environment and will therefore choose “Development” for the environment type.
The Environment Profiles page will display the properties of the environment profile that you just created. Notice that there is a warning message indicating that you still need to associate the environment profile with an active cloud group:
You can map the environment profile to the cloud group that you created earlier by selecting the “Add more…” option under the Deploy to cloud groups section. After selecting the cloud group, you must then select which IP group to use in the cloud group:
You can select the “In use” checkbox for the IP group that you want to use for the environment profile. In this case, since this is our development profile, we should choose the IP group for the development environment. Once the IP group has been added, the environment profile can be used as a target for deployments:
Environment profiles allow you to control resource limits for any deployments that use the profile. Thus, different environment profiles with different environment limits specified would result in different resource policies and limits applied to any deployed pattern instances, even if the same pattern is deployed in both environments. The Environment limits section is where you can optionally set the resource limits across all deployments in the environment. This enables you to try to optimize resource usage based on how the cloud environment is expected to be used. You can set limits as needed on the number of virtual CPUs, amount of virtual memory, amount of storage, and number of product licenses to use in the environment.
For example, a development environment may require fewer dedicated resources than a test environment where heavier workloads may be tested. You could therefore allow larger resource limits in a test environment than you would allow in a development environment. By default, no limits are initially set in an environment profile (see Figure below). Therefore, you should specify values that are appropriate for your environment. As previously noted, the developerWorks article “Managing application runtime environments in IBM PureApplication System” (http://www.ibm.com/developerworks/websphere/library/techarticles/1210_woolf/1210_woolf.html) is an excellent resource for understanding the concepts behind optimizing resource usage in your cloud environments.
Like cloud groups, environment profiles are considered deployment targets and can be used to deploy patterns to the cloud. After an environment profile is created, the administrative user who created the environment profile is its owner and has all access rights. You will likely also want to grant read access to the users and/or user groups that will be allowed to use the environment profile as a deployment target when deploying patterns to the cloud. You can use the “Add more…” selector in the Access granted to section of the environment profile properties page to add any users or user groups that should have access to the environment profile. In our example, for the development environment we grant read access to the “DevUsers” user group. Thus, development users can use the environment profile to deploy patterns to the development environment.
After creating the environment profile for the development environment, we can also create a second environment profile for the test environment. This can be done by following the same process we used to create and configure the environment profile for the development environment. In this case, we can set the environment type to “Test”, configure the environment profile to use the “IPGroup_ESX_Test” IP group, and grant read access to the “TestUsers” user group. We can also set any environment limits that are expected to be needed for resources in the test environment. Note that since each environment profile represents a separate logical deployment target with presumably different resource and usage requirements, you should set appropriate environment limits for each environment profile that you create.
Here is the properties view of an environment profile created for the test environment:
Environment Profiles properties and maintenance
After the environment profiles are created, you can manage and update the environment profiles as needed throughout their lifecycles. Each configured environment profile has a set of properties, many of which are editable. Environment profiles also have action links available that you can use to refresh, clone, or delete the environment profile. Here are the action links available on the top right of an environment profile’s properties page:
The following table provides a listing of the different actions that are available:
This table shows the different environment profile properties:
Conclusion
This concludes our final article in this series. You learned how to create IP groups and cloud groups, as well as to define hypervisors and environment profiles. These elements are key to configuring your different environments and establishing the right separation of duties. Have fun with your private cloud sandbox!
