GB2508403A

GB2508403A - Request queue scheduler based on deadlines

Info

Publication number: GB2508403A
Application number: GB1221594.3A
Authority: GB
Inventors: Ganesan Umanesan
Original assignee: Xyratex Technology Ltd
Current assignee: Seagate Systems UK Ltd
Priority date: 2012-11-30
Filing date: 2012-11-30
Publication date: 2014-06-04
Anticipated expiration: 2032-11-30
Also published as: GB2508403B

Abstract

Requests from services 14 (clients) in one or more locations to a storage resource 102 (RAID, cloud type) are scheduled by scheduler 104. The requests comprise metadata specifying: a service ID (for example of a software application); and a data size (weight) of corresponding payload. Throughput metadata specifies a required bandwidth for a service ID. The requests are arranged into FIFO throttled queues based on service ID and then a deadline is set for processing a request in a throttled queue. The deadline depends upon the size of the request and associated service throughput and can depend also on a distance parameter providing information on aggregated throughput across all storage resources. The deadline of each throttled queue is monitored and, if a request in a queue reaches or exceeds it, the request is processed. Bandwidth is guaranteed across a parallel file system when system operates within capacity and without communicating deadlines among storage resources.

Description

Data Communication Method and Apparatus The present invention relates to a method of and apparatus for, scheduling requests for data communication from a client-side service to a service station. More particularly, the present invention relates to scheduling requests for data communication from a client-side service to a service station to enable provision of a guaranteed data rate for communication.

Traditionally, electronic data is stored locally on a user's computer system by means of a data storage resource such as a hard disk drive (HDD) or other storage media.

However, the increasing prevalence of data-heavy resources (for example, real-time high definition video) has led to an increased demand for storage capacity.

An increasingly popular area is what is known as "cloud computing". Cloud computing provides a set of scalable and oflen virtual resources over a network such as an Ethernet or the Internet. A "cloud" comprises a consolidated storage system having large storage capacity (typically at the niulti-petabyte level) which may serve independent customers (e.g. the cloud acts a storage service provider) or business units within an organisation (e.g. the cloud acts as a common corporate data store). In essence, cloud architecture means that the users generally do not own the physical computing resources they use and, instead, purchase usage from a third-party provider in a service-orientated architecture, or access a common corporate data store.

Cloud-type storage service providers are attractive to small to medium sized enterprises \vhich do not typically have the resources to invest in over-provisioned storage infrastructures which will never be used efficiently. In addition, cloud-type services enable a user having multiple devices (e.g. smartphones, tablets, laptops and workstations) to access common stored data without the need to synchronise the data between the individual devices.

Storage service providcrs offcr such uscrs acccss to thc storagc services that thcy require without thc nccd for capital expcnditure on hardwarc and softwarc solutions. In addition, the cost of hardware is becoming increasingly small in comparison to the cost of maintaining and managing a data storagc rcsourcc. Thcrcforc, this makcs thc cloud approach even more attractive to businesses. In many cases, servicc providers providc services in the manner of a utility service and billed, for example, on the basis of the storage resources (e.g. storagc space) consumed by the user or on a periodical billing basis.

It is known for the provision of services by a service provider to be covered by service level agreements (SLAs). An SLA is a negotiated agreement between a service provider (or target) offering a service and a client (or initiator) requiring use of the service. The SLA records a common agreement regarding the quality of service (QoS) to be delivered to the client. For example, in the field of data storage provision, the QoS may relate to a particular level of storage capacity or reliability which can be guaranteed by the service provider.

Increasingly, users of a storage resource may \vish to access bandwidth-intensive media such as streaming video data. In this regard, a minimum bandwidth is required to provide smooth playback of the streamed video. If the minimum bandwidth is not met or maintained by the storage resource, then there may be pauses in the video playback whilst the required data is obtained from the storage resource. This leads to an unsatisfactory user experience. As a result, sonic users ofa storage resource may prefer to specify a minimum guaranteed bandwidth in addition to a guaranteed volume of storage space.

However, to date, it has been difficult to guarantee bandwidth in known storage resource arrangements. This is because the performance of a given data storage resource is heavily dependent upon the demands placed upon it. If a number of users are using a large proportion of bandwidth of the data storage resource, then the service provider may not be able to meet the particular bandwidth requirements specified by each user. Given thc non-detcrministic naturc of storage rcsourcc acccss, this mcans that, currcntly, it is not possiblc to providc an assurancc of a givcn bandwidth whcn thc data is acccsscd.

Typically, thc only way to circumvcnt this problcm is to hcavily ovcrprovision thc data storagc rcsourcc, i.c. to havc sufficicnt sparc capacity to ensure that thc spccificd bandwidth requirements are met. However, this approach is wasteful of resources and uncconomical bccausc a significant proportion of thc bandwidth availablc to thc data storage resource must be kept free for use during abnormally heavy traffic conditions, and so is rarely used. Consequently, existing service-orientated storage providers can only guard against "worst case" scenarios of abnormally heavy load.

This issue can be mitigated by providing a "throftled" service. A throttled service is one which is bandwidth limited, as opposed to an "unthroftled" service which has no such bandwidth restriction and would, in thc absence of compcting data transfers, in principle consume all of the bandwidth available. Throttling of user's services may assist in preventing some users from consuming an unfair proportion of the available bandwidth. However, throttling in a general sense merely provides an upper limit on the bandwidth and cannot providc a minimum lowcr limit which is rcquircd in ordcr to guarantee smooth transmission oL for example, video data as discussed above.

Thcrcfore, known storagc provision arrangements suffer from a technical problem that bandwidth requirements cannot be efficiently and accurately guaranteed. This means that real-time guarantees on storage resource bandwidth cannot be made without over-provisioning of the storage resource.

"Argon.perforinance insulation for shared storage servers" Waehs et al., 5112 Usenix conference on file and storage technologies (FAST 07) and US-A-7,9 17,903 relate to scheduling methods to enable a particular quality of service to be provided.

However, these arrangement are unsuitable for parallel distributed file systems in which data is stored over a number of service systems, such as may be found in a cloud-type systeni.

According to a first aspcct of thc present invcntion, therc is providcd a mcthod of scheduling requests from a plurality of services to at least one data storage resource, the mcthod comprising: a) rccciving, on a computcr systcm, servicc rcqucsts from said plurality of scrviccs, thc service rcqucsts comprising mctadata spccifying a service ID and a data size of payload data associated with said service request, at least some of said service lBs having scrvicc throughput mctadata spccifying a required scrvicc throughput associated therewith; b) arranging, in a computer system, said requests into FWO throttled queues based on said service ID; c) setting, on a computer system, a deadline for processing of a request in a throttled queue, the deadline being selected in dependence upon the size of the request and the required service throughput associated therewith; d) monitoring, on a computer system, the deadline of each throttled queue and, if a request in a throttled queue has reached or exceeded the deadline, processing said request in a data storage resource; and e) repeating step c) above.

In one embodiment, each service request is arranged into a queue selected from the group of: throttled queue, gracefully throttled queue and unthrottled queue.

In one embodiment, in step b) service requests having a service ID to which no service throughput metadata is associated, or service requests having no service ID, are arrangcd into at least one FIFO unthrottlcd queue.

In one embodiment, if, at step d), no request in a throttled queue has reached or exceeded a deadline, the method further comprises: monitoring said unthrottled queues and, if at least one request is present in an unthrottled queue: g) processing said unthrottled request in an unthrottlcd queue; and h) repeating step d).

In one embodiment, in step b) service requests having a service ID to which service throughput metadata and a gracefully throttled metadata identifier is associated are arranged into at least one FWO gracefully throttled queue.

in one embodiment, if, at step d), no request in a throttled queue has reached or exceeded a deadline, the method further comprises: 1) monitoring said gracefully throttled queues and, ifat least one request is present in a gracefully throttled queue: j) processing said gracefully throttled request in a gracefully throttled queue; and k) repeating step d).

In one embodiment, wherein if, at step d), no request in a throttled queue has reached or exceeded a deadline, the method further comprises: 1) monitoring said gracefully throttled queues and unthrottled queues and, if at least one request is present in a gracefully throttled or an unthroftled queue: m) processing said gracefully throttled or unthrottled request in a gracefully throttled or unthrottled queue; and n) repeating step d).

In one embodiment, said gracefully throttled queues have priority over said unthrottled queues.

In one embodiment, said unthrottled queues have priority over said gracefully throttled queues.

in one embodiment, said gracefully throttled queues and said unthrottled queues have equal priority.

In one embodiment, said throttled queues are arranged in priority order, with the monitoring in step d) starting with the highest priority queue.

In one embodiment, said service throughput metadata is supplied to the computer system independently of the service requests.

In one embodiment, a plurality of data storage resources arc provided and step c) further comprises selling and selecting the deadline for the nthl request having a particular service ID in dependence upon the sum of the data sizes of the first to the nth requests having said particular service ID and the required service throughput associated with said particular service ID.

In one embodiment, cach rcquest having a particular service ID has the same data size and said deadline for the nth request having a particular service ID is set in dependence upon thc request number n and thc known weight of each rcquest.

In one embodiment, each request from a particular service ID comprises a distance parameter x associated therewith relating to the sum of the data sizes of the first to the nih requests from said particular service ID.

In one embodiment, step c) comprises sefting, on a service station, a new deadline for a request based on the distance parameter x of said request and the service throughput metadata associated therewith.

Tn one embodiment, the request comprises said service throughput metadata.

In one embodiment, said request comprises service throughput metadata combined with said distance parameter x to provide deadline data to said computer system.

Tn one embodiment, in step c) the computer system determines the deadline for a request from said distance parameter x of a request and service throughput metadata received independently by said computing system.

In one embodiment, step c) further comprises: sefting a new deadline for the next request in dependence upon the distance parameter x of the next request, the distance parameter of the previously-processed request processed in step e) and the service throughput metadata.

In one embodiment, at least one service is disfributed across a plurality of locations such that each service ID is associated with a plurality of location IDs.

