WO2015056352A1 - ファイル管理方法 - Google Patents

ファイル管理方法 Download PDF

Info

Publication number
WO2015056352A1
WO2015056352A1 PCT/JP2013/078374 JP2013078374W WO2015056352A1 WO 2015056352 A1 WO2015056352 A1 WO 2015056352A1 JP 2013078374 W JP2013078374 W JP 2013078374W WO 2015056352 A1 WO2015056352 A1 WO 2015056352A1
Authority
WO
WIPO (PCT)
Prior art keywords
capacity
file
user
physical
storage device
Prior art date
Application number
PCT/JP2013/078374
Other languages
English (en)
French (fr)
Inventor
和正 松原
光雄 早坂
仁志 亀井
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to US14/423,762 priority Critical patent/US20160034476A1/en
Priority to PCT/JP2013/078374 priority patent/WO2015056352A1/ja
Publication of WO2015056352A1 publication Critical patent/WO2015056352A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/11—File system administration, e.g. details of archiving or snapshots
    • G06F16/122—File system administration, e.g. details of archiving or snapshots using management policies
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/13—File access structures, e.g. distributed indices

Definitions

  • the present invention relates to a file management method.
  • this problem is remarkable when big data analysis is performed using a cloud service.
  • calculation resources for cloud services are calculated based on computer performance and usage time, and storage resources are often calculated based on data capacity and recording period. For this reason, when the data capacity is increased, the total cost of the storage resource is more dominant than the calculation resource. Therefore, when the big data is analyzed using the cloud service, the cloud service use cost becomes enormous.
  • Patent Document 1 enables the provision and use of resources owned by users among users. At this time, the user who receives the resource obtains ownership of the provided resource. Therefore, even if the user who provided the resource wishes to collect the resource, there is a problem that the resource cannot be collected because the ownership of the resource is owned by another user.
  • an object of the present invention is to make it possible to collect resources provided by the accommodation while allowing the unused area to be accommodated.
  • a file management method is a file management method for storing a certain number of redundant files from a client to a storage apparatus, and a first step of receiving an additional file from the client to the storage apparatus; A second step of comparing the capacity of the additional file with the unused physical capacity of the storage device, and if the capacity of the additional file is larger than the unused physical capacity, the redundancy number of the already stored file is calculated. A third step of changing to increase the unused physical capacity and storing the additional file in the storage device.
  • the file management method allocates a physical allocation capacity of a storage device to each of a plurality of users, enables lending and borrowing of the allocated physical allocation capacity, and provides a certain number of redundancy from the user's client to the storage device.
  • a file management method for storing only duplicates the step of receiving an additional file from the client to the storage device, the capacity of the additional file, and the first user who owns the additional file already stored And adding the capacity of all the files, comparing the added capacity with the capacity obtained by subtracting the lent capacity from the physical allocated capacity allocated to the first user, and Of the already stored file of the borrowed user Change the long number, and having the steps of: storing the additional files to the vacated volume by changing the number of redundant.
  • the provided area can be recovered by changing the redundancy number.
  • a system that redundantly saves files in three physical volumes in the storage apparatus will be described as an example. This is an example in which the number of saved files with the same contents is set as a redundant number, and a flexible relationship is implemented in the form of a group, and unused capacity is automatically distributed within the group.
  • the second embodiment is an example of lending / collecting each user individually instead of the distribution in the group of the first embodiment.
  • the third embodiment will be described with an example of a system that stores files in three cloud storages.
  • the redundant number of files is used as an index
  • availability information hereinafter referred to as SLA
  • SLA availability information defined by the Service Level Agreement
  • Example 1 will be described with reference to FIGS.
  • an administrator allocates a capacity of a storage device to each user
  • an operation when a file is stored exceeding the capacity allocated to the user (hereinafter, logical allocation capacity) will be described.
  • the actual storage area (physical allocation area) allocated to each user has a redundant number of times that of the logical allocation area for redundant storage.
  • processing for saving a file by reducing the number of redundancy as a group and securing an unused physical allocation area when the initial logical allocation area is exceeded (2) redundancy In the case where the number decreases, a process for complementing the redundant number is held by borrowing unused physical allocation areas from other users.
  • FIGS. 1A and 1B show operations of lowering the redundant number when used exceeding the capacity allocated to the user, and borrowing the capacity from other users to complement the redundant number.
  • the capacity of the initial physical volume (9 blocks in the figure) assigned to each user is within the capacity, the redundancy number is reduced, but it is guaranteed that it can be stored.
  • # 1 to 8 will be described in order.
  • the administrator provides logical volumes for three blocks to users A and B, respectively. Since one logical volume block is tripled by default, there are three physical volume blocks. Each user changes the number of redundancy, provides an unused area, and collects the area within the physical volume of 9 blocks in total.
  • # 2 the case is shown where each user saves data within the allocated capacity.
  • the user A shows a case where the capacity is borrowed from the user B and saved beyond the initially allocated area. User A borrows the capacity of 1.5 blocks from User B and uses it as his own block in order to store data for 4.5 blocks of the physical volume.
  • user B shows the case of storing data for two physical volumes. Since user B lends 4.5 blocks to user A, he has only 4.5 blocks of physical volume, so he collects 1.5 blocks of physical volume from user A. At this time, in order to return 1.5 blocks of the physical volume, the user A changes some blocks from triple to double. Similarly, for # 5, user B collects 3 blocks from user A in order to save data for 3 physical volumes. Since user B is stored within the initially allocated capacity, all are tripled. On the other hand, the user A has stored more than the initially allocated capacity, and since there is no area to borrow, the user A has stored it in a duplex manner. Thus, the function of lending and collecting the capacity between users is provided.
  • FIG. 2 is a diagram showing an example of the configuration of a file storage system that redundantly stores files in the volume of the storage device.
  • the gateway 100 is a computer that provides a file storage service to the client 300. For this reason, the gateway 100 transfers files between the client 300 and the storage apparatus 400.
  • the CPU 110 executes a processing unit (program) stored in the memory 140.
  • the memory 140 stores a processing unit (program) and tables for the file storage service.
  • the processing units stored in the memory 140 are a data management unit 141, a redundancy number calculation unit 142, and a capacity collection unit 145.
  • the tables are a user management table 500 and a file management table 600. Further, the memory 140 has an area such as a work area necessary for execution of each processing unit.
  • the volume 120 stores a stub file 121.
  • the stub file 121 holds a file ID for each user.
  • the I / F 130 transmits and receives files between the client 300 and the storage apparatus 400. Management information is transmitted and received between the management terminal 200 and the client 300.
  • each processing unit may be an independent hardware that performs the same operation as the CPU 110 executes a program instead of the program executed by the CPU 110.
  • the management terminal 200 can acquire management information of the gateway 100 and the storage apparatus 400 as necessary, and is a terminal for managing the gateway 100, and is an I / F 230 for connecting to a network and an operation screen, It is a computer having a memory 240 and an internal communication path connecting them.
  • the memory 240 stores a processing unit (program) and data.
  • the processing unit is, for example, the gateway management unit 241.
  • the operation screen 250 inputs / outputs management information of the gateway 100 via the management terminal 200.
  • the client 300 is a computer used by a user who uses the file storage service provided by the gateway 100, and includes an I / F 230 for connecting to a network and an operation screen, a memory 240, and an internal connection for connecting them.
  • the operation screen 350 inputs / outputs management information of the gateway 100 via the client 300.
  • the storage apparatus 400 provides a file storage service (write, read, update, delete, etc.) in response to an instruction from the gateway 100. Therefore, the storage apparatus 400 possesses a single / multiple volume 401 for storing a file. A file ID for identifying the file is used for writing and reading the file. The gateway 100 attaches a unique file ID to each file.
  • the client 300 transmits the file to the gateway 100.
  • the gateway 100 attaches a unique file ID to the received file and transmits it to the storage apparatus 400.
  • the gateway 100 holds, as stub information, a correspondence between a file ID and path information indicating a file storage location for each user. By arranging the file in the storage device in this manner, when the client 300 reads the file, the client 300 may refer to the stub information.
  • FIG. 3 is a diagram illustrating an example of the user management table 500.
  • the user management table 500 is a table for managing allocation information, file priority information for reducing the redundancy number, and accommodation information.
  • the user ID 501 is an identifier for managing a file stored in the storage apparatus 400 for each user ID.
  • a logical allocation capacity 502 indicates a logical capacity allocated by the administrator.
  • the physical allocation capacity 503 is a capacity obtained by multiplying the initial number of redundancy assumed by the administrator and the logical allocation capacity.
  • the physical use capacity 504 indicates the capacity used by the user in the physical allocation capacity.
  • the interchangeable (unused) capacity 505 indicates a capacity obtained by subtracting the currently used capacity from the physical allocation capacity, and indicates the maximum capacity that can be provided to other users when belonging to the accommodation group.
  • the total file size 506 indicates the total number of files excluding redundant files.
  • the physical use capacity 507 at the time of upper limit redundancy indicates the amount of capacity used when all files possessed by the user are set to the upper limit redundancy number set in the file. If this capacity exceeds the physical allocation capacity, it is necessary to allow the capacity to be accommodated by other users, or to reduce the redundancy number of some files to fall within the physical allocation capacity.
  • the lower limit redundant number physical use capacity 508 indicates the amount of capacity used when all files owned by the user are set to the lower limit redundant number set in the file. This value is a limit value that prevents the user's physical usage from being exceeded because all files owned by the user must be held within the physical allocation capacity when the capacity cannot be borrowed from another user.
  • the initial upper limit redundancy number 509 and the initial lower limit redundancy number 510 respectively indicate the initial upper limit redundancy number and the lower limit redundancy number set in the added file.
  • the initial compression availability 511 indicates whether or not the file is automatically compressed when the file is written.
  • the redundancy number lowering priority 512 indicates priority information for determining in which order to sort when reducing the redundancy number. For example, the strength of sorting is determined for the user A in the order of priority information, size, access date / time, and creation date / time.
  • the size [large] indicates that the redundancy number is preferentially reduced from the largest size.
  • the accommodation group 513 indicates that the available (unused) capacity possessed by the user can be provided to users belonging to the same group.
  • the in-group total accommodation capacity 514 indicates a value obtained by summing up the available (unused) capacity of all users belonging to the same group.
  • the in-group use available capacity 515 indicates the capacity borrowed from the unused capacity of the users belonging to the same group that the users who use exceeding the physical allocation capacity.
  • the unused unused capacity 516 within the affiliated group indicates a capacity that is not used by other users among the affiliated group total interchangeable capacity 514.
  • the lending / borrowing capacity 517 is used in the second embodiment and will be described later, and may not be the first embodiment.
  • FIG. 4 is a diagram showing an example of the file management table 600.
  • the user ID 601 is an identifier for managing a file stored in the storage apparatus 400 for each user ID.
  • the file ID 602 is a file identifier that uniquely identifies a file stored in the storage apparatus 400.
  • the file size 603 indicates the size of the file itself that does not consider redundancy.
  • the access date / time 604 indicates the date / time of the last access.
  • Creation date 605 indicates the creation date.
  • the current redundancy number 606 indicates how many times the corresponding file is made redundant.
  • the total file size 607 indicates the amount of physical capacity used by adding the redundancy.
  • the priority 608 is used as a first index when changing the redundancy number.
  • the number of redundancy is reduced preferentially from Low in three stages of Low, Middle, and High.
  • the upper limit redundancy number 609 indicates the maximum redundancy number that a file can be made redundant.
  • the lower limit redundancy number 610 indicates the minimum number of redundancy to be maintained when the redundancy number decreases.
  • Compressibility 611 indicates whether the file can be compressed.
  • the compressed state 612 indicates whether the compressed state or the uncompressed state.
  • the file arrangement information 613 indicates a location written in the storage apparatus 400.
  • FIG. 5 is a diagram showing an example of a processing flowchart in the file writing of the data management unit 141 of the gateway 100. This example shows a case where a group is created by setting interchange of unused capacity between users. In this group, if there is a capacity that can be accommodated, the capacity is automatically distributed to each user who can no longer be stored with the upper limit redundancy number based on the ratio of the excess amount.
  • the data management unit 141 (execution of the program of the data management unit 141 by the CPU 110) acquires a file write request and file information from the client 300.
  • the user ID is user A
  • the file is an additional file (S10).
  • the data management unit 141 confirms whether the user A can save the additional file.
  • it is assumed that the existing file and the additional file are the lower limit redundancy number it is determined whether or not the value of the physical allocation capacity 503 of the user A is exceeded.
  • S12 When not exceeding, it progresses to S12, and when exceeding, it progresses to S17 (S11).
  • the determination as to whether or not it includes not only the determination based on a mathematically exact comparison but also the determination as to whether it can be stored in terms of capacity, including errors in numerical expression on a computer. The determination in the following description is also the same.
  • the data management unit 141 refers to the user management table 500 and sets the initial state of the file (S12). Next, the data management unit 141 uses the redundancy number calculation unit 142 to set the file redundancy number of the user A and the users belonging to the same group (S13). Then, the file is written in the storage device based on the changed redundancy number of the file (S14), and the file management table and the user management table are updated (S15). Here, if there is a change in the number of redundant files, the user is notified (S16). Even if the existing file and the additional file are set to the value of the lower limit redundancy number, if they do not fall within the value of the physical allocation capacity 503, the capacity is insufficient and the writing fails (S17).
  • FIG. 6 is a diagram showing an example of a processing flowchart of the redundancy number calculation unit 142 of the gateway 100, and shows details of the redundancy number determination process (S12) of FIG.
  • the capacity when it is assumed that the additional file is set to the upper limit redundancy number is compared with the capacity of the unused capacity in the group to which the user management table 500 belongs (hereinafter referred to as unused capacity) 516. If the additional file is smaller than the unused capacity 516, the process proceeds to S21. If it is larger, the process proceeds to S22 (S20).
  • the additional file can be stored with the upper limit redundancy number within the capacity obtained by adding the value of the physical allocation capacity 503 possessed by the user A and the value of the unused interchange capacity 516, the additional file is set to the upper limit redundancy number and stored ( S21). In S21, all the files that have already been saved may or may not be changed to the maximum redundancy number.
  • S27 the same process as S23 is performed (S27), and the total capacity is set as the pre-distribution capacity (S28).
  • the distribution capacity is determined from the excess amount of each excess user and the pre-distribution capacity (S29). For each excess user, the capacity (target capacity) that can store the file is designated, and the redundant number adjustment processing is performed. At this time, the user A is also included in the redundant number adjustment processing (S30).
  • FIG. 7 is a diagram showing an example of a processing flowchart of the capacity collection unit 145 of the gateway 100.
  • the redundant number is adjusted so as to be within the target capacity for the target user, which is the details of S26 and S30 in FIG.
  • the number of redundant files is decreased from the maximum number of redundant items in order from the highest priority of the list, and the number of files is repeatedly reduced until the collection amount is secured.
  • the user who adjusts the redundant number acquires the value of the redundant number lowering priority 512 in the user management table 500, sorts all the files owned by the user, and creates a list (S40). It is determined whether the current redundancy number of the highest priority file is the lower limit redundancy number (S41).
  • the redundancy number is lowered by one level (S42). If it is the lower limit redundancy number, the process proceeds to S43 without changing the redundancy number.
  • the highest priority file is set at the end of the list (priority is lowest) (S43). It is determined whether the area for the target area (recovered amount) has been secured by reducing the redundant number (S44). If it can be secured, the process ends. If not secured, the process returns to S41 in order to secure the area by reducing the redundancy number.
  • FIG. 8 is a diagram showing an example of a processing flowchart in the file deletion of the data management unit 141 of the gateway 100.
  • the additional files described with reference to FIGS. 5 to 7 can be deleted. Since deleting the file may increase the capacity, the newly increased capacity is distributed. The description of the same processing as in FIG. 5 is omitted.
  • file writing processing it is determined whether or not an additional file can be written (S11), but this is not necessary in the case of deletion. Deleted file information, user management table, and file management table information are acquired (S50). Since unused capacity occurs due to file deletion, it is determined whether all files have the upper limit redundancy number for the users in the group. If all the files of all users in the group are at the upper limit redundancy number, the process proceeds to S52. If not, the process proceeds to S53 (S51).
  • the file deletion setting is made and the process is terminated (S52, S57, S15, S16). If all the files are not stored as the upper limit redundancy value for the users in the group, the newly created unused space is redistributed (S53 to S56).
  • S53, S55, and S56 are the same as S27, S29, and S30 in FIG.
  • the total capacity and the physical usage capacity of the deleted file are added to set the pre-distribution capacity (S54). Then, the process proceeds to S56, S57, S15, and S16, and the redundant number is adjusted by deleting the file.
  • FIG. 9 is a diagram showing an example of the redundancy number lowering priority setting screen 700 of the management terminal 200 or the client 300.
  • the redundancy number lowering priority setting screen 700 displays priority information 701, file size 702, update date and time 703, and creation date and time 704, which can set the order in which the redundant number of files is reduced.
  • the update date and time 703 and the creation date and time 704 the standard of large and small or old and new is selected, and the change of the priority order of each display can be input.
  • a setting button 705 for setting the priority update in the file management table 600 is provided.
  • FIG. 10 is a diagram illustrating an example of the inter-user accommodation setting screen 800 of the management terminal 200 or the client 300.
  • the inter-user interchange setting screen 800 displays a group name 801 and a group member 802 that are a range to be interchanged, and allows a change to be set. Further, a user addition button 803 for adding a user to the group, a user deletion button 804 for deleting a user from the group, and a setting button 805 for setting the user management table 500 are provided.
  • the unused capacity of each user in the group can be accommodated to increase the number of redundant files, and the user who uses the excess capacity due to borrowing can reduce the number of redundant files.
  • the volume can be recovered.
  • Example 2 will be described with reference to FIGS. 3 and 11 to 12.
  • the second embodiment is an embodiment in which accommodation of available (unused) capacity is set for each user, not for each group.
  • the operation when the user who is renting the capacity using the lending / borrowing capacity 517 without using the items 513 to 516 related to the group in the user management table 500 of FIG. 3 writes the file will be described.
  • the lending / borrowing capacity 517 is the sum of the vertical axis (table column) and the capacity (borrowed total capacity) that is the sum of the borrowed capacity and the value of its own physical allocation capacity 503, and the horizontal axis (table row). ) Is the total capacity.
  • FIG. 3 shows a situation where the user C rents a capacity of 15 Gbytes to the user A.
  • FIG. 11 is a diagram showing an example of a processing flowchart in file writing of the data management unit 141 of the gateway 100. The description of the processing steps similar to S14 to S16 in FIG. 5 and FIG. 7 is omitted. Additional file information, user management table, and file management table information are acquired (S60). Using the user management table 500, it is determined whether the total capacity of the lower limit redundancy capacity and the lower limit redundancy physical use capacity 508 of the additional file exceeds the value of its own physical allocation capacity 503. If it exceeds the value of the physical allocation capacity 503, the process proceeds to S62, and if not, the process proceeds to S63 (S61).
  • the possessed file cannot be maintained only with the capacity allocated to itself, so that additional files cannot be written due to insufficient capacity. (S62).
  • the total capacity of the lower limit redundancy capacity and the lower limit redundancy physical usage capacity 508 of the additional file is obtained by subtracting the value of the physical allocation capacity 503 and the amount lent to other users. It is determined whether the capacity or the sum of the capacity obtained by borrowing from other users (capacity after accommodation) is exceeded. If the capacity exceeds the capacity after accommodation, the process proceeds to S64, and if not, the process proceeds to S67 (S63).
  • the user can give the capacity to other users. This is a case where the storage capacity is insufficient because of lending. Therefore, in order to collect the capacity, the collection capacity is set for the rented user (collection destination user). At this time, the collection capacity must be set to be equal to or greater than the total capacity of the lower limit redundancy capacity and the lower limit redundancy physical use capacity 503 of the additional file (S64). From the set collection destination user and the collection capacity, processing for collecting the capacity is performed. Since the redundant number adjustment processing has been described with reference to FIG. 7, it is omitted (S65). After the capacity recovery, the write user redundancy number adjustment process is performed (S66).
  • the redundancy number of the additional file is set to the maximum redundancy number. (S69). In S69, all the files already stored may or may not be set to the maximum redundancy number.
  • FIG. 12 is a diagram showing an example of a lending / borrowing capacity table setting screen 1800 operated by the management terminal 200 or the client 300.
  • the lending / borrowing table setting screen 1800 displays the user name 1801, the accommodation capacity 1802, and the lending list 1803, and updates information on the lending / borrowing capacity 517 in the user management table 500 using the update button 1805.
  • a user name 1801 is an item for selecting a user name to be updated.
  • the accommodation capacity 1802 is composed of a current accommodation capacity and an available capacity, and the current accommodation capacity does not exceed the available capacity.
  • a lending list 1803 is a list showing the capacity and users currently rented by the user with the user name 1801.
  • Example 3 will be described with reference to FIGS.
  • the administrator allocates the capacity of the cloud storage to each user
  • the operation when the file is stored exceeding the area allocated to the user (hereinafter, logical allocation area) will be described.
  • the file is protected by the SLA.
  • (1) When the initial logical allocation area is exceeded, the number of redundancy is reduced and an unused physical allocation area is secured to save the file.
  • (2 ) When the redundant number is lowered, a process for complementing the redundant number is held by borrowing an unused physical allocation area from another user.
  • FIG. 13 is a diagram showing an example of the configuration of a system using cloud storage.
  • the cloud storage 900 is connected to the gateway 100 via the WAN 1000.
  • the memory 140 stores a cloud information table 143 described with reference to FIG. 14A and an arrangement combination table 144 described with reference to FIG. 14B.
  • the cloud storage 900 owns a data store 901 and manages file storage.
  • FIG. 14A is a diagram showing an example of the cloud information table 143.
  • the cloud information table 143 has a cloud ID 1431 for identifying the cloud storage and the value of the SLA 1432 of each cloud.
  • FIG. 14B is a diagram illustrating an example of the arrangement combination table 144.
  • the arrangement state 1441 indicates whether a file is arranged on each cloud storage 900.
  • the arrangement number 1442 indicates the number of cloud storages 900 in which files are arranged.
  • the combined SLA 1443 indicates a value when the SLA of the cloud storage 900 in the arrangement state is combined.
  • FIG. 15 is a diagram showing an example of a user management table 1500 corresponding to the cloud. Only items changed for the cloud with respect to the user management table 500 of FIG. 3 will be described, and description of the same parts as in FIG. 3 will be omitted.
  • the upper limit SLA physical use capacity 1507 indicates the total capacity of the physical use capacity when all the files possessed by the corresponding user reach the upper limit SLA 1609 (FIG. 16) set in each file.
  • the lower limit SLA physical use capacity 1508 indicates the total capacity of the physical use capacity when all files possessed by the corresponding user become the lower limit SLA 1610 (FIG. 16) set in each file.
  • An initial upper limit SLA 1509 indicates an initial upper limit SLA set for a file to be added.
  • the initial lower limit SLA 1510 indicates the initial lower limit SLA set in the added file.
  • the SLA decrease priority 1512 is priority information for determining the order in which the SLA is decreased.
  • FIG. 16 is a diagram showing an example of a file management table 1600 corresponding to the cloud. Only the items changed for the cloud with respect to the file management table 600 in FIG. 4 will be described, and description of the same parts as in FIG. 4 will be omitted.
  • the current SLA 1606 indicates the current SLA value of each file.
  • the maximum SLA 1609 indicates the maximum SLA value that can be set for each file.
  • the lower limit SLA 1610 indicates the lowest SLA value that can be set for each file.
  • the processing using the user management table 1500 and the file management table 1600 only changes the processing described in the first embodiment to the corresponding cloud item.
  • the SLA availability information may be defined by calculation such as (MTBF / (MTBF + MTTR)) * 100.
  • MTBF is the average failure time
  • MTTR is the average repair time.
  • 100 Gateway, 141: Data management unit, 142: Redundancy number calculation unit, 143: Cloud information table, 144: Arrangement combination table, 145: Capacity collection unit, 200: Management terminal, 300: Client, 400: Storage device, 500 : User management table, 600: File management table, 900: Cloud storage

