JPH0581210A

JPH0581210A - Method for cooperation processing between cluster and multiprocessor

Info

Publication number: JPH0581210A
Application number: JP3241099A
Authority: JP
Inventors: Toyohiko Kagimasa; 豊彦鍵政; Toshiaki Mori; 利明森
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1991-09-20
Filing date: 1991-09-20
Publication date: 1993-04-02

Abstract

PURPOSE:To provide a cluster-multiprocessor cooperation processing method for attaining a rapid remote procedure call(RPC) and a distributed file system. CONSTITUTION:In the case of the RPC, an RPC request side cluster writes RPC request information and a parameter in a shared storage device 15 and an RPC receiving side cluster reads out the RPC request information at first, and after securing a resource necessary for RPC request processing, reads out the parameter to execute the RPC processing. In the case of the distributed file system, a remote file access receiving side cluster caches a part or all of files in the device 15. Since queuing for data transmission/reception, the copying of the RPC parameter in a main memory and excess inter-cluster communication can be removed in said constitution, RPC processing performance is improved. In addition, a distributed file accessing time can be shortened by reading out file data from the device 15.

Description

Detailed Description of the Invention

【０００１】[0001]

【産業上の利用分野】本発明は、複数プロセッサを有す
るデータ処理システムの協調処理方法に係わり、特に階
層記憶形式のクラスタ・マルチプロセッサ構成を採るデ
ータ処理システムにおいて、大容量データの高速処理に
好適なクラスタ・マルチプロセッサ協調処理方法に関す
る。BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a coordinated processing method for a data processing system having a plurality of processors, and is particularly suitable for high speed processing of a large amount of data in a data processing system having a clustered multiprocessor structure of hierarchical storage type. Cluster / multiprocessor cooperative processing method.

【０００２】[0002]

