关于数据中心:DatenLord前沿技术分享-No26

达坦科技专一于打造新一代开源跨云存储平台DatenLord,通过软硬件深度交融的形式买通云云壁垒,致力于解决多云架构、多数据中心场景下异构存储、数据对立治理需要等问题,以满足不同行业客户对海量数据跨云、跨数据中心高性能拜访的需要。在本周的前沿技术分享中,咱们邀请到了南京大学田臣传授,来为大家分享RDMA赋能数据中心/超算核心间近程互联。 01、演讲题目RDMA赋能数据中心/超算核心间近程互联 02、演讲工夫2023年6月4日上午10:30 03、演讲人田臣南京大学登峰打算引进人才,传授,博士生导师。田臣老师在计算机网络和分布式系统畛域多个顶级学术会议(含6篇SIGCOMM、3篇NSDI以及OSDI/ATC/FAST/SIGMOD等)和出名国内期刊上录用和发表论文100余篇。他的工作受到了国内外研究者的宽泛援用和关注,依据Google Scholar 最新学术搜寻数据,申请人迄今为止论文累计被援用5000余次。钻研工作取得工业界广泛应用,是华为中央研究院2020年度“最佳单干传授”惟一获奖者。 04、内容简介同城备份、东数西算等需要促成了数据中心或者超算核心之间的近程互联技术须要。RDMA是近年来数据中心/超算核心内的支流网络技术,取得了工业界广泛应用。利用心愿在数据中心之间也能间接应用RDMA技术取得其优越性。本次将分享咱们在该方向上的重要研究进展和下一步倒退方向。 05、直播预约欢迎您预约直播,或者登陆腾讯会议观看直播:会议号:474-6575-9473 达坦科技(DatenLord)专一下一代云计算——“天空计算”的基础设施技术,致力于拓宽云计算的边界。达坦科技打造的新一代开源跨云存储平台DatenLord,通过软硬件深度交融的形式买通云云壁垒,实现无限度跨云存储、跨云联通,建设海量异地、异构数据的对立存储拜访机制,为云上利用提供高性能平安存储反对。以满足不同行业客户对海量数据跨云、跨数据中心高性能拜访的需要。 公众号:达坦科技DatenLordDatenLord官网:http://www.datenlord.io知乎账号:https://www.zhihu.com/org/da-tan-ke-jiB站:https://space.bilibili.com/2017027518达坦科技邮箱:info@datenlord.com若有趣味退出达坦科技,或退出达坦科技技术交换群,请增加小助手微信:DatenLord_Tech

June 2, 2023 · 1 min · jiezi

关于数据中心:联合解决方案系列|DeepCooling面向可持续经济发展的碳中和计算技术

近年来,中国正在疾速倒退新一轮的新型根底建设。作为新基建的重要组成部分,大数据中心为应答 5G、人工智能、工业互联网的大数据需要而生,能够说,大数据中心是新基建的基本。作为数据收集、解决和交互的核心,大数据中心间接决定了企业将来的外围数字化竞争力。 因为数字经济需要的快速增长,数据中心计算自身带来的碳排放也越加收到关注。2019 年,中国建造的数据中心数量大幅增长。随着新冠疫情减速各行各业的数字化步调,美国和欧洲也纷纷大规模建设数据中心。但在如此大的用电规模之下,我国数据中心的能耗利用率却差强人意,总体能效与国内先进程度相比仍有差距。所以,进步数据中心能效,不仅是企业降本增效的重要伎俩,更是中国实现碳达峰、碳中和指标的不可缺的重要门路之一。 通过碳中和计算技术实现以 AI 和数据驱动的数据中心碳中和 用计算来解决由计算自身扩能所造成的碳排放问题,是计算畛域的衍生翻新,咱们称之为碳中和计算技术。碳中和计算反动正在席卷寰球,在寰球数据需要一直增长的局势下,大规模建设新一代以碳计算技术辅助的绿色数据中心势在必行。 VMware 作为当先的云基础架构厂商,对可持续性有着长期的承诺。在中国,VMware 和英特尔也在聚合生态,推动碳中和计算的翻新。VMware、英特尔和Quarkdata(云创近景)合作开发了联结解决方案 DeepCooling,以减速推动在中国乃至寰球数据中心规模化采纳可继续的碳中和计算技术;并一道在2021年底独特公布了数据中心进步运维效率、节能减排的联结白皮书:《面向可继续经济倒退的碳中和计算技术—数据中心新基建背景下的减排翻新》,通过在数据中心外部综合利用物联网/边缘计算、人工智能/深度学习、和交融运维治理等技术节省能源、缩小碳排放。 DeepCooling可继续的碳中和计算技术通过继续的边缘 AI 干涉和实时控制,帮忙企业优化数据中心的整套制冷体系的能耗体现。这套计划曾经在三方的联结推动下,在国内数个大型数据中心落地,帮忙客户显著改善了PUE,升高了碳排放。在曾经生产性部署的环境里全面验证了显著缩小制冷系统能耗和碳排放的成果。 1. DeepCooling 解决方案DeepCooling 概述DeepCooling 基于 AI 和大数据技术,采集数据中心制冷链关键设备的运行指标,联合动环和能源监控数据,利用机器学习建模,精准预测匹配数据中心制冷的最优参数组合,并且通过动静调节制冷系统各个环节参数,进步制冷成果、升高制冷开销。 DeepCooling 次要通过历史数据对整个数据中心负载、发热以及制冷等各个物理零碎进行建模,在此基础上基于负载的预测后果,对于制冷系统进行优化管制,将制冷系统传统的基于反馈的管制晋升为基于建模的前馈管制。DeepCooling 能效优化是一个动静循环过程,每个循环周期包含的次要步骤如下: 数据采集:通过智能传感器和网关设施,采集动环数据、机房空调数据、机房物理空间数据、人工数据等,进行初步汇总,生成机房空调冗余度、机房热力求等两头数据。剖析建模:建设各类热平衡模型,为制冷系统各个部件,如末端空调、水冷机组、旱路等进行建模,同时建设热负载、制冷系统以及温度之间的关系。优化管制:通过训练好的机器学习模型求解每个时刻各个系统的参数,并通过程序下发进行,依据负载准确匹配制冷系统的输入,从而实现制冷设施的能耗节俭。指标收集与剖析通过对接数据中心现有 DCIM 和制冷系统,收集了来自各个机房的温湿度、电量、空调负载以及连带的旱路等数据。在这个根底之上 零碎提供了一套弱小的数据展现和可视化零碎,对机房的冷热设施温度差、热力求有直观的图形化展现。产品将机柜和风道的热力散布、能耗直观展示,可对异样设施和设置做疾速的发现和解决。个别的,能够对机房外部的热负载做剖析和制冷输入进行剖析和可视化,同时反对对每个配备和传感器细节进行可视化: 零碎同时提供了丰盛的报警和策略审计能力,以更好地反对数据中心的运维工作。 模仿物理模型与优化管制基于对于整体零碎收集的数据,分两步来对数据中心的制冷系统机型建模,首先是每个机房,即理论冷量的应用端,同时基于建设的模型,对于末端风机进行优化管制。 第二步将基于所有机房的负载,对于数据中心整体负载进行建模,从而更好的管制集中冷源: 通过对于数据中心整体物理零碎的建模,零碎实现了一个基于建模的前馈优化管制,来改善传统的基于反馈的制冷系统管制体系,从而实现了更经济的能耗体现,以及更加稳固的温度控制。 2. 具体实施部署拓扑构造零碎通过一个分布式的基于边缘推理的计算体系,来实现对于数据中心整体制冷体系的优化管制。一个典型的部署拓扑如下: 每个机房都有独立的管制节点,以实现边缘侧的模型推理以及优化管制的计算,并实现对于所有空调的管制。同理,对于冷源侧,也将会有配套的边缘管制节点实现相干的优化管制。 成果及投入回报率零碎可能提供 18%-25% 的制冷电量节俭,对应的会带来大概 0.1-0.15 的 PUE 改善。对于数据中心的硬件改变较小,施行过程中个别不会对失常生产带来负面的影响。因而 DeepCooling的ROI 是传统基于硬件革新的能耗计划一倍以上。 商业案例末端空调能耗优化该数据中心因为布局等问题,存在温度方差大,温度均值散布不平均的问题,单个空调空度管制存在较大稳定。 DeepCooling 通过 11 个机房精细空调运行状态的调整,并累计 14 天机房内精细空调及 IT 设施能耗数据,通过与后期累计数据比照,均匀节能率 30% 以上,最高可达近 70%。 水冷机组能耗优化该数据中心旱路设计负荷和理论负荷差距较大,个别理论负荷远低于设计负荷,原有一次定频泵设计导致低进回水温差,大流量,导致节约;同时整体水冷机组负载偏低,该数据中心 4 台水冷机组,每个水冷机组两个压缩机开启的前提下,均匀负载个别为25%- 35%,远低于最优 COP 负载区间(个别为 60%-80%)。 ...

May 26, 2022 · 1 min · jiezi

关于数据中心:探访华为云全球最大云数据中心背后藏着这些黑科技

基础设施即服务 | infoQ 新基建背景下,数据中心作为撑持新基建倒退的重要 IT 基础设施,愈发受到重视。除三大运营商外,BAT 等互联网巨头近年也开始鼎力投入数据中心的建设和布局。近日,InfoQ 记者来到华为云贵安数据中心实地探访,进一步理解 AI 和大数据等技术在撑持超大型数据中心日常运行所施展的作用。 2016 年,华为与贵州省政府签订策略单干协定,数据中心正式投建。目前华为云贵安数据中心一期曾经投入使用,共建设有 9 栋机房,预计将来三到五年还会有更多机房建成。 据华为云营销部长董理斌介绍,贵安数据中心布局为华为寰球最大的云数据中心,全副建成后可包容 100 万台服务器。它也是华为云业务的重要承载节点,次要承载华为云、消费者云和华为外部流程 IT 等业务。“如果以贵州为核心,用一千公里画一个半径,贵安华为云数据中心的服务范畴可能辐射到重庆、广西、广东、云南、四川等周边省份和地区。” 除了建设数据中心以外,华为云贵安数据中心还将承当华为寰球 IT 保护工程师基地、员工培训实习基地的职能。预计将有约 600-800 位 IT 保护工程师对数据中心提供反对与服务,每年还将有大量人员到园区进行全景化实战培训、实习等。 以后,华为云在中国布局了五大数据中心,除了贵安和乌兰察布外,还有京津冀、长三角、粤港澳片区三大外围数据中心。在国内数据中心布局中,华为云次要基于时延来进行数据中心的冷、温、热布局,其中冷服务次要建在低成本中央,温服务贴近沿海的低成本中央,热服务则布局在贴近客户需要的中央。在海内,华为也在欧洲、中东、非洲、亚太、拉美等区域建设了本地数据中心。 在董理斌看来,以后数据中心及相关联产业目前仍处在飞速发展阶段。仅在贵州,华为云就已为超过 800 家贵州企业数字化转型提供服务,全省 62 家省直部门 1438 个数据资源都已上云。而据中国信息通信研究院数据,截至 2020 年底,我国在用数据中心机架总规模超过 400 万架,近 5 年年均增速超过 30%。 但数据中心产业疾速倒退的同时,也带来了能耗大幅增长的问题。据《中国数据中心能耗现状白皮书》,早在 2015 年,全国大数据中心的耗电量已达 1000 亿 kWh,相当于三峡电站全年的发电量;2018 年这个数值迅速俯冲至 1609 亿 kWh,超过上海全年的社会用电量。 能耗问题如何破解? 往年 7 月 14 日,工业和信息化部印发《新型数据中心倒退三年行动计划(2021-2023 年)》(以下简称“行动计划”)明确指出:到 2021 年底,全国数据中心均匀利用率力争晋升到 55%以上,总算力超过 120EFLOPS,新建大型及以上数据中心 PUE 升高到 1.35 以下;到 2023 年底,全国数据中心机架规模年均增速放弃在 20%左右,均匀利用率力争晋升到 60%以上,新建大型及以上数据中心 PUE 升高到 1.3 以下,酷寒和凛冽地区力争升高到 1.25 以下。 ...

March 14, 2022 · 1 min · jiezi

关于数据中心:我厂与张家港市达成全面战略合作共推数据中心和城市智能化转型

5月26日,在深圳举办的“张家港(深圳)翻新倒退单干交流会”上,我厂与张家港市人民政府签订策略单干协定,单方将在数据中心、AI助力智慧城市、工业互联网等畛域增强单干,携手推动新一代信息技术与城市各畛域的交融利用智能化晋升,减速城市经济高质量倒退。张家港市委常委、常务副市长卞西方,百度智能云副总裁黄艳代表单方进行签约。张家港市委书记潘国强,张家港市委副书记、市长韩卫,百度副总裁刘雅雯等缺席并见证签约典礼。 依据协定,单方将以百度云计算(张家港)核心我的项目为外围,合力推动百度云计算中心、百度AI算力核心、百度大脑翻新体验核心及百度数据中心基地等新型基础设施在张家港市的布局建设,撑持当地政企数字化、智能化转型,赋能产业高质量倒退。以云计算、大数据、人工智能平台为依靠,后续单方还将围绕新型智慧城市、智慧医疗、工业互联网等畛域发展宽泛、深度的单干,进一步摸索数字技术在数字政府、城市治理、产业倒退、民生服务方向的智慧化翻新利用,晋升城市精细化管理水平,让城市居民播种更多幸福感。 张家港是江苏省港口工业强市,也是一座凋谢容纳、充满活力的产业型城市。近年来,张家港市锚定“强富美高”新江苏建设总指标,致力抢抓长三角区域一体化倒退、长江经济带高质量倒退、“沪苏同城化”等策略倒退时机,减速推动翻新发明与高质量倒退,获得显著功效。 我厂是领有弱小互联网根底的当先人工智能公司,是寰球为数不多的提供AI芯片、软件架构和应用程序等全栈AI技术的公司之一,被国内机构评为寰球四大AI公司之一。我厂在寰球人工智能专利申请量已超过1万件,其中中国专利9000余件位列第一。AI Cloud间断三次中国市场份额第一。目前,依靠“云智一体”的劣势能力,我厂在智慧城市、智能制作、智慧医疗、智慧金融、智慧能源等畛域均领有当先的产品、技术和解决方案。以此次签约为契机,将来我厂与张家港将携手推动新技术在城市、产业中的新利用,用科技翻新助力晋升张家港城市智能化、数字化倒退程度。 会议期间,围绕数字产业倒退、营商环境共建共享等话题,政企嘉宾还进行了互动交换对话。百度副总裁刘雅雯在对话发言时示意:产业转型降级、经济继续倒退都须要数字化、智能化的新动能,产业智能化利用和AI技术之间存在着鸿沟,这正是我厂的劣势能力和发力方向。在合力助推高质量倒退的方向上,我厂与张家港具备统一的价值观和发展观。此次单方达成策略单干,将张家港的区位劣势、产业劣势及营商环境劣势,和我厂在云计算、人工智能、大数据方面的技术劣势和产业链资源能力进行充沛交融,强强联手,对将来数字产业建设、数字经济倒退都将带来微小的设想空间。

