UCloud云计算

UCloud云计算 查看完整档案

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

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

个人动态

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

VMware业务系统迁移上云方案

背景

客户要将业务从自建的虚拟化数据中心迁移至UCloud,希望能够将多年前的VMware体系换到公有云体系。其中:

  • 客户希望上云过程不影响到现有业务;
  • 去除机房托管的过保设备,减少不必要的支出;
  • 减少资源的维护人力和运维压力;

另外,希望迁移过程不要太长,不要影响市场推广等工作及业务创新。

一、迁移评估

经过可行性分析,至少存在以下挑战:

  1. 客户的操作系统类型较多且版本老旧,其中大多是windows Server版本。
  2. 业务系统无法重建,原因是软件没有部署指导文档及源码,或找不到可以重新部署的人员。
  3. 数据迁移量较大,其中数据库及备份数据较大。
  4. 客户使用的商业软件版本过老、未购买授权等原因,导致客户无法或不想重建业务系统,例如购买的第三方商业版全套系统软件,如SAP、ERP等。

基于以上原因,无法使用现成的工具,因为迁移工具对主流操作系统(CentOS、Ubuntu)支持较好,但是比较老的系统,由于新的硬件驱动缺乏厂商支持原因,导致无法使用。

因此,只能通过镜像方式迁移。

二、迁移方案

基于上述背景及迁移评估,整体迁移思路基本是2个方向:

  1. 公网传输

前置条件是:

  1. 公网带宽足够大,且不影响现有生产业务;
  2. 数据敏感性不高,允许公网传输;
  3. 数据量不太大,最好不超过10T级;

2、线下磁盘拷贝

对于数据量太大、公网带宽不够大、因安全因素不方便公网传输等,是公网在线传输做不到的,可以体现线下磁盘拷贝的优势。

这里使用U闪盘(可以理解为AWS的snowball、阿里的闪电立方)来做镜像的传输。主要有以下优势:

  1. 数据安全性高、空间大:做了raid5的大容量空间,对于数据的安全性有保障。
  2. 传输速度快:接口支持USB3.0,速度最大支持500MB/s,存储介质读写速度在150MB/s左右。
  3. 可挂载物理服务器:托管区物理机与公有云区内网互通,且与公有云US3服务内网连通,如需将大量机房外的数据拷贝到机房内,可通过这种方式进行数据传输。

为了简化步骤,减少中间态等待时间,且为了缩短单个迁移过程时间,采用异步操作,减少同步操作带来的等待时间。

在此例中,由于数据太大,为加快迁移速度,因此选择了方案2,线下磁盘迁移方式。

三、迁移详情

迁移流程图如下:

首先需要:

  • 关闭Guest系统的Windows组策略;
  • 卸载Guest系统的VMware-Tool工具;
  • 关闭防病毒软件;
  • 关闭虚拟机。

上述流程中需提前创建物理云服务器,通过U闪盘进行系统盘和数据盘镜像的传输,将存储好数据的U闪盘挂载到物理云服务器,同时在物理云主机内完成系统盘镜像的格式转换和驱动的注入过程。

在物理云主机内通过内部API,创建临时中转机器,并创建具有系统盘属性的云盘,把挂载的U闪盘当作本地盘,通过qemu-nbd,将U闪盘的系统盘和数据盘分别远程挂载到创建的中转机的两块云盘上(系统盘与数据盘)。

将临时创建的中转机绑定的两块云盘卸载下来,通过系统盘创建云主机(该过程需要内部API来实现),将另一块磁盘当作数据盘挂载,完成对云主机系统盘数据盘的迁移。

3.1IDC中VMware环境准备

1.vSphere客户端连接vCenter服务器

安装vsphere客户端,远程连接到IDC中VMware的管理节点vCenter,其将对应克隆出的镜像传输到U闪盘中保存。

2.导出镜像

对于关机离线的系统,可以直接导出OVF或者VMDK格式的镜像;对于未能离线导出的系统,可进行镜像克隆,克隆后的格式为VMDK。

3.2中转服务器环境准备

①安装KVM虚拟化环境

安装CentOS 7操作系统,并确保支持开启硬件虚拟化功能;确保磁盘空间不少于迁移数据量。安装KVM虚拟化,执行命令如下:

# yum install qemu-kvm qemu-key-tools libvirt  qemu-img
# yum install virt-*
# modprobe kvm
# modprobe kvm_intel
# systemctl start libvirtd
# systemctl enable libvirtd.service

②安装virt-v2v

考虑到兼容云服务商的兼容性问题(例如IO及网络的加速,系统的高内核版本),针对老旧的系统,如:Windows 2000,Windows Server 2003,Windows Server 2008等,需要用virt-v2v转换。

对于IO加速,通过virt-v2v自动注入VirtIO驱动来解决,可以把虚拟机从一个虚拟平台导入到另外一个虚拟平台,使用 virt-v2v 命令将其它虚拟机监控程序(hypervisor)上运行的虚拟机进行转换,从而可以在 Red Hat Enterprise Virtualization 或由 libvirt 管理的 KVM 上运行。当前,virt-v2v 可以转换在 Xen、KVM 和 VMWare ESX / ESX(i) 上运行的 Red Hat Enterprise Linux 虚拟机和 Windows 虚拟机。在需要的情况下,virt-v2v 会在被转换的虚拟机上启用准虚拟化(VirtIO)驱动。

virt-v2v将外部的虚拟化平台上的虚拟机转化到可以运行的KVM平台上。它可以读取运行在VMware、Xen、Hyper-V和其他虚拟机管理程序上的Windows和Linux的虚拟机,并将其转换为KVM的libvirt,OpenStack,oVirt,红帽虚拟化(RHV)等几种方式。

# yum install virt-v2v

③宿主机上安装VirtIO驱动

Virtio驱动程序是KVM虚拟机的半虚拟化设备驱动程序,半虚拟化驱动程序可提高机器性能,减少I / O延迟并将吞吐量提高到接近裸机水平。安装Windows的VirtIO驱动如下:

# yum install libguestfs-winsupport libguestfs-tools
# wget https://fedorapeople.org/groups/virt/VirtIO-win/VirtIO-win.repo
-O /etc/yum.repos.d/VirtIO-win.repo
# yum install VirtIO-win

④安装ntfs-3g,用于挂载U闪盘

NTFS-3G支持在Linux, FreeBSD, Mac OS X, NetBSD, Haiku等操作系统下读写NTFS格式的分区。除了完全的文件属主和访问权限,它支持所有符合POSIX标准的磁盘操作。目的是为那些用户需要与NTFS可靠互通的硬件平台和操作系统提供可信任的、功能丰富的高性能方案。

# yum install epel-release
# yum install ntfs*

⑤编译安装NDB

安装NBD可被用来进行远程存储和备份,NBD的驱动程序在本地客户端模拟了一个块设备,比如一个磁盘或者是一块磁盘分区,但实际提供物理支持的却是通过网络连接的远程服务器。

3.3镜像格式转换与VirtIO驱动注入

转换磁盘文件并注入VirtIO驱动程序,执行命令如下:

# export LIBGUESTFS_BACKEND=direct
# virt-v2v -i vmx server2003.vmx -of qcow2 -o qemu -os ./
// 注:执行命令virt-v2v -i vmx “vmx文件名” –of qcow2 –o qemu –os “转换后磁盘文件存放路径”,默认是把系统盘与数据盘都进行转换,为了节省转换时间,可以修改vmx文件只进行系统盘的转换。

3.4通过API创建中转系统盘及数据盘

通过API创建新的云盘,作为用来开启云主机的系统盘,以及用来导入数据的数据盘(_其中系统属性的磁盘为内部API_)。新创建的两块云盘均为临时中转盘,用来存储导入镜像的系统以及数据。

具体的API可参考:https://github.com/ucloud

3.5远程挂载云盘与磁盘拷贝

为减少迁移耗时的流程,将U闪盘的系统盘和数据盘以网络的形式直接挂载到新创建的VM上,然后将U闪盘内的数据与临时中转机创建的云盘实现内网的磁盘数据拷贝。鉴于磁盘IO和网络带宽的限制,上述方案可省去公网传输和对象存储US3存储镜像的中转过程。

具体过程如下:使用qemu-nbd的远程磁盘挂载,将U闪盘的数据盘,直接挂载到云盘上。然后将云盘卸载,挂载到对应的客户机器上去。

①在物理云服务器上将U闪盘的磁盘镜像挂载到nbd的特定端口

# qemu-nbd -r -t -v -f qcow2 -p 5000 web-sdc.qcow2
// 注:5000为端口号,web-sdc为数据盘镜像。

②在中转机上安装qemu-img,将远程的数据盘镜像挂载到新创建的云硬盘。

# qemu-img convert nbd://10.23.xx.xx:5000 /dev/vdc
// 注:10.23.xx.xx为物理服务器内网IP地址,/dev/vdc为新创建的云盘。

3.6创建云主机并挂载数据盘

对于已经同步过数据的系统盘与数据盘,通过API对系统盘进行云主机的创建;对于云数据盘,需要先将中转机上的云盘进行卸载,然后挂载到需要开启的目标云主机上,从而达到云主机的创建与数据盘的挂载功能。UCloud有自动化的脚本及程序来实现以上过程。

四、经验

通过本次迁移,确认可以支持和限制因素如下,供参考。

4.1支持

对于VMware,此迁移支持以下环境:

  1. 支持vSphere、ESXI。
  2. 支持系统盘和数据盘迁移。
  3. 支持操作系统RHEL 3-7,Centos 3-7,Ubuntu 10.04,12.04,14.04,16.04以上,Windows XP-Windows 10/ Windows Server2016。

4.2限制

  1. VMware Workstation创建的主机迁移存在失败风险。
  2. Windows 7 和Windows Server 2008 R2需要开启支持SHA-2证书。
  3. 需要关闭操作系统迁移,不支持在线热迁。
  4. 需要卸载防病毒软件。
  5. 需要卸载虚拟化平台工具。

本文来自UCloud华东架构中心,如有相关需求或业务咨询,欢迎私信联系或评论区留言!

查看原文

赞 0 收藏 0 评论 0

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

UCloud电子核验版备案系统已上线,彻底告别幕布时代附备案界面图示

千呼万唤始出来,电子核验版备案系统上线啦!

UCloud电子核验版备案系统已上线,新系统人像采集通过手机微信扫码实现,替换以往人像采集使用幕布方式。在UCloud云平台上的备案审核时间缩短至1个工作日。UCloud备案入口:https://console.ucloud.cn/icp/ ,按控制台提示操作即可。

备案总流程图

备案界面示意

1.主体信息填写页

2.网站信息填写完成后,展示页

3.人像采集页(该页面替代了幕布环节)

4.手机微信扫码,人像采集

5.手机扫码成功,PC页面

6.提交订单

是不是非常easy?!简单操作,备案办妥!

有任何疑问,欢迎咨询或留言~~

查看原文

赞 0 收藏 0 评论 0

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

全面提升企业的主动防御能力,UCloud全新架构云安全中心正式公测!

近年来,全球范围内频发安全事件,我国对网络安全也愈发重视相继出台多部网络安全相关法律,网络安全在今天越发被重视,各类企事业单位不断加大安全投入,市场中更是应运而生了多款安全产品,但安全产品之间普遍存在数据相互独立,无法关联分析的问题,让安全团队的运维能力疲于应对,且管理层无法感知到巨大的安全投入带来的收益效果。面对新的安全形势,传统安全体系遭遇瓶颈,需要进一步提升安全运营水平的同时,迫切需要开展主动防御能力的建设。

近日,UCloud基于云安全底层的打磨整合,重磅推出了全新架构的云安全中心USC(UCloud Security Center)。UCloud云安全中心将通过检测发现服务的漏洞、风险、木马、攻击,以提供安全防御的专业建议和合规检测等安全能力,帮助用户实现业务资产可视化展示、风险检测、威胁识别三位一体的自动化安全运营系统,满足监管合规要求,保护用户资产。

全新架构打造“自动化、统一安全管控平台”

1.安全威胁早发现


UCloud云安全中心通过对采集的数据和业界安全情况进行对比综合分析,得出用户资产的威胁信息并统一进行展示。支持对资产安全威胁定时进行检查,安全威胁包括主机漏洞、系统基线风险、应用基线风险、web基线风险和用户开放到外网的端口信息,支持用户自定义高危端口的范围和自动化安全监控,从而做到对资产中的安全威胁早发现早解决,避免被利用造成进一步入侵伤害。

2.安全事件早处理

