MS Ignite 2017 网络服务新功能之高可用-TrafficManager篇

 

上一篇给大家介绍了AZURE的下一代负载均衡,今天跟大家聊一聊Traffic Manager(智能DNS)。现在很多AZURE的用户还在使用单站点服务(资源全部在Azure的一个Region),对于理想国度的完美应用架构,从灾备以及应用性能的角度出发,多站点部署必不可少的。如何做到异地的灾备,如何做到用户的近源覆盖达成最优响应延迟?Traffic Manager(智能DNS)其实是必不可少的一环,今天我们就来看一看Traffic Manager的更新。

========阅前必读========

通常我们无论通过桌面端还是移动端访问一个互联网服务时候,访问流程是什么样子的呢?

1. 获取服务站点域名,如想访问微软AZURE服务,我们先要获得访问站点域名www.azure.cn

2. 客户端对站点域名进行解析,客户端发起DNS请求,请求域名结果(域名结果可能是A记录,CNMAE记录,NS记录等),如步骤1的例子,客户端发起DNS请求解析www.azure.cn的IP地址,如下面的dig操作中,我们看到,先获得了一个CNAME记录,然后通过CNMAE记录进一步解析最终获得了A记录(IP地址:61.200.88.84)

:~$ dig www.azure.cn

; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.azure.cn
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10792
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;www.azure.cn. IN A

;; ANSWER SECTION:
www.azure.cn. 29 IN CNAME www.azure.cn.mschcdn.com.
www.azure.cn.mschcdn.com. 522 IN CNAME um4thtubffnsqr.wscloudcdn.com.
um4thtubffnsqr.wscloudcdn.com. 1 IN CNAME 1stcncloud.dtwscachev290.ourwebcdn.com.
1stcncloud.dtwscachev290.ourwebcdn.com. 59 IN A 61.200.88.84

;; Query time: 314 msec
;; SERVER: 10.222.220.5#53(10.222.220.5)
;; WHEN: Mon Nov 06 15:57:38 DST 2017
;; MSG SIZE rcvd: 184

3. 客户端向步骤2获得站点IP地址(61.200.88.84)发起连接,从而获得服务。

通过上述基本的一个业务访问流程,童鞋们应该会发现,域名是个神奇的东西,相对固定IP地址它有更好的灵活性。如果一个业务绑定在静态IP地址上,交付给用户的访问地址直接给成IP地址的话,当该地址不可访问时,整个业务将无法访问。通过域名发布业务,我们可以做到灵活的流量调度,从高可用角度可以在某个业务IP不可用的时候将业务地址切换到其他IP地址,从性能角度可以通过智能调度将用户请求引导到近源的站点。

=========Traffic Manager(智能DNS)智能调度算法介绍============

1. 基于优先级的调度算法:当应用采用多站点部署时,可采用对不同站点进行优先级配置,实现按优先级访问,当高优先级站点不可访问时,访问切换到低优先级站点。简单理解为主备模式

2. 基于权重的调度算法:当应用采用多站点部署时,可采用对不同站点进行权重配置,实现按权重分配调度访问,比如有两个站点,权重按照1:3配置,则有25%的请求调度值站点1,75%的请求调度至站点2。简单理解为权重主主模式,通过该部署方法可实现如站点升级流量牵引等。

3. 基于性能的调度算法:当应用采用多站点部署时,可采用对不同站点进行基于性能访问调度,智能DNS可以基于各个地区DNS代理的延迟指标来对访问请求进行智能分配,延迟指标是一个动态变化的结果,所以该策略也会随时间变化而变化。目前DNS已经有相应扩展来支持将客户端真实IP返回给后端,虽然Azure Traffic Manager已经支持,但是目前并不是所有DNS代理有相应能力(RFC7871)。

4. 基于地域的调度算法:当应用采用多站点部署时,可以根据访问请求来源所在地进行智能调度,将访问请求分配到近源的站点,比如一个全球性站点,将用户引导到离用户最近的Azure Region内站点。

=========Traffic Manager(智能DNS)智能调度算法缺点============

基于优先级和权重的调度算法,相对来说是静态的调度算法,虽然可以满足高可用的要求,但是无法对性能进行优化。性能和地域调度算法都是动态的调度算法,可以保证高可用的同时进行性能的优化。But它们也有不足之处,性能算法基于的性能指标来源是DNS代理服务器并非客户端本身,所以准确性上是有偏差的。地域算法上是基于GeoIP客户IP所在地归属数据库来判别客户请求来源,但判断时基于的时DNS代理服务器的IP并非客户端IP,所以准确性上也有偏差。

=========Traffic Manager(智能DNS)功能优化============

对于性能调度我们上面介绍到,由于性能指标来源并非客户端本身,而是通过DNS代理服务器地址所在区域的性能指标来宏观表示对应区域客户IP的性能。如果我们能拿到客户IP真实的性能指标,那么准确性将有大幅度的提升。Traffic Manager目前增加支持 Real user measurements 功能,可以实现对于真实客户IP性能参数的采集。其通过在页面内或移动端代码中嵌入Javascript,实现客户端侧性能指标的采集,客户端在访问的同时执行Javasript将客户端侧的性能指标反馈被AZURE Traffic Manager。

=========Traffic Manager Real user measurements 演示 ==========

Step 1: 快速创建WebApp服务搭建Java Web Server

参见:https://docs.azure.cn/zh-cn/app-service/app-service-web-get-started-java

Step 2:创建Traffic Manager服务

Routing Method选择Performance,目前Real User Measurements只适用与Perfomance路由模式

Step 3: 添加Endpoint端点

类型选择Azure Endpoint(此示例中采用Azure WebApp服务快速搭建Java Web Server),Target resource type选择Step 1中创建的azure webapp

Step 4:开启Real User Measure

Step 5:将Step 4中获取的Real User Measure Java Script插入到Web页面代码Body部分中,并发布更新Web服务

Step 6:获取服务FQDN尝试访问,并查看页面源码

Step 7:查看Azure访问分布情况

Traffic Manager的另外一个更新是支持访问源分布热图,可以你帮助了解Traffic Manager流量调度情况,以及客户端分布。不足指出目前热图分布是基于DNS代理的IP分布,并非真实用户IP分布(如想了解这部分分布,可以考虑结合WebApp的Access Log通过tailmap等开源软件进行统计,后面有机会我会以tailmap为示例给大家介绍)

==================总结===================

通过上述DEMO可见,Traffic Manager新的功能更多侧重在Telemetry上面,通过精细化的数据来支撑更加有效的调度算法,从而保证客户最优的使用体验,相信后面Traffic Manager还会有更多相关的功能更新,让我们拭目以待。

==================参考资料=================

Real User Measure介绍:https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-rum-overview

Traffic View介绍:https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-traffic-view-overview

 

posted @ 2017-11-06 22:12 wekang 阅读(...) 评论(...) 编辑 收藏