高可用性集群解决方案HA

合集下载

VMware vCenter 高可用性 HA 详解

VMware vCenter 高可用性 HA 详解

VMware vCenter 高可用性 HA 详解时间: 2011-07-01 分类: VMware标签: DRS, HA, vCenter, VM, vMotion / 1,455 次浏览0 评论VM ware HA简介HA的全称是High Availability(高可用性)。

VM ware HA群集一般具有一个包括两个或者两个以上ESX 主机的逻辑队列。

在一个HA群集中,每一台VM ware ESX服务器配有一个HA代理,持续不断地检测群集中其他主的心跳信号。

假如某台ESX主机在连续三个时间间隔后都还没有发出心跳信号,那么该主机就被默认为发生了故障或者与网络的连接出现了问题。

在这种情况下,原本在该主机上运行的虚拟机就会自动被转移到群集中的其他主机上。

反之,如果一台主机无法接收到来自群集的其他主机的心跳信号,那么该主机便会启动一个内部进程来检测自己跟群集中其他主机的连接是否出现了问题。

如果真的出现了问题,那么就会中断在这台主机上所有正在运行的虚拟机,并启动预先设定好的备用主机。

此外,VMware HA的另一个显著的特点是能够对一个群集中的多台ESX服务器(多达四台)上进行故障转移。

对于一次VMware HA故障转移,客户端操作系统认为只是一次因硬件的崩溃而进行的重启,并不会觉察到是一次有序的关机。

因此,这样的修复并不会改变操作系统的状态。

此外,虚拟机中任何正在进行的业务也不会丢失。

即使备用ESX服务器主机的硬件设备跟原ESX服务器主机的硬件设备有所不同,客户端操作系统也不会检测到这种不同。

所以,VMware HA的故障转移对于客户来说可以算是完全透明的,几乎不会出现任何停机的危险。

1. VMware HA 提供快速中断恢复VMware HA 利用配置为群集的多台 ESX/ESXi 主机,为虚拟机中运行的应用程序提供快速中断恢复和具有成本效益的高可用性。

VMware HA 通过以下两种方式保护应用程序可用性:∙通过在群集内的其他主机上自动重新启动虚拟机,防止服务器故障。

HA高可用集群中脑裂问题解决-运维总结

HA高可用集群中脑裂问题解决-运维总结

HA⾼可⽤集群中脑裂问题解决-运维总结------ 什么是脑裂(split-brain)在"双机热备"⾼可⽤(HA)系统中,当联系两个节点的"⼼跳线"断开时(即两个节点断开联系时),本来为⼀个整体、动作协调的HA系统,就分裂成为两个独⽴的节点(即两个独⽴的个体)。

由于相互失去了联系,都以为是对⽅出了故障,两个节点上的HA软件像"裂脑⼈"⼀样,"本能"地争抢"共享资源"、争起"应⽤服务"。

就会发⽣严重后果:1)或者共享资源被⽠分、两边"服务"都起不来了;2)或者两边"服务"都起来了,但同时读写"共享存储",导致数据损坏(常见如数据库轮询着的联机⽇志出错)。

两个节点相互争抢共享资源,结果会导致系统混乱,数据损坏。

对于⽆状态服务的HA,⽆所谓脑裂不脑裂,但对有状态服务(⽐如MySQL)的HA,必须要严格防⽌脑裂[但有些⽣产环境下的系统按照⽆状态服务HA的那⼀套去配置有状态服务,结果就可想⽽知]。

------ 集群脑裂产⽣的原因⼀般来说,裂脑的发⽣,有以下⼏种原因:1. ⾼可⽤服务器各节点之间⼼跳线链路发⽣故障,导致⽆法正常通信。

2. 因⼼跳线坏了(包括断了,⽼化)。

3. 因⽹卡及相关驱动坏了,ip配置及冲突问题(⽹卡直连)。

4. 因⼼跳线间连接的设备故障(⽹卡及交换机)。

5. 因仲裁的机器出问题(采⽤仲裁的⽅案)。

6. ⾼可⽤服务器上开启了iptables防⽕墙阻挡了⼼跳消息传输。

