开放网络的先行者与推动者—星融元
加入我们技术支持(Support)  TEL:(+86)4000989811

标签: 科普-数据中心

什么是VXLAN?VXLAN和VLAN有什么区别?


更多相关内容


一、VXLAN的原理

VXLAN是一种网络封装技术,它使用隧道协议将标准以太网帧封装在UDP(User Datagram Protocol)数据包中传输。VXLAN通过在底层网络上创建虚拟网络,将虚拟机(VM)或容器跨物理网络进行通信。它使用24位的VNI(VXLAN Network Identifier)来标识不同的虚拟网络。

VXLAN利用了一个称为VTEP(VXLAN Tunnel Endpoint)的设备,它负责在物理网络和虚拟网络之间进行数据包的封装和解封装。VTEP维护了VNI与MAC地址之间的映射关系,以便正确路由数据包到相应的虚拟机或容器。

VXLAN

二、VXLAN的功能和作用

  1. 扩展性:VXLAN可以扩展现有的以太网架构,提供超过4096个VLAN标识符的虚拟网络。这使得在大规模数据中心中创建和管理多租户环境变得更加容易。
  2. 隔离性:VXLAN通过在底层网络上创建虚拟网络,实现了不同租户之间的逻辑隔离。每个租户都可以拥有自己的虚拟网络,并且它们的通信是相互隔离的,提供了更高的安全性。
  3. 移动性:VXLAN允许虚拟机或容器在物理网络中进行迁移,而无需更改它们的IP地址或VLAN标识符。这使得在数据中心中进行负载均衡、故障恢复和资源调整变得更加灵活和高效。
  4. 跨子网通信:VXLAN可以跨越不同的子网进行通信,克服了传统VLAN在这方面的限制。它可以通过底层网络中的IP隧道实现跨子网的通信,并提供更大的灵活性和可扩展性。

三、VXLAN技术的应用场景

场景1:采用VXLAN技术实现数据中心虚拟机迁移

VXLAN-场景

场景2:园区网络与数据中心VXLAN网络之间的通信

VXLAN-场景

四、VXLAN与VLAN的区别

  1. 标识符数量:VXLAN可以提供超过4096个虚拟网络标识符,而传统VLAN仅限于4096个VLAN标识符。
  2. 隔离性:传统VLAN在逻辑隔离方面存在一定的限制,因为它们共享相同的广播域。而VXLAN通过在底层网络上创建虚拟网络,提供了更好的隔离性和安全性。
  3. 跨子网通信:VXLAN可以轻松地实现跨子网的通信,而传统VLAN必须在同一子网内才能进行通信。
  4. 设备支持:传统VLAN需要支持802.1Q协议的交换机和路由器来实现,而VXLAN需要支持VTEP功能的设备来进行封装和解封装。

结论

VXLAN是一种虚拟扩展局域网技术,通过在底层网络上创建虚拟网络,实现了大规模虚拟化和多租户环境。它具有扩展性、隔离性、移动性和跨子网通信的功能,可以提供更高的灵活性和可扩展性。与传统VLAN相比,VXLAN具有更多的标识符数量、更好的隔离性、跨子网通信的能力,并且需要特定的设备支持。

相关阅读:技术手册-虚拟扩展本地局域网协议VXLAN

下载链接:技术手册-虚拟扩展本地局域网协议VXLAN

返回资源中心

 

Underlay与Overlay有什么区别和联系


更多相关内容


什么是Underlay?

Underlay是现实的物理基础层网络设备。数据中心基础转发架构的网络。

以太网最初设计的时候就是一个分布式的网络架构,没有中心控制节点,网络中的节点通过协议传递学习网络的可达性信息。

Underlay就是数据中心场景的基础物理设施,保证任何两个点路由可达,其中包含了传统的网络技术。

在数据中心强劲生长、快速演变的今天,网络面临种种挑战:

  1. 二层网络范围受限,虚拟机迁移不灵活;
  2. 数据中心交换机地址表项不够;
  3. 数据中心网络的多租户隔离能力不足。

应对这些挑战,Overlay技术可以实现:

  1. 在三层网络中实现二层网络的扩展,路由方式传输,网络架构范围不受限,具备大规模扩展能力,虚拟机迁移不再被限制在 一个较小的局部范围内。
  2. 在三层网络中实现二层网络的扩展,多采用三层互联方式,交换机仅仅需要维护一张本地的MAC地址表,极大降低了承 载网络对MAC 地址表项的需求。
  3. 扩展隔离标识的位数,从12bit到24bit,支持多达16M的用户标识,充分满足当下和未来数据中心多租户的网络隔离能力。

相关阅读:星融元携手商业地产运营商共同进入AI时代 (asterfusion.com)

什么是Overlay?

Overlay是一个基于物理网络之上构建的逻辑网络,是在网络技术领域指的是一种网络架构上叠加的虚拟化技术模式,Overlay网络也是一个网络,不过是建立在Underlay网络之上的网络

Overlay网络节点通过虚拟或者逻辑链路进行通信,其实现基于ip技术的基础网络为主。Overlay网络技术多种多样,一般采用TRILL、VxLan、GRE、NVGRE等隧道技术。

Underlay和Overlay的网络架构图

Overlay主流技术对比

Overlay主流技术对比

Underlay与Overlay的联系

Overlay的实现依赖于Underlay网络,它使用Underlay网络进行数据包的传输。Overlay网络通过在Underlay网络上部署虚拟化设备和服务,实现了对网络流量的控制、管理和优化。

通过Overlay技术,可以在Underlay网络上构建多个逻辑网络,实现不同网络需求之间的隔离和灵活性,并且可以提供更多高级的网络功能,如虚拟专用网络(VPN)、负载均衡等。

Underlay与Overlay的区别

Underlay是底层承载网,Overlay是基于底层网络互联互通的基础上加上隧道技术去构建一个虚拟的网络,例如VPN隧道组成的网络就是Overlay网络。

Underlay的核心是底层网络,Overlay的核心是上层的打隧道(tunnel)。

