高可用HA方案

方案一　文件复制

使用磁盘互相拷贝的方案，但是也是有问题，如果拷贝的过程中一台服务器宕机了，导致有数据只拷贝了一部分。进行主备机切换会不会导致问题。会不会导致数据库数据不同步，如果主机启动会起来会不会导致，备机跟主机的数据不同步？ 下面介绍解决方案

DRBD(Distributed Relicated Block Device 分布式复制块设备)

可以解决磁盘单点故障。一般情况下只支持2个节点。类似于一个网络RAID-1的功能.当你将数据写入本地文件系统时,数据还将会被发送到网络中另一台主机上。DRBD官网有非常详细的指导资料

工作模式：

• 主从模型master/slave（primary/secondary）
• 双主模型 dula primary(primary/primary) 一般这种情况会造成文件系统的错乱，可以使用集群文件系统

复制协议简介：

• A协议：异步复制（asynchronous）如上图 文件写操作执行到A点是就认为写入磁盘成功,也就是数据一旦写入磁盘并发送到网络中就认为完成了写入操作。性能好，数据可靠性差。
• B协议：半同步复制（semi sync）如上图 文件写操作执行到B点是就认为写入磁盘成功，收到接收确认就认为完成了写入操作。性能好，数据可靠性介于A和C之间。
• C协议：同步复制（ sync）如上图 文件写操作执行到C点是就认为写入磁盘成功，收到写入确认就认为完成了写入操作。性能差，数据可靠性高。也是drbd默认使用的复制协议

DRBD 支持的底层设备：
DRBD需要构建在底层设备之上，然后构建出一个块设备出来。对于用户来说，一个DRBD设备，就像是一块物理的磁盘

• 一个磁盘，或者是磁盘的某一个分区。
• 一个soft raid 设备。
• 一个LVM的逻辑卷。
• 一个EVMS（Enterprise Volume Management System，企业卷管理系统）的卷。
• 其他任何的块设备

DRBD镜像数据的特性：

1. 实时性：当某个应用程序完成对数据的修改时，复制功能立即发生
2. 透明性：应用程序的数据存储在镜像块设备上是独立透明的，他们的数据在两个节点上都保存一份，因此，无论哪一台服务器宕机，都不会影响应用程序读取数据的操作，所以说是透明的。
3. 同步镜像和异步镜像：同步镜像表示当应用程序提交本地的写操作后，数据后会同步写到两个节点上去；异步镜像表示当应用程序提交写操作后，只有当本地的节点上完成写操作后，另一个节点才可以完成写操作。

协议详细说明：

1. 协议A：异步复制协议 一旦本地磁盘写入已经完成，数据包已在发送队列中，则写被认为是完成的。在一个节点发生故障时，可能发生数据丢失，因为被写入到远程节点上的数据可能仍在发送队列。尽管，在故障转移节点上的数据是一致的，但没有及时更新。这通常是用于地理上分开的节点。
   数据在本地完成写操作且数据已经发送到TCP/IP协议栈的队列中，则认为写操作完成。如果本地节点的写操作完成，此时本地节点发生故障，而数据还处在TCP/IP队列中，则数据不会发送到对端节点上。因此，两个节点的数据将不会保持一致。这种协议虽然高效，但是并不能保证数据的可靠性。

2. 协议B：内存同步（半同步）复制协议 一旦本地磁盘写入已完成且复制数据包达到了对等节点则认为写在主节点上被认为是完成的。数据丢失可能发生在参加的两个节点同时故障的情况下，因为在传输中的数据可能不会被提交到磁盘
   数据在本地完成写操作且数据已到达对端节点则认为写操作完成。如果两个节点同时发生故障，即使数据到达对端节点，这种方式同样也会导致在对端节点和本地节点的数据不一致现象，也不具有可靠性。

3. 协议C：同步复制协议 只有在本地和远程节点的磁盘已经确认了写操作完成，写才被认为完成。没有任何数据丢失，所以这是一个群集节点的流行模式，但I/O吞吐量依赖于网络带宽。只有当本地节点的磁盘和对端节点的磁盘都完成了写操作，才认为写操作完成。这是集群流行的一种方式，应用也是最多的，这种方式虽然不高效，但是最可靠。