UCloud云安全中心可通过定时检测对用户遭受的安全攻击行为进行采集、监控和分析后进行汇总展示,并及时报告给用户进行处理。安全事件通常会对用户资产造成实质性的安全威胁,其中安全事件主要包括网络DDoS攻击、木马、web流量攻击以及异常的主机登录事件等。

3.专业安全防护建议


UCloud云安全中心通过将专业的安全防御体系规则化,结合用户受到的攻击和威胁情况、资产的实际情况,对用户目前防御体系中已经存在的安全防护情况进行展示,并提出用户缺乏的安全防御手段,最大限度保障用户的云安全。

4.多业务自动化分组

UCloud云安全中心通过在用户主机上部署agent,以自动化的方式或者用户自主选择的方式建立某业务,并根据服务内的真实连接情况画出该业务进程级别的访问关系拓扑图,通过指定规则、大数据分析,实现拓扑内服务按照集群、功能等维度进一步实现精细化、可视化的分组。

当业务由于扩容需要增加新的资产时,云安全中心可以自动化检测并添加到拓扑中,从而实现完全贴合实际业务的服务级别资源管理,并实现了创新型的拓扑图展示方式,支持按照业务分组进行安全管理,相比于以往的列表形式更具有可观性和用户对安全的把控能力更强。

5.等保一体化检测

中国经过多年安全建设,目前进行安全等保认证是每个企业的责任和业务,但等保条目的安全专业性较高,对于企业运维来说,具体应该如何通过等保认证成为一项难题。UCloud云安全中心通过专业安全人士对等保条目细化到具体云资产,然后实现对用户各项云资产的自动化检测,具体指出等保每一项条目的云资产满足情况,并针对不满足情况给出具体资产的安全建议,保障用户无需专业安全人员也可全程自主化完成等保的前期自我审核工作。

一站式解决企业安全运维三大痛点

1.安全运维门槛高

近些年我国相继出台的多部网络安全法律法规专业度要求较高,企业的普通安全和运维人员通过人工排查的方法不但耗费大量精力而且实际效果大打折扣。企业不得不招聘更多专业的安全人员去满足要求,增加了企业的运营成本,并且分析耗费时间越长,系统中威胁存在的时间更久,那企业遭受侵害的可能性就越大。

云安全中心提供一站式自动化安全检测来满足安管要求:

2.安全管理权限难统一

在实际场景中,由于权限管控原因,安全人员一般无机器的管理权限,这对安全运维人员把控整个公司安全情况造成了不小的难度。云安全中心只需要部署agent,便可实现对所有资产的安全管理。

3.资产变化难运维

现在企业一般为多业务发展,安全运维人员往往对具体业务了解不深入,导致安全管理上举步维艰。云安全中心可以帮助公司实现分业务管理,帮助企业更精确的画出各业务的服务交互和安全情况,云安全中心支持通过指定入口方式自动化生成业务资产拓扑,无需业务人员告知,安全运维也可监控各业务的资产变化情况和资产安全情况,降低人员交接工作的复杂性、减少安全管理的成本、降低运维门槛、提高企业安全性。

随着云服务的快速发展,企业的云资产类型将更加趋向多元化,潜在的安全威胁、安全攻击事件也层出不穷,如何帮助企业实现集安全预防、威胁检测、主动防御于一体的云资产自动化安全管理是UCloud云安全中心USC产品上线的初衷。未来,USC 产品将进一步优化升级,将技术功能、安全与流程相结合,为用户提供威胁情报、SOAR、微隔离,多云管理等功能,实现自动化地进行事件分析、分类过程和实战化、有效化的安全运营,不断降低企业安全运维管理的门槛和企业的云资产被入侵威胁的风险,敬请期待!

查看原文

赞 0 收藏 0 评论 0

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

UCloud全球大促:全球31个数据中心29条专线官方补贴1折起!云服务器超值特惠898元/年!

开卖!特价!福利开启!

活动时间:即日起至2021年3月31日

活动入口:https://www.ucloud.cn/site/active/kuaijie.html

接下来就是官方全解读,别眨眼,盯紧看,别错过任何你需要的云服务~~~

UCloud全球大促云服务器促销

UCloud全球大促云服务器促销分新用户促销和新老用户促销,前者限购1台,后者限购10台。新用户区分个人和企业,当然配置相同可能价格企业更便宜些。老刘博客这里特别推荐企业新客户北上广机房4核8G内存5M带宽首年898元,个人新客户同此配置首年956元。促销的数据中心包括中国、亚太、美洲、欧洲和非洲地区,具体机房在北京、上海、广州、香港、台北、东京、胡志明市、新加坡、首尔、曼谷、雅加达、马尼拉、孟买、华盛顿、洛杉矶、圣保罗、莫斯科、法兰克福、伦敦、拉各斯(西非尼日利亚)和迪拜。前往活动页>>

注意以上促销均为固定带宽不限流量云服务器,如果需要流量计费/更高带宽/其他配置,多台月付、年付折扣或机柜托管服务,客户联系客服或你的客户经理。在线咨询

专业机构测评:Cloudbest(Intel快杰型云服务器): 测试报告主要针对8核16G配置下,四家云厂商的对比分析。快杰型云服务器在测试中,各项结果均表现突出;在性价比排行上,UCloud占据此次评测第一位。测评详情

UCloud全球大促全球必备云产品特惠

UCloud全球大促云服务器促销模块选择中国地区时,活动页面会展示出必备云产品特惠专题。

UCloud全球大促全球必备云产品特惠专题下域名、SSL证书、云数据库、云内存、CDN、PathX、高防、UWAF普惠大促,新老用户均可购买,各产品限购1次。值得一提的是.com域名注册首年仅20元,.cn域名注册首年仅10元,付费SSL证书仅30元一年,100G国内CDN流量包仅1元(不限时长使用)。前往活动页>>

UCloud全球大促全球网络产品特惠

UCloud全球大促云服务器促销模块选择非中国地区,如亚太地区、美洲地区等海外地区时,页面下会展示全球网络产品特惠专题促销:

UCloud全球大促全球网络产品特惠专题下精选了全球网络加速服务,有效提升跨国、跨洲网络稳定性,各产品特惠限购1次。同时可以扫码进⼊全球网络加速交流群,了解更多网络加速产品。前往活动页>>

GlobalSSH

SSH登陆场景、linux/Window适用GlobalSSH:提高跨国远程管理服务器效率,解决由于跨国网络不稳定导致的远程管理出现的卡顿、连接失败、传输速度较慢等现象。前往活动页>>

全球动态加速PathX

全球动态加速PathX支持非UCloud服务器加速、1分钟部署:提供弹性、稳定、易用、多种协议的全球网络加速产品,提升App/网站的全球访问质量,规避跨国网络拥塞导致的响应慢、丢包等问题。单用户仅能领取一次代金券。前往活动页>>

高速通道UDPN

安全稳定、跨域内网加速:通过UCloud的自建专线,提供各个数据中心之间的,低延迟、高质量的内网数据传输服务,享受低延迟跨域访问。单用户仅能领取一次代金券。前往活动页>>

此外,活动页上设置了UCloud出海白皮书下载入口,注册UCloud账号,即可免费下载《2021最新出海白皮书》,前往活动页>>

UCloud全球大促U大使推荐返利

成为U大使,推广得返利:推荐新用户使用UCloud,最高30%现金奖励。加入UCloud U大使,推广越多,返利越多。需要注意的是以往UCloud的CDN产品是不参与推荐返利的,现在返利规则改版,将CDN流量包预付费增加到返利产品行列中,老刘注意到云计算商家里基本没有针对CDN的常规性返利策略,UCloud首开先河!立即申请成为U大使加入推广>>

UCloud全球大促更多优惠专场

更多云产品特惠请前往分会场查看:

CDN特惠专场,优质自建节点,流量包0.09元/GB起立即前往

云安全专场,高防服务6折起,多个产品免费试用,一站式等保2.0测评服务省心省力立即前往

大数据专场,大数据产品免费试用1个月,优惠大促5折起立即前往

UCloud用户社区积分奖励

UCloud在去年底就悄悄推出了自家的社区站点:UCloud用户社区,只是没有大范围推广,这里UCloud在全球大促活动页贴出社区,如果用户对他们产品和全球大促有疑问的,可以直接在他们社区发帖询问。社区支持自行注册账号、微信、GitHub账号或UCloud官网账号登录,且设置了积分获取渠道,一定积分可以兑换UCloud账号赠金、产品代金券及周边礼品,老刘一个月内已经用积攒的社区积分兑换了差不多300元赠金,妥妥买了好几个域名~。立即前往

UCloud用户社区首页

一年一次的福利别错过,各位UCloud的粉丝儿们,买它!买它!买它!

查看原文

赞 0 收藏 0 评论 0

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

基于Segment Routing技术构建新一代骨干网:智能、可靠、可调度(二)

在上篇《基于Segment Routing技术构建新一代骨干网:智能、可靠、可调度(一)》中提到了UCloud数据中心野蛮式增长给MAN网络和骨干网带来了极大挑战以及UCloud骨干网1.0、2.0的演进路线、SR技术部分原理介绍。本文将重点介绍UCloud如何通过Segment Routing技术改进控制面和转发面,实现智能、可靠、可调度的新一代骨干网。

新一代骨干网架构

设计目标:

  • 控制器智能计算路径和头端自动计算路径:控制器实时收集转发设备状态信息,响应转发节点路径计算请求和路径下发。
  • 全场景接入,实现灵活组网:支持用户本地专线、互联网线路混合接入方式,实现用户灵活组网。
  • 多维度SLA路径规划:满足多业务不同路径转发需求,确保关键业务的优先级和服务质量。
  • 降低专线成本,提高整体专线利用率:废除骨干网2.0中的VXLAN技术,缩减包头开销,降低专线成本;通过智能流量调度合理规划专线容量。
  • 流量可视化,按需调度:通过telemetry和netflow技术实现骨干网流量可视化,针对部分“热点流量”和“噪声流量”进行按需调度。

整体架构如下

新一代骨干网主要包括三大组件:智能控制器、骨干边界转发PE、接入侧转发CPE&VPE:

控制器:对全网转发PE、CPE、VPE等设备进行统一的资源管理、信息收集、配置下发,监控告警以及路径计算规划,实现全网资源的统一调度和管理。

骨干网边界:全网PE和RR组成SR-TE骨干网核心层,用于实现多路径转发,流量调度;骨干网边界对外主要接入CPE、M-Core、VPE&VCPE等设备。

接入侧边界:接入侧分为三种设备类型:CPE、M-Core、VPE&VCPE。

CPE:主要用于接入本地专线客户;

M-Core:公有云MAN网络核心,实现各城域网接入骨干网;

VPE:通过Internet或者4G/5G网络接入用户分支机构的VCPE设备,提供用户混合组网能力。

近年来,云数据中心SDN网络设计思路大行其道,其主要思想是转控分离,转控分离好处不用多说,当然也有其弊端;SDN数据中心网络中的控制面故障有太多血的教训,控制面故障带来的转发面影响也是重大的;毕竟转发面才是真正承载客户业务的地方,所以我们在设计新一代骨干网时需要考虑控制器故障时,如何保持转发层面的独立可用性。

接下来将介绍基于SR技术骨干网的控制面和转发面的设计实现原理。

控制面设计

新一代骨干网的控制面主要包括两个方面:

一、智能控制器;

二、 SR-TE骨干网路由设计控制面。

01、智能控制器

控制器的主要架构设计如下:

整个控制器的目标为实现一致的配置下发与可扩展的调度策略。基于设备全球部署的特点以及网络并非百分之百稳定的前提,该系统采用了数据层跨地域部署,同时为了兼顾正常情况下控制器的快速响应,控制节点采用了分机房的集群部署方式来保证业务的可靠性与高效的调度能力;上层控制系统通过BGP-LS、Telemetry技术采集转发链路状态信息,收集到数据库,之后对采集到的数据进行分析处理,最后通过netconf和PCEP方式下发配置和智能计算路径。

其中数据采集主要包括:

  • 基本的IGP拓扑信息(节点、链路、IGP度量值)
  • BGP EPE(Egress peer Engineering)信息
  • SR信息(SRGB、Prefix-SID、Adj-SID、Anycast-SID等)
  • TE链路属性(TE度量、链路延迟度量、颜色亲和属性等)
  • SR Policy信息(头端、端点、颜色、Segment列表、BSID等)

Netconf和PCEP主要用于配置下发和路径计算:

  • 头端向控制器请求路径计算;控制器针对收到路径计算请求进行路径计算
  • 头端从控制器学到路径,控制器通过PCEP向头端传递路径信息
  • 头端向控制器报告其本地的SR Policy

