Mac 中如何登陆麒麟堡垒机中托管的服务器?

麒麟堡垒机用于运维管理的认证、授权、审计等监控管理。因为也有开源版本,所以颇受欢迎。厂家也提供了比较完善的用于Windows访问的一系列工具,比如ssh登陆原生支持putty,xshell,sercurecrt等工具。

而对于 Mac,一般使用原生 shell 或 iterm2 登陆服务器。由于Mac小众的特点,客户公司也很少对其做兼容,使用Mac的也只能自力更生了。

ssh {username}--{server-id}@{proxy-ip}
ssh kelu--9876@1.1.1.1

稍微解释下,username是你登陆堡垒机的账号,server-id是堡垒机界面上显示的要登陆服务器的id,proxy-ip是堡垒机中转服务器的IP。

其实通过堡垒机登陆服务器的逻辑就是,将你的认证信息交给堡垒机验证,验证通过后堡垒机根据id找到目的服务器,注入服务器默认账户的账号密码,将请求转发过去,完成。


Service Mesh是下一代SDN吗?从通信的角度看Service Mesh的发展 - 赵化冰

原文链接:https://www.servicemesher.com/blog/201910-what-can-service-mesh-learn-from-sdn/

前言

如果具有通信或者网络行业的知识背景,那么你对SDN(Software Defined Network)一定不会陌生。你也许已经注意到,近来在微服务领域兴起的Service Mesh和SDN(Software Defined Network) 非常相似,这两者都采用了软件对网络进行管理和控制,也都采用了包含控制面和数据面的类似架构。

那么Service Mesh和SDN有什么关系?Service Mesh是下一代的SDN吗? Service Mesh是否可以从SDN的发展历史中借鉴一些经验?本文将就这些问题进行一一探讨。

传统网络面临的挑战

首先我们来回顾一下SDN的起源。传统的IP网络是一个分布式的无中心架构,各个网络设备包含完整的控制面和数据面,单个设备通过网络协议探测网络中其他设备的状态,自主决定如何对流量进行路由。该架构的好处是容错性强,即使网络局部出现故障,整个网络也可以自主恢复,不会影响整个网络的运行。 在传统的网络架构下,控制面和数据面位于同一设备中

这种去中心的架构在基于文本和图片的web浏览器应用时代运作良好,但随着互联网业务的爆炸式增长,各种各样的业务纷纷承载在了IP网络上,包括各种实时业务如语音视频通话,对网络提出了新的挑战。

  • 缺少网络质量保证: 绝大多数IP网络都是基于无连接的,只有基于大带宽的粗放带宽保障措施,缺乏质量保证和监控,业务体验较差。
  • 低效的业务部署: 网络配置是通过命令行或者网管、由管理员手工配置到网络设备上,并且各种网络设备之间的控制命令互不兼容,导致业务的部署非常低效。
  • 缓慢的业务适应: 业务由硬件实现,导致新业务的开发周期过长。需要持续数年的特性和架构调整、引入新设备,才能推出新的业务,无法快速适应市场,满足用户的需求。

SDN如何解决传统网络的问题

为了应对这些问题,提出了SDN的解决方案,SDN的架构如下图所示:

SDN架构

从图中可以看到,SDN从下至上划分为三层体系结构:

  • 基础设施层(Infrastructure Layer): 是网络的数据平面,由各种网络设备构成,根据控制层下发的路由规则对网络数据进行处理和转发。
  • 控制层(Control Layer): 是一个逻辑上集中的控制平面,维护了整个网络的信息,如网络拓扑和状态信息等,控制层根据业务逻辑生成配置信息下发给基础设施层,以管理整个网络的运行。
  • 应用层(Application Layer):通过控制层提供的编程接口,可以编写各种应用利用控制层的能力对网络进行灵活的配置。