安装配置步骤：

• 安装drbd(DRBD源代码树建立出的Debian包，fakeroot包支持非root用户建立DRBD)
• 配置资源文件（定义资料名称，磁盘，节点信息，同步限制等）
• 将drbd加入到系统服务chkconfig –add drbd
• 初始化资源组drbdadm create-md resource_name
• 启动服务 service drbd start
• 设置primary主机，并同步数据
• 在作为主的节点上面分区、格式化/dev/drbd*
• 一个节点进行挂载

Corosync + PaceMaker

Corosync用来实现多个机器互相通讯维持心跳，pacemaker是在corosync上层来统一管理集群运行（比如web项目）

heartbeat

• 高可用(High Availability)HA集群, 使用Heartbeat实现，也称为”双机热备”, “双机互备”, “双机”；
• 负载均衡群集(Load Balance Cluster)，使用Linux Virtual Server(LVS)实现;

Heartbeat是Linux-HA项目中的一个组件，它实现了一个高可用集群系统。心跳服务和集群通信是高可用集群的两个关键组件，在 Heartbeat项目里，由heartbeat模块实现了这两个功能。供了所有 HA 软件所需要的基本功能，比如心跳检测和资源接管、监测群集中的系统服务、在群集中的节点间转移共享 IP 地址的所有者等

Hearbeat和Keepalived区别

• Keepalived使用的VRRP协议方式，虚拟路由冗余协议 (Virtual Router Redundancy Protocol，简称VRRP);
• Heartbeat是基于主机或网络的服务的高可用方式;
• Keepalived的目的是模拟路由器的双机;
• Heartbeat的目的是用户Service的双机;
• LVS的高可用建议用Keepavlived;
• 业务的高可用用Heartbeat;

Keepalived 的作用是检测服务器的状态，如果有一台web服务器宕机，或工作出现故障，Keepalived将检测到，并将有故障的服务器从系统中剔除，同时使用其他服务器代替该服务器的工作,主要控制IP飘移，配置应用简单，而且分层，layer3，4，5，各自配置极为简单
Heartbeat 不但可以控制IP飘移，更擅长对资源服务的控制，配置，应用比较复杂;

HA集群中的相关术语

节点（node）
运行heartbeat进程的一个独立主机，称为节点，节点是HA的核心组成部分，每个节点上运行着操作系统和heartbeat软件服务，在heartbeat集群中，节点有主次之分，分别称为主节点和备用/备份节点，每个节点拥有唯一的主机名，并且拥有属于自己的一组资源，例如，磁盘、文件系统、网络地址和应用服务等。主节点上一般运行着一个或多个应用服务。而备用节点一般处于监控状态。

资源（resource）
资源是一个节点可以控制的实体，并且当节点发生故障时，这些资源能够被其它节点接管，heartbeat中，可以当做资源的实体有：

• 磁盘分区、文件系统
• IP地址
• 应用程序服务
• NFS文件系统

事件（event）
集群中可能发生的事情，例如节点系统故障、网络连通故障、网卡故障、应用程序故障等。这些事件都会导致节点的资源发生转移，HA的测试也是基于这些事件来进行的。

动作（action）
事件发生时HA的响应方式，动作是由shell脚步控制的，例如当某个节点发生故障后，备份节点将通过事先设定好的执行脚本进行服务关闭或启动, 进而接管故障节点的资源。

HeartBeat 的组成:

Heartbeat提供了高可用集群最基本的功能，例如，节点间的内部通信方式、集群合作管理机制、监控工具和失效切换功能等等，目前的最新版本是Heartbeat2.x，下面讲述也是以Heartbeat2.x为主，主要介绍Heartbeat2.0的内部组成，主要分为以下几大部分：

