首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

高可用的巅峰技术:跨机房部署、同城、异地多究竟怎么玩儿?

一、容灾介绍 同城异地多都是典型的系统容灾部署方案,对于企业来说,尤其是大型互联网公司,比较重要的系统一般都会做容灾,采用同城,甚至异地多的架构方案进行部署。...对于同城异地多活来说,都是容灾的不同方案,它们对技术、部署成本、运维成本、网络带宽、网络稳定性等的要求都不一样。...四、同城 同城方案是将系统部署在同一个城市的不同机房中,这种方案能够做到机房级别的容灾,而不能做到城市级别的容灾。...可以看到,在实施同城方案时,主库可以部署在A机房中,A机房B机房的数据都写到A机房的主库中,主库会将数据同步到A、B机房的从库。...在异地多场景下,还有一些要注意的问题:读取用户相关的数据时,尽量保证在同一个机房内处理,这时,就需要对用户的数据做分片处理,对同一个用户数据的读写操作,路由到同一个机房内。

23310

关于 Oracle 存储配置实战

跨数据中心的,它的设计目的是为一个数据中心内有着共享存储的多个主机实现负载均衡高可用性。...而且由 Interconnect 的时延基数低(1~2ms),导致机房距离产生的时延对整个 Interconnect 影响的占比更大,所以在搭建 Oracle 的 RAC 存储架构时需要对各个节点的...2Oracle 存储安装配置 安装部署存储,需要至少6快盘,详细磁盘规划需求如下: AA 机房 BB 机房 仲裁 ZC 机房 任何机房均可 aaocr 盘 bbocr 盘 zcocr 盘 tmpocr...Oracle 活存储方案存储厂商的方案(如 EMC 的 Vplex)对比有更大的灵活性,透明性,因为底层的存储磁盘对于 Oracle 来说完全可见,而且通过 Oracle 的 Normal 磁盘组的功能实现...无论是 Oracle 的活存储还是存储厂商的解决方案,均适用于两个存储机房距离小于 50 公里的情况,而且最大的瓶颈在于远端的存储节点写入速度,因此在部署活存储方案时,提前做好底层的磁盘写入速度测试

2K80
您找到你想要的搜索结果了吗?
是的
没有找到

关于 Oracle 存储配置实战

跨数据中心的,它的设计目的是为一个数据中心内有着共享存储的多个主机实现负载均衡高可用性。...而且由 Interconnect 的时延基数低(1~2ms),导致机房距离产生的时延对整个 Interconnect 影响的占比更大,所以在搭建 Oracle 的 RAC 存储架构时需要对各个节点的...2Oracle 存储安装配置 安装部署存储,需要至少6快盘,详细磁盘规划需求如下: AA 机房 BB 机房 仲裁 ZC 机房 任何机房均可 aaocr 盘 bbocr 盘 zcocr 盘 tmpocr...Oracle 活存储方案存储厂商的方案(如 EMC 的 Vplex)对比有更大的灵活性,透明性,因为底层的存储磁盘对于 Oracle 来说完全可见,而且通过 Oracle 的 Normal 磁盘组的功能实现...无论是 Oracle 的活存储还是存储厂商的解决方案,均适用于两个存储机房距离小于 50 公里的情况,而且最大的瓶颈在于远端的存储节点写入速度,因此在部署活存储方案时,提前做好底层的磁盘写入速度测试

1.2K20

Exchange Server 配置DAGNLB,实现

传统的部署方法,至少需要两台服务器,一台是邮箱传输角色,另外一台则是边缘传输角色,在本文中,按照客户的要求,两台服务器都配置为传输角色,并且配置DAG(高可用集群)NLB(网络负载平衡),以实现邮件服务器...Server 2016,IP地址:10.1.5.15; 邮箱角色服务器:Exchange Server 2016,IP地址:10.1.5.16; 2、安装 Exchange Server 2016 的邮箱角色管理工具...3、网络负载均衡(NLB)的配置 (1)在EX01EX02上分别添加网络负载均衡管理器 (2)安装完成后,分别打开EX01EX02的网卡属性上勾选NLB (3)在服务器管理器的工具中打开网络负载均衡管理器...6、在Exchange 管理中心新建Exchange证书 这个前面文章也写过了,需要注意的是,(1)两台服务器都要安装配置证书;(2)访问类型:注意选择OWA、ActiveSync等必要的访问类型(3...)身份验证无(根据邮件网关要求选择) (4)添加域,使用*即可 (5)添加源服务器,两台服务器都要添加 至此,两台 Exchange Server 2016 邮件服务器配置DAG(高可用集群)NLB

