在第2部分中，我们将深入探讨HDD和SSD之间的差异，HDD和SSD技术如何发展，以及如何在我们的运营和数据中心中利用SSD。

第一次在具有固态驱动器（SSD）的计算机上启动计算机或打开应用程序时，您可能很高兴。我知道我是。我喜欢这种新技术的速度，沉默和令人惊叹的因素，与硬盘驱动器相比，它几乎在所有方面看起来都更好。

我已经准备好完全接受SSD的承诺了。我有。我的桌面使用SSD进行引导，应用程序和工作文件。我的笔记本电脑有一个512GB的SSD。不过，我仍然使用硬盘。我的台式计算机中的第二，第三和第四个驱动器是HDD。我用于本地备份的外部USB RAID使用四个驱动器托架中的HDD。当我的笔记本电脑放在我的桌面时，它连接到1.5TB USB备份硬盘。硬盘驱动器在我的个人计算环境中仍然占有一席之地，因为它们可能在您的个人计

然而，长期以来，没有什么能保持不变，特别是在快速变化的计算世界中，所以我们肯定会看到新的存储技术脱颖而出，可能还有更多令人惊叹的因素。

在我们了解即将发生的事情之前，让我们在下表中更详细地回顾一下HDD和SSD之间的主要区别。

HDD与SSD的比较

电力消耗/电池寿命更多功耗，

• HHD:平均为6-7瓦，因此使用更多电池更少的功耗，
• SSD: 平均2-3瓦，导致30+分钟的电池提升

成本

• HHD: 仅为每千兆字节0.03美元，非常便宜（购买4TB型号）昂贵，
• SSD: 大约0.20美元至0.30美元每千兆字节（基于购买1TB硬盘）

容量

通常为笔记本电脑大小的驱动器大约500GB和2TB;

台式机最大10TB笔记本电脑尺寸驱动器通常不超过1TB;适用于台式机的4TB

操作系统启动时间

• 大约30-40秒平均启动时间
• 大约8-13秒平均启动时间

噪音

• 可听到咔嗒声和旋转盘片没有活动部件，因此没有声音
• 振动盘片的旋转有时会导致振动没有振动，因为没有活动部件

热量

• 产生的硬盘驱动器不会产生太多热量，但由于移动部件和更高的功率消耗，它将具有比SSD更多的可测量的热量
• 更低的功率消耗和没有移动部件因此产生的热量很少

故障率

• 平均故障间隔时间为150万小时
• 平均故障间隔时间为200万小时

文件复制/写入速度

• 范围可以是50-120MB / s，通常高于200 MB / s，
• 高达550 MB / s用于尖端驱动器

加密

• 在某些型号上受支持全盘加密（FDE）
• 全盘加密（FDE）某些型号支持

文件打开速度

• 比SSD慢，
• 比HDD快30％

受磁力影响

• 磁铁可以擦除数据
• SSD不受任何磁力影响

坚固耐用

• 易受物理颠簸和运动影响
• 不易受到颠簸和振动的影响

硬盘的前景如何？

硬盘具有惊人的改进和创新历史。自1956年成立以来，硬盘的尺寸减少了57,000倍，存储量增加了100万次，成本降低了2000倍。换句话说，每千兆字节的成本在大约60年内减少了20亿次。

硬盘制造商通过减小盘片的尺寸，从而减少盘片的寻道时间，提高盘密度，改进磁盘读取技术，增加多臂和读/写头，开发更好的总线接口，提高旋转速度和减少，从而取得了这些显着进步。与诸如用氦气填充驱动器之类的技术摩擦。

2005年，驱动器行业引入了垂直记录技术来取代旧的纵向记录技术，这使得面密度达到每平方英寸100千兆位以上。纵向记录相对于驱动器的旋转盘片水平对齐数据位，平行于盘的表面，而垂直记录垂直对齐位，垂直于盘表面。

 

其他技术如位图案媒体记录（BPMR）也有助于提高密度。 BPMR于2010年由东芝推出，是一种可以成功实现垂直记录的硬盘驱动器技术。它使用纳米光刻技术在磁岛中记录数据，每个岛一位。这与当前的磁盘驱动器技术形成对比，其中每个位存储在连续磁性薄膜内的20至30个磁性颗粒中。

叠瓦式磁记录（SMR）是一种用于HDD的磁存储数据记录技术，用于提高存储密度和整体每驱动器存储容量。叠瓦式录音会写入与先前写入的磁道部分重叠的新轨道，使之前的轨道更窄并允许更高的轨道密度。因此，轨道部分地重叠类似于屋顶瓦片。选择这种方法是因为物理限制阻止记录磁头具有与读头相同的宽度，从而使记录头更宽。

 

为了增加存储在驱动器盘片上的数据量，需要将磁性区域更紧密地塞入，这意味着晶粒需要更小，以便它们不会相互干扰。 2002年，希捷成功演示了热辅助磁记录（HAMR）。 HAMR使用激光热辅助记录磁力，最终可能在2019年之前产生20TB的驱动器。（请参阅我们关于HAMR的文章，希捷的CTO Mark Re，什么是HAMR以及它如何实现未来的高容量需求？）

西部数据声称其竞争的微波辅助磁记录（MAMR）可以使驱动器容量在2025年之前增加到40TB。一些行业观察者和驱动器制造商预测面密度将从今天的0.86 tbpsi太比特每平方增加到到2025年，英寸（TBPSI）达到10 tbpsi，在未来十年内可提供高达100TB的驱动器容量。

除了热量和微波之外，正在研究的其他技术包括使用极冷来增加HDD密度。

对于继续与我们保持一段时间的硬盘驱动器，未来肯定会看起来很明亮。

固态硬盘的展望

固态硬盘也取得了一些惊人的进步。

接口

SATA（串行高级技术附件）是通用硬件接口，允许与HDD和SSD之间传输数据。 SATA SSD适用于大多数家庭用户，因为它们通常更便宜，速度更低，写入寿命更短。

虽然适用于日常计算，在RAID（独立磁盘冗余阵列），服务器阵列或数据中心环境中，但通常更好的选择是使用“SAS”驱动器，它代表串行连接SCSI。这是另一种类型的接口，同样可用于HDD或SSD。 'SCSI'代表小型计算机系统接口（这就是为什么SAS驱动器有时被称为'scuzzy'驱动器）。 SAS通过SATA增加了IOPS（每秒输入输出），这意味着它能够更快地读写数据。这使SAS成为需要高性能和可用性的系统的最佳选择。

在企业级别，SAS优先于SATA，因为SAS支持过度配置以延长写入寿命，并且专门设计为在需要持续驱动器使用的环境中运行。

输入PCIe

PCIe（Peripheral Component Interconnect Express）是一种高速串行计算机扩展总线标准，由于有更多可用于数据流的通道，因此可通过SATA或SAS接口支持极高的数据传输速率。

许多领先的驱动器制造商已经采用PCIe作为新家庭和企业存储以及一些外围设备的标准。例如，您会看到最新的Apple Macbook附带基于PCIe的闪存存储，这是Apple多年来一直采用的消费设备。

PCIe还可以在数据中心内用于RAID系统，并创建高速网络功能，提高整体性能并支持更新，更高容量的HDD。

存储密度

正如我们在第1部分中所述，SSD基于一种称为NAND的非易失性闪存.NAND闪存的最新趋势是四电平单元（QLC）NAND。 NAND基于在每个物理存储器单元中存储多少位数据而被细分为类型。 SLC（单级单元）存储一位，MLC（多级单元）存储两个，TLC（三级单元）存储三个，QLC（四级单元）存储四个。

 

每个单元存储更多数据会使NAND更加密集，但它也会使存储器变慢 - 当在存储器的同一单元内存储如此多的附加信息（以及更多的电荷状态）时，读取和写入数据需要更多时间。

QLC NAND存储器构建在较旧的工艺节点上，具有较大的单元，可以更容易地存储多位数据。 新的NAND技术具有更高的整体可靠性和更高的编程/擦除周期（P / E周期）。

 

QLC NAND承诺生产更快，更密集的SSD。对价格的影响也可能是戏剧性的。 Tom's Hardware预测QLC的问世可能会将512GB SSD降至100美元。

超越HDD和SSD

我们在2015年撰写了关于未来数据存储技术的文章，并继续努力推动数据存储的范围超越旋转盘片和微电路的可能性。

例如，哈佛大学的一个团队使用基因组编辑将视频编码成活细菌。在英格兰，南安普顿大学光电子研究中心（ORC）的科学家们通过飞秒激光写入开发了五维（5D）数字数据的记录和检索过程。由于采用石英石英玻璃激光纳米结构的“5D数据存储”，这些光盘可容纳360 TB的数据，理论上可稳定长达140亿年。 Space-X的Falcon Heavy最近将这项技术带入了太空。

无论是热量，微波，DNA，细菌，石英晶体还是全息术，很明显，正在探索多种途径来提高存储容量，速度和寿命。

 

SSD在数据中心中的优势

我们已经讨论过SSD的好处。特别适用于数据中心的SSD的优点是：

• 低功耗 - 当您运行大量驱动器时，功耗会增加。在任何可以节省电力的地方都是一种胜利。
• 速度 - 可以更快地访问数据，这对于缓存数据库和影响整体应用程序或系统性能的其他数据尤其有用。
• 振动不足 - 减少振动可提高可靠性，从而减少问题和维护。机架不需要容纳SSD的尺寸和结构刚性，它们需要容纳HDD。
• 低噪音 - 随着更多SSD的部署，数据中心将变得更加安静。
• 低热量产生 - 产生的热量越少，数据中心所需的冷却和功率就越少。
• 启动速度更快 - 存储机箱上线速度越快或者维护或问题后重启服务器就越好。
• 更大的面密度 - 数据中心将能够在更小的空间内存储更多数据，从而提高所有区域的效率（电源，冷却等）

顶级驱动器制造商表示，他们希望硬盘和固态硬盘在可预见的未来在家庭，商业和数据中心的所有领域共存，客户可以选择哪种技术和产品最适合他们的应用。

如何使用SSD

