BRIEF DESCRIPTION OF THE DRAWINGS
Exemplary embodiments of the inventive method are explained below with reference to the drawings. These are simultaneously used to explain an exemplary embodiment of the inventive arrangement.
In the drawings:
FIG. 1 shows an arrangement comprising a plurality of database nodes, a plurality of application nodes and a plurality of client systems with resources,
FIG. 2 shows the distribution of releasable and allocated licenses during various load states,
FIG. 3 shows a schematic illustration of a data transfer during a synchronization step,
FIG. 4 shows the addition of releasable licenses to the arrangement,
FIG. 5 shows the situation in the event of undersupply with releasable licenses,
FIG. 6 shows a special case with just one application node, and
FIG. 7 shows a scenario with failure of an application node.
DETAILED DESCRIPTION OF INVENTION
FIG. 1 schematically shows an arrangement comprising a network NW (communication network, data network, intranet, Internet or the like) with database nodes DBN1, DBN2, DBN3, with application nodes A, B, C, with client systems CL1, CL2 and with resources R1A, R1B, R2A, R2B. The schematically shown components in this instance constitute what is known as a “distributed arrangement” (distributed system), with the individual components being able to be arranged with free “mobility”, that is to say at any location, in the network NW. This applies particularly to the database nodes DBN1, DBN2, DBN3, which logically form a single database but for reasons of load distribution and for reasons of redundancy (failsafety) are physically distributed over various hardware units. Equally, although FIG. 1 shows the resources R1A, R1B as belonging to the client system CL1—in line with the resources R2A, R2B for the client system CL2—the resources under consideration here may likewise be arranged on various and also totally different hardware platforms.
The resources R1A, R1B, R2A, R2B are functions (“services”) which can be used within the context of the distributed system, which is also known as SOA (Service Orientated Architecture), in clients or by clients. In the present exemplary embodiment, these are communication channels which can be used in a telephony arrangement; it goes without saying that any other service, an arbitrary functionality or an appliance may also be considered as a “resource”. For each telephone call which he wishes to make, a subscriber needs to use such a channel for transmitting his call. Such a communication channel is used using what is known as a protocol stack (e.g. what is known as an “SIP stack”—for Session Initiation Protocol). However, such a protocol stack can only be used if the license holder for this protocol stack grants authorization to do so, in other words: grants a license for use. In the present exemplary embodiment, it is first of all assumed that the operator of the arrangement shown has purchased a license for the simultaneous operation of 20 resources R1A, R1B, R2A, R2B. In this case, the resources R1A, R1B, R2A, R2B in FIG. 1 are shown as representative of a very much larger number of resources of the same type (in this case: protocol stacks).
For the discussion of the method based on the invention or the arrangement based on the invention, it is of no significance in or by which of the client systems CL1, CL2 one of the resources R1A, R1B, R2A, R2B is to be used. For this reason, the resources R1A, R1B, R2A, R2B are not shown further in the figures which follow. The text below therefore always uses the term “resource” in a general sense.
The use of a resource requires—as already explained—a respective license, a license only ever being able to be allotted to a particular number (in this case, precisely 1) of using resources at the same time. That is to say that before a resource is used or at the start of use of a resource, this resource needs to be attributed one license from a stock of available (“releasable”) licenses and said license should be made available to the “license pool” again following conclusion of the use of the resource. In this case, each resource is attributed to one of the application nodes A, B, C. Each resource which is to be used obtains the license required for use from the associated one of the application nodes A, B, C for the period of use. In this case, it is either possible for the resource to request the license from the application node A, B, C automatically or else for the process of license allotment to be performed by an external entity (not shown). Within the application nodes A, B, C, the licenses are respectively managed by a special computer program, known as the “resource broker”. The central instrument for managing the licenses, will be referred to below as the “resource store” RS; this first, central entity “resource store” RS can—as already described—be formed by a multiplicity of database nodes DBN1, DBN2, DBN3. The resource store RS is that central point at which licenses for the use of the resources can be added to or removed (“deleted”) from the entire communication arrangement. FIGS. 1A to 7 now schematically show only the application nodes A, B, C with the number of releasable and allocated licenses “buffer stored” there and also (respectively on the right hand side of the figure) the resource store RS with the licenses registered there.
In one alternative embodiment, the resources are not located on the client systems CL1, CL2 but rather at other nodes, for example directly at the application nodes A, B, C. It goes without saying that in these cases it is not necessary to access the network NW in order to obtain or release a license, provided that the relevant resource is installed at the same application node A, B, C at which the resource brokes associated with this resource is arranged.
In the text below, it is assumed that 20 releasable licenses have been set in the resource store. For the sake of simplicity, it is assumed that all resources under consideration require licenses of the same type; otherwise, each resource type or each associated different license type would need to be considered separately. In this regard, the right-hand part of FIG. 2A schematically shows the resource store RS, the statement “total=20” indicating that 20 licenses are being managed in total. In addition, the statement “available=20” indicates that of the 20 licenses managed there are 20 which can be released, that is to say that at first there are no licenses being used.
The resource brokers for the application nodes A, B, C are shown in the left-hand part of FIG. 2A. These perform a respective synchronization step with the resource store RS at stipulated, configurable intervals of time. In addition, a synchronization step of this type is also performed when each resource broker is engaged afresh, the resource brokers respectively setting up a connection to the resource store RS. In this synchronization step, each resource broker reads the number of releasable licenses (in this case initially: “available=20”) from the resource store RS and stores this statement. These statements “20” are respectively shown in the left-hand part of FIG. 2A.
The text below considers a period of time in which no further synchronization step takes place. In this period of time, various resources request licenses from their respective associated resource brokers. It goes without saying that if a resource broker fails or if the relevant application node A, B, C is unattainable then a resource can switch to another of the resource brokers from another of the application nodes A, B, C. The resource broker for the application node A books five licenses, the application node B books three licenses and the application node C initially does not request a license. The resultant state is shown in FIG. 2B. In the diagram, the number of licenses allocated since the last synchronization step is entered on the right-hand side of the respective resource broker in the top column; in the column below that, the number of releasable licenses is also recorded, as known from the description relating to FIG. 2A. This number is not changed at first by the mere allocation of licenses.
In this case, the difference between the number of allocated licenses and the number of releasable licenses gives that number of licenses which could still be allocated by the respective resource broker; fifteen licenses in the case of the application node A, seventeen license in the case of the application node B and the original 20 licenses in the case of the application node C.
The situation shown in FIG. 2C is obtained when one license is returned again “released” to the resource broker for the application node A and two licenses are returned again (“released”) to the resource broker for application node B. Accordingly, the respectively stored number of allocated licenses is reduced.
The text below describes the changes which are obtained as a result of a synchronization cycle. In this case, the resource broker for the application node B is first of all synchronized. In the present exemplary embodiment, it is left to chance which of the resource brokers is synchronized first, because in the present case it is dependent on which of the application nodes have been engaged first. For the order and for the frequency of the synchronization steps, however, the widest variety of scenarios and practices is conceivable. The synchronization step for the resource broker for application node B is shown schematically in FIG. 3A. In a first substep, the relevant resource broker transmits the balance of the licenses which it has allocated since the last synchronization step to the resource store RS. Since this is the first synchronization step in the present case, this is equal to the balance since the resource broker for the application node B was engaged or restarted. Since this application node B has initially allocated 3 licenses and then two resources have been deactivated again and hence two licenses have been returned (released), this balance is “−1”. This reduces the number of available, releasable licenses in the resource store RS by 1 to “19”; this value is transmitted to the resource broker for the application node B in the second substep of the synchronization step and is entered there instead of the “20” as the new value for the number of releasable licenses. At the same time, the new “balance” for the number of releasable licenses in this resource broker is reset to zero, because the resource broker is now fully synchronized.
FIG. 3B shows how the next resource broker for the application node C is synchronized. The result obtained in this case is likewise a new value for the number of releasable licenses “19”. Finally, the resource broker for the application node A is also synchronized; this process is shown schematically in FIG. 3C. In FIGS. 3A, 3B and 3C, it can be seen that the number of licenses respectively allocated (“booked”) by the individual resource brokers is recorded in the resource store RS. It follows from this that besides the total number of licenses (“total=20”) it is not imperative to store the number of releasable licenses (“available=15”) in FIG. 3C; this value can also be recalculated at any time from the total number and from the individual values (“booked A=4; B=1; C=0”). FIG. 3C shows that the four licenses which have been allocated by the resource broker for the application layer A are taken as a basis for re-stipulating both the number of releasable licenses in the resource store RS and the corresponding value in the resource broker for the application node A as “15”. This value initially remains at the value “19” for the other resource brokers because a fresh synchronization step has not yet been performed with these. That is to say that for these two remaining resource brokers there continue to be nineteen licenses available even though there are in fact now only fifteen licenses left from the total number of “20”. This state continues to exist until the synchronization steps shown in FIGS. 3D and 3E have been performed. In the meantime, it is possible for more than the “permitted” twenty licenses to be allocated. Provided that no resources are used or released in the meantime, and hence the licenses linked to these resources are allocated or released, it therefore takes a maximum of two full synchronization cycles before all the resource brokers are fully in sync with the resource store RS. In the meantime, more resources than there is provision for by the total number of releasable licenses may be used without a resource being denied a license.
FIG. 4 shows a scenario in which there are initially 20 licenses in total stored in the resource store RS, six of which are still available (“available=6”). If the operator of the arrangement purchases ten further licenses, these ten licenses are reregistered only at a single location, namely in the resource store RS. This increases the number of licenses to thirty (“total=30”), on the basis of which the number of releasable licenses is recalculated (“available=16”). This number is transferred to the respective synchronized resource broker in each subsequent synchronization step. The procedure is similar when licenses are withdrawn from the network or the arrangement. It should be noted that the practice described, using repeated synchronization cycles, means that on statistical average all resource brokers have an identical number of releasable licenses, regardless of how many licenses have already been allocated and withdrawn again by the respective resource broker. Alternatively, the resource store RS can also have instructions added which prompt an uneven distribution of the releasable licenses, for example on the basis of authorizations which are associated with the various application nodes and their users.
The method described is known to have the advantage that each application node A, B, C, or each resource broker respectively has a large number, ideally even the respective actual number, of releasable licenses available without the need to set up a respective connection to the resource store RS for the purpose of allocating licenses. Accordingly, licenses can be allocated and licenses can be released quickly and also safely. Furthermore, it is guaranteed that in cases in which releasable licenses are generally present in the overall arrangement it is possible for licenses to be freely allocated everywhere within the context of this number and hence also for peak loads, which can go beyond the total number of licenses, to be “cushioned”. This firstly means that the number of licenses to be held in the system does not need to be much greater than the number of licenses required on average, without losing the capability of handling load peaks. On the other hand, this has the drawback that in extreme cases (worst case scenario) the number of licenses allocated may even exceed a multiple of the total number of available licenses (releasable licenses), depending on the number of resource brokers, on the basis of the time interval for the synchronization steps or synchronization cycles and on the basis of the use behavior (that is to say the use of resources).
FIG. 5A shows the starting point for such a worst case scenario. The number of releasable licenses in a total number (“total=20”) has been reduced to three releasable licenses (“available=3”), because seventeen licenses have been allocated in total. In addition, the resource brokers for the application nodes A and B have respectively allocated a further license, so that—in theory—only one license can now be allocated in the whole network. Nevertheless, the resource broker for the application node A can still book two licenses, in the case of B a further two licenses and in the case of the application node C three licenses. If it is assumed that such license demands are actually made before the next synchronization steps, the state shown in FIG. 5B is obtained no later than after the next two synchronization cycles, that is to say in the state of full synchronization. The number of releasable licenses (“available=−4”) is negative (“−4”) both in the resource store and in the individual resource brokers. The method can react to this state using various strategies; in this exemplary embodiment, a plurality of strategies are used. A first reaction option is that the synchronization of the resource brokers is performed more frequently so that any licenses released in the meantime can be used again throughout the system as quickly as possible. Instead of a shortened time interval for the synchronization steps, the resource brokers for the application nodes A, B, C may also be set such that any released license is immediately reported to the resource store RS, however. In addition, the resource brokers may be set such that licenses are allocated only if the respective resource brokers store a positive value for the releasable licenses. Alternatively, the resource brokers can also be set such that “absent” licenses can also be allocated within predetermined limits and for a prescribed “tolerance time”, however. In a worst case, as shortly after a system start, for example, in combination with a long synchronization interval and a maximum network load, the number of licenses allocated “too much” may reach the number of application nodes multiplied by the total number of licenses1.
FIG. 6 shows the special case in which precisely one resource broker is present. In such a case, the synchronization process is required only in order to make licenses recently added to the resource store RS in the meantime available and to remove licenses taken from said resource store from the resource broker too. The “tolerance mechanisms” just described, which, even with long synchronization cycles, ensure that the resource broker can actually allocate all “purchased” licenses, are not necessary in this scenario.
Finally, FIG. 7 shows the case in which an application node B and hence the resource broker installed there fail. FIG. 7 shows that the resource broker for the application node B has provided a further resource with a further license before it fails and after the last synchronization step; this is shown by the number “−1” in the top column of the central block in the figure. At the time of failure, the resource store contains the information that five licenses have been allocated at the application node B, because this corresponds to the state of affairs for the last synchronization.
The failure of application node B is registered by a monitoring facility (“watchdog”). Registration of the failure can lead to various reactions, for example the monitoring facility can attempt to restart the application node B. If this attempt is unsuccessful, it is assumed that the resources managed by B are likewise unattainable or have failed. This assessment is realistic particularly in cases in which a resource needs to renew or confirm a license which is in use at periodic intervals of time. In the light of this assumption, the number of booked licenses attributed to the application node B in the resource store RS “booked B=5” is deleted; the allocated licenses are thus released again in the entire system. After the next full synchronization cycle, these licenses are thus available again to the resource brokers for the application nodes A & C. The possibility described further above, that resources send their license requests to other resource brokers in the event of a resource broker or the associated hardware failing, results in automatic “load balancing”, that is to say automatic load redistribution, taking place, with all further license requests being sent to the resource brokers for the application nodes A & C. This continues until the resource broker for the application node B can be obtained again; during the next synchronization cycles and during the next resource use and resource release operations which then occur and the associated allocation and release actions for the licenses, the license distribution in the entire system will “settle” back to a normal state.
The measures described above ensure that largely disturbance-free continued operation of resources is ensured even in the event of individual failure by application nodes A, B, C and/or by the resource store RS. Furthermore, the concept of local allocation of licenses avoids frequent data interchange with a central entity (in this case: resource store RS), which minimizes network load further.
Patent Application
20080082450
