MinIO と SystemD によるクラウド ストレージ デプロイメントの自動化

MinIO は、高性能、大規模なスケーラビリティ、高可用性を提供し、業界標準の S3 プロトコルに準拠しているため、最も広く実装されているオブジェクト ストアの 1 つです。 MinIO は驚異的なパフォーマンスを実現します。 最近のベンチマークでは、わずか 32 ノードの既製 NVMe SSD で GET で 325 GiB/s (349 GB/s)、PUT で 165 GiB/s (177 GB/s) を達成しました。ベアメタル、仮想インスタンス、Kubernetes など、どこで MinIO を実行しても、MinIO のパフォーマンスとスケーラビリティは、データ レイク、分析、AI/ML などのクラウドネイティブ アプリケーションに優れた基盤を提供します。

Kubernetes に加えて、顧客は仮想インスタンスとベアメタルで MinIO を実行し、データセンターやAWS 、 GCP 、 AzureなどのクラウドのSupermicro ハードウェアに頻繁に依存しています。 Linux は設置面積が小さく、リソースを効率的に利用できるため、MinIO を実行するための多用途かつ柔軟な選択肢となります。しかし、Linux マシンとインスタンスの数が増えると、管理負担を軽減するために自動化が必要になります。 SystemD を使用して MinIO サーバーを init サービスとして管理する必要があるのは、サービスのライフサイクル、特に起動、シャットダウン、再起動時の自動化に役立つためです。

SystemD は、起動、シャットダウン、初期化などの際に Linux システムのサービスを維持するサービス マネージャーです。これは、最初からすべてを記述する必要があった init スクリプトの後継と考えてください。ただし、SystemD を使用すると、いくつかのパラメーターを入力するだけで、コマンドとログが標準化されます。

古い init.d サービス管理を使用する際のいくつかの課題の 1 つは、ファイル全体を最初から作成する必要があることでした。各 init.d ファイルは固有であり、サービスのライフサイクルを管理する異なる方法がありました。 SystemD は init.d から学んだ教訓を取り入れ、それらを標準化します。たとえば、SystemD サービス ファイルは、実行するように記述されている限り、どのサービスでも機能します。パス、名前、セマンティクスが異なるだけですが、基本的な構造、サービスの再起動方法、ログの読み取り、ファイルシステムの正常なアンマウント、待機方法などは異なります。ネットワーク接続の確立などは、現在ではすべてのサービスで共通であるため、どのサービスを実行している場合でも、そのログをどこで探せばよいのかが正確にわかります。

SystemD はさまざまなサービス間で汎用性があるだけでなく、オペレーティング システムがサービスのライフサイクルを管理するために SystemD を使用している限り、同じ SystemD サービス ファイルを複数のオペレーティング システム間で使用できます。これにより、初期ファイルの作成中に Ubuntu で作業できるため自動化が簡素化されますが、パスやその他のものが同じであれば、同じファイルを CentOS/RedHat オペレーティング システムにデプロイできます (ほとんどの場合、そうなります)。

SystemD にはいくつかの主要なコンポーネントがありますが、よく目にするものは次のとおりです。

• systemctl : これは、主にプロセスを停止、開始、再起動するかどうかを制御するために使用されます。最も一般的に使用されるコマンドは次のとおりです。

  • systemctl start <service>

  • systemctl stop <service>

  • systemctl restart <service>

    
    

• journalctl: サービスの起動、シャットダウン、および再起動の操作を実行するときのログ。これは、何かが正しく動作していない場合に洞察を得る良い方法です。私が使用する最も一般的なコマンドは、ターミナル ウィンドウをいっぱいにするのに十分なログを表示し、最後までスクロールします。

  • journalctl -e -u <service>

    
    

このガイドのほとんどのコマンドを実行するには、「sudo」または root アクセス権が必要です。これは、SystemD 構成ファイルが root として許可されている必要があるためです。

MinIO と SystemD の追加手順については、リポジトリで見つけることができます。

MinIO バイナリ

• アップストリームから MinIO バイナリをフェッチする

