保险应用级灾备如何架构设计性价比更优及选型参考建议

本次交流邀请了来自某大型保险集团、某省农信及IBM的资深灾备专家，围绕保险行业核心系统如何建设应用级灾备进行架构设计在线讨论，并且会实践分享自己保险企业应用级灾备建设的实践，帮助大家能更好的应对灾备的建设。
参考活动：保险行业核心系统应用级灾备架构设计在线交流

本期活动交流嘉宾：

ID： jampg
某大型保险集团
主要负责系统架构设计与运维、分布式存储、灾备建设、数据库管理等工作。

邓毓
某农信社资深骨干工程师
主要负责Power，x86及相关存储、数据库、中间件、应用负载、监控、备份和各类虚拟化平台等的运维及管理工作，一线实施经验丰富，对双活数据中心及云平台建设和监控有着深入的见解。

唐国兵
IBM资深架构师
超过9年的IBM从业经历，某全球大型航空公司后台核心系统运维经验，5年某大型跨国企业全球财务系统项目管理经验，PMP项目管理认证 。目前作为IBM LinuxONE销售的技术支持，负责过社保，公安，金融，公积金，医疗，教育和交通等行业IT基础架构的方案设计。

交流集锦

1、基于ORACLE RAC 双活方案实施，如何规避脑裂这个风险？

基于ORACLE RAC 双活方案实施，难点在于远距离光纤条件下的节点之间的数据交互，尤其因为仲裁的原因，导致出现的脑裂现象较多，我们应该如何规避这个风险？

回复1：03500408163.co 数据库管理员 , gansubank
脑裂分两个层面，一个层面是共享存储的脑裂，另外一个层面是数据库RAC层面的脑裂，共享存储的脑裂通过第三方站点仲裁避免，数据库层面的脑裂通过磁盘心跳和网络心跳避免，由于发生心跳网络中断时可能同时导致存储和数据库的仲裁，所以就要优先进行存储的仲裁，存储仲裁完将会导致数据库的磁盘心跳的仲裁，这样就避免了存储和数据库的仲裁不一致的情况。当然存储仲裁的第三方站点是放在另外的机房的一般不会同时第三方站点损坏，存储心跳和数据库心跳也中断的情况。

回复2：wanggeng 系统运维工程师 , 某银行
根据一些资料的介绍，我们知道EMC的存储仲裁一般15秒左右，数据库的仲裁是通过参数missmount设置，要想不发生脑裂的现象，如何设置这个参数参数很重要，其中需要参考光纤速率，光纤稳定性，业务响应时间等诸多因素进行设定。
再次，数据库集群中可以设置优先写，优先读等关键参数，比如主中心注重写，备中心偏重读，这里面可以设置scanip的分配策略等。

回复3：zihan524524 其它 , 某银行
脑裂是通过多重心跳来防止的，最主要的是网络心跳和磁盘心跳，即使数据库节点之间不能通讯，数据库集群也会保证优先级高的节点来提供服务，其他的节点会被kill掉，所以不会担心脑裂的情况。

回复4：Switcher 数据库管理员 , 某银行
RAC尽量选择在同机房部署，同城机房或者异地机房尽量以ADG为主。
当然，对于某些企业有自己专用线路并且线路还是多条冗余，不依赖供应商线路的企业，做跨机房的RAC才会推荐。

2、同城灾备网络大二层打通会选择什么方案？选择依据是什么？

目前同城数据中心在做双活架构时基本都会考虑大二层打通，实现大二层打通有多种方案比如Vxlan、思科的OTV等，依据最佳实践建议那种组网方案是那种？

回复1：jampg 系统运维工程师 , 某大型保险
我们是采用了vxlan来做的。 VLAN实际上就是把原始二层报文进行隧道协议封装，在网络中透明传输，屏蔽中间网络的结构和细节，整个中间网络就是一台二层交换机，各个数据中心的主机都直连这台二层交换机。天然支持跨数据中心的大二层网络。OTV就有点类似于VPN技术，他将二层数据报文封装在三层报文中，跨越中间的三层网络，从而实现二层的互通。

