sftp多实例使用F5负载均衡

背景

公司机房做整体搬迁，我负责运维的一套sftp-server文件服务系统，在迁移到新机房后，问题频发。
外部合作伙伴连接这套前置机上传文件，总是报sftp密钥信任错误，导致文件上传失败。
系统上线十几年，登录主机查看运行时长，10年没有关过机（操作系统Redhat4）。
当初接到迁移任务时，是一百个不情愿，有多少坑，谁也说不准，哪怕出个小问题，排查起来费尽周折，更别提来自业务上的压力。
但胳膊拧不过大腿，不想做也得做，怀着诚惶诚恐的心情，使用快照克隆的方式，把这套集群迁移走，不出意外，变更实施完，接下来的2周内，接连暴雷~

基础架构

sftp服务使用F5做负载均衡，外部合作伙伴访问22端口，向这套主机上传文件，基本结构如下（默认防火墙放通22端口）

SSH公钥检查

sftp底层使用ssh协议通信，在ssh加持下，当第一次连接外部server，客户端会提示服务端的指纹，并征询接下来的动作。

sftp maxscale@*.*.*.*
The authenticity of host '*.*.*.* (*.*.*.*)' can't be established.
ED25519 key fingerprint is SHA256:WFcR0mUNvg3ZcYnFi/HzXrsOR34o8InXf/yXyTGfKkA.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?

输入yes,服务端的公钥会被记录在客户端~/.ssh/known_hosts文件中，基本格式是”ip/hostname+空格+公钥字符串”。
当服务端有如下变更时，会导致客户端保存的密钥失效，如：

重装操作系统
IP地址变化
虚拟机重建
中间人劫持
DHCP
很多涉及sftp的应用，都会因为密钥信任，导致莫名其妙的问题。

解决方案

方案一，客户端关闭密钥检查(不推荐)
修改~/.ssh/config文件，加入
1
2
Host *
StrictHostKeyChecking no

方案二，登录命令加入ssh选项，跳过公钥检查

1
2
3

sftp -o StrictHostKeyChecking=no  maxscale@*.*.*.*
Warning: Permanently added '*.*.*.*' (ED25519) to the list of known hosts.
maxscale@*.*.*.*'s password:

方案三，删除之前保存的公钥，重新信任一次

# 可以直接删除
sed -i '/192.168.1.102/d' ~/.ssh/known_hosts
# 可以使用命令删除
ssh-keygen -R <ip>
# 重新执行sftp登录命令...
sftp maxscale@ip
...

F5后端多个sftp实例，执行秘钥同步

F5后端有多个sftp实例，需要同步实例之间的sftp秘钥（同步文件后，重启sshd服务），否则客户端登录仍然面临秘钥信任问题。
当然，如果客户端跳过公钥检查，这个问题就不会存在。

后端sftp多实例，文件同步问题

银行客户端有两个连续动作，登录sftp成功后，先创建1个日期目录，然后向目录内上传文件。
明明都操作成功了，但内部系统就是获取不到文件，是为啥？
经过检查，F5后端有两个sftp实例，客户端两步操作，都打到后端不同实例，即创建目录在一个实例，上传文件却在不同的另外一个实例。

解决方案

方案一，F5根据source_addr, 设置会话保持。
设置以后，来自同一个客户端的请求，会被分发到后端固定实例。
方案二，使用NAS卷，主机挂载网络存储，两个实例的数据目录，指向同一个NAS目录即可。

双活方案

根据集团运营督导要求，每一套应用系统，都要搭建同城/异地双活，入口使用双活域名做负载。
搭建完双活系统的新架构如下图：

这里需要补充以下几点：

由于涉及双活切换，两套前置机系统必须挂载相同NAS卷（网络存储），共享文件存储系统。
sftp账号是和系统账号绑定，由于共享NAS存储，两套双活环境，涉及sftp服务的实例，在创建sftp账号时，需使用相同的group-id和user-id。
两套双活环境，需统一sftp实例的密钥文件，前端F5设置好会话保持功能。