从 AWS S3 迁移到 Equinix Metal 上的 MinIO

AJ AJ 于混合云 2023年7月26日

Migrate from AWS S3 to MinIO on Equinix Metal

MinIO 的一个强大用例是它能够在任何地方和任何设备上运行。随着行业逐渐转向将数据迁移回自建机房或数据中心，越来越多的公司希望获得与云端相同的对象存储功能，并完全控制基础设施。

为什么您希望将数据存储在更靠近自己的地方？原因有很多，但首要的是成本。公共云变得非常昂贵。例如，前段时间我在 AWS 上运行了一个 ElasticSearch 托管集群。我渴望尝试这项新的托管服务，但我并不想和我的老板讨论我那令人惊讶的 3 万美元账单。这是一个痛苦但熟悉的警钟，因为那一刻我意识到，我刚刚支付了 AWS 六个月的云预算来做一些我本来可以自己设置的事情。故事的寓意是，除非您非常小心并密切监控您的云支出，否则它可能会很快失控。

还有安全问题。无论您的数据在公共云中的哪个位置，它几乎总是位于与您完全无关的人共享的节点或存储池上；这是云的本质，因为它是虚拟化工作的方式。云提供了温暖的舒适感，因为现在其他人必须解决安全挑战，但是如果有任何与安全相关的问题，将无法洞察问题（如果有人能够检测到它）以及如何解决它。当您不得不为了保护自己的数据而不得不保护他人的基础设施时，这种舒适感会迅速消失。许多企业已经享受了将数据迁移回他们管理的 MinIO 硬件带来的完全控制权的回报。

为了最大限度地利用您的数据迁移工作，MinIO 附带了许多企业级功能，例如数据完整性保护以确保数据完整性，分层存储将数据转移到冷存储层，纠删码将对象保存为数据和奇偶校验块的集合，并在无需任何额外硬件或软件的情况下动态重建它们。除了这些之外，MinIO 还支持加密在静止状态和传输过程中。这确保了数据在从发出调用到对象放置在存储桶中的整个交易过程中都被加密，然后使用 IAM S3 风格的策略和内置或外部 IDP 进行保护，请参阅 MinIO 最佳实践 - 安全和访问控制以获取更多信息。

数据迁移必须经过周密而谨慎的计划。如果您正在处理 PB 级别的数据，通常拥有自己的基础设施和服务器来运行更具成本效益，您甚至可以使用自己的（或租赁的）硬件构建私有云。此外，这还包括管理房地产（机房空间）、电力/UPS、冷却/HVAC 等组件。不要被这些吓倒，我们将向您展示如何迁移，并且总体 ROI 仍然优于公共云。

私有云就像一套公寓（正如我们的首席执行官 AB Periasamy 喜欢说的那样）。您可以完全控制与之相关的成本和费用，您永远不会因为某些在夜间运行的递归循环函数而收到意外账单的警报。当然，在您试图改进事物时，移动会有一些阻力，例如，当您试图拓宽高速公路时，您不可避免地必须关闭一些车道才能安全地进行施工，但是一旦完成，您不仅能够在原来的车道上行驶，还能在新建的车道上行驶以处理容量。

在公共云中，我们需要考虑的两个最重要的成本因素是您需要的存储空间量以及访问/移动该数据时的出口成本——与您数据中心或托管设施中的自有硬件相比，这些成本分别可能高出 39% 和 42% 左右。除此之外，其他一些需要考虑的成本因素包括软件、硬件、网络/交换机、房地产/机架空间/托管租赁、S3-API 调用——所有你能想到的以及更多。在云的生命周期中了解更多有关迁移到您自己的私有云可能带来的节省。

在公共云和您的数据中心之间存在一个中间地带，您可以在其中完全控制基础设施硬件，而无需高昂的初始投资成本。Equinix Metal，顾名思义，提供满足客户要求的裸机服务器。如果您想使用 NVMe SSD，则可以将这些磁盘添加到裸机服务器。Equinix 提供了一个管理 API 来简化硬件部署和操作。对于开发人员/最终用户而言，它与在云中启动实例一样简单。实际上，甚至还有一个 Equinix Metal 的 Terraform 提供程序（我们稍后会向您展示）。

让我们开始吧！

部署基础设施

虽然我们可以手动部署资源，但我内心的 DevOps 想要至少自动化此过程的一些重复部分以节省时间和精力，尤其是在我们想要进行站点到站点复制等操作时。

设置 Equinix Metal Terraform

