-- dreamingk [2004-08-09 00:59:32]

Open Global Name Service 1.0系统说明

Open Global Name Service（开放全局名称服务，以下简称OpenGNS）为OpenUSS（开放统一存储服务）提供7*24可持续运行的支持基础。本文档用以说明OpenGNS的系统功能、结构和整体框架，以及相关开发、使用的信息。

1. 系统概述

OpenGNS是一个名称指向的统称，它是由一系列的服务器硬件和服务器、客户机软件构成的名称指向系统。OpenGNS必须依靠可持续运行的系统架构基础进行部署，并将所有的服务器改造为支持该系统架构的机制，才可以真正实现它的目标。只是在现有系统中安装OpenGNS并不能解决任何问题。为解决大容量系统中的多层、多台、多级依赖的情况下系统管理和单点故障的问题。

它的应用主要有：

OpenGNS在系统中的体现主要有以下内容：

准确的来说，OpenGNS为可能拥有大量服务器的应用系统提供了低成本、高可扩展性、高可用性的基础服务。由于OpenGNS的特点，在设计时应特别关注以下问题：

2. OpenGNS的功能

OpenGNS会分布在所有与系统应用相关的服务器上。不理会其架构，我们先阐述清楚OpenGNS有什么样的功能。以下只要谈到服务，哪么就是一个在应用系统中需要关注的、它的运行装态会与别的服务紧密相关的程序。一台服务器可能运行多个服务，一台服务器也可能只运行一个服务。但我们不会理会一个服务运行于多台服务器上的情况，这种情况只会是使用集群技术，这时我们将这一群机器只会视为一台服务器。

UserCase

2.1. 服务注册

OGNS-reg

任何一个服务在启动时，都有义务向GNS服务器通知其在线工作。通过向GNS的通知，就使得应用系统中增加了一个服务。通常来讲，任何一个服务注册时需要告诉GNS的必须有以下信息：

GNS服务器会在自己的数据库中标识出该服务，真正标识的信息会有：

同时，GNS服务器也将会产生一条服务更新日志，其中的信息会有：

如果服务校验码不通过，则会产生一条认证安全日志：

在服务注册功能完成后，GNS会调用“服务变更通知”功能。以向依赖本类服务的服务通知新服务的存在。

2.2. 服务注销

OGNS-die

任何一个服务在停止时，都有义务向GNS服务器通知其下线停止工作。通过向GNS的通知，就使得应用系统中将一个服务取消。通常来讲，任何一个服务注销时需要告诉GNS的必须有以下信息：

GNS服务器会在自己的数据库中标识出该服务，真正标识的信息会有：

同时，GNS服务器也将会产生一条服务更新日志，其中的信息会有：

如果服务校验码不通过，则会产生一条认证安全日志：

在服务注销功能完成后，GNS会调用“服务变更通知”功能。以向依赖本类服务的服务通知服务的注销。

2.3. 服务查询

OGNS-search

任何一个服务在启动时都应当向GNS请求一个它所需要的当前在线工作的清单。它所需要的服务，我们统称它们为依赖服务。也就是一个服务的正常对外提供服务，可能会依赖一种或多种服务。而每个服务都可以进行分类。举例，在PyUSS中OpenUSO和OpenUSS就是两类服务，但是明显的情况下OpenUSO和OpenUSS之间不会有所关联，但是如果有一个Web Server在使用这两个服务，哪么我们就称OpenUSO和OpenUSS是Web的依赖服务。如果这两个服务出现变更都必须通知Web。反过来，每台Web服务器中的Web启动时，都应向GNS服务器查询可以使用的OpenUSO和OpenUSS服务的清单。 每次服务查询都会由各个服务发起，在启后注册后，它们就要取回自己需要的服务信息表，查询所需要的参数有：

GNS服务器为进行查询的服务反回：

看到具体的数据后，我们就可以明白，一个服务拿着自己的服务ID去向GNS寻找可以为自己提供支持的服务（依赖服务）种类有哪几种（如web需要OpenSO和OpenUSS），另外也知道服务种类中有几服务（OpenSO中有专为东北、西北、华北提供服务的机器），以及每个服务有几个可以使用的具体侦听（可以run在三台机器上哟，但是这三台机器有一模一样的数据，提供一模一样的服务---节点冗余）。最终，也可以得到万一这类服务中有一个服务ID出现问题了（也就是所有提供该服务ID的机器都死机了），将对该服务的操作转向哪些应争服务器。

