Skip to content

Commit 9670a9d

Browse files
huypubhuypub
authored
Merge pull request #113366 from MicrosoftDocs/release-preview-vmware
Release preview vmware
2 parents 487ccc6 + 9cd50be commit 9670a9d

File tree

73 files changed

+1439
-3
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

73 files changed

+1439
-3
lines changed

‎articles/azure-vmware/concepts-identity.md

Lines changed: 56 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,56 @@
1+
---
2+
title: Concepts - Identity and access
3+
description: Learn about the identity and access concepts of Azure VMware Solution (AVS)
4+
ms.topic: conceptual
5+
ms.date: 05/04/2020
6+
---
7+
8+
# Azure VMware Solution (AVS) identity concepts
9+
10+
A vCenter server and NSX-T manager are provisioned when a private cloud is deployed. You use vCenter to manage virtual machine workloads and NSX-T manager to extend the private cloud software-defined network.
11+
12+
Access and identity management use CloudAdmin group privileges for vCenter and restricted administrator rights for NSX-T manager. This policy ensures that your private cloud platform can be upgraded automatically. This delivers the newest features and patches on a regular basis. See the [private cloud upgrades concepts article][concepts-upgrades] for more details on private cloud upgrades.
13+
14+
## vCenter access and identity
15+
16+
Privileges in vCenter are provided through the CloudAdmin group. That group can be managed locally in vCenter, or through integration of vCenter LDAP single sign-on with Azure Active Directory. You're provided with the ability to enable that integration after you deploy a private cloud.
17+
18+
The CloudAdmin and CloudGlobalAdmin privileges are shown in the table below.
19+
20+
| Privilege Set | CloudAdmin | CloudGlobalAdmin | Comment |
21+
| :--- | :---: | :---: | :--: |
22+
| Alarms | A CloudAdmin user has all Alarms privileges for alarms in the Compute-ResourcePool and VMs. | -- | -- |
23+
| Auto Deploy | -- | -- | Microsoft does host management. |
24+
| Certificates | -- | -- | Microsoft does certificate management. |
25+
| Content Library | A CloudAdmin user has privileges to create and use files in a Content Library. | Enabled with SSO. | Microsoft will distribute files in the Content Library to ESXi hosts. |
26+
| Datacenter | -- | -- | Microsoft does all data center operations. |
27+
| Datastore | Datastore.AllocateSpace, Datastore.Browse, Datastore.Config, Datastore.DeleteFile, Datastore.FileManagement, Datastore.UpdateVirtualMachineMetadata | -- | -- |
28+
| ESX Agent Manager | -- | -- | Microsoft does all operations. |
29+
| Folder | A CloudAdmin user has all Folder privileges. | -- | -- |
30+
| Global | Global.CancelTask, Global.GlobalTag, Global.Health, Global.LogEvent, Global.ManageCustomFields, Global.ServiceManagers, Global.SetCustomField, Global.SystemTag | | |
31+
| Host | Host.Hbr.HbrManagement | -- | Microsoft does all other Host operations. |
32+
| InventoryService | InventoryService.Tagging | -- | -- |
33+
| Network | Network.Assign | | Microsoft does all other Network operations. |
34+
| Permissions | -- | -- | Microsoft does all Permissions operations. |
35+
| Profile-driven Storage | -- | -- | Microsoft does all Profile operations. |
36+
| Resource | A CloudAdmin user has all Resource privileges. | -- | -- |
37+
| Scheduled Task | A CloudAdmin user has all ScheduleTask privileges. | -- | -- |
38+
| Sessions | Sessions.GlobalMessage, Sessions.ValidateSession | -- | Microsoft does all other Sessions operations. |
39+
| Storage Views | StorageViews.View | -- | Microsoft does all other Storage View operations (Configure Service). |
40+
| Tasks | -- | -- | Microsoft manages extensions that manage tasks. |
41+
| vApp | A CloudAdmin user has all vApp privileges. | -- | -- |
42+
| Virtual Machine | A CloudAdmin user has all VirtualMachine privileges. | -- | -- |
43+
| vService | A CloudAdmin user has all vService privileges. | -- | -- |
44+
45+
## NSX-T Manager access and identity
46+
47+
You access NSX-T Manager using the "administrator" account. That account has full privileges and enables you to create and manage T1 routers, logical switches, and all services. The full privileges in NSX-T also provide you with access to the NSX-T T0 router. A change to the T0 router could result in degraded network performance or a loss of access to a private cloud. To meet support requirements, it's required that you open an support request in the Azure portal to request any changes to your NSX-T T0 router.
48+
49+
## Next steps
50+
51+
The next step is to learn about [private cloud upgrade concepts][concepts-upgrades].
52+
53+
<!-- LINKS - external -->
54+
55+
<!-- LINKS - internal -->
56+
[concepts-upgrades]: ./concepts-upgrades.md

