Hallo ML,
ich habe drei HP ProLiant Server, bei denen der Speicherplatz langsam ausgeht. Zur Erweiterung schwebt mir eine zentrale Lösung vor. Ich schwanke zwischen iSCSI und FC. iSCSI scheint mir billiger zu sein. Ich habe wichtige Ordner wie /var, /opt, /home ... auf einzelne LV's gelegt, um sie bei Bedarf vergrößern zu können. Brauche ich mehr Platz, packe ich einfach ein PV dazu und kann anschließend das LV vergrößern. Fragen: 1. Kann ich über iSCSI ein PV erstellen ? Sprich, ich habe in einem zentralen Storage eine Partition (Platte, vdisk, Volume, wie auch immer), das ich im host per iSCSI einbinde, und sage dann auf dem host, Du bist ein PV. 2. Im Bootprozess von Linux werden die Partitionen gemountet, _bevor_ das Netzwerk aktiviert wird. Da eine iSCSI-Karte letztlich auch nur eine normale Netzwerkkarte, sehe ich folgendes Problem: wie kann ich die Partitionen mounten (die ja teilweise auf dem zentralen Storage liegen), wenn ich noch kein Netzwerk habe ? Any ideas ? Gibt es "intelligente" Netzwerkkarten für iSCSI, die vielleicht bereits eine IP-Konfiguration haben und iSCSI sprechen, lange bevor das Netzwerk von Linux gestartet wird ? Damit wären alle Partitionen vor dem Mounten sichtbar.
Ich hoffe, Ihr könnt mich ein wenig erhellen.
Bernd
-- Bernd Lentes Systemadministration Institut für Entwicklungsgenetik HelmholtzZentrum münchen bernd.lentes@helmholtz-muenchen.de phone: +49 89 3187 1241 fax: +49 89 3187 3826 http://www.helmholtz-muenchen.de/idg Aufsichtsratsvorsitzende: MinDir'in Bärbel Brumme-Bothe Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum Registergericht: Amtsgericht München HRB 6466
Zeit ist keine Schnellstrasse zwischen Wiege und Grab, sondern Platz zum Parken in der Sonne
Hallo zusammen,
On Donnerstag 26 August 2010, Lentes, Bernd wrote:
wie kann ich die Partitionen mounten (die ja teilweise auf dem zentralen Storage liegen), wenn ich noch kein Netzwerk habe ?
Dafür gibt es den Parameter "_netdev". Siehe man mount.
Liebe Grüße
Erik
Erik Roderwald schrieb:
Dafür gibt es den Parameter "_netdev". Siehe man mount.
Liebe Grüße
Erik
Hallo Erik,
ich habe auch /opt, /tmp, /usr und /var auf LV's liegen. Wenn diese LV's nun auf iSCSI-devices lägen, wäre das dann nicht zu spät zum Mounten, wenn auf das Netzwerk gewartet würde ? So starten einige init-skripte bereits Programme, die auf /usr liegen, bevor das Netzwerk gestartet wird (lt. /var/log/boot,msg).
Bernd-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo zusammen,
On Donnerstag 26 August 2010, Lentes, Bernd wrote:
ich habe auch /opt, /tmp, /usr und /var auf LV's liegen. Wenn diese LV's nun auf iSCSI-devices lägen, wäre das dann nicht zu spät zum Mounten, wenn auf das Netzwerk gewartet würde ? So starten einige init-skripte bereits Programme, die auf /usr liegen, bevor das Netzwerk gestartet wird (lt. /var/log/boot,msg).
Das Schöne an Linux ist, dass man alles konfigurieren kann, auch die Reihenfolge, in der die Dienste/Programme beim Systemstart geladen werden. Das ist ein wenig Fummelkram, geht aber. Ob das in Deinem konkreten Fall zum Erfolg führt, kann ich Dir nicht sagen, da ich nicht weiß, was wann warum geladen wird. Aber im Prizip kannst Du das Laden des Netzwerkes vor alle Dienste stellen, die aus dem Netz geladen werden sollen.
Liebe Grüße
Erik
Am Donnerstag, 26. August 2010 schrieb Lentes, Bernd:
Hallo ML,
ich habe drei HP ProLiant Server, bei denen der Speicherplatz langsam
...
ein PV dazu und kann anschließend das LV vergrößern. Fragen:
- Kann ich über iSCSI ein PV erstellen ? Sprich, ich habe in einem
zentralen Storage eine Partition (Platte, vdisk, Volume, wie auch immer), das ich im host per iSCSI einbinde, und sage dann auf dem host, Du bist ein PV.
so wie ich das verstehe, ist iSCSI eine Art remote-SCSI - also kannst Du auf dieser Ebene (fast) alles tun, was Du auch mit einer lokalen Platte kannst. Nur dass Du (auf einer tieferen Ebene) eben das Plattensystem auch noch logisch verwalten kannst.
- Im Bootprozess von Linux werden die Partitionen gemountet, _bevor_
das Netzwerk aktiviert wird. Da eine iSCSI-Karte letztlich auch nur eine normale Netzwerkkarte, sehe ich folgendes Problem: wie kann ich die Partitionen mounten (die ja teilweise auf dem zentralen Storage liegen), wenn ich noch kein Netzwerk habe ? Any ideas ? Gibt es "intelligente" Netzwerkkarten für iSCSI, die vielleicht bereits eine IP-Konfiguration haben und iSCSI sprechen, lange bevor das Netzwerk von Linux gestartet wird ? Damit wären alle Partitionen vor dem Mounten sichtbar.
Abgesehen von dem Parameter, den Erik erwähnt hat: iSCSI ist nicht normales IP-Netzwerk (und meines Wissens auch nicht auf derselben Leitung dazu kompatibel, da lasse ich mich aber gerne eines Besseren belehren ;-) ).
Gruß Martin
Martin Hofius schrieb:
- Im Bootprozess von Linux werden die Partitionen
gemountet, _bevor_
das Netzwerk aktiviert wird. Da eine iSCSI-Karte letztlich auch nur eine normale Netzwerkkarte, sehe ich folgendes Problem: wie
kann ich
die Partitionen mounten (die ja teilweise auf dem zentralen Storage liegen), wenn ich noch kein Netzwerk habe ? Any ideas ?
Gibt es "intelligente"
Netzwerkkarten für iSCSI, die vielleicht bereits eine
IP-Konfiguration
haben und iSCSI sprechen, lange bevor das Netzwerk von
Linux gestartet
wird ? Damit wären alle Partitionen vor dem Mounten sichtbar.
Abgesehen von dem Parameter, den Erik erwähnt hat: iSCSI ist nicht normales IP-Netzwerk (und meines Wissens auch nicht auf derselben Leitung dazu kompatibel, da lasse ich mich aber gerne eines Besseren belehren ;-) ).
Ich dachte, iSCSI setzt voll auf IP und tcp auf, das wäre gerade der Vorteil von iSCSI. "Gleichzeitig Vor- und Nachteil der iSCSI-Technologie ist die Kapselung der Pakete in Ethernet und TCP/IP. Erster wesentlicher Vorteil ist die Basierung auf Ethernet-Netzwerkstandards, bei iSCSI nutzt das Storage-Netzwerk die gleiche Technologie und Komponenten (Verkabelung, Switche, Router) wie das restliche Netzwerk." siehe: http://de.wikipedia.org/wiki/ISCSI
Bernd-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On 26.08.2010 12:47, Lentes, Bernd wrote:
Martin Hofius schrieb:
- Im Bootprozess von Linux werden die Partitionen
gemountet, _bevor_
das Netzwerk aktiviert wird. Da eine iSCSI-Karte letztlich auch nur eine normale Netzwerkkarte, sehe ich folgendes Problem: wie
kann ich
die Partitionen mounten (die ja teilweise auf dem zentralen Storage liegen), wenn ich noch kein Netzwerk habe ? Any ideas ?
Gibt es "intelligente"
Netzwerkkarten für iSCSI, die vielleicht bereits eine
IP-Konfiguration
haben und iSCSI sprechen, lange bevor das Netzwerk von
Linux gestartet
wird ? Damit wären alle Partitionen vor dem Mounten sichtbar.
Ja, es gibt auch iSCSI-Adapter, aber billiger als FC-Adapter sind die auch nicht.
Abgesehen von dem Parameter, den Erik erwähnt hat: iSCSI ist nicht normales IP-Netzwerk (und meines Wissens auch nicht auf derselben Leitung dazu kompatibel, da lasse ich mich aber gerne eines Besseren belehren ;-) ).
Du kannst durchaus auf der gleichen Leitung ganz normal deine Netzwerk-Verbindung haben und parallel die iSCSI-Verbindung aufbauen, aber sinnvoll ist das nicht, wenn du vernünftige Leistung erwartest.
Ich dachte, iSCSI setzt voll auf IP und tcp auf, das wäre gerade der Vorteil von iSCSI. "Gleichzeitig Vor- und Nachteil der iSCSI-Technologie ist die Kapselung der Pakete in Ethernet und TCP/IP. Erster wesentlicher Vorteil ist die Basierung auf Ethernet-Netzwerkstandards, bei iSCSI nutzt das Storage-Netzwerk die gleiche Technologie und Komponenten (Verkabelung, Switche, Router) wie das restliche Netzwerk." siehe: http://de.wikipedia.org/wiki/ISCSI
Wenn du iSCSI vernünftig nutzen willst (nicht nur Testbetrieb), dann brauchst du eine eigenes Netz dafür. Der Overhead ist nicht zu vernachlässigen. Wenn du gute Leistung und geringe Latenzen brauchst (Datenbankbetrieb oder ähnliches), dann nimm besser FC.
Sandy Drobic schrieb:
Wenn du iSCSI vernünftig nutzen willst (nicht nur Testbetrieb), dann brauchst du eine eigenes Netz dafür. Der Overhead ist nicht zu vernachlässigen. Wenn du gute Leistung und geringe Latenzen brauchst (Datenbankbetrieb oder ähnliches), dann nimm besser FC.
Hallo Sandy,
wie gesagt, ich schwanke zwischen iSCSI und FC. iSCSI schien mir billiger. Wie ist das denn bei Partitionen, die auf SAN's liegen, die per FC angebunden sind ? Sind die direkt für Linux verfügbar oder muss da auch noch eine "Netzwerkinitialisierung" o.ä. stattfinden ? Ab wann wären denn diese Partitionen im Bootprozess verfügbar ?
Bernd-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On 26.08.2010 14:48, Lentes, Bernd wrote:
Sandy Drobic schrieb:
Wenn du iSCSI vernünftig nutzen willst (nicht nur Testbetrieb), dann brauchst du eine eigenes Netz dafür. Der Overhead ist nicht zu vernachlässigen. Wenn du gute Leistung und geringe Latenzen brauchst (Datenbankbetrieb oder ähnliches), dann nimm besser FC.
Hallo Sandy,
wie gesagt, ich schwanke zwischen iSCSI und FC. iSCSI schien mir billiger. Wie ist das denn bei Partitionen, die auf SAN's liegen, die per FC angebunden sind ? Sind die direkt für Linux verfügbar oder muss da auch noch eine "Netzwerkinitialisierung" o.ä. stattfinden ? Ab wann wären denn diese Partitionen im Bootprozess verfügbar ?
Wir booten einige Server direkt aus dem SAN, die Server selbst haben gar keine Festplatten mehr.
Das echte Problem, das bei uns bleibt, ist die Multipath Software, die uns bei jedem Kernelupdate um die Ohren fliegt, da nicht die bei RedHat beiliegende Version mit unserem SAN zusammenarbeitet.
Sandy Drobic schrieb:
Wir booten einige Server direkt aus dem SAN, die Server selbst haben gar keine Festplatten mehr.
Das echte Problem, das bei uns bleibt, ist die Multipath Software, die uns bei jedem Kernelupdate um die Ohren fliegt, da nicht die bei RedHat beiliegende Version mit unserem SAN zusammenarbeitet.
-- Sandy
Hi,
Habt Ihr das von mir beschriebene Szenario auch, einzelne Partitionen auf dem SAN ? Falls ja, sind die direkt verfügbar ? Multipath scheidet im Moment wohl eher aus, aus Kostengründen.
Bernd-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On 26.08.2010 15:32, Lentes, Bernd wrote:
Habt Ihr das von mir beschriebene Szenario auch, einzelne Partitionen auf dem SAN ? Falls ja, sind die direkt verfügbar ?
Was ich getestet hatte, war entweder eine nicht systemrelevante Partition (also reine Datenpartition für eine Anwendung) oder komplett aus dem SAN. Deine Anforderung ist etwas exotisch. (^-^)
Multipath scheidet im Moment wohl eher aus, aus Kostengründen.
Dann würde ich wohl doch zu einem iSCSI-Adapter greifen. Wenn das auch zu teuer wird, sind ein paar lokele Platten mehr wohl doch die einfachere Wahl.
Sandy Drobic schrieb:
Habt Ihr das von mir beschriebene Szenario auch, einzelne
Partitionen auf dem SAN ?
Falls ja, sind die direkt verfügbar ?
Was ich getestet hatte, war entweder eine nicht systemrelevante Partition (also reine Datenpartition für eine Anwendung) oder komplett aus dem SAN. Deine Anforderung ist etwas exotisch. (^-^)
Multipath scheidet im Moment wohl eher aus, aus Kostengründen.
Dann würde ich wohl doch zu einem iSCSI-Adapter greifen. Wenn das auch zu teuer wird, sind ein paar lokele Platten mehr wohl doch die einfachere Wahl.
lokale Platten sind nicht mehr möglich, alle Festplattenschächte zu. Ich könnte zwar ein SAS Enclosure von HP kaufen, das kostet aber etwa genau so viel wie ein enclosure, das per iSCSI oder FC angebunden wird. Des weiteren denke ich, das ich bei einer Investition in iSCSI oder FC für die Zukunft besser gerüstet bin (eventl. weiterer Server).
Bernd-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Lentes, Bernd [26.08.2010 14:48]:
Sandy Drobic schrieb:
Wenn du iSCSI vernünftig nutzen willst (nicht nur Testbetrieb), dann brauchst du eine eigenes Netz dafür. Der Overhead ist nicht zu vernachlässigen. Wenn du gute Leistung und geringe Latenzen brauchst (Datenbankbetrieb oder ähnliches), dann nimm besser FC.
Hallo Sandy,
wie gesagt, ich schwanke zwischen iSCSI und FC. iSCSI schien mir billiger. Wie ist das denn bei Partitionen, die auf SAN's liegen, die per FC angebunden sind ? Sind die direkt für Linux verfügbar oder muss da auch noch eine "Netzwerkinitialisierung" o.ä. stattfinden ? Ab wann wären denn diese Partitionen im Bootprozess verfügbar ?
Bernd--
Ich selbst habe aktuell drei (SAP-)Server an FC angebunden. Mit SLES9, nicht gerade aktuell, aber passt vom Alter her zum RAID ;-). Als Karten stecken QLogic 2340 drin, dafür liegen wohl allen aktuellen Distris Treiber bei. Wenn der PCI-Bus nach Karten abgegrast wird, um die entsprechenden Treiber zu laden, werden die PCI-Treiber geladen. Gleich danach tauchen die LUNs als Festplatten auf.
Der Zugriff innerhalb SLES passiert in meinem Fall (2 Karten je Server) über multipath, weil die Reihenfolge des Einbindens unklar ist - also eine Platte, die heute /dev/sdc ist kann nach dem nächsten Boot z. B. /dev/sdf sein. Abhilfe schafft entweder multipath oder - wenn ein LUN nur einmal auftreten kann - mounten per LABEL= in der /etc/fstab (das habe ich gemacht, als ich noch keine doppelte Anbindung via FC-Switch hatte).
LVM setze ich da nicht ein, aber meines Wissens verwendet LVM unique IDs für die Platten (wie multipath auch), und verhindert auf diese Weise schädliche Verwechslungen.
Mit iSCSI habe ich nur einmal schlechte Erfahrungen gemacht, als nämlich eine Netzwerkverbindung zu lange unterbrochen war und das auf dem Volume liegende OCFS2 die Nodes rebootet hat :-(. Aber da war die Ursache OCFS2 (wegen des Netzwerks), nicht iSCSI.
HTH Werner
Werner Flamme schrieb:
Ich selbst habe aktuell drei (SAP-)Server an FC angebunden. Mit SLES9, nicht gerade aktuell, aber passt vom Alter her zum RAID ;-). Als Karten stecken QLogic 2340 drin, dafür liegen wohl allen aktuellen Distris Treiber bei. Wenn der PCI-Bus nach Karten abgegrast wird, um die entsprechenden Treiber zu laden, werden die PCI-Treiber geladen. Gleich danach tauchen die LUNs als Festplatten auf.
Der Zugriff innerhalb SLES passiert in meinem Fall (2 Karten je Server) über multipath, weil die Reihenfolge des Einbindens unklar ist - also eine Platte, die heute /dev/sdc ist kann nach dem nächsten Boot z. B. /dev/sdf sein. Abhilfe schafft entweder multipath oder - wenn ein LUN nur einmal auftreten kann - mounten per LABEL= in der /etc/fstab (das habe ich gemacht, als ich noch keine doppelte Anbindung via FC-Switch hatte).
LVM setze ich da nicht ein, aber meines Wissens verwendet LVM unique IDs für die Platten (wie multipath auch), und verhindert auf diese Weise schädliche Verwechslungen.
Hallo Werner,
Gruß von Helmholtz an Helmholtz :-)
Wenn die LUN's so früh auftauchen, scheint das nach meinem Geschmack zu sein. Mounten per label ? Ist das das hier:
Auszug aus /etc/fstab: /dev/disk/by-id/cciss-3600508b1001032333420202020200003-part2
Bernd-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On Thu, 26 Aug 2010 16:42:40 +0200, "Lentes, Bernd" bernd.lentes@helmholtz-muenchen.de wrote:
Mounten per label ? Ist das das hier:
Auszug aus /etc/fstab: /dev/disk/by-id/cciss-3600508b1001032333420202020200003-part2
Nein, das ist by-id ;) Anstatt /dev/disk... nimm LABEL=label z.B. LABEL=root / ext3 defaults,errors=remount-ro 0 1
Wobei dann natürlich auch ein Label vorhanden sein muss ;)
Lutz Thuns schrieb:
Auszug aus /etc/fstab: /dev/disk/by-id/cciss-3600508b1001032333420202020200003-part2
Nein, das ist by-id ;) Anstatt /dev/disk... nimm LABEL=label z.B. LABEL=root / ext3 defaults,errors=remount-ro 0 1
Wobei dann natürlich auch ein Label vorhanden sein muss ;)
Wo lege ich das label fest ? Ist das das "edit bsd disklabel" in fdisk ?
Oder das, welches z.B. bei mkfs bzw. tune2fs mit "-L volume_label" festgelegt wird ?
Bernd-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Lentes, Bernd [26.08.2010 17:55]:
Lutz Thuns schrieb:
Auszug aus /etc/fstab: /dev/disk/by-id/cciss-3600508b1001032333420202020200003-part2
Nein, das ist by-id ;) Anstatt /dev/disk... nimm LABEL=label z.B. LABEL=root / ext3 defaults,errors=remount-ro 0 1
Wobei dann natürlich auch ein Label vorhanden sein muss ;)
Wo lege ich das label fest ? Ist das das "edit bsd disklabel" in fdisk ?
Oder das, welches z.B. bei mkfs bzw. tune2fs mit "-L volume_label" festgelegt wird ?
Das Letztere auf jeden Fall. Da ich SLES benutze, greife ich zu YaST ;-)
Du kannst "gemischt" mounten, also /dev/sda3 einerseits und LABEL=HUGO andererseits. Ich habe - bei Einsatz von LVM auf meinem Arbeitsplatz - eine Zeile wie
LABEL=srv0 /srv xfs ...
in der /etc/fstab. Bei "mount" sieht man dann
/dev/mapper/Hauptgruppe-srv on /srv type xfs (rw)
Die Labels für die VGs vergebe ich beim Einrichten (klar, oder geht das auch ohne?).
Gruß Werner
Hallo,
Am Don, 26 Aug 2010, Lentes, Bernd schrieb:
Oder das, welches z.B. bei mkfs bzw. tune2fs mit "-L volume_label" festgelegt wird ?
Das. Und /dev/disk/by-label/foo kann man wohl auch verwenden (statt LABEL=foo).
-dnh, /dev/sdaN für /, LABEL für den Rest ;)
David Haller schrieb:
Das. Und /dev/disk/by-label/foo kann man wohl auch verwenden (statt LABEL=foo).
-dnh, /dev/sdaN für /, LABEL für den Rest ;)
Hallo,
noch 'ne prinzipielle Frage: mein lokaler Speicherplatz geht mir ja auf meinen hosts langsam aus. Ich benutze LVM2. Habe ich nun mein SAN, ist meine Idee, dort Partitionen anzulegen, die auf dem host als PV's deklariert und zu bestehenden VG's hinzugefügt werden. Damit würden einige PV's eines VG's auf den lokalen Platten liegen, einige PV's auf dem SAN. Glaubt Ihr, so was klappt ?
Bernd-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Freitag, 27. August 2010 schrieb Lentes, Bernd: (...)
noch 'ne prinzipielle Frage: mein lokaler Speicherplatz geht mir ja auf meinen hosts langsam aus. Ich benutze LVM2. Habe ich nun mein SAN, ist meine Idee, dort Partitionen anzulegen, die auf dem host als PV's deklariert und zu bestehenden VG's hinzugefügt werden. Damit würden einige PV's eines VG's auf den lokalen Platten liegen, einige PV's auf dem SAN. Glaubt Ihr, so was klappt ?
(...)
Klar, dafür ist LVM2 konzipiert. Die Frage ist eher ob Du das wirklich machen willst. Denn die Ausfallwahrscheinlichkeit der VG erhöht sich.
Du hast ja definitive zwei unterschiedliche Geräte. Das sieht etwas anders aus wenn Du in einem SAN immer nur neue PVs z.B. auf einem RAID zur Verfügung stellst.
Bye
Bernd
Hallo Bernd,
Lentes, Bernd schrieb:
noch 'ne prinzipielle Frage: mein lokaler Speicherplatz geht mir ja auf meinen hosts langsam aus. Ich benutze LVM2. Habe ich nun mein SAN, ist meine Idee, dort Partitionen anzulegen, die auf dem host als PV's deklariert und zu bestehenden VG's hinzugefügt werden. Damit würden einige PV's eines VG's auf den lokalen Platten liegen, einige PV's auf dem SAN. Glaubt Ihr, so was klappt ?
Ich würde mal sagen Vorsicht!!!
Dies aus folgendem Grund,
Wenn Du z.B. Dein LVM-Verbund aus mehreren einzelnen Platten besteht dann ist dieses nur so zuverlässig wie alle 3 Platten zusammen. Das bedeutet, das bei 3 einzelnen Platten eine ausfällt, ist (naja, MAthematiker schlagt mich jetzt nicht...), ca. 3x wahrscheinlicher, als bei einer Platte. Wenn Du nun Netzwerkdevices und lokale Devices mischst, dann ist dies meiner Meinung nach für die Integrität der Volumes recht gefährlich. Wenn ein Netzwerkdevice allein ausfällt, dann ist es einfach nicht verfügbar, wenn aber die Misch-Devices ausfallen, ist es meiner Meinung nach sehr wahrscheinlich dass Deine Filesystem futsch ist. Wenn bei LVM nur eine der (beispielsweise) 3 Platten ausfällt und Du hast kein Raid drunter, was der Ausfall der Platte auffängt, dann sind Dein Filesystem und Deine Daten über'n Jordan.
Axel Birndt schrieb:
Lentes, Bernd schrieb:
noch 'ne prinzipielle Frage: mein lokaler Speicherplatz
geht mir ja auf meinen hosts langsam aus. Ich benutze LVM2. Habe ich nun mein SAN, ist meine Idee, dort Partitionen anzulegen, die auf dem host als PV's deklariert und zu bestehenden VG's hinzugefügt werden. Damit würden einige PV's eines VG's auf den lokalen Platten liegen, einige PV's auf dem SAN.
Glaubt Ihr, so was klappt ?
Ich würde mal sagen Vorsicht!!!
Dies aus folgendem Grund,
Wenn Du z.B. Dein LVM-Verbund aus mehreren einzelnen Platten besteht dann ist dieses nur so zuverlässig wie alle 3 Platten zusammen. Das bedeutet, das bei 3 einzelnen Platten eine ausfällt, ist (naja, MAthematiker schlagt mich jetzt nicht...), ca. 3x wahrscheinlicher, als bei einer Platte. Wenn Du nun Netzwerkdevices und lokale Devices mischst, dann ist dies meiner Meinung nach für die Integrität der Volumes recht gefährlich. Wenn ein Netzwerkdevice allein ausfällt, dann ist es einfach nicht verfügbar, wenn aber die Misch-Devices ausfallen, ist es meiner Meinung nach sehr wahrscheinlich dass Deine Filesystem futsch ist. Wenn bei LVM nur eine der (beispielsweise) 3 Platten ausfällt und Du hast kein Raid drunter, was der Ausfall der Platte auffängt, dann sind Dein Filesystem und Deine Daten über'n Jordan.
--
Hallo,
Das ist schon klar. Meine Frage zielte mehr daraufhin, ob so was prinzipiell möglich ist. Wenn einige PV's einer VG auf einem SAN liegen, und andere PV's auf den lokalen Platten, sind ja auch die Zugriffszeiten und Datentransferraten unterschiedlich. Egal ob mein PV lokal oder im SAN liegt, ich werde immer ein RAID 5 drunter haben.
Bernd-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
-
Axel Birndt -
Bernd Nachtigall -
David Haller -
Erik P. Roderwald -
Lentes, Bernd -
Lutz Thuns -
Martin Hofius -
Sandy Drobic -
Werner Flamme