當(dāng)前位置：首頁(yè) > 编程资源 > 编程问答 >内容正文

编程问答

SONiC Warm Reboot

發(fā)布時(shí)間：2023/12/8 编程问答 57 豆豆

生活随笔收集整理的這篇文章主要介紹了 SONiC Warm Reboot 小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

原文：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熱重啟的目標(biāo)是能夠在不影響數(shù)據(jù)平面的情況下重啟和升級(jí)SONiC軟件。每個(gè)進(jìn)程/docker的熱重啟也是目標(biāo)的一部分。除了syncd和database docker之外，所有其他網(wǎng)絡(luò)應(yīng)用程序和docker都需要支持非計(jì)劃的熱重啟。
? ? ? ?對(duì)于重啟處理，SONiC可大致分為三層：

網(wǎng)絡(luò)應(yīng)用程序和Orchagent：每個(gè)應(yīng)用程序?qū)⒔?jīng)歷相似的處理流程。應(yīng)用程序和相應(yīng)的orchagent子模塊需要協(xié)同工作，以恢復(fù)原始數(shù)據(jù)并填充熱啟動(dòng)的增量。以路由為例，重啟操作后，網(wǎng)絡(luò)應(yīng)用程序BGP優(yōu)雅地重啟，通過(guò)與對(duì)等方的對(duì)話與最新的路由狀態(tài)同步，fpmsyncd利用BGP的輸入編寫(xiě)appDB程序，并對(duì)除這些路由外的所有舊路由/新路由進(jìn)行處理，不作任何更改。RouteOrch響應(yīng)來(lái)自fpmsyncd的操作請(qǐng)求，并將任何更改向下傳播到syncd。

Syncd:Syncd應(yīng)該在重啟前轉(zhuǎn)儲(chǔ)ASICDB，并恢復(fù)到與重啟前相同的狀態(tài)。恢復(fù)SONiC syncd本身不應(yīng)干擾ASIC的狀態(tài)。它從Orchagent獲取更改，并在必要的轉(zhuǎn)換之后將其傳遞給LibSAI/ASIC。
LibSAI/ASIC:ASIC供應(yīng)商需要確保ASIC和LibSAI的狀態(tài)恢復(fù)到與重啟前相同的狀態(tài)。

用例

In-Service restart

在不影響服務(wù)的情況下重新啟動(dòng)組件的機(jī)制。這假設(shè)組件的軟件版本在重新啟動(dòng)后沒(méi)有更改。在重新啟動(dòng)窗口期間，可能會(huì)有數(shù)據(jù)更改，如新/舊路由、端口狀態(tài)更改、fdb更改。
這里的組件可以是整個(gè)SONiC系統(tǒng)，也可以是運(yùn)行SONiC的一個(gè)或多個(gè)dockers。

Un-Planned restart

所有網(wǎng)絡(luò)應(yīng)用程序和orchagent都希望能夠處理計(jì)劃外重啟，并正常恢復(fù)。由于對(duì)ASIC處理的依賴性，對(duì)syncd和ASIC/LibSAI，這不是必要條件。

BGP docker restart

BGP docker重啟后，可以從BGP對(duì)等方處學(xué)習(xí)新路由，一些已被推下至APPDB和ASIC的路由可能已不存在。系統(tǒng)應(yīng)能清除從APPDB到ASIC的陳舊路由，并對(duì)新的路由進(jìn)行編程。

SWSS docker restart

swss docker重啟后，所有端口/LAG、vlan、接口、arp和route data都應(yīng)該從configDB、APPDB、Linux內(nèi)核和其他可靠來(lái)源恢復(fù)。在重新啟動(dòng)窗口期間可能會(huì)有端口狀態(tài)、ARP、FDB更改，應(yīng)執(zhí)行正確的同步處理。

Syncd docker restart

重新啟動(dòng)syncd docker應(yīng)保持?jǐn)?shù)據(jù)平面完好無(wú)損。重啟后，syncd恢復(fù)對(duì)ASIC/LibSAI的控制和與swss docker的通信。在syncd docker中運(yùn)行的所有其他函數(shù)也應(yīng)該像flexcounter處理一樣恢復(fù)。