7. ⾼可⽤服务器上⼼跳⽹卡地址等信息配置不正确,导致发送⼼跳失败。

8. 其他服务配置不当等原因,如⼼跳⽅式不同,⼼跳⼴插冲突、软件Bug等。

提⽰:Keepalived配置⾥同⼀VRRP实例如果virtual_router_id两端参数配置不⼀致也会导致裂脑问题发⽣。

VMware vCenter 高可用性 HA 详解

VMware vCenter 高可用性 HA 详解

VMware vCenter 高可用性 HA 详解时间: 2011-07-01 分类: VMware标签: DRS, HA, vCenter, VM, vMotion / 1,455 次浏览0 评论VM ware HA简介HA的全称是High Availability(高可用性)。

VM ware HA群集一般具有一个包括两个或者两个以上ESX 主机的逻辑队列。

在一个HA群集中,每一台VM ware ESX服务器配有一个HA代理,持续不断地检测群集中其他主的心跳信号。

假如某台ESX主机在连续三个时间间隔后都还没有发出心跳信号,那么该主机就被默认为发生了故障或者与网络的连接出现了问题。

在这种情况下,原本在该主机上运行的虚拟机就会自动被转移到群集中的其他主机上。

反之,如果一台主机无法接收到来自群集的其他主机的心跳信号,那么该主机便会启动一个内部进程来检测自己跟群集中其他主机的连接是否出现了问题。

如果真的出现了问题,那么就会中断在这台主机上所有正在运行的虚拟机,并启动预先设定好的备用主机。

此外,VMware HA的另一个显著的特点是能够对一个群集中的多台ESX服务器(多达四台)上进行故障转移。

对于一次VMware HA故障转移,客户端操作系统认为只是一次因硬件的崩溃而进行的重启,并不会觉察到是一次有序的关机。

因此,这样的修复并不会改变操作系统的状态。

此外,虚拟机中任何正在进行的业务也不会丢失。

即使备用ESX服务器主机的硬件设备跟原ESX服务器主机的硬件设备有所不同,客户端操作系统也不会检测到这种不同。

所以,VMware HA的故障转移对于客户来说可以算是完全透明的,几乎不会出现任何停机的危险。

1. VMware HA 提供快速中断恢复VMware HA 利用配置为群集的多台 ESX/ESXi 主机,为虚拟机中运行的应用程序提供快速中断恢复和具有成本效益的高可用性。

VMware HA 通过以下两种方式保护应用程序可用性:∙通过在群集内的其他主机上自动重新启动虚拟机,防止服务器故障。

开源HA解决方案

开源HA解决方案

开源HA解决方案《开源HA解决方案:构建稳定可靠的高可用系统》当今互联网时代,高可用性(HA)已经成为企业建设系统的重要指标之一。

在构建高可用系统时,开源软件解决方案的优势日益凸显。

开源软件具有灵活、定制性强的特点,可以满足不同企业的需求,同时,也能够降低成本,提高系统的可靠性。

开源HA解决方案是指基于开源软件构建的高可用系统解决方案。

常见的开源HA解决方案包括Pacemaker、Keepalived、Corosync等。

这些解决方案不仅能够保证系统的稳定性和可靠性,还可以提供灵活的配置和定制,满足不同企业的需求。

Pacemaker是一个常用的开源HA解决方案,它提供了很多高可用性功能,比如故障监测、自动故障切换、资源组管理等。

通过Pacemaker可以轻松构建起一个高可用的集群系统,保证系统的稳定性和可靠性。

Keepalived则是一个轻量级的负载均衡和故障转移解决方案,它可以将多台服务器组成一个高可用的集群,同时可以实现故障自动转移,确保系统的稳定性。

Corosync是一个消息传递层软件,它可以提供高可用系统必需的集群通信功能。

通过Corosync可以实现集群节点之间的通信和协调,确保集群系统的正常运行。

同时,Corosync支持灵活的配置和定制,可以满足不同企业的需求。

总之,开源HA解决方案能够帮助企业构建稳定可靠的高可用系统。

