UCloud 的大航海时代 - 史中 浅黑科技

img

颇有收藏价值,转来小站时时瞻仰。原文链接:https://mp.weixin.qq.com/s/utczhsy1vu234LQU4Hl9Nw

历史属于郑和,但历史更属于哥伦布。

郑和的二百艘船上,载着永乐帝的千秋霸业,载着郑和的真主和麦加,载着明朝政府的海路商业野心,载着水手们加官进爵的美梦。

哥伦布的三艘船上,只有一群寻宝的探险家。

历史给了他们不同的境遇,它向简单的人微笑,向复杂的人怒目。这次选择,最终写进了课本,给了中国人一场绵延六百年的“核心记忆”。

日光之下并无新事。直到今天,那些撑起几叶扁舟远行的人们,仍在得到历史奖赏,改变着站在此岸眺望的中国人。

最近,中哥认识了一位新胖友,他叫谢乐冰,是云计算厂商 UCloud 出海商务拓展总监。和他聊过之后,我突然发现:UCloud 的出海,大抵也是如此。

这是属于“一小群人”的“大航海时代”。

img

1、“草根出海”要用神马姿势?

2012年,季昕华和在腾讯共事多年的老友莫显峰、华琨共同创建了 UCloud。

虽然距今只有六年多,但那已算得上是云计算的“上古时代”。2012年的世界,大概是这样的:

互联网巨头纷纷开始开发自己的云计算。但对于 BAT 来说,他们几乎同时经历着十五年来最大的爆发期。开发云计算的最主要目的,就是满足自己对“算力”日益增长的渴求。简单来说,他们最大的客户就是自己。

像 UCloud 这样纯第三方的云计算公司,他们所有的“算力”都只有一个用途——卖出去。

所以,2012 年谢乐冰还在一家游戏公司,想了半天他还是觉得:那时 UCloud 虽然很稚嫩,但“好像没什么对手”。

彼时云计算的市场也小,随便拉住一个 IT 创业大佬,他都未必能讲清楚云计算到底有啥用。不过,有一个行业对云计算是天然敏感的,那就是“游戏”。

img

创业初期的季昕华

由于创始人团队腾讯、盛大的背景,UCloud 从一开始就瞄准了游戏市场。至少在创业的前三年,UCloud 的命运都是和中国游戏产业“绑”在一起的。

有趣的事情来了,如果让中国互联网各个行业组成一个班级的话,游戏一定是那个最不安分的童鞋,这家初创云计算厂商,就这样被小伙伴半推半就地拽上了探险之路。

浅友们可以回想一下,当时正是手游爆发的季节,《三国来了》《刀塔传奇》《放开那三国》《大掌门》《我叫 MT》一个接一个地火爆。

但实际上,游戏这个行业是典型的“一将功成万骨枯”,一个火爆的游戏脚下,肯定踩着一百个无人知晓游戏的死尸。

从游戏开发者的角度来看,这颇有些赌命的意味。一个手游开发周期要半年,如果成功就黄袍加身,如果失败就大海石沉。每当捏着一把汗看到自己的游戏无人问津的时候,开发者的心里就会想:糟了,是心肌梗死的感觉。。。

img

所以,手游开发者对成本特别敏感。

员工的工资不能减(否则要造反),游戏的品质不能牺牲(否则没人玩),看来看去只有从计算资源上节省成本。所以手游选择不自购服务器,而是租用云计算,应该算是“自己找轮椅”了。

命也该然,UCloud 搭上的手游这么一趟车,越跑越快。

在谢乐冰的记忆里,2014 年“风向”突然发生了变化。

本来中国手游的创业者里就有很大一部分“海归”,中国市场相对成熟之后,他们又发现了一个“致富经”,就是把中国的手游输出到海外去。

他说。

接下来两三年,陆续有用户找到 UCloud,劈头就问,你们在海外有数据中心吗?

UCloud 的人知道,自己是纯粹的第三方云计算厂商。这意味着,用户就是百分百的衣食父母,对方无论要什么姿势都要尽量给。。。

虽然 UCloud 已经尝试在中国香港和美国洛杉矶等地零星建立了几个数据中心,但这毕竟太少,不一定运气那么好正好是客户需要的。于是,负责客户的同学颤抖地问:你要哪儿的数据中心?

对方答:中国台湾。

UCloud 同学咬咬牙,说:没问题!你等我!

这就是 UCloud 出海的最初情形。

img

2、海外拓荒炒鸡凶险,家里得有点“黑科技”

为什么中国大陆的手游要去中国台湾?

这里涉及到手游/中国软件出海的几条经典路径:

1、直接跨越大洋落地欧美日韩。但由于对方是非常成熟的市场,已经有一套自己的文化,从而所有游戏的设计风格和操作习惯都要为欧美日韩定制。

2、切入没有文化相似性的邻国。例如印度、中东。之所以会向这些国家进发,主要是因为“中国制造”在当地受欢迎,中国人认为那里同样应该存在互联网的市场机会。但从结果来看,这条路比较艰难。

