SD-WAN Nokia-Nuage Networks 收集器架構與技術洞察/特性手冊

通道鏈結類型或傳輸類型考量

對於 Nokia-Nuage ，只會考量兩種傳輸類型。

• 網際網路
• 內部網路 (網際網路無法使用)

範例

NPM 通道/探測通道物件及其物件計數關係

• Nokia-Nuage 通道是基於不同 Network Performance Measurement (NPM) 類別的探測器。 下列每一個組合都可以根據 NPM 類別具有多個探測器。

  • 原始裝置
  • 來源埠
  • 目的地裝置
  • 目的地埠

• 每一個 NPM 類別探測都有自己的 jitter、 latency及 loss percentage度量值。

• 通道/探測物件-命名慣例為
  <Source Device>::<SourceUplink>→<Destination Device>::<Destination Uplink>::<NPM Group>

• 如果有 N 個 NPM 類別，且所有類別都連接至相同的 來源 及 目的地 裝置，則每個唯一鏈結都有 N 個探測物件。

• 如果您有 3 個不同的 NPM 類別作為物件計數，則探測也會乘以 3。

NPM 層次物件群組

根據「NPM 探測」的通道物件命名，會使用根據 NPM 名稱的「物件群組」規則來建立 NPM 群組。

流程資料 APM 與通道資料 NPM

• 來自 elasticsearch 的 Flowstats 資料具有與 應用程式效能測量 (APM)相關的 APM 群組。

• elasticsearch 中的 Probestats 資料具有兩種類型的資料點，以 APM 或 NPM 群組為基礎。

  • 目前，對於僅限 Nuage-only ，通道物件建立會考量 NPM 群組型 Probestats。

• APM 和 NPM 群組是 虛擬化服務目錄 (VSD) 中的兩個個別實體，而且即使它們具有相同的名稱也不相同。

  範例

  
  

介面及物件命名的裝置/埠 /VLAN 概念

• 對於 Nokia-Nuage ，每一個裝置都是一個 NSGateway。
• 每一個 NSGateway 都可以有多個 NSPort。
  • NSPorts 可以是 NETWORK 及 ACCESS。 在建立介面時，會考量 NETWORK 埠。
    • 每一個 NSPort 都可以有多個 VLAN ，且每一個 VLAN 都有唯一的 VLAN 號碼。
      • 每一個 VLAN 都有特定的鏈結類型傳輸- 網際網路 或 其他。
• 每一個 VLAN 都視為裝置介面物件類型的介面。
• 在具有 <NSPort-Name>::<VlanID> 的裝置下完成裝置命名

網域、子網路及 vPort 概念的 LAN 聚集

• Nokia-Nuage 裝置在邏輯實體下隔離，例如，

  • 網域 (domain)
  • 區域
  • 子網路 (subnet)

• 每一個企業都可以有多個網域 /VPN。

  • 每一個網域可以有多個區域。
    • 每一個區域可以有多個子網路。
      • 每一個子網路都與 NSgateway相關聯。
      • 每一個子網路可以鏈結至一或多個 vPort 物件。
        • vPort 是基本原始物件，並且使用 Nuage_Vport 索引從 Elasticsearch 取得資料。

• 聚集功能可用於網域及子網路層次。 物件類型與裝置介面相同。

• 子網路層次聚集物件位於與子網路相關聯的個別裝置下。

• vPort 層次原始物件位於其各自的裝置下。

• 網域是比裝置更大的實體。 對於網域層次物件，會使用 <tenant name>建立個別虛擬裝置。

• 對於網域分組，子網路層次基於「物件群組」，以提供從網域到子網路的往下探查報告。

來自 VSD 的警示執行器及 AMQP 支援