通过灵活的配置和定制,这些解决方案可以满足不同企业的需求,同时也能够降低成本,提高系统的可靠性。

相信在未来,开源HA解决方案会越来越受到企业的青睐,成为构建高可用系统的首选方案。

ha模式的工作原理

ha模式的工作原理

ha模式的工作原理在计算机系统中,高可用性(HA)模式是一种非常重要的容错机制,它能够确保系统的连续运行和数据的安全。

本篇文章将详细介绍ha模式的工作原理,包括其基本概念、硬件要求、软件要求、工作流程以及常见问题和解决方案。

一、基本概念高可用性模式(HA,High Availability)是指通过各种技术和管理手段,使得一个或多个服务能够在不间断的情况下运行,从而保障系统的稳定性和可靠性。

该模式主要包括硬件故障自动切换、软件容错、负载均衡等技术,以提高系统的可用性和性能。

二、硬件要求要实现ha模式,硬件要求主要包括以下方面:1. 服务器:至少两台服务器,用于运行相同的操作系统和应用服务。

2. 网络设备:交换机、路由器等网络设备,用于连接服务器和客户端。

3. 备份设备:备用硬盘、磁带等存储设备,用于数据备份和恢复。

三、软件要求实现ha模式需要选择合适的软件,以满足以下要求:1. 高可用性软件:如Heartbeat、Zookeeper等,用于监控和管理服务器集群。

2. 集群软件:如Pacemaker、Mongrel等,用于实现服务器之间的互斥、同步和故障自动切换。

3. 备份软件:如rsync、shadowcopy等,用于定期备份数据,确保数据安全。

四、工作流程ha模式的工作流程如下:1. 双机环境:两台服务器同时运行相同的操作系统和应用服务,相互备份。

2. 故障检测:高可用性软件会实时监测服务器的状态,一旦发现故障,会立即报警。

3. 自动切换:当一台服务器出现故障时,集群软件会自动将请求切换到另一台正常运行的服务器上,确保服务不间断。

同时,备份设备上的数据会进行同步更新,以便在需要时进行恢复。

4. 数据备份:使用备份软件定期备份数据,确保数据安全,防止数据丢失或损坏。

5. 配置管理:对所有服务器进行统一的配置管理,确保所有服务器运行在相同的标准配置下,提高系统的稳定性和可靠性。

五、常见问题及解决方案在实现ha模式的过程中,可能会遇到一些常见问题,以下是一些解决方案:1. 网络延迟:当两台服务器之间的网络延迟较大时,会导致自动切换失败。

PostgreSQL中的高可用性解决方案

PostgreSQL中的高可用性解决方案

PostgreSQL中的高可用性解决方案在现代的数据应用中,高可用性(High Availability,HA)是一个至关重要的因素。

在数据库领域,PostgreSQL提供了一些高可用性的解决方案,可以帮助用户实现数据的持续可用性和系统的可靠性。

本文将介绍一些常用的PostgreSQL高可用性解决方案。

1. 数据复制(Replication)数据复制是一种常见的高可用性解决方案,它通过将数据从主服务器复制到一个或多个备用服务器,实现数据的冗余存储和故障恢复能力。

PostgreSQL提供了多种数据复制方法,包括基于日志的物理复制(Physical Replication)和基于逻辑复制(Logical Replication)。

1.1 基于日志的物理复制基于日志的物理复制是PostgreSQL内置的一种数据复制方法,它通过复制主服务器上的事务日志(WAL),将变更的数据块物理复制到备用服务器。

这种方法可以实现快速的数据复制和故障切换,但对备用服务器的版本和配置要求较高。

1.2 基于逻辑复制基于逻辑复制是PostgreSQL 9.4及以上版本中引入的一种数据复制方法。

它通过解析和应用主服务器上的逻辑变更(例如INSERT、UPDATE、DELETE语句),将变更的数据逻辑复制到备用服务器。

这种方法相对灵活,可以实现不同版本和配置的备用服务器。

2. 流复制(Streaming Replication)流复制是PostgreSQL中一种基于日志的物理复制方法,它通过流式传输事务日志(WAL)来实现数据的持续复制和故障切换。

