边缘存储架构师指南

当前边缘计算的时代还处于起步阶段。尽管如今边缘计算市场规模已达60亿美元，并预计到2028年将增长至610亿美元，但这仍然是一个令人瞩目的声明。尽管5G刚刚开始普及，物联网（IoT）经济蓬勃发展，但事实是我们并不知道它最终会发展到多大，或者速度有多快。

MinIO架构系列的这一期将重点关注边缘的存储。在边缘端正确处理数据可以确保可扩展、经济高效且安全的基础设施。另一方面，如果未能建立正确的架构，会导致数据丢失、安全漏洞以及与将数据反复传输到公共云和从公共云传输到公共云相关的带宽成本过高。

我们的目标是提供指导，帮助您实现前者。

为什么选择边缘？

边缘计算将内容、数据和处理能力放置在更靠近使用和交互的应用程序、事物和用户的位置。边缘计算的主要挑战是在不进行大量基础设施投资的情况下，实现一种带宽优化的架构，以提供性能、弹性和安全性。

从架构的角度来看，带宽是一个关键的考虑因素，原因很明显：每 GB 的带宽成本比存储成本高 4 倍（例如，AWS 上的带宽成本为 0.023 美元，存储成本为 0.09 美元）。

边缘的兴起是数据增长地点的函数。虽然很多注意力都集中在数据中心上，但许多分析师预计，在一两年内，企业在数据中心之外创建的数据将超过在数据中心内创建的数据。

我们将涵盖边缘存储的两种模型（边缘存储和边缘缓存）以及取得成功的要求。让我们从模型开始。

边缘存储

当目标是在边缘执行处理和分析时，边缘存储模型被使用，它会过滤掉噪声，只保留/发送与这些见解相关联的见解和数据。在这个模型中，应用程序、计算和存储都存在于边缘，并被设计为在本地存储和处理数据。目标不是在边缘存储 PB 级的数据，而是这个模型设想的是 100 GB 到几 PB 的数据。从视觉上看，它看起来像这样

在最偏远的边缘，您拥有数据生成设备，以及存储和计算/分析。计算/分析可以是像 Splunk DSP 这样的东西，也可以是深度神经网络模型开发，但关键点是，在远程边缘存在 ETL、处理和洞察生成。这些实例是容器化的，并通过 Kubernetes 作为数据管道进行管理。

Kubernetes 是边缘架构的关键推动者，它实际上要求存储是解耦的和基于对象的。

为了完成架构，您需要添加一个负载均衡器，另一个 Kubernetes 层，然后在更中心的位置拥有一个源对象存储服务器和应用程序层（训练模型、进行大规模分析等）。

这种模式被像 Chick-fil-A 这样的餐厅使用。它被用于人脸识别系统。它是制造用例以及 5G 用例的默认设计。

在每种情况下，都存在足够的存储和计算资源，在现场或经济上接近的位置学习数据。

让我们以一辆汽车从传感器中生成数据为例，这是一个 MinIO 拥有大量部署经验的领域。收集数据的目的是构建和训练机器学习模型。汽车内部没有足够的计算资源来进行训练，而训练是 GPU 密集程度最高的部分。在这种情况下，数据被发送到边缘数据中心来构建和训练机器学习模型。模型训练完成后，可以将其发送回汽车，并用于从传感器传入的新数据中做出决策并得出结论。

从地理位置上分散训练和处理是有意义的，这样可以尽可能地靠近设备。

最终，这些数据将最终存储在云端（公共云或私有云）。数据将迅速积累，对于自动驾驶汽车来说，很快就会达到多个 PB 的规模。因此，您需要在边缘和云端使用相同的存储。

对象存储是云端的首选存储。因此，对象存储也是边缘的首选存储。我们将在下面讨论边缘存储需要具备哪些属性。但现在重要的是要注意，传统的 SAN/NAS 系统不灵活，而且通常与这些用例不兼容，因为数据处理应用程序正在原生采用 S3 API。

虽然有些人将边缘与私有云混为一谈，但这是错误的。目前，公共云、私有云和边缘的定义在根本上是模糊的。它们都从相同的实践中汲取灵感，即容器化、编排、RESTful API、自动化和微服务。这种“分类”是架构师优化的功能（性能、经济性、安全性、弹性和可扩展性）。

边缘缓存

回顾边缘的第一条规则，将带宽视为最高成本组件（在 AWS 上高 4 倍），我们得出第二种核心边缘用例：边缘缓存。边缘缓存并不是一个新概念，因为内容分发网络 (CDN) 已经有几十年的历史了，但它也是一个对象存储再次改变了规则的领域。CDN 需要与对象存储系统紧密集成，以维护对象的安全性 and 一致性模型。

在这个模型中，边缘充当网关缓存，在应用程序和公共云之间创建了一个中间层。在这种情况下，网关由配备有大量硬盘驱动器或闪存驱动器的服务器支持，并在世界各地的边缘数据中心部署。它看起来像这样

