用户社区 on 浙江物链网络科技有限公司

从事IDC代理业务相关所需的名词解释

info@wlstack.com (物链网络) — Sun, 22 Jun 2025 00:00:00 +0000

计费模式相关

术语	解释
95计费	每月按带宽峰值第95百分位值计费（去掉最高5%的峰值点），常用于大流量业务。
日95月平	每日取95峰值，再计算当月每日平均值的计费模式（比传统95计费成本更低）。
包端口	固定租用物理端口（如10G端口），按端口容量而非实际流量计费。
补贴端口	运营商为吸引客户提供的低价或免费端口（通常需承诺长期合作或达到流量门槛）。
配比端口	主端口与备份端口的绑定套餐（如主用10G+备用1G，或主备冗余端口或IDC端口配多少城域网端口，或IDC计费端口配多少免费端口）。
酬金	运营商给代理商的销售返佣（如机柜酬金、专线酬金、CDN代销订单返点）。

资源类型

术语	解释
80资源	支持HTTP 80端口的服务器（用于常规网页服务）。
非80资源	仅支持非80端口（如443/8080）的服务器（常用于视频、下载等业务）。
云主机资源	基于虚拟化的云计算主机（弹性扩展，按需付费）。一般特指天翼云、移动大云这些拿云主机跑PCDN的
高防	提供DDoS防护的服务器（防御能力可达Tbps级）。
源站	业务数据的原始服务器（CDN从此节点拉取内容）。
裸纤	运营商提供的纯物理光纤直连（无协议转换，延迟最低）。

网络架构

术语	解释
城域网	运营商互联网专线。
BGP	多线路智能路由协议（实现电信/联通/移动三网自动选最优路径）。
三线	同时接入电信+联通+移动三家运营商网络。
双线/多线	接入两家（双线）或多家（多线）运营商。
OTN	光传输网络（提供大带宽、低延迟的底层光缆资源）。
三线单IP	三网融合但共用一个IP（通过BGP实现智能解析，BGP为主动广播宣告IP），或运营商地址代为广播。
三线三IP	三网独立IP（需用户自行配置DNS调度）。

CDN技术

术语	解释
CDN	内容分发网络：将内容缓存到边缘节点，加速用户访问。
PCDN	P2P+CDN混合技术，用家宽汇聚接服务器或单独接路由器/盒子跑cdn。
ACDN	用接入城域网大带宽的物理机群按虚拟机或物理机或k8s api给互联网top客户跑CDN。
融合CDN	整合多家CDN厂商资源的调度平台（自动选择最优服务商）。
三网CDN	支持电信/联通/移动三网覆盖的CDN服务。
调度	控制业务流量，确保低价端口跑满，高价端口只跑95。
削峰调度	在多个节点之间或端口之间控制业务流量，确保只跑95。

测试与运营

术语	解释
测试期	资源开通后的免费试用阶段（通常7-30天）。个别运营商可按端口批次开关多次测试。
测试机	用于业务上线前到测试服务器。
压测	压力测试：模拟高并发测试带宽是否配足额。
单线测试机	仅接入单运营商（如电信）的测试服务器。
三线测试机	接入三网线路的测试服务器。
流量误差	运营商计费流量与用户监控流量的差异（行业允许±3%）。
抠流量	通过技术手段（如压缩/去冗余）降低计费流量。
流量倒挂	入流量 > 出流量（CDN场景中通常出流量更大，倒挂需排查异常）。
三网测试	同时测试电信/联通/移动三网的访问质量。

其他行话

术语	解释
跑异网	流量跨运营商传输（如电信用户访问联通服务器，质量可能下降）。
1024	带宽单位换算：1Gbps = 1024Mbps。
3个1024	指三次1024，即1Gbps=1024mbps=1024x1024kbps=1024x1024x1024bitps
天翼云CDN	中国电信旗下的CDN服务。
代下单	通过代理商购买运营商资源（常用于无直接合作资质的企业）。
IP备案	将服务器IP绑定到已备案域名（国内业务强制要求）。

一、网络覆盖与结算

术语	解释
跨省	业务流量跨越省级行政边界（如北京→上海），涉及跨省结算费（运营商间结算成本高）
跨地市	流量在同一省内跨城市需要结算
结出	运营商向其他运营商输出流量（需支付结算费）
结入	运营商接收其他运营商流量（获得结算收入）
净结入	结入金额 - 结出金额（正值表示结算盈利）
跨省比例	业务流量中跨省流量的占比（通常要求≤30%以控制成本）

二、机房基础设施

术语	解释	技术细节
机房等级	国标GB50174分级：• A级：容错型（双路供电+备份）• B级：冗余型• C级：基础型	金融/政企必选A级，Web服务可选B级
自有机房	运营商自建并管理的机房（如移动南方基地）	稳定性高，资源调配快
合作机房	第三方建设，运营商租用机柜的资源池	成本低，扩容灵活
PUE	电能使用效率 = 总耗电 / IT设备耗电（理想值≈1.3）	PUE>1.8属高能耗，北上广深要求≤1.4
机柜功率	单机柜供电能力（标准4-6kW，高密柜可达10-20kW）	GPU算力集群需≥10kW
风冷	传统空调制冷（适用于中低密度机柜）	成本低，维护简单
液冷	液体循环冷却（用于GPU服务器等高密度场景，降温效率提升50%）	算力中心标配，PUE可降至1.1以下
柜电分离	电费与机柜租费分开计费（避免捆绑加价）	大客户压降成本常用模式
机柜托盘	承托服务器的滑轨支架（标准深度42U/48U）	影响服务器部署密度

三、光缆与传输

术语	解释	关联概念
出纤	从机房向外敷设的光纤（用户向运营商购买）	需明确纤芯数量和路由
进纤	接入机房的光纤资源（运营商提供）	通常含熔接配线服务
光交箱	光纤交接箱（室外线路与机房内线的转接点）	跳纤操作核心设备
波分	波分复用技术（单纤传输多路信号，提升带宽）	骨干网必用，单纤可达192*100Gbps
骨干网络	国家级/省级核心传输网（中继带宽≥100Gbps）	三大运营商自有拓扑
骨干出口局	骨干网在城市的互联节点（如北京三元桥、上海南汇）	多线BGP机房优先选址点
离岸出口	跨境网络出口（如香港、绥芬河节点）	免备案业务常用
双路由	关键链路配置物理分离的两条路径（防单点中断）	金融/政企强制要求

四、工程与运维

术语	解释	操作要点
机房工勘	机房环境实地勘察（承重/电力/制冷/走线等）	上架前必备流程，输出《工勘报告》
割接	业务从旧系统迁移至新系统（常在凌晨进行，需备案）	风险操作！需备回滚方案
过点费	流量经过第三方网络节点的转接费用（如A→B需经C网，则向C付费）	专线报价需确认是否含过点费
配虚机	分配虚拟测试机（临时用于业务验证）	测试期免费提供
账期(T+2)	上月费用延后2月结算（如3月账期在5月支付）	运营商常用结算周期

五、流媒体与算力

术语	解释	技术逻辑
拉流	客户端从服务器拉取音视频流（如直播观众端行为）	与“推流”（主播端）对应
算力	数据处理能力（单位：TFLOPS/GPU卡）	1张A100≈20TFLOPS（FP32精度）
包头系数	网络传输中IP/TCP包头占有效数据的比例（通常≈1.15-1.2）	计算带宽需求：实际带宽 = 业务流量 × 包头系数
调度	动态分配资源（如CDN将用户请求导至最优节点）	核心算法：基于时延/负载/成本

六、端口与资源组合

术语	解释	成本策略
端口组合	多端口绑定套餐（如10个10G IDC端口+5个10G城域网端口）	提升可靠性，降低备份成本
第三方机房	非运营商自建机房（如万国数据、世纪互联）	议价空间大，但网络质量依赖运营商接入

