AIStor 更新和重启最佳做法

在现代世界中，保持系统运行不仅仅是赌注 - 它是没有商量余地的。当涉及到软件更新及其对您的系统意味着什么时 - 嗯，这要复杂得多。一方面，安全性是当今更新的主要驱动力，这也是没有商量余地的。需要尽快在所有系统中实施补丁，以保持最强的安全性。这同样适用于包含重要错误修复、性能改进和增强功能的软件更新。它们也应该及时实施，以利用内部的改进。但是停机时间呢？根据您的环境和操作流程，在应用安全补丁和软件更新时，可能会因服务重启而导致轻微的停机时间，并且可能会引入错误代码，从而导致严重停机，直到回滚或更新。如何在不停机的情况下及时更新和修补是一个难题，您需要做出正确的架构决策，否则您的环境就没有机会实现高可用性。

解决方案是依靠能够保证亚秒级重启时间的软件，即使跨数百个节点也是如此。这是我们投入巨资的领域，因此，即使是大规模升级 AIStor，也不会造成干扰。在本文中，我们将概述我们方法背后的理念，并向您展示如何执行高可用性对象存储所需的无中断升级。AIStor 专注于无中断重启，因为我们知道您的数据对您有多重要。数据是现代企业的血液。这意味着数据存储是核心。如果它停止了，血液就会停止流动——而且，坏事会发生。由于应用程序、ETL、工作流、数据库、AI/ML（甚至 CDN）的所有内容都依赖于数据，因此数据存储系统必须始终可用，即使它使用安全性和版本更新也是如此。未能实现无中断升级会累积技术债务并产生升级的负面激励，从而降低软件的实用性并增加数据隐私和持续业务运营的风险。

一般原则

使用 AIStor，就像时间一样，稳定性会朝着一个方向移动。最新的 AIStor 版本将永远是最稳定的。现代面向 CI/CD 的开发人员会理解这一点，而老派架构师可能不明白——但我们向你保证这是真的。AIStor 经常发布，但有意识地发布，并且每个版本都经过仔细规划、开发和测试。我们始终鼓励我们的客户和社区使用最新版本。发现的 Bug 将被修复，并与生成最新版本的上游合并。如果特定客户需要，可以根据请求向后移植修复程序，这些补丁将应用于旧版本。每周最新版本始终来自上游。因此，我们的客户和社区可以放心，最新版本具有您正在使用的当前版本所需的修复程序，无论该版本有多旧。虽然每个人都应该使用最新版本，但我们也认识到，我们的发布节奏和您的部署节奏以及必要的内部流程可能不一致。在每个人都运行大量软件包和开源框架的世界中，所有发布和部署节奏很少重叠。您的节奏不应影响您的停机时间 - 而 AIStor 则不会。

那么 AIStor 如何处理这一切呢？首先，AIStor 的最新二进制版本确保它向后兼容尽可能最早的版本。如果数据以较旧的格式写入，例如使用以前的元数据结构，则新版本将具有读取数据并将该数据就地升级到新格式的逻辑。每个版本的迁移逻辑都已融入到代码本身中，因此您无需执行额外的更新步骤。在 Linux 中，软件包管理器管理配置更改。但这可能会很麻烦，因为我们需要告诉包管理器每一个更改。这是一连串的更改，其中包含某人必须记住的所有更改和应用这些更改的脚本。AIStor 的滚动升级速度很快，任何旧版本的兼容性全部知识都由新版本处理。例如，最近有一位客户使用的是 2.0.9 版，他们想知道是否可以直接更新到 4.5.2 版，或者他们是否必须进行完整的重新安装或一次更新一个版本。我们建议他们直接升级到 4.5.2，他们能够立即启动并运行。AIStor 始终确保向后兼容性，我们永远不会让您高高在上。正如我们将在本教程中展示的那样，您只需下载较新版本，将其放在旧二进制文件的位置，然后重新启动您的服务。您可以从版本 B 无缝跳转到版本 X。实际上，AIStor 通过依赖关系链确保功能，该依赖关系链保证升级考虑了以前的版本，更重要的是，一次升级一个版本，例如 B->C->D....X。从用户的角度来看，也许更重要的是从管理员的角度来看，互联基础设施就是好用。AIStor 执行此迁移并处理兼容性的复杂性。结果是，不需要通过多个版本手动升级 – 这是一种过时的传统升级方式，让人想起运行整体式客户端-服务器应用程序的时代，在当今的云原生微服务世界中，当您落后几个版本或拥有数百个节点或两者兼而有之时，这是根本不可行的。

