Teil II Installationen in Verbindung mit GRUB, Solaris Zones und RAID-1 Volumes

Dieser Teil enthält Übersichten der verschiedenen Technologien, die mit der Installation oder Aktualisierung des Betriebssystems Solaris in Verbindung stehen. Hier sind auch Richtlinien und Anforderungen enthalten.

• GRUB-basiertes Booten auf x86-Systemen

• Partionierungstechnologie Solaris Zones

• Solaris Volume Manager-Komponenten wie z.B. RAID-1 Volumes

Kapitel 6 x86: GRUB-basiertes Booten für die Solaris-Installation

In diesem Kapitel wird das GRUB-basierte Booten auf x86-Systemen für die Solaris-Installation beschrieben. Dieses Kapitel enthält die folgenden Abschnitte:

• x86: GRUB-basiertes Booten (Überblick)

• x86: GRUB-basiertes Booten (Planung)

x86: GRUB-basiertes Booten (Überblick)

GRUB, der Open Source Boot-Loader, ist jetzt der standardmäßige Boot-Loader des Betriebssystems Solaris.

GRUB-basiertes Booten steht für SPARC-Systeme nicht zur Verfügung.

Der Boot Loader ist das erste Softwareprogramm, das nach dem Einschalten des Systems ausgeführt wird. Nach dem Einschalten eines x86-basierten Systems, initialisiert das BIOS (Basic Input/Output System) die CPU, den Hauptspeicher und die Plattform-Hardware. Nach dem Abschluss der Initialisierung lädt das BIOS vom konfiguierten Boot-Gerät den Boot-Loader und gibt die Systemsteuerung an ihn.

GRUB ist ein Open Source Boot-Loader mit einer einfachen Menüschnittstelle mit Boot-Optionen, die in einer Konfigurationsdatei gespeichert sind. GRUB besitzt darüber hinaus auch eine Befehlszeilenschnittstelle, die zum Ausführen verschiedener Boot-Befehle von der Menüoberfläche aus aufgerufen werden kann. Im Betriebssystem Solaris hält die GRUB-Implementierung die Vorschriften der Multiboot-Spezifikation ein. Diese Spezifikation wird ausführlich unter http://www.gnu.org/software/grub/grub.html beschrieben.

Da der Solaris-Systemkern die Multiboot-Spezifikation vollständig einhält, kann ein x86-basiertes Solaris-System mit GRUB gebootet werden. Mit GRUB können mehrere Betriebssysteme auf einem System einfach installiert und gebootet werden. Auf einem System können Sie beispielsweise die folgenden Betriebssysteme individuell booten:

• Solaris OS

• Microsoft Windows

  ---

  Hinweis –

  GRUB erkennt Microsoft Windows-Partitionen, kann jedoch nicht überprüfen, ob das Betriebssystem geladen werden kann.

  ---

Der Hauptvorteil von GRUB besteht darin, dass er Dateisysteme und ausführbare Systemkernformate intuitiv erkennt, sodass Sie ein Betriebssystem booten können, ohne dessen physische Position im Systemkern der Festplatte kennen zu müssen. Beim GRUB-basierten Booten wird der Systemkern eines Betriebssystems durch Angabe des Dateinamens, des Laufwerks und der Partition, auf der sich der Systemkern befindet, geladen. Das GRUB-basierte Booten löst den Solaris-Gerätekonfigurationsassistent ab und vereinfacht mit dem GRUB-Menü den Boot-Vorgang.

x86: Wie funktioniert GRUB-basiertes Booten ?

Nachdem GRUB die Systemsteuerung übernommen hat, wird auf der Konsole ein Menü angezeigt. Im GRUB-Menü stehen Ihnen folgende Möglichkeiten zur Verfügung:

• Auswahl eines Menüeintrags zum Booten des entsprechenden Betriebssystems

• Ändern eines Boot-Eintrags mit dem GRUB-Bearbeitungsmenü

• Manuelles Laden eines Betriebssystemkerns über die Befehlszeile

Es ist möglich, ein Timeout festzulegen. Wurde in diesem Zeitraum nichts eingegeben, wird das als Standardsystem festgelegte Betriebssystem gebootet. Durch Drücken einer beliebigen Taste wird das Booten des standradmäßigen Betriebssystems abgebrochen.

Ein Beispiel für ein GRUB-Menü finden Sie im Abschnitt Beschreibung des GRUB-Hauptmenüs.

x86: Konventionen für Gerätenamen in GRUB

Die Namenskonventionen für Geräte, die in GRUB verwendet werden, unterscheiden sich etwas von den in früheren Solaris-Versionen verwendeten Konventionen. Wenn Ihnen die in GRUB verwendeten Namenskonventionen für Geräte klar sind, sind Sie in der Lage, Laufwerks- und Partitionsinformationen ordnungsgemäß anzugeben, wenn Sie GRUB auf Ihrem System konfigurieren.

In der folgenden Tabelle sind die GRUB-Namenskonventionen für Geräte beschrieben.

Alle GRUB-Gerätenamen sind in runden Klammern anzugeben. Partitionen werden von 0 (null) und nicht von 1 an gezählt.

Weitere Informationen zu fdisk-Partitions finden Sie in Guidelines for Creating an fdisk Partition in System Administration Guide: Devices and File Systems.

x86: Wo finde ich Informationen zu GRUB-basierten Installationen?

Weitere Informationen zu diesen Neuerungen finden Sie in den folgenden Ressourcen:

x86: GRUB-basiertes Booten (Planung)

In diesem Abschnitt werden die Grundlagen des GRUB-basierten Bootens und das GRUB-Menü beschrieben.

Bei der Installation des Betriebssystems Solaris werden standardmäßig zwei GRUB-Menüeinträge erstellt. Der erste Eintrag ist für das Betriebssystem Solaris. Der zweite Eintrag ist für das Failsafe-Bootarchiv, das zur Wiederherstellung des Systems dient. Die Solaris-Einträge des GRUB-Menüs werden als Teil des Installations- bzw. Upgrade-Vorgangs automatisch installiert bzw. aktualisiert. Diese Einträge werden direkt vom Betriebssystem verwaltet und sollten nicht manuell geändert werden.

Während einer Solaris-Standardinstallation wird GRUB in der fdisk-Partition von Solaris installiert, ohne dass dafür die entsprechende BIOS-Systemeinstellung geändert wird. Falls sich das Betriebssystem nicht auf der BIOS-Bootplatte befindet, müssen Sie einen der folgenden Schritte ausführen:

• Ändern der BIOS-Einstellung.

• Mit einem Boot-Manager einen Bootstrap auf die Solaris-Partition durchführen. Ausführlichere Informationen finden Sie in der Dokumentation Ihres Boot-Managers.

