Saturday, February 14, 2015

pptp VPN 配置

pptp VPN 可能是最简单的一种支持远程接入的 VPN 方式了,大部分 Linux 发行版都很容易进行配置支持。
Windows 则自带 pptp 客户端。

服务端安装配置

安装

$ sudo apt-get install pptpd

配置隧道网段

pptp 服务配置文件在 /etc/pptpd.conf,可以修改里面的隧道使用的 IP 子网和针对 Windows 客户端的 DNS 设置。
localip 192.168.0.1
remoteip 192.168.0.100-200
ms-dns 8.8.8.8
ms-dns 8.8.4.4

添加用户

修改 /etc/ppp/chap-secrets 文件。
# client        server  secret                  IP addresses
user1 pptpd password1 *
最后重启 pptpd 服务即可。

配置 iptables 规则

pptpd 是基于 GRE 的封包,因此要开启目的端口 1723 访问,并允许 GRE 协议。
iptables -A INPUT -p tcp --dport 1723 -j ACCEPT
iptables -A INPUT -p gre -j ACCEPT 
上面是允许客户端经过封装访问到服务端,服务端还得把这些流量帮忙转发出去,不然客户端没法访问网络了。 一个是让系统开启转发功能。
sysctl -w net.ipv4.ip_forward=1
通过 iptables 配置 NAT,让私有网可以正常访问外网(如果只是内部私有网访问,则只需要配置正确路由即可)。
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE
最后,为了避免隧道路径上的分片影响性能,调整 TCP 的 MSS 小一些。
iptables -A FORWARD -p tcp --syn -s 192.168.0.0/24 -j TCPMSS --set-mss 1356

参考

  • https://help.ubuntu.com/community/PPTPServer

Thursday, February 12, 2015

Libvirt/KVM 中的网络模式

NAT

默认方式。虚拟机获取一个私有 IP(例如 192.168.122.0/24 网段的),并通过本地主机的 NAT 访问外网。
创建一个本地网桥 virbr0,包括两个端口:virbr0-nic 为网桥内部端口,vnet0 为虚拟机网关端口(192.168.122.1)。

brctl show

bridge name bridge id STP enabled interfaces virbr0 8000.52540082327e yes virbr0-nic vnet0
虚拟机启动后,配置 192.168.122.1(vnet0)为网关。所有网络操作均由本地主机系统负责。

DNS/DHCP 的实现

本地主机系统启动一个 dnsmasq 来负责管理。
# ps aux|grep dnsmasq
nobody    2496  0.0  0.0  12892   572 ?        S     2014   0:18 /usr/sbin/dnsmasq --strict-order --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --bind-interfaces --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmas /default.leases --dhcp-lease-max=253 --dhcp-no-override --dhcp-hostsfile=/var/lib/libvirt/dnsmasq/default.hostsfile --addn-hosts=/var/lib/libvirt/dnsmasq/default.addnhosts

NAT 的实现

主机系统负责进行 SNAT。
# iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 76M packets, 3728M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 412K packets, 28M bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 MASQUERADE  tcp  --  *      *       192.168.122.0/24    !192.168.122.0/24    masq ports: 1024-65535
  231 27466 MASQUERADE  udp  --  *      *       192.168.122.0/24    !192.168.122.0/24    masq ports: 1024-65535
62902 5535K MASQUERADE  all  --  *      *       192.168.122.0/24    !192.168.122.0/24

Chain OUTPUT (policy ACCEPT 412K packets, 28M bytes)
 pkts bytes target     prot opt in     out     source               destination

通过 MacvTap 直接挂在虚机到物理网卡

比较新的 kvm 中支持。基于原先的 MacVlan + tun。
原理是创建一个 tun 设备,直接绑定到指定的(物理)端口进行收发包,在系统中生成 macvtapN@ethX 类似格式的虚拟网卡。
# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:1a:64:99:f2:60 brd ff:ff:ff:ff:ff:ff
14: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 52:54:00:82:32:7e brd ff:ff:ff:ff:ff:ff
15: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
    link/ether 52:54:00:82:32:7e brd ff:ff:ff:ff:ff:ff
70: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
    link/ether fe:54:00:39:c8:23 brd ff:ff:ff:ff:ff:ff
71: macvtap0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UNKNOWN qlen 500
    link/ether 52:54:00:66:79:1d brd ff:ff:ff:ff:ff:ff
