Planen der Datenträgerverwaltung

Nehmen Sie diese Planungsinformationen in das Arbeitsblatt Plattengerätegruppen- Konfigurationen und das Arbeitsblatt Datenträger-Manager- Konfigurationen auf. Nehmen Sie bei Solstice DiskSuite oder Solaris Volume Manager diese Planungsinformationen auch in das Arbeitsblatt Metageräte (Solstice DiskSuite oder Solaris Volume Manager) auf.

Dieser Abschnitt enthält folgende Richtlinien für die Planung der Datenträgerverwaltung für die Cluster-Konfiguration:

• Richtlinien für Datenträger-Manager-Software

• Richtlinien für die Software Solstice DiskSuite oder Solaris Volume Manager

• SPARC: Richtlinien für die Software VERITAS Volume Manager

• Dateisystem-Protokollierung

• Richtlinien für das Spiegeln

Die Sun Cluster-Software verwendet Datenträger-Manager-Software, um Platten zu Plattengerätegruppen zu gruppieren, die dann als eine Einheit verwaltet werden können. Die Sun Cluster-Software unterstützt die Software Solstice DiskSuite oder Solaris Volume Manager und VERITAS Volume Manager (VxVM), die Sie folgendermaßen installieren oder verwenden.

Tabelle 1–4 Unterstützte Verwendung von Datenträger-Manager mit der Sun Cluster-Software

Datenträger-Manager-Software	Anforderungen
Solstice DiskSuite oder Solaris Volume Manager	Sie müssen die Software Solstice DiskSuite oder Solaris Volume Manager auf allen Knoten des Clusters installieren, unabhängig davon, ob Sie auf manchen Knoten VxVM zum Verwalten von Platten verwenden.
SPARC: VxVM mit der Cluster-Funktion	Sie müssen VxVM mit der Cluster-Funktion auf allen Knoten des Clusters installieren und lizenzieren.
SPARC: VxVM ohne die Cluster-Funktion	Sie müssen VxVM nur auf den Knoten installieren und lizenzieren, die an Speichergeräte angehängt sind, die von VxVM verwaltet werden.
SPARC: Sowohl Solstice DiskSuite oder Solaris Volume Manager als auch VxVM	Wenn Sie beide Datenträger-Manager auf demselben Knoten installieren, müssen Sie die Software Solstice DiskSuite oder Solaris Volume Manager verwenden, um die jeweils lokalen Platten eines Knotens zu verwalten. Lokale Platten beinhalten die Root-Platte. Verwenden Sie VxVM, um alle gemeinsam genutzten Platten zu verwalten.

Anweisungen zur Installation und Konfiguration der Datenträger-Manager-Software finden Sie in der Datenträger-Manager-Dokumentation und unter Installieren und Konfigurieren der Software Solstice DiskSuite oder Solaris Volume Manager oder SPARC: Installieren und Konfigurieren der Software VxVM . Weitere Information zur Datenträgerverwaltung in einer Cluster-Konfiguration finden Sie im Sun Cluster Konzepthandbuch für Solaris OS.

Richtlinien für Datenträger-Manager-Software

Beachten Sie folgende allgemeine Richtlinien, wenn Sie Platten mit Datenträger-Manager-Software konfigurieren:

• Software-RAID –Die Sun Cluster-Software unterstützt nicht Software-RAID 5.

• Gespiegelte Multihost-Platten – Sie müssen alle Multihost-Platten Plattenerweiterungseinheiten-übergreifend spiegeln. Informationen zum Spiegeln von Multihost-Platten finden Sie in Richtlinien für das Spiegeln von Multihost-Platten . Sie müssen keine Softwarespiegelung verwenden, wenn das Speichergerät über Hardware-RAID sowie redundante Pfade zum Gerät verfügt.

• Gespiegelte Root-Platte – Spiegeln der Root-Platte stellt hohe Verfügbarkeit sicher, ist aber nicht obligatorisch. Richtlinien für die Entscheidung, die Root-Platte zu spiegeln, finden Sie unter Richtlinien für das Spiegeln .

• Einmalige Benennung – Sie können über lokale Solstice DiskSuite-Metageräte, lokale Solaris Volume Manager -Datenträger oder VxVM-Datenträger verfügen, die als Geräte verwendet werden, in denen /global/.devices/node@nodeid-Dateisysteme eingehängt werden. Wenn dies der Fall ist, muss der Name jedes lokalen Metageräts oder lokalen Datenträgers, auf dem ein /global/.devices/node@nodeid-Dateisystem eingehängt werden soll, im gesamten Cluster einmalig sein.

