JP2016212902A - File server, information system and method of controlling information system - Google Patents

Abstract

The present invention provides a technique capable of appropriately referring to a file managed by a file server at one site by using a file server at another site. A local file server is connected to a plurality of user terminals and a remote file server, stores file data received from the plurality of user terminals in a storage device, and replicates the file to the remote file server. If the file related to the access request is not stub based on the access request from the user terminal, the data of the file is read from the storage device and the request source If the file related to the access request sent to the user terminal is stubbed, the file data is acquired from the remote file server, and the process of transmitting the file data to the requesting user terminal is controlled. . [Selection] Figure 1

Description

  The present invention relates to an information system including a file server connected to a communication network, a method for controlling the information system, and a technique for managing files of the file server.

  In the past, companies and individuals purchased servers and software at their own expense and used them, but in order to reduce TCO (Total Cost of Ownership), cloud computers that use servers and software via the Internet Tend to spread.

  Patent Document 1 discloses a system in which a storage device (local storage device, local file server) at a plurality of bases (called Edge) and a storage device (remote storage device, remote file server) at a data center (called Core) are connected. In this case, the file at the site is copied to the data center, and the copied file is managed as a stub at the site. A technique for reading this file is disclosed.

  In the system disclosed in Patent Document 1, when a user writes a file to the file system with respect to the local storage device, the local storage device periodically replicates the file to the core side. In this replication processing, there are cases where the time and time zone during which the replication processing can be executed, the amount of data that can be transmitted, and the like are limited.

  In the local storage device, even after replication, the file is managed as a cache file without being deleted.

  Thereafter, when the file system capacity on the Edge side reaches a certain threshold value, the cache file having the old access date and time is converted into a stub file (stubbing). Here, the stub file is a file that does not have a reference to actual data in Edge but holds a reference to actual data in Core.

  In such a state, when the user accesses the stub file to the local storage device, there is no actual data of the file on the Edge side, so the process of downloading the actual data from the Core side to the Edge side (Recall processing) is executed.

US Patent Application Publication No. 2012/0016838

  In the system described in Patent Document 1, it is not considered that a user moves between Edges and accesses the user's data from another Edge at the destination. In such a system, for example, when a user moves to another Edge and accesses data in the user's dedicated directory (home directory) in that Edge, the file updated by the source Edge There is a problem that the destination Edge cannot refer to the file updated with the source Edge until the file is replicated to the Core side. This problem is particularly likely to occur when updated data cannot be sent in a single replication process when the replication time, time zone, and data volume are limited.

  Therefore, an object of the present invention is to provide a technique that can appropriately refer to a file managed by a file server at one site by using a file server at another site.

  A local file server according to an aspect of the present invention is connected to a plurality of user terminals and a remote file server, stores file data received from the plurality of user terminals in a storage device, and the file is a remote file Replicate to the server, stubb the file stored in the storage device, and if the file related to the access request is not stubbed based on the access request from the user terminal, read the file data from the storage device Processing to send to the requesting user terminal, if the file related to the access request is stubbed, obtain the file data from the remote file server, and send the file data to the requesting user terminal To control. Then, the data of the user who made a session disconnection request to the local file server within a predetermined time is preferentially replicated to the remote file server.

  According to the present invention, a file updated in a local file server can be appropriately stored in a remote file server. Therefore, for example, a file updated in a certain local file server can be appropriately referred from another local file server connected to the remote file server.

