合肥先进光源束测系统后台基础架构初步设计报告

前言

大科学装置的后台基础架构的任务一般都是交给控制系统的，并且控制系统在很多科学装置上都是抓总的要把各个子系统的设备都要控制起来，和各个子系统的接口以及需要控制和调试设备的工作量极其的繁重。

不过合肥光源自从永良使用服务器虚拟化开始搭建起后台基础架构以来，束测的这部分工作一直是自己完成，束测系统的特点使得自己做这部分工作给双方带来了极大的便利：

• 束测是光源的眼镜，子系统众多，并且很多专用的处理器以及高速、产生海量数据的采集设备，这些设备和系统本身的调试和搭建的任务就极其的繁重，专门束测的人员来做，是能为控制系统分担很大的工作量的；
• 这些设备和系统工程期间的调试和建设，自己搭建这些后台做这些调试和建设的工作，带来了极大的方便，不需等靠控制系统准备好这些条件，并且两个系统的接口也变得简单；
• 除了自己搭建服务器后台虚拟化跑起这些设备的IOC，很多束测设备的快速获取会生出海量的数据，这些数据没必要大量储存在控制系统为高可靠目标搭建起的宝贵储存资源，但是束测系统自己为了研究的需要，很多时候是需要储存起来做进一步分析的，使用高性价比方案搭建的数据库为这些研究和储存节省很多的资金并带来很多的便利；
• 。。。。。。

束测自己搭建后台带来的好处不一一叙述了，永良离开合肥光源后，这部分任务就交给我来运维，从开始的战战兢兢的提心吊胆，慢慢的逐渐上手，到目前经过几年的积累还算是得心应手。对于新光源的建设，这部分工作我是胸有成竹的，但是这部分的设计报告我却是能躲就躲的态度，一直想着事情可以做，但是费力写自己不擅长的这类报告就不想写。

决定必须要有这样的一个报告后，刘老师第一时间就发给我他们的设计报告给我参考，因为整个控制系统抓总需要建设的任务繁多又复杂，只是束测后台的话，没那么多的内容，就没有参考他们的结构，还是从自己这些年运维的经验以及碰到的问题开始。

所有的设备都要联网，系统要运行好，网络是必须要通畅的，运维实践中，因为网络阻塞引起的运行问题碰到过很多次，就从网络开始叙述。

网络篇

STP

网络的稳定运行，从STP(Spanning Tree Protocol)生成树协议开始。

生成树协议最主要的应用是为了避免局域网中的单点故障、网络回环，解决成环以太网网络的"广播风暴"问题。

现在的交换机一般都很智能，多个交换机组成的二层网络，这个STP协议会自动屏蔽掉形成环路的连接，并且已经生成的树状结构有链路故障时，又能启用被屏蔽掉的链路，重新生成能连接起来的树状结构。

交换机之间高速链路连接组成的网络这样的一个树状结构，每个枝干带宽的粗壮，接到交换机上的各种设备这样的叶子之间的网络通讯就更流畅，如果有一处链路的带宽不够，这个链路两端的两个子树之间的大数据量的通讯就畅通不起来。

合肥光源束测网络现状

束测和控制的硬件接口，其中就会有一项，每个束测设备间都会通一个控制网接口，这个接口的带宽，现在合肥光源是千兆，束测所有的设备都是这样直接接入控制网，对于每个设备间之间通讯的数据，那必是会跨多个交换机，是要占用控制网的带宽的。

机器规模小，设备少时，这个带宽的占用，不会产生大问题。不过合肥光源运行实践中，因为一个摄像头高帧率的在OPI端监控，引起控制子网的阻塞曾经发生过，后来发现这个问题后，就尽量避免这样的高帧率监控。

束测设备集中的几个设备间之间的海量数据通讯，如果只通过和控制系统这个网络接口通讯的话，为了避免引起控制网的拥塞，就掣肘了这些设备间之间的大数据量的通讯和研究。因此一般建设时，会在这些设备间之间布上光纤。

合肥光源重大维修改造时，束测设备三个集中处：直线束测耳房、环中央束测本地站、环大厅束测本地站。当时建设时直线耳房到环中央束测本地站之间拉了一根光纤，环大厅束测站和另外两处之间没有拉光纤，通过控制网络接口连入控制网。后来在搭建逐束团3D系统时，因为示波器需要放在环大厅束测站，耳房的服务器从示波器获取波形数据只能通过控制网的链路，会造成本来偶尔就会拥塞的网络更加的拥塞，后来就在环大厅放了台和示波器接到同一个交换机的服务器搭建起系统。

直线束测耳房开始集中放置束测后台服务器，由于最开始我们缺乏服务器工作环境的要求经验，使得放置的机柜后面没法进人接线，并把服务器机柜放在束测设备间的一角，后来运行费新买服务器上架时都是先把后面的线接好后推入机柜中，这样的不方便在上架的过程中导致过调试好的raid阵列故障以及碰断光纤接口的问题，后来就不敢在那上架新服务器。后来在环大厅最开始为逐束团3D系统放置的服务器的基础上，继续放上新服务器，并逐渐的在那个场地重新搭建起4机集群束测后台环境。现在集群上的虚拟机上的IOC和所有的束测设备通讯并对外提供束测信息的服务，集群以及其ceph文件系统在没有UPS保护下经历过停电的考验，这几年的运行实践一直很稳定。

