云时代的编程——从计算模型演化看编程模式发展

从有计算机开始，计算模型先后经历了专业（大小型）机-->pc-->网格计算-->云计算的过程。【注】暂不考虑一些专业领域的计算机器演化。

而编程模型，也由底层的纸带-->汇编-->面向过程编程-->面向对象编程的过程。

随着云计算的进一步发展，特别是paas的发展，编程的环境、库都可以以服务的形式来动态提供，即演变为“编程即服务”模式。

在这种模式下，程序员能获取的资源已经不是以库的形式存在，而是服务组件，即每个组件会实现某些高级的业务功能。

以前，比如我们要编程实现一个web应用，我们需要有网络库、认证库、web服务器库等等的支持，开发大量的代码。

而在云时代，我们直接可以获取各种现成的web组件，就像搭建积木一样把它们拼凑在一起就可以实现自己所需要的功能了。

之前，我曾认为编程模型，从面向过程到面向对象，后面一定会演化到更进一步的面向目的。

而云时代的编程模式已经有了面向目的的雏形。更进一步的，开发者只需要定义好清晰的业务逻辑和模型，AI引擎会自动拼接各种服务组件，完成程序的构建。真到了那个时候，计算机的能力才会更进一步的被释放出来，各种产业也会面临新的变革和机遇！

RFC中的奇葩(2) - The Twelve Networking Truths

http://tools.ietf.org/html/rfc1925

12个网络相关的事实，发表在1996年的愚人节。

虽说是在愚人节，讲的东西却颇有道理。以幽默的方式阐述了设计网络这个前无古人的大工程中要注意的事实。

1）必须要能工作。。
2）不能增加光的速度。。
3）足够的推力，猪也可以飞，但显然没必要这么做。一个是很难控制它的着陆，另一个是当它们飞在空中经过的时候，坐在下面是一件很危险的事情。。
4）有些东西，不实际体验下，永远难以很好的认识和理解。
5）把多个问题糅合到一起，提出一个复杂的解决方案，不是一个好主意。
6）把问题转移到其他地方，比解决它要容易。
7）永远是某个存在。（怀疑有遗漏，推论是凡事总有tradeoff）
8）比你想象的更为复杂。
9）对所有的资源，你总是需求更多。
10）一个尺寸不能适应所有的事情。
11）所有的老主意总会被再次提出，换个名字，换个表达方式，不管是否工作的好。
12）在设计协议的时候，完美的目标，不是说无法再添加什么上去了，而是说无法再拿掉什么了。

理解网络元素

这里谈的网络，是以互联网为代表的计算机网络。
现实的网络要远比人们想象的复杂，无论是从拓扑结构还是底层设备上。
理想的网络模型，交换设备（各层的交换机、路由器、网关）连通主机，而在实际中，还存在大量的其他类型的盒子，比如负载均衡、防火墙、IDS，等等等等。
在云计算数据中心网络中，各类带有复杂功能的盒子更多，更杂乱。
那么，如何理清各种盒子（网络元素）对于正确理解网络本身就十分重要。

从网络的主要功能角度出发来看，网络的存在是为了信息的交互，因此，其最根本的功能是转发。无论一个盒子是几层设备，它的功能都是某种意义上的转发。而且这个转发，对终端用户来说应该是透明的，即用户不应该也不需要知道中间的信息。源主机只需要知道目的主机的信息，然后把流量扔出去，怎么转发到目的主机是网络的事情。同样的，目的主机收到的流量，只知道是源主机发过来的，也不需要知道具体是怎么发过来的。

基于“网络的存在是为了转发”这一原则，可以把现在的网络元素分为三大类。
第一类是基础转发盒子（basic forward network element），代表设备为传统意义上的安全middlebox，一头进流量，处理完了，从另外一头扔出来。这类盒子的特征是转发的方式是固定的，跟流量无关的。
第二类是根据流量转发的盒子（traffic aware network element），代表设备为各种交换设备。这些设备往往有多个接口，各个接口之间如何转发并非固定，而是需要根据traffic 的内容（典型的是包头中的目标值）来进行“动态”决策。
第三类是高级智能盒子（advanced smart network element），代表设备为负载均衡系统等。这类设备不光需要检查traffic的内容，还需要考虑其它相关的因素，比如服务器负载情况，各种QoS情况等。

这三类盒子，越往上，功能越复杂，同时支持的网络协议层数往往也越多。现在middlebox在网络中很热门，因为使用middlebox往往可以实现十分复杂的处理功能，这些middlebox也大多都是第三类元素。随着技术的进步，可以预见，第三类盒子的存在将越来越多。特别配合SDN技术，对这些盒子的管理将更加容易和多样化。

当然，现在有很多盒子同时把多种功能做到了一起，但万变不离其宗，仍然可以从这三个层次去理解它。

SDN国内利好

SDN已经炒了有几年了，随着云等产业的成熟，SDN也开始逐渐落地。
这方面china仍然要落后一些。
昨天（2013年8月8日）的新闻联播播出了两条消息，让人感觉国内要开始有些实际动作了。

一个是未来网络小规模试验设施开通，虽然介绍很短，但从几个闪现的画面还是看出来不少信息的。
牵头人应该是刘韵洁院士，落地在江苏南京的未来网络谷（大把的投资，好多空机房）。画面中有中科院的sofia系统，所以估计是类似geni计划的一个试验床，其中利用了sdn和ccn/ndn的一些手段，可以进行一些新协议的验证。另外，之所以叫未来网络而不是下一代网络是因为下一代网络在国内一直被认为是基于IPv6的网络。但v6这些年亚洲炒的热，拥有大块地址域的美帝等国家根本不care。SDN虽然并非是要解决地址的问题，但是新的管控手段上来后可以大量使用映射、封装来缓和一些。从消息上看，研究机构里面中科院占了大头，清华等院校在早期是领先者，但这个机会没能很好抓住。总结来看，跟企业的紧密合作很重要，不然业界难以接受新的概念。可以关注笔者在SDN刚露头的时候（09、10年）撰写的材料（https://github.com/yeasy/tech_writing/tree/master/SDN）。

另外一个是全球首款可编程网络交换机研制成功。这个其实是有夸张了，估计是第一台自主知识产权的。从图片上推测，应该是华为做的（但似乎在之前国内就有一些类似产品出来，可能还有缺陷）。可编程网络交换机是SDN的基础技术，有了交换机的可编程性，才有对网络的灵活配置和动态控制。软件的实现上ovs已经是十分成熟，足以满足产品级的应用，但放到硬件上会有一系列问题，包括表的大小、处理流程等。SDN的场景下对交换机的压力是很大的，需要很多新的考虑。现在全球范围内看能满足产品级应用的，也只有IBM的BNT系列、NEC的（Cisco老喜欢自己加封闭的东西，所以不谈也罢）。这次对华为是个不错的机会，华为走到现在很不容易，要想成功转型，在既有领域站住脚，还能开拓新的用户业务，会面临不少挑战。

ref: 新闻完整内容在：http://news.cntv.cn/2013/08/08/VIDE1375962603760867.shtml

btw，跟主题无关，才知道8月8日已经定为“全民健身日”，但好像不见丝毫举动。比较有诚意的举措是全民放假，体育场馆免费开放。话说现在搞锻炼的成本真是高啊。

RFC中的奇葩(1) - Discard Protocol

RFC见证了互联网的发展历史。
一群技术人在一起，总会产生很多让人忍俊不禁的故事，包括几个著名的愚人节发布的RFC。
本系列将关注RFC中一些“卓尔不群”的经典提案。

本文提到的RFC其实还真是一个挺有用的RFC，发表于1983年，全文就1页，在http://tools.ietf.org/html/rfc863。主要用处就是定义了Discard Protocol，即丢弃服务。

简单的说，该RFC干的事情就是定义了啥都不干。

该RFC煞有其事地分了TCP和UDP两种情况进行讨论，定义了端口号9。

让人对当年神往不已。

Open Daylight Controller 简易入门

You can find the latest version here: https://github.com/yeasy/tech_writing/tree/master/SDN

Many contents are referenced from
www.openflow.org/wk/index.php?title=OpenDayLight_Tutorial

Open Daylight Controller 指南

https://github.com/yeasy/tech_writing/tree/master/SDN

OpenStack 架构分析（Folsom）

OpenStack架构

v0.2: 2013-04-08

       添加服务架构说明

v0.1: 2013-04-02

       完成基于folsom版本的初始版本

1.1              组件

目前（folsom版本），OpenStack包括7个核心部件，包括前端面板、计算、对象、镜像、鉴权、网络和块存储。各部分功能为

l         前端面板 项目名称为Horizon，为所有的OpenStack服务提供web前端接口界面。利用web界面，可以进行大部分的云操作，包括运行实例、分配IP和设置访问控制等。

l         计算 项目名称为Nova，提供虚拟机服务。基于Nova，HP和Rackspace都开发有商用的计算服务方案，同时在Mercado Libre和NASA（发起人）等公司内部都有使用。

l         对象 项目名称为Swift 允许储存或获取文件（但不能像文件服务器一样挂载目录）。基于Swift，数家公司开发了商业的存储服务方案，包括KT，Rackspace（发起人）和Internap。Swift同时在多家大型企业内部应用负责数据存储。

l         镜像 项目名称为Glance，提供登记和虚拟机镜像的管理，这些镜像主要是支持计算服务的。

l         鉴权 项目名称为Keystone，为OpenStack所有的服务提供认证和授权，同时提供了服务的登记管理。

l         网络 项目名称为Quantum，在网络接口设备之间提供连接服务。允许用户创建自由网络并挂载端口。架构开放，支持插件。从Folsom版本时引入。

l         块存储 项目名称为Cinder，为guest虚拟机提供永久性块设备，前身为nova-volume。所提供的块存储并非类似NFS或CIFS share的文件系统。从Folsom版本时引入。

与Amazon的AWS相比，OpenStack大部分的工具和API等都有很好的兼容性。包括

l         Nova在概念上类似EC2。可以有多种方式来支持EC2的API。

l         Swift在概念上类似于S3.在WSGI中间件上实现了部分S3 API。

l         Glance提供了Amazon的AMI登记服务类似的很多特性。

l         Cinder提供了类似于EBS的块设备。

1.2              架构

1.2.1      概念架构

OpenStack在整体设计上是“提供大量的可扩展的云服务的操作系统”，为了实现这点，各个组成的服务被设计一起协作提供“架构即服务（IaaS）”。这些协作通过服务提供的API之间进行操作实现。这些API允许服务之间的调用，并且相互之间松耦合。

概念架构如图表 1所示。

图表 1 OpenStack概念架构

其中，Horizon提供用户的web前端；Nova存储和获取虚拟机，并且在Glance中维护元数据；Quantum为Nova提供虚拟网络；Cinder为Nova提供块存储；Glance在Swift中保持实际的虚拟机硬盘文件；所有的服务都需要Keystone进行认证。

1.2.2      逻辑架构

逻辑架构比概念架构复杂的多。图表 2中给出了最常见的一些架构。

图表 2 OpenStack逻辑架构

用户可以通过Horizon跟其他服务交互，或者通过其他服务提供的API。

所有的服务都需要通过Keystone来进行认证。

部分服务通过公开的API跟其他服务进行交互。

1.2.3      服务架构

图表 3 服务和通信架构

1.3              Horizon-前端面板

Horizon是一个模块化的Django web应用，它为用户和管理员提供访问OpenStack服务的界面接口，如图表 2。

图表 4 Horizon提供用户接口界面

跟大部分的web应用类似，Horizon的架构比较简单：

l         Horizon一般通过Apache中的mod_wsgi进行部署。它的代码独立成为一个可重用的python模块，包括大部分的逻辑（跟不同的OpenStack API交互）和展示层（为不同站点提供容易的定制）。

l         一个数据库。因为大部分数据都是依赖自其它服务，自身存储的数据很少。

从网络架构的角度，Horizon服务需要是用户可访问的，同时能跟其他服务的公开API交互。如果同时需要一些管理功能（例如，管理其他服务），则Horizon需要能够访问到其他服务的管理API（这些API一般是用户不能直接访问的）。

1.4              Nova-计算

Nova是最复杂，同时也是最分散的一个组件。该组件包括大量的进程合作来把用户的API请求发给运行中的虚拟机。包括如下的进程：

l         Nova-api 接受和响应终端用户的计算API请求。支持OpenStack的计算API，Amazon的EC2 API和一些特定的管理API（给超级用户提供管理操作）。并且发起大部分的协调（orchestration）操作，比如运行一个虚拟机实例。此外，还包括对策略的支持（主要是配额检查）。

l         Nova-compute 主要是个工作守护进程（worker daemon），通过hypervisor的API（包括XenServer/XCP的XenAPI，KVM和QEMU的libvirt，VMWare的VMWareAPI等）来创建和关闭虚拟机实例。进程要做的事情很复杂，但是工作过程却比较直观：不断从队列中获取请求并响应，执行一系列的系统命令（例如运行一个KVM实例），同时更新数据库的状态。

l         Nova-volume 负责管理为计算实例提供创建、挂载和卸载永久性存储（类似于Amazon的Elastic Block Storage）。该进程支持很多类型的存储，包括iSCSI、Ceph中的Rados Block Device。新出现的Cinder项目将最终取代Nova-volume，在Folsom版本中，两者提供了类似的功能。

l         Nova-schedule 该进程在概念上是Nova中最简单的一个进程：从队列中获取创建虚拟机实例的请求，并且决定在哪里运行它（特别的，运行在哪一台物理机上）。

l         Queue 提供一个中央的hub，来在各个daemon之间传递消息。基于RabbitMQ实现，但同时支持任何兼容AMPQ消息的queue机制（包括Apache Qpid和Zero MQ）。

l         SQL数据库 存储架构中大部分的创建和运行时状态。包括可用、在用、网络可用的实例类型和项目等。理论上，Nova可以支持被SQL_Alchemy支持的任意数据库，目前广泛应用的包括sqlite3（推荐仅用于测试和开发）、MySQL和PostgreSQL。

l         Nova还提供了一些控制台服务，让用户可以通过一个proxy来访问虚拟实例的控制台。包括若干daemon（nova-console、nova-vncproxy和nova-consoleauth）。

Nova跟OpenStack大部分的其他服务都有交互。例如需要KeyStone提供认证、Glance提供镜像管理、Horizon提供web接口。与Glance的交互是核心。API进程可以上传和查询Glance，同时nova-compute可以通过Glance下载镜像以运行。

1.5              Swift-对象

Swift在架构上也是分布式的，以避免单点故障（single point of failure）和支持横向扩展，包括如下的子组件。

l         Swift-proxy-server 接受通过OpenStack对象API或原始HTTP的来访请求。接受包括文件上传、元信息修改和容器创建（container creation）。另外，为web浏览器提供文件或列出容器服务。该自组件通常采用可选的cache（一般部署memcache）来提高性能。

l         Account servers 管理被对象存储服务（object storage service）定义的账户。

l         Container servers 管理在对象储存服务（object store service）中容器（例如文件夹）的映射。

l         Object servers 管理存储节点上的实际对象（例如对象）。

此外，还有一些周期性的进程，负责大数据仓库中一些管理维护工作。其中最重要的是冗余服务（replication services），来确保cluster中数据的一致性和可用性。其他的周期性进程包括审计（auditors）、更新（updaters）和收获（reapers）。

对象仓促可以通过HTTP来提供静态的网页或对象。例如图像、多媒体等。

认证是通过可配置的WSGI中间件来负责的，即Keystone。

1.6              Glance-镜像

Glance组件的架构从Cactus版本以来就一直很稳定。最大的改变包括添加了认证。Glance主要包括四个主要部分：

l         Glance-api 接受镜像API调用，包括发现镜像、获取镜像和存储镜像等。

l         Glance-registry 存储、处理和获取镜像的元数据（包括尺寸、类型等）。

l         数据库 存储镜像的元数据。数据库类型可选（i一般推荐MySQL或SQlite）。

l         镜像文件的存储 一般镜像存储是在Swift中，但这是可以配置的。Glance支持文件系统、RADOS块设备、Amazon S3和HTTP。但部分仅支持读操作。

类似Swift，Glance中也包括一些周期性进程来支持caching和冗余等。

Glance在整个OpenStack的概念架构上，起到了IaaS中的中心作用。它接受用户或Nova对镜像的请求API，并且存储磁盘文件到对象服务Swift中。

1.7              Keystone-鉴权

Keystone提供了一个对OpenStack中策略（policy）、登记（catalog）、口令（token）和认证（authentication）的支持。

l         处理API请求，包括提供可配置的登记、策略、口令和身份服务。

l         每个Keystone的功能，后面都是一个可插拔式（pluggable）的后端，从而可以采用多种不同的服务。大部分支持的标准后端包括LDAP、SQL和Key Value Store（KVS）。

Keystone一般常被用来提供认证服务。

1.8              Quantum-网络

Quantum试图在OpenStack其他服务（大部分情况下是Nova）管理的接口设备之间提供“网络连接即服务（network connectivity as a service）”。Quantum允许用户创建自由的网络，同时将接口连接上去。跟OpenStack中很多服务类似，Quantum的架构也是可配置的，支持插件（plug-in）。这些插件适应不同的网络设备和软件。因此，Quantum的架构和部署都是可以快速调整的。

l         Quantum-server 接受接受API请求，转发给合适的Quantum插件上。

l         Quantum插件和代理 执行实际的操作，包括插上、拔下端口、创建网络、划分子网和管理IP地址。这些插件和代理可以来自不同的提供商。Quantum自身支持或已配置的插件和代理包括Cisco虚拟和物理交换机，Nicira的NVP产品，NEC OpenFlow产品、Open vSwitch、Linux bridging和Ryu网络控制器。Midokua提供了一个插件来帮助整合。常见的代理包括L3、DHCP和其他指定的插件代理。

l         大部分情况下，Quantum采用一个消息队列来在Quantum-server和各种代理之间传递消息，同时采用数据库来为一些特定插件存储网络状态。

Quantum大部分交互都是跟Nova进行的，为虚拟机提供网络连通服务。

1.9              Cinder-块存储

Cinder将nova-volume服务单独剥离出来，提供永久性块存储服务。提供API来支持操作存储卷、存储类型和快照等。

l         Cinder-api 接受API请求，并转发给cinder-volume。

l         Cinder-volume 通过读写Cinder数据库来响应请求，包括维护状态、跟其他进程打交道、提供软件和硬件等。通过驱动层，可以跟不同类型的存储设备交互，包括IBM、SolidFire、NetApp、Nexenta、Zadara、Linux iSCSI等。

l         Cinder-scheduler 选取最优的块设备节点来创建存储卷。

l         Cinder采用一个消息队列来在Cinder各个进程之间传递消息，同时采用数据库类存储存储卷状态。

与Quantum类似，Cinder大部分交互都是跟Nova进行的，为虚拟实例提供存储服务。

1.10        未来版本中的部件

这些项目可能在今后版本的OpenStack中出现，包括

Ceilometer 提供一些测量（metering）信息，让提供接口展现OpenStack中的一些内部活动。该项目并非计费项目。要实现计费，需要测量、评估和计费。该项目让用户可以更好的了解哪些操作被执行了，评估则负责价格和条目、计费则计算费用，并发给用户。

Heat 提供REST API来协调多个实现标准的云应用，例如ASW的CloudFormation。

1.11        参考

http://ken.pepple.info/openstack/2012/09/25/openstack-folsom-architecture/

http://docs.openstack.org/trunk/openstack-compute/install/apt/content/index.html

网络相关的几个悖论

Braess's paradox
这个悖论是说在网络中添加新的路径，反而有可能造成更大的拥塞；反之，删除掉某些边，可能会让拥塞缓解。
乍一看，似乎比较难理解，但是回过头来考虑到在网络中传输的个体（比如交通网络中的车辆）实际上选择的都是局部最优的贪婪算法，即大家都去抢目前看来似乎比较快的路径，结果反而造成路径的通过时间变长。这是典型的局部优化导致全局不优化的一个例证。
一个很直观的简单例子在http://en.wikipedia.org/wiki/Braess's_paradox中可以看到。
这也实际上给治理交通拥堵的城市规划部门提了个醒，不能简单拍拍脑袋说拓宽某条容易堵车路，或者修条新路，有时候反而是起到相反的作用。反之，特定时间适当地限制从某些特定路通过，有时候反而能缓解。
实际上，城市里的交通规划比较理想的解决思路应该是上物联网+大规模智能计算。所有的路口安装足够多的sensor（比如监视器拍摄到画面），回传数据给类似waston一样的智能计算中心，进行实时的分析（视频、图像的分析是个迫切需要解决的问题）和计算、推理，然后统一进行调度，控制红绿（黄）灯的信号和时间。这样才有可能尽量合理的发掘道路的潜力，并能定位到真正的bottleneck所在，给市政规划、建设提出正确的建议和方向。
基于这个悖论的一些猜测也很有趣，比如是否存在如下可能？
在团体赛事中（足球、篮球），并不是队员越多越好，有时候少上一些队员反而更能赢得比赛？
管理机构中，人员也并非分工越细越好，合理的消除一些岗位或许反而使得整体办公效率提高。

NSDI 2012 论文选读 - Header space analysis: Static checking for networks

abstract:

Today’s networks typically carry or deploy dozens of protocols and mechanisms simultaneously such as MPLS, NAT, ACLs and route redistribution. Even when individual protocols function correctly, failures can arise from the complex interactions of their aggregate, requiring network administrators to be masters of detail. Our goal is to automatically find an important class of failures, regardless of the protocols running, for both operational and experimental networks.

To this end we developed a general and protocol-agnostic framework, called Header Space Analysis (HSA). Our formalism allows us to statically check network specifications and configurations to identify an important class of failures such as ReachabilityFailures, Forwarding Loops and Traffic Isolation and Leakage problems. In HSA, protocol header fields are not first class entities; instead we look at the entire packet header as a concatenation of bits without any associated meaning. Each packet is a point in the {0, 1}^L space where L is the maximum length of a packet header, and networking boxes transform packets from one point in the space to another point or set of points (multicast).

We created a library of tools, called Hassel, to implement our framework, and used it to analyze a variety of networks and protocols. Hassel was used to analyze the Stanford University backbone network, and found all the forwarding loops in less than 10 minutes, and verified reachability constraints between two subnets in 13 seconds. It also found a large and complex loop in an experimental loose source routing protocol in 4 minutes.

阅读笔记：

有一种论文，看似得来轻松，却是功到自然；看似设计简单，却是大巧不工。这样的文章一出，即便学霸、专家看了，也往往觉得眼前一亮。倘若又能联系实际，碰巧解决一两个工程问题，那就更加站得住脚了，哪怕顶级会议也是问题不大。msra的Chuanxiong Guo曾发过一些类似风格的文章，后来功力日深，不常走这类轻巧路线了。

今天读的这篇论文，无疑可称得上精妙。

sdn的概念提出早期，大家一起讨论，这玩意能干啥，当时就有人提出能做diagnosis，大家的思路就是说一旦发生了问题，通过计算能快速的发现或者解决问题。这样的工作现在也有一些成果，但都是靠solid的设计和实现取胜。这篇文章中要解决的问题，则更加大胆。给我你的网络配置（转发策略等）情况，我能告诉你有哪些问题，比如，网络中是否存在环路？并给其了一个好听的名字，叫做Header Space Analysis (HSA)。

问题提出，先别看别人咋做的，自己想一想，要解决这个问题其实技术上来说并无太大难度，如果能拿到所有节点的配置，把所有可能情况遍历一遍即可。这样做，就落入传统的解决工程问题的一般套路了。能否拔高点？这也是本文最大的亮点。网包在网络中转发，无非就是个空间变换。包头104位（5元），最多就是104维嘛。转发无非就是从一个子空间，映射到了另一个子空间。先别管这样直接粗糙的定义是否合适，但问题一下子便拔高了，有了数学上的意义。然后再自然的定义一些基本概念，一个很好的数学问题便被提出了。

之后，文章中还实现了一些简单的工具，并分析了实际的一个网络，用这些工具发现的一些可能的问题。当然，这些问题可能只是在理论意义上存在的。有理有据，这正是大家写论文该模仿的典范！

当然，原创性太强的工作，自然解决的不会那么完美，仍有很多坑等着大家去继续深入。

比如：

目前只能分析static的情况；

只能解决映射到一个点的问题；

计算复杂度如何快速降低？

能否扩展到考虑payload的情况。

解决了这些问题，这种分析的方法才会有更多的实践意义，才会被用到更多的领域，特别是安全领域。

ref: https://www.usenix.org/conference/nsdi12/header-space-analysis-static-checking-networks