如果要求是按顺序升级，那就像谚语一样（顺便说一句是错误的），金门大桥的粉刷需要两年时间，但你必须每两年粉刷一次。关键是，如果你需要逐个版本地依次升级，你会把所有的资源都花在升级上，而没有任何东西可以改进、优化和定制。事实上，这是旧遗留系统中发生的事情。他们停滞不前，然后在自己的重量下崩溃。我们大多数拥有管理系统的人都知道其中的诀窍。支持系统和相关系统脱机。然后，为了最大限度地减少总停机时间，关闭每个节点，应用更新或安全补丁，重新启动节点，然后在下一个节点上重复整个周期。如果您有 2-3 个节点，这没什么大不了的，但如果集群中有 50 个节点，则可能需要一整天（或一整夜）。不仅数据数量，而且这些节点中的数据量也可能使该过程更长。同样，从业者知道这个过程是出了名的难以跟踪，如果没有准确的跟踪，他们就有可能不知道每个节点处于哪种状态。升级不完整的后果可能很严重。具有较旧二进制版本的现有 AIStor 服务器将接收请求，但无法理解包含新功能的请求。如果存在集群负载均衡器，则请求将随机发送到节点，因此很难控制请求的去向。

更新时间越长，您的 ETL 作业备份的时间就越长，恢复所需的时间就越长。这就是我之前提到的累积的技术债务。作为一名前 DevOps 工程师，我对此有切身的了解。有时，整个系统需要整整 24 小时的周期才能恢复和稳定。当系统重新启动时，由于更新的性质和应用更新所需的时间，不可避免地会出现配置不匹配或设置更改，这会导致进程无处不在。AIStor 缓解了这些问题，因为在下载二进制文件和服务重新启动之间，没有太多可能导致漂移的移动部件。首先，我们来谈谈 AIStor 如何让您实现不间断的更新和快速重启。稍后，我们将通过有关跨环境升级和重新启动 AIStor 的教程向您展示如何执行此操作。此 AIStor 升级过程可以扩展到 50 节点集群，每个集群都运行一个 AIStor 二进制文件，侦听端口 9000。

无缝、简单、瞬时

当 AIStor 二进制文件的新版本发布时，实际升级本身非常简单。我们将向您展示如何升级二进制文件以及 kubernetes Operator。此过程将同时在所有 50 个节点上升级。这种升级的性质可以节省时间，并激励您的 DevOpsteam 更频繁地升级二进制文件，因为此任务可以轻松自动化。从架构上讲，所有内容都位于一个二进制文件中，该二进制文件在单个进程 ID 中运行。二进制文件就位后，我们将同时在所有节点上重启 AIStor 服务。同样，您不需要一次执行一个节点操作，因为它们在后端都使用单个二进制文件和数据格式。当新进程重新启动时，后端进程知道如何读取旧版本正在管理的驱动器，因为迁移逻辑也在新版本中编码。重启发生得非常快，实际上是亚秒级，因为 AIStor 很高效。AIStor 几乎不使用任何 CPU 资源，整个代码库捆绑到一个二进制文件中，使其保持精简和简单明了，并且无需管理大量移动部件。同时，我们建议您同时更新所有节点。传统上，无中断升级只能通过滚动更新来实现，因为每个节点都需要时间来更新，并且节点相互依赖，因此必须一次更新一个节点。更新 AIStor 集群时，随着每个 AIStor 节点的更新，集群将继续使用旧版本运行，直到集群中的所有节点都更新完毕。这减轻了担心不同请求显示不同版本的负担，因为所有请求都转到同一版本，直到发生完全转换。通过并行执行更新，我们以原子方式执行更新;所有节点都运行较新版本的二进制文件，或者所有节点都运行旧版本的二进制文件。AIStor 确保您不会遇到一些节点运行旧版本而一些节点正在运行新版本的潜在破坏性情况。最好的部分是，使用 AIStor 的应用程序不知道此升级过程，因为 HTTP/API 调用甚至不知道服务器正在重新启动。我们不是在谈论需要节点通知其他节点和客户端它们正在重启的旧式应用程序或文件共享。AIStor 通过仍然在指定端口上接收请求来保持一致性，并且当服务重新启动时，它会将请求路由到已出现的较新版本。无论您是在数据中心的物理服务器上还是在 Kubernetes 中运行的 Pod 上运行 AIStor，都可以使用这种升级和重启方法。在下一部分中，我们将向您展示一个简单的教程，教您如何在实际运行的基础设施中实时实现这些概念。

