ES2251118T3 - Gestion de red. - Google Patents
Gestion de red.Info
- Publication number
- ES2251118T3 ES2251118T3 ES98963110T ES98963110T ES2251118T3 ES 2251118 T3 ES2251118 T3 ES 2251118T3 ES 98963110 T ES98963110 T ES 98963110T ES 98963110 T ES98963110 T ES 98963110T ES 2251118 T3 ES2251118 T3 ES 2251118T3
- Authority
- ES
- Spain
- Prior art keywords
- node
- manager
- platform
- service
- status
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0823—Errors, e.g. transmission errors
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/0016—Arrangements providing connection between exchanges
- H04Q3/0062—Provisions for network management
- H04Q3/0095—Specification, development or application of network management software, e.g. software re-use
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/04—Processing captured monitoring data, e.g. for logfile generation
- H04L43/045—Processing captured monitoring data, e.g. for logfile generation for graphical visualisation of monitoring data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/06—Generation of reports
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/06—Generation of reports
- H04L43/062—Generation of reports related to network traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/06—Generation of reports
- H04L43/067—Generation of reports using time frame reporting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
- H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
- H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/16—Threshold monitoring
Abstract
Método para proporcionar una interfaz de software entre programas de aplicación que realizan funciones de telecomunicaciones y un sistema operativo que se ejecuta en al menos un nodo en un sitio que soporta los programas de aplicación, y que forma además una interfaz entre los programas de aplicación y una red de telecomunicaciones, caracterizado por: proporcionar un gestor de la plataforma de red (104) operable para eliminar nodos del servicio, restaurar nodos al servicio, eliminar aplicaciones del servicio, y restaurar aplicaciones al servicio; proporcionar un gestor de integridad del sistema de red (106) operable para monitorizar los nodos y permitir recuperar los nodos fallidos; proporcionar un gestor de configuración (108) operable para interactuar con un anfitrión acoplado a la plataforma de telecomunicaciones; proporcionar un gestor de la plataforma de nodos (112) operable para proporcionar funciones de gestión para un nodo; proporcionar un gestor de servicio (134) operable para iniciar y detener procesos en la dirección del gestor de la plataforma de nodos; y proporcionar un gestor de integridad del sistema de nodos (130) operable para monitorizar los enlaces entre nodos.
Description
Gestión de Red.
Esta invención está relacionada en general con el
campo de las telecomunicaciones. Más particularmente, la invención
se refiere a un método para proporcionar una interfaz de software de
acuerdo con el preámbulo de la reivindicación 1, y a una plataforma
de telecomunicaciones que forma una interfaz de acuerdo con el
preámbulo de la reivindicación 10. Un método y una plataforma de
telecomunicaciones de este tipo son conocidos por: "OSI SYSTEM AND
APPLICATION MANAGEMENT: AN EXPERIENCE IN A PUBLIC ADMINISTRATION
CONTEXT" de MALTINTI P ET AL., 1996 IEEE NETWORK
OPERATIONS AND MANAGEMENT SYMPOSIUM (NOMS), KYOTO, ABRIL,
15-19, 1996, vol. 2, nº SYMP. 5, 15 de abril de 1996
(15-04-1996), páginas
492-500, XP000634813 INSTITUTE OF ELECTRICAL AND
ELECTRONICS ENGINEERS.
Es un objeto de la presente invención
proporcionar una interfaz genérica entre programas de aplicación que
realizan funciones de telecomunicaciones y un sistema operativo que
se está ejecutando en al menos un nodo en un sitio que soporta los
programas de aplicación y que forma además una interfaz genérica
entre los programas de aplicación y una red de
telecomunicaciones.
Este objeto se lleva a cabo mediante un método
según la reivindicación 1 y mediante una plataforma de
telecomunicaciones según la reivindicación 10.
Según la presente invención se da un método para
proporcionar una interfaz de software entre programas de aplicación
que realizan funciones de telecomunicaciones y un sistema operativo
que se está ejecutando en al menos un nodo en un sitio que soporta
los programas de aplicación, y que forma además una interfaz entre
los programas de aplicación y una red de telecomunicaciones. El
método incluye: proporcionar un gestor de la plataforma de red
operable para eliminar nodos del servicio, restaurar nodos al
servicio, eliminar aplicaciones del servicio, y restaurar
aplicaciones al servicio; proporcionar un gestor de integridad del
sistema de red operable para monitorizar los nodos y permitir
recuperar los nodos fallidos; proporcionar un gestor de
configuración operable para interactuar con un anfitrión acoplado a
la plataforma de telecomunicaciones; proporcionar un gestor de la
plataforma de nodos operable para proporcionar funciones de gestión
para un nodo; proporcionar un gestor de servicio operable para
iniciar y detener procesos en la dirección del gestor de la
plataforma de nodos; y proporcionar un gestor de integridad del
sistema de nodos operable para monitorizar los enlaces entre
nodos.
Para una mejor comprensión de la presente
invención se puede hacer referencia a los dibujos adjuntos, en los
que:
Fig. 1, es un diagrama de bloques simplificado de
las capas de la arquitectura de la plataforma de telecomunicaciones
de acuerdo con una realización de la presente invención;
Fig. 2, es un diagrama de bloques simplificado de
los componentes conceptuales de la plataforma de telecomunicaciones
de acuerdo con una realización de la presente invención;
Fig. 3, es un diagrama de bloques de los
componentes conceptuales de la plataforma de telecomunicaciones y
las relaciones entre ellos de acuerdo con una realización de la
presente invención;
Fig. 4, es un diagrama de bloques simplificado de
la partición lógica de la plataforma de telecomunicaciones según una
realización de la presente invención;
Fig. 5, es un diagrama de bloques simplificado de
los servicios de la plataforma de telecomunicaciones y sus
dependencias según una realización de la presente invención;
Fig. 6, es un diagrama de bloques simplificado de
la partición física de la plataforma de telecomunicaciones según una
realización de la presente invención;
Fig. 7A, es un diagrama de bloques del flujo de
comprobación de GPRed según una realización de la presente
invención;
Fig. 7B, es un diagrama de bloques del flujo de
sincronización de tiempo de GPRed según una realización de la
presente invención;
Fig. 7C, es un diagrama de bloques que muestra la
detección de fallos y la interacción entre los servicios de gestión
de red y los servicios de gestión de nodos según una realización de
la presente invención;
Fig. 7D, es un diagrama de bloques que muestra la
interacción entre los servicios del núcleo según una realización de
la presente invención;
Fig. 8, es un diagrama de transición de estado de
los nodos de la plataforma de telecomunicaciones según una
realización de la presente invención.
Fig. 9A, es un diagrama de bloques simplificado
del proceso de arranque de nodo según una realización de la presente
invención;
Fig. 9B, es un diagrama de flujo de mensajes del
proceso de inicialización de nodos según una realización de la
presente invención;
Fig. 9C, es un diagrama de flujo de mensajes del
proceso de inicialización de nodos según una realización de la
presente invención;
Fig. 9D, es un diagrama de flujo de mensajes del
proceso de inicialización de nodos según una realización de la
presente invención;
Fig. 10, es un diagrama de flujo de mensajes del
protocolo de interfaz de gestión de servicio según una realización
de la presente invención;
Fig. 11, es un diagrama de bloques simplificado
que muestra los usos del gestor de eventos según una realización de
la presente invención;
Fig. 12, es un diagrama de flujo simplificado del
parte de información y problemas (PIP) según una realización de la
presente invención;
Fig. 13, es un diagrama de flujo simplificado del
procesamiento de PIP según una realización de la presente
invención;
Fig. 14, es una vista en la interfaz gráfica de
usuario de un PIP ejemplar según una realización de la presente
invención;
Fig. 15, es un diagrama de bloques simplificado
que muestra la recogida de datos según una realización de la
presente invención;
Fig. 16, es un diagrama de bloques simplificado
del subsistema de recogida de datos según una realización de la
presente invención;
Fig. 17, es un diagrama de bloques simplificado
de las trayectorias de comunicación de datos de contador de umbral
según una realización de la presente invención;
Fig. 18, es un diagrama de bloques simplificado
del subsistema de contador de umbral según una realización de la
presente invención;
Fig. 19, es un diagrama de bloques simplificado
del subsistema de manejo de mensajes según una realización de la
presente invención;
Fig. 20, es un diagrama de bloques simplificado
de la comprobación del manejo de mensajes según una realización de
la presente invención;
Fig. 21, es un diagrama de bloques simplificado
del entorno de mensajería de objetos distribuidos según una
realización de la presente invención;
Fig. 22, es un diagrama de bloques simplificado
de las relaciones internas de depuración y traza de objetos según
una realización de la presente invención;
Fig. 23, es un diagrama de bloques simplificado
del sistema de gestión de diccionario según una realización de la
presente invención;
Fig. 24, es un diagrama de bloques simplificado
de la representación de hardware de la plataforma de
telecomunicaciones según una realización de la presente
invención;
Fig. 25, es un diagrama de bloques simplificado
de la representación de software de la plataforma de
telecomunicaciones según una realización de la presente invención;
y
Fig. 26, es un diagrama de bloques simplificado
que muestra la asignación dinámica del software sobre la
representación del hardware de la plataforma de telecomunicaciones
según una realización de la presente invención;
La plataforma de telecomunicaciones (PT) 10 de la
presente invención es un sistema de software diseñado para soportar
el desarrollo y ejecución de aplicaciones de telecomunicaciones 12
distribuidas, escalables y resistentes a fallos. La plataforma de
telecomunicaciones 10 proporciona un conjunto único de herramientas
desarrolladas para un entorno de computación, como por ejemplo UNIX.
Estas herramientas incluyen no sólo el conjunto de interfaces,
librerías y ejecutables proporcionados por los paquetes de
desarrollo y tiempo de ejecución de la plataforma de
telecomunicaciones, sino también un conjunto de componentes
conceptuales necesarios para diseñar y gestionar aplicaciones
distribuidas, escalables y resistentes a fallos.
Como se muestra en la Fig. 1, la plataforma de
telecomunicaciones 10 está formada por tres capas de software
14-16 distintas. La capa nº 1 es una capa 14 de
interfaz de programas de aplicación (API Application Programm
Interface) de la plataforma de telecomunicaciones; la capa nº 2
es una capa 15 de servicios de la plataforma de telecomunicaciones;
y la capa nº 3 es una capa 16 de interfaz de sistemas. La capa API
14 de la plataforma de comunicaciones proporciona los métodos de
comunicación para acceder a la capa 15 de servicios de la plataforma
de comunicaciones, que está formada por servicios de software
intermediario (middleware) de telecomunicaciones. La capa 15 de
servicios de la plataforma de telecomunicaciones es la capa de
software que proporciona los servicios de middleware que se
necesitan más comúnmente para un sistema de telecomunicaciones
basado en UNIX, por ejemplo. La capa 16 interfaz del sistema está
formada por la API del sistema operativo (SO) y los enlaces de red.
La capa 16 de interfaz del sistema define las funciones de proceso y
gestión de hilos, gestión de memoria, temporizadores, sistemas de
archivo, comunicación, interfaz a dispositivos de hardware, y otros
componentes del sistema. La plataforma de telecomunicaciones 10
permite que aplicaciones de cliente de alto nivel 12 sean
desacopladas del sistema operativo y de la red. Mediante el uso de
la plataforma de telecomunicaciones 10 los desarrolladores pueden
escribir aplicaciones sin tener que dominar las complejidades de los
servicios subyacentes, tales como el sistema operativo y la red, que
realizan el trabajo en nombre de la aplicación.
La Fig. 2 es un diagrama de bloques de los
componentes conceptuales asociados a la plataforma de
telecomunicaciones 10. El componente conceptual mínimo es un
elemento configurable (EC) 30. Un elemento configurable 30 está
definido por la plataforma de telecomunicaciones 10 como una o más
copias de un programa ejecutable UNIX que es administrado por la
plataforma de telecomunicaciones 10. Por ejemplo, un elemento
configurable puede ser un proceso de enlace, una base de datos, una
interfaz gráfica de usuario, un proceso de temporización, un proceso
de consulta, manejadores de errores, etc. Los elementos
configurables 30 son los bloques de construcción fundamentales de
los programas de aplicación. Los servicios más básicos que
proporciona la plataforma de telecomunicaciones 10 a los
desarrolladores de la aplicación son aquellos servicios para crear,
configurar, y monitorizar elementos configurables 30. Los elementos
configurables 30 pueden ser configurados para ser iniciados en
puntos específicos durante la inicialización del nodo. La
representación de elementos configurables ejecutable en Unix puede
ser ejecutada muchas veces para escalabilidad o redundancia. Los
umbrales del número de instancias de elementos configurables
requeridos para proporcionar servicios adecuados pueden ser
configurados tanto si las instancias deben ser reiniciadas
automáticamente por la plataforma de telecomunicaciones 10 en el
caso de un fallo del proceso, como si no.
Los atributos configurables de un elemento
configurable incluyen NivelDeEjecución, que es el nivel en el que se
inicia un elemento configurable. NivelDeEjecución incluye PRE_MIN,
OS_MIN, EN_SVC y POST_EN_SVC. El nivel de ejecución PRE_MIN
especifica que el elemento configurable será creado automáticamente
por un subsistema de gestión de servicio en el momento de arranque.
Los elementos configurables PRE_MIN no están monitorizados por el
subsistema gestor de la plataforma. OS_MIN especifica que el
elemento configurable será creado cuando el nodo esté en la
transición a OS_MIN. EN_SVC especifica que el elemento configurable
será creado cuando el nodo esté en la transición a EN_SVC.
POST_EN_SVC especifica que el elemento configurable será creado
cuando el nodo esté en la transición al estado EN_SVC. Otro atributo
configurable es NúmeroDeInstancias, que especifica cuántas copias
del ejecutable van a ser ejecutadas, UmbralEnServicio es un atributo
configurable que especifica cuántas de NúmeroDeInstancias se
requiere que estén dispuestas y ejecutándose para hacer que el
estado del elemento configurable sea HABILITADO. Si el número de
instancias cae por debajo de este umbral, el elemento configurable
completo o todas las instancias de elemento configurable son
eliminados. Otro atributo del elemento configurable es
PlanificaciónLatidos que especifica la planificación para que los
mensajes de latidos sean enviados a un elemento configurable. Cada
elemento configurable tiene también una PlanificaciónAuditoría, que
especifica la planificación para que los mensajes de auditoría sean
enviados al elemento configurable.
Un conjunto de elementos configurables (ConjEC)
26 está definido por la plataforma de telecomunicaciones 10 como un
grupo de elementos configurables diseñados para ser desplegados
juntos en uno o más nodos 24. Un conjunto de elementos configurables
es un componente distribuible. La plataforma de telecomunicaciones
10 puede no gestionar los conjuntos 26 de elementos configurables
directamente, pero soporta su creación y despliegue. Los conjuntos
26 de elementos configurables pueden ser contemplados como los
componentes distribuibles y/o replicables de una aplicación 28.
Una aplicación 28 está definida como un grupo de
conjuntos 26 de elementos configurables que definen por completo
todos los elementos configurables 30 de un programa distribuido. La
plataforma de telecomunicaciones 10 proporciona software para
gestionar las aplicaciones 28 dentro de un sitio 20. Definir la
configuración de las aplicaciones en términos de sus componentes
distribuibles permite que el software para una aplicación
distribuida sea definido independientemente del hardware en el que
será ejecutado. Los conjuntos de elementos configurables de una
aplicación en algún momento en el tiempo serán desplegados a los
nodos 24 de un sitio 20. Cuando esto ocurra la escala y la
resistencia a fallos de la aplicación 28 serán determinadas en base
al número de nodos usados para soportar cada conjunto de elementos
configurables.
Un nodo 24 está definido como una instancia de un
sistema operativo soportado en el que es ejecutada la plataforma de
telecomunicaciones 10. La plataforma de telecomunicaciones 10
proporciona el software que gestiona los procesos en los nodos 24.
Los nodos 24 pueden ser tolerantes a fallos o no tolerantes a
fallos, de un solo procesador o multiprocesador. La plataforma de
telecomunicaciones 10 usa los servicios del sistema operativo y
generalmente ignora el hardware en el que está siendo ejecutado. La
plataforma de telecomunicaciones requiere muy poca información de
configuración para un nodo 24. Los nodos son configurados en el
sistema proporcionando su nombre e identificadores de dispositivo
únicos.
Los nodos 24 tienen estados de operación,
soportados por la plataforma de telecomunicaciones, que describen la
ordenación de los elementos configurables iniciados dentro de ellos.
Los estados de operación incluyen DETENIDO, PRE_MIN, OS_MIN, EN_SVC
y POST_EN_SVC. El estado de nodo DETENIDO indica que el sistema
operativo del nodo ha sido cerrado. El estado PRE_MIN es usado para
iniciar elementos configurables que tienen que ser iniciados antes
de que sean iniciados los elementos configurables en los estados
OS_MIN. La plataforma de telecomunicaciones inicia todos los
elementos configurables que están configurados para ser ejecutados
en PRE_MIN para dicho nodo en primer lugar, luego empiezan
inmediatamente a ser ejecutados los elementos configurables que
están configurados para ser ejecutados en el estado OS_MIN. Los
elementos configurables que están configurados para ser ejecutados
en PRE_MIN no afectan directamente al estado del nodo. El estado de
nodo OS_MIN coordina que todos los elementos configurables
configurados para el nivel de ejecución OS_MIN sean iniciados para
llevar al nodo al estado OS_MIN. Todos los elementos configurables
configurados para el estado de nodo OS_MIN consiguen su estado de
transición al nivel de ejecución configurable antes de que se diga
que el nodo ha hecho la transición a OS_MIN. Una vez que el estado
de nodo OS_MIN ha sido conseguido, si cualquier elemento
configurable cambia su estado para estar por encima de su estado de
transición al nivel de ejecución, la plataforma de
telecomunicaciones bajará de grado el nodo al estado de nodo
DETENIDO. Un nodo cerrado puede recuperarse automáticamente. El
estado de nodo EN_SRV coordina los elementos configurables
configurados para el nivel de ejecución EN_SRV. Todos los elementos
configurables configurados para el estado de nodo EN_SRV alcanzan su
estado de transición al nivel de ejecución configurable antes de que
el nodo haya hecho la transición a EN_SRV. Una vez que el estado de
nodo EN_SRV ha sido alcanzado, si cualquier elemento configurable
cambia su estado para estar por debajo de su estado de transición al
nivel de ejecución, la plataforma de telecomunicaciones bajará de
grado el nodo al estado de nodo OS_MIN. La recuperación automática
de un nodo puede producirse si la bajada de grado de nodo no fue
originada manualmente. El estado de nodo POST_EN_SRV es usado para
configurar elementos configurables que van a ser iniciados
inmediatamente después de que un nodo ha hecho la transición a
EN_SRV. Una vez que un nodo ha alcanzado EN_SRV, la plataforma de
telecomunicaciones crea cada elemento configurable POST_EN_SRV. Los
cambios de estado para los elementos configurables POST_EN_SRV no
afectan al estado de nodo, y pueden ser iniciados y detenidos
repetidamente. El proceso de detención de un elemento configurable
POST_EN_SRV no hace que el nodo sea bajado de grado a un estado de
nodo inferior.
Un sitio 20 es definido por la plataforma de
telecomunicaciones como un grupo de nodos a través de los cuales
pueden ser desplegadas las aplicaciones distribuidas. La plataforma
de telecomunicaciones proporciona una aplicación de la plataforma de
telecomunicaciones conocida como el gestor de la plataforma que
gestiona los nodos 24 dentro de un sitio 20. Un sitio puede estar
formado por al menos un nodo. En sitios de múltiples nodos, la
aplicación gestor de la plataforma puede ejecutarse como una
aplicación distribuida activa/en espera en dos de los nodos. En
sitios de nodo único, la aplicación gestor de la plataforma se
ejecuta en el nodo único junto a aplicaciones definidas por el
usuario, pero se ejecuta sin las capacidades de tratamiento de
errores proporcionadas por un nodo en espera. La administración de
un sitio es proporcionada a través del gestor de la plataforma.
Un grupo de servicio del procesador (GSP) 22 se
define como un grupo de nodos en el que se despliega un conjunto 26
de elementos configurables específicos por redundancia. La
plataforma de telecomunicaciones 10 proporciona aplicaciones de
software para gestionar los grupos de servicio del procesador dentro
de una aplicación. Los grupos de servicio del procesador soportan la
redundancia permitiendo al usuario de la plataforma de
telecomunicaciones identificar el número de nodos en el que se
requiere que un conjunto de elementos configurables sean ejecutados
para proporcionar un nivel de servicio adecuado. Cuando el estado de
los nodos o los conjuntos de elementos configurables ejecutándose en
ellos cambia, la plataforma de telecomunicaciones 10 verifica que el
nivel de servicio apropiado se mantiene o cambiará el estado de la
aplicación según esté configurado.
La Fig. 3 es un diagrama que ilustra un diseño de
sistema 40 que emplea los componentes conceptuales de la plataforma
de telecomunicaciones 10 que están asignados sobre los componentes
de hardware.
En términos de la configuración de hardware, un
nodo es un procesador de ordenador dentro de una red (tal como
ethernet) que puede actuar como un cliente o como un servidor. Cada
nodo tiene una instancia única del sistema operativo ejecutándose en
él. Los procesadores dentro de un nodo no pueden ejecutarse de forma
independiente entre sí debido a su dependencia del sistema
operativo. Cada nodo en un sitio puede ser clasificado como un
gestor de la plataforma o un nodo de la aplicación. Un sitio puede
consistir en un nodo o en una agrupación de nodos que están
conectados a un anfitrión. El nodo del gestor de la plataforma tiene
un compañero redundante. El nodo del gestor de plataforma y su
compañero pueden operar en un modo activo/en espera o en un modo de
carga compartida.
El sistema 40 tiene ocho nodos que incluyen dos
nodos del gestor de la plataforma (activo 42 y en espera 43) y seis
nodos de la aplicación 44-49. Una aplicación 50 para
el tratamiento de llamadas telefónicas basada en el tiempo en que es
establecida la llamada o enrutamiento dependiente del tiempo, es
desplegada a través de los nodos. Los conjuntos 52 y 54 de elementos
configurables de la aplicación 50 son los componentes distribuidos
que suministran la funcionalidad de enrutamiento dependiente del
tiempo. Cada conjunto 52 y 54 de elementos configurables contiene
los procesos de software de los programas ejecutables en UNIX o
elementos configurables para una zona de tiempo específica. Como se
muestra, la aplicación 50 no tiene que residir en un único nodo de
la aplicación 44-49. Puede ser deseable asignar los
conjuntos de elementos configurables sobre nodos diferentes. Esto
hace posible escalar la aplicación incrementando el número de nodos
para los que son configurados los conjuntos de elementos
configurables.
La arquitectura interna de la plataforma de
telecomunicaciones está descrita desde las perspectivas de la
partición lógica y la física. La partición lógica descompone la
plataforma de telecomunicaciones en zonas funcionales distintas como
se muestra en la Fig. 4. Cada zona funcional contiene un grupo
coherente de clases, que juntas proporcionan una función particular
del sistema. La partición física describe la descomposición concreta
de software y hardware del contexto del sistema. Los servicios
proporcionados por la plataforma de telecomunicaciones 10 pueden ser
divididos en dos grupos: servicios de la aplicación 60 y servicios
del núcleo 62. Los servicios de la aplicación pueden incluir
servicios que realizan partes de información y problemas
(PIP)/alarma 64, estadísticas 65, diccionario 66, interfaz gráfica
de usuario (IGU) 67 y simulador de mantenimiento del anfitrión
(SMA). Los servicios PIP/alarma 64 proporcionan un mecanismo
estándar para informar al usuario del sistema de estados de error y
otra información del sistema pertinente. Los servicios de
estadística 65 proporcionan los métodos para acceder a los datos de
medida a lo ancho del sistema y para generar partes basados en los
datos recogidos. Los servicios de diccionario 66 proporcionan clases
que están diseñadas para soportar almacenamiento de datos
(permanente, compartido o privado) y para acceder a los datos. Los
servicios de interfaz gráfica de usuario 67 proporcionan
abstracciones primitivas para construir aplicaciones IGU y para
acceder a las utilidades del sistema y al propio sistema, por
ejemplo ventanas xterm y programas de utilidades del sistema
operativo. Los servicios de simulador de mantenimiento del anfitrión
75 proporcionan un método de interacción con la plataforma de
telecomunicaciones cuando hay un único nodo dentro del sistema o
cuando no hay un anfitrión al que conectarlo. Es a través del
anfitrión que se hace posible el control y la operación de la
plataforma.
Los servicios del núcleo 62 pueden incluir
servicios que realicen gestión de red 68, gestión de nodos 69,
objeto distribuido 70, comunicaciones 72, funciones comunes 73 y
tratamiento de eventos 74. Los servicios de gestión de red 68
dirigen las actividades de la red, por ejemplo, la configuración de
los nodos y el procesamiento de errores a nivel de red. Los
servicios de gestión de nodos 69 dirigen los procesos a nivel de
nodos, por ejemplo el informe del estado de los nodos y la gestión
de enlaces. Los servicios de objeto distribuido 70 proporcionan un
repositorio de la base de datos distribuida para la comunicación
basada en objetos en un entorno de multiprocesamiento. Los servicios
de comunicaciones 72 proporcionan el mecanismo para el manejo de
mensajes a través de enlaces de interprocesamiento externos a la
plataforma. Los servicios comunes 73 proporcionan una librería de
herramientas de programación para ayudar en el desarrollo rápido de
los procesos diseñados para ser ejecutados sobre o dentro de la
plataforma de telecomunicaciones. Los servicios de eventos 74
proporcionan la capacidad para iniciar, terminar, y/o distribuir
acciones específicas significativas para una tarea.
Como mínimo, la plataforma de telecomunicaciones
proporciona todos los servicios del núcleo. Las aplicaciones de alto
nivel usan estos servicios para llevar a cabo las funciones de nivel
inferior.
La Fig. 5 muestra además los servicios de la
plataforma de telecomunicaciones y sus dependencias. El
desarrollador accede a todos los servicios del núcleo y de la
aplicación a través de las interfaces de programas de aplicación 14
de la plataforma de telecomunicaciones. El desarrollador puede
acceder también al sistema operativo, la red, y software/hardware de
terceros si surge la necesidad. La comunicación entre procesos
basada en objetos es manejada por los servicios de comunicación 72.
La mayoría de los servicios del núcleo y de la aplicación dependen
de los servicios de comunicación 72 y los servicios comunes 73 para
realizan sus funciones respectivas. Los servicios de interfaz
gráfica de usuario 67 pueden depender sólo de los servicios de
comunicación 72. Las flechas de la Fig. 5 indican las relaciones de
dependencia entre los servicios.
La Fig. 6 es un diagrama de la partición física
de la plataforma de telecomunicaciones 10 que incluye una capa de la
aplicación 80 y una capa del núcleo 82. La capa del núcleo 82 que
contiene servicios del núcleo 62 existe para cada instancia de la
plataforma de telecomunicaciones. La capa de núcleo 82 contiene la
API 14 de la plataforma de telecomunicaciones, mecanismos de
telecomunicación entre procesos, mecanismos de eventos y gestión de
la plataforma. La capa de aplicaciones 80 de la plataforma de
telecomunicaciones tiene particiones verticales y horizontales.
Verticalmente, cada proceso de la aplicación de la plataforma de
telecomunicaciones es clasificado como una parte de un conjunto
principal de aplicaciones 84 o no. Los procesos de conjuntos no
principales dependen de los procesos de conjuntos principales.
Horizontalmente, las aplicaciones 80 de la plataforma de
telecomunicaciones se clasifican como sea requerido u opcionalmente.
Las aplicaciones opcionales pueden incluir un paquete PIP/alarma 86,
un paquete de recogida de datos 87, un paquete de sistema de gestión
de diccionario 88 y un paquete de simulación de mantenimiento de
anfitrión 89.
La siguiente es una descripción más detallada de
los servicios de la plataforma de telecomunicaciones.
Los servicios de gestión de red 68 proporcionan
una perspectiva administrativa común del elemento de red. Es
responsable de implementar operaciones de alto nivel sobre los nodos
de elemento de red, tales como eliminar del servicio nodos de
servidor, restaurar nodos de servidor al servicio, eliminar
aplicaciones del servicio, restaurar aplicaciones al servicio,
habilitar o deshabilitar aplicaciones, mantener el estado de
aplicaciones distribuidas, mantener estado y condición de nodos de
servidor e informar de cambios de estado de aplicación. Los
servicios de gestión de red 68 incluyen un gestor de la plataforma
de red (GPRed), un subsistema de integridad del sistema de red
(ISRed) y un gestor de configuración (GtrConfig). La Fig. 7A es un
diagrama de bloques que muestra un nodo activo 100 del gestor de la
plataforma activo con un nodo en espera 102 del gestor de la
plataforma correspondiente o compañero. Cada nodo del gestor de
plataforma incluye un gestor de la plataforma de red 104, un
subsistema de integridad de sistema de red 106 y un gestor de
configuración 108. Un controlador de comprobación de red 110 del
gestor de la plataforma proporciona comprobación de nivel de
red.
El nombre de clase para el gestor de la
plataforma de red es GPRed. GPRed es responsable de proporcionar la
funcionalidad de gestión de los recursos de la plataforma. La
plataforma es un sistema distribuido que consiste en múltiples nodos
o servidores que proporcionan potencia de procesamiento para
servicios específicos, tales como validación de tarjetas de llamadas
telefónicas o tarjetas de crédito. El servicio proporcionado por un
servidor está determinado por los elementos configurables residentes
en el nodo. GPRed gestiona todos los datos de configuración
asociados a la plataforma. Los datos de configuración incluyen
información acerca del hardware, tales como la dirección TCP/IP de
un servidor, información de estado, tal como estado de servidor y
estado de consulta, información de configuración de software, tal
como tipo de aplicación, nombre de nodo, e información relativa a
los elementos configurables individuales.
GPRed mantiene la siguiente información de
configuración. Esta información es recogida por GPRed durante su
inicialización.
- \bullet
- Información de descriptor de elemento configurable -Proporciona la información de configuración para cada elemento configurable de la plataforma. GPRed recupera ésta de un archivo de disco que contiene la información sobre elementos configurables de tipos diferentes.
- \bullet
- Información de la aplicación - Proporciona información de configuración acerca de cada aplicación (servicio), que puede ser usada para calcular el estado de una aplicación. GPRed recupera esta información de un archivo de disco que contiene la información para todas las aplicaciones en la plataforma.
- \bullet
- Información de grupo de servicio del procesador - Proporciona información de configuración acerca de los grupos de servicio del procesador, que pueden ser usados en el cálculo del estado del grupo de servicio del procesador (el grupo de servicio del procesador designa al grupo de procesadores que sirven a la misma aplicación, es decir, CCD, CCL). GPRed recupera éstos de un archivo de disco que contiene la información para todos los grupos de servicio del procesador en la plataforma.
- \bullet
- Información de servidor - Proporciona información específica acerca de todos los servidores en la plataforma. GPRed solicita y recupera esta información del GtrConfig. GtrConfig dota a GPRed de la información de servidor en los nodos del gestor de la plataforma en primer lugar. Después, si GtrConfig determina que el servidor actual es el gestor de la plataforma activo, dota a GPRed local de la información sobre los restantes servidores en la plataforma. En otro caso (gestor de la plataforma en espera), GPRed recuperará esta información de su compañero, y no de GtrConfig.
Si es detectado un error mientras que se recoge
esta información GPRed emite PIPs apropiados y sale.
GPRed usa un objeto MapRed para gestionar todos
los datos de configuración. GPRed usa también un diccionario
permanente para retener el estado del servidor, estado de consulta,
e información de acciones planificadas a través de
reinicializaciones del gestor de la plataforma. Un objeto
Diccionario de Archivo de Disco es usado para gestionar este
diccionario. GPRed es responsable de mantener la integridad de los
datos de configuración entre los dos servidores del gestor de la
plataforma. GPRed usa un diccionario permanente, compensación de
bases de datos y auditoría para mantener la integridad de los
datos.
El estado de la aplicación es determinado en base
al estado del grupo de servicio del procesador. Los siguientes
criterios son usados en la determinación del estado del grupo de
servicio del procesador:
- \bullet
- GSP_DESHABILITADO - Al menos un número de conjuntos de servidores en el grupo de servicio del procesador están en estado deshabilitado.
- \bullet
- GSP_INACTIVO - Al menos un servidor en cada grupo de servicio del procesador está en estado en espera, y ninguno está en estado activo.
- \bullet
- GSP_ACTIVO_MINIMAL - Sólo cierto número de servidores en el grupo de servicio del procesador están en estado activo.
- \bullet
- GSP_ACTIVO - Un número de conjuntos de servidores en el grupo de servicio del procesador están en estado activo. (Nota: Este número será mayor que el número de servidores que tienen que estar activos para GSP_ACTIVO_MINIMAL.)
y el estado de la aplicación puede
ser derivado usando los siguientes
criterios:
- \bullet
- AP_DESHABILITADA - Al menos un número de conjuntos de los grupos de servicio del procesador para la aplicación dada tienen estado de GSP_DESHABILITADO.
- \bullet
- AP_INACTIVA - Al menos un grupo de servicio del procesador para la aplicación dada tiene estado de GSP_INACTIVO y ningún grupo de servicio de procesador tiene estado de GSP_ACTIVO.
- \bullet
- AP_ACTIVA_MINIMAL - Un número de conjuntos de grupos de servicio de procesador para la aplicación dada tiene estado de GSP_ACTIVO_MINIMAL o mayor (GSP_ACTIVO).
- \bullet
- AP_ACTIVA_PARCIAL - Un número de conjuntos de grupos de servicio del procesador para la aplicación dada tiene estado de GSP_ACTIVO_MINIMAL o mayor (GSP_ACTIVO). (Nota: el número de grupos de servicio del procesador requerido para el estado AP_ACTIVA_PARCIAL es mayor que el número de grupos de servicio del procesador requerido para AP_ACTIVA_MINIMAL).
- \bullet
- AP_ACTIVA - Un número de conjuntos de grupos de servicio del procesador para la aplicación dada tienen estado de GSP_ACTIVO (Nota: el número de grupos de servicio del procesador requerido para el estado AP_ACTIVA es mayor que el número de grupos de servicio del procesador requerido para AP_ACTIVA_PARCIAL).
GPRed mantiene la pista de los cambios de estado
en cada nodo de servidor, y a medida que los obtiene determina el
estado del grupo de servicio del procesador y en caso de cambio
determina el nuevo estado de la aplicación para el nodo, e informa a
GtrConfig de estos cambios.
GPRed proporciona las actualizaciones solicitadas
y autónomas en el estado de la aplicación. Para actualizaciones
autónomas, el proceso de aplicación registra en primer lugar una
función con GPRed para recibir actualizaciones para un tipo de
aplicación particular (CCD o CCL). Siempre que GPRed recibe un
cambio de servidor o estado de consulta desde GPNodo, el estado de
la aplicación es calculado y la función registrada es llamada con
estados de la aplicación viejo y nuevo. El estado de la aplicación
puede también ser solicitado, durante lo cual GPRed devolverá el
último valor calculado de estado de la aplicación salvado en su
MapRed al proceso que lo requiera.
GPRed proporciona, parcialmente a través del uso
de dos objetos alias, dos conjuntos de opciones de enrutamiento a
otros procesos que deseen comunicar con GPRed. GPRed proporciona una
opción activo-en espera local y una global. En la
opción local todas las solicitudes de cliente de GPRed son enviadas
al objeto servidor de GPRed en el mismo nodo que el objeto cliente.
En la opción activo-en espera global, todas las
solicitudes de cliente de GPRed son enviadas al objeto servidor de
GPRed activo disponible globalmente (es decir, posiblemente entre
nodos).
GPRed proporciona un conjunto de funciones de
lectura y escritura para muchos de los datos de configuración de
servidor. Éstos incluyen lectores/escritores para los datos de
planificación de acciones, los datos de estado activo del gestor de
la plataforma, los datos de estado de servidor, etc. GPRed
proporciona operaciones de lectura/escritura no directas para los
datos de descripción de elementos configurables.
GPRed proporciona también una función para
inicializar la mayoría de los datos de configuración del servidor.
Esta función espera un objeto MsjInfoServidor como entrada.
GPRed proporciona un conjunto de funciones que
hacen que una acción de configuración específica (tal como detección
controlada, detección inmediata, bajada de grado controlada, y
restauración) se produzcan en un servidor específico.
GPRed proporciona una función en la que el estado
del servidor puede ser cambiado en un servidor específico.
GPRed proporciona una función para habilitar y
una función para deshabilitar el procesamiento de consulta en un
servidor específico.
GPRed proporciona varias funciones que
"informan" del estado del servidor y cambios en el estado de
consulta. Estas rutinas salvan la información de nuevo estado en
MapRed, notifican al software del GtrConfig el cambio y difunden el
cambio a todo el software del GPNodo en la plataforma.
GPRed es responsable también de la sincronización
de tiempo dentro de la red del servidor. La sincronización de tiempo
consiste en tres partes principales, como se muestra en la Fig. 7B.
La primera parte es para que el gestor de la plataforma activo 100
sincronice su tiempo local con el tiempo del anfitrión. Esto incluye
convertir el tiempo del anfitrión (110) en una forma utilizable e
informar a los GPNodos 112 en los nodos 100 y 102 del gestor de la
plataforma de que realicen una función ajttiempo () para ajustar sus
relojes en línea con el anfitrión 110. GPRed 104 informa también a
la clases de relojes del anfitrión del nuevo tiempo del anfitrión
cuando recibe el mensaje de tiempo. Un proceso xntp 120 sincroniza
entonces el tiempo de los nodos (121) de la aplicación con el tiempo
de los nodos 100 y 102 del gestor de la plataforma. Cada uno de los
nodos 100 y 102 del gestor de plataforma están configurados como
fuentes de tiempo maestras xntp. Los esclavos del demonio xntp 122
en los nodos 121 de la aplicación eligen uno de los demonios xntp
maestros 120 en los nodos 100 y 102 del gestor de la plataforma para
mantenerse sincronizados con él. Finalmente, siempre que sea
recibido un mensaje Ajustar Tiempo no solicitado desde el anfitrión
110, el tiempo de la red es el mismo que el tiempo recibido.
Finalmente, GPRed 104 proporciona una función que
dota a un nodo recién arrancado de datos de configuración de
servidor pertinentes de todos los servidores en la plataforma. GPRed
104 es un elemento configurable. GPRed 104 proporciona las
operaciones no encapsuladas: Eliminar, Restaurar y ObtenerEstado que
requiere GPNodo para controlar la ejecución de GPRed.
ManejadorTemporizadorGPRed es llamado cuando se dispara el
temporizador de auditoría. Cancela la provisión del bucle de
servicio y llama a la función "AjustaTiempoParaVerificar" para
iniciar la auditoría.
GPRed 104 es un objeto con su propio hilo de
control. Después de formar sus listas MapRed, GPRed 104 entra en un
bucle infinito esperando solicitudes. GPRed 104 notifica a GtrConfig
108 siempre que hay un cambio en el servicio o estado de consulta de
un servidor. GPRed 104 envía también estos cambios de estado a todos
los GPNodos 112 en la plataforma. GPRed 104 notifica al GPNodo 104
específico que habilite, o deshabilite el procesamiento de consulta.
GPRed 104 proporciona funcionalidad de sincronización de estado de
servicio. GPRed 104 construye la información IPU para los servidores
en la plataforma y pasa esta información al GPNodo 112 específico en
la función miembro NotificarArranque. GPRed, en todas las
solicitudes de configuración de bajada de grado de servicio (esto
es, bajada controlada, bajada inmediata, detención controlada, y
detención inmediata) notifica al GPNodo 112 específico el estado
deseado del servidor. GPRed 104 hace varias cosas cuando es
solicitada una restauración de servidor. En primer lugar, GPRed 104
obtiene el estado actual del servidor a partir del GPNodo 112
específico. En segundo lugar, si el estado devuelto es fuera de
servicio/software mínimo, GPRed 104 envía al GPNodo 112 específico
la InfoEspecífNodo relevante. En tercer lugar, GPRed 104 envía la
información de descriptor de elemento configurable relevante al
GPNodo 112 específico. Finalmente, GPRed le dice al GPNodo
específico que restaure el servicio.
El subsistema 106 de integridad de sistema de red
(ISRed) proporciona operaciones de monitorización y recuperación
para el elemento de red. Es responsable de implementar la
monitorización y recuperación de red. Las operaciones implementadas
por la integridad del sistema de red incluyen:
- -
- Monitorizar el estado activo/en espera del gestor de la plataforma
- -
- Correlación de partes de fallo de nodo
- -
- Acciones de recuperación de nodos fallidos
El nombre de clase de la Integridad del Sistema
de Red es ISRed. ISRed 106 gestiona la integridad del sistema de red
para el gestor de la plataforma. ISRed 106 recibe notificaciones de
bajadas de grado de servidor y errores de comunicación desde el
ISNodo en el nodo con fallos. ISRed 106 determina qué acción debería
ser acometida en base a los datos dados por ISNodo. Si el nodo
indica una bajada de grado, ISRed acometerá la acción apropiada para
bajar el grado del nodo del nivel de red al estado de menor grado
deseado. Si el nodo indica un error de comunicación, ISRed 106
determinará qué nodo tiene fallos (si hay alguno) a partir de los
datos recibidos anteriormente y acometerá la acción para bajar el
grado del nodo con fallos si es necesario. Cuando ISRed determine
que se requiere una bajada de grado para un nodo, ISRed llama a la
operación de GPRed apropiada para realizar la bajada de grado. Si se
requiere un cambio en el estado activo, ISRed llama a la operación
de GPRed apropiada para ajustar el estado activo. Después de que
GPRed es llamado para realizar la bajada de grado, ISRed notifica a
GtrConfig que el estado está cambiando para un nodo particular. Esto
permite al anfitrión ser informado inmediatamente de que un nodo
está siendo bajado de grado. ISRed entonces escribe una entrada al
parte de configuración de red indicando el cambio de estado y el
motivo para ello. ISRed baja de grado los nodos al estado de
servicio legal en base al estado actual del nodo.
ISRed contiene una lista de errores de
comunicación. Esta lista retiene el nombre del nodo de servidor que
informa y el nombre del nodo de servidor con problemas de cada parte
de errores de comunicación recibido. Cuando es recibido un parte de
errores de comunicación, la lista es investigada buscando otro parte
acerca del nodo con problemas. Si no se encuentra, la información de
error es añadida a la lista. ISRed contiene también una lista de
información de descenso de estado. Cuando GPNodo indica que un nodo
está fuera de servicio y el estado de GPRed no indica que el nodo
está detenido, se crea una entrada de información de descenso de
estado con el nombre del nodo de la IPU detenida. Un temporizador es
creado y la información de descenso de estado es añadida a la lista.
Si GPNodo indica posteriormente un estado más alto para dicho nodo
(antes de que expire el temporizador); la entrada de información de
descenso de estado es borrada de la lista y no se lleva a cabo otra
acción.
ISRed audita rutinariamente las condiciones de
estado de ambos GPs. Si están presentes condiciones inválidas, ISRed
intenta corregir la situación ajustando el estado activo al estado
correcto. Otros procesos pueden también solicitar a ISRed que audite
las condiciones de estado del gestor de la plataforma.
ISRed opera con un concepto de carga compartida
"enviar a ambos". Si ambos nodos del gestor de la plataforma
son operacionales, cada proceso de ISRed sobre cada nodo del gestor
de la plataforma recibirá la petición de ISNodo. Cada proceso de
ISRed determinará si debería manejar la solicitud en base al estado
activo/en espera de la plataforma y al servidor con fallos. El
proceso de ISRed del gestor de la plataforma activo usualmente
emprenderá la acción requerida mientras que el gestor de la
plataforma en espera descarta la información. Sin embargo, si el
nodo con fallos es el gestor de la plataforma activo, el gestor de
la plataforma en espera (si es válido) se ajustará a sí mismo a
activo y emprenderá la acción solicitada para bajar de grado al otro
nodo gestor de la plataforma.
Cada vez que es invocada una operación de ISRed,
ISRed en primer lugar determina si es el gestor de la plataforma
activo o en espera. Si es el activo, ISRed procesará la solicitud
para todas las condiciones excepto cuando el nodo objetivo sea él
mismo y el compañero está en servicio. Si es el en espera, ISRed
descartará la solicitud para todas las condiciones excepto cuando el
nodo objetivo sea el compañero.
Durante la inicialización ISRed solicita el
nombre del nodo del compañero y los descriptores del servidor de su
propio servidor y del servidor compañero de GPNodo. Antes de
solicitar la información ISRed sondea el estado de GPNodo, y no
requerirá el nombre del nodo y los descriptores del servidor hasta
que GPNodo sea leído para proporcionarlos. ISRed no estará listo
para proporcionar servicio hasta que esta información sea recibida
correctamente.
ISRed usa el parámetro de la línea de comandos
BAJAR_ARCH_PRT para obtener el nombre de la configuración de red
(bajar de grado) nombre de archivo de parte. Si este parámetro no es
especificado, no se hace entrada de parte de las bajadas de
grado.
Con referencia a las figuras 7C y 7D, se muestra
la interacción de procesos entre la gestión de nodos y la gestión de
red. Monitor Constante (MonCon) 132 es una instancia de un objeto
que se ejecuta en el nodo de la aplicación 136. MonCon 132 detecta
un proceso erróneo o un elemento configurable fallido, lo notifica a
un programa de proceso de gestión de servicio 134. El proceso de
gestión de servicio 134 determina si el error de elemento
configurable hace que el proceso caiga por debajo de su nivel
umbral. Si no es así, el proceso de gestión de servicio 134 reinicia
el elemento configurable. Sin embargo, si el elemento configurable
no cae por debajo de su nivel umbral entonces el proceso de gestión
del servicio 134 genera un mensaje de cambio de estado de elemento
configurable y remite la notificación a ISNodo 130. ISNodo remite el
cambio de estado de elemento configurable a GPNodo 112. GPNodo 112
determina si el cambio de estado del elemento configurable afecta al
nivel de ejecución del nodo, lo que podría provocar una bajada de
grado del nodo. Si el nodo va a ser eliminado, GPNodo 112
proporciona instrucciones al proceso de gestión de servicio 134 para
eliminar todos los elementos configurables necesarios para conseguir
el estado con grado bajado. GPNodo 134 notificó a GPRed 104 el
cambio de estado de nodo. GPRed 104 realiza un cálculo para
determinar si el cambio de estado de nodo afecta al grupo de
servicio del procesador y al estado de la aplicación. El cálculo de
GPRed determina también si una acción propia, tal como eliminar un
nodo de en servicio a min-set y restaurarlo de
nuevo, debería ser realizado en el nodo. Si el nodo va a ser
eliminado, entonces el cambio de estado de nodo es remitido desde
GPRed a GtrConfig 108. GtrConfig notifica al anfitrión 140 el cambio
de estado para el nodo, el grupo de servicio del procesador y la
aplicación. Estos cambios de estado puede ser visualizados o
impresos en un parte.
En particular, cada ISRed determina si debería
manejar la solicitud de bajada de grado. Si es así, es recuperado el
estado del servidor objetivo. Si el servidor objetivo no está ya
detenido, el servidor es bajado de grado al estado apropiado en base
al estado IPU. Si el estado IPU es fuera de servicio, ISRed llama a
la operación detención inmediata de GPRed para una autodetención o
detención manual del nodo objetivo. Si el estado IPU es fuera de
servicio minimal (OS-MIN), ISRed llama a la
operación bajada de grado inmediata del GPRed para bajar de grado
del nodo objetivo a OS-MIN. Si el estado IPU es en
servicio deshabilitado, ISRed llama a la operación de consulta de
deshabilitación de GPRed para deshabilitar el estado de consulta
para el nodo objetivo. En todos los casos, ISRed actualiza el estado
activo si el nodo objetivo es el gestor de la plataforma activo.
También, si el nodo objetivo es parte del sitio local, ISRed informa
al anfitrión vía GtrConfig de que se está produciendo un cambio de
estado e inicia la recuperación del grupo de servicio del procesador
(a través de GtrConfig) si determina que el grupo de servicio del
procesador del servidor objetivo debería ser recuperado. ISRed
escribe entonces una entrada al archivo de partes de configuración
de red indicando el cambio de estado que se está produciendo debido
a que el nodo está informando de un fallo.
ISNodo informa a ISRed de errores de comunicación
que se producen entre dos nodos. ISRed almacena o actúa sobre el
error en base a la información previa recibida (si existe). Cada
ISRed determina el estado de los nodos el que informa y el que tiene
problemas. Si cualquier servidor es detenido, el parte de error de
comunicación es descartado puesto que no puede ser asegurada la
integridad de los datos. Si ningún servidor es detenido, la lista de
errores de comunicación es investigada buscando otro parte sobre el
nodo con problemas. Si no se encuentra ningún parte sobre el nodo
con problemas, es añadida una entrada a la lista de errores de
comunicación a la lista con la información del servidor. Si se
encuentra otro parte del nodo con problemas y otro servidor
informando ha informado de ello, el servidor con problemas es
ajustado para el procesamiento de bajada de grado. Una vez que se ha
tomado una decisión acerca de si el servidor debería ser bajado de
grado, ISRed determina si debería tratarlo (en base a su estado
activo y si es el mismo el servidor objetivo o no). Si debería
tratar la bajada de grado, ISRed llama a la operación Detención
Inmediata de GPRed para una Autodetención o Detención Manual del
nodo con problemas. Si el servidor a ser detenido es el GP activo,
ISRed actualiza el estado activo correspondientemente antes de
detener el nodo. También, si el objetivo es parte del sitio local,
ISRed informa al anfitrión vía GtrConfig de que se está produciendo
un cambio de estado e inicia la recuperación del grupo de servicio
del procesador (a través de GtrConfig) si determina que el grupo de
servicio del procesador del servidor objetivo debería ser
recuperado. ISRed escribe también una entrada al archivo de parte de
configuración de red indicando que la detención se está produciendo
debido a un fallo de comunicación.
El subsistema gestor de configuración (nombre de
clase: GtrConfig) proporciona la interfaz de control entre el
anfitrión SCP y los componentes del servidor. Todas las operaciones
que pueden ser realizadas en la red del servidor están definidas en
esta interfaz. El subsistema de gestión de configuración implementa
las siguientes características:
- -
- Interfaz de mensajes de control entre el anfitrión y los servidores
- -
- Máquina de estado para operaciones válidas
- -
- Conduce la gestión de red con solicitudes
- -
- Controla la operación temporización/fin de tiempo
GtrConfig gestiona el control de configuración
del servidor para el gestor de la plataforma. GtrConfig recibe
mensajes de anfitrión transmitidos en los enlaces lógicos CTLCONFIG,
MAINT, CTLAPL y CTLENRUTAM y procesos basados cada uno en su id y
tipo de mensaje. Si el anfitrión requiere que se envíe una respuesta
o parte, GtrConfig determina la respuesta necesaria y recupera la
información de parte necesaria y la envía de vuelta al anfitrión.
GtrConfig maneja los siguientes mensajes:
- \bullet
- MSJ_ESTADO_APL
- \bullet
- MSJ_ASPEC
- \bullet
- MSJ_CONFIGURAR_SERVIDOR
- \bullet
- MSJ_INFO_GSP
- \bullet
- MSJ_ESTADO_GSP
- \bullet
- MSJ_PROCESAMIENTO_CONSULTA
- \bullet
- MSJ_REINICIAR_SERVIDOR
- \bullet
- MSJ_INFO_ENRUTAMIENTO
- \bullet
- MSJ_CTL_ACCION_PLAN
- \bullet
- MSJ_INFO_SERVIDOR
- \bullet
- MSJ_ESTADO_SERVIDOR
- \bullet
- MAJ_COMPROBAR_SERVIDOR
- \bullet
- MSJ_TIEMPO
GtrConfig proporciona también operaciones al
gestor de la plataforma para recuperar la información de servidor y
tiempo del anfitrión. Proporciona también operaciones para notificar
al anfitrión los cambios de estado del servidor. Al procesar los
mensajes de órdenes del anfitrión, hay veces en que GtrConfig debe
esperar una respuesta del anfitrión o un cambio de estado de un
servidor particular. GtrConfig usa una filosofía de no bloqueo con
respecto a estas esperas. En lugar de detenerse y esperar a que el
evento ocurra, GtrConfig salva la respuesta o estado deseado en una
ColaPendiente y continua el procesamiento normal de otro mensaje del
anfitrión o proporcionando servicio a un cliente. Cuando se produce
la respuesta o estado deseado, el procedimiento apropiado es llamado
para resumir el procesamiento del mensaje ordenado por el anfitrión.
Si la respuesta deseada no llega o no se produce el estado deseado
dentro del límite de tiempo especificado, es llamado un
procedimiento de fallo para limpiar el procesamiento del mensaje
ordenado por el anfitrión y emitir PIPs cuando se necesite.
Además de procesar los mensajes de comandos del
anfitrión, GtrConfig es requerido para notificar al anfitrión cuando
se produce un cambio de estado. Cuando a GtrConfig se le notifica un
cambio de estado, comprueba las colas pendientes de estado para
determinar si está esperando a que se produzca el cambio de estado.
Si es así, se realiza la operación éxito de cola pendiente. De otra
forma GtrConfig envía mensajes de estado del servidor al anfitrión.
Al procesar los mensajes de respuesta del anfitrión, GtrConfig
comprueba la cola pendiente de respuesta del anfitrión
(ColaPendAnfi) para determinar si está esperando respuesta. Si es
así es realizada la operación éxito de cola pendiente. En otro caso
GtrConfig descarta el mensaje de respuesta del anfitrión. Cuando un
nodo del gestor de plataforma es arrancado al estado
OS-MIN, audita a su compañero y determina el estado
del compañero. En el caso de que no esté presente ningún nodo del
gestor de la plataforma, el estado del compañero es ajustado
automáticamente a detenido. Auditorías similares se hacen en los
nodos del servidor del servicio (nodos distintos de GP) para
determinar su estado.
GtrConfig tiene una capacidad de registro en la
que un subsistema puede registrarse para proporcionar información de
enrutamiento para una aplicación particular. Cuando el anfitrión
requiere información de enrutamiento acerca de una aplicación,
GtrConfig hace una solicitud al subsistema registrado apropiado (si
existe) para proporcionar la información de enrutamiento.
Los mensajes Configurar Servidor
(MsjConfigServidor) requiere un procesamiento especial debido a la
naturaleza de los servicios que son realizados (es decir,
detenciones, bajadas de grado, restauraciones, y arranques). Puesto
que los mensajes del anfitrión son enviados a ambos servidores del
gestor de la plataforma, debe tenerse cuidado para asegurar que sólo
un nodo del gestor de la plataforma procesa la solicitud. Esto exige
comprobar el estado del servidor del nodo del gestor de la
plataforma y su compañero. Hay diferentes acciones a emprender
basadas en el estado del servidor de los nodos del gestor de la
plataforma y si la solicitud ConfigServidor es para un nodo del
gestor de la plataforma, su compañero o el servidor de servicio. Dos
máquinas de estado finitas (MEFCfgSvrGP y MEFCfgSvrSvr) gestionan
todas las acciones conducidas en estados diferentes.
MEFCfgSvrGP es la máquina de estado finito que
maneja las restauraciones, detenciones, resincronizaciones, bajadas
de grado y arranques para un servidor de la aplicación del gestor de
la plataforma. Esta máquina procesa una solicitud basada en si la
solicitud es para sí mismo o para su compañero, su propio estado, el
estado de su compañero, y el evento solicitado (detección, bajada de
grado, restauración, etc.) Los estados de servidor del gestor de la
plataforma comprobados son: Detenido (Auto), Detenido (Manual),
XOS-IN, AOS-MIN (Auto),
MOS-MIN (Manual), y En-Svc. Si
En-Svc, el estado activo/en espera es comprobado
para determinar si el servidor es activo o en espera. Eventos
válidos son Restaurar, Detención Controlada, Detención Inmediata,
Bajada de grado Controlada, Bajada de grado Inmediata, Arranque
controlado, Arranque inmediato, y resincronización del
anfitrión.
El evento es importante para determinar qué nodo
del gestor de la plataforma procesará la solicitud. Si se solicita
una restauración, normalmente el nodo del gestor de la plataforma
que está siendo restaurado procesará la restauración (es decir, un
nodo del gestor de la plataforma se restaurará a sí mismo). Al
procesar una solicitud de restauración de un servidor del gestor de
la plataforma que está detenido, el compañero del servidor detenido
(si puede) enviará una respuesta de denegación de vuelta al
anfitrión. Si es solicitada cualquier detención, bajada de grado o
arranque para un nodo del gestor de la plataforma, el compañero del
nodo del gestor de la plataforma lo procesará, a menos que el
compañero esté detenido. Cuando el compañero está detenido, el nodo
del gestor de la plataforma procesará la detención, bajada de grado,
o arranque por sí mismo. Procesar una detención, bajada de grado o
arranque puede implicar realizar realmente la acción requerida o
enviar una repuesta de denegación de vuelta al anfitrión. Si una
solicitud de detención, bajada de grado o arranque no es denegada,
el anfitrión considera la acción con éxito.
Cuando un nodo del gestor de la plataforma tiene
que procesar un arranque para sí mismo, el nodo del gestor de la
plataforma llama a las operaciones DetecciónControlada o
DetenciónInmediata (basadas en el tipo de arranque) de GPRed para
llevar a sí mismo a un estado detenido. El procesamiento está
entonces completo para este nodo puesto que está siendo rebajado a
un estado detenido. (El anfitrión iniciará el reinicio y arranque
del servidor.) Una bandera de forzar es comprobada cuando una
detención, bajada de grado o arranque es requerido por el último
nodo del gestor de la plataforma en servicio. Si la bandera de
forzar no es colocada, la solicitud será denegada con una respuesta
de "DENEGADA-ÚLTIMA AMP". Si la bandera de forzar es colocada,
la detención, bajada de grado o arranque será realizado en el último
nodo del gestor de la plataforma en servicio.
Si se requiere una resincronización del anfitrión
para un nodo del gestor de la plataforma, el compañero del servidor
del gestor de la plataforma objetivo procesará la solicitud a menos
que el compañero esté detenido. Si el compañero del servidor del
gestor de la plataforma objetivo está detenido, el nodo del gestor
de la plataforma para la resincronización procesará la solicitud.
Procesar la solicitud implica cambiar el estado del servidor de
XOS-MIN a AOS-MIN o
MOS-MIN o denegar la solicitud si el estado actual
no es XOS-MIN.
MEFCfgSvrSvr es la máquina de estado finito que
maneja las restauraciones, detenciones, resincronizaciones, bajadas
de grado y arranques para un servidor de la aplicación de servicio.
Esta máquina procesa una solicitud basada en el estado del nodo del
gestor de la plataforma que realiza la acción, el estado del
servidor de servicio en el que se está trabajando, y el evento
requerido (detención, bajada de grado, restauración, etc.) Los
estados de servicio comprobados son Detenido (auto), Detenido
(manual), XOS-MIN, AOS-MIN (auto),
MOS-MIN (manual) y EnSvc. Eventos válidos son
Restaurar, Detención controlada, Detención inmediata, Bajada de
grado controlada, Bajada de grado inmediata, Arranque controlado,
Arranque inmediato, y resincronización del anfitrión.
El nodo del gestor de la plataforma activo
(OS-MIN o EnSvc) procesará la solicitud de
configurar servidor para un servidor de servicio. Un arranque,
detención, resincronización o bajada de grado son permitidos en el
servidor de servicio mientras que un gestor de la plataforma esté al
menos OS-Min. Una restauración para el servidor de
servicio sólo se permite cuando al menos un gestor de la plataforma
esté en servicio. Si ningún nodo del gestor de la plataforma está en
servicio, el nodo del gestor de la plataforma que está activo
enviará una respuesta DENEGAR AMP no en servicio de vuelta al
anfitrión. Si una solicitud de detención, bajada de grado o arranque
no es denegada, el anfitrión considera la acción con éxito.
Una bandera de forzar es comprobada cuando una
detención, bajada de grado o arranque es requerida por el último
nodo en servicio de una aplicación. Si la bandera de forzar no está
colocada, la solicitud será denegada con una respuesta de "ÚLTIMO
SERVIDOR En grupo de servicio de procesador PROCESANDO CONSULTAS
DENEGADO". Si la bandera de forzar está colocada, la detención,
bajada de grado o arranque serán realizados en el último nodo en
servicio de la aplicación.
Una bandera Bajo Configuración es comprobada
siempre que es procesado un evento de configuración (excepto
detenciones inmediatas). Si está colocada la bandera Bajo
Configuración, la solicitud será denegada con una respuesta de
"SERVIDOR BAJO CONFIGURACIÓN DENEGADO". GtrConfig ajusta y
borra la bandera Bajo Configuración durante el procesamiento de
eventos. Los otros mensajes (es decir, MsjInfoServidor,
MsjEstadoServidor, MsjTiempo, etc.) no requieren máquinas de estado
finito.
Cuando una petición de restauración no es
denegada, GtrConfig ajusta la bandera BajoConfig para el servidor,
envía un MsjConfigServidor "Acción Iniciada" de RESPUESTA al
anfitrión, y llama a la operación RestaurarESV de GPRed para
restaurar al servidor a en servicio. GtrConfig suspende entonces el
procesamiento de restauración y ajusta una entrada de ColaPendiente
de estado de servidor para que el servidor pase a en servicio. El
procesamiento de restauración no continuará hasta que GtrConfig sea
informado de que el estado del servidor es en servicio o el
temporizador expire. Cuando GtrConfig es informado del cambio de
estado de servidor a en servicio, el procesamiento de restauración
es continuado comprobando el estado de consulta del servidor. Si el
estado de consulta del servidor es DESHABILITADO_SERVIDOR_OOS y el
número de servidores activos es menor que el recuento de servidores
activos del grupo de servicio del procesador, GtrConfig invoca la
operación HabilitarConsulta de GPRed para habilitar el estado de
consulta del servidor y ajusta el estado de consulta actual a
Pendiente. GtrConfig envía entonces mensajes de estado de servidor
al anfitrión informando acerca de cambio de estado del servidor y de
consulta. Una entrada de ColaPendiente de EstadoConsulta es ajustada
para que el estado de consulta del servidor se convierta en
Habilitado. El procesamiento es entonces suspendido hasta que el
estado de consulta se convierta en habilitado o el temporizador
expire. Cuando GtrConfig es informado del cambio de estado de
consulta a Habilitado, el procesamiento de restauración es
continuado con el envío de mensajes de estado del servidor y borrado
de la bandera bajo configuración para el servidor.
El procesamiento de fallos de restauración es
iniciado si el temporizador expira antes de que el estado de
servidor cambie a En Servicio o la información de servidor requerida
para las otras aplicaciones no es nunca recibida. El procesamiento
de fallos implica bajar de grado de forma controlada al servidor a
OS-MIN, emitir un PIP, y borrar la bandera bajo
configuración para el servidor. Si el temporizador expira antes de
que el estado de consulta cambie a Habilitado, el procesamiento de
restauración es continuado con el ajuste del Estado de Consulta a
Deshabilitado, bajada de grado controlada del servidor a
OS-MIN, envío de mensajes de estado del servidor,
emisión de un PIP, y borrado de la bandera bajo configuración para
el servidor.
Cuando una solicitud de Detención Controlada no
es denegada, GtrConfig ajusta la bandera BajoConfig para el
servidor, envía un MsjConfigServidor "Acción iniciada" de
RESPUESTA al anfitrión, y llama a la operación DetenciónControlada
de GPRed para detener el servidor. Si el nodo no está ya detenido,
GtrConfig suspende entonces el procesamiento de detención y ajusta
una entrada de Cola Pendiente de Estado de Servidor para que el
servidor se convierta en Detenido. Entonces hace una entrada al
parte de configuración de red indicando que una detención fue
solicitada por el anfitrión. El procesamiento de detención no
continuará hasta que el GtrConfig sea informado de que el estado de
servidor es Detenido o el temporizador expire. Cuando GtrConfig es
informado del cambio de estado de servidor a un estado detenido, el
procesamiento de detención es continuado con el envío de mensajes de
estado del servidor y borrado de la bandera bajo configuración para
el servidor. Si el temporizador expira antes de que el estado del
servidor cambie a Detenido, es iniciado el procesamiento de fallos
de detención. El procesamiento de fallos implica emitir un PIP y
borrar la bandera bajo configuración para el servidor.
Cuando una solicitud de Detención Inmediata no es
denegada, GtrConfig coloca la bandera BajoConfig para el servidor,
elimina todos los cambios de estado de servidor pendientes para este
servidor de la cola pendiente de estado y llama a la operación
DetenciónInmed de GPRed para detener el servidor. Si el nodo no está
ya detenido, GtrConfig suspende el procesamiento de detención y
ajusta una entrada de cola pendiente de estado de servidor para que
el servidor se convierta en Detenido. Luego hace una entrada al
parte de configuración de red indicando que una detención fue
requerida por el anfitrión. El procesamiento de detención no
continuará hasta que GtrConfig sea informado de que el estado de
servidor es Detenido o el temporizador expire. Cuando GtrConfig es
informado de que el estado de servidor cambia a un estado detenido
(o el nodo está ya detenido cuando se produjo la detención), el
procesamiento de detención es continuado con el envío de mensajes de
estado del servidor, envío de un MsjConfigServidor "Completado con
éxito" de RESPUESTA al anfitrión, y borrado de la bandera bajo
configuración para el servidor.
Si el temporizador expira antes de que el estado
de servidor cambie a Detenido, es iniciado el procesamiento de
fallos de detención. El procesamiento de fallos implica emitir un
PIP, enviar un MsjConfigServidor "Acción fallida" de RESPUESTA
al anfitrión y borrar la bandera bajo configuración para el
servidor.
Cuando una solicitud de Bajada de grado
Controlada no es denegada, GtrConfig ajusta la bandera BajoConfig
para el servidor, envía un MsjConfigServidor "Acción iniciada"
de Respuesta al anfitrión, y llama a la operación Bajada de grado
controlada de GPRed para bajar de grado al servidor. Si el nodo no
está ya en el estado de menor grado deseado, GtrConfig suspende
entonces el procesamiento de bajada de grado y ajusta una entrada de
ColaPendiente de Estado del Servidor para que el servidor se
convierta en OS-MIN. Luego hace una entrada al parte
de configuración de red indicando que fue solicitada una bajada de
grado por el anfitrión. El procesamiento de bajada de grado no
continuará hasta que GtrConfig sea informado de que el estado de
servidor es OS-MIN o el temporizador expire. Cuando
GtrConfig es informado del cambio de estado del servidor a un estado
OS-MIN (o el nodo ya estaba en dicho estado), el
procesamiento de bajada de grado es continuado con el envío de
mensajes de estado del servidor y borrado de la bandera bajo
configuración para el servidor. Si el temporizador expira antes de
que el estado de servidor cambie a un estado OS-Min,
es iniciado el procesamiento de fallos de bajada de grado. El
procesamiento de fallos implica emitir un PIP y borrar la bandera
bajo configuración para el servidor.
Cuando una petición de Bajada de grado Inmediata
no es denegada, GtrConfig coloca la bandera BajoConfig para el
servidor y llama a la operación Descensoinmediato de GPRed para
bajar de grado al servidor. Si el nodo no está ya en el estado de
menor grado deseado, GtrConfig suspende entonces el procesamiento de
bajada de grado y ajusta una entrada de Cola Pendiente de Estado de
Servidor para que el servidor se convierta en
OS-MIN. Luego hace una entrada al parte de
configuración de red indicando que una bajada de grado fue
solicitada por el anfitrión. El procesamiento de bajada de grado no
continuará hasta que GtrConfig sea informado de que el estado del
servidor es OS-MIN o el temporizador expire. Cuando
GtrConfig es informado del cambio de estado de servidor a un estado
OS-MIN (o el nodo ya estaba en dicho estado), el
procesamiento de bajada de grado es continuado con el envío de
mensajes de estado del servidor, envío de un MsjConfigServidor
"Completado con Éxito" de RESPUESTA al anfitrión, y borrado de
la bandera bajo configuración para el servidor.
Si el temporizador expira antes de que el estado
de servidor cambie a un estado OS-MIN, el
procesamiento de errores de bajada de grado es iniciado. El
procesamiento de fallos implica emitir un PIP, enviar un
MsjConfigServidor "Acción fallida" de RESPUESTA al anfitrión y
borrado de la bandera bajo configuración para el servidor.
Cuando una petición de Arranque Controlado o
Inmediato no es denegada, GtrConfig coloca la bandera BajoConfig
para el servidor y envía un MsjConfigServidor "Acción Iniciada"
de RESPUESTA al anfitrión. GtrConfig comprueba el estado del
servidor para el servidor y llama a la operación DetenciónControlada
o DetenciónInmed de GPRed si el servidor no está en un estado
detenido. Si es llamada una operación detención, el procesamiento es
suspendido hasta que GtrConfig sea informado de que el estado de
servidor es detenido o el temporizador expira. Luego hace una
entrada al parte de configuración de red indicando que fue
solicitado un arranque por el anfitrión.
Cuando GtrConfig es informado del cambio de
estado del servidor a un estado OS_MIN (o el nodo estaba ya en dicho
estado), el proceso de bajada de grado es continuado con el envío de
mensajes de estado del servidor, envío de un MsjConfigServidor
"Completado con éxito" de RESPUESTA al anfitrión, y borrado de
la bandera bajo configuración para el servidor. Si el temporizador
expira antes de que el estado del servidor cambie a un estado
OS-MIN, el procesamiento de fallos de bajada de
grado es iniciado. El procesamiento de fallos implica emitir un PIP,
enviar un MsjConfigServidor "Acción fallida" de RESPUESTA al
anfitrión, y el borrado de la bandera bajo configuración para el
servidor.
Cuando una solicitud de Arranque Controlado o
Inmediato no es denegada, GtrConfig coloca la bandera BajoConfig
para el servidor y envía un MsjConfigServidor "Acción Iniciada"
de RESPUESTA al anfitrión. GtrConfig comprueba el estado de servidor
para el servidor y llama a la operación DetenciónControlada o
DetenciónInmed de GPRed si el servidor no está en un estado
detenido. Si es llamada una operación de detención, el procesamiento
es suspendido hasta que GtrConfig sea informado de que el estado del
servidor es detenido o el temporizador expira. Luego hace una
entrada al parte de configuración de red indicando que un arranque
fue solicitado por el anfitrión.
Cuando GtrConfig ha determinado que el servidor
está detenido, envía un MsjReiniciarServidor de SOLICITUD al
anfitrión. GtrConfig crea una entrada de ColaPendiente de Respuesta
al anfitrión para esperar el MsjReiniciarServidor de RESPUESTA desde
el anfitrión. El procesamiento es entonces suspendido hasta que la
RESPUESTA sea recibida o el temporizador expire. Una vez que la
RESPUESTA es recibida GtrConfig ajusta una entrada de Cola Pendiente
del Estado del Servidor para esperar que el estado del servidor se
convierta en OS-MIN. Si la RESPUESTA desde el
anfitrión no es recibida antes de que el temporizador expire, es
emitido un PIP y la bandera bajo configuración es borrada. Una vez
que el estado del servidor se convierte en OS-MIN,
GtrConfig envía mensajes de estado de servidor al anfitrión
indicando el nuevo estado de servidor y borra la bandera bajo
configuración. Si el temporizador expira antes de que el estado del
servidor se convierta en OS-MIN, GtrConfig emite un
PIP y borra la bandera bajo configuración.
Cuando una solicitud de Resincronización del
anfitrión no es denegada, GtrConfig determina si el estado del
servidor es XOX_MIN. Si es así, la operación AjustarEstadoServidor
de GPRed es llamada para ajustar el estado del servidor al estado
OS_MIN Auto/Manual apropiado, los mensajes de estado del servidor
son enviados para indicar el nuevo estado del servidor, y un
MsjConfigServidor "Con éxito" de RESPUESTA es enviado al
anfitrión. Si el estado del servidor no es XOX_MIN, es emitido un
PIP y un MsjConfigServidor "Acción Fallida" de RESPUESTA es
enviado al anfitrión.
El mensaje de Estado de la Aplicación es
procesado por el nodo del gestor de la plataforma que está En
Servicio Activo. Si ningún nodo del gestor de la plataforma está En
Servicio, el nodo del gestor de la plataforma que está
OS-MIN Activo procesará la solicitud. Al recibir
mensajes MsjEstadoAplic de tipo SOLICITUD desde el anfitrión,
GtrConfig determina el estado de consulta de la aplicación y envía
un MsjEstadoAplic S_PARTE de vuelta al anfitrión con el estado de
consulta de la aplicación actual. GtrConfig envía mensajes
MsjEstadoAplic de tipo U_PARTE al anfitrión cuando se produce el
cambio del estado del servidor o según se requiera durante el
procesamiento de una solicitud de configurar servidor del
anfitrión.
GtrConfig recibe un mensaje SOLICITUD de Datos
ASPECT desde el anfitrión para cada Aplicación en el archivo de
descriptor InfoAplic.des. GtrConfig consulta a GPRed la recuperación
de la información para dicha aplicación desde MapRed. Un mensaje de
respuesta que contiene los datos ASPEC es enviado de vuelta al
anfitrión junto con un código de respuesta que indica éxito o
fracaso. Los PIPs serán emitidos si existe un Id de Aplicación
inválido, un mensaje distinto de un mensaje SOLICITUD de Datos
ASPEC, o un mensaje de un tipo que no sea solicitud.
Un mensaje Info del grupo de servicio del
Procesador es procesado por el nodo del gestor de la plataforma que
está En Servicio Activo. Si ningún nodo del gestor de la plataforma
está En Servicio, el nodo del gestor de la plataforma que está
OS-MIN Activo procesará la solicitud.
Al recibir mensajes MsjInfoGSP de tipo SOLICITUD
desde el anfitrión, GtrConfig determina la Info del grupo de
servicio del Procesador y envía un MsjInfoGSP S_PARTE de vuelta al
anfitrión con la información del grupo de servicio del
procesador.
El mensaje de estado del grupo de servicio del
procesador es procesado por el nodo del gestor de la plataforma que
está En Servicio Activo. Si ningún nodo del gestor de la plataforma
está En Servicio, el nodo del gestor de la plataforma que esté
OS-MIN Activo procesará la solicitud. Al recibir
mensajes MsjEstadoGSP de tipo SOLICITUD desde el anfitrión,
GtrConfig determina el estado de consulta del grupo de servicio del
procesador y envía un MsjEstadoGSP S_PARTE de vuelta al anfitrión
con el estado de consulta del grupo de servicio del procesador
actual. GtrConfig envía mensajes de tipo MsjEstadoGSP U_PARTE al
anfitrión cuando se producen cambios de estado del servidor o según
se requiera durante el procesamiento de una solicitud de configurar
el servidor desde el anfitrión.
El mensaje Procesar Consulta es procesado por el
nodo del gestor de la plataforma que está En Servicio Activo. Si
ningún nodo del gestor de la plataforma está En Servicio, el nodo
del gestor de la plataforma que está OS-MIN Activo
procesará la solicitud. GtrConfig recibe MsjProcConsulta de tipo
solicitud DESHABILITAR_SERVIDOR, DESHABILITAR_SERVIDOR_FORZADO y
HABILITAR_SERVIDOR desde el anfitrión. Al procesar este mensaje,
GtrConfig inicia la habilitación/deshabilitación del procesamiento
de consulta para el servidor objetivo llamando a la operación
HabilitarServidor/DeshabilitarServidor desde GPRed. GtrConfig
ajustará una entrada de ColaPendiente de Estado de Consulta para el
servidor y suspenderá la continuación del procesamiento hasta que el
estado de consulta para el servidor cambie al estado deseado o el
temporizador expire. GPRed informa a GtrConfig de un cambio en el
estado de consulta llamando a la operación CambioEstCnstRed de
GtrConfig. Cuando GtrConfig procese esta operación, comprobará las
entradas de Cola Pendiente de Estado de consulta para el estado de
consulta del servidor. Si hay una entrada con el estado de consulta
deseado, el procedimiento de procesamiento de consulta de éxito
apropiado es llamado para resumir el procesamiento del
MsjProcConsulta. El procesamiento de éxito para el MsjProcConsulta
implica el envío de un MsjProcConsulta de RESPUESTA de vuelta al
anfitrión indicando que la solicitud tuvo éxito y cambio del estado
activo si es necesario para un nodo del gestor de la plataforma.
Si el temporizador expira antes de que el estado
de consulta del servidor sea el estado deseado, el procedimiento de
consulta de fallos apropiado es llamado para resumir el
procesamiento del MsjProcConsulta. El procesamiento de fallos para
el MsjProcConsulta implica emitir un PIP y enviar un MsjProcConsulta
de RESPUESTA de vuelta al anfitrión indicando la solicitud
fallida.
El GtrConfig envía mensajes MsjReiniciarServidor
de tipo SOLICITUD durante el procesamiento de arranque de un
servidor. Cuando el anfitrión requiere un arranque para un servidor
no del GP, el MsjReiniciarServidor de SOLICITUD es enviado después
de que el servidor objetivo ha sido detenido. GtrConfig suspende
entonces el procesamiento de arranque y ajusta una entrada de Cola
Pendiente de Respuesta del anfitrión para un mensaje
MsjReiniciarServidor de tipo RESPUESTA. El procesamiento de arranque
no continuará hasta que la RESPUESTA sea recibida o el temporizador
expire. Cuando GtrConfig recibe el mensaje MsjReiniciarServidor de
tipo RESPUESTA desde el anfitrión, GtrConfig comprobará si hay una
entrada para el MsjReiniciarServidor de RESPUESTA en la entrada de
Cola Pendiente de Respuesta del anfitrión para un
MsjReiniciarServidor en la Cola Pendiente de respuesta del
anfitrión. Si es así, el procedimiento apropiado será llamado para
completar el procesamiento de arranque.
El mensaje de Información de enrutamiento es
procesado por el nodo del gestor de la plataforma que está En
Servicio Activo. Si ningún nodo del gestor de la plataforma está En
Servicio, el mensaje será descartado. Al recibir mensajes
MsjInfoEnrutamiento de tipo SOLICITUD desde el anfitrión, GtrConfig
envía un MsjInfoEnrutamiento de RESPUESTA de vuelta al anfitrión
indicando que la solicitud fue confirmada e intenta recuperar la
Información de Enrutamiento. Una vez que la Información de
Enrutamiento es recuperada, GtrConfig envía un MsjInfoEnrutamiento
S_PARTE de vuelta al anfitrión con la información de enrutamiento.
GtrConfig envía mensajes MsjInfoEnrutamiento de tipo U_PARTE al
anfitrión al ser solicitada por otro subsistema para enviar
información de enrutamiento. Al recibir una solicitud para enviar
información de enrutamiento desde otro subsistema, GtrConfig
comprueba la cola pendiente de enrutamiento para determinar si el
anfitrión solicitó la información. Si es así, GtrConfig envía un
MsjInfoEnrutamiento S_PARTE al anfitrión con la información de
enrutamiento. En otro caso, GtrConfig envía un MsjInfoEnrutamiento
U_PARTE al anfitrión con la información de enrutamiento. Después de
que GtrConfig envía un U_PARTEal anfitrión, GtrConfig espera a que
el anfitrión confirme haber recibido los datos enviando un
MsjInfoEnrutamiento de RESPUESTA ACUSE DE RECIBO. Si no es recibida
respuesta por GtrConfig dentro del límite de tiempo, GtrConfig
requiere al subsistema apropiado que envíe la información de
enrutamiento de la aplicación de nuevo (para provocar un reenvío de
los datos al anfitrión). Si es recibida una respuesta Confirmación
Negativa desde el anfitrión, GtrConfig emite un PIP indicando un
código de respuesta fallido desde el anfitrión.
El mensaje de Control de Acción Planificada es
procesado por el nodo del gestor de la plataforma que está en
servicio activo. Si ningún nodo del gestor de la plataforma está en
servicio, el nodo del gestor de la plataforma que está
OS-MIN Activo procesará la solicitud. Cuando sean
recibidos mensajes MsjCtlAccPlan de tipo AJUSTAR desde el anfitrión,
GtrConfig llama a la operación AjustarAcciónPlan de GPRed para
habilitar/deshabilitar las acciones planificadas(tal como la
monitorización constante y auditorias genéricas) según se desee.
GtrConfig envía mensajes MsjCtlAccPlan de tipo RESPUESTA de vuelta
al anfitrión para indicar si el Ajuste tuvo éxito o no. GtrConfig
tiene una operación ObtenerAccionesPlanif que puede ser usada por un
cliente para obtener la información de tiempo del anfitrión. Cuando
esta operación es invocada, GtrConfig envía un mensaje MsjCtlAccPlan
de tipo SOLICITUD al anfitrión. GtrConfig ajusta entonces una
entrada de Cola Pendiente de Respuesta de anfitrión para el
MsjCtlAccPlan S_PARTE desde el anfitrión. El procesamiento (de
ObtenerAccionesPlanif) es entonces suspendido hasta que S_PARTE sea
recibido o el temporizador expire. No se lleva a cabo ninguna acción
si el temporizador expira antes de recibir las acciones
planificadas. Cuando GtrConfig recibe el mensaje MsjCtlAccPlan de
tipo S_PARTE desde el anfitrión, GtrConfig comprobará si hay una
entrada para el MsjCtlAccPlan S_PARTE en la Cola Pendiente de
Respuesta del anfitrión. Si es así, GtrConfig llama a la operación
AjustarAcciónPlan de GPRed para habilitar/deshabilitar las acciones
planificadas cuando sea deseado.
El mensaje de Información de Servidor es
procesado por el nodo del gestor de la plataforma que esté En
Servicio. Si ningún nodo del gestor de la plataforma está en
servicio, el nodo del gestor de la plataforma que esté OS_MIN Activo
procesará la solicitud. GtrConfig envía mensajes MsjInfoServidor de
tipo SOLICITUD y SOLICITUD DE TODO al anfitrión durante el
procesamiento de inicialización y procesamiento de restauración de
un servidor del gestor de la plataforma. Después de que el mensaje
es enviado, GtrConfig suspende el procesamiento de la tarea y ajusta
una entrada de Cola Pendiente de Respuesta al anfitrión para un
MsjInfoServidor de tipo de S_PARTE (y/o tipo COMPLETAR si es usado
SOLICITUD DE TODO). El procesamiento de inicialización y
restauración no es continuado hasta que la información del servidor
requerida sea obtenida o el temporizador expire. Si el temporizador
expira (antes de que la información sea obtenida) durante la
inicialización, GtrConfig envía un MsjInfoServidor de SOLICITUD o
SOLICITUD DE TODO de nuevo hasta que esta información sea obtenida.
Si el temporizador expira (antes de que sea obtenida la información)
durante la restauración de un servidor del gestor de la plataforma
GtrConfig emite un PIP de que la restauración falló.
Cuando los mensajes MsjInfoServidor S_PARTE y
COMPLETAR son recibidos desde el anfitrión, GtrConfig chequea si hay
una entrada para el MsjInfoServidor S_PARTE ó COMPLETAR en la Cola
Pendiente de Respuesta al anfitrión. Si es así, el procedimiento
apropiado será llamado para completar el procesamiento de
inicialización o restauración. Cuando mensajes MsjInfoServidor de
tipo CAMBIO son recibidos desde el anfitrión, GtrConfig determina si
está en un estado apropiado para procesar una información de
servidor de CAMBIO. Si es así, GtrConfig informa a GPRed de la
información de servidor cambiada y envía un MsjInfoServidor de tipo
RESPUESTA de vuelta al anfitrión para indicar si la información de
servidor fue cambiada con éxito o no.
El mensaje de estado del servidor es procesado
por el nodo del gestor de la plataforma que está En Servicio Activo.
Si ningún nodo del gestor de la plataforma está En Servicio, el nodo
del gestor de la plataforma que está OS-MIN activo
procesará la solicitud. Al recibir mensajes MsjEstadoServidor de
tipo SOLICITUD desde el anfitrión, GtrConfig obtiene información de
estado del servidor y consulta y envía un MsjEstadoServidor S_PARTE
de vuelta al anfitrión con la información de estado actual.
GtrConfig envía mensajes MsjEstadoServidor de tipo U_PARTE al
anfitrión cuando se producen cambios de estado del servidor o según
se requieran durante el procesamiento de una solicitud de configurar
servidor del anfitrión.
El mensaje Comprobar Servidor es procesado por el
nodo del gestor de la plataforma que está En servicio activo. Si
ninguno de los nodos del gestor de la plataforma está En servicio,
el nodo del gestor de la plataforma que está OS-MIN
Activo procesará la solicitud. Si el servidor objetivo es uno mismo
y su gestor de la plataforma compañero no está detenido, este nodo
del gestor de la plataforma descartará la solicitud mientras que el
otro gestor de la plataforma procesa el mensaje. Al recibir un
mensaje MsjComprobarServidor de tipo SOLIICITUD O CANCELACIÓN desde
el anfitrión o el enlace lógico MAINT, GtrConfig determina si el
estado del servidor objetivo es MOS_MIN. Si es así, GtrConfig envía
un MsjComprobarServidor de RESPUESTA de Confirmación de vuelta al
anfitrión. En el futuro, GtrConfig iniciará o cancelará la
comprobación apropiada en base a si es recibida una SOLICITUD O
CANCELACION. Si el servidor objetivo no está MOS_MIN GtrConfig envía
un MsjComprobarServidor no de Servidor No MOS_MIN de Respuesta de
vuelta al anfitrión. Si el estado del servidor objetivo no puede ser
obtenido, GtrConfig envía un MsjComprobarServidor RESPUESTA denegada
de vuelta al anfitrión y emite un PIP apropiado.
El Mensaje de Tiempo es procesado por el nodo del
gestor de la plataforma que está En Servicio Activo. Si ningún nodo
del gestor de la plataforma está En Servicio, el nodo del gestor de
la plataforma que esté OS-MIN Activo procesará la
solicitud. Al recibir mensajes MsjTiempo de tipo AJUSTAR desde el
anfitrión, GtrConfig llama a la operación AjustarTiempo de GPRed
para ajustar el tiempo de red del servidor al tiempo apropiado y
envía un MsjTiempo de RESPUESTA de vuelta al anfitrión para indicar
si el Ajuste tuvo éxito o no. GtrConfig tiene una operación
ObtenerTiempo que puede ser usada por un cliente para obtener la
información de tiempo del anfitrión. Cuando esta operación es
invocada, GtrConfig envía un mensaje MsjTiempo de tipo SOLICITUD al
anfitrión. GtrConfig ajusta entonces una entrada de Cola pendiente
de Respuesta del anfitrión para el MsjTiempo S_PARTE desde el
anfitrión, El procesamiento es entonces suspendido hasta que S_PARTE
sea recibido o el temporizador expire. No se lleva a cabo ninguna
acción si el temporizador expira antes de recibir la información de
temporizador. Al recibir un mensaje MsjTiempo de tipo S_PARTE desde
el anfitrión, GtrConfig comprobará si existe una entrada para
MsjTiempo de RESPUESTA en la Cola Pendiente de Respuesta del
anfitrión. Si es así, la operación AjustarTiempo de GPRed es llamada
para ajustar el tiempo de red del servidor.
El subsistema de Gestión de Nodos proporciona
gestión de procesos dentro de un nodo de servidor único. Es
responsable de iniciar/detener procesos dentro del nodo de servidor
para mantener niveles de ejecución específicos. Los niveles de
ejecución soportados por la Gestión de Nodos son
- -
- DETENIDO (No hay software en ejecución - ni siquiera el SO)
- -
- MIN-SET (SO + Software de la plataforma mínimo requerido)
- -
- Elemento Configurable En SERVICIO (MIN-SET + software común)
Gestión de Red informa a Gestión de Nodos del
nivel de ejecución deseado para un nodo específico. En caso de un
fallo de proceso, Gestión de Nodos evalúa el fallo y determina qué
acción de recuperación es necesaria si es que hay alguna. Las
acciones de recuperación incluyen: ignorar el fallo, autoiniciar el
nodo al nivel de ejecución inmediatamente inferior y volver al nivel
de ejecución actual, y cerrar el sistema.
GPNodo será creado como parte del procedimiento
de arranque del sistema para cada nodo de servidor. Como parte de su
inicialización, GPNodo:
- \bullet
- Instancia el objeto MapNodo, y después de obtener la información de configuración sobre el mínimo de elementos configurables que tienen que ser configurados en cada servidor, lleva al nodo del servidor a un estado operacional minimal (OS-MIN). Desde este estado al nodo del servidor se le permite sólo un conjunto mínimo de funcionalidad tal como crear el resto de los procesos. Los datos de configuración proporcionados en cada MapNodo del nodo determinan las capacidades de cada nodo de servidor (nodos de servidor con capacidades de gestor de plataforma frente a nodos con capacidades de procesamiento de consultas).
- \bullet
- Crea el objeto servidor de GPNodo para manejar las solicitudes de GPRed para realizar operaciones dentro del mismo nodo de servidor.
Por la solicitud de GPRed, GPNodo (a través de
las operaciones proporcionadas por su objeto servidor) puede
realizar las siguientes operaciones:
- \bullet
- Subir su nodo de servidor a un estado de operación completa (elemento configurable En Servicio) desde un estado operacional mínimo (OS-MIN) (operación RestaurarNodo)
- \bullet
- Bajar su nodo de servidor a un estado operacional minimal (OS-MIN) o detenido (DETENCIÓN) desde un estado operacional completo (elemento configurable En Servicio) (operación EliminarNodo)
- \bullet
- Habilitar/deshabilitar el procesamiento de consultas en su nodo de servidor
- \bullet
- Proporcionar información de estado en los elementos configurables
GPNodo informa de cualquier cambio de estado en
cada IPU autónomamente a GPRed (GPNodo utiliza la operación
proporcionada por GPRed para informar del cambio de estado)
La Fig. 8 es un diagrama que muestra las
transiciones de estado de servicio legal para un nodo. Se advierte
que todos los estados automáticos hacen transición a otros estados
automáticos y todos los estados manuales hacen transición a otros
estados manuales. No hay transición legal desde un estado manual a
un estado automático. El estado ESV no tiene una designación
automática o manual en este momento. Los estados pueden hacer
transición desde/a el estado EN SERVICIO (ESV) 200 a/desde cualquier
otro estado. Los acrónimos usados en la Fig. 8 son decodificados
como sigue:
\newpage
| ESV | 200 | En servicio |
| OOSAM | 202 | Minimal fuera de servicio automático |
| OOSMM | 204 | Minimal fuera de servicio manual |
| OOSAN | 206 | Detenido fuera de servicio automático |
| OOSMN | 208 | Detenido fuera de servicio manual |
| ARRAN-A | 210 | Arranque automático |
| ARRAN-M | 212 | Arranque manual |
| BAJ-A | 214 | Bajada de grado automática |
| BAJ-M | 216 | Bajada de grado manual |
| DETEN-A | 218 | Detención automática |
| DETEN-M | 220 | Detención manual |
| REST-A | 222 | Restauración automática |
| REST-M | 224 | Restauración manual |
El subsistema de Integridad del Sistema de Nodos
(nombre de clase ISNodo) proporciona servicios de aislamiento de
errores y monitorización dentro de un nodo de servidor único. Todos
los fallos de proceso son registrados por este subsistema y
remitidos a Gestión de nodos para la acción de recuperación. La
integridad del sistema de nodos implementa las siguientes
características:
- -
- Monitorización de procesos pasivos (captura de señal)
- -
- Monitorización de comunicaciones entre nodos
- -
- Informe de fallos locales
Las capacidades de la Integridad del Sistema (IS)
de la plataforma AIN pueden ser clasificadas en aquellas que
proporcionan capacidades a través de los nodos del servidor de la
plataforma, y aquellas que proporcionan capacidades dentro un nodo
de servidor único. Mientras que ISRed maneja las capacidades de
integridad del sistema en el nivel de la plataforma, ISNodo
proporciona integridad del sistema en el nivel de nodo único. ISNodo
reside en cualquier nodo de servidor de la plataforma, y proporciona
operaciones a través de las cuales los procesos para cada elemento
configurable puede informar de condiciones de fallo en tal proceso.
Estos fallos incluyen:
- \bullet
- Fallos detectados por el objeto Monitorización constante en cada proceso.
- \bullet
- Fallos de comunicación entre nodos.
- \bullet
- Fallos de comunicación entre el anfitrión y la red de servidores.
- \bullet
- Fallos detectados por el proceso de Servidor GI.
Realiza también monitorización constante de nodos
de todas las conexiones a/desde el nodo. Si es detectado un fallo de
comunicación, ISNodo informará a ISRed del fallo de comunicación.
Dependiendo del fallo informado, ISNodo emprenderá acciones
apropiadas que incluyen emitir PIPs, y bajar el grado del estado de
nodo (en cooperación con el GPNodo).
ISNodo monitoriza la utilización del disco en
cada nodo de servidor, las emisiones de PIP apropiados cuando la
capacidad total usada en un sistema de archivo particular excede de
un cierto umbral. La comunicación de ISNodo con otros objetos es
manejada vía la interfaz DOME. ISNodo obtiene la lista de toda las
IPUs en la configuración desde GPNodo. Una matriz es ajustada
conteniendo la siguiente información desde cada IPU:
- \bullet
- Información IPU recibida desde GPNodo
- \bullet
- Estado IPU
- \bullet
- Recuento de errores
- \bullet
- Indicador de mensajes de actividad recibidos
Se usa un índice de matriz dentro de esta lista
para comunicar estado con el otro ISNodo en lugar del nombre del
nodo puesto que las comparaciones entre cadenas pueden ser costosas
en términos de la velocidad y la eficacia. Por tanto, es importante
que cada nodo en la configuración tenga la misma lista IPU en el
mismo orden.
ISNodo registra con GPNodo para obtener
notificaciones de estado de nodo. Cuando ISNodo es informado de un
cambio de estado por otra IPU, actualizará el estado IPU y la matriz
IPU. Si el cambio de estado es a un estado detenido, ISNodo borrará
los recuentos de fallos y el indicador de mensajes de actividad
recibidos.
ISNodo tiene dos temporizadores para manejar su
función de monitorización constante:
- \bullet
- Temporizador de difusión - temporizador que hace que ISNodo difunda mensajes de actividad a los otros ISNodos en su vista.
- \bullet
- TemporizadorComMonCon - temporizador que hace que ISNodo determine si los mensajes de actividad apropiados han sido recibidos para todas las conexiones dentro del intervalo de tiempo.
Cuando ISNodo es informado de que este nodo está
OS-MIN, empieza la difusión de los mensajes de
actividad a los otros ISNodos en su vista. Luego activa el
TemporizadorDifusión. Al expirar el TemporizadorDifusión, ISNodo
redifunde inmediatamente los mensajes de actividad y reactiva el
TemporizadorDifusión. Esto interrumpirá cualquier procesamiento de
ISNODO que pueda está en progreso.
Cuando ISNodo recibe un mensaje de actividad
desde otro ISNodo, marca el indicador de mensaje de actividad
recibido de la entrada de matriz IPU apropiada.
Cuando ISNodo es informado de que este nodo está
OS-MIN, activa el temporizadorComMonCon. Al expirar
el temporizadorComMonCon, ISNodo hace una llamada Dome a la
operación ComprobarFalloComun para realizar comprobación de fallos
de comunicación y reactivar el temporizador. Está usando la llamada
DOME para sí mismo para asegurar que se da prioridad a la difusión
de mensajes de actividad.
El procesamiento de fallos de comunicación
implica comprobar cada IPU en su matriz para determinar si un
mensaje de actividad ha sido recibido desde la última vez que fue
comprobado. Si es así, el indicador de mensajes de actividad
recibidos es borrado. Si no ha sido recibido ningún mensaje y el
estado IPU no es detenido, el recuento de fallos para dicho nodo
será incrementado. Si el número de fallos para dicha IPU está en su
máximo, ISNodo informa de un fallo de comunicación a ISRed.
El número máximo del recuento de fallos es un
valor configurable que puede ser leído desde la línea de comandos
usando la clave "MAX_FALLOS_COM". Si no se da ningún valor, el
número por defecto del recuento de fallos será 2. También, si el
valor dado en la línea de comandos es menor que 2, el número máximo
será ajustado a 2.
El número de segundos entre cada difusión de
mensajes de actividad es un valor configurable que puede ser leído
desde la línea de comandos usando la palabra clave
"DIFUS_SEG_ACTIV". Si no se da ningún valor, el número por
defecto de segundos entre difusiones será de 1 segundo. Si el valor
dado en la línea de comandos es menor de 1 segundo, el número de
segundos será ajustado a 1.
El número de segundos entre cada comprobación de
monitorización constante es un valor configurable que puede ser
leído desde la línea de comandos usando la clave
"COMPROB_SEG_MONCON". Si no se da ningún valor, el número de
segundos por defecto entre comprobaciones será de 2 segundos. Si el
valor dado en la línea de comandos es menor de 2 segundos, el número
de segundos será ajustado a 2.
ISNodo es iniciado por GPNodo como parte de cada
arranque de nodo, y antes de otros procesos de arranque. Como parte
de su inicialización, ISNodo lee un archivo de descriptor
(Fallo.des) que contiene la definición de los fallos detectados por
ISNodo y crea una lista (ListInfoFallo) de aquellas grabaciones de
fallos. Cada grabación de fallo (InfoFallo) contiene las siguientes
partes:
- \bullet
- IdFallo - Identificación de fallo.
- \bullet
- IdAccFallo - Acción a ser emprendida por el fallo notificado.
Cuando los fallos son recibidos, ISNodo
investigará la grabación de fallo en su lista (ListaInfoFallo)
usando el Id del fallo y realizará la acción asociada al fallo.
Estas acciones pueden incluir:
- \bullet
- Emitir PIPs apropiados
- \bullet
- Detener el nodo en caso de detectar fallos catastróficos en el proceso de GPNodo.
- \bullet
- Informar de cambios de estado autónomos en elementos configurables a GPNodo.
- \bullet
- Informar de fallos de comunicación a GPNodo y a su vez a ISRed.
Todos los fallos (originados desde Monitor
constante u otros procesos) serán notificados a ISNodo por cada
proceso vía la operación NotificarFallos() de ISNodo. ISNodo
mantiene la pista de la utilización del disco en el nodo de servidor
y emite un PIP si fue usado 80.
ISNodo usa la interfaz proporcionada por GPNodo
para informar de los cambios autónomos en el estado de un elemento
configurable (CambioEstECAuto(..)). Dependiendo del impacto del
elemento configurable en el estado del nodo, el cambio de estado
puede hacer que GPNodo realice cualquiera de las siguientes
acciones:
- \bullet
- Bajar de grado el estado del nodo - Esta acción es realizada si el cambio de estado del elemento configurable tenía un impacto importante en el estado operacional actual del nodo. Antes de hacer esto, GPNodo informará a ISRed de su intención e inicia un temporizador. Luego por solicitud de GPRed o fin de tiempo, bajará de grado el estado del nodo.
- \bullet
- Informar de fallos de comunicación- Esta acción es realizada si el cambio de estado del elemento configurable indicaba un fallo de comunicación entre nodos (el enlace TCP va fuera de servicio). Para esta situación, GPNodo notificará a ISRed el fallo de comunicación e intenta establecer la comunicación de nuevo.
ISRed proporciona operaciones, usadas por ISNodo
y/o GPNodo para informar de las siguientes condiciones:
- \bullet
- Cambios autónomos en un estado de IPU (Bajar de gradoEstIP)(...)) - En esta situación, ISRed baja de grado al nodo a través de GPRed (solicita a GPRed bajar el grado si el nodo no estaba detenido ya).
- \bullet
- Fallos de comunicación (PartFalloComun(...)) - En esta situación, si un fallo de comunicaciones a la misma IPU fue comunicado por otras IPUs, entonces ISRed marcará dicha IPU como la IPU con fallo e intentará bajarla de grado a través de GPRed.
Cada proceso de elemento Configurable es
requerido para instanciar el objeto Monitor Constante para detectar
e informar de condiciones/eventos anormales que generan señales
diferentes en el proceso. Monitor constante informa de estas
condiciones vía la operación NotificarFallo() de ISNodo. En caso de
fracaso para comunicar el fallo a ISNodo, Monitor Constante puede
DETENER el nodo, dependiendo de las opciones ajustadas en el momento
de su instanciación.
Los procesos de elemento configurable manejador
de mensajes o enlaces lógicos utilizan la operación de ISNodo
NotificarFallo(), para informar de fallos de enlaces DNI/TCP
El subsistema gestión de servicio proporciona
control de proceso para procesos de la aplicación. Los procesos de
la aplicación son ejecutados sólo después de que el nodo ha
conseguido el nivel de ejecución EN SERVICIO. Los procesos de la
aplicación pueden individualmente ser eliminados/restaurados y
habilitados/deshabilitados en un nodo de servidor. Gestión de red
informa a gestión de servicio sobre qué aplicaciones eliminar,
restaurar, habilitar, deshabilitar. Las características
implementadas por gestión de servicio incluyen:
- -
- Monitorización de proceso activo (latidos, auditorías)
- -
- Soporte de instancias múltiples de proceso
- -
- Gestión de estado de los procesos de la aplicación
- -
- Estado administrativo
- -
- Estado operacional
- -
- Estado de uso
- -
- Notificación de cambio de estado de procesos de la aplicación
Para que la característica de navegador de la
plataforma de telecomunicaciones presente una interfaz de elemento
configurable consistente se ha hecho un cambio para tener gestión de
servicio para el inicio de elementos configurables del sistema en
lugar de GPNodo. Al hacer esto, todos los procesos en el sistema
(excepto gestión de servicio) son iniciados por gestión de servicio,
así las características de un elemento configurable son ahora del
mismo ancho del sistema. Para crear una IGU de Navegador de la
plataforma de telecomunicaciones, tiene que existir una vista
consistente de un sistema de la plataforma de telecomunicaciones. La
Fig. 9A es un diagrama que muestra la nueva relación que existe
durante la inicialización de nodos entre entidades en la plataforma
de telecomunicaciones. Para que un elemento configurable pueda
aprovechar toda la funcionalidad de gestión de servicio, la interfaz
de gestión de servicio necesita ser seguida.
- \bullet
- Un guión de arranque 230 es creado para ser lo primero que se ejecute en todos los nodos. Cuando el programa de arranque 230 se ejecute identificará el nodo 232 de gestor de la plataforma y copiará el archivo 234 de descriptor Tcl del nodo del gestor de la plataforma para usarlo para seleccionar dicho nodo. Si se determina que es el primer nodo de gestor de la plataforma en presentarse, usará el archivo 234 de descriptor Tcl existente para ejecutarse.
- \bullet
- El subsistema gestor de la plataforma y el subsistema gestión de servicio 236 tienen un concepto diferente de lo que es un elemento configurable 238 en la versión anterior de la plataforma. Estos dos conceptos están unidos en un concepto de elemento configurable, reuniendo sus funcionalidades separadas. Para hacer esto el subsistema gestor de la plataforma ya no eliminará ni restaurará elementos configurables, sino que informará a gestión de servicio cuando quiera que un elemento configurable sea eliminado y restaurado. Gestión de servicio será ahora el primer programa de la plataforma de telecomunicaciones iniciado e iniciará siempre GPNodo como parte de su inicialización. GPNodo estará entonces en control de iniciar y detener procesos lo mismo que estaba antes, sólo a través de gestión de servicios, no a través de la funcionalidad EliminarEC viejo y RestaurarEC.
La Fig. 9B es un diagrama de flujo de mensajes
que muestra la inicialización del nodo en el estado MIN_SET. La Fig.
9C es un diagrama de flujo de mensajes que muestra la inicialización
de nodo en el estado EN_SERVICIO, y la Fig. 9D es un diagrama de
flujo de mensajes que muestra la inicialización del nodo en el
estado POST-ESV.
La Fig. 10 bosqueja el protocolo de mensajes que
es usado entre GS y un Elemento Configurable. Si un elemento
configurable no puede enlazar con un objeto de la Interfaz de
Gestión de Servicio (IGS) dentro de él, gestión de servicio puede
todavía iniciar dicho elemento configurable, pero muchas de las
características que aporta gestión de servicio no estarán
disponibles.
El subsistema gestor de eventos proporciona la
capacidad para que un usuario emita genéricamente notificación de
eventos a una o más partes registradas. En el sistema pueden existir
múltiples instancias del objeto Gestor::Evento. Un Gestor::Evento de
nivel de nodo existe en todos los nodos. Otras instancias de
Gestor::Evento pueden existir también para proporcionar la capacidad
para que las partes interesadas se registren para eventos que son
especiales para un proceso. El programa gestoreventoimpl proporciona
una instancia del objeto Gestor::Evento para el modo que está en
ejecución. Los eventos que son relevantes para un nodo son emitidos
a través de tal instancia de Gestor::Evento. Los usuarios
interesados en eventos sobre un nodo particular pueden enlazarse a
tal instancia de Gestor::Evento de nodos usando dicho nombre de nodo
como el nombre de Gestor::Evento. Los programas pueden también
incrustar un objeto Gestor::Evento dentro de su programa. El
programa GtrPipimpl es un ejemplo de un programa que hace esto. El
GtrPipImpl tiene un Gestor::Evento llamado GtrEventoPip. Los
usuarios que lo deseen recibirán eventos PIP. Los usuarios que estén
interesados en un evento particular pueden registrase con una
instancia particular de Gestor::Evento para recibir tal evento a
través de tal instancia de Gestor::Evento. El Gestor::Evento no
almacena permanentemente la lista de las partes registradas. Si el
Gestor::Evento intenta remitir un evento a un Receptor::Evento que
ha desaparecido, tal Receptor::Evento es eliminado de la lista.
La Fig. 11 muestra dos ejemplos de usos para
Gestor::Evento 250 en el sistema de la plataforma de
telecomunicaciones. El gestoreventoimpl 252 contiene la instancia
250 del objeto Gestor::Evento de nodo. El programa 254 de la
plataforma de telecomunicaciones GPNodoPpal usa este Gestor::Evento
250 para emitir un evento cuando el nodo cambia de estado. El
programa de aplicación 256 crea entonces un objeto Receptor::Evento
268 y pasa una referencia de objeto CORBA a la llamada de registro
en el "nodo123" Gestor::Evento 250. Cuando GPNodoPpal 254
genera un evento solicitando notificación en el "Nodo123"
Gestor::Evento 250, tal Gestor::Evento 250 encontrará todos los
objetos Receptor::Evento 258 que se han registrado para recibir este
evento. Viendo que el programa de aplicación se ha registrado para
este evento, el Gestor::Evento 250 llamará al método notificar() en
tal objeto Receptor::Evento 258 que hará que el método notificar ()
sea invocado en el programa de Aplicación 256. En el ejemplo
anterior, el programa de aplicación 256 se ha registrado también con
el "GtrEventoPip" Gestor::Evento 260 en el programa GtrPipImpl
262. Cuando GPNodoPpal 254 usa la interfaz GtrPipImpl para emitir un
PIP, el programa GtrPipImpl 262 mira dicho PIP y realiza la
verificación, y llama a notificar() en el "GtrEventoPip"
Gestor::Evento 260. Esto hace que Gestor::Evento 250 remita el
evento generado al Receptor::Evento 264 en el programa de aplicación
256 que fue pasado en la llamada de registro.
Los programas de aplicación 256 pueden crear su
propio Gestor::Evento con su propio nombre de la misma forma que lo
hizo el programa GtrPipImpl. Las instancias de Gestor::Evento tienen
que tener nombres únicos en el sistema para prevenir la generación
de un evento al Gestor::Evento incorrecto o ayudar a evitar que un
usuario se registre con el Gestor::Evento incorrecto.
El subsistema Parte de Información y Problemas
(PIP) proporciona todos los procesos en el sistema con la capacidad
para emitir Partes de Información y Problemas. Los PIPs son el
mecanismo estándar usado para informar a los usuarios del sistema
acerca de condiciones de error u otra información pertinente del
sistema. El subsistema Parte de Información y Problemas implementa
la recogida de PIPs en la plataforma de telecomunicaciones. Una
Alarma es un mecanismo que puede ser fijado a un PIP. Los servicios
de Alarma no están disponibles ahora pero estarán disponibles en la
publicación futura de la plataforma de telecomunicaciones.
El subsistema PIP proporciona varias
características. Proporciona redundancia de servicio PIP activo/en
espera, la capacidad de remitir PIPs a receptores registrados, la
capacidad de remitir PIPs al anfitrión, la capacidad de visualizar
PIPs en tiempo real, compatibilidad regresiva con el legado de
elementos PAconfigurables de la interfaz PIP, una interfaz PIP
CORBA, la capacidad de usar un diccionario de PIP para validar PIPs,
la capacidad de proporcionar información adicional acerca del PIP
que fue emitido por el diccionario PIP y la capacidad de provisión
de PIP en el diccionario PIP.
Con referencia a la Fig. 12, el programa
GtrPipImpl es el punto de reunión para todos los PIPs en un sitio de
la plataforma de telecomunicaciones. Este programa contiene el
objeto servidor CORBA GtrPipImpl. El objeto GtrPipImpl se ejecuta en
cada uno de los nodos activo/en espera del gestor de la plataforma.
El estado activo/en espera al que reacciona el GtrPipImpl es el
estado activo/en espera de nivel de nodo de los nodos del gestor de
la plataforma de telecomunicaciones. El objeto GtrPipImpl en espera
no publicará su interfaz y el objeto GtrPipImpl activo publicará su
interfaz CORBA cuando los nodos del gestor de la plataforma cambien
al estado activo/en espera. Al hacer esto, los usuarios de cliente
de ambas interfaces GtrPip y ClientePIP tendrán sus PIP remitidos al
objeto GtrPipImpl activo.
El subsistema Gestor de Eventos es usado dentro
del subsistema PIP para distribuir PIPs. Esto permite que los PIP
sean remitidos a múltiples destinos. Usando el Gestor de Eventos,
características PIP adicionales pueden ser fácilmente añadidas al
sistema sin incurrir en cambios de interfaz. El mecanismo de Gestor
de Eventos del subsistema PIP es usado corrientemente dentro de la
plataforma de telecomunicaciones para proporcionar algunos servicios
PIP existentes. La IGU de PIP en tiempo real 270 se registra para
recibir PIPs para el propósito de mostrar PIPs cuando se producen.
El programa Pip2anfitrión 272 se registra con el subsistema PIP para
recibir PIPs y remitirlos al anfitrión, Un registrador de PIPs puede
también registrarse para recibir PIPs para registrarse al disco.
El programa Pip2anfitrión 272 es responsable de
remitir PIPs al anfitrión. Recibe PIPs desde el Gestor de Eventos de
GtrPipImpl y formatea un mensaje de anfitrión para remitirlo. Todos
los PIPs que se remiten al anfitrión usan el subsistema manejador de
mensajes para remitir PIPs a través del enlace lógico PIP_AFIRM.
El subsistema PIP tiene dos interfaces externas:
la interfaz PIPCliente 274 y la interfaz PIP CORBA 276. La interfaz
PIPCliente 276 existe para la compatibilidad regresiva con puestas
en servicio de elementos PAconfigurables anteriores. Una vez que el
PIP emitido desde la interfaz de PIPCliente 274 ha sido convertido
mediante el código PIPCliente, es emitido un PIP usando la interfaz
CORBA GtrPipImpl para enrutar el PIP al objeto de GtrPipImpl activo.
Esta interfaz usa todavía el diccionario de PIP LOCPIPBD.DSK como
entrada para convertir los PIPs de elemento PAconfigurable viejo al
formato del subsistema PIP actual. Esto requiere que un LOCPIPBD.DSK
resida en cada nodo que tiene programas que emiten PIPs. El
diccionario LOCPIPBD.DSK fue usado en las puestas en servicio
previas para hacer verificación de PIP antes de que los PIPs fueran
remitidos al anfitrión. La utilidad RegistroPIP es usada para
introducir PIPs dentro del diccionario LOCPIPBD.DSK. Los campos en
las entradas de la base de datos incluyen: Clave en ASCII (texto del
PIP), número PIP anfitrión, prioridad de PIP, número de palabras de
datos usadas y formato de palabras de datos. Para comprobar el
GtrPIP, los PIPs deben ser definidos en pip.in que será convertido
en un diccionario en clave (vía la utilidad RegistroPIP).
La interfaz de GtrPipImpl es una interfaz CORBA
IDL. Si es emitido un PIP usando esta interfaz, no se requiere que
sea introducido en el diccionario de LOCPIPBD.DSK. Cuando el objeto
GtrPipImpl recibe un PIP emitido, lo busca en el diccionario de PIP
y construye un evento PIP para que sea emitido. El evento PIP
contiene información que fue pasada desde el cliente que emitió el
PIP, e información del diccionario de PIP. Los PIPs deben ser
añadidos al diccionario de PIP y a los diccionarios de PIP del
anfitrión mega concentrador antes de la emisión de PIPs. La
herramienta ControladorPip es usada para añadir PIPs al diccionario
de PIP de GtrPipImpl. Los guiones de reformateo1 y reformateo2
ayudan a convertir un archivo PIP VAX a un formato que pueda ser
usado con el ControladorPip para engrosar el diccionario de PIP de
GtrPipImpl.
La Fig. 13 ilustra el escenario en el que una
aplicación emite un PIP, el Gestor de PIP lo procesa y el Gestor de
eventos enruta el PIP a una IGU de PIP para su representación
visual.
- 1)
- La IGU de PIP registra un interés en recibir todos los PIP informados al Gestor de Eventos de PIP.
- 2)
- Una aplicación emite un PIP.
- 3)
- El gestor de PIPs remite el PIP al Gestor de Eventos.
- 4)
- El Gestor de Eventos distribuye el PIP a la IGU de PIP.
La Fig. 14 es un ejemplo de una impresión de PIP
de la pantalla de la IGU. La vista de PIP de la aplicación IGU
proporciona la visualización de PIPs en una ventana fraccionada. En
la parte superior se muestra una vista gráfica de PIPs con costes
respecto al tiempo mostrado en la base. La parte inferior muestra
una vista de texto completa/breve tradicional de PIPs. Las
subcategorias pueden ser contempladas y se permiten varias
personalizaciones de la visualización. Adicionalmente, el filtrado y
el resalte de luz están disponibles para los PIP mostrados. La
comunicación es manejada vía CORBA.
Con referencia a la Fig. 15, el subsistema de
recogida de datos (RD) 298 proporciona la funcionalidad de medida de
tráfico para los programas de aplicación dentro de un nodo. Estas
medidas son recuentos registrados por la clase ContadorLlamadas y el
tiempo transcurrido por la clase MedidorTiempo. La comprobación de
ContadorLlamadas 299 comprobará indirectamente la memoria compartida
300 y los semáforos. Los procesos de cliente 301 llaman a la memoria
compartida 300 y recogida de datos 298 los recoge de la memoria
compartida 300 y los envía a RDMaestro 302. Cada 30 minutos,
recogida de datos 298 envía a RDMaestro 302 (en el nodo del gestor
de la plataforma activo) el valor de 30 minutos de las ranuras 299
de contador de llamadas y luego recogida de datos anula dichas
ranuras. El nodo 304 del gestor de la plataforma activo actualiza el
nodo 306 del gestor de la plataforma en espera.
Con referencia a la Fig. 16, los servicios de
estadística o subsistema de recogida de datos 320 proporciona la
medición de tráfico y las capacidades de medición de la plataforma.
Este subsistema 320 soporta la creación, recogida e informe de las
medidas estadísticas como contadores de llamadas, medidores de
tiempo, contadores de umbral, recogida y consulta. Los contadores de
llamadas 322 y los medidores de tiempo 324 se muestran soportados a
través de una aplicación distribuida. Las características
implementadas por el subsistema de recogida de datos 320
incluyen:
- -
- Soporte API de ContadorLlamadas 322 y MedidorTiempo 324
- -
- recogida de los datos acumulados desde múltiples nodos
- -
- Informar a IGU de la vista local de estadísticas
- -
- Conjuntos de medición definidos por el usuario para personalizar partes
El subsistema contador de umbral puede ser
implementado como un objeto distribuido intermediario para las
peticiones de objetos (ORB object request broker), usando la
implementación Orbeline ORB. Las aplicaciones son conectadas vía
Orbeline a un objeto servidor residente en los nodos del gestor de
la plataforma. El servidor informa de cruces de umbral de contador a
las aplicaciones vía el entorno de mensajería de objetos
distribuidos (DOME Distributed object messaging environment).
Los objetos de servidor son creados por el proceso de servidor de
contador de umbral, CUServidor. Cada proceso CUServidor comunica
también vía Orbeline con los CUServidor en nodos remotos, de manera
que los contadores pueden ser sincronizados a través de sitios. El
CUServidor mantiene todos los contadores en almacenamiento
permanente usando el diccionario permanente suministrado en la
librería de servicios comunes como clase plantilla RepShmDict.
La Fig. 17 muestra las trayectorias de
comunicación entre procesos de la aplicación 340 y los procesos de
servidor de contador. El proceso 342 de CUServidor comunica con los
procesos de la aplicación 340 vía Orbeline 344 y DOME 346. El
proceso CUServidor 342 se ejecuta en un bucle impl_está_lista,
esperando a las solicitudes de servicio desde cualquier proceso 340
de la aplicación o desde un proceso 342 de CUServidor en otro nodo.
Hace una llamada de solicitud de servicio a DOME para notificar a
los procesos de aplicación 340 que un contador ha alcanzado su
umbral.
Con referencia a la Fig. 18, la API del
subsistema contador de umbral 360 oculta las porciones específicas
de orbeline de la implementación al programador de la aplicación. En
su lugar, el lado del cliente del subsistema consistirá en dos
capas: una capa 362 independiente de ORBELINE y una capa 364
dependiente de ORBELINE. Aunque la implementación específica de
ORBELINE del subsistema está oculta al programador de la aplicación,
no lo está la naturaleza distribuida del subsistema. Para minimizar
el tiempo requerido para incrementos de contador, los incrementos de
contador son almacenados en la API y enviados al servidor en lotes.
Esto significa que la aplicación no puede recibir notificación
inmediata del éxito o fracaso de algunas operaciones en los objetos
de la API.
Como se muestra en las figuras 19 y 20, el
subsistema Manejador de Mensajes 370 proporciona servicios de
comunicaciones entre procesadores basado en mensajes. Generalmente
toda la comunicación entre procesos en los nodos del servidor es
llevada a cabo vía el entorno de mensajería de objetos distribuidos
(DOME) 372 mostrado en la Fig. 21. DOME 372 usa el subsistema Manejo
de Mensajes 370 cuando la información debe ser comunicada a través
de fronteras de nodo. El subsistema Manejo de Mensajes 370 es usado
también para comunicación a sistemas externos no del servidor tales
como el anfitrión SCP. El subsistema Manejo de mensajes 370
implementa las siguientes características.
- -
- Interfaz común para protocolos múltiples
- -
- TCP/IP 374
- -
- UDP/IP 376
- -
- DECNET 378
- -
- Identificador de acceso único (Nombre de Grupo de Enlace lógico) para enlaces múltiples con el mismo destino.
- -
- Gestión de enlace redundante (mejora la escalabilidad)
- -
- Recuperación de fracaso de enlace
- -
- Interfaz de recepción asíncrona
Con referencia a la Fig. 21, DOME 372 es una
interfaz cliente/servidor usada para comunicación cliente/servidor
entre procesos. Contiene interfaces de servidor 382 que permiten a
los procesos de servidor 382 registrar objetos y funciones miembro
para su uso mediante procesos de cliente 384. DOME 372 contiene una
base de datos 380 de memoria compartida para almacenar las
descripciones del servidor y un proceso servicios DOME único
(domeSrv) que mantiene las descripciones de objetos del servidor
desde otros nodos. También contiene interfaces de cliente 384 que
proporcionan acceso a cualquier objeto servidor registrado en la
base de datos DOME del nodo.
El subsistema de Comunicaciones entre Procesos
consiste principalmente en DOME. DOME proporciona la capacidad para
que un proceso se registre en un objeto servidor y sus métodos de
forma que permita que otros procesos en el sistema invoquen aquellos
métodos. DOME soporta varios modos de registro y acceso que incluyen
muchas opciones de enrutamiento especiales que ayudan en el
desarrollo de software resistente a fallos. Las características
implementadas por el subsistema de Comunicaciones entre Procesos
incluyen:
- -
- Gestión de Nombre de Objeto registrado a través de nodos y sitios
- -
- Manejo de solicitud priorizada
- -
- Enrutamiento de solicitud de Objeto activo/en espera
- -
- Enrutamiento de solicitud de Objeto carga compartida
- -
- Enrutamiento de solicitud de Objeto difusión
- -
- Solicitudes bloqueo/no bloqueo de Objetos
El subsistema Utilidades Comunes proporciona una
librería de herramientas de programación para ayudar en el
desarrollo rápido de procesos designados para ejecutarse sobre o
dentro de la capa de la plataforma. Las características
implementadas por el subsistema Utilidades Comunes incluyen:
- -
- Objeto Línea de Comandos
- -
- Objeto Traza
- -
- Objeto Memoria Compartida
- -
- Objeto Semáforo
- -
- Objeto Diccionario con clave
- -
- Objeto Lista
- -
- Objeto Diccionario con clave replicado
- -
- Objeto Diccionario Memoria Compartida
- -
- Etc.
Con referencia a la Fig. 22, las instalaciones
DprTraza 400 proporcionan la capacidad para emitir mensajes de traza
a una memoria intermedia de traza, a un archivo, y/o a error
estándar. Los datos de traza pueden ser introducidos en dos formatos
diferentes: formato de impresión estándar y formato de vaciado de
memoria intermedia de datos. Una máscara 402 puede ser usada para
filtrar diferentes niveles de mensajes. Hay 32 niveles de máscara
posibles para cada grupo DprTraza.
La interfaz CntlDpr 404 es la interfaz de control
para objetos DprTraza 400. Permite a los usuarios especificar muchos
aspectos diferentes de la instalación DprTraza 400. Esta interfaz
permite a los usuarios hacer las siguientes cosas en objetos
DprTraza 400:
- -
- Ajustar/obtener la máscara 402 para el grupo Dprtraza
- -
- Ajustar/obtener el tamaño de la memoria intermedia de mensajes internos 410
- -
- Obtener una lista de los grupos existentes
- -
- Encender/apagar la visualización para error estándar.
- -
- Encender/apagar el vaciado de trazas una a una a un archivo
- -
- Habilitar/deshabilitar la capacidad de vaciar trazas al archivo antes de que se sobreescriban.
Una interfaz DprDisc permite a los usuarios
especificar qué archivo de la memoria intermedia de traza 410 será
escrito en todas las solicitudes de escritura.
La instalación DprTraza 400 permite a los
usuarios crear objetos DprTraza 400 diferentes pudiendo pertenecer
cada uno de ellos a múltiples grupos. Esto permite a los usuarios
tener un valor de máscara único para cada grupo. Todas las trazas
emitidas a través de la interfaz DprTraza 400 se almacenan en una
memoria intermedia de mensajes internos. Los usuarios pueden también
especificar si emitir trazas a error estándar además de a la memoria
intermedia interna.
El objeto Traza proporciona al usuario la
capacidad de emitir opcionalmente mensajes de traza a error
estándar. Cuando el usuario emite una traza, es especificada una
máscara que representa el nivel de traza al que será sacada esta
traza. La interfaz Traza permite al usuario especificar una máscara
que usarán todas las instancias de traza en tal proceso UNIX para
determinar si emitir o no el mensaje de traza. La máscara de traza
puede soportar ocho valores de máscara únicos.
Con referencia a la Fig. 23, Gestión de
Diccionario proporciona clases que están diseñadas para soportar
almacenamiento de datos y acceso. Los diccionarios pueden ser
almacenados en disco (permanente) o almacenados en memoria. Los
diccionarios pueden también ser privados (usados solamente por el
proceso local) o compartidos (accesibles por múltiples procesos).
Los propósitos de estos diccionarios están definidos por el programa
de aplicación. La interacción primaria entre SgdMaestro 430 y
SgdServidor 432 es que SgdMaestro 430 actualiza SgdServidor 432
cuando recibe un mensaje de actualización desde la aplicación.
SgdMaestro 430 se ejecuta como activo/en espera en los nodos del
gestor de la plataforma y SgdServidor 432 se ejecuta en todos (o un
subconjunto) de las IPUs.
Los servicios de evento proporcionan la capacidad
de generar y distribuir sucesos específicos significativos para una
tarea entre procesos acoplados separables. Un ejemplo de un evento
es la compleción de una transferencia entrada/salida. Los servicios
de evento pueden ser una instalación de comunicación entre procesos
basada en CORBA. Ésta usa las solicitudes estándar de CORBA que
resultan en la ejecución de una operación por un objeto. Esto se
lleva a cabo a través del programa de implementación de gestor de
eventos.
Definiendo dos papeles distintos para objetos la
comunicación es desacoplada entre objetos, creando comunicación
asíncrona. Un objeto recibe y acumula nuevos eventos, mientras que
otro objeto registra un interés en que le sean remitidos estos
nuevos eventos. Esto se lleva a cabo por dos clases CORBA,
GestorEvento y ReceptorEvento. GestorEvento proporciona un lenguaje
de definición de Interfaz (IDL Interface Definition Language)
para recibir nuevos eventos. Receptorevento proporciona una interfaz
de lenguaje de definición de interfaz para clientes interesados en
recibir eventos.
La Fig. 24 muestra la vista de hardware de un
sistema de plataforma de telecomunicaciones. En el nivel más alto,
un sistema de plataforma de telecomunicaciones consiste en uno o más
sitios 440. Dentro de un sitio 440 existe múltiples nodos 442.
La representación de software es una jerarquía
que permite que los componentes de software sean agrupados juntos.
La Fig. 25 muestra esta jerarquía. Una aplicación 450 existe en el
nivel más alto. Una aplicación 450 está formada por uno o más
conjuntos de elementos configurables 452, que están formados por uno
o más elementos configurables 454. Múltiples aplicaciones 450 pueden
ser definidas dentro de un sistema. Todas las aplicaciones 450
dentro de un sistema constituyen la representación de software de un
sistema.
La asignación dinámica de software sobre la
representación de hardware de un sistema mostrada en la Fig. 26
muestra cómo las piezas de una aplicación 450 son colocadas sobre
nodos 442. Los sitios 440 contienen aplicaciones 450. Las
aplicaciones 450 tienen grupos de servicio del procesador 456. Los
grupos de servicio del procesador 456 se extienden sobre múltiples
nodos 442. Los nodos 442 tienen conjuntos 452 de elementos
configurables colocados en ellos. Los elementos configurables 454
residen dentro de conjuntos 452 de elementos configurables. Por
ejemplo, una representación de software de una aplicación de
enrutamiento dependiente del tiempo puede tener dos conjuntos de
elementos configurables: ConjuntoCostaOeste y ConjuntoCostaEste.
Dentro del conjuntoCostaOeste la aplicación de enrutamiento
dependiente del tiempo podría tener todos los programas que tienen
que ser ejecutados en los nodos que son objetivo para manejar las
llamadas de la Costa Oeste. Éstos podrían incluir programas de bases
de datos, procesos de enlace, etc. que son configurados
específicamente para el tratamiento de la Costa Oeste. Dentro del
ConjuntoCostaEste, la aplicación de enrutamiento dependiente del
tiempo puede tener todos los programas que tengan que ser ejecutados
en los nodos que son objetivo manejar las llamadas de la Costa
Oeste. La aplicación de enrutamiento dependiente del tiempo estaría
entonces localizada sobre un sitio. Los nodos que ejecuten la
aplicación de enrutamiento dependiente del tiempo serán agrupados en
grupos de servicio del procesador. Los conjuntos de elementos
configurables para la aplicación serán entonces colocados en nodos
que hayan sido dispuestos en una aplicación de enrutamiento
dependiente del tiempo del grupo de servicio del procesador.
Aunque han sido descritas en detalle varias
realizaciones de la presente invención y sus ventajas, debería
entenderse que pueden hacerse mutaciones, cambios, substituciones,
transformaciones, modificaciones, variaciones y alteraciones en ella
sin salirse de las instrucciones de la presente invención, estando
establecido el espíritu y alcance de la invención por las
reivindicaciones adjuntas.
Claims (18)
1. Método para proporcionar una interfaz de
software entre programas de aplicación que realizan funciones de
telecomunicaciones y un sistema operativo que se ejecuta en al menos
un nodo en un sitio que soporta los programas de aplicación, y que
forma además una interfaz entre los programas de aplicación y una
red de telecomunicaciones, caracterizado por: proporcionar un
gestor de la plataforma de red (104) operable para eliminar nodos
del servicio, restaurar nodos al servicio, eliminar aplicaciones del
servicio, y restaurar aplicaciones al servicio; proporcionar un
gestor de integridad del sistema de red (106) operable para
monitorizar los nodos y permitir recuperar los nodos fallidos;
proporcionar un gestor de configuración (108) operable para
interactuar con un anfitrión acoplado a la plataforma de
telecomunicaciones; proporcionar un gestor de la plataforma de nodos
(112) operable para proporcionar funciones de gestión para un nodo;
proporcionar un gestor de servicio (134) operable para iniciar y
detener procesos en la dirección del gestor de la plataforma de
nodos; y proporcionar un gestor de integridad del sistema de nodos
(130) operable para monitorizar los enlaces entre nodos.
2. Método, según la reivindicación 1, que
comprende además: proporcionar un gestor de eventos operable para
registrar los procesos de cliente que desean recibir eventos; y
proporcionar un receptor de eventos operable para proporcionar una
interfaz para procesos de cliente que están registrados para recibir
eventos.
3. Método según la reivindicación 1, que
comprende además: proporcionar un gestor de temporizador operable
para proporcionar funcionalidad de fecha y hora.
4. Método según la reivindicación 1, que
comprende además: proporcionar un proceso de contador de llamadas
operable para contar los eventos específicos que se producen a
través de múltiples nodos; proporcionar un proceso de medición de
tiempo operable para acumular la duración de un evento específico;
proporcionar un proceso de recogida de datos operable para recoger
datos de contador en un nodo y almacenar los datos recogidos.
5. Método según la reivindicación 1, que
comprende además: ejecutar un guión de arranque; iniciar un gestor
de servicio de acuerdo con el guión de arranque; iniciar, por el
gestor de servicio, un gestor de la plataforma de nodos para un
nodo; iniciar, por el gestor de servicio, el estado de operación
PRE-MIN de elementos de configuración para el nodo;
iniciar, por el gestor de servicio, estado de operación
OS-MIN de elementos de configuración para el nodo; y
subir un grado el estado del nodo en respuesta a los elementos de
configuración OS-MIN en el nodo.
6. Método según la reivindicación 1, que
comprende además: monitorizar y detectar un fallo en un elemento
configurable; notificar el fallo al gestor de servicio; generar, por
el gestor de servicio, un cambio de estado para el elemento
configurable y remitir la notificación al gestor de integridad del
sistema de nodos; remitir, por el gestor de integridad del sistema
de nodos, la notificación al gestor de la plataforma de nodos;
determinar, por el gestor de la plataforma de nodos, el estado del
nodo en respuesta al elemento configurable fallido, y notificar al
gestor de la plataforma de red, por el gestor de la plataforma de
nodos, un cambio de estado de nodo.
7. Método según la reivindicación 6, que
comprende además: determinar, por el gestor de la plataforma de red,
un cambio de estado en una aplicación que tiene el elemento
configurable fallido y un cambio de estado en un grupo de servicio
del procesador que tiene la aplicación que tiene el elemento
configurable fallido; y notificar cualquier cambio de estado al
gestor de configuración.
8. Método según la reivindicación 7, que
comprende además remitir, por el gestor de configuración, un cambio
de estado de nodo, aplicación, grupo de servicio de procesador a un
anfitrión.
9. Método según la reivindicación 1, que
comprende además: registrar con un gestor de eventos, mediante una
aplicación, un interés en recibir un evento particular; enviar, por
el receptor de eventos, el evento particular a la aplicación
registrada.
10. Una plataforma de telecomunicaciones que
forma una interfaz entre programas de aplicación que realizan
funciones de telecomunicaciones y un sistema operativo que se
ejecuta en al menos un nodo en un sitio que soporta los programas de
aplicación, y que forma además una interfaz entre los programas de
aplicación y una red de telecomunicaciones, caracterizada por
un gestor de plataforma de red (104) operable para eliminar nodos
del servicio, restaurar nodos al servicio, eliminar aplicaciones del
servicio y restaurar aplicaciones al servicio; un gestor de
integridad del sistema de red (106) operable para monitorizar los
nodos y permitir recuperar los nodos fallidos; un gestor de
configuración (108) operable para interactuar con un anfitrión
acoplado a la plataforma de telecomunicaciones; un gestor de la
plataforma de nodos (112) operable para proporcionar funciones de
gestión para un nodo; un gestor de servicio (134) operable para
iniciar y detener procesos en la dirección del gestor de la
plataforma de nodos; y un gestor de integridad del sistema de nodos
(130) operable para monitorizar enlaces entre nodos.
11. Plataforma de telecomunicaciones según la
reivindicación 10, que comprende además: un gestor de eventos
operable para registrar procesos de clientes que deseen recibir
eventos; y un receptor de eventos operable para proporcionar una
interfaz para procesos de cliente que están registrados para recibir
eventos.
\newpage
12. Plataforma de telecomunicaciones según la
reivindicación 10, que comprende además: un gestor de temporizador
operable para proporcionar funcionalidad de fecha y hora.
13. Plataforma de telecomunicaciones según la
reivindicación 10, que comprende además: un proceso de contador de
llamadas operable para contar eventos específicos que se producen a
través de múltiples nodos; un proceso de medición de tiempo operable
para acumular la duración de un evento específico; un proceso de
recogida de datos operable para recoger datos de contador en un nodo
y almacenar los datos recogidos.
14. Plataforma de telecomunicaciones según la
reivindicación 10, que comprende además medios para: ejecutar un
guión de arranque; iniciar un gestor de servicio de acuerdo con el
guión de arranque; iniciar, por el gestor de servicio, un gestor de
la plataforma de nodos para un nodo; iniciar, por el gestor de
servicio, el estado de operación PRE-MIN de
elementos de configuración para el nodo; iniciar, por el gestor de
servicio, el estado de operación OS-MIN de elementos
de configuración para el nodo; y subir un grado el estado del nodo
en respuesta a los elementos de configuración OS-MIN
en el nodo.
15. Plataforma de telecomunicaciones según la
reivindicación 10, que comprende además medios para: monitorizar y
detectar un fallo en un elemento configurable; notificar el fallo al
gestor de servicio; generar, por el gestor de servicio, un cambio de
estado para el elemento configurable y remitir la notificación al
gestor de integridad del sistema de nodos; remitir, por el gestor de
integridad del sistema de nodos, la notificación al gestor de
plataforma de nodos; determinar, por el gestor de plataforma de
nodos, el estado de nodo en respuesta al elemento configurable
fallido, y notificar al gestor de la plataforma de red, por el
gestor de plataforma de nodos, un cambio de estado de nodo.
16. Plataforma de telecomunicaciones según la
reivindicación 15, que comprende además medios para: determinar, por
el gestor de plataforma de red, un cambio de estado en una
aplicación que tiene un elemento configurable fallido y un cambio de
estado en un grupo de servicio del procesador que tiene la
aplicación que tiene el elemento configurable fallido, y notificar
cualquier cambio de estado al gestor de configuración.
17. Plataforma de telecomunicaciones según la
reivindicación 16, que comprende además medios para remitir, por el
gestor de configuración, un cambio de estado de un nodo, el grupo de
servicio del procesador o la aplicación.
18. Plataforma de telecomunicaciones según la
reivindicación 10, que comprende además medios para: registrar con
un gestor de eventos, mediante una aplicación, un interés en recibir
un evento particular; y enviar, por el receptor de eventos, el
evento particular a la aplicación registrada.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US6957697P | 1997-12-12 | 1997-12-12 | |
| US69576P | 1997-12-12 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2251118T3 true ES2251118T3 (es) | 2006-04-16 |
Family
ID=22089911
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES98963110T Expired - Lifetime ES2251118T3 (es) | 1997-12-12 | 1998-12-11 | Gestion de red. |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US6269396B1 (es) |
| EP (1) | EP1040678B1 (es) |
| JP (1) | JP4565740B2 (es) |
| CN (1) | CN1157960C (es) |
| AU (1) | AU1820599A (es) |
| DE (1) | DE69832096T2 (es) |
| ES (1) | ES2251118T3 (es) |
| WO (1) | WO1999030514A2 (es) |
Families Citing this family (132)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6724767B1 (en) | 1998-06-27 | 2004-04-20 | Intel Corporation | Two-dimensional queuing/de-queuing methods and systems for implementing the same |
| US6604136B1 (en) * | 1998-06-27 | 2003-08-05 | Intel Corporation | Application programming interfaces and methods enabling a host to interface with a network processor |
| US6735773B1 (en) | 1998-06-27 | 2004-05-11 | Intel Corporation | Method and apparatus for issuing commands to a network processor configured to provide a plurality of APIs |
| US6728249B2 (en) | 1998-06-27 | 2004-04-27 | Intel Corporation | System and method for performing cut-through forwarding in an ATM network supporting LAN emulation |
| US6603768B1 (en) | 1998-06-27 | 2003-08-05 | Intel Corporation | Multi-protocol conversion assistance method and system for a network accelerator |
| US6657959B1 (en) | 1998-06-27 | 2003-12-02 | Intel Corporation | Systems and methods for implementing ABR with guaranteed MCR |
| JP3834452B2 (ja) * | 1999-04-01 | 2006-10-18 | セイコーエプソン株式会社 | 機器管理システム、管理サーバ及びコンピュータ読取可能な記録媒体 |
| US6513129B1 (en) * | 1999-06-30 | 2003-01-28 | Objective Systems Integrators, Inc. | System and method for managing faults using a gateway |
| US6820214B1 (en) * | 1999-07-26 | 2004-11-16 | Microsoft Corporation | Automated system recovery via backup and restoration of system state |
| US6851073B1 (en) * | 1999-07-26 | 2005-02-01 | Microsoft Corporation | Extensible system recovery architecture |
| US7089300B1 (en) * | 1999-10-18 | 2006-08-08 | Apple Computer, Inc. | Method and apparatus for administering the operating system of a net-booted environment |
| US6751658B1 (en) * | 1999-10-18 | 2004-06-15 | Apple Computer, Inc. | Providing a reliable operating system for clients of a net-booted environment |
| US6857023B2 (en) * | 2000-04-25 | 2005-02-15 | Pegasus Solutions, Inc. | System uses an interface controller for managing operations of devices that each has a unique communication protocol |
| US20020026473A1 (en) * | 2000-08-31 | 2002-02-28 | Telefonaktiebolaget Lm Ericsson (Publ) | Application-programming-interface-based method and system including triggers |
| US6888937B1 (en) * | 2000-09-06 | 2005-05-03 | Cisco Technology, Inc. | Managing processes of a network component |
| US7043636B2 (en) * | 2000-09-26 | 2006-05-09 | Telefonaktiebolaget Lm Ericsson (Publ) | Data integrity mechanisms for static and dynamic data |
| US6725266B1 (en) * | 2000-10-05 | 2004-04-20 | Hewlett-Packard Development Company, L.P. | System and method for changing the status of a system service |
| US6981025B1 (en) | 2000-10-19 | 2005-12-27 | International Business Machines Corporation | Method and apparatus for ensuring scalable mastership during initialization of a system area network |
| US7113995B1 (en) | 2000-10-19 | 2006-09-26 | International Business Machines Corporation | Method and apparatus for reporting unauthorized attempts to access nodes in a network computing system |
| US7636772B1 (en) | 2000-10-19 | 2009-12-22 | International Business Machines Corporation | Method and apparatus for dynamic retention of system area network management information in non-volatile store |
| US6978300B1 (en) * | 2000-10-19 | 2005-12-20 | International Business Machines Corporation | Method and apparatus to perform fabric management |
| US6990528B1 (en) | 2000-10-19 | 2006-01-24 | International Business Machines Corporation | System area network of end-to-end context via reliable datagram domains |
| US6941350B1 (en) | 2000-10-19 | 2005-09-06 | International Business Machines Corporation | Method and apparatus for reliably choosing a master network manager during initialization of a network computing system |
| US7099955B1 (en) | 2000-10-19 | 2006-08-29 | International Business Machines Corporation | End node partitioning using LMC for a system area network |
| US7606898B1 (en) * | 2000-10-24 | 2009-10-20 | Microsoft Corporation | System and method for distributed management of shared computers |
| DE10052929A1 (de) * | 2000-10-25 | 2002-05-08 | Alcatel Sa | Verfahren und Vorrichtung (RNC) zum Steuern eines Funkzellenclusters bestehend aus mehreren Funkzellen eines Multistandard-Funknetzwerks |
| US7278104B1 (en) * | 2000-11-02 | 2007-10-02 | Lucent Technologies Inc. | Graphical user interface for managing network elements |
| US20020073257A1 (en) * | 2000-12-07 | 2002-06-13 | Ibm Corporation | Transferring foreign protocols across a system area network |
| US7051326B2 (en) * | 2000-12-13 | 2006-05-23 | International Business Machines Corporation | Code image distribution in a multi-node network of processors |
| US7143405B2 (en) * | 2001-01-05 | 2006-11-28 | Microsoft Corporation | Methods and arrangements for managing devices |
| US20020091720A1 (en) * | 2001-01-05 | 2002-07-11 | Jun Liu | Methods and arrangements for providing improved software version control in managed devices |
| GB2372175B (en) | 2001-02-13 | 2004-06-23 | Vodafone Ltd | Provision of services via a mobile telecommunications network |
| US7882253B2 (en) * | 2001-04-05 | 2011-02-01 | Real-Time Innovations, Inc. | Real-time publish-subscribe system |
| US20040015856A1 (en) * | 2001-05-15 | 2004-01-22 | Goward Philip J. | Automatically propagating distributed components during application development |
| US8032625B2 (en) | 2001-06-29 | 2011-10-04 | International Business Machines Corporation | Method and system for a network management framework with redundant failover methodology |
| ATE308208T1 (de) * | 2001-07-06 | 2005-11-15 | Koninkl Kpn Nv | Abfrage- und analyseverfahren für mstp in einem funktelekommunikationsnetzwerk |
| US20030046433A1 (en) * | 2001-07-25 | 2003-03-06 | Omer Luzzatti | Method to synchronize information between online devices |
| US7584425B2 (en) * | 2001-07-31 | 2009-09-01 | Verizon Business Global Llc | Systems and methods for generating reports |
| US20030046334A1 (en) * | 2001-08-29 | 2003-03-06 | Simpson Shell S. | Client resident service that launches a browser to provide device status |
| US7389332B1 (en) | 2001-09-07 | 2008-06-17 | Cisco Technology, Inc. | Method and apparatus for supporting communications between nodes operating in a master-slave configuration |
| CN100388698C (zh) * | 2001-10-19 | 2008-05-14 | 上海贝尔有限公司 | 用于数字数据网接入模块的管理指配控件及其控制方法 |
| KR100408048B1 (ko) * | 2001-12-31 | 2003-12-01 | 엘지전자 주식회사 | 인터넷 기반 ｉｐ전화 시스템 서버의 다중화 방법 |
| US20030140093A1 (en) * | 2002-01-23 | 2003-07-24 | Factor Cory L. | Method and apparatus for providing content over a distributed network |
| US7587759B1 (en) * | 2002-02-04 | 2009-09-08 | Mcafee, Inc. | Intrusion prevention for active networked applications |
| US7536181B2 (en) * | 2002-02-15 | 2009-05-19 | Telefonaktiebolaget L M Ericsson (Publ) | Platform system for mobile terminals |
| US7286823B2 (en) * | 2002-02-15 | 2007-10-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Mobile multimedia engine |
| US7240830B2 (en) * | 2002-02-15 | 2007-07-10 | Telefonaktiebolaget Lm Ericsson (Publ) | Layered SIM card and security function |
| US7415270B2 (en) * | 2002-02-15 | 2008-08-19 | Telefonaktiebolaget L M Ericsson (Publ) | Middleware services layer for platform system for mobile terminals |
| US8079015B2 (en) * | 2002-02-15 | 2011-12-13 | Telefonaktiebolaget L M Ericsson (Publ) | Layered architecture for mobile terminals |
| US7363033B2 (en) * | 2002-02-15 | 2008-04-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Method of and system for testing equipment during manufacturing |
| US7421478B1 (en) | 2002-03-07 | 2008-09-02 | Cisco Technology, Inc. | Method and apparatus for exchanging heartbeat messages and configuration information between nodes operating in a master-slave configuration |
| US7165258B1 (en) * | 2002-04-22 | 2007-01-16 | Cisco Technology, Inc. | SCSI-based storage area network having a SCSI router that routes traffic between SCSI and IP networks |
| US7415535B1 (en) * | 2002-04-22 | 2008-08-19 | Cisco Technology, Inc. | Virtual MAC address system and method |
| US7587465B1 (en) | 2002-04-22 | 2009-09-08 | Cisco Technology, Inc. | Method and apparatus for configuring nodes as masters or slaves |
| US7433952B1 (en) | 2002-04-22 | 2008-10-07 | Cisco Technology, Inc. | System and method for interconnecting a storage area network |
| US7200610B1 (en) | 2002-04-22 | 2007-04-03 | Cisco Technology, Inc. | System and method for configuring fibre-channel devices |
| US7188194B1 (en) * | 2002-04-22 | 2007-03-06 | Cisco Technology, Inc. | Session-based target/LUN mapping for a storage area network and associated method |
| US7240098B1 (en) | 2002-05-09 | 2007-07-03 | Cisco Technology, Inc. | System, method, and software for a virtual host bus adapter in a storage-area network |
| US7509436B1 (en) | 2002-05-09 | 2009-03-24 | Cisco Technology, Inc. | System and method for increased virtual driver throughput |
| US7302692B2 (en) | 2002-05-31 | 2007-11-27 | International Business Machines Corporation | Locally providing globally consistent information to communications layers |
| US7143615B2 (en) * | 2002-07-31 | 2006-12-05 | Sun Microsystems, Inc. | Method, system, and program for discovering components within a network |
| US20040045007A1 (en) * | 2002-08-30 | 2004-03-04 | Bae Systems Information Electronic Systems Integration, Inc. | Object oriented component and framework architecture for signal processing |
| US7584471B2 (en) * | 2002-09-23 | 2009-09-01 | Telefonaktiebolaget L M Ericsson (Publ) | Plug-in model |
| US7350211B2 (en) | 2002-09-23 | 2008-03-25 | Telefonaktiebolaget Lm Ericsson (Publ) | Middleware application environment |
| US7149510B2 (en) * | 2002-09-23 | 2006-12-12 | Telefonaktiebolaget Lm Ericsson (Publ) | Security access manager in middleware |
| US7730155B1 (en) | 2002-10-01 | 2010-06-01 | Apple Inc. | Method and apparatus for dynamically locating resources |
| US6876733B2 (en) * | 2002-12-03 | 2005-04-05 | International Business Machines Corporation | Generic service component for message formatting |
| CN1317653C (zh) * | 2002-12-25 | 2007-05-23 | 中兴通讯股份有限公司 | 一种数据库连接的高效管理方法 |
| CN1300979C (zh) * | 2003-01-28 | 2007-02-14 | 华为技术有限公司 | 全动态分布式网络服务管理系统及其服务方法 |
| JP2004259044A (ja) * | 2003-02-26 | 2004-09-16 | Hitachi Ltd | 情報処理装置の管理方法およびシステム |
| US7831736B1 (en) | 2003-02-27 | 2010-11-09 | Cisco Technology, Inc. | System and method for supporting VLANs in an iSCSI |
| US7890543B2 (en) | 2003-03-06 | 2011-02-15 | Microsoft Corporation | Architecture for distributed computing system and automated design, deployment, and management of distributed applications |
| US8122106B2 (en) | 2003-03-06 | 2012-02-21 | Microsoft Corporation | Integrating design, deployment, and management phases for systems |
| US7092504B1 (en) * | 2003-03-18 | 2006-08-15 | Sprint Communications Company L.P. | Method and system for presenting data stored within a network component |
| US7295572B1 (en) | 2003-03-26 | 2007-11-13 | Cisco Technology, Inc. | Storage router and method for routing IP datagrams between data path processors using a fibre channel switch |
| US7433300B1 (en) | 2003-03-28 | 2008-10-07 | Cisco Technology, Inc. | Synchronization of configuration data in storage-area networks |
| US7904599B1 (en) | 2003-03-28 | 2011-03-08 | Cisco Technology, Inc. | Synchronization and auditing of zone configuration data in storage-area networks |
| US7526527B1 (en) | 2003-03-31 | 2009-04-28 | Cisco Technology, Inc. | Storage area network interconnect server |
| JP2004361994A (ja) * | 2003-05-30 | 2004-12-24 | Toshiba Corp | データ管理装置、データ管理方法及びプログラム |
| EP1484678A1 (en) * | 2003-06-04 | 2004-12-08 | Hewlett-Packard Development Company, L.P. | Method and system for running a software application to perform a plurality of similar tasks |
| US7451208B1 (en) | 2003-06-28 | 2008-11-11 | Cisco Technology, Inc. | Systems and methods for network address failover |
| US7774774B1 (en) * | 2003-10-22 | 2010-08-10 | Apple Inc. | Software setup system |
| CN100463535C (zh) * | 2003-11-28 | 2009-02-18 | 中兴通讯股份有限公司 | 一种电信网管机架板位图的数据绑定方法 |
| US7475406B2 (en) * | 2003-12-15 | 2009-01-06 | International Business Machines Corporation | Event notification structure for dynamically aggregated logical components |
| US7431699B2 (en) * | 2003-12-24 | 2008-10-07 | Cardiac Pacemakers, Inc. | Method and apparatus for third heart sound detection |
| US7115096B2 (en) | 2003-12-24 | 2006-10-03 | Cardiac Pacemakers, Inc. | Third heart sound activity index for heart failure monitoring |
| US7778422B2 (en) | 2004-02-27 | 2010-08-17 | Microsoft Corporation | Security associations for devices |
| US20050246529A1 (en) | 2004-04-30 | 2005-11-03 | Microsoft Corporation | Isolated persistent identity storage for authentication of computing devies |
| JP4722558B2 (ja) * | 2004-06-01 | 2011-07-13 | 株式会社小松製作所 | ダイクッション装置 |
| US20060070082A1 (en) * | 2004-06-15 | 2006-03-30 | Manjula Sridhar | Managed object framework for network management application development |
| US7555743B2 (en) * | 2004-06-15 | 2009-06-30 | Alcatel-Lucent Usa Inc. | SNMP agent code generation and SNMP agent framework for network management application development |
| US20060036721A1 (en) * | 2004-06-15 | 2006-02-16 | Dong Zhao | Run-time tool for network management application |
| US20060004856A1 (en) * | 2004-06-15 | 2006-01-05 | Xiangyang Shen | Data management and persistence frameworks for network management application development |
| US20050278361A1 (en) * | 2004-06-15 | 2005-12-15 | Brunell Edward G | View definition language for network management application development |
| US20050278693A1 (en) * | 2004-06-15 | 2005-12-15 | Brunell Edward G | Distribution adaptor for network management application development |
| US20050278708A1 (en) * | 2004-06-15 | 2005-12-15 | Dong Zhao | Event management framework for network management application development |
| JP4576249B2 (ja) * | 2005-01-27 | 2010-11-04 | 株式会社クラウド・スコープ・テクノロジーズ | ネットワーク管理装置及び方法 |
| US8489728B2 (en) | 2005-04-15 | 2013-07-16 | Microsoft Corporation | Model-based system monitoring |
| US7802144B2 (en) | 2005-04-15 | 2010-09-21 | Microsoft Corporation | Model-based system monitoring |
| US7922669B2 (en) | 2005-06-08 | 2011-04-12 | Cardiac Pacemakers, Inc. | Ischemia detection using a heart sound sensor |
| US8549513B2 (en) | 2005-06-29 | 2013-10-01 | Microsoft Corporation | Model-based virtual system provisioning |
| CN100579146C (zh) * | 2005-09-02 | 2010-01-06 | 深圳市东进通讯技术股份有限公司 | 综合电信平台中的模块配置管理方法 |
| US7533128B1 (en) | 2005-10-18 | 2009-05-12 | Real-Time Innovations, Inc. | Data distribution service and database management systems bridge |
| US7941309B2 (en) | 2005-11-02 | 2011-05-10 | Microsoft Corporation | Modeling IT operations/policies |
| US20070112954A1 (en) * | 2005-11-15 | 2007-05-17 | Yahoo! Inc. | Efficiently detecting abnormal client termination |
| US7780606B2 (en) | 2006-03-29 | 2010-08-24 | Cardiac Pacemakers, Inc. | Hemodynamic stability assessment based on heart sounds |
| US7865583B2 (en) * | 2006-03-31 | 2011-01-04 | The Invention Science Fund I, Llc | Aggregating network activity using software provenance data |
| US7827559B1 (en) | 2006-04-24 | 2010-11-02 | Real-Time Innovations, Inc. | Framework for executing multiple threads and sharing resources in a multithreaded computer programming environment |
| US8671135B1 (en) | 2006-04-24 | 2014-03-11 | Real-Time Innovations, Inc. | Flexible mechanism for implementing the middleware of a data distribution system over multiple transport networks |
| US7783853B1 (en) | 2006-04-24 | 2010-08-24 | Real-Time Innovations, Inc. | Memory usage techniques in middleware of a real-time data distribution system |
| US8977252B1 (en) * | 2006-07-06 | 2015-03-10 | Gryphonet Ltd. | System and method for automatic detection and recovery of malfunction in mobile devices |
| JP4377899B2 (ja) * | 2006-09-20 | 2009-12-02 | 株式会社東芝 | リソース管理装置及びプログラム |
| US7974211B2 (en) * | 2006-10-30 | 2011-07-05 | Hewlett-Packard Development Company, L.P. | Methods and apparatus for network configuration baselining and restoration |
| US20080119749A1 (en) | 2006-11-20 | 2008-05-22 | Cardiac Pacemakers, Inc. | Respiration-synchronized heart sound trending |
| US8096954B2 (en) | 2006-11-29 | 2012-01-17 | Cardiac Pacemakers, Inc. | Adaptive sampling of heart sounds |
| JP4249780B2 (ja) * | 2006-12-26 | 2009-04-08 | 株式会社東芝 | リソースを管理する装置、およびプログラム |
| US7853327B2 (en) | 2007-04-17 | 2010-12-14 | Cardiac Pacemakers, Inc. | Heart sound tracking system and method |
| JP4907603B2 (ja) * | 2007-06-27 | 2012-04-04 | ヒューレット−パッカード デベロップメント カンパニー エル．ピー． | アクセス制御システムおよびアクセス制御方法 |
| JP2009086733A (ja) * | 2007-09-27 | 2009-04-23 | Toshiba Corp | 情報処理装置、情報処理装置の制御方法および情報処理装置の制御プログラム |
| US7958386B2 (en) * | 2007-12-12 | 2011-06-07 | At&T Intellectual Property I, L.P. | Method and apparatus for providing a reliable fault management for a network |
| CN101232540B (zh) * | 2008-02-21 | 2012-04-04 | 中兴通讯股份有限公司 | 系统间消息交互方法及消息交互系统 |
| JP2010102612A (ja) * | 2008-10-27 | 2010-05-06 | Seiko Epson Corp | デバイス状態通知装置 |
| JP5238525B2 (ja) * | 2009-01-13 | 2013-07-17 | 株式会社東芝 | リソースを管理する装置、およびプログラム |
| US9690818B2 (en) * | 2009-12-01 | 2017-06-27 | Sybase, Inc. | On demand locking of retained resources in a distributed shared disk cluster environment |
| US8830240B1 (en) * | 2011-09-30 | 2014-09-09 | Rockwell Collins, Inc. | Universal stack analyzer |
| US8943034B2 (en) * | 2011-12-22 | 2015-01-27 | Sap Se | Data change management through use of a change control manager |
| US9081818B2 (en) * | 2012-03-13 | 2015-07-14 | Hewlett-Packard Development Company, L.P. | SAS fabric discovery |
| US9497095B2 (en) * | 2012-03-22 | 2016-11-15 | International Business Machines Corporation | Dynamic control over tracing of messages received by a message broker |
| TWI594186B (zh) * | 2012-05-16 | 2017-08-01 | 緯創資通股份有限公司 | 虛擬頻道之管理方法、擷取數位內容之方法及具有虛擬頻道之網路多媒體重現系統 |
| US9542172B2 (en) | 2013-02-05 | 2017-01-10 | Apple Inc. | Automatic updating of applications |
| CN103647668A (zh) * | 2013-12-16 | 2014-03-19 | 上海证券交易所 | 一种高可用集群内主机群体决策系统及切换方法 |
| US9800515B2 (en) * | 2014-01-31 | 2017-10-24 | Apollo Education Group, Inc. | Mechanism for controlling a process on a computing node based on the participation status of the computing node |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1993020508A1 (en) * | 1992-04-07 | 1993-10-14 | Digital Equipment Corporation | Entity management system with remote call feature |
| US6243396B1 (en) | 1995-08-15 | 2001-06-05 | Broadcom Eireann Research Limited | Communications network management system |
| GB2308779B (en) | 1995-12-28 | 1998-06-10 | Nokia Telecommunications Oy | Telecommunications network management system |
| US5726979A (en) * | 1996-02-22 | 1998-03-10 | Mci Corporation | Network management system |
| US5940487A (en) * | 1996-04-10 | 1999-08-17 | Alcatel Usa Sourcing, L.P. | Programmable call processing system and method |
-
1998
- 1998-12-11 EP EP98963110A patent/EP1040678B1/en not_active Expired - Lifetime
- 1998-12-11 ES ES98963110T patent/ES2251118T3/es not_active Expired - Lifetime
- 1998-12-11 WO PCT/US1998/026439 patent/WO1999030514A2/en active IP Right Grant
- 1998-12-11 AU AU18205/99A patent/AU1820599A/en not_active Abandoned
- 1998-12-11 DE DE69832096T patent/DE69832096T2/de not_active Expired - Lifetime
- 1998-12-11 US US09/211,016 patent/US6269396B1/en not_active Expired - Lifetime
- 1998-12-11 CN CNB988121077A patent/CN1157960C/zh not_active Expired - Fee Related
- 1998-12-11 JP JP2000524941A patent/JP4565740B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| WO1999030514A3 (en) | 1999-07-22 |
| DE69832096D1 (de) | 2005-12-01 |
| WO1999030514A2 (en) | 1999-06-17 |
| CN1157960C (zh) | 2004-07-14 |
| AU1820599A (en) | 1999-06-28 |
| JP2001526508A (ja) | 2001-12-18 |
| EP1040678B1 (en) | 2005-10-26 |
| US6269396B1 (en) | 2001-07-31 |
| EP1040678A2 (en) | 2000-10-04 |
| DE69832096T2 (de) | 2006-07-13 |
| JP4565740B2 (ja) | 2010-10-20 |
| CN1297654A (zh) | 2001-05-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2251118T3 (es) | Gestion de red. | |
| US10713280B2 (en) | Systems and methods for managing distributed database deployments | |
| US11544288B2 (en) | Systems and methods for managing distributed database deployments | |
| US11615115B2 (en) | Systems and methods for managing distributed database deployments | |
| US10740353B2 (en) | Systems and methods for managing distributed database deployments | |
| US11740943B2 (en) | Techniques for managing long-running tasks with a declarative provisioner | |
| ES2687969T3 (es) | Vigilancia a distancia de un sistema de procesamiento de datos mediante una red de comunicaciones | |
| Girod et al. | Emstar: A software environment for developing and deploying heterogeneous sensor-actuator networks | |
| Alquraan et al. | An analysis of {Network-Partitioning} failures in cloud systems | |
| US10764252B2 (en) | Communicating with machine to machine devices | |
| ES2326538T3 (es) | Sistema y metodo para la gestion de las caracteristicas de funcionamiento en un entorno informatico de varios niveles. | |
| CN109857613B (zh) | 一种基于采集集群的自动化运维系统 | |
| Yabandeh et al. | Predicting and preventing inconsistencies in deployed distributed systems | |
| US8631283B1 (en) | Monitoring and automated recovery of data instances | |
| CN100549962C (zh) | 用于置换资源控制器锁的所有权的装置、系统和方法 | |
| US20240015143A1 (en) | Cross-regional replication of keys | |
| US7823136B2 (en) | Callbacks for monitoring driver-level statistics | |
| De Florio et al. | An algorithm for tolerating crash failures in distributed systems | |
| WO2019205345A1 (zh) | 用户信息同步方法、装置、计算机装置及存储介质 | |
| Ma et al. | Finding heterogeneous-unsafe configuration parameters in cloud systems | |
| US7784033B2 (en) | JDBC monitoring and diagnostics enhancements | |
| US20070083525A1 (en) | JDBC debugging enhancements | |
| US11563628B1 (en) | Failure detection in cloud-computing systems | |
| Ma | Mitigating Distributed Configuration Errors in Cloud Systems | |
| Newbold | Reliability and state machines in an advanced network testbed |