写写最近的工作

Posted on by   4.8K Views

上周过的很糟心，旧槽点没吐完呢新槽点接二连三的来了，心力交瘁裸辞的心都有了。但是想到还得交房租还得吃饭，读书还太少，不能太任性，还是先吐吐槽吧。

周一，安全部门扫到一批有严重安全漏洞的服务器，由于没有完善的监控系统，对服务器的掌控能力很弱，非常原始的依赖手工修改服务器设置。博主对手工做重复的事一直非常抵触，面对这些有着乱七八糟问题批量功能不好用的服务器，无头苍蝇一样乱忙，搞得头昏脑胀情绪低落。然而这还不算完。

一夜回到解放前

平时工作的机器也不幸中招了。但是具体怎么中的没有任何说明，直接就给拔网线了。这机器开了rsync服务，平时工作都从这里rsync脚本。一下子没了挺不方便的。好在cloudstack平台有个vm搭了git server，存储了大部分工作脚本。可是屋漏偏逢连夜雨，周二早上一来，cloudstack平台也出问题了，console proxy vm无法启动，user vm也都无法启动。这机器没放机房，几乎每天都很暴力的直接拔电源，开机时时常会遇到一些问题。由于一直只是当虚拟机管理软件用没有深究过，之前遇到类似问题重启下就ok了，这次怎么重启都不行，一冲动，就直接重置了cloudstack环境。就这样，git server一时半会也恢复无望了。焦虑中居然忘记了自己电脑上的那份代码。用另一台rsync服务器上的很老的代码做了几个提案，感觉好容易才实现的半自动化瞬间要回到刀耕火种的原始社会了，难道又要开始ctrl-c,ctrl-v的运维生涯了么。。

重装cloudstack

每次安装cloudstack都挺抓狂。周二忙了一下午也没重装成功。Secondary Storage VM始终无法成功创建。日志中大量类似下面的内容：

    at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:806)
        at com.cloud.utils.nio.Task.run(Task.java:83)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:701)
2014-05-19 03:32:54,166 WARN  [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-2:null) LibvirtException
org.libvirt.LibvirtException: Unable to create cgroup for s-30-VM: 没有那个文件或目录
        at org.libvirt.ErrorHandler.processError(Unknown Source)
        at org.libvirt.Connect.processError(Unknown Source)
        at org.libvirt.Connect.processError(Unknown Source)
        at org.libvirt.Connect.domainCreateXML(Unknown Source)
        at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startVM(LibvirtComputingResource.java:1213)
        at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3659)
        at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1307)
        at com.cloud.agent.Agent.processRequest(Agent.java:498)
        at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:806)
        at com.cloud.utils.nio.Task.run(Task.java:83)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:701)

身上提案也没心情做了。周三继续，居然在自己的wiki中找到了之前记录的解决方法。。。

北京-雪舞云飘<wufengcheng@163.com>4:03:52 PM
我在构建云的时候总是卡在create system vms在这直接报错报Unable to create cgroup for v-2-VM:No such file or directory怎么解决啊
广州-Bones(17034478)4:04:43 PM
@北京-雪舞云飘 有没有按照步骤一步一步进行配置？
北京-雪舞云飘<wufengcheng@163.com>4:05:12 PM
检查了N遍了，也没找到问题
北京-森林(120437047)4:05:32 PM
@北京-雪舞云飘   kvm？ 
北京-雪舞云飘<wufengcheng@163.com>4:05:48 PM
对啊
北京-森林(120437047)4:07:17 PM
试试这组命令吧 
北京-森林(120437047)4:07:18 PM
service libvirtd stop  # restart kvm  
service libvirtd start  
service rpcidmapd restart  
service rpcbind restart  
service nfs restart
 
北京-森林(120437047)4:07:32 PM
我是安装完kvm之后重启后就解决了 
上海-berlin.FBI<fanbailin@126.com>4:07:34

 恢复VM数据

周四几乎都在折腾恢复cloudstack的VM的事了。都忘记了周三许诺同事周四要完成的一个提案。等下班的时候才给我打电话==，只好等周五做了。恢复VM的事也没能完成，对kvm不太了解，一开始想简单的将primary下的qcow2镜像导入cloudstack模板或者存储，结果都失败了，注册模板倒是可以成功，但就是不能启动，添加存储也可以成功，但是无法挂载。

