Freeshell 资源枯竭问题大家来支招

67 views
Skip to first unread message

Bojie Li

unread,
Mar 31, 2015, 9:43:00 AM3/31/15
to USTC_LUG
现在 freeshell 用的机器是 2008 年 4 月购置,由 7 个节点构成,每个节点 8 核、16G 内存、300G 硬盘(所有节点另外共享 2T 外部存储),很多部件已经老化。Freeshell 现有 1740 台虚拟机,这个规模相当于什么呢,腾讯内部部署的 docker 私有云也才一万多台虚拟机,不过人家是有几千台物理服务器。

平均每台 8 核的机器运行着 250 台虚拟机,物理机长期有 3000~5000 个进程。56 个核的集群 load average 闲时有 100,忙时可以到 500 以上,忙的那个节点上的虚拟机会几乎无法登录。

目前这么高的负载和服务器故障率,根本原因是硬件资源供不应求。就像春运时的铁路,不管 12306 怎么优化都没法满足群众的购票需求。在极端条件下运行的 freeshell 无法保证服务的可用性,因此我们自己都不敢把重要服务放在 freeshell 上;也给维护人员带来了很多麻烦,比如经常要杀掉过于占资源的进程。我本来打算把 freeshell 搞成一个承载各种 LUG 服务的虚拟化平台,把负载均衡、数据库存储等做成公共云服务(而非 ad-hoc 的配置),但现在资源这么紧缺什么都做不了。

上周日 freeshell 的一块三星 SSD 坏了(用着用着突然就不识别了),由于在保修期内,返厂送修了。幸亏这块 SSD 目前只用作缓存,因此除了重启一个物理节点以外,没有造成数据损失。由于存储空间紧缺,freeshell 本来用作备份的硬盘都被用作存储了,也就是硬盘只要挂掉一块,就有一部分 freeshell 会永久消失。尽管 freeshell 用户协议里写着不对数据做任何保证,但很多用户的实验作业、网站等跑在 freeshell 上,如果数据丢失,会给很多同学带来麻烦。

上学期末宋虎老师问我们有什么网络服务缺少资源,可以挂靠到图书馆的名下,用图书馆的服务器。我当时说了 freeshell,但还没有写计划书。没写计划书的主要原因是维持 freeshell 正常运行所需的资源太多,至少需要是目前 freeshell 规模的 10 倍。简单更换几台配置一般的服务器只能是杯水车薪(当然,如果新服务器是 128G 内存,双路 E5,4T 硬盘这种级别,7 台这样的服务器也够了)。

当然我们可以通过清理不活跃用户、限制注册、限制运行程序等方式把 freeshell 的规模压下去,但我希望 freeshell 能继续为全校同学提供较高质量的服务。Freeshell 两年来确实起到了“车库”或者“实验田”的作用,比如 icard、ychat、选课查询、sage 科学计算,如果没有 freeshell,这些想法就很难找到校内资源来上线。大陆高校中给学生提供能够搭建网络服务的虚拟机平台的,我还没有听说过第二所(愿闻反例),大多数学校的虚拟机平台都是跟科大云一样,只能内网访问的。

如何让 freeshell 获取到足够的资源运行下去,或者采取什么方法来压缩 freeshell 的用户规模,大家有何高见?

YANG Boyuan

unread,
Mar 31, 2015, 10:06:45 AM3/31/15
to USTC_LUG

引用一下 @cuihao 原话:“VPS 是个无底洞。”用户的需求被挖掘出来以后肯定是只增不减的,更何况有 ipv6 有科学上网有教育网地址的 VPS,我曾经看见 V2EX 上面有人托科大同学注册 freeshell 的。

据我所知有一些学校的社团试图复制 freeshell 的做法,第二例可能不久就能出现;

一点思路:

采用续期制,删除不常用的 freeshell 虚拟机;

对于仅仅需要大量计算资源的用户,争取多分流到科大云和超级计算中心;

能否寻求网络中心的支持?在找到硬件支持的同时,也可以寻求将方向从 IaaS 向 PaaS,SaaS 转移。


--
-- 来自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+unsubscribe@googlegroups.com.
To post to this group, send email to ustc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

SJ Zhu

unread,
Mar 31, 2015, 10:17:55 AM3/31/15
to USTCLUG-Group
首先,禁止在freeshell上运行科学计算应用及高负荷程序,于是freeshell的load就下来了。
科学计算应用是科大超算中心的活,他们几千个核都满足不了需求,何况freeshell。

freeshell应该回归其本质,作为一个linux实验平台,freeshell != VPS

--
-- 来自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.

Yifan Gao

unread,
Mar 31, 2015, 10:37:13 AM3/31/15
to ustc...@googlegroups.com
可以像AWS一样给各项指标进行限制 (CPU、内存、IO、网络)。让其回归试验田的初衷。即便申请多个,也不会把某个节点搞跪。
但的确,这种做法扛不住数量多。一旦一个节点运行了数百个vps,即便资源限制再严格,也很难确保不把工作节点拖垮。
我们是不是可以考虑增强freeshell的迁移能力,找一些便宜的机器,比如某些地方报废的PC。每台母机上运行10~20个freeshell就行了。两个一组,做热备。
Yifan Gao