3、在中华文化圈中渗透。这是三条路径里最为经典的一个。顺序是:大陆–中国香港–中国台湾–新加坡–马来西亚、印度尼西亚、泰国、菲律宾、越南等等。由于文化的相似性,出海的成功率最高。

一款中国手游的生命通常是这样:

在大陆火爆,然后火速移植到港台试水,如果不行就洗洗睡,如果同样火爆就马上进军东南亚。如果在东南亚仍然大火,基本可以断定,游戏公司会赚得盆满钵满。

img

中国互联网出海

一条标准路径

可能有浅友会问,为什么游戏进中国台湾,服务器也必须进中国台湾呢?

这里简单科普一下。台湾地区对互联网业务有严格的限制:凡是在本岛提供服务的业务,数据不能离岛。

这种数据安全政策在很多地区也存在,所以海外机房不仅是为了保证云计算的效果,还有一个重要的因素就是合规性。

说回 UCloud,当时客户“要去中国台湾”的要求很快反映到了高层,于是一支建设台湾高雄机房的队伍马上出发。

几个月以后,高雄数据中心落成。

而就在这几个月间,想去中国台湾的客户又多了很多。UCloud 为自己的远见和开拓精神深深自豪。于是,半年之后又建立了台北数据中心。

到现在为止,海外数据中心的建设算是一帆风顺。这就像哥伦布刚登上西印度群岛时风光旖旎,直到树丛里杀出了印第安人。。。

在台北数据中心,某个游戏上线的下一秒,就遭到了巨量的 DDoS 攻击。数据接口瞬间被垃圾流量堵死,游戏没办法访问。

img

红色的垃圾流量堵满接口

绿色的正常流量就被弹出了

同事们都觉得这不用慌,UCloud 的专业就是云计算,对于 DDoS 的安全防护措施显然是提前布置好的。

实际上,在开服之前,UCloud 就已经应游戏方要求,上线了一个国际知名厂商的防护系统。他们检查了一下,之所以没有起作用,是因为有些地方配置错误,需要紧急调整。

然而,当他们联系安全服务商的时候,发现居然和对方有时差,半天才收到回信。按照这种效率,也许等对方修复好,已经一天过去了。。。这个情况一下子超出了 UCloud 童鞋的经验,有点方。

危急时刻,求人不如求己。

工程师赶紧开会,想出了一个妙计:把流量引到 UCloud 香港机房,用香港机房的清洗设备之后,再把干净的流量导回台北机房。就这样,忙了几个小时,可算是让游戏恢复了正常。再看工程师,各个都被汗水湿透了衬衫。。。

img

把清洗之后的流量引回台北

谢乐冰当时虽然肉身不在台北机房,却仍然对那次全公司总动员记忆深刻。

他给我回忆的,其实并不是一次紧急事故的处理,而是一群水手在未知的海岸停靠之后,发现既有的世界观和经验完全失效,而又难以预料对手究竟有多强大时,那种命悬一线的无助感。

“宝岛一役”,让 UCloud 上上下下明白了一件事:

离开熟悉的土地哪怕一步,都是踏进了互联网的未知地带。这和当年哥伦布踏上美洲别无二致。在“法外之地”上,如果想要把控局势,就必须从家里带足最强的武器。

某种程度上,这成为了未来数年 UCloud 出海的钢铁信条。

img

还拿“抗 DDoS”这件事来说。

从几年前开始,“本地机房被攻击,就从相邻机房拐个弯儿”这种骚操作成为了标准解决方案。

但这还不够,黑科技就要来了。

这套方案不断发展。最近两年,UCloud 全球28个机房,每一个都自建了流量清洗能力,这些机房连接起来就可以搞出一套“骚操作”——根据攻击者的来源自动调度,就近清洗。

比如我们可以把东南亚的流量,直接在东南亚的机房清洗,把欧洲的流量,直接在欧洲机房清洗,洗干净之后再把剩余的正常用户访问给到应该给的那台服务器。

而且,如果这次攻击很严重,主要的“肉鸡”又都在美国,我们就可以把美国的服务器暂时断掉,以保证其他地方的用户能正常登录。

他说。

可能有童鞋没看明白,中哥简单解释一下:

这就像幼儿园的老师,为了维护秩序,把满操场的小朋友带到不同的教室里,分别在每个教室里“控制”住不听话的熊小孩,然后再把乖宝宝重新放到操场上玩;

大多数同学都是“熊孩子”,那就索性这一个班都不要出去玩了。。。

这就是被称作 Anycast 的流量调度技术。

虽然 Anycast 技术在很多领域都有应用,但布置在全球范围的云服务里,确实有很多技术挑战。不过,既然要服务好客户,我们就得搞出这样一套一套的黑科技。。。

谢乐冰说。

