Just For Coding

Keep learning, keep living …

QEMU Monitor机制实例分析

QEMU实例运行时,用户可以通过monitor机制来与实例进行交互,通过它可以获取当前运行的虚拟机信息,处理热插拔设备,管理虚拟机快照等。要了解全部能力,可以参考文档: https://qemu.weilnetz.de/doc/qemu-doc.html#pcsys_005fmonitor

QEMU启动时,需要使用-monitor选项指定做为console设备,官方文档说明如下:

1
2
-monitor dev
    Redirect the monitor to host device dev (same devices as the serial port). The default device is vc in graphical mode and stdio in non graphical mode. Use -monitor none to disable the default monitor.

下面首先以标准输入输出设备做为console来启动QEMU实例:

1
2
3
4
[root@localhost ~]# qemu-system-x86_64 cirros-0.3.5-x86_64-disk.img -smp 2,cores=2 -m 2G -vnc :20 -device virtio-net-pci,netdev=net0 -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -name vm0 -monitor stdio

QEMU 2.0.0 monitor - type 'help' for more information
(qemu)

console里可以输入相关命令来完成我们的操作,比如我们查看虚拟机网络设备状态:

1
2
3
(qemu) info network
virtio-net-pci.0: index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
 \ net0: index=0,type=tap,ifname=tap0,script=no,downscript=no

TIME_WAIT状态实验分析

TIME_WAIT是排查TCP连接问题经常遇到的一种TCP状态。首先我们来看TIME_WAIT状态是如何产生的。TCP关闭连接的状态变化图如下:

可以看到,主动关闭连接的一端在发送最后一个ACK后进入TIME_WAIT状态。TIME_WAIT状态会持续2倍的MSL(Maximum Segment Lifetime),MSL是指一个TCP分段在网络上存在的最大时间,因而TIME_WAIT状态也被称为2MSL状态。

VMware vSphere平台端口镜像

端口镜像是物理交换机上的一种特性,用于将交换机上某一端口的流量发送至其他目的地。镜像的流量通常可以用于网络调试、性能监测、安全防护等方面。

Cisco将端口镜像分为三种形式:

  • SPAN(Switch Port Analyzer): 将流量从源端口镜像至同一交换机上的目的端口。
  • RSPAN(Remote SPAN): 这种形式扩展了SPAN方式,允许镜像流量经过多个二层网络设备。RSPAN将流量镜像至特定VLAN,流经的交换机需要允许该VLAN通过,流量到达目标交换机时镜像至目的端口。
  • ERSPAN(Encapsulated RSPAN): ERSPAN允许将流量镜像至三层网络设备。ERSPAN将原始流量封装到GRE(Generic Routing Encapsulation)中经由3层网络发送至目标设备。

VMware vSphere的VDS(Virtual Distributed Switch)也能够支持这些特性。VMware VDS有5种可用的端口镜像选项, 如图:

VMware环境中根据虚拟机IP找寻所在ESXi主机

在VMware vSphere虚拟环境中我们有时需要找寻某IP所在的虚拟机及ESXi宿主机。若VMware虚拟机安装了VMware tools, 则可以通过API直接查找该IP所在位置,但我们的环境中并不是所有的虚拟机都已安装,因而我们只能通过MAC地址来查找。

假设目标IP为10.95.48.11,首先我们从与目标IP位于相同二层网络内的虚拟机上获取10.95.48.11对应的MAC地址:

1
2
3
4
5
6
7
8
9
10
[root@localhost ~]# ping 10.95.48.11 -c 2
PING 10.95.48.11 (10.95.48.11) 56(84) bytes of data.
64 bytes from 10.95.48.11: icmp_seq=1 ttl=64 time=0.141 ms
64 bytes from 10.95.48.11: icmp_seq=2 ttl=64 time=0.137 ms

--- 10.95.48.11 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.137/0.139/0.141/0.002 ms
[root@localhost ~]# ip neighbor |grep 10.95.48.11
10.95.48.11 dev eth0 lladdr 00:0c:29:26:18:c8 REACHABLE

获取到MAC地址为00:0c:29:26:18:c8

Ansible入门

Ansible是一个自动化配置管理系统,主要用于简化运维人员对大量服务器上配置及服务等内容的管理工作。在自动化配置管理领域内,除了ansible, 比较著名的还有Puppet,SaltStack, Chef等项目。Ansible与这些同类项目相比,部署和使用更简单。Puppet等项目都是C/S架构,需要在被管理服务器上安装agent程序,agent程序与配置管理中心服务器通信拉取相应的配置或文件。而ansible无论是获取主机信息,发送命令还是拷贝文件等操作都是直接使用SSH通道来完成。