In onc cmbodimcnt, cach scrvice rcqucst eompriscs a scrvicc ID and a location ID.

In onc embodiment, step c) furthcr compriscs setting and selecting thc deadline for the nih request having a particular service ID and location ID in dependence upon thc sum ofthe data sizes of the first to the n'1' requests having said particular service ID and location ID and thc required servicc throughput associatcd with said particular servicc ID.

In one embodiment, each request has a distance parameter x associated therewith, said request number n corresponding to the nth request having a particular service ID and location ID, and said distance parameter comprising the sum of the data sizes of the first to the nih requests having said location ID.

Tn one cmbodiment, step g) further cornpriscs: setting a ncw dcadlinc for the ncxt request in dependence upon the distance parameter x of the next request having a particular location ID, the distance parameter of the previously-processed request having said location ID processed in step c) and the service throughput metadata.

Tn one embodiment, a plurality ofparallel data storage resources is provided.

According to a second aspect of the present invention, there is provided a method of scheduling requests from a plurality of services to a plurality of networked data storage resources, the method comprising: a) receiving, on a computer system, service requests from said plurality of services, the service requests comprising metadata speeiing a service ID and a data size of payload data associated with said service request, at least some of said service IDs having service throughput metadata specifying a required service throughput associated therewith; b) arranging, in a computer system, said requests into FIFO throttled queues based on said service ID; c) setting, on a computer system, a deadline for processing of the nih request having a particular service ID in a throttled queue, the deadline being selected in dependence upon the sum of the data sizes of the first to the nth requests having said particular service ID and the required service throughput associatcd with said particular scrvicc ID; d) monitoring, on a computcr systcm, thc dcadline of cach throttlcd qucuc and, if a rcqucst in a throttlcd qucuc has reached or exceeded the deadline, processing said request in a data storage resource; and c) rcpcating stcp c) abovc.

According to a third aspect of the present invention, there is provided a request schcdulcr for a scrvicc station, said requcst schcdulcr bcing configured to scheduic requests from a plurality of services accessing said service station, the request scheduler being operable to: receive service requests from said plurality of services, the service requests comprising metadata specifying a service ID and a data size of payload data associated with said service request and at least some of said service IDs having service throughput metadata specifying a required service throughput associated therewith; arrange said requests into FIFO throttled queues based on said service ID; set a dcadline for processing ofa request in a throttled qucuc, the dcadlinc being sclcctcd in dependence upon the size of the request and the required service throughput associated therewith; monitor the deadline of each throftied queue and, if a request in a throttled queue has reached or exceeded the deadline, processing said request in a data storage rcsourcc; and rcpcating thc stcp of monitoring.

According to a fourth aspect of the present invention, there is provided a computer program product cxccutablc by a programmable processing apparatus, comprising onc or more softwarc portions for performing thc stcps of thc first and sccond aspccts.

According to a fifth aspcct of thc prcscnt invcntion, thcrc is providcd a computer usabic storagc medium having a computcr program product according to thc fourth aspcct storcd thcrcon.

According to a sixth aspect of the present invention, there is provided an electronic data store comprising a data storage resource and the request scheduler of the third aspect.

Embodiments ofthc prcscnt invcntion will now bc dcscribcd in detail with reference to thc accompanying drawings, in which: Figure 1 is a schematic diagram of a cloud network; Figure 2 is a schematic diagram of an embodiment of an electronic data store comprising a single scrvicc station; Figure 3 is a schematic diagram of an embodiment comprising a distributed environment comprising multiple service stations and multiple service origins; Figure 4 is a schematic diagram showing the communication between service origins, the request scheduler, request coordinator and service station; Figure 5 is a schematic diagram illusating the distance parameter included with service requests; Figure 6 is a schcmatic diagram showing thc processing of service rcqucsts in the request scheduler; Figure 7 is a flowchart illustrating thc operation of thc rcordcring proccss in thc request scheduler; Figure 8 is a flowchart illustrating thc opcration of the dispatch process in thc rcqucst scheduler; Figure 9 is a schcmatic illustration of a single FIFO qucuc as scheduled by thc request scheduler; Figure 10 is a schematic illustration of a single FIFO queue as scheduled by the request scheduler; Figure 11 is a schematic diagram showing thc processing of service requests in the request scheduler according to an alternative embodiment; Figure 12 is a flowchart illustrating the opcration of the reordcring process in thc request scheduler according to an alternative embodiment; Figure 13 is a flowchart illustrating the operation of the dispatch process in the request scheduler according to an alternative embodiment; Figure 14 is a flowchart illustrating the operation of the dispatch process in the request scheduler according to an alternative embodiment; Figure IS is a flowchart illustrating the operation of the dispatch process in the request scheduler according to an alternative embodiment; Figure 16 is a flowchart illustrating the operation of the dispatch process in the request scheduler according to an alternative embodiment; Figure I? is a schematic diagram showing the processing of service requests in the request scheduler according to an alternative embodiment; Figure IS is a flowchart illustrating the operation of the dispatch process in the request scheduler according to an alternative embodiment; Figure 19 is a schematic graph showing the operation of the present invention on a service station.

Figure 1 shows a schematic illustration of an electronic data store 10 provided by a service provider. The data store 10 comprises a plurality of storage units 12. Each storage unit 12 may take the form of for example, an individual hard drive or a collection of hard disk drivcs (HDDs) linked togcther through a protocol such as Redundant Array of Incxpcnsivc Disks (RAID) to form a logical unit. However, irrcspcctive of thc number or configuration of HDDs present, the data store lOis presented to the service origins 14-i as a singlc logical drive.

A plurality of service origins 14 connect to the data store 10 through a cloud network 16. The scrvice origins 14 may take any suitable form. For example, they may comprise workstations, mobile telephones (such as, for example, so-called "smartphones"), laptop computers, tablet computers, servers or other computing equipment. hi the context of the described embodiments, the clients may take the form of one or more programs (for example, a web browser system) running on a computer hardware system. Additionally, the service origins 14 may comprise client programs which form part of a parallel file system, distributed file system or other distributed network services.

The cloud network 16 may take a number of forms, for example, an internet network, a cable network or a mobile network. The cloud network I 6 enables each user of each client 14 to read data from, or write data to, the data store 10 as if the data was stored locally. Each client computer 14 has an SLA with the service provider of the data store 10 which specifies the QoS required by the user of the client computer 14 whilst connected to the data store 10. For example, the SLA might speeiz the type of data access required (e.g. random or sequential) and/or the bandwidth/latency requirements of the access required to, or the retrieval required from, the data store 10.

Figure 2 shows a first embodiment of an electronic data store 100. The electronic data store 100 comprises a service station 102 and a request scheduler 104. In this example, the service station 102 comprises a server 106 and at least one data storage component 108. In an example, the data storage component 108 may comprise a group of approximately five to eight physical drives linked together in a RAID arrangement.

RAID architccture combines a multiplicity of small, incxpcnsive disk drivcs into an array of disk drives that yiclds performanec that can excced that of a singlc large drivc.

This arrangement enables high speed access because different parts of a file can be read from different dcviccs simultancously, improving acccss spccd and bandwidth.

Data interleaving in a RAID arrangement is usually in the form of data "striping" in which thc data to be stored is broken down into blocks called "stripc units". The "stripe units" are then distributed across the physical drives. Therefore, should one of the physical drives in a group forming a storage component 108 fail or become corrupted, the missing data can be recreated from the data on the other drives. The data may be reconstructed through the use of the redundant "stripe units" stored on the remaining physical drives using known RAID techniques such as XOR.

The physical drives may take any form of storage device, such as, for example, tape drives, disk drives, non-volatile memory, or solid state devices. Although most RAID architectures use hard disk drives as the main storage devices, it will be clear to the person skilled in the art that the embodiments described herein apply to any type of suitable storage device. Further, a physical drive may take the form of a single partition on a hard disk drive. Therefore, a single hard disk drive may comprise a plurality of physical drives in the context of the electronic data store 100.

In this embodiment, the data storage component comprises an Object-based Storage Device (OSD). An OSD is a computer storage device which operates at a higher level of abstraction than block-orientated interfaces. An OSD does not read and write fixed sized blocks of data as in a conventional file system structure. Instead, the OSD standard organizes data into variable-sized data packages known as objects. Each object is associated with data and metadata comprising an extensible set of attributes which describe the object.

However, the exact form and nature of the service station 102 is not material to the present invention. In the context of this application, the service station 102 is a single storage facility for data to which I/O requests can bc communicated and to which data can be sent to, storcd on, and retrieved from. The servicc station 102 may, in thet, comprise a number of different OSDs 108 connected together through a single server or through multiple servers. The skilled person would bc readily aware of the differcnt forms or structures that the service station 102 may take within the scopc of the present invention.

The request scheduler 104 controls the flow of data into and out of the storage resource 102, and controls access to the service station 102 from client computers 14 through a network 110 using, for example, the TCP/IP protocol. The network 110 may comprise a local area network (LAN) or the Internet using existing network infrastructure.

The request scheduler I 04 may take a number of forms; for example, the request scheduler 104 may take the form of a metadata server. Alternatively, the request scheduler 104 may take the form of a software or hardware interface run on the service station 102. The skilled person would be readily aware of the variations which ff11 within the scope of the present application.

The request scheduler 104 is operable to receive aplurality of service requests R from the service origins 14 and schedule the requests to provide a guaranteed service rate or service throuphput i.e. a guaranteed rate of work done for groups of service requests across the entire distributed system where service requests with same Service IDs could originate at more than one Service Origins and reach more than one Service Stations for service completion. In general, the requests R comprise metadata identi4ng payload data (e.g. I/O read/writes) to be sent to the service stations from the service origins. By scheduling these requests, the flow of data to the service stations from the service origins can be scheduled and optimised to provide guarantees of bandwidth or other parameters as required.

