分布式基础设施已是常态。
运维不该各自为政。
每个集群都有各自的标签页、凭据和端点。
只有同时询问多个人，才能掌握整个基础设施的情况。
同一套基础设施，从一处访问，遵循同一策略。
集中掌握运维情况。现有监控系统仍在原处运行。
Orcastra 适合用在哪里？
选择与你的基础设施最相近的场景。
你的服务器。你的云。一处即可运维。
雅加达有一个集群，泗水也有一个集群，由同一个团队同时监控。
销售你的云，而不是供应商的仪表盘。
众多客户，多个集群，一支运维团队。
证明谁基于谁的授权访问了哪些资源。
开发者需要的是一台 VM，而不是一张等三天的工单。
GPU 价格昂贵。你需要知道谁在使用它们。
服务器宕机，网络中断，SSH 也随之失联。
构建私有云。
别让基础设施团队头疼。
服务器归你所有。你希望虚拟机和容器持续运行在自己的基础设施上。
但你不想逐个管理每个节点、集群、项目、网络和存储池。
Orcastra 成为 LXD、Incus 或 MicroCloud 之上的管理层。
在一处管理虚拟机、容器、网络、存储、项目和集群。
无论各个集群运行在哪种平台上，都能同时运维。
不同团队拥有不同的访问权限，并可限定到具体资源。
你可以查看谁在何时对哪个集群执行了什么操作。
底层集群保持原生，不会重写任何内容。
关闭 Orcastra，集群仍会继续运行。
雅加达有一个集群。
泗水有一个集群。
仍由同一个团队同时监控。
基础设施会随站点、业务需求或项目不断扩展。
最终，同一个团队不得不打开多个仪表盘、一个 VPN、一个终端和一份电子表格，只为了解所有基础设施的运行情况。
Orcastra 让各个站点以一套完整、清晰的基础设施呈现。
哪些站点在线，哪些已停止响应。
各可用区实际还有多少计算资源可用。
明确列出无法访问的节点，而不是用平均值掩盖问题。
在引发服务中断之前，找出即将到期的集群证书。
销售你的云。
而不是供应商的仪表盘。
本地云服务提供商不必从零构建完整的控制平面。
Orcastra 可以作为你所销售云服务背后的基础设施层。
你的基础设施。你的客户。你的品牌。
每个客户的环境均与其他客户相互隔离。
集群内的网络、镜像、配置文件和存储边界。
按客户分配 CPU、内存和存储，并根据节点容量进行校验。
连接你自己的门户，无需授予管理员权限。
你的徽标，你的品牌，你的客户体验。
访问客户控制台必须主动发起、全程记录，并对客户可见。
已经在用 Orcastra？
把容量发布到 OrcaHub。
Orcastra 为云服务商提供控制平面，却不会带来客户。OrcaHub 补上另一半：独立云服务商在这个云市场上架容量，开发者直接在上面部署。
OrcaHub 以 Orcastra 作为参考控制平面，因此已在使用 Orcastra 的服务商可以从熟悉的环境起步。集群保持原生、由你掌控，改变的只是谁能找到它们。
- 01照常运维
集群、项目和配额仍在 Orcastra 中管理，RBAC 与审计记录不变。
- 02确定售卖内容
决定哪些区域、多少 CPU、内存和存储作为资源池出售，以及定价。
- 03在云市场上线
审核通过的资源池与其他服务商一起出现在 hub.orca.id，订单与计费由 OrcaHub 处理。
众多客户。
多个集群。
一支运维团队。
客户 A 运行 MicroCloud，客户 B 运行 LXD，客户 C 运行 Incus。
每套环境都不一样，但接到故障电话的仍是你的团队。
所有客户集群尽收一份资源清单，无需逐一登录。
无需在密码管理器中永久保存常驻管理员凭据。
工程师可执行的操作按客户限定，而非全局授权。
每个会话都会记入其访问的客户名下。
托管服务应让客户保有控制权，而不是要求客户永久交出所有管理员凭据。
审计人员不只会问：
“系统安全吗？”
他们会提出具体问题，并期望答案早已备妥。
让技术栈现代化。
同时保持清晰易懂。
适合开始构建开源私有云，或希望减少对专有虚拟化技术栈依赖的组织。
工作负载在 LXD、Incus 或 MicroCloud 上运行后，Orcastra 负责管理目标基础设施，但不执行迁移本身。
开发者需要一台 VM。
不该等三天工单。
为每位工程师提供一个项目、一个 shell 和一个带作用域的令牌，同时让平台团队在一处查看全局。
门户使用的密钥只能访问你指定的项目，并据此创建资源。
平台团队用一份资源清单统一掌握开发者接触的所有环境。
GPU 成本高昂。
至少要知道谁在使用。
适用于企业 AI 实验室、高校 AI 中心、GPU 私有云、机器学习团队或科研基础设施团队。
Orcastra 显示节点实际安装的 GPU，并支持直通其中一张。它不是调度器，也不报告利用率数据。
如果节点未报告 GPU，选择器会直接说明，而不是显示空列表。
有哪些显卡、位于哪个节点，以及还有多少未分配。
选择目标节点上的物理 GPU，或输入 PCI 地址。
GPU 实例归属于一个项目，因此每项分配都有明确负责人。
一套基础设施。
服务众多实验室、教师、学生和项目。
共享计算资源划分为多个项目，各有边界与限额。
服务器宕机。
网络中断。
SSH 也随之失联。
有时，仪表盘并不足够。你只需要一条重新进入机器的通道。
控制台和终端通过集群自身的通道运行，因此不需要公网 IP、SSH 守护进程，也不要求客户机网络正常工作。
root@recovery-01:~# mount -o remount,rw / root@recovery-01:~#
该通道属于集群，而非客户机网络。
无需事先在实例内安装或运行任何组件。
在同一窗口上传并挂载 ISO，然后从固件启动。
将文件拖到终端，即可传入实例。
每年只检查一次的灾备站点
称不上灾难恢复策略。
Orcastra 不执行复制，也不能替代灾难恢复编排系统。它为你提供恢复基础设施的可见性和运维访问能力。
基础设施团队只有四人。
服务器却多达数百台。
基础设施可以持续扩展，运维团队无需随之扩编。
让 AI 读取基础设施。
但不要把 root 权限交给它。
Orcastra 不是模型。控制平面内不运行任何 LLM。
它提供 MCP 服务器，让团队已在使用的助手通过你限定作用域且可撤销的密钥读取整套基础设施。
代理最初只能查询现有资源，仅此而已。
每项能力单独授予，而非通过一个角色隐含授予其余能力。
与人员操作一样，每次代理调用都会记录执行者和结果。
撤销密钥，所有持有该密钥的代理会同时停止。
不同场景分别侧重哪些能力。
每种部署都提供全部能力。此处只是展示各场景通常会优先使用哪些能力。
行业各不相同。
运维难题如出一辙。
无论你是企业、云服务提供商、托管服务提供商、高校、政府机构、研究中心、电信运营商、银行还是制造商，面对的问题通常都一样。
基础设施分散各处，工具数量过多，访问权限越来越难控制。基础设施规模越大，回答一个简单问题就越困难。
我们拥有哪些资源？
它们在哪里？
谁可以访问？
哪里出了故障？
还剩多少容量？
Orcastra 在一处回答全部五个问题。
基础设施不变。
运维层更出色。
底层三种平台，上层一套运维模式。各站点按需选择，统一管理。
在一个平台中同时运行虚拟机和系统容器。
围绕 LXD、MicroCeph 和 MicroOVN 构建的精简私有云技术栈。
由社区驱动的系统容器和虚拟机管理器。
Orcastra 不会接管
你的基础设施。
LXD 仍是 LXD，Incus 仍是 Incus，MicroCloud 仍是 MicroCloud。
你的工作负载继续以原有格式留在底层平台上。
即使关闭 Orcastra，集群仍会一如既往地运行。
采用 GPLv3，代码仓库公开，且没有贡献者许可协议。
一个控制平面。
你的基础设施始终属于你。
跨集群、站点、团队和客户管理 LXD、Incus 与 MicroCloud。