Cosas del curro

El sistema Multimedia Communication Server 5100 de Nortel es la plataforma de comunicaciones multimedia unificadas IP que esta empresa ha desarrollado conmuy buen resultado. Lo mejor de todo es que el protocolo utilizado es SIP, lo que ha cambiado sustancialmente la filosofía de la empresa y facilita enormemente la interoperabilidad con otros fabricantes (el ejemplo más claro es el uso de terminales SIP de otras marcas).

A mayores tiene otras ventajas, como su fácil (aunque esto debería ir entrecomillado) interacción con las centrales Nortel  CS1000 y CS2000…

La instalación del MCS 5100 no es demasiado compleja, lo que me ha sorprendido gratamente después de la experiencia de la central IP Communication Server 1000.

La estructura que hemos implementado en nuestro cliente es un Medium System, que consta de 4 servidores (no redundados) de core más varios servidores de aplicaciones (en nuestro caso 3 servidores más). El Small System consta de un único servidor de core, mientras que el Medium System redundado son 8 servidores.

El hardware está compuesto por 4 servers IBM xSeries 306m para el core y otros 3 servidores IBM xSeries 336 para las aplicaciones. Los servidores de core corren una distribución Red Hat Linux adaptada por Nortel con una instalación muy sencilla (ojo si vienen de fábrica, hay que crear el RAID1 antes de instalar) mientras los de aplicaciones traen un Windows 2000 preinstalado.

La instalación del Red Hat Linux es extremadamente simple, ya que los scripts aportados por Nortel lo convierten en un proceso casi automático.

Después viene la instalación del software apropiado a cada servidor del core (la base de datos Oracle, etc…) y finalmente su integración en el MCS. Por supuesto, el proceso requiere de los dichosos keycodes de Nortel que el proveedor habrá facilitado (un solo keycode para el core y un keycode para cada máquina de aplicaciones). Todo se hará con gran facilidad siguiendo los manuales de Nortel al efecto (eso sí, después de dar con el adecuado a cada caso…)

La parte más escabrosa del asunto viene después del installation & comisioning, el conocido como provisioning o, como le llamo yo, dar de alta a los usuarios de una vez… El quid del tema vienen por la regular documentación sobre este particular, ya que no me ha parecido para nada intuitiva.

La realización periódica de backups es de una importancia CAPITAL, y quien no los haga es un mal profesional. Pues yo soy un mal profesional…

Tenemos un sistema de comunicaciones unificadas Nortel MCS 5100 versión 4.0 instalado en un cliente (junto con una centralita Nortel CS1000E), pero sólo llevamos el mantenimiento correctivo, por lo que no nos preocupamos demasiado por los backups (¡gran error!) asumiendo que es el cliente quien debería realizar los mismos. A pesar de ello, y por las características del cliente, nos conectamos regularmente para realizar algunos backups, lo cual nos beneficiará a nosotros y, por supuesto, al cliente. Pero habíamos descuidado el MCS 5100 por ser un sistema supuestamente muy robusto y dando por hecho que los bakups estaban bien programados.

Nortel MCS 5100 v4.0

Pues ni los backups estaban programados ni el MCS 5100 es tan robusto: la versión 4.0 que hay instalada consta de siete servidores IBM, cuatro x306 Series con una versión de Red Hat Linux y otros tres x336 Series sobre MS Windows 2000 con las aplicaciones licenciadas. Pues ha empezado a fallar el hardware de uno de los IBM x306 Series, concretamente parece la controladora del RAID (todos los servers estón en RAID 1) que es una controladora software Adaptec está fallando, por lo que no arranca correctamente el SO o, en caso de arrancar, se bloquea a los dos minutos. El resultado es que con uno de los dos discos duros sí arrancaba, con lo que provisionalmente podíamos aguantar hasta que llegue el hardware de repuesto (Nortel nos enviará otro servidor) pero después de una semana ya no arranca ninguno de los dos discos duros.

Ahora viene el procedimiento para realizar el backup manual de los servidores IBM x306 (en todos):

• Nos identificamos como el usuario de operación (generalmente sysadmin)
• Lanzamos el script: sudo /usr/local/bin/mcp_backup.pl
• Respondemos Y a la primera pregunta y damos nombre al archivo en la segunda
• Cuando acabe podemos revisar el log en: /export/home/sysadmin/bkup_restore que debería tener el nombre mcp_backup.pl.log.YYYY_MM_DD_hh:mm:ss

Yo envío los backups a un servidor TFTP o me los descargo a mi PC con el programa WinSCP.

Ahora el backup manual del Oracle:

• Nos identificamos como usuario de operación (oracle)
• Cambiamos de directorio: cd /var/mcp/run/MCP_9.1/<db_name>/bin/util
• Lanzamos el script:  ./dbBackup.sh <dbUsername> <dbPassword> <backupName> <backupMedia>

<dbUsername> y <dbPassword> son los nombres definidos en installprops.txt
<backupName> es el nombre que le queramos dar al archivo
<backupMedia> es TAPE o DISK. Selecciona DISK.

• El backup se guarda en /var/mcp/backup/orabackup

Lo ideal seí­a que el backup de Oracle se dejase programado en la Oracle Enterprise Manager (OEM) Console (no tengo capturas porque no me funciona ningún usuario, es un problema…).

La documentación de Nortel indica que debemos hacer backup también de los accounting records a un servidor FTP (no estoy muy seguro de qué respalda este backup…):

• Nos identificamos como el usuario de operación (generalmente sysadmin)
• Nos ponemos como root: su y la password
• Cambiamos de directorio: cd /var/mcp
• Ejecutamos: backupBilling.sh <hostname> <username> <password>
  <destination directory>

<hostname> nombre o IP del servidor FTP
<username> usuario del FTP
<password> password del FTP
<destination directory> directorio de destino

Con esto habí­amos acabado los backups de los servidores Red Hat Linux del MCS 5100, ya que los backups de los Windows que contienen las aplicaciones de usuario se hacen de manera distinta (obviamente). La restauración de datos también se realiza por medio de scripts que facilitan la tarea.