【従来の技術】複数プロセッサの協調処理方法である分
散ファイルシステムとリモート・プロシジャコール（Ｒ
ＰＣ）については、アディソン・ウェスレー社（Addiso
n-Wesley Publishing Company ）刊の「オペレーティン
グシステム・コンセプト第３版」（１９９１年）第４９
１頁から第５４１頁 (Operating System ConceptThirdE
dition (1991) pp491-541 ）に記載されている。この第
１の従来技術では、ワークステーションなどの複数のデ
ータ処理システムがローカル・エリア・ネットワーク
（ＬＡＮ）により接続される分散システム構成を前提と
している。ＬＡＮ内のデータ処理システム間で相手シス
テムのローカルなファイル記憶装置にあるファイルをト
ランスペアレントにリモートアクセスすることによりフ
ァイルを共有する分散ファイルシステムと、それを実現
するための下位レイヤの機能であるＲＰＣの方法が記載
されている。ＲＰＣとは、ＬＡＮ内のデータ処理システ
ム間で相手システムに対して手続きの呼び出しを要求
し、要求されたシステムは手続きを実行した後、その結
果を要求側システムに返送するという方法であり、通常
の手続き呼び出しを分散システムに拡張したものであ
る。また、ＲＰＣは、クライアント／サーバ・モデルの
プログラミングの基本機構を提供するものである。クラ
イアント・プログラムは、サーバ・プログラム中の手続
きをＲＰＣを用いて呼び出すことによりサーバ機能を要
求する。分散ファイルシステムにおいても、ファイルを
アクセスするクライアント・プログラムがファイルをア
クセスするシステム・コールを自システムのオペレーテ
ィングシステム（ＯＳ）に対して発行すると、ＯＳはア
クセス対象のファイルを管理する分散ファイル・サーバ
の手続きをＲＰＣを用いて呼び出すことによりファイル
をリモートアクセスして、結果をクライアント・プログ
ラムに返す。また、ＲＰＣの発行に際しては、サーバに
対する通信アドレスなどのインターフェース情報を得る
必要がある。この第１の従来技術では、インターフェー
ス情報を管理するデータ処理システムに対して、情報を
要求してその情報を受け取ってからＲＰＣを発行する方
法を述べている。したがって、ＲＰＣの発行前にさらに
もう１回、他のデータ処理システムとの通信が必要であ
る。ＲＰＣのプロトコルについては、プレンティス・ホ
ール社（Prentice-Hall, Inc. ）刊の「ネットワーク・
コンピューティング・アーキテクチャ」（１９９０年）
第４２頁から第７９頁 (Network Computing Architectu
re (1990) pp42-79 ）に記載されている。この第２の従
来技術においても、複数のデータ処理システムがＬＡＮ
などのネットワークで接続される構成を前提としてお
り、クライアントとサーバの間でパケットと呼ばれるデ
ータ単位を転送しあうことによりＲＰＣを実現する。ク
ライアントからの要求パケットに対して、サーバは応答
パケットにより結果を返し、クライアントは到着通知
（ＡＣＫ）パケットを返して応答の受け取りをサーバに
連絡する。一つの要求や応答のデータ量が大きく複数パ
ケットに渡る場合は、受信側は１パケットごとにＡＣＫ
パケットを返して受け取りを送信側に連絡する。送信側
は、ＡＣＫパケットが返るまで、次のパケットを送信せ
ず、また送信したパケットを再送の時のために保持して
いる。上記第１および第２の従来技術の分散ファイルシ
ステムとＲＰＣは、複数プロセッサの協調処理の方法と
して優れた機能とシステム拡張性を提供するが、ＬＡＮ
接続による複数プロセッサ構成を前提としているため、
後で詳しく述べる性能的な問題がある。2. Description of the Related Art A distributed file system and a remote procedure call (R
For PC, Addison-Wesley (Addiso
n-Wesley Publishing Company) "Operating System Concept Third Edition" (1991) 49th
Pages 1 to 541 (Operating System ConceptThirdE
dition (1991) pp491-541). This first conventional technique is premised on a distributed system configuration in which a plurality of data processing systems such as workstations are connected by a local area network (LAN). A distributed file system that shares files by transparently remote-accessing a file in a local file storage device of a partner system between data processing systems in a LAN, and a lower layer function of RPC that realizes the file system The method is described. RPC is a method in which a data processing system in a LAN requests a call to a procedure from a partner system, the requested system executes the procedure, and then returns the result to the requesting system. It is an extension of the procedure call in (1) to a distributed system. RPC also provides a basic mechanism for client / server model programming. The client program requests the server function by calling a procedure in the server program using the RPC. Even in the distributed file system, when a client program that accesses the file issues a system call that accesses the file to the operating system (OS) of the local system, the OS of the distributed file server that manages the file to be accessed. Remotely access the file by calling the procedure with RPC and return the result to the client program. Further, when issuing the RPC, it is necessary to obtain interface information such as a communication address for the server. The first conventional technique describes a method of requesting information from a data processing system that manages interface information, receiving the information, and then issuing an RPC. Therefore, it is necessary to communicate with another data processing system once more before issuing the RPC. The RPC protocol is described in “Network.” Published by Prentice-Hall, Inc.
Computing Architecture "(1990)
Pages 42 to 79 (Network Computing Architectu
re (1990) pp42-79). Also in this second conventional technique, a plurality of data processing systems are LANs.
RPC is realized by transferring data units called packets between a client and a server on the premise that they are connected by a network such as. In response to the request packet from the client, the server returns a result in a response packet, and the client returns an arrival notification (ACK) packet to notify the server of receipt of the response. When the data volume of one request or response is large and spans multiple packets, the receiving side sends an ACK for each packet.
Return the packet and contact the sender for receipt. The sending side does not send the next packet until the ACK packet is returned, and holds the sent packet for retransmission. The first and second prior art distributed file systems and RPCs provide excellent functions and system expandability as a method for cooperative processing of a plurality of processors.
Since it is assumed that multiple processors are connected,
There is a performance problem that will be detailed later.

【０００３】一方、大容量データの高速な協調処理を可
能にするために、基盤となる複数プロセッサの接続構成
として階層記憶形式のクラスタ・マルチプロセッサが知
られている。この構成は、半導体記憶装置をプロセッサ
間で共有するため、接続可能なプロセッサ数はＬＡＮ構
成より少ないが、ＬＡＮ構成より高速かつ大容量なデー
タ転送が可能である。特開昭６４−７８３６１号公報に
記載されているデータ処理システム（第３の従来技術）
は、この構成を採る。すなわち、各々のクラスタが主記
憶共有マルチプロセッサであり、複数クラスタがランダ
ムアクセス可能な記憶装置を共有する構成である。共有
記憶装置へのアクセスは、入出力プロセッサ・コマンド
ではなくＣＰＵ命令で直接にアクセスするハードウェア
を開示している。複数のクラスタのそれぞれにＯＳが動
作する。さらに、共有記憶装置の用途として、ディスク
装置などのクラスタ間で共有される入出力装置に格納さ
れているファイルの排他制御情報を共有記憶装置に保持
する例と、ファイルそのものを共有記憶装置に格納して
共有する例を述べている。また、特開平２−３１０６６
４号公報（第４の従来技術）では、第３の従来技術と同
様の階層記憶形式のクラスタ・マルチプロセッサ構成を
前提とし、異なるクラスタで動作する特定プログラム間
で共有記憶装置を経由して高速のデータ転送を行なう方
法と装置について述べている。これらの従来技術では、
協調処理方法の基盤となる複数プロセッサの接続構成と
クラスタ間のデータ転送方式が述べられているが、ＲＰ
Ｃや分散ファイルシステムといった協調処理のレベルの
方法については述べられていない。On the other hand, in order to enable high-speed cooperative processing of a large amount of data, a hierarchical multi-type cluster multiprocessor is known as a connection configuration of a plurality of underlying processors. In this configuration, since the semiconductor memory device is shared by the processors, the number of connectable processors is smaller than that of the LAN configuration, but data transfer of higher speed and larger capacity than that of the LAN configuration is possible. Data processing system described in Japanese Patent Laid-Open No. 64-78361 (third prior art)
Adopts this configuration. That is, each cluster is a main memory shared multiprocessor, and a plurality of clusters share a randomly accessible storage device. Access to shared storage discloses hardware that is accessed directly with CPU instructions rather than I / O processor commands. The OS operates in each of the plurality of clusters. Further, as an application of the shared storage device, an example of holding exclusive control information of a file stored in an input / output device shared between clusters such as a disk device in the shared storage device, and a file itself stored in the shared storage device And then share an example. In addition, JP-A-2-31066
Japanese Patent Laid-Open No. 4 (fourth prior art) presupposes a cluster multiprocessor configuration of a hierarchical storage format similar to that of the third prior art, and high speed via a shared storage device between specific programs operating in different clusters. And a method and apparatus for performing the data transfer of. In these conventional techniques,
The connection configuration of multiple processors and the data transfer method between clusters, which are the basis of the cooperative processing method, are described.
There is no mention of collaborative processing level methods such as C or distributed file systems.

【０００４】また、階層記憶形式のクラスタ・マルチプ
ロセッサ構成において、協調処理方法ではないが、ひと
つの科学技術計算プログラムをクラスタ間で並列処理す
る方法については、情報処理学会第４１回全国大会予稿
集（１９９０年）の「階層記憶型並列処理の制御ソフト
ウェア」第６−１０９〜６−１１０頁に記載されてい
る。この第５の従来技術では、共有記憶装置にプロセス
のディスパッチング・キューを設け、プロセスを生成す
るクラスタは、生成するプロセスためのプロセス制御ブ
ロックを上記ディスパッチング・キューにキューイング
し、プロセスを実行するクラスタは、ディスパッチング
・キューからプロセス制御ブロックを取り出してプロセ
スを実行する。これは、親クラスタのプログラムがプロ
セスの実行を他クラスタにディスパッチする方法であ
り、ＲＰＣや分散ファイルシステムのように、複数のク
ラスタで実行されるプログラム間で協調処理を行なう方
法ではない。Further, in the hierarchical storage type cluster / multiprocessor configuration, a parallel processing method, which is not a cooperative processing method, is described in the 41st National Convention Proceedings of the Information Processing Society (1990) "Control software for hierarchical memory parallel processing", pages 6-109 to 6-110. In the fifth conventional technique, a process dispatching queue is provided in a shared storage device, and a cluster that creates a process queues a process control block for the creating process in the dispatching queue and executes the process. The cluster that does this retrieves the process control block from the dispatching queue and executes the process. This is a method in which a program in a parent cluster dispatches the execution of a process to another cluster, and is not a method in which programs executed in a plurality of clusters perform cooperative processing unlike RPC and a distributed file system.

【０００５】[0005]

【発明が解決しようとする課題】第１および第２の従来
技術のＲＰＣは、複数のデータ処理システムがＬＡＮに
より接続される構成を前提としており、かつ大容量デー
タがパラメタとして転送されることを考慮していないた
め、ＲＰＣのデータは通常１キロバイト程度の小さなパ
ケットに分けて何度も転送される。また、ＬＡＮにおい
てはデータが途中で消失したり、データの受信側の受信
処理が追いつかないという状況が起こる可能性があるの
で、ＲＰＣのプロトコルでは、ひとつのＲＰＣ要求およ
び応答が複数のパケットに分割されて送信される場合
は、受信側はパケットごとに受け取ったことを示すＡＣ
Ｋパケットを送信側に送り、送信側はＡＣＫパケットを
受け取ってから次のパケットを送信する。したがって、
データ転送の処理時間は処理するパケット数に比例して
大きくなり、さらに、ＡＣＫパケットの待ち時間のため
に、ＲＰＣならびにその上に実現された分散ファイルシ
ステムのリモートアクセスの処理時間が長くなり、性能
が低下するという第１の問題点があった。そして、ＲＰ
Ｃの要求ならびに応答の送信および受信側は、ＬＡＮは
データの蓄積ができないという性質から受信側はとにか
く送られてくるデータを主記憶装置のパケット・バッフ
ァに一旦ためこむため、主記憶装置のパケット・バッフ
ァ領域とパラメタ領域間のデータ・コピーを少なくとも
１回は行なうので、パラメタのデータ量が大きい場合
は、そのためのＣＰＵオーバヘッドが大きいという第２
の問題点があった。さらに、ＲＰＣ受理側クラスタは、
ＲＰＣを処理するためのタスクや主記憶装置領域などの
資源を確保して当該ＲＰＣ要求を処理可能になるまで、
受信したＲＰＣ要求に必要な情報を主記憶装置のバッフ
ァに格納して待つので、パラメタのデータ量が大きい場
合は、主記憶装置資源が専有され、効率的利用が図れな
いという第３の問題点があった。The RPCs of the first and second prior arts are premised on a configuration in which a plurality of data processing systems are connected by a LAN, and large amount of data is transferred as a parameter. Since this is not taken into consideration, the RPC data is usually transferred in small packets of about 1 kilobyte many times. Also, in a LAN, there is a possibility that data will be lost in the middle or the receiving process of the data receiving side will not be able to catch up, so in the RPC protocol, one RPC request and response is divided into multiple packets. If received and sent, the receiving side will show AC for each packet
It sends a K packet to the sender and the sender receives the ACK packet before sending the next packet. Therefore,
The processing time of data transfer increases in proportion to the number of packets to be processed, and further, due to the waiting time of the ACK packet, the processing time of remote access of RPC and the distributed file system realized on it becomes long, and the performance is increased. There was a first problem that the value decreases. And RP
The sending and receiving sides of the request and response of C have the property that the LAN cannot store data, and the receiving side temporarily stores the sent data in the packet buffer of the main storage device. Since the data copy between the buffer area and the parameter area is performed at least once, when the data amount of the parameter is large, the CPU overhead for that is large.
There was a problem. Furthermore, the RPC receiving cluster is
Until the RPC request can be processed by securing resources such as a task for processing the RPC and the main storage area,
Since the information necessary for the received RPC request is stored in the buffer of the main storage device and waits, the main storage device resource is occupied and efficient use cannot be achieved when the data amount of the parameter is large. was there.

【０００６】また、第１および第２の従来技術のＲＰＣ
は、サーバおよびサーバ手続きに関するインターフェー
ス情報を管理するデータ処理システムをあらかじめ定め
ておいて、ＲＰＣを発行するクライアントは上記データ
処理システムと通信して情報を得て、さらにＲＰＣを発
行するためにＲＰＣを受理するデータ処理システムと通
信するという２重の通信が必要になり、ＲＰＣの処理時
間が長くなり、性能が低下するという第４の問題点があ
った。Also, the first and second prior art RPCs
Defines a data processing system for managing interface information related to a server and a server procedure in advance, and a client that issues an RPC communicates with the data processing system to obtain information, and further issues an RPC to issue an RPC. There is a fourth problem that double communication is required to communicate with the accepted data processing system, the processing time of RPC becomes long, and the performance deteriorates.

【０００７】また、第１の従来技術の分散ファイルシス
テムは、複数のデータ処理システムがＬＡＮにより接続
される構成を前提としているため、他のデータ処理シス
テムにあるファイルをアクセスする場合は、そのデータ
処理システムの分散ファイル・サーバに対してＲＰＣを
発行して、ファイル記憶装置から主記憶装置を経由し
て、または主記憶装置のファイル・キャッシュからファ
イル・データを転送してもらう必要があった。そのため
に、アクセス時間が長くなるという第５の問題点があっ
た。Further, the distributed file system of the first prior art is premised on the configuration in which a plurality of data processing systems are connected by a LAN, and therefore, when a file in another data processing system is accessed, the data of that data processing system is accessed. It was necessary to issue an RPC to the distributed file server of the processing system to transfer the file data from the file storage device via the main storage device or from the file cache of the main storage device. Therefore, there is a fifth problem that the access time becomes long.

【０００８】本発明の目的は、階層記憶形式のクラスタ
・マルチプロセッサ構成を採るデータ処理システムにお
いて、高速のＲＰＣならびに分散ファイルシステムを実
現するクラスタ・マルチプロセッサの協調処理方法を提
供することにある。An object of the present invention is to provide a cluster / multiprocessor cooperative processing method for realizing a high-speed RPC and a distributed file system in a data processing system adopting a hierarchical storage type cluster / multiprocessor configuration.

【０００９】[0009]

【課題を解決するための手段】上記目的は、ＲＰＣに対
しては、ＲＰＣ要求側の第１のクラスタにおいては、Ｒ
ＰＣ受理側の第２のクラスタの処理状態に関係なく、コ
ール対象の手続きの識別子を含むコール要求情報と手続
きのパラメタを共有記憶装置に全て書き込み、ＲＰＣ受
理側の第２のクラスタにおいては、共有記憶装置から上
記コール要求情報を読み出してコール対象の手続きを特
定し、タスクおよび主記憶装置のパラメタ領域を含む手
続きの実行に必要な資源を確保してから、共有記憶装置
に書き込まれた上記パラメタを上記主記憶装置のパラメ
タ領域に読み込んでコール対象の手続きを実行すること
により達成される。SUMMARY OF THE INVENTION The above-mentioned object is to RPC, in the first cluster on the RPC requesting side, R
Regardless of the processing state of the second cluster on the PC accepting side, all the call request information including the identifier of the procedure to be called and the procedure parameters are written in the shared storage device, and shared by the second cluster on the RPC accepting side. The above parameters written to the shared storage device after the call request information is read from the storage device, the procedure to be called is specified, and the resources necessary for executing the procedure including the task and the parameter area of the main storage device are secured. Is read into the parameter area of the main memory and the procedure to be called is executed.

【００１０】さらにＲＰＣに対して、ＲＰＣ受理側の第
２のクラスタにおいては、リモート・プロシジャコール
の対象となる手続きのインターフェース情報を共有記憶
装置のテーブルに保持し、ＲＰＣ要求側の第１のクラス
タにおいては、ＲＰＣの発行時は上記テーブル情報を参
照して手続きのインターフェース情報を得ることにより
達成される。Further, with respect to the RPC, the second cluster on the RPC receiving side holds the interface information of the procedure to be the target of the remote procedure call in the table of the shared storage device, and the first cluster on the RPC requesting side. In (1), the RPC is issued by obtaining the interface information of the procedure by referring to the above table information.

【００１１】また、分散ファイルシステムに対しては、
アクセス対象のファイルを有するリモート・ファイルア
クセス受理側のクラスタにおいては、上記ファイルの一
部または全部を上記共有記憶装置にキャッシングするこ
とにより達成される。For the distributed file system,
In the cluster on the remote file access accepting side having the file to be accessed, this is achieved by caching part or all of the file in the shared storage device.

【００１２】[0012]

【作用】ＲＰＣに対しては、ＲＰＣ要求側の第１のクラ
スタにおいては、ＲＰＣ受理側の第２のクラスタの処理
状態に関係なく、コール要求情報とパラメタを共有記憶
装置に全て書き込むので、要求情報とパラメタを複数の
パケットに分けて処理することがなく、送信および受信
処理をまとめて行なうことができ、処理時間が短縮され
る。また、ＲＰＣ受理側の第２のクラスタにおいては、
共有記憶装置からまず上記コール要求情報を読み出して
コール対象の手続きを特定し、サーバのＲＰＣ処理タス
クと主記憶装置のパラメタ領域を確保して、コール対象
の手続きの実行が可能な状態になってから、共有記憶装
置に書き込まれた上記パラメタを主記憶装置のパラメタ
領域に読み込んでＲＰＣ処理タスクが手続きを実行する
ため、主記憶装置のバッファにパラメタを一旦読み込む
必要がないので、パラメタのデータ・コピーのためのＣ
ＰＵオーバヘッドはなくなる。また、パラメタのために
主記憶装置のバッファは不要となるので、主記憶装置資
源の効率的利用が図れる。With respect to the RPC, in the first cluster on the RPC request side, all the call request information and parameters are written to the shared storage device regardless of the processing state of the second cluster on the RPC accepting side. It is possible to perform transmission and reception processing collectively without dividing information and parameters into a plurality of packets for processing, and shorten processing time. In the second cluster on the RPC receiving side,
First, the call request information is read from the shared storage device to identify the call target procedure, the RPC processing task of the server and the parameter area of the main storage device are secured, and the call target procedure is ready to be executed. From the above, since the RPC processing task executes the procedure by reading the above parameters written in the shared storage device into the parameter area of the main storage device, it is not necessary to read the parameters into the buffer of the main storage device once. C for copy
There is no PU overhead. Further, since the buffer of the main storage device is unnecessary for the parameters, the main storage device resources can be efficiently used.

【００１３】さらにＲＰＣに対して、ＲＰＣ要求側の第
１のクラスタにおいては、ＲＰＣの発行時は共有記憶装
置から読み込むことによりインターフェース情報を得る
ことができるので、インターフェース情報のために他の
クラスタと通信することがなく、処理時間が短縮され
る。Further, with respect to the RPC, the first cluster on the RPC request side can obtain the interface information by reading it from the shared storage device at the time of issuing the RPC. Since there is no communication, the processing time is shortened.

【００１４】また、分散ファイルシステムに対しては、
アクセス対象のファイルを有するリモート・ファイルア
クセス受理側のクラスタにおいては、上記ファイルの一
部または全部を上記共有記憶装置にキャッシングするの
で、キャッシュがヒットすればアクセス要求側のクラス
タは、共有記憶装置から読み出すだけでファイル・デー
タにアクセスできるので、アクセス時間が短縮される。For the distributed file system,
In the remote file access accepting cluster having the file to be accessed, some or all of the above files are cached in the shared storage device. Therefore, if the cache hits, the access requesting cluster is transferred from the shared storage device. Since the file data can be accessed only by reading it, the access time is shortened.

【００１５】[0015]

【実施例】以下、本発明の一実施例を説明する。本実施
例は、階層記憶形式のクラスタ・マルチプロセッサ構成
を採るデータ処理システムにおいて、分散ファイルシス
テム（ＤＦＳ）とリモート・プロシジャコール（ＲＰ
Ｃ）を実現する例である。ＤＦＳは、ＲＰＣをクラスタ
間の通信プロトコルの下位レイヤとして用いて実現す
る。本実施例で述べるＲＰＣは、クライアント／サーバ
・モデルの一般的な機構を提供するので、ＤＦＳ以外の
用途にも使用することができる。なお、本実施例では２
クラスタの構成となっているが、本発明はもちろん３ク
ラスタ以上の構成でも適用可能であり、有効である。EXAMPLE An example of the present invention will be described below. In this embodiment, a distributed file system (DFS) and a remote procedure call (RP) are used in a data processing system adopting a hierarchical multi-processor cluster multiprocessor configuration.
This is an example of realizing C). DFS is realized by using RPC as a lower layer of a communication protocol between clusters. The RPC described in this example provides a general mechanism for the client / server model and can be used for applications other than DFS. In this embodiment, 2
Although it has a cluster configuration, the present invention is of course applicable and effective even in a configuration of three or more clusters.

【００１６】図１は、本実施例の階層記憶形式のクラス
タ・マルチプロセッサ構成を採るデータ処理システムの
構成図である。本実施例のハードウェア構成をまず説明
する。各々のクラスタ１，２が複数の命令プロセッサ
３，４，５，６と主記憶装置７，８を持つものである複
数のクラスタが、ランダムアクセス可能な共有拡張記憶
装置１５により接続される。さらに、各クラスタ１，２
は、それぞれのクラスタのみがアクセス可能なローカル
拡張記憶装置９，１０を有する。ローカル拡張記憶装置
（ローカルＥＳ）９，１０と共有拡張記憶装置（共有Ｅ
Ｓ）１５は、ともに半導体記憶装置であり、プログラム
とのインタフェースも同一である。拡張記憶装置（Ｅ
Ｓ）へのアクセスは、主記憶装置（ＭＳ）７，８と同様
に、命令プロセッサ（ＩＰ）３，４，５，６の命令すな
わちＣＰＵ命令により行なわれる。本実施例の共有ＥＳ
１５は、特開昭６４−７８３６１号公報（第３の従来技
術）および特開平２−３１０６６４号公報（第４の従来
技術）で開示されているものと同様である。共有ＥＳ１
５とローカルＥＳ９，１０は、命令プロセッサからの以
下のハードウェア命令を処理する。リードＥＳ（ＲＥＡ
ＤＥＳ）命令は、ＥＳの指定したアドレスから指定した
データ長のデータを読み込み、主記憶装置の指定したア
ドレスに格納する。ライトＥＳ（ＷＲＩＴＥＥＳ）命令
は、主記憶装置の指定したアドレスから指定したデータ
長のデータを、ＥＳの指定したアドレスに格納する。コ
ンペアスワップＥＳ（ＣＳＥＳ）命令は、主記憶装置の
指定したアドレスから指定したデータ長のデータをＥＳ
の指定したアドレスのデータを比較して、等しければ比
較した主記憶装置のデータをＥＳの指定したアドレスに
転送し、等しくなければ比較したＥＳのデータを主記憶
装置の指定したアドレスに転送する。ＣＳＥＳ命令の実
行中は、他のＥＳアクセスの実行が待たされるため、Ｃ
ＳＥＳ命令をクラスタ間の処理の排他制御方法であるロ
ック／アンロックのための命令として本実施例では使用
する。逐次化が必要な処理の先頭で、ＣＳＥＳ命令を使
用してＥＳの変数の値が使用中か否かをチェックすると
ともに、使用中でなければＥＳの変数を使用中の値に変
更する。逐次化が必要な処理の最後で、ＣＳＥＳ命令を
使用してＥＳの変数を使用可の値に変更する。さらに共
有ＥＳ１５は、通信ＩＤ送信（ＳＩＧＰＧ）命令と通信
ＩＤ受信（ＳＥＮＳＰ）命令を処理する。共有ＥＳ１５
は、通信の宛先クラスタおよびプログラムを示す通信Ｉ
Ｄを格納する通信ＩＤレジスタ１６を有する。具体的に
は、通信ＩＤレジスタ１６は、宛先クラスタと宛先プロ
グラムの組合せの数だけのビットを有する。ＳＩＧＰＧ
命令は、宛先クラスタとプログラムを指定した通信ＩＤ
をオペランドとして発行されると、通信ＩＤレジスタ１
６の対応ビットをオンにし、宛先クラスタに割り込みを
発生させる。ＳＥＮＳＰ命令は、命令発行クラスタの通
信ＩＤを通信ＩＤレジスタ１６から主記憶装置７，８に
読み込む。また、本実施例のデータ処理システムは、そ
れぞれのクラスタ１，２が入出力プロセッサ（ＩＯＰ）
１１，１２を介してディスク装置１３，１４が接続され
る。ディスク装置１３，１４は、それぞれひとつのクラ
スタのみに接続され、クラスタ間の共有はなされていな
い。FIG. 1 is a block diagram of a data processing system which adopts a hierarchical storage type cluster multiprocessor configuration of the present embodiment. The hardware configuration of this embodiment will be described first. A plurality of clusters, each of which has a plurality of instruction processors 3, 4, 5, 6 and a main storage device 7, 8 are connected by a randomly accessible shared extended storage device 15. Furthermore, each cluster 1, 2
Has local extended storage devices 9 and 10 accessible only to the respective clusters. The local extended storage device (local ES) 9 and 10 and the shared extended storage device (shared E
S) 15 are both semiconductor memory devices and have the same interface with the program. Extended storage device (E
The access to S) is performed by the instruction of the instruction processor (IP) 3, 4, 5, 6 or the CPU instruction similarly to the main memory (MS) 7, 8. Shared ES of this embodiment
No. 15 is the same as that disclosed in JP-A-64-78361 (third prior art) and JP-A-2-310664 (fourth prior art). Shared ES1
5 and the local ESs 9 and 10 process the following hardware instructions from the instruction processor. Lead ES (REA
The DES) instruction reads data of a specified data length from the address specified by ES and stores it in the specified address of the main storage device. The write ES (WRITE ES) instruction stores the data of the specified data length from the specified address of the main storage device at the address specified by the ES. The compare swap ES (CSES) instruction is used to ES the data of the specified data length from the specified address of the main storage device.
The data of the designated address are compared, and if they are equal, the compared data of the main storage device is transferred to the designated address of the ES, and if they are not equal, the data of the compared ES is transferred to the designated address of the main storage device. During execution of the CSES instruction, execution of other ES access is delayed, so C
The SES instruction is used in this embodiment as an instruction for locking / unlocking, which is an exclusive control method for processing between clusters. At the beginning of the process requiring serialization, the CSES instruction is used to check whether the value of the ES variable is in use, and if not, change the ES variable to the in-use value. At the end of the process that requires serialization, the CSES instruction is used to change the ES variable to a usable value. Further, the shared ES 15 processes a communication ID transmission (SIGPG) command and a communication ID reception (SENSP) command. Shared ES15
Is a communication I indicating the destination cluster and program of the communication
It has a communication ID register 16 for storing D. Specifically, the communication ID register 16 has as many bits as there are combinations of destination clusters and destination programs. SIGPG
The command is a communication ID that specifies the destination cluster and program.
Is issued as an operand, communication ID register 1
Turn on the corresponding bit of 6 to generate an interrupt on the destination cluster. The SENSP instruction reads the communication ID of the instruction issuing cluster from the communication ID register 16 into the main storage devices 7 and 8. In the data processing system of this embodiment, each of the clusters 1 and 2 has an input / output processor (IOP).
The disk devices 13 and 14 are connected via 11 and 12. The disk devices 13 and 14 are connected to only one cluster, respectively, and are not shared between the clusters.

【００１７】次に、図２を用いて本実施例のソフトウェ
アの構成を説明する。各クラスタ１，２にはオペレーテ
ィングシステム（ＯＳ）が動作し、ＯＳはファイルへの
Ｉ／Ｏを処理するファイルＩ／Ｏプログラム２５，２
６、ＲＰＣを処理するＲＰＣプログラム２３，２４、そ
の他のＯＳ機能を処理するＯＳ核プログラム２１，２２
を含む。クラスタＢ２では、ＤＦＳのリモート・ファイ
ルアクセスを処理するためのサーバであるＤＦＳサーバ
・プログラム２８が動作し、クラスタＡ１では、ファイ
ルＩ／Ｏを発行するユーザプログラム２７が動作する。
ファイルＩ／Ｏプログラム２５，２６とＤＦＳサーバ・
プログラム２８が、ＲＰＣを用いてＤＦＳを実現し、Ｒ
ＰＣプログラム２３，２４は共有ＥＳ１５を用いてＲＰ
Ｃを実現する。このソフトウェア構成では、クラスタＡ
１のユーザプログラム２７がクラスタＢ２のファイル４
２にリモート・ファイルアクセスを行なう構成となって
いる。したがって、ユーザプログラム２７のファイルア
クセス要求を受付けるファイルＩ／Ｏプログラム２５が
クライアントプログラムとなって、ＤＦＳサーバプログ
ラム２８に対してＲＰＣを発行してファイルアクセスを
処理する。クラスタＢ２のファイルＩ／Ｏプログラム２
６は、ＤＦＳサーバプログラム２８からコールされ、フ
ァイル４２への実際のＩ／Ｏを実行する。ＤＦＳサーバ
プログラム２８は、メインルーチン２９、ファイルから
データを入力（ｇｅｔ）するためのサーバ手続きである
ＧＥＴルーチン３７、ファイルへデータを出力（ｐｕ
ｔ）するためのサーバ手続きであるＰＵＴルーチン３８
を有する。ＲＰＣプログラム２３，２４は、ＲＰＣ登録
ルーチン３１、ＲＰＣ登録抹消ルーチン３２、ＲＰＣ送
信ルーチン３３、ＲＰＣ受信ルーチン３４、基礎的なデ
ータ転送を制御するＲＰＣ通信ルーチン３５，３６を有
する。Next, the software configuration of this embodiment will be described with reference to FIG. An operating system (OS) runs on each of the clusters 1 and 2, and the OS handles file I / O programs 25 and 2 for processing I / O to files.
6. RPC programs 23 and 24 for processing RPC, OS core programs 21 and 22 for processing other OS functions
including. A DFS server program 28, which is a server for processing DFS remote file access, operates in the cluster B2, and a user program 27 that issues a file I / O operates in the cluster A1.
File I / O programs 25, 26 and DFS server
The program 28 implements DFS using RPC,
The PC programs 23 and 24 use the shared ES 15 to RP
Realize C. In this software configuration, cluster A
User program 27 of 1 is file 4 of cluster B2
2 is configured to perform remote file access. Therefore, the file I / O program 25 that receives the file access request of the user program 27 becomes the client program and issues the RPC to the DFS server program 28 to process the file access. File I / O program 2 of cluster B2
6 is called from the DFS server program 28 to perform the actual I / O to the file 42. The DFS server program 28 has a main routine 29, a GET routine 37 that is a server procedure for inputting data from a file, and outputs data to a file (pu).
PUT routine 38, which is a server procedure for
Have. The RPC programs 23 and 24 have an RPC registration routine 31, an RPC deregistration routine 32, an RPC transmission routine 33, an RPC reception routine 34, and RPC communication routines 35 and 36 that control basic data transfer.

【００１８】本実施例のデータ構造は、図１に示されて
いる。ファイル４１，４２は、ディスク装置１３，１４
に格納されている。ＤＦＳサーバプログラム２５は、ア
クセス頻度の高いファイルの全体を共有ＥＳ１５のファ
イルキャッシュに置き、さらにアクセス頻度の高いファ
イル中のブロックは、主記憶装置８およびローカルＥＳ
１０のファィルキャッシュ４５，４４にアクセスの高速
化のために置く。ファイルのブロックというのは、ファ
イルのデータを分割する固定長の単位であり、ファイル
Ｉ／Ｏプログラム２５はブロック単位でまとめてディス
ク装置１４と主記憶装置８間のデータ転送、すなわちＩ
／Ｏを行なう。したがって、ファイルのキャッシングも
このように、ブロック単位で行なうのが通常である。ユ
ーザプログラム２７からのｇｅｔあるいはｐｕｔする対
象のデータは、通常ブロックの一部にあたる。ファイル
キャッシュ４３は、キャッシュに格納しているファイル
の管理情報を保持するディレクトリ５０を持つ。図６は
ディレクトリ５０の構造図である。ディレクトリ５０
は、６４バイトのディレクトリエントリ１５１が並ぶ構
造であり、ひとつのエントリがひとつのファイルの次の
情報を保持する。エントリをロックするためのロックワ
ード、ファイルを識別するためのＩＤ、ファイルのデー
タ長、キャッシュ内のアドレスなどである。主記憶装置
７のユーザＩ／Ｏバッファ４６はユーザプログラム２７
がファイルアクセスに使用する領域であり、ｇｅｔのシ
ステムコールの場合は、このバッファ４６をシステムコ
ールの出力パラメタ領域として指定し、ｇｅｔしたデー
タを受ける。ｐｕｔのシステムコールの場合は、このバ
ッファ４６にｐｕｔすべきデータを設定し、システムコ
ールの入力パラメタ領域として指定してシステムコール
を発行する。主記憶装置８のＧＥＴデータ領域４７は、
ＤＦＳサーバプログラム２８のＧＥＴルーチン３７のｇ
ｅｔしたデータを格納する出力パラメタ領域であり、Ｇ
ＥＴルーチン３７を実行しているタスクごとに主記憶装
置８に確保される。同様に、ＰＵＴデータ領域４８は、
ＰＵＴルーチン３８がｐｕｔすべきデータを格納する入
力パラメタ領域であり、ＰＵＴルーチン３８を実行して
いるタスクごとに主記憶装置８に確保される。共有ＥＳ
１５のファイルカタログ４９は、システム内のファイル
の位置情報を保持し、ファイルＩ／Ｏプログラム２５，
２６が使用する。共有ＥＳ１５には、ＲＰＣプログラム
２３，２４が使用するＲＰＣ管理テーブル５１、ＲＰＣ
通信領域５２、ＲＰＣポート領域５３、ＲＰＣパラメタ
領域５４、直接パラメタ領域５５がある。図３は、共有
ＥＳ１５の上記領域５２，５３，５４，５５の構造図で
ある。ＲＰＣ通信領域５２は、ＲＰＣプログラム２３，
２４間でＳＩＧＰＧ命令発行時の制御情報の授受のため
に使用される。クラスタごとに領域が設けられ、それぞ
れの領域には通信種別１１６、ＲＰＣポート領域５３の
ＥＳアドレス１１７の情報が書き込まれる。ＲＰＣポー
ト領域５３は、サーバ・プログラムごとにＲＰＣプログ
ラム２３，２４により作成され、クライアント・プログ
ラムとサーバ・プログラム間の要求および応答情報の授
受のために使用される。領域５３は、要求と応答の２つ
のポートから成り、それぞれのポートは複数のパケット
１１２，１１４のキューの構造を持つ。ひとつのパケッ
トにひとつの要求または応答の情報が格納される。した
がって、ひとつのサーバに対して複数の要求および応答
をキューイング可能である。各パケット１１２，１１４
は、パケット内に格納できない大きさのパラメタ・デー
タをＲＰＣパラメタ領域５４に格納して、パケットから
そのパラメタ１１５をポイントすることができる。ＲＰ
Ｃパラメタ領域５４は、１パケットごとにひとつの領域
として確保される。直接パラメタ領域５５は、ＲＰＣパ
ラメタ領域５４と同様にパケット外のパラメタ領域であ
り、ＲＰＣブログラム２３，２４が確保するものではな
く、クライアントまたはサーバ・プログラムのデータ領
域をそのままＲＰＣのパラメタ領域とするものである。
図４は、ポートヘッダとパケットの構造図である。ポー
トヘッダ１１１，１１３は、ポートの状態を示す次の情
報を持つ。ポートをロックするためにＣＳＥＳ命令が使
用するロックワード、キューイングされているパケット
のカウント、先頭および最後尾のパケットへのポインタ
などである。パケット１１２，１１４は、１キロバイト
の大きさであり、ひとつの要求または応答のための次の
情報を持つ。パケットヘッダ１３１には要求、サーバ、
サーバ手続き、クライアントを識別するためのＩＤ、要
求か応答かを示すパケットタイプ、パケットが未処理か
処理中か空きかを示す処理状態、パラメタ数などであ
る。パラメタリスト１３２は８バイトごとのパラメタリ
スト・エントリが並んでおり、各エントリはパラメタの
型（整数，文字など）と格納場所（エントリ内，パケッ
ト内，パケット外）を示すタグを含む。パラメタの長さ
が７バイト以下ならばエントリ内に、８９６バイト以下
でパケット内に空き領域があればパケット内の間接パラ
メタ領域１３５に、それ以外はパケット外のＲＰＣパラ
メタ領域１１５に格納される。要求パケットのパラメタ
は、コールされるサーバ手続きの入力パラメタであり、
応答パケットのパラメタは、コールされるサーバ手続き
の出力パラメタである。図５は、ＲＰＣ管理テーブル５
１の構造図である。ＲＰＣ管理テーブル５１は、１２８
バイトのサーバ手続きエントリ１４１が並ぶ構造であ
り、ひとつのエントリがひとつのサーバ手続きの次の情
報を保持する。エントリをロックするためのロックワー
ド、サーバ、サーバ手続き、ポートを識別するためのＩ
Ｄ、ポートのＥＳアドレス、サーバ手続きの主記憶アド
レス、パラメタ数、パラメタごとの属性（型など）など
である。ＲＰＣ管理テーブル５１は、ＲＰＣプログラム
２３，２４がサーバ手続きの情報を記録しておき、必要
に応じて参照するテーブルである。The data structure of this embodiment is shown in FIG. The files 41, 42 are stored in the disk devices 13, 14
It is stored in. The DFS server program 25 places all frequently accessed files in the file cache of the shared ES 15, and blocks in frequently accessed files are stored in the main storage device 8 and the local ES.
10 file caches 45 and 44 are placed for speeding up access. A file block is a fixed-length unit that divides file data, and the file I / O program 25 collectively transfers data between the disk device 14 and the main storage device 8, that is, I
/ O. Therefore, it is usual to perform file caching in block units as described above. The data to be get or put from the user program 27 corresponds to a part of a normal block. The file cache 43 has a directory 50 holding the management information of the files stored in the cache. FIG. 6 is a structural diagram of the directory 50. Directory 50
Has a structure in which 64-byte directory entries 151 are arranged, and one entry holds the next information of one file. A lock word for locking the entry, an ID for identifying the file, a data length of the file, an address in the cache, and the like. The user I / O buffer 46 of the main memory 7 is the user program 27.
Is an area used for file access, and in the case of a get system call, this buffer 46 is designated as an output parameter area of the system call to receive the get data. In the case of a put system call, data to be put is set in the buffer 46, and the system call is issued by designating it as an input parameter area of the system call. The GET data area 47 of the main memory 8 is
G of the GET routine 37 of the DFS server program 28
This is an output parameter area that stores the data that has been set.
Reserved in the main memory 8 for each task executing the ET routine 37. Similarly, the PUT data area 48 is
The PUT routine 38 is an input parameter area for storing data to be put, and is secured in the main memory 8 for each task executing the PUT routine 38. Shared ES
The file catalog 49 of 15 holds the position information of files in the system, and the file I / O program 25,
26 used. The shared ES 15 includes the RPC management table 51 and RPC used by the RPC programs 23 and 24.
There are a communication area 52, an RPC port area 53, an RPC parameter area 54, and a direct parameter area 55. FIG. 3 is a structural diagram of the areas 52, 53, 54, 55 of the shared ES 15. The RPC communication area 52 includes the RPC program 23,
It is used for exchanging control information between 24 when the SIGPG command is issued. An area is provided for each cluster, and information of the communication type 116 and the ES address 117 of the RPC port area 53 is written in each area. The RPC port area 53 is created by the RPC programs 23 and 24 for each server program, and is used for exchanging request and response information between the client program and the server program. The area 53 is composed of two ports, a request and a response, and each port has a structure of a queue of a plurality of packets 112 and 114. One request or response information is stored in one packet. Therefore, it is possible to queue multiple requests and responses for one server. Each packet 112, 114
Can store parameter data of a size that cannot be stored in the packet in the RPC parameter area 54 and point the parameter 115 from the packet. RP
The C parameter area 54 is secured as one area for each packet. The direct parameter area 55 is a parameter area outside the packet like the RPC parameter area 54 and is not secured by the RPC programs 23 and 24, and the data area of the client or server program is used as it is as the RPC parameter area. It is a thing.
FIG. 4 is a structural diagram of a port header and a packet. The port headers 111 and 113 have the following information indicating the port status. The lock word used by the CSES instruction to lock the port, the count of packets queued, pointers to the first and last packets, etc. The packets 112 and 114 are 1 kilobyte in size, and have the following information for one request or response. The packet header 131 includes a request, a server,
A server procedure, an ID for identifying a client, a packet type indicating whether it is a request or a response, a processing state indicating whether a packet is unprocessed, in process, or empty, and the number of parameters. In the parameter list 132, parameter list entries are arranged every 8 bytes, and each entry includes a tag indicating a parameter type (integer, character, etc.) and a storage location (in entry, inside packet, outside packet). If the parameter length is 7 bytes or less, it is stored in the entry, if it is 896 bytes or less and there is a free area in the packet, it is stored in the indirect parameter area 135 in the packet, and otherwise it is stored in the RPC parameter area 115 outside the packet. The parameters of the request packet are the input parameters of the called server procedure,
The parameters of the response packet are the output parameters of the called server procedure. FIG. 5 shows the RPC management table 5
It is a structural drawing of 1. The RPC management table 51 has 128
It has a structure in which byte server procedure entries 141 are arranged, and one entry holds the following information of one server procedure. Lockword to lock entry, server, server procedure, I to identify port
D, ES address of port, main memory address of server procedure, number of parameters, attributes (type, etc.) for each parameter. The RPC management table 51 is a table in which the RPC programs 23 and 24 record server procedure information and refer to it when necessary.

【００１９】次に、本実施例の動作の説明を図７〜２１
により説明する。まず、ＤＦＳの動作を図７〜１１によ
り説明する。図７は、ＯＳのファイルＩ／Ｏプログラム
２５の処理フローを示す。ファイルＩ／Ｏプログラム２
５は、ユーザプログラム２７が、ファイルからデータを
入力（ｇｅｔ）したり、ファイルへデータを出力（ｐｕ
ｔ）するシステムコールを発行したときにＯＳにより実
行される。ｇｅｔの場合を例にとると、ユーザプログラ
ムが発行するシステムコールｇｅｔは、対象ファイルＩ
Ｄ、データ長、ファイル内データ位置、データを読み込
むユーザＩ／Ｏバッファ４６の主記憶アドレスがパラメ
タとして指定されており、それらのパラメタは本プログ
ラム２５に渡される。まず、対象ファイルが他クラスタ
のファイルか否か、すなわちリモート・ファイルアクセ
スか否かをファイルカタログ４９を参照して判定し（ス
テップ２０１）、ｙｅｓならば、まず対象ファイルが共
有ＥＳ１５のファイルキャッシュ４３にあるか否かをキ
ュッシュ内のディレクトリ５０を参照して判定する（ス
テップ２０２）。ファイルキャッシュ４３にあれば、対
象ファイルを他クラスタがアクセスできないようにロッ
クして、対象データを共有ＥＳ１５から主記憶装置７の
指定アドレスに読み込む（ステップ２０３〜２０５）。
この場合は、ＲＰＣを用いることなく、共有ＥＳ１５へ
のキャッシングにより、リモート・ファイルアクセスが
実行できる。ファイルキャッシュ４３に対象ファイルが
なければ、対象ファイルを管理するクラスタのＤＦＳサ
ーバのＩＤを求めて、システムコールのパラメタをＲＰ
Ｃのパラメタリストとして、上記ＤＦＳサーバの手続き
（システムコールｇｅｔ，ｐｕｔに対してそれぞれＧＥ
Ｔルーチン３７，ＰＵＴルーチン３８）に対してＲＰＣ
送信のシステムコールを発行する（ステップ２０６〜２
０７）。ＲＰＣプログラム２３，２４が応答を返すまで
このタスクは待ち状態となる。ＲＰＣの応答が返される
と、待ち状態が解けてコール元のユーザプログラム２７
にリターンする。上記のファイルに対するロックおよび
アンロックは、キャッシュ４３内にファイルごとに設け
られたロックワードに対してＣＳＥＳ命令を発行して行
なう。図８は、ＤＦＳサーバプログラム２８のメインル
ーチン２９の処理フローを示す。本ルーチン２９は、デ
ータ処理システムの立ち上げ時に起動され、初期化処理
を行い、ＲＰＣ登録システムコールを発行して手続きを
登録し、あらかじめ定められたサーバ手続きの多重度の
数だけタスクを生成する（ステップ２２１〜２２３）。
生成された各タスクは、ＲＰＣ受信システムコールを発
行し、クライアントプログラム（本実施例ではファイル
Ｉ／Ｏプログラム２５）からのＲＰＣ受信のシステムコ
ールを発行して、ＲＰＣ要求を待つ（ステップ２２
４）。ＲＰＣ要求を受け取るとＲＰＣプログラム２４に
よりＲＰＣが処理され、処理が終了するとメインルーチ
ン２９に制御が戻り、メインルーチン２９はキャッシュ
更新ルーチン３１を起動し、オペレータが終了コマンド
を入力していなければステップ２２４に戻る（ステップ
２２５〜２２６）。終了が指示されていれば、ＲＰＣ登
録抹消システムコールを発行し、ファイルキャッシュな
どのＤＦＳサーバプログラム２８が確保した資源を解放
して終了する（ステップ２２７〜２２９）。図９は、Ｄ
ＦＳサーバプログラム２８のＧＥＴルーチン３７の処理
フローを示す。ＧＥＴルーチン３７は、メインルーチン
２９の発行したＲＰＣ受信システムコールの処理におい
て、ＧＥＴルーチンへのＲＰＣ要求を受信したときにＲ
ＰＣプログラム２４のＲＰＣ受信ルーチンによって起動
される。ＧＥＴルーチン３７は、入力パラメタからアク
セス対象データが含まれるファイルのブロックアドレス
を求め（ステップ２４１）、主記憶装置８またはローカ
ルＥＳ１０のファイルキャッシュ４４，４５あるいはデ
ィスク装置１４のいずれにアクセス対象データを含むブ
ロックがあるかをファイルキャッシュ４４，４５をロッ
クしてから読み出して判定し（ステップ２４２〜２４
４）、主記憶ファイルキャッシュ４５にあれば主記憶装
置８の入力バッファに当該ブロックを転送し、キャッシ
ュから削除する（ステップ２４５）。ローカルＥＳファ
イルキャッシュ４４にある場合は、当該ブロックを入力
バッファに転送し、ローカルＥＳファイルキャッシュ４
４から削除する（ステップ２４６）。ディスク装置１４
にある場合は、ファイルＩ／Ｏプログラムに対してｇｅ
ｔシステムコールを発行して入力バッファに当該ブロッ
クを読み込む（ステップ２４７）。その後、入力バッフ
ァの当該ブロックを主記憶ファイルキャッシュ４５に入
れて、最近アクセスしたブロックは主記憶ファイルキャ
ッシュ４５にあるように制御し、ファイルキャッシュ４
４，４５をアンロックし、入力バッファ中のアクセス対
象データを出力パラメタであるＧＥＴデータ領域４７に
転送する（ステップ２４８〜２５０）。図１０は、同様
に、ＰＵＴルーチン３８の処理フローを示す。ＰＵＴル
ーチン３８は、メインルーチン２９の発行したＲＰＣ受
信システムコールの処理において、ＰＵＴルーチンへの
ＲＰＣ要求を受信したときにＲＰＣプログラム２４のＲ
ＰＣ受信ルーチンによって起動される。ＰＵＴルーチン
３８は、入力パラメタからアクセス対象データが含まれ
るファイルのブロックアドレスを求め（ステップ２６
１）、主記憶装置８またはローカルＥＳ１０のファイル
キャッシュ４４，４５あるいはディスク装置１４のいず
れにアクセス対象データを含むブロックがあるかをファ
イルキャッシュ４４，４５をロックしてから読み出して
判定し（ステップ２６２〜２６４）、主記憶ファイルキ
ャッシュ４５にあれば主記憶装置８の出力バッファに当
該ブロックを転送し、キャッシュから削除する（ステッ
プ２６５）。ローカルＥＳファイルキャッシュ４４にあ
る場合は、当該ブロックを入力出力バッファに転送し、
ローカルＥＳファイルキャッシュ４４から削除する（ス
テップ２６６）。ディスク装置１４にある場合は、ファ
イルＩ／Ｏプログラムに対してｇｅｔシステムコールを
発行して出力バッファに当該ブロックを読み込む（ステ
ップ２６７）。その後、入力パラメタであるＰＵＴデー
タ領域４８のアクセス対象データを出力バッファのブロ
ックの指定データ位置に書き込み、出力バッファの当該
ブロックを主記憶ファイルキャッシュ４５に入れて、最
近アクセスしたブロックは主記憶ファイルキャッシュ４
５にあるように制御し、ファイルキャッシュ４４，４５
をアンロックする（ステップ２６８〜２７０）。図１１
は、ＤＦＳサーバプログラム２８のキャッシュ更新ルー
チン３１の処理フローを示す。本ルーチン３１は、３種
類のファイルキャッシュ４３，４４，４５に格納するフ
ァイルやファイルのブロックを現在のアクセス状況に合
わせて決定して、それらの入れ替えを行なうものであ
る。アクセス時間の違いから、共有ＥＳファルキャッシ
ュ４３、主記憶ファイルキャッシュ４５、ローカルＥＳ
ファイルキャッシュの順によく使われるファイルやファ
イルブロックを格納する。ただし、共有ＥＳファルキャ
ッシュ４３はファイル単位を格納するが、その他のキャ
ッシュ４４，４５はファイルブロック単位で格納する。
本ルーチン３１は、メインルーチン２９からコールさ
れ、ファイルのリモート・ファイルアクセス履歴からＬ
ＲＵの逆順で共有ＥＳ１５のファイルキャッシュ４３に
ファイルを入れて、ディレクトリ５０を更新し（ステッ
プ２８１〜２８３）、上記ファイル以外のデータのブロ
ックをＬＲＵの逆順で、まず主記憶装置８のファイルキ
ャッシュ４５、そこが一杯になれば次にローカルＥＳの
ファイルキャッシュ４５に入れるよう、共有ＥＳ１５、
主記憶装置８、ローカルＥＳ１０間でファイル・データ
を入れ替える（ステップ２８４〜２９０）。また、各フ
ァイルキャッシュ４３，４４，４５のメモリサイズは、
ＤＦＳサーバプログラムを起動するときに一定量に決め
られる。Next, the operation of this embodiment will be described with reference to FIGS.
Will be explained. First, the operation of the DFS will be described with reference to FIGS. FIG. 7 shows a processing flow of the file I / O program 25 of the OS. File I / O program 2
5, the user program 27 inputs data from a file (get) or outputs data to a file (pu).
It is executed by the OS when the system call for t) is issued. Taking the case of get as an example, the system call get issued by the user program is the target file I.
D, the data length, the data position in the file, and the main storage address of the user I / O buffer 46 for reading the data are designated as parameters, and these parameters are passed to the program 25. First, it is determined whether the target file is a file of another cluster, that is, whether it is a remote file access or not, by referring to the file catalog 49 (step 201). If yes, the target file is the file cache 43 of the shared ES 15 first. It is determined by referring to the directory 50 in the cache (step 202). If it exists in the file cache 43, the target file is locked so that it cannot be accessed by other clusters, and the target data is read from the shared ES 15 to the designated address of the main storage device 7 (steps 203 to 205).
In this case, remote file access can be performed by caching to the shared ES 15 without using RPC. If the target file does not exist in the file cache 43, the ID of the DFS server of the cluster that manages the target file is obtained, and the system call parameter is set to RP.
As a parameter list of C, the procedure of the above DFS server (GE for each of system calls get and put)
RPC for T routine 37, PUT routine 38)
Issue a send system call (steps 206-2)
07). This task is in a waiting state until the RPC programs 23, 24 return a response. When the RPC response is returned, the waiting state is released and the calling user program 27
Return to. Locking and unlocking of the above-mentioned file are performed by issuing a CSES command to a lock word provided in the cache 43 for each file. FIG. 8 shows a processing flow of the main routine 29 of the DFS server program 28. This routine 29 is started when the data processing system is started up, performs initialization processing, issues an RPC registration system call to register a procedure, and creates tasks by a predetermined number of multiplicity of server procedures. (Steps 221 to 223).
Each generated task issues an RPC reception system call, issues an RPC reception system call from the client program (the file I / O program 25 in this embodiment), and waits for an RPC request (step 22).
4). When the RPC request is received, the RPC program 24 processes the RPC, and when the processing is completed, the control is returned to the main routine 29, the main routine 29 activates the cache update routine 31, and if the operator does not input the end command, the step 224 is executed. (Steps 225 to 226). If termination is instructed, an RPC deregistration system call is issued to release resources reserved by the DFS server program 28 such as a file cache and terminate (steps 227 to 229). FIG. 9 shows D
The processing flow of the GET routine 37 of the FS server program 28 is shown. When the GET routine 37 receives the RPC request to the GET routine in the processing of the RPC reception system call issued by the main routine 29, it executes the RPC.
It is started by the RPC reception routine of the PC program 24. The GET routine 37 obtains the block address of the file containing the access target data from the input parameters (step 241), and includes the access target data in any of the file caches 44 and 45 of the main storage device 8 or the local ES 10 or the disk device 14. The file caches 44 and 45 are locked and read to determine whether there is a block (steps 242-24).
4) If it exists in the main memory file cache 45, the block is transferred to the input buffer of the main memory 8 and deleted from the cache (step 245). If it is in the local ES file cache 44, the block is transferred to the input buffer, and the local ES file cache 4
4 is deleted (step 246). Disk device 14
Ge to the file I / O program, if
A system call t is issued to read the block into the input buffer (step 247). After that, the block of the input buffer is put in the main memory file cache 45, and the recently accessed block is controlled to be in the main memory file cache 45.
4 and 45 are unlocked, and the access target data in the input buffer is transferred to the GET data area 47 which is an output parameter (steps 248 to 250). Similarly, FIG. 10 shows a processing flow of the PUT routine 38. In the processing of the RPC receiving system call issued by the main routine 29, the PUT routine 38 receives the RPC of the RPC program 24 when receiving the RPC request to the PUT routine.
It is started by the PC reception routine. The PUT routine 38 obtains the block address of the file containing the access target data from the input parameter (step 26
1) The file caches 44 and 45 are locked and read to determine which of the file caches 44 and 45 of the main storage device 8 or the local ES 10 or the disk device 14 has a block including the access target data (step 262). 264), if present in the main memory file cache 45, the block is transferred to the output buffer of the main memory 8 and deleted from the cache (step 265). If it is in the local ES file cache 44, transfer the block to the input / output buffer,
It is deleted from the local ES file cache 44 (step 266). If it is in the disk device 14, a get system call is issued to the file I / O program to read the block in the output buffer (step 267). After that, the data to be accessed in the PUT data area 48 which is the input parameter is written to the designated data position of the block of the output buffer, the block of the output buffer is put into the main memory file cache 45, and the recently accessed block is the main memory file cache. Four
5 and file caches 44, 45
Is unlocked (steps 268 to 270). 11
Shows a processing flow of the cache update routine 31 of the DFS server program 28. This routine 31 determines files to be stored in the three types of file caches 43, 44, 45 and blocks of files according to the current access status, and replaces them. Shared ES file cache 43, main memory file cache 45, local ES
Stores frequently used files and file blocks in the order of the file cache. However, the shared ES file cache 43 stores in file units, but the other caches 44 and 45 store in file block units.
This routine 31 is called from the main routine 29, and L is accessed from the remote file access history of the file.
The files are put in the file cache 43 of the shared ES 15 in the reverse order of the RU, the directory 50 is updated (steps 281-283), and the blocks of the data other than the above files are reversed in the reverse order of the LRU, and the file cache 45 of the main storage device 8 is first. , Shared ES15 so that it will be put into the file cache 45 of the local ES next when it is full,
File data is exchanged between the main storage device 8 and the local ES 10 (steps 284-290). The memory size of each file cache 43, 44, 45 is
A fixed amount is decided when the DFS server program is started.