Centos7 升级gcc/glibc/make/cmake

info@wlstack.com (物链网络) — Fri, 19 Jan 2024 00:00:00 +0000

前言

眼瞅着Centos7的生命周期即将终结，系统默认的gcc/glibc版本又太低，而事实上，目前为止，因升级gcc/glibc导致的悲剧又依然不少见，特别是glibc从升级到宕机，几乎每隔一段时间就可以看见有网友嗝屁。所以，这里把这个基础操作步骤写出来，做个小记。

操作有风险，执行需谨慎

本人也曾经因升级glibc出过事故，后因算法需求，在多次练习后已是信手拈来，但是自己的升级过程不够规范和详细，所以在写本日记的时候，参考（ctrl+c/ctrl+v）了大神的这篇文章: https://chandrameenamohan.medium.com/building-nvidia-triton-inference-server-from-scratch-for-tensorflow-backend-873ef0a1f7f3 来总结此文。该文章的各项步骤均已经过本人亲自验证可行。

升级前的准备

验证当前版本：

gcc -v
ldd --version

确定升级的版本 gcc4.8.5–>gcc9.3.0 glibc2.17–>glibc2.29
升级路径

升级和验证

先安装依赖

包名	用途
wget	用于从网络下载文件
gcc	C/C++ 编译器
gcc-c++	C++ 编译器
zlib-devel	zlib 开发库
libcurl-devel	libcurl 开发库
openssl-devel	OpenSSL 开发库
bzip2-devel	bzip2 开发库
gmp-devel.x86_64	GNU Multiprecision Library 开发库（x86_64）
mpfr-devel.x86_64	MPFR Library 开发库（x86_64）
libmpc-devel.x86_64	MPC Library 开发库（x86_64）
libSM-devel.x86_64	X.Org SM 库开发库（x86_64）
libxml2-devel	libxml2 库开发库
gcc-gfortran.x86_64	Fortran 编译器（x86_64）
autoconf	自动化配置脚本生成器，用于生成 Makefile 文件
automake	自动化 Makefile 生成器，用于生成 Makefile.in 文件
boost-devel	Boost 库的开发包，用于开发 C++ 程序
make	构建工具，用于自动化软件编译、安装、测试等工作
patchelf	用于修改 ELF 文件的符号表和动态链接库依赖项
bison	语法分析器生成器，用于生成 C 语言语法分析器

大概是这些依赖，yum 安装即可，建议在yum安装这些依赖之前，都安装一下epel库。

debian12 编译frankenphp

info@wlstack.com (物链网络) — Fri, 19 Jan 2024 00:00:00 +0000

前言

FrankenPHP 是建立在 Caddy Web 服务器之上的现代 PHP 应用程序服务器。

FrankenPHP 凭借其令人惊叹的功能为你的 PHP 应用程序提供了超能力：早期提示、worker 模式、实时功能、自动 HTTPS、HTTP/2 和 HTTP/3 支持……

FrankenPHP 可与任何 PHP 应用程序一起使用，并且由于提供了与 worker 模式的集成，使你的 Symfony 和 Laravel 项目比以往任何时候都更快。

FrankenPHP 也可以用作独立的 Go 库，将 PHP 嵌入到任何使用 net/http 的应用程序中。

本质来说，frankenphp是通过cgo来跑php的！

至于快/慢问题，目测是比fast-cgi/php-fpm快的。

编译前准备

安装必要的依赖

apt-get install libbrotli-dev \ libsnmp-dev
libxml2-dev
libsqlite-dev
libsnmp-dev
libxml2-dev
libsqlite3-dev
libzstd-dev
liblz4-dev
libjpeg-dev
libpng-dev
libpcre3-dev
libmcrypt-dev
libgd-dev
libbz2-dev
libonig-dev
libpq-dev
libreadline-dev
libsodium-dev

编译php

./configure --prefix=/usr --libdir=/usr/local/lib --enable-embed=static --enable-static --enable-zts --disable-shared --disable-cgi --disable-fpm --disable-phpdbg --with-config-file-path=/etc/frankenphp --with-config-file-scan-dir=/etc/frankenphp/php.d --enable-zend-max-execution-timers --with-snmp --enable-bcmath --enable-mbstring --enable-ctype --enable-dom --enable-session --enable-simplexml --enable-sockets --enable-tokenizer --enable-xml --enable-xmlreader --enable-xmlwriter --enable-soap --enable-opcache --enable-pdo --with-pdo-mysql --with-pdo-pgsql --with-pgsql --with-zip --with-curl --with-zlib --with-readline --with-iconv --with-libxml --with-openssl --with-bz2 --enable-gd --with-jpeg --with-webp --with-freetype --with-sodium --enable-sysvsem --enable-sysvshm --enable-sysvmsg --enable-pcntl --enable-shmop --enable-phar
make -j $(nproc)
make install

** 注意，我这里启用了一些扩展，比如snmp，我寄望是一些网络监控服务，诸如cacti/zabbix/librenms也能过痛过这个方式来跑； **

nginx 1.25.0 pagespeed 安装

info@wlstack.com (物链网络) — Thu, 18 Jan 2024 00:00:00 +0000

前言

遵从来自20世纪的呼唤，最近重新开始研究单体应用的极致的性能优化，在web应用加速来说，google和nginx曾经一度引领风骚，pagespeed+nginx的组合，一度成就了yottta这样被google花了5亿美金收购的公司，号称对web应用，实现了页面精简、html/css压缩，动态加速等。而这样的东西自从2018年后，似乎突然就不被重视了。随着云和微服务的兴起，应用被拆分得越来越细，以至于，不再有人care在http1.0/1.1时代的C10K、C100K这样的挑战了。性能不够，机器来凑，尤其是，使用云和k8s之后，没有了直接的硬件投入，起个服务和应用，api调用一下，鼠标点一点，几百上千的虚拟机或pod就起来了，而容器则动则几万几十万个，而这样的情况，短时间的成本可能已经在“人比机器贵”的黄金时代来说，不再引人注目了。长此以往，特别到了疫情后，大家的口袋都没钱的时候，才发现，原来不知不觉，在云上已经花了这么多钱，所以，鼓吹下云也好，继续上云也罢，理念的东西都不重要，重要的，还是经济效益，于是，单体应用的性能，理应重新得到重视。而这时候，我才发现，nginx似乎也不再受欢迎，好多人都要换到caddyserver去，pagespeed更是几乎没什么人用了,连明日黄花，可能都算不上了。。毕竟现代前端框架，自身在build的时候，已经是各种裁剪优化了,甚至于，倾向于搞ssr（server side render）这样的歪门邪道（当然，一段时间是因为框架对搜索引擎过于不友好，搞出来的web，搜索引擎都收录不了。。哪来的用户，哪来的业务），服务器的计算资源，始终是有限的，而客户端，却是随着用户数增长而增长…最主要的一点，服务器，是需要付费的，而用户侧的算力，是免费的. 好了，废话说了很多，很显然，在这个时候，来折腾这些一度落寞的玩意，可能会费时费力。（有人会叫你去白嫖比人打包好的docker镜像或deb包），而我决定自力更生，丰衣足食。

安装环境

OS:Centos 7.9 GCC:4.8.5 NGINX:1.25.0 PAGESPEED(NPS):1.13.35.2

依赖：