实现能力如下:

  • 快速的故障响应:由于内部自定义的算法需求,在线路或者节点出现问题时,需要重新计算整张拓扑,以避开故障链路;
  • 快速实现手动故障域隔离:借助架构的优势,实现所有流量在线路级别与节点级别的隔离;
  • 快速自定义调优路径:可以根据客户的需求快速将客户流量引导到任意路径上,保证客户各类路径需求;
  • 客户流量秒级实时监控:可监控流级别的客户故障,并实现故障情况下的路径保护;

02、SR-TE骨干网控制面

为了实现用户L2和L3接入场景需求,在骨干网规划设计了基于MP-BGP的L3VPN和BGP-EVPN的L2VPN,下面来做一个简单的介绍。

MP-BGP

新一代基于SR技术的骨干网采用了MPLS-VPN的技术特性,大致需要如下组件:

  • 首先需要在MPLS VPN Backbone内采用一个IGP(IS-IS)来打通核心骨干网络的内部路由;
  • PE上创建VRF实例,与不同的VRF客户对接,VPN实例关联RD及RT值,并且将相应的端口添加到对应的VRF实例;
  • PE上基于VRF实例运行PE-CPE&VPE、M-Core间的路由协议,从CPE&VPE、M-Core学习到站点内的VRF路由;
  • PE与RR之间,建立MP-IBGP连接,PE将自己从CE处学习到的路由导入到MP-IBGP形成VPNv4的前缀并传递给对端PE,并且也将对端PE发送过来的VPNv4前缀导入到本地相应的VRF实例中;
  • 为了让数据能够穿越MPLS VPN Backbone,所有的核心PE激活MPLS及SR功能。

在传统的MPLS-VPN技术的基础上,摒弃LDP,启用SR功能来分配公网标签,内层标签继续由运行MP-BGP协议的PE设备来分配。

BGP-EVPN

在MPLS网络中实现用户L2场景的接入需求,有很多解决方案比如VPLS,但是传统的VPLS还是有很多问题,比如:不提供 All-Active 双归接入,PE流量泛洪可能导致环路风险以及重复数据帧。

为了解决VPLS的问题,我们在新一代骨干网架构中采用了BGP-EVPN协议作为L2网络的控制面;EVPN网络和BGP/MPLS IP VPN的网络结构相似,为了实现各个站点(Site)之间的互通,骨干网上的PE设备建立EVPN实例并接入各个站点的CE设备,同时各个PE之间建立EVPN邻居关系;由于EVPN网络与BGP/MPLS IP VPN网络的不同之处在于各个站点内是二层网络,因此PE从各个CE学习到的是MAC地址而不是路由,PE通过EVPN特有的路由类型将自己从CE学习到MAC地址转发到其它Site。

BGP-EVPN有三个比较重要的概念:

1、EVPN Instance (EVI) :EVPN是一种虚拟私有网络,在一套物理设备上可以有多个同时存在的EVPN实例,每个实例独立存在。每个EVI连接了一组或者多组用户网络,构成一个或者多个跨地域的二层网络。

2、Ethernet Segment(ESI):EVPN技术为PE与某一CE的连接定义唯一的标识ESI(Ethernet Segment Identifier),连接同一CE的多个PE上的ESI值是相同,连接不同CE的ESI值不同。PE之间进行路由传播时,路由中会携带ESI值使PE间可以感知到连接同一CE的其它PE设备。

3、ET(EthernetTag):每个EVI可以构成一个或者多个二层网络。当EVI包含了多个二层网络时,通过Ethernet Tag来区分这些二层网络。如果我们把二层网络看成是广播域的话(Broadcast Domain),那么ET就是用来区分不同广播域的。

为了不同站点之间可以相互学习对方的MAC信息,因此EVPN在BGP协议的基础上定义了一种新的NLRI(Network Layer Reachability Information,网络层可达信息),被称为EVPN NLRI。EVPN NLRI中包含如下几种常用的EVPN路由类型:

相比较VPLS,EVPN的优势如下:

1、集成 L2 和 L3 VPN服务;

2、 类似L3VPN的原理和可扩展性和控制性;

3、支持双归接入,解决容灾和ECMP问题;

4、 可选择 MPLS,VXLAN作为数据平面;

5、对等PE自动发现, 冗余组自动感应。

BGP-LS

BGP-LS用于收集转发设备的链路状态信息以及标签信息,具体规划如下:

1、所有PE和RR建立BGP-LS邻居,PE将各自的链路信息、标签信息以及SR Policy状态传递给RR;

2、RR与控制器建立BGP-LS邻居,将IGP的链路状态信息转换后上报控制器。

转发面设计

01、骨干网核心层

骨干网PE设备之间运行ISIS-L2,并开启SR功能,规划Node-SID、Adj-SID、Anycast-SID;PE基于环回口与RR建立MP-IBGP邻居关系,传递各站点VPNv4路由,实现L3VPN用户业务转发;同时PE采用BGP EVPN作为Overlay路由协议,基于环回口地址建立域内BGP EVPN 邻居关系,采用SR-TE隧道封装用户二层数据,实现L2VPN用户业务通过SR-TE转发。

一般分为SR-BE和SR-TE:

SR-BE由两层标签组成:内层标签为标识用户的VPN标签,外层标签为SR分配的公网标签;

SR-TE由多层标签组成:内层标签为标识用户的VPN标签,外层标签为SR-TE标签,一般由设备头端计算或者通过控制器下发的标签栈;

L2用户通过查找MAC/IP route来实现标签封装,L3用户通过查找VRF中的私网路由来实现标签封装。

02、骨干网边界层

骨干网PE与CPE&VPE以及公有云的M-Core运行EBGP收发用户路由,通过BGP实现数据转发;CPE和VPE与接入用户CE以及VCPE运行EBGP;特别需要注意的是VPE与VCPE是通过Internet建立的BGP,所以需要通过IPsec协议进行数据加密。

介绍完整个骨干网的架构设计后,我们将分别针对骨干网的智能、可靠、可调度三大特性进行剖析。

新一代骨干网三大特性

01、智能

  • 控制器统一编排业务场景

1、分支网络设备自动化部署,实现控制器自动计算路径和流量统一调度以及业务编排;

2、控制器通过BGP-LS等收集网络拓扑、SR-TE信息以及SR Policy信息,并根据业务需求进行路径计算,然后通过BGP-SR-TE/PCEP等协议将SR Policy下发到头端节点。

  • 头端自动算路和自动引流:

1、分布式控制面,防止控制器故障带来的整网瘫痪影响,支持头端自动引流,废除复杂的策略引流机制;

2、头端节点利用IGP携带的SR-TE信息和IGP链路状态信息、SR标签信息等组成SR-TE数据库,然后基于CSPF算法按照Cost、带宽、时延、SRLG和不相交路径等约束条件计算满足条件的路径,并安装相应的SR Policy指导数据包转发。

  • 基于业务场景对网络灵活切片:

根据业务的SLA要求,可以规划新的网络转发平面,可以将时延敏感型的业务调度到基于延迟切片的网络转发平面。

如下为现网当前规划的两个网络切片转发平面:

  • 毫秒级拓扑收敛、链路重算、路径下发:线路故障场景下控制器可以做到毫秒级的拓扑收敛、故障链路重算以及备份路径下发;
  • 流级别路径展示:实现基于数据流级别的路径查询和展示。

02、可靠

  • 全球核心节点专线组网:节点之间提供运营商级的专线资源,SLA可达99.99%;
  • 双PE节点 Anycast-SID保护:地域级的双PE配置Anycast-SID标签,实现路径的ECMP和快速容灾收敛;
  • Ti-LFA无环路径保护:100%覆盖故障场景,50ms内完成备份路径切换;
  • SR-TE主备路径保护:SR-TE路径中规划主备Segment-List,实现路径转发高可用;
  • SR-TE路径快速逃生:SR-TE故障场景下可以一键切换到SR-BE转发路径(IGP最短路径转发);
  • Internet级骨干网备份:为了保障新一代骨干网的高可靠性,在每个地域的PE设备旁路上两台公网路由器,规划了一张1:1的Internet骨干网,当某地域专线故障时可以自动切换到Internet线路上;同时使用Flex-Algo技术基于Internet级骨干网规划出一张公网转发平面用于日常管理流量引流。

03、可调度

  • 根据五元组,识别并定义应用,支持Per-destination、Per-Flow调度;
  • 跨域之间根据应用业务分类定义多条不同类型SR-TE隧道;
  • 每种类型隧道定义主备路径,支持SR-TE一键逃生;
  • 通过灵活算法定义Delay、带宽、TCO(链路成本)、公网隧道等多种网络切片平面;
  • 智能控制器支持自动下发、自动计算、自动调整、自动引流和自动调度。

当前根据业务需求规划了如下几种骨干网调度策略:

IGP:最低开销转发,ISIS接口的cost根据点到点之间专线物理距离延迟*100得到;

Delay:最低延迟转发,ISIS接口配置PM功能,动态探测点到点之间实际延迟;

TCO:最优成本转发,控制器根据每条专线的实际成本计算出最优成本路径;

FM:自定义转发,控制器根据业务临时需求下发需求路径;

FBN:公网隧道转发,每个地域之间提供公网VPN线路,提供备份转发路径。

SR Policy中基于Color定义两种引流方式:

1、Per-Destination引流模板:Color在某种程度上将网络和业务进行了解耦,业务方可以通过Color来描述更复杂的业务诉求,SR-TE通过Color进行业务关联。

2、Per-Flow引流模板:通过DSCP标记业务,或者ACL进行流分类映射到Service-Class等级,Service-Class关联Color进行业务引流。

Color资源规划

Color属性在SR-TE中标记路由,用于头端节点进行灵活引流;新一代骨干网络设计的流量调度中定义四种Color类型:

默认Color:每个城市节点的用户路由必须携带的Color值,用于引流默认隧道转发【预埋保留】。

城市Color:每个城市每用户VRF路由必须携带的Color值,用于全局流量调度使用【每个城市默认分配9种相同Color分别关联到不同的业务】。

业务Color:在Per-flow(基于流分类调度)场景中使用,每个城市的MAN网络和用户私网路由标记使用,全局引流作用。

本地Color:在Per-flow(基于流分类调度)场景中结合自用Color使用,映射Service-Class服务等级,关联到业务模板。

Color分配规则

最佳实践方案

下面以流调度为例来介绍UCloud骨干网业务基于SR技术结合的最佳实践方案。

Per-Flow场景下业务模板/Color与Service-Class服务等级关联

1.Per-Flow流量调度规划每个城市分配一个业务Color,MAN网络路由在PE设备上标记各城市业务Color;

2.每个头端节点PE上定义8种调度策略,对应于不同的业务模板,其中2个业务模板保留;业务模板与Color、Service-Class定义标准的映射关系;

3.点到点的城市之间默认支持2条FM自定义策略(自定义隧道策略);

4.IGP、Delay使用动态SR Policy,其它隧道采用静态SR Policy策略;

5.Per-Flow 场景下的endpoint地址支持Anycast-SID,头端的一台PE到末端两台城市的PE只需要定义一条SR Policy即可;

6.以20个核心城市为例,单个城市的PE Per-Flow的SR Policy数量为19*7=133条。

在规划中,UCloud基础网络团队根据公有云业务类型将业务进行分类,分类方法是对具体业务进行DSCP标记;然后数据包到了骨干网PE后再根据DSCP进行灵活引流。

业务模板与Service-Class服务等级映射:

我们将骨干网当作一个整体,这个整体的边界端口使用DSCP和ACL入Service-Class,下面明确定义下何为边界端口。

边界端口:

PE连接CPE&VPE、MAN网络侧的接口

DSCP入队方式:

骨干网边界端口默认信任接入侧用户的DSCP值,根据相应的DSCP入队到Service-Class服务

ACL入队方式:

1.在一些特殊场景下需要针对某些业务通过ACL分类后入队到Service-Class服务【业务本身无法携带DSCP】

2.每种隧道调度策略都可以通过ACL对流进行分类,然后入队到Service-Class

入队和转发流程:

1.在PE上配置流分类,按照业务等级,将不同的DSCP值映射到Service-Class(8种等级)

2.为隧道(Service-Class)配置对应的调度策略

3.业务流在PE设备上会先根据路由迭代看是否选择隧道(SR Policy),然后再去比对流的DSCP值是否和SR Policy中Service-Class映射设置一致,一致流将从对应隧道通过

4.业务流根据Service-Class中的调度策略进行流量转发

