本文由 简悦 SimpRead 转码， 原文地址 blog.csdn.net
作者：来自 Elastic Nima Rezainia
在当今的全球化企业中，分布式基础设施是常态而非例外。组织跨洲运营，并由客户就近需求和监管要求驱动。对于 Elastic Stack 而言，这种现实通常转化为多集群部署模型，即在多个地理位置分散的 Elasticsearch 集群中采集和存储数据。
但是，为什么要采用这种复杂性？去中心化数据存储的决策通常由三个关键因素驱动：
-
数据主权与监管合规：对于在欧盟、澳大利亚或中国等地区运营的组织，法律规定某些类型的数据（如个人数据、财务数据或国家安全数据）必须实际存放在该国境内。这一概念被称为数据主权，是不可协商的。将数据本地存储在专用集群中是满足这些严格且往往复杂的监管要求的唯一方式。
-
性能、延迟与成本优化：虽然统一平台非常适合分析，但跨洲传输大量原始数据在成本和时间上都是难以承受的。
- 成本：跨区域数据传输成本（egress 费用）是一项重要且持续的开支。本地化数据采集可以将这些成本降到最低。
- 延迟：将 agent 数据发送到数百或数千英里外的集群可能会引入不可接受的延迟，尤其是对于对性能敏感的应用或低带宽的 edge 设备。本地集群可确保快速、可靠的数据摄取。
-
弹性与本地自治：多集群设计提升了整体系统的弹性。如果某个区域或本地集群发生故障，其他区域的数据摄取和本地操作仍不受影响。此外，本地运维团队可以对其直接相关的数据和索引保持自治，这在高度分割的组织中至关重要。
许多 Fleet 部署涉及安装在不同位置的 Elastic Agents，这要求数据存储在本地集群中。然而，运维人员需要对所有 agents 有一个统一视图，并需要一个用于升级、策略管理和指标采集等任务的集中管理界面。
统一全局 Fleet 管理
随着近期增强功能的推出（在 9.1 中可用），Elastic Fleet 已从单集群管理器转变为真正的全局 Fleet 管理平台，在保留本地化数据优势的同时解决了分布式管理问题。
核心创新简单而强大：将 agent 的数据目的地与 agent 的管理控制平面分离。
全局 Fleet 管理：集中控制，本地数据
该能力使运维人员在不牺牲数据主权、也不产生高额 egress 成本的情况下，实现关键的 “单一视图”。
工作原理：
- 本地数据路由：Elastic Agent 仍配置为将其运行和可观测性数据（例如 logs、metrics、security events）发送到本地 Elasticsearch 集群。
- 集中控制：同时，包含其状态、版本和健康信息的 agent check-in 负载会被路由到中央管理集群。
结果是，中央管理集群中的 Fleet 能够维护全球范围内每一个已部署 agent 的统一视图，即使大部分摄取的数据仍然驻留在本地。运维人员可以立即获得用于以下集中化任务的高层概览：
- 监控所有区域的 agent 健康状态
- 安排并协调全 Fleet 升级
- 全局组织 agent 策略
- 维护所有分布式资产的完整清单
- 集中下发操作并分析来自不同 agent 的响应
2. 集成同步：在规模化下强制一致性
在分布式模型中，在数十个集群之间保持一致的安全和可观测性标准可能是最大的挑战。集成同步通过确保所有远程集群自动接收与管理集群相同的集成内容，直接解决了这一问题。
同步优势：
- 一次安装，全局部署：运维人员现在只需在中央管理集群中安装一次新的集成，例如新的监控包。Fleet 负责在所有已连接的远程 Elasticsearch 集群之间可靠地同步并更新该集成。
- 统一的服务操作：这种一致性对 OSquery 等服务至关重要。你可以在中央集群中安装 OSquery 集成，Fleet 会确保所有 agents 无论其数据目的地在哪里，都运行完全相同的配置。随后，运维人员可以从中央管理集群发起服务操作，来自不同地理位置 agents 的响应会被汇总并显示在中央 Fleet UI 中。
- 预构建数据视图：为了让跨这些集群的安全和可观测性分析更加顺畅，Fleet 现在还支持使用预构建的数据视图。这消除了手动拼接零散数据源的工作，使分析人员能够像查询一个逻辑空间中的数据一样进行查询，从而实现多集群用户所期望的统一分析。
空间感知：企业级隔离
对于将 Elastic 作为 “data-as-a-service” 平台为内部或外部租户运行的团队来说，简单的全局管理还不够；他们需要隔离和精细化控制。为支持这一企业级用例，Fleet 引入了空间感知和细粒度角色权限。此前，Fleet 中的所有用户可能都能查看和修改所有内容。现在，运维人员可以：
- 定义细粒度角色权限：为角色指定针对 agents、agent policies 或 Fleet 设置的读写访问权限。例如，专门的安全团队可以仅被授予访问特定 agent policies 的权限，而服务台团队可能只获得 agents 标签页的访问权限用于排障。
- 使用空间隔离：自 9.1 起，Fleet 已完全支持空间感知。一个 Kibana Space（代表一个租户或特定团队）中的角色和用户将无法访问另一个空间中的 Fleet 资源。一个 agent policy 可以分配给一个或多个空间，从而精确控制谁可以管理哪些策略，以及由此管理哪些 agents。
这使组织能够构建高度精细的平台，在保持对核心平台和全局策略集中、权威控制的同时，赋能下游租户具备本地化管理能力。
复杂性得到管理
Fleet 中 Elastic 的新多集群能力直接解决了长期存在的张力：一方面是出于合规和成本需要而进行分布式数据存储，另一方面是为了简化和一致性而进行集中化管理的运维需求。
通过提供 Global Fleet Management、Space Awareness 和 Integration Synchronization，Elastic 为全球化运维交付了真正的 “single pane of glass”。平台团队现在可以自信地在任意数量的集群上扩展 Elastic Agent 部署。安全和可观测性策略得到一致执行，同时团队严格遵守数据主权规则，并将不必要的跨区域成本降到最低。
如果你当前正在运行分布式 Elastic 架构，或正在规划全球扩展，这些功能对于在规模化下释放效率和一致性至关重要。
了解更多
