[讨论] Freeshell 与科大云合作？

[Bojie Li]

Freeshell 磁盘紧张，3 号节点的磁盘已经快满了。少院这 7 台机器作为全校范围的公共服务实在是捉襟见肘。

我听说科大云（cloud.ustc.edu.cn）有比较多的硬件资源，也有足够的公网 IPv4 地址池，但由于技术原因服务不太稳定。能不能通过 LUG 指导老师 jameszhang 牵线，我们为科大云提供技术支持，把科大云变得更稳定易用。北京分舵前些天聚会时，几位前辈提到 “取代 FTP 的云文件系统” 这个未竟的愿望，这也需要比较大的存储资源池。

功利地说有几个好处：

• 可以把虚拟机用到课堂上，每人一个克隆出来的虚拟机，省去配置开发环境的麻烦。
• 助力校内与互联网相关的创新创业项目。（现在申请机器是个麻烦事）
• 参与科大云平台开发的同学把它写进简历，一定是个加分项。
  
• 我们 LUG 再也不缺机器和存储空间了。现在我们的资源只够做 LUG 会员范围的服务，如果傍上科大云这个资源池，就能做全校范围的服务了。

接下来的一年我多数时间在学校，可以跟小伙伴们一起把学校的云平台真正搞起来。大家觉得这个想法怎么样？

[Yuanchong Zhu]

能协调好资源就行。直接去找jameszhang吧

--
-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en

---
You received this message because you are subscribed to the Google Groups "USTC_LUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
灿烂星空，你就是我的英雄！

[Zhang Cheng]

我甚至觉得可以尝试要一批配置更好的机器。

Cheng,

Best Regards

[Bojie Li]

2014-05-26 18:27 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

我甚至觉得可以尝试要一批配置更好的机器。

据说科大云有上千台物理机器，这是真的吗？

[Bojie Li]

@stephen @snullp 能不能说说你们的 “云文件系统” 设想，我记得有个 PDF 的，不过找不到了。另外几年过去了，你们增加了很多经验，之前的想法是否有变化，也说说吧。

2014-05-26 18:09 GMT+08:00 Yuanchong Zhu <redsk...@gmail.com>:

[Zhang Cheng]

​没听说过具体的事情。不过感觉不可能有这个配置，学校机房放不下。每个机架可以放14台设备左右，1000台得几乎上百个机架。我相信那帮人搞运维也搞不过来。

--

Cheng,

Best Regards

[Zhang Cheng]

2014-05-26 18:29 GMT+08:00 Bojie Li <boj...@gmail.com>:

@stephen @snullp 能不能说说你们的 “云文件系统” 设想，我记得有个 PDF 的，不过找不到了。另外几年过去了，你们增加了很多经验，之前的想法是否有变化，也说说吧。

​当时的想法比较简单幼稚，只对期望的效果有想法，但对具体的实现、可行性都没有做过调研。现在snullp对这方面比较有经验，我再说一下我当初的想法吧，大家可以探讨一下可行性。

​我当时的想法大致是这样的：

​* 存储分为两类，用户数据和系统数据。

* 用户数据大家的都是不一样的，可以考虑使用比较成熟的分布式文件系统，例如AFS之类的。

  - 用户免不了会传一些共同的数据，比如相同的电影，可以​考虑文件系统层面支持去重的能力，例如文件系统按hash进行存储，相同的文件只存一份。

​* 系统数据主要是只读（或者说在客户端永远只读），服务器成了瓶颈，例如在LUP上大家一起玩PXE的话，PXE的带宽就成了瓶颈，大家的体验全都会变差。对此我想有两种方案可行：

  - 部署多个服务器，并且在NFS的基础上，能够加上一个load tracker，每个客户端自动选择比较优秀的节点。这样的做法，可扩展性比较差，比如我期望的效果可能是几千人同时在线（整个本科生宿舍都在用），当客户端增加，服务器数量也需要成比例增加。

  - ​做一个p2p的文件系统，所有的客户端都参与分发文件。当时觉得p2p的延迟比较高会是一个文件。不过现在觉得如果有比较好的预取机制的话，效果应该也不会太差。

​    - 这个p2p的系统需要做许多调优。例如将整个squashfs分成4M(这个数字我随便说的)的chunk，这个chunk作为最小传输单位，即​对于一个chunk，只从一个peer取，不再细分，继续细分会导致调度和验证变得复杂。

​    - 调度时尽量让同子网的人互相通信。

    - 可以采用p2p+CDN混合机制，设置一个阈值，例如对于一个chunk，在发起peer请求后1 ms内没有​开始传输或者N ms内没有完成传输，则自动开始从服务器上下载。

大致就这些想法吧。其实还有许多比较粗略的优化想法，如果真有这样的系统，能做的事情挺多的。​

--

Cheng,

Best Regards

[Zhang Cheng]

2014-05-26 18:45 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

​* 系统数据主要是只读（或者说在客户端永远只读），服务器成了瓶颈，例如在LUP上大家一起玩PXE的话，PXE的带宽就成了瓶颈，大家的体验全都会变差。对此我想有两种方案可行：

  - 部署多个服务器，并且在NFS的基础上，能够加上一个load tracker，每个客户端自动选择比较优秀的节点。这样的做法，可扩展性比较差，比如我期望的效果可能是几千人同时在线（整个本科生宿舍都在用），当客户端增加，服务器数量也需要成比例增加。

  - ​做一个p2p的文件系统，所有的客户端都参与分发文件。当时觉得p2p的延迟比较高会是一个文件。不过现在觉得如果有比较好的预取机制的话，效果应该也不会太差。

​    - 这个p2p的系统需要做许多调优。例如将整个squashfs分成4M(这个数字我随便说的)的chunk，这个chunk作为最小传输单位，即​对于一个chunk，只从一个peer取，不再细分，继续细分会导致调度和验证变得复杂。

​    - 调度时尽量让同子网的人互相通信。

    - 可以采用p2p+CDN混合机制，设置一个阈值，例如对于一个chunk，在发起peer请求后1 ms内没有​开始传输或者N ms内没有完成传输，则自动开始从服务器上下载。

​从现在的角度看，意思就是，这里用p2p虚拟一个块设备，而不是文件系统。因为文件系统需要处理的事情太多太杂，而块设备则会简单很多。但是这个块设备不能是太抽象的，不能是“通用”块设备，即上面不允许使用ext4等文件系统，可以搞成squashfs或者类似的东西，这样内容的分布是可控的，于是可以方便的做预取优化。

--

Cheng,

Best Regards

[Bojie Li]

2014-05-26 18:45 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

​* 系统数据主要是只读（或者说在客户端永远只读），服务器成了瓶颈，例如在LUP上大家一起玩PXE的话，PXE的带宽就成了瓶颈，大家的体验全都会变差。对此我想有两种方案可行：

系统从网络上启动相比从本地启动有什么优点呢？除了体验一些新的发行版，大多数时候我们还是习惯使用一个或两个操作系统，为什么要每次从网络上启动呢？如果只是为了体验新发行版，几千人同时在线的情况应该不会出现吧。

PXE 服务器是千兆网卡还是百兆网卡，多少人同时网络启动时带宽就成了瓶颈？

[Bojie Li]

2014-05-26 18:45 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

* 用户数据大家的都是不一样的，可以考虑使用比较成熟的分布式文件系统，例如AFS之类的。

  - 用户免不了会传一些共同的数据，比如相同的电影，可以​考虑文件系统层面支持去重的能力，例如文件系统按hash进行存储，相同的文件只存一份。

校内用户的共同数据多吗？应该是规模越大，去除冗余的效果越明显，对百度、迅雷之类的大型公共服务能行，校内的行吗？（瀚海星云存储在做去除冗余这件事，不过似乎用的人不多）

[Zhang Cheng]

2014-05-26 23:42 GMT+08:00 Bojie Li <boj...@gmail.com>:

系统从网络上启动相比从本地启动有什么优点呢？除了体验一些新的发行版，大多数时候我们还是习惯使用一个或两个操作系统，为什么要每次从网络上启动呢？如果只是为了体验新发行版，几千人同时在线的情况应该不会出现吧。

PXE 服务器是千兆网卡还是百兆网卡，多少人同时网络启动时带宽就成了瓶颈？

​网络启动有这些好处：

*​ 适合用于批量使用同一类型的系统。例如我想有这样的场景：某课程A的实验需要一套环境，该课程助教制作好一个镜像，大家启动这个镜像就可以做进行实验。这个系统可以在实验室应用，也可以在其他地方，例如树华或者寝室，学生可以在任何地方进行实验。

* 可以在不同的地方使用相同的系统，上述场景是一个，这里再说一种场景。许多人并没有自己的电脑，而到公共场合（例如树华）则只能使用给定的系统，每次去都会被还原。但如果可以在任何一台电脑上启动一个相同的系统，并且启动后所有的配置都保留，甚至安装的软件也都保留，那么他就可以在任何能上网的地方使用“自己”的系统了。

我想的使用场景并不仅仅是体验。如果有一天网络启动可以很成熟并且方便的维护，那么不排除这种可能性，学校为每个同学在寝室配置一台电脑，这台电脑没有硬盘，不可以自己安装系统（当然主机箱也可能进行物理封装）。电脑可以从网络启动一个或者若干个专门为学习定制的系统，可以进行各种课程的学习、实验、作业，甚至线上交流等活动。

PXE似乎是百兆网卡吧，记得有一次（似乎不止一次吧）在LUP的时候，大家在现场体验PXE，当自行体验时间开始时，大家同时启动，并且有许多人使用live系统，那个时候大家体验其实都挺慢的。但我没有做过量化的统计，当时pxe也没有collectd/ganglia这类的工具记录系统的带宽情况。

--

Cheng,

Best Regards

[Zhang Cheng]

2014-05-26 23:47 GMT+08:00 Bojie Li <boj...@gmail.com>:

* 用户数据大家的都是不一样的，可以考虑使用比较成熟的分布式文件系统，例如AFS之类的。

  - 用户免不了会传一些共同的数据，比如相同的电影，可以​考虑文件系统层面支持去重的能力，例如文件系统按hash进行存储，相同的文件只存一份。

校内用户的共同数据多吗？应该是规模越大，去除冗余的效果越明显，对百度、迅雷之类的大型公共服务能行，校内的行吗？（瀚海星云存储在做去除冗余这件事，不过似乎用的人不多）

​我觉得这个更取决于这个平台本身如何推广。比如学校的ftp，每个人限制只有300M，因此大家都不会用这个空间来存放大文件，所以大家基本上只是用来存放ppt、小软件、网站等。但是如果给你100G甚至更大的配额，相信很多人都会往上面存电影、系统iso之类的东西了。这些去重效果应该是不错的。甚至如果加上六维离线下载，估计很多人会更乐意使用这个来下，而不是去六维自己拖了。

--

Cheng,

Best Regards

[Hao Xu]

科大云那边我和高一凡已经找过了，问他们要了两台主机，已经同意，正在等待批下来，做成OpenVZ。

这边我和高一凡算是在科大云的实验室。

在 2014年5月26日星期一UTC+8下午5时52分48秒，Bojie Li写道：

[Hao Xu]

高一凡就是Yifan Gao.我是万年潜水党。。。所以和科大云合作不是问题。

在 2014年5月26日星期一UTC+8下午5时52分48秒，Bojie Li写道：

[Yifan Gao]

我和 @HaoXu在负责科大云轻量级虚拟化的部分的开发。目前正在开发API，由于需要与OpenStack整合，正式上线还需要一段时间，希望各位LUG成员有兴趣一起来开发。

