[MUSIC] >> Hi, everyone. Welcome to the Azure VMware Solution- End
to End Networking session. My name is Amit Aneja and I'm a
Product Manager at Microsoft, working on Azure VMware Solution. I'm responsible for
the networking portion of Azure VMware Solution. Let's take a quick
look at the agenda. We'll cover basics of Azure. This is a quick section. I don't want to go too deep
into the Azure terminology. This is for VMware VI admins who may or may not have
exposure to Azure. Then we're going to get to
the meat of the presentation, which is Azure VMware Solution
Network Connectivity as to how you connect to Azure VMware Solution
from your on-premise environment. Then we'll switch to
networking within an AVS software defined
datacenter or a private Cloud. Finally, we'll talk about one of the integrations of AVS
with Azure Native Services, and we'll go from there. Before we get started on the
agenda of our presentation, I want to take a minute and talk about what Azure VMware Solution is. What is AVS? It's a first party offering from Microsoft that enables you to bring your native VMware
workloads to Azure. It's a full VMware SDDC stack that
consists of ESXi for compute, NSX for networking, vSAN for storage, and HCX for your workload mobility. This is all running on top of Azure bare metal
dedicated infrastructure. When you provision
an SDDC or when you provision a private Cloud in Azure, what you get is you
get access to vSphere, you get access to vCenter, HCX, NSX-T Manager, so all of
this is pre-provisioned for you. Now, we do have a
dedicated session on this, which is AVS Solution overview that I'm showing in
the reference section. What's new for Azure VMware Solution. So I highly recommend that you take a look at that session
if you haven't already, and come back to this presentation
for a networking overview. Let's get started with our agenda, which is basics of Azure. This is Azure 101. Let's start with subscription. A subscription is simply an
agreement with Microsoft to use one or more Microsoft Cloud
platform or services. Simply put, you need an Azure subscription to
get started with Azure. Moving on to Virtual Network. This is the fundamental
foundational building block for your private network in Azure. Think of this as an
isolated network in your on-premise world which can
be connected to other networks. You typically spin up a VNet or Virtual Network
in a specific Azure region. You provide a subnet which can be sliced into
multiple smaller subnets. This is where all your
workloads will be running and all your Azure Native VM workloads will be running and deriving
their network information. Moving on to ExpressRoute. An ExpressRoute is a
private connection between Azure datacenter and
your infrastructure in on-premise or in a Colo. Here in this diagram, I'm showing one ExpressRoute, but typically you will have two
ExpressRoute for redundancy. This would typically be done
through a connectivity provider. This connection would be provided through our connectivity provider. Now, to provide this
connectivity on the Azure side, we have something called as
Microsoft Enterprise Edge. These are two routers and
Active/Active HA configuration. These routers would enable a connectivity provider
to connect their circuits directly to their
datacenter and providing you that dedicated connectivity. Moving on to Virtual Network gateway. A Virtual Network gateway is
simply a gateway to your VNet. It provides you connectivity from
your Azure Virtual Networks, Azure VNets to your on-premise. It could provide that
connectivity either through VPN or ExpressRoute, depending upon the gateway
that you have spun up. These are of two types, VPN
or ExpressRoute gateway. Moving on to another important
term which is Global Reach. Now, by definition,
Global Reach is simply stitching two ExpressRoute
circuits, and by definition, it would connect your two
on-premise datacenters to a more on-premise datacenters through Microsoft's Azure Global
Backbone Network. Now, what do I mean by that?
Let me explain with a diagram. In the first diagram, I'm showing two datacenters, San Francisco and London. Both of these datacenters, they connect to their respective
VNets in their specific region. San Francisco connects to US vast Azure VNet and London
connects to UK South Azure VNet, and this connectivity is
through ExpressRoute. So you have two
ExpressRoute circuits going from your on-premise to Azure VNets. Now, traditionally if you were to go between San Francisco
and London datacenter, or if you were to talk between
10.0.1.0 subnet, 10.0.2.0 subnet, you would typically go through connectivity provider like
you would have some kind of MPLS connection or some kind
of inter-DC connection. Now, with Global Reach, since you already have two ExpressRoute circuits
going to do your Azure VNets, what we are doing in
the background is, and this is done via
one single command, you are simply stitching
the ExpressRoute circuit and exchanging the routes over it. Now when you enable the Global Reach, you go from San Francisco
to London datacenter. You go on ExpressRoute, go over Microsoft Azure
Global Backbone Network, and go to your London datacenter. That's one use of Global Reach. With respect to Azure
VMware Solution, we are using this, again, we are using the same concept, stitching two different
ExpressRoute circuits, one that's already connected
from your on-premise to Azure. Another one is what we
pre-provision for you when we create a SDDC in Azure. I'm going to touch upon
that in next section, which brings me to Azure VMware
Solution Network Connectivity. How do you connect to an
Azure VMware Solution from your on-premise environment or
from your Virtual Networks. Now, here I have on the top, I'm showing a customer datacenter, which is a full VMware stack. It could be full or
partial VMware stack here. I'm showing vCenter,
your typical storage, it could be vSAN networking, it could be VDS, or it could be NSX, and then for the compute
part you have ESXi. This datacenter is connected over an ExpressRoute circuit
to something called as Microsoft Enterprise Edges to access all the Azure
Native workloads. Now, let's add Azure VMware
Solution to the mix. Now, I'm adding Azure
VMware Solution to the mix, and you'll see something called as Dedicated Microsoft
Enterprise Edges or DMSEE. Now, connectivity to and
from AVS is provided through these Dedicated Microsoft
Enterprise Edges whether you're going to your on-premise environment or you're going to your Azure VNets. Now, to provide this connectivity, we pre-provision an ExpressRoute
between DMSE and MSEE. This ExpressRoute is a part of SDDC provisioning when you create a private Cloud in AVS
or an SDDC in AVS. This connectivity is by
default provided for you. Now, using the concept
of Global Reach, and we simply stitch the two circuits together, exchange
routing information. Now, you can access your on-premise
workloads from AVS or you can access AVS from your on-premise workloads
just by using Global Reach. Again, this was just one command that you can enable or we
can enable that for you. Finally, you can use HCX on both
sides to pair the two sites, to pair the two SDDCs and migrate your workloads from on-premise
to AVS or the other way around. Like I said earlier, AVS comes pre-provisioned
with vCenter, ESXi, NSX Manager, and HCX manager. This is how your traffic
flow is going to look like when you are coming
from on-premise to AVS, or when you are migrating VM from
AVS to on-premise environment. We have talked about connectivity from your on-premise
environment to SDDC, but what if you have
workloads in Azure VNet. You're running in a hybrid
environment where you have VMware native workloads in AVS, and you have Azure Native workloads, or you're using Native Azure
services in Azure VNet. How do you connect to that? Now, as soon as you enable Global Reach, the connectivity from AVS to all your VNets which
are connected on that ExpressRoute is by default enabled. You don't really have to do
any special configuration to reach your Azure VNets. This is enabled as soon as
Global Reach is enabled. Now, this is ideal in most cases. But in some cases, this Microsoft Enterprise
Edge that I'm showing here, it could be sitting a
few milliseconds away from Azure DC in a
Azure Edge location. In that case, the traffic from your AVS would go to that Edge
location and come back to VNet. Now, if you're looking
for performance, you might want to do this. You could just simply
spin up a ER gateway, which is a Virtual Network
gateway of type ER and consume the ExpressRoute circuit
that we pre-provision for you, so that you have direct
connectivity to AVS workloads, now, because these two workloads, Azure native workloads
and AVS workloads, they are sitting right next to each
other in the Azure Datacenter. Moving on to what other kind of connectivity options we have
in Azure VMWare Solution. I mentioned you connect to Azure VMware Solution from your
on-premise using an ExpressRoute. We also provide VPN connectivity, but this is in POC mode or
30 day trial only at HCX, which is VMware's
hybrid Cloud extension. The migration tool from on-premise to AVS is not supported over VPN. But again, this is supported for
your trial or POC mode only. The way we provide
this connectivity is, you have a VPN coming in from your on-premise to a VPN
gateway in Azure VNet. This is powered through VWAN Hub. Azure Virtual WAN Hub, and then this traffic
is taken over to ER gateway and sent over
to AVS environment. Now, this kind of connectivity is not possible when you're
using a traditional VNet. The transit routing from
VPN gateway to ER gateway, that doesn't really
work in Azure VNet. That's why we are using
Azure Virtual WAN to provide this connectivity where this transit routing is supported. Moving on to Networking within an AVS Software Defined Data Center. You talked about the options, how to connect to AVS, Azure VMware Solutions Software Defined Data Center,
or a private Cloud. Now, we're going to look at
how the networking looks like within an SDDC that
you have defined in Azure, which brings me to this slide. Like I mentioned earlier,
when you recreate AVS SDDC, we pre-provision vCenter for you, we install NSX Manager for you, we install HCX for you. Now, with respect to NSX, if you've used NSX in an
On-premise environment, you know that there are multiple
steps to get started with NSX. First step is like you have
to install NSX Manager and integrate that with vCenter so that
you can talk to the workloads. You have to install NSX-T
software on the Host, you have to install NSX-T Edges, which are your north-south gateway, and you have to configure them as transport nodes so that they
can talk in terms of overlay. Now, in case of AVS, we take care of all of these
steps in the background for you. We set up NSX-T Managers for you, we have a Virtual IP
configured for them, for redundancy, we integrate
this with vCenter. We install the NSX-T bits on
the Host, we install the Edges, we configure both Hosts and
Edges as transport nodes, and we protect these
control plane objects. Anything that we are deploying
for you in terms of NSX, we are protecting that by using
principal identity so that a misconfiguration by a user doesn't really cause a
service level failure. There is clear separation of
control between AVS control plane, what we did in the background, and an AVS tenant admin
as to what you would do. This is the system part of the
NSX-T that we are doing for you. Moving onto the
logical configuration, we also plumb in some
logical configuration for you so that when
you create an SDDC, the SDDC is ready for consumption. While you come in, you create some
segments or layer to switches, and you can start
consuming the platform. What do we do in the background
for logical configuration? We create a Tier-0 Gateway, which is an active [inaudible]. This Tier-0 is your
north-south gateway to your infrastructure if you
were to go to Azure VNets, or if you were to go to your
On-premise environment, this Tier-0 provides you that
north-south connectivity. We pre-provision BGP Peerings so that it can already talk
to the AVS underlay, and we protect these BGP Peerings and this Tier-0 using
principal identity. We also pre-provision
a Tier-1 gateway, and if you're not familiar with
this multi-tiered routing of NSX, it's simply at this Tier-0 gateway, is your north-south gateway
for your workloads. Tier-1, think of this
as your inter-tenant or inter-department logical gateway. If you have multiple departments
like HR, finance, marketing, you can have multiple Tier-1
gateways and you could define multiple policies
depending upon that group. We pre-provision a
Tier-1 for you as well, wherein you can use
multiple services. We enabled route redistribution,
route advertisements. As soon as you come in and you want to just simply define a segment, and a segment is simply just, think of this as a layer2
to broadcast domain. As soon as you define a logical
switch or a segment and you connect it to your VM
workloads from your vCenter, you have end-to-end connectivity, you have east-west connectivity, you have north-south connectivity to Azure services and to your
On-premise environment. We also have an option
for Internet access, which is enabled by default, and you can turn it off if you don't want Internet access
for your workloads. This part, all of the configuration
that I've talked about, this is pre-provision for you so that you don't really have
to worry about routing, stitching, and how things work
in NSX-T. What can you do now? You can create overlay
segments, logical switches, and connect workloads to it
to provide them connectivity. You can deploy additional
Tier-1 gateways. You can deploy
distributed services like distributed firewall for your
east-west micro-segmentation, you can deploy stateful
services like Gateway Firewall, which is L4 to L7 capable. For your interdepartment
communication or interdepartment firewall
or inter-tenant firewall, you can use a Load
Balancer on Tier-1, you can instantiate DHCP services, which is DHCP Server or DHCP Relay, and you can configure DNS
forwarding on Tier-1 Gateway. These are some of the
things that you can do as an AVS tenant admin. Now, to simplify it even further, we understand that NSX-T
is a newer platform, so many of the VMware
infrastructure admins may or may not have exposure to it. To simplify the NSX-T
consumption for VI admins, we have a simplified NSX-T
experience in Azure portal, wherein you can simply
define a segment. This is similar to your distributed VDS Port Group that you configured in your
On-premise VDS environment, or NSX-T segment that you could configure in your
On-premise environment. Here you define, this is
my segment, you name it, you give a subnet to this segment, and you define a gateway, and we take care of all the plumbing
in the background. In addition to this, we provide DHCP, DNS, the DNS forwarding capability
from the Azure portal itself. Again, we spin up, you simply define DHCP or DNS and
we take care of the stitching like attaching it to a Tier-1 and things like that in
the background for you. To complete the story, we also have Port Metering
so that for troubleshooting, you can simply compare and
configure a logical span, and take a look at whether
the traffic is flowing through your network or not. Moving on to the next slide, which is networking in an
Hybrid Cloud environment. In the first section, we talked
about how to connect to AVS. In the second section we talked about the networking within an AVS. This slide is putting it all together and showing you
end-to-end connectivity. On the left, I have
On-premise deployment, and in this case, an
On-premise deployment, I'm using NSX-T, and you
have your On-premise WAN infra and your Tier-0, Tier-1. In AVS, again, you have Tier-0, Tier-1 connected to AVS Underlay. Moving on to connectivity. Again, these two environments are configured and connected
through ExpressRoute. You can establish HCX, you can connect the two
sides, establish hybridity, and you could use cold
migration, bulk migration, or use L2 extension to
extend your L2 segments from On-premise to AVS environment. Moving on to the next topology, where I'm using VDS in an
On-premise environment and NSX-T. Again, NSX-T is the
default networking stack in Azure VMware solutions, but you could have VDS On-premise. Here, I'm using a Web DVPG, which is DV Port Group. Again, using HCX, you can create site peering,
establish hybridity, and use cold migration, bulk migration, or use L2 extension. In this case, I'm showing
you L2 extension from your On-premise to your
NSX-T stack in AVS. As soon as you go to
HCX and simply say, I want to extend this network, this Web DVPG to my target site, which is AVS, this segment will
be pre-provisioned for you. Finally, you can just
use VMotion to move your workloads from source to target. Once you're done moving
all your workloads from source to destination, you can simply say
unextend the segment and all your traffic would be flowing
through AVS infrastructure. Moving on to the last section, which is AVS integration
with Azure services. Now, there are ton of Azure services. I'm just going to use one of
the Azure services to give you an example how you can
leverage an Azure service, which is spun up in a Azure VNet. Here, I have AVS environment. I have a couple of
web workloads that I want to expose to Internet
using a Load Balancer. This AVS environment
is connected over to an Azure VNet over ER gateway, and I'm simply using the
Azure App Gateway which is a HTTP/HTTPS Load Balancer, which provides you load
balancing capability. I have a frontend Public IP
here on Azure App Gateway, and the backend pool members, I'm using the VMs which are sitting in my AVS environments 10.1.1.10, dot 20, and dot 30. When the traffic comes
in from Internet and hits this frontend
Public IP address, this traffic is spread
over to all three Web VMs. This is how you can leverage
Azure Native Services, and consume them and integrate them with your workloads which
are running in AVS. Moving on to a quick summary slide. We have talked about how
do you connect to AVS? The connectivity to AVS
is through ExpressRoute. VPN is supported in POC mode only. Your On-premise Networking Stack, it could be VDS, or it could be NSX. The next point is that
the VMware's NSX-T is the default networking stack
in AVS SDDC, or Private Cloud. You have full access to NSX-T, which means you have full access
to spin up any services in NSX-T, which is DNS, DHCP, Firewall, a Load Balancer. You also have built-in security
for your AVS workloads using native NSX-T security features like distributed firewall for
east-west micro-segmentation, gateway firewall for North-South firewalling or
interdepartment firewall, and integration with
the an extend firewall for advanced security features. Finally, we have integration with Azure Native Services for your
workloads in an AVS SDDC. That's all I have for you today. Thank you for watching. I hope the session was
informative. Thank you. [MUSIC]