以中国高雄和中国台北为范本,UCloud 在手游出海的路径上,分别建立了新加坡、雅加达、曼⾕、孟买等等数据中心,算是把这条路跑通了。只要你有出海的计划,那么从咨询到部署,都是一对一的服务,这成了 UCloud 别致的“特色服务”。

如果你了解“黑暗丛林”有多凶险,就会明白“贴身保护”有多么重要。

img

img

3、“娘家人”的自我修养

从 2016 年开始,出海大军变得浩浩荡荡。

除了“老熟人”游戏之外,电商、社交、直播、金融科技、智能硬件也开始用 UCloud 作为“胯下白龙驹”大面积出海。谢乐冰挺有信心,他觉得有了游戏的几年磨练,这个时候 UCloud 已经是个“出海老司机”了。

实际上,无论哪个行业,出海的路径和游戏都是极其类似的,都要先从和中国文化类似的国家和地区试水,然后再去更远的地方落地。

看着全球 AppStore 排行榜上名列前茅的中国应用软件都在用自己家的云出海,谢乐冰和很多 UCloud 同事都觉得,自己像个“娘家人”。

娘家人,最爱说的就是“别怕,有你二姨在,谁都不敢动你!!”对自己家的姑娘有一种“混不吝”的袒护。

但是,孤胆深入海外的中国企业,需要的正是这种坚定的安全感。

无论人家买的数据中心在南美还是在非洲,我们都得让他和在中国使用云计算有一模一样的体验。

包括稳定性,包括计算能力和网络速度,也包括客服的质量。

谢乐冰说。

不过,古语有云:人生最大的挑战是把吹出去的NB实现。

img

说来就来,果然有中国企业要去非洲

2018年,UCloud 的几个客户提出,要去非洲尼日利亚开展业务。于是,机房建设“先遣队”直接一猛子扎到了大草原上。

由于这是第一次把数据中心建到非洲,“先遣队”特意提前联系了好几个当地的机房,确定符合自己的技术指标才亲自去调查。结果到了当地一看,有些所谓的顶级“三类机房”,一个月停电三回,都是靠发电机来续命。再看当地的运营商,标注带宽和实际带宽简直就是卖家秀和买家秀的差别。。。

最后,UCloud 只能选择这个国家最大的机房和最大的国有电信运营商,才达到了技术指标。

img

UCloud 在尼日利亚的

拉各斯机房

这给了我们经验,之后我们进入一些亚非拉国家的时候,干脆直接选择最大的国有运营商和机房就对了。

然而,即使这样,也不能百分之百避免中国的用户在海外“受委屈”。因为毕竟机房建设在亚非拉国家,网络抖动、不同运营商之间的兼容问题时有发生。

底层网络和硬件已经尽力了,接下来只能靠技术上的方法。

一个有趣的技术是:

如果在一个陌生的地区建设机房,可以先建设一个小规模的云,如果用户在这个国家的生意越做越大,就可以在不影响原有云运行的同时扩大云的规模。这就像盖一栋大楼,先盖一层,等到需要的时候再盖第二层,如此类推,既节省成本,又保证云的质量。

这被称为“灵活架构”。

img

灵活架构

大概就像个可拼插的积木

一个技术还不够。

如果某个海外接入点发生故障,系统就会自动算出一个新的线路,然后作为配置文件下发给系统,于是流量就会跑到一个新的线路上。这就好像你熟悉的“自动导航系统”,一条路线走不通,导航就自动给你算出另一条绕行路线,总之不会让你回不到家。

这被称为“自愈能力”。

img

自愈能力

大概就像随时调整的导航

另外还有一种很特别的技术。

很多互联网服务对时延的要求很高,需要专线。原本的技术是需要从云厂商专门买一条固定的专线。但是 UCloud 会实时匹配一条当时最合适的加速线路。

这被称为“Path X”。

凡此种种黑科技,不一而足。

我们是吃过时差的亏的。所以现在无论人家什么时候联系我们,接电话的一定不是传话的客服,而是是我们一线的技术人员,而且,无论在哪个地区,无论几点,都能马上联系到我们中国的同事。

他说。

做到这样,UCloud 应该算是“管得多”,“想得细”,仁至义尽的“娘家人”了,不过谢乐冰告诉我,这还不够极致。

说到这,他又给我讲了一段往事。

img

就在2018年夏天,世界杯开幕前一个月,有一个客户突然提出,要去巴西转播世界杯。而且,显然,业务在世界杯开幕前必须 Ready。

这就很不科学了啊。

一个月时间,要把机房位置选好,把电信运营商敲定,把服务器从中国运到巴西,然后在当地配置云计算系统,把用户的系统布置在云计算上。这简直可以当做一个笑话听了。

然而, UCloud 听了用户的时间表,这个任务居然接了。。。

我们的队伍紧急出动,一边找机房,一边把服务器运到南美,然而,当我们把设备放到机房的时候,离世界杯开幕只有几天了。