目前科大云3.0的全虚拟化，已经较为完善，但磁盘仍然是较大的瓶颈，虚拟机一多，IO性能大幅降低。

-- 
Yifan Gao

开启 2014年5月26日 at 下午5:52:47, Bojie Li (boj...@gmail.com) 写:

[Bojie Li]

2014-05-26 23:51 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

网络启动有这些好处：

*​ 适合用于批量使用同一类型的系统。例如我想有这样的场景：某课程A的实验需要一套环境，该课程助教制作好一个镜像，大家启动这个镜像就可以做进行实验。这个系统可以在实验室应用，也可以在其他地方，例如树华或者寝室，学生可以在任何地方进行实验。

哦，这种需求我设想成在云上开一些虚拟机了，每个人都远程登录到自己的虚拟机上操作。用自己的电脑启动云端存储上的系统可能数据传输量要大一些，但可以节约云端的 CPU 和内存资源。

下面先讨论在实验室使用的情况。

如果是一个实验室同时使用一个网络操作系统做实验，网络启动的带宽是 P2P 无法彻底解决的（相对网启服务器架设在实验室机房的主控室而言）。因为 P2P 不能认出一个机房里哪些机器是一个交换机底下的，只能认出哪些机器是一个路由器底下的，那么一个机房如果有多台交换机，则大部分 P2P 流量是在不同交换机底下的机器之间的。如果这些交换机采用链状结构，则全部流量的接近 1/4 会通过这条链中间那根网线；如果交换机采用星形结构，情况会好一些，则中心交换机和接入交换机的每根连线要承担一个接入交换机下面的机器产生的大部分流量。

假设网启服务器架设在实验室机房主控室里，千兆带宽，50 人同时启动机器，则每个人只能分到 20 Mbps，也就是不到 2.5 MB/s 的下载速度，计算机启动会非常慢。如果采用了 P2P 技术而机房交换机的拓扑结构不够合理，也不容易得到明显的提升，不过假定 P2P 没有额外开销，而且能够合理控制 P2P 连接和回源连接的比例（这些连接是公平争抢链路带宽的），下载速度应该能到 10 MB/s 以上，也许可以接受。但对仍然在使用百兆网络的机房来说，什么优化估计都无济于事了。

这个同时启动同一个操作系统的问题，本质上是多个客户端想同时获取同一个文件的问题。这个问题产生于在线会议系统，最早解决的做法是 IP Multicast，也就是源端只往路由器发一份数据，但路由器把这份数据往局域网的多个端口发送。但这种多播的做法不适用于要求可靠的数据传输，因为要做到可靠就要有应答（ACK），这些 ACK 都回传到源端就会产生经典的 ACK implosion 问题。P2P 技术应运而生，只是多数 P2P 用户并不是同时需要同一份文件，于是大家淡忘了 P2P 起源于直播的历史。由于物理上接近的局域网里很可能没有想要的文件，很多 P2P 系统干脆不考虑网络拓扑结构，而是选取随机的节点。事实上在网络拓扑结构中最适合做 peer 的是路由器，但传统意义上的路由器是不能存储数据的，在教科书里这种端到端的设计原则被称为 “Internet 成功的原因”，潜台词是更优雅的设计由于成本原因被历史淘汰了。现在很多人在研究的 Content-Centric Network，就是让路由器存储转发 URL（可以理解成所有的路由器都是小区缓存），把可靠的数据传输引入 IP Multicast。扯远了，这些 YY 跟网络启动没有关系。

再讨论在树华或者寝室使用的情况。

这时就不像一个直播系统，而像 P2P 分享文件的系统了。不过一般的 P2P，用户在下载文件结束后一般会一直做种，而我们的网络操作系统用户一关机就不再做种了，也就是只能在同时开机的同一个网络操作系统用户之间做 P2P。这个效果能有多好我心里没底。

* 可以在不同的地方使用相同的系统，上述场景是一个，这里再说一种场景。许多人并没有自己的电脑，而到公共场合（例如树华）则只能使用给定的系统，每次去都会被还原。但如果可以在任何一台电脑上启动一个相同的系统，并且启动后所有的配置都保留，甚至安装的软件也都保留，那么他就可以在任何能上网的地方使用“自己”的系统了。

这个是科大本科寝室没网，或者很多学校大一不允许带电脑导致的特殊需求吧……不过看起来确实挺诱人的。

我想的使用场景并不仅仅是体验。如果有一天网络启动可以很成熟并且方便的维护，那么不排除这种可能性，学校为每个同学在寝室配置一台电脑，这台电脑没有硬盘，不可以自己安装系统（当然主机箱也可能进行物理封装）。电脑可以从网络启动一个或者若干个专门为学习定制的系统，可以进行各种课程的学习、实验、作业，甚至线上交流等活动。

学习机？想起了龙芯 8089D……

[Bojie Li]

2014-05-26 23:55 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

​我觉得这个更取决于这个平台本身如何推广。比如学校的ftp，每个人限制只有300M，因此大家都不会用这个空间来存放大文件，所以大家基本上只是用来存放ppt、小软件、网站等。但是如果给你100G甚至更大的配额，相信很多人都会往上面存电影、系统iso之类的东西了。这些去重效果应该是不错的。甚至如果加上六维离线下载，估计很多人会更乐意使用这个来下，而不是去六维自己拖了。

我就是想知道，这些电影、系统 ISO 之类的东西用多大磁盘空间可以涵盖 80%，比如 10 TB 的存储空间可以涵盖 80% 的此类大文件吗？如果可以，我觉得去冗余文件系统还是值得做的。

此外，如果放开使用，用户是不知道什么文件可以去冗余什么文件不可以的，用户很可能放一些个人照片之类很大的文件上去，这些空间也是不可忽略的。我确实不知道国内那些动辄 TB 的云存储是怎么解决个人大文件的存储的。

[Bojie Li]

2014-05-27 1:08 GMT+08:00 Yifan Gao <ylgao...@gmail.com>:

目前科大云3.0的全虚拟化，已经较为完善，但磁盘仍然是较大的瓶颈，虚拟机一多，IO性能大幅降低。

你们用的是 SATA 7200 rpm 的机械磁盘吗？每台物理机上大概开多少个虚拟机？

你们的虚拟化平台是什么（Xen/KVM/OpenVZ）？有没有开启 Intel VT-d Directed I/O？

[Yifan Gao]

科大云使用的是刀片服务器，一共几十个节点，共计500多个物理CPU，占用空间非常小，只有2个机架。科大云2.0目前运行了超过1000台虚拟机。

-- 
Yifan Gao

开启 2014年5月26日 at 下午6:30:10, Zhang Cheng (steph...@gmail.com) 写:

[Bojie Li]

哦，这样看来资源基本上是 freeshell 的 10 倍啊，我早先还以为是 100 倍的量级呢。每个物理节点的 CPU、内存、磁盘配比大概是什么样的？虚拟机数据是集中存储，还是分散在各节点的磁盘上？

[Yifan Gao]

2.0不是我搞的。我记得物理节点是SATA 1T 7200rpm的硬盘，KVM平台，Intel VT-d Directed I/O 不清楚。

目前虚拟机数量与硬盘数量的比例大约是 50~80：1

-- 
Yifan Gao

开启 2014年5月27日 at 上午1:17:09, Bojie Li (boj...@gmail.com) 写:

[Yifan Gao]

我印象中是: 一个刀片 64U/128GB/磁盘大小忘记了(大概几个T吧) ，所有用户数据都是存在节点上的，但允许挂载远程卷(EBS)(有专门的节点管理)

-- 
Yifan Gao

开启 2014年5月27日 at 上午1:21:04, Bojie Li (boj...@gmail.com) 写:

[Bojie Li]

64U 是什么 CPU 型号，几个 socket，有没有开 hyper-threading？

允许挂载远程卷，实际有没有用远程卷？

[Bojie Li]

另外，节点的网络是 1G 网卡还是 10G 网卡？这么好配置的机器，如果上面运行几十个虚拟机，共享 1G 网络出口，跨节点跑 MapReduce 之类的任务估计网络会成为瓶颈吧。

[Yifan Gao]

64U 是什么 CPU 型号

抱歉，我简写了。 是指64颗CPU 我记得型号是Core2  T7700

几个 socket

指什么的socket？

有没有开 hyper-threading？

没有

允许挂载远程卷，实际有没有用远程卷？

登陆科大云(cloud.ustc.edu.cn)，左侧导航栏进入“申请运资源” -> 点击“EBS管理” -> “创建EBS卷” -> 回到“云主机管理” -> 点击虚拟机右侧的 “+” 挂载刚才创建的EBS卷

当然 还得在系统中初始化磁盘，然后mount

-- 
Yifan Gao

开启 2014年5月27日 at 上午1:29:08, Bojie Li (boj...@gmail.com) 写:

[Zhang Cheng]

2014-05-27 1:09 GMT+08:00 Bojie Li <boj...@gmail.com>:

哦，这种需求我设想成在云上开一些虚拟机了，每个人都远程登录到自己的虚拟机上操作。用自己的电脑启动云端存储上的系统可能数据传输量要大一些，但可以节约云端的 CPU 和内存资源。

下面先讨论在实验室使用的情况。

如果是一个实验室同时使用一个网络操作系统做实验，网络启动的带宽是 P2P 无法彻底解决的（相对网启服务器架设在实验室机房的主控室而言）。因为 P2P 不能认出一个机房里哪些机器是一个交换机底下的，只能认出哪些机器是一个路由器底下的，那么一个机房如果有多台交换机，则大部分 P2P 流量是在不同交换机底下的机器之间的。如果这些交换机采用链状结构，则全部流量的接近 1/4 会通过这条链中间那根网线；如果交换机采用星形结构，情况会好一些，则中心交换机和接入交换机的每根连线要承担一个接入交换机下面的机器产生的大部分流量。

假设网启服务器架设在实验室机房主控室里，千兆带宽，50 人同时启动机器，则每个人只能分到 20 Mbps，也就是不到 2.5 MB/s 的下载速度，计算机启动会非常慢。如果采用了 P2P 技术而机房交换机的拓扑结构不够合理，也不容易得到明显的提升，不过假定 P2P 没有额外开销，而且能够合理控制 P2P 连接和回源连接的比例（这些连接是公平争抢链路带宽的），下载速度应该能到 10 MB/s 以上，也许可以接受。但对仍然在使用百兆网络的机房来说，什么优化估计都无济于事了。

这个同时启动同一个操作系统的问题，本质上是多个客户端想同时获取同一个文件的问题。这个问题产生于在线会议系统，最早解决的做法是 IP Multicast，也就是源端只往路由器发一份数据，但路由器把这份数据往局域网的多个端口发送。但这种多播的做法不适用于要求可靠的数据传输，因为要做到可靠就要有应答（ACK），这些 ACK 都回传到源端就会产生经典的 ACK implosion 问题。P2P 技术应运而生，只是多数 P2P 用户并不是同时需要同一份文件，于是大家淡忘了 P2P 起源于直播的历史。由于物理上接近的局域网里很可能没有想要的文件，很多 P2P 系统干脆不考虑网络拓扑结构，而是选取随机的节点。事实上在网络拓扑结构中最适合做 peer 的是路由器，但传统意义上的路由器是不能存储数据的，在教科书里这种端到端的设计原则被称为 “Internet 成功的原因”，潜台词是更优雅的设计由于成本原因被历史淘汰了。现在很多人在研究的 Content-Centric Network，就是让路由器存储转发 URL（可以理解成所有的路由器都是小区缓存），把可靠的数据传输引入 IP Multicast。扯远了，这些 YY 跟网络启动没有关系。

