Browse Prior Art Database

Second level servers outage management

IP.com Disclosure Number: IPCOM000030910D
Original Publication Date: 2004-Sep-01
Included in the Prior Art Database: 2004-Sep-01
Document File: 3 page(s) / 119K

Publishing Venue

IBM

Abstract

Disclosed is a technique to manage second level servers outage in a three level architecture where a central first level server manages several second level servers handling with final endpoints.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 3

Second level servers outage management

A lot of system management software products are based on a three level architecture: all of them are the typical embodiment for such a technique.

    In such architectures we can easily divide the flow of information coming up and down among the three levels in: - endpoint information flow; - endpoint management data flow

    Without loss of generality we can assume (since it's typical) that the first kind flows up to bottom while the second kind follows the opposite way. This is shown by Figure 1:

First line server

Endpoint management and control parameters

Figure 1: three tier architecture and data flow

    Without loss of generality it can be assumed (since it's typical) that the first kind flows up to bottom while the second kind follows the opposite way. It can be assumed that endpoints control parameters flows from first line to second line servers and from second line servers to endpoint with periodically clients to servers requests (endpoints are second line servers clients as well as second line servers are clients to first line server).

    Now the issue is how to handle with second line servers outage management. The focus is on the endpoint management data flow since it cannot be suspended unless making the architecture partially unavailable. On the contrary the endpoint information flow temporary suspended can be acceptable. The proposed solution is based on three sub-mechanisms:

    Disclosure is based on three sub-mechanisms: - endpoints scope made customizable for control parameters management; - four status machine on which the first line server makes the second line one walk - backup semi automated choice

Endpoint information flow

endpoint endpoint endpoint endpoint endpoint endpoint endpoint endpoint endpoint

Second line server

Second line server

Second line server

1

[This page contains 2 pictures or other non-text objects]

Page 2 of 3

Customizable endpoint scope

    Every endpoint must have a scope to request essentials parameters. This scope is a set of second line servers that can be contacted. They're downloaded from the second line server the endpoint regularly uses (called the primary) at the first contact and can be modified at runtime on the second line server (it'll be downloaded with a communication service).

Four status machine

    The only architecture role that can be able to manage second line server is the first line server as it's the only one keeping under control them all. So let's assume that the first line server sees a second line one in one of the following four status machine (Figure 2):
1) NOT PLANNED;
2) PLANNED;
3) READY;
4) RETURNING

   Endpoints control parameters have been sent to the backup server (2)

NOT

PLANNED PLANNED

Plan outage

Undo plan outage

 Endpoints control parameters have been returned to the current server (4)

RETURNING

End outage

Undo end outage

READY (3)

Figure 2: second line server four status machine

    The second line server is in NOT PLANNED status unless a plann...