Es wird empfohlen, das Betriebssystem Solaris auf der Boot-Platte zu installieren. Wenn auf dem Rechner mehrere Betriebssysteme installiert sind, können Sie der Datei menu.lst Einträge hinzufügen. Diese Einträge werden dann beim nächsten Booten des Systems im GRUB-Menü angezeigt.

Weitere Informationen zur Installation mehrerer Betriebssysteme auf einem Rechner finden Sie in How Multiple Operating Systems Are Supported in the GRUB Boot Environment in System Administration Guide: Basic Administration.

x86: Booten einer GRUB-basierten Installation über das Netzwerk

Für das GRUB-basierte Booten über das Netzwerk benötigen Sie einen für PXE-Clients konfigurierten DHCP-Server sowie einen Installationsserver, der den tftp-Dienst bereitstellt. Der DHCP-Server muss die DHCP-Klassen PXEClient und GRUBClient erkennen können. In den vom DHCP-Server zurückgelieferten Daten müssen die folgenden Informationen enthalten sein:

• IP-Adresse des Dateiservers

• Name der Boot-Datei (pxegrub)

Für das GRUB-basierte Booten über das Netzwerk ist die Datei rpc.bootparamd, die normalerweise vom Server für das Booten über das Netzwerk benötigt wird, nicht erforderlich.

Wenn kein PXE- bzw. DHCP-Server verfügbar ist, können Sie GRUB von CD-ROM oder einer lokalen Festplatte laden. Dann können Sie das Netzwerk in GRUB manuell konfigurieren und das Multiboot-Programm sowie das Boot-Archiv vom Dateiserver herunterladen.

Weitere Informationen finden Sie in Überblick über das Booten und Installieren über das Netzwerk mit PXE in Solaris 10 11/06 Installationshandbuch: Netzwerkbasierte Installation.

Beschreibung des GRUB-Hauptmenüs

Beim Booten eines x86-basierten Systems wird das GRUB-Menü angezeigt. In diesem Menü kann ein gewünschter Eintrag ausgewählt werden. Unter einem Boot-Eintrag versteht man eine auf Ihrem System installierte Instanz eines Betriebssystems. Das GRUB-Menü liest die Einträge in der Konfigurationsdatei menu.lst. Die Datei menu.lst wird vom Solaris-Installationsprogramm erstellt und kann nach der Installation bearbeitet werden. In der Datei menu.lst wird festgelegt, welche Betriebssysteminstanzen im GRUB-Menü angezeigt werden.

• Wenn Sie das Betriebssystem Solaris installieren bzw. ein Upgrade durchführen, wird das GRUB-Menü automatisch aktualisiert. Das Betriebssystem Solaris wird dann als neuer Boot-Eintrag angezeigt.

• Wenn Sie außer Solaris noch andere Betriebssysteme installieren, müssen Sie die Konfigurationsdatei menu.lst entsprechend ändern, damit die anderen Betriebssysteminstanzen angezeigt werden. Durch das Hinzufügen einer Betriebssysteminstanz erscheint deren Eintrag beim nächsten Booten des Systems im GRUB-Menü.

Beispiel 6–1 GRUB-Hauptmenü

Im folgenden Beispiel enthält das GRUB-Hauptmenü Einträge für die Betriebssysteme Solaris und Microsoft Windows. Außerdem ist noch eine Boot-Umgebung für Solaris Live Upgrade namens second_disk aufgeführt. Im Folgenden wird jeder Menüeintrag beschrieben.

GNU GRUB version 0.95 (616K lower / 4127168K upper memory)
+-------------------------------------------------------------------+
|Solaris                                                            |
|Solaris failsafe                                                   |
|second_disk                                                        |
|second_disk 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

Das Betriebssystem Solaris.

Solaris failsafe

Ein Boot-Archiv, mit dem das System wiederhergestellt werden kann, wenn das Betriebssystem Solaris beschädigt wurde.

second_disk

Die Boot-Umgebung von Solaris Live Upgrade. Die Boot-Umgebung second_disk wurde als Kopie des Betriebssystems Solaris erstellt. Sie wurde mit dem Befehl luactivate aktualisiert und aktiviert. Mit dieser Boot-Umgebung kann das System gebootet werden.

Windows

Das Betriebssystem Microsoft Windows. GRUB erkennt Microsoft Windows-Partitionen, kann jedoch nicht überprüfen, ob das Betriebssystem geladen werden kann.

Beschreibung der GRUB-Datei menu.lst

Die GRUB-Datei menu.lst enthält den Inhalt des GRUB-Hauptmenüs. Im GRUB-Hauptmenü sind alle auf Ihrem System installierten Betriebssysteminstanzen (einschließlich Boot-Umgebungen für Solaris Live Upgrade) als Boot-Einträge aufgeführt. Beim Durchführen von Upgrades für das Betriebssystem Solaris werden alle Änderungen, die Sie an dieser Datei vorgenommen haben, gespeichert.

Alle an der Datei menu.lst vorgenommenen Änderungen (einschließlich der Änderungen an Solaris Live Upgrade-Einträgen) erscheinen entsprechend im GRUB-Hauptmenü. Diese Änderungen werden beim nächsten Booten des Systems wirksam. Sie können an dieser Datei zu folgenden Zwecken Änderungen vornehmen:

• Hinzufügen von Boot-Einträgen für andere Betriebssysteme außer Solaris

• Anpassen des Boot-Verhaltens (z. B. Angeben eines standardmäßig zu bootenden Betriebssystems im GRUB-Menü)

Einträge für Solaris Live Upgrade dürfen nicht in der GRUB-Datei menu.lst geändert werden. Durch solche Änderungen kann Solaris Live Upgrade fehlschlagen.

Obwohl das Boot-Verhalten in der Datei menu.lst angepasst werden kann (z. B. Booten mit dem Systemkern-Debugger), sollte dafür jedoch der Befehl eeprom verwendet werden. Wenn Sie das Boot-Verhalten durch Modifizieren der Datei menu.lst anpassen, kann es sein, dass die Solaris-Einträge während eines Solaris-Upgrades geändert werden Die an dieser Datei von Ihnen vorgenommenen Änderungen gehen dann verloren.

Informationen zur Verwendung des Befehls eeprom finden Sie in How to Set Solaris Boot Parameters by Using the eeprom Command in System Administration Guide: Basic Administration.

Beispiel 6–2 Datei Menu.lst

Hier ist ein Beispiel für die Datei 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
#----- second_disk - ADDED BY LIVE UPGRADE - DO NOT EDIT  -----
title second_disk
  root (hd0,1,a)
  kernel /platform/i86pc/multiboot
  module /platform/i86pc/boot_archive
title second_disk failsafe
  root (hd0,1,a)
  kernel /boot/multiboot kernel/unix -s
  module /boot/x86.miniroot-safe
#----- second_disk -------------- END LIVE UPGRADE ------------
title Windows
  root (hd0,0)
  chainloader -1

default