FIG. 1 is a diagram illustrating an overview of the information system according to the first embodiment. FIG. 2 is a hardware configuration diagram of the information system according to the first embodiment. FIG. 3 is a software configuration diagram of the information system according to the first embodiment. FIG. 4 is a configuration diagram of file system configuration information according to the first embodiment. FIG. 5 is a configuration diagram of a directory entry according to the first embodiment. FIG. 6 is a configuration diagram of the inode according to the first embodiment. FIG. 7 is a configuration diagram of an inode management table according to the first embodiment. FIG. 8 is a detailed configuration diagram of the inode according to the first embodiment. FIG. 9 is a diagram illustrating a user management table and a user management table management method according to the first embodiment. FIG. 10 is a flowchart of an access process according to the first embodiment. FIG. 11 is a flowchart of the lock process according to the first embodiment. FIG. 12 is a flowchart of the unlocking process according to the first embodiment. FIG. 13 is a flowchart of connected user management processing according to the first embodiment. FIG. 14 is a flowchart of the cache overwriting process according to the first embodiment. FIG. 15 is a flowchart of the recall process according to the first embodiment. FIG. 16 is a flowchart of stub information acquisition processing according to the first embodiment. FIG. 17 is a flowchart of disconnected user management processing according to the first embodiment. FIG. 18 is a flowchart of the replication process (scheme A) according to the first embodiment. FIG. 19 is a flowchart of the replication processing (method B) according to the first embodiment. FIG. 20 is a flowchart of replication processing (other than subordinates) according to the first embodiment. FIG. 21 is a flowchart of the stubbing process according to the first embodiment. FIG. 22 is a diagram illustrating the problem. FIG. 23 is a configuration diagram of a setting file according to the second embodiment. FIG. 24 is a diagram illustrating an overview of the realizing method 1 according to the second embodiment. FIG. 25 is a configuration diagram of a base list according to the second embodiment. FIG. 26 is a diagram illustrating an overview of the implementation method 2 according to the second embodiment. FIG. 27 is a diagram illustrating grouping of bases according to the second embodiment. FIG. 28 is a configuration diagram of a user list according to the second embodiment. FIG. 29 is a diagram illustrating an outline of the method A of the realizing method 3 according to the second embodiment. FIG. 30 is a diagram illustrating an outline of the method B of the realizing method 3 according to the second embodiment. FIG. 31 is a flowchart of Edge-side session disconnection processing according to the second embodiment. FIG. 32 is a flowchart of the session disconnection process on the Core side according to the second embodiment. FIG. 33 is a diagram illustrating an overview of data acquisition processing by polling according to the second embodiment. FIG. 34 is a flowchart of data acquisition processing by polling according to the second embodiment. FIG. 35 is a flowchart of Edge-side session connection processing according to the second embodiment. FIG. 36 is a flowchart of the session connection processing on the Core side according to the second embodiment.

  Several embodiments will be described with reference to the drawings. The embodiments described below do not limit the invention according to the claims, and all the elements and combinations described in the embodiments are essential for the solution of the invention. Is not limited.

  In the following description, the information of the present invention may be described using an expression such as “aaa table”, but the information may be expressed in a form other than a data structure such as a table. Therefore, the “aaa table” or the like may be referred to as “aaa information” to indicate that it does not depend on the data structure. In addition, information for identifying “bbb” of the present invention may be described by an expression such as “bbb name”. However, the information for identifying these is not limited to a name, but an identifier, an identification number, Any information can be used as long as it can identify “bbb” such as an address.

  In the following description, “program” may be used as the subject, but the program executes processing determined by being executed by a processor (typically a CPU (Central Processing Unit)) in the memory and I / O. Since it is performed while using F (interface), the description may be made with the processor as the subject. Further, the processing disclosed with the program as the subject may be processing performed by a file server (for example, a file storage device or archive storage device described later). Further, part or all of the program may be realized by dedicated hardware. Various programs may be installed in each computer by a program distribution server or a computer-readable storage medium. As the storage medium, for example, an IC card, an SD card, a DVD, or the like may be used.

  Here, various terms will be described. “Core” is a base (aggregation base) including a remote computer system, for example, a base that collectively manages servers and storage devices or a base that provides cloud services. “Edge” is a base including a local computer system, for example, a base where a user actually performs business such as a branch office, a sales office, or a remote office. A “stub” is an object (metadata) associated with file storage location information (information indicating a link destination). “Stubbing” refers to deleting actual data (actual data) from an Edge (Edge computer system) file and maintaining only management information. Since a stubbed file does not hold actual data, it is necessary to obtain actual data from the Core computer system when accessed. For this reason, access performance to a stubbed file is lower than that of a normal file.

  “Replication” means copying a file in Edge to Core. “Migration” means that a file in Edge is replicated to Core and a file in Edge is stubbed. “Archive” is a general term for migration and replication. “Recall” refers to acquiring actual data from the Core for a stubbed file and holding it in an Edge file. “Cache” means a file remaining in Edge after replication from Edge to Core, or leaving a file in Edge as such. Access to the cache has access performance equivalent to that of a normal file. The “home directory” refers to a user-specific directory assigned to each user in the file system, and includes the directory and file of the user under the subordinate.

  First, an information system according to the first embodiment will be described.

  FIG. 1 is a diagram illustrating an overview of the information system according to the first embodiment.

  When the file A of the file system 36 of the file storage device 30 is updated by the user A in the information system Edge 10A (also referred to as base A) ((A) in the figure), the file storage device 30 When the user A disconnects the session to the file storage device 30, or periodically, the file (file A etc.) of the file system 36 is replicated to the archive storage device 120 and the file is stubbed (in the figure) (B)).

  Thereafter, when the user A moves from the site A to the site B (Edge 10B) ((C) in the figure) and the user A connects a session to the file storage device 30 at the site B, the file storage device 30 at the site B The file A is recalled from the file system 126 of the archive storage apparatus 120 of the Core 100, and the file A is stored in the file system 36 ((D) in the figure). Here, when the file A is recalled at the site B, since the file A has already been replicated in the file system 126 of the Core 100, the file A can be recalled appropriately.

  FIG. 2 is a diagram illustrating a hardware configuration of the information system according to the first embodiment.

  The hardware of the information system is arranged in Edge 10 and Core 100. In the example illustrated in FIG. 2, the Edge 10 is plural and the Core 100 is singular, but the Edge 10 may be singular and / or the Core 100 may be plural.

  The computer system of Edge 10 includes a RAID (Redundant Array of Independent (or Inexpensive) Disks) system 20, one or more file storage devices 30, one or more clients (for example, a personal computer) / host (for example, a server) 40, and the like. . The file storage device 30 is an example of a local file server. The file storage device 30 is connected to the client / host 40 via, for example, a communication network 50 (for example, a LAN (Local Area Network)). The file storage device 30 is connected to the RAID system 20 via, for example, a communication network (for example, SAN (Storage Area Network)).

  The RAID system 20 includes a CHA (Channel Adapter) 21, a DKC (DisK Controller) 22, and a DISK 23. A CHA 21 and a DISK 23 are connected to the DKC 22. The CHA 21 is a communication interface device connected to the file storage device 30. The DKC 22 is a controller. The DISK 23 is a disk-type physical storage device (for example, HDD (Hard Disk Drive)). Another type of physical storage device (for example, a flash memory device) may be employed as the physical storage device. Further, the number of DISKs 23 is singular in FIG. 2, but is actually plural (as shown, it may be singular). One or more RAID groups may be configured by the plurality of DISKs 23. Although not shown, the RAID system 20 includes a memory that stores a program executed in the RAID system 20 and a CPU (Central Processing Unit) that executes the program.

  The RAID system 20 receives the block level I / O request transmitted from the file storage device 30 by the CHA 21 and executes I / O to the appropriate DISK 23 based on the control of the DKC 22.

  The file storage device 30 includes a memory 31, a CPU 32, a NIC (Network Interface Card) 33, and an HBA (Host Bus Adapter) 34. A CPU 32 is connected to the memory 31, the NIC 33, and the HBA 34.

  The NIC 33 is a communication interface device that communicates with the archive storage device 120 and the client / host 40.

  The HBA 34 is a communication interface device that communicates with the RAID system 20.

  The memory 31 is a storage area (for example, RAM (Random Access Memory) or ROM (Read Only Memory)) that the CPU 32 can directly read and write. In the file storage device 30, a program (for example, OS (Operating System)) for controlling the file storage device 30 is read onto the memory 31, and the CPU 32 executes the program. The file storage device 30 may have another type of storage resource in addition to or instead of the memory 31. The memory 31 is an example of a storage device.

  The file storage device 30 receives a file level I / O request from the client / host 40 via the NIC 33. The file storage device 30 creates an I / O request (block level I / O request) for I / O of a data block constituting the file specified by the I / O request. The file storage device 30 transmits a block level I / O request to the RAID system 20 via the HBA 34.

  The client / host 40 includes a memory 41, a CPU 42, a NIC 43, and a DISK 44. The client / host 40 may have other types of storage resources in addition to or instead of the memory 41 and / or the DISK 44.

  In the client / host 40, a program stored in the DISK 44 (a program (for example, OS) for controlling the client / host 40) is read onto the memory 41, and the CPU 42 executes the program. In addition, the client / host 40 transmits a file level I / O request to the file storage device 30 via the NIC 43.

  The Core 100 computer system includes a RAID system 110 and an archive storage device 120. The archive storage device 120 is an example of a remote file server. A RAID system 110 is connected to the archive storage device 120.

  The RAID system 110 includes a CHA 111, a DKC 112, and a DISK 113. In FIG. 2, the configuration of the RAID system 110 and the configuration of the RAID system 20 are the same. Therefore, the RAID system 110 also receives the block level I / O request transmitted from the archive storage apparatus 120 by the CHA 111 and executes I / O to the appropriate DISK 113 based on the control of the DKC 112. The configuration of the RAID system 110 and the configuration of the RAID system 20 may be different.

  The archive storage device 120 includes a memory 121, a CPU 122, a NIC 123, and an HBA 124. Instead of or in addition to the memory 121, another type of storage resource may be provided. In the archive storage device 120, a program (for example, OS) for controlling the archive storage device 120 is read onto the memory 121, and the CPU 122 executes the program. The archive storage device 120 communicates with the file storage device 30 via the NIC 123 and the communication network 80. The archive storage device 120 accesses the RAID system 110 in block units via the HBA 124.

  FIG. 3 is a software configuration diagram of the information system according to the first embodiment.

  The RAID system 20 (110) includes a plurality of LU (Logical Unit) 24 (114) and an OS LU (Logical Unit for OS) 25 (115). The LU 24 (114) is a logical storage device provided to a host device such as the file storage device 30 (archive storage device 120), and is created based on the storage area of the DISK 23 (113). The LU 24 (114) may be a substantial LU based on one or more DISKs 23 (113), or may be a virtual LU according to Thin Provisioning. The LU 24 (114) is composed of a plurality of blocks (storage areas). The file is stored in the LU 24 (114).

  The OS LU 25 (115) is a logical storage device. The OS LU 25 (115) may be a substantial LU based on one or more DISKs 23 (113). The OS LU 25 (115) may store a program or the like for controlling the file storage device 30 or the archive storage device 120, or all or part of the file system configuration information 200 described later.

  A data mover program 37 (125), a file system 36 (126), and a kernel / driver 38 (127) are stored in the memory 31 of the file storage device 30 (the memory 121 of the archive storage device 120). . A file sharing program 35 is further stored in the memory 31 of the file storage device 30. Hereinafter, the data mover program 37 in the file storage device 30 is referred to as a “local mover”, and the data mover program 125 in the archive storage device 120 is referred to as a “remote mover”. "Mover program". File exchange is performed between the file storage device 30 and the archive storage device 120 via the local mover 37 and the remote mover 125.

  The local mover 37 reads the replication target file (actual file data and file metadata) from the LU 24 of the RAID system 20, and transfers the file to the archive storage device 120. The remote mover 125 receives the replication target file from the file storage device 30 and writes the file to the LU 114 of the RAID system 110.

  In addition, the local mover 37 deletes the replicated file in the LU 24 (strictly, the actual data of the file) when a certain predetermined condition is satisfied, and thereby the substantial migration of the replicated file. Is realized. Thereafter, when the local mover 37 receives a read request from the client / host 40 for the stub (metadata) of the file from which the actual data has been deleted, the file linked to the stub via the remote mover 125. (Actual data of the file) is acquired, and the acquired file is transmitted to the client / host 40. In the present embodiment, the “stub” is an object (metadata) associated with file storage location information (information indicating a link destination). The client / host 40 does not know whether the file is a stub.

  The kernel / driver 38 (127) performs general control and hardware such as schedule control of a plurality of programs (processes) operating on the file storage device 30 (archive storage device 120) and handling interrupts from hardware. Perform inherent control.

  The file sharing program 35 is a program that provides a file sharing service with the client / host 40 using a communication protocol such as CIFS (Common Internet File System) or NFS (Network File System).

  In the memory 41 of the client / host 40, an application 45, a file system 46, and a kernel / driver 47 are stored.

  The application 45 is software (application program) that the client / host 40 uses according to the purpose of work. The file system 46 and the kernel / driver 47 are substantially the same as the file system 36 (126) and the kernel / driver 38 (127) described above.

  The file system 36 (126) is a file system program and manages the file system configuration information 200. The file system configuration information 200 includes information on each file and directory (for example, information indicating the size and location of the file) and is stored in, for example, the OS LU 25 (115) and the memory 31 (121).

  FIG. 4 is a configuration diagram of file system configuration information according to the first embodiment.

  The file system configuration information 200 includes a super block 210, an inode management table 220, and a data block group 230. The super block 210 is a block that collectively holds file system information, and stores information such as the size of the file system and the free capacity of the file system, for example. The inode management table 220 is a table for managing an inode that is an example of file management information. In the file system 36 (126), one inode is associated with one directory and one file. Here, the inode corresponding to the directory is called a directory entry. The inode corresponding to the file can be accessed by tracing the file path using a plurality of directory entries.

  FIG. 5 is a configuration diagram of a directory entry according to the first embodiment. FIG. 5 shows a directory entry of the inode management table 220 used when accessing the file indicated by “/home/use-01/a.txt”.

  When accessing the file indicated by “/home/use-01/a.txt”, the inode corresponding to the inode numbers “2”, “10”, “15” is traced according to the path name of the file. The inode of the inode number “100” corresponding to the file is specified. Then, based on the inode of the inode number “100” corresponding to the file, the data block storing the actual data of the file is specified, and this data block is accessed.

  FIG. 6 is a configuration diagram of an inode corresponding to a file according to the first embodiment.

