Parte II Installazioni basate su ZFS, sulle procedure di avvio, su Solaris Zones e sui volumi RAID-1

Questa parte descrive varie tecnologie legate all'installazione o all'aggiornamento di Solaris. Sono inclusi anche i requisiti e le linee guida per l'installazione.

• Installazione per il file system root (/) ZFS

• Avvio sui sistemi x86 o SPARC

• Tecnologia di partizionamento Solaris Zones

• Componenti di Solaris Volume Manager, ad esempio i volumi RAID-1

Capitolo 6 Installazione di un file system root ZFS (pianificazione)

Questo capitolo presenta i requisiti di sistema e le limitazioni relative all'installazione di un pool root ZFS. Presenta anche un'introduzione ai programmi che permettono di eseguire l'installazione su un pool root ZFS.

• Requisiti per l'installazione di un pool root ZFS

• Programmi di installazione di Solaris per l'installazione di pool root ZFS

Se sul sistema sono presenti più ambienti di boot, vedere il Capitolo 7Avvio di sistemi SPARC e x86 (panoramica e pianificazione) per informazioni sull'avvio.

Nuove funzioni di Solaris 10 10/09

A partire dalla versione Solaris 10 10/09 è possibile impostare un profilo JumpStart per identificare un archivio Flash di un pool root ZFS.

È possibile creare un archivio Flash in un sistema che utilizza un file system root UFS o ZFS. Un archivio Flash di un pool root ZFS contiene tutta la gerarchia del pool, con l'esclusione dei volumi di swap e di dump e dei set di dati eventualmente esclusi. I volumi di swap e di dump vengono creati al momento dell'installazione dell'archivio Flash.

Utilizzare il metodo di installazione degli archivi Flash indicato di seguito:

• Generare un archivio Flash che può essere utilizzato per installare e avviare un sistema che utilizza un file system root ZFS.

• Eseguire un'installazione JumpStart di un sistema utilizzando un archivio Flash ZFS.

  ---

  Nota –

  Quando si crea un archivio Flash ZFS viene eseguito il backup di un intero pool root e non di singoli ambienti di boot. È possibile escludere singoli set di dati del pool utilizzando l'opzione D dei comandi flarcreate e -flar.

  ---

Per maggiori istruzioni e informazioni sulle limitazioni, vedere la sezione Installing a ZFS Root File System (Oracle Solaris Flash Archive Installation) in Oracle Solaris ZFS Administration Guide.

Requisiti per l'installazione di un pool root ZFS

Requisiti di spazio su disco per un'installazione ZFS

In genere, in un sistema con un file system root UFS, i dispositivi swap e dump si trovano sulla stessa slice. Di conseguenza, UFS condivide lo spazio di swap con il dispositivo di dump. In un pool root ZFS, le aree di swap e dump si trovano su volumi zvols separati, in modo da non condividere lo stesso spazio fisico. Quando un sistema viene installato o aggiornato con un file system root ZFS, le dimensioni dell'area di swap e del dispositivo di dump dipendono dalla quantità di memoria fisica. Lo spazio minimo disponibile nel pool per un file system root ZFS avviabile dipende dalla memoria fisica e dallo spazio su disco disponibili, e dal numero di ambienti di boot da creare. In genere sono consigliati 1 Gbyte di memoria e almeno 2 Gbyte di spazio su disco. Lo spazio viene occupato nel modo seguente:

• Area di swap e dispositivo di dump - La dimensione predefinita dell'area di swap è pari a metà della memoria fisica, ma non è mai inferiore a 512 Mbyte o superiore a 2 Gbyte. Lo spazio del dispositivo di dump viene calcolato in base alla dimensione della memoria e al contenuto del file dumpadm.conf. Questo file definisce gli elementi che devono essere inseriti in un crash dump. È possibile regolare le dimensioni dei volumi di swap e dump prima o dopo l'installazione. Per maggiori informazioni, vedere Introducing ZFS Properties in Oracle Solaris ZFS Administration Guide.

• Ambienti di boot - In aggiunta ai requisiti di spazio per le aree di swap e dump, nuove o aggiornate, un ambiente di boot ZFS di cui è stata eseguita la migrazione da un ambiente di boot UFS richiede circa 6 Gbyte. Gli ambienti di boot ZFS clonati da altri ambienti di boot ZFS non richiedono spazio su disco aggiuntivo. Tuttavia, la dimensione dell'ambiente di boot può aumentare in seguito all'applicazione di patch. Tutti gli ambienti di boot ZFS nello stesso pool root usano gli stessi dispositivi di swap e dump.

Programmi di installazione di Solaris per l'installazione di pool root ZFS

I seguenti programmi di installazione eseguono un'installazione iniziale di un pool root ZFS.

• Programma di installazione di Solaris con interfaccia a caratteri

• Metodo JumpStart personalizzato con profilo di installazione