• 對於警示，「虛擬化服務目錄」VSD 提供對 AMQP 匯流排的支援， VSD 會為其公開埠 5672。
• 警示的連線也可以使用 JMS 來完成。 不過，目前 AMQP 並未使用這種類型的連線。
• Alarm Runner 儲存器持續執行。 其他儲存器會作為 cronjob的一部分執行。
• 對於 AMQP 連線，會使用可延續連線。 透過每一個個別連線， VSD 會為連線提供 10 分鐘延續性。 這有助於在連線中斷最多 10 分鐘時取得警示資料。 這次公佈，警示資料會遺失。

Nokia-Nuage 中的事件與警示

具有/不具有 Elasticsearch 支援的裝置性能

• Nokia-Nuage versions <= 5.3.3 do not provide support for Nuage_Sysmon index on Elasticsearch. Due to this, device health data is fetched from VSD for versions <= 5.3.3.
• Nokia-Nuage 版本> = 5.4.1 包含具有 Nuage_Sysmon 索引的 Elasticsearch 資料，以及裝置資源統計資料與 VSD 的資料。
• 在部署 Nokia-Nuage 收集器時， es_device_health 旗標可以設為 true 或 false。 當旗標設為 true 時，會從 Elasticsearch 提取資料，否則會從 VSD 提取資料。

BW-up 及 BW-down Interface Indicators-與 VSD 速率限制器設定檔的關係

• 每一個 VLAN 都有附加的「QOS 原則」。 每個 QOS 原則都與多個速率限制器設定檔相關聯。

  • 在所有相關的速率限制器設定檔中，正在選擇母項速率限制器設定檔。

• 速率限制器設定檔的「確定的資訊速率」用於 bw_up 和 bw_down 指示器，幾乎是常數，直到 VSD 設定檔中變更為止。

  
  

對 SevOne NMS 大小的 30 秒資料點影響

• SevOne NMS 大小調整是根據每 5 分鐘取得 1 個資料點來設計。
• 對於 Nokia-Nuage ，依預設， Elasticsearch 每 5 分鐘提供 10 個資料點，即每一個物件的 30 秒資料點。 因此， SevOne NMS 調整大小會作為 NMS 中的儲存體受到影響。 SevOne Data Insight 及流程資料的效能及聚集也會受到影響。

裝置名稱/物件名稱對客戶友善的主機名稱

• 裝置說明欄位可用來儲存 VSD 中裝置的對客戶友善主機名稱 (CFHN)。
• 目前， SevOne NMS 中的裝置替代名稱是由 CFHN 移入。

拓蹼在 Redis 快取中更新及儲存對映，以避免頻繁呼叫 VSD

• 來自 VSD 的所有必要拓蹼資訊都儲存在 redis 快取中，以避免頻繁呼叫 VSD。
• 每 30 分鐘，當 CREATE DEVICE 儲存器執行時，會透過對 VSD 進行呼叫來更新 redis 快取。
• 如果有任何儲存器在 CREATE DEVICE RUNNER 之前執行，且資料不存在於 redis中，則會從 VSD 提取必要的資料。
• 為了避免部署期間快取中遺漏的案例，依預設會在 INSTALLER 之後執行 CREATE DEVICE RUNNER。

集合偏移配置及影響

有時，在 VSD 移入 Elasticsearch 節點之前， Nokia-Nuage 收集器會先收集資料。 亦即，如果現行時間為 T，則 VSD 至 Elasticsearch 資料移入可以從 T 執行至 T + T1 秒或分鐘。

範例

作為上述的一部分，可以在部署時配置收集器偏移變數 collection_offset(以秒為單位)。 收集器在延遲模式下執行的持續時間 (以秒為單位)。 預設值為 0 秒，表示收集器將在現行時間執行。 變數 collection_offset 可以由使用者配置。 它值集適用於所有租戶; 它不是租戶特定的。

在某些情況下，變更集合偏移可能會有一些影響。

Scenario# 1: 新偏移小於前一個偏移

晚上 9:00 ，收集發生在晚上 8:45-晚上 8:55。 將偏移從 5 分鐘變更為 2 分鐘。 亦即，

• 舊偏移: 5 分鐘
• 新偏移: 2 分鐘
• 輪詢頻率: 10 分鐘