The inode 201 corresponding to the file is composed of a plurality of metadata. The types of metadata include file owner, file access right, file size, file storage position (data block addresses 1, 2, 3,...), And the like. For example, according to the line including the inode number “100” (the inode having the inode number “100”), as shown in FIG. Data).
(*) Data in a predetermined number (in this case, two) consecutive data blocks starting from the data block at address 100.
(*) Data in a predetermined number (two in this case) of consecutive data blocks starting from the data block at address 200.
(*) Data in a predetermined number (two in this case) of consecutive data blocks starting from the data block at address 250.

  Next, a detailed configuration of the inode management table will be described.

  FIG. 7 is a configuration diagram of an inode management table according to the first embodiment.

  The inode management information table 220 manages two types of entries, an inode 202 corresponding to a directory and an inode 201 corresponding to a file.

  The inode 202 corresponding to the directory has fields of an inode number 220a, an owner 220b, an access right 220c, a size 220d, a last access date / time 220e, a directory name 220f, and a child directory inode number 220g.

  The inode number 220a stores the inode number corresponding to this entry. The owner 220b stores the identification information of the owner of the directory corresponding to this entry. The access right 220c stores the access right for the directory corresponding to this entry. The size 220d stores the size of the directory corresponding to this entry. The last access date and time 220e stores the last access date and time for the directory corresponding to this entry. The directory name 220f stores the name of the directory (directory name) corresponding to this entry. The child directory inode number 220g stores an inode number corresponding to a directory (file) that is a child (directly below) of the directory corresponding to this entry.

  The inode 201 corresponding to the file includes an inode number 220a, an owner 220b, an access right 220c, a size 220d, a last access date / time 220e, a file name 220h, a data block address 1 220l, and a data block address 2 220m. , And a field of data block address 3 220n. Note that similar information is stored in fields indicated by the same reference numerals as the inode 202 corresponding to the directory. The file name 220h stores the file name of the file corresponding to this entry. Data block address 1 220l, data block address 2 220m, and data block address 3 220n store the address of the data block in which the actual data of the file corresponding to this entry is stored.

  In this embodiment, a new type of metadata is managed in the inode management table 220.

  FIG. 8 is a detailed configuration diagram of an inode management table according to the first embodiment.

  The inode 201 corresponding to the file further includes fields for a stubification flag 220i, a replication completed flag 220j, and a link destination 220k.

  The stubification flag 220i stores a stubification flag indicating whether or not the file corresponding to this entry (referred to as the target file in the description of FIG. 8) is stubbed. The stubbing flag is, for example, “ON” when the target file is stubbed, and “OFF” when the target file is not stubbed.

  The replicated flag 220j stores a replicated flag indicating whether or not the target file has been replicated. The replication completed flag is “ON” when the target file has been replicated, and is “OFF” when the target file is not replicated.

  The link destination 220k stores information (for example, URL (Uniform Resource Locator)) indicating the storage destination (link destination) in the Core 100 of the actual data of the target file.

  In this embodiment, a user who can connect to the file storage device 30 is managed, and a user management table 240 for session connection management is used to manage users who have made session connections. The user management table 240 for session connection management is stored in the memory 31 of the file storage device 30, for example. In addition, a user management table for session disconnection management having a similar configuration is used to manage users who disconnected sessions. The user management table for session disconnection management is also stored in the memory 31.

  FIG. 9 is a diagram illustrating a user management table and a user management table management method according to the first embodiment. FIG. 9 shows a user management table 240 for session connection management for managing users connected to a session. The user management table for session disconnection management for managing users disconnected from a session has the same configuration. In the management method, the user connected to the session in FIG. 9 may be read as the user who disconnected the session.

  As shown in the upper diagram of FIG. 9, the user management table 240 for session connection management stores entries including fields of a pointer 240a and a user 240b. The pointer 240a stores the entry number in the user management table 240. The user 240b stores the user name of the user corresponding to the entry (user identification information that can identify the user, such as a user ID).

  In the present embodiment, as shown in the lower diagram of FIG. 9, the user corresponding to the entry connected to the session after a predetermined time depending on whether or not the entry corresponds to the number indicated by the connection management pointer 250. It manages whether or not it is a certain user. That is, the user corresponding to the entry before the entry indicated by the connection management pointer is a user who has connected to the session after a predetermined time, and the user corresponding to the entry after the entry indicated by the pointer is This means that the user has not made a session connection after a predetermined time. The connection management pointer 250 is stored in the memory 31, for example.

  Management of users connected to a session using the user management table 240 for session connection management is performed as follows. First, when a user connects to a session, it is determined whether or not the entry storing the user name of the user is after the entry indicated by the pointer. The user name and the user name of the entry indicated by the pointer are swapped, and the pointer 250 is incremented by one. As a result, before the entry indicated by the pointer 250, entries including the user names of users who have made session connections after a predetermined time can be collected.

  For example, in the state shown in the upper diagram of FIG. 9 and when no user is connected to the session, when User A and User E make a session connection, the pointer is the initial value 0. Therefore, the user name at the position of the pointer is swapped, but since the position is the pointer, the user name does not move and the pointer becomes 1. Next, since UesrE is an entry after the entry indicated by the pointer, as shown in the lower diagram of FIG. 9, UserB and UserRE, which are user names at the pointer position, are swapped, and UserE is changed to the second entry. In addition to storing, 1 is added to the pointer, and the pointer is set to 2. Therefore, the user names of the users connected in the session, that is, UserA and UserE can be collected and managed in an entry before the entry indicated by the pointer.

  Next, processing performed in the first embodiment will be described.

  FIG. 10 is a flowchart of an access process according to the first embodiment. The access process is executed when an access process is performed by the user from the client / host 40 to the file storage device 30.

  When the file storage apparatus 30 receives the access process, the file storage apparatus 30 determines which type of the access process is (step S11).

  If it is determined in step S11 that the type of access processing is session connection to the file storage device 30 (step S11: session connection), the file storage device 30 requests a lock on the home directory of the user who requested the access processing. Is executed (step S12). Processing executed due to the lock request will be described later with reference to FIG.

  The file storage device 30 determines whether or not the lock is successful (step S13). As a result, when the lock is not successful (step S13: No), the file storage apparatus 30 advances the process to step S12.

  On the other hand, if the lock is successful (step S13: Yes), the file storage device 30 makes a request to obtain stub information corresponding to the directory and file under the user's home directory (step S14). Here, the stub information is an inode (entry) managed in the file system 126 of the archive storage device 120. The processing executed due to the stub information acquisition request will be described later with reference to FIG.

  Thereafter, the file storage device 30 creates a home directory based on the acquired stub information (step S15), executes data synchronization processing (see FIGS. 13 and 14) (step S16), and ends the access processing. .

  If it is determined in step S11 that the type of access processing is session disconnection for the file storage device 30 (step S11: session disconnection), the file storage device 30 performs processing at the time of session disconnection (step S17). ). For example, the file storage device 30 performs processing such as replication and stubbing of the home directory of the user who has requested access processing. Processing at the time of session disconnection will be described later with reference to FIGS.

  Next, the file storage device 30 executes an unlock request for the home directory (step S18). Processing executed due to the unlock request will be described later with reference to FIG. Thereafter, the file storage device 30 ends the access process.

  If it is determined in step S11 that the type of access processing is file read processing (step S11: read processing), the file storage apparatus 30 reads the file to be read in the inode management table 220 of the file system 36. It is determined whether or not this file is stubbed by referring to the inode (entry) corresponding to (step S19). Here, whether or not the file is stubbed can be determined by referring to the stubbing flag 220i of the inode 201. As a result, when the file is stubbed (step S19: Yes), the file storage device 30 executes a process of recalling the actual data of the file (step S20), and the process proceeds to step S21. . According to the process of recalling the file, the actual data of the file is stored in the data block of the LU 24, and the block address where the actual data is stored in the data block address of the inode 201 corresponding to the file of the inode management table 220 is stored. Recall processing for recalling actual file data will be described later with reference to FIG.

  On the other hand, if this file is not stubbed (step S19: No), that is, if the actual data of the file is stored in the LU 24, the file storage apparatus 30 advances the process to step S21.

  In step S21, the file storage device 30 reads the file entity based on the inode 201 of the file, that is, identifies the data block storing actual data from the inode 201, and reads the data from the data block. Thereafter, the file storage device 30 ends the access process.

  If it is determined in step S11 that the type of access process is a file write process (step S11: Write process), the file storage apparatus 30 creates a write target file in the inode management table 220 of the file system 36. It is determined whether or not this file is stubbed by referring to the inode (entry) 201 corresponding to (step S22). As a result, when this file is stubbed (step S22: Yes), the file storage device 30 executes a process of recalling the actual data of this file (step S23), and the process proceeds to step S24. . According to the process of recalling the file, the actual data of the file is stored in the data block of the LU 24, and the block address where the actual data is stored in the data block address of the inode 201 corresponding to the file of the inode management table 240 is stored. The process of recalling the actual data of the file will be described later with reference to FIG.

  On the other hand, if this file is not stubbed (step S22: No), the file storage apparatus 30 advances the process to step S24.

  In step S24, the file storage device 30 writes the actual data of the file based on the inode 201 of the file, that is, identifies the data block in which the actual data is stored from the inode 201, and stores the actual data for the data block. Write. Thereafter, the file storage device 30 changes the replication flag of the replication flag 220j of the inode 201 of this file to a replication flag (in this case, “OFF”) indicating that this file is not replicated (step S25). ) And the access process is terminated.

  FIG. 11 is a flowchart of the lock process according to the first embodiment.

  The lock process is executed when a lock request is executed by the file storage apparatus 30 in step S12 shown in FIG.

  Upon receiving the lock request, the archive storage device 120 of the Core 100 determines the name of the lock file (lock file name) for managing the lock of the home directory from the Edge name included in the lock request and the home directory name to be locked. The lock file for identifying and managing the lock of the same home directory, that is, the lock file including the same home directory name is searched (step S31). Here, the lock file is a file created on the CORE 100 side to identify the presence or absence of the lock state. When the home directory is locked, a lock file for the home directory is created and the home directory is unlocked. Then, the lock file for the home directory is deleted. By using the file name as the lock request source (Edge identification information) and the home directory name, it is possible to know who has locked which resource by file search. The lock file name may include the name of the user who made the lock request. The lock file is stored in the memory 121, for example.

  Next, the archive storage device 120 determines whether or not a lock file including the same home directory name has been found (step S32). As a result, when a lock file including the same home directory name is found (step S32: Yes), it means that the home directory of the home directory name is locked. Then, the result of the lock request is set as failure (step S34), the result of the lock request is returned to the file storage device 30 of Edge 10 (step S35), and the process is terminated.

  On the other hand, when no lock file including the same home directory name is found (step S32: No), the archive storage device 120 stores the lock file having the lock file name specified in step S31 in the memory 121, for example. Then, the lock request result is set as successful (step S33), and the lock request result is returned to the file storage device 30 of Edge 10 (step S35).

  The file storage device 30 that has received the result of the lock request returned in step S35 ends step S12 and proceeds to the next step. According to this lock processing, it is possible to appropriately perform lock control in units of home directories.

  The lock process may be performed at the first access to the file, not at the time of session connection.

  FIG. 12 is a flowchart of the unlocking process according to the first embodiment.

  The unlock process is executed when an unlock request is executed by the file storage apparatus 30 in step S18 shown in FIG.

  When receiving the unlock request, the archive storage apparatus 120 of the Core 100 uses the Edge name included in the unlock request and the name of the home directory to be locked from the name of the lock file (lock file name) for managing the lock of the home directory. ) Is specified, and a lock file with this lock file name is searched (step S41).

  Next, the archive storage device 120 determines whether or not a lock file with this lock file name has been found (step S42). As a result, when a lock file with this lock file name is found (step S42: Yes), the archive storage device 120 deletes this lock file and sets the result of the unlock request as success (step S43). Then, the result of the unlock request is returned to the file storage device 30 of Edge 10 (step S45), and the process ends.

  On the other hand, when the lock file having this lock file name is not found (step S42: No), the archive storage device 120 sets the result of the unlock request as failure (step S44), and the result of the unlock request. Is returned to the file storage device 30 of Edge 10 (step S45).

