C: \ ist für OS, D: \ ist für Data?


9

"Damals" haben wir unsere Betriebssystemlaufwerke (in Windows) immer von unseren Datenlaufwerken getrennt. In der Linux-Welt bin ich mir bewusst, dass die Weisheit noch mehr Volumes vorschreibt, die in einer Best-Practice-Konfiguration definiert und verwendet werden, obwohl ich mit ihr viel weniger vertraut bin.

Ist es nun wirklich wichtig, dass sich der Serverspeicher mit gleicher Wahrscheinlichkeit in einem SAN befindet (in dem die Festplattenressourcen von vielen einzelnen Betriebssystemen und Anwendungen gemeinsam genutzt werden), ob das Betriebssystem und die Datenpartitionen auf Volume-Ebene getrennt werden?

Was sind deine Gedanken?

Antworten:


7

Es gibt drei Haupttreiber für die Trennung von Betriebssystem und Daten in Bezug auf die Speicherung.

  1. Raum . Wie ErikA betont, möchten Sie wirklich nicht, dass auf Ihrem Betriebssystem kein Speicherplatz mehr zur Verfügung steht. Alle möglichen schlechten Dinge können passieren. Trennung dieser beiden Wachstumsmethoden
  2. E / A-Zugriffsanforderungen . Die Art der E / A, die auf Ihrem Betriebssystemvolume verwendet wird, unterscheidet sich im Allgemeinen stark von der Art, die von Ihren Datenvolumes verwendet wird. Die Trennung Ihrer E / A-Typen ist auf vielen Ebenen eine sehr gute Idee.
  3. Portabilität des Speichers . Wenn es an der Zeit ist, Ihr Server-Betriebssystem zu aktualisieren, können Sie das Betriebssystem-Volume nuken und alle Daten behalten. In SAN- oder VM-Umgebungen können Sie das Datenvolumen einfach auf einen neuen, frisch installierten Server verschieben und Zeit bei Upgrades sparen.

Bei einigen Betriebssystemen (darunter auch Windows) ist die Größenänderung des Betriebssystemvolumens nicht besonders hilfreich. Das bedeutet, dass Sie im Allgemeinen so viel davon angeben müssen, wie es in der Lebensdauer benötigt wird, wenn Sie den Server formatieren. Vergleichen Sie dies mit Datenvolumes, deren Größe über die gesamte Lebensdauer eines Servers häufig geändert werden kann. Selbst in vollständig virtualisierten Umgebungen, in denen sich das Betriebssystem und die Datavolumes selbst im selben Speicher befinden, kann es ein großes Problem sein, die Größe Ihres Betriebssystems nicht ändern zu können. Windows 2008+ empfiehlt derzeit 30 GB für das Laufwerk C: \, weit entfernt von den 10 GB, die wir auf Server 2003 verwendet haben. Dies ist etwas, das viele Windows-Administratoren bei der Umstellung von 2003 auf 2008 beeindrucken wird.


Dies sind gute Punkte, die tiefere Probleme im Zusammenhang mit der gemeinsamen Speicherverwaltung betreffen. Beispiel: Wenn sich C: und D: in derselben RAID-Konfiguration usw. auf demselben Spindelsatz befinden, können Sie keine Optimierung für den E / A-Typ durchführen. Für die Speicherportabilität ist es gleichermaßen wichtig, sicherzustellen, dass die C- und D-Laufwerke tatsächlich unterschiedliche LUNs sind, unabhängig davon, welches Objekt den virtuellen Speicher sichert. Andernfalls, wenn es sich nur um Partitionen auf derselben LUN handelt, können Sie keine auf einen neuen Server verschieben, ohne eine vollständige Kopie zu erstellen.
Jeremy

12

Ja, mit Sicherheit trennen Sie das Betriebssystem von den Daten. Ich habe es immer wieder gesehen, wenn bei einer gemeinsam genutzten Partition die Partition voll wird und es unmöglich ist, das Betriebssystem zu patchen, die Partition nicht zu erweitern (aus verschiedenen Gründen) usw.

IMO, der Aufwand für die Verwaltung von zwei Partitionen ist ein geringer Preis für die bereitgestellte Isolation.

