边缘存储

边缘计算是一个热门话题，也带来了一些困惑，尤其是在存储方面。在边缘正确处理数据可以确保基础设施的可扩展性、成本效益和安全性，但如果未能建立正确的架构，则可能导致数据丢失、安全漏洞以及与将数据反复传输到公共云和从公共云传输到公共云相关的过高带宽成本。从架构的角度来看，带宽是一个关键的考虑因素，其原因很明显：每 GB 的成本是存储的 4 倍（例如，在 AWS 上分别为 0.023 美元和 0.09 美元）。

虽然有多种模型，但最终，我们认为可以将其简化为两种：边缘存储和边缘缓存。本文将探讨这两种模型，并阐明实现这些模型所需的关键存储属性。

边缘存储

当目标是在边缘进行处理和分析，过滤掉噪音并仅保留/发送与这些洞察相关的洞察和数据时，就会采用边缘存储模型。在此模型中，应用程序、计算和存储存在于边缘，并设计为原位存储和处理数据。目标不是在边缘存储 PB 级的数据，而是此模型设想存储数百 GB 到几 PB 的数据。视觉效果如下所示

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

Kubernetes 有效地强制要求存储被分解并基于对象。

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

这种模型被像Chick-fil-A这样的餐厅采用。它用于面部识别系统。它也是制造用例和 5G 用例的默认设计。

在每种情况下，现场或在经济上接近的位置都有足够的存储和计算能力来从数据中学习。

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

将训练和处理地理分布到尽可能靠近设备的位置是有意义的。

最终，这些数据将最终进入云（公有或私有）。它将迅速累积，并且在自动驾驶汽车的情况下，很快就会达到多个 PB。因此，您需要在每端使用相同的存储——在边缘和云中。

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

关于私有云的简要说明。一些人将边缘与私有云混淆，但这是一个错误。私有云是一种新兴力量，随着传统 IT 采用公有云的实践和方法而蓬勃发展——从 RESTful API 到微服务和容器化。私有云看起来和感觉起来都像公有云，但具有更高的经济效益、数据安全性和性能。

边缘是不同的。边缘是一个全新的世界。

是的，它遵循集中化 -> 分散化 -> 集中化 -> 分散化的周期性技术路径，但它利用了以前根本不存在的端点——汽车、摄像头、移动应用程序和设备，以及以前不存在的技术——用于高性能、轻量级对象存储和 AI/ML。因此，需要一个新的架构框架。

边缘缓存

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

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

所有对公有云的访问都通过这些缓存（直写缓存）进行，因此数据以严格的一致性保证上传到公有云。后续读取基于 ETAG 匹配或缓存控制标头从缓存中提供服务。此架构通过减少传输数据所需的带宽来降低成本，通过将数据缓存到更靠近应用程序的位置来提高性能，并降低运营成本——数据仍然保存在公有云中，只是在边缘缓存，因此如果边缘数据中心发生火灾，数据仍然存在。

使用 MinIO 的对象存储网关，还可以采用无需管理的共享无状态架构。您只需部署一次，然后忘记它。添加一个节点、两个节点、两千个节点——无关紧要，它们在架构上彼此独立且完全无状态。只需继续扩展即可。如果一个节点死机，就让它去吧。

边缘的属性

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

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

弹性

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

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

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

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

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

此外，软件定义存储解决方案在容器化和编排方面也更胜一筹。正如我们所写的那样，不可能将硬件设备容器化。鉴于需要启动/停止和扩展/缩减边缘解决方案，因此需要一个 Kubernetes 友好的解决方案。

第三，解决方案需要是开源的。对于长期以来一直重视开源价值的电信公司来说，这是一个既定事实，但对于其他行业来说也很重要，在这些行业中，摆脱锁定、自由检查和自由创新是选择过程的关键。开源的另一个被低估的价值主张是易于采用——它在大量异构配置中运行，并且以专有软件永远无法实现的方式得到强化。

无状态

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

不可能将边缘的驱动器视为宠物。它们几乎肯定会受到更恶劣的物理条件的影响，这使得它们不仅面临故障风险，还面临损坏风险。

速度

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

即使处理位于边缘的数据中心，延迟也很难解决。构建能够快速处理数据的应用程序需要以这样一种方式设计系统，即应用程序能够在内存中处理数据。边缘速度的关键是消除对高延迟网络的任何依赖关系。

轻量级

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

安全性

无法完全确保边缘数据中心或物联网设备的物理安全性。确保数据在存储和传输过程中的加密至关重要，因为在边缘数据中心周围部署与传统数据中心相同的物理安全措施是不切实际的——对于物联网设备来说更是完全不可能的。边缘设备硬盘的物理易损性使得加密变得至关重要，即使数据被访问，也无法读取或篡改。

总结

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

此外，对象存储需要围绕弹性、性能、安全性和灵活性的某些属性，从而缩小了考虑范围。

与以往一样，我们鼓励大家做出自己的判断。我们的软件 100% 开源，您可以从这里下载。我们的文档可从这里获取，并且我们的公共 Slack 频道被认为是黄金标准。

如果您已经在边缘运行我们的软件——我们鼓励您发送邮件至hello@min.io，并告诉我们更多关于您的部署信息。我们一直在寻找机会来展示您的故事。