The file storage device 30 that has received the result of the unlock request returned in step S45 ends step S18 and proceeds to the next step. According to this unlock processing, it is possible to appropriately perform lock control in units of home directories.

  The unlock process may be performed not when the session is disconnected but when there is no access (read or write) to the file for a predetermined time or longer after replication.

  FIG. 13 is a flowchart of connected user management processing according to the first embodiment.

  The connected user management process corresponds to a part of the data synchronization process in step S16 shown in FIG.

  First, the file storage apparatus 30 determines whether or not the value of the user name position (entry order) of the user connected in the session in the user management table 240 for session connection management is greater than or equal to the value of the connection management pointer. .

  As a result, when the value of the position of the user name of the user connected to the session is equal to or greater than the value of the pointer (step S51: Yes), the file storage apparatus 30 stores the user name of the entry indicated by the pointer value in the user management table 240. And the user name of the entry storing the user name of the user connected in the session (step S52), 1 is added to the value of the pointer (step S53), and the process ends.

  On the other hand, when the value of the position of the user name of the user connected to the session is smaller than the value of the pointer (step S51: No), the file storage device 30 ends the process.

  With this process, the user names of the users connected in the session can be collected and managed in an entry before the entry indicated by the pointer in the user management table 240.

  FIG. 14 is a flowchart of the cache overwriting process according to the first embodiment.

  The cache overwriting process corresponds to a part of the data synchronization process in step S16 shown in FIG. This cache overwriting process is executed, for example, every predetermined time. Note that the cache overwriting process may be executed immediately after the connected user management process ends.

  The file storage device 30 sets the variable N to 0 (step S61), and determines whether or not the variable N is smaller than the number of users connectable to the file storage device 30 of Edge 10 (step S62). As a result, when the variable N is smaller than the number of users connectable to the file storage device 30 of Edge 10 (step S62: Yes), the file storage device 30 corresponds to the user name at the position of the variable N in the user management table 240. The home directory information of the user to be requested is requested to the archive storage device 120 (step S63), and the process proceeds to step S64. Here, the home directory information is information including inodes of files and directories under the user's home directory. The request for home directory information includes, for example, the name of the user's home directory.

  On the other hand, when receiving the request for home directory information, the archive storage device 120 acquires the home directory information of the user to be requested from the memory 121 (step S71), and the acquired home directory information is stored in the file storage. The data is transferred to the device 30 (step S72).

  The file storage device 30 acquires the home directory information transferred from the archive storage device 120, sets the home directory, and data cached in the memory 31 based on the home directory information, for example, the user's home directory The directory and file inode etc. are overwritten (step S64).

  Next, the file storage device 30 adds 1 to the variable N (step S65), and advances the process to step S62.

  On the other hand, if the variable N is not smaller than the number of users connectable to the file storage device 30 of Edge 10 (step S62: No), the cached data of all users connectable to the file storage device 30 is overwritten. Therefore, the file storage device 30 sets the pointer to 0, resets the user who has been connected (step S66), and ends the process.

  Here, in the connected user management process shown in FIG. 13, the user names of users who connected to the session after a predetermined time are managed in order from the top of the user management table 240, so in the cache overwriting process shown in FIG. 14. In this case, the cache of the user connected to the session is preferentially overwritten. That is, for example, in order to overwrite a large-sized file stored by the disconnected user, it is possible to appropriately prevent a delay in overwriting the data of the user connected to the session. Note that the user connected to the session includes, for example, a user who has moved from another Edge 10.

  FIG. 15 is a flowchart of the recall process according to the first embodiment.

  The recall process is executed according to the process of the file storage device 30 in step S20 or S23 shown in FIG.

  The file storage device 30 transmits an acquisition request (file acquisition request) of the actual data of the stubbed file to the archive storage device 120 of the Core 100 (step S81). The file acquisition request includes information on the storage destination (link destination) where the actual data to be acquired is stored. This link destination can be acquired from the link destination 220k of the inode 201 of the stubbed file.

  Upon receiving the file acquisition request, the archive storage device 120 acquires the actual data of the file to be acquired from the corresponding storage destination based on the storage destination of the file acquisition request (step S91), and stores the actual data of this file as a file The data is transferred to the storage device 30 (step S92), and the process ends.

  When the file storage device 30 acquires the actual data of the file, the file storage device 30 returns to the caller of the acquired actual data of the file, that is, the processing step of step S20 or S23 in FIG. 10 (step S82), and ends the recall processing. In step S20 or S23 of FIG. 10, the actual data of the returned file is stored in the data block of the LU 24, and the actual data is stored in the data block address (220l, etc.) of the inode 201 corresponding to the file of the inode management table 220. Is stored, and the stubification flag 220i is turned OFF.

  FIG. 16 is a flowchart of stub information acquisition processing according to the first embodiment.

  The stub information acquisition process is executed when a request for acquiring stub information is executed by the file storage apparatus 30 in step S14 shown in FIG.

  The file storage device 30 transmits a stub information acquisition request (stub information acquisition request) to the archive storage device 120 of the Core 100 (step S101). The stub information acquisition request includes information (for example, home directory name) that specifies a home directory from which stub information is acquired.

  Upon receiving the stub information acquisition request, the archive storage device 120 acquires inodes 202 of all directories and file inodes 201 (stub information) under the home directory based on information specifying the home directory (step S111). The inodes 201 and 202 are transferred to the file storage device 30 (step S112), and the process ends. Here, ON indicating that replication has been completed is set in the replication completed flag 220j of the inode 201 transferred to the file storage device 30, and the link destination where the actual data is stored is stored in the link destination 220k. ing.

  When the file storage device 30 acquires the inodes 201 and 202, the file storage device 30 returns to the calling source of the acquired stub information acquisition request, that is, the processing step of step S14 in FIG. 10 (step S102), and ends the stub information acquisition processing. As a result, the file storage apparatus 30 receives the inodes 201 and 202 of the directories and files under the home directory.

  Note that the stub information acquisition process may be executed not only when the session is connected, but also periodically, for example.