【００２０】次に、ＲＰＣの動作を図１２〜２１により
説明する。図示はしていないが、データ処理システム立
ち上げのときにＲＰＣプログラム２３，２４の実行が開
始され、初期化処理として、ＲＰＣ通信領域５２とＲＰ
Ｃ管理テーブル５１を共有ＥＳ１５に作成する。図１２
は、ＲＰＣプログラム２４のＲＰＣ登録ルーチン３１の
処理フローを示す。本ルーチン３１は、図８で説明した
ように、通常はサーバ・プログラム（本実施例ではＤＦ
Ｓサーバプログラム２８）の実行開始時にサーバ・プロ
グラムからＲＰＣ登録システムコールが発行されたとき
にコールされる。本ルーチン３１は、共有ＥＳ１５に当
該サーバのＲＰＣポート領域５３を確保して初期化し
（ステップ３０１〜３０２）、指定サーバのすべての手
続きのためにＲＰＣ管理テーブル５１のエントリを作成
し、初期化する（ステップ３０３〜３０５）。本ルーチ
ン３１により、ＲＰＣポート領域５３とＲＰＣ管理テー
ブル５１のエントリが作られてから、ＲＰＣの送信や受
信が可能となる。図１３は、ＲＰＣプログラム２４のＲ
ＰＣ登録抹消ルーチン３２の処理フローを示す。本ルー
チン３２は、サーバ・プログラム（本実施例ではＤＦＳ
サーバプログラム２８）の終了時にサーバ・プログラム
からＲＰＣ登録抹消システムコールが発行されたときに
コールされる。本ルーチン３２は、ＲＰＣ管理テーブル
５１に登録されている指定サーバのすべての手続きのエ
ントリをサーチし、空きエントリとして初期化し（ステ
ップ３１１〜３１３）、指定サーバのＲＰＣパラメタ領
域５４とＲＰＣポート領域５３を解放する（ステップ３
１４〜３１５）。Next, the operation of the RPC will be described with reference to FIGS. Although not shown, the RPC programs 23 and 24 are started to be executed when the data processing system is started up, and the RPC communication area 52 and the RP are initialized as initialization processing.
The C management table 51 is created in the shared ES 15. 12
Shows a processing flow of the RPC registration routine 31 of the RPC program 24. As described with reference to FIG. 8, this routine 31 is usually a server program (DF in this embodiment).
Called when an RPC registration system call is issued from the server program at the start of execution of the S server program 28). The routine 31 secures and initializes the RPC port area 53 of the server in the shared ES 15 (steps 301 to 302), creates entries of the RPC management table 51 for all procedures of the designated server, and initializes the entries. (Steps 303-305). This routine 31 makes it possible to send and receive RPC after the entries in the RPC port area 53 and the RPC management table 51 are created. FIG. 13 shows the R of the RPC program 24.
9 shows a processing flow of a PC registration deletion routine 32. This routine 32 is a server program (DFS in this embodiment).
Called when an RPC deregistration system call is issued from the server program at the end of the server program 28). This routine 32 searches for entries of all procedures of the designated server registered in the RPC management table 51 and initializes them as empty entries (steps 311 to 313), and the RPC parameter area 54 and RPC port area 53 of the designated server. Release (step 3)
14-315).