May 28, 2021 · 1 min · jiezi

关于数据中心:数据中心太耗电送你一个节能神器

摘要:其实对于节能,传统技术也是做了“十二分”的致力。然而在技术一直演进的状况下,传统节能技术还是存在问题,如何破?本文分享自华为云社区《数据中心节能?来试试华为NAIE数据中心节能技术!》,原文作者:启明 。 一、3 年电费耗费,可再建造一个数据中心!1.1 科技驱动,推动数据中心市场继续高速倒退国际惯例,先介(bai)绍(du)一(bai)下(ke)“数据中心”:数据中心是寰球合作的特定设施网络,用来在 internet 网络基础设施上传递、减速、展现、计算、存储数据信息。一个数据中心的次要目标是运行利用来解决商业和运作的组织的数据。 现如今,咱们曾经处在一个全联接的世界。从 2015 年到 2025 年,依据华为 GIV 的数据预测,寰球智能终端联接数将从 70 亿激增到 400 亿,寰球联接数也将从 200 亿激增到 1000 亿。而在硬件数和联接数激增的背地,是数据流量的爆发式增长:年数据流量将从 9ZB 以 20 倍的速度涌至 180ZB(见图 1)。 图 1:数据来源于 HW GIV 数据流量的极速增长,加上政府对各新兴产业的鼎力搀扶,数据中心的倒退建设将迎来高速倒退期间,依据 MarketsAndMarkets 的数据统计预估,寰球数据中心的价值将从 2017 年的 130.7 亿美元增长到 2022 年 465.0 亿美元(见图 2),这其中的 CAGR(Compound Annual GrowthRate,复合年均增长率)高达 28.9%。其市场规模及市场价值,显而易见。 图 2:数据来源于 MarketsAndMarkets 1.2 高电力耗费,数据中心产业“背地的暗影”“阳光背地总有暗影”。高产业价值的背地,是高电力耗费。作为“数据中心”,能够设想:一个大型机房,外面稀稀拉拉地布满了各式各样的机柜、服务器等。数据中心的后期根底建设和投资,将会是一笔巨额数字。而一旦启动应用,这其中的电费,又将是一个天文数字。咱们能够用一个大型数据中心 10 年的经营老本状况来看看这其中的电力应用状况: 从下面的表格能够看到,该数据中心每年电费将近 3600 万,其中有 70%都用于电费,而 70%的电费中,又有 19%用于制冷上。且据 2017 年统计,寰球数据中心用电量占寰球用电量的 3%,年增长率超过 6%,相当于 30 个核电站;仅中国的数据中心用电量每年就有 1200 亿千瓦时,超过三峡电站 2017 年全年发电量(1000 亿千瓦时)。计算下来,数据中心 3 年的电费能够再造一个数据中心! ...

May 14, 2021 · 2 min · jiezi

关于数据中心:数据中心大二层网络技术大揭秘

【摘要】 传统的三层数据中心,置身虚拟机化的浪潮中,其中改革翻新,就在此篇文章中一窥到底吧。传统数据中心三层组网架构政府部门或者金融机构等大型企业的数据中心中服务器的规模可能会达到2000台以上。个别状况下,数据中心网络都会进行服务器的分区治理,单个业务分区规模不大,此时能够采纳下图所示的规范三层架构。  在这种组网形式中,核心层是整个数据中心网络的枢纽,外围设施通常部署2-4台大容量高端框式交换机,能够是独立部署,也能够通过CSS、iStack虚拟化技术后成组部署。分区内的汇聚层和接入层通过传统CSS、iStack、xSTP等技术实现二层破环,也可在汇聚层和接入层利用纵向虚拟化技术(如SVF)实现接入层的简略治理及节点扩大。 为什么采纳这种架构,因为架构成熟(废话),二三层网络技术成熟,部署成熟,也合乎数据中心分区份模块的特点,总体来说,是运行了多年的成熟实惠大礼包,买不到吃亏,买不到受骗。 挑战来了随着20年代初的慢慢远去,网络人能够称心的回忆,他们曾经搞定了网络协议的大部分问题。 但凡能被组件化的,能被分布式的,能被备份的、降级的、平安加固的,从不间断转发(NSF)到不间断路由(NSR)最初到不间断服务(NSS),被性能优化的(各种FRR),被组网的(局域,广域)。路由(RIP,OSPF,ISIS,BGP)不行加标签(MPLS),标签不行加VPN成隧道(GRE,TE,VPLS, VPWS),但凡能做的都做到了,整个网络丁丁当当,忙忙碌碌。提了一堆广泛重要神气的国际标准,RFC写的整整齐齐。当整个三层协定几个人就能够保护的时候,网络人曾经感觉除了硬件更强以外,没多少事能够干了。 辩证思维教育通知咱们,完满事物是不存在的。虚构技术就像那只蝴蝶的翅膀,悄悄的扇了一下,数据中心的三层组网架构就轰然倒塌了。 虚构技术把一台服务器虚化成了多台逻辑服务器,每个VM都能够独立运行,有本人的OS、APP,以后也有本人独立的MAC地址和IP地址,它们通过服务器外部的虚构交换机(vSwitch)与内部实体网络连接。 对于虚构技术,数据中心怎么看也只是个吃瓜大众,吃着吃着,啊~,发现自己是瓜。 这是因为虚构技术有个伴生的需要:虚拟机动静迁徙。就是在保障虚拟机上服务失常运行的同时,将一个虚拟机零碎从一个物理服务器挪动到另一个物理服务器的过程。大白话就是动静迁徙就是虚拟机搬家(不是同一个物理机),搬家的时候,须要最终用户对搬家无感,虚拟机持续失常的干活,离岗不到职,真正的全天时全天候无休为用户服务。管理员可能在不影响用户失常应用的状况下,灵便调配服务器资源,或者对物理服务器进行培修和降级。 为了保障迁徙时业务不中断,就要求在迁徙时,不仅虚拟机的IP地址不变,而且虚拟机的运行状态也必须保持原状(例如TCP会话状态),所以虚拟机的动静迁徙只能在同一个二层域中进行,而不能跨二层域迁徙。虚拟机心想我可不是小灵通的命,要跨AZ,要跨Region,要冰激凌,要人民币,要走向真正挪动的星辰大海。 大二层网络面临的问题既然要走向星辰大海,那就把本人的地盘扩充成大海。把所有服务器都纳入一个二层网络(大于10000台以上)。纳入之前,咱们先剖析一下大二层网络的要求点:因为虚拟机迁徙这个间接需要必须要求虚拟机在迁徙前后放弃IP地址不变,那么所有服务器必须要通过一个二层网络进行连贯。那么这个二层网络有什么要求呢? 1:大,在一个数据中心服务器数量动辄上万甚至十万级别的明天,能够设想,咱们须要一个足够大的二层网络来连贯数量微小的服务器。 2:快,服务器数量的减少导致业务吞吐量减少,东西向流量减少,要求网络中每个节点都能提供线速转发的能力,并且网络中的链路必须尽可能的都利用起来,保障数据中心的网络带宽,数据的转发最好是能通过一条最短的门路来进行。 先看看传统的VLAN+xSTP二层技术不能把所有服务器都划到同一个二层域。为了提供网络的可靠性,个别会采纳设施冗余和链路冗余,传统架构因为成熟有加,财大气粗,往往是两种措施都采纳。后果就是环路(图中蓝色圈,红色圈)无处不在。二层网络处于一个播送域下,又没有TTL,有限循环之下,就会造成播送风暴,霎时导致端口阻塞和设施瘫痪。 VLAN通过划分VLAN来放大播送域的规模来减小环路,STP(各种STP家族,俗称xSTP)次要是切断备份数据转发缩小环路,两者联合,对于小二层(主机数量不超过1K)够用了。然而大二层中,VLAN是放大网络,天生就和扩充网络相克。xSTP的节点过多,网络收敛性能会成指数级降落,成为扩充网络的瓶颈。 总体来说,传统三层网络架构不反对大二层网络,大二层网络路在何方? 如何实现大二层网络在最近十来年,很多人提出了大二层的网络解决方案,基本上都是围绕着怎么解决环路,总结演绎一下,总体有三个不同的思路 化繁为简坐二学三Overlay化繁为简产生环路的起因是冗余链路和冗余设施,树形构造是没有环路的。那么有没有什么方法在设施、链路冗余的根底上又放弃树型网络的构造呢? 这样既能保障可靠性,又人造无环。基于这样的构想,简略粗犷、间接无效的网络设备虚拟化技术呈现了。 TOR套餐模式:通过网络设备虚拟化(多虚一)和链路聚合技术,简化治理和物理配置,进步带宽利用率,疾速故障收敛和不便扩容。 EOR套餐模式:SVF,将不同网络档次、不同类型的交换机多虚一,通过纵向整合,网络简化成果也非常明显,构造更加扼要清晰。 毛病也很显著:重叠扩展性是有限度的,协定是厂家公有的。 坐二学三认真钻研大二层网络的特点,总结的需要是:须要一个能反对足够多的设施,天生没有环路,并且链路利用率很高的协定,来部署在咱们这个大二层网络中。有没有感觉,咱们如同在哪儿见过,你记得吗,记得那是一个夏天盛开如花。不是,错了,是路由!具体点,外部网关协定不就是干这个事件的吗? 套餐模式:TRILL(ISIS亲妈设计)/SPB根本都是采纳ISIS作为其管制屏幕协定进行拓扑学习计算,用MAC-in-MAC在区域内进行报文传输。 这两个协定的具体技术能够在后续专门讲一下,在这就不开展介绍了。 毛病:对于TRILL和SPB,不同的厂商有这各自的反对,还在分派中。然而有一点是明确的,这些技术的部署和施行都是在网络设备上进行的,与服务器等IT设施无关,CT厂家全程Cover,IT厂商只是个看客。 Overlay如果TRILL/SPB是学习三层协定先进的技术,那Overlay就是伪装成本人个儿就是三层,名正言顺的披上三层的外衣,将大二层网络叠加在现有的根底网络之上,瞒天过海,暗度陈仓。 Overlay通过用隧道封装的形式,将源主机收回的原始二层报文封装后在现有网络中进行通明传输,达到目的地之后再解封装失去原始报文,转发给指标主机,从而实现主机之间的二层通信。 隧道封装是很成熟的技术,然而,个别只能点对点建设隧道。如果有很多主机须要二层通信的话,就须要一个全连贯的网络。真头大。既然点对点不行,那就面对面?交换机期待已久的机会来了。 家喻户晓,“二层交换机”是能够实现下挂主机之间互相二层通信的,而且主机从“二层交换机”的一个端口迁徙到另一个端口时,IP地址是能够放弃不变的。这样不就能够实现大二层网络的需要了吗? Overlay的典型技术次要有VXLAN、NVGRE、STT等,简略说一下阵容最奢华的VXLAN技术,它是VMWare和CISCO提出的Overlay技术计划,采纳Mac in UDP的封装形式,虚拟机收回的数据包在VXLAN接入点(被称为VTEP)加上VXLAN帧头后再被封装在UDP报头中,并应用承载网络的IP/MAC地址作为外层头进行封装,承载网络只须要依照一般的二三层转发流程进行转发即可。 依据这个设计,是不是能够看出,VXLAN人造能够反对跨数据中心的大二层网络的。在这种架构下,无论VM是在本数据中心内迁徙,还是跨数据中心迁徙,都无需变更IP地址。目前在华为云根底IaaS网络数据面全副VXLAN化。 VXLAN技术VXLAN和NVGRE等技术是服务器虚拟化的IT厂商主推的大二层网络技术计划,这也很好了解,对于VXLAN和NVGRE技术来说,报文的封装/解封装都是在服务器外部的虚构交换机vSwitch上进行的,内部网络只对封装后的报文进行一般的二层替换和三层转发,所以技术控制权都在IT厂商手里,CT厂商就是一个路人看客了。然而当把Overlay网络的接入点部署在TOR等网络设备上时,就须要网络设备来实现VXLAN和NVGRE的报文封装。一方面对于虚拟化的服务器来说,网络设备的性能还是要比vSwitch强很多的,用TOR等设施来进行封装,性能更好一些。 另外一方面,在TOR上部署Overlay接入点,也能够把非虚拟化的服务器对立纳入Overlay网络。CT和IT厂商的谐和共赢场面终于到来了。 后续关注本文简略了介绍了大二层网络的由来和根底的大二层网络解决方案,在数据大集中的背景下,企业产生的数据量越来越大,数据的重要性也越来越高。出于灾备、用户就近接入、晋升资源利用率等方面的思考,在前期的文章中,会介绍跨数据中心的网络互联网计划。 点击关注,第一工夫理解华为云陈腐技术~

January 6, 2021 · 1 min · jiezi

关于数据中心:前浪传统数据中心的网络模型

