transfer IPv6 to IPv4 via socat

Suppose that you have an ipv6-only server A with ip [ipv6-A], and ipv4-ipv6 server B with ip (ipv4-B, [ipv6-B]).

If you wanna visit http://[ipv6-A]:80, but your ISV does not provide some ipv6 addresses. Now then, you’ll make B be your “ipv6-ipv4 relay server” with following guide.

If TCP:

root@B:~# socat tcp4-listen:2222,fork tcp6:[2001:19f0:7001:5a34:5400:01ff:feb5:5bcd]:80

If UDP:

root@B:~# socat udp4-listen:2222,fork udp6:[2001:19f0:7001:5a34:5400:01ff:feb5:5bcd]:80

Now you can visit http://ipv4-B:2222 to access http://[ipv6-A]:80

Home-based hybridcloud(家庭作坊式混合云)

名字起的不好听,不过无所谓,也是混合云了,做到了什么地步呢?
在数据层面,家中机器和linode以及gcp公有云全通,任意地点的客户端可以通过局域网地址访问家中和公有云,而这一且,只需要一个公网IP。那么如何组建呢?

1. 选择一个趁手的VPN,这里我使用的是SoftEther,全平台全功能,图形界面客户端全都有,自带域名反向解析,自带公网,又那么稳定,为啥不用。
只要在家中的一台PC上装好服务端,把5555端口通过路由器(有公网IP)映射出去即可完成VPN服务器的搭建。

2. Linode服务器集群选择一台作为网关(边界路由器),负责作为客户端接入VPN服务器,那么它就有了192.168.0段的地址,其它机器上因为linode没有VPC的概念,所以得加条到192.168.0.0/24的路由。

3. 总结下来,接入到home的VPN服务器会给所有客户端一个home的IP地址,然后加的路由表(使linode集群的10段暴露出去)都围绕这个地址展开达到互通的目的。

4. 目前我把linode上分散在全球8个机房的私有服务器都加了进来,当然,安全线路。尝试了一次kcptun加速VPN连接,但是linux下失败了,windows成功。

这是图,PC-Server为VPN服务器,LINODE为公有云,也加入了Google的公有云进去(没画),Windows-PC为个人服务器。

联通之后,Google的CDN、DNS可以混合到Linode去使用了,再展开点,大数据、数据库都可以结合Linode去跑了。

如何正确计算CPU利用率?

我们平时使用的CPU利用率方法是极具误导性的,并且一年更甚一年。那么什么是CPU利用率?是你的CPU到底有多忙,是像“% CPU”这样到处在用的指标所显示的那样吗?

在top命令里,你看到90%的CPU利用率是这样:

然而它真正想表达的是这个意思:

Stall(这里译作“怠速”)是说这个处理器没有在跑指令,比如在等待内存I/O的时候。我上图所画的比例(“忙”与“怠速”之间)是我在真实生产环境中遇到的,并且你的CPU也很可能是处于“怠速”状态。

这些对你有什么意义呢?理解CPU怠速多少,会直接影响到你在减少代码或者减少内存I/O的调优工作。

那么真正的CPU利用率怎么算呢?

平时的CPU利用都是非空闲时间,即CPU不运行idle线程(比如Windows里的空闲进程)的时间。你的操作系统那会平时会在上下文切换的时候跟踪它,但是假如一个非idle线程开始运行100毫秒后停止,那内核会认为后面这段时间CPU也在这个非idle线程上。

在老旧的分时系统里,这么算没毛病。阿波罗登月舱的导航系统计算机将这里的idle线程叫做“DUMMY JOB”,工程师用利用它来测算计算机的利用率,可以参考之前我写过的这样一篇文章

那么它有什么毛病呢?

现在的CPU比内存已经快了很多倍,但等待内存的时间仍然被算进CPU时间中。当你在top命令中看到较高的“%CPU”的时候,你可能认为它到达了一个性能瓶颈,就是散热片和风扇下面的那个CPU,但实际上,这是那一根根内存条的锅。

如何分辨CPU到底在忙啥?

使用性能监测计数器(PMC)——一种能够用perf或者其他工具命令查看的硬件计数器。比如,观测整个系统10秒钟:

# perf stat -a -- sleep 10

 Performance counter stats for 'system wide':

     641398.723351      task-clock (msec)         #   64.116 CPUs utilized            (100.00%)
           379,651      context-switches          #    0.592 K/sec                    (100.00%)
            51,546      cpu-migrations            #    0.080 K/sec                    (100.00%)
        13,423,039      page-faults               #    0.021 M/sec                  
 1,433,972,173,374      cycles                    #    2.236 GHz                      (75.02%)
   <not supported>      stalled-cycles-frontend  
   <not supported>      stalled-cycles-backend   
 1,118,336,816,068      instructions              #    0.78  insns per cycle          (75.01%)
   249,644,142,804      branches                  #  389.218 M/sec                    (75.01%)
     7,791,449,769      branch-misses             #    3.12% of all branches          (75.01%)

      10.003794539 seconds time elapsed

