為什麼 Red Hat 和 CentOS 的主要版本之間升級如此困難？
“我們可以將現有的生產 EL5 伺服器升級到 EL6 嗎？”
來自兩個環境完全不同的客戶的一個聽起來很簡單的請求促使我通常的最佳實踐回答是“是的，但它需要協調重建你的所有系統”……
由於停機和資源原因，兩位客戶都認為完全重建系統是不可接受的選擇……當被問及為什麼有必要完全重新安裝系統時，我沒有很好的答案，“就是這樣……”
我不是試圖引出關於配置管理的回應（“Puppetize Everything ”並不總是適用）或客戶應該如何更好地計劃。這是一個真實的環境範例，這些環境在生產能力方面已經發展壯大，但沒有看到轉移到其作業系統下一個版本的干淨路徑。
環境 A：
非營利組織，擁有40 個 Red Hat Enterprise Linux 5.4 和 5.5 Web、數據庫伺服器和郵件伺服器，執行 Java Web 應用程序堆棧、軟體負載平衡器和 Postgres 數據庫。所有系統都在不同位置的兩個 VMWare vSphere 集群上進行虛擬化，每個集群都具有 HA、DRS 等。
環境 B：
高頻金融交易公司，在多個託管設施中擁有200 個 CentOS 5.x系統，執行生產交易業務，支持內部開發和後台功能。交易伺服器在裸機商品伺服器硬體上執行。他們有許多
sysctl.conf,rtctl, 中斷綁定和驅動程序調整以降低消息傳遞延遲。有些有自定義和/或實時核心。開發者工作站也執行類似版本的 CentOS。在這兩種情況下，環境都按原樣執行。升級的願望來自對 EL6 中可用的更新應用程序或功能的需求。
- 對於這家非營利性公司來說，它與 Apache、核心和一些讓開發人員高興的東西相關聯。
- 在貿易公司，它是關於核心、網路堆棧和 GLIBC 的一些增強，這將使開發人員感到高興。
兩者都是在不徹底改變作業系統的情況下無法輕鬆打包或更新的東西。
作為一名系統工程師，我很欣賞 Red Hat 建議在主要版本之間移動時完全重建。一個乾淨的開始會迫使您重構並在此過程中註意配置。
對客戶的業務需求敏感，我想知道為什麼這需要如此繁重的任務。RPM 打包系統不僅能夠處理就地升級，但正是這些小細節讓你受益匪淺：
/boot需要更多空間、新的預設文件系統、RPM 可能會在升級過程中中斷、已棄用和失效的軟體包……這裡的答案是什麼？其他發行版（基於 .deb、Arch 和 Gentoo）似乎具有這種能力或更好的途徑。假設我們找到了以正確方式完成此任務的停機時間：
- 當EL7發布並穩定時，這些客戶端應該怎麼做才能避免同樣的問題呢？
- 或者這是人們需要每隔幾年就完全重建的情況？
- 隨著企業 Linux 的發展，這似乎變得更糟了……或者我只是在想像嗎？
- 這是否會阻止任何人使用 Red Hat 和衍生作業系統？
我想這是配置管理的角度，但我看到的大多數 Puppet 安裝都不能很好地轉化為具有高度定制的應用程序伺服器的環境（環境 B
ifconfig可能有一個輸出看起來像這樣的單個伺服器）。不過，我很想听聽有關如何使用配置管理來幫助組織克服 RHEL 主要版本問題的建議。
（作者註：這個答案是指 RHEL 6 和之前的版本。RHEL 7 現在有一個完全支持的從 RHEL 6 升級的路徑，詳細資訊在最後。）
首先，我應該注意有兩種方法可以進行就地升級：
- 放入安裝 DVD（或通過 iLO/iDRAC 使用 DVD 映像），從中引導並選擇升級，例如
linux upgradeany.- 手動更新
redhat-releaseRPM，執行yum distro-sync（這有點過於簡單）並重新啟動。方法 1 只是不受支持。方法 2 適用於真正的牛仔。除了推薦的全新安裝之外，我還完成了這兩項…
我需要支持嗎？
支持在我們的世界中具有兩個互補的含義。首先是產品具有給定的特性（例如“Postfix 支持 SMTP”）。第二個是供應商會和你談談。從上下文中並不總是清楚意味著哪個定義。
要完成一項任務，您顯然首先需要支持。供應商支持的作用是幫助您解決問題並向供應商提供有關哪些功能需要存在或改進的回饋。當許多網站擁有內部專業知識來解決可能出現的任何問題時，他們會為供應商支持支付巨額費用，比供應商更快，甚至更便宜。是否購買供應商支持最終是您必須做出的業務決策（或建議管理層）。
為什麼不進行就地升級？
這就是紅帽所說的：
Red Hat 不支持在 Red Hat Enterprise Linux 的任何主要版本之間進行就地升級。主要版本由整數版本更改表示。例如，Red Hat Enterprise Linux 5 和 Red Hat Enterprise Linux 6 都是 Red Hat Enterprise Linux 的主要版本。
跨主要版本的就地升級不會保留所有系統設置、服務或自定義配置。因此，從一個主要版本升級到另一個主要版本時，Red Hat 強烈建議全新安裝。
他們進一步警告：
但是，在選擇升級系統之前，請注意以下限制：
- 由於各種配置文件格式或佈局的變化，單個軟體包配置文件在執行升級後可能會或可能不會起作用。
- 如果您安裝了 Red Hat 的一種分層產品（例如 Cluster Suite），則可能需要在 Red Hat Enterprise Linux 升級完成後手動升級它。
- 升級後第三方或 ISV 應用程序可能無法正常工作。
當然，他們隨後描述瞭如何通過方法 1 進行就地升級，以防萬一您真的想這樣做。該功能存在並且 Red Hat 將開發時間投入其中，因此支持該功能存在。但如果出現問題，Red Hat 會告訴你重新安裝；他們不會為升級導致的問題提供供應商支持。
作為記錄，我實際上從未遇到過我自己無法解決的 RHEL/CentOS 或 Fedora 系統的就地升級問題。典型的問題來自重命名的包、第三方儲存庫以及包的 i386 和 x86_64 架構之間偶爾的版本不匹配。我認為安裝程序在處理這些方面要好一些
yum。我應該如何升級？
我通常會警告人們，他們應該每 3-4 年計劃一次維護視窗，以將 RHEL 系統從一個主要版本更新到下一個主要版本。雖然升級通常順利進行，但總是會發生意外。
對於您的兩個環境，我希望就地升級會起作用，但我強烈建議先徹底測試它。P2V 是伺服器的代表性樣本，並在虛擬系統上進行就地升級，以查看您將遇到哪些問題。然後，您可以根據對將要發生的情況的更好了解來計劃實際的生產升級。
對於像您在這裡這樣的大型部署，請考慮使用 Limoncelli 的“一對多”方法。升級一台機器，看看出現什麼問題，解決它們，然後在升級小批量機器時使用經驗教訓，重複經驗教訓，然後當你認為你已經解決了所有問題時，升級大量機器。
在這種情況下，我還建議您仔細研究一下您的應用程序部署過程。如果它不夠自動化，您可以通過一個命令啟動它並合理地確定應用程序將正確部署，那麼開發人員可能需要著手解決這個問題。擁有這樣的部署過程將使全新安裝 EL 的較新版本然後部署到它上面變得更加容易。
切換發行版會有幫助嗎？
基於 Debian 的發行版確實有一種受支持的就地升級方法，而且它大部分都可以工作，但它也不能倖免於問題。例如，對於通過支持的方法從 Ubuntu 10.04 LTS 升級到 12.04 LTS的人來說，很多事情都失敗了。尚不清楚 Debian 或 Canonical 是否投入了足夠的開發時間來“支持”此功能，即確保其正常工作。如果您希望有人牽手，您實際上仍然需要為此發行版購買供應商支持。所以我懷疑你會從切換到這樣的發行版中獲得很多。
您可以通過切換到滾動發布的發行版（例如 Gentoo 或 Arch）來獲得收益。然而，這也不能讓你對問題免疫。這只是意味著您必須在伺服器的整個生命週期內不斷地處理升級問題（例如，每當您或開發人員決定更新系統上的某些內容時），而不是在精心策劃的發行版升級時間一次性處理所有問題。您也沒有供應商提供支持。
未來該何去何從？
Fedora 項目正在開發一種工具來改進就地升級。從 Fedora 18 開始，他們有一個名為fedup的工具
preupgrade被廢棄並取而代之。這已添加到 RHEL7 中，現在就地升級完全支持，至少從 RHEL 6 到 RHEL 7。根據我自己的經驗，我可以說雖然仍有一些問題，但它正在成為一個非常有用的工具。fedupCentOS 也在試驗滾動發布類型的儲存庫，但它只適用於次要版本（例如 6.3-6.4）。