近日见闻
1、 据 Windows Centra 报道,微软计划在本月晚些时候发布新款 Surface Pro 和 Surface Laptop 硬件产品,而这些产品将会作为微软首款人工智能 PC 推出。--oschina
2、KubeSphere 开发者训练营免费报名开始啦,地址https://jinshuju.net/f/eNfc8x
,报名时间:即日起至 2024 年 3 月 23 日. --kubesphere社区
3、今天偶然看到飞致云旗下的运维管理面板,项目地址https://github.com/1Panel-dev/1Panel?tab=readme-ov-file
,后期可以借鉴学习并贡献。--飞致云社区
- 摘抄:
我闷闷不乐因为我缺少一双鞋,
直到在街上我看到别人没了一双脚。
——卡耐基
最近在准备面试的过程中被问到一个高频的问题,那就是关于如何做好系统的容灾。今天就来分享一下自己的一点见解。
概念
首先了解下相关概念,这里的容灾更多的是IT系统的容灾。容灾,全称“灾难恢复”(Disaster Recovery, DR),是一系列策略和程序,用于在技术系统发生灾障(如自然灾害、人为破坏、系统故障等)时,保护和恢复信息技术系统的数据和功能,确保业务连续性。容灾的目标是最小化灾难事件对业务运营的影响,快速恢复正常服务。容灾概念[1]
在我看来,作为一线工程师,保证客户正常使用是最重要的,所以容灾的建设才是最考验我们综合能力的重要环节(包括机制建立、系统建设、故障演练、恢复等等),所以容灾,简单理解就好比一台打印机打东西,打到一半坏了,怎么快速换到另一台正常打印机接着打印呢?应该有很多种方式,值得我们深入思考。
参考步骤
建立起一套有效的容灾体系,从而在面对灾难时,最大限度地保护系统的数据资产,减少业务中断的时间,确保业务的连续性和稳定性。怎么做呢?大概有哪些步骤呢?
1. 进行风险评估和业务影响分析(BIA)
- 风险评估:识别可能面临的各种风险(如自然灾害、网络攻击、系统故障等),并评估这些风险发生的可能性及其潜在影响。这一部分,应该结合业务场景、综合评估经常遇到的一些风险,一项一项的列清单,并附上对应的风险,比如机房网断了怎么办、宕机了怎么办,还会有哪些情况(
想起来去年有个新闻、某大公司机房过热导致机器大规模宕机,业务中断好多小时的事情
) - 业务影响分析:确定哪些系统和应用是最关键的,它们的中断会对业务产生什么样的影响。这将帮助你确定恢复的优先级和目标。这里就是要做一个系统以及应用的优先级排序,比如一些应用就是某一个系统的底座,没有就是玩不转,这类的系统或者应用就是优先恢复、并分析出来对应故障带来的风险和影响范围。
2. 定义恢复目标
一旦系统故障、恢复的时间以及恢复的质量就是衡量容灾质量的标准,比如:
- 恢复时间目标(RTO):你期望或需要在多长时间内恢复业务或系统服务。肯定是越短越好,但是少一秒的恢复就要做出更多时间的努力。
- 恢复点目标(RPO):你可以接受的数据丢失量,通常按时间来衡量。因为系统正常运行必定产生数据、数据的安全也是至关重要,光恢复了不行,数据怎么保证不丢失?这个需要哪些手段?
3. 设计容灾架构
可以硬件、软件、应用、数据等多方面考虑
- 数据备份:定期备份关键数据,并确保备份在物理位置上的分离,以避免单点故障。还有比如数据库的全量增量备份、多节点分布式存储等等。
- 系统冗余:为关键系统设置热备(Hot Site)、温备(Warm Site)或冷备(Cold Site)方案,以根据RTO和RPO的要求快速切换。
- 多地部署:如果可能,可以考虑跨地域的备份和冗余,以防单一地理位置的灾难。这种就不是小规模了,一般都是大规模的集群了,服务对象范围及数量很大的时候就需要做这块了。
这块多聊聊:因为被问的最多,容灾如何设计并实现等等
容灾架构它涉及到数据备份、系统复制、故障转移和业务恢复等多个方面。根据业务需求的不同,容灾架构可以有多种实现方式,下面是一些常见的容灾架构方式:
1. 同城多活(Active/Active in Metro Area)
- 定义:同城多活指的是在同一城市或地理位置相近的两个或多个数据中心同时运行相同的业务应用,所有数据中心都处于活跃状态,能够处理业务请求。
- 特点:提供高可用性和负载均衡,可以在一个数据中心发生故障时,无缝地将流量切换到其他数据中心,实现业务的连续性。但因为是同城部署,对于自然灾害等范围较广的灾难风险覆盖有限。
2. 异地多活(Active/Active across Regions)
- 定义:异地多活是指在不同地理位置区域的数据中心中部署相同的业务应用,所有数据中心都处于活跃状态,可以同时处理业务请求。
- 特点:提供更高级别的容灾保障,可以抵御包括自然灾害在内的多种灾难。由于数据中心分布在不同的地理位置,实现了地理级别的冗余。不过,网络延迟和数据同步成为需要特别考虑的问题。
3. 热备(Active/Passive)
- 定义:热备是指有一个主要的活跃数据中心处理所有业务请求,同时有一个或多个备用数据中心处于待命状态,主数据中心出现故障时,可以迅速切换到备用数据中心。
- 特点:实现了业务的高可用性,恢复时间相对较短。但在没有发生故障时,备份数据中心的资源利用率较低。
4. 冷备(Cold Standby)
- 定义:冷备是指有一个主要的活跃数据中心处理所有业务请求,同时有备份的设施和数据,但备份的系统不运行业务应用,仅在主系统出现故障时才启动备份系统。
- 特点:成本相对较低,但恢复时间较长,因为需要启动备份系统并加载数据。
5. 异地容灾(Disaster Recovery Site)
- 定义:构建在远离主数据中心的地理位置上的备份数据中心,仅在主数据中心无法恢复时启用。
- 特点:能抵御包括自然灾害在内的大多数灾难,但在切换到备份数据中心时,业务中断时间和数据丢失风险相对更高。
每种容灾架构都有其优点和限制,选择哪种架构取决于业务的恢复时间目标(RTO)、恢复点目标(RPO)、成本预算以及对业务中断的容忍度等因素。在设计容灾架构时,不仅要考虑技术实现,还要综合考虑业务需求、法律法规要求和成本效益等因素,以制定出最合适的容灾策略。
面向客户使用的架构,没有故障才是正常。但机器也有坏的时候,所以站在客户角度,零故障的容灾才是作为工程师不断追求的极致目标。
4. 实施容灾解决方案
- 技术实现:根据设计的容灾架构,采用适合的技术和工具实施方案。架构这块咱还没有太多经验,只能是参考人家的方案学习学习。
- 自动化:尽可能实现自动化备份和故障切换,减少人为干预,提高恢复速度和准确性。恢复过程越自动化恢复时间越短毕竟人工操作远远慢于机器,除非拉电闸。
5. 测试和优化
- 定期测试:定期进行容灾演练,模拟不同类型的灾难情况,测试恢复过程和时间,确保计划的有效性。
- 性能评估:基于测试结果评估恢复目标(RTO和RPO)是否得到满足,识别并解决存在的问题或瓶颈。
- 计划更新:根据业务发展和技术变化,定期更新容灾计划和技术方案。
6. 培训和文档
- 员工培训:确保团队成员熟悉容灾计划和操作流程,提高他们对于异常情况的应对能力。
- 文档化:详细记录容灾计划、操作步骤、联系信息等,确保在紧急情况下可以快速参考。
工具使用
那容灾过程中可以用到哪些工具帮助快读恢复呢?一起来看看。
容灾实施工具与技术
- 数据备份工具:
- 云备份服务:这边各大厂商都有提供对应的备份服务,按时按量计费,提供高可用性和地理冗余特性。
- 备份软件:如Veeam, Acronis, Veritas NetBackup等,支持定期备份和恢复。
- 复制和数据同步:
- 实时复制工具:如Zerto, VMware Site Recovery Manager (SRM),提供近实时的数据复制和自动化的恢复流程。
- 数据库复制:如MySQL Replication, PostgreSQL Streaming Replication,确保数据库的高可用性和数据一致性。
- 基础设施复原:
- 基础设施即代码(IaC)工具:如Terraform, AWS CloudFormation,使基础设施的部署和恢复自动化、一致。
- 容器化与编排:如Docker, Kubernetes,通过容器化应用和使用编排工具,实现应用的快速部署和扩展。
监控与警报
- 监控工具:如Prometheus, Datadog,实时监控系统性能和健康状况。
- 警报系统:如Alertmanager, PagerDuty,当监测到异常时,自动触发警报通知相关人员。
容灾测试和维护
- 定期测试:通过模拟灾难场景对容灾计划进行测试,确保恢复策略和过程的有效性。
- 持续改进:根据测试结果和新的业务需求,不断调整和改进容灾计划。
快速恢复的关键因素
- 自动化:使用自动化工具和脚本来加速恢复过程,减少人为错误。
- 文档化:维护详细的恢复手册和操作指南,确保关键步骤和信息在紧急情况下能够迅速获取。
- 培训和演练:定期对团队进行容灾培训和演练,确保团队熟悉恢复流程。
- 分层备份和异地复制:实现数据的分层备份和异地复制,增强数据安全性和可用性。
还有最后再分享下,那就是容灾的预防、就像自然灾害的演练一样,平时的训练和演练才是最重要的。监控做好、演练做好、遇事不慌,相信一定可以做好容灾系统。
[1]
容灾概念: https://chat.openai.com/