【００２１】図１４，１５，１６は、ＲＰＣプログラム
２３のＲＰＣ送信ルーチン３３の処理フローを示す。本
ルーチン３３は、クライアント・プログラム（本実施例
ではファイルＩ／Ｏプログラム２５）からＲＰＣ送信シ
ステムコールが発行されたときにコールされる。本ルー
チン３３は、指定サーバ手続きのＲＰＣ管理テーブル５
１のエントリを主記憶装置７に読み込んでサーバの情報
を得て（ステップ３２１）、主記憶装置７に新たな要求
パケットを作成し、すべての入力パラメタについて、そ
のサイズとパケット内の空き領域のサイズに応じてパラ
メタ格納場所を決定し、パラメタ本体を主記憶装置７の
入力パラメタ領域からコピーするとともに、パケット内
のパラメタリスト・エントリを設定する（ステップ３２
２〜３３２）。パケット内の間接パラメタ領域１３５に
パラメタ本体を格納する場合は、エントリには本体のパ
ケット内相対アドレスを設定し、パケット外のＲＰＣパ
ラメタ領域５４にパラメタ本体を格納する場合は、エン
トリには本体のＥＳアドレスを設定する。クライアント
・プログラムがパラメタとして共有ＥＳ１５のデータを
指定した場合は、直接パラメタとして、指定したデータ
領域のＥＳアドレスをエントリに設定する。システムコ
ールｇｅｔの場合は、入力パラメタは小サイズなのでＲ
ＰＣパラメタ領域５４は不要である。ＰＵＴルーチン３
８の場合は、入力パラメタに大サイズのユーザＩ／Ｏバ
ッファ４６があるので、ＲＰＣパラメタ領域５４を確保
し、ユーザＩ／Ｏバッファ４６のデータをＲＰＣパラメ
タ領域５４に書き込む。その後、指定サーバのＲＰＣポ
ート領域５３の要求ポートをロックして、要求パケット
を要求ポートにキューインする（ステップ３３３〜３３
７）。このように、要求パケットのキューインおよび取
り出しは、ロックにより逐次化される。その後、要求ポ
ートに未処理の要求パケットが既になければ、指定サー
バ・プログラムが動作するクラスタＢ２に通知する必要
があるので、ＲＰＣ通信領域５２の指定サーバのクラス
タ領域をロックし、当該クラスタ領域に通信種別（要
求）１１６とＲＰＣポート領域のＥＳアドレス１１７を
書き込んで、指定サーバが動作するクラスタ（本実施例
ではクラスタＢ２）のＲＰＣプログラム２４を通信ＩＤ
に指定して、ＳＩＧＰＧ命令を発行する（ステップ３３
８〜３４１）。要求ポートに未処理の要求パケットが既
にあれば、今回キューインした要求パケットは上記未処
理の要求パケットとともに処理されるので、ＳＩＧＰＧ
命令は発行しない。その後、主記憶装置７のＲＰＣ管理
テーブルエントリ，要求ポート，作成パケットの領域な
どのＲＰＣ要求の送信処理に要した資源を解放する（ス
テップ３４２）。次に、送信先のサーバ・プログラムか
らのＲＰＣの応答を待つ（ステップ３４３）。ＲＰＣの
応答が返され、ＲＰＣプログラム２４の通信ルーチンか
ら応答パケットの主記憶アドレスを受け取ると、応答パ
ケット内のパラメタをコール元出力パラメタ領域にコピ
ーし、応答パケットにパケット外パラメタがある場合
は、ＲＰＣパラメタ領域５４のパラメタを主記憶装置７
のコール元出力パラメタ変数に読み込む（ステップ３４
４〜３４６）。ＧＥＴルーチンの場合は、出力パラメタ
は大サイズのユーザＩ／Ｏバッファ４６があるので、応
答パケットのＲＰＣパラメタ領域５４からユーザＩ／Ｏ
バッファ４６にデータを読み込む。主記憶装置７の応答
パケットと共有ＥＳのＲＰＣパラメタの領域などのＲＰ
Ｃ送信処理に要した資源を解放して、コール元のクライ
アント・プログラムにリターンする（ステップ３４
７）。14, 15 and 16 show the processing flow of the RPC transmission routine 33 of the RPC program 23. This routine 33 is called when an RPC transmission system call is issued from the client program (file I / O program 25 in this embodiment). This routine 33 is executed by the RPC management table 5 of the designated server procedure.
1 entry is read into the main memory 7 to obtain server information (step 321), a new request packet is created in the main memory 7, and the size and empty area in the packet of all input parameters are created. The parameter storage location is determined according to the size, the parameter body is copied from the input parameter area of the main storage device 7, and the parameter list entry in the packet is set (step 32).
2-332). When the parameter body is stored in the indirect parameter area 135 in the packet, the relative address within the packet of the body is set in the entry, and when the parameter body is stored in the RPC parameter area 54 outside the packet, the entry is stored in the body. Set the ES address. When the client program specifies the data of the shared ES 15 as a parameter, the ES address of the specified data area is directly set as the parameter in the entry. In the case of system call get, the input parameter is a small size, so R
The PC parameter area 54 is unnecessary. PUT routine 3
In the case of 8, since there is a large size user I / O buffer 46 in the input parameter, the RPC parameter area 54 is secured and the data of the user I / O buffer 46 is written in the RPC parameter area 54. After that, the request port in the RPC port area 53 of the designated server is locked, and the request packet is queued in the request port (steps 333 to 33).
7). In this way, the request packet queuing and retrieval are serialized by the lock. After that, if there is no unprocessed request packet in the request port, it is necessary to notify the cluster B2 in which the specified server program operates. Therefore, the cluster area of the specified server in the RPC communication area 52 is locked, and the cluster area is set in the cluster area. The communication type (request) 116 and the ES address 117 of the RPC port area are written, and the RPC program 24 of the cluster (cluster B2 in this embodiment) in which the designated server operates is used as the communication ID.
To issue a SIGPG command (step 33).
8-341). If there is an unprocessed request packet in the request port, the request packet queued this time is processed together with the unprocessed request packet.
No order is issued. After that, the resources required for the transmission processing of the RPC request such as the RPC management table entry of the main storage device 7, the request port, and the area of the created packet are released (step 342). Next, it waits for an RPC response from the destination server program (step 343). When the RPC response is returned and the main memory address of the response packet is received from the communication routine of the RPC program 24, the parameter in the response packet is copied to the caller output parameter area. The parameters of the RPC parameter area 54 are stored in the main memory 7
Read into the caller's output parameter variable (step 34
4-346). In the case of the GET routine, since the output parameter has the large size user I / O buffer 46, the user I / O is output from the RPC parameter area 54 of the response packet.
The data is read into the buffer 46. RP such as the area of the response packet of the main memory 7 and the RPC parameter of the shared ES
The resources required for the C transmission processing are released, and the process returns to the calling client program (step 34).
7).