分类业务和SR-TE隧道映射关系如下:

1、默认所有业务按照规划的DSCP和调度策略进行关联;

2、使用ACL实现特殊业务类型进行临时策略调度。

SR-TE流量工程案例

下面介绍一个SR-TE实际调度的案例分享:

  • 业务流量背景

业务高峰时段基础网络收到香港-新加坡专线流量突发告警,智能流量分析系统发现突发流量为安全部门在广州与雅加达节点同步数据库。

  • 调度前流量模型

正常情况下广州去往雅加达的流量通过IGP最短开销计算出的路径为:广州--->香港--->新加坡--->雅加达,由于香港-新加坡段为出海流量的中转点,所以经常会在高峰期出现链路拥塞情况。

  • 传统流量调度方案

1、基于目标地址流量做逐跳PBR,将大流量业务调度到其它空闲链路转发;

2、基于目的地址的流量进行限速,保障链路带宽。

  • 传统调度存在问题

1、逐跳配置策略路由,配置复杂,运维难度大;

2、粗暴的限速策略有损内部业务。

  • SR-TE流量调度方案

Segment 列表对数据包在网络中的任意转发路径进行编码,可以避开拥塞链路,通过SR流量调度后的路径为:广州--->北京--->法兰克福--->新加坡--->雅加达。

  • SR-TE流量调度优势

1、头端/控制器可以定义端到端转发路径,通过标签转发;

2、基于业务流进行灵活流量调度(目的地址+业务等级)。

未来演进

上文用很长的篇幅介绍了UCloud骨干网历史和新一代骨干网架构设计细节,其实当前基于公有云业务调度只能从MAN网络开始,还不支持从DCN内部开始调度;未来UCloud基础网络团队将设计基于Binding SID技术的公有云业务端到端的流量调度工程,大致规划如下:

  • 骨干网为每个城市的端到端SR-TE隧道分配一个Binding SID,用于数据中心云租户引流;
  • 数据中心宿主机通过VXLAN将租户流量送到骨干网UGN(公有云跨域网关);
  • UGN解封装VXLAN报文后,封装MPLS标签,内层标签用于区分租户,外层标签用于封装远端城市的Binding SID标签;
  • PE设备收到带有目标城市的Binding SID后,自动引流进对应的SR-TE隧道进行转发;
  • 对端PE收到报文后解封外层MPLS报文,然后转发给UGN,UGN根据内层标签和VXLAN的VNI的映射关系进行转换,最终通过IP转发至DCN的宿主机上。

总结

UCloud骨干网总体设计目标是智能、可靠、可调度,一方面通过全球专线资源将各Region公有云资源、用户资源打通;另一方面在接入侧支持本地线路+互联网线路接入,构建骨干网混合组网能力,从而形成了一张稳定且高性能的骨干网,为上层公有云业务、用户线下、线上资源开通提供可靠的传输网络,整体上来看骨干网是UCloud公有云网络体系中非常重要的一个组成部分。

UCloud基础网络团队在过去的一年重构新一代骨干网,使其具备了智能、可靠、可调度的能力,从而能够合理的规划专线资源,降低了专线成本,且骨干网整体性能得到极大提升。未来UCloud基础网络团队将会继续紧跟骨干网技术发展潮流,为整个公有云跨域产品提供智能、可靠、可调度的底层网络。

作者:唐玉柱,UCloud 高级网络架构师、UCloud新一代骨干网架构规划项目负责人。拥有丰富的数据中心、骨干网架构设计和运维经验;目前主要负责UCloud全球数据中心、骨干网架构设备选型、架构设计和规划。

查看原文

赞 0 收藏 0 评论 0

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

基于Segment Routing技术构建新一代骨干网:智能、可靠、可调度(一)

前言

随着网络技术的发展和云计算业务的快速普及,当前各行各业的客户都有迫切上云的需求,越来越多的关键业务,如:web前端、视频会议、办公应用、数据存储等开始部署在云端;新的网络架构设计特别是骨干网,必然要适应云计算和互联网应用的发展,而传统的MPLS骨干网不能适应这种变化,面临如下诸多挑战:

1、如何实现用户云下与云上、云上VPC之间、云下不同物理位置之间业务的灵活开通;

2、如何利用本地专线和最后一公里互联网线路构建混合组网能力;

3、如何确保关键业务的优先级和服务质量;

4、如何简化开通流程、快速部署和统一策略管理;

5、如何提升专线带宽利用率和流量可视化;

6、如何实现新一代骨干网智能、可靠、可调度。

本文将结合UCloud基础网络团队新一代骨干网的架构演进过程,介绍Segment Routing技术在UCloud骨干网的落地细节,并详细阐述当前骨干网如何通过SR-TE技术实现智能、可靠、可调度的新一代骨干网架构。

DCN网络快速迭代

UCloud数据中心基础架构网络(以下简称DCN)在最近这几年经历了野蛮式的快速发展阶段,从北上广三地的数个可用区发展到全球25个地域31个可用区;业务云化和分布式数据中心的建设,推动了城域网(以下简称MAN)和骨干网规划建设,如下图所示:

DCN网络迭代过程如下:

1、同城单可用区升级至同城多可用区;

2、单Region多可用区升级至多Region多可用区。

DCN网络快速迭代带来的网络挑战:

1、MAN网络高带宽与可靠性要求:同城分布式DCN网络建设带来的问题是:客户业务扁平化部署,导致同城跨可用区有大量的东西向业务互访流量,对MAN网络的带宽和可靠性有严格的要求。

2、骨干网架构升级与流量工程要求:随着UCloud全球节点DCN网络的建设部署,跨地域客户开始有业务互访和跨域流量优化需求,对骨干网规划和流量工程提出了新的要求。

全球专线资源布局

当前UCloud全球CDN节点有500+,25个地域,31个可用区;通过运营商专线打通全球25个地域,如下图所示:

1、全球机房专线接入骨干网

骨干网依托UCloud全球DCN网络以及专线资源,可为用户提供全球范围的就近接入,实现端到端网络稳定,解决跨域业务互访丢包和高延迟问题。

2、全球节点灵活组网

为用户提供基于本地专线和最后一公里互联网接入,实现用户的混合组网能力。

3、提供稳定、可靠的基础架构

点到点专线资源提供物理层的带环保护,一方面通过SR-TE技术实现流级别调度和快速容灾备份能力;另一方面基础网络提供一张1:1基于Internet级的备份骨干网,保证整个骨干网达到99.99%可用率。

UCloud骨干网架构演进历史

01、2018年之前骨干网架构

UCloud基础网络团队在2016年下半年开始规划第一代骨干网(以下简称骨干网1.0),2017年底完成了骨干网1.0设计规划,骨干网1.0架构规划专线资源接入到各Region的MAN网络核心设备(以下简称M-Core),各Region的M-Core之间通过供应商二层专线进行全球组网;M-Core之间运行ISIS协议,打通全球骨干网ISIS域,每个地域双M-Core或者四M-Core和控制面RR建立IBGP邻居关系,M-Core通过IBGP协议将本地域DCN网络路由信息通告至RR,RR反射给全球所有M-Core节点;数据转发面通过IBGP路由进行迭代,最终通过ISIS转发至目标DCN网络。为优化骨干网流量转发,在关键设备上开启如下功能:

1、为实现骨干网等价路由(以下简称ECMP),必须在M-Core和RR上开启BGP ADD-PATH属性;

2、为保证IGP最短路径转发,跨域之间ISIS 开销值设置为两地域直连专线实际延迟*100,如:北京-上海专线延迟为30ms,那么北京-上海地域的ISIS开销设置为3000。

骨干网1.0设计目标:

1、实现Region级别DCN网络互通,提供云业务跨地域容灾能力;

2、支持云上用户通过UCloud高速通道产品UDPN打通跨域VPC资源。

骨干网1.0新挑战:

1、MAN网络与骨干网高度耦合,专线开通配置复杂,增加运维难度;

2、不支持客户不同物理位置之间资源互通;云下资源到云上VPC之间资源开通复杂、周期冗长;

3、不支持跨地域级别的流量智能调度。

02、2020年之前骨干网架构

针对骨干网1.0所面临的一些问题,2018年UCloud基础网络团队设计规划了第二代骨干网(下简称骨干网2.0)。在骨干网2.0中,我们新增了租户隔离的特性,而要在骨干网上实现大规模的租户隔离,MPLS-VPN技术最合适不过,但由于考虑到整体的部署成本以及部署难度,我们最终放弃了这个方案,借鉴了DCN网络的租户隔离思路,采用VXLAN二层网关方案来实现;

骨干网2.0整体架构分为两层,Underlay和Overlay;Underlay使用VXLAN+BGP EVPN实现网络大二层,在Overlay上实现骨干网1.0的架构需求;具体实现如下:

  • Underlay层规划

1、Underlay层主要由两种设备组成:TBR和TER。TBR用于运营商二层专线资源接入,主要用于数据转发,TER用于封装VXLAN报文,即VTEP设备。全球节点的TBR和TER设备通过VXLAN+ BGP EVPN技术组建一张全球二层网络,这张二层网络提供全球任意跨域节点之间二层业务开通。

2、TBR设备通过ISIS协议打通整个IGP域,TER和控制面TRR建立BGP EVPN邻居关系,各个站点互相学习MAC/IP路由;转发面数据通过VXLAN封装转发,控制面信息通过EVPN学习同步。

3、用户线下IDC业务互访,以及线下IDC到云上业务之间通过VXLAN开通二层业务。

  • Overlay层规划

跨域M-Core直连通过VXLAN开通,M-Core之间运行ISIS协议,打通全球骨干网ISIS域,每个地域双M-Core或者四M-Core和控制面RR建立IBGP邻居关系,M-Core通过IBGP协议将本地域DCN网络路由通告至RR,RR反射给全球所有M-Core节点,数据转发面通过IBGP路由进行迭代,最终通过ISIS转发至目标DCN网络。

骨干网2.0设计目标:

1、实现MAN网络和骨干网严格分层,提升运维效率;

2、通过VXLAN+BGP EVPN构建业务接入网,实现业务灵活就近上骨干;

3、实现客户云下不同物理位置、云下到云上之间资源快速开通。

骨干网2.0新挑战:

1、不支持骨干网流量智能调度;

2、本地接入只支持专线接入,组网方式不够灵活,增加网络运营成本;

3、VXLAN包头开销过大,网络传输效率低下,专线结算成本上升;

4、不支持L3VPN客户接入场景。

为了解决骨干网2.0当前的问题,UCloud基础网络团队在2019年下半年开始,对新一代骨干网架构进行重新设计、硬件选型,在新一代骨干网架构设计中采用了当前比较流行的源路由即Segment Routing技术(以下简称SR),在介绍新一代骨干网架构之前先给大家简单介绍一下SR技术的基本概念。

Segment Routing基本概念

01 Segment Routing

SR架构基于源路由,节点(路由器、主机或设备)选择路径,并引导数据包沿着该路径通过网络,具体实现方式是在数据报头中插入带顺序的段列表(Segment-list),通过Segment-list指示收到这些数据包的节点怎么去处理和转发这些数据包。

由于源节点(头端节点)通过在数据包报文头中添加适当的指令(Segment-list)即可实现基于目标地址的引流(甚至可以基于单条流粒度的引流),且除了头端节点之外,其它节点都不需要存储和维护任何流状态信息,因此引流的决定权都在头端节点。通过这种方式SR可以在IP和MPLS网络中提供高级的流量引导能力。

02 常用标签类型

  • Prefix-SID

Prefix-SID是由ISIS或者OSPF通告的全局Segment,此Segment与IGP的前缀相关;Prefix-SID代表一个路由指令,含义是:引导流量沿着支持ECMP的最短路径去往该Segment相关联的前缀。Prefix-SID具有如下特性:

-全局Segment,SR域中的所有节点都知道如何处理Prefix-SID。

-支持多跳,单个Segment跨越路径中的多跳,这样就减少了路径所需要的Segment数量,并允许跨多跳的等价路径。

-支持ECMP,可以原生利用IGP的等价路径。

-Prefix-SID一般是通过手工分配,也可使用控制器分配。

  • Node-SID

Node-SID是一种特殊类型的IGP Prefix Segment,是Prefix Segment的子类型,通常是某个节点环回口的32位前缀地址,这个地址一般是IGP的“路由器ID”;Node-SID指令是:引导流量沿着支持ECMP的最短路径去往该Segment相关联的前缀。其和Prefix Segment的指令是一致的。

  • Adjacency-SID