回复2：唐国兵 系统架构师 , LinuxONE
需要根据实际物理环境及资源条件选择适合的大二层互联方案：

1. 网络设备虚拟化方案。当主备数据中心的网络设备支持网络设备虚拟化功能时，可以考虑将主备交换机跨数据中心堆叠成一台设备，从而实现主备数据中心的大二层互联。但此种方案要求主备数据中心须部署同型号网络设备，数据中心之间具备光纤直连和 DWDM 堆叠线缆的硬件资源且数据中心之间距离通常不能超过 10km 。另外，网络设备虚拟化需要主备设备横向之间进行堆叠线缆及心跳监测线缆的互联，且纵向级联设备的链路聚合也需要跨数据中心进行，因此对数据中心之间的线路质量要求较高，且会占用 DWDM 资源的多个通道。
2. 二层“路由”方案。如果同城主备数据中心之间具备二层互联的资源环境也可以考虑利用二层“路由”方案建立大二层互联，以 TRILL 为例，可以将主备数据中心的 TRILL 网络建立在同一个 TRILL 域中，通过 TRILL 协议完成二层数据帧跨数据中心的路由转发。但该方案缺点是需要更新支持 TRILL 协议的网络设备，现有网络架构变动及硬件投入成本较大。
3. Overlay 隧道方案。以 VXLAN 为代表的 Overlay 技术可以较好地支持跨数据中心的大二层互联，只要主备数据中心之间具备三层网络互联条件，且作为隧道接入节点的网络设备（ VTEP 节点）支持 VXLAN 协议即可。

3、应用级灾备架构设计如何设计性价比更好？另外在选型方面有什么建议？

现有的应用部署在虚拟化上，核心数据库部署在小型机上，如果要做应用级灾备架构设计如何设计性价比更好？另外在选型方面有什么建设？

回复1：邓毓 系统工程师 , 江西农信
以通俗的语言理解应用级灾备：
1、灾备端部署了应用节点，和生产应用程序/配置一致，并可以接管生产应用
2、灾备端部署了数据库节点，和生产数据实时/异步一致，并可以接管生产数据库
要求性价比高，就是尽量简单，但能达到要求。灾备端的硬件可以半配，但必须和生产硬件平台保持一致，可以升级生产硬件配置，替换后的硬件当作灾备，也可以直接在灾备购买半配的硬件。有了硬件后，灾备应用可以直接部署，可以考虑不打通网络大二层，只是将二层网络引到灾备端，省了一笔费用。但没有大二层，没有裸光纤波分复用，数据的同步就需要靠TCP/IP来做，要么在灾备端部署一套和生产同构的存储，用IP复制来同步，要么直接用数据库基于日志的复制技术来做。前者的灾备端主机无法挂起同步过来的数据盘，后者可以直接在灾备端主机上读数据库，后者性价比更高。

回复2：asdf-asdf 研究学者 , cloudstone
灾备需要看你对风险的承受力来配置灾备中心的硬件配置，建议核心系统预留500%以上算力
其他系统预留30%以上算力。看业务在切换完成需要承受的前端业务能力确定这些数据

回复3：bbaimm88 研发工程师 , 四川城商行
配置灾备中心的硬件配置，建议核心系统与生产保持2：1以上，其他数据库计算资源配置2：1，应用计算资源根据你系统真实计算使用率来配置吧。当业务在切换完成后能承受的业务就可以了，毕竟灾备使用不多。若果你是金融也加大投资吧。 数据重于一切。

回复4：03500408163.co 数据库管理员 , gansubank
应用级灾备目前已经基本都是应用双活+数据库的主备这种方式，应用的双活依赖DNS和F5都可以做，数据库的话双活来讲由于受到运营商线路质量的影响比较大，基本还是采用主备的这种方式。成本的话要看你是要实现那个级别的灾备，如果是想灾备可以完全接管业务的话，那成本肯定少不了。如果要减少成本可以考虑服务器配置减半。

