Rhel Isa Es

Red Hat Enterprise Linux 4
Introduccin a la administracin
de sistemas
Red Hat Enterprise Linux 4: Introduccin a la administracin de sistemas Copyright 2005 por Red Hat, Inc.
Red Hat, Inc.
1801 Varsity Drive Raleigh NC 27606-2072 USA Telfono: +1 919 754 3700 Telfono: 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 trminos y condiciones establecidas en la
Open Publication License, V1.0 o versiones posteriores (la ltima versin est disponible en
http://www.opencontent.org/openpub/).
Los derechos de autor del propietario prohiben la distribucin de versiones de este documento sustancialmente modicadas
sin un permiso explcito.
La distribucin del producto o una copia del mismo en forma de libro con nes 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 pases.
Todas las dems marcas referenciadas aqu son propiedad de sus respectivos dueos.
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
Introduccin ......................................................................................................................................... i
1. Informacin especca a la arquitectura ................................................................................ i
2. Convenciones del documento ............................................................................................... ii
3. Active su suscripcin ........................................................................................................... iv
3.1. Proporcione un nombre de conexin a Red Hat .................................................... v
3.2. Proporcione su nmero de suscripcin .................................................................. v
3.3. Conecte su sistema................................................................................................. v
4. ...y hay ms ........................................................................................................................... v
4.1. Envenos sus comentarios ..................................................................................... vi
1. Filosofa de la Administracin 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 Ingeniera Social ......................................................................... 7
1.8. Planique ........................................................................................................................... 8
1.9. Espere lo inesperado .......................................................................................................... 8
1.10. Informacin especca a Red Hat Enterprise Linux ........................................................ 9
1.10.1. Automatizacin ................................................................................................. 9
1.10.2. Documentacin y comunicacin..................................................................... 10
1.10.3. Seguridad ........................................................................................................ 10
1.11. Recursos adicionales...................................................................................................... 11
1.11.1. Documentacin instalada ................................................................................ 11
1.11.2. Sitios web de utilidad...................................................................................... 12
1.11.3. Libros relacionados......................................................................................... 12
2. Supervisin de recursos ................................................................................................................ 15
2.1. Conceptos bsicos............................................................................................................ 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. OProle ............................................................................................................. 27
2.6. Recursos adicionales........................................................................................................ 31
2.6.1. Documentacin 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 utilizacin del CPU en Red Hat Enterprise Linux .................... 42
3.4.2. Sitios Web tiles ............................................................................................... 46
4. Memoria fsica 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 lnea ................................................ 53
4.3. Conceptos bsicos sobre Memoria Virtual ...................................................................... 53
4.3.1. La memoria virtual en trminos 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 pgina ................................................................................................ 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. Informacin especca de Red Hat Enterprise Linux ...................................................... 58
4.7.2. Sitios web de utilidad........................................................................................ 61
5. Administracin 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 geometra ................................................................ 65
5.2.2. Direcciones basadas en bloques........................................................................ 67
5.3. Interfaces de dispositivos de almacenamiento masivo..................................................... 67
5.3.1. Antecedentes histricos .................................................................................... 67
5.3.2. Interfaces de hoy da con estndares de la industria ......................................... 68
5.4. Caractersticas de rendimiento del disco duro ................................................................. 71
5.4.1. Limitaciones mecnicas/elctricas.................................................................... 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. Tecnologas avanzadas de almacenamiento ..................................................................... 79
5.6.1. Almacenamiento accesible a travs de la red ................................................... 79
5.6.2. Almacenamiento basado en RAID.................................................................... 80
5.6.3. Administracin de Volmenes Lgicos ............................................................ 85
5.7. La administracin del almacenamiento da a da............................................................. 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. Aadir/Eliminar almacenamiento ..................................................................... 92
5.8. Un comentario sobre Respaldos....................................................................................... 98
5.9. Documentacin especca a Red Hat Enterprise Linux .................................................. 98
5.9.1. Convenciones de nombres de dispositivos........................................................ 98
5.9.2. Conceptos bsicos 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 automticamente con /etc/fstab ................. 106
5.9.6. Aadir/Eliminar almacenamiento ................................................................... 107
5.9.7. Implementacin de Cuotas de Disco............................................................... 111
5.9.8. Creacin de Formaciones RAID ..................................................................... 115
5.9.9. Administracin da a da de las formaciones RAID ....................................... 116
5.9.10. Administracin de Volmenes Lgicos ........................................................ 118
5.10. Recursos adicionales.................................................................................................... 118
5.10.1. Documentacin instalada .............................................................................. 118
5.10.2. Sitios Web de utilidad ................................................................................... 119
5.10.3. Libros relacionados....................................................................................... 119
6. Administracin de cuentas de usuarios y acceso a recursos ................................................... 121
6.1. Administracin de cuentas de usuarios.......................................................................... 121
6.1.1. El nombre de usuario ...................................................................................... 121
6.1.2. Contraseas ..................................................................................................... 124
6.1.3. Informacin de control de acceso ................................................................... 128
6.1.4. Administracin da a da de cuentas y acceso a recursos................................ 129
6.2. Administracin de recursos de usuarios ........................................................................ 131
6.2.1. Quin 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. Informacin especca 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 impresin .............................................................................................................. 143

7.1. Tipos de impresoras ....................................................................................................... 143
7.1.1. Consideraciones de impresin ........................................................................ 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 lnea ......................................................................................... 145
7.2.4. Consumibles para las impresoras de impacto ................................................. 145
7.3. Impresoras de inyeccin de tinta.................................................................................... 146
7.3.1. Consumibles de inyeccin de tinta ................................................................. 146
7.4. Impresoras lser ............................................................................................................. 147
7.4.1. Impresoras a color lser .................................................................................. 147
7.4.2. Consumibles para impresoras lser................................................................. 147
7.5. Otros tipos de impresoras............................................................................................... 148
7.6. Lenguajes y tecnologas de impresin ........................................................................... 148
7.7. Impresin de red Versus Impresin local....................................................................... 149
7.8. Informacin especca de Red Hat Enterprise Linux .................................................... 149
7.9.2. Sitios web de utilidad...................................................................................... 151
8. Planicacin 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 restauracin .............................................................................. 178
8.3. Recuperacin de desastres ............................................................................................. 179
8.3.1. Creacin, Evaluacin e Implementacin de un Plan de Recuperacin de
Desastres ....................................................................................................... 179
8.3.2. Sitios de respaldo: fro, 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. Informacin especca a Red Hat Enterprise Linux ...................................................... 183
8.4.1. Soporte de Software........................................................................................ 183
8.4.2. Tecnologas de respaldo .................................................................................. 183
8.5.2. Sitios Web de utilidad ..................................................................................... 187
ndice................................................................................................................................................ 189
Colofn ............................................................................................................................................. 197
Introduccin
Bienvenidos a Introduccin a la administracin de sistemas de Red Hat Enterprise Linux. El libro Introduccin a la administracin de sistemas de Red Hat Enterprise Linux contiene informa cin introductoria para los nuevos administradores de sistemas de Red Hat Enterprise Linux. No le ensea como llevar a cabo tareas especcas bajo Red Hat Enterprise Linux; ms bien le hace llegar el conocimiento general que los administradores de sistemas con ms experiencia han aprendido con el paso del tiempo. Esta gua 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), debera comenzar comprando un libro introductorio de Linux. Cada captulo en Introduccin a la administracin de sistemas de Red Hat Enterprise Linux tiene la estructura siguiente:

Material de descripcin general Esta seccin discute el tema del captulo sin profundizar mucho en detalles sobre un sistema operativo especco, tecnologa o metodologa. Material especco a Red Hat Enterprise Linux Esta seccin describe aspectos del tpico rela cionado a Linux en general y en particular a Red Hat Enterprise Linux. Recursos adicionales para complementar los estudios Esta seccin incluye apuntadores a otros manuales de Red Hat Enterprise Linux, sitios web de utilidad y libros que contienen informacin aplicable al tpico.
Al adoptar una estructura consistente, los lectores pueden leer ms fcilmente Introduccin a la ad ministracin 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 especcamente en Red Hat Enterprise Linux, mientras que un nuevo administrador de sistemas podra comenzar leyendo las secciones de descrip cin general y utilizar las secciones especcas de Red Hat Enterprise Linux, como una introduccin a recursos ms avanzados. En el lado de los recursos adicionales, el Manual de administracin del sistema de Red Hat Enterprise Linux es un recurso excelente para llevar a cabo tareas especcas en el ambiente Red Hat Enterprise Linux. Los administradores que requieren informacin ms avanzada y especca, deberan consultar el Manual de referencia de Red Hat Enterprise Linux. Las versiones en HTML, PDF y RPM de los manuales estn disponibles en el CD de documentacin de Red Hat Enterprise Linux y en lnea en http://www.redhat.com/docs/.
Nota Aunque este manual reeja la informacin ms actualizada, lea las Notas de ltima hora de Red Hat Enterprise Linux para ver aquella informacin que quizs no estaba disponible para el momento antes de que la documentacin se nalizara. Estas se pueden encontrar en el CD#1 de Red Hat Enterprise Linux y tambin el lnea en http://www.redhat.com/docs/.
1. Informacin especca a la arquitectura

A menos que se indique lo contrario, toda la informacin contenida en este manual nicamente aplica al procesador x86 y a los procesadores que tienen Intel Extended Memory 64 Technology (Intel EM64T) y las tecnologas AMD64. Para informacin especca a la arquitectura, consulte el Manual de instalacin de Red Hat Enterprise Linux para su arquitectura especca.
ii
Introduccin
2. Convenciones del documento

Cuando lea este manual, ver que algunas palabras estn representadas en fuentes, tipos de letra, tamao y peso diferentes. Esta forma de evidenciar es sistemtica; se representan diferentes palabras con el mismo estilo para indicar su pertenencia a una categora especca. 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 lnea de comandos y pulsar [Intro] para invocar el comando. A veces un comando contiene palabras que apareceran 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 deniciones de la shell de bash y alias para su propio uso. El archivo /etc/fstab contiene informacin sobre diferentes dispositivos del sistema y sis temas de archivos. Instale el RPM webalizer si quiere utilizar un programa de anlisis del archivo de registro del servidor Web. aplicacin Este estilo indica que el programa es una aplicacin de usuario nal (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 completacin con [Tab], introduzca un carcter 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]-[combinacin] Una combinacin de teclas aparece de la siguiente manera. Por ejemplo: La combinacin de teclas [Ctrl]-[Alt]-[Retroceso] le har salir de la sesin grca y volver a la pantalla grca de inicio de sesin o a la consola. texto de una interfaz grca (GUI) Un ttulo, palabra o frase encontrada en una pantalla o ventana de interfaz grca GUI apare cer en este estilo. La nalidad del texto escrito en este estilo es la de identicar una pantalla GUI particular o un elemento en una pantalla GUI (p.e, un texto relacionado con una casilla de vericacin o un campo). Ejemplos:
Introduccin
iii
Seleccione la casilla de vericacin Pedir contrasea si quiere que su salvapantallas pida una contrasea antes de terminar. nivel superior de un men en una pantalla o ventana GUI Cuando vea una palabra con este estilo, signica 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 opcin Nueva solapa le permite abrir mltiples intrpretes de comandos de la shell en la misma ventana. Si tiene que escribir una secuencia de comandos desde un men GUI, aparecern como en el siguiente ejemplo: Vaya a Botn del men principal (en el Panel) => Programacin => Emacs para iniciar el editor de textos Emacs. botn en una pantalla o ventana GUI Este estilo indica que el texto puede encontrarse en un botn que se puede pulsar en una pantalla GUI. Por ejemplo: Pulse el botn Anterior para volver a la ltima pgina Web que haya visitado.
salida de pantalla
El texto en este estilo indica el texto desplegado en un intrprete 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 Mail about.html backupfiles logs mail paulwesterberg.png reports
La salida de pantalla que le devuelvan como respuesta al comando (en este caso, el contenido del directorio) se mostrar en este estilo.
intrprete de comandos
El intrprete 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 lnea 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 instalacin en modo texto, necesitar escribir el comando text en el intrprete 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
Introduccin El directorio para la fuente del kernel es /usr/src/ version-number /, donde version-number es la versin del kernel instalado en este sistema.
Adicionalmente, usamos diferentes tipos de estrategias para llamar su atencin para determinados tipos de informacin. Dependiendo de lo importante que esta informacin sea para su sistema, estos elementos sern marcados como nota, sugerencia, importante, atencin o aviso. Por ejemplo:
Nota Recuerde que Linux es sensible a maysculas y minsculas. En otras palabras, rosa no es lo mismo que ROSA o rOsA.
Sugerencia El directorio /usr/share/doc/ contiene documentacin adicional de los paquetes instalados en su sistema.
Importante Si modica el archivo de conguracin de DHCP, los cambios no surtirn efecto sino hasta que reinicie el demonio DHCP.
Atencin 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 prdida de datos o en un ambiente del sistema daado.
3. Active su suscripcin
Antes de que pueda acceder a cualquier informacin de mantenimiento de software o servicios y a la informacin de soporte incluida con su suscripcin, debe activar su suscripcin registrndose con Red Hat. El registro incluye los pasos siguientes:

Proporcione un nombre de conexin a Red Hat Proporcione un nmero de suscripcin
Introduccin Conecte su sistema
La primera vez que arranque su instalacin de Red Hat Enterprise Linux, se le pedir que se registre con Red Hat utilizando el Agente de conguracin. Si sigue las indicaciones durante el Agente de conguracin, puede completar los pasos para la inscripcin y activar su suscripcin. Si por alguna razn no puede terminar la inscripcin durante el Agente de conguracin (lo que requiere de acceso a la Internet), alternativamente puede completar el proceso de registro en lnea en http://www.redhat.com/register/.
3.1. Proporcione un nombre de conexin a Red Hat

Si no tiene un usuario de conexin a Red Hat puede crear uno cuando se le solicite durante el Agente de conguracin, o en lnea en:
https://www.redhat.com/apps/activate/newlogin.html
Un usuario de conexin Red Hat le permite acceder a:

Actualizaciones de software, erratas y mantenimiento a travs de Red Hat Network Recursos de soporte tcnico de Red Hat, documentacin y base de datos de conocimiento
Si se le ha olvidado su usuario de conexin Red Hat, puede buscarlo en lnea en:

https://rhn.redhat.com/help/forgot_password.pxt
3.2. Proporcione su nmero de suscripcin

Su nmero de suscripcin est ubicado en el paquete en el que vino su pedido. Si su paquete no incluy un nmero de suscripcin, entonces su suscripcin fue activada por usted y se puede saltar este paso. Puede suministrar su nmero de suscripcin cuando se le solicite durante el Agente de conguracin 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 conguracin Marque las opciones Enviar informacin del hard ware y Enviar lista de paquetes del sistema cuando se le pregunte. 2. Despus de terminar el Agente de conguracin Desde el Men principal, vaya a Her ramientas del sistema, luego seleccione Red Hat Network. 3. Despus de completarse el Agente de conguracin Escriba el comando siguiente desde la lnea de comandos como usuario root.
/usr/bin/up2date --register
vi
Introduccin
4. ...y hay ms
La Introduccin a la administracin 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 documentacin nueva y mejorada.
4.1. Envenos sus comentarios

Si encuentra un error tipogrco en la Introduccin a la administracin de sistemas de Red Hat En terprise Linux o si se le ocurre una forma en la que podramos mejorar este manual, nos encantara escuchar de usted. Por favor enve un reporte a Bugzilla (http://bugzilla.redhat.com/bugzilla) indi cando el componente rhel-isa. No se olvide de mencionar el identicador del manual:
rhel-isa(ES)-4-Print-RHI (2004-08-25T17:11)
Si menciona el identicador del manual, sabremos exctamente cul versin del manual posee. Si tiene alguna sugerencia para mejorar la documentacin, trate de ser lo ms especco posible. Si encuentra algn error, por favor incluya el nmero de la seccin y algo del texto que lo rodea para que lo podamos encontrar fcilmente.
Captulo 1.
Filosofa de la Administracin de Sistemas
An cuando los detalles especcos de la administracin de sistemas pueden variar entre plataformas, hay temas subyacentes que no. Estos temas conforman la losofa de la administracin 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 Planique Espere lo inesperado
Las secciones siguientes exploran cada tema en detalle.
1.1. Automatizar todo

La mayora de los administradores de sistemas son superados en nmero bien sea por sus usuarios, sus sistemas o ambos. En muchos casos, la automatizacin es la nica forma de mantenerse al da. En general, cualquier cosa realizada ms de una vez se debera examinar como un posible candidato para automatizacin. He aqu algunas de las tareas comnmente automatizadas:

Vericacin e informes de espacio libre en disco Respaldos Recoleccin de datos de rendimiento del sistema Mantenimiento de cuentas de usuarios (crear, eliminar, etc.) Funciones especcas 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 estn limitadas por la disposicin del administrador de escribir los scripts necesarios. En este caso, el ser ojo (y dejar que la computadora haga la mayor parte del trabajo mundano) es en realidad algo positivo. La automatizacin proporciona a los usuarios el benecio extra de mayor previsibilidad y consistencia de servicios.
Captulo 1. Filosofa de la Administracin de Sistemas
Sugerencia Recuerde que si tiene una tarea que debera ser automatizada, es muy probable que no sea el primer administrador con esa necesidad. Aqu es donde los benecios del software de cdigo abierto real mente brillan quizs pueda utilizar el trabajo de otra persona para automatizar el procedimiento manual que actualmente est consumiendo su tiempo. Por esto, asegrese siempre de hacer una bsqueda en internet antes de escribir cualquier cosa ms compleja que un pequeo script de Perl.
1.2. Documentar todo

Si se les da la opcin de seleccionar entre instalar un nuevo servidor y escribir un documento pro cedimental sobre como realizar copias de seguridad, el administrador promedio escogera instalar un nuevo servidor. Aunque esto no es para nada inusual, usted debe documentar lo que hace. Muchos administradores de sistemas posponen la preparacin de la documentacin necesaria por una variedad de razones: "Ms tarde lo hago." Desafortunadamente, esto usualmente no es verdad. An si el administrador realmente tiene la intencin de hacerlo, la naturaleza del trabajo es tal que las tareas diarias son usualmente demasiado caticas para "hacerlo ms tarde". Peor an, mientras pasa ms tiempo ms 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 fotogrca, usted no se recordar. O peor an, slo recordar la mitad, sin darse cuenta de que le falta la historia completa. Esto conduce a una prdida de tiempo tratando de reaprender lo que ha olvidado o reparando lo que ech a perder debido a un entendimiento incompleto de la situacin. "Si lo mantengo en mi memoria, no me despedirn as tendr seguridad laboral!" Aunque esto puede funcionar por un tiempo, invariablemente conduce a menos no ms seguridad laboral. Piense por un momento lo que puede pasar durante una emergencia. Puede que usted no est disponible, la documentacin puede salvar el da dejando que alguien ms resuelva el problema en su ausencia. Nunca olvide que las emergencias tienden a ocurrir justo cuando la gerencia est ms atenta. En tales casos, es mejor tener la documentacin como parte de la solucin a que el problema sea su ausencia. Adems, si es parte de una organizacin en crecimiento, eventualmente habr necesidad de otro administrador de sistemas. Cmo puede esta persona aprender a respaldarlo si todo est en su cabeza? Peor an, el no tener documentacin 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 benecios de la documentacin de sistemas. Lo que nos lleva a la siguiente pregunta: Por qu debera documentar? He aqu una lista parcial: Polticas Las polticas son escritas para formalizar y claricar la relacin 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 mtodo de diseminacin de las polticas a su comunidad varan de organizacin a organizacin.
Captulo 1. Filosofa de la Administracin de Sistemas 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 administracin de cuentas de usuarios, procedimientos de reportes de proble mas, etc. De la misma manera que la automatizacin, si un procedimiento es seguido ms 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 congurar sistemas para un mximo rendimiento, ajustar scripts, modicar archivos de cong uracin, etc. Todos estos cambios deberan estar documentados de alguna forma. De lo contrario, se puede encontrar completamente confundido sobre los cambios que realiz unos meses atrs. Algunas organizaciones utilizan mtodos ms complejos para hacer un seguimiento de los cam bios, pero en muchos casos una simple revisin histrica al comienzo del archivo que est siendo modicado, es todo lo que se necesita. Como mnimo, cada entrada en la revisin histrica de bera contener:

El nombre o iniciales de la persona que est ejecutando el cambio La fecha en que se realiz el cambio La razn 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 impresin duplex de la impresora de reemplazo)
1.3. Comunique tanto como sea posible

Cuando se reere a sus usuarios, nunca hay demasiado que comunicar. Tenga en cuenta que los pe queos cambios que usted puede pensar son prcticamente insignicantes, pueden confundir comple tamente al asistente administrativo de Recursos Humanos. El mtodo que utilice para comunicarse con sus usuarios puede variar de acuerdo a su organizacin. Algunas organizaciones utilizan correo electrnico, otras un sitio web interno. Otras pueden manejar esto con Usenet o IRC. En algunos lugares puede inclusive ser suciente una hoja de papel en la cartelera informativa de la ocina. En cualquier caso, utilice el mtodo que mejor funcione de acuerdo a su organizacin. 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

Asegrese de advertir a sus usuarios con tiempo antes de hacer cualquier cosa. La cantidad de pre aviso necesario vara de acuerdo al tipo de cambio (actualizar un sistema operativo requerir mucho ms tiempo de aviso que el cambio del color predeterminado de la pantalla de inicio de sesin), as como tambin la naturaleza de su comunidad de usuarios (los usuarios con ms inclinacin tecnolgica tienden a manejar los cambios con mayor disposicin que aquellos con habilidades mnimas.) Como mnimo, debera describir:
4 La naturaleza del cambio Cuando ocurrir Porqu est sucediendo
Aproximadamente cunto tiempo tomar El impacto (si existe) que pueden esperar los usuarios debido al cambio La informacin de contacto si tienen alguna pregunta o dudas
He aqu una situacin hipottica. 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 mdulo del CPU a un modelo ms rpido y reiniciar. Una vez hecho esto, usted mover la base de datos a un almacenamiento tipo RAID. He aqu un posible anuncio para esta situacin:
Planicacin para el tiempo fuera de servicio del sistema el viernes en la noche

Comenzando este viernes a las 6pm (medianoche para nuestros asociados en Berln), todas las aplicaciones nancieras estarn indisponibles por un perodo de aproximadamente cuatro horas. Durante este tiempo, se llevarn a cabo cambios en el hardware y software del servidor de base de datos de Finanzas. Estos cambios reducirn en gran medida el tiempo requerido para ejecutar las aplicaciones de Cuentas por Pagar, Cuentas por Cobrar y la Hoja de Balance Semanal. Adems del cambio en el tiempo de ejecucin, la mayora de la gente no debera experimentar ningn otro cambio. Sin embargo, aquellas personas que hayan escrito sus propias consultas SQL deben tener en cuenta que la distribucin de algunos ndices cambiar. Esto est documentado en la intranet de la compaa, en la pgina de Finanzas. Si tiene alguna pregunta, comentarios o dudas, por favor comunquese con el Administrador de Sistemas en la extensin 4321.
Es importante resaltar algunas puntos:

Comunique efectivamente la hora de inicio y duracin de cualquier tiempo de parada relacionado con el cambio. Asegrese de indicar la hora del cambio de forma que sea til a todos los usuarios, sin importar su ubicacin. Utilice una terminologa que sus usuarios puedan entender. La gente que se ver impactada por este cambio no le importa si el nuevo mdulo 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 lgico 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 repeticin del mensaje inicial, pero haciendo ms obvio la naturaleza inminente del cambio ("La actualizacin del sistema se llevar a cabo ESTA NOCHE."). Esta es tambin una buena oportunidad para contestar pblicamente cualquier pregunta que haya recibido como resultado del primer mensaje. Continuando con nuestro mensaje hipottico, 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 ocina de Berln). Puede encontrar el anuncio original en el sitio web de la intranet corporativa, en la pgina de Administracin del Sistema. Mucha gente ha preguntado si deberan 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 ningn trabajo realizado en sus estaciones de trabajo personales. Recuerde, aquellos que hayan escrito sus propias consultas SQL deben estar conscientes de que la dis posicin de algunos ndices cambiar. Esto est documentado en la intranet corporativa, en la pgina 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

Despus de terminar de hacer los cambios, usted debe decirle a sus usuarios lo que ha hecho. Una vez ms, esto debera ser un resmen de los mensajes anteriores (invariablemente habr alguin que no los ha ledo.)1 Sin embargo, hay algo muy importante que debe agregar. Es de suma importancia que informe a sus usuarios sobre el estado actual. La actualizacin no sali como lo tena pensado? El nuevo servidor de almacenamiento solamente pudo servir los sistemas en Ingeniera 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 solucin nal. En nuestra situacin hipottica, la parada tuvo algunos problemas. El nuevo mdulo de CPU no fun cion; una llamada al fabricante del sistema revel que se requiere una versin especial del mdulo para las actualizaciones en el campo. En el lado positivo, la migracin de la base de datos al volumen RAID sali bien (an cuando tom un poco ms tiempo de lo planeado debido a los problemas con el mdulo de CPU). He aqu un posible anuncio
Finalizada la parada del sistema

Finaliz la parada del sistema planicada para este viernes en la noche (consulte la pgina de Admin istracin 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 ms de cuatros horas, que era como se tena planicado 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 tena planicado originalmente. Pronto se anunciar una segunda parada tan pronto como se resuelvan los problemas que impidieron la nalizacin de la tarea. Tenga en cuenta que el tiempo fuera de servicio modic algunos ndices de las bases de datos; las per sonas que han escrito sus propias consultas SQL deberan consultar la pgina de Finanzas en la intranet corporativa. Por favor contacte a Administracin del Sistema en la extensin 4321 si tiene alguna pregunta.
Con este tipo de informacin, sus usuarios tendrn suciente informacin de fondo para continuar con su trabajo y para entender cmo los cambios los impactan.
1. Asegrese de enviar este mensaje tan pronto termine el trabajo, antes de irse a su casa. Una vez que deje la
ocina, es muy fcil olvidarse, dejando a los usuarios en la oscuridad sobre si pueden usar el sistema o no.
1.4. Conozca sus recursos

La administracin 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 disposicin. 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 crtica 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, documentacin del sistema o en el cerebro de una persona que ha trabajado en la compaa durante los ltimos 20 aos)
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

An cuando algunas personas se encrespan con el trmino "usuarios" (quizs debido a que algunos administradores de sistemas utilizan el trmino de forma despectiva), aqu no se utiliza con esa con notacin. Los usuarios son aquellas personas que utilizan esos sistemas y recursos sobre los que usted tiene responsabilidad ni ms ni menos. Los usuarios son la clave en su habilidad de administrar exitsamente sus sistemas; sin entender a sus usuarios, cmo puede entender los recursos que estos requieren? Por ejemplo, considera un cajero de banco. Un cajero utiliza un conjunto de aplicaciones denidas 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 ms recursos de sistemas (para tiempos de compilacin/ejecucin ms rpidos). Dos usuarios completamente difer entes con necesidades completamente diferentes. Asegrese de aprender tanto como pueda de sus usuarios.
1.6. Conozca su negocio

Bien sea que trabaje para una corporacin multinacional o una comunidad pequea del colegio, tiene que entender la naturaleza del entorno del negocio en el que trabaja. Esto se puede reducir a una pregunta: Cul es el propsito de los sistemas que administra? El punto clave aqu es entender el propsito de sus sistemas en un sentido ms global:

Aplicaciones que se deben ejecutar en un perodo de tiempo particular, tal como al nal del mes, trimestre o ao
Captulo 1. Filosofa de la Administracin de Sistemas Los tiempos durante los que se ha efectuado mantenimientos al sistema Nuevas tecnologas que se podran utilizar para resolver viejos problemas de negocios
Al tomar en consideracin la organizacin 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 estn conectados a la Internet estn 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 debera considerar.

La naturaleza de las posibles amenazas a cada uno de los sistemas bajo su cuidado La ubicacin, 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 atacarn sus sistemas desde afuera de su compaa. Muchas veces el autor es alguien dentro de la compaa. As que la prxima vez que camine alrededor de la ocina, mire a la gente que lo rodea y hgase la siguiente pregunta: Qu pasara si esa persona intentara subvertir nuestra seguridad?
Nota Esto no signica que usted deba tratar a sus compaeros de trabajo como criminales. Simplemente signica 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 posicin, si tuviese esas inten ciones.
1.7.1. Los riesgos de Ingeniera Social

Mientras que la primera reaccin de los administradores de sistemas cuando piensan sobre seguridad, es concentrarse en los aspectos tecnolgicos, es importante mantener la perspectiva. Muy a menudo, las violaciones de seguridad no tienen sus orgenes en la tecnologa, 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 tecnolgicos. Esto se conoce como ingeniera 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 informacin de fondo se puede obtener desde el sitio web de la organizacin, en la pgina de "Equipo de Gerencia"). La persona que llama dice que est en algn lugar del mundo a mitad de camino (quizs esta parte de la historia es fabricada completamente o quizs en el sitio web de la organizacin, en la seccin de noticias, se menciona sobre el Director de Finanzas viajando a una exhibicin). La persona cuenta la historia de un infortunio; su porttil fue robada en el aeropuerto y ahora se encuentra con un cliente importante y necesita acceso a la intranet corporativa para vericar el estado de la cuenta del cliente. Ser el operador tan amable de darle la informacin de acceso necesaria?
Sabe usted qu har el operador? A menos que su operador tenga las pautas claras (en cuanto a las polticas y procedimientos), lo ms seguro es que no est seguro de lo que har. De la misma forma que los semforos, el objetivo de las polticas y procedimientos es el de propor cionar direcciones inequvocas sobre lo que es y no es el comportamiento apropiado. Sin embargo, as como los semforos, las polticas y procedimientos solamente funcionan si todos los siguen. Est adems el quid del problema es muy poco probable que todos se sometan a las polticas y proced imientos. De hecho, dependiendo de la naturaleza de su organizacin, es posible que ni siquiera tenga suciente autoridad para denir las polticas, mucho menos para hacerlas cumplir. Entonces ... qu hacer? Lamentablemente, no hay respuestas fciles para esto. La educacin para los usuarios puede ayudar; haga todo lo que pueda para poner a su comunidad al tanto de la seguridad y de la ingeniera social. Haga presentaciones durante la hora del almuerzo sobre seguridad. Publique enlaces a artculos rela cionados con la seguridad en la lista de correo de su organizacin. 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. Planique
Los administradores de sistemas que hayan seguido todos estos consejos y que hicieron lo posible por seguirlo sern excelentes administradores por un da. Eventualmente el entorno cambiar y un da nuestro fantstico administrador ser tomado por sorpresa. La razn? Nuestro fantstico admin istrador fall en planicar con tiempo. Por supuesto, nadie puede predecir el futuro con un 100% de delidad. Sin embargo, con un poco de consciencia es fcil leer las seales de muchos cambios:

Un comentario informal durante la aburrida reunin semanal de personal sobre el comienzo de un nuevo proyecto, es una seal segura de que en un futuro cercano tendr que apoyar a nuevos usuarios. Conversaciones sobre una inminente adquisicin signica que probablemente usted ser respons able de nuevos (y quizs incompatibles) sistemas en una o ms ubicaciones remotas
Tener la habilidad de leer estas seales (y de responder efectivamente a ellas) har su vida y la de sus usuarios ms fcil.
1.9. Espere lo inesperado

Mientras que la frase "espere lo inesperado" es trivial, reeja una verdad subyacente que todos los administradores de sistemas deben entender: Habr ocasiones en las que ser tomado por sorpresa. Despus de familiarizarse con esta incmoda realidad, qu puede hacer un administrador de sistemas preocupado? La respuesta recae en exibilidad; 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 insuciencia constante de espacio en disco parece ser una ley fsica tan seria como la Ley de Gravedad, es razonable asumir que en algn 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? Quizs sea posible mantener unas unidades adicionales en almacn como repuestos en caso de problemas de
hardware2 . Un repuesto de este tipo puede ser instalado rpidamente3 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 estndar para obtener unidades adicionales, por ejemplo). Si trata de anticipar los problemas antes de que estos ocurran, usted estar en una mejor posicin para responder rpida y efectivamente que si dejara las cosas para ser sorprendido cuando surja el momento.
1.10. Informacin especca a Red Hat Enterprise Linux

Esta seccin describe informacin relacionada a la losofa de la administracin de sistemas especca a Red Hat Enterprise Linux.
1.10.1. Automatizacin
La automatizacin de tareas realizadas frecuentemente bajo Red Hat Enterprise Linux requiere el conocimiento de diferentes tipos de tecnologas. Primero estn los comandos que controlan el tiempo de ejecucin de los scripts. Los comandos cron y at son los ms utilizados para estas funciones.
cron incorpora un sistema de especicacin de tiempos fcil de entender, exible y a la vez poderoso. cron puede planear la ejecucin de comandos o scripts en intervalos repetitivos que pueden variar en duracin desde minutos hasta meses. El comando crontab es utilizado para manipular los archivos que controlan el demonio cron que planica la ejecucin de cada trabajo cron.
El comando at (y el comando relacionado batch) son ms apropiados para planicar la ejecucin de comandos o scripts que slo se ejecutan una vez. Estos comandos implementan un subsistema rudimentario por lotes que consiste de mltiples colas con varias prioridades de planicacin. 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 crticas en trminos de cuando nalizar. Luego estn los diferentes lenguajes de scripting. Estos son los "lenguajes de programacin" 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 ms a menudo:

El intrprete 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 ms grande est en la forma en que estos lenguajes interactan con otros utilitarios en un sistema Red Hat Enterprise Linux. Los scripts escritos con el intrprete de comandos bash tienden a hacer un uso ms extensivo de muchos pequeos programas de utileras (por ejemplo, para realizar la manipulacin de cadenas de cracteres), mientras que los scripts perl realizan ms este tipo de operaciones usando funcional idades incorporadas en el lenguaje mismo. Un script escrito usando python puede explotar mejor las capacidades de orientacin a objetos del lenguaje, haciendo los scripts complejos extensible ms fcilmente. Esto signica que para manejar bien la programacin del shell, debe estar familiarizado con los mu chos programas de utileras (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
tecnologas relacionadas) para disminuir el impacto de la falla de un disco crtico durante produccin. 3. Una vez ms, los administradores de sistemas que piensan a futuro conguran sus sistemas de manera que sea fcil y rpido aadir un nuevo disco al sistema.
10
Por otro lado, aprender perl (y python), tiende a ser un proceso ms "autocontenido". Sin embargo, muchas construcciones de perl estn basadas en la sintxis de varios programas de utileras UNIX y como tales los administradores de sistemas Red Hat Enterprise Linux con experiencia en progra macin del shell estn familiarizados con ellos.
1.10.2. Documentacin y comunicacin

En las reas de comunicacin y documentacin, hay poco que sea especco a Red Hat Enterprise Linux. Puesto que la documentacin y comunicacin puede consistir de cualquier cosa desde aadir comentarios a un archivo de conguracin basado en texto hasta la actualizacin de una pgina web o el envo de correo electrnico, 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 pequea 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 aplicacin estrictamente grca (en otras palabras, requiere de un entorno X Window), mientras que vim y Emacs estn 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 funcin Composer del navegador web Mozilla. Por supuesto, algunos administradores de sistemas preeren codicar man ualmente su HTML, haciendo un editor de texto normal una herramienta perfectamente aceptable. Con respecto al correo electrnico, Red Hat Enterprise Linux incluye el cliente de correo grco Evolution, el cliente de correo Mozilla (que tambin es grco) y mutt, que est basado en texto. De la misma manera que con los editores de texto, la seleccin 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 captulo, la seguridad nunca puede ser una ocurrencia posterior y la seguridad bajo Red Hat Enterprise Linux es un poco ms profunda. La autenticacin y los controles de acceso estn profundamente integrados dentro del sistema operativo y estn basados en diseos recogidos a partir de la larga experiencia en la comunidad UNIX. Para la autenticacin, Red Hat Enterprise Linux utiliza PAM Pluggable Authentication Modules. PAM hace posible anar la autenticacin de usuarios a travs de la conguracin de bibliotecas com partidas que todas las aplicaciones compatibles con PAM utilizan, todo, sin requerir ningn cambio a las aplicaciones mismas. Los controles de acceso bajo Red Hat Enterprise Linux utilizan los permisos tradicionales tipo UNIX (lectura, escritura, ejecucin) para las clasicaciones usuario, grupo y "otros". Como UNIX, Red Hat Enterprise Linux tambin 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 crtico que cualquier programa que se ejecute con privilegios setuid o setgid debe ser auditado cuidadosamente para asegurarse de que no existan vulnerabilidades explotables.
11
Red Hat Enterprise Linux tambin incluye el soporte para las listas de control de acceso. Una lista de control de acceso (ACL) es una construcin que permite un control renado 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 dueo del archivo, sin embargo, la ACL del archivo se puede congurar 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 aplicacin. El registro es controlado por el demonio syslogd, el cual registra informacin del sistema localmente (normalmente a archivos en el directorio /var/log/) o a sistemas remotos (que acta como un servidor de registro dedicado para mltiples computadores). Los sistemas de deteccin 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 ms sistemas. El diseo 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 vericar si se han hecho cambios a los paquetes comprendidos dentro del sistema operativo. Sin embargo, debido a que RPM es fundamentalmente una herramienta de administracin de paquetes, sus habilidades como IDS son limitadas. An as, puede ser un buen primer paso hacia la supervisin de un sistema Red Hat Enterprise Linux para las modicaciones no autorizadas.
1.11. Recursos adicionales

Esta seccin incluye varios recursos que se pueden utilizar para aprender ms sobre la losofa de la administracin de sistemas y la materia especca a Red Hat Enterprise Linux discutidas en este captulo.
1.11.1. Documentacin instalada

Los recursos siguientes son instalados durante el curso normal de una instalacin tpica de Red Hat Enterprise Linux y lo pueden ayudar a aprender ms sobre la materia discutida en este captulo.

Las pginas man crontab(1) y crontab(5) Aprenda a planicar comandos y scripts para su ejecucin automtica a intervalos regulares. La pgina man de at(1) Aprenda a planicar la ejecucin posterior de comandos y scripts con esta utilidad. La pgina man de bash(1) Aprenda ms sobre el shell predeterminado y la programacin shell. La pgina man de perl(1) Revise apuntadores a las numerosas pginas man que conforman la documentacin en lnea de perl. La pgina man de python(1) Aprenda ms sobre las opciones, archivos y variables de entorno que controlan el interpretador de Python. La pgina man de gedit(1) y la entrada de men Help Aprenda cmo modicar archivos de texto con este editor grco de texto. La pgina man de bash(1) Aprenda ms sobre este exible editor de texto, incluyendo como ejecutar el tutorial en lnea. La pgina man de vim(1) Aprenda cmo utilizar este poderoso editor de texto. Las entrada de men Mozilla Help Contents Aprenda cmo editar archivos HTML, leer correo y navegar la web.
12
Captulo 1. Filosofa de la Administracin de Sistemas La pgina man de evolution(1) y la entrada de men Help Aprenda cmo manejar su correo con este cliente de correo grco. La pgina man de mutt(1) y los archivos en /usr/share/doc/mutt- version Aprenda cmo administrar su correo con este cliente de correo electrnico basado en texto. La pgina man de pam(8) y archivos en /usr/share/doc/pam- version Aprenda sobre el funcionamiento de la autenticacin bajo Red Hat Enterprise Linux.
1.11.2. Sitios web de utilidad

http://www.kernel.org/pub/linux/libs/pam/ La pgina principal del proyecto Linux-PAM. http://www.usenix.org/ La pgina principal de USENIX. Una organizacin profesional dedicada a reunir a los profesionales de computacin de todos los tipos y a fomentar la comunicacin e innovacin. http://www.sage.org/ El sitio web de System Administrators Guild (Gremio de Administradores de Sistemas). Un grupo tcnico 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 ms 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 pgina principal de RPM Package Manager. El sitio ms completo para aprender sobre RPM.
1.11.3. Libros relacionados

La mayora de los libros sobre administracin de sistemas hacen poco para cubrir la losofa detrs del trabajo. Sin embargo, los libros siguientes tienen secciones que dan un poco ms 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 scripcin general de las ubicaciones de archivos de sistema clave, conguraciones de usuarios y grupos y la conguracin de PAM. El Manual de seguridad de Red Hat Enterprise Linux; de Red Hat, Inc. Contiene una discusin completa de muchos problemas relacionados a la seguridad para los administradores de sistemas Red Hat Enterprise Linux. El Manual de administracin del sistema de Red Hat Enterprise Linux; de Red Hat, Inc. Incluye captulos para la administracin de usuarios y grupos, automatizacin de tareas y administracin de archivos de registro. El Linux Administration Handbook por Evi Nemeth, Garth Snyder y Trent R. Hein; Prentice Hall Proporciona una buena seccin sobre las pautas y polticas del lado de la administracin de sistemas, incluyendo muchas discusiones "que pasara si.." concernientes a ticas. El libro Linux System Administration: A Users Guide por Marcel Gagne; Addison Wesley Profes sional Contiene un buen captulo sobre la automatizacin de varias tareas. Solaris System Management por John Philcox; New Riders Publishing An cuando no est escrito especialmente para Red Hat Enterprise Linux (ni siquiera para Linux en general) y utiliza el trmino "gestor de sistemas" en vez de "administrador de sistemas," este libro proporciona una
13
descripcin general de 70 pginas sobre los muchos papeles que los administradores de sistemas juegan en una organizacin tpica.
14
Captulo 2.
Supervisin de recursos
Como se indic anteriormente, una gran parte de la administracin de sistemas gira alrededor de los recursos y su uso eciente. 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: Cmo saber cuales recursos estn siendo utilizados (y hasta que punto)? El propsito de este captulo es proporcionarle respuestas a estas preguntas ayudndole a conocer ms sobre los recursos y la manera de supervisarlos.
2.1. Conceptos bsicos

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 captulos 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 satisfaccin de sus usuarios. En su aspecto ms simple, monitorizar recursos no es ms que obtener informacin concerniente a la utilizacin de uno o ms 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 atencin a la situacin de cada sistema. Los sistemas que monitoriza recaen en dos categoras:

El sistema est actualmente experimentando problemas de rendimiento al menos parte del tiempo y a usted le gustara mejorar su rendimiento. El sistema est funcionando bien y le gustara que se mantenga de esa forma.
La primera categora indica que usted debera supervisar su sistema desde la perspectiva del rendimiento del sistema, mientras que la segunda categora signica que debe supervisar los recursos del sistema desde la perspectiva de planicacin de la capacidad del mismo. Debido a que cada perspectiva tiene sus requerimientos propios, las secciones siguientes exploran cada categora en mayor detalle.
16
Captulo 2. Supervisin 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 supervisin del rendimiento del sistema se realiza normalmente como el primer y el ltimo paso de un proceso de tres pasos: 1. Monitorizar para identicar la naturaleza y mbito de la escasez de recursos que estn causando los problemas de rendimiento 2. Se analizan los datos producidos a partir de la supervisin y se toma un curso de accin (nor malmente optimizacin del rendimiento o la adquisicin 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 duracin y ms 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 razn principal para esto es que los recursos del sistema y su utilizacin tienden a estar estrechamente relacionados, lo que signica que a menudo la eliminacin de un cuello de botella descubre otro ms.
2.3. Monitorizar la capacidad del sistema

La supervisin de la capacidad del sistema se hace como parte de un programa contnuo de plani cacin. La planicacin de capacidad utiliza el monitoreo a largo plazo de los recursos del sistema para determinar las tasas de cambio en la utilizacin de los recursos del sistema. Una vez que se cono cen estas tasas de cambio, se hace posible conducir una planicacin a largo plazo ms exacta con respecto a la adquisicin de recursos adicionales. Monitorizar para propsitos de planicacin de capacidad es diferente de monitorizar el rendimiento en dos formas:

Se monitoriza ms o menos de forma contnua Usualmente el monitoreo no es tan detallado
La razn de estas diferencias se generan de los objetivos del programa de planicacin de capacidades. La planicacin 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 inters. En vez de esto, se recopilan los datos sobre un perodo de tiempo, haciendo posible categorizar la utilizacin de recursos en trminos de los cambios en la carga de trabajo. En ambientes denidos de forma ms limitada (donde solamente corre una aplicacin, por ejemplo) es posible modelar el impacto de la aplicacin en los recursos del sistema. Esto se puede hacer con suciente exactitud para determinar, por ejemplo, el impacto de cinco representantes de servicio al cliente ejecutando la aplicacin de servicio al cliente durante la hora pico del da.
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, parecera que la supervisin slo consistira de examinar estas cuatro cosas. Lamentablemente, no es tan simple. Por ejemplo, considere una unidad de disco. Qu cosas podra querer saber sobre su utilizacin?

Cunto espacio libre est disponible? Cuntas operaciones de E/S realiza en promedio por segundo? Cunto tiempo en promedio toma en completarse cada operacin de E/S? Cuntas de esas operaciones de E/S son lecturas? Cuntas son escrituras? Cul es la cantidad promedio de datos ledos/escritos con cada E/S?
Hay ms formas de estudiar el rendimiento de una unidad de disco; estos puntos solamente tocan la supercie. 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 informacin de utilizacin que seran tiles para cada uno de los principales tipos de recursos.
2.4.1. Monitorizar el poder de CPU

En su forma ms bsica, monitorizar el poder de CPU signica determinar si la utilizacin del CPU alcanza alguna vez el 100%. Si la utilizacin del CPU se mantiene por debajo de 100%, sin importar lo que el sistema est haciendo, hay poder de procesamiento adicional para ms trabajo. Sin embargo, es raro que un sistema no alcance el 100% de utilizacin de CPU al menos una vez. En ese momento es importante examinar en ms detalle los datos de utilizacin de CPU. Haciendo esto, se hace posible comenzar a determinar donde se consume la mayora del poder de procesamiento. He aqu algunas de las estadsticas ms populares de utilizacin 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 estn ejecutando o a la sobrecarga del sistema operativo. Altos porcentajes de procesamiento a nivel de usuario tiende a ser bueno (asumiendo que los usuarios estn experi mentando un rendimiento satisfactorio), mientras que altos porcentajes de procesamiento a nivel de sistema tiende a apuntar hacia problemas que requeriran mayor investigacin. 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 operacin) o del software (tales como interrupciones de software que controlan el procesamiento de una aplicacin).
18 Procesos ejecutables
Un proceso puede tener diferentes estados. Por ejemplo, puede estar:

Esperando porque se termine una operacin de E/S Esperando porque el subsistema de administracin de memoria resuelva un fallo de pgina
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 ms de un proceso ejecutable en un momento determinado, todos excepto uno1 de los procesos deben esperar por su turno de CPU. Monitorizando el nmero de procesos ejecutables, es posible determinar cuan comprometido est el CPU en su sistema. Otras mtricas de rendimiento que reejan un impacto en la utilizacin del CPU tienden a incluir servi cios diferentes que el sistema operativo proporciona a los procesos. Estas pueden incluir estadsticas sobre la administracin de memoria, procesamiento de E/S, etc. Estas estadsticas tambin revelan que, cuando el rendimiento del sistema est siendo supervisado, no hay lmites entre las diferentes estadsticas. En otras palabras, las estadsticas de utilizacin de CPU pueden terminar apuntando a un problema en el subsistema de E/S, o las estadsticas de utilizacin de memoria pueden revelar un defecto de una aplicacin. Por lo tanto, cuando est supervisando el funcionamiento del sistema, no es posible examinar una estadstica de forma totalmente aislada; solamente mediante el exmen del cuadro completo es posible extraer informacin signicativa de cualquier estadstica de rendimiento que reuna.
2.4.2. Monitorizar el ancho de banda

Monitorizar el ancho de banda es ms complicado que la supervisin de otros recursos descritos aqu. La razn de esto se debe al hecho de que las estadsticas de rendimiento tienden a estar basadas en dispositivos, mientras que la mayora de los lugares en los que es importante el ancho de banda tienden a ser los buses que conectan dispositivos. En lo casos donde ms de un dispositivo comparte un bus comn, puede encontrar estadsticas 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 estadsticas para los dispositivos mismos no estn disponibles. Esto es particularmente verdadero para los buses de expansin del sistema y datapaths2 . Sin embargo, an cuando no siempre tendr disponibles estads ticas relacionadas al ancho de banda 100% exactas, a menudo se encuentra informacin suciente para hacer posible cierto nivel de anlisis, particularmente cuando se toman en cuenta estadsticas relacionadas. Algunas de las estadsticas ms comunes relacionadas al ancho de banda son: Bytes recibidos/enviados Las estadsticas de la interfaz de red proporcionan un indicativo de la utilizacin del ancho de banda de uno de los buses ms visibles la red. Cuentas y tasas de interfaz Estas estadsticas relacionadas a la red dan indicaciones de colisiones excesivas, errores de trans misin/recepcin y ms. Con el uso de estas estadsticas (particularmente si las estadsticas estn disponibles para ms de un sistema en su red), es posible realizar un fragmento de resolucin de problemas de la red antes de utilizar las herramientas de diagnstico de la red ms comunes.
1. 2. Asumiendo que se trata de un sistema con un nico procesador. Puede encontrar ms informacin sobre buses, datapaths y ancho de banda en el Captulo 3.
Captulo 2. Supervisin de recursos Transferencias por segundo
19
Normalmente reunida por dispositivos de E/S en bloques, tales como discos y unidades de cinta de alto rendimiento, esta estadstica es una buena forma de determinar si se est alcanzando el lmite del ancho de banda de un dispositivo particular. Debido a su naturaleza electromecnica, las unidades de disco y de cinta solamente pueden realizar ciertas operaciones de E/S cada se gundo; su rendimiento se ve afectado rpidamente a medida que se alcanza a este lmite.
2.4.3. Monitorizar la memoria

Si existe un rea en la que se puede encontrar gran cantidad de estadsticas de rendimiento, esta rea es la utilizacin de la memoria. Debido a la complejidad inherente de los sistemas operativos con memoria virtual bajo demanda de hoy da, las estadsticas de utilizacin de memoria son muchas y variadas. Es aqu donde tiene lugar la mayora del trabajo de un administrador de sistemas con la administracin de recursos. Las estadsticas siguientes representan una descripcin precipitada de las estadsticas de adminis tracin de memoria encontradas ms a menudo: Pginas dentro/fuera Estas estadsticas hacen posible medir el ujo de pginas desde la memoria del sistema a los dispositivos de almacenamiento masivo (usualmente unidades de disco). Altas tasas de estas estadsticas pueden representar que el sistema est corto de memoria fsica y que est haciendo thrashing o consumiendo ms recursos del sistema en mover las pginas dentro y fuera de memo ria que en ejecutando aplicaciones. Pginas activas/inactivas Estas estaditicas muestran qu tanto se estn utilizando las pginas residentes en memoria. Una falta de pginas inactivas puede estar apuntando hacia una escasez de memoria fsica. Pginas libres, compartidas, en memoria intermedia o en cach Estas estadsticas proporcionan detalles adicionales sobre las estadsticas ms simples de pginas activas/inactivas. Usando estas estadsticas es posible determinar la mezcla general de utilizacin de memoria. Intercambio dentro/fuera Estas estadsticas muestran el comportamiento general de la memoria de intercambio del sistema. Tasas excesivas pueden estar apuntando a una escasez de memoria fsica. La supervisin exitosa de la utilizacin de la memoria requiere una buena comprensin de cmo funciona la memoria virtual bajo demanda de un sistema operativo. Mientras que esta materia puede tomar un libro completo, los conceptos bsicos se discuten en el Captulo 4. Este captulo junto con tiempo invertido en monitorizar el sistema, le da los bloques de construccin necesarios para aprender ms sobre este tpico.
2.4.4. Monitorizar el almacenamiento

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

Monitorizar insuciente espacio en disco Monitorizar problemas de rendimiento relacionados con el almacenamiento
La razn de esto es que es posible tener problemas calamitosos en un rea y ningn problema en otra. Por ejemplo, es posible causar que a la unidad de disco se le acabe el espacio sin causar ningn tipo de
20
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 ms all de sus lmites en trminos de rendimiento. Sin embargo, es ms 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 mayora de las veces este tipo de interaccin toma la forma de funcionamientos de E/S ms y ms 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 estadsticas siguientes son tiles para supervisar el almacenamiento: Espacio libre El espacio libre es probablemente el recurso que todos los administradores de sistemas vigilan ms de cerca; sera raro el administrador que no verica el espacio disponible (o que tiene una forma de hacerlo automticamente). Estadsticas relacionadas al sistema de archivos Estas estadsticas (tales como el nmero de archivos/directorios, tamao promedio de los archivos, etc.) suministran detalles adicionales sobre un porcentaje de espacio libre. Como tal, estas estadsticas hacen posible para los administradores de sistemas congurar el sistema para que entregue el mejor rendimiento, pues la carga de E/S impuesta por un sistema de archivos lleno de muchos pequeos archivos no es la misma que la carga impuesta por un sistema de archivos lleno con un nico archivo enorme. Transferencias por segundo Esta estadstica es una buena forma de determinar si se estn alcanzando las limitaciones de ancho de banda de un dispositivo en particular. Lecturas/escrituras por segundo Con un desglose ms detallado de las transferencias por segundo, estas estadsticas 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 crtico, ya que algunas tecnologas de almacenamiento tienen caractersticas 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 ms de las que aqu se listan, estas herramientas son representativas en trminos de funcionalidad. Las herramientas son:
free top
(y el Monitor del Sistema de GNOME, una versin de top ms orientada a lo grco)
vmstat
La suite de herramientas de supervisin de recursos de Sysstat El perlador global del sistema OProle
Examinemos cada una con ms detalles.
21
2.5.1. free
El comando free muestra la utilizacin de la memoria del sistema. He aqu un ejemplo de esta salida:
total Mem: 255508 -/+ buffers/cache: Swap: 530136 used 240268 146488 26268 free 15240 109020 503868 shared 0 buffers 7592 cached 86188
La la Mem: muestra la utilizacin de la memoria fsica, mientras que la la Swap: muestra la uti lizacin del espacio de intercambio (swap) del sistema. La la -/+ buffers/cache: muestra la cantidad de memoria actualmente dedicada a las memorias intermedias del sistema (buffers). Puesto que por defecto free solamente muestra la utilizacin de memoria una vez, solamente es til para una supervisin de corto tiempo, o para determinar rpidamente si un problema relacionado con la memoria est en progreso actualmente. Aunque free tiene la habilidad de mostrar repetidamente los nmeros de utilizacin de memoria a travs de su opcin -s, la salida se desplaza, haciendo difcil detectar cambios en la utilizacin de memoria.
Sugerencia Una mejor solucin que utilizar free -s, sera ejecutar el comando free usando el comando watch. Por ejemplo, para mostrar la utilizacin 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 ubicacin de pantalla. Esto hace mucho ms fcil determinar cmo cambia la utilizacin de memoria con el tiempo, pues no es necesario escanear contnuamente desplazando la salida. Puede controlar el retraso entre actualizaciones usando la opcin -n y causar que cualquier cambio entre actualizaciones sea resaltado usando la opcin -d, como en el comando siguiente:
watch -n 1 -d free
Para ms informacin, consulte la pgina 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 informacin relacionada con la memoria, el comando top hace un poquito de todo. Utilizacin del CPU, estadsticas de procesos, utilizacin de memoria top lo monitoriza todo. Adems, a diferencia de free command, el comportamiento predeterminado de top es el de ejecutarse de forma contnua, 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
22
Swap: 1020116k av, PID 17578 19154 1 2 3 4 5 6 9 7 8 10 11 USER root root root root root root root root root root root root root PRI 15 20 15 RT RT 15 34 35 15 15 15 15 25
5276k used, 1014840k free NI SIZE RSS SHARE STAT %CPU %MEM 0 13456 13M 9020 S 18.5 1.3 0 1176 1176 892 R 0.9 0.1 0 168 160 108 S 0.0 0.0 0 0 0 0 SW 0.0 0.0 0 0 0 0 SW 0.0 0.0 0 0 0 0 SW 0.0 0.0 19 0 0 0 SWN 0.0 0.0 19 0 0 0 SWN 0.0 0.0 0 0 0 0 SW 0.0 0.0 0 0 0 0 SW 0.0 0.0 0 0 0 0 SW 0.0 0.0 0 0 0 0 SW 0.0 0.0 0 0 0 0 SW 0.0 0.0
382228k cached TIME CPU COMMAND 26:35 1 rhn-applet-gu 0:00 1 top 0:09 0 init 0:00 0 migration/0 0:00 1 migration/1 0:00 0 keventd 0:00 0 ksoftirqd/0 0:00 1 ksoftirqd/1 0:07 1 bdflush 1:19 0 kswapd 0:14 1 kscand 0:03 1 kupdated 0:00 0 mdrecoveryd
La pantalla se divide en dos secciones. La parte superior contiene informacin relacionada con el esta tus general del sistema tiempo ejecutndose, carga promedio, cuentas de procesos, estado del CPU y estadsticas de utilizacin para la memoria y el espacio de intercambio. La seccin de abajo muestra estadsticas 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 estn ociosos, presione [i]; otro toque lo retorna al modo de visualizacin predeterminado.
Atencin An cuando top pareciera como un simple programa de visualizacin, este no es el caso. Esto es porque top utiliza comandos de carcteres 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 ms seguro solamente pulsar [q] (sale de top).
2.5.2.1. La aplicacin Monitor del Sistema GNOME Un top grco Si se siente ms a gusto con las interfaces grcas de usuarios, la aplicacin Monitor del Sistema GNOME puede ser ms de su agrado. De la misma forma que top, el Monitor del Sistema GNOME muestra informacin relacionada al estado general del sistema, cuentas de procesos, utilizacin de memoria y de swap y estadsticas a nivel de procesos. Sin embargo, el Monitor del Sistema GNOME va un paso ms all incluyendo tambin representa ciones grcas del CPU, utilizacin de memoria y de intercambio, junto con un listado tabular de la utilizacin del espacio en disco. Un ejemplo del Listado de procesos del Monitor del Sistema GNOME aparece en la Figura 2-1.
23
Figura 2-1. La pantalla Listado de procesos del Monitor del sistema Se puede mostrar informacin adicional sobre un proceso especco pulsando primero en el proceso deseado y luego pulsando en el botn Ms Info. Para mostrar las estadsticas de uso de memoria, CPU y uso del disco, pulse la pestaa Monitor del sistema.
2.5.3. vmstat
Para una comprensin ms 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 lnea de nmeros:
procs r b 0 0 memory swpd free buff cache 5276 315000 130744 380184 si 1 swap so 1 bi 2 io bo 24 in 14 system cpu cs us sy id wa 50 1 1 47 0
La primera lnea divide los campos en seis categoras, incluyendo procesos, memoria, swap, E/S, sistema y estadsticas relacionadas al CPU. La segunda lnea identica an ms los contenidos de cada campo, haciendo ms fcil escanear datos para ver estadsticas especcas. Los campos relacionados a procesos son:
r b
El nmero de procesos ejecutables esperando para acceder al CPU El nmero de procesos en un estado dormido contnuo
Los campos relacionados a la memoria son:
24 La cantidad de memoria utilizada La cantidad de memoria libre
swpd free buff
La cantidad de memoria utilizada por las memorias intermedias La cantidad de memoria utilizada como cach de pginas
cache
Los campos relacionados a swap son:

si so
La cantidad de memoria intercambiada desde el disco La cantidad de memoria intercambiada hacia el disco
Los campos relacionados con E/S son:

bi bo
Los bloques enviados a un dispositivo de bloques Los bloques recibidos desde un dispositivo de bloques
Los campos relacionados al sistema son:

in cs
El nmero de interrupciones por segundo El nmero de cambios de contexto por segundo
Los campos relacionados al CPU son:

us sy id wa
El porcentaje de tiempo que el CPU ejecut cdigo de nivel del usuario El porcentaje de tiempo que el CPU ejecut cdigo de nivel del sistema El porcentaje de tiempo que el CPU estaba desocupado Esperas de E/S
Cuando se ejecuta vmstat sin opciones, solamente se muestra una lnea. Esta lnea contiene prome dios, calculados desde la ltima vez que se arranc el sistema. Sin embargo, la mayora de los administradores de sistemas no confan en los datos en esta lnea, pues los tiempos en que fueron recopilados varan. En su lugar, la mayora de los administradores tomas ventaja de la habilidad de vmstat de mostrar repetidamente datos de la utilizacin de recursos en intervalos establecidos. Por ejemplo, el comando vmstat 1 muestra una nueva lnea de utilizacin de datos cada segundo, mientras que el comando vmstat 1 10, muestra una nueva lnea por segundo, pero slo por los prximos 10 segundos. En manos de un administrador experimentado, vmstat puede ser usado para determinar rpidamente la utilizacin 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 perodos muy cortos, son de poca utilidad en proporcionar ms all de una instantnea de la utilizacin de recursos del sistema. Adems, hay aspectos del rendimiento del sistema que no se pueden monitorizar fcilmente usando tales herramientas tan simplsticas. Por lo tanto, se requiere una herramienta ms sosticada. Sysstat es la herramienta. Sysstat contiene las siguientes herramientas relacionadas con reunir estadsticas de E/S y CPU:
25
iostat
Muestra una descripcin general de la utilizacin del CPU, junto con las estadsticas de E/S para uno o ms unidades de disco.
mpstat
Muestra estadsticas de CPU ms complejas. Sysstat tambin contiene herramientas para reunir datos de utilizacin 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 informacin sobre la utilizacin 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 anlisis ms intensivo. Las secciones siguientes exploran cada una de estas herramientas con ms detalles. 2.5.4.1. El comando iostat El comando iostat en su forma ms bsica proporciona una descripcin general de las estadsticas del CPU y E/S de disco:
Linux 2.4.20-1.1931.2.231.2.10.ent (pigdog.example.com) avg-cpu: %user 6.11 %nice 2.56 tps 1.68 %sys 2.15 %idle 89.18 Blk_wrtn/s 22.42 Blk_read 31175836 Blk_wrtn 44543290 07/11/2003
Device: dev3-0
Blk_read/s 15.69
Debajo de la primera lnea (la cual contiene la versin del kernel del sistema y el nombre del host, junto con la fecha actual), iostat muestra una vista general de la utilizacin promedio del CPU desde el ltimo arranque. El informe de utilizacin 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 planicacin usando nice(2)) Porcentaje de tiempo en modo kernel Porcentaje de tiempo ocioso
Debajo del informe de utilizacin del CPU est el informe de utilizacin de dispositivos. Este informe contiene una lnea para cada dispositivo en el sistema e incluye la informacin siguiente:

La especicacin de dispositivos, mostrada como dev major-number -sequence-number , donde major-number es el nmero principal ("major") del dispositivo3 y sequence-number es un nmero secuencial comenzando desde cero. El nmero de transferencias (u operaciones de E/S) por segundo.
Los nmeros "major" de dispositivos se pueden encontrar usando ls -l para mostrar el archivo de disposi
3.
tivo deseado en /dev/. El nmero major aparece despus de la especicacin del grupo del dispositivo.
26 El nmero de bloques de 512 bytes ledos por segundo. El nmero de bloques de 512 bytes escritos por segundo. El nmero total de bloques de 512 bytes ledos. El nmero total de bloques de 512 bytes escritos.
Esto es solamente un muestra de la informacin que se puede obtener usando iostat. Para ms informacin, consulte la pgina man de iostat(1). 2.5.4.2. El comando mpstat El comando mpstat aparece primero sin diferencias con el informe de utilizacin de CPU producido por iostat:
Linux 2.4.20-1.1931.2.231.2.10.ent (pigdog.example.com) 07:09:26 PM 07:09:26 PM CPU all %user 6.40 %nice %system 5.84 3.29 %idle 84.47 intr/s 542.47 07/11/2003
Con la excepcin de una columna adicional mostrando las interrupciones por segundo manejadas por el CPU, no hay diferencia real. Sin embargo, la situacin cambia si se utiliza la opcin de mpstat, -P ALL.
Linux 2.4.20-1.1931.2.231.2.10.ent (pigdog.example.com) 07:13:03 07:13:03 07:13:03 07:13:03 PM PM PM PM CPU all 0 1 %user 6.40 6.36 6.43 %nice %system 5.84 3.29 5.80 3.29 5.87 3.29 %idle 84.47 84.54 84.40 intr/s 542.47 542.47 542.47 07/11/2003
En sistemas multiproceso, mpstat permite desplegar de forma individual la utilizacin 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 utilizacin del sistema y los escribe a un archivo para su anlisis 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 dgitos.
sadc normalmente es ejecutado por el script sa1. cron invoca peridicamente este script a travs 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, aadiendo 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 utilizacin del sistema basado en los datos reunidos por sadc. De acuerdo a la conguracin en Red Hat Enterprise Linux, sar es ejecutado automticamente para procesar los archivos reunidos automticamente por sadc. Los archivos de informes se escriben a /var/log/sa/ y son nombrados sar dd , donde dd son las representaciones de dos dgitos de la fecha del da anterior.
27
Normalmente, sar es ejecutado por el script sa2. Peridicamente cron invoca este script a travs del archivo sysstat, el cual se ubica en /etc/cron.d/. Por defecto, cron ejecuta a sa2 una vez al da, a las 23:53, permitiendo as producir un informe para los datos del da completo. 2.5.4.4.1. Lectura de informes sar El formato de un informe sar generado por la conguracin predeterminada de Red Hat Enterprise Linux consiste de mltiples secciones, con cada seccin conteniendo un tipo de datos especco, ordenados por hora del da en que los datos fueron reunidos. Puesto que sadc est congurado 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 seccin del informe comienza con un encabezado describiendo los datos contenidos en la sec cin. El encabezado se repite a intervalos regulares a lo largo de la seccin, haciendo ms fcil in terpretar los datos mientras se hojea el informe. Cada seccin termina con una lnea conteniendo el promedio de datos informados en la seccin. He aqu una seccin de ejemplo de un informe sar, con los datos desde 00:30 hasta 23:40 eliminados para ahorrar espacio:
00:00:01 00:10:00 00:20:01 ...
23:50:01 Average: CPU all all all all %user 6.39 1.61 44.07 5.80 %nice 1.96 3.16 0.02 4.99 %system 0.66 1.09 0.77 2.87 %idle
90.98
94.14
55.14
86.34
En esta seccin, se muestra la informacin de utilizacin del CPU. Esto es muy similar a los datos mostrados por iostat. Otras secciones pueden tener ms de una lnea necesaria para datos, como se muestra en esta seccin generada a partir de los datos de utilizacin del CPU en un sistema con dos procesadores:
00:00:01 00:10:00 00:10:00 00:20:01 00:20:01 ...
23:50:01 23:50:01 Average: Average: CPU 0 1 0 1 0 1 0 1 %user 4.19 8.59 1.87 1.35 42.84 45.29 6.00 5.61 %nice 1.75 2.18 3.21 3.12 0.03 0.01 5.01 4.97 %system 0.70 0.63 1.14 1.04 0.80 0.74 2.74 2.99 %idle
93.37
88.60
93.78
94.49
56.33
53.95
86.25
86.43
Hay un total de diecisiete secciones diferentes presente en los reportes generados por la conguracin predeterminada de Red Hat Enterprise Linux para sar; se exploran algunas en los siguientes captulos. Para ms informacin sobre los datos contenidos en cada seccin, consulte la pgina 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.
28
2.5.5. OProle
El perlador global del sistema OProle, es una herramienta de supervisin con poca sobrecarga. Oprole aprovecha el hardware de monitorizacin del rendimiento del procesador 5 para determinar la naturaleza de los problemas relacionados al rendimiento. El hardware de monitorizacin 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 ms de uno de tales contadores y permiten la seleccin de tipos diferentes para cada contador. Los contadores se pueden cargar con un valor inicial y producir una interrupcin cuando se desborde el contador. Al cargar el contador con valores iniciales diferentes, es posible variar las tasas en las que ocurre la interrupcin. 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 interrupcin por desborde con cada evento, proporciona datos de rendimiento en extremo detalle (pero con una sobrecarga excesiva). En el otro extremo, al congurar el contador para que genere tan pocas interrupciones como sea posible solamente proporciona la vista ms general del rendimiento del sistema (practicamente sin ninguna sobrecarga). El secreto para una monitorizacin efectiva es la seleccin de una tasa de muestra lo sucientemente alta como para capturar los datos requeridos, pero no tan alta como para sobrecargar el sistema con la monitorizacin.
Atencin Puede congurar OProle 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 razn, el comando opcontrol soporta la opcin --list-events, el cual despliega los diferentes tipos de eventos disponibles para el procesador instalado actualmente, junto con los valores de contador mnimos sugeridos para cada uno.
Es importante tener en mente el costo de la relacin entre la tasa de muestra y la sobrecarga cuando se utiliza OProle. 2.5.5.1. Componentes de OProle OProle consiste de los siguientes componentes:

Software de recoleccin de datos Software de anlisis de datos Software de interfaz administrativa
El software de coleccin de datos consiste del mdulo del kernel oprofile.o y el demonio oprofiled. El software de anlisis de datos incluye los programas siguientes:
op_time
Muestra el nmero y los porcentajes relativos de las muestras tomadas por cada archivo eje cutable
5. OProle tambin puede utilizar un mecanismo de fallback (conocido como TIMER_INT) para aquellas arquitecturas que no tienen el hardware de monitorizacin de rendimiento.
29
oprofpp
Muestra el nmero y el porcentaje relativo de muestras tomadas por funcin, instruccin individ ual o en salida estilo gprof.
op_to_source
Muestra cdigo fuente anotado y o listados de acumulacin

op_visualise
Presenta los datos reunidos de forma grca Estos programas hacen posible mostrar los datos reunidos en diferentes formas. El software de interfaz administrativa controla todos los aspectos de la coleccin de datos, desde especicar cuales eventos especcos sern monitorizados hasta arrancar y detener la coleccin de datos mismos. Esto se hace usando el comando opcontrol. 2.5.5.2. Un ejemplo de sesin de OProle Esta seccin muestra una sesin de OProle supervisando y analizando datos desde la conguracin inicial hasta el anlisis nal de los datos. Es solamente un visin general introductoria; para informa cin ms detallada, consulte el Manual de administracin del sistema de Red Hat Enterprise Linux. Utilice opcontrol para congurar 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 OProle a una copia del (--vmlinux=/boot/vmlinux-uname -r)
kernel
ejecutndose
actualmente
Especicar 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) Especicar que OProle va a reunir muestras cada 6000th veces que el evento ocurra (--ctr0-count=6000)
Luego, verique que el mdulo del kernel oprofile est cargado usando el comando lsmod:
Module oprofile ...
Size 75616 Used by 1
Not tainted
Conrme que el sistema de archivos de OProle (ubicado en /dev/oprofile/) est montado con el comando ls /dev/oprofile/:
0 1 buffer buffer_size buffer_watershed cpu_buffer_size cpu_type dump enable kernel_only stats
(El nmero exacto de archivos vara de acuerdo al tipo de procesador.) En este punto, el archivo /root/.oprofile/daemonrc contiene los parmetros requeridos por el software de recoleccin de datos:
CTR_EVENT[0]=CPU_CLK_UNHALTED CTR_COUNT[0]=6000
30
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 recoleccin de datos con el comando opcontrol --start:
Using log file /var/lib/oprofile/oprofiled.log
Daemon started.
Profiler running.
Verique que el demonio oprofiled est ejecutndose con el comando ps x | grep -i oprofiled:
32019 ? 32021 pts/0 S S 0:00 /usr/bin/oprofiled --separate-lib-samples=0 ... 0:00 grep -i oprofiled
(La lnea de comandos real de oprofiled mostrada por ps es mucho ms larga; sin embargo, la hemos truncado para propsitos 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 convencin de nombres un poco inusual. He aqu un ejemplo:
}usr}bin}less#0
La convencin de nombres utiliza la ruta absoluta de cada archivo conteniendo cdigo ejecutable, reemplazando los carcteres de barra oblcua (/) por llaves (}), y terminndose con una almohadilla (#) seguido de un nmero (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 anlisis de datos para desple garlos. Una de las buenas funcionalidades de OProle es que no es necesario detener la recoleccin de datos antes de efectuar el anlisis 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 nmero ms alto de muestras hasta el ms bajo) las muestras que se han reunido:
3321080 761776 368933 293570 205231 167575 123095 105677 ...
48.8021 11.1940 5.4213 4.3139 3.0158 2.4625 1.8088 1.5529 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 /boot/vmlinux-2.4.21-1.1931.2.349.2.2.entsmp
/usr/bin/oprofiled
/lib/tls/libc-2.3.2.so
/usr/lib/libgobject-2.0.so.0.200.2
/usr/lib/libgdk-x11-2.0.so.0.200.2
/usr/lib/libglib-2.0.so.0.200.2
/lib/libcrypto.so.0.9.7a
/usr/X11R6/bin/XFree86
31
Es una buena idea el uso de less cuando se genera un informe interactivamente, ya que los informes pueden ser de cientos de lneas. El ejemplo dado aqu se ha truncado por este motivo. El formato para este informe en particular es que se produce una lnea para cada archivo ejecutable para los que se tomaron muestras. Cada lnea sigue el formato siguiente:
sample-count
sample-percent
unused-field
executable-name
Donde:

sample-count
representa el nmero de muestras reunidas
en particular.
sample-percent unused-field
representa el porcentaje de todas las muestras reunidas para este ejecutable
es un campo que no se utiliza
executable-name representa el nombre del archivo que contiene el cdigo del ejecutable para el que se reunen las muestras.
Este reporte (producido en la mayora de los sistemas ociosos) muestra que casi la mitad de todas las muestras fueron tomadas mientras que el CPU estaba ejecutando cdigo dentro del kernel mismo. Luego en la lnea estaba el demonio de coleccin de datos de OProle, 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 sesin de muestra, el valor del contador usado de 6000 representa el valor mnimo recomendado por opcontrol --list-events. Esto signica que al menos para este sistema en particular la sobrecarga de OProle en su punto ms alto, consume aproximadamente 11% del CPU.

Esta seccin incluye varios recursos que se pueden utilizar para aprender ms sobre monitorizar re cursos y la materia especca a Red Hat Enterprise Linux discutida en este captulo.

Los recursos siguientes son instalados en el curso normal de una instalacin tpica de Red Hat Enter prise Linux.

La pgina man de free(1) Aprenda a mostrar estadsticas de la memoria libre y utilizada. La pgina man de top(1) Aprenda cmo mostrar la utilizacin del CPU y las estadsticas a nivel de procesos. La pgina man de watch(1) Conozca cmo ejecutar peridicamente el programa especicado, mostrando la salida en la pantalla completa. La entrada del men Ayuda del Monitor del sistema GNOME Conozca cmo mostrar grca mente estadsticas de procesos, CPU, memoria y de utilizacin de espacio en disco. La pgina man de vmstat(8) Aprenda a desplegar una visin general concisa de los procesos y la utilizacin de memoria, swap, E/S y CPU. La pgina man de iostat(1) Aprenda a mostrar estadsticas del CPU y E/S. La pgina man de mpstat(1) Vea cmo se pueden mostrar estadsticas individuales de CPU en sistemas multiprocesos. La pgina man de sadc(8) Conozca cmo reunir datos de la utilizacin del sistema.
32
Captulo 2. Supervisin de recursos La pgina man de sa1(8) Aprenda sobre este script que ejecuta peridicamente sadc. La pgina man de sar(1) Vea como se pueden producir informes de utilizacin de recursos del sistema. La pgina man de sa2(8) Aprenda a crear archivos de informes diarios de la utilizacin de recursos del sistema. La pgina man de nice(1) Aprenda a cambiar la prioridad de planicacin de los procesos. La pgina man de oprofile(1) Vea como se perla el rendimiento del sistema. La pgina man de op_visualise(1) Conozca cmo presentar grcamente datos de OProle.
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 optimizacin del rendimiento y supervisin de recursos para servidores. http://www.linuxjournal.com/article.php?sid=2396 Performance Monitoring Tools for Linux. Esta pgina del Linux Journal est enfocada hacia el administrador interesado en escribir una solu cin grca personalizada de rendimiento. Escrita hace varios aos atrs, algunos de los detalles quizs ya no se apliquen, pero el concepto general y la ejecucin estn bien fundadas. http://oprole.sourceforge.net/ El sitio web del proyecto OProle. Incluye recursos valiosos de OProle, incluyendo apuntadores a las listas de correo y al canal #oprole IRC.

Los libros siguientes discuten varios tpicos relacionados con la monitorizacin de recursos y son buenas fuentes para los administradores de sistemas Red Hat Enterprise Linux.

El Manual de administracin del sistema de Red Hat Enterprise Linux; de Red Hat, Inc. Incluye informacin sobre muchas de las herramientas de supervisin descritas aqu, incluyendo OProle. Linux Performance Tuning and Capacity Planning por Jason R. Fink y Matthew D. Sherer; Sams Proporciona descripciones ms profundas de las herramientas de supervisin presentadas aqu incluyendo otras que pueden ser apropiadas para necesidades de supervisin de recursos ms es peccas. Red Hat Linux Security and Optimization por Mohammed J. Kabir; Red Hat Press Aproxi madamente las primeras 150 pginas de este libro discuten problemas relacionados al rendimiento. Esto incluye captulos dedicados a los problemas de rendimiento especcos a la red, Web, correo electrnico y servidores de archivos. Linux Administration Handbook por Evi Nemeth, Garth Snyder y Trent R. Hein; Prentice Hall Proporciona un captulo corto similar en mbito al de este libro, pero incluye una seccin interesante sobre el diagnstico de un sistema que se vuelve lento repentinamente. Linux System Administration: A Users Guide por Marcel Gagne; Addison Wesley Professional Contiene un pequeo captulo sobre la supervisin del rendimiento y optimizacin.
Captulo 3.
Ancho de banda y poder de procesamiento
De los dos recursos discutidos en este captulo, uno (el ancho de banda) es a menudo difcil de entender para los nuevos administradores de sistemas, mientras que el otro concepto (poder de procesamiento), es usualmente mucho ms fcil de comprender. Adicionalmente, puede parecer que estos dos recursos no estn muy relacionados por qu agru parlos? La razn para referirse a estos dos recursos juntos es porque estn basados en el hardware que se une directamente con la habilidad del computador de mover y procesar datos. Como tal, su relacin a menudo est interrelacionada.
3.1. Ancho de banda

En su forma ms 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 comunicacin de datos de punto a punto implica dos cosas:

Un conjunto de conductores elctricos utilizados para hacer posible la comunicacin a bajo nivel Un protocolo para facilitar la comunicacin de datos conable y eciente
Hay dos tipos de componentes de sistemas que satisfacen estos requerimientos:

Buses Datapaths
Las secciones siguientes exploran cada uno de estos en ms detalles.
3.1.1. Buses
Como se mencion anteriormente, los buses permiten la comunicacin de punto a punto y utilizan algn tipo de protocolo para asegurarse de que toda la comunicacin toma lugar de forma controlada. Sin embargo, los buses tienen otras caractersticas distintivas:

Caractersticas elctricas estandarizadas (tales como el nmero de conductores, niveles de voltage, velocidades de seales, etc.) Caractersticas mecnicas estandarizadas (tales como el tipo de conector, tamao de la tarjeta, for mato fsico, etc.) Protocolo estndar
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 interconexin del hardware hecho por diferentes fabricantes; sin estandarizacin, esto no sera posible. Sin embargo, an en situaciones donde un bus es propiedad de un fabricante, la estandarizacin es importante porque permite a ese fabricante implementar ms fcilmente diferentes componentes usando una interfaz comn el bus mismo.
34 3.1.1.1. Ejemplos de buses
Captulo 3. Ancho de banda y poder de procesamiento
No importa dnde en el computador usted revise, habr buses. He aqu algunos de los ms comunes:

Buses de almacenamiento masivo (ATA y SCSI) Redes1 (Ethernet y Token Ring) Los buses de memoria (PC133 y Rambus) Buses de expansin (PCI, ISA, USB)
3.1.2. Datapaths
Los datapaths pueden ser ms difciles de identicar pero, como los buses, estn en todas partes. Tambin a igual que los buses, los datapaths permiten la comunicacin punto a punto. Sin embargo, a diferencia de los buses, los datapaths:

Utilizan un protocolo ms simple (si es que lo utilizan) Tienen poca (o ninguna) estandarizacin mecnica
La razn de estas diferencias es que los datapaths son normalmente internos a algunos componentes de sistemas y no son usados para facilitar la interconexin ad-hoc de componentes diferentes. Como tal, los datapaths son muy optimizados para una situacin particular, donde la velocidad y el bajo costo se preeren sobre una exibilidad ms lenta y ms costosa de propsito general. 3.1.2.1. Ejemplos de Datapaths He aqu algunos datapaths tpicos:

Datapath de CPU a cach en chip Datapath de procesador grco a memoria de vdeo
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 situacin, 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 seran 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 nal es que toda la E/S a cualquiera de estos dispositivos en el bus es lenta, an si cada dispositivo en el bus no est demasiado activo. 2. El bus o datapath puede ser un recurso dedicado con un nmero jo de dispositivos conectados a l. En este caso, las caractersticas elctricas del bus (y hasta cierto punto la naturaleza del protocolo utilizado) limitan el ancho de banda disponible. Usualmente, este es ms el caso con datapaths que con buses. Esta es una de las razones por las que los adaptadores grcos tienden a funcionar ms 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.
35
por cada refrescado de pantalla, hay ms datos que transmitir a travs del datapath que conecta la memoria de vdeo al procesador grco.
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 ms uniformemente la actividad del bus. En otras palabras, si un bus est sobrecargado y otro est ocioso, quizs la situacin sera mejorada moviendo algo de la carga hasta el bus ocioso. Como administrador del sistema, este es el primer enfoque que debera considerar, pues a menudo existen buses adicionales ya instalados en su sistema. Por ejemplo, la mayora 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 deberan estar ambas unidades en el mismo canal? An si su conguracin no incluye buses adicionales, distribuir la carga puede ser todava el mejor enfoque. Los gastos de hardware en hacer esto sern 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. Despus de todo, cuando uno distribuye la carga, tambin 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 algn 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? Quizs un pequeo archivo temporal es el recipiente de grandes lecturas/escrituras de E/S. Si ese archivo temporal reside en un servidor de la red, se podra eliminar una gran parte del trco de la red trabajando con el archivo localmente. 3.1.4.3. Incrementar la capacidad La solucin obvia a un ancho de banda insuciente, es el de incrementarlo de alguna manera. Sin embargo, esto es usualmente una proposicin 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 ms rpido. Si el controlador SCSI es una tarjeta separada, esto sera un proceso bien directo, pero si el controlador es parte de la tarjeta madre del sistema, se vuelve mucho ms difcil justicar econmicamente este cambio.
36
3.1.5. En resumen. . .
Todos los administradores de sistemas deberan estar conscientes del ancho de banda y de cmo la conguracin 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, an 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 vara con la arquitectura (y la velocidad del reloj) del CPU usualmente los CPUs con velocidades del reloj ms lentas y aquellos soportando tamaos de palabras ms grandes tienen ms poder de procesamiento que los CPUs ms lentos que soportan tamaos de palabras ms pequeos.
3.2.1. Hechos sobre el poder de procesamiento

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

El poder de procesamiento es jo El poder de procesamiento no se puede almacenar
El poder de procesamiento es jo, en el sentido de que el CPU solamente puede ir a cierta velocidad. Por ejemplo, si necesita sumar dos nmeros (una operacin que toma solamente una instruccin de mquina en la mayora 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 tambin es jo en otro sentido: es nito. Esto es, hay lmites 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 quizs no se puedan actualizar para nada2. El poder de procesamiento no se puede almacenar para usarse ms 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 ja. Si el CPU "produce" instrucciones ejecutadas, esto signica que otra cosa debe "consumir" las mismas. La prxima seccin dene a estos consumidores.
3.2.2. Consumidores de poder de procesamiento

He aqu los dos principales consumidores de poder de procesamiento:
Aplicaciones
Esta situacin lleva a que se llame de forma jocosa actualizacin con carretilla, lo que signica un reemplazo
2.
completo de un computador.
Captulo 3. Ancho de banda y poder de procesamiento El sistema operativo mismo
37
3.2.2.1. Aplicaciones Los consumidores ms obvios de poder de procesamiento son las aplicaciones y los programas que usted desea que el computador ejecute por usted. Desde una hoja de clculo hasta una base de datos, las aplicaciones son la razn por las que usted tiene un computador. Un nico CPU puede solamente ejecutar una cosa en un momento dado. Por lo tanto, si su aplicacin se est ejecutando, el resto de las cosas en el sistema no. Lo contrario, por supuesto, tambin es cierto si algo diferente a su aplicacin se est ejecutando, entonces su aplicacin 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 ilusin de que muchas estn sucediendo simultneamente cuando en realidad es que esto no es posible. El truco es darle a cada proceso una fraccin de segundo de ejecucin en el CPU antes de darle el CPU a otro proceso para la prxima fraccin de segundo. Si estos switches de contexto ocurren con la frecuencia necesaria, se logra la ilusin de que mltiples aplicaciones se ejecutan simultneamente. Por supuesto, las aplicaciones hacen otras cosas que manipular datos usando el CPU. Pueden tambin esperar por entradas del usuario as como tambin realizar E/S a dispositivos tales como discos duros y visualizaciones grcas. Cuando ocurren estos eventos, la aplicacin ya no necesita el CPU. En estos momentos, el CPU se puede utilizar para otros procesos ejecutando aplicaciones sin hacer ms lento la aplicacin en espera. Adems, el CPU puede ser utilizado por otro consumidor de poder de procesamiento: el sistema operativo mismo. 3.2.2.2. El Sistema Operativo Es difcil determinar cuanto poder de procesamiento consume el sistema operativo. La razn de esto es que el sistema operativo utiliza una mezcla de cdigo a nivel de procesos y a nivel del sistema para realizar su trabajo. Mientras que, por ejemplo, es fcil utilizar un supervisor de procesos para determinar qu est haciendo un proceso ejecutando un demonio o servicio, no es tan fcil determinar cunto 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 planicacin de procesos y administracin 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 suciente poder de procesamiento para la carga de trabajo, tiene dos opciones:

Reducir la carga Incrementar la capacidad
38 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 identicar 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 planicacin frecuente de procesos Reducir la cantidad de E/S realizada
No espere milagros, en un sistema razonablemente bien congurado, 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 congurado, por denicin, resulta en una cantidad de sobrecarga mnima. Sin embargo, si su sistema est ejecutndose con poca RAM, por ejemplo, quizs 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 signica asegurarse de que la aplicacin tiene todo lo que necesita para ejecutarse bien. Algunas aplicaciones presentan comportamientos diferentes bajo am bientes diferentes una aplicacin puede volverse muy comprometida en trminos de computacin 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 ejecutndose en su sistema si es que quiere que se ejecuten lo ms ecientemente 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 ms ecientemente. 3.2.3.1.3. Eliminar aplicaciones completas Dependiendo de su organizacin, 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 identicar cualquier aplicacin conocida como "CPU hogs", quizs pueda inuenciar para eliminarlas. Hacer esto quizs implicar ms de una persona. Los usuarios afectados denitivamente deben ser parte de este proceso; en muchos casos pueden tener el conocimiento y el poder poltico para llevar a cabo los cambios necesarios en las aplicaciones disponibles.
Sugerencia Tenga en mente que una aplicacin puede que no requiera ser eliminada de todos los sistemas de su organizacin. Probablemente pueda mover una aplicacin hambrienta de CPU desde un sistema sobrecargado a otro sistema que est prcticamente ocioso.
Captulo 3. Ancho de banda y poder de procesamiento 3.2.3.2. Incrementar la capacidad
39
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 ms 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 porttiles) tienen CPUs que estn soldados en un lugar, haciendo imposible una actualizacin. El resto, sin embargo, tienen CPUs en bancos, lo que hace posible su actualizacin al menos en teora. Luego, debe investigar para determinar si existe un CPU ms rpido para la conguracin 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 actualizacin. Finalmente, debe determinar la velocidad mxima del CPU soportada por su sistema. Continuando con el ejemplo anterior, an si existe un CPU de 2GHz del mismo tipo, un intercambio simple de CPU no es una opcin si su sistema solamente soporta procesadores ejecutndose a 1GHz o menos. Si encuentra que no puede instalar un CPU ms rpido en su sistema, sus opciones pueden estar limitadas a cambiar las tarjeta madre o hasta una actualizacin ms costosa como la de tipo carretilla mencionada anteriormente. Sin embargo, algunas conguraciones de sistemas permiten un enfoque ligeramente diferente. En vez de reemplazar el CPU existente, por que no aadir otro? 3.2.3.2.2. Es el multiprocesamiento simtrico adecuado para Usted? El multiprocesamiento simtrico (tambin conocido como SMP) hace posible que un sistema com putacional tenga ms de un CPU compartiendo todos los recursos del sistema. Esto signica, que a diferencia de un sistema uniprocesador, un sistema SMP puede en realidad tener ms de un procesador ejecutndose al mismo tiempo. A primera vista, pareciera el sueo de un administrador de sistemas. Primero que nada, SMP hace posible incrementar el poder de procesamiento de un CPU an si no esta disponible un CPU con velocidades de reloj ms rpidas simplemente aadiendo otro CPU. Sin embargo, esta exibilidad 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 diseada para soportar multiprocesamiento. Si no lo tiene, se necesitar (al menos) una actualizacin de la tarjeta madre. La segunda advertencia es que SMP incrementa la sobrecarga del sistema. Esto tiene sentido si lo piensa un poco; con ms CPUs para los cuales planicar trabajo, el sistema operativo requiere ms ciclos de CPU para la sobrecarga. Otro aspecto de esto es que con mltiples CPUs, puede haber ms competencia por los recursos del sistema. Debido a estos factores, la actualizacin de un sistema de procesadores dual a un sistema con cuatro procesadores, no signica 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 adicin de otro procesador podra ms 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 cacin monoltica con una sola corriente de ejecucin. En otras palabras, si un programa grande, vin culado computacionalmente, se ejecuta como un nico proceso sin hilos, no se ejecutar ms rpido en un sistema SMP que en una mquina de un slo procesador. De hecho, se podra ejecutar an ms 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 opcin. Esto proporciona el mximo de poder de CPU con las menores restricciones sobre su uso.
40
Mientras que esta discusin pareciera indicar que SMP nunca es una buena idea, hay circunstancias en las que tiene sentido. Por ejemplo, los entornos ejecutando mltiples aplicaciones con gran demanda computacional son buenas candidatas para SMP. La razn de esto es que las aplicaciones que no hacen nada pero computar por largos perodos de tiempo mantienen la contienda entre los procesos activos (y por lo tanto, la sobrecarga del sistema operativo) a un mnimo, 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 ms 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 mquina con mltiples procesadores.

La monitorizacin del ancho de banda y de la utilizacin del CPU bajo Red Hat Enterprise Linux implica utilizar las herramientas discutidas en el Captulo 2; por lo tanto, si an no ha ledo ese captulo, 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 Seccin 2.4.2, es difcil monitorizar directamente la utilizacin del ancho de banda. Sin embargo, examinando las estadsticas a nivel de dispositivos, es posible medir a grandes rasgos si la insuciencia 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; adems, revisando los campos si y so le dar un poco ms de conocimiento sobre cunta actividad de disco se debe a E/S relacionada a swap.
r 1 procs b w 0 0 memory swpd free buff cache 0 248088 158636 480804 si 0 swap so 0 bi 2 io bo 6 in 120 system cs 120 us 10 sy 3 cpu id 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 ledo 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 ms de detalles sobre la actividad relacionada al disco:
Linux 2.4.21-1.1931.2.349.2.2.entsmp (raptor.example.com) avg-cpu: %user 5.34 %nice 4.60 tps 1.10 0.00 %sys 2.83 %idle 87.24 Blk_wrtn/s 25.08 0.00 Blk_read 961342 16 Blk_wrtn 3881610 0 07/21/2003
Device: dev8-0 dev8-1
Blk_read/s 6.21 0.00
Esta salida nos muestra que el dispositivo con un nmero major de 8 (el cual es /dev/sda, el primer disco SCSI) tiene un promedio un poco mayor de una operacin de E/S por segundo (el campo tsp). La mayora de la actividad de E/S para este dispositivo fueron escrituras (el campo Blk_wrtn), con un poco ms de 25 bloques escritos cada segundo (el campo Blk_wrtn/s).
Captulo 3. Ancho de banda y poder de procesamiento Si se necesitan ms detalles, utilice la opcin -x de iostat:
Linux 2.4.21-1.1931.2.349.2.2.entsmp (raptor.example.com) avg-cpu: %user 5.37 %nice 4.54 %sys 2.81 r/s 0.36 0.00 0.00 0.29 0.04 %idle 87.27 w/s 0.77 0.00 0.00 0.62 0.15 rsec/s 32.20 0.34 0.00 4.74 1.06 wsec/s 29.05 0.00 0.00 21.80 7.24 rkB/s 16.10 0.17 0.00 2.37 0.53 wkB/s avgrq-sz 14.53 54.52 0.00 133.40 0.00 11.56 10.90 29.42 3.62 43.01 07/21/2003
41
Device: /dev/sda /dev/sda1 /dev/sda2 /dev/sda3 /dev/sda4
rrqm/s wrqm/s 13.57 2.86 0.17 0.00 0.00 0.00 0.31 2.11 0.09 0.75
Ms all de las largas lneas conteniendo ms campos, la primera cosa a tener en mente es que esta salida de iostat est mostrando ahora estadsticas a un nivel de particin. Usando df para asociar los puntos de montaje con los nombres de dispositivos, es posible utilizar este informe para determinar si, por ejemplo, la particin conteniendo /home/ est experimentando una sobrecarga excesiva. En realidad, cada lnea de salida de iostat -x es ms larga y contiene ms informacin que esto; he aqu el resto de cada lnea (agregando la columna del dispositivo para facilitar la lectura):
Device: /dev/sda /dev/sda1 /dev/sda2 /dev/sda3 /dev/sda4 avgqu-sz 0.24 0.00 0.00 0.12 0.11 await svctm 20.86 3.80 141.18 122.73 6.00 6.00 12.84 2.68 57.47 8.94 %util 0.43 0.03 0.00 0.24 0.17
En este ejemplo, es interesante observar que /dev/sda2 es la particin swap del sistema; obviamente, a partir de los muchos campos de esta particinque leen 0.00, el swapping no es un problema en el sistema. Otro punto interesante a tomar en cuenta es /dev/sda1. Las estadsticas para esta particin son inusuales; la actividad general parece baja, pero por qu el tamao 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 ms grandes que en las otras particiones? La respuesta es que esta particin 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 nmeros 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 estadsticas de E/S; por ejemplo, sar -b muestra un informe general de E/S:
Linux 2.4.21-1.1931.2.349.2.2.entsmp (raptor.example.com) 12:00:00 12:10:00 12:20:01 ...
06:00:02 Average: AM AM AM PM tps 0.51 0.48 1.24 1.11 rtps 0.01 0.00 0.00 0.31 wtps 0.50 0.48 1.24 0.80 bread/s 0.25 0.00 0.01 68.14 bwrtn/s
14.32
13.32
36.23
34.79
07/21/2003
Aqu, como en la pantalla inicial de iostat, las estadsticas son agrupadas para todos los dispositivos de bloque.
42
Usando sar -d se produce otro informe relacionado a E/S:

Linux 2.4.21-1.1931.2.349.2.2.entsmp (raptor.example.com) 12:00:00 12:10:00 12:10:00 12:20:01 12:20:01 ...
06:00:02 06:00:02 Average: Average: AM AM AM AM AM PM PM DEV dev8-0 dev8-1 dev8-0 dev8-1 dev8-0 dev8-1 dev8-0 dev8-1 tps 0.51 0.00 0.48 0.00 1.24 0.00 1.11 0.00 sect/s
14.57
0.00
13.32
0.00
36.25
0.00
102.93
0.00
07/21/2003
Este informe proporciona informacin por dispositivo, pero con pocos detalles. Mientras que no hay estadsticas explcitas mostrando la utilizacin del ancho de banda para un bus o datapath dado, al menos podemos determinar qu estn haciendo los dispositivos y utilizar su actividad para determinar indirectamente la carga del bus.
3.3.2. Monitorizar la utilizacin del CPU en Red Hat Enterprise Linux

A diferencia del ancho de banda, la supervisin de la utilizacin del CPU es mucho ms directa. Desde un porcentage de utilizacin de CPU en el Monitor del sistema GNOME, hasta las estadsticas ms detalladas informadas por sar, es posible determinar de forma veraz cunto poder de CPU est siendo utilizado y en qu. Ms all del Monitor del sistema GNOME, top es la primera herramienta de supervisin de recursos discutida en el Captulo 2 para proporcionar una representacin ms profunda de la utilizacin de CPU. A continuacin se muestra un informe con top de una estacin 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 30997 1120 1260 888 1264 1 2 3 4 5 6 7 8 9 10 USER ed root ed root ed root root root root root root root root root root PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 16 0 1100 1100 840 R 1.7 0.0 0:00 top 5 -10 249M 174M 71508 S < 0.9 13.8 254:59 X 15 0 54408 53M 6864 S 0.7 4.2 12:09 gnome-terminal 15 0 2428 2428 1796 S 0.1 0.1 0:06 sendmail 15 0 16336 15M 9480 S 0.1 1.2 1:58 rhn-applet-gui 15 0 476 476 424 S 0.0 0.0 0:05 init 0K 0 0 0 0 SW 0.0 0.0 0:00 migration_CPU0 0K 0 0 0 0 SW 0.0 0.0 0:00 migration_CPU1 15 0 0 0 0 SW 0.0 0.0 0:01 keventd 34 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU0 34 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU1 15 0 0 0 0 SW 0.0 0.0 0:05 kswapd 15 0 0 0 0 SW 0.0 0.0 0:00 bdflush 15 0 0 0 0 SW 0.0 0.0 0:01 kupdated 25 0 0 0 0 SW 0.0 0.0 0:00 mdrecoveryd
La primera informacin relacionada con el CPU se presenta en la primera lnea: la carga promedio. La carga promedio es un nmero correspondiente al nmero promedio de procesos ejecutables en el
43
sistema. La carga promedio es a menudo listada como tres conjuntos de nmeros (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 lnea siguiente, aunque no est relacionada estrictamente a la utilizacin del CPU, tiene una relacin indirecta, en que muestra el nmero de procesos ejecutables (aqu, solamente uno -- recuerde este nmero, pues signica algo especial en este ejemplo). El nmero de procesos ejecutables es un buen indicador de cuan comprometido computacionalmente puede estar un sistema. Luego estan dos lneas mostrando la utilizacin actual para cada uno de los dos CPUs en el sistema. Las estadsticas de utilizacin se desglosan para mostrar si los ciclos de CPU gastados se hicieron para procesamiento a nivel de usuario o a nivel del sistema; tambin est incluido una estadstica que muestra cuanto tiempo de CPU se gast por procesos con prioridades de planicacin alteradas. Finalmente, hay una estadstica de tiempo ocioso. Desplazandose ms abajo en la seccin 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 estadsticas de utilizacin de recursos que usted recibe. Todos los monitorizadores basados en software hasta cierto punto hacen esto.
Para obtener ms conocimiento detallado sobre la utilizacin del CPU, debemos cambiar herramien tas. Si examinanos la salida desde vmstat, obtenemos un entendimiento ligeramente diferente de nuestro sistema ejemplo:
r 1 0 0 0 0 0 0 0 0 0 procs b w 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 swpd 0 0 0 0 0 0 0 0 0 0 free 233276 233276 233276 233276 233276 233276 233276 233276 233276 233276 buff 146636 146636 146636 146636 146636 146636 146636 146636 146636 146636 memory cache 469808 469808 469808 469808 469808 469808 469808 469808 469808 469808 si 0 0 0 0 0 0 0 0 0 0 swap so 0 0 0 0 0 0 0 0 0 0 bi 7 0 0 0 0 0 0 0 0 0 io bo 7 0 0 0 0 32 0 0 0 0 in 14 523 557 544 517 518 516 516 516 516 system cs 27 138 385 343 89 102 91 72 88 81 us 10 3 2 2 2 2 2 2 2 2 sy 3 0 1 0 0 0 1 0 0 0 cpu id 87 96 97 97 98 98 98 98 97 97
Aqu hemos utilizado el comando vmstat 1 10 para tomar muestras del sistema cada segundo diez veces. Primero, las estadsticas relacionadas al CPU (los campos us, sy, y id) parecen similares a lo que mostraba top, y quizs hasta aparece un poco menos detallado. Sin embargo, a diferencia de top, tambin podemos obtener un poco ms de informacin en cmo 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 ms, esto es un sistema ocioso. Revisando las herramientas que Sysstat ofrece, encontramos que iostat y mpstat proporcionan poca informacin adicional sobre lo que ya hemos experimentado con top y vmstat. Sin embargo, sar produce un nmero de informes que son de ayuda cuando se supervisa la utilizacin del CPU.
44
El primer informe se obtiene por el comando sar -q, el cual muestra el largo de la cola de ejecucin, nmero 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) 12:00:01 12:10:00 12:20:01 ...
09:50:00 Average: AM AM AM AM runq-sz 3 5 5 4 plist-sz 122 123 124 123 ldavg-1 0.07 0.00 0.67 0.26 ldavg-5
0.28
0.03
0.65
0.26
07/21/2003
En este ejemplo, el sistema siempre est ocupado (dado que siempre hay ms de un proceso eje cutable), pero no est sobrecargado (puesto que este sistema particular tiene ms de un procesador). El prximo informe sar relacionado con el CPU lo produce el comando sar -u:
10:00:00 Average: AM AM AM AM CPU all all all all %user 3.69 1.73 35.17 7.47 %nice 20.10 0.22 0.83 4.85 %system 1.06 0.80 1.06 3.87 %idle
75.15
97.25
62.93
83.81
07/21/2003
Las estadsticas contenidas en este informe no son diferentes de aquellas generadas por muchas otras herramientas. El principal benecio aqu es que sar hace los datos disponibles de forma contnua y es por tanto ms til para obtener datos sobre promedios de largos tiempos, o para la produccin de grcos de utilizacin de CPU. En sistemas multiproceso, el comando sar -U puede producir estadsticas para un procesador indi vidual o para todos los procesos. He aqu un ejemplo de la salida desde sar -U ALL:
Linux 2.4.21-1.1931.2.349.2.2.entsmp (falcon.example.com) 12:00:01 12:10:00 12:10:00 12:20:01 12:20:01 ...
10:00:00 10:00:00 Average: Average: AM AM AM AM AM AM AM CPU 0 1 0 1 0 1 0 1 %user 3.46 3.91 1.63 1.82 39.12 31.22 7.61 7.33 %nice 21.47 18.73 0.25 0.20 0.75 0.92 4.91 4.78 %system 1.09 1.03 0.78 0.81 1.04 1.09 3.86 3.88 %idle
73.98
76.33
97.34
97.17
59.09
66.77
83.61
84.02
07/21/2003
El comando sar -w informa sobre el nmero de switches de contexto por segundo, haciendo posible ganar conocimiento adicional sobre dnde se gastan los ciclos de CPU:
10:10:00 AM AM AM AM cswch/s
537.97
339.43
319.42
07/21/2003
45
Average:
1158.25
Tambin es posible generar dos informes sar diferentes en actividad interrumpida. El primero, (gen erado usando el comando sar -I SUM) muestra una estadstica simple de "interrupciones por se gundo":
10:40:01 Average: AM AM AM AM INTR sum sum sum sum intr/s
539.15
539.49
539.10
541.00
07/21/2003
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) 12:00:00 AM 12:10:01 AM 12:10:01 12:20:01 ... 10:30:01 10:40:02 Average: AM AM AM AM CPU 0 CPU 0 CPU 0 0 i000/s 512.01 i000/s 512.00 i000/s 512.00 512.00 i001/s 0.00 i001/s 0.00 i001/s 1.67 0.42 i002/s 0.00 i002/s 0.00 i002/s 0.00 0.00 i008/s 0.00 i008/s 0.00 i003/s 0.00 N/A i009/s 3.44 i009/s 3.73 i008/s 0.00 0.00 07/21/2003 i011/s 0.00 i011/s 0.00 i009/s 15.08 6.03 i012/s 0.00 i012/s 0.00 i010/s 0.00 N/A
Este informe (el cual se ha truncado horizontalmente para ajustarse a la pgina) incluye una columna por cada nivel de interrupcin (por ejemplo, el campo i002/s ilustrando las tasas para nivel de interrupcin 2). Si este fuese un sistema multiprocesador, habra una lnea por perodo de muestra para cada CPU. Otro pundo importante a tomar en cuenta es que sar aade o elimina campos de interrupcin espec cos si no se reunen datos para ese campo. El informe de ejemplo de arriba suministra un ejemplo de esto, el nal del informe incluye los niveles de interrupcin (3 y 10) que no estaban presentes al principio del perodo de muestras.
Nota Existen otros dos informes sar relacionados a interrupciones sar -I ALL y sar -I XALL. Sin embargo, la conguracin predeterminada para la utilidad de recoleccin de datos sadc no re une la informacin necesaria para estos informes. Esto se puede cambiar modicando el archivo /etc/cron.d/sysstat, y cambiando esta lnea:
*/10 * * * * root /usr/lib/sa/sa1 1 1
a esto:
*/10 * * * * root /usr/lib/sa/sa1 -I 1 1
46

Tenga en mente que este cambio ocasiona que se reuna informacin adicional por sadc y resulta en tamaos de archivos ms grandes. Por lo tanto, asegrese de que la conguracin de su sistema pueda soportar el consumo de espacio adicional.

Esta seccin incluye varios recursos que se pueden utilizar para aprender ms sobre la materia espec ca a Red Hat Enterprise Linux discutida en este captulo.

Los recursos siguientes se instalan durante una instalacin tpica de Red Hat Enterprise Linux y lo pueden ayudar a aprender un poco ms sobre la materia discutida en este captulo.

La pgina man de vmstat(8) Aprenda a mostrar una vista concisa de la utilizacin de procesos, memoria, swap, E/S, sistema y CPU. La pgina man de iostat(1) Le ensea cmo mostrar estadsticas de CPU y E/S. La pgina man de sar(1) Aprenda a producir informes de utilizacin de recursos del sistema. La pgina man de sadc(8) Aprenda a reunir datos de utilizacin del sistema. La pgina man de sa1(8) Conozca este script que ejecuta peridicamente sadc. La pgina man de top(1) Conozca cmo mostrar estadsticas de utilizacin 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 optimizacin del rendimiento y supervisin de recursos para servidores. http://www.linuxjournal.com/article.php?sid=2396 Performance Monitoring Tools for Linux. Esta pgina del Linux Journal est enfocada hacia el administrador interesado en escribir una solu cin grca personalizada de rendimiento. Escrita hace varios aos atrs, algunos de los detalles quizs ya no se apliquen, pero el concepto general y la ejecucin estn bien fundadas.

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

El Manual de administracin del sistema de Red Hat Enterprise Linux de Red Hat, Inc. Incluye un captulo sobre muchas de las herramientas de supervisin de recursos discutidas aqu. Linux Performance Tuning and Capacity Planning por Jason R. Fink and Matthew D. Sherer; Sams Proporciona descripciones ms profundas de las herramientas de supervisin presentadas aqu incluyendo otras que pueden ser apropiadas para necesidades de supervisin de recursos ms es peccas.
47
Linux Administration Handbook por Evi Nemeth, Garth Snyder y Trent R. Hein; Prentice Hall Proporciona un captulo corto similar en mbito al de este libro, pero incluye una seccin interesante sobre el diagnstico de un sistema que se vuelve lento repentinamente. Linux System Administration: A Users Guide por Marcel Gagne; Addison Wesley Professional Contiene un pequeo captulo sobre la supervisin del rendimiento y optimizacin.
48
Captulo 4.
Memoria fsica y virtual
Todas las computadoras de propsito general de hoy da, 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 construccin de programas) en algn tipo de almacenamiento interno, donde son subsecuentemente ejecutadas. Las computadoras de programas almacenados tambin utilizan el mismo almacenamiento para los datos. Esto es en contraste con las computadoras que utilizan su conguracin de hardware para con trolar sus operaciones (tales como las computadoras ms antiguas basadas en la conexin de tarjetas). El lugar donde los programas eran almacenados en las primeras computadoras de programas almace nados se llam de varias formas y utiliz tecnologas diferentes, desde manchas en un tubo de rayos catdicos, hasta pulsos de presin en columnas de mercurio. Afortunadamente, los computadores de hoy en da utilizan tecnologas con mayores capacidades de almacenamiento y de menor tamao que antes.
4.1. Patrones de acceso a almacenamiento

Una cosa a recordar a lo largo de este captulo es que los computadores tienden a acceder al almace namiento en formas particulares. De hecho, la mayora 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 signica que, si el CPU accede a la direccin N , es muy probable que la direccin N +1 sea la prxima a acceder. Esto tiene sentido, ya que muchos programas consisten de grandes secciones de instrucciones que ejecutan en orden una instruccin tras la otra. El acceso localizado signica que, si se accede a la direccin X , es muy probable que otras direcciones alrededor de X tambin sern accedidas en el futuro. Estos atributos son cruciales, debido a que permite que unidades de almacenamiento pequea y ms rpida, coloque efectivamente en memoria temporal almacenamiento ms grande y lento. Esto es lo bsico para implementar la memoria virtual. Pero antes de que discutamos la memoria virtual, debemos examinar las diferentes tecnologas de almacenamiento usadas actualmente.
4.2. El espectro de almacenamiento

Las computadoras de hoy utilizan una variedad de tecnologas de almacenamiento. Cada tecnologa est orientada hacia una funcin especca, con velocidades y capacidades en combinacin. Estas tecnologas son:

Registros de CPU Memoria cach RAM Discos duros Almacenamiento fuera de lnea para respaldos (cintas, discos pticos, etc.)
50
Captulo 4. Memoria fsica y virtual
En trminos de capacidades y costos, estas tecnologas forman un espectro. Por ejemplo, los registros de CPU son:

Muy rpidos (tiempos de acceso de unos pocos nanosegundos) Baja capacidad (usualmente menos de 200 bytes) Capacidades de expansin muy limitadas (se requiere un cambio en la arquitectura del CPU) Costosas (ms de un dlar/byte)
Sin embargo, en el otro lado del espectro, el almacenamiento fuera de lnea es:

Muy lento (tiempos de acceso se miden en das, si la media de respaldo debe ser entregada sobre largas distancias) Capacidad muy alta (10s - 100s de gigabytes) Capacidades de expansin prcticamente ilimitadas (solamente limitadas por el espacio fsico re querido para hospedar la media de respaldo) Bajo costo (fracciones de cntimos/byte)
Usando diferentes tecnologas con diferentes capacidades, es posible anar el diseo del sistema para un mximo rendimiento al costo ms bajo posible. Las secciones siguientes exploran cada tecnologa en el espectro del almacenamiento.
4.2.1. Registros de CPU

Todos los diseos de CPU de hoy da incluyen registros para una variedad de propsitos, desde el almacenamiento de direcciones de la instruccin recientemente ejecutada, hasta propsitos ms gen erales de almacenamiento y manipulacin de datos. Los registros de CPU se ejecutan a la misma velocidad que el resto del CPU; de lo contrario habra un cuello de botella grave sobre el rendimiento completo del sistema. La razn para esto es que casi todas las operaciones realizadas por el CPU envuelven registros de una forma u otra. El nmero de registros de CPU (y sus usos) dependen estrictamente en el diseo arquitectnico del CPU mismo. No hay forma de cambiar el nmero de registros de CPU, solamente puede migrar a un CPU con una arquitectura diferente. Por estas razones, el nmero de registros de CPU se puede considerar como una constante, ya que slo pueden cambiarse con mucho dolor y grandes costos.
4.2.2. Memoria cach

El propsito 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 ms grande y lento usual mente conocido como RAM1. La memoria cach tiene una velocidad de operacin 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 congurada de forma tal que, cuando se leen datos desde la RAM, el sistema de hardware verica primero para determinar si los datos deseados estn en cach. Si los datos estn en cach, estos son recuperados rpidamente y utilizados por el CPU. Sin embargo, si los datos no estn en cach, estos se leen desde la RAM y, mientras se transeren al CPU, tambin se colocan en cach (en caso de que se necesiten ms tarde). Desde la perspectiva del CPU, todo esto se hace de forma
1. Mientras que "RAM" es un acrnimo para "Random Access Memory," y un trmino que podra ser fcil
mente aplicable a cualquier tecnologa de almacenamiento que permita el acceso no secuencial de los datos almacenados, cuando los administradores de sistemas hablan sobre RAM invariablemente se reeren al sistema de memoria principal.
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 trminos de la capacidad de almacenamiento, la cach es mucho ms pequea que la RAM. Por lo tanto, no todos los bytes en la RAM tienen su ubicacin 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. Anque existe una diferencia en tamao entre la cach y la RAM, dada la naturaleza secuencial y localizada del acceso a almacenamiento, una pequea 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 propsito de la cach es funcionar como una copia muy rpida de los contenidos de porciones seleccionadas de RAM, cada vez que una porcin 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 coincidiran. Los dos enfoques se diferencian en cmo se logra hacer esto. En un enfoque, conocido como write through caching, los datos modicados se escriben inmediatamente a la RAM. Sin embargo, en el write-back caching, se retrasa la escritura de los datos modicados a la RAM. La razn para hacer esto es la de reducir el nmero de veces que una porcin de datos modicada frecuentemente debe ser escrita nuevamente a la RAM. La cach "write-through" o inmediata es un poco ms simple de implementar; por esta razn es la ms comn. La cach "write-back" es un poco ms complicada; adems de almacenar los datos, es necesario mantener cierto tipo de mecanismo que sea capaz de noticar que los datos en cach estn al da o "limpios" (los datos en cach son los mismos que los datos en RAM), o que estn "sucios" (los datos en cach han sido modicados, lo que signica que los datos en RAM ya no estn actualizados). Tambin es necesario implementar una forma de vaciar peridicamente entradas "sucias" en cach de vuelta en RAM. 4.2.2.1. Niveles de cach Los subsistemas de cach en los diseos de computadoras de hoy da pueden ser de niveles mltiples; esto es, puede haber ms de un conjunto de cach entre el CPU y la memoria principal. Los niveles de cach a menudo estn enumerados, con los nmeros menores ms 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 mdulo de CPU, se ejecuta a las mismas velocidades que el CPU (o casi) y normalmente es un poco ms grande y lenta que la cach L1
Algunos sistemas (normalmente servidores de alto rendimiento) tambin tienen cach L3, que usual mente forma parte del sistema de la tarjeta madre. Como puede imaginarse, la cach L3 es ms grande (y casi con seguridad ms lenta) que la cach L2. En cualquier caso, el objetivo del todos los subsistemas de cach bien sean simples o de mltiples niveles es el de reducir el tiempo de acceso promedio a la RAM.
4.2.3. Memoria principal RAM

La RAM resuelve la mayora del almacenamiento electrnico en las computadoras de hoy en da. La RAM es utilizada tanto para almacenar datos como para almacenar los programas en uso. La velocidad de la RAM en la mayora de los sistemas actuales est entre la velocidad de la memoria cach y la de los discos duros y est mucho ms cercana a la velocidad de la primera que a la segunda.
52
La operacin bsica de la RAM es en realidad bien sencilla. En el nivel ms bajo, estn los chips de RAM circuitos integrados que "recuerdan". Estos chips tienen cuatro tipos de conexiones con el mundo externo:

Conexiones de energa (para operar la circuitera 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 sern ledos/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 direccin en la que los datos se almacenaran se presenta a las conexiones de direccin. 3. La conexin de lectura/escritura se coloca en modo de escritura. La recuperacin de datos es tambin muy directa: 1. La direccin de los datos deseados se presenta a las conexiones de direcciones. 2. La conexin de lectura/escritura es colocada a modo de lectura. 3. Los datos deseados son ledos 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 da se venden como mdulos. Cada mdulo consiste de un nmero individual de chips de RAM conectados a una pequea tarjeta de circuitos. La distribu cin mecnica y elctrica del mdulo sigue los estndares de la industria, haciendo posible la compra de memorias desde diferentes fabricantes.
Nota El benecio principal de un sistema utilizando mdulos RAM basados en estndares de la industria, es que tienden a mantener bajos los costos de las RAM, debido a la posibilidad de adquirir mdulos a partir de diferentes fabricantes. Aunque la mayora de las computadoras utilizan mdulos de RAM basados en estndares de la industria, existen algunas excepciones. Las ms notables de estas excepciones son porttiles (e in clusive aqu se comienza a ver un poco ms de estandarizacin) y servidores de punta. Sin embargo, an en estos ejemplos, es muy probable que estn disponibles mdulos de terceros, asumiendo que el sistema sea relativamente popular y que no se trate de un diseo completamente nuevo.
4.2.4. Discos duros

Todas las tecnologas discutidas hasta ahora son voltiles por naturaleza. En otras palabras, los datos contenidos en almacenamiento voltil se pierden cuando se desconecta el poder. Por otro lado, los discos duros son no-voltiles lo que signica que los datos se mantienen all, an despus que se ha desconectado la energa. Debido a esto, los discos duros ocupan un lugar muy especial en el espectro del almacenamiento. Su naturaleza no-voltil 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
53
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 ledos a la RAM. Otra diferencia de la cach y de la RAM es la velocidad del almacenamiento y recuperacin de los datos; los discos duros son de al menos un orden de magnitud ms lento que todas las tecnologas electrnicas utilizadas para cach y RAM. La diferencia en velocidad es debida principalmente a su naturaleza electromecnica. 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 tomara una unidad de alto rendimiento, para completar cada fase:

Movimiento del brazo de acceso (5.5 milisegundos) Rotacin del disco (.1 milisegundos) Lectura/escritura de datos de cabezales (.00014 milisegundos) Transferencia de datos hacia/desde la electrnica del disco (.003 Milisegundos)
De todas estas, solamente la ltima fase no es dependiente de ninguna operacin mecnica.
Nota Aunque hay mucho ms por aprender sobre los discos duros, las tecnologas de almacenamiento de disco son discutidas con ms detalles en el Captulo 5. Por los momentos, solamente es necesario tener presente la gran diferencia de velocidad entre la RAM y las tecnologas 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 ms.
4.2.5. Almacenamiento para respaldos fuera de lnea

El almacenamiento de respaldo fuera de lnea d un paso ms all del almacenamiento de disco duro en trminos de la capacidad (mayor) y de la velocidad (ms lento). Aqu, las capacidades solamente estn limitadas por su habilidad de conseguir y almacenar la media removible. Las tecnologas utilizadas en estos dispositivos varan ampliamente. He aqu los tipos ms populares:

Cinta magntica Disco ptico
Por supuesto, el tener una media removible signica que los tiempos de acceso son an ms largos, particularmente cuando los datos deseados estn en un medio que an no est cargado en el dispositivo de almacenamiento. Esta situacin es aliviada de alguna manera por el uso de dispositivos robticos capaces de montar y desmontar automticamente la media, pero las capacidades de almacenamiento de la media de tales dispositivos son nitas. Hasta en el mejor de los casos, los tiempos de acceso son medidos en segundos, lo cual est bastante lejos de los tiempos tpicos de acceso de los ya relativa mente lentos multi-milisegundos de un disco duro. Ahora que ha visto brevemente las diferentes tecnologas de almacenamiento utilizadas hoy en da, vamos a explorar los conceptos bsicos de la memoria virtual.
54
4.3. Conceptos bsicos sobre Memoria Virtual

An cuando la tecnologa detrs de la construccin 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 beran tener en consideracin: Nunca hay suciente RAM. Mientras que esta frase puede sonar al principio un poco cmica, muchos diseadores de sistemas op erativos han empleado una gran cantidad de tiempo tratando de reducir el impacto de esta limitacin. Esto lo han logrado mediante la implementacin de la memoria virtual una forma de combinar RAM con un almacenamiento ms lento para darle al sistema la apariencia de tener ms RAM de la que tiene instalada realmente.
4.3.1. La memoria virtual en trminos sencillos

Vamos a comenzar con una aplicacin hipottica. El cdigo de mquina que conforma esta aplicacin tiene un tamao de 10000 bytes. Tambin requiere otros 5000 bytes para el almacenamiento de datos y para la memoria intermedia de E/S. Esto signica que para ejecutar la aplicacin, deben haber ms de 15000 bytes de RAM disponible; un byte menos y la aplicacin no ser capaz de ejecutarse. Este requerimiento de 15000 bytes se conoce como el espacio de direcciones de la aplicacin. Es el nmero de direcciones nicas necesarias para almacenar la aplicacin y sus datos. En las primeras computadoras, la cantidad de RAM disponible tena que ser mayor que el espacio de direcciones de la aplicacin ms grande a ejecutar; de lo contrario, la aplicacin fallara con un error de "memoria insuciente". 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 cdigo requerido solamente para propsitos de inicial izacin poda ser sobreescrito con cdigo a utilizar posteriormente. Mientras que el solapamiento facilit las limitaciones de memoria, era un proceso muy complejo y susceptible a errores. El so lapamiento tambin fallaba en solucionar el problema de las limitaciones de memoria globales al sistema en tiempo de ejecucin. En otras palabras, un programa con solapamiento requera menos memoria para ejecutarse que un programa sin solapamiento, pero si el sistema no tiene suciente memoria para el programa solapado, el resultado nal es el mismo un error de falla de memoria. Con la memoria virtual el concepto del espacio de direcciones de las aplicaciones toma un signicado diferente. En vez de concentrarse en cuanta memoria necesita una aplicacin para ejecutarse, un sistema operativo con memoria virtual continuamente trata de encontrar una respuesta a la pregunta "qu tan poca memoria necesita la aplicacin para ejecutarse?". Aunque inicialmente pareciera que nuestra aplicacin hipottica requiere de un total de 15000 bytes para ejecutarse, recuerde nuestra discusin anterior en la Seccin 4.1 el acceso a memoria tiende a ser secuencial y localizado. Debido a esto, la cantidad de memoria requerida para ejecutar la aplicacin en un momento dado es menos que 15000 bytes usualmente mucho menos. Considere los tipos de accesos de memoria requeridos para ejecutar una instruccin de mquina sencilla:

La instruccin es leda desde la memoria. Se leen desde memoria los datos requeridos por la instruccin. Despus de completar la instruccin, los resultados de la instruccin son escritos nuevamente en memoria.
El nmero real de bytes necesarios para cada acceso de memoria varan de acuerdo a la arquitectura del CPU, la instruccin misma y el tipo de dato. Sin embargo, an si una instruccin 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 aplicacin de 15000 bytes. Si hubiese una forma de hacer un seguimiento de los requerimientos de memoria de la aplicacin a medida que esta se ejecuta, sera
55
posible mantener la aplicacin ejecutndose usando menos memoria que lo que indicara su espacio de direcciones. Pero esto genera una pregunta: Si solamente una parte de la aplicacin est en memoria en un momento dado, dnde 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 aplicacin se mantiene en disco. En otras palabras, el disco acta como un almacenamiento de respaldo para la RAM; un medio ms lento y tambin ms grande que acta como un "respaldo" para un almacenamiento ms rpido y ms pequeo. Esto puede parecer al principio como un gran problema de rendimiento en su creacin despus de todo, las unidades de disco son mucho ms 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 mayora 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 aplicacin 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 situacin entre la cach y la RAM: haciendo parecer una poca cantidad de almacenamiento rpido con grandes cantidades de un almacenamiento lento actuar como que si se tratase de grandes cantidades de almacenamiento rpido. Con esto en mente, exploremos el proceso en ms 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 mximo disponible para una aplicacin. 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 dene cuntos bits estn disponibles para propsitos de direccionamiento. El espacio de direcciones virtuales tam bin depende del sistema operativo puesto que la forma en que el sistema operativo fue implementado puede introducir lmites adicionales sobre aquellos impuestos por la arquitectura. La palabra "virtual" en el espacio de direcciones virtuales, signica que este es el nmero total de ubi caciones de memoria direccionables disponibles para una aplicacin, pero no la cantidad de memoria fsica instalada en el sistema, o dedicada a la aplicacin en un momento dado. En el caso de nuestra aplicacin 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 ministracin 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 direccin de memoria 123 siempre ser la misma direccin fsica dentro de la RAM. Sin embargo, con un MMU, las direcciones de memoria pasan a travs de un paso de traduccin antes de cada acceso de memoria. Esto signica que la direccin de memoria 123 puede ser redirigida a la direccin fsica 82043 en un momento dado y a la direccin 20468 en otro. Como resultado de esto, la sobrecarga relacionada con el seguimiento de las traducciones de memoria virtual a fsica sera demasiado. En vez de esto, la MMU divide la RAM en pginas secciones contiguas de memoria de un tamao jo que son manejadas por el MMU como unidades sencillas. Mantener un seguimiento de estas pginas y sus direccines traducidas puede sonar como un paso adicional confuso e innecesario, pero de hecho es crucial para la implementacin de la memoria virtual. Por tal razn, considere el punto siguiente:
56
Tomando nuestra aplicacin hipottica con un espacio de direcciones virtuales de 15000 bytes, asuma que la primera instruccin de la aplicacin accede a los datos almacenados en la direccin 12374. Sin embargo, tambin asuma que nuestra computadora solamente tiene 12288 bytes de RAM fsica. Qu pasa cuando el CPU intenta acceder a la direccin 12374? Lo que ocurre se conoce como un fallo de pgina.
4.4.1. Fallos de pgina

Un fallo de pgina es la secuencia de eventos que ocurren cuando un programa intenta acceder a datos (o cdigo) 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 pgina haciendo residentes en memoria los datos accedidos, permitiendo de esta manera que el programa continue la operacin como que si el fallo de pgina nunca ocurri. En el caso de nuestra aplicacin hipottica, el CPU primeramente presenta la direccin deseada (12374) al MMU. Sin embargo, el MMU no tiene traduccin para esta direccin. Por tanto, inter rumpe al CPU y causa que se ejecute un software, conocido como el manejador de fallos de pgina. El manejador de fallos de pgina determina lo que se debe hacer para resolver esta falla de pgina. El mismo puede:

Encontrar dnde reside la pgina deseada en disco y la lee (este es usualmente el caso si el fallo de pgina es por una pgina de cdigo) Determina que la pgina deseada ya est en RAM (pero no est asignada al proceso actual) y recongura el MMU para que apunte a el Apunta a una pgina especial que solamente contiene ceros y asigna una nueva pgina para el proceso solamente si este intenta alguna vez escribir a la pgina especial (esto se llama una pgina de copia en escritura y es utilizada a menudo por pginas que contienen datos inicializados a cero) Obtener la pgina deseada desde otro lugar (lo que se discute en detalle ms adelante)
Mientras que las primeras tres acciones son relativamente sencillas, la ltima no lo es. Por eso nece sitamos cubrir algunos tpicos adicionales.
4.4.2. El conjunto de direcciones de trabajo

El grupo de pginas de memoria fsica actualmente dedicadas a un proceso especco se conoce como conjunto de direcciones de trabajo para ese proceso. El nmero de pginas en el conjunto de direcciones de trabajo puede crecer o reducirse, dependiendo de la disponibilidad general de pginas del sistema. El conjunto de direcciones de trabajo crece si un proceso tiene fallos de pginas. El conjunto de direcciones de trabajo se reduce a medida que existen menos y menos pginas libres. Para evitar que se acabe la memoria completamente, se deben eliminar las pginas del conjunto de direcciones de trabajo y convertirlas en pginas libres, disponibles para un uso posterior. El sistema operativo reduce el conjunto de direcciones de trabajo mediante:

Escribiendo las pginas modicadas a un rea dedicada en un dispositivo de almacenamiento ma sivo (usualmente conocido como espacio de intercambio o de paginado) Marcando las pginas sin modicar como libres (no hay necesidad de escribir estas pginas 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 informacin de uso de todas las pginas. De esta manera, el sistema operativo determina cuales pginas son usadas activamente (y deben mantenerse en memoria como residentes) y cuales no (y por lo tanto, se pueden eliminar de memoria). En la mayora de los casos,
57
se utiliza un tipo de algoritmo de "menos usado recientemente" para determinar cuales pginas 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 pginas modicadas al espacio swap del sistema) es una parte normal de la operacin del sistema, es posible experimentar demasiado intercambio. La razn por la que estar atentos ante el excesivo intercambio es que la situacin siguiente puede ocurrir fcilmente, y repetirse una y otra vez:

Las pginas de un proceso son intercambiadas (swapped) El proceso se vuelve ejecutable e intenta acceder a una pgina en el espacio de intercambio La pgina es colocada en memoria (lo ms probable forzando a otras pginas de procesos a que sean extradas de all) Un momento despus, la pgina es colocada nuevamente fuera de memoria
Si esta secuencia de eventos se extiende demasiado, esto se conoce como thrashing y es un indicativo de insuciente 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 situacin rpidamente sobrepasa la carga impuesta por el trabajo real del sistema. En casos extremos, puede que el sistema no realice ningn trabajo til, consumiendo todos sus recursos moviendo pginas 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 ms fcilmente apli caciones ms 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 ms que hacer que un sistema operativo sin memoria virtual. Esto signica que el rendimiento nunca es tan bueno con memoria virtual como lo es cuando la misma aplicacin esta 100% residente en memoria. Sin embargo, esta no es razn suciente para abandonar la idea. Los benecios 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 ledo en este captulo y considere qu recursos del sistema son utilizados extensivamente por fallos de pginas y actividad de intercambio:

RAM Obviamente la RAM disponible es poca (de lo contrario no habra necesidad de fallos de pginas o de intercambio de pginas). 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 ministracin de memoria y estableciendo las operaciones necesarias de E/S para el paginado e intercambio.
La naturaleza interrelacionada de estas cargas hace fcil entender cmo las limitaciones de recursos pueden conducir a problemas graves de rendimiento.
58
Todo lo que se necesita es un sistema con poca RAM, alta actividad de fallos de pginas y un sistema ejecutando casi en sus lmites en trminos 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 mnima para un sistema bien congurado:

RAM Suciente RAM para todos los conjuntos de direcciones de trabajo con suciente exceso para manejar cualquier fallo de pgina2 Disco Debido a la actividad limitada de fallos de pgina, el ancho de banda de E/S de disco ser impactado de forma mnima. CPU La mayora de los ciclos de CPU realmente estn dedicados a ejecutar aplicaciones, en vez de ejecutar el cdigo de manejo de memoria del sistema
El punto a tener en mente es que el impacto en el rendimiento de la memoria virtual es mnimo cuando se utiliza tan poco como sea posible. Esto signica que el factor determinante para un buen rendimiento del subsistema de memoria virtual es tener suciente RAM. Lo siguiente (pero con mucho menos importancia) es suciente 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 ms limpia de intensivos fallos de pgina 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. Informacin especca de Red Hat Enterprise Linux

Debido a la complejidad inherente de un sistema operativo con memoria virtual en demanda, la su pervisin 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 ms directas y partir de all. Usando free es posible obtener una vista general concisa (quizs hasta un poco simplistica) de la utilizacin de la memoria principal y de intercambio. He aqu un ejemplo:
Podemos ver que este sistema tiene 1.2GB de RAM, de los que solamente 350MB estan realmente en uso. Como se puede esperar para un sistema con esta cantidad de RAM disponible, no se utiliza nada de los 500MB de memoria de intercambio. Compare ese ejemplo con el que sigue:
2.
Un sistema razonablemente activo siempre experimenta algn nivel de actividad de fallo de pginas, debido
a los fallos de pgina en los que se incurre cuando las aplicaciones lanzadas recientemente son tradas a memoria.
59
Este sistema tiena alrededor de 256MB de RAM, la mayora de la cual est en uso, dejando solamente 8MB libres. Ms de 100MB de los 512MB de swap estan en uso. An cuando el sistema est cierta mente ms limitado en trminos de memoria que el primer sistema, para determinar si esta limitacin de memoria est causando problemas de rendimiento, tenemos que investigar un poco ms.
vmstat, an cuando es ms crptico que free, tiene el benecio de que muestra ms que simplemente las estadsticas de utilizacin de memoria. He aqu la salida de vmstat 1 10:
r 2 2 1 1 2 3 3 2 3 2 procs b w 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 swpd 111304 111304 111304 111304 111304 111304 111304 111304 111304 111304 free 9728 9728 9616 9616 9616 9620 9440 9276 9624 9624 buff 7036 7036 7036 7036 7052 7052 7076 7076 7092 7108 memory cache 107204 107204 107204 107204 107204 107204 107360 107368 107372 107372 si 0 0 0 0 0 0 92 0 0 0 swap so 0 0 0 0 0 0 0 0 0 0 bi 6 0 0 0 0 0 244 0 16 0 io system bo in cs 10 120 24 0 526 1653 0 552 2219 0 624 699 48 603 1466 0 768 932 0 820 1230 0 832 1060 0 813 1655 972 1189 1165 us 10 96 94 98 95 90 85 87 93 68 sy 2 4 5 2 5 4 9 6 5 9 cpu id 89 0 1 0 0 6 6 7 2 23
Durante esta muestra de 10 segundos, la cantidad de memoria libre (el campo free) vara 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 cunta carga adicional de trabajo pueda manejar, dada la utilizacin actual de memoria. Cuando se investiga sobre cuestiones relacionadas a la memoria, a menudo es necesario determinar cmo 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 ms detalles. Revisando el informe de sar -r, podemos examinar la utilizacin de memoria principal y de inter cambio ms de cerca:
Linux 2.4.20-1.1931.2.231.2.10.ent (pigdog.example.com) 12:00:01 12:10:00 12:20:00 ...
08:40:00 Average: AM kbmemfree kbmemused AM 240468 1048252 AM 240508 1048212 PM 934132 324346 354588 964374 %memused kbmemshrd kbbuffers 81.34 0 133724 81.34 0 134172 27.51 74.83 0 0 26080 96072 07/22/2003
kbcached
485772
485600
185364
467559
Los campos kbmemfree y kbmemused muestran las estadsticas tpicas de memoria libre y en uso, mostrando el porcentage de memoria utilizada en el campo %memused. Los campos kbbuffers and kbcached muestran cuntos 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 lneas de este informe para que encajen en la pgina. He aqu el resto de cada lnea, con la marca de tiempo agregada a la izquierda para facilitar la lectura:
12:00:01 12:10:00 12:20:00 ...
08:40:00 Average: AM AM AM PM kbswpfree kbswpused 522104 0 522104 0 522104 522104 0 0 %swpused
0.00
0.00
0.00
0.00
60
Para la utilizacin 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 ms sobre la actividad de memoria de intercambio. A continuacin se muestra un ejemplo:
03:30:01 Average: AM AM AM PM pswpin/s pswpout/s
0.15 2.56
0.00 0.00
0.42 0.11 2.56
0.37
07/22/2003
Observe que, en promedio, hay tres veces menos pginas tradas desde la memoria de intercambio (pswpin/s) que las que se devuelven a esta (pswpout/s). Para entender mejor cmo se utilizan las pginas, consulte el informe sar -B:
08:40:00 Average: AM AM AM PM pgpgin/s pgpgout/s 0.03 8.61 0.01 7.51 0.00 201.54 7.79 201.54 activepg 195393 195385 71236 169367 inadtypg 20654 20655 1371 18999 inaclnpg 30352 30336 6760 35146 07/22/2003
inatarpg
49279
49275
15873
44702
Aqu podemos determinar cuntos bloques por segundo son paginados desde el disco (pgpgin/s) y paginados de vuelta al disco (pgpgout/s). Estas estadsticas sirven como un barmetro para la actividad general de la memoria virtual. Sin embargo, se puede aprender mucho ms examinando los otros campos en este informe. El kernel de Red Hat Enterprise Linux marca todas las pginas como activas o inactivas. Como su nombre lo implica, las pginas activas son las que estn siendo utilizadas de alguna manera (como pginas de procesos o de memoria intermedia, por ejemplo), mientras que las inactivas no. Este informe de ejemplo muestra que la lista de pginas activas (el campo activepg) promedia aproximadamente 660MB3. El resto de los campos en este informe se concentran en la lista inactiva pginas que, por alguna razn o la otra, no se han utilizado recientemente. El campo inadtypg muestra cuntas pginas inactivas estan sucias (dirty o modicadas) y requieren ser escritas al disco. Por otro lado, el campo inaclnpg, muestra cuntas pginas inactivas estn limpias (clean o sin modicar) y no necesitan ser escritas a disco. El campo inatarpg representa el tamao deseado de la lista inactiva. Este valor es calculado por el kernel de Linux y tiene un tamao tal que la lista inactiva permanezca lo sucientemente grande para actuar como un fondo para propsitos de reemplazo de pginas. Utilice el informe sar -R para datos adicionales sobre el status de pginas (especcamente, la fre cuencia con la que las pginas cambian de estado). He aqu un ejemplo de este informe:
3. El tamao de pgina 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 tamaos de pginas.
61

08:50:01 Average: AM AM AM PM frmpg/s -0.10 0.02 -3.19 0.01 shmpg/s 0.00 0.00 0.00 0.00 bufpg/s 0.12 0.19 0.46 -0.00 campg/s
-0.07
-0.07
0.81
-0.00
07/22/2003
Las estadsticas 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 pginas. Si es negativo, el valor indica la tasa a la que se estan reduciendo este tipo de pginas. Un valor de cero indica que las pginas de este tipo no se estn incrementando ni disminuyendo. En este ejemplo, la ltima parte muestra que se asignan un poco ms de tres pginas por segundo desde la lista de pginas libres (el campo frmpg/s) y se aade casi una pgina por segundo a la pgina cach (el campo campg/s). La lista de pginas utilizadas como memoria de intercambio (el campo bugpg/s) gana aproximadamente una pgina cada dos segundos, mientras que la lista de pginas de memoria compartidas (el campo shmpg/s) ni gana ni pierde pginas.

Esta seccin incluye varios recursos que se pueden utilizar para conocer un poco ms sobre la super visin de recursos y la materia especca a Red Hat Enterprise Linux discutida en este captulo.

Los recursos siguientes son instalados en el curso de una instalacin tpica de Red Hat Enterprise Linux y pueden ser de ayuda para aprender ms sobre los tpicos discutidos en este captulo.

La pgina man de free(1) Conozca cmo mostrar las estadsticas de la memoria libre y uti lizada. La pgina man de vmstat(8) Aprenda a desplegar una descripcin general concisa de la uti lizacin de procesos, memoria, swap, E/S, sistema y CPU. La pgina man de sar(1) Aprenda a producir un informe de utilizacin de recursos del sistema. La pgina man de sa2(8) Conozca cmo generar archivos de informes diarios de utilizacin de recursos del sistema.

http://people.redhat.com/alikins/system_tuning.html Informacin de optimizacin de sistemas servidores Linux. Una corriente de ideas para la optimizacin del rendimiento y supervisin de recursos para servidores. http://www.linuxjournal.com/article.php?sid=2396 Performance Monitoring Tools for Linux. Este pgina del Linux Journal est orientada ms hacia el administrador interesado en escribir una solucin grca personalizada de rendimiento. Algunos detalles quizs ya no sean vlidos pues se escribi muchos aos atrs, pero el concepto general y la ejecucin son robustas.
62

Los libros siguientes discuten varios problemas relacionados a la supervisin de recursos y son exce lentes fuentes para los administradores de sistemas Red Hat Enterprise Linux.

El Manual de administracin del sistema de Red Hat Enterprise Linux; Red Hat, Inc. Incluye un captulo sobre muchas de las herramientas de supervisin 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 supervisin de recursos presen tadas aqu e incluye otras que seran apropiadas para necesidades de supervisin de recursos ms especcas. Red Hat Linux Security and Optimization por Mohammed J. Kabir; Red Hat Press Aproximada mente las primeras 150 pginas de este libro discuten problemas relacionados al rendimiento. Esto incluye captulos dedicados a problemas de rendimiento especcos a la red, Web, correo elec trnico y servidores de archivos. Linux Administration Handbook por Evi Nemeth, Garth Snyder, y Trent R. Hein; Prentice Hall Este libro proporciona un captulo corto similar al mbito de este libro, pero incluye una seccin interesante sobre el diagnstico de un sistema que repentinamente se vuelve lento. Linux System Administration: A Users Guide por Marcel Gagne; Addison Wesley Professional Contiene un pequeo captulo sobre la supervisin y optimizacin del rendimiento. Essential System Administration (3rd Edition) por Aeleen Frisch; OReilly & Associates El captulo sobre la administracin de recursos contiene informacin general til con algunos aspectos especcos para Linux. System Performance Tuning (2nd Edition) por Gian-Paolo D. Musumeci y Mike Loukides; OReilly & Associates Aunque est orientado en gran medida hacia las implementaciones tradicionales de UNIX, hay muchas referencias especcas a Linux a lo largo del libro.
Captulo 5.
Administracin del Almacenamiento
Si hay una cosa que toma la mayor parte del da de un administrador de sistemas, esto es la ad ministracin del almacenamiento. Pareciera que los discos nunca tienen espacio suciente, que se sobrecargan con actividad de E/S o que fallan repentinamente. Por eso es vital tener un conocimiento prctico slido 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 estn almacenados los datos. A menos que posea un algn conocimiento sobre la operacin de los disposi tivos de almacenamiento masivo, quizs se encuentre en una situacin 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 ms fcilmente determinar si el subsistema de almacenamiento de su computador est funcionando correctamente. La gran mayora de los dispositivos de almacenamiento masivo utilizan alguna forma de media de rotacin y soportan el acceso aleatorio de los datos en esa media. Esto signica que los componentes siguientes estn 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 ms detalles cada uno de estos componentes.
5.1.1. Platos de discos

La media rotativa utilizada por casi todos los dispositivos de almacenamiento masivo estn en la forma de uno o ms platos planos y de forma circular. El plato puede estar compuesto de cualquier nmero de materiales diferentes, tales como aluminio, vidrio y policarbonatos. La supercie de cada plato se trata de forma que permita el almacenamiento de datos. La naturaleza exacta del tratamiento va a depender de la tecnologa de almacenamiento de datos utilizada. La tec nologa de almacenamiento de datos ms comn est basada en la propiedad de magnetismo; en estos casos los platos se cubren con un compuesto que presenta buenas caractersticas magnticas. Otra tecnologa de almacenamiento de datos comn est basada en principios pticos; en estos casos, los platos se cubren con materiales cuyas propiedades pticas pueden ser modicadas, y en conse cuencia, permitiendo almacenar datos pticamente1 . Sin importar la tecnologa de almacenamiento utilizada, los platos del disco se giran , causando que su supercie completa barra ms 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 captulo en su momento pertinente.
64
Captulo 5. Administracin 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 magnticas u pticas necesarias para interactuar con los materiales que cubren la supercie de los platos de discos. Algunas veces las condiciones bajo las cuales estos dispositivos deben operar son difciles. 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 supercie del plato. Sin embargo, si el cabezal y la supercie del plato del disco se tocan, la friccin resultante provocara un dao severo tanto al cabezal como al plato. Por lo tanto, las supercies tanto del cabezal como del plato son pulidas cuidadosamente y el cabezal utiliza aire a presin desarrollado por los platos que giran para otar sobre la supercie del plato, "otando" a una altitud no menor que el grueso de un cabello humano. Por eso es que las unidades de discos magnticos son muy sensibles a choques, cambios drsticos de temperaturas y a la contaminacin del aire. Los retos que enfrentan los cabezales pticos son de alguna manera diferentes de aquellos para los cabezales magnticos - aqu, el ensamblado de la cabeza debe permanecer a una distancia relativa mente constante de la supercie del plato. De lo contrario, los lentes utilizados para enfocarse sobre el plato no producen una imagen lo sucientemente denida. En cualquier caso, las cabezas utilizan una cantidad muy pequea del rea de supercie del plato para el almacenamiento de datos. A medida que el plato gira por debajo de las cabezas, esta rea de supercie toma la forma de una lnea circular muy delgada. Si es as como los dispositivos de almacenamiento masivo funcionan, signica que ms del 99% de la supercie del plato se desperdiciara. Se pueden montar cabezas adicionales sobre el plato, pero para utilizar completamente el rea de supercie del plato se necesitan ms de mil cabezales. Lo que se requiere es algn mtodo de mover los cabezales sobre la supercie del plato.
5.1.3. Brazos de acceso

Utilizando una cabeza conectada a un brazo que sea capaz de barrer sobre la supercie 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 rpidamente Moverse con gran precisin
El brazo de acceso se debe mover lo ms rpido posible, pues el tiempo que se pierde moviendo el cabezal desde una posicin 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 precisin porque, como se mencion ante riormente, el rea de supercie utilizada por los cabezales es muy pequea. Por lo tanto, para usar ecientemente la capacidad de almacenamiento del plato, es necesario mover las cabezas solamente lo suciente para asegurar que cualquier datos escrito en la nueva posicin no sobreescribe los datos escritos en la posicin previa. Esto tiene el efecto de dividir conceptualmente la supercie del plato en miles o ms aros concntricos o pistas. El movimiento del brazo de acceso desde una pista a la siguiente a menudo se conoce como bsqueda y el tiempo que toma el brazo de acceso para moverse de una pista a otra se le conoce como tiempo de bsqueda.
2. En algunos dispositivos pticos (tales como unidades de CD-ROM), el brazo de acceso se mueve contnu
amente, causando que el ensamble del cabezal describa una ruta en espiral sobre la supercie del plato. Esta es una diferencia fundamental en como se utiliza el medio de almacenamiento y reeja los orgenes del CD-ROM como un medio para almacenar msica, donde la recuperacin contnua de datos es una operacin ms comn que la bsqueda de un punto de datos especco.
65
Cuando existen mltiples platos (o un plato que con ambas supercies utilizadas para almacenamiento de datos), se apilan los brazos para cada supercie, permitiendo que se pueda acceder a la misma pista en cada supercie simultneamente. Si se pueden visualizar las pistas para cada supercie con el acceso estacionario sobre una pista dada, apareceran como que estn apiladas una sobre la otra, haciendo una forma cilndrica; por tanto, el conjunto de pistas accesibles en una posicin dada de los brazos de acceso se conocen como cilindro.
5.2. Conceptos de direcciones de almacenamiento

La conguracin de los platos de discos, cabezales y brazos de acceso hacen posible posicionar el cabezal sobre cualquier parte de cualquier supercie de cualquier plato en el dispositivo de almace namiento. Sin embargo, esto no es suciente; para utilizar esta capacidad de almacenamiento, debe mos tener algn mtodo de dar direcciones a partes uniformes del almacenamiento disponible. Hay un aspecto nal requerido de este proceso. Considere todas las pistas en los muchos cilindros presentes en un dispositivo tpico de almacenamiento masivo. Puesto que las pistas tienen dimetros variados, sus circunferencias tambin varan. 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 solucin es dividir cada pista en mltiples sectores o bloques segmentos de un tamao consistente (a menudo 512 bytes) de almacenamiento. El resultado es que cada pista contiene un nmero jo 3 de sectores. Un efecto secundario es que cada sector contiene espacio inutilizado - el espacio entre sectores. A pesar del nmero constante de sectores en cada pista, la cantidad de espacio inutilizado vara - relati vamente poco espacio inutilizado en las pistas internas y una cantidad mucho mayor de espacio en las pistas ms 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 mtodos de direccionamiento - el direccionamiento basado en la geometra y el direccionamiento basado en bloques.
5.2.1. Direcciones basadas en la geometra

El trmino direccionamiento basado en la geometra se reere al hecho de que dispositivos de al macenamiento masivo almacenan datos en un lugar especco en el medio de almacenamiento. En el caso de los dispositivos que se describen aqu, esto se reere a tres items especcos que denen un punto especco en los platos del disco del dispositivo:

Cilindros Cabezas Sectores
Las secciones siguientes describen como una direccin hipottica puede describir una ubicacin fsica especca en el medio de almacenamiento.
3. Mientras que los dispositivos de almacenamiento masivo anteriores utilizaban el mismo nmero de sectores
para cada pista, los dispositivos ms recientes dividen el rango de cilindros en "zonas" diferentes, con cada zona teniendo un nmero de sectores por pista. La razn para esto es aprovechar el espacio adicional entre sectores en los cilindros externos, donde existe ms espacio sin utilizar.
66 5.2.1.1. Cilindros
Como se indic anteriormente, el cilindro denota una posicin especca del brazo de acceso (y por lo tanto, las cabezas de lectura/escritura). Especicando un cilindro particular, estamos eliminando todos los otros cilindros , reduciendo nuestra bsqueda a solamente una pista para cada supercie en el dispositivo de almacenamiento masivo. Cilindros 1014 Tabla 5-1. Direcciones de Almacenamiento En la Tabla 5-1, se ha llenado la primera parte de una direccin basada en la geometra. Dos compo nentes ms a esta direccin la cabeza y el sector permanecen indenidos. 5.2.1.2. Cabezas Aunque en el sentido ms estricto estamos seleccionando un plato de disco particular, puesto que la supercie tiene un cabezal de lectura/escritura dedicado a el, es ms fcil pensar en trminos de interactuar con un cabezal especco. De hecho, la electrnica subyacente del dispositivo actualmente selecciona un cabezal eliminando la seleccin de el resto solamente interacta con el cabezal por la duracin de la operacin de E/S. Todas las otras pistas que conforman el cilindro actual han sido eliminados. Cilindros 1014 Tabla 5-2. Direcciones de Almacenamiento En la Tabla 5-2, se llenan las primeras dos partes de una direccin basada en la geometra. Permanece indenido un componente de esta direccin el sector. 5.2.1.3. Sectores Especicando un sector especco, se completa la direccin y se logra identicar unvocamente el bloque de datos deseado. Cilindros 1014 Tabla 5-3. Direcciones de Almacenamiento En la Tabla 5-3, se llena la direccin completa basada en la geometra. Esta direccin identica la ubicacin de un bloque especco fuera de todos los otros bloques en ese dispositivo. 5.2.1.4. Problemas con el direccionamiento basado en la geometra Mientras que el direccionamiento basado en la geometra es directo, hay un rea de ambigedad que pueda generar problemas. La ambigedad est en la numeracin de cilindros, cabezales y sectores. Es verdad que cada direccin basada en la geometra identica unvocamente un bloque de datos Cabezas 2 Sectores 12 Cabezas 2 Sectores X Cabezas X Sectores X
67
especco, pero esto solamente aplica si no cambia el esquema de numeracin para los cilindros, cabezales y sectores. Si el esquema de numeracin cambia (tal como cuando el software/hardware interactuando con el dispositivo de almacenamiento cambia), entonces la correspondencia entre las direcciones basadas en la geometra y sus correspondientes bloques de datos sern diferentes, ha ciendo imposible acceder a los datos deseados. Debido al potencial para esta ambigedad, se desarroll una solucin diferente. La seccin siguiente describe esto en ms detalles.
5.2.2. Direcciones basadas en bloques

El direccionamiento basado en bloques es mucho ms directo que el direccionamiento basado en la geometra. Con el direccionamiento basado en bloques, a cada bloque de datos se le d un nmero nico. Este nmero se pasa desde el computador al dispositivo de almacenamiento masivo, que luego lleva a cabo la conversin interna a la direccin basada en la geometra requerida por la circuitera de control del dispositivo. Debido a que la conversin a la direccin basada en la geometra siempre la lleva a cabo el dispositivo mismo, esta es siempre consistente, eliminando as el problema inherente en dar la direccin basada en la geometra 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 conexin se conoce como una interfaz. Los dispositivos de almacenamiento tambin tienen interfaces. Es importante conocer sobre las interfaces por dos razones principales:

Existen muchas interfaces diferentes (la mayora completamente incompatibles) Las diferentes interfaces tienen caractersticas 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 organizacin. De lo contrario, est el riesgo de comprar el hardware incorrecto cuando se planea una actualizacin del sistema. Las interfaces tienen diferentes capacidades de rendimiento, haciendo algunas ms adecuadas que otras para ciertos ambientes. Por ejemplo, las interfaces capaces de soportar dispositivos de alta ve locidad son ms adecuadas para los ambientes de servidores, mientras que las interfaces ms lentas son sucientes para un uso de escritorio ms ligero. Tales diferencias en rendimiento llevan a diferen cias en precios, lo que signica que como siempre usted recibe lo que paga. La computacin de alto rendimiento no viene a precios bajos.
5.3.1. Antecedentes histricos

A travs de los aos se han creado diferentes interfaces para los dispositivos de almacenamiento masivo. Algunos estn 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 aos para as pro porcionar una perspectiva de las interfaces en uso hoy da. FD-400 Originalmente diseada para las unidades de discos exibles de 8 pulgadas a mitad de los aos 70. Utilizaba un cable conductor 44 con un conector a la tarjeta de circuitos que suministraba tanto energa como datos.
68 SA-400
Otra interfaz para unidades de discos exible (esta vez diseada originalmente a nales de los 70 para el entonces nuevo disco de 5.25 pulgadas). Utilizaba un cable conductor de 34 con un conector de socket estndar. Una versin ligeramente modicada de esta interfaz an se usa hoy da 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 aos 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 aos 70 y 80. ST506/412 Una interfaz de disco duro que viene de los aos 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 pequeos mejorada, esta interfaz se consider un sucesor de ST506/412 con tasas de transferencia ms rpida y soportando tamaos ms grandes de unidades. La interfaz ESDI, de mediados de los 80, utilizaba el mismo esquema de conexin de dos cables que su predecesor. Tambin existan interfaces propietarias de los fabricantes ms grandes (principalmente IBM y DEC). La intencin detrs de la creacin de estas interfaces fue intentar proteger el negocio extremadamente lucrativo de los perifricos para sus computadores. Sin embargo, debido a su naturaleza propietaria los dispositivos compatibles con estas interfaces eran ms 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 seccin ya casi no tienen mucha posicin (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 computacin permanece constante por mucho tiempo. Por lo tanto, siempre est atento a las nuevas tecnologas de interfaces; un da puede encontrar una que sea ms adecuada para sus necesidades que las ofertas tradicionales en uso.
5.3.2. Interfaces de hoy da con estndares de la industria

A diferencia de las interfaces propietarias mencionadas en la seccin anterior, algunas interfaces han sido adoptadas ms globalmente y se convirtieron en estndares de la industria. Dos interfaces en particular han experimentado est transicin y hoy son el corazn del estndar de la industria:

IDE/ATA SCSI
5.3.2.1. IDE/ATA IDE viene de Integrated Drive Electronics. Esta interfaz se origin a nales de los 80 y utiliza un conector de 40 pines.
69
Nota En realidad, el nombre correcto para esta interfaz es "AT Attachment" (o ATA), pero el trmino "IDE" (que en realidad se reere a un dispositivo de almacenamiento masivo compatible con ATA) todava se utiliza. Sin embargo, para el resto de esta seccin utiliza el nombre apropiado de esta interfaz ATA.
ATA implementa una topologa de bus, con cada bus soportando dos dispositivos de almacenamiento masivo. Estos dos dispositivos se conocen como maestro y esclavo. Estos trminos pueden llevar a confusiones, pues implican un tipo de relacin entre los dispositivos; pero este no es el caso. La seleccin de cual dispositivo es el maestro y cual es el esclavo, normalmente se selecciona a travs del uso de bloques de jumpers en cada dispositivo.
Nota Una innovacin ms reciente es la introduccin de las capacidades de seleccin de cable a ATA. Esta innovacin requiere el uso de un cable especial, un controlador ATA y dispositivos de almacenamiento masivo que soporten la seleccin del cable (normalmente a travs de una conguracin en jumpers de "seleccin de cable"). Cuando se congura de la forma adecuada, la seleccin de cable elimina la necesidad de cambiar los jumpers cuando se mueven dispositivos; en vez de esto, la posicin del dispositivo en el cable ATA denota si se trata del maestro o del esclavo.
Una variacin de esta interfaz ilustra las formas nicas en que se pueden mezclar las tecnologas y tambin introduce nuestro prximo estndar de la industria para las interfaces. ATAPI es una variacin de la interfaz ATA y viene de AT Attachment Packet Interface. Utilizada principalmente por las unidades de CD-ROM, una ATAPI sigue los aspectos elctricos y mecnicos de la interfaz ATA pero utiliza el protocolo de comunicacin de la prxima interfaz discutida SCSI. 5.3.2.2. SCSI Formalmente conocida como Small Computer System Interface, Interfaz para sistemas de computacin pequeos, SCSI como se conoce hoy da se origin a principios de los 80 y se declar un estndar en 1986. De forma similar que ATA, SCSI utiliza una topologa de bus. No obstante ese es el n de las semejanzas. El uso de una topologa de bus signica que cada dispositivo en el bus debe ser identicado de forma nica de alguna forma. Mientras que ATA soporta solamente dos dispositivos diferentes para cada bus y les d un nombre especco, SCSI hace esto asignando a cada dispositivo en el bus SCSI una direccin numrica nica o SCSI ID. Cada dispositivo en un bus SCSI se debe congurar (usualmente mediante jumpers o switches4 ) para responder a su SCSI ID. Antes de continuar ms all con esta discusin, es importante notar que el estndar SCSI no representa una nica interfaz, pero una familia de interfaces. Hay varias reas en las que SCSI vara:

Ancho del bus Velocidad del bus Caractersticas elctricas

Algunos hardware de almacenamiento (usualmente aquellos que incorporan conductores de unidades re-
4.
movibles) estn diseados para que el hecho de conectar un mdulo en un lugar, automticamente congura el SCSI ID a un valor adecuado.
70
El estndar SCSI original describe una topologa de bus en la cual ocho lneas en el bus se utilizan para la transferencia de datos. Esto signica que los primeros dispositivos SCSI podan transferir datos solamente un byte a la vez. En aos posteriores, se expandi el estndar para permitir implementa ciones en las que se utilizaban diecisis lneas, doblando la cantidad de datos que podan transmitir los dispositivos. Las implementaciones originales SCSI de "8 bits" se les conoca 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 rpida. 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 trminos, se pueden nombrar de forma concisa varias conguraciones SCSI. Por ejemplo, "ultra-wide SCSI" se reere a un bus SCSI de 16-bits funcionando a 20MHz. El estndar SCSI original utilizaba sealizacin single-ended ; esto es una conguracin elctrica donde solamente se utiliza un conductor para pasar una seal elctrica. Las implementaciones pos teriores tambin permitieron el uso de la sealizacin diferencial, donde se utilizan dos conductores para pasar una seal. El SCSI diferencial (el cual posteriormente se llam diferencial de alto voltaje o HVD SCSI) tiene el benecio de una sensibilidad reducida ante el ruido elctrico y permita mayores largos de cable, pero nunca se volvi popular en el mercado de la computacin convencional. Una im plementacin posterior, conocida como diferencial de bajo voltaje (LVD), nalmente 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 tambin determina cuantos dispositivos se pueden conectar a un bus. El SCSI normal soporta 8 dispositivos direccionados unvocamente, mientras que SCSI ancho soporta 16. En cualquier caso, debe asegurarse de que todos los dispositivos estn congurados a un nico ID SCSI. Dos dispositivos compartiendo un mismo ID produce problemas que pueden llevar a corrupcin 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 conguran un dispositivo a utilizar el mismo ID SCSI que el controlador de bus. Esto signica que, en prctica, 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 mayora de las implementaciones incluyen alguna forma de escanear el bus SCSI; pero esto a menudo se utiliza para conrmar que todos los dispositivos esten correctamente congurados. Si el escaneo de un bus devuelve el mismo dispositivo para cada ID SCSI, ese dispositivo ha sido congurado de forma incorrecta al mismo ID SCSI que el controlador. Para resolver este problema, recongure 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 terminacin se logra colocando una carga con la impedancia correcta en cada conductor que comprende el bus SCSI. La terminacin es un requerimiento elctrico; sin el, las diferentes seales presentes en el bus se reejaran fuera del bus, mutilando toda la comunicacin.
5. Fast-80 tcnicamente 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.
71
Muchos (pero no todos) los dispositivos SCSI vienen con terminadores internos que se pueden habil itar o inhabilitar usando jumpers y switches. Tambin estn disponibles los terminadores externos. Una ltima cosa a tener en mente sobre SCSI no es simplemente una interfaz estndar para los dispositivos de comunicacin masiva. Muchos otros dispositivos (tales como escaners, impresoras y dispositivos de comunicacin) 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 ms para estos tipos de dispositivos en el futuro.
Sugerencia Las interfaces USB y IEEE - 1394 tambin estn 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 estn basadas en ATA o en SCSI con circuitera de conversin externa.
No importa la interfaz que un dispositivo de almacenamiento masivo utilice, el funcionamiento interno del dispositivo tiene una inuencia en su rendimiento. La seccin siguiente explora este importante tpico.
5.4. Caractersticas de rendimiento del disco duro

Las caractersticas de rendimiento del disco duro se presentaron en la Seccin 4.2.4; esta seccin discute esta materia en ms detalle. Es importante que los administradores de sistemas entiendan esto, puesto que sin un conocimiento bsico sobre cmo operan los discos duros, es posible hacer cambios inconscientemente a la conguracin de su sistema que podran impactar negativamente su rendimiento. El tiempo que toma una unidad de disco en responder a una peticin completa de E/S depende de dos cosas:

Las limitaciones mecnicas y elctricas del disco duro La carga de E/S impuesta por el sistema
Las secciones siguientes exploran en ms profundidad estos aspectos del rendimiento del disco duro.
5.4.1. Limitaciones mecnicas/elctricas

Puesto que los discos duros son dispositivos electromecnicos, estn sujetos a varias limitaciones en su velocidad y rendimiento. Cada peticin de E/S requiere que los diferentes componentes de su disco funcionen juntos para satisfacer la peticin. Puesto que cada uno de estos componentes tiene diferentes caractersticas de rendimiento, el rendimiento general del disco duro est determinado por la suma del rendimiento de los componentes individuales. Sin embargo, los componentes electrnicos son al menos un orden de magnitud ms rpidos que sus componentes mecnicos. Por lo tanto, son los componentes mecnicos los que tienen el mayor impacto en el rendimiento general del disco duro.
72
Sugerencia La forma ms efectiva de mejorar el rendimiento del disco duro es reduciendo la actividad mecnica 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 nmero en ms 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 sosticados embebidos que controlan su operacin. Estos sistemas de computacin realizan las tareas siguientes:

Se relacionan con el mundo externo a travs de la interfaz del disco duro Controlan la operacin del resto de los componentes del disco duro, recuperandose de cualquier condicin de error que pueda surgir Procesan los datos ledos y escritos a la media de almacenamiento
An 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 ledas/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 contribucin del cabezal al tiempo total de acceso. 5.4.1.3. Latencia rotacional Puesto que los platos del disco estn en contnuo movimiento, cuando llega la peticin de E/S es muy poco probable que el plato se encuentre en el punto exacto en su rotacin necesario para acceder el sector deseado. Por lo tanto, an 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 posicin bajo el cabezal de lectura/escritura. Esta es la razn por la cual los discos duros de alto rendimiento tpicamente giran sus platos de disco a altas velocidades. Hoy en da, las velocidades de 15,000 RPM estn reservadas para unidades de ms 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 taln de Aquiles, este es el brazo de acceso. La razn para esto es que el brazo de acceso se debe mover muy rpidamente y con gran precisin sobre relativamente largas distancias. Adems, el movimiento del brazo de acceso no es continuo debe acelerar rpidamente a medida que se acerca al cilindro deseado y luego desacelerar igualmente rpido para evitar disparar demasiado. Por lo tanto, el brazo de acceso debe ser resistente (para sobrevivir las violentas fuerzas provocadas por los rpidos movimientos) pero tambin ligero (as hay menos masa que acelerar/desacelerar).
73
Es difcil lograr estos objetivos conictivos, 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 especcos de la carga de E/S son:

La cantidad de lecturas contra escrituras El nmero de lectores/escritores actuales La ubicacin de las lecturas/escrituras
Estos se discuten con ms detalles en las secciones siguientes. 5.4.2.1. Lecturas contra Escrituras Para el disco duro promedio usando media magntica para el almacenamiento de datos, el nmero de operaciones de lecturas de E/S contra el nmero de operaciones de escritura de E/S no es de mayor preocupacin, pues la lectura y escritura de datos toma la misma cantidad de tiempo 6. Sin embargo, otras tecnologas de almacenamiento toman diferentes cantidades de tiempo para procesar las lecturas y las escrituras7 . El impacto de esto es que los dispositivos que toman ms tiempo en procesar las operaciones de escritura de E/S (por ejemplo) son capaces de manejar menos escrituras de E/S que lecturas. Valo de otra forma, una escritura de E/S consume ms de la habilidad del dispositivo de procesar las peticiones que una lectura de E/S. 5.4.2.2. Lecturas/Escrituras mltiples Un disco duro que procesa peticiones de E/S desde mltiples fuentes experimenta una carga diferente que un disco duro que sirve peticiones E/S desde una nica fuente. La principal razn para esto se debe al hecho de que mltiples 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. Despus de todo, el solicitante debe determinar la naturaleza de la peticin de E/S antes de llevarla a cabo. Puesto que el procesamiento necesario para determinar esto toma tiempo, hay un lmite en la carga de E/S que cualquier solicitante puede generar solamente un CPU ms rpido puede aumentar esto. Esta limitacin se vuelve ms pronunciada si el solicitante requiere de algn 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 peticin de E/S para leer datos se debe eventualmente satisfacer leyendo fsicamente los datos desde la media de almacenamiento. Esto signica 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 fsicamente los datos desde la media. 7. Algunos discos pticos presentan este comportamiento, debido a las limitaciones fsicas de la tecnologa utilizada para implementar el almacenamiento ptico de datos.
74
Sin embargo, con mltiples solicitantes, se pueden soportar mayores cargas de E/S. Siempre y cuando se tenga suciente poder de CPU para soportar el procesamiento necesario para generar las peticiones de E/S, el aadir ms solicitantes de E/S tambin incrementa la carga resultante de E/S. Sin embargo, hay otro aspecto sobre esto que tambin tiene una inuencia en la carga de E/S resul tante. Esto se discute en la seccin siguiente. 5.4.2.3. Ubicacin de Lecturas/Escrituras An cuando no se limita estrctamente a un ambiente de mltiples solicitudes, este aspecto del rendimiento del disco duro tiende a mostrarse ms en tales entornos. El problema es si la peticin de E/S que se est haciendo al disco duro es por datos que fsicamente estn cerca de otros datos que tambin estn siendo solicitados. La razn de la importancia de esto se hace aparente si se tiene en mente la naturaleza electromecnica del disco duro. El componente ms lento de la unidad de disco duro es el brazo de acceso. En con secuencia, si los datos accesados por la peticin de E/S entrante no requiere mayor movimiento del brazo de acceso, el disco duro es capaz de servir ms 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 especicaciones de rendimiento del disco duro. Estas especica ciones a menudo incluyen tiempos de bsquedas de cilindro adyacente (donde el brazo de acceso se mueve solamente una pequea cantidad - solamente al siguiente cilindro) y tiempos de bsqueda de movimiento completo (donde el brazo de acceso se mueve desde el primer cilindro al ltimo). Por ejemplo, he aqu los tiempos de bsquedas para un disco duro de alto rendimiento: Cilindro adyacente 0.6 Movimiento completo 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 geomtrica o lgica). Lo que se necesita son mtodos para convertir el almacenamiento sin formato en un disco duro que sea utilizable fcilmente. Las secciones siguientes exploran algunas de las tcnicas usadas ms comn mente para lograr esto.
5.5.1. Particiones/cuotas
Lo primero que sorprende a un administrador de sistemas es que el tamao 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 particin que almacena los archivos del sistema operativo no se ve
75
afectada an cuando la particin que contiene los archivos de usuarios se llena completamente. El sistema operativo todava 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 reeren 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 ms de cerca. 5.5.1.1. Atributos de particiones Las particiones se denen por los atributos siguientes:

Geometra de la particin Tipo de la particin Campo del tipo de particin
Estos atributos se exploran con ms detalles en las secciones siguientes.

5.5.1.1.1. Geometra La geometra de una particin se reere a su colocacin fsica en la unidad de disco. La geometra se puede especicar en trminos de cilindros de comienzo y nal, cabezales y sectores, aunque a menudo las particiones comienzan y terminan en los lmites del cilindro. El tamao de una particin se dene como la cantidad de almacenamiento entre el cilindro de comienzo y el del nal. 5.5.1.1.2. Tipo de particin El tipo de la particin se reere a la relacin de la particin con las otras particiones en el disco duro. Hay tres tipos de particiones:

Particiones Primarias Particiones extendidas Particiones lgicas
Las secciones siguientes describen cada tipo de particin.

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 ms de cuatro parti ciones por unidad de disco. Una particin extendida puede contener dentro de s mltiples particiones, extendiendo el nmero de particiones posibles en una sola unidad de disco. La introduccin de las par ticiones extendidas se gener por el desarrollo constante de las capacidades de los discos duros.
76 5.5.1.1.2.3. Particiones lgicas
Las particiones lgicas son aquellas que estn contenidas dentro de una particin extendida; en trmi nos de uso, son iguales a una particin primaria no extendida.
5.5.1.1.3. Campo de tipo de particin Cada particin tiene un campo de tipo que contiene un cdigo que indica el uso anticipado de la particin. El campo de tipo puede o no reejar el sistema operativo del computador. En cambio, puede reejar como los datos son almacenados dentro de la particin. La seccin siguiente contiene ms informacin sobre este importante aspecto.
5.5.2. Sistemas de archivos

An teniendo el dispositivo de almacenamiento masivo congurado y particionado correctamente, sera difcil almacenar y recuperar informacin todava nos falta una forma de estructurar y orga nizar esa informacin. 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 distincin 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 mtodo para representar datos en un dispositivo de almacenamiento masivo. Los sistemas de archivos usualmente incluyen las caractersticas siguientes:

Almacenamiento de datos basado en archivos Estructura de directorio jerrquico (algunas veces llamado "carpeta") Seguimiento de la creacin de archivos, tiempos de acceso y de modicacin Algn nivel de control sobre el tipo de acceso permitido para un archivo especco 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 construdo para un sistema operativo monousuario podra fcilmente utilizar un mtodo de control de acceso ms simplicado 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 organizacin, se puede asegurar de que no slo el sistema est a la altura de la tarea, pero tambin que es ms fcil y eciente de mantener. Con esto en mente, las secciones siguientes exploran estas funcionalidades en ms detalles. 5.5.2.1. Almacenamiento basado en archivos Mientras que los sistemas de archivos que utilizan esta metfora para el almacenamiento de datos son practicamente universales que casi se consideran como la norma, todava existen varios aspectos que se deben considerar. Primero debe estar consciente de cualquier restriccin de nombres. Por ejemplo, cules son los carc teres permitidos en un nombre de archivo? Cul es el largo mximo para un nombre de archivo? Estas preguntas son importantes, pues dictan cuales nombres de archivos se pueden utilizar y cuales no. Los
77
sistemas operativos ms antigos con sistemas de archivos ms primitivos permitan solamente carac teres alfanumricos (y solamente maysculas) y nicamente nombres de archivos 8.3 (lo que signica un nombre de archivo de ocho carcteres, seguido de una extensin de tres carcteres). 5.5.2.2. Estructura de directorio jerrquico Mientras que los sistemas de archivos en ciertos sistemas operativos antigos no incluan el concepto de directorios, todos los sistemas de archivos de hoy da incluyen esta caracterstica. Los directo rios son usualmente implementados como archivos, lo que signica que no se requiere de utilidades especiales para mantenerlos. Ms an, 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 jerrquica de mltiples niveles. Este es un concepto poderoso con el cual muchos administradores de sistemas deberan de estar familiarizados. Usando las jerarquas de mltiples niveles puede hacer la adminis tracin de archivos mucho ms fcil para usted y sus usuarios. 5.5.2.3. Seguimiento de la creacin de archivos, tiempos de acceso y modicacin La mayora 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 modicacin. Ms all de la conveniencia de poder determinar cuando un archivo dado fue creado, accedido o modicado, estas fechas son vitales para la operacin adecuada de los respaldos incrementales. Se puede encontrar ms informacin sobre como los respaldos utilizan estas funcionalidades de los sistema de archivos en la Seccin 8.2. 5.5.2.4. Control de acceso El control de acceso es un rea en la que los sistemas de archivso dieren dramticamente. Algunos sistemas de archivos no tienen un modelo claro para el control de acceso, mientras que otros son mucho ms sosticados. En trminos generales, la mayora de los sistemas de archivos modernos combinan dos componentes en una metodologa cohesiva de control de acceso:

Identicacin del usuario lista de acciones permitidas
La identicacin de usuarios signica que el sistema de archivos (y el sistema operativo subyacente) primeramente debe ser capaz de identicar unvocamente a usuarios individuales. Esto hace posible tener una responsabilidad completa con respecto a cualquier operacin a nivel de sistema de archivos. Otra funcionalidad de ayuda es la de los grupos de usuarios. Se utilizan grupos ms a menudo en organizaciones donde los usuarios pueden ser miembros de uno o ms proyectos. Otra funcionalidad que algunos sistemas de archivos soportan es la creacin de identicadores genricos que se pueden asignar a uno o ms 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 ms 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.
78 5.5.2.5. Contabilidad del espacio utilizado
Una constante en la vida de un administrador de sistemas es la de que nunca hay suciente espacio libre, y an si lo hubiese, no estar disponible por mucho tiempo. Por lo tanto, un administrador de sistemas debera al menos ser capaz de determinar fcilmente el nivel de espacio libre disponible para cada sistema de archivos. Adems, los sistemas de archivos con capacidades de identicacin de usuarios bien denidas, a menudo incluyen la caracterstica de mostrar la cantidad de espacio que un usuario particular ha consumido. Esta caracterstica 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 sern responsables por el con sumo de 80 por ciento de su espacio disponible en disco. Al facilitar la identicacin de estos usuarios en el 20 por ciento, puede ms efectivamente manejar sus activos relacionados al almacenamiento. Tomando este paso un poco ms all, algunos sistemas de archivos incluyen la habilidad de establecer los lmites de uso del usuario (conocidos comunmente como cuotas de disco) en la cantidad de espacio en disco que pueden consumir. Los detalles especcos varan de un sistema de archivos al otro, pero en general a cada usuario se le puede asignar una cantidad especca de almacenamiento que un usuario puede utilizar. Ms all de all, los sistemas de archivos varan. Algunos sistemas de archivos permiten que el usuario se exceda de su lmite solamente una vez, mientras que otros implementan un "perodo de gracia" durante el que aplica un segundo lmite ms 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 reexin sobre esta materia antes de pasar el almacenamiento a sus usuarios, le puede ahorrar bastante trabajo innecesario ms 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 benecios:

Ms fcil de entender Ms exibilidad en un futuro
Al imponer cierto nivel de estructura en su almacenamiento, este se puede entender ms fcilmente. 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 reejan la estructura de su or ganizacin. De esta forma, la gente que trabaja en contabilidad tendr sus directorios bajo un directorio llamado contabilidad, los que trabajan en ingeniera tendrn sus directorios bajo ingenieria y as sucesivamente. Los benecios de tal enfoque son que hace ms fcil hacer un seguimiento diario de las necesidades de almacenamiento (y uso) para cada parte de su organizacin. 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 fcil. Con la estructura apropiada, se incrementa la exibilidad. Para continuar utilizando el ejemplo ante rior, asuma por un momento que el departamento de ingeniera 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 suciente almacenamiento disponible para soportar las adiciones esperadas para ingeniera.
ingenieria, lo siguiente ser un proceso bien directo:

Sin embargo, puesto que cada persona en ingeniera tiene sus archivos almacenados bajo el directorio Obtener el espacio adicional necesario para ingeniera Respaldar todo bajo el directorio ingenieria
Captulo 5. Administracin del Almacenamiento Restaurar el respaldo a un nuevo almacenamiento
79
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 conguracin por un mes) Haga los cambios necesarios para que todo el personal de ingeniera pueda acceder a sus archivos en el nuevo almacenamiento
Por supuesto, tal enfoque tambin 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 modicar la estructura del directorio de la forma correspondiente. De lo contrario, la estructura ya no reejar la realidad, lo que signica ms 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 cmo se debe acceder al almacenamiento. El montaje del almacenamiento normalmente se hace a travs de un programa de utilidades especial o un comando y requiere que el dispositivo de almacenamiento masivo (y posiblemente la particin tambin) sea identicada explcitamente.
5.6. Tecnologas avanzadas de almacenamiento

Aunque todo lo que se ha presentado hasta ahora en este captulo solamente trata con discos duros nicos conectados directamente a un sistema, existen otras opciones ms avanzadas que explorar. Las secciones siguientes describen algunos de los enfoques ms comunes para extender sus opciones de almacenamiento masivo.
5.6.1. Almacenamiento accesible a travs de la red

Combinando redes con las tecnologas de almacenamiento masivo puede resultar en una exibilidad excelente para los administradores de sistemas. Con este tipo de conguracin se tienen dos benecios posibles:

Consolidacin del almacenamiento Administracin simplicada
El almacenamiento se puede consolidar implementando servidores de alto rendimiento con conex iones de red de alta velocidad y congurados con grandes cantidades de almacenamiento rpido. Con la conguracin apropiada, es posible suministrar acceso al almacenamiento a velocidades com parables al almacenamiento conectado directamente. Ms an, la naturaleza compartida de tal con guracin 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. Adems, el espacio libre est consolidado, en vez de espar cido (pero no utilizable globalmente) entre los clientes. Los servidores de almacenamiento centralizado tambin puede hacer muchas tareas administrativas ms fciles. Por ejemplo, monitorizar el espacio libre es mucho ms fcil cuando el almacenamiento
80
a supervisar existe en un slo servidor centralizado. Los respaldos tambin se pueden simplicar en gran medida usando un servidor de almacenamiento centralizado. Es posible hacer respaldos basados en la red para mltiples clientes, pero se requiere ms trabajo para congurar y mantener. Existen varias tecnologas disponibles de almacenamiento en red; seleccionar una puede ser compli cado. Casi todos los sistemas operativos en el mercado hoy da incluyen alguna forma de acceder a almacenamiento en red, pero las diferentes tecnologas son incompatibles entre ellas. Cul es el mejor enfoque para determinar la mejor tecnologa 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 mnimos de integracin de clientes Trabajo mnimo en cada sistema cliente Costos bajos de entrada por cliente
Tenga en cuenta que cualquier problema relacionado a clientes son multiplicados por el nmero de clientes en su organizacin. 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 adquisicin de software). Y tiene grandes posibilidades de soporte e integracin con el sistema operativo del cliente. Sin embargo, hay una desventaja. Esto signica que el entorno del servidor debe estar al nivel de la tarea de suministrar buen soporte para las tecnologas 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 ningn 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 ms que justicado.
5.6.2. Almacenamiento basado en RAID

Una habilidad que un administrador de sistemas debera cultivar es la dever las complejas congu raciones de sistemas y observar las diferentes limitaciones inherentes a cada conguracin. Mientras que esto, a primera vista, puede parecer un punto de vista deprimente a tomar, puede ser una forma excelente de ver ms all de las brillantes cajas nuevas y visualizar una futura noche del sbado con toda la produccin detenida debido a una falla que se podra haber evitado fcilmente 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 daada pueda ser reemplazada y los datos restaurados desde el respaldo ms actual). Un disco duro con una sola particin est operando en los lmites de su diseo debido a cargas de E/S masivas: qu le pasa a las aplicaciones que requieren acceso a los datos en esa particin? Las aplicaciones se vuelven ms lentas debido a que el disco duro no puede procesar lecturas y escrit uras ms rpido. Tiene un archivo de datos que poco a poco sigue creciendo en tamao; pronto ser ms grande que el disco ms grande disponible en su sistema. Qu pasa entonces? La unidad de disco se llena, el archivo de datos deja de crecer y su aplicacin asociada deja de fun cionar.
81
Cualquiera de estos problemas puede dejar su centro de datos intil, sin embargo los administradores de sistemas deben enfrentarse a este tipo de problemas todos los das. Qu se puede hacer? Afortunadamente, existe una tecnologa que puede resolver cada uno de estos problemas. El nombre de esta tecnologa es RAID. 5.6.2.1. Conceptos bsicos RAID es el acrnimo para Redundant Array of Independent Disks, Formacin de Discos Independi entes Redundantes8 . Como su nombre lo implica, RAID es una forma para que discos mltiples acten como si se tratasen de una sola unidad. Las tcnicas RAID primero fueron desarrolladas por investigadores en la Universidad de California, Berkeley a mitad de los 80. En ese tiempo, haba un gran separacin entre las unidades de disco de alto rendimiento utilizadas por las grandes instalaciones computacionales del momento, y las unidades de disco ms pequeas utilizadas por la joven industria de las computadoras personales. RAID se vea como el mtodo para tener varios discos menos costosos sustituyendo una unidad ms costosa. Ms an, las formaciones RAID se pueden construir de varias formas, resultando en caractersticas diferentes dependiendo de la conguracin nal. Vamos a ver las diferentes conguraciones (conoci das como niveles RAID) en ms detalles. 5.6.2.1.1. Niveles de RAID Los investigadores de Berkeley originalmente denieron cinco niveles RAID y los nombraron del "1" al "5." Luego, otros investigadores y miembros de la industria del almacenamiento denieron niveles RAID adicionales. No todos los niveles RAID eran igualmente tiles; algunos eran de inters solamente para propsitos de investigacin y otros no se podan implementar de una forma econmica. Al nal, haban 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 ms detalles. 5.6.2.1.1.1. RAID 0 La conguracin 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, an cuando RAID 0 no tiene ventajas con respecto a su conabilidad, si tiene otros benecios. Una formacin RAID 0 consiste de dos o ms unidades de disco. La capacidad del almacenamiento en cada disco se divide en pedazos, los cuales representan algn mltiplo del tamao de bloque nativo del disco. Los datos escritos a la formacin se escriben, pedazo a pedazo, en cada unidad de la formacin. Los pedazos se pueden ver como tiras o rayas que se van juntando a lo largo de cada unidad en la formacin; de all el otro nombre con el que se conoce a RAID 0: striping. Por ejemplo, con una formacin de dos discos y un tamao de pedazos de 4KB, el escribir 12KB de datos a la formacin, produce que los datos se escriban en tres pedazos de 4KB a las unidades siguientes:
8. Cuando comenzaron las primeras investigaciones de RAID, el acrnimo vena de Redundant Array of Inex
pensive Disks, pero con el paso del tiempo los discos "independientes" que RAID pretenda sustituir se volvieron ms y ms econmicos, dejando la cuestin del costo un poco sin sentido.
82
Captulo 5. Administracin del Almacenamiento 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:

Tamao total ms grande - RAID 0 se puede construir de manera que es ms grande que un nico disco, haciendo ms fcil el almacenamiento de grandes archivos. Mejor rendimiento de lecturas/escrituras - Las cargas por E/S en una formacin RAID 0 se pueden distribuir uniformemente entre todas las unidades en la formacin (asumiendo que todas las E/S no estn concentradas en un nico pedazo) No se desperdicia espacio - Todo el almacenamiento en todas las unidades en la formacin estn disponibles para almacenamiento de datos
Comparado con un disco sencillo, RAID 0 tiene las siguientes desventajas:

Menos conable - Cada disco en un RAID 0 debe estar operativo para que la formacin est disponible; una falla en un disco-N de RAID 0 resulta en la eliminacin de 1/N avo de todos los datos, dejando la formacin 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 ms) unidades de disco idnticas. Todos los datos son escritos a ambas unidades, haciendolos imgenes espejo. Por eso es que RAID 1 a menudo se conoce como mirroring. Cuando los datos son escritos a una formacin RAID 1, deben efectuarse dos escrituras fsicas si multneas: 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 formacin RAID 1 tiene las ventajas siguientes:

Redundancia mejorada - An si uno de los discos falla, los datos todava estarn 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 slo disco de duro, una formacin RAID 1 tiene algunas desventajas:

El tamao mximo de la formacin est limitado a la unidad ms 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 ms lento el proceso general de escribir datos a la formacin Eciencia de costos reducida - Con un disco completo dedicado a la redundancia, el costo de una formacin RAID 1 es al menos el doble de lo que costara un slo disco
83
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 benecios de RAID 0 y RAID 1, a la vez que trata de minimizar sus desventajas. Igual que RAID 0, un RAID 5 consiste de mltiples unidades de disco, cada una dividida en pedazos. Esto permite a una formacin RAID 5 ser ms grande que una unidad individual. Como en RAID 1, una formacin RAID 5 utiliza algo de espacio en disco para alguna forma de redundancia, mejorando as la conabilidad. Sin embargo, la forma en que RAID 5 funciona es diferente a RAID 0 o 1. Una formacin RAID 5 debe consistir de al menos tres discos idnticos en tamao (aunque se pueden utilizar ms 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 formacin con n unidades en ella, el ensimo pedazo est dedicado a la paridad . Los pedazos que contienen paridad hacen posible recuperar los datos si falla una de las unidades en la formacin. La paridad en el pedazo x se calcula matemticamente combinando los datos desde cada pedazo x almacenado en todas las otras unidades en la formacin. Si los datos en un pedazo son actualizados, el correspondiente pedazo de paridad debe ser recalculado y actualizado tambin. Esto tambin signica que cada vez que se escriben datos en la formacin, 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 estn concentrados en una sola unidad de la formacin. En cambio, estn distribuidos uniformemente a lo largo de todas las unidades. An cuando es posible dedicar una unidad especca para que contenga nicamente paridad (de hecho, esta conguracin se conoce como RAID nivel 4), la actualizacin constante de la paridad a medida que se escriben datos a la formacin signica que la unidad de paridad se podra convertir en un cuello de botella. Distribuyendo la informacin de paridad uniformemente a travs de la formacin, se reduce este impacto. Sin embargo, es importante recordar el impacto de la paridad en la capacidad general de almace namiento de la formacin. An cuando la informacin de paridad se distribuye uniformemente a lo largo de todos los discos, la cantidad de almacenamiento disponible se reduce por el tamao de un disco. Comparado con un nico disco, una formacin RAID 5 tiene las ventajas siguientes:

Redundancia mejorada - Si falla una unidad de la formacin, se puede utilizar la informacin de paridad para reconstruir las partes de datos faltantes, todo esto mientras se mantiene la formacin 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 formacin, la actividad de E/S de distribuye uniformemente entre todos los discos Costo eciencia razonablemente buena - Para una formacin RAID 5 de n unidades, solamente 1/navo del total de almacenamiento disponible est dedicado a la redundancia
Se reduce el rendimiento de E/S cuando se est funcionando con una unidad faltante debido a la sobrecarga
9.
generada en reconstruir los datos faltantes.
84
Comparado con un slo disco, una formacin RAID 5 tiene las siguientes desventajas:

Rendimiento de escritura reducido - Puesto que cada escritura a la formacin resulta en al menos dos escrituras a los discos fsicos (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 debera ser obvio a partir de la discusin sobre los diferentes niveles de RAID, cada nivel tiene sus fortalezas y debilidades especcas. No fue mucho tiempo despus de que se comenz a implementar el almacenamiento basado en RAID que la gente comenz a preguntarse si los diferentes niveles RAID se podran 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 formacin RAID 0 fuesen en verdad formaciones RAID 1? Esto proporcionara las ventajas de la velocidad de RAID 0, con la conabilidad de un RAID 1. Este es el tipo de cosas que se pueden hacer. He aqu los niveles de RAID ms comunes:

RAID 1+0 RAID 5+0 RAID 5+1
Debido a que los RAID anidados se utilizan en ambientes ms especializados, no nos vamos a ir en ms 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 conabilidad. En otras palabras, RAID 1+0 and RAID 0+1 no son lo mismo. Los costos pueden ser altos - Si hay alguna desventaja comn a todas las implementaciones RAID, es el costo; por ejemplo, la formacin RAID 5+1 ms pequea posible, consiste de seis discos (y se requieren hasta ms discos para formaciones ms grandes).
Ahora que ya hemos explorado los conceptos detrs de RAID, vamos a ver cmo 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 mnimo, se deben llevar a cabo las tareas siguientes:

Dividir las peticiones de E/S entrantes a los discos individuales de la formacin Para RAID 5, calcular la paridad y escribirla al disco apropiado en la formacin Supervisar los discos individuales en la formacin y tomar las acciones apropiadas si alguno falla Controlar la reconstruccin de un disco individual en la formacin, cuando ese disco haya sido reemplazado o reparado
10. Tambin existe un impacto por los clculos de paridad requeridos por cada escritura. Sin embargo, dependi endo de la implementacin de RAID 5 especca (especcamente, dnde se realizan los clculos de paridad en el sistema), este impacto puede variar desde muy grandes a inexistentes.
85
Proporcionar los medios para permitir a los administradores que mantengan la formacin (elimi nando y aadiendo discos, iniciando y deteniendo reconstrucciones, etc.)
Hay dos mtodos principales que se pueden utilizar para lograr estas tareas. Las prximas dos sec ciones las describen en ms detalles. 5.6.2.1.2.1. Hardware RAID Una implementacin 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 antrin como si se tratasen de unidades de disco normales. La mayora de las tarjetas controladoras RAID trabajan con SCSI, aunque hay algunos controladores RAID basados en ATA tambin. En cualquier caso, la interfaz administrativa se implementa usual mente en una de tres formas:

Programas de utileras especializados que funcionan como aplicaciones bajo el sistema operativo antrin, 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 ms de un tipo de interfaz administrativa disponible. Por razones obvias, una interfaz de software suministra la mayor exibilidad, 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 ejecucin. Puesto que existen muchas tarjetas controladoras RAID en el mercado, es imposible ir en ms detalles aqu. Lo mejor a hacer en estos casos es leer la documentacin del fabricante para ms informacin. 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 ms exibilidad en trminos de soporte de hardware - siempre y cuando el sistema operativo soporte ese hardware, se pueden congurar e implementar las formaciones RAID. Esto puede reducir dramticamente 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 clculos 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 estn presentes en hardware RAID. La ms importante a considerar es el soporte para el arranque desde una formacin de software RAID. En la mayora 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 formacin RAID 1 de un dispositivo de arranque no RAID, el BIOS puede iniciar exitsamente el proceso de arranque; luego el sistema operativo puede cambiarse a la operacin desde el software RAID una vez que haya obtenido el control sobre el sistema.
86
5.6.3. Administracin de Volmenes Lgicos

Otra tecnologa de almacenamiento avanzada es administracin de volmenes lgicos o logical vol ume management (LVM). LVM hace posible tratar a los dispositivos fsicos de almacenamiento ma sivo como bloques de construccin a bajo nivel en los que se construyen diferentes conguraciones de almacenamiento. Las capacidades exactas varan de acuerdo a la implementacin especca, pero pueden incluir la agrupacin del almacenamiento fsico, redimensionamiento de volmenes lgicos y la migracin de datos. 5.6.3.1. Agrupamiento de almacenamiento fsico Aunque los nombres dados a esta capacidad pueden variar, la agrupacin del almacenamiento fsico es la base para todas las implementaciones de LVM. Como su nombre lo implica, los dispositivos fsicos de almacenamiento masivo se pueden agrupar de forma tal para crear uno o ms dispositivos lgi cos de almacenamiento. Los dispositivos lgicos de almacenamiento masivo (o volmenes lgicos) pueden ser ms grandes en capacidad que cualquiera de los dispositivos fsicos de almacenamiento subyacentes. Por ejemplo, dadas dos unidades de 100GB, se puede crear un volumen lgico de 200GB. Sin em bargo, tambin se pueden crear un volumen lgico de 150GB y otro de 50GB. Es posible cualquier combinacin de volmenes lgicos igual o menor que la capacidad total (en nuestro ejemplo 200GB). Las posibilidades estn limitadas solamente a las necesidades de su organizacin. Esto hace posible que un administrador de sistemas trate a todo el almacenamiento como un slo parque de recursos de almacenamiento, disponible para ser utilizado en cualquier cantidad. Adems, posteriormente se pueden aadir unidades a ese parque, hacindo un proceso directo el mantenerse al da con las demandas de almacenamiento de sus usuarios. 5.6.3.2. Redimensionamiento de volmenes lgicos La caracterstica que la mayora de los administradores de sistemas aprecian ms sobre LVM es su habilidad para dirigir fcilmente el almacenamiento donde se necesite. En una conguracin de sis temas no LVM, el quedarse sin espacio signica - en el mejor de los casos - mover archivos desde un dispositivo lleno a uno con espacio disponible. A menudo esto signica la reconguracin de sus dispositivos de almacenamiento masivo; una tarea que se debe llevar a cabo despus del horario de ocina. Sin embargo, LVM hace posible incrementar fcilmente el tamao de un volumen lgico. Asuma por un momento que nuestro parque de almacenamiento de 200GB fue utilizado para crear un volumen lgico de 150GB, dejando el resto de 50GB en reserva. Si el volumen lgico de 150GB se llena, LVM permite incrementar su tamao (digamos por 10GB) sin ninguna reconguracin fsica. Dependiendo del entorno de su sistema operativo, se puede hacer esto dinmicamente o quizs requiera una pequea cantidad de tiempo fuera de servicio para llevar a cabo el redimensionamiento. 5.6.3.3. Migracin de datos La mayora de los administradores con experiencia estaran impresionados de las capacidades de LVM, pero tambin se preguntaran: Qu pasa si uno de los discos que forman parte del volumen lgico comienza a fallar? Las buenas noticias es que la mayora de las implementaciones LVM incluyen la habilidad de migrar datos fuera de una unidad fsica particular. Para que esto funcione, debe existir suciente capacidad para absorber la prdida de la unidad fallida. Una vez que se termine la migracin, se puede reemplazar la unidad que dej de funcionar y aadirla nuevamente en el parque de almacenamiento disponible.
Captulo 5. Administracin del Almacenamiento 5.6.3.4. Con LVM, Por qu utilizar RAID?
87
Dado que LVM tiene algunas funcionalidades similares a RAID (la habilidad de reemplazar dinmi camente unidades fallidas, por ejemplo) y algunas funcionalidades proporcionan capacidades que no se pueden comparar con la mayora de las implementaciones RAID (tales como la habilidad de aadir dinmicamente ms almacenamiento a un parque central de almacenamiento), mucha gente se pre gunta si ya RAID no es tan importante. Nada puede estar ms lejos de la realidad. RAID y LVM son tecnologas 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 administracin del almacenamiento da a da

Los administradores del sistema deben prestar atencin 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 Aadir/Eliminar almacenamiento
Las secciones siguientes discuten cada uno de estos problemas con ms detalles.
5.7.1. Monitorizar el espacio libre

Asegurarse de que se dispone de suciente espacio para el almacenamiento debera estar en el tope de la lista de tareas diarias de un administrador de sistemas. La razn por la que la vericacin frecuente de espacio disponible es tan importante es porque el espacio libre es muy dinmico; en un minuto puede haber ms que suciente espacio y al minuto siguiente casi nada. En general, hay tres razones para espacio insuciente en disco:

Uso excesivo de parte del usuario Uso excesivo de una aplicacin Crecimiento normal en uso
Estas razones se exploran en ms detalles en las secciones siguientes.

5.7.1.1. Uso excesivo de parte de un usuario Algunas personas son ms ordenadas que otras. Unos estaran horrorizados de ver un poco de polvo sobre sus escritorios, mientras que para otros ni siquiera pensaran dos veces sobre la coleccin de cajas de pizza del ao 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.
88
Captulo 5. Administracin del Almacenamiento 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 ms difcil su trabajo (o imposible), que las restricciones son ridculamente pequeas o que sencillamente no tienen tiempo para limpiar sus archivos. El mejor administrador de sistemas debe tomar en cuenta muchos factores en una situacin 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 electrnicos con ms de un ao de antigedad, por ejemplo)? Su trabajo durante esta conversacin 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 conversacin 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 utilizacin promedio es la mitad de la suya.") a la vez que lleva la conversacin hacia el punto. Asegurese de ofrecer asistencia si la falta de conocimiento/experiencia parece ser un problema. Enfocar esta situacin de una manera consciente pero rme 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 cheros de archivos Abandonar
Quizs el usuario puede reducir su utilizacin si se le concede cierta cantidad de espacio temporal que pueda utilizar sin restriccin. La gente a menudo aprovecha esta situacin pues les permite trabajar sin preocuparse sobre el espacio hasta que lleguen a un punto lgico, y en ese momento hacer un poco de mantenimiento y determinar qu archivos en el almacenamiento temporal realmente necesitan y cuales no.
Atencin Si le presenta esta situacin 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 retencin de datos; nunca se hacen respaldos de ningn tipo en espacio temporal. De hecho, muchos administradores a menudo no aprecian este hecho, eliminando automticamente 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 contnuo a ellos. Asegrese de que este es el caso. Algunas veces ciertos usuarios individuales son responsables de mantener datos en archivo; en tales circunstancias, usted
89
debera asistirlos en la tarea de proporcionarles mltiples 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, quizs 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, explicndole 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 organizacin lo que sea apropiado de acuerdo a su organizacin) 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 restauracin si alguien se lo solicita. Esto signica que la media de respaldo debera ser de algn tipo que ser utilizada por cierto tiempo en su centro de datos.
Sugerencia Su seleccin de la media tambin debera tomar en cuenta aquellas tecnologas que pueden permitir al usuario manejar la restauracin ellos mismos. Por ejemplo, an cuando respaldar varios gigabytes en una media de CD-R es mucho ms trabajo que ejecutar un slo comando y montarlo en un cartucho de cinta de 20GB, considere el hecho de que el usuario podr luego acceder fcilmente a su CD-R cuando lo desee sin molestarlo a usted.
5.7.1.2. Uso excesivo de parte de una aplicacin Algunas veces una aplicacin es responsable por uso excesivo. Las razones para esto pueden variar, pero pueden incluir:

Mejoras en la funcionalidad de la aplicacin que requieren mayor almacenamiento Un incremento en el nmero de usuarios usando la aplicacin La aplicacin falla en limpiar las cosas luego de su ejecucin, dejando archivos temporales que ya no se necesitan en el disco La aplicacin tiene problemas y el fallo que est causando esto utiliza ms espacio del que debera
Su tarea es determinar cules de estas razones de la lista aplican a su situacin. Tener presente el estado de las aplicaciones utilizadas en su centro de datos debera ayudarle a eliminar varias de estas razones, as como tambin su conocimiento de los hbitos 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 debera reducir el campo substancialmente. En este punto debe tomar los pasos apropiados, bien sea la adicin de almacenamiento para soportar la aplicacin, ponerse en contacto con los desarrolladores de la aplicacin para discutir sus caracters ticas de manejo de archivos o escribir scripts para limpiar las cosas de la aplicacin. 5.7.1.3. Crecimiento normal en uso La mayora de las organizaciones experimentan algn nivel de crecimiento a largo plazo. Debido a esto, es normal esperar que la utilizacin del almacenamiento se incremente a un ritmo similar. En casi todos los casos, la supervisin contnua puede revelar la tasa promedio de utilizacin del almace namiento en su organizacin; esta tasa puede ser usada posteriormente para determinar el tiempo en el cual se debera obtener almacenamiento adicional antes de que su espacio libre se termine.
90
Si se encuentra en la posicin de que repentinamente se le acaba el espacio libre debido a un crec imiento normal, entonces usted no ha estado haciendo su trabajo como debera ser. Sin embargo, algunas veces pueden surgir repentinamente grandes demandas de espacio adicional. Quizs su organizacin se haya combinado con otra, necesitando cambios rpidos 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 maana. Cambios a una aplicacin existente pueden producir un gran incremento en las necesidades de almacenamiento. No importa cul sea la razn, habr ocasiones en que lo tomen por sorpresa. Para planear estas situa ciones, trate de congurar su arquitectura de almacenamiento para un mximo de exibilidad. El tener espacio de almacenamiento adicional a mano (si es posible) puede aliviar el impacto de estos eventos espontneos.
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, tambin ayuda a ver el problema de espacio en disco desde otra perspectiva. Qu hay de las aplica ciones que, por una razn 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 dao causado por tales aplicaciones errticas, forzndolas a detenerse antes de consumir todo el espacio en el disco. La parte ms difcil de implementar y manejar cuotas de disco est relacionada con los lmites mismos. Cul debera ser? Un enfoque simplstico sera dividir el espacio en disco por el nmero de usuarios y/o grupos que lo utilizan y utilizar el nmero resultante como la cuota por usuario. Por ejemplo, si el sistema tiene una unidad de disco de 100GB y 20 usuarios, cada usuario tendra una cuota de 5GB. De esta forma, cada usuario tendr garantizado 5GB(aunque en este punto el disco estara a un 100%). Para aquellos sistemas operativos que lo soportan, las cuotas temporales se podran congurar un poco ms altas digamos 7.5GB, dejando la la cuota permanente en 5GB. Esto tiene el benecio 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 exibilidad cuando el usuario alcanza (y excede) su lmite. Cuando se utilicen cuotas de esta forma, usted en realidad est comprometiendo su disco ms 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 deberan en realidad ser 150GB para poder permitir a todos alcanzar su cuota temporal al mismo tiempo. No obstante, en prctica nadie excede su cuota permanente al mismo tiempo, haciendo que este sea un enfoque aceptable. Por supuesto, la seleccin 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 tpicamente giran alrededor de un escenario un usuario que no puede acceder a un archivo al cual el cree que debera tener acceso.
91
A menudo este es el caso de usuario#1 que desea dar una copia del archivo al usuario#2. En la mayora de las organizaciones, la habilidad de un usuario de acceder a los archivos de otro es estrctamente 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 propsitos; 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 electrnico para darle una copia del archivo al usuario#2.
Hay un problema con este primer enfoque -dependiendo de cmo 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 organizacin tienen acceso a los archivos del usuario#1. Peor an, puede que no se revierta el cambio despus 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 estn a cargo de este tipo de situacin, 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 quizs de puede modicar) 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 solucin extraa, quizs sea la preferible de la mayora de los casos. Con el advenimiento de protocolos de anexos de correo electrnico y programas de correo ms inteligentes, el envio de todo tipo de archivos a travs del correo electrnico es una operacin 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 nanzas, por lo tanto es prudente llevar a cabo un poco de educacin para sus usuarios (y posiblemente colocar limitaciones en el tamao de los archivos anexos). Sin embargo, ninguno de estos enfoques resuelve la situacin en la que dos o ms usuarios necesiten acceso saliente a un mismo archivo. En estos casos, se requieren otros mtodos. 5.7.3.2. Compartir archivos Cuando mltiples usuarios necesitan compartir una misma copia de un archivo, permitir el acceso mediante la modicacin de los permisos de usuarios no es la mejor solucin. 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 organizacin o hace algo tan sencillo como reorganizar sus archivos. Mantener el acceso compartido para ms de uno o dos usuarios adicionales se vuelve difcil, 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 solucin 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 dueo Hacer que todos los usuarios que necesiten acceder al archivo sean parte del grupo
92
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. Aadir/Eliminar almacenamiento

Debido a que la necesidad de espacio adicional nunca termina, el administrador de sistemas con frecuencia se encontrar en la situacin de aadir espacio en disco y otras veces tendr que eliminar unidades ms viejas o pequeas. Esta seccin proporciona una descripcin general del proceso bsico para aadir o remover almacenamiento.
Nota En muchos sistemas operativos, los dispositivos de almacenamiento masivo son nombrados de acuerdo a su conexin fsica al sistema. Por lo tanto, aadir o eliminar dispositivos de almacenamiento 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) todas las referencias a nombres de dispositivos utilizados por su sistema operativo.
5.7.4.1. Aadir almacenamiento El proceso de aadir espacio de almacenamiento a un sistema computacional es relativamente directo. He aqu los pasos bsicos: 1. Instalar el hardware 2. Particionar 3. Formatear la particin(es) 4. Actualizar la conguracin del sistema 5. Modicar la planicacin de los respaldos Las secciones siguientes detallan cada paso. 5.7.4.1.1. Instalacin del hardware Antes de que se pueda hacer nada, el nuevo disco debe estar colocado y accesible. Aunque hay muchas conguraciones de hardware posibles, las secciones siguientes mencionan las dos situaciones ms comunes - aadir una unidad de disco ATA o SCSI. An con otras conguraciones, los pasos bsicos que aqu se describen tambin se aplican.
Sugerencia No importa qu tipo de hardware utilice, siempre debe considerar la carga que un nuevo disco aade al subsistema de E/S de su computador. En general, debera 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 vaco y ocioso.
Captulo 5. Administracin del Almacenamiento 5.7.4.1.1.1. Aadir discos duros ATA
93
Las unidades de disco ATA se utilizan principalmente en escritorios y sistemas servidores ms pe queos. Casi todos los sistemas en estas clases tienen controladores ATA incorporados con mltiples canales ATA normalmente dos o cuatro. Cada canal puede soportar dos dispositivos uno maestro y otro esclavo. Los dos dispositivos estn 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 situacin es usualmente la ms fcil, 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 estn compar tiendo el canal estn correctamente congurados (uno como maestro y otro como esclavo). La segunda situacin es un poco ms complicada, pues se debe obtener un cable para conectar un disco duro al canal. El nuevo disco puede ser congurado como maestro o esclavo (aunque tradicionalmente el primer disco en un canal es congurado normalmente como maestro). En la tercera situacin, no hay espacio disponible para un disco adicional. Entonces tiene que tomar una decisin. Usted:

Compra una tarjeta controladora ATA y la instala Reemplaza uno de los discos instalados con uno nuevo ms grande
Aadir una tarjeta controladora implica vericar la compatibilidad del hardware, la capacidad fsica y la compatibilidad del software. Bsicamente, 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 despus de instalar el nuevo disco duro Utilizar su red para copiar los datos a otro sistema con espacio suciente, restaurando los datos despus de instalar el nuevo disco duro Utilizar el espacio ocupado fsicamente por un tercer disco duro mediante: 1. La eliminacin 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. Reemplazndolo 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
94
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. Aadir 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) tambin varan enorme mente. Puede venir con un bus SCSI angosto o amplio. La velocidad del bus puede ser normal, rpida, ultra, ultra2 o ultra160. Si estos trminos no le parecen familiares (se discutieron brevemente en la Seccin 5.3.2.2), debe determinar las capacidades de la conguracin de su hardware y seleccionar un nuevo disco que sea apropiado. La mejor fuente para esta informacin sera la documentacin de su sistema y/o su adaptador SCSI. Debe determinar cuntos buses SCSI estn disponibles en su sistema y cules de estos tienen espacio disponible para una nueva unidad de disco. El nmero de dispositivos soportados por un bus SCSI vara de acuerdo al ancho del bus:

Bus SCSI delgado (8-bit) 7 dispositivos (ms controlador) Bus SCSI ancho (16-bit) 15 dispositivos (ms controlador)
El primer paso es ver cules buses tienen espacio disponible para una unidad de disco adicional. Es posible una de las tres situaciones siguientes:

Hay un bus con menos del mximo nmero de unidades de disco conectadas a el Hay un bus sin unidades de disco conectadas No hay espacio disponible en ningn bus
La primera situacin usualmente es la ms fcil, pues es probable que el cable tenga un conector sin utilizar en el cual se podra 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 ms. La segunda situacin es un poco ms 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 decisin. Usted:

Compra e instala una tarjeta controladora SCSI Reemplaza una de las unidades de disco instaladas por una nueva, ms grande
Aadir una tarjeta controladora implica vericar la compatibilidad del hardware, la capacidad fsica y la compatibilidad del software. Bsicamente, 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 despus de instalar la nueva unidad de disco Utilizar su red para copiar los datos a otro sistema con espacio libre suciente y restaurarlos despus de instalar la nueva unidad de disco Utilizar el espacio ocupado fsicamente por un tercer disco duro mediante:
Captulo 5. Administracin del Almacenamiento 1. La eliminacin 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. Reemplazndolo con el nuevo disco 6. Reinstalando el tercer dico duro que ha sido temporalmente eliminado

95
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 congurado correctamente. Para hacer esto, debe saber qu estn usando todos los otros dispositivos en el bus (incluyendo el controlador) para sus IDs SCSI. La forma ms fcil de hacer esto es acceder al BIOS del controlador SCSI. Esto normalmente se hace presionando una secuencia de teclas especcas durante la secuencia de inicio del sistema. Puede entonces ver la conguracin de la controladora SCSI, junto con todos los dispositivos conectados a sus buses. Luego, debe considerar la terminacin de los buses. Cuando se aade 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 terminacin activada. De lo contrario, se debe desactivar la terminacin. 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 ms particiones para colocar el espacio disponible a su sistema operativo. Aunque las herramientas varan dependiendo del sistema operativo, los pasos bsicos 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 particin no deseada que pueda estar presente en su nueva unidad de disco 4. Cree la(s) nueva(s) particin(es), asegurandose de especicar el tamao deseado y el tipo de particin 5. Guarde sus cambios y salga del programa de particionamiento
Atencin 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 resultara en la prdida de los datos. Tambin verique que ha decidido el mejor tamao para su particin. Siempre tome este punto seriamente, pues cambiarlo ms adelante es mucho ms difcil que tomarse un poco de tiempo ahora en pensar las cosas.
96 5.7.4.1.3. Formatear la particin
En este punto, la nueva unidad de disco tiene una o ms 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 especco a utilizar dentro de cada par ticin. Como tal, este es un momento crucial en la vida de una unidad de disco; las selecciones que haga ahora no se pueden cambiar despus sin pasar por una buena cantidad de trabajo. El proceso actual de formatear la particin se hace ejecutando un programa de utilidades; los pasos relacionados en esto varan de acuerdo al sistema operativo. Una vez que se termine el formateo, la unidad de disco estarcongurada correctamente para su uso. Antes de continuar, es mejor volver a vericar su trabajo accediendo a la particin y asegurndose de que todo est en orden. 5.7.4.1.4. Actualizar la conguracin del sistema Si su sistema operativo requiere cualquier cambio en la conguracin 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 congurado correcta mente para colocar el nuevo almacenamiento accesible cada vez que el sistema arranca (aunque si se puede dar el lujo de reiniciar, valdra la pena hacerlo simplemente para estar seguros). Las prximas secciones exploran uno de los pasos ms comunmente olvidados en el proceso de aadir nuevo almacenamiento. 5.7.4.1.5. Modicar la planicacin 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 cul debera ser la frecuencia de respaldos ptima Determine el estilo de respaldo ms 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 podra causar que los respaldos demoren demasiado y comiencen a utilizar tiempo fuera de la ventana de tiempo asignada para el respaldo Asegrese 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 mayora de los pasos siendo similares a la secuencia de instalacin (excepto, por supuesto a la inversa): 1. Coloque calquier dato a guardar fuera del disco
97
2. Modique la planicacin del respaldo para que no se contine respaldando esa unidad de disco 3. Actualice la conguracin 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 instalacin, 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 dnde deben ir estos datos. Esta decisin depende principalmente en lo que se har con los datos. Por ejemplo, si los datos ya no se utilizan actvamente, entoces se deberan archivar, probablemente de la misma forma que sus respaldos de sistemas. Esto signica que ahora es el momento para considerar los perodos de retencin apropiados para este respaldo nal.
Sugerencia Tenga en cuenta que, adems de cualquier pauta de retencin de datos que su organizacin pueda tener, probablemente tambin existan ciertos requerimientos legales para mantener los datos por cierto perodo de tiempo. Por lo tanto, asegrese de consultar con el departamento que haya sido responsable por los datos mientras estos se encontraban en uso; ellos deberan saber cul es el perodo de retencin adecuado.
Por otro lado, si todava los datos estn siendo utilizados, entonces se deberan dejar en el sistema ms apropiado para su uso. Por supuesto, si este es el caso, quizs sera ms fcil mover los datos reinstalando la unidad de disco en el nuevo sistema. Si hace esto, debera 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 travs 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 razn obvia para hacer esto es asegurarse de no dejar informacin condencial en el disco, tambin es una buena idea vericar la salud del disco haciendo una prueba de lectura-escritura para bloques daados en el disco completo.
Importante Muchas compaas (y agencias del gobierno) tienen mtodos especcos de borrar datos desde sus unidades de disco y otras medias de almacenamiento. Siempre debera asegurarse de que entiende y sigue estos requerimientos; en muchos casos hay consecuencias legales si no las sigue. El ejemplo de arriba no se debera de considerar el mtodo perfecto para limpiar una unidad de disco. Adems, las organizaciones que trabajan con datos clasicados quizs tengan procedimientos legales particulares con respecto a la disposicin nal de la unidad (tal como la destruccin fsica de la unidad). En estos casos, el departamento de seguridad de su organizacin debera de indicarle las pautas en esta materia.
98
5.8. Un comentario sobre Respaldos

Una de los factores ms importantes cuando se considera el almacenamiento de discos es sobre los respaldos. Esta materia no se cubre aqu puesto que hay una seccin detallada (Seccin 8.2) dedicada a los respaldos.
5.9. Documentacin especca a Red Hat Enterprise Linux

Dependiendo de su experiencia pasada en administracin de sistemas, el manejo del almacenamiento bajo Red Hat Enterprise Linux es bien sea muy comn o totalmente extrao. Esta seccin discute aspectos de la administracin del almacenamiento especca 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 varan 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 conguracin 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 conguracin 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 cmo se ha congurado. Los puntos importantes son como sigue:

Tipo de dispositivo Unidad Particin
5.9.1.1.1. Tipo de dispositivo Las primeras dos letras del nombre de archivo de un dispositivo se reeren al tipo especco del dispositivo. Para las unidades de disco, hay dos tipos de dispositivos que son los ms comunes:
sd hd
El dispositivo est basado en SCSI El dispositivo est basado en ATA
Se puede encontrar ms informacin sobre ATA y SCSI en la Seccin 5.3.2.
Captulo 5. Administracin del Almacenamiento 5.9.1.1.2. Unidad
99
Siguiendo las dos letras para el tipo de dispositivo estn una o dos letras que denotan la unidad especca. 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 nmeros de dispositivos necesitaba la adicin de un segundo carcter de unidad para soportar sistemas con ms de 26 dispositivos SCSI conectados. Por lo tanto, los primeros 26 discos duros SCSI en un sistema seran llamados sda hasta sdz, los prximos 26 se llamarn sdaa hasta sdaz y as sucesivamente.
5.9.1.1.3. Particin La parte nal del nombre de dispositivo es un nmero que representa una particin especca en el dispositivo, comenzando con "1". El nmero puede ser de uno o dos dgitos de largo, dependiendo del nmero de particiones escritas en el dispositivo especco. Una vez que se conoce el formato para los nombres de dispositivos, es fcil entender a cual se reere cada uno. He aqu algunos ejemplos:
/dev/hda1
La primera particin en la primera unidad ATA La doceava particin en la segunda unidad SCSI La cuarta particin en la trigsima unidad SCSI
/dev/sdb12 /dev/sdad4
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 cin. Esto normalmente se hace cuando el dispositivo no est particionado o no soporta particiones estndar (tales como una unidad de CD-ROM). En tales casos, se omite el nmero de la particin:
/dev/hdc /dev/sdb
El tercer dispositivo ATA completo El segundo dispositivo SCSI completo
Sin embargo, la mayora de las unidades de disco utilizan particiones (se puede encontrar ms infor macin sobre el particionamiento bajo Red Hat Enterprise Linux en la Seccin 5.9.6.1).
5.9.1.2. Alternativas a nombres de archivos de dispositivos Debido a que aadir 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 aade un nuevo controlador SCSI para que se puedan aadir 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
100
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 teora, esto suena como un problema terrible. Sin embargo, en prctica raramente lo es. Raramente es un problema por varias razones. Primero, las reconguraciones 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 ms tiempo del estipulado. Esta planicacin tiene el benecio adicional de traer a la supercie cualquier problema relacionado a cambios de nombres de dispositivos. No obstante, algunas organizaciones y conguraciones de sistemas son ms propensas a encon trarse con este problema. Las organizaciones que requieren reconguraciones frecuentes del alma cenamiento para satisfacer sus necesidades, a menudo usan hardware que sea capaz de recongurarse sin necesitar tiempo fuera de servicio. Este tipo de hardware de conexin en caliente hace fcil aadir o eliminar almacenamiento. 5.9.1.2.1. Etiquetas de sistemas de archivos Algunos sistemas de archivos (que se discuten con ms detalles en la Seccin 5.9.2) tienen la ha bilidad de almacenar una etiqueta una cadena de carcteres que se puede utilizar para identicar unvocamente 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 algn momento existe ms de un sistema de archivos con la misma etiqueta, quizs no pueda acceder al sistema de archivos. Tambin tenga en consideracin que las conguraciones 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 conexin en caliente). Cuando se ejecuta devlabel, este lee el archivo de conguracin (/etc/sysconfig/devlabel) para obtener la lista de dispositivos de los que es responsable. Para cada dispositivo en la lista, hay un enlace simblico (seleccionado por el administrador del sistema) y el UUID (Universal Unique IDentier) del dispositivo. El comando devlabel se asegura de que el enlace simblico siempre se reere al dispositivo original especicado an si ese nombre de dispositivo ha cambiado. De esta forma, un administrador de sistemas puede congurar un sistema para que se reera 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 simblico como sea apropiado. Para ms informacin sobre devlabel, consulte el Manual de administracin del sistema de Red Hat Enterprise Linux.
5.9.2. Conceptos bsicos de sistemas de archivos

Red Hat Enterprise Linux incluye soporte para muchos sistemas de archivos populares, haciendo posible acceder fcilmente a los sistemas de archivos de otros sistemas operativos.
101
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 ms detalles los sistemas de archivos ms populares. 5.9.2.1. EXT2 Hasta no hace mucho tiempo atrs, el sistema de archivos ext2 era el estndar para Linux. Como tal, ha recibido pruebas extensivas y se considera uno de los sistemas de archivos ms robustos de hoy. Sin embargo, no existe un sistema de archivo perfecto y ext2 no es la excepcin. Un problema infor mado con frecuencia es que el sistema de archivos ext2 debe pasar por una inspeccin 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 ms grandes, implica que las vericaciones de integridad estaban tomando ms y ms tiempo. Era necesario hacer algo. La prxima seccin 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 aadiendo las capacidades de journaling o de mantener un "diario" o journal al cdigo 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 vericaciones de integridad. Esto se logra escribiendo todos los cambios al sistema de archivos a un diario en disco, el cual es vaciado regularmente. Despus de un evento inesperado del sistema (tal como una falla de poder o una cada del sistema), la nica operacin que se necesita hacer antes de colocar el sistema de archivos disponible, es procesar los contenidos del diario; en la mayora 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 benecio de journal ing). Esto puede ser un gran benecio en organizaciones donde algunos sistemas estn usando ext3 y algunos todava utilizan ext2. 5.9.2.3. ISO 9660 En 1987, la International Organization for Standardization (conocida como ISO) lanz el estndar 9660. ISO 9660 dene cmo se representan los archivos en los CD-ROMs. Los administradores de sistemas Red Hat Enterprise Linux probablemente vern datos formateados para ISO 9660 en dos lugares:
CD-ROMs
102
Los archivos (usualmente llamados imgenes ISO) conteniendo sistemas de archivos completos ISO 9660, supuestamente estn para ser escritos en una media de CD-R o de CD-RW.
El estndar bsico ISO 9660 es ms bien limitado en funcionalidad, especialmente cuando se compara con sistemas de archivos ms modernos. Los nombres de archivos deben ser de un mximo de ocho carcteres de largo y una extensin de no ms de tres caracteres. Sin embargo, hay varias extensiones al estndar que se han vuelto populares a travs de los aos, entre ellas:

Rock Ridge Utiliza algunos campos indenidos en ISO 9660 para proporcionar soporte a fun cionalidades tales como nombres de archivos largos con combinaciones de maysculas y minscu las, enlaces simblicos y directorios anidados (en otras palabras, directorios que pueden contener a su vez otros directorios) Joliet Una extensin del estndar ISO 9660, desarrollado por Microsoft para permitir que los CD-ROMs contengan nombres de archivos largos, usando el conjunto de carcteres Unicode
Red Hat Enterprise Linux puede interpretar correctamente los sistemas de archivos ISO 9660 usando extensiones Rock Ridge as como tambinJoliet. 5.9.2.4. MSDOS Red Hat Enterprise Linux tambin soporta sistemas de archivos de otros sistemas operativos. Como el nombre lo implica, el sistema operativo original que soporta msdos fue Microsofts 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 ms que suciente para hacer el trabajo. 5.9.2.5. VFAT El sistema de archivos vfat primero fue utilizado por el sistema operativo Microsofts Windows 95. Como una mejora sobre el sistema de archivos msdos, los nombres de archivos en un sistema vfat pueden ser ms largos que 8.3. No obstante, los permisos y propiedad tampoco se pueden modicar.
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 particin (en un dispositivo especco) 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 especicar dos piezas de informacin:

Una forma de identicar unvocamente el disco deseado y la particin, tal como un nombre de archivo de dispositivo, una etiqueta de sistema de archivo o un enlace simblico 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 ms detalles.
Captulo 5. Administracin del Almacenamiento 5.9.3.1. Puntos de montaje
103
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 extrao al principio. Sin embargo, es uno de los mtodos ms poderosos y exibles desarrollados para manejar sistemas de archivos. Con muchos otros sistemas operativos, una especicacin completa de archivos incluye el nombre del archivo, alguna forma de identicar el directorio especco en el cual reside el archivo, y una forma de identicar el dispositivo fsico en el cual se encuentra el archivo. Con Red Hat Enterprise Linux, se utiliza un enfoque ligeramente diferente. Como con otros sistemas operativos, una especicacin completa de archivos incluye su nombre y el directorio en que este reside. Sin embargo, no se especica el dispositivo. La razn para este problema aparente es el punto de montaje. En otros sistemas operativos, hay una jerarqua de directorios para cada particin. Sin embargo, en los sistemas tipo Linux, solamente hay una jerarqua de directorios global al sistema y esta simple jerarqua puede abarcar mltiples 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 especi cado. Este problema aparente es en realidad una fortaleza. Signica que es posible la expansin 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 raz; la ruta completa al directorio sera /foo/. Luego, asuma que este sistema tiene una particin que se debe montar y que el punto de montaje de la particin es /foo/. Si la particin tiene un archivo con el nombre de bar.txt en el nivel superior del directorio, despus de montar la particin podr acceder al archivo con la especicacin completa de archivos que sigue:
/foo/bar.txt
En otras palabras, una vez que la particin ha sido montada, cualquier archivo que sea ledo o escrito en cualquier lugar bajo el directorio /foo/, ser ledo o escrito en esa particin. Un punto de montaje utilizado a menudo en muchos sistemas Red Hat Enterprise Linux es /home/ esto es porque los directorios de conexin 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 particin 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 particin est montada en el directorio, los archivos no estarn accesibles (el sistema de archivos montado aparecer en lugar de los contenidos del directorio). Sin embargo, los archivos no sufrirn dao alguno y se podrn acceder despus de desmontar la particin.
5.9.3.2. Mostrar lo que est montado Adems de montar y desmontar espacio en disco, tambin es posible ver lo que est montado. Hay varias formas de hacer esto:
Visualizar /etc/mtab
104 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 debera modicar manualmente.
Cada lnea representa un sistema de archivos que est actualmente montado y contiene los campos siguientes (de izquierda a derecha):

La especicacin del dispositivo El punto de montaje El tipo de sistema de archivos Si el archivo est montado como de slo lectura (ro) o de slo escritura (rw), junto con cualquier otra opcin 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 representacin 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 Seccin 5.9.5 para ms informacin.
105
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 nmero 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 informacin. Otros mtodos pueden, bajo extraas circunstancias, ser inexactos. Sin embargo, es probable que la mayor parte del tiempo usted utilice un comando con una salida ms fcil (y til) de leer. La prxima seccin describe este comando. 5.9.3.2.3. Ejecucin 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 ms all de all. La mayora de las veces un administrador estar quizs ms 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 /dev/sda3 /dev/sda1 /dev/sda4 none 1k-blocks 8428196 124427 8428196 644600 Used Available Use% Mounted on 4280980 3719084 54% / 18815 99188 16% /boot 4094232 3905832 52% /home 0 644600 0% /dev/shm
Hay muchas diferencias obvias entre /etc/mtab y /proc/mount que se ven inmediatamente:

Se muestra un encabezado fcil de leer Con la excepcin del sistema de archivos de la memoria compartida, solamente se muestran los sistemas de archivos basados en disco Tamao total, espacio utilizado, espacio libre y el porcentage de uso en nmeros
El ltimo punto es probablemente el ms 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 fcil ver donde reside el problema.
5.9.4. Almacenamiento accesible desde la red bajo Red Hat Enterprise Linux
Existen dos tecnologas principales utilizadas para la implementacin del almacenamiento accesible desde la red bajo Red Hat Enterprise Linux:

NFS SMB
Las secciones siguientes describen estas tecnologas.
106 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 travs de una conexin 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 conguraciones, desde servidores de archivos centralizados hasta sistemas de computacin sin discos. Por otro lado, a diferencia de otros sistemas de archivos, NFS no dicta un formato especco 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 tecnologa Linux y UNIX, es importante mencionar que existen implementaciones de clientes NFS para otros sistemas operativos, haciendo NFS una tcnica 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 cong uracin /etc/exports. Para ms informacin, consulte la pgina man de exports(5) y el Manual de administracin 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 comunicacin utilizado por varios sistemas operativos producidos por Microsoft por varios aos. SMB hace posible compartir el almacenamiento a lo largo de la red. Las implementaciones de hoy da a menudo utilizan TCP/IP como el transporte subyacente; anteriormente era NetBEUI el transporte. Red Hat Enterprise Linux soporta SMB a travs del programa de servidor Samba. El Manual de administracin del sistema de Red Hat Enterprise Linux incluye informacin sobre la conguracin de Samba.
5.9.5. Montar sistemas de archivos automticamente con /etc/fstab

Cuando se acaba de instalar un sistema Red Hat Enterprise Linux, todas las particiones de disco denidas y/o creadas durante la instalacin son conguradas para montarse automticamente cuando el sistema arranca. No obstante, qu pasa cuando se aaden unidades de disco adicionales a un sis tema despus de efectuar la instalacin? La respuesta es "nada" porque el sistema no fue congurado para montarlos automticamente. Sin embargo, esto se puede cambiar fcilmente. 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 tambin 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=/ /dev/sda1 /dev/cdrom /dev/homedisk /dev/sda2 / /boot /mnt/cdrom /home swap ext3 ext3 iso9660 ext3 swap defaults 1 1 defaults 1 2 noauto,owner,kudzu,ro 0 0 defaults 1 2 defaults 0 0
Cada lnea representa un sistema de archivos y contiene los campos siguientes:

El especicador del sistema de archivos Para los sistemas de archivos basados en disco, bien sea un nombre de archivo de dispositivo (/dev/sda1), una especicacin de etiqueta (LABEL=/) o un enlace simblico manejado por devlabel (/dev/homedisk)
107
Punto de montaje Excepto para las particiones swap, este campo especica 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 especicado (observe que se puede especicar auto para seleccionar la deteccin automtica 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 nmero en este campo controla el manejo de dump del sistema de archivos especicado Orden de vericacin del sistema de archivos Controla el orden en que fsck vericar la inte gridad del sistema de archivos
5.9.6. Aadir/Eliminar almacenamiento

Mientras que la mayora de los pasos necesarios para aadir o eliminar almacenamiento dependen ms en el hardware del sistema que en el software, hay aspectos del procedimiento que son especcos a su entorno operativo. Esta seccin explora los pasos necesarios para aadir o eliminar almacenamiento que son especcos a Red Hat Enterprise Linux. 5.9.6.1. Aadir almacenamiento El proceso de aadir almacenamiento a un sistema Red Hat Enterprise Linux es relativamente directo. He aqu los pasos que son especcos a Red Hat Enterprise Linux:

Particionar Formatear la particin(es) Actualizar /etc/fstab
Las secciones siguientes exploran cada paso con ms detalles. 5.9.6.1.1. Particionar Una vez instalado en disco duro, es hora de crear una o ms particiones para hacer el espacio disponible a Red Hat Enterprise Linux. Hay ms de una forma de hacer esto:

Usando el programa de lnea de comandos fdisk Usando parted, otro programa utilitario de lnea de comandos
Aunque las herramientas pueden ser diferentes, los pasos bsicos 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 identicar siguiendo la convencin de nombres descrita en la Seccin 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 vericar que la unidad a particionar es, en real idad, la correcta. En nuestro ejemplo, fdisk muestra la tabla de particin usando el comando p:
Command (m for help): p
108
Disk /dev/hda: 255 heads, 63 sectors, 1244 cylinders Units = cylinders of 16065 * 512 bytes Device Boot /dev/hda1 * /dev/hda2 /dev/hda3 /dev/hda4 Start 1 18 84 476 End 17 83 475 1244 Blocks 136521 530145 3148740 6176992+ Id 83 82 83 83 System Linux Linux swap Linux Linux
3. Borre cualquier particin 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) particin(es), asegurndose de especicar el tamao deseado y el tipo de sis temas de archivos. Usando fdisk, esto es un proceso de dos pasos primero, cree la particin (usando el comando n):
Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 1
First cylinder (1-767): 1
Last cylinder or +size or +sizeM or +sizeK: +512M
Command (m for help): t

Partition number (1-4): 1
Hex code (type L to list codes): 82
Segundo, congure el tipo de sistema de archivos (usando el comando t):
El tipo de particin 82 representa una particin 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
Atencin 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 resultara en la prdida de los datos. Tambin verique que ha decidido el mejor tamao para su particin. Siempre tome este punto seriamente, pues cambiarlo ms adelante es mucho ms difcil que tomarse un poco de tiempo ahora en pensar las cosas.
Captulo 5. Administracin del Almacenamiento 5.9.6.1.2. Formatear la particin
109
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 informacin especca 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 pgina man de mkfs. fstype para el sistema de archivos que ha seleccionado. Por ejemplo, vea la pgina man de mkfs.ext3 para revisar las opciones disponibles durante la creacin de un sistema de archivos ext3. En general, los programas mkfs. fstype suministran valores por defecto razonables para la mayora de las conguraciones; sin embargo, he aqu algunas de las opciones que los administradores de sistemas cambian ms a menudo:
Conguran una etiqueta de volumen para su uso posterior en /etc/fstab En discos duros muy grandes, conguran un porcentage ms pequeo de espacio reservado para el super-usuario Conguran un tamao de bloque no estndar y/o bytes para las conguraciones de inodos, que deben soportar tamaos de archivos muy grandes o muy pequeos Verican por bloques daados antes de formatear
Una vez creados los sistemas de archivos en todas las particiones apropiadas, la unidad de disco estar congurada adecuadamente para su uso. Luego, siempre es bueno volver a vericar su trabajo manualmente montando la particin(es) y ase gurndose de que est en orden. Una vez que todo est vericado, es el momento de congurar su sistema Red Hat Enterprise Linux para que monte automticamente el nuevo sistema de archivos durante el arranque. 5.9.6.1.3. Actualizar /etc/fstab Como se describi en la Seccin 5.9.5, primero debe aadir las lneas 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, especicando solamente el dispositivo o punto de montaje. Algo similar a alguno de los comandos siguientes es suciente:
mount /home mount /dev/hda3
(Reemplace /home or /dev/hda3 con el punto de montaje o dispositivo para su situacin especca.) Si la entrada correspondiente en /etc/fstab es correcta, mount obtiene la informacin faltante desde el archivo y completa la operacin de montaje. En este punto puede estar conado de que /etc/fstab est congurado correctamente para mon tar automticamente el nuevo almacenamiento cada vez que el sistema arranca (aunque si se puede permitir un reinicio rpido, no hace dao 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 especcos para Red Hat Enterprise Linux:

Elimine las particiones de disco desde /etc/fstab Desmonte las particiones activas del disco
110 Borre los contenidos de la unidad de disco
Las secciones siguientes cubren estos tpicos en ms 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) lnea(s) correspondiente(s) a la(s) parti cin(es) de disco desde el archivo /etc/fstab. Puede identicar las lneas correctas por alguno de los mtodos 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 Asegrese de ver lneas en /etc/fstab que identican 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 particin 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 especique el nombre de archivo de dispositivo, o el punto de montaje.
umount /dev/hda2 umount /home
Solamente se puede desmontar una particin si esta no se encuentra en uso. Si la particin no se puede desmontar mientras se encuentra en el nivel de ejecucin normal, arranque en modo de rescate y elimine la entrada de la particin de /etc/fstab. Cuando utilice swapoff para desactivar el swapping en una particin, debe especicar el nombre de archivo de dispositivo representando la particin swap:
swapoff /dev/hda4
Si no puede desactivar el swapping usando swapoff, arranque en modo de rescate y elimine la entrada de la particin 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. Despus de desmontar todas las particiones del disco, ejecute el comando siguiente (conectado como root):
111
badblocks -ws
Donde device-name representa el nombre del archivo de la unidad de disco que desea borrar, excluyendo el nmero de la particin. Por ejemplo, /dev/hdb para la segunda unidad ATA. Se muestra la salida siguiente mientras se ejecuta badblocks:
Writing Reading Writing Reading Writing Reading Writing Reading pattern 0xaaaaaaaa: and comparing: done pattern 0x55555555: and comparing: done pattern 0xffffffff: and comparing: done pattern 0x00000000: and comparing: done done done done done
device-name
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 compaas (y agencias del gobierno) tienen mtodos especcos de borrar datos desde sus unidades de disco y otras medias de almacenamiento. Siempre debera asegurarse de que entiende y sigue estos requerimientos; en muchos casos hay consecuencias legales si no las sigue. El ejemplo de arriba no se debera de considerar el mtodo perfecto para limpiar una unidad de disco. No obstante, es mucho ms 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. Implementacin 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 travs 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 caractersticas:

Implementacin 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 Lmites rgidos Lmites suaves Perodos de gracia
112
Las secciones siguientes describen cada caracterstica con ms detalles. 5.9.7.1.1. Implementacin 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.
/home/ est en su propio sistema de archivos, se pueden activar las cuotas all, haciendo cumplir
Esto proporciona una gran exibilidad para el administrador del sistema. Por ejemplo, si el directorio
un uso equitativo del espacio en disco entre todos los usuarios. Sin embargo, el sistema de archivos de root se podra 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 signica que se puede hacer un seguimiento del uso de espacio por usuario individual. Tambin signica que cualquier limitacin 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 lmites 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 tambin 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 ms de cerca la utilizacin 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 ms grandes para proyectos con mltiples 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 estadsticas 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 Adems de seguir el uso por bloque, las cuotas tambin permiten hacer seguimiento por inodes. Bajo Red Hat Enterprise Linux, los inodes son utilizados para almacenar varias partes del sistema de archivos, pero ms importante an, los inodes guardan informacin para cada archivo. Por lo tanto, al controlar el uso de inodes, es posible controlar la creacin de nuevos archivos.
Captulo 5. Administracin del Almacenamiento 5.9.7.1.6. Lmites rgidos
113
Un lmite rgido es el nmero mximo absoluto de bloques de disco (o inodes) que un usuario (o un grupo) puede temporalmente utilizar. Cualquier intento de utilizar un slo bloque o inode adicional, fallar. 5.9.7.1.7. Lmites suaves Un lmite suave es el nmero mximo de bloque (o inodes) que un usuario (o un grupo) puede utilizar permanentemente. El lmite suave se congura por debajo del lmite rgido. Esto permite a los usuarios que se excedan temporalmente de su lmite suave, permitiendoles terminar lo que sea que estaban realizando y dn doles algn tiempo para revisar sus archivos y poner en orden su uso del espacio por debajo del lmite suave. 5.9.7.1.8. Perodos de gracia Como se estableci anteriormente, cualquier uso del disco ms all del lmite suave es temporal. Es el perodo de gracia el que determina el largo del tiempo que un usuario (o grupo) puede extender su uso ms all del lmite suave y hacia el lmite rgido. Si un usuario contina usando ms de su lmite suave y el perodo de gracia expira, no se le permitir ms uso adicional de disco hasta que el usuario (o el grupo) reduzca su uso a un punto por debajo del lmite suave. El perodo de gracia se puede expresar en segundos, minutos, horas, das, semanas o meses, dndole al administrador del sistema una gran libertad para determinar cunto 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 descripcin general de los pasos necesarios para habilitar las cuotas de disco bajo Red Hat Enterprise Linux. Para informacin en ms detalles sobre esto, lea el captulo sobre cuotas de discos en el Manual de administracin del sistema de Red Hat Enterprise Linux .
Para utilizar cuotas de disco, primero debe activarlas. Este proceso implica varios pasos: 1. Modicar /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 aadir a ese archivo para activar las cuotas de discos.
114
La opcin usrquota activa las cuotas basadas en disco, mientras que la opcin grpquota activa las cuotas basadas en grupos. Se puede activar una o ambas opciones colocndolas 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 informacin 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 informacin relacionada a cuotas necesaria y residen en el directorio raz del sistema. Para asignar cuotas de disco, se utiliza el comando edquota. Este programa de utilidades utiliza un editor de texto para mostrar la informacin de cuotas para el usuario o grupo especicado como parte del comando edquota. He aqu un ejemplo:
Disk quotas for user matt (uid 500): Filesystem blocks soft /dev/md3 6618000 0 hard 0 inodes 17397 soft 0 hard 0
Esto muestra que el usuario matt actualmente est utilizando ms de 6GB de espacio en disco y ms de 17.000 inodes. No se ha asignado ninguna cuota (soft o hard) para los bloques o inodes, lo que signica que no existe un lmite en el espacio en disco que este usuario puede utilizar actualmente. Utilizando el editor de texto mostrando la informacin de cuotas, el administrador del sistema puede modicar los lmites rgidos y suaves como lo desee:
Disk quotas for user matt (uid 500): Filesystem blocks soft /dev/md3 6618000 6900000 hard 7000000 inodes 17397 soft 0 hard 0
En este ejemplo, se le ha asignado al usuario matt un lmite suave de 6.9GB y un lmite rgido de 7GB. No se establecen lmites suaves o rgidos para inodes de este usuario.
Sugerencia El programa edquota tambin se puede utilizar para establecer un perodo de gracia por archivo usando la opcin -t.
5.9.7.3. Administracin 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 creacin de un informe sobre el uso del disco implica la ejecucin 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
115
----------------------------------------------------------------------root 32836 0 0 4 0 0 -- 6618000 6900000 7000000 matt 17397 0 0
Se puede encontrar ms informacin sobre repquota en el Manual de administracin del sistema de Red Hat Enterprise Linux, en el captulo 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, an 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 ms fcil de ejecutar quotacheck de forma regular es usando cron. La mayora de los administradores de sistemas ejecutan quotacheck una vez a la semana, sin embargo, pueden haber razones vlidas para seleccionar un intervalo ms largo o ms corto, dependiendo de sus condiciones especcas.
5.9.8. Creacin de Formaciones RAID

Adems de soportar las soluciones de hardware RAID, Red Hat Enterprise Linux soporta tambin software RAID. Hay dos formas de crear software RAID:

Mientras se instala Red Hat Enterprise Linux Despus de instalar Red Hat Enterprise Linux
Las secciones siguientes revisan estos dos mtodos. 5.9.8.1. Mientras se instala Red Hat Enterprise Linux Durante el proceso normal de instalacin de Red Hat Enterprise Linux, se pueden crear formaciones RAID. Esto se hace durante la fase de particionamiento de la instalacin. Para comenzar, debe particionar manualmente sus discos duros usando Disk Druid. Primero debe crear una nueva particin del tipo "software RAID." Luego, seleccione las unidades de disco que desea que formen parte de la formacin RAID en el campo Unidades admisibles. Continue seleccionando el tamao deseado y si desea que la particin sea primaria. Una vez creadas todas las particiones requeridas por la formacin(es) RAID que desea crear, debe pulsar el botn RAID para realmente crear las formaciones. Luego se le presentar una caja de dilogo donde puede seleccionar el punto de montaje de la formacin, 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 formacin. Una vez creados las formaciones deseadas, el proceso de instalacin contina como de costumbre.
Sugerencia Para ms informacin sobre la creacin de formaciones RAID durante el proceso de instalacin de Red Hat Enterprise Linux, consulte el Manual de administracin del sistema de Red Hat Enterprise Linux .
116
5.9.8.2. Despus de instalar Red Hat Enterprise Linux La creacin de una formacin RAID despus de que Red Hat Enterprise Linux ha sido instalado es un poco ms compleja. Como con la adicin de cualquier tipo de almacenamiento, primero se debe instalar y congurar 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 particin como "Linux" (tipo 83) o "Linux swap" (tipo 82), todas las particiones que son parte de una formacin RAID se deben congurar a "Linux raid auto" (tipo fd). Luego, es necesario crear el archivo /etc/raidtab. Este archivo es responsable de la conguracin correcta de todas las formaciones RAID en su sistema. El formato del archivo (el cual se documenta en la pgina man de raidtab(5)) es relativamente fcil de entender. He aqu un ejemplo de una entrada /etc/raidtab para una formacin 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 ms notables en esta entrada son:

raiddev
Muestra el nombre del archivo del dispositivo para la formacin RAID 12 Dene el nivel de RAID utilizado por esta formacin Indica cuntas particiones de disco fsicas seran parte de la formacin
raid-level
nr-raid-disks nr-spare-disks
El software RAID bajo Red Hat Enterprise Linux permite la denicin de uno o ms particiones de repuesto; estas particiones pueden automticamente tomar el lugar de un disco que no est funcionando bien RAID las particiones de disco fsicas que conforman la formacin
device, raid-disk Juntos denen
Luego, es necesario crear la formacin RAID. Esto se logra con el programa mkraid. Usando nue stro archivo de ejemplo /etc/raidtab, crearemos la formacin RAID /dev/md0 con el comando siguiente:
mkraid /dev/md0
La formacin 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. Administracin da a da de las formaciones RAID

Es poco lo que hay que hacer para mantener la formacin RAID operativa. Siempre y cuando no surjan problemas de hardware, la formacin debera funcionar como si se tratase de una sola unidad fsica de discos. Sin embargo, de la misma forma que un administrador de sistemas debera vericar
12. Observe que puesto que la formacin RAID est compuesta de espacio en disco formateado, el nombre de archivo de dispositivo de una formacin RAID no reeja ninguna informacin a nivel de particiones.
117
peridicamente el estado de todos los discos duros en el sistema, tambin se debera vericar el estatus de las las formaciones RAID. 5.9.9.1. Uso de /proc/mdstat para vericar el estado de la formacin RAID El archivo /proc/mdstat es la forma ms fcil de vericar el estado de todas las formaciones RAID en un sistema particular. He aqu una muestra mdstat (vista con el comando cat /proc/mdstat):
Personalities : [raid1] read_ahead 1024 sectors md1 : active raid1 hda3[0] hdc3[1] 522048 blocks [2/2] [UU] md0 : active raid1 hda2[0] hdc2[1] 4192896 blocks [2/2] [UU] md2 : active raid1 hda1[0] hdc1[1] 128384 blocks [2/2] [UU] unused devices:
none
En este sistema, hay tres formaciones RAID (todas RAID 1). Cada formacin RAID tiene su propia seccin en /proc/mdstat y contiene la informacin siguiente:

El nombre de dispositivo de la formacin RAID (sin incluir la parte /dev/) El estatus de la formacin RAID El nivel RAID de la formacin Las particiones fsicas que actualmente conforman la formacin (seguido por el nmero de unidad de la particin) El tamao de la formacin El nmero de dispositivos congurados contra el nmero de dispositivos operativos en la formacin El estado de cada dispositivo congurado en la formacin (U lo que signica que la formacin est OK y _ indicando que el dispositivo ha fallado)
5.9.9.2. Reconstruccin de una formacin RAID usando raidhotadd Si /proc/mdstat muestra que existe un problema con una de las formaciones RAID, se debera utilizar el programa utilitario raidhotadd para reconstruir la formacin. He aqu los pasos que se necesitan seguir: 1. Determine cul unidad de disco contiene la particin 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 idnticas a aquellas en la(s) otra(s) unidad(es) en la formacin 4. Ejecute el comando siguiente
raidhotadd raid-device
5. Monitorice /proc/mdstat para ver que se lleve a cabo la reconstruccin
disk-partition
118
Sugerencia He aqu un comando que se puede utilizar para ver que se ejecute la reconstruccin:
watch -n1 cat /proc/mdstat
Este comando muestra los contenidos de /proc/mdstat, actualizndolo cada segundo.
5.9.10. Administracin de Volmenes Lgicos

Red Hat Enterprise Linux incluye el soporte para LVM. Se puede congurar LVM mientras se est in stalando Red Hat Enterprise Linux, o tambin se puede congurar despus de terminar la instalacin. LVM bajo Red Hat Enterprise Linux soporta la agrupacin del almacenamiento fsico, la redimensin de los volmenes lgicos y la migracin de datos fuera de un volumen fsico especco. Para ms informacin sobre LVM, consulte el Manual de administracin del sistema de Red Hat Enterprise Linux.

Esta seccin incluye varios recursos que se pueden utilizar para conocer ms sobre las tecnologas de almacenamiento y la materia especca a Red Hat Enterprise Linux que se discute en este captulo.

Los recursos siguientes se instalan durante el curso de una instalacin tpica de Red Hat Enterprise Linux y lo pueden ayudar a aprender un poco ms sobre la materia discutida en este captulo.

La pgina man de exports(5) Conozca ms sobre el formato del archivo de conguracin de NFS. La pgina man de fstab(5) Conozca ms informacin sobre la conguracin del sistema de archivos. La pgina man de swapoff(8) Aprenda a desactivar particiones swap. La pgina man de df(1) Aprenda a mostrar el uso del espacio en disco en los sistemas de archivos montados. La pgina man de fdisk(8) Conozca sobre este programa para el mantenimiento de las tablas de particiones. Las pginas man de mkfs(8) y mke2fs(8) Informacin sobre estos programas utilitarios para la creacin de sistemas de archivos. La pgina man de badblocks(8) Aprenda cmo probar un dispositivo para vericar si tiene bloques daados. La pgina man de quotacheck(8) Aprenda a vericar el uso de bloques y inode para usuarios y grupos y opcionalmente crear archivos de cuotas de usuarios. La pgina man de edquota(8) Informacin sobre este programa para el mantenimiento de cuotas de discos. La pgina man de repquota(8) Conozca sobre esta programa de utileras para el informe de cuotas de disco.
119
La pgina man de raidtab(5) Conozca sobre el formato del archivo de conguracin para el software RAID. La pgina man de mkraid(8) Conozca este programa para la creacin de formaciones de soft ware RAID. La pgina man de mdadm(8) Conozca sobre este programa para la administracin de forma ciones de software RAID. La pgina man de lvm(8) Aprenda sobre la Administracin de Volmenes Lgicos, LVM. La pgina man de devlabel(8) Conozca ms 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 informacin sobre tec nologas de almacenamiento. http://www.tldp.org/ The Linux Documentation Project tiene una seccin de HOWTOs y miniHOWTOs que proporcionan buenas vistas generales de las tecnologas 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 instalacin de Red Hat Enterprise Linux; Red Hat, Inc. Contiene instrucciones sobre el particionamiento de discos duros durante un proceso de instalacin de Red Hat Enterprise Linux, as como tambin una descripcin general de las particiones de discos. El Manual de referencia de Red Hat Enterprise Linux; Red Hat, Inc. Contiene informacin detallada sobre la estructura de directorios utilizada en Red Hat Enterprise Linux y una descripcin general de NFS. El Manual de administracin del sistema de Red Hat Enterprise Linux; Red Hat, Inc. Incluye captulos sobre los sistemas de archivos, RAID, LVM, devlabel, particionamiento, cuotas de discos, NFS y Samba. El Linux System Administration: A Users Guide por Marcel Gagne; Addison Wesley Professional Contiene informacin 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 informacin sobre discos, RAID y rendimiento de NFS. El Linux Administration Handbook por Evi Nemeth, Garth Snyder y Trent R. Hein; Prentice Hall Contiene informacin sobre sistemas de archivos, manejo de discos duros, NFS y Samba.
120
Captulo 6.
Administracin de cuentas de usuarios y acceso a recursos
La administracin de cuentas de usuario y grupos es una parte esencial de la administracin de sis temas dentro de una organizacin. 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 razn principal para las cuentas de usuario es vericar la identidad de cada individuo utilizando un computador. Una razn secundaria (pero an importante) es la de permitir la utilizacin 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 lgicas que se pueden utilizar para enlazar a usuarios para un propsito comn. Por ejemplo, si una organizacin 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 administracin de recursos y acceso. Las secciones siguientes discuten las cuentas de usuario y grupos en ms detalles.
6.1. Administracin de cuentas de usuarios

Como se indic anteriormente, las cuentas de usuarios es la forma a travs de la cual se identica y autentica a un individuo con el sistema. Las cuentas de usuarios tienen diferentes componentes. Primero, esta el nombre de usuario. Luego, est la contrasea, seguida de la informacin de control de acceso. Las secciones siguientes exploran cada uno de estos componentes en ms 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 "quin 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 cmo se crean los nombres de usuario. De lo contrario, puede encontrarse en la posicin de ser forzado a reaccionar cada vez que un nuevo usuario solicita una cuenta. Lo que necesita es una convencin de nombres para sus cuentas de usuarios. 6.1.1.1. Convenio de nombres Mediante la creacin 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 ms difcil crear un nombre razonable), haga un poco de trabajo de antemano para preparar una convencin a utilizar para todas las cuentas siguientes. Su convenio de nombres puede ser muy simple, o solamente su descripcin puede tomar muchas pginas. La naturaleza exacta de su convenio de nombres debe tomar varios factores en cuenta:
El tamao de su organizacin
122
Captulo 6. Administracin de cuentas de usuarios y acceso a recursos
La estructura de su organizacin La naturaleza de su organizacin
El tamao de su organizacin importa, pues dicta cuntos usuarios puede soportar su convencin para nombres. Por ejemplo, una compaa muy pequea quizs pueda permitir que todo el mundo utilice su primer nombre. Para una organizacin mucho ms grande, este convenio no funciona. La estructura de la organizacin tambin puede tener inuencia sobre el convenio de nombres ms apropiado. Para organizaciones con una estructura bien denida puede ser adecuado incluir elemen tos de esa estructura en la convencin de nombres. Por ejemplo, puede incluir los cdigos de los departamentos como parte del nombre de usuario. La naturaleza completa de su organizacin tambin puede signicar que algunas convenciones son ms apropiadas que otras. Una organizacin que maneja datos condenciales puede decidirse por una convenicin que no indica ningn tipo de informacin personal que pueda vincular al individuo con su nombre. En una organizacin de este tipo, el nombre de usuario de Maggie McOmie podra 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 cdigo del departamento (perez029, obregon454, ramirez191, etc.)
Sugerencia Tenga en cuenta que si su convencin de nombres incluye aadir datos diferentes para formar un nombre de usuario, existe el potencial de que el resultado sea gracioso u ofensivo. Por lo tanto, an si crea los nombres de usuario de forma automtica, es recomendable que lleve a cabo alguna forma de revisin.
Una cosa comn con la convencin de nombres descrita aqu es que es posible que eventualmente existan dos individuos que, de acuerdo a la convencin, obtendran el mismo nombre de usuario. Esto se conoce como una colisin. 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 convencin de nombres. Hay muchas formas de hacer esto:

Aadiendo nmeros en secuencia al nombre de usuario en colisin (perez, perez1, perez2, etc.) Aadiendo datos especcos al usuario al nombre de usuario en colisin (perez, eperez, ekperez, etc.) Aadiendo informacin adicional de la organizacin al nombre de usuario (perez, perez029, perez454, etc.)
Es necesario tener un mtodo para resolver las colisiones como parte de cualquier convencin de nombres. Sin embargo, hace ms dicil para alguien fuera de la organizacin determinar el nombre de usuario de un individuo. Por lo tanto, la desventaja de las convenciones de nombres es que hace ms probable el envio de correos electrnicos a las direcciones equivocadas.
Captulo 6. Administracin de cuentas de usuarios y acceso a recursos 6.1.1.2. Manejo de cambios de nombres
123
Si su organizacin utiliza una convencin de nombres que est basada en el nombre de cada usuario, es de esperarse que eventualmente tendr que enfrentarse a cambios de nombres. An si el nombre de la persona realmente no cambia, de vez en cuando se le pedir que modique el nombre de usuario. Las razones pueden variar desde un usuario que no le gusta su nombre de usuario hasta un empleado con ms jerarqua en la organizacin que preere un nombre de usuario "ms acorde". No importa cual sea la razn, 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 informacin subyacente del usuario Cambien la propiedad de todos los archivos y otros recursos especcos al usuario (si es necesario) Maneje los problemas relacionados con el correo electrnico
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 funcin del sistema operativo que est vinculado con el nombre de usuario, funcionar en algunos sistemas y en otros no. Ciertos sistemas operativos utilizan tcnicas 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 algn tipo de nmero de identicacin de usuarios para la may ora de los procesamientos especcos al usuario. Para minimizar los problemas generados a partir de un cambio de nombre de usuario, trate de mantener este nmero de identicacin 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 posean anteriormente bajo el nombre de usuario original. Si se debe cambiar el nmero de identicacin del usuario, es necesario cambiar la propiedad para todos los archivos y recursos especcos al usuario para reejar la nueva identicacin 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 nal. Los problemas relacionados al correo electrnico probablemente sean donde el cambio de un nombre de usuario es ms difcil. La razn para esto es que a menos que se tomen las medidas para evitarlo, los correos electrnicos 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 electrnico tienen mltiples dimensiones. En su forma ms bsica, 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 noticar a todo el mundo en su organizacin. Pero que hay de las personas fuera de la organizacin que han enviado correo a esta persona? Cmo se les debera noticar?Qu hay de las listas de correo (tanto internas como externas)? Cmo se pueden actualizar? No hay una respuesta fcil a esta pregunta. La mejor respuesta puede ser la de crear un alias para el correo electrnico 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 modicado. A medida que el tiempo pasa, menos y menos mensajes sern entregados usando el alias y eventualmente podr eliminarlo. Mientras que el uso de alias, a cierto nivel, continua la asuncin incorrecta (de que el usuario conocido ahora como mperez todava se conoce como jperez), es la nica forma de garantizar que el correo llegue a la persona adecuada.
124
Importante Si utiliza un alias para el correo electrnico, 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 interrupcin depende de cmo se implementa la entrega de correo en su sistema operativo, pero los dos sntomas ms probables son:
El nuevo usuario nunca recibe ningn correo - todo se va al usuario original. Repentinamente el usuario original deja de recibir correo - todo se va al nuevo usuario.
6.1.2. Contraseas
Si el nombre de usuario responde a la pregunta "Quin es usted?", la contrasea es la respuesta a la pregunta que inevitablemente sigue: "Demustralo!" En trminos ms prcticos, una contrasea 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 contraseas recae en gran parte sobre varios aspectos de la contrasea:

La condencialidad de la contrasea La resistencia de adivinar la contrasea La resistencia de la contrasea ante un ataque de fuerza bruta
Las contraseas que efectivamente toman en cuenta estos problemas se conocen como contraseas robustas, mientras que aquellas que no, se les llama dbiles. Es importante para la seguridad de la or ganizacin crear contraseas robustas, mientras ms robustas sean las contraseas, hay menos chances de que estas sean descubiertas o que se adivinen. Hay dos opciones disponibles para reforzar el uso de contraseas robustas:

El administrador del sistema puede crear contraseas para todos los usuarios. El administrador del sistema puede dejar que los usuarios creen sus propias contraseas, a la vez que se verica que las contraseas sean lo sucientemente robustas.
Al crear contraseas para todos los usuarios asegura que estas sean robustas, pero se vuelve una tarea pesada a medida que crece la organizacin. Tambin incrementa el riesgo de que los usuarios escriban sus contraseas. Por estas razones, la mayora de los administradores de sistemas preeren dejar que los usuarios mismos creen sus contraseas. Sin embargo, un buen administrador de sistemas tomar los pasos adecuados para vericar que las contraseas sean robustas. Para leer sobre las pautas para la creacin de contraseas robustas, vea el captulo llamado Seguridad de las Estaciones de trabajo en el Manual de seguridad de Red Hat Enterprise Linux. La necesidad de mantener secretas las contraseas debera 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 contraseas. Dado este hecho, es de vital importancia proporcionar cierta cantidad de educacin para los usuarios, para que as estos puedan entender que sus contraseas se deberan mantener tan secretas como su sueldo.
125
Las contraseas deberan ser tan difciles de adivinar como sea posible. Una contrasea robusta es aquella que un atacante no podr adivinar, an si el atacante conoce bien al usuario. Un ataque de fuerza bruta sobre una contrasea implica el intento metdico (usualmente a travs de un programa conocido como password-cracker ) de cada combinacin de caracteres posible con la esperanza de que se encontrar la contrasea correcta eventualmente. Una contrasea robusta se debera construir de manera tal que el nmero de contraseas potenciales a probar sea muy grande, forzando al atacante a tomarse un largo tiempo buscando la contrasea. Las contraseas dbiles y robustas se exploran con ms detalles en las secciones siguientes. 6.1.2.1. Contraseas dbiles Como se estableci anteriormente, una contrasea dbil 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 cmo pueden ser dbiles las contraseas. 6.1.2.1.1. Contraseas cortas Una contrasea corta es dbil porque es mucho ms susceptible a un ataque de fuerza bruta. Para ilus trar esto, considere la tabla siguiente, en el que se muestran el nmero de contraseas potenciales que deben ser evaluadas en un ataque de fuerza bruta. (Se asume que las contraseas consisten solamente de letras en minsculas.) Largo de la contrasea 1 2 3 4 5 6 Contraseas potenciales 26 676 17,576 456,976 11,881,376 308,915,776
Tabla 6-1. El largo de la contrasea contra el nmero de contraseas potenciales Como puede ver, el nmero de contraseas posibles incrementa dramticamente a medida que se incrementa el largo.
Nota An cuando esta tabla termina en seis caracteres, esto no se debera tomar como que se recomienda contraseas de seis caracteres de largo como lo sucientemente largas para una buena seguridad. En general, mientras ms larga la contrasea mejor.
126
6.1.2.1.2. Conjunto de carcteres limitado El nmero de carcteres diferentes que comprenden una contrasea tiene un gran impacto en la habil idad de un atacante de conducir un ataque de fuerza bruta. Por ejemplo, en vez de 26 carcteres difer entes que se pueden utilizar en una contrasea de solamente minsculas, que tal si usamos nmeros? Esto signica que cada carcter en una contrasea es uno de 36 en vez de uno de 26. En el caso de contraseas de seis caracteres de largo, esto representa un incremento de contraseas posibles de 308,915,776 a 2,176,782,336. An hay ms que se puede hacer. Si tambin inclumos contraseas alfanumricas con maysculas y minsculas (para aquellos sistemas operativos que lo soporten), el nmero posible de contraseas de seis carcteres se incrementa a 56,800,235,584. Aadiendo otros caracteres (tales como smbolos de puntuacin) aumenta an ms los nmeros posibles, haciendo un ataque de fuerza bruta mucho ms difcil. Sin embargo, un punto a tener en mente es que no todos los ataques contra una contrasea son de fuerza bruta. Las secciones siguientes describen otros atributos que pueden hacer una contrasea dbil. 6.1.2.1.3. Palabras reconocibles Muchos ataques contra contraseas estn basados en el hecho de que la gente generalmente se siente ms cmoda con contraseas que pueden recordar. Y para la mayora de la gente, las contraseas ms fciles de recordar son las que contienen palabras. Por lo tanto, muchos ataques a contraseas estn 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 contrasea.
Nota Muchos programas de ataque a contraseas basados en diccionario utilizan diccionarios de difer entes idiomas. Por lo tanto, no piense que su contrasea es ms robusta simplemente porque est utilizando una palabra que no es en Espaol.
6.1.2.1.4. Informacin personal Las contraseas que contienen informacin personal (el nombre o fecha de nacimiento de un ser querido, una mascota o un nmero de identicacin personal) puede o puede que no sean encontradas a travs de un ataque basado en contraseas de diccionario. Sin embargo, si el atacante lo conoce personalmente (o est lo sucientemente motivado para investigar su vida personal), puede ser capaz de adivinar su contrasea con poca o ninguna dicultad. Adems de los diccionarios, muchos descifradores de contraseas tambin incluyen nombres co munes, fechas y otro tipo de informacin en su bsqueda de contraseas. Por lo tanto, an si el atacante no conoce que el nombre de su perro es Howard, todava pueden descubrir que su contrasea es "MiperrosellamaHoward", con un buen descifrador de contraseas. 6.1.2.1.5. Trucos simples de palabras Usando cualquiera de la informacin discutida anteriormente como la base para una contrasea, pero invirtiendo el orden de las letras, tampoco hace una contrasea dbil en una robusta. La mayora de los descifradores de contraseas hacen estos trucos en todas las contraseas posibles. Esto incluye sustituir cierto nmeros por letras en palabras comunes. He aqu algunos ejemplos:
drowssaPdaB1
Captulo 6. Administracin de cuentas de usuarios y acceso a recursos R3allyP00r
127
6.1.2.1.6. La misma palabra para mltiples sistemas An si su contrasea es robusta, no es una buena idea utilizar la misma contrasea en ms de un sistema. Obviamente se puede hacer muy poco si los sistemas son congurados para utilizar un servi dor central de algn tipo, pero en cualquier otro caso, se deben utilizar contraseas diferentes para sistemas diferentes. 6.1.2.1.7. Contraseas en papel Otra forma de hacer una contrasea robusta en una dbil es escribindola. Al colocar su contrasea en papel, ya usted no tiene un problema de condencialidad, pero de seguridad fsica - ahora usted debe mantener seguro ese pedazo de papel. Esto obviamente no es una buena idea. Sin embargo, algunas organizaciones tienen una necesidad legtima para escribir contraseas. Por ejemplo, algunas organizaciones tienen contraseas escritas como parte de un procedimiento para recuperarse de la prdida de un empleado clave (tales como un administrador de sistemas). En estos casos, el papel conteniendo las contraseas es almacenado en una ubicacin fsicamente segura que requiere la cooperacin de varias personas para tener acceso al papel. Usualmente se utilizan cajas de seguridad acorazadas y con mtiples cerrojos. Cualquier organizacin que explore este mtodo de almacenar contraseas para propsitos de emer gencia debe estar consciente de que la existencia de contraseas escritas aade un elemento de riesgo a la seguridad de sus sistemas, no importa cuan seguro sea el almacenamiento de las contraseas. Esto es particularmente cierto si es de conocimiento general que las contraseas se encuentran escritas (y donde se encuentran). Lamentablemente, a menudo las contraseas escritas no forman parte de un plan de recuperacin y no son almacenadas en una bveda, y estas son las contraseas 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 contrasea escrita.
6.1.2.2. Contraseas robustas Hemos visto cmo son las contraseas dbiles; las secciones siguientes describen funcionalidades que todas las contraseas robustas tienen. 6.1.2.2.1. Contraseas largas Mientras ms larga la contrasea, 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 mnimo para las contraseas de sus usuarios relativamente largo.
128
6.1.2.2.2. Conjunto de caracteres expandido Promocione el uso de contraseas alfanumricas que combinen el uso de maysculas y minsculas y ms an, anime la adicin de un carcter no-alfanumrico a todas las contraseas:

t1Te-Bf,te Lb@lbhom
6.1.2.2.3. Memorizables Una contrasea es robusta solamente si se puede recordar. Sin embargo, usualmente el ser fcil de memorizar y fcil de adivinar a menudo van juntos. Por lo tanto, dele a su comunidad de usuarios algunos consejos sobre la creacin de contraseas fciles de recordar pero que no sean fciles 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 creacin de la nueva contrasea. El resultado es fcil 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 suciente para crear una contrasea robusta. Siempre asegrese de incrementar el conjunto de caracteres incluyendo la combinacin de carcteres alfanumricos y tambin al menos un carcter especial.
6.1.2.3. Caducidad de las contraseas Si es posible implemente perodos de vigencia para las contraseas. La caducidad de las contraseas es una funcionalidad (disponible en muchos sistemas operativos) que coloca lmites en el tiempo que una contrasea dada es considerada vlida. Al nal del tiempo de vida de la contrasea, se le pide al usuario que introduzca una nueva contrasea, que se puede utilizar hasta que, igualmente, expire. La pregunta clave con respecto a la caducidad de las contraseas con la que se enfrentan muchos administradores de sistemas es sobre el tiempo de vida de una contrasea: Cul es el ms adecuado? Hay dos problemas diametricalmente opuestos con respecto al tiempo de vida de las contraseas:

Conveniencia del usuario Seguridad
Por un lado, un tiempo de vida de una contrasea de 99 aos presentar muy pocos problemas (si es que llega a presentar alguno). Sin embargo, proporcionar muy poco en trminos de mejorar la seguridad. En el otro extremo, un tiempo de vida de una contrasea 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 organizacin. Para la mayora de las organizaciones, los tiempos de vida de las contraseas dentro del rango de semanas - meses, son los ms comunes.
129
6.1.3. Informacin de control de acceso

Junto con un nombre de usuario y contrasea, las cuentas de usuario tambin contienen informacin de acceso. Esta informacin toma formas diferentes de acuerdo al sistema operativo utilizado. Sin embargo, los tipos de informacin a menudo incluyen:

Identicacin especca al usuario global al sistema Identicacin especca al grupo global al sistema Lista de los grupos/capacidades adicionales a los cuales el usuario es miembro Informacin de acceso por defecto a aplicar para todos los archivos y recursoscreados por el usuario
En algunas organizaciones, la informacin de control de acceso quizs nunca se necesite tocar. Este caso es ms 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 informacin de control de acceso se modique con frecuencia. La carga de trabajo requerida para mantener apropiadamente la informacin de control de acceso de sus usuarios vara de acuerdo a cuan intensivamente su organizacin utiliza las funcionalidades de control de acceso. Mientras que no esta mal contar con estas funcionalidades (de hecho, quizs sea inevitable), implica que su entorno de sistema puede requerir ms esfuerzo para ser mantenido y que cada cuenta de usuario pueda tener ms formas en las cuales pueda ser mal congurada. Por lo tanto, si su organizacin requiere de este tipo de entorno, debera documentar los pasos exactos requeridos para crear y correctamente congurar una cuenta de usuario. De hecho, si hay diferentes tipos de cuentas de usuario, debera documentar cada una (creando una nueva cuenta de usuario de nanzas, una nueva cuenta de usuario de operaciones, etc.).
6.1.4. Administracin da a da 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 tambin 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 organizacin. 6.1.4.1. Nuevos empleados Cuando una nueva persona entra a la organizacin, normalmente se les da acceso a varios recursos (dependiendo de sus responsabilidades). Quizs se les facilite un lugar para trabajar, un telfono y una llave para la puerta de entrada. Probablemente tambin se les da acceso a uno o ms computadoras en su organizacin. Como ad ministrador del sistema, es su responsabilidad vericar que esto se haga rpidamente y de la forma adecuada. Cmo 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 organizacin le notica cuando llega una nueva persona. Cree una forma que el supervisor de la nueva persona debe llenar y utilizar para solicitar la creacin de una cuenta de usuario.
Diferentes organizaciones tienen enfoques diferentes. No importa como se lleve a cabo, es vital que tenga un procedimiento conable que pueda alertar de cualquier trabajo relacionado a las cuentas que se necesite hacer.
130
6.1.4.2. Terminaciones Es conocido el hecho de que habr personas que dejen la organizacin. Algunas veces esto puede ser bajo circunstancias felices y otras quizs no tan felices. En cualquier caso, es vital que se le informe de la situacin para que as pueda tomar las acciones adecuadas. Como mnimo, 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 contrasea) 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 ganizacin recientemente. Esto es particularmente importante si el usuario fue terminado bajo condi ciones que pueden haberlo dejado con un poco de malicia hacia la organizacin. Sin embargo, an si las circunstancias no son tan graves, le conviene a la organizacin desactivar rpidamente el acceso a una persona que ya no pertenece a la compaa. Esto indica la necesidad de un proceso que lo alerte sobre las terminaciones - preferiblemente antes de que estas sean efectivas. Esto implica que usted debera trabajar con el departamento de personal de su organizacin para asegurarse de que se le notique sobre cualquier terminacin futura.
Sugerencia Cuando se manejen los "bloqueos" en respuesta a una liquidacin, es de suma importancia que las cosas se hagan en el momento correcto. Si el bloqueo ocurre despus de completarse el proceso de liquidacin, 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 liquidacin, esto puede alertar a la persona sobre el despido inminente y hacer el proceso ms difcil para ambas partes. El proceso de liquidacin usualmente se inicia a travs de una reunin entre la persona a ser liq uidada, el supervisor de la persona y un representante del departamento de personal de la organi zacin. Por lo tanto, establecer un proceso que lo alerte sobre cuando esta reunin 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 estndares de su organizacin, o puede ser un procedimiento dedicado a hacer copias de seguridad de viejas cuentas de usuario. Aspectos tales como regulaciones sobre la retencin de datos, guardar evidencia en casos de demandas por liquidaciones errneas y otras parecidas, todas forman parte en determinar la forma ms apropiada de manejar las copias de seguridad. En cualquier caso, un respaldo en este momento siempre es un buen hbito, pues el prximo paso (cuando el supervisor accede a los datos de la persona liquidada) puede resultar en la eliminacin accidental de los archivos. En tales circunstancias, el tener una copia de seguridad reciente hace posi ble recuperarse fcilmente de este tipo de accidentes, haciendo el proceso ms fcil 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 organizacin 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 ms all que simplemente correo electrnico, es posible que el supervisor tenga que revisar y colar un poco los archivos, determinar lo que se debera 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. Quizs se le solicite
131
su asistencia para este paso nal o puede que el supervisor est en una posicin de manejar esto l mismo. Todo depende de los archivos y de la naturaleza del trabajo que realiza su organizacin. 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 situacin no es tan clara cuando la persona cambia de responsabilidades dentro de su organizacin. 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 congurada adecuadamente para coincidir con las nuevas responsabilidades:

Usted El supervisor original del usuario El nuevo supervisor del usuario
Entre uds tres debera 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 ms probable que se mantenga la cuenta del usuario y que se modique 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 an ms, est la situacin en que hay un perodo de transicin donde la per sona realiza tareas relacionadas a ambos grupos de responsabilidades. Es aqu donde los supervisores original y el nuevo, lo pueden ayudar dndole una ventana de tiempo para este perodo de transicin.
6.2. Administracin de recursos de usuarios

La creacin de cuentas de usuario solamente es una parte del trabajo de un administrador de sistemas. La administracin de recursos tambin es esencial. Por lo tanto, debe considerar tres puntos:

Quin puede acceder a los datos compartidos? Dnde 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 tpicos.
6.2.1. Quin puede acceder a los datos compartidos?

El acceso de un usuario a una aplicacin dada, archivo o directorio es determinado por los permisos aplicados a esa aplicacin, archivo o directorio. Adems, a menudo es til si se pueden aplicar diferentes permisos para diferentes clases de usuarios. Por ejemplo, el almacenamiento compartido debera se capaz de prevenir la eliminacin 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.
132
Otro ejemplo es el acceso asignado al directorio principal de un usuario. Solamente el propietario del directorio principal debera poder crear y ver los archivos que se encuentran all. Se debera 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 apropiacin incorrecta de archivos personales. Pero hay muchas situaciones en las que mltiples usuarios pueden necesitar acceso al mismo conjunto de recursos en una mquina. En este caso, puede ser necesaria la creacin de grupos compartidos. 6.2.1.1. Grupos y datos compartidos Como se mencion en la introduccin, los grupos son construcciones lgicas que se pueden usar para vincular cuentas de usuario para un propsito especco. Cuando se administran grupos dentro de una organizacin, es prudente identicar los datos a los que ciertos departamentos deben tener acceso, los datos que se deben negar a otros y que datos deberan ser compartidos por todos. Esto ayuda en la creacin 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 informacin 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 quin colocar en un grupo determinado? Qu tipo de permisos deberian tener estos recursos compartidos?
Para estas preguntas se necesita un enfoque con sentido comn. Una posibilidad es reejar la estruc tura de su compaa cuando se creen grupos. Por ejemplo, si hay un departamento de nanzas, cree un grupo llamado finanzas y haga a todo el personal de nanzas parte de ese grupo. Si la informacin nanciera es muy condencial para toda la compaa, 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 nanzas aadiendolos al grupo finanzas. Tambin es bueno pecar por el lado de la precaucin cuando se otorguen permisos para los usuar ios. De esta forma, hay menos probabilidades de que los datos condenciales caigan en las manos incorrectas. Enfocando la creacin de la estructura de grupos de su organizacin de esta manera, se puede satisfacer de forma segura y efectiva la necesidad de datos compartidos dentro de la organizacin.
6.2.2. Donde los usuarios acceden a los datos compartidos?

Cuando se comparten datos entre usuarios, es un prctica comn tener un servidor central (o grupo de servidores) que hacen ciertos directorios disponibles a otras mquinas en la red. De esta forma los datos son almacenados en un lugar; no es necesario sincronizar los datos entre mltiples mquinas. Antes de asumir este enfoque, primero debe determinar cules son los sistemas a acceder a los datos almacenados centralmente. Al hacer esto, tome nota de los sistemas operativos utilizados por los sistemas. Esta informacin tienen un peso en su habilidad de implementar este enfoque, pues su
133
servidor de almacenamiento debe ser capaz de servir sus datos a cada uno de los sistemas operativos en uso en su organizacin. Lamentablemente, una vez que los datos son compartidos entre mltiples computadores en una red, puede surgir el potencial para conictos en la propiedad de un archivo. 6.2.2.1. Problemas globales de propiedad El tener los datos almacenados centralmente y accesibles por mltiples 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 an, 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 cmo 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 tambin puede ser ledo por el usuario B desde otro sistema. Por esta razn, muchas organizaciones utilizan algn 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 deberan 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 mquina 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 organizacin no podrn acceder a sus archivos. En algunas situaciones (tales como organizaciones que hacen gran uso de porttiles), el tener directorios principales centralizados no es recomendable. Pero si tiene sentido para su organizacin, la implementacin de directorios principales puede hacer la vida de un administrador mucho ms fcil.
6.2.3. Qu barreras se colocan para prevenir el abuso de los recursos?

La organizacin cuidadosa de recursos y la asignacin de permisos para los recursos compartidos es una de las cosas ms importantes que un administrador de sistemas puede hacer para prevenir el abuso de recursos entre usuarios dentro de la organizacin. De esta forma, aquellos que no deberan tener acceso a recursos condenciales, se les niega el acceso. Pero no importa cmo su organizacin 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 maana siguiente.

Las secciones siguientes describen las diferentes funcionalidades especcas a Red Hat Enterprise Linux que se relacionan con la administracin de cuentas de usuarios y recursos asociados.
134
6.3.1. Cuentas de usuarios, Grupos y Permisos

Bajo Red Hat Enterprise Linux, un usuario puede iniciar una sesin en un sistema y utilizar cualquier aplicacin o archivos a los cuales tengan permiso de acceso despus 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 smbolos de un carcter para describir cada permiso en un listado de directorio. Se usan los siguientes smbolos:
r w x
Indica que una categora dada de usuario puede leer un archivo. Indica que una categora de usuario puede escribir a un archivo. Indica que una categora de usuario puede ejecutar los contenidos de un archivo.
Un cuarto smbolo (-) indica que no se permite ningn acceso. Cada uno de estos tres permisos son asignados a tres categoras diferentes de usuarios. Las categoras son:

owner El dueo o propietario de un archivo o aplicacin. group El grupo dueo del archivo o aplicacin. 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 sera as:
-rwxrwxr-x 1 juan juan 0 Sep 26 12:25 foo
Los permisos para este archivo se listan al principio de la lnea, comenzando con rwx. El primer con junto de smbolos dene el acceso del dueo - en este ejemplo, el dueo juan tiene acceso completo y puede leer, escribir y ejecutar el archivo. El prximo conjunto de smbolos rwx dene el acceso de grupo (una vez ms, con acceso completo), mientras que el ltimo conjunto de smbolos dene el tipo de acceso permitido para todos los dems usuarios. Aqu, todos los otros usuarios pueden leer y ejecutar el archivo, pero no pueden modicarlo de ninguna forma. Otro aspecto importante a tener en mente con relacin a los permisos y a las cuentas de usuarios es que cada aplicacin ejecutada en Red Hat Enterprise Linux se ejecuta en el contexto de un usuario especco. Tpicamente, esto signica que si el usuario juan lanza una aplicacin, la aplicacin se ejecuta usando el contexto de juan. Sin embargo, en algunos casos la aplicacin puede necesitar un nivel de acceso ms privilegiado para poder realizar la tarea. Tales aplicaciones incluyen aquellas que modican los parmetros del sistema o que conectan usuarios. Por esta razn, 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 aplicacin se va a ejecu tar como el dueo del archivo y no como el usuario lanzando la aplicacin. Se indica por el carcter s en el lugar de x en la categora del propietario. Si el propietario del archivo no tiene permisos de ejecucin, la S se coloca en maysculas para reejar este hecho. setgid usada principalmente por las aplicaciones, este permiso indica que la aplicacin se ejecu tar como el grupo que es dueo del archivo y no como el grupo del usuario lanzando la aplicacin. 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
135
indica por el carcter s en el lugar de x en la categora de grupo. Si el grupo que posee el archivo o directorio no tiene permisos de ejecucin, se coloca en maysculas la S para reejar 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 carcter t en el lugar de x en la categora de todo el mundo (everyone). Si la categora everyone no tiene permisos de ejecucin, la T se coloca en maysculas para reejar este hecho. Bajo Red Hat Enterprise Linux, el sticky bit se coloca por defecto en el directorio /tmp/ exacta mente por esta razn.
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 identicadores numricos. Para los usuarios este identicador se conoce como un UID, mientras que para los grupos se conoce como GID. Los programas que hacen disponibles la informacin de usuarios o grupos para los usuarios, traducen los valores de UID/GID a sus equivalentes ms legibles para el usuario.
Importante Los UIDs y los GIDs deben ser globalmente nicos dentro de su organizacin 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. Especcamente, si los archivos /etc/passwd y /etc/group en un servidor de archivos y en la estacin de trabajo de un usuario son diferentes en los UIDs o GID que contienen, la aplicacin 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 crearn con un propietario de UID 500. No obstante, si el usuario bob inicia una sesin en el servidor de archivos (o en otro computador), y la cuenta de bob tambin 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 numrico real de un UID o GID tiene un signicado especco. El UID o GID de cero (0) se utiliza para el usuario root y se tratan de forma especial por Red Hat Enterprise Linux automticamente se le otorga acceso completo. La segunda situacin 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 algn momento. Para ms informacin sobre estos usuarios y grupos estndar, consulte el captulo llamado Usuarios y Grupos en el Manual de referencia de Red Hat Enterprise Linux. Cuando se aaden nuevas cuentas de usuario usando las herramientas estndar de Red Hat Enterprise Linux, a las nuevas cuentas de usuario se les asigna el primer UID y GID disponible comenzando por 500. La prxima cuenta de usuario se le asignar un UID/GID de 501, seguido de UID/GID 502 y as sucesivamente. Ms adelante en este captulo se hace una breve descripcin de las herramientas disponibles bajo Red Hat Enterprise Linux para la creacin de usuarios. Pero antes de revisar estas herramientas, la seccin siguiente revisa los archivos que Red Hat Enterprise Linux utiliza para denir cuentas y grupos del sistema.
136
6.3.2. Archivos que controlan Cuentas de Usuarios y Grupos

En Red Hat Enterprise Linux la informacin 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 seccin siguiente documenta los archivos en el directorio /etc/ que almacenan informacin 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 lnea separada. En cada lnea hay una lista delimitada por dos puntos (:) conteniendo la informacin siguiente:

Nombre de usuario El nombre que el usuario escribe cuando se conecta al sistema. Contrasea Contiene la contrasea encriptada (o una x si se utilizan contraseas shadow - ms detalles sobre esto enseguida). ID del usuario (UID) El equivalente numrico 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 numrico 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 histricas, el campo GECOS1 es opcional y se utiliza para al macenar informacin adicional (tal como el nombre completo del usuario). Se pueden almacenar mltiples entradas en este campo, en una lista limitada por comas. Las utilidades como finger acceden a este comando para proporcionar informacin adicional del usuario. Directorio principal La ruta absoluta al directorio principal del usuario, tal como /home/juan/. Shell El programa lanzado automticamente cada vez que un usuario se conecta. Usualmente es un intrprete 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 lnea muestra que el usuario root tiene una contrasea shadow, as como tambin un UID y GID de 0. El usuario root tiene /root/ como directorio principal y utiliza /bin/bash como intrprete de comandos. Para ms informacin sobre /etc/passwd, consulte la pgina 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 razn principal es que este archivo se utiliza para llevar a cabo la traduccin del UID al nombre de usuario), hay un riesgo relacionado en almacenar las contrasea de todo el mundo en /etc/passwd. Cierto, las contraseas
1. GECOS viene de General Electric Comprehensive Operating Supervisor. Este campo fue utilizado en Bell
Labs, en la implementacin original de UNIX. El laboratorio tenia muchas computadoras diferentes, incluyendo una ejecutando GECOS. Este campo se utiliz para almacenar informacin cuando el sistema UNIX enviaba trabajos por lotes o de impresin al sistema GECOS.
137
estan encriptadas. Sin embargo, es posible realizar ataques contra contraseas si las contraseas en criptada estn 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 deteccin teniendo que intentar un inicio de sesin con cada contrasea potencial generada por un descifrador de contraseas, el atacante puede utilizar un descifrador de contraseas de la forma siguiente:

Un descifrador de contraseas genera una contrasea potencial Cada contrasea potencial es encriptada utilizando el mismo algoritmo que utiliza el sistema La contrasea potencial encriptada es comparada con las contraseas encriptadas en /etc/passwd
El aspecto ms peligroso de este ataque es que puede ocurrir en un sistema muy lejos de su orga nizacin. Debido a esto, el atacante puede utilizar hardware con el ms alto rendimiento disponible, haciendo posible pasar a travs de nmeros masivos de contraseas rpidamente. Por esta razn, el archivo /etc/shadow solamente est disponible por el usuario root y contiene con traseas (e informacin opcional de caducidad) para cada usuario. Como en el archivo /etc/passwd, cada informacin de usuario est en una lnea separada. Cada una de estas lneas es una lista delimi tada por dos puntos (:) incluyendo la informacin siguiente:

Nombre de usuario El nombre que el usuario escribe cuando se conecta al sistema. Esto permite que la aplicacin login de inicio de sesin, recupere la contrasea del usuario (y la informacin relacionada). Contrasea encriptada La contrasea encriptada con 13 a 24 carcteres. La contrasea 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 contrasea encriptada o en hash, se utilizan para contro lar la conexin del usuario y para mostrar el status de la contrasea. 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 contrasea (y el usuario, como no ha establecido una contrasea, no se podr conectar). Ultima fecha en que se cambi la contrasea El nmero de das desde el 1 de enero, 1970 (tambin conocido como epoch) en que la fecha fue modicada. Esta informacin es utilizada en conjunto con los campos de caducidad de la contrasea. Nmero de das antes de que la contrasea debe ser modicada El nmero mnimo de das que deben pasar antes de que la contrasea se pueda cambiar. Nmero de das antes de que se requiera un cambio de contrasea El nmero de das que deben pasar antes de que se deba cambiar la contrasea. Nmero de das de advertencia antes de cambiar la contrasea El nmero de das antes que el usuario es noticado de que la contrasea v a expirar. Nmero de das antes de desactivar la contrasea El nmero de das despus que una contrasea expira antes de desactivar la cuenta. Fecha desde que la cuenta fue desactivada La fecha (almacenada como el nmero de das 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 lnea de /etc/shadow:

juan:$1$.QKDPc5E$SWlkjRWexrXYgc98F.:12825:0:90:5:30:13096:
Esta lnea muestra la informacin siguiente para el usuario juan:
La ltima vez que se cambi la contrasea fue el 11 de febrero, 2005
138
No hay in mnimo de tiempo requerido antes de que la contrasea debe ser cambiada La contrasea se debe modicar cada 90 das El usuario recibir una noticacin cinco das antes de que la contrasea deba ser modicada La cuenta ser desactivada 30 das despus que expire la contrasea si no se realiza ninguna conex in La cuenta caduca el 9 de noviembre del 2005
Para ms informacin sobre el archivo /etc/shadow, consulte la pgina 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 lnea separada. Cada lnea es una lista de cuatro campos, delimitados por dos puntos (:) que incluye la informacin siguiente:

Nombre del grupo El nombre del grupo. Utilizado por varios programas de utilidades como un identicador legible para el grupo. Contrasea de grupo Si se congura, esto permite a los usuarios que no forman parte del grupo a unirse a el usando el comando newgrp y escribiendo la contrasea almacenada aqu. Si hay una x minscula en este campo, entonces se estn usando contraseas shadow. ID del grupo (GID) El equivalente numrico 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 lnea de ejemplo de /etc/group:

general:x:502:juan,shelley,bob
Esta lnea muestra que el grupo general est utilizando contraseas shadow, tiene un GID de 502, y que juan, shelley y bob son miembros. Para ms informacin sobre /etc/group, consulte la pgina 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 traseas encriptadas para cada grupo, as como tambin informacin de los miembros del grupo y de administracin. De la misma forma que en el archivo /etc/group, cada informacin de grupos est en una lnea separada. Cada una de estas lneas es una lista delimitada por smbolos de dos puntos (:) incluyendo la informacin siguiente:

Nombre del grupo El nombre del grupo. Utilizado por varios programas de utilidades como un identicador legible para el grupo. Contrasea encriptada La contrasea encriptada para el grupo. Si est congurada, los que no sean miembros del grupo pueden unirse a este escribiendo la contrasea para ese grupo usando el comando newgrp. Si el valor de este campo es !, entonces ningn usuario tiene acceso al grupo usando el comando newgrp. Un valor de !! se trata de la misma forma que un valor de ! sin embargo, tambin indica que nunca se ha establecido una contrasea 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 aadir o eliminar miembros del grupo usando el comando gpasswd.
139
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 lnea de ejemplo de /etc/gshadow:

general:!!:shelley:juan,bob
Esta lnea muestra que el grupo general no tiene contrasea y no permite a los no miembros a unirse al grupo usando newgrp. Adems, shelley es el administrador del grupo y juan y bob son miembros normales, no administrativos. Puesto que la edicin manual de estos archivos incrementa las posibilidades de errores sintcticos, se recomienda que se utilicen las aplicaciones suministradas con Red Hat Enterprise Linux para este propsito. La seccin siguiente revisa las herramientas principales para realizar estas tareas.
6.3.3. Aplicaciones para Cuentas de Usuarios y Grupos

Hay dos tipos bsicos de aplicaciones que se pueden utilizar cuando se administran cuentas de usuarios y grupos en sistemas Red Hat Enterprise Linux:

La aplicacin grca Administrador de usuarios Un conjunto de herramientas de lnea de comandos
Para ver las instrucciones detalladas sobre el uso de Administrador de usuarios, revise el captulo llamado Conguracin de Usuarios y Grupos en el Manual de administracin del sistema de Red Hat Enterprise Linux. Mientras que tanto la aplicacin Administrador de usuarios y las utilidades de lnea de comandos esencialmente ejecutan la misma tarea, las herramientas de lnea de comandos tienen la ventaja de ser de tipo script y por lo tanto ms fciles de automatizar. La tabla siguiente describe algunas de las herramientas de lnea de comandos ms utilizadas para crear y administrar cuentas de usuarios y grupos: Aplicacin
/usr/sbin/useradd /usr/sbin/userdel /usr/sbin/usermod
Funcin Aade cuentas de usuarios. Esta herramienta tambin es utilizada para especicar membrecias primaria y secundarias a grupos. Elimina cuentas de usuarios. Modica los atributos de las cuentas incluyendo algunas funciones relacionadas a la expiracin de contraseas. Para un control ms renado, utilice el comando passwd. Tambin se utiliza usermod para especicar membrecias de grupos primaria y secundaria. Congura una contrasea. Aunque se utiliza principalmente para modicar la contrasea de un usuario, esta tambin puede controlar todos los aspectos de la expiracin de contraseas. Lee un archivo que consiste de pares de nombres de usuarios y contraseas, y actualiza cada contrasea de usuario de acuerdo a este. Cambia las polticas de envejecimiento de contraseas. Tambin se puede utilizar el comando passwd para este propsito. Cambia la informacin GECOS de un usuario.
passwd
/usr/sbin/chpasswd chage chfn
140 Aplicacin
chsh
Captulo 6. Administracin de cuentas de usuarios y acceso a recursos Funcin Cambia el intrprete de comandos por defecto de un usuario.
Tabla 6-2. Herramientas de lnea de comandos para la Administracin de Usuarios La tabla siguiente describe algunas de las herramientas de lnea de comandos ms comunes utilizadas para crear u administrar grupos: Aplicacin
/usr/sbin/groupadd
Funcin Aade grupos, pero no asigna usuarios a estos grupos. Se deben utilizar los programas useradd y usermod para asignar usuarios a un grupo dado. Elimina grupos. Modica 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. Cambia la membrecia de un grupo y congura contraseas para permitir a los usuarios que no sean miembro que conocen la contrasea, unirse al grupo. Tambin se utiliza para especicar administradores de grupos. Verica la integridad de los archivos /etc/group y /etc/gshadow.
/usr/sbin/groupdel /usr/sbin/groupmod
gpasswd
/usr/sbin/grpck
Tabla 6-3. Herramientas de lnea de comandos para Administrar Grupos Las herramientas listadas proporcionan gran exibilidad a los administradores de sistemas para con trolar todos los aspectos de las cuentas de usuarios y grupos. Para conocer an ms sobre su fun cionamiento, consulte sus pginas 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 organizacin. La tabla siguiente describe algunas de las herramientas de lnea de comandos ms comunes para este propsito. Aplicacin
chgrp chmod chown
Funcin Cambia el grupo que posee un archivo. Cambia los permisos de acceso para un archivo dado. Es capaz de asignar permisos especiales. Cambia la propiedad de un archivo (y tambin puede cambiar el grupo).
Tabla 6-4. Herramientas de lnea de comandos para la Administracin de Permisos Tambin es posible alterar estos atributos en los entornos grcos GNOME y KDE. Pulse con el botn derecho sobre el cono de un archivo (por ejemplo, mientras se muestra el cono en un administrador de archivos grco o en el escritorio), y seleccione Propiedades.
141

Esta seccin incluye varios recursos que se pueden utilizar para aprender ms sobre la administracin de cuentas y recursos y la materia especca a Red Hat Enterprise Linux discutida en este captulo.

Los recursos siguientes son instalados durante el curso de una instalacin tpica de Red Hat Enterprise Linux y lo pueden ayudar a aprender ms sobre la materia discutida en este captulo.

La entrada de men Ayuda de Administrador de usuarios Conozca cmo manejar cuentas de usuarios y grupos. La pgina man de passwd(5) Aprenda ms sobre el formato de archivo para /etc/passwd. La pgina man de group(5) Conozca ms sobre la informacin del formato de archivo para /etc/group. La pgina man de shadow(5) Conozca ms sobre la informacin del formato de archivo para /etc/shadow. La pgina man de useradd(8) Aprenda cmo crear o actualizar las cuentas de usuario. La pgina man de userdel(8) Conozca cmo eliminar cuentas de usuarios. La pgina man de usermod(8) Aprenda a modicar las cuentas de usuarios. La pgina man de passwd(1) Aprenda a actualizar la contrasea de un usuario. La pgina man de chpasswd(8) Conozca cmo actualizar las contraseas de muchos usuarios a la vez. La pgina man de chage(1) Aprenda a cambiar la informacin referente a la vigencia de una contrasea. La pgina man de chfn(1) Vea cmo se puede cambiar la informacin GECOS de un usuario (finger). La pgina man de chsh(1) Aprenda a cambiar el intrprete de comandos de conexin de un usuario. La pgina man de groupadd(8) Para aprender a crear un nuevo grupo. La pgina man de groupdel(8) Aprenda a borrar un grupo. La pgina man de groupmod(8) Aprenda a modicar un grupo. La pgina man de gpasswd(1) Aprenda a administrar los archivos /etc/group y /etc/gshadow. La pgina man de grpck(1) Le muestra cmo vericar la integridad de los archivos /etc/group y /etc/gshadow. La pgina man de chgrp(1) Para aprender a cambiar la propiedad a nivel de grupo. La pgina man de chmod(1) Le muestra cmo cambiar los permisos de acceso a archivos. La pgina man de chown(1) Conozca cmo cambiar el dueo y grupo de un archivo.

http://www.bergen.org/ATC/Course/InfoTech/passwords.html Un buen ejemplo de un documento que reune informacin sobre la seguridad de contraseas para los usuarios en una organizacin.
142
http://www.crypticide.org/users/alecm/ La pgina principal del autor de uno de los programas de descifrado de contraseas ms populares (Crack). Puede descargar Crack desde esta pgina y vericar cuantos de sus usuarios tienen contraseas dbiles. http://www.linuxpowered.com/html/editorials/le.html Una buena descripcin general de los permisos de archivos en Linux.

Los libros siguientes describen varios problemas relacionados a la administracin 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 cin general de los aspectos relacionados a la seguridad de las cuentas de usuarios y a escoger contraseas robustas. El Manual de referencia de Red Hat Enterprise Linux; Red Hat, Inc. Contiene informacin detallada sobre los usuarios y grupos presentes en Red Hat Enterprise Linux. El Manual de administracin del sistema de Red Hat Enterprise Linux; Red Hat, Inc. Incluye un captulo sobre la conguracin de usuarios y grupos. Linux Administration Handbook por Evi Nemeth, Garth Snyder, y Trent R. Hein; Prentice Hall Proporciona un captulo sobre el mantenimiento de cuentas de usuarios, una seccin sobre se guridad pues se relaciona a los archivos de cuentas de usuarios, y una seccin sobre atributos de archivos y permisos.
Captulo 7.
Impresoras e impresin
Las impresoras son un recurso esencial para la creacin de una copia impresa una representacin fsica de los datos en papel la versin de los documentos para negocios, academia y uso en el hogar. Las impresoras se han convertido un perifrico indispensable en todos los niveles de negocios y computacin institucional. Este captulo discute las diferentes impresoras disponibles y compara sus usos en diferentes ambientes computacionales. Luego describe cmo se maneja la impresin en Red Hat Enterprise Linux.
7.1. Tipos de impresoras

Como cualquier otro perifrico, existen diferentes tipos de impresoras. Algunas impresoras emplean tecnologas que imitan la funcionalidad de las mquinas de escribir manuales, mientras que otras rocan tinta en el papel, o utilizan un lser para generar una imagen de la pgina 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 evalan 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 impresin

Existen varios factores a considerar en las evaluaciones de impresoras. Lo siguiente especica algunos de los criterios ms comunes cuando se evalan las necesidades computacionales. 7.1.1.1. Funcin La evaluacin de sus necesidades organizacionales y cmo una impresora sirve esas necesidades en un criterio esencial para determinar el tipo correcto de impresora para su ambiente. La pregunta ms importante es "Qu necesitamos imprimir?." Puesto que hay impresoras especializadas para texto, imgenes o cualquier variacin en medio, debe estar seguro de que adquiere la herramienta adecuada para sus propsitos. Por ejemplo, si sus requerimientos son de alta calidad de imgenes a color en papel brillante de grado profesional, se recomienda que utilice una impresora de sublimacin de tinte o de transferencia de color de cera trmica en vez de una impresora lser o de impcto. Recprocamente, las impresoras lser o de inyeccin de tinta son adecuadas para la impresin de borradores o documentos de distribucin interna (tales impresoras con altos volmenes de impresin se llaman impresoras de grupo de trabajo). Determinar las necesidades del usuario comn 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 pgina (llamado impresin simplex). La mayora de los modelos ms econmicos no tienen la funcionalidad de dplex por defecto (sin embargo, puede que tengan un mtodo dplex manual que requiere que el usuario voltee la pgina). Algunos modelos ofrecen hardware que se puede aadir para permitir esta funcionalidad; estos complementos de hardware pueden incrementar los costos consid erablemente. Sin embargo, la impresin en dplex 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
Captulo 7. Impresoras e impresin
Otro factor a considerar es el tamao del papel. La mayora de las impresoras son capaces de manejar los tamaos de papel ms 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 diseo) tienen necesidades especializadas como la creacin de posters o banners, existen impresoras de formato grande que son capaces de utilizar tamaos de papel A3 (297mm x 420mm) o tabloide (11" x 17"). Adems, hay impresoras capaces de tamaos an mayores, aunque estas se utilizan para propsitos especiales, tales como la impresin de huellas digitales. Adicionalmente, durante la evaluacin tambin se deben considerar funcionalidades ms avanzadas,tales como mdulos de redes para trabajo en grupo e impresin remota. 7.1.1.2. Costo El costo es otro factor a considerar cuando se evalen impresoras. Sin embargo, el determinar el costo nico asociado con la compra de la impresora misma no es suciente. Existen otros costos a considerar, tales como los consumibles,repuestos, mantenimiento y los complementos de hardware. Como el nombre implica, los consumibles es el trmino general utilizado para describir el material utilizado durante el proceso de impresin. 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 seleccin de la media depende en gran medida del tipo de informacin que se imprime. Por ejemplo, la creacin de una impresin exacta de una imagen digital requiere un papel brillante especial que pueda soportar la exposicin prolongada a la luz natural o articial, as como tambin asegurar la reproduccin 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 debera utilizar un papel mate (o sin brillo). Tambin 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 tambin pueden imprimir en transparencias, permitiendo que la informacin se pueda proyectar en una pantalla durante una presentacin. La media especializada, tal como la que mencionamos aqu, puede afectar el costo de los consumibles y se debera tomar en consideracin cuando se evalen las necesidades de impresin. La tinta es un trmino generalizado, ya que no todas las impresoras utilizan tinta lquida. Por ejemplo, las impresoras lser 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 impresin, mientras que otras rocan pequeas gotas de tinta sobre la media. Los costos de reemplazo de tinta varan 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 tecnologa ms antigua en produccin activa. Algunos de los fab ricantes ms grandes continuan produciendo, mercadeando y dando asistencia a las impresoras de
145
impacto, partes y suministros. Las impresoras de impacto son las ms funcionales en ambientes es pecializados donde los bajos costos de impresin son esenciales. Las tres formas ms comunes de impresoras de impacto son matriz de puntos, margarita e impresoras en lnea.
7.2.1. Impresoras de matriz de puntos

La tecnologa detrs 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 impresin. El cabezal de impresin movido electromagnticamente se mueve a lo largo del papel y golpea la cinta de impresin situada entre el papel y el pin del cabezal de impresin. El impacto del cabezal contra la cinta imprime puntos de tinta en el papel lo que forma los carcteres legibles. Las impresoras de matriz de puntos varan en resolucin de impresin y calidad en general con 9 o 24 pines en los cabezales de impresin. Mientras ms pines por pulgada, ms alta la resolucin de impresin. La mayora de las impresoras de matriz de puntos tienen una resolucin mxima de alrededor de 240 dpi o puntos por pulgada (en ingls, dots per inch). Mientras esta resolucin no es tan alta como las que se pueden obtener con las impresoras de inyeccin de tinta o lser, hay una ventaja distintiva en las impresoras de impacto. Debido a que el cabezal de impresin debe golpear la supercie del papel con fuerza suciente como para transferir la tinta desde la cinta hasta el papel, es ideal para ambientes que deben producir copias al carbn en documentos con mltiples partes. Estos documentos tienen carbn (u otro material sensible a la presin) en el lado interno y crea una marca en la pgina de abajo cuando se aplica presin. Los vendedores al detal y los pequeos negocios a menudo utilizan copias al carbn como recibos o facturas de ventas.
7.2.2. Impresoras margarita

Si ha trabajado con una mquina de escribir anteriormente, entonces entiende el concepto tecnolgico subyacente en las impresoras de margarita. Estas impresoras tienen cabezales compuestos de ruedas metlicas o plsticas cortadas en ptalos. Cada ptalo tiene la forma de una letra (en maysculas y minsculas), nmero o smbolo de puntuacin. Cuando se golpea el ptalo contra la cinta de impre sin, la forma resultante forza la tinta al papel. Las impresoras de margarita son ruidosas y lentas. No pueden imprimir grcos y no pueden cambiar las fuentes tipogrcas a menos que se reemplace fsicamente la rueda de impresin. Con la llegada de las impresoras lser, las impresoras de margarita no son comunes en los ambientes computacionales modernos.
7.2.3. Impresoras en lnea

Otro tipo de impresoras de impacto, de alguna manera similares a las impresoras de margarita, son las impresoras de lnea. Sin embargo, en vez de una rueda de impresin, las impresoras de lnea tienen un mecanismo que permite imprimir mltiples caracteres en la misma lnea. El mecanismo puede utilizar un tambor de impresin grande que gira o una cadena de impresin rotativa. Cuando la cadena o el tambor rotan sobre la supercie del papel, los martillos electromagnticos detrs del papel empujan el papel (junto con la cinta) en la supercie del tambor o cadena, marcando el papel con la forma del carcter en el tambor o cadena. Debido a la naturaleza del mecanismo de impresin, las impresoras de lnea son mucho ms rpidas que las de matriz de puntos o de margarita. Sin embargo, tienden a ser bastante ruidosas, tienen capacidades limitadas para utilizar multiples fuentes tipogrcas y a menudo producen calidad de impresin ms baja que las tecnologas de impresin ms recientes. Debido a que las impresoras de lnea son utilizadas por su velocidad, emplean papel de hojas con tinuas con perforaciones a los lados. Este arreglo permite la impresin continua a altas velocidades y desatendida, requiriendo paradas solamente cuando se acaba el papel.
146
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 lnea) requieren papel de hojas contnuas, lo cual puede incrementar un poco los costos de operacin.
7.3. Impresoras de inyeccin de tinta

Una impresora de inyeccin de tinta utiliza una de las tecnologas de impresin ms populares hoy en da. Los costos relativamente bajos y las habilidades de impresin de propsito mltiple hacen de las impresoras de inyeccin de tinta una buena seleccin para los pequeos negocios y las ocinas en casa. Las impresoras de inyeccin de tinta utilizan una tinta que se seca rpidamente, basada en agua y un cabezal de impresin con series de pequeas inyectores que rocan tinta a la supercie del papel. El ensamblado de impresin es conducido por un motor alimentado por una correa que mueve el cabezal a lo largo del papel. Las impresoras de inyeccin de tinta fueron fabricadas originalmente para imprimir solamente en monocromtico (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 combinacin de colores (llamada CMYK ) permite la impresin de imgenes con casi la misma calidad de un laboratorio de revelado fotogrco (cuando se utilizan ciertos tipos de papel). Cuando se combina con una calidad de impresin clara y de gran calidad de lectura, las impresoras de inyeccin de tinta se convierten en la seleccin de todo en uno para las necesidades de impresin monocromticas y a color.
7.3.1. Consumibles de inyeccin de tinta

Las impresoras de inyeccin de tinta tienden a ser econmicas y van aumentando de precio basado en la calidad de impresin, funcionalidades adicionales y la habilidad para imprimir en formatos ms grandes que los tamaos de papel estndar carta o legal. Mientras que el costo inicial de la compra de una impresora de inyeccin 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 inyeccin de tinta es grande y se extiende desde el hogar a la empresa, la adquisicin de consumibles puede ser costosa.
Nota Cuando est seleccionando una impresora de inyeccin 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 inyeccin 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 cmaras mltiples; a menos de que se tenga algn tipo de proceso de relleno, tan pronto como un color se acaba, se debe reemplazar el cartucho completo. Otras impresoras utilizan cartuchos con mltiples cmaras para cyan, magenta y amarillo, pero tambin tienen un cartucho separado para el negro. En ambientes donde se imprime grandes cantidades de texto, este tipo de arreglo puede ser benecioso. Sin embargo, la mejor solucin es encontrar una impresora con cartuchos separados para cada color; as, puede reemplazar fcilmente un color particular cuando este se termine.
Algunos fabricantes de impresoras de inyeccin de tinta tambin requieren utilizar papel tratado de alguna forma particular para imprimir imgenes y documentos de alta calidad. Algunos tipos de papel utilizan una capa con una frmula de alto brillo para absorber rpidamente las tintas de color, lo
147
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 patrn de lneas extraas). Consulte la documentacin de su impresora para ver la lista de papeles recomendados.
7.4. Impresoras lser

Otra alternativa comn son las impresoras lser, una tecnologa ms vieja que la de inyeccin de tinta. Las impresoras lser son conocidas por su alto volumen de salida y sus bajos costos por pgina. Las impresoras lser son empleadas a menudo en compaas como centros de impresin departamentales o de grupos de trabajo, donde la durabilidad, rendimiento y los requerimientos de salida son la prioridad. Como las impresoras lser satisfacen fcilmente estas necesidades (y a un costo por pgina razonable), esta tecnologa es ampliamente utilizada como el caballo de batalla en la impresin empresarial. Las impresoras lser comparten bastante de la tecnologa de las fotocopiadoras. Los rodillos jalan una hoja de papel desde una bandeja de papel y a travs de un rodillo cargador , el cual le d al papel una carga electrosttica. Al mismo tiempo, un tambor de impresin le d la carga contraria. La supercie del tambor es escaneada luego por el lser, descargando la supercie 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 supercie 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 travs de los rodillos de fusin, los cuales calientan el papel y derriten el toner, juntndolo con la supercie del papel.
7.4.1. Impresoras a color lser

Las impresoras lser a color tienen como objetivo combinar las mejores caractersticas de la tecnologa lser y de inyeccin de tinta en un paquete de propsito mltiple. La tecnologa est basada en la impresin tradicional monocromtica, pero utiliza componentes adicionales para crear imgenes y documentos a color. En vez de utilizar solamente un toner negro, las impresoras lser utilizan un toner con una combinacin CMYK. El tambor de impresin 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 travs del tambor, transriendo la imagen completa en el papel. Las impresoras lser a color tambin emplean un aceite de fusin junto con los rodillos de fusin calentados, lo cual junta an ms el color del toner al papel y proporciona diferentes niveles de brillo a la imagen nal. Debido a sus funcionalidades adicionales, las impresoras lser a color son usualmente el doble de cos tosas (o a veces ms) que las impresoras lser monocromticas. Al calcular el costo total de propiedad con respecto a los recursos de impresin, algunos administradores pueden desear separar la funcional idad monocromtica (texto) y color (imagen) a una impresora lser monocromtica dedicada y una a lser a color (o de inyeccin de tinta) respectivamente.
7.4.2. Consumibles para impresoras lser

Dependiendo del tipo de impresora lser instalada, los costos de consumibles son usualmente propor cionales al volumen de impresin. El toner viene en cartuchos que son inmediatamente reemplaza dos; sin embargo, algunos modelos vienen con cartuchos recargables. Las impresoras lser a color requieren de un cartucho para cada uno de los cuatro colores. Adicionalmente, las impresoras a color requieren el uso de aceites de fusin 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 lser a color; sin embargo, esto no es nada si se compara con su duracin de aproximadamente 6000 pginas, lo que es mucho ms que la vida til de las impresoras de inyeccin de tinta o de impacto. El tipo de papel es menos relevante con las impresoras lser, lo que signica que la compra en cantidades de papel xerogrco normal o de fotocopias, es aceptable para la mayora de los trabajos de impresin.
148
Sin embargo, si tiene pensado imprimir imgenes de alta calidad, debera optar por papel brilllante para lograr una apariencia ms profesional.
7.5. Otros tipos de impresoras

Existen otros tipos de impresoras disponibles, sobre todo impresoras de propsito especco para gr cos profesionales u organizaciones de publicidad. Sin embargo, estas impresoras no son de propsito general. Puesto que estn destinadas a un uso muy particular, sus precios (tanto de compra inicial como de consumibles) tienden a ser relativamente ms altos que las unidades ms comunes. Impresoras de cera termal Estas impresoras son utilizadas principalmente para transparencias de presentaciones de negocios y para pruebas de color (creacin de documentos e imgenes de prueba para una inspeccin ms en detalle antes de enviar el documento principal a la impresin industrial). Las impresoras de cera termal utilizan cintas CMYK conducidas por correas del tamao de una hojas de papel y papel con una capa especial o transparencias. El cabezal de impresin contiene elementos de calentamiento que derriten cada cera de color en el papel a medida que se rueda sobre la impresora. Impresoras de sublimacin de tinte Utilizada en organizaciones tales como ocinas de servicios donde la calidad profesional de los documentos, pametos y presentaciones, es ms importante que los costos de los consumibles las impresoras de sublimacin de tinte son los caballos de batalla para la impresin CMYK de calidad. Los conceptos detrs de las impresoras de sublimacin son similares a los de las impresoras de cera termal excepto por el uso de una pelcula de tinte de difusin plstica en vez de cera de color. El cabezal de impresin calienta la pelcula coloreada y vaporiza la imagen en el papel especialmente cubierto. Las impresoras de sublimacin son bastante populares en el mundo de diseo y publicidad as como tambin en el campo de investigacin cientca, donde se requiere precisin y detalles. Por supuesto, tal detalle y calidad de impresin viene a un precio: las impresoras de sublimacin de tinte son tambin conocidas por sus altos costos por pgina. Impresoras de tinta slida Utilizadas principalmente en la industria de empaquetamiento y diseo, las impresoras de tinta slida estn valoradas por su habilidad para imprimir en una amplia variedad de tipos de papel. Las impresoras de tinta slida, como su nombre lo implica, utilizan palillos de tinta endurecida que son derretidos y rociados a travs de pequeas boquillas en el cabezal de impresin. El papel es luego enviado a travs de un rodillo fusor que fuerza la tinta al papel. La impresora de tinta slida es ideal para prototipos y borradores de nuevos diseos para paquetes de productos; como tal, la mayora de los negocios orientados a servicios no tienen la necesidad de este tipo de impresoras.
7.6. Lenguajes y tecnologas de impresin

Antes de la llegada de la tecnologa de inyeccin de tinta, las impresoras de impacto solamente podan imprimir texto estndar, justicado y sin variaciones de tamaos o estilos de fuentes tipogrcas. Hoy da, las impresoras son capaces de procesar documentos complejos con imgenes incrustadas, grcos y tablas en mltiples esquemas y en diferentes idiomas, todo en una pgina. Tal complejidad se debe adherir a algunas convenciones de formatos. Esto es lo que ha desatado el desarrollo de los lenguajes de descripcin de pginas (o PDL) un lenguaje especializado de formato de documentos creado para la comunicacin con impresoras.
149
Con el paso de los aos, 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 impresin usando un PDL propietario a un peridico profesional, no haba ninguna garanta de que su archivo fuese compatible con la impresora de la mquina. Aparece entonces el problema de portabilidad. Xerox desarroll el protocolo Interpress para sus impresoras de lnea, pero nunca se logr la adopcin completa de este lenguaje por el resto de la industria de impresoras. Dos desarrolladores de Interpress dejaron Xerox y formaron Adobe, una compaa de software orientada bsicamente a los grcos electrnicos 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 informacin de imgenes que las impresoras pueden procesar. Al mismo tiempo, la com paa Hewlett-Packard desarroll el Printer Control Language (o PCL) para su uso en su lnea de impresoras lser y de inyeccin de tinta. PostScript y PCL son hoy da PDLs ampliamente compatibles y adoptados por la mayora de los fabricantes de impresoras. Los PDLs funcionan con el mismo principio que los lenguajes de programacin. Cuando un docu mento est listo para la impresin, la PC o estacin de trabajo toma las imgenes, la informacin tipogrca y la distribucin 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 lneas escaneadas que forman una imagen del documento (llamado Raster Image Processing o RIP), e im prime la salida en la pgina como una imagen completa con texto y grcos incluidos. Este proceso hace los documentos impresos ms consistentes, resultando en ninguna o muy poca variacin cuando se imprime el documento en modelos diferentes de impresoras. Los PDLs estn diseados para ser portables en cualquier formato y escalable para ajustarse a cualquier tamao de papel. La seleccin de la impresora correcta es una cuestin de determinar los estndares que los diferentes departamentos en su organizacin han adoptado para sus necesidades. La mayora de los departamen tos utilizan procesadores de texto y otros software de productividad que utilizan el lenguaje PostScript para la salida de impresin. Sin embargo, si su departamento de grcos requiere PCL u otra forma de impresin propietaria, debe tomar esto en consideracin tambin.
7.7. Impresin de red Versus Impresin local

Dependiendo de las necesidades de su organizacin, puede ser innecesario asignar una impresora a cada miembro de su organizacin. Tal solapamiento en gastos puede comer un presupuesto, dejando poco capital para otras necesidades. Mientras que las impresoras locales conectadas a travs de cable paralelo o USB a cada estacin de trabajo son la solucin ideal para cada usuario, usualmente no es econmico ni factible. Los fabricantes de impresoras han solucionado esta necesidad desarrollando impresoras departmen tales (o de grupos de trabajo). Estas mquinas son usualmente durables, rpidas y tienen consumibles con larga durabilidad. Las impresoras de grupos de trabajo estn conectadas a un servidor de impre sin, un dispositivo independiente (tal como una estacin de trabajo recongurada) que maneja los trabajos de impresin y los enruta a la impresora adecuada cuando est disponible. Las impresoras departamentales ms recientes incluyen interfaces de red incorporadas que eliminan la necesidad de un servidor de impresin dedicado.
7.8. Informacin especca de Red Hat Enterprise Linux

Lo siguiente describe las diferentes funcionalidades especcas a Red Hat Enterprise Linux rela cionadas con impresoras e impresin. La Herramienta de conguracin de impresoras permite a los usuarios congurar una impresora. Esta herramienta ayuda a mantener el archivo de conguracin de la impresora, los directorios spool de impresin y los ltros de impresin.
150
Red Hat Enterprise Linux 4 utiliza el sistema de impresin CUPS. Si un sistema fue actualizado desde una versin anterior de Red Hat Enterprise Linux que usaba CUPS, el proceso de actualizacin mantiene las colas conguradas. Para usar la Herramienta de conguracin de impresoras debe tener privilegios como root. Para ini ciar la aplicacin, seleccione Botn de men principal (en el Panel) => Conguracin del sistema => Impresin, o escriba el comando syste-config-printer. Este comando determina automti camente si ejecutar la versin grca o la versin basada en texto dependiendo de si el comando es ejecutado desde el ambiente grco o desde una consola basada en texto. Puede forzar a la Herramienta de conguracin de impresoras a ejecutarse como una aplicacin basada en texto, utilice el comando system-config-printer-tui desde el intrprete de coman dos.
Importante No modique el archivo /etc/printcap o los archivos en el directorio /etc/cups/. Cada vez que el demonio de impresin (cups) es iniciado o reiniciado, se crean dinmicamente nuevos archivos de conguracin. Los archivos tambin son creados dinmicamente cuando se aplican cambios con la Herramienta de conguracin de impresoras.
Figura 7-1. Herramienta de conguracin de impresoras Se pueden congurar los siguientes tipos de colas de impresin:

Conectada-localmente una impresora directamente conectada al computador a travs de un puerto paralelo o USB. Conectada CUPS (IPP) una impresora que puede ser accesada sobre una red TCP/IP a travs del protocolo de impresin de Internet, tambin 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 mquina Microsoft Windows). Conectada Novell (NCP) una impresora conectada a un sistema diferente el cual usa la tec nologa de red Novell NetWare.
151
Conectada JetDirect una impresora connectada directamente a la red a travs de HP JetDirect en vez de a un computador.
Importante Si agrega una nueva cola de impresin o modica una existente, debe aplicar los cambios para que tomen efecto.
Al hacer click en el botn Aplicar guarda cualquier cambio que haya realizado y reinicia el demo nio de impresin. Los cambios no son escritos al archivo de conguracin hasta que el demonio de impresin no sea reiniciado. Alternativamente, puede seleccionar Accin => Aplicar. Para ms informacin sobre la conguracin de impresoras bajo Red Hat Enterprise Linux consulte el Manual de administracin del sistema de Red Hat Enterprise Linux.

La conguracin de impresoras y la impresin en redes son tpicos amplios que requieren conocimiento y experiencia en hardware, redes y administracin de sistemas. Para informacin ms detallada sobre la instalacin de servicios de impresin en su entorno, consulte los recursos siguientes.

La pgina man de lpr(1) Conozca cmo imprimir archivos seleccionados en la impresora de su seleccin. La pgina man de lprm(1) Aprenda a eliminar trabajos de impresin de una cola de impresin. La pgina man de cupsd(8) Conozca un poco ms sobre el demonio de impresin CUPS. La pgina man de cupsd.conf(5) Aprenda sobre el formato del archivo de conguracin del demonio CUPS. La pgina man de classes.conf(5) Conozca ms sobre el formato para el archivo de cong uracin de clases CUPS. Archivos en /usr/share/doc/cups- version presin CUPS.
Ms informacin sobre el sistema de im

http://www.webopedia.com/TERM/p/printer.html Deniciones generales de impresoras y de scripciones de los tipos de impresoras. http://www.linuxprinting.org/ Una base de datos de documentos sobre impresin, junto con una base de datos de casi 1000 impresoras compatibles con las facilidades de impresin de Linux. http://www.cups.org/ Documentacin, FAQs, y grupos de noticias sobre CUPS.
152

Network Printing por Matthew Gast y Todd Radermacher; OReilly & Associates, Inc. Informa cin completa sobre el uso de Linux como servidor de impresin en entornos heterogneos. El Manual de administracin del sistema de Red Hat Enterprise Linux; Red Hat, Inc. Incluye un captulo sobre la conguracin de impresoras.
Captulo 8.
Planicacin para Desastres
La planicacin para desastres es fcil de olvidar para un administrador de sistemas no es agradable y siempre pareciera que hay algo ms importante que hacer. Sin embargo, dejar pasar la planicacin para desastres es una de las peores cosas que un administrador de sistemas puede hacer. Aunque a menudo se trata de los desastres dramticos (tales como un incendio, una inundacin o tormenta) lo que primero viene a la mente, los problemas ms 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 denicin de un desastre que un administrador debe tener en mente, es cualquier evento no planeado que pueda interrumpir la operacin normal de la organizacin. Aunque sera imposible listar todos los tipos diferentes de desastres que podran ocurrir, esta seccin examina los factores principales que forman parte de cada tipo de desastre para que asi cualquier exposicin a un desastre se pueda examinar no en trminos de su posibilidad, pero si de los factores que podran 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 fciles de entender - el hardware falla y el trabajo se detiene. Lo que es ms dicil de entender es la naturaleza de las fallas y cmo se puede minimizar su exposicin a ellas. He aqu algunos enfoques que puede utilizar: 8.1.1.1. Mantener partes adicionales de hardware En su forma ms 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 sucientes habilidades para diagnosticar el problema, identicar la parte defectuosa y reemplazarla. Est disponible un repuesto para el hardware defectuoso.
Estos problemas se cubren con ms 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
Captulo 8. Planicacin para Desastres
Sugerencia Antes de tomar este enfoque de reparar las cosas ud mismo, asegurese de que el hardware:
No se encuentra bajo garanta No est bajo ningn contrato de servicio/mantenimiento
Si usted trata de reparar un hardware que se encuentra cubierto por una garanta o contrato de servicio, lo ms probable es que estar violando los trminos del acuerdo y estar poniendo en peligro su cobertura.
Sin embargo, an con las habilidades mnimas, 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 almacn? Esta pregunta ilustra la naturaleza multifactica de las cosas relacionadas con desastres. Cuando con sidere qu repuestos tener en almacn, he aqu algunas de las cosas que debe tener en mente:

Tiempo mximo permitido fuera de servicio La habilidad requerida para hacer la reparacin El presupuesto disponible para los repuestos Espacio de almacenamiento requerido para los repuestos Otro hardware que podra utilizar el mismo repuesto
Cada uno de estos problemas tiene una trascendencia en los tipos de repuestos que se deberan guardar en almacn. Por ejemplo, al almacenar sistemas completos se tiende a reducir el tiempo fuera de servicio y requiere habilidades mnimas para instalar, pero sera muchsimo ms costoso que tener un CPU y un mdulo RAM de repuestos. Sin embargo, este costo puede ser justicado si su organizacin tiene varias docenas de servidores idnticos que se podranbeneciar de tener un sistema adicional de repuesto. No importa cual sea la decisin nal, la pregunta siguiente es inevitable y se discute a continuacin. 8.1.1.1.2.1. Cunto guardar en almacn? La pregunta de los niveles de repuestos es tambin multifactica. He aqu los principales problemas:

Tiempo mximo 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 podra utilizar el mismo repuesto
En un extremo, para un sistema que puede permitirse estar fuera de servicio dos das y una parte que puede ser utilizada una vez en un ao y que se puede reemplazar en un da, tendra sentido guardar solamente un repuesto (y quizs hasta ninguno, si tiene conanza de su habilidad de asegurar un repuesto en 24 horas).
155
Por otro lado, un sistema que no se puede permitir estar fuera de servicio ms que unos pocos minutos, y un repuesto que podra utilizarse una vez al mes (y que podra tomar semanas en reemplazar) podra signicar que se necesiten media docena de repuestos (o quizs ms).
8.1.1.1.3. Repuestos que no son repuestos Cundo un repuesto no es un repuesto? Cuando es hardware que se utiliza da a da pero que tambin est disponible como repuesto para un sistema de mayor prioridad, si surge la necesidad. Este enfoque tiene sus benecios:

Menos dinero dedicado a repuestos "no productivo" Se sabe que el hardware funciona
Sin embargo, este enfoque tiene sus desventajas:

La produccin normal de la tarea de menor prioridad es interrumpida Hay una exposicin si la tarea de menor prioridad falla (no dejando ningn repuesto para el hard ware de mayor prioridad)
Dadas estas limitaciones, el uso de otro sistema en produccin como un repuesto puede funcionar, pero el xito de este enfoque depende de la carga de trabajo especca del sistema y del impacto de la ausencia del sistema en las operaciones generales de la organizacin.
8.1.1.2. Contratos de servicios Los contratos de servicios pasan el problema de las fallas de hardware a alguien ms. Lo nico que necesita hacer es conrmar que ha ocurrido una falla y que no parece estar relacionado a un problema de software. Usted simplemente hace la llamada y alguien ms aparece para encargarse de que las cosas esten en funcionamiento otra vez Parece muy simple. Pero como con la mayora de las cosas en la vida, hay mucho ms de lo que el ojo puede ver. He aqu algunas cosas que debera 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 ms 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 despus aparezca un tcnico en la puerta. En vez de esto, dependiendo de su contrato, quizs ni siquiera pueda llamar a la compaa si no en un da/hora especca, o si puede, probablemente no enven un tcnico hasta la hora o fecha que est especicado en su contrato.
156
La mayora de las horas de cobertura son denidas en trminos de las horas y los das durante los cuales se puede enviar un tcnico. Algunas de las horas de cobertura ms comunes son:

Lunes a viernes desde las 09:00 hasta las 17:00 Lunes a viernes, 12/18/24 horas cada da (con los tiempos de comienzo y de nalizacin acordados mutuamente) Lunes a sbado (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 aadir sbado y domingo. Tambin aqu hay una posibilidad de reducir los costos si est dispuesto a hacer algo del trabajo. 8.1.1.2.1.1. Servicio de depsito Si su situacin no requiere ms que la disponibilidad de un tcnico durante las horas laborales nor males y tiene la experiencia suciente como para determinar lo que est daado, puede considerar la opcin de un servicio tcnico 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 tc nicos trabajan en el hardware que los clientes traen. Los servicios tcnicos tienen la ventaja de ser tan rpidos como usted. Usted no tiene que esperar a que un tcnico est disponible y vaya a sus ocinas. Los tcnicos de este tipo de servicio no se desplazan hasta sus instalaciones, lo que signica que alguien puede trabajar en su hardware tan pronto como usted lo pueda entregar en el servicio. Debido a que los Servicios Tcnicos se hacen una ubicacin 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 kilmetros de distancia desde otra ocina que al parecer posee una de estas partes en almacn. Sin embargo, esto tiene sus desventajas. La ms obvia es que usted no puede escoger las horas de servicio usted recibe el servicio cuando el Servicio Tcnico est abierto. Otro aspecto es que los tcnicos 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 Tcnico a las 5:00 pm, nadie trabajar en su equipo hasta el siguiente lunes en la maana. Otra desventaja es que el Servicio Tcnico depende de que se encuentre cercano a su negocio. Si su organizacin se encuentra ubicada en la zona metropolitana, es posible que esto no sea un problema. Sin embargo, las organizaciones en ubicaciones ms rurales pueden tener el Servicio Tcnico a un largo camino.
Sugerencia Si est considerando un Servicio Tcnico, tmese un momento para considerar los mecanismos para hacer llegar el hardware hasta el servicio. Utilizar el vehiculo de la compaa o propio? Si utiliza su propio vehculo, Su vehculo tiene el espacio y la capacidad de carga suciente?, Qu hay del seguro? Se necesitar ms de una persona para descargar el hardware? Aunque estas son preocupaciones mundanas, se deberan considerar antes de tomar la decisin de utilizar un Servicio Tcnico.
Captulo 8. Planicacin para Desastres 8.1.1.2.2. Tiempo de respuesta
157
Adems de las horas de cobertura, muchos acuerdos de servicios especican un nivel de tiempo de respuesta. En otras palabras, cuando usted llama pidiendo un servicio, cunto tiempo debe esperar hasta que llegue un tcnico? Como se puede imaginar, mientras ms rpida la respuesta ms costoso ser el acuerdo. Existen lmites 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 ms rpidas. Tiempos de respuesta ms lentos pueden ir desde ocho horas (lo que efectivamente se convierte en un servicio de "al da siguiente" para un acuerdo de horas laborales estndar) hasta 24 horas. De la misma manera que con los otros aspectos de un acuerdo de servicios, an estos tiempos son negociables por el precio correcto.
Nota An cuando no ocurre frecuentemente, debe estar consciente de que los acuerdos de servicios con clasulas de tiempos de respuesta, algunas veces pueden estirar el servicio de un fabricante ms 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 ocina" para solicitar que alguien traiga "la parte correcta". En realidad, estn esperando a que llegue la persona que es capaz realmente de manejar la llamada. Aunque quizs se pueda entender que esto ocurra bajo circunstancias extraordinarias (tales como problemas de energa que han daado los sistemas a lo largo del rea de servicio), si este es un mtodo consistente de operacin, debera contactar al gerente de servicios y solicitar una expli cacin.
Si sus necesidades de tiempo de respuesta son rigurosas (y su presupuesto adecuadamente grande), hay un enfoque que puede recortar sus tiempos de respuesta an ms inclusive a cero. 8.1.1.2.2.1. Tiempo de respuesta cero Disponer de un tcnico in situ Dada la situacin adecuada (usted es uno de los clientes ms grandes en la zona), necesidad suciente (el tiempo fuera de servicio de cualquier magnitud es inaceptable) y los recursos nancieros (si pre gunta por el precio, lo ms probable es que no lo pueda pagar), quizs sea un candidato para un tcnico a tiempo completo in situ. Los benecios de tener a un tcnico disponible son obvios:

Respuesta inmediata a cualquier problema Un enfoque ms proactivo al mantenimiento del sistema
Como puede esperarse, esta opcin puede ser muy costosa, particularmente si requiere de un tcnico in situ 24x7. Pero si este enfoque es apropiado para su organizacin, debe tener varios puntos en mente para sacar el mximo provecho. Primero, los tcnicos in situ necesitan muchos de los recursos de un empleado regular, tales como espacio de trabajo, telfono, tarjetas de acceso/llaves, etc. Los tcnicos in situ no son de mucha ayuda si no cuentan con las partes correctas. Por lo tanto, asegrese de que se tiene un almacenamiento seguro para los repuestos del tcnico. Adems, asegrese
1. Y esto probablemente se considere el mejor caso posible, pues usualmente los tcnicos son responsables por
territorios que se extienden fuera de la ocina en todas las direcciones. Si usted est en un extremo del territorio y el nico tcnico disponible est en el otro extremo, el tiempo de respuesta ser an mayor.
158
de que el tcnico mantenga un inventario de repuestos apropiado para su conguracin y que estas partes no sean consumidas por otros tcnicos para sus clientes.
8.1.1.2.3. Partes disponibles Obviamente, la disponibilidad de partes juega un papel importante en limitar la exposicin de su organizacin a fallas de hardware. En el contexto de un acuerdo de servicio, la disponibilidad de partes toma otra dimensin, pues la esta no solamente aplica a su organizacin, pero tambin a cualquier otro cliente en el territorio que pueda necesitar esas partes. Otra organizacin que ha comprado ms hardware del fabricante que usted, puede recibir un trato preferencial cuando se reere a conseguir los repuestos (y por ende los tcnicos). Lamentablemente, hay muy poco por hacer en tales circunstancias, ms all de tratar de resolver la situacin con el gerente de servicios. 8.1.1.2.4. Presupuesto disponible Como se mencion anteriormente, los contratos de servicios varan 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 mnimo. Considere por un momento que usted ha negociado un acuerdo de servicio que tiene a un tcnico 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 compaa utiliza para tareas no crticas. Esa PC realmente necesita a alguien in situ 24x7? An 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 maana siguiente (sin mencionar los nes 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 sbado en la noche, es una prdida de dinero. Lo que hay que hacer aqu es dividir el acuerdo de servicio de manera que el hardware que no sea crtico est agrupado de forma separada al hardware crtico. De esta forma, se pueden reducir los costos.
Nota Si tiene veinte servidores congurados de forma idntica que son crticos para su organizacin, puede estar tentado a tener un acuerdo de servicio de alto nivel para uno o dos, dejando el resto cubiertos por un acuerdo mucho ms econmico. Luego, no importa cual de los servidores falle durante el n de semana, usted dir que es uno de los elegibles para el servicio de alto nivel. No lo haga. No solamente es deshonesto, pero adems la mayora de los fabricantes hacen un seguimiento de tales cosas usando los nmeros de seriales. An si usted se las arregla para tales vericaciones, se gasta mucho ms luego de ser descubierto que siendo honesto y pagando por el servicio que realmente necesita.
159
8.1.2. Fallas del software

Algunas fallas de software pueden resultar en largos tiempos fuera de servicio. Por ejemplo, los dueos de cierta marca de computadores conocidos por sus funcionalidades de alta disponibilidad, descubren esto a primeras. Un error en el cdigo de manejo de tiempo del sistema operativo del com putador result en que los sistemas fallen a cierta hora de cierto da. Mientras que esta situacin es un ejemplo ms espectacular de una falla de software en accin, otras fallas relacionadas con el software pueden ser menos dramticas, pero an devastadoras. Las fallas del software pueden golpear en dos reas:

Sistema operativo Aplicaciones
Cada tipo de falla tiene su impacto especco y se exploran en ms 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 interrupcin del servicio. Las fallas del sistema operativo vienen de dos reas:

Cadas 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 produccin. 8.1.2.1.1. Cadas del sistema Las cadas ocurren cuando el sistema opertativo experimenta una condicin de error desde la cual no se puede recuperar. La razn de las cadas pueden variar desde una incapacidad para manejar un problema de hardware subyacente hasta un error en el cdigo a nivel del kernel abarcando el sistema operativo. Cuando un sistema operativo falla, se debe reiniciar el sistema para poder continuar la produccin. 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 (tambin conocido como deadlock, cuando dos recursos se disputan los recursos que el otro posee) o livelocks (dos o ms 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 nal una falta total de productividad.
160 8.1.2.2. Fallas de las aplicaciones
A diferencia de las fallas del sistema, las fallas de las aplicaciones pueden ser ms limitadas en el mbito de lo que daan. Dependiendo de la aplicacin especca, una sola aplicacin que est fallando puede afectar solamente a un usuario. Por otro lado, si se trata de una aplicacin de servidor que est sirviendo a una gran poblacin de aplicaciones clientes, las consecuencias de la falla seran mucho ms 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 aplicacin 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 mayora del trabajo lo puede hacer el personal de soporte a travs del telfono), 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 ms comunes empleadas hoy da.

Documentacin auto-asistencia Soporte de Web o de correo electrnico Soporte telefnico Soporte in situ
Cada tipo de asistencia se describe en ms detalles en las secciones siguientes. 8.1.2.3.1. Documentacin Aunque a veces es ignorada, la documentacin del software puede servir como una herramienta de soporte de primer nivel. Bien sea en lnea o impresa, la documentacin a menudo contiene la infor macin necesaria para resolver muchos problemas. 8.1.2.3.2. Auto asistencia La auto asistencia cona en que el cliente utiliza los recursos en lnea para resolver sus propios prob lemas relacionados al software. A menudo estos recursos toman la forma de FAQs (Preguntas ms frecuentes) basadas en el Web o bases de datos de conocimientos. Las FAQs tiene poca o ninguna capacidad de seleccin, 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 ms sosticadas, permitiendo la entrada de trminos para realizar bsquedas. Las bases de conocimientos tambin pueden ser bien completas en mbito, convirtindola en una buena herramienta para resolver problemas. 8.1.2.3.3. Soporte Web o de correo electrnico Muchas veces lo que a veces parece un sitio de auto asistencia, tambin incluye algunas formas basadas en web o correo electrnico 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.
161
Si el personal de soporte est saturado de trabajo, es dicil obtener la informacin necesaria de ellos, pues su principal preocupacin es la de responder rpidamente a cada correo y moverse al siguiente. La razn de esto es que casi todo el personal de soporte usualmente es evaluado por el nmero de problemas que pueden resolver. Los problemas de escalada tambin son complicados porque hay poco que hacer dentro de un correo electrnico para promover respuestas con mejores tiempos de respuestas y ms 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 electrnico responde todas las preguntas que un tcnico podra preguntarle, tales como:

Claramente describa la naturaleza del problema Incluya todos los nmeros de versin pertinentes Describa lo que ya ha hecho en un intento de resolver el problema (aplic los ltimos parches, reinicin con la conguracin mnima, etc.)
Al darle al tcnico de soporte ms informacin, tiene ms oportunidades de obtener la asistencia que necesita. 8.1.2.3.4. Soporte telefnico Como su nombre implica, el soporte telefnico implica hablar con un tcnico a travs del telfono. Este estilo de soporte es ms 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 Tambin conocido como consultoras in situ, el soporte de software in situ normalmente est reser vado para resolver problemas especcos o para efectuar cambios crticos, tales como la instalacin y conguracin inicial, actualizaciones importantes, etc. Como se puede esperar, este es el tipo de soporte ms costoso. Sin embargo, hay situaciones en las que las consultoras in situ tienen sentido. Como ejemplo con sidere una pequea organizacin con un nico administrador de sistemas. La organizacin va a im plementar su primer servidor de bases de datos, pero la implementacin (y la organizacin) no es lo sucientemente grande como para justicar la contratacin de un administrador de bases de datos ded icado. En esta situacin, a menudo puede ser ms econmico traer a un especialista de un proveedor de bases de datos para que maneje la implementacin inicial (y ocasionalmente ms 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 an cuando el hardware se est ejecutando perfectamente y aunque el software est congurado de la forma adecuada. Los problemas ms importantes que ocurren fuera del sistema mismo tienen que ver con el ambiente fsico en el cual reside el sistema. Los problemas ambientales se pueden desglosar en cuatro categoras:

Integridad del edicio Electricidad Aire acondicionado
162 Tiempo y el mundo exterior
8.1.3.1. Integridad del edicio Para ser una estructura tan simple, un edicio realiza una gran cantidad de funciones. Proporciona un refugio contra los elementos. Suministra el ambiente climtico adecuado para los contenidos del edicio. Tiene mecanismos para proporcionar energa y proteccin contra fuegos, robos y vandalismo. Para realizar todas estas funciones, no es una sorpresa que hayan muchas cosas que pueden salir mal con un edicio. He aqu algunas de las posibilidades a considerar:

Los techos pueden tener goteras, dejando pasar agua hasta los centros de datos. Varios sistemas del edicio (tales como agua, desagues, o manejo del aire) pueden fallar, dejando el edicio inhabitable. Los pisos puede que no tengan suciente 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 edicio puede fallar. La lista de arriba solamente es un comienzo para ponerlo a pensar en esta direccin. 8.1.3.2. Electricidad Debido a que la electricidad es como la sangre de cualquier sistema computacional, los problemas relacionados a la energa son de suprema importancia en la mente de un administrador de sistemas. Hay muchos aspectos diferentes sobre la electricidad; estos se cubren con ms detalles en las secciones siguientes. 8.1.3.2.1. La seguridad de su energa Primero, es necesario determinar que tan seguro es su suministro de energa. De la misma forma que cualquier otro centro de datos, probablemente obtenga su electricidad desde la compaa elc trica local a travs de lneas de transmisin. Debido a esto, hay lmites para lo que puede hacer para asegurarse de que su suministro principal de energa es tan seguro como pueda ser posible.
Sugerencia Las organizaciones ubicadas cercanas a una compaa elctrica quizs puedan negociar conex iones a dos rejillas de energa diferentes:
La que sirve a su zona La que viene de la compaa elctrica vecina
Los costos asociados con la implementacin de lneas elctricas directas desde la rejilla vecina son considerables, haciendo esto una opcin solamente para organizaciones bastante grandes. Sin embargo, a tales organizaciones les puede parecer que la redundancia obtenida es mucho ms valiosa que los costos en muchos casos.
Aqu, lo principal a vericar son los mtodos a travs de los cuales la energa es trada a las instala ciones de su organizacin y dentro del edicio. Las lneas de transmisin estn por debajo o sobre la tierra? Las lneas sobre el suelo son susceptibles a:
Daos por condiciones ambientales extremas (hielo, viento, relmpagos)
Captulo 8. Planicacin para Desastres Accidentes de trnsito que daan los postes y/o transformadores Animales perdidos en el lugar incorrecto y cortando las lneas
163
Sin embargo, las lneas bajo tierra tienen sus limitaciones nicas:

Daos de trabajadores de construccin cavando en los lugares incorrectos Inundaciones Relmpagos (sin embargo, mucho menos que con las lneas sobre la tierra)
Continue haciendo un seguimiento a las lneas elctricas dentro de su edicio. Primero van a un transformador externo? Est el transformador protegido contra vehculos o contra rboles que se puedan caer sobre el? Los interruptores de apagado estn protegidos contra usos no autorizados? Ya dentro del edicio, pueden estar las lneas de energa (o los pneles a las cuales se conectan) sujetas a otros problemas? Por ejemplo, puede un problema de plomera inundar la sala elctrica? Continue haciendo el seguimiento de la energa hasta el centro de datos; hay alguna otra cosa ines perada que pueda interrumpir el suministro de energa? Por ejemplo, est el centro de datos compar tiendo uno o ms circuitos con cargas que no son del centro de datos? Si es as, la carga externa puede un da de estos hacer que se caiga la proteccin de sobrecarga del circuito, dejando fuera de servicio al centro de datos tambin. 8.1.3.2.2. Calidad de la electricidad No es suciente con asegurarse que la fuente de energa de su centro de datos est bien protegida. Tambin debe considerar la calidad de la energa que est siendo distribuida a su centro de datos. Hay muchos factores que debe considerar: Voltaje El voltaje de la energa 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 mnimo THD (Total Harmonic Distortion). Frecuencia La frecuencia debe ser estable (la mayora de los pases utilizan una frecuencia de energa de 50Hz o 60Hz). Ruido La energa no debe incluir ningn ruido de RFI (Interferencia de Frecuencia de Radio) o EMI (Interferencia electro-magntica). Corriente La energa se debe suministrar a una tasa suciente como para correr el centro de datos. La energa suministrada desde la compaa elctrica normalmente no satisface los estndares necesar ios para un centro de datos. Por lo tanto, usualmente se requiere un nivel de condicionamiento de la energa. Hay varios enfoques para hacer esto posible:
164 Protectores de corriente
Los protectores de corriente hacen exctamente lo que su nombre indica ltran el oleaje de la fuente de poder. La mayora no hacen nada ms que esto, dejando los equipos vulnerables a otros problemas relacionados con la energa. Acondicionadores de energa Los acondicionadores de energa tratan de lograr un enfoque ms completo; dependiendo de lo sosticado que sea la unidad, los acondicionadores de energa a menudo cubren la mayora de los problemas descritos arriba. Conjuntos de Moto-generadores Un moto-generador esencialmente es un motor elctrico 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 sucientes cantidades para correr el centro de datos. De esta forma, la energa del centro de datos est sepa rada de la electricidad externa, lo que signica que se eliminan una gran parte de los problemas relacionados con la electricidad. La rueda voladora tambin permite la habilidad de mantener energa durante interrupciones elctricas cortas, pues toma varios segundos para que la rueda se detenga al punto en que ya no genere energa. Fuentes De Alimentacin Continuas Algunos tipos de Fuentes de Alimentacin Contnuas, ms conocidos como UPS, incluyen la mayora (si no es que todas) las funcionalidades de un acondicionador de energa 2 . Con las ltimas dos tecnologas discutidas anteriormente, hemos comenzado con el tpico con el que la mayora de la gente se relaciona cuando piensa sobre energa energa de reserva. En la prxima seccin, se exploran diferentes enfoques sobre el suministro de energa de reserva. 8.1.3.2.3. Energa de reserva Un trmino relacionado con la energa que casi todo el mundo ha escuchado es un apagn. Un apagn es una prdida completa de energa y puede durar una fraccin de segundos o semanas. Debido a que la extensin de los apagones puede variar muchsimo, es necesario abordar la tarea de suministrar energa usando tecnologas diferentes para apagones de diferente duracin.
Sugerencia La mayora de los apagones frecuentes duran, en promedio, no ms que unos pocos segundos; los apagones ms largos son mucho menos frecuentes. En consecuencia, concntrese primero en los apagones de solamente unos pocos minutos de duracin, luego piense en los mtodos a utilizar para protegerse de apagones ms largos.
8.1.3.2.3.1. Suministrar energa por pocos segundos Puesto que la mayora de las interrupciones duran slo unos segundos, su solucin de energa de reserva debe tener dos caractersticas principales:

Corto tiempo para cambiarse a la energa de reserva (conocido como tiempo de transferencia) Un tiempo de ejecucin (el tiempo que durar la energa de reserva) medido en segundos a minutos
La tecnologa de UPS se discute en ms detalles en la Seccin 8.1.3.2.3.2.
2.
165
Las soluciones de energa de reserva que satisfacen estas caractersticas 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 suciente para cubrir interrupciones de un segundo o un poco ms. Los moto-generadores tienden a ser bastante grandes y costosos, haciendolos una solucin prc tica solamente para los centros de datos de mediano a gran tamao. Sin embargo, otra tecnologa llamada un UPS puede cubrir estas situaciones donde un moto generador es demasiado costoso. Tambin pueden manejar interrupciones ms largas. 8.1.3.2.3.2. Suministrar energa por pocos minutos Los UPSs se pueden comprar en una variedad de tamaos - lo sucientemente pequeo como para ejecutar una sola PC por cinco minutos o lo sucientemente poderoso como para ejecutar el centro de datos completo por una hora o ms. Los UPSs estn formados por las partes siguientes:

Un switch de transferencia para intercambiarse desde la fuente primaria de poder a la fuente de energa de reserva Una batera, para suministrar la energa de reserva Un inversor , el cual convierte la corriente DC desde la batera a corriente AC requerida por el hardware del centro de datos
Aparte del tamao y la capacidad de la batera de la unidad, los UPSs vienen en dos tipos bsicos:

Los UPSs fuera de lnea utilizan un inversor para generar energa solamente cuando falla el sumin istro principal de poder. Un UPSs en lnea utiliza un inversor para generar energa todo el tiempo, activando el inversor a travs de su batera solamente cuando la fuente principal de energa falle.
Cada tipo tiene sus ventajas y desventajas. Un UPS fuera de lnea usualmente es menos costoso, debido a que el convertidor no tiene que ser construdo para operar todo el tiempo. Sin embargo, si ocurre un problema con el UPS fuera de lnea esto pasar inadvertidamente (hasta que ocurra la prxima interrupcin elctrica). Los UPSs en lnea tienden a ser mejor en proporcionar energa limpia para su centro de datos; despus de todo, un UPS en lnea bsicamente est generando energa para usted a tiempo completo. Pero no importa qu tipo de UPS usted seleccione, debe medir el tamao de su UPS para anticipar la carga (asegurando por tanto que el UPS tiene energa suciente para producir electricidad al nivel de voltage y corriente requerido), y debe determinar cunto tiempo le gustara ejecutar su centro de datos usando la energa de la batera. Para determinar esta informacin, primero debe determinar las cargas que el UPS servir. Revise cada equipo y determine cunta energa necesita (esto normalmente est listado en una etiqueta cerca del cable elctrico de la unidad). Escriba el voltaje, los watts y/o amperios. Una vez que tenga estos nmeros para todo el hardware, debe convertirlos a VA (Volt-Amps). Si tiene un nmero de vatiaje, puede utilizar el vatiaje listado como VA; si tiene amperios, multipliquelo por los voltios para obtener el VA. Al aadir los nmeros de vatiaje puede llegar al nmero aproximado VA requerido por el UPS.
Nota Siendo ms especcos, este enfoque para calcular el VA no es correcto; sin embargo, para obtener el verdadero VA necesitara conocer el factos de energa para cada unidad y esta informacin, rara mente se encuentra disponible. En cualquier caso, los nmeros de VA obtenidos usando este en foque, reejan los valores del peor caso, dejndole un margen de error por razones de seguridad.
166
Determinar el tiempo de ejecucin es ms que una pregunta de negocios que tcnica - cpntra qu tipo de interrupciones est dispuesto a protegerse y cunto dinero est dispuesto a gastar para hacerlo? La mayora de los sitios selecciona tiempos de ejecucin menores que una hora o dos como mximo, pues a partir de este punto la energa a partir de las baterias se vuelve bastante costosa. 8.1.3.2.3.3. Suministrar energa por las prximas horas (y ms) Una vez que llegamos al punto de interrupciones elctricas que se miden en das, las opciones se vuelven ms costosas. Las tecnologas capaces de manejar interrupciones elctricas de largo tiempo estn limitadas a generadores activados por algn tipo de motor - principalmente diesel o de turbinas.
Nota Tenga en mente que los generadores activados a travs de motores requieren de recargas regulares mientras se esten ejecutando. Debera conocer la tasa de uso de su combustible con una carga mxima y programar las entregas de combustible de acuerdo a esto.
En este punto, sus opciones son bien abiertas, asumiendo que su organizacin tiene los fondos sucientes. Esto tambin es un rea en la que los expertos deberan ayudarlo a determinar la mejor solucin posible para su organizacin. Muy pocos administradores de sistemas tienen el conocimiento especializado necesario para planear la adquisicin y despliegue de estos tipos de sistemas de generacin de energa.
Sugerencia Se pueden rentar generadores portables de todos los tamaos, haciendo posible tener los benecios 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 sern difciles de obtener y muy costosos.
8.1.3.2.4. Planicacin para interrupciones prolongadas Mientras que un apagn de cinco minutos es solamente un poco ms que una inconveniencia para el personal en una ocina a oscuras, qu tal si el apagn dura una hora? cinco horas, un da, una semana? El hecho es, an si el centro de datos est operando normalmente, en algn punto una interrupcin prolongada eventualmente afectar a su organizacin. 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 suciente para mantener el control ambiental en todo el edicio? Qu pasa si no hay energa para operar las estaciones de trabajo, el sistema telefnico, las luces?
El punto aqu es que su organizacin debe determinar a qu punto una interrupcin prolongada tendr que simplemente ser tolerada. Si esto no es una opcin, su organizacin debe reconsiderar su habilidad para funcionar de forma completamente independiente de un sitio con electricidad, lo que signica que se necesitaran generadores muy grandes para servir a un edicio completo.
167
Por supuesto, an este nivel de planicacin no puede ocurrir en un vaco. Es muy probable que lo que sea que est causando la interrupcin prolongada, tambin est afectando el mundo externo a su orga nizacin, y que el mundo externo comenzar a tener un efecto en la habilidad de su organizacin para continuar sus operaciones, an cuando se tenga capacidad de generar electricidad de forma ilimitada.
8.1.3.3. Calefaccin, Ventilacin y Aire Acondicionado Los sistemas de Calefaccin, Ventilacin y Aire Acondicionado ( Heating, Ventilation, and Air Con ditioning, HVAC) utilizados en los edicios de ocinas de hoy da, son increblemente sosticados. A menudo controlados por computadoras, el sistema HVAC es vital para proporcionar un ambiente laboral cmodo. 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 electromagntica, las posibilidades de una falla son muchas y variadas. He aqu algunos ejemplos:

Las unidades de manejo de aire acondicionado (esencialmente grandes ventiladores elctricos) pueden fallar debido a la sobrecarga elctrica, una falla, falla de la correa/polea, etc. Las unidades de enfriamiento (a menudo llamadas chillers) pueden perder su refrigerante debido a ltraciones o tomar sus compresores y/o motores.
La reparacin y mantenimiento de un HVAC es un campo muy especializado - un campo que el administrador de sistemas promedio debera 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 energa y las comunicaciones, con vientos extremada mente fuertes daando inclusive el edicio mismo.
Hay otros tipos de tiempo que tambin pueden provocar problemas, an 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 elctrico 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 razn detrs de esta armacin es que si usted profundiza lo suciente, detrs de cada error computacional encontrar el error humano que lo caus. En esta seccin se exploran los tipos de errores humanos ms comunes y sus impactos.
168 8.1.4.1. Errores humanos del usuario nal
Los usuarios pueden cometer errores que podran 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 mayora de los usuarios interactuan exclusivamente con una computadora por una o ms aplicaciones, usualmente es dentro de las aplicaciones que ocurren la mayora 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 aplicacin Archivos no claramente nombrados u organizados Archivos borrados accidentalmente
La lista puede continuar, pero esto es suciente para ilustrar la situacin. 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 tcnicas correctas de admin istracin de archivos Asegurese de que se hacen copias de respaldo regulares de los archivos de sus usuarios y de que el proceso de restauracin es tan organizado y rpido como sea posible
Ms all de aqu, es poco los que se puede hacer para mantener los errores de los usuarios a un mnimo.
8.1.4.2. Errores del personal de operaciones Los operadores tienen una relacin ms profunda con las computadoras de una organizacin que los usuarios nales. Mientras que los errores de un usuario tienden a ser orientados a aplicaciones, los de los operadores tienden a llevar a cabo un rango ms 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 daos ms 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 accin que realizan3 . Puede ser que un operador no siga los procedimientos de la forma en que estos estn establecidos. Puede haber varias razones para esto:

El ambiente fue modicado en algn 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
Si los operadores en su organizacin no tienen procedimientos de operacin, trabaje en con ellos, la gerencia
3.
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.
169
invlido. 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 modicado y no existen procedimientos. Esto es simplemente una versin ms fuera de control que la situacin anterior. Los procedimientos existen y son correctos, pero el operador no los seguir (o no puede).
Dependiendo de la estructura gerencial de su organizacin, quizs no pueda hacer mucho ms 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 An si el operador sigue los procedimientos y aunque los procedimientos esten correctos, todava se pueden cometer errores. Si esto ocurre, existe la posibilidad de que el operador sea descuidado (en cuyo caso se debera involucrar al supervisor del operador). Otra explicacin 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 estn 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 ms por un operador con buenas intenciones puede amenazar la carrera de la persona y su habilidad para resolver rpidamente un problema que quizs originalmente era un problema pequeo.
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 organizacin. Tambin a diferencia de los operadores, las tareas que los ad ministradores de sistemas llevan a cabo a menudo no estn 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 estn haciendo. Durante el curso de llevar a cabo las respons abilidades diarias, los administradores de sistemas tienen acceso ms que suciente a los sistemas computacionales (sin mencionar los privilegios de superusuario) como para afectar accidentalmente los sistemas. Los administradores de sistemas cometen errores de conguracin o durante el mantenimiento. 8.1.4.3.1. Errores de conguracin Los administradores de sistemas a menudo deben congurar varios aspectos de un sistema computa cional. Esta conguracin incluye:

Correo electrnico Cuentas de usuarios Red Aplicaciones
La lista puede extenderse mucho ms. La tarea actual de congurar vara en gran medida; algunas tareas requieren editar un archivo de texto (usando cualquiera de los cientos de sintaxis de archivos de conguracin), mientras que otras tareas requieren la ejecucin de alguna utilidad de conguracin. El hecho de que estas tareas son manejadas de forma diferente es simplemente un reto adicional al hecho bsico de que cada tarea de conguracin requiere un conocimiento diferente. Por ejemplo,
170
el conocimiento requerido para congurar un agente de transporte de correo es fundamentalmente diferente al conocimiento requerido para congurar una conexin de red. Dado todo esto, quizs debera ser una sorpresa que solamente se cometen unos pocos errores. En cualquier caso, la conguracin 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 comn de cada cambio de conguracin es que ha ocurrido algn tipo de cambio. El cambio puede ser grande o puede ser pequeo. Pero an se trata de un cambio y debera ser tratado de una forma particular. Muchas organizaciones implementan algn tipo de proceso de control de cambios. La intencin 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 exposicin de la organizacin a cualquier error que pueda ocurrir. Un proceso de control de cambios normalmente desglosa el cambio en pasos diferentes. He aqu un ejemplo: Investigacin preliminar La investigacin preliminar intenta denir claramente:

La naturaleza del cambio que tomar lugar Su impacto, si el cambio es exitoso Una posicin de retroceso, si el cambio falla Una evaluacin de qu tipos de falla son posibles
La investigacin preliminar puede incluir probar el cambio propuesto durante el tiempo plan icado fuera de servicio, o puede ir tan all como para incluir la implementacin del cambio primero en un ambiente de prueba especial, ejecutndose en un hardware dedicado para las eval uaciones. Planicacin Se examina el cambio con un ojo hacia las mecnicas actuales de la implementacin. La plani cacin se hace incluyendo una descripcin 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 tambin asegurarse de que el tiempo asignado para los cambios es suciente y no entra en conicto con ninguna otra actividad a nivel de sistemas. El producto de este proceso a menudo es una lista de vericacin de pasos para que la use el administrador del sistemas mientras est llevando a cabo el cambio. Junto con cada paso estn 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 fcil para que el administrador del sistema determine si el trabajo est dentro de la planicacin o no. Ejecucin En este punto, la ejecucin real de los pasos necesarios para implementar el cambio debera ser directa y anti-culminante. El cambio es implementado o (si ocurren errores) se cancela. Supervisin Bien sea que se implemente el cambio o no, se monitoriza el ambiente para asegurarse de que todo est funcionando como debera.
Captulo 8. Planicacin para Desastres Documentacin
171
Si se implementa el cambio, toda la documentacin existente se actualiza para reejar la cong uracin modicada. Obviamente, no todos los cambios de conguracin requieren este nivel de detalles. La creacin de una cuenta de usuarios no requiere ninguna investigacin preliminar y la planicacin probablemente consistir de determinar si el administrador tiene tiempo libre para crear una cuenta. La ejecucin sera igualmente rpida; la monitorizacin consiste de asegurarse de que la cuenta es utilizable y la documentacin probablemente consistir en enviar un correo electrnico al supervisor del usuario. Pero a medida que la conguracin se vuelve ms compleja, se hace necesario un proceso de control de cambios ms formal.
8.1.4.3.2. Errores cometidos durante el mantenimiento Este tipo de errores pueden ser insidiosos porque se hace muy poca planicacin o seguimiento du rante el mantenimiento de da a da. 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 arma 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 cuestin 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 rpidamente. Un verdadero proceso del control del cambio no es realstico para los cientos de cosas que se hacen durante un da. 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 ms oportunidades de notar una falla como relacionada a un cambio que realiz recientemente.
8.1.4.4. Errores de Servicio Tcnico Algunas veces la propia gente que se supone debera ayudarlo a mantener sus sistemas funcionando conablemente, son los que complican ms las cosas. Esto no se debe a ninguna conspiracin; es simplemente por el hecho de que cualquiera que est trabajando en una tecnologa por alguna razn, arriesga el hacer esa tecnologa 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 tcnico fall en diagnosticar el problema correctamente y realiz una reparacin innecesaria (e intil), o el diagnstico fue correcto, pero la reparacin 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 reparacin. Por eso es importante estar al tanto de lo que est haciendo el tcnico 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 tcnico en carril por si hay un problema; de lo contrario hay oportunidad de que el tcnico 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.
172 8.1.4.4.2. Reparar una cosa y daar otra
Algunas veces, an cuando se diagnostic y repar el problema exitsamente, surge otro problema en su lugar. Se reemplaz el mdulo del CPU, pero la bolsa antiesttica 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 formacin RAID, pero puesto que se golpe accidentalmente un conector en otra unidad y se desconect, la formacin RAID continua fuera de servicio. Estas cosas pueden ser el resultado de descuidos crnicos o de un error honesto. No importa. Lo que siempre debe hacer es revisar cuidadosamente las reparaciones realizadas por un tcnico y asegurarse de que el sistema est funcionando correctamente antes de dejar que el tcnico se retire.
8.2. Respaldos
Los respaldos o copias de seguridad tienen dos objetivos principales:

Permitir la restauracin de archivos individuales Permitir la restauracin completa de sistemas de archivos completos
El primer propsito es la base para las peticiones tpicas 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 ms comn de los respaldos. La segunda situacin es la peor pesadilla de un administrador de sistemas: por la situacin que sea, el administrador se queda observando un hardware que sola ser una parte productiva del centro de datos. Ahora, no es ms que un pedazo de acero y silicon intil. Lo que est faltando en todo el software y los datos que usted y sus usuarios habian reunido por aos. 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 tpico. Observe que algunos de los datos raramente cambian y otros cambian constantemente. El ritmo al cual los datos cambian es crucial para el diseo de un procedimiento de respaldo. Hay dos razones para esto:

Un respaldo no es ms que una instantnea de los datos respaldados. Es un reejo 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 deberan ser capaces de agrupar rpidamente en sus sistemas en diferentes categoras. Sin embargo, he aqu algunos ejemplos para comenzar:
4. Estamos usando el trmino datos en esta seccin para describir cualquier cosa que se procesa por el software
de respaldo. Esto incluye software del sistema operativo, software de aplicaciones, as como tambin los datos reales. No importa lo que sea, para el software de respaldos, todos son datos.
Captulo 8. Planicacin para Desastres Sistema operativo
173
Estos datos solamente cambia durante las actualizaciones, las instalaciones de reparaciones de errores y cualquier modicacin especca al sitio.
Sugerencia Debera de molestarse con el respaldo del sistema operativo? Esta es una pregunta que muchos administradores de sistemas operativos han evaluado por muchos aos. Por un lado, si el proceso de instalacin es relativamente fcil y si las reparaciones de fallos y personalizaciones estn bien documentadas y son fciles de reproducir, la reinstalacin del sistema operativo puede ser una opcin viable. Por otro lado, si hay alguna duda de que una instalacin fresca pueda recrear completamente el ambiente original del sistema, el respaldo del sistema operativo es la mejor opcin, an si los respaldo se realizaron con mucho menos frecuencia que los respaldos de datos de produccin. Los respaldos ocasionales de sistemas operativos son tiles cuando se deben restaurar solamente unos pocos sistemas operativos (por ejemplo, debido a la eliminacin 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 aplicacin especca y su organizacin, esto puede signicar que los cambios toman lugar segundo a segundo o al nal del ao scal. Datos de usuarios Estos datos cambian de acuerdo a los patrones de uso de su comunidad de usuarios. En la mayora de las organizaciones, esto signica que los cambios toman lugar todo el tiempo. Basado en estas categoras (y cualquier otra adicional que sean especcas a su organizacin), usted debera 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 mayora 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 cmo se ejectuten los respaldos. Esta es otra razn 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 bsica de hacer copias de bits en una media de respaldo, tambin debe interactuar limpiamente con el personal y las necesidades de su organizacin. Algunas de las funcionalidades a considerar cuando evalue software de respaldo incluyen:
Planica respaldos para que se ejecuten en el momento adecuado
174
Maneja la ubicacin, rotacin y uso de la media de respaldo Funciona con operadores (y/o cargadores robticos) para asegurarse de que la media apropiada est disponible Asiste a los operadores en ubicar la media que contiene un respaldo especco de un archivo dado
Como puede observar, una solucin de respaldo del mundo real implica mucho ms que simplemente escribir bits en su media de respaldo. La mayora de los administradores de sistemas en este punto, ven hacia una de dos soluciones:

Comprar una solucin desarrollada comercialmente Desarrollar una solucin casera de sistema de respaldo desde el principio (posiblemente integrando una o ms tecnologas de cdigo abierto)
Cada enfoque tiene sus puntos buenos y sus puntos malos. Dada la complejidad de la tarea, una solu cin casera probablemente no maneje todos los aspectos (tales como administracin de media, o tener el soporte tcnico y la documentacin completa) muy bien. Sin embargo, para algunas organizaciones, esto quizs no sea una limitacin. Una solucin desarrollada comercialmente es ms probable que sea altamente funcional, pero tambin excesivamente compleja para las necesidades presentes de la organizacin. Dicho esto, la complejidad puede hacer posible mantenerse con una solucin aun si la organizacin crece. Como puede ver, no hay un mtodo claro para decidirse sobre un sistema de respaldo. La nica gua 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. Despus de todo, tendr archivos de respaldo por largo tiempo que podr leer. El cambiar el software de respaldo signica 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 travs de un programa de conversin ya existente, o puede requerir ingeniera inversa del formato de respaldo y escribir un software personalizado para realizar esta tarea.
El software debe ser 100% conable - 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% conable.
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 mayora pensara que un respaldo es una copia idntica 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 sera idntico que el del martes. Mientras que es posible congurar los respaldos de esta forma, es probable que no lo haga. Para entender un poco ms sobre esto, primero se debe entender los tipos de respaldo que se pueden crear. Estos son:

Respaldos completos Respaldos incrementales Respaldos diferenciales
Captulo 8. Planicacin para Desastres 8.2.3.1. Respaldos completos
175
El tipo de respaldo discutido al principio de esta seccin 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 verica para ver si un archivo ha cambiado desde el ltimo respaldo; ciegamente escribe todo a la media de respaldo, haya sido modicada o no. Esta es la razn por la que los respaldos completos no se hacen todo el tiempo - cada archivo es escrito a la media de respaldo. Esto signica el uso de gran cantidad de media de respaldo an cuando nada se haya cambiado. Respaldar 100 GB de datos cada noche cuando solamente cambi 10 MB de datos, no es una buena solucin; 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 modicacin de un archivo es ms reciente que la fecha de su ltimo respaldo. Si no lo es, signica que el archivo no ha sido modicado desde su ltimo respaldo y por tanto se puede saltar esta vez. Por otro lado, si la fecha de modicacin es ms reciente, el archivo ha sido modicado y se debera 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 muchsimo ms rpido que un respaldo completo. La principal desventaja es que restaurar un archivo dado puede implicar pasar a travs 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 travs 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 modicados. Sin embargo, los respaldos diferenciales son acumula tivos en otras palabras, con un respaldo diferencial, una vez que un archivo ha sido modicado continua siendo includo en todos los respaldos diferenciales subsecuentes (hasta el prximo respaldo completo). Esto signica que cada respaldo diferencial contiene todos los archivos modicados desde el l timo respaldo completo, haciendo posible realizar una restauracin 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 peridico seguido de ms 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 modicados con el paso del tiempo entre respaldos completos). Esto coloca los respaldos diferenciales en un punto entre los respaldos incrementales y los completos en trminos de utilizacin de la media y velocidad de los respaldos, mientras que ofrecen restauraciones completas y de archivos individuales mucho ms rp idas (debido a que hay menos respaldos en los que buscar/restaurar). Dadas estas caractersticas, vale la pena considerar cuidadosamente los respaldos diferenciales.
176
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 razn para esto. Los administradores de sistemas ms experimentados usualmente piensan sobre respaldos en trminos de leer y escribir en cintas, pero hoy da existen otras opciones. En algn momento, los dispositivos de cintas eran los nicos dispositivos de media de respaldo que se podan utilizar razonablemente para propsitos de respaldos. Sin embargo, esto ha cambiado. En las secciones siguientes vamos a tratar sobre las medias de respaldo ms populares y revisar sus ventajas as como tambin sus desventajas. 8.2.4.1. Cintas Las cintas fueron el primer tipo de media removible disponible como medio de almacenamiento. Tiene los benecios 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 nal de su vida til) y que las bsquedas 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 conabilidad. Esto signica que construir una biblioteca de cintas de un buen tamao 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 aos 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 razn principal para el uso de unidades de disco como medio para respaldos sera su velocidad. No hay un medio de almacenamiento masivo ms rpido disponible. La velocidad puede ser un factor crtico 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 algn tipo de almacenamiento fuera del sitio. Un respaldo de la base de datos de produccin sentada en un disco duro medio metro ms 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 daadas o destrudas por algn 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 signica que el nmero de copias de respaldo se debe mantener bajo para as mantener bajos los costos generales. Menos copias de seguridad signica menos redundancia si por alguna razn uno de los respaldos no se puede leer. Los discos duros son frgiles. An 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 an ms costosa. Las unidades de disco no son media para archivado. Asumiendo que pueda superar todos los otros problemas asociados con la realizacin de respaldos a unidades de disco, debera considerar lo
177
siguiente. La mayora 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 aos son mucho ms grandes que las posibilidades de hacerlo desde un disco de 20 aos. Por ejemplo, tendr el hardware necesario para conectarlo a su sistema? Otra cosa a considerar esn que una unidad de disco es mucho ms compleja que una unidad de cinta. Cuando un motor de 20 aos gira un plato de disco de 20 aos, causando que los cabezales de lectura/escritura de 20 aos vuelen sobre la supercie del plato, cules son las posibilidades de que estos componentes funcionen sin problema despus de haber estado 20 aos sentados sin hacer nada?
Nota Algunos centros de datos hacen los respaldos a unidades de disco y luego, para propsitos de archivado, copian estos respaldos a unidades de cinta. Esto permite realizar los respaldos ms rpidos 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 da laboral; siempre y cuando la grabacin se termine antes de que se realicen los respaldos del prximo da laboral.
Dicho esto, todava existen algunas situaciones en las que los respaldos a unidades de discos duros tiene sentido. En la prxima seccin podemos ver cmo se pueden combinar con una red para formar una solucin 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 tecnologas 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 ubicacin, fuera del sitio, por lo que no es necesario transportar unidades de discos frgiles a otro lado. Con suciente ancho de banda, se mantiene la ventaja de la velocidad que puede obtener por hacer los respaldos a discos. Sin embargo, este enfoque todava 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). Adems, los costos de un centro de datos remoto con un enlace de alta velocidad al centro de datos principal hace esta solucin extremadamente costosa. Pero para los tipos de organizacin que necesitan el tipo de funcionalidades que esta solucin ofrece, es un costo que pagaran 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 debera almacenar - y dnde. Para responder a estas preguntas, primero debemos considerar bajo qu circunstancias se utilizaran los respaldos. Hay tres situaciones principales: 1. Peticiones de restauracin pequeas y discretas de los usuarios 2. Restauraciones masivas para recuperarse de un desastre 3. Almacenamiento de archivos que raramente se utilizar otra vez
178
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 ms all que unos pocos pasos del sistema en el cual se restauraran los datos. En el caso de un desastre que necesita una restauracin completa de una o ms computadoras en su centro de datos, si el desastre fue de naturaleza fsica, lo que sea que haya sido destrudo tambin habr destrudo los respaldos que estaban al lado de los computadores. Esto sera una situacin 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 kilmetros de distancia del centro de datos no habr realmente ningn problema. Los enfoques para resolver estas diferencias varan de acuerdo a las necesidades de la organizacin en el caso. Un acercamiento posible es almacenar varios das de respaldo en el sitio; estos respaldos se toman luego a un sitio de almacenamiento ms seguro cuando se creen respaldos diarios ms nuevos. Otro enfoque sera mantener dos fondos diferentes de media:

Un fondo de provisiones del centro de datos utilizado estrictamente para peticiones de restauracin independientes Un fondo fuera del sitio utilizado para el almacenamiento fuera del sitio para casos de recuperacin 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 mltiples 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 an en las peores situaciones.
8.2.6. Problemas de restauracin

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 restauracin en esta seccin y determinar las formas de evaluar su habilidad para llevarlos a cabo en realidad. Tenga en cuenta que el ms difcil a evaluar es tambin el ms crtico. 8.2.6.1. Restauracin a metal pelado La frase "restauracin 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 ningn tipo en el - sin sistema operativo, sin aplicaciones, nada. En general, existen dos enfoques para las restauraciones a metal pelado: Reinstalar, seguido de una restauracin Aqu se instala el sistema operativo base como que si se estuviese congurando una computadora recin comprada. Una vez que el sistema operativo est congurado adecuadamente, se pueden particionar y formatear los discos duros restantes y restaurar todos los respaldos desde la media.
Captulo 8. Planicacin para Desastres Discos de recuperacin del sistema
179
Un disco de recuperacin del sistema es una media de arranque de algn tipo (a menudo un CD-ROM) que contiene un ambiente de sistemas mnimo, capaz de realizar las tareas bsicas de administracin del sistema. El ambiente de recuperacin 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 restauracin. Sin embargo, esta capacidad no est disponible en todos los computadores. Ms an, las computadoras basadas en la arquitectura de PC no se prestan para este enfoque.
8.2.6.2. Evaluar respaldos Cada tipo de respaldo debera ser evaluado de forma peridica 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 alineacin de los cabezales de la unidad de cinta, software de respaldo mal congurado o un error del operador. No importa la causa, sin las revisiones peridicas usted no puede estar seguro de si est generando respaldos a partir de los cuales se puedan restaurar los datos ms adelante.
8.3. Recuperacin de desastres

Como experimento, la prxima 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. Imagnese que el edicio completo ya no existe. Luego, imagine que su trabajo es recuperar la mayor cantidad de trabajo realizado posible en el centro de datos, lo ms pronto posible. Qu hara? Al pensar desde esta perspectiva, usted est dando su primer paso hacia la recuperacin de desas tres. La recuperacin de desastres es la habilidad de recuperarse de un evento que impacta el fun cionamiento del centro de datos de su organizacin lo ms rpido y completo posible. El tipo de desastre puede variar, pero el objetivo nal es siempre el mismo. Los pasos relacionados con la recuperacin a partir de un desastre son numerosos y con un rango bien amplio. A continuacin se muestra una descripcin general a un nivel alto del proceso, junto con los puntos claves a tener en mente.
8.3.1. Creacin, Evaluacin e Implementacin de un Plan de Recuperacin de Desastres

Un sitio de respaldo es vital, sin embargo es intil sin un plan de recuperacin de desastres. Un plan de recuperacin de desastres indica cada faceta del proceso de recuperacin, incluyendo (pero no limitado) a:
180 Los eventos que denotan posibles desastres
Las personas en la organizacin 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 produccin Un plan listando el personal a cubrir el sitio de respaldo, incluyendo un horario de rotacin para soportar las operaciones contnuas 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 recuperacin de desastres a menudo llenan mtiples carpetas de hojas sueltas. Este nivel de detalle es vital porque en el evento de una emergencia, el plan quizs sea lo nico que quede de su centro de datos anterior (adems de los otros sitios de respaldo, por supuesto) para ayudarlo a reconstruir y restaurar las operaciones.
Sugerencia Mientras que los planes de recuperacin de desastres deberan de estar a la mano en su sitio de trabajo, tambin se deberan 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 recuperacin. Un buen lugar para almacenar una copia es en su ubicacin de almacenamiento de respaldos. Tambin se pueden mantener copias del plan de recuperacin de desastres en los hogares de miembros claves de equipo, siempre y cuando esto no viole las polticas de seguridad de la empresa.
Un documento de tal importancia merece una consideracin bien seria (y posiblemente asistencia profesional para su creacin). Una vez que este documento es creado, el conocimiento que contiene debe ser evaluado peridicamente. Evaluar un plan de recuperacin de desastres implica seguir los pasos del plan: ir al sitio de respaldo y congurar el centro de datos temporal, ejecutar las aplicaciones temporalmente y reactivar las operaciones normales despus de que el "desastre" termine. La mayora de las pruebas no tratan de llevar a cabo un 100% de las tareas del plan; en cambio, se selecciona un sistema y una aplicacin representativa para reubicarlos en el sitio de respaldo, se coloca en produccin por un perodo de tiempo y se lleva a operacin normal al nal de la prueba.
Nota Aunque puede sonar como una frase gastada, un plan de recuperacin de desastres debe ser un documento vivo; a medida que el centro de datos cambie, el plan debe ser actualizado para reejar esos cambios. En muchas casos, un plan de recuperacin 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: fro, templado y caliente

Uno de los aspectos ms importantes del plan de recuperacin de desastres es tener una ubicacin desde la cual este puede ser ejecutado. Esta ubicacin se conoce como sitio de respaldo. En el evento
181
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 trminos no se reeren a la temperatura del sitio de respaldo. Se reeren en realidad al esfuerzo requerido para comenzar las operaciones en el sitio de respaldo en el evento de un desastre. Un sitio de respaldo fro es simplemente un espacio en un edicio congurado 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 recuperacin. Como se puede imaginar, el retraso de ir desde un sitio fro a uno en operacin completa puede ser sustancial. Los sitios de respaldo fro son los menos costosos. Un sitio tibio ya est equipado con el hardware representando una representacin el 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 restauracin a metal pelado, antes de que pueda comenzar el trabajo real de recuperacin. Los sitios de respaldo calientes tienen una imagen espejo virtual de su centro de datos, con todos los sistemas congurados 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 ms costoso para una recuperacin de desastres. Los sitios de respaldo pueden provenir de tres fuentes diferentes:

Compaas especializadas en suministrar servicios de recuperacin de desastres Otras ubicaciones que pertenecen y son operadas por la organizacin Un acuerdo mutuo con otra organizacin 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 rma de recuperacin de desastres a menudo trae consigo el acceso a profesionales con la experiencia necesaria para guiar a las organizaciones a travs del proceso de creacin, evaluacin e implementacin de un plan de recuperacin de desastres. Como se puede imaginar, estos servicios tienen su costo. El uso de otras instalaciones que pertenecen y son operadas por su organizacin, pueden ser esen cialmente una opcin de costo cero, pero el surtir el sitio de respaldo y mantener su disponibilidad inmediata es una proposicin costosa. Preparar un acuerdo para compartir centros de datos con otra organizacin puede ser extremadamente econmico, pero usualmente las operaciones a largo plazo bajo estas condiciones no son posibles, pues probablemente el centro de datos antrin todavia continua su produccin normal, haciendo la situacin incmoda en el mejor de los casos. Por otro lado, la seleccin del sitio de respaldo es un acuerdo entre los costos y la necesidad de su organizacin por la continuacin de las operaciones.
8.3.3. Disponibilidad del Hardware y Software

Su plan de recuperacin de desastres debe incluir mtodos para conseguir el hardware y software nece sarios para las operaciones en el sitio de respaldo. Un sitio de respaldo manejado profesionalmente
182
quizs ya tenga todo lo que usted necesita (o quizs tenga que organizar la adquisicin y entrega de materiales especializados que el sitio no tiene disponibles); por otro lado, un sitio de respaldo fro implica que se tienen identicadas 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 noticarlo 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 ms 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 organizacin que est sirviendo. Dependiendo del plan de recuperacin de desastres y de la naturaleza del mismo, su comunidad de usuarios puede estar ubicada a kilmetros de distancia del sitio de respaldo. En estos casos, una buena conectividad es vital para restaurar la produccin. Otro tipo de conectividad a tener en mente es la conectividad telefnica. Debe asegurarse de que existen sucientes lneas telefnicas disponibles para manejar todas las comunicaciones verbales con sus usuarios. Lo que antes poda ser un grito por encima de la pared de un cubculo ahora implica una conversacin telefnica de larga distancia; por lo tanto, planee para tener ms conectividad telefnica 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 esqueltico puede mantener las cosas en funcionamiento por un corto perodo de tiempo, a medida que el desastre se extiende se necesitar ms y ms 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 suciente para descansar y posiblemente viajar de regreso a sus hogares. Si el desastre fuese tan extendido que afecte tambin los hogares y familias de la gente, se necesitar tiempo adicional para permitirles manejar su propia recuperacin 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 recuperacin de desastres incluye que trabaje en el sitio un personal representa tivo de todas las partes de la comunidad de usuarios de la organizacin. Esto depende en la habilidad
183
de su organizacin de operar con un centro de datos remoto. Si los usuarios representantes deben trabajar en el sitio de respaldo, tambin deben estar disponibles facilidades similares para ellos.
8.3.7. Regreso a la normalidad

Eventualmente todos los desastres terminan. El plan de recuperacin de desastres debe tomar en cuenta esta fase tambin. 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 crtica de las preparaciones efectuadas cuando se declar inicialmente el desastre, los sitios de respaldo cuestan dinero cada da que son utilizados, por lo que las preocupaciones econmicas dicatarn que el cambio se lleve a cabo lo ms pronto posible. Se deben hacer y entregar los ltimos respaldos desde el sitio de respaldo al nuevo centro de datos. Despus de almacenarlos en el nuevo hardware, se puede reactivar la produccin en el nuevo centro de datos. En este punto se puede desarmar el centro de datos de respaldo, con la seccin nal del plan indicando la disposicin de todo el hardware temporal. Finalmente, se hace una revisin de la efectividad del plan, integrando cualquier cambio recomendado por el comit de revisin en una versin actualizada del plan.

Hay poco sobre el tpico general de desastres y su recuperacin que tenga un impacto directo en cualquier sistema operativo especco. Despus 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 peccos de la recuperacin de desastres; estos aspectos se discuten en esta seccin.
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 ms bsica de soporte al leer este manual. La documentacin para Red Hat Enterprise Linux est disponible en el CD de Documentacin de Red Hat Enterprise Linux (el cual tambin se puede instalar en su sistema para un acceso rpido), en forma impresa y en el sitio web de Red Hat en http://www.redhat.com/docs/. Las opciones de auto asistencia estn disponibles a travs 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; adems, muchas listas son monitorizadas por personal de Red Hat, que contribuyen cuando el tiempo se los permite. Tambin estn disponibles otros recursos desde la pgina principal de soporte de Red Hat en http://www.redhat.com/apps/support/. Existen opciones de soporte ms completas; se puede encontrar informacin sobre ellas en el sitio web de Red Hat.
8.4.2. Tecnologas de respaldo

Red Hat Enterprise Linux viene con diferentes programas para el respaldo y recuperacin de datos. Por s mismos, estos programas de utilidades no constituyen una solucin de respaldo completa. Sin embargo, se pueden utilizar como el ncleo de tal situacin.
184
Nota Como se coment en la Seccin 8.2.6.1, la mayora de las computadoras basadas en la arquitectura de PC estndar, 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 cuperacin del sistema. Para ms informacin vea el captulo sobre recuperacin bsica del sistema en el Manual de administracin del sistema de Red Hat Enterprise Linux .
8.4.2.1. tar La utilidad tar es bien conocida entre los administradores UNIX. Es el mtodo de archivado preferido para compartir bits de cdigo fuente y archivos entre sistemas. La implementacin tar includa con Red Hat Enterprise Linux es GNU tar, una de las implementaciones de tar ms 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 chero de archivos llamado home-backup.tar en /mnt/backup/. El chero 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 estn respaldando, se puede tambin comprimir el archivo para reducir su tamao. El archivo de respaldo se puede comprimir aadiendo una opcin al comando anterior.
tar czf /mnt/backup/home-backup.tar.gz /home/
El chero de archivos home-backup.tar.gz resultante es ahora comprimido con gzip 5. Hay muchas otras opciones para tar; para aprender ms sobre ellas, lea la pgina man de tar(1). 8.4.2.2. cpio La utilidad cpio es otro programa UNIX tradicional. Es un excelente programa de propsito 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 travs de la entrada estndar. Un mtodo comn 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 chero de archivos cpio (que contiene todo lo que hay en /home/) llamado home-backup.cpio en el directorio /mnt/backup/.
5.
La extensin .gz se utiliza tradicionalmente para identicar que los archivos han sido comprimidos con
gzip. Algunas veces .tar.gz se acorta con .tgz para mantener los nombres de archivos en un tamao
razonable.
185
Sugerencia Como find tiene un conjunto de pruebas de seleccin de archivos muy rico, se pueden realizar respaldos sosticados. Por ejemplo, el comando siguiente realiza un respaldo solamente de los archivos que no se accesaron el ao pasado.
find /home/ -atime +365 | cpio -o
/mnt/backup/home-backup.cpio
Hay muchas otras opciones para cpio (y find); para conocer un poco ms sobre ellas, lea las pginas man de cpio(1) y de find(1). 8.4.2.3. dump/restore: Atencin: 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 mtodo 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: Im surprised that dump is deprecated (by you at least ;-)). What to use instead for backups on machines that cant umount disks regularly?
Note that dump simply wont 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. Its 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.
Ive 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..
186
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 diseado para respaldar sistemas de archivos desmontados; por lo tanto, en situaciones donde es posible tomar un sistema de archivos fuera de lnea con umount, dump sigue siendo una tecnologa de respaldos viable. 8.4.2.4. El Advanced Maryland Automatic Network Disk Archiver (AMANDA) AMANDA es una aplicacin 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 rpidos y congurado 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 diseo de AMANDA tambin sirve para centralizar la administracin de los respaldos, haciendo ms fcil la vida del administrador del sistema. El servidor AMANDA maneja un fondo de media de respaldo y rota su uso a travs de este fondo para asegurarse de que todos los respaldos son guardados por el perodo de retencin dictado por el administrador. Toda la media est preformateada con datos que permiten a AMANDA detectar si la media adecuada est disponible o no. Adems, AMANDA puede interactuar con media robtica 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 Seccin 8.4.2.3). Como tal, los respaldos de AMANDA no requieren AMANDA para su respaldo - una ventaja considerable. En operacin, AMANDA normalmente es planicada para ejecutarse una vez al da durante la ventana de respaldo del centro de datos. El servidor AMANDA se conecta a los sistemas clientes y los dirige a producir tamaos estimados de los respaldos a realizar. Una vez que estn disponibles todos los estimados, el servidor construye un horario, determinando automticamente 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 envan sus respaldos al servidor para su almacenamiento en el disco temporal. Esto resulta en una corriente contnua 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 enva un correo electrnico al administrador del sistema con un informe del estado de los respaldos, haciendo la revisin fcil y rpida. Si es necesario restaurar los datos, AMANDA contiene un programa de utilidades que permite al operador identicar el sistema de archivos, fecha y nombre(s) de archivo(s). Una vez que se hace esto, AMANDA identica la media de respaldo correcta y luego ubica y restaura los datos deseados. Como se mencion anteriormente, el diseo de AMANDA tambin hace posible restaurar los datos an sin la asistencia de AMANDA, aunque la identicacin de la media correcta sera un proceso manual y ms lento. Esta seccin solamente menciona los conceptos ms bsicos de AMANDA. Para una investigacin ms profunda sobre AMANDA, comience por la pgina man amanda(8).
187

Esta seccin incluye varios recursos que se pueden utilizar para conocer un poco ms sobre la recu peracin de desastres y la materia especca a Red Hat Enterprise Linux discutida aqu.

Los recursos siguientes se copian durante el curso de una instalacin de Red Hat Enterprise Linux tpica y lo pueden ayudar a aprender ms sobre la materia discutida.

Pgina man de tar(1) Aprenda a archivar datos Pgina man de dump(8) Conozca cmo descargar los contenidos de un sistema de archivos. Pgina man de restore(8) Aprenda a recuperar los contenidos de un sistema de archivos guardado con dump. Pgina man de cpio(1) Aprenda a copiar archivos desde y hacia archivos. Pgina man de find(1) Conozca cmo buscar archivos. Pgina 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 pgina de soporte de Red Hat suministra acceso fcil a los diferentes recursos relacionados al soporte de Red Hat Enterprise Linux. http://www.disasterplan.com/ Una pgina interesante con enlaces a muchos sitios relacionados a la recuperacin de desastres. Incluye un plan de recuperacin de desastres de ejemplo. http://web.mit.edu/security/www/isorecov.htm La pgina 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 artculo muy bueno de Linux Magazine sobre los aspectos ms tcnicos de la produccin de respaldos bajo Linux. http://www.amanda.org/ La pgina web de Advanced Maryland Automatic Network Disk Archiver (AMANDA). Contiene punteros a las diferentes listas de correo de AMANDA y otros recursos en lnea.

Los libros siguientes discuten diferentes aspectos de la recuperacin de desastres y son buenos recur sos para los administradores de sistemas Red Hat Enterprise Linux.

El Manual de administracin del sistema de Red Hat Enterprise Linux; de Red Hat, Inc. Incluye un captulo sobre la recuperacin del sistema, lo que podra ser til en restauraciones en metal pelado.
188
Unix Backup & Recovery por W. Curtis Preston; OReilly & 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 captulo para la recuperacin de desastres.
ndice
Smbolos
/etc/cups/, 150
/etc/printcap, 150
A
abuso de recursos, 133
abuso, recursos, 133
activacin de su suscripcin, iv
administracin
impresoras, 143
administracin de sistemas
losofa de, 1
automatizacin, 1
comunicacin, 3
documentacin, 2
ingeniera social, riesgos de, 7
negocio, 6
ocurrencias inesperadas, 8
planicacin, 8
recursos, 6
seguridad, 7
usuarios, 6
administracin de volmenes lgicos (Ver LVM) almacenamiento accesible a travs de la red, 79, 105
NFS, 106
SMB, 106
administracin de, 63, 87
crecimiento, normal, 89
monitorizar espacio libre, 87
problemas de usuarios, 88
uso de una aplicacin, 89
uso excesivo de, 87
aadir, 92, 107
/etc/fstab, actualizacin, 109
conguracin, actualizar, 96
Discos duros ATA, 93
formatear, 96, 109
hardware, instalacin, 92
particionamiento, 95, 107
planicacin de respaldos, modicar, 96
Unidad de dico SCSI, 94
basado en RAID
(Ver RAID)
cuotas de usuarios, 90
(Ver cuotas de usuarios)
dispositivos de almacenamiento masivo
brazos de acceso, 64
cabeza, 66
cabezas, 64
cabezas de escritura, 72
cabezas de lectura, 72
cargas de E/S, escrituras, 73
cargas de E/S, lecturas, 73
cargas de E/S, rendimiento, 73
cilindro, 66
conceptos de direccionamiento, 65
direcciones basadas en bloques, 67
direcciones basadas en geometra, 65
direcciones, basadas en bloques, 67
direcciones, basados en la geometra, 65
geometra, problemas con, 66
interfaces con estndares de la industria, 68
interfaces para, 67
interfaces, estndar de la industria, 68
interfaces, historia, 67
Interfaz IDE, 68
Interfaz SCSI, 69
latencia rotacional, 72
latencia, rotacional, 72
lectores contra escrituras, 73
limitaciones elctricas de, 71
limitaciones mecnicas de, 71
movimiento del brazo de acceso, 72
movimiento, brazo de acceso, 72
platos de disco, 63
platos, disco, 63
procesamiento de comandos, 72
procesamiento, comando, 72
rendimiento de, 71
sector, 66
Ubicacin de E/S, 74
vista general de, 63
eliminar, 96, 109
/etc/fstab, eliminar de, 110
borrar los contenidos, 97, 110
comando umount, uso de, 110
datos, eliminar, 97
implementacin, 74
monitorizar el, 19
particin
atributos de, 75
campo tipo, 76
extendidas, 75
geometra de, 75
lgicas, 76
primaria, 75
tipo de, 75
patrones de acceso, 49
problemas relacionados a archivos, 90
acceso a archivos, 90
compartir archivos, 91
sistema de archivos, 76, 100
activando acceso a, 79
190
archivo /etc/mtab , 104
archivo /proc/mounts , 104
basado en archivos, 76
comado df, uso de, 105
contabilidad del espacio, 78
contabilidad, espacio, 78
control de acceso, 77
directorio jerrquico, 77
directorios, 77
estructura, directorio, 78
EXT2, 101
EXT3, 101
ISO 9660, 101
montaje, 102
montar con el archivo /etc/fstab, 106
mostrar lo montado, 103
MSDOS, 102
punto de montaje, 103
tiempos de acceso, 77
tiempos de creacin, 77
tiempos de modicacin, 77
VFAT, 102
tecnologas, 49 almacenamiento fuera de lnea, 53 almacenamiento para respaldos, 53 disco duro, 52 L1 cache, 51 L2 cache, 51 memoria cach, 50 memoria principal, 51 RAM, 51 Registros de CPU, 50 unidad de disco, 52 tecnologas, avanzadas, 79 archivo /etc/fstab actualizacin, 109 montar sistemas de archivos con, 106 archivo /etc/group cuenta de usuario, papel en, 138 grupo, papel en, 138 archivo /etc/gshadow cuenta de usuario, papel en, 138 grupo, papel en, 138 archivo /etc/mtab , 104 archivo /etc/passwd cuenta de usuario, papel en, 136 grupo, papel en, 136 archivo /etc/shadow cuenta de usuario, papel en, 136 grupo, papel en, 136 archivo /proc/mdstat, 117 archivo /proc/mounts , 104 automatizacin, 9 descripcin general, 1
B
bash shell, automatizacin y, 9
C
CD-ROM sistema de archivos (Ver Sistema de archivos ISO 9660) comando chage, 139 comando chfn, 139 comando chgrp, 140 comando chmod, 140 comando chown, 140 comando chpasswd, 139 comando df , 105 comando free, 21, 58 comando gnome-system-monitor, 22 comando gpasswd, 139 comando groupadd, 139 comando groupdel, 139 comando groupmod, 139 comando grpck, 139 comando iostat, 24, 40 comando mpstat, 24 comando passwd, 139 comando raidhotadd, uso de, 117 comando sa1, 24 comando sa2, 24 comando sadc , 24 comando sar, 24, 26, 41, 43, 59 informes, lectura, 27 comando top, 20, 21, 42 comando useradd, 139 comando userdel, 139 comando usermod, 139 comando vmstat, 20, 23, 40, 43, 59 comando watch, 21 comunicacin Informacin especca a Red Hat Enterprise Linux,
10
necesidad de, 3
conguracin de impresoras, 149 aplicacin basada en texto, 150 CUPS, 149 conjunto de direcciones de trabajo, 56 contrasea, 124 caducidad, 128 conjunto de caracteres grande usado en, 128 conjunto de caracteres pequeo usado en, 126 corta de, 125 dbiles, 125 escritas, 127 informacin personal usada en, 126 largas, 127 memorizables, 128
191
palabras usadas en, 126
robustas, 127
trucos de palabras usados en, 126
usado repetidamente, 127
control de cambios, 170
convenciones
documento, ii
cuenta
(Ver cuenta de usuario)
cuenta de usuario
acceso a datos compartidos, 131
administracin de, 121, 121, 129
cambios de trabajo, 131
nuevos empleados, 129
terminaciones, 130
archivos controlando, 136
/etc/group, 138
/etc/gshadow, 138
/etc/passwd, 136
/etc/shadow, 136
contrasea, 124
caducidad, 128
conjunto de caracteres grande usado en, 128
conjunto de caracteres pequeo usado en, 126
corta de, 125
dbiles, 125
escritas, 127
informacin personal usada en, 126
largas, 127
memorizables, 128
palabras usadas en, 126
robustas, 127
trucos de palabras usados en, 126
usado repetidamente, 127
control de acceso, 129
directorio principal
centralizado, 133
GID, 135
GIDs del sistema, 135
herramientas para administrar, 139
comando chage, 139
comando chfn, 139
comando chpasswd, 139
comando passwd, 139
comando useradd, 139
comando userdel, 139
comando usermod, 139
nombre de usuario, 121
cambios a, 123
colisiones en nombres, 122
convenio de nombres, 121
permisos relacionados a, 134
ejecucin, 134
escritura, 134
lectura, 134
setgid, 134
setuid, 134
sticky bit, 134
recursos, administracin de, 131
UID, 135
UIDs del sistema, 135
cuotas de usuarios
activando, 113
administracin de, 114
introduccin a, 111
especco a grupos, 112
especco al sistema de archivos, 112
especco al usuario, 112
lmite suave, 113
lmites rgidos, 113
perodo de gracia, 113
seguimiento de uso de bloques, 112
seguimiento de uso de inodes, 112
cuotas, disco
(Ver cuotas de usuarios)
CUPS, 149
D
datos
acceso compartido a, 131, 132
problemas globales de propiedad, 133
devlabel, 100
directorio principal
centralizado, 133
directorio principal centralizado, 133
discos duros, 52
Discos duros ATA
aadir, 93
dispositivo
accesos a dispositivos completos, 99
alternativas a nombres de dispositivos, 99
convencin de nombres, 98
devlabel, nombrar con, 100
etiquetas de sistemas de archivos, 100
etiquetas, sistemas de archivos, 100
nombres con devlabel, 100
nombres de archivos, 98
nombres de dispositivos, alternativas a, 99
particin, 99
tipo, 98
unidad, 99
documentacin
Informacin especca a Red Hat Enterprise Linux,
10
documentacin, necesidad de, 2
192
E
espacio de direcciones virtuales, 55
espacio en disco
(Ver almacenamiento)
estadsticas de supervisin
relacionado a la memoria, 19
relacionado al almacenamiento, 19
relacionado al ancho de banda, 18
relacionado al CPU, 17
seleccin de, 17
H
hardware contratos de servicios, 155
disponibilidad de partes, 158
hardware cubierto, 158
horas de cobertura, 155
presupuesto para, 158
servicio de depsito, 156
servicio drop-off, 156
servicio walk-in, 156
tiempo de respuesta, 157
tcnico in-situ, 157
fallas de, 153
habilidades necesarias para reparar, 153
repuestos
intercambiar hardware, 155
mantener, 153
repuestos, cantidades, 154
repuestos, seleccin de, 154
Herramienta de conguracin de impresoras (Ver conguracin de impresoras) herramientas cuentas de usuario, administrar (Ver cuentas de usuario, herramientas para administrar) grupos, administracin (Ver grupo, herramientas para administrar) supervisin de recursos, 20
free, 21
iostat, 24
Monitor del Sistema GNOME, 22
mpstat, 24
OProle, 28
sa1, 24
sa2, 24
sadc, 24
sar, 24, 26
Sysstat, 24
top, 21
vmstat, 23
F
fallo de pgina, 56
losofa de la administracin de sistemas, 1
G
GID, 135
grupo
acceso a datos compartidos usando, 132
archivos controlando, 136
/etc/group, 138
/etc/gshadow, 138
/etc/passwd, 136
/etc/shadow, 136
estructura, determinar, 132
GID, 135
GIDs del sistema, 135
herramientas para administrar, 139
comando gpasswd, 139
comando groupadd, 139
comando groupdel, 139
comando groupmod, 139
comando grpck, 139
permisos relacionados a, 134
ejecucin, 134
escritura, 134
lectura, 134
setgid, 134
setuid, 134
sticky bit, 134
UID, 135
UIDs del sistema, 135
ID del grupo (Ver GID) ID del usuario (Ver UID) impresoras

administracin, 143
color, 146
CMYK, 146
inyeccin de tinta, 146
lser, 147
consideraciones, 143
duplex, 143
193
lenguajes (Ver lenguajes de descripcin de pginas (PDL)) local, 149
recursos adicionales, 151
red, 149
tipos, 143
cera termal, 148
impacto, 144
inyeccin de tinta, 146
lser, 147
lser a color, 147
lnea, 144
margarita, 144
matriz de puntos, 144
sublimacin de tinte, 148
tinta slida, 148
impresoras a color lser, 147
impresoras de impacto, 144
consumibles, 146
lnea, 144
margarita, 144
matriz de puntos, 144
impresoras de inyeccin de tinta, 146
consumibles, 146
impresoras de lnea
(Ver impresoras de impacto)
impresoras de margarita
impresoras de matriz de puntos
impresoras lser, 147
color, 147
consumibles, 147
inesperado, preparacin para lo, 8
Informacin especca a Red Hat Enterprise Linux
automatizacin, 9
bash shell, 9
comunicacin, 10
documentacin, 10
herramientas de supervisin de recursos
iostat, 40
sar, 41, 43
top, 42
vmstat, 40, 43
herramientas para monitorizar recursos, 20
free, 20
OProle, 20
Sysstat, 20
top, 20
vmstat, 20
monitorizar recursos
ancho de banda , 40
Poder de CPU, 40
PAM, 10
perl, 9
recuperacin de desastres, 183
RPM, 10
seguridad, 10
shell scripts, 9
sistemas de deteccin de intrusos, 10
soporte de software, 183
soporte, software, 183
tecnologas de respaldo
AMANDA, 186
cpio, 184
descripcin general, 183
dump, 185
tar, 184
informacin especca de Red Hat Enterprise Linux herramientas de supervisin de recursos
free, 58
sar, 59
vmstat, 59
supervisin de recursos memoria, 58
ingeniera social, riesgos de, 7
ingeniera, social, 7
intercambio, 57
Interfaz IDE
Interfaz SCSI
L
lenguajes de descripcin de pginas (PDL), 148
Interpress, 148
PCL, 148
PostScript, 148
lpd, 151
LVM
agrupamiento de almacenamiento, 86
comparado con RAID, 87
migracin de datos, 86
migracin, datos, 86
redimensionamiento de volmenes lgicos, 86
redimensionamiento, volumen lgico, 86
194
M
memoria memoria virtual, 54
almacenamiento de respaldo, 55
conjunto de direcciones de trabajo, 56
descripcin general de, 54
espacio de direcciones virtuales, 55
fallo de pgina, 56
intercambio, 57
rendimiento de, 57
rendimiento, mejor caso, 58
rendimiento, peor caso, 57
monitorizar el, 19
utilizacin de recursos de, 49
memoria cach, 50
memoria fsica
(Ver memoria) memoria virtual (Ver memoria)
monitorizar el rendimiento del sistema, 16
montaje de sistemas de archivos
(Ver almacenamiento, sistemas de archivos, mon
taje)
multiprocesamiento simtrico, 39
N
negocio, conocimiento de, 6
NFS, 106
nombre de usuario, 121
cambio, 123
colisiones entre, 122
convenio de nombres, 121
nombres de archivos
dispositivo, 98
O
OProle, 20, 28
P
PAM, 10
particin, 99
atributos de, 75
campo tipo, 76
geometra, 75
tipo, 75
creacin de, 95, 107
extendidas, 75
lgicas, 76
primaria, 75
perl, automatizacin y, 9
permiso de ejecucin, 134

permiso de escritura, 134
permiso de lectura, 134
permiso de sticky bit, 134
permiso setgid, 10, 134
permiso setuid, 10, 134
permisos, 134
herramientas para administrar
comando chgrp, 140
comando chmod, 140
comando chown, 140
planicacin de la capacidad, 16
planicacin para desastres, 153
energa, reserva, 164
conjunto moto-generador, 164
generador, 166
interrupciones, prolongadas, 166
UPS, 165
tipos de desastre , 153
aire acondicionado, 167
aplicaciones usadas incorrectamente, 168
bloqueos del sistema operativo, 159
calefaccin, 167
cadas del sistema operativo, 159
electricidad, calidad de, 163
electricidad, seguridad de, 162
elctrical, 162
errores de conguracin, 169
errores de operadores, 168
errores de procedimientos, 168
errores de servicio tcnico, 171
errores de usuarios, 168
errores del administrador de sistemas, 169
errores durante procedimientos, 169
errores humanos, 167
errores relacionados al mantenimiento, 171
fallas ambientales, 161
fallas de las aplicaciones, 160
fallas del hardware, 153
fallas del sistema operativo, 159
fallas del software, 159
HVAC, 167
integridad del edicio, 162
relacionado al tiempo, 167
reparaciones incorrectas, 171
ventilacin, 167
planicacin, importancia de, 8 Pluggable Authentication Modules (Ver PAM) Poder de CPU (Ver recursos, sistema y poder de procesamiento) poder de procesamiento, recursos relacionados a (Ver recursos, sistema y poder de procesamiento) printconf (Ver conguracin de impresoras) printtool
195
(Ver conguracin de impresoras) puntos de montaje (Ver almacenamiento, sistema de archivos, punto de montaje) (Ver almacenamiento) ancho de banda , 33
buses, ejemplos de, 34
capacidad, incrementar, 35
carga, distribuir, 35
carga, reducir, 35
datapaths, ejemplos de, 34
datapaths, papel en, 34
monitorizar el, 18
papel de los buses en, 33
problemas relacionados a, 34
soluciones a problemas con, 35
memoria (Ver memoria) poder de procesamiento, 33
actualizar, 39
aplicaciones, eliminar, 38
capacidad, incrementar, 39
carga, reducir, 38
consumidores de, 36
CPU, actualizar, 39
escasez de, mejorar, 37
hechos relacionados a, 36
monitorizar el, 17
multiprocesamiento simtrico, 39
SMP, 39
sobrecarga de aplicaciones, reducir, 38
Sobrecarga del SO, reducir, 38
uso de aplicaciones de, 37
uso del sistema operativo de, 37
registro de su suscripcin, iv
registro de suscripcin, iv
respaldos
almacenamiento de, 177
comprar software, 173
construir software, 173
introduccin a, 172
planicacin, modicar, 96
problemas de restauracin, 178
evaluar la restauracin, 179
restauraciones a metal pelado, 178
problemas relacionados a los datos, 172
Software de respaldo AMANDA, 186
tecnologas utilizadas, 183
cpio, 184
dump, 185
tar, 184
tipos de, 174
respaldos completos, 175
respaldos diferenciales, 175
respaldos incrementales, 175
tipos de media, 176
cinta, 176
disco, 176
R
RAID
comparado con LVM, 87
creacin de formaciones
(Ver RAID, formaciones, creacin) formaciones
comando raidhotadd, uso de, 117
estatus, vericar, 117
reconstruccin, 117
formaciones, creacin, 115
en el momento de la instalacin, 115
tiempo luego de la instalacin, 116
implementaciones de, 84
hardware RAID, 85
software RAID, 85
introduccin a, 80
niveles de, 81
RAID 0, 81
RAID 0, desventajas de, 82
RAID 0, ventajas de, 82
RAID 1, 82
RAID 5, 83
RAID 5, ventajas de, 83
RAID anidado, 84
RAID anidado, 84
RAM, 51
recuperacin de desastres
disponibilidad del hardware, 181
disponibilidad del software, 181
nal de, 183
introduccin a, 179
plan, creacin, evaluacin, implementacin, 179
respaldos, disponibilidad de, 182
sitio de respaldo, 180
conectividad de red a, 182
personal de, 182
recursin
(Ver recursin)
recursos del sistema
(Ver recursos, sistema)
recursos relacionados al ancho de banda
(Ver recursos, sistema, ancho de banda)
recursos, importancia de, 6
recursos, sistema
almacenamiento
196
red, 177
RPM, 10
RPM Package Manager
(Ver RPM) Poder de CPU, 17
qu monitorizar, 17
rendimiento del sistema, 16
Sysstat, 20, 24
system-cong-printer
(Ver conguracin de impresoras)
S
seguridad
importancia de, 7
Informacin especca a Red Hat Enterprise Linux,
10
shell scripts, 9
sistema de archivos
etiquetas, 100
Sistema de archivos EXT2, 101
Sistema de archivos EXT3, 101
Sistema de archivos ISO 9660, 101
Sistema de archivos MSDOS, 102
Sistema de archivos VFAT, 102
sistemas de deteccin de intrusos, 10
SMB, 106
SMP, 39
software
asistencia para
auto asistencia, 160
descripcin general, 160
documentacin, 160
soporte de correo electrnico, 160
soporte in situ, 161
soporte telefnico, 161
Soporte Web, 160
supervisin
recursos, 15
rendimiento del sistema, 16
supervisin de recursos, 15
almacenamiento, 19
ancho de banda, 18
capacidad del sistema, 16
conceptos detrs, 15
herramienta utilizada, 20
herramientas
free, 21
iostat, 24
Monitor del Sistema GNOME, 22
mpstat, 24
OProle, 28
sa1, 24
sa2, 24
sadc, 24
sar, 24, 26
Sysstat, 24
top, 21
vmstat, 23
memoria, 19
planicacin de la capacidad, 16
U
UID, 135
Unidad de dico SCSI
aadir, 94
unidades de disco, 52
usuarios
importancia de, 6
Colofn
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 grcos de admonicin (nota, sugerencia, importante, aviso y atencin). Estos pueden ser distribudos gratuitamente con la documentacin de Red Hat. El Equipo Red Hat de Documentacin de Productos est formado por las siguientes personas: Sandra A. Moore Escritora principal y mantenedora del Manual de instalacin 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 instalacin para la arquitectura IBM POWER de Red Hat Enterprise Linux; Escritora principal y mantenedora del Manual de instalacin para las arquitecturas IBM S/390 e IBM eServer zSeries de Red Hat Enterprise Linux John Ha Escritor principal y mantenedor del Manual de conguracin y administracin 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 Introduccin a la administracin 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 instalacin 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 Gua para escribir polticas 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 administracin 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 conguracin y administracin del Cluster de Red Hat Cluster Suite Mark Johnson Escritor principal y mantenedor del Manual de conguracin y administracin 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 Localizacin de Red Hat est formado por las siguientes personas:
Amanpreet Singh Alam Traducciones al Punjabi
Jean-Paul Aubry Traducciones al Francs
David Barzilay Traducciones al Portugus Brasileo
Runa Bhattacharjee Traducciones al Bengal
Chester Cheng Traducciones al Chino Tradicional
Verena Fuehrer Traducciones al Alemn
Kiyoto Hashida Traducciones al Japons
N. Jayaradha Traducciones al Tamil
Michelle Jiyeen Kim Traducciones al Coreano
Yelitza Louze Traducciones al Espaol
198 Noriko Mizumoto Traducciones al Japons

Ankitkumar Rameshchandra Patel Traducciones al Gujarati
Rajesh Ranjan Traducciones al Hindi
Nadine Richter Traducciones al Alemn
Audrey Simons Traducciones al Francs
Francesco Valente Traducciones al Italiano
Sarah Wang Traducciones al Chino Simplicado
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

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

5.5. Preparar el almacenamiento para ser utilizado ................................................................ 74

7. Impresoras e impresin .............................................................................................................. 143

1. Informacin especca a la arquitectura

2. Convenciones del documento

Proporcione un nombre de conexin a Red Hat Proporcione un nmero de suscripcin

Introduccin Conecte su sistema

3.1. Proporcione un nombre de conexin a Red Hat

Un usuario de conexin Red Hat le permite acceder a:

Si se le ha olvidado su usuario de conexin Red Hat, puede buscarlo en lnea en:

3.2. Proporcione su nmero de suscripcin

3.3. Conecte su sistema

4.1. Envenos sus comentarios

Las secciones siguientes exploran cada tema en detalle.

1.1. Automatizar todo

Captulo 1. Filosofa de la Administracin de Sistemas

1.2. Documentar todo

Captulo 1. Filosofa de la Administracin de Sistemas Procedimientos

1.3. Comunique tanto como sea posible

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

4 La naturaleza del cambio Cuando ocurrir Porqu est sucediendo

Captulo 1. Filosofa de la Administracin de Sistemas

Planicacin para el tiempo fuera de servicio del sistema el viernes en la noche

Es importante resaltar algunas puntos:

1.3.2. Informe a sus usuarios sobre lo que est haciendo

Captulo 1. Filosofa de la Administracin de Sistemas

Parada del sistema programada para esta noche

1.3.3. Informe a sus usuarios sobre lo que ha hecho

Finalizada la parada del sistema

Captulo 1. Filosofa de la Administracin de Sistemas

1.4. Conozca sus recursos

Pero pueden no ser tan obvios:

1.5. Conozca a sus usuarios

1.6. Conozca su negocio

1.7. La seguridad no puede ser una ocurrencia posterior

1.7.1. Los riesgos de Ingeniera Social

Captulo 1. Filosofa de la Administracin de Sistemas

1.9. Espere lo inesperado

Captulo 1. Filosofa de la Administracin de Sistemas

1.10. Informacin especca a Red Hat Enterprise Linux

El intrprete de comandos bash El lenguaje de scripting perl El lenguaje de scripting python

Captulo 1. Filosofa de la Administracin de Sistemas

1.10.2. Documentacin y comunicacin

El editor de texto gedit El editor de texto Emacs El editor de texto Vim

Captulo 1. Filosofa de la Administracin de Sistemas

1.11. Recursos adicionales

1.11.1. Documentacin instalada

1.11.2. Sitios web de utilidad

1.11.3. Libros relacionados

Captulo 1. Filosofa de la Administracin de Sistemas

Captulo 1. Filosofa de la Administracin de Sistemas

2.1. Conceptos bsicos

Poder de CPU Ancho de banda Memoria Almacenamiento

Captulo 2. Supervisin de recursos

2.2. Monitorizar el rendimiento del sistema

2.3. Monitorizar la capacidad del sistema

Se monitoriza ms o menos de forma contnua Usualmente el monitoreo no es tan detallado

Captulo 2. Supervisin de recursos

2.4.1. Monitorizar el poder de CPU

Captulo 2. Supervisin de recursos

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

2.4.2. Monitorizar el ancho de banda