Adjacency-SID是与单向邻接或者单向邻接集合相关联的Segment,使用Adj-SID转发的流量将被引导至指定链路,而不管最短路径路由如何,一般情况下节点会通告它的本节点链路Segment(Adj-SID);Adjacency-SID指令是:“引导流量从与该Segment相关联的邻接链路转发出去”。Adjacency-SID具有如下特性:

-本地Segment,SR域中的只有Adjacency-SID始发节点知道如何处理该Segment。

-支持显式路径,任何路径都可以使用Adjacency-SID来表示。

-不依赖于IGP的动态路由计算,可以绕过ECMP,走管理员指定的路径转发。

实际部署中应尽量少用Adj-SID,因为其不支持ECMP,且会增加Segment-list长度,因此建议多使用Prefix-SID,即支持ECMP,又可以减少Segment-list长度。

  • Anycast-SID

SR域中多个节点上配置相同的单播前缀,那么该单播前缀就是一个Anycast-SID,Anycast-SID也是Prefix-SID的一个子类型。Anycast集合的属性是去往Anycast地址的流量被路由到Anycast集合中距离最近(IGP 最短距离)的那个成员,如果开销相同,则流量会进行ECMP,如果Anycast的成员发生故障,则由Anycast集合的其它成员来处理去往Anycast-SID的流量;Anycast-SID指令是:引导流量沿着支持ECMP的最短路径去往该Segment相关联的前缀。其和Prefix Segment的指令是一致的。

Anycast-SID具有如下特性:

-全局Segment

-天生支持ECMP

-支持高可用性

-支持流量工程

注意:所有节点必须配置相同的SRGB,才可以通告相同的Anycast Prefix-SID。

03 SR Policy特性

SR-Policy

为了解决传统隧道接口体系存在的问题, SR Policy 完全抛弃了隧道接口的概念,SR Policy 通过Segment 列表来实现流量工程;Segment 列表对数据包在网络中的任意转发路径进行编码。列表中的 Segment 可以是任何类型:IGP Segment 、 IGP Flex-Algo Segment(灵活算法) 、BGP Segment 等。

从本质上讲,SR Policy(SR-TE)是 Segment 列表,不是隧道接口。

SR Policy 由以下三元组标识:

头端(Headend):SR Policy 生成/实现的地方。

颜色(Color):任意的 32 位数值,用于区分同一头端和端点对之间的多条 SR Policy。

端点(Endpoint):SR Policy 的终结点,是一个 IPv4/IPv6 地址。

颜色是 SR Policy 的重要属性,通常代表意图,表示到达端点的特定方式(例如低延迟、低成本并排除特定属性链路等),Color也是流量引流的重要参考属性。

SR Policy生成的路径一般有两种:显式路径和动态路径

1、显式路径

显式路径一般是通过CLI/Netconf方式人工规划或者通过控制器方式下发的路径信息,主要包括信息有 endpoint地址、Color、Segment-List等;显式路径的最大弊端是无法及时响应网络拓扑变化;为了能保证故障场景下SR Policy能够快速收敛,可以通过验证头端的SR-TE数据来进行收敛。

建议Segment-List使用描述符(IP)形式编写,头端默认会验证所有描述符;

  • 一旦SR Policy候选路径不具有有效的Segment列表(描述符验证失败),则此候选路径变为无效;
  • 当SR Policy 所有候选路径都是无效的,则此SR-Policy无效。

如果SR Policy变为无效,则应用会失效;默认情况下SR Policy的转发条目被删除,流量回退到默认转发(SR-BE)路径。

2、动态路径

动态路径是由头端(路由器)或者PCEP根据头端的请求自动计算SR Policy候选路径:

  • 动态路径主要表示为优化目标和一组约束条件,这两个因素指定了SR-TE的意图。
  • 头端可以通过本地的SR-TE数据库算出路径,提供一个Segment列表或者一组Segment列表。
  • 当头端不具备足够的拓扑信息时(跨域环境),头端可以将计算委托给控制器,由控制器自动算路。
  • 当网络发生改变时,动态路径会自动进行重算以适应网络变化。

04SR Policy 自动引流

SR Policy引流支持域内场景和跨域场景,整体的转发流程如下:

  • 着色:出口PE在向入口PE通告BGP业务路由时,或者入口PE接收路由时对路由进行着色(标记路由Color),Color用于表示路由所需要的SLA。
  • 计算+引流:域内场景下,头端节点收到BGP路由后,通过头端SR-TE数据库自动算路完成引流;跨域场景下,头端向控制器发送有状态的PCEP路径计算请求,控制器计算去往远端端点的SR-TE跨域路径。
  • 转发:数据包在头端完成引流,使用头端计算或者控制器下发的路径进行标签转发。

将 BGP 路由安装到 SR Policy 的动作称为自动引流,其原理主要是通过对BGP业务路由进行着色,将流量自动引导至 SR Policy;SR Policy的自动引流不需要复杂和繁琐的引流配置,而且流量引导对转发性能没有影响,流量控制粒度更为精细。

SR/SR-TE or LDP/RSVP-TE ?

UCloud基础网络团队在新一代骨干网设计中转发面统一使用MPLS封装转发,而控制面的选择经过慎重考虑,我们详细对比了SR/SR-TE和LDP/RSVP-TE后,最终选择了SR/SR-TE,具体分析情况如下:

总结

本篇分享了数据中心野蛮式增长给MAN网络和骨干网带来的极大挑战,以及SR部分技术原理。在过去几年里,UCloud基础网络团队不断演进骨干网架构,从骨干网1.0升级到骨干网2.0架构,实现了用户云下资源之间、云下到云上资源的快速开通,但依然满足不了当前互联网客户的业务快速发展需求,例如:不支持智能流量调度、无法实现客户L3VPN接入需求,不支持最后一公里Internet线路接入等。

下一篇将重点介绍UCloud如何结合Segment Routing技术实现智能、可靠、可调度的新一代骨干网,助力用户分钟级构建多地域全球网络以及同城多可用区互访、多Region多可用区互联,实现UCloud与用户线上线下IDC无间隔互通,升化云网协同。

本文作者:唐玉柱,UCloud 高级网络架构师、UCloud新一代骨干网架构规划项目负责人。拥有丰富的数据中心、骨干网架构设计和运维经验;目前主要负责UCloud全球数据中心、骨干网架构设备选型、架构设计和规划。

查看原文

赞 0 收藏 0 评论 0

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

2021年,用更现代的方法使用PGP(下)

上篇链接:

2021年,用更现代的方法使用PGP(上)
2021年,用更现代的方法使用PGP(中)

PGP 公钥的 发布 与 交换

讨论公钥安全交换的中文文章比较少,而这一环是整个加密体系的重中之重。 大部分的PGP教程最后一步就是让小白用户将公钥上传,这是非常过时,且不负责任的,所以这里来详细介绍下PGP 公钥的 发布 与 交换。

原则

首先明确一点: 上传公钥到 公钥服务器 不是必要的,甚至是危险的。

如果你是新手,请不要发布你的公钥到 公钥服务器。

引子

通过前文,你已经熟悉了gpg的本地使用, 并且生成了自己的PGP 密钥对。

想象一下, 如果你生活在1980年代, 想和远方的朋友加密通信,需要先交换彼此的公钥,又没有一个统一的可信的认证机构,这时会有什么问题?

当面交换吗?当然是个办法,但是相信你不会想要将下列

1609751914957

这么长的公钥抄写到纸上,然后开车送到朋友那里,再让朋友照着这个输入他的电脑。如果中间有变动,需要重复以上过程n次。

那么还有其他办法吗?

那个时代还没有line、wechat这类即时通讯软件,而邮件提供商默认是不可靠的,不然也不会有PGP的诞生。 并且彼时https还未出现,用邮件交换PGP交换公钥显然不太安全。

你们双方都需要便捷地交换公玥, 并且确认彼此得到的公钥确实是未经篡改过的,真实有效的,就成了一个难题,这样,公钥服务器也就呼之欲出了。

公钥服务器 KeyServer

公钥服务器使得人们只需要交换他们短短的key id 或者user id就可以方便地从公钥服务器下载公钥。

历史与设计初衷

第一个KeyServer 叫做 HKP( web-based OpenPGP HTTP Keyserver Protocol) Keyserver , 诞生在上世纪90年代,是Marc Horowitz在麻省理工学习时为了他的论文而搭建的。在此之前, 虽然不是那么安全, 但是大部分人依靠电子邮件来交换公钥。

虽然服务器有了, 但开发者们担心政府会试图强迫钥匙服务器运营商用政府选择的各种证书来替换证书。

所以他们做出了一个决定:公钥服务器永远不会删除信息。公钥服务器可以为现有的证书添加信息(比如可以revoke/sign或者调整expire时间),但永远永远永远不会删除证书或证书的信息。

为了达到这个目标,他们开始运行一个分布式的国际公钥服务器网络,这就是现在的KeyServer。世界各地的公钥服务器会定期相互通信,同步,比较目录。如果政府强迫公钥服务器运营商删除或修改证书,那么在比较步骤中就会被发现。残缺的公钥服务器会用完好钥匙服务器目录中的内容更新自己。

任何东西都不会被删除,听起来很美好,也是解决政府审查问题的一个简单而有效的办法,可是正是这个原则后来给KeyServer带来了无穷无尽的问题。

信任网络 (Web of Trust)

好了,现在我们有了一个可以方便地上传和下载公钥的地方, 这样是不是就万事大吉了呢?

对于KeyServer 来说,任何人都可以上传公钥并声称自己是Linus, 是Zuckerberg,或是任何其他人,而KeyServer并不会去验证你是否是你所声称的人(因为KeyServer本来就没有一个中心化的运营者)。

如果你有一些密码学的基础, 那么就会知道, PGP协议依靠的非对称加密算法, 最脆弱的点就在于公钥的交换这一步。公钥交换时最容易收到中间人攻击,你一定要确定你接收到的公钥确实是你想交流的人的,由此TSL引入了CA证书认证体系,由一个可信的权威第三方来认证并颁发证书来解决身份的认证问题。 (具体可参见https系列没那么浅地谈谈HTTP与HTTPS)。

“信任一个权威的第三方” 对于最初的极具有hack精神的开发者们来说, 显然是无法接受的。

当然,你可以说下载公钥后,通过电话等手段验证下公钥的指纹(fingerprint),就可以确认正确与否。 但是想象一下, 如果你在公钥服务器找到一个声称自己Linus Torvalds 的人, 你并没有他的其他联系方式,将永远无法确定这个公钥持有者到底是谁、这个公钥可信与否 , 这样无疑是低效的,并且使整个系统沦为了熟人之间的小网络。

要知道,根据六度分隔理论(Six Degrees of Separation),世界上任何互不相识的两人,平均通过六个人就可以产生联系。 那么可以不可以这么思考, 假设我和小A见过面并检查过他的公钥,因而知道小A的公钥的的确确属于他本人,我选择信任小A。而小A同样验证了小B的证书并为小B的证书签名背书——小A的证书的持有人在此证明该证书是真实属于小B。那么我无须见亲见小B本人,也可以通过小A的背书而接受小B的证书。

如此循环下去,就形成了一张网, 这就是信任网络。

主流公钥服务器

1. SKS Keyserver Pool

当今世界最大的Key Server 池, 符合它的标准的世界各地的公钥服务器会定期相互通信,同步,比较目录,数据完全开放下载。 现在一般说起KeyServer说的就是这个。

KeyServer虽然一直是PGP的重要基础设置 ,但SKS Keyserver Pool 其实目前只有不到20台服务器,GnuPG默认用的服务器是其中的 HKPS pool,只有四台服务器。

2. Base Modern Software KeyServer

有一些KeyServer 没有用SKS的软件,运行的是更下现代和稳定的软件,比较有代表性的是 Ubuntu keyserver, 基于Hockeypuck , 这些服务器仍然会和SKS pool保持同步。

3. 独立KeyServer

这些服务器不与SKS pool同步数据,由中心化的运营者运行, 会对公钥上传者做一定的认证, 并且支持删除自己的公钥。

比较有代表性的有, keys.openpgp.org ,KeyBase等等。

在gpg中使用

发布

gpg   --send-keys  {keyid/uid}

下载

gpg --recv-keys {keyid/uid}

此时有可能报错

gpg: "xxxxxr" not a key ID: skipping

这时换个KeyServer就行:

gpg  --keyserver hkps://keyserver.ubuntu.com --recv-keys {keyid/uid}

签名和验证 他人公钥

验证公钥真实性 依靠多渠道确认的 公钥指纹。

一般来说为别人的公钥签名后,需要发还给他,或者发到公钥服务器(最好经过本人同意)。