周五。周二的情况又出现了，Console Proxy VM死活无法启动。够了！再重装非疯了不可，一定要找出解决方法。这次运气比较好，通过日志搜到了cloudstack邮件列表里的类似问题。

I have the following issue:
After emergency reboot of hypervisor node (i.e. reset via ipmi), system vms
got stuck in "starting state":
http://thesuki.org/temp/ss/SS-20130416154808.png

When I look onto console through vnc I see either prompt for fsck or errors
related to r/o mounted root fs:
http://thesuki.org/temp/ss/SS-20130416155009.png

There is no way to destroy vm either from web interface or api
(cloudmonkey):

 cloudmonkey> destroy systemvm id=eb3adb37-96d1-4785-884d-5958526b75fc
Async query failed for jobid 3c2fd0d7-a0a0-427a-ae3e-dda96b7cf9e0
Error 530 We cannot stop VM[ConsoleProxy|v-1058-VM] when it is in state
Starting
 cloudmonkey>

I have to manually update state in mysql before I am able to destroy this
vm:

mysql> update vm_instance set state='Stopped' where name='v-1058-VM';
\Query OK, 1 row affected (0.08 sec)
Rows matched: 1 Changed: 1 Warnings: 0

 cloudmonkey> destroy systemvm id=eb3adb37-96d1-4785-884d-5958526b75fc

OK，终于找到了可以不用重装就解决问题的方法。可是VM数据还是没有恢复。眼看就要放假了，提案不能在托了。抓紧时间将工作机的数据恢复到了线上机器上，重建了rsync服务器。之后完成了一个改IP的提案，四台机器，脚本批量改，抓包确定交换机端口，脚本修改通道IP数据，终于不那么抓狂了。之后又完成了一个管理卡不通的提案，有十多台，好在都是因为模式问题，ipmitool raw 0x30 0x24 2，批量一个命令搞定。在快下班的时候，十多个提案居然全做完了，一身轻松的感觉，真好。

然后专心恢复VM数据，也找到了思路。用qemu-img info看VM镜像时，可以看到backing file.

[root@manage primary]# qemu-img info 09ecf7a5-71f1-45be-8bc3-f0af92f3a193.qcow2 
image: 09ecf7a5-71f1-45be-8bc3-f0af92f3a193.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 7.5G
cluster_size: 65536
backing file: /mnt/5a22d431-3afa-3e44-b224-a17ebd40ef87/e6589794-7870-4661-8083-8a13dda869fc

直接将其转换为其他格式，会提示backing file不存在。由于重置过cloudstack环境，backing file都没在新环境的/primary下了。但是备份中还是有的，将备份中的移动到新环境，在转换，果然就OK了。

[root@manage primary]# mv tmpok/e6589794-7870-4661-8083-8a13dda869fc.qcow2 /mnt/5a22d431-3afa-3e44-b224-a17ebd40ef87/e6589794-7870-4661-8083-8a13dda869fc
[root@manage primary]# ls
09ecf7a5-71f1-45be-8bc3-f0af92f3a193.qcow2  8484ea0b-4d55-4a13-a345-ef39bc3bc18b.qcow2  diskok       tmpok
218baff4-7f45-4964-aaa4-16190f36535a.qcow2  8f48a129-8c16-4395-ab47-025f46fc9a62.qcow2  failed
408fa3e7-48d7-4e7e-8d79-f502cbb62222.qcow2  92a933e2-f457-4649-aaf0-6d1b6ae912b9.qcow2  KVMHA.qcow2
71950d98-554b-4c68-95e5-d48c139c6c61.qcow2  95bdede1-4676-4c6f-a080-7fb887404853.qcow2  small
[root@manage primary]# du -sh 09ecf7a5-71f1-45be-8bc3-f0af92f3a193.qcow2 
7.5G 09ecf7a5-71f1-45be-8bc3-f0af92f3a193.qcow2
[root@manage primary]# qemu-img convert -O vmdk 09ecf7a5-71f1-45be-8bc3-f0af92f3a193.qcow2 09ecf7a5.vmdk
[root@manage primary]# ls
09ecf7a5-71f1-45be-8bc3-f0af92f3a193.qcow2  8484ea0b-4d55-4a13-a345-ef39bc3bc18b.qcow2  failed
09ecf7a5.vmdk                               8f48a129-8c16-4395-ab47-025f46fc9a62.qcow2  KVMHA.qcow2
218baff4-7f45-4964-aaa4-16190f36535a.qcow2  92a933e2-f457-4649-aaf0-6d1b6ae912b9.qcow2  small
408fa3e7-48d7-4e7e-8d79-f502cbb62222.qcow2  95bdede1-4676-4c6f-a080-7fb887404853.qcow2  tmpok
71950d98-554b-4c68-95e5-d48c139c6c61.qcow2  diskok
[root@manage primary]# du -sh 09ecf7a5.vmdk 
8.2G 09ecf7a5.vmdk