共有四种模式:VEPA、bridge、private、passthrough。
libvirt 的配置文件中关键信息为
 <devices>
    ...
    <interface type='direct'>
      <source dev='eth0' mode='vepa'/>
    </interface>
  </devices>

VEPA (Virtual Ethernet Port Aggregator)

默认模式。多个虚拟机指定同一个接口(例如 eth0),通过该接口连接到外部的物理网络。但虚机之间的访问需要先绕到外部的物理(也可以配置为软交换机)交换机,然后由外部交换机进行转发,再绕回来。
需要外部交换机支持 Reflective Relay,或者发夹(Hairpin)模式,即从一个接口发上来的流量还能扔回去。

bridge

跟 VEPA 模式类似,但绑到同一接口上(不确定同一主机上多个网卡之间是否可以)上的多个虚机之间直接本地就转发到对应的 macvtap 设备上了,不需要到外面再绕回来。当然,要求源和目的虚机都配置为 bridge 模式。

private

虚拟机之间不能相互访问,即使外部交换机支持 Reflective Relay 也不成。除非虚机处在不同的子网,经过外面网关的转发再绕回来。要求源和目的虚机都配置为 private 模式。这种模式是不是很眼熟,多租户的公有云里面应该用处挺大。

passthrough

如果本地物理网卡支持 SRIOV,那虚机可以直接绑定到不同的 VF 上。这种模式支持虚机迁移。

连接到本地的软件交换机

例如 OpenvSwitch 等,可以先在软件交换机上创建一个 tap 接口,然后在 kvm 中指定绑定到这个 tap 接口。
跟 MACvTap 比,因为 tap 口已经创建了,直接绑定即可。
这种情况下跟 MACvTap 类似,本地系统不进行地址分配和 NAT 等,需要用户自己配置。

基本步骤

需要的脚本:
/etc/ovs-ifup
--------------------------------------------------------------------
#!/bin/sh

switch='br0'
/sbin/ifconfig $1 0.0.0.0 up
ovs-vsctl add-port ${switch} $1
--------------------------------------------------------------------

/etc/ovs-ifdown
--------------------------------------------------------------------
#!/bin/sh

switch='br0'
/sbin/ifconfig $1 0.0.0.0 down
ovs-vsctl del-port ${switch} $1
--------------------------------------------------------------------
创建网桥和虚拟接口。
# ovs-vsctl add-br br0
# ovs-vsctl add-port br0 eth0
启动虚拟机。
# kvm -m 512 -net nic,macaddr=00:11:22:EE:EE:EE -net \
tap,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown -drive \
file=/path/to/disk-image,boot=on

参考的 libvirt 虚机配置

[...]
    <interface type='bridge'>
      <mac address='52:54:00:fb:00:01'/>
      <source bridge='ovsbr0'/>
      <virtualport type='openvswitch'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
[...]

参考

  • https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Administration_Guide/chap-Virtualization_Administration_Guide-Virtual_Networking.html
  • http://seravo.fi/2012/virtualized-bridged-networking-with-macvtap
  • http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=INSTALL.KVM;hb=HEAD

Sunday, January 25, 2015

C10K 问题引发的技术变革

C10K 问题

服务器同时支持并发 10K 量级的连接,这些连接可能是保持存活状态的。
解决这一问题,思路主要有两个方面,一个是对于每个连接处理分配一个独立的进程/线程;另一个思路是用同一进程/线程来同时处理若干连接。

每个进程/线程处理一个连接

这一思路最为直接。但是由于申请进程/线程会占用相当可观的系统资源,同时对于多进程/线程的管理会对系统造成压力,因此这种方案不具备良好的可扩展性。
因此,这一思路在服务器资源还没有富裕到足够程度的时候,是不可行的;即便资源足够富裕,效率也不够高。
问题:资源占用过多,可扩展性差。

每个进程/线程同时处理多个连接

传统思路

最简单的方法是循环挨个处理各个连接,每个连接对应一个 socket,当所有 socket 都有数据的时候,这种方法是可行的。
但是当应用读取某个 socket 的文件数据不 ready 的时候,整个应用会阻塞在这里等待该文件句柄,即使别的文件句柄 ready,也无法往下处理。
  • 思路:直接循环处理多个连接。
  • 问题:任一文件句柄的不成功会阻塞住整个应用。

select

