Differences between revisions 10 and 11
⇤ ← Revision 10 as of 2004-08-11 21:18:15 →
Size: 6538
Editor: hd
Comment:
← Revision 11 as of 2004-08-11 21:52:56 → ⇥
Size: 6539
Editor: Zoom.Quiet
Comment: USS必须要解决这个问题
Deletions are marked like this. Additions are marked like this.
Line 131: Line 131:
  * OUSS是大家开发的其中之一,若明若暗 类似的开源当然高兴可以借鉴,OGNS 才是中心所在,不仅仅关注存储的 -- by Zoomq
  * OpenAFS是读快写慢。USS必须要解决这个问题。		   * OUSS是大家开发的其中之一,若有类似的开源当然高兴可以借鉴,OGNS 才是中心所在,不仅仅关注存储的 -- by Zoomq
  * OpenAFS是读快写慢。USS必须要解决这个问题。-- by HD

本页面是项目主页面,建议不要轻易编辑,志愿人员请在相应的专门页面中进行贡献... -- Zoom.Quiet [DateTime(2004-08-04T23:18:57Z)] TableOfContents

源起

高性能分布式网络存储系统-- USS（统一存储服务器/服务)

初版描述

前些日子，我在面对一个亿用户级的邮件系统，这个邮件系统的存储是使用的NFS做存储系统。
举个例子，你们上http://mail.yahoo.com.cn 就会看到它写着 power by netapp。
大家可知netapp的系统多少钱吗？一个T的存储差不多四百万罢，哪么想想yahoo的投入有多少吗？

5000万用户*0.1G空间*10%使用率= 好多好多钱

哪么并不是所有的公司都能像yahoo一般的有钱，他们买了无数的netapp来做存储。

如果我们做一个高容量的邮件系统，比如google最近推出的gmail（我帐户就是gmail的帐户，我的mail
list的讨论就是在gmail上写的），它如果也像yahoo一样的使用空间，会投入难以数记的钱数。
哪么，
我们就需要一个改良的googlefs（http://www.cs.rochester.edu/sosp2003/papers/p125-ghemawat.pdf）系统结构来存储每一封邮件。
系统的结构应是有一群机器在做index service。
它告诉client说哪个用户在哪个服务器。
然后client到存储服务器上去对这个用户的存储进行操作。而存储的文件不是以真实的文做存储在机器上的，而是用一个个的chunk存储。

我们的开发主要集中在存储服务和索引服务上，但是先从存储服务开始。
如果大家想参与进来，请简单看看googlefs的文档，简单了解一下系统的架构，以及存储在这里的位置。
再就是看看twisted的文档，如果可行，我们可以组织起来将twisted文档中的howto翻译一下，
我个人认为这个howto是我见过的最好的网络服务开发指南了。

再就是我这里会对存储协议进行定义，可以先从邮件入手，再从泛意的文件入手。一步步的考虑。
不知大家意下如何？
----HD

HD

领头羊 ["HD"]--黄冬

  • [http://blog.huangdong.com/weblog.php?id=C0_5_1 weBlog]

  • 经历:
    • 喜爱FreeBSD、开源世界
    • 现在中国移动集团公司打扫卫生
    • 以前主要从事系统架构设计，之前在金融、电信行业中摸抓滚打
    • 家里有两位领导，一位是横眉冷对的大领导，一位是喜欢天线宝宝的小领导
    • ...

PyUSS

PyUSS是一个面向高可扩展性、高容量、低成本、可分布式的网络存储服务方案。该项目包含以下几个子项目：

OpenGNS

  • ["/OpenGNS"]

提供分布式的服务器群中服务器指向、服务器状态更新的功能。

OpenUSS

  • ["/OpenUSS"]

提供分布式的服务器存储功能。

OpenUSO

  • ["/OpenUSO"]

提供分布式的服务存储认证、基本用户Profile存取功能。

woodpecker.org

目标

项目的目标是通过分布式的存储服务功能取代原有大量使用的NFS、AFS、Coda这样的文件系统。

原有网络文件系统的问题

针对于NFS文件系统来讲，如果容量大到一定的程度会出现许多不可逾越的问题：

  • 如果某台NFS Server出现问题，会造成客户机的服务程序停止响应
  • 大量的NFS Client连接到了大量的NFS Server，维护难度过高
  • NFS服务器的更换会迫使系统暂停服务
  • 对于异地服务的支持能力不强

针对于AFS、Coda这样的文件系统来讲也有许多问题：

  • 它们都是读快写慢的文件系统不能提供好的读、写并发能力
  • 不能提供良好的异地服务能力
  • 不能良好的控制热点信息的分布

我们的目标

为了应于原有网络文件系统的不足，我们需要做到：

  • 良好的可持续运行能力
  • 良好的服务器间信息管理能力
  • 良好的异地、多地服务能力

总而言之，我们需要完成一个可分布式的、有良好管理能力的、高性能的、高可扩展能力的存储服务系统。

开发计划

从现有大家的情况来讲，我考虑先从OpenGNS入手，再从OpenUSS、OpenUSO深入。 在确认功能的同时，也就是现在，我们应先针对于Python、Twisted的开发规范、编码规范、单元测试编码规范、开发方法进行一些约定。在这些条件都具备的情况下，再开始进行系统功能的编码、单元测试的编码。最终完成相关的功能进行发布。

  • OpenGNS

针对于OpenGNS，首先是确认OpenGNS的功能需求，在功能确认的基础上确认系统的功能模块、系统架构以及OpenGNS的访问协议。

  • Python开发规范
  • Twisted开发规范
  • 单元测试编码规范
  • 开发方法指南
  • 集成开发环境指南
  • 配置管理使用指南

开源协议

有待讨论指定

项目组织

管理成员

  • 项目组织：HD（黄冬）
  • 项目文档组织：天成、Zoomq
  • 配置管理：
  • 进度跟踪：

志愿贡献

  • ["/PyUSScontribute"]
    • -- 这是个自由开发的项目,请有兴趣的人员在此页面记录自个儿的真实信息,以便各管理志愿者进行协调

项目计划

  • ["/PyUSS开发日程"]
    • --- 含各种分课题的计划,日程!

项目资源

  • CVS服务器
  • 测试服务器
  • 参考资料

    • ["解读 PyTwisted"] 提供了HD在学习和使用Twisted时的一些Blog集成后的文章

    • ["PyTwisted"] 提供了Twisted的相关文档的翻译稿，项目开发必读的文章

基准代码

  • ["/benchmarks"] -- 测试平台; 演化,UML设计等等

相关知识

收集整理开发过程中大家发现,使用,迷惑的知识点,包括基础的东西是也乎

  • ["FAQnetwork"] -- TCP/IP;UCP......

  • ["PyThread"] -- 线程编程

  • ["PyOptimize"] -- Python 代码优化经验收集!

讨论

  • http://www.openafs.org/ 这个网站也是个分布文件系统，不知道是不是和你的的项目重复。by tomz

    • OUSS是大家开发的其中之一,若有类似的开源当然高兴可以借鉴,OGNS 才是中心所在,不仅仅关注存储的 -- by Zoomq
    • OpenAFS是读快写慢。USS必须要解决这个问题。-- by HD

PyUSS (last edited 2009-12-25 07:16:42 by localhost)