对backing file还不理解，但是转换的vmdk可以在vmware下挂载了，数据也都还在，下班的时间也到了，终于可以开心的过一个假期了。关于backing file，这篇文章挺好，存着备用。

在cloudstack上折腾上载卷时，遇到过挂载失败然后一直卡在Copying状态无法删除的情况，受上文提到的邮件列表的启发，直接操作数据库改状态，然后就可以销毁错误的卷。

mysql> use cloud;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> select * from volumes where name="fa508179";
+----+------------+-----------+---------+--------------+-------------+-----------+----------+--------------------------------------+-------------+--------+------+--------+----------------+------------+---------+-------------+-----------+------------------+-------------+----------------------------+-------------+---------------------+----------+---------------------+---------+---------+------------+--------------+-----------+------------------------+--------+----------------+--------+----------+----------+---------------+
| id | account_id | domain_id | pool_id | last_pool_id | instance_id | device_id | name     | uuid                                 | size        | folder | path | pod_id | data_center_id | iscsi_name | host_ip | volume_type | pool_type | disk_offering_id | template_id | first_snapshot_backup_uuid | recreatable | created             | attached | updated             | removed | state   | chain_info | update_count | disk_type | vm_snapshot_chain_size | iso_id | display_volume | format | min_iops | max_iops | hv_ss_reserve |
+----+------------+-----------+---------+--------------+-------------+-----------+----------+--------------------------------------+-------------+--------+------+--------+----------------+------------+---------+-------------+-----------+------------------+-------------+----------------------------+-------------+---------------------+----------+---------------------+---------+---------+------------+--------------+-----------+------------------------+--------+----------------+--------+----------+----------+---------------+
| 80 |          2 |         1 |       1 |         NULL |        NULL |      NULL | fa508179 | 5041bb22-5d49-4412-9bf0-894936d01fc5 | 21474836480 | NULL   | NULL |   NULL |              1 | NULL       | NULL    | DATADISK    | NULL      |                6 |        NULL | NULL                       |           0 | 2015-04-03 09:03:55 | NULL     | 2015-04-03 09:05:48 | NULL    | Copying | NULL       |            3 | NULL      |                   NULL |   NULL |              1 | QCOW2  |     NULL |     NULL |          NULL |
+----+------------+-----------+---------+--------------+-------------+-----------+----------+--------------------------------------+-------------+--------+------+--------+----------------+------------+---------+-------------+-----------+------------------+-------------+----------------------------+-------------+---------------------+----------+---------------------+---------+---------+------------+--------------+-----------+------------------------+--------+----------------+--------+----------+----------+---------------+
1 row in set (0.00 sec)

mysql> update volumes set state="Ready" where name="fa508179";
Query OK, 1 row affected (0.02 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> update volumes set state="Ready" where name="71950d98";
Query OK, 1 row affected (0.02 sec)
Rows matched: 1  Changed: 1  Warnings: 0

 一点思考

我之所以觉得工作很糟心，是因为做事的方法流程有很多很无聊的过程，大量的复制粘贴工作，大量的没有意义的通话，像个客服，像个搬运工，就是不像工程师。我的典型的工作状态：

  1. 事件追踪系统中业务方提故障提案，一般只给出个IP或者资产号
  2. 登陆服务器，如果可以直接解决还好，如果需要登陆管理卡，就需要查询管理卡IP，需要外包解决的就要查位置信息
  3. 把IP或者资产号复制下来，到CMDB中粘贴查找，获取服务器详细信息
  4. 登陆管理卡，或者把业务方提案中的内容和CMDB中查到的服务器位置信息复制下来写成工单给外包，外包工单系统还有很多体验很差的表单要选
  5. 值班，接听电话，虽然那个电话号称是紧急故障响应电话，但是有大量不需要即时反馈的事情，大量NC的事情诸如某个软件怎么使用，某人的分机号是多少之类，把人当客服了。总是被强行打断，处理很多只需要写个FAQ就能解决的事情

我希望的工作状态：

  • 运维的核心应该是监控。应该围绕监控做事，主动发现故障并及时排除故障，事件追踪系统只应该作为一个辅助：监控发现的问题在事件追踪系统做一个问题解决过程追踪记录即可。但是我司目前的情况很被动，针对基础运维（管理卡，账号，硬件等）没有完善的监控，需要业务方遇到故障后在事件追踪系统写提案，然后由我们处理。其实我的很多工作量都完全可以在未发生影响的时候就自动解决。比如管理卡模式错误问题，监控做好了，随时可以修正，还有账号，随时修正，目前每天需要处理很多账号无法登陆的问题。
  • 运维系统之间的协同非常重要，内部系统也需要用户体验。我司目前各种运维系统各自为政，用户体验非常差，效率也不高。还是要说事件追踪系统，这个系统的表单太过灵活，虽然能抓到数据，但是由于可以随便填，几乎无法自动化处理。举例来说，有个域名处理的系统，暂时不吐槽这系统使用体验有多差，只说做事流程，某些域名的添加需要在事件追踪系统手动写提案，表单数据乌七八糟，没有统一格式，这样也就无法适配其他各种运维系统，导出他们需要的格式，这样，我的工作就成了搬运工，ctrl-c，ctrl-v，无聊至极。还有很多其他系统需要做搬运工，说多了都是泪，就不说了。所以，事件追踪系统至少在基础运维这方面，应该由其他系统自动推送工单数据到事件追踪系统，而不是以事件追踪系统为核心来做事。主要的流程应该在各自的系统中完成，事件追踪系统仅作追踪之用。
  • 监控的基础是CMDB，CMDB的数据应该是其他系统自动插入，而非人工修改。而且CMDB应该是模块化的，最核心最简单的只需要一个资产库即可，采购的机器资产号硬件配置直接导入资产库，之后IP，交换机端口，操作系统等配置信息应该是其他运维系统自动向CMDB更新数据。
  • 理想的工作方式：CMDB和监控非常完善，基础运维对机器有很强的控制能力，时刻把握每台机器的状态，用监控主动修复大部分问题，人工只解决有意义的问题，而不是无头苍蝇一样的乱忙。业务方可以看到自己管理的机器的状态与警报，选择警报机器，自动生成包含详细机器信息及故障信息的工单到事件追踪系统，基础运维无法远程解决的问题可以一键生成外包工单。外包的反馈可以自动回推到事件追踪系统。
  • 内部论坛。写个FAQ，有效减少NC问题。

参考资料

1.无法create_system_vms. http://wiki.annhe.net/%E8%AF%BE%E7%A8%8B/%E6%AF%95%E4%B8%9A%E8%AE%BE%E8%AE%A1/issue#无法create_system_vms
2. system VMs failure. http://mail-archives.apache.org/mod_mbox/cloudstack-users/201304.mbox/%3CCAPJLADPrzKE+ZM3LOEXaUUB4rGXREK-8XLCbPGvsfqJ3ZN0cXg@mail.gmail.com%3E
3. kvm+libvirt虚拟机快照浅析. http://itxx.sinaapp.com/blog/content/130
4. qcow2轉成vmdk. http://wp.stes.tc.edu.tw/?p=188

相关文章:

  1. 久别重逢二三事
  2. Zabbix自动删除下线机器的监控
  3. Kubernetes节点维护脚本
  4. Shell模拟多线程
  5. nsswitch配置缺失导致Calico无法启动
  6. Zabbix自动添加端口进程监控

5 thoughts on “写写最近的工作”

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注