-
Cisco OverDrive 4.0 User Guide
-
About This Guide
-
Creating a simple site-to-site network
-
Setting up intra-site network access
-
Controlling intra-site network access
-
Controlling intra-site business access
-
Configuring clouds
-
Enabling VMs
-
Monitoring network status
-
Creating audits and reports
-
Reference to common tasks
-
Sample Reports
-
Cloud configurator fields
-
FAQ
-
Troubleshooting
-
Glossary
-
Index
-
FeedbackTable Of Contents
How the metamodel determines the parameters per screen
Supplying the right answers to the configurator
Working with clouds in domain models
A subcloud context and summary contents
Business policies within a cloud
Scenario 3a: creating and configuring a cloud
Configuring clouds
This chapter tells you how to set up your OverDrive environment in order to be able to offer cloud services and VMs to clients and users.
•
Supplying the right answers to the configurator
•
•
Note
See Chapter 6, "Enabling VMs" for creating VMs once you have created the appropriate clouds or subclouds.
Install type: clouds
Of the install types that OverDrive manages (site-to-site, intra-site, and cloud), cloud installations let you create and configure:
•
•
Introducing clouds
There are three distinct ways to use OverDrive, one of which is to provide cloud services, as described in this chapter. Cloud services combine VLAN management with business policies to automate provisioning of network resources and policies in response to requests for creating virtual machines (VMs).
Previous chapters have described using OverDrive for access control:
•
•
Clouds are segregated deployments of virtual computers. A cloud instance can be as complicated as an entire customer VPC with multiple complex configurations of VLANs and network services, or as simple as a single LAN segment with a collection of virtual machines.
The OverDrive NSV platform provides multiple cloud instances to satisfy both enterprise and service provider requirements for cloud services. OverDrive models the cloud as a set of resources and policies, therefore providing flexibility in how you define clouds and what you can do with cloud resources once they are created. For example:
•
•
•
OverDrive enables a domain for cloud management by assigning a cloud metamodel to it. The OverDrive administrator will need to activate the cloud environment on the stack of network equipment by assigning it to the site and by setting the pools of resources (VLANs and subnet address scope).
A service provider may use the REST API that is provided by OverDrive to construct a portal to manage cloud operations.
OverDrive provides a Cloud Configurator which makes use of this REST API for this purpose to both enterprises and service providers. It may be used as a reference for the construction of a customer-facing portal of your own.
You define clouds using the OverDrive Cloud Configurator user interface, which provides the following features.
•
•
•
•
•
Introducing metamodels
OverDrive provides and allows the construction of metamodels, which are represented by XML documents that describe the types of clouds and VMs that can be created with vCOM. These metamodels are accessible via the REST API and can be used to constrain and set attributes for a customized customer portal to present to end users.
Metamodels can therefore constrain the process of creating clouds with specific features. They contain parameters that may or must be specified when a cloud is created. OverDrive presents these in user-visible, usually editable, fields, often within a panel with related fields and choices. The same is true for VMs.
In other words, metamodels determine which parameters can actually be configured, as described by example in subsections in the "Supplying the right answers to the configurator" section.
Metamodels for a network may be set up during installation of OverDrive, or as written or adapted by OverDrive administrators. They generally are company-specific, as each company has its own way of representing its network.
The main concept of metamodels is that they can be deployed like easily modified cookie cutters to speed up and simplify cloud deployments. Used in conjunction with the OverDrive REST API, the metamodels become tools that allow service providers to set attributes that will be made available to users from the OverDrive Configurator or a customized portal.
Creating clouds
The browser-based Cloud Configurator is a good example of the use of the REST API to create clouds.
To create clouds:
1.
2.
3.
Note
4.
5.
The metamodel behind step 1
The XML metamodel, a behind-the-scenes document for the current user, looked something like this:
<metamodel name="virtenv-1" type="cloud"><description>Virtual environment cloud provider - Parent Cloud for VECP $Revision: 1.1 $</description>. . .OverDrive searched through various metamodels that had been previously imported into its database, looking for every metamodel of type cloud, provided that it was not actually a subcloud. For each one it found, it populated the drop-down list for the Add Cloud window, and, when the user chooses a cloud in that list, presents that cloud's description in the detail area.
How did OverDrive know if a metamodel were for a subcloud or not? It would have noticed if the <metamodel> element had been placed inside a <metamodels> element. For example:
<metamodel name="virtenv-1" type="cloud"><metamodels><!-- subclouds are defined by a metamodel within metamodels --><metamodel name="customer" type="cloud"></metamodels>. . .<metamodel>Assigning a cloud to a site
When you add a cloud, the second step is to assign it to a site in the domain in which you are adding it. The Cloud Configurator automatically presents, for Step 2, a drop-down list of available sites, for example:
Notice there is a tooltip saying, "Site to which the cloud is assigned." For this and the remaining panels, each field or checkbox has a tooltip.
The cloud you create will be provisioned at that site.
How the metamodel determines the parameters per screen
OverDrive automatically decides which screens are shown in which order and with which parameters.
So far, we have created a VPC, that is, a cloud as might be suitable for a company that provides clouds to customers. The clouds it provides them are VCDs, or subclouds, perhaps one per customer, with perhaps levels of subclouds below them.
Clouds define network and business policies, resources, and so on, at the cloud or a lower level. This allows VMs to be created within them. It also allows the VMs to be managed by OverDrive's network virtualization. The clouds might be configured to include DNS hosts for the cloud, VLAN pools, company-specific parameters, and perhaps DHCP service or NAT address translation ranges. Metamodels make it easy to set up these configurations, because they pre-supply parameters that can be tweaked by the user of the Cloud Configurator. They can be edited in the Command Center.
The Cloud Configurator marshals these configuration details into panels of related data fields, placing, for example, VLAN-related details on one panel, and NAT-related details on another. The number of panels (steps in the configuration) depends on the parameters specified in the metamodel for a cloud.
For example, consider the following parameters section of a metamodel. Any parameter whose name begins with tmpl or cloud is a candidate for being placed in a Cloud Configurator dialog box. If tmpl is followed by cloud, the parameter is a candidate for a dialog box when a cloud is being created; if followed by vm, then it is a candidate when a VM is being created, and so on.
The XML below produces two dialog boxes: one for VLAN parameters, and one for DNS. Because Step 1 is taken up by just choosing a metamodel and naming the resulting cloud, and Step 2 for assigning a cloud to a site, the following would specify Steps 3, and 4.
<metamodel name="virtenv-1" type="cloud"><description>Virtual environment cloud provider - Parent Cloud for VECP $Revision: 1.1 $</description>. . .<parameters><!-- Properties defined by the cloud metamodel type -->. . .<parameter name="tmpl.cloud.vlan.range" type="dt.range.vlanRange"/><parameter name="tmpl.cloud.vlan.pool" type="dt.subnet"/><parameter name="tmpl.cloud.vlan.mask"type="dt.integer.subnetMask">27</parameter>The dialog box that appears according to the tmpl.cloud.vlan.* parameters above is, for an example, as follows (the values here have been filled in by an actual metamodel):
The following XML would result in a dialogue such as the following (again, where the values have been filled in by an actual metamodel):
<parameter name="tmpl.cloud.dns.enable"type="dt.boolean">true</parameter><parameter name="tmpl.cloud.dns.address" type="dt.ipaddress"/><parameter name="tmpl.cloud.dns.credential" type="dt.password"/><parameter name="tmpl.cloud.dns.key" type="dt.string"/>. . .</parameters>. . .</metamodel>If the parameter is not known to OverDrive, the configurator will group it with any other unknown parameters and display them in a final panel, named Advanced.
Supplying the right answers to the configurator
To summarize so far: the Cloud Configurator lets you create clouds based on metamodels that specify parameters such as subnet address ranges, VLAN ranges, whether DNS is enabled and with which credentials and keys, the kinds of VMs that can be chosen, and so on. As mentioned above, this determines which panels open for you during the configuration, how many fields there are, and what type of information can be collected.
This section describes:
•
•
Note
Understanding address pools
OverDrive managed networks are assumed to have subnets and groups of IP address pools within which the networks exist. In OverDrive, these subnets and pools constitute what we call a coherent region. Every cloud and VLAN, for example, has to be encompassed within the subnets in the coherent region.
The coherent region is a group of subnets defined at generally high levels of the domain tree. They affect the tree all the way below the level at which they are defined. The coherent region doesn't have to be at the highest level. But, since it defines the subnets available to lower levels, it helps to place the coherent region higher. In practical terms, you might leave ROOT free from coherent region(s) and define them at customer levels below ROOT
Note that there might be subdomains which sub-administrators see as their top-level domain. They might not know there are higher domains. If you administer only subdomains, whoever assigned them to you should enter the subnets available in the comment field of the highest level domain to which you are assigned.
To check for subnets for a domain:
1.
2.
3.
4.
For more on configuring subnets for domains, sites, and VLANs irrespective of clouds, see the following subsections:
•
•
•
DNS parameters
When DNS is enabled, VMs created by OverDrive will have all interfaces dynamically registered with the DNS server prior to their being powered up.
Note
A company using OverDrive may decide to rather have the DHCP server manage DNS reservations for their virtual machines, in which case OverDrive will not be requested to manage DNS reservations.
To specify DNS parameters:
1.
2.
3.
The credentials in this dialog are typically a username (account) but may also be a fully qualified domain name. The password is for the account that will run the DHCP server service.
4.
VLAN parameters
The VLAN panel lets you define the pool of VLAN resources available in this cloud.
1.
The range specifies the entire set of VLANs for use by the cloud. This pool of VLANS will be used to draw from when assigning VLANs to clouds as they are needed.
2.
This is the pool of addresses that will be drawn from when VLANs are created. The mask defines the size of the pool and, consequently, the maximum number of VMs that can exist on that VLAN.
VLAN parameters (proprietary)
Any additional parameters you may see in the VLAN panel are company-specific, specifying perhaps a particular VLAN number and VLAN subnet for an infrastructure enclosure. Enter them as appropriate.
DHCP parameters
If you enable DHCP, OverDrive configures an IP Helper address for each VLAN that is created. This allows VMs to get an IP address from the DHCP server you specify.
1.
2.
NAT parameters
The NAT panel lets you provide a pool of public addresses that will be drawn from when creating public VMs. NAT rules are configurations that translate between the VM's public address and its address on the public cloud VLAN.
1.
This pool defines the entire public IP address pool for the cloud.
2.
3.
4.
5.
Click the delete button to delete a row.
6.
Note
Advanced parameters
The Advanced tab appears when the metamodel configures parameters and settings that OverDrive has not been told to configure on other panels.
OverDrive uses the Advanced tab to display such parameter, their initial settings, and so forth
1.
2.
Working with lists of clouds
When your cloud is created, you return to the initial dialog, with the cloud now listed in the domain tree on the left and pre-selected, for example:
1.
2.
3.
If any VMs have already been defined, they will be listed, along with their current status. Notice the MAC addresses for the internal machines. For details on setting up the VMs, see Chapter 6, "Enabling VMs."
4.
Use the cloud buttons in the top toolbar for the following functions:
Working with clouds in domain models
If you are an OverDrive administrator, you can use the Command Center to view detailed contents of the clouds.
If you are not an OverDrive administrator, but you have access to the Cloud Configurator, you may see some read-only information about various cloud aspects such as policies.
A subcloud context and summary contents
Clouds are very much like domains, except they contain additional information for managing dynamic cloud resources. They may, like domains, contain sites, business policies, and other domains or clouds.
Figure 5-1 An example cloud and subcloud
For example, the domain Cloud Operations, above, contains a hierarchy of subclouds, including:
•
•
Business policies within a cloud
If you clicked on the Remote Access to Edge business policy in the summary view:
To its right, in the Resources tab, you would see the participating resources, and the available resources, including VM1, as in the following figure:
A cloud's summary view
Finally, if you clicked on domain containing clouds, you would see its summary view:
Here, the summary view lists a subcloud NextGen Cloud), ports and protocols (ftp, http, et al.), policies, collections, resources, switches, and so on.
A cloud's metamodel
The summary view of a parent cloud shows the various cloud components.
1.
2.
3.
Scenario 3a: creating and configuring a cloud
Suppose you are an enterprise admin and you want to make it possible for several business units to create their own virtual data center (VDC).
Assume as a starting point that the metamodel has been created with a basic VDC defined in it that has one VLAN plus VMs that can attach to it.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
