Configuracion actual del backup on alarm para Multiservice Switch

Cuando el servidor de backup se inicia con la opcin notification y recibe una alarma de comisionamiento, confirmacin de provisionamiento, reset o reconexin del nodo, inicia un backup para el elemento de red que posea el parmetro On_Alarm en true. Cuando un backup on alarma falle, se genera una alarma para notificarle a usted de la falla. La alarma identifica el elemento de red y la razn de la falla en dicho elemento. Pasos para la activacin: En el papel determinar sobre que nodos se va a realizar el backup, de tal modo que en dichos nodos se encuentre activo el jorunaling. Determinar los gmdr a los que estn conectados los nodos en mencin para conectarlos con los servidores de backup apropiados. Mediante lnea de comando. 1. Verificar que los servidores relacionados se encuentran activados y que el servidor de backup se ha lanzado con la opcin notification

1. Realizar una prueba en un nodo (modificando la configuracin del nodo) y comprobar que se realiza el backup on alarm. Podra ser utilizando:
tail f /opt/MagellanNMS/data/log/journalBackup.log

Funcionalidad del servidor de backup

On_alarm se dispara debido a los cambios de configuracin en el switch debido a la notificacin del servidor de backup y requiere que el servidor de backup sea configurado para escuchar a un servidor GMDR en particular, el cual provee la notificacin basada en la informacin de la alarma desde el elemento de red. Son el servidor GMDR, el servidor de backup no puede recibir la notificacin en tiempo real de los cambios de provisionamiento. Si el GMDR se ejecuta en un host diferente del servidor de backup, puede especificarlo. Ver el apartado Interfaz con el GMDR para ms informacin. Cuando el servidor de backup recibe una alarma, se desenlazan la siguiente secuencia de eventos: 1. Verifica que la vista comisionada se haya almacenado. Si no, entonces lo hace. 2. Si vista actual posee un nombre y no est guardado, lo guarda. 3. Compara los timestamps del directorio journal en el nodo y en el lugar del backup. (Si son diferentes, se crea un nuevo directorio journal.) 4. Verifica que todos los journals se hayan guardado. Si no, guarda los archivos faltantes. 5. Actualiza el archivo recovery.INFO 6. Adquiere la lista de ejecucin AV y actualiza el archivo avl.INFO 7. Actualiza el archivo view.INFO 8. Notifica al servidor de datos de sincronizacin. La siguiente informacin se consigue desde el elemento de red Multiservice Switch: Nombre de la vista comisionada. Cantidad de journals Nombre de la vista actual Atributo journalDisabledReason Atributo restorePossible Tiempo de activacin = (en este caso, el tiempo de activacin es el tiempo d prov del ltimo backup journal)

Esta informacin es almacenada en el archivo recovery.INFO. El servidor de backup compara esta informacin con la que ya ha almacenado y entonces transfiere los archivos necesarios. Cuando no se encuentra habilitado el journaling, el nodo enva nicamente las alarmas Confirm y Node Reconnect. Cuando el servidor de backup recibe las alarmas Confirm y Node Reconnect, recupera la vista actual del nodo. El cliente debe guardas, activar y confirmar el provisionamiento para asegurar que la vista actual est disponible. En este caso, la vista actual posee un nombre vlido. El servidor de backup revisa si ya ha guardado el archivo, y si no, transfiere el archivo al sitio de backup. No hay journals transferidos.

Backup on alarm, con el journaling habilitado

Cuando el journaling se encuentra habilitado en el nodo, el servidor de backup recupera los archivos del journal y la configuracin comisionada del elemento de red. En otras palabras, la configuracin actual es completamente guardada en la estacin MDM. Adems, la configuracin completa actual puede ser sincronizada con la utilidad Administration Database. Esta opcin se recomienda para redes grandes porque el journaling permite al MDM tomar ventaja de los archivos delta del journal los cuales permites una mayor eficiencia de transferencia de los cambios. En una red grande, hay probablemente gran cantidad de archivos de vista. Tambin, ms de un elemento de red ser actualizado probablemente varias veces y concurrentemente. Esta opcin emplea la notificacin de alarma desde el elemento de red para disparar el backup de los archivos de vista y de journal cuando ocurren los cambios de la configuracin. La base de datos entonces puede ser sincronizada empleando esta informacin. Esta opcin puede ser utilizada para sincronizacin casi en tiempo real tanto de la informacin del backup como de la base de datos. Usted especifica los elementos de red que quiere realizar el backup empleando el archivo de configuracin de sincronizacin de datos, (DataSync.cfg) que se encuentra en /opt/MagellanNMS/cfg, en la estacin del servidor de backup. Las siguientes actividades son las que disparan la revisin del servidor de backup para realizar el backup si es necesario: Confirm prov luego de una activacin (7000 0007 clear) Commit prov (7000 0039) Reset del elemento de red (7000 0038 set) Reconexin del MDM al elemento de red (09990001 clear). Esta es una alarma proxy que es generada por el MDM, y no por el elemento de red.

