9月 122018
 

对于http负载均衡,往往有超时限制;对于tcp负载均衡,往往不做源地址转换(无法通过配置的方式设置为需要源地址转换),对于如下部署方式:

APP如果调用自己的话,可能服务器A发起请求,经过负载均衡后,又落到了服务器A自身,这是,由于负载均衡没有做源地址转换,所以,A的回包是发现目的地址就是自己,就不需要离开本机了,然而这种没有经过源地址转换的回包是不会被认可的,所以,这种部署方式存在较大弊端,尤其是一个服务器上部署多个应用时,应用之间的频繁调用就必然会遇到这个问题。

 

改进方案:

 

如果请求发起总是在APP上,则上述模式工作的会比较好;

但是,还有情况需要考虑,nginx做内部重定向的情况也是非常常见的,当访问a.i.phpor.net 时,很可能需要nginx直接内部转发到b.i.phpor.net ,这是,请求发起者是nginx,为了节省资源,b.i.phpor.net 也是使用的同样的负载均衡和nginx,于是,又出现了前面所讨论的问题。

 

再次改进,确保nginx不会重定向请求到负载均衡,毕竟还是要回来,索性在nginx上稍微麻烦一些,直接转发到自己,或者nginx上将所有自己能提供的服务的域名都解析到127.0.0.1

 Posted by at 下午 4:43
9月 032018
 

如图:

Local B想访问Remote B的80端口,但是由于网络限制,访问不到,但是,Local A可以访问Remote A的22端口,于是:

这样就可以在Local A上listen一个80端口,将接收到的数据包转发给Remote B的80端口

由于listen的端口在本地,所以叫做本地端口转发。

 

同样是Local A可以主动访问Remote A,但是Remote A不能ssh访问Local A,我们想让Remote B能访问Local B的80端口,如何做呢?(注意: 这里并不是上述逻辑的一个翻版)

命令:

这样就可以在Remote A上listen一个80端口,将接收到的数据转发到Local B的80端口;

由于listen的80在远端,所以叫远程端口转发

 

相关原理:

当通过端口转发创建虚线中的连接时,local A和remote A 之间并不会创建一个新的tcp连接,而是在原有tcp连接上创建了新的channel,这个可以在ssh 时 -vvvv看到相关信息

 Posted by at 下午 4:56
8月 242018
 

首先进入接口上下文:

interface g0/1

对于nat出去的话,使用nat outbound 如:

nat outbound   #所有的地址都可以通过默认的ip地址出去

nat outbound [ $acl-number ]  [ address-group $address-group-number ]   #指定的acl 通过指定的地址组中的ip地址出去

 

 

对于nat进来的话,使用nat server 如:

nat server protocol tcp global $ip $port inside $in_ip $in_port

其中 :

$ip  可以是该接口上的任意某个IP

$port 可以是任意希望暴露的端口

$in_ip  转发到内部的IP

$in_port 转发到的内部的端口

 Posted by at 下午 2:58
8月 242018
 

 

http://www.h3c.com/cn/d_201308/794662_30005_0.htm#_Toc364928020

 

 

acl 是符合一定规则的集合

流分类是符合一系列acl的集合

流行为是允许或不允许

Qos 是一组规则,说的是什么样的流分类执行什么样的流行为

最后可以在接口的上下文中应用预先定义好的Qos

 Posted by at 下午 2:48
8月 162018
 

现象:

只要访问指定的某个url,webserver就会很快死掉,直接原因是,内存消耗太多被oom

分析:

其实,这种问题多半是从数据库中一次查询太多数据所致,更直白说就是sql select查询时没有添加limit限制,基本没必要继续查,开发人员闭眼思考3秒就应该知道是哪条sql导致的了,多余的debug都是浪费时间。

但是,有些开发人员就觉得自己遇到了什么高深的bug似的,不见棺材不掉泪,不到黄河不死心,毕竟就算刻意让他写一个消耗内存的程序,都不见得能写出来,所以,下面就简述一下How to debug。

 

办法1:

通过sql-sniffer工具(或者mysqldump)抓包,看看请求都触发了哪些sql语句,一般也能看出来了。

 

办法2:

不断地jstack 该java进程,然后触发url请求,分析最后一次堆栈,通过进程死前的堆栈也能分析出来进程是死在哪里的

eg:

 

办法3:

通过ulimit -c 设置,让进程死时留下一个core文件,然后分析core文件

 

 

 Posted by at 下午 2:49
8月 162018
 
  • 不能多重判断,错误写法如:
  • 不能嵌套,错误写法如:
  • 条件前件不能为字符串,只能为变量,错误写法如:

 

相对简单可行的办法:

 

还有不太严谨的做法:

因为对于多数程序来讲, /abc?var=xyz  与 /abc?var=xyz&_=123456   是一样的,但是后者就不能被不严谨的nginx写法匹配到

 

实际用例:

 

 Posted by at 上午 10:35
8月 152018
 

现象

php 进程: THREAD_PHP_RD_\Service\Process\Deploy 不干活了,进程堆栈如下:

4个cli进程都阻塞在了这里;

大概意思为,PHP要回写session,先要一些其它交互,期望能读一行,但是,怎么也读不够一行,于是就死等

问题1:

如果没有什么意外的话,不应该让死等

问题2:

debug发现,这个stream的数据结构中,设置的超时时间为86400秒:

难怪一直阻塞住不干活。

 

解决办法:

添加超时时间的配置:

 

问题:

你问我gdb的时候是如何知道stream中如何获取超时时间的?如何知道stream->abstract 的真实数据类型的?

翻代码看到的:

 

注: 还以为此事为偶发,进程刚刚工作几个小时就全部进入到了这个场景了,还好我解决了; 其实,这并没有找到问题的根源,不找到原因的话,后续会有更加莫名其妙的的事情发生的

 

Redis 版本号

(然而现在该扩展已经开发到了4.x.y 了

 Posted by at 上午 11:43