當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

SONiC Warm Reboot

發布時間：2023/12/8 编程问答 68 豆豆

生活随笔收集整理的這篇文章主要介紹了 SONiC Warm Reboot 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

原文：https://github.com/jipanyang/SONiC/blob/69d76c5fd2d870e2c53cbe367fd09927bb4836ba/doc/warm-reboot/SONiC_Warmboot.md

Overview
Use cases
- In-Service restart
  - Un-Planned restart
  - BGP docker restart
  - SWSS docker restart
  - Syncd docker restart
  - Teamd docker restart
- In-Service upgrade
  - Case 1: without SAI api call change
  - Case 2: with SAI api call change
    - Case 2.1 attribute change with SET
    - Case 2.2 Object change with REMOVE
    - Case 2.3 Object change with CREATE
      - case 2.3.1 New SAI object
      - case 2.3.2 Old object in previous version to be replaced with new object in new software version
- Cold restart fallback
Proposal 1: Reconciliation at Orchagent
- Key steps
  - Restore to original state
  - Remove stale date and perform new update
  - States of ASIC/LibSAI, syncd, orchagent and applications become consistent and up to date.
- Questions
  - How syncd restores to the state of pre-shutdown
  - How Orchagent manages data dependencies during state restore
  - What is missing in Orchagent for it to restore to the state of pre-shutdown
  - How Orchagent gets the OID information
  - How to handle the cases of SAI api call change during restore phase.
  - How to deal with the missing notification during the reboot/restart window
- Requirements on LibSAI and ASIC
- Requirements on syncd
- Requirement on network applications and orch data
  - General requirements
  - Port
  - Lag/teamd
  - Interface
  - Fdb
  - Arp
  - Route
  - Acl
  - Buffer
  - Qos
- Summary
- Approach evaluation
  - Advantages
  - Concerns/Issues with this approach
Proposal 2: Reconciliation at syncd
- The existing syncd INIT/APPLY view framework
  - Invariants for view comparison
    - Switch internal objects discovered vis SAI get operation.
    - Configured attribute values like VLAN id, interface IP and etc.
  - View comparison logic
- Orchagent and network application layer processing
- Approach evaluation
  - Advantages
  - Concerns/Issues with this approach
Open issues
- How to do version control for software upgrade at docker level?
- Rollback support in SONiC
- What is the requirement on control plane down time?
- Upgrade path with warm reboot support
- Latency requirement on LibSAI/SDK warm restart
- Backward compatibility requirement on SAI/LibSAI/SDK?
- What is the requirment on LibSAI/SDK with regards to data plane traffic during warm reboot? Could FDB be flushed?
- What are the the principles of warm reboot support for SONiC?
References

? ? ? ?

Overview

? ? ? ? SONiC熱重啟的目標是能夠在不影響數據平面的情況下重啟和升級SONiC軟件。每個進程/docker的熱重啟也是目標的一部分。除了syncd和database docker之外，所有其他網絡應用程序和docker都需要支持非計劃的熱重啟。
? ? ? ?對于重啟處理，SONiC可大致分為三層：

網絡應用程序和Orchagent：每個應用程序將經歷相似的處理流程。應用程序和相應的orchagent子模塊需要協同工作，以恢復原始數據并填充熱啟動的增量。以路由為例，重啟操作后，網絡應用程序BGP優雅地重啟，通過與對等方的對話與最新的路由狀態同步，fpmsyncd利用BGP的輸入編寫appDB程序，并對除這些路由外的所有舊路由/新路由進行處理，不作任何更改。RouteOrch響應來自fpmsyncd的操作請求，并將任何更改向下傳播到syncd。

Syncd:Syncd應該在重啟前轉儲ASICDB，并恢復到與重啟前相同的狀態。恢復SONiC syncd本身不應干擾ASIC的狀態。它從Orchagent獲取更改，并在必要的轉換之后將其傳遞給LibSAI/ASIC。
LibSAI/ASIC:ASIC供應商需要確保ASIC和LibSAI的狀態恢復到與重啟前相同的狀態。

用例

In-Service restart

在不影響服務的情況下重新啟動組件的機制。這假設組件的軟件版本在重新啟動后沒有更改。在重新啟動窗口期間，可能會有數據更改，如新/舊路由、端口狀態更改、fdb更改。
這里的組件可以是整個SONiC系統，也可以是運行SONiC的一個或多個dockers。

Un-Planned restart

所有網絡應用程序和orchagent都希望能夠處理計劃外重啟，并正常恢復。由于對ASIC處理的依賴性，對syncd和ASIC/LibSAI，這不是必要條件。

BGP docker restart

BGP docker重啟后，可以從BGP對等方處學習新路由，一些已被推下至APPDB和ASIC的路由可能已不存在。系統應能清除從APPDB到ASIC的陳舊路由，并對新的路由進行編程。

SWSS docker restart

swss docker重啟后，所有端口/LAG、vlan、接口、arp和route data都應該從configDB、APPDB、Linux內核和其他可靠來源恢復。在重新啟動窗口期間可能會有端口狀態、ARP、FDB更改，應執行正確的同步處理。

Syncd docker restart

重新啟動syncd docker應保持數據平面完好無損。重啟后，syncd恢復對ASIC/LibSAI的控制和與swss docker的通信。在syncd docker中運行的所有其他函數也應該像flexcounter處理一樣恢復。

Teamd docker restart

重新啟動teamd docker不應導致link 抖動或任何流量損失。數據平面上的所有滯后應保持不變。

In-Service upgrade

在不影響服務的情況下將組件升級到較新版本的機制。
這里的組件可以是整個SONiC系統，也可以是運行SONiC的一個或多個dockers。

Case 1: without SAI api call change

BGP、neighsyncd、portsyncd甚至orchagent等網絡應用程序中都有軟件更改，但這些更改不會影響到與syncd的接口以及現有數據（元數據和依賴關系圖）的組織。在重新啟動窗口期間，可能會有數據更改，如新/舊路由、端口狀態更改、fdb更改。
服務內重啟的所有處理也適用于此。

Case 2: with SAI api call change

Case 2.1 attribute change with SET

新版本的orchagent可能會導致SET api對某些屬性使用與以前版本不同的值。或者將調用一個新的屬性集。

Case 2.2 Object change with REMOVE

在新的軟件版本中，默認情況下可以刪除以前版本中存在的對象。

Case 2.3 Object change with CREATE

兩種情況：

case 2.3.1 New SAI object

這是在SAI層定義的新對象，在新版軟件的orchagent處觸發CREATE調用。

case 2.3.2 Old object in previous version to be replaced with new object in new software version

例如，對象將被創建為具有更多或更少的屬性或不同的屬性值，或者多個實例對象將被替換為聚合對象。這是最復雜的場景，如果舊對象不是葉對象，那么所有其他依賴于舊對象的對象都應該被正確清理。

Cold restart fallback(冷重啟回退)

應提供通過SWSS、syncd和teamd dockers配置進行冷重啟或熱重啟的選項。如果熱重啟失敗，應提供冷重啟的回退機制。

Proposal 1: Reconciliation at Orchagent

Key steps

Restore to original state

a、 LibSAI/ASIC能夠在不中斷上層的情況下恢復到重啟前的狀態。

b、 Syncd能夠在不中斷ASIC和上層的情況下恢復到重啟前的狀態。

c、 Syncd狀態由Orchagent驅動（FDB除外），一旦恢復，就不需要自己進行調解。

Remove stale date and perform new update

a、根據每個網絡應用程序的具體行為，它要么從configDB讀取數據，要么從Linux內核（例如，for port、ARP）和BGP協議等其他源獲取數據，然后再次對APPDB進行編程。它跟蹤任何過時的數據以便刪除。Orchagent使用來自APPDB的請求。
b、 Orchagent從APPDB中恢復在其他docker（如BGP和teamd）中運行的應用程序的數據，以便能夠處理僅重啟swss的情況，并從configDB恢復ACL數據。Orchagent確保LibSaiRedis接口上的idempotent 操作，不傳遞以前對對象執行的任何create/remove/set操作。
請注意，為了減少orchagent中的依賴等待時間，松散順序控制是很有幫助的。路由的恢復可以在端口、lag、接口和ARP數據（主要）處理之后進行。
每個應用程序負責在重啟前后收集任何增量，并對增量數據執行創建（新對象）、設置或刪除（過時對象）操作。
c、 Syncd處理來自Orchagent的請求，就像正常引導一樣。

States of ASIC/LibSAI, syncd, orchagent and applications become consistent and up to date.

（ASIC/LibSAI、syncd、orchagent和應用程序的狀態變得一致和最新）

Questions

How syncd restores to the state of pre-shutdown

在這種方法中，syncd只需要保存和恢復對象RID和VID之間的映射。

How Orchagent manages data dependencies during state restore

（Orchagent如何在狀態恢復期間管理數據依賴關系）

每個orchagent子例程的構造函數可以正常啟動。

每個應用程序從讀取configDB數據或Linux內核恢復數據，或者在重新啟動時通過網絡協議重新填充數據，并相應地對appDB進行編程。每個網絡應用程序和orchagent子例程相應地處理依賴關系，這意味著某些操作可能會被延遲，直到所有必需的對象都準備好。依賴性檢查已經成為orchagent中現有實現的一部分，但是這個新場景可能會出現新的問題。
為了能夠處理只有swss重啟的情況，orchagent除了訂閱APPDB consumer channel外，還直接從APPDB恢復route（對于BGP docker）和portchannel數據（對于teamd docker）。數據恢復的松散順序控制有助于加快處理速度。

What is missing in Orchagent for it to restore to the state of pre-shutdown

（Orchagent中缺少什么，以便它恢復到停機前的狀態）

Orchagent和application可以在正常啟動時從configDB和APPDB獲取數據，但是為了能夠與syncd同步和通信，還需要為每個鍵類型為sai_object_id_t的對象提供OID。

typedef struct _sai_object_key_t {union _object_key {sai_object_id_t object_id;sai_fdb_entry_t fdb_entry;sai_neighbor_entry_t neighbor_entry;sai_route_entry_t route_entry;sai_mcast_fdb_entry_t mcast_fdb_entry;sai_l2mc_entry_t l2mc_entry;sai_ipmc_entry_t ipmc_entry;sai_inseg_entry_t inseg_entry;} key; } sai_object_key_t;

How Orchagent gets the OID information

對于對象鍵類型為sai_object_id_t的對象的SAI redis create操作，Orchagent必須能夠使用與關機前完全相同的OID，否則它將與syncd不同步。但目前的Orchagent實現只在運行時數據結構中保存OID。
對于以前通過sai redis get操作獲取的對象ID，同樣的方法仍然有效。
一個可能的解決方案是在redis_generic_create()保存OID和attr_list之間的映射。這假設在還原期間，對象創建將使用完全相同的 attr_list列表，因此可以找到并返回相同的OID。

當屬性第一次發生更改時，原始的默認映射可以保存在DEFAULT_ATTR2OID_ and DEFAULT_OID2ATTR_ tables表中。這是因為在還原過程中，object create可能使用默認屬性而不是當前屬性。
所有新的更改都將應用于常規ATTR2OID_ and OID2ATTR_ mapping表。
對于為同一組屬性創建多個對象的情況，可以為從屬性到OID的映射分配一個額外的所有者標識符，因此每個對象基于所有者上下文是唯一可識別的。一個突出的例子是使用lag_alias作為lag所有者，因此每個lag可以在重啟期間檢索相同的OID，盡管為lag create提供了NULL屬性。

+ SET_OBJ_OWNER(lag_alias);sai_status_t status = sai_lag_api->create_lag(&lag_id, gSwitchId, 0, NULL); + UNSET_OBJ_OWNER();

此解決方案中不需要虛擬OID。但如果保留虛擬OID層，也不會有什么壞處。
LibSaiRedis接口需要Idempotency 。

How to handle the cases of SAI api call change during restore phase.

（如何處理SAI-api調用在恢復階段發生變化的情況）

案例2.1屬性隨集更改：在sai_redis_generic_set層，基于object鍵，比較屬性值，并將更改直接應用到syncd/libsai/ASIC。

案例2.2Object change with REMOVE:：在 sai_redis_gereric_remove 層，如果在restoreDB中找到了對象鍵，則直接向syncd/libsai/ASIC應用REMOVE sai api調用。在orchagent已經保證了依賴性。
案例2.3使用CREATE更改對象：
案例2.3.1新SAI對象：只需將SAIAPI創建操作向下應用到syncd/libsai/ASIC。在orchagent已經保證了依賴性。但如果它不是一個葉子對象，那么在創建時對依賴它的其他對象會產生級聯效應，這將在下一個用例場景中處理。如果新的SAI對象僅用作其他對象的SET調用中的一個屬性，則可以在案例2.1屬性隨SET更改時處理它。
案例2.3.2用新軟件版本中的新對象替換以前版本中的舊對象：如果這是一個葉子對象，如路由條目、鄰居條目或fdb條目，只需添加特定于版本的邏輯即可將其刪除并創建新的。否則，如果有其他對象必須在create調用期間將此對象用作屬性之一，則應先刪除這些對象，然后再刪除此舊對象。這里需要特定于版本的邏輯。

How to deal with the missing notification during the reboot/restart window

端口/fdb在重新啟動窗口期間可能有新的狀態通知？可能相應的orchagent子例程應該對對象執行get操作？

Requirements on LibSAI and ASIC

LibSAI和ASIC應該能夠保存所有必要的狀態關閉請求與熱重啟選項。在create_switch（）請求時，LibSAI/ASIC應恢復到預關閉的確切狀態。在整個恢復過程中不應影響數據平面。一旦恢復完成，LibSAI/ASIC工作在正常的操作狀態，它們不知道上層發生的任何熱重啟處理。希望在LibSAI中支持create/remove/set的idempotency ，但對于熱重啟解決方案可能不是絕對必要的。

Requirements on syncd

Syncd應該能夠保存所有必要的狀態關閉請求與熱重啟選項。重新啟動時，syncd應恢復到預關機的確切狀態。一旦恢復完成，syncd工作在正常的操作狀態，它是不可知的，任何熱重啟處理發生在上層。

Requirement on network applications and orch data

General requirements

每個應用程序都應該能夠恢復到關機前的狀態。
Orchagent必須能夠保存和恢復Orchagent創建的對象的OID，并且對象key 類型為sai_object_id_t.。其他未由Orchagent創建的對象可以通過libsaireis接口的get操作還原OID。
每個應用程序的orchagent子例程可以使用現有的正常構造函數和producerstate/consumerstate處理流，以確保依賴性并填充內部數據結構。
如果docker僅重新啟動swss，則它應該能夠直接從appDB恢復路由和延遲數據，因為bgp docker和TeamDocker在此場景中不會將整組數據再次提供給appDB。
狀態恢復后，每個應用程序都應該能夠刪除任何過時的對象/狀態，并執行任何需要的創建/設置，或者以正常方式處理請求。

Port

Lag/teamd

Interface

Fdb

Arp

Route

Acl

Buffer

Qos

…

Summary

LayerRestoreReconciliationIdempotencyDependency management

Application/Orchagent	Y	Y	Y for LibSaiRedis interface	Y
Syncd	Y	N	Good to have	Good to have
LibSAI/ASIC	Y	N	Good to have	Good to have

Approach evaluation(方法評估)

Advantages（優勢）

簡單明了的邏輯，對于大多數升級/重啟案例來說易于實現。
層/應用程序解耦，易于分而治之。
每個docker都是獨立的，為swss進程和其他網絡應用程序的意外熱重啟做好準備。

Concerns/Issues with this approach（此方法的關注點/問題）

Orchagent軟件升級可能很方便，特別是對于SAI對象替換的情況，這需要Orchagent使用一次代碼來處理它們以進行服務內升級。

Proposal 2: Reconciliation at syncd

The existing syncd INIT/APPLY view framework

基本上有兩個視圖是為熱重啟創建的。當前視圖表示關閉前的ASIC狀態，臨時視圖表示重新啟動后新的預期ASIC狀態。基于SAI對象數據模型，每個視圖都是一個有向無環圖，all（？）對象鏈接在一起。

Invariants for view comparison（視圖比較的不變量）

Switch internal objects discovered vis SAI get operation.

它們包括 SAI_OBJECT_TYPE_PORT, SAI_OBJECT_TYPE_QUEUE, SAI_OBJECT_TYPE_SCHEDULER_GROUP, SAI_OBJECT_TYPE_SCHEDULER_GROUP 等。假設這些對象的RID/VID保持不變。問題1：如果版本更改后發現的對象發生更改，會怎樣？

Question 2: what if some of the discovered objects got changed? Like dynamic port breakout case.

Configured attribute values like VLAN id, interface IP and etc.

There could be change to the configured value, those not being changed may work as invariants.?Question 3: could some virtual OIDs for created objects in tmp view coincidently match with object in current view, but the objects are different? matchOids().

View comparison logic

視圖比較邏輯
利用對象的元數據，以這些不變量作為錨定點，對temp視圖中的每個對象，從樹的根開始，向下到子節點的所有層，直到葉子找到最佳匹配。如果未找到匹配項，則應在臨時視圖中創建對象，這是對象創建操作。如果找到了最佳匹配，但臨時視圖中的對象和當前視圖中的對象的屬性不同，則應執行設置操作。精確匹配產生Temp VID到當前VID的轉換，這也為上層比較鋪平了道路。應刪除當前視圖中末尾引用計數為0的所有對象，請執行“刪除”操作。

Question 4: how to handle two objects with exactly same attributes? Example: overlay loopback RIF and underlay loopback RIF. VRF and possibly some other object in same situation?

Question 5: New version of software call create() API with one extra attribute, how will that be handled? Old way of create() plus set() for the extra attribute, or delete the existing object then create a brand new one?

Question 6: findCurrentBestMatchForGenericObject(), the method looks dynamic. What we need is deterministic processing which matches exactly what orchagent will do (if same operation is to be done there instead), no new unnecessary REMOVE/SET/CREATE, how to guarantee that?

問題4：如何處理兩個屬性完全相同的對象？示例：覆蓋環回RIF和參考底圖環回RIF。VRF和其他物體在同一情況下？
問題5：新版本的軟件調用create（）API，它有一個額外的屬性，如何處理？“為附加屬性創建（）加set（）的舊方法，還是刪除現有對象，然后創建一個全新的對象？”？
問題6:FindCurrentBestMatchForgericObject（），方法看起來是動態的。我們需要的是確定性處理，它與orchagent將要做的事情完全匹配（如果要在那里執行相同的操作），沒有新的不必要的移除/設置/創建，如何保證？

Orchagent and network application layer processing

除了libsaireis接口上create/set/remove操作的idempotency 支持外，本方案需要與方案1中相同的處理，如原始數據恢復和每個應用程序根據需要刪除appDB陳舊數據。
一種可能但卻是一種極端的解決方案是：在應用程序重新啟動時，始終刷新所有相關的appDB表，甚至整個appDB，并讓每個應用程序從頭重新填充新數據。然后，將新數據集向下推到syncd。syncd執行舊數據和新數據之間的比較邏輯。

Approach evaluation

Advantages

基于SAI對象模型的泛型處理。
不需要更改libsairedis庫的實現，也不需要在orchagent層恢復OID。

Concerns/Issues with this approach

syncd中的高度復雜邏輯
與syncd緊密結合的上層應用程序的熱重啟。
必須處理來自SAI對象模型的各種轉角情況以及SAI對象模型本身的更改。

Open issues（未決問題）

如何在docker級別進行軟件升級的版本控制？

Show version命令能夠檢索每個docker的版本數據。進一步的擴展可能就是基于此。

root@PSW-A2-16-A02.NA62:/home/admin# show version SONiC Software Version: SONiC.130-14f14a1 Distribution: Debian 8.1 Kernel: 3.16.0-4-amd64 Build commit: 14f14a1 Build date: Wed May 23 09:12:22 UTC 2018 Built by: jipan@ubuntu01Docker images: REPOSITORY TAG IMAGE ID SIZE docker-fpm-quagga latest 0f631e0fb8d0 390.4 MB docker-syncd-brcm 130-14f14a1 4941b40cc8e7 444.4 MB docker-syncd-brcm latest 4941b40cc8e7 444.4 MB docker-orchagent-brcm 130-14f14a1 40d4a1c08480 386.6 MB docker-orchagent-brcm latest 40d4a1c08480 386.6 MB docker-lldp-sv2 130-14f14a1 f32d15dd4b77 382.7 MB docker-lldp-sv2 latest f32d15dd4b77 382.7 MB docker-dhcp-relay 130-14f14a1 df7afef22fa0 378.2 MB docker-dhcp-relay latest df7afef22fa0 378.2 MB docker-database 130-14f14a1 a4a6ba6874c7 377.7 MB docker-database latest a4a6ba6874c7 377.7 MB docker-snmp-sv2 130-14f14a1 89d249faf6c4 444 MB docker-snmp-sv2 latest 89d249faf6c4 444 MB docker-teamd 130-14f14a1 b127b2dd582d 382.8 MB docker-teamd latest b127b2dd582d 382.8 MB docker-sonic-telemetry 130-14f14a1 89f4e1bb1ede 396.1 MB docker-sonic-telemetry latest 89f4e1bb1ede 396.1 MB docker-router-advertiser 130-14f14a1 6c90b2951c2c 375.4 MB docker-router-advertiser latest 6c90b2951c2c 375.4 MB docker-platform-monitor 130-14f14a1 29ef746feb5a 397 MB docker-platform-monitor latest 29ef746feb5a 397 MB docker-fpm-quagga 130-14f14a1 5e87d0ae9190 389.4 MB

SONiC中的回滾支持

這是一個一般要求，不限于熱重啟。可能應該為這個主題準備一個單獨的設計文檔。

對控制平面停機時間有什么要求？

目前，在熱重啟期間，對控制平面的停機時間沒有硬性要求。應商定適當的數目。

支持熱重啟的升級路徑

No clear requirement available yet. The general idea is to support warm reboot between consecutive SONiC releases.

目前還沒有明確的要求。總體思路是在連續的SONiC版本之間支持熱重啟。

LibSAI/SDK熱重啟延遲要求

這一層還沒有嚴格的要求。大概是幾秒鐘，比如說10秒鐘？

SAI/LibSAI/SDK的向后兼容性要求？

是的，對于熱重啟支持，向后兼容性是必需的。

對于熱重啟期間的數據平面流量，LibSAI/SDK有什么要求？FDB可以flushed嗎？?

現有數據流在數據平面上沒有丟包。通常，FDB flush應該由LibSAI/SDK的NOS instread觸發。

SONiC支持熱重啟的原則是什么？

其中一個原則就是在每一層/模塊/docker上都有熱重啟支持，每一層/模塊/docker都是獨立的。

總結

以上是生活随笔為你收集整理的SONiC Warm Reboot的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：关于调整部分车站互联网、电话订票起售时间
下一篇：最新最全的免费股票数据接口--沪深A股深