<code id="xco5q"><s id="xco5q"></s></code>

  • <object id="xco5q"></object>

    <pre id="xco5q"></pre>
    <strike id="xco5q"></strike><strike id="xco5q"></strike>

        <code id="xco5q"></code>

        網絡解耦: 不只是軟硬件

        October 16, 2018

        對于網絡領域的人來說,解耦已成為白盒交換機的代名詞。 但是解耦的概念實際上比這更廣泛并且可能對整個行業產生深遠的影響。

        在Juniper解耦既是許多計劃背后的戰略重點,又是每個架構決策的工程原理。 它既是開發路線圖的明確組成部分,又是對Juniper工程團隊的隱性指示。

        作為開發以及如何開發的核心,解耦在 Juniper圍繞云,多云,分布式和邊緣云的更廣泛的公司戰略中起著關鍵作用。

        什么是解耦(Disaggregation)?

        盡管該術語并非特定于網絡,但大多數人將解耦等同于白盒運動以及數據中心交換機的硬件軟件分離。 雖然這是解耦的一個范例,但它是對范圍更廣戰略的狹義定義,它忽略了網絡中其他元素也進行解耦的真正價值。

        從最基本的角度看,解耦只是兩個通常集成在一起的組件的分解,其目標是比整體集成的系統在更細的粒度和層次上創造選擇性和靈活性. 如果用戶可以集成和選擇各種系統組件,那么他們就可以構建一個適合其特定目的的獨特系統。

        不止是成本

        在今天的對話環境中,技術目的通常與成本有關系。 例如白盒推進運動主要由降低數據中心交換機成本的愿望所驅動。 但這不是解耦的唯一目標。

        有些人采用解耦是為了優化性能,尤其是為了支持要求低延遲的業務. 比如高頻交易領域就以試圖從交易中節省每一個微秒而臭名昭著. 優化性能的另一個表現是嘗試通過通用管理系統對不同硬件進行管理的運維一致性。

        還有些人可能會利用解耦來優化控制. 對于提供 X即服務的公司,專門而獨特的控制平面會提供獨特的競爭優勢,而其他也購買相同基礎架構的人則無法復制。 在這種情況下,控制平面解耦后可以利用供應商系統之外的可編程接口以獨特的方式精細調整自己的解決方案。

        還有一些人認為解耦是為了安全性。 例如,使用私有加密算法會至關重要,特別是在軍事和情報行動中. 解耦提供了不依賴于運行第三方代碼的黑盒子來實施項目的安全途徑。

        盡管對于大多數人來說,成本無疑是最重要的事情,但解耦實際上是為達成更廣泛目標而采取最適宜途徑的一個有效方法。

        不僅是軟硬件

        現實是耦合的任何兩件事都可以解耦。 例如控制與轉發的分離導致出現了專門為網絡報文轉發優化的芯片. 這種分離不僅僅是硬件和軟件分離, 而且目標也不僅僅是降低成本.

        在當今的網絡設備中,軟件和硬件數據平面之間有著緊密的聯系。 也就是說包處理流水線與底層芯片設計緊密相關,這導致了芯片領域的壟斷。 隨著P4之類的標準逐漸深化,解耦可以有效地使芯片設計與包處理流程分離,從而推動ASIC芯片領域更多競爭,并在交換機和路由器的主要成本因素中創造經濟杠桿。 這是Juniper與Google一起在P4上所做的工作的主要推動力。

        解耦的另一個示例是將網絡控制 (路由選路決策)與網絡操作系統的其余部分分離。 今年早些時候, Juniper宣布支持Facebook的Open / R標準。 允許外部軟件對JUNOS設備路由表進行編程,這樣Juniper有效地分解了以前緊密耦合在網絡操作系統內的子系統。

        甚至還有人以非傳統方式來利用解耦, 比如機框系統中線卡通常固定在機箱內。 Juniper在今年早些時候推出其通用機箱產品時從機箱中解耦了線卡。 因此在插入特定線卡之前,機箱不會成為MX系列或PTX系列平臺。 這使管理員可以利用通用機箱來滿足各種業務需求,且更換線卡即可更改其產品形態.

        解耦的隱藏意義

        解耦還可以對系統設計產生深遠的影響。

        在混合搭配不同組件以創建適合特定需求的解決方案時,通常會出現兩個自然的要求:互操作性和互換性。

        首先,在解耦解決方案中,各個組件必須有清晰的分工界面并可互操作才能協同工作。 為了讓軟件定義的轉發路徑從底層芯片中解耦,軟件和芯片必須可互操作。 這就導致在這兩個組件邊界出現API?,F在很火的P4轉發平面編程語言就是擔任該角色, 其他所有解耦實現也都需要一個類似的接口以實現互操作性。

        其次,如果目標是允許用戶混合搭配不同組件以針對業務目標進行優化,則各組件必須是可互換的. 也就是說管理員必須能夠用組件B替換組件A. 在白盒交換機場景中,只有在網絡操作系統和底層硬件都有多個選項的情況下,經濟杠桿才存在。

        組件的互換性還對組件分界提出了額外的要求: 它們必須是開放的。 如果API是封閉的(專有的或不可公開訪問的), 則無法跨邊界集成其他組件. 這將限制消費者的選擇, 從而抵消了解耦帶來的好處。

        因此在每個組件邊界處都應有一個開放的界面。 無論是管理平面和控制平面之間的NETCONF,交換機軟件硬件之間的參考體系結構,還是軟件和硬件數據平面之間的P4,網絡將基于開放性繼續發展。

        分久必合

        萬事都是矛盾統一的, 分久必合合久必分.

        IT部門不部署子系統. 他們部署必須組合在一起才能工作的諸多組件. 這意味著解耦會導致集成的需求. 集成并非是一件簡單的事情, 即加載不同組件并期望它們能夠正常工作.

        例如在白盒系統中有象 BIOS這樣的底層組件. 但即使使用功能上等效的不同BIOS組件, 系統也可能以完全不同的方式運行。在使用開放的界面, 用戶自由混合搭配組件的情況下,想不執行諸如測試驗證之類的基本集成任務就期望業務能夠正常進行是不切實際的期.

        有很多進行集成的方式。 有些企業可能愿意依靠合作伙伴來提供集成解決方案,而另一些則可能自己承擔. 無論分工如何,希望利用解耦的公司都必須仔細考慮如何處理集成。

        最后,盡管解耦將在多云時代改變網絡世界,但關鍵組件的選擇不太可能大量出現。 由于即使基于標準接口也會導致行為上的細微差別,更可能的結果是只有少量解決方案可能成功服務于市場。

        好的工程設計

        從根本上說,Juniper相信需要在每個層次上進行解耦 – 這只是好的工程. 設計具有良好定義接口的模塊化系統,不僅可以在Juniper內部團隊之 間,而且可以在行業內的不同創新圈子之間進行組件復用和分布式開發。

        Juniper產品提供了很多例證:

        ? Junos OS系統的轉發控制分離
        ? 通過 對JUNOS 的RPD 進程模塊進行可編程實現網絡控制
        ? 通過NETCONF實現網絡管理
        ? 支持OCP硬件標準的白盒交換機
        ? 通過 Juniper 硬件和ONIE 標準支持第三方軟件系統
        ? 機框和線卡分離的通用機箱設計
        ? 通過轉發平面抽象層(AFT)支持
        ? 通過JET APIs實現系統層面控制(比如Open/R)
        ? 支持P4
        ? 支持Sonic

        顯然Juniper 對網絡產品進行解耦有遠大的計劃并在生產環境中進行了廣泛的實現. 最重要的是 Juniper從一開始就堅信要創建基于解耦架構的產品。 隨著商業需求的增加,與之匹配的商業模式也將隨之而來. 這就是為什么Juniper在所有產品線都引入解耦,并繼續將解耦視為多云時代的基石。

        <code id="xco5q"><s id="xco5q"></s></code>

      1. <object id="xco5q"></object>

        <pre id="xco5q"></pre>
        <strike id="xco5q"></strike><strike id="xco5q"></strike>

            <code id="xco5q"></code>