• heartbeat： 节点间通信检测模块
• ha-logd： 集群事件日志服务
• CCM（Consensus Cluster Membership）：集群成员一致性管理模块
• LRM （Local Resource Manager）：本地资源管理模块
• Stonith Daemon： 使出现问题的节点从集群环境中脱离
• CRM（Cluster resource management）：集群资源管理模块
• Cluster policy engine： 集群策略引擎
• Cluster transition engine：集群转移引擎

HeartBeat 的作用:

通过HeartBeat，可以将资源（IP以及程序服务等资源）从一台已经故障的计算机快速转移到另一台正常运转的机器上继续提供服务，一般称之为高可用的服务。在实际的生产应用场景中，heartbeat的功能和另一个高可用的开源软件keepalived有很多的相同之处，在我们实际的生产业务中也是有区别的。

HeartBeat 的工作原理:

heartbeat最核心的包括两个部分，心跳监测部分和资源接管部分，心跳监测可以通过网络链路和串口进行，而且支持冗 余链路，它们之间相互发送报文来告诉对方自己当前的状态，如果在指定的时间内未收到对方发送的报文，那么就认为对方失效，这时需启动资源接管模块来接管运行在对方主机上的资源或者服务。

heartbeat内部结构有三大部分组成:

• 集群成员一致性管理模块（CCM）用于管理集群节点成员，同时管理成员之间的关系和节点间资源的分配，heartbeat模块负责检测主次节点的运行状态，以决定节点是否失效。ha-logd模块用于记录集群中所有模块和服务的运行信息。
• 本地资源管理器（LRM）负责本地资源的启动，停止和监控，一般由LRM守护进程lrmd和节点监控进程（Stonith Daemon）组成，lrmd守护进程负责节点间的通信，Stonith Daemon通常是一个Fence设备，主要用于监控节点状态，当一个节点出现问题时处于正常状态的节点会通过Fence设备将其重启或关机以释放IP、磁盘等资源，始终保持资源被一个节点拥有，防止资源争用的发生。
• 集群资源管理模块（CRM）用于处理节点和资源之间的依赖关系，同时，管理节点对资源的使用，一般由CRM守护进程crmd、集群策略引擎和集群转移引擎三个部分组成，集群策略引擎（Cluster policy engine）具体实施这些管理和依赖，集群转移引擎（Cluster transition engine）监控CRM模块的状态，当一个节点出现故障时，负责协调另一个节点上的进程进行合理的资源接管。

推荐组合　Keepalive+DRBD

方案二 共享存储

使用Linux学习之使用RHCS套件搭建HA。 就是使用存储柜做磁盘存储共享，只有一台机子挂载磁盘，如果一台机子挂掉了切换到另一台机子挂载磁盘。

RHCS

RHCS即 RedHat Cluster Suite ,中文意思即红帽集群套件。
红帽集群套件（RedHat Cluter Suite, RHCS）是一套综合的软件组件，可以通过在部署时采用不同的配置，以满足你的对高可用性，负载均衡，可扩展性，文件共享和节约成本的需要。

它提供有如下两种不同类型的集群：

1. 高可用性集群：应用/服务故障切换－通过创建n个节点的服务器集群来实现关键应用和服务的故障切换
2. 负载均衡集群：IP 负载均衡－对一群服务器上收到的 IP 网络请求进行负载均衡
3. 存储集群。

是典型的RHCS集群拓扑结构：整个拓扑结构分为三个层面：
最上层是LVS(以及RHEL7文档中建议的Keepalived和HAProxy)负载均衡层，中间一层是Real Server层，就是服务节点部分，最后一层是共享存储层，主要用于给GFS文件系统提供共享存储空间

如果要实现主备只需中间一层使用两台机子，一台主机挂载磁盘，备机不挂载磁盘。或者都挂载磁盘，通过Heartbeat等程序对WEB应用程序进行主备切换

RHCS提供的三个核心功能:

• 高可用集群是RHCS的核心功能。当应用程序出现故障，或者系统硬件、网络出现故障时，应用可以通过RHCS提供的高可用性服务管理组件自动、快速从一个节点切换到另一个节点，节点故障转移功能对客户端来说是透明的，从而保证应用持续、不间断的对外提供服务，这就是RHCS高可用集群实现的功能。
• RHCS通过LVS（Linux Virtual Server）来提供负载均衡集群，而LVS是一个开源的、功能强大的基于IP的负载均衡技术，LVS由负载调度器和服务访问节点组成，通过LVS的负载调度功能，可以将客户端请求平均的分配到各个服务节点，同时，还可以定义多种负载分配策略，当一个请求进来时，集群系统根据调度算法来判断应该将请求分配到哪个服务节点，然后，由分配到的节点响应客户端请求，而这一系列切换动作，对用户来说，都是透明的,保证了服务的不间断、稳定运行。
• RHCS通过GFS文件系统来提供存储集群功能，GFS是Global File System的缩写，它允许多个服务同时去读写一个单一的共享文件系统，存储集群通过将共享数据放到一个共享文件系统中从而消除了在应用程序间同步数据的麻烦，GFS是一个分布式文件系统，它通过锁管理机制，来协调和管理多个服务节点对同一个文件系统的读写操作。就是使用一个共享存储柜存放数据提供多个应用节点同时使用，oracle rac也是使用共享存储的概念。

RHCS集群运行原理及功能介绍

1. 分布式集群管理器（CMAN）
   Cluster Manager，简称CMAN，是一个分布式集群管理工具，它运行在集群的各个节点上，为RHCS提供集群管理任务。
   CMAN用于管理集群成员、消息和通知。它通过监控每个节点的运行状态来了解节点成员之间的关系，当集群中某个节点出现故障，节点成员关系将发生改变，CMAN及时将这种改变通知底层，进而做出相应的调整。

2. 锁管理（DLM）
    Distributed Lock Manager，简称DLM，表示一个分布式锁管理器，它是RHCS的一个底层基础构件，同时也为集群提供了一个公用的锁运行机制，在RHCS集群系统中，DLM运行在集群的每个节点上，GFS通过锁管理器的锁机制来同步访问文件系统元数据。CLVM通过锁管理器来同步更新数据到LVM卷和卷组。
    DLM不需要设定锁管理服务器，它采用对等的锁管理方式，大大的提高了处理性能。同时，DLM避免了当单个节点失败需要整体恢复的性能瓶颈，另外，DLM的请求都是本地的，不需要网络请求，因而请求会立即生效。最后，DLM通过分层机制，可以实现多个锁空间的并行锁模式。

3. 配置文件管理（CCS）
   Cluster Configuration System，简称CCS，主要用于集群配置文件管理和配置文件在节点之间的同步。CCS运行在集群的每个节点上，监控每个集群节点上的单一配置文件/etc/cluster/cluster.conf的状态，当这个文件发生任何变化时，都将此变化更新到集群中的每个节点，时刻保持每个节点的配置文件同步。例如，管理员在节点A上更新了集群配置文件，CCS发现A节点的配置文件发生变化后，马上将此变化传播到其它节点上去。
   rhcs的配置文件是cluster.conf，它是一个xml文件，具体包含集群名称、集群节点信息、集群资源和服务信息、fence设备等。

4. 栅设备（FENCE）
   FENCE设备是RHCS集群中必不可少的一个组成部分，通过FENCE设备可以避免因出现不可预知的情况而造成的“脑裂”现象，FENCE设备的出现，就是为了解决类似这些问题，Fence设备主要就是通过服务器或存储本身的硬件管理接口，或者外部电源管理设备，来对服务器或存储直接发出硬件管理指令，将服务器重启或关机，或者与网络断开连接。
   FENCE的工作原理是：当意外原因导致主机异常或者宕机时，备机会首先调用FENCE设备，然后通过FENCE设备将异常主机重启或者从网络隔离，当FENCE操作成功执行后，返回信息给备机，备机在接到FENCE成功的信息后，开始接管主机的服务和资源。这样通过FENCE设备，将异常节点占据的资源进行了释放，保证了资源和服务始终运行在一个节点上。
   RHCS的FENCE设备可以分为两种：内部FENCE和外部FENCE，常用的内部FENCE有IBM RSAII卡，HP的iLO卡，还有IPMI的设备等，外部fence设备有UPS、SAN SWITCH、NETWORK SWITCH等

