本文由 Oracle 5G 产品组合产品经理 Ankit Srivastava 与 Oracle 对外产品生命周期管理(Outbound Product Lifecycle Management)部门的多代网络负责人 Suchismita Mohanty 共同撰写。
随着 5G 网络日益实现自动化与智能化，通信服务提供商(CSPs)面临着一项挑战：如何在不牺牲电信行业严苛的可靠性与服务要求的前提下，实现媲美云环境的弹性扩展能力。鉴于数据量持续激增且流量模式日趋多变，CSPs 必须对其扩展策略进行迭代升级。然而，尽管自动扩展在云原生环境中已是标准配置，但电信基础设施却需要在效率、成本以及不容妥协的可靠性之间进行审慎的权衡。实现这种平衡至关重要：若资源配置过度，将导致能源消耗与运营成本飙升;反之，若资源配置不足，则会危及服务质量与客户满意度。
电信领域的自动扩缩容：独特的考量与权衡
电信网络中的自动扩缩容面临着独特的挑战，这些挑战有别于典型IT环境中遇到的难题。为了维持高可用性、满足严格的可靠性标准并高效管理资源，电信领域形成了一种复杂的局面，需要在性能与能耗之间进行权衡取舍。电信运营商通常采用“两站点”或“三站点”的地理冗余配对模式来部署网络功能，以确保实现高可用性。
图1：两站点与三站点部署模式
尽管这种方法能够在光纤中断或自然灾害等站点故障发生时确保系统可靠性，但往往会导致资源过度配置。自动扩缩容所面临的挑战在于，如何设定智能的扩缩容触发机制——既能确保在站点故障发生时即时增加资源，又能避免不必要的开支浪费。
这就要求对实际流量模式、延迟目标以及微服务的启动时间进行深入分析。其中的关键考量在于：云原生技术如何在保持网络韧性的同时，实现资源的优化配置。此外，电信网络还可能因信令风暴或网络拥塞等因素，而遭遇突发性的流量激增。
图 2：典型的电信流量模式
自动扩缩容面临的挑战在于，如何准确定义自动扩缩容阈值，从而更好地预留必要的资源缓冲，以应对网络中突发的流量高峰。
网络的端到端服务等级协议(SLA)引入了另一个维度的考量，因为流量路径中的每一个网络功能(NF)都会影响整体的5G业务流程SLA。供应商必须审慎评估自动扩缩容操作如何影响网络功能SLA的履约情况，从而有助于防止在扩缩容事件发生期间出现服务质量下降的问题。
针对有状态网络功能(Stateful NFs)进行自动扩缩容，会在数据一致性和完整性方面带来特定的风险，尤其是在涉及持久化存储的场景下。对于那些负责存储用户设备(UE)会话状态数据、UE上下文等信息的有状态网络功能而言，其自动扩缩容过程可能潜藏着数据一致性受损或数据损坏的风险。因此，针对此类网络功能及其相关服务的自动扩缩容操作，必须经过详尽的验证。
最后，自动扩缩容的成效在很大程度上取决于应用层与基础设施层之间能否实现更加无缝的集成。只有当网络功能层与底层的Kubernetes基础设施层能够实现协同扩缩容时，才能真正实现运营成本(OPEX)的节约。如果仅仅在应用(网络功能)层面进行自动扩缩容，而底层的Kubernetes集群未能随之自动扩缩容以优化服务器资源利用率，那么将无法真正实现运营成本的节约。
Kubernetes原生自动扩缩容能力
Kubernetes提供了“水平Pod自动扩缩容”(Horizontal Pod Auto-scaler，简称HPA)机制，该机制包含了“资源指标监控”、“扩缩容触发”以及“扩缩容执行”这三个核心组件。Kubernetes HPA原生支持基于虚拟CPU(vCPU)和内存资源利用率进行自动扩缩容。
自动扩缩容过程主要包含以下几个步骤：
- 资源指标监控——监控应用资源利用率相关的指标，例如CPU利用率、内存利用率，或者队列利用率、缓冲区使用量等内部参数。
- 扩缩容触发——当被监控的指标数值达到预设的阈值时，即触发扩缩容操作。
- 扩缩容执行——向外扩容(Scale-out)：当被监控指标数值超过扩缩容阈值时，系统将新建(生成)应用Pod实例。向内缩容(Scale-in)：当被监控指标数值回落至扩缩容阈值以下时，系统将移除现有的应用Pod实例。
- 负载均衡——供应商应探索相应的方案，以便在自动扩缩容完成后，对流向应用微服务的HTTP/2连接进行负载均衡，从而确保流量能够得到公平、均衡的分配。
此外，Kubernetes还允许用户使用自定义的应用指标(例如队列利用率、每秒事务处理量等)作为依据，来实现应用层面的自动扩缩容。
图3：水平自动扩缩容
5G 网络功能微服务自动伸缩的最佳实践
通信服务提供商(CSPs)倾向于采取一种审慎、循序渐进的方法在网络中实现自动伸缩，以避免因引入动态网络功能(NF)资源管理而扰乱既有的运营流程。建议基于历史流量模式、具体时段以及呼叫构成比例来实施资源伸缩，从而在确保最佳服务质量(QoS)的同时提升成本效益，进而实现运营支出(OPEX)的优化。
如下图所示，典型的 5G 网络功能架构包含连接层、业务逻辑层和数据层。在实施自动伸缩的过程中，每一层都会面临不同的挑战;因此，供应商必须遵循“分而治之”的策略，通过以下步骤为 5G 网络功能实现自动伸缩：
图 4：典型的 5G 网络功能架构
第一步：业务逻辑微服务的自动扩缩容
在设计网络功能(NF)微服务时，应致力于加速实现功能就绪状态，以便新生成的微服务 Pod 能在启动后迅速投入使用并有效处理流量。此外，微服务还必须支持“优雅关停”机制，确保在 Pod 终止前，所有正在处理中的消息都能被妥善处理完毕。
对各个 NF 进行评估，以识别哪些微服务对整体资源消耗(资源足迹)贡献最大，并考虑针对这些关键领域启用自动扩缩容功能，将是一项极具价值的举措。我们鼓励供应商为其 NF 微服务提供详细的资源利用率和性能指标数据，因为这些信息能有效协助运营商设定合理的自动扩缩容阈值。
第二步：连接层的自动扩缩容
鉴于 NF 资源中有相当一部分往往被分配给负责管理 HTTP/2 连接的微服务，因此在这一层面实施自动扩缩容策略时，必须给予特别的考量。该层的自动扩缩容操作可能会引入涉及 HTTP/2 连接生命周期管理的复杂性。在进行“横向扩容”(Scale-out)时，新启动的 Pod 通常只有在接收到新的 HTTP/2 连接后才能真正发挥作用;因此，引入智能的连接负载重平衡机制，将有助于实现流量在新旧 Pod 之间的高效平滑切换。
同理，在进行“横向缩容”(Scale-in)时，建议相关 Pod 支持对 HTTP/2 连接进行“优雅关停”处理，从而确保在 Pod 终止前，所有正在处理中的消息都能被完整处理。云服务提供商(CSPs)应考虑开展互操作性测试，以确认自动扩缩容操作不会对 NF 之间的相互通信产生负面影响。
第三步：数据层的自动扩缩容
为了最大限度地降低在扩缩容过程中发生数据损坏的风险，通常建议供应商将数据层微服务与持久化存储层进行解耦。
充分考量上述各项因素，将有助于 CSPs 和供应商显著提升 5G 网络功能的扩缩容能力、运行效率及可靠性，从而构建一个更加稳健且响应更为敏捷的网络体系。
可持续的扩缩容策略
随着 5G 网络持续扩展以容纳新用户、物联网(IoT)生态系统及下一代前沿技术，对新增 NF 实例的需求也随之激增，进而推动了对基础设施进行扩容的需求，但这同时也导致了资本支出(CAPEX)和运营支出(OPEX)的增加。因此，高效利用现有基础设施，对于实现网络的可持续增长以及确保成本效益，具有至关重要的作用。自动扩缩容机制必须实现演进与升级，超越传统的单纯基于能耗的模型，进而涵盖智能化的工作负载管理、合规性监管要求以及网络韧性规划等更为广泛的维度。
展望未来
自动伸缩(Auto-scaling)是构建高效、弹性5G网络的关键赋能技术，它使通信服务提供商(CSPs)能够根据不断变化的需求模式动态调整资源配置，同时满足严格的性能与可靠性要求。在电信环境中实施自动伸缩，需要采取一种循序渐进且全面的策略，以充分兼顾网络架构中各层级的独特特性。若要在5G网络中实现有效的自动伸缩，必须重点关注业务逻辑层中那些高影响、低依赖的微服务;在连接层利用智能化的HTTP/2连接管理机制;并在数据层推进存储伸缩能力，同时高度重视数据的强一致性。
通过采取这种全面的策略，并加强编排层与应用层之间的协同配合，运营商将能够在可靠性、成本、可持续性与性能之间取得最佳平衡;最终实现无缝的伸缩能力，从而将对现有服务的影响降至最低，并显著降低运营风险。
参与评论 (0)