要解决上面阻塞的问题,思路很简单,如果我在读取文件句柄之前,先查下它的状态,ready 了就进行处理,不 ready 就不进行处理,这不就解决了这个问题了嘛?
于是有了 select 方案。用一个 fd_set 结构体来告诉内核同时监控多个文件句柄,当其中有文件句柄的状态发生指定变化(例如某句柄由不可用变为可用)或超时,则调用返回。之后应用可以使用 FD_ISSET 来逐个查看是哪个文件句柄的状态发生了变化。
这样做,小规模的连接问题不大,但当连接数很多(文件句柄个数很多)的时候,逐个检查状态就很慢了。因此,select 往往存在管理的句柄上限(FD_SETSIZE)。同时,在使用上,因为只有一个字段记录关注和发生事件,每次调用之前要重新初始化 fd_set 结构体。
int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
  • 思路:有连接请求抵达了再检查处理。
  • 问题:句柄上限+重复初始化+逐个排查所有文件句柄状态效率不高。

poll

poll 主要解决 select 的前两个问题:通过一个 pollfd 数组向内核传递需要关注的事件消除文件句柄上限,同时使用不同字段分别标注关注事件和发生事件,来避免重复初始化。
int poll(struct pollfd *fds, nfds_t nfds, int timeout);
  • 思路:设计新的数据结构提供使用效率。
  • 问题:逐个排查所有文件句柄状态效率不高。

epoll

既然逐个排查所有文件句柄状态效率不高,很自然的,如果调用返回的时候只给应用提供发生了状态变化(很可能是数据 ready)的文件句柄,进行排查的效率不就高多了么。
epoll 采用了这种设计,适用于大规模的应用场景。
实验表明,当文件句柄数目超过 10 之后,epoll 性能将优于 select 和 poll;当文件句柄数目达到 10K 的时候,epoll 已经超过 select 和 poll 两个数量级。
int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);
  • 思路:只返回状态变化的文件句柄。
  • 问题:依赖特定平台(Linux)。

libevent

跨平台,封装底层平台的调用,提供统一的 API,但底层在不同平台上自动选择合适的调用。

C10K 到 C10M

随着技术的演进,epoll 已经可以较好的处理 C10K 问题,但是如果要进一步的扩展,例如支持 10M 规模的并发连接,原有的技术就无能为力了。
那么,新的瓶颈在哪里呢?
从前面的演化过程中,我们可以看到,根本的思路是要高效的去阻塞,让 CPU 可以干核心的任务。
当连接很多时,首先需要大量的进程/线程来做事。同时系统中的应用进程/线程们可能大量的都处于 ready 状态,需要系统去不断的进行快速切换,而我们知道系统上下文的切换是有代价的。虽然现在 Linux 系统的调度算法已经设计的很高效了,但对于 10M 这样大规模的场景仍然力有不足。
所以我们面临的瓶颈有两个,一个是进程/线程作为处理单元还是太厚重了;另一个是系统调度的代价太高了。
很自然地,我们会想到,如果有一种更轻量级的进程/线程作为处理单元,而且它们的调度可以做到很快(最好不需要锁),那就完美了。
这样的技术现在在某些语言中已经有了一些实现,它们就是 coroutine(协程),或协作式例程。具体的,Python、Lua 语言中的 coroutine(协程)模型,Go 语言中的 goroutine(Go 程)模型,都是类似的一个概念。实际上,多种语言(甚至 C 语言)都可以实现类似的模型。
它们在实现上都是试图用一组少量的线程来实现多个任务,一旦某个任务阻塞,则可能用同一线程继续运行其他任务,避免大量上下文的切换。每个协程所独占的系统资源往往只有栈部分。而且,各个协程之间的切换,往往是用户通过代码来显式指定的(跟各种 callback 类似),不需要内核参与,可以很方便的实现异步。

参考文献

  • http://www.ulduzsoft.com/2014/01/select-poll-epoll-practical-difference-for-system-architects/

Saturday, January 24, 2015

网络流量监控技术概述

监控指标

  • 延迟(Latency)
  • 丢包率(Packet Loss)
  • 吞吐量(Throughput)
  • 链路使用率(Link Utilization)
  • 可用性(Availability)

测量手段

  • 主动 vs 被动
  • 单点 vs 多点
  • 网络层 vs 应用层
  • 镜像 vs 采样
  • 主机端 vs 交换节点

流量抓取协议

镜像/SPAN