SDN的不同层次之间采用标准接口进行通信:

  • 南向接口(Southbound API):数据面和控制面的接口,控制面通过该接口将路由和配置下发到数据面,该接口一般使用OpenFlow、NetConf等网络协议。标准的南向接口解耦了控制层和基础设施层,只要支持标准南向接口的交换机都可以接入到SDN网络中,这样基础设施层可以大量采用支持OpenFlow协议的白盒交换机,解除了厂商锁定,降低了网络成本。
  • 北向接口(Northbound API):控制面向应用层提供的可编程接口,例如RestConf接口。利用控制面提供的编程接口,新的网络业务可以通过存软件的方式实现,大大加快了推出新业务的周期。

微服务面临的问题

在一个微服务系统中,各个独立的微服务之间采用远程调用进行通信。服务发现,请求路由等服务通信相关的功能以代码库的形式存在于各个微服务之中。

微服务之间的通信

该架构也存在和通信网络类似的问题:

  • 不同语言/框架的代码库版本中关于服务通信相关的配置完全不同,需要对不同的微服务单独进行配置,导致微服务的运维非常困难。
  • 应用和服务通信之间的代码耦合导致修改或者增加新的服务通信功能需要修改并升级所有的微服务,如果需要引入新的运维功能,例如支持灰度发布等,则需要修改并升级所有微服务,代价非常大。

Service Mesh是下一代SDN吗?

从上面的分析可以看出,SDN和Service Mesh面临的是类似的问题,既然都是解决类似的问题,那么Service Mesh是否可以看作下一代的SDN呢?

我认为答案是否定的,因为两者之间还是有显著的不同。SDN主要面对L1到L4层,即网络层的基本转发和控制功能;Service Mesh则主要面对L7层及以上,用于处理应用层的服务发现,服务路由等功能,但两者采用了相似的理念,我们可以把Service Mesh看作SDN的理念在应用层的扩展和实践。

SDN和Service Mesh出于网络协议中的不同层次

Service Mesh可以借鉴SDN的架构来解决微服务系统的服务通信的相关问题,如下图所示: Service Mesh架构

我们可以看到,基本上所有的Service Mesh实现都采用了类似上图的的架构,包括IstioLinkerdKuma等。

在该架构中,数据面承担的是一个白盒交换机的角色,不管何种实现,其功能都是类似的,不存在太多争议,目前envoy已经成为数据面的标准实现,因此数据面和控制面之间也采用了Envoy的xDS v2作为标准的数据面协议。

各个Service Mesh项目的创新和争夺的战场主要在控制面上,Microsoft等公司提出了采用SMI(Service Mesh Interface)作为控制面的标准接口,虽然SMI得到了Linkerd,HashiCorp, Solo.io等一干公司的支持,但目前影响最大的Service Mesh项目Istio还未对此进行表态。缺乏统一的控制面标准,控制面之上的应用层生态目前还没有发展起来,基本没有看到有项目对应用层进行宣传。

统一管理硬件设备和Envoy

SDN给Service Mesh带来的一个重要启发是控制面对数据面各种网络设备的统一控制,那么是否可以采用Service Mesh控制面对硬件设备和软件代理进行统一控制呢?

F5网站上提供了一个F5 Big IP和Istio集成的案例。在该案例中, Service Mesh中的微服务需要和一个外部数据库系统进行通信,为了对数据库进行保护,在数据库前放置了一个F5 Big IP设备作为反向代理,并进行下述配置:

  • Service Mesh中的微服务通过F5 Big IP作为代理和后端的数据库通信
  • F5 Big IP和微服务之间采用mTLS,F5 Big IP和数据库之间采用Plain TCP
  • F5 Big IP采用spiffe对微服务进行身份认证,只允许需要访问该数据库的微服务的请求通过

F5的该案例证明了Service Mesh和F5设备之间集成的可能性,但是需要在F5 Big IP设备上进行一系列复杂的配置操作,包括开通服务端口,配置TLS证书,设置认证和访问策略等等。如果Service Mesh控制面可以将F5设备也纳入统一控制,通过控制面统一下发规则,则可以极大简化网络的配置工作,加快业务下发的敏捷性。

采用Service Mesh配置F5 Big IP

