Freigeben über


Skalieren von Ray-Clustern in Azure Databricks

Hier erfahren Sie, wie Sie die Größe Ihres Ray-Clusters für optimale Leistung optimieren können – einschließlich automatischer Skalierung, Hauptknotenkonfiguration, heterogener Cluster und Ressourcenzuordnung.

Erstellen eines Ray-Clusters im automatischen Skalierungsmodus

Ab Ray 2.8.0 unterstützen Ray-Cluster, die in Azure Databricks gestartet werden, die Integration in die automatische Skalierung von Azure Databricks. Diese Integration in die automatische Skalierung löst die automatische Skalierung von Azure Databricks-Clustern intern innerhalb der Azure Databricks-Umgebung aus.

Führen Sie den folgenden Befehl aus, um die automatische Skalierung zu aktivieren:

Für Ray-Versionen unter 2.10:

from ray.util.spark import setup_ray_cluster

setup_ray_cluster(
  num_worker_nodes=8,
  autoscale=True,
)

Für Ray-Versionen ab 2.10:

from ray.util.spark import setup_ray_cluster, shutdown_ray_cluster

setup_ray_cluster(
  min_worker_nodes=2,
  max_worker_nodes=4,
  num_cpus_per_node=4,
  collect_log_to_path="/dbfs/path/to/ray_collected_logs"
)

# Pass any custom Ray configuration with ray.init
ray.init(ignore_reinit_error=True)

Die ray.util.spark.setup_ray_cluster-API erstellt einen Ray-Cluster in Apache Spark. Intern wird ein Apache Spark-Hintergrundauftrag erstellt. Jede Apache Spark-Aufgabe im Auftrag erstellt einen Ray-Workerknoten, und der Ray-Hauptknoten wird für den Treiber erstellt. Die Argumente min_worker_nodes und max_worker_nodes stellen den Bereich der Ray-Workerknoten dar, die für Ray-Workloads erstellt und verwendet werden sollen. Wenn das Argument min_worker_nodes nicht definiert ist, wird ein Ray-Cluster mit fester Größe mit max_worker_nodes verfügbaren Workern gestartet. Um die Anzahl der CPU- oder GPU-Kerne anzugeben, die jedem Ray-Workerknoten zugewiesen sind, legen Sie das Argument num_cpus_worker_node (Standardwert: 1) oder num_gpus_worker_node (Standardwert: 0) fest.

Bei Ray-Versionen unter 2.10 gilt: Wenn die automatische Skalierung aktiviert ist, gibt num_worker_nodes die maximale Anzahl von Ray-Workerknoten an. Die standardmäßige Mindestanzahl von Ray-Workerknoten ist Null. Diese Standardeinstellung bedeutet, dass der Ray-Cluster auf null Ray-Workerknoten heruntergefahren wird, wenn er sich im Leerlauf befindet. Dadurch wird zwar möglicherweise nicht in allen Szenarien eine hohe Reaktionsgeschwindigkeit erzielt, die automatische Skalierung kann aber die Kosten erheblich senken, wenn sie aktiviert ist.

Im Modus mit automatischer Skalierung kann „num_worker_nodes“ nicht auf ray.util.spark.MAX_NUM_WORKER_NODES festgelegt werden.

Die folgenden Argumente konfigurieren die Hoch- und Herunterskalierungsgeschwindigkeit:

  • autoscale_upscaling_speed steht für die Anzahl der Knoten, die sich in der Schwebe befinden dürfen, als ein Vielfaches der aktuellen Anzahl von Knoten. Je höher der Wert, desto aggressiver ist die Hochskalierung. Wenn dieser Wert z.B. auf 1,0 gesetzt ist, kann der Cluster jederzeit um maximal 100 % wachsen.
  • autoscale_idle_timeout_minutes stellt die Anzahl von Minuten dar, die vergehen müssen, bevor ein untätiger Workerknoten von der automatischen Skalierung entfernt wird. Je kleiner der Wert, desto aggressiver ist das Herunterskalieren.

Ab Ray 2.9.0 können Sie auch autoscale_min_worker_nodes festlegen, damit der Ray-Cluster nicht auf null Worker herunterskaliert wird, wenn er sich im Leerlauf befindet. Dies würde nämlich dazu führen, dass der Cluster beendet wird.

Konfigurieren von Ressourcen, die vom Ray-Hauptknoten verwendet werden