这几天用来配置云平台,显然是不够了。于是我们搞了一批物理机,让客户的业务先在物理机上跑,确保世界杯之前上线,然后再迁移到云平台上。这相当于我给你的房子没建好,先给你旅馆住。

果然,一切顺利,世界杯前两三天,客户的转播业务顺利跑起来了。

他回忆。

实际上,业内建设一个机房,流程一般是“规划半年,建设半年”。像 UCloud 这样跟打仗一样,1-3个月就建设一个机房的云计算厂商,确实有种“海盗”的风范。

这方面我们得做到,因为“灵活”才是我们的特点。

互联网讲的就是快速试错、快速迭代、快速扩张。有时候,迟一个月上线,就会影响一个项目的成败,这可不是儿戏。我们承诺了帮中国企业在海外快速落地,如果不能百分之百做到,那我们算什么娘家人?

他说。

img

目前 UCloud 分布在全球的28个机房

(点鸡可看大图)

4、这也许是“一小群人”的“大航海时代”

谢乐冰给我一些数据:

UCloud 目前有8万多个⽤户,包括⾹港绿洲、紫龙游戏、宝宝巴⼠、快看漫画、微鲸科技、探探、Blued、什么值得买、前隆科技、心动网络等等。

所有公司部署在 UCloud 上的业务总产值大概千亿人民币。

间接服务⽤户数量超过10亿。

这个数据和巨头阿里云当然还有差距,但是作为一支中国企业出海搭乘的“舰队”,他们做得认真而快乐。

“自己动手,丰衣足食。”这是他总结的 UCloud 出海的价值观。

如果一切都铺平垫稳,不需要靠智慧和灵活性解决,大家都拼资源和规模,那也许就没有我们的机会了。

他说。

实际上,出海这两个字背后,意味着大千世界。有伊斯兰国家,有君主制国家,有财阀垄断国家,有新兴的年轻社会,也有在困境中艰难跋涉的社会。

这种未知,比一般人想象中更为凌厉。

这种未知,也恰恰意味着新的生存空间。

img

May Flower

五月花号

中国企业出海,虽然是30年来我们一直在做的事情。但是对于普通人来说,这仍然是个新奇而又振奋的话题。

过去,中国的国有企业是出海的主力,而新兴互联网企业的出海,直到最近几年才声势渐壮。

对于每个人来说,我们都正在亲历历史。

而对于中国企业的“娘家人” UCloud 来说,他们有资本骄傲。因为在他们手下,诞生了一批又一批在海外站稳脚跟的中国企业。

告别谢乐冰,我一直在问自己,为什么 UCloud 如此执着于中国企业出海?

后来,我大概明白了,这就和询问哥伦布“为什么执着于发现美洲新大陆”一样。

曾经有人问登山者,你为什么登山?

他回答:因为山在那里。

我记得,2015 年的时候我第一次见到季昕华,他告诉我:善泳者溺,善战者死。现在回望,这似乎确实是他一直遵守的信条。

在国内 BATH 争夺云计算霸主的时候,UCloud 显得冷静而又执拗。他们只是安静地修补自己的帆,准备下一次出海远行。

远行的人永远是少数,这也正是远行的魅力。

他们不是传教士,也不是天朝上国的使臣,他们也许只是一小群喜欢探险的人,在期待世界奖赏的同时,创造着自己的大航海时代。

img


在 win10 中使用 l2tp

背景

工作需要,使用 l2tp 连接到当地环境,使用 win7 可以无障碍接入,但是 windows 10 死活没办法连上,看到鱼目混杂的一些资料鼓捣了一会,解决了这个问题,记录一下。

一、添加配置

  1. 右键单击系统托盘中的无线/网络图标。
  2. 选择 打开网络和共享中心。或者,如果你使用 Windows 10 版本 1709 或以上,选择 打开”网络和 Internet”设置,然后在打开的页面中单击 网络和共享中心
  3. 单击 设置新的连接或网络
  4. 选择 连接到工作区,然后单击 下一步
  5. 单击 使用我的Internet连接 (VPN)
  6. Internet地址 字段中输入你的 VPN 服务器 IP
  7. 目标名称 字段中输入任意内容。单击 创建
  8. 返回 网络和共享中心。单击左侧的 更改适配器设置
  9. 右键单击新创建的 VPN 连接,并选择 属性
  10. 单击 安全 选项卡,从 VPN 类型 下拉菜单中选择 “使用 IPsec 的第 2 层隧道协议 (L2TP/IPSec)”。
  11. 单击 允许使用这些协议。确保选中 “质询握手身份验证协议 (CHAP)” 复选框。

54210938867

54210948167

二、检查IPsec Policy Agent服务

Windows + R -> 运行 ,输入 services.msc,打开“服务”窗口。确认 IPsec Policy Agent 服务开启。

54210928568

三、修改注册表

来自官方的解答:

Win10 VPN L2TP始终连接不上 已经根据网上所说的改成1了

需要修改注册表信息,同时按快捷键“Win + R”,打开“运行”窗口,输入 regedit 命令,然后点击“确定”

