数据中心基础架构运维:供电篇
鉴于某云说我只会低延迟,zartbot又演进成电工了,其实zaza很多年前就被家父弄去当过电力童工,10KV环网柜,GGD低压成套设备,21型动力柜都玩过,双电源投切这些其实非常简单,最早期还有机械锁定机制,即两把开关通过机械锁定柄来投切。
互联网企业通常装逼装多了,拿一些二次回路连上一些通信设备和采集一点数据就说自己。。。对,今天要说的就是AWS,有这么复杂么?
配电开关系统相对复杂,有一个专门名词叫做e-house,是用低压或中压的控制开关和继电器来控制线路切断。但是传统的开关控制系统内嵌的软件是预先设定无法改变的,很多功能设计并不适合AWS使用。为了适应AWS的需求,他们自己做了一套配电开关系统,保证在发生事故时,AWS可以最快的速度和极简的流程处理故障。 UPS系统更加复杂,因为传统的UPS控制产品功能复杂,但并不一定是AWS需要的,且UPS的铅酸电池质量重,危险性高,非常不利于数据中心的安全。AWS的做法是把铅酸电池做成多个小的电池,与机架的的冗余电池搭配使用,用自己开发的控制系统来掌控UPS,从而降低了复杂性和铅酸电池的破坏力。
其实配电开关系统也是完全模块化的,说复杂只是因为有不同的领域知识而已,继电器控制其实也很好做,通过通信设备触发PLC做就行了,当然钱多的直接买施耐德这样的东西就好,把Modbus接口接到一个带串口的IOT网关上,例如我以前给甲方爸爸做的思科IR829这些路由器。然后一个边缘计算程序也在这个IR829上处理就可以了。
开关的通断对于低压低电流可能好做,高电流的场景一般都是一些框式断路器,如下图所示,这些可能没有可编程的一些PLC逻辑,当然也难不倒我们,一般供电的叫一次回路,然后控制的叫二次回路。工程上大家都差不多一个数据面一个控制面,只要我们把控制逻辑加到二次回路上,用PLC跟继电器触发控制就行了。
顺带给大家提提一些电力行业的小趣事,以前小区的电工最喜欢的不是这些开关,而是DW15那种传统的开关,而且即便有储能功能都不会启用那种:
夏天电工们通常会靠它挣点外快,当过载断路后,一般人点I合闸是不行的,因为开关在合闸的时候需要一个储能机构通过弹射的方式加快合闸速度,您看开关上面有三个红色的东西其实就是灭弧罩,合闸慢在大电流情况下非常容易产生电弧,所以一般都有一些合闸储能机构,右上方的手柄就是用来手工储能的,所以很多外行的人点按I合不了只能花钱请专业咯,然后专业的也就是右边摇摇手柄,储能指示完成后,弹射走起~当然现在的开关都有电子储能机构了。
数据中心供电难点:遥测技术
其实这才是传统电工无法解决的,毕竟拿纸笔抄表巡检的时代早就过去了,IOT自然就有了它用武之地。几年前我在顺带运维某司研发机房的时候,就做过一个这样的项目。
本质上数据中心UPS供电切换什么的以及Google以前的飞轮储能机构什么的都不难,问题的关键是如何避免断电。本质上就是如何进行遥测,然后根据遥测数据分析供电质量,对于临界情况进行预干预。通常的故障很多,一方面是随着机架设备的负载不同,特别是一些高功耗的智能网卡、GPU等设备的使用,负载波动会较大。另一方面是本身的供电质量,三项电压不平衡等。明白了这些以后,对于遥测数据,通常我们只能采集电流电压和频率,一般来说电压直接接就好了,电流和我们做网络类似,需要“采样”,因为二次回路怎么也无法承受那么大的电流啊,所以一般常用的做法是100:1电流互感器。
我们在那个项目中选择的是国内的一家电表公司,它自带一些谐波分析的功能,实际上如果是互联网厂商可以尝试着把这些去掉,反正就是自己的一个程序写个FFT就好了。
然后我们就可以通过Modbus来读取数据构建时间序列了,下面这个就是我监控自己的机架用电情况做的。我自己Golang写的一个流处理引擎,然后提供GraphQL的接口,前端用React做渲染,有些组件库用了baidu的echarts和阿里的AntDesgin
当你收到数据后,会发现一些颠覆自己认知的事情,电压一天的波动会那么大,而且还有明显的周期性,统计无非就是线电压相电压,三项不平衡的统计,得出一些特征数据。另一方面就是电流了,如何跟workload关联这个是各个云需要考虑的问题,毕竟容量设计上刚刚好就行了,过大没必要,当然用电量也有周期性,时间序列分析用上就行了,某云不会?代码给你自己抄作业,放到一个小盒子里面就可以了。
https://github.com/zartbot/holtwinters
对于供电质量的另一个影响因素是谐波,其实本质上就是对电压进行FFT,然后谐波补偿主要是通过逆变器根据FFT的结果进行补偿,例如我们观测到的结果是大量的5次/7次谐波,很多时候其实是UPS产生的谐波电流,而滤波和补偿效率则也需要分布式的方式进行处理,对于进一步降低PUE还是很有帮助的。
《数据中心基础架构运维:供电篇》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:http://www.bookhoes.com/141.html