实验需要使用 kolla 部署 openstack mitaka环境，由于是两年前的版本，实验过程中遇到了一些坑，记录如下。

系统环境

操作系统：CentOS Linux release 7.2.1511 (Core)
内核版本：3.10.0-327.28.3.el7.x86_64
kolla版本：mitaka-eol
docker版本：Docker version 1.13.1, build 092cba3
docker镜像：官方tag 2.0.2 (对应 openstack mitaka版本)

问题一: openvswitch_db 容器无法运行

问题描述

kolla-ansible deploy 部署openstack的时候总会遇到 openvswitch_db service 无法启动的问题

TASK: [neutron | Waiting the openvswitch_db service to be ready] ************** 
failed: [localhost] => {"attempts": 30, "changed": false, "cmd": ["docker", "exec", "openvswitch_db", "ovs-vsctl", "--no-wait", "show"], "delta": "0:00:00.032518", "end": "2018-07-09 07:33:12.680647", "failed": true, "rc": 1, "start": "2018-07-09 07:33:12.648129", "stdout_lines": [], "warnings": []}
stderr: Error response from daemon: Container 0cec739aabe06805aa0e1624318ac052d9f8fb176078df3d20a13c4df304fa7a is restarting, wait until the container is running
msg: Task failed as maximum retries was encountered

FATAL: all hosts have already failed -- aborting

查看容器日志有如下报错

INFO:__main__:Kolla config strategy set to: COPY_ALWAYS
INFO:__main__:Loading config file at /var/lib/kolla/config_files/config.json
INFO:__main__:Validating config file
INFO:__main__:Copying service configuration files
INFO:__main__:Writing out command to execute
Running command: '/usr/sbin/ovsdb-server /var/lib/openvswitch/conf.db -vconsole:emer -vsyslog:err -vfile:info --remote=punix:/run/openvswitch/db.sock --log-file=/var/log/openvswitch/ovsdb-server.log'
ovsdb-server: I/O error: open: /var/lib/openvswitch/conf.db failed (No such file or directory)

1. 安装依赖

# yum install gcc kernel-header kernel-devel

2. 解压源码并编译

# tar zxvf ixgbe-5.3.7.tar.gz
# cd ixgbe-5.3.7/src/
# make

此时还是有以下错误

# make
common.mk:102: *** Kernel header files not in any of the expected locations.
common.mk:103: *** Install the appropriate kernel development package, e.g.
common.mk:104: *** kernel-devel, for building kernel modules and try again.  Stop.

打开 common.mk 发现编译时需要 /usr/src/linux 目录，但是系统并没有此目录，手动创建 /usr/src/kernels/3.10.0-862.6.3.el7.x86_64/ 到 /usr/src/linux 的链接即可

# ln -s /usr/src/kernels/3.10.0-862.6.3.el7.x86_64/ /usr/src/linux

关于 SR-IOV 本文就不再介绍了,具体可以查看 Intel® 82599 SR-IOV Driver Companion Guide。

一、系统环境

操作系统: RHEL 7.2
OpenStack版本: OpenStack Mitaka Allinone
网卡型号: Intel Corporation 82599ES
SR-IVO网卡名: ens1f0, ens1f0

二、服务器配置

在服务器 BIOS 中开启 VT-d 和 SR-IOV

三、操作系统配置

1. 编辑 /etc/default/grub 文件,加入以下内容

# vim /etc/default/grub

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
-GRUB_CMDLINE_LINUX="rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet"
+GRUB_CMDLINE_LINUX="rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet intel_iommu=on"
GRUB_DISABLE_RECOVERY="true"

需要说明的是: ixgbe.max_vfs 参数已经废弃，故没有加入到内核参数中。

1. 发现问题

发现某个节点无法查询网络，继而发现所有的客户端都无法正确查询，而且错误相同

