| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123 |
- # An unique identifier for the head node and workers of this cluster.
- cluster_name: ray-cluster
- # The maximum number of workers nodes to launch in addition to the head
- # node.
- max_workers: 5
- # The autoscaler will scale up the cluster faster with higher upscaling speed.
- # E.g., if the task requires adding more nodes then autoscaler will gradually
- # scale up the cluster in chunks of upscaling_speed*currently_running_nodes.
- # This number should be > 0.
- upscaling_speed: 1.0
- # This executes all commands on all nodes in the docker container,
- # and opens all the necessary ports to support the Ray cluster.
- # Empty string means disabled.
- docker:
- image: "rayproject/ray-ml:latest"
- # image: rayproject/ray:latest # use this one if you don't need ML dependencies, it's faster to pull
- container_name: "ray_container"
- # If true, pulls latest version of image. Otherwise, `docker run` will only pull the image
- # if no cached version is present.
- pull_before_run: True
- run_options: # Extra options to pass into "docker run"
- - --ulimit nofile=65536:65536
- # If a node is idle for this many minutes, it will be removed.
- idle_timeout_minutes: 5
- # Cloud-provider specific configuration.
- provider:
- type: vsphere
- # How Ray will authenticate with newly launched nodes.
- auth:
- ssh_user: ray
- # By default Ray creates a new private keypair, but you can also use your own.
- # If you do so, make sure to also set "KeyName" in the head and worker node
- # configurations below.
- ssh_private_key: ~/ray-bootstrap-key.pem
- # Tell the autoscaler the allowed node types and the resources they provide.
- # The key is the name of the node type, which is just for debugging purposes.
- # The node config specifies the launch config and physical instance type.
- available_node_types:
- ray.head.default:
- # You can override the resources here. Adding GPU to the head node is not recommended.
- # resources: { "CPU": 2, "Memory": 4096}
- resources: {}
- worker:
- # The minimum number of nodes of this type to launch.
- # This number should be >= 0.
- min_workers: 1
- max_workers: 3
- # You can override the resources here. For GPU, currently only NVIDIA GPU is supported. If no ESXi host can
- # fulfill the requirement, the Ray node creation will fail. The number of created nodes may not meet the desired
- # minimum number. The vSphere node provider will not distinguish the GPU type. It will just count the quantity:
- # mount the first k random available NVIDIA GPU to the VM, if the user set {"GPU": k}.
- # resources: {"CPU": 2, "Memory": 4096, "GPU": 1}
- resources: {}
- worker_2:
- # The minimum number of nodes of this type to launch.
- # This number should be >= 0.
- min_workers: 1
- max_workers: 2
- # You can override the resources here. For GPU, currently only NVIDIA GPU is supported. If no ESXi host can
- # fulfill the requirement, the Ray node creation will fail. The number of created nodes may not meet the desired
- # minimum number. The vSphere node provider will not distinguish the GPU type. It will just count the quantity:
- # mount the first k random available NVIDIA GPU to the VM, if the user set {"GPU": k}.
- # resources: {"CPU": 2, "Memory": 4096, "GPU": 1}
- resources: {}
- # Specify the node type of the head node (as configured above).
- head_node_type: ray.head.default
- # Files or directories to copy to the head and worker nodes. The format is a
- # dictionary from REMOTE_PATH: LOCAL_PATH, e.g.
- file_mounts: {
- # "/path1/on/remote/machine": "/path1/on/local/machine",
- # "/path2/on/remote/machine": "/path2/on/local/machine",
- }
- # Files or directories to copy from the head node to the worker nodes. The format is a
- # list of paths. The same path on the head node will be copied to the worker node.
- # This behavior is a subset of the file_mounts behavior. In the vast majority of cases
- # you should just use file_mounts. Only use this if you know what you're doing!
- cluster_synced_files: []
- # Whether changes to directories in file_mounts or cluster_synced_files in the head node
- # should sync to the worker node continuously
- file_mounts_sync_continuously: False
- # Patterns for files to exclude when running rsync up or rsync down
- rsync_exclude: []
- # Pattern files to use for filtering out files when running rsync up or rsync down. The file is searched for
- # in the source directory and recursively through all subdirectories. For example, if .gitignore is provided
- # as a value, the behavior will match git's behavior for finding and using .gitignore files.
- rsync_filter: []
- # List of commands that will be run before `setup_commands`. If docker is
- # enabled, these commands will run outside the container and before docker
- # is setup.
- initialization_commands: []
- # List of shell commands to run to set up nodes.
- setup_commands: []
- # Custom commands that will be run on the head node after common setup.
- head_setup_commands: []
- # Custom commands that will be run on worker nodes after common setup.
- worker_setup_commands: []
- # Command to start ray on the head node. You don't need to change this.
- head_start_ray_commands:
- - ray stop
- - ulimit -n 65536; ray start --head --port=6379 --autoscaling-config=~/ray_bootstrap_config.yaml --dashboard-host=0.0.0.0
- # Command to start ray on worker nodes. You don't need to change this.
- worker_start_ray_commands:
- - ray stop
- - ulimit -n 65536; ray start --address=$RAY_HEAD_IP:6379
|