neutron 分支的入口类是NeutronProvider，它会实例化NeutronNetworkChangeListener和PortDataChangeListener，它分别监听DataStore中由Neutron-Northbound更新的Neutron- Network 和NeutronPort。NeutronProvider还会实例化OvsdbDataChangeListener，用于监听 OpenStack节点的上线以及虚拟机实例的接入。这些***ChangeListener都会调用 implementation 中的模块来实现对应的业务逻辑。 在OpenStack环境中，OvsdbDataChangeListener首先会通过监听DataStore得知 OpenStack 节点的上线。OvsdbDataChangeListener对该事件进行处理，最终会走到neutron. impl.OVSDBEventHandler 的 nodeAdded方法。nodeAdded方法主要做了两件事情:写 DataStore 驱动OVSDBPlugin，在节点上建立br-int，然后写DataStore将节点的 eth0添加到br-int上。这里要注意的是，由于VTNManager的Underlay网络可以都是OpenFlow 设备，因此在nodeAdded方法中没有必要为br-int添加隧道端口和隧道逻辑。可以看到，后面implementation中VBridge的转发逻辑也并没有用到隧道。----.........*neutron.imp1.oVSDBEventHandler_----- publie void nodeAdded () public final class OVSDBEventHandler// 探测到节点上线 it (key i=null) if (addBridge()) it (lieBridgeOnOvadbNode ())// 在节点上建立br-int// 将节点上的etho 绑定到 br-int上 addPortToBridge (): 上述工作结束后，OpenStack节点的初始化就完成了。接下来，OpenStack用户会建 Network、Subnet和Router。目前VTN的实现仍然是比较简单的，并不支持L3的通信， Subnet API和Router API在VTN Manager中都还没有相应的代码实现。 NeutronNetworkChangeListener监听到由Neutron-Northbound更新的NeutronNetwork后，会调用NetworkHandler的 neutronNetworkCreated方法，这个方法再调用VTN- Managerlmp1 的updateBridge方法，该方法会通过RPC调用implementation分支中相应的 VBridgeManager模块，为这个NeutronNetwork创建对应的VBridge。VTN目前并不支持 L3的通信，NeutronNetwork和VBridge在实现中也因此为一一对应的关系。 同样，PortDataChangeListener监听由Neutron-Northbound更新的NeutronPort后，调用createPort方法，createPort 方法会获得NeutronPort所在的NeutronNetwork和该Neutron- Netowork 对应的VBridge，然后调用VTNManagerImpl的updateInterface 方法，该方法会通过RPC调用implementation分支中相应的VInterfaceService模块，生成一个VInterface并添加到对应的VBridge上。 ----==========neutron.impl.NetworkHandler --= public final class NetworkHandler publie void neutronNetworkCreated() if (result != HTTP_OK) else result = vtnManager.updateBridge(); --neutron.impl.PortDataChangeListener ==---------= public final class PortDataChangeListener private void createPort () it (port -- null) else int result = vtnManager,updateInterface(); 到这里，VTN Manager主要的初始化工作就完成了。可能有读者会觉得很奇怪，前面介绍的Netvirt Plugin 中的OVSDB-Neutron和VPNService在初始化时，业务逻辑可是相当复杂的，会下发很多的流表以保证虚拟机的通信，为什么VTN Manager的初始化工作却这么简单呢? 在本节的开始提到过，VTNManager的设计目标是通过OpenFlow实现泛化的网络虚拟化。它的实现思路是，首包都Packetln给控制器，控制器会仿真流量在租户网络中的处理，然后根据仿真结果下发流表，后续的流量直接匹配流表进行转发。因此，当VTN Manager 与OpenStack进行对接时，仍然保留了这种Reactive的设计思路，初始化的工作

数据包在Virtual Domain中转发时，会经过各个kerne1 VNF的处理，下面会对一些典型的VNF的工作原理进行介绍，帮助读者理解PLUMgrid ONS对于数据包的处理机制。虚拟机发出的数据包会被kernel中的PEM模块截获，PEM会根据vNIC找到其所属的 Virtual Domain，并将其定向给Virtual Domain中与该虚拟相连的第一个kernel VNF进行处理-通常第一个kernelVNF会是Bridge。BridgeVNF由datapath上的Bridge PLUMlet(PLUMlet即为kernel VNF)和Director中的Bridge CP组成，如图4-114所示，Bridge PLUMlet会进行MAC自学习，并根据目的MAC地址进行转发。对于目的MAC地址已知的单播流量，如果目的在本地则直接进行转发，如果目的在远端的Edge上则需要封装 VxLAN包，其中tunnelid标识的是目的虚拟机，而不是租户，因此目的虚拟所在的host做完VxLAN解封装后会直接根据tunnel id从相应的vNIC转发出去，这点和对于BUM流量，如果其目的IP地址已知，则转为单播发送(主要针对ARP);如果目的IP地址未知，则BridgePLUMlet会将其上报给BridgeCP，由BridgeCP完成数据包的复制，并向其他在同一个Virtual Domain中注册过的Bridge PLUMlet进行泛洪。NVP/Midonet中的设计是一样的。虚拟机发出的第一个数据包通常会是DHCPDiscover的广播。根据上一段中的介绍，Bridge PLUMlet会将这个Discover发送给Bridge CP，BridgeCP会通过这个包学习到源MAC地址和 Edge的对应关系，记录下来作为VxLAN的控制信息。然后这个DHCP Discover会被复制并泛洪回Bridge PLUMlet,BridgePLUMlet发现这是一个从Bridge CP发送的DHCP Discover，认为BridgeDomain已经学习到了VxLAN的控制信息，于是将该 DHCP Discover定向到DHCPPLUMlet上，DCHPPLUMlet并不具备处理DCHP包的能力，于是将这个DHCP Discover上报给DHCPCP，DHCPCP将作为DHCPServer将可用的IP地址回复给虚拟机。DHCP后续的交互就是单播了,Bridge将根据目的MAC地址进行转发，跨网段的东西向流量需要经过RouterVNF的处理，在两个Bridge的子网间进行路由。VM1首先广播ARP请求默认网关的MAC地址，通过对Bridge VNF的介绍可知这个ARP会被转成单播发送给Router PLUMlet,Router PLUMlet不具备处理 ARP包的能力，将其上报给Router CP,RouterCP单播回复在该子网下接口的MAC地址。收到ARP Reply后，VMI向另一个子网中的VM4发起通信，数据包首先到达Router PLUMlet，然后Router PLUMlet会查询路由表，那么，根据下一跳来改写MAC地址然后发送到下一跳所在的Bridge PLUMlet上。

