这篇文章写在前面首先要强调下面这句话,这也是运维人员必须要明白的一句话。不管是数据的安全,还是完整性,都是最宝贵且是无价的。养成一个良好备份的习惯,永远也不会错。

“ 数据是无价的 “ 一 所有运维人员的心声

背景简述

软件学院的新闻发布发布平台:ishikong.cn 在经历过综合测评时期的巨大访问量之后,将主要服务和数据服务全部迁徙到了Azure上面,为了有更大的自由行,我们创建了一个Ubuntu Server 14.04系统的VM,并在上面搭建了Apache+Mysql+php环境,完成了Drupal 7的各项配置,一个月来保持正常运行。

10月14号由于mysql服务的问题,出现了20分钟的事故。当时网站上的错误是这样的:

1
PDOException:SQLSTATE[HY000][2002] Can't connect to local MySQL server through socket '/tmp/mysql.sock'(111) in lock_may_be_available()......

我们首先检查 /tmp/mysql.sock 没有问题之后我们利用关键词也进行了一些查找,然而不管是设置连接数还是权限更改等一系列方法都没有效果。哦,对了,当时 service mysql status 的返回是:Not running, but PID file exist. 删除了进程之后依旧无效。遵循“重启试试”的心态在portal中restart了一个VM,虽然重启了得有十分钟,但是这个问题居然解决了。

虽然不知道是什么原理,但是我们就的确没有继续挖掘这个问题了,首先无法复现,其次日志中也没有特别奇怪的消息。

10月17日中午,再次接到反馈,出现了mysql.sock的问题,于是进入portal,进行重启操作,这个时候我还很庆幸遇上的问题不算很麻烦。这次的重启很快,大概也就一分多钟,然而这个时候我再次访问网站,依旧连接不上,我尝试ssh连接远程服务器,也是timed out。这让我很纳闷,于是开始了探索、尝试、维护的工作。

摸爬滚打

重启试试

首先采用了惯用的方式,修改VM配置之后,重启,希望在云平台上能得到自动修复,然而当我改成A1,A2之后重启都依旧失败之后,发现这种方式并没有什么作用,这次遇上的问题也不仅仅这么简单。

网上咨询

于是我去MSDN上面寻找解决方案,关键词是:Cant connect anymore via SSH to a linux VM。

有这样的发现:Troubleshoot Secure Shell connections to a Linux-based Azure virtual machine

稍微看了一下,大抵上和我之前用的方法差不多,只不过多了一个Reset ssh access, 试了一下,这个也耽误了我很多时间,因为花了快一个小时,结果告诉我reset失败了。。其他的一些回答也并没有给我什么很好的解释。

自行排查

我进入了新版的Azure portal, 这个页面还是比较好看的,使用了其中的一个新功能:Boot diagnostics。他可以自动检测出VM中出的问题。进行少数几步配置后我使用了它,虽然给我报了很多信息,more than 4000 word, 但是并没有什么用,因为尽管我能看懂一部分,但是也不知道该怎么做,这些问题是硬件层面上的,而对于云产品我只能接触到软件层面的。

1
2
3
4
5
6
7
8
9
10
11
12
[H[    0.000000] Initializing cgroup subsys cpuset
.............................
.............................
.............................
[ 15.418196] EXT4-fs (sda1): Couldn't remount RDWR because of unprocessed orphan inode list. Please umount/remount instead
An error occurred while mounting /.

keys:Press S to skip mounting or M for manual recovery

[ 310.240095]EEXT4-fs (sda1): erro count since last fsck: 11
[ 310.243094] EXT4-fs (sda1): initial error at time 1445006744: ext4_journal_check_start:56
[ 310.244081] EXT4-fs (sda1): last error at time 1445056937: ext4_remount:4888

以上就是一些重要的错误信息,我们可以看出来,/.根本就挂载不上硬盘(是这个意思?),所以就是机器完全就没有启动起来,因此更不可能连上机器了。

人工咨询

首先我找了MSDN订阅给我提供的四次完全技术支持,我的理解就是专人远程控制,来帮我解决这个问题。但是当我使用的时候,发现第一次使用要我提供两个ID,而当我电话索要这个ID的时候,告知我周末并不是服务时间 Orz 因此这个途径就不行了,虽然这个肯定是最快和最靠谱的方式。

然后我在MSDN上面发了一个post,寻求专家们的回复:I can’t connect to my VM, restart and reset SSH is no help.

在最后我通过twitter联系了Azure Support,对话如下:

chat img

chat img

看到他都索要我的部署ID了,我满怀希望的去吃nachos~ 结果:

chat img

没办法了只能自己来了,得想想办法。

这之后我采取的措施有:重新建立VM,挂载上原有OS disk,失败。通过磁盘建立映像,失败。导出VHD文件,从中拿住数据,失败。这当然也花了我一个下午的时间。

成功解决

到最后已经确定是磁盘出问题了,那就开始了正规的解决道路,说起来是解决,不如说是拯救:

将原有OS磁盘作为数据盘挂载在一个新的虚拟机上,在将其数据拷贝至新的虚拟机中,重新完成配置。毕竟数据无价,虽然麻烦了一点但也是值得的。

数据恢复

  • 首先为了保险,我新建了一个Storage的windows server VM in east Asia,来存储高达30G的VHD备份,万一出了问题,还能从这里面直接托回去。下载速度10Mb/s,很快就完成了备份。
  • 然后,我们删除了原有的虚拟机,这个时候务必要保留附加的磁盘。
    image
  • 接下来将云服务也删掉,将之前的虚拟机只留下这个磁盘。
  • 然后根据之前的配置新建一个虚拟机,什么都选新的,和之前的完全没有关系,确保能正常启动就好。
  • 然后将之前的磁盘附加到这个新的虚拟机上。等待操作完成,就完成了数据的找回。

数据转移

  • 查看系统disk情况:
    1
    $ sudo ls -l /dev/sd*

结果如下图:
disk information
这里的/dev/sdc和/dev/sdc1/就是新加的数据盘啦,至于为什么有两个我也不清楚, 有用的是这个sdc1.

  • 但是现在的状态是,我们往电脑里放了一个有数据的硬盘,主服务器是无法读取的,那我们应该怎么办呢?当然是挂载上去。
    1
    2
    3
    $ cd /
    $ sudo mkdir data
    $ sudo mount -t EXT4 /dev/sdc1 /data

要注意的是,前提必须是文件系统一样,Azure默认linux的文件系统都是EXT4, 因此对我们的挂载起到了作用。

  • 这时候再进入我们的/data目录下,就能惊喜的发现之前的文件都在了,于是开始了苦逼的转数据阶段~ 不过数据都找回来了,是不是很开心呢!
    floder information

写在最后的话:

  • 云服务器的磁盘容易坏
  • Azure的功能真心好,但是为什么不加一个自动修复硬件错误呢 - - 你在内网的操作,肯定比我的操作要好。
  • MSDN订阅的人工求助没啥用啊 - - 出事的时候基本都不在
  • 数据无价,以后打死不当服务器运维。