我们在CentOS7环境中来演示ansible使用,首先安装ansible:

1
2
yum install -y epel-release
yum install -y ansible

IPTABLES未有效阻断Windows环境下PING访问的问题分析

我们在CentOS服务器上使用IPTABLES来禁止PING访问。但为了允许从CentOS服务器上主动向外发起的PING的响应包能够正常流入,我们使用了iptables的状态机制,允许RELATED和ESTABLISHED状态的数据包通过。

我们首先配置上允许相关状态下的ICMP数据包通过的规则:

1
2
3
4
5
6
7
8
9
10
11
[root@localhost vagrant]# iptables -A INPUT -p icmp -m state --state RELATED,ESTABLISHED -j ACCEPT
[root@localhost vagrant]# iptables -nL
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Tarantool介绍

Tarantool是俄罗斯最大的互联网公司Mail.RU开发的自带DBMS的Lua应用服务器。从作用上看,它类似于带有持久化数据存储模块的node.js

现代WEB应用程序一般由专门的WEB服务器(如NGINX或APACHE)接入用户请求,然后转发给应用服务器进行业务逻辑处理。应用服务器需要从存储服务中获取数据并加工组织为特定格式的响应,发送给前端的WEB服务器,再由WEB服务器返回给用户。存储服务根据承载介质可分为磁盘存储和内存存储。最常使用的磁盘存储是关系型数据库,如MySQL、PostgreSQL。应用程序对数据库的要求主要是ACID特性。一般情况下,数据库的性能往往满足不了现代应用程序的性能要求。这种情况下,需要在应用程序中引入内存型存储做为cache来满足RPS(Request Per Second)要求,如Memcached, Redis等。典型的WEB应用架构如图:

OpenStack私有网络安全防护

之前的文章<<VMware vSphere虚拟网络防护>>介绍了vSphere环境下基于NAT实现不同子网之间的网络安全防护。在OpenStack环境下网络安全防护也可以采用同样的方式。比如,我们在OpenStack环境中,有两个私有网络, 名称分别为webdb, 两个私有网络由虚拟路由连接。架构示意图如下:

WebSocket介绍与实例分析

WEB访问一般都是基于Request/Response模式的HTTP协议,请求由浏览器发起,服务器处理请求后发送回响应。HTTP协议是短连接单向通信模型,服务器不能主动发送内容给客户端。为了解决这个问题,浏览器可以周期性地主动发送请求给服务器,服务器若没有相应数据则返回空响应,否则返回相应数据并关闭连接。这种方案被称为轮询(POLLING)。轮询需要不停地建立连接、并闭连接,不断浪费网络资源。为了减少不必要的网络消耗,LONG POLLING方案被提出。浏览器发送请求给服务器后,若服务器没有相应数据时并不返回空响应及断开连接,而是将请求保持住,当有了相应数据后或者超时发生再将数据返回给客户端并断开连接。当连接断开后,客户端会再次发起请求。这种方案依然会消耗多个TCP连接,HTTP Streaming技术进一步优化了TCP连接的使用效率。当服务器返回响应后并不关闭TCP连接,后续的请求和响应继续复用该连接。

本质上这些方案都是半双工单向通信,于是业内为基于浏览器的应用程序开发提出了全双工的实时双向通信方式: WebSocket。WebSocket是基于TCP的一种数据传输协议,它被设计成可以支持原来直接运行于TCP之上的任何协议。其他协议可以将WebSocket视为传输层,比如XMPP,STOMP,AMQP等。这给基于浏览器的应用程序开发带了具大灵活性,可以不再单纯依赖原有的HTTP协议。

PasteDeploy介绍

之前的文章<<WSGI介绍>>简要介绍了WSGI中的server, applicationmiddleware等概念。WSGI Server收到请求后调用WSGI application的入口点(一般为callable对象或者函数)来处理请求。比如,uWSGImod_wsgi默认调用名为application的入口点。

PasteDeploy是一套发现和配置WSGI应用的系统。它根据指定的配置文件动态生成入口点和组织WSGI application间的逻辑关系。配置文件为INI格式。每个配置文件可以包含多个section, section以格式为[type:name]形式的段名开始,段名行之后为具体配置。示例如下:

1
2
3
4
5
6
7
8
9
10
11
[DEFAULT]
email = alice@example.org

[app:main]
use = egg:BlogApp
database = sqlite:/home/me/blog.db
set email = bob@example.org

[app:wiki]
use = call:mywiki.main:application
database = sqlite:/home/me/wiki.db

其中,[DEFAULT]段中为全局配置,各section中可以覆盖[DEFAULT]段中配置。如示例中的set email配置。