Archiv der Kategorie: Software

IPSec-Throughput: APU1D vs APU2C

Nach dem Upgrade meiner Internetanbindung stach mir als Erstes sofort der eher bescheidene, maximale IPSec-Durchsatz der APU1-Boards ins Auge. Dies war aufgrund der fehlenden AES-Einheit eigentlich auch nicht anders zu erwarten. Um nun diesen Flaschenhals beseitigen zu können, beschloss ich kurzerhand die Anschaffung eines APU2-Boards. Mit einer, gegenüber einem APU1-Board, nun hardwarebeschleunigten AES-Verschlüsselung und erst noch doppelt so vielen (4 Stk.) CPU-Kernen sollte der IPSec-Durchsatz doch deutlich zu steigern sein, oder etwa nicht?

Erste Messungen waren leider ziemlich ernüchternd, der Durchsatz steigerte sich lediglich um ca. 10Mbps. Über die Gründe tappe ich aktuell noch im Dunkeln. Unter Umständen liegt hier aber auch nur ein klassisches Layer-8 Problem vor. Ich bleib jedenfalls am Ball.

APU1D2

  • Betriebssystem: pfSense 2.2.6
  • IPSec: IKEv2, AES256, SHA256
  • Crypto-Support:
(cryptodev) BSD cryptodev engine
 [RSA, DSA, DH]
     [ available ]
(rsax) RSAX engine support
 [RSA]
     [ available ]
(dynamic) Dynamic engine loading support
     [ unavailable ]
  • IPerf-Messungen:
root@STRUBAND-E7450:~# iperf3 -c monitoring -i 1 -R                 
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  42.7 MBytes  35.8 Mbits/sec   51          sender
[  4]   0.00-10.00  sec  42.7 MBytes  35.8 Mbits/sec               receiver

APU2C4

  • Betriebssystem: pfSense 2.2.6
  • IPSec: IKEv2, AES256, SHA256
  • Crypto-Support:
(cryptodev) BSD cryptodev engine
 [RSA, DSA, DH, AES-128-CBC, AES-192-CBC, AES-256-CBC]
     [ available ]
(rsax) RSAX engine support
 [RSA]
     [ available ]
(dynamic) Dynamic engine loading support
     [ unavailable ]

IPerf-Messungen:

root@STRUBAND-E7450:~# iperf3 -c monitoring -i 1 -R              
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  54.2 MBytes  45.4 Mbits/sec   25          sender
[  4]   0.00-10.00  sec  51.3 MBytes  43.0 Mbits/sec               receiver

ESXi 6.0 GPU Passthrough

Angespornt durch diesen Artikel und wie bereits hier angetönt, wollte ich auf meinem neuen Server eine AMD R9 285 Grafikkarte per PCI-Passthrough in eine Workstation VM durchreichen. Anders als im Artikel, sollte bei mir jedoch ESXi 6.0 auf dem neusten Patchlevel 2715440 zum Einsatz kommen. Soweit schien alles klar und ich war auch optimistisch, dass dieses Vorhaben so machbar ist. Wie ihr vielleicht schon anhand der von mir gewählten Zeitform erahnt, klappte es nicht ganz so wie gewünscht, zuerst aber mal der Reihe nach.

Vorbereitungen

Als Erstes sei jedem sicher mal der oben bereits erwähnte Artikel ans Herz gelegt. Zusätzlich waren bei meinem Supermicro Board noch BIOS Einstellungen zu tätigen. Und zwar musste die AMD Grafikkarte priorisiert werden, da sonst das PCI-Passthrough nicht funktionieren wollte. Zudem sei noch der Download einer Windows 10 Insider Preview ISO angeraten.

VM einrichten

Grundsätzlich kann gleich vorgegangen werden wie im Artikel beschrieben:

  • VM erstellen, PCI Geräte noch nicht hinzufügen
  • BIOS der VM auf EFI umstellen
  • VM starten
  • Betriebssystem installieren
  • VMWare-Tools installieren
  • VM herunterfahren
  • PCI-Geräte hinzufügen
  • ESXi-Host neu starten
  • VM starten
  • Grafikkarten Treiber installieren

Der Punkt 5 des Artikels ist bei ESXi 6 nicht mehr vonnöten, ESXi scheint das „PCI hole“ nun selbstständig zu setzen:

2015-06-21T18:54:22.550Z| vmx| I120: Automatically adjusting PCI hole to 1976 MB for passthrough RMRR

Beim Betriebssystem sei auch noch angemerkt, dass es mit meiner HW-Konfiguration leider nur mit Windows 10 klappen wollte.

Hat man die Schritte soweit abgearbeitet, sollte man anschliessend auf dem Bildschirm vom Anmeldebildschirm begrüsst werden:

Der Gerätemanager zeigt, dass alles ordnungsgemäss installiert wurde:

Vom Handling her fühlt sich das System wie eine Baremetal-Installation an. Auch Tests mit diversen Games zeigten keine Performanceprobleme. Das alles klingt jetzt natürlich zu schön um wahr zu sein. So ist es leider auch, denn dieses Setup weist ein paar gravierende Nachteile auf:

  • Der Start funktioniert nur ordnungsgemäss nach einem ESXi-Host Neustart. Das heisst, dass die VM selber nicht heruntergefahren, anschliessend wieder gestartet, oder einfach nur neu gestartet werden kann.
  • Auch funktioniert ein Standbybetrieb oder auch einfach nur ein Bildschirm ausschalten durch Windows nicht.
  • Auch kann man mit dem Monitor nicht zu einer anderen Bildquelle springen und anschliessend wieder zurück.

All diese Punkte ausser einem sauberen ESXi-Neustart führen ins Nirwana und die VM muss anschliessend hart ausgeschaltet werden. Somit ist diese Lösung nicht praxistauglich. Ich werde nun in den nächsten Tagen auf eine Windows 2012 R2 Baremetal-Installation mit Hyper-V Rolle umstellen. Diese Baremetal Windows-Installation wird Desktop-tauglich konfiguriert und mir anschliessend auch als Workstation dienen.

Supermicro Rackserver


Supermicro Rackserver erhielt einen Nachfolger in Form der Supermicro pfSense Appliance


Hardware

  • Supermicro SC505-203B 19″ 1U-Rackgehäuse
  • Supermicro A1SAi-2550F Mainboard inkl. Quad Core Atom C2550
  • Supermicro FAN-0100L4 / MCP-320-81302-0B
  • 8GB ECC-RAM [Kingston KVR16LSE11/4]
  • 2x Supermicro MCP-220-00044-0N HDD-Käfig
  • 128GB SSD Crucial M550 @SATA0 [datastore1]
  • 500GB HDD Seagate ST500LT012 @SATA1 [datastore2]
  • 500GB HDD Seagate ST9500420ASG @SATA2 [RDM-Mapping]
  • 500GB HDD Seagate ST9500423AS @SATA3 [RDM-Mapping]

Betriebssystem Hypervisor

  • pfSense 2.2.4 64-Bit
  • VMWare ESXi 6

VM

  • Ubuntu Server 12.04 LTS
    • Hardware
      • 2 CPU | 4GB RAM | 50GB @datastore1
    • Software
    • Netzwerk
      • 1 NIC @LAN
  • Synology DSM 5.1
    • Hardware
      • 2 CPU | 2GB RAM | 2x500GB HD @RAID1 [RDM@SATA2/3]
    • Software
      • Filestation | Audiostation | Photostation
    • Netzwerk
      • 1 NIC @DMZ

Energiebedarf [Idle]

  • ~20 Watt

Weitere Details / Topologie

Updates

  • 01.08.2015     Umbau in pfSense-Firewall, Einbau 40mm Lüfter

Netzwerk-Monitoring mit Observium

In den letzten Tagen beschäftigte ich mich intensiv mit dem Thema Netzwerk-Monitoring. Dabei nahm ich unzählige Systeme unter die Lupe. Angesprochen haben mich dabei jedoch nur zwei Systeme: PTRG und Observium. Für den professionellen Einsatz würde ich zu PTRG greifen. Für meine privaten Zwecke ist Observium jedoch perfekt geeignet. Voraussetzung sind jedoch SNMP-fähige Geräte, was bei mir mehrheitlich der Fall ist.

Installation

Als Basis für Observium empfiehlt sich ein Ubuntu 12.04 LTS Server. Ist der Ubuntu Server erstmal aufgesetzt, kann man sich gleich an die Installation von Observium machen. Dies gelingt mit dieser Anleitung innert weniger Minuten. Nach der Installation wird man von diesem Startbildschirm begrüsst:

SNMP aktivieren

Damit ein Gerät von Observium überwacht werden kann, gilt es, falls nicht schon aktiv, die SNMP-Funktion zu aktivieren und eine Community zu definieren. Wo diese Einstellungen liegen könnten, seht ihr anhand folgender Screenshots:

SNMP auf einem ESXi aktivieren

Um den SNMP Dienst auf einem ESXi Hypervisor zu aktivieren sind per CLI folgende Befehle einzutippen:

esxcli system snmp set --communities public
esxcli system snmp set --enable true
SNMP auf einem Windows-Server aktiviern

Um SNMP auf einem Windows Server zu aktivieren muss man mittels Server-Manager das Feature „SNMP-Dienst“ installieren und anschliessend den Dienst konfigurieren:

Gerät hinzufügen

Wurde auf allen Geräten SNMP aktiviert, kann man sie nun mittels Hostnamen zu Observium hinzufügen. Nach wenigen Minuten sollten anschliessend die ersten Werte sichtbar sein und das Monitoren kann beginnen. Viel Spass!

Screenshots Observium

Falls die Screenshots nicht reichen: Live-Demo Observium