回复5：jampg 系统运维工程师 , 某大型保险
我们目前使用linuxone,分享一下
•使用LinuxONE服务器，作为灾备应用资源池；
•该资源池上目前分配了近1000个虚拟机，用来运行部分总部应用灾备及13个省的应用灾备任务；
•在此基础上，充分利用了LinuxONE资源复用的特点，承担测试环境的任务；
看到的优势
•与传统X86架构刀片方案相比，从13个机柜缩减为6个机柜，节省了机房空间；
•经多次演练与调优，L1平台CPU使用率未超过40%，还有很大提升性能空间；
•很好的规避了传统平台有可能面临的单台资源瓶颈，同时还可以与当前云管平台契合，实现灵活资源交付。

4、保险企业异地远距离数据中心架构设计建议？

目前我们只有一个集中管理的数据中心，承载大部分核心和周边生产业务，我们要在外地建设数据中心（距离250公里以上），请问：1.新地址适合建设什么功能的数据中心。2.如何设计敏态应用架构 3.有哪些节约成本的办法或者黑科技

回复1：03500408163.co 数据库管理员 , gansubank
250公里只能做数据级的灾备吧，要做应用级灾备的话成本太高，而且必要性也不大，你的数据中心的建设本来就要考虑应对各种非自然灾害，异地主要是应对超大自然灾害，这种情况发生的概率跟你投入的成本相比就太浪费了，必要性不大。敏态应用要看适合那些业务场景了，比如银行的应用场景肯定不适合敏态，银行主要是稳定，敏态应用主要适用于互联网业务，错了可以异步补救。

回复2：jampg 系统运维工程师 , 某大型保险
先确定数据中心的定位吧，是做纯灾备中心、还是做双活的异地数据中心。
纯灾备的话就比较简单了，源端是什么，目标端接着就行，时效性要求也不高。
设计敏态应用的话，应该是需要做双活，主要问题还是距离太远，无法避免的就是时延，这个只能应用上去接受。

5、保险应用上云趋势下，如何规划云上应用灾备？

1、目前保险应用有逐步上云的趋势，如何规划云上应用的灾备？本地灾备机房与云上灾备是怎样的一种形式存在？
2、请介绍下应用级灾备的实现方式，灾备的日常运维中，通过什么手段保证数据的完整性与可靠性？

回复1：邓毓 系统工程师 , 江西农信
1、应用灾备云的确是趋势，可以省去很多成本开销，包括机房自建、动力、网络、暖通和后续运维等成本，同时也起到了灾备的效果。当然这个云不是企业私有云而是公有云，在公有云上部署应用，并通过公网DNS进行负载或引流，让公有云上应用也活起来，比较适合互联网类的应用，对于非互联网类的应用，还需要考虑将营业厅/网点/机构到数据中心的传统的专线改为公网，或者专线和公网并行。
2、保证生产和灾备数据的一致性的问题，我在其他问题中也有提到，可以参考：
有两种方式，一种是技术上，一种是流程上。
技术上有两种方式：
一是通过克隆，例如VMWARE SRM+VP（VMWARE软件复制）/存储复制，来保证主中心和灾备中心的虚拟机的一致性，应用也就一致了，只需要用SRM切换即可。这时灾备节点和生产节点都是完全一样的（OS/IP/应用等）。
二是灾备节点完全重新搭建，生产和灾备应用没有任何复制关系，借助自动化平台和工具等手段去检测两端的一致性，并批量同步变更生产节点和灾备节点。这时灾备节点和生产节点除了应用是一致的，OS/IP等都不一样。
流程上也有两种方式：
一是从变更流程上去保证同步，在设计变更流程时需要考虑到灾备节点的同步变更，落实到流程节点中的责任人，并在变更步骤中体现详细的变更操作，并具备专人审核。
二是从真实演练中去发现是否同步，通过上面的技术方式仅仅是从行为上保证了一致性，灾备节点真正是否可以真实有效接管业务，依旧需要每年多次的演练去保证，发现问题可以反过来去优化流程、优化自动化监测手段和自动化投产工具，相互相成，同时也可以完善应急预案。

回复2：jampg 系统运维工程师 , 某大型保险
数据的完整性和可靠性，我们主要通过两方面
一是存储级的数据复制，作为最可靠的保证。
另一个数数据库级的高可用，包括rac、HA、一主两从等。
上云的一般都是偏互联网的应用，代表着敏捷、快速迭代，传统保险公司要上云本身就是一个漫长的过程，所有人都没有办法一下就完成上云这个动作，自有的灾备机房和云上的灾备本身定位就不同，相辅相成。尤其是在过渡阶段。