在“注册表编辑器”中,找到以下注册表子项:

  1. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters
    • 新建一个DWORD类型,名为ProhibitIpSec,然后然后创建DWORD值为1
    • 找到“AllowL2TPWeakCrypto”,然后把值改成“1”
  2. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
    • 新建一个DWORD类型,名为AssumeUDPEncapsulationContextOnSendRule的键,将值修改为2 。

54210897098


深度解密京东登月平台基础架构 - 京东

近日,京东发布登月机器学习平台,并在京东云上线,正式对外提供人工智能服务。登月机器学习平台的上线代表着京东人工智能技术从应用级服务到基础算法的全面对外开放,实践着京东RaaS(零售即服务)的发展策略。今天我们邀请了AI与大数据部的工程师为大家深度解密京东登月平台基础架构。

从2016年9月开始,京东AI基础平台部基于Kubernetes和Docker构建机器学习平台的底层架构,后续逐步完善和优化了网络、GPU管理、存储、日志、监控、权限管理等功能。目前集群管理的容器实例数量有5K+,至今已上线运行了20多个AI前向服务(50多个API),同时为后向训练提供支持,在618大促中表现高效稳定。

架构

登月平台的基础架构以Docker+Kubernetes为中心,底层基础设施包括CPU、GPU、FPGA计算资源,IB、OPA高速互联网络以及多样化的文件系统,之上是机器学习框架和算法库,最上层是业务应用。管理中心包括权限管理、任务管理、流程管理、监控中心、日志中心。

平台整体设计思想是Kubernetes调度一切,应具有以下特性(为了方便起见所有的inference类型的应用我们称为App,所有training类型的应用我们称为Job):

  • 高可用、负载均衡。大量的inference App运行在容器中,需要保证App能够稳定高效的对外提供服务。

  • 应用打包与隔离。研究人员、开发人员将自己的代码打包成image,方便的进行CI/CD,透明的将自己的App运行于平台中。

  • 自动扩容/缩容,training/inference用同一批机器调度。白天有许多活跃的用户,平台应该扩展更多inference App,而到了晚上,应该将更多的资源分配给training Job。

  • 作为大数据调度平台。平台不仅可以原生的调度Tensorflow/Caffe/XGBoost/MXNet等机器学习、深度学习工具包,也应该将Hadoop/Spark系列的大数据生态系统调度在Kubernetes中。

  • 支持丰富的硬件资源类型。根据不同的App,Job类型,应该使用不同的硬件资源以提高加速比,平台不仅需要支持CPU、GPU,还应该支持FPGA,InfiniBand,OPA等专用高速计算资源。

  • 最大化利用整个集群资源。显而易见,对于平台来说已经不再区分是inference App还是training Job,所有的计算资源都统一在一个大的资源池中。

  • 推行数据隔离架构,保证数据安全。通过网络优势将数据和计算进行分离,提供更高级别的数据access权限。

  • 多租户安全保证。

    平台接入公有云,需要支持multi-tenancy的架构,不同的用户共享计算资源的池子,但是彼此在网络级别、文件系统级别、Linux内核级别都相互隔离。

    img

    登月平台架构

网络

Kubernetes自身不具备网络组件,需要使用第三方网络插件实现。前期我们调研了Flannel、Weave、Calico三种容器网络,并做了性能对比测试。由于Flannel、Weave都是overlay网络,均采用隧道方式,网络通信包传输过程中都有封包拆包处理,因此性能大打折扣;而Calico基于BGP路由方式实现,没有封包拆包和NAT,性能堪比物理机网络。

另外,Calico是纯三层的数据中心解决方案,主机之间二层通信使用的是物理机的MAC地址,避免了ARP风暴。除了路由方式,Calico也支持IPIP的隧道方式;如果使用BGP方式,需要机房的网络设备开启BGP功能。

公有云上需要解决的一个重要问题就是多租户网络隔离,我们使用了Kubernetes自身的NetworkPolicy和Calico的网络策略实现。给每个用户分配一个单独的Namespace,Namespace内部的Pod间可以通信,但Namespace之间的Pod不允许通信。Kubernetes的NetworkPolicy只支持对“入流量”(ingress)作限制,而Calico的网络策略作了更多的扩展,支持对“出流量”(egress)作限制,而且还具备更精细的规则控制,如协议、端口号、ICMP、源网段、目的网段等。

大部分容器网络给容器分配的IP只对集群内部可见,而登月平台上很多前向服务对外提供RPC接口,需要将容器IP暴露到集群外部。经调研之后选用了Cisco开源的Contiv项目,它的底层原理是用OVS打通了容器的跨主机通信,我们使用的是它的VLAN模式,相对于基于隧道技术实现的overlay网络来说,这是underlay网络,它不是构建于物理机的网络之上,而是与物理机位于同一网络层面,这种网络的性能接近于物理网络。

存储

