AWS S3 から Equinix Metal の MinIO に移行する方法

MinIO の強力な使用例の 1 つは、どこでも、あらゆるもので実行できるという事実です。業界がデータをコロニーまたはデータセンターに送還する方向に徐々に移行するにつれて、インフラストラクチャを完全に制御しながら、クラウドにあるのと同じオブジェクト ストレージ機能を求める企業がますます増えています。

データを家の近くに置きたいと思うのはなぜですか?理由はいくつかありますが、一番の理由はコストです。パブリック クラウドは非常に高価になっています。たとえば、少し前に、AWS で ElasticSearch マネージド クラスターを実行していました。私はこの新しいマネージド サービスを試してみたいと思っていましたが、驚きの 3 万ドルの請求について上司と話し合う気はありませんでした。これは痛みを伴う、しかし懐かしい警鐘でした。なぜなら、その瞬間、私は自分で設定できることを行うために AWS に 6 か月分のクラウド予算を支払っただけだと気づいたからです。この話の教訓は、非常に注意深くクラウド支出を注意深く監視しない限り、クラウドは急速に制御不能になる可能性があるということです。

セキュリティの問題もあります。データがパブリック クラウドのどこにあるかに関係なく、データはほとんどの場合、あなたとはまったく関係のない誰かによって共有されているノードまたはストレージ プール上にあります。これが仮想化の仕組みであるクラウドの性質です。クラウドは温かい安心感を与えてくれます。なぜなら、今は他の誰かがセキュリティの課題に取り組まなければならないからです。しかし、セキュリティ関連の問題があった場合、その問題 (誰かがそれを検出できたとしても) とその解決方法についての洞察は得られません。 。自分のデータを保護するために他人のインフラストラクチャを保護する必要に迫られると、その安心感は急速に蒸発してしまいます。多くの企業は、管理するハードウェアを MinIO に戻すことによって提供される完全な制御への復帰を享受しています。

送還の取り組みを最大限に活用するために、MinIO には、データの整合性を確保するBitrot Protection 、データをコールド ストレージ層に吸い上げる階層化、オブジェクトをデータのコレクションとして保存するErasurecodingなど、エンタープライズ対応の機能が多数搭載されています。パリティ ブロックを作成し、追加のハードウェアやソフトウェアを必要とせずにオンザフライでパリティ ブロックを再構築します。これらに加えて、MinIO は保存時と転送時の両方の暗号化をサポートします。これにより、呼び出しが行われた瞬間からオブジェクトがバケットに配置されるまで、トランザクションのすべての面でデータが暗号化されます。その後、データは IAM S3 スタイルのポリシーと組み込みまたは外部の IDP で保護されます。 「MinIO」を参照してください。詳細については、「ベスト プラクティス - セキュリティとアクセス制御」を参照してください。

本国送還は徹底的かつ慎重に計画する必要があります。ペタバイト規模のデータを扱う場合は、一般に、独自のインフラストラクチャとサーバーを実行する方がコスト効率が高く、独自の (またはリースした) ハードウェアを使用してプライベート クラウドを構築することもできます。さらに、これには、不動産 (コロスペース)、電源/UPS、冷却/HVAC などのコンポーネントの管理も含まれます。パブリック クラウドよりも全体的な ROI が向上する移行方法を説明しますので、これらの理由で思いとどまらないでください。

プライベート クラウドはアパートのようなものです (当社 CEO の AB Periasamy がよく言います)。それに関連するコストと出費を完全に制御できるため、一晩中実行された再帰ループ関数によって突然の請求が発生するというアラートに目が覚めることはありません。もちろん、状況を改善しようとするときに移動には多少の摩擦が伴います。たとえば、高速道路を拡張しようとする場合、建設を安全に進めるために必然的に一部の車線を閉鎖する必要がありますが、いったん完了すると、元の車線を走行できるだけでなく、収容力に合わせて新しく建設された車線も走行できます。

パブリック クラウドで考慮する必要がある最も重要なコストの 2 つは、必要なストレージ容量と、そのデータにアクセス/移動する際の下りコストです。これらは、独自のハードウェアと比較して、それぞれ約 39% と 42% 高くなります。データセンターまたはコロケーション施設で。これに加えて、考慮すべきコスト要素には、ソフトウェア、ハードウェア、ネットワーキング/スイッチ、不動産/ラック スペース/コロケーション レンタル、S3-API 呼び出しなど、考えられるすべてのものがあります。独自のプライベート クラウドに移行することで得られる節約の詳細については、 「クラウドのライフサイクル」をご覧ください。

パブリック クラウドとデータ センターの間には、高額な初期投資コストをかけずにインフラストラクチャ ハードウェアを完全に制御できる中間点が存在します。 Equinix Metal は、その名前が示すように、顧客が要求した正確な仕様を備えたベア メタル サーバーを提供します。 NVMe SSD を使用する場合は、それらのディスクをベア メタル サーバーに追加できます。 Equinix は、ハードウェアの導入と運用を簡素化するための管理 API を提供します。開発者/エンドユーザーにとっては、クラウドでインスタンスを起動するのと同じくらい簡単です。実際、Equinix Metal 用の Terraform プロバイダーもあります (これについては後で説明します)。