2.4. 服务变更通知

OGNS-change

服务变更通知就是在服务状态发生变更的情况下将变更的服务状态通知给依赖于这个服务的所有服务。这个发起是GNS服务器，发起时通知的内容如下：

接收此通知的服务要向GNS服务器返回的信息如下：

2.5. 故障服务通知

当一个服务在调用一个它所依赖的服务时会发现目标服务不可用。如web服务器在调用服务类型为OUSS的chinaserver的192.168.2.1:2028时发现不可用，这时它就会启动故障服务通知功能。它会通知GNS服务器，目标服务已经不可用了。当然，同时它还可以选择该服务ID中其它的服务，但是这样的通知就不会让其它的web服务器再去做相同的失败尝式，同时也可以让这台机器的故障警告通过GNS服务器发给系统管理员。在服务发现故障时它会先向GNS服务器发出故障通知消息：

GNS服务器回复正确收到之后会向依赖这个服务的所有服务发送消息：

这样达到故障服务器迅速脱离系统服务群的目的。这里需要注意的是，故障消息中的服务状态也可以是服务响应慢，这样可以告知系统管理员，而不再向其它的服务进行广播，这部分策略由GNS服务来完成。这样做的目的是让系统接着运行，但是告诉系统管理员你应该去关心一台服务器中的一个服务的运行状态了，甚至可能去查一下是不是交换机上的网线有松动的现象。 与心跳系统不同的地方在于，这种“推”和“拉”的结合，会让GNS服务器的负载迅速下降，代码量也会下降，从而提高GNS这个核心系统的可用性。

2.6. 服务手工管理

这部分功能先不做详细的详述，在最后统一补充。它主要的工作就是系统管理员手工进行GNS操作的接口。如：管理服务类型、服务ID、服务认证信息等。

3. 系统处理流程

3.1. 服务启动时的处理流程

下图为一个服务启动时的处理流程： 

                                +------------+
                                |服务守护进程|
                                +-----+------+
                                      |
                                 +----+----+
                                 |GNS服务器|
                               **+---------+**
                           ****       *       ****
                        ***           *           ***
                    ****              *              ***
                 ***                  *                 ****
             ****                     *                     ***
 +---------**---------+    +--------------------+   +----------**--------+
 | 依赖它的服务守护进程 |    | 依赖它的服务守护进程|   | 依赖它的服务守护进程|
 +--------------------+    +--------------------+   +--------------------+

一个服务守护进程启动时使用“服务注册”功能向GNS进行注册，GNS服务器会通过“服务变更通知”功能向会使用该服务的服务进行告知。

3.2. 服务发现故障时的处理流程

与服务启动时的处理流程的图相同，只是一个服务进程发现另一个服务出现问题时通知GNS服务器，GNS服务器会向所有的依赖它的服务守护进程通知该服务点的不可用信息。

3.3. 服务停止时的处理流程

与服务启动时的处理流程的图相同，与发现故障所不同的地方在于要退出服务群中的服务主动提出自己要退出服务，从而完成主动通知的可能。

4. OpenGNS的静态结构和动态结构

在功能说明中阐述了一些报文结构，只是为说明问题而提供，在本节将详细定义出OpenGNS在服务器中存储的信息（静态信息）和运行时的进程/线程结构。对于OpenGNS的报文协议，请参见OpenGNSP（Open Global Name Service Protocol）相关文档。

4.1. OpenGNS的静态结构

OpenGNS的静态结构主要包括OpenGNS中存储服务信息的数据结构、系统的部署结构。

4.1.1. 服务数据存储结构

 **************          ************
 *服务类别ID  ************服务类别ID*            **************
 *服务类别名称**         *服务ID    **************服务ID      *
 *备份服务ID  * *        *服务名称  *            *服务侦听IP  *
 **************  *       ************            *服务侦听端口*
                  *                              **************
                   *
                    *
                     *
                      *
                       * ****************
                        **服务类别ID    *
                         *依赖服务类别ID*
                         ****************

