UCloud云计算

UCloud云计算 查看完整档案

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

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

个人动态

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

1TB每日仅需6元!USnap磁盘快照服务全新上线,精确到秒级恢复

在企业数字化转型的浪潮下,数据正成为企业核心资产甚至“命门”,数据安全的重要性不言而喻。可是即便企业对数据安全高度重视,几乎每年还是会发生震撼业界的数据丢失大事件:比如2017年5月“永恒之蓝”勒索病毒爆发事件、2018年7月某企业公有云数据丢失事件以及2020年2月某公司运维删库的事件。导致这些事件的原因或是“外有强敌,内有忧患”,或是企业在公有云上的业务只做单点部署而忽视了潜在的数据安全风险。可见,数据安全真正落地的难度非常大,这是一个系统性工程。

作为一家中立的云计算公司,UCloud深刻理解用户对数据安全的重视,一直将用户的数据安全防护放在首位,在2015年推出了为云主机磁盘提供持续数据保护(CDP)的数据方舟(UDataArk),支持最小精确到秒级的恢复,针对数据删除或者丢失,能够最大程度的挽回数据。数据方舟已经在多个数据安全案例中得到应用,并得到了众多用户的认可。

近些年,随着用户高性能存储场景的需求增多,SSD云盘和RSSD云盘成为主流选择, 但由于数据方舟主要针对本地盘及普通云盘的备份,SSD云盘和RSSD云盘缺乏高效的备份手段成为用户痛点。为此我们推出了磁盘快照服务(USnap)USnap基于数据方舟CDP技术并进一步升级,以更低的成本为全系列云盘(普通/SSD/RSSD)提供了数据备份功能,当用户为一块云盘开启磁盘快照服务后,该磁盘不仅可以获得对应的手动快照额度,还能获得最近3日连续数据自动备份功能。

在线实时自动备份,可精确到秒级

USnap备份时无需暂停业务或停止磁盘读写,不影响线上业务,不损耗磁盘I/O性能。USnap不仅提供一定的手动快照额度,还为用户提供了最近3日内的连续数据自动备份,支持恢复到12小时内任意一秒、24小时内的任意整点以及3天内的任意零点。用户无需手动制作快照,也无需预设数据备份策略,即可获得最小精确到秒级的数据备份。对于部分用户对自动备份的时间范围有着更长的需求,我们还提供了自定义自动备份时间范围的增值服务,用户可以设置秒级、小时级、天级的保护范围,线上我们已经为某些用户提供了最长达到30天的自动备份服务。

异构数据备份系统,数据安全升级

USnap使用独立的集群进行数据备份,与云盘集群异构。即使遭遇云盘集群出现故障而导致数据丢失的极端事件,用户仍能从备份数据集群中恢复数据,避免了类似某企业在公有云的业务只做了单点部署,在遭遇了“黑天鹅”后出现数据完全丢失的惨痛教训。而且备份数据集群没有对外暴露数据删除接口,即便USnap服务被关闭,备份数据仍然会保留3天,如果出现类似某公司的运维删库事件,用户可以更快更方便的恢复数据。

备份使用方式灵活,满足多场景需求

用户可以在线开启USnap,无需停止业务。当用户使用USnap的手动备份或自动备份恢复磁盘时,数据会恢复到一块新的磁盘上,如果恢复后用户反悔,可以快速取回恢复前的数据。用户还可以通过克隆的方式,从USnap的手动备份或自动备份中创建出一块新的磁盘,方便查看备份数据,且克隆的数据源为备份数据集群,完全不影响当前的虚拟机运行。

自研存储引擎优化,降低用户备份成本

虽然CDP产品完全打破了传统备份周期概念,消除了备份窗口的束缚,但是备份成本较高始终是一个痛点。USnap全面升级了数据方舟底层架构,引入了更加高效数据压缩算法,并且自研了相关数据重删技术,大大降低了数据备份成本。相对于数据方舟产品,USnap的价格直降50%,低至0.2元/GB/月,保护核心的数据资产,1TB每日只需6元!

USnap典型应用场景

1、容灾备份

利用快照定期备份重要的业务数据,以应对误操作、攻击或病毒等导致的数据丢失风险。

2、数据快速恢复

在更换操作系统、升级应用软件或迁移业务数据等重大操作前,创建一份或多份快照。若在变更操作过程中出现任何问题,可通过已创建的快照及时恢复业务数据。

3、数据开发

通过创建生产数据快照,为数据挖掘、报表查询和开发测试等应用提供近实时的真实生产数据。

大数据时代,数据是企业的核心生产要素,USnap是为保障数据安全构筑的一道重要防线:自动的备份策略,可以规避由于用户安全意识缺失、制度缺失带来的数据风险;最小精确到秒级的数据备份点,在出现数据破坏和丢失时能够最大程度的挽回数据;更低的备份成本,让用户享受更先进技术带来的价格红利。现在USnap已经在北京、上海、广州、香港、华盛顿及法兰克福地域全面上线,为您的数据保驾护航!

查看原文

赞 0 收藏 0 评论 0

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

拥抱云原生,基于eBPF技术实现Serverless节点访问K8S Service

Serverless容器的服务发现

2020年9月,UCloud上线了Serverless容器产品Cube,它具备了虚拟机级别的安全隔离、轻量化的系统占用、秒级的启动速度,高度自动化的弹性伸缩,以及简洁明了的易用性。结合虚拟节点技术(Virtual Kubelet),Cube可以和UCloud容器托管产品UK8S无缝对接,极大地丰富了Kubernetes集群的弹性能力。如下图所示,Virtual Node作为一个虚拟Node在Kubernetes集群中,每个Cube实例被视为VK节点上的一个Pod。

然而,Virtual Kubelet仅仅实现了集群中Cube实例的弹性伸缩。要使得Cube实例正式成为K8s集群大家庭的一员,运行在Cube中的应用需要能利用K8s的服务发现能力,即访问Service地址。

为什么不是kube-proxy?

众所周知, kube-proxy为K8s实现了service流量负载均衡。kube-proxy不断感知K8s内Service和Endpoints地址的对应关系及其变化,生成ServiceIP的流量转发规则。它提供了三种转发实现机制:userspace, iptables和ipvs, 其中userspace由于较高的性能代价已不再被使用。

然而,我们发现,直接把kube-proxy部署在Cube虚拟机内部并不合适,有如下原因:

1 、kube-proxy采用go语言开发,编译产生的目标文件体积庞大。以K8s v1.19.5 linux环境为例,经strip过的kube-proxy ELF可执行文件大小为37MB。对于普通K8s环境来说,这个体积可以忽略不计;但对于Serverless产品来说,为了保证秒起轻量级虚拟机,虚拟机操作系统和镜像需要高度裁剪,寸土寸金,我们想要一个部署体积不超过10MB的proxy控制程序。

2 、kube-proxy的运行性能问题。同样由于使用go语言开发,相对于C/C++和Rust等无gc、具备精细控制底层资源能力的高级语言来说,要付出更多的性能代价。Cube通常存在较细粒度的资源交付配额,例如0.5C 500MiB,我们不希望kube-proxy这类辅助组件喧宾夺主。

3 、ipvs的问题。在eBPF被广为周知之前,ipvs被认为是最合理的K8s service转发面实现。iptables因为扩展性问题被鞭尸已久,ipvs却能随着services和endpoints规模增大依然保持稳定的转发能力和较低的规则刷新间隔。

但事实是,ipvs并不完美,甚至存在严重的问题。

例如,同样实现nat , iptables是在PREROUTING或者OUTPUT完成DNAT;而ipvs需要经历INPUT和OUTPUT,链路更长。因此,较少svc和ep数量下的service ip压测场景下,无论是带宽还是短连接请求延迟,ipvs都会获得全场最低分。此外,conn_reuse_mode的参数为1导致的滚动发布时服务访问失败的问题至今(2021年4月)也解决的不太干净。

4 、iptables的问题。扩展差,更新慢,O(n)时间复杂度的规则查找(这几句话背不出来是找不到一份K8s相关的工作的), 同样的问题还会出现在基于iptables实现的NetworkPolicy上。1.6.2以下iptables甚至不支持full_random端口选择,导致SNAT的性能在高并发短连接的业务场景下雪上加霜。

eBPF能为容器网络带来什么?

eBPF近年来被视为linux的革命性技术,它允许开发者在linux的内核里动态实时地加载运行自己编写的沙盒程序,无需更改内核源码或者加载内核模块。同时,用户态的程序可以通过bpf(2)系统调用和bpf map结构与内核中的eBPF程序实时交换数据,如下图所示。

编写好的eBPF程序在内核中以事件触发的模式运行,这些事件可以是系统调用入出口,网络收发包的关键路径点(xdp, tc, qdisc, socket),内核函数入出口kprobes/kretprobes和用户态函数入出口uprobes/uretprobes等。加载到网络收发路径的hook点的eBPF程序通常用于控制和修改网络报文, 来实现负载均衡,安全策略和监控观测。

cilium的出现使得eBPF正式进入K8s的视野,并正在深刻地改变k8s的网络,安全,负载均衡,可观测性等领域。从1.6开始,cilium可以100%替换kube-proxy,真正通过eBPF实现了kube-proxy的全部转发功能。让我们首先考察一下ClusterIP(东西流量)的实现。

ClusterIP的实现


无论对于TCP还是UDP来说,客户端访问ClusterIP只需要实现针对ClusterIP的DNAT,把Frontend与对应的Backends地址记录在eBPF map中,这个表的内容即为后面执行DNAT的依据。那这个DNAT在什么环节实现呢?

对于一般环境,DNAT操作可以发生在tc egress,同时在tc ingress中对回程的流量进行反向操作,即将源地址由真实的PodIP改成ClusterIP, 此外完成NAT后需要重新计算IP和TCP头部的checksum。

如果是支持cgroup2的linux环境,使用cgroup2的sockaddr hook点进行DNAT。cgroup2为一些需要引用L4地址的socket系统调用,如connect(2), sendmsg(2), recvmsg(2)提供了一个BPF拦截层(BPF_PROG_TYPE_CGROUP_SOCK_ADDR)。这些BPF程序可以在packet生成之前完成对目的地址的修改,如下图所示。

对于tcp和有连接的udp的流量(即针对udp fd调用过connect(2))来说, 只需要做一次正向转换,即利用bpf程序,将出向流量的目的地址改成Pod的地址。这种场景下,负载均衡是最高效的,因为开销一次性的,作用效果则持续贯穿整个通信流的生命周期。

而对于无连接的udp流量,还需要做一次反向转换,即将来自Pod的入向流量做一个SNAT,将源地址改回ClusterIP。如果缺了这一步操作,基于recvmsg的UDP应用会无法收到来自ClusterIP的消息,因为socket的对端地址被改写成了Pod的地址。流量示意图如下所示。

综述,这是一种用户无感知的地址转换。用户认为自己连接的地址是Service, 但实际的tcp连接直接指向Pod。一个能说明问题的对比是,当你使用kube-proxy的时候,在Pod中进行tcpdump时,你能发现目的地址依然是ClusterIP,因为ipvs或者iptables规则在host上;当你使用cilium时,在Pod中进行tcpdump,你已经能发现目的地址是Backend Pod。NAT不需要借助conntrack就能完成,相对于ipvs和iptables来说,转发路径减少,性能更优。而对比刚才提到的tc-bpf,它更轻量,无需重新计算checksum。

Cube的Service服务发现


Cube为每个需要开启ClusterIP访问功能的Serverless容器组启动了一个叫cproxy的agent程序来实现kube-proxy的核心功能。由于Cube的轻量级虚拟机镜像使用较高版本的linux内核,cproxy采用了上述cgroup2 socket hook的方式进行ClusterIP转发。cproxy使用Rust开发,编译后的目标文件只有不到10MiB。运行开销相比kube-proxy也有不小优势。部署结构如下所示。

