SAN关键技术包括哪些？

基于 SAN 设计理念和参考架构，SAN 扩展增强网络技术，研究了HFC 混合功能链、FSP 灵活调度策略、FS-OAM 全栈算网 OAM、端到端网络业务协同及基于统一标识的智能端网协同等关键技术，构建了 SAN 技术体系并研制了 SAN 样机。

1.HFC（Hybrid Function Chain）混合功能链

1.1 HFC 技术特征与内涵

伴随着应用和服务愈来愈复杂和多样化，一种对外服务中往往包含多个子服务协同及链式调度关系，而服务间互联意味着业务流量将经由网络通过多个服务端点。旨在为跨越多个服务端点和相应连接网络的对外服务提供全程与端到端的一致性服务需求保障能力，本文定义了一种混合功能链（HFC，Hybrid Function Chain）技术架构。

混合功能链（HFC，Hybrid Function Chain）的特性主要包含： 混合的服务功能类型与部署方式：基于部署态，服务与应用功能可以通过容器的形式部署在一个或多个集群，也可以基于虚机部署；服务与功能实例可以多实例部署，也可以基于 Serverless 架构动态申请与释放。基于运行态，微服务与单功能组成了多样化的对外服务，相应的，微服务与单功能对资源侧和网络侧也往往不同的需求。不同于传统网络领域服务功能链（SFC，Service Function Chain）中的服务都是是网络服务功能，HFC 中面向的服务功能也包括应用服务。  混合的服务功能间关系：服务与应用功能之间连接、请求、交互与协同方法往往呈现出多种形态，上下游服务与应用功能或微服务之间的协同与连接方式是多样化的，如单向Notification 模式、双向 Request-Response 模式，并且单个上游服务可能请求单个下游服务，也可能同时需要调用多个下游服务。  混合的算网技术的应用：跨越多段连接网络，经历多个应用服务端点的HFC需要资源侧和网络侧高度协同，技术栈跨越应用和网络层。

1.2 HFC 系统架构

HFC 架构层次包括管理面、控制面和数据面。在以Istio 系统层次和当前网络业务组件为例的当前云网控制面基础上，HFC 系统架构设计相应的补充与增量特性。在管理面中新增了服务分析和运营、服务和资源建模和服务编排和调度策略管理功能；在控制面中新增了服务注册和注入、服务发现和发布、服务路由生成和服务基础互联功能；在数据面中新增了服务标识管理、服务感知的转发和服务观测和保障功能。

1.3 基于 SRv6 的 HFC 技术

SRv6 技术作为新一代 IP 承载协议，基于现有的 IPv6 转发能力，通过灵活的IPv6扩展头，实现网络可编程。而基于 SRv6 的能力扩展，可以将 HFC 的端到端服务路径信息、各服务感知网关 SID 信息或连接上下游服务的转发路径信息编码在报文中，从而实现跨越多个服务端点和相应连接网络的对外服务提供全程与端到端的一致性需求保障，并提供对应的算网流量工程与智能调度能力。 根据在始发服务感知网关处直接封装端到端服务路径或仅封装下一跳服务转发路径，可以将基于 SRv6 的 HFC 技术更具体地以紧耦合和松耦合的技术特征进行分类。

2.FSP(Flexible Scheduling Policy)灵活调度策略

2.1 支持多种约束条件的 TE 计算

基于 SAN-TE 统一算网调度架构，允许实现调度策略灵活选择和部署，兼顾集中全局优化（跨越多个区域、连结算力与网络）与快速收敛的分布式计算。SAN-TE 计算约束条件分为体验优先（如延迟、抖动和丢包）、成本优先（资源消耗和能耗）和效率优先（如资源利用率、均衡性）三类，各自在系统设计和运营中发挥着关键作用：

 体验优先：这类约束确保服务质量（QoS），重点关注用户体验的关键指标，如延迟、抖动和丢包率。在算网一体化环境中，延迟是指数据从源到目的地所需的时间；抖动关注延迟变化的稳定性；丢包则反映网络传输的可靠性。通过优化这些指标，算网SAN-TE 致力于提供流畅、无中断的服务体验。  成本优先：成本优先约束关注资源消耗和能耗的最小化。在资源有限的情况下，高效利用计算和网络资源对降低运营成本至关重要。此外，随着绿色计算和可持续发展目标的日益重要，能耗成为 SAN-TE 设计中的另一个重要考量。通过智能化调度和优化策略，SAN-TE 致力于在满足服务需求的同时减少能源消耗和环境影响。 效率优先：这一约束集中在提高资源利用率和系统均衡性上。资源利用率高意味着系统能够更充分地利用现有资源，避免浪费；而均衡性则确保了系统负载分布均匀，防止局部过载导致的性能瓶颈。通过动态调整资源分配策略和优化网络流量管理，SAN-TE力求实现整体系统效率的最大化。