在系统中存储三类数据，首先中服务类别，服务类别的使用可以多种多样，但是需要注意的是在一个应用系统中服务类别间分有依赖关系，只要明确类别间的依赖关系就可以形成一个非常清晰的服务类别体系了。 每一个服务类别都会包含若干服务，这些服务是应用系统高度可视的第二个层级，主要是将服务、服务器分块来进行管理，但是总的来说，服务的区别是提供相同的服务，但是可能服务的内容不同。也就是说，同是Web服务器，但是可能是新闻Web服务器、论坛Web服务器等。具体每个服务中可以有多个服务侦听，每个服务侦听都有主机名和端口组成。

4.1.2. 系统部署结构

系统部署于三类机器上：

在OpenGNS Server上部署OpenGNS Server Daemon，它提供OpenGNS Server、OpenGNS Admin、OpenGNS Push服务。

在OpenGNS Client上可以部署OpenGNS Client Daemon，它提供OpenGNS Client、OpenGNS Update服务。

* OpenGNS Admin Client 在OpenGNS Admin Client上可以通过Open GNS Client或是Open GNS Admin Client来访问OpenGNS服务器和管理服务器。

4.2. OpenGNS的动态结构

这里描述说明Openg GNS各个模块的工作时结构，主要为进程、线程间关系。

4.2.1. OpenGNS Server

4.2.2. OpenGNS Client

4.2.3. OpenGNS Admin Client

5. 系统模块及结构

/compass                主目录
  /opengnssd.tac        OpenGNS Server Daemon Twisted启动程序
  /opengnssd.py         OpenGNS Server Python启动程序
  /opengnscd.tac        OpenGNS Client Daemon Twisted启动程序
  /opengnscd.py         OpenGNS Client Python启动程序
  /opengnsc.py          OpenGNS Client启动程序
  /opengnsadmin.py      OpenGNS Admin Client启动程序
  /protocols            协议目录
    /opengnsp.py        OpenGNS Protocol
  /client               客户端目录
    /opengnsclient.py   OpenGNS Server Daemon访问相关代码
    /opengnspush.py     OpenGNS Client Daemon访问相关代码
    /opengnsadmin.py    OpenGNS Admin Daemon访问相关代码
  /daemon               Daemon目录
    /opengnsserverd.py  OpenGNS Server服务相关代码
    /opengnsupdated.py  OpenGNS 更新服务相关代码
    /opengnsadmin.dpy   OpenGNS Admin服务相关代码
  /util                 工具目录
    /log.py             日志相关代码
    /config.py          配置文件存取相关代码

这只是初期的一个参考，也需要再细化，现在还没有考虑进来的是具体的服务数据的存取代码。会随时变化。

6. 系统外部接口与外部系统

7. OpenGNS的讨论与建议

社区叫了啄木鸟，因为OpenGNS的特色，所以我想依据这个特色，将OpenGNS命名为compass（指南针）。

原因很简单的，大家只要理解了OpenGNS的工作原理和目标，哪么这个名字就了解它的含义了

PyUSS针对的是海量的存储，SAN/ISCSI/NetApp 这样的存储的容量的增加是需要很大的代价的。PyUSS可以使用一群普通的PCServer完成。存储甚至可以是IDE这样的设备。所以PyUSS第一个目标就是低成本。 还有一种存储系统，就是AFS/Coda这样的集群存储，它们可以使用一群服务器形成高速的取，但是存的速度是很慢的。 举个例子，我们可以看到google能search到sina网站上2000年的网页，但是在sina可能已经找不到这样的网页了。另一方面，我们可以看到，1g.com.cn的网络硬盘是一个冷热信息非常不对称的系统，有的文件会有成百上千的人来下，而有的文件放一辈子，在清除之前也许都不被使用。。。这样的例子很多，其实使用一般的存储系统，定会不平衡的使用存储的。 PyUSS正是尽力想办法解决这样的问题。用低成本，加上高可用性，来完成海量的存储。 我们来算一下： 一台pc server＋1T硬盘多少钱？如果是IDE应在2万上下，如果是SCSI应在3万上下。 一台SAN的1T多少钱？ 实质上，PyUSS就是针对哪种不是一天到晚将所有数据都操作一遍的应用系统。而SAN是考虑将一个Oracle部署其上，Oracle的数据库会实时的操作的。 应该说应用面不同。期望的成本也不相同。

