给运维做运维:我们是怎么从苦逼到流弊的?

社区广播:运维派(Yunweipai.com)是国内最早成立的IT运维社区,欢迎大家投稿,让运维人不再孤寂的成长!

本文根据〖2016 全球运维大会•深圳站〗现场演讲嘉宾分享内容整理而成,编辑同学为吴召军@腾讯。

讲师简介

眭聚磊

先后任职于百度,金山云,多年耕耘于云计算领域,从Xen到KVM,从LXC到Docker,从IDC到控制台,研发、运维、测试、产品都能找到其身影。

在百度经历了私有云的从无到有,到金山云陪伴着公有云的一步步壮大,遍尝云计算领域的各项技术革新,负责整体架构设计,带领热补丁、在线增量备份、在线迁移和云监控等重点项目,为金山云提供高可用架构平台。

开场白

大家下午好,我先自我介绍一下,先介绍我的名字,主要是我的姓,我估计大家都不认识,眭(suī)聚磊,曾经春秋时期的皇族,后来战国就给灭了,所以就到现在大家都不知道了。

云计算的运维搞什么?

大家都知道运维是很苦逼的行业,还有比运维更苦逼的行业吗?就是给运维做运维,云计算就是这样一个行业,就是给运维做运维。

所以说,是苦逼中的苦逼。但是苦逼中我们也要自娱自乐,我们要干点儿事儿,我们和运维的目标是一样的,就是为了解决我们整个服务的高可用。

作为云计算的开发者,底下无非就是虚拟化技术等,没接触云计算的同学可能就不太了解了,希望通过我的讲解让大家知道云计算的底层是怎样支撑业务的,我们又在底层做什么,怎么样帮助运维提高服务可用性。

概要

今天我讲的内容主要涵盖以下几方面:

  1. 云计算高可用面临的挑战
  2. 高可用的需求与目标
  3. 金山云做如何应对

运维

1、云计算高可用面临的挑战

快速发展

运维

云计算基本上是面向运维人员,我们的业务体量增长是非常快的,每个月甚至每一周都有机器在上架,规模增长非常快。

硬件的故障率是一定的,软件的故障率也是存在的。所以,在这些问题面前就发现每天都可能会有故障。

这么大的规模必然面临着设备的异构,服务器一直在更新换代,但是我们的服务器不可能根据这个节奏报废。

服务器一般是三年一个周期,三年之后怎么办?

另外,在还没有到三年的时候,CPU、内存等这些东西是最容易出问题的固件问题,我们应该怎么应对?

问题永远是存在的

没有人敢说自己是百分之百的稳定,这绝对是不可能的。

我们把问题从两个维度去分析:

  1. 一个维度是东西向的:硬件故障和软件故障;
  2. 一个维度是南北向的(按照突发性):计划内的故障和计划外的故障.

从这两个维度分了四种,这四种都是有交集的,按照它的级别划分成0到3级,0级别是最致命的。

给运维做运维

0级别-计划外&硬件:CPU cat error,UE等。计划外的硬件故障,大家都应该遇到CPU  cat  error,一般是先看到宕机,然后追查到这个错误。

1级别-计划外&软件:内核panic,搞过内核的同学很头疼这个事儿,内核不知道怎么回事就panic了。

2级别-计划内&硬件:设备升级,硬盘的维护。

3级别-计划内&软件:核心软件升级。

2、高可用的需求与目标

高可用,大家的理解可能不太一样,我说一下我们的理解。我们通常都采用SLA来衡量,SLA就是一个服务等级协议,高可用的一种衡量标准。

其实用户需要的是什么?

是你的SLA保障吗?我相信应该不是。

SLA保障是你自己做的一个承诺而已,因为我们知道我们做不到到百分之一百的可用性,我们的承诺只能无限接近于百分之一百。

但是站在用户的角度而言,只要出现问题就是在故障时间内该用户百分之百的服务不可用。

给运维做运维

我们承诺:每个月的不可用时间是20分钟,分两种情况:

  • 1.0.66分钟/天×30次
  • 2.20分钟×1次

这就产生一个矛盾,我们就让它出现一次20分钟还是多出现几次30多秒的?

显然都不行,大家的SLA只是一个承诺。