Legt fest, welche Betriebssysteminstanz nach Ablauf des Timeouts gebootet werden soll. Zum Ändern der Standardeinstellung können Sie die nach diesem Parametern angegebene Zahl entsprechend ändern. Der erste unter “title” erscheinende Eintrag besitzt die Nummer 0. Sie können die Standardeinstellung beispielsweise auf 2 ändern, damit nach Ablauf des Timeouts die unter second_disk erscheinende Boot-Umgebung gebootet wird.

timeout

Legt fest, wie lange der Boot-Loader auf eine Benutzereingabe warten soll, ehe die unter “default” als Standard festgelegte Betriebssysteminstanz gebootet wird. Wenn kein Timeout angegeben ist, muss der Benutzer immer auswählen, welche Betriebssysteminstanz gebootet wird.

title Name_des_Betriebssystems

Legt den beschreibenden Namen des Betriebssystems fest.

• Falls es sich bei dem Eintrag um eine Boot-Umgebung für Solaris Live Upgrade handelt, ist der Parameter Name_des_Betriebssystems der Name, den Sie der neuen Boot-Umgebung bei ihrer Erstellung gegeben haben. Im obigen Beispiel heißt die Boot-Umgebung für Solaris Live Upgrade second_disk.

• Wenn es sich dabei um ein Failsafe-Bootarchiv handelt, dient diese Instanz zur Wiederherstellung des Systems, falls das primäre Betriebssystem beschädigt wurde. Im obigen Beispiel sind die Einträge Solaris failsafe und second_disk failsafe die Boot-Archive für die Wiederherstellung der Betriebssysteminstanzen Solaris und second_disk.

root (hd0,0,a)

Legt fest, von welcher Festplatte, Partition und welchem Bereich Dateien geladen werden sollen. GRUB erkennt den Typ des Dateisystems automatisch.

kernel /platform/i86pc/multiboot

Das Multiboot-Programm. Nach dem Befehl “kernel” muss stets unmittelbar der Name des Multiboot-Programms folgen. Die nach dem Befehl “kernel” angegebene Zeichenkette wird direkt an das Betriebssystem Solaris ohne Zwischenverarbeitung weitergegeben.

Eine vollständige Beschreibung zur Installation mehrerer Betriebssysteme auf einem Rechner finden Sie in How Multiple Operating Systems Are Supported in the GRUB Boot Environment in System Administration Guide: Basic Administration.

Auffinden der Datei menu.lst zum Ändern des GRUB-Menüs

Zum Auffinden der Datei menu.lst des GRUB-Menüs müssen Sie stets den Befehl bootadm verwenden. Der Unterbefehl list-menu dieses Befehls sucht das aktive GRUB-Menü. In der Datei menu.lst sind alle im System installierten Betriebssysteme aufgeführt. Der Inhalt dieser Datei legt fest, welche Betriebssysteme im GRUB-Hauptmenü erscheinen. Informationen zum Vornehmen von Änderungen an dieser Datei finden Sie in Auffinden der Datei menu.lst des GRUB-Menüs (Vorgehen) in Solaris 10 11/06 Installationshandbuch: Solaris Live Upgrade und Planung von Upgrades.

Kapitel 7 Upgrading When Solaris Zones Are Installed on a System (Planning)

This chapter provides an overview of how Solaris Zones partitioning technology relates to upgrading the Solaris OS when non-global zones are configured.

Dieses Kapitel enthält die folgenden Abschnitte:

• Solaris Zones (Übersicht)

• Durchführen von Upgrades auf Systemen mit installierten nicht-globalen Zonenl

• Erforderlicher Festplattenspeicher für nicht-globale Zonen

Solaris Zones (Übersicht)

For complete information on overview, planning, creating and configuring zones, see Kapitel 16, Introduction to Solaris Zones in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones.

Die Partitionierungstechnologie Solaris Zones dient zum Virtualisieren von Betriebssystemdiensten und Bereitstellen einer isolierten, sicheren Umgebung zum Ausführen von Anwendungen. Als nicht-globale Zone wird eine virtualisierte Betriebssystemumgebung bezeichnet, die mit einer einzigen Instanz des Betriebssystems Solaris erstellt wurde. Indem Sie eine nicht-globale Zone erstellen, erzeugen Sie eine Umgebung für die Ausführung von Anwendungen, in der Prozesse vom übrigen System isoliert sind. Durch diese Isolierung wird verhindert, dass Prozesse, die in der nicht-globalen Zone laufen, Prozesse in anderen nicht-globalen Zonen überwachen bzw. sich auf diese auswirken können. Selbst ein in einer Zone laufender Prozess mit Superuser-Berechtigungsnachweisen kann die Aktivität in anderen Zonen weder verfolgen noch beeinflussen. Eine nicht-globale Zone bietet darüber hinaus eine abstrakte Schicht, durch die Anwendungen von den physikalischen Attributen des Rechners, auf dem sie laufen, getrennt werden. Zu solchen Attributen zählen beispielsweise physische Pfade.

Jedes Solaris-System enthält eine globale Zone. Diese globale Zone besitzt zwei Funktionen. Die globale Zone gilt sowohl als Standardzone des Systems als auch als Zone für die systemweite Administrationssteuerung. Alle Prozesse werden in der globalen Zone ausgeführt, sofern vom globalen Administrator keine nichtglobalen Zonen erstellt wurden. Die globale Zone ist die einzige Zone, von der aus sich nicht-globale Zonen konfigurieren, installieren, verwalten und deinstallieren lassen. Über die Systemhardware kann nur die globale Zone gebootet werden. Die Verwaltung der Systeminfrastruktur, wie beispielsweise physische Geräte, das Routing oder die dynamische Rekonfiguration (DR), ist nur in der globalen Zone möglich. Prozesse, die in der globalen Zone laufen und die entsprechenden Zugriffsrechte besitzen, haben Zugang zu Objekten in nicht-globalen Zonen.

Durchführen von Upgrades auf Systemen mit installierten nicht-globalen Zonen

Nach der Installation des Betriebssystems Solaris können nicht-globale Zonen installiert und konfiguriert werden. Wenn für das Betriebssystem Solaris ein Upgrade durchgeführt werden soll, können auch die nicht-globalen Zonen entsprechend aktualisiert werden. Ein Upgrade kann mit dem interaktiven Solaris-Installationsprogramm sowie benutzerspezifischen JumpStart-Programmen durchgeführt werden.