OGNS 是通用的服务集成协议，可以应用到各种系统之上的， 比如说 我们谈过的 实用的知识共享管理系统/软件/机制/引擎 [WWW] http://www.linuxforum.net/forum/showflat.php?Cat=&Board=python&Number=479181&page=0&view=collapsed&sb=5&o=&fpart=1&vc=1 这么说就明白了， 将存储服务当作网站看待，OGNS 相当于针对OUSS 的DNS服务 可以让存储请求象URL请求一样快速定位到相应的动态目标服务对象上 是也乎？？ SAN 是通过高端硬件组合来实现， OUSS 是通过全新的服务索引协议来达成类似的功能？！？ 但是，我期望OUSS 可以象BT那样更加广阔，方便的应用起来，

如果再差一些，使用dns轮询也是一个好办法。 如果再过分一些，可以考虑使用一个集群，如LVS这样的系统来形成HA。 如果再烂一些，因为OpenGNS的数据量不大（我还没看过一个应用系统中服务器数量过万的）、它只是路过者而不是处理者（查完就断）、系统可分布式运行（查询服务和通知服务可以使用不同的机器完成）所以使用两台机器完全可以达到很强的稳定性。 总之，我能想到的就是这些了。

对，全局Map表是在GNS服务器端存在的。而GNS客户端是通讯所使用的。

[WWW] http://220.248.2.35:7080/share/Python/OpenUSS/GoogleFS/ [WWW] http://www.cs.rochester.edu/sosp2003/papers/p125-ghemawat.pdf 是e文的，挺难懂的，不过把gfs的设计思想，结构等等讲的很清楚。

卡的机器上实现，也可以在要求比较高的双网卡服务器群上实现。

服务类别（邮件存储）--->服务点（北京邮件存储）---->服务（192.168.2.1:2028） 由于是边写边想，这个名字存的有可能没有体现出这个层次来。

各个节点提供的是相同的服务，但各个节点的内容是不相同的。可能和大容量邮箱系统有点类似！

还有一种就是在通知服务时也通知另外的冗余服务器。我喜欢用第一种，因为一个好的盘柜就可以让系统在开发时不考虑过多的复杂程度就可以完成这样的事。当然还有一种做法就是使用一个很牛的数据库，所有的服务操作同一个数据库服务器就好。数据库服务器的同步和统一已经是很成熟的技术了。

（据说盛大的游戏服务器达到了10000多台，当然他们的系统不太一样，但总有一天会有这种系统需求，而且我相信应该是不久的将来） 也许只是一点胡思乱想，但我觉得这样的时代即将到来！

对该用户的数据的具体操作则会转向它最终定位的侦听端口了。USO提供了它要去哪个服务找，GNS提供了这个服务是哪个侦听端口，数据则就由USS自己提供了。 PyUSS---OpenGNS、OpenUSS、OpenUSO相信会是达到一个新的服务境界的思想的开拓者。做为这个思想的提出者，我已经与几个商业公司谈了我的想法，他们中已经有人在考虑做为支持者来支持我们这个社区。但是我相信随着互联网的发展，随着泡沫的飞去，随着真实，这个时代已经由Google的到来揭开了序幕，我更希望在国人中，有一群人，像apache对Web、Java的贡献一样，做一些有意义和价值的事。

考虑到这个问题，我建议HD在考虑节点最终名称标识的时候不要使用IP地址，可以使用一种特别命名机制。 一点建议，还没有考虑清楚。 我觉得还是那个想法，OGNS只考虑连接上来的服务节点，至于这个节点如何实现的（后面可能是磁盘柜或者其他冗余措施）我们不需要考虑，我们只把它看作一个单一的节点。

last edited 2005-01-16 15:48:30 by Zoom.Quiet