Parte II Installazioni basate su GRUB, Solaris Zones e 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.

• Avvio con GRUB sui sistemi x86

• Tecnologia di partizionamento Solaris Zones

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

Capitolo 6 x86: Avvio con GRUB per l'installazione di Solaris

Questo capitolo descrive l'avvio con GRUB dei sistemi x86 per l'installazione di Solaris. Il capitolo è suddiviso nelle seguenti sezioni:

• x86: Avvio con GRUB (panoramica)

• x86: Avvio con GRUB (pianificazione)

x86: Avvio con GRUB (panoramica)

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

L'avvio con GRUB non è disponibile sui sistemi SPARC.

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. Questa specifica è descritta in modo dettagliato alla pagina Web 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. Ad esempio è possibile, su uno stesso sistema, avviare individualmente i seguenti sistemi operativi:

• Solaris

• Microsoft Windows

  ---

  Nota –

  GRUB rileva le partizioni di Microsoft Windows ma non verifica la possibilità di avviare il sistema operativo.

  ---

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: Caratteristiche del processo di avvio con GRUB

Quando GRUB assume il controllo del sistema, sulla console viene visualizzato un menu. Usando il menu di GRUB è possibile:

• Selezionare una voce per l'avvio del sistema

• Modificare una voce di avvio utilizzando il menu di modifica di GRUB

• Caricare manualmente il kernel di un sistema operativo dalla riga di comando

Per l'avvio del sistema operativo predefinito è disponibile un timeout configurabile. Premendo qualsiasi tasto, l'avvio del sistema operativo predefinito viene interrotto.

Per un esempio del menu di GRUB, vedere Descrizione del menu principale di GRUB.

x86: Convenzioni di denominazione dei dispositivi di GRUB

Le convenzioni di denominazione dei dispositivi utilizzate da GRUB sono leggermente diverse rispetto a quelle delle versioni precedenti di Solaris. La conoscenza di queste convenzioni può essere utile per specificare correttamente le informazioni relative alle unità e alle partizioni durante la configurazione di GRUB sul sistema.

La tabella seguente descrive le convenzioni di denominazione dei dispositivi di GRUB.

In GRUB, i nomi dei dispositivi devono essere sempre specificati tra parentesi. Le partizioni vengono numerate a partire da 0 (zero), non da 1.

Per maggiori informazioni sulle partizioni fdisk, vedere la sezione Guidelines for Creating an fdisk Partition in System Administration Guide: Devices and File Systems.

x86: Dove trovare informazioni sulle installazioni con GRUB

Per maggiori informazioni su queste modifiche, vedere i seguenti riferimenti.

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 la sezione How Multiple Operating Systems Are Supported in the GRUB Boot Environment 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 Solaris 10 5/08: installazioni di rete .

Descrizione del menu principale di GRUB

Quando si avvia un sistema x86, viene visualizzato il menu di GRUB. Questo menu offre la possibilità di scegliere tra diverse voci di avvio. Ogni voce di avvio corrisponde a un'istanza di un sistema operativo installata sul sistema. Il menu di GRUB si basa sul file di configurazione menu.lst. Il file menu.lst viene creato dal programma di installazione di Solaris e può essere modificato dopo l'installazione. Il file menu.lst determina l'elenco delle istanze dei sistemi operativi visualizzate nel menu di GRUB.

• Se si installa o si aggiorna il sistema operativo Solaris, il menu di GRUB viene aggiornato automaticamente. Il sistema operativo Solaris viene quindi visualizzato come una nuova voce di avvio.

• Se si installa un sistema operativo diverso da Solaris, è necessario modificare il file di configurazione menu.lst per includervi il nuovo sistema. Aggiungendo la nuova istanza, la nuova voce di avvio apparirà nel menu di GRUB all'avvio successivo del sistema.

Esempio 6–1 Menu principale di GRUB

Nell'esempio seguente, il menu principale di GRUB mostra i sistemi operativi Solaris e Microsoft Windows. È inoltre elencato un ambiente di boot Solaris Live Upgrade di nome secondo_disco. Qui di seguito è fornita una descrizione delle singole voci del menu.

GNU GRUB version 0.95 (616K lower / 4127168K upper memory)
+-------------------------------------------------------------------+
|Solaris                                                            |
|Solaris  failsafe                                                  |
|secondo_disco                                                      |
|secondo_disco failsafe                                             |
|Windows                                                            |
+-------------------------------------------------------------------+
Use the ^ and v keys to select which entry is highlighted. Press
enter to boot the selected OS, 'e' to edit the commands before
booting, or 'c' for a command-line.

Solaris

Specifica il sistema operativo Solaris.

Solaris failsafe

Specifica un archivio di avvio che può essere utilizzato per il ripristino del sistema in caso di danneggiamento del sistema operativo Solaris.

secondo_disco

Specifica un ambiente di boot di Solaris Live Upgrade L'ambiente di boot secondo_disco è stato creato come copia del sistema operativo Solaris. È stato quindi aggiornato e attivato con il comando luactivate. L'ambiente di boot è disponibile per l'avvio del sistema.

Windows

Specifica il sistema operativo Microsoft Windows. GRUB rileva queste partizioni ma non verifica la possibilità di avviare il sistema operativo.

Descrizione del file menu.lst di GRUB

Il file menu.lst di GRUB specifica il contenuto del menu principale di GRUB. Il menu principale di GRUB contiene le voci di avvio per tutte le istanze dei sistemi operativi installate sul sistema, inclusi gli ambienti di boot Solaris Live Upgrade. Il processo di aggiornamento di Solaris preserva le modifiche eventualmente apportate a questo file.

Le revisioni effettuate sul file menu.lst vengono visualizzate nel menu principale di GRUB insieme alle voci di Solaris Live Upgrade. Le modifiche apportate al file diventano effettive al riavvio successivo del sistema. La modifica di questo file può rendersi necessaria per le seguenti ragioni:

• Per aggiungere al menu di GRUB voci corrispondenti a sistemi operativi diversi da Solaris

• Per personalizzare la procedura di avvio, ad esempio specificando nel menu di GRUB il sistema operativo predefinito

Non utilizzare il file menu.lst di GRUB per modificare le voci di Solaris Live Upgrade. Tali modifiche potrebbero impedire la corretta esecuzione di Solaris Live Upgrade.

Pur essendo possibile utilizzare il file menu.lst per personalizzare la procedura di avvio, ad esempio specificando l'avvio con il debugger del kernel, per eseguire una personalizzazione è preferibile usare il comando eeprom. Utilizzando il file menu.lst per la personalizzazione del processo, è possibile che le voci relative a Solaris vengano modificate durante un aggiornamento del software. In questo caso, le modifiche al file andrebbero perdute.

Per informazioni sull'utilizzo del comando eeprom, vedere la sezione How to Set Solaris Boot Parameters by Using the eeprom Command in System Administration Guide: Basic Administration.

Esempio 6–2 File Menu.lst

Qui di seguito è riportato un esempio del file menu.lst:

default 0
timeout 10
title Solaris
  root (hd0,0,a)
  kernel /platform/i86pc/multiboot -B console=ttya
  module /platform/i86pc/boot_archive
title Solaris failsafe
  root (hd0,0,a)
  kernel /boot/multiboot -B console=ttya -s
  module /boot/x86.miniroot.safe
#----- secondo_disco - ADDED BY LIVE UPGRADE - DO NOT EDIT  -----
title secondo_disco
  root (hd0,0,a)
  kernel /platform/i86pc/multiboot
  module /platform/i86pc/boot_archive
title secondo_disco failsafe
  root (hd0,0,a)
  kernel /boot/multiboot kernel/unix -s
  module /boot/x86.miniroot-safe
#----- secondo_disco -------------- END LIVE UPGRADE ------------
title Windows
  root (hd0,0)
  chainloader -1

default

Specifica la voce di avvio da utilizzare alla scadenza del timeout. Per cambiare l'impostazione predefinita, è possibile specificare un'altra voce dell'elenco modificando il numero. La numerazione inizia da zero per il primo titolo. Ad esempio, è possibile cambiare l'impostazione predefinita in 2 per avviare il sistema automaticamente con l'ambiente di boot secondo_disco.

timeout

Specifica il numero di secondi di attesa prima che venga attivata la voce di avvio predefinita; in questo periodo è possibile premere un tasto e quindi indicare un'altra voce. Se non viene specificato il timeout, verrà richiesto di scegliere una voce.

title nome del sistema operativo

Specifica il nome del sistema operativo.

• Se si tratta di un ambiente di boot di Solaris Live Upgrade, il nome del sistema operativo è il nome assegnato al nuovo ambiente di boot al momento della sua creazione. Nell'esempio precedente, l'ambiente di boot di Solaris Live Upgrade è denominato secondo_disco.

• Se si tratta di un archivio di avvio di emergenza, esso viene utilizzato per il ripristino del sistema in caso di danneggiamento del sistema operativo primario. Nell'esempio precedente, Solaris failsafe e secondo_disco failsafe sono gli archivi di avvio di emergenza per i sistemi operativi Solaris e secondo_disco.

root (hd0,0,a)

Specifica in quale disco, partizione e slice caricare i file. GRUB rileva automaticamente il tipo di file system.

kernel /platform/i86pc/multiboot

Specifica il programma multiboot. Il comando kernel deve sempre essere seguito dal programma multiboot. La stringa che segue multiboot viene passata al sistema operativo Solaris senza interpretazione.

Per una descrizione completa dell'utilizzo di più sistemi operativi, vedere la sezione How Multiple Operating Systems Are Supported in the GRUB Boot Environment in System Administration Guide: Basic Administration.

Individuazione del file menu.lst per la modifica del menu di GRUB

Per individuare il file menu.lst di GRUB è sempre necessario utilizzare il comando bootadm. Il sottocomando list-menu individua il menu di GRUB attivo. Il file menu.lst elenca tutti i sistemi operativi installati su un sistema. Dal contenuto di questo file dipende l'elenco dei sistemi operativi visualizzati nel menu di GRUB. Per apportare modifiche a questo file, vedere Individuazione del file menu.lst del menu di GRUB (procedure) in Guida all’installazione di Solaris 10 5/08: Solaris Live Upgrade e pianificazione degli aggiornamenti.

Capitolo 7 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. Le modifiche richieste per i sistemi su cui sono presenti zone non globali sono riassunte di seguito.

• Se si utilizza il programma di installazione di Solaris, è possibile aggiornare il sistema quando sono presenti zone non globali. 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, Uso del programma di installazione di Solaris (procedure) in Guida all’installazione di Solaris 10 5/08: installazioni di base.

• Se si esegue un'installazione automatizzata JumpStart, è possibile aggiornare o applicare le patch usando tutte 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/08: metodo JumpStart personalizzato e installazioni avanzate .

• Se si utilizza 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. Le modifiche richieste per i sistemi su cui sono presenti zone non globali sono le seguenti:

  • È richiesta l'installazione di un nuovo pacchetto, SUNWlucfg, con gli altri pacchetti di Solaris Live Upgrade, SUNWlur e SUNWluu.

  • La procedura per la creazione di un nuovo ambiente di boot sulla base di quello corrente è immutata, con una sola eccezione. È possibile specificare una slice di destinazione per un file system condiviso all'interno di una zona non globale. Questa eccezione si verifica in presenza delle seguenti condizioni:

    • Se nell'ambiente di boot corrente è stato usato il comando zonecfg add fs per creare un file system separato per una zona non globale

    • Se questo file system separato risiede su un file system condiviso, ad esempio /zone/root/export

    Per prevenire la condivisione di questo file system separato nel nuovo ambiente di boot, il comando lucreate è stato modificato in modo da consentire di specificare una slice di destinazione per un file system separato per una zona non globale. L'argomento dell'opzione -m dispone di un nuovo campo opzionale, nome_zona. Questo nuovo campo posiziona il file system separato della zona non globale su una slice separata nel nuovo ambiente di boot. Per maggiori informazioni sulla configurazione di una zona non globale con un file system separato, vedere zonecfg(1M).

    ---

    Nota –

    Nell'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.

    ---

  • Le procedure di confronto tra gli ambienti di boot sono state migliorate. Il comando lucompare ora genera un confronto tra ambienti di boot che include i contenuti di tutte le zone non globali.

  • Il comando lumount fornisce ora zone non globali con accesso ai corrispondenti file system separati che sono presenti negli ambienti di boot inattivi. Quando l'amministratore della zona globale utilizza il comando lumount per attivare un ambiente di boot inattivo, l'ambiente di boot viene attivato anche per le zone non globali.

  • L'elenco dei file system generato dal comando lufslist visualizza ora i file system sia per la zona globale che per quelle non globali.

Per istruzioni dettagliate sull'utilizzo di Solaris Live Upgrade in presenza di zone non globali, vedere il Capitolo 9, Aggiornamento di Solaris su un sistema con zone non globali in Guida all’installazione di Solaris 10 5/08: Solaris Live Upgrade e pianificazione degli aggiornamenti.

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 26, Solaris Zones Administration (Overview) in System Administration Guide: Solaris Containers-Resource Management and 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: Solaris Containers-Resource Management and Solaris Zones.

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

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.

• 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 Solaris 10 5/08: Solaris Live Upgrade e pianificazione degli aggiornamenti

• Per JumpStart:

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

  • Parola chiave metadb (creazione di repliche del database di stato) in Guida all’installazione di Solaris 10 5/08: 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 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.

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.

La Figura 8–1 mostra un mirror che duplica il file system radice (/) su due dischi fisici.

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

La Figura 8–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.

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

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

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.

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

La Figura 8–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.

Capitolo 9 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 Solaris 10 5/08: Solaris Live Upgrade e pianificazione degli aggiornamenti

• Per JumpStart:

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

  • Parola chiave metadb (creazione di repliche del database di stato) in Guida all’installazione di Solaris 10 5/08: 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 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.

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 nella stessa slice.

  • Per i sistemi con due/quattro unità disco: posizionare due repliche su ogni disco.

  • Per i sistemi con cinque o più unità disco: posizionare una replica su ogni unità disco.

• La presenza di più repliche del database di stato può migliorare le prestazioni del mirror. In genere, è necessario aggiungere due repliche per ogni mirror che si aggiunge al sistema.

• Se si dispone di un volume RAID-1 da utilizzare per gli I/O casuali di piccole dimensioni (ad esempio per un database), valutare il numero di repliche da utilizzare. Per ottenere le migliori prestazioni, verificare di disporre di almeno due repliche supplementari per ogni volume RAID-1 posizionate su slice (e preferibilmente anche su dischi e controller) non collegati al volume RAID-1.

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, assegnare nomi terminanti in 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 8/07, è 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 9–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 nuovo_be -m /:/dev/md/dsk/d10:mirror,ufs -m /:/dev/dsk/c0t0d0s0:attach
-m /:/dev/dsk/c1t0d0s0:attach

Esempio 9–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 nuovo_be -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 9–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 9–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 radice (/), swap e /usr possono utilizzare un mirror. Qualsiasi applicazione, ad esempio un database, può utilizzare un mirror.

• Verificare che le slice dei submirror abbiano le stesse dimensioni. L'uso di submirror con dimensioni differenti impedisce l'utilizzo di tutto lo spazio disponibile.

• Se per uno dei file system in mirroring il primo submirror collegato non parte dal cilindro 0, tutti gli altri submirror che vengono collegati non devono partire dal cilindro 0. Se si cerca di collegare un submirror che inizia al cilindro 0 ad un mirror in cui il submirror originale non inizia al cilindro 0, viene generato il seguente messaggio di errore:

  impossibile unire un submirror con etichetta a un mirror senza etichetta

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