下面开始介绍Neutron的网络结构，对于Nova-network和Quantum本节暂不讨论。首     先需要对Neutron中的3类节点和3种网络进行介绍。(1)3类节点 控制节点实现像、存储、身份认证、前端等服务，运行Nova-compute的调度模块以及Nova api-server。计算节点实现Nova-compute，以及Neutron的一些Agent。网络节点实现Neutron 的一些Agent。注意，由于OpenStack为分布式架构实现，因此Neutron- server 既可以运行在控制节点中，也可以运行在网络节点中。 (2)3种网络 OpenStack内部模块之间的交互发生在管理网络，虚拟机之间的通信发生在数据网络，而External Network/API Network网络是连接外网的，无论是用户调用Openstack API,还是虚拟机与外网间的互通都需要经过这个网络。目前OpenStack通常采用Out-of-Band 方式进行部署，管理网络与另外两个网络是独立的，也不涉及复杂的组网需求，本章后续内容的分析只针对数据网络与External Network/API Network 网络。 Neutron的数据网络支持3种常见的网络类型，包括Flat、VLAN和 Overlay。(1)Flat类型 Flat 类型最为简单，所有的虚拟机共用一个私有IP网段，IP地址在虚拟机启动时完成 网段的网关上进行 NAT。 注入，虚拟机间的通信直接通过HyperVisor中的vBridge/vSwitch进行转发，公网流量在该NAT上使用。(2)VLAN类型     VLAN类型引入了多租户机制，虚拟机可以使用不同的私有IP网段，一个租户可以拥有多个IP网段。虚拟机IP通过DHCP获取。网段内部虚拟机间的通信直接通过 HyperVisor 中的vBridge/vSwitch进行转发，同一租户跨网段通信可以通过vRouter做路由，公网流量在该网段的网关上进行NAT。 (3) Overlay类型 1）Overlay类型利用隧道技术进行隔离和传输，相比于VLAN类型有以下改进。1)租户数量从4096增加到1600万; 2)租户内部的二层通信可以跨越底层的IP网络，虚拟机能够迁移到任意位置;3)一般情况下，不需要对底层网络进行任何额外的配置。

有了这些传输路径做基础，再加上Packet Switching ASIC、CrossPoint和收发器所提供的可编程能力，控制平面能够对光路径进行非常灵活的调度。不过，Plexxi并没有采用纯集中式的控制，其控制平面的架构是层次化的，除了Out-of-Band的Plexxi Control外，还有分布于各个Plexxi Switch本地的Co-Controller。  1.Co-Controller     Co-Controller的作用是实现分布式的基础转发，而并不负责对光路径进行优化。Co- 身就具 Controller 的主要功能包括邻居的发现、Reactive式的二层转发、路径负载均衡、路径监测 供了车 以及快速重路由。下面来具体说一下基础转发的过程，考虑一个多跳传输的场景，A向B发起通信:①当A所在的ToR收到ARPRequest的广播后，会向所有位于相同VLAN的本地端口以及所有的Local Channel(包括east-towards和west-towards两个方向)进行泛洪，并将该数据包上送给Co-Controller,Co-Controller完成MACA的学习，并通过一种私有的协议在交换机间发布该MAC地址。②East-towards方向的过路交换机收到该ARP Request后，同样也会向所有和A位于相同VLAN的本地端口以及所有east-towards方向的Local Channel进行泛洪，不过对于从光口传进来的数据包并不会上报给Co-Controller进行学习，而是通过A所在的ToR所宣告的MAC路由来学习。West-towards方向上同理。该过程一直持续下去，最终B会收到该ARPRequest。③B把 ARP Reply单播出来以后，B所在的 TOR会上报给Co-Controller,Co-Controller会通过散列在多条光路径间进行负载均衡，这些路径包括east-towards 和 west-towards中距离A较近的方向上的Local Channel以及可以直达A所在ToR 的 Express Channel。 2.Plexxi Control 对应地，PlexxiControl只负责对光路径进行优化，也就是说，即使它宕掉了，也不会影响到基本的互通性。PlexxiControl对光路径进行优化的工作流程为:①收集所有交换机中的信息，主要包括Local Channel和ExpressChannel的分配以及MAC的接入位置，并根据上述信息形成网络的全局视图。②将AffinityModel和全局视图输入Algorithmic Fitting Engine中，为Affinity Group间的通信计算出符合AffinityAttributes的光路径，这被称为 FSAT。③完成FSAT 的计算后，剩余的光路径可用于传输那些并没有指定 Affinity的流量. Algorithmic Fitting Engine同样会为这部分流量计算出加权的光路径，这被称为PSAT。实际上可以将 PSAT理解为对于Co-Controller所实现的基础转发的优化。④FSAT和 PSAT是由Plexxi Control 自动生成的，对于用户来说属于一种隐式的路径优化。PlexxiControl 还提供了一种UDT的方式，允许用户显式地指定传输特定流量的光路径。⑤如果现有的光路径不能满足上述的优化需求，那么PlexxiControll还会调整CrossPoint和收发器，以对光路径进行重构。⑥上述步骤都完成后，PlexxiControl会将结果主动地推给交换机，并通过2-phase commit来保证一致性。 以光传输为技术主体来构建数据中心网络，这种思路多见于学术界的研究中，Plexxi将其产品化的做法可以说是革命性的，超越了当时甚至是目前工业界对于数据中心网络的理解。不过，与应用的紧密关联使得Plexxi在网络优化领域形成了独到的优势，吸引了一些有相关需求的用户。同时，光传输所带来的高带宽、低时延和稳定性，也使得Plexxi在 Plexxi已经开始将重心转向了超融合网络架构的构建。    存储的场景中找到了一些机会。超融合的兴起为Plexxi提供了汇聚自身优势的抓手。