5. 高可用服务管理器
   高可用服务管理器主要用来监督、启动和停止集群的应用、服务和资源。它提供了一种对集群服务的管理能力，当一个节点的服务失败时，高可用性集群服务管理进程可以将服务从这个失败节点转移到其它健康节点上来，并且这种服务转移能力是自动、透明的。
   RHCS通过rgmanager来管理集群服务，rgmanager运行在每个集群节点上，在服务器上对应的进程为clurgmgrd。
   在一个RHCS集群中，高可用服务管理器包含集群服务和集群资源两个方面，集群服务其实就是应用服务，例如apache、mysql等，集群资源有很多种，例如一个IP地址、一个运行脚本、ext3/GFS文件系统等。
   在RHCS集群中，高可用服务管理器是和一个失败转移域结合在一起的，所谓失败转移域是一个运行特定服务的集群节点的集合。在失败转移域中，可以给每个节点设置相应的优先级，通过优先级的高低来决定节点失败时服务转移的先后顺序，如果没有给节点指定优先级，那么集群高可用服务将在任意节点间转移。因此，通过创建失败转移域不但可以设定服务在节点间转移的顺序，而且可以限制某个服务仅在失败转移域指定的节点内进行切换。

6. 集群配置管理工具
   RHCS提供了多种集群配置和管理工具，常用的有基于GUI的system-config-cluster、Conga等，也提供了基于命令行的管理工具。
   system-config-cluster是一个用于创建集群和配置集群节点的图形化管理工具，它有集群节点配置和集群管理两个部分组成，分别用于创建集群节点配置文件和维护节点运行状态。一般用在RHCS早期的版本中。
   Conga是一种新的基于网络的集群配置工具，与system-config-cluster不同的是，Conga是通过web方式来配置和管理集群节点的。Conga有两部分组成，分别是luci和ricci，luci安装在一台独立的计算机上，用于配置和管理集群，ricci安装在每个集群节点上，Luci通过ricci和集群中的每个节点进行通信。
   RHCS也提供了一些功能强大的集群命令行管理工具，常用的有clustat、cman_tool、ccs_tool、fence_tool、clusvcadm等。

7. Redhat GFS
   GFS是RHCS为集群系统提供的一个存储解决方案，它允许集群多个节点在块级别上共享存储，每个节点通过共享一个存储空间，保证了访问数据的一致性，更切实的说，GFS是RHCS提供的一个集群文件系统，多个节点同时挂载一个文件系统分区，而文件系统数据不受破坏，这是单一的文件系统，例如EXT3、EXT2所不能做到的。
   为了实现多个节点对于一个文件系统同时读写操作，GFS使用锁管理器来管理I/O操作，当一个写进程操作一个文件时，这个文件就被锁定，此时不允许其它进程进行读写操作，直到这个写进程正常完成才释放锁，只有当锁被释放后，其它读写进程才能对这个文件进行操作，另外，当一个节点在GFS文件系统上修改数据后，这种修改操作会通过RHCS底层通信机制立即在其它节点上可见。
   在搭建RHCS集群时，GFS一般作为共享存储，运行在每个节点上，并且可以通过RHCS管理工具对GFS进行配置和管理。这些需要说明的是RHCS和GFS之间的关系，一般初学者很容易混淆这个概念：运行RHCS，GFS不是必须的，只有在需要共享存储时，才需要GFS支持，而搭建GFS集群文件系统，必须要有RHCS的底层支持，所以安装GFS文件系统的节点，必须安装RHCS组件。

8. Cluster Logical Volume Manager
   Cluster逻辑卷管理，即CLVM，是LVM的扩展，这种扩展允许cluster中的机器使用LVM来管理共享存储。

