Red Hat Cluster Suite: Configurazione e gestione di un cluster | ||
---|---|---|
Indietro | Capitolo 1. Installazione Hardware e Configurazione del Sistema Operativo | Avanti |
Dopo aver installato Red Hat Enterprise Linux, impostare i componenti dell'hardware del cluster e verificare l'installazione per assicurare che i membri riconoscano tutti i dispositivi collegati. Notare che le fasi esatte per l'impostazione dell'hardware dipendono dal tipo di configurazione. Consultare la Sezione 1.1 per maggiori informazioni inerenti le configurazioni del cluster.
Per impostare l'hardware di un cluster, seguire le seguenti fasi:
Interrompere i membri e disconnetterli dalla loro fonte di alimentazione.
Impostate i canali Ethernet unificati, se applicabile. Consultate la Sezione 1.4.1 per maggiori informazioni.
Quando si usano gli interruttori di alimentazione, impostare gli interruttori e collegare ogni membro ad uno di essi.Consultare la Sezione 1.4.2 per maggiori informazioni.
In aggiunta, é consigliabile collegare ogni interruttore (oppure ogni cavo di alimentazione del membro se non si usano interruttori) ad un sistema UPS diverso. Consultare la Sezione 1.4.3 per maggiori informazioni sull'uso dei sistemi facoltativi UPS.
Impostare la memoria del disco condiviso a seconda delle istruzioni del rivenditore e collegare i membri all'unitá di memoria esterna. Consultarela Sezione 1.4.4 per maggiori informazioni su come eseguire quanto sopra.
In aggiunta, é consigliabile collegare l'unitá di memoria a sistemi UPS ridondanti. Consultare la Sezione 1.4.3 per maggiori informazioni sull'uso dei sistemi UPS facoltativi.
Alimentare l'hardware e avviare ogni membro del cluster. Durante il procedimento di avvio, inserire la utility BIOS per modificare l'impostazione del membro:
Assicurarsi che il numero d'identificazione SCSI usato dall'HBA, sia unico per il bus SCSI al quale é collegato. Consultare la Sezione B.5 per maggiori informazioni su come effettuare questo compito.
Abilitare o disabilitare la terminazione onboard per ogni adattatore bus host, come richiesto dalla configurazione dello storage. Consultare la Sezione 1.4.4 e la Sezione B.3 per maggiori informazioni su come effettuare questo compito.
Abilitare il membro ad un avvio automatico quando é alimentato.
Uscite dalla utility BIOS e continuate ad avviare ogni membro. Esaminare i messaggi d'avvio per verificare che Red Hat Enterprise Linux sia stato configurato e che possa quindi riconoscere il set completo dei dischi condivisi. Usare il comando dmesg per visualizzare i messaggi d'avvio della console. Consultare la Sezione 1.3.3 per maggiori informazioni sull'uso del comando dmesg.
Verificare che i membri possano comunicare attraverso ogni collegamento Ethernet point-to-point, usando il comando ping per inviare i pacchetti attraverso ogni interfaccia di rete.
Impostate le partizioni del cluster condiviso sulla memoria del disco condiviso. Controllare la Sezione 1.4.4.3 per maggiori informazioni su come effettuare questo compito.
L'Ethernet channel bonding in un sistema del cluster di tipo no-single-point-of-failure, abilita un collegamento di rete fault tolerant, combinando due dispositivi Ethernet in un dispositivo virtuale. L'interfaccia del canale unificato risultante, assicura che nel caso di una verifica di un errore del dispositivo Ethernet, l'altro dispositivo diventi attivo. Questo tipo di channel bonding, chiamata policy active-backup, permette un collegamento di entrambi i dispositivi unificati ad un interruttore, oppure è in grado di abilitare ogni dispositivo Erhernet al collegamento a interruttori o hub separati, il quale elimina il single point of failure nell'interruttore/hub di rete.
Il Channel bonding richiede che ogni membro del cluster abbia due dispositivi Ethernet installati. Quando viene caricato, il modulo bonding usa l'indirizzo MAC del primo dispositivo di rete di tipo 'enslaved', e assegna l'indirizzo MAC all'altro dispositivo di rete, se il primo dispositivo non è in grado di rilevare il link.
Per configurare due dispositivi di rete per il channel bonding, eseguire quanto segue:
Creare un dispositivo bonding in /etc/modules.conf. Per esempio:
alias bond0 bonding options bonding miimon=100 mode=1 |
Questo carica il dispositivo bonding con il nome dell'interfaccia bond0, e invia le opzioni al driver bonding, in modo da configurarlo come un dispositivo master attivo di backup, per le interfacce di rete di tipo 'enslaved'.
Modificare il file di configurazione /etc/sysconfig/network-scripts/ifcfg-ethX per eth0 e eth1 in modo tale che i file possano mostrare dei contenuti identici. Per esempio:
DEVICE=ethX USERCTL=no ONBOOT=yes MASTER=bond0 SLAVE=yes BOOTPROTO=none |
Questo asservirà ethX (sostituire X con il numero assegnato dei dispositivi Ethernet) al dispositivo master bond0.
Creare uno script di rete per il dispositivo bonding (per esempio, /etc/sysconfig/network-scripts/ifcfg-bond0), il quale dovrebbe apparire come il seguente esempio:
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 |
Riavviare il sistema in modo da confermare i cambiamenti. Alternativamente, caricare manualmente il dispositivo bonding e riavviare la rete. Per esempio:
/sbin/insmod /lib/modules/`uname -r`/kernel/drivers/net/bonding/bonding.o \ miimon=100 mode=1 |
/sbin/service network restart |
Gli interruttori permettono ad un membro di baipassare(power-cycle) un altro membro prima di riavviare i propri servizi come parte del procedimento di failover. L'abilitá di disabilitare un sistema in modo remoto, assicura una integritá dei dati in qualsiasi condizione di errore. É consigliato che gli ambienti di produttivitá usino gli interruttori di alimentazione, oppure i timer watchdog nella configurazione del cluster. Solo ambienti di sviluppo (test) dovrebbero usare una configurazione senza interruttori di alimentazione. Consultare la Sezione 1.1.3per una descrizione dei diversi tipi di interruttori. Nota bene che all'interno di questa sezione, il termine generale "interruttore di alimentazione" include anche i timer watchdog.
In una configurazione cluster che usa interruttori fisici, ogni cavo di alimentazione del membro, é collegato ad un interruttore attraverso un collegamento seriale o di rete (a seconda del tipo di interruttore). Quando si verifica un failover, un membro puó usare questo collegamento per baipassare un altro membro, prima di riavviare i propri servizi.
Gli interruttori di alimentazione proteggono contro la corruzione dei dati se un membro insensibile (o sospeso) diventa sensibile dopo che i propri servizi siano subito un fail over, emettendo cosí un I/O ad un disco che allo stesso tempo riceve un I/O da un altro membro. In aggiunta, se si verifica un errore ad un demone del quorum, il membro non é piú in grado di controllare le partizioni del cluster condiviso. Se gli interruttori di alimentazione o i timer watchdog non vengono usati nel cluster, questa condizione di errore puó risultare in una esecuzione del servizio su piú di un membro,causando una corruzione dei dati e in alcuni casi un arresto del sistema.
É fortemente consigliato usare interruttori in un sistema del cluster. Tuttavia , gli amministratori che sono a conoscenza dei rischi, possono scegliere d'impostare un cluster senza interruttori.
Un membro puó essere sospeso per pochi secondi se é in fase di scambio o se é in possesso di un carico di lavoro molto alto. Per questa ragione, viene lasciato trascorrere un adeguato limite di tempo prima di considerare un membro insensibile,(generalmente il tempo che intercorre é di quindici secondi).
Se un membro determina che un membro sospeso non é piú operativo e che gli interruttori di alimentgazione sono usati nel cluster stesso, quel membro baipasserà il membro sospeso prima di riavviare i propri servizi. I cluster configurati per usare i timer watchdog effettuano un 'self-reboot' in molti casi di membri sospesi.Ciò renderá possibile che il membro sospeso effettui un riavvio in una condizione pulita, rendendo possibile la prevenzione di una emissione I/O non corrompendo cosí i dati del servizio.
I membri sospesi riavviano se stessi o a causa di un watchdog, mancanza di invio dei pacchetti heartbeat, o — nel caso in cui un membro non abbia un interruttore fisico di alimentazione — perdita della condizione quorum.
I membri sospesi possono essere riavviati da altri membri solo se essi sono collegati ad un interruttore. Se il sistema sospeso non diventerà mai sensibile, e se non vengono usati gli interruttori, allora è necessario effettuare un riavvio manuale.
Se usati, gli interruttori devono essere impostati a seconda delle istruzioni del rivenditore. Tuttavia, alcuni compiti specifici del cluster possono richiedere l'uso di un interruttore nel cluster stesso. Controllare la Sezione B.1 per informazioni piú dettagliate sugli interruttori (incluso informazioni sui timer watchdog). Assicurarsi di prendere nota delle istruzioni e degli attributi funzionali di interruttori specifici. Notare che le informazioni specifiche del cluster fornite in questo manuale, possono sostituire le informazioni del rivenditore.
Nel collegare gli interruttori, fare particolare attenzione nell'assicurare che ogni cavo sia inserito nella presa corretta. Ció é molto importante perché non é possibile per il software verificare, senza alcuna assistenza, il corretto collegamento. Se il collegamento non è corretto, si può baipassare il membro sbagliato, oppure per un membro, di determinare in modo incorretto che sia stato baipassato con successo un altro membro del cluster.
Dopo aver impostato gli interruttori, eseguite quanto segue per poter collegarli ai membri:
Collegare il cavo di alimentazione di ogni membro ad un interruttore.
Collegare ogni membro all'interruttore. Il cavo usato per il collegamento seriale dipende dal tipo di interruttore. Per esempio, interruttori seriali usano cavi null modem, mentre un interruttore collegato alla rete richiede un cavo patch Ethernet.
Collegare il cavo di alimentazione di ogni interruttore ad una fonte di alimentazione. É consigliato collegare ogni interruttore ad un sistema UPS diverso. Consultare la Sezione 1.4.3 per maggiori informazioni.
Dopo l'installazione del software del cluster, effettuare una prova degli interruttori per assicurarsi che ogni membro possa baipassare un altro membro prima di avviare il cluster. Consultare la Sezione 2.11.2 per maggiori informazioni.
I sistemi Uninterruptible power supplies (UPS) forniscono una fonte di alimentazione altamente disponibile. Idealmente, una soluzione ridondante dovrebbe essere usata per incorporare sistemi UPS multipli (uno per server). Per ottenere un fault-tolerance ottimale, é possibile incorporare due sistemi UPS per server e un APC (Automatic Transfer Switches) per gestirel'alimentazione e disabilitare la gestione del server. Entrambe le soluzioni dipendono soltanto dal livello di disponibilitá desiderato.
Non é consigliato usare una infrastruttura UPS singola come fonte unica di alimentazione per il cluster. Una soluzione UPS dedicata al cluster è più flessibile in termini di disponibilitá e di gestione.
Un sistema UPS completo deve essere in grado di fornire un adeguato voltaggio e corrente per un periodo di tempo prolungato. Mentre non vi è alcun UPS singolo idoneo ad ogni richiesta di alimentazione, si può ottenere una soluzione idonea per una configurazione particolare.
Se il sottosistema della memoria del disco del cluster ha una doppia fonte di alimentazione con cavi separati, impostare due sistemi UPS e collegare un interruttore (oppure un cavo di alimentazione di un membro se non si usano interruttori) ed un cavo di alimentazione del sottosistema di memoria, ad ogni sistema UPS. Una configurazione del sistema UPS ridondante, é mostrata in Figura 1-3.
Una configurazione alternativa di alimentazione ridondante, si puó ottenere collegando entrambi gli interruttori (oppure entrambi i cavi di alimentazione del membro) ed il sottosistema della memoria del disco, allo stesso sistema UPS. Questa é la soluzione migliore in termini di costo-efficienza, e garantisce una certa protezione contro il verificarsi di una perdita di alimentazione. Tuttavia, se si verifica un guasto, il sistema UPS singolo puó diventare un potenziale punto di errore. In aggiunta, un sistema UPS puó non essere in grado di fornire alimentazione sufficiente a tutti i dispositivi integrati, per un adeguato arco di tempo. La configurazione di un sistema UPS singolo, é mostrata in Figura 1-4.
Molti sistemi UPS forniti dai rivenditori, includono applicazioni Red Hat Enterprise Linux in grado di controllare lo stato operativo del sistema UPS attraverso un collegamento ad una porta seriale. Se l'alimentazione della batteria é bassa, il software di controllo inizierá la procedura completa per la chiusura del sistema. Se si verifica quanto detto, il software del cluster verrebbe fermato, in quanto esso controllato da uno script del runlevel Sys V (per esempio, /etc/rc.d/init.d/cluster).
Consultare la documentazione UPS fornita dal rivenditore, per informazioni dettagliate inerenti l'installazione.
In un cluster, la memoria del disco condiviso viene usata per contenere i dati del servizio e due partizioni (primaria e shadow) che conservano le informazioni inerenti lo stato del cluster. Poichè i dati memorizzati devono essere disponibili a tutti i membri, esso non puó essere posizionato su dischi che dipendono dalla disponibilitá di ogni membro.Consultare la documentazione fornita dal rivenditore per informazioni piú dettagliate sul prodotto e sulla sua installazione.
Ci sono alcuni fattori da considerare quando si imposta uno shared disk storage in un cluster:
RAID Esterno
É fortemente consigliato usare RAID 1 (mirroring) per rendere i dati del servizio e le partizioni del cluster condivise, altamente disponibili.Alternativamente si possono usare i parity RAID per ottenere un'alta disponibilitá. Non usare RAID 0 (stripping) da solo per le partizioni condivise,in quanto ne riduce la disponibilitá della memoria.
Configurazioni SCSI Multi-Initiato
Le configurazioni SCSI Multi-initiator non sono supportate a causa della difficoltá ad ottenere una terminazione idonea del bus.
Il nome del dispositivo Red Hat Enterprise Linux di ogni dispositivo di memoria condiviso, deve essere lo stesso su ogni membro. Per esempio, un dispositivo chiamato /dev/sdc su di un membro, deve essere chiamato /dev/sdcsu altri member del cluster.Usando un identico hardware per tutti i membri, generalmente si é in grado di assicurare che questi dispositivi vengano chiamati nello stesso modo.
Una partizione del disco puó essere usata da un solo servizio del cluster.
Non includere alcun file system usato in un servizio del cluster nei file locali /etc/fstab,questo perché il software del cluster deve controllare la procedura di montaggio e smontaggio del servizio dei file system.
Per un rendimento ottimale dei file system condivisi, assicurarsi di specificare a mke2fs, una misura del blocco di 4KB con l'opzione -b. Una misura del blocco più piccola, può causare dei tempi fsck lunghi. Consultare la Sezione 1.4.4.6.
Il seguente elenco, riporta i dettagli dei requisiti dello SCSI parallelo, e deve essere seguita scrupolosamente quando si usano bus SCSI paralleli in un ambiente del cluster:
I bus SCSI devono essere terminati ad ogni estremitá, e devono aderire alle restrizioni in lunghezza e di hot plugging.
Dispositivi (dischi, adattatori host bus, e RAID controller) su di un bus SCSI devono avere un numero d'identificazione SCSI unico.
Consultare la Sezione B.2 per maggiori informazioni.
É fortemente consigliato collegare l'unitá di memoria, ai sistemi UPS ridondanti per una fonte di alimentazione altamente disponibile. Consultare la Sezione 1.4.3 per maggiori informazioni.
Consultare la Sezione 1.4.4.1 e la Sezione 1.4.4.2 per informazioni sulla configurazione della memoria condivisa.
Dopo aver impostato l'hardware della memoria del disco condivisa, partizionare i dischi e successivamente creare dei file system o dei dispositivi raw sulle partizioni. Due dispositivi raw devono essere creati per le partizioni primarie e shadow condivise del cluster. Consultare la Sezione 1.4.4.3, la Sezione 1.4.4.4, la Sezione 1.4.4.5, e la Sezione 1.4.4.6 per maggiori informazioni.
Un bus SCSI single-initiator ha solo un membro collegato ad esso e fornisce un isolamento host e migliori prestazioni di un bus multi-initiator. I bus single-initiator, assicurano che ogni membrovenga protetto da interruzioni dovute al carico di lavoro, inizializzazione, o riparazione di altri membri.
Quando si usa un array RAID singolo o dual-controller che possiede porte host multiple e fornisce simultaneamente accesso a tutte le unitá logiche condivise dalle porte host su di una unitá di memoria, é possibile impostare i bus SCSI single-initiator per collegare ogni membro del cluster all'array RAID. Se una unitá logica é in grado di effettuare un fail over da un controller ad un altro, il procedimento deve essere trasparente al sistema operativo. Notare che alcuni controller RAID limitano un set di dischi adun controller o ad una porta specifica. In questo caso, non é possibile l'impostazione di bus single-initiator.
Un bus initiator singolo deve essere conforme alle richieste descritte in la Sezione B.2.
Per impostare una configurazione di un bus SCSI initiator singolo, seguire le seguenti fasi:
Permettere la terminazione on-board per ogni adattatore bus host.
Permettere la terminazione di ogni controller RAID.
Usare il cavo SCSI appropriato per collegare ogni adattatore bus host alla unitá storage.
L'impostazione della terminazione dell'adattatore bus host, viene generalmente fatta nella utility BIOS dell'adattatore durante l'avvio del membro. Per impostare la terminazione del controller RAID, fare riferimento alla documentazione del rivenditore. Figura 1-5 mostra una configurazione che usa due bus SCSI single-initiator.
Figura 1-6 mostra la terminazione in un array RAID single-controller,collegato a due bus SCSI single-initiator.
Figura 1-7 mostra la terminazione in un array RAID dual-controller,collegato a due bus SCSI single-initiator.
Un Fibre Channel puó essere usato su configurazioni single-initiator oppure multi-initiator.
Una comunicazione Fibre Channel single-initiator, ha solo un membro collegato ad esso. Ció puó fornire un migliore isolamento host e una migliore prestazione rispetto a un bus multi-initiator.Comunicazioni Single-initiator, assicurano che ogni membro venga protetto da interruzioni dovuti al carico di lavoro, all'inizializzazione o alla riparazione di un altro membro.
Se si usa un array RAID che possiede porte host multiple e provvede ad accessi simultanei a tutte le unitá logiche condivise dalle porte host sull'unitá di memoria, impostare delle comunicazioni Fibre Channel single-initiator, per collegare ogni membro all'array RAID. Se una unitá logica puó effettuare un fail over da un controller ad un altro, il procedimento deve essere trasparente al sistema operativo.
Figura 1-8 mostra un array RAID single-controller con due porte host con adattatori bus host, collegati direttamente al controller RAID senza usare le hub del Fibre Channel o interruttori. Quando si usa questo tipo di collegamento Fibre Channel single-initiator, il vostro controller RAID deve avere una porta host separata per ogni membro del cluster.
L'array RAID esterno deve avere un canale SCSI separato per ogni membro del cluster. Nei cluster con più di due membri, collegare ogni membro ad un canale SCSI diverso sull'array RAID, usando un bus SCSI del tipo single-initiator, come mostrato in Figura 1-8.
Per collegare membri multipli del cluster sulla stessa porta host sull'array RAID, usare un hub FC o un interruttore. In questo caso, ogni HBA è collegato all'hub o all'interruttore, i quali sono collegati ad una porta host di ogni controller RAID.
Un hub del Fibre Channel o un interruttore, sono necessari con un array RAID di tipo dual-controller, con due porte host su ogni controller. Questa configurazione è mostrata in Figura 1-9. Membri del cluster aggiuntivi possono essere collegati all'hub del Fibre Channel o all'interruttore mostrato nel diagramma. Alcuni array RAID includono un hub interno, in modo tale che ogni porta host sia già collegata ad ogni controller RAID interno. In questo caso può essere necessario un hub esterno aggiuntivo o un interruttore.
Devono essere creati due dispositivi raw della memoria del disco condivisa, per la partizione condivisa primaria e per la partizione condivisa shadow. Ogni partizione condivisa deve avere una grandezza minima di 10 MB. La quantitá dei dati in una partizione condivisa é costante; non aumenta o diminuisce col passare del tempo.
Le partizioni condivise sono usate solo per conservare informazioni sulla condizione del cluster, incluso quanto segue:
Condizioni lock del cluster
Condizioni del servizio
Informazioni sulla configurazione
Periodicamente, ogni membro scrive la condizione dei suoi servizi in una memoria condivisa. In aggiunta, le partizioni condivise contengono una versione del file di configurazione del cluster. Ció assicura che ogni membro abbia una vista comune della configurazione del cluster.
Se la partizione primaria condivisa é corrotta, i membri del cluster leggeranno le informazioni dalla partizione condivisa shadow (o di backup) e simultaneamente la partizione primaria verrá riparata. La consistenza dei dati viene mantenuta attraverso delle somme di controllo, e qualsiasi inconsistenza tra le partizioni, viene automaticamente corretta.
Se un membro non é in grado di scrivere su entrambe le partizioni condivisedurante l'avvio, non gli verrá permesso di unirsi al cluster. In aggiunta, se un membro attivo, non é piú in grado di scrivere su entrambe le partizioni condivise, il membro si auto-escluderá dal cluster effettuando un riavvio (un membro sano può baipassarlo in modo remoto).
I seguenti sono requisiti della partizione condivisa:
Entrambe le partizioni devono avere una misura minima di 10 MB.
Le partizioni condivise devono essere dei dispositivi raw. Esse non possono contenere dei file system.
Le partizioni condivise possono essere usate solo per le informazioni sulla condizione del cluster e sulla configurazione.
I seguenti sono delle direttive consigliate per la configurazione delle partizioni condivise:
É fortemente consigliato impostare un sottosistema RAID per la memoriacondivisa, e usare RAID 1(mirroring) per rendere l'unitá logica che contiene le partizioni condivise, altamente disponibile. Un'alternativa puó essere rappresentata dall'uso di parity RAID per un'alta disponibilità.Non usare RAID 0 (striping) da solo per le partizioni condivise.
Posizionare entrambe le partizioni condivise sullo stesso set del RAID, oppure sullo stesso disco se il RAID non viene usato, in quanto entrambe le partizioni condivise, devono essere disponibili per far si che il cluster possa funzionare.
Non posizionare le partizioni condivise su di un disco che contiene dati di servizio molto usati. Se possibile, posizionare le partizioni condivise su dischi che contengono dati di servizio usati raramente.
Consultate la Sezione 1.4.4.4 e la Sezione 1.4.4.5 per maggiori informazioni sull'impostazione delle partizioni condivise.
Consultate la Sezione 2.5 per informazioni su come effettuare una modifica dei file rawdevices per collegare i dispositivi del carattere raw ai dispositivi a bloccho, ogni qualvolta i membri eseguono un avvio.
Dopo aver impostato l'hardware della memoria del disco condiviso, partizionare i dischi in modo tale che essi possono essere usati nel cluster. Creare poi, dei file system o dei dispositivi raw sulle partizioni. Per esempio, due dispositivi raw devono essere creati per le partizioni condivise usando le direttive riportate in la Sezione 1.4.4.3.
Usare parted per modificare la tabella della partizione del disco, e divedere il disco in partizioni. Restando in parted, usare il comando p per mostrare la tabella della partizione ed il comando mkpart per creare delle nuove partizioni. Il seguente esempio mostra come usare il comando parted per creare una partizione sul disco:
Invocare parted, dalla shell usando il comando parted e specificando un dispositivo del disco condiviso disponibile. Al prompt (parted), usare p per visualizzare la tabella corrente della partizione. L'output dovrebbe essere simile al seguente:
Disk geometry for /dev/sda: 0.000-4340.294 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags |
Decidere la larghezza di una partizione. Create una partizione di questa grandezza, usando il comando mkpart in parted. Anche se mkpart non crea un file system, normalmente richiede un tipo di file system al momento della creazione della partizione. parted usa una scala sul disco, per determinare la grandezza della partizione, la grandezza è rappresentata dallo spazio che intercorre tra l'inizio e la fine della scala data. Il seguente esempio mostra come creare due partizioni di 20MB ciascuna su di un disco vuoto.
(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 |
Quando sono necessarie più di quattro partizioni su di un singolo disco, è necessario creare una partizione estesa. Se è necessaria una partizione estesa, il comando mkpart è in grado di effettuare questo compito. In questo caso, non è necessario specificare il tipo di file system.
![]() | Nota Bene |
---|---|
Solo una sola partizione estesa può essere creata, e la stessa deve essere una delle quattro partizioni primarie. |
(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 partizione estesa permette la creazione di partizioni logiche al suo interno. Il seguente esempio, mostra la divisione della partizione estesa, in due partizioni logiche.
(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 partizione può essere rimossa usando il comando rm di parted. Per esempio:
(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 |
Dopo aver creato tutte le partizioni necessarie, uscite da parted usando il comando quit. Se è stata aggiunta una partizione, rimossa oppure cambiata mentre i due membri sono alimentati e collegati alla memoria condivisa, riavviare l'altro membro in modo tale che lo stesso sia in grado di riconoscere le modifiche. Dopo aver partizionato un disco, formattare la partizione per un uso nel cluster. Per esempio, create i file system o i dispositivi raw per le partizioni condivise. Consultate la Sezione 1.4.4.5 e la Sezione 1.4.4.6 per maggiori informazioni.
Per informazioni di base su come partizionare i dischi fissi al momento dell'installazione, consultate Red Hat Enterprise Linux Installation Guide.
Dopo il partizionamento dei dischi della memoria condivisa, creare dei dispositivi raw sulle partizioni. I file system sono dei dispositivi a blocco (per esempio, /dev/sda1) che mantengono in memoria i dati usati di recente, in modo da migliorare le prestazioni. I dispositivi raw non utilizzano la memoria del sistema per immagazzinare i suddetti dati. Consultare la Sezione 1.4.4.6 per maggiori informazioni.
Red Hat Enterprise Linux supporta i dispositivi del tipo raw character, che non sono critici da codificare nei confronti di specifici dispositivi a blocco. Red Hat Enterprise Linux usa invece un numero d'identificazione (attualmente 162) per implementare una serie di dispositivi raw separati nella directory /dev/raw. Qualsiasi dispositivo a blocco puó avere un dispositivo raw character front-end, anche se il dispositivo a blocco é stato caricato dopo il tempo di esecuzione o "runtime".
Per creare un dispositivo raw, modificate il file /etc/sysconfig/rawdevices in modo tale da collegare un dispositivo raw character all'appropriato dispositivo a blocco, per permetteri di aprire, leggere e scrivere un dispositivo raw.
Le partizioni condivise e alcune applicazioni del database, richiedono dei dispositivi raw, questo perchè tali applicazioni effettuano unamemorizzazione momentanea (buffer caching). Le partizioni condivisenon possono contenere i file system perché se il dato sulla condizione vieneimmagazzinato nella memoria del sistema, i membri del cluster non avrebbero un quadro consistente degli stessi dati.
I dispositivi a carattere raw devono essere uniti a dispositivi a blocco ogni volta che un membro effettua l'avvio. Per assicurare che questo accada, modificate il file /etc/sysconfig/rawdevices e specificate i legami della partizione condivisa. Se si usa un dispositivo raw in un servizio del cluster, usare questo file per vincolare i dispositivi al momento dell'avvio. Consultare la Sezione 2.5 per maggiori informazioni.
Dopo aver modificato il file /etc/sysconfig/rawdevices i cambiamenti saranno confermati dopo il riavvio o dopo l'esecuzione del seguente comando:
service rawdevices restart |
Interrogare tutti i dispositivi raw usando il comando raw -aq. L'uotput dovrebbe essere simile al seguente:
/dev/raw/raw1 bound to major 8, minor 17 /dev/raw/raw2 bound to major 8, minor 18 |
Notare che per i dispositivi raw, non c'é coerenza nell'immagazzinamento tra il dispositivo raw e il dispositivo a blocco. In aggiunta, le richieste devono essere di 512-byte allineate sia in memoria e sia su disco. Per esempio il comando standard ddnon puó essere usato con i dispositivi raw, in quanto la memoria del buffer che il comando passa al sistema 'call write', non è allineata su 512-byte
Per maggiori informazioni sull'uso del comando raw consultare la pagina man raw(8).
![]() | Nota Bene |
---|---|
Gli stessi nomi del dispositivo raw (per esempio, /dev/raw/raw1 e /dev/raw/raw2) devono essere usati su tutti i membri del cluster. |
Usare il comando mkfs per creare un file system ext3. Per esempio:
mke2fs -j -b 4096 /dev/sde3 |
Per una prestazione ottimale dei file system condivisi, assicurarsi di specificare su mke2fs, una misura del blocco pari a 4KB con l'opzione -b. Una misura del blocco più piccola, può causare tempi più lunghi di fsck.