MinIO 的强大用例之一是它可以在任何地方、任何东西上运行。随着行业慢慢转向将数据转移到托管中心或数据中心,越来越多的公司希望拥有与云中相同的对象存储功能,并完全控制基础设施。
为什么您希望数据离家较近?原因有很多,但首要的是成本。公共云已经变得非常昂贵。例如,前段时间我在 AWS 中运行了一个 ElasticSearch 托管集群。我很想尝试这项新的托管服务,但我并不急于与老板讨论我意外的 3 万美元账单。这是一个痛苦但熟悉的警钟,因为在那一刻我意识到我刚刚向 AWS 支付了六个月的云预算来完成一些我可以自己设置的事情。这个故事的寓意是,除非您非常小心并密切监控您的云支出,否则它可能会很快失控。
还有安全问题。无论您的数据位于公有云中的哪个位置,它几乎总是位于与您完全无关的人共享的节点或存储池上;这就是云的本质,因为这就是虚拟化的工作原理。云提供了一种温暖的舒适感,因为现在其他人必须应对安全挑战,但如果存在任何与安全相关的问题,将无法深入了解该问题(如果有人能够检测到它)以及如何解决它。当您为了保护自己的数据而不得不保护他人的基础设施时,舒适感很快就会消失。许多企业都享受到通过将 MinIO 转移到他们管理的硬件上而获得的完全控制权。
为了充分利用您的汇回工作,MinIO 配备了许多企业级功能,例如确保数据完整性的Bitrot 保护、将数据虹吸到冷存储层的分层、将对象保存为数据集合的 擦除编码以及奇偶校验块,并即时重建它们,无需任何额外的硬件或软件。除此之外,MinIO 还支持静态加密和传输中加密。这可确保从进行调用的那一刻起,直到将对象放入存储桶中,数据在事务的各个方面都得到加密,然后在存储桶中使用 IAM S3 样式策略和内置或外部 IDP 进行保护,请参阅MinIO最佳实践 - 安全和访问控制了解更多信息。
遣返必须彻底、仔细地计划。如果您要处理 PB 级的数据,那么拥有自己的基础设施和服务器来运行通常会更具成本效益,您甚至可以使用自己的(或租赁的)硬件构建私有云。此外,这还包括管理不动产(托管空间)、电源/UPS、冷却/HVAC 以及其他组件。不要被这些吓倒,因为我们将向您演示如何迁移,但总体投资回报率仍然比公共云更好。
私有云就像一间公寓(正如我们的首席执行官 AB Periasamy 喜欢说的那样)。您可以完全控制与之相关的成本和费用,您永远不会因为某些过夜运行的递归循环函数而引起意外账单警报。当然,当你试图让事情变得更好时,移动会遇到一些摩擦,例如,当你试图扩建高速公路时,你不可避免地必须关闭一些车道,以便施工可以安全进行,但一旦完成,你就会不仅可以在原来的车道上行驶,还可以在新建的车道上行驶。
我们在公共云中需要考虑的两个最重要的成本考虑因素是您需要的存储空间量和访问/移动数据时的出口成本 - 与您自己的硬件相比,这些成本可能分别高出约 39% 和 42%在您的数据中心或托管设施中。除此之外,其他一些需要考虑的成本因素包括软件、硬件、网络/交换机、房地产/机架空间/托管租赁、S3-API 调用——您能想到的一切等等。在云的生命周期中详细了解迁移到您自己的私有云可能带来的节省。
公共云和数据中心之间存在一个中间地带,您可以完全控制基础设施硬件,而无需高昂的初始投资成本。顾名思义, Equinix Metal提供符合客户要求的确切规格的裸机服务器。如果您想使用 NVMe SSD,则可以将这些磁盘添加到裸机服务器。 Equinix 提供管理 API 来简化硬件部署和操作。对于开发人员/最终用户来说,这就像在云中启动实例一样简单。事实上,甚至还有 Equinix Metal 的 Terraform 提供程序(我们稍后将向您展示)。
让我们开始吧!
虽然我们可以手动部署资源,但我的 DevOps 希望至少自动化该过程的一些重复部分,以节省时间和精力,特别是当我们想要进行站点到站点复制等操作时。
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
。
最终,无论选择哪种方法,都需要设置以下两个变量
您可以在API文档中找到有关这些的更多信息。
您还可以在terraform.tfvars
中修改其他几个变量,稍后我们在进行站点到站点复制时将修改以下变量。
设置好首选配置后,应用 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
这就是整个shebang。当您看到此输出时,不仅已配置物理服务器,而且 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 迁移数据?
我们可以从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
并设置两个变量
到目前为止,该过程看起来应该与我们启动第一个集群的方式非常相似,但这就是事情有所不同的地方。
让我们设置区分第二个站点和第一个站点的变量。
首先,让我们将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 }
此时,您应该有 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
中创建bucket进行测试
/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 提供程序本质上是一个连接到 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 提供支持。
我们现在已准备好所有构建块,供您拥有生产级对象存储和对整个基础设施的完全控制。接下来,我们将迁移 S3 中已有的数据。
您可以通过多种方式将数据从 AWS S3 迁移到 MinIO,但我们推荐的一种方式是使用mc
。
mc mirror
是数据同步的瑞士军刀。它可以从 S3 或 S3-API 兼容的对象存储中复制对象并将其镜像到 MinIO。更流行的用例之一是将 Amazon S3 存储桶镜像到 MinIO,以便将数据公开给非 AWS 应用程序和服务。
使用访问密钥和秘密密钥创建新的IAM 策略,仅允许访问我们的存储桶。保存生成的凭据以供下一步使用。
/opt/minio-binaries/mc alias set s3 https://s3.amazonaws.com BKIKJAA5BMMU2RHO6IBB V7f1CwQqAcwo80UEIJEjc5gVQUSSx5ohQ9GSrr12 --api S3v4
使用mc镜像将数据从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 的一小部分。保留对您的云的完全控制。
您对所有基础设施拥有 100% 的控制权吗?不完全的。交换机、路由器和其他网络设备由 Equinix 管理,但使用其网络的优点超过了缺点。您可以获得点对点、WAN 或其他专用电路,以虚拟方式连接到任何其他提供商。从本质上讲,您可以拥有直接连接到 AWS 的专用线路(通过 Equinix Connect),然后您可以以 10 倍的速度移动数据,同时始终保持安全,因为它不穿越开放的公共互联网,并且只有您的数据经过那个电路。
此外,MinIO基准测试反复显示,在启用加密的情况下,吞吐量性能下降非常小(<1%),因此我们建议所有 MinIO 部署使用静态加密,并且所有 MinIO 部署还应使用 TLS保护网络通信。恭喜,现在您的数据位于一个更安全、更透明的系统上,您可以在其中拥有完全的控制权和责任。
如果您对 Equinix Metal 上从 AWS S3 迁移到 MinIO 有任何疑问,请务必通过Slack联系我们!
也发布在这里。