包名	用途
wget	用于从网络下载文件
gcc	C/C++ 编译器
gcc-c++	C++ 编译器
zlib-devel	zlib 开发库
libcurl-devel	libcurl 开发库
openssl-devel	OpenSSL 开发库
bzip2-devel	bzip2 开发库
gmp-devel.x86_64	GNU Multiprecision Library 开发库（x86_64）
mpfr-devel.x86_64	MPFR Library 开发库（x86_64）
libmpc-devel.x86_64	MPC Library 开发库（x86_64）
libSM-devel.x86_64	X.Org SM 库开发库（x86_64）
libxml2-devel	libxml2 库开发库
gcc-gfortran.x86_64	Fortran 编译器（x86_64）
libjpeg-turbo-devel.x86_64	libjpeg-turbo 库开发库（x86_64）
openjpeg-devel	OpenJPEG 库开发库
libpng12-devel	libpng 库开发库
libtiff-devel	libtiff 库开发库
cmake3.x86_64	CMake 3 编译系统（x86_64）
libtools-devel	libtools 开发库
yum-utils	yum 实用工具
libffi-devel	libffi 库开发库
jemalloc-devel.x86_64	jemalloc 内存分配器开发库（x86_64）
jasper-devel	JasPer 库开发库
tbb-devel	Threading Building Blocks 库开发库
libdc1394-devel	libdc1394 库开发库
gstreamer-devel.x86_64	GStreamer 库开发库（x86_64）
blosc-devel	Blosc 库开发库
libaec-devel	libaec 库开发库
brotli-devel	Brotli 库开发库
giflib-devel	giflib 库开发库
gtk2-devel	GTK+ 2 库开发库
libaio-devel	libaio 库开发库
libsqlite3x-devel.x86_64	libsqlite3x 库开发库（x86_64）
make	构建工具
eigen3-devel	Eigen3 线性代数库开发库

安装

安装依赖

yum install epel-release.noarch -y
yum install wget gcc gcc-c++ zlib-devel libcurl-devel openssl-devel bzip2-devel gmp-devel.x86_64 mpfr-devel.x86_64 libmpc-devel.x86_64 libSM-devel.x86_64 libxml2-devel gcc-gfortran.x86_64 libjpeg-turbo-devel.x86_64 openjpeg-devel.x86_64 libpng12-devel.x86_64 libtiff-devel cmake3.x86_64 libtool-devel yum-utils libffi-devel jemalloc-devel.x86_64 jasper-devel.x86_64 tbb-devel libdc1394-devel gstreamer-devel.x86_64 blosc-devel libaec-devel brotli-devel.x86_64 giflib-devel.x86_64 gtk2-devel libaio-devel libsqlite3x-devel.x86_64 make eigen3-devel libpcre3-devel

下载安装包并解压：

 wget -O nps.zip https://github.com/apache/incubator-pagespeed-ngx/archive/71e24c1c47113acb5924d8cb523d572b376e9dd0.zip && unzip nps
wget http://nginx.org/download/nginx-1.25.0.tar.gz
wget -O psol.tar.gz https://dl.google.com/dl/page-speed/psol/1.13.35.2-x64.tar.gz

nginx编译注意点

LD_LIBRARY_PATH=../incubator-pagespeed-ngx-${PAGESPEED_VERSION}/usr/lib:/usr/lib 指定LD_LIBRARY_PATH到incubator-pagespeed-ngx-71e24c1c47113acb5924d8cb523d572b376e9dd0，以便编译pagespeed，71e24c1c47113acb5924d8cb523d572b376e9dd0即为上文下载的对应版本的pagespeed版本解压后的目录

Centos7 cacti spine php74 nginx安装配置

info@wlstack.com (物链网络) — Fri, 22 Sep 2023 00:00:00 +0000

cacti是什么

Cacti是一款功能完整的网络图形化解决方案，Cacti旨在利用RRDtool的数据存储以及图形化功能来给广大安全研究人员提供以下功能性帮助：

远程和本地数据收集；
设备扫描与发现；
设备与图形创建自动化；
自定义数据收集方法；
用户、组和域访问控制；

所有的这些功能都封装在一个直观并易于使用的用户界面之中，而这种特性对于局域网安装配置以及包含数千台设备的复杂网络都有实际意义。

本项目是Ian Berry于2000年初创建的一个高中研究项目，但目前已经发展成为上千万公司以及网络安全爱好者用于监控和管理他们企业网络以及数据中心的最佳解决方案了。

Centos 7 安装 cacti

安装基础依赖和数据库

基础依赖： 先安装对应的yum repo，避免部分依赖rpm包找不到

yum install epel-release.noarch -y
yum install https://rpms.remirepo.net/enterprise/remi-release-7.rpm -y

注意，这里使用了基于remi库封装的php rpm包，所以在后续使用的时候，需要考虑remi库 rpm包安装的路径问题，否则可能出现cmd.php/poller.php运行失败的问题。接下来安装基础库：

yum install wget gcc gcc-c++ zlib-devel wget libcurl-devel openssl-devel bzip2-devel gmp-devel.x86_64 mpfr-devel.x86_64 libmpc-devel.x86_64 libSM-devel.x86_64 libxml2-devel gcc-gfortran.x86_64 bzip2-devel libjpeg-turbo-devel.x86_64 openjpeg-devel.x86_64 libpng12-devel.x86_64 libtiff-devel cmake3.x86_64 autoconf automake libtool yum-utils libSM-devel.x86_64 bzip2-devel libffi-devel jemalloc-devel.x86_64 gperftools-devel.x86_64 jasper-devel.x86_64 libxml2-devel tbb-devel libdc1394-devel gstreamer-devel.x86_64 blosc-devel libaec-devel brotli-devel.x86_64 giflib-devel.x86_64 gtk2-devel libaio-devel libsqlite3x-devel.x86_64 gperftools-devel.x86_64 make eigen3-devel ntp ntpdate perl-devel perl-CPAN perl-YAML fontconfig ttmkfdir -y

看得出来，我们安装了很多图像图像乃至视频的包。如果觉得多余，可以把gstream相关不安装，不过ntp/ttmk这些时间、字体相关的，还是装一下。 2. 安装数据库然后我们来安装数据库服务器。这里我们选择安装mysql5.7。

librenms部署到cloudflare

info@wlstack.com (物链网络) — Wed, 17 May 2023 00:00:00 +0000

Librenms是什么

LibreNMS是一个开源的网络监控和自动化工具。它可以帮助管理员监控和管理他们的网络设备、服务器和应用程序。LibreNMS提供了一个综合的平台，用于监控网络设备的性能、可用性和健康状况，以及生成报告和警报。它支持SNMP（Simple Network Management Protocol）来收集设备的指标和状态信息，并提供了一个用户友好的Web界面，供管理员查看和分析监控数据。

LibreNMS具有许多功能，包括实时图表和可视化，用于显示网络设备的性能和趋势，以及提供历史数据的存档。它支持自动发现网络设备和应用程序，并提供基于规则的警报和通知功能，以便管理员在出现问题时及时采取行动。此外，LibreNMS还提供了强大的API，可以与其他系统和工具集成，以实现自动化和定制化的监控和管理任务。

librenms的架构

LibreNMS是使用PHP语言开发的，基于Laravel框架构建的网络监控系统。Laravel是一个流行的开源PHP框架，它提供了许多工具和组件，用于快速开发高质量的Web应用程序。

使用Laravel作为开发框架，LibreNMS能够充分利用Laravel提供的功能和特性，包括路由管理、数据库抽象层、会话管理、认证和授权、模板引擎等。这些功能使得LibreNMS的开发过程更加高效、可维护和可扩展

为什么部署到cloudflare

Cloudflare 是一家提供内容分发网络服务、DDoS 保护、互联网安全性和分布式域名服务器服务的公司。其服务旨在保护和加速任何互联网应用程序，而无需更改应用程序的代码。以下是 Cloudflare 的主要功能：

内容分发网络 (CDN): Cloudflare 的 CDN 通过其全球数据中心网络存储网站的静态内容，从而使访问者能够从最近的数据中心获取内容，加速页面加载速度。

DDoS 保护: Cloudflare 可以识别并吸收大量的请求，从而保护网站不受恶意攻击。

Web 安全性: Cloudflare 提供 Web 应用程序防火墙 (WAF)、安全套接字层 (SSL) 加密等功能，以增强网站的安全性。