以下是一些测试情况对比。我们使用wrk对ClusterIP进行2000并发HTTP短连接测试,分别比较svc数量为10和svc数量为5000,观察请求耗时情况(单位ms)。

结论是cproxy无论在svc数量较少和较多的情况下,都拥有最好的性能;ipvs在svc数量较大的情况下性能远好于iptables,但在svc数量较小的情况下,性能不如iptables。svc数量=10

svc数量=10

svc数量=5000

后续我们会继续完善基于eBPF实现LoadBalancer(南北流量)转发,以及基于eBPF的网络访问策略(NetworkPolicy)。

UCloud容器产品拥抱eBPF


eBPF正在改变云原生生态, 未来UCloud容器云产品 UK8S与Serverless容器产品Cube将紧密结合业内最新进展,挖掘eBPF在网络,负载均衡,监控等领域的应用,为用户提供更好的观测、定位和调优能力。


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

查看原文

赞 0 收藏 0 评论 0

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

UDTS上线数据集成服务,汇聚多源数据帮助企业高效分析决策

背景

由于不同业务的数据存储和应用需求不同,企业通常会将不同业务产生的数据分别存储在独立的数据库中。随着业务架构的不断调整,以及受开发过程的影响,原先分开存储的数据库逐渐暴露出一些问题:1、数据分散在不同的数据库实例上,形成独立的数据孤岛,难以实现数据的聚合分析。传统的通过MySQL主从关系同步数据的方式,在MySQL5.7版本之前无法建立多对一的增量同步关系。MySQL5.7版本虽然推出了多源复制功能,但功能单一,无法进行不同库表间的映射,且配置过程复杂,当源数量较多时容易出错。2、数据库分库分表之后存在多个数据库实例,难以再合并到统一的库表中。传统的数据库迁移工具无法处理合并过程中产生的数据冲突问题。3、数据量越来越大,在不影响业务的前提下很难调整数据库架构。在线修改字段类型或者字段名,要么受限于数据库功能,要么可能给业务带来较大影响而难以调整。

为此,UDTS在数据传输的基础上,增加了数据集成服务,可实现多个数据源合并,打通数据孤岛以获得数据的统一视图,方便业务进行数据分析决策; 助力企业灵活调整业务架构,优化现有的数据库服务; 快速实现分库分表合并、自定义冲突处理策略、方便业务构建数据看板。

一站式数据集成解决方案

多源数据聚合

针对数据库分散,难以聚合的问题。UDTS推出数据集成服务,可轻松帮助用户完成多源聚合。单个任务可支持多达 10 个数据源聚合,同时可支持不同类型网络环境下的数据源,包括外网、内网以及专线。

举例: 假设现在有两个数据源,分别是 10.10.10.100:3306 和 10.10.10.120:3306 ,聚合模式如下图所示 :

考虑到大多数据源都承载着在线业务,为了避免多源聚合对线上业务的影响,UDTS数据集成服务还支持针对每个数据源独立限速。

数据库合库合表

数据库合库合表通常存在以下难点:

  • 数据库实例分散;
  • 数据可能存在冲突;
  • 对不同的数据库需要不同的数据冲突解决方法。

针对以上这些问题,UDTS数据集成服务在多源聚合的基础上,提供以下方式解决:

1、自定义基础数据

  • 对于每个数据源,都可指定“是否保留目标库的原数据”,如果选择“是”,在导入数据表时,会保留原有数据库表定义及数据。
  • 而如果选择了不保留数据,则在导入数据时,会根据映射规则先清理对应的表及其数据。

2. 自动解决数据冲突

在创建任务时可对每个数据源独立定义数据冲突解决策略,在数据集成时,可根据自己的数据冲突解决策略来处理冲突数据。当前提供“保留”与“替换”两种策略。

  • 保留: 当数据发生冲突时,保留目标库中的原数据,而丢弃当前数据。

当使用保留规则时,导入数据使用 INSERT IGNORE INTO , 比如 INSERT IGNORE INTO table VALUES(1, "name", 18) ,当有重复数据时,保留原有的数据,新插入的数据会被忽略。

  • 替换: 当发生数据冲突时,使用新的数据替换目标库中原来的数据。

当使用替换规则时,导入数据使用 REPLACE INTO ,比如 REPLACE INTO table VALUES(1, "name", 18) ,老的数据将会被新数据覆盖,集成任务中有多个子任务(多个源往同一个目标数据库同步)时,需要注意顺序。

数据库架构调整

在开发的过程中,难免会遇到数据库改名、表变更等问题,但等到数据库架构要调整的时候,才发现累积了一堆“陈年旧债”。通过UDTS数据集成服务的全量+增量,不仅可以将全量数据按映射规则迁移到目标库中,还可动态实现增量数据的库表名称的映射。

避免用户对数据源锁库锁表的担忧,UDTS数据集成服务还提供了No Lock模式,在此模式下数据集成服务运行的过程中不会对源库表进行任何的锁操作。

数据集成服务案例

1、数据脱敏

某教育企业,使用UDTS数据集成服务,将数据脱敏处理后,再交由内部其它部⻔进行数据分析,提取数据的有效价值。既避免了敏感数据泄漏风险,又帮助企业更快、更精准的决策。

2、数据合并

某金融企业使用UDTS数据集成服务,将前期拆分后的数据库合并,方便进行后续的业务开发和分析。

3、架构调整 某交友软件为了适应新的架构,通过UDTS数据集成服务对数据库 db 和 table 进行了重新调整,适应了新的环境。

架构的调整不仅仅是对现有数据库的改名,还依赖于存量数据的变更、增量数据的同步、业务的回滚等。

总结

总的来说,UDTS数据集成服务带给企业的价值主要体现在以下三个方面:

  • 多源数据聚合,数据合并,构建 BI数据看板,提取数据价值;
  • 同构数据整合,自动处理数据冲突。
  • 数据库架构在线调整,提升业务整体性能。

UDTS数据集成服务目前正在免费公测期,欢迎前往控制台开启体验~

查看原文

赞 0 收藏 0 评论 0

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

打通混合云网络孤岛,EBN助力企业灵活构建云骨干网

据信通院调查报告显示,国内企业采用混合云的比例逐年攀升,其中超过60%的企业使用了不同公有云或私有云部署业务,因此同厂商公有云多地域互连、不同厂商公有云互连、公有云与用户私有云 / 本地IDC的互连成为企业使用混合云方案时的刚需。


传统的做法是,用户首先向基础运营商申请两个区域之间的互连线路,然后经过运营商线路勘查、施工、开通后方可投入使用。不仅线路成本较高,且开通周期长达数月,难以满足互联网业务高速发展变化的需求。企业骨干网(以下简称EBN)是UCloud混合云网络推出的新一代网络互通产品,基于UCloud自有骨干网3.0的迭代,可帮助企业快速实现不同地域的多云网络互联,构建智能调度、安全可靠、高速传输的企业骨干网。

全球节点任意接入,支持二三层网络互通

依托UCloud全球DCN网络以及专线资源,UCloud自有骨干网可为用户提供全球范围的就近接入,实现端到端网络稳定传输,解决跨域业务互访丢包和高延迟问题。还能为用户提供基于本地专线和最后一公里互联网接入,实现用户的混合组网能力。EBN基于UCloud自有骨干网的迭代升级,用户只需通过控制台自助化操作,即可快速实现多接入节点、多地域、多网元之间的互通,同时支持二层和三层的互通方式,满足不同用户的接入需求。在二层互通模式下,EBN提供以太网层的点到点互通(用户可自行规划网络架构,管理用户内部路由),使用VXLAN/EVPN-MPLS封装,通过VNI/EVPN实现多租户之间的隔离。

在三层互通模式下,EBN提供IP层的多点互联(使用UCloud提供的最低时延、最低成本、应急通道等选路规则快速实现三层网络打通),基于SR-TE架构,通过L3VPN技术实现三层网络多租户隔离。

除此之外,EBN企业骨干网相比自建混合云网络,还具备高可用、智能调度、低网络开销等优势:

  • 高可用:专线资源提供物理层带环保护,同时通过Internet线路提供备份能力;
  • 智能调度:支持按照链路延迟、成本、带宽利用率等多种模式的灵活智能流量调度;
  • 低网络开销:基于SR-TE技术,降低网络开销,小包场景下可提升30%传输效率。

EBN典型使用场景

1、基于多业务的网络隔离

用户创建的每一张EBN网络都彼此隔离,相互之间不互通,即使业务都跑在同一条专线上:比如说测试环境与业务环境的网络要实现网络隔离,但是在资源建设时并不希望从物理线路上增加成本的投入,使用EBN产品创建两张相互独立的骨干网,绑定根据VLAN标签区分好的接入网元;针对每一张互通的EBN网络设计相应的带宽流控,在不增加物理资源成本的情况下,可以实现多业务的分层切片和网络隔离。

2、基于多接入节点的网络互通

用户接入点随着业务的发展将不断丰富,以前的传统互联方式在构建互联互通时,需要每一个接入点之间都两两互通,在节点增多至n个时,需要连接的互通线路即为:n(n-1)/2;这无疑增加了较多的接入成本和运维投入;EBN产品支持对所有的接入节点实现full mesh互通,无需再操作两两节点的打通,只要将VBS与对应的EBN绑定即可实现网元之间的全互通。

3、基于成本优化及高可靠的网络选路

在用户实际线路接入后,因业务需求的不同,对网络质量的要求也不尽相同,如何能够更加匹配用户的业务,对不同的业务优化不同的选路方式也成为了用户使用混合云网络产品的关注点。在UCloud骨干网3.0升级的背景下,该需求作为优先功能被采纳到整体的设计中,通过对不同业务进行染色实现业务灵活选择不同的路径进行转发。EBN产品支持按照最优成本、最短路径、最低延时等选路规则,提升了用户网络的灵活性和可靠性。

EBN产品架构和技术实现

一、EBN产品架构

如图所示,EBN支持的接入网元因互通方式的不同,略有差异,分别支持虚拟边界交换机(以下简称为VBS)和虚拟边界路由器(以下简称为VBR)的接入;VBS、VBR均与用户边界设备互联,实现用户接入UCloud网络。

在实现EBN产品功能时,对于实现逻辑的技术选型,UCloud混合云网络做了如下的技术选型对比,最终确定实现二层和三层打通的技术分别为VXLAN/EVPN与SR-MPLS。

二、技术选型

二层传输

三层传输

三、技术框架

二层传输

VXLAN网络架构

整体架构分为两层,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网络。

EVPN-MPLS网络架构在新一代骨干网3.0架构中采用了BGP-EVPN协议作为L2网络的控制平面;EVPN网络和BGP/MPLS IP VPN网络相似,为了实现各站点二层互通,骨干网上的PE设备建立EVPN实例并接入各站点CE设备,同时各PE建立EVPN邻居关系,因此PE设备可以从各个站点学习到MAC路由,PE通过EVPN特有的路由类型将自己从CE学到的MAC路由图通告给其他站点,从而实现用户二层网络互通需求。

三层传输

控制平面和转发平面规划

1、智能控制器

主要包括转发面数据采集,智能路径计算、统一策略下发、流量监控以及自动化部署等,实现如下功能:

  • 快速故障响应;
  • 快速实现故障域隔离;
  • 快速自定义调优路径和智能路径计算;
  • 客户流量秒级监控。

2、SR-TE控制面主要通过MP-BGP的L3VPN和BGP-EVPN 的L2VPN实现L2和L3接入场景,数据包外层标签通过启用SR功能分发,内层标签通过VPNv4和EVPN实现分发。

3、转发面骨干网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转发。

整机架构包括智能控制器、骨干边界转发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设备,提供用户混合组网能力。

