esxi标记为闪存 闪存问题 我们在使用 esxi6.5 版本的时候，使用了 SSD 作为数据存储，但是在数据存储的信息中仍然看到是 HDD类型，不知道会不会对性能有影响，能否转换为 SSD 呢？ 在点击此存储适配器后是可以额外做一些操作的，其中就包括更改为闪存，但测试从这里修改无法生效，提示正在被使用，即使它是刚安装完的系统、里面没有任何数据 修改方法 在通过搜索资料后，找到了修改方法： 通过 ssh 登录到 esxi 上 列出所有的驱动器，目的是找到其 nna 号码 esxcli storage nmp device list 找到正确的 编号 后，使用下面的命令清除其当前的类型 esxcli storage nmp satp rule remove -s VMW_SATP_LOCAL --device naa.61866da0a11a6d00218f81e2062afxxx --option="enable_ssd" 重新修改为 SSD 类型 esxcli storage nmp satp rule add -s VMW_SATP_LOCAL --device naa.61866da0a11a6d00218f81e2062afxxx --option="enable_ssd" 重启 esxi 机器，再次到 web 的存储适配器中可以看到类型已经为闪存

TrueNAS zfs raidz扩展磁盘expand 背景 在使用 TrueNAS 4年后的今天，终于迎来了存储池空间使用率超过了90%，存储池是使用的 10 块 2T 做的 raidz3，即可以损失任意3块盘仍然保证数据安全，剩余的空间计算为 (10-3) x 2T = 14T，实际最大可用空间 11.98T，而现在剩余可用空间不足 1T 扩容问题 手头上刚好有一块 2T 的磁盘，是否可以加进去直接扩展空间呢？ 尝试在池中加入新盘，提示需要添加 5块 硬盘，实在难以理解为何一次扩容需要5块盘，因为之前玩群晖组raid6扩展还是相当方便的，基本上新增一块、两块扩展空间都可以。 所以根据这个特殊的要求，我查阅了一些资料，才发现问题不止是扩展需要5块硬盘那么简单，最少要5块是会在此池中新建一个vdev组，它具有此池相同的raidz功能，所以raidz3最低的要求是5块新盘，但它不会扩展到原有的空间，那这个方案是相当浪费空间的 于是我查询了一些关于raidz、zfs扩展的资料，截至到2024.08.01最新的资料如下： # 12楼 https://www.truenas.com/community/threads/raidz-expansion-best-method-when-increasing-disks-and-replacing-with-larger-at-same-time.105448/ # 4楼 https://www.truenas.com/community/threads/adding-a-drive-to-a-raidz1-pool.111805/ # 正规文档关于之前是如何扩展的（新建一个vdev） https://openzfs.org/wiki/OpenZFS_Developer_Summit_2023_Talks#RAIDZ_Expansion_(Matt_Ahrens_&_Don_Brady) # 关于解决方案和其他的一些讨论 https://www.truenas.com/community/threads/adding-disk-to-raidz1.111375/ # 关于扩展以及扩展后数据分布的讨论 https://github.com/openzfs/zfs/pull/15022 # 关于扩展以及数据分布的讨论后续 https://github.com/openzfs/zfs/discussions/15232 关于上面的讨论，大概在今年底 TrueNAS 可以集成这一功能，但不知道能否解决数据分布问题，raidz 与 raid 完全不同，其扩展后不会重新分布数据，导致原数据与新数据盘符存储不同，推荐的方法是，删除原数据重新创建，则会以新盘的数量重新分布 PS. 其他的解决方案 较推荐的是把原硬盘一个一个更换更大的盘，每更换一个则等到同步完成再继续，等所有硬盘更换后会自动扩展空间 新建一个更大的池，然后把数据同步过去

