WAN口环境拉取和推送数据

== 这是一个很老的话题了。

使用rclone

使用rclone ,服务端搭建http或者webdav,然后客户端拉取数据,这个方式速度最快,但是有缺陷,就是占用cpu较高。同时像union,syncthing,要么速度慢,要么是字节检测。不适合自己的场景。

这次考虑更换方式。

使用多线程的rsync

以前自建脚本

用过ssh连接,find 在远端机器生成files类型文件,再远端拉取数据。

现在脚本没找见,试试其他的。

使用parallel

可用parallel或者xargs 作为多次命令输入查询

parallel -j {number} number用来限制rsync的最多启动数量

或者可用find . 查询,使用占位符,这里有delete 需要小心。

!!! 注意是本地推送到远程。

find -L -type f | parallel -j 8 -v rsync -razHXSR –ignore-errors –stats –info=progress2 –delete {} /目的端地址

使用parsyncfp

http://moo.nac.uci.edu/~hjm/parsync/

结合fpart部分, fpart的前身。

pfp 只需要安装在传输的 SOURCE 端,并且只能在本地 SOURCE -> remote TARGET 模式下工作(它不允许远程本地 SOURCE <- remote TARGET,如果尝试,会发出错误并退出)。它要求在操作之前设置 ssh 共享密钥,请参见此处。如果它检测到 ssh 密钥设置不正确,它将请求许可以尝试纠正这种情况。检查您的本地和远程 ssh 密钥以确保它已正确完成。通常,它们位于您的 ~/.ssh 目录中。

使用fpart

fpart下面有对应的fpsync,可以使用。

注意格式,这里也是只能推送,无法src是远程端。

可以考虑用tailscale。。。(发现tailscale 也会大量占用cpu,大概能发到360Mbps的数据,实际接受24MB/s,还是有一定的损耗的。)

考虑到CPU占用,实际使用http或者webdav更方便些。

!!! 更新,尝试了webdav,结果cpu完全打满,后限速到80Mbps,tailscale高峰有接近360mbps,就是解包占用流量较多。

最后测试后决定tailscale加上fpsync 走一波,次之考虑rclone 的http或者webdav。

# Check if $1 is a valid rsync URL
# Cf. rsync(1) :
#   SSH:   [USER@]HOST:DEST
#   Rsync: [USER@]HOST::DEST
#   Rsync: rsync://[USER@]HOST[:PORT]/DEST
# Simplified as: "anything but slash" followed by at least one ":"
fpsync  -vvv -o '-avm --numeric-ids --safe-links' -n 10 /etc/ /root/rsyncexp
#### 这里的可以用,一般会有errors,需要第二轮
fpsync  -vvv -o '-avmr --numeric-ids --safe-links --password-file=/etc/rsyncpasswd ' -n 16  /home/mxuan/torrents/qbittorrent/ admin@100.125.250.65::B2/MKV/et8-1/

使用python的wrapper

from parallel_sync import rsync                                                 
                                                                                
creds = {'user': 'root', 'key':'/root/.ssh/id_rsa', 'host':'168.235.72.82'}     
                                                                                
rsync.download('/home/mxuan/torrents/qbittorrent/', '/data/', creds=creds)

这里测试时候,没有流量判断,而且上面有显示rsync连接失败,具体的不明确,有些不敢用。。

第二次使用时候,提示no dir。不知道原因

小结

  • 使用qbox,ssh默认开启密码登录,有很多人在扫22端口,出现了将/root文件夹变更到1024:user 权限的情况。然后ssh就无法登录了。

排查了好久才排查出来,

  • tailscale的两方都需要进行加密解密,跑到24MB/s 的情况下,j3150的CPU占用80%s,ramnode的cpu占用80% (2G的存储型kvm)

  • 流量上400mbps的流量出,到解包之后只有200mbps,不知道丢包率。。

  • 如果本地跑的机子能够开22端口跑rsync,那么就是跑的最佳方案了。。

  • 国内的pt站,挂载到国外效率低,应该侧重增加国内机子的上传带宽。


udp2raw可以用bbr等拥塞控制协议。。

比如说,由于运营商一般会对UDP流量进行策略化监管或者限速,目前,有一种非常简单的UDP双边加速的方式就是,仅仅将协议号由UDP改成TCP即可!而UDP允许一定程度的丢包,所以说,路由器交换机的AQM对其而言,就是刑不上大夫!

  • 凡是涉及到dsm的,优先使用网页端的rsync。

  • PVE 使用桥接速度直接砍半??

    • image-20220715114556460
  • 可能是ip的包需要走192.168.0.1路由中转,然后只是一根线所以跑满了上联的那根线??

  • 更换网关到192.168.0.2 ,没有反应,说明网关是内网跨到外网时候使用的。

    • image-20220715121759496