6、灾备中心和主中心应用如何同步？ 目前就是做了数据同步？

我们建立了灾备机房，但两边无法应用同步，只是通过dg和其他工具做了数据库同步。

回复1：邓毓 系统工程师 , 江西农信
有两种方式，一种是技术上，一种是流程上。
技术上有两种方式：
一是通过克隆，例如VMWARE SRM+VP（VMWARE软件复制）/存储复制，来保证主中心和灾备中心的虚拟机的一致性，应用也就一致了，只需要用SRM切换即可。这时灾备节点和生产节点都是完全一样的（OS/IP/应用等）。
二是灾备节点完全重新搭建，生产和灾备应用没有任何复制关系，借助自动化平台和工具等手段去检测两端的一致性，并批量同步变更生产节点和灾备节点。这时灾备节点和生产节点除了应用是一致的，OS/IP等都不一样。
流程上也有两种方式：
一是从变更流程上去保证同步，在设计变更流程时需要考虑到灾备节点的同步变更，落实到流程节点中的责任人，并在变更步骤中体现详细的变更操作，并具备专人审核。
二是从真实演练中去发现是否同步，通过上面的技术方式仅仅是从行为上保证了一致性，灾备节点真正是否可以真实有效接管业务，依旧需要每年多次的演练去保证，发现问题可以反过来去优化流程、优化自动化监测手段和自动化投产工具，相互相成，同时也可以完善应急预案。

回复2：jampg 系统运维工程师 , 某大型保险
看两个数据中心用的硬件平台是否一致
一致的话，直接存储底层复制就可以。
不一致的话数据导入导出比较折腾。

7、保险行业灾难演练过程中，如何清除脏数据和定位脏数据？

保险经常做灾难演练，然而灾备在演练过程中时常会出现一些脏数据，不知道应该如何定位脏数据与清除脏数据？不知道是否有这方面的经验

回复1：邓毓 系统工程师 , 江西农信
由于灾难演练过程时间窗口有限，在生产切到在灾备做真实的业务演练后，会产生很多演练数据，值得关注的是账务数据和真实客户数据，据我了解，通用的做法有三种：
1、建立了生产和灾备存储间的实时/异步同步和切换后的反向复制，当生产切到灾备后，复制关系也将同步反转，由灾备存储实时/异步复制到生产，这是在灾备端的变更，也将复制回生产端。对于异步复制方式，在演练完成后，停止应用的继续写数据，在生产和灾备端数据完全一致后，再回切至生产。
2、仅仅只能建立一端到另一端的复制，复制关系无法反转，若需要反转需要删除原复制关系，重新建立反向复制关系。对于这种方式，通常有两种行业的做法：
（1）切到灾备演练后，不进行回切，因为反向同步需要大量时间，没有太多的时间窗口。这时就在灾备端运行一段时间，待数据完全/准完全同步回生产后，再次选择时间窗口进行回切演练。
（2）切到灾备演练后，不开启对外的外围渠道或服务，仅仅开启可控的渠道进行业务演练，演练后，放弃掉灾备端产生的演练数据，直接回切回生产，再开启全量的外围渠道或服务。

回复2：jampg 系统运维工程师 , 某大型保险
灾备环境是通过存储复制过去的数据，每天会克隆一次。
当作灾备演练的时候，有专门预留的单子做验证，演练结束之后，只需重新克隆即可，脏数据直接覆盖掉。

8、应用级灾备如何保证应用一致性？

对于异地应用级灾备，如何保证生产端应用节点的各项配置（OS、中间件、应用、网络权限等）与灾备端的一致性，在异常时，灾备端可真实接管？