‎articles/azure-vmware/concepts-networking.md

Lines changed: 81 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,81 @@
1+
---
2+
title: Concepts - Network interconnectivity
3+
description: Learn about key aspects and use cases of networking and interconnectivity in Azure VMware Solution (AVS)
4+
ms.topic: conceptual
5+
ms.date: 05/04/2020
6+
---
7+
8+
# Azure VMware Solution (AVS) Preview networking and interconnectivity concepts
9+
10+
Network interconnectivity between your Azure VMware Solution (AVS) private clouds and on-premises environments or virtual networks in Azure enables you to access and use your private cloud. A few key networking and interconnectivity concepts that establish the basis of interconnectivity are described in this article.
11+
12+
A useful perspective on interconnectivity is to consider the two types of AVS private cloud implementations. The implementations with basic Azure-only interconnectivity and the implementations with full on-premises to private cloud interconnectivity.
13+
14+
The use cases for AVS private clouds include:
15+
- new VMware VM workloads in the cloud
16+
- VM workload bursting to the cloud
17+
- VM workload migration to the cloud
18+
- disaster recovery
19+
- consumption of Azure services
20+
21+
All use cases for the AVS service are enabled with on-premises to private cloud connectivity. The basic interconnectivity model is best suited for AVS evaluations or implementations that don't require access from on-premises environments.
22+
23+
The two types of AVS private cloud interconnectivity are described in the sections below. The most basic interconnectivity is "Azure virtual network connectivity", and it enables you to manage and use your private cloud with only a single virtual network in Azure. The interconnectivity described in "On-premises connectivity" extends the virtual network connectivity to also include interconnectivity between on-premises environments and AVS private clouds.
24+
25+
## Azure virtual network interconnectivity
26+
27+
The basic network interconnectivity that is established at the time of a private cloud deployment is shown in the diagram below. It shows the logical, ExpressRoute-based networking between a virtual network in Azure and a private cloud. The interconnectivity fulfills three of the primary use cases:
28+
- Inbound access to management networks where vCenter server and NSX-T manager are located.
29+
- Accessible from VMs within your Azure subscription, not from your on-premises systems.
30+
- Outbound access from VMs to Azure services.
31+
- Inbound access and consumption of workloads running a private cloud.
32+
33+
![Basic virtual network -to- private cloud connectivity](./media/concepts/adjacency-overview-drawing-single.png)
34+
35+
The ExpressRoute circuit in this virtual network to private cloud scenario is established when you create a connection from a virtual network in your subscription to the ExpressRoute circuit of your private cloud. The peering uses an authorization key and a circuit ID that you request in the Azure portal. The ExpressRoute connection that is established through the peering is a private, one-to-one connection between your private cloud and the virtual network. You can manage your private cloud, consume workloads in your private cloud, and access Azure services over that ExpressRoute connection.
36+
37+
When you deploy an AVS private cloud, a single /22 private network address space is required. This address space shouldn't overlap with address spaces used in other virtual networks in your subscription. Within this address space, management, provisioning, and vMotion networks are provisioned automatically. The routing is BGP-based and it's automatically provisioned and enabled by default for each private cloud deployment.
38+
39+
When a private cloud is deployed, you're provided with the IP addresses for vCenter and NSX-T Manager. To access those management interfaces, you'll create additional resources in a virtual network in your subscription. The procedures for creating those resources and establishing ExpressRoute private peering are provided in the tutorials.
40+
41+
You design the private cloud logical networking and implement it with NSX-T. The private cloud comes with pre-provisioned NSX-T. A Tier-0 Gateway & Tier-1 Gateway is pre-provisioned for the you. You can create a segment and attach it to the existing Tier-1 gateway or attach to a new Tier-1 gateway that you can define. NSX-T logical networking components provide East-West connectivity between workloads and also provide North-South connectivity to the internet and Azure services.
42+
43+
## On-premises interconnectivity
44+
45+
You can also connect on-premises environments to your AVS private clouds. This type of interconnectivity is an extension to the basic interconnectivity described in the previous section.
46+
47+
![virtual network and on-premises full private cloud connectivity](./media/concepts/adjacency-overview-drawing-double.png)
48+
49+
To establish full interconnectivity to a private cloud, you use the Azure portal to enable ExpressRoute Global Reach between a private cloud ExpressRoute circuit and an on-premises ExpressRoute circuit. This configuration extends the basic connectivity to include access to private clouds from on-premises environments.
50+
51+
An on-premises to Azure virtual network ExpressRoute circuit is required to connect from on-premises environments to your private cloud in Azure. This ExpressRoute circuit is in your subscription and isn't part of a private cloud deployment. The on-premises ExpressRoute circuit is beyond the scope of this document. If you require on-premises connectivity to your private cloud, you can use one of your existing ExpressRoute circuits or purchase one in the Azure portal.
52+
53+
Once linked with Global Reach, the two ExpressRoute circuits will route network traffic between your on-premises environments and your private cloud. The on-premises to private cloud interconnectivity is shown in the preceding diagram. The interconnectivity represented in the diagram enables the following use cases:
54+
55+
- Hot/Cold Cross-vCenter vMotion
56+
- On-Premise to AVS private cloud management access
57+
58+
To enable full connectivity, an Authorization Key and private peering ID for Global Reach can be requested in the Azure portal. You use the key and ID to establish Global Reach between an ExpressRoute circuit in your subscription and the ExpressRoute circuit for your new private cloud. The [tutorial for creating a private cloud](tutorial-create-private-cloud.md) provides you with the procedures for requesting and using the key and ID.
59+
60+
The routing requirements of the solution require you to plan private cloud network address spaces so that you avoid overlaps with other virtual networks and on-premises networks. AVS private clouds require a minimum of a `/22` CIDR network address block for subnets, shown below. This network complements your on-premises networks. In order to connect to on-premises environments and virtual networks, this must be a non-overlapping network address block.
61+
62+
Example `/22` CIDR network address block: `10.10.0.0/22`
63+
64+
The subnets:
65+
66+
| Network usage | Subnet | Example |
67+
| ------------------------- | ------ | -------------- |
68+
| Private cloud management | `/24` | `10.10.0.0/24` |
69+
| vMotion network | `/24` | `10.10.1.0/24` |
70+
| VM workloads | `/24` | `10.10.2.0/24` |
71+
| ExpressRoute peering | `/24` | `10.10.3.8/30` |
72+
73+
## Next steps
74+
75+
The next step is to learn about [private cloud storage concepts](concepts-storage.md).
76+
77+
<!-- LINKS - external -->
78+
[enable Global Reach]: https://docs.microsoft.com/azure/expressroute/expressroute-howto-set-global-reach
79+
80+
<!-- LINKS - internal -->
81+