• Mit dem interaktiven Solaris-Installationsprogramm können Sie ein Upgrade auf einem System mit installierten nicht-globalen Zonen durchführen, indem Sie in den Fenstern Upgrade auswählen bzw. Neuinstallation die Installationsart Upgrade auswählen. Das Installationsprogramm analysiert dann das System, um zu sehen, ob dafür ein Upgrade durchgeführt werden kann, und zeigt einen Überblick dieser Analyse an. Anschließend fordert Sie das Installationsprogramm auf, mit dem Upgrade fortzufahren. Dieses Programm kann mit den folgenden Einschränkungen verwendet werden:

  • Upgrades können nicht benutzerspezifisch angepasst werden. Das bedeutet, dass Sie zum Beispiel keine zusätzlichen Softwarepakete oder Sprachumgebungen installieren und das Festplatten-Layout nicht ändern können.

  • Dafür ist die Solaris Operating System DVD oder ein DVD-basiertes Netzwerkinstallationsabbild zu verwenden. Das Upgrade kann nicht mit den Solaris Software CDs durchgeführt werden. For more information about installing with this program, see Kapitel 2, Installation mit dem Solaris-Installationsprogramm (Vorgehen) in Solaris 10 11/06 Installationshandbuch: Grundinstallation.

• Wenn Sie das benutzerspezifische JumpStart-Installationsprogramm verwenden, kann das Upgrade nur mit den Schlüsselwörtern install_type und root_device durchgeführt werden.

  Da sich einige Schlüsselwörter auf nicht-globale Zonen auswirken, dürfen sie nicht im Profil enthalten sein. Zu den Schlüsselwörtern, die sich auf nicht-globale Zonen auswirken, gehören beispielsweise die zum Hinzufügen von Packages, Neuzuweisen von Speicherplatz oder Hinzufügen von Sprachumgebungen. Wenn Sie diese Schlüsselwörter angeben, werden sie entweder ignoriert oder verursachen ein Fehlschlagen des JumpStart-Upgrades. For a list of these keywords, see Einschränkungen bei Profilschlüsselwörtern bei Upgrades mit nicht-globalen Zonen in Solaris 10 11/06 Installationshandbuch: Benutzerdefinierte JumpStart-Installation und komplexe Installationsszenarien.

Sichern Ihres Systems vor dem Durchführen eines Upgrades mit Zonen

Vor dem Durchführen eines Upgrades sollten Sie die globale Zone sowie alle nicht-globalen Zonen Ihres Solaris-Systems sichern. For information about backing up a system with zones installed, see Kapitel 26, Solaris Zones Administration (Overview) in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones.

Erforderlicher Festplattenspeicher für nicht-globale Zonen

Bei der Installation der globalen Zone müssen Sie genügend Speicherplatz für die später zu installierenden nicht-globalen Zonen reservieren. Jede nicht-globale Zone hat unter Umständen einen ganz eigenen Festplattenspeicherbedarf.

Es gilt keine grundsätzliche Beschränkung des Festplattenspeichers, der einer Zone zugewiesen werden darf. Für die Platzbeschränkung ist allein der Administrator der globalen Zone zuständig. Selbst ein kleines System mit nur einem Prozessor ist in der Lage, mehrere gleichzeitig ausgeführte Zonen zu unterstützen. Die Art der in der globalen Zone installierten Packages wirkt sich auf den Speicherplatzbedarf für die nicht-globalen Zonen aus. Dabei sind die Package-Anzahl sowie der jeweilige Speicherplatzbedarf maßgebende Faktoren.

In Kapitel 18, Planning and Configuring Non-Global Zones (Tasks) in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones finden Sie sämtliche Anforderungen und Empfehlungen für die Planung.

Kapitel 8 Erstellen von RAID-1-Volumes (Mirrors) bei der Installation (Überblick)

In diesem Kapitel werden die Vorteile der Verwendung von RAID-1 volumes (Mirrors) für das Root-Dateisystem (/) erläutert. Darüber hinaus werden in diesem Kapitel die zum Erstellen gespiegelter Dateisysteme benötigten Solaris Volume Manager-Komponenten beschrieben. Er umfasst die folgenden Themen:

• Warum RAID-1-Volumes?

• Funktionsweise von RAID-1-Volumes

• Überblick der Solaris Volume Manager-Komponenten

• Beispiel-Festplattenlayout für ein RAID-1-Volume

Zusätzliche Informationen zu Solaris Live Upgrade bzw. JumpStart finden Sie in:

• Solaris Live Upgrade: Allgemeine Richtlinien zur Erstellung von RAID-1-Volume-Dateisystemen (gespiegelten Dateisystemen) in Solaris 10 11/06 Installationshandbuch: Solaris Live Upgrade und Planung von Upgrades

• JumpStart:

  • filesys-Profilschlüsselwort (Erstellen von RAID-1-Volumes) in Solaris 10 11/06 Installationshandbuch: Benutzerdefinierte JumpStart-Installation und komplexe Installationsszenarien

  • metadb-Profilschlüsselwort (Erstellen von Statusdatenbankreplikationen) in Solaris 10 11/06 Installationshandbuch: Benutzerdefinierte JumpStart-Installation und komplexe Installationsszenarien

Warum RAID-1-Volumes?

Während der Installation oder des Upgrades haben Sie die Möglichkeit, RAID-1-Volumes zu erstellen, um Ihre Systemdaten auf mehreren physischen Festplatten zu duplizieren. Indem Sie Ihre Daten auf mehrere separate Festplatten identisch kopieren, schützen Sie sie vor Festplattenschäden oder -ausfällen.

Beim benutzerdefinierten JumpStart- sowie dem Solaris Live Upgrade-Installationsverfahren kommt zum Erstellen von RAID-1-Volumes für gespiegelte Dateisysteme die Solaris Volume Manager-Technologie zum Einsatz. Solaris Volume Manager bietet einen leistungsfähigen Ansatz zur zuverlässigen Verwaltung Ihrer Festplatten und Daten: den Einsatz von Volumes. Solaris Volume Manager ermöglicht Verkettungen (Concatenations), Striping und andere komplexe Konfigurationen. Das benutzerdefinierte JumpStart- sowie das Solaris Live Upgrade-Installationsverfahren ermöglichen einige dieser Vorgänge, wie zum Beispiel das Erstellen eines RAID-1-Volumes für das Root-Dateisystem (/). Um diese Schritte nicht nach der Installation gesondert durchführen zu müssen, können Sie schon während der Installation oder des Upgrades RAID-1-Volumes erstellen.

• Diesbezügliche Richtlinien finden Sie unter Richtlinien für das benutzerdefinierte JumpStart-Verfahren und Solaris Live Upgrade.

• Ausführliche Informationen zur Solaris Volume Manager-Software und ihren Komponenten entnehmen Sie bitte dem Dokument Solaris Volume Manager Administration Guide.

Funktionsweise von RAID-1-Volumes

Solaris Volume Manager nutzt zum Verwalten physischer Platten und deren Daten virtuelle Platten. In Solaris Volume Manager wird eine virtuelle Festplatte als Volume bezeichnet. Ein Volume ist ein Name für eine Gruppe physischer Slices, die das System als ein logisches Gerät auffasst. In der UNIX®-Standardterminologie handelt es sich bei Volumes eigentlich um Pseudo- oder virtuelle Geräte.