对比项Underlay网络Overlay网络
数据传输通过网络设备例如路由器、交换机进行传输沿着节点间的虚拟链路进行传输
包封装和开销发生在网络的二层和三层需要跨源和目的封装数据包,产生额外的开销
报文控制面向硬件面向软件
部署时间上线新服务涉及大量配置,耗时多只需更改虚拟网络中的拓扑结构,可快速部署
多路径转发因为可扩展性低,所以需要使用多路径转发,而这会产生更多的开销和网络复杂度支持虚拟网络内的多路径转发
扩展性底层网络一旦搭建好,新增设备较为困难,可扩展性差扩展性强,例如VLAN最多可支持4096个标识符,而VXLAN则提供多达1600万个标识符
协议以太网交换、VLAN、路由协议(OSPF、IS-IS、BGP等)VXLAN、NVGRE、SST、GRE、NVO3、EVPN
多租户管理需要使用基于NAT或者VRF的隔离,这在大型网络中是个巨大的挑战能够管理多个租户之间的重叠IP地址

总结

Underlay网络是底层的物理网络基础设施,而Overlay网络是在底层网络之上创建的虚拟网络。Overlay网络提供了额外的功能和服务,如VPN、VLAN、SDN和云计算中的虚拟化网络。通过Overlay网络,可以实现更好的网络管理、安全性、隔离性和性能优化。

返回资源中心

 

什么是以太网交换机的网络时延?


更多相关内容


网络时延是现代网络的一个重要方面,对数据传输的效率有着深远的影响。以太网时延是一个经常出现的术语,但您对它有深入的了解吗?本文将讨论什么是网络时延、网络时延的原因、如何测量网络时延以及如何使用以太网交换机减少网络时延。请继续阅读,了解更多信息。

什么是网络时延?

网络时延的含义

术语 “网络时延 “是指网络数据传输的时延。以太网交换机时延是指以太网数据包通过网络交换机所需的具体时间。时延时间长的网络称为高时延网络,时延时间短的网络称为低时延网络。

以太网交换机时延可从两个角度来理解–单向时延和往返时延。后者通常用作主要指标,包括以太网数据包从源到目的地所需的总时间。如今,往返时延是一个重要指标,因为设备使用 TCP/IP 网络协议将特定数据发送到目的地,并等待回执后再发送另一个数据。因此,这种方法对网络性能有重大影响。

往返时延

网络时延的意义

随着越来越多的公司进行数字化转型,它们开始采用基于云的应用程序和服务来执行基本业务功能。运营活动还依赖于从连接到互联网的智能设备(统称为物联网 (IoT))上收集的数据。时延会导致效率低下,特别是在依赖传感器数据的实时操作中。此外,即使企业实施了昂贵的网络基础设施,高时延也会降低为提高网络容量所做投资的回报,影响用户体验和客户满意度。

是什么导致了网络时延?

前几节介绍了网络时延的概念。本节将探讨造成时延的原因。造成网络时延的因素很多。以下是可能造成时延的几个潜在因素。

  • 传输介质的影响:由于数据是通过传输介质或链路传输的,因此传输介质或链路对时延的影响很大。例如,光纤网络的时延比无线网络低。同样,每次网络从一种介质切换到另一种介质时,总传输时间都会增加几毫秒。
  • 报头分析:以太网交换机有时需要额外的时间来分析数据包报头细节并纳入重要数据,因此会产生时延。这会导致通过交换机的数据包的遍历时间延长。
  • 与存储相关的数据包时延:当数据包在交换机和网桥等中间设备上遇到存储或磁盘访问时延时,就会出现存储时延。
  • 安全处理时延:网络时延可能受到反病毒和安全进程的影响,这些进程在传输前需要时间完成信息重组和分解。

如何测量时延?

IEEE 规范 RFC2544

IEEE RFC2544 规范为评估存储转发设备的时延提供了一种广为接受的方法。RFC2544 要求时延测试至少重复 20 次,测试结果为所有测试结果的平均值。

Netperf

Netperf 是基于 TCP 或 UDP 传输的网络性能测量工具。Netperf 测试结果反映了一个系统向另一个系统发送数据的速度和另一个系统接收数据的速度。

Ping ping

Ping Pong 是一种用于测量高性能计算集群内时延的方法。这种方法可评估通过消息传递接口(MPI)传输的远程过程调用(RPC)的往返持续时间。

如何利用以太网交换机减少网络时延?

使用以太网交换机最大限度地减少网络时延有多种方法。这些方法包括:

增加网络容量

减少时延和碰撞最直接有效的方法之一是为以太网交换机配备所需的容量。 验证交换机是否具备扩展网络容量的能力非常重要。 确保零数据包丢失的以太网交换机在提高网络性能方面发挥着至关重要的作用。链路聚合控制协议(简称 LACP)是一项标准功能,可通过端口中继提高网络性能。了解产品信息,请访问:https://asterfusion.com/product/cx-n/

使用 VLAN 进行网络划分

鉴于传统的扁平网络往往会导致链路过载,配备 VLAN 功能的以太网交换机可以有效地将流量路由到预定目的地。 一系列第 2 层和第 3 层 VLAN 以太网交换机可根据端口、动态 VLAN 分配、协议、MAC 地址等因素进行流量划分。

实施穿透技术

这种方法与数据包交换系统有关,旨在最大限度地减少网络时延。 直通式交换通过允许交换机在收到完整数据包之前,即在处理目的地址后立即启动数据包转发,从而减少网络时延。 不过,需要注意的是,这种技术只有在端口以相同速度运行时才能发挥最佳功能。

利用 RDMA 减少时延

RDMA 或远程直接内存访问是一种尖端网络技术,它彻底改变了数据传输效率。与涉及 CPU 的传统方法不同,RDMA 实现了网络内计算机内存之间的直接数据交换。这避开了中央处理器,减少了时延,从而加快了实时模拟、数据分析和高性能计算等任务的数据通信。QSFPTEK 的 S5600 和 S7600 系列交换机支持 RDMA,可提供高吞吐量和超低时延。

利用以太网交换机减少网络时延

结论

总之,网络时延对以太网交换机的高效数据传输至关重要。本文旨在阐明以太网交换机中以太网时延的概念,并深入探讨减少时延的策略。虽然不可能完全消除网络时延,但我们的目标是尽可能地减少时延。在当今依赖网络的环境中,了解网络时延的影响并应用缓解策略至关重要。

返回资源中心

 

