李明宇聊聊在OpenStack云环境下搞大数据系统那些坑和解决招数

李明宇在分享他在OpenStack云环境下构建大数据系统的经验时,主要聊了以下几个让他印象深刻的“坑”以及他们摸索出来的“解决招数”，他特别强调，这些经验都是从实际项目中“摔打”出来的，很实在。

第一个大坑：存储性能像过山车，时好时坏

李明宇说,最开始他们觉得OpenStack提供的共享存储（他提到用的是Cinder服务）很方便，可以动态给大数据集群的节点分配硬盘空间，但真把像Hadoop HDFS这种分布式文件系统跑上去之后，问题就来了，大数据任务一跑起来，尤其是那些需要大量读写中间数据的任务，比如Spark的Shuffle阶段，磁盘的读写速度就变得非常不稳定，有时候快，有时候慢得让人抓狂，直接导致整个数据分析任务的时间被拖长了好几倍。

解决招数： 他们试了几个办法。给计算节点“加餐”，就是不再完全依赖网络共享存储，而是在每个运行计算任务的虚拟机所在的物理服务器上，直接挂上几块性能好的本地固态硬盘（SSD），让那些对IO要求最高的临时数据读写操作都在本地SSD上进行，速度一下子就上来了，他们对OpenStack的存储后端做了优化，比如选择性能更好的存储驱动，并且把用于大数据存储的卷类型单独隔离出来，避免被其他不重要的虚拟机磁盘IO干扰，简单说，就是“好钢用在刀刃上”，把最快的存储资源留给最需要的数据。

第二个大坑：网络成了看不见的瓶颈，查问题像破案

大数据系统里,节点之间传输数据是家常便饭，李明宇形容，在物理机时代，网络问题相对好排查，网线、交换机端口都看得见摸得着，但在OpenStack的虚拟网络里，问题就复杂了，他们遇到过一种情况：明明每个虚拟机的配置都很高，但数据在节点间传输就是快不起来，后来花了很大力气排查，才发现是OpenStack虚拟网络节点（他提到是Neutron服务）的底层参数设置不合理，导致数据包转发效率低下，这种问题非常隐蔽，因为从虚拟机操作系统内部看，网络似乎是通的，但性能就是上不去。

解决招数： 他们成立了临时的“网络特调小组”，第一，大力推行“扁平化”网络，尽可能让需要大量通信的大数据集群节点部署在同一个大的虚拟局域网内，减少数据包经过虚拟路由器的次数，第二，和运维团队一起，深入检查并优化Neutron组件的配置，比如调整虚拟交换机的型号和参数，开启支持大帧传输等，第三，他们开始在集群规划时就考虑“亲和性”，也就是通过OpenStack的调度策略，让需要频繁通信的虚拟机实例尽量被创建在同一个物理机架或者距离相近的物理服务器上，缩短网络的实际物理路径。

第三个大坑：资源分配死板，集群忙的忙死闲的闲死

大数据任务的特点就是潮汐性很明显,白天上班时间分析任务多，资源紧张；到了深夜可能又空闲下来，李明宇说，如果用传统物理机，为了保证高峰期的性能，就必须按照最高峰值来采购机器，平时大部分机器都闲置着，很浪费，上了OpenStack云平台，本来指望能实现弹性伸缩，但初期他们配置的规则很死板，只有当整个集群的CPU平均利用率连续很高时，才会触发扩容，等扩容完成，用户可能都等不及了，而且缩容的时候又很粗暴，不管虚拟机上面是否还有任务没跑完，直接就给关掉了，导致任务失败。

解决招数： 他们引入了更智能的“弹性伸缩”策略。监控指标不再只看整集群的CPU平均负载，而是结合了任务队列的长度，当待处理的分析任务积压到一定数量时，就立刻触发扩容，反应更快。缩容时设置了“优雅退出”机制，在准备关闭一个虚拟机节点前，会先通知大数据平台的调度器（比如YARN），让这个节点进入“排水模式”，不再接受新任务，并等待现有任务完成后，再安全地关闭虚拟机，这样既节省了资源，又不会影响正在运行的任务，他们还为不同部门设置了资源配额和优先级，保证关键任务在资源紧张时能优先获得资源。

第四个大坑：镜像管理混乱，环境一致性难保证

大数据集群的节点上需要安装很多复杂的软件,比如特定版本的Java、Hadoop、Spark等，李明宇提到，一开始他们让用户自己从标准镜像创建虚拟机，然后手动安装配置软件，结果就是“千人千面”，每个节点环境都有细微差别，出了问题很难统一排查，后来他们尝试用脚本自动化安装，但安装过程很耗时，创建一个新节点要等很久。

解决招数： 他们下决心做“黄金镜像”，就是预先制作一个包含了所有基础软件和优化配置的虚拟机模板镜像，这个镜像是经过严格测试的，保证环境完全一致，任何节点需要扩容或者重建时，都从这个“黄金镜像”快速启动，启动后只需要注入少量个性化配置（比如主机名、加入集群的标识）就能投入使用，速度非常快，他们还将镜像版本化管理，每次软件升级就做一个新版本的镜像，方便回溯和统一升级。

李明宇最后总结说,在OpenStack上搞大数据系统，最大的体会就是不能把云平台仅仅当作一个虚拟化工具，而是要真正理解大数据应用的特性（计算密集、IO密集、网络密集、弹性伸缩），然后主动去调整和优化云平台的各项服务（计算、存储、网络）来贴合这些特性，这个过程需要大数据团队和云平台运维团队紧密协作，不断地磨合和调优，才能最终让大数据系统在云上平稳高效地跑起来。