这里的一个关键指标就是instructions per cylce(IPC,每CPU周期执行指令数),它能够显示每CPU周期内每个CPU运行了多少指令,越高说明效率越高。上述示例中,这一值为0.78,但这并不说明CPU利用率为78%,因为现代CPU的IPC最大值为4.0(新的已经到了5.0),也就是4-wide。CPU在执行指令时,单个指令会被分割为多个步骤,比如取指令、解码、执行、内存访问、写寄存器等,这些命令如果在单个CPU周期内最多执行一个,那么需要5个CPU周期来完成一条命令,IPC就是0.2,如果采用指令流水线,即3~5-wide的CPU,那么完美状态下1个CPU周期就可以完成一条命令,IPC就是1。(译者注:作者文中使用了CPU clock cycle表示通常所说的CPU周期,为了避免与晶振时钟周期混肴我并没有将其译为CPU时钟周期。)

当然,还有数百个其他你可以用来测量的性能计数器。

如果在虚拟化环境中,guest一般不能直接访问PMC,这取决于hypervisor是否支持。我最近写的一篇The PMCs of EC2: Measuring IPC展示了AWS EC2中基于Xen的虚拟机如何使用PMC。

最佳实践

如果你的IPC小于1.0,你可能遇到了内存操作密集型,软件调优策略可以有减少内存I/O,增强内存本地访问性,尤其是在NUMA系統上。硬件调优策略则是使用CPU cache较大以及更快的内存、总线和内联技术。

如果你的IPC > 1.0,你可能是指令密集型。可以试图减少指令的执行数量,比如消除不必要的工作和缓存操作等,可以用一下CPU火焰图。硬件调优方面,可以尝试高主频、多核、超线程的CPU。

性能检测产品应该告诉你什么呢?

性能检测工具都应该显示出每个进程的IPC,或者是按照指令周期与怠速周期,比如%INS和%STL,下图为Linux中的tiptop命令:

tiptop -                  [root]
Tasks:  96 total,   3 displayed                               screen  0: default

  PID [ %CPU] %SYS    P   Mcycle   Minstr   IPC  %MISS  %BMIS  %BUS COMMAND
 3897   35.3  28.5    4   274.06   178.23  0.65   0.06   0.00   0.0 java
 1319+   5.5   2.6    6    87.32   125.55  1.44   0.34   0.26   0.0 nm-applet
  900    0.9   0.0    6    25.91    55.55  2.14   0.12   0.21   0.0 dbus-daemo

CPU利用率具有误导性的其他理由

使得这个%CPU指标错误的理由除了CPU在内存的怠速周期外,还有如下因素:
1. 温度也能使CPU进入怠速;
2. Turboboost(睿频)引起时钟频率变化;
3. SpeedStep引起时钟频率变化;
4. 一分钟内的80%的平均利用率并不能表示100%的突发利用率(类似网络QoS);
5. 自旋锁:CPU在很严肃地瞎忙;

Update: CPU利用率真的错了吗?
自这篇文章发布以后,留言讨论非常激烈,已经有了上百条了。首先谢谢你们对这话题感兴趣并花时间阅读,但我在这里还是要统一回复:我对disk的iowait并不关心(译者注:PC CPU不能直接操作外部存储),并且文中也已经给出了内存操作密集型的对应调优措施。

然后,CPU利用率到底是从本质上错了还是仅仅是了?我认为需要人将高CPU利用率视为处理单元的瓶颈的事儿,是错的。那么这个指标的计算方法从技术上讲正确吗?如果CPU在怠速期间不能被其他任何进程使用,那么这不就是所谓的“使用等待”(听起来有点矛盾)。某些情况下,%CPU作为一个操作系统层面的指标是技术正确但是容易误导人的。在超线程中,怠速周期可以被其他线程使用,所以%CPU的算法也会将其算在内,而实际上并没有利用。那样是不对的,这篇文章中我强调的是解释问题并提出对策,并且,这个指标也有技术上的问题。

结论

CPU利用率已成为一个极具误导性的指标:它算进了等待主存的周期,而这类周期在现代的CPU负载中占据不少。如果使用额外指标,你就能搞清楚%CPU到底意味着什么,包括每CPU周期执行指令数(IPC)。IPC < 1.0可能意味着你的应用是内存密集型,而IPC > 1.0则可能是指令密集型。我在之前的一篇文章

