Chinaunix

标题: 自己规划了一个GFS＋iSCSI集群方案, 不知可行否？ [打印本页]

作者: jeepmac 时间: 2006-08-11 23:39
标题: 自己规划了一个GFS＋iSCSI集群方案, 不知可行否？
初来乍到，行个礼先！

要弄个网站，因为对服务器CPU的压力比较大, 可能开站准备弄5台Application server集群；对磁盘空间也要求较大，就成本考量，准备先买个iSCSI磁盘阵列。先画了个图：

负载均衡准备采用一台服务器，通过Apache＋mod_proxy_balancer来均衡; 图中只有5台Application server会使用到阵列空间, 所以在这5台上装Linux iSCSI client，并使用GFS挂载阵列空间以共享空间。5台服务器装CentOS和GFS是否可以呢？具体怎样安装呢？

数据库方面也打算两台服务器，不过不知Multi-Master Replication怎么弄？

对Linux, SAN, GFS尚属于摸索阶段，不知这种方案在实际应用中是否可行？会潜在一些什么问题？是否需要家一些其他元素，比如是否应该再加个负载均衡服务器的热备份？还请高人指点。

作者: nntp 时间: 2006-08-12 02:35
1. 为什么要用gfs? 5台app srv都需要同时读写iSCSI上面的相同数据么? 如果没有这样的需求，GFS就不需要了. 如果要同时读写同一数据，GFS必须.
2. 你看看自己画的图，难道没有发现一个很严重的问题么？万一你的Giga Switch挂掉了不但 load balancer不能访问app server, app srv连 iSCSI的通路都废掉，而且你的MySQL DB也有问题，这个拓扑是一个单点.
3. iSCSI也走giga switch, DB replication 也走，app srvx5 访问gfs也走giga switch, 没有考虑过I/O性能么? 你这样的情况，至少需要2台giga, iSCSI也是SAN(ip),所以你需要dedicate switch 为存储服务.
4.安装方法参考官方手册，本版置顶建议你看看完，linux和cluster都不熟的话，就找人来做.

作者: jeepmac 时间: 2006-08-12 08:34
谢谢！原来那么多疏漏啊

1. 5台app srv 要同时读写iSCSI上的数据，但不是同一数据，比如各个用户自己的图片；未来可能要增加app srv 到10台，或几十台。要GFS吗? 还有，5台srv读写的数据一般是10K～50K 的图片thumbnail.

2. 就是说需要在iSCSI和app srv之间增加一个giga switch？
数据库是供5台app srv使用的，怎样弄呢？

3. 同上，对吗？

4. Shanghai有没有人帮忙？

[ 本帖最后由 jeepmac 于 2006-8-12 09:34 编辑 ]

作者: oncity 时间: 2006-08-12 17:35
老实说，你这样的做成本也很高，特别现在的所谓'iSCSI磁盘柜' ，也不是硬件级东西.

读写整都限制在 20M/S 左右。

代成本的话，可以这样考虑，用NFS 共享数据给 app ，NFS主机同时提供 web 服务（纯图片）

app 只是处理请求。这样的效果会理想好多。

GFS 的必要性在于同时‘写’，就图片网站同时‘读’居多的情况下，真的没有太多的必要性。

作者: bjchenxu 时间: 2006-08-12 17:50
技术我就不分析了，但是大投资的方案一定要谨慎

我以前就多次犯过错误，对结果估计太好，做了巨大的投资，结果没有下文，你一定要吸取教训，不要为了技术而技术，重蹈覆辙

个人意见，仅供参考！

作者: jeepmac 时间: 2006-08-12 21:25

原帖由 oncity 于 2006-8-12 17:35 发表
代成本的话，可以这样考虑，用NFS 共享数据给 app ，NFS主机同时提供 web 服务（纯图片）
...

我找了一个其他网站的结构图：

这个网站文件存储的设计和oncity建议的很像（图中NFS部分），利用了web主机提供NFS服务，而且他们有说自己的这个web proxy主机选用了single P4 3.0GHz, 2GB RAM, SCSI U320 HDDs RAID-1。

