Not registered yet?
Register now! It is easy and done in 1 minute and gives you access to special discounts and much more!
External driving requirements
System main functional areas
System implementation survey
Brief overview of system use cases
Native support by means of specific, ready to run, templates for the configuration of:
Easily extensible application scope, to support configurations not included in the previously listed topics
A general purpose template mechanism:
The SCUBE product (SNMP Shot Sentinel => S3 => Scube) is an application capable of collecting all information from systems and devices that export them using the SNMP protocol.
The reasons that led to the realization of the project were many, so the definition of the targets and of the architecture was decided after a careful study conducted on the pollers most common on the market today.
The many positive and negative considerations made on the products examined led to the definition of the new poller.
SCUBE has been designed to achieve high performance.
The code was developed trying to optimize each function and the use of system resources was designed taking into account the actual performance of the same on the various systems on which it is possible to use the poller.
The set of system-calls and library-functions used was chosen without forgetting the performance aspect.
The measurements conducted on some reference HP systems have allowed us to state that SCUBE is capable of receiving information from about 40,000 objects per minute.
SCUBE has been designed to be used on a wide range of systems and therefore is able to operate on both small systems and large Main-Frames.
Its structure adapts to work with available resources and is therefore designed to require only what the host system can offer in terms of memory / processes / communication, etc ..
It is clear that the more powerful the host system is, the more the poller will be able to offer superior performance.
To ensure maximum scalability of the object, we thought of providing an InterProcessCommunication architecture between the processes capable of guaranteeing the execution of some poller modules, even on remote machines.
What you get is a real "distributed" system, capable of achieving any load target.
In order not to burden the management of IPC systems, we act in "remote" mode only if expressly necessary, in other cases we work strictly locally using the most efficient system.
The load balancing between the various processes that make up the operating scenario is always dynamically calculated and modified according to the operational trend at run-time.
The SCUBE code is written totally in a system-independent way and therefore it is easily portable on any type of operating system.
For the parts strictly related to the host operating system, libraries have been designed that can offer the poller application level an interface independent of the operating system to be used.
To bring the poller to a new system, all you have to do is create a new interface library capable of converting the poller's internal needs into appropriate specific system-calls.
"Small is Beautifull" ... in this case it is true .., the composition of the poller is made up of few parts, so both for the installation and for the run-time you have to check a few components (processes, system resources, configuration files).
The goal of having few elements does not reduce the complexity of a project, in fact the SCUBE-Core is composed of more than 22,000 lines of code and the SNMP library derived from the UCD version of about 28,000.
To reduce consumption, we tried to design an architecture that did not require too many operations from the system for the management of processes and memory resources (semaphores, shared memory, messages queues).
In this sense we have tried to define a number of processes (threads) suitably sized by the actual polling needs and not dictated by fixed rules established by an administrator.
Therefore, an auto-tuning was carried out by the poller himself in a strictly dependent manner on the quantity of actions to be performed.
SCUBE is compatible with HP OpenView, so it can be replaced without special integration efforts.
Both input and output files take the same formats.
SCUBE is set up for communication with SNMP AGENT able to operate with versions 1, 2 and 3 of the SNMP protocol.
The poller is fully configurable, that is, all the levels that make it up can be sized and configured appropriately according to the installation to be made.
The configurability extends from the use of system resources (sockets, files, etc.) to the conditioning of the SNMP protocol.
Analysis for the realization of a new version of a services remotizer (or Adapters Services) developed by third party. The system is used by InfoMobility applications in telecommunication. The new environment, named SPINA (Service Pipe Innterface Automa) has been developed using Web Service (Axis and BEA Service Bus).
Provided services are applications oriented (not device oriented). Applications have simple interfaces and code is lightly affected by their use.
There is a Single Sign On for all the available services. Applications do not see all access procedures required by devices. Using a dedicated configuration, a single login access gives access to all available services to a single user.
The system can be distributed on more servers. This characteristic leads to:
The system can grow (or decrease). Number and power of servers can change according centre needs.
It is possible to perform an automatic services discovery. The mechanism provides the chance to balance and distribute automatically jobs load. If a service is duplicated or tripled, it will be used trying to balance the load of the servers providing it. Clients, using browsing, can know available servers and the suggested one as the best to choose.
All the entities composing the system can be monitored. On all the servers you can check working status of base and external used components.
The system is configurable in all system access, security and load balancing related aspects.
All written code is portable on all common operating systems. So, it is possible to use servers with different OSs.