总结

在混合云的趋势下,EBN产品可作为企业IT基础设施的网络中枢,在UCloud全球覆盖的25个地域进行任意接入,同时利用智能调度系统实现客户混合云网络灵活部署和业务编排。

查看原文

赞 0 收藏 0 评论 0

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

NVIDIA DPU公开课下周开讲:听大牛讲解DPU在裸金属云中的技术和价值

去年10月 GTC 大会上,NVIDIA 推出了面向数据中心的 BlueField 系列数据处理器 DPU。DPU 集多核 Arm CPU、高性能网络接口、各种灵活和可编程的加速引擎于一体,能提升网络、存储和安全性能,有效防止数据泄露和网络攻击。经过优化的单个 BlueField-2 DPU 能够提供相当于消耗125个 CPU 内核所提供的数据中心服务能力,可以将数据中心关键的网络、存储、安全等任务从 CPU 上卸载下来,从而释放宝贵的 CPU 资源,降低 CPU 内核的负载,以便用于更多其他程序的运行。

针对 DPU 的应用开发,NVIDIA 还提供了DOCA 软件开发工具包,开发者可以借助DOCA SDK 在 DPU 加速的数据中心基础设施服务上,构建软件定义、硬件加速网络、存储、安全和管理应用程序。

去年10月27日,智东西公开课就联合 NVIDIA 推出了「数据中心处理器 - DPU 公开课」 ,并邀请到 NVIDIA 网络事业部亚太区市场开发高级总监宋庆春老师,从DPU的架构创新、在安全、存储和云场景中的应用、以及基于DOCA SDK的应用开发指南以及DPU的未来发展路线等方面进行了系统解读,累计收看人次3300+,受到了大家的广泛关注。

其实早在2018年,DPU 还未正式发布之前,云计算服务提供商 UCloud 便已经与 NVIDIA 合作,探索基于 NVIDIA BlueField DPU 的高性能裸金属物理云方案,并在去年成功上线了裸金属物理云1.0和2.0两款产品,其中:

裸金属云1.0通过 DPU 集成的多核 ARM CPU 将物理云基础架构软件从x86迁移到 DPU 中,满足了物理云客户高带宽、低延时的网络需求,并使用 NVIDIA ASAP² 技术,将OpenvSwitch Kernel 和 GRE 隧道硬件卸载到 DPU,实现了物理云用户无缝接入 NVGRE Overlay 虚拟网络,UCloud 也是首家应用此技术的公有云厂商。目前 UCloud 裸金属物理云1.0 已经在大数据、数据库等场景中得到了广泛的应用。

裸金属云2.0使用 NVIDIA BlueField DPU 提供的 NVMe SNAP 功能,将 UCloud 的云存储产品 RSSD 呈现为本地的 NVMe 系统盘和数据盘,为物理云客户提供了更灵活易用的云盘存储服务,通过 BlueField DPU 成熟的RDMA能力,UCloud 的 RSSD 云盘的性能也得到了很大的提升。

基于 DPU 的裸金属云打破了传统物理机带宽不足、部署复杂、不支持计算与存储分离等诸多限制,可以为用户提供高吞吐、低延迟的物理网络和虚拟化网络,同时兼顾了性能和灵活性。

为了更好的让大家了解 DPU 及其在 UCloud 裸金属云中的应用现状和最新进展,3月23日晚7点,智东西公开课策划推出 「NVIDIA DPU 公开课」,主题为《DPU及其在裸金属云中的关键技术和价值》,由 NVIDIA 网卡首席架构师陈志辉、UCloud 资深技术专家马彦青共同主讲。

陈志辉老师将从 DPU 的特性及未来产品路线、DPU 软件开发套件 DOCA,以及 ASAP² 硬件卸载、VirtIO-Net Emulation、NVMe/VirtIO-BLK SNAP 等针对裸金属云的关键技术进行深入讲解;

马彦青老师将从裸金属云的发展现状切入、系统解读基于DPU的裸金属云1.0/2.0的技术架构、应用案例,以及基于下一代虚拟化技术裸金属云3.x的研发计划和最新进展。

专 场 内 容

主题一:DPU及其在裸金属云中的关键技术

讲师:NVIDIA网卡首席架构师陈志辉

提纲:

1、DPU特性及产品路线图

2、DPU软件开发套件DOCA

3、DPU针对裸金属云的的关键技术

主题二:DPU在裸金属云中的关键价值

讲师:UCloud资深技术专家马彦青

提纲:

1、裸金属云发展现状

2、基于DPU的高性能裸金属云技术架构

3、DPU裸金属云应用案例

4、展望下一代虚拟化技术-裸金属云3.x

讲 师 介 绍

陈志辉, 英伟达网卡首席架构师,负责网络产品线对终端用户的技术支持团队。2003年毕业于中国科技大学计算机系,获系统体系结构方向博士学位。先后就职于英特尔,Mellanox和英伟达,从事的方向包括计算机系统性能优化,解决方案开发,客户技术支持等。

马彦青,UCloud资深技术专家,主攻研发物理云和虚拟化技术,先后推出裸金属物理云1.0、2.0产品,现主要负责物理云产品、裸金属3.x产品设计规划和云游戏研发工作。

直 播 信 息

时间:3月23日晚7点

地点:智东西公开课小程序

入群方式

为了便于大家学习和交流,NVIDIA DPU公开课还设有主讲群,并将邀请讲师入群。此外,加入主讲群,还能提前获得课件,结识更多技术牛人。

欢迎扫描下方二维码或者海报上的二维码,添加小助手瑞奇进行申请,备注“姓名-公司/学校-职位/专业”的朋友将优先审核通过。

查看原文

赞 0 收藏 0 评论 0

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

跨云迁移过程中的数据一致性实践

随着互联网业务发展和对容灾的需求,以及对访问加速、多供应商成本控制等要求,互联网公司通过跨云部署和迁移来更好的控制成本逐渐成为刚需,跨云部署和迁移也就成为运维圈子里的一个热门话题,而在此过程中,对运维和研发最头痛就是数据的迁移和分布。

粤语中有一句谚语“上屋搬下屋,搬洒一箩谷”,意思是在各种各样的搬动过程中,或多或少都会伴随一些资产的流失,这对于互联网业务来说是难以接受的。

通过对最近几次客户的多云部署进行总结,过程中存在的挑战有三点:

首先是数据完整性和一致性挑战。

其次是时效性,迁移窗口期相对有限。

再者是依赖性和各种访问关系。

在大多数实际环境中都存在着应用依赖性,如何万千关系中理顺每条访问关系也是让人望而却步的事情。

跨云迁移涉及到的资源一般可以分成三大类:

第一类是EIP、VPC、负载均衡和NAT网关这类网络服务,在跨云迁移的过程中这些都会发生变化,而且是无状态服务,配置并不复杂,对于这部分资源可以通过人工的方法对齐配置。

接下来是最为常见的云主机资源,这部分我们可以通过USMC服务器迁移工具来进行迁移,对于一些例如zookeeper的服务,也可以通过人手同步配置的方式来迁移。

而第三类就是包括数据库、文件存储和对象存储在内的一些存储服务,我们可以通过UDTS等工具进行迁移,而这正是本文所重点讨论的实践内容。

跨云迁移

在这些客户的多云部署和迁移过程中,如何在有限的业务暂停时间里,将大量数据进行迁移,并且保证数据一致,有了较多实践和沉淀。为给大家提供有效的借鉴意义,花了一些时间从实践总结了共性,将跨云迁移划分为三个阶段:数据同步阶段、数据规整阶段(清理测试产生脏数据)和数据割接阶段进行阐述。

  1. 数据同步阶段

数据同步阶段主要是需要解决两个问题,其中最主要的还是跨云迁移的核心,即将数据复制到新平台,并且让应用程序在新平台运行,其次就是利用真实数据对应用程序进行测试,确认应用程序在目标平台可以符合预期地运行。我们都知道数据可以分为结构化数据和非结构化数据,用来存储数据的方法众多,无法逐个深入分析,所以笔者在这里只提供一些最常见的存储组件的迁移实践,其它不同的存储组件各有不同,但也是可以参考这几个组件的迁移逻辑来处理的。

下面将分别讨论MySQL、文件存储和对象存储的数据同步方式。

1.1 MySQL同步

一般来说,我们认为对于MySQL的同步,只要存量数据和增量数据都能做到一致,那么整个数据库的同步就是一致的。

而常见的MySQL数据迁移方式有两种:一种是基于MySQL主从的方式,通过mysqldump记录下binlog位置,然后把这个binlog位置前的数据完整导出,恢复出一个备库,然后再从记录的binlog位置开始向主库追平增量数据。另一种就是UDTS工具,但总体上也是分为存量阶段和增量阶段,增量阶段的追及是将从存量同步发起的一瞬间开始往后的数据变化通过binlog的形式同步到目标库。

增量同步依靠binlog完成,这是MySQL主从同步的基础,是我们需要默认信任的数据一致性机制,所以反过来说,如果我们不信任MySQL的binlog机制,那么其它MySQL的数据一致性机制也是需要怀疑的,包括数据落地的fsycn()调用是否真正的把数据写入到磁盘和事务等等,这样就陷入了怀疑论了。当然我们最终需要以数据校验结果来确认数据是否一致。

简而言之,跨云迁移过程中MySQL的数据一致性主要就集中在存量数据的迁移如何保证一致。

【案例】

以近期的xx公司迁移到UCloud为例,其涉及数据库实例有数十个,并且由于应用依赖的原因需要进行整体迁移。在这案例中,如果采用mysqldump的方法,那么这数十个数据库都需要经过导出、传输、导入和配置主从这样的操作,给整个迁移任务增加了不少工作量。同时也正如很多商业智能应用需要将数据汇总用作分析,他们业务系统也有类似的汇总数据库,这种级联关系会让数据同步操作进一步复杂化。最终客户使用了UDTS作为跨云数据同步的解决办法,在保障数据一致的同时,DBA只需要提供两边数据库的连接和账号信息即可将数据同步任务托管,释放了精力去处理业务上的数据库工作需求。

1.1.1 数据同步

前面提到MySQL事务,在理解存量数据迁移过程中的数据一致性时,需要先了解InnoDB为代表的事务引擎和MyISAM代表的非事务引擎。使用MyISAM引擎的数据表确实没有很好的数据一致性确保手段,存量数据只能对数据表加读锁并迁移,在完成存量数据同步后,通过binlog追平,这样因为读锁会阻塞数据的写入,会导致业务的写入功能不可用,而且这一不可用的时间视表中数据体量而定。

幸而因为MyISAM的不灵活,实际互联网公司中已经很少使用MyISAM引擎了。而InnoDB引擎因为它支持事务和行级锁的特性,在数据同步过程中对业务的影响小很多,但也因此对数据一致性的保护方法也相对复杂,而这一套一致性保护方法,核心就在于基于连接session的事务隔离和基于MVCC的数据版本管理。

在存量数据同步启动的时候,数据迁移工具会在自己对数据库的连接session上设置事务隔离级别为REPEATABLE READ,自动提交设置关闭,并且启动一个事务。这个时候,只要这个session上的这个事务最终没有隐式或显式的提交,这个session里看到的数据就不再发生变化,这样就可以保证存量阶段的数据都是同步任务启动那个瞬间的数据,而不管其它session连接会对数据库做怎么的修改。之所以能做到这样,是因为使用了InnoDB引擎的表有三个隐藏列,分别是行ID DB_ROW_ID,行事务ID DB_TRX_ID和回滚指针DB_ROLL_PTR,同时在相同表空间内维护undo log。