这样的话如何做几T以上的空间呢？请原谅，就当是CU里面最愚蠢的问题好了，我是说选什么样的盘柜，给个型号和接口什么的，还有选什么样CPU＋RAM的NFS主机？如果磁盘空间再要求扩容呢？

[ 本帖最后由 jeepmac 于 2006-8-12 22:00 编辑 ]

作者: jeepmac 时间: 2006-08-12 21:27

原帖由 bjchenxu 于 2006-8-12 17:50 发表
技术我就不分析了，但是大投资的方案一定要谨慎

我以前就多次犯过错误，对结果估计太好，做了巨大的投资，结果没有下文，你一定要吸取教训，不要为了技术而技术，重蹈覆辙

个人意见，仅供参考！

是啊，我也是想办手里的钱能办的事情，谢谢提醒，我是想门儿清啊

作者: jeepmac 时间: 2006-08-12 22:10
哦，可以插卡（RAID/SCSI）连接外置磁盘柜

有便宜的磁盘柜吗？来放置SATA

作者: nntp 时间: 2006-08-12 22:24

原帖由 jeepmac 于 2006-8-12 22:10 发表
哦，可以插卡（RAID/SCSI）连接外置磁盘柜

有便宜的磁盘柜吗？来放置SATA

你这个是在开玩笑....

作者: nntp 时间: 2006-08-12 22:26

原帖由 jeepmac 于 2006-8-12 08:34 发表
谢谢！原来那么多疏漏啊

1. 5台app srv 要同时读写iSCSI上的数据，但不是同一数据，比如各个用户自己的图片；未来可能要增加app srv 到10台，或几十台。要GFS吗? 还有，5台srv读写的数据一般是10K～50K 的图片 ...

用户需求不明, 我看得实在费力.

5台app srv 到底怎么着？说清楚. 否则我就是白打字.

作者: jeepmac 时间: 2006-08-12 22:44
5台server主要执行ImageMagick进行用户图片的变换，生成的变换后的图片再存到磁盘阵上

作者: jeepmac 时间: 2006-08-12 22:58

原帖由 nntp 于 2006-8-12 22:24 发表

你这个是在开玩笑....

啊？消消火，不是那种“直连存储”的概念吗？

作者: nntp 时间: 2006-08-13 08:41

原帖由 jeepmac 于 2006-8-12 22:58 发表

啊？消消火，不是那种“直连存储”的概念吗？

我是说，你拿SATA作你这种应用的存储是在开玩笑. 你一定不知道 mutli login的SATA柜子的性能有多糟糕把. 哈.

作者: jeepmac 时间: 2006-08-13 08:51
多用户使用时，sata性能很低是吗？nntp大大，能推荐个柜和盘吗？或者机房里面可以租到？

作者: winterwolf 时间: 2006-08-13 09:42
文件系统用coda也可以建议先用3台普通pc做集群测试一下性能然后根据测试数据决定采用什么存储方案这是比较科学的方法

作者: jeepmac 时间: 2006-08-13 10:05

原帖由 winterwolf 于 2006-8-13 09:42 发表
文件系统用coda也可以建议先用3台普通pc做集群测试一下性能然后根据测试数据决定采用什么存储方案这是比较科学的方法

在这个ImageMagick的应用上，coda比NFS好在哪里？

作者: nntp 时间: 2006-08-13 13:12
coda又出来了.... 呵呵. 等一下PVFS, lustre都出来了. LZ的thread被水.....

作者: jeepmac 时间: 2006-08-13 13:47
集群、存储变化多端，对于喜欢见到实物的我来说还是一头雾水... hp 的声称100MB/s的MSA20不能满足这种服务要求吗？

multi login是指？用SCSI盘是必须的吗？

作者: winterwolf 时间: 2006-08-13 15:11
coda 支持离线操作和cilent端 catch 性能应该不错.

