UCloud云计算

UCloud云计算 查看完整档案

填写现居城市  |  填写毕业院校  |  填写所在公司/组织填写个人主网站
编辑

国内顶尖的公有云服务商,秉持 “中立、专注”的态度,依托位于国内、亚太、北美、欧洲的全球17大数据中心以及北、上、广、深、杭等全国11地线下服务站,为近5万余家企业级客户提供云计算服务,间接服务用户数量超10亿,部署在UCloud平台上的客户业务总产值达逾千亿人民币。
在这里,我们将分享云计算领域的行业资讯、技术趋势以及一切你想知道的相关讯息,欢迎提问~

个人动态

UCloud云计算 发布了文章 · 10月20日

1024致敬极客精神,我们有一个3天的秘境邀请!

10月23日-25日,在上海市经济和信息化委员会、上海市杨浦区人民政府的指导下,以东方财富、B站、达达、小红书、UCloud优刻得等沪上新生代互联网企业组成的上海浦江星河联谊会(筹)主办、优刻得科技股份有限公司承办,为期3天的1024极客文化节将在上海杨浦创智天地广场举办,向极客群体致敬!

这是一次上海城市级文化活动,希望通过极客文化氛围营造、科创企业集结、互联网人才汇聚、极客精神传递,以此促进上海在线新经济发展、为科创中心建设助力;而展会现场亦从极客视角出发,把用代码创造的科技世界呈现在观众面前。

活动现场将划分科技展览、极客编程、游戏竞技、兴趣社交、舞台演艺5大大展览区域,下面我们走进“极FUN秘境”,一探究竟!

1 名企互动展览,最前沿科技一网打尽

在本届1024极客文化节中,极客们将化身时空冒险者,来到一个虚实融合的异界大陆,开启一场科技冒险之旅。我们向超过20家知名互联网科技企业发出号召与邀请,经过集结,包括科大讯飞、深兰科技、Soul APP、西井科技、亮风台、合合信息、360小程序、怪兽充电、狮尾智能、51world等众多合作企业将在活动现场为大家带来黑科技展示,以及科技未来感十足的展览互动体验。

无人机试飞、云游戏试玩、AR/VR虚拟体验、AI魔镜体检、观摩港口无人驾驶重卡……欢迎来现场感受极客改变世界的力量!

2 快闪编程大赛,“极客之王”实力亮剑

由中国领先的开发者社区及技术媒体SegmentFault思否冠名的编程竞技屋,将为大家呈现精彩的编程赛事对决,极客快闪编程挑战赛和全民互动挑战赛两种参赛形式任意选择,所有参会观众均可现场报名对战。只要你热爱科技、敢于挑战,欢迎实力亮剑!另外,我们还为最终胜出的“极客之王”准备了丰厚的极客大礼包,大奖花落谁家,敬请期待!

3 竞技演艺有料有趣,模拟“头号玩家”

逛完了科技展区,下面到游戏竞技区放松一下!体验冒险刺激的竞速赛车、虚拟驾驶、射击模拟对战;更有迎合青年人喜好的女团、乐队、声优助阵演出。3天循环演出,躁动全场!此外,走出代码的世界,拓展属于自己的社交圈,欢迎到访社交平台Soul APP展台,跟有趣的灵魂来一场面基,这个Social的机会你可一定不能错过!

这里有关于科技的沉浸式体验,也有关于未来的冒险探索!极FUN冒险之旅,更多彩蛋,敬请期待!在本次活动中,特别感谢创智天地、Intel、希捷、极客时间、迪卡侬、猎聘网、海螺服饰、享道出行等为活动提供的合作资源支持!

http://www.huodongxing.com/go/1024wx?qd=jszhihu (二维码自动识别)

1024极客文化节,活动售票通道已开启,原价99元,点击链接,限时免费报名!10月23日-25日,1024极客文化节,上海杨浦创智天地广场,不见不散!

查看原文

赞 0 收藏 0 评论 0

UCloud云计算 发布了文章 · 10月16日

在企业的降本增效诉求下,Cube如何助力科盾业务容器化“一步到位”?

前言

以Docker为代表的容器技术缩短了企业应用从开发、构建到发布、运行的整个生命周期。Gartner推测到2022年将会有75%的全球化企业将在生产中使用容器化的应用(当前约为30%)。由于Docker往往难以独立支撑起大规模容器化部署,因此诞生了Kubernetes等容器编排工具,解决了大规模容器的组织和管理难题。

但事实上,Kubernetes的使用体系还是非常复杂的,对于企业的开发运维人员而言,需要具备一定的网络、存储、系统等方面的技术能力。同时在Kubernetes 集群的部署过程中,也需要面临多节点集群搭建维护、网络和存储的选择配置等难题。上述问题是企业在大规模应用的容器化部署和容器编排中不可避免的,科盾亦面临同样的困境。

科盾为什么选择容器化?

深圳市科盾科技有限公司(下文简称科盾)是全国领先的互联网大数据服务商,是一家专注于网络空间治理领域科研及应用开发的国家高新技术企业,致力于为网安、网信、政府及大中型企业提供大数据互联网舆情监测、网络情报挖掘和企业商情监测等服务,以便及时、精准、全面掌握互联网舆情信息,快速化解舆情危机。同时全面获取网络情报线索和市场竞争情报,为政府机构打击网络违法犯罪、企业提高市场竞争力提供高科技利器。舆情分析的数据来源几乎覆盖所有互联网平台的公开信息,包括常见的资讯网站和社交媒体、自媒体、短视频等平台。因此构建一套完整精准的舆情监测系统,不仅需要强大的数据采集能力,还需要具备强大的数据分析、价值挖掘能力,给底层的IT架构带来巨大的技术挑战。

在实现微服务及容器化部署之前,科盾是直接将应用部署在服务器上的,开发运维人员花费大量时间在开发、测试和生产环境的配置上,还要解决日常出现的网络、日志、监控等问题。随着公司业务的扩展,整个系统越来越庞杂,且依赖复杂、数据没有隔离、逻辑重复,于是科盾将其业务进行了微服务架构的改造。

科盾采用了 SpringCloud 微服务体系及 Eureka 服务注册中心,将整体业务架构分为任务调度、数据采集、数据存储、数据处理等多个环节,其整体业务架构图如下:

任务调度系统根据注册的数据采集节点信息,调度有效的采集目标给数据采集节点,数据采集节点根据算法对目标处理后,将数据结果传输根据其内容类型,传输给基于 MySQL、MongoDB、HBase、Elasticsearch、对象存储等服务的存储队列,再由处理链进行数据清洗、资源文件拆分下载、模型预测、各个子系统业务标签、数据推送服务等。

在微服务阶段,随着应用数量的增加,一次发布往往涉及了多个应用,这对团队的自动化运维水平提出了更高的要求。于是,团队开始对应用进行容器化改造。各个模块打包封装成镜像,就可以在任意平台上运行,轻松实现业务的迁移和扩展;无需重复配置环境,配合Gitlab就可以非常方便的进行持续交付和部署,还可以对应用之间进行隔离。

Cube比容器更快更轻

使用容器后确实解决了科盾先前面临的交付效率、运维成本和环境一致性等问题,但自建Docker服务仍存在一些问题,例如:• 需购买固定资源规格的主机,成本投入比较高;• 只能通过主机进行挂载,操作繁琐;• 只支持单一IP,绑定额外的IP十分繁琐;• 遇到故障时需要额外安装控制调度系统进行重启;• 只能通过namespace和cgroup进行弱隔离;• 需要使用docker命令进行创建,学习成本较高。

通过UCloud容器实例Cube,用户只需要提供打包好的容器镜像,即可实现在数秒之内,实现批量部署容器化应用,而不需要预先购买主机或K8S集群,并且只需为容器实际运行消耗的资源付费。

此外Cube还具备以下优势:• 网络上使用 UCloud VPC网络进行内网服务,与 UCloud 其他云产品打通;• 存储直接使用云盘进行挂载使用,读写性能高,操作便捷;• Cube控制调度系统为容器自动重启,自愈能力强;• UCloud海量资源支撑,超大集群避免单一节点故障;• 使用Firecracker虚拟化技术实现虚拟机级别的强隔离。