nginx代理dns的问题 环境背景 目前是由nginx 4层代理的 bind 服务提供 dns 解析服务，但是出现了一些问题，这里作为一个记录 配置和问题 这是原本的配置，测试dns解析基本上没有问题 upstream dns { server 192.168.10.120:53; server 192.168.10.121:53; server 192.168.10.122:53; } server { listen 53; listen 53 udp; proxy_connect_timeout 2s; proxy_timeout 2s; proxy_next_upstream on; proxy_pass dns; error_log /usr/local/nginx/logs/dns.log info; } 但日志一直有问题，要等到会话超时，也就是 proxy_timeout 之后才会正常打印日志，这样后续就会很难配合 bind 服务排查问题，时间是对不上的，而且bind服务只能记录 nginx 机器的 ip 地址 经过检索，增加了如下配置，主要是参数 proxy_responses server { listen 53; listen 53 udp; proxy_connect_timeout 2s; proxy_responses 1; proxy_timeout 2s; proxy_next_upstream on; proxy_pass dns; error_log /usr/local/nginx/logs/dns.log info; } 这个参数 nginx 官方的解释如下: Sets the number of datagrams expected from the proxied server in response to a client datagram if the UDP protocol is used. The number serves as a hint for session termination. By default, the number of datagrams is not limited. If zero value is specified, no response is expected. However, if a response is received and the session is still not finished, the response will be handled. 主要设置一个接收响应的报文，如果设置 1 ，则只要有一个数据包响应，则认为会话结束，然后它就会记录日志，这样确实解决了及时记录日志的问题 新的问题 在配置使用几天后发现了新的问题，明显感觉这几天上网、登录服务器等操作经常变慢，监控甚至又开始出现了一个很早之前的报错---域名解析失败，怀疑是上次修改的dns代理配置问题 在nginx服务器上检查了日志，可以看到如下内容： 2024/07/22 11:00:02 [error] 17500#0: *705 upstream timed out (110: Connection timed out) while proxying connection, udp client: 192.168.7.21, server: 0.0.0.0:53, upstream: "192.168.10.120:53 ", bytes from/to client:86/43, bytes from/to upstream:43/86 2024/07/22 11:00:04 [error] 17500#0: *1173 upstream timed out (110: Connection timed out) while proxying connection, udp client: 192.168.3.103, server: 0.0.0.0:53, upstream: "192.168.10.122: 53", bytes from/to client:100/176, bytes from/to upstream:176/100 2024/07/22 11:00:08 [error] 17500#0: *1313 upstream timed out (110: Connection timed out) while proxying connection, udp client: 172.23.126.234, server: 0.0.0.0:53, upstream: "192.168.10.121 :53", bytes from/to client:76/232, bytes from/to upstream:232/76 2024/07/22 11:00:08 [error] 17500#0: *38157 no live upstreams while connecting to upstream, udp client: 172.23.127.238, server: 0.0.0.0:53, upstream: "dns", bytes from/to client:37/0, bytes from/to upstream:0/0 2024/07/22 11:00:08 [error] 17500#0: *38158 no live upstreams while connecting to upstream, udp client: 192.168.3.103, server: 0.0.0.0:53, upstream: "dns", bytes from/to client:29/0, bytes f rom/to upstream:0/0 2024/07/22 11:00:08 [error] 17500#0: *38159 no live upstreams while connecting to upstream, udp client: 172.23.126.242, server: 0.0.0.0:53, upstream: "dns", bytes from/to client:41/0, bytes from/to upstream:0/0 2024/07/22 11:00:08 [error] 17500#0: *38160 no live upstreams while connecting to upstream, udp client: 172.23.126.254, server: 0.0.0.0:53, upstream: "dns", bytes from/to client:33/0, bytes from/to upstream:0/0 2024/07/22 11:00:09 [error] 17500#0: *38161 no live upstreams while connecting to upstream, udp client: 192.168.3.100, server: 0.0.0.0:53, upstream: "dns", bytes from/to client:40/0, bytes f rom/to upstream:0/0 显然在上次增加了 proxy_responses 1 参数后，经常访问不到后端服务器，连接后端超时，等到全部 upstream 都被判定超时则提示 no live upstream，基本上符合问题现象 接下来反复打开关闭这个参数验证多次，确实发现只要开启参数，过一会儿就会有一大片的 upstream 超时日志 虽然找到了问题，但目前还未找到原因和解决办法 --- 这个参数会导致 upstream 超时，所以只能暂时关闭了 dns真实ip问题 udp的代理是不支持 proxy_protocol 的，所以无法传递真实的 ip 给 upstream，但是了解到可以使用 proxy_responses 0 配合 DSR 来实现传递真实的 ip，后续如果要这样先把 dns 服务器独立出来吧，暂时先这样，参考文档: https://www.nginx-cn.net/blog/ip-transparency-direct-server-return-nginx-plus-transparent-proxy/