signature.asc

Bojie Li

unread,
Mar 31, 2015, 10:41:03 AM3/31/15
to USTC_LUG
2015-03-31 22:06 GMT+08:00 YANG Boyuan <073...@gmail.com>:

引用一下 @cuihao 原话:“VPS 是个无底洞。”用户的需求被挖掘出来以后肯定是只增不减的,更何况有 ipv6 有科学上网有教育网地址的 VPS,我曾经看见 V2EX 上面有人托科大同学注册 freeshell 的。

据我所知有一些学校的社团试图复制 freeshell 的做法,第二例可能不久就能出现;

今天突然写这么长,其实是因为上周末 SSD 挂掉丢了很多数据,今天在 freeshell 上跑爬虫准备爬点数据,结果挂了。我自己在参加一个数据挖掘比赛,挺影响进度的。现在 freeshell 的故障频率已经高到影响正常使用的程度了。

一点思路:

采用续期制,删除不常用的 freeshell 虚拟机;

我前面统计了 freeshell 的使用量,最近一个月登录过 freeshell 的用户占用了 67% 的磁盘空间。现在磁盘空间还剩 1T,倒不是很紧张。 

对于仅仅需要大量计算资源的用户,争取多分流到科大云和超级计算中心;

我觉得在 freeshell 上跑科学计算是导致 freeshell 出现中断的主要原因。Freeshell 也不是设计用来跑科学计算的,我觉得应该修改用户协议,予以禁止。正常的编译程序、跑网站占用的资源感觉不多。

技术上我们可能需要一种方式来自动限制科学计算类的应用(比如检测到 CPU 多少分钟持续占用 100% 就杀掉),而不是等到这类应用把服务器跑挂了才去修。

能否寻求网络中心的支持?在找到硬件支持的同时,也可以寻求将方向从 IaaS 向 PaaS,SaaS 转移。

我主要是担心这批 7 年前的硬件某天挂掉。LUG 其他的服务,要么用的是网络中心 VMWare ESX 的虚拟机,这是网络中心花钱买的,坏了是有商业支持的。要么是图书馆的几台不需要配置很高的服务器,新服务器补充的频率很容易达到旧服务器坏掉的频率。要么是 mirrors 服务器,这个如果真的坏掉了再搞一台是挺麻烦的。但 freeshell 本来就是在废弃的服务器上搭建的,而且少院没有能力更新硬件,一旦硬件坏掉,很难补充新机器,只能看着这个服务一点点消失。

我在科大的时间只有 3 个月了,不想开新坑把自己缠住。但我希望 freeshell 这个最耗资源的服务能够稳定运行下去,不一定规模很大,但不要哪天说挂就挂掉了。
 

On 2015年3月31日週二 21:43 Bojie Li <boj...@gmail.com> wrote:
现在 freeshell 用的机器是 2008 年 4 月购置,由 7 个节点构成,每个节点 8 核、16G 内存、300G 硬盘(所有节点另外共享 2T 外部存储),很多部件已经老化。Freeshell 现有 1740 台虚拟机,这个规模相当于什么呢,腾讯内部部署的 docker 私有云也才一万多台虚拟机,不过人家是有几千台物理服务器。

平均每台 8 核的机器运行着 250 台虚拟机,物理机长期有 3000~5000 个进程。56 个核的集群 load average 闲时有 100,忙时可以到 500 以上,忙的那个节点上的虚拟机会几乎无法登录。

目前这么高的负载和服务器故障率,根本原因是硬件资源供不应求。就像春运时的铁路,不管 12306 怎么优化都没法满足群众的购票需求。在极端条件下运行的 freeshell 无法保证服务的可用性,因此我们自己都不敢把重要服务放在 freeshell 上;也给维护人员带来了很多麻烦,比如经常要杀掉过于占资源的进程。我本来打算把 freeshell 搞成一个承载各种 LUG 服务的虚拟化平台,把负载均衡、数据库存储等做成公共云服务(而非 ad-hoc 的配置),但现在资源这么紧缺什么都做不了。

上周日 freeshell 的一块三星 SSD 坏了(用着用着突然就不识别了),由于在保修期内,返厂送修了。幸亏这块 SSD 目前只用作缓存,因此除了重启一个物理节点以外,没有造成数据损失。由于存储空间紧缺,freeshell 本来用作备份的硬盘都被用作存储了,也就是硬盘只要挂掉一块,就有一部分 freeshell 会永久消失。尽管 freeshell 用户协议里写着不对数据做任何保证,但很多用户的实验作业、网站等跑在 freeshell 上,如果数据丢失,会给很多同学带来麻烦。

上学期末宋虎老师问我们有什么网络服务缺少资源,可以挂靠到图书馆的名下,用图书馆的服务器。我当时说了 freeshell,但还没有写计划书。没写计划书的主要原因是维持 freeshell 正常运行所需的资源太多,至少需要是目前 freeshell 规模的 10 倍。简单更换几台配置一般的服务器只能是杯水车薪(当然,如果新服务器是 128G 内存,双路 E5,4T 硬盘这种级别,7 台这样的服务器也够了)。