PLUMgrid 的技术基石是IOVisor，而要了解IOVisor，就必须先了解eBPF。众所周知，网络协议栈的设计和实现都是分层的，数据包经过协议栈时包头会被逐层剥掉，应用 虚拟 层是看不到L2~L4的头的。如果想要实现vSwitch 或者vRouter，必须要看到L2/L3的 ter, 头，此时通常需要对协议栈进行修改(内核旁路技术除外)，通过在Linux协议栈中插入 vice    hook 点，将数据包从通用的协议栈处理流程中“钩”出来，以对数据包进行自定义的处理。     租户    BPF(BerkeleyPacket Filter，伯克利数据包过滤器)是一种著名的数据包捕获机制，用户可     NS,    以编写自己的 BPF程序，将其hook到协议栈特定的位置，然后将满足某些特征的数据包过     滤出来并送到user space 中进行处理。BPF可以在3个位置做hook,在raw socket处“钩”出来的是完整的有L2头的数据包，在streamsocket处“钩”出来的是以UDP头为起始的数据包，在datagramsocket处“钩”出来的是以TCP头为起始的数据包。比如想获得所有 HTTP 的包，就可以自己写一个BPF程序去匹配80端口，然后将关联到datagram socket 的 hook 点上即可，如图4-110所示。Linux在很早的版本中就提供了对BPF的支持，很多大家耳熟能详的网络程序都是通过BPF来实现的，包括TC、DHCP、nmap、libcap等。 不过由于实现上的原因，BPF能够支持的功能十分有限，比如只有2个寄存器，寄存器是32位的,对数据包进行处理的指令也很少，只能对数据包进行解析和匹配，因此BPF主要用来对数据包进行过滤，难以实现更为复杂的网络处理功能。eBPF( extended BPF) 的提出解决了 BPF的上述问题，主要体现在以下几个方面。 □寄存器资源更为充足，能够提供10+的 64位寄存器。 口指令更为丰富，eBPF程序能够对数据包字段进行改写、移位、交换等操作，因此 eBPF程序能够实现更为复杂L2~L7的 kernel VNF。 支持key/value的数据结构bpf_map，可以通过用户空间将网络表项(如MAC表、路由表、NAT表等)注入内核的eBPF程序中，eBPF程序会据此进行查找与转发。 bpf_map中存有一类特殊的映射关系，记录每个eBPF程序的文件描述符，因此不同的eBPF的内部结构如图4-111所示。eBPF程序间能够实现灵活的跳转，可以非常方便地实现服务链。

还在对集群成本评估感到束手无策？还在担心不合理的K8s集群资源浪费？华为云云原生全新上线云原生FinOps成本治理中心，为用户提供多维度集群成本可视化，结合智能规格推荐、混部、超卖等成本优化手段，助力客户降本增效。 4月24日（周三）16:30-18:00，华为云云原生DTSE技术布道师 Roc老师将带来《华为云云原生FinOps解决方案，为您释放云原生最大价值》直播分享。华为云云原生FinOps解决方案通过可视化的成本洞察和成本优化，帮助用户精细用云以提升单位成本的资源利用率，实现降本增效目标，本期直播通过云原生上云现状分析及华为云FinOps方案及实践解析，系统化解析华为云云原生一系列云原生FinOps技术 ，为企业与用户提供企业上云成本管理的最优路径。▍直播精彩看点企业上云现状与云原生FinOps优势华为云云原生FinOps解决方案云原生FinOps成本展示与成本分析云原生FinOps成本优化华为云CCE云原生成本治理功能演示▍直播观看平台华为云官网 华为云开发者联盟视频号、CSDN、B站、虎牙、微博华为云视频号、快手、B站、虎牙、微博▍看直播 赢定制礼品 福利1 | 专家坐堂有奖： 即日起-4月25日，在指定论坛贴提问，评选优质问题送华为云定制POLO衫。 福利2 | 互动有礼： 官网直播间发口令“华为云 DTSE”抽华为云定制雨伞。福利3 | 有奖提问：直播过程中提问，评选优质问题送华为云定制长袖卫衣。扫码体验华为云CCE获取华为云云原生FinOps方案▼▼▼