9. iSCSI
   iSCSI是一种在Internet协议上,特别是以太网上进行数据块传输的标准,它是一种基于IP Storage理论的新型存储技术，RHCS可以通过ISCSI技术来导出和分配共享存储的使用

10. Global Network Block Device
    全局网络模块，简称GNBD，是GFS的一个补充组件，用于RHCS分配和管理共享存储，GNBD分为客户端和服务端，在服务端GNBD允许导出多个块设备或者GNBD文件，而GNBD客户端通过导入这些导出的块设备或者文件，就可以把它们当作本地块设备使用。由于现在GNBD已经停止了开发，所以使用GNBD的越来越少

Ldirectord

ldirectord(Linux Director Daemon)是Jacob Rief编写的一个独立程序，以实现对LVS中的realserver管理和监测，由于LVS本身不能实现realserver的故障转移，因此需要ldirectord来帮助实现

keepalived

• Keepalived(一般需要root安装运行，可能虚拟ip映射需要权限,也有非root安装的一些资料比较少)的作用是检测web服务器的状态，如果有一台web服务器死机，或工作出现故障，Keepalived将检测到，并将有故障的web服务器从系统中剔除，当web服务器工作正常后Keepalived自动将web服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的web服务器。比如检测server服务的URL是否可以访问
• 生成VIP，进行主备机VIP切换

配置例子：

global_defs {#全局配置
   notification_email {#邮件通知地址 ，这里是本机收件地址
    root@localhost
 }
   notification_email_from keepalived@localhost   #发件地址
   smtp_server 127.0.0.1 #邮件服务地址，端口是25
   smtp_connect_timeout 30  #连接邮件服务器超时时间30秒
   router_id LVS_MASTER #可以使用主机名
   vrrp_mcast_group4 224.1.101.33 #设置多播地址，其他主机也一样
}

vrrp_instance VI_1 { #定义一个虚拟路由器，第一个
    state BACKUP  #当前状态，从的
    interface ens33  #当前的vrp应用，绑定到那个网卡设备上
    virtual_router_id 33#这个虚拟ip，与其他主机要保持一至
    priority 96 #优先级，低于master主机
    advert_int 1
    authentication {
        auth_type PASS  #密码认证
        auth_pass 123454   #密码为8位,不能用默认的密码
    }
    virtual_ipaddress {#虚拟ip地址
        192.168.1.99/24 dev ens33
    }
}
virtual_server 192.168.1.99 80 {
    delay_loop 1
    lb_algo wrr
    lb_kind DR
    protocol TCP
    sorry_server 127.0.0.1 80#故障页所在地址，本机要启动http
    real_server 192.168.1.11 80 {
          weight 1 #权重
          HTTP_GET {
               url {
                  path /index.html
                  status_code 200
               }
               nb_get_retry 3
               delay_before_retry 2
               connect_timeout 3
      }
    }

    real_server 192.168.1.12 80 {
          weight 1 #权重
          HTTP_GET {
               url {
                  path /index.html
                  status_code 200
               }
               nb_get_retry 3
               delay_before_retry 2
               connect_timeout 3
      }
    }
}

DR模式是在局域网内最简单的映射模式，原理可参见《LVS手册》。但只在keepalived主机上配置lb_kind DR是无法访问到real_server的，DR模式会将目标地址为虚拟IP地址原封不动的传给real_server。real_server发现这不是我的IP，因此会丢弃掉该包，所以这边得欺骗一下real_server，让他认为这是他的地址。做法很简单，在real_server的lo回环口上添加那个虚拟IP，这样real_server就会认为自己就是VIP这台服务器。切记在lo上设置，不要在真实网卡上设置。

ifconfig lo:0 192.168.1.99 netmask 255.255.255.0 up

LVS

DR(Direct Routing)模式

• 修改目标MAC地址
• 需要同一网段
• 目标主机lo口需要VIP接收数据包
• RealServer数据包可以直接返回客户端
• ARP (Address Resolution Protocol)，根据IP地址获取物理地址的一个TCP/IP协议

NAT 模式

