Archiv der Kategorie: Krankenhaus

ASG Uplinkausgleich & Multipathregeln

Veröffentlicht am von

Damals als ich die Sophos SG430 eingerichtet hatte war eigentlich noch alles gut, bis ich auf die Idee gekommen bin mehrere Internetanschlüsse, damals 10MBit/s SDSL, 2MBIt/s SDSL, 6MBit/s ADSL (Annex B – Business) & 16MBit/s ADSL (Annex J), zu koppeln. Also alles über je eine Schnittstelle zur ASG geführt und die beiden SDSL und die langsame ADSL Leitung per Uplinkausgleich gekoppelt, welches zur Folge hatte, dass sich verschiedene Lastquellen, wie PACS (Radiologiebilderspeicher) und das Laborsystem, auf verschiedene Leitungen verteilt wurde. Jedoch war die Auswahl die von der Firewall getroffen wurde eher zufällig, wodurch die großen PACS Datenmengen (so ca. 18GB) über die 2er SDSL und die Labordaten (ca. 800MB) über die 10er SDSL geschubst wurden. Dieses Verhalten gefiel mir jedoch nicht so recht, weswegen ich zusätzlich zum Uplinkausgleich noch die Multipathregeln aktivierte. Diese ermöglichten mir gewisse Quellen und Dienste an gewisse Ziel-/Leitungsgruppen zu binden, welches auch bei direktem Test auch als funktional herausstellte.  Jedoch zeigte sich am selbigen Abend ein anderes Bild, denn auf einmal ging der PACS Traffic über die 600kbit/s Leitung per ADSL raus, der Labortraffic über die 2er SDSL, der Traffic zum Informationsportal über die andere ADSL (was nicht besonders war, da diese eine dynamische IP hatte und man auf IP Basis freigeschaltet wurde) und der Katzenvideotraffic* wurde über die 10er SDSL rausgeblasen. Als Ursache konnte ich den Uplinkausgleich festmachen, der auf vermutlich Layer 2 angriff und die Multipathregeln die auf Layer 3-7 ihr Unwesen trieben.

Die Lösung die ich ausarbeiten konnte, war durch das deaktivieren des Uplinkausgleich zu erreichen. Damit benötigte ich zwar mehr Multipathregeln, jedoch funktionierten diese dann wie erhofft.

*(bzw. sonstiger „Multimediatraffic“ der „Unterhaltungszwecken“ dient)

Endlich schnelleres Netzwerk 2

Veröffentlicht am von

Nachdem ich mir im Juli 2014 den HP ProCurve 5308xl (siehe hier) geholt hatte, hatte ich bereits gesagt, dass der zu viel Strom benötigt. Demnach habe ich mir im Oktober 2014 den HP ProCurve 1810-24G v2 gegönnt. Von diesem habe ich selbst aktuell einen im Einsatz. Jedoch habe ich von diesem Modell, sowie vom HP ProCurve 1820-24G & HP ProCurve 1920-48G einige an der Arbeit in Umlauf gebracht. Gründe dafür waren hauptsächlich die HP ProCurve 4000M 100 MBit/s krücken.
Die von mir genutzten Features, neben den Switch sein, sind folgende:
– VLAN auf Port Basis
– Trunk/LACP – z.B. für die Anbindung einer NAS
– LWL Ports (jaja, alles Multimode…. Ich weiß)
Das größte Problem, welches ich jedoch mittlerweile mit meinem HP ProCurve 1810-24G v2 habe, ist, dass er nur 24 Ports hat. Daher hat sich dahinter schon wieder so eine TP-Link 5/8 Port Furunkel angesammelt. Wenn ich mit 24 Port auskommen würde, wäre das super, ebenso wie der geringe Stromverbrauch (ca. 18-28 Watt). Von der Performance her gibt es keine Probleme, die bricht auch nicht ein, wenn alle Geräte Daten haben wollen.

