ACK Fluid に基づいたハイブリッドクラウドの最適化されたデータアクセス (4): サードパーティのストレージディレクトリを Kubernetes にマウントして、効率と標準化を向上させます。

作者: チェヤン

以前のレビュー:

このシリーズでは、ACK Fluid に基づいてハイブリッドクラウドデータアクセスシナリオをサポートおよび最適化する方法を紹介します。関連記事を参照してください。

-ACK Fluidに基づくハイブリッドクラウド最適化データアクセス (1): シナリオとアーキテクチャ

-ACK Fluid に基づいたハイブリッドクラウド最適化データアクセス (2): エラスティックコンピューティングインスタンスとサードパーティストレージ間のブリッジの構築

- ACK Fluid に基づいたハイブリッドクラウドの最適化されたデータアクセス (3): サードパーティストレージへの読み取りアクセスを高速化し、コストを削減し、並行して効率を向上させます。

前回の記事「サードパーティストレージへの読み取りアクセスを高速化し、コストを削減し、並行して効率を向上させる」では、サードパーティストレージアクセスを高速化して、パフォーマンスの向上、コストの削減、専用線の安定性への依存を軽減する方法を紹介しました。

一部の顧客シナリオでは、歴史的な理由と、コンテナストレージインターフェイスの開発とメンテナンスのコストにより、標準の CSI インターフェイスの使用を選択せず、自動スクリプトなどの非コンテナ化方法を使用します。ただし、クラウドを導入すると、標準インターフェイスに基づいてクラウドサービスに接続する方法を検討する必要があります。

この記事では、ACK Fluid を使用してサードパーティのストレージホストディレクトリを Kubernetes にマウントし、より標準化し、効率を高める方法に焦点を当てます。

概要

多くの企業は、歴史的な理由や技術的なクラウドストレージオプションにより CSI プロトコルをサポートしておらず、ansible などの運用保守ツールを介したホストディレクトリへのマウントのみをサポートしていますが、一方で、Kubernetes 標準化プラットフォームとの接続には課題があります。その一方で、前の記事と同様のパフォーマンスとコストの問題に対処する必要もあります。

標準化の欠如とクラウド移行の難しさ:ホストディレクトリのマウントモードは Kubernetes によって認識およびスケジュールされないため、コンテナ化されたワークロードの使用と管理が困難になります。
データ分離の欠如:ディレクトリ全体がホストにマウントされ、すべてのワークロードによってアクセスされるため、データはグローバルに表示されます。
データアクセスには、コスト、パフォーマンス、可用性の点でシナリオ 2 と同じ要件があるため、詳細は説明しません。

ACK Fluid は、JindoRuntime [ 1]に基づいた PV ホストディレクトリの一般的な高速化機能を提供し、ホストディレクトリのマウントを直接サポートし、分散キャッシュを通じてネイティブ、簡単、迅速、安全にデータアクセス高速化機能を取得できます。

1. 従来のアーキテクチャをクラウドネイティブの適応アーキテクチャに移行します。ホストディレクトリのマウントモードを、Kubernetes によって管理できる CSI プロトコルに基づく PV ストレージボリュームに変更して、標準化されたプロトコルを通じてパブリッククラウドとの統合を促進します。

2. 従来のアーキテクチャの移行は低コストです。ホストディレクトリをマウントするだけで済み、追加の開発を必要とせずにすぐに使用できます。展開時にホストパスプロトコルを PV ストレージボリュームに変換するだけで済みます。

3. データを分離できる: Fluid のサブデータセットモードでは、さまざまなユーザーの可視性をさまざまなオフラインストレージディレクトリに分離できます。

4. 「サードパーティストレージへの読み取りアクセスを高速化し、コストを削減し、並行して効率を向上させる」と同じパフォーマンス、コスト、自動化、およびキャッシュフリーのデータ配置の利点を提供できます。

概要: ACK Fluidは、クラウドコンピューティングがサードパーティストレージのホストディレクトリマウント方法にアクセスするための、すぐに使える高性能、低コスト、自動化されたデータフリーのディスクマウント方法を提供します。

デモ

1. 前提条件