基于Cube的优势,科盾已将其数据采集节点迁移到了Cube,日志收集方案由原来的宿主机本地映射存取,改为发送到Kafka队列。由于容器化应用的特质,科盾无需对业务进行改造,直接采用原有镜像即可在 Cube 上部署应用,实现平滑迁移。而 Kafka 的应用,也提升了日志收集、管理的效率。

Cube 帮助科盾实现了业务的快速回滚和横向扩展。后续,科盾计划引入K8S集群,并将更多数据处理链等上的服务迁移至Cube。

总结

科盾的业务架构从传统的服务器部署模式到微服务架构、容器化改造,再到选择UCloud容器实例服务Cube的迁移,是企业降低资源成本、提升开发运维效率的探索之路,也贴合云原生技术崛起的脉络。无论是容器Docker、Kubernetes还是Serverless架构的Cube,最终都会回归到为企业降本增效的核心价值。

**

**

如果您对Cube产品感兴趣,欢迎扫码加入Cube测试交流群!

https://u.wechat.com/ELATXrQmIDI2cCgzioMgl88 (二维码自动识别)

活动预告

想了解有关Cube产品背后的技术架构以及无服务器化容器的技术实现细节,欢迎关注10月23日UCloud TIC大会技术论坛直播(点击阅读原文查看详情),届时将由UCloud容器云研发负责人张苗磊带来精彩分享,敬请关注!

查看原文

赞 0 收藏 0 评论 0

UCloud云计算 发布了文章 · 10月16日

构建·创见|2020 UCloud用户大会10月23日即将启幕

2020年对于UCloud是特殊的一年:1月20日,公司正式登陆科创板,成为中国科创板第一家上市的云计算公司;疫情加速了中国数字化的进程;随着新基建政策的推出,云计算作为5G、工业互联网、大数据、人工智能的底座,再次启动发展引擎。

在时代洪流中,如何做一个屹立潮头的持续创新者?如何进行差异化的市场定位和产品创新,为时代和用户创造价值。2020年10月23日,UCloud“构建•创见”Think in Cloud用户大会,即将在上海杨浦区创智天地召开,线上同步直播,探讨云端构建,一起创见未来。

image

核心产品,全面升级

构建面向未来的云计算平台,UCloud怪兽性能的快杰云主机系列、支持信创异构兼容的轻量级私有云UCloudStack、从数据中心到网络全面定制的混合云等产品,将全面升级,展现UCloud对用户需求的深刻洞察,以及核心产品的演进创新。

数据开放,释放价值

数据成为第五生产要素。助力政府数据开放共享,提升社会数据资源价值,安全屋已成功应用于厦门市大数据安全开放平台、上海市大数据普惠金融平台,厦门市的信息化专家将亲临现场,分享政务数据开放的创新应用。

科技推动,教育进步

高校教育信息化产业升级,开启了高校智慧教育新纪元。在本次TIC上,来自同济大学、华东师范大学信息办的老师,将分享如何用云计算,开展实训平台、无人车研究,推动智慧校园建设与产教融合新模态。

开放共享,聚能生态

中立的UCloud,将以“开放、合作、共赢”的理念,公布生态伙伴合作计划。开放UCloud特色云产品、优质客户资源、全球覆盖能力,以云计算为基石和底座,全面聚能产业链各方力量,创见万物互联,迎接数字新时代。

image

查看原文

赞 0 收藏 0 评论 0

UCloud云计算 发布了文章 · 9月9日

唯快不破!搭载超高性能RSSD云盘的快杰UDB重磅上线

2020年4月中旬,UCloud云数据库产品线发布了MySQL版本的快杰UDB,作为UDB产品架构升级后的最新一代云数据库,快杰UDB采用了业内主流的计算存储分离架构:计算层使用高性能UCloud快杰云主机,存储层采用超高性能RSSD云盘,适合绝大多数的用户场景,包括互联网、物联网、零售电商、物流、游戏等行业。

关于快杰云主机的性能表现,已在《阿里云、腾讯云、UCloud 、华为云云主机对比测试报告》中详细测试对比过,其对MySQL数据库的支持能力尤为突出。在快杰云主机和RDMA NVMe SSD云盘的底层硬件基础上,UCloud数据库团队还专门针对MySQL数据库操作系统等方面做了一系列的定制和调优工作,使快杰版MySQL UDB在不同场景下都具有独特的性能优势。

场景测试
为了便于大家直观感受快杰UDB在真实场景下的表现,UDB团队近期开展了全方位的性能对比和测试。本次压测均在部署了高可用的MySQL5.7 DB环境下,使用SysBench测试工具压测30分钟。且我们选择了3种典型的数据量场景分别进行模拟测试,每种场景均选取了普通版UDB、友商RDS、快杰UDB和快杰云主机自建DB作为比较对象。

场景一:
小型数据量(内存型)


此场景主要模拟数据可以全部读取到缓存里进行查询的业务场景,上图为数据量250张表、每张表25000行记录(压测时数据全部在内存缓存中)的QPS/TPS。

场景二:
中型数据量(中IO型)



此场景主要模拟业务需要一定程度读写磁盘更新缓存的DB使用场景,上图为数据量150张表、每张表800000(80万)行 (压测时数据部分在内存缓存中,部分需要从磁盘中进行读写)的QPS/TPS。

场景三:
大型数据量(大IO型)



此场景主要模拟业务需要大量读写磁盘更新缓存的DB使用场景,上图为数据量150张表、每张表8000000(800万)行(压测时数据大部分都需要从磁盘进行读写)QPS/TPS。

结果分析

从测试结果我们可以看到快杰UDB在三种不同数据量场景下的性能表现卓越,尤其是在小型数据量和中型数据量的场景下优势更加突出。

(图为三种场景下的平均QPS)
• 对比快杰云主机自建
快杰UDB的QPS性能平均高30%,主要原因是快杰UDB在快杰云主机的基础上,还进行了DB系统的进一步调优和操作系统的改善,采用最新最稳定的固件,通过精细化的调度减少云硬盘IOPS的波动影响,这些和UCloud云平台的深度整合调优保证了快杰UDB的性能。

• 对比老架构SSD机型UDB
快杰UDB在大多数场景和配置下性能均优于老架构UDB,其QPS平均提升了24%,这是由于架构升级后的快杰UDB底层拥有更强劲的硬件配置。

• 对比友商同等配置数据库
快杰UDB的QPS性能平均高出32%,这得益于UCloud快杰云主机平台本身在业内具有明显的性能优势(参考《阿里云、腾讯云、UCloud 、华为云云主机对比测试报告》),另一方面得益于前文所述快杰UDB在产品层面的定制优化,使其性能优势更加突出。

快杰UDB除了在性能上具备明显优势,还在价格上对用户最大化让利,如下图所示,我们结合快杰UDB、快杰云主机自建DB、友商的性能数据以及产品价格,进行了性价比的量化(性价比=平均QPS/月报价)对比,结果显示快杰UDB性价比最高,且比自建DB平均高28.6%,比友商RDS平均高75%,比普通版SSD-UDB平均高9%,因此特别适合互联网电商、游戏等需要更高性价比DB服务的业务场景。

快杰UDB优势
MySQL升级到新版快杰UDB后,在控制台上以“NVMe机型”的形式展示:

除了支持最为主流的MySQL 5.6和MySQL 5.7,无缝兼容现在同版本UDB实例的所有核心功能外,用户还可以在快杰UDB上体验到云数据库带来的高可用、高性能、高可扩展性、简单易用、低成本等特性。

高可用:高可用版快杰UDB底层采用双主热备架构,高可用实例两个节点的数据会实时同步,当主节点出现故障无法访问时,会自动切换到备节点,彻底解决因宕机或硬件故障造成的数据库不可用;高可用双主节点可以部署在同一可用区,也可以部署在不同可用区,支持可用区级别容灾。

高性能:快杰UDB的存储层RSSD云盘基于新一代分布式块存储架构,底层以NVMe SSD为存储介质,网络传输使用RDMA,能为用户提供单盘最高达120万的随机读写能力和更低的单路时延能力。

高可扩展性:用户可以对快杰UDB进行磁盘和内存的弹性在线升降级,同时支持大容量存储,最大容量可达32T,非常适用于大容量高性能需求的业务场景。

简单易用:MySQL版快杰UDB通过在线快速部署,帮助用户节省采购、部署、配置等自建数据库工作,还提供自动备份、数据秒级回档、日志管理、自动监控告警、性能优化、CloudDBA等功能,让数据库运维管理更加简单便捷。