1.2K21

同城与异地多架构分析

当用户请求到达进入机房内最先进入到流量网关,流量网关能感知全局的流量分片情况,计算用户所处流量单元并将流量转发到对应的单元,这样就可以将用户请求路由到对应的单元内。...采用GateWayr转发方式可以确定用户单元从而将用户流量路由到正确位置,但是HTTP转发也会造成一定性能损耗。...为了减少HTTP流量转发量,可以在在用户请求返回的时候在cookie上带上该用户的路由标识信息。...当用户下次在请求的时候请求的时候可以提前获取到路由标识直接请求到对应的单元,这种方式可以大幅度减少HTTP流量转发。...下图展示了RPC注册中心路由寻址过程,同城有一定的差异性。

10.6K62

分布式系统技术难题--异地多

异地多常见的解决方案有哪些? 请求如何路由,如何实现会话保持对于请求路由问题,其设计目标在于,让特定用户访问特定的机房,并且可以实现流量分发策略控制,根据IP会话保持。...而在于特定业务中,可以根据制定更加复杂的路由规则,利用前端传递来的标签,做路由策略转发。让特定的一些用户在同一个机房中,例如饿了吗,基于附近地区的业务场景,用户,骑手,商家都是在同一个地区。...并且为了防止网络延迟,我们可以在客户端做很多事情,第一,写:多个机房下允许出现多个Master,那么客户端进行封装在底层将写请求发送给多个Master上。...第二:读或回源读,当读取本机房数据没有读到时,去主机房读取或者根据用户请求解析出数据源在哪个机房然后去读取。 3. 是否可以跨机房服务调用?延迟提高,占据更多的网络带宽怎么办?...对于强一致数据,应建立多机房单集群的部署模式,使用读策略。多机房多集群模式,采用写策略。 7.

1.2K50

浅谈业务级灾备的架构模式

LDC 路由 :::异地多架构下的路由中心,一般分三层。第一层是判断决定访问哪个机房或单元。第二层是在服务间调用的时候,来判断请求应该到哪个单元。...结合蚂蚁的架构,看下路由情况 【入口流量路由】 箭头1:对于应该在本 IDC 处理的请求,就直接映射到对应的 RZ 即可; 箭头2:不在本 IDC 处理的请求,Spanner 可以转发至其他...,如果不是,将请求转发到相应单元。...如图中绿色请求所示,该用户实际规则应该路由到 B 机房,实际请求到 A 机房后,在 DLB 层也会将请求转发到 B 机房。应用服务注册的时候会标记自己的地址、服务类型。...【单元模式】的服务是单元化路由服务,会根据路由 key(用户 ID),将请求进行路由到正确的单元。 【中心模式】的服务,尽管在中心单元的注册中心都会注册,但请求最终只会路由到中心去。

83850

异地多演变流程

11.2 直接哈希分片这种方案就是,最上层的路由层,会根据用户 ID 计算「哈希」取模,然后从路由表中找到对应的机房,之后把请求转发到指定机房内。...例如系统配置、商品库存这类需要强一致的数据,这类服务依旧只能采用写主机房,读从机房的方案,不做的重点,是要优先保证「核心」业务先实现,并不是「全部」业务实现。...路由规则、路由转发、数据同步中间件、数据校验兜底策略,不仅需要开发强大的中间件,同时还要业务配合改造(业务边界划分、依赖拆分)等一些列工作,没有足够的人力物力,这套架构很难实施。...12 异地多理解了异地,那「异地多」顾名思义,就是在异地的基础上,部署多个机房即可。...3、提升高可用的核心是「冗余」,备份、主从副本、同城灾备、同城、两地三中心、异地,异地多都是在做冗余4、同城灾备分为「冷备」「热备」,冷备只备份数据,不提供服务,热备实时同步数据,并做好随时切换的准备

52621

万字长文,搞懂异地多

