Keep learning, keep living...

0%

NSX是VMware公司在vSphere平台上的网络虚拟化解决方案。从架构上分为四层, 如图:

  • 消费平面: 云管平台CMP(Cloud Management Platform)不是NSX的组件,NSX提供了丰富的REST API, 可根据需要集成NSX。
  • 管理平面: NSX Manager是NSX的集中管理器,主要功能包括管理NSX Controller集群,管理EDGE节点,为上层消费平台提供管理和配置接口。NSX Manager自身实现了vSphere vCenter插件,可注册在vCenter中,通过GUI进行管理。
  • 控制平面: 控制平台主要包括NSX Controller集群,Controller负责维护所有ESXi主机、逻辑交换机(Logical Switch)和分布式逻辑路由器(DLR: Distributed Logical Router)的信息。实际上,控制平面还包括DLR的Control VM, 上图中没有体现。上图来自官方6.4版本的文档, 在之前的官方的架构图中,曾经是体现出来的。后文会再介绍它的作用。
  • 数据平面: 数据平面主要包括NSX Virtual Switch, DLR, 和ESG: Edge Service Gateway。按图中表示,NSX Virtual Switch是基于vSphere的分布式交换机并在内核中实现VXLAN、防火墙过滤、分布式路由等功能的逻辑交换机。我个人更倾向将NSX Virtual Switch理解为VDS+VXLAN实现,将DLR看成独立组件。VDS可以理解为基于VLAN隔离的虚拟交换机,NSX Virtual Switch是基于VXLAN隔离的虚拟交换机。NSX界面上,NSX Virtual Switch叫做逻辑交换机: Logical SwitchDLRESG都是路由器,DLR负责虚拟数据中心中东西向流量路由,ESG负责虚拟数据中心边缘的南北向流量路由。其他数据面组件都在ESXi主机内核中实现,而ESG是独立的虚拟机。 NSX的一个典型逻辑网络架构如下图:
阅读全文 »

很多业务场景都需要在后台定期执行任务,如数据ETL(Extract-Transform-Load)操作。简单处理可通过crontab来管理。当任务需要在多台机器上执行,或者任务之间有依赖关系时,crontab便不太能满足需求。这种场景下需要分布式任务调度系统来组织任务编排,管理任务依赖,调度任务工作流和监视任务执行状态。

比较优秀的开源解决方案有:

Azkaban和Oozie都更聚集在大数据处理平台上的任务调度,Airflow的应用场景更为通用。本文简单介绍Airflow。

Airflow使用Python开发,它通过DAGs(Directed Acyclic Graph, 有向无环图)来表达一个工作流中所要执行的任务,以及任务之间的关系和依赖。比如,如下的工作流中,任务T1执行完成,T2T3才能开始执行,T2T3都执行完成,T4才能开始执行。

阅读全文 »

互联网服务为了保证高可用和可扩展性,在流量入口一般都需要部署负载均衡设备。负载均衡设备可分为4层(传输层)和7层(应用层)。L4负载均衡设备之前较为流行的方案是LVS,后来各大厂商又基于DPDKXDP/eBPF等技术实现了性能更高的一些方案, 如:

无论以上哪种实现,流量分发的部署方案都类似, 都是由LB集群中多个服务器通过BGP或者OSPF协议向网络设备宣告相同的IP地址(VIP),网络设备通过ECMP路由将流量分散到这些服务器中。当其中某些LB服务器异常宕机或者维护下线时,网络设备会通过OSPF或者BGP协议的路由收敛机制检测到LB服务器下线,迅速将流量切走, 实现服务高可用。

本文来实验基于ECMPOSPF的负载均衡。Cumulus是一个基于Linux的网络操作系统(NOS:Network Operation System), 运行于白牌交换机上。Cumulus VX是Cumulus的免费虚拟设备,可以以虚拟机形式运行。本文就使用Vagrant, VirtualBox, Ubuntu, Cumulus VX来构建我们的实验拓扑。结构如图:

阅读全文 »

VXLAN现在主要有以下几种类型的控制面:

  • 基于集中的SDN控制器
  • 基于IP多播实现洪泛与学习
  • 基于单播的HER(Head-End Replication)洪泛与学习,即在入口VTEP处实现包复制,通过单播发送给需要洪泛的所有VTEP
  • 基于BGP EVPN(Ethernet Virtual Private Network)

