Patent Application
20080201360
1. Field of Invention
This invention relates to locating persistent objects in a network of servers and routing requests to those objects.
2. Description of Related Art
In general, a persistent object can be defined as anything that is stored on a “persistent” medium, e.g. a hard drive. Generically, this persistent medium is called a storage unit herein. A server facilitates a client's request to access persistent objects in various storage units. Emails, calendaring data, files, and web pages are examples of persistent objects. In contrast, temporary objects, e.g. processes to deal with tasks and authentication information, are created by a server and stored only temporarily.
A conventional email request refers to a specific account, e.g. bobdavis@companyA.com, not to a server. This referencing provides system flexibility. Specifically, referring to
A computer system optimally needs flexibility in both the naming of accounts and how accounts are placed within the system. Thus, giving out the server name or server address to client 101 could limit system flexibility. To preserve this flexibility, a directory 102 controlling access to the servers is typically used. Proxy 108 can perform the task of routing the request from client 101 to the correct email server (e.g. server 104A) using directory 102 and a location service 109.
Specifically, a “mailhost” attribute can be used for locating the email server for a particular user. This mailhost attribute allows the email account name to be translated into a server address. For example, an email request access to the email account bobdavis@companyA.com can be directed as a location query 110 to directory 102. The mail host attribute for client Bob Davis is stored in directory 102. Directory 102 provides the translation to the appropriate server name and address, e.g. to server 104A in
Of importance, the real location of email for Bob Davis resides in storage unit 105A. The purpose of server 104A is to manage the data contained in storage unit 105A for read/write accesses to any mailboxes contained therein, e.g. read the requested mailbox from storage unit 105A and put the requested mailbox on access network 103 (which is then transferred to client 101 via proxy 108. As indicated in
However, if storage unit 105A was instead accessed by server 104B, then the name and address of server 104B has implicitly changed. Thus, in this system configuration, the location bindings directly refer to the access facilitating servers.
Notably, any changes to the server configuration (i.e. storage units being moved) are performed through location updates 111, which are provided to location service 109. Typically, a system administrator performs these location updates 111 manually. Changing the access of a mailbox for one user to a different server and updating the translation information in directory 102 is easy. However, the task of changing the access of hundreds or even thousands of mailboxes to one or more different servers, and then updating the translation information in directory 102 can be extremely time consuming for a system administrator and waste considerable system resources.
Therefore, a need arises for a more time and system efficient method of locating persistent objects, like email, using a network of servers.
A computer system can advantageously include a location service that minimizes changes to a directory when storage units are moved. Each storage unit can use its meta data to indicate the persistent objects the storage unit contains. For this reason, the storage units can be characterized as being “self-describing”. In one embodiment, the storage units are virtual storage units forming network storage. The directory can advantageously store a translation between each persistent object and its corresponding storage unit.
The location service allows the servers to register their corresponding storage units. In one embodiment, the servers are virtual servers forming a network server. Based on registrations stored by the location service, the access network of the system can successfully request persistent objects from the appropriate servers. Advantageously, this system configuration allows a storage unit to be moved (i.e. accessible by another server) without changing a directory entry, thereby minimizing both time and system resources.
A method of dealing with persistent objects accessible by a network of servers is described. In this method, the locations of the persistent objects can be bound to the storage units in which they are contained. Each server is allowed to register its corresponding storage unit. Routing requests to the persistent objects can include determining the storage unit that contains the persistent object and then determining the server having access to that storage unit. Access to a storage unit can be re-registered with a backup server after the failure of a server currently registered to access that storage unit.
A method of translating in a computer system is also described. In this method, meta data in each storage unit can be provided. This meta data can describe persistent objects contained by the storage unit. A directory can be used to translate a persistent object to the storage unit. A location service can then be used to translate that storage unit to a server accessing the persistent object. Persistent objects include but are not limited to email, calendaring data, and to other applications.
To ensure a time efficient method of locating persistent objects, the location of the persistent object is bound to its storage unit, not to the server that accesses the storage unit. A location service, described below, can advantageously receive location updates directly from the servers. These location updates can be both dynamic and automatic, thereby accelerating the update process without need to update an actual directory entry.
In system 200, servers 204A-204C can advantageously directly provide any location updates 211 to location service 202. For example, during an initial registration process, servers 205A-205C could indicate their respective storage units 205A-205C with location service 202.
Notably, system 200 retains a two-level translation from an email account to the location of the email account in the storage unit. For example, an entry in a directory 220 could indicate that Bob Davis' mailbox is, for example, in storage unit 205A, thereby providing a first translation. Location service 202 can then provide a second translation from the identified storage unit to its current server.
Location updates 211 can also be generated dynamically for any server configuration changes in system 200. For example, if servers 204A and 204B are moved to facilitate access to storage units 205B and 205A, as indicated by dashed arrows 221, then server 204A would register its new storage unit 205B with location service 202. Similarly, server 204B would register its new storage unit 205A with location service 202. Advantageously, the entries in directory 220 can remain the same, i.e. nothing needs to be changed because the binding of the locations of the persistent objects to their storage units remains the same.
Note that a storage unit is generally thought of as a physical structure, but could also be a “logical” or a “virtual” storage unit. Therefore, in one embodiment shown in
Similarly, a server is also generally thought of as a physical structure, but could also be a virtual server. Therefore, in one embodiment shown in
Note that a virtual server can be scaled to the needs/limitations of the storage unit. Similarly, a virtual drive can be scaled to the needs/limitations of the virtual server. In one embodiment, both virtual servers and virtual drives can be used to maximize system flexibility.
Referring back to
In summary, the self-describing storage units and the location service advantageously enable a computer system to move storage units quickly and automatically. For example, in load balancing, a storage unit can easily be shifted from an over-burdened server to a less-burdened server. This shifting requires no change to the directory, merely a registration to the location service. Moreover, as described in reference to
Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying figures, it is to be understood that the invention is not limited to those precise embodiments. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed. As such, many modifications and variations will be apparent.
For example, note that the directory and the location service can be formed separately or together. Therefore, the directory and the location server are conceptually distinct, but could be enabled in various hardware/software configurations. Accordingly, it is intended that the scope of the invention be defined by the following Claims and their equivalents.