当然我们可以通过清理不活跃用户、限制注册、限制运行程序等方式把 freeshell 的规模压下去,但我希望 freeshell 能继续为全校同学提供较高质量的服务。Freeshell 两年来确实起到了“车库”或者“实验田”的作用,比如 icard、ychat、选课查询、sage 科学计算,如果没有 freeshell,这些想法就很难找到校内资源来上线。大陆高校中给学生提供能够搭建网络服务的虚拟机平台的,我还没有听说过第二所(愿闻反例),大多数学校的虚拟机平台都是跟科大云一样,只能内网访问的。

如何让 freeshell 获取到足够的资源运行下去,或者采取什么方法来压缩 freeshell 的用户规模,大家有何高见?

--
-- 来自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+unsubscribe@googlegroups.com.
To post to this group, send email to ustc...@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.

Bojie Li

unread,
Mar 31, 2015, 10:46:09 AM3/31/15
to USTC_LUG
2015-03-31 22:37 GMT+08:00 Yifan Gao <ylgao...@gmail.com>:
可以像AWS一样给各项指标进行限制 (CPU、内存、IO、网络)。让其回归试验田的初衷。即便申请多个,也不会把某个节点搞跪。
但的确,这种做法扛不住数量多。一旦一个节点运行了数百个vps,即便资源限制再严格,也很难确保不把工作节点拖垮。
我们是不是可以考虑增强freeshell的迁移能力,找一些便宜的机器,比如某些地方报废的PC。每台母机上运行10~20个freeshell就行了。两个一组,做热备。

报废的 PC 放到哪里呢?网络中心和图书馆的机房肯定是不收的。放进少院机房,机房的物理空间也蛮有限的。如果每台母机上运行 10~20 个 freeshell,一千多个 freeshell,得上百台报废的 PC,哪里能放这么多 PC?除非像 BONIC 一样,把虚拟机放到各个学生机房的电脑上去,不过学生机房的网络条件、机器在线率都无法保证,虚拟机这种东西跟分布式计算、分布式存储还是很不一样的,后者可以做到很高的冗余,但虚拟机不容易。

Bojie Li

unread,
Mar 31, 2015, 10:53:17 AM3/31/15
to USTC_LUG
2015-03-31 22:17 GMT+08:00 SJ Zhu <zsj9...@gmail.com>:
首先,禁止在freeshell上运行科学计算应用及高负荷程序,于是freeshell的load就下来了。
科学计算应用是科大超算中心的活,他们几千个核都满足不了需求,何况freeshell。

我也认为应当禁止运行计算密集型程序。我们除了邮件警告以外,能不能自动识别并终止科学计算应用和高负荷程序?

我初步想的是定期统计每个进程所用的 CPU 时间和钟表时间(从进程创建至今的时间),如果 CPU 时间超过某个值,并且 CPU 时间与钟表时间之比大于某个值(表示该程序是计算密集的),就把它杀掉。这样可行吗?

Yifan Gao

unread,
Mar 31, 2015, 11:07:33 AM3/31/15
to ustc...@googlegroups.com


Bojie Li <boj...@gmail.com>于2015年3月31日星期二写道:

2015-03-31 22:37 GMT+08:00 Yifan Gao <ylgao...@gmail.com>:
可以像AWS一样给各项指标进行限制 (CPU、内存、IO、网络)。让其回归试验田的初衷。即便申请多个,也不会把某个节点搞跪。
但的确,这种做法扛不住数量多。一旦一个节点运行了数百个vps,即便资源限制再严格,也很难确保不把工作节点拖垮。
我们是不是可以考虑增强freeshell的迁移能力,找一些便宜的机器,比如某些地方报废的PC。每台母机上运行10~20个freeshell就行了。两个一组,做热备。

报废的 PC 放到哪里呢?网络中心和图书馆的机房肯定是不收的。放进少院机房,机房的物理空间也蛮有限的。
东区老图三楼机房(对! 就是C语言、数据结构课的上机的地方)里面有一个房间,有2个机架,放置了几台千兆交换机、几个光纤收发器,还有一个UPS。看起来像是校园网的某个汇聚节点。房间使用率不到5%。而且由于常年没人打理,房间格外得脏。我们可以向图书馆申请这个房间。对我们而言以后就有一个专属lug的机房了,对图书馆而言本来就是一个废弃的房间,现在还有人帮忙整理,估计图书馆也是愿意的。
如果每台母机上运行 10~20 个 freeshell,一千多个 freeshell,得上百台报废的 PC,哪里能放这么多 PC?
我担心的是到哪找这么多机器? 
除非像 BONIC 一样,把虚拟机放到各个学生机房的电脑上去,不过学生机房的网络条件、机器在线率都无法保证,虚拟机这种东西跟分布式计算、分布式存储还是很不一样的,后者可以做到很高的冗余,但虚拟机不容易。
如果热备困难,可以考虑做硬盘实时备份,一旦出问题,就让这个freeshell在别的节点上线。 
Yifan Gao(高一凡)

Zhang Cheng

unread,
Mar 31, 2015, 11:12:37 AM3/31/15
to USTC LUG
2015-03-31 22:37 GMT+08:00 Yifan Gao <ylgao...@gmail.com>:
可以像AWS一样给各项指标进行限制 (CPU、内存、IO、网络)。

