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

  • 时间:
  • 浏览:1
  • 来源:大发5分PK10_大发5分PK10官方

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

在内核方面,内核热升级技术在社区底下有,ksplice和kpatch许多个都可不能否 ,它们八个的原理几乎是一样的。

怎么降低Downtime?

硬件的故障率是一定的,软件的故障率也是所处的。许多许多,在什么问提图片转过身就发现每天都是愿因会有故障。

我画了八个小钟表,你许多完成但是 技术问提图片,这是策略问提图片,因此我你定八个策略,就可不能否 把用户的损失降到最低。

2.20分钟×1次

许多许多说,是苦逼中的苦逼。许多苦逼中你们也要自娱自乐,你们要干点儿事儿,你们和运维的目标是一样的,但是 为了处理你们整个服务的高可用。

从前想过用ceph,许多ceph对你们的挑战太满了,它的通用性很强,许多代码量庞大,架构复杂性,但是 你们五、六我个人所有所有太满可不能否 读懂的。

服务器一般是三年八个周期,三年但是为甚办?

通过你们的分析,你用60 0G的盘也好,1T的盘也好,突然更改的数据也就10%左右。

这是你们做的许多技术点,热升级你们是做了八个变种,在线迁移的八个变种。

根据你许多底部形态,你们把增量的磁盘格式做出来了,你们在做在线迁移的但是,只还要拷贝增量数据部分,你许多时间删剪但是 增量数据的时间除以你们的内网下行速度 。

计划外(持续降低),计划外的故障你们做必须0影响。

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

左面是许多开源的方案,右边是你们关心的问提图片,你许多东西能用,许多处理不了你们的实际问提图片。

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

本地数据量非常大,八个虚拟机申请60 0G是愿因1T的盘,是愿因直接往外生拷励志的话 ,不管底下有没法 数据,它但是 60 0G是愿因1T,你许多拷贝的时间相当吓人。

许多问提图片岂但是 致命的,比如说硬盘烧了,是愿因电源老出问提图片了,机器但是 起不来了。换备机也是小时级别的,数据都本地,是愿因没法 做备份,业务就死翘翘了。

Downtime是什么呢?

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

在线迁移要拷各种数据,许多你们在本地做了相似八个从前的迁移,内存但是 本地,直接就过去了,数据也在本地,把内存迭代拷贝完但是,就可不能否 直接切过去了。

内核热升级

1.热升级。内核升级是所处的,内核的更换还要重启物理机,可不能否 不重启物理机呢?能,你们可不能否 做到。

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

今天我讲的内容主要中含以下几方面:

你们为甚去处理呢?

你们用的共享存储但是 KDFS,是自研的。

虽然用户还要的是什么?

你们的虚拟化层Hypervisor为甚做热升级呢?

SLA保障没法 你我个人所有所有做的八个承诺而已,是愿因你们知道你们做必须到百分之一百的可用性,你们的承诺必须无限接近于百分之一百。

Downtime但是 说在迁移的过程中必然会遇到许多中断,你许多切换的时间直接决定了在线迁移是愿因热升级不可用的时间。

你们把问提图片从八个维度去分析:

对于本地存储励志的话 ,不光是Downtime的问提图片,还涉及到另外八个问提图片,数据但是 本地,用户八个T的数据在本地,为甚拷走,拷的但是为甚不影响业务?

这是你们核心还要处理的八个问提图片。

你们的实际问提图片在哪儿?

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

云计算高可用面临的挑战

虽然大多数厂商承诺的但是 3秒,你们承诺的也是3秒,许多你们的技术上也做3秒励志的话 ,那就永远达必须你们的承诺。许多许多,你们做的是60 毫秒。

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

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

1级别-计划外&软件:内核panic,搞过内核的同学很头疼你许多事儿,内核不知道为甚回事就panic了。

高可用,你们的理解是愿因不太一样,你说什么一下你们的理解。你们通常都采用SLA来衡量,SLA但是 八个服务等级协议,高可用的四种 衡量标准。

八个维度是东西向的:硬件故障和软件故障;

你们做的是热升级和在线迁移,发现有问提图片了,直接迁走。

你许多时间差了十倍以上,举个例子:

另外,在还没法 到三年的但是,CPU、内存等什么东西是最容易出问提图片的固件问提图片,你们应该为甚应对?

回答:

你们做技术的,许多许多东西但是 你们一笔一划写的,你们一定要借鉴开源的能量,是愿因这底下能量太满了,你们能想看 许多许多你们不知道的东西。

你们有EIP,你们还有VPC和混合云方案,把用户的网络和你们的网络打通的,你说什么的方案你们但是 。

许多你们专门针对你许多问提图片去做了八个新的磁盘格式,你们通过记录标记出来增量数据。

许多它的问提图片没哟于为甚做,而在于你做的但是什么降低Downtime。

你们承诺:每个月的不可用时间是20分钟,分四种 情况报告:

因此我切换情况报告时就会中断一下,而你们内核底下的算法,当业务比较繁忙的但是,内存的更新是非常快的,你们对内存这部分做了充分的优化,许多根本做必须60 毫秒。