# wget https://dl.min.io/server/minio/release/linux-amd64/minio --2022-07-24 11:31:33-- https://dl.min.io/server/minio/release/linux-amd64/minio Resolving dl.min.io (dl.min.io)... 132.68.11.115, 138.118.66.212 Connecting to dl.min.io (dl.min.io)|132.68.11.115|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 96649216 (92M) [application/octet-stream] Saving to: 'minio' minio 100%[==========================================>] 92.17M 50.2MB/s in 1.8s 2022-07-24 11:31:35 (50.2 MB/s) - 'minio' saved [96649216/96649216]

• SystemD が MinIO をサービスとして実行できるように実行可能にします。

 # chmod +x minio

• $PATH # mv minio /usr/local/bin/配下で実行可能な場所に移動します。

サービスファイル

MinIO は、オペレーティング システムに基づいて、いくつかの異なる方法で Linux にインストールできます。 RedHat/CentOS とその派生製品は .rpm パッケージに依存し、Debian/Ubuntu は .deb パッケージを使用します。どちらの場合も、次の SystemD サービス ファイルがインストール パッケージに含まれています。

ただし、アップストリームから MinIO バイナリを手動で取得したため、SystemD サービス ファイルを手動で作成します。

• お気に入りのテキスト エディタを使用して、次の内容の SystemD ファイルを/etc/systemd/system/minio.serviceに作成します。

 [Unit] Description=MinIO Documentation=https://docs.min.io Wants=network-online.target After=network-online.target AssertFileIsExecutable=/usr/local/bin/minio [Service] WorkingDirectory=/usr/local User=minio-user Group=minio-user ProtectProc=invisible EnvironmentFile=-/etc/default/minio ExecStartPre=/bin/bash -c "if [ -z \"${MINIO_VOLUMES}\" ]; then echo \"Variable MINIO_VOLUMES not set in /etc/default/minio\"; exit 1; fi" ExecStart=/usr/local/bin/minio server $MINIO_OPTS $MINIO_VOLUMES # Let systemd restart this service always Restart=always # Specifies the maximum file descriptor number that can be opened by this process LimitNOFILE=65536 # Specifies the maximum number of threads this process can create TasksMax=infinity # Disable timeout logic and wait until process is stopped TimeoutStopSec=infinity SendSIGKILL=no [Install] WantedBy=multi-user.target # Built for ${project.name}-${project.version} (${project.name})

• Group=minio-user : Minio デーモンが実行される Linux システム グループ。次のコマンドを使用して作成します。

  
  

  • groupadd -r minio-user

    
    

• User=minio-user : MinIO デーモンを実行する Linux システム ユーザー。次のコマンドを使用してユーザーを作成します。

  
  

  • useradd -M -r -g minio-user minio-user
    • -M : これはサービスであるため、ユーザーのホーム ディレクトリを作成できなくなります。
    • -r : システム ユーザーには追跡目的で個別の UID/GID 範囲があり、このフラグは事前に定義された範囲からユーザーを作成します。
    • -g <group_name> : ユーザーを追加するグループ。

  
  

MinIO

分散セットアップ

MinIO サービスを開始する前に、ベア メタル ノード上でセットアップする必要がある前提条件がいくつかあります。

• 次のメッセージが表示されないように、新しいディスクを作成し、それがルート ボリュームと同じパーティション上にないことを確認します。

  • Error: Disk /mnt/disk1/minio is part of root disk, will not be used

    
    

• 新しいディスクがマウントされたばかりのローカル ホスト上に 4 つのディレクトリを作成します (この場合は/mnt/data )。

 mkdir -p /mnt/data/disk1 \ mkdir -p /mnt/data/disk2 \ mkdir -p /mnt/data/disk3 \ mkdir -p /mnt/data/disk4

• MinIO ユーザーとグループを含むディレクトリchown
  • chown minio-user:minio-user /mnt/data/disk1 /mnt/data/disk2 /mnt/data/disk3 /mnt/data/disk4

環境サービスファイル

• このファイル/etc/default/minio次の内容で更新します