gpg --sign-key  {keyid/uid}   # 为已经导入的 他人钥签名, 你为他签名,意味着你将为他的身份真实性背书,请谨慎 

高级设置

因为并不推荐大家使用KeyServer,所以这里只列举了基础操作。

如果你决定使用KeyServer的话,可以参考 OpenPGP 最佳实践 - 密钥服务器设置你的客户端与服务器通信使用 HKPS (HKP On SSL)协议, 并定期更新从服务器下载的公钥。

安全风险和争议, 被玩坏的KeyServer

在20世纪90年代初,开发者们怀着对技术的信心和人性的希望,期望创建一个友善 、纯粹、没有审查的净土, 在当时背景下,KeyServer不能删除任何已上传的东西,听起来是美好的,设计似乎是合理的。

但是事实是,网络匿名环境中充满了不那么友好的, 甚至是恶意的使用者,在当今看来 ,KeyServer这个系统并不健壮,问题重重,许多问题已经被发现十多年,而且无望解决。

滥用

按照官方推荐, UID (User ID) 是用来存储用户信息的,应该在里面填上你的名字和邮箱,一个 GPG 帐号下可以有若干个 UID。

而其实这个UID是没有任何强制限制的,也就是说你可以在UID中放入任何东西,可以是小说片段,可以是磁力链接,可是以编码后的图像、音频或视频......

1609913349212

当上传到KeyServer时, UID限制了2k的字符 . 以至于有人写了个用KeyServer存文件的项目keyserver-fs)

再次想象一下,你往网盘传了一个文件,共享给其他人,全世界的人都可以往这个网盘文件中添加文件,而且永远无法删除,情况会变得有多糟糕。

脆弱的KeyID

见过一些生成 PGP“靓号”的工具,就是指定你喜欢的ID规则,工具会暴力生成PGP密钥, 从中返回给你想要的密钥。

由此很容易想到,若攻击者知道了目标的KeyID, 完全可以通过工具来生成完全一样的KeyID(这就是碰撞), 并上传到KeyServer,来冒充目标。

而伪造一个KeyID有多容易呢,有研究人员借助scallion程序,使用了普通的GPU(Nvidia GeForce GTX)进行碰撞,花了4秒的时间就生成了一个指定的32 bit的 KeyID。

官方推荐公布自己的KeyID时,最少应该公布64 bit(也就是长16位16进制数啦 ),但是研究表明64 bit的KeyID也是可以 被碰撞的。

投毒

公钥服务器任何人都可以上传公钥,甚至你可以上传别人的公钥,比如你可以将自己签名过的别人的公钥,再次上传到KeyServer。

签名Dos

在WOT认证体系的设计中, 当客户端收到一份未知证书时,它应当从公钥服务器拉取所有为这张证书签过名的人的证书,逐层上溯,看看是否能够找到一张已经被用户信任的证书。如果能的话,就视信任这张为可信的。

2019年6月,有攻击者恶意向公钥服务器提交了对两个著名网友的签名背书。此事件中的受害者 Robert J. Hansen 的证书就被签名了 15000 次。因而任何人的 GPG 在尝试验证他的证书时,都会拉取 15000 个签名。而 GPG 在验证这么多签名的过程中会卡住很久。

由于被攻击的两个人在 GPG 社区中中地位很高,他们在 GPG 信任网络中处于相当核心的位置。这意味着——当你验证任意一份证书的时候,有不小的概率你会不小心拉取到他们俩的证书,然后你的 GPG 就会卡住。不但他们俩的证书没法用了,他们俩签名过的证书也都面临危险,乃至于他们俩签名过的证书所签名的证书……

而上传到KeyServer的所有东西都是不可删除的...为了解决这个问题, GnuPG 2.2.17 LWN.net 开始, 从KeyServer下载公钥时默认不再下载关联的公钥, 如果你想要感受证书DoS攻击的话,可以在设置中开启:

# ~/.gnupg/gpg.conf
keyserver-options no-self-sigs-only,no-import-clean
爆破

有个很厉害的程序媛Yegor Timoshenko(前面的SKS文件存储项目也是她的杰作),写了个工具SKS-Exploit,可以将任何人的PGP公钥损坏,变得不可导入。

这个工具同时还可以给任意人的公钥 追加伪造的UID(不是KeyID),并骗过KeyServer。

1609914787731

另外能直接让KeyServer宕机。

隐私问题

讽刺的是, 最初为了保护人们隐私而生的PGP , 却因为不能满足保护隐私的法规GDPR ,而使一个公开的 SKS 公钥服务器在欧洲处于违法状态(GDPR规定: 服务商必须提供删除个人信息的选项)。

许多新手按照教程提示的在创建PGP 密钥的时候填上了自己的真实姓名,并按照那些教程将公钥上传到了KeyServer,在人肉社工猖獗的今天,简直是个灾难。

我试着在KeyServer搜过一些博客作者留下的PGP Key, 不乏有些比较注重自身隐私的,可是他们大部分都将自己真实的名字(汉字或拼音)和邮箱一起发到了服务器上,要知道那里的数据是公开且永远不能删除的。 也有些人意识到问题之后revoke了带有真实姓名的公钥,可是仍然可以查到,并且变得更加显眼(revoke过的key会变红)。

其他发布公钥的方法

1. WKD(Web Key Directory)

WKD 的工作过程是 ,通过邮箱客户端 在域名服务器检查一个"well known" 的URL, 如果匹配到了邮箱地址对应的公钥,会使用https下载,并且不需要用户进行其他操作。用户不需要gpg 命令行等等复杂操作,让PGP加密回归单纯的邮件加密本身,用起来有些像S/MIME,但其实不一样。

比如这样一个URL: https://intevation.de/.well-known/openPGPkey/hu/g8td9rsyatrazsoiho37j9n3g5ypp34h 就对应 "aheinecke@intevation.de"这个邮箱地址。

这是通过Gpg4win的使用的一个示例,

[Example from Gpg4win / GpgOL](https://files.intevation.de/u...

这种方法不会泄露自己的邮箱,也不需要验证指纹, 但是需要你的邮件服务商提供支持。

proton邮箱是原生支持 WKD的, 但是它使用的是自己私钥,似乎没办法使用使用自己本地的公钥,其他也有支持。

如果你有自己的邮箱服务器,并且想折腾的话,可以参照WKD Hosting

2. 当面交换

如果是和熟识的朋友,你可以约在任何合适地方,用你喜欢的方式交换密钥, 比如交换纸条,交换TF卡 或者usb设备,互相签名认证,互相得到公钥。

如果是想认识更多的人,并让自己的公钥被更多的人认证, 你可以参加「公钥签名派对(Key signing party)」。参与派对的人们相互交换公钥的指纹(公钥一般是存在服务器或是一个别人可以下载到的地方,这里只交换指纹),甚至需要相互出示身份证、护照、驾照、出身证明,以验明正身。

Key signing in front of FOSDEM 2008

3. DNS

有很多种方法将你的公钥通过DNS服务发布,但是有些一些方法只适用于老版本的GnuPG,有些方法只适用与新版本的GnuPG,兼容性不佳,而且搞起来比较繁琐,有兴趣的可以自行查找资料。在这里并不推荐使用。

4.个人网站 或 社交软件中

现在中文世界, PGP的使用者中 有很多都是 独立的博客作者, 如果你拥有自己的博客或者个人网站,当然可以选择将自己的公钥发布在上面,最好给你的网站上一个Https 。

很多社交网站的个人展示页,可以自由编辑你的信息,你可以将PGP的 公钥发布在这里, 或者将 指纹 放在这, 这样通过其他渠道下载到公钥的人,也可以确认身份。

5. 代码仓库或Gist

无论你是不是开发者, 都可以拥有一个Github账号, 你可以开一个仓库专门用来发布自己的公钥,或者将公钥发布到Gist。

6. 共享笔记

Notion或者印象笔记等可以共享笔记的地方,都可以贴出你的公钥。

最后

使用分散的、多渠道的、可能是线下的方式来交换和确认公钥 ,不要相信在放一处的 公钥 和指纹。

去验证紧跟在公钥后面的指纹 , 就像你去问一个诈骗者,他是不是一个诈骗者一样无用。

如果不是当面,请至少从两个渠道进行验证,比如你从一个渠道(比如这里)得到了我的公钥 , 你想和我安全通信的话,导入前一定要从另一处(比如我公布的其他账号的简介)得到我的指纹, 验证是否一致后再进行操作。

而且每次使用前,请重复以上步骤,确保你手上的公钥是最新的。

参考链接

[1]. 用 PGP 保护代码完整性系列

[2]. The GNU Privacy Handbook

[2]. GnuPG: 用多个sub keys保护primary key | missing idea (wordpress.com)

[3]. PGP 自我扫盲

[4]. GPG 的正确使用姿势

[5]. 电子邮件加密指南

[6]. Short key IDs are bad news (with OpenPGP and GNU Privacy Guard)

[7]. gnupg密钥签署原理和过程 // Shell's Home (shell909090.org)

[8]. PGP Key Server| Roll Your Own Network

[9]. Are SKS keyservers safe? Do we need them?

[10]. SKS Keyserver Network Under Attack

[11]. OpenPGP 最佳实践 - 公钥服务器

[12]. GPG SKS 同步网络被投毒事件及其影响

[13]. where-to-upload-PGP-public-key-are-keyservers-still-surviving

[14]. GPG简明介绍

查看原文

赞 0 收藏 0 评论 0

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

更快、更稳,满足多IP防护需求,UDDoS华东BGP台州高防来了!

UDDoS内地高防是UCloud面向UCloud云上及云外用户推出的抗DDoS攻击的增值付费产品,通过高防IP来代理源站IP,并面向用户,既起到防护作用,又确保源站IP不直接暴露出去。内地高防适合业务服务器部署在中国内地,提供中国内地用户访问,有防护需求的IP(包括非UCloud的外网IP)。

2020年,UCloud内地高防经过不断更新迭代,推出了诸多重点新功能特性,包括:

  • 高防API与转发重构

增强产品稳定性,并优化产品体验

  • 域名白名单

支持主域名形式录入,未备案域名检查以符合监管政策

  • 域名转发

结合UWAF,支持域名转发、非标准端口、CC攻击防护

在产品迭代的过程中,UDDoS内地高防也真实有效的帮助到一些企业免受DDoS流量攻击,保障了业务的顺利运行,例如:

2020年9月15日,UCloud云上某移动应用开发服务商防护峰值115G,第一时间检测到攻击并进行流量清洗,保障客户业务顺利进行。

2020年10月19日,UCloud云上某在线阅读平台客户受到100G+ DDoS攻击,第一时间检测到攻击并进行流量清洗,保障客户业务顺利进行。

2020年12月29日,UCloud云上某互联网运营系统提供商遭受峰值185G,第一时间检测到攻击并进行流量清洗,保障客户业务顺利进行。

2021年初,UDDoS防护产品又迎来一次重大升级,中国内地华东BGP台州高防上线!

  • 延迟更低(平均50ms,优化不同线路访问质量)
  • 灾备能力(三线BGP,提升业务可用性)
  • 防护能力(保底10G起步,弹性最大300G)
  • 更精细的清洗模型(自研安全清洗系统)
  • 更快速、更精确地流量展示(流量采集与展示系统升级)
  • 7X24专家支持

此外,用户只需简单四步即可快速接入内地高防:

1.源站使用新EIP替换已经暴露的EIP;

2.购买高防套餐,添加高防IP;

3.源站防火墙或相关安全防护软件上对高防回源IP段放行;

4.使用高防IP接入业务。

  • UDDoS安全防护体系

image.png

  • UDDoS内地高防对比

image.png

  • 选择合适的防护方案

image.png

  • 台州高防价格

image.png

限时重磅特惠:前10名新用户享2000元优惠!!!

了解更多产品详情可扫描下方二维码查阅(产品文档链接)或联系客户经理。

https://docs.ucloud.cn/uantiddos/uads/common (二维码自动识别)

查看原文

赞 0 收藏 0 评论 0

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

盲水印和图片隐写术

盲水印

一、演示

首先看 这是一张女朋友

5cd152cce839e

解码水印

接下来我们输入一行神奇的命令:

python bwm.py --action decode --origin Demo.jpg --im ../Gakki.jpg --result res.jpg

可以得到这样的一张图:

res

以后谁再跟你抢女朋友就可以这样声明版权了嘿嘿.

(脚本和原图都在最后的附录里, 有兴趣的朋友只需要将上面的图片保存为Demo.jpg,附录里的原图保存为Gakki.jpg, 就可以解码出上面的信息)

加密水印

通过今天的方法你可以将信息放入任意图片,来达到加密信息的目的.

附录里的脚本, 加密用法:

python bwm.py --action encode --origin Gakki.jpg --im wm1.png --result Demo.jpg --alpha 2

二、用途

上面 的水印就叫做盲水印,隐藏式的水印是以数字数据的方式加入音频、图片或影片中,但在一般的状况下无法被看见。隐藏式水印的重要应用之一是保护版权,期望能借此避免或阻止数字媒体未经授权的复制和拷贝。

1.不同人加相同水印

声明版权

应用案例

  • 某些画师、摄影师、设计师会在其作品中加入水印。
13年左右有位自称是“超写实主义”的画家,声称自己纯手工画的画写实程度可以超过摄影机,并开办培训班敛财。

后被一位加了盲水印的摄影师戳穿,原来其“画作”都是直接将照片用ps处理成手绘质感的图。
  • 淘宝防盗图功能
淘宝卖家图会被淘宝自动打上水印,如果有别的卖家存图作为自己的图上传会被检测出。
2.不同人加不同水印

将某份保密数字资料发送给不同人时,可加上不同标识,如果资料被复制、传播可根据解码出的唯一标识来追究责任人。

应用案例

  • 电影刚刚公映时,每个影院,影厅的 电影底片里都会加入不同的不可见水印, 如果电影流出,就可追究相关影院责任。
  • 阿里,华为等公司内部论坛、平台会在HTML页面中加入足够数量 及不被发现的唯一标识。当有内部敏感信息通过截图等方式流出,也可追踪到个人。

    比如著名的“阿里月饼门”。

1551441624605

三、原理

原理图

v2-bbecf64a76b3dbfc4539e38e46ad8223_hd

傅里叶变换

  • 简单复习下傅里叶变换

傅里叶变换简单地说就是将信号在时域空域的函数转变到频域表示,在和工程学中有许多应用。因其基本思想首先由法国学者约瑟夫·傅里叶系统地提出。

  • 再理解下时域和频域

Fourier_transform_time_and_frequency_domains_(small).gif)