​对于百兆的实验室，这个时候瓶颈至少不在与PXE服务器了，而是端了。p2p其实就是把部分服务器​成本嫁接到端上。

路由器做peer，我提到的p2p+cdn混合方案的一种实现方式其实就是这个思想，取一些服务器作为特殊的peer，这些服务器可以部署在近端的位置（也就是路由器的位置），在p2p系统中，这些peer可以有特殊的属性，例如tracker以较高的权重返回这些peer，或者客户端将这些peer作为后备使用等。

假设一个实验室有100台机器，我相信不可能有某一个时间100台机器同时启动，或者100台机器正好都需要同一个文件，但可能会有10台机器要同一个文件，如果10台机器，不考虑交换机限速（假设交换机无限大），这10台机器同时去pxe服务器取数据，假设pxe服务器是1g的网卡，那么每台机器可以有10MB/s的速度。但是如果有p2p，这10台需要相同文件的机器，很可能可以在内网，或者在校园网内得到满足，那么pxe服务器的负载就很小了，而且大家可能会得到很高的下载速度（例如30MB/s）。

我觉得这里两个问题不能混到一起。PXE服务器的瓶颈，和实验室端的交换机瓶颈是两个问题。使用p2p可以解决PXE服务器这个瓶颈，但未必能解决终端交换机这个瓶颈，甚至会加重终端交换机的压力。不过我觉得实验室换个交换机应该是大家都喜闻乐见的事，学生有动力去push老师，每个老师出个几百上千的更新一下交换机也不是什么大成本。但是服务器数量多了，不仅购买的一次性成本高，还带来更多的维护成本。

再说基于网络拓扑进行p2p优化，在这种情形下也许不需要刻意的去做。因为使用相同系统的人，很可能物理位置都比较接近，例如都是同一个实验室的、同一个机房的等。

 

再讨论在树华或者寝室使用的情况。

这时就不像一个直播系统，而像 P2P 分享文件的系统了。不过一般的 P2P，用户在下载文件结束后一般会一直做种，而我们的网络操作系统用户一关机就不再做种了，也就是只能在同时开机的同一个网络操作系统用户之间做 P2P。这个效果能有多好我心里没底。

​大概给一些数据吧，在视频直播领域，p2p的效率可以达到95%以上（即95%以上的带宽是p2p的）。而且视频直播的p2p延迟（这个延迟跟请求文件的延迟还不是一回事，后面再说）要求是比较高的，一般在2分钟以内，如果缩短这个延迟，p2p会下降一些，但也不会下降太多。

在树华这种场景下，并不是直播系统，而是点播系统，因为大家在一个时刻要访问的东西并不一样。只有极端情况下，如每天早上刚开门时，一下涌入几十个人同时开机，会出现许多人同时需要相同的文件，但正常使用后，是不会有大量人同时访问相同文件的情况出现的。所以这是一个点播p2p系统，但是在延迟的要求上跟点播不太一样。

​说说延迟。刚才说的直播延迟，是指用户看到的视频跟直播源之间的时差。点播中一般似乎不需要考虑延迟的概念。直播和点播有一个共同点是，可以“预取”，系统本身知道接下来需要什么文件块，可以提前去取（对于直播，就是提前去尝试取，对于点播，就是提前去取并缓存）。而这里的p2p文件系统则不一样，系统无法提前知道要访问哪些文件块，因此没有办法做预取。这里讨论的延迟就是从系统发出一个块的请求到得到这个块的时间。这是一个很严格的要求，这会对p2p的效率造成质的影响。但是在比较理想的校园网里，我觉得问题不会太大。举例说，假设一个block有100个peer有，我（客户端）预先从tracker那里得到了这个信息，当我要取这个块时，我从100个peer中随机选一个去取，这个peer在当时正好下线的概率是非常小的，那么取这个文件的延迟，可以跟从PXE服务器通过NFS取文件进行比较，如果这个延迟不比后者高很多，那么我觉得就是可以接受的。如果可以通过某种技术，使得这种延迟更小，那么对使用体验就没有影响了。

​

 

* 可以在不同的地方使用相同的系统，上述场景是一个，这里再说一种场景。许多人并没有自己的电脑，而到公共场合（例如树华）则只能使用给定的系统，每次去都会被还原。但如果可以在任何一台电脑上启动一个相同的系统，并且启动后所有的配置都保留，甚至安装的软件也都保留，那么他就可以在任何能上网的地方使用“自己”的系统了。

这个是科大本科寝室没网，或者很多学校大一不允许带电脑导致的特殊需求吧……不过看起来确实挺诱人的。

​这样的场景其实还可以有许多。比如陈香兰老师，她实验室自己用的电脑是Linux的，她的课程也经常要用Linux演示，但是教室里没有Linux，只能自己带笔记本。

 

--

Cheng,

Best Regards

[Yifan Gao]

节点是1G网卡，交换机连接校园网是10G接口。

网络不会成为MapReduce的瓶颈，因为磁盘才是瓶颈(目前2.0的平均磁盘访问速度已经下降到5M/s)

-- 
Yifan Gao

开启 2014年5月27日 at 上午1:31:37, Bojie Li (boj...@gmail.com) 写:

[Zhang Cheng]

2014-05-27 1:35 GMT+08:00 Yifan Gao <ylgao...@gmail.com>:

64U 是什么 CPU 型号

抱歉，我简写了。 是指64颗CPU 我记得型号是Core2  T7700

几个 socket

指什么的socket？

​

就

​是有几片CPU，在有些地方叫 几路CPU。CPU主要有三个单元单位，socket、core、thread，socket指有几片物理CPU，core指有几核，thread指全开超线程后有几个超线程。

​你这里说的64颗CPU是在同一块主板上吗？感觉不太真实啊，64颗CPU平铺可能都要比主板大了。。。

--

Cheng,

Best Regards

[Yifan Gao]

我不是很清楚啊，科大云2.0的机器我只见过一次，参数不甚了解

-- 
Yifan Gao

开启 2014年5月27日 at 上午1:42:57, Zhang Cheng (steph...@gmail.com) 写:

socket

[Yifan Gao]

这个估计得拆开看看才知道，就外观而言，刀片20多厘米宽，1米多长，不知道能不能放下64U哈

-- 
Yifan Gao

开启 2014年5月27日 at 上午1:44:57, Yifan Gao (ylgao...@gmail.com) 写:

这里说的64颗CPU是在同一块主板上吗？感觉不太真实啊，64颗CPU平铺可能都要比主板大了。。。

 

[Zhang Cheng]

2014-05-27 1:47 GMT+08:00 Yifan Gao <ylgao...@gmail.com>:

这个估计得拆开看看才知道，就外观而言，刀片20多厘米宽，1米多长，不知道能不能放下64U哈

$ ​cat /proc/cpuinfo​

其中的physical id就是socket id，有多少个不同的physical id，就有多少片CPU。

core id是一个核在相应的片里面的编号，有多少个不同的core id，就是每片CPU有多少核。

会有两个或者多个processor的physical id和core id相同，这就是超线程。

--

Cheng,

Best Regards

[Bojie Li]

64 颗双核 CPU，也就是 128 个逻辑核了？

On May 27, 2014, at 1:35, Yifan Gao <ylgao...@gmail.com> wrote:

64U 是什么 CPU 型号

抱歉，我简写了。 是指64颗CPU 我记得型号是Core2  T7700

几个 socket

指什么的socket？

CPU 的物理插槽。

[Yifan Gao]

64核心，并不是128核心

-- 
Yifan Gao

开启 2014年5月27日 at 上午1:58:32, Bojie Li (boj...@gmail.com) 写:

[Bojie Li]

赶紧看看有没有在 KVM 里打开 VT-d 了，如果确实打开了，磁盘性能还是这么差，就用 iostat 看看磁盘请求的 iops，是不是小的随机读写占很大比例。

[Yifan Gao]

赶紧看看有没有在 KVM 里打开 VT-d 了，如果确实打开了，磁盘性能还是这么差，就用 iostat 看看磁盘请求的 iops，是不是小的随机读写占很大比例。

目前新版科大云已经放弃了kvm平台，2.0也不会再更新了。关于磁盘的问题，我会你转达给相关同学，让他们查一下。

-- 
Yifan Gao

开启 2014年5月27日 at 上午2:00:49, Bojie Li (boj...@gmail.com) 写:

[Yifan Gao]

学习了，不过我没有科大云2.0的管理账号，回头帮你问问

Zhang Cheng <steph...@gmail.com>于2014年5月27日星期二写道：

--

-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en

---
You received this message because you are subscribed to the Google Groups "USTC_LUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Yifan Gao(高一凡)

[Bojie Li]

2014-05-27 1:37 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

假设一个实验室有100台机器，我相信不可能有某一个时间100台机器同时启动，或者100台机器正好都需要同一个文件，但可能会有10台机器要同一个文件，如果10台机器，不考虑交换机限速（假设交换机无限大），这10台机器同时去pxe服务器取数据，假设pxe服务器是1g的网卡，那么每台机器可以有10MB/s的速度。但是如果有p2p，这10台需要相同文件的机器，很可能可以在内网，或者在校园网内得到满足，那么pxe服务器的负载就很小了，而且大家可能会得到很高的下载速度（例如30MB/s）。

我本来想的是开始上课的时候大家都去开机，因为少院机房还是百兆网络的时候，几台机器同时网络启动 XP，有的机器就会卡住，给我留下了心理阴影。假定大家来上实验课不是一拥而入，这个问题就没有了。不过老师指示大家打开同一种软件（比如 Matlab），这种同时载入文件的需求还是存在的吧，而且很难通过预取解决。

P2P 方案就算没有 CDN 的帮助，如果块的大小适当，peer 不会轻易下线，肯定比回源（从 PXE 服务器直接取）要快。我只是说采用了 P2P + CDN 优化之后机房同时网络启动的问题能否解决，如果不能解决则机房网络启动本身就是不可行的。我刚才大概算了算，千兆网络 50 台机器问题应该不大。在带宽不是瓶颈的情况下，如果 P2P 算法很理想，从网络启动比本地启动还要快，因为局域网延迟小于磁盘寻道延迟，而且 P2P 可以并行而磁盘只能串行。

在少院机房的网络启动部署中遇到一个问题：写入磁盘的差分内容是保存在本地内存还是网启服务器上（不能使用本地硬盘）。最早是保存在网启服务器上的，结果网启服务器的硬盘成了瓶颈。后来改成写入本地内存（类似 tmpfs），但用户会奇怪地发现下载大文件之后或者系统持续运行时间较长后系统会卡死（跟图书馆查询机问题类似）。这个问题不知道 @Zhang Cheng 考虑过没有。

​大概给一些数据吧，在视频直播领域，p2p的效率可以达到95%以上（即95%以上的带宽是p2p的）。而且视频直播的p2p延迟（这个延迟跟请求文件的延迟还不是一回事，后面再说）要求是比较高的，一般在2分钟以内，如果缩短这个延迟，p2p会下降一些，但也不会下降太多。

这正是我担心的问题。我猜测视频直播的 playback lag 高达几十秒，可能是因为客户端加入和退出频道非常频繁，以及每个客户端只缓存马上要播放的和刚播放过的若干秒内容，而不会把所有收到的内容一直缓存着，因此尝试连接一个 peer，它那里不一定有我想要的内容。我不知道我的猜测对不对。对 P2P 文件系统来说，加入退出（开机关机）倒是不频繁，不过机器的本地内存有限，意味着每个节点对所取内容的缓存（或称做种）是比较短暂的，有点像视频直播里播过一段时间的内容就不再缓存了。这会不会带来较高且不可预测的延迟？

