Create virtual networks across the region in cloud computing

We are very pleased to announce that you can now create a virtual network (vnet) across the entire region. When you create a new virtual network, you can associate it with a zone instead of the Association group. New services deployed to a zone virtual network can use any services provided by the zone (such as a8/a9 size, internal load balancing, reserved IP, instance-level public IP).

Before this feature is released, Vnets can only bind to one expansion unit, or more accurately, the Association group. An association group is a grouping concept that refers to a part of a data center or, in other words, a certain number of servers. Vnet are bound to a group of associations and are indirectly bound to a set of servers, so programs cannot be deployed to servers outside this extension unit.

before:

However, these limitations are eliminated through a zone virtual network, because the scope of the virtual network is the entire region and not just the association group.

Right now:

Key Scenarios

The following are key scenarios for zone virtual network enablement:

new VMS such as A8 and A9 can be deployed to virtual networks, and virtual networks can contain VMS of other dimensions. New features, such as reserved IP, internal load balancing, and instance-level public IP virtual networks can be seamlessly extended to use the entire area's capacity, but we still limit the vnet to include http://www.aliyun.com/zixun/aggregation/9392. HTML >2048 a virtual machine. You do not need to create an association group before you create a virtual network. Deployment into vnet does not have to be in the same association group.

Instructions for use

The steps to create a zone virtual network are similar to today's steps, but one difference is that when you define vnet in a network configuration file, you use the Location property instead of the association group:

Virtual network definition (Legacy):

<virtualnetworksitename= "Vnetdemo" affinitygroup= "Vnetdemoag" >

Virtual network definition (new):

<virtualnetworksitename= "Vnetuswest" location= "West US" >

Note: You cannot convert an existing virtual network from Affinitygroup to LOCATION[DX1]. To obtain a zone virtual network, you must use the Location property to create a new virtual network. For more detailed information, see the FAQ section below.

Portal experience:

Until now, zone virtual networks cannot be created through portal workflows. Support for this feature will be added in the near future. However, customers can still create zone virtual networks using the Import/Export feature, as follows:

1. Export the current network configuration file

2. Save the file to a local disk

3. Edit the file to add a new virtual network as follows:

<?xmlversion= "1.0" encoding= "Utf-8"?>

<networkconfigurationxmlns:xsd= "Http://www.w3.org/2001/XMLSchema" xmlns:xsi= "http://www.w3.org/2001/ Xmlschema-instance "xmlns=" Http://schemas.microsoft.com/ServiceHosting/2011/07/NetworkConfiguration ">

<VirtualNetworkConfiguration>

<VirtualNetworkSites>

<!–regional Virtual Receptacle Definition–>

<virtualnetworksitename= "Vnetuswest" location= "West US" >

<AddressSpace>

<AddressPrefix>192.168.50.0/24</AddressPrefix>

<AddressPrefix>192.168.51.0/24</AddressPrefix>

</AddressSpace>

<Subnets>

<subnetname= "Frontendsubnet" >

<AddressPrefix>192.168.50.0/24</AddressPrefix>

</Subnet>

<subnetname= "Backendsubnet" >

<AddressPrefix>192.168.51.0/28</AddressPrefix>

</Subnet>

<subnetname= "Gatewaysubnet" >

<AddressPrefix>192.168.51.16/28</AddressPrefix>

</Subnet>

</Subnets>

</VirtualNetworkSite>

</VirtualNetworkSites>

</VirtualNetworkConfiguration>

</NetworkConfiguration>

4. Complete the new virtual network creation process as follows:

5. Select the edited network profile from the local disk

6. Click OK and complete the import process.

This creates a new zone virtual network.

Powershell Experience:

Download and install the latest Azure Powershell

To create a zone virtual network (Powershell cmdlet):

1. Download the current network profile from Azure

Get-azurevnetconfig-exporttofile "C:\Users\narayan\Documents\TechEdDemo\Netcfg.xml"

2. Edit the exported/created file and fill out the virtual network details, as shown in step 3 of the previous section

3. Create a zone virtual network by running the following command:

Set-azurevnetconfig-configurationpath "C:\Users\narayan\Documents\TechEdDemo\Netcfg.xml"

4. This creates a regional virtual network.

Common

What areas are supported for regional virtual networks?

Azure supports the regional virtual network in all areas of public Azure (except for the currently previewed version of Southern Brazil) listed here.

* Regional vnet are also not supported in the eastern and northern parts of China and will be supported in the near future.

How do I convert my existing virtual network into a regional virtual network?

Azure does not now support this feature. To obtain a zone virtual network, customers must create a new regional virtual network as described in this article. Shortly thereafter, however, all existing vnet bound to the association group will migrate to the range. Stay tuned for more updates on this blog.

Can my existing vnet connect to the new area Vnet?

You can use the new vnet to Vnet connection feature to connect your existing vnet to the newly created zone vnet. For more information see this link

Can the performance degradation of services running within a zone virtual network occur?

A virtual network is just a logical boundary and does not specify where the deployment in Vnet actually goes. If you need to place the service in the same association group for some reason, you can still perform the operation within the zone virtual network. At deployment time, you must specify the association group to which the managed service should be bound. The only limitation is that the Association group and the zone virtual network must belong to the same area.

If a managed service is not bound to the association group and the service is deployed directly to the zone virtual network, the deployment is placed in the expansion unit within the zone to which the virtual network is bound.

What is the relationship between the newly announced features (reserved IP, internal load balancing, and instance-level public IP) and zone virtual networks?

These newly advertised features are managed at the regional level, so these features apply only to deployments into a zone virtual network.

Will regional virtual networks be charged?

No, the zone virtual network is the platform enhancements and will not be charged.