回复1：邓毓 系统工程师 , 江西农信
可以从四个方面去保证：
一是从变更流程上去保证，在设计变更流程时需要考虑到灾备节点的同步变更，落实到流程节点中的责任人，并在变更步骤中体现详细的变更操作，并具备专人审核；
二是必须借助自动化手段去检测一致性，做应用灾备时，不仅考虑到如何做成，如何一次性保证灾备应用节点和生产的一致性，更要考虑如何去保证增量的一致性，通过自动化平台定时检测这些增量部分和变化部分，并通知相关人员注意。
三是借助自动化投产去保证，借助自动化投产工具，批量同步变更生产节点和灾备节点。
四是从真实演练中去发现，通过上面三种方式仅仅是从行为上保证了技术上的一致性，灾备节点真正是否可以真实有效接管业务，依旧需要每年多次的演练去保证，发现问题可以反过来去优化流程、优化自动化监测手段和自动化投产工具，相互相成，同时也可以完善应急预案。

回复2：jampg 系统运维工程师 , 某大型保险
灾备端可真实接管这个我个人觉得不是太对，应用级灾备不代表自动切换，更不代表100%做到数据不丢失。
1、不管是灾备中心还是生产中心，所有的操作都是有规则、有严格流程的，只有按照标准操作，咱们的数据中心才能对外提供服务，技术上能做到两端的一致性，但也是有一定前提的。
2、不是每次异常都需要让灾备端来接管的，每一次灾备演练都需要投入大量的人力，更别说真实的灾备事件了，至少我们是不会选择让应用在出现异常的时候自动切换到灾备端。
3、我个人认为异地灾备本身就是极小概率事件。

9、生产切换到灾备环境之后的回切，有什么好的解决方案吗？

目前的灾备环境，数据库是利用oracle工具从生产数据库实时同步的，应用系统程序版本会定期从生产同步过来。灾备环境平时都是冷备的。现在的问题是，一旦哪天生产环境出现灾难场景，切换到灾备环境运行一段时间后，假设生存环境灾难排除，那么如何才能快速完美的切回生产环境？主要是灾备环境设备配置一般比生产环境较低，所以再重新切回生产是必要的，但是有个问题，就是灾备环境运行一段时间后，生产和灾备的数据就不一致了，想在切回生产就不是那么容易了。

回复1：asdf-asdf 研究学者 , cloudstone
分几个场景：
rac数据库灾备的备库启动，数据如何返回主库
rac数据库如何和已经启动的备库同步
回切先确定数据量问题，目前市场上有通过数据库archlog进行恢复的技术
或者把灾备的数据库做主库然后生产做备库完全同步后找个变更时间完成数据库业务回切在做rac技术数据库保护。

回复2：Switcher 数据库管理员 , 某银行
“Oracle工具”这个描述太含糊了，工具使用的不一样回切后的同步也不一样。
常见的工具大概以下几种吧：
1.oracle dataguard
使用DG的话，由于你的primary——standby关系已被破坏，因此只能进行灾备环境到生产环境的“重拉”，然后在归档追上后，进行primary——standby的角色互换即可。
2.各类redo挖掘技术的软件
这类产品市面上很多家都有，由于技术上是通过解析redo、archive这些，所以不存在“角色”的概念，要进行回切还是非常简单的。反向同步，待完成后同步方向互换即可。
由于你说的是oracle工具，那么存储级别的技术就不在此讨论了

回复3：jampg 系统运维工程师 , 某大型保险
核心问题就是灾备的数据如何同步到主数据中心。
换个角度，在灾备中心运行的这段时间里，灾备中心就是“生产中心”，而如何将“生产中心”的数据同步到异地的生产中心去，oracle本身提供了很多追数的办法，存储级别也有很多解决方案。

10、保险行业核心系统灾备能做到异地双活吗，成本是不是要很高很高？

一般中小型保险公司就只有一个数据中心，按照银保监会的要求各保险公司需构建灾备系统，通常会选择异地搭建灾备系统。为了实现灾难情况下的快速切换，不考虑成本因素，如果生产系统和灾备系统能实现双活无疑是最理想的。两套环境在同一个数据中心内部做到双活可能比较容易，但是异地的话，两个数据库的同步机制就是问题。所以我想了解一下，目前保险行业有做到灾备与生产系统异地双活的吗？是不是对专线网络带宽要求特别高？如何实现数据库的同步？

