如上图所示，Ray集群包括一组同类的worker节点和一个集中的全局控制存储（GCS）实例。
部分系统元数据由GCS管理，GCS是基于可插拔数据存储的服务，这些元数据也由worker本地缓存，例如Actor的地址。 GCS管理的元数据访问频率较低，但可能被群集中的大多数或所有worker使用，例如，群集的当前节点成员身份。这是为了确保GCS性能对于应用程序性能影响不大。
大部分系统元数据是根据去中心化理念（ownership）进行管理的：每个工作进程都管理和拥有它提交的任务以及这些任务返回的“ ObjectRef”。Owner负责确保任务的执行并促进将ObjectRef解析为其基础值。类似地，worker拥有通过“ ray.put”调用创建的任何对象。
OwnerShip的设计具有以下优点（与Ray版本<0.8中使用的更集中的设计相比）：
低任务延迟（〜1 RTT，<200us）。经常访问的系统元数据对于必须对其进行更新的过程而言是本地的。
高吞吐量（每个客户端约10k任务/秒；线性扩展到集群中数百万个任务/秒），因为系统元数据通过嵌套的远程函数调用自然分布在多个worker进程中。
简化的架构。owner集中了安全垃圾收集对象和系统元数据所需的逻辑。
提高了可靠性。可以根据应用程序结构将工作程序故障彼此隔离，例如，一个远程调用的故障不会影响另一个。
OwnerShip附带的一些权衡取舍是：
要解析“ ObjectRef”，对象的owner必须是可及的。这意味着对象必须与其owner绑定。有关对象恢复和持久性的更多信息，请参见object故障和object溢出。
目前无法转让ownership。
核心组件
Ray实例由一个或多个工作节点组成，每个工作节点由以下物理进程组成：
一个或多个工作进程，负责任务的提交和执行。工作进程要么是无状态的（可以执行任何@ray.remote函数），要么是Actor（只能根据其@ray.remote类执行方法）。每个worker进程都与特定的作业关联。初始工作线程的默认数量等于计算机上的CPU数量。每个worker存储ownership表和小对象：
a. Ownership 表。工作线程具有引用的对象的系统元数据，例如，用于存储引用计数。
b. in-process store，用于存储小对象。
Raylet。raylet在同一群集上的所有作业之间共享。raylet有两个主线程：
a. 调度器。负责资源管理和满足存储在分布式对象存储中的任务参数。群集中的单个调度程序包括Ray分布式调度程序。
b. 共享内存对象存储（也称为Plasma Object Store）。负责存储和传输大型对象。集群中的单个对象存储包括Ray分布式对象存储。
每个工作进程和raylet都被分配了一个唯一的20字节标识符以及一个IP地址和端口。相同的地址和端口可以被后续组件重用（例如，如果以前的工作进程死亡），但唯一ID永远不会被重用（即，它们在进程死亡时被标记为墓碑）。工作进程与其本地raylet进程共享命运。
其中一个工作节点被指定为Head节点。除了上述进程外，Head节点还托管：
全局控制存储(GCS)。GCS是一个键值服务器，包含系统级元数据，如对象和参与者的位置。GCS目前还不支持高可用，后续版本中GCS可以在任何和多个节点上运行，而不是指定的头节点上运行。
Driver进程(es)。Driver是一个特殊的工作进程，它执行顶级应用程序（例如，Python中的__main__）。它可以提交任务，但不能执行任何任务本身。Driver进程可以在任何节点上运行。
交互设计应用的Driver可以通过以下方式之一连接到Ray：
调用`ray.init()’，没有参数。这将启动一个嵌入式单节点Ray实例，应用可以立即使用该实例。