Openstack日常运维

维护与诊断
控制节点 1. 采用高可用部署 2. 计划内停机尽量采用非高峰使用停机 3. 计划外停机，提供备用机替换或利用编写好的安装配置脚本脚本重新部署新机上 4. 实时监测服务进程，进程当机后利用自动脚本重启服务 5. pstree -a 计算节点 1. 计划内停机前，将宿主机内的虚拟机进行迁移，维护完成后恢复虚机 2. 检查服务进程 ps aux|grep nova-compute 3. 通过日志文件/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
检查连通性 ping 检查网络 tcpdump 检查DHCP Nova console-log ps aux|grep dnsmasq tcpdump
标准化修复与例行检查
标准化修复：
标准化修复与例行检查
例行检查：
日志与监控 定位错误 产生操作错误后，分析操作可能的API调用过程, 逐步检查API日志定位可能的问题点
故障解决思路
十三、应用系统日志 这里边可分析的东西就多了, 不过恐怕你作为运维人员是没功夫去仔细研究它的。 关注那些明显的问题，比如在一个典型的LAMP（Linux+Apache+Mysql+Perl）应用 环境里: • Apache & Nginx; 查找访问和错误日志, 直接找 5xx 错误, 再看看是否有 limit_zone 错误。这里查看了下,并没有503的,只有403的错误.所以可以跳过 • MySQL; 在mysql.log找错误消息，看看有没有结构损坏的表， 是否有innodb修复 进程在运行，是否有disk/index/query 问题. • PHP-FPM; 如果设定了 php-slow 日志, 直接找错误信息 (php, mysql, memcache, …)， 如果没设定，赶紧设定。 • Varnish; 在varnishlog 和 varnishstat 里, 检查 hit/miss比. 看看配置信息里是否遗漏 了什么规则，使最终用户可以直接攻击你的后端？ • HA-Proxy; 后端的状况如何？健康状况检查是否成功？是前端还是后端的队列大 小达到最大值了？
故障解决思路
十一、系统日志和内核消息 $ dmesg $ less /var/log/messages $ less /var/log/secure $ less /var/log/auth
• 查看错误和警告消息，比如看看是不是很多关于连接数过多导致？ • 看看是否有硬件错误或文件系统错误? • 分析是否能将这些错误事件和前面发现的疑点进行时间上的比对。如果你有多 台机器,看起来很不方便,可以事先把日志存储在系统笔记的云日志服务器上,支 持全文模糊查找
故障解决思路
九、挂载点 和 文件系统 $ mount $ cat /etc/fstab $ vgs $ pvs $ lvs $ df -h $ lsof +D / /* beware not to kill your box */ 一共挂载了多少文件系统? 有没有某个服务专用的文件系统? (比如MySQL?) 文件系统的挂载选项是什么： noatime? default? 有没有文件系统被重新挂载 为只读模式了？ 磁盘空间是否还有剩余? 是否有大文件被删除但没有清空? 如果磁盘空间有问题，你是否还有空间来扩展一个分区
故障解决思路
二、有谁在?
$w $ last
故障解决思路
三、之前发生了什么? $ history
故障解决思路
四、现在在运行的进程是啥?
$ pstree -a $ ps aux
故障解决思路
五、监听的网络服务
$ netstat –ntlp $ netstat -nulp $ netstat -nxlp
日志与监控
日志与监控
如果查询各个节点日志比较麻烦，最终可以建立一个专门的日志服务器集中管理日志
日志与监控
如果查询各个节点日志比较麻烦，最终可以建立一个专门的日志服务器集中管理日志
日志与监控
预警：
日志与监控
源自文库
日志与监控
日志与监控
趋势预测：
日志与监控
备份与恢复
数据库备份：
备份与恢复
数据库备份：
Openstack日常运维
目录
1. 2. 3. 4. 5. 6.
运维工作内容 维护与诊断 标准化修复与例行检查 日志与监控 备份与恢复 故障解决思路
运维工作内容
• 参与设计、审核、优化公司IT系统基础设施以及各应用系统的体系架构； • 全面负责公司运维项目的系统升级、扩容需求与资源落实，配合开发需求，测试、 调整运维平台； • 负责网络以及交换机、路由器、服务器的网络设置、维护和优化、网络的安全监 控、系统性能管理和优化、网络性能管理和优化； • 建立面向开发部门，业务部门的服务流程和服务标准； • 负责IT运维相关流程的规划、设计、推行、实施和持续改进； • 负责设计并部署相关应用平台（包括操作系统和基础服务组件、自动化部署配置 工具），并提出平台的实施、运行报告； • 负责配合开发搭建测试平台，协助开发设计、推行、实施和持续改进； • 负责相关故障、疑难问题排查处理，编制汇总故障、问题，定期提交汇总报告； • 负责云服务产品监控和应急反应，以确保云服务产品有7*24小时的持续运行能力； • 负责日常系统维护巡检工作及监控，提供IT软硬件方面的服务和支持，保证系统的 稳定。
故障解决思路
十二、定时任务 $ ls /etc/cron* + cat $ for user in $(cat /etc/passwd | cut -f1 -d:); do crontab -l -u $user; done
• 是否有某个定时任务运行过于频繁? • 是否有些用户提交了隐藏的定时任务? • 在出现故障的时候，是否正好有某个备份任务在执行？
七、硬件
$ lspci $ dmidecode $ ethtool
故障解决思路
八、IO 性能 $ iostat -kx 2 $ vmstat 2 10 $ mpstat 2 10 $ dstat --top-io --top-bio
这些命令对于调试后端性能非常有用。 • 检查磁盘使用量：服务器硬盘是否已满? • 是否开启了swap交换模式 (si/so)? • CPU被谁占用：系统进程? 用户进程? 虚拟机? • Dstat 用它可以看到谁在进行 IO
备份与恢复
文件备份：
备份与恢复
文件备份：
备份与恢复
文件备份：
备份与恢复
数据恢复：
1.数据库恢复 2.配置文件恢复 3.其他文件恢复
故障解决思路
一、尽可能搞清楚问题的前因后果 故障的表现是什么？无响应？报错？ 故障是什么时候发现的？ 故障是否可重现？ 有没有出现的规律（比如每小时出现一次） 最后一次对整个平台进行更新的内容是什么（代码、服务器等）？ 故障影响的特定用户群是什么样的(已登录的, 退出的, 某个地域的…)? 基础架构（物理的、逻辑的）的文档是否能找到? 是否有监控平台可用? （比如Munin、Zabbix、 Nagios、 New Relic… 什么都可以） 是否有日志可以查看?（比如Logstack系统笔记的云日志服务）
故障解决思路
六、CPU 和内存 $ free -m $ uptime $ top $ htop
注意以下问题: 还有空余的内存吗? 服务器是否正在内存和硬盘之间进行swap? 还有剩余的CPU吗? 服务器是几核的? 是否有某些CPU核负载过多了? 服务器最大的负载来自什么地方? 平均负载是多少?
故障解决思路
故障解决思路
十、内核、中断和网络 $ sysctl -a | grep ... $ cat /proc/interrupts $ cat /proc/net/ip_conntrack /* may take some time on busy servers */ $ netstat $ ss -s • 你的中断请求是否是均衡地分配给CPU处理，还是会有某个CPU的核因为大量的 网络中断请求或者RAID请求而过载了？ • SWAP交换的设置是什么？对于工作站来说swappinness 设为 60 就很好, 不过对 于服务器就太糟了：你最好永远不要让服务器做SWAP交换，不然对磁盘的读写 会锁死SWAP进程。 • conntrack_max 是否设的足够大，能应付你服务器的流量? • 在不同状态下(TIME_WAIT, …)TCP连接时间的设置是怎样的？ • 如果要显示所有存在的连接，netstat 会比较慢， 你可以先用 ss 看一下总体情况。 • 你还可以看一下 Linux TCP tuning 了解网络性能调优的一些要点。