In addition, before executing step S101 in the stub information acquisition process, a file renaming process, a cached file invalidation process, and the like as shown in (1) to (4) below may be executed.
(1) The file storage device 30 transmits the inode number, file path name, and last update date and time of the file managed by the file system 36 to the archive storage device 120.
(2) The archive storage device 120 refers to the inode number and file path name of the file managed by the file system 126 and the inode number and file path name transmitted from the file storage device 30, and the inode number is the same. If the file path name is different, the file path name is changed (renamed).
(3) The archive storage device 120 refers to the inode number and the last update date / time of the file managed by the file system 126 and the inode number and the last update date / time transmitted from the file storage device 30, and the inode number is the same. If the last update date and time transmitted from the file storage device 30 is older than the last update date and time of the archive storage device 120, that is, if the file in the file storage device 30 is old data, the inode number is set to the file. The data is transmitted to the storage device 30.
(4) The file storage device 30 deletes the actual data of the file corresponding to the inode number transmitted from the archive storage device 120 and stubs the file.

  FIG. 17 is a flowchart of disconnected user management processing according to the first embodiment.

  The disconnected user management process is a part of the session disconnection process executed in step S17 shown in FIG.

  First, the file storage device 30 determines whether or not the value (entry order) of the user name position of the user who disconnected the session in the user management table for session disconnection management is equal to or greater than the value of the disconnection management pointer. The disconnection management pointer is stored in the memory 31, for example.

  As a result, if the value of the position of the user name of the user who disconnected the session is equal to or greater than the value of the pointer (step S121: Yes), the file storage device 30 stores the user of the entry indicated by the pointer value in the user management table 240. The name and the user name of the entry storing the user name of the user who disconnected the session are swapped (exchanged) (step S122), 1 is added to the value of the pointer (step S123), and the process ends.

  On the other hand, when the value of the position of the user name of the user who disconnected the session is smaller than the value of the pointer (step S121: No), the file storage device 30 ends the process.

  By this processing, the user name of the user who disconnected the session can be managed by collecting the entry before the entry indicated by the disconnection management pointer in the user management table for session disconnection management. That is, it is possible to arrange the users who disconnected their sessions during a predetermined period in order from the earliest time when the sessions were disconnected.

  FIG. 18 is a flowchart of the replication process (scheme A) according to the first embodiment.

  The replication process (method A) is a part of the process at the time of session disconnection executed in step S17 shown in FIG. 10, and is a process according to method A executed in conjunction with the disconnection user management process shown in FIG. is there. This replication process (method A) is executed, for example, at predetermined time intervals or at predetermined time zones. Further, the amount of data transmitted by one replication may be limited.

  The file storage device 30 sets the variable N to 0 (step S131), and determines whether the variable N is smaller than the number of users that can be connected to the file storage device 30 of Edge 10 (step S132). As a result, when the variable N is smaller than the number of users connectable to the file storage device 30 of Edge 10 (step S132: Yes), the file storage device 30 corresponds to the user name at the position of the variable N in the user management table 240. The replication of the file belonging to the user's home directory is executed (step S133). Specifically, the file storage device 30 stores the inode 201 (the inode in which the replication completion flag of the replication completion flag 220j is OFF) 201 and the actual data corresponding to the file that needs to be replicated among the files under the user's home directory. The data is transmitted to the archive storage device 120.

  In response to this, the archive storage device 120 acquires the inode of the file transmitted from the file storage device 30 and also acquires the actual data of the file (step S141). Next, the archive storage device 120 stores the acquired inode and actual data of the file in the inode management table 220 of the file system 126, stores the file entity in the LU 114, and stores the file entity in the link destination 220k of the acquired inode. A URL indicating the stored location is stored (step S142), a notification to the effect that data storage has been completed is transmitted to the file storage device 30, and the process ends. Here, since the URL indicating the storage location is stored in the link destination 220k of the inode 201, the file storage device 30 acquires the inode 201 and uses the link destination 220k. The actual data can be recalled appropriately.

  When the file storage device 30 receives a notification from the archive storage device 120 that the storage of data has been completed, the file storage device 30 turns ON to indicate that replication has been completed in the replication completed flag 220j of the inode 201 corresponding to the replicated file. Is stored in the link destination 220k, the URL indicating the storage location where the actual data of the file is stored is stored, 1 is added to the variable N (step S134), and the process proceeds to step S132. Note that the URL indicating the storage location where the archive storage device 120 stores the actual data of the file may be acquired from the archive storage device 120 before step S133, or the data storage from the archive storage device 120 may be performed. You may make it receive as a notification to the effect of having completed.

  On the other hand, when the variable N is not smaller than the number of users connectable to the Edge file storage device 30 (step S132: No), replication under the home directories of all users connectable to the file storage device 30 is performed. This means that replication has been executed for all the files that have not been set, so the file storage device 30 sets the pointer to 0 and removes all the users from the disconnected users (step S135), and ends the processing. To do.

  Here, in the connected user management process shown in FIG. 17, the user IDs of the users who disconnected the session are managed side by side from the top of the user management table 240. Therefore, in the process shown in FIG. Will be replicated preferentially. That is, among the users whose files are not replicated, the file of the user who has disconnected the session is the user who has not disconnected the session (the user who is connected to the session, or the user who has not connected or disconnected the session) ) Is replicated prior to (priority) files. Furthermore, by the processing shown in FIGS. 17 and 18, replication is performed in order from the file of the user whose session is disconnected earlier. Here, it is considered that a user whose session is disconnected earlier among users who are disconnected from the session is more likely to move to another Edge 10. Therefore, in the following, when this user makes a session connection with another edge 10, the file in the user's home directory can appropriately exist in the Core 100. Further, according to the above processing, for example, in order to replicate a large-sized file stored by a connected user, it is possible to appropriately prevent the data of the user who disconnected the session from being replicated within a certain time. Moreover, the data of each user may be replicated in any order, for example, in the order of priority for each user that is arbitrarily determined, regardless of the connected user management process shown in FIG.

  FIG. 19 is a flowchart of the replication processing (method B) according to the first embodiment.

  The replication process (method B) is another example of a part of the process at the time of session disconnection executed in step S17 shown in FIG. 10, and the disconnected user management process shown in FIG. 17 and the replication process shown in FIG. This is a process that may be executed instead of the process combined with (Method A). This replication process (method B) is executed, for example, when the session is disconnected.

  The file storage device 30 performs replication of files belonging to the home directory of the user who disconnected the session (step S151). Specifically, the file storage device 30 includes an inode 201 corresponding to a file that needs to be replicated among files under the user's home directory (an inode in which the application completion flag of the replication completion flag 220j is OFF) 201 and the file. Are transmitted to the archive storage device 120.

  In response to this, the archive storage device 120 acquires the inode of the file transmitted from the file storage device 30 and also acquires the actual data of the file (step S161). Next, the archive storage device 120 stores the acquired inode and actual data of the file in the inode management table 220 of the file system 126, and stores the file entity in the LU 114 (step S162), indicating that the storage of the data is finished. A notification is transmitted to the file storage device 30, and the process is terminated. Here, since the URL indicating the storage location is stored in the link destination 220k of the inode 201, the file storage device 30 acquires the inode 201 and uses the link destination 220k. The actual data can be recalled appropriately.

  When the file storage device 30 receives a notification from the archive storage device 120 that the storage of data has been completed, the file storage device 30 sets ON indicating replication completed in the replication completed flag 220j of the inode 201 corresponding to the replicated file, and the link destination The URL indicating the storage location where the archive storage device 120 stores the actual data of the file is stored in 220k, step S151 is ended, and the replication process (method B) is ended. Note that the URL indicating the storage location where the archive storage device 120 stores the actual data of the file may be obtained from the archive storage device 120 before step S151, or the data storage from the archive storage device 120 may be performed. You may make it receive as a notification to the effect of having completed.

  According to this replication process (method B), the user who has disconnected the session, that is, moved to another Edge 10 and appropriately stores the files under the home directory of the user who may access the file on the Core 100 side. Can do.

  FIG. 20 is a flowchart of replication processing (other than subordinates) according to the first embodiment.

  This replication process (other than subordinates) is a process of performing replication for files other than files under the user's home directory. This replication process (other than subordinates) is executed, for example, every predetermined time or when a user requests it.

  The file storage device 30 searches for a file that needs to be replicated from directories other than the home directory of each user (step S171). Next, the file storage device 30 performs replication of the file obtained by the search (step S172). Specifically, the file storage apparatus 30 stores an inode corresponding to a file that needs to be replicated in a file in a directory other than the user's home directory (an inode in which the replication completion flag of the replication completion flag 220j is OFF). 120, and the actual data of the file is transmitted.

  On the other hand, the archive storage device 120 acquires the inode of the file transmitted from the file storage device 30 and also acquires the actual data of the file. Next, the archive storage device 120 stores the acquired inode and actual data of the file in the inode management table 220 of the file system 126, stores the file entity in the LU 114, and notifies the file storage that the storage of the data is finished. It transmits to the apparatus 30, and a process is complete | finished.

  When the file storage device 30 receives a notification from the archive storage device 120 that the data storage has been completed, the file storage device 30 sets the inode replication flag 220j corresponding to the replicated file to “Yes” indicating that replication has been completed. The replication flag 220j of the inode 201 corresponding to the file that has been changed and replicated is set to ON indicating replication, and the URL indicating the storage location where the archive storage device 120 stores the actual data of the file is stored in the link destination 220k. (Step S173), the process ends.

  FIG. 21 is a flowchart of the stubbing process according to the first embodiment.

  The stubbing process is a part of the process at the time of session disconnection executed in step S17 shown in FIG. Note that the stubbing process may be executed every predetermined time.

  The file storage device 30 determines whether or not the capacity of the file system 36 is larger than a predetermined threshold (step S181). As a result, when the capacity of the file system 36 is larger than the predetermined threshold value (step S181: Yes), it means that the free capacity of the LU 24 is small, so the file storage apparatus 30 uses the replication flag 220j for replication. The completed flag indicates that replication has been completed, and stubbing is executed in order from the file corresponding to the inode 201 whose last access date / time 220e is the oldest (step S182). Specifically, the file storage device 30 deletes the actual data of the target file from the data block, and sets ON indicating that the stubbing flag 220i of the inode 201 is stubbed. Thereby, the free capacity of the LU 24 can be increased.

  Next, an information system according to the second embodiment will be described.

  First, the problem will be described.

  FIG. 22 is a diagram illustrating the problem.

  Here, for example, it is assumed that a large-scale meeting is held at the base X (Edge 10X), a large number of users gather from the other bases at the base X, and a large number of users access the files at the base X.

  In this case, when the user connects to the file storage device 30 at the site X using the client / host 40 and accesses the file, only the inode 201 (stub information) is stored in the file storage device 30. In many cases, the file storage device 30 executes a recall request for acquiring the actual file data to the archive storage device 120. Here, when a large number of users access a file, a large number of recall requests are transmitted to the archive storage device 120, and the actual data of the file, which is a response to the recall request, is transmitted. The load and the load on the archive storage device 120 are increased.

  In the information system according to the second embodiment, the problem shown in FIG. 22 is solved by implementation methods 1 to 3 described below.

  First, an outline of the realization method 1 will be described. The realization method 1 is a method in which a file is stored in advance in a destination site set by a user.

  In the information system according to the implementation method 1 of the second embodiment, a new configuration and a new process are added to the same configuration as the information system of the first embodiment illustrated in FIGS. 2 and 3. Hereinafter, differences from the first embodiment will be described.

  In the information system according to the realizing method 1, the archive storage device 120 newly stores the setting file 131.

  FIG. 23 is a configuration diagram of a setting file according to the second embodiment.

  The setting file 131 stores information related to the destination site to which the user moves. The setting file 131 is set in advance when the user uses the client / host 40, for example. The setting file 131 includes destination information 131a indicating the destination location (Edge), and time information 131b for specifying the time used at the destination location. The migration destination base information 131a is, for example, the IP address of the file storage device 30 at the migration destination base. The time information 131b is, for example, the travel time from the source base where the user is present to the destination base. Note that destination base information 131a and time information 131b may be set for a plurality of destinations.

  FIG. 24 is a diagram illustrating an overview of the realizing method 1 according to the second embodiment.

  When the user works at the source site (here, for example, site A) and disconnects the session, file replication is performed from the file storage device 30 to the archive storage device 120, and the session disconnection request is sent to the archive storage device 120. ((1) in FIG. 24).

  The archive storage device 120 refers to the setting file 131 in the home directory of the user who made the session disconnection request, and acquires the movement destination base information ((2-A) in FIG. 24). In the example of FIG. 24, it is assumed that the destination is the base C.

  Next, the archive storage device 120 transmits the file (including the actual data) in the home directory of the user who made the session disconnection request to the file storage device 30 of the destination base C ((2-B) in FIG. 24). ).

  Thereafter, when the user moves from the source base A to the destination base C (FIG. 24 (3)), the user makes a session connection to the file storage device 30 at the base C and refers to the file. Since the actual data of the file has been recalled for C, the user can quickly refer to the file ((4) in FIG. 24).

  Next, an outline of the realization method 2 will be described. The realization method 2 is a method of specifying a destination site based on a user's movement history and storing a file in advance in that site.

  In the information system according to the implementation method 2, the archive storage device 120 newly stores the base list 132. The site list 132 manages the movement history of the user with respect to each site.

  FIG. 25 is a configuration diagram of a base list according to the second embodiment.

  The base list 132 has entries including fields for a user name 132a, a destination base 132b, a user IP 132c, a movement count 132d, an average movement time 132e, and a data transfer rate 132f.

  A user name is stored in the user name 132a. In the movement destination base 132b, information for specifying the movement destination base (for example, the IP address of the file storage device 30 of the base) is stored. The user IP 132c stores the IP address (user IP) of the file storage device 30 at the site to which the user belongs. In this embodiment, for example, the user is assumed to belong to any one of a plurality of bases. The number of movements 132d stores the number of movements from the movement source base indicated by the user IP of the user IP 132c to the movement destination base indicated by the information of the movement destination base 132b. The average travel time 132e stores the average travel time (average travel time) from the travel source base indicated by the user IP of the user IP 132c to the travel destination base indicated by the information on the travel destination base 132b. The data transfer speed 132f stores a speed (data transfer speed) at the time of transferring data to the base indicated by the IP address of the destination base 132b.

  FIG. 26 is a diagram illustrating an overview of the implementation method 2 according to the second embodiment.

  When the user works at the source site (here, for example, site A) and disconnects the session, file replication is performed from the file storage device 30 to the archive storage device 120, and the session disconnection request is sent to the archive storage device 120. ((1) in FIG. 26).

  The archive storage device 120 refers to the base list 132, and the base indicated by the IP address of the destination base 132b of the entry with the maximum number of movements 132d of the user who has requested the session disconnection (here, at the base C). Is selected) ((2-A) in FIG. 26).