找到一篇 2006 年基于 PPLive 的论文，不知道这些数字在 8 年后的今天是否适用。 A Measurement Study of a Large-Scale P2P IPTV System http://eeweb.poly.edu/faculty/yongliu/docs/streaming_measurement.pdf

Kosha: A Peer-to-Peer Enhancement for the Network File System 实现了 P2P 的 NFS（可惜没有找到代码），增加的延迟只是 4 个 RTT 左右，测试结果很漂亮。不过这是每个 peer 贡献出相对固定的一块磁盘空间，由 tracker 控制哪些数据放在哪个 peer，感觉跟我们准备搭建的内存 P2P 文件系统不同。

Paper: http://people.cs.vt.edu/butta/docs/sc04.pdf

Technical Report: http://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1152&context=ecetr&sei-redir=1

（BTW，这篇论文的 motivation 是每台桌面电脑贡献出自己的空闲磁盘空间，在整个学校的范围形成一个大的分布式文件系统，感觉是个不错的想法）

 

[Bojie Li]

2014-05-27 4:24 GMT+08:00 Bojie Li <boj...@gmail.com>:

我猜测视频直播的 playback lag 高达几十秒，可能是因为客户端加入和退出频道非常频繁，以及每个客户端只缓存马上要播放的和刚播放过的若干秒内容，而不会把所有收到的内容一直缓存着，因此尝试连接一个 peer，它那里不一定有我想要的内容。

刚才名词看错了，应该是 start-up delay = 用户打开频道到开始播放的时间，也是十几秒的量级吧。playback lag 应该是与视频源之间的时间差吧，这个是几十秒的量级，主要是因为在比较大的 P2P 网络里，视频从视频源分发到用户要经过好几跳，而且这个跳数不确定（因为 peer 是随机选择的）。在我们的 P2P NFS 里关心的应该是 start-up delay。

[Bojie Li]

@Yifan Gao 搞的科大云 3.0 似乎是基于 OpenStack 的。

一年半前我搞 freeshell 时也看过 OpenStack，不过当时它的计算部分（Nova）似乎没有 OpenVZ 的 API（现在 GitHub 上有开源项目了），而且我也看不懂那些虚拟网络是怎么回事（我那时候每次配 NAT 都得 Google 一下，策略路由、tunnel 什么的更是没听说过）。我觉得 freeshell 资源这么少，一定要用操作系统级虚拟化才能最大化物理资源的利用，于是就自己动手丰衣足食，三天时间写了个简单的 Web 界面就上线了。所以写代码快未必是好事，它会让人掉进重复造轮子的坑，但自己用几天时间搭建的原型一定比不上成熟的开源项目，以后维护的坑会越来越大。现在如果我启动一个新的 freeshell 项目，也会用 OpenStack。

开源社区确实发展很快啊，闭门造车的时代过去了。我们实验室年初做了一篇 paper，在虚拟网络里用虚拟机实现防火墙、IDS、tunnel 等网络功能，还以为挺新颖呢，结果投 SIGCOMM（网络顶级会议）只得了2分（满分5分）。今天一看 OpenStack 里已经有网络中间件的框架了，我们的idea 还怎么卖得出去，可惜我们实验室没人看 OpenStack。

[Yifan Gao]

我澄清一下，科大云3.0并不是我搞的

Bojie Li <boj...@gmail.com>于2014年5月27日星期二写道：

[Bojie Li]

一台科大云这样配置的物理机器大概要 20000 软妹币吧，搞两个机架的机器，应该不是说给就给，得申请项目吧，学校已经有一个云平台了，再搞一个的可行性你觉得大吗？

On May 26, 2014, at 18:27, Zhang Cheng <steph...@gmail.com> wrote:

我甚至觉得可以尝试要一批配置更好的机器。

2014-05-26 18:09 GMT+08:00 Yuanchong Zhu <redsk...@gmail.com>:

能协调好资源就行。直接去找jameszhang吧

在 2014年5月26日 下午5:52，Bojie Li <boj...@gmail.com>写道：

Freeshell 磁盘紧张，3 号节点的磁盘已经快满了。少院这 7 台机器作为全校范围的公共服务实在是捉襟见肘。

我听说科大云（cloud.ustc.edu.cn）有比较多的硬件资源，也有足够的公网 IPv4 地址池，但由于技术原因服务不太稳定。能不能通过 LUG 指导老师 jameszhang 牵线，我们为科大云提供技术支持，把科大云变得更稳定易用。北京分舵前些天聚会时，几位前辈提到 “取代 FTP 的云文件系统” 这个未竟的愿望，这也需要比较大的存储资源池。

功利地说有几个好处：

• 可以把虚拟机用到课堂上，每人一个克隆出来的虚拟机，省去配置开发环境的麻烦。
• 助力校内与互联网相关的创新创业项目。（现在申请机器是个麻烦事）
• 参与科大云平台开发的同学把它写进简历，一定是个加分项。
  
• 我们 LUG 再也不缺机器和存储空间了。现在我们的资源只够做 LUG 会员范围的服务，如果傍上科大云这个资源池，就能做全校范围的服务了。

接下来的一年我多数时间在学校，可以跟小伙伴们一起把学校的云平台真正搞起来。大家觉得这个想法怎么样？

--
-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en

---
You received this message because you are subscribed to the Google Groups "USTC_LUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
灿烂星空，你就是我的英雄！

--
-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en

---
You received this message because you are subscribed to the Google Groups "USTC_LUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Cheng,

Best Regards

[张伟]

科大云2.0kvm平台的本地存储是基于逻辑卷的？

[hui zhang]

赞

那 搞出来 到底是 freeshell  还是 云平台呢

对我的区别是 独立ip  么？

端口 是否自由开放？

个人感觉 freeshell最大的问题在于 端口 不自由

在 2014年5月26日星期一UTC+8下午5时52分48秒，Bojie Li写道：

[Zhang Cheng]

2014-05-27 2:00 GMT+08:00 Bojie Li <boj...@gmail.com>:

赶紧看看有没有在 KVM 里打开 VT-d 了，如果确实打开了，磁盘性能还是这么差，就用 iostat 看看磁盘请求的 iops，是不是小的随机读写占很大比例。

​vt-d只是改变了虚拟机访问io设别的方式吧（例如可以直接DMA、直接接受硬件中断等），但不会对访问磁盘的性能有太大的提升吧？一个主机上多个虚拟机，大家一起使用硬盘时，硬盘的瓶颈还是在随机访问上。而且我感觉，硬盘这种东西，如果通过操作系统来管理分享（例如用lvm分卷给不同的虚拟机用），操作系统还可以做合并、缓存等优化，但所有虚拟机都直接访问硬盘时，大家并不知道其他人在用，反而不利于优化吧？

--

Cheng,

Best Regards

[Zhang Cheng]

2014-05-27 4:24 GMT+08:00 Bojie Li <boj...@gmail.com>:

我本来想的是开始上课的时候大家都去开机，因为少院机房还是百兆网络的时候，几台机器同时网络启动 XP，有的机器就会卡住，给我留下了心理阴影。假定大家来上实验课不是一拥而入，这个问题就没有了。不过老师指示大家打开同一种软件（比如 Matlab），这种同时载入文件的需求还是存在的吧，而且很难通过预取解决。

P2P 方案就算没有 CDN 的帮助，如果块的大小适当，peer 不会轻易下线，肯定比回源（从 PXE 服务器直接取）要快。我只是说采用了 P2P + CDN 优化之后机房同时网络启动的问题能否解决，如果不能解决则机房网络启动本身就是不可行的。我刚才大概算了算，千兆网络 50 台机器问题应该不大。在带宽不是瓶颈的情况下，如果 P2P 算法很理想，从网络启动比本地启动还要快，因为局域网延迟小于磁盘寻道延迟，而且 P2P 可以并行而磁盘只能串行。

在少院机房的网络启动部署中遇到一个问题：写入磁盘的差分内容是保存在本地内存还是网启服务器上（不能使用本地硬盘）。最早是保存在网启服务器上的，结果网启服务器的硬盘成了瓶颈。后来改成写入本地内存（类似 tmpfs），但用户会奇怪地发现下载大文件之后或者系统持续运行时间较长后系统会卡死（跟图书馆查询机问题类似）。这个问题不知道 @Zhang Cheng 考虑过没有。

​

我

​相信并发并不会对p2p产生什么坏影响。即使老师让大家同时打开matlab，大家也不可能完全同时，总有几个人先，几个人后，先打开的人（哪怕只早几秒）都可以为后打开的人提供p2p服务。

​差分硬盘的事，这确实是大问题，而且没有很好的解决方法，这跟p2p没有关系。p2p尝试解决的是带宽的问题（当然也缓解可能潜在的服务器硬盘读压力）。而硬盘的问题，本来N多设备都有自己的硬盘，现在如果用网络系统时完全不用本地硬盘，那就相当于要将本地硬盘的需求转嫁给其他设备，例如内存、网络硬盘等。我觉得对于机房这个问题还是比较好解决的，可以约定本地硬盘里里提供一块特殊的分区给网络系统做差分存储（甚至p2p的缓存）使用，不过这里的差分内容不提供持久化存储，系统重启即失效。个人电脑就无法做这样的要求了（也可以考虑检测硬盘上是否有swap分区，如果有也可以利用）。

​但我觉得从大规模服务的角度看，硬盘的问题应该提供一个单独的解决方案，例如提供一个极高吞吐率的存储集群，至于这个东西怎么做，就是另外一个话题了。

 

​大概给一些数据吧，在视频直播领域，p2p的效率可以达到95%以上（即95%以上的带宽是p2p的）。而且视频直播的p2p延迟（这个延迟跟请求文件的延迟还不是一回事，后面再说）要求是比较高的，一般在2分钟以内，如果缩短这个延迟，p2p会下降一些，但也不会下降太多。

这正是我担心的问题。我猜测视频直播的 playback lag 高达几十秒，可能是因为客户端加入和退出频道非常频繁，以及每个客户端只缓存马上要播放的和刚播放过的若干秒内容，而不会把所有收到的内容一直缓存着，因此尝试连接一个 peer，它那里不一定有我想要的内容。我不知道我的猜测对不对。对 P2P 文件系统来说，加入退出（开机关机）倒是不频繁，不过机器的本地内存有限，意味着每个节点对所取内容的缓存（或称做种）是比较短暂的，有点像视频直播里播过一段时间的内容就不再缓存了。这会不会带来较高且不可预测的延迟？

​p2p可以做成 不是去找一个peer问他是否有我要的东西，而是问tracker哪些peer有我要的东西，我去问那些peer要。​在一个大环境里，通常一个人要的东西总是有peer有的，无论每个peer的缓存多小（我想每个peer至少有100M以上的缓存吧，一个系统使用时常用的文件大小估计也就这个量级）。

 

找到一篇 2006 年基于 PPLive 的论文，不知道这些数字在 8 年后的今天是否适用。 A Measurement Study of a Large-Scale P2P IPTV System http://eeweb.poly.edu/faculty/yongliu/docs/streaming_measurement.pdf

Kosha: A Peer-to-Peer Enhancement for the Network File System 实现了 P2P 的 NFS（可惜没有找到代码），增加的延迟只是 4 个 RTT 左右，测试结果很漂亮。不过这是每个 peer 贡献出相对固定的一块磁盘空间，由 tracker 控制哪些数据放在哪个 peer，感觉跟我们准备搭建的内存 P2P 文件系统不同。

