光猫桥接路由器

引言

最近办理了北京联通的光纤宽带,自带的光猫自带了拨号、路由、无线等功能,
我不想使用这些自带的功能,只想把光猫作为纯粹的调制解调器,拨号、路由、无线等功能交由另一个高配置的无线路由器。 所以就需要将光猫桥接到这个无线路由器。这其中有些问题需要注意。
先学习了解下 Ref 中的相关资料,然后根据这些资料来确定自己的桥接步骤。

光猫桥接路由器步骤

  1. 光猫破解开启桥接功能,关闭无线功能
  2. 光猫 LAN 口和无线路由器 WAN 口

具体操作根据自己的实际情况来。 有人会碰到这个问题:光猫管理 IP 是 192.168.1.1,路由器管理 IP 也是 192.168.1.1,如何同时访问光猫和路由器的管理界面?

下面是一种解决方法:


光猫如果设置为桥接模式,而且接在路由器 WAN 口,
那其实猫的 IP 地址跟路由器 LAN IP 地址也不会冲突,所以路由器依然可以用 192.168.1.1。

1. 拨号以后路由器 WAN 口会分配公网地址,跟猫本身就不在一个网段,无法通讯
2. 不拨号,则 WAN 口无地址,也跟猫无法通讯

若要既能上网也可以访问猫和路由,也有个简单的做法(未验证),
若猫有多个 LAN 口,可以改猫的地址为 192.168.1.2 并多接一条线从猫 LAN 口到路由器 LAN 口。
因光猫在三层上面若放在路由器 WAN 口侧,是完全被 bypass 掉了,应该无法通过正常的路由方式访问。

Ref

从性能角度,以下方案,无线路由器如何连接光纤猫最好?
光猫桥接模式与路由模式有什么区别
有谁可以告诉我光猫破解到底是为了什么?
光猫桥接路由器的问题
请教北京联通中兴 F427za 光猫如何改桥接
我自己发个F427Za折腾过程中的问题吧
如何设置北京联通光猫为桥接模式

OpenWrt 简介

引言

最近在看无线路由器,无线路由器是嵌入式计算设备,它自带的是官方固件, 如果想换成第三方的固件,OpenWrt 就是一个选择(具体是否支持请查看官方硬件支持列表)。
下面对 OpenWrt 进行一个简单了解。

OpenWrt 简介


OpenWrt is described as a Linux distribution for embedded devices.

Instead of trying to create a single, static firmware, 
OpenWrt provides a fully writable filesystem with package management.
This frees you from the application selection and configuration provided by the vendor
and allows you to customize the device through the use of packages to suit any application.
For developer, 
OpenWrt is the framework to build an application without having to build a complete firmware around it;
for users this means the ability for full customization, to use the device in ways never envisioned.


OpenWrt 项目始于 2004 年 1 月。
最早的 OpenWrt 版本基于 Linksys 为遵守 GPL 而放出的、为 WRT54G 所编写的代码,以及 uclibc 项目的 buildroot。 

Linksys 放出了 WRT54G 的源代码之后,
开源爱好者便清楚了 Linksys 是如何操作这些硬件的,这样 WRT54G 就从黑盒子变为了白盒子。
OpenWRT 的和 WRT54G 相关的内核驱动的代码都经过了重写,以保证其版权 100% 属于 OpenWRT 的版权所有人。

Ref

OpenWrt
OpenWrt Wikipedia
pandorabox、openwrt、ddwrt 是什么关系? 

Nginx resolver DNS 解析超时问题分析及解决

Nginx resolver DNS 解析超时问题分析及解决

引言

今天一运维同事反映在云游戏平台操作合服时失败,查看任务日志,提示没有合服脚本。
下面记录下问题原因分析及解决过程。

问题原因分析及解决过程

1.没有合服脚本,是没有从对应服务器上下载下来,查看任务日志和下载服务器的日志,提示 HTTP 403 错误。


# Nginx Access Log 日志:

42.51.xx.xx [24/Mar/2017:11:13:20 +0800] "GET /opgame/zmsg/merge/zmsg_merge_tool.sh HTTP/1.0" 403 162 "-" "Wget/1.12 (linux-gnu)" "-" 54.459
42.51.xx.xx [24/Mar/2017:11:16:28 +0800] "GET /opgame/zmsg/merge/zmsg_merge_tool.sh HTTP/1.0" 403 162 "-" "Wget/1.12 (linux-gnu)" "-" 60.008


# Nginx Error Log 日志:

2017/03/24 11:13:20 [error] 31708#0: *237 cmdb.xxxx.cn could not be resolved (110: Operation timed out), client: 42.51.xx.xx, server: duang.xxxx.cc, request: "GET /opgame/zmsg/merge/zmsg_merge_tool.sh HTTP/1.0", subrequest: "/mcode", host: "duang.xxxx.cc:59808"
2017/03/24 11:15:58 [error] 31708#0: *238 cmdb.xxxx.cn could not be resolved (110: Operation timed out), client: 42.51.xx.xx, server: duang.xxxx.cc, request: "GET /opgame/zmsg/merge/zmsg_merge_tool.sh HTTP/1.0", host: "duang.xxxx.cc:59808"
2017/03/24 11:16:28 [error] 31708#0: *238 cmdb.xxxx.cn could not be resolved (110: Operation timed out), client: 42.51.xx.xx, server: duang.xxxx.cc, request: "GET /opgame/zmsg/merge/zmsg_merge_tool.sh HTTP/1.0", subrequest: "/mcode", host: "duang.xxxx.cc:59808"

2.根据 Nginx Error Log 日志判断 Nginx DNS 解析 cmdb.xxxx.cn 超时

我当时第一反应是:既然是超时,先尝试调大超时时间看下。Nginx DNS 解析超时参数为 resolver_timeout。


Syntax:	resolver_timeout time;
Default:	resolver_timeout 30s;
Context:	http, server, location
Sets a timeout for name resolution, for example:
resolver_timeout 5s;

但在这里我先有个疑问:默认的 30s 不够长吗?
于是使用 ping 命令测试 cmdb.xxxx.cn 的解析,返回解析 IP 所花时间只有 10 多秒,Nginx 的 DNS 解析应该不会超时啊?
这时暂时有疑问,继续上面调大 resolver_timeout 到 60s。
重新加载 Nginx,重新下载测试,还是报 cmdb.xxxx.cn could not be resolved (110: Operation timed out) 错误。 那这样应该不是 DNS 超时时间的设置问题?其实一开始我就想更换一下 DNS 服务器看下。

3.更换 Nginx resolver DNS 服务器

Nginx 默认配置的 resolver DNS 服务器是 223.5.5.5,阿里的公共 DNS 服务器。如下:


        location = /token {
            resolver 223.5.5.5;
            internal; proxy_pass http://cmdb.xxxx.cn:8334/token/$arg_query;
        }                                    
                                             
        location = /mcode {                  
            resolver 223.5.5.5;              
            internal; proxy_pass http://cmdb.xxxx.cn:8334/mcode/$arg_query;
        }

更换 Nginx resolver DNS 服务器为 114.114.114.114,重新加载 Nginx,重新下载测试,下载竟然正常了! 说明就是这台服务器到 233.5.5.5 DNS 端口的连接有问题。下面用 telnet 验证如下。


[root@htuidc ~]# telnet 223.5.5.5 53
Trying 223.5.5.5...
telnet: connect to address 223.5.5.5: Connection timed out
[root@htuidc ~]# telnet 114.114.114.114 53
Trying 114.114.114.114...
Connected to 114.114.114.114.
Escape character is '^]'.

其实上面这步验证应该在报 cmdb.xxxx.cn could not be resolved (110: Operation timed out) 错误时就应该去做的。 而不是直接调整 Nginx 的 resolver_timeout。

Ref

ngx_http_core_module.html#resolver
Nginx 的 DNS 解析过程分析

RPC 简介

引言

一直比较关注斗鱼, 之前曾写过一篇斗鱼已公开的运维技术和架构分析
最近新看到一篇“斗鱼直播平台后端 RPC 架构浅析”。RPC 应该属于 SOA 层。
关于 RPC 相关概念和框架,没有怎么接触过,现在重新了解下。

RPC 简介


RPC 是指远程过程调用,也就是说两台服务器 A/B,一个应用部署在 A 服务器上,想要调用 B 服务器上应用提供的函数/方法,
由于不在一个内存空间,不能直接调用,需要通过网络来表达调用的语义和传达调用的数据。

