Amazon Web Services 網路的規模為全球 69 個地區的 22 個區域：美國、歐洲、亞洲、非洲和澳洲。 每個區域最多包含 8 個資料中心 - 資料處理中心。 每個資料中心都有數千或數十萬台伺服器。 網路的設計方式考慮了所有不太可能出現的中斷情況。 例如，所有區域彼此隔離，可達性區域距離數公里。 即使切斷電纜，系統也會切換到備份通道，資訊遺失也將相當於幾個資料包。 Vasily Pantyukhin 將討論該網絡構建的其他原則以及它的結構。
瓦西里·潘秋欣 最初在 .ru 公司擔任 Unix 管理員，在大型 Sun Microsystem 硬體上工作了 6 年，在 EMC 宣揚以資料為中心的世界 11 年。 它自然地演變成私有雲，然後轉移到公有雲。 現在，身為 Amazon Web Services 架構師，他提供技術建議以協助在 AWS 雲端中生活和開發。
在AWS三部曲的前一部分中，Vasily深入研究了實體伺服器和資料庫擴展的設計。 Nitro 卡、基於 KVM 的客製化管理程式、Amazon Aurora 資料庫 - 有關所有這些內容，請參閱資料“」 閱讀上下文或觀看 演講。
本部分將重點放在網路擴展，這是 AWS 中最複雜的系統之一。 從扁平網路到虛擬私有雲的演變及其設計、Blackfoot 和 HyperPlane 的內部服務、嘈雜鄰居的問題，以及最後 - 網路、主幹和實體電纜的規模。 關於這一切都在削減之下。
免責聲明：以下所有內容均為 Vasily 的個人觀點，可能與 Amazon Web Services 的立場不一致。
網路擴充
AWS 雲端於 2006 年推出。 他的網絡相當原始——具有扁平結構。 私有位址範圍對於所有雲端租戶來說都是通用的。 啟動新虛擬機器時，您意外收到此範圍內的可用 IP 位址。
這種方法很容易實現，但從根本上限制了雲端的使用。 特別是，開發將地面專用網路與 AWS 中的專用網路結合的混合解決方案相當困難。 最常見的問題是 IP 位址範圍重疊。
虛擬私有云
事實證明，雲端運算很受歡迎。 現在是時候考慮可擴展性以及數千萬租戶使用它的可能性了。 網路扁平化成為一大障礙。 因此，我們思考如何在網路層面隔離用戶，讓他們能夠獨立選擇IP範圍。
當您想到網路隔離時，您首先想到的是什麼？ 當然 VLAN и VRF - 虛擬路由與轉送.
不幸的是，它沒有起作用。 VLAN ID 只有 12 位，僅提供 4096 個隔離段。 即使是最大的交換器也最多可以使用 1-2 個 VRF。 將 VRF 和 VLAN 結合使用只為我們帶來了幾百萬個子網路。 這對數千萬租戶來說肯定是不夠的，每個租戶都必須能夠使用多個子網路。
我們也根本無力購買所需數量的大型盒子，例如從思科或瞻博網路購買。 有兩個原因：它太貴了，我們不想受到他們的開發和補丁政策的擺佈。
只有一個結論——制定自己的解決方案。
2009 年我們宣布 專有網絡 - 虛擬私有云。 這個名字一直沿用至今，現在許多雲端供應商也使用它。
VPC是一個虛擬網絡 SDN （軟體定義網路）。 我們決定不在 L2 和 L3 層級發明特殊協定。 該網路在標準乙太網路和IP 上運作。 對於透過網路傳輸，虛擬機器流量被封裝在我們自己的協定包裝器中。 屬於租戶VPC的ID。
聽起來很簡單。 然而，仍有一些嚴峻的技術挑戰需要克服。 例如，在何處以及如何儲存有關映射虛擬 MAC/IP 位址、VPC ID 和對應實體 MAC/IP 的資料。 在 AWS 規模上，這是一個龐大的表，應該能夠以最小的存取延遲運行。 對此負責 地圖服務，它在整個網路中以薄層形式傳播。
在新一代機器中，封裝是由 Nitro 卡在硬體層級執行的。 在較舊的實例中，封裝和解封裝是基於軟體的。
讓我們弄清楚它的一般情況是如何運作的。 我們先從L2級別開始。 假設我們在實體伺服器 10.0.0.2 上有一個 IP 為 192.168.0.3 的虛擬機器。 它將資料傳送到位於 10.0.0.3 上的虛擬機器 192.168.1.4。 產生 ARP 請求並將其發送到網路 Nitro 卡。 為簡單起見，我們假設兩台虛擬機器位於同一個「藍色」VPC 中。
映射將來源位址替換為自己的位址，並將 ARP 訊框轉送至映射服務。
映射服務傳回透過 L2 實體網路傳輸所需的資訊。
ARP 回應中的 Nitro 卡將實體網路上的 MAC 替換為 VPC 中的位址。
傳輸資料時，我們將邏輯 MAC 和 IP 包裝在 VPC 包裝器中。 我們使用適當的來源和目標 IP Nitro 卡透過實體網路傳輸所有這些內容。
包的目的地實體機將執行檢查。 這對於防止地址欺騙的可能性是必要的。 該機器向映射服務發送一個特殊請求並詢問：「我從實體機 192.168.0.3 收到了一個發送到藍色 VPC 中 10.0.0.3 的封包。 他合法嗎？
映射服務檢查其資源分配表並允許或拒絕資料包通過。 在所有新實例中，Nitro 卡中都嵌入了額外的驗證。 即使在理論上也是不可能繞過它的。 因此，欺騙其他 VPC 中的資源是行不通的。
接下來，資料被傳送到目標虛擬機器。
映射服務還充當邏輯路由器，用於在不同子網路中的虛擬機器之間傳輸資料。 一切在概念上都很簡單，我不會詳細說明。
事實證明，當傳輸每個資料包時，伺服器都會轉向映射服務。 如何應對不可避免的延誤？ 快取， 當然。
美妙之處在於您不需要快取整個巨大的表。 實體伺服器託管來自相對較少數量的 VPC 的虛擬機器。 您只需要快取這些VPC的資訊。 在「預設」配置下將資料傳輸到其他 VPC 仍然不合法。 如果使用 VPC 對等功能，則有關對應 VPC 的資訊會另外載入到快取中。
我們整理了資料到VPC的傳輸。
黑腳
如果需要將流量向外傳輸，例如傳輸到網路或透過VPN傳輸到地面，該怎麼辦？ 在這裡幫助我們 黑腳 — AWS 內部服務。 它是由我們的南非團隊開發的。 這就是為什麼該服務以生活在南非的企鵝命名。
Blackfoot 解封裝流量並對其進行所需的操作。 資料按原樣發送到互聯網。
使用 VPN 時，資料將被解封裝並重新封裝在 IPsec 中。
使用 Direct Connect 時，流量會被標記並傳送到適當的 VLAN。
超平面
這是一個內部流量控制服務。 許多網路服務需要監控 資料流狀態。 例如，當使用 NAT 時，流量控制必須確保每個 IP:目標連接埠對都有唯一的出站連接埠。 在平衡器的情況下 國家勞工局 - 網絡負載均衡器，資料流應始終定向到相同目標虛擬機器。 安全群組是一個狀態防火牆。 它監視傳入流量並隱式開啟傳出資料包流的連接埠。
在AWS雲中，傳輸延遲要求極高。 這就是為什麼 超平面 對整個網路的效能至關重要。
Hyperplane 建置在 EC2 虛擬機器上。 這裡沒有魔法，只有狡猾。 訣竅在於這些是具有大記憶體的虛擬機器。 操作是事務性的並且專門在記憶體中執行。 這使您可以實現僅數十微秒的延遲。 使用磁碟會扼殺所有生產力。
Hyperplane 是由大量此類 EC2 機器組成的分散式系統。 每個虛擬機器的頻寬為 5 GB/s。 在整個區域網路中，這提供了令人難以置信的太比特頻寬並允許處理 每秒數百萬個連接.
HyperPlane 僅適用於串流。 VPC資料包封裝對其來說是完全透明的。 此內部服務中的潛在漏洞仍會阻止 VPC 隔離被破壞。 以下級別負責安全。
吵鬧的鄰居
還有一個問題 吵鬧的鄰居 - 吵鬧的鄰居。 假設我們有 8 個節點。 這些節點處理所有雲端用戶的流量。 一切似乎都很好，負載應該均勻分佈在所有節點上。 節點非常強大，很難使其過載。
但我們所建構的架構甚至是基於不太可能的場景。
低機率並不意味著不可能。
我們可以想像一種情況，一個或多個使用者會產生過多的負載。 所有 HyperPlane 節點都參與處理此負載，其他使用者可能會遇到某種效能影響。 這打破了雲端的概念，租戶之間沒有能力相互影響。
如何解決鄰居吵鬧的問題？ 首先想到的是分片。 我們的 8 個節點在邏輯上分成 4 個分片，每個分片有 2 個節點。 現在，吵鬧的鄰居只會打擾所有用戶的四分之一，但會大大打擾他們。
讓我們以不同的方式做事。 我們將只為每個使用者分配 3 個節點。
訣竅是將節點隨機分配給不同的使用者。 在下圖中，藍色用戶與其他兩個用戶（綠色和橙色）之一相交。
對於 8 個節點和 3 個用戶，噪音鄰居與其中一個用戶相交的機率為 54%。 藍色用戶正是以此機率影響其他租戶。 同時，也只是其負載的一部分。 在我們的範例中，這種影響至少在某種程度上不會對每個人來說都明顯，但只有三分之一的使用者會注意到。 這已經是一個很好的結果了。
將相交的用戶數量
機率（百分比）
0
企業排放佔全球 18%
1
企業排放佔全球 54%
2
企業排放佔全球 26%
3
2%
讓我們更接近現實 - 讓我們以 100 個節點和 5 個節點上的 5 個使用者為例。 在這種情況下，沒有任何節點相交的機率為 77%。
將相交的用戶數量
機率（百分比）
0
企業排放佔全球 77%
1
企業排放佔全球 21%
2
企業排放佔全球 1,8%
3
企業排放佔全球 0,06%
4
企業排放佔全球 0,0006%
5
企業排放佔全球 0,00000013%
在實際情況中，由於超平面節點和使用者數量龐大，吵雜的鄰居對其他使用者的潛在影響很小。 這個方法稱為 混合分片 - 隨機分片。 它最大限度地減少了節點故障的負面影響。
許多服務都是基於 HyperPlane 建構的：網路負載平衡器、NAT 閘道、Amazon EFS、AWS PrivateLink、AWS Transit Gateway。
網路規模
現在我們來談談網路本身的規模。 2019 年 XNUMX 月，AWS 在以下地區提供服務： 22個地區，還有 9 個正在計劃中。
- 每個區域包含多個可用區。 全世界有 69 個。
- 每個可用區由資料處理中心組成。 總共不超過8個。
- 該資料中心擁有大量伺服器，有些甚至多達300萬台。
現在讓我們對所有這些進行平均，相乘並獲得一個令人印象深刻的數字，反映了 亞馬遜雲端規模.
可用區和資料中心之間有許多光學鏈路。 在我們最大的區域之一，鋪設了 388 個通道，專門用於 AZ 之間的通訊以及與其他區域的通訊中心（轉運中心）的通訊。 總的來說，這讓人瘋狂 5000太比特.
Backbone AWS 專為雲端建置並最佳化。 我們在頻道上建構它 100 GB/秒。 我們完全控制他們，除了中國的地區。 流量不與其他公司的負載共享。
當然，我們並不是唯一擁有私有骨幹網路的雲端供應商。 越來越多的大公司正在走這條路。 這得到了獨立研究人員的證實，例如來自 .
該圖顯示內容提供者和雲端提供者的份額正在成長。 正因如此，骨幹供應商的網路流量份額不斷下降。
我將解釋為什麼會發生這種情況。 以前，大多數 Web 服務都可以直接從 Internet 存取和使用。 如今，越來越多的伺服器位於雲端並且可以透過 加 - 內容分發網絡。 要存取資源，使用者只能透過網路到達最近的 CDN PoP - 存在點。 最常見的是它位於附近的某個地方。 然後，它離開公共互聯網，透過私人骨幹網路飛越大西洋，直接存取資源。
我想知道如果這種趨勢持續下去，10年後網路會發生什麼變化？
實體通路
科學家尚未弄清楚如何提高宇宙中的光速，但他們在透過光纖傳輸光的方法方面取得了巨大進展。 我們目前使用 6912 光纜。 這有助於顯著優化其安裝成本。
在某些地區我們必須使用特殊電纜。 例如，在雪梨地區，我們使用防白蟻特殊塗層的電纜。
沒有人能免於麻煩，有時我們的經脈會受到損害。 右邊的照片顯示了美國一個地區的光纜被建築工人撕裂的情況。 這次事故僅丟失了13個數據包，這令人驚訝。 再說一次——只有13歲！ 系統立即切換到備用通道 - 秤正在工作。
我們快速了解了亞馬遜的一些雲端服務和技術。 我希望您至少對我們的工程師必須解決的任務規模有一些了解。 就我個人而言，我覺得這非常令人興奮。
這是 Vasily Pantyukhin 關於 AWS 設備的三部曲的最後一部分。 在 部分描述伺服器優化和資料庫擴展，並在 — 無伺服器功能和 Firecracker。
上 XNUMX 月，Vasily Pantyukhin 將分享亞馬遜設備的新細節。 他 關於亞馬遜的故障原因和分散式系統的設計。 24月XNUMX日還是有可能的 票價好，然後付款。 我們在HighLoad++等你，快來聊聊吧！
來源： www.habr.com