@ 9:10 pm ，收集發生在 8:55 pm-9:08 pm (亦即 9:10 pm-2 minutes = 9:08 pm); 資料收集的時間為 13 分鐘，超過可支援且應該運作的輪詢頻率。

Scenario# 2: 新偏移大於前一個偏移

晚上 9:00 ，收集發生在晚上 8:45-晚上 8:55。 將偏移從 5 分鐘變更為 8 分鐘。 亦即，

• 舊偏移: 5 分鐘
• 新偏移: 8 分鐘
• 輪詢頻率: 10 分鐘

@ 9:10 pm ，收集發生時間為晚上 8:55-9:02 (亦即，晚上 9:10-8 分鐘 = 晚上 9:02); 資料收集時間為 7 分鐘，小於可支援且應該運作的輪詢頻率。

Scenario# 3: 新偏移設為超過輪詢頻率

晚上 9:00 ，收集發生在晚上 8:45-晚上 8:55。 將新的偏移從變更為大於輪詢頻率。 亦即，

• 舊偏移: 5 分鐘
• 新偏移: 15 分鐘
• 輪詢頻率: 10 分鐘

@ 9:10 pm (亦即 9:10 pm-15 minutes = 8:55 pm) ，將不會進行收集，因為收集已從 8:45 pm-8:55 pm 開始。

@ 9:20 pm ，收集發生在晚上 8:55-9:05 (亦即 9:20 pm-15 minutes = 9:05 pm); 資料收集的時間為 10 分鐘，偏移為 15 分鐘，輪詢頻率為 10 分鐘。

晚上 9 時 30 分，晚上 9 時 05 分至 9 時 15 分 (即晚上 9 時 30 分至 15 分鐘 = 9 時 15 分) 收集。

建立用於從 VSD 提取拓蹼資料並針對流程擴增元移入 redis 的裝置

• 對於 Nokia-Nuage ，流程資料不會直接從裝置推送至流程中繼或擴增元。 JSON 解碼器會使用 Elasticsearch 伺服器中的 index: nuage_dpi_flowstats 來取回它。
• Nokia-Nuage 中的 Flow Augmenter 包含下列元件。

  • 建立裝置 Cron

    • 依預設，它每 30 分鐘作為 cronjob 執行一次。
    • 它會從 VSD 提取拓蹼，並儲存在 redis 儲存器中。
    • 將收集器映像檔用於 Docker 儲存器。

  • JSON 解碼器

    • 正在持續執行儲存器。
    • 包含每個 JSON 解碼器 40,000 個 FPS 容量。
    • 使用 REST API 呼叫，從 JSON 格式的 Elasticsearch 提取資料。
    • 在擴增之後，會將資料傳送至 IPFIX 封包中的 DNC。

  • Redis

    • 容器也是擴增器的一部分，在收集器和擴增器佈置在同一虛擬機器上的情況下是常見的。
    • 如果擴增元單獨部署，則收集器和擴增元的 redis 儲存器都是分開的。
    • redis 用於儲存拓蹼資訊，以根據拓蹼資訊修改部分流程欄位。

多重 JSON 解碼器概念

• 為了增加傳輸量，會使用部署時所需的 JSON 解碼器總數的配置值來部署多個 JSON 解碼器。
• 每一個 JSON 解碼器都有自己的輪詢持續時間的時間片段，其提取資料時不會與另一個 JSON 解碼器發生衝突。
• 每一個 JSON 解碼器都有自己的執行緒作業機制，可從 Elasticsearch 提取資料，並將資料傳送至 DNC。
• 如果 JSON 解碼器總計配置為 3 ，

  • JSON 解碼器 A1 從 T1 提取至 T1 + X 時間

  • JSON 解碼器 A2 從 T1 + X 提取至 T1 + 2X 時間

  • JSON 解碼器 A3 從 T1 + 2X 提取到 T2 時間

    T1 是開始提取的最後一個時間戳記。
    T2 是要提取資料之前的時間。
    X 是根據 JSON 解碼器總計及提取資料的時間間隔所決定的間隙。 i.e., X = (T2 - T1) / <total_json_decoders>
