1. 為什么在離線環(huán)境里死磕本地源搭建 CDH 6.3.0大數(shù)據(jù)平臺搭建這件事在線環(huán)境和離線環(huán)境完全是兩個世界。在線環(huán)境下你敲一條yum install或者apt-get install系統(tǒng)自己去倉庫拉包順暢得像點外賣。但一旦進(jìn)了內(nèi)網(wǎng)、機房隔離區(qū)或者客戶現(xiàn)場那種連外網(wǎng)出口都沒有的環(huán)境事情就完全變了——所有依賴包、所有 RPM、所有 Parcel 文件都得你自己提前準(zhǔn)備好一個都不能少。CDH 6.3.0 這個版本在大數(shù)據(jù)圈子里地位比較特殊。它是 Cloudera 和 Hortonworks 合并之后推出的一個相對成熟的發(fā)行版集成了 Hadoop 3.0、Hive 2.1、Spark 2.4、HBase 2.1、Impala 3.2 等一大批組件版本兼容性經(jīng)過官方充分測試。很多企業(yè)內(nèi)部的存量集群至今還跑在這個版本上新項目做 POC 或者擴容的時候也經(jīng)常需要復(fù)現(xiàn)一套一模一樣的 6.3.0 環(huán)境。問題在于Cloudera 后來把免費版的下載入口收得很緊很多包已經(jīng)不那么容易從公開渠道拿到了這就逼著我們必須把本地源這套流程徹底吃透。所謂本地源說白了就是在內(nèi)網(wǎng)自己搭一個 YUM 倉庫和一個 Parcel 倉庫讓 Cloudera Manager后面簡稱 CM和集群里的每一臺機器都從這個內(nèi)網(wǎng)倉庫拉包而不是去訪問外網(wǎng)。這件事聽起來簡單但真正動手的時候坑一個接一個RPM 依賴缺失、Parcel 校驗失敗、CM 的 Agent 找不到倉庫地址、cloudera-scm-server 起不來、數(shù)據(jù)庫初始化報錯……每一個都能讓你卡上半天。這篇文章適合誰看如果你手頭有一批內(nèi)網(wǎng)機器需要從零搭一套 CDH 6.3.0或者你之前用在線方式裝過、現(xiàn)在要遷移到離線環(huán)境那這篇內(nèi)容基本能覆蓋你 90% 的場景。我會把整個流程拆成準(zhǔn)備工作、搭 YUM 源、搭 Parcel 源、裝 CM、分發(fā) Parcel、初始化集群這幾大塊每一塊都講清楚為什么這么做、參數(shù)怎么算、哪里容易翻車。全程基于我實際在幾套內(nèi)網(wǎng)環(huán)境里反復(fù)搭過的經(jīng)驗不是照抄官方文檔。先說一個總的原則離線搭建的核心矛盾是依賴完整性和版本一致性。你準(zhǔn)備的每一個 RPM、每一個 Parcel版本號必須和 CM 期望的完全對得上差一個小版本都可能讓整個流程卡死。所以后面所有步驟我都會強調(diào)先確認(rèn)版本再動手。2. 動手之前必須鎖死的版本清單與機器規(guī)劃2.1 組件版本對應(yīng)關(guān)系錯一個都不行CDH 6.3.0 不是一個孤立的版本號它背后有一整套配套的組件版本矩陣。你在準(zhǔn)備安裝包的時候必須把下面這幾樣?xùn)|西的版本全部對齊組件版本說明Cloudera Manager6.3.0管理端版本必須和 CDH 大版本一致CDH Parcel6.3.0-1.cdh6.3.0.p0.1279813Parcel 的完整版本號后面那串 build 號很關(guān)鍵JDK1.8.0_181 及以上CDH 6.3 官方推薦 Oracle JDK 8OpenJDK 也能跑但要注意操作系統(tǒng)CentOS 7.6 / RHEL 7.67.x 系列都行但 7.6 最穩(wěn)數(shù)據(jù)庫MySQL 5.7 / PostgreSQL 9.6存 CM 的元數(shù)據(jù)MySQL 用得最多Python2.7.xCM Agent 依賴 Python 2別裝 Python 3 覆蓋系統(tǒng)默認(rèn)這里重點說 Parcel 的版本號。很多人從別處拷來一個 Parcel 文件文件名是CDH-6.3.0-1.cdh6.3.0.p0.1279813-el7.parcel但 CM 界面上期望的可能是另一個 build 號。一旦對不上CM 就會一直顯示正在下載或者直接報校驗失敗。正確的做法是先裝好 CM進(jìn)到 CM 界面看它到底期望哪個版本的 Parcel然后按那個版本號去準(zhǔn)備文件?；蛘叻催^來你手頭有什么版本的 Parcel就去找對應(yīng)版本的 CM 安裝包。兩者必須成對出現(xiàn)。2.2 機器角色劃分與資源估算一套最小可用的 CDH 6.3.0 集群至少需要三臺機器。我一般這樣規(guī)劃管理節(jié)點1 臺跑 cloudera-scm-server、MySQL、本地 YUM 源、本地 Parcel 源。這臺機器是核心內(nèi)存建議 16GB 起步因為 CM Server 本身吃內(nèi)存加上 MySQL 和 HTTP 服務(wù)8GB 會很緊張。數(shù)據(jù)/計算節(jié)點2 臺起跑 cloudera-scm-agent 和各個大數(shù)據(jù)組件。每臺至少 16GB 內(nèi)存、4 核 CPU、100GB 磁盤。如果要跑 Spark 或者 Impala內(nèi)存往 32GB 以上走。磁盤規(guī)劃上有個經(jīng)驗Parcel 解壓后的體積大約是壓縮包的兩倍多。CDH 6.3.0 的 Parcel 包大概 2GB 左右解壓后接近 5GB。再加上各個組件的日志、數(shù)據(jù)目錄/opt和/var這兩個分區(qū)一定要留足空間。我見過有人/opt只給了 10GB結(jié)果 Parcel 分發(fā)到一半就滿了排查半天才發(fā)現(xiàn)是分區(qū)不夠。網(wǎng)絡(luò)方面所有機器必須在同一內(nèi)網(wǎng)段主機名要能互相解析。強烈建議提前把/etc/hosts寫好不要依賴 DNS因為內(nèi)網(wǎng) DNS 經(jīng)常不穩(wěn)定CM 對主機名解析非常敏感。每臺機器的主機名要用 FQDN 格式比如node1.bigdata.local不要用簡單的node1否則后面 CM 添加主機的時候會各種報錯。2.3 系統(tǒng)層面的預(yù)處理別跳過在正式裝任何東西之前這幾件事必須做完否則后面一定會出問題關(guān)閉防火墻和 SELinux。內(nèi)網(wǎng)環(huán)境雖然相對安全但 CM 組件之間通信端口非常多一個個開防火墻規(guī)則太累直接關(guān)掉最省事。SELinux 必須設(shè)成 disabled否則 Parcel 解壓和文件權(quán)限會出各種詭異問題。配置時間同步。集群里所有機器時間必須一致差幾秒鐘都可能讓 Kerberos如果后面要開或者 CM 的心跳檢測出問題。內(nèi)網(wǎng)沒有 NTP 服務(wù)器的話就選一臺機器做時間源其他機器跟它同步。調(diào)大文件句柄數(shù)和進(jìn)程數(shù)。大數(shù)據(jù)組件對這兩個參數(shù)很敏感默認(rèn)的 1024 根本不夠。在/etc/security/limits.conf里把nofile和nproc都調(diào)到 65536。關(guān)閉透明大頁THP。這個對 Hadoop 性能影響很大雖然不影響安裝但裝完跑起來會明顯感覺慢。在啟動參數(shù)里加上transparent_hugepagenever。這些預(yù)處理看起來瑣碎但每一條都是踩過坑之后總結(jié)出來的。尤其是 SELinux我遇到過好幾次 Parcel 分發(fā)失敗最后查出來就是 SELinux 在攔。3. 搭建本地 YUM 源讓 CM 安裝包有處可尋3.1 準(zhǔn)備 CM 的 RPM 包CM 的安裝包主要分兩類cloudera-manager-server相關(guān)的一堆 RPM以及cloudera-manager-agent相關(guān)的一堆 RPM。這些包在 Cloudera 的官方倉庫里是以 RPM 形式提供的你需要提前下載好。下載的時候有個技巧不要只下載 server 和 agent 這兩個主包要把它們依賴的所有包一起下下來。因為離線環(huán)境里沒有外網(wǎng)缺一個依賴就裝不上。最穩(wěn)妥的辦法是找一臺能聯(lián)網(wǎng)的、和目標(biāo)機器操作系統(tǒng)版本完全一致的機器用yumdownloader把依賴樹整個拉下來# 在聯(lián)網(wǎng)機器上執(zhí)行把 CM 6.3.0 相關(guān)的包和依賴全部下載到本地目錄 mkdir -p /tmp/cm_rpms cd /tmp/cm_rpms yumdownloader --resolve --destdir/tmp/cm_rpms cloudera-manager-server cloudera-manager-daemons cloudera-manager-agent--resolve這個參數(shù)是關(guān)鍵它會把所有依賴包一并下載。下載完之后你會得到一堆 RPM 文件把它們?nèi)靠降絻?nèi)網(wǎng)的管理節(jié)點上。注意聯(lián)網(wǎng)機器和目標(biāo)機器的操作系統(tǒng)版本、架構(gòu)必須完全一致都是 CentOS 7.6 x86_64。如果一個是 7.6 一個是 7.9依賴版本可能對不上裝的時候會報沖突。3.2 用 createrepo 生成倉庫元數(shù)據(jù)RPM 包準(zhǔn)備好之后它們還只是一堆散落的文件YUM 不認(rèn)識。你需要用createrepo工具把它們變成一個標(biāo)準(zhǔn)的 YUM 倉庫。先把所有 RPM 放到一個目錄里比如/var/www/html/cm6/然后執(zhí)行# 安裝 createrepo 工具如果管理節(jié)點本身能裝的話或者從別處拷 rpm 過來裝 yum install -y createrepo # 生成倉庫元數(shù)據(jù) createrepo /var/www/html/cm6/執(zhí)行完之后目錄里會多出一個repodata文件夾里面是 YUM 需要的索引文件。這時候這個目錄就已經(jīng)是一個可用的本地倉庫了。接下來要讓其他機器能訪問這個倉庫。最簡單的方式是用 HTTP 服務(wù)。管理節(jié)點上裝個 httpd或者 nginx把/var/www/html作為網(wǎng)站根目錄yum install -y httpd systemctl start httpd systemctl enable httpd然后在每一臺集群機器上配置 YUM 源指向這個地址。在/etc/yum.repos.d/下新建一個cm6.repo文件[cm6] nameCloudera Manager 6.3.0 baseurlhttp://node1.bigdata.local/cm6/ enabled1 gpgcheck0gpgcheck0是關(guān)掉 GPG 校驗內(nèi)網(wǎng)環(huán)境自己做的包沒有官方簽名關(guān)掉最省事。配好之后執(zhí)行yum clean all yum repolist如果能看到cm6這個倉庫說明源配好了。3.3 一個容易忽略的細(xì)節(jié)倉庫路徑和權(quán)限這里有個坑我踩過httpd 默認(rèn)以apache用戶運行如果/var/www/html/cm6/目錄的權(quán)限不對其他機器訪問的時候會返回 403。解決辦法是確保目錄對所有人可讀chmod -R 755 /var/www/html/cm6/另外createrepo生成的repodata目錄里如果有中文文件名或者特殊字符也可能導(dǎo)致解析失敗。所以 RPM 包的文件名盡量保持原始英文名不要手動改名。還有一點如果你后面要加新的 RPM 包到這個倉庫記得每次加完都要重新執(zhí)行一次createrepo /var/www/html/cm6/否則新包不會被索引到。這個操作叫更新倉庫元數(shù)據(jù)很多人加了包忘了更新然后納悶為什么yum install找不到。4. 搭建本地 Parcel 源CDH 組件分發(fā)的命脈4.1 Parcel 到底是什么為什么不能用 RPM 裝 CDH很多人第一次接觸 CDH 會疑惑既然 CM 是 RPM 裝的為什么 CDH 的組件Hadoop、Hive 這些不用 RPM而要用 Parcel原因在于 CDH 的組件太多了而且版本組合非常靈活。如果用 RPM 裝每個組件都要維護(hù)一套 RPM 依賴關(guān)系升級和回滾會變得極其復(fù)雜。Parcel 本質(zhì)上是一個自包含的壓縮包里面包含了某個組件在特定操作系統(tǒng)上的所有二進(jìn)制文件和配置模板。CM 把 Parcel 分發(fā)到各個節(jié)點解壓到指定目錄然后通過軟鏈接的方式激活對應(yīng)版本。這樣升級的時候只需要換一個 Parcel回滾也只需要切回舊版本非常干凈。所以離線搭建 CDHParcel 源是繞不開的。你需要準(zhǔn)備三個文件CDH-6.3.0-1.cdh6.3.0.p0.1279813-el7.parcel主 Parcel 包大約 2GBCDH-6.3.0-1.cdh6.3.0.p0.1279813-el7.parcel.sha1SHA1 校驗文件manifest.json描述所有可用 Parcel 的清單文件這三個文件缺一不可。.sha1文件用于校驗 Parcel 完整性manifest.json告訴 CM 有哪些 Parcel 可用。4.2 生成 manifest.json 的正確姿勢manifest.json這個文件是最容易出問題的。它不是一個隨便寫的 JSON而是有固定格式的CM 會解析它來獲取 Parcel 的元信息。如果你從官方渠道拿到了原始的manifest.json那最好直接用。但很多時候你只有 Parcel 文件沒有 manifest這時候就需要自己生成。格式大概是這樣{ lastUpdated: 1600000000000, parcels: [ { parcelName: CDH-6.3.0-1.cdh6.3.0.p0.1279813-el7.parcel, components: [ { name: cdh, version: 6.3.0, pkg_version: 6.3.0 } ], hash: 生成的sha1值, parcelSize: 文件字節(jié)數(shù) } ] }hash字段就是.sha1文件里的內(nèi)容parcelSize是 Parcel 文件的字節(jié)大小。這兩個值必須準(zhǔn)確否則 CM 會認(rèn)為文件損壞。生成.sha1文件很簡單sha1sum CDH-6.3.0-1.cdh6.3.0.p0.1279813-el7.parcel | awk {print $1} CDH-6.3.0-1.cdh6.3.0.p0.1279813-el7.parcel.sha1注意.sha1文件里只放哈希值不要帶文件名。有些教程說要把sha1sum的完整輸出寫進(jìn)去那是錯的CM 只讀第一段哈希值帶了文件名反而可能解析失敗。4.3 配置 HTTP 服務(wù)暴露 Parcel 目錄Parcel 文件準(zhǔn)備好之后同樣要通過 HTTP 暴露出去。在管理節(jié)點上建一個目錄比如/var/www/html/cdh6/把三個文件放進(jìn)去然后確保 httpd 能訪問到。CM 默認(rèn)會去http://server/cdh/這個路徑找 Parcel。你可以在 CM 的配置里改這個路徑但最省事的做法就是按默認(rèn)路徑來。具體來說CM 期望的 Parcel 倉庫地址格式是http://node1.bigdata.local/cdh6/然后在 CM 界面里進(jìn)入主機 - Parcel點擊配置按鈕把遠(yuǎn)程 Parcel 存儲庫 URL改成上面這個地址。改完之后 CM 會去這個地址拉manifest.json解析出可用的 Parcel 列表。提示如果你改了 Parcel 倉庫地址記得把原來的官方地址刪掉否則 CM 會同時去兩個地方找可能造成混亂。4.4 Parcel 分發(fā)的底層邏輯與常見失敗原因CM 分發(fā) Parcel 的過程是這樣的CM Server 從倉庫下載 Parcel 到本地然后通過 Agent 把 Parcel 推送到各個節(jié)點的/opt/cloudera/parcel-cache/目錄解壓到/opt/cloudera/parcels/最后創(chuàng)建軟鏈接。這個過程中最常見的失敗原因有三個磁盤空間不足。前面說過Parcel 解壓后體積翻倍/opt分區(qū)一定要夠大。SHA1 校驗失敗。說明 Parcel 文件在傳輸過程中損壞了或者.sha1文件內(nèi)容不對。重新下載或者重新生成校驗文件。Agent 無法連接 Server。檢查 Agent 的配置文件/etc/cloudera-scm-agent/config.ini里的server_host是否指向正確的管理節(jié)點。排查的時候Agent 的日志在/var/log/cloudera-scm-agent/cloudera-scm-agent.logServer 的日志在/var/log/cloudera-scm-server/cloudera-scm-server.log。這兩個日志是定位問題的關(guān)鍵遇到報錯先看日志不要瞎猜。5. 安裝 Cloudera Manager Server 與 Agent 的實操鏈路5.1 安裝 CM Server 并初始化數(shù)據(jù)庫YUM 源配好之后在管理節(jié)點上裝 CM Serveryum install -y cloudera-manager-daemons cloudera-manager-server裝完之后先別急著啟動CM Server 需要一個數(shù)據(jù)庫來存元數(shù)據(jù)。以 MySQL 為例先建庫建用戶CREATE DATABASE scm DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; GRANT ALL ON scm.* TO scm% IDENTIFIED BY YourPassword123; FLUSH PRIVILEGES;然后運行 CM 自帶的數(shù)據(jù)庫初始化腳本/opt/cloudera/cm/schema/scm_prepare_database.sh mysql scm scm YourPassword123這個腳本會往scm庫里建表。執(zhí)行成功的話會輸出All done, your SCM database is configured correctly!。如果報錯大概率是數(shù)據(jù)庫連接信息不對或者 MySQL 的 JDBC 驅(qū)動沒放對位置。驅(qū)動文件要放在/usr/share/java/mysql-connector-java.jarCM 默認(rèn)去這個路徑找。數(shù)據(jù)庫初始化完成之后啟動 CM Serversystemctl start cloudera-scm-server啟動過程比較慢第一次啟動要建表、初始化大概需要一兩分鐘。用tail -f /var/log/cloudera-scm-server/cloudera-scm-server.log盯著日志看到Started Jetty server就說明起來了。然后瀏覽器訪問http://node1.bigdata.local:7180默認(rèn)賬號密碼都是admin。5.2 Agent 安裝與主機納管CM Server 起來之后接下來要把其他節(jié)點納管進(jìn)來。在每臺數(shù)據(jù)/計算節(jié)點上裝 Agentyum install -y cloudera-manager-daemons cloudera-manager-agent然后修改 Agent 配置把server_host指向管理節(jié)點# /etc/cloudera-scm-agent/config.ini server_hostnode1.bigdata.local啟動 Agentsystemctl start cloudera-scm-agent回到 CM 界面進(jìn)入主機 - 添加主機輸入要納管的機器主機名CM 會通過 SSH 去這些機器上做檢查。這里有個前提管理節(jié)點必須能免密 SSH 到其他節(jié)點。提前配好 SSH 免密登錄否則添加主機會失敗。添加主機的過程中CM 會檢查一堆東西JDK 版本、Python 版本、磁盤空間、時間同步、SELinux 狀態(tài)等等。任何一項不通過都會卡住。所以前面第 2 章說的預(yù)處理這時候就體現(xiàn)出價值了。5.3 一個高頻報錯Agent 心跳丟失Agent 裝好啟動之后CM 界面上有時候會顯示主機狀態(tài)不良或者心跳丟失。這個問題我遇到過很多次原因通常有這幾個主機名解析問題。Agent 上報的主機名和 CM 里配置的不一致。檢查/etc/hosts和hostname命令的輸出是否匹配。端口不通。Agent 和 Server 之間通過 7182 端口通信檢查防火墻是否關(guān)了。Agent 進(jìn)程沒起來。看/var/log/cloudera-scm-agent/cloudera-scm-agent.log常見的是 Python 版本問題或者配置文件語法錯誤。排查這類問題的順序是先看 Agent 進(jìn)程在不在再看日志有沒有報錯最后檢查網(wǎng)絡(luò)連通性。不要一上來就重啟重啟解決不了根本問題。6. 集群初始化與 Parcel 激活的完整流程6.1 在 CM 界面完成 Parcel 分發(fā)與激活主機納管完成之后進(jìn)入 CM 的Parcel頁面。如果前面的 Parcel 源配好了這里應(yīng)該能看到CDH 6.3.0這個 Parcel狀態(tài)是已下載或者可下載。點擊下載CM 會從你配置的本地源拉取 Parcel。下載完成后點擊分發(fā)CM 會把 Parcel 推送到所有 Agent 節(jié)點。分發(fā)完成后點擊激活CM 會在所有節(jié)點上解壓 Parcel 并創(chuàng)建軟鏈接。這三個步驟下載、分發(fā)、激活是串行的每一步都要等所有節(jié)點完成才能進(jìn)行下一步。如果某個節(jié)點卡住了先看那個節(jié)點的 Agent 日志。激活成功后/opt/cloudera/parcels/目錄下會出現(xiàn)CDH-6.3.0-1.cdh6.3.0.p0.1279813這個目錄同時會有一個CDH軟鏈接指向它。這個軟鏈接很重要后面所有組件都通過它來引用 Parcel 路徑。6.2 集群安裝向?qū)Ю锏年P(guān)鍵選擇Parcel 激活之后就可以進(jìn)入集群安裝向?qū)Я?。CM 會引導(dǎo)你一步步選擇要安裝的組件、分配角色、配置參數(shù)。這里有幾個關(guān)鍵選擇需要說明集群名稱隨便起但建議用有意義的名稱比如prod-cluster或者test-cluster。組件選擇根據(jù)你的需求勾選。最小化安裝一般選 Core HadoopHDFS YARN ZooKeeper如果要跑 SQL 就加 Hive要跑 Spark 就加 Spark。角色分配CM 會自動推薦角色分配方案但小集群里建議手動調(diào)整把 NameNode 和 ResourceManager 放在內(nèi)存大的機器上。數(shù)據(jù)庫配置Hive、Oozie 這些組件需要自己的數(shù)據(jù)庫提前在 MySQL 里建好庫和用戶在向?qū)Ю锾钸M(jìn)去。向?qū)ё咄曛驝M 會自動啟動所有服務(wù)。第一次啟動會比較慢因為要格式化 HDFS、初始化各種元數(shù)據(jù)。全部服務(wù)變成綠色狀態(tài)就說明集群搭好了。6.3 驗證集群可用性的幾個必做檢查集群起來之后不要急著交付先做幾個基本檢查HDFS 健康檢查。在 CM 界面看 HDFS 服務(wù)狀態(tài)有沒有塊丟失、副本不足的告警。也可以手動跑一個hdfs dfsadmin -report看 DataNode 是否都注冊上了。YARN 資源檢查。跑一個簡單的 MapReduce 或者 Spark 任務(wù)確認(rèn) YARN 能正常分配資源。Hive 連通性。用beeline連一下 HiveServer2跑個show databases看看。時間同步檢查。在所有節(jié)點上跑date確認(rèn)時間一致。這些檢查看起來簡單但能提前發(fā)現(xiàn) 80% 的配置問題。我見過太多集群裝完看著是綠的一跑任務(wù)就各種報錯最后發(fā)現(xiàn)是某個基礎(chǔ)配置沒弄對。7. 離線搭建過程中最耗時的幾個坑與排查思路7.1 Parcel 版本號不匹配導(dǎo)致的死循環(huán)這是離線搭建里最惡心的問題。現(xiàn)象是CM 界面上 Parcel 一直顯示正在下載進(jìn)度條不動或者下載完了但狀態(tài)是未激活點激活沒反應(yīng)。根本原因通常是 Parcel 的 build 號和 CM 期望的不一致。CM 內(nèi)部有一個期望的 Parcel 版本列表這個列表在 CM 的某個配置文件里。如果你提供的 Parcel 版本不在這個列表里CM 就不會認(rèn)。解決辦法有兩個一是找到 CM 期望的版本號去準(zhǔn)備對應(yīng)版本的 Parcel二是修改 CM 的配置讓它接受你手頭的版本。第二種方法比較 hack不推薦。最穩(wěn)妥的還是第一種先確認(rèn) CM 版本再找對應(yīng)的 Parcel。怎么確認(rèn) CM 期望哪個版本在 CM 界面的 Parcel 頁面把鼠標(biāo)懸停在 Parcel 名稱上或者看頁面源碼通常能看到完整的版本號。另一個辦法是看 CM Server 的日志里面會打印它去倉庫請求的 Parcel 文件名。7.2 數(shù)據(jù)庫連接池耗盡與元數(shù)據(jù)鎖CM Server 和 MySQL 之間的連接池如果配置不當(dāng)在集群規(guī)模稍大的時候會出現(xiàn)連接耗盡?，F(xiàn)象是 CM 界面操作變慢日志里報Could not get a connection。解決辦法是調(diào)大 MySQL 的max_connections同時調(diào)整 CM 的數(shù)據(jù)庫連接池配置。CM 的數(shù)據(jù)庫配置在/etc/cloudera-scm-server/db.properties里可以調(diào)整com.cloudera.cmf.db.maxActive這個參數(shù)。另一個相關(guān)的問題是元數(shù)據(jù)鎖。如果多個 CM 操作同時進(jìn)行可能會在數(shù)據(jù)庫層面產(chǎn)生鎖等待。這種情況一般等一會兒就好但如果頻繁出現(xiàn)就要考慮優(yōu)化操作節(jié)奏不要同時觸發(fā)多個重操作。7.3 Agent 端 Python 環(huán)境沖突CM Agent 是用 Python 2 寫的如果目標(biāo)機器上裝了 Python 3 并且把python命令指向了 Python 3Agent 啟動就會報語法錯誤。檢查方法python --version如果輸出是 Python 3.x就需要把python命令改回 Python 2或者修改 Agent 的啟動腳本顯式指定 Python 2 的路徑。CentOS 7 默認(rèn)自帶 Python 2.7一般不會有這個問題但如果有人手動裝過 Python 3 并改了軟鏈接就會踩這個坑。7.4 主機名大小寫與 FQDN 的坑CM 對主機名非常敏感。如果一臺機器hostname輸出是Node1但/etc/hosts里寫的是node1.bigdata.localCM 就可能認(rèn)為這是兩臺不同的機器。統(tǒng)一規(guī)范是所有機器的主機名都用小寫 FQDN/etc/hosts里也用小寫hostnamectl set-hostname設(shè)置的時候也用小寫。不要混用大小寫不要用短主機名和 FQDN 混著來。這個坑的隱蔽性在于它不會立刻報錯而是在某些特定操作比如添加主機、分發(fā) Parcel的時候才暴露出來排查起來很費時間。8. 一些讓離線搭建更順手的個人經(jīng)驗搭過幾套之后我總結(jié)出幾個能明顯提升效率的做法分享出來。第一把所有安裝包和配置文件提前整理成一個離線包。包括 CM 的 RPM、CDH 的 Parcel、MySQL 的 RPM、JDK 的 RPM以及所有配置文件的模板。這樣下次再搭的時候直接拷過去就能用不用重新找包。我一般會建一個目錄結(jié)構(gòu)offline-cdh6/ ├── rpms/ │ ├── cm6/ │ ├── mysql/ │ └── jdk/ ├── parcels/ │ ├── CDH-6.3.0-....parcel │ ├── CDH-6.3.0-....parcel.sha1 │ └── manifest.json └── configs/ ├── hosts-template ├── limits.conf └── cm6.repo第二寫一個預(yù)處理腳本。把關(guān)閉防火墻、關(guān)閉 SELinux、配置 hosts、調(diào)優(yōu)內(nèi)核參數(shù)這些操作寫成一個 shell 腳本每臺新機器上跑一遍。這樣能避免手工操作遺漏。第三Parcel 分發(fā)之前先手動驗證 SHA1。在管理節(jié)點上跑一遍sha1sum和.sha1文件對比確認(rèn)文件沒損壞再分發(fā)。這個檢查只要幾秒鐘但能省掉后面幾十分鐘的排查。第四CM 的日志級別可以臨時調(diào)高。遇到疑難問題時把 CM Server 的日志級別從 INFO 調(diào)到 DEBUG能看到更詳細(xì)的內(nèi)部流程。調(diào)完之后記得調(diào)回來否則日志會漲得很快。第五數(shù)據(jù)庫一定要提前優(yōu)化。MySQL 的innodb_buffer_pool_size建議設(shè)成物理內(nèi)存的 50% 到 70%max_connections至少 500。CM 的元數(shù)據(jù)操作比較頻繁數(shù)據(jù)庫性能直接影響 CM 的響應(yīng)速度。最后說一個心態(tài)上的經(jīng)驗離線搭建 CDH 這件事第一次做大概率會卡在某個地方這是正常的。關(guān)鍵是要養(yǎng)成看日志、查版本、驗依賴的習(xí)慣不要憑感覺瞎試。每一個報錯背后都有明確的原因找到它解決它下次就不會再踩了。