低成本:用户可依据业务需求即时部署数据库资源,无需在业务初期采购高成本服务器,有效减少前期一次性大规模成本投入,弹性付费模式也能避免资源的闲置浪费。

总结

随着企业的数据量越来越大,数据库性能的提升变得尤为重要。快杰UDB经过此次架构和硬件升级,无论是对比自建DB,还是友商同等配置下的RDS,其高性能和高性价比都是企业部署高性能数据库的优秀选择。

目前快杰UDB已在北京二可用区B、北京二可用区C、北京二可用区E、上海二可用区A、广州可用区B、香港、台北、胡志明、拉各斯、首尔均已上线,接下来将陆续在菲律宾、曼谷等区域上线,助力用户实现全球化部署。

此外,快杰UDB在9月份即将支持MySQL5.5&percona5.5/5.6/5.7版本,满足用户的多版本需求。在数据库类型上,还将覆盖MongoDB、SQL Server等更多类型,致力于为用户打造高性能高可用的云数据库平台。

查看原文

赞 0 收藏 0 评论 0

UCloud云计算 发布了文章 · 8月27日

Serverless容器实例Cube的研发实践之路

Cube诞生背景

随着云原生技术的推广及落地,容器技术在企业生产环境中的使用比重越来越大。Kubernetes作为容器编排的事实标准,在企业服务中被大量采用。UCloud容器团队在2018年推出了Kubernetes产品UK8S, 这款产品基于UCloud公有云环境实现,无缝集成了UCloud IaaS层计算、网络及存储的服务,使客户能够快速获取到生产可用的Kubernetes集群,并拥有灵活控制集群的能力。

但在UK8S产品推广及接入客户过程中,容器团队也陆续收到一些用户反馈的问题:
**

  • 维护Kubernetes集群增加了额外的负担;用户除了管应用还需要后端资源,并未能实现以应用为中心的业务管理。
  • Kubernetes体系较为复杂,学习曲线比较陡峭,需要客户团队有一定技术储备;对于已经使用了容器但尚未尝试Kubernetes的客户也是如此,一方面需要了解Kubernetes的技术体系,另一方面需要修改应用架构适配Kubernetes。
  • 希望能有一款即开即用的容器产品,通过容器直接拉起应用,不需要等待虚拟机就绪再部署应用,缩短应用就绪等待时间。**

为解决上述用户问题,容器团队开发了一款新的serverless容器产品Cube&version=12040210&nettype=WIFI&lang=zh_CN&fontScale=100&exportkey=AeyrACYKyIn6fp2sFm1vTgs%3D&pass_ticket=4wqmpVNc2jvkdI3dVYbM1f74r5bD%2FzhEMtm19sXCUL0fO4Be09DNFqEUoj08GHxM&fontgear=2.000000),目前正处在公测阶段。除了降低用户使用容器的门槛,该产品还具有以下特性:

  1. 免运维:没有维护资源负担,不需要关心运行位置,以应用为中心,以容器镜像为应用打包标准。
  2. 按需付费:按照应用实际使用资源付费。
  3. 自动扩缩容:基于海量资源,提供API,可按需拉起和关闭应用,自动调度资源。
  4. 高可用:产品本身高可用,同时提供应用自愈能力。

技术选型

在实现Cube产品特性的过程中,容器团队需要解决几个技术问题:

1. 容器运行时的选型

公有云产品必然要考虑多租户隔离问题。不同于UK8S产品以云主机为基础构建的隔离性,Cube产品则直接在宿主物理机上运行容器。标准docker实现的容器并不能实现同台宿主机上不同用户不同容器之间的强隔离,因此Cube产品需要一款同时具备虚拟机强隔离性和容器快速启动特点的容器运行时方案。

容器团队注意到AWS开源了轻量级虚拟机firecracker,具有资源占用少、启动速度快、易于维护等诸多优点,并已用于实际生产环境,非常符合Cube业务场景,因此最终采用了以firecracker轻量级虚拟机为基础的容器运行时方案。从下面两张图可以看出,通过对云计算场景特别的精简和优化, firecracker相对于目前主流的虚拟化组件qemu在启动速度和内存消耗方面有明显的优势。

VMM启动时间和内存占用对比,图片引用来源&version=12040210&nettype=WIFI&lang=zh_CN&fontScale=100&exportkey=AeyrACYKyIn6fp2sFm1vTgs%3D&pass_ticket=4wqmpVNc2jvkdI3dVYbM1f74r5bD%2FzhEMtm19sXCUL0fO4Be09DNFqEUoj08GHxM&fontgear=2.000000)

2. 容器管理服务

支持虚拟机容器运行时的容器管理服务也有多种开源方案,例如containerd/cri-o,kata-container和firecracker-containerd等。经过比较,容器团队选择了cri-o + firecracker-containerd的组合。这二者在功能上能够满足单机容器管理的需求,而且和其他选型相比,代码架构更加清晰,调用链路简单明了,便于后续根据产品需求定制和改造。

3. 容器调度服务

Kubernetes已经成为了容器调度的事实标准,具备丰富的功能和良好的可扩展性。因此容器团队采用Kubernetes作为基本调度框架,并根据产品需求做相关改造,最终基本的服务架构如下所示:

优化改进

虽然采用开源方案可以加快开发进度,但为满足产品需求仍需解决一些问题,主要包括以下几个方面:

1. 容器镜像

在标准的容器镜像实现中,镜像是通过分层结构存储在宿主上的。当创建容器时,容器运行时会在镜像层之上创建一个可写层,并挂载在宿主上供容器实例使用。但Cube容器并不是直接在宿主上运行的,也不需要在宿主上挂载容器根目录。因此容器团队修改了cri-o中镜像层的相关实现,直接将容器可写层以块设备的方式挂载到轻量级虚拟机中而非宿主上,减低了宿主对Cube容器的干扰。

另外,为了解决新镜像拉取缓慢导致的容器实例启动慢的问题,容器团队提出了镜像远程挂载的解决方案。将容器镜像以块设备的形式存储在缓存集群,当需要在此镜像上生成容器实例时,先将容器镜像通过远程挂载的形式挂载到宿主上,然后容器运行时会在宿主上创建一层可写层生成容器实例。同时后台会将远程镜像同步到宿主本地,进一步加速读取,降低集群风险。上述方法可使宿主上首次获取镜像的时间缩短至3s以下,并有进一步优化空间。目前这一功能以镜像缓存的产品形式提供给用户使用,并正在逐步整合到普通镜像拉取过程中。

2. 使用公有云资源

网络方面,Cube容器的网络模型和云主机的基本相同。在将相关网络功能以cni插件的形式实现之后,Cube容器就可以很好的接入到公有云vpc网络中。

存储方面,Cube容器目前支持了两种类型的存储:可以多点读写的网络文件系统nfs和仅单点读写的云硬盘udisk。在文件存储功能上,Cube产品实现了在轻量级虚拟机中自动挂载nfs的功能,用户只需在配置文件中指定好挂载点和挂载参数,就能直接在容器中使用网络文件系统,并可以同时支持vpc网络内用户自建的nfs和UCloud公有云产品ufs。在块设备功能上,容器团队扩展了firecracker块设备的实现。通过添加对vhost-user协议的支持,Cube轻量级虚拟机可以直接对接到spdk服务,从而实现了对高性能的rssd型云硬盘挂载和使用。

3. 容器运行环境

为了减少额外资源消耗,容器团队在容器管理服务和容器运行时上做了大量优化工作。

容器团队修改了cri-o管理容器组的架构,采用了单pod对应单shim的模型。通过一个shim管理一个pod内全部容器,可以显著的降低shim资源消耗,简化容器管理。对于轻量级虚拟机,容器团队也对kernel/rootfs/init进程等做了充分地精简优化,只保留了最基本的功能,以加快启动速度,减小安全攻击面,降低资源消耗。另外,容器团队还在轻量级虚拟机中内置了infra container的实现,Cube作为pod运行时可以不必挂载额外的infra容器。

4. k8s改造

Kubernetes作为一个通用的容器调度框架,能够满足大部分容器管理的需求。但针对Cube特定的使用场景,容器团队仍需对k8s组件做一些改造。在控制面,容器团队采用了自定义的调度器,可以更好的满足多租户场景下任务优先级,调度速度,资源管理的需求。在宿主节点上,鉴于Cube容器运行时的特点,容器团队精简了一些不需要kubelet实现的功能,例如在宿主上挂载configmap/volume目录,运行cni插件,收集特定目录日志等,增强了容器与宿主之间的隔离安全性。

