我工作中踩过的坑--服务器管理篇

Posted USTC-lup

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了我工作中踩过的坑--服务器管理篇相关的知识,希望对你有一定的参考价值。

也许有人会问,束测搞好束测的事就好了,干嘛还自己搞服务器后台啥的?貌似以前有个文解释了的,竟然一时找不到,就再啰嗦一下。

束测有众多子系统,各种采集,摄像头、示波器、万用表、电机控制、各种专用处理器。。。以前一般都是众多的工控机直接去连设备跑起程序,不仅维护量大,而且程序搞起来复杂,扩展、移植、调试都很麻烦。就比如摄像头,在线的少则10几个,以后会几十个甚至更多,虽然现在也都GIGE可联网,如果采集程序来控制获取,加一个摄像头都是非常麻烦的事。

后来我们才开始使用服务器虚拟化,还是永良从2013年左右重大维修改造时开始的,那时候组里我还不是很能干,永良、周周那时候虽然是博士后,但是干活最得力的,孙老师领导下带着我们和一帮给力的师弟们就把重大维修改造里的束测系统搞定了,刚哥那时候还在控制组,两边都有很多事,雷雷那时候还在上学。那时候我做的还都是延续以前二期时建的以及后来运维的一些系统,重大维修改造时加了一些,不过都不是那种费脑筋的难啃的硬骨头,难啃的都交给永良和周周在干,比如直线BPM和环COD测量系统和逐束团反馈之类的。那时候虽然上头有这样的大馅饼一样的任务落在单位头上,实际上我是很抵触的情绪,觉得同学弄的新lattice亮度就能提高好几倍,干嘛还要瞎折腾,除了房子,其他的都推倒了再重新来一遍。

永良那时候带着几个师弟搞直线和环的BPM系统,虽然买的libera的,但是熟悉并跑起来工作量还是巨大,直线BPM以及环上的组合BPM,每个都要标定、mapping图算系数,线缆测量、接线等都是几百根,都是他们自己测好又接好,除此之外还有逐束团流强、工作点,除此之外他就在捣鼓服务器,工程建设时,现场网络、机柜都还没有布上,这些系统的IOC、OPI等等都是在实验室桌面离线调试好,那时候我还不明所以然,还在那一台台工控机裸搞,后来用上永良开的虚拟机,感觉就离不开回不去了,克隆一个虚拟机,就像一下子新生出一台调试好的工控机,真是太爽利了!得益于现在的设备都有网口,在服务器的虚拟机上就可以联网控制采集,代替了很多的工控机,但是工控机有时候还是必须的,特别是离线调试等环节少不了,但基本上不怎么让他们上线了。

现在2、3台服务器就可以跑起束测各子系统后台的所有服务,现在还都是各服务器互不关联的单独管理,以后新光源需要的服务器规模估计要翻几倍,如果还这么单独管理,光管理的工作量也要翻几倍,而且互不关联也无法实现高可用、热迁移、热备之类的系统更可靠运行的功能,以后一定是要把资源池化统一管理才行。

说到这,一想到束测做的这些为了系统更好运行,也没有向领导邀功,工作却不被领导认可,觉得我们不该自己做,应该让专门系统做心里就窝火,我们倒是想有人为我们做这些事,可是那种工程建设时期谁会提前把这些后台能为我们架设好了等着我们来用?以后新光源又会面临着这样的情况,而且规模更会大一个量级,我们基本还是会在现场网络、机柜条件都还不具备的时候,就要离线把环境都在服务器上架设好,请问谁会为我们提前把服务器搭好并开好我们需要的虚拟机?如果让我们一台台工控机离线调试,最后还是要把环境转移到云主机环境下,为什么觉得我们费这二道事,不仅又等又靠还翻倍的工作量就是应该的?其他组可以为了很多台服务器方便管理,节省工作量而可以买vmware之类的管理软件,为什么我们就不可以有这样的预算?

提到这个就一肚子气,不说了,继续说主题,永良2018年离开合肥后我就接手束测后台的服务器管理,开始时心有惴惴,现在也慢慢上手并感觉得心应手,并能跟随着新技术,把容器等也都用了起来。不过管理的过程中也踩过一些坑,有些经验也总结下:

1、放服务器的机柜周边环境一定要规划好

我们直线耳房的束测设备间是为了把我们的在线设备能集中放起来的一个房间,当时并没有为放服务器机柜规划,使得机柜后面需要接线的地方人没法进去。

每年运行费我们会有一台服务器的预算,想着要避免年头太长的使用,不要等它崩溃的时候才折腾,就要慢慢地把在线时间太长的轮换下来。每年买的一台离线安装系统并调试,利用寒暑假放进耳房。由于人没法进到后面接线,只好把后面的线先接好再从前面推进去。

服务器机柜在房间的角落里,前面还有个UPS电池柜,您可以想象一人顺线,一人抱着服务器在角落里往里放的场景,除了当初在线的两台,后来做好备份系统的服务器利用两个假期又放了两台在架子上,前一台放的时候还好,后一台Dell放的时候可能震动地厉害,做好的raid工作不正常,做好备份的系统一直跑不起来。后来我就不敢再往那放了,上次放的时候就因为空间局促撞断了一个光纤口,很是担心放进去的再有问题或引起其他的问题,重大维修改造时就一直工作近10年的两台服务器更是不敢动。

以后如果新建的时候,服务器一定要能从容安装到位并接线才好。设备间的空间尽量规划的有些冗余,买回来就有地方放好,安装调试后尽量避免换地方。

2、网络环境提前规划好

前面提到束测系统使用服务器就被人觉得不应该了,就更不要说网络还要单独规划。

就说运行时碰到的一件事,有几次指挥说控制网响应很慢,我平时就关注了一下,发现OPI开着看同步光的程序时帧率很高,如果控制台多台电脑同时看这么高帧率的图像的话,响应就慢了。发现了原因,关掉不必要的OPI并把帧率调低就好了。当然并不是所有的慢都是同步光引起的,仅仅是原因之一而已。

控制子网里,束测的设备都直接连在这个网上,束测的摄像头图像和示波器的波形都是很长的数组,现在的规模还算小,而且读取示波器波形数据量大的服务器我都是和示波器连在同一个交换机,所以除了上面产生的拥塞还没有造成过很严重的后果。

但是以后新光源设备数量和网络布局区域都会至少一个量级的提升,服务器集中放置无法保证每个数据流量大的设备旁能有台服务器和它连一个交换机,必将会有海量的图像和波形数据在主干网里窜来窜去,如果束测系统这些产生大数据量的设备不单独建网的话必然会造成控制主干网的拥塞。

先提出这件事,现在仅仅一个摄像头就能拖慢整个控制网的响应,想想以后的设备数量更多,而且常态的观看机器状态就是更多的数据量,希望到时候束测提出这类单独布网的需求时某些领导别又觉得我们在搞幺蛾子。

暂时上面两点吧,以后想到了再接着续。

以上是关于我工作中踩过的坑--服务器管理篇的主要内容,如果未能解决你的问题,请参考以下文章

spring-data-redis 使用过程中踩过的坑

转:Flutter开发中踩过的坑

vue .js 使用中踩过的坑

Python使用boto3操作AWS S3中踩过的坑

~~在python中踩过的坑~~(不断更新)

JasperReport 使用中踩过的坑