流复制要求主服务器和备用服务器之间有稳定的网络连接,并且备用服务器必须实时接收并应用主服务器上的更改。

2.1 同步流复制同步流复制是一种高可用性的方法,它确保主服务器上的事务在提交后,备用服务器立即应用并确认。

这种方法可以提供零数据丢失和最小的故障恢复时间,但对网络延迟和性能要求较高。

HACMP工作原理介绍

HACMP工作原理介绍

HACMP工作原理介绍HACMP(High Availability Cluster Multiprocessing)是一种高可用性的集群解决方案,旨在提供在系统或硬件失败发生时,保证应用程序持续可用的能力。

它通过在多个计算节点上部署应用程序和数据,并实时监控系统健康状况,来实现高可用性。

1.集群:HACMP通过将多个计算节点连接在一起形成一个集群。

每个节点都是一台具备计算和存储能力的服务器,运行着相同的操作系统和应用程序。

集群中的节点通过专用网络互相通信,实现对整个集群的协调和控制。

2.资源:在HACMP中,应用程序和其相关的数据被称为资源。

资源可以是单个的进程、服务、文件系统等。

HACMP对资源的管理包括资源的分配、启动、停止和迁移等操作。

3.心跳检测:为了实时监控系统的健康状况,HACMP引入了心跳检测机制。

每个节点通过定期发送心跳信号来表示自己的正常运行,其他节点接收到心跳信号后确认,如果长时间未收到心跳信号则判断该节点可能出现故障。

4.预定义和自动化的故障切换:当一些节点出现故障时,HACMP会自动将该节点上的资源切换到其他节点上,以保证应用程序的持续可用性。

切换的过程中,HACMP会确保数据的一致性,并在尽可能短的时间内完成切换操作。

如果故障节点恢复正常,HACMP会自动将资源切换回原节点。

5.监控和故障恢复:HACMP提供了一套完善的监控和故障恢复机制。

它实时监控系统中的节点状态、资源状态和网络连接等信息,并根据预定义的策略执行相应的故障恢复动作。

当故障发生时,HACMP会立即做出响应,启动资源切换和恢复节点操作。

通过上述工作原理,HACMP能够实现高可用性的应用程序部署和运行。

它具有以下优点:1.高可用性:HACMP提供实时监控和故障恢复机制,能够及时检测和处理系统和软件故障,保证应用程序持续可用。

2.负载均衡:HACMP能够根据系统负载情况,将资源合理地分配到不同的节点上,实现负载均衡和性能优化。

vmware 高可用性(集群HA)

vmware 高可用性(集群HA)

VMware高可用性(集群HA)1 应用层高可用性:如实现mysql、oracle数据库应用程序的储群集,主要是判断mysql、oracle 应用程序是否停止运行。

2 操作系统高可用性:如windows的故障转移群集(windows failover clustering WFC)。

3 虚拟化层的高可用性:如vsphere high availability(HA)和vsphere fault tolerance(FT)。

4 物理层的高可用性:如:多网络适配器、SAN等。

vSphere HA 和 Fault Tolerance(FT)功能分别通过提供中断快速恢复和连续可用性来最小化或消除非计划停机时间。

使用 vSphere,企业可以轻松提高为所有应用程序提供的基准级别,并且以更低成本和更简单的操作来实现更高级别的可用性。

使用vSphere,你可以:a 独立于硬件、操作系统和应用程序提供更高可用性。

b 减少常见维护操作的计划停机时间。

c 在出现故障时提供自动恢复。

一、vSphere HA 提供快速中断恢复vSphere HA 利用配置为群集的多台 ESXi 主机,为虚拟机中运行的应用程序提供快速中断恢复和具有成本效益的高可用性。

vSphere HA 通过以下方式保护应用程序可用性:1 通过在群集内的其他主机上重新启动虚拟机,防止服务器故障。

2 通过持续监控虚拟机(通过vmware tools实现主机向虚拟机发送检测信号)并在检测到故障时对其进行重新设置, 防止应用程序故障。

