多IDC互联网应用部署.docx
《多IDC互联网应用部署.docx》由会员分享,可在线阅读,更多相关《多IDC互联网应用部署.docx(14页珍藏版)》请在冰豆网上搜索。
多IDC互联网应用部署
多IDC下互联网应用部署
背景
随着业务的拓展、用户量的增加、新客户方的定制化接入等需求,要求对当前的系统应用服务进行容灾、扩容、分流,在单IDC情况下将难以满足需求,需要建设多IDC来支撑。
由此产生了在多IDC下,应用服务间协调与调用、资源的规划与部署、数据的共享与同步等一系列问题。
概念
灾备
通过建设两个或多个数据中心,并且区分主备,主数据中心承担用户的核心业务,其他的数据中心主要承担一些非关键业务并同时备份主中心的数据、配置、业务等。
正常情况下,主中心和备中心各司其职,发生灾难时,主数据中心宕机、备份数据中心可以快速恢复数据和应用。
特点:
●资源无法复用:
备份数据中心只在灾难发生时才能起到作用,平时正常情况不接入流量,资源空置
●主备切换风险:
在灾难发生进行主备切换时,备中心在接替主中心时需要较长的时间,同时存在关系依赖复杂、流量瞬时峰值、数据冷启动等问题,导致成功切换存在一定风险
●业务中断:
由于主备切换,会不可避免的影响用户业务处理
多活
将分布在多个数据中心的同一类业务同时运行,或将一个业务分布在不同数据中心层次化的运行,多中心之间地位均等,当某个数据中心的单个或整个应用系统出现问题时,都可以由另一个数据中心的对应系统来接管全部业务,实现持续的服务提供。
多活的部署模式包括网络多活、业务多活、资源多活、数据多活等,之间没有必然的联系,均可以独立建设,也可以组合建设。
特点:
●资源利用率高:
充分利用资源,避免了一个数据中心常年处于闲置状态而造成浪费,通过资源整合,多活数据中心的服务能力是成倍提高的;
●容灾能力强:
如果中断了一个数据中心,其他的数据中心仍可独立响应业务,保证业务无中断
●故障无感:
通过多IDC负载均衡用户流量,当服务异常或服务改造迁移时,对用户来说业务切换是无感的
●距离限制:
要实现业务在多IDC间的同时运行与响应,对数据一致性、延迟率、灾难恢复时间都有要求,直接决定了网络延时不能过长,从而导致IDC间的距离无法突破物理限制
两地三中心
●生产数据中心
●同城灾备中心
●异地灾备中心
特点:
●主备模式:
多个数据中心是主备关系,即存在主次,同城双中心为同步复制,数据实时同步,保证数据的安全性和业务连续性;异地灾备中心为异步复制,无距离限制,保证数据一致性,尽可能降低数据丢失机率
●优先级策略:
业务部署优先级存在差别
●业务中断:
针对灾难的响应与切换周期较长,RTO与RPO目标无法实现业务零中断
两地三中心本质上是一种通过简单资源堆砌提高可用性的模式,资源利用率低下,对高可用的提高、业务连续性的保证仍然只是量变,业务连续性及容灾备份一直没有实质性的跨越。
多用于金融银行行业的解决方案。
分布式多活
通过集成两地三中心模式与多活模式,同时复合使用多种多活部署方式,将两地三中心内的灾备中心改造为多活中心,同时可扩容更多IDC,从而实现广域网上真正意思的分布式多IDC服务组网。
最常见的的形式即为:
异地双活\多活。
特点:
●分布式资源配置:
机房基础设施、地理空间、计算/存储/网络资源的软硬件部署上是分布而非集中的
●独立性与兼容性:
多IDC在建设上可以分期分批逐步建设,彼此间保持一定独立性,同时又为未来扩容升级提供与当前架构的兼容性保证
●全局一体化管理:
资源的调度可以跨越多个数据中心,运维管理可以基于全局,多个IDC间实现有机结合与资源共享,在逻辑上视为一个全局的大数据中心
策略
多活的模式
网络多活
●目的:
解决多IDC广域网链路复用的问题,降低备份链路的成本以及提升网络性能,基本可以适用于所有的业务系统
●场景:
1)流量负载均衡:
用在用户到同一个数据中心的业务系统具有多条可选路径时的环境,如用户通过Internet到多个数据中心访问的业务模型,因存在次优路径,链路的选择可以通过全局负载均衡技术实现。
2)业务分流:
用在用户所访问的不同业务分布在不同的数据中心的环境,通过调整分支到多个数据中心的路由策略即可实现用户到不同业务的网络分流
业务多活
●目的:
解决业务服务器复用的问题,降低业务服务器总体投入以及提升业务性能,使所有的服务器均可以独立响应用户请求。
●场景:
1)共用网关:
相同的业务服务器,采用相同的网关地址,用户发起访问时都要先通过主IDC的统一网关,才能再访问到多活中心的多活服务器,实质是:
网络单活+业务多活。
前提条件:
需要为多活中心的同类服务器配置为同一个网段的不同IP地址,并需要保证多活服务器可以实现跨广域的二层VLAN互通
2)DNS负载:
相同的业务服务器,但分布在不同的网段,服务器可以配置不同的网关地址,通过DNS和全局负载均衡技术保证用户可以自动的访问到最佳性能的站点以及会话的一致性,实质是:
网络多活+业务多活。
前提条件:
需要为多活中心配置DNS服务及GSLB,同时各个IDC内部通过SLB\NAT实现服务的负载均衡
资源多活
●目的:
解决临时的计算单元不足或原机房空间扩展不便的问题,依赖于虚拟化和云计算技术,强调的是整个过程的动态性,资源是动态调配的,无需工程的实施,临时生成的计算资源使用完毕后,可以灵活撤销,不对原网产生任何影响。
实质是:
只是实现了服务器位置的动态变更,并不关注网络和业务系统是否是单活或多活,始终保持原有的业务策略。
●场景:
1)业务应用动态迁移
2)计算节点动态扩缩容
数据多活
●目的:
解决数据库在多节点间的数据同步问题,依赖于多个IDC间根据地域距离选择同步复制或异步复制实现数据同步与备份功能。
由于业务本身的实时性、一致性等限制,多IDC并不能实现“全业务”的数据多活,需根据具体场景选择针对性的技术路线实现。
●场景:
1)双A:
数据库双写(Active-Active),数据库节点均等,数据一致,同时对外提供读写服务
2)Sharding:
数据根据一定的分片、分库策略,在多个数据库节点间进行分布式分片存储,各个节点只保存数据全集的一部分,同时对外提供对该部分数据的读写服务,对不同分片区域的数据请求,根据策略路由到不同数据库节点
3)SAN:
基于SAN\NAS\DRBD\DFS等技术的共享存储
IDC选择标准
管理权
●自建IDC:
管理权自主
●客户方IDC:
依赖客户方开放权限的粒度
●公有云:
依赖于云服务厂商
位置
IDC位置的选择,关乎了IDC间距离,直接决定了多个IDC间的网络延迟率(RTT)
●同城
距离小于60公里,(金融银行类型容灾业务小于35公里)
●异地
数量
根据业务流量与用户分布情况,划分合理数量的多区域,在各个典型大区内布置IDC,作为区域中心
网络情况
●网络物理环境
●WLAN
●光纤直连
●专线
●VPN/MPLS
●是否双线
成本
●ISP
●机房环境
●资源容量
●带宽
●公有云
●服务水平
应用部署标准
分级策略
需对全系统内各业务服务进行合理分级,区分重要程度,分别对待,优先保证核心服务:
●基础服务
与业务无明显绑定关系,不包含业务逻辑或业务逻辑简单固定,且作用职责明确单一的服务
●公共服务
不特定于业务,可在多个业务场景下通用使用的服务
●核心服务
存在业务的核心区分点,是应用中最有价值的部分
●主要服务
一种或多种核心服务的组合,搭配协调完成大业务线整体流程
●周边服务
与某特定业务相关并为其服务,不存在业务逻辑的核心区分点,主要起支撑作用
部署规模
●全量部署
将所有业务应用全量复制在多个IDC部署,不推荐
●单元化部署
将业务进行合理划分,针对不同使用场景流程进行“业务+数据”整体合并打包,并固化为相对稳定的最小单元,进行独立部署,尽量将用户操作封闭在一个单元,每次请求在单元内部独立消化
单元化要点:
1)明确系统边界:
规划系统功能,降低系统间强耦合,严格遵从共同封闭原则,保证系统内部自洽运行
2)合理拆分:
业务的拆分:
✓横向拆分:
按照不同的业务域进行拆分
✓纵向拆分:
一个业务功能里的不同模块或者组件进行拆分
数据的拆分:
✓水平拆分:
同一业务域内进行数据分片
✓垂直拆分:
不同业务域进行分库
3)服务通信:
根据业务场景合理选择同步、异步、并行调用方式
4)粒度划分:
每个部署单元的划分粒度不易过细,遵循的原则:
✓高内聚:
相关行为都放在一个服务单元内,功能具备强业务相关性,同时对强依赖性的服务宜划分在单元内部
✓低耦合:
减少跨单元的服务依赖,降低服务间的依赖复杂度
✓服务可独立部署
✓扩缩容方便
✓SaaS化:
部署单元需将业务逻辑封装为API开放,单元内部尽量降低对底层软硬件环境和基础设施的直接依赖,如需使用时宜通过调用基础或公共服务的方式进行接入
5)无单点瓶颈:
单元间不存在单点问题
6)路由一致性:
保证用户从访问入口-->访问服务-->访问数据库,全链路的路由规则完全一致
●定制化部署
在实现单元化部署的前提下,根据业务场景需求,合理搭配不同单元的服务,进行定制组合部署
核心问题
针对多IDC下,应用服务部署的灾备,尤其多活模式下的分布式部署问题,存在以下一些核心问题,需要针对使用场景,综合使用多种实现方式,有针对性的处理
网络互联
多个IDC间网络互联互通的方式和网络稳定性,是跨IDC部署的技术基础,数据中心间需满足三种网络互联:
1)数据中心间存储网络互联
2)数据中心服务器接入层二层网络互联
场景:
vip迁移、虚拟机迁移、跨IDC集群类部署
3)数据中心间三层网络互联
场景:
普通数据传输,如数据库同步、文件传输、存储同步
网络互联的要素:
●网络访问控制策略的迁移
●服务器网关设计
●IP地址设置
●路由发布控制
●防火墙状态会话
●流量路径规划
●数据同步对网络带宽与服务质量的要求
数据同步
●分区、分片策略
●数据一致性
●延迟率
数据库
●分库策略
●分片策略
●数据同步方式
●分布式事务
●多维度下的数据聚合
中间件
●Cache同步
●MQ同步
●File同步
应用程序
●分布式全局唯一主键策略
●分布式锁策略
●多维度数据查询
应用关联
●服务间关联关系复杂度
原则:
永远只有不同层级服务的单向依赖,避免形成环形循环依赖。
即:
高层服务可以依赖低层服务,同层服务间不互相依赖。
●跨IDC间的服务依赖调用
●跨IDC间的通信方式
负载均衡
DNS
●DNS服务搭建
●业务系统的域名化改造
●域名的设计
GSLB
GSLB是基于DNS的流量管理机制,主要完成DNS解析请求的负载均衡、服务器状态监控、用户访问路径优化。
用户访问应用时,域名解析请求将由GSLB负责处理,它通过一组预先定义好的策略,将最接近用户的节点地址提供给用户,使其可以得到快速的服务。
同时,它还与分布在各DC的所有GSLB节点保持通讯,搜集各节点的健康状态,以保证不将用户的请求分配到任何一个已经不可用的节点上。
原理:
GSLB截获DNS查询,综合考虑路由策略、线路延时、服务可用状态、最后一次响应时间等因素为DNS查询返回域名对应的“最优”IP地址
运维管理
在多IDC模式下,涉及到在跨IDC环境中的运维一体化管理:
●运维协同
●资源管理
●部署编排
●流程控制
●监控告警