技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> 查看专题: p2p
    考虑到我手上的服务器逐渐的增多,有时候需要大规模的部署同一个文件,例如因为方便使用systemtap这个工具定位问题,需要把手上几百台服务器同时安装kernel-debuginfo这个包,原有的方式采用一个源服务器,采用rsync或者scp之类的文件传输方式只能做到一个点往下分发这个文件,这个时候下发的速度就会比较的慢,基于以上原因,我写了一个基于bt协议传输文件的小工具,实际测试,传输到10个机房,70多台机器传输一个240M的这个内核文件,到所有的机器,源采用限速2m/s的上传速度,测试的结果大概只要140s,就可以全部传输完毕,这个效率是非常之高,如果不限速的情况下速度会更快,下面把这个程序开源出来。
    NAT是在传输层及以上做的,传输层最主要的2个协议是TCP和UDP。对于TCP和UDP而言,每个包都有很基本的4个要素:src ip、src port、dst ip、dst port。 根据在做NAT的时候是否保留src ip和src port,可以把NAT分为这么三种: Cone: 将src ip映射到一个固定的IP,并且将src port映射到一个固定的Port,无论dst ip和dst port是什么。 Single IP address, symmetric:将src ip映射到一个固定的IP,将src port映射到一个随机的port,但是保证对于相同的(dst ip,dst port), src port始终相同。(否则双方没法通话啊,回来的包回给哪个端口呢?) Multiple IP address, symmetric:与上面类似,但是src ip可能会有多个。
    从09年第一次阅读Dynamo论文,到最近阅读Amazon S3的一篇专利,一路过来对论文的理解可以简单归结为两个字
    分享下2年前做过的一个传输项目,比较粗糙,当年的相关文档找不全了:( 背景:运维中经常遇到这类传输需求,A生成数据,然后将数据分发到下游B1,B2,B3….Bn。传统的做法有如下几种: A生成数据文件后,顺带生成flag(标记文件)。下游机器配置定时任务,定期探测A机器的数据是否生成,当生成后通过wget下载 A生成数据文件后,直接通过scp将数据推送到下游机器。 上述方式一般都采用系统命令和SSH信任关系,对系统依赖较强...
[ 共4篇文章 ][ 第1页/共1页 ][ 1 ]
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1