回复1：skey_deng 系统运维工程师 , 大连农村商业银行股份有限公司
正如江西农信邓老师说的，不考虑地理距离问题，谈双活架构就是耍流氓。
举个传统架构的例子，以下纯理论，不考虑任何消耗：
2015年我行在探索双活架构时，测试在核心系统日均交易量50万左右时，EMC存储的写I/O是465M/s,运营商用单模光纤有效传输距离是40KM，秒传输速度是100Mbps,那么如果是同步传输的话，写到备库的时间就是5秒左右，但是我们的业务要求的交易响应延迟需要在200ms以内，那么这就需要一条25芯裸光纤，各位可以考虑成本问题。
说下我们没有考虑的问题：
1、光衰问题
2、上面是以单根裸光纤为基础的推论，不包含中继器。
3、不考虑环境对光纤的影响，比如噪音，温湿度等情况。
4、不考虑光波复用等设备的损耗。
我们以上的推论是以40KM为基础的，但任何一个行的异地灾备中心也不仅仅是40KM这么近吧。

《中国银行业监督管理委员会办公厅关于印发<商业银行数据中心监管指引>的通知》（银监办发﹝2010）114号）要求灾备中心异地模式是指灾备中心与生产中心处于不同地理区域，一般距离在数百公里以上，不会同时面临同类区域性灾难风险，如地震、台风和洪水等。
假设我们异地灾备中心的距离是120KM，那么我们理论上要使用的光缆就要是75芯，运营商常用光缆是48芯的，那么就需要两条，仅仅应付写。
我们现在租赁的光缆是8芯的，有3个跳点，年租金是24万，按照上面的理论推算光纤租赁费用为288万/年，如果还有备线，还要考虑读，还要考虑损耗，个人估计一年光光纤的租赁就差不多要上千万，当然这个钱对大行可能不算个事，但是大行的业务交易量也不止50万这个水平啊，所以个人认为成本投入太高。
以上仅仅是成本方面的推论，技术上的瓶颈还需要我们进一步挖掘，当时我们就遇到仲裁的问题，现在随着技术发展可能解决了，但还是有待我们探索。
最后说下分布式的说法，个人认为分布式也绕不开数据一致性的问题，多副本的同步更加大了数据传输的需求，分布式只能说是提高了解决问题的技术可能性，但是成本可能更高（个人认为）。

回复2：huijx 系统架构师 , 华泰保险
异地双活数据一致性的要求难以达到，因为实际的距离决定了传输延迟，而双活对传输延迟要求非常苛刻。异地灾备的数据库同步全是异步。

回复3：邓毓 系统工程师 , 江西农信
目前技术而言，金融行业，核心系统异地双活难以实现，这其中的关键在于异地之间的距离，不谈距离说双活就是耍流氓，在合适的距离情况下，追求账务数据强一致性，保证RPO必须为0，牺牲一定的响应时间是能够实现双活的，至于牺牲多大看异地间距和业务并发，不可一概而论，对于金融行业的核心系统而言，难以接受这种牺牲。

回复4：jampg 系统运维工程师 , 某大型保险
要做异地双活，传统的架构太难了。
对于中小保险公司，考虑向分布式架构转型，做异地双活就简单多了。

11、linuxONE是否需要改造机房供电和制冷等配套设施？

看活动资料里数据估算， linuxONE 的用电量相当于70台左右的x86用电量，不知道是否需要按此功率调整机房的供电（如线缆数量和平方数）以及制冷（如密度和风道）？有没有范例方案？
**
回复1：jampg 系统运维工程师 , 某大型保险**
这个数据应该是根据额定功率计算出来的，不知道你们是自由机房还是托管的机房。
我们目前主要放置在托管机房，应该没有做特殊的改造，之前的电力和制冷能够满足。

回复2：唐国兵 系统架构师 , LinuxONE
供电基本不需要改造，一般而言，LinuxONE需要2-4根供电电源线缆，目前单柜使用的是220v,，双柜需要380v, 如果客户机房没有380v的电源是需要单独准备的，其它的和传统使用没区别。而耗电量而言，LinuxONE实际功耗根据配置各不相同，单柜为1.36kW到6.12kW之间，双柜为5.7kW-27.8kW之间，而x86普遍从几百W到几kW之间，所以只要整合到一定数量，可能几台或者10台，20台，这个能耗优势就慢慢体现出来了，如果是70台的话，是明显节约的，至少能节约一半以上，但是x86数量多了之后反而对
数据中心能耗的要求更高，供电不足问题反而更多，改造可能性也更大。

