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 radice (/) ZFS
Avvio sui sistemi x86 o SPARC
Tecnologia di partizionamento Solaris Zones
Componenti di Solaris Volume Manager, ad esempio i volumi RAID-1
Questo capitolo presenta i requisiti di sistema e le limitazioni relative all'installazione di un pool radice ZFS. Presenta anche un'introduzione ai programmi che permettono di eseguire l'installazione su un pool radice 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.
Requisito o limitazione |
Descrizione |
Informazione |
---|---|---|
La memoria minima richiesta è di 786 MB. La memoria consigliata per ottenere buone prestazioni globali è di 1 GB. | ||
Spazio su disco |
Lo spazio minimo disponibile nel pool per un file system radice ZFS avviabile dipende dalla memoria fisica e dallo spazio su disco disponibili, e dal numero di ambienti di boot da creare. |
Per maggiori informazioni, vedere Requisiti di spazio su disco per un'installazione ZFS. |
Il pool di memorizzazione ZFS deve essere creato da una o più slice anziché da interi dischi per poter essere aggiornabile e avviabile. |
|
|
Quando si esegue la migrazione da un file system radice (/) UFS a un pool radice ZFS con Solaris Live Upgrade, tenere in considerazione questi requisiti. |
|
|
In genere, su un sistema con un file system radice 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 radice 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 radice 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 radice 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 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 radice usano gli stessi dispositivi di swap e dump.
I seguenti programmi di installazione eseguono un'installazione iniziale di un pool radice 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 radice ZFS. Inoltre, Solaris Live Upgrade può creare ambienti di boot ZFS aggiornabili.
Tabella 6–2 Programmi di installazione per ZFS e relative limitazioni
Programma di installazione per ZFS |
Descrizione |
Limitazioni |
Informazione |
---|---|---|---|
Programma di installazione di Solaris con interfaccia a caratteri |
Il programma di installazione con interfaccia a caratteri di Solaris esegue un'installazione iniziale per un pool radice ZFS. Durante l'installazione è possibile selezionare come destinazione un file system UFS o un pool radice ZFS. È possibile configurare un pool radice ZFS in mirroring selezionando due o più slice durante l'installazione. Oppure, è possibile collegare o aggiungere altri dischi dopo l'installazione per creare un pool radice ZFS in mirroring. I dispositivi di swap e dump sui volumi ZFS vengono creati automaticamente nel pool radice ZFS. |
| |
Solaris Live Upgrade |
È possibile utilizzare Solaris Live Upgrade per svolgere le seguenti attività:
Dopo aver utilizzato il comando lucreate per creare un ambiente di boot ZFS, è possibile usare i comandi di Solaris Live Upgrade nell'ambiente di boot. |
| |
JumpStart |
È possibile creare un profilo per generare un pool di memorizzazione ZFS e designare un file system ZFS avviabile. Alcune nuove parole chiave di ZFS consentono di eseguire un'installazione iniziale. |
|
|
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:
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.
Se sul sistema è installato più di un sistema operativo o più di un ambiente di boot radice in un pool radice 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 radice ZFS in un pool ZFS. Per i pool radice 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 radice 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 OpenBootTM.
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 radice ZFS. Il comando luactivate è il metodo preferito per la commutazione degli ambienti di boot.
Sui sistemi SPARC e x86, ogni pool radice ZFS dispone di un set di dati designato come file system radice predefinito. Se su un sistema SPARC si digita il comando boot oppure su un sistema x86 si sceglie la voce predefinita dal menu di GRUB, viene avviato questo file system radice predefinito.
Tabella 7–1 Guida alle informazioni sull'avvio
Descrizione |
Informazione |
---|---|
Per un'introduzione generale alle funzioni di avvio | |
Per una descrizione più dettagliata delle funzioni di avvio | |
x86: per informazioni sulla modifica del comportamento di avvio, ad esempio per l'individuazione o la modifica del file menu.lst. | |
Per le procedure per l'avvio di un file system ZFS |
Capitolo 12, Booting a Solaris System (Tasks) in System Administration Guide: Basic Administration |
Per le procedure per la gestione di un archivio di avvio, ad esempio per l'individuazione del file menu.lst di GRUB e l'utilizzo del comando bootadm |
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.
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.
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 Solaris 10 5/09: installazioni di rete .
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:
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.
Descrizione |
Per maggiori informazioni |
---|---|
Le sezioni seguenti descrivono l'aggiornamento di un sistema che contiene zone non globali. | |
Per informazioni complete sulla creazione e la configurazione delle 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.
Tabella 8–1 Scelta di un programma di installazione per l'aggiornamento in presenza di zone non globali
Programma di aggiornamento |
Descrizione |
Per maggiori informazioni |
---|---|---|
Solaris Live Upgrade |
È possibile aggiornare o applicare patch a un sistema che contiene zone non globali. Se il sistema in uso contiene zone non globali, il programma consigliato per l'aggiornamento o l'applicazione delle patch è Solaris Live Upgrade. Altri programmi di aggiornamento possono richiedere molto tempo per completare l'operazione, in quanto il tempo richiesto per completare l'aggiornamento aumenta proporzionalmente al numero di zone non globali installate. Se si sta applicando una patch usando Solaris Live Upgrade, non è necessario passare alla modalità monoutente e questo aumenta il tempo di attività del sistema. A partire da Solaris 10 8/07, le modifiche richieste per i sistemi in cui sono presenti zone non globali sono le seguenti:
|
|
Solaris Live Upgrade (continuazione) |
Nota – Per impostazione predefinita, tutti i file system ad eccezione di quelli critici (root (/), /usr e /opt) sono condivisi dal vecchio e dal nuovo ambiente di boot. Di conseguenza, l'aggiornamento dei file condivisi nell'ambiente di boot attivo si riflette anche sui dati dell'ambiente di boot inattivo. Il file system /export è un esempio di file system condiviso. Se si utilizza l'opzione -m nome_zona, il file system condiviso della zona non globale viene copiato su una slice separata e i suoi dati non vengono condivisi. Questa opzione impedisce la condivisione tra gli ambiente di boot dei file system della zona non globale che erano stati creati con il comando zonecfg add fs. A partire da Solaris 10 8/07, le modifiche aggiuntive per i sistemi in cui sono presenti zone non globali sono le seguenti:
| |
Interfaccia utente grafica (GUI) interattiva del programma di installazione di Solaris |
È possibile aggiornare un sistema che contiene zone non globali o applicarvi patch. L'aggiornamento o l'applicazione delle patch può richiedere molto tempo, in base al numero di zone non globali installate. |
Per maggiori informazioni sull'installazione con questo programma, vedere il Capitolo 2, Installazione con il programma di installazione di Solaris per i file system UFS (procedure) in Guida all’installazione di Solaris 10 5/09: installazioni di base. |
Installazione automatizzata di JumpStart |
È possibile eseguire aggiornamenti o applicare patch usando le parole chiave appropriate per queste procedure. L'aggiornamento o l'applicazione delle patch può richiedere molto tempo, in base al numero di zone non globali installate. |
Per maggiori informazioni sull'installazione con l'utilizzo di questo programma, vedere la Guida all’installazione di Solaris 10 5/09: metodo JumpStart personalizzato e installazioni avanzate . |
Nella tabella seguente sono elencate le limitazioni applicate quando si esegue l'aggiornamento in presenza di zone non globali.
Tabella 8–2 Limitazioni all'aggiornamento in presenza di zone non globali
Programma o condizione |
Descrizione |
Per maggiori informazioni |
---|---|---|
Tenere presenti queste osservazioni quando si utilizza Solaris Live Upgrade in un sistema su cui sono presenti zone non globali. È di importanza fondamentale evitare transizioni di stato tra zone durante le operazioni lucreate e lumount. |
|
|
Se l'amministratore di zone globali non notifica all'amministratore di zone non globali un aggiornamento con Solaris Live Upgrade, possono verificarsi problemi. |
Quando sono in corso operazioni in Solaris Live Upgrade, l'intervento dell'amministratore di zone non globali è di importanza fondamentale. L'aggiornamento interessa le attività degli amministratori, che si occupano delle modifiche verificatesi a seguito di un aggiornamento. Gli amministratori di zona devono assicurare che la stabilità dei pacchetti locali durante tutta la sequenza, devono gestire tutte le procedure successive all'aggiornamento quali le impostazioni dei file di configurazione ed eseguire una pianificazione generale dei tempi di inattività del sistema. Ad esempio, se un amministratore di zone non globali aggiunge un pacchetto mentre l'amministratore di zone globali copia file system con il comando lucreate, il nuovo pacchetto non viene copiato con i file system e l'amministratore di zone non globali non è a conoscenza del problema. | |
Non è possibile utilizzare gli archivi di Solaris Flash con zone non globali. |
Non è possibile creare un archivio Solaris Flash quando è installata una zona non globale. La funzione Solaris Flash non è compatibile con la tecnologia di partizionamento Solaris Zones. Quando si crea un archivio Solaris Flash, l'archivio risultante non viene installato in modo corretto quando si verificano le seguenti condizioni:
|
Per maggiori informazioni sull'utilizzo degli archivi Solaris Flash, vedere la Guida all’installazione di Solaris 10 5/09: archivi Solaris Flash (creazione e installazione). |
In alcune condizioni, non devono essere usati comandi che utilizzano l'opzione -R o un'opzione equivalente. |
I comandi che accettano un file system radice alternativo (/) con l'opzione -R o equivalente non devono essere usati quando si verificano le seguenti condizioni:
Un esempio può essere l'opzione -R percorso_radice del comando pkgadd eseguito dalla zona globale utilizzando un percorso del file system radice (/) che si trova in una zona non globale. |
Per un elenco dei programmi che accettano un file system radice (/) alternativo e per maggiori informazioni sulle zone, vedere Restriction on Accessing A Non-Global Zone From the Global Zone in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones. |
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 26, Solaris Zones Administration (Overview) in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones.
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: Solaris Containers-Resource Management and Solaris Zones.
Questo capitolo prende in esami i vantaggi della creazione di volumi RAID-1 (mirror) per il file system radice (/). 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.
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 Solaris 10 5/09: Solaris Live Upgrade e pianificazione degli aggiornamenti
Per JumpStart:
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 radice (/). È 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.
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.
La Figura 9–1 mostra un mirror che duplica il file system radice (/) su due dischi fisici.
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 radice (/) su entrambi i submirror.
Il file system radice (/) su hdisk0 è incluso nella concatenazione di una singola slice denominata d31.
Il file system radice (/) viene copiato sul disco rigido denominato hdisk1. Questa copia è la concatenazione di una singola slice denominata d32.
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.
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 radice (/), 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.
Descrizione |
Per maggiori informazioni |
---|---|
Indicazioni e requisiti per l'utilizzo dei metodi JumpStart personalizzato e Solaris Live Upgrade per l'installazione di volumi RAID-1. |
Linee guida e requisiti delle repliche del database di stato |
Informazioni più dettagliate sul database di stato e sulle repliche del database di stato. |
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.
Descrizione |
Per maggiori informazioni |
---|---|
Pianificazione per i volumi RAID-1 | |
Informazioni dettagliate sui volumi RAID-1 |
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.
Descrizione |
Per maggiori informazioni |
---|---|
Pianificazione per i volumi RAID–0 | |
Informazioni dettagliate sui volumi RAID-0 |
La figura seguente mostra un volume RAID-1 che duplica il file system radice (/) su due dischi fisici. Le repliche del database di stato (metadb) vengono posizionate su entrambi i dischi.
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 radice (/) su entrambi i submirror.
Il file system radice (/) su hdisk0 è incluso nella concatenazione di una singola slice denominata d31.
Il file system radice (/) viene copiato sul 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.
Descrizione |
Per maggiori informazioni |
---|---|
Esempio di profilo JumpStart | |
Procedure dettagliate per Solaris Live Upgrade |
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.
Linee guida e requisiti delle repliche del database di stato
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 Solaris 10 5/09: Solaris Live Upgrade e pianificazione degli aggiornamenti
Per JumpStart:
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.
È 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.
Attività |
Descrizione |
---|---|
Scegliere una slice dedicata |
È consigliabile creare le repliche del database di stato su una slice dedicata di almeno 4 MB 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. |
Ridimensionare una slice |
Nell'impostazione predefinita, la dimensione di una replica del database di stato è di 4 MB 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 il Capitolo 11, Administering Disks (Tasks) in System Administration Guide: Devices and File Systems. |
Scegliere una slice non utilizzata |
È 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. |
|
Scegliere una slice per creare un volume |
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 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.
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.
Programma di installazione |
Funzione supportata |
Funzione non supportata |
---|---|---|
Metodo JumpStart personalizzato e Solaris Live Upgrade |
|
In Solaris Volume Manager, un volume RAID-0 può fare riferimento a stripe o a concatenazioni di dischi. Non è possibile creare volumi RAID-0 in striping durante l'installazione o l'aggiornamento. |
Metodo JumpStart personalizzato |
|
|
Solaris Live Upgrade |
Per gli esempi, vedere Creare un ambiente di boot con volumi RAID-1 (mirror) in Guida all’installazione di Solaris 10 5/09: Solaris Live Upgrade e pianificazione degli aggiornamenti. |
Non sono supportati più di tre volumi RAID-0. |
Creazione e installazione di un archivio Solaris Flash con volumi RAID-1 |
È possibile creare un archivio Solaris Flash da un sistema master che utilizza volumi RAID-1 di Solaris Volume Manager. Il software Solaris Flash rimuove tutte le informazioni dei volumi RAID-1 dall'archivio per mantenere l'integrità del sistema clone. Con il metodo JumpStart personalizzato è possibile ricostruire i volumi RAID-1 usando un profilo JumpStart. Con Solaris Live Upgrade è possibile creare un ambiente di boot che utilizza volumi RAID-1 e quindi installare l'archivio. Il programma di installazione di Solaris non può essere utilizzato per installare i volumi RAID-1 con un archivio Solaris Flash. Per un esempio di utilizzo dei volumi RAID-1 nei profili JumpStart, vedere Esempi di profilo in Guida all’installazione di Solaris 10 5/09: metodo JumpStart personalizzato e installazioni avanzate . |
Veritas VxVM memorizza le informazioni di configurazione in aree che non sono disponibili per Solaris Flash. Se sono stati configurati i file system Veritas VxVm, evitare di creare un archivio Solaris Flash. Inoltre, l'installazione di Solaris, inclusi i metodi JumpStart e Solaris Live Upgrade, non supporta la ricostruzione dei volumi VxVM in fase di installazione. Se si intende distribuire il software Veritas VxVM usando un archivio Solaris Flash, questo deve essere creato prima di configurare i file system VxVM. I sistemi clone devono quindi essere configurati singolarmente dopo l'applicazione dell'archivio e il riavvio del sistema. |
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.
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.
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 |
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.
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.
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.
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 /
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.
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 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.
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 su metasync, vedere la pagina man metasync(1M) e il manuale Solaris Volume Manager Administration Guide.