Aus der Sicht einer Anwendung oder eines Dateisystems (z. B. UFS) sind Volumes, was ihre Funktionsweise angeht, mit einer physischen Festplatte identisch. Solaris Volume Manager konvertiert E/A-Anforderungen an ein Volume in E/A-Anforderungen an die Festplatten, die das Volume bilden. Solaris Volume Manager-Volumes setzen sich aus Slices (Festplattenpartitionen) oder anderen Solaris Volume Manager-Volumes zusammen.

Volumes dienen zur Steigerung der Systemleistung und Datenverfügbarkeit. Unter Umständen kann der Einsatz von Volumes auch die E/A-Leistung verbessern. Aus funktioneller Sicht verhalten sich Volumes genau wie Slices. Da Volumes wie Slices dargestellt werden, sind sie sowohl für die Endbenutzer als auch für Anwendungen und Dateisysteme transparent. Wie im Fall von physischen Geräten können Sie mit der Solaris Volume Manager-Software auch auf Volumes über blockorientierte oder Raw-Gerätenamen zugreifen. Dabei ist der Volume-Name davon abhängig, ob das blockorientierte oder das Raw-Gerät verwendet wird. Sowohl das benutzerdefinierte JumpStart-Installationsverfahren als auch Solaris Live Upgrade unterstützen den Einsatz von blockorientierten Geräten für die Erstellung von gespiegelten Dateisystemen. Näheres über Volume-Namen finden Sie im Abschnitt Voraussetzungen für RAID-Volume-Namen und Richtlinien für das benutzerdefinierte JumpStart-Verfahren sowie für Solaris Live Upgrade.

Beim Erstellen von RAID-1 Volumes mit RAID-0 Volumes (Einzel-Slice-Verkettung), kopiert Solaris Volume Manager Daten in die RAID-0 Submirrors und behandelt diese Submirrors als ein Volume.

Abbildung 8–1 zeigt einen Mirror, der das Root (/)-Dateisystem auf zwei physischen Festplatten dupliziert.

Abbildung 8–1 Erstellen von RAID-1-Volumes für das Root-Dateisystem (/) auf zwei Festplatten

Abbildung 8–1 zeigt ein System mit der folgenden Konfiguration.

• Der Mirror namens d30 besteht aus den beiden Submirrors d31 und d32. Im Mirror d30werden die Daten des Root-Dateisystems (/) auf beiden Submirrors identisch gespeichert.

• Das Root-Dateisystem (/) auf hdisk0 ist in der Einzel-Slice-Verkettung namens d31 enthalten.

• Das Root-Dateisystem(/) wird auf die Festplatte hdisk1 kopiert. Diese Kopie stellt eine Einzel-Slice-Verkettung namens d32 dar.

Überblick der Solaris Volume Manager-Komponenten

Sowohl mit dem benutzerdefinierten JumpStart-Installationsverfahren als auch mit Solaris Live Upgrade können Sie die folgenden Komponenten erzeugen, die für die Spiegelung bzw. Replikation von Daten erforderlich sind.

• Statusdatenbank und Statusdatenbankreplikationen (metadbs)

• RAID-1 Volumes (Mirrors) mit Einzel-Slice-Verkettungen (Submirrors)

Dieser Abschnitt bietet eine kurze Beschreibung dieser Komponenten. Umfassende Informationen zu diesen Komponenten entnehmen Sie bitte dem Dokument Solaris Volume Manager Administration Guide.

Statusdatenbank und Statusdatenbankreplikationen

Statusdatenbanken speichern Informationen auf einer physischen Platte. Änderungen an der Konfiguration werden in der Statusdatenbank aufgezeichnet. Solaris Volume Manager aktualisiert die Statusdatenbank im Fall einer Konfigurations- oder Statusänderung automatisch. Die Erstellung eines neuen Volumes ist ein Beispiel für eine Konfigurationsänderung. Ein Beispiel für eine Statusänderung ist der Ausfall eines Submirrors.

Tatsächlich besteht die Statusdatenbank aus einer Sammlung mehrerer Datenbankkopien. Die Daten in jeder Datenbankkopie, die als Statusdatenbankreplikationen bezeichnet werden, sind stets gültig. Die Kopien der Statusdatenbank bedeuten einen Schutz gegen Datenverlust durch Redundanz. Die Statusdatenbank überwacht und speichert Angaben zu Speicherort und Status aller bekannten Statusdatenbankreplikationen.

Solange Sie die Statusdatenbank und ihre Statusdatenbankreplikationen nicht erzeugt haben, kann Solaris Volume Manager nicht betrieben werden. Eine Solaris Volume Manager-Konfiguration muss über eine funktionierende Statusdatenbank verfügen.

Die Statusdatenbankreplikationen gewährleisten, dass die Daten in der Statusdatenbank stets gültig sind. Bei einer Aktualisierung der Statusdatenbank werden immer auch alle Statusdatenbankreplikationen aktualisiert. Damit im Fall eines Systemabsturzes nicht sämtliche Aktualisierungen beschädigt werden, erfolgen die Aktualisierungen nacheinander.

Wenn Ihr System eine Statusdatenbankreplikation verliert, muss Solaris Volume Manager feststellen, welche Replikationen weiterhin gültige Daten enthalten. Dazu verwendet Solaris Volume Manager einen Mehrheitsentscheidungsalgorithmus. Dieser Algorithmus fordert, dass die Mehrheit (die Hälfte + 1) der Statusdatenbankreplikationen verfügbar sein und übereinstimmen muss, bevor eine der Kopien als gültig erklärt wird. Aufgrund dieses Verfahrens der Mehrheitsentscheidung (auch Mehrheits-Votieren) müssen Sie bei der Einrichtung Ihrer Festplattenkonfiguration mindestens drei Statusdatenbankreplikationen erstellen. Um eine „Entscheidung“ zu erreichen, müssen mindestens zwei von drei Statusdatenbanken verfügbar sein.

Jede Statusdatenbankreplikation belegt standardmäßig 4 MB (8192 Plattensektoren) Festplattenspeicherplatz. Replikationen können auf folgenden Geräten gespeichert werden:

• Einem dedizierten, lokalen Festplatten-Slice

• nur Solaris Live Upgrade:

  • Ein lokales Slice, das zu einem Volume gehört

  • Ein lokales Slice, das zu einem UFS-Protokollgerät gehört

Replikationen können hingegen nicht auf Root- (/), Swap-, /usr-Slices oder Slices mit bereits vorhandenen Dateisystemen oder Daten erstellt werden. Nachdem die Replikationen gespeichert wurden, können auf denselben Slices Volumes oder Dateisysteme erzeugt werden.

