隨著數據中心升級到100Gbps的速度逐漸加快，以支持對速度和高性能工作負載的需求，他們將需要在這個過程中和之后保持網絡的可見性和安全性，以防止瓶頸和威脅。然而，許多安全和性能工具不能以100Gbps的速度攝取數據，這就留下了可被網絡犯罪分子利用的盲點。可見性差距也增加了排除故障和最大限度地提高性能所需的時間和精力，并確保終端用戶擁有卓越的體驗，最佳做法是在將數據平面升級到100Gbps之前，確保監控平面具有這種能力。

企業有效地連接這些數據速率的一種方法是使用兩層監控拓撲結構。讓我們討論一下這種方法何時合適以及如何實施。

企業為何應該使用兩層監控拓撲

兩層可觀察性拓撲結構將在幾個方面給企業帶來好處，特別是當許多網絡端口被監控時。主要的好處是：

將核心網絡與工具/工具軌道隔離開來，以便經紀公司能夠以正確的數據速率提供正確的數據。

通過將數據包的獲取和聚合與數據包的交付分開，優化成本。這使IT部門能夠將數據包處理能力放在需要的地方。

將核心網絡與工具/工具軌道隔離，使IT部門有更大的自由，可以在一定程度上獨立地升級核心網絡。工具往往會隨著時間的推移以交錯的方式升級，因為供應商會把他們各自的工具升級到最新版本。將它們從核心網絡中分離出來，可以讓IT部門在不耽誤核心網絡升級的情況下適應這種情況。

下面列出的數據包處理功能的大部分高級處理都是面對接收設備（即工具/工具軌道）進行的。用戶控制的數據包大小和分配也延長了工具的使用壽命和對它們的投資。實時數據包處理使用戶能夠控制數據包的大小和分配，因此，接收設備通過接收它們需要的確切數據，以最大的效率運行。

數據包處理的特點是以正確的數據速率向正確的工具提供正確的數據，包括。

重復數據刪除

過濾

復制

負載均衡

數據速率調整

拼接

剝離

如何創建一個

現在你知道了部署兩層網絡數據包觀察平面有幾個好處，下面是如何建立一個兩層網絡數據包觀察平面，如下圖所示。

很多人將DevOps和云計算混為一談，但其實它們是IT中兩個不同的工作角色和領域，雖然它們確實具有相關性。并且，其中一個完全有可能獨立于另一個而存在-盡管這并不實際。

對這二者等混淆部分源于它們之間關系密切。例如，DevOps軟件不必放在云端，但它通常在云端。并且，DevOps和CloudOps都與快速變化且經常重疊的IT部分相關聯。

這種變化速度（加上圍繞這些類型角色的炒作和流動性）為有職業頭腦的人帶來不斷變化的目標，使他們很難確定針對云計算與DevOps角色的必要技能和培訓。在某個企業談論的內容可能與另一個企業完全不同。對于試圖入門的人來說，這可能會令人抓狂。

盡管如此，這些職位仍是備受追捧的高薪職位。對于那些希望在職業生涯中邁出下一步的人來說，非常重要的是，了解這些角色在IT企業中的位置以及它們如何影響你的職業生涯。

DevOps

DevOps結合了開發和運維的術語，并反映了一組側重于協作的實踐。這里的目標是簡化軟件從編程階段到部署階段的過程，與更傳統的軟件部署階段相比，速度更快，質量更高。

你可能會認為DevOps是全新的角色，并且與程序員或運維角色完全不同，但事實并非如此。DevOps人員需要知道如何做到這兩點，以及自動化和編排。

具有開發人員基礎的人員需要增加運維經驗和能力，包括學習自動化，但這可通過培訓實現。另一方面，純粹的運維人員需要通過編碼和自動化培訓，才能支持理想的DevOps角色。

請記住，DevOps不僅僅是不同任務的簡單組合;它合并了兩個不同的角色。你需要真正付出努力才能實現這種轉變，盡管這適合那些具有現有編程技能的人。這并不是說，如果你來自更傳統的管理背景，則不可能成為DevOps，但是你必須認清你所需投入的時間和精力。