而制冷就完全没有改造的必要，LinuxONE的产品越来越标准化，做到和现有标准机房无缝融合，都是整机柜摆放，和传统机柜一样，另外LinuxONE机柜内自带的散热体系密度相当高，所以相对而言，也是更节约能耗的一种解决方案。

12、双活数据中心中心大二层的相关技术有哪些？

回复1：唐国兵 系统架构师 , LinuxONE
目前实现大二层网络架构的技术手段主要分为三大类
1.网络设备虚拟化技术
所谓网络设备虚拟化技术，是将相互冗余的两台或多台物理网络设备组合在一起，虚拟化成一台逻辑网络设备，在整个网络中只呈现为一个节点。同时配合链路聚合技术，将级联设备之间的两条或多条冗余线路聚合成一条链路，这样就可以把原来的多节点、多链路的结构变成逻辑上单节点、单链路的网络结构。这样以网络设备虚拟化 + 链路聚合技术构建的二层网络必然不会形成环路，也就不再需要 xSTP 等破环协议的配合。而且网络设备虚拟化 + 链路聚合技术具备冗余备份功能，单台物理设备或者链路故障时，可以自动切换到其他物理设备和链路来进行数据转发，保证网络的可靠性。
2.二层“路由”技术
三层网络是依靠路由协议来计算转发路径的，通过路由协议每台路由设备就可以收集、扩散和更新彼此的路由信息，进而每台设备可以知道全部或者局部网络的拓扑信息，所以在数据转发时可以保证从某个主机发出的报文只会向着目标主机一路前进，而不会再返回前续节点而造成路径循环。二层“路由”技术就是把三层网络的路由转发思想引入到二层网络中，通过在二层报文前插入额外的帧头，并且采用路由计算的方式控制整网数据的转发，不仅可以在冗余链路下防止广播风暴，而且可以做负载均衡。这样可以将二层网络的规模扩展到整张网络，而不会受核心交换机数量的限制。当然这需要交换机改变传统的基于 MAC 的二层转发行为，而采用新的协议机制来进行二层报文的转发。
3.Overlay 隧道技术。
Overlay 技术是通过用隧道封装的方式，将源主机发出的原始二层报文封装后在现有网络中进行透明传输，到达目的地之后再解封装得到原始报文，转发给目标主机，从而实现主机之间的二层通信。通过封装和解封装，相当于一个大二层网络叠加在现有的基础网络之上，所以称为 Overlay 。从实现原理上看， Overlay 技术与二层“路由”技术非常相似，都是通过将原始二层报文进行再次封装实现透明二层传输，只不过二层“路由”技术定义了 MAC-in-MAC 的转发机制，而 Overlay 技术则定义了 MAC-in-IP 或 MAC-in-UDP 的转发机制。但二者不同的地方在于二层“路由”技术定义了自身的二层路由协议且要求大二层转发过程中的每一跳节点都须支持并运行该路由协议，而 Overlay 技术除去大二层边缘节点负责封装 / 解封装外，中间隧道传输过程完全基于现有的三层基础网络而不再需要额外改造，其核心就是通过点到多点的隧道封装协议，完全忽略中间网络的结构和细节，把整个中间网络虚拟成一台“巨大无比的二层交换机”，每台主机都是直接连在这台“巨大交换机”的一个端口上。而基础网络之内如何转发都是这台“巨大交换机”内部的事情，主机完全无需关心。

Overlay 技术相对于二层“路由”技术从实现上更为简单，且 VTEP 即可由虚拟机中的 vSwitch 担当也可以由 TOR 等网络交换机担当，投入成本相对较低。同时在支持 SDN 及多租户方面也有明显优势，因此也成为当前实现大二层网络的主流技术。

