微信号:jishutoutiao

介绍:国内领先的互联网技术类原创订阅号,聚焦当下技术热点、行业资讯、技术实战及管理经验,专注于技术类原创内容的发布和业内交流,打造专业的互联网技术交流和分享平台.

域名和接入

2016-10-14 10:01 技术头条
编者按: 《运维之下》一书覆盖了系统、网络、数据库、安全、标准化、自动化等多个层面,从创业初期见招拆招到BAT级别的规模化运维,从PaaS、IaaS到公有云,从运维理念到平台实践,都有所阐述。作者从个人成长经历出发,分享了自己与团队在运维工作发展过程中遇到的问题,如何去思考问题,怎样去解决问题。与其说这是一本传授管理经验和工作秘诀的书,不如说它更是一本关于运维体系化的指导手册。在各种说教式理论类丛书漫天飞的同时,笔者能够耐得住性子,将自己的多年的从业经验,合力共聚为一本书,这本书的含金量自然可想而知。本篇为《运维之下》第十二章。

第十二章:域名和接入

域名是所有互联网公司服务的入口,也是重要的公司品牌。域名的使用和设计是否合理,不仅影响用户能否快速访问到业务,而且也直接影响内部服务的部署架构、管理复杂度、自动化运维实现等方面。众所周知,域名的解析结果是一个或多个IP地址,利用域名解析的结果,就可以实现:
◎ 基本的负载均衡;
◎ 引导流量接入到期望的目的地址。

若只使用域名解析来接入服务,则存在以下问题:
◎ 受Cache等因素影响,利用域名解析多IP地址进行负载均衡效果有折扣;
◎ 域名指向的IP地址必须要直接接入互联网(公网)。

Cache还不足以造成严重的影响,但要求所有业务前端必须接入公网,在小规模情况下问题还不突显,但当业务发展到一定规模时,所引起的副作用就足以让运维人员疲于应付。主要问题有:
◎ 服务器接入公网对网络规划的要求;
◎ 服务器接入公网后的安全性考虑;
◎ 服务器接入公网后的防攻击考虑。

因而,基于VS/NAT的四层负载均衡器和基于URL分流之类的七层负载均衡器应运而生,其核心思想就是只利用少量的、直接暴露在公网的负载均衡层接入用户请求,再通过算法和策略,平均地转发到内网的业务前端进行处理。同样地,也将内网前端的处理结果,原路返回发送给对应用户。负载均衡层在用户和业务之间起到代理和转发的作用。通过图12-1可以看出有/无负载均衡层在结构上的区别。

图12-1  有/无负载均衡层在结构上的区别

负载均衡技术的引入有效地控制了对外暴露服务器的规模,使得安全策略和防攻击都能够被集中和统一地解决。并且与前端服务器规模不成正比关系,无论业务规模如何发展,对外暴露服务器的规模都是有限的。同时,负载均衡技术使前端服务的扩展更加平滑、透明和可控(不受用户DNS Cache影响)。

下面分别介绍我们在域名和负载均衡实践应用中的运维设计和自动化管理方面的经验与考量。


负载均衡及自动化

负载均衡器在大规模业务集中发展为必不可少的设施,在业务乃至整个基础环境中都起着至关重要的作用。包括:
1.简化网络结构和网络维护成本
以最原始的互联网服务为例,对互联网用户提供服务就必须将服务器接入到公网中,如图12-2所示。在小规模业务中,为满足这样的需求进行网络规划和实施并非难事,也不存在太大的成本,甚至内网和外网都可以共享同一套物理设备,所以也是比较常见的形态。

图12-2  增加负载均衡器前的网络结构

但随着业务的发展、规模的扩大,会逐渐地发现:
◎ 除了前端服务器(业务的入口),大部分服务器并没有访问外网或被外网访问的需求,因此配置外网实际上是一种浪费,甚至还额外引入了安全风险;
◎ 如果内、外网共享物理设备,则有相互干扰的风险。例如,外网被攻击导致设备工作异常,内网也会同时受到影响。但如果拆分内、外网,则又会出现两套网络,浪费物理资源。
增加负载均衡器后,网络结构变得更清晰和简洁,如图12-3所示。