本文从一个简单的系统例子开始,从单机架构、主从副本、同城灾备、同城,再到异地、异地多,由浅入深、循序渐进地讲解了大型分布式系统异地多容灾架构的技术原理基本的实现思路,非常适合入门者学习。...13.3 直接哈希分片 这种方案就是:最上层的路由层,会根据用户 ID 计算「哈希」取模,然后从路由表中找到对应的机房,之后把请求转发到指定机房内。...的重点,是要优先保证「核心」业务先实现,并不是「全部」业务实现。 至此,我们才算实现了真正的「异地」!...到这里你可以看出,完成这样一套架构,需要投入的成本是巨大的: 路由规则、路由转发、数据同步中间件、数据校验兜底策略,不仅需要开发强大的中间件,同时还要业务配合改造(业务边界划分、依赖拆分)等一些列工作,...14、异地多架构 理解了异地,那「异地多」顾名思义,就是在异地的基础上,部署多个机房即可。

87830

搞懂异地多,看这篇就够了

配置转发规则 DNS 指向 B 机房,接入流量,业务恢复 看到了么?...2、直接哈希分片 这种方案就是,最上层的路由层,会根据用户 ID 计算「哈希」取模,然后从路由表中找到对应的机房,之后把请求转发到指定机房内。...例如系统配置、商品库存这类需要强一致的数据,这类服务依旧只能采用写主机房,读从机房的方案,不做的重点,是要优先保证「核心」业务先实现,并不是「全部」业务实现。...路由规则、路由转发、数据同步中间件、数据校验兜底策略,不仅需要开发强大的中间件,同时还要业务配合改造(业务边界划分、依赖拆分)等一些列工作,没有足够的人力物力,这套架构很难实施。...3、提升高可用的核心是「冗余」,备份、主从副本、同城灾备、同城、两地三中心、异地,异地多都是在做冗余 4、同城灾备分为「冷备」「热备」,冷备只备份数据,不提供服务,热备实时同步数据,并做好随时切换的准备

2.2K30

追前沿,领略SET化架构衍化与设计

" 架构介绍 目前很多大型互联网公司的业务架构可以理解为同城""架构,注意这里的“"是加引号的,具体可以这样理解: 业务层面上已经做到的真正的(或者多),分别承担部分流量; 存储层面比如定时任务...、缓存、持久层、数据分析等都是主从架构,会有跨机房写的问题; 一个数据中心故障,可以手动切换流量,部分组件可以自动切换; 两地三中心架构介绍 使用灾备的思想,在同城“”的基础上,在异地部署一套灾备数据中心...,方面各业务线接入使用 SET化架构设计: SET化架构策略 流量路由: 按照特殊的key(通常为userid)进行路由,判断某次请求路由到中心集群还是单元化集群; 中心集群: 为进行单元化改造的服务...,各单元化集群数据需要进行双向同步来实现容灾需要 异地容灾: 通过SET化架构的流量调度能力,将SET分别部署在不同地区的数据中心,实现跨地区容灾支持 高效的本地化服务: 利用前端位置信息采集域名解析策略...RabbitMQ-SET化架构实现 SET化消息中间件架构实现(RabbitMQ): 使用RabbitMQ异步消息通信插件 Federation(节点节点、集群集群之间通信) 安装与配置

73420