Paper: http://people.cs.vt.edu/butta/docs/sc04.pdf

Technical Report: http://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1152&context=ecetr&sei-redir=1

（BTW，这篇论文的 motivation 是每台桌面电脑贡献出自己的空闲磁盘空间，在整个学校的范围形成一个大的分布式文件系统，感觉是个不错的想法）

​不明觉历，我确实没找过文章看过。。。所以我不是个搞科研的料。。。

--

Cheng,

Best Regards

[Zhang Cheng]

2014-05-27 4:35 GMT+08:00 Bojie Li <boj...@gmail.com>:

刚才名词看错了，应该是 start-up delay = 用户打开频道到开始播放的时间，也是十几秒的量级吧。playback lag 应该是与视频源之间的时间差吧，这个是几十秒的量级，主要是因为在比较大的 P2P 网络里，视频从视频源分发到用户要经过好几跳，而且这个跳数不确定（因为 peer 是随机选择的）。在我们的 P2P NFS 里关心的应该是 start-up delay。

​​如果是纯p2p系统，start-up delay会有多长我不清楚，不过如果是p2p+cdn，start-up delay做到1s以内是没有问题的（风云直播早期没有那么多插件时，start-up delay基本在1s以内）。p2p启动比较慢，而且公网的p2p受限很多，有些peer连不上，大多数peer的上传带宽很小。其实前面说的p2p可以占95%以上的带宽，前提是视频码率低于平均上传带宽，否则的话p2p就立刻下降了，因为大家的上传能力不能自给。而且p2p系统无法知道每个peer的上传能力（例如有些peer有上百m的上传带宽，但仍然只把他推荐给了很少的几个peer）。

​p2p nfs这里关注的是每一次请求的delay。类比成硬盘，将文件分块后，就是每一次随机的对齐访问的响应延迟。​

​一个简单的实现思路：这个p2p系统将一个squashfs文件映射成一个块设备/dev/p2pblock，这个块设别可以mount -t squashfs /dev/p2pblock /。p2p系统定期（如每5s）向track请求一次这个文件的所有块都有哪些peer有，也就是说，任何时候，操作系统发出请求第i块的数据，p2p系统都能直接从内存中找到哪些peer有这个块，然后随机选择一个去请求，并设置一个超时阈值，如果在阈值时间内没有收到响应，或者没有收全数据，就直接向服务器索要。

​这种实现方案本身很简单，本身仅关注下载文件的逻辑，仅需向操作系统提供块设备的read操作。操作系统会处理好缓存和预取的逻辑。

​

--

Cheng,

Best Regards

[Zhang Cheng]

2014-05-27 6:00 GMT+08:00 Bojie Li <boj...@gmail.com>:

在虚拟网络里用虚拟机实现防火墙、IDS、tunnel 等网络功能，还以为挺新颖呢

​这个在业内算是很成熟的东西了吧，而且我看有一些云主机平台已经提供很方便的操作接口了。比如青云，​可以很方便的创建虚拟私有网络（L2 switch），创建虚拟路由器（提供DHCP、端口转发、隧道、VPN等服务），负载均衡器、防火墙等。

--

Cheng,

Best Regards

[Zhang Cheng]

2014-05-27 6:40 GMT+08:00 Bojie Li <boj...@gmail.com>:

一台科大云这样配置的物理机器大概要 20000 软妹币吧，搞两个机架的机器，应该不是说给就给，得申请项目吧，学校已经有一个云平台了，再搞一个的可行性你觉得大吗？

​我在科大这几年的体会是，网络中心很有钱，他们也很愿意给学生钱（当然不是给现金），他们有许多钱很难花出去。但是不能学生要就给，这并不能督促钱被很好的花出去。同时，网络中心花钱也需要对上头有交代。对于网络中心来说，其实他们要的很少，给他们提供论文就好了。网络中心在国内会跟其他学校的网络部门竞争（我不知道为什么一个后勤保障部门会有科研、工程项目的竞争），主要方式就是看大家做了什么东西出来。

​这个事我觉得可以找james谈一谈，看看科大对于云这一块是什么想法，也可以跟他比较一下科大云和LUG freeshell有什么区别，freeshell有哪些方面的优势？

​我觉得科大的freeshell可以换一种定位。例如科大云为大家提供极稳定的计算服务，而freeshell则更侧重于云主机本身的实验。例如可以做一套像青云那样的系统（我没有关注过openstack，不清楚现在openstack究竟做到什么程度了），可以创建二层交换机、虚拟路由器等，这样的东西做好了，其实可以应用到课堂教学中去。

--

Cheng,

Best Regards

[张伟]

我觉得他想说的应该是virtio吧

--

[Bojie Li]

新版科大云所用的 OpenStack 在虚拟网络方面的功能就比较强大，不过不建虚拟网络就不能建虚拟机，对新手不人性化。

我觉得我们可以在 OpenStack 基础上做一些增量式的改进，比如自动建立默认虚拟网络免除新手痛苦，像 bitnami 一样的用户间共享镜像（这对助教发布课程所用镜像是很必要的），虚拟机镜像允许在云之外远程挂载，甚至与 PXE 系统整合直接从虚拟机镜像启动（都是 x86，还真没什么本质困难）。

--

[Bojie Li]

极高吞吐率的存储集群，先不说怎么实现，问题是访问这个集群需要网络带宽，之前说的 P2P + CDN 就是为了节约带宽，把增量存储放在中心位置，带宽又上去了。

我听说 Azure 虚拟机的数据分区都是远程挂载（类似 EBS），虚拟机镜像的存储用的是分布式块设备（erasure coding，好像还发过 paper）。所以全校范围的 PXE 这事如果中间加个虚拟化层（如果做 Windows PXE 还真得要这么一层，因为微软的网启服务器我们没有授权，也无法修改）就相当于全校范围的云服务，只是此时计算节点变成了用户的个人电脑。

云存储应该算是 P2P 文件系统的升级版，后者的主要问题是找到内容所在的节点，前者还要考虑读写一致性问题。但我们也有新的挑战，就是（1）每台机器的内存有限（节点存储内容变化频繁），而且机器上下线频繁（相对云存储），tracker 的通信开销和对 tracker 的压力都比较大。（2）校园网络基本是树形结构，bisection bandwidth 不足，如果 P2P 没有网络拓扑上的局部性，会把校园骨干网堵死。

On May 27, 2014, at 11:57, Zhang Cheng <steph...@gmail.com> wrote:

2014-05-27 4:24 GMT+08:00 Bojie Li <boj...@gmail.com>:

我本来想的是开始上课的时候大家都去开机，因为少院机房还是百兆网络的时候，几台机器同时网络启动 XP，有的机器就会卡住，给我留下了心理阴影。假定大家来上实验课不是一拥而入，这个问题就没有了。不过老师指示大家打开同一种软件（比如 Matlab），这种同时载入文件的需求还是存在的吧，而且很难通过预取解决。

P2P 方案就算没有 CDN 的帮助，如果块的大小适当，peer 不会轻易下线，肯定比回源（从 PXE 服务器直接取）要快。我只是说采用了 P2P + CDN 优化之后机房同时网络启动的问题能否解决，如果不能解决则机房网络启动本身就是不可行的。我刚才大概算了算，千兆网络 50 台机器问题应该不大。在带宽不是瓶颈的情况下，如果 P2P 算法很理想，从网络启动比本地启动还要快，因为局域网延迟小于磁盘寻道延迟，而且 P2P 可以并行而磁盘只能串行。

在少院机房的网络启动部署中遇到一个问题：写入磁盘的差分内容是保存在本地内存还是网启服务器上（不能使用本地硬盘）。最早是保存在网启服务器上的，结果网启服务器的硬盘成了瓶颈。后来改成写入本地内存（类似 tmpfs），但用户会奇怪地发现下载大文件之后或者系统持续运行时间较长后系统会卡死（跟图书馆查询机问题类似）。这个问题不知道 @Zhang Cheng 考虑过没有。

​

我

​相信并发并不会对p2p产生什么坏影响。即使老师让大家同时打开matlab，大家也不可能完全同时，总有几个人先，几个人后，先打开的人（哪怕只早几秒）都可以为后打开的人提供p2p服务。

​差分硬盘的事，这确实是大问题，而且没有很好的解决方法，这跟p2p没有关系。p2p尝试解决的是带宽的问题（当然也缓解可能潜在的服务器硬盘读压力）。而硬盘的问题，本来N多设备都有自己的硬盘，现在如果用网络系统时完全不用本地硬盘，那就相当于要将本地硬盘的需求转嫁给其他设备，例如内存、网络硬盘等。我觉得对于机房这个问题还是比较好解决的，可以约定本地硬盘里里提供一块特殊的分区给网络系统做差分存储（甚至p2p的缓存）使用，不过这里的差分内容不提供持久化存储，系统重启即失效。个人电脑就无法做这样的要求了（也可以考虑检测硬盘上是否有swap分区，如果有也可以利用）。

​但我觉得从大规模服务的角度看，硬盘的问题应该提供一个单独的解决方案，例如提供一个极高吞吐率的存储集群，至于这个东西怎么做，就是另外一个话题了。

 

​大概给一些数据吧，在视频直播领域，p2p的效率可以达到95%以上（即95%以上的带宽是p2p的）。而且视频直播的p2p延迟（这个延迟跟请求文件的延迟还不是一回事，后面再说）要求是比较高的，一般在2分钟以内，如果缩短这个延迟，p2p会下降一些，但也不会下降太多。

这正是我担心的问题。我猜测视频直播的 playback lag 高达几十秒，可能是因为客户端加入和退出频道非常频繁，以及每个客户端只缓存马上要播放的和刚播放过的若干秒内容，而不会把所有收到的内容一直缓存着，因此尝试连接一个 peer，它那里不一定有我想要的内容。我不知道我的猜测对不对。对 P2P 文件系统来说，加入退出（开机关机）倒是不频繁，不过机器的本地内存有限，意味着每个节点对所取内容的缓存（或称做种）是比较短暂的，有点像视频直播里播过一段时间的内容就不再缓存了。这会不会带来较高且不可预测的延迟？

​p2p可以做成 不是去找一个peer问他是否有我要的东西，而是问tracker哪些peer有我要的东西，我去问那些peer要。​在一个大环境里，通常一个人要的东西总是有peer有的，无论每个peer的缓存多小（我想每个peer至少有100M以上的缓存吧，一个系统使用时常用的文件大小估计也就这个量级）。

我没做过 P2P，实际中 tracker 会实时知道每个 peer 有哪些内容吗？也就是一个缓存的内容被丢弃了，会通知 tracker 吗？

系统常用的文件只有 100M 的量级？打开一个稍微大些的软件都不止 100M 吧。

对于差分内容存储，我觉得不能随便利用 swap 分区，因为用户的本地操作系统休眠也会存到这个分区。现在大多数机器的分区已经不留缝隙了，让大多数机器重新划分分区是不现实的，因此我觉得可以模仿 wubi 的做法，用户装上一个客户端即可在本地磁盘建立一个大文件，PXE 系统会挂载所有分区尝试寻找这个大文件作为写缓冲和读缓存。问题是很多笔记本 Windows 用户习惯于休眠而不是关机，这样 NTFS 分区在 PXE 启动时就处于不一致的状态，ntfs-3g 似乎会拒绝挂载（如果强行挂载估计问题更大）。

 

找到一篇 2006 年基于 PPLive 的论文，不知道这些数字在 8 年后的今天是否适用。 A Measurement Study of a Large-Scale P2P IPTV System http://eeweb.poly.edu/faculty/yongliu/docs/streaming_measurement.pdf