docker网络的疑难问题之三 前提背景 20240701 继之前的docker网络的dns解析问题 疑难问题如鲠在喉，如果不能解决，始终是一个风险，这里记录下来，尽快找到办法解决 关于 dns 解析的问题，现象为：如果本机宿主机上同时配置了VIP+BIND容器，这也是我们需要的模式，并且本机/etc/resolv.conf配置了VIP作为nameserver，那么其他容器则无法解析外网地址，容器内默认的/etc/resolv.conf配置为127.0.0.11。其他机器容器可以正常解析。这个情况在之前的帖子已经追踪过，经过排查后发现可能是NAT有问题，所以BIND服务不能使用与其他容器相同的overlay网络，而是改成host模式，当然目前来看，为了保证必定不出问题，最好是把bind服务隔离到单独的一台机器上，这样就完全避免了本机的nat转换错误问题 关于容器内访问 nginx 错误问题 从其他容器访问nginx，发现必定出现两次拒绝，一次可以访问。发现正好对应了 nginx 有三个副本，便使用 curl -v 查看了访问的ip地址，都是一样的。 [root@253258ad95d3 /]# curl http://nginx curl: (7) Failed connect to nginx:80; 拒绝连接 [root@253258ad95d3 /]# curl http://nginx curl: (7) Failed connect to nginx:80; 拒绝连接 [root@253258ad95d3 /]# curl http://nginx <html> <head><title>301 Moved Permanently</title></head> <body> <center><h1>301 Moved Permanently</h1></center> <hr><center>nginx</center> </body> </html> 查询三个 nginx 容器的ip地址，可以看到其实容器内部访问过程中还是有负载均衡的，如果是多个副本，并不会直接访问到某一个节点上，而是访问到了另外一个ip 172.21.1.185 # 其他容器curl http://nginx 解析的ip 172.21.0.200 # 节点一ip 172.21.11.227 # 节点二ip 172.21.23.214 # 节点三ip 第一个IP是容器内dns解析到的VIP（docker swarm VIP策略），另外三个则是 nginx 服务器的 3 副本实际ip 可以猜测是到了overlay网络的负载均衡地址，而overlay网络的VIP模式负载均衡是用ipvs实现的。那么如何证明呢？ 我们可以进入 /var/run/docker/netns 目录下，这里包括了本机的容器、网络配置的命名空间。其中有几个特殊的是网络的，可以看到其中有一个是 lb_1jo63pzkt，这个前缀 lb + 后面的 id 刚好是我们需要的overlay id，所以基本上确定是这个 使用命令进入 nsenter --net=lb_1jo63pzkt sh 接着可以使用命令查询防火墙规则和ipvs规则，需要注意的是，这里的命令是调用的宿主机操作系统命令，所以宿主机需要提前安装ipvs，yum -y install ipvsadm 查看防火墙mangle规则： iptables -L -t mangle -n MARK all -- 0.0.0.0/0 172.21.1.185 MARK set 0x11e 第一行是 nginx 的VIP规则，其中最后的MARK打标值为 0x11e，转换为10进制为286 接着查看 ipvs 规则: ipvsadm -l FWM 286 rr -> 172.21.0.200:0 Masq 1 0 0 -> 172.21.11.227:0 Masq 1 0 0 -> 172.21.23.214:0 Masq 1 0 0 根据MARK值286可以找到对应的三个转发条目。那么172.21.1.185是怎么回事呢？如何解释呢？ 既然打标和转发都有了，可以确定172.21.1.185 ip应该是在本机的，否则怎么转发呢？ 所以通过 ifconfig命令查看，发现此ip在接口上，同时可以看到此接口还有非常多的额外ip，应该都是其他容器的VIP地址，附加到这里做ipvs转发 最终方案 选择解藕服务，前面增加4层nginx，高可用放到此处，VIP也不再放到docker集群中，docker集群只需要保证自身的集群高可用即可，docker中再运行7层nginx，接受4层的请求。至此VIP所在机器上的容器无法解析dns的问题解决 20240702 nginx启动 docker service create --name nginx \ --mount type=bind,src=/docker/others/nginx/conf,dst=/usr/local/nginx/conf \ --mount type=bind,src=/docker/others/nginx/conf.d,dst=/usr/local/nginx/conf.d \ --mount type=bind,src=/docker/others/nginx/logs,dst=/usr/local/nginx/logs \ --network mynets \ -p target=80,published=80 \ -p target=443,published=443 \ -p target=8080,published=8080 \ --constraint node.role==manager \ --replicas 1 \ harbor.succez.com/sz/nginx-v20220701v1