个推运维平台高级网络工程师 山川 随着互联网公司规模的扩充,企业对老本管制和数据安全的需要越来越高,大部分公司往往会自建机房,而非租用云服务器。个推在互联网数据中心(Internet Data Center,简称IDC)网络布局和经营方面也经验了几次的迭代和变迁,同时,咱们也对数据中心网络倒退的历程进行了总结。 咱们将围绕IDC网络经营布局的根本要求、传统PC时代的网络架构、挪动互联网和大数据时代的IDC网络结构、罕用服务器接入技术四个局部对数据中心的倒退历程进行拆解。本文将先与大家分享传统数据中心的网络模型。 01数据中心网络建设的根本要求数据中心网络建设根本要求能够演绎为四点: a)   带宽和流量模型的适配 “南北”流量通常指的是进入和来到数据中心的流量。而服务器到服务器间的交互流量,通常称为“货色”流量。传统的“树形”拓扑中“南北”流量占比拟高,当须要更大带宽时,咱们往往能够通过降级设施的线卡构造或应用端口密度更高的设施来满足要求。古代数据中心内常见的利用,例如Hadoop等,大多采纳“货色”流量,其某些特定集群之间须要复制大量数据或进行虚拟机迁徙。因而,传统“树形”拓扑不太实用于当初IDC的互联网利用。 b)   资本收入最小化与网络相干的资本收入(CAPEX)所占比重比拟大,仅基础架构就占据了整个数据中心约10-15%收入。只管相对老本的收入是不可避免的,但咱们还是能够采取一些形式来缩小相对老本的收入。 有以下两种办法: 从洽购层面来看,咱们能够通过设施标准化来降低成本:比方应用雷同类型的设施甚至应用同一种型号的设施,这样咱们能够通过批量定价、批量洽购的形式,缩小设施保护和备件购买老本。 从网络布局层面来看,网络层协定的设计要兼容多厂家,咱们能够通过引入多个网络设备供应商,采纳竞价的形式来降低成本。 c)   经营收入最小化数据中心规模越大,企业经营收入老本就越高。据无关统计,网络设备越多,故障率越高。在网络管制层面上,设计越简洁,性能越稳固,这样咱们就能够最大限度地缩小软件问题相干的故障。 最小化经营收入的一个关键点在于缩小网络中故障域的大小。网络(这里指的是以太网络)故障次要是由播送或未知单播流量引起的,咱们通过应用全布线设计,能够大大减少数据立体故障域的大小,行将它们限度为网络层次结构中的最低级别。然而,这样的设计不能解决分布式管制立体故障的问题,所以网络设计上咱们须要放弃简洁,尽量减少管制立体协定的应用以尽可能防止协定交互问题的产生、升高网络整体故障产生的频率。此外,咱们还应最大限度缩小网络协议的应用,以缩小测试老本,进步人效。 d)   流量负载平衡的正当利用应用程序负载平衡对于任意一个数据中心而言,都是至关重要的性能。在传统流量工程中,负载均衡器是流量转发门路中的专用设备。网络布局能够帮忙组内多台负载均衡器正当调配流量。任意播前缀[ RFC4786 ]和等价组合多路径(ECMP)性能可用于实现网络流量调度。 **02**传统web时代的网络架构 首先咱们要明确一点:大二层网络基本上针对的是数据中心场景,旨在解决数据中心虚拟机动静迁徙这一特定需要。对于园区网之类的网络,大二层网络架构适用性不强(除了某些非凡场景,例如WIFI漫游等)。 **传统二层架构** 为了保障网络的高可靠性,传统的二层架构在利用于数据中心场景中,网络设计上往往采纳二层冗余链路,而因为传统二层协定没有任何防环机制,这样的做法容易引发二层环路和播送风暴。为了解决环路问题,咱们采纳了两种技术:VLAN技术和xSTP技术。而为了解决播送风暴问题,咱们采纳了如下两个解决方案: 1)通过划分VLAN放大播送域的规模 VLAN技术能够把一个绝对比拟大的物理二层域划分成许多较小的逻辑二层域,这种逻辑二层域被称为VLAN。同一个VLAN内能够进行二层通信,不同VLAN之间则进行二层隔离,这样播送的范畴就能够管制在一个VLAN内,不会扩散到整个物理二层域。 VLAN尽管能够在肯定水平上升高播送风暴的范畴和强度,但还是无奈避免VLAN内播送风暴的造成(只有同一个VLAN内还有环路)。 2) 通过破环协定避免环路的产生 咱们从播送风暴造成的根本原因动手,能够更好地解决播送风暴问题。因为播送风暴是呈现环路才导致的,因而,通过肯定的伎俩,避免环路呈现就能够无效防止播送风暴的产生。 为避免环路呈现,并保障网络的可靠性,咱们能够将冗余设施和冗余链路变成备份设施和备份链路,即在失常状况下,将网络冗余的设施端口和链路进行阻塞,使端口与链路长期不参加数据报文的转发。 只有以后转发的设施、端口、链路呈现故障,导致网络不通时,冗余的设施端口和链路才会被关上,使网络恢复正常。实现这些自动控制性能的协定咱们称为破环协定,其中最罕用的协定则是生成树协定(xSTP)。 当然,也有一些其余的破环协定,比方SEP、RRPP等等,其本质思维和xSTP协定统一。 3) 传统的二层技术网络规模之窘境下面提到传统二层网络最次要的技术是VLAN和xSTP,但这两个技术存在以下问题。 a.  VLAN的问题正如前文所述,VLAN的核心思想之一,就是通过划分VLAN来放大二层域的范畴和规模,从而管制播送风暴的规模。而大二层网络又要求把所有服务器都纳入同一个二层域。这和划分VLAN的初衷是南辕北辙的。所以VLAN技术就无奈很好地反对大二层网络。 b.  xSTP的问题xSTP能够解决大二层网络的环路问题,但因为xSTP的收敛性能等起因(如果xSTP的节点过多,那么整网的收敛速度会呈指数级降落),所以个别状况下xSTP的网络要求其交换机数量不能超过100台。同时因为xSTP须要对冗余设施和链路进行阻塞,这也在肯定水平上升高了网络资源的带宽利用率。故xSTP协定无奈很好地满足大二层网络的需要。 4) 小结总之,因为前文所提及的制约条件,基于VLAN+xSTP技术的二层网络(作为大二层网络的一种),其所能包容的服务器数量,通常不会超过1K。这与真正意义上大二层网络至多能包容一万台以上主机的要求差距甚远。 设施虚拟化架构传统的xSTP技术无奈无效解决大二层环境中的环路问题,于是一种新的技术便应运而生——网络设备虚拟化技术。所谓网络设备虚拟化技术,就是将互相冗余的两台或多台物理网络设备组合在一起,虚拟化成一台逻辑网络设备,在整个网络中只出现为一个节点。 只有网络设备虚拟化与链路聚合技术相配合,就能够把原来的多节点、多链路的构造变成逻辑上单节点、单链路的构造,从而无效防止环路问题。 网络设备虚拟化+链路聚合技术构建的二层网络人造没有环路,其规模仅受限于虚构网络设备所能反对的接入能力,只有虚构网络设备容许,二层网络的规模就不受限制。 然而网络设备虚拟化计划也存在肯定的毛病: 1)这些协定都为厂家公有,因而咱们只能应用同一厂家的设施组网。 2)因为重叠零碎自身的规模限度,目前最大规模的重叠/集群大略能够反对接入1-2万主机,对于超大型的数据中心来说,就显得力不从心了。然而对于个别的数据中心而言,还是能够熟能生巧地运行的。 随着挪动互联网的蓬勃发展,大数据技术利用变得越来越遍及,传统时代的IDC架构难以进行动静扩大,Clos架构因为灵便和老本较低的劣势,被越来越多的大型互联网公司所采纳。 《大数据时代的IDC网络结构和服务器罕用接入技术(下篇)》咱们将会带大家理解Close架构的核心思想及个性、服务器罕用接入技术类型,心愿能给大家带来更多启发。

October 8, 2020 · 1 min · jiezi

谷歌或将在台南科技工业园兴建第二座在台数据中心

近日,隶属于 Alphabet 公司的投资机构科尔控股,被台湾经济事务部投资审议委员会批准,将 260 亿新台币用于向台湾当地企业特许投资顾问股份有限公司增加投资。 据台湾经济事务部投资审议委员会透露,这次增加的投资将主要用于维持企业日常运营与加强相关投资业务,以及扩建现有厂房,采购相关新设备,负担后期运营支出等等。 谷歌公司早前于今年 9 月称,计划在台湾地区追加投资,并在台南科技工业园建设其位于台湾地区的第二座数据中心。但谷歌公司当时并未公布具体的投资金额,因此这次增资被外界视为是在为其第二座数据中心作筹备。 早在 2012 年,谷歌公司就已经开始在台湾彰化县彰滨工业区斥资至少 6 亿美元建造了当时亚洲规模最大,占地 15 公顷,同时也是其位于台湾地区的第一座数据中心。该数据中心于 2013 年 12 月启用后至今,已通过后续追加投资扩建到了第四期。 此外,谷歌公司近年来持续在拓展台湾地区的业务,比如曾在2018年收购了部分 HTC 手机业务,为推广 Pixel 手机而加强了其在台湾地区的研发能力,设立新的人工智能智能研究机构,并计划于 2020 年底在台湾北部启用新的办公室。

November 4, 2019 · 1 min · jiezi

印度版的大众点评如何将-Food-Feed-业务从-Redis-迁移到-Cassandra

Zomato 是一家食品订购、外卖及餐馆发现平台,被称为印度版的“大众点评”。目前,该公司的业务覆盖全球24个国家(主要是印度,东南亚和中东市场)。本文将介绍该公司的 Food Feed 业务是如何从 Redis 迁移到 Cassandra 的。 Food Feed 是 Zomato 社交场景中不可或缺的一部分,因为它可以让我们的用户参与其中并与朋友的餐厅评论和图片保持同步,甚至可以通过这个获取餐厅提供的优惠和折扣。开始我们选择 Redis 作为消息 Feed 流的存储引擎,因为在当时的用户场景这是最好的选择。但是随着业务的发展,我们需要更高的可用性和负载支持,而 Redis 不能很好的满足这个需求。虽然我们可以通过丢失一些数据来避免系统的中断,但这不是我们想做的事情。为了确保我们的系统具有高可用性,我们不得不放弃 Redis,而选择 Cassandra 作为其替代品。 Cassandra 非常适合这个用例,因为它是分布式的,就有高可用性等。并且 Cassandra 也可以用于存储时间序列数据 - 这实际上就是我们的Feed 流。在做出这一重大改变之前,我们确实有一些 Cassandra 的使用经验,但对于像 Feed 这样重要的东西来说肯定是不够的。我们必须弄清楚如何顺利的从 Redis 过渡到 Cassandra,并像在 Redis 上那样有效地运行 Feed,并且没有停机时间。 我们开始花时间在 Cassandra 上,在前两周深入探索其配置并调整它以满足我们的要求。接下来,在最终确定 Feed 的架构之前,我们明确了一下两个情况: Feed 流信息一般只用于读取而基本上不会修改。使用 Redis 的时候,我们可以同时读取上百个 keys 而不必担心读取延迟,但是对于Cassandra 而言,连接延迟可能是读取请求过程中一个相当重要的部分。schema 需要足够灵活,以便将来允许 Feed 中新类型的数据。鉴于我们不断迭代并致力于丰富产品体验,因此在 Feed 中添加元素和功能几乎是不可避免的。我们花了几天时间用于收集了我们项目的数据模式以及各种用户案例,然后开始使用2个数据中心,每个数据中心有3个节点。 我们从 Redis 中迁移大概 6000万条记录到 Cassandra 中用于测试其性能。由于是测试阶段,我们只将一部分流量切入到 Cassandra ,并准备了两个版本的代码,分别写入到 Cassandra 和 Redis 。架构图如下 ...

May 15, 2019 · 1 min · jiezi

Gartner阿里云亚太市场份额第一超过亚马逊和微软总和

4月24日,据彭博社报道,阿里云在亚太云计算市场份额达19.6%,超过亚马逊和微软的总和。这是阿里云连续第二年位居亚太市场第一,份额同比上年增长4.7个百分点,持续扩大领先优势。 报道引述研究机构Gartner的最新市场调研数据,在云计算基础设施领域,2018年阿里云在亚太区域市场份额为19.6%,同期亚马逊为11%、微软为8%。同比2017年,阿里云市场份额增长了4.7个百分点。同时,在全球范围内,阿里云持续保持全球前三的领先地位。 彭博表示,阿里云在过去三年里持续保持高速增长,远超行业平均增长水平。在国际市场上,阿里云的增长更加迅速,其在亚太区域拥有最为广泛的云计算基础设施布局,并且是唯一在马来西亚和印度尼西亚开设数据中心的云服务商。 公开资料显示,2018自然年阿里云营收达到213.4亿,四年间增长20倍。高速增长的同时,阿里巴巴还在不断加码对云业务的战略投入,将全集团的技术与云全面结合并对外输出,目标是构建数字经济时代的云智能基础设施。 同时,阿里巴巴自身也将在未来1到2年内All in Cloud,为数字经济发展提供基于云上最佳实践的新技术和新理念。 本文作者:阿里云头条阅读原文 本文为云栖社区原创内容,未经允许不得转载。

April 25, 2019 · 1 min · jiezi

集群 | 孙悟空分身术