Astaro AP 50 GW fail

Veröffentlicht am von

Ich hab da mal wieder ein Problem oder besser „Captain Obvious, why so silent?!?“
Ist das ein Bug, ein Sicherheitsfeatcher oder kann das weg?
So ähnlich hab ich mich beim Konfigurieren von mehereren AP50 gefühlt.
Erst hatte ich sie in einem Versuchsaufbau direkt an die neue ASG SG430 angeschlossen. Dort liefen diese auch Problemlos.

ap50
Doch als ich die Dinger in das aktive Netz gehangen habe, ging nichts mehr. Die APs fanden einfach die ASG nicht. Über fast zwei Wochen habe ich dann ausprobiert woran es liegen könnte, Proxy, DNS, DHCP, VLAN, Switche. Waren es aber alle nicht.

Fehler:
Astaro AP50 wird im Management nicht gefunden.

Lösung:
Astaro zum Standardgateway für die APs machen, sonst finden sie den Server nicht.

Warscheinlich steht das auf Seite 3 im Manuel, aber nobody RTFM anyway. Ich übrigens in dem Fall bis heute auch nicht.

PS: bei mir heißen die Sophos Geräte immernoch Astaro

2×1.1 GHz reichen

Veröffentlicht am von

Es gibt Menschen (ich gehöre auch dazu) die immer wieder ausführen, dass ein Server nie genug Kerne und RAM haben kann. Dann fängt man an Linux VMs (IPFire) zu erstellen und merkt wieviel eigendlich 16GB und 2x 1,1GHz sind.
Hier mal ein Beispiel von der Arbeit, ein MSI 7835-001R Mainboard mit Intel Celeron 847, 16GB RAM, 120GB Intel SSD, 1TB Seagate SHD und das ganze mit drei Intel Netzwerkkarten (2x PCIe | 1x PCI)

1.1GHz-reicht

Monitoring as a Service

Veröffentlicht am von

Es gibt diese Tage, an denen wird es der Serverhardware zu heiß. Vor allem dann, wenn die „eigendlich“ redundante Klimaanlage ausfällt. Ist ja nicht so schlimm, wenn die alte dahinten dauerhaft defekt ist. Jane is klar, Murphys Gesetz nimmt auch garantiert rücksicht deswegen.
Also es es kam wie es kommen musste, die zweite Klimaanlage fiehl auch aus. Ergebniss davon waren 38°C im Serverraum und eine abartige Lautstärke, natürlich Samstag abend. Dabei hat sich dann auch ein HP DL580G5 (2x6x2,4GHz, 96GB) ESXi Server endgültig verabschiedet, einer von zweien. Ausgerechnet auch noch so, dass das HA Setup nicht gegriffen hat. Dadurch hingen einige sehr viele VMs fest.
Im Nachgang wurde dann die Klimaanlage repariert und die andere erneuert.

Aber hätte es auch ohne den Vollständigen Shutdown des Krankenhauses gehen können?
JA, wenn die Temperaturen rechzeitig bemerkt worden wären. (Unter der Vorraussetzung eines Bereitschaftsdienstes)

Also, wie löst man ein Problem wenn man kein Geld zur Verfügung hat?
Eine Idee zur Lösung hab ich dann beim durchsehen der 31c3 bei Frank & Ron gesehen. Eine Webcam im Datacenter für RSA Token. Einfach aber genial.onetimepassword
Also habe ich das mal eben selbst umgesetzt:
Monitoring

Webcam auf einen Schrank um Serverraum, Thermometer davor – fertig. Zudem kann man immer sehen, ob die Klimaanlage noch läuft, wenn nicht wurde sich der Flügel zufahren.
Gratis dazu gibts gleichzeitig noch die Tür, dadurch sehe ich auf den Aufzeichnungen wer sich alles so dadrin rumtreibt. Von wegen Zugangskontrolle und so 😉