docker镜像id、摘要digests 简单说明 一般我们使用 docker images 显示的 ID 是镜像 ID，也可以通过 docker images --no-trunc 来显示完整的 ID，它是可以用来启动容器的 其一 [root@localhost ~]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE python3-rpa-crm 2024070501 6cda696a98ad 3 weeks ago 2.48GB harbor.succez.com/sz/python3-rpa-crm 2024070501 6cda696a98ad 3 weeks ago 2.48GB python3-rpa-os-common 2024070501 e4f1cbc709c9 3 weeks ago 2.48GB 其二 [root@localhost ~]# docker images --no-trunc REPOSITORY TAG IMAGE ID CREATED SIZE python3-rpa-crm 2024070501 sha256:6cda696a98ad4fefa3c429550341cd3cc9ad94573a3712fb15223cdcfe7a4d56 3 weeks ago 2.48GB harbor.succez.com/sz/python3-rpa-crm 2024070501 sha256:6cda696a98ad4fefa3c429550341cd3cc9ad94573a3712fb15223cdcfe7a4d56 3 weeks ago 2.48GB python3-rpa-os-common 2024070501 sha256:e4f1cbc709c9a4f2cbe8ab329ef5fa32a37745b938883bbd27555b7d003fc471 3 weeks ago 2.48GB 但如果用 docker inspect CONTAINER_ID 查看容器的详细信息，发现启动的镜像通常与 IMAGE ID 不一致，需要这样看是因为经常指定镜像的 latest 标签，会出现此镜像本地存在但启动容器报错无此镜像，所以需要通过查看容器明细来确定使用的哪个镜像。 而 docker inspect CONTAINER_ID 实际上显示的镜像的摘要，所以不管使用 docker images 还是 docker images --no-trunc 都会找不到此镜像，需要使用 --digtests 参数来显示镜像的摘要信息 其三 [root@localhost ~]# docker images --digests REPOSITORY TAG DIGEST IMAGE ID CREATED SIZE python3-rpa-crm 2024070501 <none> 6cda696a98ad 3 weeks ago 2.48GB harbor.succez.com/sz/python3-rpa-crm 2024070501 sha256:c7e46b2080146cfc5870f6b1580faa2a3c67e235537e988921ba2c7348a11f9b 6cda696a98ad 3 weeks ago 2.48GB python3-rpa-os-common 2024070501 <none> e4f1cbc709c9 3 weeks ago 2.48GB 此时镜像ID仍然是有的，前面多了一列 DIGEST，此摘要也是可以用来启动容器的。 有一种情况是如果使用 latest 标签，即使本地存在符合名称的镜像，仍然可能会去拉取最新的 latest 镜像，所以如果我们想启动此镜像，可以指定镜像名+摘要的方式即可