超级加倍:互联网大厂的容灾架构设计与落地方案(跨机房部署、同城、异地多

一、容灾介绍 同城异地多都是典型的系统容灾部署方案,对于企业来说,尤其是大型互联网公司,比较重要的系统一般都会做容灾,采用同城,甚至异地多的架构方案进行部署。...对于同城异地多活来说,都是容灾的不同方案,它们对技术、部署成本、运维成本、网络带宽、网络稳定性等的要求都不一样。...四、同城 同城方案是将系统部署在同一个城市的不同机房中,这种方案能够做到机房级别的容灾,而不能做到城市级别的容灾。...可以看到,在实施同城方案时,主库可以部署在A机房中,A机房B机房的数据都写到A机房的主库中,主库会将数据同步到A、B机房的从库。...在异地多场景下,还有一些要注意的问题:读取用户相关的数据时,尽量保证在同一个机房内处理,这时,就需要对用户的数据做分片处理,对同一个用户数据的读写操作,路由到同一个机房内。

13610

FA7# 异地多实践与设计思考点归纳

引言 在异地多项目整体推过程中的一些注意事项设计点归纳整理,抛砖引玉,其中一些点还有待深入探讨优化。 一、指导事项归纳 1.多原因归纳 推动多的原因大体可归纳为以下三种。...高可用架构部署 业务整体的容灾 单机房容量限制 2.多指导归纳 多牵扯公司业务方方面面,整体来讲业务改造基础设施中间件改造两大块。...流量切换过程中容忍分钟级不可用,切换结束后恢复 二、多规则与流量选择 1.路由因子选择与映射 路由因子选择: 需要根据公司业务场景选择,常见的路由因子有地域、用户ID。...路由因子与机房映射: 地域因子:将地域编号与机房建立映射,例如:001->unit-a 用户因子:将UID与机房建立映射,例如:123456与机房编号哈希后映射到unit-a 2.请求分配正确机房 一个请求有了多规则后如何将请求路由到正确机房...,归纳了以下几种方式: 终端服务通过多域名切换:将请求直接路由到正确机房 在反向代理层转发转发属于异地机房流量 在网关层转发转发属于异地机房流量 3.多管控中心服务 多部署通过双向同步或者写方式保证数据的一致性

73720

超3亿活跃用户的多架构,数据同步与流量调度怎么做?

OPPO公司的机房比较多,主要的就有好几个机房,我们的上层业务是分布在不同的机房里面去,这对平台业务来说就比较麻烦,上层业务可能只需要做就行了,而平台业务可能就要做七、甚至八,而且七、八个机房都要有读写...这里确实实现了多,每个机房都有流量,每个机房也是读写,是完全的多,但是单元高可用的问题如何解决,单元的归属机房故障了,如果把这个单元转移另一个机房继续提供服务。 4、异地业务架构 ?...前面说了单元内部主要两种模式,第一种是异地,双向同步,主主模式,读写在本机房,然后做双向同步;第二种是同城多,主备的模式,跨机房共享主备切换的数据层。...8、服务路由 ? 用户会先请求到API网关,API网关根据请求的单元号参数,判断是是否访问错了机房,如果访问错了,就做重定向,或者跨机房转发,用户自己选择的其中一种模式。...定向用户请求有两种模式,一种是转发模式,API网关直接转发到新机房的业务后端实例。

1.9K21

腾讯专有云高可用设计内幕揭秘

基于 AZ 准方案,腾讯专有云TCE 为实现 AZ 切换的 RTO≈0,增加了一个位于第三处机房(如办公区增加一个机柜)的仲裁区,在仲裁区中部署 ZK 热备节点 Etcd 热备节点,代替手工拉起...当 MAZ 与互联网之间的线路发生故障,MAZ 发布的路由失效,来自用户的访问请求会被运营商的路由器匹配到 SAZ 对外发布的路由,从而将流量牵引到 SAZ 的 CLB 节点。...当 MAZ 整体故障时,首先会触发 MAZ 侧 CLB 对外发布的路由失效,用户访问请求会被动态路由牵引到 SAZ 侧的 CLB 上。...由于 CLB 是跨 AZ 高可用的,SAZ 的 CLB 可以接管来自用户的会话并转发请求,实现 RTO≈0。 CLB 把来自用户请求转发到 RS(Real Server)的依据是 RS 的健康度。...由于 MAZ 整体故障,位于 MAZ 的所有 CVM 的健康度为0,CLB 集群不会将任何请求转发到 MAZ,而是让 SAZ 的 CVM 承担请求

6.4K42

B站多容灾高可用建设思路

用户基于DNSHTTP DNS访问DCDN节点,然后DCDN回源时,由边缘POP点做流量汇聚,路由机房。 因为B站做了多,所以有多个可用区。...用DCND做多的Router层的事情,将用户请求路由分发,可以基于用户的Mid或用户设备ID来做路由,分发到不同的可用区。 不同可用区服务,会通过proxy模式访问缓存、KV、DB。...GZS组件,用来进行多全局管控。 在713之后,对多组件做了优化。 DCND层面:支持通过用户ID或设备ID来hash路由到不同机房,同时支持用户流量在多机房的动态权重。...Service层面:最开始B站做同城时,没有实现写功能,那是还没有proxy,现在有了proxy,可以让业务方改造写了,通过存储的proxy来路由到主可用区。...延迟巡检,因为使用了GZone,所以DBKV同步延迟较低,同城一般1ms延迟,没有什么问题。

1.2K30

历时三年,苏宁如何建设多数据中心多的实践项目?

1 方案选择 参考业界多数据中心实践,目前主流的多数据中心的解决方案有如下几个: 主备模式 同城模式 介绍这几个方案前,我们先来看下相关概念: Cell:业务可封闭收敛最小执行分片;业务对请求空间按一定维度...2、同城 同一个集群横跨同城两个不同的 AZ,两个 AZ 同时对外提供服务,同时允许跨机房访问不同服务以及数据库。...CDN:根据用户请求信息按照一定的规则路由到对应的数据中心。 SLB:根据用户请求信息路由到同机房或其它机房。 RPC/MQ:根据用户请求信息按照一定的路由规则分发到不同的数据中心。...流量在进入数据中心前,按照一定的路由规则,确定好待分发的目标中心,以减少数据中心之间的二次转发。比如,苏宁在 CDN 层进行用户的初次路由,将用户分发到不同的数据中心。...6 总结 多数据中心多项目作为苏宁重大项目,经过 3 年左右的建设,已于 2019 年上线,历经 818 11 等大促考验,实现关键链路从单机房平滑过渡到多机房的突破,支撑了业务的快速发展;并在机房出现真实故障时

1.6K31

从 单体架构 到 异地多

---- 文章目录 系统可用性 单机架构 主从复制 不可抗力 同城灾备 同城 两地三中心 异地 异地多 系统可用性 让我们从最基础的开始往上垒。...---- 异地 按照上面的思路,只要把 “同城” 那一趴的图里的 “A机房”、“B机房”放到两个不同的城市好了。但是现实是如此的吗? 因为是异地,两个机房之间的专线也将升级为 跨域专线 了。...或者也可以通过别的方式,如哈希分片等,反正只要确保让同一个用户的相关请求,只在一个机房内完成所有业务「闭环」,不再出现「跨机房」访问。,从源头避免数据冲突!...例如系统配置、商品库存这类需要强一致的数据,这类服务依旧只能采用写主机房,读从机房的方案,不做。 == 的重点,是要优先保证「核心」业务先实现,并不是「全部」业务实现。...== ---- 异地多 理解了异地,那「异地多」顾名思义,就是在异地的基础上,部署多个机房即可。

1K30

B站服务稳定性建设:高可用架构与多治理

下图为B站同城多的架构图,由一个流量层即DCDN层面,对用户维度的一些信息来进行Hash路由,然后进行请求分发。...所以在同城多的场景下,要求服务能够在本地完整地支持写请求的处理,以及强弱依赖必须在本地进行部署,而弱依赖则会被允许应用跨专线回主机房。...GZone:对于同城场景下数据需要全局存放的情况,即一主多从这样的模式,服务在主可用区基本上能读写GZone的存储,本可用区有可读的从实例,在可用区也有从实例,通过Proxy将写的路由回源到主机房。...虽然我们的服务开始在另一个可用区做整个部署,但在流量层面,我们只能支持读接口的接流,而且接口大部分都通过 CDN侧或者SLB侧进行流量的转发,还有一些缓存或消息队列的一些组件未完成多改造,存在跨机房调用的情况...Q&A Q1:同城架构下应用层做了,基础架构层还有必要吗? A1:我觉得有必要。

48220

详解:淘宝高可用异地多架构

同城 前面讲到的几种方案,基本都是在一个局域网内进行的。业务发展到后面,有了同城多的方案。 前面比起来,不信任的粒度从机器转为了机房。...这种方案可以解决某个 IDC 机房整体挂掉的情况(停电,断网等)。 同城其实前文提到的双机热备没有本质的区别,只是“距离”更远了,基本上还是一样(同城专线网速还是很快的)。...远端的备份机房能更大的提供灾备能力,能更好的抵抗地震,恐袭等情况。的机器必须部署到同城,距离更远的城市作为灾备机房。...当城市 1 发生大面积故障时,比如发生地震导致 IDC1 2 同时停止工作,则数据在 IDC3 得以保全。 同时,如果负载均衡仍然有效,也可以将流量全部转发到 IDC3 中。...对上面的两地三中心进行改造,在异地也部署前端入口节点应用,在城市 1 停止服务后将流量切到城市 2,可以在降低用户体验的情况下,进行降级。但用户的体验下降程度非常大。

2.3K11
领券