在几乎所有方面，SSD都优于HDD。那么，为什么我们不用SSD替换我们在数据中心中使用的100,000多个硬盘？

主要原因是成本。

我们希望能够为我们的Storage Pod提供SSD的性能和密度（请参阅我们的帖子Seagate推出60TB SSD - 下一个是3.6PB存储盒吗？），但SSD的成本/效益比尚未在我们的青睐。

我们的运营团队尽可能利用SSD的优势和优势，在主要数据存储以外的任何适当位置使用它们。它们在我们的缓存和恢复层中特别有用，我们在策略上使用它们来加速数据传输。 SSD还加快了对B2云存储元数据的访问速度。我们的运营团队正在考虑转向使用SSD来启动我们的存储盒，其中小型SSD的成本与硬盘驱动器相比具有竞争力，而且其他属性（小尺寸，低振动，速度，低功耗，可靠性）都是加号。

硬盘和固态硬盘的未来

IDC预测，创建的总数据将从2018年的大约33个zettabytes增长到2025年的大约160个zettabytes。（如果您想了解zettabyte的大小，请参阅什么是字节？）

 

据IDC称，目前超过90％的企业驱动器出货量都是硬盘驱动器。 到2025年，SSD将占驱动器出货量的近20％。 固态硬盘将获得份额，但创造的数据总量增长将导致硬盘和固态硬盘的大量销售。

 

随着HDD和SSD销量的增长，两种技术的容量也在增长。鉴于固态硬盘在许多应用中的优势，我们可能会看到固态硬盘替代硬盘驱动器，但容量最高。

很明显，HDD和SSD都有优点。如果您没有运行数据中心，并且家庭或企业计算机上没有超过一或两TB的数据存储，那么您的第一选择应该是SSD。它们在启动和数据传输期间提供了显着的性能改进，并且更小，更安静，更可靠。将HDD保存在系统中的辅助驱动器，NAS，RAID和本地备份设备中。

也许有一天，我们会回顾旋转盘片的日子，我们回顾立体声LP的同样的怀旧情绪，我们中的一些人将在我们的浮动反重力桌上作为对话片有一个硬盘镇纸。

直到SSD的性能，容量以及最终价格将最后一个硬盘驱逐出家庭和数据中心的那一天，我们可以期待生活在包含固态SSD和磁盘HDD的世界中，作为用户，我们将从两种技术中获益。

 

客户经常询问我们是否以及何时计划将云备份和数据存储迁移到SSD（固态硬盘）。 考虑到SSD相对于磁盘式驱动器（也称为HDD（硬盘驱动器））的许多优点，这并不是一个令人惊讶的问题。

我们的数据中心是HDD的大用户（目前拥有超过500 PB数据的100,000个硬盘）。 我们希望为云备份和云存储服务提供最佳性能，可靠性和经济性，因此我们不断评估用于运营和数据中心的驱动器。 虽然我们将SSD用于某些应用程序（我们将在下面介绍），但有理由认为在可预见的未来，HDD将继续成为我们和其他云提供商的首选驱动器。

HDDs vs SSDs

 

我写的笔记本电脑有一个512GB的SSD，这已成为高端笔记本电脑的常见功能。 SSD对于笔记本电脑的优势很容易理解：它们比HDD小，更快，更安静，使用寿命更长，功耗更低，并且不易受振动和磁场的影响。它们还具有更低的延迟和访问时间。

今天2.5“512GB SSD的典型在线价格是140到170美元。 3.5“512 GB硬盘的典型在线价格为44至65美元。这在价格上是一个非常显着的差异，但由于SSD有助于使笔记本电脑更轻，使其能够更好地抵抗日常使用中不可避免的冲击和颠簸，并增加了更快启动，更快从睡眠中醒来的好处，更低功耗，更快启动应用程序和处理大文件，在这种情况下SSD的额外成本是值得的。

其中一些SSD优势（主要是速度）也将适用于台式计算机，因此台式机越来越多地配备了SSD，特别是用于保存经常访问的操作系统，应用程序和数据。用SSD替换启动驱动器已经成为一种流行的升级选择，可以为计算机注入新的活力，特别是那些似乎需要永久启动或用于臭名昭着的缓慢加载应用程序（如Photoshop）的计算机。

数据中心是一个完全不同的鱼群。数据中心存储的主要问题是可靠性，存储密度和成本。虽然SSD在前两个领域表现强劲，但它是第三个尚未具备竞争力的领域。在Backblaze，我们采用更高密度的硬盘驱动器 - 我们目前在数据中心使用10TB和12TB驱动器（以及其他容量）。更高密度的驱动器可为每个Storage Pod和Vault提供更高的存储密度，并通过减少所需维护和降低总功耗来降低我们的间接成本。这些尺寸的可比较SSD每TB的成本约为1,000美元，远高于相应的HDD。简单地说，固态硬盘还没有在价格范围内使用它们所带来的好处，这就是我们期望在可预见的未来使用硬盘驱动器作为主要存储介质的原因。

什么是硬盘驱动器(HDD)？

自IBM于1956年推出硬盘驱动器以来，硬盘驱动器已经存在了60多年。第一个磁盘驱动器的大小与汽车相当，仅存储3.75兆字节，今天的成本为30万美元。

350磁盘存储系统是IBM 305 RAMAC（会计和控制随机访问方法）系统的主要组件，该系统于1956年9月推出。它由40个盘片和一个单臂上的双读/写头组成。 上下堆叠的磁盘盘片。

 

从那时起，硬盘驱动器的基本机制保持不变，尽管它经历了不断的改进。 HDD使用磁力将数据存储在旋转盘片上。 读/写头固定在一个臂上，该臂漂浮在旋转盘片上方读取和写入数据。 盘片旋转得越快，HDD就越快。 今天典型的笔记本电脑驱动器以5400 RPM（每分钟转数）或7200 RPM旋转，尽管一些基于服务器的盘片以更高的速度旋转。

 

驱动器内部的盘片涂有磁性敏感薄膜，磁性薄膜由微小的磁性颗粒组成。当磁写头在旋转盘正上方飞行时，记录数据;写入头快速翻转晶粒的一个磁性区域的磁化，使其磁极向上或向下指向，以二进制编码编码1或0。如果所有这些听起来像硬盘容易受到冲击和振动，那么你就是对的。它们也容易受到磁铁的攻击，如果你摆脱它，这是破坏硬盘上数据的一种方法。

HDD的主要优点是它可以廉价地存储大量数据。如今，一台和两台TB（1,024和2,048千兆字节）的硬盘驱动器对于笔记本电脑来说并不罕见，10TB和12TB硬盘现在可用于台式机和服务器。密度和旋转速度继续增长。但是，如果将在线销售的普通HDD与SSD的成本进行比较，SSD的成本大约是每千兆字节成本的3-5倍。因此，如果您想要便宜的存储空间和大量存储空间，使用标准硬盘驱动器肯定是更经济的方式。

HDD的最佳用途是什么？

• 需要高容量的磁盘阵列（NAS，RAID等）
• 低成本的桌面是优先​​考虑的
• 媒体存储（照片，视频，当前未处理的音频）
• 驱动器具有极高的读写次数

什么是SSD？

固态硬盘几乎与硬盘驱动器一样，第一个半导体存储设备与1978年推出的硬盘驱动器接口兼容，即StorageTek 4305。

 

StorageTek是一款针对IBM大型机兼容市场的SSD。 STC 4305的速度比IBM流行的2305硬盘系统快七倍（也是价格的一半左右）。它由一个装满电荷耦合器件的机柜组成，45MB容量的成本为400,000美元，吞吐速度高达1.5 MB /秒。

SSD基于一种称为NAND的非易失性存储器（以布尔运算符“NOT AND”命名，并且是两种主要类型的闪存之一）。闪存将数据存储在由浮栅晶体管组成的各个存储单元中。虽然它们是基于半导体的存储器，但是当它们没有通电时它们会保留信息 - 这一功能显然是与基于磁盘的数据存储竞争的必要条件。

与HDD相比，SSD具有更高的数据传输速率，更高的区域存储密度，更高的可靠性以及更低的延迟和访问时间。对于大多数用户来说，SSD的速度主要是吸引他们。在讨论驱动器的速度时，我们所指的是它们可以读取和写入数据的速度。

对于HDD，盘片旋转的速度强烈决定了读/写时间。当访问HDD上的数据时，读/写头必须物理地移动到盘上磁性部分上编码数据的位置。如果正在读取的文件按顺序写入磁盘，则会快速读取。但是，随着更多数据写入磁盘，文件可能会跨多个部分写入，从而导致数据碎片化。使用HDD读取碎片数据需要更长时间，因为读取头必须移动到盘片的不同区域以完全读取所请求的所有数据。

由于SSD没有移动部件，因此它们的运行速度远远高于典型HDD。碎片不是SSD的问题。文件可以在任何地方写入，对读/写时间影响很小，导致读取时间远远快于任何HDD，无论碎片如何。

但是，由于数据写入和读取到驱动器的方式，SSD单元可能会随着时间的推移而磨损。 SSD单元通过栅极推动电子以设置其状态。这个过程在单元上磨损，随着时间的推移会降低其性能，直到SSD磨损。此效果需要很长时间，并且SSD具有最小化此效果的机制，例如TRIM命令。无论块中的页面有多少更新，闪存都会写入整个存储块。这需要读取和缓存现有数据，擦除块并重写块。如果空块可用，则写操作要快得多。 TRIM命令必须在OS和SSD中都受支持，使操作系统能够通知驱动器不再需要哪些块。它允许驱动器提前擦除块，以使空块可用于后续写入。

 

在SSD上重复读取和擦除的影响是累积的，并且SSD可以减慢甚至随着年龄显示错误。但是，更有可能的是，在SSD开始显示读/写错误之前，使用SSD的系统将被废弃以进行淘汰。硬盘驱动器最终也会因持续使用而磨损，因为它们使用物理记录方法，因此大多数用户不会根据预期的寿命来选择HDD或SSD驱动器。