Equinix 是少数几个拥有 API 来完全自动化基础设施管理过程的裸机提供商之一。使用他们的 API，您可以自动化部署物理服务器、关闭它们甚至终止它们。您可以完成所有这些操作，而无需使用您自己的硬件、交换机、路由器和其他资源。这与公共云级别的自动化尽可能接近，同时仍然保证没有其他人共享您的硬件。因为 Equinix Metal 支持多种实例类型和存储选项以及互连，例如 SAS 或 SATA，以及 SSD、NVMe SSD 或 HDD，并且有多种尺寸可供选择。您还可以根据您的确切规格配置 MinIO 运行的硬件——直至用于容纳 MinIO 分区的驱动器的确切类型。

没有人期望您编写 Python 脚本与 Metal API 交谈；Equinix Metal 有一个 Terraform Provider，允许我们连接到它并提供部署集群资源所需的高级信息，同时抽象出获取网络、硬件、MinIO 和其他应用程序设置所需的内部操作。

provider "metal" {
auth_token = var.auth_token
}

如果您尚未安装 Terraform，可以从他们的下载页面下载。

将 GitHub 存储库 equinix/terraform-metal-distributed-minio 克隆到您的本地工作站。

git clone https://github.com/equinix/terraform-metal-distributed-minio.git

进入存储库并初始化 Terraform，以便它可以从上游下载所有必需的模块和插件。

$ cd terraform-metal-distributed-minio
$ terraform init

这将确保自动下载所有必需的模块。现在，让我们确保设置了几个必需的变量。您可以将它们设置为环境变量，或者在上面克隆的存储库中有一个名为 vars.template 的文件，您可以将其复制为 cp vars.template terraform.tfvars。

最终，无论您选择哪种方法，都需要设置以下两个变量

auth_token
project_id

您可以在 API 文档中找到有关这些内容的更多信息。

您可以在 terraform.tfvars 中修改其他几个变量，我们将在以后进行站点到站点复制时修改以下变量。

facility: https://deploy.equinix.com/developers/docs/metal/locations/metros/
minio_region_name: 部署 MinIO 集群的区域。

设置好您喜欢的配置后，应用 Terraform 计划。如果计划看起来没问题，请运行 approve 命令。

$ terraform plan
$ terraform apply --auto-approve

如果资源已使用正确的配置正确应用，则结果输出应如下所示

Apply complete! Resources: 10 added, 0 changed, 0 destroyed.

Outputs:

minio_access_key = Xe245QheQ7Nwi20dxsuF
minio_access_secret = 9g4LKJlXqpe7Us4MIwTPluNyTUJv4A5T9xVwwcZh
minio_endpoints = [
  "minio-storage-node1 minio endpoint is http://147.75.65.29:9000",
  "minio-storage-node2 minio endpoint is http://147.75.39.227:9000",
  "minio-storage-node3 minio endpoint is http://147.75.66.53:9000",
  "minio-storage-node4 minio endpoint is http://147.75.194.101:9000",
]
minio_region_name = us-east-1

这就是全部。当您看到此输出时，不仅已预配了您的物理服务器，而且还将 MinIO 部署到了这些节点上，并且这些节点已配置为分布式存储集群。

访问 MinIO 集群

我们使用 Terraform 自动化了大部分过程，因此现在剩下的就是访问 MinIO 集群。我们推荐的工具是使用 mc。使用以下命令下载二进制文件

curl https://dl.min.io/client/mc/release/linux-amd64/mc \
  --create-dirs \
  -o $HOME/minio-binaries/mc

chmod +x $HOME/minio-binaries/mc
export PATH=$PATH:$HOME/minio-binaries/

创建一个指向我们部署的 MinIO 集群的别名

mc config host add minio1 $MINIO_ENDPOINT $MINIO_ACCESS_KEY $MINIO_SECRET_KEY

您可以使用在通过 Terraform 启动 MinIO 集群时设置的值替换以上变量，但请确保将别名设置为minio1。稍后当我们向您展示如何进行站点到站点复制时，这将变得有意义。

检查您是否能够通过从集群获取一些元数据来成功连接。

$ mc admin info minio1 --json | jq .info.backend

{
  "backendType": "Erasure",
  "onlineDisks": 48,
  "rrSCData": 6,
  "rrSCParity": 2,
  "standardSCData": 6,
  "standardSCParity": 2
}

如果您看到类似于上述的输出，则表示您能够通过mc命令成功访问 MinIO 集群。那么接下来是什么？我们什么时候应该将数据从 S3 迁移过来呢？

MinIO 集群的负载均衡