‎articles/azure-vmware/concepts-private-clouds-clusters.md

Lines changed: 78 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,78 @@
1+
---
2+
title: Concepts - Private clouds and clusters
3+
description: Learn about the key capabilities of Azure VMware software-defined data centers and vSphere clusters in VMware Solution on Azure by VMware.
4+
ms.topic: conceptual
5+
ms.date: 05/04/2020
6+
---
7+
8+
# Azure VMware Solution (AVS) Preview private cloud and cluster concepts
9+
10+
The Azure VMware Solution (AVS) delivers VMware-based private clouds in Azure. The private clouds are built from clusters of dedicated bare-metal hosts and are deployed and managed through the Azure portal. Clusters in private clouds are provisioned with VMware vSphere, vCenter, vSAN, and NSX software. AVS private cloud hardware and software deployments are fully integrated and automated in Azure.
11+
12+
There's a logical relationship between Azure subscriptions, AVS private clouds, vSAN clusters, and hosts. In the diagram, two private clouds in a single Azure subscription are shown. Private clouds represent a development and a production environment, each with their own private cloud. In each of those private clouds there are two clusters. To show the lower potential needs of a development environment, smaller clusters with lower capacity hosts are used. All of these concepts are described in the sections below.
13+
14+
![Image of two private clouds in a customer subscription](./media/hosts-clusters-private-clouds-final.png)
15+
16+
## Private clouds
17+
18+
Private clouds contain vSAN clusters that are built with dedicated, bare-metal Azure hosts. Each private cloud can have multiple clusters, all managed by the same vCenter server, and NSX-T manager. You can deploy and manage private clouds in the portal, from the CLI, or with PowerShell. As with other resources, private clouds are installed and managed from within an Azure subscription.
19+
20+
The number of private clouds within a subscription is scalable. Initially, there's a limit of one private cloud per subscription.
21+
22+
## Clusters
23+
24+
You'll create at least one vSAN cluster in each private cloud. When you create a private cloud, there's one cluster by default. You can add additional clusters to a private cloud using the Azure portal or through the API. All clusters have a default size of three hosts and can be scaled from 3 to 16 hosts. The type of hosts used in a cluster must be the same type. The hosts types are described in the next section.
25+
26+
Trial clusters are available for evaluation and they're limited to three hosts and a single trial cluster per private cloud. You can scale a trial cluster by a single host during the evaluation period.
27+
28+
You create, delete, and scale clusters through the portal or API. You still use vSphere and NSX-T Manager to manage most other aspects of cluster configuration or operation. All local storage of each host in a cluster is under control of vSAN.
29+
30+
## Hosts
31+
32+
Hyper-converged, bare-metal infrastructure nodes are used in AVS private cloud clusters. The RAM, CPU, and disk capacities of the host is provided in the table below.
33+
34+
| Host Type | CPU | RAM (GB) | vSAN NVMe cache Tier (TB, raw) | vSAN SSD capacity tier (TB, raw) |
35+
| :--- | :---: | :---: | :---: | :---: |
36+
| High-End (HE) | dual Intel 18 core 2.3 GHz | 576 | 3.2 | 15.20 |
37+
38+
Hosts that are used to build or scale clusters are acquired from an isolated pool of hosts. Those hosts have passed hardware tests and have had all data securely deleted from the flash disks. When you remove a host from a cluster, the internal disks are securely wiped and the hosts are placed into the isolated pool of hosts. When you add a host to a cluster, a sanitized host from the isolated pool is used.
39+
40+
## VMware software versions
41+
42+
The current software versions of the VMware software used in AVS private cloud clusters are:
43+
44+
| Software | Version |
45+
| :--- | :---: |
46+
| VCSA / vSphere / ESXi | 6.7 U2 |
47+
| ESXi | 6.7 U2 |
48+
| vSAN | 6.7 U2 |
49+
| NSX-T | 2.5 |
50+
51+
For any new cluster in a private cloud, the version of software will match what is currently running in the private cloud. For any new private cloud in a customer subscription, the latest version of the software stack is installed.
52+
53+
The general upgrade policies and processes for the AVS platform software is described in the Upgrades Concepts document.
54+
55+
## Host maintenance and lifecycle management
56+
57+
Host maintenance and lifecycle management are done without impact on the capacity or performance of private cloud clusters. Examples of automated host maintenance include firmware upgrades and hardware repair or replacement.
58+
59+
Microsoft is responsible for lifecycle management of NSX-T appliances such as NSX-T Manager and NSX-T Edges. Microsoft is also responsible for bootstrapping network config, such as creating the Tier-0 gateway and enabling North-South Routing. As an administrator to your AVS private cloud, you are responsible for NSX-T SDN configuration like network segments, distributed firewall rules, Tier 1 gateways, and load balancers.
60+
61+
> [!IMPORTANT]
62+
> An AVS admin must not modify the configuration of NSX-T Edges or Tier-0 Gateway. This may result in a loss of service.
63+
64+
## Backup and restoration
65+
66+
Private cloud vCenter and NSX-T configurations are backed up hourly. Backups are kept for three days. Restoration from a backup is requested through a Service Request in the Azure portal.
67+
68+
## Next steps
69+
70+
The next step is to learn [networking and inter-connectivity concepts](concepts-networking.md).
71+
72+
<!-- LINKS - internal -->
73+
74+
<!-- LINKS - external-->
75+
[VCSA versions]: https://kb.vmware.com/s/article/2143838
76+
[ESXi versions]: https://kb.vmware.com/s/article/2143832
77+
[vSAN versions]: https://kb.vmware.com/s/article/2150753
78+

0 commit comments

Comments
 (0)