云計算

另一方面，云管理員（cloud admin）就是：云管理員（cloud administrator）。擔任此角色的IT專業人員可能知道如何編寫代碼，但他們會在自動化和編排階段使用這些技能;他們不編寫原始源代碼。因此，雖然云管理員需要了解開發人員和DevOps的需求，但這主要取決于這與核心云服務的關系。

云管理員還需要密切關注成本。云管理員做出的每個決定都會對每月賬單產生真正的影響，如果你的公司想要控制其支出，這會很快引起關注。這為云管理員的角色添加了會計或業務管理元素—DevOps 職位中不存在的工作職能。

DevOps與CloudOps：主要區別

考慮到每個角色的靈活性，你不可能了解每個角色的所有信息，因此初學者可能希望專注于這種靈活性。

對于DevOps角色，員工可能會使用少量但一致的工具集。由于項目從開始到結束的流動性，日常任務是很靈活。DevOps工程師可能在午餐前編寫代碼，并在午餐后不久支持該應用程序。

對于云管理員而言，這種流動性與云本身有關，其中不斷添加新功能和服務。當企業使用多個平臺時，這會進一步復雜化。上午管理員可能會花時間在 AWS 上，而下午可能會花在Microsoft Azure或Google Cloud上。

無論你選擇哪條路徑，你都必須了解IT孤島不復存在。你不僅必須掌握多種技術，而且還必須能夠快速更換它們。

盡管如此，在這些變化的角色中，有一件事可以成為你的支柱：DevOps 和云管理基于自動化和編排來完成工作。了解Kubernetes和Terraform等工具以及如何使用它們來擴展和加速IT運營。

有時是從簡單的事情開始，并產生微小但不斷增長的影響。從自動化常見任務開始，使用Ansible等工具進行重啟或常見維護，并隨著你不斷學習擴展工作。即使是學習簡單的PowerShell或Python腳本也能幫助你深入探索。不要期望你的數據中心內的所有東西都能立即自動化。從基本級別的自動化和編排開始，如果你這樣犯錯，這將產生很小的影響。

這可能不是每個角色的主要部分，但這是每個角色都需要的共同部分。對于希望擔任DevOps或云管理員角色，但不確定哪一個最適合的人來說，這可能是理想的起點。

從圖中可以看出，使用了兩個網絡數據包經紀人（NPB）;一個用于 “聚合”，通過TAP和跨度端口獲取數據包，一個用于 “分發”。通常情況下，要觀察/監測的端口數量超過了數據包被傳送到的端口數量。聚合級數據包經紀商通常有較少的功能和較多的輸入和輸出端口，這就是為什么它們被用于采集以獲得成本效益。分布級數據包經紀商的功能更多，因此成本也更高;它們的輸入和輸出端口也往往更少，這就是為什么它們被更少地部署。

理想情況下，網絡數據包采集應以高達100Gbps的數據速率進行。因為每跳增加了性能數據的偏差，最好是觀察這些信息盡可能接近源，所以另一個理想的能力aggregation-class包代理添加高分辨率時間信息（例如，時間戳）傳入的數據包，以及觀察微爆發等性能指標。聚合代理之所以被恰當地命名為聚合代理，是因為它們所做的不僅僅是復制并轉發數據包。它們實際上聚合了包，減少了包流的數量。這使得使用具有更少輸入和輸出端口的分發類包代理成為可能。根據所涉及的網絡和IT的需求，聚合類包代理還可以將包直接交付到其他目的地，例如捕獲到磁盤的解決方案。然而，分發類包代理執行大部分的包傳遞。

分而治之

在需要的地方應用正確的網絡分組代理特性、功能和端口密度是將可見性需求劃分為兩個層的一種經濟有效的方法。

這就是兩層網絡監控拓撲的“原因”和“方式”。由于以網絡為中心的可見性是至關重要的，IT部門應該確保在升級核心網絡或工具時他們的可見性不會受到影響。兩層拓撲提供了獨立升級核心網和各種安全和性能工具的自由。
責編AJX