40cf849e55ed95732a60b52d4019d609_b

那么,傅里叶变换有什么用呢,

  • 先在纸上画一个sin(x),不一定标准,意思差不多就行。不是很难吧。
  • 好,接下去画一个sin(3x)+sin(5x)的图形。这个就很难能画得出来。

现在把sin(3x)+sin(5x)的曲线给你,只看图是看不出这整个曲线的方程式是怎样的,现在需要将把sin(5x)从图里拿出去,看看剩下的是什么。这基本是不可能做到的。

但是在频域呢?则简单的很,无非就是几条竖线而已。

这是最简单的一种用法,其他复杂用法不在此赘述。

频谱图

一维信号的变换理解之后,那么图像的频谱图长什么样呢。

图片中明亮的部分就是低频(平缓)部分,暗点的是高频(突变交界)部分。一般为了展示会把频谱图低频的部分移到中心。频谱图上的点跟原图不存在一一对应关系,频谱图的每一点都来自于全部的图像(类似于时域曲线的点,和频域图的点)。

这样可能还不够直观,接下来看这张图。

img

这是一张400x400的图,共有16 万个像素点。

我们平时怎么来表示一张图片呢,首先是在笛卡尔坐标系中用x,y来定位某一确定的点。那么,我们怎么来描述这个点呢?

我们知道,所有的色彩都是由三原色组成。生活中经常说的红、黄、蓝(青),其实是一种消减型的三原色,光学中的三原色是红、绿、蓝,也就是R、G、B。

通常我们用来描述图像点的方法就是RGB的值,其实图像处理中用的是灰度(Gray scale)来表示图片,但是为了便于理解,下面用的是RGB演示 。

CORB-RGB.png

上图是截取了某一行RGB的值做成的曲线图,可以看到,每条曲线都在不停的上下波动,且波动的频率是相同的。有些区域的波动比较小,有些区域突然出现了大幅波动。

对比一下图像就能发现,曲线波动较大的地方,也是图像出现突变的地方。

图像的频谱可以理解为将一维的频谱绕着纵轴旋转一圈,形成一个3维的数学函数图(原图中心对称、镜像对称才可以这样干,其他类似),x、y轴代表两个方向的频率,z轴代表该频率的幅值,只不过频谱图像是一个2维图,所以用亮度来表示幅值了。

二维傅里叶变换的物理意义是将图像的灰度分布函数变换为图像的频率分布函数。

盲水印的特性

鲁棒性一般要能抗(压缩 、裁剪、涂画,旋转)。

特性

  1. 隐蔽性

    由于不希望被察觉、不希望干扰用户体验、不希望被模仿等等原因,我们的水印不可见,也就是隐匿性。

  2. 不易移除性

    不易移除性跟鲁棒性有些相似, 不同的是:

    鲁棒性更加强调的是数字资源在传播过程中不要被不自觉地干扰和破坏。

    不易移除性是在别有用心者察觉了盲水印的存在后,不被他们自觉地移除或者破坏。

  3. 强健性

    强健性通常也被称作鲁棒性,来自于其英文名称(Robustness)的音译。

    简单地说就是耐操性。

    需要说明的一点是,鲁棒性和隐蔽性通常不可兼得。

  4. 明确性

    没什么可说的,就是盲水印需要表示出明确的信息。

四、引申

图种

相貌平平

例如这是一张相貌平平的图片, 你可以保存下来,将后缀改为"rar"或者直接用解压工具打开,就可以看到神秘福利.

