linux硬派运维

原创 特大喜讯：我的作品被河北某大学选做教材

原创 Proxmox VE 8虚拟机直通USB磁盘

添加上的虚拟机硬件设备状态存在两个情况---黑色及红色（或者黄色），Proxmox VE 8这个版本显示的是黑色（如下图所示），而实际远程给操作的那个Proxmox VE版本是5，显示的是黄色。准备妥当的以后，远程登录到Proxmox VE 8 Web管理后台，鼠标选中目标虚拟机（因为是重现，我的环境中没有windows虚拟机，此处以Linux虚拟机为例，效果是一样的）。USB设备显示黄色或者红色，表示当前不生效，需要管在Web管理界面关闭虚拟机，然后再启动，注意不是从虚拟机系统里关闭和重启。

原创 Linux磁盘监控小技巧

默认情况下，使用Nrpe插件check_disk加选项“-w”与”-c”除了输出我们想监控的磁盘分区外，还输出了一些形如“/dev/shm”不需要监控的项目(如下图所示)，倒对查看起到了一些干扰作用。选项大写的“-X”，作用是排除某个文件系统，这里我们尝试使用这个选项，加参数tmpfs，查看其输出。把加选项“-X”与不加选项“-X”两相对比（如下图所示），确实过滤掉了一些干扰项。注意选项“-X”与选项“-x”在命令中的顺序可以随意，没有前后之分。根本没起作用，那么将选项“-X”与其一起使用，会怎么样?

原创 Proxmox VE 超融合集群扩容后又平稳运行了170多天--不重启的话，488天了

五个节点的Proxmox VE 超融合集群，扩从了存储容量，全NVMe高速盘，单机4条3.7TB容量（扩容前是两块NVMe加两块16TB的慢速SATA机械盘，拔掉机械盘，替换成两块NVMe），速度那叫一个块啊。为保证最大的数据安全，使用了两套PBS，一套执行备份，与Proxmox VE相关联，一套执行备份同步，这样一来，就有两套虚拟机的备份副本，基本可以高枕无忧。哈哈，PBS备份服务器没扩大，也就是没有被重启系统，显示连续无故障运行时间是488天，欧耶！

原创 Proxmox Backup Server 命名空间使用

这个功能大大便利了多Proxmox VE集群或者单节点备份，在以前PBS版本中，如果有多个Proxmox VE节点或者集群，在其上创建的虚拟机很可能有相同的”VM ID”，为充分利用资源，大概率需要将这些“VM ID”备份到同一个PBS存储。进入目录” /mnt/datastore/pvedata”,其下自动生成一个子目录“ns”，继续进入子目录“ns”，其下存在两个子目录“pve165”与“pve169”，正好是我们在PBS Web管理后台创建的命名空间的字符串。作者：田逸（formyz）

原创 又一套Proxmox VE 8.2 超融合集群上线了

在安装Proxmox VE 8.2 系统的过程中，有一台机器的双网卡，四个网口，一次只亮两个灯，来回折腾（换尾纤、调试交换机、换网卡、重装系统等），死活就是不行，一般情况下，安装基础环境一天就可以完工的，结果因为这一台机器，三天没有完成任务，只好让供货商从外地飞来解决（换了硬件）。网络正常后，我就离开湖南，返回继续去做医师考核的报名准备，待留下的兄弟把网络调试好以后，我从远程登录上去，配置好集群和PBS，修改密码后，移交给使用者。作者：田逸（formyz）

原创 将ESXi上的虚拟机快速迁移到Proxmox VE 8

在Proxmox VE 8.2的管理后台，虽然可以看到ESXi下的所有虚拟机镜像，但无法通过功能键进行多选操作，这意味着一次只能进行一个虚拟机的导入操作，而不能批量进行；Proxmox VE 8.2发布后，在其存储菜单下，新增了一个ESXI（如下图所示），使用这个功能，大大简化了ESXi虚拟机迁移到虚拟机的步骤，而且能大大节省迁移时间，因为没有ESXI虚拟机的备份、复制备份文件这个比较耗时的过程。导入对话框有一些项可能需要选定或者输入，比如CPU的类型、 迁移/恢复出来的虚拟机的默认存储位置，如下图所示。

原创 第9章 负载均衡集群日常维护

在没有做任何市场推广、也没有突然大幅度增加注册用户的情况下，某一个域名的访问异常缓慢，同一个页面用浏览器反复刷新甚至出现“503”错误，而在此负载均衡集群中的其他域名的访问却是正常的。后端真实服务器节点的撤离，可直接关闭其上的服务甚至是系统，负载均衡器的健康检查将自动将其从转发队列里踢出，不会对用户的访问造成影响，然后再在主从负载均衡器删掉相关条目，即可平稳将节点下线。在高可用负载均衡集群中，一些设施或者应用发生故障虽然不影响用户的使用，但作为维护人员，发现故障应立即排查并进行故障恢复，并对处理进行记录。

