Servidores:sofie:duplicar

Plan de contingencia

Al momento de renegar con un servidor que se murió, hay dos teorías:

 * la de restaurar el sistema a partir de una imagen
 * la de reinstalar el software en una PC distinta

La primera opción consiste en tener disponible una imagen del sistema para, en caso de emergencias, restaurarla en un nuevo equipo. Este enfoque tiene algunas ventajas, pero también tiene desventajas importantes:

^ Ventajas ^ Desventajas ^ | Menor tiempo de //downtime//, ya que la restauración de la imagen es automática | Requiere rehacer las imágenes periódicamente, lo cual es un problema en servidores con alta demanda | | Restauración del sistema a //exactamente// el mismo estado, con la misma configuración y los mismos archivos | Requiere que el hardware sea lo más idéntico posible, llegando en el caso del RAID a exigir //exactamente// los mismos discos |

La segunda alternativa consiste en realizar una reinstalación desde cero en un nuevo equipo, respetando los principales detalles de la configuración original. Esto, por supuesto, también tiene sus ventajas y desventajas

^ Ventajas ^ Desventajas ^ | Permite reemplazar un equipo por otro con un hardware radicalmente diferente | Mayor tiempo de recuperación del sistema en caso de emergencia | | No requiere mantenimiento más allá de los backups periódicos del servidor | Requiere reconstruir manualmente la configuración. Algunos detalles tienden a perderse, tales como la clave pública del SSH |

Teniendo en cuenta estas consideraciones, esto nos deja con los siguientes planes de acción posible para la recuperación del servidor Sofie y el sistema Mapuche

Plan 1: servidor gemelo

Un primer plan de contingencia consiste en mantener una réplica idéntica del servidor (mismo software, ambos con un sistema RAID autónomo propio) a modo de respaldo, de modo tal que el plan de emergencia consista en enchufar simplemente el servidor de rescate, restaurar las bases de datos, y listo. Este plan es muy eficiente en downtime (el tiempo de recuperación desde el momento en que se detecta el problema hasta que se soluciona se mide en minutos), pero altamente costoso, ya que requiere tener disponible (e inmóvil) un segundo servidor todo el tiempo.

Plan 2: imagen de disco

La segunda alternativa consiste en tener una imagen de disco disponible, con el objetivo de restaurarla en otro equipo en caso de emergencia. La diferencia entre este enfoque y el anterior consiste en no tener siempre a mano un segundo servidor, o bien utilizarlo para otra tarea (de baja prioridad) hasta que sea necesario. Este enfoque tiene dos complicaciones particulares. El primero, más sencillo, consiste en el problema del hardware distinto. A menos que el hardware sea //exactamente// igual, es de esperarse que ocurran conflictos, desde cosas simples como una desconfiguración del sonido hasta complicadas como rehacer un RAID y/o una falla de la placa de red. Un administrador podría solucionar estos problemas.

El segundo, en cambio, implica tener siempre disponible un equipo secundario similar. Si el equipo está disponible, pero sin utilizar, entonces la primera alternativa resulta más conveniente (ya que de todos modos no se va a utilizar, entonces es mejor tenerlo listo para andar). Si se va a utilizar para otra cosa, en cambio, no puede utilizarse para nada importante (ya que en cualquier momento puede ser necesario secuestrarlo), lo cual en el caso particular del servidor Sofie (8 GiB de RAM, 1 Tb de espacio en disco) habría que revisar con cuidado (no es descabellado pensar que el equipo termine funcionando como servidor improvisado de otro servicio)

Plan 3: reinstalación

La tercera y última alternativa consiste en tener copia de los datos principales (base de datos, programas y algunos archivos de configuración), y en caso de emergencia reinstalar un servidor desde cero, con un CD/DVD de instalación, y luego agregar el software necesario. Este plan tiene la ventaja de que se adapta a cualquier hardware (gracias a lo cual no requiere tomar previsiones en equipos), pero tiene la desventaja de tomar bastante tiempo (pasada la reinstalación, es preciso tener un listado del software a instalar). Este plan no requiere mantenimiento, y de hecho puede ser lo más recomendable si pasa mucho tiempo desde la última actualización del servidor original (es lo que ocurre actualmente con los servidores Pilaga - la versión del S.O. que utilizan está demasiado desactualizada como para migrarla a un servidor nuevo).

Recuperación del servidor original

Una vez que se levantó un servidor secundario para reemplazar al primero, es preciso determinar cómo volver a la vida el servidor original. Para ello, veremos cómo actuar en cada tipo de falla particular. Un punto importante: todos estos consejos son para el caso en que querramos seguir trabajando sobre el mismo equipo - si nuestro plan consiste en pasarnos a un segundo equipo, los pasos a seguir son distintos.

 * **Falla de memoria:** Basta con sacar el chip de memoria defectuoso y, si se desea, reemplazarlo. Cualquier chip con el cual el sistema arranque es suficiente.
 * **Falla de placa de video:** La placa de video actual está integrada con el motherboard, por lo que una falla de este tipo podría implicar problemas mayores. En cuanto al problema en sí, basta con instalar una placa de video VGA nueva (la más barata que haya) o, en última instancia, operar el sistema remotamente.
 * **Falla de placa de red:** Similar al caso anterior, con la diferencia de que esta vez ignorar el problema no es una solución. En general, debería alcanzar con la instalación de una nueva placa, aunque ciertos modelos pueden requerir algún módulo particular para funcionar.
 * **Falla de disco en RAID:** Cuando falla un disco del RAID, con el esquema actual (RAID 0), es preciso darlo de baja, reemplazarlo (o simplemente quitarlo) y luego regenerar el RAID. En este caso, es preciso guardar la configuración de la base de datos (directorio /etc/postgresql/), crear una nueva base en el directorio del RAID, restaurar la configuración y finalmente restaurar las tablas desde un backup.
 * **Falla de disco principal:** En caso de falla del sistema, es preciso hacer una reinstalación completa. La información necesaria para recuperar el Mapuche y las bases de datos se encuentra actualmente resguardada en el backup externo, pero el resto (servidores, servicios, etc) debe ser reinstalado desde cero.
 * **Falla de motherboard:** Ante un error de estos, levantar el disco original probablemente haga funcionar el sistema, pero es de esperarse que hayan conflictos de hardware. El RAID probablemente pueda levantarse manualmente. Cuanto más distinta sea la nueva motherboard, mayores serán estos problemas.
 * **Fallo de procesador:** Este tipo de fallas, al igual que el motherboard, pueden traer problemas colaterales imposibles de prever. Como regla general, cuanto más similar sea el nuevo procesador al anterior, menores serán los problemas a esperar.
 * **Fallo de fuente:** En caso de que la fuente tenga algún problema, basta con reemplazarla. Puede traer consecuencias para la motherboard, dependiendo de la razón de la falla en primer lugar.

Fallas menores

La falla de memoria y/o de una fuente que no daña otros componentes son las fallas más sencillas de solucionar - basta con reemplazar el componente original por cualquier otro - si la PC enciende, es más que suficiente. En el caso particular de la memoria, es posible incluso iniciar el servidor sin ese chip de memoria, ya que los restantes deberían ser suficientes.

Fallas moderadas

Las fallas moderadas son aquellas en las cuales se requiere algún tipo de atención al problema, pero que no representa un tiempo de baja importante. Este tipo de fallas se refieren a problemas con hardware que no es vital para el funcionamiento del servidor, o que pueden ser reemplazados muy fácilmente:

 * **Placa de video:** en caso de falla de una placa de video, conectar una segunda placa en algún slot disponible debería ser suficiente - la BIOS debería levantar la nueva placa, y de ahí en más el Sistema Operativo no debería tener ningún tipo de problema en continuar normalmente (dado que no utilizamos ninguna interfaz gráfica avanzada).
 * **Placa de red:** si bien una falla de la placa de red es crítica en el sentido de que corta el acceso al servicio, es un problema de fácil solución - todo lo que hay que hacer es reemplazar la placa, activarla desde el sistema operativo, y listo. Para activarla, es preciso seguir los pasos delineados en este enlace. FIXME

Fallas graves

Las fallas graves requieren intervención del administrador para salir adelante. Con el entrenamiento adecuado, sin embargo, pueden realizarse en un tiempo razonable.

 * **Falla de disco en RAID con redundancia:** cuando falla un disco en esta situación, es preciso destinar tiempo a recomponerlo (esto no tiene por qué ser inmediato, ya que el sistema va a seguir funcionando, pero cuanto antes mejor). En particular, será necesario remover el disco dañado y reemplazarlo por un nuevo, formateándolo e instalándolo en reemplazo del anterior (esta guía puede servir). Si bien no es obligación que el nuevo disco comparta las características físicas de los demás, esto es deseable para mejorar el rendimiento.
 * **Falla de disco en RAID 0:** en esta situación no será posible recuperar el RAID, por lo que habrá que recuperar los datos desde un backup externo. Para ello, será necesario:
   - detener el sistema (si el RAID tiene una falla es de esperarse que el servicio ya se encuentre cortado, por lo que esto no empeorará la situación)
   - hacer copia de seguridad de los archivos de configuración de PostgreSQL (ubicados en /etc/postgresql/8.3/main)
   - retirar el disco dañado
   - reemplazarlo (si se desea)
   - crear un nuevo RAID
   - crear una nueva Base de Datos en el nuevo RAID, y recuperar los datos desde un backup
   - restaurar los archivos de configuración 

Fallas críticas

Las fallas críticas son fallas que implican un downtime serio. Estas situaciones pueden preverse hasta cierto punto, pero aún así el tiempo necesario para solucionarlas va a ser importante.

 * **Falla de motherboard:** El primer paso será cambiar de motherboard. El caso ideal es con una placa de la misma serie y modelo, ya que cuanto más difiera la nueva placa de la anterior, mayores serán las posibilidades de encontrar incompatibilidades. A líneas generales es de esperar que el sistema arranque, pero es esperable encontrar fallas de todo tipo. Tal vez el principal problema sea acceder al RAID ya que, al cambiar los puertos SATA a los cuales están conectados los discos, es posible que cambie su nombre de dispositivo y, por ende, que el RAID no arranque. En este caso, será necesario regenerar el RAID o, con paciencia, cambiar la configuración hasta que funcione.
 * **Fallo de procesador:** similar al caso anterior, con la diferencia de que es más factible encontrarse con segfaults que otra cosa. Al igual que el caso anterior, es deseable conseguir un nuevo procesador lo más similar al anterior. Por motivos que resultarán obvios, cambiar de arquitectura (de 32 a 64 bits o viceversa) es altamente desaconsejado, y llevará al equipo técnico a morder el dedo gordo del pie a quien lo intente.
 * **Fallo de disco principal:** En caso de fallo del disco de sistema, la única alternativa es la reinstalación en un nuevo disco del SO o la restauración desde una imagen (la cual se espera que esté actualizada). En ambos casos, el proceso requerirá un trabajo considerable, ya que volver el sistema a su estado original es una tarea que demanda tiempo.