ha解决方案.docx
《ha解决方案.docx》由会员分享，可在线阅读，更多相关《ha解决方案.docx（7页珍藏版）》请在冰点文库上搜索。
ha解决方案
ha,解决方案
篇一：
HadoopHA方案详细
现有HDFSHA解决方案
HDFS的HA的解决方案，主要是从使用者的角度出发，提高元数据的可靠性，减少NameNode服务恢复时间。
提高元数据的可靠性措施主要是对元数据进行备份，HDFS自身就具有多种机制来确保元数据的可靠性。
减少NameNode服务恢复时间的措施有两种思路：
第1种基于NameNode重启恢复服务的方式，对NameNode自身的启动过程进行分析，优化加载过程，减少启动时间；
第2种则是启动一个NameNode的热备（Warmstandby）节点，当主节点不能正常服务时，由热备节点进行接替，此时主备切换时间成为服务恢复时间。
从效率上分析，第1种思路尽管进行了优化，但NameNode的启动时间仍受文件系统规模的限制，第2种则突破了这种限制。
现有比较成熟的HA解决方案有：
Hadoop的元数据备份方案
Hadoop的SecondaryNameNode方案[3]Hadoop的CheckpointNode方案[4]Hadoop的BackupNode方案[5]DRDB方案[6]
Facebook的Avatarnode方案[7]下面将依次介绍。
adoop的元数据备份方案
该方案利用Hadoop自身的Failover措施（通过配置），NameNode可以将元数据信息保存到多个目录。
通常的做法，选择一个本地目录、一个远程目录（通过NFS进行共享），当NameNode发生故障时，可以启动备用机器的NameNode，加载远程目录中的元数据信息，提供服务。
优点
Hadoop自带机制，成熟可靠，使用简单方便，无需开发，配置即可。
元数据有多个备份，可有效保证元数据的可靠性，并且内容保持最新状态。
元数据需要同步写入多个备份目录，效率低于单个NameNode。
缺点
该方案主要是解决元数据保存的可靠性问题，但没有做到热备，HDFS恢复服务时，需要重新启动NameNode，恢复时间与文件系统规模成正比。
NFS共享的可靠性问题，如果配置的多个目录中有任何一个目录的保存因为异常而阻塞，将会导致整个HDFS的操作阻塞，无法对外提供正常服务。
Hadoop的SecondaryNameNode方案
该方案启动一个SecondaryNameNode节点，该节点定期从NameNode节点上下载元数据信息（元数据镜像fsimage和元数据库操作日志edits），然后将fsimage和edits进行合并，生成新的fsimage（该fsimage就是SecondaryNameNode下载时刻的元数据的Checkpoint），在本地保存，并将其推送到NameNode，同时重置NameNode上的edits。
优点
Hadoop自带机制，成熟可靠，使用简单方便，无需开发，配置即可。
SecondaryaryNameNode定期做Checkpoint，可保证各个Checkpoint阶段的元数据的可靠性，同时，进行fsimage与edits的合并，可以有效限制edits的大小，防止其无限制增长。
缺点
没有做到热备，当NameNode无法提供服务时，需要重启NameNode，服务恢复时间与文件系统规模大小成正比。
SecondaryNameNode保存的只是Checkpoint时刻的元数据，因此，一旦NameNode上的元数据损坏，通过Checkpoint恢复的元数据并不是HDFS此刻的最新数据，存在一致性问题。
Hadoop的CheckpointNode方案
CheckpointNode方案与SecondaryNameNode的原理基本相同，只是实现方式不同。
该方案利用Hadoop的Checkpoint机制进行备份，配置一个CheckpointNode。
该节点会定期从PrimaryNameNode中下载元数据信息（fsimage+edits），将edits与fsimage进行合并，在本地形成最新的Checkpoint，并上传到PrimaryNameNode进行更新。
当NameNode发生故障时，极端情况下（NameNode彻底无法恢复），可以在备用节点上启动一个NameNode，读取Checkpoint信息，提供服务。
优点
使用简单方便、无需开发、配置即可。
元数据有多个备份。
缺点
没有做到热备、备份节点切换时间长。
CheckpointNode所做的备份，只是最后一次Check时的元数据信息，并不是发生故障时最新的元数据信息，有可能造成数据的不一致。
Hadoop的BackupNode方案
利用新版本Hadoop自身的Failover措施，配置一个BackupNode，BackupNode在内存和本地磁盘均保存了HDFS系统最新的名字空间元数据信息。
如果NameNode发生故障，可用使用BackupNode中最新的元数据信息。
优点
简单方便、无需开发、配置即可使用。
BackupNode的内存中对当前最新元数据信息进行了备份（Namespace），避免了通过NFS挂载进行备份所带来的风险。
BackupNode可以直接利用内存中的元数据信息进行Checkpoint，保存到本地，与从NameNode下载元数据进行Checkpoint的方式相比效率更高。
NameNode会将元数据操作的日志记录同步到BackupNode，BackupNode会将收到的日志记录在内存中更新元数据状态，同时更新磁盘上的edits，只有当两者操作成功，整个操作才成功。
这样即便NameNode上的元数据发生损坏，BackupNode的磁盘上也保存了HDFS最新的元数据，从而保证了一致性。
缺点
高版本（以上）才支持。
许多特性还处于开发之中，例如：
当NameNode无法工作时，BackupNode目前还无法直接接替NameNode提供服务，因此当前版本的BackupNode还不具有热备功能，也就是说，当NameNode发生故障，目前还只能通过重启NameNode的方式来恢复服务。
BackupNode的内存中未保存Block的位置信息，仍然需要等待下面的DataNode进行上报，因此，即便在后续的版本中实现了热备，仍然需要一定的切换时间。
当前版本只允许1个BackupNode连接到NameNode。
DRDB方案
利用DRDB机制进行元数据备份。
当NameNode发生故障时，可以启动备用机器的NameNode，读取DRDB备份的元数据信息，提供服务。
优点
DRDB是一种较为成熟的备份机制。
元数据有多个备份、并且保持最新状态。
由于备份的工作交由DRDB完成，对于一条新的日志记录，NameNode无需同步写入多个备份目录，因而NameNode在效率上优于Hadoop的元数据备份方案。
缺点
没有做到热备、备份节点切换时间长。
需要引入新的机制、由此带来一定的可靠性问题。
FaceBook的AvatarNode方案
利用FaceBook提出的AvatarNode机制。
ActiveNode作为PrimaryNameNode对外提供服务。
StandbyNode处于Safemode模式，在内存中保存PrimaryNameNode最新的元数据信息。
ActiveNode和StandbyNode通过NFS共享存储进行交互。
DataNode同时向ActiveNode和StandbyNode发送Blocklocation信息。
当管理员确定PrimaryNameNode发生故障后，将StandbyNode切换为PrimaryNameNode。
由于StandbyNode内存中保存了所有元数据的最新信息，因此可直接对外提供服务，大大缩短了切换时间。
优点
提供热备、切换时间大大缩短。
FaceBook已将其集成到自己维护的Hadoop代码中，并部署到了自己的集群使用。
缺点
修改了部分源码、增加了一定的复杂性，并在软件的维护性上带来一定问题。
参考资料较少。
只提供一个备份节点。
方案优缺点比较
综上所述，HDFSHA方案比较如表所示。
表HDFSHA方案比较
其中"元数据备份方案"不能单独使用，因为在系统运行期间，没有相应的Checkpoint机制，会造成日志的无限制增长，因此需要和SecondaryNameNode、CheckpointNode或BackupNode配合使用。
"DRDB方案"同样如此。
而对于SecondaryNameNode、CheckpointNode机制，它们只有Checkpoint的功能，而不能保存实时的元数据，因此需要在Namenode上配置元数据备份路径来保存实时元数据。
对于BackupNode，虽然它可以实时保存元数据，但为防止BackupNode成为一个单点，也需要在NameNode上配置元数据备份路径，保存在本地进行备份。
总结
篇二：
数据库HA解决方案
HA解决方案
?
项目背景及需求分析
企业的核心业务系统，一旦出现中断，势必极大影响企业的正常运转，造成巨大的损失。
在实际（来自:
小龙文档网:
ha,解决方案）的应用过程中，非法操作、硬件故障、软件错误、人为因素、自然灾害等灾难事故都对这套业务信息系统的持续运行构成潜在威胁。
用户充分考虑到了信息系统业务容灾的必要性，对其企业内部业务系统提出了业务高可用性的需求。
做到有备无患，防范于未然。
用户准备了两台备用服务器，希望实现当生产服务器在运行时产生的数据能够实时的传送到备用服务器上，且在生产服务器遭遇故障，业务信息系统无法继续正常运行时能够自动切换到备用服务器上。
保证对外服务的连续性，达到7X24的高可用级别。
?
解决方案
通过对客户需求的详细分析，经过细致的产品对比、慎重的方案筛选以及客户现有资源等因素的综合考虑，Rose公司推荐其采用基于数据镜像的业务连续性旗舰产品——RoseMirrorHA，为客户应用系统（WEB应用+后台数据库Oracle）提供了具有无单点故障容错能力的系统平台。
1.总体架构描述
在客户应用系统的主备4台服务器上，分别安装RoseMirrorHA。
两两搭建基于数据镜像的双机高可用系统，无需客户更改现有系统的任何环节。
2.具体实现过程
一台服务器作为用户业务系统的前台应用主机，一台服务器作为用户业务系统的后台数据库主机，另两台服务器分别作为应用和数据库的备机。
客户端通过活动IP或主机别名访问应用服务。
RoseMirrorHA高可用性系统，可以对主机的IP、应用程序、数据等进行监控和保护，当应用程序或主机发生故障后，RoseMirrorHA将自动、快速的切换活动IP和应用资源到备机，保证应用系统的持续运营。
当资源在备机启动以后，客户端重连就能访问到应用。
原主机恢复后，接管了应用的备机将把变化后的数据进行同步，保障主备机的应用数据保持完全一致。
客户端
客户端
数据传输线
数据传输线
心跳线心跳线
Oracle主机Oracle备机WEB应用主机WEB
应用备机
图2.实施后拓扑图
客户应用系统在RoseMirrorHA的保护下，实现了业务的连续性运营，同时客户应用系统主机产生的数据通过数据镜像线实时传输到客户应用系统备机进行冗余备份，成熟的数据镜像技术保证主备两台主机的数据一致。
3.实现要求
a）硬件要求
b）网络要求：
应用服务器与数据容灾备份服务器之间需要实现数据通信，搭建基
于TCP/IP的局域网。
建议用户在主机与备机间至少建立2条心跳线（千兆网线
或串口线）。
c）软件要求：
2台服务器使用相同版本的操作系统；并安装部署相同版本的
RoseMirrorHA软件。
2台服务器上的应用安装必须完全一样（路径，数据库实
例名等）。
?
方案效果
通过在客户实施RoseMirrorHA高可用性解决方案，实现了以下功能：
1.业务的持续不间断
正常情况下客户应用系统在主机运行，向客户端提供应用服务，RoseMirrorHA实时将主机数据镜像到备机，并实时监控数据库、应用、网络等的状态。
当主机发生故障时，RoseMirrorHA将快速自动的切换客户应用系统到备机，使用备机镜像数据提供应用服务。
2.数据的冗余保护
RoseMirrorHA监控主机上的应用服务。
驱动一旦捕获到应用变动的数据，便会立即把该数据复制到备机，成熟的数据镜像技术保证主备两台主机的数据一致。
3.避免单点故障
整个系统硬件架构都实现了冗余（主机、存储、网络等），有效避免了软硬件的单点故障。
4.降低管理和维护成本
RoseMirrorHA简洁直观的图形化管理界面（GUI），可以在网络中的任何一个地方管理网络中RoseMirrorHA主机，实现了远程管理。
使得管理维护成为非常简单方便的事情。
RoseMirrorHA简洁易用的配置管理方式，大大的降低了系统的实施管理和维护成本。
5.灵活的Active-Active模式和Active-Standby模式
RoseMirrorHA支持Active-Active模式和Active-Standby模式。
用户可指定每台服务器的作用（activeorstandby），指定要监控的服务和硬件部分，定义指定的服务发生故障后要采取的进一步行动（如是否重新启动该服务、允许的最大启动时间等）。
?
方案总结
首先，通过实施RoseMirrorHA高可用性解决方案实现了对客户应用系统业务连续性的保障，满足了用户对于业务连续及数据冗余备份的需求。
其次，RoseMirrorHA利用成熟的数据镜像技术，保证主备两台主机数据的一致，实现无需共享存储的高可用软件解决方案，大大减少了用户在硬件上的投入。
另外，RoseMirrorHA充分利用用户既有的资源，充分保护用户投资，保护用户既有的
应用和数据。
最大限度的适应已有的软件和硬件环境，无需专门的设备和其它额外成本投入，无形中降低了整个信息系统的总体拥有成本，提高了ROI。
升级会员 