一 基础信息 1.1 前提 本次安装的为 k3s 1.21.7+k3s1 VM 版本为 RHEL 7.8, 7.9 或 8.2, 8.3, 8.4(K3s 官网要求） VM YUM 仓库：已配置对应版本的 RHEL 和 EPEL YUM 仓库 VM 提供 root 权限 已配置 ntp（防止因为时间
开篇 📜 引言： 三人行必有我师焉 知识共享，天下为公 《K3s 系列文章》 《Rancher 系列文章》 方案 在腾讯云的 K3S 上安装 Rancher 方案目标 高可用 3 台 master 的 k3s 集群 高可用模式的 rancher 数据备份 rancher 数据备份到 腾讯云对象存储
概述 书接上回：《Rancher 系列文章-K3S 集群升级》, 我们提到：通过一键脚本升级 K3S 集群有报错。 接下来开始进行 Traefik 报错的分析和修复, 问题是: 所有 Traefik 的 IngressRoute 访问报错 404 问题描述 报错如下： time="2022-05-0
概述 书接上回：《Rancher 系列文章-Rancher 升级》, 我们提到：将 Rancher 用 Helm 从 v2.6.3 升级到 v2.6.4. 接下来开始进行 K3S 集群的升级：将 K3S 集群从 v1.21.7+k3s1 升级到 v1.22.5+k3s2 相关信息 本次升级的 K3S
概述 最近在玩 Rancher, 先从最基本的功能玩起, 目前有几个已经搭建好的 K8S 集群, 需要批量导入, 发现官网已经有批量导入的文档了. 根据 Rancher v2.6 进行验证微调后总结经验. 1. Rancher UI 获取创建集群参数 访问Rancher_URL/v3/cluster
概述 只要是个公司，基本上都有邮箱和 AD(Active Directory). 在 AD 里，已经有了： 用户 账号密码 邮箱 用户组 组织架构 所以对于一些仅限于本公司一定范围内人员使用的管理或后台或运营运维类系统，其实是非常适合对接 AD 来进行认证、分组，以及根据分组来进行权限分配的。 对于
概述 之前在 天翼云上用 4 台机器安装了一个 1 master（及 etcd) 3 node 的 K3S 集群，并在其上使用 Helm 安装了 Rancher 2.6.3 版本。 前几天发现 Rancher 官方推荐的最新版为：v2.6.4 所以决定先后对 Rancher 和 K3S 集群进行升级
一 基础信息 1.1 前提 本次安装的为 20220129 最新版：Rancher v2.6.3 VM 版本为 RHEL 7.8, 7.9 或 8.2, 8.3, 8.4(Rancher 官网要求） VM YUM 仓库：已配置对应版本的 RHEL 和 EPEL YUM 仓库 VM 提供 root 权
聊到 Terraform, 必然绕不开 IaC 这个概念？那么，什么是 IaC?
本文为系列文章-Grafana 统一展示，包括 Metrics、Tracing、Logging，并尽量实现在它们之间相互跳转。通过 Grafana LTM（Loki、Tempo、Mimir）可以实现比较完美的效果，但是即使没有 Grafana LTM， 通过其他 Grafana + 其他工具也能实现相对不错的结果。
本文为系列文章-Grafana 统一展示，添加 AWS Cloudwatch 数据源。
本文为系列文章-Grafana 统一展示，添加 AWS Cloudwatch 仪表板的变量和细节。
本文为系列文章-Grafana 统一展示，通过 Grafana Explore 功能探索 Jaeger 数据源中的 trace 信息。
本文为系列文章-Grafana GaC(Grafana 即代码） 的第二篇 - Grafana Terraform Provider 基础。
这几天碰到一个情况, 使用 Terraform 批量创建日志数据源时, 有的数据源类型是 ElasticSearch, 有些是 Opensearch. 那么, 如何根据某个字段(如:`es_type`)判断是否创建?
重要系统Oracle数据库U2L迁移场景中，如果客户来问我建议，我都会回复说首选就是XTTS，除非XTTS经测试实在是无法满足停机窗口，否则就不要考虑OGG这类方案。 换句话说，选择OGG做迁移的场景，都是没有其他办法时才会选用的方案了。 而在这类XTTS的迁移项目中,我认为bct的技术是至关重要的
通常选择XTTS做迁移的数据库都不会太小的，至少都是几T、几十T这样的规模，这种级别的数据量原有空间不够用，所以在迁移过程临时用作存放迁移数据库备份文件的空间也是需要提前考虑规划的问题。 最近就有客户有这样场景，数据库的数据量已经达到了60T+，也是优先选择XTTS的方案做U2L迁移测试。 至于这个
项目测试组又反馈一个问题，XTTS执行全量备份速度慢，影响测试进度。 实际算了下，平均速度才150MB/s.. 这个速度在客户生产环境的确是不够看，首先询问是否开了并行，开了多少？ 回复是说有开32个并行，在xtt.properties配置文件中指定的。 另外也注意在RMAN中show all的配置
在上篇《[XTTS系列之四：迷迷糊糊的并行度](https://www.cnblogs.com/jyzhao/p/17525723.html)》验证之后，就让测试组在RMAN配置中设置好正确的并行。然后重新将备份任务执行，平均速度直接由之前的150MB/s提升为1200MB/s。优化效果非常明显，速
MQ系列1：消息中间件执行原理 MQ系列2：消息中间件的技术选型 MQ系列3：RocketMQ 架构分析 MQ系列4：NameServer 原理解析 MQ系列5：RocketMQ消息的发送模式 MQ系列6：消息的消费 1 介绍 前面的章节我学习了 NameServer的原理，消息的生产发送，以及消息
