下载文档原格式
一、开篇介绍在云计算领域，OpenStack作为开源的云计算管理评台，被广泛应用于企业和科研机构中。
其中，创建虚拟机实例是OpenStack评台上最为基础和重要的操作之一。
本文将详细介绍如何使用OpenStack命令行工具来创建虚拟机实例。
二、准备工作1. 确保已经安装和配置了OpenStack命令行工具（OpenStackClient）。
2. 确保已经获取到OpenStack评台的认证信息，包括用户名、密码、项目名、以及认证终端URL等。
三、创建虚拟机实例的步骤1. 连接OpenStack评台在终端中通过以下命令连接到OpenStack评台：```openstack --os-username <用户名> --os-password <密码> --os-project-name <项目名> --os-auth-url <认证终端URL> login```2. 选择镜像通过以下命令列出OpenStack评台上可用的镜像：```openstack image list```选择一个合适的镜像ID，作为虚拟机实例的基础镜像。
3. 选择规格通过以下命令列出OpenStack评台上可用的虚拟机规格：```openstack flavor list```选择一个合适的规格ID，用于配置虚拟机实例的CPU、内存等资源。
4. 创建网络通过以下命令列出OpenStack评台上可用的网络：```openstack network list```选择一个合适的网络ID，用于连接虚拟机实例的网络。
5. 创建虚拟机实例通过以下命令来创建虚拟机实例：```openstack server create --flavor <规格ID> --image <镜像ID> --network <网络ID> <虚拟机名称>在命令中可以指定其它的参数，比如关联的密钥对、安全组等。
私有云平台建设方案项目背景随着云计算技术的发展，私有云平台正逐渐成为许多企业实现灵活、安全的IT 基础设施的首选。
本文将介绍一种私有云平台建设的方案，旨在帮助企业快速搭建稳定高效的私有云环境。
方案概述本方案基于开源技术构建私有云平台，包括用于虚拟化的KVM、虚拟机管理器OpenStack以及SDN技术等。
该方案具有以下特点： - 可伸缩性：私有云平台可以根据业务需求自由扩展资源。
- 高可用性：采用集群方式组织各个组件，保证系统稳定性和可用性。
- 安全性：通过访问控制、认证和加密等机制确保敏感数据的安全性。
- 灵活性：适配多种硬件环境，支持多种操作系统和应用程序。
架构设计虚拟化基础设施•使用KVM作为虚拟化技术，将物理服务器划分为多个虚拟机，实现资源的灵活分配与管理。
•借助Libvirt管理工具，对虚拟机进行集中管理，包括创建、启动、停止等操作。
•配置集群存储，实现虚拟机镜像的高可用性和快速迁移。
私有云管理平台•使用OpenStack作为私有云管理平台，提供虚拟机、网络和存储等资源的统一管理。
•部署控制节点和计算节点，控制节点提供API服务、图像服务和身份认证服务，计算节点负责虚拟机的创建和管理。
•通过OpenStack的Web界面或命令行工具，管理员和用户可以方便地管理私有云环境。
软定义网络(SDN)•引入SDN技术，将网络设备的控制和数据转发分离，实现网络的灵活性和可编程性。
•使用Open vSwitch作为虚拟交换机，实现虚拟机之间的通信和网络隔离。
•通过SDN控制器对网络进行中央管理，包括配置网络策略、监控网络流量等。
实施步骤1. 硬件准备•购买足够的服务器，满足预定规模的虚拟化需求。
•配置高速网络设备，满足虚拟机之间和与外部网络的通信需求。
•部署网络存储，用于存储虚拟机镜像和数据。
2. 软件安装与配置•在每台服务器上安装KVM和Libvirt，并进行必要的配置。
•部署OpenStack控制节点和计算节点，安装和配置必要的组件和服务。
环境：硬件及系统配置1.华硕PC机两台，主要openstack相关配置如下：●双网卡（eth0为主板集成网卡，eth1为自己购买的TPLINK TF3239DL，插在主板PCI卡槽上，注意：在ubuntu上即插即用）●i5-3350P四核●4G 内存●500G 硬盘2.网络设备机●TP-LINK TL-SF1005+ 5口百兆交换机●腾达普通路由器（办公室多人办公使用）3.物理网络连接●controller：eth0 链接外网（路由器）ip 192.168.1.10eth1 链接交换机ip 10.0.0.10●compute1：eth0 链接路由器ip 192.168.1.11eth1 链接交换机ip 10.0.0.11Havana 官方安装手册简单网络图(P4)4.系统Ubuntu server 12.04LTS ubuntu官网下载分区：/dev/sda1 95989516 2428756 88678024 3% //dev/sda2 95990540 61104 91046648 1% /nova-swift/dev/sda5 95989516 61104 91045676 1% /nova-volume/dev/sda6 139798464 60956 132629464 1% /home其中/dev/sda3为swap交换分区（要大于内存两倍，负责机器无法进入自动休眠，现在内存为4G，可能远远不够，因此暂时设置为50G）安装前准备网络配置/etc/network/interfaces1.控制节点controller:auto loiface lo inet loopback# The primary network interface#auto eth0#iface eth0 inet dhcp# Internal Networkauto eth1iface eth1 inet staticaddress 10.0.0.10netmask 255.255.255.0# External Networkauto eth0iface eth0 inet staticaddress 192.168.1.10netmask 255.255.255.0gateway 192.168.1.1dns-nameservers 192.168.1.1计算节点compute1：auto loiface lo inet loopback# The primary network interface#auto eth0#iface eth0 inet dhcp# Internal Networkauto eth1iface eth1 inet staticaddress 10.0.0.11netmask 255.255.255.0# External Networkauto eth0iface eth0 inet staticaddress 192.168.1.11netmask 255.255.255.0gateway 192.168.1.1dns-nameservers 192.168.1.12.重启网络# /etc/init.d/networking restart更改主机名字1./etc/hostname中修改为controller2.为实现各机器间的互联配置在controller和所有节点配置vi /etc/hosts127.0.0.1 localhost10.0.0.10 controller 注意不是：192.168.1.10 controller10.0.0.11 compute1 注意不是：192.168.1.11 compute13.重启，执行hostname 看修改是否生效安装Network Time Protocol (NTP)所有节点执行：# apt-get install ntp获取用于service的密码在执行数据库、消息服务器配置时，为了安全需要用到随机密码，同时使用该随机密码，使用连通这些服务：root@controller:/home/server1# openssl rand -hex 10a8aedb272ddb43cc3b62数据库mysql安装控制节点安装1.安装mysql-server 和python库文件# apt-get install python-mysqldb mysql-server2.修改配置：/etc/mysql/f[mysqld]bind-address = 10.0.0.10 (controller ip)3.重启mysql:# service mysql restart4.如果是新安装mysql删除匿名用户：# mysql_secure_installationnote:This command presents a number of options for you to secure your database installation. Respond yesto all prompts unless you have a good reason to do otherwise.计算节点安装所有计算节点安装python-mysqldb mysql-client#apt-get install python-mysqldb mysql-client安装havana架构所有节点：1. 安装ubuntu Havana 架构:# apt-get install python-software-properties# add-apt-repository cloud-archive:havana2. 更新源，升级系统# apt-get update && apt-get dist-upgrade# reboot消息服务controller节点安装：1.安装rabbitmq# apt-get install rabbitmq-server2.rabbitmq 安装时默认密码账户guest/guest不安全所以修改密码# rabbitmqctl change_password guest RABBIT_PASS环境变量文件env.sh 注意source该文件export OS_USERNAME=adminexport OS_PASSWORD=ADMIN_PASSexport OS_TENANT_NAME=adminexport OS_AUTH_URL=http://controller:35357/v2.0export OS_AUTH_URL=http://controller:5000/v2.0export OS_SERVER_TOKEN= d42bb2198d68afa0ca33身份认证服务keystone用于创建管理服务、租户等，每一个项目都要在keystone当中备案。
服务器虚拟化技术OpenStack和MicrosoftHyperV的对比服务器虚拟化技术OpenStack和Microsoft HyperV的对比在当今信息技术高速发展的时代，服务器虚拟化成为许多企业进行IT资源管理和应用部署的首选技术。
OpenStack和Microsoft HyperV作为主要的服务器虚拟化解决方案，拥有各自独特的特点和优势。
本文将对OpenStack和Microsoft HyperV进行对比分析，以帮助读者了解它们的区别和适用场景。
一、架构和部署方式1. OpenStackOpenStack是一个开源的云计算平台，其架构包括多个核心组件，如Nova（虚拟机管理服务）、Neutron（网络服务）和Cinder（块存储服务），通过这些组件可以构建跨物理服务器的弹性、可扩展的云环境。
OpenStack采用分布式架构，可以灵活地部署在各种硬件设备上，支持公有云、私有云和混合云的部署。
2. Microsoft HyperVMicrosoft HyperV是微软的虚拟化平台，它是Windows Server操作系统的一部分。
HyperV采用基于宿主机的架构，将虚拟化服务直接集成到操作系统中。
HyperV支持Windows操作系统上的虚拟化，能够方便地与其他微软产品整合，如Active Directory和System Center等。
二、功能和特性1. OpenStackOpenStack提供了丰富的功能和特性，包括虚拟机管理、网络管理、存储管理、身份认证等。
它支持多种虚拟化技术，如KVM、Xen和VMware等，并且提供了灵活的API接口，方便用户进行自动化管理和扩展。
OpenStack还具备高可用性和容错性，可以通过故障转移和自动恢复等功能保证系统的稳定性。
2. Microsoft HyperVHyperV提供了可靠的虚拟化解决方案，支持的虚拟机数量和硬件资源利用率方面表现出色。
它能够与Windows Server操作系统无缝集成，提供了直观的管理工具，如HyperV Manager和System Center Virtual Machine Manager等。
openstack新建实例各种报错解决最近⾃⼰装了下Openstack，零基础安装，参照了⽹上不少教程。
吃了百家饭的后果，就是出现了⼀堆不明问题...openstack安装⽐较复杂，很多配置⽂件，⼀个地⽅配置不正确，可能会导致后⾯的功能不可⽤。
仅以此⽂记录安装结束后，启动实例时候遇到的⼀系列错误及排查过程。
BUG 1: No valid host►报错No valid host was found. There are not enough hosts available.►解决⽅法⽹络节点执⾏[root@openstack-controller-dev ~]# vim /etc/sysctl.conf增加下⾯内容:net.ipv4.ip_forward=1net.ipv4.conf.all.rp_filter=0net.ipv4.conf.default.rp_filter=0验证是否⽣效[root@openstack-controller-dev ~]# sysctl -pnet.ipv4.ip_forward = 1net.ipv4.conf.all.rp_filter = 0net.ipv4.conf.default.rp_filter = 0BUG 2: Unable to convert image to raw►报错69ad3af8-3253-4a35-a6f1-ee5bcd1e37f2 aborted: Image 8f9cf451-764e-4219-ba0b-2edb93a9e63e is unacceptable: Unable to convert image to raw: Image /var/lib/nova/in stances/_base/9b2bd71aef84e92d7147d0eb3697710afd403a4a.part is unacceptable: Unable to convert image to raw: Unexpected error while running command.2019-11-15 01:12:18.776 162849 ERROR pute.manager [instance: 69ad3af8-3253-4a35-a6f1-ee5bcd1e37f2] Command: qemu-img convert -O raw -f qcow2 /var/ lib/nova/instances/_base/9b2bd71aef84e92d7147d0eb3697710afd403a4a.part /var/lib/nova/instances/_base/9b2bd71aef84e92d7147d0eb3697710afd403a4a.converted 2019-11-15 01:12:18.776 162849 ERROR pute.manager [instance: 69ad3af8-3253-4a35-a6f1-ee5bcd1e37f2] Exit code: 12019-11-15 01:12:18.776 162849 ERROR pute.manager [instance: 69ad3af8-3253-4a35-a6f1-ee5bcd1e37f2] Stdout: u''2019-11-15 01:12:18.776 162849 ERROR pute.manager [instance: 69ad3af8-3253-4a35-a6f1-ee5bcd1e37f2] Stderr: u'qemu-img: error while reading sector 1728 0: Input/output error\n'►排查过程⾯向百度进⾏开发后，在openstack的官⽹QA上找到了答案：镜像上传不完整.参考链接：于是重新上传，上传后发现新的问题...BUG 3： CPU feature spec-ctrl not found►报错internal error: process exited while connecting to monitor: 2019-11-15T09:42:49.789389Z qemu-kvm: CPU feature spec-ctrl not found►分析及排查经过百度查看多篇⽂章后，发现下⾯这篇说的很在理。
OpenStack高可用集群实施案例1. 规划与部署本次分享提炼自我们在某企业部署OpenStack高可用集群的实际案例，初期平台面向公网给部分部门提供虚拟化基础设施，但仍属于私有云。
其中我借鉴了以往操作比如oVirt（RHEV）、VMWare、Citrix 等项目的经验。
考虑到时间关系，本次内容将以方法为主，减少细节描述。
还有本次涉及到的工具多以开源形式呈现，尽量不涉及到产品，以方便大家集成或开发。
架构简图可参考如下，稍后我们会就其中细节进行讲解。
两个架构图的区别在于控制节点的高可用方式。
因为客户网络环境复杂，为了节省部署时间与减少返工率，我们需要在去现场之前准备好以下三种安装方式：l PXE LiveCDl 定制系统安装盘l 安装包与安装脚本第一种方式即在用户网络环境下使用现场人员笔记本或者客户服务器启动PXE服务，配置好系统架构（服务器MAC地址、网络配置、存储配置、对应的OpenStack模块与角色、定制包、系统微调与优化措施等），然后开始全自动安装，功能与Mirantis类似，但对网络要求低很多。
第二种方式既是采用定制的系统安装盘，里面需要准备尽可能多的存储设备与网络设备的驱动，以尽可能适配客户服务器与实施人员的自带存储设备。
第三种方式作为前两种方式的替补选项，主要是因为某些客户环境中安装非标系统需要走很多流程，我们提前让客户准备好操作系统，再到现场安装。
如果给你准备的系统是RHEL、SUSE或者其他标准Linux 系统的倒还好，如果他有情怀地花了一两天给你现编译上了Gentoo甚至给你准备了一台小机，那就没办法了（开玩笑，尚未遇到过这样的客户，在进厂之前要把基本环境沟通清楚）。
另外，它也可以作为以上两种安装方式失败后的最佳选项。
这几种方式也不能说孰优孰劣，从效率上来说我推荐第一种，但针对难以定制的商业虚拟化我们就只能采取手动安装的方式了。
题外话：很多所谓“5分钟装完IaaS”的“神话”都不把服务器从启动到改BIOS配BMC/IPMI的时间算进去。
1.2. 网络规划这一步骤优先级最高，我们必须在动手之前就按照功能区域把网络进行划分，包括管理、网管、存储、租户、显示、迁移等。
当然，很多情况下没必要划分太细，因为我们要根据用户网络环境和软件特性对他们进行规划，规划太细发现最后配置难以实现，“一把梭”规划发现用户一上来就喊卡。
一般来说，客户的物理网络主要以VLAN为主，其他情况暂不讨论。
对于非核心层的虚拟化而言，我们看到的多是untagged网络，所以规划时要时刻留意网关与掩码；而对于核心层的虚拟化，那么我们很有可能得到一堆tagged网络，都由我们自己与客户商讨规划。
在网络硬件上，仅就虚拟化层面而言，KVM系列的要求不高，而VMWare的FT则要求较为苛刻，万兆、IB等都是标配（题外话：KVM的FT功能尚不稳定）。
如果涉及到下面要讲到的“超融合”，那么万兆专用存储网络真的是标配了。
如果应用层面涉及到诸如Oracle之类的应用，那我们很可能就要使用网络设备透传了，也可看规划选择性地走RDMA。
当然，在现场时我们很有可能遇到交换机是全新并且客户网管也不太会配置的情况，虽然极少但也是有的。
秉着专业事儿交给专业人来干的原则，咱们可以等，等网管把交换机配好（客户沟通妥善时自带网管技能也行）。
网络规划时，我们在最大限度保证带宽的同时，要给予整体充分的可扩展性。
这次项目中，为了给予客户享受科技带来的便利，比如OpenStack Neutron便利网管、实现NFV导流、Fabric Network、Packet Broken Network、减少网络单点故障率等等，我给客户推荐了几台SDN交换机与其Neutron主机集成，然后可以在OpenDayLight里开发应用程序并与OpenStack Dashboard结合呈现出看起来高大上的界面和功能，最大限度地利用OVS。
（这里要感谢上海同悦信息龙未来先生协助开发的应用）1.3. 存储规划如果用户那有现成的存储设备那就最好不过了，但也有利有弊。
好处是减少了我们的运维负担，关键时刻也可以“甩锅”；坏处就是现有存储很可能限制我们平台的能力，也存在潜在的兼容性风险。
由于软件定义存储的风行，尤其是VMWare带来的业界领导作用，客户有可能想当然地认为虚拟化层面的存储就该我们自己负责。
那没办法了，要么找个通过兼容性测试的存储设备，要么自己上。
这时候，用户也是有选择权的，比如这次就要上Ceph，虽然我个人更偏向于Glusterfs。
这些分布式存储大同小异，与传统的集中式存储相比他们的成本低廉，性能与功能都尚可，能覆盖绝大多数普通客户的需求。
但我们上分布式存储总不能再问客户要几台服务器专门搭存储吧，那就得部分“超融合”了。
“超融合”也是现在OpenStack厂商项目部署的主流做法，比如管理组件在虚拟机中，硬件仅仅充作当作功能性代理去操作硬盘。
而本次项目中，我们也将Nova与Ceph装在同一批机器中，同时采用对两者进程的运行时环境进行了优化的系列措施，尽量减少“此消彼长”带来的影响。
1.4. 软件配置绝大部分软件都来自社区发布版本，部分核心模块来自红帽企业版，因为就踩坑几率而言社区版本更高，况且我们作为国内一个小小的软件厂商，对红帽有一种执念，哈哈。
到宿主机层面的网管软件并没有额外采购，而是继承了客户原有系统；而到虚拟化层面，则额外配置了OpenDayLight结合OpenStack Dashboard进行管理。
由于主机的存储空间较多，所以本次也就存储多网关协议进行了一些拓展，类似于OpenMediaVault和FreeNAS的功能，以方便其他平台使用。
本次部署的OpenStack仅涉及到虚拟化以及块存储相关组件，并未涉及到容器部分，因为客户选择了一家国产厂商的容器平台作为应用平台。
此种环境下的OpenStack平台仅仅提供计算与存储能力，且保证一定的容器隔离性。
题外话：针对平台软件开发的开源参考，个人认为首选OpenStack和oVirt这两者，前者走着公有云标准，后者紧跟VMWare脚步。
对于基于Docker的PaaS平台开发，我觉得使用了Kubernetes的OpenShift 是个不错的参考对象。
还有OpenStack的那个容器模块，第一印象很差，就没再碰过了。
2. 最佳实践2.1. HA策略HA即高可用（High Availability），在某些关键性服务上需要实现HA已保证业务连续性，这次项目中先就OpenStack控制节点实现HA。
总的来说实现应用的HA我总结有如下几种方式：l 负载均衡：虽然严格讲负载均衡很容易存在单点故障，但某些情况下也是一种HA方式。
l 共享存储：也就是比较经典类似PaceMaker/KeepAlived+DRBD实现的冗余，适用范围很广。
l FT：Fault Tolerance，两台机器的系统状态随时保持同步，一台宕机后另一台快速接业务，可以保证很高的业务连续性。
虚拟化平台中以VMWare最为出名，其实也有可以单独购买的FTServer，但是成本稍贵。
目前KVM系列支持不佳。
l 迁移：在很多虚拟化平台中，尤其KVM系列基本都有这一个HA措施，但缺点就是比如所在物理机宕机后，它会在其他机器上重启，所有运行时的系统状态都会丢失，业务连续性有一定损失。
当然，它也需要宿主机的存储保持同步，一般选用共享存储。
l 虚拟管理节点：这种方式叫Self-Hosted（这个我翻译不好），它也是虚拟化平台中较为常见的HA方式，即是将管理节点作为虚拟机，同时借助于迁移来保证管理节点的高可用。
目前OpenStack尚不提供社区支持，本次部署中我们使用etcd配合简单策略进行了开发，效果尚可。
其实针对不同应用不同场景HA策略仍有很多，比如实现RabbitMQ的高可用除了以上方式我们也可直接使用它的镜像（mirror）部署，实现Neutron的高可用可以使用VRRP实现分布式路由。
总之HA方法太多了，需要灵活选型与搭配。
2.1. 自服务在一些私有云项目里，仅仅部署平台是不够的，需要集成到客户的系统中将虚拟化作为正常的业务（服务）进行提供。
那这个时候，我们就很看中平台所能提供的API完善度了。
比如自服务有主机选型、计费、审计、认证对接等流程，相当一部分的工作都要在客户环境下才能完成，虽然某些产品提供了不错的接口，但是这也正是它的缺点。
比如这次对接单点登录时，发现客户环境中的系统繁多，有些老系统甚至不能进行再开发，对接难度比较大，如果不具备非常灵活的API与丰富的扩展插件，那么绕的弯子就比较多了，部署效率大大降低。
现在一些厂商有提供自服务的单独产品，开源的也有，但在使用时仍需要一定二次开发工作。
服务的无状态也与之类似，即服务本身的载体可以被随时替换。
容器平台与虚拟化平台都可以实现应用服务的无状态，但前者更加轻量。
无状态服务是一把双刃剑，优点在易维护，缺点也是难维护。
比如软件出问题我们只要重启机器就行了，但如果涉及到无状态内容，除去较为完善的补丁机制，也有可能重制底包。
以OpenStack计算节点为例，你需要的无状态内容为系统本身+nova模块相关文件，其他关键配置比如network-interface、sysctl.conf、nova.conf等等都可以单独保持，在制作光盘时就需要确定的。
2.3. 备份与恢复整体来说，很多IaaS平台的备份与恢复都相对简单，且RTO与RPO的指标都非常容易做的很漂亮。
备份方法太多，传统的软件备份厂商已经做了很多探索并且也有很好的产品了，所以这里只讲一些适用于虚拟化的备份策略。
l 整机备份：除去传统软件外，也有一些虚拟化提供的工具，比如Converter或者virt-tools。
在备份功能之外，它们都可以作为很好的PV转换手段。
l 存储域（卷）全备：既是将整个存储域进行备份，很大程度上依赖平台自身与下层存储的能力。
存储域备份也可以将颗粒度细化到虚拟机OVF，但一般不能更细。
l 快照备份：在备份KVM平台的虚拟机时，我们仍然可以将硬盘文件与快照文件单独备份，在第一次备份完成之后，以后只需要备份快照就行。
这种方法不仅适用于裸镜像文件，更适用于Ceph RBD。
在这些备份策略里，我比较常用的快照备份。
比如OpenStack平台，如果不依赖底层存储能力的话，它所能提供备份策略不酷（只到镜像级别），所以在一些项目中我们就直接从其API定位到实例的镜像再进行镜像与快照的单独备份。
当然，恢复的时候也直接恢复到实例。
需要注意的是，假如通过网络备份或恢复，传输镜像或快照文件的时候要注意文件空洞，否则会大大增加备份时间。
还有就是数据库、配置文件等有状态内容的备份，备份方法简单就不讨论了。
在恢复时，OpenStack大多数模块的恢复都比较容易，即数据、配置与数据库即可。
