数讯PaaS云平台，是基于Docker和K8S构建、依托OKD为基础的二次开发的平台。其内构建有内部应用市场，提供中间件、数据库、自动化流程，可以快速进行应用构建，容器化和部署贯通从应用开发到测试、上线流程。

利用直观可视化平台服务

为用户带来前所未有体验过的

简单、便捷，和高效！

一 可视化桌面平台

❶ 开发、测试、运维可以在一个平台上协作提高效率▼

❷ 不管是构建pod、service、deploymes、还是基于有状态数据库的stateful sets都无比的轻松便捷▼。

❸ 另外，监控组件提供grafana及日志Prometheus为用户提供运维及监控管理▼。

❹另外，监控组件提供grafana及日志Prometheus为用户提供运维及监控管理▼。

 ❺ 我们提供比较完整的catalog可以供用户进行挑选使用▼。

二 SaaS级网络支持

与传统的PaaS平台最大不一样的地方，在于底层网络的支持。数讯从2014年开始就接触了opencontrail这个SDN技术，目前已经被Linux的CNCF收入作为孵化项目，更名为tungsten fabric，商业版为juniper contrail。数讯目前使用的是tungsten fabric 版本R2003.1.40版。

❶ PaaS网络▼。

❷ 完整的拓扑关系▼。

❸ 监控清晰▼。

❹ 细节完整▼。

❺PaaS的有些应用场景，对网络提出了相当高的要求，及复杂应用方式的功能。这些在我们的SDN来说实现起来非常方便快捷▼。

❻ 我们可以做到为每个网络提供完全不同的功能，比如共享，外部路由模式，透传，多服务链，监控以及反向路径检测等，对于有些特定的环境如组播，我们也有特别的支持▼。

❼ 由于我们的云计算网络使用的是IP-CLOS架构，也就是分underlay和overlay的网络结构，所以在Undelay层面我们使用BGP协议进行互联，使用这样的方式最好的地方在于不管底层网络怎么变换，对于上层的overlay网络是不会有任何感知，也就能足够保障租户网络的安全与稳定，也不用担心数据，路由泄露等问题，除非用户自己因为某些业务场景需要，也可以强制路由泄露▼。

三 L2&L3网络

我们的overlay网络提供L2和L3的转发模式，封装方式提供VXLAN、mpls over udp、mpls over GRE，可以理解为二层网络使用VXLAN东西向方式，三层的话在VXLAN之上在封装MPLS协议的南北向的UDP或GRE。UDP方式更适合基于ECMP多路径负载环境下更为有优势。

❶ 监控路由▼。

 

❷ 监控协议▼。

 

❸ BGP邻居关系▼。

 

云计算网络排障往往是非常痛苦的事情，在我们的云环境中，对于网络的问题的定位可以做到非常精确，在PaaS或者K8S环境中可以根据不同network或者namespace显示出极致明细的路由信息及流表信息。

友好的Portal界面

为了使用者操作更为便捷，数讯通过叠加中间层和前端再开发，打造了一套属于自身特色的引导式平台portal界面，为用户提供PaaS能力服务。从而帮助用户实现统一高效的管理，有更好的体验感受。

另外我们有时候需要IaaS和PaaS进行通讯，而且是在overlay层面通讯，这就对网络提出了非常高的要求，那么我们是怎么做到的呢？

1. 通过策略路由实现互访

默认的Pod网络本身就是VN。因此，作为TFVN，它可以在Openstack上使用，因此我们可能会在该网络上创建一个虚拟机，该虚拟机显然可以连接到我们的Pod。这是可能的，但是，当然，没有理智的人会追求这一点。相反，让VM能够与服务“对话”更为有意义。第一个用例利用了TF网络策略。转换网络策略定义了（在L4处）哪些流量可以在VN之间传递。例如，策略可能只允许任何udp / tcp / icmp流量…全部允许。然后，此策略可能同时应用于VNA和VNB。结果，VNA和VNB可以互相通信。为了允许这种通信，网络策略还会导致两个VN之间的路由泄漏。这样，VNA便知道如何到达VNB的端点，而无需诸如Openstack Router之类的其他对象。这是一种可能的情况：

 