Auf einem Slice können mehrere Kopien einer Statusdatenbank hergestellt werden. Aufgrund der geringeren Redundanz wird das System durch die Anordnung mehrerer Statusdatenbankreplikationen auf einem einzigen Slice jedoch in gewisser Hinsicht unsicherer.

RAID-1-Volumes (Mirrors)

Ein RAID-1-Volume oder Mirror ist ein Volume, das identische Kopien der Daten auf RAID-0-Volumes (Einzel-Slice-Verkettungen) enthält. Nach der Konfiguration kann ein RAID-1-Volume genau wie ein physisches Slice verwendet werden. Sie können beliebige, einschließlich bereits vorhandener, Dateisysteme spiegeln. Außerdem können Sie RAID-1-Volumes für beliebige Anwendungen wie z. B. Datenbanken einsetzen.

Die Spiegelung von Dateisystemens mit RAID-1 Volumes hat Vor- und Nachteile:

• Mit RAID-1-Volumes können Daten von beiden RAID-0-Volumes gleichzeitig gelesen werden (jedes Volume kann beliebige Anforderungen abarbeiten), wodurch eine Steigerung der Leistung erzielt wird. Sollte eine physische Festplatte ausfallen, funktioniert der Mirror ohne Leistungseinbußen oder Datenverlust weiter.

• Die Verwendung von RAID-1 Volumes erfordert eine gewisse Investition an Festplatten. Sie benötigen Festplattenspeicherplatz von mindestens dem Doppelten des zu spiegelnden Datenumfangs.

• Da die Solaris Volume Manager-Software auf alle RAID-0-Volumes schreiben muss, kann die Spiegelung außerdem die Dauer von Schreibanforderungen verlängern.

RAID-0-Volumes (Verkettungen, Concatenations)

Einzel-Slice-Verkettungen werden als RAID-0 Volume bezeichnet. Unter einer Verkettung versteht man ein Volume, dessen Daten seriell und nebeneinander über Komponenten verteilt sind, die eine logische Speichereinheit bilden. Stripes oder andere komplexe Solaris Volume Manager-Volumes lassen sich weder mit dem benutzerdefinierten JumpStart-Installationsverfahren noch mit Solaris Live Upgrade erzeugen.

Während der Installation bzw. des Upgrades können Sie RAID-1-Volumes (Mirrors, dtsch. Spiegel) erzeugen und diesen Mirrors RAID-0-Volumes hinzufügen. Die gespiegelten RAID-0-Volumes heißen Submirrors (dtsch. Teilspiegel). Ein Mirror besteht aus einem oder mehreren RAID-0-Volumes. Nach der Installation können Sie durch Administration des RAID-1-Mirror-Volumes mit der Solaris Volume Manager-Software die Daten auf separaten RAID-0-Submirror-Volumes verwalten.

Das benutzerdefinierte JumpStart-Installationsverfahren bietet Ihnen die Möglichkeit, Mirrors aus bis zu zwei Submirrors zu erzeugen. Mit Solaris Live Upgrade können Sie Mirrors erzeugen, die bis zu drei Submirrors enthalten. Ein zweiteiliger Mirror ist in der Regel ausreichend. Ein dritter Submirror ermöglicht die Durchführung von Sicherungen bei laufendem Betrieb ohne Verzicht auf Datenredundanz, während einer der Submirrors für die Dauer der Sicherung außer Betrieb genommen wird.

Beispiel-Festplattenlayout für ein RAID-1-Volume

Die folgende Abbildung zeigt ein RAID-1-Volume, bei dem das Root-Dateisystem (/) auf zwei physischen Festplatten gespiegelt wird. Die Statusdatenbankreplikationen (metadbs) sind auf beide Festplatten verteilt.

Abbildung 8–2 Festplattenlayout für ein RAID-1-Volume

Abbildung 8–2 zeigt ein System mit der folgenden Konfiguration.

• Der Mirror namens d30 besteht aus den beiden Submirrors d31 und d32. Im Mirror d30werden die Daten des Root-Dateisystems (/) auf beiden Submirrors identisch gespeichert.

• Das Root-Dateisystem (/) auf hdisk0 ist in der Einzel-Slice-Verkettung namens d31 enthalten.

• Das Root-Dateisystem(/) wird auf die Festplatte hdisk1 kopiert. Diese Kopie stellt eine Einzel-Slice-Verkettung namens d32 dar.

• Auf beiden Slices werden Statusdatenbankreplikationen erstellt: hdisk0 und hdisk1.

Kapitel 9 Erzeugen von RAID-1-Volumes (Mirrors) während der Installation (Planung)

Dieses Kapitel enthält eine Beschreibung der Voraussetzungen und Richtlinien für die Erstellung von RAID-1-Volumes mithilfe des benutzerdefinierten JumpStart- und des Solaris Live Upgrade-Installationsverfahrens.

Er umfasst die folgenden Themen:

• Systemvoraussetzungen

• Richtlinien und Voraussetzungen für Statusdatenbankreplikationen

• Voraussetzungen und Richtlinien für RAID-1- und RAID-0-Volumes

• Durch das Booten in den Einzelbenutzermodus wird irrtümlich gemeldet, dass ein Mirror gewartet werden muss

Zusätzliche Informationen zu Solaris Live Upgrade bzw. JumpStart finden Sie in:

• Solaris Live Upgrade: Allgemeine Richtlinien zur Erstellung von RAID-1-Volume-Dateisystemen (gespiegelten Dateisystemen) in Solaris 10 11/06 Installationshandbuch: Solaris Live Upgrade und Planung von Upgrades

• JumpStart:

  • filesys-Profilschlüsselwort (Erstellen von RAID-1-Volumes) in Solaris 10 11/06 Installationshandbuch: Benutzerdefinierte JumpStart-Installation und komplexe Installationsszenarien

  • metadb-Profilschlüsselwort (Erstellen von Statusdatenbankreplikationen) in Solaris 10 11/06 Installationshandbuch: Benutzerdefinierte JumpStart-Installation und komplexe Installationsszenarien

Systemvoraussetzungen

Um RAID-1-Volumes auf bestimmten Slices zu erstellen, müssen die für die Spiegelung vorgesehenen Festplatten während der Installation direkt an das System angeschlossen und dem System zugänglich sein.

Richtlinien und Voraussetzungen für Statusdatenbankreplikationen

Zur Vermeidung von Datenverlust durch den Ausfall einzelner Komponenten empfiehlt es sich, die verschiedenen Statusdatenbankreplikationen über Slices, Laufwerke und Controller zu verteilen. Ziel ist es, dass die Mehrheit der Replikationen den Ausfall einer einzelnen Komponente schadlos übersteht. Wenn Sie beispielsweise durch den Ausfall eines Geräts eine Replikation verlieren, können sich Probleme bei der Ausführung der Solaris Volume Manager-Software oder beim Neustarten des Systems ergeben. Um ausgeführt werden zu können, benötigt Solaris Volume Manager mindestens die Hälfte, für einen Neustart im Mehrbenutzermodus aber die Mehrheit (die Hälfte plus eine) der Replikationen.