把被监控端口的流量复制一份,发送到特定目的端口。某些硬件交换机支持,OpenvSwitch 支持类似的 Mirror 功能。
分为两类:
  • 本地 SPAN:被监控端口和目的端口在同一交换机。
  • 远端 SPAN:被监控端口和目的端口在不同交换机。
被监控的流量从方向上可以为:
  • 进入流量:支持多个端口或指定 VLAN。
  • 出去流量:一个端口。

流量统计协议

SNMP

Simple Network Management Protocol,IETF 标准,从路由器内存(MIB 库,管理信息数据库)中定期获取简单 IP 层统计信息,同时支持对设备进行管理。对设备有负担。

RMON

Remote Network MONitoring,IETF 标准,查询网络设备的 MIB 库。对设备有负担。

NetStream

基于网络流的信息统计。网络设备自身统计网络流信息并放在本地缓冲区,缓冲区满或超时后输出统计信息。 3Com、HP、华为支持。

sFlow

sampled flow。sFlow 是基于采样(sampling)的流量抓取工具,由 inMon 公司推出,交换机上使用较多。大部分硬件交换机中内置专用芯片支持,OpenvSwitch 支持。
sFlow 支持获取采样数据包的任何数量的字节,由内置 agent 封装为 UDP 包后发给采集器,默认端口为 6343。采集器(或分析器)可以根据这些数据包进行进一步的汇总和统计。sFlow 最大的优点是降低对设备的资源压力,扩展性好。
采样方法包括基于流的和基于时间的。
支持 sFlow 的设备列表可以参考:http://www.sflow.org/products/network.php。

NetFlow

Cisco 推出的基于采样的流统计标准,目的是统计每条流的信息,路由器上使用较多。在 NetFlow 技术的演进过程中,Cisco 一共开发出了 V1、V5、V7、V8 和 V9 等 5 个主要的实用版本。
NetFlow 支持采样或全部流量(CPU 占用高)的统计,本地采集到 cache 中进行统计,当流结束时(或超时,或指定时间间隔)以相应格式封装为 UDP 包上报记录并清除本地 cache,采集器典型端口为 2055。大部分设备支持的最低刷新 cache 超时为 60 秒。
定义一条流经典的考虑如下 7 个域:
  • 源 IP 地址;
  • 目标 IP 地址;
  • 源端口号;
  • 目标端口号;
  • 三层协议类型;
  • 服务类型(TOS)字节;
  • 网络设备输入或输出的逻辑网络端口(iflndex)。
Cisco Flexible NetFlow 协议号称支持用户选择自定义的域来定义流。
对于每条流可以记录其传送方向和目的地等流向特性,统计其起始和结束时间、服务类型、包含的数据包数量和字节数量等流量信息。
典型的一条流记录的格式,例如
源地址 | 目的地址 | 源自治域 | 目的自治域 | 流入接口号 | 流出接口号 | 协议源端口 | 协议目的端口 | 协议类型 | 包数量 | 字节数 | 流数量
例如(经 nfdump 转化):
Date flow start          Duration Proto   Src IP Addr:Port      Dst IP Addr:Port     Packets    Bytes Flows
 2010-09-01 00:00:00.459     0.000 UDP     127.0.0.1:24920   ->  192.168.0.1:22126        1       46     1
 2010-09-01 00:00:00.363     0.000 UDP     192.168.0.1:22126 ->  127.0.0.1:24920          1       80     1

IPFIX

IP Flow Information Export,IETF 推出的基于采样的流统计标准,源自 Cisco 的 NetFlow v9 标准。
定义一个流也考虑 NetFlow 类似的 7 个域。
每条流记录特征信息,包括:
  • 时间戳
  • 网包数
  • 网包平均大小
  • 总字节数
  • 流开始时间
  • 流结束时间

OpenFlow flow statistics

统计流量信息。

其他协议

类似协议还包括 Juniper 的 J-Flow/cflowd(类似 sFlow)、HP 的 Extended RMON 等、Ericsson 的 Rflow、Citrix 的 AppFlow。

流量采集和分析工具

inMon 自家的侧重 sFlow 的

  • Traffic Sentinel:提供大而全的流量性能分析和管控,包括网络、存储、计算热点等。支持主流的网络监控协议。
  • sFlowTrend:免费的 sFlow 流量采集,提供端口统计功能。
  • sFlowTrend Pro:增加存储功能,可以查看历史数据。
  • sFlow-RT:支持 sflow 和 SDN 控制器功能,实时 sflow 分析,提供负载均衡和 DDoS 检测等。