与其他群集解决方案不同,vSphere HA 提供基础架构并使用该基础架构保护所有工作负载:a 无需在应用程序或虚拟机内安装特殊软件。

所有工作负载均受 vSphere HA 保护。

配置 vSphere HA 之后,不需要执行操作即可保护新虚拟机。

它们会自动受到保护。

(需在开机状态下才受保护)b 可以将 vSphere HA 与 vSphere Distributed Resource Scheduler (DRS即负载均衡) 结合使用以防止出现故障,以及在群集内的主机之间提供负载平衡。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

1.业务连续1.1.共享存储集群业务系统运营时,服务器、网络、应用等故障将导致业务系统无法正常对外提供业务,造成业务中断,将会给企业带来无法估量的损失。

针对业务系统面临的运营风险,Rose提供了基于共享存储的高可用解决方案,当服务器、网络、应用发生故障时,Rose可以自动快速将业务系统切换到集群备机运行,保证整个业务系统的对外正常服务,为业务系统提供7x24连续运营的强大保障。

1.1.1.适用场景基于共享磁盘阵列的高可用集群,以保障业务系统连续运营硬件结构:2台主机、1台磁盘阵列主机备机心跳磁盘阵列局域网1.1.2.案例分析深圳某证券公司案例客户需求分析某证券公司在全国100多个城市和地区共设有40多个分公司、100多个营业部。

经营范围涵盖:证券经纪,证券投资咨询,与证券交易、证券投资活动有关的财务顾问,证券承销与保荐,证券自营,证券资产管理,融资融券,证券投资基金代销,金融产品代销,为期货公司提供中间介绍业务,证券投资基金托管,股票期权做市。

该证券公司的邮件系统承担着企业的内部沟通、关键信息的传达等重要角色,随着企业的业务发展,邮件系统的压力越来越重。

由于邮件服务器为单机运行,如果发生意外宕机,将会给企业的日常工作带来不便,甚至给企业带来重大损失。

因此,急需对邮件服务器实现高可用保护,保障邮件服务器的7×24小时连续运营。

解决方案经过实际的需求调研,结合客户实际应用环境,推荐采用共享存储的热备集群方案。

部署热备集群前的单机环境:邮件业务系统,后台数据库为MySQL,操作系统为RedHat6,数据存储于磁盘阵列。

在单机单柜的基础上,增加1台备用主机,即可构建基于共享存储的热备集群。

增加1台物理服务器作为邮件服务器的备机,并在备机部署邮件系统,通过Rose共享存储热备集群产品,实现对邮件应用的高可用保护。

如主机上运行的邮件系统出现异常故障导致宕机,比如应用服务异常、硬件设备故障,Rose将实时监测该故障,并自动将邮件系统切换至备用主机,以保障邮件系统的连续运营。

客户端局域网心跳电子邮件服务器(主机)电子邮件服务器(备机)磁盘阵列系统特点业务连续运营实时监测邮件服务运行状态,如出现软、硬件故障,自动将邮件系统切换至备用主机,以保障邮件系统连续运营。

⏹容错结构基于共享存储的热备集群,由2台服务器、1台磁盘阵列构成,服务器、磁盘阵列等硬件设备容错,解决单点故障。

⏹监控应用和系统资源实时监测应用服务运行状态,并支持深度监控CPU/内存资源使用率,可进行智能预警和策略切换。

⏹充分利用现有资源可利用现有软、硬件资源,轻松构建热备集群方案,避免重复投资。

⏹简化运维Rose提供友好的图形化界面,用户可以远程管理热备集群,并监管集群工作状态。

提供多种事件告警方式,比如在线状态、在线日志、短信、邮件等,方便用户进行日常管理,从而简化运维工作,降低运维难度。

1.2.数据镜像集群随着服务器硬件及软件的发展,服务器的性能、内部存储容量以及网络传输能力等都有了大幅度地提升,服务器在应对主流业务方面提供了更加强大的能力。

传统高可用性系统中必须通过共享存储来实现数据的一致性和连续性,这个特性无形中增加了可用性系统的成本。

