- 综合排序
- 最热优先
- 最新优先
- 来自专栏腾讯云混沌工程团队
【云顾问-混沌】 跨 AZ 容灾混沌演练
进行跨 AZ（可用区）容灾和混沌演练变得尤为重要。 什么是跨 AZ 容灾以及混沌演练？ 跨 AZ 容灾 它是指在一个云服务商的多个可用区之间进行业务和数据备份、恢复和迁移的能力。 跨 AZ 容灾混沌演练的价值 跨 AZ 容灾和混沌演练相结合，可以帮助企业和组织实现以下目标： 提高业务可用性：确保业务在某个可用区发生故障时能够迅速迁移到其他可用区，保证业务的高可用性和持续性。 提高应急响应能力：通过定期进行跨 AZ 容灾和混沌演练，提高企业和组织的应急响应能力，确保在发生问题时能够迅速采取恢复措施。 如何快速进行跨 AZ 容灾混沌演练？ 借助于腾讯云混沌演练平台，可方便快捷地进行跨 AZ 容灾混沌演练时，可以遵循以下步骤： 前往腾讯云混沌演练平台【概览】选择「跨可用区容灾演练」行业经验模版。
77610编辑于 2024-03-15 - 来自专栏LEo的网络日志
01 Jun 2023 az tips
创建一个启用multi-az的ip az network public-ip create -n ssli-test-pip -g ssli-testing-rg --sku Standard --zone 1 2 3 --tier Regional --version IPv4 --allocation-method Static --idle-timeout 30 执行aks命令 az_aks_command () { CMD=$1; CMDOPTS=$2; az aks command invoke --resource-group ${RESOURCE_GROUP} --name ${AKS_NAME} --command "${CMD}" ${CMDOPTS}; } az_aks_command "kubectl get no -o wide" 以特定tenant登录 az login -t TEST.onmicrosoft.com 切换到特定订阅 az account set --subscription id_or_name LEo at 00:12
20920编辑于 2023-10-17 - 来自专栏腾讯专有云
3AZ比2AZ多了什么？关键是实现免人工切换
● 负载均衡层：通过跨 AZ 大集群形式部署，实现 CLB 实例的跨 AZ 负载及容灾能力。 ● 计算及存储-资源层：通过跨 AZ 的 统一大 VPC，可将 3AZ 的云服务器划分在同一个 VPC，实现3层网络可达，不需要经过集中式网关集群。 业务可在大 VPC 内进行 3AZ 的多活实例部署。 ● SDN 网关层：通过跨 AZ 大集群及就近访问能力，实现流量的就近接入及集群故障下的跨 AZ 流程接管能力。 ● PaaS资源层：通过跨 AZ 大集群能力，用户可创建的实例的多副本跨 AZ 分布的 PaaS 服务实例，应用层无需关心 PaaS 实例副本间的跨 AZ 数据同步等处理，使用统一 VIP 进行访问。 由 PaaS 服务提供跨 AZ 容灾能力。 ● 云管平台及底座层：将整体云管平台的容器及持久支撑服务组件实现跨 AZ 部署与调度，满足云管平台的跨 AZ 高可用，避免单一 AZ 故障后的平台不可用。
5K20编辑于 2023-04-03 - 来自专栏LEo的网络日志
29 Jul 2023 az-104备考总结
在azure中，订阅（subscription）是一个逻辑单位，它用于为使用azure的服务进行计费。你可以在一个订阅下创建、使用和管理azure资源。每个订阅都与一个azure帐户关联，并由azure帐户的所有者或服务管理员进行管理。
89340编辑于 2023-10-17 - 来自专栏运维小路
Zookeeper-案例 (多AZ高可用容灾)
我们前面部署3节点集群已经满足一般情况下的高可用，但是随着互联网的发展，集群的规模会越来越大，比如出现双AZ或者多AZ的情况下如何保证这种分布式集群的高可用性。下面我们以双AZ来讲解。 所有我们这里准备了6个节点，AZ1：3个普通节点，AZ2：2个普通节点，一个OB节点。由于OB的特性，可以算这个集群只有5个节点，只要有3个节点就可以正常选举出来Leader。 如果AZ2宕机，则不影响整个集群的使用，因为他可以在AZ1还可以选举出来Leader。 但是如果是AZ1宕机，则AZ2由于只有2个节点参与投票，所所以无法选举出来的Leader，ZooKeeper集群异常，需要手工介入修复（也是本次演示模式）。 当然如果你有3个AZ，则可以使用3+3+1方式，不配置OB节点，则可以正常选举Leader，但是3个AZ和2个AZ在实际情况下代价会高很多（云环境除外。所以我们这里介绍的是双AZ，手工介入。
44010编辑于 2025-05-22 - 来自专栏huofo's blog
【Azure微服务 Service Fabric 】使用az命令创建Service Fabric集群
cli命令来代替，但官方文档中只给出了PowerShell的命令，所以需要使用对应的az命令来替换。 替换为 az sf cluster create # Create the Service Fabric cluster. 如az sf cluster create -h 参数错误：cli.azure.cli.core.parser : az: error: unrecognized arguments image.png cloud set --name AzureChinaCloud az login az account set --subscription $subscriptionId # Create the view=azure-cli-latest#az_sf_cluster_create
3.5K20编辑于 2022-03-16 - 来自专栏腾讯云存储
腾讯云 COS 多 AZ 存储保证服务高可用性
多 AZ 存储是怎样实现 AZ 级的容灾能力，保证服务高可用的？下面就来揭秘多 AZ 存储架构的奥秘之处。 多个 AZ 之间互相独立，因此跨 AZ 部署能提高服务的可用性和容灾能力。 对于多 AZ 存储，COS 存储引擎部署在3个环境独立的 AZ 上。用户上传的数据将被切片存储在3个 AZ 的多个节点中。 COS 将这些存储分块打散分布在3个 AZ 的不同机架服务器上，就实现了多 AZ 存储。 多 AZ 存储优势 多 AZ 存储具有同城容灾、稳定持久、便捷易用的优势。 同城容灾：提供跨数据中心的容灾。多 AZ 存储架构下，对象数据会被存储在同个地域不同数据中心的不同设备中。 相比单 AZ 存储，多 AZ 存储提供更高可靠性和可用性的存储服务，二者对比如下： 对比项 多 AZ 存储 单 AZ 存储 数据设计持久性 99.9999999999% （12个9） 99.999999999%
76510编辑于 2024-09-17 - 来自专栏前端进阶学习交流
如何生成A-AZ列 excel表的列 不用序号的那种？
] return 返回列表 print(to_excel序号_字母(53)) print(to_excel序号_数字('AC')) 字母列表 = get_excel序号_列表('A', 'AZ
3.2K20编辑于 2022-12-19 好的，这份文档是关于腾讯专有云TCE（Tencent Cloud Enterprise）的高可用（High Availability, HA）解决方案，内容非常全面和深入。它详细阐述了TCE如何通过其架构设计、网络、计算、存储、数据层和应用层的各种机制，确保业务的连续性和数据的可靠性。
三AZ部署：所有分布式集群（支撑、管控、云产品）均可跨三AZ部署。任一AZ故障，剩余两个AZ能组成多数派（>50%），业务几乎无感切换（RTO≈0），数据强一致（RPO=0）。是最佳实践之一。 负载均衡 (CLB) 高可用：跨AZ集群，节点冗余（N+1/N+2），健康检查自动剔除故障节点。单节点故障无感，单集群故障可跨集群切换。 AZ故障→跨AZ调度重建Pods + CLB健康检查切换。 存储高可用： CBS (块存储)：三副本机制，故障检测后自动重建副本（透明）。 CSP/COS (对象存储)：跨AZ多副本（强一致）。 CSP支持2AZ四副本（MAZ+SAZ各2个）或3AZ三副本。COS还支持跨地域异步复制（最终一致）。 备份：快照（CBS）可跨AZ备份到COS。 数据可靠性 (高RPO)：核心数据通过跨AZ强一致复制实现RPO=0，确保无数据丢失。通过跨地域异步备份作为兜底。
23710编辑于 2026-02-24- 来自专栏ReganYue's Blog
Regan Yue带你一起学习微软AZ-900认证的有关知识「 第Ⅲ章」
Regan Yue带你一起学习微软AZ-900认证的有关知识「 第Ⅲ章」 16 - Question 你计划将多个服务器从本地网络迁移到 Azure。
59720发布于 2021-09-16 - 来自专栏帅云霓的技术小屋
云存储硬核技术内幕——(24) 双城记 (下)
在上一期，我们提到，我们如果期望让对象存储具备跨AZ的高可用功能，就需要让对象存储把副本存储到两个不同的AZ。但是，对于3副本的情况，总会有一个AZ里面只有单副本。 如图，主AZ和双活AZ各自建立了数据的三个副本，这样，当任意一个AZ整体故障时，另一个AZ都保存了数据的三个副本，数据的持久性和业务的可用性都不受影响。 那么，我们可以稍作变通—— 如图，对于需要跨AZ可用的数据，我们为它创建4个副本，分别保存在2个AZ。 当任一AZ不可用时，另一个AZ依然有2个副本可用！ 因此，对象存储跨AZ部署使用2+2的机制，也被业界广泛采用了。 当然，如果期望对象存储的服务跨AZ可用，还有两个重要的组件，需要在两个AZ都可用： 1、一致性哈希环。 它可以对同一服务商不同region的对象存储进行数据同步，甚至还可以对跨云服务商的对象存储进行数据搬迁，如从A公司的OSS上搬迁到T公司的COS上。
1.5K10编辑于 2022-08-04 - 来自专栏腾讯专有云
腾讯专有云高可用设计内幕揭秘
，如云服务器和容器服务平台等，能够实现 AZ 内或跨 AZ 的算力调度； 存储高可用：腾讯专有云TCE 中的存储资源，如云硬盘、文件存储及对象存储等，能够实现 AZ 内或跨 AZ 的多副本冗余存储； 中间件与数据库高可用 腾讯专有云TCE 的负载均衡和 VPCGW 实现了跨 AZ 的高可用，负载均衡 CLB 能够实现跨 AZ 集群，也就是在跨 AZ 的至少四个节点上实现用户会话的同步。 TCE 无论是三 AZ 高可用部署，还是双 AZ 高可用部署，都可以实现对象存储的跨 AZ 高可用，其架构如下图所示： 图12 专有云TCE 中对象存储高可用-跨 AZ 多副本 如图12中所示，场景 TDMQ 跨 AZ 高可用部署时，可以将 Broker 集群和 Bookie 集群都跨 AZ 部署，并且配置在持久化存储消息的时候，三个副本分配到位于两个或多个 AZ 上的 Bookie 节点，就可以实现跨 当专有云TCE 跨 AZ 部署时，各组件所依赖的 ZK 实例和 Etcd 集群，会组成跨 AZ 集群，以支撑各组件的跨 AZ 高可用。
8.8K42编辑于 2023-01-01 腾讯专有云TCE 高可用技术白皮书
架构图关键要素：跨AZ多副本部署、强一致性同步（如TDSQL跨AZ强一致）、仲裁区多数派选举（ZK/etcd 3+3+2部署）。 关键技术：TDSQL跨AZ强一致同步（主节点binlog多AZ从节点重放，写成功需全从节点确认）、TDMQ-Pulsar存算分离强一致（3+3 Broker/Bookie跨AZ）、CRedis最终一致性缓存 （性能优先）、TKE跨AZ容器集群（Deployment Pod多AZ分布）。 量化成果：某国有大型保险集团案例RTO压缩至2分钟级别，核心数据零丢失（RPO=0）；三AZ部署单AZ故障业务无中断（数据副本跨AZ分布）。 •国际性与技术领先：TCE高可用架构获金融客户验证，跻身全球分布式云平台领导者象限；自研产品如TDSQL分布式数据库（强一致跨AZ同步）、TDMQ-Pulsar金融级消息中间件（跨AZ强一致）、CRedis
22110编辑于 2026-03-17- 来自专栏开元说说
容灾系列（二）—— 企业借助云平台“一站式”容灾建设？
随着业务对持续性要求越来越高，云上不少企业对跨AZ或多地域的容灾建设有强烈的诉求。 数据同步稳定性对容灾建设不言而喻，云上有成熟数据同步工具以及具备跨地域或AZ级别实例；企业不需要维护开源社区同步工具。 4）监控告警能力建设。云上跨AZ或地域实例均有配套的监控告警。 tdmq tdmq天然具备跨az容灾能力 不同地域可以通过异步复制同步数据 es 1.控制台购买多可用区实例，对新增业务直接购买。 2.单az实例控制台均支持升级为跨可用区能力。 2.对于存量单az实例，在控制台进行增加不同可用区副本来升级 3.当前跨az实例，当前不支持副本只读。 2.单az实例控制台均支持升级为跨可用区能力。
5K42发布于 2021-06-15 - 来自专栏腾讯云网络专家服务
腾讯云高可用网络的修炼之道
业务的高可用网络 2.1 置放群组适合跨机房容灾吗 如果你细细品读上面推荐给你的【置放群组】的官方文档或者加以实践，你就会知道【置放群组】是支持跨AZ的，但是腾讯云【置放群组】虽然是支持跨地域的，但是租户的云服务器最终要归属于 ，也要尽可能的避免同一业务跨机房后，仍然在不同AZ之间存在着相互彼此的调用关系即子网间业务的强耦合，这种情况即使业务是跨AZ的，但由于AZ间业务上的依赖性，也无法做到很好的AZ级容灾，建议您如果对业务AZ AZ之间尽量的解耦以实现AZ级别高容灾，你可能会问：AZ1服务器访问DNS的流量会不会转发给AZ2的负载均衡网关或者即便时转发给了AZ1本AZ内的负载均衡网关，负载均衡又会不会将请求跨AZ转发到AZ2的真实 ，那么这种情况下，为了实现跨AZ级高可用，那么还是建议你要买就买两份，每个AZ各一份，让每个AZ的业务在本AZ进行闭环，尽可能的不发生跨AZ关联，既然要追求刺激何不贯彻到底呢 从以上的说法来看，好像腾讯云的产品是以 上文一直说的交叉指的是相同业务跨AZ或跨地域间调用的彼此依赖关系，一旦这种彼此依赖关系断裂则会影响调用链条两端的子业务，因此CLB跨AZ交叉绑定与上文一直说的交叉是不同的； [fglai31pjj.png
13.1K196发布于 2020-10-31 - 来自专栏帅云霓的技术小屋
云存储硬核技术内幕——(23) 双城记(中)
如果我们还期望业务的可用性达到99.999%以上，还需要实现对象存储的跨AZ部署，也就是所谓的“同城双活”。 因此，实际每个AZ的架构实现，是这样的—— (Metadata数据库也可以为分布式的，在此不画出) 那么，我们只要让LB能够跨AZ，就可以让http server的HA跨AZ！ 如图，我们可以这么做： Rhino输入oss.por***b.com这个域名的时候，DNS会解析返回61.83.133.6(主AZ的VIP)，一旦主AZ整体不可用，或主AZ内部的Http server 我们只需要修改从副本分配策略，让两个从副本必须有一个在另一个AZ，就可以让三副本跨AZ分布了。 这不是很好吗？ 正如鲁迅指出的那样，事实总是和理想有一定的差距。 当主AZ全部失效(如整个AZ断网或断电)时—— 如图，主AZ的两个副本都不可用了，只有从AZ的一个副本，如李密《陈情表》里面描述的：“外无期功强近之亲，内无应门五尺之童。
70020编辑于 2022-08-04 - 来自专栏帅云霓的技术小屋
云存储硬核技术内幕——(22) 双城记 (上)
在现代云计算模型中，每个地区为一个Region，每个Region有多个AZ： 其中，如果某个服务是跨AZ的服务，那么，一个AZ瘫痪时，服务是不受影响的。 前面提到，对象存储在AZ内可以实现99.9999999%的数据持久性，那么，有没有办法让对象存储成为跨AZ的服务，从而提升它的业务可用性呢？ 让我们再次重温分布式对象存储系统的架构： 如果我们希望对象存储能够跨AZ提供服务，显然，我们需要让这些部件都可以跨AZ实现服务： HTTP Server：跨AZ使用统一的域名； Metadata数据库 ：两个AZ各自有各自的索引； 存储池：跨AZ数据同步，或实现三副本分散到两个AZ； 如下图所示： 在下一期，我们开始为大家详解对象存储双活的设计实现。
62540编辑于 2022-08-04 - 来自专栏深度学习与python
打造消息中台，华为终端云基于 Apache Pulsar 的演进实践
容灾建设困难： 在单集群跨 AZ（Availability Zone，可用区）容灾场景中，存在因网络延迟导致的性能下降的问题； 在多集群跨 AZ 主备容灾场景中，资源闲置率很高。 4. 这意味着 3AZ 都涉及跨 AZ 数据同步，且数据写入需要等待所有跨 AZ 数据同步完成后才返回响应。这一设计的优点是高可靠，但缺点也十分明显，跨 AZ 同步的性能和时延存在较大波动。 在社区版本的基础上优化了跨 AZ 的标签能力，支持给 Broker 添加 AZ 标签，进而在选择 Bookie 时可支持单元化能力 2. 资源利用率提升 共享逃生池 无论跨多少 AZ，当出现集群级别的软件故障时，整个集群都是不可用的。 Pulsar 的容灾逃生架构如下： Pulsar 集群虽然是跨 AZ 部署，但是配置了机架感知，要求必须有副本落入另外一个 AZ 才算写入成功。
89620编辑于 2023-03-29 - 来自专栏腾讯云中间件的专栏
微服务高可用容灾架构设计
组件自身无状态，可多实例部署，底层 ES/Redis 为非关系型数据库，可使用主备/分片模式部署，可单独跨 AZ 部署，避免单点故障。 数据库层：一主多从，由于主节点只在一个 AZ，所以应用访问数据库可能会跨 AZ，因此要求AZ间网络延时低，降低数据倾斜带来的性能消耗。 应用异常分析 对应用层几种异常场景进行分析： 1、整个AZ宕机：利用 GSLB 或者跨 AZ 的 LB 等技术切换至另一个 IP，同时这层能力可以实现负载均衡。 2、微服务间调用容灾：TSF 支持 AZ 内就近路由，AZ 内实例不可用时跨 AZ 调用。 添加测试环境路由插件依赖 目前 TSF 基于跨 AZ 的 VIP(客户提供或者 TCS/TCE 提供)实现注册中心等组件自动切换至另一个 AZ，在单 AZ 故障时应用无感知自动切换另一个 AZ 的管控端
2.2K71编辑于 2023-09-09 - 来自专栏Forrest随想录
公有云上应该怎么做容灾？
上面我主要讲的还是基础设施层面的内容，不同的AZ完全可以满足要求。 或者说的简单点，很多产品都是AZ级别的，在一个AZ不可用，但是可以跨AZ容灾访问。 不过前面说的IO HANG的问题，就比较困难，现实情况下，跨AZ做虚拟机热迁移，这么大批量同时做，带宽满足不了，在很多技术细节上也没法做到，所以，还是具体问题具体看。 对于数据库或缓存这样的云产品来说，跨Region就没有任何意义了，时延太大，业务根本无法容忍。如果是跨AZ，数据库可能还好，但是缓存有时候也无法接受。 从AWS的标准来说，像数据库或缓存是要保证同Region跨AZ高可用的，但是实际能不能满足真实的业务要求，这个还要看具体情况，有些系统对时延敏感度极高，可能容忍度就更弱一些。 第三，一定要注意识别云产品的高可用级别，是AZ级别，还是Region级别，如果是Region级别，就要考虑跨Region的备份方案，否则，即使做了业务多活和双活，真的灾难状态下，还是起不到作用。
3.7K41发布于 2019-03-19
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号