分享

OpenStack的未来取决于是否拥抱Amazon！

分享

分享

[原文地址可参阅：http://blog.csdn.net/neterpaole/article/details/8826829 ］

1 TRILL/FabricPath/SPB

首先肯定是传统二层网络有哪些困境或者不给力的地方喽：1 STP阻塞掉一半链路，浪费带宽；2 接入交换机MAC地址表空间会过大；3 为了二层互联而设置的三层网管限制了虚拟机的漂移。

关于MAC地址表详细说明一下：

因为传统的二层交换机是通过学习来建立MAC地址表的。怎么学习呢，接入交换机会利用所有接收到的数据桢的源MAC地址来建立MAC表。由于传统二层MAC地址没有层次化概念，那么所有接收到的数据桢的源地址都会被放入MAC表中，导致一台交换机可能会学习到整个网段内的所有二层地址，即便大部分时间只跟其中一小部分人联系。

但是大二层技术则可以减小MAC地址表空间，比如FabricPath采用的就是“基于会话的MAC地址学习”，即只有那些目的地址为本地设备的数据帧的源地址才会被放入FabricPath/TRILL网关的MAC地址表中，其他数据帧的源地址以及广播帧的源地址都不会被学习。

既然二层网络的主要问题就是缺失了控制平面，只做根据MAC地址查表转发的工作，那么TRILL/FabricPath/SPB的主要功能就是在传统二层网络的基础上引入了控制平面，下面单独详述：

1) FabricPath：新增二层帧头，主要包括三个字段：源SwitchID，目的SwitchID，TTL。其中源/目的SwitchID分别两个字节，用于在节点间寻址；TTL主要用于防环。

2) TRILL：新增TRILL头和MAC头，其中TRILL头也是源RBridgeID，目的RBridgeID和TTL，这与FabricPath基本上完全一致。MAC头主要是方便与现有以太网兼容并存。本质上讲，TRILL与当前IP报文转发过程是完全类似的。

3) SPB：与前两者类似，同样采用IS-IS构建独立的控制平面，新增的二层帧头主要由三部分组成：源MAC，目的MAC和S-VID。其中源/目的MAC与TRILL、FabricPath中的出入网关完全类似，指代了这个大二层网络的起点和终点，只不过在SPB网络中的逐跳转发由类似于隧道标识的S-VID实现。这也正是SPB使用PBB（一种MAC-in-MAC技术）的核心思想所在。

2 虚拟接入与虚拟交换机

2.1 首先是为什么需要虚拟交换机，主要两个原因：1) 服务器虚拟化让一个物理服务器上存在多个虚拟机，那多个虚拟机收发数据都从这个物理服务器的网卡上出入，导致单个操作系统与接入交换机端口间是多对一的关系，原来针对单个端口的策略无法部署；2) 服务器管理和网络管理责权不清，互相推诿。

一句话概括就是目前虚拟机同交换机端口之间没有办法直接对应上。

2.2 那为什么仅用简单的虚拟机交换机vSwtich技术又不够呢？

vSwtich技术其实由来已久了，包括软件VEB，如VMware vShpere内置的vSwitch，VMware分布式统一网络接入平台VDS(Virtual Distributed Switch)，与vSphere结合的Cisco Nexus 1000v，开源的Open vSwtich以及硬件的VEB(Virtual Ethernet Bridging)。

但是这些vSwitch也叫VEB存在三个问题：

1) 功能弱。具体说，通常只具有简单的二层转发，缺乏QoS机制和二层安全策略，流量镜像能力差。

2) 功能弱也导致网管人员难以把针对物理端口的策略平滑地迁移到VEB或者vSwtich上来；

3) 由于其管理范围被限制在物理服务器内部，没法在整个数据中心提供针对虚拟机的端到端服务。

因此，就得搞像VN-Tag或者VEPA这种复杂的专门针对DCN的虚拟交换机。

2.3 Cisco VN-Tag

核心思想：VN-Tag的核心思想就是在现有的以太网数据桢的VLAN标识前面增加一个专用标记字段VN-Tag，这个VN-Tag主要是dvif_id和svif_id一对地址，分别对应于源和目的虚拟机的虚拟网络接口VIF，因此支持VN-Tag的上联交换机就能够区分不同的VIF，识别来自和去往特定虚拟机的流量了，这样就把对虚拟机的网络管理范围从服务器内部转移到上联网络交换机上了。

换句话说，VN-Tag是如何解决2.1中所说的虚拟机无法与交换机端口对应的问题的呢？这样：虽然服务器和上联接入交换机只有一条物理连接，但是交换机可以通过VN-Tag区分不同虚拟机的流量，然后在交换机上生成对应

关键特性：

(1) Port Extender。根据上面的原理，由于虚拟化软件Hypervisor和服务器网卡不再具备寻址功能，而是变成一个单纯的网络桥接通道，因此被VN-Tag称为Port Extender。Port Extender最主要的功能就是加上和去掉VN-Tag标签

(2) 级联。正是由于前面Port Extender的特点，VN-Tag具有级联的特性。即对应的处理交换机controlling switch可以不是与服务器直连的接入交换机，而可以是网络中任意IP可达设备，这样级联的好处是可以把流量拉到高端汇聚甚至核心设备上去进行更加精细、高速的管理

(3) 迁移。由于VN-Tag与虚拟机VIF形成了固定的对应关系，因此不管虚拟机迁移到哪台服务器上去，原来部署在VIF端口上的策略都可以保持不变。

标准化与产业化：

(1) 目前已从IEEE 802.1Qbh改为了IEEE 802.1Br(Bridge Port Extension)

(2) 产品方面，服务器需要Cisco Palo卡或者更高级的Cisco VIC 1280卡，交换机要能识别VN-Tag。

2.4 HP VEPA

核心思想也是将虚拟机间的交换行为从服务器内部转移到上联交换机。

关键特性：

(1) 发卡弯。其本质是对STP生成树协议的修改，对应的场景就是同一个服务器上不同虚拟机间通信的情形，通过强制反射Reflective Relay实现对传统STP的修改。这也叫做标准版的VEPA，对数据帧没有任何改动。

(2) Q-in-Q。这是增强版的VEPA，其本质是使用VLAN堆叠的Q-in-Q技术(802.1ad)，即在传统以太网数据桢VLAN标签之外再加上一个标签，来标识不同虚拟机或者虚拟机组的流量。这个外层标签叫做S-Tag或者S-Channel或者形象地称为通道。在标准版VEPA中，上联交换机只能通过IP或者MAC地址区分不同虚拟机数据，而MAC和IP地址容易被作假和攻击，那么增强版VEPA就用另外一个标签S-Tag来实现更精细的流量管理和隔离。

标准与产业化

标准化石IEEE 802.1Qbg。

产品方面，虽然包括了除cisco和vmware之外的几乎所有厂商，但是目前仍缺少实际产品和案例的支撑，并且增强版VEPA仍然需要更换现有的交换机，因为Q-in-Q功能并不常见，当然也需要服务器网卡的支持。

3 虚拟网卡

虚拟网卡本质上就是前面提到的“虚拟接入”的具体执行中必不可少的一个环节。虽然广义上讲是SR-IOV技术(Single Root I/O Virtulization)，具体上你可以理解成为Cisco Palo卡以及后续的VIC1280卡即可。虚拟网卡本质上讲完成两个重要工作：

1 将一个物理以太网卡对虚拟机虚拟化为多个独立的PCIe设备，即在一个PF物理通道上虚拟出多个轻量级的VF虚拟通道，每个对应一个虚拟机，将网络接入直接延伸到虚拟机层面。

2 为了支持前面的虚拟接入，在虚拟网卡上打上VN-Tag标签后再送往上联交换机，最终实现区分不虚拟机的流量，并可以在整个数据中心内部署针对性的隔离和Qos策略。

阅读全文»

分享

分享

原文看参阅：http://wangxu.me/blog/p/735

前几天，亚马逊的云服务（AWS）连续发生大规模服务中断，使得默默无闻的EBS（弹性块存储）服务再次被推上风口浪尖。实际上，过去一两年间，差不多所有AWS服务大规模中断，都可以听到EBS的叹息，难怪新浪的程辉兄说：“EBS仍然是公有云最大的难点和故障点”。

作为国内为数不多的，也大概是最早提供商用EBS服务的团队成员，我当即跳出来为EBS说了几句“公道话”，之后的图灵生日会上，和刘江老师聊天的过程中，他建议我把这些想法写出来，也让用户和相关产业了解，一个EBS服务的设计者是怎么看待自己这个“故障点”的。

首先说说我的总体观点，EBS是最后一道防线，所以重大故障才往往在EBS身上体现出来。只要存储不出问题，再大的问题也不容易造成长时间、大范围的停机，不论是网络还是计算，都是无状态的，有电、有链路就可以工作，而这些也是最容易通过冗余来保障可用性的；但存储则不同，对存储来说，数据正确是我们第一要保障的，如果真发生严重故障，我们不可以为用户迫切要求的可用性而冒险牺牲正确性。

系统设计的哲学：熔断器与冗余

没有系统能避免异常情况的出现，大系统的设计中，最复杂、最难处理的地方往往是不常遇到的意外（超负荷）情况，在这里经常用到的两种策略是熔断器和冗余——

• 系统常常设计为可以承担远高于其标称值的负荷，从而在出现异常的情况下，也能持续工作，这是所谓服务能力的冗余
• 对于另外一些情况，我们会采取一种看起来和服务可用性背道而驰的策略——停止服务，以避免更严重的损失，这个就类似于电子设备中的熔断器，或者叫保险丝。

这两种策略几乎总是同时用到的——对普通的困难，我们争取用设计上的冗余来克服，让它对用户透明。但是，当系统无法承受的时候，就需要果断地中断服务。什么情况下中断服务，总是设计者最为头痛的地方，他们不愿意向用户暴露自己脆弱的一面，但也不能背弃对用户的承诺——如果你无法保证数据的持久写入，就不能欺骗用户说数据你已经存储好了。

而没有程序是没有Bug的，这些最极端的情况，往往是设计实现者自己也最难以枚举的，他们的测试很难涵盖到类似的情况，于是，对于包容性比较好的存储系统设计，在这样的困境下，尽力保持现场地退出服务，让独立的运维程序，甚至是人工来介入，恢复服务状态是一种负责任的态度。对于亚马逊的EBS故障情况，我个人基本是这么理解的。

那么好了，我想，一定有人要问一个问题，既然EBS可能会造成这样的窘境，为什么一定需要这么一个服务呢。

让人又爱又恨的EBS服务

如果你想成为最好的云服务商，请做EBS服务，这是杀手服务；如果你想成为被人唾骂的云服务商，请做EBS服务，这是你的最大故障点。（改自《北京人在纽约》的经典台词）

亚马逊大多数的AMI（操作系统镜像）都放在EBS上，亚马逊很多虚拟机都用到了EBS服务，很多数据库都放在EBS磁盘上……亚马逊的EBS需要额外付费，亚马逊的EBS的性能并不稳定，甚至可以说亚马逊的EBS性能公认的不好……这一系列的事实同样是这么矛盾，一遍又一遍地问：为什么人们要用EBS服务呢？

• EBS服务是便宜的——是的，单独额外付费的EBS反而可能是更便宜的，使用EBS作为操作系统镜像，这会让虚拟机在不需要工作的时候，可以处于stop状态，这个状态是不计费的；而且，使用EBS作为数据盘，可以在不需要计算的时候，销毁虚拟机实例，而在需要时在申请新的虚拟机，直接使用已有EBS上的数据。（后者盛大云已经提供，前者即将提供）
• EBS服务是可靠的——即使虚拟机发生故障，服务器的硬盘发生故障或其他问题，EBS作为一种可靠的持久化存储服务，仍然可以保证数据的可靠性。
• 在上面两个优异特性的基础上，更让人兴奋的是，EBS服务居然真是能用的，而且，你的程序可以直接像用本地磁盘一样用EBS，这简直是上天赐予我们的礼物。
• 此外，EBS服务有更多的玩法——可以使用RAID，组合多块EBS盘，在一定程度上提高EBS的性能；可以创建快照，可以用快照来恢复成多块EBS盘。(盛大云硬盘的快照功能即将提供)

概括地说，EBS提供了持久化的、具有独立于主机的生命周期的、高可用的块存储设备，在这一设备上可以创建支持POSIX语义的本地文件系统（或是Windows本地文件系统）。这些独一无二的特征，让用户们在口诛笔伐这个服务的同时，也离不开这个服务。

阅读全文»

分享