Thc i/O rcqucsts R may bc in any suitabic format. For example, thc I/O requests R may bc in thc OSD (Objcct storage Device) protocol. Thc OSD protocol uscs a SCSi command set developed by the T tO committee of the Tnternational Committee for information Technology Standards. In thc OSD standard, objccts arc spccificd with a 64-bit partition ID and a 64-bit objcct iD. The command intcrflice compriscs storage commands to create and delete objects, to write bytes and read bytes to and from individual objccts, and to "set" attributes on objccts, and to "get" thosc attributes on objects. Alternatively, other formats for the requests R may be used, and these will be readily apparent to the skilled person.

An alternative embodiment is illustrated in Figure 3. This configuration illustrates a distributed networked environment 200. This distributed environment 200 may represent any distributed environment where a number of service stations 102 exist to serve service requests R coming in from a number of service origins 14 where service requests R originate. The system may have one or more service coordinators 112 who helps service origins 14 send service requests R to service stations 102 and get their service completed.

The second embodiment of the data store 200 comprises a plurality of parallel but separate peer service stations 102-i. Each service station 102-i is substantially the same as for the previous embodiment and is connected to the network 110 whereby it is operablc to receive requests R from one or more service origins 14. Again, in this embodiment, the requests R comprise metadata identi1'ing payload data (e.g. I/O read/writes) to be sent to the service stations from the service origins. However, service requests may be used for any suitable purpose and may not necessarily relate to 110 or read/write requests. The skilled person will be readily aware of variations which will thil within the scope of the present invention.

Whilst, in Figure 3, six service stations 102-1, 102-2, 102-3, 102-4 and 102-5 are shown, in principle any number of service stations 102 may be provided as required.

Each scrvice station 102-i has a rcqucst scheduler 104-i. The request scheduler 104-i controls thc organisation of requcsts into the service station 102-i. The operational features of the request schedulers 104-i may be implemented in either a hardware or software layer. The skilled person will be readily aware that the above features of the present embodiment could be implemented in a variety of suitable configurations and arrangements within the context of the present invention.

The service stations 102-i communicate over the network 110 such as a local area network (LAN) or the Internet using existing network infrastructure, depending upon the relative location of the service stations 102-i and the request scheduler 104.

Each service coordinator 112 is also operable to communicate with one or more service stations 102-i through the network 110.

An example of the connections and communication between one or more service origins 14, a service coordinator 112, a request scheduler 104 and service station 102 is shown in Figure 4. The configuration shown may be used in either of the first or second embodiments.

As shown in Figure 4, each request R comprises a number of attributes.

Depending upon the nature of the request R, these attributes may, for example, comprise 1/0 metadata at the head of an 110 request.

Each request R has a service ID S, which identifies the respective service (e.g. software or hardware program or resource) which may be operating on one or more service origins 14.

It is also envisaged that a service having service ID S, (which may be, as previously described, a software application or other distributed service application or utility) may be disfributed across a number of locations (e.g. across a number of service origins 14, or different parts of single system, or merely distributed modules of a service).

Therefore, requests R may be received from a single service ID S, may be received from multiple service locations. Consequently, a further parameter of location ID L is associated with each service ID S,.

Therefore, as an example, a single service ID Si may be spread across a plurality of locations having, for example, location IDs Li, L2 and L3. The location ID L is attached to each service request R. Each request also has a request number n. The request number represents the number of the request R from service ID S and location ID L. Therefore, the n' request from service ID S, and location ID L would be represented as RtI(SL Lv). However, whilst, for the purposes of this disclosure each request is associated with a request number n, this need not be the case and each request need not be numbered in practice.

Additionally, each request R has size metadata w11(S, Lv), i.e. metadata pertaining to the volume of data contained in the request Rfl(SL L) from service ID S, and location ID L The size w1(S, L) is known as the "weight" of the request R and determines, in part, how long the service station 102 will take to service the Tb request R1F Additionally, a fhrther parameter of distance x (S, L) is attached with each request. Since, with plural service stations 102-I to 102-i receiving requests R(S, L) from a plurality of different locations and service IDs, a number of different requests from a particular service ID and location ID may be handled in parallel by different service stations 102-i. Consequently, in order to provide a deadline system which, on aggregate, meets the required service throughput of the service ID S. for each location ID L, the request R(S L) must comprise sufficient information to set a deadline without a priori knowledge ofthe processing being carried out in other service stations 102.

In other words, cach request R11(S, L) must comprisc self-contained information regarding the relationship of that particular request to previous requests such that request R(S, L) can be processcd in the correct tirnefrarne as wiH be described.

In a scqucnce of incoming rcquests for a particular service ID S having location ID L, the distance x(S, L) for the n request is calculated from equation 1) below: x(Sj) = where x is the distance for request n, and w1 is the weight (I/O size) for request i where i is in the range of 0 to ii.

Take, for example, a service ID S 1 having location ID Li and, therefore, requests R(S 1, Ll). In this case, the distance x, for request n for service ID Sl at location Ll comprises the sum of the I/O sizes ofrequests 0 (i.e. the first request) to request n-i from service ID 51 at location ID Li, plus the weight w1 of request RJS1, Ll) itself Concomitantly, for location ID [2 of service ID SI, the distance x for requestii for service ID 51 at location L2 comprises the sum of the I/O sizes of requests 0 (i.e. the first request) to request n-I from service ID 52 at location ID L2, plus the weight w11 of request R(S I, [2) itself The concept of distance is shown diagrammatically in Figure 5 where the distance parameter can be visualised as the sum of the weights of previous requests plus that of the current request.

In summary, a deadline for a particular request can be utilised which is dependent upon the previous requests from a particular service ID S, and for a particular location ID L, i.e. the "distance" from the earlier requests from that service ID S, and that location ID L. In this way, an aggrcgatcd minimum bandwidth can bc guarantccd without administration from a ccntral scrvcr attcmpting to handlc distribution across a plurality of service stations to meet a guaranteed bandwidth.

Should a minimum bandwidth bc guarantccd for a particular scrvicc having service ID S, service throughput metadata T(S) is provided for service ID S,. hi this embodiment, thc scrvicc throughput metadata 1(5,3 is supplied by the scrvicc coordinator 112 to the request scheduler 104. However, alternatives are possible and the request scheduler 104 may, for example, contain an internal record of the service throughput metadata T(S).

The service throughput metadata T(S) specifies, for service ID S, the minimum bandwidth that the service S, requires. This information is supplied to the request schedulcr 104 and is associated with a particular service TD S,. Thc service throughput information may, for example, be supplied to the request scheduler 104 in the form of an SLA previously agreedprior between the client or service prior to request transmission.

As will be described, thc request scheduler 104 is ffirther operable to proccss and schedule the requests R,(SL) to determine the appropriate order in which to service the requests. The request scheduler 104 is then operable to send the requests R11(S., L) in the appropriate order for servicing by the service station 102.

To illustrate how the parameters of each request R(S. L) are used to provide a guarantee of bandwidth, the method of operation of the present invention will now be described \vith reference to Figures 6 to 8. Figure 6 shows a schematic diagram of the movement of a request R1AS, L) from the service origin 14 to the service station 102.

Figures 7 and 8 show flow charts representing the method of an embodiment of the invention.

The rcqucst schcduler 104 has two indcpendcnt stages of operation. Thc first stage is to reordcr incoming requests. Once the requests have becn reordered, thcn the second stage of dispatching the requests to the service station 102 can be carried out.

The description of thc rcordering stage is outlined below.

Step 300: Initiate throttled queues At step 300, the request scheduler 104 configures a plurality of First-In First-Out (FF0) queues for service.

Step 302: Initiate deadlines far throttled queues At step 302, an initial service deadline d (S) is set. The service deadline d,(S) specifies the end of a time period within which request n in a queue of requests having service ID S must be serviced in order to meet the service throughput requirements of the throttled queue for a particular service ID S. Initially, when requests are first received, they can effectively be served immediately. Therefore, the initial deadline is set to the current time.

Step 304: Wait for service request At step 304, the request scheduler 104 waits for a service request to be received from one of the service origins. The method then proceeds to step 306.

Step 306: Service request received? At step 306, it is determined whether a service request has been received. Ifno service request has been received, the method proceeds back to step 306.

However, if a service request is received, the method then proceeds to step 310.

The request scheduler 104 receives the 110 requests R11(S), each of which includes the service ID S and I/O size w(S) and, optionally, may have service throughput metadata 1(5,3 associated therewith, from the servicc origin 14 via the network.

Step 308: Reorder incoming requests by service ID Once the requests R(S, L) have been received, the request scheduler 104 reorders the requests into First-In First-Out (FIFO) queues for service. At step 308, the incoming requests R11(S, L) are sorted by service ID S and allocated to an individual service so that each queue contains only requests R(S, L) from the particular service having that service ID S,.

The method then proceeds back to step 304 to process and reorder other incoming requests.

The method above operates continuously in the request schedulcr 104 when in operation. Once the requests are organised into appropriate queues, then they can be dispatched to the respective service station 102 in the next stage of operation.

The dispatch process will be described with reference to Figurc 8.

Step 400: Initiate At step 400, thc dispatch proccss is initiated. The method then proceeds to step 402.

Step 402: Lc service station ready? At step 402, it is determined whether the service station is ready to receive a new scrvicc rcqucst, i_c. if it has finished scrvicing thc previous request thc scrvicc station 102 has been handling. If not, thc mcthod proceeds to step 404.

If thc scrvicc station is ready to scrvicc a ncw request, thc method pmceeds to step 406.

Step 404: Wait At step 404, the method waits for a predetermined time to enable the service station to complete the current request and be ready to receive a new request. This time pcriod may bc any suitable timc pcriod.

Step 406: Throttled service request detected? The request scheduler 104 examines the service deadline d(S, L) for each throttled queue, starting with the highest priority queue (in this example, the leftmost queue in Figurc 3), i.c., whcre thcrc arc M scrviccs, thc qucuc having thc highcst priority valuc (M-1). Conscqucntly, thc M1fh servicc has a priority valuc of 0, i.c. thc lowcst value of priority, and this queue will be served last in the throttled queues. If the deadline for thc highcst priority throttlcd qucuc has not yct bccn rcachcd, the rcqucst schcduler 104 movcs to thc ncxt throttlcd qucuc in line in priority ordcr.

Priority ordcring providcs prcdictablc pcrformancc dcgradation or pcrformancc improvement when system capability becomes respectively low or high. The lower priority services will not meet deadlines and will suffer from performance degradation when the system capability becomes low and not enough to server all throttled queues.

Thc lowcr priority scrviccs will improve gradually as system capability improvcs.

Additionally, the throttling mechanism falls back to a priority based servicing when the system capability is not enough to meet all throttled service requests. In other words, setting high throughput values for all or somc of thc qucues means deadlines will expire quickly and queues will be served in their priority order.

This process continues until a throttled queue is reached which has a deadline which has been reached or has passed. At this point, the method proceeds to step 408.

If, however, the request scheduler 104 reaches the end of the throftled queues and none of the queues has a deadline which has passed, then the method proceeds back to step 404.

Step 408: Serve queue for which deadline has been reached or passed If in step 406, it is detected that a queue has a deadline which has been reached or has expired, then the request scheduler 104 will service first request R11(S, L) in line in that queue. Since the examining step 406 is carried out in priority order, in practice this means that requests Rn(S) in the throttled queues are serviced starting with the throttled queue having the highest priority for which the deadline d(S, L) for servicing has been reached or has passed.

When a queue is serviced, the request scheduler 104 passes the respective tO request R(S, L) at the head of that particular queue to the service station 102 for processing.

Step 410: Set new deadline for serviced queue At step 410, once the throttled queue has been serviced in step 408, a new deadline is set by which time the next request R(S, L) in the FIFO queue is to be scrviccd. Thc ncw dcadline d(S, L) to bc sct is dcpcndcnt upon thc nature of the system and the required throughput.

The simplest ease is for the configuration shown in Figure 2. In this arrangement, a service having service ID S, originating from a single location having location ID L sends requests to a single service station 102.

In this particular case, the location ID L is not needed. Therefore, it may optionally be omitted from the service request R. Alternatively, if the location ID L is included in the service request R, it can be effectively ignored by the service station 102 because there will only be one location ID L in each queue.

Additionally, where a single service station 102 is used, the distance parameter is not required. Therefore, the service request R in this situation may omit the distance parameter. Alternatively, the distance parameter may simply be ignored by the service station 102.

Consequently, requests from a single service ID at a single location to a single service station need only comprise the parameters of service ID and weight. Other parameters may be required and not used, depending upon the particular network eongfiguration.

For the configuration ofa single service sending requests from a single location to a single service station, the deadline d(S) (where y is a constant) is then set based on the 1/0 size w11(S) oL and service throughput metadata T(S) associated with, the next throttled request R1AS) in line in the relevant queue. Therefore, the deadline is set according to equation 2): 2) dr(Si) =c.i.+ where d is the deadline for the queue for requests having service ID S,, e.t. is the current time, w is the I/O size (in bytes) and 17S,) is the required service throughput (in Mb/s) associated with service TD S,.