总体而言，由于缺少机械部件，SSD被认为比HDD更耐用。 HDD内的移动机构不仅容易随着时间的推移而磨损，而且容易因移动或强力接触而损坏。如果要丢弃带有硬盘的笔记本电脑，那么所有这些移动部件很可能会发生碰撞，从而导致潜在的数据丢失甚至破坏性的物理损坏，可能直接杀死硬盘。固态硬盘没有可移动部件，但由于使用率高，它们可能会缩短使用寿命，因此它们可以承受我们对便携式设备和笔记本电脑的严格限制。

SSD的最佳用途是什么？

• 笔记本电脑，笔记本电脑，性能，重量轻，面积存储密度，抗冲击性和一般坚固性是理想的
• 引导驱动器保存操作系统和应用程序，这将加速启动和应用程序启动
• 工作文件（正在编辑的媒体：照片，视频，音频等）
• 交换驱动器，SSD将加速磁盘分页
• 缓存驱动器
• 数据库服务器

振兴旧电脑。如果您的计算机启动速度慢，加载应用程序和文件的速度很慢，那么使用SSD更新启动驱动器可能会让它看起来（如果不是新的话），至少就好像它刚刚花了一些时间才重新刷新在沙滩上。

请继续关注HDD与SSD的第2部分

这是第1部分。在我们的第二部分中，我们将深入研究HDD和SSD之间的差异，HDD和SSD技术如何发展.

事情可以而且确实会出错。这是生活中的事实，企业花费时间和金钱为意外打嗝做准备。数据存储行业花费了数十年的时间，通过假设其组件在某些时候出现故障来提高存储架构的可靠性。链式电缆，电源，冷却，驱动器，软件（甚至系统管理员）中的所有元件可能都会失败，无需预先警告，并且会中断对用户数据的访问。

可靠性通常等同于数据可访问性，即确保在给定SLA下的数据访问。更现代的视角以不同的方式看待这两种关键的独立测量：可用性和耐用性。

让我们探讨一些差异以及它们对您的业务的重要性。

数据可用性与耐用性 - 它们不是同一件事

可用性和持久性是数据可访问性的两个非常不同的方面。可用性是指系统正常运行时间，即存储系统可操作并且可以根据请求提供数据。从历史上看，这是通过硬件冗余实现的，因此如果任何组件发生故障，将以数据访问为主。另一方面，耐久性是指长期数据保护，即存储的数据不会遭受比特腐烂，退化或其他损坏。它不关注硬件冗余，而是关注数据冗余，以便数据永不丢失或受损。

可用性和耐用性有不同的目标。对于数据中心，可用性/正常运行时间是操作的关键指标，因为任何一分钟的停机都是昂贵的。测量侧重于存储系统可用性。但是当组件，系统甚至数据中心发生故障时会发生什么？当故障得到纠正时，您的数据是否完好无损？

这说明了数据持久性的同等重要性。更正可用性故障时，必须恢复对未损坏数据的访问。随着数据的爆炸式增长，挖掘的潜力以及对更长保留率（对所有事物）的需求不断增长，您可以想象这对于商业成功至关重要。

考虑无法检索存档的主数据/参考数据副本的潜在竞争，财务或法律影响。因此，数据可用性和数据持久性对于短期和长期业务成功至关重要。

确保数据可用性 - RAID或无速率擦除编码？

确保数据可用性的常用方法是通过基于RAID的架构。跨多个驱动器划分数据可以防止一个或两个驱动器发生故障，但在重建操作期间性能会急剧下降，这可能会对业务运营产生负面影响。多年的数据中心经验表明，驱动器故障通常不是孤立事件：当RAID组中的一个驱动器发生故障时，其他组成员失败的可能性会增加。重建操作期间出现不可恢复的读取错误意味着数据现在永久丢失，从而使您的企业面临风险。

随着驱动器容量的大幅增加，重建时间也在增加。以前花费几分钟的时间现在可能需要数小时甚至数天。此外，这需要尽快更换故障驱动器，无论是周末，节假日还是半夜。

对象存储通过高级擦除编码实现数据可用性，从而将数据与奇偶校验信息组合，然后在存储池中进行分片和分布。由于只需要一部分分片来重新水化数据，因此没有重建时间或性能下降，并且在方便时可以替换故障存储组件。

数据持久性 - 单独RAID无法提供

您可能已经猜测，实现数据可用性与访问最初存储的数据并不完全相同。诸如钻头腐烂之类的介质故障，其中驱动表面的一部分或其他介质变得不可读，破坏数据，从而使得不可能以其原始未改变的形式检索数据。简单地防止诸如RAID之类的完整硬盘驱动器故障，不能防止存储在磁介质上的位逐渐失效。

广泛分布的擦除编码数据（例如18/8编码策略）和数据清理技术的组合可以持续验证写在介质上的数据，使您可以实现15个九的数据持久性。简单来说：对于每1000兆对象，只有一个对象不可读。数据持久性如何？超大规模数据中心和云服务提供商使用基于对象的存储来满足最高数据可用性和数据持久性的需求并不奇怪。

数据可用性与耐用性 - 一个错误的选择

每个组织都需要在需要时访问其数据，并且不会出现损坏或其他损失。它不是高可用性和高耐用性之间的选择;两者都很重要。

请记住，这是您的数据需要保护，而不是您的磁盘驱动器。

为什么选择Apache Ozone？

为了解决首选网络PFN中不断增长的数据需求和新的使用案例，我们一直在寻找一种可以伪无限扩展的新存储系统。由于对模拟和人工智能的战略关注[1]，数据使用量的增长远远超过预期，这使得存储系统比以往任何时候都更加重要。

尽管我们的文章（ja） Hadoop in Preferred Networks Hadoop – Preferred Networks Research 中描述的基本要求没有太大变化，而且自那时以来仍然对我们至关重要[2]，但我们目前运行的Hadoop（HDFS）集群存在几个操作问题。例如，我们最大的Hadoop集群，其容量约为10PB，仍在Ubuntu 16.04上运行。由于我们对大型集群的就地升级（包括操作系统的升级）没有任何知识或经验，并且Ubuntu 16.04的生命周期已经延长[3]，我们已经放弃了系统升级，并一直在寻找新的软件来取代HDFS。我们制定了选择替代存储软件、建立新集群以及逐步迁移数据的计划。

升级底层操作系统只是我们面临的问题之一。我们的用例中还有其他几个不适合典型的HDFS用法。然而，由于其稳定性和操作方便性，我们妥协并绕过了它们。以下是列表：

• 小文件问题[4]：文件数量的增加会导致元数据的增加。NameNode的负载取决于元数据、一组文件和文件的块位置列表。如果平均文件大小小于标准块大小，则文件数量增加得更快。特别是，在NameNode重新启动后从磁盘加载元数据需要花费大量时间。

为了解决这个问题，我们将一组小文件存储到HDFS上的一个大型ZIP档案中，并使用PFIO等库直接从ZIP读取文件（而不压缩档案）。

• 高密度磁盘服务器（HDD）：当单个节点中包含更多硬盘驱动器时，每个磁盘容量的性价比会变得更好。另一方面，数据节点中完整块报告（FBR）的时间较长会影响数据的持久性和可用性。例如，最受欢迎的Hadoop分发提供商之一Cloudera不支持容量超过100TB的DataNodes和容量超过8TB的硬盘驱动器。相比之下，我们在PFN的一些数据节点配备了36个硬盘，容量为14TB。
• 与Python运行时更好的亲和力：从Python访问HDFS的标准方法是使用libhdfs2通过JNI中的Java Hadoop客户端读取和写入数据。复杂的软件堆栈施加了各种限制，使HDFS难以使用。最难的例子是PyTorch DataLoader，它并行分叉许多进程以更快地加载数据。为了在不使用JVM的情况下正确运行DataLoader，代码中需要非常小心，通过仅在分叉之后启动JVM来防止分叉已启动的JVM。
• 经典身份验证：尽管基于Kerberos的身份验证系统可靠且成熟，但其通过kinit（1）获取令牌的身份验证方法并不适合在Kubernetes Pods中执行，因为它需要额外的身份验证工具。在PFN中，我们通常在运行主容器之前在initContainer中运行kinit，使用存储为Kubernetes机密的keytab文件。更简单的身份验证方法，例如仅在初步环境变量中要求机密，会使我们的清单更加简单。
• NameNode可扩展性：为了扩展HDFS中的元数据管理，已经发布了许多系统，如HDFS Federation。它们主要涉及名称节点数量的增加，例如系统中更多的移动部件，这增加了整个系统管理的复杂性。

虽然这些问题一直让管理员感到非常疲惫，但它们也是系统用户抱怨的根源。Hadoop开发人员肯定已经意识到了这一点，因此Apache Ozone是从Hadoop中派生出来的，以解决这些问题。Apache Ozone如何解决这些问题如下：

• 小文件问题：在Ozone中，管理过去属于NameNode的元数据和块位置的职责分别分配给Ozone Manager（OM）和Storage Container Manager（SCM）。定义了一个称为“容器”的新块单元集，SCM只管理容器及其复制和位置。这种拆分还使得元数据的增加仅与文件数量成比例，并且仅影响OM中文件表的内存大小。目录树访问变得更快，因为文件表存储在更高效的数据库RocksDB中。
• 高密度磁盘服务器：由于设计的改变，FBR变得更快。DataNodes只需要向SCM报告容器。一个容器最多可以存储2^64个块——通过控制容器中块的平均数量，我们可以控制SCM的总体负载。
• 与Python运行时更好的相关性：添加了新的API端点。它与AWS S3兼容。它的生态系统如此庞大，以至于不仅它的SDK以各种语言提供，而且许多软件都有一个AWS S3（以及兼容的对象存储系统）的抽象来读取
• NameNode可扩展性：由于NameNode的职责被划分并转移到OM和SCM，底层数据存储被迁移到RocksDB，元数据扫描和更新的性能得到了很大的提高。我们不能说我们不再需要像HDFS联邦这样的扩展噱头，但一个相当大的集群可以通过当前的设计进行管理。Cloudera测试了插入100亿个物体的Ozone [5]。

就在我去年发表了这篇博客文章[2]之后，我们开始测试Apache Ozone作为下一代对象存储系统，并且已经运行了几个月。

