【活动】聊聊VPC——虚拟私有云_InfoQ_传送门
【活动】聊聊VPC——虚拟私有云
VPC即虚拟私有云（Virtual Private Cloud），是一种兼具公有云和私有云优势的解决方案。具体说来，一方面，VPC是在公有云中划分出一块逻辑区域，享受公有云的高弹性、高扩展性以及按需付费等灵活的支付方式。另一方面，VPC采用通过专用的数据通道，通过隔离的网络提供更安全的数据保护，以及类似私有云的灵活的架构和管理。另外，通过VPC也比较容易的实现混合云。根据Wikipedia上词条的信息，VPC出现在2009年，Google和亚马逊AWS都在这一年发布了VPC服务。Google App Engine的VPC产品叫Secure Data Connector，不过在2013年Google决定放弃这一服务，不再接受新用户注册，而对已有用户的服务也将在2015年关闭。直到现在，亚马逊AWS的VPC服务还活的好好的。当然，提供VPC服务的公司远不只有这两家巨头。专门提供了VPC平台，用户可以选择在使用哪些基础设施服务商，这其中包括Rackspace、DigitalOcean以及亚马逊AWS。HP、VMware、Nimbula（已被Oracle收购）、CloudVelocity（已更名为CloudVelox）也都在提供VPC解决方案。此外，国内许多外包公司和系统集成商也可以提供VPC服务。如果你足够的资金，没有太多技术积累，完全可以将VPC服务交给VMware、Nimbula这样的公司。当然，对于那些预算卡的很紧的公司，自己在云服务商上构建VPC也是明智的选择。如果你是后者，可以在8月19日的14:00-15:00，参与InfoQ在线课堂《VPC——AWS如何定义网络服务》，你不仅能了解到VPC本身的概念和作用，还能进一步掌握在AWS云端定义、管理网络服务的能力，包括：管理子网、网关、网络安全访问列表、路由表、路由规则等。点击【阅读原文】了解课程详细信息
觉得不错，分享给更多人看到
InfoQ 微信二维码
分享这篇文章
InfoQ 最新头条文章
InfoQ 热门头条文章虚拟私有云
VPC（Virtual Private Cloud）即虚拟私有云，在多租户专有云/公有云环境下，为企业提供私网数据中心在云中的延伸，租户可根据自身的业务需要，为自己分配虚拟子网及规划IP地址。保证不修改应用网络策略和IP地址的前提下平滑迁移上云，并支持多租户IP地址和网络策略重叠。华三虚拟私有云方案基于先进的SDN和NFV等技术，实现与Openstack Neutron网络模型的映射。帮助您在华三云中开辟专属隔离的虚拟私有云。您可以在VPC中自由创建虚拟数据中心，自主选择IP地址规划、vNET、vFW、vLB、vRouter等逻辑元素设计自身虚拟私有云中的网络架构。VPC方案的应用场景:云中多租户安全隔离云中多租户东西向及南北向流量安全控制云中多租户IP地址、VLAN使用重叠分享给朋友：通用代码: <input id="link4" type="text" class="form_input form_input_s" value="" />复 制flash地址: 复 制html代码: <input type="text" class="form_input form_input_s" id="link3" value="" />复 制分享视频到站外获取收益&&手机扫码分享视频二维码2小时内有效虚拟私有云功能_VPC下载至电脑扫码用手机看用或微信扫码在手机上继续观看二维码2小时内有效虚拟私有云功能_VPC扫码用手机继续看用或微信扫码在手机上继续观看二维码2小时内有效，扫码后可分享给好友没有优酷APP？立即下载请根据您的设备选择下载版本
药品服务许可证(京)-经营- 节目制作经营许可证京字670号 请使用者仔细阅读优酷、、Copyright(C)2017 优酷
版权所有不良信息举报电话:虚拟私有云：virtual private cloud
虚拟私有云（VPC）是一个公共云计算资源的动态配置池，需要使用加密协议、隧道协议和其他安全程序，在民营企业和云服务提供商之间传输数据。一个VPC基本上把提供商的多租户架构变成单租户架构。 虚拟私有云在概念上类似于虚拟专用网（）。一个VPN可以被用来在公共网，比如互联网上通过专用隧道发送数据，该隧道不能输入未适当加密的数据。安全的附加级别既包括对数据进行加密，也包括对产生和接收网络地址进行加密。
最近更新时间：
翻译：张茜
查看更多评论
敬请读者发表评论，本站保留删除与本文无关和不雅评论的权力。
公共云的好处不断地吸引着企业用户们的关注，近年来其应用也有了显著的增长。但是在公共云大势所趋之下，还有一个企业更青睐的部署模式：虚拟私有云。
当企业架构师们在为云设计应用架构时，他们会面临众多的挑战。这些挑战之一就包括他们无法掌控物理硬件或网络的无所适从感。
在众多寻求在服务器上运行代码又不想配置服务器的开发人员中，AWS Lambda已经是越来越普及了，而其一系列的新功能也拓展了其应用。
VPC让企业能够快速部署资源并将其整合到现有的IT基础架构中，前提是IT团队可以接受AWS的诸多限制。
企业级IT网站群
TechTarget中国 版权所有
All Rights Reserved, Copyright
TechTarget中国 版权所有
All Rights Reserved, Copyright酷勤网 C 程序员的那点事！
当前位置： >
浏览次数：次
在云计算的基础架构领域，没有比从一开始就正确地布局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地址以后，是否就能公开访问了？不，并非如此。你还需要创建一个路由表，其中默认路由要是互联网网关。然后对一个或多个子网应用该表。之后，这些子网中的所有主机都将继&#8203;&#8203;承路由表。你需要创建一个路由表，将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&#8202;&&#8202;AZ A&br&
10.0.64.0/18&#8202;&&#8202;AZ B&br&
10.0.128.0/18&#8202;&&#8202;AZ C&br&
10.0.192.0/18&#8202;&&#8202;Spare
现在你要决定在每个AZ内部的公共子网，私有子网和备用容量。能够公开访问的主机数量应该远远少于只能内部访问的数量，于是决定将私有子网一半大小的空间分配给公共子网。想要创建一个独立的地址空间，只需继续增加bit。即：
10.0.0.0/18&#8202;&&#8202;AZ A
10.0.0.0/19&#8202;&&#8202;Private
10.0.32.0/19
10.0.32.0/20&#8202;&&#8202;Public
10.0.48.0/20&#8202;&&#8202;Spare
随后，如果你想要在NACL中增加一个&受保护的&子网，只要再次从备用空间中划分出一块即可：
10.0.0.0/18&#8202;&&#8202;AZ A
10.0.0.0/19&#8202;&&#8202;Private
10.0.32.0/19
10.0.32.0/20&#8202;&&#8202;Public
10.0.48.0/20
10.0.48.0/21&#8202;&&#8202;Protected
10.0.56.0/21&#8202;&&#8202;Spare
需要确保你在一个AZ中做过任何事情，都在所有其他AZ中重复一遍：
10.0.0.0/16:
10.0.0.0/18&#8202;&&#8202;AZ A
10.0.0.0/19&#8202;&&#8202;Private
10.0.32.0/19
10.0.32.0/20&#8202;&&#8202;Public
10.0.48.0/20
10.0.48.0/21&#8202;&&#8202;Protected
10.0.56.0/21&#8202;&&#8202;Spare
10.0.64.0/18&#8202;&&#8202;AZ B
10.0.64.0/19&#8202;&&#8202;Private
10.0.96.0/19
10.0.96.0/20&#8202;&&#8202;Public
10.0.112.0/20
10.0.112.0/21&#8202;&&#8202;Protected
10.0.120.0/21&#8202;&&#8202;Spare
10.0.128.0/18&#8202;&&#8202;AZ C
10.0.128.0/19&#8202;&&#8202;Private
10.0.160.0/19
10.0.160.0/20&#8202;&&#8202;Public
10.0.176.0/20
10.0.176.0/21&#8202;&&#8202;Protected
10.0.184.0/21&#8202;&&#8202;Spare
10.0.192.0/18&#8202;&&#8202;Spare
路由表是这样的：
10.0.0.0/16&#8202;&&#8202;Local
0.0.0.0/0&#8202; &&#8202; Internet Gateway
&Internal-only& (ie, Protected and Private)
10.0.0.0/16&#8202;&&#8202;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，曾担任高级咨询师，现为软件开发工程师。
& 相关主题：