[Linux] Abhaengigkeiten von Blockdevices visualisieren

Autor: Raphael Eiselstein <rabe_at_uugrn.org>
Datum: Sun, 1 Dec 2013 03:40:20 +0100
Hallo,

jeder der ein etwas komplexeres Setup hat als ein Rechner mit einer
Festplatte mit ein paar Partitionen kennt vielleicht irgendwann das
Problem, dass die Schichten zwischen realer Storage-Hardware 
(Festplatten, Blockdevices, ...) und Dateisystemen beliebig komplex sein
können.

Gibt es ein Tool, mit dem man den kompletten Abhängigkeitsbaum zwischen
konkreter Hardware und einem Filesystem analysieren und ggf. darstellen
kann?


Beispiel für eine komplexe Struktur die ich meine 
(ASCII-Art, ggf Darstellung auf monospaced font ändern):


Linux-1
 +--SATA-1
 |   +--/dev/sda
 |   |   +--/dev/sda1  -----.
 |   |   `--/dev/sda2  --.  |
 |   |                   |  |
 |   +--/dev/sdb         |  |
 |   |   +--/dev/sdb1  --|--+
 |   |   |               |  |
 |   |   |               | /dev/md0 
 |   |   |               |  `-- /boot [ext2]
 |   |   +--/dev/sdb2  --+
 |   |                   |
 |   |                  /dev/md1 
 |   |                   `--- /dev/dm0 [alias md1_crypt]
 |   |                         `-- lvm2 [pv]
 |   |                              `--/dev/vg01
 |   |                                  +-- lvroot
 |   |                                  |    `-- / [xfs]
 |   |                                  +-- lvswap
 |   |                                  |    `-- [swap]
 |   |                                  +-- lvhome
 |   |                                  |    `-- /home [xfs]
 |   |                                  [... ... ...]
 |   `--/dev/sdc              
 |       +--/dev/sdc1
 |       |   `-- /foo
 |       `--/dev/sdc2
 |           `-- /dev/dm9 [sdc2_crypt]
 |                `-- lvm2 [pv]
 |                     `-- /dev/vg02
 |                          +-- lvbackup
 |                          |    `-- /backup
 |                          `-- lvarchive
 |                               `-- /archive
 +--SATA-2
 |   +--/dev/sdd [GPT]
 |   |   `--/dev/sdd1 
 |   |       `-----------.
 |   |                   |
 |   `--/dev/sde [GPT]   |
 |       `--/dev/sde1    |
 |           `-----------+
 |                       |
 |                      mirror-0 [vdev: mirror sdd1 sde1]
 |                       `-- tank [zpool]
 |                            +-- /tank [zfs, mountpoint]
 |                            +-- tank/foo
 |                            |    `-- /some/where [zfs, mountpoint]
 |                            +-- tank/bar
 |                            |    `-- /tank/bar [zfs, mountpoint]
 |                            +-- tank/baz
 |                            |    `-- /baz [zfs, mountpoint]
 |                            +-- tank/foo [zvol, blockdevice]
 |                            |    `-- /dev/zvol/tank/foo [aka zd0]
 |                            |         `-- /foo [xfs auf /dev/zd0]
 |                            `-- tank/test [zvol, blockdevice]
 |                                 `-- /dev/zvol/tank/test [aka zd16]
 |                                      `-- /test [vfat auf /dev/zd16]
 |                        
 `-- SATA-3
      `--/dev/sdf [GPT]
          `-- /dev/sdf1 
               `-- /dev/drbd0 (primary) <~~~~~~~~ drbd ~~~~~~~~~~> Linux-2 (secondary)
                    `-- /ha [xfs, mountpoint]

* Ja, das ist nicht vollständig konsistent, denn Hardware-zentrisch müsste
es ausgehend vom Mainboard über die PCI-Busse zu den Controllern zu den
Platten hin aufgebaut sein. Dabei müsste die konkrete Hardware und deren
"device-node" aus Sicht vom Betriebssystem getrennt dargetellt werden.

* Es gibt lokale Blockdevices, die ohne (lokalen) physikalischen Storage 
auskommen, etwa RAM-Disks, iSCSI (da ist die Hardware *anderswo*) oder
weitaus komplexere Szenarien, bei denen zB Dateien im Dateisystem auf 
dem lokalen Host als Festplatten innerhalb von VirtualMachines (Xen,
VirtualBox, quemu, ... ) abgebildet werden können.

* Manche Blockdevices sind zwar in Hardware immer Verfügbar aber nur
zeitweise lokal sichtbar, zB auf einem drbd-secondary.

* Bind-Mounts sind beliebt, um einen Teil des Filesystems lokal
anderswohin zu mounten, etwa /ha/www nach /var/www. Ausgehend von
/var/www ist dann /ha/www Provider das wiederum auf drbd aufsetzt,
welches vielleicht noch ein lvm unten drunter hat bevor es ganz unten
auf realer Hardware landet.

* Was sicherlich eine Herausforderung darstellt ist, dass es unter Linux
durchaus üblich und verbreitet ist, bestimmte Devices via Symlinks in
/dev/ als Alias anzulegen und dass die aufeinander aufbauenden Layer
jeweils verschiedene Devices nutzen, zB /dev/sde1:

| /dev/disk/by-path/pci-0000:02:00.0-scsi-3:0:0:0-part1 -> ../../sde1
| /dev/disk/by-id/wwn-0x5***********-part1 -> ../../sde1
| /dev/disk/by-id/scsi-SATA_XXXX_YYYYY###########-part1 -> ../../sde1
| /dev/disk/by-id/ata-XXXXXXX_YYYYYYY_ZZZZZZZZZZZ-part1 -> ../../sde1
| /dev/block/8:65 -> ../sde1
| /dev/sde1

Das kann schon beim manuellen Zusammensuchen der Abhängigkeiten zu
Konfusionen führen, zB wenn ein zpool aus einem mirror aus 2 devices
besteht, die jeweils als /dev/disk/by-id/XYZ-*-part1 verwendet werden,
und man zB beim Ausfall einer Platte nicht mehr auf direktem Weg
nachvollziehen kann, an welchem Controller und Port die konkrete defekte 
Platte denn nun eigentlich hängt (oder vor dem Reset hing).

Schon allein um hier eine *sinnvolle* Dokumentation zu ermöglichen wäre 
ein Visualisierungstool echt nützlich. Sowas muss es doch schon fertig
geben?

Viele Grüße
Raphael

-- 
Raphael Eiselstein <rabe@uugrn.org>               http://rabe.uugrn.org/
xmpp:freibyter@gmx.de  | https://www.xing.com/profile/Raphael_Eiselstein   
PGP (alt):            E7B2 1D66 3AF2 EDC7 9828  6D7A 9CDA 3E7B 10CA 9F2D
PGP (neu):            4E63 5307 6F6A 036D 518D  3C4F 75EE EA14 F625 DB4E
.........|.........|.........|.........|.........|.........|.........|..



-- 
UUGRN e.V. http://www.uugrn.org/
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: https://wiki.uugrn.org/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/

Empfangen am 01.12.2013

Dieses Archiv wurde generiert von hypermail 2.2.0 : 01.12.2013 CET