• 修改目标IP地址
• 不需要修改MAC
• 可以不同网段
• 数据包进出都需要经过LVS,LVS会成为系统瓶颈

IP TUNNEL 模式

• VIP 收到数据包后，会根据LVS设置的LB算法选择一个合适的RealServer；并把客户端发送的包包装到一个新的IP包里面；新的IP包的目标是RealServer的IP
• RealServer判断目标IP是不是自己,解析出来的目标IP是VIP。所以也要lo口加上VIP
• 必须所有RealServer都绑定VIP
• LVS RealServer可以在不同网段
• RealServer直接返回消息包给客户端不经过LVS
• 隧道模式

实验配置

实验环境一

操作系统:RedHat 6.5
node1 192.168.33.200 luci管理端
node2 192.168.33.101 集群节点
node3 192.168.33.102 集群节点
虚拟IP 192.168.33.150

方案三 集群方案

使用集群方案

(lvs+keepalived) + tomcat集群 + MySQL Cluster
(lvs+keepalived) + tomcat集群 + Oracle Rac(共享存储) + Oracle Dataguard(HA)

方案四 分布式集群方案

分布式集群方案

代码：使用spring cloud　实现分布式
数据库：使用mongodb clickhouse hbase等支持分布式集群的数据库
谷歌的: GFS

Oracle的高可用

使用dataguard做异地容灾，使用RAC做多实例提供高并发服务

使用Heartbeat做主备切换+dataguard做数据的主备切换+自己程序实现文件的主备机复制

Redhat6.5+DRBD+heartbeat+oracle11g

PaceMaker+corosync+drbd 实现oracle双机

tomcat 也是类似的把工程，跟需要同步文件的目录放在挂载的同步磁盘中。DRBD官方推荐使用pacemaker集群组件

Redhat6.9+DRBD+Keepalive+Oracle11g+FTP (验证通过)

1. 建立一个数据库存储分区给DRBD使用
2. 把数据库文件(oradata、fast_recovery_area、控制文件、其他相关配置等)存储路径指定到在DRBD共享磁盘中（可行）,还想使用软链接连接路径不过出现了问题（失败）
3. FTP目录文件也想做同步，使用软链接连接路径出现FTP无法识别问题（失败），改用mount挂载成功
4. 断网脑裂问题解决，可以使用双网线，一个数据直连保持不断网
5. DRBD关闭自启动，交给keepalive管理

其他集群软件

RoseHA

其他

主备切换除了使用虚拟IP，通过程序自动切换。还有其他手动的方法比如：

1. 直接修改主备机网卡IP、调换主备机的IP地址（这种模式实现自动切换难度大、需要修改网卡IP地址、可能改完就失联了，切换后导致IP冲突，程序得知道主备机需要配置成什么IP能用，如果不是云主机还得跑机房处理。对于云平台可能对虚拟机网卡分配MAC绑定了固定IP，避免用户直接修改IP地址导致其他虚拟服务受到影响，直接修改虚拟机内网卡IP还是不够，需要修改云平台分配的IP。还可能某些网络设备有几十分钟的老化机制才能识别到新的MAC与IP对应关系。）
2. 修改外部网络映射，原先映射到主机的IP映射到备机（这种模式自动化的话需要修改路由配置，不通用 各式各样的路由设备）

参考

• DRBD原理知识
• DRBD+MariaDB+Corosync+Pacekmaer HA安装配置详解
• DRBD中文应用指南
• DRBD详细解说及配置过程记录
• RHCS 实现高可用 HA（一）
• RHCS(概念篇)
• Linux High Availabi RHCS
• 实战体验几种MySQLCluster方案(转)\
• NFS或iSCSI哪个更好
• iSCSI（一） iSCSI详解 及 iSCSI配置
• 高可用集群
• LVS负载均衡-基础知识梳理
• 基于keepalived高可用代理轮询后端服务器组
• Centos 6.8 上DRBD安装和使用教程
• DRBD脑裂解决
• keepalived ubuntu non-root user
• NFS存储服务