Ausführliche Informationen zur Erstellung und Verwaltung von Statusdatenbankreplikationen entnehmen Sie bitte dem Dokument Solaris Volume Manager Administration Guide.

Auswahl von Slices für Statusdatenbankreplikationen

Beachten Sie bei der Auswahl von Slices für Statusdatenbankreplikationen bitte die folgenden Richtlinien und Empfehlungen:

Wahl der Anzahl von Statusdatenbankreplikationen

Beachten Sie bei der Entscheidung über die Anzahl von Statusdatenbankreplikationen bitte die folgenden Richtlinien:

• Es wird eine Mindestanzahl von 3 und eine Höchstanzahl von 50 Statusdatenbankreplikationen pro Solaris Volume Manager-Diskset empfohlen. Empfohlene Richtlinien:

  • Für Systeme mit einem einzigen Laufwerk: Legen Sie alle drei Replikationen auf einem Slice an.

  • Für Systeme mit zwei bis vier Laufwerken: Erzeugen Sie in jedem Laufwerk zwei Replikationen.

  • Für Systeme mit fünf oder mehr Laufwerken: Erzeugen Sie auf jedem Laufwerk eine Replikation.

• Durch zusätzliche Statusdatenbankreplikationen lässt sich die Mirror-Leistung erhöhen. Im Allgemeinen müssen für jeden Mirror, den Sie einem System hinzufügen, zwei weitere Replikationen erzeugt werden.

• Bei RAID-1-Volumes, die für Direkt-E/A-Operationen mit kleinerem Datenumfang eingesetzt werden sollen (z. B. für eine Datenbank), ist die Anzahl der Replikationen zu bedenken. Um eine optimale Leistung zu gewährleisten, müssen pro RAID-1-Volume mindestens zwei zusätzliche Replikationen auf Slices (und wenn möglich auf Festplatten und Controllern) vorhanden sein, die nicht an das RAID-1-Volume angeschlossen sind.

Verteilung von Statusdatenbankreplikationen über mehrere Controller

Bei mehreren Controllern sollten die Replikationen möglichst gleichmäßig über alle Controller verteilt sein. Diese Strategie erzeugt Redundanz als Sicherheit bei Controller-Ausfällen und trägt zu einer Verteilung der Last bei. Sind mehrere Festplatten an einen Controller angeschlossen, sollte auf mindestens zwei Festplatten pro Controller eine Replikation gespeichert sein.

Voraussetzungen und Richtlinien für RAID-1- und RAID-0-Volumes

Beachten Sie für die Arbeit mit RAID-1-Volumes (Mirrors) und RAID-0-Volumes (Einzel-Slice-Verkettungen) bitte die nachfolgenden Richtlinien.

Richtlinien für das benutzerdefinierte JumpStart-Verfahren und Solaris Live Upgrade

Sowohl das benutzerdefinierte JumpStart-Installationsverfahren als auch Solaris Live Upgrade unterstützen einen Teil der Leistungsmerkmale der Solaris Volume Manager-Software. Wenn Sie mit diesen Installationsprogrammen gespiegelte Dateisysteme erstellen, beachten Sie bitte die folgenden Richtlinien.

Voraussetzungen für RAID-Volume-Namen und Richtlinien für das benutzerdefinierte JumpStart-Verfahren sowie für Solaris Live Upgrade

Beachten Sie beim Benennen von Volumes die folgenden Regeln.

• Wählen Sie eine Benennungsmethode, bei der die Slice- und die Festplattennummer den Volume-Nummern zugeordnet werden.

• Volume-Namen bestehen aus dem Buchstaben d, gefolgt von einer Zahl, z. B. d0.

• Für Solaris Volume Manager gelten 128 Standard-Volume-Namen von 0–127. Sehen Sie hier zwei Beispiele für Volume-Namen:

  • Gerät /dev/md/dsk/d0 – blockorientiertes Volume d0

  • Gerät /dev/md/dsk/d1 – blockorientiertes Volume d1

• Sehen Sie für jeden Volume-Typ einen eigenen Bereich vor. Weisen Sie beispielsweise RAID-1-Volumes die Zahlen 0–20 und RAID-0-Volumes die Zahlen 21–40 zu.

RAID-Volume-Namenskonventionen für Solaris Live Upgrade

Beim Erstellen von RAID-1- (Mirrors) und RAID-0-Volumes (Submirrors) mit Solaris Live Upgrade können Sie entweder die Software Namen für die Volumes ermitteln und sie ihnen zuweisen lassen, oder Sie weisen den Volumes selbst Namen zu. Wenn Sie die Ermittlung der Namen der Software überlassen, wird der erste verfügbare Mirror- bzw. Submirrorname verwendet. Wenn Sie selbst Namen zuweisen, wählen Sie Namen, die auf Null enden, sodass auf 1 und 2 endende Namen bei der Installation an Submirrors vergeben werden können. Sollten Sie die Namen von Submirrors selbst wählen, verwenden Sie auf 1 oder 2 endende Namen. Bei einer falschen Zuweisung der Nummern wird der Mirror möglicherweise nicht erzeugt. Wenn Sie beispielsweise einen Mirrornamen mit einer Nummer angeben, die auf 1 oder 2 endet (d1 oder d2), kann Solaris Live Upgrade den Mirror dann nicht erstellen, wenn der Mirrorname auch als Submirrorname vorhanden ist.

In früheren Versionen war die Eingabe eines abgekürzten Volume-Namens möglich. Ab Version Solaris 10 11/06 können nur noch vollständige Volume-Namen eingegeben werden. So kann zur Angabe eines Mirrors beispielsweise nur der vollständige Name /dev/md/dsk/d10, verwendet werden.

Beispiel 9–1 Solaris Live Upgrade: Software erkennt und benennt Mirror und Submirror

In diesem Beispiel erfolgt die Vergabe der Volume-Namen durch Solaris Live Upgrade. Die RAID-1-Volumes d0 und d1 sind die einzigen verwendeten Volumes. Für den Mirror d10 wählt Solaris Live Upgrade die Namen d2 für den Submirror des Geräts c0t0d0s0 und d3 für den Submirror des Geräts c1t0d0s0.

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

Beispiel 9–2 Solaris Live Upgrade: Zuweisen von Mirror- und Submirror-Namen

In diesem Beispiel werden die Volume-Namen im Befehl vergeben. Der Mirror d10 erhält den Namen d11 für den Submirror des Geräts c0t0d0s0 und d12 für den Submirror des Geräts 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

Ausführliche Informationen zu den Benennungsvoraussetzungen für Solaris Volume Manager entnehmen Sie bitte dem Dokument Solaris Volume Manager Administration Guide.