我了解也不多这是coda文档中的描述

Coda is a distributed filesystem with its origin in AFS2. It has many features that are very desirable for network filesystems. Currently, Coda has several features not found elsewhere.

1. disconnected operation for mobile computing
2. is freely available under a liberal license
3. high performance through client side persistent caching
4. server replication
5. security model for authentication, encryption and access control
6. continued operation during partial network failures in server network
7. network bandwith adaptation
8. good scalability
9. well defined semantics of sharing, even in the presence of network failures

最近在研究coda 如果有时间我会做个coda nfs的对比测试

作者: oncity 时间: 2006-08-13 19:29
标题: 回复 6楼 jeepmac 的帖子
结构大家都是差不多，但真实应用时，把压力都放在最新端的 proxy lighttpd ，而不用 LVS 和不同IP处理WEB 请求的话，效果很很差

例如 lighttpd 的设置，对于纯图片，HTML为了加速会考虑‘极端’的设置方法，来优化。

有空看看我的网站 http://www.oncity.cc

作者: jeepmac 时间: 2006-08-13 19:46
恩，那个lighttpd是别人家采用的方式，我们打算用Apache+mod_proxy_balancer分配负载到5台app srv, 在app srv上用mongrel http server，相当于LVS吗？对LVS一窍不通，望指正！

oncity真是个社区大站啊，而我们的这个前端的proxy基本上就是分配负载和NFS srv之用，图片也是app srv处理好再传给前端，负载不象你的社区网站那么大吧？

作者: oncity 时间: 2006-08-13 21:49
标题: 回复 21楼 jeepmac 的帖子
不是什么大站，只是个小朋友社区。。。

LVS 只是很普通的东西，好处在于简单直接，几句配置语法就做到负载，不用 apache 那些搞到好复杂

再说，5台 app 已经很夸张，我觉得你数据库的机器，装个 LVS ，两台做 app server ，NFS机装 lighttpd 显示图片

最低4台机就足够了。

一台机同一时间处理 TCP的连接是有限的，所以才用LVS这类方式。平台统一用最新的 SLED 10 ，够你方便了。

作者: Irc_worm 时间: 2006-08-14 09:39
那个负载均衡的设置为什么在光纤交换机之前，何解？？

作者: nntp 时间: 2006-08-14 11:07

原帖由 Irc_worm 于 2006-8-14 09:39 发表
那个负载均衡的设置为什么在光纤交换机之前，何解？？

他那个交换机是LAN switch, 也是一个function switch,用来个 iSCSI走的，我想LZ的图里面只不过没有把边界的switch画出来而已.

作者: Asyouwish 时间: 2006-08-14 12:34

原帖由 nntp 于 2006-8-13 13:12 发表
coda又出来了.... 呵呵. 等一下PVFS, lustre都出来了. LZ的thread被水.....

都来,都起方案,都起mini环境测试性能,都贴测试结果

作者: kingnowok 时间: 2006-08-14 14:19

原帖由 Asyouwish 于 2006-8-14 12:34 发表

都来,都起方案,都起mini环境测试性能,都贴测试结果

强烈同意！！！

对于web的图片应用，基于文件不大，而且对相同文件无同时写操作，无需GFS系统，NFS绝对可以满足了，既稳定维护又方便，而且性能也能保障。如果你是用作流媒体的源服务器应用，那NFS的性能肯定会出问题的，而GFS系统的同时读写性能确实远远好于NFS。
至于web的loadbanner就用LVS+Ldirectord应用就足够了，至少三台肯定没问题，当然具体还得看establish数，如果再多，就建议直接用四层交换机F5好了，就是价格好像有点贵赫赫。
对于数据库，也可采用lvs方式吧，后台用反线执行DB replication既可，串口线用作心跳线。
对于存储设备，要看你的心理价位是多少了，其实外面很多牌子的san存储也就几千块钱，贵的是fc硬盘的价格。其实有一种方式你可以考虑，既便宜又保证性能，现在很多san盘柜都支持直接连主机，无需delicate switch，不过也就最多连四台主机（ch0主/备，ch1主/备四口），采用loop方式可以满足共享存储的要求。