虽然在测试过程中，我发现并报告了CVE-2020-17517[6]，但没有任何严重或关键的问题值得使用阻断剂。我们将该服务作为阿尔法服务向内部用户开放，并继续不断添加知识。API的覆盖范围远不是AWS S3的全部功能，但我们认为我们可以为社区贡献重要的功能和修复，因为社区一直非常活跃。

群集配置和设置

我们在MN-2中的一台管理服务器上安装了OM和SCM，在4台存储服务器上安装DataNode[7]。它们的物理规格如表1和表2所示。表1适用于DataNode；36个硬盘驱动器都被格式化为ext4分区（每1个驱动器1个分区），并被Ozone用作JBOD。

表1:DataNode的服务器规范

Type	Amount
CPU	Intel(R) Xeon(R) Silver 4114	1
Memory	32GB DDR4	12 ※1
HDD	14TB SATA 6GB/s 7200rpm	36
Network	Mellanox ConnectX-6 (100GbE)	2

表2是运行OM和SCM的管理服务器的规范。为了持久保存元数据，它配备了四个15TB NVMe SSD，这些SSD捆绑为raidz分区。我们选择ZFS是因为我们在OpenZFS方面有一些经验，而且它有一组简单一致的CLI，很容易理解。在该分区中，OM和SCM存储它们的元数据。这种配置在SSD出现单次故障时仍然有效。

表2：Ozone 管理器和存储容器管理器的服务器规格

Type	Amount
CPU	Intel(R) Xeon(R) Silver 4114	1
Memory	32GB DDR4	12 ※1
NVMe	15TB PCIe Gen3	4
Network	Mellanox ConnectX-6 (100GbE)	2

※1稍后，通过添加四个32GB棒，每个节点的内存将扩展到512GB。

操作系统是Ubuntu 18.04，它是我们在MN-2集群中设置物理服务器时安装的。由于之前在另一台服务器中有NVMe SSD管理的经验，我们在元数据服务器上安装了Linux 5.4.0 HWE内核。我们重新使用了构建MN-2集群时安装的Oracle JDK 8u162。

我们使用Apache Ozone 1.0.0从这些服务器构建了一个安全的集群。

图1描述了Ozone 集群的简单配置。在存储服务器中，DataNode和S3Gateway正在运行。在元数据服务器中，OM和SCM正在运行。S3Gateway是一个网关过程，它将S3 API访问转换为Ozone 原生API。S3Gateway进程公开为HTTP API服务器。来自客户端的访问通过DNS循环分布在网关进程中。我们没有使用HAProxy之类的反向代理进程来消除HDD到客户端进程内存空间的任何潜在瓶颈。在Ozone 1.0.0中，OM已经具有通常可用的高可用性（HA）功能，但它会引入一些操作复杂性，并且由于SCM没有HA，无法删除SPoF（单点故障）。因此，我们没有使用OM的HA功能。

Figure 1: simplified picture of processes

我们运行了一个访问大小约为200GB的文件的简单基准测试。我们构建了一个并行读取的基准脚本，将其部署为Kubernetes集群中的几个客户端Pod，并在更改并发量的同时测量其性能。图2显示了所有客户端的总吞吐量。当并发量为128时，最大吞吐量略低于4GB/s。潜在的最大吞吐量将通过64和256之间的客户端中的某个并行点来获得。目标数据的大小小于磁盘缓存总容量的大小，我们有4个节点有20个核心CPU（总共80个核心处理来自所有客户端的请求），以及DataNodes的总CPU使用率饱和在100%左右，这表明瓶颈在服务器端。

Figure 2: performance of parallel download of a blob file

在这个基准测试之后，我们开放了该服务供内部使用。几个月后，我们现在有几个内部用例，例如机器学习和备份。起初，我想我可以在这里详细分享其中的一些，但事实证明，它们中的大多数与深度学习中的标准工作负载没有太大区别。

历史和当前状态

在我们于2021年初建立集群后，Ozone 1.1.0于4月发布。我们在发布后立即升级了集群。

不是因为新版本，而是集群的管道（多Raft实例的单元）分布不平衡。我们期望4个节点和36个硬盘驱动器——期望SCM创建36*4/3=48个管道。但它没有起作用；SCM只创建了36个管道，我们没有充分利用144个HDD，只有108个存储了数据。后来，我们添加了另外两个存储服务器作为DataNodes，总共在6个DataNodes中创建了72个管道，最后我们充分利用了所有的HDD。如果你想了解更多关于管道的信息，请参阅Cloudera的博客文章[8]。

我们已经运行Apache Ozone好几个月了。它拥有所有具有HTTPS侦听/prom端点的组件，并以Prometheus Exposition格式公开了各种度量。我们使用普罗米修斯收集这些指标，并使用格拉法纳进行可视化。此外，我们还设置了Alertmanager，以便在出现某些异常情况时获得通知。截至今天，它拥有3000多万件物品和400多个水桶。图3描述了最近数据量的增加。

Figure 3: Historical and total disk usage and capacity of our Ozone cluster (physical)

设置后，我们做了一些上游贡献，以解决操作过程中发现的问题。我们已经报告了1.1的CVE-2020-17517。1.2的主要贡献如下：

• HDDS-5197（修补程序）
• HDDS-5620（修补程序）
• HDDS-5893（修补程序）
• HDDS-4856（报告）
• HDDS-5005（报告）
• HDDS-5393（报告）

还有几个其他贡献合并到1.3.0或仍在进行中。对这些问题的描述将很长，并将在单独的博客文章中介绍。除了上游贡献外，我们精心挑选了HDDS-5472，并于9月将其应用于集群。这个补丁极大地提高了OM的性能，集群变得非常稳定。10月，我们切换到了OpenJDK 1.8.0。Ubuntu 18.04提供了补丁级别1.8.0-292，其中包括服务器端的TLS处理性能。

11月，1.2.0发布，并针对过去版本中的漏洞进行了多次修复。我们在发布后立即进行了升级，进展非常顺利，没有出现任何重大问题。毫无疑问，我们未来还有很多工作要做，分为三大类。。

OM和SCM中的高可用性

在当前设置中，OM和SCM中的元数据使用ZFS在多个磁盘上复制。但我们在服务本身仍有几个单点故障。例如，如果运行OM和SCM的机器出现故障，这些进程肯定会停止，因此服务将全部停止。Ozone 1.2.0具有通过Raft复制这些服务的HA功能，Raft运行三个复制的进程，并允许在单节点故障的情况下进行服务故障切换。该服务的可用性将大大提高，并降低在PFN中更广泛的实际工作负载用例中采用Apache Ozone的门槛。

Ozone 的集群扩展与HDFS的迁移

截至目前，HDFS集群总共存储约9PB的数据，而Ozone 中的数据量仍在200TB左右。基本上，我们希望HDFS中的所有数据都迁移到Ozone 层。此外，我们的业务工作量产生的新数据将新存储在Ozone 中。绝对需要更多的容量——随着数据迁移的进展，我们确实计划逐步将HDFS数据节点转移到Ozone，但在全面迁移真正开始之前，我们对可以从HDFS移动多少节点的前景很渺茫。我确实记得，过去一些存储系统中的数据量甚至在其使用寿命结束之前都没有减少，我们只能无奈地手动清理这些数据。

有几种方法和路径可以迁移数据。在具有相同KDC（Kerberos的密钥分发中心，我们有多个）的集群之间，我们将能够在它们之间运行distcp。在使用不同KDC的情况下，distcp可以使用s3a协议，并且似乎是可行的。但有一个问题是HDFS对文件大小没有限制，S3 API的最大文件大小为5TB。我们在HDFS中确实有几个超过5TB的文件。

新特点与上游贡献

没有一个软件是完美的，因此，当我们继续使用它时，我们可能会发现一些缺点。我们不仅会等待社区改进或解决这些缺点，还会尝试自己去做。我们将继续努力发送补丁。我们已经有了其中的一些；一些重要补丁和建议如下：

• HDDS-5656–多部分上传优化
• HDDS-5905–潜在的数据丢失
• HDDS-5975–ListObjects错误修复

结论

在PFN中，从Apache Hadoop到Apache Ozone的迁移一直在进行中。我们介绍了它的背景、实际设置和基准。我们预计数据将持续增加，我们将扩大我们的集群。我们还努力在行动期间不断向社区发送我们的反馈和贡献。

参考

• [1] 《日経Robotics》AIによるシミュレーションの進化 ：PFN岡野原氏連載 第56回
• [2] Preferred Networks におけるHadoop – Preferred Networks Research
• [3] Ubuntu 14.04 and 16.04 lifecycle extended to ten years
• [4] The Small Files Problem
• [5] Future of Data Meetup: Apache Ozone – Breaking the 10 billion object barrier
• [6] NVD – CVE-2020-17517
• [7] PFN’s Supercomputers – Preferred Networks
• [8] Multi-Raft – Boost up write performance for Apache Hadoop-Ozone
• [9] HDFS | CDP Private Cloud

自2021年初以来，我们优选网络（PFN）正处于从HDFS转向Ozone的过程中。我们的Ozone集群已经被我们的ML/DL项目所采用，集群的使用量正在迅速增长，在过去两年中，我们已经多次扩大了集群。然而，随着集群的逐渐扩展，磁盘使用不平衡成为了一个问题。例如，将完全空的数据节点添加到所有现有磁盘已满80%的Ozone集群中，将导致集群使用率严重失衡。将数据移动到新添加的空服务器称为再平衡，但它的具体工作方式并不明显。在HDFS中，有平衡器，它在每个节点的指定阈值内均匀地移动块，还有磁盘平衡器，它将块在单个数据节点内的磁盘之间对齐。另一方面，Ozone有一个容器平衡器，起初再平衡在Ozone.2.0中似乎不起作用，因为它仍然是一个年轻的功能。因此，当我们最近添加新的数据节点时，我们决定执行手动再平衡作为紧急维护。在这篇文章中，我们从背景开始展示我们的全部故事。

（有关建立Ozone集群的更多信息，请阅读2021年的博客文章“与Apache Ozone共度一年”。）

