引言：本篇假设我们要在云上新增一个应用，讨论其在单体、failover、DR、集群模式下的成本规划。
假设该应用base on Linux，硬件要求是8cores、64G mem的云主机，并搭配500g内存，至少部署在一台云主机上。我们有开发、测试、生产三套环境都需要部署。应用的license费用为$cost_l，我们选用红帽企业版，其license费用为$cost_r，一台满足硬件要求的云主机跑满24小时的月度费用为$cost_e, RPO为$time_r，RTO可以根据架构模型或者实际恢复时间得出（笔者尽量假设贴近于真实的企业环境与硬件要求，如果读者更复杂的环境和要求，可以留言，我们讨论下怎么调整模型）。
一、单点部署+failover机制
相较于单点部署，failover机制是利用快照来及时恢复应用。架构图类似如下：
请求从route53进来，先到gateway做负载均衡，再通过dns解析访问到单点应用single node。当发生故障不可用时，通过快照在另个AZ创建DR node，再修改DNS，让请求转发到DR node上来。整个过程可用脚本执行，笔者自己实测需要15-20min左右，但不包含应用本身启动时间。
用快照恢复的优点是不需要花费额外的云主机，也不用花费redhat的license，但应用的license保险起见还是需要备一个，以防云主机关机后无法取出应用的license，当然有的应用支持一个license放到多台ec2上，那么可以忽略这个问题。快照恢复的缺点是通过AMI创建的快照恢复出实例来到应用能对外提供访问的时间较长，且如果对RPO要求较高，则定期打快照的频率就会较高。假设RPO要求时2 hours，RTO为30min-60min左右（snapshot恢复时间再加上应用启动时间），那么打快照的频率就必须在1 ~1.5 hour之间。
那么它的总费用为：$cost_e * 3(开发、测试、生产三套环境) + 500g EBS * 3 + 500g snapshot * 3 + $cost_l * 3 + $cost_r *3, 云厂商会提供价格计算器来估算价格，因不同云厂商对云主机定价不一样，且不同机型、不同区域，价格都不一样，在这就不举例了。
| DR solution | Cost(USD) | RTO | Snapshot schedule | HA |
| Single node with snapshot | $cost_e *3 + $cost_l *3 + $cost_r *3; | 30~60 min | RPO - RTO | Null |
二、单点部署+DR node standby
第二种方式是提前建好一个standby，日常定期做数据同步，主节点故障时切换过去。架构图如下：
请求从route53进来，前端在gateway做负载，然后转发到单点应用。DR node通过snapshot创建好，并定期同步数据，当故障发生时通过修改route53 的A记录切换。切换时间在分钟级。但注意，后续如果对稳定性的预期没有那么高，愿意牺牲一点恢复时间换取成本，可以在日常对standby保持关机状态，数据同步通过snapshot做，开机时挂载新的卷就行。这样成本可以节省近一半，恢复时间取决于应用启动时间，但也快过第一个方案。
这样的架构优点是恢复时间短，缺点是要多花费一台云主机的费用。它的费用预估如下：
| DR solution | Cost(USD) | RTO | Snapshot schedule | HA |
| Single node with DR node standby | $cost_e *6 + $cost_l *6 + $cost_r *6; | 分钟级 | RPO | Null |
三、双节点集群模式
双节点集群模式由两个节点组成，同时对外提供服务，具备负责均衡能力。备节点和主节点共用一个数据库，具备1/2的高可用能力：当备节点挂了还能继续提供服务，但是主节点挂了就不行，只能通过重建主节点恢复，重建方式也是有多种，可以通过快照恢复，也可以通过创建一个standby节点候命，建议考虑通过快照恢复，这样能节省成本，因为本身它就提供了一部分高可用，且如果起多一台云主机做standby，还不如用三节点集群模式呢。架构如下：
这种架构下，cost是两个node的费用，RTO跟第一个架构一样，快照频率也要求高一些，优点是提供了部分高可用。费用预估如下：
| DR solution | Cost(USD) | RTO | Snapshot schedule | HA |
| 2-node cluster | $cost_e * 6 + $cost_l *6 + $cost_r *6; | 30~60 min | RPO - RTO | medium |
四。三节点集群模式
三节点集群模式中，由1个master和2个slave节点组成。数据库有主备，当主节点挂了后，数据库可自动切换到备节点，所以主节点挂了之后依旧可用。架构如下：
该架构优势在于提供了很好的高可用行，node部署在三个AZ上，整个集群挂掉的概率几乎不可能（除非云厂商的整个region都挂了），RPO/RTO可不用考虑。缺点是费用最高。
| DR solution | Cost(USD) | RTO | Snapshot schedule | HA |
| 3-node cluster | $cost_e * 9 + $cost_l *9 + $cost_r *9; | NA | NA | high |
五、成本优化
对于架构一，在开发和测试环境可以采取非工作时间定时关机的策略，理想情况下，可节省约云主机2/3的费用。
对于架构二，开发和测试环境可以采取非工作时间定时关机的策略，且standy节点可以保持关机，但生产环境的话standy节点依然保持开机状态，这样不会影响恢复时间。
对于架构三，开发环境可以采用单节点，因为只需要提供功能开发就行；测试环境和生产保持一致。同样也采用定时关机策略。
对于架构四，同样开发环境采用单节点，满足功能开发就行，测试环境和生产保持一致。
| DR solution | Cost optimize | Cost(USD) | RTO | Snapshot schedule | HA |
| Single node with snapshot | auto shutdown; | $cost_e * 5/3 $cost_l *3 + $cost_r *3; | 30~60 min | RPO - RTO | Null |
| Single node with DR node standby | auto shutdown; standby shutdown | $cost_e * 8/3 + $cost_l *6 + $cost_r *6; | 分钟级 | RPO | Null |
| 2-node cluster | auto shutdown; single node in dev | $cost_e * 3 + $cost_l *6 + $cost_r *6; | 30~60 min | RPO - RTO | medium |
| 3-node cluster | auto shutdown; single node in dev | $cost_e * 13/3 + $cost_l *9 + $cost_r *9; | NA | NA | high |
我们在规划应用时需要考虑优先级，稳定性、成本、或者RTO/RPO硬指标等。架构四的费用大幅高于其他三个，但提供的高可用性也是最好的；架构二明显具备更高性价比，恢复时间、快照频率都比较好，且费用比架构三还便宜。综上，大家可参加本篇的思路去做架构规划。