Solaris Live Upgrade può eseguire la migrazione da un file system UFS a un pool root ZFS. Inoltre, Solaris Live Upgrade può creare ambienti di boot ZFS aggiornabili.

Capitolo 7 Avvio di sistemi SPARC e x86 (panoramica e pianificazione)

A partire da Solaris 10 10/08, le modifiche apportate all'architettura di avvio forniscono varie nuove funzioni, inclusa la possibilità di avviare il sistema da differenti tipi di file system, ad esempio i file system ZFS. Il presente capitolo descrive alcune di queste modifiche e fornisce i riferimenti per ottenere maggiori informazioni sulla procedura di avvio. Contiene anche un'introduzione all'avvio con GRUB per i sistemi x86.

Il capitolo è suddiviso nelle seguenti sezioni:

• Avvio di Solaris (panoramica)

• x86: Avvio con GRUB (panoramica)

• x86: Avvio con GRUB (pianificazione)

Avvio di Solaris (panoramica)

A partire da Solaris 10 10/08, il processo di avvio di Solaris SPARC è stato riprogettato per migliorare la sua analogia con l'architettura di avvio dei sistemi Solaris x86. Questa migliorata architettura di avvio di Solaris consente di utilizzare funzioni come l'avvio diretto, l'avvio basato su dischi RAM e l'utilizzo di miniroot su dischi RAM sulla piattaforma SPARC. Queste tecnologie supportano le seguenti funzioni:

• Avvio del sistema da altri tipi di file system, ad esempio i file system ZFS.

• Avvio di una singola miniroot per l'installazione del software da DVD, NFS o HTTP

Altri miglioramenti includono un tempo di avvio notevolmente ridotto, una maggiore versatilità e ridotti requisiti di manutenzione.

Nell'ambito di questa riprogettazione dell'architettura, gli archivi di avvio di Solaris e il comando bootadm, disponibili in precedenza solo sulla piattaforma Solaris x86, sono ora parte integrante dell'architettura di avvio di Solaris SPARC.

Nonostante le modifiche all'implementazione dell'architettura di avvio di Solaris SPARC, nessuna procedura di amministrazione per l'avvio della piattaforma SPARC è stata modificata. La procedura di installazione di Solaris ora consente l'installazione da un file system ZFS. Non sono state apportate altre modifiche in relazione alla nuova architettura di avvio.

Avvio degli ambienti di boot ZFS (panoramica)

Se sul sistema è installato più di un sistema operativo o più di un ambiente di boot root in un pool root ZFS, è possibile avviare il sistema da questi ambienti di boot sia per le piattaforme SPARC che per quelle x86. Gli ambienti di boot avviabili includono quelli creati da Solaris Live Upgrade.

• A partire da Solaris 10 10/08 è possibile avviare un sistema SPARC da un file system root ZFS in un pool ZFS. Per i pool root ZFS, è possibile elencare gli ambienti di boot disponibili con l'opzione -L del comando boot. È quindi possibile scegliere un ambiente di boot e usare il comando boot di OBP con l'opzione -Z per avviare quell'ambiente di boot. L'opzione -Z può essere usata in alternativa al comando luactivate per avviare un nuovo ambiente di boot di un pool root ZFS. Il comando luactivate è il metodo preferito per la commutazione degli ambienti di boot. Per i file system UFS, l'interfaccia di amministrazione principale per la selezione dei comandi di boot è sempre costituita dei comandi della PROM di OpenBoot.

• A partire da Solaris 10 1/06 per i sistemi x86, il menu di avvio di GRUB consente di avviare diversi ambienti di boot. A partire da Solaris 10 10/08, questo menu elenca gli ambienti di boot ZFS che è possibile avviare. Se l'ambiente di boot predefinito è un file system ZFS e viene visualizzato il menu di GRUB, è possibile avviare l'ambiente predefinito o scegliere un diverso ambiente di boot. Il menu di GRUB può essere usato in alternativa al comando luactivate per avviare un nuovo ambiente di boot per un pool root ZFS. Il comando luactivate è il metodo preferito per la commutazione degli ambienti di boot.

Nei sistemi SPARC e x86, ogni pool root ZFS dispone di un set di dati designato come file system root predefinito. Se in un sistema SPARC si digita il comando boot oppure in un sistema x86 si sceglie il valore predefinito dal menu di GRUB, viene avviato questo file system root predefinito.

x86: Avvio con GRUB (panoramica)

Nel sistema operativo Solaris è stato adottato come boot loader predefinito il boot loader open source GRUB.

Il boot loader è il primo programma che viene eseguito dopo l'accensione di un sistema. Quando si accende un sistema x86, il BIOS (Basic Input/Output System) inizializza la CPU, la memoria e i componenti hardware della piattaforma. Al termine della fase di inizializzazione, il BIOS carica il boot loader dal dispositivo di avvio configurato e trasferisce il controllo del sistema al boot loader.