cinder 服务无法访问
[root@controller01 ~]# cinder list
ERROR: Unable to establish connection to http://nt-controller:8776/v2/364307d25ca8465daa7982dafc625f05/volumes/detail: ('Connection aborted.', BadStatusLine("''",))

nova服务无法访问
[root@controller01 ~]# nova list
/usr/lib/python2.7/site-packages/novaclient/client.py:278: UserWarning: The 'tenant_id' argument is deprecated in Ocata and its use may result in errors in future releases. As 'project_id' is provided, the 'tenant_id' argument will be ignored.
  warnings.warn(msg)
ERROR (ConnectFailure): Unable to establish connection to http://nt-controller:8774/v2.1/364307d25ca8465daa7982dafc625f05/servers/detail: ('Connection aborted.', BadStatusLine("''",))

2. 问题排查

手动 telnet 端口可以连接

[root@controller01 ~]# telnet nt-controller 8774
Trying 192.168.105.253...
Connected to nt-controller.
Escape character is '^]'.

Connection closed by foreign host.

conductor 和 api 服务有无法连接数据库的错误

2018-05-30 02:16:08.609 29270 ERROR nova.servicegroup.drivers.db     return self.dbapi.connect(*cargs, **cparams)
2018-05-30 02:16:08.609 29270 ERROR nova.servicegroup.drivers.db   File "/usr/lib/python2.7/site-packages/pymysql/__init__.py", line 90, in Connect
2018-05-30 02:16:08.609 29270 ERROR nova.servicegroup.drivers.db     return Connection(*args, **kwargs)
2018-05-30 02:16:08.609 29270 ERROR nova.servicegroup.drivers.db   File "/usr/lib/python2.7/site-packages/pymysql/connections.py", line 694, in __init__
2018-05-30 02:16:08.609 29270 ERROR nova.servicegroup.drivers.db     self.connect()
2018-05-30 02:16:08.609 29270 ERROR nova.servicegroup.drivers.db   File "/usr/lib/python2.7/site-packages/pymysql/connections.py", line 947, in connect
2018-05-30 02:16:08.609 29270 ERROR nova.servicegroup.drivers.db     raise exc
2018-05-30 02:16:08.609 29270 ERROR nova.servicegroup.drivers.db DBConnectionError: (pymysql.err.OperationalError) (2003, "Can't connect to MySQL server on 'nt-controller' ([Errno 111] ECONNREFUSED)")

查看数据库集群状态(集群正常)

MariaDB [(none)]> SHOW STATUS LIKE 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+

3. 问题解决

全部服务都无法连接，而keystone服务又是正常（鉴权服务不在本地），数据库服务也正常，同时和这么多服务有关联的就是 haproxy 了，手动重启 haproxy 后问题解决（haproxy监听端口正常，可能发生了crash）。

1. 发现问题

安全加固后的虚拟机使用普通用户登陆，然后切换到 root 用户的时候有如下报错

$ su root
Password: 
su: Module is unknown

2. 查找错误

查看 /var/log/secure 文件有如下错误, 找不到库文件 pam_tally.so

# vim /var/log/secure
Apr 16 16:45:32 compute01 sshd[21311]: pam_unix(sshd:session): session opened for user vmuser by (uid=0)
Apr 16 16:45:34 compute01 su: PAM unable to dlopen(/usr/lib64/security/pam_tally.so): /usr/lib64/security/pam_tally.so: cannot open shared object file: No such file or directory
Apr 16 16:45:34 compute01 su: PAM adding faulty module: /usr/lib64/security/pam_tally.so

3. 解决办法

把 pam_tally2.so 链接到 pam_tally.so

# ln -s /lib64/security/pam_tally2.so /lib64/security/pam_tally.so

Zun 容器服务简介

