「CEPH」- 部署服务及快速开始
问题描述
该笔记将记录：我们部署测试 Ceph Cluster 的过程，以及相关问题的解决办法；
解决方案
参考 Installing Ceph 文档，以获取安装相关的官方详细说明，这里仅做简单记录；
第一步、版本选择
鉴于我们是测试部署，所以直接部署最新版本 Ceph 17；
第二步、服务部署
通过 ceph-deploy 进行部署（Quickstart）。但是 ceph-deploy 已不再主动维护，其未在 Nautilus 之上的测试。在对比其他部署工具并结合我们的工作场景后，我们决定在测试环境中使用 Cephadm 进行部署（需要 container 与 systemd 来管理）；
该部分将记录：通过 cephadm 命令，部署 Ceph 测试集群（学习）的方法，以及相关问题的解决办法；
#1 环境准备工作
对于非生产环境下的Ceph集群的最小化部署，推荐最少配置3个节点。节点角色可以复用。条件允许的情况下，可以配置3 MON+3 OSD+3 Gateway+1Client。
实验环境下服务器的最小配置如下：
Hardware
Ceph OSD
Ceph Mon / Ceph Mgr
Ceph RGW
Ceph MDS
CPU
1vCPU
1vCPU
1vCPU
1vCPU
RAM
16GB+5GB*OSD
1G/Daemon
1G/Daemon
2G/Daemon
DISK
OS * 1 + OSD * N
OS * 1 + 15GB*Daemon
OS * 1 + 5GB*Daemon
2MB*Daemon + Log
Network
1000Mbps * 2
1000Mbps * 2
1000Mbps * 2
1000Mbps * 2
我们需要通过 SSH 连接到各节点服务器上，然后通过执行 cephadm 命令来完成 Ceph Cluster 部署； Ceph 对时间要求很高，建议在部署 Ceph 集群的时候提前配置好 NTP 服务器； Ceph 安装对网络要求不高，但是鉴于 Ceph 源在外国有时候会被屏蔽，解决办法多尝试机器或者代理；
#2 通过 Cephadm 部署
WIP
第三步、配置使用
创建 CephFS 实例
CephFS Quick S[……]
「Electric-Drill」- 学习笔记
强力冲击钻头（780w）
品牌：质造 型号：冲击钻 产地：中国大陆 颜色分类：强劲版冲击钻-出厂配强劲版冲击钻+47 件套强劲版冲击钻+切磨钻头套 电钻类型：冲击钻电压：220V 货号：冲击钻 操作方式：手持式
产品信息
转速：～3000r/min 电压：220v 功率：780w 钻头夹持范围：1.5mm – 13mm
应用场景
支持平钻与 冲击两种模式；
平钻：金属木板瓷砖塑料玻璃铁皮 冲击：混凝土墙面水泥砖红砖天花板水泥柱[……]
「Home Appliance」- 家电
家电，Home Appliance 家用电器，Household Electrical Appliance
Coffee maker
Blender
Mixer
Toaster
Microwave
Crockpot
Rice cooker
Pressure cooker
Bachelor griller (U.K)
Stove
Lamp
Light bulb
Lantern
Torch
Clothes iron
Electric drill
Kettle
Water cooker (U.K)/ Electric kettle/ Hot pot (U.S)
Water purifier
Kitchen hood
Electric guitar
Vacuum cleaner
Electric fan
Evaporative cooler
Air conditioner; air-conditioning; aircondition; air-conditioner; 空调
Oven
Dishwasher
Television
Speaker
Clothes dryer
Washing machine
Refrigerator[……]
「Air Conditioning」- 空调
空调匹数、功率和适用面积对照表
知乎/家电蓝哥/空调匹数、功率和适用面积对照表非常实用建议收藏
空调是比较耗电的产品，功率并非越大越好，而是要与房间面积相匹配。买空调首先要考虑的是房间面积，然后再考虑房间朝向等环境影响，最后选择一款适合匹数的空调。
如果一味追求高速制冷或者制热，小房间买大空调，在使用时，制冷制热速度过快，空调压缩机会频繁启动，耗电量高，造成不必要的浪费；而过分考虑耗电问题，大房间使用小功率空调，就会造成制冷制热速度慢，空调压缩机不停机的现象，影响寿命，耗电不停。
空调匹数
空调的“匹（P）”是功率单位“马力”的俗称，1P=735.499W，通常用匹来表示压缩机的规格。目前主要是以制冷量来计算，因此常说的空调 1P 指的是为空调压缩机输入 735w 功率所对应产生的制冷量；
制冷量
参考 空调制冷量计算公式 说明，以获得详说明。
压缩机的效率约为 0.8～0.85，性能系数（COP）一般在 2.8～3.0 之间，计算下来，1P 空调器的制冷量大约为 2200～2600W，同样也可以计算出 1.5 匹、2 匹空调的制冷量。
一般来说 1P 的制冷量大约为 2000 大卡，换算成国际单位 * 1.162，1P 制冷量为 2000×1.162=2324W；
制冷量 and 制热量 and 房屋朝向
我们以楼层高 2.5 米的房间为例，可按下面公式计算房间所需的制冷量、制热量： 1）制冷量＝房间面积×140W～180W 2）制热量＝房间面积×180W～240W
上面是参考计算方法，实际情况还应根据房间朝向、装修布置、玻璃窗大小、楼层高低、房间保暖性、密闭程度、居住人数等因素综合权衡。在朝阳、房顶较高或是外墙较多的房间，空调的功率就应适当放大。在低温的地区还应考虑的热冷比及低温启动能力，以满足较高的制热要求；
房屋朝向与制冷量参考如下：
明明白白选购适合匹数的空调
明白了匹数、制冷、制热等关系，我们在选购空调的时候，可以根据室内的面积来选择空调的匹数大小，参考如下(大约值)：[……]
「Electrical-Engineering-and-Automation」- 杂记、技巧
木头上拧螺丝开裂怎么办？
木头上拧螺丝容易开裂？今天才知道用这2个方法轻松解决，涨知识
把螺丝的前端尖尖的部分用钳子夹掉，使螺丝形成平头而不是尖头，这样即使怎么钉木板都不会开裂了。
或者，我们们会先用电钻钻孔（孔径小于螺丝直径），然后再拧入螺丝；
或者，先剪去螺丝头部的尖端（少量即可），然后在拧入。我们猜测其原理类似用电钻钻孔：拧入螺丝时，参差的螺丝前端将内部木质捣碎，沿螺纹排出，以减小内部压力从而防止木头开裂；
或者，将螺丝用水弄湿，再拧入木板中，在拧入螺丝的 1/3 之后，再拧出沾水重新拧入 —— 我们未试过这种方法，只是听说过；[……]
「K4NZ」- 待办事项
papers-we-love/papers-we-love: Papers from the computer science community to read and discuss.
英语
其他事项
# 在Linux中设置显卡及相关内容
# 与KVM有关的CPU设置
# 设置WebDAV、CalDAV服务器
# Glype 项目
# /etc/sysctl.conf介绍；
# java命令介绍
# make教程
# sslsniff
# 性能分析 http://www.brendangregg.com/linuxperf.html http://www.kuqin.com/shuoit/20140910/342080.html
# 虚拟机检测 http://cache.baiducontent.com/c?m=9f65cb4a8c8507ed4fece763104687270e54f7216b818b5e68d4e419ce3b46001d3ba6fd7d62475785d27c1043f50b4beb847065367523b490c38c41c9fecf6879873042720bf14a05a21fb8bc4632c050872a99b86d94adf14284dea3c4a82544ba53120d80e78a2a1764bb7880652692d58e3c124811cafa4161e828043eee5457c243&p=c272c45385cc43e008e2947d074981&newp=91769a47cd934eaf5be78834115c95231610db2151d4d61f64&user=baidu&fm=sc&query=%D0%E9%C4%E2%BB%FA%BC%EC%B2%E2%BC%BC%CA%F5%C6%CA%CE%F6&qid=b9dbb5a600016864&p1=1
# 《working with unix processes》
# Programming in Haskell
# 树莓派 魔镜： http://shumeipai.nxez.com/2015/04/08/make-magic-mirror-with-raspberry-pi.html http://tieba.baidu.com/p/4326191804
# 树莓派集群
配置snort入侵检测
修改风扇的转速
系统级Shadowsocks代理。Shadowsocks：美国云主机，VPS，HHVPS，国外云主机购买、SS搭建。
大海捞针，[……]
「Linux」- 性能优化（学习路径）
背景知识准备
对于性能优化，需要学习以下内容： 1）基础知识：熟练掌握计算机原理、操作系统知识、计算机网络等等知识，熟记于心； 2）排查工具：常用性能工具使用、查看性能指标、定位性能问题； 3）经验总结：总具体的案例中总结经验，抽象出性能排查的一般思路与模式；
熟练掌握”基础原理知识“只是性能优化的开始，这些基础知识盘根错节，任何地方都可能导致性能问题。所以，并不是说掌握基础支持就等于掌握性能问题的排查方法；
性能优化学习
该部分笔记开始于 Linux 性能优化实战 的学习笔记，然后不断整理性能优化相关的内容；
CPU 性能篇 (13 讲)
02 | 基础篇：到底应该怎么理解“平均负载”？ => Load Average
03 | 基础篇：经常说的 CPU 上下文切换是什么意思？（上） => Context switch 04 | 基础篇：经常说的 CPU 上下文切换是什么意思？（下）
05 | 基础篇：某个应用的 CPU 使用率居然达到 100%，我该怎么办？ => CPU utilization
06 | 案例篇：系统的 CPU 使用率很高，但为啥却找不到高 CPU 的应用？ 07 | 案例篇：系统中出现大量不可中断进程和僵尸进程怎么办？（上） => Linux process states 08 | 案例篇：系统中出现大量不可中断进程和僵尸进程怎么办？（下）
09 | 基础篇：怎么理解 Linux 软中断？ => interrupts and softirqs
10 | 案例篇：系统的软中断 CPU 使用率升高，我该怎么办？
11 | 套路篇：如何迅速分析出系统 CPU 的瓶颈在哪里？ => 01.CPU 12 | 套路篇：CPU 性能优化的几个思路
13 | 答疑（一）：无法模拟出 RES 中断的问题，怎么办？ 14 | 答疑（二）：如何用 perf 工具分析 Java 程序？
内存性能篇 (8 讲)
15 | 基础篇：Linux 内存是怎么工作的？ 16 | 基础篇：怎么理解内存中的 Buffer 和 Cache？ 17 | 案例篇：如何利用系统缓存优化程序的运行效率？ 18 | 案例篇：内存泄漏了，我该如何定位和处理？ 19 | 案例篇：为什么系统的 Swap 变高了（上） 20 | 案例篇：为什么系统的 Swap 变高了？（下） 21 | 套路篇：如何“快准狠”找到系统内存的问题？
22 | 答疑（三）：文件系统与磁盘的区别是什么？
I/O 性能篇 (10 讲)
23 | 基础篇：Linux 文件系统是怎么工作的？ 24 | 基础篇：Linux 磁盘 I/O 是怎么工作的（上） 25[……]
「LINUX-PERFORMANCE-TUNING」- I/O
指标（Metrics）
注意事项： 1）注意具体场景，读写类型（顺序还是随机）、读写比例、读写大小、存储类型（有无 RAID 以及 RAID 级别、本地存储还是网络存储）等 2）不同场景的 I/O 性能指标，不能直接进行分析对比
工具（Tools）
df => 文件系统数据的空间容量 / 查看索引节点的容量
/proc/meminfo、/proc/slabinfo / slabtop => 页缓存、目录项缓存、索引节点缓存、具体文件系统的缓存
iostat => 磁盘的 I/O 使用率、吞吐量、响应时间、IOPS
pidstat => 观察到进程的 I/O 吞吐量、块设备 I/O 的延迟
strace / lsof => 进程正在读写的文件、系统调用
filetop / opensnoop => 从内核中跟踪系统调用
联系（Metrics <=> Tools）
磁盘 I/O 查看
iostat iotop
从指标出发
文件系统空间容量、使用量以及剩余空间 => df
索引节点容量、使用量以及剩余量 => df
页缓存和可回收 Slab 缓存 /proc/meminfo sar -r、vmstat
缓冲区 /proc/meminfo sar -r、vmstat
目录项、索引节点以及文件系统的缓存 /proc/slabinfo slabtop 更直观
磁盘 /O 使用率、IOPS、吞吐量、响应时间、I/O 平均大小以及等待队列长度 iostat -d -x sar -d dstat
进程 I/O 大小以及 I/O 延迟 pidstat -d iotop
块设备 I/0 事件跟踪 blktrace => blktrace -d /dev/sda -O – | blkparse -i –
进程 I/O 系统调用跟踪（通过系统调用跟踪进程的 /0） strace
进程块设备 I/O 大小跟踪（安装 bcc 软件） biosnoop biotop
从工具出发
iostat => 磁盘 I/O 使用率、IOPS、 吞吐量、响应时间、I/O 平均大小以及等待队列长度
pidstat => 进程 I/O 大小以及 I/O 延迟
sar => 磁盘 I/O 使用率、IOPS、吞吐量以及响应时间
dstat => 磁盘 I/O 使用率、IOPS 以及吞吐量
iotop => 按 I/O 大小对进程排序
/proc/slabinfo / slabtop => 目录项[……]
「Linux」- 文件系统调优
检查磁盘空间
// 查看文件系统的磁盘空间使用情况（总空间用 1K-blocks 的数量来表示）
$ df /dev/sda1
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 30308240 3167020 27124836 11% /
// 通过 -h 选项，以获得更好的可读性
$ df -h /dev/sda1
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 29G 3.1G 26G 11% /
检查索引节点
// 检查 索引节点 的使用情况
$ df -i /dev/sda1
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda1 3870720 157460 3713260 5% /
检查 inode/dentry 缓存
Linux Kernel 使用 Slab 机制，管理 dentry 和 inode 的缓存；
/proc/meminfo 仅显示 Slab 的整体大小，具体到每一种 Slab 缓存，还要查看 /proc/slabinfo 文件；
slabtop
/proc/slabinfo 并不易阅读，在实际性能分析中，我们更常使用 slabtop ，来找到占用内存最多的缓存类型；
# slabtop
Active / Total Objects (% used) : 1448105 / 1884228 (76.9%)
Active / Total Slabs (% used) : 56703 / 56703 (100.0%)
Active / Total Caches (% used) : 113 / 158 (71.5%)
Active / Total Size (% used) : 361280.20K / 669058.59K (54.0%)
Minimum / Average / Maximum Object : 0.01K / 0.35K / 9.62K
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
316050 62089 19% 1.06K 10535 30 337120K nfs_inode_cache
216239 206662 95% 0.20K 11[……]
「Linux」- 磁盘 I/O（学习笔记）
解决方案
存储系统的 I/O ，通常是整个系统中最慢的一环。所以， Linux 通过多种缓存机制来优化 I/O 效率： 1）比方说，为了优化文件访问的性能，会使用页缓存、索引节点缓存、目录项缓存等多种缓存机制，以减少对下层块设备的直接调用； 2）为了优化块设备的访问效率，会使用缓冲区，来缓存块设备的数据
磁盘性能指标（常见指标）
不要孤立地去比较某一指标，而要结合读写比例、I/O 类型（随机还是连续）以及 I/O 的大小综合来分析； 1）在数据库、大量小文件等这类随机读写比较多的场景中，IOPS 更能反映系统的整体性能； 2）而在多媒体等顺序读写较多的场景中，吞吐量才更能反映系统的整体性能；
Bandwidth（吞吐量）
指每秒的 I/O 请求大小
Latency（响应时间）
指 I/O 请求从发出到收到响应的间隔时间
IOPS（每秒请求数）
指每秒的 I/O 请求数量
使用率
指磁盘处理 I/O 的时间百分比。过高的使用率（比如超过 80%），通常意味着磁盘 I/O 存在性能瓶颈；
注意，使用率只考虑有没有 I/O，而不考虑 I/O 的大小。换句话说，当使用率是 100% 的时候，磁盘依然有可能接受新的 I/O 请求；
饱和度（Saturation Level）
指磁盘处理 I/O 的繁忙程度；
过高的饱和度，意味着磁盘存在严重的性能瓶颈。当饱和度为 100% 时，磁盘无法接受新的 I/O 请求；
磁盘 I/O 性能（基准测试）
推荐用性能测试工具 fio ，来测试磁盘的 IOPS、吞吐量以及响应时间等核心指标。但还是那句话，因地制宜，灵活选取。在基准测试时，一定要注意根据应用程序 I/O 的特点，来具体评估指标；
并且需要我们测试出，不同 I/O 大小（一般是 512B 至 1MB 中间的若干值）分别在随机读、顺序读、随机写、顺序写等各种场景下的性能情况；
用性能工具得到的这些指标，可以作为后续分析应用程序性能的依据。一旦发生性能问题，你就可以把它们作为磁盘性能的极限值，进而评估磁盘 I/O 的使用情况；
磁盘 I/O 观测
容易被误读的 iostat | Linux Performance 深入理解 iostat
iostat，来自 /proc/diskstats 文件，而 /proc/diskstats 并不提供存储设备性能的数据。其显示的数据包含在队列中等待的时间，所以并不能直接反馈存储设备性能；
# iostat -d -x 1 // -d -x 表示显示所有磁盘 I/[……]
「LINUX-PERFORMANCE-TUNING」- 高延迟
问题描述
# docker run –name=app-iodelay -p 10000:80 -itd feisky/word-pop
# curl http://10.10.50.188:10000/ // 确认案例正常启动
hello world
# curl http://10.10.50.188:10000/popularity/word // 访问示例应用
// 我们发现这个接口居然长时间都没响应
# df // 查看一下文件系统的使用情况
// 这么简单的命令，居然也要等好久才有输出
// 运行如下命令，以制造负载，用于问题排查
# while true; do time curl http://10.10.50.188:10000/popularity/word; sleep 1; done
原因分析
第一步、查看总体情况：top
# top
top – 10:49:54 up 57 days, 1:06, 1 user, load average: 4.26, 1.50, 0.88
Tasks: 191 total, 1 running, 190 sleeping, 0 stopped, 0 zombie
%Cpu0 : 0.3 us, 1.0 sy, 0.0 ni, 36.5 id, 62.1 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu1 : 1.3 us, 2.3 sy, 0.0 ni, 0.7 id, 95.4 wa, 0.0 hi, 0.3 si, 0.0 st
%Cpu2 : 2.3 us, 5.0 sy, 0.0 ni, 3.7 id, 89.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu3 : 0.3 us, 1.7 sy, 0.0 ni, 0.0 id, 98.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 11854.82+total, 117.410 free, 1456.715 used, 10280.70+buff/cache
MiB Swap: 0.000 total, 0.000 free, 0.000 used. 9987.316 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND[……]
「LINUX-PERFORMANCE-TUNING」- 高负载
问题描述
我们运行如下程序，但是我们发现系统负载快速升高，需要进行问题排查；
# docker run -v /tmp:/tmp –name=app-log -itd feisky/logapp // 运行应用程序
# ps -ef | grep /app.py // 确认案例应用正常启动
root 23054 23036 45 08:30 pts/0 00:00:02 python /app.py
root 23089 20643 0 08:30 pts/0 00:00:00 grep –color=auto /app.py
原因分析
第一步、观察总体情况：top
# top
top – 08:32:22 up 56 days, 22:49, 1 user, load average: 3.57, 1.70, 0.89
Tasks: 196 total, 2 running, 194 sleeping, 0 stopped, 0 zombie
%Cpu0 : 0.7 us, 1.3 sy, 0.0 ni, 0.0 id, 97.7 wa, 0.0 hi, 0.3 si, 0.0 st
%Cpu1 : 17.9 us, 78.8 sy, 0.0 ni, 3.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu2 : 1.0 us, 0.3 sy, 0.0 ni, 97.0 id, 1.7 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu3 : 2.0 us, 0.3 sy, 0.0 ni, 97.3 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
MiB Mem : 11854.82+total, 1368.898 free, 1653.500 used, 8832.430 buff/cache
MiB Swap: 0.000 total, 0.000 free, 0.000 used. 9793.617 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
23054 root 20 0 1040092 644228 3304 R 96.7 5.3 1:25.50 python /app.py
7294 apache 20 0 369372 30468 4136 S 2.0[……]
「mysql slowquery」- 由数据库慢查询引发的 I/O 问题
配置环境，以创建负载场景
# git clone https://github.com/feiskyer/linux-perf-examples
# cd linux-perf-examples/mysql-slow
# make run // 启动与案例相关的容器
# docker ps // 确认三个容器都处在运行
// MySQL 需要做一些初始化工作，需要花费几分钟时间
# docker logs -f mysql // 查看 MySQL 的启动过程
// 执行下面的命令，确认它也已经正常运行
# curl http://127.0.0.1:10000/
Index Page
// 初始化数据库，并插入 10000 条商品信息
# make init
// 访问一下商品搜索的接口
# curl http://10.10.50.188/products/geektime
// 这个接口返回的是空数据，而且处理时间超过 15 秒
// 继续执行下面的命令，制造负载以进行测试
# while true; do curl http://192.168.0.10:10000/products/geektime; sleep 5; done
第一步、运行 top 命令，观察资源使用情况
# top
top – 12:02:15 up 6 days, 8:05, 1 user, load average: 0.66, 0.72, 0.59
Tasks: 137 total, 1 running, 81 sleeping, 0 stopped, 0 zombie
%Cpu0 : 0.7 us, 1.3 sy, 0.0 ni, 35.9 id, 62.1 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu1 : 0.3 us, 0.7 sy, 0.0 ni, 84.7 id, 14.3 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 8169300 total, 7238472 free, 546132 used, 384696 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 7316952 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27458 999 20 0 833852 57968 13176 S 1.7 0.7 0:12.40 mysqld
27617 r[……]
「redis」- 由于 Redis 错误配置导致的 I/O 压力
配置环境，以创建负载场景
# docker run –name=redis -itd -p 10000:80 feisky/redis-server
# docker run –name=app –network=container:redis -itd feisky/redis-app
# docker ps // 确认两个容器都处于运行状态
# curl http://10.10.50.188:10000/ // 检测应用正常启动
hello redis
// 初始化 Redis 缓存，并且插入 5000 条缓存信息
curl http://10.10.50.188:10000/init/5000
{“elapsed_seconds”:30.26814079284668,”keys_initialized”:5000}
// 测试接口调用
# curl http://10.10.50.188:10000/get_cache
{“count”:1677,”data”:[“d97662fa-06ac-11e9-92c7-0242ac110002″,…],”elapsed_seconds”:10.545469760894775,”type”:”good”}
// 接口调用响应时间较长，需要花费 10 秒
// 循环执行命令，以创造负载，用于调试
# while true; do curl http://10.10.50.188:10000/get_cache; done
第一步、运行 top 命令，观察资源使用情况
# top
top – 12:46:18 up 11 days, 8:49, 1 user, load average: 1.36, 1.36, 1.04
Tasks: 137 total, 1 running, 79 sleeping, 0 stopped, 0 zombie
%Cpu0 : 6.0 us, 2.7 sy, 0.0 ni, 5.7 id, 84.7 wa, 0.0 hi, 1.0 si, 0.0 st
%Cpu1 : 1.0 us, 3.0 sy, 0.0 ni, 94.7 id, 0.0 wa, 0.0 hi, 1.3 si, 0.0 st
KiB Mem : 8169300 total, 7342244 free, 432912 used, 394144 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 7478748 avail Mem
PID USER PR NI VIRT RES[……]
「Linux」- eBPF
「Docker」- Containerd did not exist sucessfully
问题描述
机器关机，再次启动之后，产生如下错误：
Jul 30 13:26:43 localhost.localdomain dockerd[3957]: time=”2018-07-30T13:26:43.932115371+02:00″ level=error msg=”containerd did not exit successfully” error=”exit status 2″ module=libcontainerd
问题原因
不知道……内核版本不满足要求可能导致该问题，但是我的内核版本已经满足要求。
解决办法
重新安装：yum reinstall
相关链接
Docker-CE cannot run because of dockered error: “Containerd did not exist sucessfully” Exist status code 2 #377 Failed to connect to containerd: failed to dial #274 Just installed: Failed to connect to containerd #218[……]
「Docker」- 进程被意外杀死（KILL/9）
问题描述
运行在主机中的 dockerd（docker.service）会收到 KILL/9 信号，便退出。
我们们希望知道是哪个进程发送了 KILL 信号。
该笔记将记录：如何定位发送 KILL 信号的进程
解决方法
使用 Audit 或者 SystemTap 进行捕获。由于 SystemTap 比较复杂，我们这里介绍使用 Audit 的方法。
方法一、使用 Audit 捕获信号
第一步、进行 Audit 配置
apt-get install auditd
auditctl -a exit,always -F arch=b64 -S kill -k audit_kill
# 默认配置已处理日志轮转
第二步、等待 KILL 信号出现……
第三步、通常日志较多，在捕获后，建议尽快结束：
systemctl restart auditd.service
参考文献
How to find Which Process Is Killing mysqld With SIGKILL or SIGTERM on Linux – The Geek Diary SystemTap – Debian Wiki[……]
「Docker」- …dial unix /var/run/docker.sock: connect: permission denied…
问题描述
当使用非 ROOT 用户执行 docker 命令时，
产生如下错误信息：
# docker inspect -f . node:14-alpine
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.40/containers/node:14-alpine/json: dial unix /var/run/docker.sock: connect: permission denied
或者如下错误信息：
Post http:///var/run/docker.sock/v1.19/auth: dial unix /var/run/docker.sock: permission denied. Are you trying to connect to a TLS-enabled daemon without TLS?
问题原因
这些都是同类问题，即非 Root 用户管理 Docker 服务时权限不足。
在 Docker 进程运行时，使用 Unix socket 文件，它由 root:root 所有，所以只有 root 能访问。
如果非 root 用户想要管理，则需要使用 sudo 命令，或者使用其他方法（见下文）。
解决办法
# groupadd docker
# usermod -aG docker “target user”
# systemctl restart docker.service
注意事项
使用 docker 组所授予的权限等同于 root 用户。对系统安全的影响，参考 Docker daemon attack surface 文档
参考文献
Manage Docker as a non-root user[……]
「Docker」- runtime/cgo: pthread_create failed: No space left on device
问题描述
在执行 docker ps 命令时（运行容器、其他命令），产生如下错误：
# docker ps
runtime/cgo: pthread_create failed: No space left on device
SIGABRT: abort
PC=0x7f1a69cace97 m=0 sigcode=18446744073709551610
goroutine 0 [idle]:
runtime: unknown pc 0x7f1a69cace97
stack: frame={sp:0x7ffd418bd5d0, fp:0x0} stack=[0x7ffd410bec10,0x7ffd418bdc50)
00007ffd418bd4d0: 0000000000000000 0000000000000000
…
00007ffd418bd540: 000000006e43a318 00005601a65818ac
00007ffd418bd550: 0000000000000000 00005601a508d93e <runtime.callCgoMmap+62>
00007ffd418bd560: 00007ffd418bd568 0000000000000000
00007ffd418bd570: 0000000000000000 00007ffd418bd5b8
00007ffd418bd580: 00005601a50855ba <runtime.mmap.func1+90> 0000000000000000
00007ffd418bd590: 0000000000210800 0000002200000003
00007ffd418bd5a0: 00000000ffffffff 00007f1a67a5d000
00007ffd418bd5b0: 00007ffd418bd5f8 00007ffd418bd630
00007ffd418bd5c0: 00005601a5032113 <runtime.mmap+179> 00007ffd418bd600
00007ffd418bd5d0: <0000000000000000 00007ffd418bd628
…
00007ffd418bd600: 000000006e43a318 00005601a65818ac
00007ffd418bd610: 0000000000210800 00005601a508d93e <runtime.callCgoMmap+62>
00007ffd418bd620: 00007ffd418bd628 00007ffd[……]
「Docker Compose」- 容器编排
Compose，一个用于定义和运行多个容器的工具；
首先，使用 YAML 文件定义一组要启动的容器，然后通过一个简单的命令来启动所有在配置文件中定义的服务；
使用 Docker Compose 部署应用：
（1）创建 Compse 文件。该文件的内容「类似于把docker run的参数写在文件中」；
web:
image: jam01/compseapp
command: python app.py
ports:
– “5000:5000”
volumns:
– .:/composeapp
links:
– redis
redis:
images: redis
也可以用于构建一个镜像：
web:
build: /home/jams/composeapp
关于该 YAML 文件的完整指令列表，可以参考「Overview of Docker Compose」手册；
（2）运行 Compse 程序
#!/bin/sh
# 使用 docker-compose up 来启动这些服务
docker-compose up
# 必须在 docker-compose.yaml 目录中执行大多数的 Compose 命令；
# 为了保证服务的唯一，Compose 将目录名字作为前缀，并使用数字作为后缀，组合起来作为服务名
# 使用-d 选项以守护进程的方式运行。不使用该选项是可以通过 Ctrl+C 来结束；
docker-compose up -d
# 和 docker 命令类似，Compose 也受 DOCKER_HOST 环境变量的影响；
参考文献
GitHub/Docker Compose[……]
「CONTAINER-RUNTIME」- podman
修改 infra_image 地址
How to change the default infra container in Podman? – Server Fault
配置文件路径： 1）/usr/share/containers/containers.conf 2）/etc/containers/containers.conf 3）$HOME/.config/containers/containers.conf (Rootless containers ONLY)
# cp /usr/share/containers/containers.conf /etc/containers/containers.conf # 如果 conftainers.conf 不存在，则执行该命令
# vim /etc/containers/containers.conf
…
infra_image = “index.docker.io/rancher/pause:3.2”
…[……]
「Network」- 概念，术语
RFC, Request for Comments
Wikipedia/RFC: https://en.wikipedia.org/wiki/Request_for_Comments RFC Official Website: https://www.rfc-editor.org RFC Index: https://www.rfc-editor.org/rfc-index.html
TCP/IP Model
Wikipedia/List of network protocols (OSI model)
将网络的通信过程划分为小一些、简单一些的部件，有助于各个部件的开发、设计和故障排除； 通过网络组件的标准化，允许多个供应商进行开发； 通过定义在模型的每一层实现什么功能，鼓励产业的标准化； 允许各种类型的网络硬件和软件相互通信；
Network vs Networking
What is the Difference Between Network and Networking – Pediaa.Com
The main difference between network and networking is that network is a collection of computing devices connected via a communication medium to exchange information and resources while networking is the practice of creating, maintaining, securing and troubleshooting the network.
QoS, Quality of Service
服务质量
SLA, Service Level Agreement
SLA 是关于网络服务供应商和客户间的一份合同，其中定义了服务类型、服务质量和客户付款等术语。 按照SLA要求，服务供应商采用多种技术和解决方案去监控和管理网络性能及流量，以满足SLA中的相关需求，并产生对应的客户结果报告。
VPN, Virtual Private Network
虚拟专用网络
TE, Traffic Engineering
流量工程
组织机构
IETF, Internet Engineering Task Force
因特网工程任务组
ISO（International Organization for Standardization）
国际标准化组织
ISP and NSP
Internet Service Provider，ISP[……]
「NETWORKING」- 网络类型：局域网，城域网，广域网
按照地理覆盖范围划分
局域网（Local Area Network，LAN）
1）LAN，局域网，方圆几千米内； 比如家庭、网吧、家庭等等；
LAN 是在一个局部的地理范围内（如一个学校、工厂和机关内），一般是方圆几千米以内，将各种计算机，外部设备和数据库等互相联接起来组成的计算机通信网；
城域网（MAN）
2）MAN，城域网，在城市范围内的计算机通信网络； 比如宽带城域网、教育城域网等等；
广域网（WAN）
3）WAN，广域网，在几十公里到几千公里，连接多个城市和国家，提供远距离通信； 比如：因特网（Internet）
覆盖的范围比局域网（LAN）和城域网（MAN）都广。广域网的通信子网主要使用分组交换技术。广域网的通信子网可以利用公用分组交换网、卫星通信网和无线分组交换网，它将分布在不同地区的局域网或计算机系统互连起来，达到资源共享的目的。如因特网（Internet）是世界范围内最大的广域网；
广域网（Wide Area Network，WAN），提供不同地区、城市、国家之间的互联服务。广域网通常会跨越非常远的距离（几十公里到几千公里），为了满足广域网远距离传输的需求，经常使用光纤作为互联的媒介；
局域网是在某一区域内的，而广域网要跨越较大的地域。例如，一家大型公司的总公司位于北京，而分公司遍布全国各地，如果该公司将所有的分公司都通过网络联接在一起，那么一个分公司就是一个局域网，而整个总公司网络就是一个广域网；
广域网的典型速率是从 56 Kbps 到 155 Mbps，现在已有 622 Mbps，2.4 Gbps 甚至更高速率的广域网；传播延迟可以从几毫秒到几百毫秒（使用卫星信道时）；
教育行业的网络结构
无线网络
WPAN：10m；比如：蓝牙 Zigbee NFC
WLAN：100m；比如：
WMAN：5km；比如：WiMax
WWAN：15km；比如：GSM CDMA LTE 5G[……]
「Network」- 网络拓扑，Network Topology
问题描述
网络拓扑，是指用传输介质互联各种设备所呈现的结构化布局。
解决方案
简单网络
两台设备直连。
按照 网络拓扑形态 划分
总线网络/星型网络，是早期的网络，已经淘汰。[……]
「NETWORK」- 数据通信协议、网络协议
问题描述
该部分笔记将记录：与网络协议相关的内容，以及相关服务部署；
解决方案
协议栈：用于定义和管理不同网络的数据转发规则。比如 OSI、TCP/IP、IPX/SPX、SNA 等等；
在网络中，协议栈是分层的： 1）在 OSI model 中，分 7 层 2）在 TCP/IP model 中，分 5 层
IEEE 802，是局域网协议标准。广域网有 Ethernet PPP HDLC 等等协议；
分层模型的作用
协议分层的原因： 1）网络通信的过程很复杂：便于接收者处理；分层能够降低复杂性；
分层设计的意义： 1）简化相关相关网络操作；提供厂商之间的兼容性； 2）各层独立，一层变化不会影响其他临层；
OSI 层次设计理念： 1）解决异种网络互联时所遇到的兼容性问题； 2）将服务、接口、协议这三个概念明确区分开； —- 服务：某一层为上一层提供一些什么功能； —- 接口：上层如何使用下层服务； —- 协议：如何实现本层服务； 3）各层独立性强，网络中采用何种协议不会影响上层；
List of network protocols (OSI model) – Wikipedia
参考文献
ISC: https://www.isc.org/ Wikipedia/OSI model TCP/IP Model TCP/IP 详解（TCP/IP illustrated）[……]
「NETWORK」- 数通网络：网络技术、技术方案
解决方案
该部分笔记将记录与数据通信相关的协议，而以网络管理相关的协议将不在该部分记录；
Layer 3: Network Layer（OSI model & TCP/IP model）
Internet Layer Protocols: https://en.wikipedia.org/wiki/Category:Internet_layer_protocols
功能：定义逻辑地址：实现数据从源到目的地址的转发；
协议：ICMP，IGMP，IP，VRRP，
Layer 2: Data Link Layer（OSI model & TCP/IP model）
Link Protocols: https://en.wikipedia.org/wiki/Category:Link_protocols
功能：将分组数据封装成帧；在数据链路上实现数据的点到点、点到多点的数据通信；差错检测；
协议：PPPoE、Ethernet、PPP、EVPN, Ethernet VPN、MPLS, Multiprotocol Label Switching
Layer 1: Physical Layer（OSI model & TCP/IP model）
功能：在媒介上传输比特流；提供机械的、电气的规约；[……]
「NETWORKING」- LAYER 1，物理层，互联
物理层：比特流传输
数据单元：比特流，Bitstream；
在 Bit 中，具有以下字段： 1）FCS：CRC 校验，保证数据完整性； 2）Preamble：前导码，告诉设备进入同步状态； 3）SFD：帧首定界符，指示帧的开始；[……]
「NETWORK-HARDWARE」- 网络设备，数据处理，网络硬件
问题描述
世界虽然很大，但是当前网络的高速发展使得我们足不出户都能了解全球最新的资讯、随时和朋友与同事交流、网络极大的丰富人们的沟通和生活。 未来将会是一个万物互联的智能世界。
网络的搭建离不开网络设备，物理连接，以及设备之间的多种协议。其中在实现网络互通时，最常见的网络设备是路由器和交换机。 如今在各种级别的网络随处可见各种低、中、高端的路由器、交换机，种类繁多，这些不同种类的设备内部是如何工作、处理数据报文的呢？
该笔记将记录：路由器、交换机为例学习网络设备的工作机制、报文转发流程。
解决方案
网络基础设施由交换机、路由器、防火墙等构成，这些设备日复一日地接收、发送数据，从一个接口收到的数据如何经过设备内部转发到另外一个接口？设备有哪些组件构成？这些组件如何协同工作？。
每台网络设备存在独立的控制平面、转发平面、监控平面： 1）控制平面，负责系统的协议处理、路由运算、业务调度等， 2）转发平面负责转发数据，实现各个业务模块之间的报文交互。 3）监控平面负责系统的环境监控，以保证系统的安全稳定运行。
高端框式设备各个平面以不同的板卡形式存在，接口板、交换网板实现转发平面的功能，主控板实现控制平面的功能，监控板实现监控平面的功能。
高端框式设备采用“硬转发”，报文的转发由接口板直接完成，无需控制平面参与，报文转发效率极高。
网络设备：常见设备
How the Internet Works Under the Hood | by Kyle McCurley | Better Programming
交换机可以隔离冲突域，路由器可以隔离广播域，这两种设备在企业网络中应用越来越广泛。
集线器（Hub）
主机发送数据时，其他主机不能发送数据。 数据会被所有人收到，Hub 会将数据包发往每个连接的设备
交换机，Switch，终端设备的网络接入
多个主机能够同时发送数据，数据不会被所有主机收到。Switch 会将数据包发送给 MAC 地址匹配的设备。 此时，相同广播域，所有主机都会收到广播数据。
路由器，Router，网络之间的数据转发
路由器能够分割广播域，减小广播域。
广播域：一个广播流量能够影响的设备；一个网络为一个广播域；
隔离广播域：路由器，使经过交换机的广播报文都在某个网络内部；
防火墙，Firewall，网络之间的安全通信
无线设备，Wireless Device，无线终端接入设备
在大型网络中，通常使用 FIT AP + AC 方式管理无线网络。
网络设备：逻辑构架
网络设备从逻辑上可以分为以下三个平面：数据平面、控制管理平面、监控平面。
监控[……]
「NETWORK-SWITCH」- 概念术语
交换机背板（Backplane board）
What is a Backplane? A Network Backplane Throughput Primer | Auvik
背板为交换机业务板卡和控制板卡提供连接的槽位，相当于电脑的主板，各个板卡之间通过背板的总线进行通讯。 主要用于 接口板和主控 以及 接口板间 的板间通信，平时所说的 HG 链路也就是走的那里。
通常只有框式交换机才有背板 主控板：框式交换机一般有两个主控板，一个当前运行，一个做备份。 接口板：其他槽位就插入接口板等。 当主控板和接口板插进交换机时，单板和机框接触的地方就是背板的接口。
交换机的背板带宽（背板容量）
数据不是靠背板转发的，而是靠交换矩阵（高端路由器）或是交换芯片（低端交换机）来转发的，一般来说背带宽是指业务板（接口板）连接到交换矩阵的带宽，或者说交换机接口处理器（或接口卡）和数据总线间所能吞吐的最大数据量。
背板带宽标志交换机总的数据交换能力，单位为Gbps，也叫交换带宽，一般的交换机的背板带宽从几Gbps到上百Gbps不等。一台交换机的背板带宽越高，所能处理数据的能力就越强，但同时设计成本也会越高。
背板带宽一般为插满业务板卡总端口带宽的2倍(即双工)。简单说就是交换机能够同时转发的最大流量。
背板带宽资源的利用率与交换机的内部结构息息相关。
交换机的内部结构类型
主要有以下几种：
共享内存结构：这种结构依赖中心交换引擎来提供全端口的高性能连接，由核心引擎检查每个输入包以决定路由。这种方法需要很大的内存带宽、很高的管理费用，尤其是随着交换机端口的增加，中央内存的价格会很高，因而交换机内核成为性能实现的瓶颈；
交叉总线结构：它可在端口间建立直接的点对点连接，这对于单点传输性能很好，但不适合多点传输；
混合交叉总线结构：这是一种混合交叉总线实现方式，它的设计思路是，将一体的交叉总线矩阵划分成小的交叉矩阵，中间通过一条高性能的总线连接。其优点是减少了交叉总线数，降低了成本，减少了总线争用；但连接交叉矩阵的总线成为新的性能瓶颈。
参考文献
Different Types of Network Switches – Cisco 交换机背板是什么？请勿介绍交换机背板容量，只介绍什么是背板。_百度知道 背板宽带_百度百科 背板容量_百度百科[……]
「NETWORK-SWITCH」- 固定配置交换机，Fixed-configuration Switch，华为：盒式交换机
网络设备：盒式
不同于框式设备，盒式设备的各个业务模块并不是独立的硬件模块，而是集成在一个框内。[……]