GRUB è un boot loader open source dotato di una semplice interfaccia a menu, che include le opzioni di avvio predefinite in un file di configurazione. GRUB dispone inoltre di un'interfaccia dalla riga di comando, accessibile dall'interfaccia a menu, da cui è possibile eseguire diversi comandi di avvio. L'implementazione di GRUB del sistema operativo Solaris è conforme alla specifica Multiboot. La specifica è descritta in dettaglio in http://www.gnu.org/software/grub/grub.html.

Poiché il kernel di Solaris è pienamente compatibile con la specifica Multiboot, è possibile avviare i sistemi x86 basati su Solaris utilizzando il boot loader GRUB. GRUB offre la possibilità di avviare e installare facilmente diversi sistemi operativi.

Un vantaggio fondamentale di GRUB è la sua capacità di riconoscere i file system e i formati eseguibili del kernel; questo consente di caricare un sistema operativo senza registrare la posizione fisica del kernel sul disco. Nell'avvio del sistema con GRUB, il kernel viene caricato specificando il nome del file corrispondente, l'unità e la partizione in cui risiede. L'avvio con GRUB sostituisce il Solaris Device Configuration Assistant e semplifica il processo grazie all'interfaccia a menu.

x86: Avvio con GRUB (pianificazione)

Questa sezione descrive le operazioni di base del processo di avvio con GRUB e i componenti del menu di GRUB.

Quando si installa il sistema operativo Solaris, sul sistema vengono installate automaticamente due voci del menu di GRUB. La prima è quella relativa al sistema operativo Solaris. La seconda riguarda l'archivio di avvio di emergenza, da utilizzare per il ripristino del sistema. Le voci del menu di GRUB relative a Solaris vengono installate e aggiornate automaticamente nell'ambito del processo di installazione e aggiornamento di Solaris. Queste voci vengono gestite direttamente dal sistema operativo e non devono essere modificate manualmente.

Durante l'installazione standard di Solaris, GRUB viene installato nella partizione fdisk di Solaris senza modificare le impostazioni del BIOS di sistema. Se il sistema operativo non si trova sul disco di avvio del BIOS, usare una delle procedure seguenti:

• Modificare le impostazioni del BIOS.

• Utilizzare un boot manager per avviare la partizione di Solaris. Per maggiori informazioni, vedere le istruzioni del proprio boot manager.

Il metodo consigliato è quello di installare Solaris sul disco di avvio. Se sul sistema sono installati più sistemi operativi, è possibile aggiungere le voci corrispondenti al file menu.lst. Queste voci verranno visualizzate nel menu di GRUB all'avvio successivo del sistema.

Per maggiori informazioni sull'uso di più sistemi operativi, vedere How Multiple Operating Systems Are Supported by GRUB in System Administration Guide: Basic Administration.

x86: Esecuzione di un'installazione con GRUB dalla rete

Per avviare un sistema dalla rete con GRUB sono richiesti un server DHCP configurato per i client PXE e un server di installazione che fornisca il servizio tftp. Il server DHCP deve essere in grado di rispondere alle classi DHCP PXEClient e GRUBClient. La risposta DHCP deve contenere le seguenti informazioni:

• Indirizzo IP del file server

• Nome del file di avvio (pxegrub)

rpc.bootparamd, generalmente richiesto dal server per i processi di avvio in rete, non è richiesto per l'avvio in rete con GRUB.

Se non sono disponibili server PXE o DHCP, è possibile caricare GRUB da un CD-ROM o da un disco locale. A questo punto si potrà configurare manualmente la rete in GRUB e scaricare il programma multiboot e l'archivio di avvio dal file server.

Per maggiori informazioni, vedere Introduzione all’avvio e all’installazione in rete con PXE in Guida all’installazione di Oracle Solaris 10 9/10: installazioni di rete.

Capitolo 8 Aggiornamento in presenza di zone di Solaris (pianificazione)

Questo capitolo contiene una descrizione generale del modo in cui la tecnologia di partizionamento Solaris Zones ha effetto sulle procedure di aggiornamento di Solaris quando sono presenti zone non globali.

Il capitolo è suddiviso nelle seguenti sezioni:

• Solaris Zones (panoramica)

• Aggiornamento in presenza di zone non globali

• Requisiti di spazio per le zone non globali

Solaris Zones (panoramica)

La tecnologia Solaris Zones è una tecnologia di partizionamento del software usata per virtualizzare i servizi del sistema operativo e per creare un ambiente isolato e sicuro per l'esecuzione delle applicazioni. Una zona è un ambiente di sistema operativo virtualizzato creato all'interno di una singola istanza del sistema operativo Solaris. Quando si crea una zona non globale, si produce un ambiente di esecuzione delle applicazioni in cui i processi sono isolati dal resto del sistema. L'isolamento impedisce ai processi eseguiti in una data zona non globale di monitorare o di produrre effetti sui processi eseguiti in tutte le altre zone non globali. Anche i processi dotati di credenziali di superutente non possono visualizzare o in alcun modo modificare l'attività delle altre zone. La zona non globale fornisce anche un livello astratto che separa le applicazioni dagli attributi fisici del sistema su cui sono implementate. Un esempio di questi attributi sono i percorsi dei dispositivi fisici.