Abstract

　クライアントからストレージ装置へ、ある冗長数だけ重複してファイルを格納するファイル管理方法であって、前記クライアントから前記ストレージ装置への追加ファイルを受け付ける第１のステップと、前記追加ファイルの容量と前記ストレージ装置の未使用物理容量を比較する第２のステップと、前記追加ファイルの容量が前記未使用物理容量より大きい場合に、既に格納されたファイルの前記冗長数を変更して前記未使用物理容量を増やし、前記追加ファイルを前記ストレージ装置へ格納する第３のステップと、を有する。

Description

ファイル管理方法
　本発明はファイル管理方法に関するものである。
　近年、ソーシャルネットワーキングサービスや金融、医療及び交通といった社会インフラに関する膨大なデータを分析することにより、新たな価値を生み出すビッグデータ分析と呼ばれる技術が実用化されつつある。
　ビッグデータ分析においては、社会インフラから収集される入力データ及び分析結果である出力データの容量が共に非常に大きく、時間と共に増加し続ける。
　例えば、クラウドサービスを利用してビックデータ分析を行う場合この課題は顕著である。クラウドサービスの計算資源に関しては計算機の性能及び利用時間に基づいて計算され、ストレージ資源に関してはデータ容量及び記録期間に基づいて算出されることが多い。このためデータ容量が拡大すると、トータルコストは計算資源よりもストレージ資源の利用料金のほうが支配的になる。よってクラウドサービスを利用してビックデータ分析を行った場合クラウドサービス利用コストが膨大になる。
　ストレージ資源の利用効率向上方法として、特許文献１に開示されているように、ユーザに割り当てられた資源を円滑にユーザ間で提供（売り）－利用（買い）する技術がある。この技術を用いることで、ユーザの未使用資源を売買し、未使用資源の利用効率を向上することが可能である。
　また、入力データの収集のコストも高いため、ストレージ資源の信頼性も重要である。
特開２０１１－１５４５３２号公報
　特許文献１に開示された技術では、ユーザ間でユーザが所有する資源の提供－利用を可能とする。このとき、資源を受け取ったユーザは、提供された資源の所有権を得る。そのため、資源を提供したユーザが資源の回収を希望しても、資源の所有権が他ユーザにあるので、資源の回収ができないという課題があった。
　そこで、本発明は、未使用領域を融通可能にしつつ、融通で提供した資源を回収可能にすることを目的とする。
　本発明にかかるファイル管理方法は、クライアントからストレージ装置へ、ある冗長数だけ重複してファイルを格納するファイル管理方法であって、前記クライアントから前記ストレージ装置への追加ファイルを受け付ける第１のステップと、前記追加ファイルの容量と前記ストレージ装置の未使用物理容量を比較する第２のステップと、前記追加ファイルの容量が前記未使用物理容量より大きい場合に、既に格納されたファイルの前記冗長数を変更して前記未使用物理容量を増やし、前記追加ファイルを前記ストレージ装置へ格納する第３のステップと、を有することを特徴とする。
　また、本発明にかかるファイル管理方法は、複数のユーザそれぞれへストレージ装置の物理割当容量を割り当て、前記割り当てた物理割当容量の貸し借りを可能にし、前記ユーザのクライアントから前記ストレージ装置へ、ある冗長数だけ重複して格納するファイル管理方法であって、前記クライアントから前記ストレージ装置への追加ファイルを受け付けるステップと、前記追加ファイルの容量と、前記追加ファイルを所有する第１の前記ユーザの既に格納されたファイルすべての容量とを加算し、前記加算した容量と、前記第１のユーザへ割り当てられた前記物理割当容量から貸し出した容量を減算した容量とを比較するステップと、前記加算した容量の方が大きい場合に、前記貸し出した先のユーザの既に格納されたファイルの前記冗長数を変更し、前記冗長数を変更することにより空いた容量へ前記追加ファイルを格納するステップと、を有することを特徴とする。
　本発明によれば、冗長数を変更することにより、提供した領域の回収を可能にする。
ユーザ間の未使用容量の貸し出しの例を示す図である。 ユーザ間の容量の回収と冗長数の変更の例を示す図である。 システム構成の例を示す図である。 ユーザ管理テーブルの例を示す図である。 ファイル管理テーブルの例を示す図である。 データ管理部のファイル書き込みの処理フローチャートの例を示す図である。 冗長数調整部の処理フローチャートの例を示す図である。 容量回収部の処理フローチャートの例を示す図である。 データ管理部のファイル削除の処理フローチャートの例を示す図である。 冗長数低下優先度設定画面の例を示す図である。 ユーザ間融通設定画面の例を示す図である。 容量回収によるファイル書き込みの処理フローチャートの例を示す図である。 ユーザ間貸出借用容量設定画面の例を示す図である。 クラウドストレージを使用したシステムの構成の例を示す図である。 クラウド情報テーブルの例を示す図である。 配置組合せテーブルの例を示す図である。 クラウドに対応したユーザ管理テーブルの例を示す図である。 クラウドに対応したファイル管理テーブルの例を示す図である。
　以下、計算機（ゲートウェイ）を介して、ファイルの保護を目的とし、ストレージ装置にファイルを冗長化して保存するシステムを例として、ユーザ間でのストレージの容量を融通する実施形態を説明する。融通の概要として、（１）ユーザに割り当てられた容量の内、未使用容量に対して、融通関係を持っている他ユーザに未使用容量の貸し出しを可能にする。（２）貸し出した容量を他ユーザが利用している場合であっても回収を可能にするため、借用ユーザのデータ冗長性を低下させ、回収容量を確保可能にする。（３）自身のデータを削除することなく回収容量の確保を可能するため、全データの冗長性を最低にした場合において、自身に割り当てられた容量内に収まるようにする。
　実施例１では、ストレージ装置内の3つの物理ボリュームへファイルを冗長保存するシステムを例に説明する。同じ内容のファイルの保存個数を冗長数として、融通関係をグループという形で実装し、グループ内で未使用容量を自動分配する例である。実施例２は実施例１のグループでの分配の代わりにユーザ個別に貸し出し／回収をする例である。実施例３は、３つのクラウドストレージにファイルを保存するシステムを例に説明する。実施例１ではファイルの冗長数を指標とするのに対し、実施例３では冗長性としてＳｅｒｖｉｃｅ　Ｌｅｖｅｌ　Ａｇｒｅｅｍｅｎｔで定められた可用性情報（以下、ＳＬＡ）を指標とする。
　図１～１０を用いて実施例1について説明する。実施例１は、管理者がストレージ装置の容量を各ユーザに割り当てた場合において、ユーザに割り当てた容量（以下、論理割当容量）を超えてファイルを保存する場合の動作を説明する。各ユーザに割り当てられている実際の記憶領域（物理割当領域）は、冗長保存のため、論理割当領域の冗長数倍を確保している。
　本実施例においても、（１）初期の論理割当領域を超えた場合において、グループとして冗長数を下げ、未使用の物理割当領域を確保することにより、ファイルの保存をする処理、（２）冗長数が低下している場合において、他のユーザから未使用の物理割当領域を借用することにより、冗長数を補完する処理を保有する。
　図１Ａ、１Ｂは、ユーザに割り当てられた容量を超えて利用した際に冗長数を下げることと、他のユーザから容量を借用し、冗長数を補完する動作を示している。このシステムにおいて、各ユーザに割り当てられた初期の物理ボリューム（図では９ブロック分）の容量内であれば、冗長数の低下はあるが、保存可能であることを保証する。＃１～８を順に説明する。＃１において、管理者はユーザA、Bに各３ブロック分の論理ボリュームを提供している。論理ボリューム１ブロック分は初期設定で３重化しているので物理ボリューム３ブロック分となる。各ユーザはこの合計９ブロックの物理ボリューム内で冗長数の変更、及び未使用領域の提供、領域の回収を行う。＃２において、各ユーザが割り当てられた容量内でデータの保存を行った場合を示している。＃３において、ユーザAは、初期に割り当てられた領域を超えて、ユーザBから容量を借用して保存する場合を示している。ユーザAは、物理ボリューム4.5ブロック分のデータを保存するため、ユーザBから1.5ブロック分の容量を借用し、自分のブロックとして使用している。
　＃４において、ユーザBは物理ボリューム２ブロック分のデータを保存する場合を示している。ユーザBはユーザAに4.5ブロックを貸し出しているため、物理ボリュームを4.5ブロックしか所持していないので、ユーザAから物理ボリューム1.5ブロック分を回収する。この時、ユーザAは物理ボリューム1.5ブロック分を返却するため、一部のブロックを３重化から２重化に変更している。＃５も同様に、ユーザBが物理ボリューム３ブロック分のデータを保存するため、ユーザAから３ブロックを回収している。ユーザBは、初期に割り当てられた容量内で保存しているため、全て３重化されている。これに対してユーザAは、初期に割り当てられた容量を超えて保存しており、借用する領域がないため、２重化で保存している。このように、ユーザ間での容量の貸し出し及び回収する機能を提供する。
　図２は、ストレージ装置のボリューム内にファイルを冗長保存するファイル保存システムの構成の例を示す図である。
　ゲートウェイ１００はファイル保存サービスをクライアント３００に提供する計算機である。このため、ゲートウェイ１００はクライアント３００とストレージ装置４００との間でファイルを転送する。ＣＰＵ１１０はメモリ１４０に格納された処理部（プログラム）を実行する。メモリ１４０はファイル保存サービスのための処理部（プログラム）やテーブル類を格納する。メモリ１４０に格納される処理部は、データ管理部１４１、冗長数計算部１４２、容量回収部１４５である。テーブルはユーザ管理テーブル５００とファイル管理テーブル６００である。さらに、メモリ１４０は各処理部の実行に必要なワークエリアなどの領域を有する。ボリューム１２０はスタブファイル１２１を格納する。スタブファイル１２１はユーザ毎にファイルＩＤを保持する。Ｉ／Ｆ１３０はクライアント３００、ストレージ装置４００との間でファイルを送受信する。また、管理端末２００、クライアント３００との間で管理情報を送受信する。なお、各処理部をＣＰＵ１１０で実行するプログラムではなく、ＣＰＵ１１０がプログラムを実行するのと同じ動作をする独立したハードウェアとしてもよい。
　管理端末２００はゲートウェイ１００、ストレージ装置４００の管理情報を必要に応じて取得することができ、ゲートウェイ１００を管理するための端末であって、ネットワーク及び操作画面に接続するためのＩ／Ｆ２３０と、メモリ２４０と、それらを接続する内部的な通信路を有する計算機である。メモリ２４０は処理部（プログラム）やデータを格納する。処理部は、例えば、ゲートウェイ管理部２４１である。操作画面２５０は、管理端末２００を介してゲートウェイ１００の管理情報を入出力する。
　クライアント３００は、ゲートウェイ１００により提供されるファイル保存サービスを利用するユーザによって使用される計算機であって、ネットワーク及び操作画面に接続するためのＩ／Ｆ２３０と、メモリ２４０と、それらを接続する内部的な通信路を有する計算機である。操作画面３５０はクライアント３００を介してゲートウェイ１００の管理情報を入出力する。
　ストレージ装置４００はゲートウェイ１００からの指示に対応してファイルの保存サービス（書き込み、読み出し、更新、削除等）を提供する。このため、ストレージ装置４００はファイルを保存するための単体／複数のボリューム４０１を所持する。また、ファイルの書き込みや読み出しには、ファイルを識別するファイルＩＤを用いる。ゲートウェイ１００は、各ファイルに固有のファイルＩＤを付す。
　クライアント３００からファイルを書き込む場合について説明する。クライアント３００はファイルをゲートウェイ１００に送信する。ゲートウェイ１００は受信したファイルに対して固有のファイルＩＤを付して、ストレージ装置４００へ送信する。ゲートウェイ１００は、ユーザ毎にファイルＩＤ、及びファイルの格納場所を示すパス情報の対応関係をスタブ情報として保持する。このようにしてファイルをストレージ装置に配置することにより、クライアント３００がファイルを読み出す場合、クライアント３００はスタブ情報を参照すればよい。
　図３はユーザ管理テーブル５００の例を示す図である。ユーザ管理テーブル５００は、割り当て情報、冗長数を低下させるファイルの優先度情報、融通情報を管理するテーブルである。ユーザＩＤ５０１はストレージ装置４００に格納しているファイルをユーザＩＤ毎に管理するための識別子である。論理割当容量５０２は管理者が割り当てた論理容量を示す。物理割当容量５０３は管理者が想定している初期の冗長数と論理割当容量を掛け合わせた容量である。物理利用中容量５０４は、物理割当容量の内、ユーザが利用している容量を示している。融通可能（未使用）容量５０５は物理割当容量から物理利用中容量を引いた容量を示し、融通グループに所属している場合、他ユーザに提供することが可能な最大容量を示している。
　合計ファイルサイズ５０６は冗長ファイルを除いたファイルの合計を示す。上限冗長時物理利用容量５０７はユーザが所持する全ファイルをファイルに設定された上限冗長数にした場合の容量の使用量を示している。この容量が物理割当容量を超えていた場合は、他ユーザから容量を融通してもらうか、幾つかのファイルの冗長数を下げて物理割当容量内に収める必要がる。下限冗長数物理利用容量５０８はユーザが所持する全ファイルをファイルに設定された下限冗長数にした場合の容量の使用量を示している。この値が、他ユーザから容量の借用ができない場合において、ユーザが所持する全ファイルを物理割当容量内で保持する必要があるので、ユーザの物理利用量を超過しないようにする制限値となる。初期上限冗長数５０９と初期下限冗長数５１０それぞれは追加されるファイルに設定される初期の上限冗長数と下限冗長数を示す。
　初期圧縮可否５１１は、ファイルを書き込む際に自動的にファイルを圧縮するか否かを示す。冗長数低下優先度５１２は冗長数を低下させる際にどの順番でソートするかを決定するための優先度情報を示す。例えば、ユーザＡは、優先度情報、サイズ、アクセス日時、作成日時の順にソートの強さが決まっている。また、サイズ［大］は、サイズが大きいものからが優先的に冗長数を低下させることを示す。融通グループ５１３はユーザが所持する融通可能（未使用）容量を同じグループに所属するユーザに提供可能であることを示す。所属グループ内合計融通容量５１４は同じグループに所属する全ユーザの融通可能（未使用）容量を合計した値を示す。所属グループ内利用中融通容量５１５は物理割当容量を超えて利用しているユーザが同じグループに所属するユーザの未使用容量から借用している容量を示している。所属グループ内未使用融通容量５１６は所属グループ合計融通容量５１４の内、他ユーザに利用されていない容量を示す。貸出借用容量５１７は、実施例２で利用するので後で説明し、実施例１では無くてもよい。
　図４はファイル管理テーブル６００の例を示す図である。ユーザＩＤ６０１はストレージ装置４００に格納しているファイルをユーザＩＤ毎に管理するための識別子である。ファイルＩＤ６０２はストレージ装置４００に格納しているファイルを一意に識別するファイル識別子である。ファイルサイズ６０３は冗長を考慮しないファイルそのものの大きさを示す。アクセス日時６０４は、最後にアクセスされた日時を示す。作成日時６０５は作成された日時を示す。現在冗長数６０６は対応するファイルが何重に冗長化されているかを示す。総ファイルサイズ６０７は冗長分を加算した物理容量の使用量を示す。優先度６０８は冗長数を変更する際の第一指標として利用する。ここでは、例として、LowとMiddleとHighの3段階でLowから優先的に冗長数を低下させる設定となっている。上限冗長数６０９はファイルが冗長化できる最大の冗長数を示す。下限冗長数６１０は冗長数が低下した際の最低限維持する冗長数を示す。圧縮可否６１１はファイルが圧縮可能か否かを示す。圧縮状態６１２は圧縮状態であるか未圧縮状態であるかを示す。ファイル配置情報６１３はストレージ装置４００に書き込んだ場所を示す。
　図５はゲートウェイ１００のデータ管理部１４１のファイル書き込みにおける処理フローチャートの例を示す図である。この例では、ユーザ間で未使用容量の融通設定を行い、グループを作成している場合を示している。このグループ内では、融通可能容量がある場合、上限冗長数で保存できなくなった各ユーザに対して融通容量を超過量の割合を基に自動分配する。
　まず、データ管理部１４１（ＣＰＵ１１０によるデータ管理部１４１のプログラムの実行）はクライアント３００からファイルの書き込み要求及びファイルの情報を取得する。ここでは、ユーザＩＤをユーザＡ、ファイルを追加ファイルとする（Ｓ１０）。データ管理部１４１はユーザＡが追加ファイルを保存可能か確認する。既存のファイル及び追加ファイルを下限冗長数と仮定した場合にユーザＡの物理割当容量５０３の値を超えているか判断する。超えていない場合はＳ１２へ進み、超えている場合はＳ１７へ進む（Ｓ１１）。ここで、超えているかの判断は数学的に厳密な比較による判断以外に、計算機上の数値表現の誤差等も含めて、容量的に保存可能かの判断も含む。以下の説明における判断も同じである。
　データ管理部１４１は、ユーザ管理テーブル５００を参照して、ファイルの初期状態を設定する（Ｓ１２）。次に、データ管理部１４１は、冗長数計算部１４２を使用し、ユーザＡ及び同じグループに所属するユーザのファイル冗長数を設定する（Ｓ１３）。そして、変更されたファイルの冗長数を基にファイルをストレージ装置に書き込み（Ｓ１４）、ファイル管理テーブルおよびユーザ管理テーブルを更新する（Ｓ１５）。ここで、ファイルの冗長数の変更があった場合、ユーザに通知する（Ｓ１６）。既存ファイル及び追加ファイルを下限冗長数の値にしても、物理割当容量５０３値に収まらない場合は、容量不足であり、書き込み失敗となる（Ｓ１７）。
　図６はゲートウェイ１００の冗長数計算部１４２の処理フローチャートの例を示す図であり、図５の冗長数決定処理（Ｓ１２）の詳細を示す。追加ファイルを上限冗長数にしたと仮定した場合の容量とユーザ管理テーブル５００の所属グループ内未使用融通容量（以下未使用融通容量）５１６の容量を比較する。追加ファイルが未使用融通容量５１６の容量より小さければ、Ｓ２１へ進む。大きければ、Ｓ２２へ進む（Ｓ２０）。ユーザＡが所持する物理割当容量５０３の値と未使用融通容量５１６の値を足した容量内で追加ファイルを上限冗長数で保存できる状態なので、追加ファイルを上限冗長数に設定して保存する（Ｓ２１）。Ｓ２１において、既に保存した全ファイルは最大冗長数に変更しても変更しなくてもよい。
　上限冗長数の値で追加ファイルを保存できない場合は、容量の回収もしくは、融通容量の分配を行うため、状態を比較する。容量を回収する場合はＳ２３へ進み、融通容量の分配をする場合は、Ｓ２７へ進む（Ｓ２２）。Ｓ２３へ進むと判定した場合は、グループ内の各ユーザに対して、上限冗長時物理利用容量５０７の値と物理割当容量５０３の値を比較し、物理割当容量５０３の値を超えているユーザを取得する（Ｓ２３）。融通容量合計容量から上限冗長の追加ファイルの容量を引いた容量を分配前容量とする（Ｓ２４）。各超過ユーザの超過量と分配前容量から分配容量を決定する（Ｓ２５）。各超過ユーザに対して、ファイルを保存可能な容量（目標容量）を指定し、冗長数調整処理を行う。この時、ユーザＡは冗長数調整処理に含まれていないので、Ｓ２１に進む（Ｓ２６）。
　Ｓ２２にてＳ２７へ進むと判定した場合は、Ｓ２３と同様の処理をし（Ｓ２７）、融通容量合計容量を分配前容量とする（Ｓ２８）。各超過ユーザの超過量と分配前容量から分配容量を決定する（Ｓ２９）。各超過ユーザに対して、ファイルを保存可能な容量（目標容量）を指定し、冗長数調整処理を行う。この時、冗長数調整処理にユーザＡも含まれる（Ｓ３０）。
　図７はゲートウェイ１００の容量回収部１４５の処理フローチャートの例を示す図である。対象ユーザに対して目標容量内に収まるように冗長数を調整するものであって、図６におけるＳ２６及びＳ３０の詳細である。ファイルの冗長数を最大冗長数から、リストの優先順位の高いものから順に冗長数を下げ、回収量を確保するまで繰り返し低下させる処理である。冗長数調整を行うユーザにおいて、ユーザ管理テーブル５００の冗長数低下優先度５１２の値を取得し、ユーザが所持する全ファイルをソートしてリストを作成する（Ｓ４０）。最優先ファイルの現在の冗長数が下限冗長数となっているかを判断する（Ｓ４１）。下限冗長数となっていなければ冗長数を１段階下げる（Ｓ４２）。下限冗長数となっていれば、冗長数を変化させずにＳ４３へ進む。最優先ファイルをリストの末尾（優先度を最低）にする（Ｓ４３）。冗長数を下げたことで目標領域分（回収量分）の領域を確保できたか判断する（Ｓ４４）。確保できている場合は処理を終了する。確保できていない場合は、冗長数を下げて領域を確保するためＳ４１へ戻る。
　図８はゲートウェイ１００のデータ管理部１４１のファイル削除における処理フローチャートの例を示す図である。例えば、図５～７を用いて説明した追加ファイルなどを削除することができる。ファイルを削除すると融通容量が増える場合があるため、新たに増加した融通容量を分配する。図５と同様の処理はその説明を省略する。ファイルの書き込み処理の場合、追加のファイルが書き込めるかの判断（Ｓ１１）を行っているが、削除の場合は不要である。削除ファイルの情報及び、ユーザ管理テーブル、ファイル管理テーブル情報を取得する（Ｓ５０）。ファイル削除によって、融通未使用容量が発生するため、グループ内ユーザに対して全ファイルが上限冗長数になっているかを判断する。グループ内ユーザ全ての全ファイルが上限冗長数となっていれば、Ｓ５２へ進む。なっていなければＳ５３へ進む（Ｓ５１）。
　グループ内ユーザが全ファイルを上限冗長数の値で保存している場合は、ファイルの冗長数を変更する必要がないので、ファイル削除設定をし、終了する（Ｓ５２、Ｓ５７、Ｓ１５、Ｓ１６）。グループ内ユーザに全ファイルを上限冗長数の値で保存していない場合は、新に生じる融通未使用領域を再分配する（Ｓ５３～Ｓ５６）。ここで、Ｓ５３、Ｓ５５，Ｓ５６は、図６のＳ２７、Ｓ２９、Ｓ３０と同様の処理のため説明を省略する。融通容量合計と削除ファイルの物理利用容量を足し、分配前容量に設定する（Ｓ５４）。そして、Ｓ５６、Ｓ５７、Ｓ１５、Ｓ１６と進み、ファイルを削除して冗長数を調整する。
　図９は管理端末２００又はクライアント３００の冗長数低下優先度設定画面７００の例を示す図である。冗長数低下優先度設定画面７００はファイルの冗長数を低下させる順序を設定可能にするものである、優先度情報７０１、ファイルサイズ７０２、更新日時７０３、作成日時７０４を表示し、ファイルサイズ７０２と更新日時７０３と作成日時７０４については大小や新古の基準を選択し、表示それぞれの優先順位の変更を入力可能にする。さらに、優先順位の更新をファイル管理テーブル６００に設定する設定ボタン７０５を有する。
　図１０は管理端末２００又はクライアント３００のユーザ間融通設定画面８００の例を示す図である。ユーザ間融通設定画面８００は、融通する範囲となるグループ名８０１、グループメンバ８０２を表示し、変更を設定可能にする。さらに、グループにユーザを追加するユーザ追加ボタン８０３、グループからユーザを削除するユーザ削除ボタン８０４、ユーザ管理テーブル５００に設定する設定ボタン８０５を有する。
　以上、説明したように所属グループ内の各ユーザの未使用容量を融通してファイルの冗長数を上げることができるとともに、借用により超過した容量を使用しているユーザはファイルの冗長数を下げて容量を回収させることができる。
　図３と図１１～１２を用いて実施例２を説明する。実施例２は、融通可能（未使用）容量の融通をグループ単位ではなく、ユーザ毎に設定する実施の形態である。図３のユーザ管理テーブル５００においてグループに関係する項目５１３～５１６を備えず、貸出借用容量５１７を備えて使用し、容量を貸出中のユーザがファイルを書き込む際の動作を説明する。貸出借用容量５１７は、縦軸（テーブルの列）の合計を借用中の容量と自身が利用できる自身の物理割当容量５０３の値を合計した容量（借用合計容量）とし、横軸（テーブルの行）の合計を融通中の容量としている。図３では、ユーザＣが１５Gbyteの容量をユーザＡに貸し出している状況を示している。
　図１１はゲートウェイ１００のデータ管理部１４１のファイル書き込みにおける処理フローチャートの例を示す図である。図５のＳ１４～Ｓ１６、図７と同様の処理の部分は説明を省略する。追加ファイル情報及び、ユーザ管理テーブル、ファイル管理テーブル情報を取得（Ｓ６０）。ユーザ管理テーブル５００を用いて、追加ファイルの下限冗長時容量と下限冗長時物理利用容量５０８の値の合計容量が自身の物理割当容量５０３の値を超えているか判断する。物理割当容量５０３の値を超えていればＳ６２、超えていなければＳ６３へ進む（Ｓ６１）。
　物理割当容量５０３の値を超えている場合、自身に割り当てられている容量だけで所持ファイルを維持できないので、容量不足により追加ファイルの書き込み不可とする。（Ｓ６２）。物理割当容量５０３の値を超えていない場合、追加ファイルの下限冗長時容量と下限冗長時物理利用容量５０８の値の合計容量が自身の物理割当容量５０３の値と他ユーザへ貸出分を差し引いた容量、又は、他ユーザから借用分を足した容量の合計（融通後容量）を超えているか判断する。融通後容量を超えている場合は、Ｓ６４へ、超えていない場合は、Ｓ６７へ進む（Ｓ６３）。
　追加ファイルの下限冗長時容量と下限冗長時物理利用容量５０８の値の合計値が、物理割当容量５０３の値を超えておらず、融通後容量を超えている場合は、ユーザが他ユーザに容量を貸し出しているために、保存容量が足りない場合である。ゆえに、容量の回収を行うため、貸し出しているユーザ（回収先ユーザ）に対して回収容量を設定する。このとき、回収容量は、追加ファイルの下限冗長時容量と下限冗長時物理利用容量５０３の値の合計容量以上に設定しなければならない（Ｓ６４）。設定された、回収先ユーザと回収容量から、容量を回収する処理を行う。冗長数調整処理は、図７で説明したので省略する（Ｓ６５）。容量回収後、書き込みユーザの冗長数調整処理を行う（Ｓ６６）。
　追加ファイルの下限冗長時容量と下限冗長時物理利用容量５０３の値の合計容量が、物理割当容量５０３の値を超えていない、且つ融通後容量も超えていない場合を説明する。追加ファイルの上限冗長時容量と上限冗長時物理利用容量５０７の値の合計容量が融通後容量を超えているか判断する。融通後容量を超えている場合はＳ６８へ進み、超えていない場合はＳ６９へ進む（Ｓ６７）。Ｓ６８へ進む場合は、Ｓ６４と異なり、回収容量を自由に設定可能である。回収容量の大きさの違いにより、書き込みユーザのファイル冗長数が全て最大になるかどうか決まる（Ｓ６８）。Ｓ６９へ進む場合は、追加ファイルを最大冗長数にしても書き込める容量が存在するので、追加ファイルの冗長数を最大冗長数に設定する。（Ｓ６９）。Ｓ６９において、既に保存した全ファイルは最大冗長数に設定しても設定しなくてもよい。
　図１２は管理端末２００又はクライアント３００によって操作される貸出借用容量テーブル設定画面１８００の例を示す図である。貸出借用テーブル設定画面１８００は、ユーザ名１８０１、融通容量１８０２、貸出リスト１８０３を表示し、ユーザ管理テーブル５００の貸出借用容量５１７の情報を更新ボタン１８０５により更新する。ユーザ名１８０１は更新を行うユーザ名を選択する項目である。融通容量１８０２は現在融通容量と融通可能容量から構成され、現在融通容量は融通可能容量を超えない。貸出リスト１８０３はユーザ名１８０１のユーザが現在貸し出している容量とユーザを示すリストである。
　以上、説明したように追加ファイルの書き込みにおいて容量が不足した場合、所属グループ内の各ユーザの冗長数を下げて回収するのではなく、特定の回収先ユーザの冗長数を下げて容量を回収して書き込むことができる。このため、回収処理の影響範囲が狭く、高速に処理できる可能性がある。
　図１３～図１６を用いて実施例３を説明する。実施例３は、管理者がクラウドストレージの容量を各ユーザに割り当てた場合において、ユーザに割り当てた領域（以下、論理割当領域）を超えてファイルを保存する場合の動作を説明する。ファイルはＳＬＡにより保護されており、（１）初期の論理割当領域を超えた場合において、冗長数を下げて、未使用の物理割当領域を確保することにより、ファイルの保存をする処理、（２）冗長数が低下している場合において、他のユーザから未使用の物理割当領域を借用することにより、冗長数を補完する処理を保有する。
　図１３はクラウドストレージを使用したシステムの構成の例を示す図である。図２のストレージ装置４００を接続する代わりにゲートウェイ１００へＷＡＮ１０００経由でクラウドストレージ９００を接続する。また、メモリ１４０には図１４Ａを用いて説明するクラウド情報テーブル１４３と図１４Ｂを用いて説明する配置組合せテーブル１４４を格納する。クラウドストレージ９００はデータストア９０１を所有し、ファイルの保存管理を行う。
　図１４Ａはクラウド情報テーブル１４３の例を示す図である。クラウド情報テーブル１４３はクラウドストレージを識別するためのクラウドＩＤ１４３１と各クラウドのＳＬＡ１４３２の値を有する。図１４Ｂは配置組合せテーブル１４４の例を示す図である。配置状態１４４１は各クラウドストレージ９００上にファイルを配置するか否かを示す。配置数１４４２はファイルを配置しているクラウドストレージ９００の数を示す。合成ＳＬＡ１４４３は配置状態のクラウドストレージ９００のＳＬＡを合成した際の値を示す。
　図１５はクラウドに対応したユーザ管理テーブル１５００の例を示す図である。図３のユーザ管理テーブル５００に対してクラウドのために変更した項目のみを説明し、図３と同様の部分については説明を省略する。上限ＳＬＡ時物理利用容量１５０７は該当するユーザが所持する全ファイルが各ファイルに設定された上限ＳＬＡ１６０９（図１６）になった場合の物理利用容量の合計容量を示す。下限ＳＬＡ時物理利用容量１５０８は該当するユーザが所持する全ファイルが各ファイルに設定された下限ＳＬＡ１６１０（図１６）になった場合の物理利用容量の合計容量を示す。初期上限ＳＬＡ１５０９は追加されるファイルに設定される初期の上限ＳＬＡを示す。初期下限ＳＬＡ１５１０は追加されるファイルに設定される初期の下限ＳＬＡを示す。ＳＬＡ低下優先度１５１２は、ＳＬＡを低下させる順番を決定するための優先度情報である。
　図１６はクラウドに対応したファイル管理テーブル１６００の例を示す図である。図４のファイル管理テーブル６００に対してクラウドのために変更した項目のみを説明し、図４と同様の部分については説明を省略する。現在ＳＬＡ１６０６は各ファイルの現在のＳＬＡ値を示す。最大ＳＬＡ１６０９は各ファイルが設定できる最大のＳＬＡの値を示す。下限ＳＬＡ１６１０は各ファイルが設定できる最低のＳＬＡ値を示す。
　ユーザ管理テーブル１５００とファイル管理テーブル１６００を使用しての処理は実施例１にて説明した処理を、対応するクラウドの項目へ変更するだけである。なお、ＳＬＡの可用性情報として（ＭＴＢＦ／（ＭＴＢＦ＋ＭＴＴＲ））＊１００等の計算で定義してもよい。ここで、ＭＴＢＦは平均故障時間であり、ＭＴＴＲは平均修復時間である。
　以上、説明したようにクラウドシステムにおいても、所属グループ内の各ユーザの未使用容量を融通してファイルの可用性を上げることができるとともに、借用により超過した容量を使用しているユーザはファイルの可用性を下げて容量を回収させることができる。そして、ビッグデータを格納するクラウドシステムのストレージ資源の利用効率を向上するとともに、信頼性を確保できる。
１００：ゲートウェイ、１４１：データ管理部、１４２：冗長数計算部、１４３：クラウド情報テーブル、１４４：配置組合せテーブル、１４５：容量回収部、２００：管理端末、３００：クライアント、４００：ストレージ装置、５００：ユーザ管理テーブル、６００：ファイル管理テーブル、９００：クラウドストレージ