RAID-Volume-Namenskonventionen für das benutzerdefinierte JumpStart-Verfahren

Beim Erstellen von RAID-1- (Mirrors) und RAID-0-Volumes (Submirrors) mit der benutzerdefinierten JumpStart-Installation können Sie entweder die Software Namen für die Mirrors ermitteln und sie ihnen zuweisen lassen, oder Sie vergeben die Namen selbst im Profil.

• Wenn Sie die Ermittlung der Namen der Software überlassen, wird die erste verfügbare Volumenummer verwendet.

• Wenn Sie selbst Namen im Profil zuweisen, wählen Sie Mirrornamen, die auf Null enden, sodass die auf 1 und 2 endenden Namen bei der Installation an Submirrors vergeben werden können.

  ---

  Hinweis –

  Bei einer falschen Vergabe der Nummern wird der Mirror möglicherweise nicht erstellt. Wenn Sie beispielsweise einen Mirrornamen mit einer Nummer angeben, die auf 1 oder 2 endet (d1 oder d2), kann JumpStart den Mirror dann nicht erstellen, wenn der Mirrorname auch als Submirrorname vorhanden ist.

  ---

Sie können die Namen von physischen Festplatten-Slices und Solaris Volume Manager-Volumes abkürzen. Die Abkürzung ist der kürzestmögliche Name, der ein Gerät eindeutig kennzeichnet. Im Folgenden finden Sie hierzu einige Beispiele.

• Solaris Volume Manager lassen sich durch die Angabe dnum ansprechen; /dev/md/dsk/d10 wird also z. B. einfach zu d10.

• Wenn Ihr System nur einen einzigen Controller mit mehreren Festplatten hat, können Sie das Format t0d0s0 verwenden; bei mehreren Controllers ist jedoch das Format c0t0d0s0 zu verwenden.

Beispiel 9–3 Erkennen von Mirror- und Submirrornamen durch die Software

Im folgenden Beispielprofil werden dem Mirror die ersten verfügbaren Volume-Nummern zugewiesen. Wenn der nächste verfügbare Mirror, dessen Nummer auf Null endet, d10 ist, dann werden den Submirrors die Namen d11 und d12 zugewiesen.

filesys                 mirror c0t0d0s1  / 

Beispiel 9–4 Zuweisen von Mirror- und Submirrornamen

Im folgenden Profilbeispiel wird der Mirrorname im Profil als d30 zugewiesen. Submirrornamen werden von der Software aufgrund der Mirrornummer und der ersten verfügbaren Submirrors zugewiesen. Die Submirrors werden als d31 und d32 nummeriert.

filesys                 mirror:d30 c0t1d0s0 c0t0d0s0  /

Ausführliche Informationen zu den Benennungsvoraussetzungen für Solaris Volume Manager entnehmen Sie bitte dem Dokument Solaris Volume Manager Administration Guide.

Richtlinien für die Auswahl von Festplatten und Controllern

Beachten Sie bei der Auswahl von Festplatten und Controllern zum Spiegeln von Dateisystemen bitte die folgenden Richtlinien:

• Verwenden Sie Komponenten an unterschiedlichen Controllern. Dadurch erhöhen Sie die Anzahl der gleichzeitig durchführbaren Lese- und Schreibzugriffe.

• Ordnen Sie die Slices verschiedener Submirrors auf unterschiedlichen Festplatten und Controllern an. Befinden sich die Slices von zwei oder mehr Submirrors desselben Mirrors auf derselben Festplatte, wird eine wesentlich niedrigere Datensicherheit erzielt.

• Ordnen Sie Submirrors auf separaten Controllern an, da Controller und ihre Kabel häufiger ausfallen als Festplatten. Außerdem erhöht sich hierdurch die Mirror-Leistung.

• Setzen Sie in einem Mirror nur eine Sorte Festplatten und Controller ein. Besonders in älteren SCSI-Speichergeräten können unterschiedliche Modelle oder Marken von Festplatten oder Controllern sehr stark voneinander abweichende Leistungen aufweisen. Die Verbindung unterschiedlicher Leistungsniveaus in einem Mirror kann eine wesentliche Leistungseinbuße bewirken.

Richtlinien für die Auswahl von Slices

Beachten Sie bei der Auswahl von Slices zum Spiegeln von Dateisystemen bitte die folgenden Richtlinien:

• Jedes Dateisystem, einschließlich des Root-Dateisystems (/) sowie swap und /usr, bietet sich zum Spiegeln an. Auch alle Anwendungen, wie z. B. Datenbanken, bieten sich zum Spiegeln an.

• Verwenden Sie für Submirrors Slices gleicher Größe. Bei unterschiedlich großen Submirrors bleibt ungenutzter Speicherplatz zurück.

• Beginnt der zuerst eingefügte Submirror eines gespiegelten Dateisystems nicht an Zylinder 0, dürfen auch alle weiteren eingefügten Submirrors nicht an Zylinder 0 starten. Bei dem Versuch, einen an Zylinder 0 startenden Submirror in einen Mirror einzufügen, dessen erster Submirror nicht an Zylinder 0 beginnt, wird die folgende Fehlermeldung angezeigt:

  Beschrifteter untergeordneter Spiegel kann nicht mit einem unbeschrifteten Spiegel verbunden werden

  Sie müssen sich vergewissern, dass entweder alle Submirrors, die Sie in einen Mirror einfügen zu beabsichtigen, oder keiner an Zylinder 0 starten.

  Dabei müssen die Anfangszylinder der Submirrors nicht identisch sein, es ist lediglich zu beachten, dass sämtliche Submirrors entweder bei Zylinder 0 starten oder nicht.

Durch das Booten in den Einzelbenutzermodus wird irrtümlich gemeldet, dass ein Mirror gewartet werden muss

Beim Booten eines Systems mit Mirrors für das Root-Dateisystem (/), /usr und swap im Einbenutzermodus gibt das System diese Mirrors als wartungsbedürftig an. Wenn Sie diese Mirrors mit dem Befehl metastat überprüfen, wird für sie und möglicherweise auch alle anderen Mirrors des Systems der Status „Needing Maintenance? ausgegeben.

Auf den ersten Blick mag dies zwar gefährlich wirken, es besteht jedoch kein Grund zur Beunruhigung. Wenn Sie das System im Einbenutzermodus booten, wird der Befehl metasync -r, der normalerweise beim Booten zum Synchronisieren der Spiegel ausgeführt wird, unterbrochen. Nach einem Systemneustart wird der Befehl metasync -r wieder ausgeführt und synchronisiert alle Mirrors.

Wenn Sie diese Unterbrechung vermeiden möchten, führen Sie den Befehl metasync -r manuell aus.

Informationen zum Befehl metasync entnehmen Sie bitte der Manpage metasync(1M) und dem Dokument Solaris Volume Manager Administration Guide.