Ogni sistema Solaris contiene una zona globale. Questa zona ha una duplice funzione. La zona globale è la zona predefinita del sistema e viene utilizzata per i controlli di amministrazione che coinvolgono l'intero sistema. Se l'amministratore globale non ha creato nessuna zona non globale, tutti i processi vengono eseguiti nella zona globale. La zona globale è l'unica zona dalla quale è possibile configurare, installare, gestire e deconfigurare una zona non globale. Solo la zona globale può essere avviata dall'hardware del sistema. L'amministrazione dell'infrastruttura del sistema, ad esempio dei dispositivi fisici, del routing o della riconfigurazione dinamica (DR), può essere eseguita solo nella zona globale. I processi eseguiti nella zona globale che dispongono di privilegi appropriati possono accedere a oggetti associati alle zone non globali.

Aggiornamento in presenza di zone non globali

Una volta eseguita l'installazione di Solaris, è possibile installare e configurare le zone non globali. L'aggiornamento di Solaris è possibile anche quando sono installate zone non globali. Se sono presenti zone non globali non native (branded), durante la procedura di aggiornamento queste vengono ignorate. Di seguito è fornita una breve descrizione dei programmi di installazione per i sistemi in cui sono presenti zone non globali.

A partire dalla versione Solaris 10 10/09 la funzione di applicazione parallela delle patch alle zone consente di migliorare le prestazioni delle utilità di patch standard di Solaris 10. Questa funzione migliora l'applicazione delle patch alle zone in quanto applica le patch in parallelo alle zone non globali.

Le patch vengono ancora applicate alla zona globale prima dell'applicazione delle patch alle zone non globali.

Per le versioni precedenti alla Solaris 10 10/09, questa funzione viene resa disponibile nelle seguenti patch delle utilità di patch:

• SPARC: patch 119254-66 o revisione successiva

• x86: patch 119255-66 o revisione successiva

Per maggiori informazioni, vedere la seguente documentazione:

• Solaris 10 10/09: Zones Parallel Patching to Reduce Patching Time in System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones

• Solaris 10 10/09: How to Patch Non-Global Zones in Parallel in System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones

Nella tabella seguente sono elencate le limitazioni applicate quando si esegue l'aggiornamento in presenza di zone non globali.

Backup del sistema prima dell'aggiornamento in presenza di zone

Prime di eseguire l'aggiornamento è necessario effettuare un backup della zona globale e delle zone non globali presenti sul sistema. Per eseguire il backup del sistema in presenza di zone, vedere il Capitolo 27, Solaris Zones Administration (Overview) in System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones.

Requisiti di spazio per le zone non globali

Durante l'installazione della zona globale, riservare una quantità di spazio su disco sufficiente a contenere tutte le zone che si desidera creare. Ogni zona non globale può avere requisiti di spazio differenti.

Non esistono limiti per quanto riguarda la quantità di spazio su disco che può essere occupata da una zona. Eventuali limitazioni sono a discrezione dell'amministratore della zona globale. Anche un piccolo sistema monoprocessore può supportare più zone attive simultaneamente. Le caratteristiche dei pacchetti installati nella zona globale influisce sui requisiti di spazio delle zone non globali. Il numero dei pacchetti e i requisiti di spazio sono fattori rilevanti per l'allocazione dello spazio.

Per informazioni complete sui requisiti di pianificazione e sulle configurazioni consigliate, vedere il Capitolo 18, Planning and Configuring Non-Global Zones (Tasks) in System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones.

Capitolo 9 Creazione di volumi RAID-1 (mirror) durante l'installazione (panoramica)

Questo capitolo prende in esame i vantaggi della creazione di volumi RAID-1 (mirror) per il file system root (/). Il capitolo descrive anche i componenti di Solaris Volume Manager richiesti per la creazione di file system in mirroring. Gli argomenti trattati sono i seguenti.

• Vantaggi dei volumi RAID-1

• Funzionamento dei volumi RAID-1

• Panoramica dei componenti di Solaris Volume Manager

• Esempio di configurazione dei dischi in un volume RAID-1

Per altre informazioni specifiche su Solaris Live Upgrade o JumpStart, vedere i seguenti testi di riferimento:

• Per Solaris Live Upgrade: Indicazioni generali per la creazione di file system in volumi RAID-1 (mirror) in Guida all’installazione di Oracle Solaris 10 9/10: Solaris Live Upgrade e pianificazione degli aggiornamenti

• Per JumpStart:

  • Parola chiave filesys (creazione di volumi RAID-1) in Guida all’installazione di Oracle Solaris 10 9/10: metodo JumpStart personalizzato e installazioni avanzate.

  • Parola chiave metadb (creazione di repliche del database di stato) in Guida all’installazione di Oracle Solaris 10 9/10: metodo JumpStart personalizzato e installazioni avanzate.