In other words, thc nev deadline is thc current time plus the time required to process a given amount of data in a request at a required data rate (or bandwidth).

Meeting this deadline will mean that the required service throughput is achieved.

In an alternative configuration, a service having service ID S and a single location ID L may send requests to multiple service stations. In this arrangement, each service station 102 sets deadlines independently of each other service station 102 and there is no communication therebetween. Consequently, it is necessary to utilise the distance parameter. However, again, in this example the location ID L is effectively a constant, and so it can be ignored in the following description.

The new deadline d(S) for the next request R(S) set in dependence upon a number of factors. As for the first example, the deadline ci (S) for request R11(S) is dependent upon the I/O size w(S) and service throughput metadata T(S) for the requests having service TD S. However, the deadline is set with the aim of achieving aggregated throughput across all of the service stations 102-I -102-i, i.e. achieving the requirements set out in the service throughput metadata T(S) but in parallel with other service stations 102 processing requests from the same service having service ID S. Therefore, the distance parameter xis required, together with a further parameter, the last served distance I. The last served distance parameter / is, effectively, the distance of the last served request in the queue for service ID S,. In other words, for request R11(S) the last served distance I would be equal to the distance of the previously served request R1(S) (i.e. the request most recently processed in step 408), as set out in equation 3): 3) = 1=0 where 1,, is the last served distance for request R11(S) which is equal to the distance of request R111(S), i.e. sum of the weights of requests R0(S) to R111(S,J.

The deadline for request R(S) is, thus, calculated according to equation 4): 4) ci (S)=cL+ (x(S)-I(S)) T(S1) where d is the deadline for request R1(S), e.t. is the current time, w is the 1/0 size (or weight) (in bytes) of request R, x is the distance parameter of request n, i, is the last served distance for request R (equal to the distance of previously-served request R0) of service station 102-,! and T is the required service throughput (in Mb/s).

Tn other words, the new deadline is the current time plus thc time required to process a given amount of data in a request at a required data rate (or bandwidth) in order to achieve an aggregated throughput across all of the service stations 102-i to which requests having a particular service TD S have been sent. Meeting this deadline will mean that the required service throughput is achieved.

Figure 9 provides an example of this. In a queue comprising service requests from service ID SI having a single location ID LI (omitted from the Figure for clarity), the head request R3(S I) is immediately followed by request R5(S I).

R1(Sl) is the first request in the queue, and so has a distancex3 equal to w1+ w2+w3, and a last served distance h equal to 0 (because this is the first request in the queue, there is no last served distance). Therefore, the deadline d3(S1) for request R1(S1) is equal to equation 5): 5) d(Sl)=c.L+ +w2+w3)-0 T(S1) Once request R3(S I) has been served, R5(S I) is the next request in line for servicing. The distance x5 for R5(Sl) is equal to w1+ w2+w3+w4+w5 and the last served distance I for R5(S 1) is equal to the distance of R1(S 1) or wj+ w2+w3. Therefore, the deadline for R5(S1) is equal to equation 6): 6) d. (SI) = ci. + (Ml + 142 + w3 + 144 + w5) -(wl + w2 + \v3) T(SI) Which means that the new deadline for request R5(S I) is equal to equation 7): 7) d(Sl) =ci.+ w4+w5 T(Sl) In the final case, services having a service ID S originate from a number of locations having location IDs Land are serviced by a number of service stations 102.

This is done by utilising a deadline for a particular request which is dependent upon the previous requests from a particular service ID S and for a particular location ID L, i.e. the "distance" from the earlier requests from that service ID S and for that location ID L. In this way, an aggregated minimum bandwidth can be guaranteed without administration from a central server attempting to handle distribution across a plurality of service stations to meet a guaranteed bandwidth.

In a sequence of incoming requests for a particular service TD S having location ID L, the distance x(S, L) for the nthl request is calculated from equation 8) below (which is identical to equation 1)): 8) w1(S1,L1) 1=0 where x1, is the distance for request ii, and it' is the weight (I/O size) for request / where / is in the range of 0 to 11.

Take, for example, a service ID SI having location ID Li and, therefore, requests R(S 1, LI). In this case, the distance x, for request n for service iD 51 at location Li comprises the sum of the I/O sizes of requests 0 (i.e. the first request) to request n-i from service ID Si at location iD Li, plus the weight w of request R11(Sl, LI) itself Concomitantly, for location ID L2 of service ID Si, the distance x for request n for service ID Sl at location L2 comprises the sum of the I/O sizes of requests 0 (i.e. the first request) to request n-i from service ID S2 at location ID L2, plus the weight w of request R11(Sl, L2) itself Knowing the time in which these requests need to be serviced (i.e. the 110 sizes divided by the service throughput TS/)) enables a deadline system which is able, on aggregate, to meet bandwidth requirements across the distributed system and to meet these requirements fairly across all of the locations of the service having service ID Si.

Where 1,,, is the last served distance for request R1(S, L) which is equal to the sum of the weights of requests Ro(S, L) to R11(S, L) as set out in equation 9): 9) l,(S1, L) = w1(S, L1) The deadline for request R(S, L) is, thus, cacdated according to equation 10): 10) d (S,L)=c.L+ T(S,L) where d is the deadline for request R1(S, Lv), ct. is the current time, w,, is the 1/0 size (or weight) (in bytes) of request R,, (St, L) x,, is the distance parameter of request n, I is the last served distance for request R (S, L) (equal to the distance of previously-served request Rm (S, L) of service station 102 and T(S) is the required service throughput (in Mb/s).

Therefore, in this embodiment, the deadlines for each service ID S, having location ID L are effectively independent between location IDs. In other words, within a single queue, the deadline for request R1(S 1, Li) is dependent upon the distance of the most recently-served request R1 (Si, Li) having the same location ID Ll. Other requests in the same queue having different location IDs do not affect the deadhne for request R1(Si,Li).

Therefore, in this embodiment, the last served distance is not necessarily that of the previous request in the queue for service ID but for the previous request in the queue having the same location ID L. In other words, for a given location ID L, the new deadline is the current time plus the time required to process a given amount of data in a request at a required data rate (or bandwidth) in order to achieve an aggregated throughput across all of the service stations 302 to which requests having a particular service ID S, have been sent. Meeting this deadline will mean that the required service throughput is achieved.

Figure 10 provides an example of this. In a queue comprising service requests from service ID Sl and location IDs Li to L3, the head request R3(Sl, Ll) is immediately followed by the following sequence of requests: R2(Si, L2), R3(Sl, L3), R5(Sl, Ll), Rio(Si, L2) and Rigo(Sl, L3).

R](Sl, Li) is the first request in the queue, and so has a distancex3(Si, Li) equal to w (Si, Li) + w2(Si, Li) +w? (S1, Ll) and a last served distance I? (Si, Li) equal toO (because this is the first request in the queue, there is no last served distance). Therefore, the deadline d3(Sl, Ll) for request R3(Si, Li) is equal to equation 5): ii) d(Si,Li) = c.t.+ (512 LI)-i-\v2 (SI, LI H-\v3(S I,LI)) -O T(Si) Once request R2(Sl, Li) has been served, R2(Si, L2) is the next request in line for servicing. The distance x2 (Si, L2) for R2(S i, L2) is equal to w1 (S 1, L2) + w2 (S 1, L2) and the last served distance 12 for R2(Si, L2) is equal to 0, since this is the first request for location ID L2. The deadline d7(S i, L2) can then be calculated as for R2(Si, Li) in equation II) above.