Next, the archive storage device 120 includes the files (including the actual data) in the home directory of the user who made the session disconnection request so that the transfer data amount of the selected one or more files satisfies the following Expression 1. One or more files are selected in order from the file having the latest access date and time (FIG. 26 (2-B)).
(Expression 1) Transfer data amount <Data transfer speed of the data transfer speed 132f of the base list 132 × Average moving time of the average moving time 132e of the base list 132

  Next, the archive storage device 120 transmits the selected one or more files to the file storage device 30 of the selected base (here, the base C) ((2-C) in FIG. 26).

  Thereafter, when the user moves from the source base A to the destination base C (FIG. 26 (3)), the user connects to the file storage device 30 at the base C in session and refers to the file. Then, since the actual data of one or more files has been recalled to the site C, the user can quickly refer to the files ((4) in FIG. 26).

  According to the realization method 2, since the file is moved in advance to a base where the user is likely to move, there is a high possibility that the file can be referred to quickly at the destination base. Further, according to the implementation method 2, the user does not need to set the setting file 131 and the like in advance.

  Next, an outline of the realizing method 3 will be described.

  In the realization method 2, based on the movement history of the user, the destination base is specified, and the file is stored in advance in the base. However, the distribution of the number of times a user moves to a base can be considered in various cases, such as when the user concentrates on a specific base or when the movement to each base is substantially uniform. For this reason, there is a possibility that an unfavorable case may occur if the file is only stored in a specific destination site.

  Therefore, in the realization method 3, the tendency regarding the movement of the user's base is analyzed based on the movement history of each user, and the transfer of the file to the file storage device 30 is controlled based on the movement tendency. I have to.

  In order to determine the tendency of each user to move to a base, each base is grouped based on the number of times the user has moved to that base.

  FIG. 27 is a diagram illustrating grouping of bases according to the second embodiment.

  In this embodiment, for example, each base is divided into two groups (group A and group B). As a method of dividing into groups, for example, as shown in FIG. 27, a predetermined number (for example, three) bases with the highest number of movements are set as group A, and other bases are set as group B. The grouping is not limited to this. For example, one or more bases having 50% or more of the most frequent movements may be group A, and the other bases may be group B.

  And in the implementation method 3, the total number of movements to the bases belonging to the group A (group A total movements number) is compared with the total number of movements to the bases belonging to the group B (total number of group B movements). The transfer method of the file to the file storage device 30 differs depending on the comparison result.

  For example, if the total number of movements of group A is equal to or greater than the total number of movements of group B, it is considered that there is a high tendency to move to the base of group A, so the file is transferred to the file storage device 30 of the base of group A. When the transfer method (transfer method A) is used and the total number of movements of group A is less than the total number of movements of group B, the movement tendency to each site is considered to be relatively uniform. A transfer method (transfer method B) for transferring a file to the apparatus 30 is assumed.

  In the realization method 3, the user list 133 is stored in the archive storage device 120 in order to manage the transfer method according to the movement tendency of each user.

  FIG. 28 is a configuration diagram of a user list according to the second embodiment.

  The user list 133 stores a record (entry) including fields of a user name 133a, a user IP 133b, a session disconnection time 133c, a transfer method 133d, and a bandwidth rate 133e.

  The user name 133a stores the user name of the user connected to the file storage device 30. The user IP 133b stores the IP address (user IP) of the file storage apparatus 30 at the site to which the user belongs. The session disconnection time 133c stores the time when the session is disconnected (session disconnection time). Using this session disconnection time, it is possible to calculate the travel time to another base. The transfer method 133d stores a file transfer method corresponding to the movement tendency of the entry to the user's base. In the present embodiment, either the transfer method A or the transfer method B is stored in the transfer method 133d. The bandwidth rate 133e stores the bandwidth rate allowed for the user corresponding to this entry for data transfer from the archive storage device 120.

  FIG. 29 is a diagram illustrating an outline of the transfer method A of the realizing method 3 according to the second embodiment. This transfer method A is executed when the user has a high tendency to move to the base of the group A.

  When the user works at the source site (here, for example, site A) and disconnects the session, file replication is performed from the file storage device 30 to the archive storage device 120, and the session disconnection request is sent to the archive storage device 120. ((1) in FIG. 29).

  The archive storage device 120 refers to the user list 133, refers to the transfer method 133d of the user who made the session disconnection request, and specifies the transfer method (here, it is assumed that the transfer method is A) (FIG. 29). (2-A)).

  Next, the archive storage device 120 preferentially selects one or more files (including actual data) in the home directory of the user who made the session disconnection request, with priority given to the file having the latest last access date and time, and selects the selected file in the group A. Is transmitted to the file storage device 30 of each base (in this case, the base B and the base C) ((2-B) in FIG. 29).

  Thereafter, when the user moves from the source base A to the base C belonging to the group A ((3) in FIG. 29), the user makes a session connection to the file storage apparatus 30 at the base C and refers to the file. Since the actual data of one or more files have been recalled to the site C, the user can quickly refer to the files ((4) in FIG. 29).

  As a result, when the user has a high tendency to move to the base of group A, the file is stored in the base of group A. Therefore, the file can be referred to quickly at the base of the destination. High nature.

  FIG. 30 is a diagram illustrating an outline of the transfer method B of the realizing method 3 according to the second embodiment. This transfer method B is executed when the user has a high tendency to move to each base relatively uniformly.

  When the user works at the source site (here, for example, site A) and disconnects the session, file replication is performed from the file storage device 30 to the archive storage device 120, and the session disconnection request is sent to the archive storage device 120. ((1) in FIG. 30).

  The archive storage device 120 refers to the user list 133, refers to the transfer method 133d of the user who made the session disconnection request, and specifies the transfer method (here, it is assumed that the transfer method is B) (FIG. 30). (2-A)).

  Next, the archive storage device 120 preferentially selects one or more files (including actual data) in the home directory of the user who has made the session disconnection request, with priority given to the file with the latest last access date and time. The file is transmitted to the file storage device 30 at the base ((2-B) in FIG. 30). Since the file is transmitted to all the bases, files having a data amount smaller than the data amount of the transfer method A are selected.

  Thereafter, when the user moves from the source base A to the destination base C (FIG. 30 (3)), the user makes a session connection to the file storage device 30 at the base C and refers to the file. Since the actual data of one or more files has been recalled for the site C, the user can quickly refer to the files ((4) in FIG. 30). Note that there is a high possibility that the file can be referred to quickly even if the user moves to any base.

  As a result, if the user has a tendency to move to each base relatively uniformly, the file is stored in each base, so the file can be referred to quickly at the destination base. High nature.

  Next, processing performed in the second embodiment will be described.

  FIG. 31 is a flowchart of Edge-side session disconnection processing according to the second embodiment.

  Edge side session disconnection processing is executed when the file storage apparatus 30 receives a session disconnection request from the client / host 40.

  The file storage device 30 executes a session disconnection process between the client / host 40 and the file storage device 30 (step S191). Next, the file storage device 30 performs replication and stubbing of the home directory of the user who has requested session disconnection (step S192). This process is the same as step S17 in FIG. 10 according to the first embodiment.

  Next, the file storage apparatus 30 determines whether or not the Edge 10 that has been disconnected from the session is the Edge 10 to which the user who requested the disconnection belongs (step S193).

  As a result, if Edge 10 whose session has been disconnected is Edge 10 to which the user belongs (step S193: Yes), the file storage device 30 requests the archive storage device 120 of Core 100 for processing at the time of session disconnection (step S194). ), The session disconnection process is terminated. On the other hand, when Edge 10 whose session has been disconnected is not its own Edge 10 (step S193: No), file storage device 30 ends the session disconnection process.

  FIG. 32 is a flowchart of processing when a session on the Core side is disconnected according to the second embodiment. Note that the flowchart in FIG. 32 collectively describes the processes in the implementation methods 1 to 3 for convenience, but actually corresponds to one of the implementation methods employed by the archive storage device 120. The processing of the part to be executed is executed.

  The session disconnection process on the Core side is executed when the archive storage apparatus 120 receives a request for the session disconnection process in step S194 of FIG. 31 from the file storage apparatus 30.

  When the archive storage device 120 adopts the implementation method 1, upon receiving the session disconnection processing request, the archive storage device 120 acquires the IP address and the movement time of the movement destination base from the setting file 131 ( In step S201), the acquired travel time is set to the variable “total travel time” (step S209), and the process proceeds to step S210.

  In addition, when the archive storage device 120 adopts the implementation method 2, when the archive storage device 120 receives a session disconnection processing request, the archive storage device 120 moves in the record corresponding to the user name to be disconnected from the site list 132. The record having the maximum number of movements 132d is acquired (step S202), the movement average time of the average movement time 132e of the record is set to the variable “total movement time” (step S209), and the process proceeds to step S210. .

  Further, when the archive storage device 120 adopts the realization method 3, when the archive storage device 120 receives the session disconnection processing request, the user IP of the user who has requested disconnection is set from the user list 133. The selected record is selected (step S203). Next, the archive storage device 120 records the session disconnection time included in the session disconnection process request at the session disconnection time 133c of the selected record (step S204). Next, the archive storage apparatus 120 identifies the transfer method with reference to the transfer method 133d of the selected record (step S205), and determines whether the transfer method is the transfer method A or the transfer method B (step S205). Step S206).

  As a result, when the transfer method is transfer method A (step S206: transfer method A), records of locations belonging to grape A corresponding to the user are acquired from the location list 132 (step S207), and all acquired The sum of the average movement time of the average movement time 132e of the record is set in the variable “total movement time” (step S209), and the process proceeds to step S210.

  On the other hand, when the transfer method is transfer method B (step S206: transfer method B), all records corresponding to the user who requested disconnection are acquired from the site list 132 (step S208), and all the acquired records are recorded. The sum of the average travel times of the average travel time 132e is set in the variable “total travel time” (step S209), and the process proceeds to step S210.

  In step S210, the archive storage device 120 sets 0 to the variable “transfer data amount_TMP”. Next, the archive storage device 120 determines whether or not (Expression 2) variable “transfer data amount_TMP” <band speed × variable “total movement time” is satisfied (step S211). Here, the bandwidth speed is the value of the bandwidth speed 133e of the record of the user who requested the disconnection of the user list 133 in the implementation method 3, and is a preset bandwidth speed in the implementation method 2 or the implementation method 1.

  As a result, when (Formula 2) is satisfied (step S211: Satisfaction), the archive storage device 120 sets the value of the variable “transfer data amount_TMP” to the variable “transfer data amount” (step S212). . Next, the archive storage device 120 acquires a new file next to the file whose last access date / time 220e is reflected in the transfer data amount among the files belonging to the home directory of the user who has requested disconnection (Step S120). S213). If the file reflected in the transfer data amount does not exist, the file having the latest last access date and time of the last access date and time 220e is acquired from the files belonging to the home directory of the user who requested disconnection.

  Next, the archive storage apparatus 120 sets a value that reflects (adds) the file size acquired in step S213 to the variable “transfer data amount” in the variable “transfer data amount_TMP” (step S214), and performs processing. Advances to step S211.

  If (Equation 2) is not satisfied in step S211, (step S211: not satisfied), it means that the data reflected in the transfer data amount_TMP cannot be transferred within the time indicated by the total movement time. Therefore, the archive storage device 120 transmits the file reflected in the current variable “transfer data amount” (the file reflected when it was determined that (Equation 2) was satisfied in the determination in the previous step S211). The file is selected as a target file (step S215).

  Next, the archive storage device 120 determines the data transfer rate (step S216). For example, the data transfer rate is obtained by dividing the value of the variable “transfer data amount” by the average movement time of the average movement time 132e of the record corresponding to the movement destination base in the base list 132.

  Next, the archive storage device 120 compares the determined data transfer rate with the actual transfer rate, and controls the amount of data to transfer the transmission target file to the transmission target file storage device 30 (step S217). If data cannot be transferred from the archive storage device 120 to the file storage device 30 due to the operation of the archive storage device 120, polling by the file storage device 30 as described below is used to perform the file storage device 30. Data may be transferred to

  Next, an example in which the file storage apparatus 30 acquires file data from the archive storage apparatus 120 by polling will be described.

  FIG. 33 is a diagram illustrating an overview of data acquisition processing by polling according to the second embodiment.

  When the user works at the source site (here, for example, site A) and disconnects the session, file replication is performed from the file storage device 30 to the archive storage device 120, and the session disconnection request is sent to the archive storage device 120. ((1) in FIG. 33).

  The archive storage device 120 determines a file transfer destination base and a file to be transferred ((2) in FIG. 33). Here, it is assumed that, for example, the base B, the base C, and the base D are determined as file transfer destinations.

  Next, the archive storage device 120 sets the determined file to be transferred in the queue for the destination site of the file in the transmission data queue 140 ((3) in FIG. 33). In this example, the file data to be transferred is set in the queues for the sites B, C, and D.

  Thereafter, the file storage device 30 at each base performs polling to acquire data of the file set in its own queue in the archive storage device 120 ((4) in FIG. 33), and the data acquired in the LU 24 Is stored.

  By this data acquisition processing, file data can be appropriately transmitted to the file storage device 30 that cannot transfer data due to the operation of the archive storage device 120.

  FIG. 34 is a flowchart of data acquisition processing by polling according to the second embodiment.

  The file storage device 30 of Edge 10 transmits a confirmation request as to whether or not there is data in the queue for its own site to the archive storage device 120 when it is time to perform polling (step S221).

  When the archive storage device 120 receives a confirmation request as to whether or not there is data in the queue, whether there is data in the queue corresponding to this confirmation request, that is, the queue for the base of the file storage device 30 (for own use). It is checked whether or not (step S231), and the check result is transferred to the file storage device 30 (step S232).

  Upon receiving the check result, the file storage device 30 determines whether there is data in its own queue based on the check result (step S222). As a result, when there is data in its own queue (step S222: Yes), the file storage device 30 recalls the file data in the queue (step S223).

  That is, the file storage apparatus 30 transmits a file transfer request to the archive storage apparatus 120. When receiving the file transfer request, the archive storage device 120 acquires the file data corresponding to the transfer request from the queue (step S233), and transfers the file data to the file storage device 30 (step S234). When the file storage apparatus 30 acquires the file data, the file storage apparatus 30 stores this data in the LU 24 and ends the data acquisition process.

  On the other hand, when there is no data in its own queue (step S222: No), the file storage apparatus 30 ends the data acquisition process.

  FIG. 35 is a flowchart of Edge-side session connection processing according to the second embodiment.

  The session connection processing on the Edge side is executed when a session connection request is received from the client / host 40 to the file storage device 30 by the user.

  The file storage device 30 performs session connection with the client / host 40 (step S251). Next, the file storage device 30 requests the archive storage device 120 to acquire stub information of the user's home directory (step S252). As a result, home directory stub information can be acquired from the archive storage device 120. Next, the file storage device 30 creates a home directory based on the acquired stub information (step S253).

  The file storage device 30 determines whether or not the edge-connected Edge 10 (Edge 10 to which the session-connected file storage device 30 belongs) is the Edge 10 to which the connected user belongs (step S254). As a result, when the Edge 10 connected to the session is the Edge 10 to which the connected user belongs (step S254: Yes), the file storage apparatus 30 ends the process.

  On the other hand, when Edge 10 connected to the session is not Edge 10 to which the connected user belongs (step S254: No), the file storage device 30 transmits a session connection processing request to the archive storage device 120 (step S255), and processing Exit. Upon receiving the session connection processing request, the archive storage device 120 executes the session connection processing on the Core side shown in FIG.

  FIG. 36 is a flowchart of the session connection processing on the Core side according to the second embodiment.

  The session connection processing on the Core side is executed when the archive storage device 120 receives a session connection processing request from the file storage device 30. The session connection processing request includes the user name of the user who requested the session connection, the IP address of the connected base, the session connection time, and the like.

  The archive storage device 120 refers to the user list 133 and selects a record corresponding to the name of the user who made the session connection request (step S261). Next, the archive storage device 120 refers to the site list 132, the destination site of the destination site 132b is the IP address of the connected site included in the session connection processing request, and the user name of the user name 132a and The user IP of the user IP 132c identifies the record that is the user name of the user name 133a and the user IP of the user IP 133b of the record acquired in step S261 (step S262).

  Next, the archive storage device 120 calculates the average moving time according to the following (Equation 3), and updates the average moving time of the average moving time 132d of the identified record (step S263). (Expression 3) Average moving time = ((Session connecting time during session connection processing request−Session cutting time 133c of the record selected in step S261) + Average of average moving time 132e of the record specified in step S262 Travel time) / 2

  Next, the archive storage device 120 adds 1 to the number of movements of the identified number of movements 132d of the record (step S264). Thereby, the average movement time and the number of movements according to the movement of the actual user's base are reflected in the user list 132.

  The processing after step S264 differs depending on the implementation method employed. Here, in the implementation method 1 or the implementation method 2, the archive storage device 120 ends the session connection process. On the other hand, in the case of the implementation method 3, the archive storage device 120 advances the process to step S266.

  In step S266, the archive storage device 120 divides the destination site of each destination site 132b into a group A and a group B based on the record corresponding to the user name connected in the session in the site list 132.

  Further, based on these records, the archive storage device 120 is divided into the total number of movements 132d (total number of movements of group A) of the records corresponding to the movement destination bases divided into group A and group B. The total number of movements 132d (total number of group B movements) of the number of movements 132d of the record corresponding to the destination site is calculated, and it is determined whether the total number of group A movements is greater than the total number of B group movements (Step S267).

  As a result, when the total number of group A movements is larger than the total number of group B movements (step S267: Yes), the archive storage apparatus 120 sets the transfer method A to the transfer method 133d of the record selected in step S261. (Step S268), and the process ends.

  On the other hand, when the total number of group A movements is not larger than the total number of group B movements (step S267: No), the archive storage device 120 sets the transfer method B to the transfer method 133d of the record selected in step S261. (Step S269), and the process ends. By this processing, it is possible to appropriately determine which one of the transfer method A and the transfer method B is used according to the movement tendency of the user's base.

  Although several embodiments have been described above, these are examples for explaining the present invention, and are not intended to limit the scope of the present invention only to these embodiments. That is, the present invention can be implemented in various other forms.