VMware NSX方案是基于SDN控制器。而之前的两篇关于VXLAN的文章<<动态维护FDB表项实现VXLAN通信>>和<<VXLAN原理介绍与实例分析>>中, 我们实验的方式是基于多播和单播的方案。本文我们来介绍基于BGP EVPN的VXLAN控制面。

BGP EVPN是一个标准的控制面协议,由RFC7432定义。它支持三种数据面: MPLS、PBB、NVO(Network Virtualization Overlay)。VXLAN是NVO方案中的一种,它的EVPN应用由RFC8365定义。BGP EVPN依赖BGP协议MP-BGP扩展。BGP是支撑互联网的主要协议,用于在网络设备之间同步路由信息。MP-BGP扩展能够将BGP所同步信息扩展到多种协议,如IPv4, IPv6, L3VPN和EVPN等。EVPN地址族用来传递MAC地址以及这些MAC地址所挂接的设备IP。

阅读全文 »

之前的文章<<VXLAN原理介绍与实例分析>>简要介绍了VXLAN的基本概念和基于组播的通信过程实例。其中控制面是混合在数据面中的,由洪泛(flood)和源地址学习实现。本文通过实例将控制面从数据面中分离,手动维护FDBARP表项实现通信过程。

对于大规模的VXLAN网络中,最核心的问题一般有两个:

  1. 如何发现网络中其他VTEP
  2. 如何降低BUM(Broadcast, Unknown unicast, Multicast)流量

在对于问题一来说,之前的文章中的解决方法是洪泛,对于问题二,则通过源地址学习来确定MAC地址的归属。VXLAN的转发过程主要依赖FDB(Forwarding Database)实现。二层网桥的FDB表项格式可表达为:

1
<MAC> <VLAN> <DEV PORT>

VXLAN设备的表项与之类似,可以表达为:

1
<MAC> <VNI> <REMOTE IP>

VXLAN设备根据MAC地址来查找相应的VTEP IP地址,继而将二层数据帧封装发送至相应VTEP。

如果我们能够从集中的Controller或者存储中获取VTEP信息以及MAC地址与VTEP的对应信息,则问题一和问题二都可以通过根据相应信息动态更新FDB表项来解决,OpenStack的Neutron, VMware的NSX,Docker Overlay都有类似的思路。

下面我们通过实例来手动更新FDB表来实现VXLAN通信。我们的实验环境如下图, VTEP本地使用Linux bridge来挂载连接到network namespace中的veth pair虚拟网卡,我们要实现3.3.3.3二层访问3.3.3.4

阅读全文 »

应用服务常常需要存取各种各样的机密信息,比如,数据库的访问凭证,依赖的外部服务的TokenKey,服务之间的通信凭证等等。在每个这样的应用中都重复实现机密信息的存取、更新与吊销等管理操作相当繁重,而且容易出问题。HashiCorp公司的开源项目Vault就将这部分工作以独立服务方式来实现,需要机密信息操作的应用可以与Vault服务交互完成相应的操作。

Vault的应用场景非常广泛,如:

  • 机密信息存取
  • 凭证的动态生成,比如数据库凭证、PKI证书、公有云服务的凭证等等
  • 加密即服务

Vault架构非常清晰,如下图所示,主要分为三部分:

  • HTTP/S API: Vault服务对外提供HTTP API接口
  • Storage Backend: 负责加密数据的持久化存储, Vault支持多种存储机制。
  • Barrier: 负责各种机密信息相关的处理逻辑,最核心的组件是Secrets EngineAuth MethodSecrets Engine负责实际机密信息处理功能的实现,各种不同的Secrets Engine有着不同的功能服务,Auth Method提供各种不同的身份校验方法。这两个组件都依赖Plugin机制实现,如果官方提供的功能不满足需求,还可以自己写相应Plugin实现特有功能或身份校验方法。
阅读全文 »

Photo by Lukas from Pexels

Kubernetes中, 所有的功能实现都以资源(Resource)形式体现。简单来说,资源就是Kubernetes的API端点(endpoint),用于存储某种类型的对象。用户通过对资源对象的CRUD操作完成相应功能管理。Kubernetes 1.7之后添加了自定义资源(Custom Resource)的扩展能力,允许使用者通过定义自己的资源类型来扩展Kubernetes API,大大增强扩展Kubernetes的灵活性。这些自定义资源和PodDeployment等原生资源对象的操作方法基本一样。

用户使用CRD(Custom Resource Definitions)来定义自定义资源(Custom Resource)。CRD被创建后,Kubernetes APIServer会为CRD中指定的资源版本创建相应的RESTAPI端点。

