云计算凭借其强大的分布式计算能力，可伸缩的特性以及低成本高可靠性的优势, 在海量数据处理方面占据优势地位。但是日常所产生的数据并非都是需要随时存取的，事实上，我们依赖于云服务进行存储的数据，大多数都不是需要频繁访问的热点数据，大量的数据被存储后访问频率很低(例如数据归档, 长期备份等场景,平均一年访问一次甚至更低），这时候我们可以将这些不再经常使用的“冷数据”转移到一种成本更低的存储设备来进行长期保存，我们称这种存储为归档存储。归档存储安全、持久且成本极低，为了保持成本低廉，数据取回时间可能需要花费数小时。
在数据归档领域，传统的磁带库或是蓝光盘库介质在过往一直是首选，这些磁带或者光盘一旦存储了数据，就意味着数据进入到数据中心某个不起眼的角落中，如无必要的话，这些数据将通常会进入到“沉睡”阶段，有些数据甚至几十年都不再被读取使用。如今数字经济的背景下，冷数据的价值挖掘受到了越来越多的关注，灵活的数据检索，准实时的数据取回能力，也成为了新时代数据归档场景的核心需求。
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年上线，且稳定运行多年，预计随着更大范围的应用，将会更大幅度地节省存储成本。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/128389.html
摘要：对此，存储产品经理周恭元在月日刚结束的技术分论坛上带来了海量数据云归档存储最佳实践的议题分享，围绕企业数据归档面临的存储问题及需求，重点介绍了数据存储的分层价值，以及新一代归档存储的可靠性优势及三大适用场景。随着互联网科技的不断进步，产生的数据将以成倍速度进行增长，据IDC预测，到2025年全球数据总量将会达到175ZB。如果要把175ZB用8TB的磁盘存下来的话，那就需要230亿块磁盘来存...
摘要：目前，对象存储是这些海量非结构化数据最好的存储载体。宋体做式的对象存储宋体是年推出的对象存储产品。宋体二业务低成本宋体对象级别的分层存储宋体采用专门的存储机型，存储密度更高，单位存储的成本最低可降到计算机型的。随着 5G+IoT 时代来临，产生数据的主角除了人类还有海量的物理设备，相比 4G 移动互联网的短视频、直播等，会有更大量的数据产生。据 IDC 发布的《数据时代 2025》的预测，全...
摘要：更多归档存储类型的使用说明请参考数据归档方案。控制台快速上手注产品已作为归档存储类型合并至对象存储，目前不再向新用户提供独立的归档存储服务。创建归档存储空间登录控制台，选择右侧归档存储后进入归档存储列表页，选择创建归档存储空间按钮。使用场景注：UArchive 产品已作为归档存储类型合并至 US3 对象存储，目前不再向新用户提供独立的归档存储服务。如需使用更低成本的对象存储服务，请至 US3...
随着数据量的增长、数据来源途径的多元化，企业用户需要考虑到私有云与公有云数据存储的统一性管理，从而随时随地能够从数据存储平台上获得用户所需要的数据，为业务创新带来敏捷的数据价值。当前行业用户对混合云的需求越发明显，云厂商也是不断推动混合云解决方案在百行百业中的深入发展，从而，让混合云与以软件定义为主导的存储显得越来越密不可分。因而，就带来了一个重要的混合云治理话题：混合云架构下，如何让数据存储无边...
摘要：三是可以降低我们的写放大，在写入时不会由于需要更新元数据而写入两次，这在随机能力不是强项的硬盘场景下也格外重要。前言UCloud在2020年8月正式发布了基于US3的全新一代归档存储产品，该产品采用UCloud全新自研存储架构，相较标准存储降低近80%存储成本的同时，与市场同类归档存储产品相比降低近30%的价格。据IDC的预测，全球年新增数据量到2025年将达175ZB，真正能存储下来的数据...
阅读 1284·2024-02-01 10:43
阅读 370·2024-01-31 14:58
阅读 432·2024-01-31 14:54
阅读 815·2024-01-29 17:11
阅读 2204·2024-01-25 14:55
阅读 1481·2023-06-02 13:36
阅读 2085·2023-05-23 10:26
阅读 469·2023-05-23 10:25
