标签：情况 info one rm -rf 获得 概率 res 集群 mat
一、如何查看各项服务的状态
source /root/keystonerc_admin #在查看服务状态前务必要先source这个环境变量文件，否则会出现类似如下的错误提示
ERROR (Comm andError): You must provide a username or user id via --os-username, --os-user-id, env[OS_USERNAME] or env[OS_USER_ID]
nova service-list #查看nova的各项服务的状态，State字段的状态为up代表服务正常，down代表服务不正常
neutron agent-list #查看neutron的各项服务的状态，alive字段的状态为:-)代表服务正常，xxx代表服务不正常
cinder service-list #查看cinder的各项服务的状态，State字段的状态为up代表服务正常，down代表服务不正常
glance image-list #查看镜像列表，能正常列出镜像列表一般也代表glance的服务是正常的
注：有时会出现服务状态显示正常，但实际进行操作后还是会失败，或者dashboard上显示无法获取镜像、网络等信息，此时可能需要去查看各组件的日志，日志信息均在/var/log/以对应组件命名的目录中
二、上传镜像的命令
glance image-create --name "cirros-0.3.3-x86_64" --file /root/openstack/cirros-0.3.3-x86_64-disk.img --disk-format qcow2 --container-format bare --is-public True --progress
--name 指定上传后镜像的名称，可自定义，若名称中间有空格需要用引号引起来
--file 指定要上传的镜像的文件路径，可以是相对路径也可以是绝对路径，建议使用绝对路径
--disk-format 指定上传的镜像的文件格式，这个参数的值要根据--file指定的镜像文件的格式来执行，可以通过qemu-img info /root/openstack/cirros-0.3.3-x86_64-disk.img命令查看镜像文件的格式，看输出内容中的file format字段
qemu-img info /root/openstack/cirros-0.3.3-x86_64-disk.img
image: /root/openstack/cirros-0.3.3-x86_64-disk.img
file format: qcow2
virtual size: 39M (41126400 bytes)
disk size: 13M
cluster_size: 65536
Format specific information:
compat: 0.10
三、基础云mariadb数据库出现异常，执行mysql无法进入数据库
当采用高可用控制节点模式部署，若出现机器掉电或环境重启的情况下，可以通过如下步骤尝试恢复，若单控制节点部署则直接执行systemctl restart mariadb启动即可：
1、登录控制节点1，执行如下指令启动mariadb
ulimit -n 16384 && sudo -u mysql /usr/libexec/mysqld --wsrep-cluster-address=‘gcomm://‘ &
2、分别登录控制节点2和控制节点3，执行如下指令启动mariadb
systemctl restart mariadb
3、三个节点的mariadb都启动成功后，返回到控制节点1上，执行如下指令，重新通过systemctl的方式启动控制节点1上的mariadb：
killall -9 mysqld
systemctl restart mariadb
注：若有某个节点的mariadb启动失败，请查看mariadb相关的日志进行排错，日志存放路径为：/var/log/mariadb/mariadb.log
若报错信息显示说启动失败节点的数据库比目前的primary节点的数据要更新，则先将所有节点的数据库服务先关闭，然后在启动失败的节点上先运行第1步中的指令启动数据库。
四、rabbitmq消息队列down掉，重启无法成功
1、分别登录部署了rabbitmq的节点，执行如下指令清空消息队列：
rm -rf /var/lib/rabbitmq/*
2、从控制节点1开始启动rabbitmq服务
systemctl restart rabbitmq-server
五、故障现象：输出正确的用户名密码点击登录后，还是显示密码错误的错误
原因：此种情况90%的概率是mysql数据库有问题，首先查看各控制节点上的mysql数据库服务是否正常，直接在各控制节点上执行mysql看是否可以正常进入数据库进行确认。若数据库异常则参考第三部分尝试进行恢复
六、当所有节点全部关机，重新启动后恢复服务步骤
思路：先恢复所有基础服务，mysql、rabbitmq、httpd、haproxy、keepalived，然后再恢复所有openstack相关的服务
1、根据第三部分恢复控制节点上的mariadb服务
2、通过rabbitmqctl cluster_status查看rabbitmq集群状态，确保所有节点的消息队列服务都在running状态，并且partitions字段为空，无时间分区现象。若消息队列没有启动则执行systemctl start rabbitmq-server启动，若启动失败则参考第四部分尝试进行恢复
rabbitmqctl cluster_status
Cluster status of node ‘rabbit@hs-con01‘ ...
[{nodes,[{disc,[‘rabbit@hs-con01‘,‘rabbit@hs-con02‘,‘rabbit@hs-con03‘]}]},
{running_nodes,[‘rabbit@hs-con01‘]},
{cluster_name,<<"rabbit@hs-con01">>},
{partitions,[]}]
...done.
3、重启控制节点上的httpd服务
systemctl restart httpd
systemctl status httpd 确认服务为running状态
4、重启控制节点上的haproxy服务
systemctl restart haproxy
systemctl status haproxy 确认服务为running状态
5、重启控制节点上的keepalived服务
systemctl restart keepalived
systemctl status keepalived 确认服务为running状态
6、ping下基础云的VIP看是否正常
7、重启所有openstack服务
openstack-service restart
七、故障现象：通过nova service-list、neutron agent-list、cinder service-list等命令连续查看服务状态时，服务的状态会不停的出现变化，一会down、一会up
故障原因：节点之间的时间不同步
解决方法：
1、手动进行时间同步，确保各节点之间的时间是同步的。
systemctl stop ntpd
ntpdate <server_ip>
2、确保server端的ntpd服务为running状态（systemctl status ntpd），client在/etc/ntp.conf文件中指定了server，并且ntpd服务为running状态
八、一般问题排查思路
1、查看日志，网络方面的问题首先查看neutron的日志，对虚拟机的相关操作失败首先查看nova的日志，对云硬盘的相关操作失败首先查看cinder的日志
2、时间是否同步、磁盘空间是否有剩余、
3、若服务日志中没有相关信息，可查看下系统日志中是否有相关报错，例如/var/log/message
九、存储节点重启后osd处于down的状态
1、df -h查看下故障节点的osd盘是否自动挂载到对应的目录下，类似如下：
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 12G 5.9G 5.2G 54% /
devtmpfs 32G 0 32G 0% /dev
tmpfs 32G 4.0K 32G 1% /dev/shm
tmpfs 32G 16M 32G 1% /run
tmpfs 32G 0 32G 0% /sys/fs/cgroup
/dev/sda4 58G 53M 55G 1% /data
/dev/sda1 2.0G 106M 1.8G 6% /boot
/dev/sdl1 1.9T 455G 1.4T 25% /var/lib/ceph/osd/ceph-10
/dev/sdj1 1.9T 448G 1.4T 25% /var/lib/ceph/osd/ceph-8
/dev/sdh1 1.9T 457G 1.4T 25% /var/lib/ceph/osd/ceph-6
/dev/sdg1 1.9T 483G 1.4T 26% /var/lib/ceph/osd/ceph-5
2、若有单独的盘作为journal，需手动修改journal分区的权限为ceph。注：机器重启过，此权限会被恢复为原来的root:disk属主和属组，需重新修改权限
chown ceph:ceph /dev/sdb1
3、在故障节点上执行以下命令启动对应的osd
systemctl restart ceph-osd@xxx xxx为故障节点上osd盘的编号，例如以上机器osd编号为10、8、6、5
4、ceph -s查看集群状态，确认osd盘全部为up状态
注：若osd重启失败，查看相应osd的日志是否有错误信息，osd的日志在/var/log/ceph/ceph-osd.xxx.log（xxx为osd编号），根据错误信息具体问题具体分析。
十、mon节点down掉
1、到对应的mon节点上执行以下命令启动mon
systemctl restart ceph-mon@xxx xxx为mon节点的主机名
2、ceph -s查看mon节点是否恢复正常
注：若mon启动失败，确认磁盘空间是否有剩余、iptables、selinux是否关闭。若这些都没有问题则查看mon的日志/var/log/ceph/ceph-mon.xxx.log xxx为mon节点主机名
十一：
简述一下 nova/cinder/glance 和 Ceph 存储池的关系：
Nova 对应 vms 池，用于保存虚拟机系统盘。
Cinder 对应 volumes 池，用于保存云硬盘。
Glance 对应 images 池，用于保存镜像。
十二、
请简要说明第一次创建的虚拟机无法获得IP的排查思路：
参考答案：
①检查最直观的日志 nova show；
②是否进行了调度到了计算节点；
③调度后在目的计算节点上有否有异常；
④检查neutron网络服务 和后端的存储日志
十三、
请简述 Keystone中各个用户获取Token的过程：
参考答案：
用户获得Token主要是通过已知用户提供的账户密码等认证信息，加上keystone的api endpoint 端点访问连接，然后请求keystone 的api,keystone 服务进行用户密
码等方式的校验完成后，生成一个用户所对应的token,token中附带了该用户所拥有的权限，以及用户的可以访问的接口信息。
标签：情况 info one rm -rf 获得 概率 res 集群 mat
原文地址：https://www.cnblogs.com/lsw-blogs/p/11248687.html