【００２２】図１７，１８，１９は、ＲＰＣプログラム
２４のＲＰＣ受信ルーチン３４の処理フローを示す。本
ルーチン３４は、サーバ・プログラム（本実施例ではＤ
ＦＳサーバプログラム２８）からＲＰＣ受信システムコ
ールが発行されたときにコールされる。図８で説明した
ように、サーバ・プログラムは初期化処理後、ＲＰＣ受
信システムコールを発行してクラアント・プログラムか
らのＲＰＣ要求を待つ。本ルーチン３４は、ＲＰＣ要求
パケットの到着を待ち、ＲＰＣの要求が送られ、ＲＰＣ
プログラム２４の通信ルーチン３６から要求パケットの
主記憶アドレスを受け取ると（ステップ３５１）、サー
バに関する情報を得るために、指定サーバ手続きのＲＰ
Ｃ管理テーブル・エントリ１４１を主記憶装置８に読み
込む（ステップ３５２）。指定手続きの実行環境を用意
するために、入力および出力パラメタ領域（本実施例で
はＧＥＴデータ領域４７またはＰＵＴデータ領域４８な
ど）を主記憶装置８に確保して、要求パケット内のパラ
メタを指定手続きの入力パラメタ領域にコピーし、要求
パケットにパケット外パラメタがあれば、ＲＰＣパラメ
タ領域５４または直接パラメタ領域５５のパラメタを主
記憶装置８の入力パラメタ領域に読み込か、または共有
ＥＳの入力パラメタ領域として設定してから、指定手続
き（本実施例ではＧＥＴルーチン３７またはＰＵＴルー
チン３８）をコールする（ステップ３５３〜３５８）。
ＰＵＴルーチン３８の場合は、ＲＰＣパラメタ領域５４
の入力パラメタがあるので、主記憶装置８のＰＵＴデー
タ領域４８にＲＰＣパラメタ領域５４のデータを読み込
む。指定手続きの実行が終了した後、クライアント・ブ
ログラムに応答を返すために、主記憶装置８に新たな応
答パケットを作成し、すべての出力パラメタについて、
そのサイズとパケット内の空き領域のサイズに応じてパ
ラメタ格納場所を決定し、パラメタ本体をコピーすると
ともに、パケット内のパラメタリスト・エントリを設定
する（ステップ３６１〜３７２）。パケット内の間接パ
ラメタ領域１３５にパラメタ本体を格納する場合は、エ
ントリには本体のパケット内相対アドレスを設定し、パ
ケット外のＲＰＣパラメタ領域５４にパラメタ本体を格
納する場合は、エントリには本体のＥＳアドレスを設定
する。手続きが出力パラメタ領域を共有ＥＳ１５に持っ
ている場合は、直接パラメタとして、その出力パラメタ
領域のＥＳアドレスをエントリに設定する。ＧＥＴルー
チン３８の場合は、ＲＰＣパラメタ領域５４の出力パラ
メタがあるので、主記憶装置８のＧＥＴデータ領域４８
からＲＰＣパラメタ領域５４にデータを書き込む。その
後、指定サーバのＲＰＣポート領域５３の応答ポートを
ロックして、応答パケットを応答ポートにキューインす
る（ステップ３７３〜３７７）。このように、応答パケ
ットのキューインおよび取り出しは、ロックにより逐次
化される。次に、応答パケットのキューインにより、サ
ーバ・プログラム側は、当該ＲＰＣ要求の処理が完了し
たので、クライアント・プログラムが動作するクラスタ
Ａ１に通知する必要があるので、ＲＰＣ通信領域５２の
指定サーバのクラスタ領域をロックし、当該クラスタ領
域に通信種別（応答）１１６とＲＰＣポート領域のＥＳ
アドレス１１７を書き込んで、クライアント・プログラ
ムが動作するクラスタ（本実施例ではクラスタＡ１）の
ＲＰＣプログラム２３を通信ＩＤに指定して、ＳＩＧＰ
Ｇ命令を発行する（ステップ３７７〜３８０）。その
後、主記憶装置８のＲＰＣ管理テーブルエントリ，要求
ポート，応答ポート，作成パケットの領域などのＲＰＣ
受信処理に要した資源を解放する（ステップ３８１）。
そして、ＲＰＣポート領域５３の要求ポートを読み込ん
で、処理した要求パケットを空きパケットとし、未処理
の要求パケットがあれば先頭の未処理要求パケットをパ
ラメタとしてステップ３５２に戻り、ＲＰＣ要求の処理
を繰り返す。未処理の要求パケットがなければ受信ルー
チンの処理を終わる（ステップ３８２〜３８８）。17, 18 and 19 show the processing flow of the RPC receiving routine 34 of the RPC program 24. This routine 34 is a server program (D in this embodiment).
Called when an RPC receiving system call is issued from the FS server program 28). As described with reference to FIG. 8, after the initialization process, the server program issues an RPC reception system call and waits for an RPC request from the client program. This routine 34 waits for the arrival of the RPC request packet, sends the RPC request,
When the main storage address of the request packet is received from the communication routine 36 of the program 24 (step 351), the RP of the designated server procedure is obtained in order to obtain information about the server.
The C management table entry 141 is read into the main memory 8 (step 352). In order to prepare the execution environment for the designated procedure, the input and output parameter areas (in this embodiment, the GET data area 47 or the PUT data area 48, etc.) are secured in the main memory 8 and the parameters in the request packet are designated. Of the RPC parameter area 54 or the direct parameter area 55 to the input parameter area of the main storage device 8 or the shared ES input parameter area. Then, the designated procedure (the GET routine 37 or the PUT routine 38 in this embodiment) is called (steps 353 to 358).
In the case of the PUT routine 38, the RPC parameter area 54
Data of the RPC parameter area 54 is read into the PUT data area 48 of the main memory 8. After the execution of the designated procedure is completed, a new response packet is created in the main memory 8 in order to return a response to the client program, and for all output parameters,
The parameter storage location is determined according to the size and the size of the free area in the packet, the parameter body is copied, and the parameter list entry in the packet is set (steps 361 to 372). When the parameter body is stored in the indirect parameter area 135 in the packet, the relative address within the packet of the body is set in the entry, and when the parameter body is stored in the RPC parameter area 54 outside the packet, the entry is stored in the body. Set the ES address. When the procedure has the output parameter area in the shared ES 15, the ES address of the output parameter area is directly set as the parameter in the entry. In the case of the GET routine 38, since there is an output parameter in the RPC parameter area 54, the GET data area 48 in the main memory 8
Write data into the RPC parameter area 54 from. After that, the response port in the RPC port area 53 of the designated server is locked, and the response packet is queued in the response port (steps 373 to 377). In this way, the queue-in and take-out of response packets are serialized by the lock. Next, due to the queue-in of the response packet, the server program side has completed the processing of the RPC request and needs to notify the cluster A1 in which the client program operates. The cluster area is locked, and the communication type (response) 116 and ES of the RPC port area are locked in the cluster area.
The address 117 is written, the RPC program 23 of the cluster in which the client program operates (cluster A1 in this embodiment) is designated as the communication ID, and SIGP is set.
The G command is issued (steps 377 to 380). After that, the RPCs such as the RPC management table entry, the request port, the response port, and the created packet area of the main memory 8
The resources required for the receiving process are released (step 381).
Then, the request port in the RPC port area 53 is read, the processed request packet is set as an empty packet, and if there is an unprocessed request packet, the head unprocessed request packet is used as a parameter to return to step 352 to repeat the RPC request processing. .. If there is no unprocessed request packet, the processing of the reception routine ends (steps 382 to 388).

【００２３】図２０，２１は、ＲＰＣプログラム２３，
２４のＲＰＣ通信ルーチン３５，３６の処理フローを示
す。本ルーチン３５，３６は、サーバおよびクライアン
トの両側のＲＰＣプログラム２３，２４に含まれ、通信
ＩＤにＲＰＣプログラム２３，２４を指定したＳＩＧＰ
Ｇ命令による割り込みの発生を検知したＯＳ核プログラ
ム２１，２２によりコールされる。ＯＳ核プログラム２
１，２２は、割り込みを検知すると通信ＩＤレジスタ１
６の内容を読んでＲＰＣプログラムに対応するビットが
オンであることによりＲＰＣプログラムへの通信である
ことを知る。本ルーチン２３，２４は、ＲＰＣ通信領域
５２の自クラスタ領域を主記憶装置７，８に読み込み、
当該クラスタ領域をアンロックする（ステップ４０１〜
４０２）。このように、ＲＰＣ通信領域５２のクラスタ
領域は、ＳＩＧＰＧ命令を発行するＲＰＣプログラム２
３，２４のルーチンがロックしたままＳＩＧＰＧ命令を
発行し、この通信ルーチン３５，３６が、ＲＰＣ通信領
域５２の制御情報を読み込んだ後でアンロックするの
で、ＲＰＣ通信領域５２による情報の授受の逐次化が行
なわれる。本ルーチンは、その後、通信種別１１６を判
定し（ステップ４０３）、通信種別１１６が要求なら
ば、ＥＳアドレス１１７が示すＲＰＣポート領域５３の
要求ポート１１１をロックして主記憶装置８に読み込
み、要求ポート中のすべての未処理の要求パケット１１
２について、要求ポートに対応するサーバ・プログラム
のＲＰＣ受信を発行して要求パケットを待っているタス
ク（ＲＰＣ受信ルーチン内）を選んで、要求パケットを
パラメタとして渡して待ちを解除し、要求パケットの状
態を処理中とする（ステップ４０６〜４１１）。要求パ
ケットを待っているタスク数が未処理パケット数より小
さい場合は、処理できない未処理パケットは未処理のま
ま要求ポート１１１に書き戻されることになる。ステッ
プ４０３において通信種別１１６が応答ならば、ＥＳア
ドレス１１７が示すＲＰＣポート領域５３の応答ポート
１１３をロックして主記憶装置７に読み込み、応答ポー
ト中のすべての未処理の応答パケット１１４について、
応答パケットに指定されているクライアント・プログラ
ムのＲＰＣ送信を発行して応答パケットを待っているタ
スク（ＲＰＣ送信ルーチン内）に対して、応答パケット
をパラメタとして渡して待ちを解除し、応答ポート内の
応答パケットの状態を処理中とする（ステップ４２１〜
４２８）。20 and 21 show the RPC program 23,
24 shows a processing flow of 24 RPC communication routines 35 and 36. The routines 35 and 36 are included in the RPC programs 23 and 24 on both sides of the server and the client, and SIGP in which the RPC programs 23 and 24 are designated as the communication IDs.
It is called by the OS core programs 21 and 22 that have detected the occurrence of an interrupt due to the G instruction. OS nuclear program 2
1 and 22 detect the interrupt and communication ID register 1
By reading the contents of 6, it is known that the communication to the RPC program is made by turning on the bit corresponding to the RPC program. The routines 23 and 24 read the own cluster area of the RPC communication area 52 into the main storage devices 7 and 8,
Unlock the cluster area (step 401-).
402). As described above, the cluster area of the RPC communication area 52 is the RPC program 2 that issues the SIGPG command.
Since the routines 3 and 24 issue the SIGPG instruction while the routines are locked, and the communication routines 35 and 36 unlock after reading the control information of the RPC communication area 52, successive transmission and reception of information by the RPC communication area 52. The conversion is performed. This routine thereafter determines the communication type 116 (step 403), and if the communication type 116 is a request, locks the request port 111 of the RPC port area 53 indicated by the ES address 117, reads it into the main storage device 8, and makes a request. All outstanding request packets in port 11
For 2, select a task (in the RPC reception routine) that issues the RPC reception of the server program corresponding to the request port and waits for the request packet, passes the request packet as a parameter, and releases the wait. It is assumed that the state is being processed (steps 406 to 411). When the number of tasks waiting for a request packet is smaller than the number of unprocessed packets, unprocessed packets that cannot be processed are written back to the request port 111 as unprocessed. If the communication type 116 is a response in step 403, the response port 113 of the RPC port area 53 indicated by the ES address 117 is locked and read into the main storage device 7, and all unprocessed response packets 114 in the response port are
For the task (in the RPC transmission routine) that issues the RPC transmission of the client program specified in the response packet and waits for the response packet, passes the response packet as a parameter to cancel the wait and The state of the response packet is assumed to be in process (steps 421 to
428).