Kosha: A Peer-to-Peer Enhancement for the Network File System 实现了 P2P 的 NFS（可惜没有找到代码），增加的延迟只是 4 个 RTT 左右，测试结果很漂亮。不过这是每个 peer 贡献出相对固定的一块磁盘空间，由 tracker 控制哪些数据放在哪个 peer，感觉跟我们准备搭建的内存 P2P 文件系统不同。

Paper: http://people.cs.vt.edu/butta/docs/sc04.pdf

Technical Report: http://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1152&context=ecetr&sei-redir=1

（BTW，这篇论文的 motivation 是每台桌面电脑贡献出自己的空闲磁盘空间，在整个学校的范围形成一个大的分布式文件系统，感觉是个不错的想法）

​不明觉历，我确实没找过文章看过。。。所以我不是个搞科研的料。。。

我没有实战经验才要找文章看啊，这种运营数据还是你说的更靠谱。

我觉得你提的这个 P2P PXE 完全是个研究问题啊，如果能做到与本地磁盘相差不多的用户体验，并在校园大规模部署，都可以投国际会议了。我不是搞分布式系统的，如果谁发现了相关的开源项目或 paper 请告诉我。

[Yuanchong Zhu]

> 我没做过 P2P，实际中 tracker 会实时知道每个 peer 有哪些内容吗？也就是一个缓存的内容被丢弃了，会通知 tracker 吗？

这一点我也很好奇。看BT软件似乎是自己通过tracker向每个peer发出请求然后自行判断的。

--
灿烂星空，你就是我的英雄！

[Zhang Cheng]

2014-05-27 17:16 GMT+08:00 Yuanchong Zhu <redsk...@gmail.com>:

> 我没做过 P2P，实际中 tracker 会实时知道每个 peer 有哪些内容吗？也就是一个缓存的内容被丢弃了，会通知 tracker 吗？

这一点我也很好奇。看BT软件似乎是自己通过tracker向每个peer发出请求然后自行判断的。

​这个就看协议如何实现了。普通的bt协议中不会由tracker记录每个peer含有的内容，因为这会消耗大量的tracker内存。但是自己实现的话，peer可以在每次与tracker heartbeat时报告自己拥有的片。​

--

Cheng,

Best Regards

[Yifan Gao]

科大云的师兄是想把系统级虚拟化也加入openstack中，并入科大云3.0

然后，清空现有的科大云2.0，用原来的机器运行3.0

-- 
Yifan Gao

开启 2014年5月27日 at 上午6:40:37, Bojie Li (boj...@gmail.com) 写:

[Bojie Li]

为什么不能做迁移（把 2.0 的镜像迁移到 3.0），而要把原来的虚拟机清空？这样会大伤元气啊。

[XuHao]

似乎是因为迁移难度不小

Hao Xu

University of Science and Technology of China

You received this message because you are subscribed to a topic in the Google Groups "USTC_LUG" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ustc_lug/dHNV1B_FqFM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ustc_lug+u...@googlegroups.com.

[Yifan Gao]

主要是原先2.0时代有很多遗留问题没有解决

1.虚拟机和数据库不同步

2.有许多无人使用但仍在运行的僵尸机器

3.实名制考虑

4.瀚海星云2.0 和 3.0 虚拟架构调整，如果要解决兼容性问题，需要修改3.0现有的架构

-- 
Yifan Gao

开启 2014年5月29日 at 上午6:15:01, Bojie Li (boj...@gmail.com) 写:

[Bojie Li]

On May 30, 2014, at 0:49, Yifan Gao <ylgao...@gmail.com> wrote:

主要是原先2.0时代有很多遗留问题没有解决

1.虚拟机和数据库不同步

以数据库为准，只迁移数据库里存在的虚拟机。

虚拟机和数据库不同步的问题是一个很挠头的问题，freeshell 就有很多这类问题并未解决。

在虚拟化平台里总有一些操作会失败，我们把这些操作分成两类，第一类操作是一个事务，要么都完成要么回滚，比如创建虚拟机，需要创建存储，分配计算节点，配置虚拟网络，最后虚拟机开机，其中有任何一步失败都会通过 Web 界面或 API 返回值告诉用户创建失败，数据库的更新就会被回滚。第二类操作是早晚都要完成的任务，例如第一类操作的事务失败需要回滚，需要删除已经分配的存储资源，但这时那台存储机器刚好宕机了，就要挂一个 pending operation，这台机器一恢复，就执行积累的 pending operation。另一个第二类操作的例子是用户的配额用完需要停止服务，这个 event 只会 trigger 一次，但如果相关操作执行失败，不能就这么让他免费用着，而要把操作挂在那里，一有机会就执行。

2.有许多无人使用但仍在运行的僵尸机器

由于科大云无需付费，可以设置三个月内没有 SSH 登录的，自动销毁虚拟机，收回资源。当然需要在收回之前邮件通知几次。如果存储资源充裕，收回的动作也可以只是关机，这样用户不会丢失数据。

系统通知邮件的 email 要让 jameszhang 加入白名单，这样不会被学校邮箱误判为垃圾。

3.实名制考虑

在现有的非实名制系统里实现实名制很简单，给所有用户群发邮件，限期完成校内邮箱认证，限期内不完成认证的删除账号。

4.瀚海星云2.0 和 3.0 虚拟架构调整，如果要解决兼容性问题，需要修改3.0现有的架构

2.0 和 3.0 的虚拟化技术有什么不同？我们就不考虑热迁移了，只要用户不丢数据就能接受。虚拟机全部关机，把磁盘镜像 copy 到 3.0 的架构里，都弄好之后虚拟机开机。也就是只要迁移虚拟机的磁盘镜像（比如 LVM 卷）就行了。

[Yifan Gao]

由于科大云无需付费，可以设置三个月内没有 SSH 登录的，自动销毁虚拟机，收回资源。

对于全虚拟化技术，我们无法监控用户运行了哪些进程、是否运行了SSH、是否登陆了SSH、甚至不知道用户是否更换了系统。如果要监控SSH登陆，只能从流量入手，不过解析数据包一方面要考虑CPU能否扛得住、另一方面会引起一些不必要的隐私问题，所以目前3.0的设计是：只在虚拟交换机上监控端口流量大小，但不识别具体内容(虽然技术上可以)。ps：2.0完全不做虚拟机流量监控

我们就不考虑热迁移了，只要用户不丢数据就能接受。虚拟机全部关机，把磁盘镜像 copy 到 3.0 的架构里，都弄好之后虚拟机开机。也就是只要迁移虚拟机的磁盘镜像（比如 LVM 卷）就行了。

这种迁移方案是非常好的，但貌似没有那么多设备可以同时容纳2000个虚拟机数据的备份。另外，节点做原地升级，比较困难

里面还涉及到一些kvm上的问题，这方面我不太清楚

-- 
Yifan Gao

开启 2014年5月30日 at 上午1:55:39, Bojie Li (boj...@gmail.com) 写:

[Bojie Li]

On May 30, 2014, at 2:28, Yifan Gao <ylgao...@gmail.com> wrote:

由于科大云无需付费，可以设置三个月内没有 SSH 登录的，自动销毁虚拟机，收回资源。

对于全虚拟化技术，我们无法监控用户运行了哪些进程、是否运行了SSH、是否登陆了SSH、甚至不知道用户是否更换了系统。如果要监控SSH登陆，只能从流量入手，不过解析数据包一方面要考虑CPU能否扛得住、另一方面会引起一些不必要的隐私问题，所以目前3.0的设计是：只在虚拟交换机上监控端口流量大小，但不识别具体内容(虽然技术上可以)。ps：2.0完全不做虚拟机流量监控

关于 SSH 协议有一个很好的教程 http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_12-4/124_ssh.html

只要数 22 端口的 TCP 连接所发包的个数，并统计开始若干个包的大小就行了。首先设置一个阈值（比如50个包），如果连接发送了这么多包，就认为 SSH 登录成功了，因为 SSH key 加密码一般最多试四次。如果连接从开始到终止发包的个数小于阈值，就根据每个包的大小判断是否登录成功，因为 SSH 握手和登录阶段每个包的大小基本是固定的，讲起来很麻烦，用 tcpdump 抓抓看就清楚了，注意考虑 ssh 终端、scp、ssh -D 端口转发等情况。

顺便说一句，总有人用 freeshell 和 ssh -D 搭建代理服务器，这是不允许的，但我一直都懒得管。ssh 终端和端口转发做代理的流量特征是非常不一样的，看用户发往 freeshell 的数据包，如果是终端，用户每敲一个键就是一个包，都是相对固定大小的小包；要是端口转发做代理，比如用来访问网页，一个 HTTP 请求被封在一个 SSH 包里，HTTP 请求肯定不止一个字节吧，数据包比终端的大多了。千万别以为加了密别人就不知道你干坏事了。

至于抓包 CPU 能否扛得住，1Gbps 的网卡 libpcap 应该问题不大，建议用 C 语言写统计连接和包大小的程序。如果嫌性能不够或者想一个 CPU 管 10Gbps，可以看看 netmap（已经是 FreeBSD 的标配，也有 Linux port）：

http://info.iet.unipi.it/~luigi/netmap/

我们就不考虑热迁移了，只要用户不丢数据就能接受。虚拟机全部关机，把磁盘镜像 copy 到 3.0 的架构里，都弄好之后虚拟机开机。也就是只要迁移虚拟机的磁盘镜像（比如 LVM 卷）就行了。

这种迁移方案是非常好的，但貌似没有那么多设备可以同时容纳2000个虚拟机数据的备份。另外，节点做原地升级，比较困难

什么叫“原地升级”？

[Yifan Gao]

只要数 22 端口的 TCP 连接所发包的个数，并统计开始若干个包的大小就行了。首先设置一个阈值（比如50个包），如果连接发送了这么多包，就认为 SSH 登录成功了，因为 SSH key 加密码一般最多试四次。如果连接从开始到终止发包的个数小于阈值，就根据每个包的大小判断是否登录成功，因为 SSH 握手和登录阶段每个包的大小基本是固定的，讲起来很麻烦，用 tcpdump 抓抓看就清楚了，注意考虑 ssh 终端、scp、ssh -D 端口转发等情况。

用户使用VNC、Windows OS、修改端口 都会导致这类办法失效。如果要通用，比较理想的还是记录前端控制台网站的last login time，每天固定时间检查并清理。

顺便说一句，总有人用 freeshell 和 ssh -D 搭建代理服务器，这是不允许的，但我一直都懒得管。ssh 终端和端口转发做代理的流量特征是非常不一样的，看用户发往 freeshell 的数据包，如果是终端，用户每敲一个键就是一个包，都是相对固定大小的小包；要是端口转发做代理，比如用来访问网页，一个 HTTP 请求被封在一个 SSH 包里，HTTP 请求肯定不止一个字节吧，数据包比终端的大多了。千万别以为加了密别人就不知道你干坏事了。

SSH能够承载的业务有很多，不知只靠包大小统计能否区分。比如：sftp、X-Window-f 、port forwarding、local port forwarding 等。假设freeshell部署了这类port forwarding 监控，会不会把正常数据也给误杀了？或者杀不干净？

比如：我的freeshell上部署了一个local port forwarding -L，用于从远程服务器接收中转过来的git(ssh协议)数据（这个应该也算广义的proxy -_-//），但这类流量与git本身的流量特征非常相似，很难区分。