​话说,AWS也有一种Instance Type,其对CPU的限制跟硬盘一样,保证一个​baseline performance,然后允许burst一会儿。不清楚他们这种限制方式是如何做到的。如果freeshell上可以有这种限制方式,效果倒是会不错,给大家提供一个比较低的baseline performance,偶尔有需求飙一下的也可以满足。

我不清楚openvz是否有对CPU、IO做accounting的功能?如果有的话,也许我们可以这样做,例如默认每个虚拟机每天允许使用 N 秒的CPU时间,如果超了,就把这个freeshell freeze住,到第二天再 unfreeze (当然,如果真的要用类似的方法的话,细节上也要调整,避免零点把所有的虚拟机都unfreeze,然后就死了)。IO也是如此。


技术之外,我们也要明确freeshell的初衷,并在使用协议里面体现出来。对于一些违反初衷的行为,无论是否可以通过技术的手段自动化检测、封禁,协议里条款都要到位,这样当人工检查发现时,也可以有理由去关停而不引起用户的反感。当然,协议也是可以经常更新的,毕竟我们资源有限,服务能力有限,大家也都会理解的。当协议有比较大的更新时,最好能够邮件告知用户。

对于使用限制,我觉得可以简单粗暴的写上,禁止一切CPU Intensive/Mem Intensive/IO Intensive的程序。在协议上,我们可以不对这些阈值给出具体规定,可以给出大概的参考值,最终解释权在维护者手里。例如像超算、挖矿这类场景,都可以按CPU Intensive给蔽掉。



--
Cheng,
Best Regards

Yifan Gao

unread,
Mar 31, 2015, 12:16:30 PM3/31/15
to ustc...@googlegroups.com


在 2015年3月31日星期二 UTC+8下午10:53:17,Bojie Li写道:
2015-03-31 22:17 GMT+08:00 SJ Zhu <zsj9...@gmail.com>:
首先,禁止在freeshell上运行科学计算应用及高负荷程序,于是freeshell的load就下来了。
科学计算应用是科大超算中心的活,他们几千个核都满足不了需求,何况freeshell。

我也认为应当禁止运行计算密集型程序。我们除了邮件警告以外,能不能自动识别并终止科学计算应用和高负荷程序?

我初步想的是定期统计每个进程所用的 CPU 时间和钟表时间(从进程创建至今的时间),如果 CPU 时间超过某个值,并且 CPU 时间与钟表时间之比大于某个值(表示该程序是计算密集的),就把它杀掉。这样可行吗?
也可以考虑调低进程优先级

Bojie Li

unread,
Mar 31, 2015, 11:28:25 PM3/31/15
to USTC_LUG
2015-03-31 23:12 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

2015-03-31 22:37 GMT+08:00 Yifan Gao <ylgao...@gmail.com>:
可以像AWS一样给各项指标进行限制 (CPU、内存、IO、网络)。

​话说,AWS也有一种Instance Type,其对CPU的限制跟硬盘一样,保证一个​baseline performance,然后允许burst一会儿。不清楚他们这种限制方式是如何做到的。如果freeshell上可以有这种限制方式,效果倒是会不错,给大家提供一个比较低的baseline performance,偶尔有需求飙一下的也可以满足。

是修改了虚拟化层的调度器。这么大规模的云服务,对 KVM 之类的虚拟化层肯定是深度定制的。这个我们恐怕做不来。 

我不清楚openvz是否有对CPU、IO做accounting的功能?如果有的话,也许我们可以这样做,例如默认每个虚拟机每天允许使用 N 秒的CPU时间,如果超了,就把这个freeshell freeze住,到第二天再 unfreeze (当然,如果真的要用类似的方法的话,细节上也要调整,避免零点把所有的虚拟机都unfreeze,然后就死了)。IO也是如此。

这个功能我没找到。

找到了个 cpulimit 选项,可以限制一个虚拟机不能占用超过某个百分比的 CPU,不管整个节点是否空闲。目前用的是 cpuunits 选项,指定了各个虚拟机 CPU 的占用比例,也就是 CPU 空闲的时候,一个虚拟机可以占用整个节点的 CPU 时间。 
 

技术之外,我们也要明确freeshell的初衷,并在使用协议里面体现出来。对于一些违反初衷的行为,无论是否可以通过技术的手段自动化检测、封禁,协议里条款都要到位,这样当人工检查发现时,也可以有理由去关停而不引起用户的反感。当然,协议也是可以经常更新的,毕竟我们资源有限,服务能力有限,大家也都会理解的。当协议有比较大的更新时,最好能够邮件告知用户。

对于使用限制,我觉得可以简单粗暴的写上,禁止一切CPU Intensive/Mem Intensive/IO Intensive的程序。在协议上,我们可以不对这些阈值给出具体规定,可以给出大概的参考值,最终解释权在维护者手里。例如像超算、挖矿这类场景,都可以按CPU Intensive给蔽掉。



--
Cheng,
Best Regards

--

Zhaohui Li

unread,
Apr 1, 2015, 7:30:03 AM4/1/15
to ustc...@googlegroups.com
我也觉得给用户定一个使用资源的上限比较好~

Hao Wang