• Knotenlisten – Um die hohe Verfügbarkeit einer Plattengerätegruppe sicherzustellen, konfigurieren Sie ihre Knotenliste von potenziellen Mastern und ihre Failback-Verfahren identisch mit allen zugeordneten Ressourcengruppen. Oder konfigurieren Sie die Knotenliste der Scalable-Ressourcengruppe, wenn sie mehr Knoten als ihre zugeordnete Plattengerätegruppe verwendet, als Obergruppe der Knotenliste der Plattengerätegruppe. Informationen zu Knotenlisten finden Sie in den Planungsinformationen für Ressourcengruppen im Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

• Multihost-Platten – Sie müssen sämtliche Geräte, die zur Bildung einer Gerätegruppe dienen, mit allen Knoten verbinden, bzw. an die Knoten anschließen, die in der Knotenliste für die entsprechende Gerätegruppe konfiguriert wurden. Die Software Solstice DiskSuite oder Solaris Volume Manager kann automatisch diese Verbindungen prüfen, wenn einem Plattensatz die Geräte hinzugefügt werden. Konfigurierte VxVM-Plattengruppen sind jedoch keiner bestimmten Knotengruppe zugeordnet.

• Hot-Spare-Platten – Sie können Hot-Spare-Platten verwenden, um die Verfügbarkeit zu erhöhen. Hot-Spare-Platten sind jedoch nicht erforderlich.

Informationen zu Platten-Layout-Empfehlungen und weitere Einschränkungen finden Sie in der Datenträger-Manager-Dokumentation.

Richtlinien für die Software Solstice DiskSuite oder Solaris Volume Manager

Beachten Sie folgende Punkte bei der Planung von Konfigurationen mit Solstice DiskSuite oder Solaris Volume Manager:

• Lokale Metageräte- oder Datenträger-Namen – Der Name jedes lokalen Solstice DiskSuite-Metageräts oder Solaris Volume Manager-Datenträgers, auf dem ein Dateisystem für globale Geräte, /global/.devices/node@nodeid, eingehängt ist, muss im ganzen Cluster einmalig sein. Der Name darf auch nicht mit dem Geräte-ID-Namen identisch sein.

• Doppelverkettungsvermittler – Jeder Plattensatz, der mit genau zwei Plattenverkettungseinheiten konfiguriert und von genau zwei Knoten unterstützt wird, muss für den Plattensatz konfigurierte Solstice DiskSuite oder Solaris Volume Manager-Vermittler aufweisen. Eine Plattenverkettungseinheit besteht aus einem Plattengehäuse, den realen Platten, den Kabeln vom Gehäuse zu dem/n Knoten und den Schnittstellen-Adapterkarten. Beachten Sie folgende Regeln beim Konfigurieren von Doppelverkettungsvermittlern:

  • Sie müssen jeden Plattensatz mit genau zwei Knoten als Vermittler konfigurieren.

  • Sie müssen dieselben beiden Knoten für alle Plattensätze verwenden, die Vermittler erfordern. Diese beiden Knoten müssen diese Plattensätze unterstützen.

  • Vermittler können nicht für Plattensätze konfiguriert werden, welche die Doppelverkettungs- und Zwei-Host-Anforderungen nicht erfüllen.

  Weitere Informationen finden Sie in der Online-Dokumentation unter mediator(7D).