回复2：jampg 系统运维工程师 , 某大型保险
VLAN实际上就是把原始二层报文进行隧道协议封装，在网络中透明传输，屏蔽中间网络的结构和细节，整个中间网络就是一台二层交换机，各个数据中心的主机都直连这台二层交换机。天然支持跨数据中心的大二层网络。OTV就有点类似于VPN技术，他将二层数据报文封装在三层报文中，跨越中间的三层网络，从而实现二层的互通。

13、如何应用“云”构建核心业务系统的灾备体系呢？

回复：唐国兵 系统架构师 , LinuxONE
云灾备是灾备业务的实现形式，主要包括云备份与云容灾，这二者是一个有机体，其中云备份是指备份技术将数据直接备份到云平台上，进而实现数据备份与恢复功能；而云容灾则是指通过数据 / 系统的云端迁移、高可用等方式实现业务的快速接管，保证业务连续性。其中，云灾备的特点包括：减少基础设施、降低 IT 成本；按需付费，具有高度机动性；可快速恢复，具备高度灵活性；安全备份，以服务为导向。
在构建核心灾备体系上云的时候最重要的前提是认清当前技术无法做到保障数据万无一失，同时提升数据安全意识。核心业务灾备一定要构建在多云环境中，提升业务连续性和可靠性，通过一些解决方案，比如块级恢复技术，实时立体保护用户环境中的文件、应用、操作系统及虚拟机，实现快速高效的持续数据保护。同时要确保云上业务灾备至本地，也能保证本地数据容灾至云，无论云上系统还是本地数据中心出现故障或业务中断，都可在灾备节点快速恢复数据，保障企业云上云下业务连续。
在云端主机恢复方案中，一定要量化指标，比如能不能达到实时保护，多少时间能够实现数据恢复，快照
的时间粒度，确保有本地留存，本地可以快速接管， 传输过程支持断点续传、压缩加密。支持将本地数据中心数据容灾到云；支持当本地数据中心发生站点级灾难导致数据丢失时，可从云上恢复数据等等。

14、核心业务系统异地应用级灾备如果部署在云上与部署在本地的优缺点？有需要特别考虑的地方吗？安全如何考虑？

回复：唐国兵 系统架构师 , LinuxONE
部署在云上和本地都可以，但是如果能够成功稳定的部署在云上， 能提供动态的资源池、虚拟化以及高可用性，并且能使 IT 具有强大的灵活性，能根据业务的需求而随时作出相应调整，能够通过提高资源利用率来增强盈利能力。部署在云上也使个人、团队和企业能简化采购流程，并避免重复掌握涉及安装、配置和支持的特定计算机管理技能。这些都是企业越来越愿意把业务逐渐转向云平台上。
几年前，影响云计算应用的两个最大障碍是云计算的安全性和可靠性。随着时间的推移，人们已经了解到云计算可以像内部部署一样安全（甚至更安全）。但这并不是说采用云计算是万无一失的。仍然有大量的重大停机事件，所以目前大部分核心业务没有上云，主要也在于安全，合规性，部署地点等限制和担心，以及企业客户再寻求更多或者更优的选择。去年看到一个很有趣的预测，认为2019年出现的停机事件会更加突出一个风险，就是企业依赖单个云平台。这也是未来发展的趋势——混合多云架构，多云可以是同一运营商的不同区域云，也可以是不同供应商的云平台，也可以是私有云和公有云的混合，确保架构发展的合理性，提升企业对于关键业务上云的安全和可靠性控制。而云计算服务提供商遇到的数据中心问题并不多，通常都是由于人为错误。有人说，应用云计算就是使用别人的电脑，但 “ 别人 ” 也会容易出错。 除了云运营商提升运维管理能力以外，其实我们也看到其他思路，比如 IBM LinuxONE 通过安全服务容器的方式确保未经授权的内外部访问，从底层硬件来做隔离，也有云服务商提供专属关键业务云确保安全和可靠性。 目前从技术层面来说云平台已经能够提供和本地部署相同的保障能力，甚至更高，但是企业关键业务上云路线上，还是必须考虑刚才提到的合规性，安全性和可靠性，选择最合适的平台，最合理的组合确保企业关键业务上云。