unread,
Apr 2, 2015, 5:05:34 AM4/2/15
to ustc...@googlegroups.com
觉得可以考虑设置总资源使用上限,超过后降低其可使用资源的强度(类似国外运营商的数据流量使用上限,超过后限速很低的策略)。

另外,总资源使用上限和其申请的shell个数最好不要是线性关系,可以考虑是对数式什么的。

Zhang Cheng

unread,
Apr 2, 2015, 5:55:49 AM4/2/15
to USTC LUG

2015-03-31 22:41 GMT+08:00 Bojie Li <boj...@gmail.com>:
LUG 其他的服务,要么用的是网络中心 VMWare ESX 的虚拟,这是网络中心花钱买的,坏了是有商业支持的。

​跑题一下,我发现 VMWare ESXi 新的版本(5.5开始)有免费版了,大致看了一下,其免费版基本没有限制,只是没有集群相关的功能(如热迁移、资源池、cloud management等)。不知道网络中心是不是用的这个免费版,还是确认网络中心是购买了收费版的(我只是比较好奇)?​



--
Cheng,
Best Regards

Yifan Gao

unread,
Apr 2, 2015, 6:10:46 AM4/2/15
to ustc...@googlegroups.com
我记得VMWare ESXi 3.5就有免费版了(或许更早?)
Yifan Gao




signature.asc

Bojie Li

unread,
Apr 2, 2015, 7:03:12 AM4/2/15
to USTC_LUG
VMWare ESX(收费版)和 ESXi(免费版)应该是从一开始就有吧。网络中心是在 Windows Server 2003 上安装了 VMWare VCenter(而不是 VMWare ESX,我对 VMWare 这些版本搞不清楚),这个平台是从 2011 年就开始跑了。VMWare VCenter 是没有免费版的,因此我猜测网络中心是花钱买的。上次 blog 服务器挂掉,jamezhang 就给了我们一个账号,用 VMWare vSphere Client 登录进去管理(4.1 版客户端在 Win8.1 上用兼容模式才能安装成功。现在已经 6.0 版了)

图书馆机房有个虚拟机平台,也是 VMWare VCenter,据说也是网络中心搭建的。

[OT] james 当初给我临时维护用的账号之后一段时间,就把这个账号关闭了。不过 VMWare VCenter 里的用户是没有远程桌面权限的 Windows 用户,而关闭用户的方式是使该用户的密码过期。Windows 远程桌面登录时,如果使用过期的密码,会提示立即修改密码。改完密码之后 VMWare VCenter 就又能登录了。这不知道算不算 VMWare VCenter 的漏洞。

Zhang Cheng

unread,
Apr 2, 2015, 7:17:26 AM4/2/15
to ustc...@googlegroups.com
如果是vCenter的话,肯定是收费的。我的理解是,单独的esxi仅仅能在一台机器上使用,也就是管理时只能以单台物理机为单位。vCenter是esxi的基础上增加了集群管理的功能,管理时以集群为单位。

vSphere是一个管理客户端,其本身是不收费的。如果购买了vmware workstation的话,也可以用workstation来管理esxi,在某些方面,ws的体验更好(例如支持在一个ws应用窗口里同时管理多个esxi,而vSphere则只能一个进程管理一个esxi)。

esxi,我记得用5.1的时候专门找过keygen(好吧,暴露使用盗版的本质了。。。),应该是那时候免费版对硬件的限制比较高吧(具体我不记得了,但肯定是不能充分利用当时我的所有硬件资源,不然我应该不会去找keygen的)。
--
-- 来自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.
To post to this group, send email to ustc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
(sent from a mobile device)

Zhang Cheng

unread,
Apr 2, 2015, 7:26:17 AM4/2/15
to ustc...@googlegroups.com
http://en.m.wikipedia.org/wiki/VMware_ESX
根据wiki的描述,ESX和ESXi的关系并非免费和收费的关系,而是自某个版本起改名了。


On Thursday, April 2, 2015, Bojie Li <boj...@gmail.com> wrote:
--
-- 来自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.
To post to this group, send email to ustc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Thomas Copper

unread,
Apr 2, 2015, 7:48:48 AM4/2/15
to ustc_lug
注册可以考虑对协会实名的方式。必须是协会成员,协会成员每个人可以申请n个freeshell,这几个都和他实名绑定。在freeshell上面的后果有他本人负责。

记录freeshell活跃情况,多长时间不登录ssh执行命令就警告,再不登录就停止直到删除。

就是不知道有没有记录是否ssh登录过虚拟机执行命令的工具。

对于一些机器过度的占用资源的情况(比如servers.blog上面的一个人在7太机器上跑计算)和为校外人员申请freshell(下面“V2EX 上面有人托科大同学注册 freeshell”)的情况,可以考虑杀鸡儆猴,直接取消其所有lug网络服务的使用权限。到时候有人说使用条款没有这一条,就够告诉他们这叫做判例法:条文很简单,但是前面的判例可以作为以后判决的依据。


--

Zhang Cheng

unread,
Apr 2, 2015, 8:01:56 AM4/2/15
to USTC LUG

