Openstack日常运维课件

1、Openstack日常运维1/36目录运维工作内容维护与诊疗标准化修复与例行检验日志与监控备份与恢复故障处理思绪2/36运维工作内容参加设计、审核、优化企业IT系统基础设施以及各应用系统体系架构；全方面负责企业运维项目标系统升级、扩容需求与资源落实，配合开发需求，测试、调整运维平台；负责网络以及交换机、路由器、服务器网络设置、维护和优化、网络安全监控、系统性能管理和优化、网络性能管理和优化；建立面向开发部门，业务部门服务流程和服务标准；负责IT运维相关流程规划、设计、推行、实施和连续改进；负责设计并布署相关应用平台（包含操作系统和基础服务组件、自动化布署配置工具），并提出平台实施、运行汇报；负

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

3、检验服务进程 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 -a4/36维护与诊疗ip -a检验网卡状态tcpdump检验连通性 ping检验网络检验DHCPNova conso

4、le-log ps aux|grep dnsmasqtcpdump5/36标准化修复与例行检验标准化修复：6/36标准化修复与例行检验例行检验：7/36日志与监控定位错误产生操作错误后，分析操作可能API调用过程, 逐步检验API日志定位可能问题点8/36日志与监控9/36日志与监控假如查询各个节点日志比较麻烦，最终能够建立一个专门日志服务器集中管理日志10/36日志与监控假如查询各个节点日志比较麻烦，最终能够建立一个专门日志服务器集中管理日志11/36日志与监控预警：12/36日志与监控13/36日志与监控14/36日志与监控趋势预测：15/36日志与监控16/36备份与恢复数据库备份：17

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

6、Logstack系统笔记云日志服务）一、尽可能搞清楚问题前因后果23/36故障处理思绪二、有谁在?$ w$ last 24/36故障处理思绪三、之前发生了什么?$ history 25/36故障处理思绪四、现在在运行进程是啥?$ pstree -a $ ps aux26/36故障处理思绪五、监听网络服务$ netstat ntlp$ netstat -nulp $ netstat -nxlp27/36故障处理思绪六、CPU 和内存$ free -m $ uptime $ top $ htop 注意以下问题:还有空余内存吗? 服务器是否正在内存和硬盘之间进行swap?还有剩下CPU吗? 服务器是

7、几核?是否有一些CPU核负载过多了?服务器最大负载来自什么地方?平均负载是多少?28/36故障处理思绪七、硬件$ lspci $ dmidecode $ ethtool29/36故障处理思绪八、IO 性能$ iostat -kx 2 $ vmstat 2 10 $ mpstat 2 10 $ dstat -top-io -top-bio 这些命令对于调试后端性能非常有用。检验磁盘使用量：服务器硬盘是否已满?是否开启了swap交换模式 (si/so)?CPU被谁占用：系统进程? 用户进程? 虚拟机?Dstat用它能够看到谁在进行 IO30/36故障处理思绪九、挂载点 和 文件系统$ mount

8、$ cat /etc/fstab $ vgs $ pvs $ lvs $ df -h $ lsof +D / /* beware not to kill your box */ 一共挂载了多少文件系统?有没有某个服务专用文件系统? (比如MySQL?)文件系统挂载选项是什么：noatime?default? 有没有文件系统被重新挂载为只读模式了？磁盘空间是否还有剩下?是否有大文件被删除但没有清空?假如磁盘空间有问题，你是否还有空间来扩展一个分区31/36故障处理思绪十、内核、中止和网络$ sysctl -a | grep . $ cat /proc/interrupts $ cat /proc

9、/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连接时间设置是怎样？假如要显示全部存在连接，nets

10、tat 会比较慢， 你能够先用 ss 看一下总体情况。你还能够看一下 Linux TCP tuning 了解网络性能调优一些关键点。32/36故障处理思绪十一、系统日志和内核消息$ dmesg $ less /var/log/messages $ less /var/log/secure $ less /var/log/auth 查看错误和警告消息，比如看看是不是很多关于连接数过多造成？看看是否有硬件错误或文件系统错误?分析是否能将这些错误事件和前面发觉疑点进行时间上比对。假如你有多台机器,看起来很不方便,能够事先把日志存放在系统笔记云日志服务器上,支持全文含糊查找33/36故障处理思绪十二、

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