Teamd docker restart

重新啟動(dòng)teamd docker不應(yīng)導(dǎo)致link 抖動(dòng)或任何流量損失。數(shù)據(jù)平面上的所有滯后應(yīng)保持不變。

In-Service upgrade

在不影響服務(wù)的情況下將組件升級(jí)到較新版本的機(jī)制。
這里的組件可以是整個(gè)SONiC系統(tǒng)，也可以是運(yùn)行SONiC的一個(gè)或多個(gè)dockers。

Case 1: without SAI api call change

BGP、neighsyncd、portsyncd甚至orchagent等網(wǎng)絡(luò)應(yīng)用程序中都有軟件更改，但這些更改不會(huì)影響到與syncd的接口以及現(xiàn)有數(shù)據(jù)（元數(shù)據(jù)和依賴關(guān)系圖）的組織。在重新啟動(dòng)窗口期間，可能會(huì)有數(shù)據(jù)更改，如新/舊路由、端口狀態(tài)更改、fdb更改。
服務(wù)內(nèi)重啟的所有處理也適用于此。

Case 2: with SAI api call change

Case 2.1 attribute change with SET

新版本的orchagent可能會(huì)導(dǎo)致SET api對(duì)某些屬性使用與以前版本不同的值。或者將調(diào)用一個(gè)新的屬性集。

Case 2.2 Object change with REMOVE

在新的軟件版本中，默認(rèn)情況下可以刪除以前版本中存在的對(duì)象。

Case 2.3 Object change with CREATE

兩種情況：

case 2.3.1 New SAI object

這是在SAI層定義的新對(duì)象，在新版軟件的orchagent處觸發(fā)CREATE調(diào)用。

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

例如，對(duì)象將被創(chuàng)建為具有更多或更少的屬性或不同的屬性值，或者多個(gè)實(shí)例對(duì)象將被替換為聚合對(duì)象。這是最復(fù)雜的場(chǎng)景，如果舊對(duì)象不是葉對(duì)象，那么所有其他依賴于舊對(duì)象的對(duì)象都應(yīng)該被正確清理。

Cold restart fallback(冷重啟回退)

應(yīng)提供通過(guò)SWSS、syncd和teamd dockers配置進(jìn)行冷重啟或熱重啟的選項(xiàng)。如果熱重啟失敗，應(yīng)提供冷重啟的回退機(jī)制。

Proposal 1: Reconciliation at Orchagent

Key steps

Restore to original state

a、 LibSAI/ASIC能夠在不中斷上層的情況下恢復(fù)到重啟前的狀態(tài)。

b、 Syncd能夠在不中斷ASIC和上層的情況下恢復(fù)到重啟前的狀態(tài)。

c、 Syncd狀態(tài)由Orchagent驅(qū)動(dòng)（FDB除外），一旦恢復(fù)，就不需要自己進(jìn)行調(diào)解。

Remove stale date and perform new update

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

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

（ASIC/LibSAI、syncd、orchagent和應(yīng)用程序的狀態(tài)變得一致和最新）

Questions

How syncd restores to the state of pre-shutdown

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

How Orchagent manages data dependencies during state restore

（Orchagent如何在狀態(tài)恢復(fù)期間管理數(shù)據(jù)依賴關(guān)系）

每個(gè)orchagent子例程的構(gòu)造函數(shù)可以正常啟動(dòng)。

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

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

（Orchagent中缺少什么，以便它恢復(fù)到停機(jī)前的狀態(tài)）

Orchagent和application可以在正常啟動(dòng)時(shí)從configDB和APPDB獲取數(shù)據(jù)，但是為了能夠與syncd同步和通信，還需要為每個(gè)鍵類型為sai_object_id_t的對(duì)象提供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

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