Cube未来展望

在完成了上述开发改造后,Cube产品成功上线,并取得良好效果。后续Cube产品会继续沿着帮助用户提升效率、降低开销、简化维护、节约成本的思路持续迭代更新。在容器性能方面,容器团队会继续优化轻量级虚拟机IO路径,减少虚拟化及管理组件的性能损耗,确保用户容器实例稳定高效运行。在服务管理方面,Cube产品层面会推出多种的容器管理控制器,并实现Cube实例直接接入Kubernetes集群的能力,为用户提供多层次的资源调度方式,方便用户按实际需要管理维护。

如果您对UCloud Cube产品感兴趣,欢迎扫码加入Cube测试交流群!

查看原文

赞 0 收藏 0 评论 0

UCloud云计算 发布了文章 · 7月28日

UCloud推出U位智能资产管理服务,助力托管用户进一步降本增效

在企业数字化转型的浪潮下,出于对业务隐私和数据安全的考虑,越来越多的企业将目光投向了混合云部署模式,而服务器设备托管则可以进一步有效控制企业自建数据中心的运营和管理成本。传统的数据中心托管模式由于缺乏完善的设备监控体系,容易导致资源信息管理不精确、运维效率低等问题。

为解决此类问题,UCloud于近期推出了基于RFID技术的数据中心资产智能管理服务,通过粘贴在IT设备上的RFID标签,可实时定位托管资产的位置、自动统计机架的实时容量和机架利用率、快速盘点资产信息,为接入该服务的托管用户提供准确及时的资产管理数据,助力实现IT基础设施的智能化运维管理。

1 传统数据中心托管资产面临的挑战

据Gartner相关调查发现,目前全球只有不到25%的公司具备合理的IT资产管理规划,大多数公司都使用复杂的人工跟踪监测方式。随着时间的推移,托管设备不断增加,就容易产生IT设备定位难、盘点难、规划难、安全监管难、空间碎片化严重等弊端,具体表现有:

  • IT资产管理基本依赖人工和电子表格方式管理,每次设备变更都需要人工在系统修改。而人工容易出错、变更不及时,使维护成本更高、资产信息错误率高,从而导致整体容量IT资产数据混乱。
  • 人工盘点设备资产耗时长,往往无法匹配快速变化的业务需求,业务变化带来的IT资产变化又无法及时同步到资产统计结果中,这样积累的隐患日益趋多,最终变成难以解决的问题资产。
  • 面对大量的设备信息,例如服务器的维保时间、是否在架、是否在用等情况都无法实时有效地掌握,导致基础设施管理无序、丢失等情况时有发生,缺乏IT资产全生命周期的管理手段。
  • 设备资产管理流程的缺失,导致整个运维管理体系混乱;加上缺乏有效的定位技术手段,设备查找和部署都比较困难、容易出错。

由于很多企业用户不能够及时有效地掌握自有IT设备的相关信息,就导致了业务发展过程中的时间、资金以及系统性能等损失。据Gartner最新发布的《中国智能运维市场指南》表明,已经有相当一部分中国企业开始运用AlOps工具进行IT基础设施智能化运维管理,尤其看重AIOps的监控平台整合能力和数据监控能力的加强。而RFID射频识别技术作为底层物理设备信息采集的重要一环,是帮助企业实现IT资产智能化运维管理的关键。

2 UCloud借助RFID实现托管资产的智能化管理

RFID是一种非接触式的自动识别技术,它通过射频信号自动识别目标对象并获取相关数据,识别工作无须人工干预,可远距离、自动批量进行实物的信息采集,是保证设备信息准确性、完整性的基础。RFID射频识别技术主要由电子标签和读写设备组成,二者之间通过射频信号自动识别IT设备的型号以及位置等信息,并将采集到的信息传输到应用系统进行汇总分析。

基于RFID的智能资产管理服务,在硬件侧主要包括:

  • RFID资产标签:通过RFID发卡器,对每一个资产标签进行初始化,初始化后通过将标签内数据与设备信息进行关联,作为该设备标识,并与设备终生绑定;
  • RFID手持盘点设备:该设备运行资产管理app应用,用于对资产的移动作业,或补充业务,确保全流程的管理;

针对企业用户托管在UCloud数据中心的IT设备,UCloud充分利用了RFID在设备数据采集上的优势,通过粘贴到托管物理设备上的RFID标签,与定位模块配套使用,可以实时自动识别IT托管设备的SN信息、所在的某个具体机架、在机架中的具体U位号、占用机架U位的容量数据、是否在位的状态等基础信息,并通过网络实时上传到控制台可视化界面,实现托管设备的全生命周期管理。

3 RFID智能资产管理服务全方位提升运维效率

相比传统的托管设备人工管理模式,UCloud RFID智能资产管理服务结合了多状态自定义管理、位置变更自动化管理来实现零误差,还可通过可视化追踪自动生成资产全生命周期分析报表,实现精细化的资源管理,其优势非常明显,主要体现在以下几点:

1、规划快 U位资源可视化空间资源精细化管理,容量利用率实时可视,支持IT设备高效部署;远程一键查询,万台设备数据秒级采集,容量精准分析,为容量扩展提供精准数据。

2、上架快 资产标签结构简单,一贴即用,免工具安装,方便不影响设备运行;支持设备信息用手持终端以扫描的方式录入,传统手工录入需要20s,自动录入仅需1s,时间成本可节约95%。

3、维护快通过自动盘点、位置异常警告、后台U位精准定位和现场声光提示,帮助运维人员迅速找到目标设备,在纯人工排查的基础上可降低50%运维人力成本;数万台资产设备自动盘点仅需3s,节省90%时间成本。

4、空间利用率高综合机架空间、服务器类别、设备高度等因素构建容量模型,将设备型号、高度等多维度纳入设备匹配需求,对机柜U位空间利用率实时监控,自动监控设备上架、下架与移动,相比粗放式规划可提升5%-20%空间利用率。

5、投资回报率高随需安装、灵活扩容、按需付费的数据资产服务模式,可以减少初期投入成本,降低设备空置率和投资风险。

4 总结

UCloud基于RFID技术为接入用户提供智能资源管理服务,对托管在数据中心的重要IT设备进行全方位自动监控和管理,大幅提升运维效率和资产安全性。目前UCloud RFID智能资产管理服务将在上海颛桥机房和北京昌平机房完成首批部署,后续将覆盖更多UCloud自建机房,彻底解决用户的托管资产运维管理难题。

查看原文

赞 0 收藏 0 评论 0

UCloud云计算 发布了文章 · 7月7日

智联家园,AI上云 | 世界人工智能大会来啦!

人工智能大会长图议程(1).jpg

云上展厅将于7月8日正式开启,

扫描图中二维码,了解大会详情。

查看原文

赞 0 收藏 0 评论 0

UCloud云计算 发布了文章 · 5月27日

游戏出海,技术先行 ——UCloud助力出海业务最佳实践直播公开课

1 游戏出海企业面临的机遇及风险

Sensor Tower 商店情报数据显示,2019 年全球移动游戏在 App Store 和 Google Play 的预估总收入达到 617 亿美元,较 2018 年增长 14.8%。

其中,来自 iOS 的收入近 370 亿美元,占全球手游收入近 60%,Google Play 贡献的收入为 247 亿美元,占比为 40%

除美国市场以外,前十大手游市场中,增长快速的包括:中国(14.5%),韩国(14.7%),中国台湾(21.4%)。Top10 手游市场中,亚洲地区占据 5 个名额,美国和亚洲仍是全球手游收入增长的主要动力。

2019年,中国自主研发网络游戏海外市场实际销售收入111.9亿美元,保持稳定增幅。国产游戏在海外市场的竞争力变强,预计未来海外市场将带来更大营收。

2019年,中国自主研发游戏海外市场实际销售收入地区分布中,美国的收入占比达到30.9%,日本的收入占比达到22.4%,韩国收入占比为14.3%,三个地区合计占比达到67.5%。

以印度尼西亚、马来西亚、新加坡、泰国、越南、菲律宾为首的东南亚被认为是全球手游市场增长最快的的区域,整个东南亚地区超过95%以上的手游收入都来自这六个国家。