Rose基于以太网络TCP/IP协议,通过数据实时镜像技术,在两台主机之间实现不需要共享存储的纯软高可用系统。

如此灵活的双机高可用系统配置方式,用户可以在充分利用已有资源的基础上,根据自己的实际硬件环境来选择。

该解决方案采用HA技术对主机的IP、应用程序、数据存取等进行监控和保护。

当应用程序或主机发生故障后,Rose将自动、快速地切换应用到备机,保障应用服务的连续运营。

1.2.1.适用场景基于主机的数据镜像高可用集群,以保障业务系统连续运营。

硬件结构:2台主机1.2.2.案例分析某百货公司是一家香港联交所主板挂牌上市公司,并控股多家A 股上市公司。

经过十余年长足发展,该公司年销售额近100亿元,居中国百货零售业前列,目前在全国华南、西南、华北、华东区域20个城市共拥有40多家门店。

项目背景及需求该百货公司每个门店销售管理系统均由运行在RedHat 5.4平台上前端管理应用服务和Sybase数据库服务构成,其中Sybase数据库服务作为前端销售管理应用服务的核心后台数据库,无疑是系统中最为重要的一个环节。

项目实施前,客户后台Sybase数据库均运行在单机系统上。

项目实施目标:为该公司旗下所有的门市销售管理系统,提供保障业务连续运营不间断的基础环境,实现各个门市销售管理系统持续不间断运营,为提高各个门市销售效率,同时,减小全公司系统管理人力和财力成本。

解决方案作为整个方案的重点,门市销售管理系统的核心后台Sybase数据库,需要能够连续不间断运营来确保整个系统的可用性。

通过慎重方案筛选及客户现有资源等因素综合考虑,Rose公司推荐其采用基于数据镜像的业务连续性产品,将该公司旗下某市城区的八个客流量较大的商场销售管理系统后台Sybase数据库组成镜像热备方案保护业务连续工作。

总体架构描述因各商场硬件平台不同,有些商场硬件配置增加1台服务器作为Sybase数据库备机,有些商场利用前端应用服务器作为Sybase数据库备机,充分运用硬件资源,在软硬件环境准备就绪后,通过Rose 解决方案搭建基于数据镜像的热备集群。

实现过程以某一个门店为例作详细说明。

正常情况下,2台服务器中的1台服务器作为Sybase主机,通过活动IP对外提供服务,主机产生的数据会直接写入主机的本地磁盘,同时通过Rose解决方案,将实时捕获到的变动数据,通过网络实时传输到备机,从而保证两台服务器数据的一致性。

在此基础上,如果主机出现故障(服务器宕机,应用系统故障,网络故障等情况),导致所保护的应用程序无法继续对外提供服务,主机会在保证数据一致性前提下,通过Rose解决方案将Sybase数据库切换到备机运行,继续对外提供服务,确保生产管理系统持续运营工作。

数据复制心跳局域网数据库主机数据库备机系统特点⏹ 业务连续运营实时监测Sybase 数据库运行状态,如出现软、硬件故障,自动将数据库服务切换至备用主机,以保障数据库系统的连续运营。

⏹ 数据实时复制应用在线的数据实时复制,保障主、备机的数据一致性。

并支持计划快照任务,可定期为数据创建快照记录,进一步保障数据安全。

⏹ 多种监控方式实时监测应用服务运行状态,并支持深度监控CPU/内存资源使用率,可进行智能预警和策略切换。

⏹ 架构灵活无需磁盘阵列设备,即可构建热备集群,方案架构灵活。

可充分利用现有软、硬件资源,轻松构建热备集群方案,避免重复投资。

简化运维Rose提供友好的图形化界面,用户可以远程管理热备集群,并监管集群工作状态。

提供多种事件告警方式,比如在线状态、在线日志、短信、邮件等,方便用户进行日常管理,从而简化运维工作,降低运维难度。

2.灾备恢复2.1.远程容灾随着IT行业的发展,用户核心系统重要性逐渐凸显,为了应对核心系统的可靠性,用户纷纷开始构建自己的容灾系统,实现核心系统的远程容灾保护。

