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.
Installation für das ZFS-Root-Dateisystem (/)
Booten auf x86- bzw. SPARC-basierten Systemen
Partionierungstechnologie Solaris Zones
Solaris Volume Manager-Komponenten wie z.B. RAID-1-Volumes
Dieses Kapitel enthält Informationen zu Voraussetzungen und Einschränkungen, die für die Installation von ZFS-Root-Pools gelten. Darüber hinaus enthält es eine Übersicht zu den Installationsprogrammen, mit denen ein ZFS-Root-Pool installiert werden kann.
Wenn auf Ihrem System mehrere Boot-Umgebungen vorhanden sind, sollten Sie in Kapitel 7SPARC- und x86-basiertes Booten (Überblick und Planung) nachlesen. Dort finden Sie Informationen zum Booten.
Voraussetzung bzw. Einschränkung |
Beschreibung |
Informationen |
---|---|---|
Mindestens erforderlich sind 786 MB. Für eine optimale Gesamtleistung werden 1 GB empfohlen: | ||
Speicherplatz auf dem Datenträger |
Der für ein bootfähiges ZFS-Root-Dateisystem mindestens erforderliche Pool-Speicherplatz hängt von der Kapazität des physischen Speichers, dem verfügbaren Festplattenspeicherplatz sowie der Anzahl der zu erstellenden Boot-Umgebungen ab. |
Eine Erläuterung finden Sie unter Voraussetzungen für den Festplattenspeicherplatz bei ZFS-Installationen. |
Ein ZFS-Speicherpool muss auf·Datenträgerbereichen·(Slices) und darf nicht auf einer gesamten Festplatte erstellt werden, damit es bootfähig ist und später aufgerüstet werden kann. |
|
|
Wenn Sie eine Migration von einem UFS-Root-Dateisystem (/) auf ein ZFS-Root-Pool mit Solaris Live Upgrade durchführen, sollten Sie die folgenden Voraussetzungen berücksichtigen. |
|
|
Normalerweise befinden sich bei·Systemen mit einem UFS-Root-Dateisystem Swap-Speicher und der Bereich für Speicherabzüge auf dem gleichen Slice. Deswegen teilt sich UFS den Swap-Bereich mit dem Speicherabzugsgerät. In einem ZFS-Root-Pool befinden sich Swap-Speicher und der Bereich für Speicherabzüge auf verschiedenen zvols und belegen so nicht den gleichen physischen Speicherplatz. Wenn ein System mit einem ZFS-Root-Dateisystem installiert bzw. aufgerüstet wird, hängen die Größe des Swap-Bereichs und des Speicherabzugsgeräts von der Kapazität des physischen Speichers ab. Der für ein bootfähiges ZFS-Root-Dateisystem mindestens erforderliche Pool-Speicherplatz hängt von der Kapazität des physischen Speichers, dem verfügbaren Festplattenspeicherplatz sowie der Anzahl der zu erstellenden Boot-Umgebungen ab. Es werden ca. 1 GB Hauptspeicher sowie mindestens 2 GB Festplattenspeicherplatz empfohlen. Der Speicherplatz wird wie folgt belegt:
Swap-Speicher und Bereich für Speicherabzüge - Die Standardkapzität beträgt die Hälfte der Kapazität des physischen Speichers (mindestens 512 MB und maximal 2 GB). Die Kapazität des Speicherabzugsbereichs wird auf der Grundlage der Hauptspeicherkapazität und dem Inhalt der Datei dumpadm.conf berechnet. Diese Datei legt fest, welche Informationen in einem Speicherabzug festgehalten werden. Sie können die Größe des Swap-Speichers sowie anderer Speichergeräte vor und nach der Installation anpassen. Weitere Informationen finden Sie unter ZFS-Eigenschaften in Solaris ZFS - Administrationshandbuch.
Boot-Umgebungen - Zusätzlich zu Anforderungen für neuen Swap-Speicher bzw. Speicherabzugsbereichen oder angepassten Kapazitäten für Swap-Speicher bzw. Speicherabzugsbereichen benötigt eine von einer UFS-Bootumgebung migrierte ZFS-Bootumgebung ca. 6 GB Speicherplatz. ZFS-Bootumgebungen, die von anderen ZFS-Bootumgebungen geklont werden, benötigen keinen zusätzlichen Festplattenspeicherplatz. Die Größe einer Bootumgebung kann sich aber möglicherweise bei der Anwendung von Patches erhöhen. Alle ZFS-Bootumgebungen im selben·Root-Pool nutzen den gleichen Swap-Speicher bzw. Speicherabzugsbereich.
Die folgenden Installationsprogramme führen eine Neuinstallation auf einem ZFS-Root-Pool durch.
textbasierte Version des Solaris-Installationsprogramms
benutzerdefinierte JumpStart-Installation mit Installationsprofil
Solaris Live Upgrade kann ein UFS-Dateisystem auf ein ZFS-Root-Pool migrieren. Darüber hinaus kann Solaris Live Upgrade ZFS-Bootumgebungen erstellen, für die ein Upgrade durchgeführt werden kann.
Tabelle 6–2 ZFS-Installationsprogramme und Einschränkungen
ZFS-Installationsrogramm |
Beschreibung |
Einschränkungen |
Informationen |
---|---|---|---|
Textbasierte Version des Solaris- Installationspro- gramms |
Das textbasierte Solaris-Installationsprogramm führt eine Neuinstallation eines ZFS-Root-Pools aus. Während der Installation können Sie auswählen, ob Sie ein UFS-Dateisystem oder ein ZFS-Root-Pool installieren möchten. Sie können auch ein gespiegeltes ZFS-Root-Pool einrichten, indem Sie während der Installation zwei oder mehr Slices auswählen. Als Alternative dazu können Sie nach der Installation zusätzliche Festplatten hinzufügen bzw. anhängen, um ein gespiegeltes ZFS-Root-Pool zu erstellen. Swap-Speicher und Speicherabzugsgeräte auf ZFS-Volumes werden im ZFS-Root-Pool automatisch erstellt. |
| |
Solaris Live Upgrade |
Mit Solaris Live Upgrade können Sie die folgenden Aufgaben ausführen:
Nach dem Erstellen der ZFS-Bootumgebung mithilfe des Befehls lucreate können Sie die anderen Solaris Live Upgrade-Befehle in dieser Bootumgebung verwenden. |
| |
JumpStart |
Sie können ein Profil zum Erstellen eines ZFS-Speicherpools anlegen und ein bootfähiges ZFS-Dateisystem vorsehen. Mithilfe neuer ZFS-Schlüsselwörter kann eine Neuinstallation durchgeführt werden. |
|
|
Ab Solaris-Release 10 10/08 gibt es aufgrund von Änderungen in der Boot-Architektur von Solaris viele neue Leistungsmerkmale einschließl. Booten von unterschiedlichen Dateisystemtypen wie z. B. ZFS-Dateisystemen. In diesem Kapitel werden einige dieser Änderungen beschrieben, und es enthält Verweise auf weitere Informationen zum Booten. Darüber hinaus enthält dieses Kapitel einen Überblick zum GRUB-basierten Booten für x86-Systeme.
Dieses Kapitel enthält die folgenden Abschnitte:
In Solaris-Release 10 10/08 wurde der Solaris Bootstrap-Prozess SPARC-basierter Systeme überarbeitet. Damit wurde eine Vereinheitlichung mit der Solaris Boot-Architektur x86-basierter Systeme erreicht. Die verbesserte Solaris-Boot-Architektur ermöglicht jetzt direktes Booten, RAM-Disk-basiertes Booten sowie RAM-Disk-Miniroots für SPARC-Plattformen. Diese Technologien unterstützen folgende Funktionen:
Booten eines Systems von zusätzlichen Dateisystemtypen wie z. B. ZFS.
Booten einer einzelnen Miniroot für die Software-Installation von DVD, NFS oder HTTP.
Weitere Verbesserungen sind u. a. erheblich schnellere Bootzeiten, erhöhte Flexibilität sowie geringerer Wartungsaufwand.
Im Rahmen der Überarbeitung dieser Architektur sind die früher nur auf Solaris x86-Plattformen verfügbaren Boot-Archive sowie der Befehl bootadm jetzt integraler Bestandteil der Solaris Boot-Architektur SPARC-basierter Systeme.
Obwohl sich die Implementierung des Solaris-Bootvorgangs SPARC-basierter Systeme geändert hat, bleiben die administrativen Vorgänge zum Booten eines SPARC-basierten Systems gleich. Solaris-Installationen umfassen jetzt die Möglichkeit zur Installation von einem ZFS-Dateisystem, haben sich jedoch anderweitig im Rahmen der neuen Boot-Architektur nicht geändert.
Wenn auf Ihrem System mehrere Betriebssysteme installiert sind bzw. dieses mehrere Root-Boot-Umgebungen einem ZFS-Root-Pool besitzt, können Sie jetzt auf SPARC- und x86-Plattformen von diesen Boot-Umgebungen booten. Zum Booten können auch die mit Solaris Live Upgrade erstellten Boot-Umgebungen verwendet werden.
Ab Solaris-Release 10 10/08 können Sie auf SPARC-basierten Systemen ein ZFS-Root-Dateisystem in einem ZFS-Pool booten. Für ZFS-Root-Pools können Sie sich die verfügbaren Boot-Umgebungen mit der Option -L des Befehls boot anzeigen lassen. Sie können dann eine Boot-Umgebung auswählen und diese mit der Option -Z des OBP-Befehls boot booten. Die Option -Z ist eine Alternative zum Befehl luactivate, der bei ZFS-Root-Pools ebenfalls zum Booten einer neuen Boot-Umgebung dient. Der Befehl luactivate ist die empfohlene Vorgehensweise für das Umschalten von Boot-Umgebungen. Bei UFS-Dateisystemen können Sie auch weiterhin den PROM OBP-Befehl OpenBootTM als primäre administrative Schnittstelle nutzen, wobei Boot-Optionen mithilfe von OBP-Befehlen auswählbar sind.
Ab Solaris-Release 10 1/06 ist·bei x86-basierten Systemen ein GRUB-Bootmenü die Schnittstelle zum Umschalten zwischen verschiedenen Boot-Umgebungen. Ab Solaris-Release 10 10/08 werden in diesem Menü auch zum Booten verfügbare ZFS-Boot-Umgebungen angezeigt Wenn die Standard-Boot-Umgebung ein ZFS-Dateisystem ist und das GRUB-Menü angezeigt wird, können Sie Ihr System mit der Standard-Boot-Umgebung booten oder dafür eine andere Boot-Umgebung auswählen. Das GRUB-Menü ist eine Alternative zum Befehl luactivate, der bei ZFS-Root-Pools ebenfalls zum Booten einer neuen Boot-Umgebung dient. Der Befehl luactivate ist die empfohlene Vorgehensweise für das Umschalten von Boot-Umgebungen.
Bei SPARC- und x86-basierten Systemen besitzt jedes ZFS-Root-Pool ein Dataset, das·als Standard-Root-Dateisystem vorgesehen ist. Wenn Sie den boot-Befehl eingeben (SPARC) bzw. aus dem GRUB-Menü die Standardeinstellung auswählen (x86), wird dieses Standard-Root-Dateisystem gebootet.
Tabelle 7–1 Quellenverweise für Informationen zum Booten
Beschreibung |
Informationen |
---|---|
Allgemeine Übersicht zu Boot-Funktionen | |
Ausführlichere Informationen zu Boot-Funktionen | |
x86: Informationen zum Ändern des Bootverhaltens wie z. B. Suchen und Bearbeiten der Datei menu.lst | |
Vorgehensweisen zum Booten eines ZFS-Dateisystems |
Kapitel 12, Booting a Solaris System (Tasks) in System Administration Guide: Basic Administration |
Vorgehensweisen zum Verwalten von Boot-Archiven wie z. B. Suchen der GRUB-Datei menu.lst und Verwendung des Befehls bootadm |
GRUB, der Open Source Boot-Loader, ist jetzt der standardmäßige Boot-Loader des Betriebssystems Solaris.
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 konfigurierten 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. Eine ausführliche Spezifikation finden Sie unter http://www.gnu.org/software/grub/grub.html.
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.
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.
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 by GRUB in System Administration Guide: Basic Administration.
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 10/08 Installationshandbuch: Netzwerkbasierte Installation.
Dieses Kapitel beschreibt, wie sich die Partitionierungstechnologie Solaris Zones auf die Aktualisierung des Betriebssystems Solaris auswirkt, wenn bereits nicht-globale Zonen auf dem System konfiguriert sind.
Dieses Kapitel enthält die folgenden Abschnitte:
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 Prozess, der mit Berechtigungen eines Superuser ausgeführt wird, kann Aktivitäten in anderen Zonen weder anzeigen 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. Ein Beispiel für diese Attribute sind physikalische Gerätepfade.
Jedes Solaris-System enthält eine globale Zone. Die globale Zone hat 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 nicht globalen Zonen erstellt wurden. Die globale Zone ist die einzige Zone, von der aus eine nicht-globale Zone konfiguriert, installiert, verwaltet oder deinstalliert werden kann. Nur die globale Zone kann von der System-Hardware 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.
Beschreibung |
Weitere Informationen |
---|---|
In den folgenden Abschnitten wird beschrieben, wie Sie ein System mit nicht-globalen Zonen aktualisieren können. |
Durchführen von Upgrades auf Systemen mit installierten nicht-globalen Zonen |
Vollständige Informationen zum Erstellen und Konfigurieren von nicht-globalen Zonen finden Sie in |
Nach der Installation des Betriebssystems Solaris können Sie nicht-globale Zonen installieren und konfigurieren. Sie können das Betriebssystem Solaris aktualisieren, wenn nicht-globale Zonen installiert sind. Bereits installierte nicht-globale Markenzonen werden während des Upgrade-Prozesses ignoriert. Die Änderungen zur Aufnahme von Systemen mit bereits installierten nicht-globalen Zonen sind im Folgenden zusammengefasst.
Wenn Sie das interaktive Solaris-Installationsprogramm verwenden, können Sie ein System auch bei bereits installierten nicht-globalen Zonen aktualisieren oder patchen. Abhängig von der Anzahl der bereits installieren nicht-globalen Zonen dauert das Aktualisieren oder Patchen jedoch recht lange. Weitere Informationen zur Installation mithilfe dieses Programms finden Sie in Kapitel 2, Installation mit dem Solaris-Installationsprogramm für UFS-Dateisysteme (Vorgehen) in Solaris 10 10/08 Installationshandbuch: Grundinstallationen.
Bei einer automatisierten JumpStart-Installation können Sie mit jedem für ein Upgrade oder einen Patch gültigem Schlüsselwort aktualisieren oder patchen. Abhängig von der Anzahl der bereits installieren nicht-globalen Zonen dauert das Aktualisieren oder Patchen jedoch recht lange. Weitere Informationen entnehmen Sie bitte dem Solaris 10 10/08 Installationshandbuch: Benutzerdefinierte JumpStart-Installation und komplexe Installationsszenarien.
Mit dem Solaris Live Upgrade können Sie ein System mit bereits installierten nicht-globalen Zonen aktualisieren oder patchen. Wenn bereits nicht-globale Zonen auf Ihrem System installiert sind, sollten Sie Solaris Live Upgrade zum Aktualisieren oder Patchen Ihres Systems verwenden. Andere Programme zum Aktualisieren des Systems benötigen eventuell deutlich mehr Zeit, da die für die Aktualisierung erforderliche Zeit linear mit der Anzahl an installierten nicht-globalen Zonen ansteigt. Wenn Sie ein System mit Solaris Live Upgrade patchen, brauchen Sie das System nicht in den Einzelbenutzermodus überführen und können die Verfügbarkeit Ihres Systems maximieren. Die Änderungen zur Aufnahme von Systemen mit bereits installierten nicht-globalen Zonen sind im Folgenden zusammengefasst.
Ein neues Paket, SUNWlucfg, muss mit den anderen Solaris Live Upgrade-Paketen SUNWlur und SUNWluu installiert werden.
Das Erstellen einer neuen Boot-Umgebung von einer derzeit ausgeführten Boot-Umgebung bleibt im Vergleich mit früheren Versionen bis auf eine Ausnahme gleich. Sie können ein Ziel-Slice für ein freigegebenes Dateisystem innerhalb einer nicht-globalen Zone angeben. Diese Ausnahme tritt unter den folgenden Umständen auf:
Wenn der Befehl zonecfg add fs für die aktuelle Boot-Umgebung verwendet wurde und ein separates Dateisystem für eine nicht-globale Zone erstellt hat.
Wenn dieses separate Dateisystem auf einem freigegebenen Dateisystem gespeichert ist, z. B. /zone/root/export
Damit dieses separate Dateisystem in der neuen Boot-Umgebung nicht freigegeben wird, wurde der Befehl lucreate geändert. Er gibt jetzt ein Ziel-Slice für ein separates Dateisystem für eine nicht-globale Zone an. Das Argument zur Option -m verfügt über ein neues optionales Feld, Zonenname. Dieses neue Feld positioniert das separate Dateisystem der nicht-globalen Zone auf einem separaten Slice in der neuen Boot-Umgebung. Weitere Informationen zum Einrichten einer nicht-globalen Zone mit einem separatem Dateisystem finden Sie unter zonecfg(1M).
In der Standardeinstellung wird jedes Dateisystem mit Ausnahme der kritischen Dateisysteme (root (/), /usr und /opt) für die aktuelle und die neue Boot-Umgebung freigegeben. Eine Aktualisierung der gemeinsam genutzten Dateien in der aktiven Boot-Umgebung bewirkt gleichzeitig auch eine Aktualisierung der Daten in der inaktiven Boot-Umgebung. Das Dateisystem /export ist ein Beispiel für ein freigegebenes Dateisystem. Wenn Sie die Option -m und die Option Zonenname verwenden, wird das freigegebene Dateisystem der nicht-globalen Zone auf einen separaten Slice kopiert und die Daten werden nicht freigegeben. Diese Option verhindert, dass Dateisysteme der nicht-globalen Zone, die mit dem Befehl zonecfg add fs erstellt wurden, von den Boot-Umgebungen gemeinsam genutzt werden.
Der Vergleich der Boot-Umgebungen wurde verbessert. Der Befehl lucompare erstellt jetzt einen Vergleich der Boot-Umgebungen, die die Inhalte einer beliebigen nicht-globalen Zone enthalten.
Der Befehl lumount stellt nicht-globalen Zonen jetzt Zugriff auf entsprechende Dateisysteme zur Verfügung, die in inaktiven Boot-Umgebungen vorhanden sind. Wenn der Administrator einer globalen Zone den Befehl lumount zum Einhängen einer inaktiven Boot-Umgebung verwendet, wird auch die Boot-Umgebung für die nicht-globalen Zonen eingehängt.
Das Auflisten von Dateisystemen mit dem Befehl lufslist wurde verbessert. Jetzt wird eine Liste der Dateisysteme für sowohl die globale Zone als auch für die nicht-globalen Zonen angezeigt.
Schrittweise Anleitungen·zur Verwendung von Solaris Live Upgrade für UFS-Dateisysteme bei bereits installierten nicht-globalen Zonen finden Sie in Kapitel 8, Aktualisieren des Betriebssystems Solaris auf einem System mit bereits installierten nicht-globalen Zonen in Solaris 10 10/08 Installationshandbuch: Solaris Live Upgrade und Planung von Upgrades.
Eine Übersicht über ZFS-Root-Pools und schrittweise Anleitungen finden Sie in Kapitel 14, Solaris Live Upgrade für ZFS mit installierten nicht-globalen Zonen in Solaris 10 10/08 Installationshandbuch: Solaris Live Upgrade und Planung von Upgrades.
Programm bzw. Bedingung |
Beschreibung |
---|---|
Solaris Flash-Archive |
Ein Solaris Flash-Archiv kann nicht korrekt angelegt werden, wenn bereits nicht-globale Zonen installiert sind. Die Solaris Flash-Funktion ist nicht mit der Partitionierungstechnologie Solaris Zones kompatibel. Wenn Sie ein Solaris Flash-Archiv erstellen, wird dieses Archiv nicht korrekt installiert, wenn es unter den folgenden Bedingungen bereitgestellt wird:
Weitere Informationen zum Verwenden von Solaris Flash-Archiven finden Sie im Solaris 10 10/08 Installationshandbuch: Solaris Flash-Archive (Erstellung und Installation). |
Befehle mit der Option -R (oder entsprechenden Optionen) dürfen in bestimmten Situationen nicht verwendet werden. |
Befehle, die über die Option -R oder ähnliche Optionen ein alternatives Root-Verzeichnis (/) akzeptieren, dürfen nicht verwendet werden, wenn Folgendes zutrifft:
Beispiel: Die Option -R Root-Pfad des Dienstprogramms pkgadd, das von der globalen Zone aus mit einem Pfad im Root-Dateisystem (/), der auf einen Pfad in einer nicht-globalen Zone verweist, ausgeführt wird. Eine Liste der Dienstprogramme, die ein alternatives Root-Dateisystem (/) akzeptieren, sowie weitere Informationen zu Zonen stehen Ihnen unter Einschränken des Zugriffs von der globalen Zone auf eine nicht-globale Zone in Systemverwaltungshandbuch: Solaris Container – Ressourcenverwaltung und Solaris Zones zur Verfügung . |
Bevor Sie ein Upgrade durchführen, sollten Sie die globale Zone und alle nicht-globalen Zonen auf dem Solaris-System sichern. Informationen zum Sichern eines Systems mit bereits installierten Zonen finden Sie in Kapitel 26, Einführung in die Verwaltung der Solaris Zones in Systemverwaltungshandbuch: Solaris Container – Ressourcenverwaltung und Solaris Zones.
Achten Sie bei der Installation der globalen Zone darauf, ausreichend Speicherplatz für die anzulegenden Zonen einzuplanen. 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 Uniprozessor-System kann mehrere Zonen unterstützen, die gleichzeitig ausgeführt werden. Die Art der in der globalen Zone installierten Packages wirkt sich auf den Speicherplatzbedarf für die nicht-globalen Zonen aus. Weitere Faktoren sind die Anzahl der Pakete und deren Speicherplatzanforderungen.
In Kapitel 18, Planen und Konfigurieren von nicht-globalen Zonen (Vorgehen) in Systemverwaltungshandbuch: Solaris Container – Ressourcenverwaltung und Solaris Zones finden Sie sämtliche Anforderungen und Empfehlungen für die Planung .
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:
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 10/08 Installationshandbuch: Solaris Live Upgrade und Planung von Upgrades
JumpStart:
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.
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 9–1 zeigt einen Mirror, der das Root (/)-Dateisystem auf zwei physischen Festplatten dupliziert.
Abbildung 9–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.
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.
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.
Beschreibung |
Weitere Informationen |
---|---|
Bevor Sie mit der benutzerdefinierten JumpStart-Installation oder Solaris Live Upgrade ein RAID-1-Volume installieren, sollten Sie sich die folgenden Richtlinien und Voraussetzungen durchlesen: |
Richtlinien und Voraussetzungen für Statusdatenbankreplikationen |
Besorgen Sie sich ausführliche Informationen zu Statusdatenbanken und Statusdatenbankreplikationen: |
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 Dateisystemen 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.
Beschreibung |
Weitere Informationen |
---|---|
Planung von RAID-1 Volumes |
Voraussetzungen und Richtlinien für RAID-1- und RAID-0-Volumes |
Ausführliche Informationen zu RAID-1 Volumes |
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.
Beschreibung |
Weitere Informationen |
---|---|
Planung von RAID–0 Volumes |
Voraussetzungen und Richtlinien für RAID-1- und RAID-0-Volumes |
Ausführliche Informationen zu RAID-0 Volumes |
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 9–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.
Beschreibung |
Weitere Informationen |
---|---|
Beispiel für ein JumpStart-Profil | |
Schrittweise Anleitung für Solaris Live Upgrade |
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:
Richtlinien und Voraussetzungen für Statusdatenbankreplikationen
Voraussetzungen und Richtlinien für RAID-1- und RAID-0-Volumes
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 10/08 Installationshandbuch: Solaris Live Upgrade und Planung von Upgrades
JumpStart:
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.
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.
Beachten Sie bei der Auswahl von Slices für Statusdatenbankreplikationen bitte die folgenden Richtlinien und Empfehlungen:
Aufgabe |
Beschreibung |
---|---|
Auswahl eines dedizierten Slices |
Für Statusdatenbankreplikationen sollte ein dediziertes Slice von mindestens 4 MB pro Replikation vorgesehen werden. Falls notwendig, können Statusdatenbankreplikationen auf einem Slice erstellt werden, das Teil eines RAID-0- oder RAID-1-Volumes wird. Dabei sind die Replikationen vor der Aufnahme des Slices in das Volume zu erstellen. |
Ändern der Slice-Größe |
Die Standardgröße für eine Statusdatenbankreplikation beträgt 4 MB oder 8192 Festplattenblöcke. Da Ihre Festplattenslices wahrscheinlich nicht so klein angelegt sind, können Sie ein für eine Statusdatenbankreplikation vorgesehenes Slice verkleinern. Informationen zum Ändern der Slice-Größe finden Sie in Kapitel 11, Administering Disks (Tasks) in System Administration Guide: Devices and File Systems. |
Auswahl eines unbenutzten Slices |
Sie können Statusdatenbankreplikationen auf nicht verwendeten Slices erstellen. Der für die Statusdatenbankreplikation reservierte Teil auf einem Slice sollte für keinen weiteren Zweck verwendet werden. |
Statusdatenbankreplikationen können weder in vorhandenen Dateisystemen noch im Root- (/), /usr- oder swap-Dateisystem erstellt werden. Falls erforderlich, können Sie ein neues Slice erzeugen (sofern ein Slice-Name verfügbar ist), indem Sie Speicherplatz aus swap reservieren und dann auf diesem neuen Slice Statusdatenbankreplikationen erstellen. |
|
Auswahl eines Slices zur späteren Verwendung als Volume |
Wenn eine Statusdatenbankreplikation auf einem Slice angelegt wird, das Teil eines Volumes wird, verringert sich die Kapazität des Volumes um den von der Replikation bzw. den Replikationen belegten Platz. Der von einer Replikation belegte Platz wird bis zur nächsten Zylindergrenze aufgerundet, und dieser Bereich wird vom Volume ignoriert. |
Beachten Sie bei der Entscheidung über die Anzahl von Statusdatenbankreplikationen bitte die folgenden Richtlinien:
Es werden mindestens drei Statusdatenbankreplikationen empfohlen. Sie können jedoch bis zu 50 Replikationen pro Solaris Volume Manager-Plattensatz anlegen. Empfohlene Richtlinien:
Für Systeme mit einem einzigem Laufwerk: Erzeugen Sie in einem Slice alle drei Replikationen.
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.
Zusätzliche Statusdatenbankreplikationen können die Leistungsfähigkeit der Mirrors verbessern. 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.
Wenn mehrere Controller vorhanden sind, sollten die Replikationen möglichst gleichmäßig über alle Controller verteilt werden. 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.
Wenn Sie mit RAID-1-Volumen (Mirrors) und RAID-0-Volumen arbeiten (Single-Slice-Verkettungen), müssen Sie die folgenden Richtlinien berücksichtigen.
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.
Installationsprogramm |
Unterstützte Funktion |
Nicht unterstützte Funktion |
---|---|---|
Benutzerdefinierte JumpStart-Installation und Solaris Live Upgrade |
|
In Solaris Volume Manager kann es sich bei RAID-0-Volumes um Platten-Stripes oder Verkettungen handeln. Sie können während der Installation oder des Upgrades keine RAID-0-Stripe-Volumes erzeugen. |
Benutzerdefiniertes JumpStart |
|
|
Solaris Live Upgrade |
Beispiele finden Sie unter So erstellen Sie eine Boot -Umgebung mit RAID-1-Volumes (Mirrors) in Solaris 10 10/08 Installationshandbuch: Solaris Live Upgrade und Planung von Upgrades. |
Mehr als drei RAID-0-Volumes werden nicht unterstützt. |
Erstellen und Installieren eines Solaris Flash-Archivs mit RAID-1-Volumes |
Sie können ein Solaris Flash-Archiv aus einem Mastersystem mit konfigurierten Solaris Volume Manager RAID-1-Volumes erstellen. Dabei entfernt die Solaris Flash-Erstellungssoftware zur Wahrung der Integrität der Klonsysteme sämtliche RAID-1-Volume-Informationen aus dem Archiv. Mit der benutzerdefinierten JumpStart-Installation können die RAID-1-Volumes unter Zuhilfenahme eines JumpStart-Profils wiederhergestellt werden. Wenn Sie mit Solaris Live Upgrade arbeiten, erstellen Sie eine Boot-Umgebung mit konfigurierten RAID-1-Volumes und installieren das Archiv. Das Solaris-Installationsprogramm erlaubt die Installation von RAID-1-Volumes mit einem Solaris Flash-Archiv nicht. Beispiele von RAID-1-Volumes in JumpStart-Profilen finden Sie unter Beispiele für Profile in Solaris 10 10/08 Installationshandbuch: Benutzerdefinierte JumpStart-Installation und komplexe Installationsszenarien. |
Veritas VxVM speichert Konfigurationsinformationen in Bereichen, auf die Solaris Flash nicht zugreifen kann. Wenn Veritas VxVm-Dateisysteme konfiguriert wurden, sollte kein Solaris Flash-Archiv angelegt werden. Außerdem bietet die Solaris-Installation einschließlich JumpStart und Solaris Live Upgrade keine Unterstützung für eine Wiederherstellung von VxVM-Volumes bei der Installation. Wenn Sie beabsichtigen, Veritas VxVM-Software mit einem Solaris Flash-Archiv bereitzustellen, müssen Sie das Archiv deshalb vor der Konfiguration der VxVM-Dateisysteme erstellen. Die Klonsysteme sind im Anschluss an die Installation des Archivs und einen Systemneustart einzeln zu konfigurieren. |
Beachten Sie beim Benennen der Volumen die folgenden Richtlinien.
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.
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. Sie sollten Submirrors Namen zuweisen, die auf 1 oder 2 enden. Bei einer falschen Vergabe der Nummern wird der Mirror möglicherweise nicht erstellt. Wenn Sie zum Beispiel einen Mirror-Namen mit einer Zahl angeben, die mit 1 oder 2 (d1 oder d2) endet, kann Solaris Live Upgrade den Mirror nicht erstellen, wenn der Mirror-Name einem bereits vorhandenen Submirror-Namen entspricht.
In früheren Versionen war die Eingabe eines abgekürzten Volume-Namens möglich. Ab Release 10 10/08 können nur noch vollständige Volume-Namen eingegeben werden. Beispielsweise kann nur ein vollständiger Volumen-Name wie /dev/md/dsk/d10 zur Angabe eines Mirrors verwendet werden.
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 |
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.
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.
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 dNummer 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.
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 /
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 numeriert.
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.
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.
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.
Liegt der erste Submirror eines gespiegelten Dateisystems (/) nicht bei Zylinder 0, so dürfen auch angefügte untergeordnete Spiegelpartitionen (Submirrors) bei Zylinder 0 beginnen. Wenn Sie versuchen, einen Submirror mit Anfang bei Zylinder 0 an einen Mirror·anzufügen, dessen ursprünglicher Submirror nicht bei Zylinder 0 startet, dann wird die folgende Fehlermeldung angezeigt:
can't attach labeled submirror to an unlabeled mirror |
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.
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 Mirrors·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.