本文基于Russ White 驾驭复杂的网络和自顶向下的网络设计等书籍,结合实际部署相关经验总结对网络架构设计和演进进行相关的可行性探讨。

网络架构设计实现中的复杂性探讨(持续UPDATE)_网络架构

1.网络设计的复杂性:复杂性两种直觉:①复杂性就是不理解 ②复杂性就是庞大臃肿

三元权衡的复杂性:

  • CAP定理:不懂的请google
  • 快速、廉价和优质:​这是一个众所周知的问题,对于任何领域来说,如果希望廉价和优质,那么就需要花费大量的时间;如果希望快速和优质,那么就需要花费更多的成本;如果希望廉价和快速,那么就得牺牲质量。这种关系适用用所有事物,包括软件和硬件。
  • 快速收敛、稳定性和简单的控制面​:网络架构中,缩短收敛时间总是会增加控制面的复杂性,或者导致网络的不稳定,从而更容易出现故障。

网路架构中的复杂性建模:

网络设计中相关解决方案的有效性和稳健性、复杂性关系图如下所示,随着业务和网络规模及复杂性递增,解决方案可能到达相关瓶颈期,就会面临稳定性的挑战。

网络架构设计实现中的复杂性探讨(持续UPDATE)_网络架构_02

网络架构设计实现中的复杂性探讨(持续UPDATE)_数据_03

  • 状态:减少状态总是朝着更少的优化或更多交互表面方向移动
  • 速度:增加速度和反馈的方向会朝着更多的状态方向移动。
  • 交互面:减少交互表面始终朝着更少的优化或更多状态方向移动。
  • 优化
  • 优化速度:可以通过增加控制面中的状态来优化网络收敛速度,但这样做必然会增加这两层网络之间的交互面,从而增加复杂性。
  • 优化状态:可以优化网络让控制面携带尽可能少的状态。
  • 优化交互面:可以按照严格的层次化方式构建网络,使得层与层之间的交互达到最少。但是这样做必然会降低收敛速度,从而导致网络可能运行在次优状态,并增加叠加式逻辑层正常操作所需要携带的状态量。

网络架构中三碗面

  • 管理平面
  • 控制平面
  • 转发平面

    如果网络的设计模式面向可预测问题,那么面对不可预测问题(基于前面的僵化效应)时就会变得脆弱不堪。对于一个网络来说,如果网络最强大的能力能够处理不可预测问题,那么就一定能够处理可预测问题,那么就一定能够处理可预测的问题,也就意味着网络不必为了处理可预测的问题提供过于健壮性的解决方案(虽然解决方案不过于健壮对于避免僵化效应来说确实有必要,但是对于解决不可预测问题来说却又显得力不从心)

常用模型:

  1. 分组流模型:
  2. 面向状态的模型:
  3. 面向API的模型:
  4. 面向策略的模型:

下面就实际网络设计架构,试图分析在常见的数据中心CLOS结构下DCN/DCI结构实践层面,按照模型进行分析对比和逐步形成相关HLD/LLD的过程展示给相关读者(作者水平有限,如果错漏之处欢迎各位大佬指正):

    什么是好的网络?这是一个复杂的问题。

    网络工程国内来说其实缺乏体系的理论培训和梳理,很多同行在术与道之间经常迷失。关于好的网络设计国内外已经有很多布道者对网络设计,结合我工作从事网络设计和构建将近有20几年的工作经验中思考,有下面几个直觉和经验分享给平时在网络设计或者网络技术选择时的小伙伴们做一点参考。

    网络设计的一个基本真相:对于网络设计,没有唯一正确的方法。网络设计通常被视为与网络安全是一样的----直到最后一刻,以尽可能快的速度完成,同时尽可能少地思考和烦忧。真正的设计从业务需求开始(而不是速度和传输,或者端口和机架),却又在简单粗暴中经常被忽略。‘‘这个项目现在就需要完成,忘记设计内容,让他工作就好。’’这是通向技术性债务的道路,也是网络最终崩溃和业务失败的必经之路。

1.网络设计的维度

2.什么是好的网络设计?

关于网络设计的直觉

第一点:很明显即它应该能满足主要的业务需求。

第二点:好的网络设计会优雅的降级,而不是悬崖式的降级。

第三点是:良好的网络设计允许操作人员快速的发现和修复故障。换句话说,良好的网络设计与平均修复时间(MTTR)相互作用

3.如何能设计出好的网络

网络设计的真正目标是设计出好的网络的必要条件,好的网络设计真正目标到底是什么有没有相关的评判标准,如何选取相关的技术?先让我们讨论下网络设计的终极目标及其关系拆解分析:

从多年的网络从业者经验访谈来说,好的网络设计应该是:可靠的、可管理的、可扩展的。

3.1明确网络的组件

  • 硬件:实际的物理设备、电(光)缆、电源、机架和其他设备成本(理线器、配架等)这是构建物理网络所需的,当然也应包括供应商连接网络的物理设备(如备用设备和工具)成本
  • 软件:网络操作系统、路由堆栈、监控工具的许可成本以及任何需要的维护成本
  • 服务:有技术呼叫的援助中心、设计服务、异地备份服务等成本

3.2如何灵活的搭积木

一些经验法则

  •     第一个是模块的大小:如果模块设置的太大,(可能)会降低可重复性,没有为自己提供足够的位置来隐藏信息(这会影响可伸缩性),也没有为自己提供足够的位置将策略插入网络中。如果模块设置的太小,就会降低信息隐藏过程的有效性。找到合适的大小就像找到刚好合适温度的粥一样,没有明确的答案(或者是更好的答案:一个袋子能装多少个气球?)
  • 第二个是优化权衡:每次隐藏信息时,(很可能)都会在网络中丢失某种形式的优化。这是一个基本的规则,因现实中的实际情况而内置在网络和协议的设计中。
  • 第三个是使用网络复杂性作为确定模块边界位置的指南:一般来说,最好的规则是把复杂性区分开来。例如,如果有一个大型的骨干和叶子节点的数据中心fabric连接到一个大型的半网格(mesh)的网络核心,那么最好将它们放在两个不同的模块中。

3.3调整优化的手段分析

3.4故障排除手段和分析

4.额外需要考虑的问题