• /kernel/drv/md.conf-Einstellungen – Alle Solstice DiskSuite-Metageräte oder Solaris 9 Solaris Volume Manager-Datenträger, die von den einzelnen Plattensätzen verwendet werden, werden im Voraus beim Rekonfigurations-Booten erstellt. Diese Rekonfiguration basiert auf den Konfigurationsparametern, die in der Datei /kernel/drv/md.conf vorhanden sind.

  ---

  Hinweis –

  In Version Solaris 10 wurde Solaris Volume Manager so verbessert, dass eine dynamische Konfiguration von Datenträgern möglich ist. Sie brauchen nicht mehr die Parameter nmd und md_nsets in der Datei /kernel/drv/md.conf zu bearbeiten. Neue Datenträger werden nach Bedarf neu erstellt.

  ---

  Sie müssen die Felder nmd and md_nsets wie folgt ändern, damit sie eine Sun Cluster-Konfiguration unter Solaris 8 oder Solaris 9 OS unterstützen:

  ---

  Caution –

  Alle Cluster-Knoten müssen identische /kernel/drv/md.conf-Dateien aufweisen, unabhängig von der Anzahl von Plattensätzen, die von jedem Knoten bedient werden. Die Nichtbeachtung dieser Richtlinie kann zu schweren Fehlern von Solstice DiskSuite oder Solaris Volume Manager und Datenverlusten führen.

  ---

  • md_nsets – Das Feld md_nsets definiert die Gesamtanzahl an Plattensätzen, die für ein System erstellt werden können, um den Anforderungen des gesamten Clusters gerecht zu werden. Stellen Sie den Wert von md_nsets auf die im Cluster erwartete Anzahl von Plattensätzen plus einem Plattensatz ein. Die Solstice DiskSuite oder Solaris Volume Manager-Software verwendet den zusätzlichen Plattensatz zum Verwalten der privaten Platten auf dem lokalen Host.

    Pro Cluster sind maximal 32 Plattensätze zulässig. Die Zahl lässt 31 Plattensätze für die allgemeine Verwendung plus einem Plattensatz für die Privatplattenverwaltung zu. Der Standardwert von md_nsets beträgt 4.

  • nmd – Das Feld nmd definiert den höchsten vorhergesagten Wert für den Namen eines Metageräts oder Datenträgers, der im Cluster vorhanden sein wird. Beispiel: Wenn der höchste Wert für den Namen eines Metageräts oder Datenträgers in den ersten 15 Plattensätzen 10 lautet, der höchste Wert für den Namen eines Metageräts oder Datenträgers im 16. Plattensatz jedoch 1000 ist, müssen Sie den Wert von nmd mindestens auf 1000 setzen. Außerdem muss der Wert von nmd groß genug sein, um zu gewährleisten, dass für jeden Geräte-ID-Namen genügend Nummern vorhanden sind. Die Zahl muss auch hoch genug sein, um sicherzustellen, dass jeder lokale Metageräte- oder Datenträgername im gesamten Cluster einmalig sein kann.

    Der höchste zulässige Wert eines Metageräte- oder Datenträgernamens pro Plattensatz beträgt 8192. Der Standardwert von nmd beträgt 128.

  Stellen Sie diese Felder bei der Installation so ein, dass auch zukünftige Erweiterungen des Clusters möglich sind. Das Erhöhen der Werte dieser Felder ist zeitaufwändig, wenn der Cluster schon produktiv ist. Das Ändern der Werte erfordert ein Rekonfigurations-Neubooten jedes Knotens. Das Anheben der Werte im Nachhinein erhöht auch die Möglichkeit von ungeeigneten Speicherplatzzuweisungen im Root-Dateisystem (/), um alle gewünschten Geräte zu erstellen.

  Halten Sie gleichzeitig den Wert der Felder nmd und md_nsets so niedrig wie möglich. Für alle möglichen Geräte sind Speicherstrukturen gemäß den Festlegungen in nmd und md_nsets vorhanden, auch wenn Sie diese Geräte nicht erstellt haben. Setzen Sie für eine optimale Leistung die Werte von nmd und md_nsets nur geringfügig höher als die Anzahl von Metageräten oder Datenträgern, die Sie zu verwenden planen.

  Weitere Informationen zur Datei md.conf finden Sie unter System and Startup Files im Solstice DiskSuite 4.2.1 Reference Guide (Solaris 8) oder System Files and Startup Files im Solaris Volume Manager Administration Guide (Solaris 9 oder Solaris 10).

SPARC: Richtlinien für die Software VERITAS Volume Manager

Beachten Sie folgende Punkte bei der Planung von Konfigurationen mit VERITAS Volume Manager (VxVM).

• Gehäusebasierte Benennung – Wenn Sie die Gehäusebasierte Benennung von Geräten verwenden, sollten Sie sicherstellen, dass einheitliche Gerätenamen für alle Cluster-Knoten verwendet werden, die denselben Speicher gemeinsam nutzen. VxVM koordiniert diese Namen nicht, weshalb der Verwalter sicherstellen muss, dass VxVM denselben Geräten dieselben Namen von unterschiedlichen Knoten zuweist. Die Nichtbeachtung der konsistenten Namenszuweisung beeinträchtigt das korrekte Cluster-Verhalten nicht. Inkonsistente Namen komplizieren jedoch die Cluster-Verwaltung und erhöhen die Wahrscheinlichkeit von Konfigurationsfehlern, die potenziell zu Datenverlusten führen können.