• 每一個 JSON 解碼器最多可以處理 40,000 個 FPS。

Nokia-Nuage 特定流程欄位

有一組特定於 Nokia-Nuage 的欄位，在原始流程資料中新增或修改。

• 流程時間戳記 (4333) -流程時間戳記指出流程資料封包的時間戳記。 時間戳記是該流程封包的實際時間戳記。
• 網域名稱 (4334) -網域名稱欄位代表流程資料網域名稱的說明。 它使用拓蹼資訊中的名稱，在此欄位中提取並移入個別網域說明。
• 來源上行鏈路 (4335) -來源上行鏈路欄位代表埠及 VLAN 號碼的實際名稱。 從流程資料中，取得埠的實體名稱及 VLAN 號碼。 使用拓蹼資訊中的名稱，會移入個別實際埠名稱及 VLAN 號碼。 如果無法使用，則會在欄位中移入 NA。
• 目的地上行鏈路 (4336) -目的地上行鏈路欄位代表埠和 VLAN 號碼的實際名稱。 從流程資料中，取得埠的實體名稱及 VLAN 號碼。 使用拓蹼資訊中的該名稱，會移入個別實際埠名稱及 VLAN 號碼。 如果無法使用，則會在欄位中移入 NA。
• 基礎名稱 (4337) -此欄位根據流程資料。 如果無法使用，則會在欄位中移入 NA。
• 進入頻寬 (4338) -此欄位中移入來自流程欄位的 EgressBytes 。 Nokia-Nuage 流程資料與 LAN 端相關，而 SevOne的 SD-WAN 表示法與 WAN 端相關。 流程資料及 SevOne NMS 中的 egress 及 ingress 位元組會反轉。
• Egress 頻寬 (4339) -此欄位中移入來自流程欄位的 IngressBytes 。 Nokia-Nuage 流程資料與 LAN 端相關，而 SevOne的 SD-WAN 表示法與 WAN 端相關。 流程資料及 SevOne NMS 中的 egress 及 ingress 位元組會反轉。
• HostIP (4340) -此欄位代表從中送出資料作為來源或送入資料作為目的地的實際主機。 對於具有 ingress 位元組的流程資料，它代表「來源 IP」，對於具有 egress 封包的流程資料，它代表「目的地 IP」。

流程欄位 10 和 14 的流程介面輸入/輸出索引產生

• Nuage 流程資料不包含資料來源的介面索引。 具有 SevOne NMS 介面物件和裝置的索引對映需要其他邏輯才能產生它們。
• 作為索引產生的一部分，必須將焦點放在索引上。 索引在相同裝置的不同介面之間必須是唯一的。
• 下列邏輯用來產生索引。

  • 每一個 NSPort 在範圍 0-4096 的裝置內具有唯一實體埠名稱。

  • NSPort 下的每一個 VLAN 在 NSPort 內具有範圍 0-4096 的唯一 VLAN 號碼。

    基於此，會產生唯一的 8 位數號碼，並新增至「物件」說明中的 ifIndex 。 亦即，對於 GigaEthernet2.0 介面，如果實體名稱為 port2 且 VLAN 號碼為 0，則介面 ifIndex 將為 20000。
    
    產生的 ifIndex 用於將在個別 Script 中執行的流程介面管理程式中的 ifIndex 轉換為 ifName 。

基於流場 61 的流場資料和反向對映的流場邏輯

流程欄位 61 是流程方向的標準欄位。 Nokia-Nuage 流程資料與 LAN 端相關，而 SevOne的 SD-WAN 表示法與 WAN 端相關。 存在 EgressBytes 之流程的流程方向視為送入。 呈現 IngressBytes 之流程的流程方向視為送出。

• 具有 EgressBytes -方向-0 的流程
• 具有 IngressBytes 的流程-方向-1