1.1 游戏出海-港澳台

STRENGTHS| 优势

由于文化上的优势,大陆手游公司出海首选港澳台,尤其是现在大陆游戏版号发放较严格,游戏研发商首先在港澳台测试玩家对游戏类型的接受度。

WEAKNESS | 劣势

网络基础设施比较成熟,不过地理形势比较割裂,台湾岛内与岛外的通讯存在公网网络波动,业务部署在岛外容易影响用户体验,同时台湾有资安检查,服务器不能与中国大陆通讯。

OPPORTUNITIES| 机会

港澳台人均GDP位于世界前列,相较于大陆,用户付费意愿更高,游戏里面人均ARPU值较高。

THREATS| 威胁

台湾地区本土公司没有足够的技术能力发展云计算,最大的运营商中华电信不完全是市场化性质,工程师的技术能力和响应时间不能满足大陆公司的快节奏要求。

1.2 游戏出海-印尼

STRENGTHS| 优势

东南亚第一人口大国,印尼总人口数达2.62亿,互联网用户数超过1.3亿,是东南亚最大的游戏市场,智能手机用户过亿,仅次于中国、印度和美国,位居全球第四。

WEAKNESS | 劣势

印尼属于穆斯林国家,约87%的人口信奉伊斯兰教,虔诚的教徒会经常做礼拜,本土电信运营商工程师技术能力和响应时间不一定满足中国公司要求。

OPPORTUNITIES| 机会

印尼PC 互联网没有完全普及,直接进入了移动互联时代,年轻化的人口结构和庞大的人口基数,到2021年,移动游戏玩家数量有望达到1.02亿人。

THREATS| 威胁

印尼有超过1.7万个岛屿,号称千岛之国,网络基础设施有待完善,香港、新加坡的网络不能完全覆盖印尼本土,可能影响玩家游戏体验。

1.3 游戏出海-越南

STRENGTHS| 优势

越南人口超过9000万,免费WIFI的普及率高,智能手机是主流的网络接入设备,占72%的用户;其次是笔记本电脑/台式机,占43%;有13%的用户使用平板电脑,互联网电视机的用户占5%。

WEAKNESS | 劣势

越南的工会力量比较强大,劳工权利意识也很强,技术专业能力和响应速度有待加强。

OPPORTUNITIES| 机会

越南是东南亚增长最快的手游市场,拥有超过3600万玩家,受中国文化影响,三国、仙侠、武侠是越南游戏市场最受欢迎的题材。

THREATS| 威胁

越南《网络安全法》规定,提供互联网相关服务的国内外企业,必须将服务器设在越南境内并在越南设立办事处,该法已于2019年1月1日生效。

1.4 游戏出海-中东

STRENGTHS| 优势

中东互联网基础设施较为成熟,智能手机渗透率达64%,阿联酋是全球智能手机最普及的国家,渗透率高达 80.6%;在卡塔尔,移动网络渗透率超过 90%,卡塔尔电信(Ooredoo)在国内的月 ARPU 超过 50 美元。

WEAKNESS | 劣势

地缘政治和宗教环境比较复杂,在当地发行游戏要注意宗教信仰、风俗习惯。

OPPORTUNITIES| 机会

中东经济较发达的国家:阿联酋、阿曼、巴林、卡塔尔、科威特、沙特阿拉伯海湾六国,总人口超过5000万,人均 GDP 位居世界前列,消费能力强劲,玩家活跃度高,付费玩家的比例不超过20%,但游戏中的大R玩家较多。

THREATS| 威胁

地缘政治和宗教环境比较复杂,在当地发行游戏要注意宗教信仰、风俗习惯。

1.5 游戏出海-非洲

STRENGTHS| 优势

非洲大陆的15亿人口中有3.88亿网民,其中1.6亿人有Facebook账户。移动宽带覆盖率迅速扩张,约60%的人口生活在有3G和4G信号覆盖的范围内,而2G蜂窝信号已覆盖了近九成的人口。

WEAKNESS | 劣势

非洲人均收入偏低,南非、尼日利亚部分区域收入较高,技术人才不足,中国公司在非洲地区发挥着重要且不可或缺的作用。

OPPORTUNITIES| 机会

南非、尼日利亚、肯尼亚为首的非洲国家,在移动互联网的普及率逐年上升,中国与非洲国家几十年的友好往来,使得中国公司在非洲发展具有一定的优势。

THREATS| 威胁

非洲网络基础设施不发达,网络质量较差,本土通信技术和人才培养方面存在不足。

2、 UCloud海外产品优势详解

2.1 全球布局

UCloud全球机房,覆盖面积较广,区域主要有:

中国:北京,上海,杭州,广州,香港,台北,高雄

亚太:东京,首尔,曼谷,新加坡,雅加达,胡志明市,马尼拉

欧美:洛杉矶,华盛顿,莫斯科,法兰克福,伦敦

南亚:孟买

中东:迪拜

南美:圣保罗

非州:拉各斯

海外机房建设基本在覆盖“一带一路”沿线国家或地区,为客户产品服务本地国家或地区的用户,提供质量更优更稳定的网络接入。

对于不同国家或地区的法律法规,例如:

(1)越南的《网络安全法》,需要将业务部署在越南当地,否则将不允许APP产品在越南提供服务;

(2)中国台湾的资安审查政策,中国大陆游戏公司,要求游戏业务不能部署在香港或大陆;

针对这些政策,UCloud在当地的机房,能够为客户避免这类风险。

2.2 PathX全球加速

全球动态加速(PathX),是一款致力于提升应用在全球访问质量的网络加速产品。使用PathX后,借助于分布在全世界的转发集群,各地区用户可实现就近接入,并通过PathX将请求转发回源站,有效规避跨国网络拥塞导致的响应慢、丢包等问题。

依托于UCloud全球机房之间的专线,通过智能域名系统,实现业务的全球加速,不论业务是部署其他云商或IDC机房,都可以无缝接入,在金融、跨域电商、游戏等领域,有大量的使用场景。

2.3 罗马Rome

罗马Rome是一款集网络加速与多云互联为一体的SD-WAN产品。它依托于UCloud全球的数据中心及跨地域、跨国、跨运营商内网网络,为企业提供便捷的广域网就近接入、链路动态调度、多云互联的能力,帮助用户轻松实现云、数据中心、企业的专属网络高效互联。

对于那些已经选择了其他云服务的用户来说,同样可以加入到罗马网络,“原汁原味”地感受到网络传输优化和链路动态调度等技术带来的良好效果,轻松实现跨云、异地容灾,防范于未然。

2.4 安全防护

UCloud在台北机房本地提供70G清洗,可以初步防护小规模DDoS攻击,在香港提供超过400G的DDoS防护,另外在全球六个清洗中心:洛杉机、华盛顿、法兰克福、新加坡、东京、台北、香港,总共提供350G防护,对于中国公司出海最核心的区域,UCloud为客户保驾护航。

3 UCloud出海最佳实践

3.1 全球加速PathX

业务痛点:

l 业务部署在香港,香港用户直连部署在香港的业务。

l 台湾用户、新马用户访问香港业务时,由于网络出现不稳定现象,影响用户体验。

解决方案:

l 使用香港与台北、新加坡之间的PathX加速专线,用户就近接入网络,提升速度。

l 通过智能域名解析,台湾、新马用户就近接入UCloud当地节点,专线与香港交互。

3.2 网络安全

解决方案一:

l 被攻击时,启用香港高防,台湾以外的区域直连香港高防IP。

l 港澳台最大游戏玩家群体在台湾,被攻击时在台湾本地使用70G网络防护,保障台湾玩家。

解决方案二:

l 攻击出海游戏的黑客,一般是在中国大陆,通过智能域名解析引导其攻击大陆机房。

l 大陆机房的IP无法使用,黑客会以为游戏已经受到影响,但只影响大陆,不影响港台业务。

l 这本质上是社会工程学攻防,如果黑客通过VPN访问业务,也会发现真实IP,这时可启用高防。

3.3 全球同服游戏

方案一:一个中心节点+边缘节点加速

方案说明:

l 游戏部署在一个中心区域

l 全球其他区域用户访问中心区域

l 各区域用户通过PathX与中心区域通讯

方案二:全局服+区服架构