Vantaggi dei volumi RAID-1

Durante l'installazione o l'aggiornamento è possibile creare volumi RAID-1 per duplicare i dati del sistema su più dischi fisici. Duplicando i dati su dischi diversi è possibile proteggerli dal danneggiamento o da un guasto del disco.

I metodi di installazione JumpStart personalizzato e Solaris Live Upgrade utilizzano la tecnologia di Solaris Volume Manager per creare volumi RAID-1 che duplichino i file system. Solaris Volume Manager offre un metodo estremamente efficiente per gestire i dischi e i dati con l'uso dei volumi. Solaris Volume Manager permette di gestire le concatenazioni, le stripe e altre configurazioni complesse. I metodi di installazione JumpStart personalizzato e Solaris Live Upgrade consentono di eseguire un sottoinsieme di queste attività, ad esempio la creazione di un volume RAID-1 per il file system root (/). È possibile creare i volumi RAID-1 durante l'installazione o l'aggiornamento, eliminando la necessità di crearli al termine dell'installazione.

• Per indicazioni, vedere Linee guida per JumpStart personalizzato e Solaris Live Upgrade.

• Per informazioni dettagliate sul software e sui componenti complessi di Solaris Volume Manager, vedere il manuale Solaris Volume Manager Administration Guide.

Funzionamento dei volumi RAID-1

Solaris Volume Manager usa i dischi virtuali per gestire i dischi fisici e i dati che contengono. In Solaris Volume Manager, un disco virtuale viene denominato volume. Il volume comprende un gruppo di slice fisiche che appaiono al sistema come un singolo dispositivo logico. I volumi sono in realtà pseudodispositivi (o dispositivi virtuali) secondo la terminologia standard di UNIX.

Un volume è funzionalmente identico a un disco fisico dal punto di vista di un'applicazione e del file system (ad esempio UFS). Solaris Volume Manager converte le richieste di I/O dirette al volume in richieste di I/O ai dischi che lo compongono. I volumi di Solaris Volume Manager sono realizzati a partire dalle slice (partizioni del disco) o utilizzando altri volumi di Solaris Volume Manager.

I volumi possono essere utilizzati per migliorare le prestazioni e la disponibilità dei dati. In alcuni casi, possono anche migliorare le prestazioni di I/O. Dal punto di vista funzionale, i volumi si comportano allo stesso modo delle slice. Grazie a questa analogia, i volumi sono trasparenti per gli utenti, le applicazioni e i file system. Come accade con i dispositivi fisici, è possibile usare Solaris Volume Manager per accedere ai volumi con i nomi di dispositivo a blocchi o raw. Il nome del volume è diverso a seconda che si utilizzi il dispositivo a blocchi o quello raw. I metodi di installazione JumpStart personalizzato e Solaris Live Upgrade supportano l'uso di dispositivi a blocchi per creare file system in mirroring. Per maggiori informazioni sui nomi dei volumi, vedere Requisiti dei nomi dei volumi RAID e linee guida per i metodi JumpStart personalizzato e Solaris Live Upgrade.

Quando si creano volumi RAID-1 con volumi RAID-0 (concatenazioni di una singola slice), Solaris Volume Manager duplica i dati sui submirror RAID-0 e tratta i submirror come un singolo volume.

Nella Figura 9–1 è illustrato un mirror che duplica il file system root (/) su due dischi fisici.

Figura 9–1 Creazione di volumi RAID-1 nei file system root (/) di due dischi

La Figura 9–1 mostra un sistema con la seguente configurazione.

• Il mirror denominato d30 consiste dei due submirror d31 e d32. Il mirror (d30), duplica i dati del file system root (/) su entrambi i submirror.

• Il file system root (/) su hdisk0 è incluso nella concatenazione di una singola slice denominata d31.

• Il file system root (/) viene copiato sul disco rigido denominato hdisk1. Questa copia è la concatenazione di una singola slice denominata d32.

Panoramica dei componenti di Solaris Volume Manager

I metodi di installazione JumpStart personalizzato e Solaris Live Upgrade consentono di creare i seguenti componenti necessari per replicare i dati.

• Database di stato e repliche del database di stato (metadb)

• Volumi RAID-1 (mirror) con concatenazioni di una singola slice (submirror)

Questa sezione descrive brevemente ognuno di questi componenti. Per informazioni complete sui componenti qui descritti, vedere il manuale Solaris Volume Manager Administration Guide.

Database di stato e repliche del database di stato

Il database di stato è un database che memorizza informazioni su un disco fisico. Il database di stato registra e tiene traccia delle modifiche apportate alla configurazione. Solaris Volume Manager aggiorna automaticamente il database di stato quando si verifica una modifica alla configurazione o allo stato. La creazione di un nuovo volume è un esempio di modifica alla configurazione. Il guasto di un submirror è un esempio di modifica dello stato.