对于insert操作,会在表空间内写入一行数据,记录DB_ROW_ID 和DB_TRX_ID,但DB_ROLL_PTR为null;对于update操作,则undo log是写入一行数据并且根据update语句更新字段数值,记录DB_ROW_ID 和DB_TRX_ID,同时DB_ROLL_PTR指向被修改前的数据行;至于delete操作,则复制数据到undo log中,记录数据删除位,并且将DB_ROLL_PTR指向原先数据。假设数据导出事务启动的同时,mysql上面还有多个活跃事务,这时候数据导出事务就是存量事务中DB_TRX_ID最新的一个,记为Tmax,而这些事务中最老的事务ID为Tmin,而从表空间中导出的每一行的数据为T,通过这些事务ID和一定的比较方法,就可以判断读出的数据对于数据导出任务是否应该保留。

如果T比Tmin还小,或者T小于Tmax且不属于数据导出事务启动时的任何活跃事务,说明这一行数据在数据导出前已经落地,如果还没有被删除则应该予以保留,而其他行则通过DB_ROLL_PTR从undo log中找到数据的上一版本,再通过上一版本的DB_TRX_ID再进行迭代判断。这一处理过程,就是InnoDB引擎的MVCC版本控制实现。

InnoDB的undo log和MVCC实现

1.1.2 数据校验

数据一致性的关键,除了数据同步过程中的一致性保障,更加简单直接的手段是数据校验,只要对比过数据是一致的,那才是真正的一致。MySQL数据校验的手段有很多,其中最经典的是pt-table-checksum。

pt-table-checksum会新建一个临时的checksum表,并且获取与主库有主从关系的所有从库信息。在校验工作时,工具会将该session的binlog格式设置为statement,这样是为了利用mysql的binlog机制,将主库上执行的sql语句同步到从库去。接着工具会以chunk为单位从主库中读取数据和计算校验,将校验结果写入checksum表,这个过程会在一个语句中完成,随后这个语句由于对checksum表进行修改,会被同步到从库并且被从库执行。这样从库也会在自己的checksum表写入校验值。这个时候工具再从库中把checksum值读出,就可以与主库的计算值进行对比。

pt-table-checksum的优势在于使用方便,在经历了多年迭代也有非常好的可靠性保证。但是它的技术限制也是明显,那就是要求被校验的两个库需要是主从关系,同时也要求数据表有索引,因为chunk大小的计算是通过索引完成的。

【案例】

以近期的xx公司迁移到UCloud为例,在数据同步的阶段由于数据库实例众多,需要减少DBA的工作负担而采用了UDTS来进行数据库迁移,但是这样就打破了源和目标库的主从关系,进而导致pt-table-checksum无法使用。当然实际上数据导出-传输-导入-配置主从这样的机械化操作可以通过制作脚本来解决,但是为了迁移而开发一套重用率不高的脚本代码并不明智。这时候sync_diff_inspector工具的优势就体现出来了。

sync_diff_inspector是TiDB团队为了方便用户在MySQL数据迁移到TiDB后对数据一致性进行检查的开源工具,它不要求被校验的两个数据库存在主从关系,也没有对数据表索引的要求,甚至允许源库和目标库有不同的库名和表名,只要有明确的映射,就可以对数据本身进行校验。同时,在sync_diff_inspector发现某一块数据存在差异的时候,会通过二分对比的办法,最终找到实际不一致的行,缩小了疑似不一致的数据范围。

虽然这种相对松耦合的环境下对数据进行校验,可能会出现记录下一些数据不一致,例如主库的某个写入还没有完全即时的同步到从库,这时候进行检查可能会存在数据差异,但是除非源库insert/delete/update操作非常频繁,否则一般期望工具检查发现的差异不会太多。这时候只需要针对检查报告中的少数差异做第二次的手工或脚本校验,就可以确认数据一致性。当然如果一致性检查工具发现有较多数据不一致,我们一是可以用检查工具生成的一致性修复脚本来修复一致性,也可以对通过对数据进行重新同步来完成。

需要留意的是,pt-table-checksum和sync_diff_inspector都是对实体数据进行校验的工具,在数据量较大的情况下校验操作会相对缓慢,不适合在割接时间窗口中操作。在实际项目中笔者测得一个500G的数据库的完整校验耗时大约28小时。在割接时间窗口中,一般通过select max(id)或者select count(id)对数据进行简单对比。

1.2 文件存储同步

1.2.1 文件同步

相比于MySQL,文件作为一种非结构化的存储方式,迁移方法相对较少,也没有太多的数据一致性保障方法。与此同时,海量小文件的处理效率有限一直都是技术难题。

一般来说,文件存储的方式一般是硬盘本地存储或者基于NFS协议的存储服务,这两种存储服务中NFS存储的同步会更困难一些。单个文件的同步是简单的,将文件复制到目标空间然后再对文件计算md5校验和,只要两边的数据是一致的就行。难点在于获知文件是否有发生变化。在linux kernel中可以利用 inotify机制了解到本机对文件的修改动作。

inotify应用在启动的时候除了初始化监听和创建事件队列以外,还会在文件系统操作的函数中加入inotify hook函数以将文件系统事件通知到inotify系统中,这些都是操作系统内核中的系统调用。所以对于NFS而言inotify就失效了,因为相关调用都是本机环境中的系统调用而没有经过网络,挂载了同一个NFS的多台主机没有机制了解对方在什么时候对文件进行了操作。

当然也有一些实现了分布式锁的文件系统,例如vmware的vmfs和oracle的ocfs,可以共享文件系统数据的同时,通过锁机制来实现操作系统对文件变化的感知,但这是另一个故事了。

所以这时候,从业务中对出现变化的文件进行记录就很有必要,因为实际上所有对文件的增、删、改都是业务所需的操作行为。所以在数据同步阶段,我们依然通过rsync或类似方法来同步数据,并且通过业务日志记录发生了变化的文件,最后在割接阶段解析业务日志,将出现过变化的文件做最后的增量同步,从而实现数据追平。典型的组件可以参考FastDFS。FastDFS实现了类似binlog的方式,来记录每个storaged接受到哪些文件的更新,是哪种更新操作。在启动storaged之后,就可以实现自动读取其它同副本关系的storaged的数据来恢复。例如大C表示源创建,小c表示创建副本,大A表示源追加,小a标识副本追加,大D表示源删除,小d表示副本删除等等。

实际生产环境中的fastdfs binlog

1.2.2 文件校验

文件的校验,这里会涉及到存储静默错误的问题。我们回忆硬盘坏道这个概念,就会发现硬盘自己也不知道某个扇区目前状态是否良好,需要专门进行扫描才能确认。一个扇区写了数据,在长久的运行中这一扇区成为了坏道导致不能读出数据,这时候应用不读取就不知道底层数据出现问题,这就是静默错误。

要解决静默错误的唯一办法是全链路数据校验:

在数据上传前,确认数据正常,生成校验和;

上传到某个存储服务之后,存储服务存储文件并且记录这个文件的校验和;

定期对数据进行巡检,重新计算文件校验和并且和记录值比较;

取出数据时,也对数据进行校验和比较,这样才能保证文件数据一致。

因此从技术层面来说建议从一开始就使用带有全链路数据校验功能的服务,自建存储服务的全链路一致性也需要自行建设,否则在迁移后只能通过md5sum这类工具对全部数据进行校验,确保迁移前后数据没有差异,而不保证迁移后的文件依然是访客当初上传的文件。尽管需要做这样的妥协,海量小文件的迁移和校验依然会造成迁移工期的压力。

利用md5sum递归遍历整个目录,生成所有文件的md5结果,可以通过以下命令完成:

find ./ -type f -print0 | xargs -0 md5sum > ./my.md5

相应的,可以通过以下命令对迁移后的整个目录进行递归遍历校验。

md5sum -c my.md5

1.3 对象存储同步

1.3.1 数据同步

对象存储的数据同步和校验的复杂度介于数据库和文件存储之间,因为它基本上是基于HTTP协议的,镜像回源的功能就能派上用场了,即如果一个文件在我们平台上不存在,那对象存储会尝试到源站去获取并保存下来。而相对于InnoDB数据表这中结构化数据,对象存储的数据一致性保障还是相对较弱。

目前市面上各种平台的对象存储服务对S3协议都有较好支持,而通过ufile-import工具就可以将其他支持S3协议的对象存储数据迁移到US3中。虽然US3也支持镜像回源,但是在数据同步的刚开始时,不建议将原平台bucket配置为回源目标之后就将US3作为服务入口来使用起来,因为这个时候US3 bucket中还没有数据,直接使用US3会造成大量镜像回源,一是从而导致整体访问延迟变大,其次也容易出现访问失败的情况。

ufile-import工具与redis协同工作。在数据同步开始前,ufile-import工具会通过S3协议的列表接口,将一定数量的源bucket对象key以及这些key的同步状态记录进redis中。每当一个文件完成从源bucket的下载、缓存和上传到US3后,导入工具就会在redis中将数据标记为已同步。这样在ufile-import工具因为一些可能的原因,例如网络环境不好等问题故障挂起之后,只需要重启ufile-import,它都可以从断点开始续传。

当完成一轮数据导入之后,就可以开始配置镜像回源配置了,这时候直接访问US3也能得到不错的命中率。当然也可以选择再运行一次ufile-import工具,如果这样操作需要注意ufile-import工具原本的功能是断点续传的,所以我们应该把redis的内容清除。

但是直接清理掉redis再重新跑,ufile-import工具的行为是重新加载文件列表并且重写写入US3,这样会导致所有数据都要重新写一次,效率很低。在这个时候,我们可以配置ufile-import工具为文件比对模式,在获取文件列表后将文件都通过HEAD获取文件大小,这时候只要将源bucket HEAD成功,但是US3为not found或者文件大小不同的数据同步到US3即可。在实际的数据迁移实践中,我们可以更加灵活的使用续传和比对模式来提高工作效率。

【案例】

以近期的xx公司迁移到UCloud为例,该公司的CDN和对象存储从金山云迁移到UCloud的过程里面,有一个bucket中存在文件数量达到了12亿,将所有key存储到redis中并不合理,会导致redis数据膨胀,进而对迁移中转主机提出非常高的内存需求。这时候应该从一开始就使用比对模式对数据进行迁移,进而避免不合理的redis内存使用。

1.3.2 数据校验

对象存储的数据校验方面,大多数对象存储都支持给文件提供ETag的Header,且ETag的生成都跟原始数据有一定关系,所以可以根据源平台的ETag计算方式,在下载到文件后对文件进行一次计算,看看ETag是否相符。而ufile-import功能本身也会按照US3的ETag计算规则预先计算我们的ETag,在上传成功后对比US3返回的ETag和导入工具自行计算的值,来实现对数据的校验。

  1. 数据规整阶段

2.1 脏数据处理

正如前面提到,为了了解新平台中应用是否能正常运行,一般来说迁移过程中涉及到的应用测试都会尽量使用真实数据,甚至采用流量重放的方法对新系统进行测试,以便通过原平台环境中真实行为的结果来校验新平台用应用是否正常工作。在测试之后,新平台就会出现脏数据,需要对其进行处理。实际上脏数据的处理也有两种思路可以使用。其一是回滚,就是在开展业务测试前先对数据进行备份或者记录还原点。

对于MySQL数据库可以备份binlog然后基于binlog进行回滚,也可以通过云平台能力利用备份直接回滚数据库。对于文件存储和对象存储,文件变更日志的作用就很显著了,所有变更过的文件从日志中解析出来之后从源头重新同步,这样可以避免所有文件的重新同步。当然也可以丢掉全部脏数据,采取跟第一章相同的数据迁移手段对数据进行重新同步,这样虽然慢一些,但是整个数据同步过程就是幂等的,可重复性更强。两种脏数据的处理方式可以视乎数据量灵活采用。

2.2 保障数据一致性