In Bezug auf die von Ihnen erwähnten SAN-gesicherten Systeme schützt Sie dies immer noch nicht vor Daten, die Ihre Betriebssystempartition ausfüllen. Mit vollständig virtualisiertem Speicher müssen Sie sich nicht so viele Sorgen machen, dass Betriebssystem und Daten auf getrennten Spindeln gespeichert sind.


Komisch, die Gründe, die Sie für die Trennung von Betriebssystem und Daten angeben, sind in der Tat genau die Gründe, die ich dafür habe, dies NICHT zu tun.
John Gardeniers

Ja, ich nehme an, es gibt Fälle (insbesondere bei nicht virtualisierten Servern mit direkt angeschlossener Festplatte), in denen es vorteilhaft sein kann, einen großen Eimer Festplatte zur Verfügung zu haben.
EEAA,

Interessanterweise bootet mein Windows-Betriebssystem von Laufwerk F: und mein zusätzliches
Brian Knoblauch

2

Ich würde sagen, es hängt davon ab, was Sie mit dem System machen. Wenn Sie das Betriebssystem möglicherweise neu installieren müssen, können Sie sich Ärger ersparen, indem Sie alle Ihre Daten auf einer separaten Partition ablegen. Ansonsten sehe ich die Notwendigkeit nicht mehr. Meine zwei Cent.


2

Im Allgemeinen halte ich es für eine gute Idee, den Standard-Betriebssystemspeicher (wie C :) von den Daten (D :) zu trennen, aber ich würde auch empfehlen, eine kleinere Partition für Protokolldateien (L :) zu erstellen, um sie ein wenig zu behalten sicherer machen und einige Arten von Denial-of-Service-Angriffen verhindern.

Linux ist sehr gut darin, dass das Dateisystem hierarchisch unter einem Stammverzeichnis bleibt, unabhängig davon, wie viele physische Festplatten oder virtuelle Partitionen Sie verwenden. Ich würde definitiv die Festplatte partitionieren, aber nicht unbedingt für die Trennung von Daten und Betriebssystem (da die beiden sowieso sehr oft verwechselt werden).

Ich würde schauen:

  1. Welche Unterverzeichnisse füllen wahrscheinlich ihre Festplatte und verursachen Speicherplatzprobleme für andere Verzeichnisse (z. B. Partition aus / home und / var / log).
  2. Ob verschiedene Teile Ihrer Verzeichnisstruktur aus Leistungsgründen unterschiedliche Dateisysteme benötigen (z. B. XFS für die Stabilität, Ext3 für die allgemeine Verwendung usw.)
  3. Welche Verzeichnisse in Zukunft möglicherweise erweitert werden müssen - dies sind gute Kandidaten für die Partitionierung, da Sie einfach das Verzeichnis umbenennen, einen neuen Satz von Speicherplatz in den Verzeichnisspeicherort partitionieren und bereitstellen und die Daten von den alten in die neuen kopieren können Standort.

2

Bisherige Empfehlungen für die Partitionierung von Linux (naja, eigentlich Unix) beruhen teilweise auf der Entstehung eines (vernetzten) Mainframe-Server-Betriebssystems, das wiederum vermutlich von der (damals) relativen Unzuverlässigkeit der Hardware beeinflusst wurde. Zum Beispiel wurden Protokolle und temporäre Daten in der Regel getrennt, weil diese Speicherbereiche sehr abgenutzt waren, aber es war kein großes Problem, wenn sie verloren gingen.

Wenn Sie ein Desktop-System erstellen, würde ich den Daten- / Nicht-Daten- / Swap-Split wählen. Wenn Sie keinen Server erstellen, der ernsthafte Probleme mit sich bringt, werden Dinge wie / usr / local und / var / tmp nur zu einem Problem bei der Speicherplatzzuweisung.


Ich würde sagen, Protokolle und temporäre Dateien waren getrennt, da sie möglicherweise von einem betrügerischen Benutzer erstellt wurden - da das Betriebssystem normalerweise eine gemeinsame Mehrbenutzerumgebung ist. Ich war mir nicht sicher, ob Zuverlässigkeit eine Rolle spielt.
gbjbaanb

0