显示%CPU的性能监控产品也应该显示PMC测量指标,并给予充分解释,这样才不会误导用户。比如,它们可以一起显示%CPU和IPC,或者指令周期与怠速周期。有了这些指标,开发或管理人员才能在应用和操作系统中选择正确的调优方式。

本文翻译自Brendan Gregg的博客文章《CPU Utilization is Wrong》,原文链接为http://www.brendangregg.com/blog/2017-05-09/cpu-utilization-is-wrong.html,就是那本《性能之巅(中译)》的作者,调试工具dtrace的作者,现就职于NetFlix。

PS:为什么要翻译这个文章呢?因为很多时候总感觉PC的这个CPU利用率的百分比显示没能真实反应我的CPU到底忙不忙,在学校的时候用单片机也是算idle,但到了PC后隐约感觉这么算不对,看了BG的文章后才恍然大悟。另外这篇文章之前已经被翻译过,但作者又有更新,也挺有意思的,我就重新翻了一遍,并加了一些弹幕。

硬盘、RAID组与Ceph分布式存储IOPS计算公式

防怼说明:本文用于速算,想把难以量化的环境变量以及各种组合拿来说事儿的请自行Google,或者问厂商和IDC要报告去。

机械硬盘

7200硬盘IOPS = 1000/(3 + 1000*(7200/60)/2) = 140
10k硬盘IOPS = 1000/(3 + 60000/10000/2) = 167
15k硬盘IOPS = 1000/(3 + 60000/15000/2) = 200

其中3为寻道延迟,7200/10k/15k为转速(rpm),1000*(7200/60)/2为旋转延迟(旋转延迟一般用转一圈所需时间的1/2表示),结果为理论峰值,实际还会有系统延迟导致测得IOPS一般低于此值。

RAID组
由于RAID组需要校验以提供恢复功能,所以会存在一定写惩罚,这个系数如下:
RAID0: 1
RAID1: 2
RAID5: 4
RAID6: 6
RAID1-0: 2

所以RAID组IOPS = 硬盘写IOPS*硬盘数量*写操作百分比/写惩罚系数 + 硬盘读IOPS*硬盘数量*读操作百分比。

以4块IOPS为180的SAS硬盘组RAID 6然后百分百随机写操作为例:

IOPS = 180*4/6 = 120

Ceph的IOPS经验公式
由于Ceph存储结构不同于物理硬件,所以影响其IOPS的因素主要有网络、副本数量、日志、OSD(硬盘)数量、OSD服务器数量、OSD IOPS等,这里给出一个来自Mirantis的经验公式:

IOPS = 硬盘IOPS * 硬盘数量 * 0.88 / 副本数量,
其中0.88为4-8k随机读操作占比(88%)。

关于Ceph的IOPS计算仅供参考,计算结果可能会跟物理环境实测有较大偏差。

虚拟化平台镜像去冗测试(opendedup)

OpenDedup,是一款开源去重文件系统,https://github.com/opendedup/sdfs,可以分布式,支持NFS、iSCSI等,感觉非常厉害,作者是Veritas的银堡(Sam Silverberg)。

可以去官网下载镜像,或者是笔者认为更加实用的NAS系统。

简单测试

目的是减少更多本地环境占用,使用opendedup测试。

1. 首先测试我新闻服务器上的数据,以索引文件为主,经常变动,有大有小。

2. 然后选择一款kvm软件平台。

安装:

wget http://www.opendedup.org/downloads/sdfs-latest.deb
sudo dpkg -i sdfs-latest.deb

sudo su
echo "* hardnofile 65535" >> /etc/security/limits.conf
echo "* soft nofile 65535" >> /etc/security/limits.conf
exit
sudo mkfs.sdfs --volume-name=pool0 --volume-capacity=256GB
sudo mkdir /media/pool0 
sudo mount.sdfs pool0 /media/pool0/

数据拷贝进去后,原9.3GB索引数据降为8.5GB,效果不如想象中好。

可能原因:

sdfs提供了丰富的命令行选项,我没有使用,使用后可能会达到预期,比如更小的block。

平台测试

这里选择的平台包括oVirt、OpenStack、PVE、ZStack企业版,来分别感受一下。

Hercules with Jason UI, emulator of IBM mainframe

Hercules is an open source software implementation of the mainframe System/370 and ESA/390 architectures, in addition to the new 64-bit z/Architecture. Hercules runs under Linux, Windows (98, NT, 2000, and XP), Solaris, FreeBSD, and Mac OS X (10.3 and later).

Online web interface.(deprecated)

