Obwohl das neue Jahr nur wenige Tage alt ist, hatte es mit Meltdown und Spectre bereits einiges an sicherheitsrelevanten Bugs im Petto.
Auch in Juniper Produkten wurde jetzt eine schwerwiegende Sicherheitslücke entdeckt.
Immerhin ist der Workarround im Gegensatz zu Meltdown und Spectre einfach: Auf den betroffenen Geräten muss das Web-Management deaktiviert werden.
Das knuddelige Observium Maskottchen(tm)
Wer kennt sie nicht, die Qual der Wahl.
Monitoring und Graphing Werkzeuge gibt es zuhauf und jedes hat seine eigenen Vorzüge und Besonderheiten. Man hat meist die Wahl zwischen den „full blown“ Enterprise Tools wie HP OpenView und Solarwinds, den „Schweizer Bastelmessern“ wie Nagios & Friends oder anschaulichen Nischenlösungen wie PRTG. Viele dieser traditionellen Tools haben oftmals die Eigenschaft, dass erhebliche Anpassungen und Konfigurationsarbeiten im Tool von Nöten sind, um die gewünschten Erfolge zu erzielen.
Heute wollen wir euch einen weiteren Kandidaten für die „Qual der Wahl“ vorstellen, der oftmals im „Enterprise Umfeld“ noch nicht weit bekannt ist und gerade bei der Überwachung von großen, heterogenen Netzwerken seine Stärken ausspielen kann: Observium.
Im September 2010 wurde IEEE 802.3az als ein Standard für ein energieffizienteres Ethernet veröffentlicht, welcher von vielen Herstellern, schon vorab als Green Ethernet vermarktet wurde. Ziel sollte sein 50% oder mehr an Energie pro Ethernet Port einzusparen und das unter Berücksichtigung von Abwärtskompatibilität und keinerlei Beeinträchtigungen der Betriebsstablilität.
Die besinnliche Zeit um die Jahreswende und durch aktuelle Wetter und Klimaereignisse in der Realität und Politik gaben den initialen Gedankenanstoß sich mal damit zu beschäftigen ob denn 802.3az das Zeug dazu hat einen kleinen Betrag dazu zu leisten den Energieverbrauch und damit die CO2-Emissionen ein klein wenig zu reduzieren.
Ob und wie viel es bringt erfahrt Ihr in diesem „Aus den teamix Labs“ Blog Artikel.
In der Überschrift steht zwar schon das Ergebnis, aber diesmal wollen wir euch mal einen Blick hinter die Kulissen von teamix gewähren, was so eine profane Überschrift an Arbeit nach sich zieht.
Vorgeschichte: Bei teamix hat es sich zur Trandition entwickelt, dass selbst wenn wir wegen Kindern oder Weihnachts-Anti-IT-Blues nicht mehr so zahlreich auf dem Congress vertreten sind zumindest dafür zu sorgen, dass die Jungs ein halbwegs solides LAN und WAN haben. Darum kümmern wir uns immer rechtzeitig mit den Organisatoren vom CCC darum, dass ausreichende Mengen an Leihequippment von Juniper bereit gestellt werden. Weiterlesen
Hi @all,
heute Nacht ist es soweit: Wir erhalten eine zusätzliche Sekunde bzw. eine sog. Schaltsekunde (= Leap Second). Was heisst das? Die Zeit könnte je nach System/OS/Applikation auf eine Uhrzeit von 23:59:60 UTC (01:59:60 Uhr CEST) springen. Die letzte Schaltsekunde gab es im Jahr 2012.
Das Problem: Gewisse Systeme haben diesen Fall bereits bedacht, andere Systeme nicht. Die Auswirkungen unterscheiden sich je System und reichen von: „nicht betroffen“ über „100% CPU Last“ bis hin zu „Absturz des Systems“.
In diesem Blogartikel findet ihr eine gesammelte Liste mit Links, in der die nicht-betroffenen und betroffenen Systeme aufgelistet sind. Bitte prüft eure kritischen Systeme, ob sie von der „Leap Second“ betroffen sind, verwendet umgehend die angegebenen Workarounds und prüft am Besten heute Nacht nach 00:00:00 Uhr UTC (02:00:00 Uhr CEST) direkt, ob alle Systeme noch sauber laufen. Nicht, dass morgen das „böse Erwachen“ bzw. der „große Knall“ kommt und eure User nicht arbeiten können…
Hier die gesammelte Liste der Fa. teamix GmbH mit den Links bzgl. dem Thema „Leap Second“:
In meiner 3-teiligen Blogserie „Software-defined networking with VMware NSX“ möchte ich euch zeigen, wie man technisch
Zusätzlich zum technischen Deployment dieser Funktionen werde ich die einzelnen Basis“rollen“ und -funktionen der beteiligten NSX-Komponenten in jedem Kapitel beim entsprechenden Schritt erläutern. Wer weiterführende Informationen zu den einzelnen Komponenten und möglichen Konzepten benötigt, wird im VMware® NSX for vSphere (NSX-V) Network Virtualization Design Guide fündig.
Im ersten Teil der „Software-defined networking with VMware NSX“ Blogserie haben wir bereits die NSX Infrastrukturkomponenten implementiert. In diesem Kapitel möchte ich euch näher bringen, wie einfach es ist, ein neues logisches Netzwerk für virtuelle Maschinen zu erstellen, wie man ein hochverfügbares Edge Services Gateway ausrollt und deren NAT-Funktion nutzen kann.
In meiner 3-teiligen Blogserie „Software-defined networking with VMware NSX“ möchte ich euch zeigen, wie man technisch
(Wer noch nie etwas mit Software-defined networking zu tun hatte, findet hier eine Erläuterung, was ein sogenanntes „SDN“ ist.)
Zusätzlich zum technischen Deployment dieser Funktionen werde ich die einzelnen Basis“rollen“ und -funktionen der beteiligten NSX-Komponenten in jedem Kapitel beim entsprechenden Schritt erläutern. Wer weiterführende Informationen zu den einzelnen Komponenten und möglichen Konzepten benötigt, wird im VMware® NSX for vSphere (NSX-V) Network Virtualization Design Guide fündig.
Im 1. Teil der Serie möchte ich euch das Deployment der VMware NSX for vSphere Infrastrukturkomponenten näher bringen:
Auf Grund unterschiedlichster Online-Posts, Blogartikel etc., möchte ich euch mit diesem Blogartikel darüber informieren, wie der Support / Vertrieb von den Cisco Nexus 1000V Switches in Zukunft aussehen wird (Stand: 04.02.2015).
VMware announcte folgendes Statement:
VMware recommends that Nexus 1000V users move to the VMware vSphere® Distributed Switch™ (VDS) as it simplifies operations (e.g., upgrade) and provides advanced monitoring capabilities plus a broader feature set. VMware will also offer migration assistance to make this change. For additional details, please contact your VMware account team or support representative. Customers that use the Nexus 1000V already do so in conjunction with VMware vSphere® Enterprise Plus Edition™ and have the correct licensing in place to make this change.
Juniper stellt mit seiner „Branch SRX“ Serie für den normalen und gehobenen Mittelstand eine sehr flexible und auch preissensitive Plattform für Firewalling, VPN und Routing bereit.
Durch den sogenannten „Chassis Cluster“ besteht die Möglichkeit Hochverfügbarkeit zum administrativen Aufwand eines Einzelsystems zu bekommen, indem man zwei Firewalls zu einer logischen kombiniert.
Soweit die Theorie und auch die Praxis, wenn man sich genau an die entsprechenden KB-Artikel halten kann. Spannend wird es, wenn Anforderungen wie z.B. das Aufteilen des Clusters auf zwei Rechenzentren ins Spiel kommen.
Weiterlesen
Gerade im Bereich Datacenter Switching ist inzwischen allseits bekannt, dass neben den Portgeschwindigkeiten (1,10,40,100 GBit/s) und der Oversubscription-Ratio (Idealerweise keine) auch die Latenz eine essentielle Rolle bei Performancebetrachtungen spielt.
Früher waren niedrige Latenzen bekannterweise ein Monopol für die FibreChannel-Fraktion. Ethernet wurde damals bestenfalls müde belächelt oder als Kinderspielzeug abgetan.
Heute kann jeder „normale“ Datacenter Switch FCoE und hat mit nativem FibreChannel vergleichbare Latenzen. Dabei unterbieten sich die Hersteller in immer wahnwitziger anmutenden Latenzen im Submikrosekundenbereich.
Erstaunlicherweise findet man jedoch fast nie Angaben zu den angewandten Methoden, welche einen nicht unerheblichen Einfluß auf das Ergebnis haben – in Einzelfällen sogar so extrem, dass man bei einem Messverfahren sogar „negative Latenzen“ erhalten kann. Zeitreisen gibt es jedoch leider nur in StarTrek.
Dieser Artikel soll hier etwas Licht ins Dunkel bringen.
Proact Deutschland GmbH
Südwestpark 43
90449 Nürnberg
Mail: info@proact.de
Tel.: 0911 309990