2015-04-02 19:48 GMT+08:00 Thomas Copper <univers...@gmail.com>:
对于一些机器过度的占用资源的情况(比如servers.blog上面的一个人在7太机器上跑计算)和为校外人员申请freshell(下面“V2EX 上面有人托科大同学注册 freeshell”)的情况,可以考虑杀鸡儆猴,直接取消其所有lug网络服务的使用权限。到时候有人说使用条款没有这一条,就够告诉他们这叫做判例法:条文很简单,但是前面的判例可以作为以后判决的依据。

​没必要扯什么“判例法”,搞的像黑社会一样。现在在条款里加上​加上就好了。例如“对于严重违反使用条款的行为,LUG保留取消其帐号、禁止使用其他LUG提供的公共服务的权力。严重违反使用条款的行为包括但不限于 1)为校外人员申请freeshell 2) 恶意占用freeshell资源 3) blabla ... 最终解释权归freeshell维护团队所有“,这样就好了。此外,这里对于”恶意占用freeshell资源“的判定,也不要太扣,一般如果初犯提醒一下,不再犯就好了,另外有一些由于程序bug导致占用过多资源的(如不小心写了个死循环),我们也是提醒就好了。freeshell的一个很大的作用是给大家一个发挥想象力的平台,太苛刻的条款就违背了这样的初衷了。

此外,也不必限定协会会员,注册使用学校的邮箱就足够实名了。



--
Cheng,
Best Regards

Thomas Copper

unread,
Apr 2, 2015, 8:07:57 AM4/2/15
to ustc_lug
2015-04-02 20:01 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

2015-04-02 19:48 GMT+08:00 Thomas Copper <univers...@gmail.com>:
对于一些机器过度的占用资源的情况(比如servers.blog上面的一个人在7太机器上跑计算)和为校外人员申请freshell(下面“V2EX 上面有人托科大同学注册 freeshell”)的情况,可以考虑杀鸡儆猴,直接取消其所有lug网络服务的使用权限。到时候有人说使用条款没有这一条,就够告诉他们这叫做判例法:条文很简单,但是前面的判例可以作为以后判决的依据。

​没必要扯什么“判例法”,搞的像黑社会一样。现在在条款里加上​加上就好了。例如“对于严重违反使用条款的行为,LUG保留取消其帐号、禁
止使用其他LUG提供的公共服务的权力。严重违反使用条款的行为包括但不限于 1)为校外人员申请freeshell 2) 恶意占用freeshell资源 3) blabla ... 最终解释权归freeshell维护团队所有“,这样就好了。此外,这里对于”恶意占用freeshell资源“的判定,也不要太扣,一般如果初犯提

打个比方而已,主要是怕现在的管理团队对于这种“模糊条款”有心理障碍,觉得这样做和“罪恶的zf”一样,就这么说了。线下的交流可以看着对方反应,线上的交流看不到。
 
醒一下,不再犯就好了,另外有一些由于程序bug导致占用过多资源的(如不小心写了个死循环),我们也是提醒就好了。freeshell的一个很大的作用是给大家一个发挥想象力的平台,太苛刻的条款就违背了这样的初衷了。

此外,也不必限定协会会员,注册使用学校的邮箱就足够实名了。
我把这件事儿给忘了,确实用学校邮箱就行……

 



--
Cheng,
Best Regards

Bojie Li

unread,
Apr 6, 2015, 6:18:32 AM4/6/15
to USTC_LUG
2015-03-31 22:06 GMT+08:00 YANG Boyuan <073...@gmail.com>:

能否寻求网络中心的支持?在找到硬件支持的同时,也可以寻求将方向从 IaaS 向 PaaS,SaaS 转移。

前两天跟 Armnotstrong 讨论,感觉 freeshell 跟科大云是功能相似的产品,而 freeshell 从架构上和资源上都比科大云落后很多,应该是被科大云淘汰的。只是科大云比 freeshell 的“附加功能”目前少一些,比如 IPv6、IPv4 可以出国、支持从校外端口映射访问、支持三级域名和 HTTP 代理。这些功能科大云要想做,没有本质技术困难的。

Freeshell 目前的主要用法是有点 PaaS 的感觉。对 Web 技术感兴趣的同学现在缺少一个快速搭建网络应用的平台,freeshell 作为裸的虚拟机,对 Linux 不熟悉的用户用起来还是蛮麻烦的。今天我看了 OpenShift,最新的社区版 3.0 用的是 docker 作为封装,可以快速部署一个 Web 应用,支持 JBoss / Tomcat / PHP / Python 2 & 3 / Ruby / Node.js / Vert.x / Perl 等 Web 开发语言,支持 MongoDB / MySQL / PostgreSQL 等数据库,还支持使用 Jenkins 做持续集成、Cron 计划任务。

事实上 Freeshell 现在的 Gallery 就是打算做这个的,事先封装好一些类型的应用,用户除了从裸的系统镜像创建 freeshell,还可以从 gallery 中的 freeshell “fork”。不过我们还没创建这些镜像(大家也不知道控制面板里的 Gallery 有什么用),这是个不错的方向(我们也可以提供 install from Docker hub 服务,就是把 Dockerfile 执行一遍,再把镜像目录 copy 到 freeshell 的 openvz 目录)。

不过 LUG 不是 Web 开发协会,提供 Web 开发的 PaaS 平台是有点偏离 LUG 主题的。喜欢折腾系统的同学可能更希望有自己可以更换内核、安装任意发行版的平台,科大云刚好满足这一需求。

