Deploy Ray using Helm

計算要件を分散し、データの合成のような重いジョブを実行する, を展開する必要があります。 Ray クラスタにHelmを使ってAPIを接続する。チャートはリポジトリ here または、Helm で直接使用するリポジトリ URL を指定することもできます。このレポURLについてはSynthoチームにお問い合わせください。

このドキュメントでは helm/ray を前述のGitHubリポジトリのmasterブランチに追加した。

{ヒント style="info" %}。 OpenShiftユーザーのためのメモ: Rayでは、ポッド内に多くのスレッドを作成する必要があります。, 特にRayクラスタをスケーリングする場合。デフォルトでは, OpenShiftはポッドが生成できるプロセス数を制限している, コンテナランタイムインターフェース（CRI）としてCRI-Oを使用しているためです。この制限を更新することをお勧めします。: セクションを参照 Deploy Ray using Helm

画像の設定

において values.yaml ファイル helm/ray, 正しいDockerイメージを使用するために、以下のフィールドを設定します。:

演算子画像:
  リポジトリ: syntho.azurecr.io/syntho-ray-operator
  タグ: <tag>
  プルポリシー: IfNotPresent

イメージ:
  リポジトリ: syntho.azurecr.io/syntho-ray
  タグ: <tag>
  プルポリシー: IfNotPresent

画像タグはSynthoチームが提供します。場合によっては, 最新のタグが使える, しかし、特定のタグを設定することをお勧めします。

正しいDockerイメージを設定する, Kubernetesを定義する Secret で作成される。 imagePullSecrets:

イメージプル秘密: 
    - 名称: シンセシークレット

この値は syntho-cr-secret デフォルトで

ライセンスキー - レイ

ライセンスキーは SynthoLicense での values.yaml ファイルを作成する。この例は次のようになる。:

シンセライセンス: <syntho-license-key>

Syntho が提供するライセンスキーを使用してください。

クラスタ名

デフォルトのクラスター名は ray-cluster.調整が必要な場合, を変更することで可能です。 clustername:

クラスター名: レイクラスタ

ワーカーとノード

まず最初に, Synthoチームは、お客様のデータ要件に応じたクラスタの正確なサイズについて、いくつかの推奨事項を持っています。これに関する情報を受け取っていない場合, 最適なセットアップをご相談ください。このセクションの残りの部分では、Helmチャートでどのように見えるかを示す設定例を示します。

クラスタのサイズとノード数に応じて, レイがタスクに使えるワーカーの数を調整する。Rayは少なくとも1つのヘッドインスタンスを必要とします。パフォーマンスを上げるには, さらにワーカーグループを作ることもできます。以下 head ヘッドノードのリソースを設定します。このヘッドノードは主にRayの管理タスクに使用され、ワーカーノードはSynthoアプリケーションのタスクのほとんどをピックアップします。

本番環境の場合, ヘッドノードの隣にワーカーのプールを作ることをお勧めします。Syntho チームは、ヘッドノードとワーカーノードに割り当てるリソースを指定できます。以下は、ヘッドノードと1つのノードプールを持つクラスタの構成例です。, 1台, 16個のCPUと64GBのRAMを搭載:

頭:
  rayStartParams:
    ダッシュボードホスト: '0.0.0.0'
    ブロック: 'true'
  コンテナ環境:
  - 名称: レイ_スケジューラー_拡散しきい値
    値: "0.0"
  envFrom: []
  リソース:
    制限:
      CPU: "16"
      メモリ: "64G"
    リクエスト:
      CPU: "16"
      メモリ: "64G"
  注釈: {}
  ノードセレクタ: {}
  許容範囲: []
  親和性: {}
  セキュリティコンテキスト: {}
  ポート:
  - コンテナポート: 6379
    名称: ジェーシー
  - コンテナポート: 8265
    名称: ダッシュボード
  - コンテナポート: 10001
    名称: 顧客
  数量:
    - 名称: ログボリューム
      空のディレクトリ: {}
  ボリュームマウント:
    - マウントパス: /tmp/ray
      名前: ログボリューム
  サイドカーコンテナ: []


ワーカー:
  # デフォルトのworkergroupを無効にしたい場合
  # 以下の行のコメントを解除する
  # 無効にする: 真
  グループ名: ワーカーグループ
  レプリカ: 1
  ラベル: {}
  rayStartParams:
    ブロック: 'true'
  initContainerImage: ビジーボックス:1.28'
  initContainerSecurityContext: {}
  コンテナ環境:
   - 名称: レイ_スケジューラー_拡散しきい値
     値: "0.0"
  envFrom: []
  リソース:
    制限:
      CPU: "16"
      メモリ: "64G"
    リクエスト:
      CPU: "16"
      メモリ: "64G"
  注釈: {}
  ノードセレクタ: {}
  許容範囲: []
  親和性: {}
  セキュリティコンテキスト: {}
  ボリューム:
    - 名称: ログボリューム
      空のディレクトリ: {}
  ボリュームマウント:
    - マウントパス: /tmp/ray
      名前: ログボリューム
  サイドカーコンテナ: []