l 根据全球监控,评估游戏部署在哪个区域,能满足游戏对网络的要求。

l 在开展业务的目标区域,部署区服,覆盖当地用户。

l 区服与中心服之间使用UCloud全球专线UDPN,联通各区域之间内网,通过专线交互数据。

作者:钱建锋 UCloud解决方案架构师

直播预告:

查看原文

赞 0 收藏 0 评论 0

UCloud云计算 发布了文章 · 4月10日

从Spring Cloud到Kubernetes的微服务迁移实践

写在前面

要出发周边游(以下简称要出发)是国内知名的主打「周边游」的在线旅行网站,为了降低公司内部各个业务模块的耦合度,提高开发、交付及运维效率,我们在 2017 年就基于 Spring Cloud 完成了公司内部业务微服务化的改造,并在 2019 年实现了 Spring Cloud 至 UK8S 平台的迁移。 

本文从要出发的业务架构、Prometheus JVM 监控、基于 HPA 的峰值弹性伸缩、基于 Elastic 的APM链路跟踪及 Istio 服务治理等方面介绍了我们基于UK8S的 Spring Cloud 改造实践。

Why K8S & Why UK8S

Spring Cloud 作为当下主流的微服务框架,在功能层面为服务治理定义了智能路由、熔断机制、服务注册与发现等一系列的标准,并提供了对应的库和组件来实现这些标准特性,对微服务周边环境提供了最大力度的支持。

改造前,Spring Cloud 的业务架构如下:服务发现部分采用了 Spring Cloud 的 Eureka 组件,熔断器组件采用了 Hystrix,服务网关使用了Zuul 和 Spring Cloud Gateway(历史原因),分布式配置主要采用了 Spring Cloud Config(部分小组使用了Apollo),并通过 Feign 实现了客户服务端的负载均衡。

但 Spring Cloud 也有一些不可避免的缺点,如基于不同框架的不同组件带来的高应用门槛及学习成本、代码级别对诸多组件进行控制的需求与微服务多语言协作的目标背道而驰。

在我们内部,由于历史原因,不同小组所使用的 API 网关架构不统一,且存在多套 Spring Cloud,给统一管理造成了不便;Spring Cloud 无法实现灰度发布,也给公司业务发布带来了一定不便。更重要的是,作为一家周边游网站,我们经常会举行一些促销活动,面临在业务峰值期资源弹性扩缩容的需求,仅仅依靠 Spring Cloud 也无法实现资源调度来满足业务自动扩缩容的需求。

在决定向 UK8S 转型时,我们也考虑过使用 Kubespray 自建 K8S 集群,并通过 Cloud Provider 实现 K8S 集群与云资源的对接,例如使用 Load Balance、Storage Class、Cluster Autoscaler(CA) 等,但在这种情况下,新增 Node 节点需要单独去部署安装 Cloud Provider,给运维工作带来了一定的复杂性。

UK8S 实现了与内部 UHost 云主机、ULB 负载均衡、UDisk 云盘等产品的无缝连接,我们能够在 UK8S 集群内部轻松创建、调用以上产品。在峰值弹性的场景下,也能够通过 UK8S 内部的 CA 插件,实现 Node 级别的资源自动扩缩容,极大提升了运维效率。通过其 CNI 插件,UK8S 与 UCloud 自身 VPC 网络相连接,无需采用其他开源网络解决方案,降低了网络复杂度;而且 UK8S 原生无封装的特质,也给了更大的改造空间,并且能够在出现故障时自己快速排查定位解决。

整体业务架构

从 Spring Cloud 到 UK8S 的过程,也是内部服务模块再次梳理、统一的过程,在此过程中,我们对整体业务架构做了如下改动:

1. 去掉原有的 Eureka,改用 Spring Cloud Kubernetes 项目下的 Discovery。Spring Cloud 官方推出的项目 Spring Cloud Kubernetes 提供了通用的接口来调用Kubernetes服务,让 Spring Cloud 和 Spring Boot 程序能够在 Kubernetes 环境中更好运行。在 Kubernetes 环境中,ETCD 已经拥有了服务发现所必要的信息,没有必要再使用 Eureka,通过 Discovery 就能够获取 Kubernetes ETCD 中注册的服务列表进行服务发现。

2. 去掉 Feign 负载均衡,改用 Spring Cloud Kubernetes Ribbon。Ribbon 负载均衡模式有 Service / Pod 两种,在 Service 模式下,可以使用 Kubernetes 原生负载均衡,并通过 Istio 实现服务治理。

3. 网关边缘化。网关作为原来的入口,全部去除需要对原有代码进行大规模的改造,我们把原有的网关作为微服务部署在 Kubernetes 内,并利用 Istio 来管理流量入口。同时,我们还去掉了熔断器和智能路由,整体基于 Istio 实现服务治理。

4. 分布式配置 Config 统一为 Apollo。Apollo 能够集中管理应用在不同环境、不同集群的配置,修改后实时推送到应用端,并且具备规范的权限、流程治理等特性。

5. 增加 Prometheus 监控。特别是对 JVM 一些参数和一些定义指标的监控,并基于监控指标实现了 HPA 弹性伸缩。

Kubernetes 化后业务架构将控制平面和数据平面分开。Kubernetes Master天然作为控制平面,实现整套业务的控制,不部署任何实际业务。数据平面中包含了基于 Java、PHP、Swoole、.NET Core 等不同语言或架构的项目。由于不同语言对机器性能有着不同要求,我们通过 Kubernetes 中节点 Label,将各个项目部署在不同配置的 Node 节点上,做到应用间互不干扰。

基于Prometheus 的JVM监控

在 Spring Cloud 迁移到 Kubernetes 后,我们仍需要获取 JVM 的一系列底层参数,对服务的运行状态进行实时监控。Prometheus 是目前较为成熟的监控插件,而 Prometheus 也提供了 Spring Cloud 插件,可以获取到 JVM 的底层参数,进行实时监控。

我们设置了响应时间、请求数、JVM Memory、JVM Misc、Garbage Collection 等一系列详尽的参数,为问题解决、业务优化提供可靠的依据。

基于HPA的峰值弹性伸缩

要出发作为一家周边游服务订购平台,在业务过程中经常会涉及到景区、酒店门票抢购等需要峰值弹性的场景。Kubernetes 的 HPA 功能为弹性伸缩场景提供了很好的实现方式。

在 Kubernetes中,HPA 通常通过 Pod 的 CPU、内存利用率等实现,但在 Java 中,内存控制通过 JVM 实现,当内存占用过高时,JVM 会进行内存回收,但 JVM 并不会返回给主机或容器,单纯基于 Pod / CPU 指标进行集群的扩缩容并不合理。我们通过 Prometheus 获取 Java 中 http_server_requests_seconds_count(请求数)参数,通过适配器将其转化成 Kubernetes API Server 能识别的参数,并基于这一指标实时动态调整 Pod 的数量。

UK8S 产品也提供了自身的集群伸缩插件,通过设置伸缩组,并匹配相应的伸缩条件,能够及时创建相应的云主机作为 Node 节点,方便我们在业务高峰时期更快速高效地拉起资源。

基于Elastic的APM链路跟踪

微服务框架下,一次请求往往需要涉及到多个服务,因此服务性能监控和排查就变得复杂;不同服务可能由不同的团队开发,甚至使用不同的编程语言来实现;服务有可能部署在几千台服务器,横跨多个不同的数据中心。

因此,就需要一些可以帮助理解系统行为、用于分析性能问题的工具,以便发生故障的时候,能够快速定位和解决问题。

目前市面有很多开源的APM组件,Zipkin、Pinpoint、Skywalking等等。我们最终选择了基于Elastic开源的apm-server。正是由于市面上有太多的监控开源项目,但是各项目之间无法很好的互通。而Elastic通过filebeat收集业务日志,通过metricbeat监控应用服务性能,通过apm-server实现服务间的tracing,并把数据统一存放在es,很好的将logging、metrics、tracing整合到一起,打破了各项目之间的壁垒,能够更快速的协助运维及开发定位故障,保障系统的稳定性。

Istio服务治理

基于应用程序安全性、可观察性、持续部署、弹性伸缩和性能、对开源工具的集成、开源控制平面的支持、方案成熟度等考虑,我们最终选择了 Istio 作为服务治理的方案,主要涉及以下几个部分:

1.  Istio-gateway 网关:Ingress Gateway 在逻辑上相当于网格边缘的一个负载均衡器,用于接收和处理网格边缘出站和入站的网络连接,其中包含开放端口和TLS的配置等内容,实现集群内部南北流量的治理。

2. Mesh 网关:Istio内部的虚拟Gateway,代表网格内部的所有Sidecar,实现所有网格内部服务之间的互相通信,即东西流量的治理。

3. 流量管理:在去除掉 Spring Cloud 原有的熔断、智能路由等组件后,我们通过对 Kubernetes 集群内部一系列的配置和管理,实现了 http 流量管理的功能。包括使用 Pod签对具体的服务进程进行分组(例如 V1/V2 版本应用)并实现流量调度,通过 Istio 内的 Destination Rule 单独定义服务负载均衡策略,根据来源服务、URL 进行重定向实现目标路由分流等,通过 MenQuota、RedisQuota 进行限流等。

4. 遥测:通过 Prometheus 获取遥测数据,实现灰度项目成功率、东西南北流量区分、服务峰值流量、服务动态拓扑的监控。

总结

目前我们已将旗下「云客赞」社交电商 App 全部迁移至 UK8S,开发语言包括Java、PHP-FPM、NodeJS 等等。结合CI/CD,能快速实现服务迭代以及新项目上线,大大提升了开发以及运维的工作效率;通过完善的日志、监控、链路跟踪及告警系统,能够快速的定位故障,并且根据遥测数据提前预判峰值,通过HPA实现服务自动伸缩,科学的分配资源,大大降低了计算资源成本;通过Istio服务治理,很好的实现了流量的管理,并且基于此轻松的实现了灰度发布。

接下来,我们将更加丰富CI/CD流水线,加入单元测试、代码扫描、性能测试等提升测试效率;引入chatops丰富运维手段;借助Istio实现多云管理进一步保障业务的稳定性。

◆ 本文作者介绍:王琼,「要出发周边游」运维架构师兼运维经理,负责公司云原生落地和企业容器化改造。2016年开始接触K8S,在K8S以及Service Mesh领域持续深耕,致力于搭建生产级可用的容器服务平台。

查看原文

赞 2 收藏 1 评论 0

UCloud云计算 发布了文章 · 4月3日

UCloud基于Linux内核新特性的Conntrack卸载设计与优化

近期,Netfilter 和 Mellanox 联合开发了flowtable hardware offload 功能,使flowtable成为一种标准的conntrack卸载方案,并实现了Linux标准的Netfilter 硬件offload接口。作为一个新功能,还存在一些缺陷和不完善的地方。

对此,我们做了大量的硬件卸载开发工作,进行问题修复、功能优化,帮助完善kernel功能并提升性能,后续也计划将该功能合并至UCloud外网网关,进一步提升系统性能和管理能力。

优化后的性能飞跃

首先,来看一组简单粗暴的数据。

在所有硬件卸载开发工作完成后,我们基于flowtable的conntrack offload,从bps、pps、cpu使用率等维度分别进行了系列性能对比测试,测试结果如下:

  • 非硬件卸载模式:

①单条流带宽测试为12GBps,耗费2个host CPU;

②多条流小包包量测试为1Mpps,耗费8个host CPU; 

  • 硬件卸载模式:

①单条流带宽测试为23GBps,耗费 0 host CPU;

②多条流小包包量测试为8Mpps,耗费 0 host CPU; 

可以看到在硬件卸载模式下bps、pps性能提升显著,不仅做到了CPU无损耗,性能还分别提升1倍、8倍之多。不过对于新建连接率cps并没有太显著的提升,分析原因为该性能由conntrack在软件协议栈中完成,与硬件无关。在已有层面,一旦该特性应用于产品上,预估将带来极大的性能飞跃。

当然,性能提升的背后离不开每一个细微技术的打磨:我们对conntrack offload与NAT功能分别进行了问题修复与优化,并在此基础上,还与Netfilter、Mellanox合作开发了tunnel offload的新特性。 接下来,就来详细聊聊我们所做的工作。

Flowtable offload背景简介

Linux内核在版本4.16引入了flow offload功能,它为IP forward提供了基于流的卸载功能。当一条新建连接完成首回合原方向和反方向的报文时,完成路由,Firewall和NAT工作后,在处理反方向首报文的forward hook,根据报文路由、NAT等信息创建可卸载flow到接收网卡ingress hook上。后续的报文可以在接收ingress hook上直接转发,不需要再进入IP stack处理。 这种模式实现了完成建立连接的conntrack软件offload,不过目前flowtable offload只支持TCP和UDP协议的卸载。 

图:Flowtable offload图示 

当前内核中硬件支持offload的标准只有Network TC subsystem的tc flower接口。

_Pablo Neira Ayuso_首先将tc flower相应的offload接口进行公共化为network子系统flow offload,然后在flowtable offload中支持HW的flow offload接口。这样便可在驱动层面上完全统一使用flow offload接口。 