智能路由: Cloudflare 的 Argo Smart Routing 能够确保用户的请求通过最快的路径到达目的地。

部署到cloudflare的优势：

安全性: LibreNMS 作为一个网络管理和监控工具，可能会面临各种网络攻击，特别是 DDoS 攻击。Cloudflare 可以为 LibreNMS 提供额外的安全层，保护它免受这些攻击。
可访问性: 使用 Cloudflare，即使 LibreNMS 的主服务器出现问题，用户仍然可以通过 Cloudflare 的缓存数据访问 LibreNMS 的某些信息。
性能: Cloudflare 的 CDN 可以加速 LibreNMS 的在全球范围内的访问，特别是当你拥有一个跨地域的协作或合作的时候，确保你和你的合作伙伴能够快速访问LibrenNMS以获得网络用量和简况状况显得尤为重要。
简化配置: 对于那些不熟悉web服务安全配置的用户，使用 Cloudflare 可以简化 LibreNMS 的安全和性能优化配置，确保LibreNMS的相对安全性和管理的便捷性。

内核优化参数之2-网友的内核引导参数

info@wlstack.com (物链网络) — Fri, 10 Mar 2023 00:00:00 +0000

参数说明

Linux内核参数的配置对于性能的影响是巨大的。可以通过修改/etc/sysctl.conf文件来调整。下面是每个参数的简要说明：

参数	说明
loglevel=3	设置内核打印级别为3
selinux=0	禁用 SELinux
audit=1	启用系统审计功能
rd.systemd.show_status=auto	启用 Systemd 系统启动状态
rd.udev.log_priority=3	设置 udev 日志级别为3
systemd.unified_cgroup_hierarchy=false	禁用 Systemd 统一 cgroup 层级
systemd.legacy_systemd_cgroup_controller=false	禁用旧版 Systemd cgroup 控制器
scsi_mod.use_blk_mq=1	使用多队列 I/O 调度器（blk-mq）
crashkernel=384M-2G:64M,2G-:128M	为内核启动设置的保留物理内存大小
workqueue.power_efficient=0	禁用内核 power_efficient 工作队列优化
domain init_on_free=0, init_on_alloc=0	禁用 NUMA 内存分配初始化
cma=128M	设置 Contiguous Memory Allocator（CMA）大小
vsyscall=none	禁用 vDSO/vsyscall
nosoftlockup	禁用软锁定检测
mce=off	禁用机器检查异常（MCE）
threadirqs	启用中断线程（threaded interrupt）
noresume	禁用系统挂起功能
nmi_watchdog=0	禁用 NMI 监视器
vt.cur_default=50	设置终端 VT 缓冲区大小
transparent_hugepage=never	禁用透明大页（Transparent Huge Pages，THP）
cgroup_enable=memory	启用 cgroup 内存限制
cgroup_memory=nokmem	禁用 KSM 和 THP
swapaccount=1	启用交换空间统计
nf_conntrack.acct=0	禁用 netfilter 连接追踪计数
log_buf_len=2M	设置内核日志缓冲区大小
intel_pstate=disable	禁用 Intel P-state 驱动
processor.max_cstate=0	禁用处理器 C 状态
intel_idle.max_cstate=0	禁用 Intel Idle
thermal.off=1	禁用温度传感器
pci=realloc	启用 PCI 设备热插拔支持
pcie_aspm=off	禁用 PCIe ASPM 支持
cpufreq.off=1	禁用 CPU 频率调节功能
idle=halt	使用 halt 代替 idle
net.ifnames=0	禁用预测命名接口
biosdevname=0	禁用预测 BIOS 命名接口
mitigations=off	禁用针对特定 CPU 安全漏洞的补丁
noibrs	禁用间接分支预测限制（Indirect Branch Restricted Speculation）
nopti	禁用特权级别转换限制（Privilege Level Translation Tables）
l1tf=off	禁用 L1 终端失效漏洞（L1 Terminal Fault）
nomodeset	禁用内核模式设置
nospec_store_bypass_disable	禁用处理器存储旁路漏洞的修复
noibpb	禁用分支预测条目保护（Indirect Branch Prediction Barrier）。
spectre_v2_user=off	禁用用户空间的漏洞修复
spectre_v2=off	禁用针对 Spectre Variant 2 漏洞的修复
kvm-intel.vmentry_l1d_flush=never	禁用 L1D Flush 特性，减少 L1D Cache 映射切换的开销
no_timer_check	禁用内核检查定时器是否过期，可减少部分系统调用的开销
noreplace-smp	禁用热插拔 CPU
kvm-intel.nested=1	启用 KVM Nested 虚拟化
nosync	禁用 CPU 忙等待
iommu.strict=0	禁用 IOMMU 严格模式
intel_iommu=on	启用 Intel VT-d IOMMU
amd_iommu=on	启用 AMD IOMMU
cryptomgr.notests	禁用内核加密 API 的测试模式
rcu_nocbs=0-64	设置 RCU 操作不会影响 CPU 0 到 CPU 64 之间的性能
rcupdate.rcu_expedited=1	优先处理 RCU 更新操作，以减少延迟
rcutree.kthread_prio=2	设置 RCU 的内核线程的优先级为 2
skew_tick=1	启用 CPU 偏移时钟

参考示例

loglevel=3 selinux=0 audit=1 rd.systemd.show_status=auto rd.udev.log_priority=3 systemd.unified_cgroup_hierarchy=false systemd.legacy_systemd_cgroup_controller=false scsi_mod.use_blk_mq=1 crashkernel=384M-2G:64M,2G-:128M workqueue.power_efficient=0 domain init_on_free=0, init_on_alloc=0 cma=128M vsyscall=none nosoftlockup mce=off threadirqs noresume nmi_watchdog=0 vt.cur_default=50 transparent_hugepage=never cgroup_enable=memory cgroup_memory=nokmem swapaccount=1 nf_conntrack.acct=0 log_buf_len=2M intel_pstate=disable processor.max_cstate=0 intel_idle.max_cstate=0 thermal.off=1 pci=realloc pcie_aspm=off cpufreq.off=1 idle=halt net.ifnames=0 biosdevname=0 mitigations=off noibrs nopti l1tf=off nomodeset nospec_store_bypass_disable noibpb spectre_v2_user=off spectre_v2=off kvm-intel.vmentry_l1d_flush=never no_timer_check noreplace-smp kvm-intel.nested=1 nosync iommu.strict=0 intel_iommu=on amd_iommu=on cryptomgr.notests rcu_nocbs=0-64 rcupdate.rcu_expedited=1 rcutree.kthread_prio=2 skew_tick=1

内核优化参数记录

info@wlstack.com (物链网络) — Tue, 07 Mar 2023 00:00:00 +0000

参数说明

Linux内核参数的配置对于性能的影响是巨大的。可以通过修改/etc/sysctl.conf文件来调整。下面是每个参数的简要说明：

