JindoRuntime は、Alibaba Cloud E-MapReduce (EMR) チームによって開発された JindoFS の実行エンジンです。 JindoRuntime は C++ に基づいており、データセットの管理とキャッシュを提供します。 JindoRuntime は Object Storage Service (OSS) もサポートしています。 Alibaba Cloud は、JindoFS に対するクラウドサービスレベルのサポートを提供しています。 Fluid は、JindoRuntime を管理およびスケジューリングすることにより、データセットの可観測性、自動スケーリング、および移植性を実現します。 このトピックでは、JindoFS を使用して OSS へのアクセスを高速化する方法について説明します。
前提条件
non-containerOS を使用した Container Service for Kubernetes (ACK) Pro マネージドクラスターが作成されており、クラスターの Kubernetes バージョンは 1.18 以降です。 詳細については、「ACK マネージドクラスターを作成する」をご参照ください。
重要ack-fluid コンポーネントは、現在 ContainerOS ではサポートされていません。
クラウドネイティブ AI スイートがインストールされ、ack-fluid コンポーネントがデプロイされています。
重要オープンソースの Fluid を既にインストールしている場合は、Fluid をアンインストールし、ack-fluid コンポーネントをデプロイします。
クラウドネイティブ AI スイートをまだインストールしていない場合は、スイートをインストールするときに [Fluid アクセラレーション] を有効にします。 詳細については、「クラウドネイティブ AI スイートをデプロイする」をご参照ください。
クラウドネイティブ AI スイートを既にインストールしている場合は、クラウドネイティブ AI SuiteACK コンソール の [クラウドネイティブ AI スイート] ページに移動し、[ack-fluid] コンポーネントをデプロイします。
kubectl クライアントが ACK Pro マネージドクラスターに接続されています。 詳細については、「kubectl を使用してクラスターに接続する」をご参照ください。
OSS がアクティブ化されています。 詳細については、「OSS をアクティブ化する」をご参照ください。
ステップ 1：OSS にデータをアップロードする
次のコマンドを実行して、テストデータセットを Elastic Compute Service (ECS) インスタンスにダウンロードします。
wget https://archive.apache.org/dist/spark/spark-3.0.1/spark-3.0.1-bin-hadoop2.7.tgzテストデータセットを OSS バケットにアップロードします。
重要この例では、Alibaba Cloud Linux 3.2104 LTS 64 ビット オペレーティングシステムを実行している ECS インスタンスから OSS にテストデータセットをアップロードする方法について説明します。 他のオペレーティングシステムを使用する場合は、「ossutil」および「ossutil 1.0」をご参照ください。
examplebucketという名前のバケットを作成します。次のコマンドを実行して、
examplebucketという名前のバケットを作成します。ossutil64 mb oss://examplebucket次の出力が表示された場合、
examplebucketという名前のバケットが作成されます。0.668238(s) elapsed
テストデータセットを
examplebucketにアップロードします。ossutil64 cp spark-3.0.1-bin-hadoop2.7.tgz oss://examplebucket
ステップ 2：データセットと JindoRuntime を作成する
データセットを作成する前に、ECS インスタンスのルートディレクトリに
mySecret.yamlという名前のファイルを作成します。apiVersion: v1 kind: Secret metadata: name: mysecret stringData: fs.oss.accessKeyId: xxx fs.oss.accessKeySecret: xxxステップ 1 で OSS にアクセスするために使用される
AccessKey IDとAccessKey Secretとして、fs.oss.accessKeyIdとfs.oss.accessKeySecretを指定します。次のコマンドを実行してシークレットを作成します。 Kubernetes は、保存されている情報がプレーンテキストとして公開されないように、作成されたシークレットを暗号化します。
kubectl create -f mySecret.yaml次の YAML テンプレートを使用して、
resource.yamlという名前のファイルを作成します。 このテンプレートは、次の操作を実行するために使用されます。リモートストレージ内のデータセットと基盤となるファイルシステム (UFS) に関する情報を指定するデータセットを作成します。
データキャッシュ用の JindoFS クラスターを起動する JindoRuntime を作成します。
apiVersion: data.fluid.io/v1alpha1 kind: Dataset metadata: name: hadoop spec: mounts: - mountPoint: oss://<oss_bucket>/<bucket_dir> options: fs.oss.endpoint: <oss_endpoint> name: hadoop path: "/" encryptOptions: - name: fs.oss.accessKeyId valueFrom: secretKeyRef: name: mysecret key: fs.oss.accessKeyId - name: fs.oss.accessKeySecret valueFrom: secretKeyRef: name: mysecret key: fs.oss.accessKeySecret --- apiVersion: data.fluid.io/v1alpha1 kind: JindoRuntime metadata: name: hadoop spec: replicas: 2 tieredstore: levels: - mediumtype: MEM path: /dev/shm volumeType: emptyDir quota: 2Gi high: "0.99" low: "0.95"次の表に、YAML テンプレートのパラメーターを示します。
パラメーター
説明
mountPoint
oss://<oss_bucket>/<bucket_dir> は、マウントされる UFS へのパスを指定します。 パスにエンドポイントは必要ありません。
fs.oss.endpoint
OSS バケットのパブリックまたはプライベートエンドポイント。 詳細については、「リージョンとエンドポイント」をご参照ください。
replicas
JindoFS クラスター内のワーカーの数。
mediumtype
キャッシュタイプ。 このパラメーターは、JindoRuntime テンプレートを作成するときに使用されるキャッシュタイプを指定します。 有効な値：HDD、SDD、および MEM。
path
ストレージパス。 指定できるパスは 1 つだけです。 mediumtype を MEM に設定した場合、ログなどのデータを格納するローカルパスを指定する必要があります。
quota
キャッシュデータの最大サイズ。 単位：GB。
high
ストレージ容量の上限。
low
ストレージ容量の下限。
次のコマンドを実行して、データセットと JindoRuntime を作成します。
kubectl create -f resource.yaml次のコマンドを実行して、データセットがデプロイされているかどうかを確認します。
kubectl get dataset hadoop予期される出力：
NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE hadoop 210MiB 0.00B 4.00GiB 0.0% Bound 1h次のコマンドを実行して、JindoRuntime がデプロイされているかどうかを確認します。
kubectl get jindoruntime hadoop予期される出力：
NAME MASTER PHASE WORKER PHASE FUSE PHASE AGE hadoop Ready Ready Ready 4m45s次のコマンドを実行して、永続ボリューム (PV) と永続ボリューム要求 (PVC) が作成されているかどうかを確認します。
kubectl get pv,pvc予期される出力：
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE persistentvolume/hadoop 100Gi RWX Retain Bound default/hadoop 52m NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE persistentvolumeclaim/hadoop Bound hadoop 100Gi RWX 52m
上記の出力は、データセットと JindoRuntime が作成されたことを示しています。
ステップ 3：データアクセラレーションをテストするアプリケーションを作成する
コンテナーにアプリケーションをデプロイして、JindoFS のデータアクセラレーションをテストできます。 また、機械学習ジョブを送信して、関連機能を使用することもできます。 このトピックでは、同じデータへのアクセスをテストするために、コンテナーにアプリケーションがデプロイされます。 テストでは、アクセス時間を比較することで、JindoRuntime のアクセラレーション効果を示します。
次の YAML テンプレートを使用して、app.yaml という名前のファイルを作成します。
apiVersion: v1 kind: Pod metadata: name: demo-app spec: containers: - name: demo image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6 volumeMounts: - mountPath: /data name: hadoop volumes: - name: hadoop persistentVolumeClaim: claimName: hadoop次のコマンドを実行して、アプリケーションをデプロイします。
kubectl create -f app.yaml次のコマンドを実行して、指定されたファイルのサイズをクエリします。
kubectl exec -it demo-app -- bash du -sh /data/spark-3.0.1-bin-hadoop2.7.tgz予期される出力：
210M /data/spark-3.0.1-bin-hadoop2.7.tgz次のコマンドを実行して、ファイルのコピーに費やされた時間をクエリします。
time cp /data/spark-3.0.1-bin-hadoop2.7.tgz /dev/null予期される出力：
real 0m18.386s user 0m0.002s sys 0m0.105s出力は、ファイルのコピーに 18 秒かかったことを示しています。
次のコマンドを実行して、データセットのキャッシュデータを確認します。
kubectl get dataset hadoop予期される出力：
NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE hadoop 210.00MiB 210.00MiB 4.00GiB 100.0% Bound 1h出力は、210 MiB のデータがオンプレミスストレージにキャッシュされていることを示しています。
次のコマンドを実行して、現在のアプリケーションを削除してから、同じアプリケーションを作成します。
説明この手順は、ページキャッシュなどの他の要因が結果に影響を与えるのを避けるために行われます。
kubectl delete -f app.yaml && kubectl create -f app.yaml次のコマンドを実行して、ファイルのコピーに費やされた時間をクエリします。
kubectl exec -it demo-app -- bash time cp /data/spark-3.0.1-bin-hadoop2.7.tgz /dev/null予期される出力：
real 0m0.048s user 0m0.001s sys 0m0.046s出力は、ファイルのコピーに 48 ミリ秒かかり、300 倍以上短縮されたことを示しています。
説明これは、ファイルが JindoFS によってキャッシュされているためです。
（オプション）環境をクリアする
データアクセラレーションを使用しない場合は、次のコマンドを実行して環境をクリアできます。
次のコマンドを実行して、アプリケーションを削除します。
kubectl delete pod demo-app次のコマンドを実行して、データセットと JindoRuntime を削除します。
kubectl delete dataset hadoop