Rose针对用户的需求提供远程容灾方案,一旦生产中心发生灾难事故,可以把核心系统快速转移到容灾系统上继续运营,达到RPO≈0、RTO=分钟级的远程容灾级别。

2.1.1.适用场景用户根据系统环境、网络环境,结合容灾需求等情况,构建远程容灾方案。

在不改变用户现有架构的情况下,适用于本地及远程的应用系统和核心数据的容灾备份场景。

2.1.2.案例分析客户为华东地区某市的一个天然气供应商,是该市工业园区城市燃气基础设施投资、建设、管理和运营的主体,每天为10多万户家庭和超过1000家企事业单位提供洁净天然气。

项目背景及需求客户在总部部署有多套业务系统,包括OA、ERP、数据采集SCADA、燃气客户管理系统等,分别部署在多台服务器上,考虑到各种突发事件可能导致的业务中断及数据丢失,客户计划在距离总部10公里地方部署容灾机房,将相关业务系统通过容灾机房服务器保护,达到数据和应用的冗余保护。

项目实施目标为企业相关核心系统实现异地的数据+应用容灾保护,在本地机房出现故障时,能够在容灾机房快速启用相关服务,保持业务系统对外连续、稳定运行。

解决方案推荐采用基于数据容灾的旗舰产品—RoseReplicator,部署企业核心系统的异地数据+应用保护方案。

⏹总体架构描述通过和客户沟通,计划在容灾机房通过一台高性能服务器,采用VMware ESXi虚拟化方式,虚拟出多个虚拟机,分别对应多台生产服务器,通RoseReplicator部署多个1to1的数据+应用保护模式来保护不同的应用程序。

网络层面,客户在两地通过运营商专网实现100M 带宽通信,确保数据传输稳定性。

⏹实现过程以管理系统为例:容灾机房的虚拟机保持和原生产服务器相同操作系统,应用程序和数据库部署方式保持一致,通过RoseReplicator搭建1-1数据保护模式,将管理系统生产服务器的数据实时复制到容灾服务器上,确保两台机器数据一致性。

当主服务器出现故障时,可通过备用服务器快速恢复业务系统;当本地机房完全瘫痪时,可通过容灾机房公网IP将服务映射出去,对外提供服务;当本地服务器恢复后,可通过恢复向导将数据快速恢复至生产服务器,继续通过生产服务器对外提供服务。

⏹解决方案示意图方案效果核心数据的异地容灾备份核心应用系统的容灾切换多种数据删除模式避免误删除灵活的网络带宽限制策略远程集中统一管理方案总结通过虚拟化平台下搭建容灾方案,为客户节省不少硬件投入,满足客户数据异地保护需求。

2.2.云容灾越来越多的用户计划将其业务系统或数据迁移至云。

业务和数据迁移至云端,业务系统的运营和数据将完全托管于云服务商,而如何对云端的业务系统和数据进行有效控制和容灾保护,也是用户将业务迁移至云需考虑的一个重要环节。

结合云平台,常见的容灾模式有如下几种:本地至云将生产中心的数据和业务实时灾备至云端,如生产中心出现事故,可迅速利用云端的容灾系统及时接管业务。

云至本地用户将业务迁移至云端,可将云端的业务数据实时灾备至用户本地机房,可有效控制业务和数据安全。

不同区域的云之间不同区域的云之间,构建数据和业务灾备,最大化保障业务系统和数据的安全。

2.2.1.适用场景本地至云,云至本地,不同区域的云之间,构建云容灾方案2.2.2.案例分析某公司是全球最大的中央处理器散热风扇(CPU Cooler)供应厂商,为深圳高新技术企业。

公司主要生产制造散热片(Heat Sink)、风扇(DC Fan)、导热管(Heat Pipe)等。

在工厂生产流水线作业平台信息化建设过程中,需对核心MES业务系统构建容灾保护,以保障MES系统能够抵御灾难事故。

容灾方案部署前,MES系统数据库已迁移至微软云,并使用云端高可用技术实现业务系统的连续性保护,、、武汉等分公司均通过VPN网络访问云端数据库。

相关文档
最新文档