始めましょう！

インフラストラクチャの導入

リソースを手動でデプロイすることもできますが、私の中の DevOps は、時間と労力を節約するために、特にサイト間のレプリケーションを行う場合に、このプロセスの繰り返しの部分の少なくとも一部を自動化したいと考えています。

Equinix Metal Terraform のセットアップ

Equinix は、インフラストラクチャ管理プロセスを完全に自動化する API を備えた数少ないベアメタル プロバイダーの 1 つです。 APIを使用すると、物理サーバーの展開、シャットダウン、さらには終了までを自動化できます。これらすべてを、独自のハードウェア、スイッチ、ルーター、その他のリソースを使用せずに行うことができます。これは、ハードウェアを他の人が共有しないことを保証しながら、パブリック クラウド レベルの自動化に限りなく近いものになります。 Equinix Metal は、さまざまなサイズの無数のインスタンス タイプ、ストレージ オプション、および SAS や SATA、SSD、NVMe SSD、HDD などの相互接続をサポートしているためです。また、MinIO が実行されるハードウェアを、MinIO パーティションを格納するドライブの正確な種類に至るまで、正確な仕様に合わせて構成することもできます。

Metal API と通信するための Python スクリプトを作成することを期待している人は誰もいません。 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としてコピーすることもできます。

最終的には、どの方法を選択しても、次の 2 つの変数を設定する必要があります。

• 認証トークン
• プロジェクトID

これらの詳細については、 APIドキュメントを参照してください。

terraform.tfvarsで変更できる変数は他にもいくつかあります。後でサイト間のレプリケーションを行うときに次の変数を変更します。

• 施設: 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 と同じレベルの冗長性を実現したいと考えています。つまり、1 つのサイトがダウンした場合でも、別のサイトからデータにアクセスできるようにしたいと考えています。 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をコピーし、2 つの変数を設定します。

• 認証トークン
• プロジェクトID

ここまでのプロセスは、最初のクラスターを起動した方法と非常に似ているはずですが、ここからが異なります。

2 番目のサイトと最初のサイトを区別する変数を設定しましょう。

まず、 facility sv16に設定するか、この施設リストから 1 つ選択しましょう。次に、 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と表示されている場合は、2 番目のクラスターが正常に起動されています。それを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の 2 つのサイトが存在するはずです。

両方のクラスター間でレプリケーションを設定しましょう

$ 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 にミラーリングできます。この最も一般的な使用例の 1 つは、AWS 以外のアプリケーションやサービスにデータを公開するために、Amazon S3 バケットを MinIO にミラーリングすることです。

アクセス キーと秘密キーを使用して新しいIAM ポリシーを作成し、バケットへのアクセスのみを許可します。生成された認証情報を次のステップのために保存します。

 /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を実行しているラップトップがボトルネックになります。これは数ペタバイトのデータになる可能性があり、ネットワーク速度によっては移行に数週間とは言わないまでも数日かかる場合があります。 S3 から MinIO にデータを移行するには、バッチ レプリケーションと呼ばれるより効率的な方法があります。バッチ レプリケーションとその他の移行のベスト プラクティスの詳細については、「AWS S3 から MinIO に戻す方法」を参照してください。

ペダルを金属に近づける

このブログ投稿では、サイト間レプリケーション構成の Equinix Metal NVMe SSD 上で動作する MinIO が、S3 の数分の 1 のコストで、同等またはそれ以上のパフォーマンス、データ耐久性、回復力を提供することを実証しました。クラウドに対する完全な制御を維持します。

すべてのインフラストラクチャを 100% 制御できますか?完全ではありません。スイッチ、ルーター、その他のネットワーク機器はエクイニクスによって管理されていますが、同社のネットワーク上にあることの利点は欠点を上回ります。ポイントツーポイント、WAN、またはその他の専用回線を利用して、他のプロバイダーに仮想的に接続できます。本質的には、プライベート回線を (Equinix Connect 経由で) AWS に直接接続すると、オープンなパブリック インターネットを経由せず、データのみが通過するため安全性を保ちながら、データを 10 倍の速度で移動できます。その回路。

さらに、MinIOベンチマークでは、暗号化を有効にした場合でもスループット パフォーマンスの低下が非常にわずか (1% 未満) であることが繰り返し示されているため、すべての MinIO 展開で保存時に暗号化を使用し、すべての MinIO 展開で TLS を使用してネットワーク通信を保護することをお勧めします。おめでとうございます。これで、あなたのデータはより安全でありながら透明性のあるシステム上に置かれ、完全な制御と責任を負うことができます。

AWS S3 から Equinix Metal の MinIO への移行についてご質問がある場合は、必ずSlackでご連絡ください。