【００２４】[0024]

【発明の効果】本発明によれば、ＲＰＣの要求ならびに
応答情報を受信側の処理を待ち合わせることなくまとめ
て送信することができる。また、ＲＰＣ受理側のクラス
タにおいては、ＲＰＣの大容量パラメタを主記憶装置の
バッファに一旦読み込みことやサーバ手続きのパラメタ
領域にコピーするＣＰＵオーバヘッドはなくなり、さら
に、大容量パラメタのための主記憶装置バッファすなわ
ちメモリ・オーバヘッドがなくなるので、ＲＰＣの処理
時間が短縮され、かつＲＰＣ受理側のクラスタの処理ス
ループットが向上する。さらに、他のデータ処理システ
ムまたはクラスタと通信することなく、ＲＰＣのインタ
ーフェース情報を共有記憶装置から直接読み込むことに
より得ることができ、ＲＰＣの処理時間が短縮される。
これらのことにより、クライアント／サーバ・モデルの
協調処理を高速に実行することができ、このことは、ク
ライアント／サーバ・モデルの協調処理のひとつである
分散ファイルシステムの高速化につながる。According to the present invention, RPC request and response information can be collectively transmitted without waiting for processing on the receiving side. Further, in the cluster on the RPC receiving side, there is no CPU overhead for once reading the large-capacity parameter of the RPC into the buffer of the main storage device or copying it to the parameter area of the server procedure. Since there is no buffer or memory overhead, the processing time of RPC is shortened and the processing throughput of the cluster on the RPC receiving side is improved. Further, the RPC interface information can be obtained by reading the interface information of the RPC directly from the shared storage device without communicating with another data processing system or cluster, and the processing time of the RPC is shortened.
By these things, the client / server model cooperative processing can be executed at high speed, which leads to the acceleration of the distributed file system which is one of the client / server model cooperative processing.

