转载

实用VPC虚拟私有云设计原则

在云计算的基础架构领域,没有比从一开始就正确地布局VPC(虚拟私有云)IP地址更重要的事情了。VPC的设计对于系统的伸缩性,容错性以及安全性都有深刻的影响。它也直接影响到基础架构的灵活性:如果你走进了一个死胡同,将来就可能要花费大量的时间做跨子网实例(instance)迁移来释放地址空间。

幸运的是,如果记住了几个原则,正确地布局VPC就容易了。

子网

正确的子网布局是VPC运行良好的关键。子网决定路由 可用区(AZ)的分布和网络访问控制列表(NACLs)。

我观察到围绕VPC子网划分最常见的错误,是像对待数据中心网络那样对待VPC。VPC不是数据中心,不是交换机,更不是路由器,虽然它执行了全部这三项工作。VPC是一种软件定义网络,对大量数据包迁入、迁出和跨AWS区域(region)迁移进行了优化。在发起端捡起数据包,然后在其目的地丢下数据包,就这么简单。

就是由于这个简单性,许多数据中心和网络设备存在的问题在一开始就被解决掉了。

历史回顾:

90年代时,建造数据中心时使用的是10 Mb / 秒的以太网交换机。以太网用地址解析协议(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: <br>    10.0.0.0/18 — AZ A<br>    10.0.64.0/18 — AZ B<br>    10.0.128.0/18 — AZ C<br>    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,曾担任高级咨询师,现为软件开发工程师。

原文链接 :https://medium.com/aws-activate-startup-blog/practical-vpc-design-8412e1a18dcc

如您需要了解AWS最新资讯或是技术文档可访问 AWS中文技术社区 ;如您有更多的疑问请在 AWS技术论坛 提出,稍后会有专家进行答疑。

订阅“AWS中文技术社区”微信公众号,实时掌握AWS技术及产品消息!

AWS中文技术社区为广大开发者提供了一个Amazon Web Service技术交流平台 ,推送AWS最新资讯、技术视频、技术文档、精彩技术博文等相关精彩内容,更有AWS社区专家与您直接沟通交流!快加入AWS中文技术社区,更快更好的了解AWS云计算技术。

( 翻译/彭根禄  责编/王玉平 )

正文到此结束
Loading...