在2024年的寒假，刚哥为预研期间同步光线站购买的一套UPS那边不用了，正好利用停机挪用到环大厅束测服务器集群上，这样更有利于后期的稳定运行，后面进一步的计划是利用假期再从环中心束测站拉根光纤到环大厅束测站，这样束测的三处设备集中处之间就能通过高速光纤连接，之间的通讯时，就避免了占用控制网的带宽。

新光源束测网络规划

新光源规模更大了，从现在的3个束测设备集中处，增加到16、7个设备间（直线3个、环中心10个、反馈、几处光学间）。

现在和控制网的接口，我们申请的要求是光纤，万兆光纤会比现在的千兆好很多，但是对于更大的规模，每个设备间都过这个接口，最后的瓶颈还可能是这个接口。

幸运的是我们这个时代网络技术的发展，现在交换机之间通过40G甚至100G的高速链路连接，已经是很平常并不高代价的事，如果控制给我们的网络接口从这样的万兆应用层升级到接入层，同样的光纤只要两边使用40G或100G的光模块接入，我们的每个设备间瞬间就每个叶片集中接入的交换机上行带宽升级到40G甚至100G，就不存在束测网络规划的问题，也不需要有这部分内容。

不过即使不这样从应用层升级到接入层，我们也不需要很多的代价能够有这部分的网络规划。

就像现在的合肥光源一样，设备间之间拉上光纤，设备间之间的通讯就可以不从控制网接口走，特别是摄像头图像和示波器波形，以及很多高速采集设备的高速数据流，这些没有经过分析处理的海量数据流，是没有必要占用控制网的带宽的。

调研的去年就有的上行40G的交换机，电口和光口的就有华为和华三的型号可供选择，并且通用的这样的接口，不同品牌的设备间互通性实验也都顺利完成。

关于束测设备间之间的高速光纤怎么布，下面的示意图可以很清晰的显示：

为了更清晰，我把环内的设备间画在环外分布显示，相邻的设备间之间只要这样通过一根或两根光纤简单互联成一个环路，所有设备间之间的通讯就可以不占用控制网的带宽，这样的环路又可交换机STP自动屏蔽掉冗余的一根链路生成不会产生回环网络风暴的树状网络，并且在有一根链路故障时恢复屏蔽的链路使得网络不间断的稳定运行。

直线的三个设备间之间通过两根光纤扩展这个环路，也是为了任何两根光纤接入的交换机故障，不影响其他交换机和链路的运行。

束测后台集群可放置在有4个光纤接头的两个束测间，并且服务器的网络接口做成bond接入两个交换机，即使其中一个交换机故障，也不影响集群后台的运行。

不过这样不花额外代价的连接和布置，无法克服这两个设备间停电时影响束测后台的问题，不过使用UPS可以克服这类故障，不过新光源束测没有这部分预算，以后运行费想办法或利用闲置的UPS。

束测设备本身就需要接入交换机，这样虽名义上的束测网络规划，实际上是不需要额外的设备的，只是设备间光纤连接了起来。这样的环形网络生成树，在任何一个设备间接入控制网，和通常的束测设备间接入网络没什么区别，但是额外的好处就是设备间之间的通讯流量，不会占用控制网的带宽。

这样的40G~100G的交换机主干连接网络树覆盖的设备间之间的通讯，不仅可以不占控制网带宽的流通各种设备的海量数据流，而且ceph文件系统、iSCSI、NAS、NFS等等的数据流都不会占用控制网的带宽，达到40G以上的带宽，对这些带宽要求极大的数据流通畅运行也都足够的胜任。这样的联通为以后的运维以及新设备的扩展会带来极大的便利，不需要象现在没有拉光纤时一样，为了避免影响控制网运行，增加设备只能就近的和其通讯的设备连接到同一个交换机，任何一点都可以适当根据设备间空间的情况放置新设备，而不是集中在某一个设备间。

后台集群篇

在这篇文章“合肥先进光源束测后台的初步设计”中做了这部分规划，里面的这张图引过来：

自我感觉的软件安全性排序：

不自主闭源<开源<自主开闭源

对于基础架构那就是：

vmware<proxmox<zstack

这三个架构都使用过，最开始知道zstack还是在2020年，之后其单机版用的得心应手，并且那时候安装的服务器现在还在运行。

高能所在美国制裁下，北京光源用起开源免费的proxmox，在叶强老师的推荐下，我从两年前知道这个架构，并用此架构搭建起现光源的束测后台集群，至今已稳定运行快两年。

去年的运行费买了一台服务器使得后台集群从3节点增加到4节点，现在即使有一台服务器故障，3机集群也能继续稳定运行，并不再担心3节点如果有一台故障的话，会造成脑裂集群无法稳定运行的问题。

并且利用去年运行费买服务器时配的NAS解决了在线IOC镜像备份服务器的存储问题，并且proxmox集群的自动备份作业，以及HA可靠性运行转移的作业都在后台验证过并一直在线工作。