Once request R2(Sl, L2) has been served, the next request in line is R1(Si, L3).

The distancex3 (Si, L3) forR3(Si, L3) is equalto wj (Si, L3) + w2 (Si, L3) + w (Si, L3) and the last served distance l (S I, L3) for R3(S I, L3) is equal to 0, since this is the is first request for location ID L3. The deadline d3(S1, L3) can then be calculated as for R(S I, LI) in equation II) above.

The next request in line is R5(Sl, Ll). The distancex5 (Si, Li) for R5(Si, Li) is equal tow1 (SI, LI) + W2 (SI, LI) + w? (SI,LI) + w4 (SI, LI) + w5 (SI, LI) and the last served distance 15 for R5(S i, L2) is equal to the distance of the previously served request for location ID Li, namely R3(Si, Li), or w1 (Sl, Ll) + w2(Si, Li) +w3 (Si, Li).

Therefore, the deadline d5(S I, LI) is equal to equation 12): i2) d(S1,L1) = ct. + (v1(S1,L1)+ w2(Sl,I.1) + w3(Si,L1)+ w4(Sl,Ll) + w5(S1,L1)) -(wl(S1,L1) + w2(S1,L1) +w3(S1, Li)) T(S1) which means that the new deadline for request R5(Si) is equal to: 13) d. (S1,L1) = c.t.--w4(SI,Ll) + w5(Sl, LI) T(S1) The penultimate and final requests in the queue shown in Figure 10, R10(S I, L2) and R100(S 1, L3), can be calculated in a similar manner with, for example, R100(S 1, L3) having a last served distance, 1100 (Si, L3) equal to the distance of the previously served request from location ID L3, namely R1(Sl, L3).

Once the new deadline has been set, the method then proceeds back to step 402.

it will be appreciated that not all of the above variables are necessary in each case.

For example, as set out in the case of a single service station arranged serve all requests in a distributed system, the distance parameter is not required. Since all service requests with weights are directed toward a single service station the service station itself can determine the distance if necessary. !5

Additionally, sonic service requests may conic with zero weight meaning that the service station that receives this service request wastes no efforts to complete this service request.

in the above disclosure, the service rate, i.e., the rate at which a service station \vorks to complete a service request is Weight/Time where Time is time taken to complete service request.

For a group of service requests, i.e., service requests with same service ID, service throughput corresponds to average service rate over all the service requests completed so far.

The above embodiments provide configurations where bandwidth can be guaranteed for throftled services in, in one example, a distributed environment. However, throttled services alone may not ifilly utilise the capacity of a service station. In order to compcnsatc for this, thc following cmbodimcnts providc for additional scrviccs to use any rcmaining capacity without compromising thc bandwidth guarantees for the throttled services. The two additional services that may be provided comprise gracefiully throttled serviccs and unthrottled scrviccs.

Gracefully throttled services are services which have a guaranteed minimum bandwidth but which arc not rcstrictcd to that minimum limit and may consume morc bandwidth if the capacity is available to do so. If the service station has capability to do so after servicing all the throftled service requests, the service station may increase the service throughput for particular service IDs. Gracefully throttled services are identified by metadata received by the service station identifying particular service IDs as relating to a gracefully throttled service. This metadata may be sent as part of the service throughput metadata, or may comprise separate metadata.

Unthrottled services are services which have no minimum bandwidth requirements at aft The service station may accommodate these service requests if there is capability to do so. Unthottled requests correspond to service TDs that have no associated scrvicc throughput rcquircmcnts.

The scheduler gives first priority to throttled service requests thereby guarantccing thc scrvicc throughput of service IDs with throughput rcquircmcnts. Aftcr this, the graccfully throttled and unthrottled scrvicc rcqucsts can be scrviccd using a number of fair scheduling mechanisms. An example of this may be a "round-robin" schcduling.

Figurc 11 shows a schcmatic (similar to Figurc 6) showing thc gencral proccss of opcration. In this cmbodimcnt, thc qucucs arc dividcd into throttlcd scrvices (shown in white) and unthrottled services (shown in grey). Gracefully throttled services are also shown in black in the throttled section. Figure 12 shows a flow chart of the reordering process of this embodiment.

Step 500: Initiate throttled queues At step 500, the request scheduler 104 configures a plurality of First-In First-Out (F1FO) queues for service.

Step 502: Initiate deadlines far throttled queues At step 502, an initial service deadline d,, (St) is set. The service deadline d(S) specifies the end of a time period within which request n in a queue of requests having service ID S must be serviced in order to meet the service throughput requirements of the throttled queue for a particular service ID S. Initially, when requests are first received, they can effectively be served immediately. Therefore, the initial deadline is set to the current time.

Step 504: Initiate gracefully throttled queues At step 504, the request scheduler 104 configures a plurality of First-In First-Out (FIFO)gracefully throttlcd queues for scrviee.

Step 506: Place service marker fur gracefully throttled queues At step 506, a service marker (shown in Figurc 11) is placcd ncxt to the next gracefully throttled service queue in line for servicing. The gracefully throttled queue to which thc scrvicc marker is placed may be selected on any appropriate basis; for example, by queue priority, by a round-robin system or by a random selection.

Step 508: Initiate unthrottied queues At step 508, the request scheduler 104 configures a plurality of First-In First-Out (FF0) queues for service as unthrottled queues.

Step 510: Place service marker for unthrottled queues At step 510, a service marker is placed next to the first unthrottled service queue to demark the throttled and unthrottled service queues.

Step 512: Waitfor service request At step 512, the request scheduler 104 waits for a service request to be received from one of the services. The method then proceeds to step 514.

Step 514: Service request received? At step 514, it is determined whether a service request has been received. If no service request has been received, the methodpmceeds back to step 512.

However, if a service request is received, the method then proceeds to step 516.

The request scheduler 104 receives the I/O requests RJS,J, each of which includes the service ID S1 and I/O size w(S1) and, optionally, may have service throughput metadata T(S1) associated therewith, from the service origin 14 via the network The I/O requests R(S1) comprise metadata relating to a data payload from the service having service ID S. Step 516: Reorder incoming requests by service ID and type Once the requests RJS1, L) have been received, the request scheduler 104 reorders the requests into First-In First-Out (FIFO) queues fbr service. At step 518, the incoming requests R0(S, L) are sorted by service ID S and allocated to an individual service so that each queue contains only requests R4S,, L) from the particular service having that service ID S. As shown in Figurc 11, thc rcqucsts R11(S) arc ordcrcd into throttled and unthrottlcd scrvicc queues. Requests R1AS) for thc throttled queues arc idcntificd by thc presence of service throughput metadataT(S) relating to the specific service ID S of the request R. Thc service throughput metadata T(S) identifies that particular request R11(S) as coming from a client or scrviee which has specificd a particular minimum bandwidth requirement.

Requests R1(S) in the unthroftied queues are requests that will be addressed if sufficient capacity on the service station 102 exists to do this once the requests R11(S) in the throttled queues have been addressed. Unthroftled requests R11(S) do not have any service throughput metadata T(S) associated therewith. The bandwidth remaining afler the throttled service requests have been serviced will be shared between the unthrottled requests in the unthrottled request queues.

There is also a priority order to the throttled queues. As shown in Figure 12, in a given service cycle the leftmost queue (having the highest priority) will be serviced first, followed by queues to the right. Finally, once the throttled queues have been served, the unthrottled qucucs will be scrvcd if sufficient bandwidth rcmains.

The priority order may be set in a number of ways. An arbitrary system would be for thc first uscrs to purchasc or acccss thc storagc to bc allocated thc highcst priority.

Anothcr schcmc would be for uscrs to purchasc a particular priority.

Thc mcthod thcn proceeds back to stcp 512 to proccss and rcordcr othcr incoming requests.

Thc mcthod abovc opcratcs continuously in thc rcqucst schcdulcr 104 when in operation. Once the requests are organised into appropriate queues, then they can be dispatched to the respective service station 102 in the next stage of operation.

The dispatch process will bc described with reference to Figurcs 13 to 17. iD

Figure 13 shows an embodimcnt of thc dispatch process involving throttled and graceflully throttled queues only.

Step 600: initiate At step 600, thc dispatch proccss is initiated. The method then proceeds to step 602.

Step 602: Is service station ready? At step 602, it is determined whether the service station is ready to receive a new servicc request, i.e. if it has finished servicing the previous request the service station 102 has been handling. If not, the method proceeds to step 604.

If the service station is ready to service a new request, the method pmceeds to step 606.

Step 604: Wait At step 604, the method waits for a predetermined time to enable the service station to complete thc current request and bc rcady to receive a new rcqucst. This timc period may be any suitable time period.

Step 606: Throttled service request detected? The requcst scheduler 104 examines the service deadline d,(S, L) for each throttled queue, starting with thc highest priority queue (in this example, the leftmost queue in Figure 3), i.e. the queue having the highest priority M. If the deadline for the highest priority throttled queue has not yet been reached, the request scheduler 104 moves to the next throttled queue in line.

This process continues until a throttled queue is reached which has a deadline which has been reached or has passed. At this point, the method proceeds to step 608.

If, however, the request scheduler 104 reaches thc cnd of the throttled queues and none of the queues has a deadline which has passed, then the method proceeds to step 612.

Step 608: Serve queue for which deadline has been reached or passed If, in step 606, it is detected that a queue has a deadline which has been reached or has expired, then the request scheduler 104 will service first request R(S, L) in line in that queue. Since the examining step 606 is carried out in priority order, in practice this means that requests Rn(S) in the throttled qucues are serviced starting with the throttled queue having the highest priority for which the deadline d(S, L) for servicing has been reached or has passed.