ACK Pro バージョンのクラスターが作成されており、クラスターのバージョンは 1.18 以降です。特定の操作については、「ACK Pro Edition クラスターの作成[ 2]」を参照してください。
クラウドネイティブ AI スイートがインストールされ、ack-fluid コンポーネントがデプロイされました。重要:オープンソースの Fluid をインストールしている場合は、ack-fluid コンポーネントをデプロイする前にアンインストールしてください。

クラウドネイティブ AI スイートがインストールされていません:インストール中に流体データアクセラレーションを有効にします。特定の操作については、「Cloud Native AI Suite のインストール[ 3]」を参照してください。
クラウドネイティブ AI スイートがインストールされています。 Container Service 管理コンソールのクラウドネイティブ AI スイートページにack-fluidをデプロイします。

ACK クラスターは kubectl を介して接続されています。特定の操作については、「kubectl ツールを使用したクラスターへの接続[ 4]」を参照してください。
アクセスする必要があるストレージシステムに対応する PV ストレージボリュームおよび PVC ストレージボリューム要求が作成されています。Kubernetes環境では、ストレージシステムごとにストレージボリュームの作成方法が異なるため、ストレージシステムとKubernetesクラスタ間の接続を安定させるために、対応するストレージシステムの公式ドキュメントに従って準備してください。

2. ホストディレクトリのマウントポイントを準備する

この例では、sshfs を使用してサードパーティのストレージをシミュレートし、流体を通じてデータ量宣言に変換し、アクセス高速化を実装します。

2.1 まず、192.168.0.1、192.168.0.2、192.168.0.3の3台のマシンにログインし、それぞれsshfsサービスをインストールしますここではCentOSを例に、以下のコマンドを実行します。

$ sudo yum install sshfs -y

2.2 sshfsサーバー192.168.0.1にログインし、以下のコマンドを実行し、/mntディレクトリにホストディレクトリのマウントポイントとして新しいサブディレクトリを作成し、テストファイルを作成します。

$ mkdir /mnt/demo-remote-fs
$ cd /mnt/demo-remote-fs
$ dd if=/dev/zero of=/mnt/demo-remote-fs/allzero-demo count=1024 bs=10M

2.3 次のコマンドを実行して、2 つの sshfs クライアントノード 192.168.0.2 および 192.168.0.3 に対応するホストディレクトリを作成します。

$ mkdir /mnt/demo-remote-fs
$ sshfs 192.168.0.1:/mnt/demo-remote-fs /mnt/demo-remote-fs
$ ls /mnt/demo-remote-fs

2.4 次のコマンドを実行して、192.168.0.2 および 192.168.0.3 ノードにラベルを付けます。タグdemo-remote-fs=trueは、JindoRuntimeのマスターおよびワーカーコンポーネントのノードスケジュール制約を設定するために使用されます。

$ kubectl label node 192.168.0.2 demo-remote-fs=true
$ kubectl label node 192.168.0.3 demo-remote-fs=true

2.5 192.168.0.2 を選択し、次のコマンドを実行してデータにアクセスし、ファイルアクセスのパフォーマンスを評価します。10G ファイルのコピーには 1 分 5.889 秒かかります。

$  ls -lh /mnt/demo-remote-fs/
total 10G
-rwxrwxr-x 1 root root 10G Aug 13 10:07 allzero-demo
$ time cat /mnt/demo-remote-fs/allzero-demo > /dev/null

real  1m5.889s
user  0m0.086s
sys  0m3.281s

3. 流体データセットと JindoRuntime を作成する

次の YAML を使用して、dataset.yaml ファイルを作成します。

以下の dataset.yaml 構成ファイルには、作成される 2 つの Fluid リソースオブジェクト、つまり Dataset と JindoRuntime が含まれています。

データセット: マウントされるホストディレクトリ情報。
JindoRuntime: 開始される JindoFS 分散キャッシュシステム構成 (キャッシュシステムワーカーコンポーネントのコピー数と各ワーカーコンポーネントの最大利用可能なキャッシュ容量を含む)。

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: hostpath-demo-dataset
spec:
  mounts: 
    - mountPoint: local:///mnt/demo-remote-fs
      name: data
      path: /
  accessModes:
    - ReadOnlyMany
