HDFS 下一代对象存储 Ozone 在腾讯的使用

vlambda
2020-12-10

HDFS 下一代对象存储 Ozone 在腾讯的使用

背景介绍

腾讯目前在HDFS上存储了海量的数据，但HDFS在可扩展性上的缺陷，以及对小文件的不友好，限制了HDFS在许多场景下的应用。

为了寻找能解决这些问题的存储系统，Ozone走入了我们的视野。Ozone是继HDFS的下一代统一数据湖对象存储系统，数据湖是一种在系统或存储库中以自然格式存储数据的方案，它有助于以各种模式和结构形式配置数据，通常是对象块或文件。

HDFS缺陷

Apache Hadoop HDFS从出现到现在经过10多年的发展，已经到了非常成熟的状态，广泛应用于业界，解决海量文件的存储需求。但随着数据量的增长，以及对于数据使用方式的多样化，HDFS的架构局限性就逐渐被放大，NameNode在大规模场景很容易成为瓶颈：

•元数据的扩展性：NameNode是一个中央元数据服务节点，也是集群管理节点，文件系统的元数据以及块位置关系全部在内存中。NameNode对内存的要求非常高，需要定制大内存的机器，内存大小也限制了集群扩展性。京东的NameNode采用内存512GB的机器，字节跳动的NameNode采用内存1TB的机器。此外，NameNode的堆分配巨大，京东的NameNode需要360GB的堆大小，对GC的要求比较高，京东定制化的JDK11+G1GC在GC时性能良好，但是一般规模的公司不具备维护JDK能力，该方案不具备普遍性。字节跳动把NameNode修改成C++版本，这样分配、释放内存都由程序控制，也达到了不错的性能，该方案仍然不具普遍性，因为开发和维护C++版本的NameNode也需要不小规模的团队。

•块汇报风暴：HDFS块大小默认128M，启动几百PB数据量的集群时，NameNode需要接受所有块汇报才可以退出安全模式，因此启动时间会达数小时。当集群全量块汇报、下线节点、balance集群存储，也会对集群元数据服务的性能造成影响，这些根本原因都是DataNode需要把所有块汇报给NameNode。

•全局锁：NameNode 有一把FSNamesystem全局锁，每个元数据请求时都会加这把锁。虽然是读写分开的，且有部分流程对该锁的持有范围进行了优化，但依然大问题。同时FSNamesystem内部的FSDirectory（Inode树）还存在一把单独的锁，用来保护整棵树以及BlockMap的访问和修改。

Ozone优势

为了解决HDFS的上述问题，Hadoop社区推出分布式key-value对象存储系统Ozone，兼容文件访问接口。利用Hadoop Compatible FileSystem接口， Ozone可以用于大数据生态；利用CSI，S3协议， Ozone可以作为云存储服务云上用户。

Ozone架构分为三个部分，OzoneManager、StorageContainerManager、Datanode。OzoneManager相当于HDFS的Namespace元数据；StorageContainerManager相当于HDFS的Block Manager，但管理的是Container而不是HDFS的Block。而Datanode使用Raft实现的Ratis保证写一致性。

HDFS的三个局限，Ozone采用如下方式解决：

•Ozone把Namespace元数据服务和Block Manager拆分为两个服务。OzoneManager负责元数据服务；StorageContainerManager负责数据块管理、节点管理、副本冗余管理。两个服务可以部署在两台机器，各自利用机器资源。Ozone的元数据不像NameNode存储在内存中，不管是OzoneManager的元数据，还是StorageContainerManager中的Container信息都维护在RocksDB中，极大降低对内存的依赖，理论上元数据可以无限扩展。

•StorageContainerManager无须管理默认128MB的Block，只需管理默认5GB的Container。极大地减少了StorageContainerManager管理的数据量，从而提升StorageContainerManager的服务性能。因为StorageContainerManager是以Container作为汇报单位，汇报数量比HDFS大大减少。无论是全量块汇报，增删副本，balancer集群存储，都不会给StorageContainerManager性能造成很大影响。

•OzoneManager内部的锁是Bucket级别，可以达到Bucket级的写并发。Ozone是对象存储，对象语义的操作，不存在目录和树的关系，因此不需要维护文件系统树，可以达到高吞吐量。

Ozone稳定性提升

腾讯正将越来越多的业务接入Ozone，包括数据仓库、机器学习平台、K8S集群挂载盘等等。因此亟需提升Ozone的成熟度，而大规模集群上能否长时间稳定运行是检验成熟度的一个非常重要的标志。因此我们采用线上业务真实数据，在千台以上Datanode的单集群上，进行读、写、删操作，观察集群稳定性，以及数据正确性。

在经过长时间的反复验证改进后，内部Ozone能够以千台以上的规模长时间稳定运行，且无须人工运维介入。在验证改进过程中，我们做了大量的优化工作来改进性能，提升稳定性。在接下来的内容中，我们将会分享几个重点的改进案例。

优化历程

在千台集群规模之前，已提前进行小规模的测试，并测出若干导致集群不稳定的因素，例如内存泄露、吞吐量下降、Ratis Group不稳定等问题。这些问题的修复，保证了千台Datanode的集群能长时间稳定运行。接下来介绍三个优化实例：

内存泄露

内存是影响Ozone Datanode和S3gateway稳定的最主要因素。长期运行中发现若干内存泄露问题，导致Datanode、S3gateway宕机。本文介绍两个典型内存泄露问题。

案例一

绝大部分Datanode宕机后产生core.pid文件，但没有产生crash log，也没有产生heap dump；少部分Datanode宕机后产生crash log，但没有产生core.pid，也没有产生heap dump。Ozone本身采用Java实现，但也使用C++实现的RocksDB。因此可以确认core文件是RocksDB异常退出时产生，而crash log是JVM crash时产生。

首先用gdb分析core.pid，堆栈如下，可以看出rocksdb创建线程时宕机，而且崩溃在libstdc++里，这是C++标准库，基本不可能出现问题，因此怀疑其他原因导致创建线程失败。

注意到gdb打开core文件时，有大量New LWP，LWP为轻量级进程即线程。因此怀疑线程数过多，用info threads打出所有线程，可以看到有32599个线程都在wait锁。

接下来分析32599个线程都是什么线程，随机选出几十个线程分析，用thread threadid命令切换到对应线程，并查看线程堆栈，发现绝大部分线程来源于/usr/java/jdk1.8.0_191-amd64/jre/lib/amd64/server/libjvm.so，这表示绝大部分线程都是jvm创建出来的。因此问题仍然在Java代码里，大量Java线程，占用太多内存，导致创建C++线程时宕机。

继续分析crash log，可以看出JVM创建线程时因为OOM崩溃，从crash log可以找到26000多个Datanode State Machine Thread线程，都处于block状态。查看代码发现Datanode State Machine Thread是使用newCachedThreadPool创建的线程池里的线程，而newCachedThreadPool在所有线程block时，会不断创建新的线程，导致产生26000多个线程。至此可确认，产生core.pid的宕机和产生crash log的宕机是同一个原因：Datanode State Machine Thread线程太多。

接着分析大量Datanode State Machine Thread线程被block的原因，在每个Datanode线程数超过7000时，自动执行jstack打出所有线程堆栈，发现有7939个Datanode State Machine Thread线程，其中7938个处于等锁状态，只有1个编号5500的线程拿到锁但卡在rpc调用里。