新基建也是基建，摆脱不了它作为基础设施建设的本质，所以标题皮了一下，从底向上看，就是农民工盖楼搞IDC建设，然后为了加速建设采用装配式建筑的方法，整Rack的交付，这也是此文要讲的。而另一方面是从顶往下看，涉及到投资回报率，也就是从地产商或者金融民工的视角，这个下次有空写，主要是谈业务模式的，可能更多的从需求上谈一下小区物业数据中心/微蜂窝数据中心的架构设计。
有人说，这个号历史讲的多，新的东西少， 那是没明白我的苦心，一个答案的解题过程比答案本身更加重要，但总是有那么些想直接看答案的， 那这个文就简单粗暴直接给答案~
1. 网络
1.1
业务概述
Service-Mesh使得东西向流量需求激增，直播等视频业务使得跨AZ跨Region的数据实时调度需求也激增，AI训练及存储对低延迟的需求也激增，正规的解法就是接入上50G/100G，或者部分AI训练的集群上200G接入，这一点上需要注意，大多数服务器还是以CascadeLake为主， PCIE3.0限制了带宽，所以基本上单机50~100G够了，而部分AI训练集群可以采用AMD（PCIE4.0，CCIX）。
带宽并不能无休止的扩展，考虑到成本控制等因素，将不得不对某些低优先级的流量做丢包处理，否则大带宽投资回报率太低，而大buffer影响低延迟业务性能。
基于这个结论，东西向流量的调度和预测以及实时遥测（Realtime Telemetry）和基于AI的实时路径控制（Realtime path control）将会成为下一代数据中心架构中最重要的一环，那么下一代SR或者SRv6将逐渐在数据中心内部使用，而P4/NPL对报文的分类和动态标记会成为一个趋势。
控制面协议，BGP-EVPN会逐渐退缩到DCI的位置，而内部采用分布式KV数据库，例如ETCD直接将K8S，SmartNIC和交换机转发表打通和灵活的业务标记和策略标记将成为下一代数据中心必备的软件解决方案。
策略层面，数据中心网络引入基于声明式的策略实现部分的Intent Based Network的策略模型。
1.2
交换机
1.2.1 拓扑结构
CLOS架构毋庸置疑，其它拓扑（3D-Torus）通常面临接线复杂，路由难设计，调度算法复杂等问题不用考虑。只是局部的在AI训练集群中可能会有异构拓扑的需求，当然这部分内容涉及到一个很保密的项目，我才不会说呢。下面还是以CLOS为主。
为了避免说某厂的ASW/PSW/DSW或者某厂的（RSW/FSW/SSW）下面统一用TOR--Leaf--Spine描述，200G光模块价格基本上会下降到100G的两倍或者更低，那么结论就很显然了。
1.2.2 TOR交换机
根据接入服务器单机50G预估，这样就可以倒推出来接入交换机（ToR）选择6.4T(48x50 8x200GE）即可，6.4T的片子取决于客户是希望将一些可编程能力下放到SmartNIC上做，还是自己在接入TOR上做。
1.2.3 Leaf交换机
部分汇聚层交换机（leaf）可以采用12.8T的片子提供64x200GE/32x400GE的选择，12.8T是从成本上考虑的最佳选择，这个层面主要是考虑Loadbalance和Congestion management的定制化需求，P4或者NPL在这一层都有很好的应用方式。具体会在后续的运维软件部分详细说。
1.2.4 Spine交换机
核心层（Spine）现在可用的也只有12.8T的片子25.6T只有BRCM TH4，Innovium TeraLynx 8和最近Cisco发布的Quadpeak，基本上要到2021年才有产品，不过很多都是512x56G PAM4的，可能还是等等以后选择112G Serdes的产品会更好。
硬件这些相关的马总写了一个很好的文，大家看看——《超大规模云网络数据中心创新（上）》
1.2.5 MAN/DCI 路由器
SegmentRouting一定要用了，主要是用来做切片和FlexAlgo，远程教育云会议云视频直播等业务对低延迟的要求越来越高，至于大容量的MAN/DCI的片子Jericho2 或者Cisco Q100是必须要配的了，毕竟DCI的需求未来几年基本上在4Tbps以上， 而路由缓冲和低延迟等几个指标都必须要考虑，很期待这个位置上Cisco 8000 SONIC的表现。
1.2.6 MEC
云边缘建设：主要是在各大城市构建POP点便于MEC接入或者客户自带小型数据中心接入，接入协议就是IPsec没得选，虽然复杂但是互联互通暂时还没有更好的选择，但是路由层面可以使用ETCD同步Overlay路由和IPsec SPI，尽量不要使用IKE交互密钥因为这样POP点的Scale会出问题，也尽量不要使用BGP，某云Provider的自研SDWAN不就是有Scale的问题么, 而MEC交付分为几种场景
1. 单主机交付及云连接：单台基于Xeon D或者ARM N1多核的平台，单机构建SDWAN隧道连接云提供商的POP点
2. 4U/8U/16U/32U的多种规格机柜式交付，单主机交付的平台可以构成机柜交互的管理节点，提供一个48口万兆的简单的交换芯片即可，同时是否需要同时提供48个千兆的管理接口（例如iLOM的接入）， 或者各24个口的解决方案，是否提供串口管理接入取决于下面挂的服务器类型。其实就是Outposts，但是可能在MEC的位置需要不同尺寸的Pod，4U/8U可能是最好卖的，直接做成一个类刀片的系统就好了。
广域网MEC的连接和管理带来的挑战比大型和超大型数据中心难度大很多，各种意想不到的故障会使得收敛性变得比较困难，这些需要多做测试和相对详细的灾备方案。
另外部分行业可能需要完全的Baremental的交付，云管软件仅限制于在iLOM或者SmartNIC上，而本身系统完全由客户自己控制，这也是部分业务数据敏感客户的需求，在弹性和隐私间取舍平衡。
1.3
软件及策略
1.3.1 概述
针对下一代数据中心运维，一方面是东西向流量工程，另一方面是东西向的安全策略，所以最佳的实践是在报文中将安全标签和流量工程标签解耦，切忌不要使用SR标签和所谓的可编程的locator/func/argument来解决安全问题，解耦会使得上层的声明式策略更加容易实现：
1.3.2 基于分布式K-V的路由协议
BGP-EVPN用了很多年，但是它很多人忽视的地方。为了保证CLOS架构的直接通信, IBGP在CLOS下要RR肯定不好，eBGP又涉及到跨集群的ASPATH防环的问题，然后又人为定一些规则来解决。本质上在数据中心内部Overlay地址通告实际上只有K-V pair的需求，没有防环的需求，所以不得不说MPLS这群家伙真的很厉害，当年Insieme的时候很聪明的在DC内部采用了COOPS协议，也就是一个很简单的K-V pair 同步的协议。
随着下一代网络智能网卡和HostOverlay的部署，如果继续采用BGP通告到路由表中的信息变动会更加频繁，而且BGP Speaker的数据会增加数十倍，整网收敛速度会更加慢。所以至少在接入层和汇聚层采用ETCD等分布式数据库将成为一种趋势，也不用像阿里那样把ARP转路由宣告了， 直接SONIC里启动一个ETCD同步表就行了。SONIC基于ETCD的路由系统如何和K8S的ETCD互通这个也非常容易实现，看看哪个大厂能自己写了开源一个，他们不写我就过几个月忙完另一个AI Fabric的活后再来弄。
1.3.3 让主机智能网卡感知LinkState（NetOps）
主机网卡在HostOverlay的位置感知整个Fabric的Linkstate并根据链路状态实现SR，可能的SR实现会在Leaf--spine--man/dci 这一段， 而对于访问MEC的流量也需要SR支持，Linkstate结果更新到ETCD中也是必须的，而核心设备如果不支持这样的方式则可以构建一个BGP-LS转邻接表，并将邻接表同步到ETCD的方式实现（这个我前年自己写过，但是某司能不能开源就不是我说了算了的...)
1.3.4 ACL安全组向基于Micro Segment的组策略迁移（SecOps）
随着云原生容器和Serverless函数计算的使用，安全的边界会更加模糊，传统的云安全组策略基于IP地址将会很难描述，或者随着客户弹性建立和删除主机会面临大量的组策略ACL修改， 对于部分TOR实现Overlay或者HostOverlay的平台都带来了极大的运维难度， 而这些策略最好提供北向API供应用层快速编辑。
主要的方式就是对源和目的进行编码， Prefix/Mask可以作为组策略的ID，因为组策略会有颗粒度不同的需求，同时在这个编码中引入Application ID 也同样使用Prefix based组策略
1.3.5 声明式的策略
这一部分直接参考《 意图网络的语言学思考 》就好了， 不过那文的具体工程实现上没细说，还是同样的，Overlay host身份信息同步到ETCD，然后策略也在ETCD中，SmartNIC或TOR根据Overlay IP地址和端口反查ID，然后反查出策略Action并对报文进行策略组标记和执行策略。
这种分布式策略执行的方式在Pensando的实现里也有，它们同样也是采用云原生的分布式控制器，由网卡上的ARM核同步策略信息然后通过P4对网卡上的流表进行处理实现的，具体内容自己看Salvano Gai的书以及他们家最近关于PSM的视频，有版权信息就不多贴人家的图了。
1.4
运维及监控
1.4.1 基础设施监控概述
SONIC摒弃了YANG Model直接给与各个软件操作Redis DB的权限这使得DevOps速度进一步加快，的确从写代码的角度更加方便了，阿里提供了sonic-telemetry实现了标准化的gRPC dial-in/out，但是问题也随之到来，telemetry如何处理，控制面telemetry相对容易，例如光功率接口带宽丢包率等。而实时的queue depth，流量的postcard模式或者inband telemetry模式的监控使得telemetry consumer压力很大，所以你们一定要明白一个问题，控制器或者业务只关注结果不关注过程。
1.4.2 Onbox Telemetry Analytics
telemetry数据需要在box上直接分析汇总，而这种streaming的数据是连续的没有边界的，偶尔还是乱序的，大量的操作需要对流量进行Keyby-Group的算子进行聚合，例如按照流量类型聚合按照时间聚合上报。所以在这里面需要大量的在线统计算法， 例如welford's来统计mean/std，或者GK算法来统计75/90/99分位数。
所以这也是你们看到Broadcom Tomhawk 4在片子里自带ARM核的原因，同样Pensando也在网卡内携带了一颗ARM核。问题来了，流计算引擎用什么，某家的Flink刚支持ARM而且内存使用率和在嵌入式ARM核上跑Java可能会存在大量的问题，我自己则是两年前给某司写了一套基于Go的流计算引擎来解决类似的问题，你们可以借鉴一下，参考资料书籍：《广告流式系统（影印版）》作者：Tyler Akidau，Slava Chernyak，Reuven Lax.
1.4.3 按需全链路追踪
业务层已经有Google Dapper一类的解决方案来实现APM，而网络层对于业务层的Tracing ID无感知，因此建议在service-mesh架构中，将Tracing ID暴露在网络层，并且按需在网络层策略标签中打上一个flag让网络层的P4/NPL 识别后产生postcard telemetry。
Postcard telemetry需要大量的流表更新，这里需要采用基于ARM Neoverse 1架构的处理器，例如Thunder X3来实现，为什么不是X86，主要是内存访问带宽的问题，大量的流表需要大量的内存操作，核多和N1的L3分布式Cache设计对优化此类应用非常有帮助，当然要自己弄基于FPGA的也行。
1.4.4 AIOps
其实主要是两块，一块是基于时间序列流的周期性检测和异常检测，这一块内容我前段时间写过一文，自己去看就好了：《AIOps系列（1）：时间序列分析的方法》
另一块是基于决策树模型的，主要是运维中有大量的场景，根据数据分析可能在告警触发边界故障点判断等问题上人工写if then else会比较麻烦，所以我当年直接就在流计算引擎中添加了一个推理算子，这个算子直接可以加载XGboost/LightGBM的模型产生推理结果，然后把推理结果继续放入流计算引擎中往下游传递即可。
本节总结：
切记：控制器仅需要部分的结果即可，在设备端进行流计算数据聚合非常有必要，当你运行一个Pod可能只有几百台交换机的时候不觉得这样做有什么必要，但是当你采用host overlay可能telemetry上报点是几万个的时候你就懂我这话的意思了，因为我做过~
2. 计算
2.1
业务概述
主要有几个趋势，视频类低延迟业务激增，基于AI等业务将以数据为中心。抽像来看传统的办公业务和逻辑一般是标量计算（Scalar），然后逐渐的伴随一些视频类业务，矢量（Vector）计算需求也在增加，但是X86寄存器结构导致SIMD效率可能还是比不过一些DomainSpecific芯片，而AI则是大量的矩阵（Matrix）计算和更高维度的Spatial计算， 异构是必然出现的。
2.2
计算异构
计算异构主要就是GPU或者FPGA来进行Vector/Matrix/Spatial，各个大厂都有布局，但是也有出现问题的地方， 下一代架构一定要网络和计算异构要紧耦合来实现随路计算，具体怎么做我在某司已经有专利了，保密不说话~
例如阿里云的含光800在ISSC2020的论文和另一篇HPCA2020：EFLOPS：Algorithm and System Co-design for a High Performance Distributed Training Platform的论文可以合并在一起看，也就是说在分布式计算的阶段，无论是推理还是训练，通信bypass CPU是必须的，两种做法，一种是网卡上的PCIE-Switch和GPU互联，Mellanox CX6就是这样，甚至它家和N家合体后直接发布这样的网卡了，同样Xilinx的Alveo也是这样的思路，阿里含光下一代估计也应该这么干，腾讯云最近也在做推理加速卡，也可以考虑。
2.3
随路计算
这是一个很有趣的话题，开放的议题，特别是如果在MEC到DC之间的整个长链条上实现网络随路的计算和实时响应，不过实在是抱歉，有些话我憋着~ 憋着~ 咩~打我啊~
2.4
Sidecar offload
service-mesh后大量的业务都需要NFV做sidecar，并且为了安全性考虑大量的sidecar之间的连接升级到了TLS，加解密的offload十分重要，这也是pensando的网卡的一个非常重要的使用场景，利用ARM核来实现TCP状态机和逻辑，而报文的封装加解密全部放到网卡上做，网卡和CPU直接通过PCIe DMA明文的payload， 随着HTTP/3的流行，网卡实现QUIC的offload也指日可待。
3. 存储
分布式存储演进和ROCE的部署已经在上一代数据中心架构中被广泛接收，而下一代数据中心架构的主要变数来自于Persistent Memory在新一代数据中心的使用，特别是大型AI训练Fabric：
Persistent Memory的编程结构和如何使用一些总线实现可扩展的内存是一件非常有趣的事情，Fungible DPU看上去有类似的功能，但是不知道他们是如何hack Intel的QPI总线的？不过AMD架构就容易一些了，基于CCIX架构可以将一些内存映射过去。而基于存储的SmartNIC也是很多厂商很关注的， 反正主要就是压缩/去重/AES-XTS offload 这些功能，看着自己需要的找vendor买就好了
4. 电力
哈哈，突然冒出些奇怪的东西来了，对滴这也是我工作的一块，农民工的视角就是凡是能省的钱一定要省！两年前我在某实验室的配电箱上装了一个智能电表
背后主要就是在电流互感器上接几根线出来，然后RS485的串口弄到一个ARM的盒子上采集分析数据就好，整个解决方案成本就1000多块钱，如下图所示，其实它也是借助了我为网络设备做的那个嵌入式流计算引擎，然后用Golang直接生成Web后端提供GraphQL和http，然后UI渲染全部是React做client render
其实很多互联网公司构建数据中心的时候都在谈高压直流或者腾讯采用的一路市电的方式，但是对于供电质量，功率因数补偿分析，谐波分析基本上没做，为了降低PUE我们观测到市电的谐波和电压实际上是存在周期性波动的：
谐波的分析结果如下：
其实本质上就是对电压进行FFT，然后谐波补偿主要是通过逆变器根据FFT的结果进行补偿，例如我们观测到的结果是大量的5次/7次谐波，很多时候其实是UPS产生的谐波电流，而滤波和补偿效率则也需要分布式的方式进行处理，对于进一步降低PUE还是很有帮助的。
5. 云原生的公司
其实很多公司都成为了云原生的架构了，也就是说整个公司并没有自己的数据中心，然后基本上都是租借公有云的方式，公有云之间如何进行流量调度呢，其实主要就是依赖于service-mesh架构和QUIC-SR实施：《QUIC-SR：关于NewIP的答案》
基于IPv4你怎么跑SR？UDP里面跑呀，反正QUIC的PMTU把自己弄到了1200B左右，给我留了很大的空间插一个QUIC-SR的头，今天正好把dataplane的代码写完~ 过几天就可以测了，例如抖音头条钉钉云信这些互联网厂商自己照着抄作业吧....