Claims (8)

  1. 　クライアントからストレージ装置へ、ある冗長数だけ重複してファイルを格納するファイル管理方法であって、
    　前記クライアントから前記ストレージ装置への追加ファイルを受け付ける第１のステップと、
    　前記追加ファイルの容量と前記ストレージ装置の未使用物理容量を比較する第２のステップと、
    　前記追加ファイルの容量が前記未使用物理容量より大きい場合に、既に格納されたファイルの前記冗長数を変更して前記未使用物理容量を増やし、前記追加ファイルを前記ストレージ装置へ格納する第３のステップと、
    を有することを特徴とするファイル管理方法。
  2. 　複数のユーザそれぞれへ前記ストレージ装置の物理割当容量を割り当てるステップと、
    　前記冗長数の範囲として上限冗長数と下限冗長数を設定するステップと、
    　前記追加ファイルを下限冗長数で重複した場合の容量と、前記追加ファイルを所有する第１の前記ユーザの前記格納されたファイルすべてを下限冗長数で重複した場合の容量とを加算し、前記加算した容量と前記第１のユーザに割り当てられた第１の前記物理割当容量とを比較するステップと、
    　前記加算した容量の方が大きい場合は、前記追加ファイルを書き込み不可とするステップと、
    をさらに有することを特徴とする請求項１に記載のファイル管理方法。
  3. 　前記第２のステップと前記第３のステップであって、前記追加ファイルの容量は前記追加ファイルを上限冗長数で重複した場合の第１の容量である第２のステップと第３のステップと
    を有することを特徴とする請求項２に記載のファイル管理方法。
  4. 　前記第３のステップであって、前記第１の容量が前記未使用物理容量より大きい場合に、前記第１の容量と前記第１のユーザの前記既に格納されたファイルすべてを上限冗長数で重複した場合の容量とを加算し、前記加算した容量と前記第１の物理割当容量とを比較し、前記既に格納されたファイルの前記冗長数を下げて前記未使用物理容量を増やし、前記追加ファイルを前記ストレージ装置へ格納する第３のステップと
    を有することを特徴とする請求項３に記載のファイル管理方法。
  5. 　前記第３のステップであって、前記既に格納されたファイルの前記冗長数を変更して前記未使用物理容量を増やすことは、前記格納されたファイルに付けられた冗長数低下優先度にしたがって、前記格納されたファイルの前記冗長数を１段階ずつ下げることにより、前記未使用物理容量を増やすことを含む第３のステップと
    を有することを特徴とする請求項４に記載のファイル管理方法。
  6. 　前記クライアントから前記ストレージ装置へのファイル削除を受け付けるステップと、
    　前記ファイル削除により増える前記未使用物理容量を使用して前記格納されたファイルの冗長数を増やすステップと、
    を有することを特徴とする請求項１に記載のファイル管理方法。
  7. 　前記ストレージ装置はクラウドストレージであり、
    　前記冗長数は可用性であり、
    　前記第３のステップであって、前記追加ファイルの容量が前記未使用物理容量より大きい場合に、前記既に格納されたファイルの前記可用性を変更して前記未使用物理容量を増やし、前記クラウドストレージへ前記追加ファイルを格納する第３のステップと、
    を有することを特徴とする請求項１に記載のファイル管理方法。
  8. 　複数のユーザそれぞれへストレージ装置の物理割当容量を割り当て、前記割り当てた物理割当容量の貸し借りを可能にし、前記ユーザのクライアントから前記ストレージ装置へ、ある冗長数だけ重複して格納するファイル管理方法であって、
    　前記クライアントから前記ストレージ装置への追加ファイルを受け付けるステップと、
    　前記追加ファイルの容量と、前記追加ファイルを所有する第１の前記ユーザの既に格納されたファイルすべての容量とを加算し、前記加算した容量と、前記第１のユーザへ割り当てられた前記物理割当容量から貸し出した容量を減算した容量とを比較するステップと、
    　前記加算した容量の方が大きい場合に、前記貸し出した先のユーザの既に格納されたファイルの前記冗長数を変更し、前記冗長数を変更することにより空いた容量へ前記追加ファイルを格納するステップと、
    を有することを特徴とするファイル管理方法。