端口转发的可以是任何类型的流量，所以很难说“某类”特征的数据包就是代理（如果只考虑一般情况下的http数据比较好搞）。

至于抓包 CPU 能否扛得住，1Gbps 的网卡 libpcap 应该问题不大，建议用 C 语言写统计连接和包大小的程序。如果嫌性能不够或者想一个 CPU 管 10Gbps，可以看看 netmap（已经是 FreeBSD 的标配，也有 Linux port）：

http://info.iet.unipi.it/~luigi/netmap/

学习了O(∩_∩)O

什么叫“原地升级”？

是我没说清楚。即：在原服务器上升级架构、升级用户配置及目录结构，使之能够运行在新的架构中。这区别于boj所讲的：“磁盘镜像 copy 到 3.0 的架构里”。

-- 
Yifan Gao

开启 2014年5月30日 at 上午5:05:47, Bojie Li (boj...@gmail.com) 写:

[Bojie Li]

2014-05-30 12:45 GMT+08:00 Yifan Gao <ylgao...@gmail.com>:

只要数 22 端口的 TCP 连接所发包的个数，并统计开始若干个包的大小就行了。首先设置一个阈值（比如50个包），如果连接发送了这么多包，就认为 SSH 登录成功了，因为 SSH key 加密码一般最多试四次。如果连接从开始到终止发包的个数小于阈值，就根据每个包的大小判断是否登录成功，因为 SSH 握手和登录阶段每个包的大小基本是固定的，讲起来很麻烦，用 tcpdump 抓抓看就清楚了，注意考虑 ssh 终端、scp、ssh -D 端口转发等情况。

用户使用VNC、Windows OS、修改端口 都会导致这类办法失效。如果要通用，比较理想的还是记录前端控制台网站的last login time，每天固定时间检查并清理。

到用户的虚拟机镜像里查登录记录，一方面是有隐私问题，另一方面对 Windows 来说绕开操作系统读取登录记录还是有点麻烦的。

我没有看过 VNC 协议，不过用户使用 VNC 的话，用户一旦成功登录，图形界面操作和屏幕内容的流量应该是比较大的，而且鼠标键盘事件的消息大小应该也是相对固定的。

如果考虑到修改端口，可以根据 SSH 和 VNC 协议本身的特征来区分，比如包头的 magic string，一个连接只要开始的几个包匹配上某个协议的模式，这个连接就被记下来了，后续的包也会被分类到这个协议。这种基于正则表达式的匹配，Snort（http://www.snort.org/）就可以做，在官方的入侵检测规则集上，每个 CPU 核每秒能处理 1Gbps。

SSH能够承载的业务有很多，不知只靠包大小统计能否区分。比如：sftp、X-Window-f 、port forwarding、local port forwarding 等。假设freeshell部署了这类port forwarding 监控，会不会把正常数据也给误杀了？或者杀不干净？

比如：我的freeshell上部署了一个local port forwarding -L，用于从远程服务器接收中转过来的git(ssh协议)数据（这个应该也算广义的proxy -_-//），但这类流量与git本身的流量特征非常相似，很难区分。

端口转发的可以是任何类型的流量，所以很难说“某类”特征的数据包就是代理（如果只考虑一般情况下的http数据比较好搞）。

确实会有误杀和漏报，所以我不会限制没事采取技术手段。而且学校的同学想用 freeshell 加速上网也不是什么坏事。

 

深度包检测（DPI）很强大的，下面这张列表是 Cisco 路由器能够区分的协议，可以当协议大全看了。

http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/90364_product_bulletin_c25_627831.pdf

[Bojie Li]

今天做了一个很粗糙的仿真，感觉这个 P2P 文件系统可以做。

机房 100 台机器的情况下，假定网络延迟 1ms，机房所有机器千兆网络全线速交换，机房到中心服务器是千兆，块大小 4 MB，每台机器（peer）获取到一块之后就永久做种，中心服务器知道每个 peer 所拥有的块列表，每个 peer 要下载一块前就问中心服务器从哪个 peer 下载，中心服务器会立即返回目前任务最少的一个 peer。现在让这 100 台机器以 1 秒的间隔相继启动，启动过程理想化为顺序下载相同的 1 GB 内容，下载完就认为启动完，结果是平均下载完成（启动完成）时间从全部从中心服务器取数据约 800 秒缩短到 P2P 的约 20 秒。当然这个数字非常理想化，因为考虑到机房的拓扑结构，所有机器全线速交换很可能不成立，这样平均启动时间应该仍然是分钟级别的。

这个仿真说明在低网络延迟的情况下，局域网内的 P2P 系统效率是很高的，值得去做。刚才我翻了翻 FUSE 的文档，在 FUSE 里做网络操作应该没有什么问题（因为我对内核不熟悉，跨自系统调用总怕出问题，用户态的就好办多了），如果 PXE 的新架构搭起来，P2P 文件系统的编码一个人月就差不多了，当然后面的测试和优化就是无止境的了。

On Monday, May 26, 2014, Zhang Cheng <steph...@gmail.com> wrote:

2014-05-26 18:29 GMT+08:00 Bojie Li <boj...@gmail.com>:

@stephen @snullp 能不能说说你们的 “云文件系统” 设想，我记得有个 PDF 的，不过找不到了。另外几年过去了，你们增加了很多经验，之前的想法是否有变化，也说说吧。

​当时的想法比较简单幼稚，只对期望的效果有想法，但对具体的实现、可行性都没有做过调研。现在snullp对这方面比较有经验，我再说一下我当初的想法吧，大家可以探讨一下可行性。

​我当时的想法大致是这样的：

​* 存储分为两类，用户数据和系统数据。

* 用户数据大家的都是不一样的，可以考虑使用比较成熟的分布式文件系统，例如AFS之类的。

  - 用户免不了会传一些共同的数据，比如相同的电影，可以​考虑文件系统层面支持去重的能力，例如文件系统按hash进行存储，相同的文件只存一份。

​* 系统数据主要是只读（或者说在客户端永远只读），服务器成了瓶颈，例如在LUP上大家一起玩PXE的话，PXE的带宽就成了瓶颈，大家的体验全都会变差。对此我想有两种方案可行：

  - 部署多个服务器，并且在NFS的基础上，能够加上一个load tracker，每个客户端自动选择比较优秀的节点。这样的做法，可扩展性比较差，比如我期望的效果可能是几千人同时在线（整个本科生宿舍都在用），当客户端增加，服务器数量也需要成比例增加。

  - ​做一个p2p的文件系统，所有的客户端都参与分发文件。当时觉得p2p的延迟比较高会是一个文件。不过现在觉得如果有比较好的预取机制的话，效果应该也不会太差。

​    - 这个p2p的系统需要做许多调优。例如将整个squashfs分成4M(这个数字我随便说的)的chunk，这个chunk作为最小传输单位，即​对于一个chunk，只从一个peer取，不再细分，继续细分会导致调度和验证变得复杂。

​    - 调度时尽量让同子网的人互相通信。

    - 可以采用p2p+CDN混合机制，设置一个阈值，例如对于一个chunk，在发起peer请求后1 ms内没有​开始传输或者N ms内没有完成传输，则自动开始从服务器上下载。

大致就这些想法吧。其实还有许多比较粗略的优化想法，如果真有这样的系统，能做的事情挺多的。​

--

Cheng,

Best Regards

[Bojie Li]

今天写了个 P2P 校园网络启动系统的初步设计，恳请各位多提意见。

ftp://lug.ustc.edu.cn/misc/P2P-Network-Booting-System.pdf

（放到 LUG FTP 上是不希望被搜索引擎爬到，因为我觉得这个题目是有可能发论文的）

（毕设还没搞定的时候写这个，我是不是在作死……）

[SJ Zhu]

最后远程挂载差分磁盘是直接去读中心存储的数据吗？这会不会很低效？

[Bojie Li]

2014-06-03 21:23 GMT+08:00 SJ Zhu <zsj9...@gmail.com>:

最后远程挂载差分磁盘是直接去读中心存储的数据吗？这会不会很低效？

是的。我没想到更好的方法，因为每个用户的差分内容都可能不相同，只能靠提高中心存储的带宽和 I/O 吞吐量来解决。你有什么办法吗？

[Bojie Li]

2014-06-03 21:47 GMT+08:00 Bojie Li <boj...@gmail.com>:

2014-06-03 21:23 GMT+08:00 SJ Zhu <zsj9...@gmail.com>:

最后远程挂载差分磁盘是直接去读中心存储的数据吗？这会不会很低效？

是的。我没想到更好的方法，因为每个用户的差分内容都可能不相同，只能靠提高中心存储的带宽和 I/O 吞吐量来解决。你有什么办法吗？

刚才想了想，如果允许系统镜像任意可写，那么每个用户都会形成一份独立的镜像（虽然大部分相同），这就破坏了 P2P 系统能工作的基本假设——很多系统镜像是相同的。我觉得性能上可以接受的是远程挂载用户磁盘（例如 Linux 的 /home 和 Windows 的 D: 盘），这个用户磁盘存储是逻辑上中心化的，可以用传统的分布式文件系统。

如果一定要求用户可写系统镜像，那就不如不要 P2P。是不是这样？

[Yuanchong Zhu]

差分部分就不做p2p了呗～

--

-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en

---
You received this message because you are subscribed to the Google Groups "USTC_LUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
灿烂星空，你就是我的英雄！

[Bojie Li]

2014-06-03 22:30 GMT+08:00 Yuanchong Zhu <redsk...@gmail.com>:

差分部分就不做p2p了呗～

问题是你怎么知道差分部分在哪里？KVM 如果用差分磁盘的话，每次磁盘读取都会先读取差分磁盘，后读取源磁盘。

如果想减少对差分磁盘的读取，只能预取一个类似 bitmap 的东西，表示源磁盘的哪些部分被修改了，一旦 KVM 欲读取的偏移量在 bitmap 中是被修改的，就去读差分磁盘，否则只读源磁盘就够了。bitmap 预取的开销基本上可以忽略，例如源磁盘（系统镜像）5 GB，块大小为 128 KB，则只需要 40 Kbit 的 bitmap，也就是 5 KB。但问题是差分部分会不会很分散，如果每个块里都写了一点，那么 bitmap 所节省的读取就不多了。我们只好再加上一个假设，用户对系统镜像的修改在磁盘存储上是相对集中的……（似乎有点道理）

另外如果允许修改系统镜像，就会有用户使用网络启动系统来做日常工作，系统总会变得越来越臃肿，也就是差分部分越来越多，直到很大一部分都要从中心存储去取，这样中心存储的 I/O 和带宽都无法承受。

[Zhang Cheng]

2014-06-03 18:49 GMT+08:00 Bojie Li <boj...@gmail.com>:

今天写了个 P2P 校园网络启动系统的初步设计，恳请各位多提意见。

ftp://lug.ustc.edu.cn/misc/P2P-Network-Booting-System.pdf

（放到 LUG FTP 上是不希望被搜索引擎爬到，因为我觉得这个题目是有可能发论文的）

（毕设还没搞定的时候写这个，我是不是在作死……）

​我觉得可以进一步明确实现这个东西的接口：p2p block device。

channel很好做，一个镜像文件就是一个channel（可以用文件的hash作为channel标识）。客户端不一定要用fuse，可以直接做一个block device driver，处理逻辑可能会更简单。因为一个fs肯定是有目录的，但我们实际上只需要一个文件，所以block device会更简单一些。这个block device可以是一个squashfs，也可以是一个qcow2镜像。