Standardmäßig werden die dem Ray-Hauptknoten zugewiesenen Ressourcen von Azure Databricks bei der Konfiguration von Ray on Spark auf Folgendes beschränkt:

  • 0 CPU-Kerne
  • 0 GPUs
  • 128 MB Heapspeicher
  • 128 MB Objektspeicher

Das liegt daran, dass der Ray-Hauptknoten normalerweise nur für die globale Koordination und nicht für die Ausführung von Ray-Aufgaben verwendet wird. Die Apache Spark-Treiberknotenressourcen werden für mehrere Benutzer freigegeben, sodass die Standardeinstellung Ressourcen auf der Apache Spark-Treiberseite spart. Mit Ray 2.8.0 und höher können Sie Ressourcen konfigurieren, die vom Ray-Hauptknoten verwendet werden. Verwenden Sie die folgenden Argumente in der setup_ray_cluster-API:

  • num_cpus_head_node: Einstellung von CPU-Kernen, die vom Ray-Hauptknoten verwendet werden
  • num_gpus_head_node: Einstellung der GPU, die vom Ray-Hauptknoten verwendet wird
  • object_store_memory_head_node: Einstellung der Speichergröße des Objektspeichers durch den Ray-Hauptknoten

Unterstützung für heterogene Cluster

Für effizientere und kostengünstigere Trainingsläufe können Sie einen Ray on Spark-Cluster erstellen und unterschiedliche Konfigurationen zwischen dem Ray-Hauptknoten und den Ray-Workerknoten festlegen. Alle Ray-Workerknoten müssen jedoch dieselbe Konfiguration aufweisen. Azure Databricks-Cluster unterstützen keine heterogenen Cluster, aber Sie können einen Azure Databricks-Cluster mit unterschiedlichen Treiber- und Workerinstanztypen erstellen, indem Sie eine Clusterrichtlinie festlegen. Zum Beispiel:

{
  "node_type_id": {
    "type": "fixed",
    "value": "i3.xlarge"
  },
  "driver_node_type_id": {
    "type": "fixed",
    "value": "g4dn.xlarge"
  },
  "spark_version": {
    "type": "fixed",
    "value": "13.x-snapshot-gpu-ml-scala2.12"
  }
}

Optimieren der Ray-Clusterkonfiguration

Die empfohlene Konfiguration für jeden Ray-Workerknoten lautet wie folgt: mindestens vier CPU-Kerne pro Ray-Workerknoten. Mindestens 10 GB Heapspeicher für jeden Ray-Workerknoten.

Wenn Sie also ray.util.spark.setup_ray_cluster aufrufen, empfiehlt Azure Databricks, num_cpus_per_node auf einen Wert festzulegen, der größer oder gleich „4“ ist.

Ausführliche Informationen zum Optimieren des Heaparbeitsspeichers für die einzelnen Ray-Workerknoten finden Sie im nächsten Abschnitt.

Speicherzuweisung für Ray-Workerknoten

Jeder Ray-Workerknoten verwendet zwei Speichertypen: Heap-Speicher und Objektspeicherspeicher.

Die zugewiesene Arbeitsspeichergröße für jeden Typ wird wie unten beschrieben bestimmt.

Der gesamte Arbeitsspeicher, der den einzelnen Ray-Workerknoten zugeordnet ist, wird wie folgt berechnet: RAY_WORKER_NODE_TOTAL_MEMORY = (SPARK_WORKER_NODE_PHYSICAL_MEMORY / MAX_NUMBER_OF_LOCAL_RAY_WORKER_NODES * 0.8)

MAX_NUMBER_OF_LOCAL_RAY_WORKER_NODES ist die maximale Anzahl von Ray-Workerknoten, die auf dem Apache Spark-Workerknoten gestartet werden können. Dies wird durch das Argument num_cpus_per_node oder num_gpus_per_node bestimmt.

Wenn Sie das Argument object_store_memory_per_node nicht festlegen, werden die Größe des Heaparbeitsspeichers und die Arbeitsspeichergröße für den Objektspeicher, die den einzelnen Ray-Workerknoten zugeordnet sind, wie folgt berechnet: RAY_WORKER_NODE_HEAP_MEMORY = RAY_WORKER_NODE_TOTAL_MEMORY * 0.7OBJECT_STORE_MEMORY_PER_NODE = RAY_WORKER_NODE_TOTAL_MEMORY * 0.3