Kubernetesでオートスケールが有効になっている場合, レイの要件が利用可能なリソースを上回った場合、新しいノードが作成されます。どのような状況がお客様のデータ要件に合うか、Synthoチームとご相談ください。

開発・実験環境の場合, ほとんどの場合、それほど高度なセットアップは必要ない。この場合, 最初にヘッドノードタイプのみをセットアップし、ワーカーや追加の自動スケーリング設定は行わないことをお勧めします。このノードのサイズについては、Synthoチームが再度アドバイスします。, データ要件を考慮する。16CPUと64GBのRAMを搭載したノードを使用した構成例は以下の通りです。:

頭:
  rayStartParams:
    ダッシュボードホスト: '0.0.0.0'
    ブロック: 'true'
  コンテナ環境:
  - 名称: レイ_スケジューラー_拡散しきい値
    値: "0.0"
  envFrom: []
  リソース:
    制限:
      CPU: "16"
      # メモリ不足の問題を避けるために, レイヘッドに2G未満のメモリを割り当てないこと。
      メモリー: 「64G" # データ要件による
    リクエスト:
      CPU: "16"
      メモリ: 「64G" # データ要件による
  注釈: {}
  ノードセレクタ: {}
  許容範囲: []
  親和性: {}
  セキュリティコンテキスト: {}
  ポート:
  - コンテナポート: 6379
    名称: ジェーシー
  - コンテナポート: 8265
    名称: ダッシュボード
  - コンテナポート: 10001
    名称: 顧客
  数量:
    - 名称: ログボリューム
      空のディレクトリ: {}
  ボリュームマウント:
    - マウントパス: /tmp/ray
      名前: ログボリューム
  サイドカーコンテナ: []

ワーカー:
  # デフォルトのworkergroupを無効にしたい場合
  # 以下の行のコメントを解除する
  無効: 真の

# マップのキーがgroupNameとして使用される。
# 例えば, キー:以下のマップの小グループ
# がグループ名として使用されます。
追加ワーカーグループ:
  スモールグループ:
    # デフォルトでは無効
    無効: 擬似

さらに, nodeSelector, tolerations そして affinity ノードのタイプごとに定義できる, ポッドやノードがどこに割り当てられるかをある程度コントロールできるようにするためだ。 securityContext そして annotiations は、ワーカー/ヘッドノードのタイプごとに設定することもできます。

Ray ワーカーの共有ストレージ

現在実行中のタスクに関するメタデータを共有するために、Ray ワーカー用に追加の永続ボリュームが必要です。これは Helm チャートに含まれ、Persistent Volume タイプが ReadWriteMany.セクション storage を使用する場合は、storageClassNameを調整してください。を使用していることを確認してください。 storageClass 型をサポートする ReadWriteMany.

ストレージ:
  ストレージクラス名: デフォルト # 正しいstorageClassに変更

ボリュームのマウント

オプション

特定のボリュームをマウントする必要がある場合, 価値観 volumes そして volumeMounts を調整して定義することができる。PVを使用する際は、Rayがそのボリュームを使用して複数のポッドをスケジュールする可能性があることに留意してください。, そのため、複数のマシンからアクセスできる必要がある。

OpenShift/CRI-O に関する追加変更

特定のオーケストレーターやセットアップでは、コンテナランタイムインターフェース (CRI) として CRI-O が使用されます。Openshift 4.x では現在、CRI-O はデフォルトで 1024 プロセスの制限を設定しています。スケーリング時, Rayを使用すると、この制限に簡単に達することができます。この制限を8096プロセス程度に設定することを推奨する；

Openshiftのドキュメントには、この制限を増やす手順が記載されています。 here.その following link には、CRI-Oで使用できる設定の詳細が記載されている。

デプロイ

で値が正しく設定されたら values.yaml アンダー helm/ray, 以下のコマンドを使ってアプリケーションをクラスタにデプロイできる。:

helm install ray-cluster ./helm/ray --values values.yaml --namespace syntho

配備後, KubernetesでRayアプリケーションのサービス名を見つけることができる。サービス名を ray-cluster 上のコマンドのように, サービス名（および変数 ray_address コアAPI値のセクション)は ray-cluster-ray-head.

最後に, レイ・オペレーター・ポッドと、それに続くレイ・ヘッドやレイ・ワーカー・ポッドをチェックできる。実行中 kubectl logs deployment/ray-operator -n syntho オペレータのログが表示されます。

PreviousPreparations NextTroubleshooting

Last updated 11 months ago

Was this helpful?