Zun 允许用户无需管理服务器或集群即可快速启动和运行容器。它通过与 Neutron 、Cinder、Keystone 和其他核心 OpenStack 服务集成，无缝地将先进的企业网络、存储和身份验证功能添加到容器中。
Zun目标在于解决 Nova Docker driver方案存在的问题，独立于 Nova 之外实现 Docker 部署调度框架，自身实现与 Glance、Neutron、Cinder等组件的集成，但并不实现对容器编排引擎（Container Orchestration Engines COE）的部署调度。Nova-docker通过Nova API访问容器，而Zun不受Nova API的限制。
Zun和Magnum的差异在于Zun目标是提供管理容器的API，而Magnum提供部署和管理容器编排引擎（COE）的API。Zun将容器作为Openstack管理的资源，为用户提供了创建和管理这些容器的接口。被Zun管理的容器和其他Openstack资源能够良好的集成在一起，例如Neutron网络和Cinder卷。用户使用统一的、简化的API接口来管理容器，而不需要关心不同容器技术的差异。
Zun不准备实现COE提供的很多先进的功能（例如容器保活、负载均衡等），而是提供基本的容器操作（CRUD），并和Openstack紧密集成。

OpenStack Queens 平台于2月28日正式发布，这是该开源云平台的第17版。OpenStack Queens 增加了多项新功能，也优化增强了多项旧功能，包括虚拟 GPU（ vGPU ）支持和容器集成的改进。几个新项目也在 OpenStack Queens 这一里程碑中露面，包括提供管理硬件和软件加速资源框架的Cyborg 。
Queens 发布了一些强大的面向企业的功能，其中最引人注目的是 Cinder 中的 Multi-Attach 功能。Cinder Multi-Attach 使运维者能够将相同的Cinder 卷加载到多个 VM 中。如果一个节点关闭，另一个节点能够接管并访问该卷。

host-only 联网

iptables -t nat -A POSTROUTING -s 10.20.0.0/24 -j MASQUERADE

10.20.0.0/24 为 host-only 网段

制作源

# vim /usr/share/fuel-mirror/ubuntu.yaml
- ubuntu_baseurl: &ubuntu_baseurl http://archive.ubuntu.com/ubuntu
+ ubuntu_baseurl: &ubuntu_baseurl http://mirrors.aliyun.com/ubuntu
mos_baseurl: &mos_baseurl http://mirror.fuel-infra.org/mos-repos/ubuntu/$mos_version

# fuel-createmirror

bootstrap

更换国内源

# vim /etc/fuel-bootstrap-cli/fuel_bootstrap_cli.yaml

repos:
    - name: ubuntu
      section: "main universe multiverse"
-     uri: "http://archive.ubuntu.com/ubuntu"
+     uri: "http://mirrors.aliyun.com/ubuntu"
      priority:
      suite: trusty
      type: deb
    - name: ubuntu-updates
      section: "main universe multiverse"
-     uri: "http://archive.ubuntu.com/ubuntu"
+     uri: "http://mirrors.aliyun.com/ubuntu"
      priority:
      suite: trusty-updates
      type: deb
    - name: ubuntu-security
      section: "main universe multiverse"
-      uri: "http://archive.ubuntu.com/ubuntu"
+      uri: "http://mirrors.aliyun.com/ubuntu"
      priority:
      suite: trusty-security
      type: deb

Hexo 环境搭建

使用 coding 和 github.io 的 pages 服务，绑定了自己的域名，做了双线解析，国内用户解析到 coding ,国外用户解析到 github.io，访问速度很满意(本来就是静态文件，访问速度很快)。
Hexo 环境的搭建，这里不再赘述，主要介绍如何导出 typecho 的数据和 Hexo 站点的配置以及 Next 主题的配置及优化。

typecho 数据导出

文章数据的导出

花了点时间把 typecho 的文章全部改写成 Markdown 的格式，方便我导出为 md 文件，使用了 github 上面一个开源的 python 项目 Typecho2Hexo 进行 typecho 文章数据的导出。稍微修改后如下所示:

# -*- coding: utf-8 -*-

import codecs
import os
import torndb
import arrow