Kubernetes本身不提供存储功能,而是通过存储插件与第三方存储系统实现,Kubernetes支持二十多种存储后端,我们选用了Glusterfs。

Glusterfs是面向文件的分布式存储系统,架构和部署都很简单,社区版已经足够稳定,它的特点是:弹性、线性横向扩展、高可靠。Glusterfs在架构上消除了大多数文件系统对元数据服务的依赖,取而代之的是以弹性哈希算法实现文件定位,优化了数据分布,提高了数据访问并行性,极大地提升了性能和扩展性。

Kubernetes的Volume支持静态分配和动态分配两种方式。静态分配指的是由管理员手动添加和删除后端存储卷,动态分配则是使用Kubernetes的StorageClass结合Heketi服务实现。Heketi是Glusterfs的卷的管理服务,对外提供REST接口,可以动态创建、销毁Glusterfs Volume。

Glusterfs虽然性能很好,却不适合存储海量小文件,因为它只在宏观上对数据分布作了优化,却没在微观上对文件IO作优化。登月平台上大多数前向服务都是图像识别应用,需要将图片和识别结果保存下来,用作训练数据,进行算法的迭代优化。我们在调研之后采用了SeaweedFS作为小文件存储系统。

SeaweedFS的设计思想源于Facebook的Haystack论文,架构和原理都很简单,性能极好,部署和维护也很方便。SeaweedFS对外提供REST接口,结合它的filer服务可实现目录管理,我们在此基础上实现了批量上传和下载功能。SeaweedFS具有rack-aware和datacenter-aware功能,可根据集群的拓扑结构(节点在机架和数据中心的分布情况)实现更可靠的数据冗余策略。目前登月平台上很多图像服务已经接入SeaweedFS,每天存储的图片数量达到600万张,存储量以每天30G的速度增长。

因为多数计算任务都会使用HDFS,所以HDFS也是登月平台必不可少的存储组件。为了提高数据读写速度,我们引入Alluxio作为HDFS的cache层,跟直接读写HDFS相比,性能提升了几十倍。

在文件系统的多租户隔离方面,使用Kerberos和Ranger对HDFS作安全管理,Kerberos提供了身份验证,Ranger提供了权限校验。而Glusterfs的Volume使用mount方式挂载到容器中,本身就可将用户限定在特定卷中,因此可变相支持多租户隔离。

GPU资源管理

平台当前使用的Kubernetes 是1.4版本,当时社区还没有加入对多GPU的支持,我们就自己开发了多GPU管理,包括:GPU探测与映射,cuda driver管理与映射,GPU健康检查和状态监控,GPU-aware调度等。GPU-aware调度可根据GPU型号、显存大小、空闲的GPU数量等条件合理地调度应用程序,以保证资源利用率最大化。

负载均衡

登月平台的前向服务对外提供的通信接口有RPC和HTTP两种。RPC服务可以通过注册中心和RPC Client实现负载均衡,HTTP服务使用的是Kubernetes 社区的ingress组件实现负载均衡。Ingress的本质是对Nginx作了封装。用户只需将Ingress规则配置到Kubernetes里,指定服务的Host、Path与Kubernetes的Service之间的映射关系,然后Ingress-controller实时监控规则的变化,并生成Nginx配置文件,将Nginx程序reload,流量就会被分发到Serivce对应的Pod上。

CI/CD

我们选用Gitlab+Jenkins+Harbor作为持续集成/部署的组件。开发者将代码提交至Gitlab,由Jenkins触发编译、打包的规则,并生成Docker镜像push到Harbor上。当用户执行上线操作后,镜像被拉取到Kubernetes集群的Worker节点上,启动容器。平台使用Harbor搭建了私有仓库和mirror仓库,为了加速拉取镜像的速度,在不同机房作了复制仓库。

日志

在日志采集方面,我们采用了业界普遍的解决方案EFK:容器将日志打到标准输出,由docker daemon落盘存到宿主机的文件里,然后经Fluentd收集,发给Kafka,再经Fluentd转发到Elasticsearch,最后通过Kibana展示给用户作查询和分析。之所以中间加了Kafka,一是对流量起到削峰填谷的作用,二是方便业务方直接从Kafka上消费日志导入第三方系统处理。

监控

我们采用的是Heapster+Influxdb+Grafana监控组件。Heapster定期从每个Node上拉取Kubelet暴露出的metric数据,经过聚合汇总之后写入Influxdb,最终由Grafana展示出来。Heapster提供了Container、Pod、Namespace、Cluster、Node级别的metric统计,我们对Heapster作了修改,加入了Service级别的metric聚合,以便用户从应用的维度查看监控。

Kubernetes调度Spark

重点说一下Spark on Kubernetes。该开源项目由Google发起,旨在将Spark能够原生的调度在Kubernetes中,和YARN、Mesos调度框架类似。

业界有一种比较简单的做法,就是将Spark Standalone模式运行在Docker中,由Kubernetes进行调度。

