边缘存储架构师指南

当前一代的边缘计算仍处于起步阶段。鉴于其目前的规模（60 亿美元）和增长预期（到 2028 年将达到 610 亿美元），这是一个了不起的声明。尽管如此，随着 5G 刚刚站稳脚跟，物联网 (IoT) 经济呈爆炸式增长，事实是我们真的不知道它会变得有多大或多快。

MinIO 的架构师系列中的这一部分重点关注边缘存储。在边缘正确处理数据可以确保可扩展、经济高效且安全的基础架构。另一方面，未能设置正确的架构可能会导致数据丢失、安全漏洞以及与反复向公共云传输数据和从公共云传输数据所需的带宽相关的天价成本。

我们旨在为实现前者提供指导。

为什么是边缘？

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

从架构的角度来看，带宽是一个关键的考虑因素，原因很明显：它每 GB 的成本是存储的 4 倍（例如，AWS 上的 .023 与 .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 需要紧密集成到对象存储系统中，以维护对象的安全性和一致性模型。

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

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

使用 MinIO 的对象存储网关，还可以采用零管理的无共享架构。你部署一次就忘了它。添加一个节点、两个节点、两千个节点——没关系，它们在架构上相互独立并且完全无状态。继续缩放。如果一个节点死了，就让它去吧。

边的属性

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

但是，该对象存储还有其他要求，如下所示：

弹力

弹性对于边缘存储至关重要。熟练的工程师更难物理访问和维护物联网设备或边缘数据中心。与此同时，物联网设备中的驱动器——甚至是边缘数据中心中的驱动器——比传统数据中心的驱动器要经受更严酷的物理条件。

这些架构，尤其是存储组件，需要能够原地发生故障。会发生驱动器故障。如果没有正确的架构，驱动器故障可能会导致数据丢失。除了丢失数据外，更换驱动器可能是一场运营噩梦，因为它们需要经验丰富的技术人员访问地理分布的数据中心和/或处理数千台边缘设备。

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

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

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

此外，软件定义的存储解决方案更适合容器化和编排。您可能还记得，不可能将硬件设备容器化。鉴于需要增加/减少和增长/缩小边缘解决方案，需要一个 Kubernetes 友好的解决方案。

第三，解决方案需要开源。这对于长期看到开源价值的电信公司（参见O-Ran）来说是一个给定的条件，但对于其他行业也很重要，在这些行业中，免于锁定、自由检查和自由创新都是选择过程的关键. 开源的另一个未被充分认识的价值主张是易于采用——它在高度异构的配置中运行，并且以专有软件永远无法达到的方式强化。

无国籍

边缘存储系统需要由完全一次性的物理基础设施组成。如果它们着火，应该不会丢失数据。如果发生意外，应该不会有数据丢失。关键状态应存储在公共云中，以便可以一次性使用各个硬件元素。

不可能将边缘驱动器视为宠物。他们几乎无一例外地要承受更艰难的身体条件，这使他们不仅面临失败的风险，而且面临腐败的风险。

速度

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

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

轻的

边缘设备很小。要使存储系统在边缘可行，它必须以极少的计算和存储资源提供速度、弹性和安全性。在低资源设备（例如Raspberry Pi）上运行的能力对于构建可能在 IoT 设备中的单个固态驱动器上运行的存储系统至关重要。然而，关键是从应用程序和 API 的角度来看，单个固态驱动器的外观和行为必须像一个成熟的服务器。

安全

没有办法完全确保边缘数据中心或物联网设备的物理安全。确保静态和传输中的加密至关重要，因为在边缘数据中心周围放置与传统数据中心周围相同的物理安全措施是不切实际的——对于物联网设备来说这是不可能的。边缘驱动器的物理脆弱性使得加密必不可少，因此即使数据被访问，也无法读取或篡改。

概括

设计合适的架构在边缘世界中至关重要。这篇文章介绍了两种模型，一种是在边缘收集数据，另一种是将数据推送到边缘。虽然模型根本不同，但存储选择是相同的：对象。