PCT/JP2013/078374 2013-10-18 2013-10-18 ファイル管理方法 WO2015056352A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US14/423,762 US20160034476A1 (en) 2013-10-18 2013-10-18 File management method
PCT/JP2013/078374 WO2015056352A1 (ja) 2013-10-18 2013-10-18 ファイル管理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2013/078374 WO2015056352A1 (ja) 2013-10-18 2013-10-18 ファイル管理方法

Publications (1)

Publication Number Publication Date
WO2015056352A1 true WO2015056352A1 (ja) 2015-04-23

Family

ID=52827819

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/078374 WO2015056352A1 (ja) 2013-10-18 2013-10-18 ファイル管理方法

Country Status (2)

Country Link
US (1) US20160034476A1 (ja)
WO (1) WO2015056352A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021039623A (ja) * 2019-09-04 2021-03-11 富士ゼロックス株式会社 情報管理装置および情報管理システム

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5748932B2 (ja) * 2013-04-30 2015-07-15 株式会社日立製作所 計算機システム及び非同期リモートレプリケーションの分析を支援する方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0973407A (ja) * 1995-09-05 1997-03-18 Mitsubishi Electric Corp データ管理装置
JP2006343924A (ja) * 2005-06-08 2006-12-21 Hitachi Ltd ボリューム管理システムおよびその方法
JP2007328727A (ja) * 2006-06-09 2007-12-20 Hitachi Ltd 分散ファイル管理方法及び情報処理装置

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5274805A (en) * 1990-01-19 1993-12-28 Amalgamated Software Of North America, Inc. Method of sorting and compressing data
US5809224A (en) * 1995-10-13 1998-09-15 Compaq Computer Corporation On-line disk array reconfiguration
US7161615B2 (en) * 2001-11-30 2007-01-09 Pelco System and method for tracking objects and obscuring fields of view under video surveillance
US8397133B2 (en) * 2008-11-26 2013-03-12 Arizona Board Of Regents For And On Behalf Of Arizona State University Circuits and methods for dual redundant register files with error detection and correction mechanisms
DE102009031923A1 (de) * 2009-07-07 2011-01-13 Sones Gmbh Verfahren zum Verwalten von Datenobjekten
US9858548B2 (en) * 2011-10-18 2018-01-02 Dotloop, Llc Systems, methods and apparatus for form building
US8903764B2 (en) * 2012-04-25 2014-12-02 International Business Machines Corporation Enhanced reliability in deduplication technology over storage clouds
MX2013005303A (es) * 2013-05-10 2013-08-07 Fondo De Informacion Y Documentacion Para La Ind Infotec Un sistema y un proceso de alto desempeño para el tratamiento y almacenamiento de datos, basado en componentes de bajo costo, que garantiza la integridad y disponibilidad de los datos para su propia administracion.

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0973407A (ja) * 1995-09-05 1997-03-18 Mitsubishi Electric Corp データ管理装置
JP2006343924A (ja) * 2005-06-08 2006-12-21 Hitachi Ltd ボリューム管理システムおよびその方法
JP2007328727A (ja) * 2006-06-09 2007-12-20 Hitachi Ltd 分散ファイル管理方法及び情報処理装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021039623A (ja) * 2019-09-04 2021-03-11 富士ゼロックス株式会社 情報管理装置および情報管理システム
JP7383940B2 (ja) 2019-09-04 2023-11-21 富士フイルムビジネスイノベーション株式会社 情報管理装置および情報管理システム

