金仓数据库KingbaseES高可用概述（高可用性需求分析与架构确定）
本节将提供一个可以有效评估高可用性需求进而选择合适架构的步骤，步骤包括：
3.1. 调研高可用性需求 ¶
本节将描述如何通过业务影响分析确认计划内、计划外故障造成的停机或数据丢失带来的影响。业务分析并不限于企业，无论是企业、政府还是非盈利组织，任何情况下数据丢失和停机都会严重影响他们对外提供服务的能力。
实现高可用性可能涉及到以下关键任务：
-
报废原有系统
-
投资建设更强大的系统和设施
-
重新设计整体IT架构和运营方式，以适应新的高可用架构
-
修改现有应用，充分利用高可用的基础架构
-
重新设计业务流程
-
招聘和培训人员
-
充分了解现有主机和网络基础设施的能力和限制
业务分析的评估、实现不同的高可用性解决方案所需的成本和收益可以用于实现一个能同时满足业务目标和技术目标的高可用性架构。
3.2. 确定高可用性需求的方法 ¶
分析框架包括以下要素：
-
业务影响分析
-
停机代价分析
-
恢复时间目标（RTO）
-
恢复点目标（RPO）
-
管理能力目标
-
投资成本与回报
3.2.1. 业务影响分析 ¶
根据与IT相关的停机影响的严重程度对业务流程进行分类。
完整的业务影响分析应包括：
-
确定组织中的关键业务
-
评估IT中断造成这些关键业务流程受影响的可能性
-
概述这些中断的影响
-
考虑到必要的业务功能、人员、资源、法规以及内外部业务依赖性
-
向有经验的专家或一线工作者收集客观和主观的评价及数据
-
参考商业历史、财务报表、IT日志等资料
3.2.2. 停机代价 ¶
一个完整的业务影响分析提供了量化计划外和计划内停机时间的成本所需的预测能力。
了解并量化停机代价至关重要，这有助于各业务决策在高可用性投资的优先级，并直接影响选择的高可用技术。 有权威的发布报告记录了不同行业的停机成本。例如，每小时的信用卡销售费用为数百万美元，每小时的快递运输服务费用为数万美元。
3.2.3. 恢复时间目标（RTO） ¶
恢复时间目标是指一个基于信息系统的商业流程失效到它开始为组织造成不可接受的影响（财产损失，客户不满意，信誉受损等等）的时间总和。概括的讲，恢复时间目标是一个组织或者是商业流程对停机时间的容忍度。可更简单的理解为：从系统发生故障到恢复系统之间的时间段。
3.2.4. 恢复点目标（RPO） ¶
恢复点目标是指基于信息系统的商业流程，在不会对组织带来任何损害的情况下所能允许丢失的最大数据量。总的来说，它体现了组织或者业务流程对数据丢失的容忍程度。这样的数据丢失常常用时间来衡量，比如，几小时或几天的数据丢失。
对于一些灾难来说，RPO为零是一个挑战，但我们可以通过各种KingbaseES的高可用技术来实现。
3.2.5. 管理能力目标 ¶
管理能力目标比RPO或RTO更主观。一般是指高可用解决方案管理的复杂程度，而这个复杂程度又是由它们提供的管理工具决定的。和恢复时间目标和恢复点目标决定组织对停机时间和数据丢失的容忍度类似，用户的管理能力目标考量组织对信息系统环境复杂性的容忍度。
如果用户要求操作简单的系统，那么相对于复杂的管理系统，能够达到同样高可用性的简单方法更可取，即使复杂的系统能够提供更好的恢复时间目标和恢复点目标。理解管理能力目标将帮助组织区分什么样的部署是可能的而什么样的部署更实用。
3.2.6. 投资成本与回报 ¶
了解总投资成本(TCO)和投资回报率(ROI)对于选择一个能实现企业业务目标高可用性方案至关重要。
总投资成本包括所选择的高可用解决方案在整个生命周期里产生的所有开销（如采购、实施、系统、网络、设施、员工、培训和支持）。同样，投资回报的计算也包含了在给定的高可用性方案所带来的所有资金收入。
例如，如果远端备用系统和存储未对其它的业务提供支撑而保持闲置状态时，它的唯一产出就是，通过备用系统在故障切换时所减少的停机时间所挽回的损失。相对而言，如果采用备机只读部署方案，备用节点在充当备用角色时，它的系统和存储还能对外提供服务（比如减少主节点的终端查询冲突压力的报表服务）。这时的系统产出除了因避免停机带来的收益外，还应该包括它在担当备用角色的同时提供服务所带来的收入。
3.3. 根据需求选择适合的架构 ¶
业务影响分析描述了企业已有的应用和应用对高可用性的需求。不同的应用和支撑应用的数据库对企业的重要程度不同，对一个即使停机也不会对企业产生直接影响的应用来说，投入高成本建设高可用架构并不值得。我们推荐根据数据库的RTO和RPO需求，从KingbaseES的高可用方案架构中选择能提供最接近需求的可用性的方案架构。注意如果多个应用和支撑数据库有依赖关系，这组数据库的高可用需求应该选择其中要求最高的需求。
3.3.1. KingbaseES最大可用性架构 ¶
KingbaseES最大可用性架构（以下简称MAA，Maximum Availability Architecture）定义了实现不同等级可用性的解决方案架构，这些架构可以满足各种规模的组织使用的各类应用对可用性和数据保护的需求。
MAA定义了三个保护级别：
-
初级保护架构 适用于对高可用需求要求不高，可通过重新启动故障组件（如数据库实例)、从备份恢复解决存储故障等功能满足。大部分维护操作需要停机。
-
中级保护架构 在初级的基础上支持在节点故障时自动切换，最小化停机时间。对于常见的计划内维护操作，如硬件和软件更新可以实施滚动操作。在可用区级别故障发生时仍然需要从备份恢复数据库。
-
高级保护架构 通过跨可用区和地域的实时复制解决灾难恢复的实时性需求，增加逻辑复制特性在线处理更多的维护操作，适用于有高RTO和RPO的关键业务使用，对包括灾难在内各种故障引起的计划外停机、物理复制无法实现的在线维护操作有更多支持。
| 初级 |
中级 |
高级 |
|
|---|---|---|---|
| 备份恢复管理工具（RMAN） |
使用 |
使用 |
使用 |
| 数据损坏检测 |
使用 |
使用 |
使用 |
| 对象在线重定义 |
使用 |
使用 |
使用 |
| 数据导出导入，数据迁移工具 |
使用 |
使用 |
使用 |
| 自动重启 |
使用 |
不使用 |
不使用 |
| 监控工具 |
使用 |
使用 |
使用 |
| 读写分离集群（KingbaseRWC） |
不使用 |
使用 |
使用 |
| Clusterware |
不使用 |
使用 |
使用 |
| 异构数据同步软件（Kingbase FlySync） |
不使用 |
可选 |
使用 |
3.3.2. 各架构的高可用性及数据保护能力 ¶
每个MAA架构都提供经大量实际项目验证的高可用性和数据保护能力。
下表总结了各架构对应的高可用性和数据保护能力。每个架构都包含了上一个架构的所有功能，并在上一个架构的基础上处理更多的停机类型。
| MAA架构 |
计划外故障 |
计划内维护 |
数据保护 |
灾难恢复 |
|---|---|---|---|---|
| 初级 |
单实例，通过自动重启 减少数据库实例故障 造成的停机时间。 通过硬件冗余部署解决 网络、存储等硬件故障。 |
少量在线完成 大部分离线完 成。 |
运行时 验证和人工 检查相结合。 |
从备份恢复， 可能丢失未完成归档 备份的数据。 |
| 中级 |
实例和主机 故障自动切换。 |
大部分在线滚 动完成，少量 离线完成。 |
运行时 验证和人工 检查相结合。 |
从备份恢复， 可能丢失未完成归档 备份的数据。 |
| 高级 |
可用区和地域级 故障切换。 |
全部滚动或在 线完成。 |
运行时 验证和人工 检查相结合。 |
实时切换， 不丢失或少量数据丢失 。 |