本文首发于我的公众号 cloud_dev,专注于干货分享,号内有大量书籍和视频资源,后台回复「1024」即可领取,欢迎大家关注,二维码文末可以扫。在孙悟空的七十二变中,我觉得最厉害的是分身能力,这也是他百试不得其爽的终极大招,每每都能打得妖怪摸不着北。集群,学名叫 Cluster,可以翻译为簇、聚类、集群等多种意思,不同的翻译,在技术世界里所表示的意思都不尽相同,但都有一个共同的指向,即群体。集群就是由一组计算机所组成的实体,通常作为一个整体向用户提供资源和服务。集群的研究和发展离不开人们对高性能计算的追求,像我们熟悉的向量机、对称多处理机、工作站、超级计算机等等都是对高性能计算追求下的产物。这些系统要么是提高 CPU 的主频和总线带宽来提高系统性能,要么是增加 CPU 个数和内存容量来提高性能,但这些手段对性能的提高都是有限的。有人做过实验,当 CPU 个数超过某一阈值时,系统的性能反而会变差。其主要的瓶颈就在于 CPU 访问内存的带宽并不能随着 CPU 个数的增加而有效增加。相反,集群系统的性能可扩展能力是线性增长的。我们可以简单通过增加机器数来增加集群的运算能力,相比购买高性能的大型计算机,同等运算能力下,我们可以获得更高的性价比。同时,系统的可靠性也得到了增强。历史早在七十年代计算机厂商和研究机构就开始了对集群系统的研究和开发,首先创造性发明集群的是 Seymour Cray(西摩·克雷)—— 超级计算机之父。Seymour 是一位美国工程师,在 1960 年代,CDC 公司开始涉足高性能计算领域,彼时还是大型机的天下,这些大型机设计非常复杂,生产周期漫长,价格还非常昂贵。于是,当时在 CDC 公司担任总设计师的 Seymour 就决心建造出一台他心目中的高性能计算机。Seymour 出于工程师的直觉,很快想到并行是提高计算机性能的有效方式。他使用廉价的方式来获得跟大型机一样的运算能力。他将多个普通的处理器连接起来,使它们能够协同工作,这就是高性能计算机的原型。后来,IBM、HP 等公司学习了 Seymour 的这套架构,高性能计算机开始迅速推广,逐步取代原有的大型机。高性能计算机为当时的登月计划等大型科研项目作出了非常重要的贡献。然后进入八十年代,在摩尔定律的指导下,CPU 频率不断提高,芯片不断降价,个人计算机强势崛起。苹果、微软等公司借助这股东风成为个人计算机时代的王者。随之而来的就是高性能计算机市场遭到了吞噬,被迫只能退守公司服务器市场。但很快,随着互联网的普及,高性能计算机又迎来新的一波热潮。互联网上用户量庞大,普通 PC 难以应付如此众多的网络请求,必须要依赖由高性能计算机组成的服务器集群。在 2000 年左右的网络泡沫时期,成就了很多像 Sun 这样的服务器生产商。如今,IT 行业向云计算冲击,诸如 Google、Apple、Amazon 等很巨头纷纷建立起了自己的数据中心。集群的规模在不断扩大,为海量的数据提高基础设施提供了支撑。根据不同的应用场景,集群也演变出多种形态,比如高性能集群、高可用集群、负载均衡集群等等。集群元素集群不是简单的硬件堆叠,而是硬件和软件的结合。从软件上说,集群至少需要:构建于 TCP/IP 协议上的通信软件,用于集群中节点之间的通信。一套中心管理软件,用于统一管理集群中节点的资源、任务和容错等等。这两点比较好理解,集群的规模往往是比较庞大的,对于管理员来说,需要随时能够知晓集群中各节点的业务正常与否,出问题了应该怎么保证业务能够不中断,遇到流量高峰和低谷的时候,又该怎么响应,这些操作如果纯靠人工来完成那必将很惨烈。依靠软件和网络来完成自动化的管理方式,可以将管理员解放出来。当然,以上说的两点是比较宽泛的,用户可以根据自身需求来部署不同的集群元素。一个比较经典的集群模型当属 Beowulf 集群,它通过一个节点统一将来自网络的请求分配给各个节点进行计算处理。集群与分布式集群与分布式像一对孪生兄弟,傻傻分不清楚。在我看来,它们之间没有特别明确的分界线,集群离不开分布式,分布式也需要集群。如果一定要做个区分,可以套用一个比喻来描述两者的区别:一家餐厅刚开业,由于成本限制招了一个厨师,慢慢地,餐厅生意越做越好,一个厨师已经很难应付过来,于是又招了一个,这两个厨师水平相当,都能做同样的事,两个厨师之间的关系就是集群。两厨师除了炒菜,还要负责洗菜、配菜等等的活,工作负荷已经严重超标,为了让厨师能专心炒菜,把菜做到极致,餐厅又招了配菜师来辅助厨师,厨师和配菜师之间的关系就是分布式。这个例子比较形象,在网站开发中也有类似的关系,两个全栈工程师之间就是集群的关系,前端工程师和后端工程师之间就属于分布式的关系。所以,一定要有区分的话就是:集群是一个业务部署在多个服务器上,而分布式是一个业务拆分成多个子业务部署在不同的服务器上。但在实际部署中,为了高性能,需要分布式部署,为了高可用,需要集群部署,这两者都是业务所必须的指标。所以,集群和分布式之间的关系是相互补充的。虚拟化随着虚拟化技术的发展,一台服务器可以虚拟出多个虚拟机,对外提供业务,这种方式大大提高了资源的利用率,集群的部署也逐步从物理机过渡到虚拟机,灵活性大大提高。但同时也带来了更多新的研究课题。虚拟化计算、虚拟化存储、虚拟化网络、虚拟化安全等等这些课题共同推动着云计算产业迈出一个又一个的台阶。数据中心数据中心是集中存放和运行服务器的地方,是规模最大的集群。随着云计算和大数据概念的风起云涌,Google、Amazon 等这些明星公司幕后的数据中心也开始走入大众的视野。数据中心要求有优秀的架构设计、电路设计、空间设计等等,还要有机制能够应对各种各样的意外,否则一点小小的失误,公司的股价恐怕就要跳水。地理位置的选择也是数据中心考虑的一个指标,随着绿色数据中心概念的兴起,越来越多人关注数据中心所带来的能源问题和环境问题,选择一个远离市区,并且能利用天然水源和气温的地方,将会为数据中心的建设节约大量的成本。Google 等大公司的数据中心就有意放在高纬度、高海拔的地区,以及有湖泊、河流流经地区,以享受天然的空调和冷却水。参考[1] 分布式与集群的区别是什么?[2] 数据中心网络架构演讲 [3] Linux 高性能计算集群[4] 高性能计算机传奇我的公众号 cloud_dev,号内有大量书籍和视频资源,后台回复「1024」即可领取,分享的内容包括但不限于云计算虚拟化、容器、OpenStack、K8S、雾计算、网络、工具、SDN、OVS、DPDK、Linux、Go、Python、C/C++编程技术等内容,欢迎大家关注。

March 28, 2019 · 1 min · jiezi

独家揭秘!阿里大规模数据中心的性能分析

阿里妹导读:数据中心已成为支撑大规模互联网服务的标准基础设施。随着数据中心的规模越来越大,数据中心里每一次软件(如 JVM)或硬件(如 CPU)的升级改造都会带来高昂的成本。合理的性能分析有助于数据中心的优化升级和成本节约,而错误的分析可能误导决策、甚至造成巨大的成本损耗。本文整理自阿里巴巴高级技术专家郭健美(花名:希伯)在Java相关行业会议的分享,主要介绍阿里大规模数据中心性能监控与分析的挑战与实践,希望对你有所启发。作者简介:郭健美(花名:希伯),阿里巴巴高级技术专家,目前主要从事数据中心的性能分析和软硬件结合的性能优化。CCF 系统软件专委和软件工程专委的委员。大家好,很高兴有机会与 Java 社区的开发者交流。我的研究领域在软件工程,主要集中在系统配置和性能方面。软件工程一个比较常见的活动是找 bug,当然找 bug 很重要,但后来也发现,即便 bug-free 的程序也会被人配置错,所以就衍生出了软件配置问题。很多软件需要配置化,比如 Java 程序或 JVM 启动时可以配置很多参数。通过配置,一套软件可以灵活地提供各种定制化的功能,同时,这些配置也会对软件整体性能产生不同的影响。当然这些还在软件配置方面,来了阿里以后,我有机会把这方面工作扩展到了硬件,会更多地结合硬件比如 CPU,来看系统的配置变更和升级改造对性能、可靠性以及业务上线效果的影响。今天主要谈谈我在这方面的一点工作。阿里最有代表性的事件是“双 11”。这里还是用的17年的数据,左上角是双十一的销售额,17年大概是 253 亿美金,比美国同期 Thanksgiving、Black Friday、Cyber Monday 加起来的销售额还要多。当然这是从业务层面去看数据,技术同学会比较关注右边的数据,17年双十一的交易峰值达到 32.5 万笔/秒、支付峰值达到 25.6 万笔/秒。对于企业来说,这么高的峰值性能意味着什么?意味着成本!我们之所以关注性能,就是希望通过持续的技术创新,不断地提高性能、同时节省成本。双十一零点的峰值性能不是一个简单的数字,其背后需要一个大规模数据中心来支撑。 简单来说,阿里的基础架构的上层是各种各样的应用,比如淘宝、天猫、菜鸟、钉钉,还有云计算和支付宝等,这也是阿里的一个特色,即具有丰富的业务场景。底层是上百万台机器相连的大规模数据中心,这些机器的硬件架构不同、分布地点也不同,甚至分布在世界各地。中间这部分我们称之为中台,最贴近上层应用的是数据库、存储、中间件以及计算平台,然后是资源调度、集群管理和容器,再下面是系统软件,包括操作系统、JVM 和虚拟化等。中台这部分的产品是衔接社区与企业的纽带。这两年阿里开源了很多产品,比如 Dubbo、PouchContainer 等,可以看出阿里非常重视开源社区,也非常重视跟开发者对话。现在很多人都在讲开源社区和生态,外面也有各种各样的论坛,但是像今天这样与开发者直接对话的活动并不是那么多,而推动社区发展最终还是要依赖开发者。这样大规模的基础架构服务于整个阿里经济体。从业务层面,我们可以看到 253 亿美金的销售额、32.5 万笔交易/秒这样的指标。然而,这些业务指标如何分解下来、落到基础架构的各个部分就非常复杂了。比如,我们在做 Java 中间件或 JVM 开发时,都会做性能评估。大部分技术团队开发产品后都会有个性能提升指标,比如降低了 20% 的 CPU 利用率,然而这些单个产品的性能提升放到整个交易链路、整个数据中心里面,占比多少?对数据中心整体性能提升贡献多少?这个问题很复杂,涉及面很广,包括复杂关联的软件架构和各种异构的硬件。后面会提到我们在这方面的一些思考和工作。阿里的电商应用主要是用 Java 开发的,我们也开发了自己的 AJDK,这部分对 OpenJDK 做了很多定制化开发,包括:融入更多新技术、根据业务需要及时加入一些 patches、以及提供更好的 troubleshooting 服务和工具。大家也知道,18年阿里入选并连任了 JCP EC(Java Community Process - Executive Committee) 职位,有效期两年,这对整个 Java 开发者社区、尤其是国内的 Java 生态都是一件大事。但是,不是每个人都了解这件事的影响。记得之前碰到一位同仁,提到 JCP EC 对阿里这种大业务量的公司是有帮助,对小公司就没意义了。其实不是这样的,参选 JCP EC 的时候,大公司、小公司以及一些社区开发者都有投票资格,小公司或开发者有一票,大公司也只有一票,地位是一样的。很多国外的小公司更愿意参与到社区活动,为什么?举个简单例子,由于业务需要,你在 JVM 8 上做了一个特性,费了很大的力气开发调试完成、业务上线成功,结果社区推荐升级到 JVM11 上,这时你可能又需要把该特性在 JVM 11 上重新开发调试一遍,可能还要多踩一些新的坑,这显然增加了开发代价、拉长了上线周期。但如果你能影响社区标准的制定呢?你可以提出将该特性融入社区下一个发布版本,有机会使得你的开发工作成为社区标准,也可以借助社区力量完善该特性,这样既提高了技术影响力也减少了开发成本,还是很有意义的。过去我们做性能分析主要依赖小规模的基准测试。比如,我们开发了一个 JVM 新特性, 模拟电商的场景,大家可能都会去跑 SPECjbb2015 的基准测试。再比如,测试一个新型硬件,需要比较 SPEC 或 Linpack 的基准测试指标。这些基准测试有必要性,因为我们需要一个简单、可复现的方式来衡量性能。但基准测试也有局限性,因为每一次基准测试都有其限定的运行环境和软硬件配置,这些配置设定对性能的影响可能很大,同时这些软硬件配置是否符合企业需求、是否具有代表性,都是需要考虑的问题。阿里的数据中心里有上万种不同的业务应用,也有上百万台分布在世界各地的不同服务器。当我们考虑在数据中心里升级改造软件或硬件时,一个关键问题是小规模基准测试的效果是否能扩展到数据中心里复杂的线上生产环境?举个例子,我们开发了 JVM 的一个新特性,在 SPECjbb2015 的基准测试中看到了不错的性能收益,但到线上生产环境灰度测试的时候,发现该特性可以提升一个 Java 应用的性能、但会降低另一个 Java 应用的性能。同时,我们也可能发现即便对同一个 Java 应用,在不同硬件上得到的性能结果大不相同。这些情况普遍存在,但我们不可能针对每个应用、每种硬件都跑一遍测试,因而需要一个系统化方法来估计该特性对各种应用和硬件的整体性能影响。对数据中心来说,评估每个软件或硬件升级的整体性能影响非常重要。比如,“双11”的销售额和交易峰值,业务层面可能主要关心这两个指标,那么这两个指标翻一倍的时候我们需要买多少台新机器?需要多买一倍的机器么?这是衡量技术能力提升的一个手段,也是体现“新技术”对“新商业”影响的一个途径。我们提出了很多技术创新手段,也发现了很多性能提升的机会,但需要从业务上也能看出来。为了解决上面提到的问题,我们开发了 SPEED 平台。首先是估计当前线上发生了什么,即 Estimation,通过全域监控采集数据,再进行数据分析,发现可能的优化点。比如,某些硬件整体表现比较差,可以考虑替换。然后,我们会针对软件或硬件的升级改造做线上评估,即 Evaluation。比如,硬件厂商推出了一个新硬件,他们自己肯定会做一堆评测,得到一组比较好的性能数据,但刚才也提到了,这些评测和数据都是在特定场景下跑出来的,这些场景是否适合用户的特定需求?没有直接的答案。通常,用户也不会让硬件厂商到其业务环境里去跑评测。这时候就需要用户自己拿这个新硬件做灰度测试。当然灰度规模越大评测越准确,但线上环境都直接关联业务,为了降低风险,实际中通常都是从几十台甚至几台、到上百台、上千台的逐步灰度。SPEED 平台要解决的一个问题就是即便在灰度规模很小时也能做一个较好的估计,这会节约非常多的成本。随着灰度规模增大,平台会不断提高性能分析质量,进而辅助用户决策,即 Decision。这里的决策不光是判断要不要升级新硬件或新版软件,而且需要对软硬件全栈的性能有一个很好的理解,明白什么样的软硬件架构更适合目标应用场景,这样可以考虑软硬件优化定制的方向。比如,Intel 的 CPU 从 Broadwell 到 Skylake,其架构改动很大,但这个改动的直接效果是什么?Intel 只能从基准测试中给答案,但用户可能根据自己的应用场景给出自己的答案,从而提出定制化需求,这对成本有很大影响。最后是 Validation,就是通常规模化上线后的效果来验证上述方法是否合理,同时改进方法和平台。数据中心里软硬件升级的性能分析需要一个全局的性能指标,但目前还没有统一的标准。Google 今年在 ASPLOS 上发表了一篇论文,提出了一个叫 WSMeter 的性能指标,主要是基于 CPI 来衡量性能。在 SPEED 平台里,我们也提出了一个全局性能指标,叫资源使用效率 RUE。基本思想很简单,就是衡量每个单位 Work Done 所消耗的资源。这里的 Work Done 可以是电商里完成的一个 Query,也可以是大数据处理里的一个 Task。而资源主要涵盖四大类:CPU、内存、存储和网络。通常我们会主要关注 CPU 或内存,因为目前这两部分消费了服务器大部分的成本。RUE 的思路提供了一个多角度全面衡量性能的方法。举个例子,业务方反映某台机器上应用的 response time 升高了,这时登录到机器上也看到 load 和 CPU 利用率都升高了。这时候你可能开始紧张了,担心出了一个故障,而且很可能是由于刚刚上线的一个新特性造成的。然而,这时候应该去看下 QPS 指标,如果 QPS 也升高了,那么也许是合理的,因为使用更多资源完成了更多的工作,而且这个资源使用效率的提升可能就是由新特性带来的。所以,性能需要多角度全面地衡量,否则可能会造成不合理的评价,错失真正的性能优化机会。下面具体讲几个数据中心性能分析的挑战,基本上是线上碰到过的具体问题,希望能引起大家的一些思考。首先是性能指标。可能很多人都会说性能指标我每天都在用,这有什么好说的。其实,真正理解性能指标以及系统性能本身并不是那么容易。举个例子,在数据中心里最常用的一个性能指标是 CPU 利用率,给定一个场景,数据中心里每台机器平均 CPU 利用率是 50%,假定应用需求量不会再增长、并且软件之间也不会互相干扰,那么是否可以把数据中心的现有机器数量减半呢?这样,理想情况下 CPU 利用率达到 100% 就可以充分利用资源了,是否可以这样简单地理解 CPU 利用率和数据中心的性能呢?肯定不行。就像刚才说的,数据中心除了 CPU,还有内存、存储和网络资源,机器数量减半可能很多应用都跑不起来了。再举个例子,某个技术团队升级了其负责的软件版本以后,通过线上测试看到平均 CPU 利用率下降了 10%,因而声明性能提升了 10%。这个声明没有错,但我们更关心性能提升以后是否能节省成本,比如性能提升了 10%,是否可以把该应用涉及的 10% 的机器关掉?这时候性能就不应该只看 CPU 利用率,而应该再看看对吞吐量的影响。所以,系统性能和各种性能指标,可能大家都熟悉也都在用,但还需要更全面地去理解。刚才提到 SPEED 的 Estimation 会收集线上性能数据,可是收集到的数据一定对吗?这里讲一个 Hyper-Threading 超线程的例子,可能对硬件了解的同学会比较熟悉。超线程是 Intel 的一个技术,比如我们的笔记本,一般现在都是双核的,也就是两个 hardware cores,如果支持超线程并打开以后,一个 hardware core 就会变成两个 hardware threads,即一台双核的机器会有四个逻辑 CPU。来看最上面一张图,这里有两个物理核,没有打开超线程,两边 CPU 资源都用满了,所以从任务管理器报出的整台机器平均 CPU 利用率是 100%。左下角的图也是两个物理核,打开了超线程,每个物理核上有一个 hardware thread 被用满了,整台机器平均 CPU 利用率是 50%。再看右下角的图,也是两个物理核,也打开了超线程,有一个物理核的两个hardware threads 都被用满了,整台机器平均 CPU 利用率也是 50%。左下角和右下角的 CPU 使用情况完全不同,但是如果我们只是采集整机平均 CPU 利用率,看到的数据是一样的!所以,做性能数据分析时,不要只是想着数据处理和计算,还应该注意这些数据是怎么采集的,否则可能会得到一些误导性的结果。数据中心里的硬件异构性是性能分析的一大挑战,也是性能优化的一个方向。比如这里左边的 Broadwell 架构,是 Intel 过去几年服务器 CPU 的主流架构,近几年在推右边的 Skylake 架构,包含最新的 Cascade Lake CPU。Intel 在这两个架构上做了很大的改动,比如,Broadwell 下访问内存还是保持多年的环状方式,而到了 Skylake 改为网格状方式。再比如,L2 Cache 到了Skylake 上扩大了四倍,通常来说这可以提高 L2 Cache 的命中率,但是 cache 越大也不代表性能就一定好,因为维护 cache coherence 会带来额外的开销。这些改动有利有弊,但我们需要衡量利和弊对整体性能的影响,同时结合成本来考虑是否需要将数据中心的服务器都升级到 Skylake。了解硬件的差异还是很有必要的,因为这些差异可能影响所有在其上运行的应用,并且成为硬件优化定制的方向。现代互联网服务的软件架构非常复杂,比如阿里的电商体系架构,而复杂的软件架构也是性能分析的一个主要挑战。举个简单的例子,图中右边是优惠券应用,左上角是大促主会场应用,左下角是购物车应用,这三个都是电商里常见的业务场景。从 Java 开发的角度,每个业务场景都是一个 application。电商客户既可以从大促主会场选择优惠券,也可以从购物车里选择优惠券,这是用户使用习惯的不同。从软件架构角度看,大促主会场和购物车两个应用就形成了优惠券应用的两个入口,入口不同对于优惠券应用本身的调用路径不同,性能影响也就不同。所以,在分析优惠券应用的整体性能时需要考虑其在电商业务里的各种错综复杂的架构关联和调用路径。像这种复杂多样的业务场景和调用路径是很难在基准测试中完全复现的,这也是为什么我们需要做线上性能评估。这是数据分析里著名的辛普森悖论,在社会学和医学领域有很多常见案例,我们在数据中心的性能分析里也发现了。这是线上真实的案例,具体是什么 App 我们不用追究。假设还用前面的例子,比如 App 就是优惠券应用,在大促的时候上线了一个新特性 S,灰度测试的机器占比为 1%,那么根据 RUE 指标,该特性可以提升性能 8%,挺不错的结果。但是如果优惠券应用有三个不同的分组,分组假设就是关联刚才提到的不同入口应用,那么从每个分组看,该特性都降低了应用的性能。同样一组数据、同样的性能评估指标,通过整体聚集分析得到的结果与通过各部分单独分析得到的结果正好相反,这就是辛普森悖论。既然是悖论,说明有时候应该看总体评估结果,有时间应该看部分评估结果。在这个例子里面,我们选择看部分评估、也就是分组上的评估结果,所以看起来这个新特性造成了性能下降,应该继续修改并优化性能。所以,数据中心里的性能分析还要预防各种可能的数据分析陷阱,否则可能会严重误导决策。最后,还有几分钟,简单提一下性能分析师的要求。这里通常的要求包括数学、统计方面的,也有计算机科学、编程方面的,当然还有更重要的、也需要长期积累的领域知识这一块。这里的领域知识包括对软件、硬件以及全栈性能的理解。其实,我觉得每个开发者都可以思考一下,我们不光要做功能开发,还要考虑所开发功能的性能影响,尤其是对数据中心的整体性能影响。比如,JVM 的 GC 开发,社区里比较关心 GC 暂停时间,但这个指标与 Java 应用的 response time 以及所消耗的 CPU 资源是什么关系,我们也可以有所考虑。本文作者:郭健美阅读原文本文来自云栖社区合作伙伴“ 阿里技术”,如需转载请联系原作者。 ...