HCS830，每星期使用自动作业---操作管理---内置操作中的自动批量定时快照，执行的数量是每次都保存1个，那么我每次执行完都会自动覆盖掉上星期的整机快照，但是每次快照审计完后都会显示有野子快照残留，都需要去清理，这是什么原因导致的呢，有什么方法可以规避吗

 1.背景介绍 云计算是一种基于互联网和服务器集群的计算模式，它允许用户在远程服务器上存储和处理数据，而无需购买和维护自己的硬件和软件。随着数据量的增加，云计算在各个领域的应用也逐渐普及。然而，随着数据量的增加，数据库和存储系统也面临着挑战。在这篇文章中，我们将讨论云计算的未来，以及如何应对数据库和存储的挑战。  2.核心概念与联系 在云计算中，数据库和存储系统是关键组成部分。数据库用于存储和管理数据，而存储系统则用于存储数据库和其他应用程序的数据。云计算为数据库和存储系统提供了灵活性和可扩展性，但同时也面临着挑战。  2.1 数据库 数据库是一种用于存储和管理数据的系统，它可以存储和管理结构化数据、非结构化数据和半结构化数据。数据库可以分为关系型数据库和非关系型数据库。关系型数据库使用表格结构存储数据，而非关系型数据库则使用其他数据结构存储数据。  2.2 存储系统 存储系统是一种用于存储数据的硬件和软件组件，它可以存储数据库和其他应用程序的数据。存储系统可以分为本地存储和云存储。本地存储使用物理硬盘存储数据，而云存储则使用远程服务器存储数据。  2.3 联系 数据库和存储系统在云计算中有紧密的联系。数据库用于存储和管理数据，而存储系统则用于存储数据库和其他应用程序的数据。数据库和存储系统之间的联系可以通过API进行交互，以实现数据的读取和写入。  3.核心算法原理和具体操作步骤以及数学模型公式详细讲解 在云计算中，数据库和存储系统需要处理大量的数据。为了提高数据处理的效率，需要使用算法和数据结构。以下是一些常用的算法和数据结构：  3.1 二分查找 二分查找是一种用于查找有序数组中元素的算法。它的基本思想是将数组划分为两个部分，然后根据元素是否在数组的左半部分或右半部分来判断元素的位置。二分查找的时间复杂度为O(logn)。  二分查找的具体操作步骤如下：  设置两个指针，一个指向数组的开始，一个指向数组的结束。 计算中间位置，并将中间位置的元素与目标元素进行比较。 如果中间位置的元素等于目标元素，则返回中间位置。 如果中间位置的元素小于目标元素，则将开始指针设置为中间位置的下一个位置。 如果中间位置的元素大于目标元素，则将结束指针设置为中间位置的上一个位置。 重复步骤2-5，直到找到目标元素或者指针指向的范围为空。 3.2 哈希表 哈希表是一种用于存储键值对的数据结构。它使用哈希函数将键映射到一个固定大小的索引表，从而实现快速的查找和插入操作。哈希表的时间复杂度为O(1)。  哈希表的具体操作步骤如下：  定义一个索引表，用于存储键值对。 定义一个哈希函数，将键映射到索引表的某个位置。 对于每个键值对，使用哈希函数将键映射到索引表的某个位置，并将值存储在该位置。 对于查找操作，使用哈希函数将键映射到索引表的某个位置，并返回存储在该位置的值。 3.3 排序算法 排序算法是一种用于对数据进行排序的算法。常见的排序算法有插入排序、快速排序、归并排序等。排序算法的时间复杂度取决于所使用的算法。  3.4 数学模型公式 在云计算中，数据库和存储系统需要处理大量的数据，因此需要使用数学模型来描述数据的特性和关系。以下是一些常用的数学模型公式：  平均值(average)：$$ \bar{x} = \frac{1}{n} \sum{i=1}^{n} x{i} $$ 中位数(median)：对于有序数组，中位数是数组的中间元素。 方差(variance)：$$ \sigma^{2} = \frac{1}{n} \sum{i=1}^{n} (x{i} - \bar{x})^{2} $$ 标准差(standard deviation)： σ=σ2−−√ � = � 2 4.具体代码实例和详细解释说明 在云计算中，数据库和存储系统的代码实例主要包括数据库的创建、查询、更新和删除操作，以及存储系统的读取和写入操作。以下是一些具体的代码实例和详细解释说明。  4.1 数据库 4.1.1 创建数据库 在MySQL中，可以使用以下代码创建数据库：  sql CREATE DATABASE mydatabase;  4.1.2 查询数据库 在MySQL中，可以使用以下代码查询数据库：  sql USE mydatabase;  4.1.3 更新数据库 在MySQL中，可以使用以下代码更新数据库：  sql ALTER DATABASE mydatabase MODIFY CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;  4.1.4 删除数据库 在MySQL中，可以使用以下代码删除数据库：  sql DROP DATABASE mydatabase;  4.2 存储系统 4.2.1 读取存储系统 在Python中，可以使用以下代码读取存储系统：  ```python import requests  url = 'http://example.com/data' response = requests.get(url) data = response.json() ```  4.2.2 写入存储系统 在Python中，可以使用以下代码写入存储系统：  ```python import requests import json  data = {'key': 'value'} url = 'http://example.com/data' response = requests.post(url, data=json.dumps(data)) ```  5.未来发展趋势与挑战 在云计算的未来，数据库和存储系统面临着以下挑战：  大数据：随着数据量的增加，数据库和存储系统需要处理更大的数据量，这将对系统性能和可扩展性产生挑战。 实时性：随着实时数据处理的需求增加，数据库和存储系统需要提供更快的响应时间。 安全性：随着数据的敏感性增加，数据库和存储系统需要提高安全性，以防止数据泄露和盗用。 多源集成：随着数据来源的增加，数据库和存储系统需要集成多个数据源，以实现更全面的数据处理。 智能化：随着人工智能技术的发展，数据库和存储系统需要具备智能化功能，以提高处理效率和准确性。 为了应对这些挑战，数据库和存储系统需要进行以下发展：  分布式存储：通过分布式存储技术，可以将数据存储在多个服务器上，从而实现负载均衡和高可用性。 数据库引擎优化：通过优化数据库引擎，可以提高查询性能和可扩展性。 数据压缩：通过数据压缩技术，可以减少存储空间需求，从而降低存储成本。 数据加密：通过数据加密技术，可以保护数据的安全性，防止数据泄露和盗用。 数据流处理：通过数据流处理技术，可以实现实时数据处理，从而满足实时性需求。 6.附录常见问题与解答 在这里列出一些常见问题与解答。  问题1：如何选择适合的数据库引擎？ 答案：根据应用程序的需求和数据特性选择适合的数据库引擎。例如，如果需要处理大量的读操作，可以选择NoSQL数据库；如果需要处理事务和关系数据，可以选择关系型数据库。  问题2：如何优化数据库性能？ 答案：优化数据库性能需要考虑以下几个方面：  索引优化：使用合适的索引可以提高查询性能。 查询优化：优化查询语句可以减少查询时间。 数据分区：将数据分成多个部分，可以提高查询性能和可扩展性。 缓存优化：使用缓存可以减少数据库访问次数，提高性能。 问题3：如何保护数据的安全性？ 答案：保护数据的安全性需要考虑以下几个方面：  数据加密：使用数据加密技术可以保护数据的安全性。 访问控制：使用访问控制列表(ACL)可以限制对数据的访问。 审计：使用审计工具可以记录数据的访问历史，以便发现潜在的安全问题。 备份和恢复：定期备份数据，以便在发生故障时进行恢复。 ————————————————                              版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。                          原文链接：https://blog.csdn.net/universsky2015/article/details/135795296 

前言随着科技的飞速发展，云计算和人工智能两大技术领域的融合已经成为推动数字化转型的重要力量。云计算以其强大的计算能力、灵活的资源调配和高效的成本控制，为人工智能的发展提供了坚实的基础。本文将探讨云计算在人工智能中的作用，并展望未来的发展趋势。一、云计算为人工智能提供强大的计算能力人工智能需要大量的数据训练和优化模型，而云计算平台能够提供弹性可伸缩的计算资源，满足人工智能在不同阶段的需求。无论是模型训练、推理还是部署，云计算都能提供足够的计算能力，保证人工智能系统的稳定运行。此外，云计算还能通过分布式计算、并行计算等技术手段，提高人工智能算法的执行效率，进一步加速人工智能的发展。二、云计算降低人工智能的门槛和成本传统的人工智能开发需要高昂的硬件投入和维护成本，而云计算平台则提供了按需付费的模式，使得企业和个人能够以较低的成本获取所需的计算资源。此外，云计算还提供了丰富的工具和服务，帮助开发者更加便捷地构建和部署人工智能应用。这些优势降低了人工智能的门槛，使得更多的人能够参与到人工智能的研究和应用中来。三、云计算促进人工智能的普及和应用云计算平台的开放性和可扩展性，使得人工智能应用能够更加灵活地部署到各种场景中。无论是智能家居、智慧城市还是工业自动化，云计算都能为人工智能提供稳定的运行环境，实现数据的共享和协同。这种普及和应用不仅提高了人工智能的实用性，也推动了各行各业的创新发展。四、未来展望随着云计算技术的不断进步和人工智能应用的深入拓展，云计算在人工智能中的作用将更加凸显。未来，我们可以期待云计算平台在以下几个方面为人工智能提供更加优质的服务：更高效的资源调配：云计算平台将进一步优化资源调度算法，实现更精细化的资源管理和分配，以满足人工智能在不同场景下的需求。更智能的安全保障：随着人工智能应用的普及，数据安全和隐私保护将成为重要议题。云计算平台将利用人工智能技术，构建更加智能的安全防护体系，保障用户数据的安全和隐私。更广泛的生态合作：云计算平台将积极与人工智能领域的上下游企业开展合作，共同推动人工智能技术的创新和应用。这将有助于形成更加完善的产业生态链，推动整个行业的快速发展。五、总结云计算在人工智能中发挥着举足轻重的作用。它不仅为人工智能提供了强大的计算能力和灵活的资源调配，还降低了人工智能的门槛和成本，促进了其普及和应用。未来，随着云计算技术的不断进步和人工智能应用的深入拓展，我们有理由相信这一融合将带来更多创新和惊喜。