基於流程流程邏輯方向的流程來源及目的地位址

• Nokia-Nuage 流程資料與 LAN 端相關，而 SevOne的 SD-WAN 表示法與 WAN 端相關。 因此，會根據流程的方向來變更流程資料封包的來源端位址。
• 如果流程中具有上方計算方向 1 的流程資料，則流程中的 sourceheader 及 destinationheader 代表流程的實際來源及目的地裝置 IP。
• 如果流程中具有上述計算方向 0 的流程資料，則會反轉流程中的 sourceheader 及 destinationheader ; 標頭中的來源位址代表目的地裝置 IP ，而標頭中的目的地位址代表來源裝置 IP。

流程資料刪除重複資料處理

背景

若要從 Elasticsearch收集流程統計資料，它會使用 Elasticsearch的 search_after 功能，您需要在其中提供提取資料之前的時間戳記。 此外，您還需要提供第二個參數，以避免相同時間戳記上資料記錄之間發生衝突。

查詢範例

{"size": 5000 * * ，"search_after": [1572846005998,<tie_breaker>] ， "sort": [{"timestamp":"asc"}

，{"TotalBytesCount":"desc"}] ， "query": {"bool": {"must": [{"term":{"EnterpriseName":"0Fingles Fries"}} ， {" range ": {" timestamp ":

{"gte":1572846005999,"lt":1572846065999}

}}]}}}

理想情況下，第二個參數必須是唯一的，因此當相同時間戳記有多筆記錄時，它可以協助移動後續查詢的搜尋。

問題

對於流程統計資料， doc_id 欄位對於所有記錄都是唯一的。 不過，使用此欄位會導致 Elasticsearch 伺服器上的大量記憶體需求，且伺服器資源很重。 建議使用其他某個欄位作為仲裁，並附上時間戳記。 目前，使用 TotalBytes計數 作為仲裁，但由於此情況，在 Elasticsearch呼叫邊緣可能會有重複的流程記錄。

目前為止，我們使用 "TotalBytes計數" 作為仲裁，因為 ES 呼叫邊緣可能會有重複的流程記錄。

範例: 假設下列 Elasticsearch 資料

如果查詢的「頁面大小」為 5000 ，

• 在第一個查詢 Q1中，資料是針對時間戳記 T1 (= 450)、 T2 (= 1)、 T3 (= 3000)、 T4 (= 1000) 及 T5(= 549 筆 (共 800 筆記錄)。
• 在下一個查詢中，如果您在下一個查詢中往前移動時間戳記，則可以跳過為 T5 時間戳記 (251 筆記錄) 留下的資料記錄
  ，或者如果從前次接收的時間戳記重新收集資料記錄，則會再次收集前一個查詢中的 549 筆記錄。 這裡沒有其他參數可讓搜尋環境定義保持作用中。

為了克服重複的問題，會重新收集最後一個時間戳記的資料，並捨棄前一個查詢中的最後一個時間戳記。 因此，在上述情況下，如果查詢 Q1 中的 549 筆記錄都具有相同的時間戳記以及相同的 TotalBytes計數，則會捨棄這些記錄。 下一個查詢會針對 DNC 重新提取資料並處理它。

Nokia-Nuage 的提取器與傳送端執行緒

• 提取器執行緒 -執行從 Elasticsearch 伺服器平行流程提取資料的作業。 具有更多提取器執行緒會增加更多平行查詢，並導致針對收集器每秒處理更高資料。
• 傳送端執行緒 -一旦提取器執行緒開始從 Elasticsearch提取資料，它會將資料放入處理佇列。 傳送端執行緒會從佇列中挑選流程資料點，並將它們進一步傳送至 rabbitmq。

依預設，提取器和傳送端執行緒是 2 和 4。 根據資料載入，可以從環境對其進行細部調整。 較高的提取器執行緒會產生高記憶體耗用量。 高傳送端執行緒會增加 CPU 整體的負載。