Best Practices für die Thin-Provisioning von Linux-Servern (auf VMware)

Ich habe ein Setup von ungefähr 20 Linux-Maschinen mit jeweils ungefähr 30-150 Gigabyte Kundendaten. Wahrscheinlich wird die Datengröße auf einigen Computern erheblich schneller wachsen als auf anderen. Dies sind virtuelle Maschinen in einem VMware vSphere-Cluster. Die Disk-Images werden auf einem SAN-System gespeichert.

Ich versuche, eine Lösung zu finden, die den Speicherplatz sparsam nutzt und gleichzeitig das einfache Wachstum einzelner Computer ermöglicht.

Theoretisch würde ich einfach große Festplatten für jede Maschine erstellen und Thin Provisioning verwenden. Jede Festplatte würde nach Bedarf wachsen. Es scheint jedoch, dass ein 500 GB ext3-Dateisystem mit nur 50 GB Daten und einer relativ geringen Anzahl von Schreibvorgängen das Festplatten-Image immer noch leicht auf z. 250 GB im Laufe der Zeit. Oder mache ich hier etwas falsch? (Ich war überrascht, wie wenig ich bei Google zu diesem Thema gefunden habe. Übrigens gibt es auf serverfault.com sogar kein Thin-Provisioning-Tag.)

Derzeit plane ich, große Festplatten mit Thin Provisioning zu erstellen - allerdings mit einem kleinen LVM-Volume. Beispiel: Ein 100-GB-Volume auf einer 500-GB-Festplatte. Auf diese Weise konnte ich das LVM-Volumen und die Dateisystemgröße bei Bedarf auch online einfacher erhöhen.

Nun zur eigentlichen Frage:

Gibt es dafür bessere Möglichkeiten? (Das heißt, um die Datengröße nach Bedarf ohne Ausfallzeiten zu erhöhen.)

Mögliche Lösungen sind:

• Verwenden eines Thin-Provisioning-freundlichen Dateisystems, das versucht, immer wieder dieselben Stellen zu belegen, wodurch die Bildgröße nicht vergrößert wird.

• Eine einfache Methode finden, um freien Speicherplatz auf der Partition zurückzugewinnen (erneutes Ausdünnen?)

• Etwas anderes?

Eine Bonusfrage: Wenn ich meinen aktuellen Plan verwende, würden Sie empfehlen, Partitionen auf den Datenträgern ( pvcreate /dev/sdX1vs pvcreate /dev/sdX) zu erstellen ? Ich denke, es ist gegen Konventionen, Raw-Festplatten ohne Partitionen zu verwenden, aber es würde es ein bisschen einfacher machen, die Festplatten zu vergrößern, falls dies jemals benötigt wird. Das ist alles nur Geschmackssache, oder?

Wenn ich Thin Provisioning richtig verstehe, kann es wirklich zu Problemen kommen, wenn Sie das Wachstum Ihres VMFS-Dateisystems nicht genau überwachen und Ihren VMDKs erlauben, Ihre VMFS-Volumes zu füllen. Sie haben bei Ihren Tests festgestellt, dass Thin Provisioning-Festplatten dazu neigen, ihren verfügbaren Speicherplatz schnell zu füllen, und dass sie keinen Speicherplatz zurückfordern können, der möglicherweise innerhalb des Betriebssystems frei ist.

Die andere Option besteht darin, ausreichend große VMDK-Dateien zu erstellen, um Ihre aktuelle Nutzung und die erwarteten Wachstumsspitzen zu bewältigen, und einfach weitere VMDK-Dateien hinzuzufügen, wenn Ihre Anwendungsdatennutzung zunimmt. Neue VMDK-Dateien können live zu einer VM hinzugefügt werden. Sie müssen sie nur erneut scannen (Echo "- - -"> / sys / class / scsi_host / host? / Scan). Sie können die neue Festplatte partitionieren, Ihrem LVM hinzufügen und das Dateisystem live erweitern. Auf diese Weise wissen Sie immer, wie viel Speicherplatz jeder der VMs zugewiesen ist, und Sie können Ihr VMFS nicht versehentlich innerhalb eines Gasts ausführen.

Was die Partitionierung betrifft oder nicht, wenn die Festplatte nur von LVM verwendet werden soll, partitioniere ich immer. Durch die Partitionierung der Festplatte wird verhindert, dass beim Starten des Computers Warnungen vor gefälschten Partitionstabellen angezeigt werden, und es wird klargestellt, dass die Festplatte zugewiesen ist. Es ist ein bisschen Voodoo, aber ich stelle auch sicher, dass die Partition bei 64 gestartet wird, um sicherzustellen, dass die Partition und das Dateisystem blockorientiert mit dem zugrunde liegenden Speicher ausgerichtet sind. Es ist schwer zu erkennen und zu kategorisieren, da Sie normalerweise nichts haben, mit dem Sie leicht vergleichen können. Wenn das Betriebssystem-Dateisystem jedoch nicht richtig mit dem zugrunde liegenden Speicher ausgerichtet ist, können zusätzliche IOPS erforderlich sein, um Anforderungen zu bearbeiten, die Blockgrenzen überschreiten zugrunde liegender Speicher.