• Root-Plattengruppen – Ab VxVM 4.0 ist die Erstellung einer Root-Plattengruppe optional

  Eine Root-Plattengruppe kann auf folgenden Platten erstellt werden:

  • Die Root-Platte, die eingekapselt werden muss.

  • Eine oder mehrere lokale Nicht-Root-Platten, die Sie einkapseln oder initialisieren können.

  • Eine Kombination von Root- und Nicht-Root-Platten.

  Die Root-Plattengruppe muss lokal im Knoten sein.

• Einfache Root-Plattengruppen – Einfache Root-Plattengruppen (rootdg, in einem einzelnen Bereich der Root-Platte erstellt) werden von VxVM in der Sun Cluster-Software nicht als Plattentypen unterstützt. Es handelt sich hierbei um eine allgemeine VxVM-Software-Einschränkung.

• Einkapselung – Platten, die eingekapselt werden sollen, müssen zwei freie Plattenbereichs-Tabelleneinträge aufweisen.

• Anzahl von Datenträgern – Schätzen Sie bei der Erstellung der Plattengerätegruppe die maximale Anzahl von Datenträgern, die eine Plattengerätegruppe verwenden kann.

  • Wenn die Anzahl von Datenträgern weniger als 1000 beträgt, können Sie die Standard-Unternummern verwenden.

  • Wenn die Anzahl von Datenträgern 1000 oder mehr beträgt, müssen Sie sorgfältig planen, wie die Unternummern den Plattengerätegruppen-Datenträgern zugewiesen werden. Die Unternummernzuweisungen dürfen sich in keinen Plattengerätegruppen überlappen.

• Dirty Region Logging –> Verwenden von Dirty Region Logging (DRL) senkt die Wiederherstellungszeit nach einem Knotenausfall. Die Verwendung von DRL kann die E/A-Leistung senken.

• Dynamic Multipathing (DMP) – Die Verwendung von DMP zur bloßen Verwaltung mehrerer E/A-Pfade pro Knoten zum gemeinsam genutzten Speicher wird nicht unterstützt. Die Verwendung von DMP wird nur in folgenden Konfigurationen unterstützt:

  • Ein einziger E/A-Pfad pro Knoten zum gemeinsam genutzten Cluster-Speicher.

  • Eine unterstützte Multipathing-Lösung, wie zum Beispiel Sun Traffic Manager, EMC PowerPath oder Hiatchi HDLM, die mehrere E/A-Pfade pro Knoten zum gemeinsam genutzten Cluster-Speicher verwaltet.

Weitere Informationen finden Sie in der Installationsdokumentation von VxVM.

Dateisystem-Protokollierung

Die Protokollierung ist für UFS- und VxFS-Cluster-Dateisysteme erforderlich. Diese Anforderung gilt nicht für gemeinsam genutzte QFS-Dateisysteme. Die Sun Cluster-Software unterstützt folgende Möglichkeiten der Dateisystem-Protokollierung:

• Solaris UFS-Protokollierung – Weitere Informationen finden Sie in der Online-Dokumentation unter mount_ufs(1M).

• Solstice DiskSuite Transaktions-Metageräte-Protokollierung oder Solaris Volume Manager Transaktions-Datenträger-Protokollierung – Weitere Informationen finden Sie in Kapitel 2, Creating DiskSuite Objects in Solstice DiskSuite 4.2.1 User’s Guide oder Transactional Volumes (Overview) in Solaris Volume Manager Administration Guide. Transaktions-Datenträger sind ab der Solaris 10-Version von Solaris Volume Manager nicht mehr gültig.

• SPARC: VERITAS File System (VxFS) logging – Weitere Informationen finden Sie in der Online-Dokumentation zu mount_vxfs, die im Lieferumfang der VxFS-Software enthalten ist.

Die folgende Tabelle listet die Dateisystem-Protokollierung auf, die vom jeweiligen Datenträger-Manager unterstützt wird.

Tabelle 1–5 Matrix der unterstützten Dateisystem-Protokollierungen

Datenträger-Manager	Unterstützte Dateisystem-Protokollierung
Solstice DiskSuite oder Solaris Volume Manager	Solaris UFS-Protokollierung Solstice DiskSuite Transaktions-Metageräte-Protokollierung Solaris Volume Manager Transaktions-Datenträger-Protokollierung VxFS-Protokollierung
SPARC: VERITAS Volume Manager	Solaris UFS-Protokollierung VxFS-Protokollierung