Il database di stato è in realtà una raccolta di più copie replicate del database. Ogni copia, detta replica del database di stato, garantisce che i dati del database siano sempre validi. La possibilità di disporre di più copie del database di stato garantisce dal rischio di perdita dei dati legata alla presenza di un singolo punto vulnerabile. Il database di stato tiene traccia della posizione e dello stato di tutte le repliche note.

Solaris Volume Manager non può operare fino a quando non sono stati creati il database di stato e le relative repliche. Una configurazione di Solaris Volume Manager deve disporre di un database di stato operativo.

Le repliche del database di stato garantiscono la validità dei dati del database. Quando il database di stato viene aggiornato, vengono aggiornate anche le repliche del database. Gli aggiornamenti vengono effettuati uno per volta per evitare un danneggiamento di tutti gli aggiornamenti nel caso di un'interruzione del sistema.

Se sul sistema si danneggia una replica del database di stato, Solaris Volume Manager deve identificare quali repliche del database contengono ancora dati validi. Solaris Volume Manager ottiene questa informazione applicando un algoritmo di consenso a maggioranza. Questo algoritmo richiede che la maggioranza (metà + 1) delle repliche del database di stato siano disponibili e coerenti tra loro prima che una qualsiasi di loro possa essere considerata valida. A causa di questo algoritmo, è necessario creare almeno tre repliche del database di stato quando si imposta la configurazione del disco. Il consenso viene raggiunto quando almeno due delle tre repliche sono disponibili.

Nell'impostazione predefinita, ogni replica del database di stato occupa 4 Mbyte (8192 settori del disco). Le repliche possono essere memorizzate sui seguenti dispositivi:

• Una slice dedicata del disco locale

• Solo per Solaris Live Upgrade:

  • Una slice locale che entrerà a far parte di un volume

  • Una slice locale che entrerà a far parte di un dispositivo di logging UFS

Le repliche non possono essere memorizzate nelle slice root (/), swap o /usr, o sulle slice che contengono dati o ospitano un file system. Una volta memorizzate le repliche, è possibile posizionare i volumi o i file system sulla stessa slice.

È possibile conservare più di una copia del database di stato su una singola slice. Tuttavia, in questo modo il sistema è più esposto ai guasti legati alla presenza di un singolo punto vulnerabile.

Volumi RAID-1 (mirror)

Un volume RAID-1, o mirror, conserva una o più copie identiche dei dati contenuti nei volumi RAID-0 (concatenazioni di una singola slice). Una volta configurato un volume RAID-1, questo può essere utilizzato come una normale slice fisica. È possibile duplicare qualsiasi file system, anche già esistente. È anche possibile usare un volume RAID-1 per un'applicazione, ad esempio un database.

L'uso di volumi RAID-1 per il mirroring dei file system comporta vantaggi e svantaggi.

• Con i volumi RAID-1, i dati possono essere letti da entrambi i volumi RAID-0 simultaneamente (uno qualsiasi dei volumi può servire ogni richiesta) migliorando in questo modo le prestazioni. Se uno dei dischi fisici si guasta, è possibile continuare regolarmente utilizzando il mirror senza un calo di prestazioni o la perdita di dati.

• L'utilizzo di volumi RAID-1 richiede un investimento a livello di dischi. È infatti necessario disporre di uno spazio su disco almeno doppio rispetto a quello occupato dai dati.

• Poiché Solaris Volume Manager deve scrivere i dati in tutti i volumi RAID-0, la duplicazione dei dati può aumentare il tempo necessario per completare le richieste di scrittura.

Volumi RAID-0 (concatenazioni)

Un volume RAID-0 è una concatenazione di una singola slice. La concatenazione è un volume i cui dati vengono organizzati e posizionati in modo seriale e adiacente sui vari componenti, in modo da creare una singola unità di memorizzazione logica. I metodi di installazione JumpStart personalizzato e Solaris Live Upgrade non consentono la creazione di stripe o di altri volumi complessi consentiti da Solaris Volume Manager.

Durante l'installazione o l'aggiornamento, è possibile creare volumi RAID-1 (mirror) e collegare i volumi RAID-0 a questi mirror. I volumi RAID-0 che vengono posti in mirroring sono denominati submirror. Ogni mirror è composto da uno o più volumi RAID-0. Dopo l'installazione, è possibile gestire i dati residenti sui singoli submirror RAID-0 amministrando il volume mirror RAID-1 con il software Solaris Volume Manager.

Il metodo di installazione JumpStart personalizzato consente di creare un mirror composto da un massimo di due submirror. Solaris Live Upgrade consente invece di creare un mirror composto da un massimo di tre submirror. Nel normale utilizzo, i mirror a due vie (con due submirror) sono in genere sufficienti. Il terzo submirror consente l'effettuazione dei backup in linea senza mai rinunciare alla ridondanza dei dati anche quando uno dei submirror non è in linea per eseguire il backup.

