上期我們發布了《完全替換F5，深信服應用交付AD如何做到？》后，有來自金融、企業、政府、能源行業的用戶給我們留言，關心實際替換過程中的具體操作問題。

今天，我們為大家梳理了F5平滑替換至深信服應用交付AD需要重點關注的四大關鍵點，并提供實際的操作建議，希望幫助大家完成平滑替換。

解耦聯動很絲滑——四步解耦，完成平滑升級

在F5 GTM（全局負載）和LTM（服務器負載）聯動的使用場景，解耦的操作至關重要，因為它可以降低系統復雜性，控制替換風險，確保業務連續性，同時提高系統的靈活性和維護效率。通過以下四個步驟的解耦操作，用戶可以逐步平滑地替換到深信服應用交付AD。

• 步驟一：

深信服應用交付AD SLB（服務器負載均衡）與F5 LTM并行提供服務，同時F5 GTM通過健康檢查的方式檢查深信服應用交付AD SLB 上的業務地址并對外進行發布。

• 步驟二：

采用灰度測試驗證深信服應用交付AD SLB業務正常，可通過F5 GTM將業務全部流量切換到新的深信服應用交付AD SLB上，完成深信服應用交付AD SLB的替換。

• 步驟三：

添加域名注冊商的NS記錄，將深信服應用交付AD GSLB的DNS服務地址添加進來，與F5 GTM并行提供DNS服務。  

• 步驟四：

深信服應用交付AD與F5GSLB系統并行運行一段時間后，在互聯網域名注冊機構的DNS管理后臺，將F5 GTM的NS地址刪除，從而完成替換F5 LTM 與GTM。   

機制對齊很絲滑——每個機制都有“解”，完成平滑替換

平滑替換過程中，用戶需要對齊F5與深信服應用交付AD的業務處理機制。

這些機制涉及地址轉換、會話保持、健康檢查及流量分配策略等多個技術層面，以執行HTTP健康檢查為例，F5與深信服應用交付AD的處理方式存在差異：F5在健康檢查中不區分大小寫，而深信服應用交付AD則區分。如果F5預期響應為大寫"OK"，但實際頁面返回小寫"ok"，深信服應用交付AD將會認為檢查失敗。因此，在從F5替換至深信服應用交付AD時，務必確認并統一響應內容的大小寫格式，以確保健康檢查的準確性，避免對業務造成影響。

此外，還有以下三個機制的對齊細節需要注意，從而保障替換F5后系統的整體穩定性和可靠性。

源IP地址透傳—XFF方式機制

當客戶端請求中已經存在XFF字段時，深信服應用交付AD直接將客戶端源地址插入到原來頭部信息的后面，如果需要插入一個新的XFF頭部，則需要采用iPro腳本方式實現。

源IP地址透傳—TCP Option方式機制

深信服應用交付AD通過iPro腳本的方式來實現，四/七層插入的地方有差異，四層純轉發模式插入的位置為syn包；七層TCP代理模式插入的位置為三次握手之后的數據包的TCP頭部。

Cookie會話保持—插入模式機制

深信服應用交付AD具備以下機制：

1. 在默認情況下會自動生成cookie名稱[SF_cookie_pooid]，其中poolid根據調度的節點池動態生成，對外不暴露配置信息，也可自定義cookie名稱；
2. 默認添加節點信息時，深信服應用交付AD會生成8位數字隨機碼，作為member對應的Cookie值，唯一標識一個節點信息，不暴露任何節點相關信息。
3. 深信服應用交付AD在收到客戶端HTTP請求頭部后，解析Cookie頭部信息，查找會話保持Cookie信息，根據Cookie值查找對應的member信息，判斷member狀態，進行流量分發。

如果您有F5替換需求，需要了解更多深信服應用交付AD與F5的機制區別，請聯系我們的售前工程師。

iRules腳本兼容很絲滑——F5 iRules腳本直接復制使用，完成平滑替換

F5替換核心業務系統時，iRules腳本遷移是關鍵問題。深信服應用交付AD支持TCL語言，用戶可以直接復制使用F5 iRules腳本，無需人工進行翻譯轉換，實現平滑過渡。

另外，深信服應用交付AD提供LUA語言的iPro可編程腳本，在保證與iRules功能一致的情況下，實現更高效的業務處理。

配置遷移很絲滑——自動轉換工具，實現無縫、安全、高效遷移

F5替換的實際操作中，還容易面臨配置遷移難題，手動操作易出錯且耗時。深信服提供自動轉換工具，將F5的UCS配置文件轉換為AD配置，實現無損、高效遷移，降低人力和時間成本。

以上是用戶在替換時容易遇到的難題。

實際上，在用戶的替換過程中，深信服會全程參與，提供一站式全流程替換服務，確保用戶在各環節都能獲得專業指導和技術支持。

截至目前，深信服應用交付AD已經累計服務了超過11000家用戶，為數萬個關鍵業務系統的可靠高效運行提供有力保障。其中為50%的銀行、證券、保險等金融行業用戶解決應用交付升級需求，助力每個用戶在數字化轉型的道路上「穩」步前行。