在割接准备阶段时候进行的数据同步,这时候所得到的数据就是割接和割接后的生产数据了,所以需要通过一定的手段,保障数据的持续同步,同时避免数据被意外修改。下面说说几种保障的办法。

2.2.1 基于用户的数据库只读

对于MySQL而言,通过对数据同步和业务设置不同的账户,并且对不同用户分配不同的权限,这几乎是最简单易行的实践方式。设立数据同步账户,赋予增删查改权限和DDL语句的权限,这样可以满足存量和增量数据同步的需要,然后将数据同步账户严格控制只配置给UDTS数据同步工具和sync_diff_inspector数据校验工具。而对于业务应用的配置文件,或者记录到配置中心中的配置,上面所使用的数据库账户就只分配select语句权限,这样就能保障业务应用、脚本或者各种定时任务都无法对数据进行更改。而且这样做还有一个好处,对于一些没有实现数据库重连逻辑的业务应用,这时候数据库是可以正常连接的,这意味着在割接的时候不需要重启应用,而是只需要调整MySQL中业务账户的权限。

对于一些场景,不重启对于割接过程来说是非常重要的。例如由于分布式框架的引入,对象和方法可以轻松的通过RPC获取,这时候业务团队也专注于业务的实现,忽略了底层重连机制的实现。结果就是应用系统成为了一个分布式的紧耦合系统,主机A上某个进程的正常运行需要依赖主机B上进程的正常运行,而且B还不能随便重启,因为重启后A不会重连。这时候如果应用不用重启,那意味着清理脏数据后,应用保持当前的运行状态即可,而不是调查所有应用的启动顺序,在割接时确认数据同步后再按顺序逐个启动,这样对于割接后的业务稳定性和割接操作复杂度都是大有裨益的。

通过数据库只读来保障数据一致性的方式受限会比较多。MySQL有基于用户的只读方法,与此同时redis,sql server,mongodb,Elastic Search,文件存储,对象存储等等组件又有各自不同的只读方法,在组件数量和种类增加以后,这种操作方式的优势会逐渐丧失。所以对于数据库数量在数十个,且只有少数几款数据库应用的时候,数据库只读会是一个很有优势的数据一致性保障方法。

总结一下,数据库只读的方式适用于MySQL数据库且实例数量不多的情况,例如整体迁移以模块化方式进行的情况。另外对于需要尽量减少应用重启操作的系统可以优先考虑。

2.2.2 结束应用进程

前面提到,在一些应用系统里重启应用并不是易事;那自然就有一些应用系统,重启造成的困扰并没有那么大,可以相对自由的重启应用。实际上对于一个系统而言,会有三类程序可能对数据存储进行修改,分别是应用程序和操作系统定时任务脚本,对于数据库而言还需要多加一个定时任务。只需要保证这三类程序都是停止的,那么就可以保证没有同步服务以外的程序对数据进行修改,从而保障数据一致性。

通过这种方法来保证数据不被意外修改的优势在于他是普遍适用的,不管提供存储服务的是数据库或者琳琅满目的各种存储服务,只要进程停了数据就不可能被修改。但是这种处理方法的限制也是很明显的。首先就是应用可以随意重启。更重要的是在分布式环境下面,需要具备批量的启动或者关闭应用程序,以及修改操作系统定时任务的能力,不管是基于ansible或者其他方式,除此以外也需要确保生产环境中应用程序和脚本的统计是正确的,也就是说所有应用程序和脚本都是运维和开发共同知晓的。例如运维为了短时间方便,编写脚本作用在生产环境的数据而不被其他同事所了解,那在停止应用的时候自然也不会被考虑到。

总结来说,结束应用程序的方式适合应用可以各自独立启停,且生产环境应用、脚本和数据库定时任务都完全统计清楚明确的情况下使用。

2.2.3 ACL网络隔离

通过ACL对网络数据存储服务做隔离是一个操作上相对比较简单的方法。简单来说,就是在网络环境上配置ACL,允许数据同步服务连接存储并且禁止其它应用主机连接。这种方法的优势在于规则的套用和解除都相对简单,在数据同步是直接对一整个VPC子网生效,在割接时候又只需要在控制台上解除,对整个子网的存储服务做到批量控制。而且相比于数据库只读和结束应用进程,这两种方法都依赖于运维团队对全系统所有细节的掌握,通过网络ACL进行隔离则可以忽略应用系统细节,而且对所有基于网络的存储服务都能覆盖,可以说完全具备了前面两种数据一致性保护方式的优点。

当然ACL网络隔离的方法也有它的适用场景限制。其中最主要的是这个方法的实施要求运维团队对各个子网的功能划分是清晰明确的,网络入口、业务应用和数据存储分别在不同的子网,所以如果应用习惯了大二层的部署方式,那么网络ACL的批量管理优势就会大打折扣。其次,由于对于应用的网络中断,所以对于没有重连机制的应用,也网络重新开通后依然需要重启应用。最后就是这一方法对于不走网络的应用是无法限制的,例如云硬盘本地存储,这种情况需要以挂载云硬盘的主机为单位去考虑网络隔离。

经过对上面几种保障数据一致性方法的了解,其实我们可以发现这几种方法其实并没有相互冲突的点,可以灵活组合来匹配更多实际环境的要求,例如同时使用结束应用进程和ACL网络隔离。

【案例】

在XX公司的跨云迁移任务中,有几个条件是在前期调研中发现的。首先是数据库实例数量众多,源库和目标库既有自建的也有云平台产品,具体操作方式各有差异;其次是数据存储服务种类众多,除了MySQL以外,还有MongoDB、SQL Server、NFS存储、Elastic Search等,逐个组件去设计读写-只读切换的逻辑需要运维人员很大的精力投入;再次,目标系统对存储和应用有比较好的网段划分,虽然组件众多,但是至少都在相同子网内,适合使用ACL来隔离;最后就是,应用方面也确实没有读写-只读的切换开关,而且也没有实现重连机制。所以,在实际操作过程中,笔者使用了结束应用进程和ACL网络隔离的双重保险,因为应用不具备重连实现的情况下,割接测试前应用至少需要重启一次的,ACL和结束应用的限制都会被接受,与此同时ACL隔离也补充了结束应用的覆盖面,从网络层面保障不会有数据同步组件以外的系统连接到数据存储层面来进行操作。

  1. 数据割接阶段

3.1 数据校验时机

不管是整体割接,还是以业务模块为单位的割接,时间窗口大小总是有限的,而且从业务角度也希望割接窗口越小越好。

数据校验最早应该在完成数据规整后才启动,这一点应该是可以简单理解的,因为数据规整前的数据不用作割接后投产,没有校验价值。而在前面数据校验章节中提到,数据校验分为两种,一种是sync_diff_inspector这类实体数据校验,另一种是select max(id)这类元数据校验,两种方法并不冲突,在实际任务中可以灵活安排来减少对割接时间窗口的压力。

【案例】

以近期XX公司迁移到UCloud项目为例,割接时间只有凌晨12点到早上6点的6个小时,中间需要进行应用配置和业务测试,留给数据校验的时间不多,所以早在数据割接之前就启动了sync_diff_inspector对实体数据进行校验。结果数据校验时间和效果都如前预料,最大一个500G数据库的实体数据校验花费了1天多的时间,同时多个数据库的校验也发现了少量的不一致,这一部分不一致经过人工对比后发现发现也实际一致。随后在割接过程中进行元数据校验,结果随着消息队列完成消费和定时任务结束,两边的select max(id)或者select count(id)结果最终一致了。

3.2 割接与回滚

在割接阶段,不得不考虑的一个问题就是回滚,在割接过程中发现数据确实出现了不一致,这时候需要对不一致的范围做合理的评估。如果在割接时间窗口中的元数据校验如果发现不一致,这时候最明智的处理手段就是回滚,而保障原平台没有脏数据则是回滚的基础。

【案例】

以xx公司迁移到UCloud为例,在托管IDC迁移到UCloud混合云的过程中,由于业务依赖较少,所以采用了可以敏捷割接和回滚的业务模块迁移方式。在这一案例的割接实践中,运维团队不仅在为数据库设置了只读,而且也在业务应用中嵌入了只读开关,只要通过配置中心发布开启只读开关即可生效。在数据库只读后就参考数据同步阶段的数据校验方式,对数据或者元数据进行校验,最后在确认应用的读取功能都正常以后再解除目标库的只读,开放业务。在这样的案例中回滚也是相对简单的,如果发现应用的读取功能异常,这时候只需将应用重新部署回原平台,启动和解除数据库只读即可。

而对于需要进行整体割接的任务,割接过程相比于模块化的割接会复杂一些,但是与模块化割接的机理大同小异。在割接过程中先通过停用负载均衡、设置ACL的方式停止业务入口,等待消息队列完成消费数据落地以及定时任务运行完成,然后参考割接准备阶段的方法对原平台数据进行保护。在完成原平台的数据封存后,需要等待同步任务最终完成同步以及对数据进行校验,具体的数据校验方法是参考前面数据校验章节完成的。在确认两边平台数据一致后,就可以停止同步,在新平台启动应用和进行内部测试。

至于回滚操作,本身也是有时间边界的,当新平台业务入口做了灰度开放后就不能进行回滚操作了,因为这时候有很大机率真正的客户数据已经写入到新平台,但是这部分新数据又没有同步回原平台,这样两边数据就是不一致的。

但是一般而言,只要保证迁移两边平台数据是一致的,应用程序大多是应用状态或者代码逻辑问题,相对可控。

本文由UCloud华南架构部团队成员创作

如有疑问或咨询,欢迎留言探讨!

查看原文

赞 0 收藏 0 评论 0

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

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

没那么浅地谈谈HTTP与HTTPS【三】

未济,亨。小狐汔济,濡其尾,无攸利。——《易》

六、密钥管理

当不再担心身份会被冒充、篡改之后,我们再来详细谈谈网络通信中对于加密算法的密钥管理。

在密钥被签发后,密钥管理一般有三个步骤:交换存储使用。其中最重要也是最难的点在于密钥交换

密钥交换

进行安全通信之前,各用户间需要确立加密程序的细节,尤其是密钥。在对称密钥加密系统,各用户间需要确立共同使用的单一密钥,此步骤即密钥交换。

前面章节已经提过,交换对称密钥必须透过另一安全的通信管道进行;否则,如果以明文形式在网络发送,将使窃听者能够立即得知密钥以及据其加密的数据。以前,交换密称密钥是非常麻烦的,可能需要使外交邮袋等安全渠道。

公开密钥加密的出现大大减轻了交换对称密钥的困难,公钥可以公开(透过不安全、可被窃听的渠道)发送,用以加密明文。不过,公钥加密在在计算上相当复杂,性能欠佳、远远不比对称加密。

因此,在一般实际情况下,往往通过公钥加密来随机创建临时的对称秘钥,亦即对话键,然后才通过对称加密来传输大量、主体的数据。(也叫混合加密算法)

密钥交换/协商机制的几种类型

1.依靠非对称加密算法

  • 原理:

拿到公钥的一方先生成随机的会话密钥,然后利用公钥加密它;再把加密结果发给对方,对方用私钥解密;于是双方都得到了会话密钥。

  • 举例:

RSA

2. 依靠专门的密钥交换算法

  • 原理:

这个原理比较复杂,一两句话说不清楚,待会儿聊到 DH 的那个章节会详谈。

  • 举例:

DH 算法及其变种(ECDH算法

3. 依靠通讯双方事先已经共享的“秘密”

  • 原理:

既然双方已经有共享的秘密(这个“秘密”可能已经是一个密钥,也可能只是某个密码/password),只需要根据某种生成算法,就可以让双方产生相同的密钥(并且密钥长度可以任意指定)

  • 举例:

PSKSRP

基于 RSA 的密钥协商

概述

这大概是 SSL 最古老的密钥协商方式——早期的 SSLv2 只支持一种密钥协商机制,就是它。(前一篇)介绍身份认证重要性的时候,也是拿 RSA 来演示。

RSA 是一种【非】对称加密算法。特点是:加密和解密用使用【不同的】密钥。

并且“非对称加密算法”既可以用来做“加密/解密”,还可以用来做“数字签名”。

密钥协商的步骤

  1. 客户端连上服务端
  2. 服务端发送 CA 证书给客户端
  3. 客户端验证该证书的可靠性
  4. 客户端从 CA 证书中取出公钥
  5. 客户端生成一个随机密钥 k,并用这个公钥加密得到 k'
  6. 客户端把 k' 发送给服务端
  7. 服务端收到 k' 后用自己的私钥解密得到 k
  8. 此时双方都得到了密钥 k,协商完成

如何防范偷窥(嗅探)

  • 攻击方式1
攻击者虽然可以监视网络流量并拿到公钥,但是【无法】通过公钥推算出私钥(这点由 RSA 算法保证)
  • 攻击方式2
攻击者虽然可以监视网络流量并拿到 k',但是攻击者没有私钥,【无法解密】 k',因此也就无法得到 k

如何防范篡改(假冒身份)

  • 攻击方式1
如果攻击者在第2步篡改数据,伪造了证书,那么客户端在第3步会发现(这点由证书体系保证)
  • 攻击方式2
如果攻击者在第6步篡改数据,伪造了k',那么服务端收到假的k'之后,解密会失败(这点由 RSA 算法保证)。服务端就知道被攻击了。

基于 DH 的密钥协商

概述

DH 算法又称“Diffie–Hellman 算法”。这是两位数学牛人的名称,他们创立了这个算法。该算法用来实现【安全的】“密钥交换”。它可以做到——“通讯双方在完全没有对方任何预先信息的条件下通过不安全信道创建起一个密钥”。这句话比较绕口,通俗地说,可以归结为两个优点:

  1. 通讯双方事先【不】需要有共享的秘密。
  2. 用该算法协商密码,即使协商过程中被别人全程偷窥(比如“网络嗅探”),偷窥者也【无法】知道协商得出的密钥是啥。

但是 DH 算法本身也有缺点——它不支持认证。

也就是说:它虽然可以对抗“偷窥”,却无法对抗“篡改”,自然也就无法对抗“中间人攻击/MITM”(前一篇已经强调过——缺乏身份认证,【必定会】遭到“中间人攻击/MITM”)。

为了避免遭遇 MITM 攻击,DH 需要与其它签名算法(比如 RSA、DSA、ECDSA)配合——靠签名算法帮忙来进行身份认证。当 DH 与 RSA 配合使用,称之为“DH-RSA”,与 DSA 配合则称为“DH-DSA”,以此类推。

反之,如果 DH 【没有】配合某种签名算法,则称为“DH-ANON”(ANON 是“anonymous”(匿名)的简写)。此时会遭遇“中间人攻击/MITM”。

关于该算法具体数学原理,可以参见迪菲-赫尔曼密钥交换

密钥协商的步骤

  1. 客户端先连上服务端
  2. 服务端生成一个随机数 s 作为自己的私钥,然后根据算法参数计算出公钥 S(算法参数通常是固定的)
  3. 服务端使用某种签名算法把“算法参数(模数p,基数g)和服务端公钥S”作为一个整体进行签名
  4. 服务端把“算法参数(模数p,基数g)、服务端公钥S、签名”发送给客户端
  5. 客户端收到后验证签名是否有效
  6. 客户端生成一个随机数 c 作为自己的私钥,然后根据算法参数计算出公钥 C
  7. 客户端把 C 发送给服务端
  8. 客户端和服务端(根据上述 DH 算法)各自计算出 k 作为会话密钥

如何防范偷窥(嗅探)

嗅探者可以通过监视网络传输,得到算法参数(模数p,基数g)以及双方的公钥,但是【无法】推算出双方的私钥,也【无法】推算出会话密钥(这是由 DH 算法在数学上保证的)

如何防范篡改(假冒身份)

  • 攻击方式1
攻击者可以第4步篡改数据(修改算法参数或服务端公钥)。但因为这些信息已经进行过数字签名。篡改之后会被客户端发现。
  • 攻击方式2
攻击者可以在第7步篡改客户端公钥。这步没有签名,服务端收到数据后不会发现被篡改。但是,攻击者篡改之后会导致“服务端与客户端生成的会话密钥【不一致】”。在后续的通讯步骤中会发现这点,并导致通讯终止。
(协议初始化/握手阶段的末尾,双方都会向对方发送一段“验证性的密文”,这段密文用各自的会话密钥进行【对称】加密,如果双方的会话密钥不一致,这一步就会失败,进而导致握手失败,连接终止)

基于 PSK 的密钥协商

概述

PSK 是“Pre-Shared Key”的缩写。顾名思义,就是【预先】让通讯双方共享一些密钥(通常是【对称加密】的密钥)。所谓的【预先】,就是说,这些密钥在 TLS 连接尚未建立之前,就已经部署在通讯双方的系统内了。

这种算法用的不多,它的好处是:

  1. 不需要依赖公钥体系,不需要部属 CA 证书。
  2. 不需要涉及非对称加密,TLS 协议握手(初始化)时的性能好于前述的 RSA 和 DH。 更多介绍可以参见维基百科,链接在“这里”。

密钥协商的步骤

(由于 PSK 用的不多,下面只简单介绍一下步骤,让大伙儿明白其原理)

  • 在通讯【之前】,通讯双方已经预先部署了若干个共享的密钥。
  • 为了标识多个密钥,给每一个密钥定义一个唯一的 ID
  • 协商的过程很简单:客户端把自己选好的密钥的 ID 告诉服务端。
  • 如果服务端在自己的密钥池子中找到这个 ID,就用对应的密钥与客户端通讯;否则就报错并中断连接。

如何防范偷窥(嗅探)

使用这种算法,在协商密钥的过程中交换的是密钥的标识(ID)而【不是】密钥本身。 就算攻击者监视了全过程,也无法知晓密钥是什么。

如何防范篡改(假冒身份)

PSK 可以单独使用,也可以搭配签名算法一起使用。

  • 对于单独使用:
如果攻击者篡改了协商过程中传送的密钥 ID,要么服务端发现 ID 无效(协商失败),要么服务端得到的 ID 与客户端不一致,在后续的通讯步骤中也会发现,并导致通讯终止。
(协议初始化/握手阶段的末尾,双方都会向对方发送一段“验证性的密文”,这段密文用各自的会话密钥进行【对称】加密,如果双方的会话密钥不一致,这一步就会失败,进而导致握手失败,连接终止)
  • 对于搭配签名算法
如果攻击者篡改了协商过程中传送的密钥 ID,验证签名会失败

补充说明

PSK 与 RSA 具有某种相似性——既可以用来搞“密钥协商”,也可以用来搞“身份认证”。 所以,PSK 可以跟 DH(及其变种)进行组合。例如:DHE-PSK、ECDHE-PSK

基于 SRP 的密钥协商

概述

SRP 是“Secure Remote Password”的缩写。

这个算法有点类似于刚才提到的 PSK——只不过 client/server 双方共享的是比较人性化的密码(password)而不是密钥(key)。该算法采用了一些机制(盐/salt、随机数)来防范“嗅探/sniffer”或“字典猜解攻击”或“重放攻击”。

这个算法应该用得很少——OpenSSL 直到2012年才开始支持该算法。所以这里就不展开了,有兴趣的同学可以去看 RFC2945 的协议描述

密钥存储

对称加密使用的单一密钥会被收发双方存储,公开密钥加密的私钥由于还有数字签名的功能,所以都必须安全存储,以保障通信安全。业界已发展出各种各样的技术来保障密钥得到妥善存储,包括定期或不定的系统检测是否有入侵之虞、对存储媒体或服务器提供高强度的物理防护及监控。

最常见的是加密应用程序负责管理用户的密钥,使用密钥时则需要输入认别用户的访问密码。对于认证机构,一旦私钥外泄,将可能导致整个信任链被摧毁,影响广及众多客户,所以认证机构会使用硬件安全模块,有些存储私钥的计算机甚至平时不会连线,只在固定的调度下,经过一系列严谨的行政程序重重把关,才会取出私钥为客户签名证书。

在信任链设计中,绝大部分的根证书都不会直接为客户签名,而是先签名一个(或多个)中继证书,再由中继证书为客户签名,这可以加强控管能力及控制一旦签名私钥被泄时的损失。

密钥使用

密钥的有效期限是一个重要问题,一个密钥应该在产生后多久被汰换呢?

密钥汰换之后,旧有的密钥就无法再解密新产生的密文,丧失对窃听者的价值,这会增加了攻击者所需要投入的气力,所以密钥应该经常替换。

同时,这也可以减低信息一旦被破解(_一般是回溯性破解【注1】_)时的损失:因为窃听者可能在破解密钥之前一直存储截取到的加密消息,等待成功破解密钥的一刻。所以密钥更换得越频密,窃听者可解读的消息就越少。

在过去,如果可靠的密钥交换程序非常困难或者仅仅间歇可行,对称密钥会被长期使用。

但在理想情况下,对称密钥应该在每次交换消息或会话时转换(_完美正向加密【注2】_),使得如果某一密钥被泄(例如,被盗窃,密码分析或社会工程化)时,只有单一消息或会话被解读。

基于公开密钥加密的特性,一对公钥和私钥的有效期一般会长于对称加密所使用的单一密钥,尤其是需要认证机构签核的电子证书,当中涉及行政及部署成本,所以可能是三个月至一、两年不等,考虑的因素包括配合加密算法的密钥长度、存储私钥的强度、一旦外泄可能引致的风险、更换程序对运行中的服务的影响、以及运行成本。

七、TSL握手

有了前面的基础知识,这章我们就来讨论下TSL完整的实现过程。

TSL建立连接要经过四次握手, 握手过程又分为:

  1. 单向验证:就是server端将证书发送给客户端,客户端验证server端证书的合法性等。例如百度、新浪、google等普通的https网站。
  2. 双向验证:不仅客户端会验证server端的合法性,同时server端也会验证客户端的合法性。例如银行网银登陆,支付宝登陆交易等。

下面只讨论单向验证的情况:

第一步:客户端发出请求(ClientHello)

首先,客户端(通常是浏览器)先向服务器发出加密通信的请求,这被叫做ClientHello请求。

在这一步,客户端主要向服务器提供以下信息。

(1) 支持的协议版本,比如TLS 1.0版。
(2) 一个客户端生成的随机数,稍后用于生成"对话密钥"。
(3) 支持的加密方法,比如RSA公钥加密。
(4) 支持的压缩方法。

这里需要注意的是,客户端发送的信息之中不包括服务器的域名。也就是说,理论上服务器只能包含一个网站,否则会分不清应该向客户端提供哪一个网站的数字证书。这就是为什么通常一台服务器只能有一张数字证书的原因。

对于虚拟主机的用户来说,这当然很不方便。2006年,TLS协议加入了一个Server Name Indication扩展,允许客户端向服务器提供它所请求的域名。

第二步:服务器回应(SeverHello)

服务器收到客户端请求后,向客户端发出回应,这叫做SeverHello。服务器的回应包含以下内容。

(1) 确认使用的加密通信协议版本,比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致,服务器关闭加密通信。
(2) 一个服务器生成的随机数,稍后用于生成"对话密钥"。
(3) 确认使用的加密方法,比如RSA公钥加密。
(4) 服务器证书。

除了上面这些信息,如果服务器需要确认客户端的身份,就会再包含一项请求,要求客户端提供"客户端证书"。比如,金融机构往往只允许认证客户连入自己的网络,就会向正式客户提供USB密钥,里面就包含了一张客户端证书。

第三步:客户端回应

客户端收到服务器回应以后,首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期,就会向访问者显示一个警告,由其选择是否还要继续通信。

如果证书没有问题,客户端就会从证书中取出服务器的公钥。然后,向服务器发送下面三项信息。

(1) 一个随机数。该随机数用服务器公钥加密,防止被窃听。
(2) 编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送。
(3) 客户端握手结束通知,表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值,用来供服务器校验。

上面第一项的随机数,是整个握手阶段出现的第三个随机数,又称"pre-master key"。有了它以后,客户端和服务器就同时有了三个随机数,接着双方就用事先商定的加密方法,各自生成本次会话所用的同一把"会话密钥"。

至于为什么一定要用三个随机数,来生成"会话密钥",dog250解释得很好:

"不管是客户端还是服务器,都需要随机数,这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的,因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
对于RSA密钥交换算法来说,pre-master-key本身就是一个随机数,再加上hello消息中的随机,三个随机数通过一个密钥导出器最终导出一个对称密钥。
pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数,如果随机数不随机,那么pre master secret就有可能被猜出来,那么仅适用pre master secret作为密钥就不合适了,因此必须引入新的随机因素,那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了,一个伪随机可能完全不随机,可是是三个伪随机就十分接近随机了,每增加一个自由度,随机性增加的可不是一。"

此外,如果前一步,服务器要求客户端证书,客户端会在这一步发送证书及相关信息。

第四步: 服务器的最后回应

服务器收到客户端的第三个随机数pre-master key之后,计算生成本次会话所用的"会话密钥"。然后,向客户端最后发送下面信息。

(1)编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送。
(2)服务器握手结束通知,表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值,用来供客户端校验。

至此,整个握手阶段全部结束。接下来,客户端与服务器进入加密通信,就完全是使用普通的HTTP协议,只不过用"会话密钥"加密内容。

握手过程拟人化说明

A:我想和你安全的通话,我这里的对称加密算法有DES,RC5, 密钥交换算法有RSA和DH, 摘要算法有MD5和SHA。
B:我们用DES-RSA-SHA这对组合好了。 这是我的证书,里面有我的名字和公钥,你拿去验证一下我的身份(把证书发给A)。 目前没有别的可说的了。
A:(查看证书上B的名字是否无误,并通过手头早已有的CA的证书验证了B的证书的真实性,如果其中一项有误,发出警告并断开连接,这一步保证了B的公钥的真实性)
(产生一份秘密消息,这份秘密消息处理后将用作加密密钥,加密初始化向量(IV)和hmac的密钥。将这份秘密消息-协议中称为per_master_secret-用B的公钥加密,封装成称作ClientKeyExchange的消息。由于用了B的公钥,保证了第三方无法窃听)
我生成了一份秘密消息,并用你的公钥加密了,给你(把ClientKeyExchange发给B) 注意,下面我就要用加密的办法给你发消息了!
(将秘密消息进行处理,生成加密密钥,加密初始化向量和hmac的密钥) [我说完了]
B:(用自己的私钥将ClientKeyExchange中的秘密消息解密出来,然后将秘密消息进行处理,生成加密密钥,加密初始化向量和hmac的密钥,这时双方已经安全的协商出一套加密办法了) 注意,我也要开始用加密的办法给你发消息了! [我说完了]

八、其他

HTTP与HTTPS区别小结:

  1. HTTP 的URL 以http:// 开头,而HTTPS 的URL 以https:// 开头
  2. HTTP 是不安全的,而 HTTPS 是安全的
  3. HTTP 标准端口是80 ,而 HTTPS 的标准端口是443
  4. 在OSI 网络模型中,HTTP工作于应用层,而HTTPS 工作在传输层
  5. HTTP 无加密,而HTTPS 对传输的数据进行加密
  6. HTTP无需证书,而HTTPS 需要CA机构颁发的SSL证书

握手过程优化

对于HTTP,为了避免每次请求都要经过tcp三次握手,使用了长连接技术进行优化。

而对于HTTPS,如果每次重连都要重新TSL握手也是比较消耗性能和费时的,大致有几个优化方向:

  1. Session id及session ticket的复用,缩减证书交换时间,减少可能的计算以及RTT时间 。
  2. 选取相对来说计算量较小且安全的算法 。
  3. 将最消耗性能和费时的握手部分,交给加速卡承担。

在此不再详细展开,有兴趣的可以参考TLS 握手优化详解

回顾前篇请点击以下链接:

UCloud云计算:没那么浅地谈谈HTTP与HTTPS【一】​zhuanlan.zhihu.com图标UCloud云计算:没那么浅地谈谈HTTP与HTTPS【二】​zhuanlan.zhihu.com图标

参考链接:

  1. 浅谈HTTPS(SSL/TLS)原理
  2. SSL/TLS协议运行机制的概述
  3. HTTPS证书生成原理和部署细节
  4. 扫盲 HTTPS 和 SSL/TLS 协议系列
  5. 数字证书及 CA 的扫盲介绍
  6. RFC:The Transport Layer Security (TLS) Protocol Version 1.2
  7. HTTPS协议详解(三):PKI 体系
  8. 《HTTP权威指南》 人民邮电出版社 2012

本文作者:UCloud后台研发工程师 Hughes.Chen

博客地址:https://ulyc.github.io/

查看原文

赞 0 收藏 0 评论 0

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

没那么浅地谈谈HTTP与HTTPS【二】

**玫瑰与荆棘共生,香菇与毒菇同长,真实与假冒比翼腾飞。——王蒙
**

没那么浅地谈谈HTTP与HTTPS【二】

四、加密算法和密钥管理

介绍密钥交换机制之前先普及一些加密算法基本知识以及为什么要有密钥管理机制。

1. 加密算法

加密算法就是将普通信息(明文)转换成难以理解的数据(密文)的过程;

解密算法则是其相反的过程:由密文转换回明文

加解密包含了这两种算法,一般加密即同时指称加密解密的技术。

加解密的具体运作由两部分决定:一个是算法,另一个是密钥

密钥是一个用于加解密算法的秘密参数,通常只有通信者拥有。

1) 对称密钥加密