Jason 1.00 is an integrated graphical frontend to the Hercules S/370, ESA/390 and z/Architecture Emulator. What, you haven’t heard of Hercules before? It’s a masterpiece that emulates IBM mainframes, from old good IBM System/360 and up to the modern z Series… No, it has nothing to do with IBM compatible… No, it can’t emulate Xbox 360… Oh, you are asking what a mainframe is? Then probably you don’t need Jason.

Download Hercules with Jason.

Grafana+InfluxDB+Collectd/Telegraf on RPi2

Grafana will provide a visual view for the sites, InfluxDB is the data box, and collectd/telegraf is the agent on the server. Here we go.

Install Grafana:

# Download deb from https://github.com/fg2it/grafana-on-raspberry
root@raspberrypi:~# rpm -i grafana.deb
root@raspberrypi:~# service grafana-server start


Install InfluxDB:

Download from https://portal.influxdata.com/downloads

root@raspberrypi:~# tar xf influxdb-1.2.0_linux_armhf.tar.gz
root@raspberrypi:~# cp -a influxdb-1.2.0-1/* /

vim /etc/influxdb/influxdb.ini:

[admin]
enabled=true

[http]
enabled=true

[collectd]
enabled=true
bind-address=":25826"
database="collectd"

Then run “influxdb &” and check it out in http://localhost:8083, add db named “collectd”.

Install Collectd:

root@raspberrypi:~# apt-get install collectd

In /etc/collectd/collectd.conf, find :

<Plugin network>
    <Server "localhost" "25826"></Server>
</Plugin>

Then restart collectd service.

Now you can visit http://localhost:3000 to add InfluxDB source and add panel.

Using X server in Windows Linux Subsystem

1. Turn on “Developer Mode” in Control panel.
developer-mode
sss

2. Run “bash”
bash

3. Install Xming(Xserver for Windows)
Download

4. Launch your app

# export DISPLAY=:0
# firefox

launch

5. You can create a link on your desktop like this
aaa

and ~/.bashrc

alias home='cd /mnt/c/Users/rex/Desktop'
home
export DISPLAY=:0

Tips:

Use “powershell bash” instead of “bash”, you can access your service in this way.

All about text terminal

http://www.tldp.org/HOWTO/html_single/Text-Terminal-HOWTO/

控制台(console)和终端(terminal)比较容易混淆,一般来说与主机显示输出与控制接口直接相连的显示器和键盘叫做控制台,其他不与主机控制接口直接相连的则叫做终端。
现代PC的模拟终端(tty in Linux)是模拟当年接到主机上的客户机之间的串口输入输出行为,准确的说是含有键盘作为输入和VDU(video display unit)作为输出与回显的客户端。
有些真实的终端是能够显示黑白图片的,也就是位图,这些终端协议包括Tektronix Vector Graphics, ReGIS (DEC), Sixel (DEC), and NAPLPS (North American Presentation Level Protocol Syntax)。更为炫酷的是在Apollo、Sun、SGI主机上的矢量终端(http://www.cca.org/vector/),早期电影里你看到的那些能画图的绿色显示器就是它了。
瘦客户端早期是文字终端,后来才开始有图形界面和鼠标的终端。根据其与主机的计算量相对大小可分为胖客户端和瘦客户端。
Windows NT版本开始提供的RDP服务是基于ITU T.120协议,ICA协议是在其基础上的兼容扩展。Linux可使用免费的ICA客户端,但需要向MS支付许可费。
现代的终端,包括X-Windows、Windows、Gnome等全部叫做窗口终端(Window Terminal)。
上世纪80年代的内存价格约为每兆数千美元,所以文字终端更容易流行。
终端一般都遵循一定的控制标准,即escape(ESC)控制序列,最常见的例子是我们常用的银行密码键盘。
美国的终端多以ASCII作为字母标准(除了IBM的EBCDIC),但是这些终端的ESC控制序列并不都一样,所以往往引起兼容性的问题。为此引入了termcap(“terminal capabilities”),也就是现在的环境变量TERM。
现代的模拟终端最早是由DEC引入的VT系列(vt100、vt220),Linux中的终端模型linux也与vt100类似。
模拟软件可模拟的终端类型一般有Wyse60, 50; VT 220, 102, 100, 52: TV950, 925, 912; PCTERM; ANSI; IBM3101; ADM-1l; WANG 2110。
流控(flow control)是用来防止终端、电脑、猫或其他设备处理过多字符而导致信息丢失等现象的发生,可分为软件控制和硬件控制,软件控制即发送DC1/DC3控制序列,硬件控制即分别控制串口/并口的RTS/CTS或DTR/DSR引脚高低电平。当然,现在模拟终端的流控全由软件控制了。