3月21日，在巴黎举办的云原生顶级峰会KubeCon+CloudNativeCon Europe 2024上 ，华为云首席架构师顾炯炯在 “Cloud Native x AI：以持续开源创新开启智能时代” 的主题演讲中指出，云原生和AI技术的融合，是推动产业深刻变革的关键所在。华为云将持续进行开源创新，与开发者共启智能时代。  ▲华为云首席架构师顾炯炯发表演讲AI对于云原生范式提出关键挑战在过去的几年里，云原生彻底改变了传统的IT系统，催化了互联网和政府服务等领域的数字飞跃。云原生范式带来的新的可能性，例如闪电般的快速销售和基于微服务治理的敏捷应用DevOps，已经深入人心。同时，人工智能的快速发展和广泛采用，包括大规模模型，已经成为行业智能的跳动心脏。根据Epoch 2023年的调研数据，基础模型所需的计算能力每18个月就会增长10倍，是摩尔定理揭示的通用计算能力增长率的5倍。AI带来的新摩尔定律和大规模AI模型的主导地位对云原生范式提出了挑战，顾炯炯总结了其中关键的4点：首先，低GPU/NPU平均利用率导致AI训练和推理的高成本；其次，大模型训练集群频繁的失败率限制了训练效率；第三，大规模模型的复杂配置导致AI开发门槛高；第四，大规模的AI推理部署面临着不可预测的最终用户访问延迟和数据隐私问题的风险。华为云AI创新为开发者迎接挑战提供思路随着AI模型变得越来越大，对计算能力的需求也呈指数级增长。这种需求不仅给云原生技术带来了挑战，也为业界提供了创新机遇。顾炯炯分享了一些华为云在AI创新方面的故事，为开发者解决这些挑战提供了参考。在云原生边缘计算平台KubeEdge的基础上，华为云实现了一个云原生多机器人调度管理平台。用户可以通过自然语言命令在云端输入任务指令，由系统协调边缘的多个机器人共同协作完成复杂任务。为了克服自然语言命令理解、大量机器人高效调度管理以及跨类型机器人访问管理的三个挑战，该系统采用了云端、边缘节点和机器人三个部分的架构，通过大模型执行自然语言命令，并进行流量预测、任务分配和路由规划。这一架构显著提高了机器人平台的灵活性，管理效率提升25%，系统部署周期缩短30%，新机器人的部署时间从月级缩短到天级。中国某顶级内容分享社区，每月活跃用户超过1亿。它的核心服务之一是主页上的推荐功能。推荐模型有近1000亿个参数。训练集群有数千个计算节点。一个训练作业需要数百个参数服务器和worker。因此，该社区对最优拓扑调度、高性能、高吞吐量有着强烈的需求。开源项目Volcano可以更好地支持在Kubernetes上运行的AI/ML工作负载，并提供了一系列作业管理和高级调度策略。Volcano项目引入了拓扑感知调度、装箱、SLA感知调度等算法，帮助社区将整体训练性能提升了20%，运维复杂度也大大降低。Serverless AI引领云原生发展趋势如何高效、稳定地运行AI应用，同时降低运营成本，成为摆在众多企业和开发者面前的一大挑战。为此，华为云总结了云原生AI平台的关键要求，提出了一种全新的云原生AI平台理念——Serverless AI。顾炯炯提到，从开发者的视角来看，Serverless AI致力于智能地推荐并行策略，让复杂的训练和推理任务变得轻而易举。它提供自适应的GPU/NPU自动扩展功能，能够根据工作负载的实时变化动态调整资源分配，确保任务的高效执行。同时，Serverless AI还维护着一个无故障的GPU/NPU集群，让开发者无需担心硬件故障带来的中断风险。更值得一提的是，该平台保持与主流AI框架的兼容性，让开发者能够无缝集成现有的AI工具和模型。对于云服务提供商而言，Serverless AI同样具有深远的意义。它不仅能够提高GPU/NPU的利用率，使训练、推理和开发混合工作负载得以高效运行，还能通过优化能效实现绿色计算，降低能耗成本。此外，Serverless AI平台还能实现跨多个租户的空间和时间GPU/NPU共享，提高资源的复用率。最重要的是，它为训练和推理任务提供了有保证的QoS和SLA，确保了服务质量和稳定性。Serverless AI平台采用了构建在操作系统和虚拟化之上的灵活的资源调度层，将应用程序框架的关键功能封装于应用资源中介层中。顾炯炯现场展示了Serverless AI平台的参考架构。他认为，这种架构设计，使得Serverless AI平台具有了大规模AI资源自动驱动引擎的特点，包括精确了解应用资源利用模式的资源分析，实现异构硬件资源池化的资源共享，基于GPU/NPU虚拟化和负载热迁移的AI训练任务容错能力，以及提高资源利用率的多维度调度和自适应弹性伸缩等优点。分论坛上，华为云技术专家提到，Kubernetes上运行AI/ML工作负载的使用量不断增加，许多公司在分布于数据中心和各种GPU类型的多个 Kubernetes 集群上构建云原生AI平台。使用Karmada和Volcano，可轻松实现多集群的GPU工作负载智能调度、集群故障转移支持，在保障集群内和跨集群的两级调度一致性和效率，并平衡系统整体资源的利用率和不同优先级工作负载的QoS，以应对大规模、异构的GPU环境管理中面临的挑战。Karmada为多云和混合云场景中的多集群应用管理提供即时可用的自动化管理，越来越多的用户在生产环境中使用Karmada构建灵活高效的解决方案。Karmada已于2023年正式升级为CNCF孵化项目，期待与更多伙伴与开发者们共建繁荣社区。Volcano与主流AI/大数据框架实现了无缝集成，有效解决了AI/大数据任务的作业管理，资源分配，资源调度等问题与挑战，为业界提供了分布式作业训练的最佳实践。在大模型日新月异的今天，Volcano将持续发力，解决多集群AI任务调度等难题，助推大模型训练与推理快速发展。“云原生技术的敏捷性和异构AI计算平台的创新性，将是提升AI生产力的关键。” 顾炯炯谈到，未来，华为云将持续致力于开源创新，与业界同仁、伙伴共同开启智能时代的新篇章。更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

