Questo capitolo descrive i requisiti e le linee guida necessarie per la creazione di file system in mirroring con i metodi di installazione JumpStart personalizzato e Solaris Live Upgrade.
Vengono trattati i seguenti argomenti:
Per altre informazioni di pianificazione sulla creazione di file system in mirroring con il metodo di installazione Solaris Live Upgrade, vedere Indicazioni generali per la creazione di file system in mirroring.
Per istruzioni sulla creazione di file system in mirroring con il metodo di installazione JumpStart personalizzato, vedere Parola chiave filesys (creazione di file system in mirroring) e Parola chiave metadb (creazione di repliche del database di stato).
Per creare un file system in mirroring su una slice specifica, i dischi da utilizzare per il mirroring devono essere collegati direttamente al sistema ed essere disponibili al momento dell'installazione.
Il metodo di installazione JumpStart personalizzato assegna automaticamente i nomi di volume ai submirror RAID-0 nel corso dell'installazione. È possibile opzionalmente assegnare un nome ai volumi RAID-1 (mirror) usando la parola chiave filesys di JumpStart.
Osservare le seguenti regole per assegnare i nomi ai volumi.
I nomi dei volumi devono iniziare con la lettera d seguita da un numero, ad esempio, d0.
Invece di specificare il nome completo del volume, ad esempio /dev/md/dsk/d1, è spesso possibile usare un'abbreviazione, ad esempio d1.
Per semplificare l'amministrazione dei volumi, si consigliano le seguenti convenzioni di denominazione standard.
Usare determinati intervalli per ogni tipo di volume. Ad esempio, assegnare i numeri da 0 a 20 ai volumi RAID-1 e quelli da 21 a 40 ai volumi RAID-0.
Quando si utilizza Solaris Live Upgrade per la creazione dei mirror, usare una correlazione nei nomi per i mirror. È possibile far terminare con zero (0) i nomi dei mirror e far terminare con uno (1) e due (2) i nomi dei submirror. Ad esempio, il mirror d10 può comprendere i submirror d11 e d12, mentre il mirror d20 può comprendere i submirror d21 e d22.
Quando si usa il metodo di installazione JumpStart personalizzato per creare i mirror, ai submirror viene automaticamente assegnato un nome che è collegato a quello del mirror.
Usare un metodo di denominazione che assegna il numero della slice e il numero del disco al numero del volume.
Solaris Volume Manager dispone di 128 nomi di volume predefiniti nell'intervallo tra 0 e 127. L'elenco seguente mostra alcuni esempi di nomi di volumi.
Dispositivo /dev/md/dsk/d0 — volume a blocchi d0
Dispositivo /dev/md/dsk/d1 — volume a blocchi d1
Per informazioni dettagliate sui requisiti di denominazione di Solaris Volume Manager, vedere il manuale Solaris Volume Manager Administration Guide.
È consigliabile distribuire le repliche del database di stato su più slice, dischi e controller diversi, per evitare la creazione di singoli punti vulnerabili. L'obiettivo è di garantire l'integrità della maggior parte delle repliche anche dopo il guasto di un singolo componente. Se una replica viene danneggiata, ad esempio quando un dispositivo si guasta, questa condizione può provocare problemi durante l'esecuzione di Solaris Volume Manager o al riavvio del sistema. Solaris Volume Manager richiede che almeno la metà delle repliche siano disponibili per poter funzionare correttamente, ma richiede la presenza della maggioranza (metà più una) delle repliche per il riavvio in modalità multiutente.
Per informazioni dettagliate sulla creazione e l'amministrazione delle repliche del database di stato, vedere il manuale Solaris Volume Manager Administration Guide.
Prima di selezionare le slice che dovranno ospitare le repliche del database di stato, valutare le seguenti linee guida e raccomandazioni.
È consigliabile creare le repliche del database di stato su una slice dedicata di almeno 4 Mbyte per replica. Se necessario, è possibile creare le repliche del database di stato su una slice che fa parte di un volume RAID-0 o RAID-1. È necessario creare le repliche prima di aggiungere la slice al volume.
Nell'impostazione predefinita, la dimensione di una replica del database di stato è di 4 Mbyte o 8192 blocchi del disco. Poiché in genere le slice non sono così piccole, è possibile ridimensionare una slice per posizionarvi la replica del database di stato. Per informazioni sul ridimensionamento di una slice, vedere “Administering Disks (Tasks)” in System Administration Guide: Basic Administration.
È possibile creare le repliche del database di stato sulle slice non utilizzate. La parte della slice riservata alla replica del database di stato non dovrebbe mai essere utilizzata ad altro scopo.
Non è possibile creare le repliche del database di stato su file system già esistenti o sui file system radice (/), /usr e swap. Se necessario, è possibile creare una nuova slice (se è ancora disponibile un nome) allocando una parte dello spazio di swap e quindi posizionando le repliche del database sulla nuova slice.
Quando una replica del database di stato viene posizionata su una slice che entra a far parte di un volume, la capacità del volume viene ridotta di una dimensione pari allo spazio occupato dalla replica o dalle repliche. Lo spazio utilizzato da una replica è arrotondato al cilindro successivo e viene ignorato dal volume.
Prima di scegliere il numero di repliche del database di stato da creare, si tengano in considerazione le seguenti linee guida.
Si consiglia di utilizzare almeno 3 repliche del database di stato e fino a un massimo di 50 repliche per ogni set di dischi di Solaris Volume Manager. Osservare le seguenti linee guida:
Per i sistemi con una sola unità disco: posizionare tutte e tre le repliche nella stessa slice.
Per i sistemi con due/quattro unità disco: posizionare due repliche su ogni disco.
Per i sistemi con cinque o più unità disco: posizionare una replica su ogni unità disco.
La presenza di più repliche del database di stato può migliorare le prestazioni del mirror. In genere, è necessario aggiungere due repliche per ogni mirror che si aggiunge al sistema.
Se si dispone di un volume RAID-1 da utilizzare per gli I/O casuali di piccole dimensioni (ad esempio per un database), valutare il numero di repliche da utilizzare. Per ottenere le migliori prestazioni, verificare di disporre di almeno due repliche supplementari per ogni volume RAID-1 posizionate su slice (e preferibilmente anche su dischi e controller) non collegati al volume RAID-1.
Se sul sistema sono presenti più controller, le repliche dovrebbero essere distribuite nel modo più uniforme possibile tra tutti i controller. Questa strategia garantisce la ridondanza nel caso di guasto di un controller e contribuisce anche a distribuire il carico in modo omogeneo. Se su un controller sono presenti più dischi, almeno due dei dischi di ciascun controller dovrebbero contenere una replica.
Quando si utilizzano volumi RAID-1 (mirror) e RAID-0 (concatenazioni di una singola slice), tenere presenti le seguenti linee guida.
I metodi di installazione JumpStart personalizzato e Solaris Live Upgrade supportano un sottoinsieme delle funzioni disponibili in Solaris Volume Manager. Quando si creano file system in mirroring con questi programmi di installazione, tenere presenti le seguenti linee guida.
Il termine volume RAID-0 può riferirsi sia a una stripe che a una concatenazione. I metodi di installazione JumpStart personalizzato e Solaris Live Upgrade consentono solo la creazione di concatenazioni di una singola slice. Non è possibile creare volumi RAID-0 in striping durante l'installazione o l'aggiornamento.
Il metodo di installazione JumpStart personalizzato consente di creare un massimo di due submirror per ogni mirror. Il metodo di installazione Solaris Live Upgrade consente di creare un massimo di tre submirror per ogni mirror. In genere, due submirror forniscono un grado di ridondanza sufficiente per la maggior parte delle applicazioni e riducono i costi legati alle unità disco. La presenza di tre submirror consente di porre uno dei submirror non in linea e di eseguirne il backup pur mantenendo la ridondanza dei dati con gli altri due submirror.
Se si creano i file system in mirroring con il metodo di installazione JumpStart personalizzato, non è necessario creare i file system di cui eseguire il mirroring prima di creare il mirror.
Nella scelta dei dischi e dei controller da destinare al mirroring di un file system, tenere presenti le seguenti linee guida.
Usare componenti che utilizzano differenti controller per aumentare il numero di letture e scritture simultanee che è possibile effettuare.
Posizionare le slice dei submirror su dischi e controller differenti. La protezione dei dati diminuisce considerevolmente se slice di due o più submirror dello stesso mirror si trovano sullo stesso disco.
Distribuire i submirror su diversi controller, in quanto i controller e il relativo cablaggio tendono a guastarsi più spesso dei dischi. Questa pratica migliora anche le prestazioni del mirror.
Usare lo stesso tipo di dischi e controller per un singolo mirror. In particolare nel caso di dispositivi SCSI non recenti, dischi di diverse marche o modelli possono avere prestazioni notevolmente diverse. La combinazione di dischi con differenti prestazioni in un singolo mirror può produrre un considerevole degrado delle prestazioni.
Nella scelta delle slice da destinare al mirroring di un file system, tenere presenti le seguenti linee guida.
Tutti i file system, inclusi i file system radice (/), swap e /usr possono utilizzare un mirror. Qualsiasi applicazione, ad esempio un database, può utilizzare un mirror.
Verificare che le slice dei submirror abbiano le stesse dimensioni. L'uso di submirror con dimensioni differenti impedisce l'utilizzo di tutto lo spazio disponibile.
Se per uno dei file system in mirroring il primo submirror collegato non parte dal cilindro 0, tutti gli altri submirror che vengono collegati non devono partire dal cilindro 0. Se si cerca di collegare un submirror che inizia al cilindro 0 ad un mirror in cui il submirror originale non inizia al cilindro 0, viene generato il seguente messaggio di errore:
impossibile unire un submirror con etichetta a un mirror senza etichetta |
Non è necessario che tutti i submirror abbiano lo stesso cilindro iniziale, ma occorre che il cilindro 0 sia incluso in tutti i submirror o non incluso in nessun submirror.
Se un sistema su cui sono presenti mirror dei file system radice (/), /usr e swap viene avviato in modalità monoutente, il sistema indica che è necessario eseguire la manutenzione dei mirror. Quando si visualizzano i mirror con il comando metastat, i mirror sopra indicati e potenzialmente tutti i mirror del sistema mostrano lo stato di richiesta di manutenzione.
Anche se la situazione può apparire potenzialmente rischiosa, in realtà non è così. Il comando metasync -r, che viene normalmente eseguito all'avvio per risincronizzare i mirror, viene interrotto quando il sistema si avvia in modalità monoutente. Dopo il riavvio del sistema, il comando metasync -r viene eseguito e risincronizza tutti i mirror.
Se questa interruzione desta qualche preoccupazione, eseguire il comando metasync -r manualmente.
Per maggiori informazioni sul comando metasync, vedere la pagina man metasync(1M) e il manuale Solaris Volume Manager Administration Guide.