[Linux] Abhaengigkeiten von Blockdevices visualisieren

[Raphael Eiselstein <rabe@xxxxxxxxx>]

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
koennen.

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


Beispiel fuer eine komplexe Struktur die ich meine 
(ASCII-Art, ggf Darstellung auf monospaced font aendern):


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 vollstaendig konsistent, denn Hardware-zentrisch muesste
es ausgehend vom Mainboard ueber die PCI-Busse zu den Controllern zu den
Platten hin aufgebaut sein. Dabei muesste 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 koennen.

* Manche Blockdevices sind zwar in Hardware immer Verfuegbar 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 ueblich 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 Abhaengigkeiten zu
Konfusionen fuehren, 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 haengt (oder vor dem Reset hing).

Schon allein um hier eine *sinnvolle* Dokumentation zu ermoeglichen waere 
ein Visualisierungstool echt nuetzlich. Sowas muss es doch schon fertig
geben?

Viele Gruesse
Raphael

-- 
Raphael Eiselstein <rabe@xxxxxxxxx>               http://rabe.uugrn.org/
xmpp:freibyter@xxxxxx  | 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/