當(dāng)屬性第一次發(fā)生更改時(shí)，原始的默認(rèn)映射可以保存在DEFAULT_ATTR2OID_ and DEFAULT_OID2ATTR_ tables表中。這是因?yàn)樵谶€原過(guò)程中，object create可能使用默認(rèn)屬性而不是當(dāng)前屬性。
所有新的更改都將應(yīng)用于常規(guī)ATTR2OID_ and OID2ATTR_ mapping表。
對(duì)于為同一組屬性創(chuàng)建多個(gè)對(duì)象的情況，可以為從屬性到OID的映射分配一個(gè)額外的所有者標(biāo)識(shí)符，因此每個(gè)對(duì)象基于所有者上下文是唯一可識(shí)別的。一個(gè)突出的例子是使用lag_alias作為lag所有者，因此每個(gè)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層，也不會(huì)有什么壞處。
LibSaiRedis接口需要Idempotency 。

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

（如何處理SAI-api調(diào)用在恢復(fù)階段發(fā)生變化的情況）

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

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

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

端口/fdb在重新啟動(dòng)窗口期間可能有新的狀態(tài)通知？可能相應(yīng)的orchagent子例程應(yīng)該對(duì)對(duì)象執(zhí)行g(shù)et操作？

Requirements on LibSAI and ASIC

LibSAI和ASIC應(yīng)該能夠保存所有必要的狀態(tài)關(guān)閉請(qǐng)求與熱重啟選項(xiàng)。在create_switch（）請(qǐng)求時(shí)，LibSAI/ASIC應(yīng)恢復(fù)到預(yù)關(guān)閉的確切狀態(tài)。在整個(gè)恢復(fù)過(guò)程中不應(yīng)影響數(shù)據(jù)平面。一旦恢復(fù)完成，LibSAI/ASIC工作在正常的操作狀態(tài)，它們不知道上層發(fā)生的任何熱重啟處理。希望在LibSAI中支持create/remove/set的idempotency ，但對(duì)于熱重啟解決方案可能不是絕對(duì)必要的。

Requirements on syncd

Syncd應(yīng)該能夠保存所有必要的狀態(tài)關(guān)閉請(qǐng)求與熱重啟選項(xiàng)。重新啟動(dòng)時(shí)，syncd應(yīng)恢復(fù)到預(yù)關(guān)機(jī)的確切狀態(tài)。一旦恢復(fù)完成，syncd工作在正常的操作狀態(tài)，它是不可知的，任何熱重啟處理發(fā)生在上層。

Requirement on network applications and orch data

General requirements

每個(gè)應(yīng)用程序都應(yīng)該能夠恢復(fù)到關(guān)機(jī)前的狀態(tài)。
Orchagent必須能夠保存和恢復(fù)Orchagent創(chuàng)建的對(duì)象的OID，并且對(duì)象key 類型為sai_object_id_t.。其他未由Orchagent創(chuàng)建的對(duì)象可以通過(guò)libsaireis接口的get操作還原OID。
每個(gè)應(yīng)用程序的orchagent子例程可以使用現(xiàn)有的正常構(gòu)造函數(shù)和producerstate/consumerstate處理流，以確保依賴性并填充內(nèi)部數(shù)據(jù)結(jié)構(gòu)。
如果docker僅重新啟動(dòng)swss，則它應(yīng)該能夠直接從appDB恢復(fù)路由和延遲數(shù)據(jù)，因?yàn)閎gp docker和TeamDocker在此場(chǎng)景中不會(huì)將整組數(shù)據(jù)再次提供給appDB。
狀態(tài)恢復(fù)后，每個(gè)應(yīng)用程序都應(yīng)該能夠刪除任何過(guò)時(shí)的對(duì)象/狀態(tài)，并執(zhí)行任何需要的創(chuàng)建/設(shè)置，或者以正常方式處理請(qǐng)求。

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(方法評(píng)估)

Advantages（優(yōu)勢(shì)）

簡(jiǎn)單明了的邏輯，對(duì)于大多數(shù)升級(jí)/重啟案例來(lái)說(shuō)易于實(shí)現(xiàn)。
層/應(yīng)用程序解耦，易于分而治之。
每個(gè)docker都是獨(dú)立的，為swss進(jìn)程和其他網(wǎng)絡(luò)應(yīng)用程序的意外熱重啟做好準(zhǔn)備。