存储系统在PFN的计算基础设施中的作用是提供一个地方来保存我们的ML/DL研究活动所需的数据，并在需要时高速读取数据。“所需数据”包括各种内容，如数据集、程序执行结果和作业检查点文件。最近，公司中通过使用CG和模拟进行计算来生成数据的用例[1][2][3][4]的数量有所增加，而且数据不断从无到有。我们一直在通过根据磁盘使用统计数据预测需求来购买和构建服务器，但最近很难估计，而且磁盘的填充速度比预期的要快。

通过购买服务器和磁盘设备来扩展集群实际上需要花费大量时间。如果我们在可用空间较低的阶段购买服务器，我们将无法跟上数据增长的步伐。我们购买并添加了新的服务器，同时收缩了HDFS集群，并多次将退役的HDFS数据节点重新部署为新的Ozone数据节点。值得庆幸的是，HDFS和Ozone都支持扩展和删除数据节点。然而，如上所述，由于采购条件和使用预测的困难，我们的集群扩展进展很小。图1显示了过去一年中我们集群的系统容量（橙色）和实际使用量（蓝色）的发展情况，这表明使用量的增长速度快于容量，而我们一直在重复添加服务器。我们计划进行系统扩展，以将数据使用率保持在80%以下，但最近几个月，使用率已达到这一极限。

Fig. 1: Physical system capacity and actual usage of the Ozone cluster (Unit: TB)

增量群集扩展导致磁盘失衡

虽然整个集群的可用空间即将耗尽，但数据节点之间的磁盘使用不平衡也是一个问题。图2显示了每个数据节点的物理磁盘使用情况。在该图中，磁盘使用率高的数据节点是旧节点，而新添加的节点可以观察到磁盘使用率低。这种分布是不可取的，因为为了实现I/O负载平衡，磁盘使用应该尽可能均匀。此外，磁盘使用率高的节点会引起对磁盘已满的担忧。

数据节点配置如表1所示，图2中各服务器的数据节点配置如下：

Table 1: Ozone Datanode configuration

Software	Apache Ozone 1.2.0 based custom version
CPU	Intel(R) Xeon(R) Silver 4114 x1 20c
RAM	32GB DDR4 x16
HDD	14TB SATA 6GB/s 7200rpm x36
Network	Mellanox ConnectX-6 (100GbE) x2

在Apache Ozone和Hadoop中，没有自动磁盘使用平衡的功能。对于HDFS，有一个Node Reblancer，它在启动时在数据节点之间移动数据，以实现磁盘使用均衡。Ozone有一个名为Container Balancer的组件，它可以在数据节点之间重新平衡数据，类似于HDFS，但不幸的是，Ozone 1.2中不支持它，因此我们还无法使用它。

在此期间，数据节点保持不平衡状态，并以相同的速度在所有节点上填充，无论是高使用率还是低使用率。一些数据节点的磁盘利用率超过90%，接近100%。当时，我们对Datanodes的磁盘将满时的行为一无所知。为了避免出现不可预测的状态，我们决定尝试停用接近磁盘满状态的Datanode。停用是一种从集群中安全删除数据节点、将数据节点上的所有数据复制到其他数据节点并将其从集群中删除的操作。如果我们有额外的空间，停用高利用率的数据节点不仅会防止磁盘满，而且我们可以期望数据统一写入其他数据节点。

由于每个数据节点的磁盘容量为每个硬盘14TB，并且线速足够快，因此我们开始停用时假设拷贝可以在几天内完成，即使考虑到它是一个硬盘。然而，它并没有像最初预期的那样在期限内结束，两个月过去了，节点状态仍处于“断开”状态。由于用于检查停用进度的CLI尚未实现，我们不得不直接在SCM中读取Replication Manager日志，我们发现停用在某个时候被卡住了。就在那时，我们放弃了通过删除节点重新定位和重新平衡数据的想法。

出现满磁盘节点

虽然我们尝试了容器平衡器和停用，但不幸的是，它对我们不起作用，时间一天天过去了，集群中的一些节点最终变成了磁盘满状态。在达到100%使用率的磁盘上，容器无法打开，如图3所示。容器[5]是Ozone的一个管理单元，它将最多5 GB的区块分组[6]。Ozone不像HDFS那样直接管理块，但它决定了容器单元中的数据放置和复制计数。

Ozone在打开容器时总是以写入模式打开RocksDB以读取元数据，并且似乎未能写入打开RocksDB.所需的日志[7]。对于这些情况，磁盘已满的节点上的容器将无法读取。

2022-09-07 15:36:24,555 [grpc-default-executor-8298] ERROR org.apache.hadoop.ozone.container.common.utils.ContainerCache: Error opening DB. Container:150916 ContainerPath:/data/21/ozone/hdds/CID-xxx/current/containerDir38/150916/metadata/150916-dn-container.db
java.io.IOException: Failed init RocksDB, db path : /data/21/ozone/hdds/CID-xxx/current/containerDir38/150916/metadata/150916-dn-container.db, exception :org.rocksdb.RocksDBException While appending to file: /data/21/ozone/hdds/CID-xxx/current/containerDir38/150916/metadata/150916-dn-container.db/MANIFEST-001861: No space left on device; status : IOError(NoSpace); message : While appending to file: /data/21/ozone/hdds/CID-xxx/current/containerDir38/150916/metadata/150916-dn-container.db/MANIFEST-001861: No space left on device

Fig. 3: Failure when opening RocksDB

即使某些数据节点的磁盘已满，唯一的影响是这些节点上的副本变得不可读，因此读取其他副本和写入不会受到影响。在PFN，尽管一些数据节点的磁盘已经满了，但每天都会生成大量数据并写入Ozone集群。几天后，更多的数据节点变为磁盘已满状态。如果复制集的副本计数不满足所需的复制因子，则无法读取此集中的数据。发生这种情况时，集群用户报告集群中的某些数据不可读。9月12日，集群中12个数据节点中有5个数据节点的磁盘已满。这意味着集群中超过一半的数据节点的磁盘已满。如果我们能够等待Ozone1.3.0的发布，容器平衡器可能会帮助我们，但我们需要尽快修复磁盘已满的数据节点，以最大限度地减少对我们研究活动的负面影响。

“手动”重新平衡的一种选择

通常，对于有状态的应用程序（如文件系统和数据库系统），应避免手动操作。这是因为系统应该保持一致性，而手动干预很容易由于简单的人为错误而破坏系统保证的完整性。基本上，管理所需的所有功能都应该以管理工具的形式提供。这是一个确保统一维护质量并提前避免一些意外操作错误的框架。

然而，由于Ozone目前的标准功能无法解决磁盘满的问题，而且预计手动再平衡将解决这个问题，而不是寻求现有功能的解决方案，因此我们决定尝试使用手动再平衡来恢复集群。

我们熟悉Ozone的内部数据结构，并有可能手动操作它。曾经有一段时间，我们定期聚集在一起阅读Ozone的源代码，如果有任何可疑或不清楚的地方，我们会检查当前工作版本的源代码。这一次对我们有所帮助。在接下来的部分中，我们将简要解释如何通过手动重新平衡来实际传输数据。

Ozone1.2.0的内部数据结构遵循容器布局V2，如图4所示。容器布局V2是一种格式，每个容器包含一个目录，称为容器目录。容器目录由元数据（RocksDB和YAML）和块（Blob）组成。

Ozone数据节点具有hddsVolumes，每个卷都将容器（由Ozone SCM管理）存储为由容器id标识的容器目录。容器id由SCM按顺序编号。

在PFN中，Ozone数据节点是以JBOD方式设置的，每个HDD对应一个hddsVolume。从理论上讲，容器只是文件系统中的一个目录，我们认为，如果我们能够在保持目录结构的同时将它们移动到其他数据节点，那么我们可能可以做与复制或容器再平衡相同的事情。

Fig. 4: HddsVolume structure in Container Layout V2

人工再平衡还有一个问题。如果我们可以手动移动容器位置，那么容器位置元数据的一致性是否存在问题？当数据节点启动时，它会扫描本地磁盘中的所有数据，然后将收集到的有关现有和可读容器的信息作为ContainerReport发送给SCM。这相当于HDFS中的BlockReport。如果我们完全停止Ozone，我们认为在数据节点之间移动容器是安全的，我们实际上通过一个小的测试案例证实了在停止一些数据节点的同时移动容器是成功的。

由于我们用小型测试用例确认了计划的操作，我们决定使用上述内部数据结构手动重新平衡磁盘使用情况。同时，由于我们可以通过缩小HDFS集群来添加七个新的数据节点，我们还决定通过添加数据节点来扩展Ozone集群。我们的手动再平衡政策是：

• 准备具有相同配置（相同数量的磁盘、相同容量）的数据节点
• 选择磁盘使用率高的（旧的）数据节点，并将一半的容器复制到新的数据节点
  • 我们将数据节点（旧的）和数据节点（新的）配对，并且这些对是独占的和唯一标识的（为了简化和避免容器副本之间的冲突）
  • 维护目录结构，使其在新旧之间遵循Container Layout V2，包括SCM ID和Container ID迁移
  • 复制完成后从旧数据节点中删除容器
• 完全停止Ozone集群只是为了维护
  • 停止服务是一个合理的选择，因为群集中超过一半的数据节点由于磁盘已满而无法为文件提供服务
  • 向用户清楚地解释，在维护期间，存储服务将完全不可用，这是一项非常重要的维护

由于此次维护需要停止服务，我们决定制定更具体的时间表和详细的任务清单。

离线维护：计划和行动

进度计划

离线维护的注意事项包括：

• 确保有足够的操作时间
  • 最小化维护周期，因为离线维护将暂停我们的研究活动
• 提供足够长的准备期
  • 更长的时间允许用户为数据迁移做准备，并允许管理员验证维护说明
  • 这是一种权衡，因为较短的周期可能会避免即将出现的其他与磁盘相关的意外问题
  • 由于9月中旬有连续假期，增加了更多的宽限期（日本“白银周”）