---
apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: hostpath-demo-dataset
spec:
  master:
    nodeSelector:
      demo-remote-fs: "true"
  worker:
    nodeSelector:
      demo-remote-fs: "true"
  fuse:
    nodeSelector:
      demo-remote-fs: "true"
  replicas: 2
  tieredstore:
    levels:
      - mediumtype: MEM
        path: /dev/shm
        quota: 10Gi
        high: "0.99"
        low: "0.99"

設定ファイル内のリソースオブジェクトの詳細パラメータについては、以下で説明します。

3.1 次のコマンドを実行して、Dataset および JindoRuntime リソースオブジェクトを作成します。

$ kubectl create -f dataset.yaml

3.2 以下のコマンドを実行してデータセットの配備状況を確認します。

$ kubectl get dataset hostpath-demo-dataset

期待される出力:

NAME                    UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
hostpath-demo-dataset   10.00GiB         0.00B    20.00GiB         0.0%                Bound   47s

3.3 データセットはバインド状態にあります。これは、JindoFS キャッシュシステムがクラスター内で正常に起動されており、アプリケーションポッドがデータセットで定義されたデータに正常にアクセスできることを示します。

4. キャッシュのウォームアップを実行するための DataLoad を作成します。

最初のアクセスではデータキャッシュにヒットしないため、アプリケーション Pod のデータアクセス効率が低い可能性があります。Fluid は、最初のデータアクセスの効率を向上させるために DataLoad キャッシュのウォームアップ操作を提供します。

4.1 dataload.yaml ファイルを作成するコード例は次のとおりです。

apiVersion: data.fluid.io/v1alpha1
kind: DataLoad
metadata:
  name: dataset-warmup
spec:
  dataset:
    name: hostpath-demo-dataset
    namespace: default
  loadMetadata: true
  target:
    - path: /
      replicas: 1

上記のリソースオブジェクトの詳細なパラメータの説明は次のとおりです。

4.2 次のコマンドを実行して、DataLoad オブジェクトを作成します。

$ kubectl create -f dataload.yaml

4.3 以下のコマンドを実行して、DataLoad の状態を確認します。

$ kubectl get dataload dataset-warmup

期待される出力:

NAME             DATASET                 PHASE      AGE   DURATION
dataset-warmup   hostpath-demo-dataset   Complete   96s   1m2s

4.4 以下のコマンドを実行してデータキャッシュの状態を確認します。

$ kubectl get dataset

期待される出力:

NAME                    UFS TOTAL SIZE   CACHED     CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
hostpath-demo-dataset   10.00GiB         10.00GiB   20.00GiB         100.0%              Bound   157m

DataLoad キャッシュのウォームアップ操作が完了すると、データセットのキャッシュデータ量 CACHED がデータセット全体のサイズに更新されます。これは、データセット全体がキャッシュされたことを意味し、キャッシュパーセンテージ CACHED PERCENTAGE は次のようになります。 100.0%。

5. データウォームアップ後のアクセスパフォーマンスを確認する

5.1 次の YAML を使用して pod.yaml ファイルを作成し、YAML ファイル内のclaimName 名をこの例で作成したデータセットの名前と同じになるように変更します。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx
      command:
      - "bash"
      - "-c"
      - "sleep inf"
      volumeMounts:
        - mountPath: /data
          name: data-vol
  volumes:
    - name: data-vol
      persistentVolumeClaim:
        claimName: hostpath-demo-dataset # 名称需要与Dataset相同。

5.2 以下のコマンドを実行してアプリケーション Pod を作成します。

kubectl create -f pod.yaml

5.3 次のコマンドを実行して Pod にログインし、データにアクセスします。

$ kubectl exec -it nginx bash

予想される出力は、10G ファイルのコピーにかかる時間は 0m8.629s であり、sshfs の直接リモートコピーにかかる時間 (1m5.889s) の 1/8 です。

root@nginx:/# ls -lh /data
total 10G
-rwxrwxr-x 1 root root 10G Aug 13 10:07 allzero-demo
root@nginx:/# time cat /data/allzero-demo > /dev/null

real  0m8.629s
user  0m0.031s
sys  0m3.594s

5.4 クリーンアプリケーションポッド

$ kubectl delete po nginx