参数名	参数值	说明	建议
vm.swappiness	0	控制内核将哪些页面交换到磁盘以释放内存。	如果您的系统拥有足够的内存容量，建议将这个参数的值设置为 0，以减少交换分区的使用。
vm.panic_on_oom	1	控制系统在内存不足时是否会宕机。	如果您的系统拥有足够的内存容量，建议将这个参数的值设置为 1，以确保系统不会因为内存不足而出现问题。
kernel.panic	10	控制系统在内核崩溃时重新启动的时间。	如果您的系统存在内核崩溃的问题，建议将这个参数的值设置得较小，以便快速重新启动系统。
fs.file-max	65536	控制内核允许打开的文件数的最大数量。	如果您的应用程序需要大量的文件句柄，建议增加这个参数的值。
kernel.sysrq	0	控制内核是否允许使用 SysRq 键来执行紧急操作。	如果您不需要使用 SysRq 键，建议将这个参数的值设置为 0，以增加系统的安全性。
kernel.printk	5 4 1 7	控制内核消息的打印级别。	如果您不需要详细的内核消息，建议将这个参数的值设置为 3 4 1 3，以减少内核消息的频率和级别。
kernel.softlockup_panic	1	控制系统在发生软锁定时是否宕机。	如果您的系统存在软锁定的问题，建议将这个参数的值设置为 1，以便快速重新启动系统。
net.ipv4.conf.default.rp_filter	0	控制反向路径检测。	如果您的系统需要进行反向路径检测，建议将这个参数的值设置为 1。
net.ipv4.ip_forward	1	控制 IP 转发功能。	如果您的系统需要使用 IP 转发功能，建议将这个参数的值设置为 1。
net.core.netdev_max_backlog	40960	控制网络设备接收队列的长度。	如果您的系统的网络流量较大，建议增加这个参数的值。
net.core.optmem_max	921600	控制内核套接字缓冲区的最大大小。	如果您的系统的网络流量较大，建议增加这个参数的值。
net.core.rmem_default	2097152	控制内核套接字接收缓冲区的默认大小。	如果您的系统的网络流量较大，建议增加这个参数的值。
net.core.rmem_max	8388608	内核套接字接收缓冲区的最大大小。	如果您的系统的网络流量较大，建议增加这个参数的值。
net.ipv4.tcp_rmem	4096 87380 8388608	内核套接字 TCP 接收缓冲区的最小、默认、最大大小。	如果您的系统的网络流量较大，建议增加这些参数的值。
net.ipv4.tcp_wmem	4096 87380 8388608	内核套接字 TCP 发送缓冲区的最小、默认、最大大小。	如果您的系统的网络流量较大，建议增加这些参数的值。
net.ipv4.udp_mem	8388608 12582912 16777216	内核套接字 UDP 缓冲区的最小、默认、最大大小。	如果您的系统的网络流量较大，建议增加这些参数的值。
net.ipv4.udp_rmem_min	65536	内核套接字 UDP 接收缓冲区的最小大小。	如果您的系统的网络流量较大，建议增加这个参数的值。
net.ipv4.udp_wmem_min	65536	内核套接字 UDP 发送缓冲区的最小大小。	如果您的系统的网络流量较大，建议增加这个参数的值。
net.ipv4.tcp_no_metrics_save	1	控制内核是否保存 TCP 的性能指标。	如果您不需要保存 TCP 的性能指标，建议将这个参数的值设置为 1，以减少系统的 I/O 负载。
net.ipv4.icmp_echo_ignore_broadcasts	1	控制内核是否响应广播地址的 ICMP 请求。	如果您不需要响应广播地址的 ICMP 请求，建议将这个参数的值设置为 1，以增加系统的安全性。
net.ipv4.ipfrag_high_thresh	5242880	控制内核 IP 分片的高阈值。	如果您的系统的网络流量较大，建议增加这个参数的值。
net.ipv4.ipfrag_low_thresh	2932160	控制内核 IP 分片的低阈值。	如果您的系统的网络流量较大，建议增加这个参数的值。
net.ipv4.ip_local_port_range	1025 65530	控制内核分配本地端口的范围。	如果您的应用程序需要大量的本地端口，建议增加这些参数的值。
net.ipv4.neigh.default.gc_thresh1	8192	控制内核网络邻居表的 GC 阈值。	如果您的系统的网络流量较大，建议增加这个参数的值。｜
net.ipv4.neigh.default.gc_thresh2	4092	控制内核网络邻居表的 GC 阈值。	如果您的系统的网络流量较大，建议增加这个参数的值。
net.ipv4.neigh.default.gc_thresh3	8192	控制内核网络邻居表的 GC 阈值。	如果您的系统的网络流量较大，建议增加这个参数的值。
net.ipv4.tcp_fin_timeout	10	控制内核 TCP 连接终止时的超时时间。	如果您的应用程序需要快速地建立和终止 TCP 连接，建议将这个参数的值设置为较小的值。
net.ipv4.tcp_keepalive_time	3600	控制内核 TCP 连接的空闲时间。	如果您的应用程序需要保持 TCP 连接的长时间空闲状态，建议增加这个参数的值。
net.ipv4.tcp_max_syn_backlog	40960	控制内核 TCP SYN 队列的最大长度。	如果您的系统需要处理大量的 TCP 连接请求，建议增加这个参数的值。
net.ipv4.tcp_max_tw_buckets	1440000	控制内核 TCP TIME-WAIT 队列的最大长度。	如果您的系统需要处理大量的 TCP 连接请求，建议增加这个参数的值。
net.ipv4.tcp_rmem	92160 6000000 17476000	内核套接字 TCP 接收缓冲区的最小、默认、最大大小。	如果您的系统的网络流量较大，建议增加这些参数的值。
net.ipv4.tcp_sack	1	控制内核是否启用 TCP SACK。	如果您的应用程序需要使用 TCP SACK，建议将这个参数的值设置为 1。
net.ipv4.tcp_synack_retries	2	控制内核 TCP 连接建立时的重试次数。	如果您的系统需要处理大量的 TCP 连接请求，建议增加这个参数的值。
net.ipv4.tcp_syncookies	1	控制内核是否启用 TCP SYN Cookie。	如果您的系统需要处理大量的 TCP 连接请求，建议将这个参数的值设置为 1。
net.ipv4.tcp_syn_retries	2	控制内核 TCP 连接建立时的重试次数。	如果您的系统需要处理大量的 TCP 连接请求，建议增加这个参数的值。
net.ipv4.tcp_tw_recycle	1	控制内核是否启用 TCP TIME-WAIT 回收机制。	如果您的系统需要处理大量的 TCP 连接请求，建议将这个参数的值设置为 1。
net.ipv4.tcp_tw_reuse	1	控制内核是否启用 TCP TIME-WAIT 重用机制。	如果您的系统需要处理大量的 TCP 连接请求，建议将这个参数的值设置为 1。
net.ipv4.tcp_window_scaling	1	控制内核是否启用 TCP 窗口扩展机制。	如果您的系统需要处理大量的 TCP 连接请求，建议将这个参数的值设置为 1。
net.ipv4.tcp_timestamps	1	控制内核是否启用 TCP 时间戳机制。	如果您的应用程序需要使用 TCP 时间戳机制，建议将这个参数的值设置为 1。
net.core.somaxconn	65535	内核套接字连接队列的最大长度。	如果您的系统需要处理大量的 TCP 连接请求，建议增加这个参数的值。

参考示例

vm.swappiness = 0
vm.panic_on_oom=1
kernel.panic=10
fs.file-max = 65536
kernel.sysrq = 0
kernel.printk = 5 4 1 7
kernel.softlockup_panic = 1
net.ipv4.conf.default.rp_filter = 0
net.ipv4.ip_forward = 1
net.core.netdev_max_backlog = 40960
net.core.optmem_max = 921600
net.core.rmem_default = 2097152
net.core.wmem_default = 2097152
net.core.wmem_max = 8388608
net.core.rmem_max = 8388608
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 87380 8388608
net.ipv4.udp_mem = 8388608 12582912 16777216
net.ipv4.udp_rmem_min = 65536
net.ipv4.udp_wmem_min = 65536
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.ipfrag_high_thresh = 5242880
net.ipv4.ipfrag_low_thresh = 2932160
net.ipv4.ip_local_port_range = 1025 65530
net.ipv4.neigh.default.gc_thresh1 = 8192
net.ipv4.neigh.default.gc_thresh2 = 4092
net.ipv4.neigh.default.gc_thresh3 = 8192
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_keepalive_time = 3600
net.ipv4.tcp_max_syn_backlog = 40960
net.ipv4.tcp_max_tw_buckets = 1440000
net.ipv4.tcp_rmem = 92160 6000000 17476000
net.ipv4.tcp_sack = 1
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_syn_retries = 2
net.ipv4.tcp_tw_recycle=1
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.core.somaxconn = 65535

