There are some resources online which provide latency numbers which seem to hold somewhat accurate still, but I wanted the latest latency numbers to use in my analysis. Each end-user location could determine which Azure data center was closest by using Azurespeed.com. Next I referenced a Microsoft blog to test latency between Azure data centers, so that I could prove the benefit of Azure Express Routes to the nearest/lowest-latency data center, then routing traffic to the FinOps instance would be the best approach. Here is what I did-
1. Created a vNet with two subnets in the region to host FinOps
10.20.1.0/24 vNet
10.20.1.0/26 Resources subnet
10.20.1.192/26 Gateway subnet
2. Created a VPN Gateway in the region to host FinOps - this takes a long time to deploy
3. Created vNets with two subnets in every destination region each region with a different number for variable 'n.'
10.20.n.0/24 vNet10.20.n.0/26 Resources subnet
10.20.n.192/26 Gateway subnet
4. Created VPN Gateways in every destination regions
5. Created VPN connections - connections representing both directions must be created, both origin to destination and destination to origin.
6. Created virtual machines (VM) - Deployed the first one manually then created a template for the other regions to make for a faster deployment which could guarantee consistency.
7. Configured the Network Security Groups on all virtual machines
Limited RDP traffic to my IP and inter-region IPs {MyIP},10.200.0.0/16
Allowed PsPing traffic on port 81
8. Did testing using psping (iperf is an alternative)
On the origin: psping -f -s 10.20.1.4:81
On the destination: psping -l 8k -n 1000 -f 10.20.1.4:81
Example output from PsPing from Korea Central to East US2:
Latency has always been a critical component of any AX or D365FO implementation. Now that it is hosted by Microsoft we have several tools to test network performance before we deploy.
No comments:
Post a Comment