【００２５】また、分散ファイルシステムにおいて、リ
モート・アクセス対象のファイル・データが共有記憶装
置のキャッシュにあれば、リモート・アクセス要求側の
クラスタは、共有記憶装置から読み出すだけでファイル
・データにアクセスできるので、アクセス時間が短縮さ
れる。したがって、分散ファイルシステムを高速化す
る。In the distributed file system, if the file data to be remotely accessed is in the cache of the shared storage device, the cluster on the remote access request side can access the file data only by reading from the shared storage device. Therefore, the access time is shortened. Therefore, the distributed file system is accelerated.

[Brief description of drawings]

【図１】実施例のデータ処理システムの構成を示すブロ
ック図である。FIG. 1 is a block diagram illustrating a configuration of a data processing system according to an embodiment.

【図２】実施例のデータ処理システムのソフトウェア構
成を示すブロック図である。FIG. 2 is a block diagram showing a software configuration of the data processing system of the embodiment.

【図３】実施例のＲＰＣポート領域の構造図である。FIG. 3 is a structural diagram of an RPC port area according to an embodiment.

【図４】実施例のＲＰＣポートヘッダとパケットの構造
図である。FIG. 4 is a structural diagram of an RPC port header and a packet according to the embodiment.

【図５】実施例のＲＰＣ管理テーブルの構造図である。FIG. 5 is a structural diagram of an RPC management table according to the embodiment.

【図６】実施例のキャッシュディレクトリの構造図であ
る。FIG. 6 is a structural diagram of a cache directory according to an embodiment.

【図７】実施例のＯＳファイルＩ／Ｏプログラムのフロ
ーチャートである。FIG. 7 is a flowchart of an OS file I / O program according to the embodiment.

【図８】実施例のＤＦＳサーバプログラムのメインルー
チンのフローチャートである。FIG. 8 is a flowchart of a main routine of a DFS server program according to the embodiment.

【図９】実施例のＤＦＳサーバプログラムのＧＥＴルー
チンのフローチャートである。FIG. 9 is a flowchart of a GET routine of the DFS server program according to the embodiment.

【図１０】実施例のＤＦＳサーバプログラムのＰＵＴル
ーチンのフローチャートである。FIG. 10 is a flowchart of a PUT routine of the DFS server program according to the embodiment.

【図１１】実施例のＤＦＳサーバプログラムのキャッシ
ュ更新ルーチンのフローチャートである。FIG. 11 is a flowchart of a cache update routine of the DFS server program according to the embodiment.

【図１２】実施例のＯＳ−ＲＰＣプログラムのサーバ登
録ルーチンのフローチャートである。FIG. 12 is a flowchart of a server registration routine of an OS-RPC program according to the embodiment.

【図１３】実施例のＯＳ−ＲＰＣプログラムのサーバ登
録抹消ルーチンのフローチャートである。FIG. 13 is a flowchart of a server registration deletion routine of the OS-RPC program of the embodiment.

【図１４】実施例のＯＳ−ＲＰＣプログラムのＲＰＣ送
信ルーチンのフローチャート第１部である。FIG. 14 is a first part of a flowchart of an RPC transmission routine of the OS-RPC program of the embodiment.

【図１５】実施例のＯＳ−ＲＰＣプログラムのＲＰＣ送
信ルーチンのフローチャート第２部である。FIG. 15 is the second part of the flowchart of the RPC transmission routine of the OS-RPC program of the embodiment.

【図１６】実施例のＯＳ−ＲＰＣプログラムのＲＰＣ送
信ルーチンのフローチャート第３部である。FIG. 16 is the third part of the flowchart of the RPC transmission routine of the OS-RPC program of the embodiment.

【図１７】実施例のＯＳ−ＲＰＣプログラムのＲＰＣ受
信ルーチンのフローチャート第１部である。FIG. 17 is a first part of a flowchart of an RPC reception routine of the OS-RPC program of the embodiment.

【図１８】実施例のＯＳ−ＲＰＣプログラムのＲＰＣ受
信ルーチンのフローチャート第２部である。FIG. 18 is the second part of the flowchart of the RPC reception routine of the OS-RPC program of the embodiment.

【図１９】実施例のＯＳ−ＲＰＣプログラムのＲＰＣ受
信ルーチンのフローチャート第３部である。FIG. 19 is the third part of the flowchart of the RPC reception routine of the OS-RPC program of the embodiment.

【図２０】実施例のＯＳ−ＲＰＣプログラムの通信ルー
チンのフローチャート第１部である。FIG. 20 is a first part of a flowchart of a communication routine of the OS-RPC program of the embodiment.

【図２１】実施例のＯＳ−ＲＰＣプログラムの通信ルー
チンのフローチャート第２部である。FIG. 21 is the second part of the flowchart of the communication routine of the OS-RPC program of the embodiment.

[Explanation of symbols]

１，２…クラスタ、７，８…主記憶装置、９，１０…ロ
ーカル拡張記憶装置、１５…共有拡張記憶装置、２３，
２４…ＯＳ−ＲＰＣプログラム、２５，２６…ＯＳファ
イルＩ／Ｏプログラム、２７…ユーザプログラム、２８
…分散ファイルシステム・サーバプログラム、４３…共
有拡張記憶ファイルキュッシュ、４４…ローカル拡張記
憶ファイルキュッシュ、４５…主記憶ファイルキュッシ
ュ、５１…ＲＰＣ管理テーブル、５２…ＲＰＣ通信領
域、５３…ＲＰＣポート領域、５３…ＲＰＣパラメタ領
域。1, 2 ... Cluster, 7, 8 ... Main storage device, 9, 10 ... Local expansion storage device, 15 ... Shared expansion storage device, 23,
24 ... OS-RPC program, 25, 26 ... OS file I / O program, 27 ... User program, 28
... distributed file system / server program, 43 ... shared extended storage file cache, 44 ... local extended storage file cache, 45 ... main storage file cache, 51 ... RPC management table, 52 ... RPC communication area, 53 ... RPC port area, 53 ... RPC parameter area.

Claims

[Claims]

1. A plurality of clusters, each cluster having one or more processors and main memory,
A method of calling a procedure between clusters in a data processing system adopting a hierarchical storage type cluster multiprocessor configuration connected by a randomly accessible shared storage device, wherein a procedure is called in a first cluster of a calling side. Procedure call request information including an identifier and a parameter of the procedure call request information written in the shared storage device in the second cluster to be called, and the procedure corresponding to the procedure identifier is written. A cluster / multiprocessor cooperative processing method characterized by executing the following.

2. A plurality of clusters, each cluster having one or more processors and main memory,
A method of performing a remote procedure call between clusters in a data processing system adopting a cluster multiprocessor configuration connected by a randomly accessible shared storage device, comprising:
The call request information including the identifier of the procedure to be called and the procedure parameters are written in the shared storage device. In the call receiving side cluster, the call request information is read from the shared storage device and requested by the call request information. Secure the resources necessary for executing the procedure, including the parameter area in the main memory of the task and the call receiving task, and then read the above parameters from the shared memory into the above parameter area and execute the procedure requested by the call. A cluster / multiprocessor cooperative processing method characterized by executing.

3. When the call request information of the call requesting side cluster is written to the shared storage device, call request information including information necessary for a call request other than the parameter body and position information in the shared storage of the parameter body is provided. 3. The shared storage device according to claim 2, wherein the parameter main body is written into the first region of the shared storage device, and the parameter main body is written into the second region of the shared storage device from the main storage device region of the data designated as a parameter by the call request side program. Cluster / multiprocessor cooperative processing method.

4. When the call request side program designates the data of the shared storage device as a parameter of the remote procedure call, the data area is written in writing the call request information of the call request side cluster to the shared storage device. 4. The cluster multiprocessor cooperative processing method according to claim 3, wherein the position information of the first area is set as the second area of the shared storage device for the parameter body.

5. When the procedure of the call target defines the data of the shared storage device as a parameter, when reading the call request information of the second cluster on the call receiving side, it corresponds to the above parameter of the shared storage device. The second to do
4. The cluster / multiprocessor cooperative processing method according to claim 3, wherein the area is set as the procedure parameter as it is.

6. The call request is provided in the shared storage device with a queue capable of accumulating a plurality of pieces of call request information, and a flag indicating whether or not the second cluster on the receiving side is processing the call request of the queue. In the first cluster on the side, if the flag is off at the time of enqueuing the call request information, an interrupt is generated to the second cluster, and if the flag is on, no interrupt is generated. 3. The cluster / multiprocessor cooperative processing method according to claim 2, wherein the unprocessed call request information of the queue is read when the processing of the call request read from the queue is completed.

7. A plurality of clusters, each cluster having one or more processors and main memory,
In a data processing system that adopts a hierarchical multi-processor cluster multiprocessor configuration that is connected by a shared storage device that can be randomly accessed,
A method of performing a procedure call, which holds interface information of a procedure targeted for a remote procedure call in a table of the shared storage device, and when issuing a call request, refers to the table information to obtain the interface information of the procedure. A cluster / multiprocessor cooperative processing method characterized by obtaining.

8. A hierarchical storage type cluster in which a plurality of clusters, each cluster having one or more processors, a main storage device and a file storage device, are connected by a randomly accessible shared storage device. A method for performing remote file access of a distributed file system between clusters in a data processing system having a multiprocessor configuration, wherein a part of the above files is provided in a cluster on the remote file access accepting side having a file to be accessed. Alternatively, a cluster / multiprocessor cooperative processing method is characterized by caching all of them in the shared storage device.

9. A cluster on the remote file access request side judges whether or not file data targeted for remote file access exists in the cache of the shared storage device, and if it exists, the file data in the cache. 9. The cluster / multiprocessor cooperative processing method according to claim 8, wherein the cluster / multiprocessor cooperative processing method is directly accessed.