有了这个备份服务器(proxmox backup server)，并且后台每个月自动备份的作业稳定运行，集群运维就更让人安心了。在后面新光源建设中，束测没有这个后台基础架构license的经费下，将选用proxmox搭建起后台服务，并且已有的运行经验，大版本的升级等都已经在现集群上成功做过尝试，使得这部分工作没有技术上的障碍。

直线服务器的预算是3台服务器，这是搭建起集群的最小配置，后继的增加节点会用以后的运行费慢慢增加，就更不用担心只剩两台正常工作的服务器会产生脑裂的问题。这个最小规模的集群，经费有限，将采用超融合架构，就是每台服务器配好硬盘，计算、储存都在服务器建起的集群上，没有经费、也不需要经费额外的购买SAN等专用的高端储存设备。

集群储存也是基于proxmox系统上本身集成的ceph功能，多副本个数的设置，即使大规模的集群多个服务器故障，都不会影响整个集群的运行（当然，对于3机小规模集群，宕掉一个节点都会脑裂的影响运行的情况不覆盖），这个优势应该是比vmware集群只能保证一个节点故障的继续运行要有优势多了。

并且在线自动备份作业，尝试过1T容量的超大镜像备份，并成功验证和生成，这些都更有助于系统的稳定让人安心的运行。

直线除了三机的基础集群服务器的预算，没有备份储存的预算，不过这部分经费到时候看情况，从别的设备省出的牙缝里挤点经费能买设备即可，几年前有过5万不到的价格，配过一台150T容量NAS的经历，我想IT设备的进步，很少的钱配出很大容量的储存不在话下。

除了直线的三台服务器的预算，储存环还有三台服务器，到时候看情况加进这个集群中，或者是另外搭建一套三机集群，这样的双集群的同时在线工作，为系统的稳定运行带来更好的保障。

新光源束测的各子系统清单

直线加速器：

合计：40个

储存环

合计：25个左右IOC，还有OPI虚拟机以及一些运行采集程序的虚拟机。

这些子系统，除了一些专用的处理器，比如BPM处理器、快反馈、逐束团反馈等，自带IOC之外，其他所有能联网的设备，数据获取的IOC都需要运行在束测后台集群上；上面提到的特殊处理器，和控制系统的接口也需要PV命名规则变更的软IOC运行；其他的设备，比如摄像头，每个摄像头需要两个IOC，一个和摄像头连接获取图像数据的IOC，另一个专门用作分析图像数据给出结果的IOC，更多具体的设备不一而足。

各个子系统的IOC，工程建设中，各子系统各自调试好之后，镜像上传到集群中，对于比较通用的设备的镜像，比如示波器、摄像头、电机控制等等，这些我和雷雷以及在留国的帮助下都已搭建起来，在测试中发现的问题也在和厂家的技术人员共同在改进，相信这一两年的建设中最后能很好的上线。

杂篇

除了这个集群运行束测后台IOC，为了束测系统数据更好的利用和研究以及工作的方便，后面列举一些额外的服务：

• NFS，服务运行在集群虚拟机上，利用ceph空间或者另外NAS上开辟iSCSI盘；
• PBS，运行在工控机的虚拟机上，利用NAS上开辟iSCSI盘做储存（备份集群的目的，系统和储存不能跑在集群上）；
• AA数据库，服务运行在集群虚拟机上，利用ceph空间或者另外NAS上开辟iSCSI盘，这个服务为了束测自己研究的需要，也欢迎愿意利用和分析数据的感兴趣者访问；
• NTP、DHCP等服务，束测交换机数量的预算，差不多每个束测间2台的配置，这个也就基本的设备接入网的需求，实际上如果有足够的交换机，上面这样的环是可以另外组成一个和控制网隔离的二层网络的，这样很多的设备就不需要占用大量的控制子网里的ip资源，特别是bpm处理器这一项，就超过256个数量，这样的单独成网，在集群上的虚拟机分配这个网和控制网的虚拟网卡，就可以为控制网提供束测数据的服务，这样的单独成网，在这个网内，时间同步和DHCP服务就需要搭建起来；
• VLAN，交换机可以通过这个技术划分为几个虚拟交换机，就像很宽的高速路上分隔开多条道路一样，不过这个40G宽的网络只束测的设备接入，不象控制网需接入的设备庞多并很难管理，交换机连接起来就作为一个简单的二层网使用，是最简单的方式，也不需要为ceph、管理、应用那样单独划分出VLAN；
• 其他可能的服务到时候根据需要再逐步建起来

后记

这部分工作在光源的设计报告中没有提到，但是现在建设中需要为购买这些设备花钱时，怎么建设这部分工作，让领导很不放心，自己随意写博客文章很开心，最后还是赶鸭子上架，不得不写这个设计报告，这样随心写出的东西一定漏洞百出，写成这个样子，还请路过的方家能一笑了之。千万别因为我的水平有限，而质疑我所热爱的实验室众多大牛们的水平。

不过这只是昨天决定必须写这个报告今天完成的初稿，相信在各位老师的指导下，这个报告后面会更完善的还能可看。

2024-04-13