什么是Ansible Playbook以及如何上手?

更多相关内容


什么是 Ansible Playbook?

Ansible 是 Red Hat(红帽) 推出的一款配置管理工具,能自动完成多台服务器的配置和应用程序的部署,Playbook是任何在 Ansible 平台之上进行配置的核心组件。

Ansible playbook是一个自动化脚本集合,定义了 Ansible 在一台或多台机器上要执行的一系列配置管理工作。管理员无需逐个运行单个 Ansible 命令,而是通过 playbook 简化配置管理工具的使用。熟悉了 Ansible 命令后,你就可以从头开始编写Play(剧本),或从 Ansible 及其用户社区获取预编写的playbook和模块。

Ansible Playbook的组件

Ansible Playbook 由一个或多个 play 组成,而 play 又由各种模块(module)组成。

Playbook 不是标准文本文件,而是 YAML 格式。他们可以定义与托管服务器上的配置相关的工作,IT运维人员会为目标机器创建带有特定环境参数的版本,所以并不存在一个标准版的Playbook。

用 Python 或 PowerShell 编写的脚本(模块)与目标托管服务器的各个方面相关,适用于系统配置的许多方面。包括软件安装和用户管理。模块组件的存在使得Ansible工具非常灵活,不光Ansible本身提供了许多模块,很多Ansible相关的开源社区也提供了丰富的选择。

使用 Ansible playbook

当管理员对目标机器运行 ansible-playbook 命令时,就会执行一个 playbook。

管理员必须使用清单文件(inventory file)来指定Playbook所管理的主机。清单文件包含 Ansible 管理的所有主机列表,可按功能对主机进行分组。例如,管理员可以对一组网络服务器应用一个管理程序,对一组数据库服务器应用另一个管理程序。

要开始使用这些 Ansible 管理程序,首先要确认该工具已安装并正在运行。 发出以下命令运行一个 playbook,其中 myfile 是 YAML 文件名:

发出以下命令运行一个 playbook

Ansible 通过 SSH 与它所管理的机器通信,因此 Ansible playbook 和 Ansible 可执行文件都存储在本地服务器的文件夹中。

使用检查模式和分组

在实际环境执行之前,可以在检查模式下运行playbook,尤其是对于那些刚开始使用 Ansible 的管理人员。此操作会在不修改任何文件的前提下,输出系统在标准模式下运行时会发生的更改,以便于我们及时勘误。
要使用检查模式,可添加 –check 指令:

添加 --check 指令

要检查语法是否有误:

检查语法

管理员可以根据主机的功能或其他层次结构,将类似的主机归为一组,并只对组内的主机执行操作。例如,分隔不同主机组确保只有网络服务器运行最新版本的 Apache,排除了数据库服务器。

所有主机都存储在名为 /etc/ansible/hosts 的本地 Ansible 清单文件中。虽然管理员可以更改主机信息的存储位置,但该位置是默认设置(建议不要更改)。如果该文件经常更改,请使用版本控制功能。

星融元网络操作系统AsterNOS对Ansible的支持

在实际部署使用中,如果对应设备的软件版本没有提供现成的Ansible插件/模块,则需要对其进行二次开发。设备能否被顺利集成完全取决于运维人员的研发能力。

AsterNOS是星融元开发的一款功能强大的企业级SONiC发行版,稳定兼容几乎所有主流商业交换芯片,已在全球有着数万台的商业拷贝。作为一款为云计算时代构建的新一代NOS,AsterNOS具备开放、开源、以业务为中心的特点,完全顺应NetDevOps理念。

AsterNOS对Ansible的支持

我们的官方模块集合 Asterfusion AsterNOS Collection 现已正式上线,目前已完成cliconf插件和asternos_command模块的开发适配。我们将为其持续提供开发更新。

更多相关信息请访问星融元的Ansible Galaxy主页查看,欢迎各位运维工程师下载体验,与我们深度交流!

项目主页地址:https://galaxy.ansible.com/asterfusion

返回资源中心

 

承载AI计算的数据中心网络和传统数据中心有何不同?

更多相关内容


生成式AI正在风靡全球,不少企业开始研究如何在其业务流程中采用人工智能技术,更有一些企业客户开始考虑在数据中心和私有云中部署自己的AIGC和 GPU 扩展网络。从网络角度来看,用于承载这类业务的数据中心与传统的数据中心有很大不同,它甚至与用于高性能计算 (HPC) 的数据中心也有所区别。

分析AI训练数据的一半时间消耗在网络上

尽管人们都在关注使用GPU服务器处理数据的用时,但实际上人工智能数据的一半处理过程都发生在网络中。所以,我们需要更加关注数据中心网络所能提供的速度和灵活性,以避免其成为整个数据中心的性能瓶颈。

构建高度可扩展的网络是AI数据中心的关键所在,考虑到未来的增长能力,网络交换架构必须包括横向和纵向扩展的硬件,网络操作系统需要带有应对数据包突增、负载平衡和智能流量重定向等数据中心高级功能,这样才可在AIGC网络内超负荷的 GPU 处理单元之间智能地重新路由流量。

工作负载数变少,但规模更大了

与致力于将网络延迟降至超低水平的高性能计算不同,人工智能数据中心的建设必须侧重于高吞吐能力。高性能计算网络旨在同时传输数千个工作负载,并要求将延迟降至最低,而人工智能工作负载的数量要少得多,但规模却大得多。

从速度的角度来看,对于AIGC网络来说,网络吞吐量比网络延迟更重要。如此,用于 HPC 的 InfiniBand 网络结构所具有的超低延迟优势已被削弱,而由于以太网标准具有更高的吞吐能力和更高的性价比,使用吞吐量更高的以太网网络可能很快就会成为常态。

网络部署需要更适应高密度连接

为生成式AI计算部署高密度 GPU 机架并非易事,首先网络布线的难度变大,此外还需要高达四倍的交换机端口密度。根据 Dell’Oro Group 的一份研究报告,到 2027 年,多达 20% 的数据中心交换机端口将分配给 AI 服务器。电源和冷却系统可能也都需要进行对应的调整才能适应更高的密度。

使用多站点或微型数据中心或许是适应这种密度的最佳选择。然而这也给连接这些站点的网络带来了压力,即要求网络尽可能具有更高的传输性能和扩展性。