请求镜像块（不妨称之为blob）时，建议不用每次都连接tracker。客户端可以每10s与tracker heartbeat一次，heartbeat时可以干两件事，一个是告诉服务器我有哪些blob，另一个是获知哪些客户端在当前的channel，以及他们各自拥有的blob列表。当客户端需要请求一个blob时，不需要每次都问tracker要，而是从heartbeat得来的数据中自行选择peer，这样可以进一步减少响应延迟，当然服务器的压力会很大，可能需要部署多个tracker（每个客户端在生命周期里只连一个tracker，启动时可以随机选择一个，然后就用它了）。

另外，这个p2p系统应该有一个fallback机制，例如发现拥有正在请求的blob的peer数量少于一个阈值（如10个），那么就不从peer取了，而是从fallback取。fallback可以是一个特殊的peer，这个peer其实就是服务器，它永远在线。

至于拓扑结构的优化，我觉得在初期不用考虑太多，这东西没有数据的支撑意义不大，只有实际运作起来才行。就好像国内搞p2p的厂商，似乎还没见过谁大规模实施区域p2p的（例如每个省自行p2p），不是不能做，其他大家的平台都支持区域p2p，甚至代码都ready了，只是没有动力去做。而且每个peer都有随机的情况，全局随机选peer或许收益率最高。

即使要做拓扑优化的话，第一步也不要尝试自动优化（例如判断自动判断网段，根据网段选peer），可以先将学校按校区或者按楼分组，每个组内自行p2p。这样做实施也简单，效果也是可以预知的（至少不会比全校p2p的效果差）。

如果这个东西实际投入开发的话，建议客户端的逻辑尽量简单且少修改，毕竟是内核模块，修改起来很麻烦。在修改时尽量在服务端修改。就p2p本身的优化而言，大多数工作其实就是选peer，在服务端做其实就是返回一个特定的peer列表。

我近期打算花点时间来研究一下block device的驱动，看看能不能实现一个prototype出来。

--

Cheng,

Best Regards

[Zhang Cheng]

2014-06-03 22:46 GMT+08:00 Bojie Li <boj...@gmail.com>:

问题是你怎么知道差分部分在哪里？KVM 如果用差分磁盘的话，每次磁盘读取都会先读取差分磁盘，后读取源磁盘。

如果想减少对差分磁盘的读取，只能预取一个类似 bitmap 的东西，表示源磁盘的哪些部分被修改了，一旦 KVM 欲读取的偏移量在 bitmap 中是被修改的，就去读差分磁盘，否则只读源磁盘就够了。bitmap 预取的开销基本上可以忽略，例如源磁盘（系统镜像）5 GB，块大小为 128 KB，则只需要 40 Kbit 的 bitmap，也就是 5 KB。但问题是差分部分会不会很分散，如果每个块里都写了一点，那么 bitmap 所节省的读取就不多了。我们只好再加上一个假设，用户对系统镜像的修改在磁盘存储上是相对集中的……（似乎有点道理）

另外如果允许修改系统镜像，就会有用户使用网络启动系统来做日常工作，系统总会变得越来越臃肿，也就是差分部分越来越多，直到很大一部分都要从中心存储去取，这样中心存储的 I/O 和带宽都无法承受。

个人建议一开始不要先考虑kvm，而是老老实实的用squashfs+aufs，一步步的来，这个东西搞成熟了再搞kvm。或者这两件事分开做：

* p2p block device

* pxe启动kvm

​

两件事其实各有各的问题。比如kvm，其实问题挺多的，显卡性能不行应该是一个致命的问题。

--

Cheng,

Best Regards

[Bojie Li]

首先，不用开发内核模块，用 FUSE 就行，block device 可以认为是 FUSE 中的一个文件，客户端性能损失一点问题不大。用 FUSE 纯粹是为了开发简单。

其次，比起每取一块都到中心节点查询一次，我觉得找若干个固定的 peer 获取 bitmap 的方案可能是最好的。5 G 的系统磁盘镜像，128 KB 分块，bitmap 只有 5 KB。就算我连接 100 个 peer，获取 bitmap 也只需读取 500 KB，每分钟更新一次在校园网内根本算不上什么开销。客户端可以把自己的 bitmap 传递给中心节点，让掌握全局 bitmap 的中心节点决定选取哪些 peer，中心节点选取的策略可以很简单：选取那些有最多客户端没有的块的 peer，当然也可以做得更复杂。连接 100 个 peer 都找不到所需要的块，这只能说明这个块太少见了，直接去中心节点取。

这种固定 peer 做法的主要缺点是有一定的延迟，在所用带宽一定的前提下，需要在 peer 个数和更新频率间达到平衡。

--

[Bojie Li]

2014-06-03 22:52 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

两件事其实各有各的问题。比如kvm，其实问题挺多的，显卡性能不行应该是一个致命的问题。

我没试过，不过物理显卡不可以通过 IOMMU 直接映射进虚拟机吗？IOMMU 就是把物理机的一段 DMA 地址空间映射到虚拟机的一段地址空间的硬件，Intel 叫 VT-d，AMD 叫 HyperTransport，有了这个，虚拟机 DMA 读写显卡就不需要经过虚拟化层。比较新的电脑应该都支持 IOMMU。在显卡方面有什么特殊的吗？

[Zhang Cheng]

2014-06-03 23:01 GMT+08:00 Bojie Li <boj...@gmail.com>:

首先，不用开发内核模块，用 FUSE 就行，block device 可以认为是 FUSE 中的一个文件，客户端性能损失一点问题不大。用 FUSE 纯粹是为了开发简单。

​FUSE会使得开发简单这一点我清楚，但是我感觉做FUSE毕竟还是要处理一些无关的情况，例如inode，文件metadata，文件权限属性等，这些事其实都是我们不关心的，当然用FUSE的话，这些问题也都是一次性coding能解决掉的。

如果用block device的话，其实开发难度也不会增加太多，内核模块也可以动态insmod、rmmod，不过调试的门槛可能会高一些。使用block device我倒没有考虑过性能的问题，这点性能差不了太多。

这两者之间选择，其实我也没有太强烈的倾向性。

 

其次，比起每取一块都到中心节点查询一次，我觉得找若干个固定的 peer 获取 bitmap 的方案可能是最好的。5 G 的系统磁盘镜像，128 KB 分块，bitmap 只有 5 KB。就算我连接 100 个 peer，获取 bitmap 也只需读取 500 KB，每分钟更新一次在校园网内根本算不上什么开销。客户端可以把自己的 bitmap 传递给中心节点，让掌握全局 bitmap 的中心节点决定选取哪些 peer，中心节点选取的策略可以很简单：选取那些有最多客户端没有的块的 peer，当然也可以做得更复杂。连接 100 个 peer 都找不到所需要的块，这只能说明这个块太少见了，直接去中心节点取。

这种固定 peer 做法的主要缺点是有一定的延迟，在所用带宽一定的前提下，需要在 peer 个数和更新频率间达到平衡。

​选peer的具体算法我觉得已经属于优化的范畴了。你说的固定peer其实跟我的方案并不冲突，我的方案里其实就是会定时跟服务器通信，更新peer list和每个peer的bitmap表而已。更新peer list时可以给全部也可以给部分，例如你的方案就是每次heart beat都给固定的100个peer。这其实问题都不大。

 

--

Cheng,

Best Regards

[Zhang Cheng]

2014-06-03 23:18 GMT+08:00 Bojie Li <boj...@gmail.com>:

我没试过，不过物理显卡不可以通过 IOMMU 直接映射进虚拟机吗？IOMMU 就是把物理机的一段 DMA 地址空间映射到虚拟机的一段地址空间的硬件，Intel 叫 VT-d，AMD 叫 HyperTransport，有了这个，虚拟机 DMA 读写显卡就不需要经过虚拟化层。比较新的电脑应该都支持 IOMMU。在显卡方面有什么特殊的吗？

​显卡比较特殊，目前只有少数显卡可以通过vt-d直接接到kvm里面，参考：

http://www.linux-kvm.org/page/VGA_device_assignment​

--

Cheng,

Best Regards

[Bojie Li]

看不太懂，不过 KVM 以外的虚拟化技术有没有解决了这个问题的，比如 Xen？ 

[Bojie Li]

2014-06-03 22:52 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

个人建议一开始不要先考虑kvm，而是老老实实的用squashfs+aufs，一步步的来，这个东西搞成熟了再搞kvm。

想了想，感觉 squashfs + aufs 的方法除了不支持 Windows 虚拟机、不容易实现 suspend to cloud 以外，没有显著的缺点了。

Suspend to cloud，用 OpenVZ 的 chkpnt 功能可以实现。用户看到的是一个 OpenVZ 虚拟机，OpenVZ 虚拟机与主机是共享内核和设备驱动的，不太可能有不支持显卡之类问题。vzctl chkpnt 可以把进程和内核的状态保存到文件，vzctl restore 可以恢复虚拟机的状态。我曾经把 chkpnt 生成的 dump 文件、虚拟机的根目录和虚拟机配置文件复制到另外一台 CPU 核数和内存大小比原来小的机器，vzctl restore 后虚拟机正常运行。但如何让虚拟机“接管”主机的 USB 设备、显卡等，我还没想清楚。

[Zhang Cheng]

2014-06-03 23:01 GMT+08:00 Bojie Li <boj...@gmail.com>:

首先，不用开发内核模块，用 FUSE 就行，block device 可以认为是 FUSE 中的一个文件，客户端性能损失一点问题不大。用 FUSE 纯粹是为了开发简单。

​我又想了一下，我觉得FUSE会比block device有更好的灵活性。

在网络系统中，我们将来可能会需要多个镜像，例如将/usr单独做一个镜像，其他目录做一个镜像之类的（也许是为了更方便定制更新系统，也许是为了能够更合理的制作差分文件系统，只为感兴趣的分区的差分内存提供持久化存储等，这个暂时不讨论。）。如果用FUSE的话，就可以随意的添加文件了。这个FUSE文件系统里，每一个文件对应一个p2p的channel，在这个文件系统中，原则上可以访问到所有的镜像文件（只不过不使用而已）。

在实现方面，这个东西可以分为三个部件：

* tracker，图省事可以用HTTP，图性能（主要是协议的延迟）可以用udp

* ​p2p-client

* fuse interface

其中服务器端运行一个tracker，另外可以部署若干个p2p-client做fallback使用。在客户端将p2p-client和fuse interface整合起来。

不知道大家对go语言感兴趣么？我倒是有点想尝试一下用go语言实现。go的开发效率肯定比C要高，运行效率其实也不差（而且更容易写出高效的程序，比如我们线上的一个用于p2p的udp server，原来是用C++写的，不支持多线程，为了使用多核，只能一台机器上启动多个进程，这反而带来了许多问题，例如多个进程的负载是不均匀的，有的撑死了一个CPU，有的几乎空载。后来用go重写了，天然的多线程，许多问题都直接消失了）。另外，FUSE也有go的绑定，看上去性能还不错的样子。此外，go在部署上也有着很大的优势，基本上一处编译到处运行，不拖泥带水。

--

Cheng,

Best Regards

[Bojie Li]

如果 FUSE 有 go 的绑定的话我觉得用 go 挺好的，go 的编程模型很适合高并发。用 C 实现同样效果就需要异步 I/O，写起来很麻烦。不过我不会用 go，还要学习。

--

[Zuyi Hu]

lug的ftp帐号怎么获取？

Bojie Li <boj...@gmail.com>于2014年6月4日星期三写道：

[Bojie Li]

用户名密码都是 ftp

[Zuyi Hu]

谢谢！

Bojie Li <boj...@gmail.com>于2014年6月4日星期三写道：