|ू・ω・` )

制作方法也很简单,在win下 入以下命令就可以做一张"图种"了.

copy /b A.jpg + B.zip C.jpg

大约十年以前,图种被广泛上传到论坛等地用来传播资源。后来由于许多网站在上传图片时会判断图片结尾标识,其之后的全部丢弃,慢慢不再有人使用。(https://sm.ms/这个图床还是很给力的, 经测试还是可以解析种子)

隐藏文件

图片可以跟种子文件结合,当然也可以和其他文件结合。

其实隐藏文件和盲水印都属于图片隐写术

图片隐写术

隐写术(Steganography)也是数字水印的一种应用,双方可利用隐藏在数字信号中的信息进行沟通。

数字照片中的注释数据能记录照片拍摄的时间、使用的光圈快门,甚至是相机的厂牌等信息,这也是数字水印的应用之一。

某些文件格式可以包含这些称为“metadata”的额外信息。

用途

规避敏感词过滤

​ 所谓的“敏感词过滤”,常翻墙的同学,应该都很熟悉了。用图片来隐藏信息,可以规避GFW的敏感词过滤。

规避肉眼审查

​ 国内的很多网站,对于上传的图片,都会进行人工审查。如果能通过技术手段把信息隐藏在图片中,而图片本身又看不出什么异样,人工审核就看不出来。

传递加密信息

​ 不希望被别人看到的资料、信息等。

常见方法

原理

内容覆盖法

通常来说,图片文件都有包含2部分:文件头和数据区。

而“内容覆盖法”,就是把要隐藏的文件,直接【覆盖】到图片文件的【数据区】的【尾部】。

比方说,某图片有 100KB,其中文件头占 1KB,那么,数据区就是 99KB。也就是说,最多只能隐藏 99KB 的文件。

切记:覆盖的时候,千万不可破坏文件头。文件头一旦破坏,这个图片文件就不再是一个合法的图片文件了。
  

使用这种方法,对图片文件的格式,是有讲究的——最好用【24位色的 BMP 格式】。

  • BMP 格式本身比较简单,数据区随便覆盖,问题不大;
  • 24位色的 BMP 相对其它的格式 BMP,文件尺寸更大,可以隐藏更多内容。
import sys

def embed(container_file, data_file, output_file) :
    """代码没有严格计算 BMP 的文件头尺寸,只是大致预留了 1024 字节"""
    
    container = open(container_file, "rb").read()
    data = open(data_file, "rb").read()

    if len(data)+1024 >= len(container) :
        print("Not enough space to save " + data_file)
    else :
        f = open(output_file, "wb")
        f.write(container[ : len(container)-len(data)])
        f.write(data)
        f.close()

if "__main__" == __name__ :
    try :
        if len(sys.argv) == 4 :
            embed(sys.argv[1], sys.argv[2], sys.argv[3])
        else :
            print("Usage:\n%s container data output" % sys.argv[0])
    except Exception as err :
        print(err)

LSB最低有效位

很多商业软件使用的原理都是这个方法。

例如在PNG图片的储存中,每个颜色会有8bit,LSB(Least Significant Bit)隐写就是修改了像数中的最低的1bit,在人眼看来是看不出来区别的,也把信息隐藏起来了。(每个像数可以携带3bit的信息。)

image-20210113193335303

譬如我们想把’A’隐藏进来的话,如下图,就可以把A转成16进制的0x61再转成二进制的01100001,再修改为红色通道的最低位为这些二进制串。

image-20210113193350763

最后

  1. 附上前面演示代码的实现:

    (参考了几个git hub上的项目,不过鲁棒性都不太好)

    # coding=utf-8
    import cv2
    import numpy as np
    import random
    import os
    from argparse import ArgumentParser
    
    ALPHA = 5
    
    class BlindWaterMark():
        """盲水印加解密,无频移简单版"""
        def __init__(self):
            self.parser = ArgumentParser()
            self.parser.add_argument('--action', dest='action', required=True)
            self.parser.add_argument('--origin', dest='ori', required=True)
            self.parser.add_argument('--img', dest='img', required=True)
            self.parser.add_argument('--result', dest='res', required=True)
            self.parser.add_argument('--alpha', dest='alpha', default=ALPHA)
    
        def encode(self, ori_path, wm_path, res_path, alpha):
            img = cv2.imread(ori_path)
            img_f = np.fft.fft2(img)  # 2维离散傅里叶变换
    
            height, width, channel = np.shape(img)
            watermark = cv2.imread(wm_path)
            wm_height, wm_width = watermark.shape[0], watermark.shape[1]
    
            # 水印随机编码
            x, y = range(height / 2), range(width)
            random.seed(height + width)   # 随机数解码时可控
            random.shuffle(x)
            random.shuffle(y)
            
            # 按目标图片大小 对水印图进行对称
            tmp = np.zeros(img.shape)  # 根据图片形状,生成0填充的矩阵
    
            for i in range(height / 2):
                for j in range(width):
                    if x[i] < wm_height and y[j] < wm_width:
                        tmp[i][j] = watermark[x[i]][y[j]]
                        tmp[height - 1 - i][width - 1 - j] = tmp[i][j]
    
            res_f = img_f + alpha * tmp  # 原图频域值  +  水印频域值
            res = np.fft.ifft2(res_f)      # 傅里叶逆变换
            res = np.real(res)  # 转换为实数
    
            cv2.imwrite(res_path, res, [int(cv2.IMWRITE_JPEG_QUALITY), 100])
    
    
        def decode(self, ori_path, img_path, res_path, alpha):
            ori = cv2.imread(ori_path)
            img = cv2.imread(img_path)
    
            ori_f = np.fft.fft2(ori)
            img_f = np.fft.fft2(img)
    
            height, width = ori.shape[0], ori.shape[1]
            watermark = (ori_f - img_f) / alpha
    
            watermark = np.real(watermark)
            res = np.zeros(watermark.shape)
    
            random.seed(height + width)
    
            x = range(height / 2)
            y = range(width)
            random.shuffle(x)
            random.shuffle(y)
    
            for i in range(height / 2):
                for j in range(width):
                    res[x[i]][y[j]] = watermark[i][j]
                    res[height - i - 1][width - j - 1] = res[i][j]
    
            cv2.imwrite(res_path, res, [int(cv2.IMWRITE_JPEG_QUALITY), 100])
    
        def run(self):
            options = self.parser.parse_args()
            action = options.action
            ori = options.ori
            img = options.img
            res = options.res
            alpha = float(options.alpha)
    
            if not os.path.isfile(ori):
                parser.error("image %s does not exist." % ori)
            if not os.path.isfile(img):
                parser.error("watermark %s does not exist." % img)
    
            if action == "encode":
                self.encode(ori, img, res, alpha)
            elif action == "decode":
                self.decode(ori, img, res, alpha)
    
    
    if __name__ == '__main__':
        bwm = BlindWaterMark()
        bwm.run()
    

2.隐写术是一门很深、应用很广泛的学问,这里讲的很泛,权当做抛砖引玉。图片隐写术只是其中一种,有兴趣的同学可以看下面这本书。

1551625636929

查看原文

赞 0 收藏 0 评论 0

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

基于文件存储UFS的Pytorch训练IO优化实践

我们在协助某AI客户排查一个UFS文件存储的性能case时发现,其使用的Pytorch训练IO性能和硬件的IO能力有很大的差距(后面内容有具体性能对比数据)。

让我们感到困惑的是: UFS文件存储,我们使用fio自测可以达到单实例最低10Gbps带宽、IOPS也可达到2w以上。该AI客户在高IOPS要求的AI单机小模型训练场景下,或者之前使用MXNet、TensorFlow框架时,IO都能跑到UFS理论性能,甚至在大型分布式训练场景中,UFS也可以完全胜任。

于是我们开启了和客户的一次深度联合排查。

初步尝试优化

一、调整参数:

基于上述情况,首先考虑是不是使用Pytorch的姿势不对?参考网上提到经验,客户调整batch_size、Dataloader等参数。

Batch_size

默认batch_size为256,根据内存和显存配置尝试更改batch_size大小,让一次读取数据更多,发现实际对效率没有提升。通过分析是由于batch_size设置与数据读取逻辑没有直接关系,IO始终会保留单队列与后端交互,不会降低网络交互上的整体延时(因为用的是UFS文件存储,后面会讲到为什么用)。

Pytorch Dataloader

Pytorch框架dataloader的worker负责数据的读取和加载、分配。通过batch_sampler将batch数据分配给对应的worker,由worker从磁盘读取数据并加载数据到内存,dataloader从内存中读取相应batch做迭代训练。这里尝试调整了worker_num参数为CPU核数或倍数,发现提升有限,反而内存和CPU的开销提升了不少,整体加重了训练设备的负担,通过 worker加载数据时的网络开销并不会降低,与本地SSD盘差距依然存在。

这个也不难理解,后面用strace排查的时候,看到CPU更多的时候在等待。

所以:从目前信息来看,调整Pytorch框架参数对性能几乎没有影响。

二、尝试不同存储产品

在客户调整参数的同时,我们也使用了三种存储做验证,来看这里是否存在性能差异、差异到底有多大。在三种存储产品上放上同样的数据集:

  1. 单张平均大小20KB的小图片,总量2w张。
  2. 以目录树方式存到三种存储下的相同路径,使用Pytorch常用的标准读图接口CV2和PIL

测试结果,如下图:

注:SSHFS基于X86物理机(32核/64G/480G SSD*6 raid10)搭建,网络25Gbps

结论:通过对存储性能实测, UFS文件存储较本地盘、单机SSHFS性能差距较大。

为什么会选用这两种存储(SSHFS和本地SSD)做UFS性能对比?

当前主流存储产品的选型上分为两类:自建SSHFS/NFS或采用第三方NAS服务(类似UFS产品),个别场景中也会将需要的数据下载到本地SSD盘做训练。传统SSD本地盘拥有极低的IO延时,一个IO请求处理基本会在us级别完成,针对越小的文件,IO性能越明显。受限于单台物理机配置,无法扩容,数据基本 “即用即弃”。而数据是否安全也只能依赖磁盘的稳定性,一旦发生故障,数据恢复难度大。但是鉴于本地盘的优势,一般也会用作一些较小模型的训练,单次训练任务在较短时间即可完成,即使硬件故障或者数据丢失导致训练中断,对业务影响通常较小。

用户通常会使用SSD物理机自建SSHFS/NFS共享文件存储,数据IO会通过以太网络,较本地盘网络上的开销从us级到ms级,但基本可以满足大部分业务需求。但用户需要在日常使用中同时维护硬件和软件的稳定性,并且单台物理机有存储上限,如果部署多节点或分布式文件系统也会导致更大运维精力投入。

我们把前面结论放到一起看:

  1. 隐形结论:Tensorflow、Mxnet框架无问题。
  2. 调整Pytorch框架参数对性能几乎没有影响。

3、Pytorch+UFS的场景下, UFS文件存储较本地SSD盘、单机SSHFS性能差距大。

结合以上几点信息并与用户确认后的明确结论:

UFS结合非Pytorch框架使用没有性能瓶颈, Pytorch框架下用本地SSD盘没有性能瓶颈,用SSHFS性能可接受。那原因就很明显了,就是Pytorch+UFS文件存储这个组合存在IO性能问题。

深入排查优化

看到这里,大家可能会有个疑问:是不是不用UFS,用本地盘就解决了?

答案是不行,原因是训练所需的数据总量很大,很容易超过了单机的物理介质容量,另外也出于数据安全考虑,存放单机有丢失风险,而UFS是三副本的分布式存储系统,并且UFS可以提供更弹性的IO性能。

根据以上的信息快速排查3个结论,基本上可以判断出: Pytorch在读UFS数据过程中,文件读取逻辑或者UFS存储IO耗时导致。于是我们通过strace观察Pytorch读取数据整体流程:

通过strace发现,CV2方式读取UFS里的文件(NFSV4协议)有很多次SEEK动作,即便是单个小文件的读取也会“分片”读取,从而导致了多次不必要的IO读取动作,而最耗时的则是网络,从而导致整体耗时成倍增长。这也是符合我们的猜测。

简单介绍一下NFS协议特点:

NAS所有的IO都需要经过以太网,一般局域网内延时在1ms以内。以NFS数据交互为例,通过图中可以看出,针对一次完整的小文件IO操作将涉及元数据查询、数据传输等至少5次网络交互,每次交互都会涉及到client与server集群的一个TTL,其实这样的交互逻辑会存在一个问题,当单文件越小、数量越大时则延时问题将越明显,IO过程中有过多的时间消耗在网络交互,这也是NAS类存储在小文件场景下面临的经典问题。

对于UFS的架构而言,为了达到更高扩展性、更便利的维护性、更高的容灾能力,采用接入层、索引层和数据层的分层架构模式,一次IO请求会先经过接入层做负载均衡,client端再访问后端UFS索引层获取到具体文件信息,最后访问数据层获取实际文件,对于KB级别的小文件,实际在网络上的耗时比单机版NFS/SSHFS会更高。

从Pytorch框架下两种读图接口来看:CV2读取文件会“分片”进行,而PIL虽然不会“分片”读取,但是基于UFS分布式架构,一次IO会经过接入、索引、数据层,网络耗时也占比很高。我们存储同事也实际测试过这2种方法的性能差异:通过strace发现,相比OpenCV的方式,PIL的数据读取逻辑效率相对高一些。

优化方向一: 如何降低与UFS交互频次,从而降低整体存储网络延时

CV2:对单个文件而言,“分片读取”变“一次读取”

通过对Pytorch框架接口和模块的调研,如果使用 OpenCV方式读取文件可以用2个方法, cv2.imread和cv2.imdecode。

默认一般会用cv2.imread方式,读取一个文件时会产生9次lseek和11次read,而对于图片小文件来说多次lseek和read是没有必要的。cv2.imdecode可以解决这个问题,它通过一次性将数据加载进内存,后续的图片操作需要的IO转化为内存访问即可。

两者的在系统调用上的对比如下图:

我们通过使用cv2.imdecode方式替换客户默认使用的cv2.imread方式,单个文件的总操作耗时从12ms下降到6ms。但是内存无法cache住过大的数据集,不具备任意规模数据集下的训练,但是整体读取性能还是提升明显。使用cv2版本的benchmark对一个小数据集进行加载测试后的各场景耗时如下(延迟的非线性下降是因为其中包含GPU计算时间):

PIL:优化dataloader元数据性能,缓存文件句柄

通过PIL方式读取单张图片的方式,Pytorch处理的平均延迟为7ms(不含IO时间),单张图片读取(含IO和元数据耗时)平均延迟为5-6ms,此性能水平还有优化空间。

由于训练过程会进行很多个epoch的迭代,而每次迭代都会进行数据的读取,这部分操作从多次训练任务上来看是重复的,如果在训练时由本地内存做一些缓存策略,对性能应该有提升。但直接缓存数据在集群规模上升之后肯定是不现实的,我们初步只缓存各个训练文件的句柄信息,以降低元数据访问开销。

我们修改了Pytorch的dataloader实现,通过本地内存cache住训练需要使用的文件句柄,可以避免每次都尝试做open操作。测试后发现1w张图片通过100次迭代训练后发现,单次迭代的耗时已经基本和本地SSD持平。但是当数据集过大,内存同样无法cache住所有元数据,所以使用场景相对有限,依然不具备在大规模数据集下的训练伸缩性。

UFS server端元数据预加载

以上client端的优化效果比较明显,但是客户业务侧需要更改少量训练代码,最主要是client端无法满足较大数据量的缓存,应用场景有限,我们继续从server端优化,尽量降低整个链路上的交互频次。

正常IO请求通过负载均衡到达索引层时,会先经过索引接入server,然后到索引数据server。考虑到训练场景具有目录访问的空间局部性,我们决定增强元数据预取的功能。通过客户请求的文件,引入该文件及相应目录下所有文件的元数据,并预取到索引接入server,后续的请求将命中缓存,从而减少与索引数据server的交互,在IO请求到达索引层的第一步即可获取到对应元数据,从而降低从索引数据server进行查询的开销。

经过这次优化之后,元数据操作的延迟较最初能够下降一倍以上,在客户端不做更改的情况下,读取小文件性能已达到本地SSD盘的50%。看来单单优化server端还是无法满足预期,通过执行Pytorch的benchmark程序,我们得到UFS和本地SSD盘在整个数据读取耗时。

此时很容易想到一个问题:非Pytorch框架在使用UFS做训练集存储时,为什么使用中没有遇到IO性能瓶颈?

通过调研其他框架的逻辑发现:无论是MXNet的rec文件,Caffe的LMDB,还是TensorFlow的npy文件,都是在训练前将大量图片小文件转化为特定的数据集格式,所以使用UFS在存储网络交互更少,相对Pytorch直接读取目录小文件的方式,避免了大部分网络上的耗时。这个区别在优化时给了我们很大的启示,将目录树级别小文件转化成一个特定的数据集存储,在读取数据做训练时将IO发挥出最大性能优势。

优化方向二:目录级内的小文件转换为数据集,最大程度降到IO网络耗时

基于其他训练框架数据集的共性功能,我们UFS存储团队赶紧开工,几天开发了针对Pytorch框架下的数据集转换工具,将小文件数据集转化为UFS大文件数据集并对各个小文件信息建立索引记录到index文件,通过index文件中索引偏移量可随机读取文件,而整个index文件在训练任务启动时一次性加载到本地内存,这样就将大量小文件场景下的频繁访问元数据的开销完全去除了,只剩下数据IO的开销。该工具后续也可直接应用于其他AI类客户的训练业务。

工具的使用很简单,只涉及到两步:

  • 使用UFS自研工具将Pytorch数据集以目录形式存储的小文件转化为一个大文件存储到UFS上,生成date.ufs和index.ufs。
  • 使用我方提供Folder类替换pytorch原有代码中的torchvision.datasets.ImageFolder数据加载模块(即替换数据集读取方法),从而使用UFS上的大文件进行文件的随机读取。只需更改3行代码即可。

20行:新增from my_dataloader import *

205行:train_dataset = datasets.ImageFolder改为train_dataset = MyImageFolder

224行:datasets.ImageFolder改为MyImageFolder

通过github上Pytorch测试demo对imagenet数据集进行5、10、20小时模拟训练,分别读取不同存储中的数据,具体看下IO对整体训练速度的影响。(数据单位:完成的epoch的个数)

测试条件:

GPU服务器:P404物理机,48核256G,数据盘800G6 SATA SSD RAID10

SSHFS:X86物理机32核/64G,数据盘480G*6 SATA SSD RAID10

Demo:https://github.com/pytorch/examples/tree/master/imagenet

数据集:总大小148GB、图片文件数量120w以上

通过实际结果可以看出: UFS数据集方式效率已经达到甚至超过本地SSD磁盘的效果。而UFS数据集转化方式,客户端内存中只有少量目录结构元数据缓存,在100TB数据的体量下,元数据小于10MB,可以满足任意数据规模,对于客户业务上的硬件使用无影响。

UFS产品

针对Pytorch小文件训练场景,UFS通过多次优化,吞吐性能已得到极大提升,并且在后续产品规划中,我们也会结合现有RDMA网络、SPDK等存储相关技术进行持续优化。详细请访问:https://docs.ucloud.cn/storage_cdn/ufs/overview

本文作者:UCloud 解决方案架构师 马杰

欢迎各位与我们交流有关云计算的一切~~~

查看原文

赞 0 收藏 0 评论 0

认证与成就

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

擅长技能
编辑

(゚∀゚ )
暂时没有

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

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