JindoRuntimeは、Alibaba Cloud E-MapReduce (EMR) チームによって開発されたJindoFSの実行エンジンです。 JindoRuntime は C++ ベースで、データセットの管理とキャッシングを行います。 JindoRuntime は、Object Storage Service (OSS) にも対応しています。 Alibaba Cloudは、JindoFSのクラウドサービスレベルのサポートを提供します。 Fluidは、JindoRuntimeの管理とスケジューリングにより、データセットの可観測性、自動スケーリング、移植性を実現します。 このトピックでは、JindoFSを使用してOSSへのアクセスを高速化する方法について説明します。
前提条件
非containerOSを使用したContainer Service for Kubernetes (ACK) Proクラスターが作成され、クラスターのKubernetesバージョンが1.18以降になります。 詳細については、「ACK Proクラスターの作成」をご参照ください。
重要ack − fluidコンポーネントは、現在、ContainerOS上でサポートされていない。
クラウドネイティブAIスイートがインストールされ、ack-fluidコンポーネントがデプロイされます。
重要既にオープンソースFluidをインストールしている場合は、Fluidをアンインストールしてack-fluidコンポーネントをデプロイします。
クラウドネイティブAIスイートをインストールしていない場合は、スイートのインストール時にFluidアクセラレーションを有効にします。 詳細については、「クラウドネイティブAIスイートのデプロイ」をご参照ください。
クラウドネイティブAIスイートを既にインストールしている場合は、ACKコンソールのクラウドネイティブAIスイートページに移動し、ack-fluidコンポーネントをデプロイします。
kubectlクライアントがACK Proクラスターに接続されています。 詳細については、「kubectlを使用したクラスターへの接続」をご参照ください。
OSSが有効化されています。 詳細については、「OSSの有効化」をご参照ください。
背景情報
Container Service for Kubernetes (ACK) クラスターとOSSバケットをセットアップした後、JindoRuntimeをデプロイする必要があります。 デプロイには約10分かかります。
手順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 バケット
examplebucketという名前のバケットを作成します。次のコマンドを実行して、
examplebucketという名前のバケットを作成します。ossutil64 mb oss:// examplebucket次の出力が表示された場合、
examplebucketという名前のバケットが作成されます。0.668238経過
テストデータセットを
examplebucketにアップロードします。ossutil64 cp spark-3.0.1-bin-hadoop2.7.tgz oss:// examplebucket
ステップ2: データセットとJindoRuntimeの作成
データセットを作成する前に、ECSインスタンスのルートディレクトリに
mySecret.yamlという名前のファイルを作成します。apiVersion: v1 kind: 秘密 メタデータ: 名前: 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) に関する情報を指定するデータセットを作成します。
JindoRuntimeを作成して、データキャッシュ用のJindoFSクラスターを起動します。
apiVersion: data.fluid.io/v1alpha 1 kind: データセット メタデータ: 名前: hadoop spec: mounts: -mountPoint: oss://<oss_bucket>/<bucket_dir> options: fs.oss.endpoint: <oss_endpoint> 名前: hadoop パス: "/" encryptOptions: -名前: fs.oss.accessKeyId valueFrom: secretKeyRef: 名前: mysecret キー: fs.oss.accessKeyId -名前: fs.oss.accessKeySecret valueFrom: secretKeyRef: 名前: mysecret キー: fs.oss.accessKeySecret --- apiVersion: data.fluid.io/v1alpha 1 kind: JindoRuntime メタデータ: 名前: hadoop spec: レプリカ：2 tieredstore: レベル: -mediumtype: MEM パス: /dev/shm volumeType: emptyDir クォータ: 2Gi high: "0.99" low: "0.95"次の表に、YAMLテンプレートのパラメーターを示します。
パラメーター
説明
mountPoint
oss://<oss_bucket>/<bucket_dir> は、マウントされるUFSへのパスを指定します。 パスにエンドポイントは必要ありません。
fs.oss.endpoint
OSSバケットのパブリックエンドポイントまたはプライベートエンドポイント。 詳細については、「リージョン、エンドポイント、オープンポート」をご参照ください。
レプリカ
JindoFSクラスター内のワーカーの数。
mediumtype
キャッシュタイプ。 このパラメーターは、JindoRuntimeテンプレートを作成するときに使用するキャッシュタイプを指定します。 有効な値: HDD、SDD、およびMEM。
パス
ストレージパス。 指定できるパスは1つだけです。 mediumtypeをMEMに設定した場合、ログなどのデータを保存するためのローカルパスを指定する必要があります。
クォータ
キャッシュされたデータの最大サイズ。 (単位：GB)
高い
ストレージ容量の上限。
低い
ストレージ容量の下限。
次のコマンドを実行して、データセットとJindoRuntimeを作成します。
kubectl create -f resource.yaml次のコマンドを実行して、データセットがデプロイされているかどうかを確認します。
kubectl getデータセットhadoop期待される出力:
名UFS合計サイズキャッシュキャッシュ容量キャッシュパーセント位相年齢 hadoop 210MiB 0.00B 4.00GiB 0.0% バウンド1h次のコマンドを実行して、JindoRuntimeがデプロイされているかどうかを確認します。
kubectl get jindoruntime hadoop期待される出力:
名マスターフェーズ作業者フェーズヒューズフェーズ年齢 hadoopレディレディ4m4 5s次のコマンドを実行して、永続ボリューム (PV) と永続ボリューム要求 (PVC) が作成されているかどうかを確認します。
kubectl get pv,pvc期待される出力:
が容量アクセスモードに名前を付けると、ポリシーステータスはSTORAGECLASSの理由年齢を主張します persistentvolume/hadoop 100Gi RWXバインド済みのデフォルト /hadoop 52m 名前ステータスボリューム容量アクセスモードSTORAGECLASS年齢 persistentvolumeclaim/hadoopバインドされたhadoop 100Gi RWX 52m
上記の出力は、データセットとJindoRuntimeが作成されたことを示しています。
ステップ3: データアクセラレーションをテストするアプリケーションを作成する
アプリケーションをコンテナにデプロイして、JindoFSのデータアクセラレーションをテストできます。 機械学習ジョブを送信して、関連する機能を使用することもできます。 このトピックでは、同じデータへのアクセスをテストするために、アプリケーションをコンテナーにデプロイします。 テストは、時間消費を比較するために複数回実行される。
次のyamlテンプレートを使用して、app. YAMLという名前のファイルを作成します。
apiVersion: v1 種類: ポッド メタデータ: 名前: demo-app spec: コンテナー: -name: デモ 画像: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6 volumeMounts: -mountPath: /データ 名前: hadoop ボリューム: -name: hadoop persistentVolumeClaim: claimName: hadoop次のコマンドを実行して、アプリケーションをデプロイします。
kubectl create -f app.yaml次のコマンドを実行して、指定したファイルのサイズを照会します。
kubectl exec -it demo-app -- bash du -sh /データ /spark-3.0.1-bin-hadoop2.7.tgz期待される出力:
210M /データ /spark-3.0.1-bin-hadoop2.7.tgz次のコマンドを実行して、ファイルのコピーにかかる時間を照会します。
time cp /data/spark-3.0.1-bin-hadoop2.7.tgz /dev/null期待される出力:
リアル0m18.386s ユーザー0m0.002s sys 0m0.105s出力は、ファイルのコピーに18秒かかることを示します。
次のコマンドを実行して、データセットのキャッシュデータを確認します。
kubectl getデータセットhadoop期待される出力:
名UFS合計サイズキャッシュキャッシュ容量キャッシュパーセント位相年齢 hadoop 210.00MiB 210.00MiB 4.00GiB 100.0% バウンド1h出力は、データの210のMiBがオンプレミスストレージにキャッシュされていることを示します。
次のコマンドを実行して、現在のアプリケーションを削除し、同じアプリケーションを作成します。
説明このステップは、ページキャッシュなどの他の要因が結果に影響を与えることを回避するために実行される。
kubectl delete -f app.yaml && kubectl create -f app.yaml次のコマンドを実行して、ファイルのコピーにかかる時間を照会します。
kubectl exec -it demo-app -- bash 時間cp /データ /spark-3.0.1-bin-hadoop2.7.tgz /dev/null期待される出力:
リアル0m0.048s ユーザー0m0.001s sys 0m0.046s出力は、ファイルのコピーに48ミリ秒かかり、300倍以上の短縮が必要であることを示しています。
説明これは、ファイルがJindoFSによってキャッシュされているためです。
環境をクリアする
データアクセラレーションを使用しなくなった場合は、環境をクリアします。
次のコマンドを実行して、アプリケーションを削除します。
kubectl delete pod demo-app次のコマンドを実行して、データセットとJindoRuntimeを削除します。
kubectl deleteデータセットhadoop