我们可以将数据从 S3 迁移过来，甚至添加一些我们自己的数据，并开始使用集群。但是让我们更进一步。我们希望实现与 AWS S3 相同级别的冗余，这意味着如果一个站点宕机，我们希望确保我们的数据可以在另一个站点上访问。AWS 通过区域实现了这一点，但是我们如何用 MinIO 实现这一点呢？

现在，我们可以看到我们之前使用 Terraform 进行的小型自动化带来的优势。让我向您展示在 Equinix Metal 上启动另一个 MinIO 区域是多么简单。

让我们再次git clone我们的源代码仓库，但这次在新的目录terraform-metal-distributed-minio-site-2中。

git clone https://github.com/equinix/terraform-metal-distributed-minio.git terraform-metal-distributed-minio-site-2

进入terraform-metal-distributed-minio-site-2仓库并初始化 Terraform，以便它可以从上游下载所有必需的模块和插件，类似于最初的 MinIO 部署。

$ cd terraform-metal-distributed-minio-site-2
$ terraform init

所有模块下载完成后，复制变量文件cp vars.template terraform.tfvars并设置这两个变量。

auth_token
project_id

到目前为止，该过程应该看起来与我们启动第一个集群的方式非常相似，但这里将有所不同。

让我们设置区分第二个站点和第一个站点的变量。

首先，让我们将facility设置为sv16或从以下设施列表中选择一个设施。接下来将minio_region_name设置为us-west-1或任何与其他集群不同的名称。

运行计划以确保您所做的更改反映在输出中。

$ terraform plan
$ terraform apply --auto-approve

如果资源已正确应用且配置正确，则生成的输出应如下所示。

Apply complete! Resources: 10 added, 0 changed, 0 destroyed.

Outputs:

minio_access_key = Xe245QheQ7Nwi20dxsuF
minio_access_secret = 9g4LKJlXqpe7Us4MIwTPluNyTUJv4A5T9xVwwcZh
minio_endpoints = [
  "minio-storage-node1 minio endpoint is http://144.45.65.29:9000",
  "minio-storage-node2 minio endpoint is http://144.45.39.227:9000",
  "minio-storage-node3 minio endpoint is http://144.45.66.53:9000",
  "minio-storage-node4 minio endpoint is http://144.45.194.101:9000",
]
minio_region_name = us-west-1

如果您看到minio_region_name为us-west-1，则表示您已成功启动了第二个集群。让我们将其添加到mc中。

mc config host add minio2 $MINIO_ENDPOINT $MINIO_ACCESS_KEY $MINIO_SECRET_KEY

将别名设置为minio2，并检查您是否能够通过从集群获取一些元数据来成功连接。

$ mc admin info minio2 --json | jq .info.backend

{
  "backendType": "Erasure",
  "onlineDisks": 48,
  "rrSCData": 6,
  "rrSCParity": 2,
  "standardSCData": 6,
  "standardSCParity": 2
}

此时，您应该有两个站点：minio1和minio2。

让我们在两个集群之间设置复制。

$ mc admin replicate add minio1 minio2
Requested sites were configured for replication successfully.

验证两个站点是否已正确配置。

mc admin replicate info minio1

SiteReplication enabled for:

Deployment ID                    	| Site Name   	| Endpoint
f96a6675-ddc3-4c6e-907d-edccd9eae7a4 | minio1      	| http://<site1_public_ip>
0dfce53f-e85b-48d0-91de-4d7564d5456f | minio2      	| http://<site2_public_ip>

检查以确保复制正常工作。

mc admin replicate status minio1

Bucket replication status:
No Buckets present

Policy replication status:
●  5/5 Policies in sync

User replication status:
No Users present

Group replication status:
No Groups present

通过在minio1中创建一个桶进行测试。

/opt/minio-binaries/mc mb minio1/testbucket

向桶中添加任何对象。

/opt/minio-binaries/mc cp my_object minio1/testbucket

列出其他站点（在本例中为minio2）中的对象。

/opt/minio-binaries/mc ls minio2/testbucket
[2023-07-20 18:52:09 UTC] 3.0KiB STANDARD my_object

如您所见，将数据复制到其他 MinIO 部署几乎是即时的，即使它们在地理位置上相距甚远。

让我们做一个快速测试，看看这是否真的像看起来那样简单。请记住，MinIO 是 AWS S3 的直接替代品，因此所有应该与 S3 一起使用的功能都将与 MinIO 一起使用。在本例中，我们将使用 Terraform 将对象上传到 MinIO 桶。在 Terraform 中，这是通过 AWS 提供程序完成的，该提供程序本质上是一个连接到 AWS API 以在 AWS 生态系统中执行各种操作的模块，但在本例中，我们将使用 Terraform AWS S3 资源来访问 MinIO 桶。