执行升级

请务必确保集群中运行的所有节点都是 AIStor 部署的节点，而不是其他与 S3 兼容的服务。

要更新所有节点上的 AIStor，请运行以下命令

mc admin update ALIAS

此命令更新 AIStor 部署中的所有服务器。更新后，它还将同时在所有 AIStor 部署的节点上重新启动 AIStor 服务。AIStor 操作是原子的并且严格一致，因此重启过程不会对应用程序造成中断。

这避免了 AIStor 节点的“滚动”重启，并符合 AIStor 方式的更新和重启理念。

Kubernetes 操作员

如果您运行的是 Kuberntes 运算符，则可以按如下方式进行升级。

在开始升级之前，请在 operator 中验证资源的状态

kubectl get all -n minio-operator

同时验证 Operator 的版本

kubectl get pod -l 'name=minio-operator' -n minio-operator -o json | jq '.items[0].spec.containers'

验证后，您可以使用 krew 插件进行升级，或者在这种情况下，我们将向您展示如何手动进行升级。下载 AIStor kubernetes 插件，并将其替换为系统路径中已有的 on

curl https://github.com/minio/operator/releases/download/v4.5.8/kubectl-minio_4.5.8_linux_amd64 -o kubectl-minio

chmod +x kubectl-minio

mv kubectl-minio /usr/local/bin/

验证插件是否已安装在正确的路径中

kubectl minio version

以下命令是实际升级 Operator 的命令

kubectl minio init

从前面再次运行 jq 命令以验证新安装的 Operator 的版本

kubectl get pod -l 'name=minio-operator' -n minio-operator -o json | jq '.items[0].spec.containers'

这也可以通过登录到 Operator Console 进行验证

kubectl minio proxy

关于无中断升级的最终想法

现代企业始终处于运行状态，永不停机。诚然，在一个互联的世界中，企业没有端到端的控制——问问 Amazon 自己就知道了。话虽如此，需要设计出自作自受的停机时间 - 有了 AIStor 的功能套件，这成为可能。不要只听我们的一面之词，但是，请自己看看。创建一个 AIStor 集群，然后下载 AIStor（50 个节点对于测试:)来说可能有点高）并执行升级 - 您将亲眼看到并行性、弹性和二进制文件的力量，它足够小，可以在一秒钟内重新加载，但强大到足以为地球上一些最大的企业提供支持。未能实现无中断升级会立即导致技术债务的累积。这会产生涟漪效应，为您的整个工程和 DevOps 团队增加额外的技术债务。维护后，启动这些系统是完全不同的游戏。通常，它们必须按正确的顺序启动，并且需要进行广泛的测试，以确保它们在下线之前以相同的方式运行。您可以确信，每个 AIStor 版本在您的环境中都能完美运行，无论是开发、QA、暂存还是生产。我们尽一切努力确保每个新版本都是一项改进，并为您提供工具，以便在您的环境中快速验证这一点。在以后的博客文章中，我们将更详细地介绍如何设置这些不同的环境的建议。例如，如果您没有足够的节点用于不同的环境，那么您可以在相同的节点但不同的端口上运行多个 AIStor 二进制文件;这样，您可以将数据重新用于生产环境，并针对暂存环境端口对其进行测试，以确保在升级生产端口上运行的二进制文件之前，一切按预期工作。如果您有多个 AIStor 租户，则可以先升级免费套餐，然后随着信心的建立，您可以一次将其推广到其他区域。