上所述，体验优先、成本优先和效率优先三类约束在 SAN-TE 中扮演着不可或缺的角色。它们不仅指导着系统的设计和优化方向，还直接关系到最终用户的服务质量和运营商的经济效益。在实际部署中，平衡这些约束之间的关系是一项挑战，需要综合考量业务需求、技术可行性和经济成本等因素。

2.2 业务调度和负载均衡技术

从业务视角出发，根据调度触发机制的不同，SAN-TE（SAN Traffic Engineering）的应用模型存在以下三种，其特点如下：  周期调度：该调度方式并不依赖于实时的业务流请求来触发。相反，它遵循预设的时间周期或特定事件（例如算力状态超出预设阈值）来自动执行。在这一机制下，算网TE会定期或在事件触发时计算面向特定服务标识的最优网络路径与计算实例，并将计算结果直接下发至转发平面。当业务请求首次抵达入口算力网关时，系统会根据服务标识进行匹配。一旦匹配成功，将进一步触发生成流亲和表，确保后续所有相关报文能够准确无误地被路由至同一计算实例，从而实现高效的数据处理与资源利用。

逐流调度：在逐流调度模式中，控制平面并不直接向转发平面推送详细的算网调度结果。相反，它仅下发服务标识表以识别特定的算力请求报文。当带有服务标识的业务请求进入算力网关时，报文会被上送至控制平面。随后，控制平面会基于当前的算力状态与网络状况，动态计算出最合适的路由路径或匹配已有的、符合需求的算力资源分配方案。计算完成后，相应的流亲和表将被生成并下发至转发平面，确保后续同一业务流的所有报文都能被导向至同一计算实例进行处理，以实现精准的业务流亲和与资源优化分配。 混合调度：在同一个支持多种服务的算网调度系统中，根据业务特点不同，基于服务标识定制调度方式，根据调度方式配置来灵活选择周期调度或逐流调度。通过智能化的路径计算与资源分配策略，提升算力网络的服务质量和效率。

于以上三种调度策略，SAN 汲取了多种模式的优势，还创新性地引入了一种全新的负载均衡机制。这一机制旨在缓解 TE 计算带来的局限性。其主要特点包括： 控制面 TE 计算：通过一次 TE 计算，系统能够自入口网关至所有满足算网SLA（服务等级协议）要求的服务实例及其可达路径进行编排，并计算出相应的分担比例。这些信息被整合进算力路由表中，形成了一系列可行的下一跳选项。  转发面 TE 转发：利用首包报文中的五元组或三元组 HASH 值确定多下下一跳路由表中唯一下一跳并引流和转发。这一过程同时确保了同一会话流中所有后续报文的连续性和一致性，实现了算力网络服务请求在会话级别上的精准负载均衡并大大降低控制面负载。

通过结合这一负载均衡机制与多种调度模式灵活组合，SAN 不仅保障了用户会话质量达到算网 SLA 的要求，还实现了算网资源的细粒度均衡利用。具体而言，在连续两次更新算力路由表的时间周期内，它有效避免了单一计算或网络资源因过度占用而导致的“极化”现象。同时，该机制显著减少了因算力实例状态频繁变动对控制面造成的额外压力，从而确保了系统的稳定性和效率。 总之，在提升用户体验的同时优化资源分配是 SAN 的核心目标之一。通过智能调度策略和负载均衡技术的应用，SAN 有效地避免了资源过度集中或分散所带来的问题，在算网环境中展现出强大的适应性和高效性。

3.FS-OAM(Full-Stack OAM) 全栈算网OAM

3.1 网络和计算可观测现状

可观测性是指对监控对象的状态、性能指标和事件的监控、测量、追踪和分析的能力。随着云计算、大数据以及 AI 技术和应用的迅猛发展，数据中心作为支撑各类关键业务运行的基础设施，其规模的快速发展带来了网络规模的显著扩大，网络架构日趋复杂。在这种背景下，可观测性变得尤为重要，它不仅关系到故障的快速发现、定位、和修复，也关系到性能优化，更直接影响到业务的连续性和服务质量。

3.2 FS-OAM 关键目标和技术