但是我们要做的是要降低故障的频率,减少单次故障的时长,最低地降低故障时对用户业务产生的影响。我们是在99.95%的基础上去做这些工作,无限地满足用户高可用的需求。

3、我们是如何应对的?

1)计划内

计划内(0影响),我们会在内核以及虚拟化这一层做很多事情:

1.热升级。内核升级是存在的,内核的更换需要重启物理机,能不能不重启物理机呢?能,我们可以做到。

2.在线迁移。对于计划内的故障,我们知道服务器即将故障或者可能要故障了,怎么办?是不是可以把上面的云主机直接迁移到没有问题的主机上呢?一定可以。

这种技术是开源的技术,但是开源的技术只能解决通用的需求,解决不了真正的业务场景需求。

运维是什么

2)计划外

计划外(持续降低),计划外的故障我们做不到0影响。

但是我们要持续降低,降低计划外的故障无外乎是通过几种方式,把一部分计划外的故障转成计划内的故障,另外一部分的计划外的故障,把我们的服务不可外的时间缩短,降低最终的影响。

我们做云计算,物理介质一般就是有两种:共享存储、本地存储

针对于不同的场景,我们采取不同的措施,比如说针对于共享存储我们会有Auto Failover,这儿挂了,那儿立刻启动,虽然挂了,服务不可用了,但是服务不可用的时间很短,马上就能够起来。

本地的服务器宕了,没有共享存储,数据都在本地,这个时候一定要减少宕机时间。对于两种介质,我们从应用级做一些Auto Backup,降低重大故障的损失。

3)热升级

内核热升级

在内核方面,内核热升级技术在社区里面有,ksplice和kpatch这两个都可以,它们两个的原理几乎是一样的。

左面是一些开源的方案,右边是我们关心的问题,这个东西能用,但是解决不了我们的实际问题。

我们的实际问题在哪儿?

在高频函数!比如说CPU调度、KVM的一些中断处理,调用频率是非常高的,打补丁的时候,根本无法实现。

运维是什么

我们怎么去解决呢?

原理上我们应该能够想到降低高频的使用,怎么降低使用就是仁者见仁、智者见智了,我们把这个问题解决了,就解决了高频函数调用的问题。

我们现在已经处理线上Bug的种类是大于30个,涉及的内核版本数量大于10个。到现在为止,我们已经可以做到软件零故障了,内核零故障了。

4)Hypervisor热升级

我们的虚拟化层Hypervisor怎么做热升级呢?

我们做的是热升级和在线迁移,发现有问题了,直接迁走。

但是它的问题不在于怎么做,而在于你做的时候什么降低Downtime。

Downtime是什么呢?

Downtime就是说在迁移的过程中必然会遇到一些中断,这个切换的时间直接决定了在线迁移或者热升级不可用的时间。

其实大多数厂商承诺的都是3秒,我们承诺的也是3秒,但是我们的技术上也做3秒的话,那就永远达不到我们的承诺。所以,我们做的是300毫秒。

运维

如何做到300毫秒?

这是我们做的一些技术点,热升级我们是做了一个变种,在线迁移的一个变种。

在线迁移要拷各种数据,但是我们在本地做了类似一个这样的迁移,内存都在本地,直接就过去了,数据也在本地,把内存迭代拷贝完之后,就可以直接切过去了。

其实这部分会遇到很大的问题,什么时候会发生Downtime的时间比较长呢?

内核里面的内存,我们在迁的时候业务是不中断的,业务的一些系统服务正在运行,迁移是无感知的,这个时候会产生很多内存,内存拷贝总有停的时候,什么时候停呢?

只要切换状态时就会中断一下,而我们内核里面的算法,当业务比较繁忙的时候,内存的更新是非常快的,我们对内存这部分做了充分的优化,否则根本做不到300毫秒。

5)在线迁移

在线迁移分两种介质:有共享存储的在线迁移和本地存储的在线迁移

云计算

如何降低Downtime?

对于本地存储的话,不光是Downtime的问题,还涉及到另外一个问题,数据都在本地,用户一个T的数据在本地,怎么拷走,拷的时候怎么不影响业务?

这是我们核心需要解决的一个问题。

共享存储,社区里面做得很好,只要我们解决了Downtime的问题,就解决了共享存储里面迁移不中断的问题。