openEuler折腾小记:docker/nvidia 配置

info@wlstack.com (物链网络) — Fri, 17 Feb 2023 00:00:00 +0000

openEuler 简介

openEuler是一款开源操作系统。当前openEuler内核源于Linux，支持鲲鹏及其它多种处理器，能够充分释放计算芯片的潜能，是由全球开源贡献者构建的高效、稳定、安全的开源操作系统，适用于数据库、大数据、云计算、人工智能等应用场景。同时，openEuler是一个面向全球的操作系统开源社区，通过社区合作，打造创新平台，构建支持多处理器架构、统一和开放的操作系统，推动软硬件应用生态繁荣发展

为什么选择openEuler

内存RAS - 高可靠内存，可以支持内核、关键进程、内存文件系统、文件缓存使用高可靠内存，避免内存多 bit 故障引起内核复位。改进了对高可靠内存的支持，对高可靠内存支持更加完善。
内存RAS - UCE容错增强，支持 copy_from_user 读操作时，发生内存多bit错误，可以通过杀掉受影响的进程，而避免内核复位。可编程内核调度框架，抢占、选核、选任务部分实现及示例。
资源隔离，在cgroup v1中支持iocost，用户可以通过配置权重对io资源进行分配。
CXL支持，增加PCIe/AER的RCEC(Root Complex Event Collectors)处理。调测，基于 ARM 64 SPE，实现 perf c2c，更方便的检测Cache伪共享，定位性能瓶颈。
AF_UNIX socket 性能优化，大幅降低多并发场景下，连接时延和CPU占用率。

openEuler智能运维

openEuler提供智能运维基本框架，支持cve管理、配置溯源、异常检测等基础能力，支持快速排障和运维成本降低。

cve在线巡检，提供cve批量感知修复能力，系统管理各主机漏洞情况，方便用户快速识别主机漏洞，区分受影响与不受影响cve，一键修复，保障集群安全，提升漏洞修复效率。异常检测，突破在线巡检、高性能高精度探针等关键技术，在mysql、openGauss业务场景实现网络I/O时延、丢包、中断等故障以及磁盘I/O高负载故障的发现。运维工具集，通过对案例的总结/分析形成，包含问题定位、系统巡检/监控、ftrace增强、一键收集日志等功能，是一款集成分析、流程跟踪、信息定时记录、历史经验固化等功能于一体的OS内核问题定位工具。

折腾环境与目标

CPU：I9-10980XE 主板:MSI X299-PRO 内存:32Gx2 GPU:GIGABYTE 3060x2 OS:openEuler 22.03 (LTS-SP1) 安装包:最小化安装

安装所需依赖

dnf install kernel-devel dkms make -y
yum install bzip2-devel gmp-devel.x86_64 mpfr-devel.x86_64 libmpc-devel.x86_64 libSM-devel.x86_64 libxml2-devel -y

安装nvidia驱动

注释开源驱动和ipv6这种碍事的东西编辑/etc/grub2.cfg或/etc/grub2-efi.cfg，具体是哪个文件取决于bios设置的引导模式是什么。

	echo 'Loading openEuler (5.10.0-136.17.0.93.oe2203sp1.x86_64) 22.03 (LTS-SP1)'
 linuxefi	/vmlinuz-5.10.0-136.17.0.93.oe2203sp1.x86_64 root=UUID=54a9e953-0a9e-45dc-9206-179453b0f341 ro cgroup_disable=files apparmor=0 ipv6.disable=1 rd.driver.blacklist=nouveau nouveau.modeset=0 crashkernel=512M

安装nvidia显卡驱动静默安装，默认接受协议，不检测x windows系统,安装dkms动态内核模块

产品研发中的系统化思维（1）：囚徒困境

info@wlstack.com (物链网络) — Wed, 23 Nov 2022 00:00:00 +0000

从2010年起，工作的重心与研发的联系越来越紧密。非科班出身，边学习边工作。十二年饮冰，步步皆艰辛。访问最多的网站肯定是某搜索引擎，使用频次最高的按键依然是Ctrl+C和Ctrl+V. 开始时战战兢兢，只会敲命令背语法亦步亦趋，到14年开始创业已是放荡不羁不换行不注释无所畏惧，再到隐入城市，在城中村中求静，潜心打磨产品，一不小心，就已过了4年有余，产品也由套框架、买主题，上线测试，用户评议、合规注册，再到改版重构，数次迭代，渐渐累积了各种矛盾各种负面情绪，或当然还会有敬畏。显然市场竞争技术研发产品进化是逆水行舟不进则退，无论从何角度看都没有躺平的意愿。而前进的诱惑和担忧，却又彷若夫妻有七年止痒，市场反响褒贬不一,用户反馈噪杂无序，微弱的性能优势在价格竞争中不值一提，研发资源有限却又被各种任务快速消费。产品的历史是往日的荣光，但更可能是三体人的智子，锁死了前进的道路。

而我们清楚的知道，如果不前进就一定会死 同时我发现，这个产品的第一代第二代乃至一直陪伴这个产品成长的小伙伴，在现有体系、架构，维护起来渐感力不从心的时候，往往都希望有一个“破壁者” 但下一个迭代，如果方向不对，就是一个陷阱，很容易陷入某种困境，而跳出来，方有可能在上一个阶梯。

抱怨1:测试与开发之间

1. 关于流程：提测单里不写测试范围或者寥寥几句跟没写一样!系统中提交的bug开发都不及时处理，也不看测试邮件！

2. 关于标准：为什么开发写完代码都不自测就扔给我们?测试提的bug不能复现、优先级还设置为major！

3. 关于资源：谁在测试环境调试？谁动了我们的测试数据？我们开发环境没数据，不用你们的用谁的？

4. 关于态度：测试什么都不懂…跟你说不清楚用户根本不可能这样用，你们整来整去净瞎耽误工夫你们安排计划时根本不考虑测试，三天，三天怎么可能测得完！

...诸如此类...

抱怨2:市场与后端之间

抱怨3:实施与研究之间

抱怨4:需求与设计之间

什么是囚徒困境

囚徒困境是博弈论中的一个经典理论

1950年，梅里尔.德莱希尔提出了“囚徒困境”的游戏。杜克将这一想法定型完善。

两个罪犯被当作嫌疑犯抓获，隔离囚禁候审，二人均在思考招供还是不招。
若二人均不招，各判半年徒刑；
若一人招拱，另一人不招，招供者立功释放，不招者判10年徒刑；
若二人都招，各判2年徒刑。
因无法沟通，二人困惑不已。发明者以这一游戏透示社会生活中普遍存在的一种状况。

在企业里面，通常存在如下类似的困境:

一名经理，数名员工; 前提，经理比较苛刻;
如果所有员工都听从经理吩咐，则奖金等待遇一样，不过所有人都超负荷工作;如果某人不听从吩咐，其他人听从吩咐，则此人下岗,其他人继续工作;如果所有人都不听从经理吩咐，则经理下岗;

但是，由于员工之间信息是不透明的，而且，都担心别人听话自己不听话而下岗，所以，大家只能继续繁重的工作。

上帝视角不应只存在于老板眼中

电影《教父》里有一句台词：「花一秒钟就看透事物本质的人，和花一辈子都看不清事物本质的人，注定是截然不同的命运。」

而系统思维，可以简单的以老板看问题看事情的角度来类比。

从工作本身而论：

程序员通常执着于某段代码某个功能的实现。老板看到的是这个功能能不能迎合市场取悦顾客，能不能卖出产品，以及实现这个功能所需的成本、时间、资源。

而这最终要求产品经理、研发、测试，在产品研发的全生命周期，具备一定的视野，不一定是全局的、系统性的，但至少要分得清，这个系统是什么，由什么组成、组成的流程和链接关系、链接路径，最终实现了什么功能，满足了市场的某个需求

