检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
故障快速恢复 当应用系统采用华为云服务的高可用设计时,在云服务实例发生故障后,云服务能自动检测和恢复;但对于应用系统本身的故障,需要应用系统自身进行检测和快速恢复处理,以保证系统能够正常运行,从而提高系统的可靠性和稳定性。 RES08 依赖减少与降级 RES09 故障重试 RES10
例节点、实例主题、实例分区、实例分区的消费组、实例队列的消费组、实例的消费组等进行监控和告警。详见“支持的监控指标”。 RabbitMQ:配合CES服务,支持对RabbitMQ实例、实例节点、实例队列进行监控和告警等进行监控和告警。详见“支持的监控指标”。 RocketMQ:配合
突发性自然灾害等状况,主节点(Master)和备节点(Slave)均无法连接时,可将异地灾备实例切换为主实例,在应用端修改数据库链接地址后,即可快速恢复应用的业务访问。数据复制服务提供的实时灾备功能,可实现主实例和跨区域的灾备实例之间的单主灾备(详见“云数据库 TaurusDB到云数据库
设计原则 问题和检查项 COST01 规划成本优化相应的组织机构和流程 COST02 实施预算规划管理机制 COST03 对成本进行分配 COST04 持续进行成本治理 COST05 优化指定策略和目标 COST06 使用不同计费模式优化成本 COST07 管理和优化资源 COST08
包)。相反,通道则允许较为频繁的开启和关闭,但在发布消息时复用通道也是一个好的习惯,不要每发送一条消息都开启一个新的通道。同时需要注意如下几点: 多线程不要共享通道,因为你很难实现线程安全。 不要频繁的开启或关闭连接和通道,否则会造成更高的延迟。 生产者和消费者使用独立的连接,来提高吞吐量。
导致变更规格和迁移失败。应从设计源头上避免此类问题带来的影响。 设计合理的Key中元素的数量。 对于集合和列表类的数据结构(例如Hash,Set,List等),避免其中包含过多元素,建议单Key中的元素不要超过5000个。 建议 由于某些命令(例如HGETALL)的时间复杂度直接
性能优化工作中,需警惕“过早优化”的问题。我们的基本指导策略还是首先让系统运行起来,再考虑怎么让它变得更快。一般只有在我们证实某部分代码的确存在一个性能瓶颈的时候,才应进行优化。除非用专门的工具分析瓶颈,否则很有可能是在浪费自己的时间。另外,性能优化的隐含代价会使我们的代码变得难于理解和维护,这一点也是需要权衡和关注的。
RES08 依赖减少与降级 对于应用系统,需要识别和管理系统依赖项。应用系统设计人员需要维护对其他系统组件的依赖项的完整列表,包括系统内和系统外的所有依赖。 应用系统应尽可能减少关键依赖项,即减少由于该依赖项不可用而导致服务中断的组件。 RES08-01 减少强依赖项 RES08-02
考对应组件的调优。本文档重点讨论上述的1,2,3部分的性能调优的内容,并结合MapReduce/Spark的进行调优说明。 批处理业务 批处理主要特点是耗时时间长,消耗的资源比较多,主要的调优和设计推荐如下: 尽量使用ORC File, 配上合适的压缩算法, 主要可选的压缩算法为
选择合适网络服务资源 选择合适的网络服务资源是一个复杂的过程,需要考虑许多因素。以下提供了一些主要因素: 评估合适网络云服务,主要考虑如下性能指标: 网络流量:评估工作负载的预期网络流量,了解数据传输需求和网络请求的频率。 带宽要求:确定工作负载的带宽要求,考虑通过网络传输和接收的数据量。 网络
选择这两种模型时,部署的每个阶段之间的时间应该足够长,以便能够监控工作负载的运行状况指标。应该提供充足的部署间隔时间(即部署组之间的时间),以确保来自不同区域的用户或执行不同任务的用户有时间使用工作负载。间隔时间应以小时和天而不是分钟来衡量。每个部署组的间隔时间也应该增加,以便考虑不同的时区和使用模式。 相关云服务和工具
据丢失时间以及恢复时间符合数据的RPO与RTO指标要求。 风险等级 高 关键策略 灾难演练着重测试服务跨AZ或跨Region故障转移能力,验证系统的容灾能力以及面对灾难时的应对能力,涉及到多个团队间配合,通常作为专项开展。容灾演练可以帮助企业更好的验证RPO、RTO指标,及时发现
DMS分布式消息服务支持以下各种消息类型: Kafka版:基于开源社区版Kafka提供的消息队列服务,向用户提供计算、存储和带宽资源独占式的Kafka专享实例。 RabbitMq版:完全兼容开源RabbitMQ,提供即开即用、消息特性丰富、灵活路由、高可用、监控和告警等特性,广泛应用于秒杀、流控、系统解耦等场景。
或中断。 对已部署的应用系统,改造为支持高可用能力的实施步骤: 确定应用系统的关键组件;所谓关键组件是指一旦故障,会导致整个应用系统或其中的关键功能受损。 针对关键组件,检查其高可用能力,即在其故障的情况下,是否能自动故障转移,进行业务恢复。 针对未支持高可用的关键组件,进行如下优化处理:
预测:维护团队需要根据系统运行现状,通过数据分析、机器学习等方式,预测系统的风险情况,提前进行预防和处理。 在进行应急恢复处理时,通常需要尽快缓解或恢复业务,快速结束业务中断对客户的影响,然后再启动问题定位和修复处理流程,以减少业务中断时间。 组织协调:故障发生后,应急恢复主席需要迅速组织相关人员快速恢复业务。
CCE集群支持3个Master节点高可用部署,确保集群的可靠性。 数据备份和恢复 为满足数据持久化的需求,CCE支持将云硬盘(EVS)创建的存储卷挂载到容器的某一路径下;CCE通过云硬盘EVS服务提供针对云硬盘的快照功能,当数据丢失时,可通过快照将数据完整的恢复到快照时间点。详见“快照与备份”。
可用性目标定义 可用性是衡量可靠性和韧性的综合性指标。 可用度及SLO RTO与RPO 数据持久度 父主题: 基本概念
RES14 配置防差错 配置防差错是针对配置过程中因人输入了错误的配置数据导致系统和业务受损或失效场景下通过产品设计降低或避免配置错误产生的影响。 RES14-01 变更防呆检查 RES14-02 自动化变更 RES14-03 变更前数据备份 RES14-04 提供runbook进行标准化变更
关键策略 通过建立的分层性能模型,判断系统是否会出现性能劣化的情况。当出现劣化事件时,需要通过自动化手段快速定位定界发现根因。可以通过应用模型建设三维的拓扑,把架构-空间-时间数据关联起来。这里面的关键是架构模型的建立及分层指标的聚合可视化能力,需要依赖持续的资源治理和数据治理。
变更防差错 在系统的运行过程中,配置变更是导致生产系统不可用的重要风险之一,如配置修改、工作负载手工增缩或补丁安装等。当变更失败时,可能会导致性能下降或业务中断等严重的问题。因此为了降低变更带来的业务风险,需要为工作负载或其环境的更改做好准备,实现工作负载的可靠操作。 变更操作属