Mostrando entradas con la etiqueta RAID. Mostrar todas las entradas
Mostrando entradas con la etiqueta RAID. Mostrar todas las entradas

21 de noviembre de 2010

Mi mailbox ha regresado al “Big Bang”


Descripción del entorno
Lotus Notes es una aplicación que se clasifica dentro de la categoría de colaboración de grupos o equipos de trabajo.
En la empresa, en la cual empleo la mayor parte de mi tiempo, utiliza esta herramienta desde hace mogollón de años, aunque parece que a nadie le acabe de satisfacer, la herramienta sigue ahí y bien viva ya que se van pidiendo la implementación de nuevas funcionalidades sobre ella.

Nosotros, los del departamento de TI, tenemos que sufrir las constantes críticas de la mayor parte de los usuarios, incluyendo usuarios con potestad para impulsar un cambio (la dirección), pero este nunca llega, ya que aunque nosotros no somos unos fans de Notes, somos realistas y exponemos las realidades que hay cuando se nos dice “¿por que no ponemos Outlook?” (He dicho Outlook, porque para el usuario es Outlook y nada más, es decir Exchange no existe).
En resumen, el cambio nunca llega porque cuando empiezan a sonar los números, los que pagan ya se echan para tras, y eso que solo llegan a escuchar el dinero de adquisición de la licencia de Exchange, sin haber escuchado lo que cuesta otra herramienta que supla las funcionalidades que ofrece Notes y no Exchange, desarrollo de aplicaciones y BBDD de “negocio” y su migración.

En fin dentro de este berenjenal a nosotros nos toca lidiar con la administración de Notes y las constante insatisfacción y todo eso con una política, de puertas hacia dentro, de inversión mínima en TI.

Como de costumbre, el gran perjudicado en una insuficiente inversión en el importante ámbito actual de las TI, no se lo lleva el personal del departamento de TI que tenemos que plantarnos fuera de horarios para apagar fuegos, aprender de manera autodidacta y normalmente a base de “ostias”, etc., sino que se lo lleva los usuarios y sobre todo la continuidad de negocio de la empresa.

Regresando al “Big Bang”
Hace poco más de una semana, el servidor de Notes de Barcelona dejó de funcionar, al estropearse dos discos de un RAID 5, así que los datos se quedaron en el limbo, ya que no hay tiempo para mandar esos discos a un empresa de recuperación de datos, ya que el servidor se tiene que restablecer lo antes posible; el tema económico, ni lo menciono ya que no lo llegamos ni a consular, pero con la política de inversión mencionada anteriormente, se puede prever con cierta exactitud la respuesta.

La incidencia hasta aquí la normal, no hay disco hot spare, así que a reinstalar servidor y su servicio, después de cambiar los dos discos.

Lo que sucedió, es que ciertos usuarios no tenían una copia de su BBDD de correo, así que volvieron a “Big Bang”, buzón vacío y si tenías algo importante te las apañas para recuperar lo o continuas tu actividad sin esa información como puedas. He dicho ciertos usuarios, por otros si tenían una copia, ya que usan correo web y para eso necesitamos tener replicada su BBDD en otro servidor Notes, y casualidad o no, suele coincidir con el correo de los usuarios de mayor importancia (hablando en términos organizativos).

Restableciendo el servidor
Yo, que de administrar el Notes, sé lo del día a día, ya que el tiempo de la extendida jornada laboral, con el personal que somo en TI, no deja para estar jugando con los sistemas, e invertir en formación del personal de TI (y otros tantos departamentos, más bien casi todos a excepción uno y medio) no cabe en los presupuestos de la empresa; tuve que reinstalar un servidor de Notes entero y meterlo en el Domino existente, sin más ayuda hasta la fase de poner la guinda al pastel, ya que mi compañero no estaba localizable.

La verdad es que el Notes, as nivel de interfaz y de la lógica de ejecutar las acciones es rebuscado, de ahí su baja popularidad entre los usuarios, pero para administrarlo no lo es mucho, aunque la lógica de ejecución y realización de operaciones sobre él sigue siendo la misma, pero para los IT Pros no hay mucho problema ya que nos dedicamos a probar lo todo.