CRD可以通过YAML文件来创建,YAML文件中指定CRD对象的规范,其中比较重要的字段有:

  • metadata.name: 要创建的CRD名称
  • spec.group: CRD对象所属的API组
  • spec.version: CRD对象所属的API版本
  • spec.names: 管理自定义资源所需要的名称描述,可以定义plural(复数名称), singular(单数名称)和shortnames(简称)等字段
  • spec.names.kind: 指定自定义资源的类型名称
  • spec.scope: 指明自定义资源有效范围,可以是整个集群有效(clustered)或命名空间内有效(namespaced)
阅读全文 »

在应用开发中,应用程序往往需要跟据特定策略的决策结果来判断后续执行何种操作。比如,权限校验就是策略决策的一种典型场景,它需要判断哪些用户对哪些资源能够执行哪些操作。这些策略可能随着时间需要不断的动态更新。当前策略决策的逻辑往往硬编码实现在软件的业务逻辑中,当需要更新策略规则集时,还需要修改应用代码、重新部署应用,非常不灵活。同时,不同的应用服务也都需要重复实现类似的功能,因而策略决策逻辑非常适合做为独立的模块从业务逻辑中抽离出来。

Open Policy Agent,官方简称OPA, 为这类策略决策需求提供了一个统一的框架与服务。它将策略决策从软件业务逻辑中解耦剥离,将策略定义、决策过程抽象为通用模型,实现为一个通用策略引擎,可适用于广泛的业务场景,比如:

  • 判断某用户可以访问哪些资源
  • 允许哪些子网对外访问
  • 工作负载应该部署在哪个集群
  • 二进制物料可以从哪些仓库下载
  • 容器能执行哪些操作系统功能
  • 系统能在什么时间被访问

需要注意的是,OPA本身是将策略决策和策略施行解耦,OPA负责相应策略规则的评估,即决策过程,业务应用服务需要根据相应的策略评估结果执行后续操作,策略的施行是业务强相关,仍旧由业务应用来实现。

OPA的整体逻辑结构如下图:

阅读全文 »

在一些场景下,运行在CloudFoundryKubernetes等平台上的Cloud Native应用需要使用各种各样的外部服务,如数据库,消息队列等。但应用开发者并不想关心这些服务的配置、管理和位置等信息,以便将精力集中在业务逻辑开发上。为了满足这种需要,CloudFoundryGoogle等一系列公司创建了Open Service Broker API(OSBAPI)项目,致力于将外部服务的生命周期管理,应用平台与服务代理的交互,服务实例的访问等内容标准化。

OSBAPI规范定义了高度抽象的应用平台与外部服务代理的交互逻辑,规范化外部服务的使用,主要包括:

  • 注册服务代理: 应用平台会获取服务代理提供的服务列表及相应规格,OSBAPI使用术语Plan来表示规格。
  • Provision服务实例: OSBAPI使用术语Provision来统一指定服务资源的供应。在外部服务具体实现上,可以是创建虚拟机实例,也可以是分配资源,也可以是创建SaaS帐号等等。
  • 绑定应用及服务实例: 当服务实例创建完成后,开发者想要其应用与该服务实例进行交互。从服务代理的角度来看,就是将应用与服务实例进行绑定。具体实现逻辑可以非常灵活,一般情况下,会生成访问该服务实例所需的新凭证。比如,生成数据库实例的IP、端口、用户名、密码等等。这些凭证会被返回给应用平台以提供给具体应用使用。

OSBAPI的具体工作模式如下图:

阅读全文 »

之前的文章<<Ansible入门>>介绍了做为自动化配置管理的Ansible,这篇文章简要来介绍Python远程执行库Fabric

Fabric是一个通过SSH远程执行SHELL命令的库,主要用于自动化的安装部署及远程管理任务。Ansible也能够实现Fabric的这些能力,但Fabric更为轻量,只是单纯地用于远程执行。它本身是一个Python库,可以在我们自己的Python程序中直接import,并基于它实现远程命令执行。此外,它还提供了一个fab命令行工具,使用它可以更简单地编写我们需要执行的任务。这种模式被使用的更为普遍,我们主要来介绍以fab命令来使用fabric。

需要注意的是,Fabric的2.x版本并不兼容1.x版本,而且2.x版本很大程度上边缘化了fab命令行工具,因而我们还是来介绍1.x版本。当前最新1.x版本为1.14, 文档地址为:http://docs.fabfile.org/en/1.14/。

阅读全文 »