Rhel Isa Es

Red Hat Enterprise Linux 4
Introducción a la administración
de 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-2072 USA Teléfono: +1 919 754 3700 Teléfono: 888 733 4281 Fax: +1 919 754 3701 PO Box 13588 Re-
search 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 la
Open Publication License, V1.0 o versiones posteriores (la última versión está disponible en
http://www.opencontent.org/openpub/).
Los derechos de autor del propietario prohiben la distribución de versiones de este documento sustancialmente modificadas
sin 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 se
obtenga 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 security@redhat.com 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 ................................................................................ i
2. Convenciones del documento ............................................................................................... ii
3. Active su suscripción ........................................................................................................... iv
3.1. Proporcione un nombre de conexión a Red Hat .................................................... v
3.2. Proporcione su número de suscripción .................................................................. v
3.3. Conecte su sistema................................................................................................. v
4. ...y hay más ........................................................................................................................... v
4.1. Envíenos sus comentarios ..................................................................................... vi
1. Filosofía de la Administración de Sistemas .................................................................................. 1
1.1. Automatizar todo ............................................................................................................... 1
1.2. Documentar todo................................................................................................................ 2
1.3. Comunique tanto como sea posible ................................................................................... 3
1.3.1. Informe a sus usuarios sobre lo que va a hacer................................................... 3
1.3.2. Informe a sus usuarios sobre lo que está haciendo ............................................. 4
1.3.3. Informe a sus usuarios sobre lo que ha hecho..................................................... 5
1.4. Conozca sus recursos ......................................................................................................... 6
1.5. Conozca a sus usuarios ...................................................................................................... 6
1.6. Conozca su negocio ........................................................................................................... 6
1.7. La seguridad no puede ser una ocurrencia posterior.......................................................... 7
1.7.1. Los riesgos de Ingeniería Social ......................................................................... 7
1.8. Planifique ........................................................................................................................... 8
1.9. Espere lo inesperado .......................................................................................................... 8
1.10. Información específica a Red Hat Enterprise Linux ........................................................ 9
1.10.1. Automatización ................................................................................................. 9
1.10.2. Documentación y comunicación..................................................................... 10
1.10.3. Seguridad ........................................................................................................ 10
1.11. Recursos adicionales...................................................................................................... 11
1.11.1. Documentación instalada ................................................................................ 11
1.11.2. Sitios web de utilidad...................................................................................... 12
1.11.3. Libros relacionados......................................................................................... 12
2. Supervisión de recursos ................................................................................................................ 15
2.1. Conceptos básicos............................................................................................................ 15
2.2. Monitorizar el rendimiento del sistema ........................................................................... 15
2.3. Monitorizar la capacidad del sistema............................................................................... 16
2.4. ¿Qué monitorizar?............................................................................................................ 16
2.4.1. Monitorizar el poder de CPU............................................................................ 17
2.4.2. Monitorizar el ancho de banda.......................................................................... 18
2.4.3. Monitorizar la memoria .................................................................................... 19
2.4.4. Monitorizar el almacenamiento ........................................................................ 19
2.5.1. free .................................................................................................................. 20
2.5.2. top .................................................................................................................... 21
2.5.3. vmstat.............................................................................................................. 23
2.5.4. Las herramientas para monitorizar recursos de la suite Sysstat........................ 24
2.5.5. OProfile ............................................................................................................. 27
2.6. Recursos adicionales........................................................................................................ 31
2.6.1. Documentación instalada .................................................................................. 31
2.6.2. Sitios Web útiles ............................................................................................... 32
2.6.3. Libros relacionados........................................................................................... 32
3. Ancho de banda y poder de procesamiento ................................................................................ 33
3.1. Ancho de banda................................................................................................................ 33
3.1.1. Buses ................................................................................................................. 33
3.1.2. Datapaths........................................................................................................... 34
3.1.3. Problemas potenciales relacionados al ancho de banda.................................... 34
3.1.4. Soluciones potenciales relacionadas al ancho de banda ................................... 35
3.1.5. En resumen. . . ................................................................................................... 35
3.2. Poder de procesamiento ................................................................................................... 36
3.2.1. Hechos sobre el poder de procesamiento.......................................................... 36
3.2.2. Consumidores de poder de procesamiento ....................................................... 36
3.2.3. Mejorando la escasez de CPU........................................................................... 37
3.3.1. Monitorizar el ancho de banda en Red Hat Enterprise Linux........................... 40
3.3.2. Monitorizar la utilización del CPU en Red Hat Enterprise Linux .................... 42
3.4.2. Sitios Web útiles ............................................................................................... 46
4. Memoria física y virtual ............................................................................................................... 49
4.1. Patrones de acceso a almacenamiento ............................................................................. 49
4.2. El espectro de almacenamiento........................................................................................ 49
4.2.1. Registros de CPU .............................................................................................. 50
4.2.2. Memoria caché.................................................................................................. 50
4.2.3. Memoria principal — RAM.............................................................................. 51
4.2.4. Discos duros...................................................................................................... 52
4.2.5. Almacenamiento para respaldos fuera de línea ................................................ 53
4.3. Conceptos básicos sobre Memoria Virtual ...................................................................... 53
4.3.1. La memoria virtual en términos sencillos......................................................... 54
4.3.2. Almacenamiento de respaldo — el Tenet central de la memoria virtual .......... 55
4.4. La memoria virtual: los detalles....................................................................................... 55
4.4.1. Fallos de página ................................................................................................ 56
4.4.2. El conjunto de direcciones de trabajo ............................................................... 56
4.4.3. Intercambio ....................................................................................................... 57
4.5. Implicaciones de rendimiento de la memoria virtual....................................................... 57
4.5.1. Escenario de rendimiento del peor caso............................................................ 57
4.5.2. Escenario de rendimiento del mejor caso ......................................................... 58
4.6. Información específica de Red Hat Enterprise Linux ...................................................... 58
4.7.2. Sitios web de utilidad........................................................................................ 61
5. Administración del Almacenamiento.......................................................................................... 63
5.1. Una vista general del hardware de almacenamiento........................................................ 63
5.1.1. Platos de discos ................................................................................................. 63
5.1.2. Dispositivo de lectura/escritura de datos .......................................................... 63
5.1.3. Brazos de acceso ............................................................................................... 64
5.2. Conceptos de direcciones de almacenamiento................................................................. 65
5.2.1. Direcciones basadas en la geometría ................................................................ 65
5.2.2. Direcciones basadas en bloques........................................................................ 67
5.3. Interfaces de dispositivos de almacenamiento masivo..................................................... 67
5.3.1. Antecedentes históricos .................................................................................... 67
5.3.2. Interfaces de hoy día con estándares de la industria ......................................... 68
5.4. Características de rendimiento del disco duro ................................................................. 71
5.4.1. Limitaciones mecánicas/eléctricas.................................................................... 71
5.4.2. Cargas y rendimiento de E/S............................................................................. 73
5.5. Preparar el almacenamiento para ser utilizado ................................................................ 74
5.5.1. Particiones/cuotas ............................................................................................. 74
5.5.2. Sistemas de archivos ......................................................................................... 76
5.5.3. Estructura del directorio.................................................................................... 78
5.5.4. Activando el acceso al almacenamiento ........................................................... 79
5.6. Tecnologías avanzadas de almacenamiento ..................................................................... 79
5.6.1. Almacenamiento accesible a través de la red ................................................... 79
5.6.2. Almacenamiento basado en RAID.................................................................... 80
5.6.3. Administración de Volúmenes Lógicos ............................................................ 85
5.7. La administración del almacenamiento día a día............................................................. 87
5.7.1. Monitorizar el espacio libre .............................................................................. 87
5.7.2. Problemas de cuotas de usuarios....................................................................... 90
5.7.3. Problemas relacionados a archivos ................................................................... 90
5.7.4. Añadir/Eliminar almacenamiento ..................................................................... 92
5.8. Un comentario sobre Respaldos....................................................................................... 98
5.9. Documentación específica a Red Hat Enterprise Linux .................................................. 98
5.9.1. Convenciones de nombres de dispositivos........................................................ 98
5.9.2. Conceptos básicos de sistemas de archivos .................................................... 100
5.9.3. Montaje de Sistemas de Archivos ................................................................... 102
5.9.4. Almacenamiento accesible desde la red bajo Red Hat Enterprise Linux ....... 105
5.9.5. Montar sistemas de archivos automáticamente con /etc/fstab ................. 106
5.9.6. Añadir/Eliminar almacenamiento ................................................................... 107
5.9.7. Implementación de Cuotas de Disco............................................................... 111
5.9.8. Creación de Formaciones RAID ..................................................................... 115
5.9.9. Administración día a día de las formaciones RAID ....................................... 116
5.9.10. Administración de Volúmenes Lógicos ........................................................ 118
5.10. Recursos adicionales.................................................................................................... 118
5.10.1. Documentación instalada .............................................................................. 118
5.10.2. Sitios Web de utilidad ................................................................................... 119
5.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.......................................................................... 121
6.1.1. El nombre de usuario ...................................................................................... 121
6.1.2. Contraseñas ..................................................................................................... 124
6.1.3. Información de control de acceso ................................................................... 128
6.1.4. Administración día a día de cuentas y acceso a recursos................................ 129
6.2. Administración de recursos de usuarios ........................................................................ 131
6.2.1. ¿Quién puede acceder a los datos compartidos?............................................. 131
6.2.2. ¿Donde los usuarios acceden a los datos compartidos?.................................. 132
6.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 ...................................................... 133
6.3.1. Cuentas de usuarios, Grupos y Permisos ........................................................ 133
6.3.2. Archivos que controlan Cuentas de Usuarios y Grupos ................................. 135
6.3.3. Aplicaciones para Cuentas de Usuarios y Grupos .......................................... 139
6.4.2. Sitios Web de utilidad ..................................................................................... 141
7. Impresoras e impresión .............................................................................................................. 143
7.1. Tipos de impresoras ....................................................................................................... 143
7.1.1. Consideraciones de impresión ........................................................................ 143
7.2. Impresoras de impacto ................................................................................................... 144
7.2.1. Impresoras de matriz de puntos ...................................................................... 145
7.2.2. Impresoras margarita ...................................................................................... 145
7.2.3. Impresoras en línea ......................................................................................... 145
7.2.4. Consumibles para las impresoras de impacto ................................................. 145
7.3. Impresoras de inyección de tinta.................................................................................... 146
7.3.1. Consumibles de inyección de tinta ................................................................. 146
7.4. Impresoras láser ............................................................................................................. 147
7.4.1. Impresoras a color láser .................................................................................. 147
7.4.2. Consumibles para impresoras láser................................................................. 147
7.5. Otros tipos de impresoras............................................................................................... 148
7.6. Lenguajes y tecnologías de impresión ........................................................................... 148
7.7. Impresión de red Versus Impresión local....................................................................... 149
7.8. Información específica de Red Hat Enterprise Linux .................................................... 149
7.9.2. Sitios web de utilidad...................................................................................... 151
8. Planificación para Desastres ...................................................................................................... 153
8.1. Tipos de desastre............................................................................................................ 153
8.1.1. Fallas del hardware ......................................................................................... 153
8.1.2. Fallas del software .......................................................................................... 159
8.1.3. Fallas ambientales ........................................................................................... 161
8.1.4. Errores humanos ............................................................................................. 167
8.2. Respaldos ....................................................................................................................... 172
8.2.1. Datos diferentes: Necesidades de respaldos diferentes................................... 172
8.2.2. Software de respaldos: Comprar contra Construir.......................................... 173
8.2.3. Tipos de respaldo ............................................................................................ 174
8.2.4. Media de respaldo ........................................................................................... 176
8.2.5. Almacenamiento de las copias de seguridad o respaldos ............................... 177
8.2.6. Problemas de restauración .............................................................................. 178
8.3. Recuperación de desastres ............................................................................................. 179
8.3.1. Creación, Evaluación e Implementación de un Plan de Recuperación de
Desastres ....................................................................................................... 179
8.3.2. Sitios de respaldo: frío, templado y caliente................................................... 180
8.3.3. Disponibilidad del Hardware y Software........................................................ 181
8.3.4. Disponibilidad de los respaldos ...................................................................... 182
8.3.5. Conectividad de red al sitio de respaldo ......................................................... 182
8.3.6. Personal del sitio de respaldo.......................................................................... 182
8.3.7. Regreso a la normalidad.................................................................................. 183
8.4. Información específica a Red Hat Enterprise Linux ...................................................... 183
8.4.1. Soporte de Software........................................................................................ 183
8.4.2. Tecnologías de respaldo .................................................................................. 183
8.5.2. Sitios Web de utilidad ..................................................................................... 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 informa-
ció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 experi-
encia 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 rela-
cionado 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 ad-
ministración de sistemas de Red Hat Enterprise Linux de la forma que deseen. Por ejemplo, un ad-
ministrador 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 descrip-
ció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 sis-
temas 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 apare-
cerá 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 determinados
tipos de información. Dependiendo de lo importante que esta información sea para su sistema, estos
elementos 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 mismo
que ROSA o rOsA.
Sugerencia
El directorio /usr/share/doc/ contiene documentación adicional de los paquetes instalados en su
sistema.
Importante
Si modifica el archivo de configuración de DHCP, los cambios no surtirán efecto sino hasta que
reinicie el demonio DHCP.
Atención
No lleve a cabo tareas rutinarias como root — utilice una cuenta de usuario normal a menos que
necesite usar una cuenta de usuario para administrar su sistema.
Aviso
Tenga cuidado de solamente borrar las particiones Red Hat Enterprise Linux necesarias. Si elimina
otras particiones esto puede resultar en la pérdida de datos o en un ambiente del sistema dañado.
3. Active su suscripción
Antes de que pueda acceder a cualquier información de mantenimiento de software o servicios y a la
información de soporte incluida con su suscripción, debe activar su suscripción registrándose con Red
Hat. 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 hard-
ware 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 Her-
ramientas 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 Enter-
prise 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 En-
terprise 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) indi-
cando 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 mensu-
ales, 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 real-
mente 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 pro-
cedimental 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 comu-
nidad 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 proble-
mas, 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 config-
uració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 cam-
bios, 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 de-
berí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 apo-
yar 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 pe-
queños cambios que usted puede pensar son prácticamente insignificantes, pueden confundir comple-
tamente 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 dis-
posició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 fun-
cionó; 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 Admin-
istració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 per-
sonas 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 con-
notació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 inge-
niero 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 difer-
entes 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 inten-
ciones.
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 con-
troles 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 propor-
cionar 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 proced-
imientos. 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 rela-
cionados 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 admin-
istrador 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á respons-
able 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 solu-
cionar 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 funcional-
idades 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 mu-
chos 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 progra-
mació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 computa-
doras 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 man-
ualmente 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 com-
partidas 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 admin-
istradores 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 de-
scripció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 Profes-
sional — 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 (nor-
malmente 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 planifi-
cació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 cono-
cen 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 proce-
samiento 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 experi-
mentando 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 servi-
cios 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ís-
ticas 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 trans-
misió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 se-
gundo; 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 adminis-
tració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 memo-
ria 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á experi-
mentando 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. Mien-
tras 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 uti-
lizació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 recor-
dar; 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 esta-
tus 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 representa-
ciones 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 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:
• 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 prome-
dios, 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:50 4.
Cada sección del informe comienza con un encabezado describiendo los datos contenidos en la sec-
ción. El encabezado se repite a intervalos regulares a lo largo de la sección, haciendo más fácil in-
terpretar 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 %idle

00:10:00 all 6.39 1.96 0.66 90.98
00:20:01 all 1.61 3.16 1.09 94.14
...
23:50:01 all 44.07 0.02 0.77 55.14
Average: 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 %idle

00:10:00 0 4.19 1.75 0.70 93.37
00:10:00 1 8.59 2.18 0.63 88.60
00:20:01 0 1.87 3.21 1.14 93.78
00:20:01 1 1.35 3.12 1.04 94.49
...
23:50:01 0 42.84 0.03 0.80 56.33
23:50:01 1 45.29 0.01 0.74 53.95
Average: 0 6.00 5.01 2.74 86.25
Average: 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 procesador 5 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 proce-
sador 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 inutiliz-
able. 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 eje-
cutable
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 individ-
ual 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 informa-
ció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 tainted

oprofile 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
CTR_KERNEL[0]=1
CTR_USER[0]=1
CTR_UM[0]=0
CTR_EVENT_VAL[0]=121
CTR_EVENT[1]=
CTR_COUNT[1]=
CTR_KERNEL[1]=1
CTR_USER[1]=1
CTR_UM[1]=0
CTR_EVENT_VAL[1]=
one_enabled=1
SEPARATE_LIB_SAMPLES=0
SEPARATE_KERNEL_SAMPLES=0
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.log

Daemon 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 desple-
garlos. 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.entsmp

761776 11.1940 0.0000 /usr/bin/oprofiled
368933 5.4213 0.0000 /lib/tls/libc-2.3.2.so
293570 4.3139 0.0000 /usr/lib/libgobject-2.0.so.0.200.2
205231 3.0158 0.0000 /usr/lib/libgdk-x11-2.0.so.0.200.2
167575 2.4625 0.0000 /usr/lib/libglib-2.0.so.0.200.2
123095 1.8088 0.0000 /lib/libcrypto.so.0.9.7a
105677 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
sample-percent
representa el número de muestras reunidas
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 re-
cursos 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 Enter-
prise 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áfica-
mente 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 solu-
ció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.
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 es-
pecíficas.
• Red Hat Linux Security and Optimization por Mohammed J. Kabir; Red Hat Press — Aproxi-
madamente 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é agru-
parlos?
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, for-
mato 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 proce-
samiento 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 multi-
proceso. 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 determi-
nar 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 in-
cremento 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 am-
bientes 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 aplica-
ciones 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 com-
putacional 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 apli-
cación monolítica con una sola corriente de ejecución. En otras palabras, si un programa grande, vin-
culado 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 admin-
istradores 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 ex-
aminando 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.

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 inter-
cambio 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

5.34 4.60 2.83 87.24
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:

5.37 4.54 2.81 87.27
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 servi-
cio (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 alma-
cenados. 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/s

12:10:00 AM 0.51 0.01 0.50 0.25 14.32
12: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.23
Average: 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/s

12:10:00 AM dev8-0 0.51 14.57
12:10:00 AM dev8-1 0.00 0.00
12:20:01 AM dev8-0 0.48 13.32
12:20:01 AM dev8-1 0.00 0.00
...
06:00:02 PM dev8-0 1.24 36.25
06:00:02 PM dev8-1 0.00 0.00
Average: dev8-0 1.11 102.93
Average: 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 ejecu-
tando 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 herramien-
tas. Si examinanos la salida desde vmstat, obtenemos un entendimiento ligeramente diferente de
nuestro sistema ejemplo:

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 inter-
rupciones 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-5

12:10:00 AM 3 122 0.07 0.28
12:20:01 AM 5 123 0.00 0.03
...
09:50:00 AM 5 124 0.67 0.65
Average: 4 123 0.26 0.26
En este ejemplo, el sistema siempre está ocupado (dado que siempre hay más de un proceso eje-
cutable), 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 %idle

12:10:00 AM all 3.69 20.10 1.06 75.15
12:20:01 AM all 1.73 0.22 0.80 97.25
...
10:00:00 AM all 35.17 0.83 1.06 62.93
Average: 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 indi-
vidual o para todos los procesos. He aquí un ejemplo de la salida desde sar -U ALL:
12:00:01 AM CPU %user %nice %system %idle

12:10:00 AM 0 3.46 21.47 1.09 73.98
12:10:00 AM 1 3.91 18.73 1.03 76.33
12:20:01 AM 0 1.63 0.25 0.78 97.34
12:20:01 AM 1 1.82 0.20 0.81 97.17
...
10:00:00 AM 0 39.12 0.75 1.04 59.09
10:00:00 AM 1 31.22 0.92 1.09 66.77
Average: 0 7.61 4.91 3.86 83.61
Average: 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/s
12:10:00 AM 537.97
12: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, (gen-
erado usando el comando sar -I SUM) muestra una estadística simple de "interrupciones por se-
gundo":
12:00:01 AM INTR intr/s

12:10:00 AM sum 539.15
12:20:01 AM sum 539.49
...
10:40:01 AM sum 539.10
Average: 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 CPU i000/s i001/s i002/s i008/s i009/s i011/s i012/s

12:10:01 AM 0 512.01 0.00 0.00 0.00 3.44 0.00 0.00

12:20:01 AM 0 512.00 0.00 0.00 0.00 3.73 0.00 0.00
...
10:40:02 AM 0 512.00 1.67 0.00 0.00 0.00 15.08 0.00
Average: 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 re-
une 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.
Esta página del Linux Journal está enfocada hacia el administrador interesado en escribir una solu-
ció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 es-
pecí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.
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 computado-
ras 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 con-
trolar 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 almace-
nados 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 almace-
namiento 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 re-
querido 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 gen-
erales 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 — usual-
mente 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 write-
through 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 usual-
mente 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 distribu-
ció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 in-
clusive 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 almace-
namiento 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 relativa-
mente 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 almace-
namiento 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 de-
berí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 op-
erativos 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 inicial-
izació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 so-
lapamiento 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 necesi-
tan — 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 di-
recciones 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 tam-
bié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 ubi-
caciones 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 ad-
ministració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, inter-
rumpe 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 nece-
sitamos 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 ma-

sivo (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 apli-
caciones 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 ad-
ministració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 su-
pervisió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:

Mem: 1288720 361448 927272 0 27844 187632
-/+ buffers/cache: 145972 1142748
Swap: 522104 0 522104
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:

Mem: 255088 246604 8484 0 6492 111320
-/+ buffers/cache: 128792 126296
Swap: 530136 111308 418828
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á cierta-
mente 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:

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 inter-
cambio más de cerca:
12:00:01 AM kbmemfree kbmemused %memused kbmemshrd kbbuffers kbcached

12:10:00 AM 240468 1048252 81.34 0 133724 485772
12:20:00 AM 240508 1048212 81.34 0 134172 485600
...
08:40:00 PM 934132 354588 27.51 0 26080 185364
Average: 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 %swpused

12:10:00 AM 522104 0 0.00
12:20:00 AM 522104 0 0.00
...
08:40:00 PM 522104 0 0.00
Average: 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/s

12:10:01 AM 0.15 2.56
12:20:00 AM 0.00 0.00
...
03:30:01 PM 0.42 2.56
Average: 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 inatarpg

12:10:00 AM 0.03 8.61 195393 20654 30352 49279
12:20:00 AM 0.01 7.51 195385 20655 30336 49275
...
08:40:00 PM 0.00 7.79 71236 1371 6760 15873
Average: 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 fre-
cuencia 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/s

12:10:00 AM -0.10 0.00 0.12 -0.07
12:20:00 AM 0.02 0.00 0.19 -0.07
...
08:50:01 PM -3.19 0.00 0.46 0.81
Average: 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 positi-
vas, 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 super-
visió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 uti-
lizada.
• La página man de vmstat(8) — Aprenda a desplegar una descripción general concisa de la uti-
lizació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.
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 exce-
lentes 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 presen-
tadas 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 — Aproximada-
mente 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 elec-
tró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.
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 ad-
ministració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 disposi-
tivos de almacenamiento masivo, quizás se encuentre en una situación donde tenga un problema rela-
cionado 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 tec-
nologí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 conse-
cuencia, 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 sis-
tema 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 ejem-
plo, en un almacenamiento masivo basado en magnetismo, los dispositivos de lectura/escritura (cono-
cidos 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 relativa-
mente 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ó ante-
riormente, 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 almace-
namiento. Sin embargo, esto no es suficiente; para utilizar esta capacidad de almacenamiento, debe-
mos 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 fijo 3 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 - relati-
vamente 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 al-
macenamiento 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 compo-
nentes 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, ha-
ciendo 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 ve-
locidad 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 diferen-
cias 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 pro-
porciona una idea del ámbito del desarrollo de las interfaces sobre los últimos 30 años para así pro-
porcionar 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 Almace-
namiento ) 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 person-
ales 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ía
se 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 almacenamiento
masivo. Estos dos dispositivos se conocen como maestro y esclavo. Estos términos pueden llevar
a confusiones, pues implican un tipo de relación entre los dispositivos; pero este no es el caso. La
selección de cual dispositivo es el maestro y cual es el esclavo, normalmente se selecciona a través
del 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ón
en jumpers de "selección de cable"). Cuando se configura de la forma adecuada, la selección de
cable 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 de
la interfaz ATA y viene de AT Attachment Packet Interface. Utilizada principalmente por las unidades
de CD-ROM, una ATAPI sigue los aspectos eléctricos y mecánicos de la interfaz ATA pero utiliza el
protocolo 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 de
computació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 ese
es 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 cada
bus y les dá un nombre específico, SCSI hace esto asignando a cada dispositivo en el bus SCSI una
dirección numérica única o SCSI ID. Cada dispositivo en un bus SCSI se debe configurar (usualmente
mediante 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 representa
una ú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 implementa-
ciones 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 pos-
teriores 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 im-
plementació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 habil-
itar 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 tiempo 6. 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 resul-
tante. 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 con-
secuencia, 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 especifica-
ciones 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 milise-
gundos)
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ún-
mente 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 can-
tidades 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 parti-
ciones 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 par-
ticiones 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érmi-
nos 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 orga-
nizar 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 alma-
cenamiento 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ác-
teres 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 carac-
teres 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 directo-
rios 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 adminis-
tració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 con-
sumo 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 or-
ganizació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 ante-
rior, asuma por un momento que el departamento de ingeniería está a punto de arrancar varios proyec-
tos. 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 fre-
cuencia 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 mon-
tar — 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 conex-
iones 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 com-
parables al almacenamiento conectado directamente. Más aún, la naturaleza compartida de tal con-
figuració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 espar-
cido (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 compli-
cado. 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 in-
stalar 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 requeri-
das 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 configu-
raciones 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 escrit-
uras 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 fun-
cionar.
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 Independi-
entes 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 (conoci-
das 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 si-
multá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 actualiza-
dos, 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 almace-
namiento 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 implemen-
tar 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 (elimi-
nando 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 sec-
ciones 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 usual-
mente 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 adminis-
trativas 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 sis-
tema 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 vol-
ume management (LVM). LVM hace posible tratar a los dispositivos físicos de almacenamiento ma-
sivo 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ógi-
cos 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 em-
bargo, 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 sis-
temas 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ámi-
camente 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 pre-
gunta 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ís-
ticas 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 almace-
namiento 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 crec-

imiento 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 situa-
ciones, 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 aplica-
ciones 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 inesper-
adamente 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 utilizar
para implementar el almacenamiento compartido para grandes proyectos.
5.7.4. Añadir/Eliminar almacenamiento

Debido a que la necesidad de espacio adicional nunca termina, el administrador de sistemas con
frecuencia se encontrará en la situación de añadir espacio en disco y otras veces tendrá que eliminar
unidades más viejas o pequeñas. Esta sección proporciona una descripción general del proceso básico
para añadir o remover almacenamiento.
Nota
En muchos sistemas operativos, los dispositivos de almacenamiento masivo son nombrados de
acuerdo 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. Cuando
agregue 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 almacenamiento

El 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 muchas
configuraciones de hardware posibles, las secciones siguientes mencionan las dos situaciones más
comunes - añadir una unidad de disco ATA o SCSI. Aún con otras configuraciones, los pasos básicos
que 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ñade
al subsistema de E/S de su computador. En general, debería tratar de distribuir la carga de E/S de
su disco sobre todos los canales/buses disponibles. Desde un punto de vista de rendimiento, esto
es 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 pe-
queñ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 compar-
tiendo 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 enorme-
mente. 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 par-
tició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 almace-
namiento 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 correcta-
mente 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 conser-
var, 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 ad-
ministradores 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 com-
pleto 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 disposi-
tivos 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 nom-
brados bajo Red Hat Enterprise Linux.
Nota
Los nombres de dispositivos bajo Red Hat Enterprise Linux se determinan en el momento del ar-
ranque.
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 parti-
ció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 infor-
mació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 cam-
bian 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 encon-
trarse con este problema. Las organizaciones que requieren reconfiguraciones frecuentes del alma-
cenamiento 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 ha-
bilidad 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 infor-
mado 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 aproximada-
mente 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 journal-
ing). 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 fun-
cionalidades tales como nombres de archivos largos con combinaciones de mayúsculas y minúscu-
las, 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 parti-
ciones. 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 especifi-
cado.
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 0
none /proc proc rw 0 0
usbdevfs /proc/bus/usb usbdevfs rw 0 0
/dev/sda1 /boot ext3 rw 0 0
none /dev/pts devpts rw,gid=5,mode=620 0 0
/dev/sda4 /home ext3 rw 0 0
none /dev/shm tmpfs rw 0 0
none /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 actual-
mente. 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/fstab 11)
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 0
usbdevfs /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 0
none /dev/shm tmpfs rw 0 0
none /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 config-
uració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 sis-
tema 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 inte-
gridad 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 real-
idad, 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 sis-
temas 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)

First cylinder (1-767): 1
Last cylinder or +size or +sizeM or +sizeK: +512M
Segundo, configure el tipo de sistema de archivos (usando el comando t):

Command (m for help): t
Hex 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 ejecu-
tando 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 ase-
gurá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 actual-
izado /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 mon-
tar 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) parti-
ció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
Writing pattern 0xffffffff: done
Writing pattern 0x00000000: 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 individ-
ualmente.
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 respons-
abilidades 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 correla-
cionar 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án-
doles 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 RAID 12
• 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 nue-
stro 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]

