Openstack日常运维

1、Openstack日常运维目录1. 运维工作内容2. 维护与诊断3. 标准化修复与例行检查4. 日志与监控5. 备份与恢复6. 故障解决思路运维工作内容 参与设计、审核、优化公司IT系统基础设施以及各应用系统的体系架构； 全面负责公司运维项目的系统升级、扩容需求与资源落实，配合开发需求，测试、调整运维平台； 负责网络以及交换机、路由器、服务器的网络设置、维护和优化、网络的安全监控、系统性能管理和优化、网络性能管理和优化； 建立面向开发部门，业务部门的服务流程和服务标准； 负责IT运维相关流程的规划、设计、推行、实施和持续改进； 负责设计并部署相关应用平台（包括操作系统和基础服务组件、自动化部署

2、配置工具），并提出平台的实施、运行报告； 负责配合开发搭建测试平台，协助开发设计、推行、实施和持续改进； 负责相关故障、疑难问题排查处理，编制汇总故障、问题，定期提交汇总报告； 负责云服务产品监控和应急反应，以确保云服务产品有7*24小时的持续运行能力； 负责日常系统维护巡检工作及监控，提供IT软硬件方面的服务和支持，保证系统的稳定。维护与诊断1. 采用高可用部署2. 计划内停机尽量采用非高峰使用停机3. 计划外停机，提供备用机替换或利用编写好的安装配置脚本脚本重新部署新机上线4. 实时监测服务进程，进程当机后利用自动脚本重启服务5. pstree -a控制节点控制节点计算节点计算节点1. 计

3、划内停机前，将宿主机内的虚拟机进行迁移，维护完成后恢复虚机2. 检查服务进程 ps aux|grep nova-compute3. 通过日志文件/var/log/nova/nova-compute检查恢复问题虚拟机4. 利用qemu-nbd命令挂载虚拟机磁盘到本地设备，检查修复失败的虚拟机5. 利用nova volume-detach 和nova volume-attach重新挂载卷存储6. 使用共享存储的虚机实在无法启动，可以新建虚机挂在其他宿主节点7. 可以利用恢复/var/lib/nova/instances恢复虚机机8. pstree -a维护与诊断ip -a检查网卡状态检查网卡状态t

4、cpdump检查连通性检查连通性 ping检查网络检查网络检查检查DHCPNova console-log ps aux|grep dnsmasqtcpdump标准化修复与例行检查标准化修复：标准化修复与例行检查例行检查：日志与监控定位错误产生操作错误后，分析操作可能的API调用过程, 逐步检查API日志定位可能的问题点日志与监控日志与监控如果查询各个节点日志比较麻烦，最终可以建立一个专门的日志服务器集中管理日志日志与监控如果查询各个节点日志比较麻烦，最终可以建立一个专门的日志服务器集中管理日志日志与监控预警：日志与监控日志与监控日志与监控趋势预测：日志与监控备份与恢复数据库备份：备份与恢复数

5、据库备份：备份与恢复文件备份：备份与恢复文件备份：备份与恢复文件备份：备份与恢复数据恢复：1.数据库恢复2.配置文件恢复3.其他文件恢复故障解决思路故障的表现是什么？无响应？报错？故障是什么时候发现的？故障是否可重现？有没有出现的规律（比如每小时出现一次）最后一次对整个平台进行更新的内容是什么（代码、服务器等）？故障影响的特定用户群是什么样的(已登录的, 退出的, 某个地域的)?基础架构（物理的、逻辑的）的文档是否能找到?是否有监控平台可用? （比如Munin、Zabbix、 Nagios、 New Relic 什么都可以）是否有日志可以查看?（比如Logstack系统笔记的云日志服务）一、尽

