Cuando los buenos discos fallan

Previniendo y recuperándose de fallas de disco

Nunca se trata de si un disco va a fallar, sino de cuándo. Entonces, ¿qué hace cuando es despertado a las 2 de la mañana debido a errores en el sistema de archivos, LVM o SAN en un servidor de AIX de IBM? O, mejor aún, ¿cómo evita que lo despierten en primer lugar? Este artículo observa las estrategias para gestionar recursos de disco para maximizar la disponibilidad, el rendimiento y la redundancia y proporciona técnicas sobre cómo recuperarse de fallas cuando los buenos discos fallan.

Christian Pruett, Senior Systems Administrator, Freelance

Christian Pruett es un administrador sénior de sistemas de UNIX con más de 14 años de experiencia con AIX, Sun Solaris, Linux y HP/UX en una amplia variedad de industrias, incluyendo la computación, agricultura y telecomunicaciones. Es el co-autor de dos IBM Redbooks sobre AIX, ha servido como revisor de libro de UNIX para O’Reilly Publishing y ha trabajado en muchos de los exámenes de certificación de IBM AIX. Vive en Colorado con su esposa y sus dos hijos. Puede contactar a Christian escribiendo a pruettc@gmail.com.



05-03-2012

Introducción

Si ha estado haciendo administración de sistemas de IBM® AIX® o administración de SAN durante cualquier periodo de tiempo, probablemente esté íntimamente familiarizado con los errores de disco, problemas de sistema de archivos y fallas del Gestor de Volumen Lógico (LVM). ¿Qué debe hacer cuando surge una de estas situaciones? O, mejor aún, ¿cómo evita que sucedan en primer lugar?

Acrónimos de uso frecuente

  • E/S: Entrada/Salida
  • JFS: Journaled file system
  • LPAR: partición lógica
  • RAID: Conjunto redundante de discos independientes
  • SAN: Red de área de almacenamiento

Este artículo observa esas situaciones — cuando los buenos discos fallan. Comienza con una visión general de los errores de disco y su categorización. Después, se mueve hacia los conceptos de hardware y las formas de especificar la arquitectura de entornos bien diseñados y redundantes. A partir de ahí, discute soluciones para estar en esas situaciones cuando la crisis surge.


Categorizando errores de disco

Yo uso dos áreas principales para categorizar errores de disco en sistemas de AIX: impacto y duración. El Impacto mide la potencia de los errores de disco y cómo afectan a los servidores. En otras palabras, "¿Qué tanto va a doler esto?" La Duración mide la duración del tiempo o la persistencia de los errores de disco más la recuperación— o, "¿Durante cuánto tiempo va a doler esto?"

El impacto puede ser segmentado en cuatro niveles principales:

  • Pérdida de disponibilidad - Una pérdida de disponibilidad ocurre cuando los recursos de almacenamiento se vuelven offline o son desconectados de sus servidores gestionados. Los datos en los discos no son comprometidos, pero los discos no pueden ser accedidos. Los ejemplos incluyen sistemas de archivos siendo desmontados o adaptadores de Canal de Fibra siendo desconectados.
  • Pérdida de datos - Los datos no pueden ser escritos o leídos en un disco debido a un problema lógico o físico. Los ejemplos incluyen errores de escritura de LVM.
  • Pérdida de datos en múltiples discos - En esta instancia, no es sólo un disco en el que se ha encontrado una pérdida de datos, sino un número de discos. Esta situación normalmente ocurre cuando volúmenes lógicos son fragmentados en discos y uno falla.
  • Pérdida de datos en múltiples servidores - Con el uso generalizado de la tecnología de SAN, es posible que una sola pieza de hardware de disco sea comprometida hasta el punto en que los servidores son afectados con una pérdida de datos.

La duración también puede ser segmentada en cuatro niveles principales:

  • Temporal - Este tipo de error de disco es el extraño, un hipo de una sola vez que no representa ninguna amenaza. Se muestra una vez en el recurso errpt del servidor y después se va. Los ejemplos incluyen una mala reasignación de bloqueo.
  • Intermitente - Los errores intermitentes se muestran con una base irregular y pueden ser un indicativo de un problema naciente, como cuando un disco duro registra una serie de errores de escritura, mostrando que la unidad puede fallar.
  • Regular - Como si fuera planificado por un trabajo de cron mismo, los problemas que ocurren con un intervalo semanal, diario, cada hora o minuto a minuto presentan un riesgo serio para los servidores y pueden tener efectos de detrimento generalizados.
  • Permanente - No hay una forma sencilla o factible para regresar de este tipo de error. Además de sustituir el hardware, no puede recuperarse de esta situación.

Al referencia estas dos medidas en una tabla, puede obtener una buena idea d qué tan crítico es el error de disco y cómo puede afectar al servidor. La Figura 1 proporciona un ejemplo de dicha tabla.