原创 Proxmox VE 8 SDN创建VLAN隔离用户网络

登录Proxmox VE 8集群每个节点宿主系统Debian，命令行下在网络配置接口文件“/etc/network/interfaces” 末尾追加文本行“source /etc/network/interfaces.d/*”,然后切换到Proxmox VE 8 集群Web管理后台，数据中心级别，选定“SDN”之子菜单“区域”，点击页面顶部按钮“添加”旁边箭头，下拉列表单选“VLAN”，如下图所示。如果没有错误，在Promxox VE每个节点下，会正常显示创建好的虚拟机网络，如下图所示。

原创 Proxmox VE 8 用SDN隔离用户网络

网络桥接下拉列表框选定前边步骤创建好的虚拟网络接口“mvnet”，虚拟机使用网络地址“192.168.99.0/24”.创建好虚拟机后，在其上安装操作系统Rocky 9，设置网络地址为“192.168.99.111”,默认网关为“192.168.99.1”，dns为“223.6.6.6”，系统正常启动后，登录到该虚拟机所在的系统，用指令“ping 192.16.99.1”及“ping。刷新PVE Web管理后台页面，在页面的左侧，显示刚创建好的两个区域，如果设置有错误，图标将以红色的叉显示，如下图所示。

原创 Proxmox VE 8.1.4升级到8.2

Proxmox VE宿主系统Debian命令行执行如下命令，看是否可以有可以更新的包，如果有，就省事了。第一个是SDN的项目丰富了，其子菜单包含四项，区域可添加的有一个比较新的QinQ，有机会要试试这个功能。当前运行的版本为8.1.4，官方发布了最新的8.2版本，测试环境升级试一把，看有哪些变化。在运行过程中，可能需要对Grub进行配置，我的选择如下图所示。存储增加了一个Exsi，哈哈，可以直接导入vmware虚拟机？直接执行如下命令，进行升级操作。升级完成后，看看有哪些变化。哈哈，更新的包还不少呢！

原创 《Linux 高可用负载均衡集群实践真传》正式面市

本书囊括了常规类型的应用多实例负载均衡（Web或者自定义TCP服务）、传统的异名服务负载均衡（应用A在A主机、应用B在B主机，应用A与B共同组成一个完整的服务单元）以及应用自身负载均衡（如MongDB分片集群）。本书所涉及的软件工具，除Oracle数据库外，全部开源，且可无障碍地部署在物理主机或者虚拟化环境。负载均衡技术是服务或应用高可用的基础，不论是Web应用，还是数据库，要保证访问的持续性，负载均衡技术的支持不可或缺，至关重要。​"Linux高可用实践真传系列"三本终于全部弄齐了，总的来说算是圆满。

原创 MySQL 8自动备份脚本密码安全警告

这个警告，是MySQL的一种的保护机制，它的要求是：不要在“mysql”指令与“mysqldump”指令后，不要显示的指定密码选项“-p”。为验证思路的正确性、避免风险，撰写一个完整的脚本，将备份的脚本中“mysqldump”指令改成“echo”，逐行输出库名，完整的Shell脚本（文件被命名为bkdb.sh）内容如下.输出的确如我所期待,再将“echo”所在的行改成“mysqldump”备份的文本，修改后的备份脚本“bkdb.sh”的完整内容如下。系统命令行，运行这个脚本，具体的指令和操作如下。

原创 这MySQL错误日志异常也太猛了吧

保存并退出编辑模式，如果需要验证任务的正确性和有效性，可以把执行时间修改到相当近的一个时间点，然后对比任务执行前与执行后，错误日志文件“mysql.log”的大小，同时查看cron日志是否执行了这个计划任务，如下图所示。打开”mysql.log”大文件，发现全是些警告信息，用系统命令“tail -f mysql.log”，屏幕输出翻滚犹如电动机飞轮，具体的数据如下图所示。由于用户账号比较多，设计到多个业务，相比之下，不记录警告信息更容易一些，反正这些警告信息没什么用（让它记录真正的错误日志，有助于排错）。

原创 踩坑了，MySQL数据库生成大量奇怪的大文件

回顾一下最近所做的操作，突然想起上周主从不同步，延迟特别大（4万多秒），为了处理这个主从不同步的麻烦，对MySQL的选项文件“/etc/my.cnf”做了修改，因为是从库，就决定将数据库的二进制日志记录给关闭，将文本行“log-bin = mysql-bin”变更成“log-bin = OFF”（还增加了其它的项，这里不做展开）。更改好选项文件之后，重启MySQL服务，确保主从复制正常的情况下，检查二进制日志生成的状况，具体的操作是，MySQL客户端登录MySQL，执行下列操作进行验证。

原创 挽起袖子正式开工

预计半年左右完工，寻厂商赞助。

原创 老司机用脚本批量巧删恶意文件

正确执行命令“screen”后，系统立即返回Shell提示符，这时，正式输入如下指令对疑似有问题的共享目录进行完整扫描，并把输出记录到日志文件”/var/log/clamscan.log”。假使这种形式分布的恶意文件成千上万，用手工逐一删除的方式基本无法完成。在此指令后，增加管道并配合“xargs”传递参数，就可以将扫描出来的恶意文件全部清理掉，不管它分布到什么路径，完整的命令如下所示。执行完毕，随机找几条扫描出来的恶意文件全路径，文件应该不存在(如下图所示)，则表明脚本正确，正是我们所期待的结果。

原创 金融行业现场故障处理实录

找一台运行正常的，版本一致的系统，对比/etc目录里各种权限与验证有关的目录和权限，如 passwd、shadow、ssh等。用chmod指令逐一进行修改，修改一些权限以后，重启系统，直到能正常运行，并且能用ssh远程登录。通过沟通，了解到是用户自己在远程执行一個ssh脚本，此脚本有一行”chmod –R 777”的指令，本意是共享一個nfs服务目录，但因为为对目录是否存在进行判断，因此一执行完脚本，所有的目录文件的权限都变成777了。重启完成后，在目录/var/crash确实生成了大文件，大小为4G。

原创 Linux部署配置远程日志服务

修改文件/etc/rsyslog.conf，增加一行“local3.* @172.16.98.39:514“,保存修改，然后执行命令service rsyslog restart重启服务。服务器端及客户端都使用同一个工具 rsyslog，用rpm -qa | grep rsyslog 指令检查包是否被安装，如果没有安装，可用yum install rsyslog进行安装。为更方便理解，这里以两个客户端为例，一個客户端把ssh登录日志传输到服务器端，另一个客户端把自定义日志传输到服务器端。

原创 Proxmox VE 8 试装Oracle 23c

与以前的版本不同的是，Oracle 23c不能用“sqlplus / as sysdba”登录，而是需要用用户名和密码（Oracle 23c免费版本所有账号密码皆为“oracle”，包括Oracle Linux Server 8操作系统密码），完整的登录指令及输出如下。先来证实前边的猜想“一个系统盘和一个数据盘”，命令提示符执行“df -h”,果然是如此，系统盘“/dev/sda”,数据盘“/dev/sdb1”挂接到目录“/opt/oracle”,如下图所示。如果系统正常启动，但又无法登录，如下图所示。

原创 Proxmox VE 8安装OpenSuse和部署JumpServer

幸运的是，官方提供一键式在线安装脚本，将这些组件以Docker镜像方式进行安装部署，极大的简化了操作，提高了效率。连续鼠标单击几次“Yes”或“Next”按钮，选择安装程序给出的默认值，直到系统角色（System Role）这个交互界面，单选“Server”（最小化安装模式，节省时间和空间）进入下一步，如下图所示。用准备好的JumpServer可引导U盘，或者直接将ISO镜像文件挂接到创建好的虚拟机，启动机器（或者虚拟机），进入引导界面，输入命令“nuke”,系统自动执行完全恢复操作，如下图所示。

原创 试用统信服务器操作系统UOS 20

必须将必选项设置完成并正确以后，才可以进行正式安装（界面右下角的“开始安装”按钮才会由灰色变成蓝色），点击“开始安装”按钮，等待安装自动进行，如下图所示。在进行安装源选择的时候（local iso file），可能会提示“没有发现mount 到本地的ISO”文件，这个可能是bug，不用理会，只要到最后一步，输入字符“b”能够进行安装即可。在选择MySQL版本之前，需要查询一下UOS 20的glibc版本，执行的命令是“rpm -qa|grep glibc”,输出的结果为“glibc2.28”，如下图所示。

原创 Proxmox VE 超融合集群销毁Ceph Pool

一套五节点的Proxmox VE超融合集群，当初为有效利用资源，配备了Nvme高性能磁盘和大容量的SATA机械磁盘（如图所示），高性能Nvme磁盘用于虚拟机的系统盘、数据库的数据存储盘，而大容量的机械盘则用于存储诸如图片、视频、共享数据等对性能要求不高的场景。如果顺序反了，再逐步销毁Ceph OSD的过程中，还没有被销毁的Ceph OSD会自动做数据平衡，如果销毁的Ceph OSD数量小于Ceph 集群所需要的最少值，系统报错，可能会引起其它问题，让人不安。”给销毁了，因为这个再次创建就很费劲了！

原创 Proxmox VE 8 安装开源监控平台Centreon 23

从官网下载来的是一个压缩文件“centreon-vmware-vm-23_10-1.el8.zip”,解开此压缩包后，生成一个以“.ova”的单个大文件（最终解压后，是4个文件），而Centreon 23.04版本压缩文件解压后，生成的是4个大小不一的文件，如下图所示。以ISO方式安装的Centreon，需要手动创建数据库账号，才能进行Centreon 运行环境的下一步配置，以虚拟机方式恢复出来的Centreon， 简化了创建数据库账号和运行环境检查这个过程。123”，如下图所示。

原创 Proxmox Backup Server（PBS）从2.X升级到PBS3

在准备好新的操作系统及PBS 2.4以后，再次修改“/etc/apt/source.list.d/pbs.list”文件，将“bullseye”替换成“bookworm”，保存修改然后执行命令“apt update && apt dist-upgrade”进行版本升级。登录Debian系统，用编辑器或者工具“sed”将“bullseye”替换成“bookworm”，我这里用指令“sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list”。

原创 被他人错误解析域名到雷池 WAF网关的处理办法

所有项目的网站在WAF的保护下运行平稳，大家以为可以稍微松一口气了，突然，相关人员接到IDC机房打来的电话，告知提供网关服务的WAF所使用的公网地址，同时被解析到不相干的域名，需要立即处理，不然就要封IP，而且给出了时限（限定一个小时内处理）。下图为添加WAF前与添加WAF的结构对比。乘热打铁，切换到目录“/data/safeline/resources/nginx/custom_params”，找到文件backend_20(这个文件也是在WAF Web添加域名后，自动生成的)，默认情况下，它是个空文件。

原创 将Gitlab迁移到内网Proxmox VE

登录源服务器，查看Gitlab配置文件“gitlab.rb”备份路径的设置，执行导出操做后，备份文件将在此目录生成，用指令” grep backup_path gitlab.rb |grep -v \#“搜索出备份路径为”/data/backups“,如下图所示。关闭Centos的”firewalld“服务（服务器在内网，无需使用主机防火墙），并将“selinux”的值由“enforce”设置成“disabled”，减少干扰因素。导入完毕，执行”gitlab-ctl start” 启动Gitlab服务。

原创 Proxmox VE 超融合集群不停服务新增配置（磁盘）

关掉集群中任意一台物理服务器，拔出所有的SATA硬盘，再插入新的Nvme高速磁盘，在关机以后，运行在该节点上的虚拟机全部自动飘逸到其它节点上。选定同时处于“down/out”状态的OSD磁盘，单击右上方按钮“更多”，再继续单击子菜单“销毁”，如图。更换完新盘的服务器开机，新插入的Nvme被Proxmox VE所识别，然后继续在Web管理后台，对单个磁盘执行创建OSD的操作，进行销毁，这个步骤也是必须的，否则硬盘拔掉后，开机，会遗留一些问题，引起感官上的不舒服（强迫证）。盘，如果顺序反了，在销毁。

原创 在线更换Proxmox VE超融合集群Ceph OSD磁盘

因为资源紧张的原因，担心一旦关机，虚拟机因为没有空闲的资源而被冻结，以致于不能漂移，导致部分服务停止，只好让机房帮忙热插拔。幸运的是，插上去能够被系统所识别（/dev/sdf就是新插入的硬盘）。开始对新加入磁盘的服务器做创建OSD操作。

原创 半夜三更的，Proxmox VE集群的ceph OSD磁盘挂了

这几天centreon监控频频报警，提示ceph pg 错误，用 ceph health detail 确定不一致的pgs，然后用指令 ceph pg repair pg_num 进行修复，通过查看系统日志，有IO错误，修复一次，能管半天，提醒决策人买新硬盘换上，不理睬，今天终于挂掉了，虽然不影响业务，但资源总体利用率超过70%，一旦节点挂掉，虚拟机连漂移的机会都没有。Ceph OSD磁盘自己down了，不打算在mount。系统自己在那里做平衡操作呢！

原创 服务器被持续攻击

持续gong击俺管理的服务器，有什么好处呢？弄得我好一阵不能安稳，画个雷符治死你们信不信？

原创 高龄服务器终于挂掉了

硬盘报错，系统盘没问题，是一块独立的SCSI盘坏了，里边存储的是MySQL用户数据，可以访问目录，查看文件属性，企图将MySQL整个数据库目录完整拷贝出来（cp或rsync），失败。妥妥的连续运行了3018天，在本次开机以前，它就是一台老龄服务器，最初在我手里投入使用的时间是2010年，由此推断，此服务器可能有20岁了。最终没有办法快速修复，用备份的sql文件进行数据恢复（到别的存储空间）连续运行了3018天的高龄服务器硬盘挂了，昨晚整了一个通宵，困极。负载不高，IO稍微有点高。

原创 网站频频告警故障排查实录

登录到主站所在的虚拟机，执行指令“netstat -anp| grep -v unix”查看网络状态,从屏幕输出发现大量的“TIME_WAIT”（如下图所示），记录下与之关联的IP地址及端口，通过简单统计，得知IP地址为“172.16.98.124”，端口为“3306”的系统，遗留的信息最多，由此判断，故障应该有数据库“172.16.98.124”关系密切。在有问题的系统上，关闭MySQL服务，卸载分区“/dev/sdb1”,正式执行”fsck -y /dev/sdb1”进行文件系统修复。

原创 给Proxmox VE 虚拟机分配巨大分区惹麻烦

由于缺乏良好的规划，有开发人员直接在公有云采购一个容量超过100TB的NAS存储，使用过程中，数据的存储也没有规划，业务数据一股脑的写入到同一个目录，下边的子目录没有规律，用用户的图片、视频、访问日志、甚至还有备份。为解决共享存储问题，购买了专门的设备，就是普通服务器插很多硬盘，SSD安装系统，NVME做缓存，部署TrueNAS，然后将Proxmox VE集群上的那个大分区的数据迁移，彻底排除集群的隐患。这几天，开始释放这个巨大巨大无比的虚拟机，删除起来还很费时，差不多24小时，才进行到40%多。

原创 centreon 23版本换界面了

没有与操作系统一起打包的ISO文件了，要么先安装系统，再安装Centreon，要么用pve导入OVF文件。

原创 MongoDB负载均衡集群监控

对负载均衡的集群监控，不仅仅集中在对集群所有的资源、服务等进行监控，还要兼顾整体逻辑。以MongoDB高可用负载均衡集群为例，对逻辑层面的监控，就是模拟用户行为，访问集群数据，判断运行状态是否正常。MongoDB集群内置一个名为“db.serverStatus()”的工具，用它可以来监控整个集群是否处于正常状态。用客户端“mongosh”登录MongoDB集群路由“mongos”，切换到管理员用户“admin”，交互界面执行“db.serverStatus()”，部分输出如图9-2所示。

原创 MongoDB负载均衡集群（第8章节选）

MongoDB自身可组成分片加复制的集群，在这个集群的前端加上负载均衡器（比如HAProxmy + Keepalived），就可组建成一个无单点故障、十分完美的高可用负载均衡集群（如图8-1所示）。整个MongDB高可用体系结构中，存在四个应用集群：入口路由集群Mongos、配置集群“Config Server”、分片集群1、分片集群2。入口路由集群“Mongos”由负载均衡器来实现高可用及负载均衡功能。配置集群“Config Server”的高可用及负载均衡有MongDB自身功能实现。

原创 升级系统到Proxmox VE 8

Proxmox VE 需要升级到7.4，验证一下。Proxmox VE 8.0正式版发布。升级完毕，多了一个本地网络。

原创 MySQL 读写分离代理（Mycat2）

在Mycat2的安装目录“/usr/local/mycat”下，存在目录“logs”，打开此目录中的日志文件“wrapper.log”，可了解Mycat2服务的运行状况，如图7-11所示。启动Mycat2服务，需要有真实的数据库服务器支撑才能运行，因此，需要在MySQL服务器（其它被Mycat2支持的数据库也如此）创建账号并给账号授权，然后在Mycat2所在的宿主系统用MySQL客户端用创建好的账号远程进行连接，验证账号的有效性和正确性。执行完安装，将在自动生成目录“/usr/lib/jvm”。

原创 6.6.4 PCS创建Oracle 资源及资源组

上边这些资源，在PCS里创建好以后，将其组合成一个单独的资源组，形成一个不可分割的整体。Oracle 的VIP资源在前边已经添加，那么接下来就从第2项监听器开始。为了方便安排各资源的启动顺序，可以先勾选已经存在的资源“db_vip”创建资源组“db_grp”,然后再创建监听器。