利用控制面接口开发应用

SDN的另一个优势是可以通过控制器提供的北向接口快速开发各种SDN应用,而不需要对硬件进行升级,这种模式加快了新业务上线的周期,鼓励各种创新业务蓬勃发展。目前Service Mesh在应用方面尚未有太多实践,但从SDN的发展历程来看,Service Mesh应用层有极大的发展空间。

下图是一个利用控制面接口开发的用户业务订阅及SLA管理的APP示例:

  1. 用户通过APP管理界面订阅服务,并设置SLA(服务水平协议),包括服务的请求次数,服务的响应时间等等
  2. APP将用户订阅及SLA约定转换为运维策略,调用控制面提供的编程接口下发给控制面
  3. 控制面将运维策略转换为数据面标准协议下发给数据面的代理,在代理上,运维策略被转换为代理的配置和转发策略
  4. 代理在收到用户请求时,根据用户标识对用户进行认证,并根据配置和路由策略对用户请求进行处理,例如根据SLA处理用户请求的限流策略,系统忙时优先转发高SLA等级的用户请求,等等。

Service Mesh应用:用户业务订阅及SLA管理

上面只是一个非常简单的应用示例。通过对Service Mesh控制面提供的流量控制,安全策略,拓扑信息、性能指标等基本能力进行组合,并加以创新,可以创建大量端到端的高附加值业务,例如支持业务平滑升级的灰度发布,测试微服务系统健壮性的混沌测试,微服务的监控系统等等。

总结:他山之石,可以攻玉

SDN和Service Mesh的出现都是为了解决类似的网络通信问题,两者都采用了“数据面+控制面”这种类似的架构,但位于网络协议的不同层次。Service Mesh并不是下一代的SDN,但通过借鉴SDN的发展经验,Service Mesh也许可以向下面这些方向发展:

  • 北向接口:北向接口面向业务和运维,具有较高的抽象层次,比较容易提取统一的控制面标准。目前已经有多个公司支持采用SMI作为统一的控制面标准。但SMI的发展也存在一些挑战,例如如何避免SMI成为不同Service Mesh实现之间的最小公共子集,如何扩展支持除HTTP之外的其它应用层协议?
  • 南向接口:Envoy的xDS v2已经成为了南向接口的事实标准,但xDS接口包含有较多实现相关内容,例如Listener, Filter等,这些限制是否会妨碍Envoy之外的其它兼容数据面实现?
  • 对硬件的控制能力:Service Mesh控制面可以提供对数据面软硬件的统一控制能力,以减少软硬件混合环境下的运维复杂度。
  • 应用层的发展:通过北向接口(控制面编程接口)提供出来的能力,可以开发各端到端的创新应用,这也许会成为Service Mesh的下一个热点。

数据中心AI加速芯片的选择 - 老石谈芯

这篇的原文链接:https://zhuanlan.zhihu.com/p/56062418

推动人工智能爆发的最主要原因之一,就是硬件算力的提升。而英伟达的股价当年之所以能够三年涨10倍,就是因为GPU非常适用于深度神经网络的训练。与传统的CPU相比, GPU拥有数千个计算内核,能够在性能上取得上百倍的提升。因此AI就成为了GPU最主要的应用领域之一,也成就了英伟达的高速增长。

随着AI的不断发展,诸如微软和谷歌这样的巨头公司开始考虑在数据中心里采用GPU作为AI加速芯片,这时问题就出现了。在大量部署时,芯片的性能并不是唯一需要考虑的因素。事实上,很多情况下它也并不是最重要的因素。

对于某种AI加速芯片,老石将常见的评价因素总结为五点:性能、灵活性、同构性、成本和功耗。其中:

  • 灵活性:指这种芯片对不同应用场景的适应程度。
  • 同构性:指的是AI加速芯片能否重复利用数据中心现有的架构和资源。
  • 成本:既包括对该硬件加速器的研发投入,也包含了它的采购、部署和运维开支。
  • 功耗:就是指引入该方案后,对数据中心带来的额外功耗负担。