作者: wnoracle 时间: 2006-08-15 06:54
还是这里做的方案比较实在，大家对项目精益求精。但最近接触了几个政府的项目，硬件、软件配置绝对够豪华，但是肯定没什么应用，没什么负载，简直是太浪费了。

作者: justinchang 时间: 2006-08-15 09:39
标题: 不少好的主意
我想lz开始的做法肯定有问题，如果我做，前端肯定考虑lvs
后端图片的存储通常的做法，就是用盘柜，raid,光千，至于采取哪一家的就看你的预算，供应商等具体情况了。

还有个想法仅供大家参考，错了欢迎大家拍砖。

图片存在app server上，然后把路径记到mysql里，比如，img001的url是 image1.XXX.com\img20060815\070823\img001.jpg
当然appserver本身也要raid，定期近线备份。
不知道这样在低成本的情况下会不会好些。

作者: jeepmac 时间: 2006-08-15 10:02

原帖由 justinchang 于 2006-8-15 09:39 发表
图片存在app server上，然后把路径记到mysql里，比如，img001的url是 image1.XXX.com\img20060815\070823\img001.jpg
当然appserver本身也要raid，定期近线备份。
不知道这样在低成本的情况下会不会好些。

就是说放在某一台app server上，这台server上安装大的磁盘柜；而其他server访问图片就是访问一些url而不是通过NFS？

或者所有app server上都会有存储图片的功能？这样是不是所有的数据都被分散了啊

作者: yuguo 时间: 2006-08-15 10:10
其实个人觉得前面还是使用4层交换机较好，扩展性灵活性和管理维护都比较方便，可靠性也比较高。

作者: sttkx 时间: 2006-08-15 10:59
标题: 提供搂主交换机的小建议
giga switch只需要划分两个vlan就不需要买2个giga switch
同时switch不会是数据传输瓶颈所以100mbps switch 划分好vlan 可以应付数据交换交换机推荐华为s3050或者csico2950 比较稳定

作者: jeepmac 时间: 2006-08-15 11:08
机房里面会提供什么？交换机、盘阵可以租吗？

作者: justinchang 时间: 2006-08-15 12:02

原帖由 jeepmac 于 2006-8-15 10:02 发表

就是说放在某一台app server上，这台server上安装大的磁盘柜；而其他server访问图片就是访问一些url而不是通过NFS？

或者所有app server上都会有存储图片的功能？这样是不是所有的数据都被分散了啊

我的本意是这样做可以降低一些成本，至少省了潘贵。
appserver上本身就可以挂硬盘阿，做raid就可以了，具体是5还是0+1看应用了。
每台都都是自己的硬盘，数据分散在所有的appserver上，访问就用url就可以了。

这样做的好处是，系统伸缩性好，开始2台就可以了，费用只有你的方案的1/4。负载大了，就+机器。
不过这样做应用程序需要改动，但是工作量应该不可怕。

还有你最前面放一个squid 可能会好点。这个我不熟，你问问人吧。

作者: blue_stone 时间: 2006-08-16 09:14

原帖由 jeepmac 于 2006-8-12 22:10 发表
哦，可以插卡（RAID/SCSI）连接外置磁盘柜

有便宜的磁盘柜吗？来放置SATA

有盘桂支持sata硬盘，不知道那些存储厂商打算干嘛

作者: kingnowok 时间: 2006-08-16 09:58

原帖由 blue_stone 于 2006-8-16 09:14 发表

有盘桂支持sata硬盘，不知道那些存储厂商打算干嘛

现在很多盘柜是支持sata硬盘，但总线协议其实走的还是san，所以它在背板上做好了sata转san接口，这样也适合了不同用户和不同应用，毕竟sata比fc硬盘可便宜多了，而并行处理能力还要比fc的性能好，我们有流媒体应用有用的sata盘，还不错。