Beachten Sie folgende Punkte, wenn Sie zwischen Solaris UFS-Protokollierung und Solstice DiskSuite Transaktions-Metageräte-Protokollierung bzw. Solaris Volume Manager Transaktions-Datenträger-Protokollierung für UFS-Cluster-Dateiysteme wählen:

• Es ist geplant, Solaris Volume Manager Solaris Volume Manager Transaktions-Datenträger-Protokollierung (früher Solstice DiskSuite Transaktions-Metageräte-Protokollierung) bei einer kommenden Solaris-Version aus dem Solaris-Betriebssystem zu entfernen. Solaris UFS-Protokollierung bietet dieselben Funktionen, aber höhere Leistung bei geringeren Systemverwaltungsanforderungen und -aufwand.

• Solaris UFS-Protokollgröße – Solaris UFS-Protokollierung speichert das Protokoll immer unter Verwendung von freiem Speicherplatz im UFS-Dateisystem je nach Größe des Dateisystems.

  • Bei Dateisystemen unter 1 GB belegt das Protokoll 1 MB.

  • Bei 1 GB großen oder größeren Dateisystemen belegt das Protokoll 1 MB pro GB des Dateisystems bis zu maximal 64 MB.

• Protokoll-Metagerät/Transaktions-Datenträger – Ein Solstice DiskSuite-Transaktions-Metagerät oder ein Solaris Volume Manager-Transaktions-Datenträger unterstützt UFS-Protokollierung. Die Protokollierungs-Gerätekomponente eines Transaktions-Metageräts oder Transaktions-Datenträgers ist ein Metagerät oder ein Datenträger, das Spiegeln und Striping zulässt. Sie können eine Protokollgröße bis zu maximal 1 GB erstellen, obwohl 64 MB für die meisten Dateisysteme ausreichend sind. Die Mindestprotokollgröße beträgt 1 MB.

Richtlinien für das Spiegeln

Dieser Abschnitt bietet folgende Richtlinien für die Planung der Spiegelung der Cluster-Konfiguration:

• Richtlinien für das Spiegeln von Multihost-Platten

• Richtlinien für das Spiegeln der Root-Platte

Richtlinien für das Spiegeln von Multihost-Platten

Das Spiegeln sämtlicher Multihosplatten in einer Sun Cluster-Konfiguration gewährleistet, dass die Konfiguration Ausfälle einzelner Geräte toleriert. Die Sun Cluster-Software erfordert, dass Sie alle Multihost-Platten Erweiterungseinheiten-übergreifend spiegeln. Sie müssen keine Softwarespiegelung verwenden, wenn das Speichergerät über Hardware-RAID sowie redundante Pfade zum Gerät verfügt.

Beachten Sie beim Spiegeln von Multihost-Platten folgende Punkte:

• Getrennte Plattenerweiterungseinheiten –Jeder Unterspiegel eines gegebenen Spiegels oder Plex sollte sich auf einer anderen Multihost-Erweiterungseinheit befinden.

• Festplattenkapazität – Das Spiegeln verdoppelt die erforderliche Festplattenkapazität.

• Dreifach-Spiegelung – Solstice DiskSuite oder Solaris Volume Manager-Software und VERITAS Volume Manager (VxVM) unterstützen Dreifach-Spiegelung. Die Sun Cluster-Software erfordert jedoch nur Zweifach-Spiegelung.

• Unterschiedliche Gerätegrößen – Wenn Sie ein Gerät auf ein Gerät mit unterschiedlicher Größe spiegeln, ist die Spiegelungskapazität auf die Kapazität des kleinsten Unterspiegels oder Plex beschränkt.

Weitere Informationen zu Multhost-Platten finden Sie unter Multihost-Plattenspeicher in Sun Cluster Überblick für das Betriebssystem Solaris und Sun Cluster Konzepthandbuch für Solaris OS.

Richtlinien für das Spiegeln der Root-Platte

Nehmen Sie diese Planungsinformationen in das Arbeitsblatt Lokales Dateisystem-Layout auf.

Maximale Verfügbarkeit erzielen Sie, wenn Sie root (/), /usr, /var, /opt und swap auf den lokalen Platten spiegeln. Unter VxVM kapseln Sie die Root-Platte ein und spiegeln die generierten Unterplatten. Für die Sun Cluster-Software ist es jedoch nicht erforderlich, dass Sie die Root-Platte spiegeln.