更多工具可以参考 http://www.sflow.org/products/collectors.php

ntopng

开源产品,原先的版本叫 ntop,定位于流量分析和问题定位。
ntopng 以网页形式显示流量统计信息,支持流量实时汇总和监控。

NetFlow Analyzer

闭源产品。支持 NetFlow, sFlow, JFLow 等格式 flow 的收集器和分析引擎整合。

Solarwinds NetFlow Traffic Analyzer

solarwinds 的产品,基于 Windows .Net+SQL Server,支持 NetFlow, sFlow, JFLow 等格式,图形界面,支持带宽统计、应用类型统计、

flowviewer

对 NetFlow/IPFix 的数据分析工具,提供 Web 界面。http://sourceforge.net/projects/flowviewer

nfdump

支持 NetFlow,提供一系列命令行工具,提供基于地址、端口等的流量信息统计。
开源产品,项目地址为 http://nfdump.sourceforge.net/。

nfsen

为 nfdump 提供的 Web 前端。
开源产品,项目地址为 http://nfsen.sourceforge.net/。

Sunday, January 18, 2015

OpenvSwitch 的 Open Virtual Network(OVN)项目

几天前(1 月 13 日),OpenvSwitch 团队正式宣布了 OVN(Open Virtual Network )项目。正文参考 Open Virtual Network Annoucement
这个项目挺有意思,简单谈下我的看法。
众所周知,OpenvSwitch 已经是现在数据中心里软件交换机的事实标准。由于硬件交换设备的成本一直降不下来,而且用硬件交换设备去延伸管控服务器上的虚拟机的相关标准和协议仍不成熟,OpenvSwitch 在相当长的一段时间里,以其成本和灵活性的优势,占据很大一部分低端市场。
传统情况下,大家使用 OpenvSwitch 主要有两个目的,一个是支持 OpenFlow、OVSDB 这样的 SDN 管控协议;另外一个是作为数据中心中的接入层交换机。
而 OVN 项目的提出,其实是针对后一种应用场景,大大增强和简化了 OpenvSwitch 作为接入层交换机的使用。
OVN 要做的事情,看起来其实蛮简单,就是直接提供对虚拟网络(各种 overlay、安全组等)的支持。这件事很简单,但是将产生的影响实际上很大。
现在数据中心里,由于大二层的需求和硬件交换机的不给力,虚拟网络实际上已经成为了一种基础设施。谁不上虚拟网络,那他的数据中心规模一定大不了。正是看到了这点,OVN 希望将如何提供虚拟网络这件事情 take over 过来,让上层的用户直接使用它,而无需自己费心思去采用各种 overlay 技术往 OpenvSwitch 中塞各种规则。
在实现上也不难理解,底下还是 OpenvSwitch,上面多了一层 Hypervisor 层,如下图(基于官方的图修改)所示,新的组件主要包括一个 OVN DB 和 一个 OVN-Controller,以及它们之间的通讯协议。

虽然官方一直坚持 OVN-Controller 并非一个 SDN 的完整控制器,但是由于目前虚拟网络管理往往是在 SDN 控制器中做的,其实可以理解为把传统 SDN 控制器中这一层要做的事情给接管了过来。往后控制器实际上可以直接操作现成的虚拟网络了。
从架构设计上,理念跟 OpenvSwitch 类似,核心还是数据库,组件之间通过协议进行松耦合的调用。
如果说最初大家讨论 SDN 是希望将控制平面跟数据平面拿开,那么,在这里其实是希望将控制层的部分功能再往回放放。这个思想跟我们 12 年提出的设计很相似。
不从对错的角度,从实用的角度看,数据平面特点是“傻快”,控制平面是“灵慢”。这意味大量重复性的简单操作应该是跟数据平面靠的近一些,反过来发生频率低的,需要复杂处理的则应该争取放到控制平面去。OVN 无疑也是看到了在数据中心网络这个特殊场景中,各种虚拟网络所依靠的封装、映射等操作已经成为了常见的基本需求。这些基本需求都放到远端的控制器,已经有点“杀鸡用牛刀”的感觉了。
当然,思路是这个思路,具体怎么做,现在这个样子是否是最合理的,还得看实践的检验。但这确实是一个从底下往上走的很好的尝试。