图12-3  增加负载均衡器后的网络结构

在增加了负载均衡器的结构中内、外网是分离的,外网流量通过负载均衡器转发进入内网,即使外网发生故障异常也不会不影响内部服务的运转。负载均衡器的规模与流量和转发性能成正比,与内网服务的规模无关。而通常业务功能的扩展和集群规模的扩大都主要发生在内网。

2.减轻在业务升级维护过程中对用户的直接影响
从图12-2中可以看到,用户请求直接与服务器交互,服务器正常的维护、升级、故障等因素都会导致短暂的服务中断,虽然用户端可以设置重试策略,在请求失败后重试到其余服务器,但是对于新用户请求来说仍然会有一部分会访问到异常服务器上,即服务中断期间,有n/m的请求会出现失败和重试(n为服务中断服务器数量,m为提供该服务的服务器总量)。

而从图12-3中可以看到,用户请求与负载均衡器进行交互,再由它进行转发,因此如何进行转发是可控和可配置的。当内网中某服务器异常或维护时,在负载均衡层屏蔽该服务器即可使用外网流量,不再转发到该服务器,从而消除了用户请求存在n/m失败重试的可能性。

3.更集中的安全策略控制和防攻击
增加负载均衡器后,与互联网(公网)互联的服务器由分散的多个入口收敛为集中的一个入口,从而使安全防护策略也跟随集中和统一,更方便地进行维护和变更,消除和避免安全防护策略的缺失、遗漏而造成的隐患和损失。在防攻击方面,图13-2所示的结构是以寡敌众,容易被逐个击破;而图13-3所示的结构通过负载均衡器将内网的服务集群虚拟为外部可见的一台服务器,是以众敌众,强者胜之。

4.支撑业务前端更灵活和实时的容量扩展
如前面所述,负载均衡器将内网的服务集群进行了虚拟,在外部用户看来就是一台服务器,内、外网之间的流量由其决定如何转发,因此内网服务器的扩展和调整是可控制的,变更的生效是更为实时的,集群的规模几乎是不受限制的(例如,使用域名->IP地址会受到DNS相同域名的最大条目数限制集群规模),并且变更的过程对于用户透明、无感知。

负载均衡的解决方案有多种,如基于四层或七层,基于硬件或软件;在大规模业务场景中历练过的不乏有F5、LVS、Nginx、HAProxy等。作为一个重要的基础设施,负载均衡方案的性能、可扩展性、均衡策略、对业务是否透明等指标直接关系到业务的稳定性、处理能力和接入维护成本。

下面介绍的是以经典代表LVS+Keepalived为基础的负载均衡器接入设计和自动化管理方案。

选择LVS+Keepalived的考虑
当前LVS在业内已得到广泛的应用和认可,属于四层负载均衡实现,最初具有NAT、DR、TUNNEL三种工作模式,在随后业内的工程实践中又增加了FULLNAT工作模式,并由taobao开源,使之更适用于大规模业务场景。四层负载均衡如同底层交换设备一样具有天生的业务透明性,接驳到业务流中时对应用层无感知,无须进行额外的设置和调整。

而FULLNAT则是专为大规模工程应用而设计的,消除了原有DR/NAT模式在应用中的诸多限制,比如要求前端服务器在同一广播域或同一网段等。FULLNAT模式使网络结构的设计更为清晰,同时跨网段的转发使服务集群的扩展更加灵活、便捷。LVS可以运行在普通服务器上,有不俗的性能表现,并且安装和配置不复杂,名副其实的低成本和高收益。针对LVS的部署过程已有丰富的文档和手册详细介绍,在此不再赘述。

Keepalived则是基于底层负载均衡框架(如LVS)进一步扩展和增强了负载均衡的高可用性,使之具备构建集群的能力,提供了更适合于维护的配置格式、健康检查能力等。概括来说,LVS实现了内部的业务集群抽象和虚拟,而Keepalived则完成了LVS集群的构建,以及LVS映射关系管理。