所有对公共云的访问都通过这些缓存（直写缓存）进行，因此数据被上传到公共云，并具有严格的一致性保证。后续的读取将根据 ETAG 匹配或缓存控制标头从缓存中提供。这种架构通过减少传输数据的带宽来降低成本，通过将数据缓存到更靠近应用程序的位置来提高性能，并降低运营成本——数据仍然保存在公共云中，但在边缘被缓存，因此即使边缘数据中心被烧毁，数据仍然存在。

借助 MinIO 的对象存储网关，您还可以使用无状态架构，无需管理。您只需部署一次，然后就无需再管它。添加一个节点、两个节点或两千个节点——都没有关系，它们在架构上彼此独立，完全无状态。只需不断扩展。如果一个节点失效，让它失效。

边缘的属性

无论您在边缘构建哪种类型的架构，都需要在任何边缘存储系统中构建某些属性，无论是在边缘处理中心、物联网设备本身还是作为边缘缓存系统的一部分。首先，正如所指出的，存储需要基于对象，并且可以通过 HTTPs 访问。对象是边缘的默认模式。文件和块协议无法扩展到本地网络之外。

然而，该对象存储还有一些额外的要求，如下所示

弹性

弹性对于边缘存储至关重要。对于熟练的工程师来说，物理访问和维护物联网设备或边缘数据中心更加困难。同时，物联网设备中的驱动器，甚至边缘数据中心中的驱动器，所承受的物理条件比传统数据中心中的驱动器要恶劣。

这些架构，特别是存储组件，需要能够就地失效。驱动器故障会发生。如果没有正确的架构，驱动器故障会导致数据丢失。除了丢失数据之外，更换驱动器还会成为运营噩梦，因为它们需要经验丰富的技术人员前往地理位置分散的数据中心或访问数千个边缘设备。

存储架构使用自我修复和自动化来确保即使驱动器出现故障数据也是安全的，并在特定边缘位置的所有驱动器都出现故障时自动故障转移到其他数据中心，这一点至关重要。

软件定义 + 容器友好 + 开源

软件定义存储解决方案提供了传统系统所不具备的灵活性。它们可以轻松地在各种硬件平台上运行，并且可以轻松地从远处维护。

此外，软件定义存储解决方案在容器化和编排方面更加出色。您可能还记得，无法容器化硬件设备。鉴于需要启动/停止和扩展/缩减边缘解决方案，Kubernetes 友好的解决方案是必需的。

第三，解决方案需要是开源的。对于电信公司来说，这是一个必须，因为他们长期以来一直认识到开源的价值（参见 O-Ran），但对于其他行业来说，这也是重要的，因为他们需要免受锁定、自由检查和自由创新的权利，这些都是选择过程的关键因素。开源的另一个被低估的价值主张是易于采用——它是在大量异构配置中运行的，并且以专有软件无法实现的方式得到强化。

无状态的

边缘存储系统需要由完全可丢弃的物理基础设施构成。如果发生火灾，不应该有数据丢失。如果发生事故，也不应该有数据丢失。关键状态应该存储在公共云中，以便各个硬件元素可以丢弃。

在边缘环境中，不可能将驱动器视为宠物。它们几乎总是会受到更恶劣的物理条件的影响，这不仅使它们面临故障风险，而且也面临数据损坏的风险。

速度

数据处理速度越快，业务决策速度就越快。速度是将数据处理从传统数据中心和公共云迁移到边缘计算的主要原因之一。能够加速数据处理和数据传输对于充分利用边缘计算至关重要。

即使处理位于边缘的数据中心，延迟也很难解决。成功的架构师会在任何可能的地方解决延迟问题。一个广泛使用的技术是在内存中处理和分析数据，以消除磁盘引入的延迟。在边缘实现速度需要消除对高延迟网络的任何依赖关系。

轻量级

边缘设备体积小。为了使存储系统在边缘环境中可行，它必须在极少的计算和存储资源的情况下提供速度、弹性和安全性。能够在资源较少的设备（例如树莓派）上运行对于构建一个可能运行在物联网设备中单个固态硬盘上的存储系统至关重要。然而，关键在于，单个固态硬盘必须从应用程序和 API 的角度来看，像一个完整的服务器一样。

安全性

无法完全确保边缘数据中心或物联网设备的物理安全性。确保数据在静止和传输过程中的加密至关重要，因为在边缘数据中心周围部署与传统数据中心相同的物理安全措施是不切实际的，在物联网设备的情况下更是不可能。驱动器在边缘的物理脆弱性使得加密变得至关重要，即使数据被访问，也无法读取或篡改。

总结

在边缘环境中，设计合适的架构至关重要。本文介绍了两种模型，一种是在边缘收集数据，另一种是将数据推送到边缘。虽然这些模型在本质上有所不同，但存储选择却相同：对象存储。