作者: kingnowok 时间: 2006-08-16 10:01

原帖由 jeepmac 于 2006-8-15 11:08 发表
机房里面会提供什么？交换机、盘阵可以租吗？

IDC机房一般提供机架位，ip地址，专线带宽等。。。
当然也提供盘柜，硬件设施的租用，而价格跟客户关系，租用数量，区域不同上下差别巨大。

作者: nntp 时间: 2006-08-16 10:06

原帖由 sttkx 于 2006-8-15 10:59 发表
giga switch只需要划分两个vlan就不需要买2个giga switch
同时switch不会是数据传输瓶颈所以100mbps switch 划分好vlan 可以应付数据交换交换机推荐华为s3050或者csico2950 比较稳定

我不同意你的说法，现在不是 performance的问题，现在是single point of failure的问题, 业务数据，block data，甚至 backup全部在这个giga switch上.

作者: nntp 时间: 2006-08-16 10:08

原帖由 blue_stone 于 2006-8-16 09:14 发表

有盘桂支持sata硬盘，不知道那些存储厂商打算干嘛

nearlin storage ,就是为这个目的。SATA介质最适合nearline storage了.

作者: 好好先生 时间: 2006-08-16 11:08
我现在还是对SATA盘柜不看好....低端一点儿就用SCSI,高端一点儿还是用光纤的吧...

作者: jeepmac 时间: 2006-08-16 13:25
像网易，flickr这种图片网站，用户不停的上传图片，他们是用的怎样的一个存储架构呢？规模是个什么样的？

作者: nntp 时间: 2006-08-16 13:33

原帖由 好好先生 于 2006-8-16 11:08 发表
我现在还是对SATA盘柜不看好....低端一点儿就用SCSI,高端一点儿还是用光纤的吧...

Agree. SCSI & Fiber based disk have more advantage on performance , scalability & availability

作者: nntp 时间: 2006-08-16 13:47

原帖由 jeepmac 于 2006-8-16 13:25 发表
像网易，flickr这种图片网站，用户不停的上传图片，他们是用的怎样的一个存储架构呢？规模是个什么样的？

ofcoz HSM. online + near line+offline, SAN for online I/O, cheap array/disk for near line and some traditional solutions for offline backup.

作者: Linuxcn.com 时间: 2006-08-17 14:32
看了张见识了...不知道我的方案什么时候能够实施得了,寒一个

作者: nntp 时间: 2006-08-17 20:03

原帖由 Linuxcn.com 于 2006-8-17 14:32 发表
看了张见识了...不知道我的方案什么时候能够实施得了,寒一个

8字口诀,

化繁为简，化整为零

作者: Linuxcn.com 时间: 2006-08-17 20:30
多谢建议

作者: haohaoo 时间: 2006-08-17 23:37
弄三台做LVS，上面同时跑TUX和apache，另外两台做mysql集群，TUX对静态图片处理很好的。

作者: alex_linux 时间: 2006-08-31 10:43
如果是直接存储，还是不要用sata 了，，

app 和 tape 还有磁盘阵列，都走一个switch？？？？

作者: brave623 时间: 2006-09-01 10:06
不好意思，问个题外话，LZ的这个图使用什么软件画的？？呵呵

作者: jeepmac 时间: 2006-09-01 17:09

原帖由 brave623 于 2006-9-1 10:06 发表
不好意思，问个题外话，LZ的这个图使用什么软件画的？？呵呵

OmniGraffle from www.omnigroup.com
Only for Mac OS X...

作者: nntp 时间: 2006-09-01 19:42
呵呵 :-)

作者: blue_stone 时间: 2006-09-04 08:59

原帖由 nntp 于 2006-8-16 10:08 发表

nearlin storage ,就是为这个目的。SATA介质最适合nearline storage了.

what is nearline storage?

作者: Kayv 时间: 2006-09-04 13:52

原帖由 blue_stone 于 2006-9-4 08:59 发表

