随着互联网的发展,大数据正在以惊人的速度被创造和收集着,尤其随着诸如Google和Alibaba等互联网公司的崛起,数据的价值越来越得到认可,甚至被公司定义为战略资源。因此越来越多的公司开始搭建自己的大数据平台,用来处理数据,从中挖掘商业价值。大数据运维正是在这样的背景下发展起来的,它与传统领域的运维有很多共性的地方,也有一些自身的特点。
第一个特点是规模大
大数据领域单个集群的规模一般是几百台物理机,多则上万台。为了满足容灾需求,一般会有多个集群,而且是跨地域部署的。集群规模大了之后各类异常事件会成为常态,譬如硬件故障、网络故障等,这对我们提出了如下几点要求:
第二个特点是分层
大数据平台实质上是提供大数据的PaaS服务,基于大数据平台会有很多的大数据应用,包括各类离线报表、机器学习、OLAP、实时分析等。大数据运维人员一般只需要负责大数据平台的运维,平台之上具体的业务层都会有自己的应用运维人员。所以大数据运维人员要有能力快速地定位和区分哪些是平台问题,哪些是业务问题。如果把两者混在一起,那么基本上会时刻处于忙碌状态。
本文作者 范伦挺 从事运维工作已经快10个年头,最近7年都在做大数据平台相关的事情,一路走来自己踩过一些坑,也看到别人踩过一些坑。借此机会,将这些经验整理成一条条短句分享出来。希望能让大家的日常工作有所受益!也希望做大数据运维的同学能够通过自身努力,用大数据改变运维,把运维带入到一个数据驱动的智能运维新时代!
大数据运维三十六计之 确保稳定 篇
第一计:数据是大数据之本,宁可停服也不可丢数据。
第二计:不可关闭数据平台回收站功能,任何删除都要默认进回收站,切 勿偷懒跳过。机器或者数据下线一定要有静默期。
第三计:重要数据要有异地灾备,仅同城是不够的。
第四计:所有配置里的密钥要加密存储,关注平台安全。
第五计:大数据平台的控制服务要有机房间切换能力,以加快故障恢复速度。
第六计:大规模系统发布一定要分级灰度。
第七计:多租户系统的quota限制和隔离技术是关键。
第八计:要有很好的各维度TOP N资源占用情况实时分析能力。
第九计:平台运行SLI要对用户透明,避免用户经常怀疑是否是平台有问题。
第十计:平台问题要第一时间公告给用户,否则各种询问的唾沫会淹死你。
第十一计:大数据存储瓶颈除了容量,文件数也是一个大问题。
第十二计:离线作业要有基线关键路径产出时间预测系统,提前预警,否则没有足够时间重跑。
第十三计:实时计算链路长,延时敏感,要有各阶段的详细监控指标,方便问题定位。
第十四计:实时计算要注意热点机器,一粒老鼠屎坏一锅汤。
第十五计:实时计算平台对于延迟很敏感,布局规划上要贴近数据源。
第十六计:实时计算重要业务要通过双链路灾备保证业务稳定性。
第十七计:大规模计算平台至少要能容忍单机故障,否则别让它上线。
第十八计:大数据平台要有服务迁移能力,因为终有一天机房会容不下。
第十九计:大数据平台流量大,共享网络一定要有QoS隔离,否则你将成为众矢之的。
第二十计:大数据平台是电老虎,注意上架密度。
第二十一计:业务规划要提前和机房对齐,否则IDC建设和供应链都很难满足。
第二十二计:用户的突增需求要提前收集,避免资源不足,巧妇难为无米之炊。
第二十三计:多master的物理分布要满足不同机架和交换机要求。
大数据运维三十六计之 控制成本 篇
第二十四计:密切关注集群的水位利用效率,优化一个点都是大把的钱。
第二十五计:按照波峰波谷区别定价,引导用户合理提交任务。
第二十六计:建立作业和存储健康分模型,引导用户做资源优化。
第二十七计:在业务低峰期适合跑一些系统任务,如merge,archive等。
第二十八计:离在线混布可以节省不少资源,但隔离能力是关键。
第二十九计:存储计算分离架构可以扩大混布范围,并且尽快拿到硬件红利。
第三十计:存储需求要预测准,计算资源还可以挤挤,hdd&sdd 混合存储提升shuffle性能。
第三十一计:要储备计算换存储或者存储换计算应急方案,解决临时资源缺口。
第三十二计:规模大、压力大,要时刻关注硬件和网络发展,尽快拿到科技红利。
第三十三计:硬件资源的配比要有预见性,技术迭代比机器过保快。
大数据运维三十六计之 提升效率 篇
第三十四计:大规模和小规模场景不是量的变化,而是质的差异,一定要做好自动化。
第三十五计:自动化工具是生存之本,也是危险根源,一定要有严格测试。
第三十六计:要善于利用大数据运维大数据,运维数据的积累和分析很关键。
案例:欲速则不达——直接删除惹的祸
诚然,上述每一条计策背后都一段刻骨铭心的故事,但篇幅有限无法与大家一一分享,我们在这里仅分享第二计(不可关闭数据平台回收站功能,任何删除都要默认进回收站,切勿偷懒跳过。机器或者数据下线一定要有静默期)背后的一段血泪教训。其实,第二计不仅适用于大数据运维,对传统的数据运维也适用,虽看似简单,却至关重要。
故障来袭
在一个风和日丽的星期天,某公司资深IT男小明正惬意地享受着宅男的周末生活,戴着耳机,手指飞快地在键盘上敲打着。看着一行行code往下延伸,小明嘴角露出一丝满意的微笑。他品上一口咖啡,提提神,继续努力。突然一阵急促的电话铃声响起,小明懒懒地瞥了一眼:又是该死的电话报警。他接起来,静静地听电话那头生硬的电脑语音播报:“异常告警,监控项disk_full状态critical,水位超过了90%,详情查看****。”
故障排查
哎,coding正high呢,又被打断。无奈,小明放下手头的活儿,开始登录系统查看情况。小明查看了整个集群的存储水位,分析了增长趋势,查看了TOP N目录,整体看下来没有发现当前突发的异常事件。不过存储增长趋势从周三开始变快了,对比查看近期的变更操作列表,发现周三有一个变更,变更原因是:新系统切换调试需求,要求将队列缓存数据保留时间从3天延长至5天。此时,作为资深运维人员的小明对报警的原因已经心中有数了,处理这种故障也是小菜一碟。小明拿起了电话,联系了新系统联调测试的负责同学小静,告知小静当前平台存储告警,需要先做清理,等周一上班后再从长计议。小静表示没问题。
故障处理遇险情
放下电话,小明开始在心里盘算接下来怎么操作。他决定采用最快最直接的方法,把多保留的数据直接从HDFS删掉。这时告警电话铃声再次响起,小明想到即使从HDFS直接删除,还会先进回收站,报警依然会持续。先删除,再清理回收站?想想都觉得麻烦,反正是要立马删除释放的,不如直接跳过回收站删除(hadoop fs -rm -r –skipTrash ),干净利落!说干就干。
他立即登录console,各种查看确认路径,先拼好要删除的路径,把路径复制出来,再console粘贴……悲剧发生了,复制的命令中间有换行,删除了上上层目录!身为资深运维人员小明也算见过各种世面,但面对这个场景,还是瞬间觉得整个人被电流击穿,惊出一身冷汗!
小明赶紧采取紧急措施,停止HDFS服务紧急止血,上报故障,拉相关同学一起处理故障。经过各位大神的努力,从nn 日志里回滚了删除操作,重新启动服务。但是已经下发并删除的部分chunk已经回天乏力。之后是漫长的扫描损坏文件,以及与业务同学一一确认后续操作方案(删除损坏文件并重新导入,也有些永久丢失)。
启发
从上面这个故事中我们可以学到三个注意点:
流程和规范都是历史经验的总结,千万不能为了少敲几个命令而偷懒。血的教训再次告诉我们,任何操作都有风险,一定要走一步检查一步,每走一步都给自己留check的时间和回滚的机会。不要为了快或省事而大踏步往前走,看起来比老运维还牛逼高效,但是一旦踏空,想收都收不住脚,只能堕入万丈深渊。重要的事情说三遍:
任何删除都要默认先进回收站,切勿偷懒跳过! 任何删除都要默认先进回收站,切勿偷懒跳过! 任何删除都要默认先进回收站,切勿偷懒跳过!
本文节选自《DevOps三十六计》一书,预计2017年11月出版
本书“大数据运维”部分作者:范伦挺,已在运维领域摸爬滚打近10年,GOPS 全球运维大会金牌讲师。2010年入职阿里,现任阿里巴巴计算平台事业部高级技术专家,负责实时计算平台运维工作。在超大规模集群运维理念和运维产品建设领域具备丰富的经验。