JindoRuntime は C++ ベースであり、データセット管理、データキャッシング、および Object Storage Service (OSS) でのデータストレージをサポートします。Fluid は JindoRuntime を管理およびスケジューリングすることで、データセットの可観測性、自動スケーリング、および可搬性を実現します。このトピックでは、ACS コンピューティング能力が使用されるシナリオで Fluid を使用してデータアクセスを高速化する方法について説明します。
Pod が OSS データを繰り返し読み取る場合、たとえ同じファイルが直前にアクセスされたばかりであっても、各読み取りはネットワーク経由でデータをフェッチします。JindoFS は、データをローカルメモリにキャッシングすることで、これらの繰り返しのラウンドトリップを排除します。ファイルが一度キャッシュされると、その後の読み取りはローカルに近い速度で提供されます。このトピックの例では、最初のキャッシュ読み取り後に 210 MiB のファイルで 9 倍の高速化が実証されています。
前提条件
開始する前に、以下を確認してください：
アクティベートされた OSS アカウント。「OSS のアクティベート」をご参照ください。
ack-fluid 1.0.11-* 以降がクラスターにインストールされていること。「Helm を使用した ACS でのアプリケーション管理」をご参照ください。
ACS Pod で特権モードが有効になっていること。
説明Fluid を使用してデータアクセラレーションを行うには、特権モードが必要です。有効にするには、してください。
ステップ1：OSS へのデータのアップロード
テストデータセットをダウンロードします。
wget https://archive.apache.org/dist/spark/spark-3.0.1/spark-3.0.1-bin-hadoop2.7.tgzデータセットを OSS バケットにアップロードします。
examplebucketという名前のバケットを作成します。説明コマンドが
ErrorCode=BucketAlreadyExistsを返した場合、バケットはすでに存在します。OSS バケット名はグローバルに一意である必要があるため、必要に応じて名前を変更してください。ossutil64 mb oss://examplebucket期待される出力：
0.668238(s) elapsedデータセットをバケットにアップロードします。
ossutil64 cp spark-3.0.1-bin-hadoop2.7.tgz oss://examplebucket(オプション) バケットとデータのアクセス権限を設定します。「権限制御」をご参照ください。
重要以下のサブステップでは、Alibaba Cloud Linux 3.2104 LTS 64 ビットを実行している Elastic Compute Service (ECS) インスタンスを使用します。他のオペレーティングシステムについては、「ossutil コマンドリファレンス」および「ossutil 1.0」をご参照ください。
mySecret.yamlという名前のファイルを次の内容で作成します。apiVersion: v1 kind: Secret metadata: name: mysecret stringData: fs.oss.accessKeyId: <your-access-key-id> # AccessKey ID に置き換えてください fs.oss.accessKeySecret: <your-access-key-secret> # AccessKey Secret に置き換えてくださいKubernetes は、機密データがプレーンテキストで公開されるのを防ぐために、Secret を自動的に暗号化します。
Secret を適用します。
kubectl create -f mySecret.yaml
ステップ2：Dataset と JindoRuntime の作成
続行する前に、ack-fluid コンポーネントの dataset-controller と jindoruntime-controller が実行中であることを確認してください：
kubectl get pods --field-selector=status.phase=Running -n fluid-systemこの例では、CPU コンピューティング能力が優先的に使用されます。大規模言語モデル (LLM) の読み込みを高速化するには、クラスターのゾーンが GPU リソースを提供していることを確認してください。「GPU コンピューティングクラスの概要」をご参照ください。
resource.yamlという名前のファイルを次の内容で作成します。このファイルは、OSS データを指す Dataset と、それをキャッシュするための JindoFS クラスターを起動する JindoRuntime を定義します。パラメーター 説明 mountPoint基盤となるファイルシステム (UFS) としてマウントする OSS パス。サブディレクトリには oss://<bucket>またはoss://<bucket>/<path>のフォーマットを使用します。fs.oss.endpointOSS バケットのエンドポイント (パブリックまたはプライベート)。例： oss-cn-beijing-internal.aliyuncs.com。「OSS のリージョンとエンドポイント」をご参照ください。replicasJindoFS クラスター内のワーカーノードの数。 mediumtypeキャッシュストレージ媒体。サポートされている値： MEM、HDD、SSD。quotaワーカーあたりの最大キャッシュサイズ。 high/lowキャッシュエビクションの上限および下限しきい値。 apiVersion: data.fluid.io/v1alpha1 kind: Dataset metadata: name: hadoop spec: placement: Shared # ACS 仮想ノードに必要 mounts: # サブディレクトリをマウントするには、oss://<oss_bucket>/<oss_path> を使用します - mountPoint: oss://<oss_bucket> # OSS バケット名に置き換えてください (例: oss://examplebucket) options: fs.oss.endpoint: <oss_endpoint> # OSS エンドポイントに置き換えてください (例: oss-cn-beijing-internal.aliyuncs.com) 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 # Dataset 名と一致させる必要があります spec: networkmode: ContainerNetwork replicas: 4 # JindoFS ワーカーノードの数。必要に応じて調整してください master: podMetadata: labels: alibabacloud.com/compute-class: performance alibabacloud.com/compute-qos: default worker: podMetadata: labels: alibabacloud.com/compute-class: performance alibabacloud.com/compute-qos: default resources: requests: cpu: 24 memory: 48Gi limits: cpu: 24 memory: 48Gi tieredstore: levels: - mediumtype: MEM # キャッシュ媒体：MEM、HDD、または SSD path: /dev/shm # キャッシュ媒体のストレージパス volumeType: emptyDir quota: 48Gi # ワーカーあたりの最大キャッシュサイズ。必要に応じて調整してください high: "0.99" # 使用量がこのしきい値に達するとエビクションが開始されます low: "0.95" # 使用量がこのしきい値まで低下するとエビクションが停止します主要なパラメーター：
設定を適用します。
kubectl create -f resource.yamlDataset と JindoRuntime の準備ができていることを確認します。Dataset を確認します：
kubectl get dataset hadoop期待される出力：
NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE hadoop 209.74MiB 0.00B 4.00GiB 0.0% Bound 56sJindoRuntime を確認します：
kubectl get jindoruntime hadoop期待される出力：
NAME MASTER PHASE WORKER PHASE FUSE PHASE AGE hadoop Ready Ready Ready 2m11s永続ボリューム (PV) と永続ボリューム要求 (PVC) が作成されたことを確認します。PV は Dataset 名を使用します。
kubectl get pv,pvc期待される出力：
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE persistentvolume/default-hadoop 100Pi ROX Retain Bound default/hadoop fluid <unset> 2m5s NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE persistentvolumeclaim/hadoop Bound default-hadoop 100Pi ROX fluid <unset> 2m5s
ステップ3：DataLoad リソースの作成
ワークロードを実行する前にデータセットを JindoFS キャッシュにプリロードすることで、最初のアクセスから高速になり、データ処理ロジックが有効であることが保証されます。
OSS バケット内のデータが静的な場合は、
dataload.yamlという名前のファイルを次の内容で作成します。apiVersion: data.fluid.io/v1alpha1 kind: DataLoad metadata: name: hadoop spec: dataset: name: hadoop namespace: default loadMetadata: trueデータが定期的に変更される場合は、代わりに定期的なプリロードを設定します。「シナリオ2：バックエンドストレージのデータは読み取り専用だが定期的に変更される」をご参照ください。
DataLoad リソースを適用してプリロードを開始します。
kubectl create -f dataload.yamlプリロードの進行状況を監視します。
kubectl get dataload完了時の期待される出力：
NAME DATASET PHASE AGE DURATION hadoop hadoop Complete 92m 51s
ステップ4：データアクセラレーションの検証
Dataset をマウントするテスト Pod をデプロイし、JindoFS キャッシングが有効になる前と後でファイルコピー時間を測定します。
app.yamlという名前のファイルを作成します。apiVersion: v1 kind: Pod metadata: name: demo-app labels: # 必須：Fluid Webhook に JindoFS サイドカーコンテナを ACS Pod に注入するよう指示します alibabacloud.com/fluid-sidecar-target: acs spec: containers: - name: demo image: mirrors-ssl.aliyuncs.com/nginx:latest volumeMounts: - mountPath: /data name: hadoop resources: requests: cpu: 14 memory: 56Gi volumes: - name: hadoop persistentVolumeClaim: claimName: hadoop # Fluid Dataset 名と一致します nodeSelector: type: virtual-kubelet tolerations: - key: virtual-kubelet.io/provider operator: Equal value: alibabacloud effect: NoSchedulePod をデプロイします。
kubectl create -f app.yamlJindoFS キャッシングなしでファイルコピー時間を測定します。ファイルサイズを確認します：
kubectl exec -it demo-app -c demo -- du -sh /data/spark-3.0.1-bin-hadoop2.7.tgz期待される出力：
210M /data/spark-3.0.1-bin-hadoop2.7.tgzコピー時間を測定します：
kubectl exec -it demo-app -c demo -- bash time cp /data/spark-3.0.1-bin-hadoop2.7.tgz /dev/null期待される出力：
real 0m1.883s user 0m0.001s sys 0m0.041sデータが完全にキャッシュされていることを確認します。
kubectl get dataset hadoop期待される出力：
NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE hadoop 209.74MiB 209.74MiB 4.00GiB 100.0% Bound 64mPod を削除して再作成し、JindoFS キャッシュに対して再度コピーテストを実行します。
説明Pod を再作成すると OS ページキャッシュがクリアされるため、2 回目の測定では最初の実行によるメモリ内の残留物ではなく、JindoFS キャッシュの速度のみが反映されます。
既存の Pod を削除します：
kubectl delete pod demo-app再作成します：
kubectl create -f app.yamlコピー テストを再度実行してください：
kubectl exec -it demo-app -c demo -- bash time cp /data/spark-3.0.1-bin-hadoop2.7.tgz /dev/null期待される出力：
real 0m0.203s user 0m0.000s sys 0m0.047sコピー処理時間は現在 0.203 秒です。これは、キャッシュを使用しない場合の 1.883 秒と比較して約 9 倍速いです。この高速化は、JindoFS がファイルを
/dev/shm上のメモリキャッシュから提供するためであり、OSS からネットワーク経由でフェッチするのとは異なります。データがローカルにキャッシュされると、その後の読み取りではネットワークを完全に経由せずに処理されます。重要ここに表示されているコピー時間は参考のみであり、ご利用のクラスター構成およびネットワーク条件に応じて変動する場合があります。
Container Service for Kubernetes (ACK) Pro クラスターでの ACS コンピューティング能力の使用
上記の手順は ACS クラスターに適用されます。代わりに ACK マネージドクラスターで ACS コンピューティング能力を使用するには、「ACK Pro クラスターで ACS のコンピューティング能力を使用する」をご参照ください。
ACK マネージドクラスターの場合は、次の調整を行います：
ack-fluid コンポーネントを ACK マネージドクラスターにインストールします。「Helm を使用してアプリケーションのデプロイを簡素化する」をご参照ください。
次の構成を使用して Dataset と JindoRuntime を作成します。ACS 構成との主な違いは、
placement: Sharedとnetworkmodeがなく、compute-classラベルもないことです。標準の ACK ノードではこれらの設定は必要ありません。ACS クラスターは、標準のノードスケーリングをサポートしない仮想ノードを使用します。共有データセットアクセスと Pod 間通信を有効にするには、ACS 構成で
placement: Sharedとnetworkmode: ContainerNetworkを設定します。これらのフィールドは ACK マネージドクラスターには必要ありません。ACS 上の Fluid ワーカーは高い帯域幅を必要とします。十分な帯域幅を確保するために、ACS 構成で
compute-class: performanceを設定し、十分な CPU とメモリのresourcesを構成します。ACK マネージドクラスターはリソースを異なる方法で割り当てるため、これらのラベルは必要ありません。
apiVersion: data.fluid.io/v1alpha1 kind: Dataset metadata: name: hadoop spec: mounts: # サブディレクトリをマウントするには、oss://<oss_bucket>/<oss_path> を使用します - mountPoint: oss://<oss_bucket> # OSS バケット名に置き換えてください options: fs.oss.endpoint: <oss_endpoint> # OSS エンドポイントに置き換えてください 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: 4 # 必要に応じて調整してください tieredstore: levels: - mediumtype: MEM path: /dev/shm volumeType: emptyDir quota: 48Gi high: "0.99" low: "0.95"ACS 構成との違い：