10 Edge, 30 File storage device, 100 Core, 120 Archive storage device.

Claims (15)

An interface for communicating with multiple users and remote file servers;
A storage device connected to the interface for storing the data of the files of the plurality of users in a storage device, a replication process for replicating the data of the files in the storage device to the remote file server, and a session disconnection request from the user And a processor for receiving
In the replication process, the processor replicates file data to the remote file server in the order of users with a fast session disconnect request within a predetermined time. 2. The file server according to claim 1, wherein when receiving a session connection request from a user, the processor acquires information on the home directory of the user from the remote file server. The processor stubs a file stored in the storage device,
If the processor receives an access request from a user,
If the file related to the access request is not stubbed, the data of the file is read from the storage device and provided to the user,
The file according to claim 1 or 2, wherein if the file related to the access request is stubbed, the file data is acquired from the remote file server and the file data is provided to the user. file server. The file server according to claim 1, wherein the processor performs the replication process periodically. When the processor receives a session connection request from a user, the processor includes an identifier of the user and a user identifier indicated by the pointer of the user management information having a pointer indicating the user who transmitted the session disconnection request within the predetermined time. If the identifier of the user who transmitted the session disconnection request is lower, the user identifier indicated by the pointer is swapped with the identifier indicating the user who transmitted the session disconnection request, and the position of the pointer is one. The file server according to any one of claims 1 to 4, wherein the file server is lowered. 6. The file server according to claim 5, wherein, when data of a file of a certain user is replicated, the certain user is excluded from a user who has made a session disconnection request in the user management information. When the processor receives a session connection request from a certain user, or when accessing the data of a certain user's file for the first time, the processor sends a lock request for the certain user's home directory to the remote file server. The file server according to claim 1, wherein the file server is characterized in that When the processor receives the session disconnection request from the certain user or when there is no access from the certain user for a certain period of time, the processor transmits an unlock request for the home directory of the certain user to the remote file server. The file server according to claim 7. A plurality of local file servers including the file server according to any one of claims 1 to 8;
A remote file server connected to the plurality of local file servers. An information processing system control method comprising a plurality of local file servers and a remote file server connected to the plurality of local file servers,
Storing data of files of a plurality of users in a storage device;
Performing a replication process for replicating a file in the storage device to the remote file server;
Receiving a session disconnection request from the user,
A method of controlling an information system, wherein in the step of performing the replication process, file data is replicated to the remote file server in the order of users with a fast session disconnect request within a predetermined time. 11. The information system control method according to claim 10, wherein when a session connection request is received from a user, information on the home directory of the user is acquired from the remote file server. Stubbing a file stored in the storage device;
When an access request is received from a user, the following steps (a) and (b) are executed. (A) If the file related to the access request is not stubbed, the data of the file is read from the storage device. Provide to the user,
(B) If the file relating to the access request is stubbed, the file further includes obtaining the data of the file from the remote file server and providing the user with the data of the file. The control method of the information system of 10 or 11. When a session connection request is received from a user, the session disconnection is more than the user identifier indicated by the user management information having the user identifier and the pointer indicating the user who transmitted the session disconnection request within the predetermined time. If the identifier of the user who transmitted the request is lower, the identifier of the user indicated by the pointer and the identifier indicating the user who transmitted the session disconnection request are swapped, and the position of the pointer is lowered by one. The method for controlling an information system according to any one of claims 10 to 12. 14. The method of controlling an information system according to claim 13, wherein, when data of a file of a certain user is replicated, the certain user is excluded from a user who makes a session disconnection request in the user management information. When a session connection request is received from a certain user, or when the user's data is first accessed, a lock request for the user's home directory is sent to the remote file server;
A step of transmitting an unlock request for the home directory of the certain user to the remote file server when a session disconnection request is received from the certain user or when there is no access from the certain user for a certain period of time. The method of controlling an information system according to claim 10, wherein:

Images