对称密钥加密是密码学中的一种加密法,是以转换其中一个数字、字母或仅字符串随机字母,一个秘密密钥会以特定的方式变更消息里面的文字或字母,例如更换字母相对位置(例如hello变成lohel)。只要寄件者与收件者知道秘密密钥,他们可以加密和解密并使用这个数据。

2.)公开密钥加密

公开密钥加密(也称为非对称加密)是密码学中的一种加密法,非对称密钥,是指一对加密密钥与解密密钥,某用户使用加密密钥加密后所获得的数据,只能用该用户的解密密钥才能够解密。如果知道了其中一个,并不能计算出另外一个。因此如果公开了其中一个密钥,并不会危害到另外一个。因此公开的密钥为公钥;不公开的密钥为私钥。

2. 单纯使用加密算法存在的问题

通信双方使用加密算法之后,需要密钥来解密和加密信息,而双方如何得到、交换密钥,并且不会被第三方窃取,或者说密钥就算被窃取也不会导致密文被解密读取呢?

1)单纯对称加密算法的困境:

如果“单纯用对称加密”,浏览器和网站之间势必先要交换“对称加密的密钥”。

如果这个密钥直接用【明文】传输,很容易就会被第三方(有可能是“攻击者”)偷窥到;如果这个密钥用密文传输,那就再次引入了“如何交换加密密钥”的问题——这就变成“先有鸡还是先有蛋”的循环逻辑了。

2)单纯非对称加密算法的困境:

基于“加密和解密采用不同的密钥”的特点,可以避开前面提到的“循环逻辑”的困境。大致的步骤如下:

第1步 网站服务器先基于“非对称加密算法”,随机生成一个“密钥对”(为叙述方便,称之为“k1 和 k2”)。因为是随机生成的,目前为止,只有网站服务器才知道 k1 和 k2。
第2步 网站把 k1 保留在自己手中,把 k2 用【明文】的方式发送给访问者的浏览器。 因为 k2 是明文发送的,自然有可能被偷窥。不过不要紧。即使偷窥者拿到 k2,也【很难】根据 k2 推算出 k1 (这一点是由“非对称加密算法”从数学上保证的)。
第3步 浏览器拿到 k2 之后,先【随机生成】第三个对称加密的密钥(简称 k)。 然后用 k2 加密 k,得到 k'(k' 是 k 的加密结果) 浏览器把 k' 发送给网站服务器。 由于 k1 和 k2 是成对的,所以只有 k1 才能解密 k2 的加密结果。 因此这个过程中,即使被第三方偷窥,第三方也【无法】从 k' 解密得到 k
第4步 网站服务器拿到 k' 之后,用 k1 进行解密,得到 k 至此,浏览器和网站服务器就完成了密钥交换,双方都知道 k,而且【貌似】第三方无法拿到 k 然后,双方就可以用 k 来进行数据双向传输的加密。

乍看以上步骤很严密,即使被第三方偷窥,第三方也难以从 k' 解密得到 k。

但这种方法有一个致命的缺陷,就是无法防止数据篡改,也无法识别假冒的身份。

攻击方法如下:

第1步 这一步跟原先一样——服务器先随机生成一个“非对称的密钥对”k1 和 k2(此时只有网站知道 k1 和 k2)
第2步 当网站发送 k2 给浏览器的时候,攻击者截获 k2,保留在自己手上。 然后攻击者自己生成一个【伪造的】密钥对(以下称为 pk1 和 pk2)。 攻击者把 pk2 发送给浏览器。
第3步 浏览器收到 pk2,以为 pk2 就是网站发送的。 浏览器不知情,依旧随机生成一个对称加密的密钥 k,然后用 pk2 加密 k,得到密文的 k' 浏览器把 k' 发送给网站。 (以下是关键)
发送的过程中,再次被攻击者截获。 因为 pk1 pk2 都是攻击者自己生成的,所以攻击者自然就可以用 pk1 来解密 k' 得到 k 然后,攻击者拿到 k 之后,用之前截获的 k2 重新加密,得到 k'',并把 k'' 发送给网站。
第4步 网站服务器收到了 k'' 之后,用自己保存的 k1 可以正常解密,所以网站方面不会起疑心。 至此,攻击者完成了一次漂亮的偷梁换柱,而且让双方都没有起疑心。  

上述过程,即是传说中的中间人攻击(Man-In-The-Middle attack )。

3. 失败的原因—缺乏【可靠的】身份认证

为什么以上方案会失败?

除了提到的“攻击者具备篡改数据的能力”,还有另一点关键点——“缺乏身份认证机制”。

正是因为“缺乏身份认证机制”,所以当攻击者一开始截获 k2 并把自己伪造的 pk2 发送给浏览器时,浏览器无法鉴别:自己收到的密钥是不是真的来自于网站服务器。

假如具备某种【可靠的】身份认证机制,即使攻击者能够篡改数据,但是篡改之后的数据很容易被识破。那篡改也就失去了意义。于是我们引入“CA认证体系”。

五、CA认证体系

CA

数字证书认证机构(英语:Certificate Authority,缩写为CA),也称为电子商务认证中心电子商务认证授权机构,是PKI(公钥基础设施)的核心执行机构,是PKI的主要组成部分,并作为电子商务交易中受信任的第三方,承担公钥体系中公钥的合法性检验的责任。

从广义上讲,认证中心还应该包括证书申请注册机构RA(Registration Authority),RA是数字证书的申请注册、证书签发的管理机构。

CA证书

CA 证书,顾名思义,就是CA颁发的证书。   

人人都可以找工具制作证书。但是个人制作出来的证书是没什么用处的。

因为你【不是】权威的 CA 机关,你自己搞的证书不具有权威性。   