When a queue is serviced, the request scheduler 104 passes the respective 1/0 request R(S, L) at the head of that particular queue to the service station 102 for processing. The method then proceeds to step 610.

Step 610: Set new deadline for serviced queue At step 610, once the throttled queue has been serviced in step 608, a new deadline is set by which time the next request R1fS, L) in the FIFO queue is to be serviced. The new deadline d(S, L) to be set is dependent upon the nature of the system and the required throughput.

The simplest case is for the configuration shown in Figure 2. In this arrangement, a service having service ID S, originating from a single location having location ID L sends requests to a single service station 102. In this particular case, the location ID L is not nccdcd. Thcrcforc, it may optionally bc omittcd from thc scrvice rcqucst R. Altcrnativcly, if the location ID L is includcd in thc scrvicc rcquest R, it can be effectively ignored by the service station 102 because there will only be one location TD L in cach quduc.

For the configuration ofa single service sending requests from a single location to a singlc scrvicc station, thc dcadlinc d(S) (whcrc y is a constant) is thcn sct bascd on thc I/O size w11(S) of; and service throughput metadata T(S) associated with, the next throttled request R(S) in line in the relevant queue. Therefore, the deadline is set according to equation 2) above.

In other words, the new deadline is the current time plus the time required to process a given amount of data in a request at a required data rate (or bandwidth).

Meeting this dcadlinc will mean that thc rcquircd service throughput is achicved.

In an alternative configuration, a service having service ID S, and a single location ID L may send requests to multiple service stations. In this arrangement, each scrvicc station 102 scts dcadlincs indepcndently of cach othcr scrvicc station 102 and there is no communication therebetween.

Thc ncw dcadline d(S) for thc ncxt rcqucst R(S) set in dcpcndcncc upon a numbcr of factors. As for the first example, thc dcadlinc d (S) for rcqucst R11(S) is dependent upon the Tb size w,(S) and service throughput metadata T(S) for the rcqucsts having scrvicc ID S,. Howcvcr, thc dcadline is sot with thc aim of achicving aggrcgatcd throughput across all of thc scrvicc stations 102-1 -102-i, i.e. achicving thc rcquircmcnts sct out in thc scrvicc throughput mctadata T(S) but in parallcl with othcr servicc stations 102 proccssing requcsts from thc samc scrvicc having scrvicc ID S. The last served distance parameter I is, effectively, the distance of the last served request in the queue for service ID S. In other words, for request R(S) the last served distance I would bc equal to the distance of the previously served request R1(S) (i.c. the request most recently processed in step 408), as set out in equation 3) above. The deadline for request R11(S) is, thus, calculated according to equation 4) above.

In other words, thc new dcadlinc is thc current time plus the time required to process a given amount of data in a request at a required data rate (or bandwidth) in order to achieve an aggregated throughput across all of the service stations 102-i to which requests having a particular service ID S have been sent. Meeting this deadline will mean that the required service throughput is achieved.

In the final case, services having a service ID S have a number of locations having location IDs L and are serviced by a number of service stations 102. This is done by utilising a deadline for a particular request which is dependent upon the previous requests from a particular service ID S, and for a particular location ID L, i.e. the "distance" from the earlier rcqucsts from that service ID S and for that location ID L. In this way, an aggregated minimum bandwidth can be guaranteed without administration from a central server attempting to handle distribution across a plurality of service stations to meet a guaranteed bandwidth.

In a sequence of incoming requests for a particular service TD S having location ID L, the distance x(S, L) for the nthl request is calculated from equation 8) above.

Knowing the time in which these requests need to be serviced (i.e. the I/O sizes divided by the service throughput T(S/)) enables a deadline system which is able, on aggregate, to meet bandwidth requirements across the distributed system and to meet these requirements fairly across all of the locations of the service having service ID S 1.

Where I,,, is the last served distance for request R(S, L) which is equal to the sum of the weights of requests R0(S, L) to R111(S, L) as set out in equation 9) above. The deadline for request R(S, L) is, thus, calculated according to equation 10) above.

Therefore, in this embodiment, the deadlines for each service ID S, having location ID L are effectively independent between location IDs. In other words, within a single queue, thc dcadline for request R11(S1, Li) is dependent upon thc distancc of the most recentiy-scrvcd request R111 (Si, Li) having the same location ID Li. Other requests in the same queue having different location IDs do not affect the deadline for request R1(Si, Li).

Once the new deadline has been set, the method then proceeds back to step 602.

Step 612: Gracefully throttled service request detected? Step 6i2 is reached if, at step 606 it is determined that, in a stepwise scan of each of the throttled queues, none of the throttled queues has a service deadline which has been reached or is expired, then the request scheduler 104 is operable to move to the gracefully throttled queues.

The gracefully throttled queues are, essentially, of lower priority than the throttled queues and are provided to utilise (or "soak up") bandwidth that remains unused once the minimum bandwidth requirements have been met. Tn practical terms, a throttled connection will bc, for example, a paid-for conncction where a uscr pays for a particular amount of storage and a particular guaranteed bandwidth, and a graceffilly throttled connection may be one where, at higher cost, extra bandwidth may be used when available.

Consequently, given their low priority, graceffilly throttled queues are only serviccd if there is currently no throttled queuc which is at or has cxceedcd its respective deadline.

If a gracefully throttled qucuc is not dctectcd, thc method proceeds back to step 604. However, if a gracefully throttled queue is detected, the gracefully throttled queue to which the service marker is associated is serviced in step 614.

Step 614: Service gracefully throttled queue The graceffifly throttled queue to which the service marker is associated is serviced. Whcn a gracefully throttled queue is serviced, thc request scheduler 104 passes the respective rcqucst R(S, L) at thc head ofthat particular queue to thc service station 102 for processing.

Step 616: Move service marker Once the gracefully throttled request has been serviced in step 614, the service marker identifying the next gracefully throttled queue to be serviced is moved to the next gracefully throttled queue. Any suitable selection criterion may be used; for example, the next queue in priority order, a round-robin selection, a random queue selection or some othcr mechanism to select an arbitrary queuc for processing.

The method then proceeds back to step 602.

Figure 14 illustrates an alternative cmbodiment \vhcreby, instcad of gracefully throttled connections, unthrottled connections are used. The steps of this method are set out below. Steps 700-716 are substantially similar to those of the steps 610-616 and procedurcs and subjcct matter in common will not be described again here. Only steps which are different will be described here.

Step 712: Unthrottied service request detected? Step 712 is reached if, at step 706 it is determined that, in a stepwise scan of each of the throttled queues, none ofthe throttled queues has a service deadline which has been reached or is expired, then the request scheduler 104 is operable to move to the unthrottled queues.

The unthrottlcd queues arc, csscntially, of lowcr priority than thc throttlcd qucucs and arc providcd to utilise (or "soak up") bandwidth that remains unuscd oncc thc minimum bandwidth requirements have been met for the throttled connections.

If an unthrottled queue is not detected, thc method proceeds back to step 704.

However, if an unthroftied queue is detected, the unthrottled queue to which the service flag is associatcd is scrviccd in step 714.

Step 714: Service unthrottled queue In step 714, the unthrottled queue to which the service marker is associated is serviced starting. When the unthrottled queue is serviced, the Request scheduler 104 passes the respective request R0(S, L) at the head of that particular queue to the service station 102 forprocessing.

Unthrottled requests have no throughput requirements. However, unthroftled service requests need to be served fairly and any service of unthrottled requests should not affcct thc scrvicc throughput ofthroftled rcqucsts.

Step 7/6: iWove service marker Thc scrvicc marker is thcn movcd to thc ncxt unthrottlcd qucuc in line. This applies until the Request scheduler 104 reaches the end of the unthrottled queues (i.e. the rightmost qucuc shown in Figure 11), thc service marker is rcturncd to thc first unthrottled qucuc in line.

Thc mcthod thcn proceeds back to stcp 702.

Two additional variations of the above method are illustrated in Figures 15 and 16. These illustrate the general approach shown in Figure 11 whereby throttled conncctions arc provided, together with graceftilly throttled connections and unthrottled connections.

The graceffihly throttled and unthrottled connections can be provided in any suitable priority order. It is envisaged that graceftilly throttled services could take precedence over unthroftled service (as shown in Figure 15) and vice versa (as shown in Figure 16).

Figure 15 illustrates a method whereby, if spare capability exists after throttled connections have been served, then gracefully throttled services are served followed by unthrottled services. The steps of this method are set out below. Steps 800-816 are substantially similar to those of the steps 610-616 and procedures and subject matter in common will not be described again here. Only steps which are different will be described here.

Step 8/2: Gracefully throttled service request detected? Step 812 is reached if, at step 806 it is determined that, in a stepwise scan of each of the throttled queues, none of the throttled queues has a service deadline which has been reached or is expired, then the request scheduler 104 is operable to move to the graeethlly throttled queues.

Given their low priority, graceffilly throttled queues are only serviced if there is currently no throttled queue which is at or has exceeded its respective deadline, if a graeeftilly throttled queue is detected, the first gracefully throttled queue in priority order is serviced in step 8 14.

However, if a gracefully throttled queue is not detected, in this embodiment the method proceeds to step 818.

Step 818: Unthrottled service request detected? Step 818 is reached if at step 812 it is deteimined that, in a stepwise scan of each of the gracefully throttled queues, none of thcsc queues requires servicing. Then, in stcp 818, the request scheduler 104 is opcrablc to move to the unthrottlcd queues.

If an unthrottlcd qucuc is detccted, the first untbrottlcd queue in priority ordcr is serviced in step 820. However, if an unthrottled queue is not detected, the method proceeds back to step 802.

Step 820: Service unthrottled queue In step 820, the unthrottled queue to which the service marker is associated is serviccd. When thc unthrottled qucue is serviced, thc Request scheduler 104 passes the respective request R0(S, I,) at the head of that particular queue to the service station 102 for processing.