Downtime的问题已经解决了,在300毫秒以内,这样共享存储问题就解决了。

云计算

6)在线迁移-本地存储

我重点说一下对于本地盘如何解决本地数据传输的问题。

本地数据量非常大,一个虚拟机申请500G或者1T的盘,如果直接往外生拷的话,不管里面有没有数据,它都是500G或者1T,这个拷贝的时间相当吓人。

但是我们专门针对这个问题去做了一个新的磁盘格式,我们通过记录标记出来增量数据。

云计算

当你在格式化文件系统或者做分区表或者写数据的时候,它会有实际的数据下发,我们通过增量记录就可以统计出来上面实际的数据是多大。

通过我们的分析,你用500G的盘也好,1T的盘也好,经常更改的数据也就10%左右。

根据这个特性,我们把增量的磁盘格式做出来了,我们在做在线迁移的时候,只需要拷贝增量数据部分,这个时间完全就是增量数据的时间除以我们的内网带宽。

这个时间差了十倍以上,举个例子:

500G的磁盘,修改的数据50G,我们的迁移就是把50G的数据迁移走,这个很快就会做完。

而且做的过程中是异步的,不会影响用户现有任何业务,你的磁盘该怎么写就怎么写,业务平滑迁过去,能够做到300毫秒之内的中断,整个迁移的总时间也会非常短。

7)Auto Backup

有些问题真是致命的,比如说硬盘烧了,或者电源出现问题了,机器就是起不来了。换备机也是小时级别的,数据都本地,如果没有做备份,业务就死翘翘了。

对于一些小的创业公司,数据就是命根子,没有了数据公司只能死翘翘了。

我们使用自研的增量磁盘,利用这个技术做快速的在线备份,快速地恢复数据。其实这个备份做下来,其实完全取决于你自己写入的数据量。

因为做出来全部是增量的,从云主机创建开始,一直到最后,它一直只记录每一次增量,所以备份时间非常短暂。

云计算

这样,我们不停机,对业务影响在3%以内,很快就可以备份到第三方存储上,这样用户在恢复的时候也非常快。基于我们自研的增量磁盘可以做数据备份和数据恢复。

我画了一个小钟表,这个完成不是技术问题,这是策略问题,只要你定一个策略,就可以把用户的损失降到最低。

Q&A

提问:你好,我对你刚才说的物理机故障检测这块比较感兴趣,请问你是基于一些开源的系统去实现的,还是你们有一些自研的算法快速检测和故障通知?

回答:
我们做技术的,很多东西不是我们一笔一划写的,我们一定要借鉴开源的能量,因为这里面能量太大了,我们能看到很多我们不知道的东西。

我们是基于一个开源的软件去做的,但是开源的是哪个软件我就不说了,我们在里面做了很深层的改动,我们把监控做到了整个平台的高可用。

这个问题的核心在于我的监控能扛多大的量?因为我们要实时,要实时的话就意味着瞬间的量非常大,还要解决误报的问题。

所以,我们花了大概一年的时间去做这个事儿来感知故障和快速响应。

提问:我刚才看你讲宕机时间,主要是通过修改磁盘的格式,把它改成增量,还有一个是修改内存就可以迁移过去。你们的存储是用了一个共享存储和本地磁盘的存储。我想问,除了这两种存储,有没有ceph存储,我们在ceph存储会遇到很多问题。

回答:

我们用的共享存储都是KDFS,是自研的。

曾经想过用ceph,但是ceph对我们的挑战太大了,它的通用性很强,但是代码量庞大,架构复杂,不是我们五、六个人能够搞定的。

而且它的性能遇到很大的问题,它发挥不出我们的SSD性能,果断放弃,然后自研了一套KDFS,写了大概两万行代码,不到十个人的团队,做了一套专用的分布式存储。

提问:我是做云计算的,我想了解一下你们在网络虚拟化的技术,包括在VPC实现方面有哪些自己自研的技术?

回答:

我们有EIP,我们还有VPC和混合云方案,把用户的网络和我们的网络打通的,你说的方案我们都有。

 

原文出处:高效运维

网友评论comments

发表评论

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

暂无评论

Copyright © 2012-2017 YUNWEIPAI.COM - 运维派 - 粤ICP备14090526号-3
扫二维码
扫二维码
返回顶部