负载均衡器接入结构
负载均衡器接入结构如图12-4所示。

图12-4  负载均衡器接入结构

在实际应用中基于LVS+Keepalived的负载均衡器采用了如图13-4所描述的结构,LVS的外网侧与交换设备通过OSPF进行接驳,LVS的内网侧与内网交换设备直连。这种结构的特点和优势如下。

1.容量可扩展的LVS集群
在前面已经提到,Keepalived使LVS具备了构建集群的能力,但是Keepalived使用VRRP进行容错备份,而VRRP协议造成了两方面的局限:
◎ 在一个集群中,同一时刻只有Master能够工作,若干Slave只能作为冷备。
◎ VRRP只能工作在二层网络,因此所有LVS节点必须部署在同一广播域。

通过VRRP协议构建的LVS集群,起到了冗余和备份的作用,但在集群处理性能和容量上仍然是单机性能为上限,并不能通过扩展节点来扩充容量。另外,同属于一个广播域的要求也必须要在网络架构上进行设计和支持,在某种程度上也会增加网络维护的成本和复杂度,其中不能水平扩展在大规模服务的应用场景中是明显的软肋。

所以,必须要使LVS节点具备热备的能力以及水平扩展的能力。通过在LVS与交换设备间建立OSPF邻居关系便是可行的方案之一,OSPF邻居关系建立后,交换设备可以动态发现和感知LVS节点变化,并从LVS节点学习路由。若有多个LVS节点同时宣告了相同路由,交换设备则会通过ECMP(Equal Cost Multipath Routing,等价路由)机制进行分流,而这恰好就是我们所需要的热备机制。在热备的基础上,增加或减少LVS节点数便能够重新分流,达到容量伸缩的目的。

2.独立的LVS节点
不再依赖VRRP作为构建集群的基础后,LVS节点之间便消除了相互通信和选举的需求,不会再发生类似VRRP模式下出现多个Master或无Master的情况。各个LVS节点更具独立性,单节点故障或进行维护不影响其他节点的正常运行。
在OSPF+LVS构建的集群化负载均衡结构中,虽然解决了大规模应用中的诸多问题,但也并非十全十美。

首先,单节点故障会造成交换设备路由的变化,造成ECMP机制重新计算。在交换设备中ECMP通常只是简单hash计算,没有一致性hash的特性,因此数据流将会完全打乱(简单hash计算保证了转发的性能和均衡性,而一致性hash除了增加复杂度外,也不能保证绝对均衡,所以当前交换机基本上都不支持一致性hash的特性)。若没有对LVS节点的Session进行同步,打乱后的数据流无法再进行转发,从而造成连接中断。例如,ECMP重新计算前业务流是经过LVS NODE1分流和转发的;而ECMP重新计算后,业务流则可能会被分配到LVS NODE2。由于LVS NODE2上并没有之前会话的任何信息,因而无法正常继续之前的转发和交互。

其次,FULLNAT模块in/out流量都会经由LVS节点穿行,对LVS节点转发性能造成额外的开销。
最后,也是由于各节点的独立性,在配置有差异的情况下,各节点仍然能够正常运行,使得配置上错误或不同等小隐患不容易被及时发现。
LVS的集群化增强了业务架构体系的稳定性和高可用性,但规模化的集群管理是衍生而来的运维烦恼。如何保证集群的同步一致和可靠运行,便是随之而来的课题。

自动化管理系统
Keepalived在LVS的基础上,提供了更为友好的配置形式,便于人工维护。但在大规模应用中,由于配置的条目多,造成人工维护的变更成本高、误操作概率高等衍生问题,从而使得规模越大配置越难维护。而同时,LVS又是内、外网流量接驳的咽喉,一旦出现误操作,就会损失全部用户流量。因此,LVS配置的有效性、变更的准确性至关重要。抛弃人工管理实现自动化,既是顺势而为,又是必然的趋势。

系统结构如图12-5所示。

图12-5  系统结构