# Set the hosts and volumes MinIO uses at startup # The command uses MinIO expansion notation {x...y} to denote a # sequential series. # # The following example covers four MinIO hosts # with 4 drives each at the specified hostname and drive locations. # The command includes the port that each MinIO server listens on # (default 9000) MINIO_VOLUMES="https://minio1.example.com:9000/mnt/data/disk{1...4}/minio" # Set all MinIO server options # # The following explicitly sets the MinIO Console listen address to # port 9001 on all network interfaces. The default behavior is dynamic # port selection. MINIO_OPTS="--console-address :9001" # Set the root username. This user has unrestricted permissions to # perform S3 and administrative API operations on any resource in the # deployment. # # Defer to your organizations requirements for superadmin user name. MINIO_ROOT_USER=minioadmin # Set the root password # # Use a long, random, unique string that meets your organizations # requirements for passwords. MINIO_ROOT_PASSWORD=minioadmin # Set to the URL of the load balancer for the MinIO deployment # This value *must* match across all MinIO servers. If you do # not have a load balancer, set this value to to any *one* of the # MinIO hosts in the deployment as a temporary measure. MINIO_SERVER_URL="https://minio.example.net:9000"

MinIO プロセスを開始する

• サービスを有効にして開始するために必要な要素がすべて揃っています

# systemctl enable minio.service # systemctl start minio.service

• サービスとログのステータスを確認する

# systemctl status minio.service # journalctl -e -u minio.service

• MinIO サービスが起動していることを確認します。ログには次のような内容が表示されるはずです。

 Aug 01 13:27:06 aj-test-3 systemd[1]: Starting MinIO... Aug 01 13:27:06 aj-test-3 systemd[1]: Started MinIO. Aug 01 13:27:07 aj-test-3 minio[3241]: Formatting 1st pool, 1 set(s), 4 drives per set. Aug 01 13:27:07 aj-test-3 minio[3241]: WARNING: Host minio1.example.com:9000 has more than 2 drives of set. A host fai> Aug 01 13:27:07 aj-test-3 minio[3241]: You are running an older version of MinIO released 4 days ago Aug 01 13:27:07 aj-test-3 minio[3241]: Update: Run `mc admin update` Aug 01 13:27:07 aj-test-3 minio[3241]: MinIO Object Storage Server Aug 01 13:27:07 aj-test-3 minio[3241]: Copyright: 2015-2022 MinIO, Inc. Aug 01 13:27:07 aj-test-3 minio[3241]: License: GNU AGPLv3 <https://www.gnu.org/licenses/agpl-3.0.html> Aug 01 13:27:07 aj-test-3 minio[3241]: Version: RELEASE.2022-07-26T00-53-03Z (go1.18.4 linux/amd64) Aug 01 13:27:07 aj-test-3 minio[3241]: Status: 4 Online, 0 Offline. Aug 01 13:27:07 aj-test-3 minio[3241]: API: https://minio.example.net:9000 Aug 01 13:27:07 aj-test-3 minio[3241]: Console: http://10.128.0.4:9001 http://127.0.0.1:9001 Aug 01 13:27:07 aj-test-3 minio[3241]: Documentation: https://docs.min.io

コンソールにログインする

ブラウザを使用し、前に作成した構成のMINIO_ROOT_USERとMINIO_ROOT_PASSWORDを使用して MinIO コンソールにログインします。

 http://<server_host_ip>:9001/ 

上記のセットアップは、MinIO をすぐに起動して実行できるようにするためのものであることに注意してください。追加のテストのために、単一ノードからマルチノード分散構成に拡張できます。 MinIO を運用環境に展開して構成したい場合は、 ドキュメントを参照してください。

SystemD は MinIO 仮想およびベアメタル展開を簡素化します

SystemD との統合は非常に多用途です。

• サービス ファイルの構文はすべてのサービスで同じです

• 同じサービス ファイルは、SystemD をサポートするすべての OS で動作します。

• SystemD は、ベアメタルまたは AWS、GCP、Azure などのクラウド内の VM で使用できます。

• これにより、形式が標準化され、デプロイメントの自動化が簡単になるため、DevOps の自動化に役立ちます。

  
  

自動化は、オブジェクト ストレージなどのミッション クリティカルなサービスを実行する際の可用性の維持に大きく役立ちます。自動化は、複数のクラウドや環境にわたって大規模に運用するための要件です。 SystemD と MinIO を利用すると、クラウド オブジェクト ストレージの展開を自動化し、サービスのライフサイクルをスムーズかつ適切に管理できます。

質問がありますか?始めてみませんか? Slackでご連絡ください。