该做法具有以下缺点:

  • Standalone本身就是一种调度模式,却跑在另一种调度平台中,架构上重叠拖沓。
  • Standalone模式跑在Kubernetes中经过实际测试,很多机器学习任务性能会有30%以上的衰减。
  • 需要预先设定Worker的数量,Executor进程和Worker进程跑在同一个Container中,相互影响。
  • 无法完成多租户的隔离。在同一个Docker中Worker可以启动不同用户的Executor,安全性很差。

为了解决上述问题,Kubernetes需要原生支持调度Spark,架构图如下:

img

Native Spark on Kubernetes架构

从Kubernetes的角度出发,把Driver和Executor分别Container化,完成原生调度,架构清晰。

继承了Docker的计算资源隔离性,并且通过Kubernetes的Namespace概念,可以将不同的Job从网络上彻底隔离。

可以保持多版本并行,Spark-submit提交任务的时,可根据用户需求定义不同版本的Driver和Executor。

从Cluster模式的角度来观察Spark on Kubernetes,显而易见的结论是,我们已经不再有一个所谓的“Spark Cluster”,取而代之的是Kubernetes调度了一切,Spark Job可以无缝地与其他应用对接,真正形成了一个大的调度平台。

当前的社区的版本是非生产环境下的,我们团队为此做了大量的benchmark测试,稳定性测试等等。为了支持更多的需求,如multi-tenancy,python job, 我们修改了部分代码,维护了京东的一套版本。

计算与数据分离

在Hadoop生态圈,数据本地性一直被津津乐道。但是在容器化、云的领域,大家都在推崇存储中心化,数据和计算分离,现在有越来越多的公司正在将存储和计算相分离,这主要是得益于网络带宽的飞速发展。不说专有网络,就说通用的25G网络,还有RDMA和SPDK等新技术的使用,让我们具备了存储计算分离的能力。

从架构的角度看有如下意义:

  • 1、多租户场景,数据安全性得到保证,实现物理上的隔离。
  • 2、部署机房可以灵活多变,计算资源和存储资源可以分机房部署。当然,如果需要性能保证,可以加入中间件例如Alluxio。
  • 3、平台可以方便的部署在用户网络,而不改变其数据结构。例如联通、工商银行等。

对于Tensorflow/Caffe/MXNet框架来说,Glusterfs可以直接满足需求。而对于Spark框架,我们直接用HDFS和Spark相分离的计算架构,经过大量的Benchmark,10G网络下LR,KMEANS,Decision Tree,Native Bayes等MLlib算法,数据分离与数据本地性对比,性能损失在3%左右。这样一来,所有的机器学习/深度学习框架都可以统一架构,将计算和存储相分离。

Kubernetes作为容器集群管理工具,为应用平台提供了基于云原生的微服务支持,其活跃的社区吸引了广大开发者的热情关注,刺激了容器周边生态的快速发展,同时为众多互联网企业采用容器集群架构升级内部IT平台设施,构建高效大规模计算体系提供了技术基础。

AI基础平台部是一个专注、开放的team,致力于打造安全高效的机器学习平台架构,为登月算法平台提供底层支持,研究方向主要为Kubernetes,AI算法工程化,大数据系统虚拟化等方向。

感谢Intel公司在Spark on k8s,BigDL等领域为我们提供了有力支持和宝贵经验。


smokeping 初使用

背景

闲着无事,看到这个古老的Smokeping,尝试用来监控服务器的网络情况。当然,我使用的方案优先是容器化方案。

相关网站链接如下:

运行后监控的界面如下:

image-20181028104858605

image-20181028104933050

什么是 Smokeping

Smokeping是一个开源免费的网络性能监控工具,广泛应用于机房网络质量分析,包括常规的 ping,dig,echoping,curl等,SmokePing的优点在于采用rrdtool画图,监控图像实时更新。

使用

快速开始

想快速尝鲜的用户可以直接用 docker 启动:

$ docker run -it --name smokeping -p 8080:80 -e TZ=Asia/Shanghai -d dperson/smokeping

在本机的8080端口访问即可。需要等待几分钟后才能显示图形。添加监控目标可以使用如下命令添加,以添加谷歌 DNS 为例:

$ docker exec -it smokeping smokeping.sh -t "Google;DNS1;8.8.8.8"
Service already running, please restart container to apply changes

$ docker restart smokeping
smokeping

即在 Google 目录下的 DNS1中显示图像。


小米正式开源Istio管理面板Naftis

img

本文作者:小米信息部武汉研发中心。

小米信息部武汉研发中心,支撑小米公司国内外的线上线下销售服务体系、供应链体系、数据决策体系等精细化管控的执行落地工作,服务小米所有业务部门以及 40 家生态链公司,同事承担部门微服务体系建设落地及各类后端基础平台研发维护,长年虚位以待对微服务、基础架构有深入理解和实践、或有大型电商后端系统研发经验的各路英雄。转发自微信公众号 service mesh