传统的网络侧与计算侧可观测性技术长期以来独立发展，互不兼容，缺乏必要的互操作性。面对日益显著的算力与网络融合趋势，构建一个全面覆盖、端到端的监测体系成为迫切需求。为此，整合网络域和计算域的运维管理（OAM）能力显得至关重要。

SAN 提出 FS-OAM(Full-Stack OAM) 全栈算网 OAM, 主要包括检测连通性故障、丢包、时延等指标，还包括新定义的算侧指标（连接数、资源占用等），并可以逐段、逐层覆盖， 特别关注从算力网关到计算实例的性能监测与优化，支持快速的路由收敛机制和业务质量保障。同时，它还具备强大的故障定位能力，以及高度的实用性和可扩展性。如图16 所示，当前算网一体存在四类关键需求：

需求 1--加速算网控制面收敛：为快速响应计算实例状态的变化，当前控制面感知机制在处理速度上存在局限，难以跟上算力实例状态的迅速变动。因此，亟需在数据平面实现快速监测功能，对出口算力网关到算力实例端到端状态进行实时监控。一旦检测到故障或性能劣化，将立即触发算网流量工程（TE）的计算收敛机制，采取行动避免服务黑洞现象，确保资源的有效利用与快速恢复。  需求 2--算网 SLA 评估闭环保障：为了确保服务等级协议（SLA）得到持续满足，有必要从算力路由表中提取与网络到计算实例路径相关的测量数据。通过TE 计算得出的算力路由信息需经过验证，确认其是否符合既定的算网 SLA 标准。

需求 3--业务流 SLA 闭环保障：服务访问激活后，后续数据包通过流亲和表转发至同一计算实例，期间计算与网络性能可能波动。为确保稳定高质量的用户体验，需持续监控从网关到实例的业务流性能。依据算网 SLA 要求，在网络层适时进行修复或调整，以维持服务稳定可靠。  需求 4--业务故障定界和排障：当用户体验下降时，迅速准确定位问题是关键。这需要快速识别从用户终端到计算实例全路径上的故障点。传统 OAM 技术仅限于传输层监控，应扩展至应用层以实现全面监控，并据此进行端到端的故障定位与排除。增强的OAM 机制能更精准地识别故障源头，缩短恢复时间并提升服务质量。

FS-OAM 面向算网一体四大类需求提出综合解决方案，主要包括以下三个技术层面：1. 针对需求 1 和 2，FS-OAM 分别提出算网实例 OAM 和算力路由级OAM，相应的技术考虑如下：  检测协议的选择与应用：可选用 PING、TWAMP、OWAMP、STAMP 等协议或其组合进行网络到计算节点健康状况检测，建议优先采用反射型策略以提高检测效率和准确性。  检测协议部署：除了支持网络侧部署，在算侧支持上述检测协议的部署与运行，确保能够实时监测并及时响应各种变化和需求。  检测新能力拓展：为了全面覆盖算力网络的独特指标，应积极探索并引入新型检测协议，确保能够准确评估计算资源的状态和性能。 2. 针对需求 3，FS-OAM 提出算力会话级 OAM，相应的技术考虑如下：检测协议的选择与应用：为确保全面覆盖真实的业务流并获取精确的数据分析，我们应充分考虑采用随流检测技术，如 IOAM、IFA 等。  检测协议部署：在算力网络中，从网关入口至计算实例的整个传输路径上，推荐网络节点和计算实例部署。  检测新能力拓展：扩展覆盖算力网络的独特指标，比如计算时延、负载等增量信息。

针对需求 4，FS-OAM 提出应用级 OAM，相应的技术考虑如下： 检测协议的选择与应用：存在两种路线（1）为了实现高效且低开销的端到端业务性能监测，可基于创新的轻量级端侧协议栈利用探针机制，确保对业务流程进行全面而精准的追踪与分析；（2）在跨端、网、云的环境中，采用随流检测技术延伸到算侧，实现对传输业务的更加精细化监控定界。  检测新能力拓展：将云内可观测性与网络随流检测紧密结合，具体措施是在随流检测头部携带 TraceID 和 SPAN ID,结合 eBPF 将助力我们实现从用户终端到云端应用层的全程性能评估与故障定位，有效提升运维效率及用户体验。

总之，FS-OAM 延伸到算侧并定义的四个层次（实例级、表项级、业务流级、应用级）和关键技术，特别说明的是，应用级 OAM 不仅打通了网络和算侧，还实现网络OAM和eBPF、分布式追踪技术结合，实现端到端业务故障快速定界，实现算力网络“悬丝诊脉”，解决未来算网一体化运维的关键痛点。