En resumen, la instalación del software, es un siguiente, siguiente, siguiente, … si no te encuentras que te falta algo como me pasó a mí. Como tenía que restaurar un servidor, necesitaba conseguir el ID (fichero de registro de los elementos registrados en el Domino: máquinas, servidores, etc.) del servidor antiguo y justo este ni estaba en el names (BBDD donde Domino gestiona todos los elementos registrados) y menos lo encontré perdido por algún directorio de los múltiples que tenemos en la empresa.
De tenerlo, creo que hubiese podido asociar esa nueva instalación al servidor ya registrado, pero al no ser así tuve que crear un nuevo servidor, al cual le puede poner el mismo nombre que antiguo, préviamente habiendo renombrado al antiguo, y no hizo falta mucho más para que el Domino continuara tratando el nuevo servidor como el servidor existente.

Evaluación
Finalmente la experiencia no ha estado más, ahora ya sé instalar un servidor Lotus Notes, añadirlo a un Domino existente, además de haber aprendido y encontrado múltiples herramientas y operaciones de administración que Lotus Notes tiene.
Para los usuarios y la continuidad de negocio, ha sido un mal menor, ser perdió poca información importante, al menos para la empresa, para el usuario que la ha perdido parece algo más importante, y como siempre, si se hubiese tenido una copia de seguridad en toda regla el impacto de perdida de información hubiese sido minúsculo, pero si no la hay, puedo constatar que es por falta de inversión en TI, no solo en máquinas (que si que hace falta) sino en aplicaciones y en recursos humanos.

Tengo previsto, espero que sea en un breve espacio de tiempo, escribir alguna entrada sobre algunas cosas que he descubierto de Lotus Notes, que me han sorprendido como funcionan, y que me han tenido perdiendo una parte del tiempo, ya que remendando por Internet, en Google y en la documentación de IBM, no logré encontrar, con el objetivo de que a alguien le puedan ser útiles.


Hasta la próxima enfermos.

10 de octubre de 2010

Gestionando incidencias de manera organizada (3/3)