• 在我们的工作时间内进行维护，为用户和管理员留出空间，以便快速处理一些意外问题
• 确保缓冲日

至于操作所需的时间，假设复制过程具有足够的并行性，我们可以估计维护时间相当于在每个数据节点中复制一半物理HDD卷大小的时间（14 TB/2=7 TB）。每个数据节点都通过100GbE网络相互连接，因此我们最初估计复制将在一天内完成。此外，我们还分配了一天作为缓冲区，并最终决定停止集群最多两天。为了确保有足够的准备时间，我们决定从维护公告到复制操作之间至少需要两周的宽限期。

抢救重要数据

由于我们将两周设置为修复该问题的准备时间，因此我们需要为那些希望立即使用由于磁盘满问题而当前不可用的文件的群集用户提供另一个选项。我们从集群中抢救了一些文件，直到维护完成，方法是从OM中获取元数据，从SCM中获取块的位置以识别数据节点，然后从数据节点上的容器中收集块以恢复原始文件。对于数据抢救，我们准备了读取Ozone元数据、下载块和重建块等操作，并使这些功能在集群之外普遍可用。实际上，手动执行这些操作很复杂，所以我们将它们作为自动化脚本来实现。

手动重新平衡的准备

手动再平衡说明的初步示意图为：

1. 停止所有与Ozone有关的过程
2. 准备新的数据节点并将其添加到集群中
3. 将数据节点（旧）的一半数据复制到数据节点（新）
4. 从数据节点删除完全传输的数据（旧）
5. 启动Ozone

对于复制容器，因为实际上这些副本只是服务器之间的简单目录传输，所以我们决定使用rsync。这一次，由于我们只希望Datanode中有一半的容器，所以我们使用偶数容器ID传输容器。接受列表格式的传输目标作为其参数也是我们使用rsync的原因之一。图5显示了使用rsync传输容器的示例。在实践中，我们在一个Datanode中有36个HDD，因此我们对磁盘和服务器的数量重复此命令，但由于它可以充分并行化，因此传输时间相当于一个磁盘。

Fig. 5: An example of filtering target containers and transferring them with rsync

由于这种维护需要停止Ozone集群，我们希望提前确保数据传输时间在维护窗口内合理。因此，我们发现，单个数据节点的完整拷贝仅拷贝7 TB就需要长达五天的时间。数据节点包含许多目录和条目，这会导致低吞吐量。为了最大限度地减少停机时间，我们使用了差异副本作为维护的前期工作。最后，维修说明如下：

1. 预备：列出要复制的目标容器
2. 预备：将目标数据的完整副本从数据节点（旧）复制到数据节点（新）
3. 在窗口中：停止所有与Ozone有关的过程
4. 在窗口中：在数据节点之间获取目标数据的差异副本
5. 在窗口中：从Datanode（旧）中删除已完成的容器
6. 在窗口中：从Datanode中删除步骤2中完整复制后删除的容器（新）
7. 在窗口中：启动Ozone

当我们等待两周的平稳期时，又出现了两个磁盘已满的节点，现在有八个节点处于这种状态。图6显示了当时Datanode的磁盘使用情况。由于我们要添加七个节点，因此在实践中需要将维护过程更改为将两个数据节点中的容器合并为一个。

Fig. 6: Disk usage of Datanodes at the before the maintenance day

维护日

尽管我们不得不处理一些比预期更多的新的满磁盘节点，但由于作为前期工作执行的完整拷贝已经成功完成，直到维护日，我们停止了集群，并按计划执行了差异拷贝。对于差异复制，rsync有两种模式：比较时间戳和在文件之间进行校验和。我们没有使用校验和模式来加快速度。使用校验和模式需要计算所有目标文件的校验和，在这种情况下吞吐量很低。

最终，我们按时完成了维修工作。在这个维护日，我们通过手动重新平衡，从8个磁盘已满的数据节点减少到零，通过添加新的数据节点，整个集群的磁盘使用率也从85%减少到69%。图7显示了维护后集群的磁盘使用情况报告。与Ozone相关的磁盘使用率指示绿色条，这些条在集群之间几乎重新平衡，最终没有磁盘满的数据节点。

Fig. 7: The disk usage report after the maintenance

手动重新平衡，一个月后

9月22日进行了手动再平衡。截至目前，我们还没有因手动再平衡工作而引起的任何问题。此外，我们还修复了集群的其他一些配置问题。

已修复：某些复制已停止

我们注意到Datanodes在维护后使用的证书已过期。这些证书由数据节点之间的特定复制过程使用，并在第一次启动数据节点时自动初始化。Ozone RPC使用Kerberos进行身份验证，但一些复制操作依赖于SCM使用自签名CA颁发的此证书。实际上，有效期为一年，但Ozone 1.2.0中没有实现续订证书的功能。由于我们的集群具有长时间运行的Datanodes，因此节点中的一些证书已经过期。

这次我们手动续订了证书，这使复制工作正常。虽然更新后退役仍在进行中，但我们最初遇到的退役停滞的原因可能是证书过期。

已修复：修改的ContainerPlacementPolicy

我们仍然看到数据增长的不平衡。我们将尝试更改ContainerPlacementPolicy、PipelineChoosingPolicy和LeaderChoosePolicy等政策来改善这种情况。特别是，我们将用于选择数据节点作为容器放置的ContainerPlacementPolicy更改为用于选择最空闲数据节点的容量感知策略。由于该政策在Ozone 1.2.0中确实存在问题（由HDDS-5804修复），我们为内部分发备份了一个补丁。

未来的工作

Ozone仍然是一个年轻的软件，但社区非常活跃。虽然我们这次面临的问题包含在1.2.0版本中，但这些问题中的大多数都是为即将发布或未来的版本修复的，因此我们介绍以下内容。在PFN中，我们正在运行Ozone 1.2.x集群和主HEAD集群，以预测即将发布的1.3.0版本。从现在起，如果有必要，我们将在后台移植最新补丁的同时操作集群。

自动证书续订（HDDS-7453）

社区建议自动续订证书。这使我们能够通过手动更新来节省劳动。

退役可观测性改进（HDDS-2642）

退役进度现在作为指标导出。目前，我们需要读取SCM日志和Datanode状态，这是检查退役进度的唯一方法。这一建议使我们能够提高退役的可观察性。

保留卷空间（HDDS-6577和HDDS-6901）

HddsVolume现在可以在数据节点中声明一些保留空间。通过此更改，可以将磁盘空间限制为磁盘的某些边距，并防止磁盘已满，从而减少元数据故障。

容器平衡器（HDDS-4656）

现在我们有了Ozone容器平衡器。这就消除了像我们所做的那样手动重新平衡工作的必要性。这是我们运营集群的一个重要特征，我们将仔细评估我们的集群。

结论

由于集群的增量扩展，我们遇到了磁盘使用不平衡的情况，而且一些数据节点达到了磁盘已满的状态。这种情况使我们无法从这些节点读取数据。在这篇文章中，我们分享了我们的背景以及为什么我们做出手动再平衡的决定，并通过介绍Ozone数据节点的内部数据结构来分享我们的维护操作。我们决定通过停止集群来进行离线维护，因为超过一半的数据节点处于降级状态，并且精心设计了计划以最大限度地减少停机时间。

为了进行维护，一开始我们向Ozone集群添加了七个新的数据节点，然后手动将一半的容器从旧的数据节点移动到新的数据结点。虽然这次的维护需要对Ozone执行情况及其内部数据结构有深入的了解，但幸运的是，我们完成了维护，没有遇到任何问题，一个月后集群仍然健康。

参考文献

• [1] Development of Universal Neural Network for Materials Discovery, PFN Tech Blog, 2022
• [2] A Research for Geophysical Exploration Methods using a Deep Learning Technology (深層学習を用いた物理探査技術の研究開発; written in Japanese), PFN Tech Blog, 2021
• [3] An Analysis of Earthquake Wave with Machine Learning (機械学習を用いた地震波解析; written in Japanese), PFN Tech Blog, 2022
• [4] Learning Time Evolution Dynamics in Low-Dimensional Latent Spaces of Numerical Simulation Data (数値シミュレーションデータの低次元潜在空間における時間発展ダイナミクスの学習; written in Japanese), 2022
• [5] Containers, Documentations for Apache Ozone, 2021
• [6] Storage Container Manager, Documentations for Apache Ozone, 2021
• [7] MANIFEST, RocksDB Wiki, 2022

软件定义的存储正在帮助各行各业的客户管理他们的数据。它也可以帮助你的公司。最近的一篇eWeek文章揭穿了围绕软件定义存储的一些常见神话，展示了这种技术如何被误解。但是，有一些很大的好处，因此了解软件定义的存储在公司的旅程中可以发挥的作用非常重要。

什么是软件定义存储（SDS）？

软件定义存储（SDS）是一种存储架构，可根据一组松散耦合的软件和硬件组件满足各种数据存储要求。 SDS是一种包含传统和较新类型工作负载的模型，并针对硬件和软件解决方案之间的互操作性进行了优化。简而言之，它为您提供了更高的灵活性，使您可以接收，使用和探索不同的数据存储选项，并更好地利用数据来获得更多业务洞察。

 

有什么好处？

1. 更聪明地工作。 SDS在工作负载和存储之间创建更智能的交互。它支持更动态的存储配置，帮助存储更好地适应工作负载需求，并在服务器上提供存储功能。
2. 实现敏捷的存储消耗。 SDS支持新兴和传统的IT消费模型，实现跨云，移动，社交和分析基础架构的技术灵活性。
3. 获得控制和效率。 SDS提供满足快速变化的业务需求所需的灵活性，控制和效率。它动态优化基础架构功能以满足应用程序服务级别的要求。
4. 获取实时可扩展性。 SDS按服务级别提供分层容量，并能够按需配置存储，根据当前业务需求实现最佳容量。 SDS还为您提供存储基础架构使用情况的指标报告。

SDS提供的自动化和灵活性将有助于提高存储和员工效率，从而真正影响您的利润。我们的优化评估显示SDS策略可以减少花费的总金额。

介绍