6、可能搞清楚问题的前因后果故障解决思路二、有谁在?$ w$ last 故障解决思路三、之前发生了什么?$ history 故障解决思路四、现在在运行的进程是啥?$ pstree -a $ ps aux故障解决思路五、监听的网络服务$ netstat ntlp$ netstat -nulp $ netstat -nxlp故障解决思路六、CPU 和内存$ free -m $ uptime $ top $ htop 注意以下问题:还有空余的内存吗? 服务器是否正在内存和硬盘之间进行swap?还有剩余的CPU吗? 服务器是几核的?是否有某些CPU核负载过多了?服务器最大的负载来自什么地方?平均负载是多少

7、?故障解决思路七、硬件$ lspci $ dmidecode $ ethtool故障解决思路八、IO 性能$ iostat -kx 2 $ vmstat 2 10 $ mpstat 2 10 $ dstat -top-io -top-bio 这些命令对于调试后端性能非常有用。 检查磁盘使用量：服务器硬盘是否已满? 是否开启了swap交换模式 (si/so)? CPU被谁占用：系统进程? 用户进程? 虚拟机? Dstat 用它可以看到谁在进行 IO故障解决思路九、挂载点 和 文件系统$ mount $ cat /etc/fstab $ vgs $ pvs $ lvs $ df -h $ lsof

8、 +D / /* beware not to kill your box */ 一共挂载了多少文件系统?有没有某个服务专用的文件系统? (比如MySQL?)文件系统的挂载选项是什么： noatime? default? 有没有文件系统被重新挂载为只读模式了？磁盘空间是否还有剩余?是否有大文件被删除但没有清空?如果磁盘空间有问题，你是否还有空间来扩展一个分区故障解决思路十、内核、中断和网络$ sysctl -a | grep . $ cat /proc/interrupts $ cat /proc/net/ip_conntrack /* may take some time on busy se

9、rvers */ $ netstat $ ss -s 你的中断请求是否是均衡地分配给CPU处理，还是会有某个CPU的核因为大量的网络中断请求或者RAID请求而过载了？ SWAP交换的设置是什么？对于工作站来说swappinness 设为 60 就很好, 不过对于服务器就太糟了：你最好永远不要让服务器做SWAP交换，不然对磁盘的读写会锁死SWAP进程。 conntrack_max 是否设的足够大，能应付你服务器的流量? 在不同状态下(TIME_WAIT, )TCP连接时间的设置是怎样的？ 如果要显示所有存在的连接，netstat 会比较慢， 你可以先用 ss 看一下总体情况。 你还可以看一下 L

10、inux TCP tuning 了解网络性能调优的一些要点。故障解决思路十一、系统日志和内核消息$ dmesg $ less /var/log/messages $ less /var/log/secure $ less /var/log/auth 查看错误和警告消息，比如看看是不是很多关于连接数过多导致？ 看看是否有硬件错误或文件系统错误? 分析是否能将这些错误事件和前面发现的疑点进行时间上的比对。如果你有多台机器,看起来很不方便,可以事先把日志存储在系统笔记的云日志服务器上,支持全文模糊查找故障解决思路十二、定时任务$ ls /etc/cron* + cat $ for user in $

11、(cat /etc/passwd | cut -f1 -d:); do crontab -l -u $user; done 是否有某个定时任务运行过于频繁? 是否有些用户提交了隐藏的定时任务? 在出现故障的时候，是否正好有某个备份任务在执行？故障解决思路十三、应用系统日志这里边可分析的东西就多了, 不过恐怕你作为运维人员是没功夫去仔细研究它的。关注那些明显的问题，比如在一个典型的LAMP（Linux+Apache+Mysql+Perl）应用环境里: Apache & Nginx; 查找访问和错误日志, 直接找 5xx 错误, 再看看是否有 limit_zone 错误。这里查看了下,并没有503的,只有403的错误.所以可以跳过 MySQL; 在mysql.log找错误消息，看看有没有结构损坏的表， 是否有innodb修复进程在运行，是否有disk/index/query 问题. PHP-FPM; 如果设定了 php-slow 日志,