Heute wollen wir wie versprochen über die Konfiguration von ECMP (Equal Cost Multipath) mit JunOS berichten. Nach ein paar Worten zu den Grundlagen holen wir uns zur Demonstration zwei bzw. drei vSRX (aka Firefly Perimeter) ins Labor und schauen uns die Praxis und die entsprechende JunOS-Syntax an.
In diesem Artikel möchte ich euch die Einrichtung von NetApp SnapManager Exchange näher bringen. Ebenso wird in diesem Artikel die Integration in NetApp OnCommand erläutert, damit automatisiert über eine Protection Policy nach einem erfolgreichen lokalen Backup automatisiert ein SnapVault auf eine Secondary NetApp getriggert wird. Wer bereits meinen Artikel über die Integration von Microsoft SMSQL in NetApp OnCommand gelesen hat, wird erstaunlich viele Parallelen in der Vorgehensweise finden 😉
Folgende Konfigurationsschritte werden beschrieben:
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.
Seit Anfang des Jahres gibt es nun von Juniper Networks offiziell eine SRX Firewall als virtuelle Maschine unter dem toll klingenden Namen Firefly Perimeter. Diese virtuelle Maschine, welche man per OVA (Open Virtualisation Archive) einfach deployen kann, hat es ziemlich in sich, da man damit sehr flexibel agieren und sehr viel Blech beim Kunden oder auch im Labor einsparen kann.
Viele Kunden installieren in der Praxis für VMware vSphere und Horizon View Umgebungen ihren vCenter zu Beginn mit einer SQL Express Datenbank. Die Installation ist einfach (da inklusive) und die Performance absolut in Ordnung. Offiziell sind mit einer SQL Express Datenbank allerdings nur 5 Hosts und 50 virtuelle Maschinen supportet.
Technisch spricht nichts dagegen, auch mehr Hosts bzw. mehr virtuelle Maschinen auf einer Micrososft SQL Express Instanz laufen zu lassen. Das Problem ist lediglich das Datenbanklimit von 4GB bei einer Microsoft SQL Express 2005 bzw. 10GB bei einer Micrososoft SQL Express 2008 R2 Datenbank. Läuft die Datenbank voll, „steht“ der vCenter bzw. der Service lässt sich nicht mehr starten.
In den folgenden Schritten möchte ich aufzeigen, wie man die vCenter Datenbank „klein“ halten kann bzw. immer wieder bereinigen kann.
Im WAN gibt es oft die Konstellation, dass man mehrere Datenpfade zwischen einzelnen Netzknoten hat, welche primär zur Herstellung von Redundanz gedacht sind. Man ist also oft in der Situation, dass einige Datenpfade nur im Standby sind. Umgesetzt wird dies i.d.R. über ein Routingprotokoll (z.B. OSPF), welches die Datenpfade mit entsprechenden Metriken versieht und immer „den günstigsten“ Pfad in die aktive Routingtabelle (FIB) einträgt. Bei Pfaden welche dieselben Kosten besitzen wird ein beliebiger Pfad ausgewählt und in die FIB eingetragen. Weiterlesen
CrashPlan ist eine leistungsfähige Datensicherungssoftware für Workstations und Notebooks. Das Produkt gibt es in 3 Ausführungen: Home, Business und Enterprise, wobei nur letztere einen eigenen Server mitbringt, den man selbst hosten kann.
Damit ist es für Unternehmen möglich, die Datensicherung auch im eigenen Unternehmen oder einem Anbieter in Deutschland zu hosten, statt alle Firmendaten auf die Server des Anbieters in die U.S.A. auszulagern. Grund genug für uns, sich die Software näher anzusehen. Weiterlesen
So schnell SSDs auch sind – so schnell sind sie auch voll. Oder so ähnlich. So geschehen mit der 300 GB Intel SSD 320 in einem ThinkPad T520. Die SSD durch eine größere austauschen wäre eine Möglichkeit gewesen. Doch wozu haben moderne Laptops eigentlich einen mSATA-Slot? In dem sogar eine Weile schon eine 30 GB mSATA SSD von Intel lief, auf dem das Debian GNU/Linux residierte. Ein Preis-/Leistungsvergleich brachte mich schnell auf eine Crucial m500 mSATA SSD. Vielleicht nicht die schnellste, aber zuverlässig. Und günstig. Warum also nicht gleich 480 GB? Weiterlesen
Hi @all,
nachdem wir 3-4 Wochen bei einem Kunden nach einem Update auf Version ESXi 5.5 Update 1 ein sehr merkwürdiges Verhalten festgestellt haben und seitdem in einer VMware Supportcall-Eskalations-Loop festgesteckt waren, schaffen die Blogger und das Internet seit diesem Wochenende „traurige“ Gewissheit.
Worum geht es? In der Version ESXi 5.5 Update 1 kursiert ein Bug, bei dem völlig „random“ komplette! NFS Datastores disconnecten und VMs „freezen“ bzw. komplett crashen. In den Logs ist lediglich ein APD (All Path Down) zu erkennen und der Datastore disconnected (connected sich nach einer gewissen Zeit allerdings wieder). Nachzulesen ist dies im VMware Knowledgebaseartikel Frequent NFS APDs after upgrading ESXi to 5.5 U1.
Hi @all,
nachdem hoffentlich mittlerweile jeder vom Heartbleed Bug und dessen Auswirkungen gehört hat, möchte ich mit diesem Blogartikel schnell die Links verteilen, die bzgl. der betroffenen VMware Produkte relevant sind.
Allgemein: Über die Website https://filippo.io/Heartbleed/ kann überprüft werden, ob eine entsprechende Zugriffs-Website vom Heartbleed Bug betroffen ist bzw. ob der Bug entsprechend „gefixt“ ist.
Proact Deutschland GmbH
Südwestpark 43
90449 Nürnberg
Mail: info@proact.de
Tel.: 0911 309990