从企业文化与工作氛围来说：

我们当然没有办法要求每个人都一定都视野或格局，或经验沉淀，来聚焦核心，或是高屋建瓴，也不可能要求把什么事情都想的面面俱到。但“宰相起于州部猛将发于卒伍”，今天不敢想，不深入的想，忙忙碌碌看上去活就没停过，最后发现，要么交付的东西与最初的用户需求或问题，已南辕北辙，捡了芝麻丢了西瓜，要么是是改进了A功能，引入了B隐患或缺陷，最终顾此失彼。而这样的人生，看上去这么辛苦，产物确实一塌糊涂，与测试扯“设计如此”、与老板讲“资源局限性和妥协”、与客户强调“客观条件”，最终陷入“相互指责”、“借口与推脱”、“相互摆烂”的囚徒困境。

而囚徒困境下，员工与老板、与企业是双输并且将一直输，除非事情得到改善。很简单的逻辑：工作辛苦、产品不出众、企业市场竞争处于劣势、效益差、薪水低、工作幸福感更差，于是下一个版本下一个产品更…..死循环直到企业消亡。而在这个时间段，企业与老板，输的是可量化的经济损失。但对工程师而言输了什么？输了职场的黄金时间，输了职业生命周期。而这，是决定一个工程师能否成长到高级/资深工程师或架构师，走上职场金字塔巅峰的起点。输在了起点，基本上，即可宣告

在

系统的定义

德内拉•梅多斯在她的著作《系统思考》中的定义：

系统是一组相互关联的元素，它以一种可以实现某些东西的方式联系起来。

所以，我们可以将系统分为：环境：系统的运行环境、硬件、操作系统、使用场景；要素：在系统里，最核心的要素是什么？互联：要素之间是如何连接的？它们之间的关系是怎样的？它们进行输入和输出的途径是什么？目的：产品最终想要达到的目的是什么？程序和功能并不是目的，帮助使用程序或功能的人解决某种问题达成某个目标，才是系统设计、产品研发的根部目的。

套入我们辅助诊断系统：

环境

操作系统：Centos7 64bit/一切64位的linux操作系统（特别是基于Linux衍生的国产操作系统，在以后越来越重要），或Windows操作系统 使用场景：病理科边扫描边计算，当切片量大、扫描设备多时，扫描、计算、阅片复核，同时进行是常态。 硬件环境:

组件	供应商或品牌或架构
CPU	Intel/AMD/ARM(华为)/Apple M
内存	DDR家用级/服务器级（ecc）
存储	local(ssd/nvme ssd/sata) remote(nas:nfs/cifs/fc/vfs client/fuse client)
网络	介质:ethernet/fiber 连接:lan/wan
计算卡	GPU:nvidia(cuda)/amd(romc)/华为/Google/xilinx（fbga）

软件环境：

jupyterhub notebook ldap统一认证

info@wlstack.com (物链网络) — Mon, 10 Oct 2022 00:00:00 +0000

冷饭重炒

这其实是在19年就应该发出来的一点笔记，只是以前都存在自己脑子里，而且现在随着版本的变动，配置上也有了一点点小变化，所以炒一下冷饭。

需求是什么

在一个小公司里面，如何为算法工程师分配GPU资源是个问题。大厂当然有成熟的k8s+各种gpu虚拟化黑科技。但很显然，这需要完整的体系，从用户认证到临时存储、持久化存储、日志存储、资源配额、资源用量统计、任务队列等等的配套，才能结合k8s的调度一起来完成GPU资源分配。在2019年的时候，服务器少，人也少，项目和任务单一，所以那时候只搞了服务器端的ldap认证，不存在什么资源协调问题，所以裸机直接上了。到了20年，机器增多，人也增多，任务和环境的诉求也不一样，这个时候，再走裸机，很显然，无论从资源利用率、数据安全、环境冲突（即使有Anaconda和virtualenv）这样的环境管理，也无法在延续之前的裸机方式了。

所以呢，准备基于docker容器特性，来实现GPU资源的交付和隔离。那就意味着，在容器内，涉及容器内ssh服务（算法工程师大多喜欢通过vscode直连服务器ssh）、notebook的认证，延续之前的ldap认证。

规划是这样的：

采用nvidia-container-toolkit结合docker交付GPU资源
建设内部镜像库，涵盖常见的发行版和cuda版本；
基于内部镜像库build每个工程师的容器镜像
每个工程师的工程目录，即ldap里面账户的/home目录，一般在/home/username 下面
每个工程师能够访问的数据通过挂载host上的目录透传到容器中
统一管理容器内的时间戳、认证、权限（sudoers）

实际的操作

容器镜像build的时候安装openssh-server、生成ssh服务所需要的key文件
容器镜像build的时候，安装jupyterhub和jupyterhub-ldapauthenticator 和nodejs、npm包configurable-http-proxy
容器镜像build的时候安装nss-pam-ldapd 认证模块
创建容器

docker run -d --rm=false --net=host --restart=unless-stopped --name username --shm-size=8g (cat /etc/hosts|awk -F ' ' '{if(NR>2){print "--add-host "$2":"$1}}') -it -v /data-directory:/data-directory -v /home/username:/home/username -v /var/log/username:/var/log/username -v /etc/jupyterhub/username_config.py:/etc/jupyterhub/username_config.py -e TZ=Asia/Shanghai -v /etc/pam.d:/etc/pam.d:ro -v /etc/nslcd.conf:/etc/nslcd.conf:ro -v /etc/nsswitch.conf:/etc/nsswitch.conf:ro -v /var/run/nslcd:/var/run/nslcd -v /etc/passwd:/etc/passwd:ro -v /etc/group:/etc/group:ro -v /etc/shadow:/etc/shadow:ro -v /etc/gshadow:/etc/gshadow:ro -v /etc/sudoers:/etc/sudoers:ro --runtime nvidia --privileged image:tag /home/username/start.sh

几个特殊的挂载点和参数，解释一下：

FreeBSD ZFS存储与samba配置

info@wlstack.com (物链网络) — Tue, 27 Sep 2022 00:00:00 +0000

作为穷人，我们选择基于FreeBSD+ZFS+SAMBA构建山寨存储

毋庸质疑，也无需赘述

freebsd操作系统是公认的“快”、“安全”、“稳定”

zfs是人类有史以来最先进的文件系统

FreeBSD入门

软件包管理

Linux® 命令 (Red Hat/Debian)	FreeBSD 等价命令目的
yum install package / apt-get install package	pkg install package 从远程仓库安装 package
rpm -ivh package / dpkg -i package	pkg add package 安装 package
rpm -qa / dpkg -l	pkg info 列出已安装的软件包

系统管理

Linux	FreeBSD 等价命令目的
lspci	pciconf 列出 PCI 设备
lsmod	kldstat 列出已载入的内核模块
modprobe.	kldload / kldunload 载入/卸载内核模块
strace.	truss 跟踪系统调用

网络管理

Linux	FreeBSD 等价命令目的
ip	ifconfig
ifconfig	ifconfig
iptable	ipfw

ZFS入门

ZFS 的历史