def create_data(db):
    # 创建分类和标签
    categories = db.query("select type, slug, name from typecho_metas")
    for cate in categories:
        path = 'data/%s' % cate.slug
        if not os.path.exists(path):
            os.makedirs(path)
        f = codecs.open('%s/index.md' % path, 'w', "utf-8")
        f.write("title: %s\n" % cate.slug)
        f.write("date: %s\n" % arrow.now().format('YYYY-MM-DD HH:mm:ss'))
        # 区分分类和标签
        if cate.type == 'category':
            f.write('type: "categories"\n')
        elif cate.type == 'tags':
            f.write('type: "tags"\n')
        # 禁止评论
        f.write("comments: true\n")
        f.write("---\n")
        f.close()

    # 创建文章
    entries = db.query("select cid, title, slug, text, created from typecho_contents where type='post'")
    for e in entries:
        title = e.title
        urlname = e.slug
        print(title)
        content = str(e.text).replace('<!--markdown-->', '')
        tags = []
        category = ""
        # 找出文章的tag及category
        metas = db.query(
            "select type, name, slug from `typecho_relationships` ts, typecho_metas tm where tm.mid = ts.mid and ts.cid = %s",
            e.cid)
        for m in metas:
            if m.type == 'tag':
                tags.append(m.name)
            if m.type == 'category':
                category = m.slug
        path = 'data/_posts/'
        if not os.path.exists(path):
            os.makedirs(path)
        f = codecs.open(r"%s%s.md" % (path,title), 'w', "utf-8")
        f.write("---\n")
        f.write("title: %s\n" % title)
        f.write("date: %s\n" % arrow.get(e.created).format('YYYY-MM-DD HH:mm:ss'))
        f.write("categories: %s\n" % category)
        f.write("tags: [%s]\n" % ','.join(tags))
        f.write("urlname: %s\n" % urlname)
        f.write("---\n")
        f.write(content)
        f.close()


def main():
    # 把数据库连接信息
    db = torndb.Connection(host="******", database="******", user="******", password="******")
    create_data(db)

if __name__ == "__main__":
    main()

问题分析

1. 两台服务器收到告警，top 查看进程发现如下可疑进程

# top

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
19078 vmuser    20   0  680232  14284   1032 S 342.8  0.1   1583:11 md
501 vmuser    20   0   32348   3264    760 R  55.9  0.0   2172:49 [atd]
504 vmuser    20   0   32348   3264    760 R  46.7  0.0   2000:21 [atd]
18469 vmuser    20   0   32348   3504    984 R  46.1  0.0   1252:47 [atd]
18692 vmuser    20   0   32348   3408    908 R  43.1  0.0 318:58.87 [atd]
18695 vmuser    20   0   32348   3536   1020 R  42.8  0.0 129:26.05 [atd]
10547 vmuser    20   0   32348   3412    908 R  40.8  0.0  72:19.69 [atd]
8658 vmuser    20   0   32348   3400    880 R  40.5  0.0   4606:03 [atd]
8655 vmuser    20   0   32348   3468    948 R  40.1  0.0   4383:23 [atd]
10542 vmuser    20   0   32348   3408    908 S  24.7  0.0  90:27.13 [atd]
8549 vmuser    20   0   32348   3372    868 R   9.9  0.0 323:27.79 [atd]

用户名为 vmuser 的可疑进程

2. 查看 md 进程详情

# ps aux | grep 19078

vmuser   19078  343  0.0 680232 13764 ?        Sl   07:38 1613:58 -bash -a cryptonight -o stratum+tcp://etn-us-west1.nanopool.org:13333 -u etnk5c12V3YAb5gLekc5N8SizEpbpDogviaU2U9tff2F9JafNFS9pxmF1PNf4aZrMjRSqd9bhjXn7dbpmepNjKi586ZtD9Cv9N -p x

查询后果然和自己判断一样是一个挖矿程序