首先,系统的核心是Etcd,一款用于配置管理和服务发现的开源的分布式KV存储。Etcd数据是以树状结构存储的,而Keepalived配置同样也是树状的层次关系,DC->CLUSTER->VS->RS->RS HealthCheck,因此Keepalived经过层次化转换后,可以很容易地保存到Etcd中,并由Etcd自身存储结构来始终保证这样的层次性。同样在读取方面,指定一个节点(如CLUSTER),拉取以该节点为root的子树,经过简单的合并,就可以轻松地将整个节点配置转换为Keepalived的格式。这也是我们选取Etcd作为Keepalived配置存储的考量。

其次,利用Etcd已有的HTTP API接口,封装和完善数据的权限及有效性检查,从而通过UI或工具就能自动化地进行Etcd数据操作,保证配置变更的准确性和可靠性,减少人为误操作。

再次,Etcd作为整个系统的核心,同样也需要保证高可用性和高可靠性,而其自身的分布式设计便能满足高可用性需求。

最后,在Keepalived端,设计采用拉取的策略从Etcd查询得到集群配置并转换为Keepalived配置文件生效。pull策略无疑牺牲了配置生效的实时性,但在稳定性和实时性之间,整个负载均衡器的稳定性是具有更高优先级的。
 
为什么pull策略会更稳定?主要体现在如下几个方面。
(1)pull动作的触发并非是用户行为,因而是可控的、周期性的,即使有大量的集中的配置变更,也不会造成KPD的频繁加载。

(2)pull形式更便捷地保证了LVS集群配置的一致性,例如某节点在故障或维护后,重新加入集群时,配置可能就已经发生过变化或更新。pull方式在加入集群时强制拉取一次,便可以完成线上配置的同步。而若换作push方式,事情就会变得复杂,在节点故障期间,要记录状态不能往故障机器发布,节点恢复后,再重置状态触发配置的推送和发布。如果状态处理得不正确,就会导致集群配置的不一致,造成隐患。

(3)避免功能模块间的耦合,从图12-6中可以看出,UI、Etcd和LVS是相对独立的业务模块,Etcd通过标准接口接受更新、查询请求,各个模块的升级不影响和依赖其他。

在实现LVS的自动化管理之后,才能进一步整合其他系统,实现体系的自动化。比如通过与部署系统的接驳,实现应用部署完成后自动流量引入;通过与域名管理系统的接驳,实现域名申请后自动进行LVS虚拟IP地址申请等。


总结

在互联网行业,高可用性和高性能业务架构是永远不能懈怠的话题,通过负载均衡技术进行流量的接入,不仅提高了业务的可靠性和冗余性,还使资源利用率和请求响应时间得到提升。如何利用好负载均衡这件利器,是持续的实践和探索。




连载干货看不够?
GITC2016全球互联网技术大会
带你看更多有料干货!
11月24日-11月25日
即将于北京国家会议中心举办
本届主题定为技术源动力,届时将与您一同探讨当下互联网技术热点,汇聚互联网行业技术大咖们进行主题演讲。同时将引入全球领先的AI,VR技术,让与会观众全方位领略、感受世界领先技术。更有更有炫酷好玩的黑科技游乐场和首届音乐盛典等待你的加入。这场技术的饕餮盛宴小伙伴千万不要错过哦!

更多精彩内容技术头条将持续跟进,第一时间为大家送上最新动态~
o(^▽^)o

 
请扫描以下二维码关注技术头条公众号
更多精彩内容将在技术头条持续发布,敬请关注!
微信号:jishutoutiao

点击“阅读原文”,快来购票吧!
 
 
技术头条 更多文章 从外包到自建,小中企业CDN运维进阶指南 公共JS组件安全部署实战 当当史海峰谈架构师的自我成长之路 《运维之下》十章干货大合集,拿走不谢 传输网建设
猜您喜欢 【今日直播】 线上讲座:程序猿的别样进化路程 【视频】►博彩网站骗局:后台被掌控 大笔资金全是虚构 代码能不能不要写得这么烂?! 架构师需要编写代码吗? Retrofit分析与实现