可能情况：

• 我们的服务从外部VN获取外部IP

• 在用户创建的虚拟网络上产生了VM

• 两个VN都应用了网络策略（允许我们要通过的流量）

• 结果， VM可以访问该服务！

2. 通过L3VPN路由互访

在外部网络上分配了外部IP，因此为什么不将VM连接到同一网络：

 

VM可以访问同一VN上的服务。简单，可能不是最好的选择，但是它说明了为VN和VM拥有一个通用的虚拟网络层如何带来灵活性和选项。

 

虚拟网络不过是VRF...我们都从L3VPN知道的那些VRF。这也意味着vRouter可以看作是众所周知的PE。这个比喻实际上离现实并不遥远。作为承载VRF（VN）的PE，vRouter可以将路由目标分配给这些VRF（VN）。除了制定网络策略外，我们可能只是想为在上一个示例中看到的两个VN分配相同的路由目标。这样做，我们将隐式地实现路由泄漏……vRouter是一个PE，VRF根据路由目标导入路由…良好的旧路由。

 

3. 通过外部Gateway硬件（PNF）互访

这种情况下可行，但有时可能并不理想。例如，假设您要通过SDN GW将VM VN转换为外部转换。SDN GW也是PE，因此它将具有一个具有匹配路由目标的VRF，在这种情况下为X。通过此设置，在SDN GW上，我将拥有来自VN，外部fip网络和VM网络的路由…它们具有相同的RT，这是SDN GW上的VRF所查看的，以便从bgp导入/复制路由。l3vpn.0表。隐含地，我们也将外部fip网络带到了外面……即使最初我们只想要VM网络。

这只是一个示例，显示了不同用例如何适合一个或另一个场景。好消息是我们具有灵活性，因此可以在不同情况下提出适当的解决方案。根据我们刚才所说的，这个用例现在应该很清楚了。诀窍是在外部网络VN上分配路由目标，并在SDN GW上具有匹配的VRF：

可能情况：

• SDN GW与TF控制器对话BGP

• TF控制器发送具有路由目标X的fip网络路由

• SDN GW将路由安装到bgp.l3vpn.0表，并根据路由目标将其复制到VRF

• SDN GW向运行服务Pod的计算节点构建动态MPLSoUDP隧道

我们说，多个MPLSoUDP隧道是指服务背后的Pod正在运行在不同的工作程序（计算节点）上，因此我们希望有多个ECMP路径吗？这些都是所有可能的用例吗？

当然不是！但是，我们看到了许多关键概念：名称空间隔离，自定义Pod网络，自定义服务网络，外部网络，通过网络策略或路由目标进行的路由泄漏等等……到现在，我们应该已经意识到，通过结合这些部分，我们可以得到我们想要的难题；建立新的用例并尝试支持我们面临的不同情况！

最后我想说的是，数讯在云计算市场上海属于默默无闻的跟随者，但数讯是运营商和数据中心供应商出身，对于网络的理解可能比传统做云的企业认识的更为深刻，所以数讯的云平台在基于各种优秀的开源平台上构建了一些不一样的东西，希望能为企业用户在复杂的环境中提高一点便利。

 

作者简介：钱誉   上海数讯云计算事业部总经理

 

关于云计算事业部

上海数讯信息技术有限公司云计算业务事业部，于2020年1月2日正式建立。事业部承袭了数讯信息原云计算开发部此前五年的研究成果，引入先进资源和人才，致力于快步提升自主研发的创新型云服务，创建“企业多云管理、运维简捷高效”的云管理平台！

事业部自主知识产权研发的数讯云，为大数据、人工智能、企业数字化转型等多领域发展提供助力！