Concerns/Issues with this approach（此方法的關(guān)注點(diǎn)/問(wèn)題）

Orchagent軟件升級(jí)可能很方便，特別是對(duì)于SAI對(duì)象替換的情況，這需要Orchagent使用一次代碼來(lái)處理它們以進(jìn)行服務(wù)內(nèi)升級(jí)。

Proposal 2: Reconciliation at syncd

The existing syncd INIT/APPLY view framework

基本上有兩個(gè)視圖是為熱重啟創(chuàng)建的。當(dāng)前視圖表示關(guān)閉前的ASIC狀態(tài)，臨時(shí)視圖表示重新啟動(dòng)后新的預(yù)期ASIC狀態(tài)。基于SAI對(duì)象數(shù)據(jù)模型，每個(gè)視圖都是一個(gè)有向無(wú)環(huán)圖，all（？）對(duì)象鏈接在一起。

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 等。假設(shè)這些對(duì)象的RID/VID保持不變。問(wèn)題1：如果版本更改后發(fā)現(xiàn)的對(duì)象發(fā)生更改，會(huì)怎樣？

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

視圖比較邏輯
利用對(duì)象的元數(shù)據(jù)，以這些不變量作為錨定點(diǎn)，對(duì)temp視圖中的每個(gè)對(duì)象，從樹(shù)的根開(kāi)始，向下到子節(jié)點(diǎn)的所有層，直到葉子找到最佳匹配。如果未找到匹配項(xiàng)，則應(yīng)在臨時(shí)視圖中創(chuàng)建對(duì)象，這是對(duì)象創(chuàng)建操作。如果找到了最佳匹配，但臨時(shí)視圖中的對(duì)象和當(dāng)前視圖中的對(duì)象的屬性不同，則應(yīng)執(zhí)行設(shè)置操作。精確匹配產(chǎn)生Temp VID到當(dāng)前VID的轉(zhuǎn)換，這也為上層比較鋪平了道路。應(yīng)刪除當(dāng)前視圖中末尾引用計(jì)數(shù)為0的所有對(duì)象，請(qǐng)執(zhí)行“刪除”操作。

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?

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

Orchagent and network application layer processing

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

Approach evaluation

Advantages

基于SAI對(duì)象模型的泛型處理。
不需要更改libsairedis庫(kù)的實(shí)現(xiàn)，也不需要在orchagent層恢復(fù)OID。

Concerns/Issues with this approach

syncd中的高度復(fù)雜邏輯
與syncd緊密結(jié)合的上層應(yīng)用程序的熱重啟。
必須處理來(lái)自SAI對(duì)象模型的各種轉(zhuǎn)角情況以及SAI對(duì)象模型本身的更改。

Open issues（未決問(wèn)題）

如何在docker級(jí)別進(jìn)行軟件升級(jí)的版本控制？

Show version命令能夠檢索每個(gè)docker的版本數(shù)據(jù)。進(jìn)一步的擴(kuò)展可能就是基于此。

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中的回滾支持

這是一個(gè)一般要求，不限于熱重啟。可能應(yīng)該為這個(gè)主題準(zhǔn)備一個(gè)單獨(dú)的設(shè)計(jì)文檔。

對(duì)控制平面停機(jī)時(shí)間有什么要求？

目前，在熱重啟期間，對(duì)控制平面的停機(jī)時(shí)間沒(méi)有硬性要求。應(yīng)商定適當(dāng)?shù)臄?shù)目。

支持熱重啟的升級(jí)路徑

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

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

LibSAI/SDK熱重啟延遲要求

這一層還沒(méi)有嚴(yán)格的要求。大概是幾秒鐘，比如說(shuō)10秒鐘？

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

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

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

現(xiàn)有數(shù)據(jù)流在數(shù)據(jù)平面上沒(méi)有丟包。通常，FDB flush應(yīng)該由LibSAI/SDK的NOS instread觸發(fā)。

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

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

總結(jié)

以上是生活随笔為你收集整理的SONiC Warm Reboot的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。

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