Red Hat Cluster Suite: Configuring and Managing a Cluster | ||
---|---|---|
Anterior | Capítulo 1. Instalación del hardware y configuración del sistema operativo | Siguiente |
Después de instalar Red Hat Enterprise Linux, configure los componentes de hardware del cluster y verifique la instalación para asegurarse que los miembros reconocen todos los dispositivos conectados. Note que los pasos exáctos para configurar el hardware dependen del tipo de configuración. Vea la Sección 1.1 para más información sobre configuraciones del cluster.
Para instalar el hardware del cluster, siga estos pasos:
Apague los miembros y desconéctelos de sus fuentes de poder.
Configure los canales comprometidos a Ethernet, si aplica. Consulte la Sección 1.4.1 para más información.
Cuando utilice interruptores, configure los switches y conecte cada miembro a un interruptor. Vea la Sección 1.4.2 para más información.
Además, es recomendado conectar cada interruptor (o cada cable eléctrico del miembro si no se está usando interruptores) a un sistema UPS diferente. Refiérase a la Sección 1.4.3 para más información sobre el uso de sistemas UPS opcionales.
Instale el almacenamiento de disco compartido de acuerdo a las instrucciones suministradas por el fabricante y conecte los miembros al recinto de almacenamiento externo. Vea la Sección 1.4.4 para más información sobre como realizar esta tarea.
Además, se recomienda conectar el recinto de almacenamiento a sistemas UPS redundantes. Vea la Sección 1.4.3 para más información sobre el uso de sistemas UPS opcionales.
Encienda el equipo y arranque cada miembro cluster. Durante el proceso de arranque, entre en la utilidad del BIOS para modificar el setup del miembro, como sigue:
Asegúrese que el número de identificación SCSI usado por el adaptador HBA es único para el bus SCSI al cual está conectado. Consulte la Sección B.5 para más información sobre como realizar esta tarea.
Active o desactive la terminación dentro de cada HBA, como es requerido por la configuración del almacenamiento. Refiérase a la Sección 1.4.4 y Sección B.3 para más información sobre como realizar esta tarea.
Habilite el miembro para que arranque automáticamente cuando se encienda.
Salga de la utilidad del BIOS y continue arrancando cada miembro. Examine los mensajes de inicio para verificar que el kernel de Red Hat Enterprise Linux ha sido configurado y puede reconocer el conjunto completo de discos compartidos. Use el comando dmesg para desplegar los mensajes de inicio de la consola. Refiérase a la Sección 1.3.3 para más información sobre el uso del comando dmesg.
Verifique que los miembros pueden comunicarse sobre cada conexión Ethernet punto-a-punto usando el comando ping para enviar paquetes sobre cada interfaz de red.
Configure las particiones cluster compartidas en el almacenamiento compartido del disco. Vea la Sección 1.4.4.3 para más información sobre como realizar esta tarea.
La vinculación a canales Ethernet en un sistema cluster de ningún punto de falla, le permite una conexión de red tolerante a fallas al combinar dos dispositivos Ethernet en un único dispositivo virtual. La interfaz confinada al canal resultante asegura que en el evento de que un dispositivo Ethernet falle, el otro dispositivo se volverá activo. Este tipo de vinculación al canal, llamada una política de respaldo-activo permite una conexión de ambos dispositivos confinados a un switch o permite que cada dispositivo Ethernet se conecte a concentradores o switches separados, lo cual elimina el único punto de falla en el concentrador/switch de la red.
La vinculación al canal requiere que cada miembro cluster tenga dos dispositivos Ethernet instalados. Cuando se carga, el módulo enlazado utiliza la dirección MAC del primer dispositivo de red esclavizado y asigna esa dirección MAC al otro dispositivo de red si el primer dispositivo falla la detección del enlace.
Para configurar dos dispositivos de red para la vinculación de canales, haga lo siguiente:
Cree dispositivos vinculados en /etc/modules.conf. Por ejemplo:
alias bond0 bonding options bonding miimon=100 mode=1 |
Esto carga el dispositivo vinculado con el nombre de interfaz bond0, así como también pasa las opciones al controlador enlazado para configurarlo como en dispositivo de respaldo-activo maestro para las interfaces de red esclavizadas.
Modifique el archivo de configuración /etc/sysconfig/network-scripts/ifcfg-ethX para eth0 y eth1 de manera que los archivos muestren contenidos idénticos. Por ejemplo:
DEVICE=ethX USERCTL=no ONBOOT=yes MASTER=bond0 SLAVE=yes BOOTPROTO=none |
Esto esclavizará ethX (replace X con el número asignado del dispositivo Ethernet) al dispositivo maestro bond0.
Cree un script de red para el dispositivo vinculado (por ejemplo, /etc/sysconfig/network-scripts/ifcfg-bond0), el cual aparecerá como en el ejemplo siguiente:
DEVICE=bond0 USERCTL=no ONBOOT=yes BROADCAST=192.168.1.255 NETWORK=192.168.1.0 NETMASK=255.255.255.0 GATEWAY=192.168.1.1 IPADDR=192.168.1.10 |
Reinicie el sistema para que los cambios surtan efecto. De forma alternativa, cargue manualmente el dispositivo vinculado y reinicie la red. Por ejemplo:
/sbin/insmod /lib/modules/`uname -r`/kernel/drivers/net/bonding/bonding.o \ miimon=100 mode=1 |
/sbin/service network restart |
Los interruptores permiten a cada miembro alternar el poder a otro miembro antes de reiniciar sus servicios como parte del proceso de failover. La habilidad para desactivar remotamente un sistema asegura que se mantenga la integridad de los datos bajo cualquier condición de falla. Se recomienda que en ambientes de producción se usen interruptores o temporizadores tipo perro-guardián en la configuración del cluster. Solamente se debería usar una configuración sin interruptores en ambientes de prueba. Refiérase a la Sección 1.1.3 para una descripción de los diferentes tipos de interruptores. Note que dentro de esta sección, el término "interruptores" también incluye a los temporizadores tipo perro-guardián.
En una configuración cluster que usa interruptores físicos, cada cable de energía del miembro está conectado a un interruptor a través de una conexión serial o de red (dependiendo del tipo de interruptor). Cuando ocurre una caída del sistema, el miembro puede usar esta conexión para hacer ciclo de encendido con el otro miembro antes de reiniciar sus servicios.
Los interruptores protegen contra la corrupción de los datos en caso de que un miembro que no respondía (o colgado) se vuelva activo después de que sus servicios se han caído, y comienza a emitir E/S al disco que al mismo tiempo también está recibiendo E/S desde el otro miembro.Además, si un demonio quorum falla en un miembro, el miembro ya no puede monitorear las particiones cluster compartidas. Si no se usan interruptores ni temporizadores perro-guardián en el cluster, entonces esta condición de error puede resultar en que los servicios se ejecuten en más de un miembro, lo cual podría generar corrupción de los datos y posiblemente fallas del sistema.
Se recomienda fuertemente usar interruptores en un cluster. Sin embargo, los administradores que estén conscientes del riesgo pueden escoger instalar un cluster sin interruptores.
Un miembro puede colgarse, por unos pocos segundos si esta haciendo swapping o tiene una gran carga de trabajo. Por esta razón, se permite un tiempo adecuado antes de llegar a la conclusión de que el miembro ha fallado (típicamente 15 segundos).
Si un miembro determina que un sistema colgado se ha caído y que se usan interruptores en el cluster, el miembro tomará el control del miembro colgado antes de reiniciar sus servicios. Los clusters configurados para usar temporizadores de tipo perro-guardián se auto-reiniciarán en la mayoría de las ocasiones en las que el sistema se cuelgue. Esto ocasionará que el miembro colgado se inicie en un estado limpio y lo prevendrá de emitir E/S y, por ende, de corromper los datos.
Los miembros colgados se reinician asímismos bien sea debido a que se dispara el watchdog, debido a la falla al enviar paquetes de hearbeat o, — en el caso de que un miembro no tenga un interruptor físico, pérdida del status quorum.
Los miembros colgados pueden reiniciar otros miembros si estos están conectados a un interruptor. Si el miembro colgado se vuelve responsivo y no se están usando interruptores, entonces se requiere reiniciar manualmente.
Los interruptores deben ser configurados de acuerdo a las instrucciones del fabricante. Sin embargo, algunas tareas específicas del cluster pueden ser necesarias para poder usar un interruptor en el cluster. Consulte la Sección B.1 para información detallada sobre interruptores (incluyendo información sobre temporizadores perro-guardián). Asegúrese de tomar en cuenta cualquier advertencia o atributos funcionales de tipos particulares de interruptores. Note que la información específica del cluster provista en este documento reemplaza la información del fabricante.
Cuando se este cableando los interruptores, tome especial cuidado para asegurarse de que cada cable esté en el enchufe apropriado. Esto es de suma importancia porque no hay forma de que el software verifique si el cableado está correcto. Si se falla en cablear de la forma correcta puede generar que se haga un ciclo de encendido con el miembro incorrecto o que un miembro concluya erróneamente que se ha encendido otro miembro éxitosamente.
Después de configurar los interruptores, realice estas tareas para conectarlos a los miembros:
Conecte el cable eléctrico para cada miembro a un interruptor.
Conecte cada miembro al interruptor. El cable usado para la conexión depende del tipo de interruptor. Un interruptor conectado a serial utiliza cables de módem nulos, mientras que un interruptor conectado a la red requerirá un cable de Ethernet.
Conecte el cable de energía para cada interruptor a una fuente de poder. Se recomienda conectar cada interruptor a diferentes sistemas UPS. Vea la Sección 1.4.3 para más información.
Después de la instalación del software del cluster, pruebe los interruptores para asegurarse de que cada miembro puede efectivamente ejecutar ciclos de encendido con al otro miembro antes de iniciar el cluster. Vea la Sección 2.11.2 para más información.
Los sistemas de Suministro de Poder Contínuo (UPS) proveen de fuentes de energía de alta disponibilidad. Idealmente, se debería usar una solución redundante que incorpore múltiples UPS (uno para cada servidor). Para una tolerancia a fallas máxima, es posible incorporar dos UPS por servidor así como también APCs (Automatic Transfer Switches) para manejar la energía y el control de apagado del servidor. Ambas soluciones son totalmente dependientes del nivel de disponibilidad deseado.
No se recomienda usar una gran infraestructura de UPS como única fuente de poder para el cluster. Una solución de UPS dedicada al cluster es más flexible en términos de manejabilidad y disponibilidad.
Un sistema UPS completo debe proporcionar el voltage y la corriente adecuada por largos períodos de tiempo. Aún cuando no existe un único UPS que satisfaga todos los requerimientos de energía, se puede ajustar una solución para satisfacer una configuración particular.
Si el subsistema cluster de almacenamiento en disco tiene dos fuentes de alimentación con cables separados, instale dos sistemas UPS, y conecte un interruptor (o un cable de corriente para el cluster si no se está usando interruptores) y uno de los cables de corriente del subsistema de almacenamiento a cada sistema UPS. Una configuración de sistema UPS redundante es mostrada en la Figura 1-3.
Una alternativa de configuración de energía redundante es conectar ambos interruptores (o ambos cables eléctricos de los miembros) y el subsistema de almacenamiento de disco al mismo sistema UPS. Esta es la configuración más rentable y provee de algo de protección contra fallas de energía. Sin embargo, si ocurre una interrupción de la energía, el único sistema UPS se convierte en un posible punto simple de falla. Además, un sólo sistema UPS puede no ser suficiente para proveer energía a todos los dispositivos conectados por un período adecuado de tiempo. Una configuración de un sólo sistema UPS es mostrada en la Figura 1-4.
Muchos sistemas UPS sumistrados por el fabricante incluyen aplicaciones Red Hat Enterprise Linux que monitorean el estado operacional del sistema UPS a través de una conexión de puerto serial. Si la energía de la bateria es baja, el software de monitoreo iniciará una parada limpia del sistema. Si esto ocurre, el software del cluster será detenido de la forma correcta, porque está controlado por un script de nivel de ejecución Sys V (por ejemplo, /etc/rc.d/init.d/clumanager).
Vea la documentación del UPS proporcionada por el fabricante para información de instalación detallada.
En un cluster, el almacenamiento compartido en disco es usado para mantener datos del servicio y dos particiones (una primaria y otra shadow) que almacenan la información de estado del cluster. Debido a que este almacenamiento debe estar disponible para todos los miembros, no puede ubicarse en discos que dependen de la disponibilidad de algún miembro.Consulte la documentación del fabricante para información detallada del producto y de la instalación.
Hay algunos factores que deben ser considerados cuando se configura el almacenamiento compartido en el cluster:
RAID externo
Se recomienda fuertemente usar RAID 1 (mirroring) para hacer los datos del servicio y las particiones compartidas del cluster altamente disponibles. Opcionalmente, también se puede emplear paridad RAID para mayor disponibilidad. No use solo RAID 0 (striping) para particiones compartidas porque esto reduce la disponibilidad del almacenamiento.
Configuraciones de SCSI Multi-Initiator
Las configuraciones multi-initiator SCSI no son soportadas debido a la dificultad para obtener la terminación de bus apropiada.
El nombre del dispositivo Red Hat Enterprise Linux para cada dispositivo de almacenamiento compartido debe ser el mismo en cada miembro. Por ejemplo, un dispositivo llamado /dev/sdc en un miembro debe llamarse /dev/sdc en los otros miembros cluster. Usando hardware idéntico para todos los miembros cluster usualmente asegura que estos dispositivos se nombrarán igual.
Una partición de disco solamente puede ser usada por un servicio cluster.
No incluya ningún sistema de archivos usado en el servicio cluster en los archivos locales /etc/fstab del miembro, porque el software del cluster debe controlar el montaje y desmontaje de servicios de sistemas de archivos.
Para un uso óptimo de los sistemas de archivos compartidos, asegúrese de especificar el tamaño de bloques a 4 KB con la opción -b a mke2fs. Un tamaño de bloque más pequeño puede causar tiempos muy largos de fsck. Refiérase a Sección 1.4.4.6.
La siguiente lista detalla los requerimientos de SCSI paralelo, los cuales deben ser seguidos si se emplean en un ambiente cluster:
Los buses SCSI deben estar terminados en cada punta y se deben seguir las restricciones en cuanto a largo y conexión en caliente (hot plugging).
Los dispositivos (discos, adaptadores de bus del host (HBA) y controladores RAID) en un bus SCSI deben tener un número de identificación SCSI único.
Consulte la Sección B.2 para más información.
Además, se recomienda enfáticamente conectar el recinto de almacenamiento a un sistema redundante UPS para una mayor disponibilidad de energía. Vea la Sección 1.4.3 para más información.
Consulte la Sección 1.4.4.1 y la Sección 1.4.4.2 para más información sobre la configuración de almacenamiento compartido.
Después de configurar el hardware del almacenamiento compartido, particione los discos y luego cree sistemas de archivos o dispositivos brutos en las particiones. Se deben crear dos dispositivos brutos para las particiones del cluster primaria y shadow. Consulte la Sección 1.4.4.3, la Sección 1.4.4.4, Sección 1.4.4.5 y Sección 1.4.4.6 para más información.
Un bus SCSI single-initiator tiene sólo un miembro conectado a él y provee aislamiento del host y un mejor rendimiento que un bus multi-initiator. Los buses Single-initiator aseguran que cada miembro esté protegido contra interrupciones debidas a la carga de trabajo, inicialización o reparaciones de los otros miembros.
Cuando se usa un controlador de arreglos RAID simple o dual que tiene múltiples puertos host y provee acceso simultáneo a todas las unidades lógicas compartidas desde los puertos host en el recinto de almacenamiento, es posible instalar buses single-initiator SCSI para conectar cada miembro al arreglo RAID. Si una unidad lógica puede iniciar el proceso de failover desde un controlador al otro, el proceso debe ser transparente para el sistema operativo. Note que algunos controladores RAID restringen un conjunto de discos a un controlador o puerto específico. En este caso, no es posible una configuración de bus single-initiator.
Un bus single-initiator se debe ajustar a los requerimientos especificados en la Sección B.2.
Para establecer una configuración de un single-initiator SCSI bus, se requiere lo siguiente:
Habilitar la terminación on-board para cada adaptador de bus del host.
Habilitar la terminación para cada controlador RAID.
Usar el cable SCSI apropiado para conectar cada adaptador de bus al recinto de almacenamiento.
La configuración de la terminación del adaptador de bus del host se hace usualmente en la utilidad del adaptador del BIOS durante el arranque del miembro. Para configurar la terminación del controlador RAID, refiérase a la documentación del fabricante. La Figura 1-5 muestra una configuración que usa dos buses SCSI single-initiator.
La Figura 1-6 muestra la terminación en un arreglo RAID de controlador único conectado a dos buses single-initiator SCSI.
La Figura 1-7 muestra la terminación en un arreglo RAID de controlador dual conectado a dos buses SCSI single-initiator.
La Fibra Canal puede ser usada en configuraciones de single-initiator o multi-initiator.
Una interconexión de Fibra Canal single-initiator tiene solamente un miembro conectado. Esto puede proveer de un mejor aislamiento del host y un mejor rendimiento que un bus multi-initiator. Una interconexion single-initiator asegura que cada miembro esté protegido de interrupciones debidas a la carga de trabajo, inicialización o reparaciones de otro miembro.
Si se emplea un arreglo RAID que tiene puertos host múltiples y el arreglo RAID provee de acceso simultáneo a todas las unidades lógicas compartidas desde los puertos host en el recinto de almacenamiento, instale interconexiones de Fibra Canal single-initiator para conectar cada miembro al arreglo RAID. Si una unidad lógica puede iniciar una caída desde un controlador al otro, el proceso debe ser transparente al sistema operativo.
La Figura 1-8 muestra una formación RAID de controlador único con dos puertos host y los adaptadores de bus del host conectados directamente al controlador RAID, sin utilizar concentradores o switches de Fibra canal. Cuando se utilice este tipo de conexión single-initiator de Fibra Canal, su controlador RAID debe tener un puerto de host separado para cada miembro cluster.
Figura 1-8. Arreglo RAID de un sólo controlador conectado a una interconexión Fibra Canal single-initiator
La formación RAID externa debe tener un canal SCSI separado para cada miembro cluster. En clusters con más de dos miembros, conecte cada miembro a un canal SCSI diferente en la formación RAID, usando un bus SCSI single-initiator como se muestra en la Figura 1-8.
Para conectar múltiples miembros cluster al mismo puerto host en la formación RAID, utilice un concentrador FC o un switch. En este caso, cada HBA es conectado al concentrador o switch y el concentrador o switch es conectado a un puerto host en el controlador RAID.
También se requiere un concentrador o switch de Fibra Canal con una formación RAID de controlador dual con dos puertos host en cada controlador. Esta configuración se muestra en la Figura 1-9. Se pueden conectar miembros cluster adicionales a los concentradores o switches de Fibra Canal mostrados en el diagrama. Algunas formaciones RAID incluyen un concentrador incorporado para que cada puerto host ya esté conectado a cada uno de los controladores RAID internos. En este caso, quizás no se necesite un concentrador o switch externo adicional.
Se deben crear dos dispositivos brutos en el almacenamiento compartido del disco para la partición compartida primaria y la partición compartida shadow. Cada partición compartida debe tener un tamaño mínimo de 10 MB. La cantidad de datos en las particiones compartidas es constante; no se incrementa ni disminuye con el paso del tiempo.
Las particiones compartidas solamente pueden ser usadas para guardar la información del estado del cluster, incluyendo lo siguiente:
Estados del bloqueo del cluster
Estados de servicios
Información de configuración
Periódicamente, cada miembro escribe el estado de sus servicios al almacenamiento compartido. Además de esto, las particiones compartidas contienen una versión del archivo de configuración del cluster. Esto asegura que cada miembro tiene una vista común de la configuración del cluster.
Si se corrompe la partición compartida primaria, los miembros cluster leen la información desde la partición compartida shadow o de backup y simultáneamente repara la partición primaria. La consistencia de los datos es mantenida a través de sumas de comprobación (checksums) y cualquier inconsistencia es corregida automáticamente.
Si un miembro es incapaz de escribir en ambas particiones compartidas al momento del inicio, no se le permitirá unirse al cluster. Además, si un miembro activo no puede continuar escribiendo en ambas particiones, este miembro se removerá asímismo del cluster ejecutando un reinicio y quizás sea encendido remotamente por un miembro saludable.
Los siguientes son los requerimientos de las particiones compartidas:
Ambas particiones deben tener un tamaño mínimo de 10 MB.
Las particiones compartidas deben ser dispositivos brutos. No pueden contener sistemas de archivos.
Las particiones compartidas solamente pueden ser usadas para estado del cluster e información de la configuración.
Las siguientes son las pautas recomendadas para la configuración de particiones compartidas:
Se recomienda fuertemente configurar un subsistema RAID para el almacenamiento compartido, y usar un RAID 1 (mirroring) para hacer altamente disponible la unidad lógica que contiene las particiones compartidas. Opcionalmente, la paridad RAID puede ser usada para alta disponibilidad. No use solamente RAID 0 (striping) para particiones compartidas.
Coloque ambas particiones compartidas en el mismo conjunto RAID, o en el mismo disco si no se está empleando RAID, debido a que ambas particiones compartidas deben estar disponibles para que el cluster funcione.
No coloque las particiones compartidas en un disco que contiene servicios de datos con mucho acceso. Si es posible, coloque las particiones compartidas en discos que contengan servicios de datos que se usen raramente.
Consulte la Sección 1.4.4.4 y la Sección 1.4.4.5 para más información sobre la configuración de particiones compartidas.
Vea la Sección 2.5 para más información sobre como modificar el archivo rawdevices para vincular los dispositivos de caracteres brutos a los dispositivos en bloque cada vez que los miembros arranquen.
Después que el hardware del almacenamiento compartido ha sido configurado, particione los discos para que así puedan ser usados en el cluster. Luego, cree los sistemas de archivos o dispositivos brutos en las particiones. Por ejemplo, dos dispositivos brutos deben ser creados para las particiones compartidas usando las pautas descritas en la Sección 1.4.4.3.
Invoque el comando interactivo parted para modificar una tabla de particiones de disco y dividir el disco en particiones. Mientras esté ejecutando parted, use el comando p para desplegar la tabla de particiones actual y el comando mkpart para crear nuevas particiones. El ejemplo siguiente muestra como utilizar parted para crear una partición en un disco:
Invoque el comando interactivo parted desde el indicador de comandos de la shell y especifique dispositivo de disco compartido disponible. En el indicador de comandos de (parted), utilice el comando p para desplegar la tabla de particiones actual. La salida debería ser similar a lo siguiente:
Disk geometry for /dev/sda: 0.000-4340.294 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags |
Decida qué tan grande será la partición. Cree una partición de este tamaño usando el comando mkpart en parted. Aún cuando mkpart no crea un sistema de archivos, normalmente requiere un tipo de sistema de archivos al momento de lacreación de la partición. parted utiliza un rango en el disco para determinar el tamaño de la partición; el tamaño es el espacio entre el final y el comienzo del rango dado. El ejemplo siguiente muestra cómo crear dos particiones de 20 MB cada una en un disco vacío.
(parted) mkpart primary ext3 0 20 (parted) mkpart primary ext3 20 40 (parted) p Disk geometry for /dev/sda: 0.000-4340.294 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags 1 0.030 21.342 primary 2 21.343 38.417 primary |
Cuando se requieren más de cuatro particiones en un único disco, es necesario crear una partición extendida. Si se requieren particiones extendidas, el comando mkpart también realiza esta tarea. En este caso, no es necesario especificar el tipo de sistema de archivo.
![]() | Nota |
---|---|
Solamente se crea una partición extendida y esta debe ser una de las cuatro particiones primarias. |
(parted) mkpart extended 40 2000 (parted) p Disk geometry for /dev/sda: 0.000-4340.294 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags 1 0.030 21.342 primary 2 21.343 38.417 primary 3 38.417 2001.952 extended |
Una partición extendida permite la creación de particiones lógicas dentro de ella. El ejemplo siguiente muestra la división de la partición extendida en dos particiones lógicas.
(parted) mkpart logical ext3 40 1000 (parted) p Disk geometry for /dev/sda: 0.000-4340.294 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags 1 0.030 21.342 primary 2 21.343 38.417 primary 3 38.417 2001.952 extended 5 38.447 998.841 logical (parted) mkpart logical ext3 1000 2000 (parted) p Disk geometry for /dev/sda: 0.000-4340.294 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags 1 0.030 21.342 primary 2 21.343 38.417 primary 3 38.417 2001.952 extended 5 38.447 998.841 logical 6 998.872 2001.952 logical |
Una partición puede ser eliminada utilizando el comando rm de parted. Por ejemplo:
(parted) rm 1 (parted) p Disk geometry for /dev/sda: 0.000-4340.294 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags 2 21.343 38.417 primary 3 38.417 2001.952 extended 5 38.447 998.841 logical 6 998.872 2001.952 logical |
Después de haber creado todas las particiones requeridas, salga de parted usando el comando quit. Si una partición fué agregada, eliminada o cambiada mientras ambos miembros estaban encendidos y conectados al almacenamiento compartido, reinicie el otro miembro para que este reconozca las modificaciones. Después de particionar un disco, formatee la partición para ser usada en el cluster. Por ejemplo, cree el sistema de archivos o los dispositivos brutos para las particiones compartidas. Refiérase a la Sección 1.4.4.5 y a la Sección 1.4.4.6 para más información.
Para información básica sobre el particionamiento de discos duros durante la instalación, refiérase al Manual de instalación de Red Hat Enterprise Linux.
Después de particionar los discos de almacenamiento compartido, cree dispositivos brutos en las particiones. Los sistemas de archivos son dispositivos en bloque (por ejemplo, /dev/sda1) que colocan en memoria caché los datos que ha sido usados recientemente para así mejorar el rendimiento. Los dispositivos brutos no usan la memoria del sistema para hacer caching. Vea la Sección 1.4.4.6 para más información.
Red Hat Enterprise Linux soporta dispositivos brutos de caracteres que no son hard-coded contra dispositivos en bloque específicos. En su lugar, Red Hat Enterprise Linux usa un número importante (actualmente 162) para implementar una serie de dispositivos brutos sin limite en el directorio /dev/raw. Cualquier dispositivo en bloque puede tener un dispositivo bruto de caracteres en primer plano, aún si el dispositivo en bloque es cargado más tarde en tiempo de ejecución.
Para crear un dispositivo bruto, modifique el archivo /etc/sysconfig/rawdevices para juntar un dispositivo bruto de caracteres al dispositivo en bloque apropiado para que pueda ser abierto, leído y escrito.
Las particiones compartidas y algunas aplicaciones de bases de datos requieren de dispositivos brutos, porque estas aplicaciones realizan sus propias funciones de caché del buffer para propósitos de rendimiento. Las particiones compartidas no pueden contener sistemas de archivos pues si información del estado del cluster es depositada en memoria de sistema, los miembros no tendrán una vista consistente de los datos de estado.
Los dispositivos brutos de caracteres (raw devices) deben ser limitados a dispositivos en bloque cada vez que se arranca un miembro. Para asegurarse de que esto ocurra, modifique el archivo /etc/sysconfig/rawdevices y especifique los lazos de la partición compartida. Si se está usando un dispositivo bruto en un servicio cluster, use este archivo para enlazar los dispositivos al momento de carga del sistema. Vea la Sección 2.5 para más información.
Después de editar /etc/sysconfig/rawdevices, los cambios tomarán efecto bien sea reanudando el sistema o ejecutando el siguiente comando:
service rawdevices restart |
Haga un query de todos los dispositivos brutos usando el comando raw -aq. La salida debería ser similar a lo siguiente:
/dev/raw/raw1 bound to major 8, minor 17 /dev/raw/raw2 bound to major 8, minor 18 |
Note que, para los dispositivos brutos, no hay coherencia de la caché entre el dispositivo bruto y el dispositivo en bloque. Además, las peticiones deben estar alineadas a 512-byte en memoria y en disco. Por ejemplo, el comando estándar dd no puede ser usado en dispositivos brutos porque el buffer de memoria que el comando pasa a la llamada de escritura del sistema, no está alineada en un límite de 512-byte.
Para más información sobre como usar el comando raw, refiérase a la página del manual de raw(8).
![]() | Nota |
---|---|
Se deben usar los mismos nombres de dispositivos brutos en todos los miembros del cluster (por ejemplo, /dev/raw/raw1 and /dev/raw/raw2). |
Use el comando mkfs para crear un sistema de archivo ext3.Por ejemplo:
mke2fs -j -b 4096 /dev/sde3 |
Para un rendimiento óptimo de los sistemas de archivos compartidos, asegúrese de especificar un tamaño de bloque de 4 KB con la opción -b de mke2fs. Un tamaño de bloque más pequeño puede causar largos tiempos de fsck.