|
CubeFS は、S3、HDFS、POSIX などのアクセス プロトコルをサポートし、マルチレプリカと消去コードの 2 つのストレージ エンジンをサポートし、マルチテナント、マルチ AZ デプロイメント、クロスリージョン レプリケーションなどの複数の機能をユーザーに提供する、新世代のクラウドネイティブ ストレージ システムです。 CubeFS はクラウドネイティブの分散ストレージ プラットフォームとして、さまざまなアクセス プロトコルを提供するため、そのアプリケーション シナリオも非常に幅広くなっています。以下では、いくつかの典型的なアプリケーション シナリオを簡単に紹介します。 - ビッグデータ分析: HDFS プロトコルと互換性があり、Hadoop エコシステム (Spark や Hive など) の統合ストレージ ベースを提供し、コンピューティング エンジンに無制限のストレージ スペースと高帯域幅のデータ ストレージ機能を提供します。
- ディープトレーニング/機械学習: 分散並列ファイルシステムとして、AI トレーニング、モデルの保存と配布、IO アクセラレーションなどのニーズをサポートします。
- コンテナ共有ストレージ: コンテナ クラスターは、コンテナ イメージの構成ファイルや初期化ロード データを CubeFS 上に保存し、コンテナがバッチでロードされるときにリアルタイムで読み取ることができます。複数のポッドが CubeFS を通じて永続データを共有し、ポッドに障害が発生した場合に高速フェイルオーバーを実行できます。
- データベースとミドルウェア: MySQL、ElasticSearch、ClickHouse などのデータベース アプリケーション向けに、高同時実行性と低レイテンシのクラウド ディスク サービスを提供して、ストレージとコンピューティングの完全な分離を実現します。
- オンライン サービス: オンライン ビジネス (広告、クリックストリーム、検索など) やエンド ユーザーの画像、テキスト、オーディオ、ビデオ コンテンツ向けに、信頼性が高く低コストのオブジェクト ストレージ サービスを提供します。
- 従来の NAS をクラウドへ: オフラインの従来のローカル ストレージと NAS を置き換えて、IT サービスをクラウドに移行できるようにします。
特性CubeFS には次のような多くの機能があります: マルチプロトコルS3、POSIX、HDFSなどの複数のアクセスプロトコルと互換性があり、プロトコル間のアクセスは相互運用可能です。 - POSIX 互換性: POSIX インターフェイスと互換性があるため、上位層アプリケーションの開発が非常に簡単になり、ローカル ファイル システムを使用するのと同じくらい便利です。さらに、CubeFS は、ファイル操作とメタファイル操作のパフォーマンスのバランスをとるために、実装における POSIX セマンティクスの一貫性要件を緩和します。
- オブジェクト ストレージの互換性: AWS の S3 オブジェクト ストレージ プロトコルと互換性があるため、ユーザーはネイティブの Amazon S3 SDK を使用して CubeFS のリソースを管理できます。
- Hadoop プロトコルの互換性: Hadoop FileSystem インターフェース プロトコルと互換性があります。ユーザーは CubeFS を使用して HDFS を置き換えることができ、上位レベルのビジネスに意識させる必要はありません。
ツインエンジンマルチコピーと消去コードの 2 つのエンジンをサポートします。ユーザーはビジネスシナリオに応じて柔軟に選択できます - マルチコピー ストレージ エンジン: レプリカ間のデータはミラーリング関係にあります。レプリカ間のデータの一貫性を確保するために、強力な一貫性のあるレプリケーション プロトコルが使用されます。ユーザーは、アプリケーションのシナリオに基づいて、さまざまな数のレプリカを柔軟に構成できます。
- 消去コード ストレージ エンジン: 消去コード エンジンは、高い信頼性、高い可用性、低コスト、超大規模 (EB) のサポートなどの特性を備えています。消去コードモードは、さまざまな AZ モデルに応じて柔軟に選択できます。
マルチテナントマルチテナント管理をサポートし、きめ細かなテナント分離戦略を提供します スケーラブルPB や EB 規模の分散ストレージ サービスを容易に構築でき、各モジュールを水平に拡張できます。 高性能マルチレベルキャッシュ、小さなファイル向けの特定の最適化をサポートし、複数の高性能レプリケーションプロトコルをサポートします。 - メタデータ管理: メタデータ クラスターは、メモリ内のメタデータ ストレージです。 2 つの B ツリー (inodeBTree と dentryBTree) を使用してインデックスを管理し、メタデータ アクセスのパフォーマンスを向上させるように設計されています。
- 強力な一貫性レプリケーション プロトコル: CubeFS は、さまざまなファイル書き込み方法に応じて異なるレプリケーション プロトコルを使用して、レプリカ間のデータの一貫性を確保します。 (ファイルが順番に書き込まれる場合は、IO スループットを最適化するためにマスター スレーブ レプリケーション プロトコルが使用されます。ファイルがランダムに書き込まれて既存のファイル コンテンツを上書きする場合は、強力なデータ一貫性を確保するために Multi-Raft ベースのレプリケーション プロトコルが使用されます)。
- マルチレベル キャッシュ: 消去コード化ボリュームはマルチレベル キャッシュ アクセラレーション機能をサポートし、ホット データに対してより高いデータ アクセス パフォーマンスを提供します。
- ローカル キャッシュ: BlockCache コンポーネントをクライアント マシンに展開し、ローカル ディスクをローカル キャッシュとして使用できます。ローカル キャッシュはネットワークを経由せずに直接読み取ることができますが、容量はローカル ディスクによって制限されます。
- グローバル キャッシュ: レプリカ コンポーネント DataNode を使用して構築された分散グローバル キャッシュ。たとえば、SSD ディスクを備えた DataNode を、クライアントと同じコンピューター ルームにグローバル キャッシュとして展開できます。ローカル キャッシュと比較すると、ネットワークを経由する必要がありますが、容量が大きく、動的に拡張および縮小でき、レプリカの数を調整できます。
クラウドネイティブCSI プラグインに基づいて、CubeFS を Kubernetes 上ですぐに使用できます。 全体的なアーキテクチャ全体として、CubeFS はメタデータ サブシステム、データ サブシステム、リソース管理ノード (マスター)、およびオブジェクト ゲートウェイ (オブジェクト サブシステム) で構成され、POSIX/HDFS/S3 インターフェイスを介して保存されたデータにアクセスできます。 リソース管理ノード複数のマスターノードで構成され、データシャードとメタデータシャードの管理（作成、削除、更新、整合性チェックを含む）、データノードまたはメタデータノードのヘルスステータスのチェック、ボリューム情報の維持と管理など、さまざまな種類のタスクを非同期的に処理する役割を担います。 マスターノードは複数存在できます。ノード間でメタデータの一貫性を確保し、それを永続化するためにラフトアルゴリズムが使用されます。 RocksDB 真ん中。
メタデータサブシステム複数のメタノード、複数のメタデータシャード (メタパーティション)、および Raft インスタンス (Multi-Raft レプリケーションプロトコルに基づく) で構成されます。各メタデータ シャードは、inode BTree と dentry BTree という 2 つのメモリ B ツリーを含む Inode 範囲メタデータを表します。 最低 3 つのメタデータ インスタンスが必要であり、水平拡張がサポートされています。
データサブシステムこれはレプリカ サブシステムと消去コード サブシステムに分かれています。両方のサブシステムは同時に存在することも、別々に存在することもできます。 - レプリカ サブシステムは DataNode で構成されます。各ノードはデータ シャードのセットを管理します。複数のノードのデータ シャードがレプリカ グループを構成します。
- 消去コードサブシステム (Blobstore) は、主に BlobNode モジュールで構成されています。各ノードはデータ ブロックのグループを管理し、複数のノードのデータ ブロックが消去コード ストライプを構成します。
データ ノードは水平方向の拡張をサポートします。
オブジェクトサブシステムこれはオブジェクト ノード (ObjectNode) で構成され、標準の S3 セマンティクスと互換性のあるアクセス プロトコルを提供します。ストレージ リソースには、Amazon S3 SDK や s3cmd などのツールを通じてアクセスできます。 ロール複数のメタデータとデータ シャードで構成される論理概念。クライアントの観点から見ると、ボリュームはコンテナーにアクセス可能なファイル システム インスタンスとして表示されます。オブジェクト ストレージの観点から見ると、ボリュームはバケットに対応します。ボリュームは複数のコンテナにマウントできるため、異なるクライアントが同時にファイルにアクセスできるようになります。 インストールCubeFS をインストールする方法は、Docker、YUM など、多数あります。ここでは Kubernetes 上で直接使用するため、Helm 経由で CubeFS をインストールできます。各コンポーネントはホスト ネットワークを直接使用し、hostPath を使用してディスクをコンテナーにマップします。 CubeFS は、次の図に示すアーキテクチャに従って Kubernetes クラスターにデプロイできます。 CubeFS は現在、次の 4 つの部分で構成されています。 - マスター: クラスター全体のメタデータを維持し、StatefulSet リソースとしてデプロイされるリソース管理ノード。
- DataNode: ファイル データの実際の保存を担当するために多数のディスクをマウントする必要があり、DaemonSet リソースとしてデプロイされるデータ ストレージ ノード。
- MetaNode: DaemonSet リソースとしてデプロイされる、すべてのファイル メタデータを保存するメタデータ ノード。
- ObjectNode: S3 プロトコルを変換してオブジェクト ストレージを提供する機能を提供します。これはステートレス サービスであり、デプロイメント リソースとしてデプロイされます。
デプロイする前に、少なくとも 3 つのノード (災害復旧のためには 4 つ以上が望ましい) を持つ Kubernetes クラスターが必要であり、クラスターのバージョンは 1.15 以上である必要があります。 $ kubectl get nodes NAME STATUS ROLES AGE VERSION master Ready control-plane 46d v1.28.7 node1 Ready <none> 46d v1.28.7 node2 Ready <none> 46d v1.28.7 まず、CubeFS クラスター内でマシンが果たす役割を示すために、ノードにラベルを付ける必要があります。 ここにはノードが 3 つしかないため、これらのノードがいくつかの共通の役割を担う必要があります。
- マスターノードは少なくとも 3 つ、奇数が推奨されます。
kubectl label node master component.cubefs.io/master=enabled kubectl label node node1 component.cubefs.io/master=enabled kubectl label node node2 component.cubefs.io/master=enabled - MetaNode メタデータ ノードは少なくとも 3 つ、奇数か偶数かは関係ありません。
kubectl label node master component.cubefs.io/metanode=enabled kubectl label node node1 component.cubefs.io/metanode=enabled kubectl label node node2 component.cubefs.io/metanode=enabled - データノード データノード、少なくとも 3、パリティは関係ありません。
kubectl label node master component.cubefs.io/datanode=enabled kubectl label node node1 component.cubefs.io/datanode=enabled kubectl label node node2 component.cubefs.io/datanode=enabled - ObjectNode オブジェクト ストレージ ノードは必要に応じてマークできます。オブジェクト ストレージ機能が不要な場合は、このコンポーネントをデプロイしないこともできます。
kubectl label node node1 component.cubefs.io/objectnode=enabled kubectl label node node2 component.cubefs.io/objectnode=enabled - Kubernetes で CubeFS を使用するために使用される CSI コンポーネントは、すべてのノードにデプロイする必要があります。
kubectl label node node1 component.cubefs.io/csi=enabled kubectl label node node2 component.cubefs.io/csi=enabled CubeFS をインストールすると、これらのラベルは nodeSelector を通じて照合され、対応する Pod がマシン上に作成されます。 次に、Helm 経由で CubeFS をインストールします。まず、CubeFS の Helm Chart をローカル コンピューターにダウンロードする必要があります。 git clone https://github.com/cubefs/cubefs-helm cd cubefs-helm 次に、環境に応じて値ファイルをカスタマイズします。たとえば、次のものは単純な値ファイルです。 # cubefs-values.yaml component: master: true datanode: true metanode: true objectnode: false client: false csi: true monitor: false ingress: true image: # 3.3.0 版本之前会出现/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found 错误server: cubefs/cfs-server:v3.3.0 client: cubefs/cfs-client:v3.3.0 csi_driver: cnych/cubefs-cfs-csi-driver:3.2.0.150.0 csi_provisioner: cnych/csi-provisioner:v2.2.2 csi_attacher: cnych/csi-attacher:v3.4.0 csi_resizer: cnych/csi-resizer:v1.3.0 driver_registrar: cnych/csi-node-driver-registrar:v2.5.0 master: # The replicas of master component, at least 3, recommend to be an odd number replicas: 3 tolerations: - key: "node-role.kubernetes.io/control-plane" operator: "Exists" effect: "NoSchedule" resources: enabled: true requests: memory: "512Mi" cpu: "500m" limits: memory: "512Mi" cpu: "500m" metanode: total_mem: "4000000000" tolerations: - key: "node-role.kubernetes.io/control-plane" operator: "Exists" effect: "NoSchedule" resources: enabled: true requests: memory: "512Mi" cpu: "500m" limits: memory: "512Mi" cpu: "500m" datanode: # DataNode 要使用的磁盘，可以挂载多块# 格式: 挂载点:保留的空间# 保留的空间: 单位字节，当磁盘剩余空间小于该值时将不会再在该磁盘上写入数据disks: - /data0:10000000000 tolerations: - key: "node-role.kubernetes.io/control-plane" operator: "Exists" effect: "NoSchedule" resources: enabled: true requests: memory: "512Mi" cpu: "500m" limits: memory: "512Mi" cpu: "500m" csi: driverName: csi.cubefs.com logLevel: error kubeletPath: /var/lib/kubelet controller: tolerations: [] nodeSelector: component.cubefs.io/csi: "enabled" node: tolerations: [] nodeSelector: component.cubefs.io/csi: "enabled" resources: enabled: true requests: memory: "512Mi" cpu: "500m" limits: memory: "512Mi" cpu: "500m" storageClass: setToDefault: false reclaimPolicy: "Delete" # CSI 客户端配置provisioner: # Kubelet 的主目录kubelet_path: /var/lib/kubelet 次に、次のコマンドを使用して CubeFS をデプロイします。 helm upgrade --install cubefs -n cubefs-system ./cubefs-helm/cubefs -f cubefs-values.yaml --create-namespace デプロイが完了したら、コマンド kubectl get pods -n cubefs-system を使用して、すべてのコンポーネントが実行中になるまで待ちます。 $ kubectl get pods -n cubefs-system NAME READY STATUS RESTARTS AGE cfs-csi-controller-66cdbb664f-pqkp6 4/4 Running 0 28m cfs-csi-node-966t9 2/2 Running 0 25m cfs-csi-node-9f4ts 2/2 Running 0 25m datanode-4zfhc 1/1 Running 0 28m datanode-blc8w 1/1 Running 0 28m datanode-ldj72 1/1 Running 0 28m master-0 1/1 Running 0 28m master-1 1/1 Running 0 23m master-2 1/1 Running 0 23m metanode-5csgt 1/1 Running 0 7m31s metanode-jvqnl 1/1 Running 0 7m31s metanode-vpjtj 1/1 Running 0 7m31s 各コンポーネントのキーログはコンテナの標準出力に出力されます。 さらに、StorageClass オブジェクトが自動的に作成され、kubectl get sc を通じて表示できます。 $ kubectl get sc NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE cfs-sc csi.cubefs.com Delete Immediate true 29m テスト使用可能な StorageClass オブジェクトが作成されたので、PVC オブジェクトを作成して CubeFS のストレージ機能をテストできます。以下のように表示されます。 # cubefs-pvc.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: cubefs-pvc namespace: default spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi storageClassName: cfs-sc 上記の PVC オブジェクトでは、storageClassName を通じて使用する StorageClass 名を指定します。ここでは cfs-sc です。この名前は、以前に作成した StorageClass 名と一致している必要があります。これにより、ストレージ ボリュームは、cubefs-sc で定義されたパラメーターに従って作成されます。 pvc yaml を書くときは、次のパラメータに注意する必要があります。 - metadata.name: 必要に応じて変更できる PVC の名前。同じ名前空間内の PVC 名は一意であり、同一の名前を 2 つ持つことはできません。
- metadata.namespace: pvc が配置されている名前空間。必要に応じて変更します。
- spec.resources.request.storage: PVC 容量サイズ。
- storageClassName: ストレージ クラスの名前です。現在のクラスターにどのストレージクラスが含まれているかを確認したい場合は、コマンド kubectl get sc を使用して表示できます。
この yaml ファイルをここに適用するだけです: kubectl apply -f cubefs-pvc.yaml コマンドを実行した後、kubectl get pvc -n namespace コマンドを使用して、対応する pvc のステータスを表示できます。 Pending は待機中を意味し、Bound は作成が成功したことを意味します。 $ kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE cubefs-pvc Bound pvc-53cc95b7-8a05-43f8-8903-f1c6f7b11c05 5Gi RWO cfs-sc 3s PVC ステータスが常に保留中の場合は、次のコマンドで理由を確認できます。 kubectl describe pvc -n 命名空间PVC 名称 エラー メッセージが明確でない場合、またはエラーが見つからない場合は、kubectl logs コマンドを使用して、csi コントローラー ポッド内の csi-provisioner コンテナーのエラー情報を表示できます。 csi-provisioner は、k8s と csi ドライバー間の中間ブリッジです。ここのログでは多くの情報を見ることができます。 csi-provisioner ログで特定の問題が明らかにならない場合は、kubectl exec コマンドを使用して、csi コントローラー ポッド内の cfs-driver コンテナのログを表示します。ログはコンテナ内の /cfs/logs に保存されます。 cfs-driver のログは標準出力に出力されないため、kubectl ログ関連のコマンドはここでは使用できませんが、csi-provisioner などの他のいくつかのサイドカー コンテナーのログは標準出力に出力されるため、kubectl ログ関連のコマンドを使用してそれらを表示できます。 PVC を使用すると、アプリケーション内の指定されたディレクトリにマウントできます。たとえば、次の例を示します。 # cfs-csi-demo.yaml apiVersion: apps/v1 kind: Deployment metadata: name: cfs-csi-demo namespace: default spec: selector: matchLabels: app: cfs-csi-demo-pod template: metadata: labels: app: cfs-csi-demo-pod spec: nodeSelector: component.cubefs.io/csi: enabled containers: - name: cfs-csi-demo image: nginx:1.17.9 imagePullPolicy: "IfNotPresent" ports: - containerPort: 80 name: "http-server" volumeMounts: - mountPath: "/usr/share/nginx/html" mountPropagation: HostToContainer name: mypvc volumes: - name: mypvc persistentVolumeClaim: claimName: cubefs-pvc 上記のリソース リストでは、cubefs-pvc という名前の PVC を cfs-csi-demo コンテナーの /usr/share/nginx/html にマウントします。 このリソース リストを直接作成することもできます。 kubectl apply -f cfs-csi-demo.yaml 作成が完了したら、kubectl get pods で Pod のステータスを確認できます。 $ kubectl get pods -owide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES cfs-csi-demo-5d456c8d97-sjsvw 1/1 Running 0 78s 10.0.1.85 node1 <none> <none> /usr/share/nginx/html ディレクトリにファイルを直接書き込むことで、CubeFS のストレージ機能をテストできます。 $ kubectl exec -it cfs-csi-demo-5d456c8d97-sjsvw -- /bin/bash root@cfs-csi-demo-5d456c8d97-sjsvw:/# echo "Hello, CubeFS" > /usr/share/nginx/html/index.html root@cfs-csi-demo-5d456c8d97-sjsvw:/# 次に、Pod を削除して再構築し、ファイルがまだ存在するかどうかを確認します。 $ kubectl delete pod cfs-csi-demo-5d456c8d97-sjsvw $ kubectl get pods NAME READY STATUS RESTARTS AGE cfs-csi-demo-5d456c8d97-c245z 1/1 Running 0 3m22s $ kubectl exec -it cfs-csi-demo-5d456c8d97-c245z -- ls /usr/share/nginx/html index.html $ kubectl exec -it cfs-csi-demo-5d456c8d97-c245z -- cat /usr/share/nginx/html/index.html Hello, CubeFS Hello, CubeFS が表示されれば、CubeFS のストレージ機能は正常であることを意味します。 | 
