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 werdennum_gpus_head_node
: Einstellung der GPU, die vom Ray-Hauptknoten verwendet wirdobject_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.7
OBJECT_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.