Unthrottled requests havc no Throughput requirements. However, unthrottled service requests need to be served Ilirly and any service of unthrottled requests should not affect the service throughput of throttled requests.

Step 822: Move service marker Thc servicc marker is then moved to the next unthrottled queue in line. This applies until the request schedulcr 104 reaches thc end of the unthrottled queues (i.e. the rightmost queue shown in Figure 11), the service marker is returned to thc first unthrottled queue in line.

The methodthen proceeds back to step 802.

Concomitantly, Figure 16 illustrates a method whereby if spare capability exists after throttled connections have been served, then unthrottled services are served followed by gracefully throttled services. The steps of this method are set out below.

Steps 900-916 are substantially similar to those of the steps 700-716 and procedures and subject matter in common will not be described again here. Only steps which are difirent will be described here.

Step 912: Unthrottled service request detected? Step 912 is reached if; at step 906 it is determined that, in a stepwise scan of each of the throttled queues, none of the throttled queues has a service deadline which has been reached or is expired, then the request scheduler 104 is operable to move to the unthrottled queues.

If an unthrottled queue is detected, the method proceeds to step 914 to service the queue. However, if no unthrottled request is detected, the method proceeds to step 918.

Step 918: Gracefidly throttled service request detected? Step 918 is reached if at step 912 it is determined that, in astepwise scan of each of the throttled queues, none ofthe throttled queues las a service deadline which has been reached or is expired, then the request scheduler 104 is operable to move to the gracefully throttled queues.

Given their low priority, gracefhlly throttled queues are only serviced if there is currently no throttled queue which is at or has exceeded its respective deadline and no unthrottled service request waiting.

If a gracefully throttled queue is detected at step 918, the fist gracefully throttled queue in priority order is serviced in step 920. However, if a gracefully throttled queue is not dctccted, in this embodiment the method proceeds back to step 902.

Step 920: Service gracefully throttled queue The graccthhly throttled queues arc serviced starting with thc qucuc having the highest priority M. When a graceffihly throttled queue is serviced, thc request scheduler 104 passes the respective request R(S, L) at the head of that particular queue to the service station 102 for processing.

Step 922: Move service marker Once the gracefully throttled request has been serviced in step 920, the service marker identifying the gracefully throttled queue to be serviced is moved to the next gracefully throttled queue in line.

The method then proceeds back to step 902.

A final variation is shown in the embodiment of Figures 17 and 18. In this embodiment, instead of setting a priority order for the servicing of throttled and!or unthrottled queues, a single fair scheduling system is used to address both throttled and unthrottled queues equally. Figure I 7 shows a schematic diagram whereby throttled connections are provided, together with graeeftilly throttled connections and unthrottled connections. Figure 18 shows a method according to an alternative embodiment of the invention.

The steps of this method are set out below. Some of steps 1000-1016 are substantially similar to those of the steps 610-616 as set out in Figure 13 and procedures and subject matter in common will not be described again here. Only steps which are different will be described here.

In thc method dcscribcd bclow, graccfully throttlcd and unthrottlcd qucues arc treated equally without a preferred priority ordcr. Therefore, a common service marker is shared between these queues and is moved as appropriate after a queue has been serviced.

Step 1012: Gracefully throttled or unthrottled service request detected? Step 1012 is rcachcd iL at step 1006 it is determined that, in a stepwise scan of each of the throftied queues, none of the throttled queues has a service deadline which has been reached or is expired, then the request scheduler 104 is operable to move to the gracefully throttled queues and the unthrottled queues.

As previously described, the gracefully throftled queues and unthrottled queues are able to utilise bandwidth that remains unused once the minimum bandwidth requirements have been met for the throttled queues. Consequently, given their low priority, gracefully throttled queues and unthrottled are only serviced if there is currently no throttled queue which is at or has exceeded its respective deadline.

If neither a graccfully throttled queue nor an unthrottled is detected, the method proceeds back to step 1004. However, if a gracefully throttled queue or an unthrottled queue is detected, the gracefully throttled queue or unthrottled queue to which the service marker is associated is serviccd in step 1014.

Step / 0/4: Service gracefully throttled queue or unthrottied queue The gracefully throttled queue or unthrottled queue to which the service marker is associated is serviced. When a gracefully throftled queue or an unthroftled queue is serviccd, the request scheduler 104 passcs thc respective rcquest R1(S, L) at the head of that particular queue to the service station 102 for processing.

The service marker in this example is common between both gracefully throttled queues and unthrottled queues. In other words, in contrast to previous embodiments that had a separate service marker for each queue type, in this arrangement, a single service marker is shared between both types of queue.

Step 1016: Move service marker Once the gracefully throttled request or an unthroftled request has been serviced in step 1014, the service marker identifying the next graceftilly throttled orunthrottled queue to be serviced is moved to the next gracefully throttled or unthroftled queue. Any suitable selection criterion may be used; for example, the adjacent queue, a round-robin selection, a random queue selection, an alternate gracefully throttled to unthrottled (or vice versa) selection or some other mechanism to select an arbitrary queue for processing.

The method then proceeds back to step 1002.

The method outlined above enable service throughput for a throttled service to be guaranteed. In other words, if the requests R(S) are arriving at a higher rate than the specified bandwidth (or throughput) they need to be slowed down before being dispatched to the service station 102 by the Request scheduler 104. On the other hand, if the requests R(S) are arriving slowly it is not necessary to slow them down. They can be dispatched to an available service station immediately.

In the above-described method, it is possible for the status of a service to change at any time. For example, a throttled service could become an unthrottled service or vice versa. This can be achieved by changing the service throughput metadata T associated with the request R as appropriate.

In this situation, a particular queue associated with a particular service ID S can be moved from the throttled queue section to the unthrottled queue section at any point based upon the updating of the service throughput metadata I(S) sent to the Request scheduler 104. The advantage of this arrangement is that a particular request R(S) itself docs not nccd to changc format in ordcr to movc from onc scrvice typc to anothcr. This rcduccs the amount of proccssing and data cxchangc rcquired.

Thc abovc scheduling mcthod has a numbcr of advantagcs. Throughput (ic.

bandwidth) is guaranteed for thc throttled scrvicc whcn the systcm opcratcs within its capacity. Further, when the system is operating within its capability, no throftied or unthrottlcd scrvicc can disrupt thc throughput of othcr throttlcd or unthrottlcd scrviccs by send requests at a higher rate. This avoids a major drawback of conventional throttled service arrangements which can only impose a maximum possible bandwidth as opposed to a guaranteed minimum.

Furthermore, the described method enables unthrottled requests to be serviced by the service station 102 as well. The untbrottled requests are serviced only when there is no throtded service requests and thcrcfore do not affect the throughput of the throttled services. Concomitantly, the ability to service unthrottled requests when system capacity permits enables improved utilisation of the service station 102.

Additionally, throughput is throttled for throttlcd scrvicc queucs. Thcrcforc, in this embodiment, for a given service ID S,< the maximum throughput cannot be more than the associated service throughput T(S) even when corresponding service requests R(S) arrivc at a higher ratc.

The method outlined above enable service throughput for a throtded service to be guarantccd across multipic scrvicc stations rccciving rcqucsts from a distributed scrvicc having multipic scrvicc locations. Thc abovc scheduling method has a number of advantages. Throughput (ic. bandwidth) is guarantccd for thc throttlcd scrvice across a parailcl flIc systcm whcn thc system opcratcs within its capacity. This bandwidth is guaranteed without each service station needing to share or communicate deadlines or other request processing information with other service stations. This eliminates a potentially enormous amount of data communication which would otherwise be required if for example, a ccntral servcr managcd thc data transactions and sct thc dcadlincs for cach request to bc proccsscd.

Figure 19 is a graph of bandwidth usagc on scrvicc stagc conncctcd to a typical storagc nctwork used by a plurality of applications. As shown, when all applications arc unthrottled, close to the maximum capacity of the service station is used at times.

However, whcn thc mcthod of thc prcsent invcntion is uscd, all applications arc maintained at their specified minimum bandwidth, irrespective of the other connections.

This figure illustrates the ability of the present invention to manage the bandwidth of multiple services.

Variations of the above embodiments will be apparent to the skilled person. The precise configuration of hardware and software components may differ and still fall within the scope of the present invention. For example, the location ID aspect of the third embodiment above could be equally applied to the single service station configuration of the first embodiment.

Whilst the distance and last served distance aspects above have been set out in terms of summing from 0 to n for the nth request, it is also possible to sum from 0 to n-I and then add in the weight of the nth request, if desired.

Alternatively, if the requests are all of the same weight (i.e. I/O size), then the request number n or request count can be used to determine the distance (and, thus, the deadline) on the service station side.

Additionally, the distance parameter may be sent in a different format. For example, the distance, x0, could be sent as a function which is then processed by the service station. Examples of such functions may be axwhere a is a constant or other function. Alternatively, function such as (x)2 or (x)3 may be used.