February 21, 2019 · 2 min · jiezi

阿里大规模数据中心性能分析

郭健美,阿里巴巴高级技术专家,目前主要从事数据中心的性能分析和软硬件结合的性能优化。CCF 系统软件专委和软件工程专委的委员。曾主持国家自然科学基金面上项目、入选上海市浦江人才计划A类、获得 ACMSIGSOFT “杰出论文奖”。担任 ICSE'18NIER、ASE'18、FSE'19 等重要会议程序委员会委员。*数据中心已成为支撑大规模互联网服务的标准基础设施。随着数据中心的规模越来越大,数据中心里每一次软件(如 JVM)或硬件(如 CPU)的升级改造都会带来高昂的成本。合理的性能分析有助于数据中心的优化升级和成本节约,而错误的分析可能误导决策、甚至造成巨大的成本损耗。本文整理自阿里巴巴高级技术专家郭健美在 2018 年 12 月 GreenTea JUG Java Meetup上的分享,主要介绍阿里大规模数据中心性能监控与分析的挑战与实践。大家好,很高兴有机会与 Java 社区的开发者交流。我的研究领域在软件工程,主要集中在系统配置和性能方面。软件工程一个比较常见的活动是找 bug,当然找 bug 很重要,但后来也发现,即便 bug-free 的程序也会被人配置错,所以就衍生出了软件配置问题。很多软件需要配置化,比如 Java 程序或 JVM 启动时可以配置很多参数。通过配置,一套软件可以灵活地提供各种定制化的功能,同时,这些配置也会对软件整体性能产生不同的影响。当然这些还在软件配置方面,来了阿里以后,我有机会把这方面工作扩展到了硬件,会更多地结合硬件比如 CPU,来看系统的配置变更和升级改造对性能、可靠性以及业务上线效果的影响。今天主要谈谈我在这方面的一点工作。阿里最有代表性的事件是“双 11”。这里还是用的去年的数据,因为今年有些数据还没出来。左上角是双十一的销售额,去年大概是 253 亿美金,比美国同期 Thanksgiving、Black Friday、Cyber Monday 加起来的销售额还要多。当然这是从业务层面去看数据,技术同学会比较关注右边的数据,去年双十一的交易峰值达到 32.5 万笔/秒、支付峰值达到 25.6 万笔/秒。对于企业来说,这么高的峰值性能意味着什么?意味着成本!我们之所以关注性能,就是希望通过持续的技术创新,不断地提高性能、同时节省成本。双十一零点的峰值性能不是一个简单的数字,其背后需要一个大规模数据中心来支撑。 简单来说,阿里的基础架构的上层是各种各样的应用,比如淘宝、天猫、菜鸟、钉钉,还有云计算和支付宝等,这也是阿里的一个特色,即具有丰富的业务场景。底层是上百万台机器相连的大规模数据中心,这些机器的硬件架构不同、分布地点也不同,甚至分布在世界各地。中间这部分我们称之为中台,最贴近上层应用的是数据库、存储、中间件以及计算平台,然后是资源调度、集群管理和容器,再下面是系统软件,包括操作系统、JVM 和虚拟化等。中台这部分的产品是衔接社区与企业的纽带。这两年阿里开源了很多产品,比如 Dubbo、PouchContainer 等,可以看出阿里非常重视开源社区,也非常重视跟开发者对话。现在很多人都在讲开源社区和生态,外面也有各种各样的论坛,但是像今天这样与开发者直接对话的活动并不是那么多,而推动社区发展最终还是要依赖开发者。这样大规模的基础架构服务于整个阿里经济体。从业务层面,我们可以看到 253 亿美金的销售额、32.5 万笔交易/秒这样的指标。然而,这些业务指标如何分解下来、落到基础架构的各个部分就非常复杂了。比如,我们在做 Java 中间件或 JVM 开发时,都会做性能评估。大部分技术团队开发产品后都会有个性能提升指标,比如降低了 20% 的 CPU 利用率,然而这些单个产品的性能提升放到整个交易链路、整个数据中心里面,占比多少?对数据中心整体性能提升贡献多少?这个问题很复杂,涉及面很广,包括复杂关联的软件架构和各种异构的硬件。后面会提到我们在这方面的一些思考和工作。阿里的电商应用主要是用 Java 开发的,我们也开发了自己的 AJDK,这部分对 OpenJDK 做了很多定制化开发,包括:融入更多新技术、根据业务需要及时加入一些 patches、以及提供更好的 troubleshooting 服务和工具。大家也知道,今年阿里入选并连任了 JCPEC 职位,有效期两年,这对整个 Java 开发者社区、尤其是国内的 Java 生态都是一件大事。但是,不是每个人都了解这件事的影响。记得之前碰到一位同仁,提到 JCPEC 对阿里这种大业务量的公司是有帮助,对小公司就没意义了。其实不是这样的,参选 JCPEC 的时候,大公司、小公司以及一些社区开发者都有投票资格,小公司或开发者有一票,大公司也只有一票,地位是一样的。很多国外的小公司更愿意参与到社区活动,为什么?举个简单例子,由于业务需要,你在 JVM 8 上做了一个特性,费了很大的力气开发调试完成、业务上线成功,结果社区推荐升级到 JVM11 上,这时你可能又需要把该特性在 JVM 11 上重新开发调试一遍,可能还要多踩一些新的坑,这显然增加了开发代价、拉长了上线周期。但如果你能影响社区标准的制定呢?你可以提出将该特性融入社区下一个发布版本,有机会使得你的开发工作成为社区标准,也可以借助社区力量完善该特性,这样既提高了技术影响力也减少了开发成本,还是很有意义的。过去我们做性能分析主要依赖小规模的基准测试。比如,我们开发了一个 JVM 新特性, 模拟电商的场景,大家可能都会去跑SPECjbb2015 的基准测试。再比如,测试一个新型硬件,需要比较 SPEC 或 Linpack 的基准测试指标。这些基准测试有必要性,因为我们需要一个简单、可复现的方式来衡量性能。但基准测试也有局限性,因为每一次基准测试都有其限定的运行环境和软硬件配置,这些配置设定对性能的影响可能很大,同时这些软硬件配置是否符合企业需求、是否具有代表性,都是需要考虑的问题。阿里的数据中心里有上万种不同的业务应用,也有上百万台分布在世界各地的不同服务器。当我们考虑在数据中心里升级改造软件或硬件时,一个关键问题是小规模基准测试的效果是否能扩展到数据中心里复杂的线上生产环境?举个例子,我们开发了 JVM 的一个新特性,在 SPECjbb2015 的基准测试中看到了不错的性能收益,但到线上生产环境灰度测试的时候,发现该特性可以提升一个 Java 应用的性能、但会降低另一个 Java 应用的性能。同时,我们也可能发现即便对同一个 Java 应用,在不同硬件上得到的性能结果大不相同。这些情况普遍存在,但我们不可能针对每个应用、每种硬件都跑一遍测试,因而需要一个系统化方法来估计该特性对各种应用和硬件的整体性能影响。对数据中心来说,评估每个软件或硬件升级的整体性能影响非常重要。比如,“双11”的销售额和交易峰值,业务层面可能主要关心这两个指标,那么这两个指标翻一倍的时候我们需要买多少台新机器?需要多买一倍的机器么?这是衡量技术能力提升的一个手段,也是体现“新技术”对“新商业”影响的一个途径。我们提出了很多技术创新手段,也发现了很多性能提升的机会,但需要从业务上也能看出来。为了解决上面提到的问题,我们开发了 SPEED 平台。首先是估计当前线上发生了什么,即 Estimation,通过全域监控采集数据,再进行数据分析,发现可能的优化点。比如,某些硬件整体表现比较差,可以考虑替换。然后,我们会针对软件或硬件的升级改造做线上评估,即 Evaluation。比如,硬件厂商推出了一个新硬件,他们自己肯定会做一堆评测,得到一组比较好的性能数据,但刚才也提到了,这些评测和数据都是在特定场景下跑出来的,这些场景是否适合用户的特定需求?没有直接的答案。通常,用户也不会让硬件厂商到其业务环境里去跑评测。这时候就需要用户自己拿这个新硬件做灰度测试。当然灰度规模越大评测越准确,但线上环境都直接关联业务,为了降低风险,实际中通常都是从几十台甚至几台、到上百台、上千台的逐步灰度。SPEED 平台要解决的一个问题就是即便在灰度规模很小时也能做一个较好的估计,这会节约非常多的成本。随着灰度规模增大,平台会不断提高性能分析质量,进而辅助用户决策,即 Decision。这里的决策不光是判断要不要升级新硬件或新版软件,而且需要对软硬件全栈的性能有一个很好的理解,明白什么样的软硬件架构更适合目标应用场景,这样可以考虑软硬件优化定制的方向。比如,Intel 的 CPU 从 Broadwell 到 Skylake,其架构改动很大,但这个改动的直接效果是什么?Intel 只能从基准测试中给答案,但用户可能根据自己的应用场景给出自己的答案,从而提出定制化需求,这对成本有很大影响。最后是 Validation,就是通常规模化上线后的效果来验证上述方法是否合理,同时改进方法和平台。数据中心里软硬件升级的性能分析需要一个全局的性能指标,但目前还没有统一的标准。Google 今年在 ASPLOS 上发表了一篇论文,提出了一个叫 WSMeter 的性能指标,主要是基于 CPI 来衡量性能。在 SPEED 平台里,我们也提出了一个全局性能指标,叫资源使用效率 RUE。基本思想很简单,就是衡量每个单位 Work Done 所消耗的资源。这里的 Work Done 可以是电商里完成的一个 Query,也可以是大数据处理里的一个 Task。而资源主要涵盖四大类:CPU、内存、存储和网络。通常我们会主要关注 CPU 或内存,因为目前这两部分消费了服务器大部分的成本。RUE 的思路提供了一个多角度全面衡量性能的方法。举个例子,业务方反映某台机器上应用的 response time 升高了,这时登录到机器上也看到 load 和 CPU 利用率都升高了。这时候你可能开始紧张了,担心出了一个故障,而且很可能是由于刚刚上线的一个新特性造成的。然而,这时候应该去看下 QPS 指标,如果 QPS 也升高了,那么也许是合理的,因为使用更多资源完成了更多的工作,而且这个资源使用效率的提升可能就是由新特性带来的。所以,性能需要多角度全面地衡量,否则可能会造成不合理的评价,错失真正的性能优化机会。下面具体讲几个数据中心性能分析的挑战,基本上是线上碰到过的具体问题,希望能引起大家的一些思考。首先是性能指标。可能很多人都会说性能指标我每天都在用,这有什么好说的。其实,真正理解性能指标以及系统性能本身并不是那么容易。举个例子,在数据中心里最常用的一个性能指标是 CPU 利用率,给定一个场景,数据中心里每台机器平均 CPU 利用率是 50%,假定应用需求量不会再增长、并且软件之间也不会互相干扰,那么是否可以把数据中心的现有机器数量减半呢?这样,理想情况下 CPU 利用率达到 100% 就可以充分利用资源了,是否可以这样简单地理解 CPU 利用率和数据中心的性能呢?肯定不行。就像刚才说的,数据中心除了 CPU,还有内存、存储和网络资源,机器数量减半可能很多应用都跑不起来了。再举个例子,某个技术团队升级了其负责的软件版本以后,通过线上测试看到平均 CPU 利用率下降了 10%,因而声明性能提升了 10%。这个声明没有错,但我们更关心性能提升以后是否能节省成本,比如性能提升了 10%,是否可以把该应用涉及的 10%的机器关掉?这时候性能就不应该只看 CPU 利用率,而应该再看看对吞吐量的影响。所以,系统性能和各种性能指标,可能大家都熟悉也都在用,但还需要更全面地去理解。刚才提到 SPEED 的 Estimation 会收集线上性能数据,可是收集到的数据一定对吗?这里讲一个 Hyper-Threading 超线程的例子,可能对硬件了解的同学会比较熟悉。超线程是 Intel 的一个技术,比如我们的笔记本,一般现在都是双核的,也就是两个hardwarecores,如果支持超线程并打开以后,一个 hardware core 就会变成两个 hardware threads,即一台双核的机器会有四个逻辑 CPU。来看最上面一张图,这里有两个物理核,没有打开超线程,两边 CPU 资源都用满了,所以从任务管理器报出的整台机器平均 CPU 利用率是 100%。左下角的图也是两个物理核,打开了超线程,每个物理核上有一个 hardwarethread 被用满了,整台机器平均 CPU 利用率是 50%。再看右下角的图,也是两个物理核,也打开了超线程,有一个物理核的两个hardware threads 都被用满了,整台机器平均 CPU 利用率也是 50%。左下角和右下角的 CPU 使用情况完全不同,但是如果我们只是采集整机平均 CPU 利用率,看到的数据是一样的!所以,做性能数据分析时,不要只是想着数据处理和计算,还应该注意这些数据是怎么采集的,否则可能会得到一些误导性的结果。数据中心里的硬件异构性是性能分析的一大挑战,也是性能优化的一个方向。比如这里左边的 Broadwell 架构,是 Intel 过去几年服务器 CPU 的主流架构,近几年在推右边的 Skylake 架构,包含最新的 Cascade Lake CPU。Intel 在这两个架构上做了很大的改动,比如,Broadwell 下访问内存还是保持多年的环状方式,而到了 Skylake 改为网格状方式。再比如,L2 Cache 到了Skylake 上扩大了四倍,通常来说这可以提高 L2 Cache 的命中率,但是 cache 越大也不代表性能就一定好,因为维护 cache coherence 会带来额外的开销。这些改动有利有弊,但我们需要衡量利和弊对整体性能的影响,同时结合成本来考虑是否需要将数据中心的服务器都升级到 Skylake。了解硬件的差异还是很有必要的,因为这些差异可能影响所有在其上运行的应用,并且成为硬件优化定制的方向。现代互联网服务的软件架构非常复杂,比如阿里的电商体系架构,而复杂的软件架构也是性能分析的一个主要挑战。举个简单的例子,图中右边是优惠券应用,左上角是大促主会场应用,右下角是购物车应用,这三个都是电商里常见的业务场景。从 Java 开发的角度,每个业务场景都是一个 application。电商客户既可以从大促主会场选择优惠券,也可以从购物车里选择优惠券,这是用户使用习惯的不同。从软件架构角度看,大促主会场和购物车两个应用就形成了优惠券应用的两个入口,入口不同对于优惠券应用本身的调用路径不同,性能影响也就不同。所以,在分析优惠券应用的整体性能时需要考虑其在电商业务里的各种错综复杂的架构关联和调用路径。像这种复杂多样的业务场景和调用路径是很难在基准测试中完全复现的,这也是为什么我们需要做线上性能评估。这是数据分析里著名的辛普森悖论,在社会学和医学领域有很多常见案例,我们在数据中心的性能分析里也发现了。这是线上真实的案例,具体是什么 App 我们不用追究。假设还用前面的例子,比如 App 就是优惠券应用,在大促的时候上线了一个新特性 S,灰度测试的机器占比为 1%,那么根据 RUE 指标,该特性可以提升性能 8%,挺不错的结果。但是如果优惠券应用有三个不同的分组,分组假设就是刚才提到的不同入口应用,那么从每个分组看,该特性都降低了应用的性能。同样一组数据、同样的性能评估指标,通过整体聚集分析得到的结果与通过各部分单独分析得到的结果正好相反,这就是辛普森悖论。既然是悖论,说明有时候应该看总体评估结果,有时间应该看部分评估结果。在这个例子里面,我们选择看部分评估、也就是分组上的评估结果,所以看起来这个新特性造成了性能下降,应该继续修改并优化性能。所以,数据中心里的性能分析还要预防各种可能的数据分析陷阱,否则可能会严重误导决策。最后,还有几分钟,简单提一下性能分析师的要求。这里通常的要求包括数学、统计方面的,也有计算机科学、编程方面的,当然还有更重要的、也需要长期积累的领域知识这一块。这里的领域知识包括对软件、硬件以及全栈性能的理解。其实,我觉得每个开发者都可以思考一下,我们不光要做功能开发,还要考虑所开发功能的性能影响,尤其是对数据中心的整体性能影响。比如,JVM 的 GC 开发,社区里比较关心 GC 暂停时间,但这个指标与 Java 应用的 response time 以及所消耗的 CPU 资源是什么关系,我们也可以有所考虑。当然,符合三块要求的候选人不好找,我们也在总结系统化的训练流程,欢迎对系统性能有兴趣的同学加入我们。本文作者:amber涂南阅读原文本文为云栖社区原创内容,未经允许不得转载。 ...

January 17, 2019 · 2 min · jiezi

如何“神还原”数据中心? 阿里联合NTU打造了工业级精度的仿真沙盘!

阿里妹导读:如何保障数据中心的稳定运行,是多年来一直困扰业界的难题。机房环境如果发生未预期变化,可能造成难以估计的损失。所以我们希望能构建一个“变更沙盘”,在真实变更之前,操作人员可以先在沙盘中进行试变更,若变更效果在预期内,再对真实环境进行变更,从而尽可能减少变更导致的机房故障。近期,阿里巴巴-南大联合研究院联合实现并上线完成了一个高精度,可连接实时监控系统、基于CFD的变更沙盘系统。本系统在off-the-shelf CFD软件上实现了工业级精度的变更沙盘测试和验证。今天,我们就来观摩这个从零到一的尝试。项目背景随着阿里巴巴业务不断拓展,其数据中心规模也越来越大。相应地,数据中心内的日常演练、运营优化等变更操作越来越频繁;而规模增加导致环境的复杂程度呈指数增长,变更是否可能导致故障,仅凭专家经验,已经越来越难以判断。同时,数据中心变更故障可能造成的业务影响也越来越大,可能造成的损失已难以估计。所以,机房运营人员急需一个标准化的、可靠的机房变更安全验证系统,帮助他们获知变更产生的具体效果会是如何,是否影响生产安全,是否有更合理的变更建议。对于电力变更,可以从电力拓扑图着手构建变更沙盘。但暖通变更,涉及到气流组织变化、热力变化,这些东西看不见也摸不着,传统的方式难以模拟出现实世界中的变化。IDC运营优化团队对此进行了一系列调研工作,认为利用计算流体力学(ComputationalFluid Dynamics,简称CFD)进行机房仿真是较为可能达到生产标准的一种方式。现有的类似的解决方案利用计算流体力学(Computational Fluid Dynamics,简称CFD)进行机房仿真是检查不同变更对机房的热力学影响的通用解决方案。CFD建模可以通过搭建物理模型,载入现实中的热力学设置(冷热量,空调server风速等)来计算一个包间内部的气流分布和温度情况。CFD模拟有较为成熟的技术积累,并被广泛应用与热力学和空气动力学领域。在数据中心领域,也有从包间到芯片级的CFD模拟应用。但由于其精度限制,一般只用于前期设计和规划。应用CFD建立沙盘系统的挑战:1)现有商业CFD软件可以根据对包间进行仿真,得到机房的热力分布、气流动向。但该软件通常应用于设计阶段,采用设计阶段的粗略数据进行模拟,对真实操作情况的还原度较低,温度预测精度仅能达到3度或以上,不能满足用于变更沙盘的精度需求。2)当前CFD软件以人工交互为主,缺少对自动化操作的支持,不能满足自动获取数据和返回结果的需求。大量的操作只能通过人机交互进行,效率低下。3)建模所需要的数据真实性问题。由于模型的准确性与其所采用的模拟设置与实际是否一致息息相关,因此获取的模拟设置信息(如功耗,空调设置信息等)准确性非常关键。通常这些信息是在设计阶段确定的,也有部分是运行时获得的。这些数据只有进行精细的核实才能保证建模的精度(反过来建模的过程可以反推设计实施情况和数据的标准化过程)。我们的解决方案阿里巴巴联合新加坡南洋理工大学(NTU)计算机科学与工程学院文勇刚教授团队,依托阿里巴巴-南大联合研究院平台,通过接近1年的研究,开发和测试,实现并上线完成了一个高精度,可连接实时监控系统的基于CFD的变更沙盘系统。本系统在off-the-shelf CFD软件上实现了工业级精度的变更沙盘测试和验证。本次项目选定了某个机房包间作为技术试点,并在对该机房的物理建模,模型校准和工程落地上进行了紧密合作。1)物理建模:该过程主要将包间内各物理结构设置到模型,提供仿真基础。以达到最好还原度为准则,我们实现了下面所述方面的建模操作:结构建模:对机房结构、墙、通风口、天花板、管道进行设置IT部署建模:机列、机柜、机位设置环境建模:空调设备、传感器设置设备建模:按厂商型号导入服务器模型2)模型校准模型校准的主要原则需要达到下述3个方面的真实还原:机房冷热温度来源:校准中需要确认模型中冷热量与实际一致。机房气流变化原因:校准中需要保证冷热风气流与实际一致。温度测量数据:校准中需要保证模型预测温度与实际一致。为了保证模型可以到工业级精度,项目团队进行了大量的数据核准和模型调整工作。这些工作全方位地对整个机房的相关信息和设置进行了梳理和核实,并形成了完整的标准化校准文档,为以后建模推广打下了坚实的基础。这些校准操作可以分为2类:第1类:数据核准服务器核准(包含:少数服务器U位冲突、服务器功耗校准)传感器核准(包含:空调供风温度、转速和冷热通道传感器位置、数据)第2类:模型调整热气泄露设置调整,热气泄露会导致冷通道温度升高。机柜模拟模式调整,设置为细粒度模拟模式。Server风量设置调整,精确设置server风速以符合实际需求。依托大量的传感器数据,通过上述校准操作,最终模型达到了设计阶段CFD使用未有过的精度。这些精度来源于我们精确地还原各项硬件的布置,各个操作的数据核准和细粒度的server风速校准。3)工程落地如图所示为沙盘系统的流程图。在模型达到预期精度后,团队进一步解决了CFD模拟的自动化问题。通过接入阿里巴巴自研的数据中心实时监控系统(DCIM),我们获取到实时的服务器功耗、空调出风温度和风机转速等数据,通过6Sigma开放SDK将数据写入CFD模型,从而使得模型能够实时模拟包间内真实情况。此外,一旦仿真计算完成后,我们将计算结果从模型中导出,回传到监控系统,从而完成一次仿真计算的闭环。如此,我们实现了将沙盘系统整合进入DCIM系统,并且全程操作可以自动化进行,为将来沙盘系统的应用和推广打下了坚实基础。最终成果:1)精度达标:模型采用真实的监控数据作为输入,并计算模拟的目标传感器测温与实际的传感器测温之间的平均绝对误差(MAE)来作为模型的准确性的测量依据。经过长时间观察(采用不同时刻的数据进行验证),模型模拟精度均能达到阿里巴巴数据中心建设标准要求。理论上可以替代冷热通道传感器,进行数据中心生产包间环境监控。2)成功落地:目前该模型已经成功接入DCIM系统,可以自动从DCIM中抓取数据,返回结果。当前模拟的时耗为大约1小时,通过升级6Sigma License规格未来有希望提升到10分钟。接入该实时CFD模拟系统意味着阿里自研DCIM系统成为世界上唯一有高精度实时CFD模拟模块的数据中心云维管理系统。变更沙盘系统的价值包间可视化:由原来的2D、数字的方式,升级为3D、图形数字结合的展现方式,包括实际布局、热力情况、气流情况,从而可以让机房经理与设施专家能更直观、全面、迅速地了解机房的整体情况,更快发现包间暖通环境问题,辅助优化现场供冷分配与气流组织。故障发现:可以厘米级别监测包间内的温度,快速发现温升(局部热点),从而具备更快、更强的风险识别能力,防止出现大范围的机房温升事件。设计验证:建模过程所需要的物理设置信息通常决定于设计阶段。建模过程中得到的误差反馈信息可以直接验证设计与实施的差别。设计优化(变更指引):沙盘系统可以模拟不同设计下数据中心的操作情况,从而可以用于设计上的优化和数据中心变更的先验平台。暖通控制推荐:可以通过尝试不同空调设置应用到当前环境,得到温度控制最佳、能耗最低的空调设置,实现包间内供冷可靠、智能的控制。业务调度推荐:根据详细的机房温度分布情况,结合功耗水位数据,可以向业务调度系统提供调度参考,使得业务分布更均匀,机房温度分布也更加均匀,降低制冷能耗,提升服务器健康度。未来展望未来合作的方向之一是对变更沙盘系统进行产业级推广和验证,目标是做出业界标准。使得变更沙盘系统可以应用与阿里数据中心的更多机房,去验证设计和优化管理控制。未来,我们希望将系统沙盘推广到整个暖通系统,覆盖到机房外的制冷设备,实现全链条模拟。从而实现整个制冷系统的设计验证和控制优化。综上,变更沙盘系统将可以显著促进数据中心设计到运维的自动化水平,为实现更稳定更高效的数据中心运维提供支撑。这是一次从零到一的尝试,我们构建了第一个可实时的、高精度的暖通变更系统,帮助数据中心运维人员能够判断一次变更是否可能造成故障,从而减少由变更导致的故障。进一步,我们可以给出具体的变更后环境变化,给出变更建议,甚至能够实现自动变更。如此,我们将离机房无人值守的目标越来越近。本文作者:阿里&NTU阅读原文本文来自云栖社区合作伙伴“阿里技术”,如需转载请联系原作者。

January 15, 2019 · 1 min · jiezi

十余位权威专家深度解读,达摩院2019十大科技趋势点燃科技热情

2019年的第一个工作日,阿里巴巴达摩院重磅发布了2019十大科技趋势,引发社会各界对未来科技的讨论和向往。这一发布同样引来科学界的普遍关注。来自包括中科院、清华大学、佛罗里达大学、杜克大学等权威学术机构的十余位专家就此发表评论,深度点评达摩院提出的观点,充分肯定达摩院在基础科研领域持续深耕的专注精神。专家普遍认为,达摩院发布的科技趋势虽然有十个方向,但都是围绕着当前科学发展的几个关键潮流,即以芯片为代表的算力、以图计算为代表的算法以及以5G为代表的连接能力。一、计算是变革的源头传统时代的计算始终在冯诺伊曼架构约束下发展,但人工智能的到来正在挑战冯诺依曼架构,而摩尔定律也接近失效,新型芯片以及新的计算机架构已经成为整个行业研究重心。达摩院认为,计算体系结构正在被重构,基于FPGA、ASIC等计算芯片的异构计算架构正在对以CPU为核心的通用计算发起冲击。“通过推高通用芯片的性能来征服一切的方式已经失效。” 中国科学院计算技术研究所研究员陈天石对此评论说,“学术界和工业界都把目光投向了更加专用的处理器架构,并且一直在期待新器件引发的新的架构演进。”杜克大学副教授、IEEE Fellow陈怡然也表示,目前学术界的研究重心在一些更为革命性的架构研究,例如内存计算、非冯诺依曼架构、神经形态计算等。而佛罗里达大学杰出教授、IEEE Fellow李涛则指出,计算体系结构的变革将主导和引领ICT领域的持续创新和发展,这将是未来产业界的核心竞争力。在人工智能领域,GPU无疑是最受企业以及开发者追捧的芯片。但达摩院认为,数据中心的AI训练场景下,计算和存储之间数据搬移已成为瓶颈,AI专用芯片将挑战GPU的绝对统治地位。“对于训练场景来说,计算量要求非常高,需要存储和处理的数据量远远大于之前常见的应用,AI专用计算架构是最佳选择。” 清华大学微纳电子系副系主任尹首一对达摩院的这一观点表示认可。根据达摩院的判断,AI专用芯片的应用将成为趋势。在2018年的杭州云栖大会上,阿里巴巴曾宣布首款AI芯片AliNPU将于2019年应用于城市大脑和自动驾驶等云端数据场景中。陈天石指出,“AI芯片可以灵活高效地支持视觉、语音和自然语言处理,甚至传统的机器学习应用,将在数据中心场景发挥重要作用。”二、算法的创新让AI更加智能1950年,人工智能之父图灵提出著名的图灵测试用以检验人工智能能力,即如果有超过30%的测试者不能确定被测试者是人还是机器人,则认为是通过测试。图灵提出的猜想可能将会很快实现。达摩院认为,在未来,人类可能无法辨别人工智能生成的语音和真人语音,具备语音交互能力的公共设施将会越来越多,甚至在一些特定对话测试中机器可以通过图灵测试。西北工业大学计算机学院教授谢磊对此表示,“声音合成技术在某些方面已经可以媲美人声,并将会拉动‘耳朵经济’的爆发,各种‘AI声优’ 将上岗,为大家提供听觉盛宴。”人工智能行业的迅速发展与深度学习带来的突破高度相关,但仅靠深度学习要实现通用人工智能仍然困难重重。达摩院认为,结合深度学习的图神经网络将让机器成为具备常识、具有理解、认知能力的AI。杜克大学统计学院终身教授David Dunson对此评论说,“结合了深度学习的图计算方法将实现推荐系统的变革性改进,为用户提供更有趣和更合适的产品,同时改善整体用户体验。”过去两年,城市大脑成为社会热词。达摩院认为,2019年,人工智能将在城市大脑技术和应用的研发中发挥更大作用,未来越来越多的城市将拥有大脑。中国城市规划设计院院长杨保军认为,“城市大脑将不再是单一领域或是单项要素的智慧,而是全局联动、多源交融的智慧。”同济大学智能交通运输系统研究中心主任杨晓光则表示,“新一代城市智能管理、智能服务与智能决策将帮助人类最大程度地预防和综合治理城市病。”三、连接万物的5G催生更多应用场景过去几年,5G的热度并不逊于人工智能。5G构建的不仅是一张人联网,它将会成为连接万物的纽带。达摩院在此次十大科技趋势中提到,5G将催生超高清视频、AR/VR等场景的成熟。中国信通院副总工、工信部信息通信经济专家委员会秘书长陈金桥对此评论说,“5G将掀开数据资源作为生产力的大幕,一个基于泛在高速连接的智能社会必将形成。” 车路协同将会是5G与人工智能两大技术交融的典型场景。达摩院认为,车路协同技术路线会加快无人驾驶的到来,并且将在固定线路公交、无人配送、园区微循环等商用场景将快速落地。单纯依靠“单车智能”的方式革新汽车存在诸多限制,例如传感器部署的成本高,感知系统以及决策系统的可靠性低等。“车路协同的优势在于,可降低单车系统在定位方案部署上的成本,并且可以实现更好的感知与决策。” 中科院自动化研究所研究员赵冬斌如此表示。本文作者:阿里云头条阅读原文本文为云栖社区原创内容,未经允许不得转载。

January 3, 2019 · 1 min · jiezi

跨境物流链路怎么做?菜鸟工程师打造了全球通关“神器”