_Paul Blakey_将flowtable offload指定到TC_SETUP_FT域,实现在驱动层来区分不同的subsystem。

 在所有基本功能完善后,我们在review commit的代码后发现flowtable HW offload的建立并没有指定到正确的TC_SETUP_FT类型。对此,我们进行了简单的修复,并将patch提交至社区:

 ① Netfilter:nf_flow_table_offload:Fix block setup as TC_SETUP_FT cmd(https://git.kernel.org/pub/sc...

②Netfilter:nf_flow_table_offload:Fix block_cb tc_setup_type as TC_SETUP_CLSFLOWER(https://git.kernel.org/pub/sc...

Conntrack offload测试优化实践

接着,我们对conntrack offload卸载功能进行了实操测试,发现其中存在部分卸载规则问题,对其进行了修复优化。

|  测试复现

创建一台虚拟机,配置虚拟机地址为10.0.0.75。host创建user1的vrf,将虚拟机对应的VF representor mlx_pf0vf0以及PF mlx_p0加入到user vrf。PF对端连接物理机地址为10.0.1.241。Host作为虚拟机和对端物理机之间的虚拟机路由器。 

创建firewall规则,允许访问虚拟机的icmp和tcp 5001端口,并且把VFrepresentor port和PF port加入到flowtable做offload。 

开启netperf测试,10.0.1.241访问10.0.0.75:5001。发现连接能成功建立,但是后续带宽跑不上来。

|  问题定位

在Host上的确抓不到相应的报文,说明卸载成功,并且在虚拟机中抓包发现收报文的收到和回复的报文都是正确的。但是在对端物理机上抓包却发现dst_mac全为0。 我们猜测应该是卸载规则出现了问题,为验证结论,我们查看相关源码并进行分析:

通过源码可以发现dst_neigh正确获取,但是由于dst_neigh_lookup会为没有neighbor项的地址创建一个新的neighbor,导致值为0。(由于整个测试环境刚部署好,没有进行过任何通信,所以两端的neighbor是没有的) 

仔细分析下offload规则下发的时机,第一个original方向的SYN报文从10.0.1.241->10.0.0.75:5001通过协议栈能转入到虚拟机,虚拟机发出reply方向的SYN+ACK报文10.0.0.75:5001->10.0.1.241,同时在Host的netfilter forward表会建立offload规则下发给硬件。这时链接两个方向的报文都进行了鉴权,conntrack项也变成established,形成完整的转发规则。 

但是reply方向的ip_dst 10.0.1.241的neighbor还是没有,原因在于协议栈上的报文还没真正发送触发arp流程。 

针对上诉分析,由于flowtable offload并不支持icmp协议,我们先进行了ping探测让两端的neighbor项建立成功,然后再继续测试。此时发现,正式化硬件offload可以正常的工作。

|  提交patch:

针对conntrack offload 中neighbor无效导致卸载错误的情况,我们提交patch进行了修复。简单总结为:在获得无效neighbor的时候先不进行卸载:

Netfilter: nf_flow_table_offload: checkthe status of dst_neigh(https://git.kernel.org/pub/sc...

NAT功能测试优化实践

接着,我们继续对flowtableoffload中NAT功能项进行了实操测试,对部分卸载规则问题进行了优化改善。

|  测试复现:  

创建一台虚拟机,配置虚拟机地址为10.0.0.75,具有外部地址2.2.2.11。host创建user1的vrf,将虚拟机对应的VF representor mlx_pf0vf0以及PF mlx_p0加入到user vrf。PF对端连接物理机地址为1.1.1.7。Host就作为虚拟机和对端物理机之间的虚拟nat网关。

同样创建firewall规则,允许访问虚拟机的icmp和tcp 5001端口,并且把VFrepresentor port和PF port加入到flowtable做offload。

接着创建nat转发规则,dst ip address 2.2.2.11 dnat to 10.0.0.75, src ip address 10.0.0.75snat to 2.2.2.11。

开启netperf测试,1.1.1.7访问至2.2.2.11:5001。发现连接能成功建立,但是后续带宽值很低。

|  问题定位:

在Host上的确抓不到相应的报文,说明卸载成功,在虚拟机中抓包发现收报文的dst mac不正确,值同样也为0(测试代码没合入,无效neighbor的时候先不进行卸载的patch)。 

由于original方向的SYN报文1.1.1.7访问2.2.2.11:5001转换成1.1.1.7到10.0.0.75:5001成功发送给了虚拟机,这时10.0.0.75对应的neighbor是存在的,不应该出现获取不到的情况。 

我们猜测应该还是卸载规则出现了问题,查看源码进行分析: 

通过源码可知,在NAT场景下original方向的tuple->dst_cache的device确实是mlx_pf0vf0,但是tuple->dst_v4却仍旧是原来的2.2.2.11,不是10.0.0.75。10.0.0.75应该通过remote_tuple->src_v4获取

解决该问题后,我们再次开启netperf测试,1.1.1.7:32315访问2.2.2.11:5001。发现连接依然能成功建立,但是带宽还是跑不上来。 

在虚拟机上抓包发现接收报文dst port异常为32315。即1.1.1.7: 32315到10.0.0.75: 32315。我们判断卸载规则仍存在其他问题,查看源码进行分析:

可以看到在DNAT场景下会将original方向的dst port改为reply方向的dstport即32315, 将reply方向的dst port改为original方向的source port。这个逻辑明显有误。

同样在SNAT下也存在类似的转换问题, 会将original方向的srcport改为reply方向的dst port, 将reply方向的src port改为original方向的source port。 

举个例子,比如10.0.0.75:32200访问1.1.1.75:5001会将reply的报文改为1.1.1.75: 32200到2.2.2.11:32200。 所以NAT模式下的portmangle存在问题,正确的逻辑应该是: 

  • DNAT: 

original方向的dst port应该改为reply方向的src port;

reply方向的src port应改为original 方向的dst port。 

  • SNAT:

Original方向的src port应该改为reply方向的dstprt;

Reply方向的dst port应该改为original方向的src port。

|  提交patch: 

最终,针对NAT测试问题,我们也提交了相关patch进行修复:

① Netfilter: nf_flow_table_offload: fix incorrect ethernet dst address(https://git.kernel.org/pub/sc...

② Netfilter: nf_flow_table_offload: fix the nat port mangle.(https://git.kernel.org/pub/sc...

新特性开发:SDN网络下的Tunnel offload

我们发现flowtable hardware offload无法支持tunnel设备。对于SDN网络而言,tunnel是一项关键性的指标。 最终,我们从conntrack offload与NAT功能的优化修复过程中得到启发,在新思考的推动下,与 Netfilter 维护者Pablo NeiraAyuso 和 Mellanox 驱动工程师Paul Blakey通力合作,共同开发出了tunnel 卸载的新特性。 

以下是开发细节的详细介绍。 

1、在Flowtable上设置tunnel device实现卸载 

在tc flower softwarefilter规则中, 所有的tunnel meta match、tunnel decap action均设置在tunnel device的ingress qdisc上,只有在tunnel device 接收入口才能获取meta信息。 

因此tc flower offload模式下的卸载规则也会follow这个逻辑,下发到tunnel device上。但是tunnel device都是虚拟的逻辑device,需要找到lower hardware device进行设置卸载——即采用indirect block的方式来实现。 

首先驱动程序注册监听tunnel创建的事件。当tunnel被创建,驱动会给对应tunnel device设置一个tc flower规则的callback。通过这种indirect block的方式来实现tunnel device与hardware device的关联。

|  提交patch: 

我们先提交了series(http://patchwork.ozlabs.org/c... )——在flow offload 中支持indirect block方式,主要包括以下patch:

① cls_api:modify the tc_indr_block_ing_cmd parameters.

② cls_api:remove the tcf_block cache

③ cls_api:add flow_indr_block_call function

④ flow_offload:move tc indirect block to flow offload

⑤ flow_offload:support get multi-subsystem block

 引入上面的series后,flowtable就能通过indirect block卸载tunnel device。

①Netfilter: flowtable: addnf_flow_table_block_offload_init()(https://git.kernel.org/pub/sc...

②Netfilter: flowtable: addindr block setup support(https://git.kernel.org/pub/sc...) 

2、Tunnel 信息匹配及Action 设计 

完成第一步后,flowtable便可以成功的将卸载规则设置到tunnel device上,但是此时还存在一个问题:无法支持tunnel信息匹配以及decap、encap操作。 

针对这一问题,首先我们想到Linux内核在4.3版本中引入的轻量级隧道Lightweight tunneling,它提供了通过route方式设置tunnel属性的方法:创建隧道设备时指定external模式,利用路由设置的轻量级隧道通过tun设备发送报文。

Flowtable规则设置也是完全基于route信息去完成,沿着这一思路:tunnel信息也可以通过route信息获取。

|  提交patch:

我们提交了flowtable中tunnelmatch和encap/decap action的offloadpatches:

①Netfilter: flowtable: add tunnel match offload support(https://git.kernel.org/pub/sc...

②Netfilter: flowtable: add tunnel encap/decap actionoffload support(https://git.kernel.org/pub/sc...

3、Mlx5e在TC_SETUP_FT中支持Indirect block 

接着,我们又发现了第3个问题:mlx5e驱动中flowtable offload的规则被指定到TC_SETUP_FT域中,但该驱动中并不支持indirect block

|  提交patch: 

发现这一点后,我们向社区提交了patch实现该功能的完善:

① net/mlx5e:refactor indr setup block(https://git.kernel.org/pub/sc...

②net/mlx5e:add mlx5e_rep_indr_setup_ft_cb support(https://git.kernel.org/pub/sc...) 

4、Tunnel offload 功能验证 

完成上述开发步骤后,我们也按照前文的测试思路进行了功能验证,确认功能的完善与准确性。 

|  测试验证: 

创建一台虚拟机,配置虚拟机地址为10.0.0.75,具有外部地址2.2.2.11。host创建user1的vrf,创建key 1000的gretap tunnel device tun1。将虚拟机对应的VF representor mlx_pf0vf0和tun1加入到user1 vrf。PF mlx_p0配置underlay地址172.168.152.75/24。PF对端连接物理机网卡配置地址172.168.152.208/24, 创建gretap tunnel tun,  tun设备的remote为172.168.152.75,key为1000,设置地址为1.1.1.7。 首先,虚拟机与对端物理机tun设备通过tunnel相互访问:

接着,创建firewall规则,允许访问虚拟机的icmp和tcp 5001端口,并且把VF representor port和tun 1隧道设备加入到flowtable做offload。 最后,创建NAT转发规则:dst ip address 2.2.2.11 dnat to 10.0.0.75、src ip address 10.0.0.75 snat to 2.2.2.11。

测试后最终确认各个功能完整正常,至此,我们实现了SDN网络下tunnel offload卸载的能力。

写在最后

以上是本项目涉及的部分核心问题,我们把这期间贡献的patch整理成了一份列表,希望能为开发者提供帮助,读者可以点击“阅读原文”阅览完整patch list。 

Flow Offload开源技术为行业内带来了革命性的思路,但在技术的更新迭代过程中,一些新特性在实际应用上也会存在稳定性、兼容性等方面的问题。作为开源技术的同行者,UCloud一直积极探索、丰富开源技术功能,帮助提高开源技术稳定性。

作者简介:文旭,UCloud虚拟网络平台研发工程师,Linux kernel network 活跃开发者,Netfilter flowtable offload 稳定维护者 

查看原文

赞 3 收藏 1 评论 0

认证与成就

  • 获得 12 次点赞
  • 获得 0 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 0 枚铜徽章

擅长技能
编辑

(゚∀゚ )
暂时没有

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2013-01-24
个人主页被 719 人浏览