-- dreamingk [2004-08-09 00:59:32]
Open Global Name Service 1.0系统说明
Contents
1. 系统概述
OpenGNS是一个名称指向的统称，它是由一系列的服务器硬件和服务器、客户机软件构成的名称指向系统。OpenGNS必须依靠可持续运行的系统架构基础进行部署，并将所有的服务器改造为支持该系统架构的机制，才可以真正实现它的目标。只是在现有系统中安装OpenGNS并不能解决任何问题。为解决大容量系统中的多层、多台、多级依赖的情况下系统管理和单点故障的问题。
它的应用主要有：
- 服务发现、服务寻找
- 单点故障的紧急响应
- 服务指向、服务路由
OpenGNS在系统中的体现主要有以下内容：
- 所有的服务器都会使用OpenGNS所提供的OpenGNSP协议与OpenGNS服务器进行通信
- 在可行的情况下，大家可以使用OpenGNS所提供的统一API与OpenGNS进行沟通
- OpenGNS会变为一个大容量的系统单元运行在系统的核心层
准确的来说，OpenGNS为可能拥有大量服务器的应用系统提供了低成本、高可扩展性、高可用性的基础服务。由于OpenGNS的特点，在设计时应特别关注以下问题：
- 由于OpenGNS是核心服务器，所以应特别注意它的单点故障问题
- 由于OpenGNS会服务于所有的服务器以及服务器中的服务程序，所以它的服务对象会非常的多，为了降低其因高负载而出现问题的机会，所以在系统架构时应尽量考虑将OpenGNS设计为“路过者”而不是“处理者”
- 在客户端和服务器端都会启动侦听，以适应推和拉两种信息更新方式
- 由于OpenGNS的服务对应于多个服务/服务器，所以信息的处理可以使用“推”和“拉”结合的方法减少服务器的负载，同时提高系统的可用性
- 尽量减少OpenGNS存储的数据（字段数和条数）
2. OpenGNS的功能
OpenGNS会分布在所有与系统应用相关的服务器上。不理会其架构，我们先阐述清楚OpenGNS有什么样的功能。以下只要谈到服务，哪么就是一个在应用系统中需要关注的、它的运行装态会与别的服务紧密相关的程序。一台服务器可能运行多个服务，一台服务器也可能只运行一个服务。但我们不会理会一个服务运行于多台服务器上的情况，这种情况只会是使用集群技术，这时我们将这一群机器只会视为一台服务器。
2.1. 服务注册
任何一个服务在启动时，都有义务向GNS服务器通知其在线工作。通过向GNS的通知，就使得应用系统中增加了一个服务。通常来讲，任何一个服务注册时需要告诉GNS的必须有以下信息：
- 服务ID
- 服务校验码
- 注册附加参数
GNS服务器会在自己的数据库中标识出该服务，真正标识的信息会有：
- 服务ID
- 服务地址（IP地址）
- 服务端口
- 服务状态
- 状态更新时间
同时，GNS服务器也将会产生一条服务更新日志，其中的信息会有：
- 时间
- 操作类型（注册）
- 服务ID
- 服务地址（IP地址）
- 服务端口
- 服务变更后状态
如果服务校验码不通过，则会产生一条认证安全日志：
- 时间
- 操作类型（注册）
- 服务ID
- 注册附加参数
- 发起IP
在服务注册功能完成后，GNS会调用“服务变更通知”功能。以向依赖本类服务的服务通知新服务的存在。
2.2. 服务注销
任何一个服务在停止时，都有义务向GNS服务器通知其下线停止工作。通过向GNS的通知，就使得应用系统中将一个服务取消。通常来讲，任何一个服务注销时需要告诉GNS的必须有以下信息：
- 服务ID
- 服务校验码
- 注销附加参数
GNS服务器会在自己的数据库中标识出该服务，真正标识的信息会有：
- 服务ID
- 服务地址（IP地址）
- 服务端口
- 服务状态
- 状态更新时间
同时，GNS服务器也将会产生一条服务更新日志，其中的信息会有：
- 时间
- 操作类型（注销）
- 服务ID
- 服务地址（IP地址）
- 服务端口
- 服务变更后状态
如果服务校验码不通过，则会产生一条认证安全日志：
- 时间
- 操作类型（注销）
- 服务ID
- 注销附加参数
- 发起IP
在服务注销功能完成后，GNS会调用“服务变更通知”功能。以向依赖本类服务的服务通知服务的注销。
2.3. 服务查询
任何一个服务在启动时都应当向GNS请求一个它所需要的当前在线工作的清单。它所需要的服务，我们统称它们为依赖服务。也就是一个服务的正常对外提供服务，可能会依赖一种或多种服务。而每个服务都可以进行分类。举例，在PyUSS中OpenUSO和OpenUSS就是两类服务，但是明显的情况下OpenUSO和OpenUSS之间不会有所关联，但是如果有一个Web Server在使用这两个服务，哪么我们就称OpenUSO和OpenUSS是Web的依赖服务。如果这两个服务出现变更都必须通知Web。反过来，每台Web服务器中的Web启动时，都应向GNS服务器查询可以使用的OpenUSO和OpenUSS服务的清单。 每次服务查询都会由各个服务发起，在启后注册后，它们就要取回自己需要的服务信息表，查询所需要的参数有：
- 服务ID
- 查询附加参数
GNS服务器为进行查询的服务反回：
- 依赖服务类型数量
- 依赖服务类型 （以下重复m次，m=依赖服务类型数量）
- 服务ID
- 服务数量
- 服务地址：服务端口（本记录重复n次，n=服务数量）
- 服务类应急服务ID
- 应急服务数量
- 服务地址：服务端口（本记录重复n次，n=服务数量）
看到具体的数据后，我们就可以明白，一个服务拿着自己的服务ID去向GNS寻找可以为自己提供支持的服务（依赖服务）种类有哪几种（如web需要OpenSO和OpenUSS），另外也知道服务种类中有几服务（OpenSO中有专为东北、西北、华北提供服务的机器），以及每个服务有几个可以使用的具体侦听（可以run在三台机器上哟，但是这三台机器有一模一样的数据，提供一模一样的服务---节点冗余）。最终，也可以得到万一这类服务中有一个服务ID出现问题了（也就是所有提供该服务ID的机器都死机了），将对该服务的操作转向哪些应争服务器。
2.4. 服务变更通知
服务变更通知就是在服务状态发生变更的情况下将变更的服务状态通知给依赖于这个服务的所有服务。这个发起是GNS服务器，发起时通知的内容如下：
- 服务类型
- 服务ID
- 服务地址（IP地址）
- 服务端口
- 服务状态
- 状态更新时间
接收此通知的服务要向GNS服务器返回的信息如下：
- 正确与否的应答状态码
2.5. 故障服务通知
当一个服务在调用一个它所依赖的服务时会发现目标服务不可用。如web服务器在调用服务类型为OUSS的chinaserver的192.168.2.1:2028时发现不可用，这时它就会启动故障服务通知功能。它会通知GNS服务器，目标服务已经不可用了。当然，同时它还可以选择该服务ID中其它的服务，但是这样的通知就不会让其它的web服务器再去做相同的失败尝式，同时也可以让这台机器的故障警告通过GNS服务器发给系统管理员。在服务发现故障时它会先向GNS服务器发出故障通知消息：
- 服务ID
- 服务地址
- 服务状态
- 故障附加参数
GNS服务器回复正确收到之后会向依赖这个服务的所有服务发送消息：
- 服务ID
- 服务地址
- 服务状态
- 故障附加参数
这样达到故障服务器迅速脱离系统服务群的目的。这里需要注意的是，故障消息中的服务状态也可以是服务响应慢，这样可以告知系统管理员，而不再向其它的服务进行广播，这部分策略由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上部署OpenGNS Server Daemon，它提供OpenGNS Server、OpenGNS Admin、OpenGNS Push服务。
- OpenGNS Client
在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的讨论与建议
HD: 呵呵，在写系统说明时，一直在想OpenGNS的对外发布时的命名。
社区叫了啄木鸟，因为OpenGNS的特色，所以我想依据这个特色，将OpenGNS命名为compass（指南针）。
原因很简单的，大家只要理解了OpenGNS的工作原理和目标，哪么这个名字就了解它的含义了
limodou: 现在不是有一个存储局域网的概念吗？与它有什么关系，还是就是它的一个实现，它现在有没有什么标准？
HD:SAN是一个专用的系统，首选它需要一群高价格的设备，千M交换机、TOE的网卡、SAN的驱动等。它的想法是将存储网络化。现在还可以看到ISCSI这样的概念，但是没有硬件支持的情况下还是很难以应用。
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的数据库会实时的操作的。 应该说应用面不同。期望的成本也不相同。
Zomm.Quiet: SAN 是专用的硬件分布存储系统，
OGNS 是通用的服务集成协议，可以应用到各种系统之上的， 比如说 我们谈过的 实用的知识共享管理系统/软件/机制/引擎 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那样更加广阔，方便的应用起来，
limodou: OpenGNS是单机还是集群，有没有均衡负载
HD:准确的来讲，OpenGNS对外是一个或几个服务器，可以使用一个四层交换机完成它的假集群和假负载均横的功能。一般的四层还支持健康检查，所以在外表看来它就像一台机器一样。
如果再差一些，使用dns轮询也是一个好办法。 如果再过分一些，可以考虑使用一个集群，如LVS这样的系统来形成HA。 如果再烂一些，因为OpenGNS的数据量不大（我还没看过一个应用系统中服务器数量过万的）、它只是路过者而不是处理者（查完就断）、系统可分布式运行（查询服务和通知服务可以使用不同的机器完成）所以使用两台机器完全可以达到很强的稳定性。 总之，我能想到的就是这些了。
limodou: OpenGNS会分布在所有与系统应用相关的服务器上
- 这句话如何理解。是不是OpenGNS要在所有机器上进行部署。看前面的说明，OpenGNS是一个服务结点，感觉在逻辑上是一个中心结点，其它机器与之相连。但OpenGNS软件要所以机器均安装，只有目录数据是统一存放在OpenGNS的中心机上，不知道是不是这个意思。
HD: OpenGNS会分为GNS服务器端和GNS客户端两部分。服务器在GNS服务器上部分，GNS客户端需要每个服务集成或部署一份的。
对，全局Map表是在GNS服务器端存在的。而GNS客户端是通讯所使用的。
Frank: 建议大家去看看hd推荐的google的那篇文章
http://220.248.2.35:7080/share/Python/OpenUSS/GoogleFS/ http://www.cs.rochester.edu/sosp2003/papers/p125-ghemawat.pdf 是e文的，挺难懂的，不过把gfs的设计思想，结构等等讲的很清楚。
HD:在PyUSS中与GoogleFS最大的不同在于，它也要面对可能大量的写操作，而不是读多写少。
Dirk Ye: 是否可以考虑通过“心跳”机制来实现节点在线状态的查询，我觉得只是让节点主动注销不够稳定，需要把系统底层引起的服务节点不可用（服务节点无法注销）问题考虑到。
HD:这部分的考虑已经在里面了，为了减少GNS服务器的负载，所以我使用了另外一种处理办法来解决心跳问题。就是后面要写的《故障服务通知》部分。
HD: 昨天做饭的时候考虑过这个问题，心跳是可以的，可能用另外一种基于协议的方式来通讯，这样可以在单网
卡的机器上实现，也可以在要求比较高的双网卡服务器群上实现。
- 用nas和其他共享存储设备的话，存在当一个IP死掉的时候，另外一台机器如何接管。这个又是集群的概念了。但是这么做会提高造价，和项目初衷相违背。 能让数10台服务器启动的时候和只有一台服务器运行的时候，客户机都能正确的找到路由是比较重要的。 或许dns的解析过程更值得借鉴。
Dirk Ye: 另外，将“以及每个服务有几个可以使用的具体侦听（可以run在三台机器上哟，但是这三台机器有一模一样的数据，提供一模一样的服务）”这个概念表示为“节点镜像”或“节点冗余”？？
HD:呵呵，这两个词中节点冗余更准确。之所以要白话说出，是为了简单易懂。
Dirk Ye: 在OGNS中，用于“节点冗余”的各服务ID 和 不同服务的各服务ID之间是相同对待还是有不同的级别处理？（我的理解是不同对待，但需要考虑使用什么样的机制来处理）
HD:呵呵，我的想法是有级别的，具体的数据结构需要在功能上确定后统一给出一个数据结构。我想基本的范式会是
服务类别（邮件存储）--->服务点（北京邮件存储）---->服务（192.168.2.1:2028） 由于是边写边想，这个名字存的有可能没有体现出这个层次来。
Dirk Ye: 我最近也在考虑这方面的需求，总体架构和你描述的差不多，但实际情况会存在这样一种应用需求：
各个节点提供的是相同的服务，但各个节点的内容是不相同的。可能和大容量邮箱系统有点类似！
HD:这方面的处理主要是如何将内容进行快速的分布到冗余服务器上去，有几种手段，一种是用盘柜或NFS这样的共享存储。另一种是使用mysql的主从方式，将交易的log发布到从服务器上，从服务器更新数据。
还有一种就是在通知服务时也通知另外的冗余服务器。我喜欢用第一种，因为一个好的盘柜就可以让系统在开发时不考虑过多的复杂程度就可以完成这样的事。当然还有一种做法就是使用一个很牛的数据库，所有的服务操作同一个数据库服务器就好。数据库服务器的同步和统一已经是很成熟的技术了。
Dirk Ye: 在实际应用中，可能会有数据量远远超出了单个系统所能承受的能力（不论是什么数据库或者文件系统，总有一个极限，或者有无法承受的高成本），在这种情况下，能不能做到将数据平均的分摊到数量巨大的节点服务器，各个服务器所拥有的数据是唯一的（每个唯一数据节点的再次冗余是下一级的问题了），能不能在OGNS中实现这种情况下的数据透明定位。
- eg: 一个系统中存在一亿的邮箱账号，邮箱数据存放在10000台个体服务器中，能否考虑一种机制，透明的实现用户对数据的定位和操作。
（据说盛大的游戏服务器达到了10000多台，当然他们的系统不太一样，但总有一天会有这种系统需求，而且我相信应该是不久的将来） 也许只是一点胡思乱想，但我觉得这样的时代即将到来！
HD: 在GNS中不会完成定位。这部分功能我想就需要结合USO（统一认证）了，在进行用户认证和其Profile的获取时，就可以得到自己的邮件存储在哪一个USS服务ID上了。而GNS的工作就只是简单的告诉系统这个USS服务ID有几个侦听端口可以使用。你觉得这样分配是否合适。还是哪个原则，我可以用GNS指出系统中有很多台USO来进行认证，而GNS可能只能有几台，这样的话，我还是要尽量让GNS减少数据存储量，做路过者。
对该用户的数据的具体操作则会转向它最终定位的侦听端口了。USO提供了它要去哪个服务找，GNS提供了这个服务是哪个侦听端口，数据则就由USS自己提供了。 PyUSS---OpenGNS、OpenUSS、OpenUSO相信会是达到一个新的服务境界的思想的开拓者。做为这个思想的提出者，我已经与几个商业公司谈了我的想法，他们中已经有人在考虑做为支持者来支持我们这个社区。但是我相信随着互联网的发展，随着泡沫的飞去，随着真实，这个时代已经由Google的到来揭开了序幕，我更希望在国人中，有一群人，像apache对Web、Java的贡献一样，做一些有意义和价值的事。
[email protected]: 别说1万，就是100台服务器里面，当其中30%的服务器发生故障，还要能保证能正常存储数据。那样才有存在的必要。否则raid5的磁盘柜更值得他们考虑了。
Dirk Ye: 我们不能一味考虑造价，我们完全可以将一个集群看作一个简单的节点（后面的集群如何实现、如何昂贵我们不考虑），对OGNS来说应该是透明的。
考虑到这个问题，我建议HD在考虑节点最终名称标识的时候不要使用IP地址，可以使用一种特别命名机制。 一点建议，还没有考虑清楚。 我觉得还是那个想法，OGNS只考虑连接上来的服务节点，至于这个节点如何实现的（后面可能是磁盘柜或者其他冗余措施）我们不需要考虑，我们只把它看作一个单一的节点。