弱鸡鸡的机房

作者 xrspook

2024年11月27日 09:35

当年今日

某次单位进行电力监控的升级改造，要在半夜的时候断电进行操作。理论上大半夜没有作业，大家都在睡觉，这样的操作影响应该是最低的，但关键是第二天，整个单位的业务瘫痪了。因为浪潮的智能化系统挂掉了。我一整天都不知道是怎么回事，反正就好像单位那个刷车车船排队的网页无论如何打不开，理论上正常的话，单位早上8、9点就会有重车校验的图片以及说明，但是那一天一整天都没有，从调度信息来看，理论上那天是要装船的，但是车船记录都没有。我以为是微信在平板上登录了，但实际上没有，所以我退出了手机的微信。我还清楚记得那天是周日，因为那天傍晚吃过晚饭我回单位，但结果是当我准备从家里离开的时候，打开手机打开微信才发现单位同事找我要前几天的库存数据。一个管网络的人找我要库存数据，你们的数据就没有备份？后来我才知道，因为半夜进行电力改造，但是单位的服务器没有提前手动关掉，所以对服务器来说，等于是突然断电，突然断电导致数据丢失，并且出现莫名其妙的错误。

机房的升级改造之前，浪潮的数据库会出现错误，绝大多数情况都是缓存数据满了，于是新的数据没法写入，这时，你能看到非常明确的提示，接下来，网管同志就知道该如何做了，另外一个情况就是整个系统越用越慢，这种情况谁也说不清到底是怎么回事，但重启一下就好了。

电力监控改造是有计划的，但是管机房的人却少了这个心眼手动把数据库关掉。在机房改造之前，我不知道那里有多少设备、有多少UPS，直到周二我去询问情况的时候才被告知，现在的机房服务器的设备多了很多，UPS也大了很多，但现在的UPS蓄电池只能支撑两个小时。两个小时能做什么？即便机房24小时都有人值守，但可能打个瞌睡都不止两个小时了。

这一次也是一个周日，我们遇到了也说不准到底是什么原因的突然停电，而且是半夜停电，可想而知，服务器们又是突然就挂掉，因为那些UPS甚至无法支撑到天亮就全部耗尽了。停电的那一天，我第一走进机房，看到那些UPS蓄电池的放置场所我的第一个反应是为什么就只放半人高呢，又是周二，我才被告知，那个地板的承受能力也就只能在那个面积上面堆这么多蓄电池了。我感觉那堆蓄电池的占地大概几个平方。虽然堆起来密度已经不小了，但是它们却仅仅能支撑十几米一堵墙那么多服务器两个小时的电量，可能除了那些服务器以外，还包括空调。在改造之前，据说以前的UPS只能支撑20分钟。20分钟，我即便收到信息马上赶过来都赶不上，但2个小时，如果发生在半夜，同样无解。为什么要搞UPS呢？就是为了停电的时候还有个后路，但2个小时的设计等于没有路。既然升级机房的时候你要选择华为分布式的服务器，华为怎么可能不告诉你我至少得有多少UPS蓄电池支持才能持续运行多长时间。
UPS不能保证你一直没有问题，但起码得支撑到管理员到达现场处理或者远程处理。让我觉得非常不可理解的是为什么他们既然知道UPS在启动了、UPS的电量不足了，但是服务器却没有一个逐步保存关闭的程序。突然断电服务器肯定受损，而且那种受损是你无法预知到底损在了哪里。知道没有电，就进行逐步自动关闭，等于是模仿人工应急的操作，能把损害降到最低，为什么就没有这个自动自我关闭的设定呢？是华为自己没有这个设定，还是浪潮根本就没往这方面想？为什么其它的机房不会有这种问题，人家的UPS蓄电池到底用多久？别人的电路到底有多少条？为什么别人能保证当这一条电路不行的时候能切换到另外一条？哪怕都不行了以后，依然能保证服务器里面的东西安全。

周日的停电，除了让我们的生活非常痛苦以外，现在的后遗症很明显，就是浪潮的应用跟数据库出岔子了。整套智能化系统基本属于瘫痪的状态。突然停电算是意外的天灾，但是一次又一次在同一个问题上摔跤，依然没有一个确切的解决方案，这就是人祸。

华为USG防火墙配置NAT映射回流解决内网通过公网映射访问内部服务器

老谢博客

作者老谢

2020年11月12日 12:08

　　标题有点绕，问题就是在公网出接口上配置了内网某台服务器的端口映射，内网的普通用户通过内网地址访问正常，但无法通过公网IP进行正常访问，拓扑图如下：

　　上图以出接口地址100.100.100.100:80映射为192.168.1.11:80为例，实际问题为192.168.1.100与192.168.1.110无法通过100.100.100.100:80进行访问，但通过互联网访问映射端口正常。

问题原因分析

　　假设以192.168.1.100通过公网访问192.168.1.11:80的话，这里假设访问的源端口是10000，目标端口是80，主机发起web请求，那么访问目标就是100.100.100.100:80即数据包分析如下：

　　192.168.1.100:10000—>100.100.100.100:80

　　数据包最终会被路由到防火墙上，防火墙检查访问的目的地址，匹配到它的端口映射策略，将目标地址改为对192.168.1.11的访问，建立起一个针对目标ip地址转换的NAT会话表：

　　192.168.1.100:10000—>192.168.1.11:80

　　然后数据包到会被转发到192.168.1.11服务器上并会响应192.168.1.100主机的请求，将上述访问的源目ip地址及端口进行倒转，并将数据包交给它的网关处理，拓扑中即为USG防火墙：

　　192.168.1.11:80—>192.168.1.100:10000

　　网关发现目标ip地址是192.168.1.100，是在路由表中的内网直连地址，就会将数据包直接路由到主机上，主机接收到数据包，检查数据包的源ip和端口是192.168.1.11:80，发现其本身并没有这样一个http会话与之相匹配，就是说主机并没有主动发起对192.168.1.11:80的访问，实际发起的是对100.100.100.100:80的访问，那么主机就会丢弃这个数据包，导致内网用户通过域名或者公网ip地址访问自己的内网服务器不通的现象。

　　192.168.1.11:80—>192.168.1.100:10000

　　发生上述问题的原因，就是因为网关发现响应数据包的目的ip地址是内网一个可直接路由的地址，就会直接在内网进行路由转发。然而这并不是一个BUG，任何设备只要做了端口映射，都绕不开这个问题，因为TCP/IP协议栈就是这样工作的，有的设备在你做端口映射的时候，偷偷地把端口回流的问题也给你解决了。然而你也不要以为它们帮你做了端口回流，你就认为那些设备是好设备，感觉好高端，那你错了，我很少见企业级设备偷偷地帮你解决这个问题的(不是说没有，一般是应用层网络设备有这个)，都是需要你主动去处理解决，这也体现了它们设备高度可定制性及专业性。

问题解决方案

　　实际解决这个问题也很简单，即在192.168.1.100:10000访问192.168.1.11:80的时候，不走内网路由，再做一次回流的NAT映射即可。

回流NAT映射验证

参考:

https://blog.51cto.com/11555417/2288036

http://www.360doc.com/content/18/0419/01/11935121_746788625.shtml

https://blog.csdn.net/weixin_30376509/article/details/97982837?utm_medium=distribute.pc_aggpage_search_result.none-task-blog-2~all~first_rank_v2~rank_v28-1-97982837.nonecase&utm_term=%E9%98%B2%E7%81%AB%E5%A2%99%E5%81%9A%E5%9B%9E%E6%B5%81%E9%85%8D%E7%BD%AE&spm=1000.2123.3001.4430