Der beste Vorschlag, den ich mir vorstellen kann, ist, ein LVM-Setup mit physischen Volumes, Volume-Gruppen und logischen Volumes zu erstellen und diese logischen Volumes dann über iSCSI als Dateisystem Ihrer VM bereitzustellen .

Auf diese Weise können Sie die Größe des logischen Volumes ändern. Anschließend müssen Sie lediglich Ihren iscsi-Daemon und die Software für virtuelle Maschinen neu starten, überprüfen, ob die neuen Größenparameter vorhanden sind, und die Größe des Dateisystems des Gasts entsprechend anpassen.

Die Partitionierung würde wie bei einer Standard-Festplatte funktionieren, da der LV dem Gast der virtuellen Maschine auf diese Weise angezeigt wird.

Bearbeiten: egal, ich habe den falschen Eindruck, dass Sie VMware unter Linux ausgeführt haben, nicht Linux unter VMware.

Ich weiß nicht, wie es in VMware funktioniert, aber Redhat RHEV-M / RHEV-H ist möglich und es unterstützt RHEL 4.8 bis 5.X und gleichzeitig für Win 2k3 R2 und Win 2k8. Weitere Informationen finden Sie unter http://studyhat.blogspot.com/2010/05/rhev-for-servers-22-installation-and.html

Anderer Vorschlag: Richten Sie einen Dateiserver ein, der alle Ihre Benutzerdaten enthält.

Dieser Dateiserver sollte natürlich mit LVM für Ihre Online-Kapazitätsverwaltungszwecke verwaltet werden.

Wenn Sie möchten, können Sie ein Ha-Setup (drbd + heartbeat) mit einer Kopie Ihres Dateiservers im SAN und einer zweiten Kopie außerhalb oder ähnlich erstellen. (für die Paranoiden)

Da Ihre Clients auf Linux basieren, können Sie NFS verwenden, das angeblich schneller als Samba ist. Ein FileServer ermöglicht Ihnen eine zentralisierte Sicherungsstrategie sowie eine zentralisierte Überwachung der Speichernutzung. Und in Bezug auf Ihre Thin Provisioning-Frage:

Erstellen Sie Ihr LVM-Setup wie beabsichtigt (in Ihrem Beispiel 100 GB LV auf einem 500 GB PV ändern Sie einfach die Zahlen, die der Summe des von Ihren VMs benötigten Speichers entsprechen). Erweitern Sie diesen LV bei Bedarf, wie Sie es in jeder VM separat geplant haben. Aber machen Sie es einfach EINMAL auf Ihrem Dateiserver. Jedes Mal, wenn eine VM ihre Speichernutzung reduziert, wird Speicherplatz für alle Ihre VMs verfügbar ;-)

Verwenden Sie bei Bedarf oder Wunsch Kontingente auf Ihrem Dateiserver, um zu verhindern, dass eine einzelne VM Ihren Dateiserver füllt.

Können Sie ein Volume erweitern, ohne die virtuelle Maschine damit herunterzufahren? Ich mache das normalerweise, aber ich weiß nicht, wie Ihr Speicher-Setup aussieht oder wie VMware die Dinge komplizieren könnte. Wenn du kannst, würde ich das tun

1) Dünne Vorsorge nicht. Stellen Sie jedes Volume auf die Größe ein, die Sie für erforderlich halten. 2) Verwenden Sie keine Partitionen. Machen Sie jedes Dateisystem zu einem eigenen Volume. 3) Überwachen Sie das Wachstum des Dateisystems, damit Sie die Größe der Volumes proaktiv ändern können.

Wenn es darum geht, ein Volumen zu vergrößern

1) Führen Sie in Ihrem SAN oder in VMware alles aus, um das Volume zu erweitern. 2) Führen Sie unter Linux aus echo 1 > /sys/block/EXAMPLE/device/rescan, wobei BEISPIEL die Gerätenamen unter / sys / block / sind. 3) Führen Sie unter Linux aus resize2fs /dev/EXAMPLE, wobei BEISPIEL der Gerätename unter / dev ist.

Dieser Ansatz funktioniert gut für mich. Ich habe Ihren Ansatz mit Thin Provisioning und LVM in Betracht gezogen, und ich denke, es würde auch funktionieren.

Wenn Sie sich für die LVM-Route entscheiden, empfehle ich, die Festplatten nicht zu partitionieren. Wie Sie bereits sagten, erleichtert das Fehlen einer Partitionstabelle das Wachstum der virtuellen Festplatte. Ohne Partitionstabelle können Sie einfach pvresize ausführen und Linux erkennt, dass das physische Volume gewachsen ist. Bei einer Partitionstabelle müssen Sie alle Dateisysteme aushängen, die Partitintabelle löschen, die Partitionstabelle neu erstellen und dann pvresize ausführen. Das ist viel mehr Arbeit und erfordert Ausfallzeiten.