在处理大量非结构化数据时，我们需要一个地方来存储它。 我们选择存储数据的方式有很多种，但今天我们要关注的一种是对象存储或基于对象的存储。 这是处理大量数据时的最佳选择，特别是因为它并不昂贵，并且可以更轻松地管理这些数据。
如果您不熟悉它，对象存储是一种数据存储架构，允许您将大量非结构化数据存储在可扩展的对象结构中。 它将数据存储为具有元数据和唯一标识符的对象，从而更容易访问该数据。 现在，有许多平台提供对象存储设施。
这就是为什么在本文中，我们将告诉您四个有用的开源对象存储平台，它们包含强大的功能，使它们成为 2022年的重大投资。

1.LakeFS

LakeFS 是一种开源数据环境工具，可让您管理基于对象存储的数据湖。 这些数据湖是存储库，您可以在其中转储所有结构化和非结构化类型的数据。 LakeFS 还集成了许多工具并支持 Amazon S3 和 Google Cloud Storage。 此外，它适用于所有主要数据框架，例如 Hive、Spark、Presto、AWS Athena 等。
使用 LakeFS，您可以扩展 PB 级数据，还可以通过其类似于 Git 的分支和版本控制方法向其中添加数据，这使您可以在不破坏数据的情况下添加更新。 这种类似于 Git 的方法还有助于轻松撤消数据更改，这使得处理数据更加容易和安全。
您还可以通过查看 LakeFS 文档了解其他特性和功能。

2.Ceph

Ceph 是对象存储、块存储和文件系统的开源平台。 它提供与 Amazon 的 S3 REST API 和 OpenStack 的 API Swift 完全兼容的对象存储功能。
Ceph 的对象存储允许您使用本地语言绑定和 Ceph 提供的其他技术轻松访问数据对象。 如果您想转变公司的 IT 基础架构及其管理大量非结构化数据的能力，这是一个很好的解决方案。 他们还有一些软件库，使用 Java、C、C++、Python、PHP 和其他几个编写的软件能够使用原生 API 的强大功能访问 Ceph 的对象存储系统。

3. MinIO

MinIO 是一款开源云存储软件，提供高性能分布式对象存储，专为大规模数据基础设施而设计。 它与 Amazon S3 API 兼容，并且它在 GitHub 上拥有超过 26,000 颗星，有超过 680 名贡献者在为它工作。
MinIO 服务器存储所有类型的非结构化数据，例如照片、视频、日志文件等。 它也可在开源 Apache V2 许可下使用，许多最强大的大数据和机器学习应用程序都使用 MinIO S3 对象存储。 您可以在 MinIO 网站上查看许多其他功能。

4.OpenIO

OpenIO 是一种开源对象存储解决方案，用于管理和保护大量非结构化数据。 它允许您构建和操作具有弹性且安全的大规模存储基础架构。
OpenIO 与 S3 兼容，可以在任何硬件上部署或云托管。 添加新硬件时也不需要重新分配数据； 您可以立即使用额外的容量。 OpenIO 还专为大规模基础设施和大数据工作负载而设计。 除此之外，它还提供了一个直观的用户界面来简化存储管理员的日常生活。 因此，您的数据变得非常易于访问且易于管理。

结论

您可以使用许多开源对象存储提供程序，它们提供了我们提到的许多功能中的一些功能。 它们为您的所有存储需求提供了良好的解决方案，并避免了高昂的财务成本。 因此，选择具有您需要的所有功能的对象存储平台非常重要。

原文：https://betterprogramming.pub/4-open-source-object-storage-platforms-fo…

本文：

关键点

• 使存储系统具有云感知的传统方法是提升和转移方法。虽然它是有效的，但根据我们的经验，投资重构架构，使其更能感知云，可以产生更好的结果。
• 在跨区域环境中部署Apache BookKeeper的当前解决方案需要将BookKeeper存储节点手动映射到特定的区域/可用性区域，但这并不能在区域中断期间提供相同的持久性和可用性保证。
• Salesforce使Apache BookKeeper具有云感知的独特方法包括为BookKeeper存储节点提供智能，以便它们在基于云的部署中有效运行，同时保持BookKeeper保证的持久性和可用性。
• 这些新增功能使集群更容易打补丁、升级和重新启动，对使用服务的影响最小。

在Salesforce，我们需要一个可以处理两种流的存储系统，一种是写前日志（write-ahead logs  WAL）流，另一种是数据流。但是我们有来自两个流的竞争需求。预写日志流应该是写的低延迟和读的高吞吐量。数据流应该具有高的写吞吐量，但具有低的随机读延迟。作为云计算的先驱，我们也要求我们的存储系统能够感知云，因为对可用性和持久性的要求越来越高。我们的部署模型被设计为不可变的，以便能够扩展到大规模的级别并在普通硬件上运行。

开源替代

我们对这种存储系统的最初研究遇到了构建还是购买的问题。

考虑到我们所有的期望和需求都取决于上市时间、资源、成本等主要业务驱动因素，我们决定采用开源存储系统。

在研究了开源所能提供的服务之后，我们确定了两种最终的选择:Ceph和Apache BookKeeper。随着系统对我们的客户可用的需求，规模到大规模的水平，也作为一致的事实来源，我们需要确保系统可以满足我们用例的CAP定理的方面。让我们鸟瞰一下BookKeeper和Ceph在CAP定理(一致性、可用性和分区容忍度)和我们独特的要求方面的立场。

Ceph提供了一致性和分区容忍，而读路径可以提供不可靠读取的可用性和分区容忍。要让写路径提供可用性和分区容忍度，还有很多工作需要做。我们还必须记住部署的不可变数据需求。

我们决定Apache BookKeeper是我们用例的明确选择。它接近于我们所需要的CAP系统，因为它的数据存储设计是只附加/不可变的，并且是高度复制的分布式日志。其他主要特点:

• 一旦一个写入被确认，它总是可读的。
• 一旦一个条目被读取，它总是可读的。
• 没有中央主服务器，厚客户机，使用Apache Zookeeper来达成共识和元数据。
• 没有复杂的散列/计算的数据放置。

此外，Salesforce一直鼓励开源，Apache BookKeeper社区是一个活跃且充满活力的社区。

Apache BookKeeper -几乎完美，但需要更多的工作

虽然Apache BookKeeper已经为我们的需求检查了大多数框，但仍然有差距。在我们进入差距之前，让我们了解一下Apache BookKeeper提供了什么。

• 每个存储节点都被称为赌徒（bookie）。“Ensemble”是一组赌徒。
• “条目”（Entry）是你能写的最小单位。它也是不可变的。
• 一个“分类账”（Ledger）是由一系列的条目组成的，这些条目也遵循了一个不可变的只添加的模型。
• “写入仲裁”（write quorum）是指将数据写入或复制到该条目的最大复制数。
• “ack quorum”是在确认写入之前确认数据的赌徒数量——条目的最小复制。

从耐久性的角度来看，账本被复制到一个赌徒的集合中，账本内的条目也贯穿于整个集合中。

Ensemble Size: 5 Write Quorum Size: 3 Ack Quorum Size: 2

写入是基于可配置的写入和确认仲裁进行确认的。这提供了较低的写延迟和扩展能力。

然而，事实证明，在云中的商用硬件上运行BookKeeper具有挑战性。

数据放置策略不是原生云感知的，也没有考虑到底层的公共云提供商(云底层)。一些用户目前部署它的方式是手动识别不同可用性区域中的节点，将它们逻辑地分组在一起，并在这些节点组上改进现有的放置策略。虽然这是一种解决方案，但它不提供对区域故障的任何支持，也不提供维护和升级大规模集群时的易用性。

众所周知，所有的云底层都经常出现跨可用性区域的宕机，一般的理解是应用程序应该针对这些故障进行设计。一个很好的例子是Netflix在2012年圣诞节期间受到了亚马逊网络服务可用区中断的影响。Netflix的服务一直以有限的容量运行，即使它所依赖的底层公共云基础设施宕机了。

公共云中的问题

互联网——从网站到应用程序，甚至企业软件——大多运行在公共云提供商提供的基础设施上。这是因为公共云基础设施易于扩展，并且在一定程度上使用和维护成本更低。然而，它也有其缺陷，其中之一就是节点、区域或区域级别的不可用性。如果底层基础设施不可用，那么用户实际上什么也做不了。这可能是由于某些机器、区域或区域的停机。它甚至可能是由于硬件故障导致的网络延迟增加。因此，最终，作为在这个公共云基础设施上运行的应用程序，我们——开发人员——在设计时要考虑到它的缺点。

Apache BookKeeper没有针对这种可能性的内置答案，因此我们需要设计一个修复程序。

Salesforce 的重新架构

现在我们对问题有了大致的了解，我们开始思考如何修复它们，以便使Apache BookKeeper具有云感知并符合我们的需求。我们将这些差距归纳如下:

• Bookies 需要在公共云中的集群中提供一个身份。
• 为了提供更好的可用性、更容易的维护和更平滑的部署，需要将数据放置策略设计为根据可用性区域分布的集成。
• 现有的博彩功能(如读、写和数据复制)需要更改，以便利用多区域布局，并考虑跨这些区域传输数据的成本。
• 所有这些都应该是云底物不可知的。

让我们看看我们是如何解决这些差距的。

用于云感知的cookie和Kubernetes

现有的BookKeeper架构为每个赌徒提供了在其首次启动时分配的唯一标识。这个标识持久化在元数据存储中(Zookeeper)，其他赌徒或客户可以访问它。

让Apache BookKeeper具有云感知的第一步是让每个赌徒知道他们在Kubernetes中部署的集群中的位置。我们认为这些饼干是最好的信息来源。

我们在cookie中添加了一个名为“networkLocation”的字段，该字段由两个可以定位赌徒的主要组件组成——可用性区域和升级域。使用Kubernetes允许我们不考虑底层，所以我们使用Kubernetes api来查询底层可用性区域信息。我们还根据一个涉及主机名序号索引的公式生成' upgradeDomain '。upgradeDomain可以用于滚动升级，而不影响集群的可用性。

所有这些信息都是在启动时生成的，并持久化到元数据存储中以供访问。