A more general approach may be to pmvidc a general function, such as, for example, F, where F is an invertible function that has inverse 0. Then, the request may comprise F(x(R)) from the client or service origin side to obtain x(Rn) by inversion at thc server/service station sidc because xjR) = 0(F(x(Ra)). indeed, thc examples given abovc Xn(Rn) itself corresponds to Suction F(x) = x which has inverse 0(x) = x. A similar function could be used ibr the example given above in the x(R4 = n case where all requests have equal weight.

In general, the distance parameter provides information identifying how much I/O has been sent to other service stations before sending a request. As set out above, the distance parameter may be supplied with the request or may be calculated from the supplied request number n.

However, variations arc possible. For example, the service throughput T may, optionally, be supplied with the request rather than supplied by other means. Theitibre, the request may optionally comprise the deadline data itself; i.e. the distance of the particular request divided by the throughput required for the service ID associated with the request. Alternatively, the deadline could be calculated on the service station side from the distance and the throughput data provided separately in the same request.

In addition, with regard to gracefhlly throttled services, the gracefully throttled identifier mctadata may be supplied by the service coordinators to the service stations as described in the manner of the service throughput metadata T. The gracefhlly throttled identifier mctadata may also be supplied as part of the service thmughput metadatal. As a father variation, the gracefully throttled identifier may be included in the service request if desired.

In general, a number of permutations for determining deadlines may be used. For example, as set out above, a request may comprise only a request number, and the distance is calculated based on constant weights at the service station and the deadline determined from the throughput data received separately. Alternatively, the request may comprise a distance metric, with the throughput data being received separately by the service station and the distance/deadline determined at the service station Further, the request may comprise distance data determined at the service origin or client side and throughput data received separately by the service station. Finally, the request may comprise both distance data and throughput data either separately or in the form of deadline data sent to the service station. The final arrangement does not require the service station to perform any determination or calculations to determine the deadline.

This may be beneficial in some configurations.

In the examples illusm-ated above, each service station may, for example, comprise an object storage server (OSS) that stores file data on one or more object storage targets (OST5). Typically, an OSS serves between two and eight OSTs, with each OST managing a single local disk fllcsystcrn (not shown). The capacity of the file system is the sum ofthe capacities provided by the OSTs 8.

The service stations may, optionally, be connected to a metadata server (MDS).

The MDS 3 has a single metadata target (MDT) per filcsystcm that stores metadata, such as filenames, directories, access permissions, and file layout. The MDT data is stored in a single local disk filesystem MDS. The MDS is configured to ifinction as a portal for a client computers or services to the parallel file system comprising the storage located on the plurality of service stations. This may take the form of, for example, a webpage or a portal whereby a user ca request access to a data storage resource.

The present invention is particularly applicable to parallel distributed file systems.

These systems arc often used for large scale cluster computing and may comprise file systems such as Lustrc'' or CollibrilM. However, it will be appreciated that this need not be the case and that other distributed network systems may fall within the scope of the present invention.

Embodimcnts ofthc prcscnt invcntion havc bccn dcscribcd with particular rcfcrcncc to thc cxamplcs iflustratcd. Whilc spccific cxamplcs arc shown in thc drawings and are herein described in detail, it should be understood, however, that the drawings and dctailcd dcscription arc not intcndcd to limit thc invcntion to thc particular thnn disclosed. It will be apprcciatcd that variations and modifications may bc madc to thc examples described within the scope of the present invention.

Claims

CLAIMSI. A method of scheduling requests from a plurality of services to at least one data storage resource, the method comprising: a) receiving, on a computer systcrn, service rcquests from said plurality of services, the service requests comprising metadata specifying a service ID and a data size of payload data associated with said service request, at least some of said service IDs having service throughput metadata speci'ing a required service throughput associated therewith; b) arranging, in a computer system, said requests into FWO throttled queues based on said service ID; c) sefting, on a computer system, a deadline for processing of a request in a throttled queue, the deadline being selected in dependence upon the size of the request and the required service throughput associated therewith; d) monitoring, on a computer system, the deadline of each throttled queue and, if a request in a throttled queue has reached or exceeded the deadline, processing said request in a data storage resource; and c) repeating step c) above.
2. A method according to claim I, wherein each service request is arranged into a queue selected from the group of: throttled queue, gracefully throttled queue and unthrottled queue.
3. A method according to claim 2, wherein in step b) service requests having a service ID to which no service throughput metadata is associated, or service requests having no service ID, are arranged into at least one FIFO unthrottled queue.
4. A method according to claim 3, wherein if, at step d), no request in a throftled queue has reached or exceeded a deadline, the method further comprises: f) monitoring said unthrottled queues and, if at least one request is present in an unthrottled queue: g) processing said unthrottled request in an unthrottled queue; and h) repeating step d).
5. A method according to claim 2, wherein in step b) service requests having a service ID to which service throughput metadata and gracefully throttled identifier metadata is associated are arranged into at least one FO gracefully throttled queue.
6. A method according to claimS, wherein if; at step d), no request in a throttled queue has reached or exceeded a deadline, the method further comprises: i) monitoring said gracefully throttled queues and, if at least one request is present in a gracefully throttled queue: j) processing said gracefully throttled request in a gracefully throttled queue; and k) repeating step d).
7. A method according to claim 2, wherein if; at step d), no request in a throttled queue has reached or exceeded a deadline, the method further comprises: 1) monitoring said gracefully throttled queues and unthrottled queues and, if at least one request is present in a gracefully throttled or an unthrottled queue: m) processing said gracefully throttled or unthrottled request in a gracefully throttled or unthrottled queue; and n) repeating step d).
8. A method according to claim 7, wherein said gracefully throttled queues have priority over said unthrottled queues.
9. A method according to claim?, wherein said unthrottled queues have priority over said gracefully throttled queues.
10. A method according to claim?, wherein said gracefully throttled queues and said unthrottled queues have equal priority.
11. A mcthod according to any onc of thc prcccding claims, whcrcin said throttlcd qucucs arc arrangcd in priority ordcr, with thc monitoring in stcp d) stalling with thc highest priority queue.
12. A mcthod according to any onc of thc prcccding claims, whcrcin said scrvicc throughput metadata is supplied to the computer system independently of the service rcqucsts.
13. A method according to any one of the preceding claims, wherein a plurality of data storage resources are provided and step c) further comprises sefting and selecting the deadline for the nth request having a particular service ID in dependence upon the sum of the data sizes of the first to the th requests having said particular service ID and the required service throughput associated with said particular service ID.
14. A method according to claim 13, wherein each request having a particular service ID has the same data size and said deadline for the ib request having a particular service ID is set in dependence upon the request number ii and the known weight of each rcqucst.
15. A method according to claim 13, wherein each request from a particular scrvicc ID compriscs a distancc paramctcr x associatcd thcrcwith rclating to the sum of the data sizcs of thc first to thc nt" rcqucsts from said particular scrvicc ID.
16. A mcthod according to claim 15, whcrcin stcp c) compriscs sctting, on a scn'icc station, a ncw dcadlinc for a rcqucst bascd on thc distance paramctcr x of said rcqucst and the scrvicc throughput mctadata associatcd thcrcwith.
17. A method according to claim 16, wherein the request comprises said service throughput metadata.
18. A mcthod according to claim 17, whcrcin said rcqucst compriscs scrvicc throughput mctadata combincd with said distancc paramctcr x to providc dcadlinc data to said computer system.
19. A mcthod according to claim 16, whcrcin in stcp c) thc computcr system determines the deadline for a request from said distance parameter x of a request and scrvicc throughput mctadata rcccivcd indcpcndcntly by said computing systcm.
20. A method according to claim 16, wherein step c) further comprises: sefting a new 11) deadline for the next request in dependence upon the distance parameter x of the next request, the distance parameter of the previously-processed request processed in step e) and the service throughput metadata.
21. A mcthod according to any one of the prcccding claims, whercin at least one service is distributed across a plurality of locations such that each service ID is associated with aphirality of location IDs.
22. A mcthod according to claim 21, whcrcin each scwicc rcqucst comprises a scrvicc ID and a ocation ID.
23. A mcthod according to claim 22, whcrcin stcp c) thrthcr compriscs setting and selccting thc dcadlinc for thc n1' rcqucst having a particular scrvicc ID and location ID in dependence upon the sum of the data sizes of the first to the n1' requests having said particular scrvicc ID and location ID and thc rcquircd scrvice throughput associatcd with said particular service ID.
24. A mcthod according to claim 23, whcrein each rcqucst has a distanec paramctcr x associated therewith, said request number n corresponding to the nth request having a particular service ID and location ID, and said distance parameter comprising the sum of the data sizes of the first to the n0 requests having said location ID.
25. A method according to claim 24, whcrcin stcp g) furthcr comprises: sctting a ncw deadline for thc ncxt requcst in dependence upon thc distancc parameter x of thc ncxt request having a particular location ID, the distance parameter of the previously-proccsscd rcqucst having said location ID proccsscd in step c) and thc scrvicc throughput mctadata.
26. A method according to claim 21, whcrcin a plurality of parallel data storagc resources is provided.
27. A method of scheduling requests from a plurality of services to a plurality of networked data storage resources, the method comprising: a) receiving, on a computer system, service requests from said plurality of services, the service requests comprising metadata specifying a service ID and a data size of payload data associated with said service request, at least sonic of said service IDs having service throughput metadata speci'ing a required service throughput associated therewith; b) arranging, in a computer system, said requests into F1FO throttled queues based on said scrvicc ID; c) setting, on a computer system, a deadline for processing of the n request having a particular service ID in a throttled queue, the deadline being selected in dependence upon the sum of the data sizes of the first to the tIi requests having said particular service ID and the required service throughput associated with said particular service ID; d) monitoring, on a computer system, the deadline of each throttled queue and, ifa request in a throttled queue has reached or exceeded the deadline, processing said request in a data storage resource; and e) repeating step c) above.
28. A request scheduler for a service station, said request scheduler being configured to schedule requests from a plurality of services accessing said service station, the request scheduler being operable to: receive service requests from said plurality of services, the service requests comprising mctadata speciTing a service ID and a data size of payload data associated with said service request and at least some of said service IDs having service throughput metadata spcciing a required service throughput associated therewith; arrange said requests into FIFO throttled queues based on said service TD; set a deadline for processing of a request in a throttled queue, the deadline being selected in dependence upon the size of the request and the required service throughput associated therewith; monitor the deadline of each throttled queue and, if a request in a throttled queue has reached or exceeded the deadline, processing said request in a data storage resource; and repeating the step of monitoring.
29. A computer program product executable by a programmable processing apparatus, comprising one or more software portions for performing the steps of any one of claims 1 to 27.
30. A computer usable storage medium having a computer program product accoriling to claim 29 stored thereon.
31. An electronic data store comprising a service station and the request scheduler of claim 28.
32. A method substantially as shown in and/or described with reference to any one or more of Figures 1 to 19 of the accompanying drawings.
33. A computer program product substantially as described with reference to any one or more of Figures 1 to 19 of the accompanying drawings.
34. A request scheduler substantially as described with reference to any one or more of Figures 1 to 19 of the accompanying drawings.