网络的自动化编排和运维成为必备条件

承载AI的数据中心网络错综复杂,需要为此专门优化性能和提高可靠性,因此我们不应继续使用传统的命令行和第三方性能监控工具来管理 AIGC 网络。相反,企业应该部署一个网络编排平台,从一开始就在控制平面架构中提供一些有用的功能和性能洞察。

编排平台可提供多种优势,大大增强数据中心的管理能力:

  • 自动创建数据中心Underlay网络,大大减少网络开局和网络安全策略所需的时间。
  • 创建直观、自动化的Overlay网络和持续的 NetOps 管理。借助图形用户界面,管理平台可让网络管理员一站式地创建网络和网络安全策略,并自动将命令推送到需要的数据中心交换机而无需学习复杂的命令行。并且策略的创建基于系统内的标准模板,在很大程度上可以消除手动配置错误。
  • 提高性能和网络可视化程度。网络自动化工具还可使用多种传统和现代方法从网络交换硬件中收集和分析交换机健康状况和性能数据。收集和分析网络遥测数据是目前最新的方案:在这种情况下,交换机被配置为使用 gNMI 和 NETCONF 等专用协议标准向协调器发送实时性能测量数据。
  • 与传统的网络监控协议(如SNMP)相比,这些协议功能强大得多,有助于主动识别网络中存在的性能问题,在造成网络瘫痪或中断之前就开始补救。

附录:星融元AIGC网络建设实践方案

方案详情请参阅:客户案例:高性能、大规模、高可靠的AIGC承载网络 (asterfusion.com)

AIGC承载网方案架构图

  • 超低TCO、超高性价比:相较于IB网络方案,大幅度降低用户的网络TCO,同时确保超高性能
  • 横向平滑扩容、1:1收敛无阻塞:无收敛的网络设计确保无阻塞的大容量网络,按需横向扩展
  • 整网RoCEv2:基于CEE/DCB能力,提供可与IB媲美的性能和同样无损的网络服务
  • 开放网络操作系统:星融元网络操作系统AsterNOS,SONiC企业级发行版,支持灵活的功能扩展、在线升级
  • 无缝对接云管:AsterNOS 利用简单易用的REST API,可轻松让第三方的云平台/控制器快速纳管
  • 专家级服务:专业、全面、可靠的研发、方案与服务团队,为客户提供小时级的快速响应服务

返回资源中心

 

公有云还是自建私有云?企业如何计算云的总体拥有成本(TCO)

更多相关内容


要估算购买一定数量的云计算和存储所需的成本并不难——毕竟,供应商会公开列出他们的基本价格。但是,如果企业想真正了解云计算的运营成本,就需要对计划部署的资源有更全面的了解。企业尤其希望在云迁移之前估算云成本,以帮助更好地了解与继续在企业内部运行这些工作负载相比的经济效益。

常见的云成本考虑因素

在云中运行工作负载涉及多种类型的成本。这些成本包括但不限于以下方面:

  • 应用程序迁移(重新托管、重构或重新设计);
  • 基于基础设施的资源(计算实例大小、数据存储要求以及网络和 SaaS 使用量);
  • 云服务之间的数据传输成本;
  • 跨区域或可用性区域的数据重复;
  • 未来使用量/工作量的长期增长。

在总体拥有成本模型中,还需要考虑和核算一些无形成本,如风险管理、灵活性和可扩展性,这些成本可能难以量化,但在更大的成本范围内却非常重要。

其中一些成本,如风险管理和安全的特定方面,部分由云服务提供商(CSP)承担。其他一些成本,如灵活性和机会成本则由企业承担,会影响企业投资其他业务领域的能力。

用于数据中心科普文章的配图如何计算公有云方案和与本地私有云的总体拥有成本(TCO)?

要计算企业的云计算总体拥有成本,首先要比较在企业本地和在云中运行相同工作负载的成本。您还必须了解您的应用程序所需的全部功能,特别是其安全要求和其他可能增加大量成本的地方

无论是向云迁移还是新建应用,企业都需要对其预计的云总体拥有成本有一个准确的把握。

了解云计算的财务模型

在比较企业内部部署基础设施和主机托管服务(如 IaaS)时,使用率和时间是最重要的变量。通常情况下,企业本地部署IT资源的价值会随着账期的延长和利用率的提高而增加。但这不适用于云资源,因为云资源是按消耗量收费的。

要了解云的财务模型,第一步是指定一个统一的单位,以便在总拥有成本比较中将数据标准化。物理服务器、虚拟服务器或千兆字节的存储。标准单位既适用于企业内部资产,也适用于云资产。在本文中,我们假设您希望迁移到云提供商的基础设施,而不是为 PaaS 或无服务器配置重构应用程序。

接下来,计算平均资源单元的大小。例如,这个值可以是将所需的vCPU 和 RAM 除以VM数量。此外还应将网络和安全等相关服务考虑在内,以确保计算的准确性。

最后还需要模拟工作负载的预计增长率。增长率越高,意味着这项业务对标准化和自动化的依赖程度越高,在它规模化部署之后的总体成本会下降。相反,低增长率的工作负载并不适合云计算,因为企业无法充分利用云计算的弹性和按需付费的特性去节约成本。

深入研究TCO模型

确定工作量需求后,确定建模期限的起始月份。一般是从第二个月开始建立模型,根据第一个月的预计使用需求,决定起始容量。然后确定建模期结束时的最佳容量利用率和资源单位(将大容量利用率的上限通常设定为 80% 至 90%)。

考虑任何基础设施开销和管理要求。例如,包括任何已经到位的服务管理工具和网络安全防御措施。您需要将内部安全和管理系统的成本与完成相同工作所需的云服务成本进行比较。这种开销会降低贵公司向客户销售收费应用程序的创收能力。

IT 供应商通常为内部部署硬件指定最长三年的定价折扣。我们可以以月为单位进行分析,并创建相应的模型——这是因为较长的总体时间框架会影响云计算 TCO 分析中折旧部分。

最后,确定每月的使用量,记录公司计划使用的云服务。这样做的目的是记录服务的潜在使用情况,以便预测成本。(生产系统的典型使用率是 100%,因为这些应用程序会持续运行。相反,测试和开发系统的最高使用率则较低,毕竟团队每天只在工作时间使用)。

