Managing Azure
This topic explains how to get started with Microsoft® Azure in Commander, and also explains how managing Azure services differs from managing your on-premise VMware and Hyper-V services. This topic assumes that you understand the basics of Azure.
In this topic:
Getting started
To manage Azure services with Commander, here's how to get started:
- Create a Microsoft Azure account. Commander uses your account to connect to Azure.
- Create an Azure subscription. You do this in the Azure Management Portal. All of the private images and instances belonging to that subscription become a single managed system in Commander. It's a good idea to have a small number of Azure subscriptions, so that you can keep the number of managed systems to a minimum.
- Create an identity for the Commander application. You do this in the Azure Management Portal. This involves creating an Azure Active Directory application and service principal that can access Azure resources. To learn how, see the following article from the Microsoft documentation:
- Record the subscription ID. You find this information in the Azure Management Portal. For example:
- Record the application ID and authentication key. You find this information in the Azure Management Portal. To learn how, see the following article from the Microsoft documentation:
- Record the tenant ID. You find this information in the Azure Management Portal. To learn how, see the following article from the Microsoft documentation:
- Assign the Commander application to a role. To learn how, see the following article from the Microsoft documentation:
- Optional: If Internet access is established through a web proxy server, integrate your web proxy server with Commander. See Connecting Public Clouds to Commander through a Web Proxy Server.
- Add your Azure subscription to Commander as a managed system, using the Subscription ID, tenant ID, application ID and authentication key. See Adding Managed Systems.
- (Optional) Add private images to your subscription. You do this in the Azure Management Portal. Commander also displays a configurable set of common public Azure images.
- Add images to the Service Catalog. See Managing the Service Catalog.
For Application Type, select Web app / API.
To learn what Commander features are supported for Azure, see Commander Capability Matrix.
How Commander works with Azure
Infrastructure view
To learn about how the Infrastructure, Applications, and Storage views differ for Azure managed systems, see Commander Views. Because Azure doesn't provide visibility of its physical compute infrastructure, hosts and clusters are not shown in Commander.
Supported Azure resources
Commander allows you to manage the Azure resources detailed in the following table.
| Infrastructure / Resource Type | Details |
|---|---|
|
Virtual Machines |
Azure virtual machines can be managed from Commander's Infrastructure and Applications views and can be deployed through the service catalog. Azure VMs are deployed using preconfigured instance types rather than fine-grained configuration of CPU, memory, storage and networking resources. You add Azure images from your Azure subscription to the Commander Service Catalog. Commander also provides a configurable set of popular public images. When you add an image to the service catalog, you choose the instance types to make available to users when they request that image. Commander supports reconfiguring Azure VM resources both manually and through a service change request. Instance types added between Commander releases are fully supported in the next Commander release. If a new instance type is added between Commander releases, the instance type won't be available in Commander until a new instance with this instance type is deployed in the public cloud and Commander is synchronized with the public cloud. The new instance type will then be available for use in Commander deployments, but resource and cost information won't be available, and quota won't be calculated. |
|
Images |
Azure images are equivalent to templates and are displayed as templates in Commander. Azure provides a set of public images. Any images you create are private images. Commander enables you to deploy private images as well as a set of popular public images. |
|
Disks |
Commander retrieves information for disks that are attached to Azure VMs. See also Storage Accounts below. |
|
Network Interfaces |
Commander supports the assignment of network interfaces to VMs during manual and automated deployment. |
|
Availability Sets |
An availability set ensures both fault tolerance and service availability during upgrade. You can assign the availability set through the service catalog, as well as during manual deployment. |
|
Images |
Azure images are equivalent to templates and are displayed as templates in Commander. Azure provides a set of public images. Any images you create are private images. Commander lets you deploy private images as well as a set of popular public images. |
|
Regions |
Azure operates datacenters in global regions. See Selecting Public Cloud Regions to Display to learn which Azure regions Commander displays by default, and how to change this. |
|
Resource Groups |
Each Azure VM must be deployed into a resource group, which provides lifecycle management capabilities. Resource groups are created in a specific region, but the contents of a resource group can span regions. You can assign the resource group through the service catalog, as well as during manual and automated deployment. |
|
Networks |
An Azure Virtual Network enables you to create a logically isolated section in Azure and securely connect it to your on-premises datacenter or a single client machine using an IPsec connection. Commander supports the assignment of network zones to virtual networks. You can also assign virtual networks during manual and automated deployment. |
|
Network Security Groups |
Security groups are like firewall rules: they define inbound and outbound rules with source and target IP restrictions and port definitions. You can assign a security group during manual and automated deployment. |
|
Commander supports both managed and unmanaged storage accounts. With managed storage, Azure automatically manages the availability of disks to provide data redundancy and fault tolerance, so that you don't need to create and manage storage accounts. Managed Disks may not be available in all regions. It's similar to AWS storage, where you can select between SSD and HDD disks. The managed storage account can't be assigned a Commander storage tier. With unmanaged storage, you must create and manage storage accounts yourself. It's analogous to vCenter datastores. Because Azure provides more than six types of unmanaged storage account, you need to decide how best to map storage accounts to Commander's six storage tiers. By default, all unmanaged storage accounts are assigned storage tier 1. See also Setting the Storage Tier for a Datastore or Datastore Cluster. An Azure VM may use storage that spans multiple resource groups, but not multiple regions. Azure storage accounts are displayed as datastores in Commander. You can assign the storage account through the service catalog, as well as during manual and automated deployment. See also Storage view. Because Azure storage is elastic, Commander properties and variables related to capacity (for example, provisioning level) don't apply to Azure. Likewise, reports based on these properties don't include data for Azure (for example, the Over-provisioned Disk Summary Report). During regular synchronization with Azure, Commander collects the storage used by disks, but not the total used storage. |
Updates from Azure
Changes made to an Azure managed system within Commander are displayed as soon as the task has finished, just as they are with vCenter and SCVMM managed systems. Unlike vCenter and SCVMM, however, Commander retrieves changes made within Azure and generates events based on these changes at a configurable update frequency. By default, Commander waits 60 minutes between updates. You can change this interval, but we recommend keeping at least 60 minutes between updates.
Caution: More frequent updates (meaning lower values for this setting) may impact Commander performance, especially in large installations.
You can manually resynchronize the inventory, just as you can with vCenter and SCVMM.
Public Azure images
The Public Images folder in the Applications view provides a set of popular images from the Azure Marketplace. The default images provided can be deployed in any Azure region. You can add, remove and modify images in this folder by editing the following configuration file:
<Commander_install_dir>\tomcat\common\classes\arm-images.xml
Save a backup copy of this file before editing.
Elements in the ARM Public Images XML Configuration File
|
Element |
Description |
Example |
|---|---|---|
|
image name |
The display name of the image in Commander. You can set this name to whatever you like. |
Ubuntu Server 16.04.0-LTS |
|
region |
The Azure region where you want Commander to look for the image, in command-line format |
centralus If the image is not available in the region specified, deployment will fail. All of the default public images referenced in the file are available in all Azure regions. |
|
publisher |
The publisher of the image |
Canonical |
|
offer |
The image offer |
UbuntuServer |
|
sku |
The image SKU |
16.04.0-LTS |
|
osDiskSizeGb |
The default size of the OS disk, in GiB |
40 |
You can add these public images to the service catalog, and you can deploy them manually. Note that the cost of these templates is always displayed as $0. To learn more, see:
Authentication
Guest OS credentials must be supplied in order to deploy an Azure prepared image. These credentials can be either username/password or, for Linux prepared images, RSA key credentials.
User names must be between one and 64 characters long, and must not include reserved words or unsupported characters.
Passwords must be between 12 and 72 characters long and must include three of the following: one lowercase character, one uppercase character, one number and one special character.
Due to an Azure limitation, all images are displayed as generalized images.
Automated deployment
Microsoft Azure VMs (instances) must be deployed in the same Azure region as their source template (image). Therefore, if you're deploying to multiple Azure regions, you need to configure a service catalog entry and a deployment destination for each region.
See Azure: Configuring destinations for automated deployment.
Azure has strict rules for VM names. If you're deploying Azure services, to prevent automated deployment failure, you must ensure that your naming convention adheres to these rules. VM names must be between 3 and 15 characters, must contain only letters, numbers and hyphens, must start and end with a letter or a number, and must not contain spaces. The default VM naming convention in new installations of Commander adheres to these rules.
See Customizing Naming Conventions.
Power scheduling
To save public cloud costs, Commander supports the ability to schedule a power on/off cycle for VMs. See Configuring VM Power Schedules for more details.
Costing
Commander includes an Azure cost model that is automatically applied when an Azure subscription is added as a managed system. Azure doesn't provide a breakdown of CPU, memory, and operating system costs. Instead, Azure instance costs are taken from Azure's On-Demand Instance Prices for the particular instance type requested. For more details, see Configuring Cost Models.
Azure resource and storage costs are updated with every Commander release. However, if you have customized storage tier costs, your custom costs are not overwritten on upgrade.
To make sure your Azure list prices are current, you can use the command workflow Update Public Cloud List Prices. For more information, see Updating Public Cloud List Prices.