现在可以在生成集合、向集合指定赌徒以及决定从哪个赌徒复制或复制到哪个赌徒时使用这些信息。

公共云放置策略

现在我们在客户端中有了智能，这样它就可以与特定区域的赌徒通信，我们需要确保我们有一个利用这些信息的数据放置策略。我们的一个独特的发展是ZoneAwareEnsemblePlacementPolicy (ZEPP)。它是专为基于云的部署而设计的两级分层放置策略。ZEPP知道可用分区(AZ)和升级域(UD)。

AZ是区域内逻辑隔离的数据中心。UD是AZ内的一组节点，可以一起关闭，对服务没有影响。它还提供了理解区域何时停止和何时恢复的启发式方法。

下面是ZEPP可以使用的一个可视化部署。此部署考虑来自cookie的AZ和UD信息来对赌徒节点进行分组，如图所示。

可用性、延迟和成本

通过这些改变，我们已经能够使Apache BookKeeper真正具有云意识。然而，在设计此架构时考虑成本也很重要。大多数云基质对其服务之外的单向数据传输收费，跨可用性区域时收费是不同的。对于BookKeeper客户端来说，这是需要考虑的一个重要因素，因为它目前从集合中任意选择一个赌徒来满足读取。

如果赌徒是来自另一个可用区域比客户，这将导致不必要的收费。数据复制现在将在分布在可用性区域的赌徒之间进行，在可用性区域下降的情况下将导致更多的成本。

让我们看看如何处理这些特定的场景。

重新排序读取

目前，簿记员（BookKeeper ）客户端从一个集合中任意选择一个赌徒来满足阅读。

通过我们的重新排序读取功能，客户端现在选择了一个赌徒，这样可以最小化读取延迟，同时降低成本。

重新排序读取功能开启后，客户端按以下顺序选择赌徒:

• 从本地区域按能满足请求和有更少未决请求的赌徒顺序排序。
• 从一个远端区域按能满足请求和有较少待处理请求的赌徒顺序。
• 下一个来自本地区域的赌徒，其失败次数最少或未挂起的请求超过配置的阈值
• 下一个来自远程区域的赌徒，其失败次数最少或未挂起的请求超过配置的阈值

按照这个顺序，我们在一个运行了很长时间并经历过故障的系统中进行了适当的权衡，以满足延迟和成本需求。

处理区域故障

在区域下降的情况下，现在来自不同集合的所有赌徒将开始复制他们的数据到当前可用区域的赌徒，以满足集合的规模约束和法定人数要求，造成一个“雷鸣群体问题”。

我们处理这个问题的方法是，首先决定一个区域什么时候实际上是下降的。故障可能是短暂的信号;我们不希望仅仅因为一个网络信号导致一个区域不可用而开始复制tb级的数据。与此同时，我们想要为真正的失败做好准备。

我们的解决方案有两个阶段:

• 识别一个区域什么时候真正下降，什么时候是暂时的波动。
• 将整个区域的大规模自动复制移动到手动操作中。

下面的图表显示了我们在声明区域关闭和区域恢复时考虑的启发式。

HighWaterMark和LowWaterMark是两个值，它们是根据一个区域中可用的赌徒数量与该区域中总赌徒数量计算的。这两个值的阈值是可配置的，因此用户可以根据他们认为的故障来决定故障的灵敏度。

当一个区域被标记为down时，我们还禁用自动复制，以避免跨区域自动复制tb级的数据。我们在其位置上添加了警报，以提醒用户可能出现的区域故障。我们相信，运营专家能够区分噪音和真正的故障，并决定是否启动整个区域的自动复制。

我们还提供了启动已禁用的自动复制的赌徒shell命令。

我们学到了什么

Apache BookKeeper是一个非常活跃的开源项目，并拥有一个令人惊讶的支持社区，社区中对该系统面临的所有挑战进行了充满活力的讨论。由于它是许多用户的真实来源，它需要成为云感知。

然而，这样的架构更改在每个级别上都有权衡和决定因素——可用性、延迟、成本、部署和维护的便利性。上述考虑和改变已经在Salesforce进行了战斗测试，现在我们可以使用Apache BookKeeper支持AZ和AZ+1故障。我们已经合并了一些更改，并将在未来的版本中继续为社区做出更多贡献。这些添加的目的是使集群更容易打补丁、升级和重新启动，同时对使用服务的影响最小。

关于作者

Anup Ghatage是旧金山的一位软件开发人员。

他喜欢在维护和开发高度可伸缩的系统中挑战问题。他目前是Salesforce的技术人员领导成员，在那里他致力于云基础设施和数据工程。他也是Apache Bookkeeper的提交者和积极贡献者。他曾任职于SAP和思科系统公司，拥有浦那大学计算机科学学士学位和卡内基梅隆大学硕士学位。你可以在推特@ghatageanup上联系到Anup。

原文：https://www.infoq.com/articles/storage-cloud-apache-bookkeeper/

本文：http://jiagoushi.pro/node/1505

讨论：请加入知识星球【首席架构师圈】或者小号【cea_csa_cto】或者QQ【2808908662】

全球传输和生成的数据比以往任何时候都多。国际数据公司(IDC)的分析师预计，到2025年，全球数据层将增至163zb。这比2016年16.1 ZB的数据增长了1000%以上。数据大量增加的原因是多方面的:

生成数据的来源和设备比以前多得多——嵌入式系统和设备正在收集数据并将其传输到大数据应用程序和解决方案中进行实时分析。使用移动设备、社交媒体平台、在线购物以及随时随地使用各种应用程序的持续趋势每天都在产生大量数据。此外，企业正在进行一场向客户提供数据的转型，以满足他们对从未见过的新闻和实时数据日益增长的需求。

根据Gartner的最新预测，到2020年，超过一半的主要业务流程和系统将在其组织中加入物联网(Internet of things)的某些元素。与此同时，由大数据应用程序生成、传输和分析的数据量(这些数据将被存储在内部或外部)将大幅增长。

由于对存储的需求，管理部门和IT部门的代表已经大大增加了能够处理和存档比以往任何时候都多的数字内容的解决方案。

然而，从硬件的角度来看，现在不仅需要更大数量的存储设备——例如硬盘、ssd或SSHDs——而且还需要一个适当的文件系统来处理这种大数据增长的结果。这是因为即使不是所有的数据都存储在存储设备上，最重要的数据以及分析结果也会被存储在存储设备上。这将导致存储空间的需求增加。此外，大部分存储需求将由企业内部处理，也可以通过Amazon的S3或Microsoft Azure等云服务处理。

带有文件存储和块存储的旧的存储概念将不适用于未来的数据增长，对企业和云提供商都是如此。存储这些海量数据的解决方案是对象存储(也称为基于对象的存储)。但是，与以前的概念相比，它们之间的区别是什么?是什么使对象存储更好地适应数据爆炸?

要理解对象存储所提供的好处，必须首先了解文件存储和块存储的旧概念，因为它们之间有很大的差异。

文件、块和对象存储之间的区别

文件存储和块存储是在NAS和SAN存储系统上存储数据的方法。

在NAS系统上，它将其存储作为网络文件系统公开。当设备附加到NAS(网络附加存储)系统时，将显示一个挂载文件系统，用户可以使用适当的访问权限访问其文件。因为NAS系统必须管理用户权限、文件锁定和其他安全措施，以便多个用户可以访问文件。对NAS的访问通过NFS和SMB/CIFS协议进行处理。与任何服务器或存储解决方案一样，文件系统负责在NAS中定位文件。这对于数十万甚至数百万的文件非常有效，但对于数十亿的文件就不行了。

块存储的工作方式与此类似，但与在文件级管理数据的文件存储不同，数据存储在数据块中。几个块(例如在SAN系统中)构建一个文件。一个块由一个地址组成，如果SAN应用程序对这个地址发出scsi请求，那么它将获得这个块。存储应用程序然后决定数据块是否存储在系统中，以及存储在什么特定的磁盘或存储介质上。最后如何组合这些块以及如何访问它们决定了存储应用程序。SAN中的块没有与存储系统或应用程序相关的元数据。换句话说:块是没有描述、关联和存储解决方案所有者的数据段。一切都由SAN软件处理和控制。由于SAN和块存储经常用于需要性能的应用程序，如数据库或事务，因为数据可以访问、修改和保存。

这两种存储数据的方法多年来都运行良好。那么，为什么需要另一个概念呢?这是因为这两个概念的解决方案都需要实现用户访问权限的功能，以便对数据进行更改。

我们现在看到的是，产生的大部分数据是“固定的”或非结构化数据。内容或材料不会再改变。这就是对象存储发挥作用的地方:

对象存储中的对象是与相应元数据“绑定的数据”(即文件)。该对象获取一个惟一的ID(标识符)，该标识符是从文件内容和元数据中计算出来的。应用程序通过这个ID标识对象。对象存储系统中的许多对象都存储在给定的存储磁盘上。在纯形式的对象存储中，“只能”保存一个文件(对象)的一个版本。如果用户进行了更改，相同文件的另一个版本将存储为新对象。因此，对象存储是备份或归档解决方案的完美解决方案。或者，例如，存储大量的视频或电影，这些视频或电影只能被观看，不能像在线电影流媒体网站或YouTube上的视频那样被改变。

其他概念之间的主要区别是通过支持对象存储的应用程序本身来管理对象。这意味着这里不需要真正的文件系统。这一层已经过时了。使用对象存储的应用程序将存储查询发送到解决方案中存储对象的位置。然后，在巨大的存储空间中给对象一个地址，并由应用程序本身保存在那里。

由于数据管理非常简单——没有真正的文件系统——对象存储解决方案比文件存储或基于块存储的系统更容易扩展。您只需在解决方案中添加一些磁盘，就不再需要大的管理来获得更多的存储空间。这是一个主要的好处，尤其是在指数级数据增长的时代。

因此，对象存储是处理大量数据的完美解决方案，因此被Amazon、谷歌等大型云服务提供商高度使用。但是数据保护和数据恢复呢?我们将在本文的第二部分提供这些问题的答案。

 

讨论：请加入知识星球【首席架构圈】