Mit der veröffentlichung der neusten Ubuntu-Version sind noch ein paar GB dazu gekommen:
Das 10GBit-Zeitalter hat begonnen – Teil 3/3
Ich hatte mir für den dritten Teil ja noch vorgenommen, auch meine Windows 10 Installation (bevor es evtl. zu Windows 11 wird) ebenfalls mit 20Gbit-Anbindung zu versorgen.
Die beiden Ports sind als Ethernet-Adapter bereits eingerichtet und von mir entsprechend benannt:
Also kurz bei Microsoft in der Dokumentation (https://docs.microsoft.com/en-us/powershell/module/netlbfo/new-netlbfoteam?view=windowsserver2019-ps) geforscht… und dann doch ziemlich schnell ernüchtert:
Das Internet sagt, dass das Feature bis 1809 in Windows 10 enthalten war und dann von MS entfernt wurde.
Habs natürlich trotzdem schnell ausprobiert… aber natürlich ohne Erfolg:
Man kann wohl die nötigen Funktionen aus den Server-Images extrahieren, aber dafür fehlt mir im Moment die Zeit 😉
Vielleicht später mal: https://codeinsecurity.wordpress.com/2020/05/27/re-enabling-nic-teaming-lbfo-in-windows-10-desktop-skus-even-after-microsoft-removed-it/
Das 10GBit-Zeitalter hat begonnen – Teil 2.1/3
Heute Abend bin ich dann auch mal dazu gekommen, die neuen Netzwerk-Interfaces in mein Checkmk aufzunehmen:
Das 10GBit-Zeitalter hat begonnen – Teil 2/3
Da ich ja zu den eher ungeduldigen Menschen gehöre… kann es nie schnell genug gehen.
Und wenn man schon eine 10Gbit-Netzwerkkarte mit 2 Ports hat, dann sollte man diese auch nutzen!
Los geht es mit der Einrichtung auf VMware-Seite. Wie in Teil 1/3 schon beschrieben, habe ich mir überlegt, dass ich die Link Aggregation auf Switch-Ebene realisieren möchte, damit potentiell mehrere VMs profitieren können.
Schnell geprüft, dass auch beide Links verfügbar sind:
Weiter geht es auf der Linux-Workstation… zunächst muss man für jeden Port / jedes Interface ein Slave-Interface anlegen:
Leider schränkt die Hardware-Ausstattung meines VMware-Systems die Performance etwas ein :/
Das SATA-SSD-Raid 5 liefert round about 550MB/s, die NVME-SSD ist da schon ein wenig schneller…
Der Datastore für diese Disk liegt auf einer NVME-SSD, auch hier sind nicht gerade super Werte zu erzielen.
pv /mnt/nas_nvme/Oracle\ Enterprise\ Linux\ 8.4.iso > test1.iso 9,25GiB 0:00:05 [1,62GiB/s] [================================================================>] 100%
Für mehr Tempo, bleibt mir nur, temporär ein tmpfs einzurichten:
tmpfs /ramfs tmpfs defaults,size=20G,nosuid,noexec 0 0Entsprechend erreicht man so ca. 2,7 GByte / Sekunde:
dneubert@ryzen:/ramfs$ pv /mnt/nas_nvme/Oracle\ Enterprise\ Linux\ 8.4.iso > test1.iso 9,25GiB 0:00:03 [2,69GiB/s] [================================================================>] 100% dneubert@ryzen:/ramfs$ pv /mnt/nas_nvme/Oracle\ Enterprise\ Linux\ 8.4.iso > test1.iso 9,25GiB 0:00:03 [2,71GiB/s] [================================================================>] 100% dneubert@ryzen:/ramfs$ pv /mnt/nas_nvme/Oracle\ Enterprise\ Linux\ 8.4.iso > test1.iso 9,25GiB 0:00:03 [2,75GiB/s] [================================================================>] 100% dneubert@ryzen:/ramfs$ pv /mnt/nas_nvme/Oracle\ Enterprise\ Linux\ 8.4.iso > test1.iso 9,25GiB 0:00:03 [2,68GiB/s] [================================================================>] 100% dneubert@ryzen:/ramfs$ pv /mnt/nas_nvme/Oracle\ Enterprise\ Linux\ 8.4.iso > test1.iso 9,25GiB 0:00:03 [2,69GiB/s] [================================================================>] 100% dneubert@ryzen:/ramfs$
Weiter geht es dann irgendwann mal in Teil 3/3… da werde ich mir dann mal anschauen, ob/wie ich das unter Windows hin bekomme.
Das 10GBit-Zeitalter hat begonnen – Teil 1/3
Nach langem hin und her, Kupfer oder Fiber… ist es endlich soweit: Die Entscheidung für Kupfer ist gefallen. Also schnell mal zwei Netzwerkkarten gekauft:
Ein Blick in den VMware Compatibility Guide bestätigt, dass die gewünschte Karte bzw. deren Chips unterstützt werden.
Ein paar Überlegungen vorab:
- Da ich aktuell noch keinen 10GBit-Switch habe, wird es eine direkte Kupfer-Verbindung zwischen zwei Hosts geben
- Host 1: Meine Linux-Workstation
- Host 2: Mein VMware-Server
- In Teil 1/3 richte ich die 10GBit-Verbindung ein, in Teil 2/3 dann Link-Aggregation
- In Teil 3/3 versuche ich mich dann an Windows 10
Dann legen wir mal los…
Einrichtung und Einbau in meine Linux-Workstation sind denkbar einfach – Karte einbauen, der Broadcom-Chipsatz wird direkt unterstützt:
dneubert@ryzen:~$ lspci |grep Broad 05:00.0 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme II BCM57810 10 Gigabit Ethernet (rev 10) 05:00.1 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme II BCM57810 10 Gigabit Ethernet (rev 10) dneubert@ryzen:~$
dneubert@ryzen:~$ find /sys | grep drivers.*05:00* --color=never /sys/bus/pci/drivers/bnx2x/0000:05:00.1 /sys/bus/pci/drivers/bnx2x/0000:05:00.0 dneubert@ryzen:~$
… also nur schnell die IPv4-Konfiguration erstellen und die MTU auf 9000 setzen – fertig:
root@ryzen:~# ifconfig enp5s0f0
enp5s0f0: flags=4099<UP,BROADCAST,MULTICAST> mtu 9000
inet 10.10.0.3 netmask 255.255.255.0 broadcast 10.10.0.255
ether 00:0e:1e:86:48:e0 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 39 memory 0xe4000000-e47fffff
Damit die Kommunikation mit meinem virtualisierten NAS über die neue Verbindung läuft, hinterlege ich die zukünftige IP des NAS in der /etc/hosts. Das ist aktuell die einfachste Variante. Später lasse ich meiner Workstation diese IP via DHCP mitteilen – dafür wäre aber noch einiges an zusätzlicher Konfiguration erforderlich.
dneubert@ryzen:~$ grep nas /etc/hosts 10.10.0.2 nas dneubert@ryzen:~$
Auf der VMware-Seite ist die Konfiguration ebenfalls denkbar einfach. Die Netzwerkkarte wird erkannt, der Link ist mit 10GBit / Vollduplex aktiv:
Es ist ein neuer vSwitch erforderlich – auch hier eine MTU von 9000 einrichten und das neue Interface als Uplink auswählen:
Um die Anbindung nutzen zu können wird noch eine entsprechende Portgruppe für die VMs angelegt:
Um auf das neue 10GBit-Netz zugreifen zu können, richte ich eine weitere Netzwerkkarte für die VM „nas“ ein. Die sieht im OS dann natürlich unspektakulär aus:
[root@nas ~]# lspci | grep Ether 03:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01) 04:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01) [root@nas ~]#
Auch hier schnell eine entsprechende Konfiguration erstellt…
[root@nas ~]# cat /etc/sysconfig/network-scripts/ifcfg-LAN-10GBit DEVICE=eth1 TYPE=Ethernet BOOTPROTO=static DEFROUTE=no IPV4_FAILURE_FATAL=no IPV6INIT=no NAME=LAN-10GBit ONBOOT=yes MTU=9000 IPADDR=10.10.0.2 PREFIX=24 [root@nas ~]#
… und schon steht die Verbindung:
[root@nas ~]# ifconfig eth1
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000
inet 10.10.0.2 netmask 255.255.255.0 broadcast 10.10.0.255
ether 00:50:56:bc:c4:e0 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 6 bytes 252 (252.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[root@nas ~]#
Pingtest erfolgreich:
dneubert@ryzen:~$ ping nas -s 8972 -M do -c 1 PING nas (10.10.0.2) 8972(9000) bytes of data. 8980 bytes from nas (10.10.0.2): icmp_seq=1 ttl=64 time=0.249 ms --- nas ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.249/0.249/0.249/0.000 ms dneubert@ryzen:~$
Nachdem ich meine NFS-Exports in der /etc/exports um die neue IP-Adresse meiner Linux-Worksation ergänzt habe kann es an den ersten Speed-Test gehen:
dneubert@ryzen:/tmp$ pv /mnt/nas/ISO-Images/Oracle/Oracle\ Enterprise\ Linux\ 8.4.iso > oel_84.iso 9,25GiB 0:00:17 [ 529MiB/s] [================================================================================================================>] 100% dneubert@ryzen:/tmp$
Das sieht doch schon mal recht brauchbar aus – Quelle für die Daten ist hier das SATA-RAID 5.
Mehr Geschwindigkeit bekommen wir dann vielleicht in Teil 2/2 mit Daten von einer der NVME-SSDs 😉
NVIDIA-Grafikkarten unter Linux mit Checkmk überwachen
Das Überwachen von NVIDIA-Grafikkarten unter Linux gelingt mit Checkmk durch einen einfachen Local-Check. Einzig das nvidia-smi-Binary muss vorhanden sein.
Der Check übermittelt die Metriken für Temperatur, Speichernutzung und Stromverbrauch.
#!/bin/bash
# Version 1.0, 2021-07-24, (c) Daniel Neubert, https://neubert.at
TEMP_WARN=50
TEMP_CRIT=60
NVIDIA_SMI=`/usr/bin/which nvidia-smi`
if [ -z "{NVIDIA_SMI}" ] || [ ! -x "${NVIDIA_SMI}" ]; then
exit
fi
trim() {
local s2 s="$*"
until s2="${s#[[:space:]]}"; [ "$s2" = "$s" ]; do s="$s2"; done
until s2="${s%[[:space:]]}"; [ "$s2" = "$s" ]; do s="$s2"; done
echo "$s"
}
for GPU_INDEX in `${NVIDIA_SMI} --query-gpu=index --format=csv,noheader`; do
while IFS="," read -r index gpu_name driver_version temperature_gpu memory_total memory_used utilization_gpu power_draw
do
if (( $(trim $temperature_gpu) >= ${TEMP_CRIT} )); then
SEVERITY=2
elif (( $(trim $temperature_gpu) >= ${TEMP_WARN} )); then
SEVERITY=1
else
SEVERITY=0
fi
echo "${SEVERITY} NVIDIA_GPU_$(trim $index) gpu_temp=$(trim $temperature_gpu);${TEMP_WARN};${TEMP_CRIT}|power_draw=$(trim $power_draw)|gpu_memory=$(trim $memory_used);;0;$(trim $memory_total) $(trim $gpu_name), Version $(trim $driver_version) - Temp GPU $(trim $temperature_gpu)"°C" - $(trim $memory_used)MB/$(trim $memory_total)MB used - Power $(trim $power_draw)W"
done < <( nvidia-smi --query-gpu=index,gpu_name,driver_version,temperature.gpu,memory.total,memory.used,utilization.gpu,power.draw --format=csv,noheader,nounits )
Das Script findet sich auch in meinem Github-Repository für Checkmk: https://github.com/glutorange/checkmk
Projekt NAS-SSD-RAID-Upgrade
So langsam wurde es Zeit, die alten Magnet-Platten aus NAS zu werfen. Einige der verwendeten 2TB-WD-Disks sind Baujahr 2009 und haben entsprechend hohe Laufzeiten hinter sich. Auch wenn das NAS bei mir längst nicht mehr 24/7 läuft, sind da über die ganzen Jahre schon so einige Stunden zusammen gekommen.
Das bisher verwendete RAID 5, bestehend aus 7 x 2 TB Disks wird abgelöst durch ein minimal kleineres RAID 5, bestehend aus 6 x 2 TB SATA-SSDs.
Bei Geizhals hat sich für die von mir gewählte Crucial BX 500 mit 2TB ein Anbieter mit einem Preis von 144€ je Disk (und damit wieder auf dem Nivau der letzten Angebote) gefunden so dass ich hier einfach zugreifen musste:
Damit wird das NAS nebenbei um 7 x 820g, also ca. 5,7kg (!) erleichtert. Die SSDs wiegen jeweils 38g, in Summe also gerade mal etwa 230g.
Um die SSDs im Gehäuse ordentlich befestigen zu können, habe ich den 3D-Drucker bemüht und ein kleines SSD-Case modelliert:
Hier lassen sich bis zu 8 2,5″ SSDs einschieben und dann auf einen 3,5″ Quick-Release-Rahmen setzen so dass im Gehäuse maximale Ordnung herrscht. Da die SSDs nie für längere Zeit beansprucht werden ist die Belüftung/Kühlung sekundär, im Gehäusebereich für die Laufwerke herrscht allgemein ein brauchbarer Luftstrom.
Das Software-RAID 5 mit 6 SSDs:
[root@nas ~]# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Sat Apr 10 15:29:45 2021
Raid Level : raid5
Array Size : 9766912000 (9.10 TiB 10.00 TB)
Used Dev Size : 1953382400 (1862.89 GiB 2000.26 GB)
Raid Devices : 6
Total Devices : 6
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Mon Apr 12 00:38:34 2021
State : clean
Active Devices : 6
Working Devices : 6
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Consistency Policy : bitmap
Name : nas:0 (local to host nas)
UUID : 21422187:a0472572:9362bf60:cd407cf9
Events : 7168
Number Major Minor RaidDevice State
0 8 32 0 active sync /dev/sdc
1 8 80 1 active sync /dev/sdf
2 8 96 2 active sync /dev/sdg
3 8 16 3 active sync /dev/sdb
4 8 48 4 active sync /dev/sdd
6 8 64 5 active sync /dev/sde
[root@nas ~]#
Und sauber im Monitoring:
SysMonTask – Task-Manager für Linux
Es ist mal wieder Zeit für ein neues Linux-Tool: SysMonTask:
Das stark an den Windows-Task-Manager angelehnte Tool bietet auf einen Blick alles, was man braucht und ist damit auch deutlich übersichtlicher als der Standard System Monitor oder auch CLI-Tools wie htop und Konsorten.
Download und Installations-Anleitung gibt es auf der Projektseite bei Github, einen interessanten Artikel dazu bei Its‘ FOSS.
game.neubert.at
Schaut doch mal auf der neuen Status-Seite game.neubert.at vorbei:
Aktuell laufen hier neben dem obilagtorischen Mumble-Server jeweils Server für Valheim und Starbound.
Firmware-Update unter Linux
Auch wenn es schon lange verfügbar ist, habe ich heute zum ersten mal den fwupdmgr unter Linux benutzt um eine Geräte-Firmware zu aktualisieren. Wenn es doch immer so einfach wäre…
dneubert@ryzen:~$ sudo fwupdmgr get-upgrades
• Samsung SSD 970 EVO 1TB has no available firmware updates
• Samsung SSD 970 EVO 1TB has no available firmware updates
X570 AORUS PRO
│
└─Unifying Receiver:
│ Device ID: 5bb8be566f7b007e87240de3ad212f80349dda9c
│ Summary: A miniaturised USB wireless receiver
│ Current version: RQR12.01_B0019
│ Bootloader Version: BOT01.02_B0014
│ Vendor: USB:0x046D
│ Install Duration: 30 seconds
│ GUIDs: 9d131a0c-a606-580f-8eda-80587250b8d6
│ fcf55bf5-767b-51ce-9c17-f6f538c4ee9f ← HIDRAW\VEN_046D&DEV_C52B&REV_00
│ 279ed287-3607-549e-bacc-f873bb9838c4 ← HIDRAW\VEN_046D&DEV_C52B
│ Device Flags: • Updatable
│ • Supported on remote server
│
├─Unifying Receiver (RQR12) Device Update:
│ New version: RQR12.10_B0032
│ Remote ID: lvfs
│ Summary: Firmware for the Logitech Unifying Receiver (RQR12.xx)
│ License: Proprietary
│ Size: 56,8 kB
│ Vendor: Logitech
│ Duration: 30 seconds
│ Flags: is-upgrade
│ Description: This release addresses an encrypted keystroke injection vulnerability sent by pointing devices. The vulnerability is complex to replicate and would require a hacker to be physically close to a target.
│
│ A few of Logitech's devices used to send select buttons in an unencrypted way, and in an effort to protect against this vulnerability, Logitech removed the feature. Affected hardware is:
│
│ • Wireless Mouse M335
│ • Zone Touch Mouse T400
│ • Wireless Mouse M545
│ • Wireless Mouse M560
│ • Touch Mouse M600
│ • Touch Mouse T620
│ • Wireless Rechargeable Touchpad T650
│
│ Although Logitech does not recommend it, these features may be re-activated by keeping/downgrading the receiver to an older firmware.
│
├─Unifying Receiver (RQR12) Device Update:
│ New version: RQR12.08_B0030
│ Remote ID: lvfs
│ Summary: Firmware for the Logitech Unifying Receiver (RQR12.xx)
│ License: Proprietary
│ Size: 72,7 kB
│ Vendor: Logitech
│ Duration: 30 seconds
│ Flags: is-upgrade
│ Description: This release addresses an encrypted keystroke injection issue known as Bastille security issue #13. The vulnerability is complex to replicate and would require a hacker to be physically close to a target.
│
│ A few of Logitech's devices used to send select buttons in an unencrypted way, and in an effort to protect against this vulnerability, Logitech removed the feature. Affected hardware is:
│
│ • Wireless Mouse M335
│ • Zone Touch Mouse T400
│ • Wireless Mouse M545
│ • Wireless Mouse M560
│ • Touch Mouse M600
│ • Touch Mouse T620
│ • Wireless Rechargeable Touchpad T650
│
│ Although Logitech does not recommend it, these features may be re-activated by keeping/downgrading the receiver to an older firmware.
│
└─Unifying Receiver (RQR12) Device Update:
New version: RQR12.07_B0029
Remote ID: lvfs
Summary: Firmware for the Logitech Unifying Receiver (RQR12.xx)
License: Proprietary
Size: 69,6 kB
Vendor: Logitech
Duration: 30 seconds
Flags: is-upgrade
Description: This release addresses an unencrypted keystroke injection issue known as Bastille security issue #11. The vulnerability is complex to replicate and would require a hacker to be physically close to a target.
Hier wird uns verraten, dass es ein Firmware-Update für den Logitech Unifying Receiver gibt, also fix das Update angestoßen:
dneubert@ryzen:~$ sudo fwupdmgr update 5bb8be566f7b007e87240de3ad212f80349dda9c
Unifying Receiver and all connected devices may not be usable while updating. Continue with update? [Y|n]:
Downloading RQR12.10_B0032 for Unifying Receiver...
Fetching firmware https://fwupd.org/downloads/8d83954fcf79453738dbeba9615a095bae9caed9-Logitech-Unifying-RQR12.10_B0032.cab
Downloading… [***************************************] Less than one minute remaining…
Decompressing… [***************************************]
Authenticating… [***************************************]
Updating Unifying Receiver…
Idle… [***************************************]
Updating Unifying Receiver…**************************************]
Writing… [***************************************]
Successfully installed firmware
dneubert@ryzen:~$ Nach knapp 15 Sekunden ist alles erledigt. Während des Updates ist die Maus – wie im Hinweistext beschrieben – nicht nutzbar 😉
Weitere Informationen liefern folgende Links: