Ⅰ openstack 支持多大的内存
目前OpenStack支持的虚拟机宿主包括KVM,XEN，... 命名为Node1: CPU:Intel G530 2.4GHz 内存：2G DDR3 硬盘 500G 电脑2仅作为云计算节....
Ⅱ openstack对象存储可以使用哪些
最近在quora上有人提到一个问题，有关hadoop分布式文件系统和openstack对象存储的不同。
问题原文如下：
“hdfs （hadoop分布式文件系统）和openstack对象存储（openstack object storage）似乎都有着相似的目的：实现冗余、快速、联网的存储。什么样的技术特性让这两种系统因而不一样？这两种存储系统最终趋于融合是否大有意义？”
问题提出之后，很快有openstack的开发者进行了回复。本文在此摘抄了前两名回复进行翻译，以供各位参考。
排名第一的答案来自rackspace的openstack swift开发者chuck their：
虽然hdfs与openstack对象存储（swift）之间有着一些相似之处，但是这两种系统的总体设计却大不一样。
1. hdfs使用了中央系统来维护文件元数据（namenode，名称节点），而在swift中，元数据呈分布式，跨集群复制。使用一种中央元数据系统对hdfs来说无异于单一故障点，因而扩展到规模非常大的环境显得更困难。
2. swift在设计时考虑到了多租户架构，而hdfs没有多租户架构这个概念。
3. hdfs针对更庞大的文件作了优化（这是处理数据时通常会出现的情况），swift被设计成了可以存储任何大小 .....
Ⅲ OpenStack怎么对接分布式存储
OpenStack对接对象存储的方式有很多，我们的OpenStack就是通过Glance、Cinder、Nova等组件对接元核云的对象存储，方便好用。
Ⅳ 全面认识openstack，它到底是什么包含什么
（1）官方的解释相信大家都已经了解了，不了解也没有关系。现在从常识的角度来给大家解释和说明。
OpenStack是一个云平台管理的项目，它不是一个软件。这个项目由几个主要的组件组合起来完成一些具体的工作。
OpenStack是一个旨在为公共及私有云的建设与管理提供软件的开源项目，OpenStack被公认作为基础设施即服务（简称IaaS）资源的通用前端。
如果这些还不明白，那么从另外的角度给大家介绍：
首先让大家看下面两个图就很简单明了了：
此图为openstack的登录界面
下面是openstack的一个管理界面
从这两个图，相信有一定开发经验，就能看出openstack是什么了。可以说他是一个框架，甚至可以从软件的角度来理解它。如果不明白，就从传统开发来讲解。不知道你是否了解oa，erp等系统，如果不了解可以到网上去找，资料一大把。他和oa，erp有什么不同。很简单就是openstack是用做云计算的一个平台，或则一个解决方案。它是云计算一个重要组成部分。
上面对openstack有了一个感性的认识。
（2）openstack能干什么。
大家都知道阿里云平台，网络云平台，而阿里云平台据传说就是对openstack的二次开发。对于二次开发相信只要接触过软件的都会明白这个概念。不明白的自己网上去查一下。也就是说openstack，可以搭建云平台，什么云平台，公有云，私有云。现在网络在招聘的私有云工程师，应该就是这方面的人才。
（3）openstack自身都包含什么
以下是5个OpenStack的重要构成部分：
l Nova – 计算服务
l Swift – 存储服务
l Glance – 镜像服务
l Keystone – 认证服务
l Horizon – UI服务
图1 OpenStack基本构架
下图展示了Keystone、Dashboard二者与其它OpenStack部分的交互。
下面详细介绍每一个服务：
（一）OpenStack计算设施—-Nova Nova是OpenStack计算的弹性控制器。OpenStack云实例生命期所需的各种动作都将由Nova进行处理和支撑，这就意味着Nova以管理平台的身份登场，负责管理整个云的计算资源、网络、授权及测度。虽然Nova本身并不提供任何虚拟能力，但是它将使用libvirt API与虚拟机的宿主机进行交互。Nova通过Web服务API来对外提供处理接口，而且这些接口与Amazon的Web服务接口是兼容的。
功能及特点
l 实例生命周期管理
l 计算资源管理
l 网络与授权管理
l 基于REST的API
l 异步连续通信
l 支持各种宿主：Xen、XenServer/XCP、KVM、UML、VMware vSphere及Hyper-V
OpenStack计算部件
l Nova弹性云包含以下主要部分：
l API Server（nova-api）
l 消息队列（rabbit-mq server）
l 运算工作站（nova-compute）
l 网络控制器（nova-network）
l 卷管理（nova-volume）
l 调度器（nova-scheler）
API服务器（nova-api）
API服务器提供了云设施与外界交互的接口，它是外界用户对云实施管理的唯一通道。通过使用web服务来调用各种EC2的API，接着API服务器便通过消息队列把请求送达至云内目标设施进行处理。作为对EC2-api的替代，用户也可以使用OpenStack的原生API，我们把它叫做“OpenStack API”。
消息队列（Rabbit MQ Server）
OpenStack内部在遵循AMQP（高级消息队列协议）的基础上采用消息队列进行通信。Nova对请求应答进行异步调用，当请求接收后便则立即触发一个回调。由于使用了异步通信，不会有用户的动作被长置于等待状态。例如，启动一个实例或上传一份镜像的过程较为耗时，API调用就将等待返回结果而不影响其它操作，在此异步通信起到了很大作用，使整个系统变得更加高效。
运算工作站（nova-compute）
运算工作站的主要任务是管理实例的整个生命周期。他们通过消息队列接收请求并执行，从而对实例进行各种操作。在典型实际生产环境下，会架设许多运算工作站，根据调度算法，一个实例可以在可用的任意一台运算工作站上部署。
网络控制器（nova-network）
网络控制器处理主机的网络配置，例如IP地址分配，配置项目VLAN，设定安全群组以及为计算节点配置网络。
卷工作站（nova-volume）
卷工作站管理基于LVM的实例卷，它能够为一个实例创建、删除、附加卷，也可以从一个实例中分离卷。卷管理为何如此重要？因为它提供了一种保持实例持续存储的手段，比如当结束一个实例后，根分区如果是非持续化的，那么对其的任何改变都将丢失。可是，如果从一个实例中将卷分离出来，或者为这个实例附加上卷的话，即使实例被关闭，数据仍然保存其中。这些数据可以通过将卷附加到原实例或其他实例的方式而重新访问。
因此，为了日后访问，重要数据务必要写入卷中。这种应用对于数据服务器实例的存储而言，尤为重要。
调度器（nova-scheler）
调度器负责把nova-API调用送达给目标。调度器以名为“nova-schele”的守护进程方式运行，并根据调度算法从可用资源池中恰当地选择运算服务器。有很多因素都可以影响调度结果，比如负载、内存、子节点的远近、CPU架构等等。强大的是nova调度器采用的是可插入式架构。
目前nova调度器使用了几种基本的调度算法：
随机化：主机随机选择可用节点；
可用化：与随机相似，只是随机选择的范围被指定；
简单化：应用这种方式，主机选择负载最小者来运行实例。负载数据可以从别处获得，如负载均衡服务器。
（二）OpenStack镜像服务器—-GlanceOpenStack镜像服务器是一套虚拟机镜像发现、注册、检索系统，我们可以将镜像存储到以下任意一种存储中：
本地文件系统（默认）
l OpenStack对象存储
l S3直接存储
l S3对象存储（作为S3访问的中间渠道）
l HTTP（只读）
功能及特点
提供镜像相关服务
Glance构件
l Glance控制器
l Glance注册器
（三）OpenStack存储设施—-Swift
Swift为OpenStack提供一种分布式、持续虚拟对象存储，它类似于Amazon Web Service的S3简单存储服务。Swift具有跨节点百级对象的存储能力。Swift内建冗余和失效备援管理，也能够处理归档和媒体流，特别是对大数据（千兆字节）和大容量（多对象数量）的测度非常高效。
功能及特点
l 海量对象存储
l 大文件（对象）存储
l 数据冗余管理
l 归档能力—–处理大数据集
l 为虚拟机和云应用提供数据容器
l 处理流媒体
l 对象安全存储
l 备份与归档
l 良好的可伸缩性
Swift组件
l Swift账户
l Swift容器
l Swift对象
l Swift代理
l Swift RING
Swift代理服务器
用户都是通过Swift-API与代理服务器进行交互，代理服务器正是接收外界请求的门卫，它检测合法的实体位置并路由它们的请求。
此外，代理服务器也同时处理实体失效而转移时，故障切换的实体重复路由请求。
Swift对象服务器
对象服务器是一种二进制存储，它负责处理本地存储中的对象数据的存储、检索和删除。对象都是文件系统中存放的典型的二进制文件，具有扩展文件属性的元数据（xattr）。
注意：xattr格式被Linux中的ext3/4，XFS，Btrfs，JFS和ReiserFS所支持，但是并没有有效测试证明在XFS，JFS，ReiserFS，Reiser4和ZFS下也同样能运行良好。不过，XFS被认为是当前最好的选择。
Swift容器服务器
容器服务器将列出一个容器中的所有对象，默认对象列表将存储为SQLite文件（译者注：也可以修改为MySQL，安装中就是以MySQL为例）。容器服务器也会统计容器中包含的对象数量及容器的存储空间耗费。
Swift账户服务器
账户服务器与容器服务器类似，将列出容器中的对象。
Ring（索引环）
Ring容器记录着Swift中物理存储对象的位置信息，它是真实物理存储位置的实体名的虚拟映射，类似于查找及定位不同集群的实体真实物理位置的索引服务。这里所谓的实体指账户、容器、对象，它们都拥有属于自己的不同的Rings。
（四）OpenStack认证服务（Keystone）
Keystone为所有的OpenStack组件提供认证和访问策略服务，它依赖自身REST（基于Identity API）系统进行工作，主要对（但不限于）Swift、Glance、Nova等进行认证与授权。事实上，授权通过对动作消息来源者请求的合法性进行鉴定。如下图所示：
Keystone采用两种授权方式，一种基于用户名/密码，另一种基于令牌（Token）。除此之外，Keystone提供以下三种服务：
l 令牌服务：含有授权用户的授权信息
l 目录服务：含有用户合法操作的可用服务列表
l 策略服务：利用Keystone具体指定用户或群组某些访问权限
认证服务组件
服务入口：如Nova、Swift和Glance一样每个OpenStack服务都拥有一个指定的端口和专属的URL，我们称其为入口（endpoints）。
l 区位：在某个数据中心，一个区位具体指定了一处物理位置。在典型的云架构中，如果不是所有的服务都访问分布式数据中心或服务器的话，则也称其为区位。
l 用户：Keystone授权使用者
译者注：代表一个个体，OpenStack以用户的形式来授权服务给它们。用户拥有证书（credentials），且可能分配给一个或多个租户。经过验证后，会为每个单独的租户提供一个特定的令牌。[来源：http://blog.sina.com.cn/s/blog_70064f190100undy.html]
l 服务：总体而言，任何通过Keystone进行连接或管理的组件都被称为服务。举个例子，我们可以称Glance为Keystone的服务。
l 角色：为了维护安全限定，就云内特定用户可执行的操作而言，该用户关联的角色是非常重要的。
译者注：一个角色是应用于某个租户的使用权限集合，以允许某个指定用户访问或使用特定操作。角色是使用权限的逻辑分组，它使得通用的权限可以简单地分组并绑定到与某个指定租户相关的用户。
l 租间：租间指的是具有全部服务入口并配有特定成员角色的一个项目。
译者注：一个租间映射到一个Nova的“project-id”，在对象存储中，一个租间可以有多个容器。根据不同的安装方式，一个租间可以代表一个客户、帐号、组织或项目。
（五）OpenStack管理的Web接口—-Horizon
Horizon是一个用以管理、控制OpenStack服务的Web控制面板，它可以管理实例、镜像、创建密匙对，对实例添加卷、操作Swift容器等。除此之外，用户还可以在控制面板中使用终端（console）或VNC直接访问实例。总之，Horizon具有如下一些特点：
l 实例管理：创建、终止实例，查看终端日志，VNC连接，添加卷等
l 访问与安全管理：创建安全群组，管理密匙对，设置浮动IP等
l 偏好设定：对虚拟硬件模板可以进行不同偏好设定
l 镜像管理：编辑或删除镜像
l 查看服务目录
l 管理用户、配额及项目用途
l 用户管理：创建用户等
l 卷管理：创建卷和快照
l 对象存储处理：创建、删除容器和对象
l 为项目下载环境变量
Ⅳ 什么是OpenStack
本文详细介绍了Openstack的网络原理和实现，主要内容包括：Neutron的网络架构及网络模型还有neutron虚拟化的实现和对二三层网桥的理解。
一、Neutron概述
Neutron是一个用Python写的分布式软件项目，用来实现OpenStack中的虚拟网络服务，实现软件定义网络。Neutron北向有自己的REST API，中间有自己的业务逻辑层，有自己的DB和进程之间通讯的消息机制。同时Neutron常见的进程包括Neutron-server和Neutron-agent，分布式部署在不同的操作系统。
OpenStack发展至今，已经经历了20个版本。虽然版本一直在更替，发展的项目也越来越多，但是Neutron作为OpenStack三大核心之一，它的地位是不会动摇的。只不过当初的Neutron也只是Nova项目的一个模块而已，到F版本正式从中剥离，成为一个正式的项目。
从Nova-Network起步，经过Quantum，多年的积累Neutron在网络各个方面都取得了长足的发展。其主要的功能为：
（1）支持多租户隔离
（2）支持多种网络类型同时使用
（3）支持隧道技术（VXLAN、GRE）
（4）支持路由转发、SNAT、DNAT技术
（5）支持Floating IP和安全组
多平面租户私有网络
图中同时有VXLAN和VLAN两种网络，两种网络之间互相隔离。租户A和B各自独占一个网络，并且通过自己的路由器连接到了外部网络。路由器为租户的每个虚拟机提供了Float IP，完成vm和外网之间的互相访问。
二、Neutron架构及网络模型
1、Neutron架构
Neutron-sever可以理解为类似于nova-api那样的一个专门用来接收API调用的组件，负责将不同的api发送到不同Neutron plugin。
Neutron-plugin可以理解为不同网络功能实现的入口，接收server发来的API，向database完成一些注册信息。然后将具体要执行的业务操作和参数通知给对应的agent来执行。
Agent就是plugin在设备上的代理，接受相应的plugin通知的业务操作和参数，并转换为具体的命令行操作。
总得来说，server负责交互接收请求，plugin操作数据库，agent负责具体的网络创建。
2、Neutron架构之Neutron-Server
（1）Neutron-server的本质是一个Python Web Server Gateway Interface（WSGI），是一个Web框架。
（2）Neutron-server接收两种请求：
REST API请求：接收REST API请求，并将REST API分发到对应的Plugin（L3RouterPlugin）。
RPC请求：接收Plugin agent请求，分发到对应的Plugin（NeutronL3agent）。
3、Neutron架构之Neutron-Plugin
Neutron-plugin分为Core-plugin和Service-plugin。
Core-plugin：ML2负责管理二层网络，ML2主要包括Network、Subnet、Port三类核心资源，对三类资源进行操作的REST API是原生支持的。
Service-plugin：实现L3-L7网络，包括Router、Firewall、VPN。
4、Neutron架构之Neutron-Agent
（1）Neutron-agent配置的业务对象是部署在每一个网络节点或者计算节点的网元。
（2）网元区分为PNF和VNF：
PNF：物理网络功能，指传统的路由器、交换机等硬件设备
VNF：虚拟网络功能，通过软件实现的网络功能（二层交换、三层路由等）
（3）Neutron-agent三层架构如下图：
Neutron-agent架构分为三层，北向为Neutron-server提供RPC接口，供Neutron server调用，南向通过CLI协议栈对Neutron VNF进行配置。在中间会进行两种模型的转换，从RPC模型转换为CLI模型。
5、Neutron架构之通信原理
（1）Neutron是OpenStack的核心组件，官网给出Neutron的定义是NaaS。
（2）Naas有两层含义：
对外接口：Neutron为Network等网络资源提供了RESTful API、CLI、GUI等模型。
内部实现：利用Linux原生或者开源的虚拟网络功能，加上硬件网络，构建网络。
Neutron接收到API请求后，交由模块WSGI进行初步的处理，然后这个模块通过Python API调用neutron的Plugin。Plugin做了相应的处理后，通过RPC调用Neutron的Agent组件，agent再通过某种协议对虚拟网络功能进行配置。其中承载RPC通信的是AMQP server，在部署中常用的开源软件就是RabbitMQ
6、Neutron架构之控制节点网络模型
控制节点没有实现具体的网络功能，它对各种虚拟设备做管理配合的工作。
（1）Neutron：Neutron-server核心组件。
（2）API/CLI：Neutron进程通过API/CLI接口接收请求。
（3）OVS Agent：Neutron通过RPC协议与agent通信。
控制节点部署着各种服务和Neutron-server，Neutron-server通过api/cli接口接收请求信息，通过RPC和Agent进行交互。Agent再调用ovs/linuxbridge等网络设备创建网络。
7、Neutron架构之计算节点网络模型
（1）qbr：Linux Bridge网桥
（2）br-int：OVS网桥
（3）br-tun：OVS隧道网桥
（4）VXLAN封装：网络类型的转变
8、Neutron架构之网络节点网络模型
网络节点部署了Router、DHCP Server服务，网桥连接物理网卡。
（1）Router：路由转发
（2）DHCP： 提供DNS、DHCP等服务。
（3）br-ex： 连接物理网口，连接外网
三、Neutron虚拟化实现功能及设备介绍
1、Neutron虚拟化实现功能
Neutron提供的网络虚拟化能力包括：
（1）二层到七层网络的虚拟化：L2（virtual Switch）、L3（virtual Router 和 LB）、L47（virtual Firewall ）等
（2）网络连通性：二层网络和三层网络
（3）租户隔离性
（4）网络安全性
（5）网络拓展性
（6）REST API
（7）更高级的服务，包括 LBaaS，FWaaS，VPNaaS 等
2、Neutron虚拟化功能之二层网络
（1）按照用户权限创建网络：
Provider network：管理员创建，映射租户网络到物理网络
Tenant network：租户创建的普通网络
External network：物理网络
（2）按照网络类型：
Flat network：所有租户网络在一个网络中
Local network：只允许在服务器内通信，不通外网
VLAN network：基于物理VLAN实现的虚拟网络
VXLAN network：基于VXLAN实现的虚拟网络
3、Neutron虚拟化实现功能之租户隔离
Neutron是一个支持多租户的系统，所以租户隔离是Neutron必须要支持的特性。
（1）租户隔离三种含义：管理面隔离、数据面的隔离、故障面的隔离。
（2）不同层次租户网络的隔离性
租户与租户之间三层隔离
同一租户不同网络之间二层隔离
同一租户同一网络不同子网二层隔离
（3）计算节点的 br-int 上，Neutron 为每个虚机连接 OVS 的 access port 分配了内部的 VLAN Tag。这种 Tag 限制了网络流量只能在 Tenant Network 之内。
（4）计算节点的 br-tun 上，Neutron 将内部的 VLAN Tag 转化为 VXLAN Tunnel ID，然后转发到网络节点。
（5）网络节点的 br-tun 上，Neutron 将 VXLAN Tunnel ID 转发了一一对应的 内部 VLAN Tag，使得 网络流被不同的服务处理。
（6）网络节点的 br-int 上连接的 DHCP 和 L3 agent 使用 Linux Network Namespace 进行隔离。
4、Neutron虚拟化实现功能之租户网络安全
除了租户隔离以外 Neutron还提供数据网络与外部网络的隔离性。
（1）默认情况下，所有虚拟机通过外网的流量全部走网络节点的L3 agent。在这里，内部的固定IP被转化为外部的浮动IP地址
（1）Neutron还利用Linux iptables特性，实现其Security Group特性，从而保证访问虚机的安全性
（3）Neutron利用网络控制节点上的Network Namespace中的iptables，实现了进出租户网络的网络防火墙，从而保证了进出租户网络的安全性。
5、Neutron虚拟化设备
（1）端口：Port代表虚拟网络交换机上的一个虚拟交换机端口
虚拟机的网卡连接到Port上就会拥有MAC地址和IP地址
（2）虚拟交换机：Neutron默认采用开源的Openvswitch，
同时还支持Linux Bridge
（3）虚拟路由器VR：
- 路由功能
- 一个VR只属于一个租户，租户可以有多个VR
- 一个VR可以有若干个子网
- VR之间采用Namespace隔离
四、Neutron网桥及二三层网络理解
1、Neutron-Local-Bridge
仅用于测试；网桥没有与物理网卡相连VM不通外网。
图中创建了两个local network，分别有其对应的qbr网桥。Vm123的虚拟网卡通过tap连接到qbr网桥上。其中2和3属于同一个network可以通信，1属于另一个网络不能和23进行通信。并且qbr网桥不连物理网卡，所以说local网络虚拟机只能同网络通信，不能连通外网。
2、Neutron-Flat-Bridge
- Linux Bridge直接与物联网卡相连
- 每个Flat独占一个物理网卡
- 配置文件添加响应mapping
Flat网络是在local网络的基础上实现不同宿主机之间的二层互联，但是每个flat network都会占用一个宿主机的物理接口。其中qbr1对应的flatnetwork 连接 eth1 qbr2，两个网络的虚机在物理二层可以互联。其它跟local network类似。
3、Neutron-VLAN-Bridge
在基于linux bridge的vlan网络中，eht1物理网卡上创建了两个vlan接口，1.1连接到qbr1网桥，1.2连接到了qbr2网桥。在这种情况下vm通过eth1.1或者eth1.2发送到eth1的包会被打上各自的vlan id。此时vm2和vm3属于同一个network所以是互通的，vm与vm2和vm3不通。
4、Neutron-VXLAN-Bridge
这个是以Linux bridge作agent的Vxlan网络：
Vxlan网络比Vxlan网络多了个VXLAN隧道，在Openstack中创建好内部网络和实例后，agent就会在计算节点和网络节点创建一对vxlan vtep.组成隧道的两个端点。
Vxlan连接在eth0网口。在网络节点多了两个组件dhcp 和router，他们分别通过一对veth与qbr网桥连接在一起，多个dhcp和路由之间使用namesapce隔离，当vm产生ping包时，发往linux 网桥qbr1，通过网桥在vxlan12上封装数据包，数据通过eth0网卡出计算节点到网络节点的eth0，在vxlan12解包。到达路由器之后经过nat地址转换，从eth1出去访问外网，由租户网络到运营商网络再到外部网络。
5、Neutron-VLAN-OVS
与Linux bridge不同，openvswitch 不是通过eth1.1 eth1.2这样的vlan接口来隔离不同的vlan，而是通过openvswitch的流表规则来指定如何对进出br-int的数据进行转发，实现不同vlan的隔离。
图中计算节点的所有虚拟机都连接在int网桥上，虚拟机分为两个网络。Int网桥会对到来的数据包根据network的不同打上vlan id号，然后转发到eth网桥,eth网桥直连物理网络。这时候流量就从计算节点到了网络节点。
网络节点的ehx int网桥的功能相似，多了一个ex网桥，这个网桥是管理提前创建好的，和物理网卡相连，ex网桥和int网桥之间通过一对patch-port相连，虚拟机的流量到达int网桥后经过路由到ex网桥。
6、Neutron-VXLAN-OVS
Vxlan的模型和vlan的模型十分相似，从表面上来看，他俩相比只有一个不同,vlan对应的是ethx网桥，而vxlan对应的是tun网桥。
在这里ethx和tun都是ovs网桥，所以说两者的差别不是实现组件的差别而是组件所执行功能的差别，ethx执行的是普通二层交换机的功能，tun执行的是vxlan中的vtep的功能，图中俩tun对应的接口ip就是vxlan的隧道终结点ip。所以说虚机的数据包在到达tun网桥之前是打的是vlan tag，而到达tun之后会发生网络类型的转换，从vlan封装为vxlan然后到达网络节点。而之前的vlan类型的网络，虚机数据包的类型一直都是vlan。
7、物理的二层与虚拟的二层（VLAN模式)
（1）物理的二层指的是：物理网络是二层网络，基于以太网协议的广播方式进行通信。
（2）虚拟的二层指的是：Neutron实现的虚拟网络也是二层网络（openstack的vm机所用的网络必须是大二层），也是基于以太网协议的广播方式进行通信，但毫无疑问的是该虚拟网络是依赖于物理的二层网络。
（3）物理二层+虚拟二层的典型代表：VLAN网络模式。
8、物理的三层与虚拟的二层（GRE模式与VXLAN模式）
（1）物理三层指的是：物理网络是三层网络，基于IP路由的方式进行通信。
（2）虚拟的二层指的是：Neutron实现的虚拟网络仍然是二层网络（openstack的vm机所用的网络必须是大二层），仍然是基于以太网的广播方式进行通信，但毫无疑问的是该虚拟机网络是依赖于物理的三层网络，这点有点类似于VPN的概念，根本原理就是将私网的包封装起来，最终打上隧道的ip地址传输。
（3）物理三层+虚拟二层的典型代表：GRE模式与VXLAN模式。
Ⅵ Openstack和VMware Esxi的不同
首先遇到的坑是存储问题
VMware ESxi是单机系统即便使用了NFS或者其他外接存储设备，照样是映射到了系统的某个路径下。而OpenStack支持多种存储方式，任何一种存储都是用户无关的，这看似方便的设定，其实意味着最终用户根本不知道虚拟机的磁盘文件路径保存在什么位置，系统无法对文件直接操作。
处于保守考虑，整个项目第一期直接放弃了OpenStack的SAN/NFS/NAS这类共享存储的设定，每一个主机只能使用自己的本地磁盘。这种考虑其实本质上是放弃了OpenStack的集群负载能力而保留那套仅存的API，为的是换取根Esxi相类似的拓扑结构。可事实上并没有降低丝毫的复杂度，而且给日后又挖了一个不小的坑。
然后是虚拟机部署流程的问题
VMWare的所有solution的虚拟机部署流程根本上说就是一个传统上买电脑裸机的过程：定制硬件、设置好启动方式、光盘iso安装操作系统、安装配置完成交付用户。而OpenStack的虚拟机部署流程更像一个厂商安装的过程：定制硬件、通过现有的模板定制克隆一块新的虚拟硬盘、挂装硬盘到虚拟机、启动系统完成配置、交付用户。传统上用户说我有个iso想要装台虚拟机这样的过程根本不成立！而且对于我们使用的Havana版本OpenStack来说，没有任何方式可以修改默认的启动顺序，启动顺序永远是第一块硬盘为空的情况下无限尝试pxe网络启动。
作为虚拟机来说，还有一个重要的用途是通过拷贝虚拟磁盘文件的方式大量克隆主机。这对于VMware来说，第一知道文件路径；第二都是本地磁盘操作的模式来说真的非常方便，而且众所周知的是VMware对这个拷贝过程做了大量的优化，允许用户选择仅拷贝一个体积很小继承文件。但对于OpenStack来说，有现成的API可以将虚拟机直接转换成模板，然后通过模板大量部署。可问题来了：尽管只用了本地存储，OpenStack本质上是一个集群，很大的可能你虚拟机转模板或者模板转虚拟机的过程中需要跨主机之间通讯。动辄以10G计算的虚拟磁盘文件一下子就吃光了所有的网络带宽和IO，让这个过程变得极其难以预测。当然，你可以选择共享存储的方式优化OpenStack，表现上甚至于远远好于VMware 的终极解决方案Vcenter。但痛苦的是我们跳进了自己挖的坑……
接下来是网络问题
这一点上感觉其实OpenStack更适合大批量部署，OpenStack通过Neutron组件可以在虚拟机部署的同时就给虚拟机分配合适的IP并通过API返回给用户，这个IP是在DHCP里与mac直接绑定的，这也就意味着只要虚拟机的DHCP没有问题，它的IP是固定不变的。但传统上VMware必须通过工作在虚拟主机上的插件获取虚拟的IP，插件的前提是VMware愿意提供而且要记得安装，这对于很多妖孽的操作系统来说就呵呵了。由于脱胎于传统的“装机模式”Vmware似乎更推荐用户手工指定IP或者通过外部网络的DHCP，而OpenStack更喜欢自己管理一套DHCP服务。
对于VMware VCenter支持的分布式交换机技术而言，尽管我有Vcenter的环境，但受软件授权的限制并不支持，只能说说OpenStack集成了网络管理能力，支持Vlan切换和调整，但至少Exsi这个级别的产品，VMware提供的和OpenStack出入不大。但很明显的是licence 的不同导致了VMware本身网络管理的差异化也不小。
各式各样的细节问题
我们一路上碰到的各种不同之处
VMware允许用户随意的组合CPU/RAM/disk的配置，而OpenStack只允许用户在多个预先设置的CPU/RAM/disk的配置（flavor）中多选一。
电源管理部分，真心说差异太大。比如VMWare的开机按钮可以覆盖任何其他按钮事件，无论当时的状态是暂停、挂起还是关机，直接开机；而OpenStack则需要对应到暂停、恢复和开机3个按钮事件。
唯一标示的问题：VMware主机名和磁盘文件名是一一对应的，而OpenStack则不具备此特性。
控制台部分，OpenStack用noVNC的HTML5来实现控制台，而Vmware则是IE插件，兼容性你懂得。
OpenStack的各种各样的bug
吐槽部分，作为开源软件的软肋，bug是最让人头疼的，何况作为复杂的OpenStack更是如此。随便说几个吧：
novnc，当时的版本在触摸屏主机上鼠标失效，键位混乱。
虚拟机在删除网卡之后查看状态照旧，每次必现（想象下一个上百个网卡的主机吧）。尽管作为一个虚拟机管理系统会造成很大困扰，但不影响使用。离奇的是删除该问题主机后会报错说尝试删除一个不存在的网卡。
主机信息中网卡的排序混乱，你可能用于无法从虚拟机状态信息中得知那块是eth0，哪个是eth1，排序规则完全看心情。
Ⅶ 分布式存储技术与OpenStack有什么关系
他们是一种相互关系，分布式存储技术可以为openstack很好的解决存储这块的问题，而openstack和分布式存储相结合能避免它对存储这块的缺陷，查看此链接，可以学习了解存储与openstack关系 ，网页链接
Ⅷ OpenStack选用哪种后端存储系统比较好
和openstack融合度较好的就是ceph，国内大多数云环境都使用ceph作为openstack的唯一后端存储。国内使用ceph开发出分布式存储系统的厂商有深圳元核云、北京xsky等，性能都还不错的。
Ⅸ 文件系统和OpenStack对象存储有何不同
虽然HDFS与Openstack对象存储（Swift）之间有着一些相似之处，但是这两种系统的总体设计却大不一样。
1. HDFS使用了中央系统来维护文件元数据（Namenode，名称节点），而在Swift中，元数据呈分布式，跨集群复制。使用一种中央元数据系统对HDFS来说无异于单一故障点，因而扩展到规模非常大的环境显得更困难。
2. Swift在设计时考虑到了多租户架构，而HDFS没有多租户架构这个概念。
3. HDFS针对更庞大的文件作了优化（这是处理数据时通常会出现的情况），Swift被设计成了可以存储任何大小的文件。
4. 在HDFS中，文件写入一次，而且每次只能有一个文件写入；而在Swift中，文件可以写入多次；在并发操作环境下，以最近一次操作为准。
5. HDFS用Java来编写，而Swift用Python来编写。
另外，HDFS被设计成了可以存储数量中等的大文件，以支持数据处理，而Swift被设计成了一种比较通用的存储解决方案，能够可靠地存储数量非常多的大小不一的文件。
排名第二的答案来自Joshua McKenty，他是美国宇航局Nebula云计算项目的首席架构师，是OpenStack Nova软件的早期开发者之一，目前是OpenStack项目监管委员会的成员，还是Piston.cc这家基于OpenStack的公司的创始人。
Chuck刚才详细介绍了两者的技术差异，但是没有讨论两者可想而知的融合，OpenStack设计峰会上抛出了融合这个话题。简而言之，HDFS被设计成可以使用Hadoop，跨存储环境里面的对象实现MapRece处理。对于许多OpenStack公司（包括我自己的公司）来说，支持Swift里面的处理是路线图上面的一个目标，不过不是每个人都认为MapRece是解决之道。
我们已讨论过为HDFS编写包装器，这将支持OpenStack内部存储应用编程接口（API），并且让用户可以针对该数据来执行Hadoop查询。还有一个办法就是在Swift里面使用HDFS。但是这些方法似乎没有一个是理想的。
OpenStack社区方面也在开展研究开发方面的一些工作，认真研究其他替代性的MapRece框架（Riak和CouchDB等）。
最后，现在有别的一些存储项目，目前“隶属于”OpenStack社区（SheepDog和HC2）。充分利用数据局部性，并且让对象存储变得“更智能”，这是预计会取得进步的一个领域。