<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                ??一站式輕松地調用各大LLM模型接口,支持GPT4、智譜、豆包、星火、月之暗面及文生圖、文生視頻 廣告
                # Google 如何創造只有他們才能創造的驚人的數據中心網絡 > 原文: [http://highscalability.com/blog/2015/8/10/how-google-invented-an-amazing-datacenter-network-only-they.html](http://highscalability.com/blog/2015/8/10/how-google-invented-an-amazing-datacenter-network-only-they.html) ![](https://img.kancloud.cn/0d/b9/0db9a0a9a95e12bec3a9ddfcbd541d32_499x234.png) 最近以自己的驕傲而自豪的 Google [宣布了](http://googlecloudplatform.blogspot.com/2015/06/A-Look-Inside-Googles-Data-Center-Networks.html) : > 今天在 2015 年開放網絡峰會上,我們將首次揭示五代內部網絡技術的詳細信息。 從十年前我們的第一個內部數據中心網絡 Firehose 到最新一代的 Jupiter 網絡,我們已經將單個數據中心網絡的容量提高了 100 倍以上。 我們當前的產品-Jupiter 織物-可以提供超過 1 PB / sec 的總 對等帶寬 。 從角度來看,這樣的容量足以使 100,000 臺服務器以 10Gb / s 的速度交換信息,足以在不到 1/10 秒的時間內讀取國會圖書館的全部掃描內容。 Google 的數據中心網絡是使 Google 真正發揮作用的背后的魔力。 但是什么是“雙向帶寬”,為什么重要呢? 早在 [不斷變化的架構中,我們討論了雙向帶寬:新的數據中心網絡將使您的代碼和數據免費](http://highscalability.com/blog/2012/9/4/changing-architectures-new-datacenter-networks-will-set-your.html) 。 簡而言之,雙向帶寬是指 Google 服務器用來相互通信的網絡。 歷史上,數據中心網絡的定位是與用戶交談。 假設某網頁請求來自瀏覽器。 該請求將發送到服務器,并通過僅與其他幾臺服務器(甚至根本沒有服務器)進行通信來制作答復,然后將答復發送回客戶端。 這種類型的網絡稱為面向北方/南方的網絡。 實施請求幾乎不需要內部溝通。 隨著網站和 API 服務的日趨豐富,這一切都發生了變化。 現在,可以進行 [數以千計的](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) 后端請求來創建單個網頁。 令人振奮。 這意味著通信已從與用戶交談的主導轉變為與數據中心內其他計算機的交談。 因此,這些被稱為東西方網絡。 向東方/西方主導的通信方式的轉變意味著數據中心網絡需要不同的 [拓撲結構](https://en.wikipedia.org/wiki/Network_topology) 。 舊的傳統 [胖樹](https://storagemojo.com/2008/08/24/fat-trees-and-skinny-switches/) 網絡設計已經淘汰,需要采取一些新的方法來代替它。 Google 一直處于開發新的豐富服務支持網絡設計的最前沿,這主要是因為他們的指導思想是將 [數據中心視為計算機](http://research.google.com/pubs/pub35290.html) 。 一旦您的數據中心成為計算機,您的網絡就相當于一臺計算機上的 [背板](https://en.wikipedia.org/wiki/Backplane) ,因此它必須盡可能快且可靠,因此遠程磁盤 并且可以像訪問本地存儲一樣訪問遠程存儲。 Google 的工作圍繞著三個有計劃的攻擊計劃:使用 [Clos 拓撲結構](https://en.wikipedia.org/wiki/Clos_network) ,使用 [SDN](https://www.youtube.com/watch?v=ED51Ts4o3os) (軟件定義網絡),并以自己的 Googlish 方式構建自己的自定義設備。 到目前為止,我們對 Google 的網絡設計的了解有限。 Google 研究員和 Google 聯網技術負責人 [Amin Vahdat](http://research.google.com/pubs/AminVahdat.html) 雖然沒有完全訪問權限,但在 精彩演講: [ONS [開放網絡峰會] 2015:星期三主題演講](https://www.youtube.com/watch?v=FaAZAII2x0w) 。 還有一篇論文: [Jupiter Rising:Google 數據中心網絡](http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p183.pdf) 的 Clos 拓撲和集中控制的十年。 為什么要比通常提前發布細節? 谷歌與亞馬遜之間存在真正的競爭,因此他們需要找到引人注目的差異化點。 谷歌希望他們的數據中心網絡就是其中之一。 那么,是什么讓 Google 與眾不同? 整體訊息: * 摩爾定律的終結意味著程序的構建方式正在發生變化。 * Google 知道了。 Google 知道如何建立良好的網絡并實現適當的數據中心平衡。 * 您可以利用 Google 的云平臺(與支持 Google 搜索的平臺相同)的創新和功能來實現繁榮。 * 所以爬上去,網絡很好! 夠了嗎? 也許這不是一個具有廣泛吸引力的信息,但它可能會找到有區別的買家的房屋。 我的演講重點: * **我們不知道如何構建可提供大量帶寬的大型網絡**。 Google 說,他們的網絡提供了 1 Pb / sec 的總二等分帶寬,但事實證明這還遠遠不夠。 為了支持數據中心的大型計算服務器,您需要 5 Pb / sec 的網絡。 請記住,今天整個互聯網可能接近 200Tb / s。 * **在大型群集**上安排作業效率更高。 否則,您會將 CPU 留在一個地方,將內存留在另一個地方。 因此,如果您可以正確地構建系統,那么數據中心規模的計算機將為您帶來確定的規模經濟。 * **Google 利用從服務器和存儲世界中汲取的經驗教訓構建了數據中心網絡系統**:橫向擴展,邏輯上集中化,使用商品組件,從不管理任何單一組件。 統一管理所有服務器,存儲和網絡。 * **I / O 差距很大**。 阿明說必須解決,如果沒有解決,我們將停止創新。 通過分類可以增加存儲容量。 機會是像訪問本地數據中心一樣訪問全局數據中心存儲。 使用 Flash 和 NVM 會越來越難。 閃存和 NWM 的新層將完全改變編程模型。 注意:很遺憾,他沒有擴大這個概念,我非常希望他能這樣做。 阿敏,我們可以談談嗎? 在一個好故事中,您所尋找的是扮演核心身份角色的角色。 在這里,我們看到 Google 運作的獨特愿景來自其在構建可擴展軟件系統方面的豐富經驗而有機發展。 也許只有 Google 才能勇于遵循自己的愿景,并建立與公認的智慧完全不同的數據中心網絡。 這需要巨大的精力。 這造就了一個好故事。 這是我在演講中毫無希望的不足: * 十年來,數百人為這項工作做出了貢獻。 * 自從大約 30 年前將套接字引入 BSD 以來,分布式編程就面臨著同樣的挑戰。 這將改變。 * 隨著摩爾定律的結束,我們對計算的思考方式必須改變,而分布式計算的方式將要改變。 * 計算的關鍵部分以及人們如何構建自己的系統都圍繞存儲。 * 我們已經看到,遵循摩爾定律,存儲容量有了巨大的增長。 * I / O 間隙仍然存在。 處理器與他們需要處理的基礎數據之間的距離正在不斷增加。 * 我們可以認為遍布整個建筑物的磁盤可用于任何服務器。 這是太棒了。 同時,鑒于我們擁有的處理能力,它們正在越來越遠地尋找。 * 分布式計算環境中的大規模下一代閃存仍未開發。 * 在計算的未來意義上,網絡將扮演至關重要的角色。 * 聯網處于拐點。 計算手段將在很大程度上取決于您構建強大網絡的能力。 * 因此,數據中心網絡是關鍵的區別因素。 * Google 建造了建筑規模的計算機。 計算一行一行,存儲一行一行。 * 多年來,Google 建立了軟件基礎架構以利用其硬件基礎架構: * GFS(2002),MapReduce(2004),BigTable(2006),Borg(2006),Pregel(2008),Colossus(2010),FlumeJava(2012),Dremel,Spanner。 * 這些努力中的許多已經定義了當今進行分布式計算的含義。 * 沒有世界一流的網絡基礎架構,您將無法建立世界一流的分布式計算基礎架構。 您如何構建像 GFS 這樣的系統來利用 100,000 個磁盤,而沒有世界一流的網絡將它們整合在一起? * Google 在網絡方面的創新: * Google Global Cache(2006 年):如何交付內容,包括來自世界各地的視頻和靜態內容) * 守望臺(2008) * Freedome:校園級互連 * Onix(2010 年 * BwE(2010) * B4:Google 的軟件定義 WAN,可將全球所有數據中心連接在一起。 它比面向公眾的網絡更大,并且增長速度更快。 * Jupiter(2012):高帶寬數據中心規模聯網 * Andromeda(2014):網絡虛擬化。 我們如何利用我們的基礎網絡基礎架構,并將其拆分成單個虛擬機,以至于它們擁有自己的高性能網絡? 我們如何打開 Goog??le 一直用于其服務(例如負載平衡,DDoS 保護,訪問控制列表,VPN,路由等)的相同類型的網絡虛擬化,以及如何使這些隔離網絡在原始硬件上運行(如果可用) ? * QUIC * gRPC:Google 內部使用的多平臺 RPC,負載平衡,應用程序級流控制,取消調用,序列化,開源,HTTP / 2。 構建分布式服務的良好基礎。 ## 數據中心網絡 * 數據中心網絡與傳統 Internet 網絡不同。 * 由單個組織運營,并且已預先計劃。 必須發現互聯網才能看到它的外觀。 您實際上知道網絡在數據中心中的外觀。 您已經計劃好了。 您建立了它。 因此,您可以集中管理它,而不用隨便發現它。 由于它是在單一組織的控制下,因此您可以運行的軟件可能會大不相同。 它無需與 20 年的歷史遺存進行互操作,因此可以針對您的需要對其進行優化。 * 吸引人們加入網絡的通常是問題的美。 美麗可能意味著這是一個難題。 是否可以將問題定義為更簡單,更可擴展且更容易? * Google 需要一個新的網絡。 大約十年前,谷歌發現傳統的網絡架構,包括硬件和軟件,**無法滿足**的帶寬需求以及數據中心中分布式計算基礎架構的規模。 * 我們可以買嗎? * Google 無法以任何價格購買能夠滿足 Google 分布式系統要求的數據中心網絡。 * 我們可以運行它嗎? * 以箱為中心的部署產生了高**操作復雜性**的成本。 即使 Google 買了他們能買到的最大的數據中心網絡,用于操作這些網絡的模型還是圍繞著具有單獨命令行界面的單個盒子。 * Google 已經知道如何處理成千上萬的服務器,就像它們是一臺計算機一樣,如何處理成千上萬的磁盤,就像它們是一個存儲系統一樣。 必須像管理一千個交換機一樣管理一千個交換機**的想法沒有多大意義,而且似乎不必要地困難**。 * 我們將構建它。 * 受服務器和存儲領域的經驗啟發: **橫向擴展** 。 * 無需弄清楚如何購買下一個最大的網絡或下一個最大的路由器,而是可以像使用服務器和存儲一樣,通過使用**個附加商品元素**來擴展交換和路由基礎結構。 * 當出現需要**插入另一個網絡元素**以提供更多端口和更多帶寬時,為什么不這樣做呢? * 允許 Google 建立橫向擴展數據中心網絡的三個關鍵原則: * **Clos 拓撲結構** 。 這個想法是利用小型商品交換機來構建一個可以無限擴展的無阻塞超大型交換機。 * **商業硅** 。 由于 Google 并未建立廣域網互聯網基礎架構,因此他們不需要龐大的路由表或深度緩沖。 這意味著商業硅芯片可以完成在數據中心中構建基于 Clos 的拓撲的工作。 * **集中控制** 。 軟件代理知道網絡的外觀,設置路由,并對基礎計劃中的異常做出反應。 知道網絡的形狀后,管理網絡要比不斷嘗試發現其外觀要容易得多。 如果要更改網絡,則可以告訴集中控制軟件更改網絡。 * 數據中心網絡的方法也適用于園區網絡,將建筑物連接在一起并連接到廣域網。 B4 和 Andromeda 受到數據中心網絡工作的啟發和啟發,他們多年來一直在練習構建自己的硬件和集中控制基礎結構。 * 在過去 6 年中,數據中心帶寬增長了 50 倍。 * 需要交付給 Google 服務器的帶寬超過了摩爾定律。 * 這意味著要滿足 Google 必須能夠擴展的帶寬需求,就不可能不斷地淘汰舊設備并建立新的網絡。 * 規模驅動架構。 * 當今的典型網絡(不一定是 Google)可能具有 10K +交換機,250K +鏈接,10M +路由規則。 **如此規模的網絡處理方式與規模較小的網絡**根本不同。 * 為什么要建立整個數據中心規模的網絡? * 一些最大的數據中心擁有 10 兆瓦和 10 兆瓦的計算基礎架構。 * 如果您無法大規模調度,則有大量的 **資源擱淺** 。 想象一下需要在共享基礎結構上運行的許多不同的作業。 如果必須在一個群集的邊界內調度作業,并且您有 101,000 個服務器群集,而您有 110,000 個服務器群集,那么如果可以在 10,000 個服務器群集中任意調度,則效率會好得多。 如果您可以將作業放置在 10,000 臺服務器中的任何位置,而不必放在 1,000 臺服務器中,那么這個數字就顯得非常少。 因此,如果可以構建一個網絡以擴展到整個建筑物,那么從計算和磁盤上獲得的效率將更高。 這些最終成為主要成本。 該網絡可能非常便宜,并且可以成為計算和存儲的促成因素。 * “資源擱淺”是指將一個 CPU 留在一個地方,而將內存留在另一個地方( [源](http://jturgasen.github.io/2014/10/26/tech-takeaway-012-cluster-management-at-google/) )。 * 平衡您的數據中心。 * 一旦達到建筑物的規模,就必須確保提供足夠的帶寬。 * 不平衡的數據中心缺少**某些資源,這限制了您的價值**。 如果一種資源稀缺,則意味著其他一些資源處于閑置狀態,這會增加您的成本。 * 通常,在數據中心規模上,最稀缺的資源是網絡。 由于我們不知道如何構建可提供大量帶寬的大型網絡,因此網絡配置不足。 * 帶寬。 阿姆達爾還有另一部法律。 * 對于并行計算,每 1 Mhz 計算需要 1 Mbit / sec 的 IO。 * 舉例來說,僅在您附近的未來數據中心中,計算服務器具有 64 * 2.5 Ghz 內核,然后為了平衡每個服務器大約需要 100 Gb / s 的帶寬。 這不是本地 IO。 本地 IO 無關緊要。 您需要訪問數據中心范圍的 IO。 數據中心可能有 5 萬臺服務器; 100k + IOPS 的閃存存儲,100 毫秒的訪問時間,PB 級存儲; 將來,其他一些非易失性存儲器技術將具有 1M + IOPS,10 微秒的訪問時間和 TB 的存儲量。 * 因此,您將需要 5 Pb / s 的網絡和具有相應功能的交換機。 即使超額預訂比率為 10:1,這也意味著您將需要 500Tb / s 的數據中心網絡來接近平衡。 從角度來看,一個 500Tb / s 的網絡比今天的整個 Internet 容量更大(可能接近 200Tb / s)。 * 延遲。 為了實現存儲基礎架構分解的目標,您需要可預測的低延遲。 * 磁盤速度很慢,訪問延遲為 10 毫秒,因此很容易使它們看起來很本地。 網絡比這快。 * Flash 和 NVM 困難得多。 * 可用性。 您的計算價值很高,需要不斷引入新服務器,需要將服務器升級到 1G-> 10G-> 40G-> 100G->? * 無法拆除建筑物以進行升級。 投資太大了。 刷新網絡和服務器必須保持不變。 舊的必須與新的一起生活,而不能完全中斷很大的容量。 * 擴展網絡無效。 無法在遍布整個數據中心的網絡上進行焦土升級。 * Google Cloud Platform 建立在支持 Google 規模,性能和可用性的數據中心網絡基礎架構上。 這是向公眾開放的。 希望下一個出色的服務可以利用此基礎結構而無需發明它。 * 關鍵的挑戰是在提供隔離的同時打開硬件的原始容量。 ## 軟件定義的網絡 * 網絡是實現下一代計算機體系結構的關鍵因素。 SDN 將扮演關鍵角色。 * SDN 是關于抽象并管理復雜性的軟件 [控制平面](http://sdntutorials.com/difference-between-control-plane-and-data-plane/) 。 這是要超越框框。 這是關于將網絡接口更改為標準協議而不是標準協議,而是關于管理復雜性,將其隱藏并可以使 10,000 臺交換機看起來像一個的軟件控制平面。 * 硬件將在那里。 您如何管理它,就像它是一個大實體一樣? 這就是服務器端,存儲端和網絡端的問題。 * Google 開始了,每個人都開始使用四柱集群網絡來構建數據中心網絡。 網絡的大小和帶寬由他們可以購買的最大路由器決定。 當需要更多容量時,他們需要使用更大的路由器來構建另一個數據中心網絡。 * 圍繞 Clos 拓撲的方法是使用商用交換芯片,并構建超過 5 代的網絡,如下所示: ## ![](https://img.kancloud.cn/11/5d/115d59f6cac892e1dd8c7632c53f1576_638x306.png) * 基于 Clos 的分層拓撲結構表示在 Clos 拓撲結構中利用了商戶硅片,可在建筑物規模上提供高帶寬。 為機架式交換機頂部供電的同一交換機芯片將服務器連接在一起,也為聚合模塊供電,這些聚合模塊可在一定數量的機架之間提供連接。 相同的硅為將邊緣聚合層連接在一起的脊柱層提供動力。 * 十年前,總帶寬為 2 兆比特/秒。 最新一代的 Jupiter 結構提供 1.3 Pb / s 的帶寬。 他們的 Jupiter Superblock 交換機提供 80Tb / s 的帶寬,它通過 OpenFlow 托管 SDN 軟件堆棧,并受到遠程控制。 交換機將利用 Google 已獲得的余額為所有數據中心供電。 ## 網絡控制 * 早期,Google 面臨著如何構建其控制平面的選擇。 使用現有的服務提供商相關的 OSPF,ISIS,BGP 等堆棧。或者構建自己的堆棧。 * 他們出于多種原因選擇構建自己的。 * Google 十年前考慮的拓撲需要多路徑轉發才能起作用。 為了獲得所需的帶寬,需要在源目標之間建立很多路徑。 現有協議不支持多路徑。 他們是關于連通性的。 查找從源到目的地的路徑,而不是最佳路徑,而不是多個路徑。 * 十年前,還沒有高質量的開源堆棧。 * 所有協議都是基于廣播的,而 Google 希望以此規模運作,他們擔心基于廣播的協議的可擴展性。 * 安裝基于廣播的協議后,您必須配置每個單獨的框以使用它們,而 Google 對此并不滿意。 * 將這一切與從 Google 學到的新常規知識結合在一起,以大規模構建大規模系統: * **邏輯上將** (這并不意味著單個服務器)集中在具有點對點數據平面的分層控制平面的情況下。 看到它一遍又一遍地播放,并且也與數據中心網絡一起播放。 * **向外擴展** 比向上擴展方便得多。 使用 GFS,MapReduce,BigTable 和 Andromeda 可以看到這種情況。 * **集中式配置和管理** 大大簡化了系統的所有方面以及部署。 ## 相關文章 * [在 HackerNews](https://news.ycombinator.com/item?id=10037960) 上/ [木星在 HackerNews](https://news.ycombinator.com/item?id=9977414) 上崛起 * [Google 在大規模定義軟件定義的網絡功能虛擬化方面的經驗](https://www.youtube.com/watch?v=n4gOZrUwWmc) (Google 視頻,2014 年) * [直觀地了解 Google 在全球網絡基礎架構中的創新](http://googlecloudplatform.blogspot.com/2015/08/a-visual-look-at-googles-innovation-in.html) * [撤消 Google 網絡基礎架構上的帷幕](http://googleresearch.blogspot.com/2015/08/pulling-back-curtain-on-googles-network.html) * [Google 數據中心網絡內部的外觀](http://googlecloudplatform.blogspot.com/2015/06/A-Look-Inside-Googles-Data-Center-Networks.html) (Google 博客文章 [在 HackerNews](https://news.ycombinator.com/item?id=9734305) 和 [在 Reddit 上](https://www.reddit.com/r/sysadmin/comments/3a7kwc/a_look_inside_googles_data_center_networks/) ) * [木星崛起:Google 數據中心網絡中 Clos 拓撲和集中控制的十年](http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p183.pdf) (Google 論文,2015 年) * [服務提供商網絡的 SDN 堆棧](https://www.youtube.com/watch?v=ED51Ts4o3os) (Google 視頻,2012 年)。 * [Show 222-介紹 OpenClos 項目](http://packetpushers.net/show-222-introducing-openclos-project/) (來自 Packet Pushers 的網絡實體) * [Google 向其最高機密的數據中心敞開大門](http://www.wired.com/2012/10/ff-inside-google-data-center/) (有線,2012 年) * [不斷變化的體系結構:新的數據中心網絡將使您的代碼和數據自由自如](http://highscalability.com/blog/2012/9/4/changing-architectures-new-datacenter-networks-will-set-your.html) (來自 HighScalability) * [VL2:可擴展且靈活的數據中心網絡](http://research.microsoft.com/apps/pubs/default.aspx?id=80693) (微軟提供的文件) * [Google On Latency Tolerant Systems:由不可預測的部分組成可預測的整體](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) (來自 HighScalability) * [介紹數據中心結構,下一代 Facebook 數據中心網絡](https://code.facebook.com/posts/360346274145943/introducing-data-center-fabric-the-next-generation-facebook-data-center-network) * [云系統管理的實踐:設計和操作大型分布式系統](http://the-cloud-book.com/) (看起來像一本好書) * [十年來 Google 自家的數據中心網絡](http://www.theplatform.net/2015/06/19/inside-a-decade-of-google-homegrown-datacenter-networks/) * [技術要點 012:Google 的集群管理](http://jturgasen.github.io/2014/10/26/tech-takeaway-012-cluster-management-at-google/) * [評估倉庫規模計算中的工作包裝](http://www.e-wilkes.com/john/papers/2014-IEEECluster-job-packing.pdf) * [萬億級計算-事實還是虛構?](http://www.ipdps.org/ipdps2013/SBorkar_IPDPS_May_2013.pdf) * [使數據中心的高效率和低延遲實現協調](http://web.stanford.edu/~davidlo/resources/2015.thesis.pdf) * [ONS 2015:星期三主題演講-Mark Russinovich](https://www.youtube.com/watch?v=RffHFIhg5Sc) -微軟在網絡領域的發展。 這是對現代 Web 規模數據中心網絡的很好描述。 Clos 面料又是新的了。 除了谷歌,其他大公司也在做類似的事情。 例如,Microsoft 正在將 BGP 與 SDN 控制器一起使用。 至少可以說,這是進入數據中心工程的激動人心的時刻! 去年在英特爾開發人員論壇(IDF 2014)上宣布了“ Fabrics 上的 NVMe”協議。 它應該標準化對低延遲 NVM 設備的遠程訪問。 在您寫“今天整個互聯網可能接近 200Tb / s”的地方,您的意思可能是 200Pb / s,對嗎? 一篇關于 CloS 面料的好文章。 Google 的體系結構可能適合搜索,但是 Google 的后端存在可靠性問題,只需瀏覽一下 Google Drive 論壇,所有用戶報告丟失的數據即可。 非常有趣的細節! 亞歷山德羅,我回去檢查。 他肯定說大約在 19:26 時,Internet 的速度約為每秒 200 兆位,盡管他說很難知道確切的數字。 @Alessandro Alinone,那條大約 200Tb / s 的線路也把我甩了! 非常好的描述。
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看