Also Published As

Publication number Publication date
US20160034476A1 (en) 2016-02-04

Similar Documents

Publication Publication Date Title
US10331370B2 (en) Tuning a storage system in dependence upon workload access patterns
US8595364B2 (en) System and method for automatic storage load balancing in virtual server environments
US8103628B2 (en) Directed placement of data in a redundant data storage system
US8676951B2 (en) Traffic reduction method for distributed key-value store
US9361034B2 (en) Transferring storage resources between snapshot storage pools and volume storage pools in a distributed network
JP5124551B2 (ja) ボリューム割り当てを管理する計算機システム及びボリューム割り当て管理方法
JP5244236B2 (ja) 計算機システム、方法、およびプログラム
US9794135B2 (en) Managed service for acquisition, storage and consumption of large-scale data streams
JP5400482B2 (ja) 管理計算機、リソース管理方法、リソース管理プログラム、記録媒体および情報処理システム
US20180300350A1 (en) File table index aggregate statistics
US8090792B2 (en) Method and system for a self managing and scalable grid storage
JP5099128B2 (ja) ストレージ管理プログラム、ストレージ管理装置およびストレージ管理方法
US20100125715A1 (en) Storage System and Operation Method Thereof
US20130332608A1 (en) Load balancing for distributed key-value store
US10356150B1 (en) Automated repartitioning of streaming data
JP2005275829A (ja) ストレージシステム
CN105074674A (zh) 计算机系统以及资源管理方法
US9823948B2 (en) Efficient resource utilization in data centers
JP2012504295A (ja) データベースサーバシステムのためのストレージ階層
JP2010191670A (ja) ストレージシステム、容量管理方法、および管理計算機
CN108268344A (zh) 一种数据处理方法和装置
JP6269140B2 (ja) アクセス制御プログラム、アクセス制御方法、およびアクセス制御装置
CN111352592B (zh) 磁盘读写控制方法、装置、设备及计算机可读存储介质
US10019182B2 (en) Management system and management method of computer system
JP6221717B2 (ja) ストレージ装置、ストレージシステム及びデータ管理プログラム

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 14423762

Country of ref document: US

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13895507

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13895507

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP