自己规划了一个GFS＋iSCSI集群方案, 不知可行否？

jeepmac

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

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

oncity

不是什么大站，只是个小朋友社区。。。

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

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

最低4台机就足够了。

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

Irc_worm

那个负载均衡的设置为什么在光纤交换机之前，何解？？

nntp

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

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

Asyouwish

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

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

kingnowok

原帖由 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

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

justinchang

我想lz开始的做法肯定有问题，如果我做，前端肯定考虑lvs
后端图片的存储通常的做法，就是用盘柜，raid,光千，至于采取哪一家的就看你的预算，供应商等具体情况了。

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

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

jeepmac

原帖由 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

其实个人觉得前面还是使用4层交换机较好，扩展性灵活性和管理维护都比较方便，可靠性也比较高。