CentOS上端口转发方案之HAProxy

端口转发的实际使用场景很多,比如说load balance,比如说流量中转

所谓的端口转发,是发生在网络协议的第四层,TCP/UDP层,也就是IP层面

所以一般来说有这么几个解决方案:

iptables: 系统原生底层的解决方案,配置比较麻烦。但是如果使用CSF来配置iptables,这是非常简单的

HAproxy: 性能比iptables高,配置简单,但是只支持TCP,不支持UDP. 但是如果不玩游戏的话,TCP的端口转发就足够了。

因此这篇文章主要讲述如何使用HAProxy来做流量中转.

底层操作系统是CentOS 7,系统的repo自带haproxy,版本比较老(1.5.18)但是足够用了

安装haproxy:

yum install haproxy

systemctl enable hapoxy

配置haproxy:

cd /etc/haproxy
mv haproxy.cfg haproxy.cfg.bak
vi haproxy.cfg

然后输入下面的配置:

global
ulimit-n 51200
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
user haproxy
group haproxy
daemon

defaults
log global
mode tcp
option dontlognull
timeout connect 5000
timeout client 50000
timeout server 50000
maxconn 20480

frontend v2
bind *:443
default_backend v2

backend v2
server v1 A.A.A.A maxconn 20480

frontend rdp
bind *:3389
default_backend rdp

backend rdp
server r1 B.B.B.B maxconn 20480

上图表示把把这台服务器的443端口的流量转到A.A.A.A的443端口上,把这台服务器的3389端口流量转到B.B.B.B的443端口上

配置好以后,下面只需要开启haproxy服务就好了

systemctl start haproxy

Cloudflare 推荐节点IP

Cloudflare 百度云合作节点IP:

162.159.208.4-162.159.208.103

162.159.209.4-162.159.209.103

162.159.210.4-162.159.210.103

162.159.211.4-162.159.211.103

各线路推荐列表:

电信:推荐走圣何塞,例:104.16.160.* 或者上面的百度云合作 ip。
移动:推荐走移动香港,例:172.64.32.* 141.101.115.* 或者 104.23.240.0-104.23.243.254。
联通:没发布什么好线路,可走圣何塞。例:104.16.160.* 或者 104.23.240.0-104.23.243.254。也可以试一下走亚特兰大 108.162.236.* 。

Smokeping 常用操作

在centos上安装了smokeping 以后,我们可能会经常遇到各种问题

  1. 对target进行修改,修改完以后,我们需要重启smokeping service ,一般情况下是不需要重启httpd,因为smokeping 的主程序会查看config 的timestamp,如果有变化就会重新读取config 配置文件,但是如果你把target 通过include 的方式包含在config当中,那么即使你修改了target文件,但是config 文件的timestamp 仍然不变。经过测试,解决办法有两个: 要么稍微修改一下config 文件,添加或者删除一些无关紧要的文字,要不然就在重启完smokeping以后再重启一下httpd服务
  2. 还有一个经常见的问题就是slave 的图没有数据,这个一般是权限的问题。因为slave 端的数据,是slave 端通过http call,写入master 端的,而master 端完成此项任务的是httpd,因此httpd 要对 data 文件夹下面的target 的文件夹要有写入权限。实现这个目标,可以有多种实现的办法,一种办法是利用getfacl 和 setfacl 来设置apache 对这些目录单独的权限,另外一种办法是把这些文件的group 设置为apache,并且给apache 写入的权限 chmod g+w *
  3. 查看rrd文件里面的是否用数据,例如可以用rrdtool fetch Akamai1~10.10.16.111.rrd AVERAGE 命令查看master端slave提交的rrd文件

现代Linux系统的swap空间

以前的资料上的东西,都是以RAM很小为前提,但是现在的server,RAM动不动就是32G,64G什么的,内存要大不少

下面的内容是从fedora 28的安装文档上看到的。Fedora 28安装指南定义了有关swap 空间分配的思路。需要注意的是,fedora的分配思路可能与其他Linux发行版略有不同,但是和REHL,Centos是一摸一样的,这些建议自从Fedora19以来就没有变过

Fedora的建议:

RAM<=2GB, SWAP = 2X RAM

2GB < RAM < 8GB, SWAP = RAM

8GB < RAM < 64GB, 4G<=SWAP<=0.5XRAM

RAM> 64GB, SWAP>=4GB

但是根据多年专业的运维人员的经验来说,

RAM <= 2GB, SWAP = 2X RAM

2GB < RAM < 8GB, SWAP = RAM

SWAP > 8GB, SWAP = 8GB

MSDN Win10 Ltsc 2019姗姗来迟

等了好长时间的MSDN版本的EN Win10 Ltsc 2019终于来了,可是通过比较完sha-1以后,发现msdn和vlsc的文件是一模一样的,没有任何更改。。。看来阿三还是比较懒的。。。

 

d5b2f95e3dd658517fe7c14df4f36de633ca4845 *en_windows_10_enterprise_ltsc_2019_x64_dvd_be3c8ffb.iso

c0b4704e1336281c98a91438c7df0f14b8f41e46 *cn_windows_10_enterprise_ltsc_2019_x64_dvd_d17070a8.iso

C0B4704E1336281C98A91438C7DF0F14B8F41E46 *SW_DVD5_WIN_ENT_LTSC_2019_64-bit_Chinese_Simplified_MLF_X21-96413.ISO

D5B2F95E3DD658517FE7C14DF4F36DE633CA4845 *SW_DVD5_WIN_ENT_LTSC_2019_64-bit_English_MLF_X21-96425.ISO

由此可见,VLSC和MSDN在1809版本上继续保持一致

Nginx 反代 upstream sent too big header

今天突然几个站点打不开了,出现了502 错误,赶紧打开nginx error log, 发现了这个错误:

upstream sent too big header while reading response header from upstream, client: XX.XX.XX.XX

这个错误很明显,是nginx proxy buffer 不够了,解决的办法很简单,直接在http block 里面添加如下命令即可:

proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;

添加完毕重启即可解决上述问题.

同时这也说明了在监控中,不仅要检查nginx,mysql 的程序运行情况,也要检查http status, 只有200的情况是可以接受的