不过目前科大云可能有些问题,刚刚建了两个虚拟机,网络不通;从 web console 看,启动特别慢(已经发邮件报 bug)。刚刚扫描了一下科大云的浮动 IP 网段,科大云的网关竟然就不通了,Web 界面也是响应非常缓慢。另外 Web 界面上的部分中文翻译也让人摸不着头脑。希望 LUG 对虚拟机感兴趣的同学参与改进科大云的性能,并给它增加一些功能。我觉得科大云可以有个从科大 PXE 网络启动的功能,这样就可以自行安装操作系统了(科大云官方提供的系统种类不多)。

Yifan Gao

unread,
Apr 6, 2015, 8:29:04 AM4/6/15
to ustc...@googlegroups.com
在 2015年4月6日,下午6:18,Bojie Li <boj...@gmail.com> 写道:

2015-03-31 22:06 GMT+08:00 YANG Boyuan <073...@gmail.com>:

能否寻求网络中心的支持?在找到硬件支持的同时,也可以寻求将方向从 IaaS 向 PaaS,SaaS 转移。

前两天跟 Armnotstrong 讨论,感觉 freeshell 跟科大云是功能相似的产品,而 freeshell 从架构上和资源上都比科大云落后很多,应该是被科大云淘汰的。只是科大云比 freeshell 的“附加功能”目前少一些,比如 IPv6、IPv4 可以出国、支持从校外端口映射访问、支持三级域名和 HTTP 代理。这些功能科大云要想做,没有本质技术困难的。

Freeshell 目前的主要用法是有点 PaaS 的感觉。对 Web 技术感兴趣的同学现在缺少一个快速搭建网络应用的平台,freeshell 作为裸的虚拟机,对 Linux 不熟悉的用户用起来还是蛮麻烦的。今天我看了 OpenShift,最新的社区版 3.0 用的是 docker 作为封装,可以快速部署一个 Web 应用,支持 JBoss / Tomcat / PHP / Python 2 & 3 / Ruby / Node.js / Vert.x / Perl 等 Web 开发语言,支持 MongoDB / MySQL / PostgreSQL 等数据库,还支持使用 Jenkins 做持续集成、Cron 计划任务。

事实上 Freeshell 现在的 Gallery 就是打算做这个的,事先封装好一些类型的应用,用户除了从裸的系统镜像创建 freeshell,还可以从 gallery 中的 freeshell “fork”。不过我们还没创建这些镜像(大家也不知道控制面板里的 Gallery 有什么用),这是个不错的方向(我们也可以提供 install from Docker hub 服务,就是把 Dockerfile 执行一遍,再把镜像目录 copy 到 freeshell 的 openvz 目录)。

不过 LUG 不是 Web 开发协会,提供 Web 开发的 PaaS 平台是有点偏离 LUG 主题的。喜欢折腾系统的同学可能更希望有自己可以更换内核、安装任意发行版的平台,科大云刚好满足这一需求。

不过目前科大云可能有些问题,刚刚建了两个虚拟机,网络不通;
可能需要手动添加网关,默认是无外网访问的

从 web console 看,启动特别慢(已经发邮件报 bug)。
嗯嗯 cloud-init已经跪了很久了,DO貌似也有这个问题,属于概率事件

刚刚扫描了一下科大云的浮动 IP 网段,科大云的网关竟然就不通了,Web 界面也是响应非常缓慢。
目前虚拟机已经严重超载,免费资源总是稀缺的。。。。
另外 Web 界面上的部分中文翻译也让人摸不着头脑。
额 是的,翻译得有些诡异。我给王硕吐槽过几次。。。。但大家一直懒得改,就没弄。。。。

希望 LUG 对虚拟机感兴趣的同学参与改进科大云的性能,并给它增加一些功能。我觉得科大云可以有个从科大 PXE 网络启动的功能,这样就可以自行安装操作系统了(科大云官方提供的系统种类不多)。
赞!这是一个好主意!

--
-- 来自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.
signature.asc

Bojie Li

unread,
Apr 6, 2015, 8:41:43 AM4/6/15
to USTC_LUG
2015-04-06 20:28 GMT+08:00 Yifan Gao <ylgao...@gmail.com>:
不过目前科大云可能有些问题,刚刚建了两个虚拟机,网络不通;
可能需要手动添加网关,默认是无外网访问的

当然添加了网关,我之前是能用的,是今天想起来去登录,发现不能用了。

Inline image 1
Inline image 3

虚拟机里连 IP 地址都分配不到。
Inline image 4


从 web console 看,启动特别慢(已经发邮件报 bug)。
嗯嗯 cloud-init已经跪了很久了,DO貌似也有这个问题,属于概率事件

为什么跪了呢?

刚刚扫描了一下科大云的浮动 IP 网段,科大云的网关竟然就不通了,Web 界面也是响应非常缓慢。
目前虚拟机已经严重超载,免费资源总是稀缺的。。。。

现在科大云的负载情况如何?不是说科大云 3.0 的硬件资源很多吗?现在有多少虚拟机? 

Yifan Gao

unread,
Apr 6, 2015, 11:52:06 AM4/6/15
to ustc...@googlegroups.com
在 2015年4月6日,下午8:41,Bojie Li <boj...@gmail.com> 写道:

2015-04-06 20:28 GMT+08:00 Yifan Gao <ylgao...@gmail.com>:
不过目前科大云可能有些问题,刚刚建了两个虚拟机,网络不通;
可能需要手动添加网关,默认是无外网访问的

当然添加了网关,我之前是能用的,是今天想起来去登录,发现不能用了。

<image.png>
<image.png>

虚拟机里连 IP 地址都分配不到。
<image.png>
我刚试了一下,网络的确出问题了。可以获取到ip,但无法访问外网(不过以前创建的虚拟机貌似可以正常联网),已经有人在定位故障。



从 web console 看,启动特别慢(已经发邮件报 bug)。
嗯嗯 cloud-init已经跪了很久了,DO貌似也有这个问题,属于概率事件

为什么跪了呢?
王硕说是服务器鸭梨太大了。。。。


刚刚扫描了一下科大云的浮动 IP 网段,科大云的网关竟然就不通了,Web 界面也是响应非常缓慢。
目前虚拟机已经严重超载,免费资源总是稀缺的。。。。

现在科大云的负载情况如何?不是说科大云 3.0 的硬件资源很多吗?现在有多少虚拟机? 
3.0用的还是那些旧硬件。运行超过1k个虚拟机。
signature.asc

Bojie Li

unread,
Apr 6, 2015, 12:33:38 PM4/6/15
to USTC_LUG
2015-04-06 23:51 GMT+08:00 Yifan Gao <ylgao...@gmail.com>:


在 2015年4月6日,下午8:41,Bojie Li <boj...@gmail.com> 写道:



2015-04-06 20:28 GMT+08:00 Yifan Gao <ylgao...@gmail.com>:
不过目前科大云可能有些问题,刚刚建了两个虚拟机,网络不通;
可能需要手动添加网关,默认是无外网访问的

当然添加了网关,我之前是能用的,是今天想起来去登录,发现不能用了。

<image.png>
<image.png>

虚拟机里连 IP 地址都分配不到。
<image.png>
我刚试了一下,网络的确出问题了。可以获取到ip,但无法访问外网(不过以前创建的虚拟机貌似可以正常联网),已经有人在定位故障。

我觉得科大云应该搞个用户交流论坛,方便用户与开发者的交流和用户之间的交流。当然我知道有官方邮箱可以发邮件,不过邮件很容易回复不及时。

事实上 LUG 的网络服务也应该有用户交流论坛,但我由于是服务开发者之一,不了解用户的需求。经常有人私信或者 QQ 问我 freeshell 的事情,我要是认真回复就挺浪费时间,要是不认真回复显得态度不好。如果有论坛,“高级用户” 就可以解决 “小白用户” 的这些问题,而且小白用户看了论坛里已有的回答也许问题就解决了。

现在我作为科大云的普通用户,就感觉到用户与开发者间交流的重要性。

3.0用的还是那些旧硬件。运行超过1k个虚拟机。

为什么不启用新硬件呢?留给 4.0 吗?旧硬件的配置怎么样,能不能贴出来?

Yifan Gao

unread,
Apr 6, 2015, 12:59:29 PM4/6/15
to ustc...@googlegroups.com
在 2015年4月7日,上午12:33,Bojie Li <boj...@gmail.com> 写道:



2015-04-06 23:51 GMT+08:00 Yifan Gao <ylgao...@gmail.com>:


在 2015年4月6日,下午8:41,Bojie Li <boj...@gmail.com> 写道:



2015-04-06 20:28 GMT+08:00 Yifan Gao <ylgao...@gmail.com>:
不过目前科大云可能有些问题,刚刚建了两个虚拟机,网络不通;
可能需要手动添加网关,默认是无外网访问的

当然添加了网关,我之前是能用的,是今天想起来去登录,发现不能用了。

<image.png>
<image.png>

虚拟机里连 IP 地址都分配不到。
<image.png>
我刚试了一下,网络的确出问题了。可以获取到ip,但无法访问外网(不过以前创建的虚拟机貌似可以正常联网),已经有人在定位故障。

我觉得科大云应该搞个用户交流论坛,方便用户与开发者的交流和用户之间的交流。当然我知道有官方邮箱可以发邮件,不过邮件很容易回复不及时。

事实上 LUG 的网络服务也应该有用户交流论坛,但我由于是服务开发者之一,不了解用户的需求。经常有人私信或者 QQ 问我 freeshell 的事情,我要是认真回复就挺浪费时间,要是不认真回复显得态度不好。如果有论坛,“高级用户” 就可以解决 “小白用户” 的这些问题,而且小白用户看了论坛里已有的回答也许问题就解决了。
这个想法不错,要不咱给LUG搭一个?

现在我作为科大云的普通用户,就感觉到用户与开发者间交流的重要性。

3.0用的还是那些旧硬件。运行超过1k个虚拟机。

为什么不启用新硬件呢?留给 4.0 吗?旧硬件的配置怎么样,能不能贴出来?
我有一段时间没去科大云那边了,可能是后来又增加了新硬件吧,这方面就不太清楚了
旧硬件见这篇帖子的讨论
signature.asc
Reply all
Reply to author
Forward
0 new messages