Wenn Sie das Argument object_store_memory_per_node festlegen, gilt Folgendes: RAY_WORKER_NODE_HEAP_MEMORY = RAY_WORKER_NODE_TOTAL_MEMORY - argument_object_store_memory_per_node

Darüber hinaus ist die Speichergröße des Objektspeichers pro Ray-Workerknoten durch den gemeinsam genutzten Speicher des Betriebssystems begrenzt. Der Höchstwert ist: OBJECT_STORE_MEMORY_PER_NODE_CAP = (SPARK_WORKER_NODE_OS_SHARED_MEMORY / MAX_NUMBER_OF_LOCAL_RAY_WORKER_NODES * 0.8)

SPARK_WORKER_NODE_OS_SHARED_MEMORY ist die Größe des Datenträgers /dev/shm, die für den Apache Spark-Workerknoten konfiguriert ist.

Bewährte Methoden für die Skalierung

Festlegen der CPU- und GPU-Anzahl für die einzelnen Ray-Workerknoten

Es wird empfohlen, das Argument num_cpus_worker_node auf die Anzahl von CPU-Kernen pro Apache Spark-Workerknoten festzulegen. Ebenso optimal ist das Festlegen von num_gpus_worker_node auf die Anzahl von GPUs pro Apache Spark-Workerknoten. Bei dieser Konfiguration startet jeder Apache Spark-Workerknoten einen einzelnen Ray-Workerknoten, der die Ressourcen des jeweiligen Apache Spark-Workerknotens vollständig nutzt.

Legen Sie die Umgebungsvariable RAY_memory_monitor_refresh_ms innerhalb der Azure Databricks-Clusterkonfiguration auf 0 fest, wenn Sie Ihren Apache Spark-Cluster starten.

Konfiguration von Arbeitsspeicherressourcen für Apache Spark- und Ray-Hybridworkloads

Wenn Sie Spark- und Ray-Hybridworkloads in einem Azure Databricks-Cluster ausführen, empfiehlt Azure Databricks, den Spark-Executorarbeitsspeicher auf einen kleinen Wert zu verringern. Legen Sie in der Azure Databricks-Clusterkonfiguration beispielsweise spark.executor.memory 4g fest.

Der Apache Spark-Executor ist ein Java-Prozess, der GC verzögert auslöst, und der Apache Spark-Datasetcache beansprucht viel Apache Spark-Executorarbeitsspeicher. Dadurch reduziert sich der für Ray verfügbare Arbeitsspeicher. Um potenzielle Fehler aufgrund von zu wenig Arbeitsspeicher zu vermeiden, empfiehlt es sich, die spark.executor.memory-Konfiguration zu verringern.

Konfiguration von Berechnungsressourcen für Apache Spark- und Ray-Hybridworkloads

Wenn Sie Spark- und Ray-Hybridworkloads in einem Azure Databricks-Cluster ausführen, empfiehlt es sich, entweder Clusterknoten oder Ray-Workerknoten automatisch skalierbar zu machen. Zum Beispiel:

Wenn Sie über eine feste Anzahl von Workerknoten zum Starten eines Azure Databricks-Clusters verfügen, empfiehlt es sich, die automatische Skalierung für Ray on Spark zu aktivieren. Wenn keine Ray-Workloads ausgeführt werden, wird der Ray-Cluster herunterskaliert, wodurch Ressourcen für die Verwendung durch Apache Spark-Aufgaben freigegeben werden. Wenn Apache Spark-Aufgaben abgeschlossen sind und Ray wieder verwendet wird, wird der Ray on Spark-Cluster wieder hochskaliert, um den Bedarf zu decken.

Darüber hinaus können die Azure Databricks- und die Ray on Spark-Cluster automatisch skalierbar gemacht werden. Wenn Sie z. B. die automatisch skalierbaren Knoten des Azure Databricks-Clusters auf maximal 10 Knoten konfigurieren, konfigurieren Sie die Ray-on-Spark-Workerknoten auf maximal vier Knoten, und konfigurieren Sie jeden Ray-Workerknoten so, dass die Ressourcen der einzelnen Apache Spark Worker vollständig genutzt werden, ray workloads können bei einer solchen Clusterkonfiguration maximal vier Knotenressourcen verwenden. Im Vergleich dazu können Apache Spark-Aufträge maximal sechs Ressourcenknoten zuordnen.