Bevor Sie entscheiden, ob Sie die Root-Platte spiegeln, wägen Sie die Risiken, die Komplexität, die Kosten und den Verwaltungsaufwand der verschiedenen Alternativen ab, die die Root-Platte betreffen. Es gibt keine Spiegelungsstrategie, die für alle Konfigurationen gültig ist. Vielleicht ist es hilfreich, die bevorzugte Lösung Ihres lokalen Sun-Servicevertreters zu kennen, wenn Sie entscheiden, ob Sie die Root-Platte spiegeln sollen.

Anweisungen zum Spiegeln der Root-Platte finden Sie in der Datenträger-Manager-Dokumentation und unter Installieren und Konfigurieren der Software Solstice DiskSuite oder Solaris Volume Manager oder SPARC: Installieren und Konfigurieren der Software VxVM .

Beachten Sie folgende Punkte, wenn Sie entscheiden, ob Sie die Root-Platte spiegeln.

• Startdatenträger – Sie können den Spiegel als bootfähige Root-Platte konfigurieren. Sie können dann vom Spiegel booten, wenn der Primär-Startdatenträger ausfällt.

• Komplexität – Das Spiegeln der Root-Platte macht die Systemverwaltung komplexer. Durch das Spiegeln der Root-Platte wird auch das Booten im Einzelbenutzermodus komplizierter.

• Sicherungen – Unabhängig davon, ob Sie die Root-Platte spiegeln oder nicht, sollten Sie regelmäßig Sicherungskopien des Root erstellen. Das Spiegeln allein schützt nicht vor Verwaltungsfehlern. Nur ein Sicherungsplan ermöglicht Ihnen, Dateien wiederherzustellen, die unbeabsichtigt geändert oder gelöscht wurden.

• Quorum-Geräte – Verwenden Sie keine als Quorum-Gerät konfigurierte Platte zum Spiegeln einer Root-Platte.

• Quorum – Unter der Software Solstice DiskSuite oder Solaris Volume Manager können Sie bei einem Ausfallszenario mit verloren gegangenem Zustands-Datenbankquorum das System erst neu booten, wenn die Wartung erfolgt ist. Informationen zu Zustands-Datenbanken und Zustands-Datenbankreplikate finden Sie in der Dokumentation zu Solstice DiskSuite oder Solaris Volume Manager.

• Getrennte Controller – Höchste Verfügbarkeit wird erreicht, wenn die Root-Platte auf einem getrennten Controller gespiegelt wird.

• Sekundäre Root-Platte – Bei einer gespiegelten Root-Platte kann die primäre Root-Platte ausfallen und die Arbeit dennoch auf der (gespiegelten) sekundären Root-Platte fortgesetzt werden. Später kann die primäre Root-Platte, zum Beispiel nach einem Kurzschluss oder vorübergehenden E/A-Fehlern, wieder in Betrieb genommen werden. Die nachfolgenden Boot-Vorgänge werden dann auf der primären Root-Platte durchgeführt, die für den eeprom(1M) boot-device-Parameter angegeben ist. In diesem Fall erfolgen keine manuellen Reparaturarbeiten, doch das Laufwerk beginnt ausreichend gut zu arbeiten, um zu starten. Bei der Solstice DiskSuite oder Solaris Volume Manager-Software erfolgt eine Resynchronisierung. Eine Resynchronisierung erfordert einen manuellen Schritt, wenn das Laufwerk wieder in Betrieb genommen wird.

  Wenn Änderungen an Dateien der (gespiegelten) sekundären Root-Platte vorgenommen wurden, sind diese beim Starten der primären Root-Platte nicht vorhanden. Diese Bedingung führt zu einem veralteten Unterspiegel. Änderungen an der Datei /etc/system würden zum Beispiel verloren gehen. Bei der Solstice DiskSuite oder Solaris Volume Manager-Software können manche Verwaltungsbefehle die Datei /etc/system geändert haben, während die primäre Root-Platte außer Betrieb war.

  Das Boot-Programm prüft nicht, ob das System von einem Spiegel oder vom zugrunde liegenden realen Gerät bootet. Wenn die Metageräte oder Datenträger geladen sind, wird die Spiegelung durch den Boot-Prozess eine aktive Bahn. Daher ist das System bis zu diesem Punkt für Probleme aufgrund veralteter Unterspiegel anfällig.