Figura 1. Impacto de referencia y duración de los errores de disco
Impacto de referencia y duración de los errores de disco

La Figura 1 muestra una tabla de cuatro por cuatro. Las columnas representan la duración de un problema, incrementando en el tiempo de izquierda a derecha. Las filas representan el impacto de un problema, incrementando en la severidad del fondo a la parte superior. Las celdas en la tabla están coloreadas por código junto con el espectro, moviéndose de azul y verde en la parte inferior izquierda, indicando menos grados de problemas (como pérdida temporal de disponibilidad) a naranja y rojo en la esquina superior derecha (indicando un mayor grado de problema tal como una pérdida permanente de datos en múltiples servidores).

En mi experiencia, cualquier cosa más allá del área verde es un problema severo y serio y muy probablemente causará pérdida de productividad o empresarial. Sólo he visto unas pocas instancias en las que los servidores han llegado hasta las áreas amarillas, y con ellas llegaron consecuencias drásticas.


Medidas preventivas

Nunca se trata de si ocurrirá una falla de disco, sino más bien es una cuestión de cuándo sucederá. Ningún disco ha sido jamás garantizado para funcionar indefinidamente. La meta de cualquier buen administrador de sistemas es evitar ser una víctima del tiempo entre el valor de falla del hardware y encontrar una forma de mitigar el riesgo de una falla de disco.

Los tres objetivos principales para cualquier administrador de AIX o SAN son maximizar la disponibilidad, el rendimiento y la redundancia. Usted querrá que su entorno de almacenamiento esté disponible—para asegurar que los datos puedan ser accedidos on-demand y para asegurar que haya suficiente espacio en disco para contener todos los datos. El disco debe tener un buen rendimiento, de forma que las aplicaciones no sean retrasadas por ninguna espera de E/S. Y el disco necesita tener redundancia, de forma que una falla de recursos no perjudique la capacidad de funcionamiento del servidor.

Normalmente, cada maximización tiene una compensación con al menos una de las otras áreas. Un entorno de almacenamiento que maximice la disponibilidad y el rendimiento normalmente deja de tener un gran nivel de redundancia, ya que los recursos del disco están optimizados para velocidad y para usar hasta el último byte disponible. Uno que se enfoque en la disponibilidad y redundancia probablemente tendrá lecturas y escrituras más lentas, ya que el objetivo es la estabilidad a largo plazo. Y una solución que es fuerte en rendimiento y redundancia requiere más espacio para obtener esas altas E/S y duplicarse en lecturas y escrituras, reduciendo la disponibilidad en términos de cuánto espacio está disponible.

Con AIX, hay formas más prácticas de poner medidas preventivas en su lugar. Estos son algunos conceptos generales que todo administrador debe saber:

  • Evite los puntos individuales de falla. Nunca, nunca construya un entorno donde la pérdida de un recurso solitario perjudicaría el entorno. Dicha arquitectura incluiría un solo disco duro, un solo adaptador de Canal de Fibra o una sola fuente de poder para cualquier pieza o equipo. Inevitablemente, ese recurso morirá en el momento más inoportuno.
  • La tecnología de RAID es una excelente forma de maximizar los recursos. Hace muchos años, ingenieros desarrollaron una forma de recolectar dispositivos de almacenamiento económicos en largas agrupaciones mediante la tecnología de RAID. AIX tiene muchos niveles de tecnología de RAID incorporados sin costo adicional: estas tecnologías pueden ser empleadas a nivel de software, tal como fragmentado (RAID 0) y duplicando (RAID 1). Dependiendo del tipo de subsistema de disco en uso, otras opciones pueden estar disponibles, como fragmentar con paridad (RAID 5), fragmentar duplicados (RAID 0 + 1) o duplicados fragmentados (RAID 1 + 0/RAID 10).
  • Uso efectivo de estrategias de LVM para segregar datos. El peor error que un administrador puede hacer es poner todos los recursos del servidor — sistema operativo, aplicaciones de terceros, espacio de paginación y datos de aplicación — dentro de un solo grupo de volumen. Hacer esto tiene todo tipo de malas consecuencias, incluyendo un pobre rendimiento, copias de seguridad de sistema masivas, gestión en deterioro y aumentar las posibilidades de una falla. Cada faceta del servidor debe ser evaluada, aislada y puesta en su propio grupo de volumen y tipo de almacenamiento. Por ejemplo, un servidor de base de datos grande puede estar diseñado para tener discos de rootvg duplicados internos, almacenamiento de SAN para almacenamiento de aplicaciones y espacio de paginación y algunos discos en estado sólido para registro de archivos y transacciones de altas E/S.

Observemos estrategias para diversos tipos de almacenamiento usados en servidores de AIX.

Discos duros internos

La forma más común de almacenamiento en AIX, los discos duros internos son normalmente usados para discos y servidores de grupo de volumen de raíz con huellas más pequeñas. Al usar discos duros internos, el primer paso siempre debe ser tener al menos dos discos por grupo de volumen y duplicar los discos duros con el comando mirrorvg . Si el servidor está en una máquina grande de IBM System p® , elija los discos a través de múltiples gavetas de rack para maximizar la redundancia en caso de que una pieza de hardware como una placa posterior falle. También, para optimizar el rendimiento, es una buena idea examinar el diseño de los volúmenes lógicos en el disco con los comandos lspv –l y lspv –p para mantener áreas de E/S más altas en el límite exterior de los discos y los volúmenes lógicos contiguos.

Almacenamiento de SAN pequeño

Subsistemas de almacenamiento más pequeños, como las gavetas de rack de disco de IBM FAStT directamente acopladas o tecnología de SAN pequeña más antigua, son soluciones costeables para entornos en los cuales se necesita más que espacio de disco interno para alojar grandes cantidades de datos. Para estas situaciones, es importante gestionar íntimamente la configuración del entorno, ya que puede haber algunos puntos individuales de falla en el camino. El almacenamiento debe estar optimizado con una configuración de RAID apropiada, tal como una configuración de RAID 5 con un disco de repuesto en caliente. Debe haber dos adaptadores que puedan acceder a la gaveta de rack para mantener la disponibilidad y redundancia en el lado del servidor. Y los controladores de software apropiados, como E/S de ruta múltiple o un módulo de control de ruta del controlador del dispositivo del subsistema, deben estar instalados y actualizados para que los discos sean presentados claramente para el servidor.

Almacenamiento de SAN grande

En entornos de almacenamiento de SAN más grande, donde múltiples servidores estén accediendo a un número de dispositivos de almacenamiento, tales como dispositivos DS8300 de IBM System Storage® , mediante conmutadores de clase de director, normalmente hay administradores de SAN dedicados que gestionan los recursos en disco. Pero desde una perspectiva de AIX, los administradores de sistemas pueden ayudar al hacer cosas como elegir múltiples tarjetas de Canal de Fibra de puerto dual para comunicarse con distintos tejidos y mejorar el rendimiento. Si la tecnología de optimización de infraestructura virtual (VIO) está en uso, N_Port ID virtualization (NPIV) puede permitir que múltiples servidores con necesidades de E/S más bajas se comuniquen mediante el mismo adaptador, reduciendo el número de ranuras asignadas a LPARs. La tecnología de arranque de SAN proporciona tiempos extremadamente rápidos de compilación y arranque para LPARs, especialmente cuando se hace con Network Installation Manager (NIM).


Etapas de recuperación

Los efectos de una falla de disco pueden variar de una interrupción ligera a una falla completa del servidor. Entonces, ¿qué hace cuando encuentra una falla?

La primera etapa es verificar la accesibilidad de los recursos del disco, comenzando con el nivel más alto disponible y moviéndose hacia abajo, usando errpt como una guía cuando sea posible. Si el servidor sigue funcionando, ¿los sistemas de archivos siguen montados cuando son vistos con un comando df o mount ? Si no es así, ¿el grupo de volumen es accesible con lsvg o varyonvg o ha perdido quórum? ¿Los discos mismos siguen en un estado de Disponibles o un lsdev –Ccdisk los muestra estando en un estado de Definidos? ¿Comandos de almacenamiento de SAN como lspath o pcmpath query adapter muestran que los dispositivos de Canal de Fibra están offline o que faltan? ¿El servidor está simplemente inactivo y sentado en un estado de No Activado cuando es visto mediante la Consola de Gestión de Hardware? ¿O la máquina de System p más grande o el subsistema de SAN están encendidos? Nunca asuma que simplemente porque un tipo de recurso es accesible, todos los recursos similares serán accesibles, así que sea meticuloso en su investigación.

La segunda etapa es verificar la integridad de los recursos, comenzando con el nivel más bajo disponible y moviéndose hacia arriba. ¿Su servidor se reinició con éxito o hubieron errores como el sistema iniciado, como mensajes de LED colgando con números como 552, 554 o 556 (sistemas de archivos corruptos, JFS o Gestor de Datos de Objeto [ODM])? Si el sistema está funcionando, ¿los recursos de discos vuelven a estar online en el estado de Disponible si ejecuta el comando cfgmgr ? ¿Los grupos de volumen pueden ser activados con un comando varyonvg ? ¿Los sistemas de archivos se montan con limpieza? ¿Los datos que espera ver están presentes dentro de los sistemas de archivos, o faltan los archivos?

La tercera etapa es corregir los problemas con los recursos en una base de caso por caso. Aquí están algunos consejos que he usado con el paso de los años para corregir problemas:

  • Sistemas de archivos. En mi experiencia, este es el tipo más común de error de disco que hay. No se requiere de mucho para hacer un superbloqueo sucio, causar una fragmentación, estropear inodes o causar errores de JFS repetidos en el errpt. Aún un sistema de archivos completo puede estropear las cosas. Y la mejor estrategia para corregir problemas del sistema de archivos es la más simple: el comando de verificación del sistema de archivos (fsck). En estas situaciones, yo desmonto los sistemas de archivos y ejecuto fsck –y en ellos hasta que regresan sin errores antes de montarlos de nuevo. Algunas veces, seré extra meticuloso para desmontar todos los sistemas de archivos en un grupo de volumen y hacer esto con un bucle pequeño en un script de shell en caso de que haya un problema latente.
  • Grupos de volumen. Cuando el problema excede el dominio del sistema de archivos, frecuentemente va al nivel de grupo de volumen. Algunas veces, el problema está al nivel de ODM y puede ser corregido con un syncvg o synclvodm. En un apuro, he desactivado los grupos de volumen con varyoffvg, los he exportado con exportvg, después los he re-importado con importvg para reorganizarlos apropiadamente. Pero siempre hago una copia de seguridad del archivo /etc/filesystems y registro los IDs de VLAN de puerto (PVID) con anticipación para preservar el orden de montaje.
  • Volúmenes físicos. Hablando de PVIDs, he visto discos que se pierden y después regresan en el servidor con PVIDs distintos. Ayuda registrar la información de disco en algún otro lugar periódicamente para comparación en caso de que ocurra tal cosa. Cuando ocurre, normalmente suprimo los discos del servidor con rmdev –dl, los vuelvo a detectar con cfgmgr y después exporto y vuelvo a importar el grupo de volumen.
  • Conexiones de SAN. Hay ocasiones en que los números de todo el mundo (WWN) no están comunicados de punta a punta a través del tejido de SAN, como con los servidores de NPIV o VIO. Algunas veces inhabilito los adaptadores de Canal de Fibra al ejecutar pcmpath set adapter offline, defino o verifico los WWNs manualmente y después vuelvo a activar el adaptador. También he tenido que ir a los extremos de perseguir cables y verificar las luces en el otro extremo para asegurarme de que no existe un problema físico.
  • Problemas de arranque. Si está intentando determinar por qué un servidor no arranca después de una falla de disco, lo primero que normalmente hago es dejar de correlacionar o desconectar todos los discos del servidor, excepto el grupo de volumen de raíz. Puede tomarle al Sistema de Gestión de Software (SMS) una cantidad de tiempo considerable para arrancar si tiene que analizar cientos de discos al intentar encontrar el disco o los discos de rootvg . Yo arranco el sistema desde un servidor de NIM en modo de mantenimiento para ejecutar la clasificación y corregir los sistemas de archivos, recreo el volumen lógico de arranque con el comando bosboot o acceso al grupo de volumen de raíz para corregir archivos de configuración como /etc/filesystems. También, después de que el servidor se activa, los sistemas de archivos que tienen problemas son normalmente aquellos que están en un estado cerrado mientras que los otros a su alrededor se montaron bien.
  • Recuperación. Finalmente, cuando algo no funciona y realmente necesita ser arreglado, asegúrese de que las partes que se están intercambiando sean tan semejantes al equipamiento original como sea posible. De esta manera, minimiza la necesidad de manipular cosas como los tamaños del sistema de archivos o los controladores de software que pueden complicar el tiempo requerido para que las cosas estén funcionando de nuevo. Yo siempre recomiendo hacer buenas copias de seguridad del sistema—de ambas imágenes de mksysb y usar productos como IBM Tivoli® Storage Manager—para aquellas ocasiones en que los datos se pierdan y no puedan ser recuperados en el peor de los casos.

Conclusión

La mejor forma de evitar el impacto y la duración de los problemas cuando los buenos discos fallan es no ser reactivo a los problemas cuando ocurren, sino maximizar la disponibilidad, el rendimiento y la redundancia en sus entornos de AIX para prevenir que los errores sucedan en primer lugar. Pero cuando ocurren — porque las fallas son inevitables—valide su accesibilidad e integridad y elabore un plan incremental para corregirlos y hacer que su servidor funcione completamente una vez más.

Recursos

Aprender

Obtener los productos y tecnologías

  • Pruebe el software de IBM gratis. Descargue una versión de prueba, regístrese en una prueba online, trabaje con un producto en un entorno de recinto de seguridad o accédalo a través de la nube. Elija de entre más de 100 productos de prueba de IBM.

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Linux
ArticleID=799371
ArticleTitle=Cuando los buenos discos fallan
publish-date=03052012