近年来服务网格(Service Mesh)已成为各大公司关注重点,各大公司纷纷开始调研Service Mesh相关架构。作为Service Mesh中的佼佼者,Istio诞生之初就已吸引众多目光。

作为基础设施层,Istio有优秀的服务治理能力。但使用Istio进行服务治理时,开发者需通过istioctl或kubectl工具在终端中进行操作,这种方式目前存在一些问题,举例如下:

  1. Istio要求用户熟练掌握istioctl工具的数百种指令,有较高的学习成本。
  2. Istio进行服务治理时需要的yaml配置文件的数量非常庞大,如何配置和管理这些配置文件,也是个难题。
  3. Istio的istioctl工具没有用户权限的约束,存在一定安全隐患,无法适应大公司严格的权限管理需求。
  4. Istio的istioctl工具不支持任务回滚等需求,在执行任务出错的情况下,无法快速回滚到上一个正确版本。

为了解决这些问题,小米信息部武汉研发中心为Istio研发出了一套友好易用的Dashboard - Naftis。

Naftis意为水手,和Istio(帆船)意境契合。作为dashboard,Naftis能使用户像水手一样熟练掌控和管理Istio。

GitHub地址:https://github.com/XiaoMi/naftis

Naftis通过任务模板的方式来帮助用户更轻松地执行Istio任务。用户可以在 Naftis中定义自己的任务模板,并通过填充变量来构造单个或多个任务实例,从而完成各种服务治理功能。

Naftis提供了如下特性:

  • 集成了一些常用的监控指标,包括40X、50X错误趋势等。
  • 提供了可定制的任务模板的支持。
  • 支持回滚指定某一任务。
  • 提供了Istio状态诊断功能,可实时查看Istio的Services和Pod状态。
  • 开箱即用,通过kubectl指令一键部署。

依赖

目前Naftis仅支持Kubernetes,不支持其他容器调度平台。

  • Istio > 1.0
  • Kubernetes>= 1.9.0
  • HIUI >= 1.0.0

Naftis后端采用Go编写,通过Kubernetes和Istio的CRD接口对Istio资源进行操作;前端则采用了同样由小米开源的基于React的前端组件 HIUI,HIUI简洁优雅,有一定React基础的前端开发者能迅速上手:

GitHub地址:https://github.com/XiaoMi/hiui

快速开始

kubectl create namespace naftis && kubectl apply -n naftis -f mysql.yaml && kubectl apply -n naftis -f naftis.yaml

# 通过端口转发的方式访问Naftis
kubectl -n naftis port-forward $(kubectl -n naftis get pod -l app=naftis-ui -o jsonpath='{.items[0].metadata.name}') 8080:80 &

# 打开浏览器访问 http://localhost:8080,默认用户名和密码分别为admin、admin。

详细的部署流程

Kubernetes集群内运行

54044573943

本地运行

数据移植

# 执行sql语句mysql> source ./tool/naftis.sql;

# 将in-local.toml中的数据库的DSN配置替换成本地数据库实例的DSN。

启动API服务

  • Linux
make build && ./bin/naftis-api start -c config/in-local.toml

./run
  • Mac OS
GOOS=darwin GOARCH=amd64 make build && ./bin/naftis-api start -c config/in-local.toml

GOOS=darwin GOARCH=amd64 ./run

配置Nginx代理

cp tool/naftis.conf <your-nginx-conf-directory>/naftis.conf# 酌情修改naftis.conf文件并reload nginx

启动前端Node代理

cd src/uinpm installnpm run dev# 打开浏览器访问 http://localhost:5200。

预览

Dashboard

Dashboard页面集成了一些常用的图表,比如请求成功率、4XX请求数量等。

img

服务管理

服务详情

服务详情页面可以查看查看已部署到Kubernetes中服务信息。

img

服务Pod和拓扑图等

服务详情页面可以查看指定服务Pod和拓扑图等信息。

img

任务模板管理

任务模板列表

任务模板列表也可以查看已经添加好的任务模板卡片列表。

img

查看指定模板

点击“查看模板”可以查看指定模板信息。

img

新增模板

点击“新增模板”可以向系统中新增自定义模板。

img

创建任务

初始化变量值。

img

确认变量值。

img

提交创建任务的分步表单。

img

Istio诊断

Istio诊断页面可以查看Istio Service和Pod状态。

img

Docker镜像

Naftis的API和UI镜像已经发布到Docker Hub上,见api和ui。

开发者指南

获取源码

go get github.com/xiaomi/naftis

配置环境变量

将下述环境变量添加到 ~/.profile。我们强烈推荐通过autoenv来配置环境变量。

54044585582

如果你使用autoenv,则输入 cd.来使环境变量生效。

Go依赖

我们目前使用dep管理依赖。

# 安装depgo get -u github.com/golang/depdep ensure -v # 安装Go依赖

代码风格

  • Go
  • React

其他指令

54044602757


1 2 3 4 5 6 73 74 75 76 77