云计算凭借其强大的分布式计算能力，可伸缩的特性以及低成本高可靠性的优势,在海量数据处理方面占据优势地位。但是日常所产生的数据并非都是需要随时存取的，事实上，我们依赖于云服务进行存储的数据，大多数都不是需要频繁访问的热点数据，大量的数据被存储后访问频率很低（例如数据归档,长期备份等场景,平均一年访问一次甚至更低），这时候我们可以将这些不再经常使用的“冷数据”转移到一种成本更低的存储设备来进行长期保存，我们称这种存储为归档存储。归档存储安全、持久且成本极低，为了保持成本低廉，数据取回时间可能需要花费数小时。

在数据归档领域，传统的磁带库或是蓝光盘库介质在过往一直是首选，这些磁带或者光盘一旦存储了数据，就意味着数据进入到数据中心某个不起眼的角落中，如无必要的话，这些数据将通常会进入到“沉睡”阶段，有些数据甚至几十年都不再被读取使用。如今数字经济的背景下，冷数据的价值挖掘受到了越来越多的关注，灵活的数据检索，准实时的数据取回能力，也成为了新时代数据归档场景的核心需求。

UCloud19年上线的归档存储为对象存储US3提供了一套极低价格的数据存储系统，该系统具备存储速度快、可靠性高、数据取回灵活等特性，以下是该系统的介绍。

硬件架构

UCloud的存储硬件架构是采用两个机头连接多个JBOD的方式来组织的，一个机架里有多个JBOD和两个机头，每个JBOD都分别连接到两个机头的HBA卡上，每个JBOD容纳了一百块以上的硬盘，JBOD是存储领域中一类重要的存储设备，英文Just a Bunch Of Disks，意为磁盘簇，磁盘连续捆束阵列，是在一个底板上安装的带有多个磁盘驱动器的存储设备。不同于RAID阵列，JBOD没有用来管理磁盘上数据分布的前端逻辑，每个磁盘进行单独寻址，可以作为分开的存储资源，用户可以像访问普通硬盘一样，访问JBOD中的任意一块硬盘。JBOD在近几年被一些厂家提出，并逐渐被广泛采用。

硬盘的选择上我们首选HM-SMR（Host-Managed-SMR）盘，当然也兼容普通的CMR盘，SMR盘的优点是成本低廉，但是不支持随机读写，上面的数据按固定的大小（通常是256MB）被分为一个个的Zone，只有1%的CMR Zone是支持随机写的，剩余99%的SMR Zone都是只支持顺序写的，数据的擦除也是以Zone为单位的，这种盘的缺点是不适用于频繁更改性写入，但用来存储大容量，修改少的数据却十分合适，且成本低于普通HDD盘，适合作为UCloud归档存储的存储介质。

两个机头用于管理连接在上面的JBOD和硬盘，装有操作系统，它们之间是主从关系，主机头负责接收IO请求，主机头故障后，从机头接替成为主。

存储的成本其中还有非常显著的一部分是电力的开销，如果所有硬盘长时间保持全部上电状态，将带来比较大的一笔电力开销，考虑到我们归档存储写多读少的特性，且写入都是追加写，速度很快，少量的硬盘就可以充分利用网络带宽，所以我们的设计目标是在正常使用的情况下可以做到大部分的硬盘处于下电状态，只有少部分硬盘处于上电状态提供IO，在5年的质保期间保证50k的上下电频率，平均下来是小时级别。为此，UCloud在软件架构上设计了一套上下电调度策略，具体后文会有讲解。

软件架构

冗余策略

常用的冗余策略有副本和纠删两种方式，为了达到节省成本的目的，UCloud归档存储采用的策略是对数据进行纠删分片，又由于硬件架构上的较多硬盘配置，以及异步写的原因，我们采用了较大的EC比例。

Blob

考虑到前面提到的SMR盘的Zone和纠删条带的设定，我们引入了Blob这一概念,例如采用大比例的EC纠删策略,把综合考虑Zone和EC比例的数据划分到一个Blob，这样删除或压缩数据时可以以Blob为单位来进行。

磁盘组

我们把整个系统的磁盘分成了一个个逻辑的磁盘组。一次IO的所有纠删分片都在一个磁盘组中，一个Blob也只属于某一个磁盘组,例如23+3的纠删分片，那么一个磁盘组就包含26块盘,且上电，下电也是以磁盘组为最小单位的。当上层来了写IO时，为了避免磁盘组频繁上下电，会让一个磁盘组持续服务写操作，当该磁盘组写到一定的量后，按轮询策略挑选下一个磁盘组进行上电。

元数据

我们利用每块硬盘那1%的支持随机读写的CMR Zone来存储元数据信息，元数据信息包含两部分，Disk Meta和Zone Meta,Disk Meta用于保存整个磁盘的元数据，包含唯一标识这块盘的Disk ID,属于哪个JBOD，有多少个Zone，以及Zone Meta在磁盘中的偏移和长度等。Zone Meta用于保存这块盘每个Zone的元数据信息，包括这个Zone是第几个，有没有被使用等。

归档服务启动时，通过加载Disk Meta和Zone Meta在内存中构建每个Blob的信息。

上下电调度策略

为了节省电力成本，所有磁盘组并不是保持长期上电状态的，当没有读IO时，只有当前负责写的磁盘组处于上电状态，当这个磁盘组写到一定量后，切换到下一个写磁盘组上电，原来的写磁盘组安排下电。对于读IO，分为非紧急读和紧急读两种，如果是非紧急读，且这个读IO对应的磁盘组处于下电状态，则为这个磁盘组加一个读标记，每小时轮询所有磁盘组，将有读标记但处于下电状态的磁盘组上电，已处于上电状态的磁盘组如果超过一定时间没有收到IO请求会安排下电，也就是说，对于非紧急读，最多需要数个小时的时间来等待磁盘组上电，而对于紧急读IO来说，如果这次IO对应的磁盘组处于下电状态，则立即安排上电，进行数据读取，并且在1小时内不安排下电，用额外的电力成本提供了紧急读的服务。

IO流程

上层IO的数据通过计算被切割成一个个EC分片（如果数据大小没有按EC条带对齐需要填0），分别派发到其对应磁盘组的每个磁盘上，如果是非紧急读IO可能需要等待对应的磁盘组上电后进行重试，如果是写IO，当一个Blob写满后，也就是磁盘组中每个磁盘的当前Zone被写满后，会切换到下一个Zone，分配下一个Blob开始写，写成功后向上层返回这次IO对应的Blob编号和在这个Blob内的偏移，用于上层组织文件的元数据信息。

数据保存

数据在磁盘上是以4KB大小的Sector为单位写下去的，每个IO所携带的数据经过EC计算后落盘时，都会被拆分成一个个Sector,且在每个Sector的尾部都填充了一块Sector Meta，用于记录这个Sector的元数据信息，包括这个Sector对应了第几个Zone，以及这个Sector上数据的crc等，这样可以防止硬盘的静默错误。

周期性数据检查

归档服务启动后会周期性扫描已经写满的Blob，对这个Blob的每个Sector进行数据校验，这一过程利用了上文提到的每个Sector尾部的Sector Meta里保存的crc，校验失败时会上报错误，通知到相关运维人员进行处理。

总结

这套归档存储系统在保证了高性能、安全的前提下，大幅地优化了成本。非常适用于一些数据量大但访问频率不高的存储场景，比如保存一些下载量少的多媒体数据，大型数据库、日志、用户资料的备份等等。目前，UCloud归档存储服务已经于2019年上线，且稳定运行多年，预计随着更大范围的应用，将会更大幅度地节省存储成本。