Rook Advent Calendar 2020 — Internal と External Cluster のユースケース
Rook Advent Calendar 2020 の第一回は、Internal Cluster と External Cluster の違いを解説します。External Cluster は Rook 1.1 でリリースされました。Internal Cluster は Kubernetes や OpenShift クラスタ上に Ceph Cluster をデプロイする一方、External Cluster の主な目的はストレージのワークロードを Kubernetes や OpenShift クラスタから分離させることです。
ユースケースと制約
まず双方のユースケースをざっと見てみましょう。なお制約に関しては、アップストリームの Rook をベースとした Red Hat のストレージ製品である OpenShift Container Storage (OCS) を参考にしています。なお OCS では Ceph Cluster の配置について、Internal Approach と External Approach と呼んでいます。
Internal Cluster は Kubernetes クラスタ上に Ceph Cluster を構築するため、コンテナ専用に利用することを前提とするとワークロードを前提とする一方、External Cluster は既存の Ceph Cluster を利用するため、VM などコンテナ以外のワークロードも従来の Ceph Cluster で管理する場合に選択します。ワークロードを混在させるか分離させるかの方針は Kubernetes クラスタの規模、プラットフォーム、従来のストレージの有無などによるため、主にプラットフォームが Public Cloud かオンプレミスで Internal か External Cluster かの選択肢が決まります。例えば Public Cloud でクラスタを運用する際、 プラットフォームが AWS なら EBS が Multi-AZ に対応しないことから、Multi-AZ に対応する OCS を選択するケースが挙げられます。AWS の場合、OCS 用 Node を異なる AZ に分散して配置させることで、AZ 障害に対応します。
次に制約に関して、サポートされる Ceph のバージョンは 12.2 以上 (Red Hat Ceph Storage では 4.11 以上) であることが前提となるため、既存の Ceph Cluster のバージョンが合致しない場合、External Cluster を選択することはできません。その他に Internal Cluster は Ceph Cluster のインストールからアップグレード、また監視を Operator が管理するため、導入や運用面のコストは下がりますが、External Cluster の場合はあくまで外部の Ceph Cluster を利用するため、 Ceph Cluster 自体の運用管理は Operator により自動化はされず、Ceph Cluster の管理者が責任を持ちます。また Internal Cluster を選択する場合、複数の OpenShift クラスタから単一の Ceph Cluster を利用することはサポートされません。そのため、単一の Ceph Cluster を複数のクラスタに利用させたい場合、External Cluster が前提となります。ただしプラットフォームに応じて次のようにサポートが異なります。
Public Cloud では External Mode (Cluster) はサポートされないため、External Cluster を選択できる環境はオンプレミスに限定されます。Internal Cluster では複数の OpenShift クラスタを単一の Ceph Cluster でサポートしないことから、主に数十台など中規模程度のクラスタ管理に適していると考えられます。
OCS でサポートされるプラットフォームや機能の制約は以下で公開されています。
- What is supported in Red Hat OpenShift Storage 4.X?
- Red Hat OpenShift Container Storage and Red Hat OpenShift Container Platform interoperability matrix
システム要求と設定
OCS で Internal と External Cluster で要求されるシステムリソースの違いは次のようになります。Internal Cluster では Ceph Cluster を構築することから相応のリソースが必要になるため、社内などで既存の Ceph Cluster を利用できる環境であれば External Cluster を検討できますが、POC であればプラットフォームや検証の要件に応じて Public Cloud で Internal Cluster を選択する方針も考えられます。そのため、例えばベアメタルを想定した一台の HW で OpenShift クラスタを含めた検証環境を賄うため、Internal Cluster を前提に OCS 用 Node を Compute Node と混在させる場合、最低でも Bootstrap x 1 と Control Plane x 3 台分のリソースが必要になります。
次に Kubernetes や OpenShift クラスタ (Local Cluster) と Ceph Cluster (External Cluster) におけるネットワークに関する要件は次のようになります。
- Local Cluster から External Cluster (Ceph Monitor のエンドポイント) へのアクセス
- External Cluster を管理する Admin ユーザの Keyring
そして Local Cluster から External Cluster へのアクセスに関して、各種 Daemon のエンドポイントにアクセスする必要があります。
- Ceph Monitor (Quorum の監視)
- Ceph Monitor/OSD (クライアントのアクセス)
- Ceph Manager (ダッシュボードへのアクセス)
- Ceph MDS (CephFS へのアクセス)
Rook-Ceph Storage Operator はクライアントである Local Cluster 側で External Cluster の状態を管理するため、CephCluster Custom Resource として Ceph Cluster や OSD の構成情報などを定義します。そのため、各種 Ceph Daemon へのアクセスが必要になります。例えば、共有ファイルシステムは External Cluster で作成されなければいけないため、クライアントである Local Cluster は External Cluster の Ceph MDS にアクセスする必要があります。そして External Cluster を設定する場合、既存の Ceph Cluster にアクセスさせるため、Rook-Ceph Storage Operator (OCS では OpenShift Container Storage Operator) をデプロイした後、環境変数に Ceph Cluster の FSID (UUID)、Ceph Monitor のホスト名または IP アドレスや認証情報などを指定します。OCS では Python スクリプトを実行し Ceph Cluster の情報を JSON 形式で出力した後、JSON ファイルをメタデータとしてインポートします。
まとめ
Internal Cluster は Public Cloud やオンプレミスに対応する一方、External Cluster はオンプレミスに制限されます。また Kubernetes や OpenShift クラスタにストレージを提供する際、複数か単一のクラスタを対象とするかクラスタの規模に応じて、Internal か External Cluster を検討する必要があり、複数クラスタの場合は外部の Ceph Cluster を用いて External Cluster として、ストレージのワークロードを分離させることができます。ただし、ハイブリッドクラウドを想定した複数のプラットフォームに配置されたクラスタから External Cluster を利用する場合、一般的なネットワークのスループットやレイテンシに加えて、クライアントである Kubernetes や OpenShift クラスタから External Cluster である Ceph Cluster の Ceph Monitor など各種エンドポイントにアクセスする必要があるため、ネットワークのセグメンテーションなどセキュリティも考慮する必要があります。