接下来,老石就对几种常见的AI加速芯片,比如GPU、FPGA以及ASIC,采用上述评价因素做一个简单的定性对比。

*GPU*

img

GPU最大的问题是,它基本上是个“功耗黑洞”:中等性能的GPU功耗都普遍超过200W,而高性能GPU的功耗会超过300W。相比于FPGA或ASIC的几十瓦甚至几瓦的功耗而言,这个数字显得过于惊人。

高功耗对于GPU在数据中心里的大规模部署是致命的,因为这不仅代表着高昂的电费开支,还表示数据中心现有的供电、散热等硬件架构需要进行重新修改,这对于同构性和低成本这两项要求而言基本上是不可能的任务。

在灵活性方面,GPU通常只适用于计算密集型运算,对于通信密集型的应用,GPU需要与CPU和网卡组成一个完整的通信系统,因此对于这类应用,GPU的灵活性会受到较大限制。

*ASIC*

img

专用的AI加速芯片以谷歌的张量处理器TPU(Tensor Processing Unit)最为典型。TPU专为谷歌的深度学习框架TensorFlow设计,现在已有第二代,被用来加速神经网络的和决策。ASIC最主要的优势是它的超高性能和超低功耗。与GPU相比,TPU在某些AI应用的性能可以提高一个量级,而功耗会下降一到两个量级。

不过,得到这样高性能和低功耗需要付出的代价就是巨大的研发成本。放眼全球,有资金实力和技术储备进行这类研发的公司,大概用一个手就能数的出来。ASIC的另外一个缺点是它的低灵活性,它通常针对某种特定的应用和算法框架而设计,因此很难直接用于其他的应用。

*FPGA*

img

相比GPU和ASIC,FPGA在各项评价指标中能够达到比较理想的平衡。在绝对性能方面,虽然不如GPU或ASIC,但由于FPGA可以定制化硬件流水线,并且可以进行大规模并行运算,因此相比传统的基于CPU的计算性能还是有着至少一到两个量级的提升。由于FPGA具有硬件可编程的特点,使得它可以应对包括计算密集型和通信密集型在内的各类应用。此外,FPGA独有的动态可编程、部分可编程的特点,使其可以跨空间和时间两个维度,同时处理多个应用,或在不同时刻处理不同应用,因此有很强的灵活性。

功耗和成本方面,FPGA的功耗通常为几十瓦,采购与运维成本远低于GPU。FPGA的开发成本主要涉及购买特定的FPGA设计和调试工具、采购FPGA芯片或加速卡,以及组建团队进行或外包FPGA开发项目等投入。虽不及CPU或GPU等基于软件的开发方式,但由于省去了FPGA芯片制造的相关环节,因此相比研发一款专用芯片而言还是低很多。

此外,FPGA目前通常以加速卡的形式配合现有的通用处理器进行大规模部署,对额外的供电和冷却等环节没有特殊要求,因此可以兼容数据中心的现有硬件体系结构。

AI芯片的最大风险

对于AI芯片的设计者而言,当前最大的风险就是AI本身。在这个群雄争霸的时代,各种新算法、新模型层出不穷,因此在某种方法一统天下之前,很难将其中的任何一种方法固化在芯片上,否则就很可能再次重演以前的小甜甜变成今天的牛夫人这样的悲剧。

比如,为了进一步提升性能功耗比,目前比较流行的方法是使用近似(approximation)算法,例如将双精度浮点数换成低精度的定点数,或者对不同权重的网络分支做剪枝、结构优化和压缩的操作

这些不断涌现的全新AI方法只有通过FPGA才能快速实现,这对于GPU或者ASIC都是不可能完成的任务。

结语

正如老石在之前的文章里提到的,数据中心与AI已经成为各家芯片公司的必争之地。只不过,近期资本市场的表现在某种程度上展示了人们对不同方案的认可度。这也是老石在本文中尝试分析的。

然而,老石并不想立flag断言这些公司的未来,老石只是相信,技术会不断给出自己的答案。