Ich würde sagen, es ist immer noch schön zu haben - Sie haben 100 GB an Daten (zu viel Pr0n-Typ :)) und Sie müssen das Betriebssystem neu installieren (oder, entsprechend dem Windows-Verlauf, regelmäßig neu installieren, um die vorhandenen Daten zu entfernen) cruft) dann ist es sehr einfach, es intakt zu halten, als wenn es auch auf der C-Partition wäre.

Ich würde jedoch sagen, dass es dort ein Problem gibt, da Windows besonders gerne alle Arten von Dingen in Verzeichnissen auf dem Laufwerk C ablegt - es ist nicht nur das Benutzerverzeichnis, sondern alle App-Daten und verschiedene Teile, die am Ende hängen bleiben auch in ProgramData.

Es gibt noch einen weiteren Faktor - abgesehen von den wirklich großen Dingen (ja, das ist wieder pr0n) gibt es viele Online-Backup-Tools (oder lokale Backup-Dienstprogramme), die fortlaufende Backups durchführen. In Anbetracht dessen ist es nicht so wichtig, die Daten zu trennen, da Sie sie einfach vom Sicherungsspeicherort wiederherstellen können.

Persönlich versuche ich, Daten + OS aufzuteilen. Ich versuche auch, Apps auf einer anderen Partition zu platzieren, sodass meine Betriebssystem-Backups viel kleiner sind.


0

Ich werde der Anwalt des Teufels für eine andere Denkschule sein.

Angenommen, Ihr Anbieter empfiehlt aus Leistungsgründen, dass die Betriebssystempartition nicht "spärlich" ist, und möchte, dass Sie die vollständige Betriebssystempartition im Voraus zuweisen. Dies führt zu 10 GB bis 20 GB (oder mehr) nicht verwendetem Speicherplatz auf dem SAN-Laufwerk.

Dies ist in Ordnung für eine einzelne VM, aber es besteht die Möglichkeit, dass Sie über mehrere "leistungskritische" Server mit jeweils 10 bis 20 GB Leerraum-Overhead verfügen. In unserer Umgebung machte dieser Whitespace 20% unserer SAN-Festplatte aus. Denken Sie daran, dass es Grenzen gibt, bis zu denen wir eine SAN-Festplatte füllen sollten (aber das ist eine andere Geschichte).

Das Management hatte die Wahl

1) Absorbieren Sie den zu 20% verschwendeten Speicherplatz im SAN, der zusätzlich zu den anderen Anforderungen für "weißen Speicherplatz" erforderlich ist, und isolieren Sie eventuell auftretende Szenarien für "vollständige Festplatte"

2) Legen Sie alles auf das Laufwerk C: \ und riskieren Sie, dass sich das Laufwerk aufgrund von Anwendungsprotokollen füllt.

Was haben Sie gemacht?

In Anbetracht der Tatsache, dass Windows 2008R2 das Laufwerk C: \ des Host-Betriebssystems dynamisch erweitern und das Laufwerk, wenn es voll ist, erweitern kann, hat das Management die Kosteneinsparungen in Kauf genommen und sie in Überwachungstools wie SCOM reinvestiert.

Jetzt erhalten wir mehr als nur den einfachen Schutz einer C: \ Laufwerksfüllung, aber wir verfügen über eine umfassendere Systemüberwachung, um andere Probleme zu beheben, bevor dies geschieht.


Thin-Provisioned-SAN-Volumes neigen dazu, aufgrund der Datenabwanderung im Laufe der Zeit eine Thick-Provisioning-Funktion zu erhalten, es sei denn, auf dem Betriebssystem wird Software ausgeführt, die nach dem Löschen einer Datei wieder mit dem SAN kommuniziert. In einer SAN-Umgebung ist es im Allgemeinen besser, dem Startlaufwerk nur so viel Speicherplatz zuzuweisen, wie erforderlich, und zu akzeptieren, dass alles rechtzeitig verbraucht wird. SAN macht es allerdings komplizierter, das gebe ich dir! Möglicherweise hätten Sie sowohl für C: als auch für D: ein einzelnes SAN-Volume zuweisen können (abhängig von vielen anderen Faktoren, z. B. Festplattenleistung und Workload-Anforderungen).
Jeremy
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.