用于数据中心科普文章的配图洞察成本构成

要了解构成您现有本地基础设施部署支出的细枝末节,并考虑这些支出将如何转换到云中。

首先从硬件开始,这通常属于资本支出(CAPEX)。本地部署的软件大多也属于资本支出,但也可以作为运营支出计费,如数据库。硬件和软件维护也是总拥有成本中需要考虑的成本因素。

另外还需评估 CSP、软件供应商或外包专业服务公司的一次性安装费用。这些费用可能包括雇人构建云环境或将内部资产转移到公共云所需的费用。如果您的公司在公共部门或任何其他受严格监管的行业工作,则可能需要更多的前期费用,以支付应用程序部署到云之前必须满足的各种安全要求。

您还需要计算经常性开支,如运营和维护的人工成本。如果您拥有混合云环境,则应将数据中心的电力消耗成本纳入云计算的总体拥有成本。您可能还需要考虑前期成本和资本支出中未包含的容量利用支出。例如,随着用户群的不断扩大,软件许可费用可能会根据您部署的虚拟机数量而增加。

对潜在成本进行分类

到目前为止,我们讨论过的各种成本构成可以分为三类。对于每一类,企业可能都有一个或多个成本组成部分需要考虑:

  • 实体设备。作为成本组成部分,这包括托管虚拟服务器的内部物理服务器。它还包括支持这些物理服务器所需的机架数量。
  • 管理。这包括支持管理所需的任何成本组成部分。例如,AWS 用户可能会选择由服务级别协议支持的基于结果的管理服务,如 AWS 业务支持或企业支持计划。
  • 产业化成本(进入生产应用阶段的成本)。包括支持研究、开发、自动化、文档或培训的任何成本组成部分。产业化背后的成本效益很难量化,因此许多 TCO的比较都低估了这一类别的价值,这也是云计算支出充满意外的主要原因。例如,向云迁移或建设新云的预算可能无法准确反映自动化的云管理和运营任务所需的工作。

对于每个成本类别,确定总成本是否使用由通用容量变量定义的相同归一化分母。

总结:公有云还是本地私有部署?

在定义本地私有部署方案的价值驱动因素时,请仔细研究单位资源成本中的最大利用率和常规利用率,并进行量化比较。利用率是指服务器、网络和其他基础设施用于提供服务的总体程度。服务器或路由器等内部资产的使用时间越长,您从中获得的价值就越大。不过,使用时间越长,运营和维护成本也会随之增加。

上云并不一定更便宜,成本不应该是唯一的决定因素。不过如果您了解云计算的总体拥有成本,就能更好地做出明智的云决策。在确定云计算的价值驱动因素时也要特别考虑利用率因素,如虚拟机每天运行多少小时、存储消耗、可用性和安全性。云计算的 “即用即付 “模式提供了一定的经济效益,因为它使资源管理更加灵活,并能让员工腾出时间处理其他重要任务。


降低云计算总体拥有成本的方法

您可以采取以下措施来降低长期云成本:

  • 从配置到监控,采用更多自动化技术。
  • 设计具有明确灵活性和自动扩展空间的应用程序。
  • 消除闲置或放弃的资源和服务。
  • 从按需定价转向基于消费的定价以及计划或预留实例。

相关阅读:企业私有云网络解决方案

返回资源中心

 

P4交换机

更多相关内容


可编程交换机和OpenFlow

目前的专用交换芯片(ASIC)的设计面向标准2/3层的数据包的转发操作,虽然软件定义网络(SDN)的发展为其提供一定灵活性(通过将控制平面独立出来,消除对交换和路由协议的依赖)但转发仍基于固定的数据包格式。

OpenFlow 协议定义了控制平面和数据平面之间的网络可编程接口,但对比起数据平面可编程的交换机,其灵活性和性能还是相距甚远。

例如,SDN 控制器可以使用 OpenFlow 协议,根据数据包中的附加字段(如老化时间或 IP 数据包选项字段中的值等),指示应将具有指定源 IP 地址和目标 IP 地址的数据包转发到某个端口。

而支持数据平面可编程交换机,可以使用L2/3数据包字段值以外的标准转发数据包。它能通过从不同端口发送具有相同参数的数据包来实现负载平衡。例如,它还可以根据通过交换机的数据包速率实施其他类型的策略,或者以任意格式封装数据包——根据任意帧格式转发数据包的能力对于支持非 IP 协议(例如某些物联网设备使用的一些协议)非常有用,具有可编程数据平面的交换机就可以转发这些数据包,并将其修改为通过 IP 网络发送。

P4语言与可编程数据平面的结合

为配置可编程数据平面,我们有一种专门的编程语言: 独立于协议的数据包处理器编程语言(P4)。这是一种开源语言,由 P4 语言联盟维护。P4 独立于转发硬件设计,因此必须开发专门针对硬件的编译器,才能将 P4 语句转换为硬件。

P4 程序由一组表组成,这些表指定了数据包中的字段以及要对这些字段执行的操作。解析器扫描接收到的数据包,直到与表项中的模式匹配,然后执行相关操作。P4程序没有定义的字段或操作集,因此 P4 程序员可以自由创建。

当然可编程数据平面并不是唯一支持非 IP 协议的方法,芯片为可以支持任何协议或应用而设计,但那也仅限于该应用,并且开发半导体是一个耗时且昂贵的过程。所以,可编程数据平面与 P4 编程语言的结合,为处理新协议和现有协议的新要求提供了更高效、更灵活的方式。

P4交换机与DPU的结合

Asterfusion X-T 系列是一款出色的 P4 交换机,旨在将高性能交换可编程性和 DPU 的基于状态的处理能力结合在一起,这在网络历史上尚属首次。Asterfusion 将 tofino 交换机上基于 P4 的数据路径与 ARM64 DPU 上基于 DPDK 的流量处理相结合,帮助应用于负载平衡、NAT 和 NVMEoF等场景。

产品详情:X-T系列:全开放、可编程、高性能的P4可编程硬件平台 – 星融元Asterfusion

P4可编程硬件平台产品开箱图

返回资源中心

 

超算中心/高性能计算数据中心的网络建设