what is nearline storage?

近线存储,介于在线和离线存储之间的东东

作者: wheel 时间: 2006-09-11 13:48
SATA很快阿，比scsi的同价格的快多了！也稳定，不过比同档次的慢一点，我觉得还是该同价格的比阿

作者: nntp 时间: 2006-09-11 20:11

原帖由 wheel 于 2006-9-11 13:48 发表
SATA很快阿，比scsi的同价格的快多了！也稳定，不过比同档次的慢一点，我觉得还是该同价格的比阿

呵呵，你有测试过 1分钟 2G数据的读写,每个文件大概在 16K以下的情况么？知道SATA vs SCSI在这种情况下的差别么? nearline 就是nearline. 而且你说稳定我觉得很不可思议，你知道SATA服务器用硬盘的MTBF多少么? 同样的SCSI多少么？不是一个档次的东西. 你说SATA稳定的技术上的依据是什么?

作者: baif 时间: 2006-09-11 21:51

原帖由 nntp 于 2006-9-11 20:11 发表

呵呵，你有测试过 1分钟 2G数据的读写,每个文件大概在 16K以下的情况么？知道SATA vs SCSI在这种情况下的差别么? nearline 就是nearline. 而且你说稳定我觉得很不可思议，你知道SATA服务器用硬盘的MTBF多少么 ...

WD 5000YS的现在做的是MTBF 1.2MHs，HITACHI的则是1MHs，都是7200RPMS .For SCSI between 1 and 1.5 million hours.

WD1500ADFD则号称 MTBF 1.2MHs，我看还可以。通过几家的比较，WD在这方面还是很领先。只是跟SCSI比，nntp大侠说的一分钟完成16K * 131072个文件，确实不知道实际效果会如何，不知道会有太合适的方案去接近。假设每个文件只需要一次IO操作，每次IO操作都成功，2184.533 IOPS应该就可以了吧。

作者: nntp 时间: 2006-09-11 22:46

原帖由 baif 于 2006-9-11 21:51 发表

WD 5000YS的现在做的是MTBF 1.2MHs，HITACHI的则是1MHs，都是7200RPMS .For SCSI between 1 and 1.5 million hours.

WD1500ADFD则号称 MTBF 1.2MHs，我看还可以。通过几家的比较，WD在这方面还是很领先。只 ...

sorry,不能说详细我的测试，不过结果是SATA的性能很不理想，远达不到关键应用的要求. 当然如果如果客户本来没什么苛刻的性能和稳定性要求，也无所谓SATA/SCSI了，哪各便宜买哪个.

作者: jeepmac 时间: 2006-09-11 23:32
俺是需要稳定性和性能的...呵呵

SATAII没有在这方面有显著提高吗？

[ 本帖最后由 jeepmac 于 2006-9-11 23:33 编辑 ]

作者: initx 时间: 2006-09-12 19:32
提示: 作者被禁止或删除内容自动屏蔽

作者: xxj119 时间: 2006-09-13 13:47
都是牛人！但不知道能理解这些性能细节的专业客户有多少

作者: baif 时间: 2006-09-17 21:27

原帖由 nntp 于 2006-9-11 22:46 发表

sorry,不能说详细我的测试，不过结果是SATA的性能很不理想，远达不到关键应用的要求. 当然如果如果客户本来没什么苛刻的性能和稳定性要求，也无所谓SATA/SCSI了，哪各便宜买哪个.

en,nntp你说得很对。如果可以不计成本或者说不能计成本的时候，SCSI还是要强很多。

作者: erjing 时间: 2006-10-14 00:26
标题: 回复 2楼 nntp 的帖子
性能不是很差，首先是交换机，其次一般G的交换机背板很高的。不过因该是有backup。

作者: gl00ad 时间: 2008-10-28 02:34
标题: 回复 #61 erjing 的帖子
I think this is good, worth reading!

作者: 双鱼石 时间: 2008-10-28 16:09

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)