Esempio di configurazione dei dischi in un volume RAID-1

Nella figura seguente è illustrato un volume RAID-1 che duplica il file system root (/) su due dischi fisici. Le repliche del database di stato (metadb) vengono posizionate su entrambi i dischi.

Figura 9–2 Configurazione dei dischi in un volume RAID-1

La Figura 9–2 mostra un sistema con la seguente configurazione.

• Il mirror denominato d30 consiste dei due submirror d31 e d32. Il mirror (d30), duplica i dati del file system root (/) su entrambi i submirror.

• Il file system root (/) su hdisk0 è incluso nella concatenazione di una singola slice denominata d31.

• Il file system root (/) viene copiato nel disco rigido denominato hdisk1. Questa copia è la concatenazione di una singola slice denominata d32.

• Le repliche del database di stato vengono create su entrambe le slice: hdisk0 e hdisk1.

Capitolo 10 Creazione di volumi RAID-1 (mirror) durante l'installazione (pianificazione)

Questo capitolo descrive i requisiti e le linee guida necessarie per la creazione di volumi RAID-1 con i metodi di installazione JumpStart personalizzato e Solaris Live Upgrade.

Gli argomenti trattati sono i seguenti.

• Requisiti di sistema

• Linee guida e requisiti delle repliche del database di stato

• Requisiti e linee guida per volumi RAID-1 e RAID-0

• Nell'avvio in modalità monoutente, un messaggio indica che il mirror richiede manutenzione

Per altre informazioni specifiche su Solaris Live Upgrade o JumpStart, vedere i seguenti testi di riferimento:

• Per Solaris Live Upgrade: Indicazioni generali per la creazione di file system in volumi RAID-1 (mirror) in Guida all’installazione di Oracle Solaris 10 9/10: Solaris Live Upgrade e pianificazione degli aggiornamenti

• Per JumpStart:

  • Parola chiave filesys (creazione di volumi RAID-1) in Guida all’installazione di Oracle Solaris 10 9/10: metodo JumpStart personalizzato e installazioni avanzate.

  • Parola chiave metadb (creazione di repliche del database di stato) in Guida all’installazione di Oracle Solaris 10 9/10: metodo JumpStart personalizzato e installazioni avanzate.

Requisiti di sistema

Per creare volumi RAID-1 con cui duplicare i dati di slice specifiche, i dischi da utilizzare devono essere collegati direttamente al sistema ed essere disponibili al momento dell'installazione.

Linee guida e requisiti delle repliche del database di stato

È 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 reboot 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 reboot 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.

Scelta delle slice per le repliche del database di stato

Prima di selezionare le slice che dovranno ospitare le repliche del database di stato, valutare le seguenti linee guida e raccomandazioni.

Scelta del numero di repliche del database di stato

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 su una singola 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.

Distribuzione delle repliche del database di stato tra i controller

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.

Requisiti e linee guida per volumi RAID-1 e RAID-0

Quando si utilizzano volumi RAID-1 (mirror) e RAID-0 (concatenazioni di una singola slice), tenere presenti le seguenti linee guida.

Linee guida per JumpStart personalizzato e Solaris Live Upgrade

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.

Requisiti dei nomi dei volumi RAID e linee guida per i metodi JumpStart personalizzato e Solaris Live Upgrade

Osservare le seguenti regole per l'assegnazione dei nomi ai volumi.

• Usare un metodo di denominazione che assegna il numero della slice e il numero del disco al numero del volume.

• I nomi dei volumi devono iniziare con la lettera d seguita da un numero, ad esempio, d0.

• Solaris Volume Manager dispone di 128 nomi di volumi predefiniti, compresi tra 0 e 127. L'elenco seguente mostra alcuni esempi di nomi dei volumi.

  • Dispositivo /dev/md/dsk/d0 – volume a blocchi d0

  • Dispositivo /dev/md/dsk/d1 – volume a blocchi d1

• 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.

Convenzioni di denominazione dei volumi RAID per Solaris Live Upgrade

Quando si utilizza la procedura Solaris Live Upgrade per creare i volumi RAID-1 (mirror) e RAID-0 (submirror), è possibile lasciare che il software rilevi ed assegni i nomi dei volumi oppure assegnarli direttamente. Se la rilevazione viene eseguita dal software, viene assegnato il primo nome di mirror o submirror disponibile. Se si assegnano i nomi ai mirror direttamente, assegnare nomi terminanti in zero in modo che l'installazione possa usare i nomi terminanti in 1 e 2 per i submirror. Se si assegnano i nomi ai submirror direttamente, utilizzare nomi che terminano con 1 o 2. Se i nomi vengono assegnati in modo errato, il mirror non può essere creato. Ad esempio, se si specifica il nome di un mirror terminante in 1 o 2 (d1 o d2), Solaris Live Upgrade non è in grado di creare il mirror se il suo nome è uguale al nome di uno dei submirror.