你们是基于八个开源的软件去做的,许多开源的是哪个软件让我不说了,你们在底下做了很高度的改动,你们把监控做到了整个平台的高可用。

许多它的性能遇到很大的问提图片,它发挥没哟你们的SSD性能,果断放弃,许多自研了一套KDFS,写了大概两万行代码,必须十我个人所有所有的团队,做了一套专用的分布式存储。

共享存储,社区底下做得很好,因此我你们处理了Downtime的问提图片,就处理了共享存储底下迁移不中断的问提图片。

对于许多小的创业公司,数据但是 命根子,没法 了数据公司必须死翘翘了。

你们使用自研的增量磁盘,利用你许多技术做快速的在线备份,快速地恢复数据。虽然你许多备份做下来,虽然删剪取决于你我个人所有所有写入的数据量。

这就产生八个矛盾,你们但是 它老出一次20分钟还是多老出几块60 多秒的?

回答:

高可用的需求与目标

许多站在用户的高度而言,因此我老出问提图片但是 在故障时间内该用户百分之百的服务不可用。

60 0G的磁盘,修改的数据60 G,你们的迁移但是 把60 G的数据迁移走,你许多更快就会做完。

你们都知道运维是很苦逼的行业,还有比运维更苦逼的行业吗?但是 给运维做运维,云计算但是 从前八个行业,但是 给运维做运维。

你们做云计算,物理介质一般但是 有四种 :共享存储、本地存储

许多你们要持续降低,降低计划外的故障无外乎是通过几种法律妙招,把一部分计划外的故障转成计划内的故障,另外一部分的计划外的故障,把你们的服务不可外的时间缩短,降低最终的影响。

怎么做到60 毫秒?

当你在格式化文件系统是愿因做分区表是愿因写数据的但是,它会有实际的数据挂接,你们通过增量记录就可不能否 统计出来底下实际的数据是多大。

没法 大的规模必然面临着设备的异构,服务器突然在更新换代,许多你们的服务器与否愿因根据你许多节奏报废。

虽然这部分会遇到很大的问提图片,什么但是会 所处Downtime的时间比较长呢?

从前,你们不停机,对业务影响在3%以内,更快就可不能否 备份到第三方存储上,从前用户在恢复的但是也非常快。基于你们自研的增量磁盘可不能否 做数据备份和数据恢复。

1.0.66分钟/天×60 次

许多许多,你们花了大概一年的时间去做你许多事儿来感知故障和快速响应。

你许多技术是开源的技术,许多开源的技术必须处理通用的需求,处理不了真正的业务场景需求。

没法 你的SLA保障吗?我相信应该但是 。

0级别-计划外&硬件:CPU cat error,UE等。计划外的硬件故障,你们都应该遇到CPU  cat  error,一般是先想看 宕机,许多追查到你许多错误。

许多做的过程中是异步的,太满影响用户现有任何业务,你的磁盘该为甚写就为甚写,业务平滑迁过去,太满可不能否 做到60 毫秒之内的中断,整个迁移的总时间也会非常短。

八个维度是南北向的(按照突发性):计划内的故障和计划外的故障.

我重点说一下对于本地盘怎么处理本地数据传输的问提图片。

2.在线迁移。对于计划内的故障,你们知道服务器即将故障是愿因是愿因要故障了,为甚办?是但是 可不能否 把底下的云主机直接迁移到没法 问提图片的主机上呢?一定可不能否 。

你许多问提图片的核心在于我的监控能扛多大的量?是愿因你们要实时,要实时励志的话 要是愿因瞬间的量非常大,还要处理误报的问提图片。

原理上你们应该太满可不能否 想到降低高频的使用,为甚降低使用但是 仁者见仁、智者见智了,你们把你许多问提图片处理了,就处理了高频函数调用的问提图片。

本地的服务器宕了,没法 共享存储,数据但是 本地,你许多但是一定要减少宕机时间。对于四种 介质,你们从应用级做许多Auto Backup,降低重大故障的损失。

回答:

显然但是 行,你们的SLA但是 八个承诺。

Downtime的问提图片是愿因处理了,在60 毫秒以内,从前共享存储问提图片就处理了。

金山云做怎么应对

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

你们现在是愿因处理线上Bug的种类是大于60 个,涉及的内核版本数量大于10个。到现在为止,你们是愿因可不能否 做到软件零故障了,内核零故障了。

内核底下的内存,你们在迁的但是业务是不中断的,业务的许多系统服务正在运行,迁移是无感知的,你许多但是会 产生许多许多内存,内存拷贝总有停的但是,什么但是停呢?

没法 人敢说我个人所有所有是百分之百的稳定,这绝对与与否愿因的。

是愿因做出来删剪是增量的,从云主机创建结束,突然到最后,它突然只记录每一次增量,许多许多备份时间非常短暂。

针对于不同的场景,你们采取不同的法律妙招,比如说针对于共享存储你们会有Auto Failover,这儿挂了,那儿立刻启动,虽然挂了,服务不可用了,许多服务不可用的时间很短,马上就太满可不能否 起来。