CloudVison在设计之初，只是通过XMPP把交换机EOS上的状态数据同步到一个集color:中的全局数据库中，然后通过Portal把全局视图提供出来。这实际上可以看作一个偏向于网管的入口，除了一些ZTP功能用于配置自动化以外，并没有过多的控制逻辑，因此 CloudVison最初的定位并不是作为SDNController，而是Network Wide Enhanced EOS。随着这几年的发展，CloudVison逐渐增加了对虚拟网络进行直接控制的能力和对全局数据的监测分析能力，因此CloudVison现在可以看作Arista的SDN 控制器。CloudVison分为CloudVison Portal (CVP)和CloudVison eXchange(CVX)两个部分， CVP和CVX可以采用分布式部署，各自可以支持3个节点的集群。其中，CVP是一个 Web平台，是网络的管理入口，负责提供网络的配置以及全局数据的可视化，其主要功能包括以下几点。用户安全，支持RBAC。基于JSON 的 RESTful API。口设备的镜像、快照、智能升级。□设备自动上线、管理与配置、配置回滚。□网络的实时状态与历史状态、大数据分析。CVX是增强的EOS 环境，它相当于网络中的控制器，负责业务到网络下行的自动化控制，其主要功能包括以下几点:口提供EOS 的 CLI、API以及基于JSON-RPC的eAPI。 OVSDB 接口协议。□物理网络的拓扑发现。VxLAN控制逻辑(VCS，VxLAN Control Service，基于Arista的私有协议)。 Vmware NSX与OpenStack，对VLAN和VxLAN两种组网模式提供支持。口宏分段(Macro-Segmentation Services)，实现虚拟机和裸机间东西向流量的安全。 Arista一直主打的是 Underlay Fabric上的SDN，这种 SDN应该理解为软件驱动网络,主要功能包括自动化和遥测两大类。自动化即为对Fabric进行自动的维护，主要包括:配置、回滚与智能升级等。遥测即为网络的可视化，主要包括数据流量分析、时延分析、网络追踪等，这些数据可以通过gRPC实时地推送给CloudVison进行呈现，以及后续的分析与处理。

VSs交换机的市场份额上升得非常快，在Gartener近三年的Magic Quadrant中与Cisco并列第相比 Cisco 和 Juniper,Arista算是网络圈子的“新兵”，不过近几年Arista在数据中心机级的一象限。高速上涨的背后是Arista对于数据中心的专注，其交换机的两点核心竞争力一以及安低延时和开放性，成为Arista在云数据中心网络领域脱颖而出的基础。先来看低延时。某些特定领域的应用，如超算和高频交易，对延时的要求十分苛刻。对于低延时应用来说，InfiniteBand在技术上是最好的网络选择，不过以太网正在靠着简单性、低成本和40GE/100GE端口不断地进行着渗透，低延时以太网+RoCE正在获得低延时网络的市场份额。低延时对以太网要求的不仅是带宽的NonOver-Subscribe，还需综合考虑设备的转发架构、端口的buffer深度、链路的负载均衡、精细的拥塞可视化以及完整来实的网络数据审计，来构成一整套的低延时解决方案。Arista凭借着直通式转发、大buffer、用于 ECMP+M-LAG以及其LANZ和DANZ技术，在低延时以太网市场上形成了独特的竞争优间 势，在金融圈子内拥有大量的客户。随着大数据和其他分布式计算应用的大规模爆发，低延时的需求被引入了云计算数据中心，Arista也得以借这股东风找到了新的市场爆发点。再来谈开放性。Arista做设备秉承的理念是“Merchant Silicon+Open Protocol >> Vendors Proprietary Fabrics”，即通过通用的芯片和标准的协议来组盒子，通过开放性和低成本来抗衡Cisco。“通用的芯片”意味着 Arista不会自己玩芯片，而是会选择Broadcom专业芯片公司的产品，以降低高昂的芯片研发成本，如果对ASIC有特殊需要(如LANZ)、也是我芯片公司进行定制。“标准的协议”意味着Arista的组网通常依赖着的都是标准的L2/L3协议，如STP、OSPF、BGP、ECMP等，少数Arista私有的协议，如M-LAG和VARP,也是参照开放协议进行修改的。因此，和Cisco的FabricPath以及Juniper的 QFabric 不同，Arista在2010年前后面对着即将爆发的数据中心虚拟化时，并没有选择自己搞一套大二层的专用Fabric，而是联合VMware和Microsoft 推出了 VxLAN和NvGRE,希望把二层 Overlay在现有设备上。搭上了VMware对于VxLAN生态建设的便车，Arista又一次在网络虚拟化领域占据了有利的位置。当然，光占据市场位置是没有用的，把技术的内功修炼到位才是产品能够持续卖出去的根本。如果自己不做芯片和协议，技术上想要出彩，就要在软件平台上花心思。Arista显然很早就搞清楚了这个道理，于是在其交换机软件平台EOS上下了很大的工夫。EOS是完全基于开源Linux来做的，相比于WindRiver提供的专用网络操作系统，其开放性和可维护性有着本质上的提升。恰逢其时，EOS的技术路线正好契合了SDN所提倡“把盒子开放出来”的理念，Arista作为传统的设备厂商，得以在SDN的大时代中站稳了脚跟。自家数据中心的盒子年增长率惊人，Arista就没有动vSwitch的心思，虽然自己也做SDN控制器但也没有大张旗鼓地去宣传，而是主力在推动自己的Underlay SDN。这注意,Underlay SDN是为了补充Overlay SDN的，这与CiscoACI“以硬件为中心”HUAWEI 订了战略合作关系，图4-63是两家合作的路标。 SDN理念有着本质的不同，虽然Arista自己也支持纯硬件的方案，但是并没有在市场上 VMware NSX直接竞争。