4192896 blocks [2/2] [UU]

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á in-
stalando 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 soft-
ware RAID.
• La página man de mdadm(8) — Conozca sobre este programa para la administración de forma-
ciones 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 tec-
nologí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.
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 y
acceso a recursos
La administración de cuentas de usuario y grupos es una parte esencial de la administración de sis-
temas 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 admin-
istradores 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 elemen-
tos 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 may-
orí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 or-
ganizació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.
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 prue-
bas:
• 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 ilus-
trar 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

1 26
2 676
3 17,576
4 456,976
5 11,881,376
6 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 habil-
idad de un atacante de conducir un ataque de fuerza bruta. Por ejemplo, en vez de 26 carácteres difer-
entes 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 difer-
entes 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 co-
munes, 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 servi-
dor 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 emer-
gencia 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 co-
munidad de usuarios. Gente viene, se vá y también hay gente que se mueve de un grupo de respons-
abilidades 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 ad-
ministrador 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 or-
ganización recientemente. Esto es particularmente importante si el usuario fue terminado bajo condi-
ciones 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 liq-
uidada, el supervisor de la persona y un representante del departamento de personal de la organi-
zació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 posi-
ble 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 responsabili-
dades 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 man-
tener 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 respon-
sabilidades 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 per-
sona 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 estruc-
tura 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, en-
tonces 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 usuar-
ios. 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 direc-
torios 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 con-
junto 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 ejecu-
tar 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 ejecu-
tará 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/ exacta-
mente 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 aplica-
ciones 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 al-
macenar 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 en-
criptada 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 orga-
nizació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 con-
traseñ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 delimi-
tada 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 en-
criptada 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 contro-
lar 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 conex-
ió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 oper-
ativo 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 con-
traseñ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 con-
trolar todos los aspectos de las cuentas de usuarios y grupos. Para conocer aún más sobre su fun-
cionamiento, 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 recur-
sos 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 descrip-
ció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.
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 se-
guridad 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 impre-
soras 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 consid-
erablemente. Sin embargo, la impresión en dúplex con el tiempo puede reducir los costos consider-
ablemente, 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 profe-
sional (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 fab-
ricantes 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 es-
pecializados 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 impre-
sió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 con-
tinuas 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 relativa-
mente bajos. Las cintas de impresora y el papel son los principales costos para estas impresoras. Al-
gunas 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 bo-
quillas 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 cos-
tosas (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 funcional-
idad 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 propor-
cionales al volumen de impresión. El toner viene en cartuchos que son inmediatamente reemplaza-
dos; 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 cap-
turar 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 propi-
etarios 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 en-
viar 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 amplia-
mente 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 com-
pañí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 docu-
mento 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 im-
prime 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 departamen-
tos 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 departmen-
tales (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 impre-
sió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 rela-
cionadas 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 ini-
ciar 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áti-
camente 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 coman-
dos.
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á com-
partiendo 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 tec-
nologí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 demo-
nio 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 config-
uración de clases CUPS.
•
presión CUPS.

Archivos en /usr/share/doc/cups- version — Más información sobre el sistema de im-
• http://www.webopedia.com/TERM/p/printer.html — Definiciones generales de impresoras y de-

scripciones 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. — Informa-
ción completa sobre el uso de Linux como servidor de impresión en entornos heterogéneos.
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 con-
tructores 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 nece-
sarias 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 reem-
plazar 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 con-
sidere 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 hard-
ware 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é dis-
puesto 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 nor-
males 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éc-
nicos 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 in-
mediato 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 expli-
cació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 pre-
gunta 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 natu-
raleza 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 com-
putador 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 difer-
encias 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 infor-
mació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 prob-
lemas 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á reser-
vado 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 con-
sidere una pequeña organización con un único administrador de sistemas. La organización va a im-
plementar 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 ded-
icado. 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éc-
trica 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 conex-
iones 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 instala-
ciones 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 ines-
perada que pueda interrumpir el suministro de energía? Por ejemplo, ¿está el centro de datos compar-
tiendo 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 necesar-
ios 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 nor-
mal 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á sepa-
rada 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ía 2 .
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 moto-
generadores 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ác-
tica 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 moto-
generador 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 sumin-
istro 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, rara-
mente se encuentra disponible. En cualquier caso, los números de VA obtenidos usando este en-
foque, 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é tipo
de interrupciones está dispuesto a protegerse y cuánto dinero está dispuesto a gastar para hacerlo? La
mayorí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 se
vuelven más costosas. Las tecnologías capaces de manejar interrupciones eléctricas de largo tiempo
está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 regulares
mientras se esten ejecutando. Debería conocer la tasa de uso de su combustible con una carga
má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 conocimiento
especializado 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 beneficios
de un generador sin el gasto de dinero inicial para comprar uno. Sin embargo, tenga en cuenta que en
desastres que afectan su vecindad en general, los generadores alquilados serán difíciles de obtener
y 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 para
el personal en una oficina a oscuras, ¿qué tal si el apagón dura una hora? ¿cinco horas, un día, una
semana?
El hecho es, aún si el centro de datos está operando normalmente, en algún punto una interrupción
prolongada 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 habilidad
para funcionar de forma completamente independiente de un sitio con electricidad, lo que significa
que 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 orga-
nizació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 Con-
ditioning, 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 extremada-
mente fuertes dañando inclusive el edificio mismo.
Hay otros tipos de tiempo que también pueden provocar problemas, aún cuando no sean tan conoci-
dos. 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 admin-
istració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 actu-
alizaron. 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 ad-
ministradores 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 respons-
abilidades 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 computa-
cional. 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 plan-
ificado 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 eval-
uaciones.
Planificación
Se examina el cambio con un ojo hacia las mecánicas actuales de la implementación. La plani-
ficació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 config-
uració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 du-
rante 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 co-
mentarios 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 apli-
caciones 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 de
errores 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 el
proceso de instalación es relativamente fácil y si las reparaciones de fallos y personalizaciones
están bien documentadas y son fáciles de reproducir, la reinstalación del sistema operativo
puede ser una opción viable.
Por otro lado, si hay alguna duda de que una instalación fresca pueda recrear completamente
el ambiente original del sistema, el respaldo del sistema operativo es la mejor opción, aún si
los 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 restaurar
solamente unos pocos sistemas operativos (por ejemplo, debido a la eliminación accidental de
un 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 de
la aplicación específica y su organización, esto puede significar que los cambios toman lugar
segundo 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ía
de 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), usted
debería tener una buena idea concerniente a la naturaleza de los respaldos que se necesitan para
proteger sus datos.
Nota
Debe tener en mente que la mayoría del software de respaldo trata con datos en un directorio o a
nivel del sistema de archivos. En otras palabras, la estructura de su sistema de archivo juega un
papel importante en cómo se ejectuten los respaldos. Esta es otra razón por la que es una buena
idea considerar cuidadosamente la mejor estructura de directorios para un nuevo sistema y agrupar
los archivos y directorios de acuerdo a su uso anticipado.
8.2.2. Software de respaldos: Comprar contra Construir

Para poder llevar a cabo los respaldos, es necesario tener el software de respaldo apropiado. Este
software no solamente debe ser capaz de realizar la tarea básica de hacer copias de bits en una media de
respaldo, 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 solu-
ció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 ejem-
plo, 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 acumula-
tivos — 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 úl-
timo 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 difer-
enciales siguen el mismo enfoque: un respaldo completo periódico seguido de más frecuentes respal-
dos diferenciales.
El efecto de utilizar los respaldos diferenciales de esta forma es que los respaldos diferenciales tien-
den 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áp-
idas (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 im-
plica 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 desas-
tres. La recuperación de desastres es la habilidad de recuperarse de un evento que impacta el fun-
cionamiento 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, colocar
el plan en efecto
• La secuencia de eventos necesaria para preparar el sitio de respaldo una vez que se ha declarado un
desastre
• 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 para
soportar 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 al
nuevo/restaurado centro de datos
Los planes de recuperación de desastres a menudo llenan mútiples carpetas de hojas sueltas. Este
nivel de detalle es vital porque en el evento de una emergencia, el plan quizás sea lo único que quede
de su centro de datos anterior (además de los otros sitios de respaldo, por supuesto) para ayudarlo a
reconstruir y restaurar las operaciones.
Sugerencia
Mientras que los planes de recuperación de desastres deberían de estar a la mano en su sitio
de trabajo, también se deberían conservar copias fuera de sus instalaciones. De esta forma, si un
desastre destruye sus instalaciones no se eliminaran todas las copias de su plan de recuperación. Un
buen lugar para almacenar una copia es en su ubicación de almacenamiento de respaldos. También
se pueden mantener copias del plan de recuperación de desastres en los hogares de miembros
claves 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 asistencia
profesional 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 de
respaldo y configurar el centro de datos temporal, ejecutar las aplicaciones temporalmente y reactivar
las operaciones normales después de que el "desastre" termine. La mayoría de las pruebas no tratan
de llevar a cabo un 100% de las tareas del plan; en cambio, se selecciona un sistema y una aplicación
representativa para reubicarlos en el sitio de respaldo, se coloca en producción por un período de
tiempo 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 un
documento vivo; a medida que el centro de datos cambie, el plan debe ser actualizado para reflejar
esos cambios. En muchas casos, un plan de recuperación de desastres desactualizado puede ser
peor 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 caliente

Uno de los aspectos más importantes del plan de recuperación de desastres es tener una ubicación
desde 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 esen-
cialmente 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 nece-
sarios 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 hard-
ware 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 nor-
males 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 representa-
tivo 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 hard-
ware 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 in-
undado 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 es-
pecí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 re-
cuperació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 funcional-
idades.
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 gzip 5.

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 nom-
bres 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 pen-
sar 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 Torvalds

To: Neil Conway
Subject: 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 buffer
cache and the page cache (where all the actual data is) are not
coherent. This is only going to get even worse in 2.5.x, when the
directories are moved into the page cache as well.
So anybody who depends on "dump" getting backups right is already playing

Russian roulette with their backups. It’s not at all guaranteed to get the
right results - you may end up having stale data in the buffer cache that
ends 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 recu-
peració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 infor-
mativos.
• 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 recur-
sos para los administradores de sistemas Red Hat Enterprise Linux.
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 cabezas, 64
cabezas de escritura, 72
cabezas de lectura, 72
cargas de E/S, escrituras, 73
Símbolos cargas de E/S, lecturas, 73
/etc/cups/, 150 cargas de E/S, rendimiento, 73
/etc/printcap, 150 cilindro, 66
conceptos de direccionamiento, 65
direcciones basadas en bloques, 67
A direcciones basadas en geometría, 65
direcciones, basadas en bloques, 67
abuso de recursos, 133 direcciones, basados en la geometría, 65
abuso, recursos, 133 geometría, problemas con, 66
activación de su suscripción, iv interfaces con estándares de la industria, 68
administración interfaces para, 67
impresoras, 143 interfaces, estándar de la industria, 68
administración de sistemas interfaces, historia, 67
filosofía de, 1 Interfaz IDE, 68
automatización, 1 Interfaz SCSI, 69
comunicación, 3 latencia rotacional, 72
documentación, 2 latencia, rotacional, 72
ingeniería social, riesgos de, 7 lectores contra escrituras, 73
negocio, 6 limitaciones eléctricas de, 71
ocurrencias inesperadas, 8 limitaciones mecánicas de, 71
planificación, 8 movimiento del brazo de acceso, 72
recursos, 6 movimiento, brazo de acceso, 72
seguridad, 7 platos de disco, 63
usuarios, 6 platos, disco, 63
administración de volúmenes lógicos procesamiento de comandos, 72
(Ver LVM) procesamiento, comando, 72
almacenamiento rendimiento de, 71
accesible a través de la red, 79, 105 sector, 66
NFS, 106 Ubicación de E/S, 74
SMB, 106 vista general de, 63
administración de, 63, 87 eliminar, 96, 109
crecimiento, normal, 89 /etc/fstab, eliminar de, 110
monitorizar espacio libre, 87 borrar los contenidos, 97, 110
problemas de usuarios, 88 comando umount, uso de, 110
uso de una aplicación, 89 datos, eliminar, 97
uso excesivo de, 87 implementación, 74
añadir, 92, 107 monitorizar el, 19
/etc/fstab, actualización, 109 partición
configuración, actualizar, 96 atributos de, 75
Discos duros ATA, 93 campo tipo, 76
formatear, 96, 109 extendidas, 75
hardware, instalación, 92 geometría de, 75
particionamiento, 95, 107 lógicas, 76
planificación de respaldos, modificar, 96 primaria, 75
Unidad de dico SCSI, 94 tipo de, 75
basado en RAID vista general de, 74
(Ver RAID) patrones de acceso, 49
cuotas de usuarios, 90 problemas relacionados a archivos, 90
(Ver cuotas de usuarios) acceso a archivos, 90
dispositivos de almacenamiento masivo compartir archivos, 91
brazos de acceso, 64 sistema de archivos, 76, 100
cabeza, 66 activando acceso a, 79
190
archivo /etc/mtab , 104 B

archivo /proc/mounts , 104
bash shell, automatización y, 9
basado en archivos, 76
comado df, uso de, 105
contabilidad del espacio, 78
contabilidad, espacio, 78
C
control de acceso, 77 CD-ROM
directorio jerárquico, 77 sistema de archivos
directorios, 77 (Ver Sistema de archivos ISO 9660)
estructura, directorio, 78 comando chage, 139
EXT2, 101 comando chfn, 139
EXT3, 101 comando chgrp, 140
ISO 9660, 101 comando chmod, 140
montaje, 102 comando chown, 140
montar con el archivo /etc/fstab, 106 comando chpasswd, 139
mostrar lo montado, 103 comando df , 105
MSDOS, 102 comando free, 21, 58
punto de montaje, 103 comando gnome-system-monitor, 22
tiempos de acceso, 77 comando gpasswd, 139
tiempos de creación, 77 comando groupadd, 139
tiempos de modificación, 77 comando groupdel, 139
VFAT, 102 comando groupmod, 139
tecnologías, 49 comando grpck, 139
almacenamiento fuera de línea, 53 comando iostat, 24, 40
almacenamiento para respaldos, 53 comando mpstat, 24
disco duro, 52 comando passwd, 139
L1 cache, 51 comando raidhotadd, uso de, 117
L2 cache, 51 comando sa1, 24
comando sa2, 24
memoria caché, 50
comando sadc , 24
memoria principal, 51
comando sar, 24, 26, 41, 43, 59
RAM, 51
informes, lectura, 27
Registros de CPU, 50
comando top, 20, 21, 42
unidad de disco, 52
comando useradd, 139
tecnologías, avanzadas, 79
comando userdel, 139
archivo /etc/fstab
comando usermod, 139
actualización, 109
comando vmstat, 20, 23, 40, 43, 59
montar sistemas de archivos con, 106
comando watch, 21
archivo /etc/group
comunicación
cuenta de usuario, papel en, 138
Información específica a Red Hat Enterprise Linux,
grupo, papel en, 138 10
archivo /etc/gshadow necesidad de, 3
cuenta de usuario, papel en, 138 configuración de impresoras, 149
grupo, papel en, 138 aplicación basada en texto, 150
archivo /etc/mtab , 104 CUPS, 149
archivo /etc/passwd conjunto de direcciones de trabajo, 56
cuenta de usuario, papel en, 136 contraseña, 124
grupo, papel en, 136 caducidad, 128
archivo /etc/shadow conjunto de caracteres grande usado en, 128
cuenta de usuario, papel en, 136 conjunto de caracteres pequeño usado en, 126
grupo, papel en, 136 corta de, 125
archivo /proc/mdstat, 117 débiles, 125
archivo /proc/mounts , 104 escritas, 127
automatización, 9 información personal usada en, 126
descripción general, 1 largas, 127
memorizables, 128
191
palabras usadas en, 126 setuid, 134

robustas, 127 sticky bit, 134
trucos de palabras usados en, 126 recursos, administración de, 131
usado repetidamente, 127 UID, 135
control de cambios, 170 UIDs del sistema, 135
convenciones cuotas de usuarios
documento, ii activando, 113
cuenta
administración de, 114
(Ver cuenta de usuario)
introducción a, 111
cuenta de usuario
vista general de, 111
acceso a datos compartidos, 131
administración de, 121, 121, 129 específico a grupos, 112
cambios de trabajo, 131 específico al sistema de archivos, 112
nuevos empleados, 129 específico al usuario, 112
terminaciones, 130 límite suave, 113
archivos controlando, 136 límites rígidos, 113
/etc/group, 138 período de gracia, 113
/etc/gshadow, 138 seguimiento de uso de bloques, 112
/etc/passwd, 136 seguimiento de uso de inodes, 112
/etc/shadow, 136 cuotas, disco
contraseña, 124 (Ver cuotas de usuarios)
caducidad, 128 CUPS, 149
conjunto de caracteres grande usado en, 128
conjunto de caracteres pequeño usado en, 126
corta de, 125
débiles, 125
D
escritas, 127 datos
información personal usada en, 126 acceso compartido a, 131, 132
largas, 127 problemas globales de propiedad, 133
memorizables, 128 devlabel, 100
palabras usadas en, 126
directorio principal
robustas, 127
centralizado, 133
trucos de palabras usados en, 126
directorio principal centralizado, 133
usado repetidamente, 127
control de acceso, 129 discos duros, 52
directorio principal Discos duros ATA
centralizado, 133 añadir, 93
GID, 135 dispositivo
GIDs del sistema, 135 accesos a dispositivos completos, 99
herramientas para administrar, 139 alternativas a nombres de dispositivos, 99
comando chage, 139 convención de nombres, 98
comando chfn, 139 devlabel, nombrar con, 100
comando chpasswd, 139 etiquetas de sistemas de archivos, 100
comando passwd, 139 etiquetas, sistemas de archivos, 100
comando useradd, 139 nombres con devlabel, 100
comando userdel, 139 nombres de archivos, 98
comando usermod, 139
nombres de dispositivos, alternativas a, 99
nombre de usuario, 121
partición, 99
cambios a, 123
tipo, 98
colisiones en nombres, 122
convenio de nombres, 121 unidad, 99
permisos relacionados a, 134 documentación
ejecución, 134 Información específica a Red Hat Enterprise Linux,
escritura, 134 10
lectura, 134 documentación, necesidad de, 2
setgid, 134
192
E H
espacio de direcciones virtuales, 55 hardware
espacio en disco contratos de servicios, 155
disponibilidad de partes, 158
(Ver almacenamiento)
hardware cubierto, 158
estadísticas de supervisión horas de cobertura, 155
relacionado a la memoria, 19 presupuesto para, 158
relacionado al almacenamiento, 19 servicio de depósito, 156
relacionado al ancho de banda, 18 servicio drop-off, 156
servicio walk-in, 156
relacionado al CPU, 17
tiempo de respuesta, 157
selección de, 17 técnico in-situ, 157
fallas de, 153
habilidades necesarias para reparar, 153
F repuestos
intercambiar hardware, 155
fallo de página, 56 mantener, 153
filosofía de la administración de sistemas, 1 repuestos, cantidades, 154
repuestos, selección de, 154
Herramienta de configuración de impresoras
(Ver configuración de impresoras)
G herramientas
cuentas de usuario, administrar
GID, 135
(Ver cuentas de usuario, herramientas para
grupo administrar)
acceso a datos compartidos usando, 132 grupos, administración
administración de, 121 (Ver grupo, herramientas para administrar)
archivos controlando, 136 supervisión de recursos, 20
/etc/group, 138 free, 21
iostat, 24
/etc/gshadow, 138
Monitor del Sistema GNOME, 22
/etc/passwd, 136 mpstat, 24
/etc/shadow, 136 OProfile, 28
estructura, determinar, 132 sa1, 24
GID, 135 sa2, 24
sadc, 24
GIDs del sistema, 135
sar, 24, 26
herramientas para administrar, 139 Sysstat, 24
comando gpasswd, 139 top, 21
comando groupadd, 139 vmstat, 23
comando groupdel, 139
comando groupmod, 139
comando grpck, 139
I
permisos relacionados a, 134 ID del grupo
ejecución, 134 (Ver GID)
ID del usuario
escritura, 134
(Ver UID)
lectura, 134 impresoras
setgid, 134 administración, 143
setuid, 134 color, 146
sticky bit, 134 CMYK, 146
inyección de tinta, 146
UID, 135
láser, 147
UIDs del sistema, 135 consideraciones, 143
duplex, 143
193
lenguajes recuperación de desastres, 183

(Ver lenguajes de descripción de páginas RPM, 10
(PDL))
seguridad, 10
local, 149
recursos adicionales, 151 shell scripts, 9
red, 149 sistemas de detección de intrusos, 10
tipos, 143 soporte de software, 183
cera termal, 148
soporte, software, 183
impacto, 144
inyección de tinta, 146 tecnologías de respaldo
láser, 147 AMANDA, 186
láser a color, 147 cpio, 184
línea, 144
descripción general, 183
margarita, 144
matriz de puntos, 144 dump, 185
sublimación de tinte, 148 tar, 184
tinta sólida, 148 información específica de Red Hat Enterprise Linux
impresoras a color láser, 147
impresoras de impacto, 144 herramientas de supervisión de recursos
consumibles, 146 free, 58
línea, 144 sar, 59
margarita, 144 vmstat, 59
matriz de puntos, 144
impresoras de inyección de tinta, 146 supervisión de recursos
consumibles, 146 memoria, 58
impresoras de línea ingeniería social, riesgos de, 7
(Ver impresoras de impacto)
ingeniería, social, 7
impresoras de margarita
(Ver impresoras de impacto) intercambio, 57
impresoras de matriz de puntos Interfaz IDE
(Ver impresoras de impacto) vista general de, 68
impresoras láser, 147
Interfaz SCSI
color, 147
consumibles, 147 vista general de, 69
inesperado, preparación para lo, 8
Información específica a Red Hat Enterprise Linux
automatización, 9
bash shell, 9
L
comunicación, 10 lenguajes de descripción de páginas (PDL), 148
documentación, 10
Interpress, 148
herramientas de supervisión de recursos
iostat, 40 PCL, 148
sar, 41, 43 PostScript, 148
top, 42 lpd, 151
vmstat, 40, 43
LVM
herramientas para monitorizar recursos, 20
free, 20 agrupamiento de almacenamiento, 86
OProfile, 20 comparado con RAID, 87
Sysstat, 20 migración de datos, 86
top, 20
vmstat, 20 migración, datos, 86
monitorizar recursos redimensionamiento de volúmenes lógicos, 86
ancho de banda , 40 redimensionamiento, volumen lógico, 86
Poder de CPU, 40 vista general de, 86
PAM, 10
perl, 9
194
M permiso de ejecución, 134

permiso de escritura, 134
memoria
permiso de lectura, 134
memoria virtual, 54
permiso de sticky bit, 134
almacenamiento de respaldo, 55
permiso setgid, 10, 134
conjunto de direcciones de trabajo, 56
permiso setuid, 10, 134
descripción general de, 54
permisos, 134
espacio de direcciones virtuales, 55
herramientas para administrar
fallo de página, 56
comando chgrp, 140
intercambio, 57
comando chmod, 140
rendimiento de, 57
comando chown, 140
rendimiento, mejor caso, 58
planificación de la capacidad, 16
rendimiento, peor caso, 57
planificación para desastres, 153
monitorizar el, 19
energía, reserva, 164
utilización de recursos de, 49
conjunto moto-generador, 164
memoria caché, 50
generador, 166
memoria física
interrupciones, prolongadas, 166
(Ver memoria)
UPS, 165
memoria virtual
tipos de desastre , 153
(Ver memoria)
aire acondicionado, 167
monitorizar el rendimiento del sistema, 16
aplicaciones usadas incorrectamente, 168
montaje de sistemas de archivos
bloqueos del sistema operativo, 159
(Ver almacenamiento, sistemas de archivos, mon-
calefacción, 167
taje)
caídas del sistema operativo, 159
multiprocesamiento simétrico, 39
electricidad, calidad de, 163
electricidad, seguridad de, 162
eléctrical, 162
N
errores de configuración, 169
negocio, conocimiento de, 6 errores de operadores, 168
NFS, 106 errores de procedimientos, 168
nombre de usuario, 121 errores de servicio técnico, 171
cambio, 123 errores de usuarios, 168
colisiones entre, 122 errores del administrador de sistemas, 169
convenio de nombres, 121 errores durante procedimientos, 169
nombres de archivos errores humanos, 167
dispositivo, 98 errores relacionados al mantenimiento, 171
fallas ambientales, 161
fallas de las aplicaciones, 160
O fallas del hardware, 153
fallas del sistema operativo, 159
OProfile, 20, 28
fallas del software, 159
HVAC, 167
integridad del edificio, 162
P relacionado al tiempo, 167
PAM, 10 reparaciones incorrectas, 171
partición, 99 ventilación, 167
atributos de, 75 planificación, importancia de, 8
campo tipo, 76 Pluggable Authentication Modules
geometría, 75 (Ver PAM)
tipo, 75 Poder de CPU
creación de, 95, 107 (Ver recursos, sistema y poder de procesamiento)
extendidas, 75 poder de procesamiento, recursos relacionados a
lógicas, 76 (Ver recursos, sistema y poder de procesamiento)
primaria, 75 printconf
vista general de, 74 (Ver configuración de impresoras)
perl, automatización y, 9 printtool
195
(Ver configuración de impresoras) (Ver almacenamiento)

puntos de montaje ancho de banda , 33
(Ver almacenamiento, sistema de archivos, punto buses, ejemplos de, 34
de montaje) capacidad, incrementar, 35
carga, distribuir, 35
carga, reducir, 35
R datapaths, ejemplos de, 34
datapaths, papel en, 34
RAID descripción general de, 33
comparado con LVM, 87 monitorizar el, 18
creación de formaciones papel de los buses en, 33
(Ver RAID, formaciones, creación) problemas relacionados a, 34
formaciones soluciones a problemas con, 35
administración de, 116 memoria
comando raidhotadd, uso de, 117 (Ver memoria)
estatus, verificar, 117 poder de procesamiento, 33
reconstrucción, 117 actualizar, 39
formaciones, creación, 115 aplicaciones, eliminar, 38
en el momento de la instalación, 115 capacidad, incrementar, 39
tiempo luego de la instalación, 116 carga, reducir, 38
implementaciones de, 84 consumidores de, 36
hardware RAID, 85 CPU, actualizar, 39
software RAID, 85 descripción general de, 36
introducción a, 80 escasez de, mejorar, 37
niveles de, 81 hechos relacionados a, 36
RAID 0, 81 monitorizar el, 17
RAID 0, desventajas de, 82 multiprocesamiento simétrico, 39
RAID 0, ventajas de, 82 SMP, 39
RAID 1, 82 sobrecarga de aplicaciones, reducir, 38
RAID 1, desventajas de, 82 Sobrecarga del SO, reducir, 38
RAID 5, 83 uso de aplicaciones de, 37
RAID 5, desventajas de, 83 uso del sistema operativo de, 37
RAID 5, ventajas de, 83 registro de su suscripción, iv
RAID anidado, 84 registro de suscripción, iv
RAID anidado, 84 respaldos
vista general de, 81 almacenamiento de, 177
RAM, 51 comprar software, 173
recuperación de desastres construir software, 173
disponibilidad del hardware, 181 introducción a, 172
disponibilidad del software, 181 planificación, modificar, 96
final de, 183 problemas de restauración, 178
introducción a, 179 evaluar la restauración, 179
plan, creación, evaluación, implementación, 179 restauraciones a metal pelado, 178
respaldos, disponibilidad de, 182 problemas relacionados a los datos, 172
sitio de respaldo, 180 Software de respaldo AMANDA, 186
conectividad de red a, 182 tecnologías utilizadas, 183
personal de, 182 cpio, 184
recursión dump, 185
(Ver recursión) tar, 184
recursos del sistema tipos de, 174
(Ver recursos, sistema) respaldos completos, 175
recursos relacionados al ancho de banda respaldos diferenciales, 175
(Ver recursos, sistema, ancho de banda) respaldos incrementales, 175
recursos, importancia de, 6 tipos de media, 176
recursos, sistema cinta, 176
almacenamiento disco, 176
196
red, 177 Poder de CPU, 17

RPM, 10 qué monitorizar, 17
RPM Package Manager rendimiento del sistema, 16
(Ver RPM) Sysstat, 20, 24
system-config-printer
(Ver configuración de impresoras)
S
seguridad U
importancia de, 7
Información específica a Red Hat Enterprise Linux, UID, 135
10 Unidad de dico SCSI
shell scripts, 9 añadir, 94
sistema de archivos unidades de disco, 52
etiquetas, 100 usuarios
Sistema de archivos EXT2, 101 importancia de, 6
Sistema de archivos EXT3, 101
Sistema de archivos ISO 9660, 101
Sistema de archivos MSDOS, 102
Sistema de archivos VFAT, 102
sistemas de detección de intrusos, 10
SMB, 106
SMP, 39
software
asistencia para
auto asistencia, 160
descripción general, 160
documentación, 160
soporte de correo electrónico, 160
soporte in situ, 161
soporte telefónico, 161
Soporte Web, 160
supervisión
recursos, 15
rendimiento del sistema, 16
supervisión de recursos, 15
almacenamiento, 19
ancho de banda, 18
capacidad del sistema, 16
conceptos detrás, 15
herramienta utilizada, 20
herramientas
free, 21
iostat, 24
Monitor del Sistema GNOME, 22
mpstat, 24
OProfile, 28
sa1, 24
sa2, 24
sadc, 24
sar, 24, 26
Sysstat, 24
top, 21
vmstat, 23
memoria, 19
planificación de la capacidad, 16
Colofón
Los manuales son escritos en formato DocBook SGML v4.1. Los formatos HTML y PDF son pro-
ducidos 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, Ita-
nium™, AMD64 e Intel® Extended Memory 64 Technology (Intel® EM64T) de Red Hat Enter-
prise 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 sis-
temas 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® Ex-
tended 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 En-
terprise 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 Enterprise
Linux
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

Rhel Isa Es

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Rhel Isa Es

Cargado por

Copyright:

Formatos disponibles

Red Hat Enterprise Linux 4

Red Hat, Inc.

1. Información específica a la arquitectura

2. Convenciones del documento

nombre del archivo

texto de una interfaz gráfica (GUI)

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

botón en una pantalla o ventana GUI

entrada del usuario

• Proporcione un nombre de conexión a Red Hat

3.1. Proporcione un nombre de conexión a Red Hat

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

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

3.2. Proporcione su número de suscripción

3.3. Conecte su sistema

4. ...y hay más

4.1. Envíenos sus comentarios

1.1. Automatizar todo

• Verificación e informes de espacio libre en disco

1.2. Documentar todo

"Más tarde lo hago."

"Para qué escribirlo? Yo me recuerdo."

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

1.3. Comunique tanto como sea posible

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

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

• La naturaleza del cambio

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

Es importante resaltar algunas puntos:

• Comunique efectivamente la hora de inicio y duración de cualquier tiempo de parada relacionado

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

Parada del sistema programada para esta noche

1.3.3. Informe a sus usuarios sobre lo que ha hecho

Finalizada la parada del sistema

1.4. Conozca sus recursos

1.5. Conozca a sus usuarios

1.6. Conozca su negocio

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

1.7. La seguridad no puede ser una ocurrencia posterior

1.7.1. Los riesgos de Ingeniería Social

• Un comentario informal durante la aburrida reunión semanal de personal sobre el comienzo de

1.9. Espere lo inesperado

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

• El intérprete de comandos bash

1.10.2. Documentación y comunicación

• El editor de texto gedit

1.11. Recursos adicionales

1.11.1. Documentación instalada

1.11.2. Sitios web de utilidad

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

1.11.3. Libros relacionados

2.1. Conceptos básicos

2.2. Monitorizar el rendimiento del sistema

2.3. Monitorizar la capacidad del sistema

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

2.4. ¿Qué monitorizar?

• ¿Cuánto espacio libre está disponible?

2.4.1. Monitorizar el poder de CPU

Usuario contra Sistema

2.4.2. Monitorizar el ancho de banda

Cuentas y tasas de interfaz

1. Asumiendo que se trata de un sistema con un único procesador.

Transferencias por segundo