选择系统HA、还是数据库HA，还是选择应用HA
专家您好:
一直没搞懂HA中分了很多种类型，但是有些场景，只用了RAC，没有系统HA，而有些场景是用了全部物理机而做系统HA，而银联那种单位选择了应用写两份了冗余，而底层并没有采用存储复制那种HA，还有HACMP或者MC-SG+RAC的模式，请问这些分别应用于哪些场景才能使应用最优和冗余?该如何选择。
一直没搞懂HA中分了很多种类型，但是有些场景，只用了RAC，没有系统HA，而有些场景是用了全部物理机而做系统HA，而银联那种单位选择了应用写两份了冗余，而底层并没有采用存储复制那种HA，还有HACMP或者MC-SG+RAC的模式，请问这些分别应用于哪些场景才能使应用最优和冗余?该如何选择。
10同行回答
后台应用采用ＨＡ，根据不同的硬件，采用对应的软件： AIX 就是HACMP目前叫PowerHA, HP-UX 就是MC/SG, Linux 就是 VCS，或者是newstartHA,或者是skybility,如果用Redhat的话，也可以用RHCS， 如果是Solaris ,可以用SUN CLuster，也可以用VCS。
前台应用：用硬件负载均衡进行分发；小访问量的可以用ngnix 或者是apache, 小部分的前台也可以用ＨＡ。
数据库，如果是oracle 11g，最好是用RAC(双node)，或者是dataguard,目前有for one Node 的RAC ,这个实际情况还不是太清楚，见过的案例比较少，都是数据库很小的场景才考虑这个。11g最好别用ＨＡ，文件系统暴露在外面，实在是很危险。有些不靠谱的DBA，或者系统管理员，很容易对数据文件误操作。收起
前台应用：用硬件负载均衡进行分发；小访问量的可以用ngnix 或者是apache, 小部分的前台也可以用ＨＡ。
数据库，如果是oracle 11g，最好是用RAC(双node)，或者是dataguard,目前有for one Node 的RAC ,这个实际情况还不是太清楚，见过的案例比较少，都是数据库很小的场景才考虑这个。11g最好别用ＨＡ，文件系统暴露在外面，实在是很危险。有些不靠谱的DBA，或者系统管理员，很容易对数据文件误操作。收起
高可用HA实现的方法手段各不相同，但目标是一致的，就是使应用高可用。随着应用的特点和需求不同，适用的手段也有区别。有时多种层级的HA方法可以配合使用。而有时多种解决方案都可以达到需要的效果，此时就要比较各种方案的成本（包括运维成本）、效果、优势和局限性等方面。任何解决方案都有局限性，而方案的提出者往往不会强调局限性，甚至有时会隐瞒，所以需要用户对其有自己的分析（必要时可以咨询第三方）。这样才能选择到更适合的解决方案。
简单说下您提到的具体HA技术：（都是很好的solution，优点很容易找，篇幅有限，恕我主要说局限性，希望不会误导大家）
1）RAC可以多节点oracle DB并发，优点是DB层无需切换启动时间。但是1+1<2，由于各节点需要cache fusion所以一般性能优化到1+1>1.3都很困难（需要针对应用来优化）。与主备的solution相比，如果有两套应用系统，或DB与APP分区互备，往往可以比RAC更高效。
2）系统级别的HA，可以对不同类型的应用（不仅DB）进行高可用部署。但是对应用提供的只是接口和个别常用应用的监测接口（如PowerHA的smart assist)。所以需要对应用编制启停脚本、定制监测机制等工作才能真正与应用融合，达到保护应用的效果。
3）应用层通过网络冗余复制（同步或异步），好处是无需硬件层的HA机制，而且一般同时是远程灾备的solution。但是需要高效的软件才能充分利用网络有限的带宽，同时避免网络延时对应用造成的影响。如果距离较远，IP网络的复制效率往往不如FC SAN网络，而顶级存储（如DS8000）的复制效率也不是一般软件可以达到的。即使距离不远，IP网络也比SAN网络更容易受到干扰，所以软件必须能解决这些问题，才能在企业级应用上采用。
4）HA+RAC的模式现在用得越来越少了，因为RAC的ASM已经承担起存储并发的任务了（原来由HA提供的concurrent VG支持）收起
简单说下您提到的具体HA技术：（都是很好的solution，优点很容易找，篇幅有限，恕我主要说局限性，希望不会误导大家）
1）RAC可以多节点oracle DB并发，优点是DB层无需切换启动时间。但是1+1<2，由于各节点需要cache fusion所以一般性能优化到1+1>1.3都很困难（需要针对应用来优化）。与主备的solution相比，如果有两套应用系统，或DB与APP分区互备，往往可以比RAC更高效。
2）系统级别的HA，可以对不同类型的应用（不仅DB）进行高可用部署。但是对应用提供的只是接口和个别常用应用的监测接口（如PowerHA的smart assist)。所以需要对应用编制启停脚本、定制监测机制等工作才能真正与应用融合，达到保护应用的效果。
3）应用层通过网络冗余复制（同步或异步），好处是无需硬件层的HA机制，而且一般同时是远程灾备的solution。但是需要高效的软件才能充分利用网络有限的带宽，同时避免网络延时对应用造成的影响。如果距离较远，IP网络的复制效率往往不如FC SAN网络，而顶级存储（如DS8000）的复制效率也不是一般软件可以达到的。即使距离不远，IP网络也比SAN网络更容易受到干扰，所以软件必须能解决这些问题，才能在企业级应用上采用。
4）HA+RAC的模式现在用得越来越少了，因为RAC的ASM已经承担起存储并发的任务了（原来由HA提供的concurrent VG支持）收起
后台应用采用ＨＡ，根据不同的硬件，采用对应的软件： AIX 就是HACMP目前叫PowerHA, HP-UX 就是MC/SG, Linux 就是 VCS，或者是newstartHA,或者是skybility,如果用Redhat的话，也可以用RHCS， 如果是Solaris ,可以用SUN CLuster，也可以用VCS。
前台应用：用硬件负载均衡进行分发；小访问量的可以用ngnix 或者是apache, 小部分的前台也可以用ＨＡ。
数据库，如果是oracle 11g，最好是用RAC(双node)，或者是dataguard,目前有for one Node 的RAC ,这个实际情况还不是太清楚，见过的案例比较少，都是数据库很小的场景才考虑这个。11g最好别用ＨＡ，文件系统暴露在外面，实在是很危险。有些不靠谱的DBA，或者系统管理员，很容易对数据文件误操作。收起
前台应用：用硬件负载均衡进行分发；小访问量的可以用ngnix 或者是apache, 小部分的前台也可以用ＨＡ。
数据库，如果是oracle 11g，最好是用RAC(双node)，或者是dataguard,目前有for one Node 的RAC ,这个实际情况还不是太清楚，见过的案例比较少，都是数据库很小的场景才考虑这个。11g最好别用ＨＡ，文件系统暴露在外面，实在是很危险。有些不靠谱的DBA，或者系统管理员，很容易对数据文件误操作。收起
系统ha，数据库ha，应用ha这个应该根据不同的场景选择吧，如果是大的数据中心，可能都要做，这就涉及到灾备的概念了，这个问题比较复杂，涉及面也很多，不好回答，2楼回答的可以参考下收起
浏览4770