在 Terraform 中创建如下所示的 AWS 提供程序。确保您更新详细信息以匹配我们刚刚部署的 Equinix Metal minio1集群。

provider "aws" {
    region = "us-east-1"
    access_key = "Xe245QheQ7Nwi20dxsuF"
    secret_key = "9g4LKJlXqpe7Us4MIwTPluNyTUJv4A5T9xVwwcZh"
    skip_credentials_validation = true
    skip_metadata_api_check = true
    skip_requesting_account_id = true
    s3_force_path_style = true
    endpoints {
        s3 = "http://147.75.65.29:9000"
    }   
}

使用 terraform aws_s3_bucket_object资源上传文件。

resource "aws_s3_bucket_object" "object" {
    bucket = "public"
    key = "my_file_name.txt"
    source = "path/to/my_file_name.txt"
    etag = filemd5("path/to/my_file_name.txt")
}

如您所见，我们没有使用任何 MinIO 特定的 Terraform 资源，而是使用了 AWS 提供程序aws_s3_bucket_object资源。即使我们使用现有的 AWS S3 Terraform 资源，对象存储也完全由生产级企业级 MinIO 提供支持。

从 AWS S3 迁移数据

我们现在已经准备好了所有构建块，您可以拥有生产级的对象存储并完全控制整个基础设施。接下来，我们将迁移已存在于 S3 中的数据。

您可以通过多种方法将数据从 AWS S3 迁移到 MinIO，但我们推荐使用mc。

mc mirror是数据同步的瑞士军刀。它可以从 S3 或与 S3 API 兼容的对象存储中复制对象，并将它们镜像到 MinIO。此功能的一个更流行的用例是将 Amazon S3 桶镜像到 MinIO，以便向非 AWS 应用程序和服务公开数据。

创建一个新的具有访问密钥和密钥的IAM 策略，仅允许访问我们的桶。保存生成的凭证以供下一步使用。

接下来，让我们使用我们创建的 S3 桶名称以及我们下载的凭证添加一个别名。

/opt/minio-binaries/mc alias set s3 https://s3.amazonaws.com BKIKJAA5BMMU2RHO6IBB V7f1CwQqAcwo80UEIJEjc5gVQUSSx5ohQ9GSrr12 --api S3v4

使用mc mirror将数据从 S3 复制到 MinIO。

mc mirror s3/mybucket minio1/testbucket

根据数据量、网络速度和存储桶数据所在区域的物理距离，镜像所有数据可能需要几分钟或更长时间。当mc完成复制所有对象时，您将看到一条消息。

数据复制完成后或复制过程中，列出minio2站点中桶的内容。您会注意到一些数据已经从minio1中复制过来了。

/opt/minio-binaries/mc ls minio2/testbucket
[2022-12-19 18:52:09 UTC] 3.0KiB STANDARD all_object s

最终，您运行mc mirror的笔记本电脑是一个瓶颈，因为数据必须穿过执行mc mirror命令的系统。这可能是几 PB 的数据，根据网络速度，迁移可能需要几天甚至几周的时间。要将数据从 S3 迁移到 MinIO，有一种更有效的方法称为批处理复制，请参阅如何从 AWS S3 迁移到 MinIO，以了解有关批处理复制和其他迁移最佳实践的更多信息。

全力以赴

这篇博文证明了在站点到站点复制配置中运行在 Equinix Metal NVMe SSD 上的 MinIO 将为您提供相同甚至更高的性能、数据持久性和弹性，同时只需支付 S3 的一小部分成本，同时保留对云的完全控制。

您是否完全控制所有基础设施？不完全是。交换机、路由器和其他网络设备由 Equinix 管理，但位于其网络上的优势超过了劣势。您可以获得点对点、广域网或其他专用电路，以虚拟方式连接到任何其他提供商。从本质上讲，您可以拥有一个直接连接到 AWS（通过 Equinix Connect）的专用电路，然后您可以将数据传输速度提高 10 倍，同时保持安全，因为它不会穿越开放的公共互联网，并且只有您的数据通过该电路。

此外，MinIO 的基准测试反复表明，启用加密后吞吐量性能下降非常小（<1%），因此我们建议所有 MinIO 部署都使用静态加密，并且所有 MinIO 部署也应使用 TLS保护网络通信。恭喜，现在您的数据位于一个更安全、更透明的系统中，您拥有完全的控制权和问责制。

如果您有任何关于将 AWS S3 迁移到 Equinix Metal 上的 MinIO 的问题，请务必在Slack上联系我们！