NSX-V数据平面的组件包括NSXvSwitch和NSX Edge。NSX vSwitch在VDS 的基础上添加了3个内核模块:VxLAN(VTEP),DLR(分布式逻辑路由器)和DFW(分布式防火墙)。 NSX Edge则为NSX网络提供了L2GW以及L3-L7的高级网络服务，如集中式路由/NAT集中式防火墙、负载均衡、VPN等。先来看NSXvSwitch。VDS负责租户的二层转发，VM连接在VDS上。VxLAN模块对目的地位于其他ESXi主机的L2帧封装VxLANHeader.DLR模块负责租户的三层转发，包括东西向流量和南北向流量。DFW与VM的vNIC相关联，能够per VM的细粒度、定制化、带状态的安全防护。由于这些模块都是分布式的，不存在单点故障的问题，因此 NSX vSwitch本身就具备了很高的可用性，不需要再设计额外的HA机制。NSXEdge可以理解为NSX-V提供的NFV产品套件。L2Gateway用来实现NSX租户网络和物理主机的二层连通，L3Router负责集中式的路由和NAT，用于连接NSX-V租户网络与 Internet。除了二层和三层网关外，NSXEdge还提供了诸多的高级网络服务:防火墙用来提供per VDC级别的安全防护，负载均衡既可以集成在三层网关上，又可以独立于三层网关部署，高版本的NSX-V还支持DLB(Distributed Load Balancer)，VPN既可以部署L2VPN又可以部署L3 VPN,L2VPN采用私有封装实现跨域二层互通，L3VPN支持 IPSEC和 SSL两种。NSXEdge通常放在NFV POD下面采用集中式部署，以连接NSX-V网络与外界网络，因此需要为NSXEdge设计HA机制，以保证其可用性。对于上述不同的 NSX Edge功能，它们的HA机制都不尽相同，此处不进行详细的分析。在vSphere 环境中，除了VxLAN所承载的VM通信的数据流量以外，VDS上还通过 VMkernel 接口承载了很多其他类型的流量，如管理流量、vMotion流量和存储流量，这些流量的特征和优先级截然不同，对物理网络的需求自然也有很大的区别。因此，这4种类型的流量在上联时可以采用不同的VLAN ID，并在上联口使用VLANTrunking，以便进行复用、隔离和 QoS 规划。

  NSX-V用于在纯VMware vSphere环境对网络进行虚拟化，并不支持KVM、XEN等开源服务器虚拟化技术。虽然NSX-V面向的是VMware自家的产品，但还是保留了NVP的大部分SDN技术特征，并提供了强大的NSXEdge以支持更为丰富的NFV组件,为 NSX-V的组网提供了更多的可能性。NSX-V的微分段技术中实现了分布式防火墙，能够支持更为灵活、立体的网络安全策略。另外，NSX-V还提供了网络管理平面，方便用户进行集中式的管理。  NSX-V的产品架构由上到下分为三个平面:管理、控制与数据。管理平面的主要组件为NSXManager，它通过UI提供虚拟化网络的视图呈现与集中式的单点配置与管理，通过RESTfulAPI与VMware的管理平台交互、通过RESTfulAPI/私有协议对控制平面/数据平面进行配置与管理。控制平面组件主要为NSXController，它向上通过 RESTful API接收NSXManager的配置与管理，向下通过私有协议来管控数据平面的转发，另外DLR(Distributed Logic Router) ControlVM也是NSXController的一个组件，它接受 NSX Manager的配置与管理，并运行传统的路由协议，作为分布式逻辑路由器的控制平面与下一跳路由器(通常为NSXEdge)交换路由信息，以处理南北向流量。数据平面的组件主要包括NSXvSwitch和NSXEdge，通过私有的协议与控制平面进行通信，并根据控制平面提供的全局信息进行转发。可以看到，NSX-V的这套架构是一套纯软的方案，也就是说，从管理到控制再到设备全是软件实现的，将虚拟网络透明地Overlay在物理网络之上。对于纯软的方案来说，功能从来都不是问题，性能与高可用才是软件产品能否成功的关键，NSX-V作为生产级别的网络虚拟化平台，自然也少不了对这些方面的考虑。