• <noscript id="eom2a"><optgroup id="eom2a"></optgroup></noscript>
    <tt id="eom2a"><small id="eom2a"></small></tt>
    <input id="eom2a"></input>
  • <div id="eom2a"><small id="eom2a"></small></div>
    <td id="eom2a"><small id="eom2a"></small></td>
  • 您的位置:知識庫 ? 云計算

    實用VPC虛擬私有云設計原則

    作者: Nathan McCourtney  來源: CSDN  發布時間: 2017-10-01 14:09  閱讀: 6236 次  推薦: 3   原文鏈接   [收藏]  

      英文原文:Practical VPC Design

      在云計算的基礎架構領域,沒有比從一開始就正確地布局VPC(虛擬私有云)IP地址更重要的事情了。VPC的設計對于系統的伸縮性,容錯性以及安全性都有深刻的影響。它也直接影響到基礎架構的靈活性:如果你走進了一個死胡同,將來就可能要花費大量的時間做跨子網實例(instance)遷移來釋放地址空間。

      幸運的是,如果記住了幾個原則,正確地布局VPC就容易了。

      子網

      正確的子網布局是VPC運行良好的關鍵。子網決定路由 可用區(AZ)的分布和網絡訪問控制列表(NACLs)。

      我觀察到圍繞VPC子網劃分最常見的錯誤,是像對待數據中心網絡那樣對待VPC。VPC不是數據中心,不是交換機,更不是路由器,雖然它執行了全部這三項工作。VPC是一種軟件定義網絡,對大量數據包遷入、遷出和跨AWS區域(region)遷移進行了優化。在發起端撿起數據包,然后在其目的地丟下數據包,就這么簡單。

      就是由于這個簡單性,許多數據中心和網絡設備存在的問題在一開始就被解決掉了。

      歷史回顧:

      90年代時,建造數據中心時使用的是10Mb/秒的以太網交換機。以太網用地址解析協議(ARP)進行廣播,確定交換結構中數據的相應位置。因此,網絡分段與廣播域中主機的數量大致成正比。因此,超過幾百臺主機的網絡段,性能就會降低。再加上IPv4子網公式的反直觀性,導致了在實踐中不同的網段都使用24位的子網。三個字節的地址,在全部約束條件下似乎是最佳選擇。

      這種思維不適用于云環境。VPC既不支持廣播,也不支持多播。就像ARP之于OS,廣播和多播可以非常優雅的使用SDN實現。考慮到這一點,就沒有任何理由將一個VPC劈成一些24位的子網。事實上,不這樣做的重要的原因在于:浪費。因為254(或128或64或32或16)個地址的“中間層”子網,只能有四個中間層主機,其它工作負載都用不到其余的地址。

      相反,如果你有一個多用途的子網,可容納4094個地址的話,那么你可以根據每個末位IP進行自動分組等等工作,這樣一來盡可能的擴大子網就變得十分必要,這樣做可以讓你在龐大的地址池中得以自由地進行動態分配。。

      一般來說,創建一個子網主要出于三個原因:

      1. 不同的主機需要用不同的的路由方式(例如,內網主機與公網主機)

      2.  出于容錯的目的,需要在多個AZ之間分配負載。這項工作應該持續不斷進行。

      3. 特定的地址空間由于安全的原因需要授權NACL(例如,駐留客戶個人身份信息數據庫的網段)

      讓我們依次分析一下這些因素。

      路由

      VPC中的所有主機都可以通過路由與同一個VPC內的其他主機連接。唯一真正的問題在于:允許什么樣的數據包可以在VPC中進出。

      事實上,可以輕松地建立一個禁止任何數據包進入或離開的VPC。只要建立的VPC不存在互聯網網關或虛擬專用網關,就可以有效地將其隔離為孤島了。

      VPC不產生任何網絡流量那還有什么價值。假設,你有一個使用互聯網的應用,在添加了互聯網網關,并為主機指定了一些彈性的IP地址以后,是否就能公開訪問了?不,并非如此。你還需要創建一個路由表,其中默認路由要是互聯網網關。然后對一個或多個子網應用該表。之后,這些子網中的所有主機都將繼??承路由表。你需要創建一個路由表,將Internet網關作為默認路由,然后你需要將該表格應用于一個或多個子網中,之后所有子網內的host都會繼承該路由表屬性。任何指向VPC外被block的IP地址的都需要經過Internet網關,這樣一來你的host就會被賦予回應外部通信的能力;即便如此幾乎沒有應用希望其所有的host都能被公開訪問。

      事實上,完善的安全性決定了最小特權原則。因此任何不是絕對需要外部世界直接訪問的主機,都應不能直接從入口傳送流量。這些主機需要有更高一層不同的路由表。

      一個子網只能有一個路由表(盡管路由表可以應用于多個子網)。如果希望一組主機與另一組主機用不同的路由,就需要創建新的子網,并對其應用新的路由表。

      容錯

      AWS以可用區(Availability Zones(AZ))的形式提供了開箱即用的geographic distribution,每個region至少有兩個AZ。

      子網不能跨越多個AZs。因此,要實現容錯,需要在AZ中平均分配地址空間,并在每一個里面分別創建子網。AZ越多越好:假如你有三個可用AZ,就將地址空間分成四份,并把第四分段作為備用。

      平均劃分地址空間更加明顯的原因,是讓每個AZ的內部布局都是相同的。當創建諸如自動伸縮組等資源時,它們最好是均勻分布的。如果創建的地址塊是不連續的,必然給今后的維護留下了后悔不已的噩夢。

      安全性

      在VPC中,防御措施的第一層已經得到解決:嚴格控制packet的出入。在路由層之上有兩個補充性質的控件:安全組和NACLs(網絡訪問控制表)。安全組是動態的,有橫跨整個VPC的狀態和能力;NACLs是無狀態的(也就是說你需要定義出入端口),靜態的和子網特有的。

      一般來說,如果要在多組管理員之間分配變更控制的權限,就需要上述兩個控件。例如,可能讓系統管理員團隊控制安全組,而網絡團隊控制NACL。這樣一來,任何一方都不可能獨自突破網絡的限制。

      在實踐中,NACLs應該謹慎使用,并且一旦被創建,就少去改動。因為他們是子網特定的,并與IP地址對應的,在此層管理流量的復雜度,將隨著附加規則個數的增加,成幾何級數地增加。

      安全組是完成大部分工作的地方。除了前述的特定場合以外,應盡可能保持安全規則簡單明了,這樣能提供更好的服務。這樣的安全組才是最好的。

      一個例子

      以上只是一組抽象的準則。我想提供一個具體的例子來說明如何將它們結合在一起。

      布局一個VPC最簡單的方法有下列幾個步驟:

      1.  在盡可能多的AZ中平均分配你的地址空間。

      2.  確定你所需要的不同種類的路由,以及每種路由相關的host數量。

      3.  在各個AZ中按照每個路由的需求來創建大小相同的子網,賦予其相同的路由表。

      4. 為了預防任何遺漏,留下一點未分配的空間。(相信我一次。)

      因此在我們的例子中,將創建一個具有外部訪問網絡主機的,標準的n層架構應用。使用的地址空間是10.0.0.0/16。

      最簡單地布局一個VPC地址空間時要忘掉IP范圍,而只從子網掩碼方面考慮。

      以上述10.0.0.0/16地址空間為例。假設希望在美國-西部-2(us-west–2)地點運行全部三個AZ,以使Mongo cluster可以達到一個可靠的值。通過地址范圍實現這個需求是很討人厭的。相反,你可以簡單地說:“我需要四個分塊,三個AZ各對應一塊,另一塊備用。”因為子網掩碼是二進制的,屏蔽碼中每增加一個比特就將空間除以二。所以四個分塊,就要增加兩個比特,16比特將變成四個18比特。

    10.0.0.0/16: 
        10.0.0.0/18?—?AZ A
        10.0.64.0/18?—?AZ B
        10.0.128.0/18?—?AZ C
        10.0.192.0/18?—?Spare

      現在你要決定在每個AZ內部的公共子網,私有子網和備用容量。能夠公開訪問的主機數量應該遠遠少于只能內部訪問的數量,于是決定將私有子網一半大小的空間分配給公共子網。想要創建一個獨立的地址空間,只需繼續增加bit。即:

    10.0.0.0/18?—?AZ A
        10.0.0.0/19?—?Private
        10.0.32.0/19
                10.0.32.0/20?—?Public
                10.0.48.0/20?—?Spare

      隨后,如果你想要在NACL中增加一個“受保護的”子網,只要再次從備用空間中劃分出一塊即可:

    10.0.0.0/18?—?AZ A
          10.0.0.0/19?—?Private
          10.0.32.0/19
                  10.0.32.0/20?—?Public
                  10.0.48.0/20
                      10.0.48.0/21?—?Protected
                      10.0.56.0/21?—?Spare

      需要確保你在一個AZ中做過任何事情,都在所有其他AZ中重復一遍:

    10.0.0.0/16:
        10.0.0.0/18?—?AZ A
            10.0.0.0/19?—?Private
            10.0.32.0/19
                   10.0.32.0/20?—?Public
                   10.0.48.0/20
                       10.0.48.0/21?—?Protected
                       10.0.56.0/21?—?Spare
        10.0.64.0/18?—?AZ B
            10.0.64.0/19?—?Private
            10.0.96.0/19
                    10.0.96.0/20?—?Public
                    10.0.112.0/20
                        10.0.112.0/21?—?Protected
                        10.0.120.0/21?—?Spare
        10.0.128.0/18?—?AZ C
            10.0.128.0/19?—?Private
            10.0.160.0/19
                    10.0.160.0/20?—?Public
                    10.0.176.0/20
                        10.0.176.0/21?—?Protected
                        10.0.184.0/21?—?Spare
        10.0.192.0/18?—?Spare

      路由表是這樣的:

    “Public”
        10.0.0.0/16 ?— ?Local
        0.0.0.0/0? —? Internet Gateway
    “Internal-only” (ie, Protected and Private)
        10.0.0.0/16? — ?Local

      創建這兩個路由表,把它們應用到每個AZ中正確的子網,然后就大功告成了!

      如果團隊中有人擔心空間不足,就給他看這個表:

    16-bit: 65534 addresses
        18-bit: 16382 addresses
        19-bit: 8190 addresses
        20-bit: 4094 addresses

      很顯然, Web 服務器不需要用4000個IP地址。這還不是問題的關鍵,關鍵是此VPC只有那些路由需求。沒有理由在同一個AZ內部,沒有子網有不同的路由需要時,再創建新的子網。

      結論

      適當地應用本文建議的規劃方法,就可以確保不會由于起始的決定,在實施時捆住了手腳。這里談到的一切 - 安全組,自動伸縮,彈性負載均衡,亞馬遜關系數據庫服務,AWS直接連接,甚至更多——這些都可以套用在該模式中。(  / Nathan McCourtney:任職于亞馬遜網絡服務公司AWS,曾擔任高級咨詢師,現為軟件開發工程師。

    3
    0
    標簽:云計算 VPC

    云計算熱門文章

      云計算最新文章

        最新新聞

          熱門新聞

            黄色网_免费在线黄色电影_黄色成人快播电影_伦理电影_黄色片