ZFS是由 Matthew Ahrens 和 Jeff Bonwick 在 2001 年开发的。ZFS 是作为太阳微系统(Sun MicroSystem) 公司的 OpenSolaris 的下一代文件系统而设计的。在 2008 年，ZFS 被移植到了 FreeBSD 。同一年，一个移植 ZFS 到 Linux 的项目也启动了。然而，由于 ZFS 是通用开发和发布许可证 (Common Development and Distribution License)（CDDL）许可的，它和 GNU 通用公共许可证不兼容，因此不能将它迁移到 Linux 内核中。为了解决这个问题，绝大多数 Linux 发行版提供了一些方法来安装 ZFS。在甲骨文公司收购太阳微系统公司之后不久，OpenSolaris 就闭源了，这使得 ZFS 的之后的开发也变成闭源的了。许多 ZFS 开发者对这件事情非常不满。三分之二的 ZFS 核心开发者，包括 Ahrens 和 Bonwick，因为这个决定而离开了甲骨文公司。他们加入了其它公司，并于 2013 年 9 月创立了 OpenZFS 这一项目。该项目引领着 ZFS 的开源开发。让我们回到上面提到的许可证问题上。既然 OpenZFS 项目已经和 Oracle 公司分离开了，有人可能好奇他们为什么不使用和 GPL 兼容的许可证，这样就可以把它加入到 Linux 内核中了。根据 OpenZFS 官网的介绍，更改许可证需要联系所有为当前 OpenZFS 实现贡献过代码的人（包括初始的公共 ZFS 代码以及 OpenSolaris 代码），并得到他们的许可才行。这几乎是不可能的（因为一些贡献者可能已经去世了或者很难找到），因此他们决定保留原来的许可证。

FreeBSD Lagg 端口聚合与LACP配置

info@wlstack.com (物链网络) — Fri, 23 Sep 2022 00:00:00 +0000

基础环境

os:FreeBSD 12.3-RELEASE

网卡:Mellanox Technologies ConnectX-4 Lx

交换机：华为ce6820-48S6CQ-B

需求

FreeBSD 通过ConnectX-4 两个端口连接到交换机。配置端口聚合（bonding、aggregate，port-chanel，portgroup 好多种说法），实现2个端口负载均衡。

配置

FreeBSD侧配置：

kldload if_lagg ### 加载bonding，即freebsd里的lagg内核模块

ifconfig lagg0 create ### 创建lagg接口

ifconfig mce0 up ### 启动mce1 网卡

ifconfig mce1 up ### 启动mce1 网卡

ifconfig lagg0 up laggproto lacp laggport mce0 laggport mce1 ### 启动聚合接口，聚合协议为lacp，同时还有loadbalance/fce/failover/roundrobin和none模式可选

交换机侧配置：

int eth 111

mode lacp-dynamic

持久化配置到服务器上，编辑/etc/rc.conf 配置文件

ifconfig_mce0="up"
ifconfig_mce1="up"
cloned_interfaces="lagg0"
ifconfig_lagg0="up laggproto lacp laggport mce0 laggport mce1"
ipv4_addrs_lagg0="x.x.x.x/x"
defaultrouter="x.x.x.x"

FreeBSD Lagg协议的分类

协议	说明
failover	主备模式，第一个端口为主端口，后续端口为备用端口。流量默认走主端口，主端口故障中断后切换到备用端口
LACP	支持 IEEE 802.3ad 链路聚合控制协议 (LACP) 和标记协议。 LACP 将与一个或多个链路聚合组中的对等方协商一组可聚合链路。每个 LAG 由相同速度的端口组成，设置为全双工操作。流量将在总速度最大的 LAG 中的端口之间进行平衡，在大多数情况下，只有一个 LAG 包含所有端口。如果物理连接发生变化，链路聚合将快速收敛到新配置。根据协议标头hash信息平衡活动端口之间的传出流量，并接受来自任何活动端口的传入流量。hash包括以太网源地址和目标地址，以及 VLAN 标记（如果可用）以及 IPv4/IPv6 源地址和目标地址。一般和华为交换机对接时使用
FEC	支持思科 EtherChannel。这是一种静态设置，不会与对等方协商聚合或交换帧来监控链路，如果交换机支持 LACP，则应改为使用它。根据标头信息hash平衡活动端口之间的传出流量，并接受来自任何活动端口的传入流量。 hash包括以太网源地址和目标地址，以及 VLAN 标记（如果可用）以及 IPv4/IPv6 源地址和目标地址。
loadbalance	FEC的别名
roundrobin	使用轮询分发流量，通过所有活动端口分配传出流量，并接受来自任何活动端口的传入流量。此模式将违反以太网帧顺序，应谨慎使用。大概率负载不均。
none	这个协议什么都不做：它在不禁用 lagg 接口本身的情况下禁用任何流量。

内核优化参数记录之FreeBSD

info@wlstack.com (物链网络) — Mon, 07 Mar 2022 00:00:00 +0000

#最大的待发送TCP数据缓冲区空间 net.inet.tcp.sendspace=65536

#最大的接受TCP缓冲区空间 net.inet.tcp.recvspace=65536

#最大的接受UDP缓冲区大小 net.inet.udp.sendspace=65535

#最大的发送UDP数据缓冲区大小 net.inet.udp.maxdgram=65535

#本地套接字连接的数据发送空间 net.local.stream.sendspace=65535

#加快网络性能的协议 net.inet.tcp.rfc1323=1 net.inet.tcp.rfc1644=1 net.inet.tcp.rfc3042=1 net.inet.tcp.rfc3390=1

#最大的套接字缓冲区 kern.ipc.maxsockbuf=2097152

#系统中允许的最多文件数量 kern.maxfiles=65536

#每个进程能够同时打开的最大文件数量 kern.maxfilesperproc=32768

#当一台计算机发起TCP连接请求时,系统会回应ACK应答数据包. #该选项设置是否延迟ACK应答数据包,把它和包含数据的数据包一起发送, #在高速网络和低负载的情况下会略微提高性能,但在网络连接较差的时候, #对方计算机得不到应答会持续发起连接请求,反而会降低性能. net.inet.tcp.delayed_ack=0

#屏蔽ICMP重定向功能 net.inet.icmp.drop_redirect=1 net.inet.icmp.log_redirect=1 net.inet.ip.redirect=0 net.inet6.ip6.redirect=0

#防止ICMP广播风暴 net.inet.icmp.bmcastecho=0 net.inet.icmp.maskrepl=0

#限制系统发送ICMP速率 net.inet.icmp.icmplim=100

#安全参数,编译内核的时候加了options TCP_DROP_SYNFIN才可以用 net.inet.icmp.icmplim_output=0 net.inet.tcp.drop_synfin=1

#设置为1会帮助系统清除没有正常断开的TCP连接,这增加了一些网络带宽的使用,但是一些死掉的连接最终能被识别并清除.死的TCP连接是被拨号用户存取的系统的一个特别的问题,因为用户经常断开modem而不正确的关闭活动的连接 net.inet.tcp.always_keepalive=1

#若看到net.inet.ip.intr_queue_drops这个在增加,就要调大net.inet.ip.intr_queue_maxlen,为0最好 net.inet.ip.intr_queue_maxlen=1000

#防止DOS攻击,默认为30000 net.inet.tcp.msl=7500

#接收到一个已经关闭的端口发来的所有包,直接drop,如果设置为1则是只针对TCP包 net.inet.tcp.blackhole=2

#接收到一个已经关闭的端口发来的所有UDP包直接drop net.inet.udp.blackhole=1

#为网络数据连接时提供缓冲 net.inet.tcp.inflight.enable=1

#如果打开的话每个目标地址一次转发成功以后它的数据都将被记录进路由表和arp数据表,节约路由的计算时间,但会需要大量的内核内存空间来保存路由表 net.inet.ip.fastforwarding=0

##kernel编译打开options POLLING功能,高负载情况下使用低负载不推荐 ##SMP不能和polling一起用 #kern.polling.enable=1

#并发连接数,默认为128,推荐在1024-4096之间,数字越大占用内存也越大 kern.ipc.somaxconn=32768

#禁止用户查看其他用户的进程 security.bsd.see_other_uids=0

#设置kernel安全级别 kern.securelevel=0

#记录下任何TCP连接 net.inet.tcp.log_in_vain=1

#记录下任何UDP连接 net.inet.udp.log_in_vain=1

#防止不正确的udp包的攻击 net.inet.udp.checksum=1