rhel-isa-es

Red Hat Enterprise Linux 4

Introducción a la administraciónde sistemas

Red Hat Enterprise Linux 4: Introducción a la administración de sistemas Copyright © 2005 por Red Hat, Inc.

Red Hat, Inc.

1801 Varsity Drive Raleigh NC 27606-2072USA Teléfono: +1 919 754 3700 Teléfono: 888 733 4281 Fax: +1 919 754 3701 PO Box 13588 Research Triangle Park NC 27709 USA

rhel-isa(ES)-4-Print-RHI (2004-08-25T17:11)Copyright © 2005 por Red Hat, Inc. Este material solamente se distribuye bajo los términos y condiciones establecidas en laOpen Publication License, V1.0 o versiones posteriores (la última versión está disponible enhttp://www.opencontent.org/openpub/).Los derechos de autor del propietario prohiben la distribución de versiones de este documento sustancialmente modificadassin un permiso explícito.La distribución del producto o una copia del mismo en forma de libro con fines comerciales está prohibida a menos que seobtenga permiso previo del propietario de los derechos de autor.Red Hat y el logo "Shadow Man" de Red Hat, son marcas registradas de Red Hat, Inc. en los Estados Unidos y otros países.Todas las demás marcas referenciadas aquí son propiedad de sus respectivos dueños.La marca de GPG de la clave [email protected] es:CA 20 86 86 2B D6 9D FC 65 F6 EC C4 21 91 80 CD DB 42 A6 0E

Tabla de contenidos Introducción ......................................................................................................................................... i

1. Información específica a la arquitectura ................................................................................ i2. Convenciones del documento ............................................................................................... ii3. Active su suscripción ........................................................................................................... iv

3.1. Proporcione un nombre de conexión a Red Hat .................................................... v3.2. Proporcione su número de suscripción .................................................................. v3.3. Conecte su sistema................................................................................................. v

4. ...y hay más ........................................................................................................................... v4.1. Envíenos sus comentarios ..................................................................................... vi

1. Filosofía de la Administración de Sistemas .................................................................................. 1

1.1. Automatizar todo ............................................................................................................... 11.2. Documentar todo................................................................................................................ 21.3. Comunique tanto como sea posible ................................................................................... 3

1.3.1. Informe a sus usuarios sobre lo que va a hacer................................................... 31.3.2. Informe a sus usuarios sobre lo que está haciendo ............................................. 41.3.3. Informe a sus usuarios sobre lo que ha hecho..................................................... 5

1.4. Conozca sus recursos ......................................................................................................... 61.5. Conozca a sus usuarios ...................................................................................................... 61.6. Conozca su negocio ........................................................................................................... 61.7. La seguridad no puede ser una ocurrencia posterior.......................................................... 7

1.7.1. Los riesgos de Ingeniería Social ......................................................................... 71.8. Planifique ........................................................................................................................... 81.9. Espere lo inesperado .......................................................................................................... 81.10. Información específica a Red Hat Enterprise Linux ........................................................ 9

1.10.1. Automatización................................................................................................. 91.10.2. Documentación y comunicación..................................................................... 101.10.3. Seguridad ........................................................................................................ 10

1.11. Recursos adicionales...................................................................................................... 111.11.1. Documentación instalada ................................................................................ 111.11.2. Sitios web de utilidad...................................................................................... 121.11.3. Libros relacionados......................................................................................... 12

2. Supervisión de recursos ................................................................................................................ 15

2.1. Conceptos básicos............................................................................................................ 152.2. Monitorizar el rendimiento del sistema ........................................................................... 152.3. Monitorizar la capacidad del sistema............................................................................... 162.4. ¿Qué monitorizar?............................................................................................................ 16

2.4.1. Monitorizar el poder de CPU............................................................................ 172.4.2. Monitorizar el ancho de banda.......................................................................... 182.4.3. Monitorizar la memoria .................................................................................... 192.4.4. Monitorizar el almacenamiento ........................................................................ 19

2.5. Información específica a Red Hat Enterprise Linux ........................................................ 202.5.1. free .................................................................................................................. 202.5.2. top .................................................................................................................... 212.5.3. vmstat.............................................................................................................. 232.5.4. Las herramientas para monitorizar recursos de la suite Sysstat........................ 242.5.5. OProfile ............................................................................................................. 27

2.6. Recursos adicionales........................................................................................................ 312.6.1. Documentación instalada .................................................................................. 312.6.2. Sitios Web útiles ............................................................................................... 322.6.3. Libros relacionados........................................................................................... 32

3. Ancho de banda y poder de procesamiento................................................................................ 33

3.1. Ancho de banda................................................................................................................ 333.1.1. Buses ................................................................................................................. 333.1.2. Datapaths........................................................................................................... 343.1.3. Problemas potenciales relacionados al ancho de banda.................................... 343.1.4. Soluciones potenciales relacionadas al ancho de banda ................................... 353.1.5. En resumen. . . ................................................................................................... 35

3.2. Poder de procesamiento ................................................................................................... 363.2.1. Hechos sobre el poder de procesamiento.......................................................... 363.2.2. Consumidores de poder de procesamiento ....................................................... 363.2.3. Mejorando la escasez de CPU........................................................................... 37

3.3. Información específica a Red Hat Enterprise Linux ........................................................ 403.3.1. Monitorizar el ancho de banda en Red Hat Enterprise Linux........................... 403.3.2. Monitorizar la utilización del CPU en Red Hat Enterprise Linux .................... 42

3.4. Recursos adicionales........................................................................................................ 463.4.1. Documentación instalada .................................................................................. 463.4.2. Sitios Web útiles ............................................................................................... 463.4.3. Libros relacionados........................................................................................... 46

4. Memoria física y virtual ............................................................................................................... 49

4.1. Patrones de acceso a almacenamiento ............................................................................. 494.2. El espectro de almacenamiento........................................................................................ 49

4.2.1. Registros de CPU.............................................................................................. 504.2.2. Memoria caché.................................................................................................. 504.2.3. Memoria principal — RAM.............................................................................. 514.2.4. Discos duros...................................................................................................... 524.2.5. Almacenamiento para respaldos fuera de línea ................................................ 53

4.3. Conceptos básicos sobre Memoria Virtual ...................................................................... 534.3.1. La memoria virtual en términos sencillos......................................................... 544.3.2. Almacenamiento de respaldo — el Tenet central de la memoria virtual .......... 55

4.4. La memoria virtual: los detalles....................................................................................... 554.4.1. Fallos de página ................................................................................................ 564.4.2. El conjunto de direcciones de trabajo ............................................................... 564.4.3. Intercambio ....................................................................................................... 57

4.5. Implicaciones de rendimiento de la memoria virtual....................................................... 574.5.1. Escenario de rendimiento del peor caso............................................................ 574.5.2. Escenario de rendimiento del mejor caso ......................................................... 58

4.6. Información específica de Red Hat Enterprise Linux ...................................................... 584.7. Recursos adicionales........................................................................................................ 61

4.7.1. Documentación instalada .................................................................................. 614.7.2. Sitios web de utilidad........................................................................................ 614.7.3. Libros relacionados........................................................................................... 61

5. Administración del Almacenamiento.......................................................................................... 63

5.1. Una vista general del hardware de almacenamiento........................................................ 635.1.1. Platos de discos ................................................................................................. 635.1.2. Dispositivo de lectura/escritura de datos .......................................................... 635.1.3. Brazos de acceso ............................................................................................... 64

5.2. Conceptos de direcciones de almacenamiento................................................................. 655.2.1. Direcciones basadas en la geometría ................................................................ 655.2.2. Direcciones basadas en bloques........................................................................ 67

5.3. Interfaces de dispositivos de almacenamiento masivo..................................................... 675.3.1. Antecedentes históricos .................................................................................... 675.3.2. Interfaces de hoy día con estándares de la industria ......................................... 68

5.4. Características de rendimiento del disco duro ................................................................. 715.4.1. Limitaciones mecánicas/eléctricas.................................................................... 715.4.2. Cargas y rendimiento de E/S............................................................................. 73

5.5. Preparar el almacenamiento para ser utilizado ................................................................ 745.5.1. Particiones/cuotas ............................................................................................. 745.5.2. Sistemas de archivos ......................................................................................... 765.5.3. Estructura del directorio.................................................................................... 785.5.4. Activando el acceso al almacenamiento ........................................................... 79

5.6. Tecnologías avanzadas de almacenamiento ..................................................................... 795.6.1. Almacenamiento accesible a través de la red ................................................... 795.6.2. Almacenamiento basado en RAID.................................................................... 805.6.3. Administración de Volúmenes Lógicos ............................................................ 85

5.7. La administración del almacenamiento día a día............................................................. 875.7.1. Monitorizar el espacio libre .............................................................................. 875.7.2. Problemas de cuotas de usuarios....................................................................... 905.7.3. Problemas relacionados a archivos ................................................................... 905.7.4. Añadir/Eliminar almacenamiento ..................................................................... 92

5.8. Un comentario sobre Respaldos....................................................................................... 985.9. Documentación específica a Red Hat Enterprise Linux .................................................. 98

5.9.1. Convenciones de nombres de dispositivos........................................................ 985.9.2. Conceptos básicos de sistemas de archivos .................................................... 1005.9.3. Montaje de Sistemas de Archivos ................................................................... 1025.9.4. Almacenamiento accesible desde la red bajo Red Hat Enterprise Linux ....... 1055.9.5. Montar sistemas de archivos automáticamente con /etc/fstab ................. 1065.9.6. Añadir/Eliminar almacenamiento ................................................................... 1075.9.7. Implementación de Cuotas de Disco............................................................... 1115.9.8. Creación de Formaciones RAID..................................................................... 1155.9.9. Administración día a día de las formaciones RAID ....................................... 1165.9.10. Administración de Volúmenes Lógicos ........................................................ 118

5.10. Recursos adicionales.................................................................................................... 1185.10.1. Documentación instalada .............................................................................. 1185.10.2. Sitios Web de utilidad ................................................................................... 1195.10.3. Libros relacionados....................................................................................... 119

6. Administración de cuentas de usuarios y acceso a recursos ................................................... 121

6.1. Administración de cuentas de usuarios.......................................................................... 1216.1.1. El nombre de usuario ...................................................................................... 1216.1.2. Contraseñas ..................................................................................................... 1246.1.3. Información de control de acceso ................................................................... 1286.1.4. Administración día a día de cuentas y acceso a recursos................................ 129

6.2. Administración de recursos de usuarios ........................................................................ 1316.2.1. ¿Quién puede acceder a los datos compartidos?............................................. 1316.2.2. ¿Donde los usuarios acceden a los datos compartidos?.................................. 1326.2.3. ¿Qué barreras se colocan para prevenir el abuso de los recursos?.................. 133

6.3. Información específica a Red Hat Enterprise Linux ...................................................... 1336.3.1. Cuentas de usuarios, Grupos y Permisos ........................................................ 1336.3.2. Archivos que controlan Cuentas de Usuarios y Grupos ................................. 1356.3.3. Aplicaciones para Cuentas de Usuarios y Grupos .......................................... 139

6.4. Recursos adicionales...................................................................................................... 1416.4.1. Documentación instalada ................................................................................ 1416.4.2. Sitios Web de utilidad ..................................................................................... 1416.4.3. Libros relacionados......................................................................................... 142

7. Impresoras e impresión .............................................................................................................. 143

7.1. Tipos de impresoras ....................................................................................................... 1437.1.1. Consideraciones de impresión ........................................................................ 143

7.2. Impresoras de impacto ................................................................................................... 1447.2.1. Impresoras de matriz de puntos ...................................................................... 1457.2.2. Impresoras margarita ...................................................................................... 1457.2.3. Impresoras en línea ......................................................................................... 1457.2.4. Consumibles para las impresoras de impacto ................................................. 145

7.3. Impresoras de inyección de tinta.................................................................................... 1467.3.1. Consumibles de inyección de tinta ................................................................. 146

7.4. Impresoras láser ............................................................................................................. 1477.4.1. Impresoras a color láser .................................................................................. 1477.4.2. Consumibles para impresoras láser................................................................. 147

7.5. Otros tipos de impresoras............................................................................................... 1487.6. Lenguajes y tecnologías de impresión ........................................................................... 1487.7. Impresión de red Versus Impresión local....................................................................... 1497.8. Información específica de Red Hat Enterprise Linux .................................................... 1497.9. Recursos adicionales...................................................................................................... 151

7.9.1. Documentación instalada ................................................................................ 1517.9.2. Sitios web de utilidad...................................................................................... 1517.9.3. Libros relacionados......................................................................................... 151

8. Planificación para Desastres ...................................................................................................... 153

8.1. Tipos de desastre............................................................................................................ 1538.1.1. Fallas del hardware ......................................................................................... 1538.1.2. Fallas del software .......................................................................................... 1598.1.3. Fallas ambientales ........................................................................................... 1618.1.4. Errores humanos ............................................................................................. 167

8.2. Respaldos ....................................................................................................................... 1728.2.1. Datos diferentes: Necesidades de respaldos diferentes................................... 1728.2.2. Software de respaldos: Comprar contra Construir.......................................... 1738.2.3. Tipos de respaldo ............................................................................................ 1748.2.4. Media de respaldo ........................................................................................... 1768.2.5. Almacenamiento de las copias de seguridad o respaldos ............................... 1778.2.6. Problemas de restauración .............................................................................. 178

8.3. Recuperación de desastres ............................................................................................. 1798.3.1. Creación, Evaluación e Implementación de un Plan de Recuperación de

Desastres ....................................................................................................... 1798.3.2. Sitios de respaldo: frío, templado y caliente................................................... 1808.3.3. Disponibilidad del Hardware y Software........................................................ 1818.3.4. Disponibilidad de los respaldos ...................................................................... 1828.3.5. Conectividad de red al sitio de respaldo ......................................................... 1828.3.6. Personal del sitio de respaldo.......................................................................... 1828.3.7. Regreso a la normalidad.................................................................................. 183

8.4. Información específica a Red Hat Enterprise Linux ...................................................... 1838.4.1. Soporte de Software........................................................................................ 1838.4.2. Tecnologías de respaldo.................................................................................. 183

8.5. Recursos adicionales...................................................................................................... 1878.5.1. Documentación instalada ................................................................................ 1878.5.2. Sitios Web de utilidad ..................................................................................... 1878.5.3. Libros relacionados......................................................................................... 187

Índice................................................................................................................................................ 189

Colofón............................................................................................................................................. 197

Introducción

Bienvenidos a Introducción a la administración de sistemas de Red Hat Enterprise Linux.

El libro Introducción a la administración de sistemas de Red Hat Enterprise Linux contiene información introductoria para los nuevos administradores de sistemas de Red Hat Enterprise Linux. No le enseña como llevar a cabo tareas específicas bajo Red Hat Enterprise Linux; más bien le hace llegar el conocimiento general que los administradores de sistemas con más experiencia han aprendido con el paso del tiempo.

Esta guía asume que usted tiene una experiencia limitada como usuario de Linux y ninguna experiencia como administrador de sistemas. Si usted es completamente nuevo a Linux en general (y en particular a Red Hat Enterprise Linux), debería comenzar comprando un libro introductorio de Linux.

Cada capítulo en Introducción a la administración de sistemas de Red Hat Enterprise Linux tiene la estructura siguiente:

• Material de descripción general — Esta sección discute el tema del capítulo sin profundizar mucho en detalles sobre un sistema operativo específico, tecnología o metodología.

• Material específico a Red Hat Enterprise Linux — Esta sección describe aspectos del tópico relacionado a Linux en general y en particular a Red Hat Enterprise Linux.

• Recursos adicionales para complementar los estudios — Esta sección incluye apuntadores a otros manuales de Red Hat Enterprise Linux, sitios web de utilidad y libros que contienen información aplicable al tópico.

Al adoptar una estructura consistente, los lectores pueden leer más fácilmente Introducción a la administración de sistemas de Red Hat Enterprise Linux de la forma que deseen. Por ejemplo, un administrador de sistemas con experiencia pero con poca experiencia con Red Hat Enterprise Linux, puede hojear solamente las secciones que se enfocan específicamente en Red Hat Enterprise Linux, mientras que un nuevo administrador de sistemas podría comenzar leyendo las secciones de descripción general y utilizar las secciones específicas de Red Hat Enterprise Linux, como una introducción a recursos más avanzados.

En el lado de los recursos adicionales, el Manual de administración del sistema de Red Hat Enterprise Linux es un recurso excelente para llevar a cabo tareas específicas en el ambiente Red Hat Enterprise Linux. Los administradores que requieren información más avanzada y específica, deberían consultar el Manual de referencia de Red Hat Enterprise Linux.

Las versiones en HTML, PDF y RPM de los manuales están disponibles en el CD de documentación de Red Hat Enterprise Linux y en línea en http://www.redhat.com/docs/.

Nota

Aunque este manual refleja la información más actualizada, lea las Notas de última hora de Red Hat Enterprise Linux para ver aquella información que quizás no estaba disponible para el momento antes de que la documentación se finalizara. Estas se pueden encontrar en el CD#1 de Red Hat Enterprise Linux y también el línea en http://www.redhat.com/docs/.

1. Información específica a la arquitectura

A menos que se indique lo contrario, toda la información contenida en este manual únicamente aplica al procesador x86 y a los procesadores que tienen Intel® Extended Memory 64 Technology (Intel® EM64T) y las tecnologías AMD64. Para información específica a la arquitectura, consulte el Manual de instalación de Red Hat Enterprise Linux para su arquitectura específica.

ii Introducción

2. Convenciones del documento

Cuando lea este manual, verá que algunas palabras están representadas en fuentes, tipos de letra, tamaño y peso diferentes. Esta forma de evidenciar es sistemática; se representan diferentes palabras con el mismo estilo para indicar su pertenencia a una categoría específica. Los tipos de palabras representados de esta forma incluyen los siguientes:

comando

Los comandos en Linux (y otros comandos de sistemas operativos, cuando estos se utilicen) se representan de esta manera. Este estilo le indica que puede escribir la palabra o frase en la línea de comandos y pulsar [Intro] para invocar el comando. A veces un comando contiene palabras que aparecerían con un estilo diferente si fueran solas (p.e, nombres de archivos). En estos casos, se las considera como parte del comando, de manera que toda la frase aparece como un comando. Por ejemplo:

Utilice el comando cat testfile para ver el contenido de un archivo, llamado testfile, en el directorio actual.

nombre del archivo

Los nombres de archivos, nombres de directorios, rutas y nombres de rutas y paquetes RPM aparecen siempre en este modo. Este estilo indica que un archivo o directorio en particular existe con ese nombre en su sistema. Ejemplos:

El archivo .bashrc en su directorio principal contiene definiciones de la shell de bash y alias para su propio uso.

El archivo /etc/fstab contiene información sobre diferentes dispositivos del sistema y sistemas de archivos.

Instale el RPM webalizer si quiere utilizar un programa de análisis del archivo de registro del servidor Web.

aplicación

Este estilo indica que el programa es una aplicación de usuario final (lo contrario a software del sistema). Por ejemplo:

Use Mozilla para navegar por la Web.

[tecla]

Una tecla del teclado aparece en el siguiente estilo. Por ejemplo:

Para utilizar la completación con [Tab], introduzca un carácter y pulse la tecla [Tab]. Aparecerá una lista de archivos en el directorio que empiezan con esa letra. Su terminal visualizará la lista de archivos en el directorio que empiezan con esa letra.

[tecla]-[combinación]

Una combinación de teclas aparece de la siguiente manera. Por ejemplo:

La combinación de teclas [Ctrl]-[Alt]-[Retroceso] le hará salir de la sesión gráfica y volver a la pantalla gráfica de inicio de sesión o a la consola.

texto de una interfaz gráfica (GUI) Un título, palabra o frase encontrada en una pantalla o ventana de interfaz gráfica GUI aparecerá en este estilo. La finalidad del texto escrito en este estilo es la de identificar una pantalla GUI particular o un elemento en una pantalla GUI (p.e, un texto relacionado con una casilla de verificación o un campo). Ejemplos:

Introducción iii

Seleccione la casilla de verificación Pedir contraseña si quiere que su salvapantallas pida una contraseña antes de terminar.

nivel superior de un menú en una pantalla o ventana GUI

Cuando vea una palabra con este estilo, significa que la palabra está en el nivel superior de un menú desplegable. Si hace clic sobre la palabra en la pantalla GUI, aparecerá el resto del menú. Por ejemplo:

Bajo Archivo en una terminal de GNOME, la opción Nueva solapa le permite abrir múltiples intérpretes de comandos de la shell en la misma ventana.

Si tiene que escribir una secuencia de comandos desde un menú GUI, aparecerán como en el siguiente ejemplo:

Vaya a Botón del menú principal (en el Panel) => Programación => Emacs para iniciar el editor de textos Emacs.

botón en una pantalla o ventana GUI

Este estilo indica que el texto puede encontrarse en un botón que se puede pulsar en una pantalla GUI. Por ejemplo:

Pulse el botón Anterior para volver a la última página Web que haya visitado.

salida de pantalla

El texto en este estilo indica el texto desplegado en un intérprete de comandos de la shell, tales como mensajes de error y respuestas a comandos. Por ejemplo:

Utilice el comando ls para visualizar los contenidos de un directorio. Por ejemplo: Desktop about.html logs paulwesterberg.png Mail backupfiles mail reports

La salida de pantalla que le devuelvan como respuesta al comando (en este caso, el contenido del directorio) se mostrará en este estilo.

intérprete de comandos

El intérprete de comandos es el modo en el que el ordenador le indica que está preparado para que usted introduzca algo, aparecerá con el siguiente estilo. Ejemplos:

$

#

[stephen@maturin stephen]$

leopard login:

entrada del usuario

El texto que el usuario tiene que escribir, ya sea en la línea de comandos o en una casilla de texto de una pantalla GUI, se visualizará en este estilo. En el siguiente ejemplo, text se visualiza en este estilo:

Para arrancar su sistema en el programa de instalación en modo texto, necesitará escribir el comando text en el intérprete de comandos boot:.

replaceable

El texto usado para los ejemplos, que se supone debe ser reemplazado con datos proporcionados por el usuario, usualmente se representa en este estilo. En el siguiente ejemplo, � version-number � se visualiza en este estilo:

iv Introducción

El directorio para la fuente del kernel es /usr/src/ � version-number � /, donde� version-number � es la versión del kernel instalado en este sistema.

Adicionalmente, usamos diferentes tipos de estrategias para llamar su atención para determinadostipos de información. Dependiendo de lo importante que esta información sea para su sistema, estoselementos serán marcados como nota, sugerencia, importante, atención o aviso. Por ejemplo:

Nota

Recuerde que Linux es sensible a mayúsculas y minúsculas. En otras palabras, rosa no es lo mismoque ROSA o rOsA.

Sugerencia

El directorio /usr/share/doc/ contiene documentación adicional de los paquetes instalados en susistema.

Importante

Si modifica el archivo de configuración de DHCP, los cambios no surtirán efecto sino hasta quereinicie el demonio DHCP.

Atención

No lleve a cabo tareas rutinarias como root — utilice una cuenta de usuario normal a menos quenecesite usar una cuenta de usuario para administrar su sistema.

Aviso

Tenga cuidado de solamente borrar las particiones Red Hat Enterprise Linux necesarias. Si eliminaotras particiones esto puede resultar en la pérdida de datos o en un ambiente del sistema dañado.

3. Active su suscripciónAntes de que pueda acceder a cualquier información de mantenimiento de software o servicios y a lainformación de soporte incluida con su suscripción, debe activar su suscripción registrándose con RedHat. El registro incluye los pasos siguientes:

• Proporcione un nombre de conexión a Red Hat

• Proporcione un número de suscripción

Introducción v

• Conecte su sistema

La primera vez que arranque su instalación de Red Hat Enterprise Linux, se le pedirá que se registre con Red Hat utilizando el Agente de configuración. Si sigue las indicaciones durante el Agente de configuración, puede completar los pasos para la inscripción y activar su suscripción.

Si por alguna razón no puede terminar la inscripción durante el Agente de configuración (lo que requiere de acceso a la Internet), alternativamente puede completar el proceso de registro en línea en http://www.redhat.com/register/.

3.1. Proporcione un nombre de conexión a Red Hat Si no tiene un usuario de conexión a Red Hat puede crear uno cuando se le solicite durante el Agente de configuración, o en línea en:

https://www.redhat.com/apps/activate/newlogin.html

Un usuario de conexión Red Hat le permite acceder a:

• Actualizaciones de software, erratas y mantenimiento a través de Red Hat Network

• Recursos de soporte técnico de Red Hat, documentación y base de datos de conocimiento

Si se le ha olvidado su usuario de conexión Red Hat, puede buscarlo en línea en:

https://rhn.redhat.com/help/forgot_password.pxt

3.2. Proporcione su número de suscripción

Su número de suscripción está ubicado en el paquete en el que vino su pedido. Si su paquete no incluyó un número de suscripción, entonces su suscripción fue activada por usted y se puede saltar este paso.

Puede suministrar su número de suscripción cuando se le solicite durante el Agente de configuración o visitando http://www.redhat.com/register/.

3.3. Conecte su sistema

El Cliente de Registro de Red Hat Network le ayuda a conectar su sistema para que pueda comenzar a recibir las actualizaciones y administrar su sistema. Hay tres formas de conectarse:

1. Durante el Agente de configuración — Marque las opciones Enviar información del hardware y Enviar lista de paquetes del sistema cuando se le pregunte.

2. Después de terminar el Agente de configuración — Desde el Menú principal, vaya a Herramientas del sistema, luego seleccione Red Hat Network.

3. Después de completarse el Agente de configuración — Escriba el comando siguiente desde la línea de comandos como usuario root.

• /usr/bin/up2date --register

vi Introducción

4. ...y hay más

La Introducción a la administración de sistemas de Red Hat Enterprise Linux es parte del compromiso creciente de Red Hat de proporcionar asistencia útil y a tiempo para los usuarios de Red Hat Enterprise Linux. A medida que surgen nuevas ediciones de Red Hat Enterprise Linux, hacemos todos los esfuerzos necesarios para hacerle llegar documentación nueva y mejorada.

4.1. Envíenos sus comentarios

Si encuentra un error tipográfico en la Introducción a la administración de sistemas de Red Hat Enterprise Linux o si se le ocurre una forma en la que podríamos mejorar este manual, nos encantaría escuchar de usted. Por favor envíe un reporte a Bugzilla (http://bugzilla.redhat.com/bugzilla) indicando el componente rhel-isa.

No se olvide de mencionar el identificador del manual:

rhel-isa(ES)-4-Print-RHI (2004-08-25T17:11)

Si menciona el identificador del manual, sabremos exáctamente cuál versión del manual posee.

Si tiene alguna sugerencia para mejorar la documentación, trate de ser lo más específico posible. Si encuentra algún error, por favor incluya el número de la sección y algo del texto que lo rodea para que lo podamos encontrar fácilmente.

Capítulo 1. Filosofía de la Administración de Sistemas

Aún cuando los detalles específicos de la administración de sistemas pueden variar entre plataformas, hay temas subyacentes que no. Estos temas conforman la filosofía de la administración de sistemas.

Los temas son:

• Automatizar todo

• Documentar todo

• Comunicar tanto como sea posible

• Conocer sus recursos

• Conocer sus usuarios

• Conocer el negocio

• La seguridad no puede ser una ocurrencia posterior

• Planifique

• Espere lo inesperado

Las secciones siguientes exploran cada tema en detalle.

1.1. Automatizar todo

La mayoría de los administradores de sistemas son superados en número — bien sea por sus usuarios, sus sistemas o ambos. En muchos casos, la automatización es la única forma de mantenerse al día. En general, cualquier cosa realizada más de una vez se debería examinar como un posible candidato para automatización.

He aquí algunas de las tareas comúnmente automatizadas:

• Verificación e informes de espacio libre en disco

• Respaldos

• Recolección de datos de rendimiento del sistema

• Mantenimiento de cuentas de usuarios (crear, eliminar, etc.)

• Funciones específicas al negocio (colocar nuevos datos al servidor web, ejecutar informes mensuales, trimestrales o anuales, etc.)

Esta lista no esta para nada completa; las funciones automatizadas por los administradores de sistemas solamente están limitadas por la disposición del administrador de escribir los scripts necesarios. En este caso, el ser flojo (y dejar que la computadora haga la mayor parte del trabajo mundano) es en realidad algo positivo.

La automatización proporciona a los usuarios el beneficio extra de mayor previsibilidad y consistencia de servicios.

2 Capítulo 1. Filosofía de la Administración de Sistemas

Sugerencia

Recuerde que si tiene una tarea que debería ser automatizada, es muy probable que no sea el primer administrador con esa necesidad. Aquí es donde los beneficios del software de código abierto realmente brillan — quizás pueda utilizar el trabajo de otra persona para automatizar el procedimiento manual que actualmente está consumiendo su tiempo. Por esto, asegúrese siempre de hacer una búsqueda en internet antes de escribir cualquier cosa más compleja que un pequeño script de Perl.

1.2. Documentar todo

Si se les da la opción de seleccionar entre instalar un nuevo servidor y escribir un documento procedimental sobre como realizar copias de seguridad, el administrador promedio escogería instalar un nuevo servidor. Aunque esto no es para nada inusual, usted debe documentar lo que hace. Muchos administradores de sistemas posponen la preparación de la documentación necesaria por una variedad de razones:

"Más tarde lo hago."

Desafortunadamente, esto usualmente no es verdad. Aún si el administrador realmente tiene la intención de hacerlo, la naturaleza del trabajo es tal que las tareas diarias son usualmente demasiado caóticas para "hacerlo más tarde". Peor aún, mientras pasa más tiempo más se olvida, llevando a un documento mucho menos detallado (y menos útil).

"Para qué escribirlo? Yo me recuerdo."

A menos que usted sea uno de esos raros individuos con una memoria fotográfica, usted no se recordará. O peor aún, sólo recordará la mitad, sin darse cuenta de que le falta la historia completa. Esto conduce a una pérdida de tiempo tratando de reaprender lo que ha olvidado o reparando lo que echó a perder debido a un entendimiento incompleto de la situación.

"Si lo mantengo en mi memoria, no me despedirán — así tendré seguridad laboral!"

Aunque esto puede funcionar por un tiempo, invariablemente conduce a menos — no más — seguridad laboral. Piense por un momento lo que puede pasar durante una emergencia. Puede que usted no esté disponible, la documentación puede salvar el día dejando que alguien más resuelva el problema en su ausencia. Nunca olvide que las emergencias tienden a ocurrir justo cuando la gerencia está más atenta. En tales casos, es mejor tener la documentación como parte de la solución a que el problema sea su ausencia.

Además, si es parte de una organización en crecimiento, eventualmente habrá necesidad de otro administrador de sistemas. Cómo puede esta persona aprender a respaldarlo si todo está en su cabeza? Peor aún, el no tener documentación lo puede hacer tan indispensable que no le permitirá avanzar en su carrera. Puede terminar trabajando para la misma persona que fue contratada para asistirlo a usted.

Con suerte, ya le vendimos la idea de los beneficios de la documentación de sistemas. Lo que nos lleva a la siguiente pregunta: ¿Por qué debería documentar? He aquí una lista parcial:

Políticas

Las políticas son escritas para formalizar y clarificar la relación que usted tiene con su comunidad de usuarios. Estas establecen la forma en que se manejan las solicitudes de recursos o de asistencia. La naturaleza, estilo y método de diseminación de las políticas a su comunidad varían de organización a organización.

Capítulo 1. Filosofía de la Administración de Sistemas 3

Procedimientos

Los procedimientos son secuencias de pasos sobre acciones que deben ser tomadas para alcanzar una tarea determinada. Los procedimientos a documentar incluyen procedimientos de respaldo, procedimientos de administración de cuentas de usuarios, procedimientos de reportes de problemas, etc. De la misma manera que la automatización, si un procedimiento es seguido más de una vez, es una buena idea documentarlo.

Cambios

Una gran parte de la carrera de un administrador de sistemas gira alrededor de ejecutar cambios — configurar sistemas para un máximo rendimiento, ajustar scripts, modificar archivos de configuración, etc. Todos estos cambios deberían estar documentados de alguna forma. De lo contrario, se puede encontrar completamente confundido sobre los cambios que realizó unos meses atrás.

Algunas organizaciones utilizan métodos más complejos para hacer un seguimiento de los cambios, pero en muchos casos una simple revisión histórica al comienzo del archivo que está siendo modificado, es todo lo que se necesita. Como mínimo, cada entrada en la revisión histórica debería contener:

• El nombre o iniciales de la persona que está ejecutando el cambio

• La fecha en que se realizó el cambio

• La razón del cambio

Esto genera entradas concisas pero útiles:

ECB, 12-Junio-2002 — Entrada actualizada para la nueva impresora de Contabilidad (para apoyar la habilidad de impresión duplex de la impresora de reemplazo)

1.3. Comunique tanto como sea posible

Cuando se refiere a sus usuarios, nunca hay demasiado que comunicar. Tenga en cuenta que los pequeños cambios que usted puede pensar son prácticamente insignificantes, pueden confundir completamente al asistente administrativo de Recursos Humanos.

El método que utilice para comunicarse con sus usuarios puede variar de acuerdo a su organización. Algunas organizaciones utilizan correo electrónico, otras un sitio web interno. Otras pueden manejar esto con Usenet o IRC. En algunos lugares puede inclusive ser suficiente una hoja de papel en la cartelera informativa de la oficina. En cualquier caso, utilice el método que mejor funcione de acuerdo a su organización.

En general, es conveniente utilizar un enfoque similar al utilizado en la escritura de noticias de prensa:

1. Informe a sus usuarios sobre lo que va a hacer

2. Informe a sus usuarios sobre lo que está haciendo

3. Informe a sus usuarios sobre lo que ha hecho

Las secciones siguientes detallan estos pasos con mayor profundidad.

1.3.1. Informe a sus usuarios sobre lo que va a hacer

Asegúrese de advertir a sus usuarios con tiempo antes de hacer cualquier cosa. La cantidad de pre aviso necesario varía de acuerdo al tipo de cambio (actualizar un sistema operativo requerirá mucho más tiempo de aviso que el cambio del color predeterminado de la pantalla de inicio de sesión), así como también la naturaleza de su comunidad de usuarios (los usuarios con más inclinación tecnológica tienden a manejar los cambios con mayor disposición que aquellos con habilidades mínimas.)

Como mínimo, debería describir:


• La naturaleza del cambio

• Cuando ocurrirá

• Porqué está sucediendo

• Aproximadamente cuánto tiempo tomará

• El impacto (si existe) que pueden esperar los usuarios debido al cambio

• La información de contacto si tienen alguna pregunta o dudas

He aquí una situación hipotética. El departamento de Finanzas está experimentando problemas con su servidor de base de datos, el cual a veces funciona muy lentamente. Usted tiene que desconectar el servidor, actualizar el módulo del CPU a un modelo más rápido y reiniciar. Una vez hecho esto, usted moverá la base de datos a un almacenamiento tipo RAID. He aquí un posible anuncio para esta situación:

Planificación para el tiempo fuera de servicio del sistema el viernes en la noche

Comenzando este viernes a las 6pm (medianoche para nuestros asociados en Berlín), todas las aplicaciones financieras estarán indisponibles por un período de aproximadamente cuatro horas.

Durante este tiempo, se llevarán a cabo cambios en el hardware y software del servidor de base de datos de Finanzas. Estos cambios reducirán en gran medida el tiempo requerido para ejecutar las aplicaciones de Cuentas por Pagar, Cuentas por Cobrar y la Hoja de Balance Semanal.

Además del cambio en el tiempo de ejecución, la mayoría de la gente no debería experimentar ningún otro cambio. Sin embargo, aquellas personas que hayan escrito sus propias consultas SQL deben tener en cuenta que la distribución de algunos índices cambiará. Esto está documentado en la intranet de la compañía, en la página de Finanzas.

Si tiene alguna pregunta, comentarios o dudas, por favor comuníquese con el Administrador de Sistemas en la extensión 4321.

Es importante resaltar algunas puntos:

• Comunique efectivamente la hora de inicio y duración de cualquier tiempo de parada relacionado con el cambio.

• Asegúrese de indicar la hora del cambio de forma que sea útil a todos los usuarios, sin importar su ubicación.

• Utilice una terminología que sus usuarios puedan entender. La gente que se verá impactada por este cambio no le importa si el nuevo módulo de CPU es una unidad de 2 GHz con el doble de L2 caché, o que la base de datos está siendo colocada en un volumen lógico RAID 5.

1.3.2. Informe a sus usuarios sobre lo que está haciendo

Este paso es principalmente una advertencia de último hora sobre el cambio inminente; como tal, debe ser una breve repetición del mensaje inicial, pero haciendo más obvio la naturaleza inminente del cambio ("La actualización del sistema se llevará a cabo ESTA NOCHE."). Esta es también una buena oportunidad para contestar públicamente cualquier pregunta que haya recibido como resultado del primer mensaje.

Continuando con nuestro mensaje hipotético, he aquí una posible advertencia de última hora:


Parada del sistema programada para esta noche

Recordatorio: La parada del sistema anunciada el lunes pasado se llevará a cabo como se indicó, esta noche a las 6pm (medianoche para la oficina de Berlín). Puede encontrar el anuncio original en el sitio web de la intranet corporativa, en la página de Administración del Sistema.

Mucha gente ha preguntado si deberían dejar de trabajar temprano para asegurarse de que su trabajo sea respaldado antes de la parada. Esto no será necesario, ya que el trabajo que se realizará esta noche no impactará ningún trabajo realizado en sus estaciones de trabajo personales.

Recuerde, aquellos que hayan escrito sus propias consultas SQL deben estar conscientes de que la disposición de algunos índices cambiará. Esto está documentado en la intranet corporativa, en la página de Finanzas.

Ya advirtió a sus usuarios; ahora está listo para comenzar a hacer el trabajo.

1.3.3. Informe a sus usuarios sobre lo que ha hecho

Después de terminar de hacer los cambios, usted debe decirle a sus usuarios lo que ha hecho. Una vez más, esto debería ser un resúmen de los mensajes anteriores (invariablemente habrá alguién que no los ha leído.)1

Sin embargo, hay algo muy importante que debe agregar. Es de suma importancia que informe a sus usuarios sobre el estado actual. La actualización no salió como lo tenía pensado? El nuevo servidor de almacenamiento solamente pudo servir los sistemas en Ingeniería pero no en Finanzas? Este tipo de problemas se deben mencionar aquí.

Por supuesto, si el estado actual es diferente del que usted comunicó anteriormente, debe aclarar este punto y describir que se hará (si aplica) para llegar a la solución final.

En nuestra situación hipotética, la parada tuvo algunos problemas. El nuevo módulo de CPU no funcionó; una llamada al fabricante del sistema reveló que se requiere una versión especial del módulo para las actualizaciones en el campo. En el lado positivo, la migración de la base de datos al volumen RAID salió bien (aún cuando tomó un poco más tiempo de lo planeado debido a los problemas con el módulo de CPU).

He aquí un posible anuncio

Finalizada la parada del sistema

Finalizó la parada del sistema planificada para este viernes en la noche (consulte la página de Administración del Sistema en la intranet corporativa). Lamentablemente, algunos problemas con el hardware impidieron completar una de las tareas. Como resultado de esto, el resto de las tareas demoraron más de cuatros horas, que era como se tenía planificado originalmente.

Debido a los problemas de hardware, el rendimiento de los informes de Cuentas por Pagar, Cuentas por Cobrar y Hoja de Balance, mejorará un poco pero no al punto que se tenía planificado originalmente. Pronto se anunciará una segunda parada tan pronto como se resuelvan los problemas que impidieron la finalización de la tarea.

Tenga en cuenta que el tiempo fuera de servicio modificó algunos índices de las bases de datos; las personas que han escrito sus propias consultas SQL deberían consultar la página de Finanzas en la intranet corporativa.

Por favor contacte a Administración del Sistema en la extensión 4321 si tiene alguna pregunta.

Con este tipo de información, sus usuarios tendrán suficiente información de fondo para continuar con su trabajo y para entender cómo los cambios los impactan.

1. Asegúrese de enviar este mensaje tan pronto termine el trabajo, antes de irse a su casa. Una vez que deje la

oficina, es muy fácil olvidarse, dejando a los usuarios en la oscuridad sobre si pueden usar el sistema o no.


1.4. Conozca sus recursos

La administración de sistemas es mayormente un asunto de balancear los recursos disponibles con la gente y los programas que utilizan esos recursos. Por lo tanto, su carrera como administrador de sistemas será corta y llena de stress a menos que entienda completamente los recursos que tiene a su disposición.

Algunos de estos recursos pueden parecer muy obvios:

• Recursos del sistema, tales como el poder de procesamiento disponible, memoria y espacio en disco

• Ancho de banda

• Dinero disponible en el presupuesto para IT

Pero pueden no ser tan obvios:

• Los servicios del personal de operaciones, otros administradores de sistemas o hasta un asistente administrativo

• Tiempo (a veces de importancia crítica cuando el tiempo incluye cuestiones tales como la cantidad de tiempo durante la que se realizan los respaldos del sistema)

• Conocimiento (bien sea almacenado en libros, documentación del sistema o en el cerebro de una persona que ha trabajado en la compañía durante los últimos 20 años)

Lo importante es tomar en cuenta que es de gran valor llevar un inventario completo de los recursos disponibles y mantenerlo actualizado — una falta de "consciencia situacional" sobre los recursos disponibles a veces es peor que ninguna consciencia.

1.5. Conozca a sus usuarios

Aún cuando algunas personas se encrespan con el término "usuarios" (quizás debido a que algunos administradores de sistemas utilizan el término de forma despectiva), aquí no se utiliza con esa connotación. Los usuarios son aquellas personas que utilizan esos sistemas y recursos sobre los que usted tiene responsabilidad — ni más ni menos. Los usuarios son la clave en su habilidad de administrar exitósamente sus sistemas; sin entender a sus usuarios, cómo puede entender los recursos que estos requieren?

Por ejemplo, considera un cajero de banco. Un cajero utiliza un conjunto de aplicaciones definidas de forma estricta y requiere poco desde el punto de vista de recursos del sistema. Por otro lado, un ingeniero de software, puede utilizar muchas aplicaciones diferentes y siempre va a apreciar más recursos de sistemas (para tiempos de compilación/ejecución más rápidos). Dos usuarios completamente diferentes con necesidades completamente diferentes.

Asegúrese de aprender tanto como pueda de sus usuarios.

1.6. Conozca su negocio

Bien sea que trabaje para una corporación multinacional o una comunidad pequeña del colegio, tiene que entender la naturaleza del entorno del negocio en el que trabaja. Esto se puede reducir a una pregunta:

¿Cuál es el propósito de los sistemas que administra?

El punto clave aquí es entender el propósito de sus sistemas en un sentido más global:

• Aplicaciones que se deben ejecutar en un período de tiempo particular, tal como al final del mes, trimestre o año


• Los tiempos durante los que se ha efectuado mantenimientos al sistema

• Nuevas tecnologías que se podrían utilizar para resolver viejos problemas de negocios

Al tomar en consideración la organización de su negocio, notará que sus decisiones diarias seran mejores para sus usuarios y para usted.

1.7. La seguridad no puede ser una ocurrencia posterior

Sin importar lo que usted piense sobre el entorno en el cual se ejecutan sus sistemas, no puede asumir la seguridad como algo garantizado. Hasta los sistemas independientes que no están conectados a la Internet están a riesgo (obviamente los riesgos son diferentes de aquellos de un sistema con conexiones al mundo externo).

Por lo tanto, es extremadamente importante considerar las implicaciones de seguridad en todo lo que realice. La lista siguiente ilustra los diferentes tipos de problemas que debería considerar.

• La naturaleza de las posibles amenazas a cada uno de los sistemas bajo su cuidado

• La ubicación, tipo y valor de los datos en esos sistemas

• El tipo y la frecuencia del acceso autorizado a los sistemas

Cuando piense sobre seguridad, no cometa el error de asumir que los posibles intrusos solamente atacarán sus sistemas desde afuera de su compañía. Muchas veces el autor es alguien dentro de la compañía. Así que la próxima vez que camine alrededor de la oficina, mire a la gente que lo rodea y hágase la siguiente pregunta:

¿Qué pasaría si esa persona intentara subvertir nuestra seguridad?

Nota

Esto no significa que usted deba tratar a sus compañeros de trabajo como criminales. Simplemente significa que debe observar el tipo de trabajo que cada persona realiza y determinar qué tipos de violaciones de seguridad puede llevar a cabo una persona en esa posición, si tuviese esas intenciones.

1.7.1. Los riesgos de Ingeniería Social Mientras que la primera reacción de los administradores de sistemas cuando piensan sobre seguridad, es concentrarse en los aspectos tecnológicos, es importante mantener la perspectiva. Muy a menudo, las violaciones de seguridad no tienen sus orígenes en la tecnología, pero en la naturaleza humana.

La gente interesada en violar la seguridad a menudo utiliza la naturaleza humana para saltar los controles de acceso tecnológicos. Esto se conoce como ingeniería social. He aquí un ejemplo:

El segundo operador de turno recibe una llamada externa. La persona que llama dice ser el Director de Finanzas (el nombre del Director de Finanzas e información de fondo se puede obtener desde el sitio web de la organización, en la página de "Equipo de Gerencia").

La persona que llama dice que está en algún lugar del mundo a mitad de camino (quizás esta parte de la historia es fabricada completamente o quizás en el sitio web de la organización, en la sección de noticias, se menciona sobre el Director de Finanzas viajando a una exhibición).

La persona cuenta la historia de un infortunio; su portátil fue robada en el aeropuerto y ahora se encuentra con un cliente importante y necesita acceso a la intranet corporativa para verificar el estado de la cuenta del cliente. ¿Será el operador tan amable de darle la información de acceso necesaria?


¿Sabe usted qué hará el operador? A menos que su operador tenga las pautas claras (en cuanto a las políticas y procedimientos), lo más seguro es que no esté seguro de lo que hará.

De la misma forma que los semáforos, el objetivo de las políticas y procedimientos es el de proporcionar direcciones inequívocas sobre lo que es y no es el comportamiento apropiado. Sin embargo, así como los semáforos, las políticas y procedimientos solamente funcionan si todos los siguen. Está además el quid del problema — es muy poco probable que todos se sometan a las políticas y procedimientos. De hecho, dependiendo de la naturaleza de su organización, es posible que ni siquiera tenga suficiente autoridad para definir las políticas, mucho menos para hacerlas cumplir. Entonces ... ¿qué hacer?

Lamentablemente, no hay respuestas fáciles para esto. La educación para los usuarios puede ayudar; haga todo lo que pueda para poner a su comunidad al tanto de la seguridad y de la ingeniería social. Haga presentaciones durante la hora del almuerzo sobre seguridad. Publique enlaces a artículos relacionados con la seguridad en la lista de correo de su organización. Exprese su disponibilidad como una junta para contestar preguntas de los usuarios sobre cosas que no parecen del todo correctas.

En resumidas cuentas, entregue el mensaje a sus usuarios de la forma que pueda.

1.8. Planifique

Los administradores de sistemas que hayan seguido todos estos consejos y que hicieron lo posible por seguirlo serán excelentes administradores — por un día. Eventualmente el entorno cambiará y un día nuestro fantástico administrador será tomado por sorpresa. ¿La razón? Nuestro fantástico administrador falló en planificar con tiempo.

Por supuesto, nadie puede predecir el futuro con un 100% de fidelidad. Sin embargo, con un poco de consciencia es fácil leer las señales de muchos cambios:

• Un comentario informal durante la aburrida reunión semanal de personal sobre el comienzo de un nuevo proyecto, es una señal segura de que en un futuro cercano tendrá que apoyar a nuevos usuarios.

• Conversaciones sobre una inminente adquisición significa que probablemente usted será responsable de nuevos (y quizás incompatibles) sistemas en una o más ubicaciones remotas

Tener la habilidad de leer estas señales (y de responder efectivamente a ellas) hará su vida y la de sus usuarios más fácil.

1.9. Espere lo inesperado

Mientras que la frase "espere lo inesperado" es trivial, refleja una verdad subyacente que todos los administradores de sistemas deben entender:

Habrá ocasiones en las que será tomado por sorpresa.

Después de familiarizarse con esta incómoda realidad, ¿qué puede hacer un administrador de sistemas preocupado? La respuesta recae en flexibilidad; hacer su trabajo de forma tal que le pueda dar a usted y a sus usuarios la mayor cantidad de opciones. Por ejemplo, el caso de espacio en disco. Dado que la insuficiencia constante de espacio en disco parece ser una ley física tan seria como la Ley de Gravedad, es razonable asumir que en algún momento se le presentará la necesidad desesperada de espacio adicional en disco ya.

¿Qué puede hacer un administrador de sistemas que espera lo inesperado en este caso? Quizás sea posible mantener unas unidades adicionales en almacén como repuestos en caso de problemas de


hardware2 . Un repuesto de este tipo puede ser instalado rápidamente3 de forma temporal para solucionar a corto plazo la necesidad de espacio de disco, dando tiempo para resolver el problema de forma permanente (siguiendo el procedimiento estándar para obtener unidades adicionales, por ejemplo).

Si trata de anticipar los problemas antes de que estos ocurran, usted estará en una mejor posición para responder rápida y efectivamente que si dejara las cosas para ser sorprendido cuando surja el momento.

1.10. Información específica a Red Hat Enterprise Linux

Esta sección describe información relacionada a la filosofía de la administración de sistemas específica a Red Hat Enterprise Linux.

1.10.1. Automatización

La automatización de tareas realizadas frecuentemente bajo Red Hat Enterprise Linux requiere el conocimiento de diferentes tipos de tecnologías. Primero están los comandos que controlan el tiempo de ejecución de los scripts. Los comandos cron y at son los más utilizados para estas funciones.

cron incorpora un sistema de especificación de tiempos fácil de entender, flexible y a la vez poderoso. cron puede planear la ejecución de comandos o scripts en intervalos repetitivos que pueden variar en duración desde minutos hasta meses. El comando crontab es utilizado para manipular los archivos que controlan el demonio cron que planifica la ejecución de cada trabajo cron.

El comando at (y el comando relacionado batch) son más apropiados para planificar la ejecución de comandos o scripts que sólo se ejecutan una vez. Estos comandos implementan un subsistema rudimentario por lotes que consiste de múltiples colas con varias prioridades de planificación. Las prioridades son conocidas como niveles de niceness (debido al nombre del comando — nice). Tanto at como batch son perfectos para las tareas que deben comenzar en un momento determinado pero que no son críticas en términos de cuando finalizar.

Luego están los diferentes lenguajes de scripting. Estos son los "lenguajes de programación" que el administrador de sistemas promedio utiliza para automatizar las operaciones manuales. Hay muchos lenguajes de scripting (y cada administrador tiende a tener un favorito), pero los siguientes son los que se utilizan más a menudo:

• El intérprete de comandos bash

• El lenguaje de scripting perl

• El lenguaje de scripting python

Por encima de todas las diferencias obvias entre estos lenguajes, la diferencia más grande está en la forma en que estos lenguajes interactúan con otros utilitarios en un sistema Red Hat Enterprise Linux. Los scripts escritos con el intérprete de comandos bash tienden a hacer un uso más extensivo de muchos pequeños programas de utilerías (por ejemplo, para realizar la manipulación de cadenas de cáracteres), mientras que los scripts perl realizan más este tipo de operaciones usando funcionalidades incorporadas en el lenguaje mismo. Un script escrito usando python puede explotar mejor las capacidades de orientación a objetos del lenguaje, haciendo los scripts complejos extensible más fácilmente.

Esto significa que para manejar bien la programación del shell, debe estar familiarizado con los muchos programas de utilerías (tales como grep y sed) que son parte de Red Hat Enterprise Linux.

2. Y por supuesto, un administrador de sistemas que espera lo inesperado naturalmente utilizará RAID (u otras

tecnologías relacionadas) para disminuir el impacto de la falla de un disco crítico durante producción. 3. Una vez más, los administradores de sistemas que piensan a futuro configuran sus sistemas de manera que

sea fácil y rápido añadir un nuevo disco al sistema.


Por otro lado, aprender perl (y python), tiende a ser un proceso más "autocontenido". Sin embargo, muchas construcciones de perl están basadas en la sintáxis de varios programas de utilerías UNIX y como tales los administradores de sistemas Red Hat Enterprise Linux con experiencia en programación del shell están familiarizados con ellos.

1.10.2. Documentación y comunicación

En las áreas de comunicación y documentación, hay poco que sea específico a Red Hat Enterprise Linux. Puesto que la documentación y comunicación puede consistir de cualquier cosa desde añadir comentarios a un archivo de configuración basado en texto hasta la actualización de una página web o el envío de correo electrónico, un administrador de sistemas usando Red Hat Enterprise Linux debe tener acceso a editores de texto, editores HTML y clientes de correo.

He aquí una pequeña muestra de los muchos editores de texto disponibles bajo Red Hat Enterprise Linux:

• El editor de texto gedit • El editor de texto Emacs

• El editor de texto Vim

El editor de texto gedit es una aplicación estrictamente gráfica (en otras palabras, requiere de un entorno X Window), mientras que vim y Emacs están principalmente basadas en texto.

El tema del mejor editor de texto ha generado un debate que data casi desde que existen las computadoras y continuará así por un tiempo. Por lo tanto, el mejor enfoque es probar cada editor usted mismo y utilizar el que mejor funciona para usted.

Para los editores HTML, los administradores de sistemas pueden utilizar la función Composer del navegador web Mozilla. Por supuesto, algunos administradores de sistemas prefieren codificar manualmente su HTML, haciendo un editor de texto normal una herramienta perfectamente aceptable.

Con respecto al correo electrónico, Red Hat Enterprise Linux incluye el cliente de correo gráfico Evolution, el cliente de correo Mozilla (que también es gráfico) y mutt, que está basado en texto. De la misma manera que con los editores de texto, la selección del cliente de correo tiende a ser personal; como resultado, el mejor enfoque es probar cada cliente usted mismo y utilizar el que mejor se ajusta a usted.

1.10.3. Seguridad

Como se indicó anteriormente en este capítulo, la seguridad nunca puede ser una ocurrencia posterior y la seguridad bajo Red Hat Enterprise Linux es un poco más profunda. La autenticación y los controles de acceso están profundamente integrados dentro del sistema operativo y están basados en diseños recogidos a partir de la larga experiencia en la comunidad UNIX.

Para la autenticación, Red Hat Enterprise Linux utiliza PAM — Pluggable Authentication Modules. PAM hace posible afinar la autenticación de usuarios a través de la configuración de bibliotecas compartidas que todas las aplicaciones compatibles con PAM utilizan, todo, sin requerir ningún cambio a las aplicaciones mismas.

Los controles de acceso bajo Red Hat Enterprise Linux utilizan los permisos tradicionales tipo UNIX (lectura, escritura, ejecución) para las clasificaciones usuario, grupo y "otros". Como UNIX, Red Hat Enterprise Linux también utilizan los bits setuid y setgid para conferir temporalmente los derechos de acceso a procesos ejecutando un programa particular, basado en la propiedad del archivo del programa. Por supuesto, esto hace crítico que cualquier programa que se ejecute con privilegios setuid o setgid debe ser auditado cuidadosamente para asegurarse de que no existan vulnerabilidades explotables.


Red Hat Enterprise Linux también incluye el soporte para las listas de control de acceso. Una lista de control de acceso (ACL) es una construción que permite un control refinado sobre qué usuarios o grupos pueden tener acceso a un archivo o directorio. Por ejemplo, los permisos de un archivo pueden restringir todo el acceso de cualquiera que no sea el dueño del archivo, sin embargo, la ACL del archivo se puede configurar para permitir que solamente el usuario bob a que escriba y al grupo finance a que lea el archivo.

Otro aspecto de la seguridad es poder hacer un seguimiento de la actividad del sistema. Red Hat Enterprise Linux hace un uso extensivo de los registros, tanto al nivel del kernel como de la aplicación. El registro es controlado por el demonio syslogd, el cual registra información del sistema localmente (normalmente a archivos en el directorio /var/log/) o a sistemas remotos (que actúa como un servidor de registro dedicado para múltiples computadores).

Los sistemas de detección de intrusos (IDS) son herramientas poderosas para cualquier administrador de sistemas Red Hat Enterprise Linux. Un IDS hace posible que un administrador pueda determinar si los cambios autorizados fueron realizados a uno o más sistemas. El diseño general del sistema operativo mismo incluye funcionalidades de IDS.

Debido a que Red Hat Enterprise Linux es instalado usando RPM Package Manager (RPM), es posible utilizar RPM para verificar si se han hecho cambios a los paquetes comprendidos dentro del sistema operativo. Sin embargo, debido a que RPM es fundamentalmente una herramienta de administración de paquetes, sus habilidades como IDS son limitadas. Aún así, puede ser un buen primer paso hacia la supervisión de un sistema Red Hat Enterprise Linux para las modificaciones no autorizadas.

1.11. Recursos adicionales

Esta sección incluye varios recursos que se pueden utilizar para aprender más sobre la filosofía de la administración de sistemas y la materia específica a Red Hat Enterprise Linux discutidas en este capítulo.

1.11.1. Documentación instalada

Los recursos siguientes son instalados durante el curso normal de una instalación típica de Red Hat Enterprise Linux y lo pueden ayudar a aprender más sobre la materia discutida en este capítulo.

• Las páginas man crontab(1) y crontab(5) — Aprenda a planificar comandos y scripts para su ejecución automática a intervalos regulares.

• La página man de at(1) — Aprenda a planificar la ejecución posterior de comandos y scripts con esta utilidad.

• La página man de bash(1) — Aprenda más sobre el shell predeterminado y la programación shell.

• La página man de perl(1) — Revise apuntadores a las numerosas páginas man que conforman la documentación en línea de perl.

• La página man de python(1) — Aprenda más sobre las opciones, archivos y variables de entorno que controlan el interpretador de Python.

• La página man de gedit(1) y la entrada de menú Help — Aprenda cómo modificar archivos de texto con este editor gráfico de texto.

• La página man de bash(1) — Aprenda más sobre este flexible editor de texto, incluyendo como ejecutar el tutorial en línea.

• La página man de vim(1) — Aprenda cómo utilizar este poderoso editor de texto.

• Las entrada de menú Mozilla Help Contents — Aprenda cómo editar archivos HTML, leer correo y navegar la web.


• La página man de evolution(1) y la entrada de menú Help — Aprenda cómo manejar su correo con este cliente de correo gráfico.

• La página man de mutt(1) y los archivos en /usr/share/doc/mutt- � version � — Aprenda cómo administrar su correo con este cliente de correo electrónico basado en texto.

• La página man de pam(8) y archivos en /usr/share/doc/pam- � version � — Aprenda sobre el funcionamiento de la autenticación bajo Red Hat Enterprise Linux.

1.11.2. Sitios web de utilidad

• http://www.kernel.org/pub/linux/libs/pam/ — La página principal del proyecto Linux-PAM.

• http://www.usenix.org/ — La página principal de USENIX. Una organización profesional dedicada a reunir a los profesionales de computación de todos los tipos y a fomentar la comunicación e innovación.

• http://www.sage.org/ — El sitio web de System Administrators Guild (Gremio de Administradores de Sistemas). Un grupo técnico especial de USENIX que es una buena fuente para todos los administradores de sistemas responsables de sistemas operativos Linux (o similares a Linux).

• http://www.python.org/ — El sitio web del Lenguaje Python. Un sitio excelente para aprender más sobre Python.

• http://www.perl.org/ — El sitio web de Perl Mongers. Un buen sitio para comenzar a aprender sobre Perl y conectarse con la comunidad Perl.

• http://www.rpm.org/ — La página principal de RPM Package Manager. El sitio más completo para aprender sobre RPM.

1.11.3. Libros relacionados

La mayoría de los libros sobre administración de sistemas hacen poco para cubrir la filosofía detrás del trabajo. Sin embargo, los libros siguientes tienen secciones que dan un poco más de profundidad a los problemas que se discutieron aquí:

• El Manual de referencia de Red Hat Enterprise Linux; de Red Hat, Inc. — Proporciona una descripción general de las ubicaciones de archivos de sistema clave, configuraciones de usuarios y grupos y la configuración de PAM.

• El Manual de seguridad de Red Hat Enterprise Linux; de Red Hat, Inc. — Contiene una discusión completa de muchos problemas relacionados a la seguridad para los administradores de sistemas Red Hat Enterprise Linux.

• El Manual de administración del sistema de Red Hat Enterprise Linux; de Red Hat, Inc. — Incluye capítulos para la administración de usuarios y grupos, automatización de tareas y administración de archivos de registro.

• El Linux Administration Handbook por Evi Nemeth, Garth Snyder y Trent R. Hein; Prentice Hall — Proporciona una buena sección sobre las pautas y políticas del lado de la administración de sistemas, incluyendo muchas discusiones "que pasaría si.." concernientes a éticas.

• El libro Linux System Administration: A User’s Guide por Marcel Gagne; Addison Wesley Professional — Contiene un buen capítulo sobre la automatización de varias tareas.

• Solaris System Management por John Philcox; New Riders Publishing — Aún cuando no está escrito especialmente para Red Hat Enterprise Linux (ni siquiera para Linux en general) y utiliza el término "gestor de sistemas" en vez de "administrador de sistemas," este libro proporciona una


descripción general de 70 páginas sobre los muchos papeles que los administradores de sistemas juegan en una organización típica.


Capítulo 2. Supervisión de recursos

Como se indicó anteriormente, una gran parte de la administración de sistemas gira alrededor de los recursos y su uso eficiente. Al balancear los diferentes recursos con las personas y programas que utilizan tales recursos, usted gasta menos dinero y mantiene a sus usuarios tan contentos como se es posible. Sin embargo, esto deja dos preguntas:

¿Qué son los recursos?

y:

¿Cómo saber cuales recursos están siendo utilizados (y hasta que punto)?

El propósito de este capítulo es proporcionarle respuestas a estas preguntas ayudándole a conocer más sobre los recursos y la manera de supervisarlos.

2.1. Conceptos básicos

Antes de poder supervisar recursos, primero tiene que conocer cuales recursos hay que monitorizar. Todos los sistemas tienen disponibles los siguientes recursos:

• Poder de CPU

• Ancho de banda

• Memoria

• Almacenamiento

Estos recursos se cubren en profundidad en los capítulos siguientes. Sin embargo, por los momentos todo lo que necesita tener en mente, es que estos recursos tienen un impacto directo en el rendimiento del sistema y, por lo tanto, en la productividad y satisfacción de sus usuarios.

En su aspecto más simple, monitorizar recursos no es más que obtener información concerniente a la utilización de uno o más recursos del sistema.

Sin embargo, raramente esto es tan simple. Primero, debe tomar en cuenta los recursos a controlar. Luego es necesario examinar cada sistema a monitorizar, prestando especial atención a la situación de cada sistema.

Los sistemas que monitoriza recaen en dos categorías:

• El sistema está actualmente experimentando problemas de rendimiento al menos parte del tiempo y a usted le gustaría mejorar su rendimiento.

• El sistema está funcionando bien y le gustaría que se mantenga de esa forma.

La primera categoría indica que usted debería supervisar su sistema desde la perspectiva del rendimiento del sistema, mientras que la segunda categoría significa que debe supervisar los recursos del sistema desde la perspectiva de planificación de la capacidad del mismo.

Debido a que cada perspectiva tiene sus requerimientos propios, las secciones siguientes exploran cada categoría en mayor detalle.

16 Capítulo 2. Supervisión de recursos

2.2. Monitorizar el rendimiento del sistema

Como se estableció anteriormente, el monitorizar el rendimiento del sistema se hace normalmente en respuesta a problemas de rendimiento. Bien sea que el sistema está corriendo muy lentamente, o los programas (y algunas veces hasta el sistema completo) fallan en ejecutarse. En cualquiera de estos casos, la supervisión del rendimiento del sistema se realiza normalmente como el primer y el último paso de un proceso de tres pasos:

1. Monitorizar para identificar la naturaleza y ámbito de la escasez de recursos que están causando los problemas de rendimiento

2. Se analizan los datos producidos a partir de la supervisión y se toma un curso de acción (normalmente optimización del rendimiento o la adquisición de hardware adicional)

3. Monitorizar para asegurarse de que se ha solucionado el problema de rendimiento

Debido a esto, tiende a tener una vida relativamente corta en duración y más detallada en ámbito.

Nota

Monitorizar el rendimiento del sistema a menudo es un proceso iterativo, repitiendo estos pasos varias veces para llegar al mejor rendimiento posible para el sistema. La razón principal para esto es que los recursos del sistema y su utilización tienden a estar estrechamente relacionados, lo que significa que a menudo la eliminación de un cuello de botella descubre otro más.

2.3. Monitorizar la capacidad del sistema

La supervisión de la capacidad del sistema se hace como parte de un programa contínuo de planificación. La planificación de capacidad utiliza el monitoreo a largo plazo de los recursos del sistema para determinar las tasas de cambio en la utilización de los recursos del sistema. Una vez que se conocen estas tasas de cambio, se hace posible conducir una planificación a largo plazo más exacta con respecto a la adquisición de recursos adicionales.

Monitorizar para propósitos de planificación de capacidad es diferente de monitorizar el rendimiento en dos formas:

• Se monitoriza más o menos de forma contínua

• Usualmente el monitoreo no es tan detallado

La razón de estas diferencias se generan de los objetivos del programa de planificación de capacidades. La planificación de capacidades requiere un punto de vista de "cuadro completo"; un punto de vista a corto plazo o el uso incorrecto de recursos es de poco interés. En vez de esto, se recopilan los datos sobre un período de tiempo, haciendo posible categorizar la utilización de recursos en términos de los cambios en la carga de trabajo. En ambientes definidos de forma más limitada (donde solamente corre una aplicación, por ejemplo) es posible modelar el impacto de la aplicación en los recursos del sistema. Esto se puede hacer con suficiente exactitud para determinar, por ejemplo, el impacto de cinco representantes de servicio al cliente ejecutando la aplicación de servicio al cliente durante la hora pico del día.

Capítulo 2. Supervisión de recursos 17

2.4. ¿Qué monitorizar?

Como se indicó anteriormente, los recursos presentes en cada sistema son poder de CPU, ancho de banda, memoria y almacenamiento. En el primer vistazo, parecería que la supervisión sólo consistiría de examinar estas cuatro cosas.

Lamentablemente, no es tan simple. Por ejemplo, considere una unidad de disco. ¿Qué cosas podría querer saber sobre su utilización?

• ¿Cuánto espacio libre está disponible?

• ¿Cuántas operaciones de E/S realiza en promedio por segundo?

• ¿Cuánto tiempo en promedio toma en completarse cada operación de E/S?

• ¿Cuántas de esas operaciones de E/S son lecturas? ¿Cuántas son escrituras?

• ¿Cuál es la cantidad promedio de datos leídos/escritos con cada E/S?

Hay más formas de estudiar el rendimiento de una unidad de disco; estos puntos solamente tocan la superficie. El concepto principal a tener en mente es que hay muchos tipos diferentes de datos para cada recurso.

Las siguientes secciones exploran los tipos de información de utilización que serían útiles para cada uno de los principales tipos de recursos.

2.4.1. Monitorizar el poder de CPU

En su forma más básica, monitorizar el poder de CPU significa determinar si la utilización del CPU alcanza alguna vez el 100%. Si la utilización del CPU se mantiene por debajo de 100%, sin importar lo que el sistema esté haciendo, hay poder de procesamiento adicional para más trabajo.

Sin embargo, es raro que un sistema no alcance el 100% de utilización de CPU al menos una vez. En ese momento es importante examinar en más detalle los datos de utilización de CPU. Haciendo esto, se hace posible comenzar a determinar donde se consume la mayoría del poder de procesamiento. He aquí algunas de las estadísticas más populares de utilización de CPU:

Usuario contra Sistema

El porcentaje de tiempo consumido realizando procesamiento a nivel de usuario contra procesamiento a nivel de sistema, puede indicar si la carga de un sistema se debe principalmente a las aplicaciones que se están ejecutando o a la sobrecarga del sistema operativo. Altos porcentajes de procesamiento a nivel de usuario tiende a ser bueno (asumiendo que los usuarios están experimentando un rendimiento satisfactorio), mientras que altos porcentajes de procesamiento a nivel de sistema tiende a apuntar hacia problemas que requerirían mayor investigación.

Cambios de contexto

Un cambio de contexto ocurre cuando el CPU para de ejecutar un proceso y comienza a ejecutar otro. Debido a que cada contexto requiere que el sistema operativo tome el control del CPU, cambios excesivos de contexto y altos niveles de consumo de CPU a nivel de sistema, tienden a ir de la mano.

Interrupciones

Como su nombre lo implica, las interrupciones son situaciones donde el procesamiento realizado por el CPU se cambia abruptamente. Las interrupciones ocurren generalmente debido a actividad del hardware (tal como un dispositivo de E/S que termina una operación) o del software (tales como interrupciones de software que controlan el procesamiento de una aplicación).


Procesos ejecutables

Un proceso puede tener diferentes estados. Por ejemplo, puede estar:

• Esperando porque se termine una operación de E/S

• Esperando porque el subsistema de administración de memoria resuelva un fallo de página

En estos casos, el proceso no tiene necesidad del CPU.

Sin embargo, eventualmente el estado del proceso cambia y el proceso se vuelve ejecutable. Como su nombre lo implica, un proceso ejecutable es aquel capaz de realizar el trabajo tan pronto como reciba tiempo de CPU. Sin embargo, si hay más de un proceso ejecutable en un momento determinado, todos excepto uno1 de los procesos deben esperar por su turno de CPU. Monitorizando el número de procesos ejecutables, es posible determinar cuan comprometido está el CPU en su sistema.

Otras métricas de rendimiento que reflejan un impacto en la utilización del CPU tienden a incluir servicios diferentes que el sistema operativo proporciona a los procesos. Estas pueden incluir estadísticas sobre la administración de memoria, procesamiento de E/S, etc. Estas estadísticas también revelan que, cuando el rendimiento del sistema está siendo supervisado, no hay límites entre las diferentes estadísticas. En otras palabras, las estadísticas de utilización de CPU pueden terminar apuntando a un problema en el subsistema de E/S, o las estadísticas de utilización de memoria pueden revelar un defecto de una aplicación.

Por lo tanto, cuando esté supervisando el funcionamiento del sistema, no es posible examinar una estadística de forma totalmente aislada; solamente mediante el exámen del cuadro completo es posible extraer información significativa de cualquier estadística de rendimiento que reuna.

2.4.2. Monitorizar el ancho de banda

Monitorizar el ancho de banda es más complicado que la supervisión de otros recursos descritos aquí. La razón de esto se debe al hecho de que las estadísticas de rendimiento tienden a estar basadas en dispositivos, mientras que la mayoría de los lugares en los que es importante el ancho de banda tienden a ser los buses que conectan dispositivos. En lo casos donde más de un dispositivo comparte un bus común, puede encontrar estadísticas razonables para cada dispositivo, pero la carga que esos dispositivos colocan en el bus es mucho mayor.

Otro reto al monitorizar el ancho de banda es que pueden existir circunstancias donde las estadísticas para los dispositivos mismos no estén disponibles. Esto es particularmente verdadero para los buses de expansión del sistema y datapaths2 . Sin embargo, aún cuando no siempre tendrá disponibles estadísticas relacionadas al ancho de banda 100% exactas, a menudo se encuentra información suficiente para hacer posible cierto nivel de análisis, particularmente cuando se toman en cuenta estadísticas relacionadas.

Algunas de las estadísticas más comunes relacionadas al ancho de banda son:

Bytes recibidos/enviados

Las estadísticas de la interfaz de red proporcionan un indicativo de la utilización del ancho de banda de uno de los buses más visibles — la red.

Cuentas y tasas de interfaz

Estas estadísticas relacionadas a la red dan indicaciones de colisiones excesivas, errores de transmisión/recepción y más. Con el uso de estas estadísticas (particularmente si las estadísticas están disponibles para más de un sistema en su red), es posible realizar un fragmento de resolución de problemas de la red antes de utilizar las herramientas de diagnóstico de la red más comunes.

1. Asumiendo que se trata de un sistema con un único procesador. 2. Puede encontrar más información sobre buses, datapaths y ancho de banda en el Capítulo 3.


Transferencias por segundo

Normalmente reunida por dispositivos de E/S en bloques, tales como discos y unidades de cinta de alto rendimiento, esta estadística es una buena forma de determinar si se está alcanzando el límite del ancho de banda de un dispositivo particular. Debido a su naturaleza electromecánica, las unidades de disco y de cinta solamente pueden realizar ciertas operaciones de E/S cada segundo; su rendimiento se ve afectado rápidamente a medida que se alcanza a este límite.

2.4.3. Monitorizar la memoria

Si existe un área en la que se puede encontrar gran cantidad de estadísticas de rendimiento, esta área es la utilización de la memoria. Debido a la complejidad inherente de los sistemas operativos con memoria virtual bajo demanda de hoy día, las estadísticas de utilización de memoria son muchas y variadas. Es aquí donde tiene lugar la mayoría del trabajo de un administrador de sistemas con la administración de recursos.

Las estadísticas siguientes representan una descripción precipitada de las estadísticas de administración de memoria encontradas más a menudo:

Páginas dentro/fuera

Estas estadísticas hacen posible medir el flujo de páginas desde la memoria del sistema a los dispositivos de almacenamiento masivo (usualmente unidades de disco). Altas tasas de estas estadísticas pueden representar que el sistema está corto de memoria física y que está haciendo thrashing o consumiendo más recursos del sistema en mover las páginas dentro y fuera de memoria que en ejecutando aplicaciones.

Páginas activas/inactivas

Estas estaditicas muestran qué tanto se están utilizando las páginas residentes en memoria. Una falta de páginas inactivas puede estar apuntando hacia una escasez de memoria física.

Páginas libres, compartidas, en memoria intermedia o en caché

Estas estadísticas proporcionan detalles adicionales sobre las estadísticas más simples de páginas activas/inactivas. Usando estas estadísticas es posible determinar la mezcla general de utilización de memoria.

Intercambio dentro/fuera

Estas estadísticas muestran el comportamiento general de la memoria de intercambio del sistema. Tasas excesivas pueden estar apuntando a una escasez de memoria física.

La supervisión exitosa de la utilización de la memoria requiere una buena comprensión de cómo funciona la memoria virtual bajo demanda de un sistema operativo. Mientras que esta materia puede tomar un libro completo, los conceptos básicos se discuten en el Capítulo 4. Este capítulo junto con tiempo invertido en monitorizar el sistema, le da los bloques de construcción necesarios para aprender más sobre este tópico.

2.4.4. Monitorizar el almacenamiento

El monitoreo del almacenamiento normalmente tiene lugar en dos niveles diferentes:

• Monitorizar insuficiente espacio en disco

• Monitorizar problemas de rendimiento relacionados con el almacenamiento

La razón de esto es que es posible tener problemas calamitosos en un área y ningún problema en otra. Por ejemplo, es posible causar que a la unidad de disco se le acabe el espacio sin causar ningún tipo de


problemas relacionados al rendimiento. De la misma manera, es posible tener una unidad de disco que tiene 99% de espacio libre, pero que se ha puesto más allá de sus límites en términos de rendimiento.

Sin embargo, es más probable que el sistema promedio experimente diferentes grados de escasez de recursos en ambas áreas. Debido a esto, es probable que — hasta cierto punto — los problemas en un área impacten a la otra. La mayoría de las veces este tipo de interacción toma la forma de funcionamientos de E/S más y más pobres cuando el sistema se acerca al 0% de espacio libre, en casos de cargas de E/S extremas, es posible reducir las salidas de E/S a tal nivel que las aplicaciones no se ejecutan adecuadamente.

En cualquier caso, las estadísticas siguientes son útiles para supervisar el almacenamiento:

Espacio libre

El espacio libre es probablemente el recurso que todos los administradores de sistemas vigilan más de cerca; sería raro el administrador que no verifica el espacio disponible (o que tiene una forma de hacerlo automáticamente).

Estadísticas relacionadas al sistema de archivos

Estas estadísticas (tales como el número de archivos/directorios, tamaño promedio de los archivos, etc.) suministran detalles adicionales sobre un porcentaje de espacio libre. Como tal, estas estadísticas hacen posible para los administradores de sistemas configurar el sistema para que entregue el mejor rendimiento, pues la carga de E/S impuesta por un sistema de archivos lleno de muchos pequeños archivos no es la misma que la carga impuesta por un sistema de archivos lleno con un único archivo enorme.

Transferencias por segundo

Esta estadística es una buena forma de determinar si se están alcanzando las limitaciones de ancho de banda de un dispositivo en particular.

Lecturas/escrituras por segundo

Con un desglose más detallado de las transferencias por segundo, estas estadísticas permiten al administrador de sistemas entender mejor la naturaleza de las cargas de E/S que está experimentando un dispositivo de almacenamiento. Esto puede ser crítico, ya que algunas tecnologías de almacenamiento tienen características de funcionamiento muy diferentes para operaciones de lecturas contra escrituras.


Red Hat Enterprise Linux viene con una variedad de herramientas para monitorizar recursos. Mientras que existen más de las que aquí se listan, estas herramientas son representativas en términos de funcionalidad. Las herramientas son:

• free

• top (y el Monitor del Sistema de GNOME, una versión de top más orientada a lo gráfico)

• vmstat

• La suite de herramientas de supervisión de recursos de Sysstat

• El perfilador global del sistema OProfile

Examinemos cada una con más detalles.


2.5.1. free

El comando free muestra la utilización de la memoria del sistema. He aquí un ejemplo de esta salida:

total used free shared buffers cached Mem: 255508 240268 15240 0 7592 86188 -/+ buffers/cache: 146488 109020 Swap: 530136 26268 503868

La fila Mem: muestra la utilización de la memoria física, mientras que la fila Swap: muestra la utilización del espacio de intercambio (swap) del sistema. La fila -/+ buffers/cache: muestra la cantidad de memoria actualmente dedicada a las memorias intermedias del sistema (buffers).

Puesto que por defecto free solamente muestra la utilización de memoria una vez, solamente es útil para una supervisión de corto tiempo, o para determinar rápidamente si un problema relacionado con la memoria está en progreso actualmente. Aunque free tiene la habilidad de mostrar repetidamente los números de utilización de memoria a través de su opción -s, la salida se desplaza, haciendo difícil detectar cambios en la utilización de memoria.

Sugerencia

Una mejor solución que utilizar free -s, sería ejecutar el comando free usando el comando watch. Por ejemplo, para mostrar la utilización de memoria cada dos segundos (el intervalo de muestra predeterminado para watch), utilice este comando:

watch free

El comando watch ejecuta el comando free cada dos segundos, limpiando la pantalla para mostrar la salida actualizada y volviendo a escribir en la misma ubicación de pantalla. Esto hace mucho más fácil determinar cómo cambia la utilización de memoria con el tiempo, pues no es necesario escanear contínuamente desplazando la salida. Puede controlar el retraso entre actualizaciones usando la opción -n y causar que cualquier cambio entre actualizaciones sea resaltado usando la opción -d, como en el comando siguiente:

watch -n 1 -d free

Para más información, consulte la página man de watch.

El comando watch se ejecuta hasta ser interrupido con [Ctrl]-[C]. El comando watch es uno a recordar; puede ser muy útil en muchas situaciones.

2.5.2. top

Mientras que free muestra solamente información relacionada con la memoria, el comando top hace un poquito de todo. Utilización del CPU, estadísticas de procesos, utilización de memoria — top lo monitoriza todo. Además, a diferencia de free command, el comportamiento predeterminado de top es el de ejecutarse de forma contínua, no hay necesidad de utilizar el comando watch. He aquí una muestra de la pantalla:

14:06:32 up 4 days, 21:20, 4 users, load average: 0.00, 0.00, 0.00 77 processes: 76 sleeping, 1 running, 0 zombie, 0 stopped CPU states: cpu user nice system irq softirq iowait idle

total 19.6% 0.0% 0.0% 0.0% 0.0% 0.0% 180.2% cpu00 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 100.0% cpu01 19.6% 0.0% 0.0% 0.0% 0.0% 0.0% 80.3%

Mem: 1028548k av, 716604k used, 311944k free, 0k shrd, 131056k buff 324996k actv, 108692k in_d, 13988k in_c


Swap: 1020116k av, 5276k used, 1014840k free 382228k cached

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 17578 root 15 0 13456 13M 9020 S 18.5 1.3 26:35 1 rhn-applet-gu 19154 root 20 0 1176 1176 892 R 0.9 0.1 0:00 1 top

1 root 15 0 168 160 108 S 0.0 0.0 0:09 0 init 2 root RT 0 0 0 0 SW 0.0 0.0 0:00 0 migration/0 3 root RT 0 0 0 0 SW 0.0 0.0 0:00 1 migration/1 4 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 keventd 5 root 34 19 0 0 0 SWN 0.0 0.0 0:00 0 ksoftirqd/0 6 root 35 19 0 0 0 SWN 0.0 0.0 0:00 1 ksoftirqd/1 9 root 15 0 0 0 0 SW 0.0 0.0 0:07 1 bdflush 7 root 15 0 0 0 0 SW 0.0 0.0 1:19 0 kswapd 8 root 15 0 0 0 0 SW 0.0 0.0 0:14 1 kscand 10 root 15 0 0 0 0 SW 0.0 0.0 0:03 1 kupdated 11 root 25 0 0 0 0 SW 0.0 0.0 0:00 0 mdrecoveryd

La pantalla se divide en dos secciones. La parte superior contiene información relacionada con el estatus general del sistema — tiempo ejecutándose, carga promedio, cuentas de procesos, estado del CPU y estadísticas de utilización para la memoria y el espacio de intercambio. La sección de abajo muestra estadísticas a nivel de procesos. Es posible cambiar lo que se muestra mientras top se ejecuta. Por ejemplo, por defecto top muestra procesos activos y ociosos. Para mostrar solamente procesos activos o que no estén ociosos, presione [i]; otro toque lo retorna al modo de visualización predeterminado.

Atención

Aún cuando top pareciera como un simple programa de visualización, este no es el caso. Esto es porque top utiliza comandos de carácteres simples para llevar a cabo diferentes operaciones. Por ejemplo, si usted está conectado como root, le es posible cambiar la prioridad y hasta matar cualquier proceso en su sistema. Por lo tanto, hasta que no haya revisado la pantalla de ayuda de top (escriba [?] para mostrar la ayuda), es más seguro solamente pulsar [q] (sale de top).

2.5.2.1. La aplicación Monitor del Sistema GNOME — Un top gráfico

Si se siente más a gusto con las interfaces gráficas de usuarios, la aplicación Monitor del Sistema GNOME puede ser más de su agrado. De la misma forma que top, el Monitor del Sistema GNOME muestra información relacionada al estado general del sistema, cuentas de procesos, utilización de memoria y de swap y estadísticas a nivel de procesos.

Sin embargo, el Monitor del Sistema GNOME va un paso más allá incluyendo también representaciones gráficas del CPU, utilización de memoria y de intercambio, junto con un listado tabular de la utilización del espacio en disco. Un ejemplo del Listado de procesos del Monitor del Sistema GNOME aparece en la Figura 2-1.


Figura 2-1. La pantalla Listado de procesos del Monitor del sistema

Se puede mostrar información adicional sobre un proceso específico pulsando primero en el proceso deseado y luego pulsando en el botón Más Info.

Para mostrar las estadísticas de uso de memoria, CPU y uso del disco, pulse la pestaña Monitor del sistema.

2.5.3. vmstat

Para una comprensión más concisa del rendimiento del sistema, intente con vmstat. Con vmstat, es posible obtener una vista general de los procesos, memoria, swap, E/S, sistema y actividad de CPU en una línea de números:

procs memory swap io system cpu r b swpd free buff cache si so bi bo in cs us sy id wa

0 5276 315000 130744 380184 1 1 2 24 14 50 1 1 47 0

La primera línea divide los campos en seis categorías, incluyendo procesos, memoria, swap, E/S, sistema y estadísticas relacionadas al CPU. La segunda línea identifica aún más los contenidos de cada campo, haciendo más fácil escanear datos para ver estadísticas específicas.

Los campos relacionados a procesos son:

• r — El número de procesos ejecutables esperando para acceder al CPU

• b — El número de procesos en un estado dormido contínuo

Los campos relacionados a la memoria son:

0


• swpd — La cantidad de memoria utilizada

• free — La cantidad de memoria libre

• buff — La cantidad de memoria utilizada por las memorias intermedias

• cache — La cantidad de memoria utilizada como caché de páginas

Los campos relacionados a swap son:

• si — La cantidad de memoria intercambiada desde el disco

• so — La cantidad de memoria intercambiada hacia el disco

Los campos relacionados con E/S son:

• bi — Los bloques enviados a un dispositivo de bloques

• bo — Los bloques recibidos desde un dispositivo de bloques

Los campos relacionados al sistema son:

• in — El número de interrupciones por segundo

• cs — El número de cambios de contexto por segundo

Los campos relacionados al CPU son:

• us — El porcentaje de tiempo que el CPU ejecutó código de nivel del usuario

• sy — El porcentaje de tiempo que el CPU ejecutó código de nivel del sistema

• id — El porcentaje de tiempo que el CPU estaba desocupado

• wa — Esperas de E/S

Cuando se ejecuta vmstat sin opciones, solamente se muestra una línea. Esta línea contiene promedios, calculados desde la última vez que se arrancó el sistema.

Sin embargo, la mayoría de los administradores de sistemas no confían en los datos en esta línea, pues los tiempos en que fueron recopilados varían. En su lugar, la mayoría de los administradores tomas ventaja de la habilidad de vmstat de mostrar repetidamente datos de la utilización de recursos en intervalos establecidos. Por ejemplo, el comando vmstat 1 muestra una nueva línea de utilización de datos cada segundo, mientras que el comando vmstat 1 10, muestra una nueva línea por segundo, pero sólo por los próximos 10 segundos.

En manos de un administrador experimentado, vmstat puede ser usado para determinar rápidamente la utilización de recursos y problemas de rendimiento. Pero para obtener mayor conocimiento en estos problemas, se requiere un tipo de herramienta diferente — una herramienta capaz recolectar y analizar datos en mas detalles.

2.5.4. Las herramientas para monitorizar recursos de la suite Sysstat Mientras que las herramientas anteriores pueden ser de ayuda para ganar mayor conocimiento sobre el rendimiento del sistema en períodos muy cortos, son de poca utilidad en proporcionar más allá de una instantánea de la utilización de recursos del sistema. Además, hay aspectos del rendimiento del sistema que no se pueden monitorizar fácilmente usando tales herramientas tan simplísticas.

Por lo tanto, se requiere una herramienta más sofisticada. Sysstat es la herramienta.

Sysstat contiene las siguientes herramientas relacionadas con reunir estadísticas de E/S y CPU:


iostat

Muestra una descripción general de la utilización del CPU, junto con las estadísticas de E/S para uno o más unidades de disco.

mpstat

Muestra estadísticas de CPU más complejas.

Sysstat también contiene herramientas para reunir datos de utilización de los recursos y crear informes diarios basados en esos datos. Estas herramientas son:

sadc

Conocida como el coleccionador de datos de actividad del sistema, sadc reune información sobre la utilización de recursos y la escribe a un archivo.

sar

Los informes sar, producidos a partir de los archivos creados por sadc, se pueden generar interactivamente o se pueden escribir a un archivo para un análisis más intensivo.

Las secciones siguientes exploran cada una de estas herramientas con más detalles.

2.5.4.1. El comando iostat

El comando iostat en su forma más básica proporciona una descripción general de las estadísticas del CPU y E/S de disco:

Linux 2.4.20-1.1931.2.231.2.10.ent (pigdog.example.com) 07/11/2003

avg-cpu: %user %nice %sys %idle 6.11 2.56 2.15 89.18

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn dev3-0 1.68 15.69 22.42 31175836 44543290

Debajo de la primera línea (la cual contiene la versión del kernel del sistema y el nombre del host, junto con la fecha actual), iostat muestra una vista general de la utilización promedio del CPU desde el último arranque. El informe de utilización del CPU incluye los porcentajes siguientes:

• Porcentaje de tiempo en modo usuario (ejecutando aplicaciones, etc.)

• Porcentaje de tiempo en modo usuario (para procesos que han alterado su prioridad de planificación usando nice(2))

• Porcentaje de tiempo en modo kernel

• Porcentaje de tiempo ocioso

Debajo del informe de utilización del CPU está el informe de utilización de dispositivos. Este informe contiene una línea para cada dispositivo en el sistema e incluye la información siguiente:

• La especificación de dispositivos, mostrada como dev � major-number � -sequence-number, donde � major-number � es el número principal ("major") del dispositivo3 y � sequence-number � es un número secuencial comenzando desde cero.

• El número de transferencias (u operaciones de E/S) por segundo.

3. Los números "major" de dispositivos se pueden encontrar usando ls -l para mostrar el archivo de disposi

tivo deseado en /dev/. El número major aparece después de la especificación del grupo del dispositivo.


• El número de bloques de 512 bytes leídos por segundo.

• El número de bloques de 512 bytes escritos por segundo.

• El número total de bloques de 512 bytes leídos.

• El número total de bloques de 512 bytes escritos.

Esto es solamente un muestra de la información que se puede obtener usando iostat. Para más información, consulte la página man de iostat(1).

2.5.4.2. El comando mpstat

El comando mpstat aparece primero sin diferencias con el informe de utilización de CPU producido por iostat:


07:09:26 PM CPU %user %nice %system %idle intr/s 07:09:26 PM all 6.40 5.84 3.29 84.47 542.47

Con la excepción de una columna adicional mostrando las interrupciones por segundo manejadas por el CPU, no hay diferencia real. Sin embargo, la situación cambia si se utiliza la opción de mpstat, -P ALL.


07:13:03 PM CPU %user %nice %system %idle intr/s 07:13:03 PM all 6.40 5.84 3.29 84.47 542.47 07:13:03 PM 0 6.36 5.80 3.29 84.54 542.47 07:13:03 PM 1 6.43 5.87 3.29 84.40 542.47

En sistemas multiproceso, mpstat permite desplegar de forma individual la utilización de cada CPU, haciendo posible determinar que tan efectivamente se utiliza cada CPU.

2.5.4.3. El comando sadc

Como se estableció anteriormente, el comando sadc reune los datos de utilización del sistema y los escribe a un archivo para su análisis posterior. Por defecto, los datos son escritos a archivos en el directorio /var/log/sa/. Los archivos son llamados sa � dd � , donde � dd � es la fecha actual de dos dígitos.

sadc normalmente es ejecutado por el script sa1. cron invoca periódicamente este script a través del archivo sysstat, el cual está ubicado en /etc/cron.d/. El script sa1 invoca sadc por un intervalo único de un segundo. Por defecto, cron ejecuta sa1 cada 10 minutos, añadiendo los datos reunidos durante cada intervalo al archivo actual /var/log/sa/sa � dd � .

2.5.4.4. El comando sar

El comando sar produce informes de utilización del sistema basado en los datos reunidos por sadc. De acuerdo a la configuración en Red Hat Enterprise Linux, sar es ejecutado automáticamente para procesar los archivos reunidos automáticamente por sadc. Los archivos de informes se escriben a /var/log/sa/ y son nombrados sar � dd � , donde � dd � son las representaciones de dos dígitos de la fecha del día anterior.


Normalmente, sar es ejecutado por el script sa2. Periódicamente cron invoca este script a través del archivo sysstat, el cual se ubica en /etc/cron.d/. Por defecto, cron ejecuta a sa2 una vez al día, a las 23:53, permitiendo así producir un informe para los datos del día completo.

2.5.4.4.1. Lectura de informes sar

El formato de un informe sar generado por la configuración predeterminada de Red Hat Enterprise Linux consiste de múltiples secciones, con cada sección conteniendo un tipo de datos específico, ordenados por hora del día en que los datos fueron reunidos. Puesto que sadc está configurado para ejecutar un intervalo de un segundo cada 10 minutos, el informe sar predeterminado contiene datos en incrementos de 10 minutos, desde las 00:00 hasta las 23:504 .

Cada sección del informe comienza con un encabezado describiendo los datos contenidos en la sección. El encabezado se repite a intervalos regulares a lo largo de la sección, haciendo más fácil interpretar los datos mientras se hojea el informe. Cada sección termina con una línea conteniendo el promedio de datos informados en la sección.

He aquí una sección de ejemplo de un informe sar, con los datos desde 00:30 hasta 23:40 eliminados para ahorrar espacio:

00:00:01 CPU %user %nice %system %idle00:10:00 all 6.39 1.96 0.66 90.9800:20:01 all 1.61 3.16 1.09 94.14...23:50:01 all 44.07 0.02 0.77 55.14Average: all 5.80 4.99 2.87 86.34

En esta sección, se muestra la información de utilización del CPU. Esto es muy similar a los datos mostrados por iostat.

Otras secciones pueden tener más de una línea necesaria para datos, como se muestra en esta sección generada a partir de los datos de utilización del CPU en un sistema con dos procesadores:

00:00:01 CPU %user %nice %system %idle00:10:00 0 4.19 1.75 0.70 93.3700:10:00 1 8.59 2.18 0.63 88.6000:20:01 0 1.87 3.21 1.14 93.7800:20:01 1 1.35 3.12 1.04 94.49...23:50:01 0 42.84 0.03 0.80 56.3323:50:01 1 45.29 0.01 0.74 53.95Average: 0 6.00 5.01 2.74 86.25Average: 1 5.61 4.97 2.99 86.43

Hay un total de diecisiete secciones diferentes presente en los reportes generados por la configuración predeterminada de Red Hat Enterprise Linux para sar; se exploran algunas en los siguientes capítulos. Para más información sobre los datos contenidos en cada sección, consulte la página del manual de sar(1).

4. Debido a las cargas variantes del sistema, la hora real en la que los datos fueron tomados puede variar por

uno o dos segundos.


2.5.5. OProfile

El perfilador global del sistema OProfile, es una herramienta de supervisión con poca sobrecarga. Oprofile aprovecha el hardware de monitorización del rendimiento del procesador5 para determinar la naturaleza de los problemas relacionados al rendimiento.

El hardware de monitorización del rendimiento es parte del procesador mismo. Toma la forma de un contador especial, incrementado cada vez que ocurre un determinado evento (tal como que el procesador no esté ocioso o que los datos requeridos no se encuentren en caché). Algunos procesadores tienen más de uno de tales contadores y permiten la selección de tipos diferentes para cada contador.

Los contadores se pueden cargar con un valor inicial y producir una interrupción cuando se desborde el contador. Al cargar el contador con valores iniciales diferentes, es posible variar las tasas en las que ocurre la interrupción. De esta forma es posible controlar la tasa de muestra y, por lo tanto, el nivel de detalle obtenido desde los datos reunidos.

En un extremo, al establecer el contador de manera que genere una interrupción por desborde con cada evento, proporciona datos de rendimiento en extremo detalle (pero con una sobrecarga excesiva). En el otro extremo, al configurar el contador para que genere tan pocas interrupciones como sea posible solamente proporciona la vista más general del rendimiento del sistema (practicamente sin ninguna sobrecarga). El secreto para una monitorización efectiva es la selección de una tasa de muestra lo suficientemente alta como para capturar los datos requeridos, pero no tan alta como para sobrecargar el sistema con la monitorización.

Atención

Puede configurar OProfile para que produzca tanta sobrecarga como para dejar el sistema inutilizable. Por lo tanto, debe tener cuidado cuando seleccione los valores de contador. Por esta razón, el comando opcontrol soporta la opción --list-events, el cual despliega los diferentes tipos de eventos disponibles para el procesador instalado actualmente, junto con los valores de contador mínimos sugeridos para cada uno.

Es importante tener en mente el costo de la relación entre la tasa de muestra y la sobrecarga cuando se utiliza OProfile.

2.5.5.1. Componentes de OProfile

OProfile consiste de los siguientes componentes:

• Software de recolección de datos

• Software de análisis de datos

• Software de interfaz administrativa

El software de colección de datos consiste del módulo del kernel oprofile.o y el demonio oprofiled.

El software de análisis de datos incluye los programas siguientes:

op_time

Muestra el número y los porcentajes relativos de las muestras tomadas por cada archivo ejecutable

5. OProfile también puede utilizar un mecanismo de fallback (conocido como TIMER_INT) para aquellas

arquitecturas que no tienen el hardware de monitorización de rendimiento.


oprofpp

Muestra el número y el porcentaje relativo de muestras tomadas por función, instrucción individual o en salida estilo gprof.

op_to_source

Muestra código fuente anotado y o listados de acumulación

op_visualise

Presenta los datos reunidos de forma gráfica

Estos programas hacen posible mostrar los datos reunidos en diferentes formas.

El software de interfaz administrativa controla todos los aspectos de la colección de datos, desde especificar cuales eventos específicos serán monitorizados hasta arrancar y detener la colección de datos mismos. Esto se hace usando el comando opcontrol.

2.5.5.2. Un ejemplo de sesión de OProfile

Esta sección muestra una sesión de OProfile supervisando y analizando datos desde la configuración inicial hasta el análisis final de los datos. Es solamente un visión general introductoria; para información más detallada, consulte el Manual de administración del sistema de Red Hat Enterprise Linux.

Utilice opcontrol para configurar el tipo de datos a ser reunido con el comando siguiente:

opcontrol \ --vmlinux=/boot/vmlinux-‘uname -r‘ \ --ctr0-event=CPU_CLK_UNHALTED \ --ctr0-count=6000

Las opciones utilizadas aquí dirigen opcontrol a:

• Dirigir OProfile a una copia del kernel ejecutándose actualmente (--vmlinux=/boot/vmlinux-‘uname -r‘)

• Especificar que se utilizará el contador 0 del procesador y que el evento a supervisar es el tiempo cuando el CPU está ejecutando instrucciones (--ctr0-event=CPU_CLK_UNHALTED)

• Especificar que OProfile va a reunir muestras cada 6000th veces que el evento ocurra (--ctr0-count=6000)

Luego, verifique que el módulo del kernel oprofile esté cargado usando el comando lsmod:

Module Size Used by Not taintedoprofile 75616 1...

Confirme que el sistema de archivos de OProfile (ubicado en /dev/oprofile/) esté montado con el comando ls /dev/oprofile/:

0 buffer buffer_watershed cpu_type enable stats 1 buffer_size cpu_buffer_size dump kernel_only

(El número exacto de archivos varía de acuerdo al tipo de procesador.)

En este punto, el archivo /root/.oprofile/daemonrc contiene los parámetros requeridos por el software de recolección de datos:

CTR_EVENT[0]=CPU_CLK_UNHALTED CTR_COUNT[0]=6000

30

CTR_KERNEL[0]=1CTR_USER[0]=1CTR_UM[0]=0CTR_EVENT_VAL[0]=121CTR_EVENT[1]=CTR_COUNT[1]=CTR_KERNEL[1]=1CTR_USER[1]=1CTR_UM[1]=0CTR_EVENT_VAL[1]=one_enabled=1SEPARATE_LIB_SAMPLES=0SEPARATE_KERNEL_SAMPLES=0

Capítulo 2. Supervisión de recursos

VMLINUX=/boot/vmlinux-2.4.21-1.1931.2.349.2.2.entsmp

Luego, utilice opcontrol para arrancar la recolección de datos con el comando opcontrol --start:

Using log file /var/lib/oprofile/oprofiled.logDaemon started.Profiler running.

Verifique que el demonio oprofiled esté ejecutándose con el comando ps x | grep -i oprofiled:

32019 ? S 0:00 /usr/bin/oprofiled --separate-lib-samples=0 ... 32021 pts/0 S 0:00 grep -i oprofiled

(La línea de comandos real de oprofiled mostrada por ps es mucho más larga; sin embargo, la hemos truncado para propósitos de formato.)

Ahora se está monitorizando el sistema, con todos los datos reunidos por todos los ejecutables en el sistema. Los datos son almacenados en el directorio /var/lib/oprofile/samples/. Los archivos en este directorio siguen una convención de nombres un poco inusual. He aquí un ejemplo:

}usr}bin}less#0

La convención de nombres utiliza la ruta absoluta de cada archivo conteniendo código ejecutable, reemplazando los carácteres de barra oblícua (/) por llaves (}), y terminándose con una almohadilla (#) seguido de un número (en este caso, 0.) Por lo tanto, el archivo utilizado en este ejemplo representa los datos reunidos mientras se estaba ejecutando /usr/bin/less.

Una vez que los datos son reunidos, utilice alguna de las herramientas de análisis de datos para desplegarlos. Una de las buenas funcionalidades de OProfile es que no es necesario detener la recolección de datos antes de efectuar el análisis de datos. Sin embargo, debe esperar al menos a que se escriban un conjunto de muestras al disco, o utilice el comando opcontrol --dump para forzar las muestras al disco.

En el ejemplo siguiente, op_time se utiliza para mostrar (en orden inverso — desde el número más alto de muestras hasta el más bajo) las muestras que se han reunido:

3321080 48.8021 0.0000 /boot/vmlinux-2.4.21-1.1931.2.349.2.2.entsmp761776 11.1940 0.0000 /usr/bin/oprofiled368933 5.4213 0.0000 /lib/tls/libc-2.3.2.so293570 4.3139 0.0000 /usr/lib/libgobject-2.0.so.0.200.2205231 3.0158 0.0000 /usr/lib/libgdk-x11-2.0.so.0.200.2167575 2.4625 0.0000 /usr/lib/libglib-2.0.so.0.200.2123095 1.8088 0.0000 /lib/libcrypto.so.0.9.7a105677 1.5529 0.0000 /usr/X11R6/bin/XFree86...


Es una buena idea el uso de less cuando se genera un informe interactivamente, ya que los informes pueden ser de cientos de líneas. El ejemplo dado aquí se ha truncado por este motivo.

El formato para este informe en particular es que se produce una línea para cada archivo ejecutable para los que se tomaron muestras. Cada línea sigue el formato siguiente:

� � � �sample-count � sample-percent � unused-field � executable-name �

Donde:

�• sample-count � representa el número de muestras reunidas �

• sample-percent � representa el porcentaje de todas las muestras reunidas para este ejecutable en particular. �

• unused-field � es un campo que no se utiliza �

• executable-name � representa el nombre del archivo que contiene el código del ejecutable para el que se reunen las muestras.

Este reporte (producido en la mayoría de los sistemas ociosos) muestra que casi la mitad de todas las muestras fueron tomadas mientras que el CPU estaba ejecutando código dentro del kernel mismo. Luego en la línea estaba el demonio de colección de datos de OProfile, seguido por una variedad de bibliotecas y el servidor del sistema X Window, XFree86. Es de utilidad tomar en cuenta que para el sistema ejecutando la sesión de muestra, el valor del contador usado de 6000 representa el valor mínimo recomendado por opcontrol --list-events. Esto significa que — al menos para este sistema en particular — la sobrecarga de OProfile en su punto más alto, consume aproximadamente 11% del CPU.


Esta sección incluye varios recursos que se pueden utilizar para aprender más sobre monitorizar recursos y la materia específica a Red Hat Enterprise Linux discutida en este capítulo.


Los recursos siguientes son instalados en el curso normal de una instalación típica de Red Hat Enterprise Linux.

• La página man de free(1) — Aprenda a mostrar estadísticas de la memoria libre y utilizada.

• La página man de top(1) — Aprenda cómo mostrar la utilización del CPU y las estadísticas a nivel de procesos.

• La página man de watch(1) — Conozca cómo ejecutar periódicamente el programa especificado, mostrando la salida en la pantalla completa.

• La entrada del menú Ayuda del Monitor del sistema GNOME — Conozca cómo mostrar gráficamente estadísticas de procesos, CPU, memoria y de utilización de espacio en disco.

• La página man de vmstat(8) — Aprenda a desplegar una visión general concisa de los procesos y la utilización de memoria, swap, E/S y CPU.

• La página man de iostat(1) — Aprenda a mostrar estadísticas del CPU y E/S.

• La página man de mpstat(1) — Vea cómo se pueden mostrar estadísticas individuales de CPU en sistemas multiprocesos.

• La página man de sadc(8) — Conozca cómo reunir datos de la utilización del sistema.


• La página man de sa1(8) — Aprenda sobre este script que ejecuta periódicamente sadc.

• La página man de sar(1) — Vea como se pueden producir informes de utilización de recursos del sistema.

• La página man de sa2(8) — Aprenda a crear archivos de informes diarios de la utilización de recursos del sistema.

• La página man de nice(1) — Aprenda a cambiar la prioridad de planificación de los procesos.

• La página man de oprofile(1) — Vea como se perfila el rendimiento del sistema.

• La página man de op_visualise(1) — Conozca cómo presentar gráficamente datos de OProfile.

2.6.2. Sitios Web útiles

• http://people.redhat.com/alikins/system_tuning.html — System Tuning Info for Linux Servers. Un enfoque de corriente consciente sobre la optimización del rendimiento y supervisión de recursos para servidores.

• http://www.linuxjournal.com/article.php?sid=2396 — Performance Monitoring Tools for Linux. Esta página del Linux Journal está enfocada hacia el administrador interesado en escribir una solución gráfica personalizada de rendimiento. Escrita hace varios años atrás, algunos de los detalles quizás ya no se apliquen, pero el concepto general y la ejecución están bien fundadas.

• http://oprofile.sourceforge.net/ — El sitio web del proyecto OProfile. Incluye recursos valiosos de OProfile, incluyendo apuntadores a las listas de correo y al canal #oprofile IRC.


Los libros siguientes discuten varios tópicos relacionados con la monitorización de recursos y son buenas fuentes para los administradores de sistemas Red Hat Enterprise Linux.

• El Manual de administración del sistema de Red Hat Enterprise Linux; de Red Hat, Inc. — Incluye información sobre muchas de las herramientas de supervisión descritas aquí, incluyendo OProfile.

• Linux Performance Tuning and Capacity Planning por Jason R. Fink y Matthew D. Sherer; Sams — Proporciona descripciones más profundas de las herramientas de supervisión presentadas aquí incluyendo otras que pueden ser apropiadas para necesidades de supervisión de recursos más específicas.

• Red Hat Linux Security and Optimization por Mohammed J. Kabir; Red Hat Press — Aproximadamente las primeras 150 páginas de este libro discuten problemas relacionados al rendimiento. Esto incluye capítulos dedicados a los problemas de rendimiento específicos a la red, Web, correo electrónico y servidores de archivos.

• Linux Administration Handbook por Evi Nemeth, Garth Snyder y Trent R. Hein; Prentice Hall — Proporciona un capítulo corto similar en ámbito al de este libro, pero incluye una sección interesante sobre el diagnóstico de un sistema que se vuelve lento repentinamente.

• Linux System Administration: A User’s Guide por Marcel Gagne; Addison Wesley Professional — Contiene un pequeño capítulo sobre la supervisión del rendimiento y optimización.

Capítulo 3. Ancho de banda y poder de procesamiento

De los dos recursos discutidos en este capítulo, uno (el ancho de banda) es a menudo difícil de entender para los nuevos administradores de sistemas, mientras que el otro concepto (poder de procesamiento), es usualmente mucho más fácil de comprender.

Adicionalmente, puede parecer que estos dos recursos no están muy relacionados — ¿por qué agruparlos?

La razón para referirse a estos dos recursos juntos es porque están basados en el hardware que se une directamente con la habilidad del computador de mover y procesar datos. Como tal, su relación a menudo está interrelacionada.

3.1. Ancho de banda

En su forma más simple, el ancho de banda es la capacidad de transferencia de datos — en otras palabras, la cantidad de datos que se pueden mover de un punto a otro en cierta cantidad de tiempo. El tener una comunicación de datos de punto a punto implica dos cosas:

• Un conjunto de conductores eléctricos utilizados para hacer posible la comunicación a bajo nivel

• Un protocolo para facilitar la comunicación de datos confiable y eficiente

Hay dos tipos de componentes de sistemas que satisfacen estos requerimientos:

• Buses

• Datapaths

Las secciones siguientes exploran cada uno de estos en más detalles.

3.1.1. Buses

Como se mencionó anteriormente, los buses permiten la comunicación de punto a punto y utilizan algún tipo de protocolo para asegurarse de que toda la comunicación toma lugar de forma controlada. Sin embargo, los buses tienen otras características distintivas:

• Características eléctricas estandarizadas (tales como el número de conductores, niveles de voltage, velocidades de señales, etc.)

• Características mecánicas estandarizadas (tales como el tipo de conector, tamaño de la tarjeta, formato físico, etc.)

• Protocolo estándar

La palabra "estandarizado" es importante porque los buses son la principal forma en la que diferentes componentes de software se juntan.

En muchos casos, los buses permiten la interconexión del hardware hecho por diferentes fabricantes; sin estandarización, esto no sería posible. Sin embargo, aún en situaciones donde un bus es propiedad de un fabricante, la estandarización es importante porque permite a ese fabricante implementar más fácilmente diferentes componentes usando una interfaz común — el bus mismo.

34 Capítulo 3. Ancho de banda y poder de procesamiento

3.1.1.1. Ejemplos de buses

No importa dónde en el computador usted revise, habrá buses. He aquí algunos de los más comunes:

• Buses de almacenamiento masivo (ATA y SCSI)

• Redes1 (Ethernet y Token Ring)

• Los buses de memoria (PC133 y Rambus®)

• Buses de expansión (PCI, ISA, USB)

3.1.2. Datapaths

Los datapaths pueden ser más difíciles de identificar pero, como los buses, están en todas partes. También a igual que los buses, los datapaths permiten la comunicación punto a punto. Sin embargo, a diferencia de los buses, los datapaths:

• Utilizan un protocolo más simple (si es que lo utilizan)

• Tienen poca (o ninguna) estandarización mecánica

La razón de estas diferencias es que los datapaths son normalmente internos a algunos componentes de sistemas y no son usados para facilitar la interconexión ad-hoc de componentes diferentes. Como tal, los datapaths son muy optimizados para una situación particular, donde la velocidad y el bajo costo se prefieren sobre una flexibilidad más lenta y más costosa de propósito general.

3.1.2.1. Ejemplos de Datapaths

He aquí algunos datapaths típicos:

• Datapath de CPU a caché en chip

• Datapath de procesador gráfico a memoria de vídeo

3.1.3. Problemas potenciales relacionados al ancho de banda

Hay dos formas en la que pueden ocurrir problemas relacionados al ancho de banda (tanto para buses como para datapaths):

1. El bus o datapath puede representar un recurso compartido. En esta situación, los altos niveles de competencia por el bus reducen el ancho de banda efectivo disponible para todos los dispositivos en el bus.

Un bus SCSI con discos duros altamente activos serían un buen ejemplo de esto. Las unidades de disco altamente activas saturan el bus SCSI, dejando poco ancho de banda disponible para cualquier otro dispositivo en el mismo bus. El resultado final es que toda la E/S a cualquiera de estos dispositivos en el bus es lenta, aún si cada dispositivo en el bus no está demasiado activo.

2. El bus o datapath puede ser un recurso dedicado con un número fijo de dispositivos conectados a él. En este caso, las características eléctricas del bus (y hasta cierto punto la naturaleza del protocolo utilizado) limitan el ancho de banda disponible. Usualmente, este es más el caso con datapaths que con buses. Esta es una de las razones por las que los adaptadores gráficos tienden a funcionar más lentamente cuando se operan a altas resoluciones y/o profundidades de color —

1. En vez de un bus interno al sistema, las redes pueden ser pensadas como un bus inter-sistema.

Capítulo 3. Ancho de banda y poder de procesamiento 35

por cada refrescado de pantalla, hay más datos que transmitir a través del datapath que conecta la memoria de vídeo al procesador gráfico.

3.1.4. Soluciones potenciales relacionadas al ancho de banda

Afortunadamente, los problemas relacionados al ancho de banda se pueden resolver. De hecho, se pueden tomar varios enfoques:

• Distribuir la carga

• Reducir la carga

• Incrementar la capacidad

Las secciones siguientes exploran cada uno de estos enfoques en mas detalles.

3.1.4.1. Distribuir la carga

El primer enfoque es distribuir más uniformemente la actividad del bus. En otras palabras, si un bus está sobrecargado y otro está ocioso, quizás la situación sería mejorada moviendo algo de la carga hasta el bus ocioso.

Como administrador del sistema, este es el primer enfoque que debería considerar, pues a menudo existen buses adicionales ya instalados en su sistema. Por ejemplo, la mayoría de los PCs incluyen al menos dos canales ATA (lo cual es simplemente otro nombre para un bus). Si tiene dos unidades de disco ATA y dos canales ATA, ¿por qué deberían estar ambas unidades en el mismo canal?

Aún si su configuración no incluye buses adicionales, distribuir la carga puede ser todavía el mejor enfoque. Los gastos de hardware en hacer esto serán mucho menos costosos que reemplazando un bus existente por hardware con mayor capacidad.

3.1.4.2. Reducir la carga

A primera vista, el reducir y distribuir la carga parecen ser los diferentes lados de la misma moneda. Después de todo, cuando uno distribuye la carga, también se está reduciendo la misma (al menos en un bus sobrecargado), ¿cierto?

Mientras que este punto de vista es correcto, no es lo mismo que reducir la carga globalmente. La clave aquí es determinar si hay algún aspecto de la carga del sistema que esté causando que este bus particular esté sobrecargado. Por ejemplo, ¿está la red sobrecargada debido a actividades que no son necesarias? Quizás un pequeño archivo temporal es el recipiente de grandes lecturas/escrituras de E/S. Si ese archivo temporal reside en un servidor de la red, se podría eliminar una gran parte del tráfico de la red trabajando con el archivo localmente.

3.1.4.3. Incrementar la capacidad

La solución obvia a un ancho de banda insuficiente, es el de incrementarlo de alguna manera. Sin embargo, esto es usualmente una proposición costosa. Considere, por ejemplo, un controlador SCSI y su bus sobrecargado. Para incrementar el ancho de banda, se necesita reemplazar el controlador SCSI (y probablemente todos los dispositivos conectados a el) con hardware más rápido. Si el controlador SCSI es una tarjeta separada, esto sería un proceso bien directo, pero si el controlador es parte de la tarjeta madre del sistema, se vuelve mucho más difícil justificar económicamente este cambio.


3.1.5. En resumen. . . Todos los administradores de sistemas deberían estar conscientes del ancho de banda y de cómo la configuración y uso del sistema impacta el ancho de banda disponible. Desafortunadamente, no siempre es aparente cuando se trata de un problema de ancho de banda y cuando no. Algunas veces, el problema no es el bus mismo, pero uno de los componentes conectados al bus.

Por ejemplo, considere un adaptador SCSI que está conectado a un bus PCI. Si hay problemas de rendimiento con la E/S del disco SCSI, puede ser el resultado de un adaptador SCSI funcionando muy mal, aún cuando los buses SCSI y PCI mismos no esten ni siquiera cerca de sus capacidades de ancho de banda.

3.2. Poder de procesamiento

A menudo conocido como poder de CPU, ciclos de CPU y otros nombres diferentes, el poder de procesamiento es la habilidad de un computador de manejar datos. El poder de procesamiento varía con la arquitectura (y la velocidad del reloj) del CPU — usualmente los CPUs con velocidades del reloj más lentas y aquellos soportando tamaños de palabras más grandes tienen más poder de procesamiento que los CPUs más lentos que soportan tamaños de palabras más pequeños.

3.2.1. Hechos sobre el poder de procesamiento

He aquí los dos principales hechos sobre el poder de procesamiento que debería tener en mente:

• El poder de procesamiento es fijo

• El poder de procesamiento no se puede almacenar

El poder de procesamiento es fijo, en el sentido de que el CPU solamente puede ir a cierta velocidad. Por ejemplo, si necesita sumar dos números (una operación que toma solamente una instrucción de máquina en la mayoría de las arquitecturas) un CPU particular lo puede hacer a una velocidad y solamente a una velocidad. Con pocas excepciones, ni siquiera es posible reducir la velocidad en la que el CPU procesa las instrucciones, mucho menos incrementarla.

El poder de procesamiento también es fijo en otro sentido: es finito. Esto es, hay límites para los tipos de CPUs que se pueden conectar a un computador determinado. Algunos sistemas son capaces de soportar un amplio rango de CPUs de diferentes velocidades, mientras que otros quizás no se puedan actualizar para nada2 .

El poder de procesamiento no se puede almacenar para usarse más tarde. En otras palabras, si un CPU puede procesar 100 millones de instrucciones en un segundo, un segundo de tiempo ocioso equivale a gastar 100 millones de instrucciones de poder de procesamiento.

Si tomamos estos hechos y los examinamos desde una perspectiva ligeramente diferente, un CPU "produce" una corriente de instrucciones ejecutadas a una rata fija. Si el CPU "produce" instrucciones ejecutadas, esto significa que otra cosa debe "consumir" las mismas. La próxima sección define a estos consumidores.

3.2.2. Consumidores de poder de procesamiento

He aquí los dos principales consumidores de poder de procesamiento:

• Aplicaciones

2. Esta situación lleva a que se llame de forma jocosa actualización con carretilla, lo que significa un reemplazo

completo de un computador.


• El sistema operativo mismo

3.2.2.1. Aplicaciones

Los consumidores más obvios de poder de procesamiento son las aplicaciones y los programas que usted desea que el computador ejecute por usted. Desde una hoja de cálculo hasta una base de datos, las aplicaciones son la razón por las que usted tiene un computador.

Un único CPU puede solamente ejecutar una cosa en un momento dado. Por lo tanto, si su aplicación se está ejecutando, el resto de las cosas en el sistema no. Lo contrario, por supuesto, también es cierto — si algo diferente a su aplicación se está ejecutando, entonces su aplicación no está haciendo nada.

Pero como es que muchas aplicaciones diferentes pueden parecer que se estan ejecutando al mismo tiempo bajo un sistema operativo moderno? La respuesta es que estos son sistemas operativos multiproceso. En otras palabras, estos crean la ilusión de que muchas están sucediendo simultáneamente cuando en realidad es que esto no es posible. El truco es darle a cada proceso una fracción de segundo de ejecución en el CPU antes de darle el CPU a otro proceso para la próxima fracción de segundo. Si estos switches de contexto ocurren con la frecuencia necesaria, se logra la ilusión de que múltiples aplicaciones se ejecutan simultáneamente.

Por supuesto, las aplicaciones hacen otras cosas que manipular datos usando el CPU. Pueden también esperar por entradas del usuario así como también realizar E/S a dispositivos tales como discos duros y visualizaciones gráficas. Cuando ocurren estos eventos, la aplicación ya no necesita el CPU. En estos momentos, el CPU se puede utilizar para otros procesos ejecutando aplicaciones sin hacer más lento la aplicación en espera.

Además, el CPU puede ser utilizado por otro consumidor de poder de procesamiento: el sistema operativo mismo.

3.2.2.2. El Sistema Operativo

Es difícil determinar cuanto poder de procesamiento consume el sistema operativo. La razón de esto es que el sistema operativo utiliza una mezcla de código a nivel de procesos y a nivel del sistema para realizar su trabajo. Mientras que, por ejemplo, es fácil utilizar un supervisor de procesos para determinar qué está haciendo un proceso ejecutando un demonio o servicio, no es tan fácil determinar cuánto poder de procesamiento el sistema operativo consume por procesamiento a nivel del sistema relacionado con E/S (lo cual usualmente se hace dentro del contexto del proceso ejecutando la E/S).

En general, es posible dividir este tipo de sobrecarga de sistema operativo en dos tipos:

• Mantenimiento del sistema operativo

• Actividades relacionadas a procesos

El mantenimiento del sistema operativo incluye actividades tales como planificación de procesos y administración de memoria, mientras que las actividades relacionadas a procesos incluyen cualquier proceso que soporta al sistema operativo mismo, tales como procesos que manejan el registro de eventos globales al sistema o el vaciado de E/S de caché.

3.2.3. Mejorando la escasez de CPU

Cuando no hay suficiente poder de procesamiento para la carga de trabajo, tiene dos opciones:

• Reducir la carga

• Incrementar la capacidad


3.2.3.1. Reducir la carga

Reducir la carga de CPU es algo que se puede hacer sin el gasto monetario. El truco es identificar aquellos aspectos de la carga del sistema bajo su control que se pueden reducir. Hay tres áreas en las que enfocarse:

• Reducir la sobrecarga del sistema operativo

• Reducir la sobrecarga de las aplicaciones

• Eliminar aplicaciones completas

3.2.3.1.1. Reducir la sobrecarga del sistema operativo

Para reducir la sobrecarga del sistema operativo, debe examinar su carga actual del sistema y determinar los aspectos del mismo que resultan en cantidades de sobrecarga excesivas. Estas áreas incluyen:

• Reducir la necesidad de planificación frecuente de procesos

• Reducir la cantidad de E/S realizada

No espere milagros, en un sistema razonablemente bien configurado, es poco probable notar un incremento del rendimiento sustancial al tratar de reducir la carga del sistema operativo. Esto se debe al hecho de que un sistema razonablemente bien configurado, por definición, resulta en una cantidad de sobrecarga mínima. Sin embargo, si su sistema está ejecutándose con poca RAM, por ejemplo, quizás pueda reducir la sobrecarga al mejorar la escasez de memoria.

3.2.3.1.2. Reducir la sobrecarga de aplicaciones

El reducir la sobrecarga de aplicaciones significa asegurarse de que la aplicación tiene todo lo que necesita para ejecutarse bien. Algunas aplicaciones presentan comportamientos diferentes bajo ambientes diferentes — una aplicación puede volverse muy comprometida en términos de computación cuando procesa ciertos tipos de datos, pero no para otros, por ejemplo.

El punto a tener en cuenta aquí es que debe entender las aplicaciones ejecutándose en su sistema si es que quiere que se ejecuten lo más eficientemente posible. A menudo esto implica trabajar con sus usuarios y/o los desarrolladores, para ayudar a descubrir en que formas se pueden hacer las aplicaciones para que se ejecuten más eficientemente.

3.2.3.1.3. Eliminar aplicaciones completas

Dependiendo de su organización, este enfoque puede que no esté disponible para usted, pues a menudo no es la responsabilidad del administrador del sistema dictar cuales aplicaciones se ejecutaran y cuales no. Sin embargo, si puede identificar cualquier aplicación conocida como "CPU hogs", quizás pueda influenciar para eliminarlas.

Hacer esto quizás implicará más de una persona. Los usuarios afectados definitivamente deben ser parte de este proceso; en muchos casos pueden tener el conocimiento y el poder político para llevar a cabo los cambios necesarios en las aplicaciones disponibles.

Sugerencia

Tenga en mente que una aplicación puede que no requiera ser eliminada de todos los sistemas de su organización. Probablemente pueda mover una aplicación hambrienta de CPU desde un sistema sobrecargado a otro sistema que esté prácticamente ocioso.


3.2.3.2. Incrementar la capacidad

Por supuesto, si no es posible reducir la demanda de poder de procesamiento, debe buscar formas de incrementar el poder de procesamiento disponible. Hacer esto cuesta dinero, pero se puede hacer.

3.2.3.2.1. Actualizar el CPU

El enfoque más directo es determinar si el CPU de su sistema puede ser actualizado. El primer paso es determinar si el CPU actual se puede eliminar. Algunos sistemas (principalmente portátiles) tienen CPUs que están soldados en un lugar, haciendo imposible una actualización. El resto, sin embargo, tienen CPUs en bancos, lo que hace posible su actualización — al menos en teoría.

Luego, debe investigar para determinar si existe un CPU más rápido para la configuración de su sistema. Por ejemplo, si su sistema actual tiene un CPU de 1GHz y existe una unidad de 2GHz del mismo tipo, entonces es posible hacer una actualización.

Finalmente, debe determinar la velocidad máxima del CPU soportada por su sistema. Continuando con el ejemplo anterior, aún si existe un CPU de 2GHz del mismo tipo, un intercambio simple de CPU no es una opción si su sistema solamente soporta procesadores ejecutándose a 1GHz o menos.

Si encuentra que no puede instalar un CPU más rápido en su sistema, sus opciones pueden estar limitadas a cambiar las tarjeta madre o hasta una actualización más costosa como la de tipo carretilla mencionada anteriormente.

Sin embargo, algunas configuraciones de sistemas permiten un enfoque ligeramente diferente. En vez de reemplazar el CPU existente, por que no añadir otro?

3.2.3.2.2. ¿Es el multiprocesamiento simétrico adecuado para Usted?

El multiprocesamiento simétrico (también conocido como SMP) hace posible que un sistema computacional tenga más de un CPU compartiendo todos los recursos del sistema. Esto significa, que a diferencia de un sistema uniprocesador, un sistema SMP puede en realidad tener más de un procesador ejecutándose al mismo tiempo.

A primera vista, pareciera el sueño de un administrador de sistemas. Primero que nada, SMP hace posible incrementar el poder de procesamiento de un CPU aún si no esta disponible un CPU con velocidades de reloj más rápidas — simplemente añadiendo otro CPU. Sin embargo, esta flexibilidad viene con algunas advertencias.

La primera advertencia es que no todos los sistemas son capaces de operar con SMP. Su sistema debe tener una tarjeta madre diseñada para soportar multiprocesamiento. Si no lo tiene, se necesitará (al menos) una actualización de la tarjeta madre.

La segunda advertencia es que SMP incrementa la sobrecarga del sistema. Esto tiene sentido si lo piensa un poco; con más CPUs para los cuales planificar trabajo, el sistema operativo requiere más ciclos de CPU para la sobrecarga. Otro aspecto de esto es que con múltiples CPUs, puede haber más competencia por los recursos del sistema. Debido a estos factores, la actualización de un sistema de procesadores dual a un sistema con cuatro procesadores, no significa un incremento de 100% de poder de CPU disponible. De hecho, dependiendo del hardware actual, la carga de trabajo y la arquitectura del procesador, es posible alcanzar un punto en el que la adición de otro procesador podría más bien reducir el rendimiento del sistema.

Otro punto a tener en mente es que SMP no ayuda a las cargas de trabajo consistentes de una aplicación monolítica con una sola corriente de ejecución. En otras palabras, si un programa grande, vinculado computacionalmente, se ejecuta como un único proceso sin hilos, no se ejecutará más rápido en un sistema SMP que en una máquina de un sólo procesador. De hecho, se podría ejecutar aún más lento debido al incremento de la sobrecarga que SMP trae consigo. Por estas razones, muchos administradores de sistemas sienten que cuando se trata de poder de procesamiento, una sola corriente de procesamiento es la mejor opción. Esto proporciona el máximo de poder de CPU con las menores restricciones sobre su uso.


Mientras que esta discusión pareciera indicar que SMP nunca es una buena idea, hay circunstancias en las que tiene sentido. Por ejemplo, los entornos ejecutando múltiples aplicaciones con gran demanda computacional son buenas candidatas para SMP. La razón de esto es que las aplicaciones que no hacen nada pero computar por largos períodos de tiempo mantienen la contienda entre los procesos activos (y por lo tanto, la sobrecarga del sistema operativo) a un mínimo, mientras que los procesos mismos mantienen cada CPU ocupado.

Otra cosa a tener en mente sobre SMP es que el rendimiento de un sistema SMP tiende a degradarse de forma más graciosa a medida que la carga del sistema se incrementa. Esto hace a los sistemas SMP populares en entornos de servidor y multiusuario, pues la mezcla de procesos siempre cambiantes pueden impactar menos la carga global del sistema en una máquina con múltiples procesadores.


La monitorización del ancho de banda y de la utilización del CPU bajo Red Hat Enterprise Linux implica utilizar las herramientas discutidas en el Capítulo 2; por lo tanto, si aún no ha leído ese capítulo, es bueno que lo haga antes de continuar.

3.3.1. Monitorizar el ancho de banda en Red Hat Enterprise Linux

Como se indicó en la Sección 2.4.2, es difícil monitorizar directamente la utilización del ancho de banda. Sin embargo, examinando las estadísticas a nivel de dispositivos, es posible medir a grandes rasgos si la insuficiencia de ancho de banda es un problema en su sistema.

Usando vmstat, es posible determinar si es excesiva la actividad general de los dispositivos examinando los campos bi y bo; además, revisando los campos si y so le dará un poco más de conocimiento sobre cuánta actividad de disco se debe a E/S relacionada a swap.

procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 1 0 0 0 248088 158636 480804 0 0 2 6 120 120 10 3 87

En este ejemplo, el campo bi muestra dos bloques/segundos escritos a los dispositivos en bloque (principalmente unidades de disco), mientras que el campo bo muestra seis bloques/segundos leído desde los dispositivos de bloque. Podemos determinar que ninguna de esta actividad se debe a intercambio de memoria (swap), ya que los campos si y so ambos muestran una tasa de E/S relacionada a swap de cero kilobytes/segundo.

Usando iostat, es posible obtener un poco más de detalles sobre la actividad relacionada al disco:

Linux 2.4.21-1.1931.2.349.2.2.entsmp (raptor.example.com) 07/21/2003


Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn dev8-0 1.10 6.21 25.08 961342 3881610 dev8-1 0.00 0.00 0.00 16 0

Esta salida nos muestra que el dispositivo con un número major de 8 (el cual es /dev/sda, el primer disco SCSI) tiene un promedio un poco mayor de una operación de E/S por segundo (el campo tsp). La mayoría de la actividad de E/S para este dispositivo fueron escrituras (el campo Blk_wrtn), con un poco más de 25 bloques escritos cada segundo (el campo Blk_wrtn/s).


Si se necesitan más detalles, utilice la opción -x de iostat:



Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz /dev/sda 13.57 2.86 0.36 0.77 32.20 29.05 16.10 14.53 54.52 /dev/sda1 0.17 0.00 0.00 0.00 0.34 0.00 0.17 0.00 133.40 /dev/sda2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11.56 /dev/sda3 0.31 2.11 0.29 0.62 4.74 21.80 2.37 10.90 29.42 /dev/sda4 0.09 0.75 0.04 0.15 1.06 7.24 0.53 3.62 43.01

Más allá de las largas líneas conteniendo más campos, la primera cosa a tener en mente es que esta salida de iostat está mostrando ahora estadísticas a un nivel de partición. Usando df para asociar los puntos de montaje con los nombres de dispositivos, es posible utilizar este informe para determinar si, por ejemplo, la partición conteniendo /home/ está experimentando una sobrecarga excesiva.

En realidad, cada línea de salida de iostat -x es más larga y contiene más información que esto; he aquí el resto de cada línea (agregando la columna del dispositivo para facilitar la lectura):

Device: avgqu-sz await svctm %util /dev/sda 0.24 20.86 3.80 0.43 /dev/sda1 0.00 141.18 122.73 0.03 /dev/sda2 0.00 6.00 6.00 0.00 /dev/sda3 0.12 12.84 2.68 0.24 /dev/sda4 0.11 57.47 8.94 0.17

En este ejemplo, es interesante observar que /dev/sda2 es la partición swap del sistema; obviamente, a partir de los muchos campos de esta particiónque leen 0.00, el swapping no es un problema en el sistema.

Otro punto interesante a tomar en cuenta es /dev/sda1. Las estadísticas para esta partición son inusuales; la actividad general parece baja, pero por qué el tamaño promedio de peticiones de E/S (el campo avgrq-sz), el tiempo promedio de espera (el campo await) y el tiempo promedio de servicio (el campo svctm) son mucho más grandes que en las otras particiones? La respuesta es que esta partición contiene el directorio /boot/, el cual es donde el kernel y el disco inicial ramdisk son almacenados. Cuando el sistema arranca, las lecturas de E/S (observe que solamente los campos rsec/s y rkB/s son diferentes de cero; no se hace ninguna escritura aquí de forma regular) usadas durante el proceso de arranque son para grandes números de bloques, resultando en despliegues iostat de esperas relativamente largas y tiempos de servicios.

Es posible utilizar sar para una vista de largo plazo de las estadísticas de E/S; por ejemplo, sar -b muestra un informe general de E/S:


12:00:00 AM tps rtps wtps bread/s bwrtn/s12:10:00 AM 0.51 0.01 0.50 0.25 14.3212:20:01 AM 0.48 0.00 0.48 0.00 13.32...06:00:02 PM 1.24 0.00 1.24 0.01 36.23Average: 1.11 0.31 0.80 68.14 34.79

Aquí, como en la pantalla inicial de iostat, las estadísticas son agrupadas para todos los dispositivos de bloque.


Usando sar -d se produce otro informe relacionado a E/S:


12:00:00 AM DEV tps sect/s12:10:00 AM dev8-0 0.51 14.5712:10:00 AM dev8-1 0.00 0.0012:20:01 AM dev8-0 0.48 13.3212:20:01 AM dev8-1 0.00 0.00...06:00:02 PM dev8-0 1.24 36.2506:00:02 PM dev8-1 0.00 0.00Average: dev8-0 1.11 102.93Average: dev8-1 0.00 0.00

Este informe proporciona información por dispositivo, pero con pocos detalles.

Mientras que no hay estadísticas explícitas mostrando la utilización del ancho de banda para un bus o datapath dado, al menos podemos determinar qué están haciendo los dispositivos y utilizar su actividad para determinar indirectamente la carga del bus.

3.3.2. Monitorizar la utilización del CPU en Red Hat Enterprise Linux

A diferencia del ancho de banda, la supervisión de la utilización del CPU es mucho más directa. Desde un porcentage de utilización de CPU en el Monitor del sistema GNOME, hasta las estadísticas más detalladas informadas por sar, es posible determinar de forma veraz cuánto poder de CPU está siendo utilizado y en qué.

Más allá del Monitor del sistema GNOME, top es la primera herramienta de supervisión de recursos discutida en el Capítulo 2 para proporcionar una representación más profunda de la utilización de CPU. A continuación se muestra un informe con top de una estación de trabajo con dos procesadores:

9:44pm up 2 days, 2 min, 1 user, load average: 0.14, 0.12, 0.09 90 processes: 82 sleeping, 1 running, 7 zombie, 0 stopped CPU0 states: 0.4% user, 1.1% system, 0.0% nice, 97.4% idle CPU1 states: 0.5% user, 1.3% system, 0.0% nice, 97.1% idle Mem: 1288720K av, 1056260K used, 232460K free, 0K shrd, 145644K buff Swap: 522104K av, 0K used, 522104K free 469764K cached

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 30997 ed 16 0 1100 1100 840 R 1.7 0.0 0:00 top 1120 root 5 -10 249M 174M 71508 S < 0.9 13.8 254:59 X 1260 ed 15 0 54408 53M 6864 S 0.7 4.2 12:09 gnome-terminal 888 root 15 0 2428 2428 1796 S 0.1 0.1 0:06 sendmail 1264 ed 15 0 16336 15M 9480 S 0.1 1.2 1:58 rhn-applet-gui

1 root 15 0 476 476 424 S 0.0 0.0 0:05 init 2 root 0K 0 0 0 0 SW 0.0 0.0 0:00 migration_CPU0 3 root 0K 0 0 0 0 SW 0.0 0.0 0:00 migration_CPU1 4 root 15 0 0 0 0 SW 0.0 0.0 0:01 keventd 5 root 34 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU0 6 root 34 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU1 7 root 15 0 0 0 0 SW 0.0 0.0 0:05 kswapd 8 root 15 0 0 0 0 SW 0.0 0.0 0:00 bdflush 9 root 15 0 0 0 0 SW 0.0 0.0 0:01 kupdated 10 root 25 0 0 0 0 SW 0.0 0.0 0:00 mdrecoveryd

La primera información relacionada con el CPU se presenta en la primera línea: la carga promedio. La carga promedio es un número correspondiente al número promedio de procesos ejecutables en el


sistema. La carga promedio es a menudo listada como tres conjuntos de números (como lo hace top), lo que representa la carga promedio para los últimos 1, 5 y 15 minutos, indicando que el sistema en este ejemplo no estaba muy ocupado.

La línea siguiente, aunque no está relacionada estrictamente a la utilización del CPU, tiene una relación indirecta, en que muestra el número de procesos ejecutables (aquí, solamente uno -- recuerde este número, pues significa algo especial en este ejemplo). El número de procesos ejecutables es un buen indicador de cuan comprometido computacionalmente puede estar un sistema.

Luego estan dos líneas mostrando la utilización actual para cada uno de los dos CPUs en el sistema. Las estadísticas de utilización se desglosan para mostrar si los ciclos de CPU gastados se hicieron para procesamiento a nivel de usuario o a nivel del sistema; también está incluido una estadística que muestra cuanto tiempo de CPU se gastó por procesos con prioridades de planificación alteradas. Finalmente, hay una estadística de tiempo ocioso.

Desplazandose más abajo en la sección relacionada a procesos, encontramos que el proceso ejecutando la mayor parte del poder de CPU es top mismo; en otras palabras, el proceso ejecutable en este sistema ocioso fue top tomando una "foto" de sí mismo.

Sugerencia

Es importante recordar que el acto mismo de ejecutar un monitor del sistema afecta las estadísticas de utilización de recursos que usted recibe. Todos los monitorizadores basados en software hasta cierto punto hacen esto.

Para obtener más conocimiento detallado sobre la utilización del CPU, debemos cambiar herramientas. Si examinanos la salida desde vmstat, obtenemos un entendimiento ligeramente diferente de nuestro sistema ejemplo:

procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 1 0 0 0 233276 146636 469808 0 0 7 7 14 27 10 3 87 0 0 0 0 233276 146636 469808 0 0 0 0 523 138 3 0 96 0 0 0 0 233276 146636 469808 0 0 0 0 557 385 2 1 97 0 0 0 0 233276 146636 469808 0 0 0 0 544 343 2 0 97 0 0 0 0 233276 146636 469808 0 0 0 0 517 89 2 0 98 0 0 0 0 233276 146636 469808 0 0 0 32 518 102 2 0 98 0 0 0 0 233276 146636 469808 0 0 0 0 516 91 2 1 98 0 0 0 0 233276 146636 469808 0 0 0 0 516 72 2 0 98 0 0 0 0 233276 146636 469808 0 0 0 0 516 88 2 0 97 0 0 0 0 233276 146636 469808 0 0 0 0 516 81 2 0 97

Aquí hemos utilizado el comando vmstat 1 10 para tomar muestras del sistema cada segundo diez veces. Primero, las estadísticas relacionadas al CPU (los campos us, sy, y id) parecen similares a lo que mostraba top, y quizás hasta aparece un poco menos detallado. Sin embargo, a diferencia de top, también podemos obtener un poco más de información en cómo el CPU es utilizado.

Si examinamos los campos system, notamos que el CPU está manejando alrededor de 500 interrupciones por segundo en promedio y que se intercambia entre procesos entre 80 y 400 veces en un segundo. Si piensa que esto parece mucha actividad, piense nuevamente, porque el procesamiento a nivel de usuario (el campo us) está promediando solamente 2%, mientras que el procesamiento a nivel del sistema (el campo sy) es usualmente por debajo de 1%. Una vez más, esto es un sistema ocioso.

Revisando las herramientas que Sysstat ofrece, encontramos que iostat y mpstat proporcionan poca información adicional sobre lo que ya hemos experimentado con top y vmstat. Sin embargo, sar produce un número de informes que son de ayuda cuando se supervisa la utilización del CPU.


El primer informe se obtiene por el comando sar -q, el cual muestra el largo de la cola de ejecución, número total de procesos y la carga promedio durante los últimos uno y cinco minutos. He aquí un ejemplo:

Linux 2.4.21-1.1931.2.349.2.2.entsmp (falcon.example.com) 07/21/2003

12:00:01 AM runq-sz plist-sz ldavg-1 ldavg-512:10:00 AM 3 122 0.07 0.2812:20:01 AM 5 123 0.00 0.03...09:50:00 AM 5 124 0.67 0.65Average: 4 123 0.26 0.26

En este ejemplo, el sistema siempre está ocupado (dado que siempre hay más de un proceso ejecutable), pero no está sobrecargado (puesto que este sistema particular tiene más de un procesador).

El próximo informe sar relacionado con el CPU lo produce el comando sar -u:


12:00:01 AM CPU %user %nice %system %idle12:10:00 AM all 3.69 20.10 1.06 75.1512:20:01 AM all 1.73 0.22 0.80 97.25...10:00:00 AM all 35.17 0.83 1.06 62.93Average: all 7.47 4.85 3.87 83.81

Las estadísticas contenidas en este informe no son diferentes de aquellas generadas por muchas otras herramientas. El principal beneficio aquí es que sar hace los datos disponibles de forma contínua y es por tanto más útil para obtener datos sobre promedios de largos tiempos, o para la producción de gráficos de utilización de CPU.

En sistemas multiproceso, el comando sar -U puede producir estadísticas para un procesador individual o para todos los procesos. He aquí un ejemplo de la salida desde sar -U ALL:


12:00:01 AM CPU %user %nice %system %idle12:10:00 AM 0 3.46 21.47 1.09 73.9812:10:00 AM 1 3.91 18.73 1.03 76.3312:20:01 AM 0 1.63 0.25 0.78 97.3412:20:01 AM 1 1.82 0.20 0.81 97.17...10:00:00 AM 0 39.12 0.75 1.04 59.0910:00:00 AM 1 31.22 0.92 1.09 66.77Average: 0 7.61 4.91 3.86 83.61Average: 1 7.33 4.78 3.88 84.02

El comando sar -w informa sobre el número de switches de contexto por segundo, haciendo posible ganar conocimiento adicional sobre dónde se gastan los ciclos de CPU:


12:00:01 AM cswch/s12:10:00 AM 537.9712:20:01 AM 339.43...10:10:00 AM 319.42


Average: 1158.25

También es posible generar dos informes sar diferentes en actividad interrumpida. El primero, (generado usando el comando sar -I SUM) muestra una estadística simple de "interrupciones por segundo":


12:00:01 AM INTR intr/s12:10:00 AM sum 539.1512:20:01 AM sum 539.49...10:40:01 AM sum 539.10Average: sum 541.00

Usando el comando sar -I PROC, es posible desglosar la actividad de interrupciones por procesador (en sistemas multiproceso) y por nivel de interrupciones (desde 0 a 15):

Linux 2.4.21-1.1931.2.349.2.2.entsmp (pigdog.example.com) 07/21/2003

12:00:00 AM 12:10:01 AM

12:10:01 AM 12:20:01 AM ... 10:30:01 AM 10:40:02 AM Average:

CPU i000/s i001/s i002/s i008/s i009/s i011/s i012/s 0 512.01 0.00 0.00 0.00 3.44 0.00 0.00

CPU i000/s i001/s i002/s i008/s i009/s i011/s i012/s 0 512.00 0.00 0.00 0.00 3.73 0.00 0.00

CPU i000/s i001/s i002/s i003/s i008/s i009/s i010/s 0 512.00 1.67 0.00 0.00 0.00 15.08 0.00 0 512.00 0.42 0.00 N/A 0.00 6.03 N/A

Este informe (el cual se ha truncado horizontalmente para ajustarse a la página) incluye una columna por cada nivel de interrupción (por ejemplo, el campo i002/s ilustrando las tasas para nivel de interrupción 2). Si este fuese un sistema multiprocesador, habría una línea por período de muestra para cada CPU.

Otro pundo importante a tomar en cuenta es que sar añade o elimina campos de interrupción específicos si no se reunen datos para ese campo. El informe de ejemplo de arriba suministra un ejemplo de esto, el final del informe incluye los niveles de interrupción (3 y 10) que no estaban presentes al principio del período de muestras.

Nota

Existen otros dos informes sar relacionados a interrupciones — sar -I ALL y sar -I XALL. Sin embargo, la configuración predeterminada para la utilidad de recolección de datos sadc no reune la información necesaria para estos informes. Esto se puede cambiar modificando el archivo /etc/cron.d/sysstat, y cambiando esta línea:

*/10 * * * * root /usr/lib/sa/sa1 1 1

a esto:

*/10 * * * * root /usr/lib/sa/sa1 -I 1 1


Tenga en mente que este cambio ocasiona que se reuna información adicional por sadc y resulta en tamaños de archivos más grandes. Por lo tanto, asegúrese de que la configuración de su sistema pueda soportar el consumo de espacio adicional.


Esta sección incluye varios recursos que se pueden utilizar para aprender más sobre la materia específica a Red Hat Enterprise Linux discutida en este capítulo.


Los recursos siguientes se instalan durante una instalación típica de Red Hat Enterprise Linux y lo pueden ayudar a aprender un poco más sobre la materia discutida en este capítulo.

• La página man de vmstat(8) — Aprenda a mostrar una vista concisa de la utilización de procesos, memoria, swap, E/S, sistema y CPU.

• La página man de iostat(1) — Le enseña cómo mostrar estadísticas de CPU y E/S.

• La página man de sar(1) — Aprenda a producir informes de utilización de recursos del sistema.

• La página man de sadc(8) — Aprenda a reunir datos de utilización del sistema.

• La página man de sa1(8) — Conozca este script que ejecuta periódicamente sadc.

• La página man de top(1) — Conozca cómo mostrar estadísticas de utilización del CPU y de nivel de procesos.

3.4.2. Sitios Web útiles

• http://people.redhat.com/alikins/system_tuning.html — System Tuning Info for Linux Servers. Un enfoque de corriente consciente sobre la optimización del rendimiento y supervisión de recursos para servidores.

• http://www.linuxjournal.com/article.php?sid=2396 — Performance Monitoring Tools for Linux. Esta página del Linux Journal está enfocada hacia el administrador interesado en escribir una solución gráfica personalizada de rendimiento. Escrita hace varios años atrás, algunos de los detalles quizás ya no se apliquen, pero el concepto general y la ejecución están bien fundadas.


Los libros siguientes discuten varios aspectos relacionados a la supervisión de recursos y son una buena fuente para los administradores de sistemas Red Hat Enterprise Linux.

• El Manual de administración del sistema de Red Hat Enterprise Linux de Red Hat, Inc. — Incluye un capítulo sobre muchas de las herramientas de supervisión de recursos discutidas aquí.

• Linux Performance Tuning and Capacity Planning por Jason R. Fink and Matthew D. Sherer; Sams — Proporciona descripciones más profundas de las herramientas de supervisión presentadas aquí incluyendo otras que pueden ser apropiadas para necesidades de supervisión de recursos más específicas.


• Linux Administration Handbook por Evi Nemeth, Garth Snyder y Trent R. Hein; Prentice Hall — Proporciona un capítulo corto similar en ámbito al de este libro, pero incluye una sección interesante sobre el diagnóstico de un sistema que se vuelve lento repentinamente.

• Linux System Administration: A User’s Guide por Marcel Gagne; Addison Wesley Professional — Contiene un pequeño capítulo sobre la supervisión del rendimiento y optimización.


Capítulo 4. Memoria física y virtual

Todas las computadoras de propósito general de hoy día, son del tipo conocido como computadoras de almacenamiento de programas. Como su nombre lo implica, las computadoras de programas almacenados cargan las instrucciones (los bloques de construcción de programas) en algún tipo de almacenamiento interno, donde son subsecuentemente ejecutadas.

Las computadoras de programas almacenados también utilizan el mismo almacenamiento para los datos. Esto es en contraste con las computadoras que utilizan su configuración de hardware para controlar sus operaciones (tales como las computadoras más antiguas basadas en la conexión de tarjetas).

El lugar donde los programas eran almacenados en las primeras computadoras de programas almacenados se llamó de varias formas y utilizó tecnologías diferentes, desde manchas en un tubo de rayos catódicos, hasta pulsos de presión en columnas de mercurio. Afortunadamente, los computadores de hoy en día utilizan tecnologías con mayores capacidades de almacenamiento y de menor tamaño que antes.

4.1. Patrones de acceso a almacenamiento

Una cosa a recordar a lo largo de este capítulo es que los computadores tienden a acceder al almacenamiento en formas particulares. De hecho, la mayoría del acceso a almacenamiento tiende a exhibir uno (o ambos) de los siguientes atributos:

• El acceso tiende a ser secuencial

• El acceso tiende a ser localizado

El acceso secuencial significa que, si el CPU accede a la dirección N , es muy probable que la dirección N +1 sea la próxima a acceder. Esto tiene sentido, ya que muchos programas consisten de grandes secciones de instrucciones que ejecutan — en orden — una instrucción tras la otra.

El acceso localizado significa que, si se accede a la dirección X, es muy probable que otras direcciones alrededor de X también serán accedidas en el futuro.

Estos atributos son cruciales, debido a que permite que unidades de almacenamiento pequeña y más rápida, coloque efectivamente en memoria temporal almacenamiento más grande y lento. Esto es lo básico para implementar la memoria virtual. Pero antes de que discutamos la memoria virtual, debemos examinar las diferentes tecnologías de almacenamiento usadas actualmente.

4.2. El espectro de almacenamiento

Las computadoras de hoy utilizan una variedad de tecnologías de almacenamiento. Cada tecnología está orientada hacia una función específica, con velocidades y capacidades en combinación.

Estas tecnologías son:

• Registros de CPU

• Memoria caché

• RAM

• Discos duros

• Almacenamiento fuera de línea para respaldos (cintas, discos ópticos, etc.)

50 Capítulo 4. Memoria física y virtual

En términos de capacidades y costos, estas tecnologías forman un espectro. Por ejemplo, los registros de CPU son:

• Muy rápidos (tiempos de acceso de unos pocos nanosegundos)

• Baja capacidad (usualmente menos de 200 bytes)

• Capacidades de expansión muy limitadas (se requiere un cambio en la arquitectura del CPU)

• Costosas (más de un dólar/byte)

Sin embargo, en el otro lado del espectro, el almacenamiento fuera de línea es:

• Muy lento (tiempos de acceso se miden en días, si la media de respaldo debe ser entregada sobre largas distancias)

• Capacidad muy alta (10s - 100s de gigabytes)

• Capacidades de expansión prácticamente ilimitadas (solamente limitadas por el espacio físico requerido para hospedar la media de respaldo)

• Bajo costo (fracciones de céntimos/byte)

Usando diferentes tecnologías con diferentes capacidades, es posible afinar el diseño del sistema para un máximo rendimiento al costo más bajo posible. Las secciones siguientes exploran cada tecnología en el espectro del almacenamiento.

4.2.1. Registros de CPU

Todos los diseños de CPU de hoy día incluyen registros para una variedad de propósitos, desde el almacenamiento de direcciones de la instrucción recientemente ejecutada, hasta propósitos más generales de almacenamiento y manipulación de datos. Los registros de CPU se ejecutan a la misma velocidad que el resto del CPU; de lo contrario habría un cuello de botella grave sobre el rendimiento completo del sistema. La razón para esto es que casi todas las operaciones realizadas por el CPU envuelven registros de una forma u otra.

El número de registros de CPU (y sus usos) dependen estrictamente en el diseño arquitectónico del CPU mismo. No hay forma de cambiar el número de registros de CPU, solamente puede migrar a un CPU con una arquitectura diferente. Por estas razones, el número de registros de CPU se puede considerar como una constante, ya que sólo pueden cambiarse con mucho dolor y grandes costos.

4.2.2. Memoria caché

El propósito de la memoria caché es actuar como una memoria temporal entre los registros de CPU, limitados y de gran velocidad y el sistema de memoria principal, mucho más grande y lento — usualmente conocido como RAM1 . La memoria caché tiene una velocidad de operación similar a la del CPU mismo, por eso cuando el CPU accede a datos en la caché, no tiene que quedarse esperando por los datos.

La memoria caché es configurada de forma tal que, cuando se leen datos desde la RAM, el sistema de hardware verifica primero para determinar si los datos deseados están en caché. Si los datos están en caché, estos son recuperados rápidamente y utilizados por el CPU. Sin embargo, si los datos no están en caché, estos se leen desde la RAM y, mientras se transfieren al CPU, también se colocan en caché (en caso de que se necesiten más tarde). Desde la perspectiva del CPU, todo esto se hace de forma

1. Mientras que "RAM" es un acrónimo para "Random Access Memory," y un término que podría ser fácil

mente aplicable a cualquier tecnología de almacenamiento que permita el acceso no secuencial de los datos

almacenados, cuando los administradores de sistemas hablan sobre RAM invariablemente se refieren al sistema

de memoria principal.

Capítulo 4. Memoria física y virtual 51

transparente, por lo que la única diferencia entre el acceso de los datos en caché y desde la RAM es la cantidad de tiempo que toma para que los datos sean recuperados.

En términos de la capacidad de almacenamiento, la caché es mucho más pequeña que la RAM. Por lo tanto, no todos los bytes en la RAM tienen su ubicación única en caché. Como tal, es necesario dividir la caché en secciones que se puedan utilizar para alojar diferentes áreas de RAM y tener un mecanismo que permita que cada área de la caché haga un "caché" de la RAM en diferentes momentos. Aúnque existe una diferencia en tamaño entre la caché y la RAM, dada la naturaleza secuencial y localizada del acceso a almacenamiento, una pequeña cantidad de caché puede efectivamente acelerar el acceso a grandes cantidades de RAM.

Cuando se escriben datos desde el CPU, las cosas se complican un poco. Existen dos enfoque que se pueden utilizar. En ambos casos, los datos son escritos primero a la caché. Sin embargo, puesto que el propósito de la caché es funcionar como una copia muy rápida de los contenidos de porciones seleccionadas de RAM, cada vez que una porción de datos cambia su valor, ese nuevo valor debe ser escrito tanto a la caché como a la RAM. De lo contrario, los datos en caché y los datos en la RAM ya no coincidirían.

Los dos enfoques se diferencian en cómo se logra hacer esto. En un enfoque, conocido como writethrough caching, los datos modificados se escriben inmediatamente a la RAM. Sin embargo, en el write-back caching, se retrasa la escritura de los datos modificados a la RAM. La razón para hacer esto es la de reducir el número de veces que una porción de datos modificada frecuentemente debe ser escrita nuevamente a la RAM.

La caché "write-through" o inmediata es un poco más simple de implementar; por esta razón es la más común. La caché "write-back" es un poco más complicada; además de almacenar los datos, es necesario mantener cierto tipo de mecanismo que sea capaz de notificar que los datos en caché están al día o "limpios" (los datos en caché son los mismos que los datos en RAM), o que están "sucios" (los datos en caché han sido modificados, lo que significa que los datos en RAM ya no están actualizados). También es necesario implementar una forma de vaciar periódicamente entradas "sucias" en caché de vuelta en RAM.

4.2.2.1. Niveles de caché

Los subsistemas de caché en los diseños de computadoras de hoy día pueden ser de niveles múltiples; esto es, puede haber más de un conjunto de caché entre el CPU y la memoria principal. Los niveles de caché a menudo están enumerados, con los números menores más cercanos a la CPU. Muchos sistemas tienen dos niveles de caché:

• La caché L1 a menudo está ubicada en el chip del CPU mismo y se ejecuta a la misma velocidad que el CPU.

• La caché L2 usualmente es parte del módulo de CPU, se ejecuta a las mismas velocidades que el CPU (o casi) y normalmente es un poco más grande y lenta que la caché L1

Algunos sistemas (normalmente servidores de alto rendimiento) también tienen caché L3, que usualmente forma parte del sistema de la tarjeta madre. Como puede imaginarse, la caché L3 es más grande (y casi con seguridad más lenta) que la caché L2.

En cualquier caso, el objetivo del todos los subsistemas de caché — bien sean simples o de múltiples niveles — es el de reducir el tiempo de acceso promedio a la RAM.

4.2.3. Memoria principal — RAM

La RAM resuelve la mayoría del almacenamiento electrónico en las computadoras de hoy en día. La RAM es utilizada tanto para almacenar datos como para almacenar los programas en uso. La velocidad de la RAM en la mayoría de los sistemas actuales está entre la velocidad de la memoria caché y la de los discos duros y está mucho más cercana a la velocidad de la primera que a la segunda.


La operación básica de la RAM es en realidad bien sencilla. En el nivel más bajo, están los chips de RAM — circuitos integrados que "recuerdan". Estos chips tienen cuatro tipos de conexiones con el mundo externo:

• Conexiones de energía (para operar la circuitería dentro del chip)

• Conexiones de datos (para permitir la transferencia de datos hacia adentro y fuera del chip)

• Conexiones de lectura/escritura (para controlar si los datos se almacenaran o se recuperaran desde el chip)

• Conexiones de direcciones (para determinar si los datos en el chip serán leídos/escritos)

He aquí los pasos requeridos para almacenar datos en RAM:

1. Los datos a almacenar se presentan a las conexiones de datos.

2. La dirección en la que los datos se almacenaran se presenta a las conexiones de dirección.

3. La conexión de lectura/escritura se coloca en modo de escritura.

La recuperación de datos es también muy directa:

1. La dirección de los datos deseados se presenta a las conexiones de direcciones.

2. La conexión de lectura/escritura es colocada a modo de lectura.

3. Los datos deseados son leídos desde las conexiones de datos.

Mientras que estos pasos parecen bastante simples, estos toman lugar a grandes velocidades, con el tiempo consumido en cada paso medido en nanosegundos.

Casi todos los chips de memoria creados hoy en día se venden como módulos. Cada módulo consiste de un número individual de chips de RAM conectados a una pequeña tarjeta de circuitos. La distribución mecánica y eléctrica del módulo sigue los estándares de la industria, haciendo posible la compra de memorias desde diferentes fabricantes.

Nota

El beneficio principal de un sistema utilizando módulos RAM basados en estándares de la industria, es que tienden a mantener bajos los costos de las RAM, debido a la posibilidad de adquirir módulos a partir de diferentes fabricantes.

Aunque la mayoría de las computadoras utilizan módulos de RAM basados en estándares de la industria, existen algunas excepciones. Las más notables de estas excepciones son portátiles (e inclusive aquí se comienza a ver un poco más de estandarización) y servidores de punta. Sin embargo, aún en estos ejemplos, es muy probable que estén disponibles módulos de terceros, asumiendo que el sistema sea relativamente popular y que no se trate de un diseño completamente nuevo.

4.2.4. Discos duros

Todas las tecnologías discutidas hasta ahora son volátiles por naturaleza. En otras palabras, los datos contenidos en almacenamiento volátil se pierden cuando se desconecta el poder.

Por otro lado, los discos duros son no-volátiles — lo que significa que los datos se mantienen allí, aún después que se ha desconectado la energía. Debido a esto, los discos duros ocupan un lugar muy especial en el espectro del almacenamiento. Su naturaleza no-volátil los hace ideal para el almacenamiento de programas y datos para su uso a largo plazo. Otro aspecto único de los discos duros es


que, a diferencia de la RAM y la memoria caché, no es posible ejecutar los programas directamente cuando son almacenados en discos duros; en vez de esto, ellos deben primero ser leídos a la RAM.

Otra diferencia de la caché y de la RAM es la velocidad del almacenamiento y recuperación de los datos; los discos duros son de al menos un orden de magnitud más lento que todas las tecnologías electrónicas utilizadas para caché y RAM. La diferencia en velocidad es debida principalmente a su naturaleza electromecánica. Hay cuatro fases distintas que toman lugar durante cada transferencia de datos desde o hacia un disco duro. La lista siguiente ilustra estas fases, junto con el tiempo que en promedio tomaría una unidad de alto rendimiento, para completar cada fase:

• Movimiento del brazo de acceso (5.5 milisegundos)

• Rotación del disco (.1 milisegundos)

• Lectura/escritura de datos de cabezales (.00014 milisegundos)

• Transferencia de datos hacia/desde la electrónica del disco (.003 Milisegundos)

De todas estas, solamente la última fase no es dependiente de ninguna operación mecánica.

Nota

Aunque hay mucho más por aprender sobre los discos duros, las tecnologías de almacenamiento de disco son discutidas con más detalles en el Capítulo 5. Por los momentos, solamente es necesario tener presente la gran diferencia de velocidad entre la RAM y las tecnologías basadas en disco y que su capacidad de almacenamiento usualmente excede la de la RAM por un factor de al menos 10 y a menudo de 100 y hasta más.

4.2.5. Almacenamiento para respaldos fuera de línea

El almacenamiento de respaldo fuera de línea dá un paso más allá del almacenamiento de disco duro en términos de la capacidad (mayor) y de la velocidad (más lento). Aquí, las capacidades solamente están limitadas por su habilidad de conseguir y almacenar la media removible.

Las tecnologías utilizadas en estos dispositivos varían ampliamente. He aquí los tipos más populares:

• Cinta magnética

• Disco óptico

Por supuesto, el tener una media removible significa que los tiempos de acceso son aún más largos, particularmente cuando los datos deseados están en un medio que aún no está cargado en el dispositivo de almacenamiento. Esta situación es aliviada de alguna manera por el uso de dispositivos robóticos capaces de montar y desmontar automáticamente la media, pero las capacidades de almacenamiento de la media de tales dispositivos son finitas. Hasta en el mejor de los casos, los tiempos de acceso son medidos en segundos, lo cual está bastante lejos de los tiempos típicos de acceso de los ya relativamente lentos multi-milisegundos de un disco duro.

Ahora que ha visto brevemente las diferentes tecnologías de almacenamiento utilizadas hoy en día, vamos a explorar los conceptos básicos de la memoria virtual.


4.3. Conceptos básicos sobre Memoria Virtual Aún cuando la tecnología detrás de la construcción de las implementaciones modernas de almacenamiento es realmente impresionante, el administrador de sistemas promedio no necesita estar al tanto de los detalles. De hecho, solamente existe un factor que los administradores de sistemas deberían tener en consideración:

Nunca hay suficiente RAM.

Mientras que esta frase puede sonar al principio un poco cómica, muchos diseñadores de sistemas operativos han empleado una gran cantidad de tiempo tratando de reducir el impacto de esta limitación. Esto lo han logrado mediante la implementación de la memoria virtual — una forma de combinar RAM con un almacenamiento más lento para darle al sistema la apariencia de tener más RAM de la que tiene instalada realmente.

4.3.1. La memoria virtual en términos sencillos

Vamos a comenzar con una aplicación hipotética. El código de máquina que conforma esta aplicación tiene un tamaño de 10000 bytes. También requiere otros 5000 bytes para el almacenamiento de datos y para la memoria intermedia de E/S. Esto significa que para ejecutar la aplicación, deben haber más de 15000 bytes de RAM disponible; un byte menos y la aplicación no será capaz de ejecutarse.

Este requerimiento de 15000 bytes se conoce como el espacio de direcciones de la aplicación. Es el número de direcciones únicas necesarias para almacenar la aplicación y sus datos. En las primeras computadoras, la cantidad de RAM disponible tenía que ser mayor que el espacio de direcciones de la aplicación más grande a ejecutar; de lo contrario, la aplicación fallaría con un error de "memoria insuficiente".

Un enfoque posterior conocido como solapamiento intentó aliviar el problema permitiendo a los programadores dictar cuales partes de sus aplicaciones necesitaban estar residentes en memoria en cualquier momento dado. De esta forma, el código requerido solamente para propósitos de inicialización podía ser sobreescrito con código a utilizar posteriormente. Mientras que el solapamiento facilitó las limitaciones de memoria, era un proceso muy complejo y susceptible a errores. El solapamiento también fallaba en solucionar el problema de las limitaciones de memoria globales al sistema en tiempo de ejecución. En otras palabras, un programa con solapamiento requería menos memoria para ejecutarse que un programa sin solapamiento, pero si el sistema no tiene suficiente memoria para el programa solapado, el resultado final es el mismo — un error de falla de memoria.

Con la memoria virtual el concepto del espacio de direcciones de las aplicaciones toma un significado diferente. En vez de concentrarse en cuanta memoria necesita una aplicación para ejecutarse, un sistema operativo con memoria virtual continuamente trata de encontrar una respuesta a la pregunta "qué tan poca memoria necesita la aplicación para ejecutarse?".

Aunque inicialmente pareciera que nuestra aplicación hipotética requiere de un total de 15000 bytes para ejecutarse, recuerde nuestra discusión anterior en la Sección 4.1 — el acceso a memoria tiende a ser secuencial y localizado. Debido a esto, la cantidad de memoria requerida para ejecutar la aplicación en un momento dado es menos que 15000 bytes — usualmente mucho menos. Considere los tipos de accesos de memoria requeridos para ejecutar una instrucción de máquina sencilla:

• La instrucción es leída desde la memoria.

• Se leen desde memoria los datos requeridos por la instrucción.

• Después de completar la instrucción, los resultados de la instrucción son escritos nuevamente en memoria.

El número real de bytes necesarios para cada acceso de memoria varían de acuerdo a la arquitectura del CPU, la instrucción misma y el tipo de dato. Sin embargo, aún si una instrucción requiere de 100 bytes de memoria por cada tipo de acceso de memoria, los 300 bytes requeridos son mucho menos que el espacio de direcciones total de la aplicación de 15000 bytes. Si hubiese una forma de hacer un seguimiento de los requerimientos de memoria de la aplicación a medida que esta se ejecuta, sería


posible mantener la aplicación ejecutándose usando menos memoria que lo que indicaría su espacio de direcciones.

Pero esto genera una pregunta:

Si solamente una parte de la aplicación está en memoria en un momento dado, dónde esta el resto?

4.3.2. Almacenamiento de respaldo — el Tenet central de la memoria virtual La respuesta corta a esta pregunta es que el resto de la aplicación se mantiene en disco. En otras palabras, el disco actúa como un almacenamiento de respaldo para la RAM; un medio más lento y también más grande que actúa como un "respaldo" para un almacenamiento más rápido y más pequeño. Esto puede parecer al principio como un gran problema de rendimiento en su creación — después de todo, las unidades de disco son mucho más lentas que la RAM.

Aunque esto es cierto, es posible tomar ventaja del comportamiento de acceso secuencial y localizado de las aplicaciones y eliminar la mayoría de las implicaciones de rendimiento en el uso de unidades de disco como unidades de respaldo para la RAM. Esto se logra estructurando el subsistema de memoria virtual para que este trate de asegurarse de que esas partes de la aplicación que actualmente se necesitan — o que probablemente se necesitaran en un futuro cercano — se mantengan en RAM solamente por el tiempo en que son realmente requeridas.

En muchos aspectos, esto es similar a la situación entre la caché y la RAM: haciendo parecer una poca cantidad de almacenamiento rápido con grandes cantidades de un almacenamiento lento actuar como que si se tratase de grandes cantidades de almacenamiento rápido.

Con esto en mente, exploremos el proceso en más detalle.

4.4. La memoria virtual: los detalles

Primero, debemos introducir un nuevo concepto: espacio de direcciones virtuales. El espacio de direcciones virtuales es el espacio de direcciones máximo disponible para una aplicación. El espacio de direcciones virtuales varia de acuerdo a la arquitectura del sistema y del sistema operativo. El espacio de direcciones virtuales depende de la arquitectura puesto que es la arquitectura la que define cuántos bits están disponibles para propósitos de direccionamiento. El espacio de direcciones virtuales también depende del sistema operativo puesto que la forma en que el sistema operativo fue implementado puede introducir límites adicionales sobre aquellos impuestos por la arquitectura.

La palabra "virtual" en el espacio de direcciones virtuales, significa que este es el número total de ubicaciones de memoria direccionables disponibles para una aplicación, pero no la cantidad de memoria física instalada en el sistema, o dedicada a la aplicación en un momento dado.

En el caso de nuestra aplicación de ejemplo, su espacio de direcciones virtuales es de 15000 bytes.

Para implementar la memoria virtual, para el sistema es necesario tener un hardware especial de administración de memoria. Este hardware a menudo se conoce como un MMU (Memory Management Unit). Sin un MMU, cuando el CPU accede a la RAM, las ubicaciones reales de RAM nunca cambian — la dirección de memoria 123 siempre será la misma dirección física dentro de la RAM.

Sin embargo, con un MMU, las direcciones de memoria pasan a través de un paso de traducción antes de cada acceso de memoria. Esto significa que la dirección de memoria 123 puede ser redirigida a la dirección física 82043 en un momento dado y a la dirección 20468 en otro. Como resultado de esto, la sobrecarga relacionada con el seguimiento de las traducciones de memoria virtual a física sería demasiado. En vez de esto, la MMU divide la RAM en páginas — secciones contiguas de memoria de un tamaño fijo que son manejadas por el MMU como unidades sencillas.

Mantener un seguimiento de estas páginas y sus direcciónes traducidas puede sonar como un paso adicional confuso e innecesario, pero de hecho es crucial para la implementación de la memoria virtual. Por tal razón, considere el punto siguiente:


Tomando nuestra aplicación hipotética con un espacio de direcciones virtuales de 15000 bytes, asuma que la primera instrucción de la aplicación accede a los datos almacenados en la dirección 12374. Sin embargo, también asuma que nuestra computadora solamente tiene 12288 bytes de RAM física. ¿Qué pasa cuando el CPU intenta acceder a la dirección 12374?

Lo que ocurre se conoce como un fallo de página.

4.4.1. Fallos de página

Un fallo de página es la secuencia de eventos que ocurren cuando un programa intenta acceder a datos (o código) que está en su espacio de direcciones, pero que no está actualmente ubicado en la RAM del sistema. El sistema operativo debe manejar los fallos de página haciendo residentes en memoria los datos accedidos, permitiendo de esta manera que el programa continue la operación como que si el fallo de página nunca ocurrió.

En el caso de nuestra aplicación hipotética, el CPU primeramente presenta la dirección deseada (12374) al MMU. Sin embargo, el MMU no tiene traducción para esta dirección. Por tanto, interrumpe al CPU y causa que se ejecute un software, conocido como el manejador de fallos de página. El manejador de fallos de página determina lo que se debe hacer para resolver esta falla de página. El mismo puede:

• Encontrar dónde reside la página deseada en disco y la lee (este es usualmente el caso si el fallo de página es por una página de código)

• Determina que la página deseada ya está en RAM (pero no está asignada al proceso actual) y reconfigura el MMU para que apunte a el

• Apunta a una página especial que solamente contiene ceros y asigna una nueva página para el proceso solamente si este intenta alguna vez escribir a la página especial (esto se llama una página de copia en escritura y es utilizada a menudo por páginas que contienen datos inicializados a cero)

• Obtener la página deseada desde otro lugar (lo que se discute en detalle más adelante)

Mientras que las primeras tres acciones son relativamente sencillas, la última no lo es. Por eso necesitamos cubrir algunos tópicos adicionales.

4.4.2. El conjunto de direcciones de trabajo

El grupo de páginas de memoria física actualmente dedicadas a un proceso específico se conoce como conjunto de direcciones de trabajo para ese proceso. El número de páginas en el conjunto de direcciones de trabajo puede crecer o reducirse, dependiendo de la disponibilidad general de páginas del sistema.

El conjunto de direcciones de trabajo crece si un proceso tiene fallos de páginas. El conjunto de direcciones de trabajo se reduce a medida que existen menos y menos páginas libres. Para evitar que se acabe la memoria completamente, se deben eliminar las páginas del conjunto de direcciones de trabajo y convertirlas en páginas libres, disponibles para un uso posterior. El sistema operativo reduce el conjunto de direcciones de trabajo mediante:

• Escribiendo las páginas modificadas a un área dedicada en un dispositivo de almacenamiento masivo (usualmente conocido como espacio de intercambio o de paginado)

• Marcando las páginas sin modificar como libres (no hay necesidad de escribir estas páginas fuera del disco pues no se han cambiado)

Para determinar los conjuntos de trabajo apropiados para todos los procesos, el sistema operativo debe hacer un seguimiento de la información de uso de todas las páginas. De esta manera, el sistema operativo determina cuales páginas son usadas activamente (y deben mantenerse en memoria como residentes) y cuales no (y por lo tanto, se pueden eliminar de memoria). En la mayoría de los casos,


se utiliza un tipo de algoritmo de "menos usado recientemente" para determinar cuales páginas son elegibles para eliminarse de los conjuntos de trabajo de los procesos.

4.4.3. Intercambio

Mientras que el hacer intercambio de memoria (swapping, escribiendo páginas modificadas al espacio swap del sistema) es una parte normal de la operación del sistema, es posible experimentar demasiado intercambio. La razón por la que estar atentos ante el excesivo intercambio es que la situación siguiente puede ocurrir fácilmente, y repetirse una y otra vez:

• Las páginas de un proceso son intercambiadas (swapped)

• El proceso se vuelve ejecutable e intenta acceder a una página en el espacio de intercambio

• La página es colocada en memoria (lo más probable forzando a otras páginas de procesos a que sean extraídas de allí)

• Un momento después, la página es colocada nuevamente fuera de memoria

Si esta secuencia de eventos se extiende demasiado, esto se conoce como thrashing y es un indicativo de insuficiente RAM para la carga de trabajo actual. "Trashing" es extremadamente perjudicial para el rendimiento del sistema, pues las cargas de CPU y E/S que se pueden generar en tal situación rápidamente sobrepasa la carga impuesta por el trabajo real del sistema. En casos extremos, puede que el sistema no realice ningún trabajo útil, consumiendo todos sus recursos moviendo páginas dentro y fuera de memoria.

4.5. Implicaciones de rendimiento de la memoria virtual Mientras que la memoria virtual hace posible que las computadoras manejen más fácilmente aplicaciones más grandes y complejas, como con cualquier otra herramienta, esto viene a un precio. El precio en este caso es el de rendimiento — la memoria virtual de un sistema operativo tiene mucho más que hacer que un sistema operativo sin memoria virtual. Esto significa que el rendimiento nunca es tan bueno con memoria virtual como lo es cuando la misma aplicación esta 100% residente en memoria.

Sin embargo, esta no es razón suficiente para abandonar la idea. Los beneficios de la memoria virtual son demasiados para hacer esto. Y, con un poco de esfuerzo, es posible lograr un buen rendimiento. Lo que se debe hacer es examinar aquellos recursos de sistemas impactados por el uso pesado del subsistema de memoria virtual.

4.5.1. Escenario de rendimiento del peor caso

Por un momento, utilice lo que ha leído en este capítulo y considere qué recursos del sistema son utilizados extensivamente por fallos de páginas y actividad de intercambio:

• RAM — Obviamente la RAM disponible es poca (de lo contrario no habría necesidad de fallos de páginas o de intercambio de páginas).

• Disco — Aunque el espacio en disco puede no ser impactado, el ancho de banda de E/S (debido a mucho paginado e intercambio) si lo será.

• CPU — El CPU está utilizando ciclos haciendo el procesamiento necesario para soportar la administración de memoria y estableciendo las operaciones necesarias de E/S para el paginado e intercambio.

La naturaleza interrelacionada de estas cargas hace fácil entender cómo las limitaciones de recursos pueden conducir a problemas graves de rendimiento.


Todo lo que se necesita es un sistema con poca RAM, alta actividad de fallos de páginas y un sistema ejecutando casi en sus límites en términos de CPU o E/S de disco. En este punto, el sistema está haciendo trashing, siendo el bajo rendimiento el resultado inevitable.

4.5.2. Escenario de rendimiento del mejor caso

En el mejor caso, la sobrecarga proveniente del soporte a la memoria virtual representa una carga mínima para un sistema bien configurado:

• RAM — Suficiente RAM para todos los conjuntos de direcciones de trabajo con suficiente exceso para manejar cualquier fallo de página2

• Disco — Debido a la actividad limitada de fallos de página, el ancho de banda de E/S de disco será impactado de forma mínima.

• CPU — La mayoría de los ciclos de CPU realmente están dedicados a ejecutar aplicaciones, en vez de ejecutar el código de manejo de memoria del sistema

El punto a tener en mente es que el impacto en el rendimiento de la memoria virtual es mínimo cuando se utiliza tan poco como sea posible. Esto significa que el factor determinante para un buen rendimiento del subsistema de memoria virtual es tener suficiente RAM.

Lo siguiente (pero con mucho menos importancia) es suficiente capacidad de E/S de disco y de CPU. Sin embargo, tenga en cuenta que estos recursos solamente ayudan a que el rendimiento del sistema se degrade de una forma más limpia de intensivos fallos de página y del intercambio; pero hacen poco para ayudar el rendimiento del subsistema de memoria virtual (aunque obviamente pueden jugar un papel importante en el rendimiento global del sistema).

4.6. Información específica de Red Hat Enterprise Linux

Debido a la complejidad inherente de un sistema operativo con memoria virtual en demanda, la supervisión de los recursos relacionados con la memoria bajo Red Hat Enterprise Linux, pueden ser un poco confusos. Por lo tanto, lo mejor es comenzar con las herramientas más directas y partir de allí.

Usando free es posible obtener una vista general concisa (quizás hasta un poco simplistica) de la utilización de la memoria principal y de intercambio. He aquí un ejemplo:


Podemos ver que este sistema tiene 1.2GB de RAM, de los que solamente 350MB estan realmente en uso. Como se puede esperar para un sistema con esta cantidad de RAM disponible, no se utiliza nada de los 500MB de memoria de intercambio.

Compare ese ejemplo con el que sigue:


2. Un sistema razonablemente activo siempre experimenta algún nivel de actividad de fallo de páginas, debido

a los fallos de página en los que se incurre cuando las aplicaciones lanzadas recientemente son traídas a memoria.


Este sistema tiena alrededor de 256MB de RAM, la mayoría de la cual está en uso, dejando solamente 8MB libres. Más de 100MB de los 512MB de swap estan en uso. Aún cuando el sistema está ciertamente más limitado en términos de memoria que el primer sistema, para determinar si esta limitación de memoria está causando problemas de rendimiento, tenemos que investigar un poco más.

vmstat, aún cuando es más críptico que free, tiene el beneficio de que muestra más que simplemente las estadísticas de utilización de memoria. He aquí la salida de vmstat 1 10:

procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 2 0 0 111304 9728 7036 107204 0 0 6 10 120 24 10 2 89 2 0 0 111304 9728 7036 107204 0 0 0 0 526 1653 96 4 0 1 0 0 111304 9616 7036 107204 0 0 0 0 552 2219 94 5 1 1 0 0 111304 9616 7036 107204 0 0 0 0 624 699 98 2 0 2 0 0 111304 9616 7052 107204 0 0 0 48 603 1466 95 5 0 3 0 0 111304 9620 7052 107204 0 0 0 0 768 932 90 4 6 3 0 0 111304 9440 7076 107360 92 0 244 0 820 1230 85 9 6 2 0 0 111304 9276 7076 107368 0 0 0 0 832 1060 87 6 7 3 0 0 111304 9624 7092 107372 0 0 16 0 813 1655 93 5 2 2 0 2 111304 9624 7108 107372 0 0 0 972 1189 1165 68 9 23

Durante esta muestra de 10 segundos, la cantidad de memoria libre (el campo free) varía de alguna forma, y hay un poco de E/S relacionada con la memoria de intercambio (los campos si y so), pero en general, este sistema está funcionando bien. Sin embargo, se duda cuánta carga adicional de trabajo pueda manejar, dada la utilización actual de memoria.

Cuando se investiga sobre cuestiones relacionadas a la memoria, a menudo es necesario determinar cómo el subsistema de memoria virtual de Red Hat Enterprise Linux está utilizando el sistema de memoria. Usando sar, es posible examinar este aspecto de rendimiento del sistema con muchos más detalles.

Revisando el informe de sar -r, podemos examinar la utilización de memoria principal y de intercambio más de cerca:


12:00:01 AM kbmemfree kbmemused %memused kbmemshrd kbbuffers kbcached12:10:00 AM 240468 1048252 81.34 0 133724 48577212:20:00 AM 240508 1048212 81.34 0 134172 485600...08:40:00 PM 934132 354588 27.51 0 26080 185364Average: 324346 964374 74.83 0 96072 467559

Los campos kbmemfree y kbmemused muestran las estadísticas típicas de memoria libre y en uso, mostrando el porcentage de memoria utilizada en el campo %memused. Los campos kbbuffers and kbcached muestran cuántos kilobytes de memoria son asignados a la memoria intermedia (buffers) y a la caché de datos global del sistema.

El campo kbmemshrd siempre es cero para los sistemas usando el kernel 2.4 de Linux (tal como Red Hat Enterprise Linux).

Se han truncado las líneas de este informe para que encajen en la página. He aquí el resto de cada línea, con la marca de tiempo agregada a la izquierda para facilitar la lectura:

12:00:01 AM kbswpfree kbswpused %swpused12:10:00 AM 522104 0 0.0012:20:00 AM 522104 0 0.00...08:40:00 PM 522104 0 0.00Average: 522104 0 0.00


Para la utilización de la memoria de intercambio, los campos kbswpfree y kbswpused muestran la cantidad de espacio de intercambio libre y utilizado, en kilobytes, con el campo %swpused mostrando el espacio de intercambio utilizado como un porcentaje.

Utilice el informe sar -W para conocer un poco más sobre la actividad de memoria de intercambio. A continuación se muestra un ejemplo:


12:00:01 AM pswpin/s pswpout/s12:10:01 AM 0.15 2.5612:20:00 AM 0.00 0.00...03:30:01 PM 0.42 2.56Average: 0.11 0.37

Observe que, en promedio, hay tres veces menos páginas traídas desde la memoria de intercambio (pswpin/s) que las que se devuelven a esta (pswpout/s).

Para entender mejor cómo se utilizan las páginas, consulte el informe sar -B:


12:00:01 AM pgpgin/s pgpgout/s activepg inadtypg inaclnpg inatarpg12:10:00 AM 0.03 8.61 195393 20654 30352 4927912:20:00 AM 0.01 7.51 195385 20655 30336 49275...08:40:00 PM 0.00 7.79 71236 1371 6760 15873Average: 201.54 201.54 169367 18999 35146 44702

Aquí podemos determinar cuántos bloques por segundo son paginados desde el disco (pgpgin/s) y paginados de vuelta al disco (pgpgout/s). Estas estadísticas sirven como un barómetro para la actividad general de la memoria virtual.

Sin embargo, se puede aprender mucho más examinando los otros campos en este informe. El kernel de Red Hat Enterprise Linux marca todas las páginas como activas o inactivas. Como su nombre lo implica, las páginas activas son las que están siendo utilizadas de alguna manera (como páginas de procesos o de memoria intermedia, por ejemplo), mientras que las inactivas no. Este informe de ejemplo muestra que la lista de páginas activas (el campo activepg) promedia aproximadamente 660MB3 .

El resto de los campos en este informe se concentran en la lista inactiva — páginas que, por alguna razón o la otra, no se han utilizado recientemente. El campo inadtypg muestra cuántas páginas inactivas estan sucias (dirty o modificadas) y requieren ser escritas al disco. Por otro lado, el campo inaclnpg, muestra cuántas páginas inactivas están limpias (clean o sin modificar) y no necesitan ser escritas a disco.

El campo inatarpg representa el tamaño deseado de la lista inactiva. Este valor es calculado por el kernel de Linux y tiene un tamaño tal que la lista inactiva permanezca lo suficientemente grande para actuar como un fondo para propósitos de reemplazo de páginas.

Utilice el informe sar -R para datos adicionales sobre el status de páginas (específicamente, la frecuencia con la que las páginas cambian de estado). He aquí un ejemplo de este informe:

3. El tamaño de página bajo Red Hat Enterprise Linux en el sistema x86 utilizado en este ejemplo, es de 4096

bytes. Los sistemas basados en otras arquitecturas pueden tener diferentes tamaños de páginas.



12:00:01 AM frmpg/s shmpg/s bufpg/s campg/s12:10:00 AM -0.10 0.00 0.12 -0.0712:20:00 AM 0.02 0.00 0.19 -0.07...08:50:01 PM -3.19 0.00 0.46 0.81Average: 0.01 0.00 -0.00 -0.00

Las estadísticas sobre este informe particular sar, son únicas, en el sentido de que pueden ser positivas, negativas o cero. Cuando son positivas, el valor indica la tasa a la que se estan incrementando este tipo de páginas. Si es negativo, el valor indica la tasa a la que se estan reduciendo este tipo de páginas. Un valor de cero indica que las páginas de este tipo no se están incrementando ni disminuyendo.

En este ejemplo, la última parte muestra que se asignan un poco más de tres páginas por segundo desde la lista de páginas libres (el campo frmpg/s) y se añade casi una página por segundo a la página caché (el campo campg/s). La lista de páginas utilizadas como memoria de intercambio (el campo bugpg/s) gana aproximadamente una página cada dos segundos, mientras que la lista de páginas de memoria compartidas (el campo shmpg/s) ni gana ni pierde páginas.


Esta sección incluye varios recursos que se pueden utilizar para conocer un poco más sobre la supervisión de recursos y la materia específica a Red Hat Enterprise Linux discutida en este capítulo.


Los recursos siguientes son instalados en el curso de una instalación típica de Red Hat Enterprise Linux y pueden ser de ayuda para aprender más sobre los tópicos discutidos en este capítulo.

• La página man de free(1) — Conozca cómo mostrar las estadísticas de la memoria libre y utilizada.

• La página man de vmstat(8) — Aprenda a desplegar una descripción general concisa de la utilización de procesos, memoria, swap, E/S, sistema y CPU.

• La página man de sar(1) — Aprenda a producir un informe de utilización de recursos del sistema.

• La página man de sa2(8) — Conozca cómo generar archivos de informes diarios de utilización de recursos del sistema.


• http://people.redhat.com/alikins/system_tuning.html — Información de optimización de sistemas servidores Linux. Una corriente de ideas para la optimización del rendimiento y supervisión de recursos para servidores.

• http://www.linuxjournal.com/article.php?sid=2396 — Performance Monitoring Tools for Linux. Este página del Linux Journal está orientada más hacia el administrador interesado en escribir una solución gráfica personalizada de rendimiento. Algunos detalles quizás ya no sean válidos pues se escribió muchos años atrás, pero el concepto general y la ejecución son robustas.



Los libros siguientes discuten varios problemas relacionados a la supervisión de recursos y son excelentes fuentes para los administradores de sistemas Red Hat Enterprise Linux.

• El Manual de administración del sistema de Red Hat Enterprise Linux; Red Hat, Inc. — Incluye un capítulo sobre muchas de las herramientas de supervisión de recursos discutidas aquí.

• Linux Performance Tuning and Capacity Planning por Jason R. Fink y Matthew D. Sherer; Sams — Proporciona descripciones detalladas sobre las herramientas de supervisión de recursos presentadas aquí e incluye otras que serían apropiadas para necesidades de supervisión de recursos más específicas.

• Red Hat Linux Security and Optimization por Mohammed J. Kabir; Red Hat Press — Aproximadamente las primeras 150 páginas de este libro discuten problemas relacionados al rendimiento. Esto incluye capítulos dedicados a problemas de rendimiento específicos a la red, Web, correo electrónico y servidores de archivos.

• Linux Administration Handbook por Evi Nemeth, Garth Snyder, y Trent R. Hein; Prentice Hall — Este libro proporciona un capítulo corto similar al ámbito de este libro, pero incluye una sección interesante sobre el diagnóstico de un sistema que repentinamente se vuelve lento.

• Linux System Administration: A User’s Guide por Marcel Gagne; Addison Wesley Professional — Contiene un pequeño capítulo sobre la supervisión y optimización del rendimiento.

• Essential System Administration (3rd Edition) por Aeleen Frisch; O’Reilly & Associates — El capítulo sobre la administración de recursos contiene información general útil con algunos aspectos específicos para Linux.

• System Performance Tuning (2nd Edition) por Gian-Paolo D. Musumeci y Mike Loukides; O’Reilly & Associates — Aunque está orientado en gran medida hacia las implementaciones tradicionales de UNIX, hay muchas referencias específicas a Linux a lo largo del libro.

Capítulo 5. Administración del Almacenamiento

Si hay una cosa que toma la mayor parte del día de un administrador de sistemas, esto es la administración del almacenamiento. Pareciera que los discos nunca tienen espacio suficiente, que se sobrecargan con actividad de E/S o que fallan repentinamente. Por eso es vital tener un conocimiento práctico sólido del almacenamiento en disco para poder ser un administrador de sistemas exitoso.

5.1. Una vista general del hardware de almacenamiento

Antes de administrar el almacenamiento, primero es necesario entender el hardware en el que están almacenados los datos. A menos que posea un algún conocimiento sobre la operación de los dispositivos de almacenamiento masivo, quizás se encuentre en una situación donde tenga un problema relacionado al almacenamiento pero le falte el conocimiento de fondo para si quiera entender lo que ve. Al tener un entendimiento sobre la forma en que opera el hardware subyacente, podrá más fácilmente determinar si el subsistema de almacenamiento de su computador está funcionando correctamente.

La gran mayoría de los dispositivos de almacenamiento masivo utilizan alguna forma de media de rotación y soportan el acceso aleatorio de los datos en esa media. Esto significa que los componentes siguientes están presentes en alguna forma dentro de casi todos los dispositivos de almacenamiento masivo:

• Plato del disco

• Dispositivo de lectura/escritura de datos

• Brazos de acceso

Las secciones siguientes exploran con más detalles cada uno de estos componentes.

5.1.1. Platos de discos

La media rotativa utilizada por casi todos los dispositivos de almacenamiento masivo están en la forma de uno o más platos planos y de forma circular. El plato puede estar compuesto de cualquier número de materiales diferentes, tales como aluminio, vidrio y policarbonatos.

La superficie de cada plato se trata de forma que permita el almacenamiento de datos. La naturaleza exacta del tratamiento va a depender de la tecnología de almacenamiento de datos utilizada. La tecnología de almacenamiento de datos más común está basada en la propiedad de magnetismo; en estos casos los platos se cubren con un compuesto que presenta buenas características magnéticas.

Otra tecnología de almacenamiento de datos común está basada en principios ópticos; en estos casos, los platos se cubren con materiales cuyas propiedades ópticas pueden ser modificadas, y en consecuencia, permitiendo almacenar datos ópticamente1 .

Sin importar la tecnología de almacenamiento utilizada, los platos del disco se giran , causando que su superficie completa barra más allá de otro componente - el dispositivo de lectura/escritura.

1. Algunos dispositivos ópticos - principalmente unidades de CD-ROM - utilizan diferentes enfoques para el

almacenamiento de datos; estas diferencias se mencionan en este capítulo en su momento pertinente.

64 Capítulo 5. Administración del Almacenamiento

5.1.2. Dispositivo de lectura/escritura de datos

El dispositivo de lectura/escritura es el componente que toma los bits y bytes en los que opera un sistema computacional y los convierte en las variaciones magnéticas u ópticas necesarias para interactuar con los materiales que cubren la superficie de los platos de discos.

Algunas veces las condiciones bajo las cuales estos dispositivos deben operar son difíciles. Por ejemplo, en un almacenamiento masivo basado en magnetismo, los dispositivos de lectura/escritura (conocidos como cabezales), deben estar muy cerca de la superficie del plato. Sin embargo, si el cabezal y la superficie del plato del disco se tocan, la fricción resultante provocaría un daño severo tanto al cabezal como al plato. Por lo tanto, las superficies tanto del cabezal como del plato son pulidas cuidadosamente y el cabezal utiliza aire a presión desarrollado por los platos que giran para flotar sobre la superficie del plato, "flotando" a una altitud no menor que el grueso de un cabello humano. Por eso es que las unidades de discos magnéticos son muy sensibles a choques, cambios drásticos de temperaturas y a la contaminación del aire.

Los retos que enfrentan los cabezales ópticos son de alguna manera diferentes de aquellos para los cabezales magnéticos - aquí, el ensamblado de la cabeza debe permanecer a una distancia relativamente constante de la superficie del plato. De lo contrario, los lentes utilizados para enfocarse sobre el plato no producen una imagen lo suficientemente definida.

En cualquier caso, las cabezas utilizan una cantidad muy pequeña del área de superficie del plato para el almacenamiento de datos. A medida que el plato gira por debajo de las cabezas, esta área de superficie toma la forma de una línea circular muy delgada.

Si es así como los dispositivos de almacenamiento masivo funcionan, significa que más del 99% de la superficie del plato se desperdiciaría. Se pueden montar cabezas adicionales sobre el plato, pero para utilizar completamente el área de superficie del plato se necesitan más de mil cabezales. Lo que se requiere es algún método de mover los cabezales sobre la superficie del plato.

5.1.3. Brazos de acceso

Utilizando una cabeza conectada a un brazo que sea capaz de barrer sobre la superficie completa del plato, es posible utilizar completamente el plato para el almacenamiento de datos. Sin embargo, el brazo de acceso debe ser capaz de dos cosas:

• Moverse rápidamente

• Moverse con gran precisión

El brazo de acceso se debe mover lo más rápido posible, pues el tiempo que se pierde moviendo el cabezal desde una posición a la otra es tiempo perdido. Esto se debe a que no se pueden leer o escribir datos hasta que el brazo se detenga2 .

El brazo de acceso debe ser capaz de moverse con gran precisión porque, como se mencionó anteriormente, el área de superficie utilizada por los cabezales es muy pequeña. Por lo tanto, para usar eficientemente la capacidad de almacenamiento del plato, es necesario mover las cabezas solamente lo suficiente para asegurar que cualquier datos escrito en la nueva posición no sobreescribe los datos escritos en la posición previa. Esto tiene el efecto de dividir conceptualmente la superficie del plato en miles o más aros concéntricos o pistas. El movimiento del brazo de acceso desde una pista a la siguiente a menudo se conoce como búsqueda y el tiempo que toma el brazo de acceso para moverse de una pista a otra se le conoce como tiempo de búsqueda.

2. En algunos dispositivos ópticos (tales como unidades de CD-ROM), el brazo de acceso se mueve contínu

amente, causando que el ensamble del cabezal describa una ruta en espiral sobre la superficie del plato. Esta es

una diferencia fundamental en como se utiliza el medio de almacenamiento y refleja los orígenes del CD-ROM

como un medio para almacenar música, donde la recuperación contínua de datos es una operación más común

que la búsqueda de un punto de datos específico.

Capítulo 5. Administración del Almacenamiento 65

Cuando existen múltiples platos (o un plato que con ambas superficies utilizadas para almacenamiento de datos), se apilan los brazos para cada superficie, permitiendo que se pueda acceder a la misma pista en cada superficie simultáneamente. Si se pueden visualizar las pistas para cada superficie con el acceso estacionario sobre una pista dada, apareceran como que están apiladas una sobre la otra, haciendo una forma cilíndrica; por tanto, el conjunto de pistas accesibles en una posición dada de los brazos de acceso se conocen como cilindro.

5.2. Conceptos de direcciones de almacenamiento

La configuración de los platos de discos, cabezales y brazos de acceso hacen posible posicionar el cabezal sobre cualquier parte de cualquier superficie de cualquier plato en el dispositivo de almacenamiento. Sin embargo, esto no es suficiente; para utilizar esta capacidad de almacenamiento, debemos tener algún método de dar direcciones a partes uniformes del almacenamiento disponible.

Hay un aspecto final requerido de este proceso. Considere todas las pistas en los muchos cilindros presentes en un dispositivo típico de almacenamiento masivo. Puesto que las pistas tienen diámetros variados, sus circunferencias también varían. Por lo tanto, si el almacenamiento fue resuelto solamente a nivel de pistas, cada pista tendrá diferentes cantidades de datos - pista #0 (estando cerca del centro del plato) puede almacenar 10,827 bytes, mientras que la pista #1,258 (cerca del borde externo del plato) puede almacenar 15,382 bytes.

La solución es dividir cada pista en múltiples sectores o bloques segmentos de un tamaño consistente (a menudo 512 bytes) de almacenamiento. El resultado es que cada pista contiene un número fijo3 de sectores.

Un efecto secundario es que cada sector contiene espacio inutilizado - el espacio entre sectores. A pesar del número constante de sectores en cada pista, la cantidad de espacio inutilizado varía - relativamente poco espacio inutilizado en las pistas internas y una cantidad mucho mayor de espacio en las pistas más externas. En cualquier caso, este espacio inutilizado se desperdicia, pues allí no se puede almacenar datos.

Sin embargo, la ventaja que supera este espacio desperdiciado es que ahora es posible direccionar efectivamente el almacenamiento en un dispositivo de almacenamiento masivo. De hecho, hay dos métodos de direccionamiento - el direccionamiento basado en la geometría y el direccionamiento basado en bloques.

5.2.1. Direcciones basadas en la geometría

El término direccionamiento basado en la geometría se refiere al hecho de que dispositivos de almacenamiento masivo almacenan datos en un lugar específico en el medio de almacenamiento. En el caso de los dispositivos que se describen aquí, esto se refiere a tres items específicos que definen un punto específico en los platos del disco del dispositivo:

• Cilindros

• Cabezas

• Sectores

Las secciones siguientes describen como una dirección hipotética puede describir una ubicación física específica en el medio de almacenamiento.

3. Mientras que los dispositivos de almacenamiento masivo anteriores utilizaban el mismo número de sectores

para cada pista, los dispositivos más recientes dividen el rango de cilindros en "zonas" diferentes, con cada zona

teniendo un número de sectores por pista. La razón para esto es aprovechar el espacio adicional entre sectores en

los cilindros externos, donde existe más espacio sin utilizar.


5.2.1.1. Cilindros

Como se indicó anteriormente, el cilindro denota una posición específica del brazo de acceso (y por lo tanto, las cabezas de lectura/escritura). Especificando un cilindro particular, estamos eliminando todos los otros cilindros , reduciendo nuestra búsqueda a solamente una pista para cada superficie en el dispositivo de almacenamiento masivo.

Cilindros Cabezas Sectores

1014 X X

Tabla 5-1. Direcciones de Almacenamiento

En la Tabla 5-1, se ha llenado la primera parte de una dirección basada en la geometría. Dos componentes más a esta dirección — la cabeza y el sector — permanecen indefinidos.

5.2.1.2. Cabezas

Aunque en el sentido más estricto estamos seleccionando un plato de disco particular, puesto que la superficie tiene un cabezal de lectura/escritura dedicado a el, es más fácil pensar en términos de interactuar con un cabezal específico. De hecho, la electrónica subyacente del dispositivo actualmente selecciona un cabezal — eliminando la selección de el resto — solamente interactúa con el cabezal por la duración de la operación de E/S. Todas las otras pistas que conforman el cilindro actual han sido eliminados.


1014 2 X


En la Tabla 5-2, se llenan las primeras dos partes de una dirección basada en la geometría. Permanece indefinido un componente de esta dirección — el sector.

5.2.1.3. Sectores

Especificando un sector específico, se completa la dirección y se logra identificar unívocamente el bloque de datos deseado.


1014 2 12


En la Tabla 5-3, se llena la dirección completa basada en la geometría. Esta dirección identifica la ubicación de un bloque específico fuera de todos los otros bloques en ese dispositivo.

5.2.1.4. Problemas con el direccionamiento basado en la geometría

Mientras que el direccionamiento basado en la geometría es directo, hay un área de ambigüedad que pueda generar problemas. La ambigüedad está en la numeración de cilindros, cabezales y sectores.

Es verdad que cada dirección basada en la geometría identifica unívocamente un bloque de datos


específico, pero esto solamente aplica si no cambia el esquema de numeración para los cilindros, cabezales y sectores. Si el esquema de numeración cambia (tal como cuando el software/hardware interactuando con el dispositivo de almacenamiento cambia), entonces la correspondencia entre las direcciones basadas en la geometría y sus correspondientes bloques de datos serán diferentes, haciendo imposible acceder a los datos deseados.

Debido al potencial para esta ambigüedad, se desarrolló una solución diferente. La sección siguiente describe esto en más detalles.

5.2.2. Direcciones basadas en bloques

El direccionamiento basado en bloques es mucho más directo que el direccionamiento basado en la geometría. Con el direccionamiento basado en bloques, a cada bloque de datos se le dá un número único. Este número se pasa desde el computador al dispositivo de almacenamiento masivo, que luego lleva a cabo la conversión interna a la dirección basada en la geometría requerida por la circuitería de control del dispositivo.

Debido a que la conversión a la dirección basada en la geometría siempre la lleva a cabo el dispositivo mismo, esta es siempre consistente, eliminando así el problema inherente en dar la dirección basada en la geometría al dispositivo.

5.3. Interfaces de dispositivos de almacenamiento masivo

Cada dispositivo utilizado en un sistema computacional debe tener alguna forma de conectarse a dicho computador. Este punto de conexión se conoce como una interfaz. Los dispositivos de almacenamiento también tienen interfaces. Es importante conocer sobre las interfaces por dos razones principales:

• Existen muchas interfaces diferentes (la mayoría completamente incompatibles)

• Las diferentes interfaces tienen características de rendimiento y precios diferentes

Desafortunadamente, no existe una interfaz de dispositivos universal y tampoco una única interfaz para los dispositivos de almacenamiento. Por lo tanto, los administradores de sistemas deben estar conscientes de la(s) interfa(z/ces) soportadas por los sistemas de su organización. De lo contrario, está el riesgo de comprar el hardware incorrecto cuando se planea una actualización del sistema.

Las interfaces tienen diferentes capacidades de rendimiento, haciendo algunas más adecuadas que otras para ciertos ambientes. Por ejemplo, las interfaces capaces de soportar dispositivos de alta velocidad son más adecuadas para los ambientes de servidores, mientras que las interfaces más lentas son suficientes para un uso de escritorio más ligero. Tales diferencias en rendimiento llevan a diferencias en precios, lo que significa que — como siempre — usted recibe lo que paga. La computación de alto rendimiento no viene a precios bajos.

5.3.1. Antecedentes históricos

A través de los años se han creado diferentes interfaces para los dispositivos de almacenamiento masivo. Algunos están fuera del mercado, otros han prevalecido. Sin embargo, la lista siguiente proporciona una idea del ámbito del desarrollo de las interfaces sobre los últimos 30 años para así proporcionar una perspectiva de las interfaces en uso hoy día.

FD-400

Originalmente diseñada para las unidades de discos flexibles de 8 pulgadas a mitad de los años 70. Utilizaba un cable conductor 44 con un conector a la tarjeta de circuitos que suministraba tanto energía como datos.


SA-400

Otra interfaz para unidades de discos flexible (esta vez diseñada originalmente a finales de los 70 para el entonces nuevo disco de 5.25 pulgadas). Utilizaba un cable conductor de 34 con un conector de socket estándar. Una versión ligeramente modificada de esta interfaz aún se usa hoy día para las unidades de 5.25 pulgadas y las unidades de disco de 3.5 pulgadas.

IPI

Las siglas vienen de Intelligent Peripheral Interface; esta interfaz se utilizó en las unidades de discos de 8 y 14 pulgadas desarrollada para los minicomputadores en los años 70.

SMD

Un sucesor de IPI, SMD (viene de Storage Module Device o Dispositivo Modular de Almacenamiento ) se utilizó en los discos duros de los minicomputadores de 8 y 14 pulgadas de los años 70 y 80.

ST506/412

Una interfaz de disco duro que viene de los años 80. Utilizado en muchas computadoras personales de hoy, esta interfaz tiene dos cables - un conducto de 34 y otro de 20.

ESDI

Viene de Enhanced Small Device Interface, interfaz de dispositivos pequeños mejorada, esta interfaz se consideró un sucesor de ST506/412 con tasas de transferencia más rápida y soportando tamaños más grandes de unidades. La interfaz ESDI, de mediados de los 80, utilizaba el mismo esquema de conexión de dos cables que su predecesor.

También existían interfaces propietarias de los fabricantes más grandes (principalmente IBM y DEC). La intención detrás de la creación de estas interfaces fue intentar proteger el negocio extremadamente lucrativo de los periféricos para sus computadores. Sin embargo, debido a su naturaleza propietaria los dispositivos compatibles con estas interfaces eran más costosos que sus equivalentes no propietarios. Debido a esto, estas interfaces fallaron en alcanzar una popularidad a largo plazo.

Mientras que las interfaces propietarias han desaparecido en gran medida y las interfaces descritas aquí al principio de esta sección ya casi no tienen mucha posición (si es que tienen alguna) en el mercado, es importante conocer sobre estas interfaces que ya no se usan, pues prueban un punto — nada en la industria de la computación permanece constante por mucho tiempo. Por lo tanto, siempre esté atento a las nuevas tecnologías de interfaces; un día puede encontrar una que sea más adecuada para sus necesidades que las ofertas tradicionales en uso.

5.3.2. Interfaces de hoy día con estándares de la industria

A diferencia de las interfaces propietarias mencionadas en la sección anterior, algunas interfaces han sido adoptadas más globalmente y se convirtieron en estándares de la industria. Dos interfaces en particular han experimentado está transición y hoy son el corazón del estándar de la industria:

• IDE/ATA

• SCSI

5.3.2.1. IDE/ATA

IDE viene de Integrated Drive Electronics. Esta interfaz se originó a finales de los 80 y utiliza un conector de 40 pines.


Nota

En realidad, el nombre correcto para esta interfaz es "AT Attachment" (o ATA), pero el término "IDE"(que en realidad se refiere a un dispositivo de almacenamiento masivo compatible con ATA) todavíase utiliza. Sin embargo, para el resto de esta sección utiliza el nombre apropiado de esta interfaz -ATA.

ATA implementa una topología de bus, con cada bus soportando dos dispositivos de almacenamientomasivo. Estos dos dispositivos se conocen como maestro y esclavo. Estos términos pueden llevara confusiones, pues implican un tipo de relación entre los dispositivos; pero este no es el caso. Laselección de cual dispositivo es el maestro y cual es el esclavo, normalmente se selecciona a travésdel uso de bloques de jumpers en cada dispositivo.

Nota

Una innovación más reciente es la introducción de las capacidades de selección de cable a ATA.Esta innovación requiere el uso de un cable especial, un controlador ATA y dispositivos de almace-namiento masivo que soporten la selección del cable (normalmente a través de una configuraciónen jumpers de "selección de cable"). Cuando se configura de la forma adecuada, la selección decable elimina la necesidad de cambiar los jumpers cuando se mueven dispositivos; en vez de esto,la posición del dispositivo en el cable ATA denota si se trata del maestro o del esclavo.

Una variación de esta interfaz ilustra las formas únicas en que se pueden mezclar las tecnologías y tam-bién introduce nuestro próximo estándar de la industria para las interfaces. ATAPI es una variación dela interfaz ATA y viene de AT Attachment Packet Interface. Utilizada principalmente por las unidadesde CD-ROM, una ATAPI sigue los aspectos eléctricos y mecánicos de la interfaz ATA pero utiliza elprotocolo de comunicación de la próxima interfaz discutida — SCSI.

5.3.2.2. SCSI

Formalmente conocida como Small Computer System Interface, Interfaz para sistemas decomputación pequeños, SCSI como se conoce hoy día se originó a principios de los 80 y se declaróun estándar en 1986. De forma similar que ATA, SCSI utiliza una topología de bus. No obstante esees el fin de las semejanzas.

El uso de una topología de bus significa que cada dispositivo en el bus debe ser identificado de formaúnica de alguna forma. Mientras que ATA soporta solamente dos dispositivos diferentes para cadabus y les dá un nombre específico, SCSI hace esto asignando a cada dispositivo en el bus SCSI unadirección numérica única o SCSI ID. Cada dispositivo en un bus SCSI se debe configurar (usualmentemediante jumpers o switches4) para responder a su SCSI ID.

Antes de continuar más allá con esta discusión, es importante notar que el estándar SCSI no representauna única interfaz, pero una familia de interfaces. Hay varias áreas en las que SCSI varía:

• Ancho del bus

• Velocidad del bus

• Características eléctricas

4. Algunos hardware de almacenamiento (usualmente aquellos que incorporan conductores de unidades re-

movibles) están diseñados para que el hecho de conectar un módulo en un lugar, automáticamente configura el

SCSI ID a un valor adecuado.


El estándar SCSI original describe una topología de bus en la cual ocho líneas en el bus se utilizan para la transferencia de datos. Esto significa que los primeros dispositivos SCSI podían transferir datos solamente un byte a la vez. En años posteriores, se expandió el estándar para permitir implementaciones en las que se utilizaban dieciséis líneas, doblando la cantidad de datos que podían transmitir los dispositivos. Las implementaciones originales SCSI de "8 bits" se les conocía como SCSI angosto o narrow SCSI, mientras que las implementaciones de 16 bits se conocieron como SCSI amplio.

Originalmente, la velocidad del bus para SCSI estaba a 5MHz, permitiendo una tasa de transferencia de 5MB/segundo en el bus de 8-bits original. Sin embargo, las revisiones subsecuentes duplicaron la velocidad a 10MHz, resultando en 10MB/segundo para el SCSI angosto y 20MB/segundo para SCSI amplio. Con respecto al ancho del bus, los cambios en la velocidad del bus recibieron nuevos nombres, llamando a la velocidad de 10MHz rápida. Las mejoras subsecuentes empujaron la velocidad del bus a ultra (20MHz), fast-40 (40MHz) y fast-805 . Incrementos posteriores en las tasas de transferencia llevaron a muchas versiones diferentes de la velocidad ultra160.

Combinando estos términos, se pueden nombrar de forma concisa varias configuraciones SCSI. Por ejemplo, "ultra-wide SCSI" se refiere a un bus SCSI de 16-bits funcionando a 20MHz.

El estándar SCSI original utilizaba señalización single-ended; esto es una configuración eléctrica donde solamente se utiliza un conductor para pasar una señal eléctrica. Las implementaciones posteriores también permitieron el uso de la señalización diferencial, donde se utilizan dos conductores para pasar una señal. El SCSI diferencial (el cual posteriormente se llamó diferencial de alto voltaje o HVD SCSI) tiene el beneficio de una sensibilidad reducida ante el ruido eléctrico y permitía mayores largos de cable, pero nunca se volvió popular en el mercado de la computación convencional. Una implementación posterior, conocida como diferencial de bajo voltaje (LVD), finalmente se ha convertido en el requerimiento para las velocidades de bus altas.

El ancho de un bus SCSI no solamente dicta la cantidad de datos que se pueden transferir con cada ciclo del reloj, pero también determina cuantos dispositivos se pueden conectar a un bus. El SCSI normal soporta 8 dispositivos direccionados unívocamente, mientras que SCSI ancho soporta 16. En cualquier caso, debe asegurarse de que todos los dispositivos están configurados a un único ID SCSI. Dos dispositivos compartiendo un mismo ID produce problemas que pueden llevar a corrupción de los datos.

Otra cosa a tener en mente es que cada dispositivo en el bus utiliza un ID. Esto incluye el controlador SCSI. A menudo los administradores de sistemas se olvidan de esto e inconscientemente configuran un dispositivo a utilizar el mismo ID SCSI que el controlador de bus. Esto significa que, en práctica, solamente 7 dispositivos (o 15 para SCSI ancho) pueden estar presentes en un bus sencillo, pues cada bus debe reservar un ID para el controlador.

Sugerencia

La mayoría de las implementaciones incluyen alguna forma de escanear el bus SCSI; pero esto a menudo se utiliza para confirmar que todos los dispositivos esten correctamente configurados. Si el escaneo de un bus devuelve el mismo dispositivo para cada ID SCSI, ese dispositivo ha sido configurado de forma incorrecta al mismo ID SCSI que el controlador. Para resolver este problema, reconfigure el dispositivo para que utilice un ID SCSI diferente (y único).

Debido a la arquitectura orientada al bus de SCSI, es necesario terminar correctamente ambas puntas del bus. La terminación se logra colocando una carga con la impedancia correcta en cada conductor que comprende el bus SCSI. La terminación es un requerimiento eléctrico; sin el, las diferentes señales presentes en el bus se reflejaran fuera del bus, mutilando toda la comunicación.

5. Fast-80 técnicamente no es un cambio en la velocidad del bus; en cambio, se mantuvo el bus de 40MHz,

pero los datos fueron registrados al pulso en subida y bajada del reloj, duplicando efectivamente la salida.


Muchos (pero no todos) los dispositivos SCSI vienen con terminadores internos que se pueden habilitar o inhabilitar usando jumpers y switches. También están disponibles los terminadores externos.

Una última cosa a tener en mente sobre SCSI — no es simplemente una interfaz estándar para los dispositivos de comunicación masiva. Muchos otros dispositivos (tales como escaners, impresoras y dispositivos de comunicación) utilizan SCSI. Aunque son mucho menos comunes que los dispositivos de almacenamiento masivo SCSI, estos dispositivos si existen. Sin embargo, es posible que, con la llegada de USB y IEEE - 1394 (a menudo llamados Firewire), estas interfaces se utilizaran más para estos tipos de dispositivos en el futuro.

Sugerencia

Las interfaces USB y IEEE - 1394 también están comenzando a hacer incursiones en el campo del almacenamiento masivo; sin embargo, no existen actualmente dispositivos de almacenamiento masivo nativos USB o IEEE-1394. En cambio, las ofertas actuales están basadas en ATA o en SCSI con circuitería de conversión externa.

No importa la interfaz que un dispositivo de almacenamiento masivo utilice, el funcionamiento interno del dispositivo tiene una influencia en su rendimiento. La sección siguiente explora este importante tópico.

5.4. Características de rendimiento del disco duro

Las características de rendimiento del disco duro se presentaron en la Sección 4.2.4; esta sección discute esta materia en más detalle. Es importante que los administradores de sistemas entiendan esto, puesto que sin un conocimiento básico sobre cómo operan los discos duros, es posible hacer cambios inconscientemente a la configuración de su sistema que podrían impactar negativamente su rendimiento.

El tiempo que toma una unidad de disco en responder a una petición completa de E/S depende de dos cosas:

• Las limitaciones mecánicas y eléctricas del disco duro

• La carga de E/S impuesta por el sistema

Las secciones siguientes exploran en más profundidad estos aspectos del rendimiento del disco duro.

5.4.1. Limitaciones mecánicas/eléctricas

Puesto que los discos duros son dispositivos electromecánicos, están sujetos a varias limitaciones en su velocidad y rendimiento. Cada petición de E/S requiere que los diferentes componentes de su disco funcionen juntos para satisfacer la petición. Puesto que cada uno de estos componentes tiene diferentes características de rendimiento, el rendimiento general del disco duro está determinado por la suma del rendimiento de los componentes individuales.

Sin embargo, los componentes electrónicos son al menos un orden de magnitud más rápidos que sus componentes mecánicos. Por lo tanto, son los componentes mecánicos los que tienen el mayor impacto en el rendimiento general del disco duro.


Sugerencia

La forma más efectiva de mejorar el rendimiento del disco duro es reduciendo la actividad mecánica de la unidad tanto como sea posible.

El tiempo de acceso promedio de una unidad de disco duro promedio es de aproximadamente 8.5 milisegundos. Las secciones siguientes desglosan este número en más detalle, mostrando como cada componente impacta el rendimiento general del disco.

5.4.1.1. Tiempo de procesamiento de comandos

Todos los discos duros de hoy tienen sistemas computarizados sofisticados embebidos que controlan su operación. Estos sistemas de computación realizan las tareas siguientes:

• Se relacionan con el mundo externo a través de la interfaz del disco duro

• Controlan la operación del resto de los componentes del disco duro, recuperandose de cualquier condición de error que pueda surgir

• Procesan los datos leídos y escritos a la media de almacenamiento

Aún cuando los microprocesadores utilizados en los discos duros son relativamente poderosos, las tareas asignadas a ellos toman tiempo en llevarse a cabo. En promedio, este tiempo está en el rango de los .003 milisegundos.

5.4.1.2. Datos de cabezas leídas/escritas

Los cabezales de lectura/escritura del disco duro solamente funcionan cuando los platos del disco duro sobre los cuales estos "vuelan" estan girando. Debido a que es el movimiento de la media debajo de los cabezales lo que permite que los datos se lean o escriban, el tiempo que toma para que la media que contiene los sectores deseados pase completamente debajo del cabezal es el único determinante de la contribución del cabezal al tiempo total de acceso.

5.4.1.3. Latencia rotacional Puesto que los platos del disco están en contínuo movimiento, cuando llega la petición de E/S es muy poco probable que el plato se encuentre en el punto exacto en su rotación necesario para acceder el sector deseado. Por lo tanto, aún si el resto de la unidad está lista para acceder al sector, es necesario esperar mientras el plato está rotando, trayendo el sector deseado en posición bajo el cabezal de lectura/escritura.

Esta es la razón por la cual los discos duros de alto rendimiento típicamente giran sus platos de disco a altas velocidades. Hoy en día, las velocidades de 15,000 RPM están reservadas para unidades de más alto rendimiento, mientras que las de 5,400 RPM se consideran adecuadas solamente para discos a nivel de entrada de datos. Esto promedia 3 milisgundos para una unidad de 10,000 RPM.

5.4.1.4. Movimiento del brazo de acceso

Si existe un componente en los discos duros que se puede considerar como el talón de Aquiles, este es el brazo de acceso. La razón para esto es que el brazo de acceso se debe mover muy rápidamente y con gran precisión sobre relativamente largas distancias. Además, el movimiento del brazo de acceso no es continuo — debe acelerar rápidamente a medida que se acerca al cilindro deseado y luego desacelerar igualmente rápido para evitar disparar demasiado. Por lo tanto, el brazo de acceso debe ser resistente (para sobrevivir las violentas fuerzas provocadas por los rápidos movimientos) pero también ligero (así hay menos masa que acelerar/desacelerar).


Es difícil lograr estos objetivos conflictivos, un hecho que se demuestra por la cantidad de tiempo que se toma el brazo de acceso cuando se compara con el tiempo tomado por los otros componentes. Por lo tanto, el movimiento del brazo de acceso es el principal determinante del rendimiento general del disco duro, con un promedio de 5.5 milisegundos.

5.4.2. Cargas y rendimiento de E/S

La otra cosa que controla el rendimiento del disco duro es la carga de E/S a la cual su disco está sujeta. Algunos de los aspectos específicos de la carga de E/S son:

• La cantidad de lecturas contra escrituras

• El número de lectores/escritores actuales

• La ubicación de las lecturas/escrituras

Estos se discuten con más detalles en las secciones siguientes.

5.4.2.1. Lecturas contra Escrituras

Para el disco duro promedio usando media magnética para el almacenamiento de datos, el número de operaciones de lecturas de E/S contra el número de operaciones de escritura de E/S no es de mayor preocupación, pues la lectura y escritura de datos toma la misma cantidad de tiempo6 . Sin embargo, otras tecnologías de almacenamiento toman diferentes cantidades de tiempo para procesar las lecturas y las escrituras7 .

El impacto de esto es que los dispositivos que toman más tiempo en procesar las operaciones de escritura de E/S (por ejemplo) son capaces de manejar menos escrituras de E/S que lecturas. Véalo de otra forma, una escritura de E/S consume más de la habilidad del dispositivo de procesar las peticiones que una lectura de E/S.

5.4.2.2. Lecturas/Escrituras múltiples

Un disco duro que procesa peticiones de E/S desde múltiples fuentes experimenta una carga diferente que un disco duro que sirve peticiones E/S desde una única fuente. La principal razón para esto se debe al hecho de que múltiples solicitantes tienen el potencial de traer mayores cargas de E/S que soportar en un disco que un simple solicitante de E/S.

Esto se debe a que el solicitante de E/S debe ejecutar cierta cantidad de procesamiento antes de que la E/S tome lugar. Después de todo, el solicitante debe determinar la naturaleza de la petición de E/S antes de llevarla a cabo. Puesto que el procesamiento necesario para determinar esto toma tiempo, hay un límite en la carga de E/S que cualquier solicitante puede generar — solamente un CPU más rápido puede aumentar esto. Esta limitación se vuelve más pronunciada si el solicitante requiere de algún tipo de entrada manual antes de hacer la E/S.

6. En realidad, esto no es totalmente correcto. Todas las unidades de disco duro incluyen cierta cantidad de

memoria caché que se utiliza para mejorar el rendimiento de las lecturas. Sin embargo, cualquier petición de E/S

para leer datos se debe eventualmente satisfacer leyendo físicamente los datos desde la media de almacenamiento.

Esto significa que, mientras que la caché puede aliviar los problemas de rendimiento de lecturas de E/S, nunca se

puede eliminar totalmente el tiempo requerido para leer físicamente los datos desde la media. 7. Algunos discos ópticos presentan este comportamiento, debido a las limitaciones físicas de la tecnología

utilizada para implementar el almacenamiento óptico de datos.


Sin embargo, con múltiples solicitantes, se pueden soportar mayores cargas de E/S. Siempre y cuando se tenga suficiente poder de CPU para soportar el procesamiento necesario para generar las peticiones de E/S, el añadir más solicitantes de E/S también incrementa la carga resultante de E/S.

Sin embargo, hay otro aspecto sobre esto que también tiene una influencia en la carga de E/S resultante. Esto se discute en la sección siguiente.

5.4.2.3. Ubicación de Lecturas/Escrituras

Aún cuando no se limita estríctamente a un ambiente de múltiples solicitudes, este aspecto del rendimiento del disco duro tiende a mostrarse más en tales entornos. El problema es si la petición de E/S que se está haciendo al disco duro es por datos que físicamente están cerca de otros datos que también están siendo solicitados.

La razón de la importancia de esto se hace aparente si se tiene en mente la naturaleza electromecánica del disco duro. El componente más lento de la unidad de disco duro es el brazo de acceso. En consecuencia, si los datos accesados por la petición de E/S entrante no requiere mayor movimiento del brazo de acceso, el disco duro es capaz de servir más peticiones de E/S que si los datos solicitados estuviesen dispersos a lo largo de todo el disco, requiriendo un movimiento intensivo del brazo de acceso.

Esto se puede ilustrar viendo las especificaciones de rendimiento del disco duro. Estas especificaciones a menudo incluyen tiempos de búsquedas de cilindro adyacente (donde el brazo de acceso se mueve solamente una pequeña cantidad - solamente al siguiente cilindro) y tiempos de búsqueda de movimiento completo (donde el brazo de acceso se mueve desde el primer cilindro al último). Por ejemplo, he aquí los tiempos de búsquedas para un disco duro de alto rendimiento:

Cilindro adyacente Movimiento completo

0.6 8.2

Tabla 5-4. Tiempos de movimiento al cilindro adyacente y de movimiento completo (en milisegundos)

5.5. Preparar el almacenamiento para ser utilizado

Una vez que el dispositivo de almacenamiento esta en su lugar, es poco lo que se puede hacer con el. Cierto, se pueden escribir y leer datos desde el mismo, pero sin una estructura subyacente el acceso de datos solamente es posible utilizando direcciones de sectores (bien sea geométrica o lógica).

Lo que se necesita son métodos para convertir el almacenamiento sin formato en un disco duro que sea utilizable fácilmente. Las secciones siguientes exploran algunas de las técnicas usadas más comúnmente para lograr esto.

5.5.1. Particiones/cuotas

Lo primero que sorprende a un administrador de sistemas es que el tamaño de una unidad de disco puede ser mucho mayor que lo necesario para la tarea a realizar. Como resultado, muchos sistemas operativos tienen la capacidad de dividir una unidad de disco duro en varias particiones o secciones.

Puesto que estas se encuentran separadas unas de otras, las particiones pueden tener diferentes cantidades de espacio utilizado, y ese espacio de ninguna manera impacta el espacio utilizado por las otras particiones. Por ejemplo, la partición que almacena los archivos del sistema operativo no se ve


afectada aún cuando la partición que contiene los archivos de usuarios se llena completamente. El sistema operativo todavía tiene espacio libre para su propio uso.

Aunque puede parecer un enfoque simplista, puede pensar en las particiones como unidades de disco individuales. De hecho, algunos sistemas operativos de hecho se refieren a las particiones como "unidades". Sin embargo, este punto de vista no es totalmente correcto; por lo tanto, es importante observar las particiones un poco más de cerca.

5.5.1.1. Atributos de particiones

Las particiones se definen por los atributos siguientes:

• Geometría de la partición

• Tipo de la partición

• Campo del tipo de partición

Estos atributos se exploran con más detalles en las secciones siguientes.

5.5.1.1.1. Geometría

La geometría de una partición se refiere a su colocación física en la unidad de disco. La geometría se puede especificar en términos de cilindros de comienzo y final, cabezales y sectores, aunque a menudo las particiones comienzan y terminan en los límites del cilindro. El tamaño de una partición se define como la cantidad de almacenamiento entre el cilindro de comienzo y el del final.

5.5.1.1.2. Tipo de partición

El tipo de la partición se refiere a la relación de la partición con las otras particiones en el disco duro. Hay tres tipos de particiones:

• Particiones Primarias

• Particiones extendidas

• Particiones lógicas

Las secciones siguientes describen cada tipo de partición.

5.5.1.1.2.1. Particiones primarias

Las particiones primarias son particiones que toman hasta cuatro de los ranuras de particiones en la tabla de particiones del disco duro.

5.5.1.1.2.2. Particiones extendidas

Las particiones extendidas fueron desarrolladas en respuesta a la necesidad de más de cuatro particiones por unidad de disco. Una partición extendida puede contener dentro de sí múltiples particiones, extendiendo el número de particiones posibles en una sola unidad de disco. La introducción de las particiones extendidas se generó por el desarrollo constante de las capacidades de los discos duros.


5.5.1.1.2.3. Particiones lógicas

Las particiones lógicas son aquellas que están contenidas dentro de una partición extendida; en términos de uso, son iguales a una partición primaria no extendida.

5.5.1.1.3. Campo de tipo de partición

Cada partición tiene un campo de tipo que contiene un código que indica el uso anticipado de la partición. El campo de tipo puede o no reflejar el sistema operativo del computador. En cambio, puede reflejar como los datos son almacenados dentro de la partición. La sección siguiente contiene más información sobre este importante aspecto.

5.5.2. Sistemas de archivos

Aún teniendo el dispositivo de almacenamiento masivo configurado y particionado correctamente, sería difícil almacenar y recuperar información — todavía nos falta una forma de estructurar y organizar esa información. Lo que necesitamos es un sistema de archivos.

El concepto de un sistema de archivos es tan fundamental para el uso de los dispositivos de almacenamiento masivo que el usuario de computadoras promedio ni siquiera hace una distinción entre los dos. Sin embargo, los administradores de sistemas no se pueden permitir ignorar los sistemas de archivos y su impacto en el trabajo diario.

Un sistema de archivos es un método para representar datos en un dispositivo de almacenamiento masivo. Los sistemas de archivos usualmente incluyen las características siguientes:

• Almacenamiento de datos basado en archivos

• Estructura de directorio jerárquico (algunas veces llamado "carpeta")

• Seguimiento de la creación de archivos, tiempos de acceso y de modificación

• Algún nivel de control sobre el tipo de acceso permitido para un archivo específico

• Un concepto de propiedad de archivos

• Contabilidad del espacio utilizado

No todos los sistemas de archivos tienen todas estas funcionalidades. Por ejemplo, un sistema de archivos construído para un sistema operativo monousuario podría fácilmente utilizar un método de control de acceso más simplificado y no requerir el soporte para la propiedad de archivos.

Un punto a tener en cuenta es que el sistema de archivos utilizado puede tener un gran impacto en la naturaleza de su carga de trabajo diaria. Al cerciorarse de que su sistema de archivos se ajusta mejor a los requerimientos funcionales de su organización, se puede asegurar de que no sólo el sistema está a la altura de la tarea, pero también que es más fácil y eficiente de mantener.

Con esto en mente, las secciones siguientes exploran estas funcionalidades en más detalles.

5.5.2.1. Almacenamiento basado en archivos

Mientras que los sistemas de archivos que utilizan esta metáfora para el almacenamiento de datos son practicamente universales que casi se consideran como la norma, todavía existen varios aspectos que se deben considerar.

Primero debe estar consciente de cualquier restricción de nombres. Por ejemplo, ¿cuáles son los carácteres permitidos en un nombre de archivo? ¿Cuál es el largo máximo para un nombre de archivo? Estas preguntas son importantes, pues dictan cuales nombres de archivos se pueden utilizar y cuales no. Los


sistemas operativos más antigüos con sistemas de archivos más primitivos permitían solamente caracteres alfanuméricos (y solamente mayúsculas) y únicamente nombres de archivos 8.3 (lo que significa un nombre de archivo de ocho carácteres, seguido de una extensión de tres carácteres).

5.5.2.2. Estructura de directorio jerárquico

Mientras que los sistemas de archivos en ciertos sistemas operativos antigüos no incluían el concepto de directorios, todos los sistemas de archivos de hoy día incluyen esta característica. Los directorios son usualmente implementados como archivos, lo que significa que no se requiere de utilidades especiales para mantenerlos.

Más aún, puesto que los directorios son en sí mismos archivos, y los directorios contienen archivos, los directorios pueden a su vez contener otros directorios, conformando una estructura jerárquica de múltiples niveles. Este es un concepto poderoso con el cual muchos administradores de sistemas deberían de estar familiarizados. Usando las jerarquías de múltiples niveles puede hacer la administración de archivos mucho más fácil para usted y sus usuarios.

5.5.2.3. Seguimiento de la creación de archivos, tiempos de acceso y modificación

La mayoría de los sistemas de archivos mantienen un seguimiento del tiempo en el que se creó un archivo; otros mantienen un seguimiento de los tiempos de acceso y modificación. Más allá de la conveniencia de poder determinar cuando un archivo dado fue creado, accedido o modificado, estas fechas son vitales para la operación adecuada de los respaldos incrementales.

Se puede encontrar más información sobre como los respaldos utilizan estas funcionalidades de los sistema de archivos en la Sección 8.2.

5.5.2.4. Control de acceso

El control de acceso es un área en la que los sistemas de archivso difieren dramáticamente. Algunos sistemas de archivos no tienen un modelo claro para el control de acceso, mientras que otros son mucho más sofisticados. En términos generales, la mayoría de los sistemas de archivos modernos combinan dos componentes en una metodología cohesiva de control de acceso:

• Identificación del usuario

• lista de acciones permitidas

La identificación de usuarios significa que el sistema de archivos (y el sistema operativo subyacente) primeramente debe ser capaz de identificar unívocamente a usuarios individuales. Esto hace posible tener una responsabilidad completa con respecto a cualquier operación a nivel de sistema de archivos. Otra funcionalidad de ayuda es la de los grupos de usuarios. Se utilizan grupos más a menudo en organizaciones donde los usuarios pueden ser miembros de uno o más proyectos. Otra funcionalidad que algunos sistemas de archivos soportan es la creación de identificadores genéricos que se pueden asignar a uno o más usuarios.

Luego, el sistema de archivos debe ser capaz de mantener listas de las acciones que son permitidas (o prohibidas) para cada archivo. Las acciones a las que se les hace seguimiento más a menudo son:

• Leer el archivo

• Escribir al archivo

• Ejecutar el archivo

Varios sistemas de archivos pueden extender la lista para incluir otras acciones tales como eliminar, o hasta la habilidad de hacer cambios al control de acceso del archivo.


5.5.2.5. Contabilidad del espacio utilizado

Una constante en la vida de un administrador de sistemas es la de que nunca hay suficiente espacio libre, y aún si lo hubiese, no estará disponible por mucho tiempo. Por lo tanto, un administrador de sistemas debería al menos ser capaz de determinar fácilmente el nivel de espacio libre disponible para cada sistema de archivos. Además, los sistemas de archivos con capacidades de identificación de usuarios bien definidas, a menudo incluyen la característica de mostrar la cantidad de espacio que un usuario particular ha consumido.

Esta característica es vital en grandes entornos de usuarios, pues es un hecho que la regla de 80/20 se aplica a menudo al espacio en disco — 20 por ciento de sus usuarios serán responsables por el consumo de 80 por ciento de su espacio disponible en disco. Al facilitar la identificación de estos usuarios en el 20 por ciento, puede más efectivamente manejar sus activos relacionados al almacenamiento.

Tomando este paso un poco más allá, algunos sistemas de archivos incluyen la habilidad de establecer los límites de uso del usuario (conocidos comunmente como cuotas de disco) en la cantidad de espacio en disco que pueden consumir. Los detalles específicos varían de un sistema de archivos al otro, pero en general a cada usuario se le puede asignar una cantidad específica de almacenamiento que un usuario puede utilizar. Más allá de allí, los sistemas de archivos varían. Algunos sistemas de archivos permiten que el usuario se exceda de su límite solamente una vez, mientras que otros implementan un "período de gracia" durante el que aplica un segundo límite más alto.

5.5.3. Estructura del directorio

Muchos administradores de sistemas le dan poca importancia a como el espacio que hoy le dan a sus usuarios será utilizado en un futuro. Sin embargo, un poco de reflexión sobre esta materia antes de pasar el almacenamiento a sus usuarios, le puede ahorrar bastante trabajo innecesario más adelante.

Lo principal que un administrador de sistemas puede hacer es utilizar directorios y subdirectorios para estructurar el almacenamiento disponible de una forma comprensible. Esto trae muchos beneficios:

• Más fácil de entender

• Más flexibilidad en un futuro

Al imponer cierto nivel de estructura en su almacenamiento, este se puede entender más fácilmente. Por ejemplo, considere un sistema grande multiusuario. En vez de colocar todos los directorios de usuarios en un gran directorio, tiene sentido utilizar subdirectorios que reflejan la estructura de su organización. De esta forma, la gente que trabaja en contabilidad tendrá sus directorios bajo un directorio llamado contabilidad, los que trabajan en ingeniería tendrán sus directorios bajo ingenieria y así sucesivamente.

Los beneficios de tal enfoque son que hace más fácil hacer un seguimiento diario de las necesidades de almacenamiento (y uso) para cada parte de su organización. Obtener una lista de los archivos utilizados por todo el mundo en recursos humanos es directo. Respaldar todos los archivos usados por el departamento legal es fácil.

Con la estructura apropiada, se incrementa la flexibilidad. Para continuar utilizando el ejemplo anterior, asuma por un momento que el departamento de ingeniería está a punto de arrancar varios proyectos. Debido a esto, se contrataran muchos nuevos ingenieros en un futuro cercano. Sin embargo, actualmente no hay suficiente almacenamiento disponible para soportar las adiciones esperadas para ingeniería.

Sin embargo, puesto que cada persona en ingeniería tiene sus archivos almacenados bajo el directorio ingenieria, lo siguiente será un proceso bien directo:

• Obtener el espacio adicional necesario para ingeniería

• Respaldar todo bajo el directorio ingenieria


• Restaurar el respaldo a un nuevo almacenamiento

• Cambie el nombre del directorio ingenieria en el almacenamiento original a algo como fichero_ingenieria (antes de eliminarlo completamente luego de su funcionamiento normal con la nueva configuración por un mes)

• Haga los cambios necesarios para que todo el personal de ingeniería pueda acceder a sus archivos en el nuevo almacenamiento

Por supuesto, tal enfoque también tiene sus limitaciones. Por ejemplo, si la gente se mueve con frecuencia entre departamentos, debe tener una forma de mantenerse informado de estos cambios y debe modificar la estructura del directorio de la forma correspondiente. De lo contrario, la estructura ya no reflejará la realidad, lo que significa más trabajo — no menos — a largo plazo para usted.

5.5.4. Activando el acceso al almacenamiento

Una vez que un dispositivo de almacenamiento masivo se particione correctamente y se le escriba un sistema de archivos, el almacenamiento estará listo para su uso general.

Para algunos sistemas operativos, esto es verdad; tan pronto como el sistema operativo detecta el nuevo dispositivo de almacenamiento masivo, el administrador del sistema lo puede formatear y está listo para ser accesado sin esfuerzo adicional.

Otros sistemas operativos requieren de un paso adicional. Este paso - a menudo conocido como montar — dirige al sistema operativo sobre cómo se debe acceder al almacenamiento. El montaje del almacenamiento normalmente se hace a través de un programa de utilidades especial o un comando y requiere que el dispositivo de almacenamiento masivo (y posiblemente la partición también) sea identificada explícitamente.

5.6. Tecnologías avanzadas de almacenamiento

Aunque todo lo que se ha presentado hasta ahora en este capítulo solamente trata con discos duros únicos conectados directamente a un sistema, existen otras opciones más avanzadas que explorar. Las secciones siguientes describen algunos de los enfoques más comunes para extender sus opciones de almacenamiento masivo.

5.6.1. Almacenamiento accesible a través de la red

Combinando redes con las tecnologías de almacenamiento masivo puede resultar en una flexibilidad excelente para los administradores de sistemas. Con este tipo de configuración se tienen dos beneficios posibles:

• Consolidación del almacenamiento

• Administración simplificada

El almacenamiento se puede consolidar implementando servidores de alto rendimiento con conexiones de red de alta velocidad y configurados con grandes cantidades de almacenamiento rápido. Con la configuración apropiada, es posible suministrar acceso al almacenamiento a velocidades comparables al almacenamiento conectado directamente. Más aún, la naturaleza compartida de tal configuración a menudo hace posible reducir los costos, ya que los gastos asociados con suministrar almacenamiento centralizado y compartido pueden ser menores que suministrar el almacenamiento equivalente para cada uno de los clientes. Además, el espacio libre está consolidado, en vez de esparcido (pero no utilizable globalmente) entre los clientes.

Los servidores de almacenamiento centralizado también puede hacer muchas tareas administrativas más fáciles. Por ejemplo, monitorizar el espacio libre es mucho más fácil cuando el almacenamiento


a supervisar existe en un sólo servidor centralizado. Los respaldos también se pueden simplificar en gran medida usando un servidor de almacenamiento centralizado. Es posible hacer respaldos basados en la red para múltiples clientes, pero se requiere más trabajo para configurar y mantener.

Existen varias tecnologías disponibles de almacenamiento en red; seleccionar una puede ser complicado. Casi todos los sistemas operativos en el mercado hoy día incluyen alguna forma de acceder a almacenamiento en red, pero las diferentes tecnologías son incompatibles entre ellas. ¿Cuál es el mejor enfoque para determinar la mejor tecnología a implementar?

El enfoque que usualmente deriva los mejores resultados es dejar que las capacidades incorporadas del cliente decidan el problema. Esto tiene varias razones:

• Problemas mínimos de integración de clientes

• Trabajo mínimo en cada sistema cliente

• Costos bajos de entrada por cliente

Tenga en cuenta que cualquier problema relacionado a clientes son multiplicados por el número de clientes en su organización. Usando las capacidades incorporadas de los clientes, no tiene que instalar software adicional en cada cliente (lo que resulta en cero costos adicionales en adquisición de software). Y tiene grandes posibilidades de soporte e integración con el sistema operativo del cliente.

Sin embargo, hay una desventaja. Esto significa que el entorno del servidor debe estar al nivel de la tarea de suministrar buen soporte para las tecnologías de almacenamiento basadas en la red requeridas por los clientes. En casos donde el servidor y el sistema operativo cliente son uno y el mismo, normalmente no hay ningún problema. De lo contrario, será necesario invertir un poco de tiempo y esfuerzo en hacer que el servidor "hable" el idioma del cliente. Sin embargo, a menudo este costo está más que justificado.

5.6.2. Almacenamiento basado en RAID

Una habilidad que un administrador de sistemas debería cultivar es la dever las complejas configuraciones de sistemas y observar las diferentes limitaciones inherentes a cada configuración. Mientras que esto, a primera vista, puede parecer un punto de vista deprimente a tomar, puede ser una forma excelente de ver más allá de las brillantes cajas nuevas y visualizar una futura noche del sábado con toda la producción detenida debido a una falla que se podría haber evitado fácilmente con pensarlo un poco.

Con esto en mente, utilicemos lo que conocemos sobre el almacenamiento basado en discos y veamos si podemos determinar las formas en que los discos pueden causar problemas. Primero, considere un falla absoluta del hardware:

Un disco duro con cuatro particiones se muere completamente: ¿qué pasa con los datos en esas particiones?

Está indisponible inmediatamente (al menos hasta que la unidad dañada pueda ser reemplazada y los datos restaurados desde el respaldo más actual).

Un disco duro con una sola partición está operando en los límites de su diseño debido a cargas de E/S masivas: ¿qué le pasa a las aplicaciones que requieren acceso a los datos en esa partición?

Las aplicaciones se vuelven más lentas debido a que el disco duro no puede procesar lecturas y escrituras más rápido.

Tiene un archivo de datos que poco a poco sigue creciendo en tamaño; pronto será más grande que el disco más grande disponible en su sistema. ¿Qué pasa entonces?

La unidad de disco se llena, el archivo de datos deja de crecer y su aplicación asociada deja de funcionar.


Cualquiera de estos problemas puede dejar su centro de datos inútil, sin embargo los administradores de sistemas deben enfrentarse a este tipo de problemas todos los días. ¿Qué se puede hacer?

Afortunadamente, existe una tecnología que puede resolver cada uno de estos problemas. El nombre de esta tecnología es RAID.

5.6.2.1. Conceptos básicos

RAID es el acrónimo para Redundant Array of Independent Disks, Formación de Discos Independientes Redundantes8 . Como su nombre lo implica, RAID es una forma para que discos múltiples actúen como si se tratasen de una sola unidad.

Las técnicas RAID primero fueron desarrolladas por investigadores en la Universidad de California, Berkeley a mitad de los 80. En ese tiempo, había un gran separación entre las unidades de disco de alto rendimiento utilizadas por las grandes instalaciones computacionales del momento, y las unidades de disco más pequeñas utilizadas por la joven industria de las computadoras personales. RAID se veía como el método para tener varios discos menos costosos sustituyendo una unidad más costosa.

Más aún, las formaciones RAID se pueden construir de varias formas, resultando en características diferentes dependiendo de la configuración final. Vamos a ver las diferentes configuraciones (conocidas como niveles RAID) en más detalles.

5.6.2.1.1. Niveles de RAID

Los investigadores de Berkeley originalmente definieron cinco niveles RAID y los nombraron del "1" al "5." Luego, otros investigadores y miembros de la industria del almacenamiento definieron niveles RAID adicionales. No todos los niveles RAID eran igualmente útiles; algunos eran de interés solamente para propósitos de investigación y otros no se podían implementar de una forma económica.

Al final, habían tres niveles de RAID que terminaron siendo ampliamente utilizados:

• Nivel 0

• Nivel 1

• Nivel 5

Las secciones siguientes discuten cada uno de estos niveles en más detalles.

5.6.2.1.1.1. RAID 0

La configuración del disco conocida como RAID 0 tiende a confundir un poco, pues este es el único tipo de nivel RAID que no implementa absolutamente ninguna redundancia. Sin embargo, aún cuando RAID 0 no tiene ventajas con respecto a su confiabilidad, si tiene otros beneficios.

Una formación RAID 0 consiste de dos o más unidades de disco. La capacidad del almacenamiento en cada disco se divide en pedazos, los cuales representan algún múltiplo del tamaño de bloque nativo del disco. Los datos escritos a la formación se escriben, pedazo a pedazo, en cada unidad de la formación. Los pedazos se pueden ver como tiras o rayas que se van juntando a lo largo de cada unidad en la formación; de allí el otro nombre con el que se conoce a RAID 0: striping.

Por ejemplo, con una formación de dos discos y un tamaño de pedazos de 4KB, el escribir 12KB de datos a la formación, produce que los datos se escriban en tres pedazos de 4KB a las unidades siguientes:

8. Cuando comenzaron las primeras investigaciones de RAID, el acrónimo venía de Redundant Array of Inex

pensive Disks, pero con el paso del tiempo los discos "independientes" que RAID pretendía sustituir se volvieron

más y más económicos, dejando la cuestión del costo un poco sin sentido.


• Los primeros 4KB se escriben al primer disco, en el primer pedazo

• Los segundos 4KB se escriben al segundo disco, en el primer pedazo

• Los últimos 4KB se escriben en el primer disco, en el segundo pedazo

Comparado con una unidad de disco sencilla, las ventajas de RAID 0 incluyen:

• Tamaño total más grande - RAID 0 se puede construir de manera que es más grande que un único disco, haciendo más fácil el almacenamiento de grandes archivos.

• Mejor rendimiento de lecturas/escrituras - Las cargas por E/S en una formación RAID 0 se pueden distribuir uniformemente entre todas las unidades en la formación (asumiendo que todas las E/S no están concentradas en un único pedazo)

• No se desperdicia espacio - Todo el almacenamiento en todas las unidades en la formación están disponibles para almacenamiento de datos

Comparado con un disco sencillo, RAID 0 tiene las siguientes desventajas:

• Menos confiable - Cada disco en un RAID 0 debe estar operativo para que la formación esté disponible; una falla en un disco-N de RAID 0 resulta en la eliminación de 1/N avo de todos los datos, dejando la formación inutilizable

Sugerencia

Si tiene problemas para distinguir los diferentes niveles de RAID, simplemente recuerde que RAID 0 tiene un porcentaje de redundancia cero.

5.6.2.1.1.2. RAID 1

RAID 1 utiliza dos (aunque algunas implementaciones soportan más) unidades de disco idénticas. Todos los datos son escritos a ambas unidades, haciendolos imágenes espejo. Por eso es que RAID 1 a menudo se conoce como mirroring.

Cuando los datos son escritos a una formación RAID 1, deben efectuarse dos escrituras físicas simultáneas: una al primer disco y otra al segundo. La lectura de datos, por otro lado, solamente se hace una vez y se puede llevar a cabo en cualquiera de los discos.

Comparado con un disco único, una formación RAID 1 tiene las ventajas siguientes:

• Redundancia mejorada - Aún si uno de los discos falla, los datos todavía estarán accesibles

• Mejor rendimiento de lecturas - Con ambos discos operacionales, las lecturas pueden ser distribuídas uniformemente entre ellos, reduciendo las cargas de E/S por disco

Cuando se compara con un sólo disco de duro, una formación RAID 1 tiene algunas desventajas:

• El tamaño máximo de la formación está limitado a la unidad más grande disponible.

• Rendimiento reducido en las escrituras - Debido a que ambos discos se deben mantener actualizados, todas las operaciones de E/S deben realizarse en ambos discos, haciendo más lento el proceso general de escribir datos a la formación

• Eficiencia de costos reducida - Con un disco completo dedicado a la redundancia, el costo de una formación RAID 1 es al menos el doble de lo que costaría un sólo disco


Sugerencia

Si tiene problemas para distinguir los diferentes nivels de RAID, solamente tiene que recordar que RAID 1 tiene 100 por ciento redundancia.

5.6.2.1.1.3. RAID 5

RAID 5 trata de combinar los beneficios de RAID 0 y RAID 1, a la vez que trata de minimizar sus desventajas.

Igual que RAID 0, un RAID 5 consiste de múltiples unidades de disco, cada una dividida en pedazos. Esto permite a una formación RAID 5 ser más grande que una unidad individual. Como en RAID 1, una formación RAID 5 utiliza algo de espacio en disco para alguna forma de redundancia, mejorando así la confiabilidad.

Sin embargo, la forma en que RAID 5 funciona es diferente a RAID 0 o 1.

Una formación RAID 5 debe consistir de al menos tres discos idénticos en tamaño (aunque se pueden utilizar más discos). Cada unidad está dividida en pedazos y los datos se escriben a los pedazos siguiendo un orden. Sin embargo, no cada pedazo está dedicado al almacenamiento de datos como en RAID 0. En cambio, en una formación con n unidades en ella, el enésimo pedazo está dedicado a la paridad.

Los pedazos que contienen paridad hacen posible recuperar los datos si falla una de las unidades en la formación. La paridad en el pedazo x se calcula matemáticamente combinando los datos desde cada pedazo x almacenado en todas las otras unidades en la formación. Si los datos en un pedazo son actualizados, el correspondiente pedazo de paridad debe ser recalculado y actualizado también.

Esto también significa que cada vez que se escriben datos en la formación, al menos dos unidades son escritas a: la unidad almacenando los datos y la unidad que contiene el pedazo con la paridad.

Un punto clave a tener en mente es que los pedazos de paridad no están concentrados en una sola unidad de la formación. En cambio, están distribuidos uniformemente a lo largo de todas las unidades. Aún cuando es posible dedicar una unidad específica para que contenga únicamente paridad (de hecho, esta configuración se conoce como RAID nivel 4), la actualización constante de la paridad a medida que se escriben datos a la formación significa que la unidad de paridad se podría convertir en un cuello de botella. Distribuyendo la información de paridad uniformemente a través de la formación, se reduce este impacto.

Sin embargo, es importante recordar el impacto de la paridad en la capacidad general de almacenamiento de la formación. Aún cuando la información de paridad se distribuye uniformemente a lo largo de todos los discos, la cantidad de almacenamiento disponible se reduce por el tamaño de un disco.

Comparado con un único disco, una formación RAID 5 tiene las ventajas siguientes:

• Redundancia mejorada - Si falla una unidad de la formación, se puede utilizar la información de paridad para reconstruir las partes de datos faltantes, todo esto mientras se mantiene la formación disponible para su uso9

• Mejor rendimiento de lecturas - Debido a la forma similar a RAID 0 en que los datos son divididos entre los discos de la formación, la actividad de E/S de distribuye uniformemente entre todos los discos

• Costo eficiencia razonablemente buena - Para una formación RAID 5 de n unidades, solamente 1/navo del total de almacenamiento disponible está dedicado a la redundancia

9. Se reduce el rendimiento de E/S cuando se está funcionando con una unidad faltante debido a la sobrecarga

generada en reconstruir los datos faltantes.


Comparado con un sólo disco, una formación RAID 5 tiene las siguientes desventajas:

• Rendimiento de escritura reducido - Puesto que cada escritura a la formación resulta en al menos dos escrituras a los discos físicos (una escritura para los datos y otra para la paridad), el rendimiento de escrituras es peor que en una sola unidad10

5.6.2.1.1.4. Niveles RAID anidados

Como debería ser obvio a partir de la discusión sobre los diferentes niveles de RAID, cada nivel tiene sus fortalezas y debilidades específicas. No fue mucho tiempo después de que se comenzó a implementar el almacenamiento basado en RAID que la gente comenzó a preguntarse si los diferentes niveles RAID se podrían combinar de alguna forma, produciendo formaciones con todas las fortalezas y ninguna de las debilidades de los niveles originales.

Por ejemplo, ¿qué pasa si los discos en una formación RAID 0 fuesen en verdad formaciones RAID 1? Esto proporcionaría las ventajas de la velocidad de RAID 0, con la confiabilidad de un RAID 1.

Este es el tipo de cosas que se pueden hacer. He aquí los niveles de RAID más comunes:

• RAID 1+0

• RAID 5+0

• RAID 5+1

Debido a que los RAID anidados se utilizan en ambientes más especializados, no nos vamos a ir en más detalles aquí. Sin embargo, hay dos puntos a tener en mente cuando se piense sobre RAID anidados:

• Otros aspectos - El orden en el que los niveles RAID son anidados pueden tener un gran impacto en la confiabilidad. En otras palabras, RAID 1+0 and RAID 0+1 no son lo mismo.

• Los costos pueden ser altos - Si hay alguna desventaja común a todas las implementaciones RAID, es el costo; por ejemplo, la formación RAID 5+1 más pequeña posible, consiste de seis discos (y se requieren hasta más discos para formaciones más grandes).

Ahora que ya hemos explorado los conceptos detrás de RAID, vamos a ver cómo se puede implementar RAID.

5.6.2.1.2. Implementaciones RAID

Es obvio a partir de las secciones anteriores que RAID requiere "inteligencia" adicional sobre y por encima del procesamiento usual de discos de E/S para unidades individuales. Como mínimo, se deben llevar a cabo las tareas siguientes:

• Dividir las peticiones de E/S entrantes a los discos individuales de la formación

• Para RAID 5, calcular la paridad y escribirla al disco apropiado en la formación

• Supervisar los discos individuales en la formación y tomar las acciones apropiadas si alguno falla

• Controlar la reconstrucción de un disco individual en la formación, cuando ese disco haya sido reemplazado o reparado

10. También existe un impacto por los cálculos de paridad requeridos por cada escritura. Sin embargo, dependi

endo de la implementación de RAID 5 específica (específicamente, dónde se realizan los cálculos de paridad en

el sistema), este impacto puede variar desde muy grandes a inexistentes.


• Proporcionar los medios para permitir a los administradores que mantengan la formación (eliminando y añadiendo discos, iniciando y deteniendo reconstrucciones, etc.)

Hay dos métodos principales que se pueden utilizar para lograr estas tareas. Las próximas dos secciones las describen en más detalles.

5.6.2.1.2.1. Hardware RAID

Una implementación de hardware RAID usualmente toma la forma de una tarjeta controladora de disco. La tarjeta ejecuta todas las funciones relacionadas a RAID y controla directamente las unidades individuales en las formaciones conectadas a ella. Con el controlador adecuado, las formaciones manejadas por una tarjeta de hardware RAID aparecen ante el sistema operativo anfitrión como si se tratasen de unidades de disco normales.

La mayoría de las tarjetas controladoras RAID trabajan con SCSI, aunque hay algunos controladores RAID basados en ATA también. En cualquier caso, la interfaz administrativa se implementa usualmente en una de tres formas:

• Programas de utilerías especializados que funcionan como aplicaciones bajo el sistema operativo anfitrión, presentando una interfaz de software a la tarjeta controladora

• Una interfaz en la tarjeta usando un puerto serial que es accedido usando un emulador de terminal

• Una interfaz tipo BIOS que solamente es accesible durante la prueba de encendido del sistema

Algunas controladores RAID tienen más de un tipo de interfaz administrativa disponible. Por razones obvias, una interfaz de software suministra la mayor flexibilidad, ya que permite funciones administrativas mientras el sistema operativo se está ejecutando. Sin embargo, si está arrancando un sistema operativo desde una controladora RAID, se necesita una interfaz que no requiera un sistema operativo en ejecución.

Puesto que existen muchas tarjetas controladoras RAID en el mercado, es imposible ir en más detalles aquí. Lo mejor a hacer en estos casos es leer la documentación del fabricante para más información.

5.6.2.1.2.2. Software RAID

Software RAID es RAID implementado como kernel - o software a nivel de controladores para un sistema operativo particular. Como tal, proporciona más flexibilidad en términos de soporte de hardware - siempre y cuando el sistema operativo soporte ese hardware, se pueden configurar e implementar las formaciones RAID. Esto puede reducir dramáticamente el costo de implementar RAID al eliminar la necesidad de adquirir hardware costoso especializado.

A menudo el exceso de poder de CPU disponible para los cálculos de paridad RAID exceden en gran medida el poder de procesamiento presente en una tarjeta controladora RAID. Por lo tanto, algunas implementaciones de software RAID en realidad tienen mejores capacidades de rendimiento que las implementaciones de hardware RAID.

Sin embargo, el software RAID tiene ciertas limitaciones que no están presentes en hardware RAID. La más importante a considerar es el soporte para el arranque desde una formación de software RAID. En la mayoría de los casos, solamente se puede utilizar formaciones RAID 1 para arrancar, ya que el BIOS del computador no está al tanto de RAID. Puesto que no se puede distinguir una unidad única de una formación RAID 1 de un dispositivo de arranque no RAID, el BIOS puede iniciar exitósamente el proceso de arranque; luego el sistema operativo puede cambiarse a la operación desde el software RAID una vez que haya obtenido el control sobre el sistema.


5.6.3. Administración de Volúmenes Lógicos

Otra tecnología de almacenamiento avanzada es administración de volúmenes lógicos o logical volume management (LVM). LVM hace posible tratar a los dispositivos físicos de almacenamiento masivo como bloques de construcción a bajo nivel en los que se construyen diferentes configuraciones de almacenamiento. Las capacidades exactas varían de acuerdo a la implementación específica, pero pueden incluir la agrupación del almacenamiento físico, redimensionamiento de volúmenes lógicos y la migración de datos.

5.6.3.1. Agrupamiento de almacenamiento físico

Aunque los nombres dados a esta capacidad pueden variar, la agrupación del almacenamiento físico es la base para todas las implementaciones de LVM. Como su nombre lo implica, los dispositivos físicos de almacenamiento masivo se pueden agrupar de forma tal para crear uno o más dispositivos lógicos de almacenamiento. Los dispositivos lógicos de almacenamiento masivo (o volúmenes lógicos) pueden ser más grandes en capacidad que cualquiera de los dispositivos físicos de almacenamiento subyacentes.

Por ejemplo, dadas dos unidades de 100GB, se puede crear un volumen lógico de 200GB. Sin embargo, también se pueden crear un volumen lógico de 150GB y otro de 50GB. Es posible cualquier combinación de volúmenes lógicos igual o menor que la capacidad total (en nuestro ejemplo 200GB). Las posibilidades están limitadas solamente a las necesidades de su organización.

Esto hace posible que un administrador de sistemas trate a todo el almacenamiento como un sólo parque de recursos de almacenamiento, disponible para ser utilizado en cualquier cantidad. Además, posteriormente se pueden añadir unidades a ese parque, haciéndo un proceso directo el mantenerse al día con las demandas de almacenamiento de sus usuarios.

5.6.3.2. Redimensionamiento de volúmenes lógicos

La característica que la mayoría de los administradores de sistemas aprecian más sobre LVM es su habilidad para dirigir fácilmente el almacenamiento donde se necesite. En una configuración de sistemas no LVM, el quedarse sin espacio significa - en el mejor de los casos - mover archivos desde un dispositivo lleno a uno con espacio disponible. A menudo esto significa la reconfiguración de sus dispositivos de almacenamiento masivo; una tarea que se debe llevar a cabo después del horario de oficina.

Sin embargo, LVM hace posible incrementar fácilmente el tamaño de un volumen lógico. Asuma por un momento que nuestro parque de almacenamiento de 200GB fue utilizado para crear un volumen lógico de 150GB, dejando el resto de 50GB en reserva. Si el volumen lógico de 150GB se llena, LVM permite incrementar su tamaño (digamos por 10GB) sin ninguna reconfiguración física. Dependiendo del entorno de su sistema operativo, se puede hacer esto dinámicamente o quizás requiera una pequeña cantidad de tiempo fuera de servicio para llevar a cabo el redimensionamiento.

5.6.3.3. Migración de datos

La mayoría de los administradores con experiencia estarían impresionados de las capacidades de LVM, pero también se preguntarían:

¿Qué pasa si uno de los discos que forman parte del volumen lógico comienza a fallar?

Las buenas noticias es que la mayoría de las implementaciones LVM incluyen la habilidad de migrar datos fuera de una unidad física particular. Para que esto funcione, debe existir suficiente capacidad para absorber la pérdida de la unidad fallida. Una vez que se termine la migración, se puede reemplazar la unidad que dejó de funcionar y añadirla nuevamente en el parque de almacenamiento disponible.


5.6.3.4. Con LVM, ¿Por qué utilizar RAID?

Dado que LVM tiene algunas funcionalidades similares a RAID (la habilidad de reemplazar dinámicamente unidades fallidas, por ejemplo) y algunas funcionalidades proporcionan capacidades que no se pueden comparar con la mayoría de las implementaciones RAID (tales como la habilidad de añadir dinámicamente más almacenamiento a un parque central de almacenamiento), mucha gente se pregunta si ya RAID no es tan importante.

Nada puede estar más lejos de la realidad. RAID y LVM son tecnologías complementarias que se pueden usar en conjunto (de una forma similar a los niveles RAID anidados), haciendo posible obtener lo mejor de los dos mundos.

5.7. La administración del almacenamiento día a día

Los administradores del sistema deben prestar atención al almacenamiento en el curso de su rutina diaria. Hay varios problemas que se deben tener en cuenta:

• Monitorizar el espacio libre

• Problemas con cuotas de disco

• Problemas relacionados a archivos

• Problemas relacionados a directorios

• Problemas relacionados a respaldos

• Problemas relacionados con el rendimiento

• Añadir/Eliminar almacenamiento

Las secciones siguientes discuten cada uno de estos problemas con más detalles.

5.7.1. Monitorizar el espacio libre

Asegurarse de que se dispone de suficiente espacio para el almacenamiento debería estar en el tope de la lista de tareas diarias de un administrador de sistemas. La razón por la que la verificación frecuente de espacio disponible es tan importante es porque el espacio libre es muy dinámico; en un minuto puede haber más que suficiente espacio y al minuto siguiente casi nada.

En general, hay tres razones para espacio insuficiente en disco:

• Uso excesivo de parte del usuario

• Uso excesivo de una aplicación

• Crecimiento normal en uso

Estas razones se exploran en más detalles en las secciones siguientes.

5.7.1.1. Uso excesivo de parte de un usuario

Algunas personas son más ordenadas que otras. Unos estarían horrorizados de ver un poco de polvo sobre sus escritorios, mientras que para otros ni siquiera pensarían dos veces sobre la colección de cajas de pizza del año pasado que tienen apilada al lado del sofá. Es lo mismo con el almacenamiento:

• Algunas personas son muy frugales con su almacenamiento y nunca dejan archivos innecesarios por allí.


• Otras personas pareciera que nunca tienen tiempo de desechar archivos que ya no necesitan.

Muchas veces cuando un usuario es responsable de utilizar grandes cantidades de almacenamiento, es el segundo tipo de persona los que aparecen como responsables.

5.7.1.1.1. Manejo del uso excesivo de sus usuarios

Esta es un área en la que un administrador de sistemas necesita reunir toda la diplomacia y habilidades interpersonales que pueda reunir. A menudo las discusiones sobre espacio en disco se pueden volver emocionales, pues la gente ve las restricciones impuestas en el espacio en disco como medidas para hacer más difícil su trabajo (o imposible), que las restricciones son ridículamente pequeñas o que sencillamente no tienen tiempo para limpiar sus archivos.

El mejor administrador de sistemas debe tomar en cuenta muchos factores en una situación de este tipo. ¿Son las restricciones equitativas y razonables para el tipo de trabajo realizado por la persona? ¿La persona está utilizando su espacio disponible de la forma correcta? ¿Puede ayudar a la persona de alguna forma a reducir su uso en disco (creando un CD-ROM de respaldo con todos los correos electrónicos con más de un año de antigüedad, por ejemplo)? Su trabajo durante esta conversación es intentar descubrir si este es el caso, a la vez que se asegura que alguien que realmente no tiene necesidad de tanto espacio haga su trabajo de limpieza.

En cualquier caso, lo que hay que hacer es mantener la conversación a un nivel profesional. Trate de resolver los problemas del usuario de una forma profesional ("Entiendo que esté muy ocupado, pero todos en su departamento tienen la misma responsabilidad de no desperdiciar espacio, y su utilización promedio es la mitad de la suya.") a la vez que lleva la conversación hacia el punto. Asegurese de ofrecer asistencia si la falta de conocimiento/experiencia parece ser un problema.

Enfocar esta situación de una manera consciente pero firme es a menudo mucho mejor que utilizar su autoridad como administrador de sistemas para lograr un resultado. Por ejemplo, verá que con frecuencia se necesita llegar a un acuerdo entre el usuario y usted. Este compromiso puede tomar tres formas:

• Proporcionar espacio temporal

• Hacer respaldos de ficheros de archivos

• Abandonar

Quizás el usuario puede reducir su utilización si se le concede cierta cantidad de espacio temporal que pueda utilizar sin restricción. La gente a menudo aprovecha esta situación pues les permite trabajar sin preocuparse sobre el espacio hasta que lleguen a un punto lógico, y en ese momento hacer un poco de mantenimiento y determinar qué archivos en el almacenamiento temporal realmente necesitan y cuales no.

Atención

Si le presenta esta situación a un usuario, no caiga en la trampa de permitir que el espacio temporal se convierta en espacio permanente. Deje bien claro que el espacio que se le está ofreciendo es temporal y que no garantiza retención de datos; nunca se hacen respaldos de ningún tipo en espacio temporal.

De hecho, muchos administradores a menudo no aprecian este hecho, eliminando automáticamente cualquier archivo en almacenamiento temporal, que sea mayor que cierta fecha (por ejemplo, una semana).

Otras veces, el usuario puede tener muchos archivos que son obviamente viejos y que es poco probable que se necesite acceso contínuo a ellos. Asegúrese de que este es el caso. Algunas veces ciertos usuarios individuales son responsables de mantener datos en archivo; en tales circunstancias, usted


debería asistirlos en la tarea de proporcionarles múltiples respaldos que se traten de la misma forma que los respaldos de archivos desde su centro de datos.

Sin embargo, hay veces en que los datos tienen un valor dudoso. En tales casos, quizás le parezca que es mejor ofrecerles un respaldo especial para ellos. Usted hace una copia de seguridad de los datos y le entrega la media de respaldo al usuario, explicándole que ellos son responsables por su resguardo y que si alguna vez necesitan acceder a esos datos que le solicite a usted (o al personal de operaciones de su organización — lo que sea apropiado de acuerdo a su organización) para restaurarlos.

Hay unas cosas a tener en mente para que esto no se le devuelva de una forma negativa. Primero y principal es no incluir archivos que posiblemente necesite restaurar; no seleccione archivos que sean muy nuevos. Luego, asegurese de que usted es capaz de realizar una restauración si alguien se lo solicita. Esto significa que la media de respaldo debería ser de algún tipo que será utilizada por cierto tiempo en su centro de datos.

Sugerencia

Su selección de la media también debería tomar en cuenta aquellas tecnologías que pueden permitir al usuario manejar la restauración ellos mismos. Por ejemplo, aún cuando respaldar varios gigabytes en una media de CD-R es mucho más trabajo que ejecutar un sólo comando y montarlo en un cartucho de cinta de 20GB, considere el hecho de que el usuario podrá luego acceder fácilmente a su CD-R cuando lo desee — sin molestarlo a usted.

5.7.1.2. Uso excesivo de parte de una aplicación

Algunas veces una aplicación es responsable por uso excesivo. Las razones para esto pueden variar, pero pueden incluir:

• Mejoras en la funcionalidad de la aplicación que requieren mayor almacenamiento

• Un incremento en el número de usuarios usando la aplicación

• La aplicación falla en limpiar las cosas luego de su ejecución, dejando archivos temporales que ya no se necesitan en el disco

• La aplicación tiene problemas y el fallo que está causando esto utiliza más espacio del que debería

Su tarea es determinar cuáles de estas razones de la lista aplican a su situación. Tener presente el estado de las aplicaciones utilizadas en su centro de datos debería ayudarle a eliminar varias de estas razones, así como también su conocimiento de los hábitos de procesamiento de sus usuarios. Lo que queda por hacer es un poco de trabajo de detective para ver donde ha ido a parar el almacenamiento. Esto debería reducir el campo substancialmente.

En este punto debe tomar los pasos apropiados, bien sea la adición de almacenamiento para soportar la aplicación, ponerse en contacto con los desarrolladores de la aplicación para discutir sus características de manejo de archivos o escribir scripts para limpiar las cosas de la aplicación.

5.7.1.3. Crecimiento normal en uso

La mayoría de las organizaciones experimentan algún nivel de crecimiento a largo plazo. Debido a esto, es normal esperar que la utilización del almacenamiento se incremente a un ritmo similar. En casi todos los casos, la supervisión contínua puede revelar la tasa promedio de utilización del almacenamiento en su organización; esta tasa puede ser usada posteriormente para determinar el tiempo en el cual se debería obtener almacenamiento adicional antes de que su espacio libre se termine.


Si se encuentra en la posición de que repentinamente se le acaba el espacio libre debido a un crecimiento normal, entonces usted no ha estado haciendo su trabajo como debería ser.

Sin embargo, algunas veces pueden surgir repentinamente grandes demandas de espacio adicional. Quizás su organización se haya combinado con otra, necesitando cambios rápidos en la infraestructura de IT (y por lo tanto, almacenamiento). Un nuevo proyecto de alta prioridad puede haber nacido literalmente de la noche a la mañana. Cambios a una aplicación existente pueden producir un gran incremento en las necesidades de almacenamiento.

No importa cuál sea la razón, habrá ocasiones en que lo tomen por sorpresa. Para planear estas situaciones, trate de configurar su arquitectura de almacenamiento para un máximo de flexibilidad. El tener espacio de almacenamiento adicional a mano (si es posible) puede aliviar el impacto de estos eventos espontáneos.

5.7.2. Problemas de cuotas de usuarios

Muchas veces cuando la gente piensa sobre cuotas de disco es para usarlas de manera de forzar a los usuarios a que mantengan limpios sus directorios. Aunque hay sitios donde este puede ser el caso, también ayuda a ver el problema de espacio en disco desde otra perspectiva. ¿Qué hay de las aplicaciones que, por una razón o la otra, consumen demasiado espacio en disco? Se sabe de aplicaciones que fallan de una forma tal en que consumen todo el espacio disponible. En estos casos, las cuotas de disco le pueden ayudar a limitar el daño causado por tales aplicaciones erráticas, forzándolas a detenerse antes de consumir todo el espacio en el disco.

La parte más difícil de implementar y manejar cuotas de disco está relacionada con los límites mismos. ¿Cuál debería ser? Un enfoque simplístico sería dividir el espacio en disco por el número de usuarios y/o grupos que lo utilizan y utilizar el número resultante como la cuota por usuario. Por ejemplo, si el sistema tiene una unidad de disco de 100GB y 20 usuarios, cada usuario tendría una cuota de 5GB. De esta forma, cada usuario tendrá garantizado 5GB(aunque en este punto el disco estaría a un 100%).

Para aquellos sistemas operativos que lo soportan, las cuotas temporales se podrían configurar un poco más altas — digamos 7.5GB, dejando la la cuota permanente en 5GB. Esto tiene el beneficio de permitir a los usuarios consumir de forma permanente solamente el porcentage de disco que les corresponde, pero a la vez otorgando un poco de flexibilidad cuando el usuario alcanza (y excede) su límite. Cuando se utilicen cuotas de esta forma, usted en realidad está comprometiendo su disco más allá de su espacio disponible. La cuota temporal es 7.5GB. Si todos sus 20 usuarios exceden su cuota permanente al mismo tiempo e intenta acercarse a su cuota temporal, esos 100GB de disco deberían en realidad ser 150GB para poder permitir a todos alcanzar su cuota temporal al mismo tiempo.

No obstante, en práctica nadie excede su cuota permanente al mismo tiempo, haciendo que este sea un enfoque aceptable. Por supuesto, la selección de las cuotas permanentes y temporales dependen del administrador del sistema, pues cada sitio y comunidad de usuarios es diferente.

5.7.3. Problemas relacionados a archivos

Los administradores de sistemas a menudo tienen que tratar con problemas relacionados a los archivos. Estos problemas incluyen:

• Acceso a archivos

• Compartir archivos

5.7.3.1. Acceso a archivos

Los problemas relacionados con el acceso de archivos típicamente giran alrededor de un escenario un usuario que no puede acceder a un archivo al cual el cree que debería tener acceso.


A menudo este es el caso de usuario#1 que desea dar una copia del archivo al usuario#2. En la mayoría de las organizaciones, la habilidad de un usuario de acceder a los archivos de otro es estríctamente eliminada, lo que lleva a este problema.

Se pueden tomar tres enfoques:

• El usuario#1 hace los cambios necesarios para permitir que el usuario#2 acceda al archivo donde exista.

• Se crea un área de intercambio de archivos para tales propósitos; el usuario#1 coloca una copia del archivo allí, desde donde puede ser copiado posteriormente por el usuario#2.

• El usuario#1 utiliza el correo electrónico para darle una copia del archivo al usuario#2.

Hay un problema con este primer enfoque -dependiendo de cómo se otorgue el acceso, el usuario#2 puede tener acceso completo a todos los archivos del usuario#1. Peor, puede haberse hecho de una forma tal que todos los usuarios de su organización tienen acceso a los archivos del usuario#1. Peor aún, puede que no se revierta el cambio después que el usuario#2 ya no requiera el acceso, dejando a los archivos del usuario#1 permanentemente disponibles para los otros. Lamentablemente, cuando los usuarios están a cargo de este tipo de situación, la seguridad raramente es su mayor prioridad.

El segundo enfoque elimina el problema de hacer todos los archivos del usuario#1 accesibles a otros. Sin embargo, una vez que el archivo está en el área de intercambio, es legible (y dependiendo de los permisos, hasta quizás de puede modificar) por todos los otros usuarios. Este enfoque realza la posibilidad de que el área de intercambio de archivos se llene de archivos, pues a menudo los usuarios se olvidan de limpiar las cosas.

El tercer enfoque, aunque puede parecer una solución extraña, quizás sea la preferible de la mayoría de los casos. Con el advenimiento de protocolos de anexos de correo electrónico y programas de correo más inteligentes, el envio de todo tipo de archivos a través del correo electrónico es una operación a prueba de tontos, que no requiere implicar a un administrador de sistemas. Por supuesto, está la posibilidad de que un usuario trate de enviar por correo un archivo de bases de datos de 1GB a 150 personas en el departamento de finanzas, por lo tanto es prudente llevar a cabo un poco de educación para sus usuarios (y posiblemente colocar limitaciones en el tamaño de los archivos anexos). Sin embargo, ninguno de estos enfoques resuelve la situación en la que dos o más usuarios necesiten acceso saliente a un mismo archivo. En estos casos, se requieren otros métodos.

5.7.3.2. Compartir archivos

Cuando múltiples usuarios necesitan compartir una misma copia de un archivo, permitir el acceso mediante la modificación de los permisos de usuarios no es la mejor solución. Es preferible formalizar el estado compartido del archivo. Hay varias razones para esto:

• Los archivos compartidos desde el directorio de un usuario son vulnerables a desaparecer inesperadamente cuando el usuario deja la organización o hace algo tan sencillo como reorganizar sus archivos.

• Mantener el acceso compartido para más de uno o dos usuarios adicionales se vuelve difícil, lo que a largo plazo lleva al problema del trabajo innecesario requerido cada vez que los usuarios que se encuentran compartiendo cambian de responsabilidades.

Por lo tanto, la solución preferida es:

• Haga que el usuario original renuncie a la propiedad directa del archivo

• Crear un grupo que será el propietario del archivo

• Colocar el archivo en un directorio compartido con el grupo como dueño

• Hacer que todos los usuarios que necesiten acceder al archivo sean parte del grupo


Por supuesto este enfoque funcionará bien tanto con un archivo como con varios, y se puede utilizarpara implementar el almacenamiento compartido para grandes proyectos.

5.7.4. Añadir/Eliminar almacenamientoDebido a que la necesidad de espacio adicional nunca termina, el administrador de sistemas confrecuencia se encontrará en la situación de añadir espacio en disco y otras veces tendrá que eliminarunidades más viejas o pequeñas. Esta sección proporciona una descripción general del proceso básicopara añadir o remover almacenamiento.

Nota

En muchos sistemas operativos, los dispositivos de almacenamiento masivo son nombrados deacuerdo a su conexión física al sistema. Por lo tanto, añadir o eliminar dispositivos de almace-namiento masivo puede resultar en cambios inesperados en los nombres de los dispositivos. Cuandoagregue o extraiga almacenamiento, siempre asegurese de revisar (y actualizar, si es necesario) to-das las referencias a nombres de dispositivos utilizados por su sistema operativo.

5.7.4.1. Añadir almacenamientoEl proceso de añadir espacio de almacenamiento a un sistema computacional es relativamente directo.He aquí los pasos básicos:

1. Instalar el hardware

2. Particionar

3. Formatear la partición(es)

4. Actualizar la configuración del sistema

5. Modificar la planificación de los respaldos

Las secciones siguientes detallan cada paso.

5.7.4.1.1. Instalación del hardware

Antes de que se pueda hacer nada, el nuevo disco debe estar colocado y accesible. Aunque hay muchasconfiguraciones de hardware posibles, las secciones siguientes mencionan las dos situaciones máscomunes - añadir una unidad de disco ATA o SCSI. Aún con otras configuraciones, los pasos básicosque aquí se describen también se aplican.

Sugerencia

No importa qué tipo de hardware utilice, siempre debe considerar la carga que un nuevo disco añadeal subsistema de E/S de su computador. En general, debería tratar de distribuir la carga de E/S desu disco sobre todos los canales/buses disponibles. Desde un punto de vista de rendimiento, estoes mucho mejor que poner todas las unidades de disco en un canal y dejando otro vacío y ocioso.


5.7.4.1.1.1. Añadir discos duros ATA

Las unidades de disco ATA se utilizan principalmente en escritorios y sistemas servidores más pequeños. Casi todos los sistemas en estas clases tienen controladores ATA incorporados con múltiples canales ATA — normalmente dos o cuatro.

Cada canal puede soportar dos dispositivos — uno maestro y otro esclavo. Los dos dispositivos están conectados al canal con un solo cable. Por lo tanto, el primer paso es ver cuales canales tienen espacio disponible para una unidad adicional. Es posible una de las tres situaciones siguientes:

• Hay un canal solamente con un disco conectado a él

• Hay un canal sin unidad de disco conectada a el

• No hay espacio disponible

La primera situación es usualmente la más fácil, pues es muy probable que el cable que ya está en su lugar tenga un conector sin utilizar en el cual se puede conectar el nuevo disco duro. Sin embargo, si el cable solamente tiene dos conectores (uno para el canal y otro para el disco duro ya instalado), entonces es necesario reemplazar el cable existente con un modelo de cable de tres conectores.

Antes de instalar la nueva unidad de discos, asegurese de que los dos discos duros que están compartiendo el canal están correctamente configurados (uno como maestro y otro como esclavo).

La segunda situación es un poco más complicada, pues se debe obtener un cable para conectar un disco duro al canal. El nuevo disco puede ser configurado como maestro o esclavo (aunque tradicionalmente el primer disco en un canal es configurado normalmente como maestro).

En la tercera situación, no hay espacio disponible para un disco adicional. Entonces tiene que tomar una decisión. Usted:

• Compra una tarjeta controladora ATA y la instala

• Reemplaza uno de los discos instalados con uno nuevo más grande

Añadir una tarjeta controladora implica verificar la compatibilidad del hardware, la capacidad física y la compatibilidad del software. Básicamente, la tarjeta debe ser compatible con las ranuras del bus de su computador, debe existir una ranura abierta para ella y debe ser soportada por su sistema operativo. Reemplazar una unidad de disco instalada presenta un problema único: qué hacer con los datos en el disco? Existen algunos enfoques posibles:

• Escribir los datos a un dispositivo de respaldo y restaurarlos después de instalar el nuevo disco duro

• Utilizar su red para copiar los datos a otro sistema con espacio suficiente, restaurando los datos después de instalar el nuevo disco duro

• Utilizar el espacio ocupado físicamente por un tercer disco duro mediante:

1. La eliminación temporal del tercer disco duro

2. Instalando temporalmente el nuevo disco en su lugar

3. Copiando los datos al nuevo disco

4. Eliminando el viejo disco duro

5. Reemplazándolo con el nuevo disco

6. Reinstalando el tercer dico duro que ha sido temporalmente eliminado

• Instalar temporalmente la unidad de disco original y el nuevo disco en otro computador, copiar los datos al nuevo disco y luego instalar el nuevo disco en el computador original


Como puede ver, algunas veces se debe invertir un poco de esfuerzo para pasar los datos (y el nuevo hardware) a donde tienen que ir.

5.7.4.1.1.2. Añadir unidades de disco SCSI

Las unidades SCSI normalmente se utilizan en estaciones de trabajo superiores y sistemas servidores. A diferencia de los sistemas basados en ATA, los sistemas SCSI pueden o no tener controladores SCSI incorporados; algunos lo tienen, mientras que otros utilizan una tarjeta controladora SCSI separada.

Las capacidades de los controladores SCSI (bien sean incorporadas o no) también varían enormemente. Puede venir con un bus SCSI angosto o amplio. La velocidad del bus puede ser normal, rápida, ultra, ultra2 o ultra160.

Si estos términos no le parecen familiares (se discutieron brevemente en la Sección 5.3.2.2), debe determinar las capacidades de la configuración de su hardware y seleccionar un nuevo disco que sea apropiado. La mejor fuente para esta información sería la documentación de su sistema y/o su adaptador SCSI.

Debe determinar cuántos buses SCSI están disponibles en su sistema y cuáles de estos tienen espacio disponible para una nueva unidad de disco. El número de dispositivos soportados por un bus SCSI varía de acuerdo al ancho del bus:

• Bus SCSI delgado (8-bit) — 7 dispositivos (más controlador)

• Bus SCSI ancho (16-bit) — 15 dispositivos (más controlador)

El primer paso es ver cuáles buses tienen espacio disponible para una unidad de disco adicional. Es posible una de las tres situaciones siguientes:

• Hay un bus con menos del máximo número de unidades de disco conectadas a el

• Hay un bus sin unidades de disco conectadas

• No hay espacio disponible en ningún bus

La primera situación usualmente es la más fácil, pues es probable que el cable tenga un conector sin utilizar en el cual se podría conectar el nuevo disco. Sin embargo, si el cable no tiene un conector sin utilizar, es necesario reemplazar el cable existente con uno que tenga al menos un conector más.

La segunda situación es un poco más complicada, si no fuese por el cable que se debe obtener para que se pueda conectar una unidad de disco al bus.

Si no hay espacio para una unidad de disco adicional, debe tomar una decisión. Usted:

• Compra e instala una tarjeta controladora SCSI

• Reemplaza una de las unidades de disco instaladas por una nueva, más grande

Añadir una tarjeta controladora implica verificar la compatibilidad del hardware, la capacidad física y la compatibilidad del software. Básicamente, la tarjeta debe ser compatible con las ranuras del bus del computador, debe haber una ranura para ella y el sistema operativo la debe soportar.

Reemplazar una unidad de disco instalada representa un problema único: ¿qué hacer con los datos en el disco? Existen algunas soluciones para esto:

• Escribir los datos a un dispositivo de respaldo y restaurarlos después de instalar la nueva unidad de disco

• Utilizar su red para copiar los datos a otro sistema con espacio libre suficiente y restaurarlos después de instalar la nueva unidad de disco

• Utilizar el espacio ocupado físicamente por un tercer disco duro mediante:


1. La eliminación temporal del tercer disco duro

2. Instalando temporalmente el nuevo disco en su lugar

3. Copiando los datos al nuevo disco

4. Eliminando el viejo disco duro

5. Reemplazándolo con el nuevo disco

6. Reinstalando el tercer dico duro que ha sido temporalmente eliminado

• Instalar temporalmente la unidad de disco original y el nuevo disco en otro computador, copiar los datos al nuevo disco y luego instalar el nuevo disco en el computador original

Una vez que tenga un conector disponible en el que conectar la nueva unidad de disco, debe asegurarse de que el ID de su SCSI está configurado correctamente. Para hacer esto, debe saber qué están usando todos los otros dispositivos en el bus (incluyendo el controlador) para sus IDs SCSI. La forma más fácil de hacer esto es acceder al BIOS del controlador SCSI. Esto normalmente se hace presionando una secuencia de teclas específicas durante la secuencia de inicio del sistema. Puede entonces ver la configuración de la controladora SCSI, junto con todos los dispositivos conectados a sus buses.

Luego, debe considerar la terminación de los buses. Cuando se añade una nueva unidad de disco, la regla es bien directa — si el nuevo disco es el último (o el único) dispositivo en el bus, debe tener la terminación activada. De lo contrario, se debe desactivar la terminación.

En este punto, puede pasar al siguiente paso en el proceso — particionar su nueva unidad de disco.

5.7.4.1.2. Particionar

Una vez instalado el disco, es hora de crear una o más particiones para colocar el espacio disponible a su sistema operativo. Aunque las herramientas varían dependiendo del sistema operativo, los pasos básicos son los mismos:

1. Seleccione la nueva unidad de disco

2. Revise la tabla de particiones de la unidad de discos actual, para asegurarse de que la unidad de disco a particionarse es, en verdad, la correcta

3. Borre cualquier partición no deseada que pueda estar presente en su nueva unidad de disco

4. Cree la(s) nueva(s) partición(es), asegurandose de especificar el tamaño deseado y el tipo de partición

5. Guarde sus cambios y salga del programa de particionamiento

Atención

Cuando particione un nuevo disco, es vital que esté seguro de que la unidad que piensa particionar es la correcta. De lo contrario, puede inconscientemente particionar una unidad que ya está en uso, lo que resultaría en la pérdida de los datos.

También verifique que ha decidido el mejor tamaño para su partición. Siempre tome este punto seriamente, pues cambiarlo más adelante es mucho más difícil que tomarse un poco de tiempo ahora en pensar las cosas.


5.7.4.1.3. Formatear la partición

En este punto, la nueva unidad de disco tiene una o más particiones creadas. Sin embargo, antes de que el espacio contenido dentro de esas particiones se pueda utilizar, se deben formatear las particiones. Al formatearlas, estará seleccionando un sistema de archivos específico a utilizar dentro de cada partición. Como tal, este es un momento crucial en la vida de una unidad de disco; las selecciones que haga ahora no se pueden cambiar después sin pasar por una buena cantidad de trabajo.

El proceso actual de formatear la partición se hace ejecutando un programa de utilidades; los pasos relacionados en esto varían de acuerdo al sistema operativo. Una vez que se termine el formateo, la unidad de disco estaráconfigurada correctamente para su uso.

Antes de continuar, es mejor volver a verificar su trabajo accediendo a la partición y asegurándose de que todo está en orden.

5.7.4.1.4. Actualizar la configuración del sistema

Si su sistema operativo requiere cualquier cambio en la configuración para utilizar el nuevo almacenamiento que agregó, ahora es el momento de efectuar esos cambios necesarios.

En este punto puede estar relativamente seguro de que el sistema operativo está configurado correctamente para colocar el nuevo almacenamiento accesible cada vez que el sistema arranca (aunque si se puede dar el lujo de reiniciar, valdría la pena hacerlo — simplemente para estar seguros).

Las próximas secciones exploran uno de los pasos más comunmente olvidados en el proceso de añadir nuevo almacenamiento.

5.7.4.1.5. Modificar la planificación de los respaldos

Asumiendo que el nuevo almacenamiento se está usando para guardar datos que vale la pena conservar, este es el momento de hacer los cambios necesarios a sus procedimientos de respaldo y asegurarse de que el nuevo almacenamiento, de hecho, está siendo respaldado. La naturaleza exacta de lo que debe hacer depende de la forma en que se realizan los respaldos en su sistema. Sin embargo, he aquí algunos puntos a tener en mente mientras se hacen los cambios necesarios.

• Considere cuál debería ser la frecuencia de respaldos óptima

• Determine el estilo de respaldo más apropiado (respaldos completos, completos con incrementos, diferenciales, etc.)

• Considere el impacto del almacenamiento adicional en su media de respaldo, particularmente a medida que se va llenando

• Juzgue si el respaldo adicional podría causar que los respaldos demoren demasiado y comiencen a utilizar tiempo fuera de la ventana de tiempo asignada para el respaldo

• Asegúrese de que estos cambios sean comunicados a las personas que necesitan saber (otros administradores de sistema, personal operativo, etc.)

Una vez que se haga todo esto, su nuevo almacenamiento está listo para ser utilizado.

5.7.4.2. Eliminar Almacenamiento

Eliminar espacio en disco desde un sistema es directo, con la mayoría de los pasos siendo similares a la secuencia de instalación (excepto, por supuesto a la inversa):

1. Coloque calquier dato a guardar fuera del disco


2. Modifique la planificación del respaldo para que no se continúe respaldando esa unidad de disco

3. Actualice la configuración del sistema

4. Borre los contenidos de la unidad de disco

5. Extraiga la unidad de disco

Como puede ver, comparado con el proceso de instalación, hay unos pocos pasos adicionales a tomar. Estos pasos se discuten en las secciones siguientes.

5.7.4.2.1. Mover los datos fuera del disco

Si existen datos en la unidad de disco que se deben guardar, lo primero que hay que hacer es determinar dónde deben ir estos datos. Esta decisión depende principalmente en lo que se hará con los datos. Por ejemplo, si los datos ya no se utilizan actívamente, entoces se deberían archivar, probablemente de la misma forma que sus respaldos de sistemas. Esto significa que ahora es el momento para considerar los períodos de retención apropiados para este respaldo final.

Sugerencia

Tenga en cuenta que, además de cualquier pauta de retención de datos que su organización pueda tener, probablemente también existan ciertos requerimientos legales para mantener los datos por cierto período de tiempo. Por lo tanto, asegúrese de consultar con el departamento que haya sido responsable por los datos mientras estos se encontraban en uso; ellos deberían saber cuál es el período de retención adecuado.

Por otro lado, si todavía los datos están siendo utilizados, entonces se deberían dejar en el sistema más apropiado para su uso. Por supuesto, si este es el caso, quizás sería más fácil mover los datos reinstalando la unidad de disco en el nuevo sistema. Si hace esto, debería efectuar un respaldo completo de los datos antes — una persona puede dejar caer un disco duro lleno de datos valiosos (y en consecuencia, perdiendo todo) haciendo algo tan simple como caminando a través del centro de datos.

5.7.4.2.2. Borre los contenidos de la unidad de disco

No importa si la unidad de disco tiene datos valiosos o no, siempre es una buena idea borrar los contenidos del disco antes de reasignar o abandonar el control del mismo. Mientras que la razón obvia para hacer esto es asegurarse de no dejar información confidencial en el disco, también es una buena idea verificar la salud del disco haciendo una prueba de lectura-escritura para bloques dañados en el disco completo.

Importante

Muchas compañías (y agencias del gobierno) tienen métodos específicos de borrar datos desde sus unidades de disco y otras medias de almacenamiento. Siempre debería asegurarse de que entiende y sigue estos requerimientos; en muchos casos hay consecuencias legales si no las sigue. El ejemplo de arriba no se debería de considerar el método perfecto para limpiar una unidad de disco.

Además, las organizaciones que trabajan con datos clasificados quizás tengan procedimientos legales particulares con respecto a la disposición final de la unidad (tal como la destrucción física de la unidad). En estos casos, el departamento de seguridad de su organización debería de indicarle las pautas en esta materia.


5.8. Un comentario sobre Respaldos

Una de los factores más importantes cuando se considera el almacenamiento de discos es sobre los respaldos. Esta materia no se cubre aquí puesto que hay una sección detallada (Sección 8.2) dedicada a los respaldos.

5.9. Documentación específica a Red Hat Enterprise Linux

Dependiendo de su experiencia pasada en administración de sistemas, el manejo del almacenamiento bajo Red Hat Enterprise Linux es bien sea muy común o totalmente extraño. Esta sección discute aspectos de la administración del almacenamiento específica a Red Hat Enterprise Linux.

5.9.1. Convenciones de nombres de dispositivos

Como todos los sistemas operativos tipo Linux, Red Hat Enterprise Linux utiliza archivos de dispositivos para acceder a todo el hardware (incluyendo unidades de disco). No obstante, las convenciones de nombres para los dispositivos de almacenamiento conectados varían de alguna forma entre varias implementaciones de Linux o similares a Linux. He aquí como los archivos de dispositivos son nombrados bajo Red Hat Enterprise Linux.

Nota

Los nombres de dispositivos bajo Red Hat Enterprise Linux se determinan en el momento del arranque.

Por lo tanto, los cambios hechos a la configuración del hardware pueden resultar en cambios en los nombres de dispositivos cuando el sistema arranca. Debido a esto, pueden surgir problemas si no se actualizan apropiadamente en la configuración del sistema las referencias a un nombre de dispositivo.

5.9.1.1. Archivos de dispositivos

Bajo Red Hat Enterprise Linux, los archivos de dispositivos para las unidades de disco aparecen en el directorio /dev/. El formato para cada nombre de archivo depende de muchos aspectos del hardware actual y de cómo se ha configurado. Los puntos importantes son como sigue:

• Tipo de dispositivo

• Unidad

• Partición

5.9.1.1.1. Tipo de dispositivo

Las primeras dos letras del nombre de archivo de un dispositivo se refieren al tipo específico del dispositivo. Para las unidades de disco, hay dos tipos de dispositivos que son los más comunes:

• sd — El dispositivo está basado en SCSI

• hd — El dispositivo está basado en ATA

Se puede encontrar más información sobre ATA y SCSI en la Sección 5.3.2.


5.9.1.1.2. Unidad

Siguiendo las dos letras para el tipo de dispositivo están una o dos letras que denotan la unidad específica. El designador de la unidad comienza con "a"para la primera unidad, "b" para la segunda, y así sucesivamente. Por lo tanto, el primer disco duro en su sistema aparecerá como hda o sda.

Sugerencia

La habilidad de SCSI de direccionar grandes números de dispositivos necesitaba la adición de un segundo carácter de unidad para soportar sistemas con más de 26 dispositivos SCSI conectados. Por lo tanto, los primeros 26 discos duros SCSI en un sistema serían llamados sda hasta sdz, los próximos 26 se llamarán sdaa hasta sdaz y así sucesivamente.

5.9.1.1.3. Partición

La parte final del nombre de dispositivo es un número que representa una partición específica en el dispositivo, comenzando con "1". El número puede ser de uno o dos dígitos de largo, dependiendo del número de particiones escritas en el dispositivo específico. Una vez que se conoce el formato para los nombres de dispositivos, es fácil entender a cual se refiere cada uno. He aquí algunos ejemplos:

• /dev/hda1 — La primera partición en la primera unidad ATA

• /dev/sdb12 — La doceava partición en la segunda unidad SCSI

• /dev/sdad4 — La cuarta partición en la trigésima unidad SCSI

5.9.1.1.4. Accesos completos a dispositivos

Hay situaciones en las que es necesario acceder al dispositivo completo y no simplemente una partición. Esto normalmente se hace cuando el dispositivo no está particionado o no soporta particiones estándar (tales como una unidad de CD-ROM). En tales casos, se omite el número de la partición:

• /dev/hdc — El tercer dispositivo ATA completo

• /dev/sdb — El segundo dispositivo SCSI completo

Sin embargo, la mayoría de las unidades de disco utilizan particiones (se puede encontrar más información sobre el particionamiento bajo Red Hat Enterprise Linux en la Sección 5.9.6.1).

5.9.1.2. Alternativas a nombres de archivos de dispositivos

Debido a que añadir o remover dispositivos de almacenamiento masivo puede resultar en cambios a los nombres de archivos de dispositivos, hay un riesgo de que el almacenamiento no esté disponible cuando el sistema arranque. He aquí un ejemplo de la secuencia de eventos que llevan a este problema:

1. El administrador del sistema añade un nuevo controlador SCSI para que se puedan añadir dos nuevas unidades SCSI al sistema (el bus SCSI existente está completamente lleno)

2. Las unidades SCSI originales (incluyendo la primera unidad en el bus: /dev/sda) no se cambian de ninguna manera

3. Se reinicia el sistema


4. La unidad SCSI anteriormente conocida como /dev/sda ahora tiene un nuevo nombre, porque la primera unidad SCSI en el nuevo controlador es ahora /dev/sda

En teoría, esto suena como un problema terrible. Sin embargo, en práctica raramente lo es. Raramente es un problema por varias razones. Primero, las reconfiguraciones de hardware de este tipo no ocurren a menudo. Segundo, es probable que el administrador del sistema tenga programado un tiempo fuera de servicio para efectuar los cambios necesarios; los tiempos fuera de servicio se deben planear con gran cuidado para asegurarse de que no toman más tiempo del estipulado. Esta planificación tiene el beneficio adicional de traer a la superficie cualquier problema relacionado a cambios de nombres de dispositivos.

No obstante, algunas organizaciones y configuraciones de sistemas son más propensas a encontrarse con este problema. Las organizaciones que requieren reconfiguraciones frecuentes del almacenamiento para satisfacer sus necesidades, a menudo usan hardware que sea capaz de reconfigurarse sin necesitar tiempo fuera de servicio. Este tipo de hardware de conexión en caliente hace fácil añadir o eliminar almacenamiento.

5.9.1.2.1. Etiquetas de sistemas de archivos

Algunos sistemas de archivos (que se discuten con más detalles en la Sección 5.9.2) tienen la habilidad de almacenar una etiqueta — una cadena de carácteres que se puede utilizar para identificar unívocamente los datos que contiene el sistema de archivos. Las etiquetas se pueden utilizar cuando se monta el sistema de archivos, eliminando la necesidad de utilizar el nombre de dispositivo.

Las etiquetas de sistemas de archivos funcionan bien; sin embargo, estas deben ser únicas para el sistema. Si en algún momento existe más de un sistema de archivos con la misma etiqueta, quizás no pueda acceder al sistema de archivos. También tenga en consideración que las configuraciones del sistema que no utilizan sistemas de archivos (algunas bases de datos, por ejemplo) no pueden tomar aprovechar las etiquetas.

5.9.1.2.2. Uso de devlabel

El software devlabel intenta resolver el problema de nombres de dispositivos en una forma diferente que las etiquetas de sistemas de archivos. El software devlabel lo ejecuta Red Hat Enterprise Linux cada vez que el sistema reinicia (y cuando se inserta o extrae un dispositivo de conexión en caliente).

Cuando se ejecuta devlabel, este lee el archivo de configuración (/etc/sysconfig/devlabel) para obtener la lista de dispositivos de los que es responsable. Para cada dispositivo en la lista, hay un enlace simbólico (seleccionado por el administrador del sistema) y el UUID (Universal Unique IDentifier) del dispositivo.

El comando devlabel se asegura de que el enlace simbólico siempre se refiere al dispositivo original especificado — aún si ese nombre de dispositivo ha cambiado. De esta forma, un administrador de sistemas puede configurar un sistema para que se refiera a /dev/projdisk en vez de a /dev/sda12, por ejemplo.

Debido a que el UUID se obtiene directament a partir del dispositivo, devlabel solamente debe buscar en el sistema por el UUID correspondiente y actualizar el enlace simbólico como sea apropiado.

Para más información sobre devlabel, consulte el Manual de administración del sistema de Red Hat Enterprise Linux.

5.9.2. Conceptos básicos de sistemas de archivos

Red Hat Enterprise Linux incluye soporte para muchos sistemas de archivos populares, haciendo posible acceder fácilmente a los sistemas de archivos de otros sistemas operativos.


Esto es particularmente útil en un escenario de arranque dual y cuando se migren archivos desde un sistema operativo a otro.

Los sistemas de archivos soportados incluyen (pero no se limitan a):

• EXT2

• EXT3

• NFS

• ISO 9660

• MSDOS

• VFAT

Las secciones siguientes exploran en más detalles los sistemas de archivos más populares.

5.9.2.1. EXT2

Hasta no hace mucho tiempo atrás, el sistema de archivos ext2 era el estándar para Linux. Como tal, ha recibido pruebas extensivas y se considera uno de los sistemas de archivos más robustos de hoy.

Sin embargo, no existe un sistema de archivo perfecto y ext2 no es la excepción. Un problema informado con frecuencia es que el sistema de archivos ext2 debe pasar por una inspección de integridad larga si el sistema fue apagado de forma repentina. Aunque este requerimiento no es único a ext2, la popularidad de ext2, combinada con el advenimiento de los discos más grandes, implica que las verificaciones de integridad estaban tomando más y más tiempo. Era necesario hacer algo.

La próxima sección describe el enfoque tomado para resolver este problema bajo Red Hat Enterprise Linux.

5.9.2.2. EXT3

El sistema de archivos ext3 se construye sobre ext2 añadiendo las capacidades de journaling o de mantener un "diario" o journal al código base de ext2 ya evaluado. Como un sistema de archivos con journaling, ext3 siempre mantiene el sistema de archivos en un estado consistente, eliminando la necesidad de las largas verificaciones de integridad.

Esto se logra escribiendo todos los cambios al sistema de archivos a un diario en disco, el cual es vaciado regularmente. Después de un evento inesperado del sistema (tal como una falla de poder o una caída del sistema), la única operación que se necesita hacer antes de colocar el sistema de archivos disponible, es procesar los contenidos del diario; en la mayoría de los casos esto toma aproximadamente un segundo.

Debido a que el formato en disco de ext3 está basado en ext2, es posible acceder a un sistema de archivos ext3 en cualquier sistema capaz de leer y escribir sistemas ext2 (sin el beneficio de journaling). Esto puede ser un gran beneficio en organizaciones donde algunos sistemas están usando ext3 y algunos todavía utilizan ext2.

5.9.2.3. ISO 9660

En 1987, la International Organization for Standardization (conocida como ISO) lanzó el estándar 9660. ISO 9660 define cómo se representan los archivos en los CD-ROMs. Los administradores de sistemas Red Hat Enterprise Linux probablemente verán datos formateados para ISO 9660 en dos lugares:

• CD-ROMs


• Los archivos (usualmente llamados imágenes ISO) conteniendo sistemas de archivos completos ISO 9660, supuestamente están para ser escritos en una media de CD-R o de CD-RW.

El estándar básico ISO 9660 es más bien limitado en funcionalidad, especialmente cuando se compara con sistemas de archivos más modernos. Los nombres de archivos deben ser de un máximo de ocho carácteres de largo y una extensión de no más de tres caracteres. Sin embargo, hay varias extensiones al estándar que se han vuelto populares a través de los años, entre ellas:

• Rock Ridge — Utiliza algunos campos indefinidos en ISO 9660 para proporcionar soporte a funcionalidades tales como nombres de archivos largos con combinaciones de mayúsculas y minúsculas, enlaces simbólicos y directorios anidados (en otras palabras, directorios que pueden contener a su vez otros directorios)

• Joliet — Una extensión del estándar ISO 9660, desarrollado por Microsoft para permitir que los CD-ROMs contengan nombres de archivos largos, usando el conjunto de carácteres Unicode

Red Hat Enterprise Linux puede interpretar correctamente los sistemas de archivos ISO 9660 usando extensiones Rock Ridge así como tambiénJoliet.

5.9.2.4. MSDOS

Red Hat Enterprise Linux también soporta sistemas de archivos de otros sistemas operativos. Como el nombre lo implica, el sistema operativo original que soporta msdos fue Microsoft’s MS-DOS®. Como en MS-DOS, un sistema Red Hat Enterprise Linux accediendo a un sistema de archivos msdos está limitado a nombres 8.3. De la misma manera, otros atributos de archivos tales como permisos y propiedad de archivos, no se pueden cambiar. Sin embargo, desde el punto de vista de intercambio de archivos, msdos es más que suficiente para hacer el trabajo.

5.9.2.5. VFAT

El sistema de archivos vfat primero fue utilizado por el sistema operativo Microsoft’s Windows® 95. Como una mejora sobre el sistema de archivos msdos, los nombres de archivos en un sistema vfat pueden ser más largos que 8.3. No obstante, los permisos y propiedad tampoco se pueden modificar.

5.9.3. Montaje de Sistemas de Archivos

Para acceder cualquier sistema de archivos, primero es necesario montarlo (mount). Al montar un sistema de archivos, usted dirige Red Hat Enterprise Linux para que coloque una partición (en un dispositivo específico) disponible al sistema. De la misma manera, cuando ya no se necesita o desea el acceso a un sistema de archivos particular, es necesario desmontarlo (umount).

Para montar cualquier sistema de archivos, se deben especificar dos piezas de información:

• Una forma de identificar unívocamente el disco deseado y la partición, tal como un nombre de archivo de dispositivo, una etiqueta de sistema de archivo o un enlace simbólico manejado por devlabel.

• Un directorio bajo el cual se colocará disponible el sistema de archivos montado (conocido como un punto de montaje)

Las secciones siguientes discuten los puntos de montaje con más detalles.


5.9.3.1. Puntos de montaje

A menos que esté acostumbrado a los sistemas operativos Linux (o parecido a Linux), el concepto de un punto de montaje puede parecer un poco extraño al principio. Sin embargo, es uno de los métodos más poderosos y flexibles desarrollados para manejar sistemas de archivos. Con muchos otros sistemas operativos, una especificación completa de archivos incluye el nombre del archivo, alguna forma de identificar el directorio específico en el cual reside el archivo, y una forma de identificar el dispositivo físico en el cual se encuentra el archivo.

Con Red Hat Enterprise Linux, se utiliza un enfoque ligeramente diferente. Como con otros sistemas operativos, una especificación completa de archivos incluye su nombre y el directorio en que este reside. Sin embargo, no se especifica el dispositivo.

La razón para este problema aparente es el punto de montaje. En otros sistemas operativos, hay una jerarquía de directorios para cada partición. Sin embargo, en los sistemas tipo Linux, solamente hay una jerarquía de directorios global al sistema y esta simple jerarquía puede abarcar múltiples particiones. La clave aquí es el punto de montaje. Cuando se monta un sistema de archivos, ese sistema de archivos se coloca disponible como un conjunto de subdirectorios bajo el punto de montaje especificado.

Este problema aparente es en realidad una fortaleza. Significa que es posible la expansión consistente de un sistema de archivos Linux, con cada directorio siendo capaz de actuar como un punto de montaje para espacio adicional.

Como ejemplo, asuma un sistema Red Hat Enterprise Linux conteniendo un directorio foo en su directorio raíz; la ruta completa al directorio sería /foo/. Luego, asuma que este sistema tiene una partición que se debe montar y que el punto de montaje de la partición es /foo/. Si la partición tiene un archivo con el nombre de bar.txt en el nivel superior del directorio, después de montar la partición podrá acceder al archivo con la especificación completa de archivos que sigue:

/foo/bar.txt

En otras palabras, una vez que la partición ha sido montada, cualquier archivo que sea leído o escrito en cualquier lugar bajo el directorio /foo/, será leído o escrito en esa partición.

Un punto de montaje utilizado a menudo en muchos sistemas Red Hat Enterprise Linux es /home/ — esto es porque los directorios de conexión para todas las cuentas de usuarios normalmente se ubican bajo /home/. Si se utiliza /home/ como punto de montaje, todos los archivos de usuarios se escriben a una partición dedicada y no llenaran el sistema de archivos del sistema operativo.

Sugerencia

Puesto que un punto de montaje es simplemente un directorio normal, es posible escribir archivos a un directorio que luego será utilizado como un punto de montaje. Si esto ocurre, ¿qué pasa con los archivos que estaban en ese directorio originalmente?

Mientras la partición esté montada en el directorio, los archivos no estarán accesibles (el sistema de archivos montado aparecerá en lugar de los contenidos del directorio). Sin embargo, los archivos no sufrirán daño alguno y se podrán acceder después de desmontar la partición.

5.9.3.2. Mostrar lo que está montado

Además de montar y desmontar espacio en disco, también es posible ver lo que está montado. Hay varias formas de hacer esto:

• Visualizar /etc/mtab


• Visualizar /proc/mounts

• Ejecutar el comando df

5.9.3.2.1. Visualizar /etc/mtab

El archivo /etc/mtab es un archivo normal actualizado por el programa mount cada vez que se montan o desmontan sistemas de archivos. He aquí una muestra de /etc/mtab:

/dev/sda3 / ext3 rw 0 0none /proc proc rw 0 0usbdevfs /proc/bus/usb usbdevfs rw 0 0/dev/sda1 /boot ext3 rw 0 0none /dev/pts devpts rw,gid=5,mode=620 0 0/dev/sda4 /home ext3 rw 0 0none /dev/shm tmpfs rw 0 0none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0

Nota

El archivo /etc/mtab se utiliza para mostrar el estado de los sistemas de archivos montados actualmente. No se debería modificar manualmente.

Cada línea representa un sistema de archivos que está actualmente montado y contiene los campos siguientes (de izquierda a derecha):

• La especificación del dispositivo

• El punto de montaje

• El tipo de sistema de archivos

• Si el archivo está montado como de sólo lectura (ro) o de sólo escritura (rw), junto con cualquier otra opción de montaje

• Dos campos sin utilizar llenos de ceros (para la compatibilidad con /etc/fstab11)

5.9.3.2.2. Visualizar /proc/mounts

El archivo /proc/mounts es parte del sistema de archivos virtual proc. Igual que los otros sistemas de archivos bajo /proc/, el "archivo" montado no existe en ninguna unidad de disco en su sistema Red Hat Enterprise Linux.

De hecho, ni siquiera es un archivo; en cambio es una representación del estatus del sistema que se coloca disponible (por el kernel de Linux) en la forma de archivo.

Usando el comando cat /proc/mounts, podemos ver el estatus de todos los sistemas de archivos montados:

rootfs / rootfs rw 0 0/dev/root / ext3 rw 0 0/proc /proc proc rw 0 0usbdevfs /proc/bus/usb usbdevfs rw 0 0/dev/sda1 /boot ext3 rw 0 0

11. Consulte la Sección 5.9.5 para más información.


none /dev/pts devpts rw 0 0/dev/sda4 /home ext3 rw 0 0none /dev/shm tmpfs rw 0 0none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0

Como podemos ver en el ejemplo de arriba, el formato de /proc/mounts es muy similar al de /etc/mtab. Hay un número de sistemas de archivos montados que no tienen nada que ver con las unidades de disco. Entre estas está el sistema de archivos /proc/ mismo (junto con otros dos sistemas de archivos montados bajo /proc/), pseudo-ttys y memoria compartida.

Aunque el formato realmente no es muy amigable al usuario, un vistazo a /proc/mounts es la mejor forma de estar 100% seguros de ver exactamente lo que está montado en su sistema Red Hat Enterprise Linux pues es el kernel el que está proporcionando la información. Otros métodos pueden, bajo extrañas circunstancias, ser inexactos.

Sin embargo, es probable que la mayor parte del tiempo usted utilice un comando con una salida más fácil (y útil) de leer. La próxima sección describe este comando.

5.9.3.2.3. Ejecución del comando df

Mientras que el uso de /etc/mtab o de /proc/mounts le permite conocer los sistemas de archivos que se encuentran montados actualmente, hace muy poco más allá de allí. La mayoría de las veces un administrador estará quizás más interesado en un aspecto particular de los sistemas de archivos montados actualmente — la cantidad de espacio disponible en ellos.

Para esto, podemos utilizar el comando df. He aquí una muestra de la salida de df:

Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda3 8428196 4280980 3719084 54% / /dev/sda1 124427 18815 99188 16% /boot /dev/sda4 8428196 4094232 3905832 52% /home none 644600 0 644600 0% /dev/shm

Hay muchas diferencias obvias entre /etc/mtab y /proc/mount que se ven inmediatamente:

• Se muestra un encabezado fácil de leer

• Con la excepción del sistema de archivos de la memoria compartida, solamente se muestran los sistemas de archivos basados en disco

• Tamaño total, espacio utilizado, espacio libre y el porcentage de uso en números

El último punto es probablemente el más importante puesto que eventualmente todo administrador de sistemas tendrá que enfrentarse a un sistema que se encuentra sin espacio disponible en disco. Con df es fácil ver donde reside el problema.

5.9.4. Almacenamiento accesible desde la red bajo Red Hat Enterprise Linux

Existen dos tecnologías principales utilizadas para la implementación del almacenamiento accesible desde la red bajo Red Hat Enterprise Linux:

• NFS

• SMB

Las secciones siguientes describen estas tecnologías.


5.9.4.1. NFS

Como su nombre lo implica, el Sistema de Archivos de Red o NFS(de Network File System) es un sistema de archivos al que se puede acceder a través de una conexión de red. Con otros sistemas de archivos, el dispositivo de almacenamiento debe estar directamente conectado al sistema local. Sin embargo, con NFS esto no es un requerimiento, haciendo posible una variedad de diferentes configuraciones, desde servidores de archivos centralizados hasta sistemas de computación sin discos.

Por otro lado, a diferencia de otros sistemas de archivos, NFS no dicta un formato específico en disco. En cambio, se basa en el soporte del sistema de archivos del sistema operativo del servidor para controlar la E/S a el/los disco(s) local(es). NFS luego coloca disponible el sistema de archivos a cualquier sistema operativo ejecutando un cliente compatible con NFS.

Aunque principalmente NFS es una tecnología Linux y UNIX, es importante mencionar que existen implementaciones de clientes NFS para otros sistemas operativos, haciendo NFS una técnica viable para compartir archivos con una variedad de plataformas.

El sistema de archivos que NFS coloca disponible a los clientes es controlado por el archivo de configuración /etc/exports. Para más información, consulte la página man de exports(5) y el Manual de administración del sistema de Red Hat Enterprise Linux.

5.9.4.2. SMB

SMB viene de Server Message Block y es el nombre para el protocolo de comunicación utilizado por varios sistemas operativos producidos por Microsoft por varios años. SMB hace posible compartir el almacenamiento a lo largo de la red. Las implementaciones de hoy día a menudo utilizan TCP/IP como el transporte subyacente; anteriormente era NetBEUI el transporte.

Red Hat Enterprise Linux soporta SMB a través del programa de servidor Samba. El Manual de administración del sistema de Red Hat Enterprise Linux incluye información sobre la configuración de Samba.

5.9.5. Montar sistemas de archivos automáticamente con /etc/fstab

Cuando se acaba de instalar un sistema Red Hat Enterprise Linux, todas las particiones de disco definidas y/o creadas durante la instalación son configuradas para montarse automáticamente cuando el sistema arranca. No obstante, ¿qué pasa cuando se añaden unidades de disco adicionales a un sistema después de efectuar la instalación? La respuesta es "nada" porque el sistema no fue configurado para montarlos automáticamente. Sin embargo, esto se puede cambiar fácilmente.

La respuesta recae en el archivo /etc/fstab. Este archivo es utilizado para controlar qué sistemas de archivos son montados cuando el sistema arranca, así como también para suministrar valores por defecto para otros sistemas de archivos que pueden ser montados manualmente de vez en cuando. He aquí una muestra del archivo /etc/fstab:

LABEL=/ / ext3 defaults 1 1 /dev/sda1 /boot ext3 defaults 1 2 /dev/cdrom /mnt/cdrom iso9660 noauto,owner,kudzu,ro 0 0 /dev/homedisk /home ext3 defaults 1 2 /dev/sda2 swap swap defaults 0 0

Cada línea representa un sistema de archivos y contiene los campos siguientes:

• El especificador del sistema de archivos — Para los sistemas de archivos basados en disco, bien sea un nombre de archivo de dispositivo (/dev/sda1), una especificación de etiqueta (LABEL=/) o un enlace simbólico manejado por devlabel (/dev/homedisk)


• Punto de montaje — Excepto para las particiones swap, este campo especifica el punto de montaje a utilizar cuando se monta el sistema de archivos (/boot)

• Tipo de sistema de archivos — El tipo de sistema de archivos presente en el dispositivo especificado (observe que se puede especificar auto para seleccionar la detección automática del sistema de archivos a montar, lo que es útil para la media removible tal como unidades de disquete)

• Opciones de montaje — Una lista de opciones separadas por comas que se puede utilizar para controlar el comportamiento de mount (noauto,owner,kudzu)

• Frecuencia de descarga — Si se utiliza la utilidad para respaldos dump, el número en este campo controla el manejo de dump del sistema de archivos especificado

• Orden de verificación del sistema de archivos — Controla el orden en que fsck verificará la integridad del sistema de archivos

5.9.6. Añadir/Eliminar almacenamiento

Mientras que la mayoría de los pasos necesarios para añadir o eliminar almacenamiento dependen más en el hardware del sistema que en el software, hay aspectos del procedimiento que son específicos a su entorno operativo. Esta sección explora los pasos necesarios para añadir o eliminar almacenamiento que son específicos a Red Hat Enterprise Linux.

5.9.6.1. Añadir almacenamiento

El proceso de añadir almacenamiento a un sistema Red Hat Enterprise Linux es relativamente directo. He aquí los pasos que son específicos a Red Hat Enterprise Linux:

• Particionar

• Formatear la partición(es)

• Actualizar /etc/fstab

Las secciones siguientes exploran cada paso con más detalles.

5.9.6.1.1. Particionar

Una vez instalado en disco duro, es hora de crear una o más particiones para hacer el espacio disponible a Red Hat Enterprise Linux.

Hay más de una forma de hacer esto:

• Usando el programa de línea de comandos fdisk

• Usando parted, otro programa utilitario de línea de comandos

Aunque las herramientas pueden ser diferentes, los pasos básicos son los mismos. En el ejemplo siguiente, se incluyen los comandos necesarios para efectuar estos pasos usando fdisk:

1. Seleccione la nueva unidad de disco (el nombre de la unidad se puede identificar siguiendo la convención de nombres descrita en la Sección 5.9.1). Usando fdisk, esto se hace incluyendo el nombre del dispositivo cuando arranca fdisk: fdisk /dev/hda

2. Revise la tabla de particiones de la unidad para verificar que la unidad a particionar es, en realidad, la correcta. En nuestro ejemplo, fdisk muestra la tabla de partición usando el comando p:Command (m for help): p


Disk /dev/hda: 255 heads, 63 sectors, 1244 cylinders Units = cylinders of 16065 * 512 bytes

Device Boot Start End Blocks Id System /dev/hda1 * 1 17 136521 83 Linux /dev/hda2 18 83 530145 82 Linux swap /dev/hda3 84 475 3148740 83 Linux /dev/hda4 476 1244 6176992+ 83 Linux

3. Borre cualquier partición no deseada que pueda existir en la nueva unidad de disco. Esto se hace usando el comando d en fdisk: Command (m for help): d Partition number (1-4): 1

El proceso se repetirá para todas las particiones no deseadas presentes el el disco.

4. Cree la(s) nueva(s) partición(es), asegurándose de especificar el tamaño deseado y el tipo de sistemas de archivos. Usando fdisk, esto es un proceso de dos pasos — primero, cree la partición (usando el comando n): Command (m for help): n Command action

e extended p primary partition (1-4)

p

Partition number (1-4): 1First cylinder (1-767): 1Last cylinder or +size or +sizeM or +sizeK: +512M

Segundo, configure el tipo de sistema de archivos (usando el comando t): Command (m for help): tPartition number (1-4): 1Hex code (type L to list codes): 82

El tipo de partición 82 representa una partición Linux swap.

5. Guarde sus cambios y salga del programa de particionamiento. Esto se hace en fdisk ejecutando w: Command (m for help): w

Atención

Cuando particione un nuevo disco, es vital que esté seguro de que la unidad que piensa particionar es la correcta. De lo contrario, puede inconscientemente particionar una unidad que ya está en uso, lo que resultaría en la pérdida de los datos.

También verifique que ha decidido el mejor tamaño para su partición. Siempre tome este punto seriamente, pues cambiarlo más adelante es mucho más difícil que tomarse un poco de tiempo ahora en pensar las cosas.


5.9.6.1.2. Formatear la partición

El formateo de particiones bajo Red Hat Enterprise Linux se hace usando el programa de utilidades mkfs. Sin embargo, mkfs en realidad no hace el trabajo de escribir la información específica del sistema de archivos en el disco; en cambio pasa el control a uno de los muchos programas que crean el sistema de archivos.

Este es el momento de observar la página man de mkfs. � fstype � para el sistema de archivos que ha seleccionado. Por ejemplo, vea la página man de mkfs.ext3 para revisar las opciones disponibles durante la creación de un sistema de archivos ext3. En general, los programas mkfs. � fstype �suministran valores por defecto razonables para la mayoría de las configuraciones; sin embargo, he aquí algunas de las opciones que los administradores de sistemas cambian más a menudo:

• Configuran una etiqueta de volumen para su uso posterior en /etc/fstab

• En discos duros muy grandes, configuran un porcentage más pequeño de espacio reservado para el super-usuario

• Configuran un tamaño de bloque no estándar y/o bytes para las configuraciones de inodos, que deben soportar tamaños de archivos muy grandes o muy pequeños

• Verifican por bloques dañados antes de formatear

Una vez creados los sistemas de archivos en todas las particiones apropiadas, la unidad de disco estará configurada adecuadamente para su uso.

Luego, siempre es bueno volver a verificar su trabajo manualmente montando la partición(es) y asegurándose de que está en orden. Una vez que todo está verificado, es el momento de configurar su sistema Red Hat Enterprise Linux para que monte automáticamente el nuevo sistema de archivos durante el arranque.

5.9.6.1.3. Actualizar /etc/fstab

Como se describió en la Sección 5.9.5, primero debe añadir las líneas necesarias a /etc/fstab para asegurarse de que se monte el nuevo sistema de archivos cuando arranque el sistema. Una vez actualizado /etc/fstab, pruebe su trabajo ejecutando un comando "incompleto" de mount, especificando solamente el dispositivo o punto de montaje. Algo similar a alguno de los comandos siguientes es suficiente:

mount /home mount /dev/hda3

(Reemplace /home or /dev/hda3 con el punto de montaje o dispositivo para su situación específica.)

Si la entrada correspondiente en /etc/fstab es correcta, mount obtiene la información faltante desde el archivo y completa la operación de montaje.

En este punto puede estar confiado de que /etc/fstab está configurado correctamente para montar automáticamente el nuevo almacenamiento cada vez que el sistema arranca (aunque si se puede permitir un reinicio rápido, no hace daño — simplemente para estar seguros).

5.9.6.2. Eliminar Almacenamiento

El proceso de eliminar almacenamiento desde un sistema Red Hat Enterprise Linux es relativamente directo. He aquí los pasos específicos para Red Hat Enterprise Linux:

• Elimine las particiones de disco desde /etc/fstab

• Desmonte las particiones activas del disco


• Borre los contenidos de la unidad de disco

Las secciones siguientes cubren estos tópicos en más detalles.

5.9.6.2.1. Elimine las particiones de disco desde /etc/fstab

Usando el editor de texto de su preferencia, elimine la(s) línea(s) correspondiente(s) a la(s) partición(es) de disco desde el archivo /etc/fstab. Puede identificar las líneas correctas por alguno de los métodos siguientes:

• Haciendo corresponder los puntos de montaje con los directorios en la segunda columna de /etc/fstab

• Haciendo corresponder el nombre del archivo de dispositivo con el nombre de archivo en la primera columna de /etc/fstab

Sugerencia

Asegúrese de ver líneas en /etc/fstab que identifican particiones swap en la unidad de disco a eliminar; se pueden dejar pasar por accidente.

5.9.6.2.2. Terminar el acceso con umount

Luego, se deben terminar todos los accesos. Para particiones con sistemas de archivos activos en ellas, esto se hace con el comando umount. Si una partición swap existe en el disco, se debe desactivar con el comando swapoff o se debe reiniciar el sistema.

Desmontar las particiones con el comando umount requiere que usted especifique el nombre de archivo de dispositivo, o el punto de montaje.

umount /dev/hda2 umount /home

Solamente se puede desmontar una partición si esta no se encuentra en uso. Si la partición no se puede desmontar mientras se encuentra en el nivel de ejecución normal, arranque en modo de rescate y elimine la entrada de la partición de /etc/fstab.

Cuando utilice swapoff para desactivar el swapping en una partición, debe especificar el nombre de archivo de dispositivo representando la partición swap:

swapoff /dev/hda4

Si no puede desactivar el swapping usando swapoff, arranque en modo de rescate y elimine la entrada de la partición desde /etc/fstab.

5.9.6.2.3. Borre los contenidos de la unidad de disco

Borrar los contenidos desde una unidad de disco bajo Red Hat Enterprise Linux es un procedimiento directo.

Después de desmontar todas las particiones del disco, ejecute el comando siguiente (conectado como root):


badblocks -ws � device-name �

Donde � device-name � representa el nombre del archivo de la unidad de disco que desea borrar, excluyendo el número de la partición. Por ejemplo, /dev/hdb para la segunda unidad ATA.

Se muestra la salida siguiente mientras se ejecuta badblocks:

Writing pattern 0xaaaaaaaa: done Reading and comparing: done Writing pattern 0x55555555: done Reading and comparing: done Writing pattern 0xffffffff: done Reading and comparing: done Writing pattern 0x00000000: done Reading and comparing: done

Tenga en mente que badblocks en realidad está escribiendo cuatro patrones de datos diferentes a cada bloque en la unidad de disco. Para las unidades grandes, este proceso puede tomar un largo tiempo — a menudo varias horas.

Importante

Muchas compañías (y agencias del gobierno) tienen métodos específicos de borrar datos desde sus unidades de disco y otras medias de almacenamiento. Siempre debería asegurarse de que entiende y sigue estos requerimientos; en muchos casos hay consecuencias legales si no las sigue. El ejemplo de arriba no se debería de considerar el método perfecto para limpiar una unidad de disco.

No obstante, es mucho más efectivo que utilizar el comando rm. Esto se debe a que cuando usted elimina un archivo usando rm solamente marca el archivo como borrado — no elimina los contenidos del archivo.

5.9.7. Implementación de Cuotas de Disco

Red Hat Enterprise Linux es capaz de llevar un seguimiento del espacio en disco en una base de por usuario y por grupo a través del uso de cuotas. Las secciones siguientes proporcionan una vista general de las funcionalidades presentes en las cuotas de disco bajo Red Hat Enterprise Linux.

5.9.7.1. Antecedentes de las Cuotas de Discos

Las cuotas de disco bajo Red Hat Enterprise Linux tiene las siguientes características:

• Implementación por sistemas de archivos

• Contabilidad de espacio por usuario

• Contabilidad de espacio por grupo

• Seguimiento del uso de bloques de disco

• Seguimiento de uso de inodes

• Límites rígidos

• Límites suaves

• Períodos de gracia


Las secciones siguientes describen cada característica con más detalles.

5.9.7.1.1. Implementación por sistema de archivo

Las cuotas de disco bajo Red Hat Enterprise Linux se pueden usar en una base por sistema de archivos. En otras palabras, las cuotas se pueden habilitar o inhabilitar para cada sistema de archivos individualmente.

Esto proporciona una gran flexibilidad para el administrador del sistema. Por ejemplo, si el directorio /home/ está en su propio sistema de archivos, se pueden activar las cuotas allí, haciendo cumplir un uso equitativo del espacio en disco entre todos los usuarios. Sin embargo, el sistema de archivos de root se podría dejar sin cuotas, eliminando la complejidad de mantener cuotas en un sistema de archivos donde solamente reside el sistema operativo.

5.9.7.1.2. Contabilidad del espacio por usuario

Las cuotas pueden realizar la contabilidad del espacio por usuarios. Esto significa que se puede hacer un seguimiento del uso de espacio por usuario individual. También significa que cualquier limitación en uso (lo que se discute en las secciones siguientes) se hacen igualmente basada en usuarios.

El tener la posibilidad de seguir de cerca el uso del espacio para cada usuario individual, permite a un administrador de sistemas asignar límites diferentes a diferentes usuarios, de acuerdo a sus responsabilidades y necesidades de almacenamiento.

5.9.7.1.3. Contabilidad de uso por grupos

Las cuotas de disco también pueden realizar seguimiento del uso de disco por grupos. Esto es ideal para aquellas organizaciones que utilizan grupos como formas de combinar usuarios en un solo recurso global al proyecto.

Mediante el establecimiento de cuotas globales a grupos, el administrador del sistema puede manejar más de cerca la utilización del almacenamiento al darle a los usuarios individuales solamente la cuota de disco que requieren para su uso personal, a la vez que se les proporcionan cuotas más grandes para proyectos con múltiples usuarios. Esto es una gran ventaja para aquellas organizaciones que usan un mecanismo de "cobranzas" para asignar costos de centro de datos para aquellos departamentos y equipos que utilicen los recursos del centro de datos.

5.9.7.1.4. Seguimiento del uso de bloques de disco

Las cuotas de disco mantienen estadísticas del uso del bloques de disco. Debido a que todos los datos en un sistema de archivos se almacenan en bloques, las cuotas son capaces de directamente correlacionar los archivos creados y borrados en sistema de archivos con la cantidad de almacenamiento que esos archivos utilizan.

5.9.7.1.5. Seguimiento del uso de inodes

Además de seguir el uso por bloque, las cuotas también permiten hacer seguimiento por inodes. Bajo Red Hat Enterprise Linux, los inodes son utilizados para almacenar varias partes del sistema de archivos, pero más importante aún, los inodes guardan información para cada archivo. Por lo tanto, al controlar el uso de inodes, es posible controlar la creación de nuevos archivos.


5.9.7.1.6. Límites rígidos

Un límite rígido es el número máximo absoluto de bloques de disco (o inodes) que un usuario (o un grupo) puede temporalmente utilizar. Cualquier intento de utilizar un sólo bloque o inode adicional, fallará.

5.9.7.1.7. Límites suaves

Un límite suave es el número máximo de bloque (o inodes) que un usuario (o un grupo) puede utilizar permanentemente.

El límite suave se configura por debajo del límite rígido. Esto permite a los usuarios que se excedan temporalmente de su límite suave, permitiendoles terminar lo que sea que estaban realizando y dándoles algún tiempo para revisar sus archivos y poner en orden su uso del espacio por debajo del límite suave.

5.9.7.1.8. Períodos de gracia

Como se estableció anteriormente, cualquier uso del disco más allá del límite suave es temporal. Es el período de gracia el que determina el largo del tiempo que un usuario (o grupo) puede extender su uso más allá del límite suave y hacia el límite rígido.

Si un usuario continúa usando más de su límite suave y el período de gracia expira, no se le permitirá más uso adicional de disco hasta que el usuario (o el grupo) reduzca su uso a un punto por debajo del límite suave.

El período de gracia se puede expresar en segundos, minutos, horas, días, semanas o meses, dándole al administrador del sistema una gran libertad para determinar cuánto tiempo le dará a sus usuarios para poner sus cosas en orden.

5.9.7.2. Activando Cuotas de Disco

Nota

Las secciones siguientes suministran una breve descripción general de los pasos necesarios para habilitar las cuotas de disco bajo Red Hat Enterprise Linux. Para información en más detalles sobre esto, lea el capítulo sobre cuotas de discos en el Manual de administración del sistema de Red Hat Enterprise Linux .

Para utilizar cuotas de disco, primero debe activarlas. Este proceso implica varios pasos:

1. Modificar /etc/fstab

2. Remontar el(los) sistema(s) de archivo(s)

3. Ejecutar quotacheck

4. Asignar cuotas

El archivo /etc/fstab controla el montaje de sistemas de archivos bajo Red Hat Enterprise Linux. Debido a que las cuotas de discos se implementan en una base de por archivo, hay dos opciones — usrquota y grpquota — que se deben añadir a ese archivo para activar las cuotas de discos.


La opción usrquota activa las cuotas basadas en disco, mientras que la opción grpquota activa las cuotas basadas en grupos. Se puede activar una o ambas opciones colocándolas en el campo de opciones para el sistema de archivos deseado.

Se debe entonces desmontar el sistema de archivos afectado y volver a montar para que las opciones referentes a las cuotas surtan efecto.

Luego, se utiliza el comando quotacheck para crear los archivos de cuotas de disco y para reunir la información referente al uso actual de los archivos ya existentes. Los archivos de cuota de disco (llamados aquota.user y aquota.group para las cuotas basadas en usuario y grupos) contienen la información relacionada a cuotas necesaria y residen en el directorio raíz del sistema.

Para asignar cuotas de disco, se utiliza el comando edquota.

Este programa de utilidades utiliza un editor de texto para mostrar la información de cuotas para el usuario o grupo especificado como parte del comando edquota. He aquí un ejemplo:

Disk quotas for user matt (uid 500): Filesystem blocks soft hard inodes soft hard /dev/md3 6618000 0 0 17397 0 0

Esto muestra que el usuario matt actualmente está utilizando más de 6GB de espacio en disco y más de 17.000 inodes. No se ha asignado ninguna cuota (soft o hard) para los bloques o inodes, lo que significa que no existe un límite en el espacio en disco que este usuario puede utilizar actualmente.

Utilizando el editor de texto mostrando la información de cuotas, el administrador del sistema puede modificar los límites rígidos y suaves como lo desee:

Disk quotas for user matt (uid 500): Filesystem blocks soft hard inodes soft hard /dev/md3 6618000 6900000 7000000 17397 0 0

En este ejemplo, se le ha asignado al usuario matt un límite suave de 6.9GB y un límite rígido de 7GB. No se establecen límites suaves o rígidos para inodes de este usuario.

Sugerencia

El programa edquota también se puede utilizar para establecer un período de gracia por archivo usando la opción -t.

5.9.7.3. Administración de Cuotas de Disco

Realmente es poco lo que se tiene que hacer para manejar las cuotas de disco bajo Red Hat Enterprise Linux. Esencialmente lo que se requiere hacer es:

• Generar informes de uso del disco a intervalos regulares (y hacer un seguimiento de los usuarios que parecen tener problemas con manejar efectivamente su espacio de disco asignado)

• Asegurarse de que las cuotas de discos permanecen exactas

La creación de un informe sobre el uso del disco implica la ejecución del programa de utilidades repquota. Usando el programa repquota /home produce la salida siguiente:

*** Report for user quotas on device /dev/md3 Block grace time: 7days; Inode grace time: 7days

Block limits File limits User used soft hard grace used soft hard grace

--------------------------------------------------------------------------


root 32836 0 0 4 0 0 matt 6618000 6900000 7000000 17397 0 0

Se puede encontrar más información sobre repquota en el Manual de administración del sistema de Red Hat Enterprise Linux, en el capítulo sobre cuotas de disco.

Cada vez que se desmonta un sistema de archivo de forma abrupta (debido a una falla del sistema, por ejemplo), es necesario ejecutar quotacheck. Sin embargo, muchos administradores de sistemas recomiendan ejecutar quotacheck regularmente, aún si el sistema no falla.

El proceso es similar al uso inicial de quotacheck cuando se activan cuotas de disco.

He aquí un ejemplo del comando quotacheck:

quotacheck -avug

La forma más fácil de ejecutar quotacheck de forma regular es usando cron. La mayoría de los administradores de sistemas ejecutan quotacheck una vez a la semana, sin embargo, pueden haber razones válidas para seleccionar un intervalo más largo o más corto, dependiendo de sus condiciones específicas.

5.9.8. Creación de Formaciones RAID

Además de soportar las soluciones de hardware RAID, Red Hat Enterprise Linux soporta también software RAID. Hay dos formas de crear software RAID:

• Mientras se instala Red Hat Enterprise Linux

• Después de instalar Red Hat Enterprise Linux

Las secciones siguientes revisan estos dos métodos.

5.9.8.1. Mientras se instala Red Hat Enterprise Linux

Durante el proceso normal de instalación de Red Hat Enterprise Linux, se pueden crear formaciones RAID. Esto se hace durante la fase de particionamiento de la instalación.

Para comenzar, debe particionar manualmente sus discos duros usando Disk Druid. Primero debe crear una nueva partición del tipo "software RAID." Luego, seleccione las unidades de disco que desea que formen parte de la formación RAID en el campo Unidades admisibles. Continue seleccionando el tamaño deseado y si desea que la partición sea primaria.

Una vez creadas todas las particiones requeridas por la formación(es) RAID que desea crear, debe pulsar el botón RAID para realmente crear las formaciones. Luego se le presentará una caja de diálogo donde puede seleccionar el punto de montaje de la formación, el tipo de sistema de archivos, el nombre del dispositivo RAID, nivel RAID y las particiones de "software RAID" en las que se basa la formación.

Una vez creados las formaciones deseadas, el proceso de instalación continúa como de costumbre.

Sugerencia

Para más información sobre la creación de formaciones RAID durante el proceso de instalación de Red Hat Enterprise Linux, consulte el Manual de administración del sistema de Red Hat Enterprise Linux .


5.9.8.2. Después de instalar Red Hat Enterprise Linux

La creación de una formación RAID después de que Red Hat Enterprise Linux ha sido instalado es un poco más compleja. Como con la adición de cualquier tipo de almacenamiento, primero se debe instalar y configurar el hardware necesario.

El particionamiento es un poco diferente para RAID que con las unidades de discos únicas. En vez de seleccionar el tipo de partición como "Linux" (tipo 83) o "Linux swap" (tipo 82), todas las particiones que son parte de una formación RAID se deben configurar a "Linux raid auto" (tipo fd).

Luego, es necesario crear el archivo /etc/raidtab. Este archivo es responsable de la configuración correcta de todas las formaciones RAID en su sistema. El formato del archivo (el cual se documenta en la página man de raidtab(5)) es relativamente fácil de entender. He aquí un ejemplo de una entrada /etc/raidtab para una formación RAID 1.

raiddev /dev/md0 raid-level 1 nr-raid-disks 2 chunk-size 64k persistent-superblock 1 nr-spare-disks 0

device /dev/hda2 raid-disk 0 device /dev/hdc2 raid-disk 1

Algunas de las secciones más notables en esta entrada son:

• raiddev — Muestra el nombre del archivo del dispositivo para la formación RAID12

• raid-level — Define el nivel de RAID utilizado por esta formación

• nr-raid-disks — Indica cuántas particiones de disco físicas seran parte de la formación

• nr-spare-disks — El software RAID bajo Red Hat Enterprise Linux permite la definición de uno o más particiones de repuesto; estas particiones pueden automáticamente tomar el lugar de un disco que no esté funcionando bien

• device, raid-disk — Juntos definen las particiones de disco físicas que conforman la formación RAID

Luego, es necesario crear la formación RAID. Esto se logra con el programa mkraid. Usando nuestro archivo de ejemplo /etc/raidtab, crearemos la formación RAID /dev/md0 con el comando siguiente:

mkraid /dev/md0

La formación RAID /dev/md0 ahora está lista para ser formateada y montada. El proceso en este punto no es diferente a formatear y montar un disco único.

5.9.9. Administración día a día de las formaciones RAID

Es poco lo que hay que hacer para mantener la formación RAID operativa. Siempre y cuando no surjan problemas de hardware, la formación debería funcionar como si se tratase de una sola unidad física de discos. Sin embargo, de la misma forma que un administrador de sistemas debería verificar

12. Observe que puesto que la formación RAID está compuesta de espacio en disco formateado, el nombre de

archivo de dispositivo de una formación RAID no refleja ninguna información a nivel de particiones.


periódicamente el estado de todos los discos duros en el sistema, también se debería verificar el estatus de las las formaciones RAID.

5.9.9.1. Uso de /proc/mdstat para verificar el estado de la formación RAID

El archivo /proc/mdstat es la forma más fácil de verificar el estado de todas las formaciones RAID en un sistema particular. He aquí una muestra mdstat (vista con el comando cat /proc/mdstat):

Personalities : [raid1] read_ahead 1024 sectors md1 : active raid1 hda3[0] hdc3[1]

522048 blocks [2/2] [UU]

md0 : active raid1 hda2[0] hdc2[1] 4192896 blocks [2/2] [UU]

md2 : active raid1 hda1[0] hdc1[1] 128384 blocks [2/2] [UU]

unused devices: � none �

En este sistema, hay tres formaciones RAID (todas RAID 1). Cada formación RAID tiene su propia sección en /proc/mdstat y contiene la información siguiente:

• El nombre de dispositivo de la formación RAID (sin incluir la parte /dev/)

• El estatus de la formación RAID

• El nivel RAID de la formación

• Las particiones físicas que actualmente conforman la formación (seguido por el número de unidad de la partición)

• El tamaño de la formación

• El número de dispositivos configurados contra el número de dispositivos operativos en la formación

• El estado de cada dispositivo configurado en la formación (U lo que significa que la formación está OK y _ indicando que el dispositivo ha fallado)

5.9.9.2. Reconstrucción de una formación RAID usando raidhotadd

Si /proc/mdstat muestra que existe un problema con una de las formaciones RAID, se debería utilizar el programa utilitario raidhotadd para reconstruir la formación. He aquí los pasos que se necesitan seguir:

1. Determine cuál unidad de disco contiene la partición que falla

2. Corrija el problema que causó la falla (probablemente reemplazando la unidad)

3. Particione la nueva unidad para que así las nuevas particiones en ella sean idénticas a aquellas en la(s) otra(s) unidad(es) en la formación

4. Ejecute el comando siguiente raidhotadd � raid-device �� disk-partition �

5. Monitorice /proc/mdstat para ver que se lleve a cabo la reconstrucción


Sugerencia

He aquí un comando que se puede utilizar para ver que se ejecute la reconstrucción:

watch -n1 cat /proc/mdstat

Este comando muestra los contenidos de /proc/mdstat, actualizándolo cada segundo.

5.9.10. Administración de Volúmenes Lógicos

Red Hat Enterprise Linux incluye el soporte para LVM. Se puede configurar LVM mientras se está instalando Red Hat Enterprise Linux, o también se puede configurar después de terminar la instalación. LVM bajo Red Hat Enterprise Linux soporta la agrupación del almacenamiento físico, la redimensión de los volúmenes lógicos y la migración de datos fuera de un volumen físico específico.

Para más información sobre LVM, consulte el Manual de administración del sistema de Red Hat Enterprise Linux.


Esta sección incluye varios recursos que se pueden utilizar para conocer más sobre las tecnologías de almacenamiento y la materia específica a Red Hat Enterprise Linux que se discute en este capítulo.


Los recursos siguientes se instalan durante el curso de una instalación típica de Red Hat Enterprise Linux y lo pueden ayudar a aprender un poco más sobre la materia discutida en este capítulo.

• La página man de exports(5) — Conozca más sobre el formato del archivo de configuración de NFS.

• La página man de fstab(5) — Conozca más información sobre la configuración del sistema de archivos.

• La página man de swapoff(8) — Aprenda a desactivar particiones swap.

• La página man de df(1) — Aprenda a mostrar el uso del espacio en disco en los sistemas de archivos montados.

• La página man de fdisk(8) — Conozca sobre este programa para el mantenimiento de las tablas de particiones.

• Las páginas man de mkfs(8) y mke2fs(8) — Información sobre estos programas utilitarios para la creación de sistemas de archivos.

• La página man de badblocks(8) — Aprenda cómo probar un dispositivo para verificar si tiene bloques dañados.

• La página man de quotacheck(8) — Aprenda a verificar el uso de bloques y inode para usuarios y grupos y opcionalmente crear archivos de cuotas de usuarios.

• La página man de edquota(8) — Información sobre este programa para el mantenimiento de cuotas de discos.

• La página man de repquota(8) — Conozca sobre esta programa de utilerías para el informe de cuotas de disco.


• La página man de raidtab(5) — Conozca sobre el formato del archivo de configuración para el software RAID.

• La página man de mkraid(8) — Conozca este programa para la creación de formaciones de software RAID.

• La página man de mdadm(8) — Conozca sobre este programa para la administración de formaciones de software RAID.

• La página man de lvm(8) — Aprenda sobre la Administración de Volúmenes Lógicos, LVM.

• La página man de devlabel(8) — Conozca más sobre el acceso a dispositivos de almacenamiento persistente.

5.10.2. Sitios Web de utilidad

• http://www.pcguide.com/ — Una buena fuente para diferentes tipos de información sobre tecnologías de almacenamiento.

• http://www.tldp.org/ — The Linux Documentation Project tiene una sección de HOWTOs y mini-HOWTOs que proporcionan buenas vistas generales de las tecnologías de almacenamiento en la forma en que se relacionan con Linux.


Los libros siguientes discuten varios problemas relacionados al almacenamiento y son buenos recursos para los administradores de sistemas Red Hat Enterprise Linux.

• El Manual de instalación de Red Hat Enterprise Linux; Red Hat, Inc. — Contiene instrucciones sobre el particionamiento de discos duros durante un proceso de instalación de Red Hat Enterprise Linux, así como también una descripción general de las particiones de discos.

• El Manual de referencia de Red Hat Enterprise Linux; Red Hat, Inc. — Contiene información detallada sobre la estructura de directorios utilizada en Red Hat Enterprise Linux y una descripción general de NFS.

• El Manual de administración del sistema de Red Hat Enterprise Linux; Red Hat, Inc. — Incluye capítulos sobre los sistemas de archivos, RAID, LVM, devlabel, particionamiento, cuotas de discos, NFS y Samba.

• El Linux System Administration: A User’s Guide por Marcel Gagne; Addison Wesley Professional — Contiene información sobre permisos de usuarios y grupos, sistemas de archivos, cuotas de discos, NFS y Samba.

• El Linux Performance Tuning and Capacity Planning por Jason R. Fink and Matthew D. Sherer; Sams — Contiene información sobre discos, RAID y rendimiento de NFS.

• El Linux Administration Handbook por Evi Nemeth, Garth Snyder y Trent R. Hein; Prentice Hall — Contiene información sobre sistemas de archivos, manejo de discos duros, NFS y Samba.


Capítulo 6. Administración de cuentas de usuarios yacceso a recursos

La administración de cuentas de usuario y grupos es una parte esencial de la administración de sistemas dentro de una organización. Pero para hacer esto efectivamente, un buen administrador de sistemas primero debe entender lo que son las cuentas de usuario y los grupos y como funcionan.

La razón principal para las cuentas de usuario es verificar la identidad de cada individuo utilizando un computador. Una razón secundaria (pero aún importante) es la de permitir la utilización personalizada de recursos y privilegios de acceso.

Los recursos incluyen archivos, directorios y dispositivos. El control de acceso a estos dispositivos forma una gran parte de la rutina diaria de un administrador de sistemas; a menudo el acceso a un recurso es controlado por grupos. Los grupos son construcciones lógicas que se pueden utilizar para enlazar a usuarios para un propósito común. Por ejemplo, si una organización tiene varios administradores de sistemas, todos ellos se pueden colocar en un grupo administrador de sistema. Luego se le pueden dar permisos al grupo para acceder a recursos claves del sistema. De esta forma, los grupos pueden ser una herramienta poderosa para la administración de recursos y acceso.

Las secciones siguientes discuten las cuentas de usuario y grupos en más detalles.

6.1. Administración de cuentas de usuarios

Como se indicó anteriormente, las cuentas de usuarios es la forma a través de la cual se identifica y autentifica a un individuo con el sistema. Las cuentas de usuarios tienen diferentes componentes. Primero, esta el nombre de usuario. Luego, está la contraseña, seguida de la información de control de acceso.

Las secciones siguientes exploran cada uno de estos componentes en más detalles.

6.1.1. El nombre de usuario

Desde el punto de vista del sistema, el nombre de usuario es la respuesta a la pregunta "quién es usted?". Como tal, los nombres de usuarios tienen un requerimiento principal — deben ser únicos. En otras palabras, cada usuario debe tener un nombre de usuario que sea diferente a todos los otros usuarios en ese sistema.

Debido a este requerimiento, es vital determinar — por adelantado — cómo se crean los nombres de usuario. De lo contrario, puede encontrarse en la posición de ser forzado a reaccionar cada vez que un nuevo usuario solicita una cuenta.

Lo que necesita es una convención de nombres para sus cuentas de usuarios.

6.1.1.1. Convenio de nombres

Mediante la creación de un convenio de nombres para los usuarios, puede ahorrarse varios problemas. En vez de inventar nombres cada vez (y darse cuenta de que cada vez se hace más difícil crear un nombre razonable), haga un poco de trabajo de antemano para preparar una convención a utilizar para todas las cuentas siguientes. Su convenio de nombres puede ser muy simple, o solamente su descripción puede tomar muchas páginas.

La naturaleza exacta de su convenio de nombres debe tomar varios factores en cuenta:

• El tamaño de su organización

122 Capítulo 6. Administración de cuentas de usuarios y acceso a recursos

• La estructura de su organización

• La naturaleza de su organización

El tamaño de su organización importa, pues dicta cuántos usuarios puede soportar su convención para nombres. Por ejemplo, una compañía muy pequeña quizás pueda permitir que todo el mundo utilice su primer nombre. Para una organización mucho más grande, este convenio no funciona.

La estructura de la organización también puede tener influencia sobre el convenio de nombres más apropiado. Para organizaciones con una estructura bien definida puede ser adecuado incluir elementos de esa estructura en la convención de nombres. Por ejemplo, puede incluir los códigos de los departamentos como parte del nombre de usuario.

La naturaleza completa de su organización también puede significar que algunas convenciones son más apropiadas que otras. Una organización que maneja datos confidenciales puede decidirse por una convenición que no indica ningún tipo de información personal que pueda vincular al individuo con su nombre. En una organización de este tipo, el nombre de usuario de Maggie McOmie podría ser LUH3417.

He aquí algunas convenciones de nombres que otras organizaciones han utilizado:

• Primer nombre (jorge, carlos, pedro, etc.)

• Apellido (perez, obregon, ramirez, etc)

• Primera inicial, seguido del apellido (jperez, cobregon, pramirez, etc.)

• Apellido, seguido del código del departamento (perez029, obregon454, ramirez191, etc.)

Sugerencia

Tenga en cuenta que si su convención de nombres incluye añadir datos diferentes para formar un nombre de usuario, existe el potencial de que el resultado sea gracioso u ofensivo. Por lo tanto, aún si crea los nombres de usuario de forma automática, es recomendable que lleve a cabo alguna forma de revisión.

Una cosa común con la convención de nombres descrita aquí es que es posible que eventualmente existan dos individuos que, de acuerdo a la convención, obtendrían el mismo nombre de usuario. Esto se conoce como una colisión.

6.1.1.1.1. Manejar colisione

Las colisiones son un hecho — no importa cuanto lo intente, eventualmente se encontrará tratando con colisiones. Debe planear para las colisiones en su convención de nombres. Hay muchas formas de hacer esto:

• Añadiendo números en secuencia al nombre de usuario en colisión (perez, perez1, perez2, etc.)

• Añadiendo datos específicos al usuario al nombre de usuario en colisión (perez, eperez, ekperez, etc.)

• Añadiendo información adicional de la organización al nombre de usuario (perez, perez029, perez454, etc.)

Es necesario tener un método para resolver las colisiones como parte de cualquier convención de nombres. Sin embargo, hace más dificil para alguien fuera de la organización determinar el nombre de usuario de un individuo. Por lo tanto, la desventaja de las convenciones de nombres es que hace más probable el envio de correos electrónicos a las direcciones equivocadas.

Capítulo 6. Administración de cuentas de usuarios y acceso a recursos 123

6.1.1.2. Manejo de cambios de nombres

Si su organización utiliza una convención de nombres que está basada en el nombre de cada usuario, es de esperarse que eventualmente tendrá que enfrentarse a cambios de nombres. Aún si el nombre de la persona realmente no cambia, de vez en cuando se le pedirá que modifique el nombre de usuario. Las razones pueden variar desde un usuario que no le gusta su nombre de usuario hasta un empleado con más jerarquía en la organización que prefiere un nombre de usuario "más acorde".

No importa cual sea la razón, hay muchos aspectos a tener en mente cuando se cambie un nombre de usuario:

• Efectue el cambio en todos los sistemas afectados

• Mantenga constante toda la información subyacente del usuario

• Cambien la propiedad de todos los archivos y otros recursos específicos al usuario (si es necesario)

• Maneje los problemas relacionados con el correo electrónico

Primero que nada, es importante asegurarse de que el nuevo nombre de usuario es propagado a todos los sistemas donde se utilizaba el nombre original. De lo contrario, cualquier función del sistema operativo que esté vinculado con el nombre de usuario, funcionará en algunos sistemas y en otros no. Ciertos sistemas operativos utilizan técnicas de control de acceso basadas en nombres de usuarios; tales sistemas son paticularmente vulnerables a problemas derivados de un cambio de nombre de usuario.

Muchos sistemas operativos utilizan algún tipo de número de identificación de usuarios para la mayoría de los procesamientos específicos al usuario. Para minimizar los problemas generados a partir de un cambio de nombre de usuario, trate de mantener este número de identificación constante entre el nuevo y el viejo nombre de usuario. Si no se hace esto, puede producir un escenario en el que el usuario ya no puede acceder a sus archivos y otros recursos que ellos poseían anteriormente bajo el nombre de usuario original.

Si se debe cambiar el número de identificación del usuario, es necesario cambiar la propiedad para todos los archivos y recursos específicos al usuario para reflejar la nueva identificación del usuario. Este puede ser un proceso muy susceptible a errores, ya que pareciera que siempre hay algo en alguna esquina olvidada del sistema que se ignora al final.

Los problemas relacionados al correo electrónico probablemente sean donde el cambio de un nombre de usuario es más difícil. La razón para esto es que a menos que se tomen las medidas para evitarlo, los correos electrónicos dirigidos al viejo nombre de usuario no se entregaran al nuevo.

Lamentablemente, los problemas alrededor del impacto de los cambios de nombres de usuario en el correo electrónico tienen múltiples dimensiones. En su forma más básica, un cambio de nombre de usuario implica que la gente ya no conoce el nombre de usuario correcto de esa persona. A primera vista, esto puede parecer como que no es gran cosa — notificar a todo el mundo en su organización. Pero que hay de las personas fuera de la organización que han enviado correo a esta persona? ¿Cómo se les debería notificar?¿Qué hay de las listas de correo (tanto internas como externas)? ¿Cómo se pueden actualizar?

No hay una respuesta fácil a esta pregunta. La mejor respuesta puede ser la de crear un alias para el correo electrónico de manera que todo el correo enviado al viejo nombre de usuario sea redirigido al nuevo nombre. Se le puede indicar al usuario que debe alertar a todas las personas que su nombre de usuario ha sido modificado. A medida que el tiempo pasa, menos y menos mensajes serán entregados usando el alias y eventualmente podrá eliminarlo.

Mientras que el uso de alias, a cierto nivel, continua la asunción incorrecta (de que el usuario conocido ahora como mperez todavía se conoce como jperez), es la única forma de garantizar que el correo llegue a la persona adecuada.


Importante

Si utiliza un alias para el correo electrónico, asegurese de tomar todos los pasos necesarios para proteger el viejo nombre de usuario de un reuso potencial. Si no hace esto y un nuevo usuario recibe el viejo nombre de usuario, la entrega de correo (tanto para el usuario original como para el nuevo) será interrumpida. La naturaleza exacta de la interrupción depende de cómo se implementa la entrega de correo en su sistema operativo, pero los dos síntomas más probables son:

• El nuevo usuario nunca recibe ningún correo - todo se va al usuario original.

• Repentinamente el usuario original deja de recibir correo - todo se va al nuevo usuario.

6.1.2. Contraseñas

Si el nombre de usuario responde a la pregunta "¿Quién es usted?", la contraseña es la respuesta a la pregunta que inevitablemente sigue:

"Demuéstralo!"

En términos más prácticos, una contraseña proporciona una forma de probar la autenticidad de la persona que dice ser el usuario con ese nombre de usuario. La efectividad de un esquema basado en contraseñas recae en gran parte sobre varios aspectos de la contraseña:

• La confidencialidad de la contraseña

• La resistencia de adivinar la contraseña

• La resistencia de la contraseña ante un ataque de fuerza bruta

Las contraseñas que efectivamente toman en cuenta estos problemas se conocen como contraseñas robustas, mientras que aquellas que no, se les llama débiles. Es importante para la seguridad de la organización crear contraseñas robustas, mientras más robustas sean las contraseñas, hay menos chances de que estas sean descubiertas o que se adivinen. Hay dos opciones disponibles para reforzar el uso de contraseñas robustas:

• El administrador del sistema puede crear contraseñas para todos los usuarios.

• El administrador del sistema puede dejar que los usuarios creen sus propias contraseñas, a la vez que se verifica que las contraseñas sean lo suficientemente robustas.

Al crear contraseñas para todos los usuarios asegura que estas sean robustas, pero se vuelve una tarea pesada a medida que crece la organización. También incrementa el riesgo de que los usuarios escriban sus contraseñas.

Por estas razones, la mayoría de los administradores de sistemas prefieren dejar que los usuarios mismos creen sus contraseñas. Sin embargo, un buen administrador de sistemas tomará los pasos adecuados para verificar que las contraseñas sean robustas.

Para leer sobre las pautas para la creación de contraseñas robustas, vea el capítulo llamado Seguridad de las Estaciones de trabajo en el Manual de seguridad de Red Hat Enterprise Linux.

La necesidad de mantener secretas las contraseñas debería ser una parte arraigada en la mente de un administrador de sistemas. Sin embargo, este punto se pierde con frecuencia en muchos usuarios. De hecho, muchos usuarios ni siquiera entienden la diferencia entre nombres de usuarios y contraseñas. Dado este hecho, es de vital importancia proporcionar cierta cantidad de educación para los usuarios, para que así estos puedan entender que sus contraseñas se deberían mantener tan secretas como su sueldo.

1

2

3

4

5

6


Las contraseñas deberían ser tan difíciles de adivinar como sea posible. Una contraseña robusta es aquella que un atacante no podrá adivinar, aún si el atacante conoce bien al usuario.

Un ataque de fuerza bruta sobre una contraseña implica el intento metódico (usualmente a través de un programa conocido como password-cracker) de cada combinación de caracteres posible con la esperanza de que se encontrará la contraseña correcta eventualmente. Una contraseña robusta se debería construir de manera tal que el número de contraseñas potenciales a probar sea muy grande, forzando al atacante a tomarse un largo tiempo buscando la contraseña.

Las contraseñas débiles y robustas se exploran con más detalles en las secciones siguientes.

6.1.2.1. Contraseñas débiles

Como se estableció anteriormente, una contraseña débil es una que no pasa alguna de estas tres pruebas:

• Es secreta

• Es resistente a ser adivinada

• Es resistente a un ataque de fuerza bruta

Las secciones siguientes muestran cómo pueden ser débiles las contraseñas.

6.1.2.1.1. Contraseñas cortas

Una contraseña corta es débil porque es mucho más susceptible a un ataque de fuerza bruta. Para ilustrar esto, considere la tabla siguiente, en el que se muestran el número de contraseñas potenciales que deben ser evaluadas en un ataque de fuerza bruta. (Se asume que las contraseñas consisten solamente de letras en minúsculas.)

Largo de la contraseña Contraseñas potenciales

26

676

17,576

456,976

11,881,376

308,915,776

Tabla 6-1. El largo de la contraseña contra el número de contraseñas potenciales

Como puede ver, el número de contraseñas posibles incrementa dramáticamente a medida que se incrementa el largo.

Nota

Aún cuando esta tabla termina en seis caracteres, esto no se debería tomar como que se recomienda contraseñas de seis caracteres de largo como lo suficientemente largas para una buena seguridad. En general, mientras más larga la contraseña mejor.


6.1.2.1.2. Conjunto de carácteres limitado

El número de carácteres diferentes que comprenden una contraseña tiene un gran impacto en la habilidad de un atacante de conducir un ataque de fuerza bruta. Por ejemplo, en vez de 26 carácteres diferentes que se pueden utilizar en una contraseña de solamente minúsculas, que tal si usamos números? Esto significa que cada carácter en una contraseña es uno de 36 en vez de uno de 26. En el caso de contraseñas de seis caracteres de largo, esto representa un incremento de contraseñas posibles de 308,915,776 a 2,176,782,336.

Aún hay más que se puede hacer. Si también incluímos contraseñas alfanuméricas con mayúsculas y minúsculas (para aquellos sistemas operativos que lo soporten), el número posible de contraseñas de seis carácteres se incrementa a 56,800,235,584. Añadiendo otros caracteres (tales como símbolos de puntuación) aumenta aún más los números posibles, haciendo un ataque de fuerza bruta mucho más difícil.

Sin embargo, un punto a tener en mente es que no todos los ataques contra una contraseña son de fuerza bruta. Las secciones siguientes describen otros atributos que pueden hacer una contraseña débil.

6.1.2.1.3. Palabras reconocibles

Muchos ataques contra contraseñas están basados en el hecho de que la gente generalmente se siente más cómoda con contraseñas que pueden recordar. Y para la mayoría de la gente, las contraseñas más fáciles de recordar son las que contienen palabras. Por lo tanto, muchos ataques a contraseñas están basados en el diccionario. En otras palabras, el atacante utiliza diccionarios de palabras en un intento de encontrar la palabra o palabras que forman la contraseña.

Nota

Muchos programas de ataque a contraseñas basados en diccionario utilizan diccionarios de diferentes idiomas. Por lo tanto, no piense que su contraseña es más robusta simplemente porque está utilizando una palabra que no es en Español.

6.1.2.1.4. Información personal

Las contraseñas que contienen información personal (el nombre o fecha de nacimiento de un ser querido, una mascota o un número de identificación personal) puede o puede que no sean encontradas a través de un ataque basado en contraseñas de diccionario. Sin embargo, si el atacante lo conoce personalmente (o está lo suficientemente motivado para investigar su vida personal), puede ser capaz de adivinar su contraseña con poca o ninguna dificultad.

Además de los diccionarios, muchos descifradores de contraseñas también incluyen nombres comunes, fechas y otro tipo de información en su búsqueda de contraseñas. Por lo tanto, aún si el atacante no conoce que el nombre de su perro es Howard, todavía pueden descubrir que su contraseña es "MiperrosellamaHoward", con un buen descifrador de contraseñas.

6.1.2.1.5. Trucos simples de palabras

Usando cualquiera de la información discutida anteriormente como la base para una contraseña, pero invirtiendo el orden de las letras, tampoco hace una contraseña débil en una robusta. La mayoría de los descifradores de contraseñas hacen estos trucos en todas las contraseñas posibles. Esto incluye sustituir cierto números por letras en palabras comunes. He aquí algunos ejemplos:

• drowssaPdaB1


• R3allyP00r

6.1.2.1.6. La misma palabra para múltiples sistemas

Aún si su contraseña es robusta, no es una buena idea utilizar la misma contraseña en más de un sistema. Obviamente se puede hacer muy poco si los sistemas son configurados para utilizar un servidor central de algún tipo, pero en cualquier otro caso, se deben utilizar contraseñas diferentes para sistemas diferentes.

6.1.2.1.7. Contraseñas en papel

Otra forma de hacer una contraseña robusta en una débil es escribiéndola. Al colocar su contraseña en papel, ya usted no tiene un problema de confidencialidad, pero de seguridad física - ahora usted debe mantener seguro ese pedazo de papel. Esto obviamente no es una buena idea.

Sin embargo, algunas organizaciones tienen una necesidad legítima para escribir contraseñas. Por ejemplo, algunas organizaciones tienen contraseñas escritas como parte de un procedimiento para recuperarse de la pérdida de un empleado clave (tales como un administrador de sistemas). En estos casos, el papel conteniendo las contraseñas es almacenado en una ubicación físicamente segura que requiere la cooperación de varias personas para tener acceso al papel. Usualmente se utilizan cajas de seguridad acorazadas y con mútiples cerrojos.

Cualquier organización que explore este método de almacenar contraseñas para propósitos de emergencia debe estar consciente de que la existencia de contraseñas escritas añade un elemento de riesgo a la seguridad de sus sistemas, no importa cuan seguro sea el almacenamiento de las contraseñas. Esto es particularmente cierto si es de conocimiento general que las contraseñas se encuentran escritas (y donde se encuentran).

Lamentablemente, a menudo las contraseñas escritas no forman parte de un plan de recuperación y no son almacenadas en una bóveda, y estas son las contraseñas de los usuarios comunes y son almacenadas en sitios como:

• En la gaveta (cerrada con llave o no)

• Bajo el teclado

• En la cartera

• Pegada al lado del monitor

Ninguna de estas ubicaciones son lugares apropiados para una contraseña escrita.

6.1.2.2. Contraseñas robustas

Hemos visto cómo son las contraseñas débiles; las secciones siguientes describen funcionalidades que todas las contraseñas robustas tienen.

6.1.2.2.1. Contraseñas largas

Mientras más larga la contraseña, menos es la probabilidad de que tenga éxito un ataque de fuerza bruta. Por lo tanto, si su sistema operativo lo soporta, establezca un largo mínimo para las contraseñas de sus usuarios relativamente largo.


6.1.2.2.2. Conjunto de caracteres expandido

Promocione el uso de contraseñas alfanuméricas que combinen el uso de mayúsculas y minúsculas y más aún, anime la adición de un carácter no-alfanumérico a todas las contraseñas:

• t1Te-Bf,te

• Lb@lbhom

6.1.2.2.3. Memorizables

Una contraseña es robusta solamente si se puede recordar. Sin embargo, usualmente el ser fácil de memorizar y fácil de adivinar a menudo van juntos. Por lo tanto, dele a su comunidad de usuarios algunos consejos sobre la creación de contraseñas fáciles de recordar pero que no sean fáciles de adivinar.

Por ejemplo, tome una frase favorita o dicho y utilice las primeras letras de cada palabra como el punto de comienzo para la creación de la nueva contraseña. El resultado es fácil de memorizar (pues la frase en la cual está basado es, en sí misma, recordable), sin embargo el resultado no contiene ninguna palabra.

Nota

Tenga en cuenta que el usar las primeras letras de cada palabra en una frase no es suficiente para crear una contraseña robusta. Siempre asegúrese de incrementar el conjunto de caracteres incluyendo la combinación de carácteres alfanuméricos y también al menos un carácter especial.

6.1.2.3. Caducidad de las contraseñas

Si es posible implemente períodos de vigencia para las contraseñas. La caducidad de las contraseñas es una funcionalidad (disponible en muchos sistemas operativos) que coloca límites en el tiempo que una contraseña dada es considerada válida. Al final del tiempo de vida de la contraseña, se le pide al usuario que introduzca una nueva contraseña, que se puede utilizar hasta que, igualmente, expire.

La pregunta clave con respecto a la caducidad de las contraseñas con la que se enfrentan muchos administradores de sistemas es sobre el tiempo de vida de una contraseña: ¿Cuál es el más adecuado?

Hay dos problemas diametricalmente opuestos con respecto al tiempo de vida de las contraseñas:

• Conveniencia del usuario

• Seguridad

Por un lado, un tiempo de vida de una contraseña de 99 años presentará muy pocos problemas (si es que llega a presentar alguno). Sin embargo, proporcionará muy poco en términos de mejorar la seguridad.

En el otro extremo, un tiempo de vida de una contraseña de 99 minutos será un gran inconveniente para los usuarios. Sin embargo, la seguridad mejorará en extremo.

La idea es encontrar un balance entre la conveniencia para sus usuarios y la necesidad de seguridad de su organización. Para la mayoría de las organizaciones, los tiempos de vida de las contraseñas dentro del rango de semanas - meses, son los más comunes.


6.1.3. Información de control de acceso

Junto con un nombre de usuario y contraseña, las cuentas de usuario también contienen información de acceso. Esta información toma formas diferentes de acuerdo al sistema operativo utilizado. Sin embargo, los tipos de información a menudo incluyen:

• Identificación específica al usuario global al sistema

• Identificación específica al grupo global al sistema

• Lista de los grupos/capacidades adicionales a los cuales el usuario es miembro

• Información de acceso por defecto a aplicar para todos los archivos y recursoscreados por el usuario

En algunas organizaciones, la información de control de acceso quizás nunca se necesite tocar. Este caso es más frecuente con estaciones de trabajo personales y sistemas independientes, por ejemplo. Otras organizaciones, particularmente aquellas que hacen uso extensivo de los recursos compartidos a los largo de la red entre diferentes grupos de usuarios, requieren que la información de control de acceso se modifique con frecuencia.

La carga de trabajo requerida para mantener apropiadamente la información de control de acceso de sus usuarios varía de acuerdo a cuan intensivamente su organización utiliza las funcionalidades de control de acceso. Mientras que no esta mal contar con estas funcionalidades (de hecho, quizás sea inevitable), implica que su entorno de sistema puede requerir más esfuerzo para ser mantenido y que cada cuenta de usuario pueda tener más formas en las cuales pueda ser mal configurada.

Por lo tanto, si su organización requiere de este tipo de entorno, debería documentar los pasos exactos requeridos para crear y correctamente configurar una cuenta de usuario. De hecho, si hay diferentes tipos de cuentas de usuario, debería documentar cada una (creando una nueva cuenta de usuario de finanzas, una nueva cuenta de usuario de operaciones, etc.).

6.1.4. Administración día a día de cuentas y acceso a recursos

Como dice el viejo dicho, lo único constante es el cambio. Es lo mismo cuando se trata de su comunidad de usuarios. Gente viene, se vá y también hay gente que se mueve de un grupo de responsabilidades a otro. Por lo tanto, los administradores de sistemas deben ser capaces de responder a los cambios que son una parte normal de la vida diaria de su organización.

6.1.4.1. Nuevos empleados

Cuando una nueva persona entra a la organización, normalmente se les da acceso a varios recursos (dependiendo de sus responsabilidades). Quizás se les facilite un lugar para trabajar, un teléfono y una llave para la puerta de entrada.

Probablemente también se les da acceso a uno o más computadoras en su organización. Como administrador del sistema, es su responsabilidad verificar que esto se haga rápidamente y de la forma adecuada. ¿Cómo hacerlo?

Antes de hacer algo, primero debe estar al tanto de la llegada de la nueva persona. Esto se maneja de diferentes formas en varias organizaciones. He aquí algunas posibilidades:

• Cree un procedimiento donde el departamento de personal de su organización le notifica cuando llega una nueva persona.

• Cree una forma que el supervisor de la nueva persona debe llenar y utilizar para solicitar la creación de una cuenta de usuario.

Diferentes organizaciones tienen enfoques diferentes. No importa como se lleve a cabo, es vital que tenga un procedimiento confiable que pueda alertar de cualquier trabajo relacionado a las cuentas que se necesite hacer.


6.1.4.2. Terminaciones

Es conocido el hecho de que habrá personas que dejen la organización. Algunas veces esto puede ser bajo circunstancias felices y otras quizás no tan felices. En cualquier caso, es vital que se le informe de la situación para que así pueda tomar las acciones adecuadas.

Como mínimo, las acciones apropiadas deben incluir:

• Inhabilitar el acceso del usuario a todos los sistemas y recursos relacionados (usualmente mediante el cambio o bloqueo de la contraseña)

• Hacer una copia de seguridad de los archivos del usuario, en caso de que contengan algo que se pueda necesitar en un futuro.

• Coordinar el acceso a los archivos del usuario para el supervisor

La principal prioridad es asegurar sus sistemas contra un usuario que ha dejado de trabajar con la organización recientemente. Esto es particularmente importante si el usuario fue terminado bajo condiciones que pueden haberlo dejado con un poco de malicia hacia la organización. Sin embargo, aún si las circunstancias no son tan graves, le conviene a la organización desactivar rápidamente el acceso a una persona que ya no pertenece a la compañía.

Esto indica la necesidad de un proceso que lo alerte sobre las terminaciones - preferiblemente antes de que estas sean efectivas. Esto implica que usted debería trabajar con el departamento de personal de su organización para asegurarse de que se le notifique sobre cualquier terminación futura.

Sugerencia

Cuando se manejen los "bloqueos" en respuesta a una liquidación, es de suma importancia que las cosas se hagan en el momento correcto. Si el bloqueo ocurre después de completarse el proceso de liquidación, hay potencial para el acceso no autorizado de la persona recientemente terminada. Por otro lado, si el bloqueo ocurre antes de que se inicie el proceso de liquidación, esto puede alertar a la persona sobre el despido inminente y hacer el proceso más difícil para ambas partes.

El proceso de liquidación usualmente se inicia a través de una reunión entre la persona a ser liquidada, el supervisor de la persona y un representante del departamento de personal de la organización. Por lo tanto, establecer un proceso que lo alerte sobre cuando esta reunión comenzará le dará las indicaciones sobre el momento correcto para hacer el bloqueo.

Una vez desactivado el acceso, es el momento para hacer una copia de seguridad de los archivos de esta persona. Este respaldo puede ser parte de los respaldos estándares de su organización, o puede ser un procedimiento dedicado a hacer copias de seguridad de viejas cuentas de usuario. Aspectos tales como regulaciones sobre la retención de datos, guardar evidencia en casos de demandas por liquidaciones erróneas y otras parecidas, todas forman parte en determinar la forma más apropiada de manejar las copias de seguridad.

En cualquier caso, un respaldo en este momento siempre es un buen hábito, pues el próximo paso (cuando el supervisor accede a los datos de la persona liquidada) puede resultar en la eliminación accidental de los archivos. En tales circunstancias, el tener una copia de seguridad reciente hace posible recuperarse fácilmente de este tipo de accidentes, haciendo el proceso más fácil tanto para el supervisor como para usted.

En este punto, debe determinar que tipo de acceso requiere el supervisor de la persona recientemente terminada a los archivos de esta. Dependiendo de su organización y la naturaleza de las responsabilidades de la persona, es posible que no se requiera ningun acceso, o que se necesite acceso completo.

Si la persona utilizó los sistemas para cosas más allá que simplemente correo electrónico, es posible que el supervisor tenga que revisar y colar un poco los archivos, determinar lo que se debería mantener y qué se puede desechar. Al concluir este proceso, al menos algunos de estos archivos seran entregados a la persona que tomará las responsabilidades de la persona liquidada. Quizás se le solicite


su asistencia para este paso final o puede que el supervisor esté en una posición de manejar esto él mismo. Todo depende de los archivos y de la naturaleza del trabajo que realiza su organización.

6.1.4.3. Cambios de trabajo

Responder a las peticiones de crear cuentas para los nuevos usuarios y el manejo de la secuencia de eventos necesarios para bloquear una cuenta de un empleado liquidado son procesos relativamente directos. Sin embargo, la situación no es tan clara cuando la persona cambia de responsabilidades dentro de su organización. Algunas veces la persona puede requerir cambios a su cuenta y algunas veces no.

Habrá al menos tres personas relacionadas en asegurarse de que la cuenta del usuario sea configurada adecuadamente para coincidir con las nuevas responsabilidades:

• Usted

• El supervisor original del usuario

• El nuevo supervisor del usuario

Entre uds tres debería ser posible determinar qué se debe hacer para cerrar limpiamente las responsabilidades anteriores del empleado y qué se debe hacer para preparar la cuenta para sus nuevas responsabilidades. En muchos casos, este proceso se puede pensar como el equivalente de cerrar un usuario existente y crear una nueva cuenta de usuario. De hecho, algunas organizaciones hacen esto para todos los cambios de responsabilidades.

No obstante, es más probable que se mantenga la cuenta del usuario y que se modifique para adaptarse a las nuevas responsabilidades. Este enfoque implica que usted debe revisar cuidadosamente la cuenta para asegurarse de que no se estan dejando recursos o privilegios de acceso en la cuenta y que esta tiene solamente los recursos y privilegios adecuados para las nuevas responsabilidades de la persona.

Para complicar las cosas aún más, está la situación en que hay un período de transición donde la persona realiza tareas relacionadas a ambos grupos de responsabilidades. Es aquí donde los supervisores original y el nuevo, lo pueden ayudar dándole una ventana de tiempo para este período de transición.

6.2. Administración de recursos de usuarios

La creación de cuentas de usuario solamente es una parte del trabajo de un administrador de sistemas. La administración de recursos también es esencial. Por lo tanto, debe considerar tres puntos:

• ¿Quién puede acceder a los datos compartidos?

• ¿Dónde los usuarios acceden a esos datos?

• ¿Qué barreras se colocan para prevenir el abuso de los recursos?

Las secciones siguientes revisan brevemente cada uno de estos tópicos.

6.2.1. ¿Quién puede acceder a los datos compartidos?

El acceso de un usuario a una aplicación dada, archivo o directorio es determinado por los permisos aplicados a esa aplicación, archivo o directorio.

Además, a menudo es útil si se pueden aplicar diferentes permisos para diferentes clases de usuarios. Por ejemplo, el almacenamiento compartido debería se capaz de prevenir la eliminación accidental (o maliciosa) de archivos de usuarios por otros usuarios, a la vez que se permite que el propietario de los archivos tenga acceso completo a los mismos.


Otro ejemplo es el acceso asignado al directorio principal de un usuario. Solamente el propietario del directorio principal debería poder crear y ver los archivos que se encuentran allí. Se debería negar el acceso a todos los otros usuarios (a menos que el usuario desee lo contrario). Esto incrementa la privacidad del usuario y previene de la posible apropiación incorrecta de archivos personales.

Pero hay muchas situaciones en las que múltiples usuarios pueden necesitar acceso al mismo conjunto de recursos en una máquina. En este caso, puede ser necesaria la creación de grupos compartidos.

6.2.1.1. Grupos y datos compartidos

Como se mencionó en la introducción, los grupos son construcciones lógicas que se pueden usar para vincular cuentas de usuario para un propósito específico.

Cuando se administran grupos dentro de una organización, es prudente identificar los datos a los que ciertos departamentos deben tener acceso, los datos que se deben negar a otros y que datos deberían ser compartidos por todos. Esto ayuda en la creación de una estructura de grupos adecuada, junto con los permisos apropiados para los datos compartidos.

Por ejemplo, asuma que el departamento de cuentas por cobrar debe mantener una lista de las cuentas morosas. Esta lista debe ser compartida con el departamento de cobros. Si el personal de cuentas por cobrar y el personal de cobranzas se colocan como miembros de un grupo llamado cuentas, esta información se puede colocar entonces en un directorio compartido (propiedad del grupo cuentas) con permisos de grupo para leer y escribir en el directorio.

6.2.1.2. Determinar la estructura de un grupo

Algunos de los retos con los que se encuentra un administrador de sistemas cuando crean grupos son:

• ¿Qué grupos crear?

• ¿A quién colocar en un grupo determinado?

• ¿Qué tipo de permisos deberian tener estos recursos compartidos?

Para estas preguntas se necesita un enfoque con sentido común. Una posibilidad es reflejar la estructura de su compañía cuando se creen grupos. Por ejemplo, si hay un departamento de finanzas, cree un grupo llamado finanzas y haga a todo el personal de finanzas parte de ese grupo. Si la información financiera es muy confidencial para toda la compañía, pero es vital para los empleados senior, entonces otorgue a estos permisos a nivel de grupo para el acceso a los directorios y los datos utilizados por el departamento de finanzas añadiendolos al grupo finanzas.

También es bueno pecar por el lado de la precaución cuando se otorguen permisos para los usuarios. De esta forma, hay menos probabilidades de que los datos confidenciales caigan en las manos incorrectas.

Enfocando la creación de la estructura de grupos de su organización de esta manera, se puede satisfacer de forma segura y efectiva la necesidad de datos compartidos dentro de la organización.

6.2.2. ¿Donde los usuarios acceden a los datos compartidos?

Cuando se comparten datos entre usuarios, es un práctica común tener un servidor central (o grupo de servidores) que hacen ciertos directorios disponibles a otras máquinas en la red. De esta forma los datos son almacenados en un lugar; no es necesario sincronizar los datos entre múltiples máquinas.

Antes de asumir este enfoque, primero debe determinar cuáles son los sistemas a acceder a los datos almacenados centralmente. Al hacer esto, tome nota de los sistemas operativos utilizados por los sistemas. Esta información tienen un peso en su habilidad de implementar este enfoque, pues su


servidor de almacenamiento debe ser capaz de servir sus datos a cada uno de los sistemas operativos en uso en su organización.

Lamentablemente, una vez que los datos son compartidos entre múltiples computadores en una red, puede surgir el potencial para conflictos en la propiedad de un archivo.

6.2.2.1. Problemas globales de propiedad

El tener los datos almacenados centralmente y accesibles por múltiples computadores sobre la red tiene sus ventajas. No obstante, asuma por un momento que cada una de esas computadoras tiene una lista mantenida localmente de las cuentas de usuarios. ¿Qué tal si las listas de usuarios en cada uno de estos sistemas no son consistentes con la lista de usuarios en el servidor central? Peor aún, ¿qué pasa si la lista de usuarios en cada uno de esos sistemas no son ni siquiera consistentes unas con otras?

Mucho de esto depende sobre cómo se implementen los usuarios y los permisos de acceso en cada sistema, pero en algunos casos es posible que el usuario A en un sistema pueda ser conocido como B en otro. Esto se vuelve un verdadero problema cuando los datos son compartidos entre sistemas, pues los datos que el usuario A tiene permitido acceder desde un sistema también puede ser leído por el usuario B desde otro sistema.

Por esta razón, muchas organizaciones utilizan algún tipo de base de datos central de usuarios. Esto asegura que no haya solapamientos entre las listas de usuarios en sistemas diferentes.

6.2.2.2. Directorios principales

Otro problema que enfrentan los administradores de sistemas es si los usuarios deberían tener directorios principales centralizados.

La ventaja principal de tener un directorio principal centralizado en un servidor conectado a la red es que si un usuario se conecta a cualquier máquina en la red, podrá acceder a los archivos en su directorio principal.

La desventaja es que, si la red se cae, los usuarios a lo largo de la organización no podrán acceder a sus archivos. En algunas situaciones (tales como organizaciones que hacen gran uso de portátiles), el tener directorios principales centralizados no es recomendable. Pero si tiene sentido para su organización, la implementación de directorios principales puede hacer la vida de un administrador mucho más fácil.

6.2.3. ¿Qué barreras se colocan para prevenir el abuso de los recursos?

La organización cuidadosa de recursos y la asignación de permisos para los recursos compartidos es una de las cosas más importantes que un administrador de sistemas puede hacer para prevenir el abuso de recursos entre usuarios dentro de la organización. De esta forma, aquellos que no deberían tener acceso a recursos confidenciales, se les niega el acceso.

Pero no importa cómo su organización haga las cosas, la mejor guardia contra el abuso de recursos siempre es la vigilancia permanente por parte del administrador del sistema. Mantener los ojos abiertos a menudo es la única manera de evitar que una sorpresa desagradable esté esperando por usted a la mañana siguiente.


Las secciones siguientes describen las diferentes funcionalidades específicas a Red Hat Enterprise Linux que se relacionan con la administración de cuentas de usuarios y recursos asociados.


6.3.1. Cuentas de usuarios, Grupos y Permisos

Bajo Red Hat Enterprise Linux, un usuario puede iniciar una sesión en un sistema y utilizar cualquier aplicación o archivos a los cuales tengan permiso de acceso después de crear una cuenta de usuario normal. Red Hat Enterprise Linux determina si un usuario o grupo puede acceder estos recursos basado en los permisos asignados a ellos.

Existen tres tipos diferentes de permisos para archivos, directorios y aplicaciones. Estos permisos son utilizados para controlar los tipos de acceso permitido. Se utilizan diferentes símbolos de un carácter para describir cada permiso en un listado de directorio. Se usan los siguientes símbolos:

• r — Indica que una categoría dada de usuario puede leer un archivo.

• w — Indica que una categoría de usuario puede escribir a un archivo.

• x — Indica que una categoría de usuario puede ejecutar los contenidos de un archivo.

Un cuarto símbolo (-) indica que no se permite ningún acceso.

Cada uno de estos tres permisos son asignados a tres categorías diferentes de usuarios. Las categorías son:

• owner — El dueño o propietario de un archivo o aplicación.

• group — El grupo dueño del archivo o aplicación.

• everyone — Todos los usuarios con acceso al sistema.

Como se indicó anteriormente, es posible ver los permisos para un archivo invocando un listado de directorios largo con el comando ls -l. Por ejemplo, si el usuario juan crea un archivo ejecutable llamado foo, la salida del comando ls -l foo sería así:

-rwxrwxr-x 1 juan juan 0 Sep 26 12:25 foo

Los permisos para este archivo se listan al principio de la línea, comenzando con rwx. El primer conjunto de símbolos define el acceso del dueño - en este ejemplo, el dueño juan tiene acceso completo y puede leer, escribir y ejecutar el archivo. El próximo conjunto de símbolos rwx define el acceso de grupo (una vez más, con acceso completo), mientras que el último conjunto de símbolos define el tipo de acceso permitido para todos los demás usuarios. Aquí, todos los otros usuarios pueden leer y ejecutar el archivo, pero no pueden modificarlo de ninguna forma.

Otro aspecto importante a tener en mente con relación a los permisos y a las cuentas de usuarios es que cada aplicación ejecutada en Red Hat Enterprise Linux se ejecuta en el contexto de un usuario específico. Típicamente, esto significa que si el usuario juan lanza una aplicación, la aplicación se ejecuta usando el contexto de juan. Sin embargo, en algunos casos la aplicación puede necesitar un nivel de acceso más privilegiado para poder realizar la tarea. Tales aplicaciones incluyen aquellas que modifican los parámetros del sistema o que conectan usuarios. Por esta razón, se deben crear permisos especiales.

Hay tres tipos de permisos especiales dentro de Red Hat Enterprise Linux. Ellos son:

• setuid — utilizado solamente para aplicaciones, este permiso indica que la aplicación se va a ejecutar como el dueño del archivo y no como el usuario lanzando la aplicación. Se indica por el carácter s en el lugar de x en la categoría del propietario. Si el propietario del archivo no tiene permisos de ejecución, la S se coloca en mayúsculas para reflejar este hecho.

• setgid — usada principalmente por las aplicaciones, este permiso indica que la aplicación se ejecutará como el grupo que es dueño del archivo y no como el grupo del usuario lanzando la aplicación.

Si se aplica a un directorio, todos los archivos creados dentro del directorio son propiedad del grupo que posee el directorio, y no por el grupo del usuario creando el archivo. El permiso de setgid se


indica por el carácter s en el lugar de x en la categoría de grupo. Si el grupo que posee el archivo o directorio no tiene permisos de ejecución, se coloca en mayúsculas la S para reflejar este hecho.

• sticky bit — utilizado principalmente en directorios, este bit indica que un archivo creado en el directorio solamente puede ser eliminado por el usuario que creó el archivo. Esto se indica por el carácter t en el lugar de x en la categoría de todo el mundo (everyone). Si la categoría everyone no tiene permisos de ejecución, la T se coloca en mayúsculas para reflejar este hecho.

Bajo Red Hat Enterprise Linux, el sticky bit se coloca por defecto en el directorio /tmp/ exactamente por esta razón.

6.3.1.1. Nombres de usuarios y UIDs, Grupos y GIDs

En Red Hat Enterprise Linux, los nombres de cuentas de usuarios y grupos son principalmente para la conveniencia de la gente. Internamente, el sistema utiliza identificadores numéricos. Para los usuarios este identificador se conoce como un UID, mientras que para los grupos se conoce como GID. Los programas que hacen disponibles la información de usuarios o grupos para los usuarios, traducen los valores de UID/GID a sus equivalentes más legibles para el usuario.

Importante

Los UIDs y los GIDs deben ser globalmente únicos dentro de su organización si pretende compartir archivos y recursos sobre la red. De lo contrario, cualquier control de acceso que implemente no funcionará correctamente pues estan basados en UIDs y GIDs, no en nombres de usuarios y de grupos.

Específicamente, si los archivos /etc/passwd y /etc/group en un servidor de archivos y en la estación de trabajo de un usuario son diferentes en los UIDs o GID que contienen, la aplicación inadecuada de permisos puede llevar a problemas de seguridad.

Por ejemplo, si el usuario juan tiene un UID de 500 en un computador de escritorio, los archivos que juan cree en un servidor de archivos se crearán con un propietario de UID 500. No obstante, si el usuario bob inicia una sesión en el servidor de archivos (o en otro computador), y la cuenta de bob también tiene un UID de 500, bob tendrá acceso completo a los archivos de juan y viceversa.

Por lo tanto, se deben evitar las colisiones de UID y GID a toda costa.

Hay dos instancias donde el valor numérico real de un UID o GID tiene un significado específico. El UID o GID de cero (0) se utiliza para el usuario root y se tratan de forma especial por Red Hat Enterprise Linux — automáticamente se le otorga acceso completo.

La segunda situación es que los UIDs y los GIDs por debajo de 500 se reservan para el uso del sistema. A diferencia de UID/GID cero (0), los UIDs y GIDs por debajo de 500 no son tratados de forma especial por Red Hat Enterprise Linux. Sin embargo, estos UIDs/GIDs nunca son asignados a un usuario, pues es posible que algunos componentes de sistemas utilicen o utilizaran alguno de estos UIDs/GIDs en algún momento. Para más información sobre estos usuarios y grupos estándar, consulte el capítulo llamado Usuarios y Grupos en el Manual de referencia de Red Hat Enterprise Linux.

Cuando se añaden nuevas cuentas de usuario usando las herramientas estándar de Red Hat Enterprise Linux, a las nuevas cuentas de usuario se les asigna el primer UID y GID disponible comenzando por 500. La próxima cuenta de usuario se le asignará un UID/GID de 501, seguido de UID/GID 502 y así sucesivamente.

Más adelante en este capítulo se hace una breve descripción de las herramientas disponibles bajo Red Hat Enterprise Linux para la creación de usuarios. Pero antes de revisar estas herramientas, la sección siguiente revisa los archivos que Red Hat Enterprise Linux utiliza para definir cuentas y grupos del sistema.


6.3.2. Archivos que controlan Cuentas de Usuarios y Grupos

En Red Hat Enterprise Linux la información sobre cuentas de usuarios y grupos es almacenada en varios archivos de texto dentro del directorio /etc/. Cuando un administrador del sistema crea una nueva cuenta de usuario, estos archivos deben ser editados manualmente o se deben usar las aplicaciones para hacer los cambios necesarios.

La sección siguiente documenta los archivos en el directorio /etc/ que almacenan información de usuarios y grupos bajo Red Hat Enterprise Linux.

6.3.2.1. /etc/passwd

El archivo /etc/passwd es un archivo legible por todo el mundo y contiene y una lista de usuarios, cada uno en una línea separada. En cada línea hay una lista delimitada por dos puntos (:) conteniendo la información siguiente:

• Nombre de usuario — El nombre que el usuario escribe cuando se conecta al sistema.

• Contraseña — Contiene la contraseña encriptada (o una x si se utilizan contraseñas shadow - más detalles sobre esto enseguida).

• ID del usuario (UID) — El equivalente numérico del nombre de usuario el cual es referenciado por el sistema y las aplicaciones cuando se determinan los privilegios de acceso.

• ID de Grupo (GID) — El equivalente numérico del nombre principal de grupo que utiliza el sistema y las aplicaciones para referenciar el grupo cuando se determinan los privilegios de acceso.

• GECOS — Nombrado por razones históricas, el campo GECOS1 es opcional y se utiliza para almacenar información adicional (tal como el nombre completo del usuario). Se pueden almacenar múltiples entradas en este campo, en una lista limitada por comas. Las utilidades como finger acceden a este comando para proporcionar información adicional del usuario.

• Directorio principal — La ruta absoluta al directorio principal del usuario, tal como /home/juan/.

• Shell — El programa lanzado automáticamente cada vez que un usuario se conecta. Usualmente es un intérprete de comandos (a menudo llamado shell). Bajo Red Hat Enterprise Linux, el valor por defecto es /bin/bash. Si se deja este campo en blanco, se utilizará /bin/sh. Si se deja a un archivo que no existe, entonces el usuario no podrá conectarse al sistema.

He aquí un ejemplo de una entrada en /etc/passwd:

root:x:0:0:root:/root:/bin/bash

Esta línea muestra que el usuario root tiene una contraseña shadow, así como también un UID y GID de 0. El usuario root tiene /root/ como directorio principal y utiliza /bin/bash como intérprete de comandos.

Para más información sobre /etc/passwd, consulte la página man de passwd(5).

6.3.2.2. /etc/shadow

Debido a que el archivo /etc/passwd debe ser legible por todo el mundo (la razón principal es que este archivo se utiliza para llevar a cabo la traducción del UID al nombre de usuario), hay un riesgo relacionado en almacenar las contraseña de todo el mundo en /etc/passwd. Cierto, las contraseñas

1. GECOS viene de General Electric Comprehensive Operating Supervisor. Este campo fue utilizado en Bell

Labs, en la implementación original de UNIX. El laboratorio tenia muchas computadoras diferentes, incluyendo

una ejecutando GECOS. Este campo se utilizó para almacenar información cuando el sistema UNIX enviaba

trabajos por lotes o de impresión al sistema GECOS.


estan encriptadas. Sin embargo, es posible realizar ataques contra contraseñas si las contraseñas encriptada están disponibles.

Si un atacante puede obtener una copia de /etc/passwd, este puede llevar a cabo un ataque en secreto. En vez de arriesgar la detección teniendo que intentar un inicio de sesión con cada contraseña potencial generada por un descifrador de contraseñas, el atacante puede utilizar un descifrador de contraseñas de la forma siguiente:

• Un descifrador de contraseñas genera una contraseña potencial

• Cada contraseña potencial es encriptada utilizando el mismo algoritmo que utiliza el sistema

• La contraseña potencial encriptada es comparada con las contraseñas encriptadas en /etc/passwd

El aspecto más peligroso de este ataque es que puede ocurrir en un sistema muy lejos de su organización. Debido a esto, el atacante puede utilizar hardware con el más alto rendimiento disponible, haciendo posible pasar a través de números masivos de contraseñas rápidamente.

Por esta razón, el archivo /etc/shadow solamente está disponible por el usuario root y contiene contraseñas (e información opcional de caducidad) para cada usuario. Como en el archivo /etc/passwd, cada información de usuario está en una línea separada. Cada una de estas líneas es una lista delimitada por dos puntos (:) incluyendo la información siguiente:

• Nombre de usuario — El nombre que el usuario escribe cuando se conecta al sistema. Esto permite que la aplicación login de inicio de sesión, recupere la contraseña del usuario (y la información relacionada).

• Contraseña encriptada — La contraseña encriptada con 13 a 24 carácteres. La contraseña es encriptada usando bien sea la biblioteca de funciones crypt(3) o el algoritmo de hash md5. En este campo, los valores diferentes a una contraseña encriptada o en hash, se utilizan para controlar la conexión del usuario y para mostrar el status de la contraseña. Por ejemplo, si el valor es ! o *, la cuenta es bloqueada y al usuario no se le permite conectarse. Si el valor es !!, nunca se ha establecido una contraseña (y el usuario, como no ha establecido una contraseña, no se podrá conectar).

• Ultima fecha en que se cambió la contraseña — El número de días desde el 1 de enero, 1970 (también conocido como epoch) en que la fecha fue modificada. Esta información es utilizada en conjunto con los campos de caducidad de la contraseña.

• Número de días antes de que la contraseña debe ser modificada — El número mínimo de días que deben pasar antes de que la contraseña se pueda cambiar.

• Número de días antes de que se requiera un cambio de contraseña — El número de días que deben pasar antes de que se deba cambiar la contraseña.

• Número de días de advertencia antes de cambiar la contraseña — El número de días antes que el usuario es notificado de que la contraseña vá a expirar.

• Número de días antes de desactivar la contraseña — El número de días después que una contraseña expira antes de desactivar la cuenta.

• Fecha desde que la cuenta fue desactivada — La fecha (almacenada como el número de días desde epoch) desde que la cuenta del usuario ha sido desactivada.

• Un campo reservado — Un campo que es ignorado en Red Hat Enterprise Linux.

He aquí un ejemplo de una línea de /etc/shadow:

juan:$1$.QKDPc5E$SWlkjRWexrXYgc98F.:12825:0:90:5:30:13096:

Esta línea muestra la información siguiente para el usuario juan:

• La última vez que se cambió la contraseña fue el 11 de febrero, 2005


• No hay in mínimo de tiempo requerido antes de que la contraseña debe ser cambiada

• La contraseña se debe modificar cada 90 días

• El usuario recibirá una notificación cinco días antes de que la contraseña deba ser modificada

• La cuenta será desactivada 30 días después que expire la contraseña si no se realiza ninguna conexión

• La cuenta caduca el 9 de noviembre del 2005

Para más información sobre el archivo /etc/shadow, consulte la página man shadow(5).

6.3.2.3. /etc/group

El archivo /etc/group es un archivo legible por todo el mundo y contiene una lista de los grupos, cada uno en una línea separada. Cada línea es una lista de cuatro campos, delimitados por dos puntos (:) que incluye la información siguiente:

• Nombre del grupo — El nombre del grupo. Utilizado por varios programas de utilidades como un identificador legible para el grupo.

• Contraseña de grupo — Si se configura, esto permite a los usuarios que no forman parte del grupo a unirse a el usando el comando newgrp y escribiendo la contraseña almacenada aquí. Si hay una x minúscula en este campo, entonces se están usando contraseñas shadow.

• ID del grupo (GID) — El equivalente numérico del nombre del grupo. Lo utilizan el sistema operativo y las aplicaciones para determinar los privilegios de acceso.

• Lista de miembros — Una lista delimitada por comas de los usuarios que pertenecen al grupo.

He aquí una línea de ejemplo de /etc/group:

general:x:502:juan,shelley,bob

Esta línea muestra que el grupo general está utilizando contraseñas shadow, tiene un GID de 502, y que juan, shelley y bob son miembros.

Para más información sobre /etc/group, consulte la página man de group(5).

6.3.2.4. /etc/gshadow

El archivo /etc/gshadow es un archivo legible solamente por el usuario root y contiene las contraseñas encriptadas para cada grupo, así como también información de los miembros del grupo y de administración. De la misma forma que en el archivo /etc/group, cada información de grupos está en una línea separada. Cada una de estas líneas es una lista delimitada por símbolos de dos puntos (:) incluyendo la información siguiente:

• Nombre del grupo — El nombre del grupo. Utilizado por varios programas de utilidades como un identificador legible para el grupo.

• Contraseña encriptada — La contraseña encriptada para el grupo. Si está configurada, los que no sean miembros del grupo pueden unirse a este escribiendo la contraseña para ese grupo usando el comando newgrp. Si el valor de este campo es !, entonces ningún usuario tiene acceso al grupo usando el comando newgrp. Un valor de !! se trata de la misma forma que un valor de ! — sin embargo, también indica que nunca se ha establecido una contraseña para el grupo. Si el valor en nulo, solamente los miembros del grupo pueden conectarse al grupo.

• Administradores del grupo — Los miembros del grupo listados aquí (en una lista delimitada por comas) pueden añadir o eliminar miembros del grupo usando el comando gpasswd.


• Miembros del grupo — Los miembros del grupo listados aquí (en una lista delimitada por comas), son miembros normales, no administrativos, del grupo.

He aquí una línea de ejemplo de /etc/gshadow:

general:!!:shelley:juan,bob

Esta línea muestra que el grupo general no tiene contraseña y no permite a los no miembros a unirse al grupo usando newgrp. Además, shelley es el administrador del grupo y juan y bob son miembros normales, no administrativos.

Puesto que la edición manual de estos archivos incrementa las posibilidades de errores sintácticos, se recomienda que se utilicen las aplicaciones suministradas con Red Hat Enterprise Linux para este propósito. La sección siguiente revisa las herramientas principales para realizar estas tareas.

6.3.3. Aplicaciones para Cuentas de Usuarios y Grupos

Hay dos tipos básicos de aplicaciones que se pueden utilizar cuando se administran cuentas de usuarios y grupos en sistemas Red Hat Enterprise Linux:

• La aplicación gráfica Administrador de usuarios

• Un conjunto de herramientas de línea de comandos

Para ver las instrucciones detalladas sobre el uso de Administrador de usuarios, revise el capítulo llamado Configuración de Usuarios y Grupos en el Manual de administración del sistema de Red Hat Enterprise Linux.

Mientras que tanto la aplicación Administrador de usuarios y las utilidades de línea de comandos esencialmente ejecutan la misma tarea, las herramientas de línea de comandos tienen la ventaja de ser de tipo script y por lo tanto más fáciles de automatizar.

La tabla siguiente describe algunas de las herramientas de línea de comandos más utilizadas para crear y administrar cuentas de usuarios y grupos:

Aplicación Función

/usr/sbin/useradd Añade cuentas de usuarios. Esta herramienta también es utilizada para especificar membrecias primaria y secundarias a grupos.

/usr/sbin/userdel Elimina cuentas de usuarios.

/usr/sbin/usermod Modifica los atributos de las cuentas incluyendo algunas funciones relacionadas a la expiración de contraseñas. Para un control más refinado, utilice el comando passwd. También se utiliza usermod para especificar membrecias de grupos primaria y secundaria.

passwd Configura una contraseña. Aunque se utiliza principalmente para modificar la contraseña de un usuario, esta también puede controlar todos los aspectos de la expiración de contraseñas.

/usr/sbin/chpasswd Lee un archivo que consiste de pares de nombres de usuarios y contraseñas, y actualiza cada contraseña de usuario de acuerdo a este.

chage Cambia las políticas de envejecimiento de contraseñas. También se puede utilizar el comando passwd para este propósito.

chfn Cambia la información GECOS de un usuario.



chsh Cambia el intérprete de comandos por defecto de un usuario.

Tabla 6-2. Herramientas de línea de comandos para la Administración de Usuarios

La tabla siguiente describe algunas de las herramientas de línea de comandos más comunes utilizadas para crear u administrar grupos:


/usr/sbin/groupadd Añade grupos, pero no asigna usuarios a estos grupos. Se deben utilizar los programas useradd y usermod para asignar usuarios a un grupo dado.

/usr/sbin/groupdel Elimina grupos.

/usr/sbin/groupmod Modifica nombres de grupos o GIDs, pero no cambia la membrecia del grupo. Se tiene que utilizar useradd y usermod para asignar usuarios a un grupo determinado.

gpasswd Cambia la membrecia de un grupo y configura contraseñas para permitir a los usuarios que no sean miembro que conocen la contraseña, unirse al grupo. También se utiliza para especificar administradores de grupos.

/usr/sbin/grpck Verifica la integridad de los archivos /etc/group y /etc/gshadow.

Tabla 6-3. Herramientas de línea de comandos para Administrar Grupos

Las herramientas listadas proporcionan gran flexibilidad a los administradores de sistemas para controlar todos los aspectos de las cuentas de usuarios y grupos. Para conocer aún más sobre su funcionamiento, consulte sus páginas del manual.

Sin embargo, estas aplicaciones no determinan sobre qué recursos estos usuarios y grupos tienen control. Para esto, el administrador del sistema debe utilizar aplicaciones de permisos de archivos.

6.3.3.1. Aplicaciones de Permisos de Archivos

Los permisos de archivos son una parte integral del manejo de recursos dentro de una organización. La tabla siguiente describe algunas de las herramientas de línea de comandos más comunes para este propósito.


chgrp Cambia el grupo que posee un archivo.

chmod Cambia los permisos de acceso para un archivo dado. Es capaz de asignar permisos especiales.

chown Cambia la propiedad de un archivo (y también puede cambiar el grupo).

Tabla 6-4. Herramientas de línea de comandos para la Administración de Permisos

También es posible alterar estos atributos en los entornos gráficos GNOME y KDE. Pulse con el botón derecho sobre el ícono de un archivo (por ejemplo, mientras se muestra el ícono en un administrador de archivos gráfico o en el escritorio), y seleccione Propiedades.



Esta sección incluye varios recursos que se pueden utilizar para aprender más sobre la administración de cuentas y recursos y la materia específica a Red Hat Enterprise Linux discutida en este capítulo.


Los recursos siguientes son instalados durante el curso de una instalación típica de Red Hat Enterprise Linux y lo pueden ayudar a aprender más sobre la materia discutida en este capítulo.

• La entrada de menú Ayuda de Administrador de usuarios — Conozca cómo manejar cuentas de usuarios y grupos.

• La página man de passwd(5) — Aprenda más sobre el formato de archivo para /etc/passwd.

• La página man de group(5) — Conozca más sobre la información del formato de archivo para /etc/group.

• La página man de shadow(5) — Conozca más sobre la información del formato de archivo para /etc/shadow.

• La página man de useradd(8) — Aprenda cómo crear o actualizar las cuentas de usuario.

• La página man de userdel(8) — Conozca cómo eliminar cuentas de usuarios.

• La página man de usermod(8) — Aprenda a modificar las cuentas de usuarios.

• La página man de passwd(1) — Aprenda a actualizar la contraseña de un usuario.

• La página man de chpasswd(8) — Conozca cómo actualizar las contraseñas de muchos usuarios a la vez.

• La página man de chage(1) — Aprenda a cambiar la información referente a la vigencia de una contraseña.

• La página man de chfn(1) — Vea cómo se puede cambiar la información GECOS de un usuario (finger).

• La página man de chsh(1) — Aprenda a cambiar el intérprete de comandos de conexión de un usuario.

• La página man de groupadd(8) — Para aprender a crear un nuevo grupo.

• La página man de groupdel(8) — Aprenda a borrar un grupo.

• La página man de groupmod(8) — Aprenda a modificar un grupo.

• La página man de gpasswd(1) — Aprenda a administrar los archivos /etc/group y /etc/gshadow.

• La página man de grpck(1) — Le muestra cómo verificar la integridad de los archivos /etc/group y /etc/gshadow.

• La página man de chgrp(1) — Para aprender a cambiar la propiedad a nivel de grupo.

• La página man de chmod(1) — Le muestra cómo cambiar los permisos de acceso a archivos.

• La página man de chown(1) — Conozca cómo cambiar el dueño y grupo de un archivo.


• http://www.bergen.org/ATC/Course/InfoTech/passwords.html — Un buen ejemplo de un documento que reune información sobre la seguridad de contraseñas para los usuarios en una organización.


• http://www.crypticide.org/users/alecm/ — La página principal del autor de uno de los programas de descifrado de contraseñas más populares (Crack). Puede descargar Crack desde esta página y verificar cuantos de sus usuarios tienen contraseñas débiles.

• http://www.linuxpowered.com/html/editorials/file.html — Una buena descripción general de los permisos de archivos en Linux.


Los libros siguientes describen varios problemas relacionados a la administración de cuentas y recursos y son buenas fuentes para los administradores de sistemas Red Hat Enterprise Linux.

• El Manual de seguridad de Red Hat Enterprise Linux; Red Hat, Inc. — Proporciona una descripción general de los aspectos relacionados a la seguridad de las cuentas de usuarios y a escoger contraseñas robustas.

• El Manual de referencia de Red Hat Enterprise Linux; Red Hat, Inc. — Contiene información detallada sobre los usuarios y grupos presentes en Red Hat Enterprise Linux.

• El Manual de administración del sistema de Red Hat Enterprise Linux; Red Hat, Inc. — Incluye un capítulo sobre la configuración de usuarios y grupos.

• Linux Administration Handbook por Evi Nemeth, Garth Snyder, y Trent R. Hein; Prentice Hall — Proporciona un capítulo sobre el mantenimiento de cuentas de usuarios, una sección sobre seguridad pues se relaciona a los archivos de cuentas de usuarios, y una sección sobre atributos de archivos y permisos.

Capítulo 7. Impresoras e impresión

Las impresoras son un recurso esencial para la creación de una copia impresa — una representación física de los datos en papel — la versión de los documentos para negocios, academia y uso en el hogar. Las impresoras se han convertido un periférico indispensable en todos los niveles de negocios y computación institucional.

Este capítulo discute las diferentes impresoras disponibles y compara sus usos en diferentes ambientes computacionales. Luego describe cómo se maneja la impresión en Red Hat Enterprise Linux.

7.1. Tipos de impresoras

Como cualquier otro periférico, existen diferentes tipos de impresoras. Algunas impresoras emplean tecnologías que imitan la funcionalidad de las máquinas de escribir manuales, mientras que otras rocían tinta en el papel, o utilizan un láser para generar una imagen de la página impresa. Las impresoras se conectan con el hardware de PC o red utilizando protocolos paralelos, seriales o de datos de red. Existen varios factores a considerar cuando se evalúan impresoras para adquirir e instalar en su entorno computacional.

Las secciones siguientes discuten los diferentes tipos de impresoras y los protocolos que estas utilizan para comunicarse con las computadoras.

7.1.1. Consideraciones de impresión

Existen varios factores a considerar en las evaluaciones de impresoras. Lo siguiente especifica algunos de los criterios más comunes cuando se evalúan las necesidades computacionales.

7.1.1.1. Función

La evaluación de sus necesidades organizacionales y cómo una impresora sirve esas necesidades en un criterio esencial para determinar el tipo correcto de impresora para su ambiente. La pregunta más importante es "¿Qué necesitamos imprimir?." Puesto que hay impresoras especializadas para texto, imágenes o cualquier variación en medio, debe estar seguro de que adquiere la herramienta adecuada para sus propósitos.

Por ejemplo, si sus requerimientos son de alta calidad de imágenes a color en papel brillante de grado profesional, se recomienda que utilice una impresora de sublimación de tinte o de transferencia de color de cera térmica en vez de una impresora láser o de impácto.

Recíprocamente, las impresoras láser o de inyección de tinta son adecuadas para la impresión de borradores o documentos de distribución interna (tales impresoras con altos volúmenes de impresión se llaman impresoras de grupo de trabajo). Determinar las necesidades del usuario común permite a los administradores determinar la impresora correcta para el trabajo.

Otros factores a considerar son funcionalidades tales como duplexing — la habilidad de imprimir en ambos lados de una hoja de papel. Tradicionalmente, las impresoras solamente imprimen en un lado de la página (llamado impresión simplex). La mayoría de los modelos más económicos no tienen la funcionalidad de dúplex por defecto (sin embargo, puede que tengan un método dúplex manual que requiere que el usuario voltee la página). Algunos modelos ofrecen hardware que se puede añadir para permitir esta funcionalidad; estos complementos de hardware pueden incrementar los costos considerablemente. Sin embargo, la impresión en dúplex con el tiempo puede reducir los costos considerablemente, al reducir la cantidad de papel utilizado para imprimir documentos, y por ende, reduciendo los costos de consumibles — principalmente papel.

144 Capítulo 7. Impresoras e impresión

Otro factor a considerar es el tamaño del papel. La mayoría de las impresoras son capaces de manejar los tamaños de papel más comunes:

• carta — (8 1/2" x 11")

• A4 — (210mm x 297mm)

• JIS B5 — (182mm x 257mm)

• legal — (8 1/2" x 14")

Si ciertos departamentos (tales como mercadeo o diseño) tienen necesidades especializadas como la creación de posters o banners, existen impresoras de formato grande que son capaces de utilizar tamaños de papel A3 (297mm x 420mm) o tabloide (11" x 17"). Además, hay impresoras capaces de tamaños aún mayores, aunque estas se utilizan para propósitos especiales, tales como la impresión de huellas digitales.

Adicionalmente, durante la evaluación también se deben considerar funcionalidades más avanzadas,tales como módulos de redes para trabajo en grupo e impresión remota.

7.1.1.2. Costo

El costo es otro factor a considerar cuando se evalúen impresoras. Sin embargo, el determinar el costo único asociado con la compra de la impresora misma no es suficiente. Existen otros costos a considerar, tales como los consumibles,repuestos, mantenimiento y los complementos de hardware.

Como el nombre implica, los consumibles es el término general utilizado para describir el material utilizado durante el proceso de impresión. Los consumibles principalmente toman la forma de media y tinta.

La media es el material en el cual el texto o imagen es impreso. La selección de la media depende en gran medida del tipo de información que se imprime.

Por ejemplo, la creación de una impresión exacta de una imagen digital requiere un papel brillante especial que pueda soportar la exposición prolongada a la luz natural o artificial, así como también asegurar la reproducción exacta del color, estas cualidades son conocidas como resistencia del color. Para documentos con calidad de archivado que requieren durabilidad y un nivel de legibilidad profesional (tal como contratos, hojas de vida y otros registros permanentes), se debería utilizar un papel mate (o sin brillo). También es importante el grueso del papel, ya que algunas impresoras tienen una bandeja de papel que no es derecha. El uso de papel que es muy delgado o demasiado grueso, puede causar obstrucciones. Algunas impresoras también pueden imprimir en transparencias, permitiendo que la información se pueda proyectar en una pantalla durante una presentación.

La media especializada, tal como la que mencionamos aquí, puede afectar el costo de los consumibles y se debería tomar en consideración cuando se evalúen las necesidades de impresión.

La tinta es un término generalizado, ya que no todas las impresoras utilizan tinta líquida. Por ejemplo, las impresoras láser utilizan un polvo conocido como toner, mientras que las de impacto utilizan cintas saturadas de tinta. Hay impresoras especializadas que calientan la tinta durante el proceso de impresión, mientras que otras rocían pequeñas gotas de tinta sobre la media. Los costos de reemplazo de tinta varían ampliamente y van a depender de si el contenedor de la tinta puede ser recargado o si requiere un reemplazo completo del cartucho.

7.2. Impresoras de impacto

Las impresoras de impacto son la tecnología más antigua en producción activa. Algunos de los fabricantes más grandes continuan produciendo, mercadeando y dando asistencia a las impresoras de

Capítulo 7. Impresoras e impresión 145

impacto, partes y suministros. Las impresoras de impacto son las más funcionales en ambientes especializados donde los bajos costos de impresión son esenciales. Las tres formas más comunes de impresoras de impacto son matriz de puntos, margarita e impresoras en línea.

7.2.1. Impresoras de matriz de puntos

La tecnología detrás de las impresoras de matriz de puntos en bien simple. Se presiona el papel contra un tambor (un cilindro cubierto con una goma) y y es constantemente empujado a medida que prograsa la impresión. El cabezal de impresión movido electromagnéticamente se mueve a lo largo del papel y golpea la cinta de impresión situada entre el papel y el pin del cabezal de impresión. El impacto del cabezal contra la cinta imprime puntos de tinta en el papel lo que forma los carácteres legibles.

Las impresoras de matriz de puntos varían en resolución de impresión y calidad en general con 9 o 24 pines en los cabezales de impresión. Mientras más pines por pulgada, más alta la resolución de impresión. La mayoría de las impresoras de matriz de puntos tienen una resolución máxima de alrededor de 240 dpi o puntos por pulgada (en inglés, dots per inch). Mientras esta resolución no es tan alta como las que se pueden obtener con las impresoras de inyección de tinta o láser, hay una ventaja distintiva en las impresoras de impacto. Debido a que el cabezal de impresión debe golpear la superficie del papel con fuerza suficiente como para transferir la tinta desde la cinta hasta el papel, es ideal para ambientes que deben producir copias al carbón en documentos con múltiples partes. Estos documentos tienen carbón (u otro material sensible a la presión) en el lado interno y crea una marca en la página de abajo cuando se aplica presión. Los vendedores al detal y los pequeños negocios a menudo utilizan copias al carbón como recibos o facturas de ventas.

7.2.2. Impresoras margarita

Si ha trabajado con una máquina de escribir anteriormente, entonces entiende el concepto tecnológico subyacente en las impresoras de margarita. Estas impresoras tienen cabezales compuestos de ruedas metálicas o plásticas cortadas en pétalos. Cada pétalo tiene la forma de una letra (en mayúsculas y minúsculas), número o símbolo de puntuación. Cuando se golpea el pétalo contra la cinta de impresión, la forma resultante forza la tinta al papel. Las impresoras de margarita son ruidosas y lentas. No pueden imprimir gráficos y no pueden cambiar las fuentes tipográficas a menos que se reemplace físicamente la rueda de impresión. Con la llegada de las impresoras láser, las impresoras de margarita no son comunes en los ambientes computacionales modernos.

7.2.3. Impresoras en línea

Otro tipo de impresoras de impacto, de alguna manera similares a las impresoras de margarita, son las impresoras de línea. Sin embargo, en vez de una rueda de impresión, las impresoras de línea tienen un mecanismo que permite imprimir múltiples caracteres en la misma línea. El mecanismo puede utilizar un tambor de impresión grande que gira o una cadena de impresión rotativa. Cuando la cadena o el tambor rotan sobre la superficie del papel, los martillos electromagnéticos detrás del papel empujan el papel (junto con la cinta) en la superficie del tambor o cadena, marcando el papel con la forma del carácter en el tambor o cadena.

Debido a la naturaleza del mecanismo de impresión, las impresoras de línea son mucho más rápidas que las de matriz de puntos o de margarita. Sin embargo, tienden a ser bastante ruidosas, tienen capacidades limitadas para utilizar multiples fuentes tipográficas y a menudo producen calidad de impresión más baja que las tecnologías de impresión más recientes.

Debido a que las impresoras de línea son utilizadas por su velocidad, emplean papel de hojas continuas con perforaciones a los lados. Este arreglo permite la impresión continua a altas velocidades y desatendida, requiriendo paradas solamente cuando se acaba el papel.


7.2.4. Consumibles para las impresoras de impacto

De todos los tipos de impresoras, las impresoras de impacto tienen costos de consumibles relativamente bajos. Las cintas de impresora y el papel son los principales costos para estas impresoras. Algunas impresoras de impacto (usualmente las de matriz y de línea) requieren papel de hojas contínuas, lo cual puede incrementar un poco los costos de operación.

7.3. Impresoras de inyección de tinta

Una impresora de inyección de tinta utiliza una de las tecnologías de impresión más populares hoy en día. Los costos relativamente bajos y las habilidades de impresión de propósito múltiple hacen de las impresoras de inyección de tinta una buena selección para los pequeños negocios y las oficinas en casa.

Las impresoras de inyección de tinta utilizan una tinta que se seca rápidamente, basada en agua y un cabezal de impresión con series de pequeñas inyectores que rocían tinta a la superficie del papel. El ensamblado de impresión es conducido por un motor alimentado por una correa que mueve el cabezal a lo largo del papel.

Las impresoras de inyección de tinta fueron fabricadas originalmente para imprimir solamente en monocromático (blanco y negro). Sin embargo, desde entonces el cabezal se ha expandido y las boquillas se han incrementado para incluir cyan, magenta, amarillo y negro. Esta combinación de colores (llamada CMYK) permite la impresión de imágenes con casi la misma calidad de un laboratorio de revelado fotográfico (cuando se utilizan ciertos tipos de papel). Cuando se combina con una calidad de impresión clara y de gran calidad de lectura, las impresoras de inyección de tinta se convierten en la selección de todo en uno para las necesidades de impresión monocromáticas y a color.

7.3.1. Consumibles de inyección de tinta

Las impresoras de inyección de tinta tienden a ser económicas y van aumentando de precio basado en la calidad de impresión, funcionalidades adicionales y la habilidad para imprimir en formatos más grandes que los tamaños de papel estándar carta o legal. Mientras que el costo inicial de la compra de una impresora de inyección de tinta es menor que el de otros tipos de impresora, se debe considerar el factor de los consumibles. Puesto que la demanda para las impresoras de inyección de tinta es grande y se extiende desde el hogar a la empresa, la adquisición de consumibles puede ser costosa.

Nota

Cuando esté seleccionando una impresora de inyección de tinta para la compra, siempre asegurese de saber el tipo de cartucho de tinta que requiere. Esto es muy importante sobre todo para las unidades de color. Las impresoras de inyección de tinta CMYK requieren tinta para cada color; sin embargo, el punto aquí es si cada color es almacenado en un cartucho separado o no.

Algunas impresoras utilizan un cartucho de cámaras múltiples; a menos de que se tenga algún tipo de proceso de relleno, tan pronto como un color se acaba, se debe reemplazar el cartucho completo. Otras impresoras utilizan cartuchos con múltiples cámaras para cyan, magenta y amarillo, pero también tienen un cartucho separado para el negro. En ambientes donde se imprime grandes cantidades de texto, este tipo de arreglo puede ser beneficioso. Sin embargo, la mejor solución es encontrar una impresora con cartuchos separados para cada color; así, puede reemplazar fácilmente un color particular cuando este se termine.

Algunos fabricantes de impresoras de inyección de tinta también requieren utilizar papel tratado de alguna forma particular para imprimir imágenes y documentos de alta calidad. Algunos tipos de papel utilizan una capa con una fórmula de alto brillo para absorber rápidamente las tintas de color, lo


que evita que se hagan grumos (acumulaciones de tinta basada en agua en ciertas áreas donde se mezclan los colores, causando manchas de tinta seca) o bandas (donde la salida de la impresora tiene un patrón de líneas extrañas). Consulte la documentación de su impresora para ver la lista de papeles recomendados.

7.4. Impresoras láser

Otra alternativa común son las impresoras láser, una tecnología más vieja que la de inyección de tinta. Las impresoras láser son conocidas por su alto volumen de salida y sus bajos costos por página. Las impresoras láser son empleadas a menudo en compañías como centros de impresión departamentales o de grupos de trabajo, donde la durabilidad, rendimiento y los requerimientos de salida son la prioridad. Como las impresoras láser satisfacen fácilmente estas necesidades (y a un costo por página razonable), esta tecnología es ampliamente utilizada como el caballo de batalla en la impresión empresarial.

Las impresoras láser comparten bastante de la tecnología de las fotocopiadoras. Los rodillos jalan una hoja de papel desde una bandeja de papel y a través de un rodillo cargador, el cual le dá al papel una carga electrostática. Al mismo tiempo, un tambor de impresión le dá la carga contraria. La superficie del tambor es escaneada luego por el láser, descargando la superficie del tambor y solamente dejando esos puntos correspondientes al texto deseado e imagen con una carga. Esta carga es luego utilizada para forzar el toner a adherirse a la superficie del tambor.

El papel y el tambor se ponen en contacto; sus diferentes cargas hacen que el toner se pegue al papel. Finalmente, el papel viaja a través de los rodillos de fusión, los cuales calientan el papel y derriten el toner, juntándolo con la superficie del papel.

7.4.1. Impresoras a color láser

Las impresoras láser a color tienen como objetivo combinar las mejores características de la tecnología láser y de inyección de tinta en un paquete de propósito múltiple. La tecnología está basada en la impresión tradicional monocromática, pero utiliza componentes adicionales para crear imágenes y documentos a color. En vez de utilizar solamente un toner negro, las impresoras láser utilizan un toner con una combinación CMYK. El tambor de impresión rueda cada color y coloca el toner un color a la vez; o, coloca los cuatro colores en un plato y luego los pasa al papel a través del tambor, transfiriendo la imagen completa en el papel. Las impresoras láser a color también emplean un aceite de fusión junto con los rodillos de fusión calentados, lo cual junta aún más el color del toner al papel y proporciona diferentes niveles de brillo a la imagen final.

Debido a sus funcionalidades adicionales, las impresoras láser a color son usualmente el doble de costosas (o a veces más) que las impresoras láser monocromáticas. Al calcular el costo total de propiedad con respecto a los recursos de impresión, algunos administradores pueden desear separar la funcionalidad monocromática (texto) y color (imagen) a una impresora láser monocromática dedicada y una a láser a color (o de inyección de tinta) respectivamente.

7.4.2. Consumibles para impresoras láser

Dependiendo del tipo de impresora láser instalada, los costos de consumibles son usualmente proporcionales al volumen de impresión. El toner viene en cartuchos que son inmediatamente reemplazados; sin embargo, algunos modelos vienen con cartuchos recargables. Las impresoras láser a color requieren de un cartucho para cada uno de los cuatro colores. Adicionalmente, las impresoras a color requieren el uso de aceites de fusión para sellar el toner con el papel y botellas de desecho para capturar los botes de toner. Estos suministros adicionales aumentan los costos de las impresoras láser a color; sin embargo, esto no es nada si se compara con su duración de aproximadamente 6000 páginas, lo que es mucho más que la vida útil de las impresoras de inyección de tinta o de impacto. El tipo de papel es menos relevante con las impresoras láser, lo que significa que la compra en cantidades de papel xerográfico normal o de fotocopias, es aceptable para la mayoría de los trabajos de impresión.


Sin embargo, si tiene pensado imprimir imágenes de alta calidad, debería optar por papel brilllante para lograr una apariencia más profesional.

7.5. Otros tipos de impresoras

Existen otros tipos de impresoras disponibles, sobre todo impresoras de propósito específico para gráficos profesionales u organizaciones de publicidad. Sin embargo, estas impresoras no son de propósito general. Puesto que están destinadas a un uso muy particular, sus precios (tanto de compra inicial como de consumibles) tienden a ser relativamente más altos que las unidades más comunes.

Impresoras de cera termal

Estas impresoras son utilizadas principalmente para transparencias de presentaciones de negocios y para pruebas de color (creación de documentos e imágenes de prueba para una inspección más en detalle antes de enviar el documento principal a la impresión industrial). Las impresoras de cera termal utilizan cintas CMYK conducidas por correas del tamaño de una hojas de papel y papel con una capa especial o transparencias. El cabezal de impresión contiene elementos de calentamiento que derriten cada cera de color en el papel a medida que se rueda sobre la impresora.

Impresoras de sublimación de tinte

Utilizada en organizaciones tales como oficinas de servicios — donde la calidad profesional de los documentos, pamfletos y presentaciones, es más importante que los costos de los consumibles — las impresoras de sublimación de tinte son los caballos de batalla para la impresión CMYK de calidad. Los conceptos detrás de las impresoras de sublimación son similares a los de las impresoras de cera termal excepto por el uso de una película de tinte de difusión plástica en vez de cera de color. El cabezal de impresión calienta la película coloreada y vaporiza la imagen en el papel especialmente cubierto.

Las impresoras de sublimación son bastante populares en el mundo de diseño y publicidad así como también en el campo de investigación científica, donde se requiere precisión y detalles. Por supuesto, tal detalle y calidad de impresión viene a un precio: las impresoras de sublimación de tinte son también conocidas por sus altos costos por página.

Impresoras de tinta sólida

Utilizadas principalmente en la industria de empaquetamiento y diseño, las impresoras de tinta sólida están valoradas por su habilidad para imprimir en una amplia variedad de tipos de papel. Las impresoras de tinta sólida, como su nombre lo implica, utilizan palillos de tinta endurecida que son derretidos y rociados a través de pequeñas boquillas en el cabezal de impresión. El papel es luego enviado a través de un rodillo fusor que fuerza la tinta al papel.

La impresora de tinta sólida es ideal para prototipos y borradores de nuevos diseños para paquetes de productos; como tal, la mayoría de los negocios orientados a servicios no tienen la necesidad de este tipo de impresoras.

7.6. Lenguajes y tecnologías de impresión

Antes de la llegada de la tecnología de inyección de tinta, las impresoras de impacto solamente podían imprimir texto estándar, justificado y sin variaciones de tamaños o estilos de fuentes tipográficas. Hoy día, las impresoras son capaces de procesar documentos complejos con imágenes incrustadas, gráficos y tablas en múltiples esquemas y en diferentes idiomas, todo en una página. Tal complejidad se debe adherir a algunas convenciones de formatos. Esto es lo que ha desatado el desarrollo de los lenguajes de descripción de páginas (o PDL) — un lenguaje especializado de formato de documentos creado para la comunicación con impresoras.


Con el paso de los años, los fabricantes de impresoras han desarrollado sus propios lenguajes propietarios para describir formatos de documentos. Sin embargo, tales lenguajes propietarios solamente aplican a las impresoras que los fabricantes mismos crearon. Si por ejemplo, usted tuviese que enviar un archivo listo para la impresión usando un PDL propietario a un periódico profesional, no había ninguna garantía de que su archivo fuese compatible con la impresora de la máquina. Aparece entonces el problema de portabilidad.

Xerox® desarrolló el protocolo Interpress™ para sus impresoras de línea, pero nunca se logró la adopción completa de este lenguaje por el resto de la industria de impresoras. Dos desarrolladores de Interpress dejaron Xerox y formaron Adobe®, una compañía de software orientada básicamente a los gráficos electrónicos y documentos profesionales. En Adobe, ellos desarrollaron un PDL ampliamente adoptado llamado PostScript™, el cual utiliza un lenguaje de marcas para describir el formato de texto y la información de imágenes que las impresoras pueden procesar. Al mismo tiempo, la compañía Hewlett-Packard® desarrolló el Printer Control Language™ (o PCL) para su uso en su línea de impresoras láser y de inyección de tinta. PostScript y PCL son hoy día PDLs ampliamente compatibles y adoptados por la mayoría de los fabricantes de impresoras.

Los PDLs funcionan con el mismo principio que los lenguajes de programación. Cuando un documento está listo para la impresión, la PC o estación de trabajo toma las imágenes, la información tipográfica y la distribución del documento, y los utiliza como objetos que forman instrucciones para que la impresora los procese. La impresora luego traduce estos objetos en rasters, una serie de líneas escaneadas que forman una imagen del documento (llamado Raster Image Processing o RIP), e imprime la salida en la página como una imagen completa con texto y gráficos incluidos. Este proceso hace los documentos impresos más consistentes, resultando en ninguna o muy poca variación cuando se imprime el documento en modelos diferentes de impresoras. Los PDLs están diseñados para ser portables en cualquier formato y escalable para ajustarse a cualquier tamaño de papel.

La selección de la impresora correcta es una cuestión de determinar los estándares que los diferentes departamentos en su organización han adoptado para sus necesidades. La mayoría de los departamentos utilizan procesadores de texto y otros software de productividad que utilizan el lenguaje PostScript para la salida de impresión. Sin embargo, si su departamento de gráficos requiere PCL u otra forma de impresión propietaria, debe tomar esto en consideración también.

7.7. Impresión de red Versus Impresión local Dependiendo de las necesidades de su organización, puede ser innecesario asignar una impresora a cada miembro de su organización. Tal solapamiento en gastos puede comer un presupuesto, dejando poco capital para otras necesidades. Mientras que las impresoras locales conectadas a través de cable paralelo o USB a cada estación de trabajo son la solución ideal para cada usuario, usualmente no es económico ni factible.

Los fabricantes de impresoras han solucionado esta necesidad desarrollando impresoras departmentales (o de grupos de trabajo). Estas máquinas son usualmente durables, rápidas y tienen consumibles con larga durabilidad. Las impresoras de grupos de trabajo están conectadas a un servidor de impresión, un dispositivo independiente (tal como una estación de trabajo reconfigurada) que maneja los trabajos de impresión y los enruta a la impresora adecuada cuando está disponible. Las impresoras departamentales más recientes incluyen interfaces de red incorporadas que eliminan la necesidad de un servidor de impresión dedicado.

7.8. Información específica de Red Hat Enterprise Linux

Lo siguiente describe las diferentes funcionalidades específicas a Red Hat Enterprise Linux relacionadas con impresoras e impresión.

La Herramienta de configuración de impresoras permite a los usuarios configurar una impresora. Esta herramienta ayuda a mantener el archivo de configuración de la impresora, los directorios spool de impresión y los filtros de impresión.


Red Hat Enterprise Linux 4 utiliza el sistema de impresión CUPS. Si un sistema fue actualizado desde una versión anterior de Red Hat Enterprise Linux que usaba CUPS, el proceso de actualización mantiene las colas configuradas.

Para usar la Herramienta de configuración de impresoras debe tener privilegios como root. Para iniciar la aplicación, seleccione Botón de menú principal (en el Panel) => Configuración del sistema => Impresión, o escriba el comando syste-config-printer. Este comando determina automáticamente si ejecutará la versión gráfica o la versión basada en texto dependiendo de si el comando es ejecutado desde el ambiente gráfico o desde una consola basada en texto.

Puede forzar a la Herramienta de configuración de impresoras a ejecutarse como una aplicación basada en texto, utilice el comando system-config-printer-tui desde el intérprete de comandos.

Importante

No modifique el archivo /etc/printcap o los archivos en el directorio /etc/cups/. Cada vez que el demonio de impresión (cups) es iniciado o reiniciado, se crean dinámicamente nuevos archivos de configuración. Los archivos también son creados dinámicamente cuando se aplican cambios con la Herramienta de configuración de impresoras.

Figura 7-1. Herramienta de configuración de impresoras

Se pueden configurar los siguientes tipos de colas de impresión:

• Conectada-localmente — una impresora directamente conectada al computador a través de un puerto paralelo o USB.

• Conectada CUPS (IPP) — una impresora que puede ser accesada sobre una red TCP/IP a través del protocolo de impresión de Internet, también conocido como IPP (por ejemplo, una impresora conectada a otro sistema Red Hat Enterprise Linux corriendo CUPS en la red).

• Conectada UNIX (LPD) — una impresora conectada a un sistema UNIX diferente que puede ser accesada sobre una red TCP/IP (por ejemplo, una impresora conectada a otro sistema Red Hat Enterprise Linux corriendo LPD en la red).

• Conectada Windows (SMB) — una impresora conectada a un sistema diferente el cual está compartiendo una impresora sobre una red SMB (por ejemplo, una impresora conectada a una máquina Microsoft Windows™).

• Conectada Novell (NCP) — una impresora conectada a un sistema diferente el cual usa la tecnología de red Novell NetWare.


• Conectada JetDirect — una impresora connectada directamente a la red a través de HP JetDirect en vez de a un computador.

Importante

Si agrega una nueva cola de impresión o modifica una existente, debe aplicar los cambios para que tomen efecto.

Al hacer click en el botón Aplicar guarda cualquier cambio que haya realizado y reinicia el demonio de impresión. Los cambios no son escritos al archivo de configuración hasta que el demonio de impresión no sea reiniciado. Alternativamente, puede seleccionar Acción => Aplicar.

Para más información sobre la configuración de impresoras bajo Red Hat Enterprise Linux consulte el Manual de administración del sistema de Red Hat Enterprise Linux.


La configuración de impresoras y la impresión en redes son tópicos amplios que requieren conocimiento y experiencia en hardware, redes y administración de sistemas. Para información más detallada sobre la instalación de servicios de impresión en su entorno, consulte los recursos siguientes.


• La página man de lpr(1) — Conozca cómo imprimir archivos seleccionados en la impresora de su selección.

• La página man de lprm(1) — Aprenda a eliminar trabajos de impresión de una cola de impresión.

• La página man de cupsd(8) — Conozca un poco más sobre el demonio de impresión CUPS.

• La página man de cupsd.conf(5) — Aprenda sobre el formato del archivo de configuración del demonio CUPS.

• La página man de classes.conf(5) — Conozca más sobre el formato para el archivo de configuración de clases CUPS.

• Archivos en /usr/share/doc/cups- � version � — Más información sobre el sistema de impresión CUPS.


• http://www.webopedia.com/TERM/p/printer.html — Definiciones generales de impresoras y descripciones de los tipos de impresoras.

• http://www.linuxprinting.org/ — Una base de datos de documentos sobre impresión, junto con una base de datos de casi 1000 impresoras compatibles con las facilidades de impresión de Linux.

• http://www.cups.org/ — Documentación, FAQs, y grupos de noticias sobre CUPS.



• Network Printing por Matthew Gast y Todd Radermacher; O’Reilly & Associates, Inc. — Información completa sobre el uso de Linux como servidor de impresión en entornos heterogéneos.

• El Manual de administración del sistema de Red Hat Enterprise Linux; Red Hat, Inc. — Incluye un capítulo sobre la configuración de impresoras.

Capítulo 8. Planificación para Desastres

La planificación para desastres es fácil de olvidar para un administrador de sistemas — no es agradable y siempre pareciera que hay algo más importante que hacer. Sin embargo, dejar pasar la planificación para desastres es una de las peores cosas que un administrador de sistemas puede hacer.

Aunque a menudo se trata de los desastres dramáticos (tales como un incendio, una inundación o tormenta) lo que primero viene a la mente, los problemas más mundanos (tales como que unos contructores corten los cables por accidente o un lavamanos que esté botando agua) pueden ser igualmente destructivos. Por lo tanto, la definición de un desastre que un administrador debe tener en mente, es cualquier evento no planeado que pueda interrumpir la operación normal de la organización.

Aunque sería imposible listar todos los tipos diferentes de desastres que podrían ocurrir, esta sección examina los factores principales que forman parte de cada tipo de desastre para que asi cualquier exposición a un desastre se pueda examinar no en términos de su posibilidad, pero si de los factores que podrían llevar a un desastre.

8.1. Tipos de desastre

En general, hay cuatro tipos de factores diferentes que pueden disparar un desastre. Estos factores son:

• Fallas del hardware

• Fallas del software

• Fallas ambientales

• Errores humanos

8.1.1. Fallas del hardware

Las fallas de hardware son fáciles de entender - el hardware falla y el trabajo se detiene. Lo que es más dificil de entender es la naturaleza de las fallas y cómo se puede minimizar su exposición a ellas. He aquí algunos enfoques que puede utilizar:

8.1.1.1. Mantener partes adicionales de hardware

En su forma más simple, las exposiciones debidas a fallas del hardware se pueden reducir manteniendo repuestos de hardware adicionales. Por supuesto, este enfoque asume dos cosas:

• Alguien está en el sitio con suficientes habilidades para diagnosticar el problema, identificar la parte defectuosa y reemplazarla.

• Está disponible un repuesto para el hardware defectuoso.

Estos problemas se cubren con más detalles en las secciones siguientes.

8.1.1.1.1. Tener las habilidades

Dependiendo de sus experiencias pasadas y del hardware relacionado, el tener las habilidades necesarias puede que no sea un problema. Sin embargo, si no ha trabajado con hardware anteriormente, puede considerar buscar en los colegios

154 Capítulo 8. Planificación para Desastres

Sugerencia

Antes de tomar este enfoque de reparar las cosas ud mismo, asegurese de que el hardware:

• No se encuentra bajo garantía

• No está bajo ningún contrato de servicio/mantenimiento

Si usted trata de reparar un hardware que se encuentra cubierto por una garantía o contrato de servicio, lo más probable es que estará violando los términos del acuerdo y estará poniendo en peligro su cobertura.

Sin embargo, aún con las habilidades mínimas, puede ser posible diagnosticar efectivamente y reemplazar un hardware defectuoso — si selecciona cuidadosamente sus repuestos.

8.1.1.1.2. ¿Qué cosas tener en almacén?

Esta pregunta ilustra la naturaleza multifacética de las cosas relacionadas con desastres. Cuando considere qué repuestos tener en almacén, he aquí algunas de las cosas que debe tener en mente:

• Tiempo máximo permitido fuera de servicio

• La habilidad requerida para hacer la reparación

• El presupuesto disponible para los repuestos

• Espacio de almacenamiento requerido para los repuestos

• Otro hardware que podría utilizar el mismo repuesto

Cada uno de estos problemas tiene una trascendencia en los tipos de repuestos que se deberían guardar en almacén. Por ejemplo, al almacenar sistemas completos se tiende a reducir el tiempo fuera de servicio y requiere habilidades mínimas para instalar, pero sería muchísimo más costoso que tener un CPU y un módulo RAM de repuestos. Sin embargo, este costo puede ser justificado si su organización tiene varias docenas de servidores idénticos que se podríanbeneficiar de tener un sistema adicional de repuesto.

No importa cual sea la decisión final, la pregunta siguiente es inevitable y se discute a continuación.

8.1.1.1.2.1. ¿Cuánto guardar en almacén?

La pregunta de los niveles de repuestos es también multifacética. He aquí los principales problemas:

• Tiempo máximo permitido fuera de servicio

• Tasa de fallas proyectada

• Tiempo estimado de reemplazo del repuesto

• El presupuesto disponible para los repuestos

• Espacio de almacenamiento requerido para los repuestos

• Otro hardware que podría utilizar el mismo repuesto

En un extremo, para un sistema que puede permitirse estar fuera de servicio dos días y una parte que puede ser utilizada una vez en un año y que se puede reemplazar en un día, tendría sentido guardar solamente un repuesto (y quizás hasta ninguno, si tiene confianza de su habilidad de asegurar un repuesto en 24 horas).

Capítulo 8. Planificación para Desastres 155

Por otro lado, un sistema que no se puede permitir estar fuera de servicio más que unos pocos minutos, y un repuesto que podría utilizarse una vez al mes (y que podría tomar semanas en reemplazar) podría significar que se necesiten media docena de repuestos (o quizás más).

8.1.1.1.3. Repuestos que no son repuestos

¿Cuándo un repuesto no es un repuesto? Cuando es hardware que se utiliza día a día pero que también está disponible como repuesto para un sistema de mayor prioridad, si surge la necesidad. Este enfoque tiene sus beneficios:

• Menos dinero dedicado a repuestos "no productivo"

• Se sabe que el hardware funciona

Sin embargo, este enfoque tiene sus desventajas:

• La producción normal de la tarea de menor prioridad es interrumpida

• Hay una exposición si la tarea de menor prioridad falla (no dejando ningún repuesto para el hardware de mayor prioridad)

Dadas estas limitaciones, el uso de otro sistema en producción como un repuesto puede funcionar, pero el éxito de este enfoque depende de la carga de trabajo específica del sistema y del impacto de la ausencia del sistema en las operaciones generales de la organización.

8.1.1.2. Contratos de servicios

Los contratos de servicios pasan el problema de las fallas de hardware a alguien más. Lo único que necesita hacer es confirmar que ha ocurrido una falla y que no parece estar relacionado a un problema de software. Usted simplemente hace la llamada y alguien más aparece para encargarse de que las cosas esten en funcionamiento otra vez

Parece muy simple. Pero como con la mayoría de las cosas en la vida, hay mucho más de lo que el ojo puede ver. He aquí algunas cosas que debería considerar cuando esté revisando contratos de servicios:

• Horas de cobertura

• Tiempo de respuesta

• Partes disponibles

• Presupuesto disponible

• Hardware cubierto

Exploramos cada uno de estos detalles más de cerca en las secciones siguientes.

8.1.1.2.1. Horas de cobertura

Hay diferentes contratos de servicios disponibles para satisfacer necesidades diferentes; una de las grandes variables entre los contratos se relaciona con las horas de cobertura. A menos que esté dispuesto a pagar un contrato premium por ese privilegio, usted no puede simplemente llamar a la hora que quiera y esperar a que unos pocos minutos después aparezca un técnico en la puerta.

En vez de esto, dependiendo de su contrato, quizás ni siquiera pueda llamar a la compañía si no en un día/hora específica, o si puede, probablemente no envíen un técnico hasta la hora o fecha que está especificado en su contrato.


La mayoría de las horas de cobertura son definidas en términos de las horas y los días durante los cuales se puede enviar un técnico. Algunas de las horas de cobertura más comunes son:

• Lunes a viernes desde las 09:00 hasta las 17:00

• Lunes a viernes, 12/18/24 horas cada día (con los tiempos de comienzo y de finalización acordados mutuamente)

• Lunes a sábado (o de lunes a domingo), las mismas horas que anteriormente

Como puede esperarse, el costo de un contrato se incrementa con las horas de cobertura. En general, extender la cobertura de lunes a viernes tiende a costar menos que añadir sábado y domingo.

También aquí hay una posibilidad de reducir los costos si está dispuesto a hacer algo del trabajo.

8.1.1.2.1.1. Servicio de depósito

Si su situación no requiere más que la disponibilidad de un técnico durante las horas laborales normales y tiene la experiencia suficiente como para determinar lo que está dañado, puede considerar la opción de un servicio técnico o depot service. Conocido por muchos nombres diferentes (incluyendo walk-in service y drop-off service), los fabricantes pueden tener este tipo de servicios donde los técnicos trabajan en el hardware que los clientes traen.

Los servicios técnicos tienen la ventaja de ser tan rápidos como usted. Usted no tiene que esperar a que un técnico esté disponible y vaya a sus oficinas. Los técnicos de este tipo de servicio no se desplazan hasta sus instalaciones, lo que significa que alguien puede trabajar en su hardware tan pronto como usted lo pueda entregar en el servicio.

Debido a que los Servicios Técnicos se hacen una ubicación central, es muy probable que las partes requeridas se encuentren disponibles. Esto puede eliminar la necesidad de un despacho nocturno inmediato o de esperar a que la parte llegue desde muchos kilómetros de distancia desde otra oficina que al parecer posee una de estas partes en almacén.

Sin embargo, esto tiene sus desventajas. La más obvia es que usted no puede escoger las horas de servicio — usted recibe el servicio cuando el Servicio Técnico está abierto. Otro aspecto es que los técnicos no trabajan luego de sus horas normales, por lo que si su sistema falló un viernes a las 4:30 pm y usted llegó al Servicio Técnico a las 5:00 pm, nadie trabajará en su equipo hasta el siguiente lunes en la mañana.

Otra desventaja es que el Servicio Técnico depende de que se encuentre cercano a su negocio. Si su organización se encuentra ubicada en la zona metropolitana, es posible que esto no sea un problema. Sin embargo, las organizaciones en ubicaciones más rurales pueden tener el Servicio Técnico a un largo camino.

Sugerencia

Si está considerando un Servicio Técnico, tómese un momento para considerar los mecanismos para hacer llegar el hardware hasta el servicio. ¿Utilizará el vehiculo de la compañía o propio? Si utiliza su propio vehículo, ¿Su vehículo tiene el espacio y la capacidad de carga suficiente?, ¿Qué hay del seguro? ¿Se necesitará más de una persona para descargar el hardware?

Aunque estas son preocupaciones mundanas, se deberían considerar antes de tomar la decisión de utilizar un Servicio Técnico.


8.1.1.2.2. Tiempo de respuesta

Además de las horas de cobertura, muchos acuerdos de servicios especifican un nivel de tiempo de respuesta. En otras palabras, cuando usted llama pidiendo un servicio, ¿cuánto tiempo debe esperar hasta que llegue un técnico? Como se puede imaginar, mientras más rápida la respuesta más costoso será el acuerdo.

Existen límites para los tiempos de respuesta disponibles. Por ejemplo, el tiempo de viaje desde las instalaciones del fabricante hasta las suyas, tiene una gran trascendencia en los tiempos de respuesta posibles1 . Los tiempos de respuesta dentro del rango de cuatro horas generalmente se consideran entre las opciones más rápidas. Tiempos de respuesta más lentos pueden ir desde ocho horas (lo que efectivamente se convierte en un servicio de "al día siguiente" para un acuerdo de horas laborales estándar) hasta 24 horas. De la misma manera que con los otros aspectos de un acuerdo de servicios, aún estos tiempos son negociables — por el precio correcto.

Nota

Aún cuando no ocurre frecuentemente, debe estar consciente de que los acuerdos de servicios con claúsulas de tiempos de respuesta, algunas veces pueden estirar el servicio de un fabricante más allá de su habilidad para responder. A veces se escucha de organizaciones que envian a alguien — cualquier persona — para responder a una llamada de servicio con tiempos de respuesta cortos, simplemente para cubrir su responsabilidad. Esta persona aparentemente diagnostica el problema y llama a "la oficina" para solicitar que alguien traiga "la parte correcta".

En realidad, están esperando a que llegue la persona que es capaz realmente de manejar la llamada.

Aunque quizás se pueda entender que esto ocurra bajo circunstancias extraordinarias (tales como problemas de energía que han dañado los sistemas a lo largo del área de servicio), si este es un método consistente de operación, debería contactar al gerente de servicios y solicitar una explicación.

Si sus necesidades de tiempo de respuesta son rigurosas (y su presupuesto adecuadamente grande), hay un enfoque que puede recortar sus tiempos de respuesta aún más — inclusive a cero.

8.1.1.2.2.1. Tiempo de respuesta cero — Disponer de un técnico in situ

Dada la situación adecuada (usted es uno de los clientes más grandes en la zona), necesidad suficiente (el tiempo fuera de servicio de cualquier magnitud es inaceptable) y los recursos financieros (si pregunta por el precio, lo más probable es que no lo pueda pagar), quizás sea un candidato para un técnico a tiempo completo in situ. Los beneficios de tener a un técnico disponible son obvios:

• Respuesta inmediata a cualquier problema

• Un enfoque más proactivo al mantenimiento del sistema

Como puede esperarse, esta opción puede ser muy costosa, particularmente si requiere de un técnico in situ 24x7. Pero si este enfoque es apropiado para su organización, debe tener varios puntos en mente para sacar el máximo provecho.

Primero, los técnicos in situ necesitan muchos de los recursos de un empleado regular, tales como espacio de trabajo, teléfono, tarjetas de acceso/llaves, etc.

Los técnicos in situ no son de mucha ayuda si no cuentan con las partes correctas. Por lo tanto, asegúrese de que se tiene un almacenamiento seguro para los repuestos del técnico. Además, asegúrese

1. Y esto probablemente se considere el mejor caso posible, pues usualmente los técnicos son responsables por

territorios que se extienden fuera de la oficina en todas las direcciones. Si usted está en un extremo del territorio

y el único técnico disponible está en el otro extremo, el tiempo de respuesta será aún mayor.


de que el técnico mantenga un inventario de repuestos apropiado para su configuración y que estas partes no sean consumidas por otros técnicos para sus clientes.

8.1.1.2.3. Partes disponibles

Obviamente, la disponibilidad de partes juega un papel importante en limitar la exposición de su organización a fallas de hardware. En el contexto de un acuerdo de servicio, la disponibilidad de partes toma otra dimensión, pues la esta no solamente aplica a su organización, pero también a cualquier otro cliente en el territorio que pueda necesitar esas partes. Otra organización que ha comprado más hardware del fabricante que usted, puede recibir un trato preferencial cuando se refiere a conseguir los repuestos (y por ende los técnicos).

Lamentablemente, hay muy poco por hacer en tales circunstancias, más allá de tratar de resolver la situación con el gerente de servicios.

8.1.1.2.4. Presupuesto disponible

Como se mencionó anteriormente, los contratos de servicios varían en precio de acuerdo a la naturaleza de los servicios que se suministren. Tenga en cuenta que los costos asociados con un contrato de servicio son un gasto recursivo; cada vez que se vence el contrato, usted debe negociar un nuevo contrato y pagar nuevamente.

8.1.1.2.5. Hardware cubierto

He aquí un área donde puede ayudar a mantener los costos a un mínimo. Considere por un momento que usted ha negociado un acuerdo de servicio que tiene a un técnico in situ 24x7, repuestos in situ — y todo lo necesario. Cada pieza de hardware que compre de este fabricante está cubierta, incluyendo la PC que la recepcionista de la compañía utiliza para tareas no críticas.

Esa PC realmente necesita a alguien in situ 24x7? Aún si esa PC es vital para el trabajo del/de la recepcionista, este(a) solamente trabaja de 09:00 a 17:00; es muy improbable que:

• La PC será utilizada desde 17:00 hasta las 09:00 de la mañana siguiente (sin mencionar los fines de semana)

• Una falla de esta PC será notable, excepto durante 09:00 y 17:00

Por lo tanto, pagar por la casualidad de que esta PC necesite servicio a mitad del sábado en la noche, es una pérdida de dinero.

Lo que hay que hacer aquí es dividir el acuerdo de servicio de manera que el hardware que no sea crítico esté agrupado de forma separada al hardware crítico. De esta forma, se pueden reducir los costos.

Nota

Si tiene veinte servidores configurados de forma idéntica que son críticos para su organización, puede estar tentado a tener un acuerdo de servicio de alto nivel para uno o dos, dejando el resto cubiertos por un acuerdo mucho más económico. Luego, no importa cual de los servidores falle durante el fin de semana, usted dirá que es uno de los elegibles para el servicio de alto nivel.

No lo haga. No solamente es deshonesto, pero además la mayoría de los fabricantes hacen un seguimiento de tales cosas usando los números de seriales. Aún si usted se las arregla para tales verificaciones, se gasta mucho más luego de ser descubierto que siendo honesto y pagando por el servicio que realmente necesita.


8.1.2. Fallas del software

Algunas fallas de software pueden resultar en largos tiempos fuera de servicio. Por ejemplo, los dueños de cierta marca de computadores conocidos por sus funcionalidades de alta disponibilidad, descubren esto a primeras. Un error en el código de manejo de tiempo del sistema operativo del computador resultó en que los sistemas fallen a cierta hora de cierto día. Mientras que esta situación es un ejemplo más espectacular de una falla de software en acción, otras fallas relacionadas con el software pueden ser menos dramáticas, pero aún devastadoras.

Las fallas del software pueden golpear en dos áreas:

• Sistema operativo

• Aplicaciones

Cada tipo de falla tiene su impacto específico y se exploran en más detalles en las secciones siguientes.

8.1.2.1. Fallas del sistema operativo

En este tipo de falla, el sistema operativo es responsable por la interrupción del servicio. Las fallas del sistema operativo vienen de dos áreas:

• Caídas del sistema

• Colgarse o bloquearse

Lo principal a tener en cuenta sobre las fallas del sistema operativo es que estas sacan cualquier cosa que el computador estaba ejecutando en ese momento. Como tales, las fallas del sistema operativo pueden ser devastadoras para la producción.

8.1.2.1.1. Caídas del sistema

Las caídas ocurren cuando el sistema opertativo experimenta una condición de error desde la cual no se puede recuperar. La razón de las caídas pueden variar desde una incapacidad para manejar un problema de hardware subyacente hasta un error en el código a nivel del kernel abarcando el sistema operativo. Cuando un sistema operativo falla, se debe reiniciar el sistema para poder continuar la producción.

8.1.2.1.2. Colgarse o bloquearse

Cuando el sistema operativo deja de manejar estos eventos, el sistema se detiene aparatosamente. Esto se conoce como un bloqueo o se dice que el computador está colgado. Los interbloqueos (también conocido como deadlock, cuando dos recursos se disputan los recursos que el otro posee) o livelocks (dos o más procesos respondiendo a las actividades de cada uno, pero sin hacer un trabajo útil) pueden provocar que el sistema se cuelgue, con el mismo resultado final — una falta total de productividad.


8.1.2.2. Fallas de las aplicaciones

A diferencia de las fallas del sistema, las fallas de las aplicaciones pueden ser más limitadas en el ámbito de lo que dañan. Dependiendo de la aplicación específica, una sola aplicación que esté fallando puede afectar solamente a un usuario. Por otro lado, si se trata de una aplicación de servidor que está sirviendo a una gran población de aplicaciones clientes, las consecuencias de la falla serían mucho más extensas.

Las fallas de las aplicaciones, igual que otras fallas del sistema, pueden ser causadas por caidas o bloqueos; la única diferencia es que aquí es la aplicación la que se está guindando o fallando.

8.1.2.3. Obteniendo ayuda — Asistencia de software

De la misma forma que los fabricantes de hardware ofrecen soporte para sus productos, muchos proveedores de software colocan paquetes de soporte disponibles a sus clientes. Excepto por las diferencias obvias (no se requieren repuestos y la mayoría del trabajo lo puede hacer el personal de soporte a través del teléfono), los contratos de soporte de software pueden ser bastante similares a los contratos de hardware.

El nivel de soporte suministrado por un fabricante de software puede variar. He aquí algunas de las estrategias de soporte más comunes empleadas hoy día.

• Documentación

• auto-asistencia

• Soporte de Web o de correo electrónico

• Soporte telefónico

• Soporte in situ

Cada tipo de asistencia se describe en más detalles en las secciones siguientes.

8.1.2.3.1. Documentación

Aunque a veces es ignorada, la documentación del software puede servir como una herramienta de soporte de primer nivel. Bien sea en línea o impresa, la documentación a menudo contiene la información necesaria para resolver muchos problemas.

8.1.2.3.2. Auto asistencia

La auto asistencia confia en que el cliente utiliza los recursos en línea para resolver sus propios problemas relacionados al software. A menudo estos recursos toman la forma de FAQs (Preguntas más frecuentes) basadas en el Web o bases de datos de conocimientos.

Las FAQs tiene poca o ninguna capacidad de selección, dejando que el cliente se desplace pregunta por pregunta con la esperanza de encontrar una que mencione el problema que tiene. Las bases de conocimiento tienden a ser un poco más sofisticadas, permitiendo la entrada de términos para realizar búsquedas. Las bases de conocimientos también pueden ser bien completas en ámbito, convirtiéndola en una buena herramienta para resolver problemas.

8.1.2.3.3. Soporte Web o de correo electrónico

Muchas veces lo que a veces parece un sitio de auto asistencia, también incluye algunas formas basadas en web o correo electrónico que permiten que la persona pueda enviar preguntas al personal de soporte. Mientras que esto puede parecer a primera vista una mejora de un buen sitio web de auto asistencia, realmente depende de la gente que contesta los correos.


Si el personal de soporte está saturado de trabajo, es dificil obtener la información necesaria de ellos, pues su principal preocupación es la de responder rápidamente a cada correo y moverse al siguiente. La razón de esto es que casi todo el personal de soporte usualmente es evaluado por el número de problemas que pueden resolver. Los problemas de escalada también son complicados porque hay poco que hacer dentro de un correo electrónico para promover respuestas con mejores tiempos de respuestas y más útiles — particularmente cuando la persona leyendo su correo está apurado para moverse al siguiente.

La forma de obtener el mejor servicio es asegurarse de que su correo electrónico responde todas las preguntas que un técnico podría preguntarle, tales como:

• Claramente describa la naturaleza del problema

• Incluya todos los números de versión pertinentes

• Describa lo que ya ha hecho en un intento de resolver el problema (aplicó los últimos parches, reinición con la configuración mínima, etc.)

Al darle al técnico de soporte más información, tiene más oportunidades de obtener la asistencia que necesita.

8.1.2.3.4. Soporte telefónico

Como su nombre implica, el soporte telefónico implica hablar con un técnico a través del teléfono. Este estilo de soporte es más similar al soporte de hardware; en que pueden haber diferentes niveles de soporte disponible (con diferentes horas de cobertura, tiempo de respuesta, etc.)

8.1.2.3.5. Soporte in situ

También conocido como consultorías in situ, el soporte de software in situ normalmente está reservado para resolver problemas específicos o para efectuar cambios críticos, tales como la instalación y configuración inicial, actualizaciones importantes, etc. Como se puede esperar, este es el tipo de soporte más costoso.

Sin embargo, hay situaciones en las que las consultorías in situ tienen sentido. Como ejemplo considere una pequeña organización con un único administrador de sistemas. La organización va a implementar su primer servidor de bases de datos, pero la implementación (y la organización) no es lo suficientemente grande como para justificar la contratación de un administrador de bases de datos dedicado. En esta situación, a menudo puede ser más económico traer a un especialista de un proveedor de bases de datos para que maneje la implementación inicial (y ocasionalmente más adelante, si surge la necesidad) que entrenar al administrador de sistemas con una habilidad que será utilizada muy de vez en cuando.

8.1.3. Fallas ambientales

Los problemas pueden ocurrir aún cuando el hardware se está ejecutando perfectamente y aunque el software esté configurado de la forma adecuada. Los problemas más importantes que ocurren fuera del sistema mismo tienen que ver con el ambiente físico en el cual reside el sistema.

Los problemas ambientales se pueden desglosar en cuatro categorías:

• Integridad del edificio

• Electricidad

• Aire acondicionado


• Tiempo y el mundo exterior

8.1.3.1. Integridad del edificio

Para ser una estructura tan simple, un edificio realiza una gran cantidad de funciones. Proporciona un refugio contra los elementos. Suministra el ambiente climático adecuado para los contenidos del edificio. Tiene mecanismos para proporcionar energía y protección contra fuegos, robos y vandalismo. Para realizar todas estas funciones, no es una sorpresa que hayan muchas cosas que pueden salir mal con un edificio. He aquí algunas de las posibilidades a considerar:

• Los techos pueden tener goteras, dejando pasar agua hasta los centros de datos.

• Varios sistemas del edificio (tales como agua, desagues, o manejo del aire) pueden fallar, dejando el edificio inhabitable.

• Los pisos puede que no tengan suficiente capacidad para soportar el equipo que desea colocar en su centro de datos.

Es importante tener una mente creativa cuando se tiene que pensar sobre las diferentes formas en que un edificio puede fallar. La lista de arriba solamente es un comienzo para ponerlo a pensar en esta dirección.

8.1.3.2. Electricidad

Debido a que la electricidad es como la sangre de cualquier sistema computacional, los problemas relacionados a la energía son de suprema importancia en la mente de un administrador de sistemas. Hay muchos aspectos diferentes sobre la electricidad; estos se cubren con más detalles en las secciones siguientes.

8.1.3.2.1. La seguridad de su energía

Primero, es necesario determinar que tan seguro es su suministro de energía. De la misma forma que cualquier otro centro de datos, probablemente obtenga su electricidad desde la compañía eléctrica local a través de líneas de transmisión. Debido a esto, hay límites para lo que puede hacer para asegurarse de que su suministro principal de energía es tan seguro como pueda ser posible.

Sugerencia

Las organizaciones ubicadas cercanas a una compañía eléctrica quizás puedan negociar conexiones a dos rejillas de energía diferentes:

• La que sirve a su zona

• La que viene de la compañía eléctrica vecina

Los costos asociados con la implementación de líneas eléctricas directas desde la rejilla vecina son considerables, haciendo esto una opción solamente para organizaciones bastante grandes. Sin embargo, a tales organizaciones les puede parecer que la redundancia obtenida es mucho más valiosa que los costos en muchos casos.

Aquí, lo principal a verificar son los métodos a través de los cuales la energía es traída a las instalaciones de su organización y dentro del edificio. ¿Las líneas de transmisión están por debajo o sobre la tierra? Las líneas sobre el suelo son susceptibles a:

• Daños por condiciones ambientales extremas (hielo, viento, relámpagos)


• Accidentes de tránsito que dañan los postes y/o transformadores

• Animales perdidos en el lugar incorrecto y cortando las líneas

Sin embargo, las líneas bajo tierra tienen sus limitaciones únicas:

• Daños de trabajadores de construcción cavando en los lugares incorrectos

• Inundaciones

• Relámpagos (sin embargo, mucho menos que con las líneas sobre la tierra)

Continue haciendo un seguimiento a las líneas eléctricas dentro de su edificio. ¿Primero van a un transformador externo? ¿Está el transformador protegido contra vehículos o contra árboles que se puedan caer sobre el? ¿Los interruptores de apagado están protegidos contra usos no autorizados?

Ya dentro del edificio, ¿pueden estar las líneas de energía (o los páneles a las cuales se conectan) sujetas a otros problemas? Por ejemplo, ¿puede un problema de plomería inundar la sala eléctrica?

Continue haciendo el seguimiento de la energía hasta el centro de datos; ¿hay alguna otra cosa inesperada que pueda interrumpir el suministro de energía? Por ejemplo, ¿está el centro de datos compartiendo uno o más circuitos con cargas que no son del centro de datos? Si es así, la carga externa puede un día de estos hacer que se caiga la protección de sobrecarga del circuito, dejando fuera de servicio al centro de datos también.

8.1.3.2.2. Calidad de la electricidad

No es suficiente con asegurarse que la fuente de energía de su centro de datos esté bien protegida. También debe considerar la calidad de la energía que está siendo distribuida a su centro de datos. Hay muchos factores que debe considerar:

Voltaje

El voltaje de la energía entrante debe ser estable, sin reducciones de voltaje (a menudo conocidas como holguras, inclinaciones oapagones parciales) o incrementos de voltaje (conocidos como puntos y oleadas).

Forma de las ondas

La forma de la onda debe ser una onda limpia del seno, con un mínimo THD (Total Harmonic Distortion).

Frecuencia

La frecuencia debe ser estable (la mayoría de los países utilizan una frecuencia de energía de 50Hz o 60Hz).

Ruido

La energía no debe incluir ningún ruido de RFI (Interferencia de Frecuencia de Radio) o EMI (Interferencia electro-magnética).

Corriente

La energía se debe suministrar a una tasa suficiente como para correr el centro de datos.

La energía suministrada desde la compañía eléctrica normalmente no satisface los estándares necesarios para un centro de datos. Por lo tanto, usualmente se requiere un nivel de condicionamiento de la energía. Hay varios enfoques para hacer esto posible:


Protectores de corriente

Los protectores de corriente hacen exáctamente lo que su nombre indica — filtran el oleaje de la fuente de poder. La mayoría no hacen nada más que esto, dejando los equipos vulnerables a otros problemas relacionados con la energía.

Acondicionadores de energía

Los acondicionadores de energía tratan de lograr un enfoque más completo; dependiendo de lo sofisticado que sea la unidad, los acondicionadores de energía a menudo cubren la mayoría de los problemas descritos arriba.

Conjuntos de Moto-generadores

Un moto-generador esencialmente es un motor eléctrico grande activado por su suministro normal de poder. El motor está conectado a una rueda voladora, la cual a su vez está conectada a un generador. El motor mueve la rueda y el generador, lo cual produce la electricidad en suficientes cantidades para correr el centro de datos. De esta forma, la energía del centro de datos está separada de la electricidad externa, lo que significa que se eliminan una gran parte de los problemas relacionados con la electricidad. La rueda voladora también permite la habilidad de mantener energía durante interrupciones eléctricas cortas, pues toma varios segundos para que la rueda se detenga al punto en que ya no genere energía.

Fuentes De Alimentación Continuas

Algunos tipos de Fuentes de Alimentación Contínuas, más conocidos como UPS, incluyen la mayoría (si no es que todas) las funcionalidades de un acondicionador de energía2 .

Con las últimas dos tecnologías discutidas anteriormente, hemos comenzado con el tópico con el que la mayoría de la gente se relaciona cuando piensa sobre energía — energía de reserva. En la próxima sección, se exploran diferentes enfoques sobre el suministro de energía de reserva.

8.1.3.2.3. Energía de reserva

Un término relacionado con la energía que casi todo el mundo ha escuchado es un apagón. Un apagón es una pérdida completa de energía y puede durar una fracción de segundos o semanas.

Debido a que la extensión de los apagones puede variar muchísimo, es necesario abordar la tarea de suministrar energía usando tecnologías diferentes para apagones de diferente duración.

Sugerencia

La mayoría de los apagones frecuentes duran, en promedio, no más que unos pocos segundos; los apagones más largos son mucho menos frecuentes. En consecuencia, concéntrese primero en los apagones de solamente unos pocos minutos de duración, luego piense en los métodos a utilizar para protegerse de apagones más largos.

8.1.3.2.3.1. Suministrar energía por pocos segundos

Puesto que la mayoría de las interrupciones duran sólo unos segundos, su solución de energía de reserva debe tener dos características principales:

• Corto tiempo para cambiarse a la energía de reserva (conocido como tiempo de transferencia)

• Un tiempo de ejecución (el tiempo que durará la energía de reserva) medido en segundos a minutos

2. La tecnología de UPS se discute en más detalles en la Sección 8.1.3.2.3.2.


Las soluciones de energía de reserva que satisfacen estas características son los conjuntos de motogeneradores y los UPSs. La rueda voladora en el moto-generador permite que el generador continue produciendo electricidad por el tiempo suficiente para cubrir interrupciones de un segundo o un poco más. Los moto-generadores tienden a ser bastante grandes y costosos, haciendolos una solución práctica solamente para los centros de datos de mediano a gran tamaño.

Sin embargo, otra tecnología — llamada un UPS — puede cubrir estas situaciones donde un motogenerador es demasiado costoso. También pueden manejar interrupciones más largas.

8.1.3.2.3.2. Suministrar energía por pocos minutos

Los UPSs se pueden comprar en una variedad de tamaños - lo suficientemente pequeño como para ejecutar una sola PC por cinco minutos o lo suficientemente poderoso como para ejecutar el centro de datos completo por una hora o más.

Los UPSs están formados por las partes siguientes:

• Un switch de transferencia para intercambiarse desde la fuente primaria de poder a la fuente de energía de reserva

• Una batería, para suministrar la energía de reserva

• Un inversor, el cual convierte la corriente DC desde la batería a corriente AC requerida por el hardware del centro de datos

Aparte del tamaño y la capacidad de la batería de la unidad, los UPSs vienen en dos tipos básicos:

• Los UPSs fuera de línea utilizan un inversor para generar energía solamente cuando falla el suministro principal de poder.

• Un UPSs en línea utiliza un inversor para generar energía todo el tiempo, activando el inversor a través de su batería solamente cuando la fuente principal de energía falle.

Cada tipo tiene sus ventajas y desventajas. Un UPS fuera de línea usualmente es menos costoso, debido a que el convertidor no tiene que ser construído para operar todo el tiempo. Sin embargo, si ocurre un problema con el UPS fuera de línea esto pasará inadvertidamente (hasta que ocurra la próxima interrupción eléctrica).

Los UPSs en línea tienden a ser mejor en proporcionar energía limpia para su centro de datos; después de todo, un UPS en línea básicamente está generando energía para usted a tiempo completo.

Pero no importa qué tipo de UPS usted seleccione, debe medir el tamaño de su UPS para anticipar la carga (asegurando por tanto que el UPS tiene energía suficiente para producir electricidad al nivel de voltage y corriente requerido), y debe determinar cuánto tiempo le gustaría ejecutar su centro de datos usando la energía de la batería.

Para determinar esta información, primero debe determinar las cargas que el UPS servirá. Revise cada equipo y determine cuánta energía necesita (esto normalmente está listado en una etiqueta cerca del cable eléctrico de la unidad). Escriba el voltaje, los watts y/o amperios. Una vez que tenga estos números para todo el hardware, debe convertirlos a VA (Volt-Amps). Si tiene un número de vatiaje, puede utilizar el vatiaje listado como VA; si tiene amperios, multipliquelo por los voltios para obtener el VA. Al añadir los números de vatiaje puede llegar al número aproximado VA requerido por el UPS.

Nota

Siendo más específicos, este enfoque para calcular el VA no es correcto; sin embargo, para obtener el verdadero VA necesitaría conocer el factos de energía para cada unidad y esta información, raramente se encuentra disponible. En cualquier caso, los números de VA obtenidos usando este enfoque, reflejan los valores del peor caso, dejándole un margen de error por razones de seguridad.


Determinar el tiempo de ejecución es más que una pregunta de negocios que técnica - cpntra qué tipode interrupciones está dispuesto a protegerse y cuánto dinero está dispuesto a gastar para hacerlo? Lamayoría de los sitios selecciona tiempos de ejecución menores que una hora o dos como máximo,pues a partir de este punto la energía a partir de las baterias se vuelve bastante costosa.

8.1.3.2.3.3. Suministrar energía por las próximas horas (y más)

Una vez que llegamos al punto de interrupciones eléctricas que se miden en días, las opciones sevuelven más costosas. Las tecnologías capaces de manejar interrupciones eléctricas de largo tiempoestán limitadas a generadores activados por algún tipo de motor - principalmente diesel o de turbinas.

Nota

Tenga en mente que los generadores activados a través de motores requieren de recargas regularesmientras se esten ejecutando. Debería conocer la tasa de uso de su combustible con una cargamáxima y programar las entregas de combustible de acuerdo a esto.

En este punto, sus opciones son bien abiertas, asumiendo que su organización tiene los fondos sufi-cientes. Esto también es un área en la que los expertos deberían ayudarlo a determinar la mejor solu-ción posible para su organización. Muy pocos administradores de sistemas tienen el conocimientoespecializado necesario para planear la adquisición y despliegue de estos tipos de sistemas de gen-eración de energía.

Sugerencia

Se pueden rentar generadores portables de todos los tamaños, haciendo posible tener los beneficiosde un generador sin el gasto de dinero inicial para comprar uno. Sin embargo, tenga en cuenta que endesastres que afectan su vecindad en general, los generadores alquilados serán difíciles de obtenery muy costosos.

8.1.3.2.4. Planificación para interrupciones prolongadas

Mientras que un apagón de cinco minutos es solamente un poco más que una inconveniencia parael personal en una oficina a oscuras, ¿qué tal si el apagón dura una hora? ¿cinco horas, un día, unasemana?

El hecho es, aún si el centro de datos está operando normalmente, en algún punto una interrupciónprolongada eventualmente afectará a su organización. Considere los puntos siguientes:

• ¿Qué pasa si no hay electricidad para mantener el control ambiental en el centro de datos?

• ¿Qué pasa si no hay electricidad suficiente para mantener el control ambiental en todo el edificio?

• ¿Qué pasa si no hay energía para operar las estaciones de trabajo, el sistema telefónico, las luces?

El punto aquí es que su organización debe determinar a qué punto una interrupción prolongada tendráque simplemente ser tolerada. Si esto no es una opción, su organización debe reconsiderar su habilidadpara funcionar de forma completamente independiente de un sitio con electricidad, lo que significaque se necesitaran generadores muy grandes para servir a un edificio completo.


Por supuesto, aún este nivel de planificación no puede ocurrir en un vacío. Es muy probable que lo que sea que esté causando la interrupción prolongada, también esté afectando el mundo externo a su organización, y que el mundo externo comenzará a tener un efecto en la habilidad de su organización para continuar sus operaciones, aún cuando se tenga capacidad de generar electricidad de forma ilimitada.

8.1.3.3. Calefacción, Ventilación y Aire Acondicionado

Los sistemas de Calefacción, Ventilación y Aire Acondicionado ( Heating, Ventilation, and Air Conditioning, HVAC) utilizados en los edificios de oficinas de hoy día, son increíblemente sofisticados. A menudo controlados por computadoras, el sistema HVAC es vital para proporcionar un ambiente laboral cómodo.

Los centros de datos tienen equipos adicionales de manejo de aire acondicionado, principalmente para eliminar el calor generado por los muchas computadoras y el resto del equipo asociado. Las fallas en el sistema HVAC pueden ser devastadoras para el funcionamiento continuo de su centro de datos. Dada su complejidad y la naturaleza electromagnética, las posibilidades de una falla son muchas y variadas. He aquí algunos ejemplos:

• Las unidades de manejo de aire acondicionado (esencialmente grandes ventiladores eléctricos) pueden fallar debido a la sobrecarga eléctrica, una falla, falla de la correa/polea, etc.

• Las unidades de enfriamiento (a menudo llamadas chillers) pueden perder su refrigerante debido a filtraciones o tomar sus compresores y/o motores.

La reparación y mantenimiento de un HVAC es un campo muy especializado - un campo que el administrador de sistemas promedio debería dejar a los expertos. En cualquier caso,

8.1.3.4. El tiempo y el mundo externo

Hay algunos tipos de tiempo que pueden causar problemas a un adminstrador de sistemas:

• Las nevadas fuertes y el hielo puede impedir que el personal llegue hasta el centro de datos y hasta puede tapar los condensadores de aire acondicionado, provocando que se eleven las temperaturas de los centros de datos justament cuando no hay nadie que pueda acercarse al centro de datos para llevar a cabo las acciones correctivas.

• Vientos fuertes que pueden interrumpir la energía y las comunicaciones, con vientos extremadamente fuertes dañando inclusive el edificio mismo.

Hay otros tipos de tiempo que también pueden provocar problemas, aún cuando no sean tan conocidos. Por ejemplo, las temperaturas muy altas pueden ocasionar que se sobrecarguen los sistemas de enfriamiento, generando apagones parciales o totales cuando el panel eléctrico se sobrecarga.

Aunque es muy poco lo que puede hacer sobre el tiempo, el conocer la forma en que este puede afectar las operaciones de su centro de datos, lo ayudará a mantener las cosas funcionando cuando se tenga mal tiempo.

8.1.4. Errores humanos

Se ha dicho que las computadoras son realmente perfectas. La razón detrás de esta afirmación es que si usted profundiza lo suficiente, detrás de cada error computacional encontrará el error humano que lo causó. En esta sección se exploran los tipos de errores humanos más comunes y sus impactos.


8.1.4.1. Errores humanos del usuario final Los usuarios pueden cometer errores que podrían tener un impacto muy serio. Sin embargo, debido a que su ambiente normalmente no tiene muchos privilegios, los errores tienden a ser de naturaleza localizada. Puesto que la mayoría de los usuarios interactuan exclusivamente con una computadora por una o más aplicaciones, usualmente es dentro de las aplicaciones que ocurren la mayoría de los errores.

8.1.4.1.1. Uso inapropiado de las aplicaciones

Cuando las aplicaciones son usadas inapropiadamente, pueden ocurrir varios problemas:

• Archivos sobreescritos inadvertidamente

• Datos incorrectos utilizados como entrada a una aplicación

• Archivos no claramente nombrados u organizados

• Archivos borrados accidentalmente

La lista puede continuar, pero esto es suficiente para ilustrar la situación. Puesto que los usuarios no tienen privilegios de superusuario, los errores que cometen estan usualmente limitados a sus propios archivos. Como tal, el mejor enfoque es dividido:

• Eduque a sus usuarios para el uso correcto de sus aplicaciones y en las técnicas correctas de administración de archivos

• Asegurese de que se hacen copias de respaldo regulares de los archivos de sus usuarios y de que el proceso de restauración es tan organizado y rápido como sea posible

Más allá de aquí, es poco los que se puede hacer para mantener los errores de los usuarios a un mínimo.

8.1.4.2. Errores del personal de operaciones

Los operadores tienen una relación más profunda con las computadoras de una organización que los usuarios finales. Mientras que los errores de un usuario tienden a ser orientados a aplicaciones, los de los operadores tienden a llevar a cabo un rango más amplio de tareas. Aunque la naturaleza de las tareas haya sido dictada por otros, algunas de estas tareas pueden incluir el uso de utilidades a nivel del sistema, donde el potencial para daños más amplios debido a errores es mayor. Por lo tanto, los tipos de errores que un operador puede hacer se centran en la habilidad de un operador de seguir procedimientos que hayan sido desarrollados para su uso.

8.1.4.2.1. No se siguen los procedimientos

Los operadores deben tener conjuntos de procedimientos documentados y disponibles para casi cada acción que realizan3 . Puede ser que un operador no siga los procedimientos de la forma en que estos están establecidos. Puede haber varias razones para esto:

• El ambiente fue modificado en algún momento en el pasado y los procedimientos nunca se actualizaron. Ahora el ambiente cambia otra vez, dejando a que el operador memorice un procedimiento

3. Si los operadores en su organización no tienen procedimientos de operación, trabaje en con ellos, la gerencia

y sus usuarios para crearlos. Sin procedimientos, un centro de datos está fuera de control y vulnerable a sufrir

problemas graves en el curso de las operaciones diarias.


inválido. En este punto, aun si los procedimientos se actualizaron (lo que es poco probable, dado el hecho de que no estaban actualizados anteriormente) el operador no lo sabrá.

• El ambiente fue modificado y no existen procedimientos. Esto es simplemente una versión más fuera de control que la situación anterior.

• Los procedimientos existen y son correctos, pero el operador no los seguirá (o no puede).

Dependiendo de la estructura gerencial de su organización, quizás no pueda hacer mucho más que simplemente comunicar sus preocupaciones al gerente adecuado. En cualquier caso, ofrecerse para ayudar en lo que sea posible para ayudar es la mejor forma de abordar esto.

8.1.4.2.2. Errores cometidos durante los procedimientos

Aún si el operador sigue los procedimientos y aunque los procedimientos esten correctos, todavía se pueden cometer errores. Si esto ocurre, existe la posibilidad de que el operador sea descuidado (en cuyo caso se debería involucrar al supervisor del operador).

Otra explicación es que fue simplemente un error. En estos casos, los mejores operadores se daran cuenta de que algo está mal y buscaran ayuda. Siempre anime a sus operadores a que contacten a la gente adecuada si sospechan que algo anda mal. Aunque muchos operadores están muy bien preparados y son capaces de resolver muchos problemas independientemente, el hecho es que esto no es su trabajo. Y un problema que se complica más por un operador con buenas intenciones puede amenazar la carrera de la persona y su habilidad para resolver rápidamente un problema que quizás originalmente era un problema pequeño.

8.1.4.3. Errores del Administrador del Sistema

A diferencia de los operadores, los administradores de sistemas realizan una variedad de tareas usando las computadoras de la organización. También a diferencia de los operadores, las tareas que los administradores de sistemas llevan a cabo a menudo no están basadas en procedimientos documentados.

En consecuencia, los administradores de sistemas a veces crean trabajo adicional para sí mismos cuando no tienen cuidado en lo que están haciendo. Durante el curso de llevar a cabo las responsabilidades diarias, los administradores de sistemas tienen acceso más que suficiente a los sistemas computacionales (sin mencionar los privilegios de superusuario) como para afectar accidentalmente los sistemas.

Los administradores de sistemas cometen errores de configuración o durante el mantenimiento.

8.1.4.3.1. Errores de configuración

Los administradores de sistemas a menudo deben configurar varios aspectos de un sistema computacional. Esta configuración incluye:

• Correo electrónico

• Cuentas de usuarios

• Red

• Aplicaciones

La lista puede extenderse mucho más. La tarea actual de configurar varía en gran medida; algunas tareas requieren editar un archivo de texto (usando cualquiera de los cientos de sintaxis de archivos de configuración), mientras que otras tareas requieren la ejecución de alguna utilidad de configuración.

El hecho de que estas tareas son manejadas de forma diferente es simplemente un reto adicional al hecho básico de que cada tarea de configuración requiere un conocimiento diferente. Por ejemplo,


el conocimiento requerido para configurar un agente de transporte de correo es fundamentalmente diferente al conocimiento requerido para configurar una conexión de red.

Dado todo esto, quizás debería ser una sorpresa que solamente se cometen unos pocos errores. En cualquier caso, la configuración es y seguirá siendo, un reto para los administradores de sistemas. ¿Hay algo que se pueda hacer para hacer el proceso menos susceptible a errores?

8.1.4.3.1.1. Control de cambios

La tendencia común de cada cambio de configuración es que ha ocurrido algún tipo de cambio. El cambio puede ser grande o puede ser pequeño. Pero aún se trata de un cambio y debería ser tratado de una forma particular.

Muchas organizaciones implementan algún tipo de proceso de control de cambios. La intención es la de ayudar a los administradores de sistemas (y a todas las partes afectadas por el cambio) a administrar el proceso de cambio y reducir la exposición de la organización a cualquier error que pueda ocurrir.

Un proceso de control de cambios normalmente desglosa el cambio en pasos diferentes. He aquí un ejemplo:

Investigación preliminar

La investigación preliminar intenta definir claramente:

• La naturaleza del cambio que tomará lugar

• Su impacto, si el cambio es exitoso

• Una posición de retroceso, si el cambio falla

• Una evaluación de qué tipos de falla son posibles

La investigación preliminar puede incluir probar el cambio propuesto durante el tiempo planificado fuera de servicio, o puede ir tan allá como para incluir la implementación del cambio primero en un ambiente de prueba especial, ejecutándose en un hardware dedicado para las evaluaciones.

Planificación

Se examina el cambio con un ojo hacia las mecánicas actuales de la implementación. La planificación se hace incluyendo una descripción de la secuencia y tiempo del cambio (junto con la secuencia y tiempo de cualquier paso necesario para cancelar el cambio en caso de que ocurra un problema), así como también asegurarse de que el tiempo asignado para los cambios es suficiente y no entra en conflicto con ninguna otra actividad a nivel de sistemas.

El producto de este proceso a menudo es una lista de verificación de pasos para que la use el administrador del sistemas mientras está llevando a cabo el cambio. Junto con cada paso están las instrucciones a realizar para cancelar el cambio y volver al estado anterior, en caso de que falle el paso. A menudo se incluyen los tiempos estimados, haciendo fácil para que el administrador del sistema determine si el trabajo está dentro de la planificación o no.

Ejecución

En este punto, la ejecución real de los pasos necesarios para implementar el cambio debería ser directa y anti-culminante. El cambio es implementado o (si ocurren errores) se cancela.

Supervisión

Bien sea que se implemente el cambio o no, se monitoriza el ambiente para asegurarse de que todo está funcionando como debería.


Documentación

Si se implementa el cambio, toda la documentación existente se actualiza para reflejar la configuración modificada.

Obviamente, no todos los cambios de configuración requieren este nivel de detalles. La creación de una cuenta de usuarios no requiere ninguna investigación preliminar y la planificación probablemente consistirá de determinar si el administrador tiene tiempo libre para crear una cuenta. La ejecución sera igualmente rápida; la monitorización consiste de asegurarse de que la cuenta es utilizable y la documentación probablemente consistirá en enviar un correo electrónico al supervisor del usuario.

Pero a medida que la configuración se vuelve más compleja, se hace necesario un proceso de control de cambios más formal.

8.1.4.3.2. Errores cometidos durante el mantenimiento

Este tipo de errores pueden ser insidiosos porque se hace muy poca planificación o seguimiento durante el mantenimiento de día a día.

Los administradores de sistemas ven el resultado de estos errores diariamente, especialmente de los usuarios que juran que no cambiaron nada - simplemente la computadora se echó a perder. El usuario que afirma esto usualmente no se recuerda qué fue lo que hizo y cuando le pase lo mismo a usted, probablemente usted tampoco recuerde lo que hizo.

La cuestión clave a tener en mente es que usted debe ser capaz de recordar los cambios que realizó durante un mantenimiento si quiere ser capaz de resolver los problemas rápidamente. Un verdadero proceso del control del cambio no es realístico para los cientos de cosas que se hacen durante un día. ¿Qué se puede hacer para seguir las 101 cosas que un administrador de sistemas realiza diariamente?

La respuesta es simple - tome notas. Bien sea que esté hecho en un cuaderno, un PDA o como comentarios en los archivos comentados, tome notas. Al hacer un seguimiento de lo que hace, tiene más oportunidades de notar una falla como relacionada a un cambio que realizó recientemente.

8.1.4.4. Errores de Servicio Técnico

Algunas veces la propia gente que se supone debería ayudarlo a mantener sus sistemas funcionando confiablemente, son los que complican más las cosas. Esto no se debe a ninguna conspiración; es simplemente por el hecho de que cualquiera que esté trabajando en una tecnología por alguna razón, arriesga el hacer esa tecnología inoperable. El mismo efecto es en el trabajo cuando los programadores reparan un fallo pero terminan creando otro.

8.1.4.4.1. Hardware reparado incorrectamente

En este caso, el técnico falló en diagnosticar el problema correctamente y realizó una reparación innecesaria (e inútil), o el diagnóstico fue correcto, pero la reparación realizada no se llevó a cabo bien. Puede ser que la parte misma reemplazada estaba defectuosa, o que no se siguió el procedimiento adecuado cuando se realizó la reparación.

Por eso es importante estar al tanto de lo que está haciendo el técnico en todo momento. Haciendo esto, puede mantener un ojo sobre las fallas que puedan parecer estar relacionadas al problema original de alguna forma. Esto mantiene al técnico en carril por si hay un problema; de lo contrario hay oportunidad de que el técnico pueda ver esa falla como nueva y no relacionada con la supuestamente reparada. De esta forma, no se pierde tiempo buscando por el problema incorrecto.


8.1.4.4.2. Reparar una cosa y dañar otra

Algunas veces, aún cuando se diagnosticó y reparó el problema exitósamente, surge otro problema en su lugar. Se reemplazó el módulo del CPU, pero la bolsa antiestática en la cual vino, se dejó en el gabinete bloqueando el ventilador y causando un apagado por sobre-calentamiento. O se reemplazó el disco duro que estaba fallando en la formación RAID, pero puesto que se golpeó accidentalmente un conector en otra unidad y se desconectó, la formación RAID continua fuera de servicio.

Estas cosas pueden ser el resultado de descuidos crónicos o de un error honesto. No importa. Lo que siempre debe hacer es revisar cuidadosamente las reparaciones realizadas por un técnico y asegurarse de que el sistema está funcionando correctamente antes de dejar que el técnico se retire.

8.2. Respaldos

Los respaldos o copias de seguridad tienen dos objetivos principales:

• Permitir la restauración de archivos individuales

• Permitir la restauración completa de sistemas de archivos completos

El primer propósito es la base para las peticiones típicas de restauraciones de archivos: un usuario accidentalmente borra un archivo y le pide restaurarlo desde el último respaldo. Las circunstancias exactas pueden variar, pero este es el uso diario más común de los respaldos.

La segunda situación es la peor pesadilla de un administrador de sistemas: por la situación que sea, el administrador se queda observando un hardware que solía ser una parte productiva del centro de datos. Ahora, no es más que un pedazo de acero y silicon inútil. Lo que está faltando en todo el software y los datos que usted y sus usuarios habian reunido por años. Supuestamente todo ha sido respaldado. La pregunta es: ¿Está seguro?

Y si lo ha sido, ¿Lo puede restaurar?

8.2.1. Datos diferentes: Necesidades de respaldos diferentes

Observe el tipo de datos4 procesados y almacenados por un sistema computacional típico. Observe que algunos de los datos raramente cambian y otros cambian constantemente.

El ritmo al cual los datos cambian es crucial para el diseño de un procedimiento de respaldo. Hay dos razones para esto:

• Un respaldo no es más que una instantánea de los datos respaldados. Es un reflejo de los datos en un momento particular.

• Los datos que cambian con poca frecuencia se pueden respaldar menos a menudo, mientras que los datos que cambian regularmente deben ser copiados frecuentemente.

Los administradores de sistemas que tienen un buen entendimiento de sus sistemas, usuarios y aplicaciones deberían ser capaces de agrupar rápidamente en sus sistemas en diferentes categorías. Sin embargo, he aquí algunos ejemplos para comenzar:

4. Estamos usando el término datos en esta sección para describir cualquier cosa que se procesa por el software

de respaldo. Esto incluye software del sistema operativo, software de aplicaciones, así como también los datos

reales. No importa lo que sea, para el software de respaldos, todos son datos.


Sistema operativo

Estos datos solamente cambia durante las actualizaciones, las instalaciones de reparaciones deerrores y cualquier modificación específica al sitio.

Sugerencia

Debería de molestarse con el respaldo del sistema operativo? Esta es una pregunta que mu-chos administradores de sistemas operativos han evaluado por muchos años. Por un lado, si elproceso de instalación es relativamente fácil y si las reparaciones de fallos y personalizacionesestán bien documentadas y son fáciles de reproducir, la reinstalación del sistema operativopuede ser una opción viable.

Por otro lado, si hay alguna duda de que una instalación fresca pueda recrear completamenteel ambiente original del sistema, el respaldo del sistema operativo es la mejor opción, aún silos respaldo se realizaron con mucho menos frecuencia que los respaldos de datos de produc-ción. Los respaldos ocasionales de sistemas operativos son útiles cuando se deben restaurarsolamente unos pocos sistemas operativos (por ejemplo, debido a la eliminación accidental deun archivo).

Software de aplicaciones

Estos datos cambian cuando se instalan, actualizan o eliminan aplicaciones.

Datos de aplicaciones

Estos datos cambian tan frecuente como lo hacen las aplicaciones asociadas. Dependiendo dela aplicación específica y su organización, esto puede significar que los cambios toman lugarsegundo a segundo o al final del año fiscal.

Datos de usuarios

Estos datos cambian de acuerdo a los patrones de uso de su comunidad de usuarios. En la mayoríade las organizaciones, esto significa que los cambios toman lugar todo el tiempo.

Basado en estas categorías (y cualquier otra adicional que sean específicas a su organización), usteddebería tener una buena idea concerniente a la naturaleza de los respaldos que se necesitan paraproteger sus datos.

Nota

Debe tener en mente que la mayoría del software de respaldo trata con datos en un directorio o anivel del sistema de archivos. En otras palabras, la estructura de su sistema de archivo juega unpapel importante en cómo se ejectuten los respaldos. Esta es otra razón por la que es una buenaidea considerar cuidadosamente la mejor estructura de directorios para un nuevo sistema y agruparlos archivos y directorios de acuerdo a su uso anticipado.

8.2.2. Software de respaldos: Comprar contra ConstruirPara poder llevar a cabo los respaldos, es necesario tener el software de respaldo apropiado. Estesoftware no solamente debe ser capaz de realizar la tarea básica de hacer copias de bits en una media derespaldo, también debe interactuar limpiamente con el personal y las necesidades de su organización.Algunas de las funcionalidades a considerar cuando evalue software de respaldo incluyen:

• Planifica respaldos para que se ejecuten en el momento adecuado


• Maneja la ubicación, rotación y uso de la media de respaldo

• Funciona con operadores (y/o cargadores robóticos) para asegurarse de que la media apropiada está disponible

• Asiste a los operadores en ubicar la media que contiene un respaldo específico de un archivo dado

Como puede observar, una solución de respaldo del mundo real implica mucho más que simplemente escribir bits en su media de respaldo.

La mayoría de los administradores de sistemas en este punto, ven hacia una de dos soluciones:

• Comprar una solución desarrollada comercialmente

• Desarrollar una solución casera de sistema de respaldo desde el principio (posiblemente integrando una o más tecnologías de código abierto)

Cada enfoque tiene sus puntos buenos y sus puntos malos. Dada la complejidad de la tarea, una solución casera probablemente no maneje todos los aspectos (tales como administración de media, o tener el soporte técnico y la documentación completa) muy bien. Sin embargo, para algunas organizaciones, esto quizás no sea una limitación.

Una solución desarrollada comercialmente es más probable que sea altamente funcional, pero también excesivamente compleja para las necesidades presentes de la organización. Dicho esto, la complejidad puede hacer posible mantenerse con una solución aun si la organización crece.

Como puede ver, no hay un método claro para decidirse sobre un sistema de respaldo. La única guía que se puede ofrecer es pedirle que considere los puntos siguientes:

• Cambiar el software de respaldo es complicado; una vez implementado, estará usando el software de respaldo por un largo tiempo. Después de todo, tendrá archivos de respaldo por largo tiempo que podrá leer. El cambiar el software de respaldo significa que usted debe bien sea mantener el software original (para acceder a los archivos de respaldo), o que debe convertirlos para que sean compatibles con el nuevo software.

Dependiendo del software de respaldo, el esfuerzo que implica convertir archivos de respaldo puede ser tan directo (pero probablement consuma mucho tiempo) como ejecutar los respaldos a través de un programa de conversión ya existente, o puede requerir ingeniería inversa del formato de respaldo y escribir un software personalizado para realizar esta tarea.

• El software debe ser 100% confiable - debe respaldar lo que se supone que debe respaldar y cuando se necesite.

• Cuando llega el momento de restaurar los datos - ya sea un archivo único o un sistema de archivos completo - el software de respaldo debe ser 100% confiable.

8.2.3. Tipos de respaldo

Si le pregunta a una persona que no esta familiarizada con los respaldos o copias de seguridad de computadoras, la mayoría pensaría que un respaldo es una copia idéntica de todos los datos en un computador. En otras palabras, si se creó un respaldo el martes en la noche, y no se cambió nada durante el miercoles completo, el respaldo del miercoles en la noche sería idéntico que el del martes.

Mientras que es posible configurar los respaldos de esta forma, es probable que no lo haga. Para entender un poco más sobre esto, primero se debe entender los tipos de respaldo que se pueden crear. Estos son:

• Respaldos completos

• Respaldos incrementales

• Respaldos diferenciales


8.2.3.1. Respaldos completos

El tipo de respaldo discutido al principio de esta sección se conoce como respaldo completo. Un respaldo completo es un respaldo donde cada archivo es escrito a la media de respaldo. Como se mencionó anteriormente, si los datos a respaldar nunca cambian, cada respaldo completo creado será una copia de exactamente lo mismo.

Esta similaridad se debe al hecho de que un respaldo completo no verifica para ver si un archivo ha cambiado desde el último respaldo; ciegamente escribe todo a la media de respaldo, haya sido modificada o no.

Esta es la razón por la que los respaldos completos no se hacen todo el tiempo - cada archivo es escrito a la media de respaldo. Esto significa el uso de gran cantidad de media de respaldo aún cuando nada se haya cambiado. Respaldar 100 GB de datos cada noche cuando solamente cambió 10 MB de datos, no es una buena solución; por eso es que se crean los respaldos incrementales.

8.2.3.2. Respaldos incrementales

A diferencia de los respaldos completos, los respaldos incrementales primero revisan para ver si la fecha de modificación de un archivo es más reciente que la fecha de su último respaldo. Si no lo es, significa que el archivo no ha sido modificado desde su último respaldo y por tanto se puede saltar esta vez. Por otro lado, si la fecha de modificación es más reciente, el archivo ha sido modificado y se debería copiar.

Los respaldos incrementales son utilizados en conjunto con respaldos regulares completos (por ejemplo, un respaldo semanal completo, con respaldos incrementales diarios).

La principal ventaja obtenida de los respaldos incrementales es que se ejecutan muchísimo más rápido que un respaldo completo. La principal desventaja es que restaurar un archivo dado puede implicar pasar a través de varios respaldos incrementales hasta encontrar el archivo. Cuando se restaura un sistema de archivos completo, es necesario restaurar el último respaldo completo y cada respaldo incremental subsecuente.

En un intento de aliviar la necesidad de pasar a través de varios respaldos incrementales, se puede utilizar un enfoque ligeramente diferente. Esto se conoce como respaldo diferencial.

8.2.3.3. Respaldos diferenciales

Los respaldos diferenciales son similares a los respaldos incrementales en que ambos solamente copian archivos que han sido modificados. Sin embargo, los respaldos diferenciales son acumulativos — en otras palabras, con un respaldo diferencial, una vez que un archivo ha sido modificado continua siendo incluído en todos los respaldos diferenciales subsecuentes (hasta el próximo respaldo completo).

Esto significa que cada respaldo diferencial contiene todos los archivos modificados desde el último respaldo completo, haciendo posible realizar una restauración completa solamente con el último respaldo completo y el último respaldo diferencial.

De la misma manera que la estrategia de respaldo de los respaldos incrementales, los respaldos diferenciales siguen el mismo enfoque: un respaldo completo periódico seguido de más frecuentes respaldos diferenciales.

El efecto de utilizar los respaldos diferenciales de esta forma es que los respaldos diferenciales tienden a crecer un poco con el tiempo (asumiendo que diferentes archivos son modificados con el paso del tiempo entre respaldos completos). Esto coloca los respaldos diferenciales en un punto entre los respaldos incrementales y los completos en términos de utilización de la media y velocidad de los respaldos, mientras que ofrecen restauraciones completas y de archivos individuales mucho más rápidas (debido a que hay menos respaldos en los que buscar/restaurar).

Dadas estas características, vale la pena considerar cuidadosamente los respaldos diferenciales.


8.2.4. Media de respaldo

Hemos sido muy cuidadosos en seleccionar la palabra "media de respaldo" a lo largo de las secciones. Hay una razón para esto. Los administradores de sistemas más experimentados usualmente piensan sobre respaldos en términos de leer y escribir en cintas, pero hoy día existen otras opciones.

En algún momento, los dispositivos de cintas eran los únicos dispositivos de media de respaldo que se podían utilizar razonablemente para propósitos de respaldos. Sin embargo, esto ha cambiado. En las secciones siguientes vamos a tratar sobre las medias de respaldo más populares y revisar sus ventajas así como también sus desventajas.

8.2.4.1. Cintas

Las cintas fueron el primer tipo de media removible disponible como medio de almacenamiento. Tiene los beneficios de bajos costos y una capacidad de almacenamiento razonablemente buena. Sin embargo, las cintas tienen algunas desventajas - es susceptible a desgastarse y el acceso a los datos en una cinta es por naturaleza secuencial.

Estos factores implican que es necesario hacer un seguimiento del uso de las cintas (retirando las cintas una vez que hayan alcanzado el final de su vida útil) y que las búsquedas de un archivo en cinta pueden ser una tarea bastante lenta.

Por otro lado, las cintas son uno de los medios de almacenamiento masivo menos costosos disponibles y tienen una larga historia de confiabilidad. Esto significa que construir una biblioteca de cintas de un buen tamaño no necesita consumir una gran parte de su presupuesto, y puede contar con poderla utilizar ahora y en un futuro.

8.2.4.2. Disco

En años pasados, las unidades de disco nunca se utilizaban como medio para respaldos. Sin embargo, los precios se han reducido tanto que, en algunos casos, el uso de discos duros como unidades de respaldo, tiene sentido.

La razón principal para el uso de unidades de disco como medio para respaldos sería su velocidad. No hay un medio de almacenamiento masivo más rápido disponible. La velocidad puede ser un factor crítico cuando la ventana para hacer el respaldo de su centro de datos es corta y la cantidad de datos a copiar es grande.

Pero por varias razones el almacenamiento en disco no es el medio ideal para respaldos.

• Normalmente los discos duros no son removibles. Un factor clave para una estrategia de respaldo efectiva es que se pueda retirar la media de su centro de datos y en algún tipo de almacenamiento fuera del sitio. Un respaldo de la base de datos de producción sentada en un disco duro medio metro más allá de la base de datos misma no es un respaldo; es una copia. Y las copias no son muy útiles si los datos del centro de datos y sus contenidos (incluyendo las copias) son dañadas o destruídas por algún tipo de evento desafortunado.

• Las unidades de disco duro son costosas (al menos comparadas con otros tipos de media). Hay situaciones donde el dinero realmente no es un problema, pero en todos los demas casos, los costos asociados con el uso de discos duros para respaldos significa que el número de copias de respaldo se debe mantener bajo para así mantener bajos los costos generales. Menos copias de seguridad significa menos redundancia si por alguna razón uno de los respaldos no se puede leer.

• Los discos duros son frágiles. Aún si hace el gasto adicional de comprar discos removibles, su fragilidad puede ser un problema. Si se le cae un disco, usted perdió el respaldo. Es posible comprar estuches especiales que pueden reducir (pero no eliminar completamente) este peligro, pero esto hace una propuesta costosa aún más costosa.

• Las unidades de disco no son media para archivado. Asumiendo que pueda superar todos los otros problemas asociados con la realización de respaldos a unidades de disco, debería considerar lo


siguiente. La mayoría de las organizaciones tienen varios requerimientos legales para mantener los registros disponibles por cierto tiempo. Las posibilidades de obtener data utilizable desde una cinta de 20 años son mucho más grandes que las posibilidades de hacerlo desde un disco de 20 años. Por ejemplo, ¿tendrá el hardware necesario para conectarlo a su sistema? Otra cosa a considerar esn que una unidad de disco es mucho más compleja que una unidad de cinta. Cuando un motor de 20 años gira un plato de disco de 20 años, causando que los cabezales de lectura/escritura de 20 años vuelen sobre la superficie del plato, ¿cuáles son las posibilidades de que estos componentes funcionen sin problema después de haber estado 20 años sentados sin hacer nada?

Nota

Algunos centros de datos hacen los respaldos a unidades de disco y luego, para propósitos de archivado, copian estos respaldos a unidades de cinta. Esto permite realizar los respaldos más rápidos durante la ventana de respaldo que se tiene. Se puede hacer luego la escritura de los respaldos a las unidades de cinta, durante el resto del día laboral; siempre y cuando la grabación se termine antes de que se realicen los respaldos del próximo día laboral.

Dicho esto, todavía existen algunas situaciones en las que los respaldos a unidades de discos duros tiene sentido. En la próxima sección podemos ver cómo se pueden combinar con una red para formar una solución de respaldo viable (pero costosa).

8.2.4.3. Red

Por sí misma, una red no puede actuar como una media de respaldo. Pero combinada con tecnologías de almacenamiento masivo, puede hacerlo muy bien. Por ejemplo, combinando un enlace de red de gran velocidad a un centro de datos remoto conteniendo grandes cantidades de almacenamiento en disco, repentinamente las desventajas sobre el respaldo a discos mencionadas anteriormente, dejan de ser desventajas.

Al hacer respaldos sobre la red, las unidades de disco ya se encuentran en otra ubicación, fuera del sitio, por lo que no es necesario transportar unidades de discos frágiles a otro lado. Con suficiente ancho de banda, se mantiene la ventaja de la velocidad que puede obtener por hacer los respaldos a discos.

Sin embargo, este enfoque todavía no soluciona el problema del almacenamiento de los archivo (aunque se puede utilizar el mismo enfoque de copiar a las cintas luego de hacer el respaldo, como se mencionó anteriormente). Además, los costos de un centro de datos remoto con un enlace de alta velocidad al centro de datos principal hace esta solución extremadamente costosa. Pero para los tipos de organización que necesitan el tipo de funcionalidades que esta solución ofrece, es un costo que pagarían con gusto.

8.2.5. Almacenamiento de las copias de seguridad o respaldos

Una vez que se termine de hacer el respaldo, que pasa luego? La respuesta obvia es que los respaldos se deben guardar. Sin embargo, lo que no es tan obvio es exactamente qué se debería almacenar - y dónde.

Para responder a estas preguntas, primero debemos considerar bajo qué circunstancias se utilizaran los respaldos. Hay tres situaciones principales:

1. Peticiones de restauración pequeñas y discretas de los usuarios

2. Restauraciones masivas para recuperarse de un desastre

3. Almacenamiento de archivos que raramente se utilizará otra vez


Lamentablemente, hay diferencias irreconciliables entre el primer y segundo caso. Cuando un usuario elimina accidentalmente un archivo, usualmente quiere recuperar su archivo de inmediato. Esto implica que el medio de respaldo no esté más allá que unos pocos pasos del sistema en el cual se restauraran los datos.

En el caso de un desastre que necesita una restauración completa de una o más computadoras en su centro de datos, si el desastre fue de naturaleza física, lo que sea que haya sido destruído también habrá destruído los respaldos que estaban al lado de los computadores. Esto sería una situación muy mala.

El almacenamiento de los archivos es menos controversial; puesto que las posibilidades de que se vuelvan a utilizar son bastante bajas, si la media de respaldo fue ubicada a muchos kilómetros de distancia del centro de datos no habrá realmente ningún problema.

Los enfoques para resolver estas diferencias varían de acuerdo a las necesidades de la organización en el caso. Un acercamiento posible es almacenar varios días de respaldo en el sitio; estos respaldos se toman luego a un sitio de almacenamiento más seguro cuando se creen respaldos diarios más nuevos.

Otro enfoque sería mantener dos fondos diferentes de media:

• Un fondo de provisiones del centro de datos utilizado estrictamente para peticiones de restauración independientes

• Un fondo fuera del sitio utilizado para el almacenamiento fuera del sitio para casos de recuperación en casos de desastres

Por supuesto, el tener dos fondos de datos implica la necesidad de ejecutar todos los respaldos dos veces o de hacer copias de los respaldos. Esto se puede hacer, pero los respaldos dobles pueden tomar bastante tiempo y requieren de múltiples unidades de respaldo para procesar las copias (y probablemente un sistema dedicado para efectuar la copia).

El reto para un administrador de sistemas es el de encontrar un balance que reuna adecuadamente las necesidades de todo el mundo, mientras que se asegura que los respaldos esten disponibles aún en las peores situaciones.

8.2.6. Problemas de restauración

Mientras que los respaldos son una ocurrencia diaria, las restauraciones generalmente son un evento menos frecuente. Sin embargo, las restauraciones son inevitables; seran necesarias, así que es mejor estar preparados.

Lo importante que se debe hacer aquí es ver a los diferentes escenarios de restauración en esta sección y determinar las formas de evaluar su habilidad para llevarlos a cabo en realidad. Tenga en cuenta que el más difícil a evaluar es también el más crítico.

8.2.6.1. Restauración a metal pelado

La frase "restauración a metal pelado" es la forma de describir de un administrador de sistemas el proceso de restaurar un respaldo completo de sistemas en un computador sin datos de ningún tipo en el - sin sistema operativo, sin aplicaciones, nada.

En general, existen dos enfoques para las restauraciones a metal pelado:

Reinstalar, seguido de una restauración

Aquí se instala el sistema operativo base como que si se estuviese configurando una computadora recién comprada. Una vez que el sistema operativo esté configurado adecuadamente, se pueden particionar y formatear los discos duros restantes y restaurar todos los respaldos desde la media.


Discos de recuperación del sistema

Un disco de recuperación del sistema es una media de arranque de algún tipo (a menudo un CD-ROM) que contiene un ambiente de sistemas mínimo, capaz de realizar las tareas básicas de administración del sistema. El ambiente de recuperación contiene las utilidades necesarias para particionar y formatear los discos, los controladores de dispositivos necesarios para acceder el dispositivo de respaldo y el software necesario para restaurar los datos desde la media de respaldo.

Nota

Algunos computadores tienen la capacidad de crear cintas de respaldo de arranque y utilizarlas para arrancar desde ellas e iniciar el proceso de restauración. Sin embargo, esta capacidad no está disponible en todos los computadores. Más aún, las computadoras basadas en la arquitectura de PC no se prestan para este enfoque.

8.2.6.2. Evaluar respaldos

Cada tipo de respaldo debería ser evaluado de forma periódica para asegurarse de que los datos se pueden leer. Es un hecho que algunas veces se realizan los respaldos que son, de una forma u otra, ilegibles. La parte desafortunada en todo esto es que muchas veces esto no se nota hasta que los datos se pierden y se deben restaurar desde el respaldo.

Las razones para esto pueden variar desde cambios en la alineación de los cabezales de la unidad de cinta, software de respaldo mal configurado o un error del operador. No importa la causa, sin las revisiones periódicas usted no puede estar seguro de si está generando respaldos a partir de los cuales se puedan restaurar los datos más adelante.

8.3. Recuperación de desastres

Como experimento, la próxima vez que esté en su centro de datos, mire a su alrededor e imagine por un momento que no hay nada. Y no solamente los computadores. Imagínese que el edificio completo ya no existe. Luego, imagine que su trabajo es recuperar la mayor cantidad de trabajo realizado posible en el centro de datos, lo más pronto posible. ¿Qué haría?

Al pensar desde esta perspectiva, usted está dando su primer paso hacia la recuperación de desastres. La recuperación de desastres es la habilidad de recuperarse de un evento que impacta el funcionamiento del centro de datos de su organización lo más rápido y completo posible. El tipo de desastre puede variar, pero el objetivo final es siempre el mismo.

Los pasos relacionados con la recuperación a partir de un desastre son numerosos y con un rango bien amplio. A continuación se muestra una descripción general a un nivel alto del proceso, junto con los puntos claves a tener en mente.

8.3.1. Creación, Evaluación e Implementación de un Plan de Recuperación de Desastres

Un sitio de respaldo es vital, sin embargo es inútil sin un plan de recuperación de desastres. Un plan de recuperación de desastres indica cada faceta del proceso de recuperación, incluyendo (pero no limitado) a:


• Los eventos que denotan posibles desastres

• Las personas en la organización que tienen la autoridad para declarar un desastre y por ende, colocarel plan en efecto

• La secuencia de eventos necesaria para preparar el sitio de respaldo una vez que se ha declarado undesastre

• Los papeles y responsabilidades de todo el personal clave con respecto a llevar a cabo el plan

• Un inventario del hardware necesario y del software requerido para restaurar la producción

• Un plan listando el personal a cubrir el sitio de respaldo, incluyendo un horario de rotación parasoportar las operaciones contínuas sin quemar a los miembros del equipo de desastres

• La secuencia de eventos necesaria para mover las operaciones desde el sitio de respaldo alnuevo/restaurado centro de datos

Los planes de recuperación de desastres a menudo llenan mútiples carpetas de hojas sueltas. Estenivel de detalle es vital porque en el evento de una emergencia, el plan quizás sea lo único que quedede su centro de datos anterior (además de los otros sitios de respaldo, por supuesto) para ayudarlo areconstruir y restaurar las operaciones.

Sugerencia

Mientras que los planes de recuperación de desastres deberían de estar a la mano en su sitiode trabajo, también se deberían conservar copias fuera de sus instalaciones. De esta forma, si undesastre destruye sus instalaciones no se eliminaran todas las copias de su plan de recuperación. Unbuen lugar para almacenar una copia es en su ubicación de almacenamiento de respaldos. Tambiénse pueden mantener copias del plan de recuperación de desastres en los hogares de miembrosclaves de equipo, siempre y cuando esto no viole las políticas de seguridad de la empresa.

Un documento de tal importancia merece una consideración bien seria (y posiblemente asistenciaprofesional para su creación).

Una vez que este documento es creado, el conocimiento que contiene debe ser evaluado periódica-mente. Evaluar un plan de recuperación de desastres implica seguir los pasos del plan: ir al sitio derespaldo y configurar el centro de datos temporal, ejecutar las aplicaciones temporalmente y reactivarlas operaciones normales después de que el "desastre" termine. La mayoría de las pruebas no tratande llevar a cabo un 100% de las tareas del plan; en cambio, se selecciona un sistema y una aplicaciónrepresentativa para reubicarlos en el sitio de respaldo, se coloca en producción por un período detiempo y se lleva a operación normal al final de la prueba.

Nota

Aunque puede sonar como una frase gastada, un plan de recuperación de desastres debe ser undocumento vivo; a medida que el centro de datos cambie, el plan debe ser actualizado para reflejaresos cambios. En muchas casos, un plan de recuperación de desastres desactualizado puede serpeor que no tener ninguno, por lo tanto, haga revisiones y actualizaciones regulares (trimestrales,por ejemplo) del plan.

8.3.2. Sitios de respaldo: frío, templado y calienteUno de los aspectos más importantes del plan de recuperación de desastres es tener una ubicacióndesde la cual este puede ser ejecutado. Esta ubicación se conoce como sitio de respaldo. En el evento


de un desastre, el sitio de respaldo es donde se recreará su centro de datos y desde donde usted operará, durante el mismo.

Hay tres tipos diferentes de sitios de respaldo:

• Sitios de respaldo frios

• Sitios de respaldo templado

• Sitios de respaldo calientes

Obviamente estos términos no se refieren a la temperatura del sitio de respaldo. Se refieren en realidad al esfuerzo requerido para comenzar las operaciones en el sitio de respaldo en el evento de un desastre.

Un sitio de respaldo frío es simplemente un espacio en un edificio configurado apropiadamente. Todo lo que se necesite para restaurar el servicio a sus usuarios se debe conseguir y entregar a este sitio antes de comenzar el proceso de recuperación. Como se puede imaginar, el retraso de ir desde un sitio frío a uno en operación completa puede ser sustancial.

Los sitios de respaldo frío son los menos costosos.

Un sitio tibio ya está equipado con el hardware representando una representación fiel de lo encontrado en su centro de datos. Para restaurar el servicio, se deben despachar los últimos respaldos desde sus instalaciones de almacenamiento fuera del sitio y completar un restauración a metal pelado, antes de que pueda comenzar el trabajo real de recuperación.

Los sitios de respaldo calientes tienen una imagen espejo virtual de su centro de datos, con todos los sistemas configurados y esperando solamente por los últimos respaldos de los datos de sus usuarios desde las facilidades de almacenamiento fuera del sitio. Como se puede imaginar, un sitio de respaldo caliente se puede poner en funcionamiento completo en unas pocas horas.

Un sitio de respaldo caliente comprende el enfoque más costoso para una recuperación de desastres.

Los sitios de respaldo pueden provenir de tres fuentes diferentes:

• Compañías especializadas en suministrar servicios de recuperación de desastres

• Otras ubicaciones que pertenecen y son operadas por la organización

• Un acuerdo mutuo con otra organización para compartir las facilidades del centro de datos en el evento de un desastre

Cada enfoque tiene sus puntos buenos y malos. Por ejemplo, haciendo un contrato con una firma de recuperación de desastres a menudo trae consigo el acceso a profesionales con la experiencia necesaria para guiar a las organizaciones a través del proceso de creación, evaluación e implementación de un plan de recuperación de desastres. Como se puede imaginar, estos servicios tienen su costo.

El uso de otras instalaciones que pertenecen y son operadas por su organización, pueden ser esencialmente una opción de costo cero, pero el surtir el sitio de respaldo y mantener su disponibilidad inmediata es una proposición costosa.

Preparar un acuerdo para compartir centros de datos con otra organización puede ser extremadamente económico, pero usualmente las operaciones a largo plazo bajo estas condiciones no son posibles, pues probablemente el centro de datos anfitrión todavia continua su producción normal, haciendo la situación incómoda en el mejor de los casos.

Por otro lado, la selección del sitio de respaldo es un acuerdo entre los costos y la necesidad de su organización por la continuación de las operaciones.

8.3.3. Disponibilidad del Hardware y Software

Su plan de recuperación de desastres debe incluir métodos para conseguir el hardware y software necesarios para las operaciones en el sitio de respaldo. Un sitio de respaldo manejado profesionalmente


quizás ya tenga todo lo que usted necesita (o quizás tenga que organizar la adquisición y entrega de materiales especializados que el sitio no tiene disponibles); por otro lado, un sitio de respaldo frío implica que se tienen identificadas las fuentes para cada ítem requerido. A menudo las organizaciones trabajan directamente con los fabricantes para establecer acuerdos para la entrega inmediata de hardware y/o software en el evento de un desastre.

8.3.4. Disponibilidad de los respaldos

Cuando se declara un desastre, es necesario notificarlo a sus instalaciones de almacenamiento fuera de sitio por dos razones:

• Para enviar los últimos respaldos al sitio de respaldo

• Para coordinar entregas de respaldos regulares al sitio de respaldo (en soporte a los respaldos normales en el sitio de respaldo)

Sugerencia

En el evento de un desastre, el último respaldo que se tiene de su centro de datos viejo, es de vital importancia. Considere realizar copias de este antes de hacer alguna otra cosa, y luego enviando los originales fuera del sitio lo más pronto posible.

8.3.5. Conectividad de red al sitio de respaldo

Un centro de datos no es de mucha ayuda si se encuentra desconectado del resto de la organización que está sirviendo. Dependiendo del plan de recuperación de desastres y de la naturaleza del mismo, su comunidad de usuarios puede estar ubicada a kilómetros de distancia del sitio de respaldo. En estos casos, una buena conectividad es vital para restaurar la producción.

Otro tipo de conectividad a tener en mente es la conectividad telefónica. Debe asegurarse de que existen suficientes líneas telefónicas disponibles para manejar todas las comunicaciones verbales con sus usuarios. Lo que antes podía ser un grito por encima de la pared de un cubículo ahora implica una conversación telefónica de larga distancia; por lo tanto, planee para tener más conectividad telefónica de la que pudiera parecer necesaria en un principio.

8.3.6. Personal del sitio de respaldo

El problema sobre conseguir el personal para su sitio de respaldo es multidimensional. Un aspecto del problema es determinar el personal requerido para poner a funcionar el centro de datos de respaldo por el tiempo que sea necesario. Mientras que un equipo esquelético puede mantener las cosas en funcionamiento por un corto período de tiempo, a medida que el desastre se extiende se necesitará más y más gente para continuar el esfuerzo necesario para funcionar bajo las circunstancias extraordinarias que rodean un desastre.

Esto implica asegurarse de que el personal tiene tiempo suficiente para descansar y posiblemente viajar de regreso a sus hogares. Si el desastre fuese tan extendido que afecte también los hogares y familias de la gente, se necesitará tiempo adicional para permitirles manejar su propia recuperación de desastre. Se necesita alojamiento temporal cerca del sitio de respaldo, junto con el transporte requerido para movilizar a la gente entre el sitio de respaldo y su alojamiento.

A menudo un plan de recuperación de desastres incluye que trabaje en el sitio un personal representativo de todas las partes de la comunidad de usuarios de la organización. Esto depende en la habilidad


de su organización de operar con un centro de datos remoto. Si los usuarios representantes deben trabajar en el sitio de respaldo, también deben estar disponibles facilidades similares para ellos.

8.3.7. Regreso a la normalidad

Eventualmente todos los desastres terminan. El plan de recuperación de desastres debe tomar en cuenta esta fase también. El nuevo centro de datos debe ser equipado con todo el software y hardware necesario; mientras que esta fase a menudo no tiene la naturaleza crítica de las preparaciones efectuadas cuando se declaró inicialmente el desastre, los sitios de respaldo cuestan dinero cada día que son utilizados, por lo que las preocupaciones económicas dicatarán que el cambio se lleve a cabo lo más pronto posible.

Se deben hacer y entregar los últimos respaldos desde el sitio de respaldo al nuevo centro de datos. Después de almacenarlos en el nuevo hardware, se puede reactivar la producción en el nuevo centro de datos.

En este punto se puede desarmar el centro de datos de respaldo, con la sección final del plan indicando la disposición de todo el hardware temporal. Finalmente, se hace una revisión de la efectividad del plan, integrando cualquier cambio recomendado por el comité de revisión en una versión actualizada del plan.


Hay poco sobre el tópico general de desastres y su recuperación que tenga un impacto directo en cualquier sistema operativo específico. Después de todo, las computadoras en un centro de datos inundado estaran inoperativas bien sea que ejecuten Red Hat Enterprise Linux o cualquier otro sistema operativo. Sin embargo, hay partes de Red Hat Enterprise Linux que se relacionan con aspectos específicos de la recuperación de desastres; estos aspectos se discuten en esta sección.

8.4.1. Soporte de Software

Como fabricante de software Red Hat tiene varias opciones de soporte para sus productos, incluyendo Red Hat Enterprise Linux. En estos momentos usted está utilizando la herramienta más básica de soporte al leer este manual. La documentación para Red Hat Enterprise Linux está disponible en el CD de Documentación de Red Hat Enterprise Linux (el cual también se puede instalar en su sistema para un acceso rápido), en forma impresa y en el sitio web de Red Hat en http://www.redhat.com/docs/.

Las opciones de auto asistencia están disponibles a través de varias listas de correo hospedadas por Red Hat (disponibles en https://www.redhat.com/mailman/listinfo). Estas listas de correo aprovechan el conocimiento combinado de la comunidad de usuarios de Red Hat; además, muchas listas son monitorizadas por personal de Red Hat, que contribuyen cuando el tiempo se los permite. También están disponibles otros recursos desde la página principal de soporte de Red Hat en http://www.redhat.com/apps/support/.

Existen opciones de soporte más completas; se puede encontrar información sobre ellas en el sitio web de Red Hat.

8.4.2. Tecnologías de respaldo

Red Hat Enterprise Linux viene con diferentes programas para el respaldo y recuperación de datos. Por sí mismos, estos programas de utilidades no constituyen una solución de respaldo completa. Sin embargo, se pueden utilizar como el núcleo de tal situación.


Nota

Como se comentó en la Sección 8.2.6.1, la mayoría de las computadoras basadas en la arquitectura de PC estándar, no tienen la funcionalidad necesaria para arrancar directamente desde una cinta. En consecuencia, Red Hat Enterprise Linux no es capaz de realizar un arranque desde cinta cuando se esté ejecutando en hardwares de este tipo.

Sin embargo, es posible utilizar su CD-ROM de Red Hat Enterprise Linux como un ambiente de recuperación del sistema. Para más información vea el capítulo sobre recuperación básica del sistema en el Manual de administración del sistema de Red Hat Enterprise Linux .

8.4.2.1. tar

La utilidad tar es bien conocida entre los administradores UNIX. Es el método de archivado preferido para compartir bits de código fuente y archivos entre sistemas. La implementación tar incluída con Red Hat Enterprise Linux es GNU tar, una de las implementaciones de tar más ricas en funcionalidades.

Usando tar, el respaldo de los contenidos de un directorio puede ser tan simple como ejecutar un comando similar a lo siguiente:

tar cf /mnt/backup/home-backup.tar /home/

Este comando crea un fichero de archivos llamado home-backup.tar en /mnt/backup/. El fichero incluye los contenidos del directorio /home/.

El archivo resultante será casi tan grande como hacer un respaldo de los datos. Dependiendo del tipo de datos que se están respaldando, se puede también comprimir el archivo para reducir su tamaño. El archivo de respaldo se puede comprimir añadiendo una opción al comando anterior.

tar czf /mnt/backup/home-backup.tar.gz /home/

El fichero de archivos home-backup.tar.gz resultante es ahora comprimido con gzip5 .

Hay muchas otras opciones para tar; para aprender más sobre ellas, lea la página man de tar(1).

8.4.2.2. cpio

La utilidad cpio es otro programa UNIX tradicional. Es un excelente programa de propósito general para mover datos de un lugar a otro y, como tal, puede servir muy bien como un programa para hacer respaldos.

El comportamiento de cpio es ligeramente diferente a tar. A diferencia de tar, cpio lee los nombres de los archivos que va a procesar a través de la entrada estándar. Un método común para generar una lista de archivos para cpio es utilizar un programa como find cuya salida se puede entubar a cpio:

find /home/ | cpio -o � /mnt/backup/home-backup.cpio

Este comando crea un fichero de archivos cpio (que contiene todo lo que hay en /home/) llamado home-backup.cpio en el directorio /mnt/backup/.

5. La extensión .gz se utiliza tradicionalmente para identificar que los archivos han sido comprimidos con

gzip. Algunas veces .tar.gz se acorta con .tgz para mantener los nombres de archivos en un tamaño

razonable.


Sugerencia

Como find tiene un conjunto de pruebas de selección de archivos muy rico, se pueden realizar respaldos sofisticados. Por ejemplo, el comando siguiente realiza un respaldo solamente de los archivos que no se accesaron el año pasado.

find /home/ -atime +365 | cpio -o � /mnt/backup/home-backup.cpio

Hay muchas otras opciones para cpio (y find); para conocer un poco más sobre ellas, lea las páginas man de cpio(1) y de find(1).

8.4.2.3. dump/restore: Atención: No se recomienda para sistemas de archivos montados. Los programas dump y restore son los equivalentes de Linux a los programas de UNIX con el mismo nombre. Como tales, muchos administradores de sistemas con experiencia UNIX pueden pensar que dump y restore son candidatos aceptables para un buen programa de respaldo bajo Red Hat Enterprise Linux. Sin embargo, un método de usar dump puede causar problemas. He aquí un comentario de Linus Torvald sobre este tema:

From: Linus TorvaldsTo: Neil ConwaySubject: Re: [PATCH] SMP race in ext2 - metadata corruption.Date: Fri, 27 Apr 2001 09:59:46 -0700 (PDT)Cc: Kernel Mailing List � linux-kernel At vger Dot kernel Dot org �

[ linux-kernel added back as a cc ]

On Fri, 27 Apr 2001, Neil Conway wrote: �� I’m surprised that dump is deprecated (by you at least ;-)). What to � use instead for backups on machines that can’t umount disks regularly?

Note that dump simply won’t work reliably at all even in 2.4.x: the buffercache and the page cache (where all the actual data is) are notcoherent. This is only going to get even worse in 2.5.x, when thedirectories are moved into the page cache as well.

So anybody who depends on "dump" getting backups right is already playingRussian roulette with their backups. It’s not at all guaranteed to get theright results - you may end up having stale data in the buffer cache thatends up being "backed up".

Dump was a stupid program in the first place. Leave it behind.

� I’ve always thought "tar" was a bit undesirable (updates atimes or � ctimes for example).

Right now, the cpio/tar/xxx solutions are definitely the best ones, and will work on multiple filesystems (another limitation of "dump"). Whatever problems they have, they are still better than the _guaranteed_(*) data corruptions of "dump".

However, it may be that in the long run it would be advantageous to have a "filesystem maintenance interface" for doing things like backups and defragmentation..


Linus

(*) Dump may work fine for you a thousand times. But it _will_ fail under the right circumstances. And there is nothing you can do about it.

Dado este problema, el uso de dump/restore en sistemas de archivos montados no se recomienda para nada. Sin embargo, dump originalmente fue diseñado para respaldar sistemas de archivos desmontados; por lo tanto, en situaciones donde es posible tomar un sistema de archivos fuera de línea con umount, dump sigue siendo una tecnología de respaldos viable.

8.4.2.4. El Advanced Maryland Automatic Network Disk Archiver (AMANDA) AMANDA es una aplicación de respaldos basada en cliente/servidor producida por la Universidad de Maryland. Teniendo una arquitectura cliente/servidor, un simple servidor de respaldo (normalmente un sistema sustancialmente poderoso con bastante espacio libre, discos rápidos y configurado con el dispositivo de respaldo deseado) puede respaldar muchos sistemas clientes, que solamente necesitan el software cliente AMANDA.

Este enfoque hacia los respaldos tiene mucho sentido, pues concentra los recursos necesarios para los respaldos en un sistema, en vez de requerir hardware adicional para cada sistema que requiere servicios de respaldo. El diseño de AMANDA también sirve para centralizar la administración de los respaldos, haciendo más fácil la vida del administrador del sistema.

El servidor AMANDA maneja un fondo de media de respaldo y rota su uso a través de este fondo para asegurarse de que todos los respaldos son guardados por el período de retención dictado por el administrador. Toda la media está preformateada con datos que permiten a AMANDA detectar si la media adecuada está disponible o no. Además, AMANDA puede interactuar con media robótica para el cambio de unidades, haciendo posible automatizar completamente los respaldos.

AMANDA puede utilizar tar o dump para hacer los respaldos (aunque bajo Red Hat Enterprise Linux es preferible el uso de tar, debido a los problemas con dump mencionados en la Sección 8.4.2.3). Como tal, los respaldos de AMANDA no requieren AMANDA para su respaldo - una ventaja considerable.

En operación, AMANDA normalmente es planificada para ejecutarse una vez al día durante la ventana de respaldo del centro de datos. El servidor AMANDA se conecta a los sistemas clientes y los dirige a producir tamaños estimados de los respaldos a realizar. Una vez que estén disponibles todos los estimados, el servidor construye un horario, determinando automáticamente el orden en el cual se hará el respaldo de los sistemas.

Una vez que comiencen los respaldos, los datos son enviados sobre la red desde el cliente al servidor, donde son almacenados en un disco temporal. Una vez terminado el respaldo, el servidor comienza a escribirlo fuera del dico temporal a la media de respaldo. Al mismo tiempo, los otros clientes envían sus respaldos al servidor para su almacenamiento en el disco temporal. Esto resulta en una corriente contínua de datos disponibles para escritura a la media de respaldo. A medida que se escriben los respaldos a la media, se van eliminando del disco temporal del servidor.

Una vez completados todos los respaldos, se envía un correo electrónico al administrador del sistema con un informe del estado de los respaldos, haciendo la revisión fácil y rápida.

Si es necesario restaurar los datos, AMANDA contiene un programa de utilidades que permite al operador identificar el sistema de archivos, fecha y nombre(s) de archivo(s). Una vez que se hace esto, AMANDA identifica la media de respaldo correcta y luego ubica y restaura los datos deseados. Como se mencionó anteriormente, el diseño de AMANDA también hace posible restaurar los datos aún sin la asistencia de AMANDA, aunque la identificación de la media correcta sería un proceso manual y más lento.

Esta sección solamente menciona los conceptos más básicos de AMANDA. Para una investigación más profunda sobre AMANDA, comience por la página man amanda(8).



Esta sección incluye varios recursos que se pueden utilizar para conocer un poco más sobre la recuperación de desastres y la materia específica a Red Hat Enterprise Linux discutida aquí.


Los recursos siguientes se copian durante el curso de una instalación de Red Hat Enterprise Linux típica y lo pueden ayudar a aprender más sobre la materia discutida.

• Página man de tar(1) — Aprenda a archivar datos

• Página man de dump(8) — Conozca cómo descargar los contenidos de un sistema de archivos.

• Página man de restore(8) — Aprenda a recuperar los contenidos de un sistema de archivos guardado con dump.

• Página man de cpio(1) — Aprenda a copiar archivos desde y hacia archivos.

• Página man de find(1) — Conozca cómo buscar archivos.

• Página man de amanda(8) — Conozca los comandos que forman parte del sistema de respaldo AMANDA.

• Los archivos en /usr/share/doc/amanda-server- � version � / — Conozca sobre AMANDA revisando estos documentos y archivos de ejemplo.


• http://www.redhat.com/apps/support/ — La página de soporte de Red Hat suministra acceso fácil a los diferentes recursos relacionados al soporte de Red Hat Enterprise Linux.

• http://www.disasterplan.com/ — Una página interesante con enlaces a muchos sitios relacionados a la recuperación de desastres. Incluye un plan de recuperación de desastres de ejemplo.

• http://web.mit.edu/security/www/isorecov.htm — La página principal del Massachusetts Institute of Technology Information Systems Business Continuity Planning contiene muchos enlaces informativos.

• http://www.linux-backup.net/ — Una vista general interesante de muchos problemas relacionados al respaldo.

• http://www.linux-mag.com/1999-07/guru_01.html — Un artículo muy bueno de Linux Magazine sobre los aspectos más técnicos de la producción de respaldos bajo Linux.

• http://www.amanda.org/ — La página web de Advanced Maryland Automatic Network Disk Archiver (AMANDA). Contiene punteros a las diferentes listas de correo de AMANDA y otros recursos en línea.


Los libros siguientes discuten diferentes aspectos de la recuperación de desastres y son buenos recursos para los administradores de sistemas Red Hat Enterprise Linux.

• El Manual de administración del sistema de Red Hat Enterprise Linux; de Red Hat, Inc. — Incluye un capítulo sobre la recuperación del sistema, lo que podría ser útil en restauraciones en metal pelado.


• Unix Backup & Recovery por W. Curtis Preston; O’Reilly & Associates — Aunque no está escrito para sistemas Linux, este libro proporciona una cobertura completa sobre los muchos problemas relacionados con el respaldo y hasta incluye un capítulo para la recuperación de desastres.

Índice

Símbolos

/etc/cups/, 150/etc/printcap, 150

A

abuso de recursos, 133abuso, recursos, 133activación de su suscripción, ivadministración

impresoras, 143administración de sistemas

filosofía de, 1automatización, 1comunicación, 3documentación, 2ingeniería social, riesgos de, 7negocio, 6ocurrencias inesperadas, 8planificación, 8recursos, 6seguridad, 7usuarios, 6

administración de volúmenes lógicos (Ver LVM)

almacenamiento accesible a través de la red, 79, 105

NFS, 106SMB, 106

administración de, 63, 87crecimiento, normal, 89monitorizar espacio libre, 87problemas de usuarios, 88uso de una aplicación, 89uso excesivo de, 87

añadir, 92, 107/etc/fstab, actualización, 109configuración, actualizar, 96Discos duros ATA, 93formatear, 96, 109hardware, instalación, 92particionamiento, 95, 107planificación de respaldos, modificar, 96Unidad de dico SCSI, 94

basado en RAID(Ver RAID)

cuotas de usuarios, 90(Ver cuotas de usuarios)

dispositivos de almacenamiento masivobrazos de acceso, 64cabeza, 66

cabezas, 64cabezas de escritura, 72cabezas de lectura, 72cargas de E/S, escrituras, 73cargas de E/S, lecturas, 73cargas de E/S, rendimiento, 73cilindro, 66conceptos de direccionamiento, 65direcciones basadas en bloques, 67direcciones basadas en geometría, 65direcciones, basadas en bloques, 67direcciones, basados en la geometría, 65geometría, problemas con, 66interfaces con estándares de la industria, 68interfaces para, 67interfaces, estándar de la industria, 68interfaces, historia, 67Interfaz IDE, 68Interfaz SCSI, 69latencia rotacional, 72latencia, rotacional, 72lectores contra escrituras, 73limitaciones eléctricas de, 71limitaciones mecánicas de, 71movimiento del brazo de acceso, 72movimiento, brazo de acceso, 72platos de disco, 63platos, disco, 63procesamiento de comandos, 72procesamiento, comando, 72rendimiento de, 71sector, 66Ubicación de E/S, 74vista general de, 63

eliminar, 96, 109/etc/fstab, eliminar de, 110borrar los contenidos, 97, 110comando umount, uso de, 110datos, eliminar, 97

implementación, 74monitorizar el, 19partición

atributos de, 75campo tipo, 76extendidas, 75geometría de, 75lógicas, 76primaria, 75tipo de, 75vista general de, 74

patrones de acceso, 49problemas relacionados a archivos, 90

acceso a archivos, 90compartir archivos, 91

sistema de archivos, 76, 100activando acceso a, 79

190

archivo /etc/mtab , 104archivo /proc/mounts , 104basado en archivos, 76comado df, uso de, 105contabilidad del espacio, 78contabilidad, espacio, 78control de acceso, 77directorio jerárquico, 77directorios, 77estructura, directorio, 78EXT2, 101EXT3, 101ISO 9660, 101montaje, 102montar con el archivo /etc/fstab, 106mostrar lo montado, 103MSDOS, 102punto de montaje, 103tiempos de acceso, 77tiempos de creación, 77tiempos de modificación, 77VFAT, 102

tecnologías, 49 almacenamiento fuera de línea, 53 almacenamiento para respaldos, 53 disco duro, 52 L1 cache, 51 L2 cache, 51 memoria caché, 50 memoria principal, 51 RAM, 51 Registros de CPU, 50 unidad de disco, 52

tecnologías, avanzadas, 79 archivo /etc/fstab

actualización, 109 montar sistemas de archivos con, 106

archivo /etc/group cuenta de usuario, papel en, 138 grupo, papel en, 138

archivo /etc/gshadow cuenta de usuario, papel en, 138 grupo, papel en, 138

archivo /etc/mtab , 104 archivo /etc/passwd

cuenta de usuario, papel en, 136 grupo, papel en, 136

archivo /etc/shadow cuenta de usuario, papel en, 136 grupo, papel en, 136

archivo /proc/mdstat, 117 archivo /proc/mounts , 104 automatización, 9

descripción general, 1

B

bash shell, automatización y, 9

C

CD-ROM sistema de archivos

(Ver Sistema de archivos ISO 9660) comando chage, 139 comando chfn, 139 comando chgrp, 140 comando chmod, 140 comando chown, 140 comando chpasswd, 139 comando df , 105 comando free, 21, 58 comando gnome-system-monitor, 22 comando gpasswd, 139 comando groupadd, 139 comando groupdel, 139 comando groupmod, 139 comando grpck, 139 comando iostat, 24, 40 comando mpstat, 24 comando passwd, 139 comando raidhotadd, uso de, 117 comando sa1, 24 comando sa2, 24 comando sadc , 24 comando sar, 24, 26, 41, 43, 59

informes, lectura, 27 comando top, 20, 21, 42 comando useradd, 139 comando userdel, 139 comando usermod, 139 comando vmstat, 20, 23, 40, 43, 59 comando watch, 21 comunicación

Información específica a Red Hat Enterprise Linux,10necesidad de, 3

configuración de impresoras, 149 aplicación basada en texto, 150 CUPS, 149

conjunto de direcciones de trabajo, 56 contraseña, 124

caducidad, 128 conjunto de caracteres grande usado en, 128 conjunto de caracteres pequeño usado en, 126 corta de, 125 débiles, 125 escritas, 127 información personal usada en, 126 largas, 127 memorizables, 128

191

palabras usadas en, 126robustas, 127trucos de palabras usados en, 126usado repetidamente, 127

control de cambios, 170convenciones

documento, iicuenta

(Ver cuenta de usuario)cuenta de usuario

acceso a datos compartidos, 131administración de, 121, 121, 129

cambios de trabajo, 131nuevos empleados, 129terminaciones, 130

archivos controlando, 136/etc/group, 138/etc/gshadow, 138/etc/passwd, 136/etc/shadow, 136

contraseña, 124caducidad, 128conjunto de caracteres grande usado en, 128conjunto de caracteres pequeño usado en, 126corta de, 125débiles, 125escritas, 127información personal usada en, 126largas, 127memorizables, 128palabras usadas en, 126robustas, 127trucos de palabras usados en, 126usado repetidamente, 127

control de acceso, 129directorio principal

centralizado, 133GID, 135GIDs del sistema, 135herramientas para administrar, 139

comando chage, 139comando chfn, 139comando chpasswd, 139comando passwd, 139comando useradd, 139comando userdel, 139comando usermod, 139

nombre de usuario, 121cambios a, 123colisiones en nombres, 122convenio de nombres, 121

permisos relacionados a, 134ejecución, 134escritura, 134lectura, 134setgid, 134

setuid, 134sticky bit, 134

recursos, administración de, 131UID, 135UIDs del sistema, 135

cuotas de usuariosactivando, 113administración de, 114introducción a, 111vista general de, 111

específico a grupos, 112específico al sistema de archivos, 112específico al usuario, 112límite suave, 113límites rígidos, 113período de gracia, 113seguimiento de uso de bloques, 112seguimiento de uso de inodes, 112

cuotas, disco(Ver cuotas de usuarios)

CUPS, 149

D

datosacceso compartido a, 131, 132

problemas globales de propiedad, 133devlabel, 100directorio principal

centralizado, 133directorio principal centralizado, 133discos duros, 52Discos duros ATA

añadir, 93dispositivo

accesos a dispositivos completos, 99alternativas a nombres de dispositivos, 99convención de nombres, 98devlabel, nombrar con, 100etiquetas de sistemas de archivos, 100etiquetas, sistemas de archivos, 100nombres con devlabel, 100nombres de archivos, 98nombres de dispositivos, alternativas a, 99partición, 99tipo, 98unidad, 99

documentaciónInformación específica a Red Hat Enterprise Linux,10

documentación, necesidad de, 2

192

E

espacio de direcciones virtuales, 55

espacio en disco

(Ver almacenamiento)estadísticas de supervisión

relacionado a la memoria, 19

relacionado al almacenamiento, 19

relacionado al ancho de banda, 18

relacionado al CPU, 17

selección de, 17

F

fallo de página, 56

filosofía de la administración de sistemas, 1

G

GID, 135

grupo

acceso a datos compartidos usando, 132

administración de, 121

archivos controlando, 136

/etc/group, 138

/etc/gshadow, 138

/etc/passwd, 136

/etc/shadow, 136

estructura, determinar, 132

GID, 135

GIDs del sistema, 135

herramientas para administrar, 139

comando gpasswd, 139

comando groupadd, 139

comando groupdel, 139

comando groupmod, 139

comando grpck, 139

permisos relacionados a, 134

ejecución, 134

escritura, 134

lectura, 134

setgid, 134

setuid, 134

sticky bit, 134

UID, 135

UIDs del sistema, 135

H

hardware contratos de servicios, 155

disponibilidad de partes, 158hardware cubierto, 158horas de cobertura, 155presupuesto para, 158servicio de depósito, 156servicio drop-off, 156servicio walk-in, 156tiempo de respuesta, 157técnico in-situ, 157

fallas de, 153habilidades necesarias para reparar, 153repuestos

intercambiar hardware, 155mantener, 153repuestos, cantidades, 154repuestos, selección de, 154

Herramienta de configuración de impresoras (Ver configuración de impresoras)

herramientas cuentas de usuario, administrar

(Ver cuentas de usuario, herramientas para administrar)

grupos, administración (Ver grupo, herramientas para administrar)

supervisión de recursos, 20free, 21iostat, 24Monitor del Sistema GNOME, 22mpstat, 24OProfile, 28sa1, 24sa2, 24sadc, 24sar, 24, 26Sysstat, 24top, 21vmstat, 23

IID del grupo

(Ver GID) ID del usuario

(Ver UID) impresoras

administración, 143color, 146

CMYK, 146inyección de tinta, 146láser, 147

consideraciones, 143duplex, 143

193

lenguajes (Ver lenguajes de descripción de páginas (PDL))

local, 149recursos adicionales, 151red, 149tipos, 143

cera termal, 148impacto, 144inyección de tinta, 146láser, 147láser a color, 147línea, 144margarita, 144matriz de puntos, 144sublimación de tinte, 148tinta sólida, 148

impresoras a color láser, 147impresoras de impacto, 144

consumibles, 146línea, 144margarita, 144matriz de puntos, 144

impresoras de inyección de tinta, 146consumibles, 146

impresoras de línea(Ver impresoras de impacto)

impresoras de margarita(Ver impresoras de impacto)

impresoras de matriz de puntos(Ver impresoras de impacto)

impresoras láser, 147color, 147consumibles, 147

inesperado, preparación para lo, 8Información específica a Red Hat Enterprise Linux

automatización, 9bash shell, 9comunicación, 10documentación, 10herramientas de supervisión de recursos

iostat, 40sar, 41, 43top, 42vmstat, 40, 43

herramientas para monitorizar recursos, 20free, 20OProfile, 20Sysstat, 20top, 20vmstat, 20

monitorizar recursosancho de banda , 40Poder de CPU, 40

PAM, 10perl, 9

recuperación de desastres, 183

RPM, 10

seguridad, 10

shell scripts, 9

sistemas de detección de intrusos, 10

soporte de software, 183

soporte, software, 183

tecnologías de respaldo

AMANDA, 186

cpio, 184

descripción general, 183

dump, 185

tar, 184

información específica de Red Hat Enterprise Linux

herramientas de supervisión de recursos

free, 58

sar, 59

vmstat, 59

supervisión de recursos

memoria, 58

ingeniería social, riesgos de, 7

ingeniería, social, 7

intercambio, 57

Interfaz IDE

vista general de, 68

Interfaz SCSI


L

lenguajes de descripción de páginas (PDL), 148

Interpress, 148

PCL, 148

PostScript, 148

lpd, 151

LVM

agrupamiento de almacenamiento, 86

comparado con RAID, 87

migración de datos, 86

migración, datos, 86

redimensionamiento de volúmenes lógicos, 86

redimensionamiento, volumen lógico, 86


194

M

memoria memoria virtual, 54

almacenamiento de respaldo, 55conjunto de direcciones de trabajo, 56descripción general de, 54espacio de direcciones virtuales, 55fallo de página, 56intercambio, 57rendimiento de, 57rendimiento, mejor caso, 58rendimiento, peor caso, 57

monitorizar el, 19utilización de recursos de, 49

memoria caché, 50memoria física

(Ver memoria) memoria virtual

(Ver memoria)monitorizar el rendimiento del sistema, 16montaje de sistemas de archivos

(Ver almacenamiento, sistemas de archivos, montaje)

multiprocesamiento simétrico, 39

N

negocio, conocimiento de, 6NFS, 106nombre de usuario, 121

cambio, 123colisiones entre, 122convenio de nombres, 121

nombres de archivosdispositivo, 98

O

OProfile, 20, 28

P

PAM, 10partición, 99

atributos de, 75campo tipo, 76geometría, 75tipo, 75

creación de, 95, 107extendidas, 75lógicas, 76primaria, 75vista general de, 74

perl, automatización y, 9

permiso de ejecución, 134permiso de escritura, 134permiso de lectura, 134permiso de sticky bit, 134permiso setgid, 10, 134permiso setuid, 10, 134permisos, 134

herramientas para administrarcomando chgrp, 140comando chmod, 140comando chown, 140

planificación de la capacidad, 16planificación para desastres, 153

energía, reserva, 164conjunto moto-generador, 164generador, 166interrupciones, prolongadas, 166UPS, 165

tipos de desastre , 153aire acondicionado, 167aplicaciones usadas incorrectamente, 168bloqueos del sistema operativo, 159calefacción, 167caídas del sistema operativo, 159electricidad, calidad de, 163electricidad, seguridad de, 162eléctrical, 162errores de configuración, 169errores de operadores, 168errores de procedimientos, 168errores de servicio técnico, 171errores de usuarios, 168errores del administrador de sistemas, 169errores durante procedimientos, 169errores humanos, 167errores relacionados al mantenimiento, 171fallas ambientales, 161fallas de las aplicaciones, 160fallas del hardware, 153fallas del sistema operativo, 159fallas del software, 159HVAC, 167integridad del edificio, 162relacionado al tiempo, 167reparaciones incorrectas, 171ventilación, 167

planificación, importancia de, 8 Pluggable Authentication Modules

(Ver PAM) Poder de CPU

(Ver recursos, sistema y poder de procesamiento) poder de procesamiento, recursos relacionados a

(Ver recursos, sistema y poder de procesamiento) printconf

(Ver configuración de impresoras) printtool

195

(Ver configuración de impresoras) puntos de montaje

(Ver almacenamiento, sistema de archivos, punto de montaje)

R

RAIDcomparado con LVM, 87creación de formaciones

(Ver RAID, formaciones, creación) formaciones

administración de, 116comando raidhotadd, uso de, 117estatus, verificar, 117reconstrucción, 117

formaciones, creación, 115en el momento de la instalación, 115tiempo luego de la instalación, 116

implementaciones de, 84hardware RAID, 85software RAID, 85

introducción a, 80niveles de, 81

RAID 0, 81RAID 0, desventajas de, 82RAID 0, ventajas de, 82RAID 1, 82RAID 1, desventajas de, 82RAID 5, 83RAID 5, desventajas de, 83RAID 5, ventajas de, 83RAID anidado, 84

RAID anidado, 84vista general de, 81

RAM, 51recuperación de desastres

disponibilidad del hardware, 181disponibilidad del software, 181final de, 183introducción a, 179plan, creación, evaluación, implementación, 179respaldos, disponibilidad de, 182sitio de respaldo, 180

conectividad de red a, 182personal de, 182

recursión(Ver recursión)

recursos del sistema(Ver recursos, sistema)

recursos relacionados al ancho de banda(Ver recursos, sistema, ancho de banda)

recursos, importancia de, 6recursos, sistema

almacenamiento

(Ver almacenamiento) ancho de banda , 33

buses, ejemplos de, 34capacidad, incrementar, 35carga, distribuir, 35carga, reducir, 35datapaths, ejemplos de, 34datapaths, papel en, 34descripción general de, 33monitorizar el, 18papel de los buses en, 33problemas relacionados a, 34soluciones a problemas con, 35

memoria (Ver memoria)

poder de procesamiento, 33actualizar, 39aplicaciones, eliminar, 38capacidad, incrementar, 39carga, reducir, 38consumidores de, 36CPU, actualizar, 39descripción general de, 36escasez de, mejorar, 37hechos relacionados a, 36monitorizar el, 17multiprocesamiento simétrico, 39SMP, 39sobrecarga de aplicaciones, reducir, 38Sobrecarga del SO, reducir, 38uso de aplicaciones de, 37uso del sistema operativo de, 37

registro de su suscripción, ivregistro de suscripción, ivrespaldos

almacenamiento de, 177comprar software, 173construir software, 173introducción a, 172planificación, modificar, 96problemas de restauración, 178

evaluar la restauración, 179restauraciones a metal pelado, 178

problemas relacionados a los datos, 172Software de respaldo AMANDA, 186tecnologías utilizadas, 183

cpio, 184dump, 185tar, 184

tipos de, 174respaldos completos, 175respaldos diferenciales, 175respaldos incrementales, 175

tipos de media, 176cinta, 176disco, 176

196

red, 177RPM, 10RPM Package Manager

(Ver RPM)

S

seguridadimportancia de, 7Información específica a Red Hat Enterprise Linux,10

shell scripts, 9sistema de archivos

etiquetas, 100Sistema de archivos EXT2, 101Sistema de archivos EXT3, 101Sistema de archivos ISO 9660, 101Sistema de archivos MSDOS, 102Sistema de archivos VFAT, 102sistemas de detección de intrusos, 10SMB, 106SMP, 39software

asistencia paraauto asistencia, 160descripción general, 160documentación, 160soporte de correo electrónico, 160soporte in situ, 161soporte telefónico, 161Soporte Web, 160

supervisiónrecursos, 15rendimiento del sistema, 16

supervisión de recursos, 15almacenamiento, 19ancho de banda, 18capacidad del sistema, 16conceptos detrás, 15herramienta utilizada, 20herramientas

free, 21iostat, 24Monitor del Sistema GNOME, 22mpstat, 24OProfile, 28sa1, 24sa2, 24sadc, 24sar, 24, 26Sysstat, 24top, 21vmstat, 23

memoria, 19planificación de la capacidad, 16

Poder de CPU, 17qué monitorizar, 17rendimiento del sistema, 16

Sysstat, 20, 24system-config-printer

(Ver configuración de impresoras)

U

UID, 135Unidad de dico SCSI

añadir, 94unidades de disco, 52usuarios

importancia de, 6

Colofón

Los manuales son escritos en formato DocBook SGML v4.1. Los formatos HTML y PDF son producidos usando hojas de estilos personalizados DSSSL y scripts personalizados jade wrapper. Los archivos DocBook SGML son escritos en Emacs con la ayuda del modo PSGML.

Garrett LeSage creó los gráficos de admonición (nota, sugerencia, importante, aviso y atención). Estos pueden ser distribuídos gratuitamente con la documentación de Red Hat.

El Equipo Red Hat de Documentación de Productos está formado por las siguientes personas:

Sandra A. Moore — Escritora principal y mantenedora del Manual de instalación para x86, Itanium™, AMD64 e Intel® Extended Memory 64 Technology (Intel® EM64T) de Red Hat Enterprise Linux; Escritora principal y mantenedora de Manual de instalación para la arquitectura IBM® POWER de Red Hat Enterprise Linux; Escritora principal y mantenedora del Manual de instalación para las arquitecturas IBM® S/390® e IBM® eServer™ zSeries® de Red Hat Enterprise Linux

John Ha — Escritor principal y mantenedor del Manual de configuración y administración del Cluster de Red Hat Cluster Suite; Colaborador en la escritura del Manual de seguridad de Red Hat Enterprise Linux; Mantenedor de las hojas de estilo personalizadas y los scripts DocBook

Edward C. Bailey — Escritor principal y mantenedor del Introducción a la administración de sistemas de Red Hat Enterprise Linux; Escritor principal y mantenedor de las Notas de última hora; Colaborador en la escritura del Manual de instalación para x86, Itanium™, AMD64 e Intel® Extended Memory 64 Technology (Intel® EM64T) de Red Hat Enterprise Linux

Karsten Wade — Escritor principal y mantenedor del Manual del desarrollador de aplicaciones de SELinux de Red Hat; Escritor principal y mantenedor del Guía para escribir políticas SELinux de Red Hat

Andrius Benokraitis — Escritor principal y mantenedor del Manual de referencia de Red Hat Enterprise Linux; Colaborador en la escritura y mantenimiento del Manual de seguridad de Red Hat Enterprise Linux; Colaborador en la escritura del Manual de administración del sistema de Red Hat Enterprise Linux

Paul Kennedy — Escritor principal y mantenedor del Manual del administrador de Red Hat GFS; Colaborador en la escritura del Manual de configuración y administración del Cluster de Red Hat Cluster Suite

Mark Johnson — Escritor principal y mantenedor del Manual de configuración y administración para escritorios de Red Hat Enterprise Linux

Melissa Goldin — Escritora principal y mantenedora del Manual paso-a-paso de Red Hat EnterpriseLinux

El Equipo de Localización de Red Hat está formado por las siguientes personas:

Amanpreet Singh Alam — Traducciones al Punjabi

Jean-Paul Aubry — Traducciones al Francés

David Barzilay — Traducciones al Portugués Brasileño

Runa Bhattacharjee — Traducciones al Bengalí

Chester Cheng — Traducciones al Chino Tradicional

Verena Fuehrer — Traducciones al Alemán

Kiyoto Hashida — Traducciones al Japonés

N. Jayaradha — Traducciones al Tamil

Michelle Jiyeen Kim — Traducciones al Coreano

Yelitza Louze — Traducciones al Español

198

Noriko Mizumoto — Traducciones al Japonés

Ankitkumar Rameshchandra Patel — Traducciones al Gujarati

Rajesh Ranjan — Traducciones al Hindi

Nadine Richter — Traducciones al Alemán

Audrey Simons — Traducciones al Francés

Francesco Valente — Traducciones al Italiano

Sarah Wang — Traducciones al Chino Simplificado

Ben Hung-Pin Wu — Traducciones al Chino Tradicional

Documents

rhel-isa-es