比如说,一个方法可能是这样定义的:
Employee getEmployeeByName(String fullName)

1. 首先,要解决通讯的问题,主要是通过在客户端和服务器之间建立 TCP 连接,远程过程调用的所有交换的数据都在这个连接里传输。
连接可以是按需连接,调用结束后就断掉,也可以是长连接,多个远程过程调用共享同一个连接。

2. 要解决寻址的问题,也就是说,A 服务器上的应用怎么告诉底层的 RPC 框架,
如何连接到 B 服务器(如主机或 IP 地址)以及特定的端口,
方法的名称名称是什么,这样才能完成调用。比如基于 Web 服务协议栈的 RPC,
就要提供一个 endpoint URI,或者是从 UDDI 服务上查找。
如果是 RMI 调用的话,还需要一个 RMI Registry 来注册服务的地址。

3. 当 A 服务器上的应用发起远程过程调用时,方法的参数需要通过底层的网络协议如 TCP 传递到 B 服务器,
由于网络协议是基于二进制的,内存中的参数的值要序列化成二进制的形式,也就是序列化(Serialize)或编组(marshal),
通过寻址和传输将序列化的二进制发送给 B 服务器。

4. B 服务器收到请求后,需要对参数进行反序列化(序列化的逆操作),恢复为内存中的表达方式,
然后找到对应的方法(寻址的一部分)进行本地调用,然后得到返回值。

5. 返回值还要发送回服务器 A 上的应用,也要经过序列化的方式发送,
服务器 A 接到后,再反序列化,恢复为内存中的表达方式,交给 A 服务器上的应用。


为什么需要 RPC 呢?就是无法在一个进程内,甚至一个计算机内通过本地调用的方式完成的需求,
比如不同的系统间的通讯,甚至不同的组织间的通讯。
由于计算能力需要横向扩展,需要在多台机器组成的集群上部署应用,

RPC 的协议有很多,比如最早的 CORBA,Java RMI,Web Service 的 RPC 风格,Hessian,Thrift,甚至 Rest API。

RPC

上面是用比较通俗的语言解释了 RPC 相关概念。
这里的一篇远程过程调用(RPC)详解写的非常详细,需要看看。

Ref

远程过程调用(RPC)详解
谁能用通俗的语言解释一下什么是 RPC 框架?
“斗鱼直播平台后端 RPC 架构浅析”

关于工作上遇到的一些技术问题的回顾总结

引言

好久没有更新博客了,春节休息了一段时间,然后是一个新业务上线会比之前忙一些。
这 2 天突然想对现在的工作上遇到的一些技术问题进行一个回顾总结。

关于工作上遇到的一些技术问题的回顾总结

1. 要在大量机器上快速分发大的软件包
2. Salt 结合 GitLab 做自动化更新,实现简单的 CI/CD

其实,这些技术问题在克服后,也不像一开始那么难,难点我感觉是在调研实施和维护的过程和判断决策。
首先是要了解痛点和需求,前期要调研(参考业界现有成熟方案)测试好,理解技术方案原理及架构,
然后更重要,同时我感觉更难的一点是如何在现有生产环境实施,因为生产环境和测试环境不同,
很多软件的默认参数我们需要真正深入理解它之后,然后根据实际情况做修改,
这就要求我们必须更加深刻理解所用的技术。 然后还有一点是,一个系统架构部署好后就不是完事了,实际上后期还要把它用起来,用好它, 而不只是实现最开始的需求,这就像互联网开发中的迭代开发一样。

3. 业务上,新游戏对接时,第三方游戏研发公司没有大规模线上运维经验。

这个对接比较耗费时间和精力。这种的情况下需要我们游戏业务的运维从项目开发初期就介入并一直跟进, 评估程序架构的可运维性,引导推进研发改进程序架构,以满足我们的成熟的游戏运维标准及规范, 这是为了以后大规模游戏服务器可以高效运维。 (上面的问题看起来是流程及标准规范的问题。但我们还可以用技术来实现流程化和标准化,减少过多的人为参与)

4. 实施一些项目时,运维标准化没做好,导致项目实施效率很慢,引入了额外的工作量。