ansible简介 使用python开发，以playbook作为基础部署架构 特点：仅依靠SSH协议通讯就可以完成全平台，无需编译，模块化的部署管理 作用：推送playbook进行远程节点快速部署 ansible与chef/saltstack的不同： chef： 使用ruby 语言编写，C/S架构，配置需要git依赖（实现版本控制功能） pipline脚本编写规范，需要编程经验 saltstack： 使用python语言编写，C/S架构，模块化配置管理 YAML脚本编写规范，适合大规模集群部署 （含有异步文件服务器，为客户端加快文件服务速度） ansible： python语言编写，无client，模块化配置管理 playbook脚本编写规范，易于上手，适合中小规模快速部署 优势： 1. 轻量级无客户端（agentless），SSH连接，无形中减少了客户端资源的占用，安全问题。 2. 开源免费，学习成本低，快速上手 3. 使用playbook作为核心的配置架构，统一的脚本格式批量户部署 4. 完善的模块化扩展，支持目前主流的开发场景 5. 强大的稳定性和兼容性 6. 活跃的官方社区问题讨论，方便Troubleshooting与DEBUG问题 在部署ansible环境时，避免python模块的冲突，保证部署的模块只会应用于ansible，而不会影响到其他工具的使用，将ansible与其他系统工具隔离开，使用python内置的virtualenv命令隔离python3.6语言环境，单独划分一个环境给ansible使用 ansible的部署： yum包管理安装 ansible成为系统全局下的工具，系统下任意的用户都可以使用，但是如果当前系统下的其他用户安装了其他的python模块，这里就会与ansible下的模块造成潜在的冲突。 因为在全局状态下，Python的模块安装后都会保存在Python的同一个Python扩展目录下，当ansible用到的模块与其他工具用到的模块一致时，但是调用模块的版本不同，这样势必会造成Python模块的管理混乱，最终影响产品部署交付。 我们可以clone ansible的源码至主机中，配合virtualenv实现ansible特定版本独立环境的创建，保证ansible在一个独立的python环境下运行。 ansible2.5+Python3.6部署： ``` 1. 安装python3.6版本,以及pip3 ~]# wget http://www.python.org/ftp/python/3.6.5/python-3.6.5.tar.xz ~]# tar -xvf python-3.6.5.tar.xz ~]# cd python-3.6.5 ~]# ./configure --prefix=/usr/local/ --with-ensurepip=install --enable-shared LDFLAGS=”-wi,-rpath /usr/local/lib” --prefix=/usr/local/ #指定安装目录 --with-ensurepip=install #安装pip包管理工具 --enable-shared LDFLAGS=”-wi,-rpath /usr/local/lib” #用来配置python3.6匹配当前系统的参数值 ~]# make ~]# make altinstall #~]# make && make altinstall #需要root权限执行 ~]# whitch pip3.6 ~]# ln -s /usr/local/bin/pip3.6 /usr/local/bin/pip #给pip3.6做软链接 2. 安装virtualenv，用于隔离python与ansible环境 ~]# pip install virtualenv 3. 创建ansible账户病安装python3.6版本env实例 ~]# useradd deploy && su - deploy #创建一个名为.py3-a2.5-env的实例目录 ~]# virtualenv -p /usr/local/bin/python3 .py3-a2.5-env 4. git源代码安装ansible2.5 #安装git环境及依赖 ~]# yum -y install git nss curl ~]# cd /home/deploy/.py3-a2.5-env ~]# git clone https://github.com/ansible/ansible.git ~]# cd ansible && git checkout stable-2.5 5. 加载python3.6 virtualenv环境 ~]# source /home/deploy/.py3-a2.5-env/bin/activate 6. 安装ansible依赖包 ~]# pip install paramiko pyYAML jinjia2 7. 在python3.6环境下加载ansible2.5（虚拟环境） ~]# source /home/deploy/.py3-a2.5-env/ansible/hacking/env-setup -q 8. 验证ansible2.5 ~]# ansible --version ``` ansible playbook入门和编写规范 playbooks表层目录结构： inventory/ testenv roles/ testbox/ tasks/ main.yml deploy.yml ``` 1. inventory/ #存放一个或多个server清单，用来保存目标部署主机的相关域名或者IP地址，以及该主机的变量参数。 #通常可以使用具体部署环境的名称给server清单进行命名，如devlop开发环境、UAT测试环境、production生产环境，对应保存在清单下的主机地址具体部署到哪个环境当中。 testenv文件结构： [testservers] #server组标列表标签，可以保存一个或者多个目标主机（IP或域名） test.example.com #目标部署服务器主机名 [testserver:vars] #server组列表参数（变量） #目标主机key:value键值对参数作为server组的变量声明 server_name=test.example.com user=root output=/root/test.txt 2. roles/ #用来保存我们需要部署的详细任务列表，可以存放一个或多个role，通常会命名为项目名称。 tasks/ #用于保存项目的主任务文件：main.yml main.yml任务文件 #文件位于roles目录下的项目目录下的tasks目录中，用来保存特定role下面要执行的具体任务乐章，文件中会有一个或多个task作为音符 #task一般由两部分组成 - name: print server name and user to remote testbox #任务名称，用于识别不同的task的作用 shell: “echo Currently {{user}} is logining {{server_name}} >{{output}}” #具体要执行的任务，通常会调用ansible内建的模块来编排我们的任务逻辑，此处调用的是inventory中定义的键值对参数。 3. deploy.yml #playbooks任务入口文件，它将调度我们roles/下需要去部署的项目，以及该项目下所有的任务，最终将任务部署到我们在inventory/中定义的目标主机中。 #核心文件，用来直接和ansible playbook命令直接对话，它将playbook下的编排内容展示给ansible命令，进行最终的演奏，将项目部署到对应的目标主机当中。 - hosts: "testserver" #调用对应server列表中的主机，inventory/testenv文件中的server组标签 gather_facts: ture #获取server基本信息 remote_user: root #目标服务器系统用户指定 roles: -testbox #指定roles/下的任务目录进行任务执行 ``` SSH免密认证 ``` 1. ansible服务器端创建SSH本地秘钥 ~]# ssh-keygen -t rsa #在本地创建rsa格式的公钥与私钥 2. ansible服务器端建立与目标部署机器的秘钥认证 ~]# ssh-copy-id -i /home/deploy/.ssh/id_rsa.pub root@test.example.com #将公钥传输到目标机器，实现ansible服务器端免密访问目标服务器 ``` 执行playbooks，将对应项目进行部署 ``` ~]# ansible-playbook -i inventory/testenv ./deploy.yml playbooks执行结果字段含义： PLAY RECAP #playbooks执行总结 主机名：test.example.com ok=2 #成功执行2个task changed=1 #有一个task有变动，对目标主机进行了修改 unreachable=0 #无法到达的主机数为0 filed=0 #语法结构没有错误 ``` ansible常用的模块： ``` file模块：在目录主机创建文件或目录，并赋予其系统权限 - name: create a file file: 'path=/root/foo.txt state=touch mode=0755 owner=foo group=foo’ #任务 copy模块：实现ansible服务端到目录主机的文件传递 - name copy a file copy: 'remote_src=no src=roles/testbox/files/foo.sh dest=/root/foo.sh mode=0664 force=yes’ remote_src=no #声明将ansible主机的文件传送到目标主机中 src=roles/testbox/files/foo.sh #源文件路径 dest=/root/foo.sh #目标路径 mode=0664 #指定目标主机copy的文件权限 force=yes #强制执行，同名覆盖 stat模块：用于获取远程文件状态信息，并将其信息保存在一个环境变量下供随后使用。 - name: check if foo.sh exists stat: 'path=/root/foo.sh’ register: script_stat Debug模块：打印到ansible执行输出，与stat结合使用 - debug: msg='foo.sh exists' #输出内容为:foo.sh exists when: script_stat.stat.exists #判断语句 command/shell模块：用来执行Linux目标主机命令，推荐使用shell模块 #shell环境会调用Linux环境下的/bin/bash，因此可以使用系统变量，重定向符、管道符等 #command不能使用特殊的用法 - name: run the script command: "sh /root/foo.sh" #执行目标主机上的指定目录下的脚本 - name: run the script shell: "echo 'test' > /root/test.txt" template模块：实现ansible服务端到目标主机jinja2模板传送 - name: write the nginx config file template: src=roles/testbox/templates/nginx.conf.j2 dest=/etc/nginx/nginx.conf Packaging模块：调用目标主机系统包管理工具（yum|apt）进行安装 - name: ensure nginx is at the latest version yum: pkg=nginx state=latest #CentOS|RedHat pkg=nginx #指定安装包的名称 state=latest #保证为最新的版本 - name: ensure nginx is at the latest version apt: pkg=nginx state=latest #Debian|Ubuntu service模块：管理目标主机系统服务，调用service或systemctl - name: start nginx service service: name=nginx state=started ``` Ansible 2019-05-04 评论 231 次浏览
持续集成工具Jenkins 持续部署的关注点在于项目功能部署至服务器后可以运行，为下一步测试环境测试环节或最终用户正式使用做好准备。 经常性，频繁的吧所有的模块集成在一起进行测试，有问题尽早发现，这就是持续集成。 持续集成的关注点在于尽早发现项目整体运行问题，尽早解决。使用小版本不断进行快速迭代，不断收集用户反馈信息，用最快的速度改进优化。 持续交付的关注点在于研发团队的最新代码能够让最终用户体验到。 #####CI（持续集成） 持续集成是软件开发过程中的一种实现，通过将代码仓库与jenkins集成，是开发人员的每一次代码提交都能够在jenkins上自动进行任务的build构建，帮助开发团队第一时间发现问题并解决问题。 #####CD（持续交付） 在CI的基础上将构建好的软件版本通过jenkins的测试自动化部署，持续、安全、快速地交付到用户手中。 总体目标： 降低风险 减少重复过程 任何时间任何地点生成可部署软件 增强项目的可见性 建立团队对开发团队的信心 Jenkins可以整合GitHub和Subversion 自动化部署的实现：向版本库提交新的代码后，应用服务器上自动部署，用户或者测试员使用的马上就是最新的应用程序。 #####系统结构描述： 版本控制子系统 Subversion服务器 项目对应版本库 版本库中的钩子程序 持续集成系统 #####Jenkins 主体程序 SVN插件 Mavn插件 Deploy web container插件 #####应用发布子系统 JDK TomCat Jenkins使用天气来表示构建成功率 curl命令用来发送HTTP请求 ``` ～]# curl –X post –v [Jenkins_user_name]:[Jenkins_Password] –H“请求消息头信息” –http://[server_IP]:[Port]/Jenkins/job/[Jenkins_Project]/build?token=[身份验证令牌] ``` -X 指定请求方式 -v 显示响应结果 -u 携带用户名和密码 -H 携带请求消息头信息 Jenkins_URL/job/Project_Name/build?token=TOKEN_NAME Jenkins_URL http://Server_IP:8080/jenkins job 固定名称 Project_Name 自定义项目名称 build 固定名称 ?token=TOKEN_VALUE 值在jenkins界面自定义 当触发该触发器后会完成自动构建（浏览器访问该地址也会触发构建[代码提交通知jenkins的方法]）  Jenkins： Jenkins Build的版本比代码库晚一个版本的解决办法：在Jenkins源码管理工程配置中，Repository URL为URL@HEAD，“@HEAD”意思为指向最新版区下载代码，GitHub上使用的每个repository的WebHook方式远程触发Jenkins的构建。 GitLab：开源分布式版本控制系统，使用ruby开发，管理项目源代码，版本控制复用与查找。 GitHub：分布式在线代码托管仓库，个人版本可以直接在线免费使用，企业版本收费且需要服务器安装。 GitLab的优势和应用场景： 开源免费适合中小型公司将源代码放置在该系统中 差异化的版本管理，离线同步以及强大的分支管理功能 便捷的GUI操作界面以及强大的账户权限管理功能。 集成度很高，能够集成绝大多数的开发工具 支持HA，保证在高并发下仍旧实现高可用性。 GitLab主要服务构成 1. Nginx静态web服务器，GitLab的proxy处理所有HTTPS静态访问请求。 2. GitLab-workhorse 轻量级的反向代理服务器，处理较大文件的上传下载（如push操作） 3. GitLab-shell用于处理Git命令和修改authorized keys列表 4. Logrotate 日志文件管理工具，负责处理日志的切割/打包等操作 5. Postgre sql数据库，保存所有的gitlab数据信息 6. Redis缓存服务器，加快前台的访问速度 本地需安装gitclient，保证能够进行clone gitlab的工作流程（可使开发人员并行完成后自身的feature需求，而又不会对主分支代码产生影响）： 创建并clone项目 创建项目某Feature分支 编写代码并提交至该分支 （实际环境中，管理员会创建好项目仓库，并在该仓库下根据我们的业务需求去创建若干个feature特征分支，这些feature分支会以任务的形式分发给我们的开发） 推送该项目分支至远程Gitlab服务器 在Gitlab图形界面下找到自己的代码进行代码检查并提交master主分支合并申请 项目领导审查代码并确认合并申请 GitLab应用： Gitlab拥有强大的分布式版本控制系统，也有着出色的后台管理能力，后台的管理可以针对不同的项目/不同的用户去定制不同的访问策略。 GitLab运维需要获取的系统的关键值： CPU利用率/内存/磁盘使用率 保证在gitlab在一个高并发的情况下依旧能够快速稳定运转 admin需要分配不同的人对不同的项目拥有不同的权限 保证开发人员具有分支的克隆/删除/推送/提交/合并/创建分支等权限 保证项目领导在具有开发人员权限的基础的同时，具有检查项目用户/开启/禁用/保护分支/编辑项目信息/审核确认分支的申请的权限 ``` ～]# git -c http.sslVerify=flase clone CodeRepo_Addredd(仓库地址) #输入开发人员账号密码进行代码仓库的克隆 ～]# git check -b release-1.0 #创建名为release-1.0的分支并切换进该分支 #该分支下依旧存在clone的代码文件，在该分支下进行代码的编写 ～]# git add ~]# git commit -m “release-1.0” #本地提交feature更新 ~]# git -c http.sslVerify=flase push origin release-1.0 #将代码同步到远程的release-1.0的分支中 登陆到gitlab Dev账号，在界面上可以看到新提交的代码，点击create merge request将代码合并到master分支（申请） leader登陆gitlab界面通过合并申请 ``` CI/CD 2019-05-04 评论 254 次浏览
VLAN&VXLAN简介 Vlan： 在较大的局域网内，存在多台交换机，多个网段，交换机下的所有主机都处于广播域中，会造成广播风暴，浪费宝贵的带宽资源，通过vlan标签对逻辑子网隔离，划分从逻辑上广播域。 Vlan允许的子网数量为2^12=4096 VLAN环境下不同网段的主机通信必须要经过路由或三层交换来实现。 在云环境中，多租户的场景下VLAN的子网往往是不够使用的，而且VLAN能够解决二层网络中主机之间信道的争抢，但是不能解决三层IP地址的冲突。 因此，为了解决多租户网络重叠（IP地址冲突），产生了VXLAN技术。 VXLAN是一种基于IP网络且采用MAC地址封装在UDP报文中的VPN技术。 VXLAN技术可以通过建立VXLAN隧道，在现有网络架构上建立大量的虚拟可扩展局域网，不同的虚拟可扩展局域网使用VNI（VXLAN Network Identifiler，虚拟可扩展局域网网络标识符）进行标识。 VXLAN提供和VLAN相同的2层网络服务，但相比VLAN拥有更大的扩展性和灵活性，优点如下： 多租户的网络在整个数据中心更具灵活性：VXLAN提供了一个在可靠的共享网络设施上扩展二层网络的解决方案，从而租户的负载（tenant workload）可以在数据中心跨physical pods。 VXLAN提供更多的二层网段，VLAN使用12bit的VLAN_ID表示网段名，从而网段数被限制在4096个，而VXLAN使用24bit作为VXLAN标识符（VNID），使得VXLAN的个数扩展到2^24个。 更好的在基础设施中利用网络路径（Network path）：VLAN使用STP（spanning Tree Protocol）协议防止路由环路，最终不使用网络中的网络连接半阻塞冗余路径。VXLAN数据包基于三层报头，可以完整的利用三层路由，ECMP路由以及链路聚合协议来使用所有可用的路径。 传统三层网络： 核心层：核心交换机负责骨干网络传输，对外提供业务。 汇聚层：降低核心交换机的压力，ACL、划分VLAN，控制等都是在汇聚层进行。 接入层：接入到底层的终端服务器。 在南北流量大的场景下，如果东西向流量增多（主机之间通过的层数多），会导致南北向流量拥堵。 VLAN是为解决以太网的广播问题和安全性而提出的一种协议，它在以太网帧的基础上增加了VLAN头，用VLAN ID把用户划分为更小的工作组，限制不同工作组间的用户互访，每个工作组就是一个虚拟局域网。虚拟局域网的好处是可以限制广播范围，并能够形成虚拟工作组，动态管理网络。 GRE VPN（Generic Routing Encapsulation）即通用路由封装协议，是对某些网络层协议（如IP和IPX）的数据报进行封装，使这些被封装的数据报能够在另一个网络层协议（如IP）中传输。 GRE是VPN（Virtual Private Network）的第三层隧道协议，即在协议层之间采用了一种被称之为Tunnel（隧道）的技术。 随手笔记 2019-04-27 评论 342 次浏览
RabbitMQ RabbitMQ是什么？ RabbitMQ是实现AMQP（高级消息队列协议）的消息中间件的一种，最初源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性方面表现不俗。 RabbitMQ主要是为了解决系统之间的双向解耦而实现的，当生产者大量产生数据的时，消费者无法快速消费，那么需要一个中间层保存这个数据。 rabbitmq是一个消息代理，一个消息系统的媒介，它可以为你的应用提供一个通用的消息发送和接收平台，并保证消息在传输过程中的安全。 随着系统压力的增大和系统解耦的急迫性，各大应用之间通过消息队列互相连接起来组成一个更大的应用，并且消息系统通过将消息的发送和接收分离来实现应用程序的异步和解耦。 通过接入rabbitmq解决了数据传递，非阻塞操作和推送通知的操作，实现了发布/订阅、异步处理和工作队列的问题。 RabbitMQ的特点： ①可靠性：RabbitMQ提供了多种技术，可以让使用者在性能和可靠之间进行权衡，这些技术包括持久性机制、投递确认、发布者证实和高可用性机制。 ②灵活的路由： 消息队列到达队列前是通过交换器进行路由的，RabbitMQ为典型的路由逻辑提供了多种交换器类型，如果使用者有更复杂的路由需求，可以将这些交换器组合起来使用，甚至可以实现自己的交换器类型，并当做RabbitMQ的插件来使用。 RabbitMQ提供的内置交换器4中类型中，我们常使用到的有三种，分别是：direct exchange（直连交换器）、topic exchange（主题交换器）、fanout exchange（扇形交换器），RabbitMQ支持多种中间件协议。 ③集群：在相同的局域网中的多个RabbitMQ服务器可以聚合在一起，作为一个逻辑代理来使用。 ④高可用队列：在同一个集群中，队列可以被镜像到多个物理机器中，以确保当中某些硬件故障后消息仍然安全。 ⑤广泛的客户端：只要是能够想到的编程语言，几乎都有与其相适配的RabbitMQ客户端 ⑥可视化管理工具：RabbitMQ给我们提供了易于使用的可视化管理工具，它可以帮助使用者监控信息代理的每一个环节 Direct exchange（直连交换器）  转发消息到routingkey（路由键）指定的队列，routingkey是一个消息的原属性，由生产者加在消息头中。 XQ1 有一个routingkey，routingkey为orange XQ2 有两个routingkey，routingkey为black和green 当消息队列的routingkey（路由键）和routingkey对应时，这个消息去往对应的队列中。 topic exchange（主题交换器） 按规则（通配符）转发消息，这种交换机制下，队列和交换机的绑定会定义一种路由模式，通配符就是要在这种路由模式和路由键之间匹配后，交换器才能够进行消息的转发  XQ1 有一个路由模式*.orange.*来匹配任何A.orange.B类似的路由键的消息 XQ2 有两个路由模式*.*.rabbit和lazy.#来匹配任何A.B.rabbit和lazy.A、lazy.A.B或者lazy.A.B.C，其中“#”表示一个或多个单词 主题交换器严格区分*.*和lazy.#,在生产环境中尽量不要使用#作为routingkey（路由键） 在指定路由键的时候最好指定准确的路由键作为routingkey fanout exchange（扇形交换器） 转发消息到所有的绑定队列，如果有不同的consumer（消费者）需要对童谣的消息进行不同的处理，使用这种方式是很有用的。 这种类型的交换器，不管是路由键或者是路由模式，会把消息发送给绑定给它的全部队列。  RabbitMQ的模型 RabbitMQ使用的是AMQP协议，这是一种二进制协议，默认启用的端口为5672  P代表消息生产者，也就是网RabbitMQ发消息的程序 中间件为RabbitMQ，其中包括交换器和队列 C代表消费者，也就是从RabbitMQ拿消息的程序 RabbitMQ的集群 RabbitMQ搭建有三种模式，其中集群模式有两种 ①单一模式 单机情况不做集群，单独运行一个RabbitMQ ②普通模式 默认模式，以两个节点（node_01、node_02）为例来进行说明，对于Queue来说，消息实体只是存在于其中的一个节点（node_01或node_02）,node_01和node_02有相同的元数据，即队列结构，当消息进入node_01节点的Queue后，consumer从node_02节点消费时，RabbitMQ会临时在node_01、node_02间进行消息传输，将node_01中的消息实体取出并经过node_02发送给consumer，所以consumer应当尽量连接每一个节点，从中获取消息。即对于同一个逻辑队列，要在多个节点建立物理Queue，否则无论consumer连接node_01或者node_02，出口总在node_01，这样会产生瓶颈，当node_01节点故障，node_02节点无法获取到node_01节点中还未消费的消息实体，如果消息做了持久化，那么就得等node_01节点恢复，然后才可以消费，如果没有做持久化，就会产生消息丢失的现象。 ③镜像模式 把需要的队列做成镜像队列存在于多个节点，属于RabbitMQ的HA方案，该模式下解决了普通模式中的问题，其实和普通模式不同之处在于，消息实体会主动的在镜像节点间同步，而不是在客户端取数据的时候临时拉取，该模式带来的副作用也很明显，除了降低系统的性能外，如果奖项队列数量过多，加之大量的消息进入，集群内部的带宽将会被这种同步通讯大大消耗，所以在对可靠性要求较高的场合中适用。 RabbitMQ集群搭建的注意事项 ①所有机器上，运行的erlang和rabbitmq的版本需相同（否则RabbitMQ之间不能连接到一起） ②所有机器上erlang的cookie需要相同，将/var/lib/rabbitmq/.erlang.cookie复制到其他节点，保证一直，且权限的设置要符合标准（属主属组为rabbiymq） ~]# chown rabbitmq.rabbitmq /var/lib/rabbitmq/.erlang.cookie #修改后需重启服务 两个节点的RabbitMQ集群搭建 搭建epel源，配置主机名DNS解析， ~]# yum install erlang ~]# yum -y install rabbitmq-server ~]# rabbitmq-server -detached #启动 #将/var/lib/rabbitmq/.erlang.cookie复制到其他节点，并修改属主属组 node_01操作： ~]# rabbitmqctl stop_app ~]# rabbitmqctl reset ~]# rabbitmqctl join_cluster rabbit@node_02 #加入node_02集群中 ~]# rabbitmqctl start_app node_02上查看加入集群的状态 ~]# rabbitmqctl cluster_status ~]# netstat -antp #查看rabbitmq之间建立的连接 新增用户： ~]# rabbitmqctl add_user admin 123456 #新添加用户admin，并指定密码123456 ~]# rabbitmqctl set_user_tags admin administrator ~]# rabbitmqctl set_permissions -p / admin ".*" ".*" ".*" #给用户admin授予默认vhost"/"read/write/configure权限 开启图形化管理界面 ~]# rabbitmq-plugins enable rabbitmq_management #访问http://RabbiyMq_Server_IP:15672 #建议使用rabbitmq3.6.9以上的版本和erlang最新的版本 服务 2019-04-27 评论 339 次浏览
OpenStack组件 IAAS基础设施即服务，面向运维人员 PAAS平台即服务，面向开发人员 SAAS软件即服务，面向用户终端 服务器虚拟化：将一台物理机服务器做成虚拟机 桌面虚拟化：只提供一个桌面，用户的操作限制在桌面 应用虚拟化：采用B/S架构方式实现，但是代价较大 OpenStack：使用Python写的，通过消息队列进行通信，模块化。 Dashboard：管理界面，通过API调用接口。 Dashboard horizon 基于OpenStack API接口使用Django开发的web管理 Compute nova 通过虚拟化技术提供计算资源池 Networking neutron 实现了虚拟机的网络资源管理 Object storage swift 对象存储，适用于一次写入多次读取，写入后不可更改 Block storage cinder 块存储，提供存储资源池 Identity service keystone 认证管理 Image service glance 提供虚拟镜像的注册和存储管理 Telemetry ceilometer 提供检测和数据库采集计量服务 Openstack通过API的方式调用服务，REST API 调用的方式： curl、firefox plugin、restclient-ui-3.4-jar（java写的在Windows下的工具） 只要能够支持HTTP协议就能够进行调用 Xshell用户信息添加页面上可以对远端主机进行端口的映射（通过22端口将远端服务器端口映射到本地：127.0.0.1:xxxx） 查询请求：get 修改请求：put 云平台的部署要根据用户的需求对各个组件进行选择，参照需要启动多少实例，实例的配置，镜像的数量等对硬件需求进行规划。在生产环境中安装使用种子节点的方式，既作为控制节点又作为种子节点，使用PXE对镜像和软件进行推送。 部署openstack的顺序： ①安装控制节点操作系统和网络配置 ②控制节点安装必要的中间件和相关系统服务 ③控制节点组件安装 ④（SDN）网络节点操作系统安装 ⑤（SDN）网络节点安装必要的中间件和相关系统服务 ⑥（SDN）网络节点组件安装 ⑦计算节点操作系统安装 ⑧计算节点安装必要的中间件和相关系统服务 ⑨计算节点组件安装 CentOS_7上安装OpenStack注意事项： 采用本地yum源构建速度会快很多，可以使用FTP服务器提供服务 关闭NetworkManager 关闭firewalld 关闭selinux 设置主机名并搭建DNS，可以使用host解析，也可使用bind提供服务，controller上搭建 搭建时间服务器，在控制节点上安装。 注意：openstack使用主机名来进行区分，如果某节点主机名被修改会造成不可逆的操作。 OpenStack网络示意图  Keystone验证流程：  用户创建虚拟机的流程：  ~]# keystone token-get #以当前用户身份获取一个token Openstack平台搭建的时候租户、用户、角色的创建流程： 先创建租户 创建用户时指定属于那个租户 创建角色，默认有两个角色:admin（管理员），member（普通用户），角色可自定义 绑定角色，将角色分配到具体的某个用户，这个用户在这个租户下是什么角色 镜像-glance Image identifiers Image_URI(<glance server location>/images/<ID>全局唯一的定位符) Image status（对镜像操作的状态） Queued：镜像已经被保留（metadata已经写入数据库，但是还没有上传镜像。） Saving：镜像正在被上传 Active：镜像可以使用 Killed：镜像损坏或者不可用 Deleted：镜像被删除（只有拿着被删除的镜像的ID去查找的时候才会出现，在dashboard上不会显示。） Disk format： Raw：裸数据，二进制组成，占用磁盘较大，启动虚拟机较快。 Vhd：vmware、xen、microsoft、virtualbox支持的格式 Vmdk：vmware发起的开源的磁盘格式 Vdi：virtualbox、QEMU、emulator支持 Iso：主要是归档使用 Qcow2：用于kvm虚拟机上，磁盘支持扩展，磁盘动态变化、支持快照 Container format（容器格式）： Bare：裸格式 Ovf：虚拟机格式，使用较多 Glance API用于处理HTTP请求 Glance_DB：metadata for image，存储镜像的元数据信息 Store adapter：image的存储方式由store image决定，通常我们是用文件系统的方式进行存储。 存储的方式可以是filesystem、swift storage、S3（simple storage servers） 亚马逊镜像的存储方式、HTTP storage（也可以将镜像放到HTTP服务器上）。 RDB：ceph（分布式块存储）等存储方式。 Glance镜像的定制： 定制的需求： 包的添加与删除 Linux的优化 支持秘钥登录等预设定功能 首先到官网下载能在openstack上使用的镜像 1. 先创建一个10G的文件 ~]# qemu-img create –f qcow2 image-test.img 10G 对于创建好的文件可以使用file命令查看文件的类型 2. 创建虚拟机 ~]# virsh-install --name VM_NAME --hvm –ram 2048 --vcpus 4 –disk path=/var/tmp/image-test.img size=10,bus=virtio,format=qcow2 --network network:default --acclerate --vnc --vncport=5908 --cdrom /var/tmp/centos-xx-xx.iso -boot cdrom xhell想要看到虚拟机内的图形界面，需要在xshell中开启x11隧道转发（需要manager）通过22端口。 启动起来的操作系统删除网卡的MAC、UUID等硬编码信息（70的配置文件） 禁用防火墙，清空/etc/sysconfig/iptables中的规则信息 默认启用SSH服务 开机自动resize根分区 设置使用SSH密钥对连接 设置YUM源 ~]# yum -y install cloud-init #针对云的运行环境需要使用到的一些功能 ~]# vi /etc/cloud/cloud.conf #通过更改该配置文件可以定义instance启动起来后的一些行为。 ~]# shotdown -h now #修改完成关机，此时需要注意的是不能开机，否则需要重新修改。 将imag-test.img作为镜像上传至glance服务器，镜像制作完成。 使用virtualbox也能够完成镜像的制作 创建vmdk格式的硬盘文件的虚拟机 安装操作系统并进行相应的修改，关机 将vmdk文件上传到Linux主机上进行格式的转换 ~]# qemu-img convert -f vmdk -O raw CentOS_6.vmdk CentOS_6.img #现将vmdk格式的镜像转成raw格式，不能直接转成qcow2的格式 ~]# qemu-img convert -f raw -O qcow2 CentOS_6.img CentOS_6.qcow2 ~]# qemu-img info 镜像名称 #查看镜像的信息 修改镜像中的内容： 使用guestfish工具，需要先安装 ~]# guestfish --rw -a 镜像名 进入guestfish工具环境 >run 启动镜像 >list-fliesystems 3查看磁盘及文件系统类型 >mount /dev/sda1 / #将root挂载到根上 >upload 本地文件 镜像目录下的文件 #上传文件到镜像中，徐志鼎镜像中的文件名，不能自动生成 >download 镜像文件 本地目录下的文件 #将镜像中的文件下载到本地 安装软件等操作不适合在此处进行。 nova核心组件： controller节点组件： nova-api 接口，用于接收http请求 nova-schedule 计算资源调度 nova-conductor 连接数据库的Proxy（避免直连数据库，大量的直连导致数据库的压力无法均衡） nova-conductor 认证 nova-novncproxy vnc proxy（避免直接访问vnc） compute节点组件： nova-compute 负责虚拟机的管理 client： nova-client 向nova发起请求的客户端 nova-manage 运维组件管理操作工具 nova主要是提供计算服务，大致服务框架如下：  nova内部组件的交互： 采用RabbitMQ Queues（消息队列），异步通信，组件之间是松耦合关系。 如果采用API的方式，强耦合使得服务的拆解变得困难。 对应的服务只需要监控消息队列，即可完成消息的获取。  nova启动innstance的流程，涉及两个节点： nova：cloud controller nova：compute node 以及其他公用的组件，如glance、swift等  ~]# virsh list --all #查看当前计算节点上的实例 ~]# virsh edit Instance_ID #显示指定实例的VNC端口号 ~]# cd /var/lib/nova/instance/ #该目录下是以虚拟机ID命名的目录，实例启动后存放磁盘的目录。 console.log 启动过程日志 disk 虚拟机的磁盘 libvirt.xml instance描述文件 ./base 为glance下载的镜像 ~]# virsh vncdisplay Instance_ID #显示指定实例的VNC端口号 ~]# qumu-img info /var/lib/nova/instance/base/Image_File #查看镜像文件格式 创建虚拟机常见的错误： 401：认证错误 检查用户名密码是否输入正确 检查认证配置是否正确 409：查看nova服务是否正常运行 No Valid host错误 查看是不是有可用的资源（compute节点） 调高配置资源，或者删除一些无用的主机。 网络不通： 查看dhcp（dnsmasq）、查看路由、查看openswitch服务是不是crash。 查看instance启动流程 编辑计算节点下配置文件 ~]# vim /etc/nova/nova.conf #开启debug，并开启日志 ~]# /etc/init.d/openstack-nova-api restart #重启nova-api服务 OpenStack网络： LInux interface type： TAP/TUN kvm等Hypervisor虚拟网卡的实现 TUN and TAP device have 啊/sys/class/net/tap0/tun-flags file bridge 相当于交换机，所有的物理网卡收到的包都是一样的，每个网卡只抓取自己的数据包 brideg have a /sys/class/net/br0/bridge directory loopback 回环网卡 bridge and loopback interface have 00:00:00:00:00:00 in /sys/class/net/lo/address physical 物理网卡 physical device have a /sys/class/net/eth0/device symlink floast IP(浮动IP)的实现需要物理网卡开启混杂模式（promiscuous mode） "UP BROADCAST RUNING MULTICAST" 网卡信息中显示此条信息表示已开启混杂模式。 依靠dnsmasq服务实现DHCP功能 DNSmasq是一个小巧且方便地用于配置DNS和DHCP的工具，适用于小型网络，它提供了DNS功能和可选择的DHCP功能。它服务那些只在本地适用的域名，这些域名是不会在全球的DNS服务器中出现的。DHCP服务器和DNS服务器结合，并且允许DHCP分配的地址能在DNS中正常解析，而这些DHCP分配的地址和相关命令可以配置到每台主机中，也可以配置到一台核心设备中（比如路由器），DNSmasq支持静态和动态两种DHCP配置方式。 LXC：Linux Container容器是一种内核虚拟化技术，可以提供轻量级的虚拟化，以便隔离进程和资源。网络隔离，主机上可以配置多个相同IP地址或相同网段的网卡。 叠加网络： 1. 一个数据包封装在另一个数据包内，被封装的包转发到隧道断电后在进行拆装。 2. 叠加网络就是使用这种"包内之包"的技术安全的将一个网络隐藏在另一个网络中，然后将网络区段进行迁移。 VLAN：L2 over L2 GRE：L3 over L3（UDP） VXLAN：L2 over L3（UDP） atp设备： tap设备是kvm虚拟机网卡的实现类型，虚拟机可以通过tap设备和连接在另一端的设备进行通信。 tap设备的查找方式： ~]# cat /etc/libvirt/qumu/instance-XXX.xml #虚拟机xml文件 可以在xml文件中看到<target dev='tapb……'/> 虚拟网络对（VETH，Virtual Ethernet Pair） 将两个网卡直接连接起来，在一端发怵消息，在另一端可以完整的收到，类似于网线的作用，用于连接bridge和switch（不同虚拟网之间的连接）。 虚拟网络对（VETH）设备的查看： ~]# ip a ~]# ethtool -S 设备名 #可以看到成对的VETH设备的index编号是连续的，即成对出现。 Linux Bridge的使用 bridge相当于HUB设备，转发接收到的数据包到所有端口 bridge的查看方式： ~]# brctl show #网桥上有两个设备，一个是连接虚拟机的tap设备，一个是连接open switch的虚拟网卡对，也可以通过虚拟机的xml文件进行查看。 #] cat /etc/libvirt/qemu/instance-xxx.xml #体现在interface标签中 neutron SDN实现： neutron SDN的实现是在计算节点和网络节点上实现的。 实例通过tap设备连接到br-int（open vswitch bridge）  neutron SDN GRE的实现 br-int与br-tun之间由虚拟网络对连接（patch-tunpatch-int），br-tun是专门用于同其他主机建立隧道的bridge，数据通过建立的隧道到达Network node节点的br-tun（通过指定IP到达），br-tun通过虚拟网络对连接（patch-intpatch-tun）br-int，在network上的br-int上有一个特殊的网口qrXX，它属于br-int网桥，同时它暴露在物理层，连接到br-ex的qgXX,图中红色虚线为同一个namespace，namespace中配置了source NAT规则，在同一个网桥下的eth0物理网卡收到数据包，并将其转发到Internet。 计算节点网络的实现 open switch的使用： 在open switch上可以配置端口和VLAN ~]# ovs-vsctl show #每创建一个虚拟机都会多出四个虚拟网卡 #在compute节点上，网桥以qb开头（连接虚拟机的bridge），q为前一代网络组件名称的简写。 虚拟网络对的识别： qvo：连接到open vswitch qvb：连接到bridge  虚拟机的网卡是由tap设备提供的，tap设备的另一端连接到Linux网桥上，再由虚拟网络对连接到open vswitch，从此tap设备出来的数据包会带有port VLAN tag标记。因此，不同的虚拟机如果属于同一个子网，port ID是一样的，再通过虚拟网络对从open vswitch连接到open vswitch的bridge上，这个bridge是直连物理网卡的，因此和外网是通的，在此处（bridge）会将虚拟机的VLAN转换成物理机的VLAN_ID 网络节点network ~]# ovs-vsctl show #查看open vswitch的网络状态 #当open vswitch接收到数据包的时候会将数据包转发给相同tag标记的port #此处显示的tap设备是DHCPserver的网卡 ~]# ip netns #可以看到3个namespace（一个网络中） #qrouter用于路由，该命名空间中有相应网段的网关（web界面上需要使用amdin查看，因为网络是admin创建的） #namespace名称的后缀是网络的ID ~]# ip netns exec NameSpace ip a #查看namespace中的内容，可以找到与DHCPserver先关的tap设备，因此命名网络空间中的tap设备就是DHCPserver ~]# ps -ef |grep dnsmasq #可查看相关进程，DHCP服务器进程 ~]# ip netns exec qrouterXXX route #W查看命名空间中的路由表 ~]# ip netns exec qrouterXXX iptables -t nat -nL #查看命令空间中的NATO转发规则 OpenStack+Ceph 2019-04-27 评论 682 次浏览
OpenStack+Ceph在Ceph底层删除卷——慎用！建议从OpenStack层面进行删除操作。 我门在删除云平台快照的时候，会遇到快照被依赖的情况，这个时候可能在openstack层面删除不掉，需要从ceph底层解决： ``` ~]# rbd snap rm volumes/volume-db3aee3c-b549-48d9-8cdc-65a801845c6c@snapshot-dd42a722-be84-4792-8557-e50b1aaa2b05 Removing snap: 0% complete...failed. rbd: snapshot 'snapshot-dd42a722-be84-4792-8557-e50b1aaa2b05' is protected from removal. ~]# rbd children volumes/volume-db3aee3c-b549-48d9-8cdc-65a801845c6c@snapshot-dd42a722-be84-4792-8557-e50b1aaa2b05 ~]# rbd snap unprotect volumes/volume-db3aee3c-b549-48d9-8cdc-65a801845c6c@snapshot-dd42a722-be84-4792-8557-e50b1aaa2b05 ~]# rbd snap rm volumes/volume-db3aee3c-b549-48d9-8cdc-65a801845c6c@snapshot-dd42a722-be84-4792-8557-e50b1aaa2b05 ``` OpenStack+Ceph 2019-04-25 评论 492 次浏览