Nelle versioni precedenti, era possibile immettere un nome di volume abbreviato. A partire da Solaris 10 10/08, è possibile immettere solo il nome completo del volume. Ad esempio, è possibile utilizzare solo il nome del volume completo, /dev/md/dsk/d10, per specificare un mirror.

Esempio 10–1 Solaris Live Upgrade: consentire al software di rilevare e assegnare il nome al mirror e al submirror

Nell'esempio seguente, Solaris Live Upgrade assegna i nomi dei volumi. I volumi RAID-1 d0 e d1 sono i soli volumi in uso. Per il mirror d10, Solaris Live Upgrade sceglie d2 per il submirror del dispositivo c0t0d0s0 e d3 per il submirror del dispositivo c1t0d0s0.

lucreate -n newbe -m /:/dev/md/dsk/d10:mirror,ufs  \
-m /:/dev/dsk/c0t0d0s0:attach -m /:/dev/dsk/c1t0d0s0:attach

Esempio 10–2 Solaris Live Upgrade: assegnare i nomi di mirror e submirror

In questo esempio, i nomi dei volumi vengono assegnati direttamente con il comando. Per il mirror d10, d11 è il nome del submirror del dispositivo c0t0d0s0 e d12 è il nome del submirror del dispositivo c1t0d0s0.

lucreate -n newbe -m /:/dev/md/dsk/d10:mirror,ufs \
-m /:/dev/dsk/c0t0d0s0,/dev/md/dsk/d11:attach \
-m /:/dev/dsk/c1t0d0s0,/dev/md/dsk/d12:attach

Per informazioni dettagliate sui requisiti di denominazione di Solaris Volume Manager, vedere il manuale Solaris Volume Manager Administration Guide.

Convenzioni di denominazione dei volumi RAID per il metodo JumpStart personalizzato

Quando si utilizza il metodo JumpStart personalizzato per creare i volumi RAID-1 (mirror) e RAID-0 (submirror), è possibile lasciare che il software rilevi ed assegni i nomi dei volumi oppure assegnarli direttamente nel profilo.

• Se la rilevazione viene eseguita dal software, viene assegnato il primo numero di volume disponibile.

• Se si assegnano i nomi nel profilo, assegnare nomi terminanti in zero in modo che l'installazione possa usare i nomi terminanti in 1 e 2 per i submirror.

  ---

  Nota –

  Se i nomi vengono assegnati in modo errato, il mirror non può essere creato. Ad esempio, se si specifica il nome di un mirror terminante in 1 o 2 (d1 o d2), JumpStart non è in grado di creare il mirror se il suo nome è uguale al nome di uno dei submirror.

  ---

È possibile abbreviare i nomi delle slice dei dischi fisici e dei volumi Solaris Volume Manager. L'abbreviazione è il nome più corto che può identificare un dispositivo in modo univoco. Qui di seguito sono riportati alcuni esempi.

• Un volume di Solaris Volume Manager può essere identificato con la designazione dnum; ad esempio, il volume /dev/md/dsk/d10 può essere denominato semplicemente d10.

• Se un sistema dispone di un solo controller e di più dischi, è possibile usare la designazione t0d0s0, mentre se i controller sono più di uno occorre usare la forma c0t0d0s0.

Esempio 10–3 Consentire al software di rilevare e assegnare il nome al mirror e al submirror

Nell'esempio di profilo seguente, al mirror vengono assegnati i primi numeri di volume disponibili. Se il successivo mirror disponibile terminante in zero è d10 al submirror vengono assegnati i nomi d11 e d12.

filesys                 mirror c0t0d0s1  / 

Esempio 10–4 Assegnazione dei nomi a mirror e submirror

Nel seguente esempio di profilo, il numero del mirror (d30) viene assegnato dal profilo. I nomi dei submirror vengono assegnati dal software, in base al numero del mirror e a quello del primo submirror disponibile. I submirror sono denominati d31 e d32.

filesys                 mirror:d30 c0t1d0s0 c0t0d0s0  /

Per informazioni dettagliate sui requisiti di denominazione di Solaris Volume Manager, vedere il manuale Solaris Volume Manager Administration Guide.

Linee guida per la scelta di dischi e controller

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.

Linee guida per la scelta delle slice

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 root (/), 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 si dispone di un file system in mirroring in cui il primo submirror collegato non inizia al cilindro 0, anche 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:

  can't attach labeled submirror to an unlabeled mirror

  Verificare che tutti i submirror che si prevede di collegare a un mirror partano dal cilindro 0 (o che nessuno di essi parta dal cilindro 0).

  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.

Nell'avvio in modalità monoutente, un messaggio indica che il mirror richiede manutenzione

Se un sistema in cui sono presenti mirror dei file system root (/), /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 reboot 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 su metasync, vedere la pagina man metasync(1M) e il manuale Solaris Volume Manager Administration Guide.