更多相关内容


云计算和超级计算的区别

  • 通用 vs 专用:云计算面向更广泛普适的场景,随着应用领域和应用层次不断扩张,对外提供丰富多变的云业务应用;超级计算/HPC则主要提供国家高科技领域和尖端技术研究需的运算速度和存储容量,其中主要包括航天、能源、国防、气候建模等
  • 分布 vs 并行:云计算以分布式为特色,统筹分散的硬件、软件和数据资源,通过软件实现资源共享和业务协同,运行的任务也是分布式的,当前云计算正在从核心云转向边缘云,分布式理念体现得更加极致;超算集群逻辑上是集中式的,针对计算密集型任务更强调并行计算以获得高性能,各节点任务存在前后的依赖,节点之间数据交换的延迟要求极高。
  • 成本 vs 性能:云计算中心的底层逻辑是规模经济,追求成本效益,一般采用廉价标准x86硬件搭建,可用性、可靠性、扩展性大多通过软件模拟实现;而超算中心更追求卓越性能,舍得花钱升级计算和存储,使用各类高性能加速芯片、低延时通信、高级存储系统,随之而来的能源消耗也很高。

我国超算中心的布局

超级计算又称高性能计算 (HPC),是计算科学的重要前沿分支,指利用并行工作的多台计算机系统(即超级计算机)的集中式计算资源,处理极端复杂或数据密集型问题。超算能力是衡量一个国家或地区科技核心竞争力和综合国力的重要标志。超算算力以每秒浮点运算次数衡量,一般以Petaflops(PFlops)为度量单位。

目前,全国国家超级计算中心有十座,分别位于天津、广州、长沙、深圳、济南、无锡、郑州、昆山、成都和西安,其中深圳和西安中心二期正在建设,文昌航天超算中心已进入建设尾声。

我国超算中心的介绍

超算中心网络建设

超算中心需要解决的一个性能瓶颈,是各个计算节点之间的网络连接。在早期的计算中心内部,服务器之间是通过普通的万兆网卡和网线(或者光纤)使用 TCP/IP 协议传输数据。这种方案下网络延迟和吞吐量完全无法满足高性能计算的需求。

目前超算中心主流的网络架构基于 RDMA (Remote Direct Memory Access),远程直接数据存取),它通过网络把数据直接传入计算机的存储区,将数据从一个系统快速移动到远程系统的内存中,而不对操作系统造成任何影响,这样就不需要用到多少计算机的处理功能。RDMA有三个特点,低时延、低CPU占用、高吞吐带宽。它就是为了解决网络传输中服务器端数据处理的延迟而产生的。

当前RDMA技术有三大路线,分别是InfiniBand,iWARP和RoCE。

InfiniBand 是由 InfiniBand 行业协会所倡导的。InfiniBand 采用封闭的私有协议,需要使用 Mellanox 的专用交换机。但它的性能目前是三派之中最强的。iWARP 是在 TCP/IP 协议上面,对 RDMA 做的技术封装。从原理上看,它就失去了 RDMA 的性能优势,已经逐渐被业界所抛弃了。

值得一提的是 RoCE。RoCEv2 标准可实现 RDMA 路由在三层以太网的传输——RoCEv2 规范将用以太网链路层上的 IP 报头和 UDP 报头替代 InfiniBand 网络层,只需专用网卡和低时延的以太网交换机便可实现。与此相对的,InfiniBand 只有单一厂商,可能存在厂商锁定问题,并且供货周期和后续维保服务难以保证。所以,RoCE 作为低时延替代方案,越来越被人们所重视。

星融元高性能计算(HPC)网络方案(基于RoCEv2)

AIGC承载网方案架构图AIGC承载网方案架构图

超低TCO、超高性价比

相较于IB网络方案,大幅度降低用户的网络TCO,同时确保超高性能

横向平滑扩容、1:1收敛无阻塞

无收敛的网络设计确保无阻塞的大容量网络,按需横向扩展

整网RoCEv2

基于CEE/DCB能力,提供可与IB媲美的性能和同样无损的网络服务

开放网络操作系统

星融元网络操作系统AsterNOS,SONiC企业级发行版,支持灵活的功能扩展、在线升级

无缝对接云管

AsterNOS 利用简单易用的REST API,可轻松让第三方的云平台/控制器快速纳管

专家级服务

专业、全面、可靠的研发、方案与服务团队,为客户提供小时级的快速响应服务

本文参考:
浙商证券行业报告 算力铸就大模型:超算、智算及数据中心行业报告(2023)
HPCWire https://www.hpcwire.com/topic/networks/

返回资源中心

 

分布式机框(DDC)方案和全盒式低时延组网对比

更多相关内容


什么是分布式机框DDC?

DDC,Disaggregated Distributed Chassis的概念指使用若干个低功耗盒式设备组成的集群替换框式设备业务线卡和网板等硬件单元,盒式设备间通过线缆互联形成集群。整个集群通过集中式或者分布式的NOS(网络操作系统)管理,以期突破DCI单框设备性能和功耗瓶颈的问题。

分布式机框DDC

分布式机框方案的优势和劣势?

降低单点功耗:多台低功耗的盒式设备分散部署,解决了功耗集中的问题

传统的机框式交换机随着交换芯片技术的不断提升,交换容量越来越大,端口从 100G 逐步过渡到400G。但随之而来的是交换机功耗的大幅提升,16 槽位的机框交换机,全400G 端口需要4-5 万瓦的电力供应,这对老机房的设备选代升级带来巨大挑战,部分机房机柜电力无法满足需求。

突破框式设备扩容限制:通过多设备集群实现扩容,不受机框尺寸限制;

降低单点功耗:多台低功耗的盒式设备分散部署,解决了功耗集中的问题,降低机柜电力和散热的要求;

提升带宽利用率:与传统的ETH网Hash交换相比,DDC采用信元(Cell)交换,基于Cell进行负载均衡,有助于提升带宽利用率;

缓解丢包:使用设备大缓存能力满足DCI场景高收敛比要求。先通过VOQ(Virtual Output Queue)技术先将网络中接收到的报文分配到不同的虚拟出队列中,再通过Credit通信机制确定接收端有足够的缓存空间后再发送这些报文,从而减少由于出口拥塞带来的丢包。


当然,以上只是有关厂家对外宣称的说法,对此也有业内人士提出了质疑,总结了DDC方案的四大缺陷。

缺陷一:不可靠的设备管控平面

框式设备各部件通过硬件高度集成、可靠性极高的PCIe总线实现控制管理面互联,并设备都使用双主控板设计,确保设备的管控平面高可靠。DDC则使用“坏了就换”的易损模块线缆互联,构筑多设备集群并支撑集群管控平面运行。虽突破了框式设备的规模,但这种不可靠的互联方式给管控面带来了极大风险。两台设备堆叠,异常时会出现脑裂、表项不同步等问题。对于DDC这不可靠的管控平面而言,这种问题更容易发生。

缺陷二:高度复杂的设备NOS

SONiC社区已有基于VOQ架构下的分布式转发机框设计,并持续迭代补充和修改以便于满足对DDC的支持。虽然白盒确实已经有很多落地案例,但“白框”却少有人挑战。构筑一个拉远的“白框”,不仅仅需要考虑集群内多设备的状态、表项信息的同步和管理,还需要考虑到版本升级、回滚、热补丁等多个实际场景在多设备下的系统化实现。DDC对集群的NOS复杂度要求指数级提升,目前业界没有成熟商用案例,存在很大的开发风险。

缺陷三:可维护方案缺失

网络是不可靠的,因此ETH网络做了大量可维护和可定位的特性或工具,比如耳熟能详的INT、MOD。这些工具可以对具体的流进行监控,识别丢包的流特征,从而进行定位排障。但DDC使用的信元仅是报文的一个切片,没有相关IP等五元组信息,无法关联到具体的业务流。DDC一旦出现丢包问题,当前的运维手段无法定位到丢包点,维护方案严重缺失。

缺陷四:成本提升

DDC为突破机框尺寸限制,需要将集群的各设备通过高速的线缆/模块互联;互联成本是远高于框式设备线卡和网板之间通过PCB走线和高速链接器互联,且规模越大互联成本越高。

同时为降低单点功耗集中,通过线缆/模块互联的DDC集群整体功耗高于框式设备。相同一代的芯片,假设DDC集群设备之间用模块互联,集群功耗较框式设备高30%。


AI场景下,DDC方案能否应对?

AI网络支撑的业务其特征是流数量少,单条流的带宽大;同时流量不均匀,经常出现多打一或者多打多的情况(All-to-All和All-Reduce)。所以极易出现流量负载不均、链路利用率低、频繁的流量拥塞导致的丢包等问题,无法充分释放算力。

根据上文,DDC使用信元交换将报文切片成Cells,并根据可达信息采用轮询机制发送,流量负载会较为均衡的分配到每一条链路,实现带宽的充分利用,这可以解决DCN中大小流的问题,仍然存在相当多的缺陷。

AI场景下的DDC方案

缺陷一:硬件要求特定设备,封闭专网不通用

DDC架构中的信元交换和VOQ技术,均依赖特定硬件芯片实现。DCC依赖硬件并通过私有的交换协议构建了一张封闭的专网并不通用,给后续运维以及升级扩容造成困难。

缺陷二:大缓存设计增加网络成本,不适合大规模DCN组网

DDC方案除去高昂的互联成本外,还背负着芯片大缓存的成本负担。DCN网络当前均使用小缓存设备,最大仅64M;而源于DCI场景的DDC方案通常芯片的HBM达到GB以上。

缺陷三:静态时延增加

DDC的大缓存能力将报文缓存,势必增加硬件转发静态时延。同时信元交换,对报文的切片、封装和重组,同样增加网络转发时延。通过测试数据比较,DDC较传统ETH网转发时延增大1.4倍。显然不适应AI计算网络的需求。
缺陷四:DC规模增大,可靠性下降

DDC进入DCN需要满足更大的一个集群,至少要满足一个网络POD。这意味着这个拉远的“框“,各个部件距离更远。那么对于这个集群的管控平面的可靠性、设备网络NOS的同步管理、网络POD级的运维管理要求更高。

全盒式的分布式组网方案

盒式组网方案

高性能计算、分布式存储等场景的低时延以太网

区别于DDC方案本质上仍是一个被拆解的”机框”,星融元的分布式组网则将解耦这件事做得更彻底——依靠高密度、大容量的盒式设备+专利的分布式算法,将禁锢在机箱内的CLOS架构分布到网络中,将网络的规划、部署、调整、优化,这些的主动权交还给用户,大幅降低建设成本,提升可扩展性,轻松实现千万级虚机规模的网络部署

数据面:支持专利的分布式路由算法PICFA,所有交换机能力整合为一个超级的“分布式虚拟路由表”,支持大规模组网扩展

在部署了PICFA的云网络中,所有租户的所有虚拟网络信息被动态、智能、均衡地分布在全网的所有Spine和Leaf交换机上,充分利用所有交换机的所有表项空间,由此,单台网络设备的FIB容量不再成为云的容量限制,虚拟机数量获得量级的提升,服务器计算力被充分利用。

控制面:采用ARP转主机路由的去堆叠方案,将路由分布到全网,Leaf仅保留直接接入VM的MAC表项,降低表项空间要求

Leaf交换机以上均采用L3路由,Leaf交换机仅需保存直接接入的虚机的MAC表项,有效的降低了Leaf交换机上的表项空间要求,也从另一个角度解决了Leaf交换机表项空间不足的问题

管理面:全网统一配置模板,支持ZTP零配置上线,即插即用,提高运维效率,全网分层简化配置,只需两个配置模板(Spine、Leaf)上线即插即用。

星融元全盒式组网在时延敏感网络场景的应用(以AIGC网络为例)

1、接入能力:网络架构横向扩展与存算分离

由于GPU资源本身稀缺的特性,尽可能多的把GPU资源集中在一个统一的资源池里面,将有利于任务的灵活调度,减少AI任务的排队、减少资源碎片的产生、提升GPU的利用率。要组成大规模GPU集群,网络的组网方式需要进行优化

AIGC网络架构拓扑

AIGC组网中的PODAIGC承载方案架构图

ToR交换机用于和GPU Server直接连接,构成一个Block;ToR交换机向上一层是Leaf交换机,一组ToR交换机和一组Leaf交换机之间实现无阻塞全连接架构,构成一个Pod;不同Pod之间使用Spine交换机连接。

  • Block是最小单元,包括256个GPU
  • Pod是典型集群规模,包括8个Block,2048个GPU
  • 超过2048个GPU,通过Fabric-Pod模式进行扩展

2、高可用设计

可用性问题在GPU集群中要求不高,因为大规模分布式的AI任务基本都是离线的训练任务,网络中断不会对主业务造成直接影响。但是这不意味着网络可用性无需关注,因为一个AI训练持续的时间可能会很长,如果没有中间状态保存的话,网络中断就意味着前面花费时间训练出来的成果全部失效,所使用的GPU资源也全部被浪费。

考虑到AI训练任务对网络拓扑的高度敏感性,某一处网络的中断会导致其他节点网络的非对称,无限增加上层处理的复杂度,因此在设计集群的时候需要考虑中断容忍的网络架构。

双上联设计

存储双上联

由于网络中断,导致一个存储节点下线,可能会在网络内触发大量数据恢复流量,增加网络负载,因此,建议采用双上联设计,确保某个交换机或上联链路中断不会影响存储节点的可用性。

计算单上行

如上文提及,综合性能与成本考虑,计算网暂不考虑双上联设计。

GPU网卡连接方式:同一个GPU Server上的8块卡连接到8个ToR,可以节省机间网络的流量,大部分都聚合在轨道内传输(只经过一级ToR),机间网络的流量大幅减少,冲击概率也明显下降,从而提供了整网性能。但是上面的方案,GPU Server上任何一个网卡或链接中断都会导致网络的非对称,整个GPU Server都会受到影响。所以干脆让所有网卡共享同一个交换机,好处是如果ToR交换机故障,影响到的GPU Server会尽可能少,从整个系统的角度出发,可用性反而提高了。

更多相关资讯:
客户案例:高性能、大规模、高可靠的AIGC承载网络
全以太网超低时延HPC网络方案 – 星融元Asterfusion
全闪分布式存储网络解决方案 – 星融元Asterfusion

本文参考:
http://www.cww.net.cn/article?id=577516
https://www.odcc.org.cn/download/24 DDC 技术白皮书2021

返回资源中心

 

云数据中心交换机向400G过渡,面临着哪些机遇与挑战?

更多相关内容


2021 年,云数据中心交换机的销售额以两位数增长,而非云领域的销售额则以中等个位数增长。到 2026 年,全球数据中心交换机市场的价值预计将达到 199 亿美元,年复合增长率为 5.6%。近年来,数据中心交换机市场的云计算部分预计将以几乎是非云计算市场两倍的速度扩张。以下是促成如此强劲的市场预测的主要因素:

  • 持续的供应链问题推动了冲动消费
  • 各行业数字化转型速度加快
  • AI的等新兴业务驱动下,网络基础设施建设进入一轮扩张周期

数据中心交换机市场的美好前景固然带来了巨大的机遇,但在向400G过渡的过程中也面临着挑战。

400G交换机的市场机遇

  • 芯片平台的多样性: 芯片多样性是过去几年数据中心行业的主题,这也给半导体巨头 Broadcom 带来了一定的压力。
  • 智能设备: 智能设备的技术进步推动了对复杂连接和增强型网络解决方案的需求。预计这一趋势将推动芯片在数据中心服务器中的集成,从而为全球数据中心交换机市场提供利润丰厚的增长机会。

400G交换机的市场挑战

  • 数据中心运营成本: 数据中心需要考虑当地的能源价格,因为能源成本在整体运营成本中占很大比重。对于云服务提供商和超大规模数据中心来说,能源成本本身就会令人望而却步。此外,机器维护和人工等额外运营费用也阻碍了市场的扩张。
  • 复杂的架构: 由于云计算、服务器虚拟化、计算和存储技术的发展,数据中心架构变得越来越复杂。虽然高性能和更高带宽的数据中心交换机可以处理巨大的工作负载,但在各种架构中实施高带宽解决方案仍面临诸多挑战。
  • 此外,在数据中心使用的各种技术之间建立兼容性也变得十分困难,这可能会导致大量额外开支,并阻碍新的部署。

型号为CX732Q-N的数据中心交换机

星融元推出的32x400G规格的低时延交换机在公有云、私有云等场景下都有着不俗的性能表现,可为云数据中心多业务融合、高性能计算、大数据分析、高频交易等多种业务场景提供卓越的网络服务。

除了400G规格以外,CX-N系列还有以下型号以供组网选择:

型号高度业务接口 交换容量
CX308P-48Y-N1U48 x 25GE SFP28, 8 x 100GE QSFP284.0Tbps
CX532P-N1U32 x 100GE QSFP28, 2 x 10GE SFP+6.4Tbps
CX564P-N2U64 x 100GE QSFP28, 2 x 10GE SFP+12.8Tbps
CX664D-N2U64 x 200GE QSFP56, 2 x 10GE SFP+25.6Tbps
CX732Q-N1U32 x 400GE QSFP-DD, 2 x 10GE SFP+25.6Tbps

CX-N系列预装的网络操作系统为AsterNOS(基于SONiC),具备高度的功能定制和可扩展性,帮助实现网络运维自动化。对比社区版SONiC,AsterNOS在以下方面做了大量功能补充和增强:

值得一提的是,与MC-LAG 解决方案相比,EVPN Multi-homing不仅能更好地解决可扩展性和流量负载平衡方面的限制,还能提高 VXLAN 接入端的可靠性。

更多有关EVPN Multi-homing的介绍:

MC-LAG还是Multi-Homing?探讨网络通信高可用性的新选择

此外,AsterNOS 完全支持类似 Cisco 的命令行模式,大大降低了运维端的学习成本。

下面是我们在使用 AserNOS 的交换机上演示以 不同的命令行模式(Klish/Bash)配置 VLAN。

AsterNOS配置界面

欢迎关注微信公众号“星融元Asterfusion”,获取更多技术分享和最新产品动态。

返回资源中心

 
  • 1
  • 2

对星融元产品感兴趣?

立即联系!

返回顶部

© 星融元数据技术(苏州)有限公司 苏ICP备17070048号-2