Cuando el servidor de backup recibe cualquiera de dichas alarmas, consigue la vista actual y los journals, con propsitos de restauracin, desde los elementos de red y los almacena en el archivo recovery.INFO. Si una activacin se seguida por un comisionamiento, todos los journals pendientes son comprimidos, cargados, y luego los tags de activacin son revisados para

verificar si ser requiere la carga del vista comisionada. El tag de activacin permite al servidor de sincronizacin de datos determinar si la vista comisionada es la misma que la vista comisionada anterior, ms todos los journals, desde el ltimo comisionamiento.

Backup on alarm para vista completa (sin journaling)

Si un usuario ha realizado aprovisionamiento y activaciones en el elemento de red sin guardar, entonces nicamente la vista comisionada puede ser respaldada en la estacin MDM. Cuando el journaling no est habilitado para los elementos de red MSS, no es posible obtener una vista completa actual. Las activaciones no son respaldadas en la estacin hasta que se hayan guardado, activado, y se haya ejecutado un comando confirm prov. El comando confirm prov es extremadamente importante en casos en donde el journaling no est disponible/habilitado. Esta opcin es empleada en versiones anteriores de MSS PCR 5.1, y slo debe ser utilizada para una red pequea. En done el journaling no es utilizado, el archivo completo de vista es transferido para cada confirmacin de provisionamiento realizado en cada elemento de red. Esto aade una gran cantidad de trfico de datos entre el servidor de backup y la red, requiere gran cantidad de espacio en disco para almacenar todas las vistas, y ocasiona gran demanda de procesamiento MDM y memoria para sincronizacin de la base de datos. Esto puede ocasionar situaciones de ingeniera en trminos de la red OAM y la capacidad de la estacin, y no es recomendado. Los elementos de red que soportan journaling, pero no lo utilizan, apenas envan las alarmas Confirm y Node Reconnect generadas por el MDM. Es esta situacin, el servidor de backup apenas es disparado por las alarmas de confirmacin. Consigue nicamente la vista comisionada a partir del elemento de red y almacena esta informacin en el archivo recovery.INFO. (Ver el apartado archivo recovery.INFO). Como es el caso con elementos de red empleando journaling, el servidor de backup revisa si la vista actual posee un archivo de backup. Si no, emplea FTP para enviar el archivo al sitio de respaldo.

Interfaz con GMDR

El proceso GMDR debe estar disponible cuando deba ocurrir un backup on_alarm. El proceso GMDR asegura que el servidor de backup es notificado de un cambio de provisionamiento en el elemento de red. El GMDR enva alarmas al servidor de backup cuando una alarma de notificacin se recibe desde el elemento de red. Para que funcione un backup impulsado por alarma cuando el GMDR se encuentra en una estacin de trabajo diferente que la del servidor de backup, hay que especificar la opcin gmdrhost para el servidor de backup. Emplee la interfaz de lnea de comando para especificar el host GMDR con la opcin gmdrhost como sigue:
/opt/MagellanNMS/bin/nsctlbck -notification gmdrhost <hostname>

ARCHIVOS DE CONFIGURACIN Y DE LOGS

config and log files

/opt/MagellanNMS/cfg/Controller.cfg when the providers are running on a different workstation than the providers. /opt/MagellanNMS/cfg/DataSync.cfg to configure backup on alarm /opt/MagellanNMS/cfg/bkRst.cfg GUI config, shared configuration $HOME/MagellanNMS/bkRst.cfg GUI config, user specific configuration

/opt/MagellanNMS/data/log/DataSync/ DBSync server logs /opt/MagellanNMS/data/log/bckRst/backup.dlog backup controller log /opt/MagellanNMS/data/log/bckRst/restore.dlog restore controller log The level of debug info is set by an option on command line: "-ll" Try "-h" option to see the possible level of debug. Alternatively, you can change the level of debugging by sending signal SIGUSR2 to the process. ex.: kill -17 13703 where 13703 is the pid of nsctlbck or nsctlrst /opt/MagellanNMS/data/log/journalBackup.log log for backup on alarm only. Overwritten each time "nsctlbck notification" is started. $HOME/MagellanNMS/bkRst.log GUI log

Referencias:
http://wiki.us.nortel.com/bin/view/MDM/BackupAndRestore#Backup_on_alarm