企業(yè)級項目管理系統(tǒng)的部署向來是個細致活尤其是把 Primavera P6 EPPM 這套重型應用架在 RHEL 上中間涉及的中間件、數(shù)據(jù)庫、權(quán)限、服務編排環(huán)環(huán)相扣任何一個環(huán)節(jié)沒對齊后面就是無窮無盡的排查。我前后在幾套不同規(guī)模的 RHEL 環(huán)境里落地過 P6 EPPM從單機測試到多節(jié)點集群都趟過一遍踩的坑足夠?qū)懸槐拘宰?。這篇就把整套安裝思路、關(guān)鍵參數(shù)、實操步驟和那些文檔里不會寫的經(jīng)驗一次性攤開講清楚。P6 EPPM 是工程項目管理領(lǐng)域的核心平臺負責進度計劃、資源調(diào)配、成本跟蹤和報表分析典型用戶是工程、能源、基建類企業(yè)的計劃控制團隊。它不是一個單體應用而是由數(shù)據(jù)庫、應用服務器、Web 前端、報表服務、作業(yè)服務等多個組件拼起來的分布式系統(tǒng)。把它裝到 RHEL 上本質(zhì)上是做一次企業(yè)級 Java 應用的完整部署準備操作系統(tǒng)、裝數(shù)據(jù)庫、配應用服務器、部署應用包、調(diào)通服務、驗證功能。適合誰來參考負責企業(yè)應用運維的工程師、需要獨立搭建測試環(huán)境的實施顧問以及想搞清楚這套系統(tǒng)底層結(jié)構(gòu)的技術(shù)負責人。下面按我實際操作的順序展開每一步都說明為什么這么做。1. 部署前的整體設計與方案取舍動手之前先把架構(gòu)想清楚比裝到一半推倒重來省事得多。P6 EPPM 的部署形態(tài)直接決定了后面所有配置的復雜度這一步的決策成本最高。1.1 單機部署與分布式部署怎么選P6 EPPM 官方支持多種拓撲落到實際項目里無非兩類單機全棧和分布式拆分。單機就是把數(shù)據(jù)庫、應用服務器、報表服務全塞在一臺機器上分布式則是數(shù)據(jù)庫獨立、應用服務器獨立、報表服務再獨立。我見過不少團隊一上來就追求分布式結(jié)果測試環(huán)境資源不夠各組件搶內(nèi)存反而比單機還不穩(wěn)定。選擇邏輯其實很簡單看兩個維度并發(fā)用戶數(shù)和環(huán)境用途。測試、演示、小團隊內(nèi)部使用并發(fā)在五十人以內(nèi)單機完全夠用一臺 16 核 32G 的機器就能跑得很順。生產(chǎn)環(huán)境、并發(fā)上百、有報表密集查詢需求的才需要考慮把數(shù)據(jù)庫單獨拆出去應用服務器和報表服務視負載再決定是否分離。我個人的建議是第一次部署一定從單機開始。原因很實在單機能讓你在最短時間內(nèi)把整套鏈路跑通理解各組件之間的依賴關(guān)系。等你對每個服務的啟動順序、端口占用、日志位置都心里有數(shù)了再拆分布式就是水到渠成的事。反過來一上來就搞分布式出問題時你連是哪個組件的問題都定位不了。1.2 組件構(gòu)成與依賴關(guān)系梳理把 P6 EPPM 拆開看核心組件有這么幾塊理解它們的關(guān)系是后續(xù)配置的基礎組件作用依賴數(shù)據(jù)庫存儲所有項目數(shù)據(jù)、配置、用戶信息無最底層應用服務器承載 P6 Web 應用處理業(yè)務邏輯數(shù)據(jù)庫報表服務生成各類分析報表數(shù)據(jù)庫、應用服務器作業(yè)服務執(zhí)行后臺定時任務、批量計算數(shù)據(jù)庫Web 前端用戶訪問入口應用服務器這個依賴鏈條決定了一切安裝順序數(shù)據(jù)庫必須先就位應用服務器其次報表和作業(yè)服務最后。很多新手栽在順序上先裝了應用服務器發(fā)現(xiàn)連不上庫又回頭折騰數(shù)據(jù)庫前面的配置全白費。提示安裝前把這張依賴表打印出來貼在顯示器邊上每完成一個組件打個勾能避免絕大多數(shù)順序性錯誤。1.3 操作系統(tǒng)層面的前置規(guī)劃RHEL 這邊要提前定幾件事主機名、IP 規(guī)劃、磁盤分區(qū)、SELinux 策略、防火墻規(guī)則。主機名一旦在安裝數(shù)據(jù)庫時寫入后面改起來極其麻煩所以第一步就定死。磁盤分區(qū)上數(shù)據(jù)庫的數(shù)據(jù)目錄和歸檔目錄建議單獨掛載避免日志寫滿根分區(qū)導致系統(tǒng)卡死這個坑我見過太多次。SELinux 和防火墻是另一個高頻雷區(qū)。P6 各組件之間通過固定端口通信SELinux 的默認策略會攔截不少非常規(guī)端口訪問。測試環(huán)境我通常直接把 SELinux 設為 permissive 模式生產(chǎn)環(huán)境則根據(jù)實際端口逐條放行而不是簡單粗暴地關(guān)掉。防火墻同理需要放行的端口包括數(shù)據(jù)庫監(jiān)聽端口、應用服務器 HTTP/HTTPS 端口、報表服務端口等具體端口號在安裝各組件時確認后統(tǒng)一配置。2. 操作系統(tǒng)與數(shù)據(jù)庫的實操落地這一層是整個系統(tǒng)的地基地基不穩(wěn)后面全是隱患。RHEL 的準備工作看似瑣碎但每一項都有明確的意圖。2.1 RHEL 基礎環(huán)境配置清單拿到一臺干凈的 RHEL 機器我按這個順序過一遍基本不會漏確認系統(tǒng)版本與內(nèi)核cat /etc/redhat-release和uname -rP6 EPPM 對 RHEL 大版本有明確支持矩陣裝之前對照官方兼容性列表確認別用太新的小版本中間件兼容性容易出問題。設置主機名hostnamectl set-hostname p6app01同時更新/etc/hosts加入本機 IP 與主機名映射這一步不做后面數(shù)據(jù)庫監(jiān)聽和應用連接都會出詭異問題。關(guān)閉不必要的服務把 NetworkManager 之外的非必要服務停掉減少端口和資源爭搶。調(diào)整內(nèi)核參數(shù)數(shù)據(jù)庫和應用服務器對文件句柄數(shù)、共享內(nèi)存、網(wǎng)絡連接數(shù)有要求在/etc/security/limits.conf里給對應用戶調(diào)高nofile和nproc在/etc/sysctl.conf里調(diào)整kernel.shmmax、kernel.shmall、net.core.somaxconn等參數(shù)。創(chuàng)建專用用戶和用戶組數(shù)據(jù)庫、應用服務器各用獨立系統(tǒng)用戶不要用 root 跑任何應用進程這是安全底線。內(nèi)核參數(shù)這塊補充一下計算邏輯。kernel.shmmax建議設為物理內(nèi)存的一半或更大單位是字節(jié)比如 32G 內(nèi)存的機器設為 17179869184。kernel.shmall是共享內(nèi)存頁數(shù)等于 shmmax 除以頁大小通常 4096 字節(jié)。這些值不是拍腦袋定的數(shù)據(jù)庫啟動時如果共享內(nèi)存不夠會直接報錯起不來。2.2 數(shù)據(jù)庫安裝的關(guān)鍵決策與步驟P6 EPPM 支持多種數(shù)據(jù)庫實際項目里最常見的是 Oracle 和 SQL ServerRHEL 環(huán)境下自然是 Oracle 為主。數(shù)據(jù)庫版本要嚴格對照 P6 的支持矩陣差一個小版本都可能遇到驅(qū)動不兼容。安裝 Oracle 的流程本身有大量成熟資料這里只講和 P6 相關(guān)的關(guān)鍵點。第一字符集必須選 AL32UTF8P6 的多語言支持依賴這個裝錯了后面中文亂碼、特殊字符丟失改字符集幾乎等于重建庫。第二創(chuàng)建 P6 專用表空間時給足初始大小我一般數(shù)據(jù)表空間起步 10G、索引表空間 5G自動擴展打開但設上限避免磁盤被悄悄吃滿。第三監(jiān)聽配置要確認local_listener和remote_listener正確應用服務器連不上庫十有八九是監(jiān)聽或網(wǎng)絡訪問控制的問題。數(shù)據(jù)庫裝完后用 P6 安裝介質(zhì)里提供的建庫腳本創(chuàng)建 schema。這一步要注意腳本執(zhí)行用戶的權(quán)限以及腳本里表空間名稱、數(shù)據(jù)文件路徑要和實際環(huán)境一致。執(zhí)行完檢查有沒有報錯有些腳本報錯不中斷但會留下殘缺的對象后面應用啟動時才暴露排查成本極高。注意建庫腳本執(zhí)行前先做一次數(shù)據(jù)庫全備腳本中途失敗需要回滾重來時有備份能省下大量時間。2.3 數(shù)據(jù)庫連接與網(wǎng)絡訪問驗證數(shù)據(jù)庫就位后別急著裝應用先在數(shù)據(jù)庫服務器上用tnsping驗證監(jiān)聽可達再從應用服務器上用客戶端工具測試連接。我習慣在應用服務器上裝一個輕量客戶端用sqlplus連一次確認網(wǎng)絡、監(jiān)聽、賬號密碼、服務名全部正確。這一步花五分鐘能省掉后面應用部署時半小時的瞎猜。連接測試通過后記錄下完整的連接串信息主機、端口、服務名、schema 用戶名。后面應用服務器配置數(shù)據(jù)源時要一字不差地填進去大小寫、下劃線都不能錯。3. 應用服務器與 P6 組件的部署實現(xiàn)應用服務器是 P6 EPPM 的核心承載層配置項最多也最容易出問題。這一層的思路是先把中間件裝好調(diào)通再部署應用包。3.1 應用服務器中間件的安裝與調(diào)優(yōu)P6 EPPM 主流跑在 WebLogic 上部分版本也支持其他中間件。WebLogic 的安裝分兩步先裝基礎中間件再建域。建域時選擇 P6 提供的模板能自動帶出大部分必要配置比手工建域省事且不易漏項。WebLogic 的調(diào)優(yōu)重點在 JVM 參數(shù)。默認堆內(nèi)存往往偏小P6 應用啟動后加載大量類和緩存堆不夠會頻繁 Full GC表現(xiàn)為頁面響應越來越慢。我一般把初始堆和最大堆設為相同值比如-Xms4g -Xmx4g避免運行期堆伸縮帶來的抖動元空間設-XX:MetaspaceSize512m -XX:MaxMetaspaceSize1g垃圾回收器根據(jù) JDK 版本選擇較新版本用 G1 表現(xiàn)更穩(wěn)。域建好后先啟動一次管理服務器確認能正常進入控制臺再考慮部署應用。這一步是驗證中間件本身沒問題把中間件問題和應用問題隔離開排查時思路清晰得多。3.2 P6 應用包的部署與數(shù)據(jù)源配置應用包部署通過 WebLogic 控制臺完成把 P6 的 ear 包上傳部署部署時指定為生產(chǎn)模式還是開發(fā)模式要按環(huán)境用途選。部署過程中最關(guān)鍵的是數(shù)據(jù)源配置需要填數(shù)據(jù)庫連接信息并測試連接。這里有個細節(jié)數(shù)據(jù)源的初始連接數(shù)和最大連接數(shù)要匹配預期并發(fā)設太小高并發(fā)時連接等待設太大又浪費數(shù)據(jù)庫資源我一般初始 10、最大 50 起步壓測后再調(diào)。部署完成后不要立刻啟動先檢查部署描述符里的上下文根、端口配置是否和規(guī)劃一致。有些版本的默認上下文根和實際訪問路徑不同不確認清楚會出現(xiàn)部署成功但訪問 404 的情況。3.3 報表服務與作業(yè)服務的配置要點報表服務和作業(yè)服務是容易被忽視但缺一不可的組件。報表服務負責生成各類分析報表配置時要指定報表服務器地址、數(shù)據(jù)庫連接和輸出目錄。輸出目錄的磁盤空間要留足報表文件積累起來很占地方我見過因為報表目錄寫滿導致整個報表功能癱瘓的案例。作業(yè)服務負責后臺定時任務比如進度計算、數(shù)據(jù)同步。配置時注意作業(yè)的執(zhí)行頻率和超時時間頻率設太密會給數(shù)據(jù)庫帶來持續(xù)壓力超時設太短則大項目計算容易中斷。這兩個參數(shù)沒有標準答案要根據(jù)實際項目規(guī)模和服務器性能調(diào)我的經(jīng)驗是先按默認值跑一周觀察作業(yè)日志里的執(zhí)行時長再針對性調(diào)整。4. 服務啟動、驗證與常見問題排查所有組件裝完真正的考驗才開始。啟動順序、日志觀察、功能驗證每一步都有講究。4.1 正確的啟動順序與健康檢查啟動順序嚴格遵循依賴關(guān)系數(shù)據(jù)庫 → 應用服務器管理節(jié)點 → 應用服務器受管節(jié)點 → 報表服務 → 作業(yè)服務。每啟動一個組件等它完全就緒再啟動下一個不要圖快一次性全拉起來否則出問題時根本分不清是誰的鍋。健康檢查我按這個清單過數(shù)據(jù)庫監(jiān)聽狀態(tài)、應用服務器控制臺可訪問、P6 Web 登錄頁能打開、用測試賬號能登錄、能創(chuàng)建并保存一個測試項目、報表能正常生成、作業(yè)服務日志無報錯。全部通過才算部署完成任何一項不過都要停下來排查。4.2 高頻問題速查與排查思路下面這張表是我這些年遇到最多的問題及處理方向按出現(xiàn)頻率排序問題現(xiàn)象可能原因排查方向應用啟動報數(shù)據(jù)庫連接失敗連接串錯誤、監(jiān)聽未起、網(wǎng)絡不通先用客戶端工具測試連接登錄頁能開但登錄報錯數(shù)據(jù)源配置錯誤、schema 不完整檢查數(shù)據(jù)源測試連接、核對建庫腳本頁面響應極慢JVM 堆不足、Full GC 頻繁看 GC 日志、調(diào)大堆內(nèi)存報表生成失敗報表服務未啟動、輸出目錄無權(quán)限查報表服務日志、檢查目錄權(quán)限作業(yè)不執(zhí)行作業(yè)服務未啟動、調(diào)度配置錯誤查作業(yè)服務日志、核對調(diào)度時間中文顯示亂碼數(shù)據(jù)庫字符集非 UTF8確認字符集必要時重建庫排查的核心方法是看日志而且要按組件分層看。應用服務器日志看部署和啟動問題應用自身日志看業(yè)務邏輯問題數(shù)據(jù)庫日志看連接和 SQL 問題。養(yǎng)成先看日志再動手的習慣比憑經(jīng)驗瞎猜高效得多。4.3 實操心得與避坑清單最后分享幾條文檔里不會寫但實際很管用的經(jīng)驗。第一所有配置文件改動前先備份改壞了能秒回滾這個習慣救過我無數(shù)次。第二安裝過程中每一步的截圖和命令記錄保存好重裝或遷移時就是現(xiàn)成的操作手冊。第三測試環(huán)境驗證通過的配置遷移到生產(chǎn)前逐項核對環(huán)境差異往往是事故源頭。第四磁盤空間監(jiān)控一定要做數(shù)據(jù)庫歸檔、應用日志、報表文件都是空間消耗大戶提前設告警比事后救火強。這套部署流程我在不同規(guī)模的環(huán)境里反復驗證過單機測試環(huán)境從零到可用大約半天分布式生產(chǎn)環(huán)境視復雜度一到三天。真正耗時的從來不是安裝本身而是配置調(diào)優(yōu)和問題排查把上面這些細節(jié)吃透能少走很多彎路。后續(xù)如果要做高可用或性能擴展也是在這套基礎上疊加地基打牢了往上加東西才踏實。