★ FEATURED ARTICLE 看到“鲲鹏泰山arm服务器搭建ambari”这个标题我脑子里蹦出来的第一个词就是“折腾”。我去查了一圈资料发现网上关于Ambari的教程九成以上都是x86平台、CentOS 7、虚拟机一把梭真正能在ARM架构服务器上把Ambari跑起来的完整案例少得可怜。这背后的原因不复杂Ambari官方发布的RPM包和仓库存量基本只针对x86_64架构和特定操作系统做了二进制适配你在ARM平台上直接照搬x86教程大概率会在依赖解析或组件启动阶段卡到怀疑人生。这篇内容写给谁给手里正好有ARM架构服务器又想用开源Ambari来统一管理Hadoop生态组件的人。无论是单位内部搞大数据资源池还是个人实验室想验证非x86平台上的大数据能力只要你打算在ARM平台把Ambari这套东西“从0到1”拉起来这篇文章应该能帮你省下好几天的踩坑时间。我先把整体思路、版本适配、编译部署、故障排查这条主线交代清楚最后再把我个人踩过的几个坑单独拎出来讲。1. 为什么说这是“硬仗”ARM平台部署Ambari的真实困境1.1 Ambari到底解决什么问题先简单说一句Ambari是什么。它是一个开源的大数据集群部署、管理和监控平台你可以通过它自带的Web界面把HDFS、YARN、Hive、HBase、Kafka、Zookeeper这一整套Hadoop生态组件以非常图形化的方式装到一批服务器上。装完之后日常的服务启停、配置修改、性能指标告警也都能在这个界面上完成不用再挨个机器手动改配置文件。它的价值在于把“集群运维”这件事标准化。手动部署一个三节点的Hadoop集群要先处理HDFS格式化、配置分发、SSH免密、进程守护、日志收集一堆琐事稍有不慎就会漏掉一个配置项。而Ambari把这些步骤封装成了可重复执行的流程你只要在向导里选好组件、填好主机剩下的依赖检查、安装顺序、服务注册它自己会处理。但问题是Ambari官方对“平台支持”的定义非常死板。它只针对特定操作系统版本、特定架构发布编译产物架构这一栏几乎默认就是x86_64。这意味着在ARM机器上你拿不到“开箱即用”的安装包必须自己动手解决两件事一是把Ambari从源码编译成ARM平台能跑的产物二是把Hadoop全家桶里那些跟CPU指令集强相关的native库全部换成ARM版本。1.2 ARM平台和x86平台的根本差异这里说的“根本差异”不是简单地换个CPU那么简单。Ambari本身大部分代码是Java和Scala写的理论上Java字节码跨平台没问题但一旦到了安装阶段问题就全冒出来了。首先Ambari的RPM包在构建时会把平台相关的架构字符串写进依赖里比如Requires: glibc 2.17这种系统库依赖表面上没有架构标记但实际安装时RPM会按照当前系统架构去解析依赖。你在ARM机器上安装x86编译出来的RPMRPM包管理器会直接拒绝提示架构不匹配。其次Hadoop生态里的HDFS、YARN等组件大量依赖libhadoop.so这类通过JNI调用本地系统能力的动态库这些动态库必须针对ARM指令集重新编译不然就算装上了启动时也会报“Unable to load native-hadoop library”。我习惯把这套流程比作两件截然不同的事。在x86平台装Ambari相当于拎包入住精装房开发商把家具、水电、网络都给你布置好了你只需要打开门、签字入住。在ARM平台装Ambari相当于拿到一块地皮水电管网可能要自己从零铺设家具也得按房间尺寸重新打整个过程里你会反复在三件事上打转组件版本不匹配、依赖库找不到、架构不支持。1.3 三条路线与我的方案选型面对ARM平台部署Ambari这个问题业内大体有三条路线。第一条是找现成的ARM编译版本。这条路看起来很美好但实际能下载到的成品极少。多数第三方编译版本停留在老版本阶段而且往往只覆盖某几个组件你用了之后会发现Ambari的仓库里缺这缺那最后还是得回到源码编译。第二条是官方源码自行编译这也是我最终选择的路线。你需要准备一台编译环境把Ambari整个工程拉下来修改掉那些硬编码了x86_64的配置重新制作出适配aarch64的RPM包再维护一套自己的yum仓库。第三条是绕开Ambari直接用Apache Hadoop源码在ARM上编译再配上简单的脚本做管理。这条路可以做到最小可用但如果你要管理一整套复杂大数据组件脚本方案会迅速变得难以维护。我的最终方案是“第二条为主、第三条辅助”。Ambari核心组件自己编译而对于Hadoop生态里的某些发行版套件比如官方只提供x86_64的HDP包则采用自定义蓝图或外部服务纳管的方式从Apache Hadoop源码编译出ARM版本地库挂到Ambari的管理体系里。这样做既保证了集群管理的统一入口也没有在“必须把整套HDP塞进Ambari”这个点上死磕。2. 动手前必须确认的依赖与版本矩阵2.1 硬件拓扑与系统版本建议开始动手之前先把整个部署环境的“底盘”定死。硬件方面我的建议是至少准备一台独立的管理节点作为Ambari Server另外准备若干台数据节点作为Ambari Agent。管理节点不需要特别高的算力但内存一定要给够因为Ambari Server本身要跑Web服务、消息队列还会缓存部分集群状态数据。数据节点则要根据实际数据量配置。我这边用过的参考配置如下表格节点角色CPU核数内存磁盘主要承担的任务管理节点4核16GB100GBAmbari Server、MySQL/MariaDB、本地YUM源数据节点18核32GB300GBHDFS DataNode、YARN NodeManager数据节点28核32GB300GBHDFS DataNode、YARN NodeManager、HBase RegionServer数据节点38核32GB300GBHDFS DataNode、Zookeeper、Kafka操作系统版本我强烈建议选择兼容RHEL 7系列的内核生态而不是盲目追新。原因很简单Ambari 2.7.x系列是在systemd服务管理和Python 2.7环境下设计和测试的你要用基于Python 3的默认环境去硬适配会遭遇大量脚本兼容性问题。如果单位里有特定的国产Linux发行版只要它宣称兼容RHEL 7部署成功的概率就会高很多。内核版本在4.19左右、架构字段显示为aarch64或arm64这是最稳的起点。2.2 JDK、Python、数据库选型对照ARM平台下JDK、Python、数据库这三个东西的选型可能是整个项目里最容易出乱子的部分。多台机器之间版本一旦不一致后续安装Hadoop组件会有各种稀奇古怪的报错。我整理了一张适配对照表你可以直接抄作业组件x86_64常规选择ARM适配建议备注JDKOracle JDK 8 x64开源OpenJDK 8的aarch64构建版Ambari 2.7.5对JDK8兼容性最好不要一上来就上JDK11Python系统自带Python 2.7保留Python 2.7作为默认pythonAmbari的agent脚本依赖2.7语法默认Python改成3会直接报错MariaDB/MySQLMySQL 5.7 x86_64选择支持aarch64的MariaDB 10.2或MySQL 5.7对应构建数据库用于存Ambari Server的元数据初始化SQL必须执行成功Hadoop native库x86_64预编译使用Apache Hadoop源码编译的aarch64版本libhadoop.so必须对应ARM指令集否则启动时告警甚至失败这里要特别提醒一句JDK的坑尤其隐蔽。官方文档要求你设置JAVA_HOME指向JDK安装目录很多人在x86平台上习惯从Oracle官网下载但ARM平台的官网包里几乎没有直接可用的x86版。正确做法是找一个适配aarch64的OpenJDK构建版本装完之后检查java -version的输出里是否带aarch64字样再设置环境变量。我遇到过一次性装了三个JDK、最后忘记修改JAVA_HOME导致Ambari Server起不来的情况那个排查过程真的非常痛苦。数据库的坑也值得一提。Ambari Server初始化元数据库的时候需要创建很多表和索引如果你选的数据库源不对部分初始化SQL会在创建索引或字符集阶段失败。最好提前确认你的数据库安装包是ARM平台原生包而不是通过某种兼容层跑起来的。另外初始化前先手动建好库和用户并授予足够的权限后面能省很多事。2.3 网络、时钟与SSH基础环境部署前的基础环境检查我建议按照下面这个顺序逐项确认一条都不要漏。第一时间同步。Ambari在安装和监控阶段对集群内各节点的时间差非常敏感。如果时间差距过大HDFS的NameNode和DataNode之间通信会出现各种鉴权和租约异常。建议用chronyd或ntpd统一指向一台内网时间服务器确保所有节点时间一致。第二主机名解析。所有节点都必须通过/etc/hosts或内网DNS正确解析到其他节点的主机名而且主机名最好全部使用全小写字母和点分隔格式不要出现下划线或中文。第三SSH免密。Ambari在集群创建向导中需要通过SSH登录到你填写的主机如果免密没有配好向导会卡在主机注册阶段。我习惯在所有节点上统一添加类似下面的hosts记录并且在管理机上生成SSH密钥把公钥分发到所有节点10.10.10.10 ambari-server 10.10.10.11>grep -r x86_64 --include*.xml --include*.properties . | head -50常见的修改思路是在定义os.detection.classifier或类似架构属性的地方补齐linux-aarch64的classifier在rpm打包插件配置文件里增加ARM平台对应的profile。这个改动没有统一的公式每家版本细节略有差异但核心目标是让Maven在打包时认为自己是在为ARM平台构建产物。修改完源码后执行Maven构建命令。注意要跳过测试和源码检查因为Ambari的源码检查会对文件版权头、代码格式做严格校验你改动过的文件很可能过不了检查mvn -B -DskipTests -DskipPythonSDKInstall -Drat.skiptrue clean package这个命令执行时长取决于你的机器性能一般需要40分钟到1小时。如果只编译server和agent两个模块也可以指定模块以节省时间mvn -B -DskipTests -DskipPythonSDKInstall -Drat.skiptrue -am -pl ambari-server,ambari-agent clean package构建完成后在ambari-server/target/rpm和ambari-agent/target/rpm目录下就能看到生成的RPM包。提醒一句构建过程中如果node-sass下载超时或者npm安装依赖失败网络慢的问题可以靠配置国内npm镜像来解决但改了镜像之后要记得重建一次前端资源避免打包出半成品。3.2 搭建本地YUM源拿到RPM包只能算完成第一步接下来必须把这些包放进一个yum仓库里否则你在ARM服务器上执行yum install ambari-server时因为仓库里找不到其他依赖项安装会非常容易中断。搭建本地yum源听上去很简单但它在整个方案里的位置非常关键。我建议把“本地源”这件事做成永久基础设施而不只是临时应付一下。因为Ambari在安装集群组件时还会去仓库里拉取很多额外依赖把这些东西全部提前放在本地内网能极大降低后续各种安装失败的几率。先安装httpd作为仓库的承载服务再安装createrepo工具yum install -y httpd createrepo systemctl start httpd systemctl enable httpd然后把编译产物和相关依赖包拷贝到web服务的工作目录mkdir -p /var/www/html/ambari cp ambari-server/target/rpm/*.rpm /var/www/html/ambari/ cp ambari-agent/target/rpm/*.rpm /var/www/html/ambari/ createrepo /var/www/html/ambari接着在所有ARM服务器上配置repo文件。这一步建议用内网IP而不要用公网域名避免DNS解析问题cat /etc/yum.repos.d/ambari.repo EOF [ambari] nameAmbari ARM baseurlhttp://10.10.10.10/ambari gpgcheck0 EOF yum clean all yum repolist如果yum repolist能看到ambari仓库说明本地源已经可用。这里还有一个容易被忽略的细节就是本地源默认gpgcheck0可以省去签名验证但如果你们的内部安全规范要求签名则需要在createrepo生成仓库信息后额外用gpg key对RPM包做签名否则安装时会被拒绝。3.3 部署Ambari Server与Agent仓库配好后Ambari Server和Agent的安装就相对顺理成章了。先在管理节点上执行yum install -y ambari-server然后进入经典的配置阶段执行ambari-server setup它会以一问一答的方式引导你完成配置。关键步骤我列在下面自定义Java环境选择手动输入JAVA_HOME一般填/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.xxx务必确认该目录下存在bin/java。选择数据库类型选MySQL/MariaDB然后填写数据库主机、端口、库名、用户名、密码。配置共享资源和JDK许可按默认即可。保存配置后再执行ambari-server setup --jdbc-dbmysql --jdbc-driver/usr/share/java/mysql-connector-java.jar来注册JDBC驱动。数据库这一环在setup之前就应该准备好。我习惯单独在数据库节点执行下面的SQLCREATE DATABASE ambari CHARACTER SET utf8; CREATE USER ambari% IDENTIFIED BY your_password; GRANT ALL PRIVILEGES ON ambari.* TO ambari%; FLUSH PRIVILEGES;然后在管理节点启动服务ambari-server start启动后立刻检查端口和接口curl -u admin:admin http://localhost:8080/api/v1/clusters如果返回了JSON说明Server端已经正常。此时再在所有数据节点上安装并启动Agentyum install -y ambari-agentAgent的配置文件是/etc/ambari-agent/conf/ambari-agent.ini关键是把hostnamelocalhost改成管理节点的实际主机名或IP[server] hostnameambari-server改完后启动并观察日志ambari-agent start tail -f /var/log/ambari-agent/ambari-agent.log日志里出现“Connected to Ambari Server”字样说明Agent反向注册成功。3.4 在Web界面创建集群与组件分配Agent全部注册完毕后就可以打开浏览器访问http://10.10.10.10:8080。默认账号是admin/admin。登录进去你会看到Ambari的引导向导它要求你指定集群名称、版本来源、主机清单和SSH凭据。版本来源这一块是全程风险最集中的环节。Ambari 2.7.5默认推荐的是HDP发行版的仓库但那个仓库的架构标记是x86_64在ARM环境直接使用会失败。我的做法是先去获取对应的HDP的VDF文件版本定义文件把它下载下来把文件里的x86_64字符串全部替换成aarch64然后把所有需要用的ARM平台RPM包放进本地yum源最后在Ambari的“Manage Versions”里注册这个本地VDF。具体操作可以这样curl -SL -O http://your-local-mirror/HDP-3.1.5.0-152-vdf.xml sed -i s/x86_64/aarch64/g HDP-3.1.5.0-152-vdf.xml然后把这个修改后的VDF文件路径填进去仓库地址填http://10.10.10.10/ambari。如果你不需要完整的HDP发行版只希望用Ambari纳管一套自己编译的Apache Hadoop集群那么可以在向导里选择“自定义仓库”并把组件的安装命令指向你事先准备好的本地源。主机分配阶段Ambari会列出所有已经注册或可以SSH登录的主机。你需要手动指定每台机器上运行哪些主组件比如NameNode和ResourceManager最好放在管理节点DataNode和NodeManager分散到数据节点Zookeeper尽量部署奇数台。分配完组件后Ambari会开始逐个安装和启动服务这个过程里你会在界面上看到大量的状态刷新等着它跑完即可。这一步最容易出问题的地方是Ambari在启动HDFS时会对native库做初始化检查。如果你没有提前把ARM版的libhadoop.so放置到对应路径或者JAVA_HOME里的库路径不对NameNode进程经常会启动失败。我建议在向导开始安装之前先在所有数据节点上把Hadoop native库准备好方式可以是编译安装或直接解压预编译的aarch64版本让hadoop checknative命令能够正常输出openssl: true这样的结果。4. 高频故障排查与避坑实录4.1 安装过程中最常见的三类依赖报错在ARM平台上跑Ambari每个环节都可能翻车。我整理了一份高频故障速查表都是实际部署中踩过的坑你可以对照着排查故障现象典型原因解决思路yum安装ambari-server时提示架构不匹配仓库里存在x86_64的残留包清理repo缓存只保留本地aarch64 RPM包依赖检查提示glibc 2.17但不满足操作系统的glibc版本低于Ambari要求升级系统到兼容RHEL 7.9的最低标准或者补充本地base源ambari-agent start后进程立即退出Python默认版本冲突脚本用python2但系统指向python3检查/usr/bin/python链接确保环境里存在Python 2.7Ambari Server启动报数据库连接失败数据库初始化不完全或JDBC驱动未注册重跑初始化SQL执行ambari-server setup --jdbc-dbmysql主机注册时提示SSH失败免密配置不完整或使用非root账号重新分发SSH公钥确认Ambari对目标主机的登录权限HDFS启动时提示找不到native库Hadoop的本地库不是ARM版本编译或替换ARM版libhadoop.so并检查JAVA_LIBRARY_PATH4.2 “网络与主机名”导致的Agent注册失败我遇到的第一个硬骨头就是Agent注册失败。现象是Agent日志里反复出现“ERROR: Error connecting to Ambari Server”同时管理节点上看不到任何新的主机注册消息。排查路径分三步。第一步确认Agent所在节点能ping通管理节点并确认管理节点8080端口可访问。第二步确认/etc/hosts中主机名与Agent配置的hostname字段完全匹配大小写和省略域名都可能导致Ambari无法匹配到主机的唯一标识。第三步查看管理节点的/var/log/ambari-server/ambari-server.log看是否有“Unknown host”或“Connection refused”之类的记录。这里给一个独家心得Ambari会记录Agent上报的“机器标识”通常基于主机名生成。如果你在安装Ambari之后再修改主机名会导致旧的注册信息残留。我遇到过一次把所有主机名统一改成了小写格式结果Agent全部变成了“不健康”状态。最后只能逐个卸载Agent、清理/var/run/ambari-agent下的缓存文件再重新注册非常浪费时间。所以主机名方案一定要在部署前定死。4.3 数据库初始化SQL失败Ambari Server安装过程中它会往元数据库里灌入大量初始化SQL。在ARM平台的数据库上这些初始化脚本可能会在字符集或索引长度上失败。最典型的报错是“Specified key was too long; max key length is 767 bytes”。这个问题通常是MySQL/MariaDB的字符集配置和Ambari初始化SQL不一致导致的x86平台也存在但在ARM上更容易遇到因为很多人选择的数据库安装包来自不同源默认字符集不是utf8mb4。解决方法是把数据库默认字符集调整成utf8或者适当缩小某些表索引字段的长度。具体可以在数据库配置文件的[mysqld]段中加入character-set-serverutf8 collation-serverutf8_general_ci innodb_large_prefixON修改后重启数据库删除Ambari的初始化数据库重新执行初始化流程。切记不要在原库上反复重试初始化SQL因为Ambari会认为表已存在导致后续步骤直接跳过失败。4.4 Hadoop组件启动失败native库与JVM参数集群向导安装HDFS时NameNode启动阶段失败是最常见的问题尤其是在没有提前准备ARM本地库的情况下。当你打开NameNode日志往往能看到类似“Unable to load native-hadoop library for your platform”的告警或者“java.lang.UnsatisfiedLinkError”错误。这个问题的本质是Hadoop在启动HDFS时需要通过JNI调用本地的压缩、校验等能力如果加载不到与当前架构匹配的.so文件某些功能会退化严重时进程直接退避。解决方案是提前编译好ARM版本地库并把它们放到$HADOOP_HOME/lib/native目录下。编译命令大致是在Hadoop源码目录里执行mvn package -Pdist,native -DskipTests -Dtar编译产物中有一个libhadoop.so以及libsnappy.so等辅助库。把整个native目录替换到集群组件对应位置后再通过hadoop checknative确认输出中所有项都显示为true。除此之外Ambari里每个组件都有自己的JVM堆大小默认参数。ARM服务器通常内存较大但Ambari默认值往往给的比较保守比如HDFS NameNode默认堆只有1GBHBase Master可能只有256MB。数据量大的时候你会发现界面里服务频繁重启或内存持续高位。建议根据实际内存提前调整/etc/ambari-server/conf/ambari.properties里的服务堆参数或者在Ambari Web界面的“Configs”里逐个修改关键组件的堆大小。4.5 Ambari Metrics监控组件吃内存Ambari自带一套叫Ambari Metrics System的监控栈里面包含Metrics Collector和HBase的简版实现。这个组件能展示集群CPU、内存、磁盘等指标曲线但对资源的要求也不低尤其是ARM平台下默认堆大小经常不够。如果你的集群节点数不多我甚至建议先不安装Ambari Metrics或者只部署一个Collector到管理节点不要在每个数据节点都展开。否则你会发现三个节点的测试集群光监控组件就可能吃掉2到4GB内存。如果确实需要监控曲线记得把Metrics Collector的堆大小从默认值改到至少1GB以上否则页面会加载不出图表并且日志里频繁出现GC停顿记录。5. 这个项目值得注意的几个“隐藏成本”写到最后想再分享几个泛化经验。ARM平台搭Ambari这件事技术上最大的成本其实不是安装本身而是“版本对齐”。你需要维护一份自己的版本矩阵把操作系统版本、JDK版本、Python版本、数据库版本、Ambari版本、Hadoop版本以及对应的native库版本全部记录清楚并且保证每个节点的组合完全一致。只要有一台机器跟别人不一样故障排查的复杂度就会成倍上升。另外本地yum源一定要做好并且要随着部署过程持续补充依赖包。Ambari安装集群组件时会对很多底层库有隐式依赖比如snappy压缩库、lzo库、zstd库这些库在ARM平台的系统源里可能没有一旦缺失某些组件就算安装成功启动后也会在压缩编码功能上报错。把这些依赖提前下载到本地源从源头减少在线拉取是效率最高的方式。还有一个经验是永远先做最小化验证。我第一次实施这个方案时直接在三台机器上并行安装结果因为数据库字符集问题三台机器全部在半路卡死最后只能一台一台重新初始化。正确的做法是先部署一台管理节点加一台数据节点把Ambari Server、Agent、HDFS、YARN全部跑通确认整条链路没有暗坑之后再铺开其他数据节点。如果你已经决定要在ARM平台落地Ambari我建议你把这个项目当成一次“平台适配工程”来管理而不是简单地“安装一个软件”。整个过程中你会不断接触到底层架构、依赖管理、native代码编译这些更底层的内容虽然过程痛苦但做完之后你对Hadoop生态的依赖关系理解会明显提升一个层次。对我个人来说这次折腾最值的部分就是被迫把以前在x86平台上从来不会去翻的源码细节都翻了一遍这种收益比单纯跑起来一个集群要大得多。
阅读完成 · 觉得有帮助？