conjuntoEntradas() {

Planificando la resolución
Asumiendo mi rol, por falta de la persona al cargo y por la poca experiencia de mi compañero, no sin motivos justificados, decidí invertir mi maravillo tiempo dentro de la jornada y fuera de él, a planificar la resolución de la incidencia, que se iba a atender al día siguiente y fuera de la jornada laboral para no entorpecer la actividad diaria de la empresa, después de saber que se tenía que restablecer el sistema por completo.

Como por motivos de productividad y disponibilidad no se podía atender el mismo día, yo tenía más tiempo de realizar una mejor planificación, más detallada, pensada y documentada. Así que pensé y evalué exhaustivamente la situación y de ahí saque un documento donde se detallaba lo sucedido, los sistemas afectados y el tiempo necesario para su restauración completa (debido al volumen de información), las actuaciones a realizar sobre los sistemas afectados indirectamente y la lista de acciones a llevar a cabo de manera correlativa.

Al plasmar todo esto en un documento, me permitió tener un mejor razonamiento de la situación y de sus resolución; además el documento iba a ser a la guía para hacer lo de manera metódica y no olvidarse de nada, dar un soporte a la explicación verbal mi compañero para que lo tuviese más claro y pudiese acudir en caso de duda, teniendo presente que la incidencia era en la oficina donde él estaba y que nos separaban unos 600 km y además tener un informe de la incidencia algo que nunca se ha hecho y que en situaciones futuras se puede llegar agradecer, como los planes de contingencia, que por cierto a falta de recursos, también son inexistentes.

Con todo lo que acabo de mencionar, creo que el tiempo invertido en crear el mencionado documento, ha sido de sobras, rentabilizado, además de la satisfacción de trabajar planificada y organizadamente, y más cuando algún miembro el equipo está desconcertado y con poco control de la situación.

Aquí os dejo un documento modelo del que realicé por si puede servir de algo.

Conclusiones
Las incidencias surgen cuando toca y es bastante complicado o prácticamente imposible predecir cuando van a suceder así que cuando más preparado estés, planes de contingencia, infraestructura de backups, copias de seguridad actualizadas de la información y de los sistemas críticos (configuraciones, parametrizaciones, etc.), sistemas hardware replicados y preparados para soportar posibles fallos, etc., y sobre todo cuando no hay un plan de acción para la situación o una situación que se lo asemeje y hay un margen temporal de reacción entonces piensa, razona y elabora un planning de como vas a abordar la resolución y restauración manteniendo el servicio los más disponible posible mientras actúas y si no eres un lobo solitario y tienes compañía, un equipo o un único compañero, explícale el planning y hazle participe en las situaciones que le implican directamente, si realmente quieres que “te eche un cable” y le ponga ganas al asunto.

Hasta la próxima enfermos.

6 de octubre de 2010

Gestionando incidencias de manera organizada (2/3)

conjuntoEntradas() {

Descripción de la incidencia
Durante la mañana se detecta que el servidor está offline; entonces se procede a verificar el motivo y se detecta que está en la pantalla justo antes de realizar el boot del sistema operativo.

Se revisa lo que sucede y desde la controladora SATA-RAID se detecta que dos discos están en estado offline, por lo que se prueba de forzar su estado a online y se revisa si el sistema operativos es capaz de arrancar. Por ahora aunque el indicativo es que el fallo es de dos disco, al encontrarlos en estado offline y no en estado fail puede que el fallo haya sido, aunque poco probable, por otra causa.

El sistema operativo arranca, por lo que el servicio esta de nuevo disponible. Tras arrancar se decide instalar un aplicación del fabricante que monitorea el estado del hardware, esto ya es un FAIL por no tenerlo instalado desde que el servidor se puso en producción. Con dicha aplicación se pueden lanzar test sobre el hardware, en este caso lo hicimos sobre los discos, y en el test se comprueba que un disco falla, así que se llega a la conclusión que el reinicio pudo ser algo puntual por fallo de un disco algo que siendo un RAID 5 no tendría porque haber sucedido, pero al arrancar sin problemas de nuevo, no da pie a pensar, después del test, que haya dos discos dañados.

Se tramita el cambio de disco con el fabricante y al día siguiente, antes de que empiece la jornada laboral, se reemplaza.

El servicio se levantó en menos de una hora y se mantuvo todo el día, pero al día siguiente después de haber reemplazado el disco, el servicio se vuelve a detener con los mismos síntomas; esta vez el disco que el día anterior había estado offline se encuentra en estado fail, no obstante se puede de nuevo levantar el servidor y con otro aplicación de diagnóstico se obtiene un estado del servidor en un fichero de log que tras el análisis por parte del fabricante se dictamina que el segundo disco también está averiado. Debido a que el fallo, se produjo en dos discos, se nos indica que hay que reinstalar todo el sistema de nuevo, ya que el error puede haberse propagado al resto del RAID y eso puede producir inestabilidades en el sistema.

Aquí es cuando para mí empieza el tratamiento de la incidencia de manera planificada, ya que hasta el momento ha sido acción-reacción ya que el problema estaba ahí y había que resolverlo lo antes posible y las circunstancias han permitido activar y mantener de nuevo el servicio y tener un margen acotado de tiempo para organizar como eliminar el problema definitivamente.

No me voy a alargar más explicando que es lo que se ve afectado por la caída de uno de los servidores de almacenamiento en una de las oficinas, ya que tendría que entrar en bastante detalle en el funcionamiento del sistema y no es el objetivo de esta serie de posts.

Información a los usuarios
Yo soy de los que prefiere estar informado de las cosas y vivir la realidad antes que vivir engañado pensando que todo es un jardín de rosas.

Esta es una de las cosas que yo he echado en falta desde que rondo por la empresa, siempre que pasa algo y en algunas ocasiones, se va hacer algo no se informa ni se advierte de nada a los usuarios. Sé que a veces esto puede ser contraproducente, por la idea que algunos se puedan hacer de la situación, pero creo que eso se soluciona dando un explicación con los mínimos tecnicismos que se pueda pero que te permita explicar de lo que sucede y como se va a solventar la incidencia, esto último es muy importante mencionarlo y como se dice para que no cunda el pánico.

Así que con el rol que tenía desde un primer momento decidí mantener a los usuarios informados para evitar, la sicosis de estos, ya que cuando lo que involucra la incidencia es información y encima la que está generando día día los empleados con su esfuerzo, es lo que le coge a todos, supongo que pensando las N horas extras sin remuneración que tendrán que hacer para restablecer el trabajo ya realizado.

Manteniendo los informados, también te evitas que te suene el teléfono cada 2 minutos, preguntando te que sucede y cuando va a estar solucionado además de escuchar, en algunos casos, despotricaciones varias; por lo que el tiempo que dedicas escribiendo el comunicado, creo que se rentabiliza, de manera lineal al número de usuarios afectados.

Además en este caso, también era necesario información que actividades podían desarrollar con normalidad y cuales no y como hacer un workarround mientras se solventaba la incidencia.

Hasta la próxima enfermos.

2 de octubre de 2010

Gestionando incidencias de manera organizada (1/3)

conjuntoEntradas() {

De que va esto
En esta serie de posts voy escribir una posible forma de gestionar de una manera más o menos organizada como se debería gestionar una incidencia en empresa de tamaño medio con menos personas en el departamento de TI de lo que realmente sería necesario, teniendo en cuenta que tampoco se contratan recursos externos (outsourcing y/o insourcing).
Antes de continuar con el tema a tratar quiero dejar claro que lo aquí descrito no tiene que ser lo estrictamente correcto y mucho menos la manera perfecta, todo se puede mejorar; ésta, ni de lejos, es la única vía para tratar incidencias, pero si, desde mi punto de vista, una manera ordenada, organizada y metódica de hacerlo, aunque el resto es libre de opinar de otro modo, y por mi parte lo respeto totalmente.
Porque ahora
Si ahora estoy escribiendo este conjunto de posts es porque antes de ir me de vacaciones, tuve que afrontar, en la empresa donde ahora trabajo, una incidencia; esta vez a diferencia de las demás tenía que asumir el rol de gestionar su resolución debido a que el responsable que lo tendría que hacer estaba gozando de sus merecidas vacaciones. En el pasado he participado en muchas otras pero siempre he tenido un papel de técnico que le indican que es lo que tiene que ir haciendo y como se tiene que coordinar con el resto del equipo y siempre he pensado, ya sea por la situación del departamento dentro de la empresa (no hay tiempo material dentro de la jornada laboral, con los recursos que somos para hacer las cosas bien) o por cualquier otro motivo, que, el orden, la coordinación y la metodología han sido inexistentes.

Todo esto quería publicarlo en el momento que pasó pero entre las vacaciones, el volumen de trabajo al regreso en la empresa en la cual trabajo y nuevos retos profesionales en modo freelance me ha obligado a retrasar su publicación.

Escenario organizativo
El escenario en el que se desarrollo la incidencia es el siguiente:
  • Empresa con unos 110 usuarios aproximadamente, de los cuales unos 80 trabajando en las tres oficinas que consta la empresa, el resto de vacaciones, de viaje de negocios o trabajan fuera por la actividad que están desarrollando.
  • Departamento de TI, o podríamos decir de mierdas varias, formado por 4 personas, 2 en la oficina de Madrid, 1 en Bilbao y el otro, yo, en Barcelona. Dadas las fechas, solo eramos dos, yo, y el recién incorporado y recién terminado un CGS de Administración de Sistemas, en Madrid.

Escenario tecnológico
La infraestructura de comunicación, la descrita en este post, pero ahora sin la cuarta oficina, Málaga, que la crisis ha obligado a cepillarse la.
Se utiliza el sistema DFS (Distributed File System), para mantener replicados en las 3 oficinas gran parte de los espacios de almacenamiento de documentos de trabajo, pero sin Share Point, usando un sistema de acceso desarrollado en la empresa para atacar los repositorios evitando accesos simultáneos a mismo fichero, sobre este punto, no hago manifestaciones, ya que no es el objetivo de este conjunto de posts.
Usamos 3 máquinas en cada oficina para el almacenamiento de la información, replicando se en malla por pares, es decir los 3 servidores de una oficina contienen información distinta, por lo que no se replican entre ellos, y se replican con sus 3 homólogos ubicados en las otras dos oficinas; y lo hacen las 24 horas y con todo el ancho de banda que la red les dé.

Sistema afectado
La incidencia fue originada por el fallo de dos discos montados en RAID 5 de uno de los 3 servidores de almacenamiento ubicado en la oficina de Madrid.

Hasta la próxima enfermos.

2 de junio de 2010

Conectando un disco de un RAID software de Windows 2000

Ayer en el curro tuvimos una incidencia con una de las máquinas que utilizamos como servidor de sistemas, es decir básicamente para almacenar software que instalamos en los equipos, almacenar alguna que otra documentación interna del departamento de TI y rodar ciertos software de tareas de mantenimiento de sistemas con un nivel de criticidad bajo o más bien nulo.

La incidencia básicamente se resumió en que el sistemas se fue colgando desde hacía unos días cada vez con mayor frecuencia hasta el punto que el tiempo de funcionando se redujo a menos de 8 horas, por lo que la prioridad de la incidencia aumentó, ya que con un intervalo de indisponibilidad inferior a 8 horas y en decrecimiento deja de ser operativa en toda regla.

El sistema operativo de esta máquina era un, prehistórico Windows 2000 Server; es lo que hay en un departamento con presupuesto bastante reducido y más aún en tiempos de crisis y con el estatus económico de España; la máquina tenía dos discos duros del mismo tamaño, los cuales en su día se tomó la decisión de crear un RAID 1 software sobre ellos con la propia herramienta integrada en Windows 2000 Server.

Una vez haber soltado el rollo del motivo de la incidencia y cual era el entorno de producción que nos interesa conocer para entender la situación, paso a explicar la fácil y rápida solución a esta historia que llegó a un punto que parecía que no iba a tener ese final feliz que si tuvo.

Para recuperar esa información durante el tiempo en que tardaremos en poner en marcha el nuevo entorno de producción, decidí pinchar ese disco en una de las máquinas, con Windows XP, que tenemos de backup como plan de contingencia de fallo de alguna de las workstation.

Al iniciar la máquina y ver que el disco a recuperar no se mapeao directamente en Mi PC como una unidad más, fui a la consola de "Administrador de discos" (Accesible a través de la consola de administración del equipo) y en ella me aparecía como que me detectaba el disco con "error" y otro disco inexistente que es el  otro que hace de espejo.

 Acceso a la consolad de administración de Windows XP

En este momento ya me estaba imaginando que recuperar el disco no sería tan sencillo, como pinchar lo y ya está, ya que aunque el formato fuera NTFS, es posible que el RAID software tuviese alguna que otra configuración que no siendo un Windows 2000 Server o un Windows Server de versión superior pudiese gestionar, es decir que desde un cliente Windows XP, no iba a poder recuperar lo de manera sencilla.

En ese momento antes de buscar otra máquina o algún software de recuperación, dando le un par de vueltas al asunto y mirando si desde la consola de administración de discos me daba alguna opción de recuperación,  se me ocurrió asignarle una letra a la unidad y ver que aunque lo marcase con error me dejase y después de eso ya veremos si se puede acceder o no.
El resultado fue satisfactorio, al asignarle una letra a la unidad del disco se  ha mapeado sin problema, totalmente accesible desde "Mi PC", como cualquier otro unidad y además el administrador de discos ha pasado de indicar como sistema de archivos "error" a indicar "NTFS"; así que la historia tuvo un final feliz y para otra vez ya sé que un disco que funciona como uno de los espejos de un RAID software de Windows 2000 se puede conectar a una máquina con un cliente Windows XP y siendo accesible como cualquier otra unidad.

 Administrador de discos de Windows XP

Como podemos ver en la imagen anterior el otro disco del espejo del RAID 1 aparece informado como que falta porque físicamente no esta. Podemos hacer que desaparezca de esa lista si no pensamos añadir el otro espejo, dando botón derecho sobre ese disco informado e indicando "Extraer", en el caso de querer activar el espejo sería, una vez conectado físicamente al equipo, la opción "Reactivar", pero esto último no lo he probado y no sé con toda certeza si funcionaría.

Hasta la próxima enfermos.