JavaScript is required to for searching.
Ignora collegamenti di spostamento
Esci da visualizzazione stampa
Guida all'installazione di Oracle Solaris 10 8/11: Solaris Live Upgrade e pianificazione degli aggiornamenti
search filter icon
search icon

Informazioni sul documento

Prefazione

Parte I Aggiornamento con Solaris Live Upgrade

1.  Informazioni sulla pianificazione dell'installazione di Solaris

2.  Solaris Live Upgrade (panoramica)

Descrizione di Solaris Live Upgrade

Procedura Solaris Live Upgrade

Creazione di un ambiente di boot

Tipi di file system

Copia dei file system

Creazione di un ambiente di boot con file system di volumi RAID-1

Gestione dei volumi con Solaris Live Upgrade

Corrispondenze tra le operazioni di Solaris Volume Manager e quelle di Solaris Live Upgrade

Esempi di utilizzo di Solaris Live Upgrade per la creazione di volumi RAID-1

Aggiornamento di un ambiente di boot

Effetto della registrazione automatica sul Live Upgrade.

Attivazione di un ambiente di boot

Ripristino dell'ambiente di boot originale

Manutenzione di un ambiente di boot

3.  Solaris Live Upgrade (pianificazione)

4.  Uso di Solaris Live Upgrade per creare un ambiente di boot (procedure)

5.  Aggiornamento con Solaris Live Upgrade (procedure)

6.  Ripristino dei guasti: ripristino dell'ambiente di boot originale (procedure)

7.  Manutenzione degli ambienti di boot con Solaris Live Upgrade (procedure)

8.  Aggiornamento del sistema operativo Oracle Solaris su un sistema con zone non globali

9.  Solaris Live Upgrade (esempi)

10.  Solaris Live Upgrade (riferimenti sui comandi)

Parte II Aggiornamento e migrazione con Solaris Live Upgrade a un pool root ZFS

11.  Solaris Live Upgrade e ZFS (panoramica)

12.  Solaris Live Upgrade per ZFS (pianificazione)

13.  Creazione di un ambiente di boot per i pool root ZFS

14.  Solaris Live Upgrade per ZFS in presenza di zone non globali

Parte III Appendici

A.  Soluzione dei problemi (procedure)

B.  Altri requisiti per i pacchetti SVR4 (riferimenti)

C.  Utilizzo dello strumento di analisi delle patch nell'aggiornamento (procedure)

Glossario

Indice analitico

Procedura Solaris Live Upgrade

Qui di seguito sono descritte le operazioni necessarie per creare una copia dell'ambiente di boot corrente, aggiornare la copia e attivare la copia aggiornata rendendola l'ambiente di boot corrente. Viene descritto anche il processo con cui è possibile ripristinare l'ambiente di boot originale. La Figura 2-1 descrive questa procedura completa di Solaris Live Upgrade.

Figura 2-1 Procedura Solaris Live Upgrade

image:Il contesto descrive l'illustrazione.

Le sezioni seguenti descrivono la procedura Solaris Live Upgrade.

  1. Il nuovo ambiente di boot può essere creato su una slice fisica o su un volume logico:

  2. Aggiornamento di un ambiente di boot

  3. Attivazione di un ambiente di boot

  4. Ripristino dell'ambiente di boot originale

Creazione di un ambiente di boot

La creazione di un ambiente di boot consente di copiare i file system di importanza critica dall'ambiente di boot attivo a uno nuovo. Il disco viene riorganizzato (se necessario), i file system vengono personalizzati e i file system di importanza critica vengono copiati nel nuovo ambiente di boot.

Tipi di file system

Solaris Live Upgrade distingue tra due tipi di file system: file system di importanza critica e file system condivisibili. La tabella seguente descrive questi tipi di file system.

Tipo di file system
Descrizione
Esempi e altre informazioni
File system critici
I file system critici sono necessari per il sistema operativo Oracle Solaris. Questi file system sono rappresentati da punti di attivazione separati nei file vfstab dell'ambiente di boot attivo e di quello inattivo. Questi file system vengono sempre copiati dall'ambiente originale all'ambiente di boot inattivo. I file system di importanza critica sono non condivisibili.
Alcuni esempi sono il file system root (/), /usr, /var o /opt.
File system condivisibili
I file system condivisibili vengono definiti dall'utente, ad esempio /export, e sono rappresentati dallo stesso punto di attivazione nel file vfstab dell'ambiente di boot attivo e in quello dell'ambiente inattivo. Di conseguenza, l'aggiornamento dei file condivisi nell'ambiente di boot attivo si riflette anche sui dati dell'ambiente di boot inattivo. Quando si crea un nuovo ambiente di boot, i file system condivisibili vengono automaticamente condivisi. È possibile tuttavia specificare una slice di destinazione in cui copiarli.
Un esempio di file system che può essere condiviso è /export.

Per informazioni più dettagliate sui file system condivisibili, vedere Indicazioni per la scelta delle slice per i file system condivisibili.

Swap
  • Per i file system UFS, swap è uno speciale volume condivisibile. Come negli altri file system di questo tipo, tutte le slice sono già condivise nella configurazione predefinita. È tuttavia possibile specificare una directory di destinazione in cui copiare la slice di swap.
  • Per i file system ZFS, i volumi swap e dump sono condivisi con il pool.

Creazione di volumi RAID-1 sui file system

Solaris Live Upgrade può creare un ambiente di boot che comprende volumi RAID-1 (mirror) nei file system. Per una descrizione generale, vedere Creazione di un ambiente di boot con file system di volumi RAID-1.

Copia dei file system

Il primo passo per la creazione di un nuovo ambiente di boot consiste nell'identificare una slice non utilizzata in cui sia possibile copiare un file system di importanza critica. Se non è disponibile una slice non utilizzata, o se la slice non soddisfa i requisiti minimi richiesti, è necessario formattare una nuova slice.

Una volta definita la slice, è possibile riconfigurare i file system del nuovo ambiente di boot prima di copiarli nelle directory. La riconfigurazione, vale a dire la divisione o la combinazione dei file system, rappresenta un metodo semplice per modificare il file vfstab per connettere e disconnettere le directory dei file system. È possibile unire i file system con le directory di livello superiore specificando lo stesso punto di attivazione. È anche possibile dividere i file system dalle directory di livello superiore specificando punti di attivazione differenti.

Una volta configurati i file system nell'ambiente di boot inattivo, è possibile avviare la copia automatica. I file system di importanza critica vengono copiati nelle directory designate. I file system condivisibili non vengono copiati ma vengono condivisi. Fa eccezione il caso in cui i alcuni file system condivisibili vengono designati per essere copiati. Quando i file system vengono copiati dall'ambiente di boot attivo a quello inattivo, i file vengono posizionati nelle nuove directory. L'ambiente di boot attivo non viene in nessun modo modificato.

Per le procedure di divisione o unione dei file system
Per una descrizione della creazione di un ambiente di boot con file system di volumi RAID–1
Esempi di creazione di un nuovo ambiente di boot

Per i file system UFS, le figure seguenti illustrano vari metodi per la creazione di nuovi ambienti di boot.

Per i file system ZFS, vedere il Capitolo 11Solaris Live Upgrade e ZFS (panoramica)

La Figura 2-2 mostra il file system root (/) copiato in un'altra slice di un disco per creare un nuovo ambiente di boot. L'ambiente di boot attivo contiene il file system root (/) in un'unica slice. Il nuovo ambiente di boot è una copia esatta del file system root (/) in una nuova slice. Il volume /swap e il file system /export/home vengono condivisi dall'ambiente di boot attivo e da quello inattivo.

Figura 2-2 Creazione di un ambiente di boot inattivo – Copia del file system root (/)

image:Il contesto descrive l'illustrazione.

La Figura 2-3 mostra i file system di importanza critica che sono stati divisi e copiati su un disco per creare un nuovo ambiente di boot. L'ambiente di boot attivo contiene il file system root (/) in un'unica slice. In questa slice, il file system root (/) contiene le directory /usr, /var e /opt. Nel nuovo ambiente di boot, il file system root (/) è diviso e le directory /usr e /opt si trovano in slice separate. Il volume /swap e il file system /export/home vengono condivisi da entrambi gli ambienti di boot.

Figura 2-3 Creazione di un ambiente di boot inattivo – Divisione dei file system

image:Il contesto descrive l'illustrazione.

La Figura 2-4 mostra i file system di importanza critica che sono stati divisi e copiati su un disco per creare un nuovo ambiente di boot. L'ambiente di boot attivo contiene i file system root (/), /usr, /var e /opt, ognuno in una propria slice. Nel nuovo ambiente di boot, /usr e /opt sono uniti nel file system root (/) in un'unica slice. Il volume /swap e il file system /export/home vengono condivisi da entrambi gli ambienti di boot.

Figura 2-4 Creazione di un ambiente di boot inattivo – Unione dei file system

image:Il contesto descrive l'illustrazione.

Creazione di un ambiente di boot con file system di volumi RAID-1

Solaris Live Upgrade utilizza la tecnologia di Solaris Volume Manager per creare un ambiente di boot che possa contenere file system incapsulati in volumi RAID-1. 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. Solaris Live Upgrade permette di eseguire un sottoinsieme di queste operazioni, ad esempio la creazione di un volume RAID-1 per il file system root ( /).

I volumi permettono di raggruppare le slice di diversi dischi in modo che appaiano come un unico disco al sistema operativo. Solaris Live Upgrade permette solo di creare un ambiente di boot per il file system root (/) che contenga concatenazioni di una singola slice all'interno di un volume RAID-1 (mirror). Questa limitazione è legata al fatto che la PROM di boot permette di scegliere una sola slice per l'avvio del sistema.

Gestione dei volumi con Solaris Live Upgrade

Quando si crea un ambiente di boot, è possibile usare Solaris Live Upgrade per gestire le seguenti operazioni.

Il comando lucreate con l'opzione -m permette di creare un mirror, di scollegare i submirror e di collegarli al nuovo ambiente di boot.


Nota - Se sul sistema in uso sono configurati volumi VxVM, il comando lucreate può creare un nuovo ambiente di boot. Quando i dati vengono copiati sul nuovo ambiente di boot, la configurazione del file system Veritas viene perduta e sul nuovo ambiente di boot viene creato un file system UFS.


Per le procedure dettagliate
Per una descrizione della creazione dei volumi RAID-1 durante l'installazione
Per informazioni dettagliate su altre configurazioni complesse di Solaris Volume Manager che non sono supportate da Solaris Live Upgrade

Corrispondenze tra le operazioni di Solaris Volume Manager e quelle di Solaris Live Upgrade

Solaris Live Upgrade gestisce un sottoinsieme delle operazioni di Solaris Volume Manager. La Tabella 2-1 mostra i componenti di Solaris Volume Manager che possono essere gestiti da Solaris Live Upgrade.

Tabella 2-1 Classi di volumi

Termine
Descrizione
concatenazione
Volume RAID-0. Se le slice sono concatenate, i dati vengono scritti nella prima slice disponibile finché il suo spazio non è esaurito. Una volta raggiunto il limite di spazio di quella slice, i dati vengono scritti nella slice successiva, in modo seriale. La concatenazione non fornisce alcuna ridondanza dei dati, a meno che non sia contenuta in un mirror.
mirror
Volume RAID-1. Vedere volume RAID-1.
volume RAID-1
Classe di volumi che replica i dati conservandone più copie. I volumi RAID-1 vengono a volte denominati mirror. I volumi RAID-1 sono formati da uno o più volumi RAID-0, detti submirror.
volume RAID-0
Classe di volumi che comprende stripe o concatenazioni. Questi componenti sono denominati submirror. Le stripe o le concatenazioni sono i componenti essenziali dei mirror.
database di stato
Il database di stato memorizza informazioni riguardo allo stato della configurazione di Solaris Volume Manager. Il database di stato è una raccolta di più copie replicate del database. Ogni copia viene denominata replica del database di stato. Il database di stato tiene traccia della posizione e dello stato di tutte le repliche note.
replica del database di stato
Copia di un database di stato. La replica garantisce che i dati del database siano validi.
submirror
Vedere volume RAID-0.
volume
Gruppo di slice fisiche o di altri volumi che appare al sistema come un unico dispositivo logico. Dal punto di vista delle applicazioni o dei file system, i volumi sono funzionalmente identici ai dischi fisici. In alcune utility disponibili dalla riga di comando, i volumi sono denominati metadevice.

Esempi di utilizzo di Solaris Live Upgrade per la creazione di volumi RAID-1

Gli esempi seguenti presentano la sintassi dei comandi che permettono di creare volumi RAID-1 per un nuovo ambiente di boot.

Creazione di un volume RAID-1 su due dischi fisici

La Figura 2-5 mostra un nuovo ambiente di boot in cui un volume RAID-1 (mirror) è stato creato su due dischi fisici. Per creare il nuovo ambiente di boot e il mirror è stato usato il comando seguente.

# lucreate -n second_disk -m /:/dev/md/dsk/d30:mirror,ufs \ -m /:/dev/dsk/c0t1d0s0,/dev/md/dsk/d31:attach -m /:/dev/dsk/c0t2d0s0,/dev/md/dsk/d32:attach \ -m -:/dev/dsk/c0t1d0s1:swap -m -:/dev/dsk/c0t2d0s1:swap

Questo comando esegue le seguenti operazioni:

Figura 2-5 Creare un ambiente di boot e creare un mirror

image:Il contesto descrive l'illustrazione.
Creare un ambiente di boot e usare il submirror esistente

La Figura 2-6 mostra un nuovo ambiente di boot contenente un volume RAID-1 (mirror). Per creare il nuovo ambiente di boot e il mirror è stato usato il comando seguente.

# lucreate -n second_disk -m /:/dev/md/dsk/d20:ufs,mirror \ -m /:/dev/dsk/c0t1d0s0:detach,attach,preserve

Questo comando esegue le seguenti operazioni:

Figura 2-6 Creare un ambiente di boot e usare il submirror esistente

image:La figura illustra il contesto.

Aggiornamento di un ambiente di boot

Dopo aver creato un ambiente di boot, è possibile eseguirne un aggiornamento. Nell'ambito di questo aggiornamento, l'ambiente di boot può contenere volumi RAID-1 (mirror) per qualunque file system. Nell'ambiente di boot possono essere presenti zone non globali. Questa procedura infatti non ha effetto sui file dell'ambiente di boot attivo. Al momento opportuno, è possibile attivare il nuovo ambiente di boot, che quindi diventa l'ambiente di boot corrente.


Nota - A partire dalla release Oracle Solaris 10 9/10, il processo di aggiornamento viene bloccato dalla registrazione automatica. Vedere Effetto della registrazione automatica sul Live Upgrade..


Per le procedure sull'aggiornamento di un ambiente di boot per i file system UFS
Per un esempio dell'aggiornamento di un ambiente di boot con il file system di un volume RAID–1 per i file system UFS
Per le procedure sull'aggiornamento in presenza di zone non globali per i file system UFS
Per informazioni sull'aggiornamento dei file system ZFS o sulla migrazione a un file system ZFS

La Figura 2-7 illustra l'aggiornamento di un ambiente di boot inattivo.

Figura 2-7 Aggiornamento di un ambiente di boot inattivo

image:Il contesto descrive l'illustrazione.

Anziché eseguire un aggiornamento, è possibile installare un archivio Solaris Flash in un ambiente di boot. La funzione di installazione Solaris Flash consente di creare una singola installazione di riferimento del sistema operativo Oracle Solaris. Questo sistema viene denominato sistema master. Successivamente, tale installazione può essere replicata su altri sistemi, denominati cloni. In questo caso, l'ambiente di boot inattivo è un clone. Quando si installa un archivio Solaris Flash su un sistema, l'archivio sostituisce tutti i file dell'ambiente di boot esistente, come accadrebbe eseguendo un'installazione iniziale.

Per le procedure di installazione degli archivi Solaris Flash, vedere Installazione di archivi Solaris Flash in un ambiente di boot.

Le figure seguenti illustrano l'installazione di un archivio Solaris Flash in un ambiente di boot inattivo. La Figura 2-8 mostra un sistema con un solo disco rigido. La Figura 2-9 mostra un sistema con due dischi rigidi.

Figura 2-8 Installazione di un archivio Solaris Flash su un solo disco

image:Il contesto descrive l'illustrazione.

Figura 2-9 Installazione di un archivio Solaris Flash su due dischi

image:Il contesto descrive l'illustrazione.

Effetto della registrazione automatica sul Live Upgrade.

A partire dalla release Oracle Solaris 10 9/10, il processo di aggiornamento viene bloccato dalla registrazione automatica.

Che cos'è la registrazione automatica?

Quando si installa o si aggiorna il sistema, al momento del reboot i dati di configurazione del sistema vengono comunicati automaticamente all'Oracle Product Registration System tramite la tecnologia dei tag servizio esistente. I dati dei tag servizio per il sistema in uso vengono utilizzati, ad esempio, per migliorare il supporto tecnico e i servizi Oracle. È possibile utilizzare gli stessi dati di configurazione per creare e gestire il proprio inventario di sistemi.

Per un'introduzione alla registrazione automatica, vedere Nuove funzioni di installazione in Oracle Solaris 10 9/10 in Guida all’installazione di Oracle Solaris 10 8/11: pianificazione dell’installazione e dell’aggiornamento.

Situazioni in cui la registrazione automatica incide su Live Upgrade

La registrazione automatica non modifica le procedure del Live Upgrade a meno che non si esegua l'aggiornamento di un sistema da una release precedente a Oracle Solaris 10 9/10 o release successive.

La registrazione automatica non determina alcuna modifica delle seguenti procedure del Live Upgrade.

Esclusivamente nella circostanza in cui si aggiorna un sistema da una versione precedente alla versione Oracle Solaris 10 9/10 o release successive, è necessario creare un file di configurazione. Quando si procede quindi all'aggiornamento di tale sistema, è necessario utilizzare l'opzione -k nel comando luupgrade -u, puntando a tale file di configurazione. Vedere la seguente procedura.

Come specificare i dati di registrazione automatica durante un aggiornamento

Esclusivamente nella circostanza in cui si aggiorna un sistema da una versione precedente alla versione Oracle Solaris 10 9/10 o release successive, utilizzare la presente procedura per fornire i dati di registrazione automatica richiesti durante l'aggiornamento.

  1. Utilizzare un editor di testo per creare un file di configurazione che contiene le credenziali di supporto e, facoltativamente, le informazioni sul proxy.

    Questo file è formattato come un elenco di coppie parola chiave/valore. Includere i seguenti valori e parole chiave in questo formato nel file.

    http_proxy=Proxy-Server-Host-Name
    http_proxy_port=Proxy-Server-Port-Number
    http_proxy_user=HTTP-Proxy-User-Name
    http_proxy_pw=HTTP-Proxy-Password
    oracle_user=My-Oracle-Support-User-Name
    oracle_pw=My-Oracle-Support-Password

    Nota - Attenersi alle seguenti regole.

    • Le password devono essere in testo normale, non codificato.

    • L'ordine delle parole chiave non è rilevante.

    • Le parole chiave possono essere omesse completamente se non si desidera specificare un valore. In alternativa è possibile mantenere la parola chiave e lasciare vuoto il valore.


      Nota - Se si omettono le credenziali di supporto, la registrazione sarà anonima.


    • Gli spazi nel file di configurazione non sono rilevanti, se non nel caso in cui il valore da immettere debba contenere uno spazio. Solo i valori http_proxy_user e http_proxy_pw possono contenere uno spazio al proprio interno.

    • Il valore oracle_pw non deve contenere spazi.


    Vedere l'esempio seguente.

    http_proxy= webcache.central.example.COM
    http_proxy_port=8080
    http_proxy_user=webuser
    http_proxy_pw=secret1
    oracle_user=joe.smith@example.com
    oracle_pw=csdfl2442IJS
  2. Salvare il file.
  3. Eseguire il comando luupgrade -u -k /path/filename, includendo le opzioni del comando luupgrade necessarie per l'aggiornamento in questione.

Come disabilitare i dati di registrazione automatica durante un aggiornamento

  1. Creare o rivedere il contenuto del file di configurazione descritto nelle istruzioni precedenti. Per disabilitare la registrazione automatica, questo file di configurazione deve contenere soltanto la seguente riga:
    autoreg=disable
  2. Salvare il file.
  3. Eseguire il comando luupgrade -u -k /path/filename, includendo le opzioni del comando luupgrade necessarie per l'aggiornamento in questione.
  4. Opzionale: quando il Live Upgrade è completo e viene effettuato il reboot del sistema, è possibile verificare che la funzionalità di registrazione automatica sia disabilitata come descritto.
    # regadm status
        Solaris Auto-Registration is currently disabled

Attivazione di un ambiente di boot

Quando si è pronti per usare il nuovo ambiente di boot, è possibile attivarlo velocemente ed effettuare il reboot del sistema. La prima volta che si avvia un nuovo ambiente di boot, i file vengono sincronizzati con quelli dell'ambiente precedentemente in uso. “Sincronizzazione” significa in questo caso la copia di alcuni file e directory di sistema dall'ambiente di boot precedente a quello nuovo. Quando si effettua il reboot del sistema, viene attivata la configurazione installata sul nuovo ambiente. L'ambiente di boot originale viene invece reso inattivo.

Per le procedure di attivazione di un ambiente di boot
Per informazioni sulla sincronizzazione tra l'ambiente di boot attivo e quello inattivo

La Figura 2-10 mostra il passaggio da inattivo ad attivo dell'ambiente di boot al reboot del sistema.

Figura 2-10 Attivazione di un ambiente di boot inattivo

image:Il contesto descrive l'illustrazione.

Ripristino dell'ambiente di boot originale

In caso di malfunzionamento, è possibile tornare velocemente all'ambiente di boot originale con un processo di attivazione e reboot. La procedura di fallback richiede solo il tempo di reboot del sistema, ed è perciò molto più veloce rispetto al backup e al ripristino dell'ambiente originale. Il nuovo ambiente di boot che non è stato avviato correttamente viene preservato. In questo modo, l'errore può essere analizzato. È possibile ripristinare con il fallback solo l'ambiente di boot che era stato usato da luactivate per attivare quello nuovo.

Per tornare all'ambiente di boot precedente, è possibile procedere nei seguenti modi:

Problema
Azione
Il nuovo ambiente di boot si avvia correttamente ma non si è soddisfatti dei risultati.
Eseguire il comando luactivate con il nome dell'ambiente di boot precedente ed effettuare il reboot del sistema.

x86 Solo - A partire dalla release Solaris 10 1/06, è possibile ripristinare l'ambiente di boot originale selezionandolo dal menu di GRUB. L'ambiente di boot originale e il nuovo ambiente di boot devono essere basati sul software GRUB. L'avvio dal menu di GRUB non sincronizza i file tra i due ambienti di boot. Per maggiori informazioni sulla sincronizzazione dei file, vedere Sincronizzazione forzata tra gli ambienti di boot.


Il nuovo ambiente di boot non si avvia.
Avviare l'ambiente di boot precedente in modalità monoutente, eseguire luactivate ed effettuare il reboot del sistema.
Non è possibile avviare il sistema in modalità monoutente.
Usare una delle procedure seguenti:
  • Avviare il sistema dal DVD, dal CD o da un'immagine di installazione di rete

  • Attivare il file system root (/) nell'ambiente di boot ripristinato

  • Eseguire il comando luactivate ed effettuare il reboot del sistema

Per istruzioni dettagliate, vedere il Capitolo 6Ripristino dei guasti: ripristino dell'ambiente di boot originale (procedure).

La Figura 2-11 mostra lo svolgimento del processo di ripristino.

Figura 2-11 Ripristino dell'ambiente di boot originale

image:Il contesto descrive l'illustrazione.

Manutenzione di un ambiente di boot

È anche possibile eseguire varie operazioni di manutenzione sull'ambiente di boot, ad esempio controllarne lo stato, rinominarlo o eliminarlo. Per informazioni sulle procedure di manutenzione, vedere il Capitolo 7Manutenzione degli ambienti di boot con Solaris Live Upgrade (procedure).