PKI公钥基础设施

公钥基础设施(Public Key Infrastructure,简称PKI)是目前网络安全建设的基础与核心。

简单的说PKI技术就是利用公钥理论和技术建立的提供信息安全服务的基础设施,该体系在统一的安全认证标准和规范基础上提供在线身份认证,是_CA认证、数字证书、数字签名_以及相关_安全应用组件模块_的集合。

做为一种技术体系,PKI可以作为支持认证、完整性、机密性和不可否认性的技术基础,从技术上解决网上身份认证、信息完整性的抗抵赖等安全问题,为网络应用提供可靠的安全保障,但PKI不仅仅涉及到技术层面的问题。

证书链

为了尽可能的保证根证书的安全性,CA中心采取了一种树状的结构:

一个root CA下面包含多个intermediates CA,然后根CA和次级CA都可以颁发证书给用户,颁发的证书分别是根证书和次级证书,最后则是用户的证书,也可以说是中级证书。

证书信任链

实际上,证书之间的信任关系,是可以嵌套的。比如,C 信任 A1,A1 信任 A2,A2 信任 A3......这个叫做证书的信任链。

只要你信任链上的头一个证书,那后续的证书,都是可以信任的。

CA认证体系的基本使用

  1. 服务方S向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证;
  2. CA通过线上、线下等多种手段验证申请者提供信息的真实性,如组织是否存在、企业是否合法,是否拥有域名的所有权等;
  3. 如信息审核通过,CA会向申请者签发认证文件-证书。证书包含以下信息:申请者公钥、申请者的组织信息和个人信息、签发机构 CA的信息、有效时间、证书序列号等信息的明文,同时包含一个签名;

(签名的产生算法:首先,使用散列函数计算公开的明文信息的信息摘要,然后,采用 CA的私钥对信息摘要进行加密,密文即签名。)

  1. 客户端 C 向服务器 S 发出请求时,S 返回证书文件;
  2. 客户端 C读取证书中的相关的明文信息,采用相同的散列函数计算得到信息摘要,然后,利用对应 CA的公钥解密签名数据,对比证书的信息摘要,如果一致,则可以确认证书的合法性,即公钥合法;
  3. 客户端验证证书相关的域名信息、有效时间等信息;
  4. 客户端会内置信任CA的证书信息(包含公钥),如果CA不被信任,则找不到对应 CA的证书,证书也会被判定非法。

在这个过程注意几点:

  • 申请证书不需要提供私钥,确保私钥永远只能由服务器端掌握;
  • 证书的合法性仍然依赖于非对称加密算法,证书主要是增加了服务器信息以及签名;
  • 内置 CA 对应的证书称为根证书,颁发者和使用者相同,自己为自己签名,即自签名证书(为什么说"部署自签SSL证书非常不安全")
  • 证书= 公钥 + 申请者与颁发者信息 + 签名;

即便有人截取服务器A证书,再发给客户端,想冒充服务器A,也无法实现。因为证书和url的域名是绑定的。

未完待续……

本文作者:UCloud后台研发工程师 Hughes.Chen
博客地址:https://ulyc.github.io/

查看原文

赞 0 收藏 0 评论 0

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

没那么浅地谈谈HTTP与HTTPS【一】

面对愚昧,神们自己也缄口不言 。——《基地》

2019年8月11日,IETF 终于发布了 RFC 8446,标志着 TLS 1.3 协议大功告成 。这是该协议的第一次重大改革,带来了重大的安全性和性能改进。

本来想写一篇简短介绍...结果越写越长,干脆拆分开慢慢写,慢慢发。

一、基本概念

http

HTTP 是一个网络协议,是专门用来帮你传输 Web 内容的。

比如浏览器地址栏打开任意网址http://http://ulyc.github.io/

加了粗体的部分就是指 HTTP 协议。大部分网站都是通过 HTTP 协议来传输 Web 页面、以及 Web 页面上包含的各种东西(图片、CSS 样式、JS 脚本)。

如果你有一些网络基础知识,就知道http协议存在于四层网络结构中的应用层

HHTP协议为明文传输,所有信息均为可见的,很不安全,信息极易被篡改和劫持,也因此衍生出了相对更为安全的HTTPS。

SSL/TLS

SSL(Secure Sockets Layer),即安全套接层,是一种安全协议,目的是为互联网通信提供安全及数据完整性保障。

网景公司(Netscape)在1994年推出HTTPS协议,以SSL进行加密,这是SSL的起源。 到了1999年,SSL 因为应用广泛,已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 TLS(是“Transport Layer Security”的缩写),中文叫做“传输层安全协议”。   

很多相关的文章都把这两者并列称呼(SSL/TLS),因为这两者可以视作同一个东西的不同阶段。

SSL又分为两层:

  1. SSL记录协议(SSL Record Protocol):它建立在可靠的传输协议(如TCP)之上,为高层协议提供数据封装、压缩、加密等基本功能的支持。
  2. SSL握手协议(SSL Handshake Protocol):它建立在SSL记录协议之上,用于在实际的数据传输开始前,通讯双方进行身份认证、协商加密算法、交换加密密钥等。 包括SSL握手协议,SSL改变密码协议,SSL警告协议 。

https

HTTPS(Hyper Text Transfer Protocol Secure),即超文本传输安全协议,也称为http over tls等,是一种网络安全传输协议。

相当于工作在应用层(osi七层模型)的http,只不过是在会话层和表示层利用ssl/tls来加密了数据包,说白了就是“HTTP 协议”和“SSL/TLS 协议”的组合,你可以把 HTTPS 大致理解为——“HTTP over SSL”或“HTTP over TLS” 。

有位大神做过一个很形象的比喻:

如果原来的 HTTP 是塑料水管,容易被戳破;那么如今新设计的 HTTPS 就像是在原有的塑料水管之外,再包一层金属水管。
一来,原有的塑料水管照样运行;
二来,用金属加固了之后,不容易被戳破。

访问时以https://开头,默认443端口,同时需要证书。现在大部分网站都已经支持https协议,如果经常访问的支持https的网站突然只能以http访问,就要小心了。

二、引入https的必要性

不使用SSL/TLS的HTTP通信,就是不加密的通信。

所有信息明文传播,带来了三大风险:

  1. 窃听风险(eavesdropping):第三方可以获知通信内容。
  2. 篡改风险(tampering):第三方可以修改通信内容。
  3. 冒充风险(pretending):第三方可以冒充他人身份参与通信。

SSL/TLS协议是为了解决这三大风险而设计的,希望达到:

  1. 所有信息都是加密传播,第三方无法窃听。
  2. 具有校验机制,一旦被篡改,通信双方会立刻发现。
  3. 配备身份证书,防止身份被冒充。

互联网是开放环境,通信双方都是未知身份,这为协议的设计带来了很大的难度。而且,协议还必须能够经受所有匪夷所思的攻击,这使得SSL/TLS协议变得异常复杂。

SSL/TLS协议对于以上风险的防护分别作了以下实现:

  1. _加密(encryption)_:使用密钥协商机制。
  2. _鉴定(identification)_:依赖CA 认证体系和加密算法。
  3. _认证(verification)_:依赖CA 认证体系。

三、基本的运行过程

应用层

客户端(浏览器、爬虫程序等)向服务器发送符合http协议的请求(http发送的是明文请求,https是经过安全层加密的密文请求),得到服务器返回的响应(同样http是明文响应,https是密文响应),并在本地解析渲染。

安全层

此层是是SSL/TLS所在的位于传输层与应用层之间的一个抽象层,在TCP/IP协议族中勉强可以划分到_传输层_,在osi七层网络模型中没有严格的对应,一般认为属于 _会话层_和_表达层_。

http与https主要区别就在于是否存在此安全层,本层实现了_加密(encryption)(非对称加密),认证(verification),鉴定(identification)。_

基本过程是:

  1. 客户端向服务器端索要并验证公钥。
  2. 双方协商生成"对话密钥"
  3. 双方采用"对话密钥"进行加密通信。

上面过程的前两步,称为"握手阶段",即SSL四次握手。

传输层

http与https协议都是基于传输层的TCP协议。

连接时会进行“三次握手”,断开连接时客户端与服务器进行”四次挥手“。

未完待续……

本文作者:UCloud后台研发工程师 Hughes.Chen

博客地址:https://ulyc.github.io/

查看原文

赞 0 收藏 0 评论 0

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

Terraform初体验(二) 第一个demo执行

通过Terraform在本地运行docker nginx

前置条件: 1. 安装好windows docker 2. 安装好terraform

安装docker

安装windows docker可以直接登录http://docker.com下载安装即可,docker可以有图形化管理页面安装最新的19.03。为了简化第一次的操作,这里我们先不通过terraform来安装docker,docker下载安装地址https://www.docker.com/get-started

编写main.tf

terraform {
  required_providers {
    docker = {
      source = "terraform-providers/docker"
    }
  }
}

provider "docker" {
  host    = "tcp://localhost:2375"
}

resource "docker_image" "nginx" {
  name         = "nginx:latest"
  keep_locally = false
}

resource "docker_container" "nginx" {
  image = docker_image.nginx.latest
  name  = "tutorial"
  ports {
    internal = 80
    external = 8000
  }
}

其中值得注意的是,官方的例子,在provider "docker"中指定的host是通过windows的管道完成的,怕是已经很多人不会用了。这里需要在docker desktop中设置开启"tcp://localhost:2375",并替换tf文件中的host ="tcp://localhost:2375"。

执行main.tf

笔者使用的vs code,可以直接右键在终端中打开,然后依次进行以下步骤。

1. 初始化

在终端中执行terraform init。首次执行初始化操作,会有较长的时间去获取terraform中定义的source信息,在第一次初始化后没有source信息的变化,可以跳过初始化直接开始部署。

2. 部署

在终端中执行terraform plan查看terraform执行计划,在终端中执行terraform apply完成部署。执行部署命令时,会将terraform的plan列出来展示给用户,并由用户确定执行。也可以输入-auto-approve跳过plan。

输入"yes"

安装完成!

查看结果。

大家可以简单的字面理解main.tf中的语义,会在后面的内容中详细介绍,在此次执行中我们会在本地创建一个nginx的容器,并暴露800端口,我们访问localhost:800可以看到由terraform创建的容器可以正常运行。

3. 删除

在终端中执行terraform destroy。则删除由tf创建的docker容器。

附录

在我们执行terraform -h后看到terraform的相关操作命令和使用方法,整理给大家,如果你刚刚开始使用terraform,可以从这些基础命令开始,对于其他命令,请使用前阅读terraform的官方文档。

Usage: terraform [-version] [-help] [args]

Common commands:

apply              构建或更改基础设施

console            terraform传参的交互式控制台

destroy            删除由terraform控制的基础设施

env                工作空间管理

fmt                将配置文件重写为规范格式

get                下载并安装配置模块

graph              创建terraform资源的可视化图形

import             将现有基础设施导入terraform

init               初始化terraform的工作目录

login              获取并保存远程主机的凭据

logout             删除远程主机的本地存储凭据

output             从状态文件读取输出

plan               生成并显示执行计划

providers          打印配置中使用的提供程序的树型结构

refresh            根据实际资源更新本地状态文件

show               检查terraform的状态或计划

taint              手动标记污点以便资源重新创建

untaint            手动取消污点

validate           验证terraform文件

version            terraform版本

workspace          工作空间管理

All other commands:

0.12upgrade        重写v0.12之前的模块源代码

0.13upgrade        重写v0.13之前的模块源代码

debug              debug输出管理

force-unlock       手动解除terraform锁定状态

push               推送完成代码到企业仓库

state              关键状态管理

本文作者:UCloud 容器云产品经理 沈旭

查看原文

赞 0 收藏 0 评论 0