阿里妹导读:2018天猫双11物流订单量创新高,突破10亿件,这是一次史无前例的物流洪峰。天猫双11十年来,见证了物流业从手写地址、人工分拣,到电子面单、机器人分拣。无论是物流园区、干线运输,还是秒级通关、末端配送,都通过技术高效连接,智能物流骨干网正在加快实现行业数字化、智能化升级。因此,阿里技术推出《菜鸟智慧新物流》专题,邀请菜鸟技术人,为你揭秘物流核心技术。今天第一期,让我们一起走近神秘的“神鲸网络全球通关平台”,全方位了解新技术时代下的跨境智能关务。前言“跨境”,这是在当今行业一个非常 fashion的名词。从2014年起,海关总署陆续颁发多项跨境贸易政策,给跨境进出口业务带来了诸多红利。2014年也被很多业内人士称为跨境进口电商元年。也许你会听到这样一段对话:A:Hey,兄dei,你是做什么的?B:哦,我搞跨境物流的。A:是嘛,跨境这几年很火啊!政府在大力扶持这一块,我看很多公司都在做一块,有前途!B:哪有?道路坎坷,很艰辛的,不过累并快乐着,我也挺看好这块的!在整个跨境物流链路中,会涉及到多个角色:仓、干线、关务、快递等。关务是跨境物流链路最核心的环节,需要协同海关,国检等政府部门完成整个进出口国的通关操作。这块不仅业务复杂,而且存在诸多不确定性。为此,我们搭建了“神鲸网络全球通关平台”。旨在对接海关,协同CP(cainiao partner),从线下到线上,以全球化、数据化、智能化为方向,以快速、轻量、多态为核心目标,为跨境电商客户提供全球一体化的通关解决方案!痛点和挑战如下是整个通关全链路业务流程,包含资质备案、风控、出入区、跨境通关、税汇等核心领域。整个链路交互节点繁多,不同国家,甚至不同监管区在申报模式,交互方式,通关能力上都存在很大差别,另外由于申报链路冗长,任何一个节点出现抖动都有可能导致整个通关发生异常,进而导致申报时效拖长,为保障用户能够正常通关,我们往往需要投入更多的成本去解决申报链路过程发生的种种问题。所以,如何有效使用海关通关能力,给到跨境商户稳定的、高效的、统一的一站式通关解决方案?这是我们需要攻克的核心难题。应对策略通关异常繁多,申报时效冗长,大促成本飙高是大部分跨境通关企业碰到的问题。如何去异常,打时效,降成本,保障通关丝般顺滑?基于此,在神鲸网络通关平台中,我们做了诸多举措,有一体化监控的星宫大盘,阳关道批量申报,政企协同全链路摸高压测以及守护神智能辅助系统等等。今年的双十一大促上,因为有这些强有力的后盾,加上海关通关能力再创新高,大家在喝茶+聊天中度过了一个轻松愉快的双十一。今天,我们重点来交流下星宫大盘、批量申报和智能辅助系统。星宫大盘,一体化监控整个通关链路长,依赖系统多,如果有一个全链路的监控系统进行护卫,不仅可以实时窥视整个链路流转情况,还可以做到异常的实时跟踪处理。为此,我们搭建了关务数据中心,承载关务所有数据,并依托它构建了整个星宫大盘产品,将业务监控,指标监控,系统监控一体化,真正实现360度无死角主动监控。如下图(注:下图中数据非真实数据,仅做示例):数据中心数据中心涵盖了整个关务生态的数据,通过实时+离线两种方式,很好的支撑了实时业务监控和指标监控等核心业务。如下是整个数据中心核心架构,包含消息接入,指标计算,数据存储等核心模块。作为一个数据产品,最基本的的诉求就是能保证数据实时性、准确性,那怎么在大促情况下能够做到99.99%数据准确性?这是数据中心面临的最大的一个挑战。实时性(秒级生效)业务系统通过消息埋点的方式记录各个链路节点数据,通过阿里消息中间件消息异步推送给数据中心。数据中心拥有一个支持水平扩展的庞大的服务器集群,具有强大的消息处理能力,保证消息的实时消费。通过缓存+异步存储的方式提升整体消息处理能力; 存储之前先往缓存存一份,后面热点查询优先从缓存获取数据,提高查询效率,数据插入如果超时或者失败立即创建调度任务进行异步重试插入。准确性(99.99%)由于关务业务特殊性,星宫需要保证监控数据的准确性,传统的方案一般是通过流计算的方式把数据统计出来,这种方案统计和详情数据是分开的,可能会导致数据统计和真实数据存在误差的情况,这对于星宫来说是不可接受的。为此,项目组另辟蹊径采用实时详情数据聚合的方案,这里,我们引入了ES中间件,阿里中间件团队针对ES做了非常多的优化,具有高性能的聚合能力,支持海量级数据的实时聚合。另外我们在数据结构存储上面做了多层优化,比如:热点查询条件用int来逻辑映射,字段存储底层采用列存储。为了加快检索,存储树形结构把目录加载到缓存,犹如数据字典一样。另外为了保证数据消费不丢失,在客户端启动了多层重试机制,保证数据的最终一致性。今年大促上,数据中心表现出色,双11当天QPS达到40000+ 平均耗时11ms,正是这种强大的数据消费能力保证了星宫数据实时性,另外亿级别数据多维度聚合统计基本上都是秒级返回,真正做到了100%可用。批量申报,独木桥变阳关道由于海关各个节点大多采用MQ+FTP的技术架构,文件数的个数会影响整体通道消费能力。另外总署的56号公告要求四单申报进行加签操作,随之带来的将是验签成本的增加。为减轻总署通道压力,并提升验签能力,我们采用了批量申报的策略,简而言之就是将多个订单聚合到一起进行申报,一次加签操作,一次申报动作。如下:批量申报调度模块自研了一个轻量的批量调度框架实现,通过一个任务池汇总所有任务,按照不同业务规则聚合同类型的任务然后进行消费。如下:记得当时该项目刚上线时,还有一个小插曲,压测下来发现整体性能远远达不到要求,这可急坏了整个项目组。任务消费过程大体分为:分页捞取任务-》锁定任务-》消费任务。其中捞取任务和锁定任务过程是通过抢占分布式锁的方式来防止并发,避免同一个任务被多个线程捞取并消费。正式由于这个分布式锁的限制以及单库单表的DB瓶颈,导致整体性能一直上不去。经过讨论,最终我们采用了分布式锁池+DB散列方案。即既然单个分布式锁无法满足要求,那么设计成锁池好了;既然单库单表存在瓶颈,那按照业务关键字进行散列。分布式锁池我们使用的是redis的Set数据结构+spop和sadd命令实现的,应用启动时初始化指定个数的锁放到Set数据结构中,然后通过spop随机获取一个模值捞取任务,任务锁定后再通过sadd返还锁,插入任务时也是通过锁个数进行随机散列到多个库多个表中。通过该机制改造后,整体性能大大提升,数据库压力也降低了好几倍。这次微小的调整,却带来了巨大的性能提升,在今年双十一大促上,批量申报也是大放异彩,整个通关审单时效大大降低,申报能力相比往年也有质的提升。如下是17年和18年双十一某一属地海关的平均审单时效对比,相比17年,今年的平均审单时效非常稳定,基本保持在20分钟以内,海关上行和下行通道毫无压力。如下是某海关30分钟内审单完成率情况,相比往年,今年审单能力有巨大的飞跃,基本上是零堆积,申报速度跟审单速度几乎持平。智能辅助系统,关务守护神今年是关务的智能化元年,在正向申报链路上,我们推出了智能限流与智能hold单产品,自适应保护自身与海关系统。在人工成本降低的同时,保证了海关系统的最大吞吐能力。在异常处理上,我们基于规则引擎上线了异常智能处理系统,通过不断丰富异常处理规则,系统变得越来越聪明,基本上可以自动处理大部分海关异常。同时,作为关务智能大脑,还为关务数据中心提供数据分析服务。智能系统包含产品如下:智能限流整个智能限流的设计不仅支持集群环境下任意接口秒级与分钟级精准限流,还能根据接口的RT与失败率等指标对接口流量进行动态调节。1.技术架构:智能限流分三个主要模块:资源监控(对资源的请求量精准统计)、限流策略(请求量达到阈值后的操作)、智能调控(依据一定的规则与算法调节)。智能限流整体采用了pipeline的设计模式,目前实现了单机限流、集群限流和自适应限流三个阀门,只有全部通过阀门,请求才能被放行,否则就会被拦截。这种设计便于维护以及后期限流策略的扩展,例如在双十一之前紧急增加的集群分钟级限流(开发测试仅半个人日)。单机限流和集群限流都是固定限流,即人为提前设定好接口的限流值,如果请求量超过这个值,便会被流控。人工限流的关键是对请求量的精准统计。动态限流则会依赖一些指标进行实时计算和分析,系统按照一定规则自行判断是否需要限流,这个限流是将接口能力分为档位进行调整,既会下调,也会自动上调恢复接口的能力。2.资源监控资源监控是指统计某个接口的各种指标,包含请求量/失败量/限流量等,这些指标基本上是在单台机器上的统计。但是在限流场景,单机限流仅仅能保护机器本身,对于下游的保护,还是需要集群限流功能,因此还需要对集群环境下的资源访问统计。单机指标统计单机指标主要是基于滑动窗口的原理进行统计,比如QPS(每秒的请求数)的统计是将1秒分为5个时间窗口,每个窗口统计200ms内的请求,最后做累加。单机指标监控主要是做单机限流,单机限流的最大好处是能够保障单台机器不会被上游压垮。而对下游而言,单机限流可用性较低,对集群数据来说准确性不能保障。集群指标统计我们不仅仅要保护自己,还要保护下游系统,因此需要保证集群环境下给到下游的量是精确可控制的。集群指标统计需要借助分布式缓存实现,通过使用incr原子累加功能,实现在分布式环境下对请求量的统计。针对QPS的统计,缓存的key由接口名称+秒级时间戳(yyyyMMddmmSS)组成,例如:xxxx_20181118012012。集群统计的准确性依赖两个点:一个是分布式缓存的性能,另一个是分布式环境下每台机器的时间一致性(NTP网络可以保证)。智能限流的缓存使用的是阿里集团的tair(MDB),单次读写平均在5ms以内,对于并发量不是特别大的业务系统来说误差完全可以接受。3.限流策略通过对资源的准确监控,人工固定限流比较容易实现,只要比较下当前的实际qps值和设定的qps值大小即可,达到设定的限流值该请求就会被终止(目前通过抛出指定类型的异常)。无论是秒级还是分钟级限流,只是监控的粒度不同,即统计的key的时间戳的区别,对于限流的逻辑完全一致。在限流时,我们还会进行主动通知,便于人工干预。异常智能处理异常智能处理主要是在日常和大促后的扫尾阶段发挥重要作用。它以关务知识大脑为核心,协同CP、小二、系统共同高效解决业务异常。处理的异常越多,沉淀的就越多,系统也会越来越智能。关务异常存在繁、杂、多、变等特点,如果靠人工去处理每一个异常订单,需要投入巨大的成本,时效也无法得到保障,在大促期间,异常订单量更是以百倍级别增长。技术是第一生产力,我们需要机器代替人工处理这些异常,系统自动处理也就应运而生。然而,经过不断的实践证明,短期单纯依赖系统自动处理所有的异常是不现实的,有部分还是需要人工介入(比如备案问题),然后再利用系统进行重新申报。因此,异常智能处理系统的目标是:搭建人机交互闭环机制,沉淀底层知识大脑,快速提高异常处理的智能化程度。在底层实现上,我们搭建了一套规则库用于知识沉淀,上层实时监听海关异常回执,实现大部分异常秒级处理;同时,启动定时异常处理任务,每天定点捞取遗漏订单进行处理;最后,为小二和CP推送需要人工介入的异常订单,处理完后再推送到系统,由系统接着处理后续流程。展望未来在全球化的道路上,我们任重而道远,AI智能,大数据协同是未来的方向,基于人工智能方式实现全球通关的丝般顺滑,让全球通关更简单!这是我们的宗旨和目标,我们会一步一个脚印一直走下去!未来的路还很长,我们迫切需要有更多的能人异士加入,一起谱写旷世不灭的传奇。如果你足够优秀,如果你不甘平庸,来吧,让我们一起风骚前行!本文作者:啸鹏阅读原文本文来自云栖社区合作伙伴“阿里技术”,如需转载请联系原作者。

December 4, 2018 · 1 min · jiezi

阿里云梁楹:这样的青春,别样的精彩

人的青春应该怎样度过?相信一千个人心中,有一千个答案。我是郭嘉梁,花名梁楹,在不少人眼中,我是一个来自北方的大男孩,一个自带“古典气质的少年”,其实我是一个喜欢晋级打怪,热爱挑战自我的阿里云工程师。1024程序员节之际,分享我的成长经历,且看别样的“青春修炼手册”。学生时代:热爱、执著、前进早在读书的时候,我就一直很喜欢接触一些新的技术。本科毕业后,我被保送到中科院计算所读研,机缘巧合,我接触到了很有前瞻性的光网络互连技术。当时,在国内做光网络研究的人还是很少的。在导师的指导下,我专注于根据高性能数据中心流量模型,利用光交换机对数据中心的网络拓扑进行快速重构。通过 RYU 控制器完成了控制层的拓扑发现,路由计算等工作。在模拟系统中,实现并验证了 HyperX、Torus、DragonFly 等高性能网络常见拓扑结构 的重构算法 FHTR(fast and hitless data center topology reconfiguration)。在基于 AWGR 的光网络中利用该算法达到了微秒级的拓扑重构,并在小规模拓扑的评测中比之前的最新研究成果降低了 50%的丢包率。终于在2017年投中了欧洲光通信领域顶会ECOC的文章。虽然实验室内接触的技术大多偏重计算机硬件,但当时实验室的同学也喜欢利用业余时间探讨一些互联网的相关技术。研二时,我看到了阿里云正在举办中间件性能挑战赛,我和实验室的小伙伴一拍即合,决定以赛代练,多接触接触工业界的先进技术。当时的赛题是需要实现自定制数据库,满足双十一脱敏数据的高并发写入和查询需求。于是在两个多月的时间里,我们几乎从0开始调研数据库的索引机制,整个暑假的时间都泡在实验室里。最终,在索引阶段,我们通过 TeraSort 的排序算法对 4 亿订单进行聚集索引,并采用多线程同步的方式控制磁盘 I/O。 在查询阶段,通过多线程完成 Join 操作,充分利用了 CPU 资源。同时,利用 AVRO 实现了数据的压缩,将原始数据压 缩到了 46%。使用 LRU 算法完成了基于块的缓存机制,查询的命中率达到 83%。日常学习的沉淀积累、平时练就的细致全面的解题思路、敢打硬仗的勇气,终于帮助我们克服了重重困难,翻越高山和大海,我们拿到了决赛冠军的好成绩!从此,我也结下了与阿里巴巴的缘分。阿里体验:我挑战,我能行2017年,我参加了阿里巴巴的校园招聘,了解到当时正在打算开辟新的业务,也是国内第一个和Elasticsearch官方合作的项目。当时内心就十分向往,虽然对全文搜索技术了解不多,但我依然觉得这是一个不错的挑战机遇。心里有个声音告诉我,如果刚工作的时候,能把一件未知的事情干好,以后职场上没有什么事情是做不好的!十分幸运,我加入阿里就赶上了Elasticsearch项目的启动,以及长达三个月的封闭开发。“一个新人+ 一个新项目”,挑战模式全面升级,而这正是我加入阿里所期待的。还记得刚入职的时候,很多问题搞不清楚,阿里的“老员工”濒湖同学,就像高年级的学长一样,耐心与我共同探讨问题、结对开发,极大的缩短了我融入团队的时间。但毕竟是新项目,压力和焦虑感也随之而来,漫长的封闭开发期,需要我用最快的速度了解阿里云的相关业务,以及适应阿里的开发节奏,这种“折磨”感让我无论是在技术方面还是对公司文化的理解方面,感觉都是经历了一场脱胎换骨式的洗礼。记忆里,几乎所有的场景都是与时间赛跑的拼搏画面,项目也终于在进入封闭开发室两个月后,进入了公测阶段。阿里的工程师每个人都肩负着重要的开发任务,以及相应的责任。主管万喜对我说的一句话,至今记忆犹新,“阿里云上的业务很重要,对待每一行代码都要非常认真,这是客户沉甸甸的信任。”每一次开发新功能时,每一次版本迭代时,我都心怀敬畏。如今,我参与开发的产品和相关技术在国内同行业中已经处于领先位置,获得行业认可和用户的好评。马老师说过,阿里人要有家国情怀。阿里云的业务涉及到的中小型企业非常多,因此我们每一天要做的,就是要完成好这一份重托,这份嘱托,支撑我迎接挑战、面对困难、赢得胜利!不忘初心,迎接未来来到阿里已经一年多了,在这个欢乐的大家庭,我收获很多,不但认识了新的同事,开发了新的产品,身份也从一名学生,正是转变成了工程师,我的“青春”再升级。对于工程师的身份,我感到十分骄傲。目前,我参与的阿里云Elasticsearch产品,提供基于开源Elasticsearch及商业版X-Pack插件,致力于数据分析、数据搜索等场景服务。在开源Elasticsearch基础上提供企业级权限管控、安全监控告警、自动报表生成等功能。Elasticsearch公有云,目前已经部署了4个国内区域以及6个国际区域,在线的弹性调度,配置管理,词典更新,集群监控,集群诊断,集群网络管理等功能均已提供服务。如果有志同道合的小伙伴,欢迎加入我们的团队。从学生时代到阿里巴巴,所有获得的成绩,都来源于对未知的好奇心。所有事情都是这样,做了不一定有机会,但不做一定没机会。未来,我感到身上的责任更重了,我会认真写好每一行代码,做好每一个云产品。认真生活,快乐工作!点击了解阿里云Elasticsearchhttps://data.aliyun.com/product/elasticsearch本文作者:山哥在这里阅读原文本文为云栖社区原创内容,未经允许不得转载。

November 16, 2018 · 1 min · jiezi