記一次Linux物理伺服器遷移總結

2021-09-04 05:25:55 字數 3102 閱讀 9434

1. 盡量不中斷業務,不影響使用者使用,如果影響使用者使用,則應該告知使用者做好接受和準備    

2. 伺服器硬體資源要統一,如硬體架構、晶元組、處理器等    

3. 系統軟體執行環境要盡可能保持一致    

4. 用最合適的人去做這件事情,有問題及時溝通

一些遷移指標:

乙個優秀的遷移工具,目標是最小化整體遷移的時間和停機時間,並且將遷移對於被遷移主機上執行服務的效能造成的影響降至最低。當然,這幾個因素互相影響,實施者需要根據遷移針對的應用的需求在其中進行衡量,選用合適的工具軟體。對於linux系統的遷移,由於是開源系統,因此可以借助一些開源工具和指令碼,手動遷移系統,這種方法要求負責實施遷移的管理員必須具有相關經驗,並且對物理機中執行的linux系統非常熟悉。    

遷移的整體步驟以及流程:

1. 準備遷移

1). 收集源主機硬體資訊與軟體環境等資訊,準備與源主機的相關軟硬體文件    

2). 依據上述資訊和文件將目標主機配置成與源主機相同的軟體環境(伺服器硬體資源統一的條件下)    

3). 測試上述配置結果(測試方法參考驗證遷移)    

4). 以上工作在遷移前做好

2. 實施遷移

1). 提前通知相關人員,做好遷移準備    

2). 切換網路引數,如切換ip等    

3). 關閉源主機上的業務應用程式    

4). 啟動目標主機上的業務應用程式    

5). 重新啟動或平滑重啟相關主機執行的關聯服務    

6). 遷移當天完成

3. 驗證遷移

1). 自測遷移結果    

2). 請其他人員測試遷移結果,如研發團隊或測試團隊的相關人員    

3). 遷移當天完成

4. 遷移後任務

1). 匯報通知到相關負責人    

2). 匯報通知到相關使用者    

3). 更新相關文件和記錄

5. 完成遷移(同「遷移後任務」)    

6. 回滾

1). 重新切換網路引數,如切換ip等    

2). 關閉目標主機上的業務應用程式    

3). 啟動源主機上的業務應用程式    

4). 更新相關主機執行的關聯服務的配置檔案等,重新啟動相關主機執行的關聯服務    

5). 修正問題,準備下一次遷移

應用切換/遷移的注意點:

1. 有一些應用程式因為實施之前需要測試,但啟動後可能跟生產環境中的一些伺服器有衝突,例如訊息處理應用程式可能會與其他訊息處理程式爭奪訊息佇列中的訊息,因此測試時需要注意消除這種可能存在的衝突問題,這也要求應用程式需要盡可能的松耦合,盡可能的模組化,以便於更改。    

2. 遷移過程中,啟動目標主機上的業務應用程式,必須關閉源主機上的業務應用程式,反之亦然    

3. 無論哪種切換,盡量做到無遺漏,事事鉅細

下面列舉一下linux系統遷移過程中需要注意和考慮的地方:

1. 整理遷移列表。

1). 包括源主機作業系統名稱,版本,主機名稱,環境變數,驅動程式,程序,安裝的軟體,安裝的服務,防火牆,核心引數,安全設定,使用者配置,證書金鑰,檔案許可權等系統基礎環境    

2). 根據程序名、埠號、防火牆配置,或者找到系統維護管理日誌,根據文件查詢當前伺服器正在提供的服務,服務的安裝手冊、服務依賴的軟體環境    

3). 根據文件或者源主機當前的網路連線狀態,主要是使用源主機的內網位址的相關主機,例如找到**源伺服器的相關主機,留意這些**主機上的配置,如固定寫好內網ip,網域名稱資訊等,需要一起更改,典型的例子就是nginx、haproxy反向**    

4). 一些較為特殊的檔案目錄,軟體編譯目錄,/etc/profile,~/.bash_profile,/etc/rc.local,~/.profile,~/.ssh,/etc/fstab,/etc/hosts,/etc/sysconfig等等    

5). 如果遷移專案或步驟過多,可以做成相應的列表,便於對照參考,和防止遺漏,可參考附錄

2. 準備目標主機。

1). 採用手動(可以逐條操作也可以編寫指令碼等)的方式,將目標主機配置成與源主機盡可能相同的軟體環境測試目標主機

3. 切換網路引數。如果只是切換公網ip,不切換內網ip,由於內網ip可能會做一些網路內部的耦合,因此需要注意其他相關主機

遷移總結:

1. 文件化標準化的實施很重要,儘管也許很辛苦很累,但要盡可能去做    

2. 已經發生的變更需要及時修改相關文件和告知相關人    

3. 部署規範化,如固定的編譯安裝目錄,人性化的軟鏈結,嚴格參照文件    

4. 合理利用工具和技巧,減少操作時間    

5. 軟體設計過程中盡可能的高內聚低耦合,盡可能支援橫向擴充套件,達到無狀態的軟體設計是一種非常理想化的設計目標    

6. 有一些硬體製造商提供了一些遷移工具或者資訊收集工具,可以進行參考,如dell的systemmanager、dset,cisco的ucs manager等相關工具

如何避免夜間遷移、公升級或業務變更等操作:

1. 要想避免半夜公升級,必須採用ha的系統架構(無單點故障),即當有一台或多台伺服器宕機時,對使用者無影響    

2. 軟體盡可能的松耦合,盡可能支援橫向擴充套件    

3. 合理利用自動化、指令碼、計畫任務等    

4. 多寫測試多做演練,例如究竟能否正常回滾等    

5. 凡事提前溝通,有事好商量,;)

附錄:

#源伺服器設定

設定標識

目標伺服器設定狀態結果備註1

key1

value1

success

2key2

value1

failed

原因,解決辦法等

其他參考:      

1.紅帽red hat文件:

2.微軟microsoft technet:

3.微軟論壇中的遷移主題:

4.虛擬機器遷移技術漫談:

--end--

記一次Linux物理伺服器遷移總結

原始出處 作者資訊和本宣告。否則將追究法律責任。1.盡量不中斷業務,不影響使用者使用,如果影響使用者使用,則應該告知使用者做好接受和準備 2.伺服器硬體資源要統一,如硬體架構 晶元組 處理器等 3.系統軟體執行環境要盡可能保持一致 4.用最合適的人去做這件事情,有問題及時溝通 一些遷移指標 乙個優秀...

記一次伺服器專案遷移

今天被分配了伺服器專案遷移的任務,現在還在傳輸,閒著沒事就寫下總結,也算是一種學習 開啟虛擬機器,訪問需要遷移的伺服器 賬號密碼請向領導或運維索要 找到需要遷移的專案,一般在home 公司名 專案名,例如我所在的公司服務放置在home che tomcat epc 10100複製專案 訪問被遷移到的...

記一次django遷移到伺服器之xadmin爬坑

記下來,免得別人也踩坑。檔案拷到伺服器上以後,剛開始是直接安裝的pip install r requirements.txt 然後在執行時就出錯了,一堆關於xadmin的錯誤,接著就開始了爬坑過程 網上找啊找,辦法用盡沒找到。也有一些帖子說是要從github上安裝xadmin,試了 pip inst...