本文根据〖2016 全球运维大会•深圳站〗现场演讲嘉宾分享内容整理而成，编辑同学为吴召军@腾讯。
讲师简介
眭聚磊
先后任职于百度，金山云，多年耕耘于云计算领域，从Xen到KVM，从LXC到Docker，从IDC到控制台，研发、运维、测试、产品都能找到其身影。
在百度经历了私有云的从无到有，到金山云陪伴着公有云的一步步壮大，遍尝云计算领域的各项技术革新，负责整体架构设计，带领热补丁、在线增量备份、在线迁移和云监控等重点项目，为金山云提供高可用架构平台。
开场白
大家下午好，我先自我介绍一下，先介绍我的名字，主要是我的姓，我估计大家都不认识，眭（suī）聚磊，曾经春秋时期的皇族，后来战国就给灭了，所以就到现在大家都不知道了。
云计算的运维搞什么？
大家都知道运维是很苦逼的行业，还有比运维更苦逼的行业吗？就是给运维做运维，云计算就是这样一个行业，就是给运维做运维。
所以说，是苦逼中的苦逼。但是苦逼中我们也要自娱自乐，我们要干点儿事儿，我们和运维的目标是一样的，就是为了解决我们整个服务的高可用。
作为云计算的开发者，底下无非就是虚拟化技术等，没接触云计算的同学可能就不太了解了，希望通过我的讲解让大家知道云计算的底层是怎样支撑业务的，我们又在底层做什么，怎么样帮助运维提高服务可用性。
概要
今天我讲的内容主要涵盖以下几方面：
- 云计算高可用面临的挑战
- 高可用的需求与目标
- 金山云做如何应对
1、云计算高可用面临的挑战
快速发展
云计算基本上是面向运维人员，我们的业务体量增长是非常快的，每个月甚至每一周都有机器在上架，规模增长非常快。
硬件的故障率是一定的，软件的故障率也是存在的。所以，在这些问题面前就发现每天都可能会有故障。
这么大的规模必然面临着设备的异构，服务器一直在更新换代，但是我们的服务器不可能根据这个节奏报废。
服务器一般是三年一个周期，三年之后怎么办？
另外，在还没有到三年的时候，CPU、内存等这些东西是最容易出问题的固件问题，我们应该怎么应对？
问题永远是存在的
没有人敢说自己是百分之百的稳定，这绝对是不可能的。
我们把问题从两个维度去分析：
- 一个维度是东西向的：硬件故障和软件故障;
- 一个维度是南北向的（按照突发性）：计划内的故障和计划外的故障.
从这两个维度分了四种，这四种都是有交集的，按照它的级别划分成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和混合云方案，把用户的网络和我们的网络打通的，你说的方案我们都有。
原文出处：高效运维
本文链接：https://www.yunweipai.com/7751.html
网友评论comments