Firefox: Browser Suche für Doofe abschalten

Wie oft hat mich das schon geärgert! Ich gebe in der Adressleiste des Browser einen lokalen Servernamen an und werde statt dessen mit der Google Suchseite verbunden. Google sagt mir dann wo ich günstig NAS Geräte oder HP-Drucker kaufen kann. [Argh!!]

Danke Google, Danke Firefox, Danke IE! – Ich bin nicht doof!

Wenn ich etwas suchen möchte, dann verwende ich die Suchleiste oder gehe direkt zu Google. Aber bitte lasst die Finger von der Address-Bar! Wenn ich mich vertippe ist das alleine mein Problem, also versucht nicht zu erraten was ich vielleicht gemeint haben könnte.

Wie stellt man das ab?

Ich erkläre das hier am Beispiel FireFox (12), da ich diesen in etwa 99,9% aller Situationen verwende. „Firefox: Browser Suche für Doofe abschalten“ weiterlesen

Fujitsu Eternus vCenter Plugin

Der vSphere-Client und vCenter bieten normalerweise nur minimale Informationen zu Datastores. Möchte man Einzelheiten zur angebundenen Storage verwalten, bleibt oft nur die WebGUI. Schön wäre es, wenn man bereits im vSphere Client erweiterte Informationen zur Storage sehen könnte. Fujitsu hat hierfür jetzt ein kostenloses Plugin bereitgestellt.

Unterstützt werden folgende Umgebungen:

Quelle: Fujitsu DE

Setup

Das Download Archiv enthält nur eine Setup Datei. Es empfiehlt sich, die Installation auf vCenter auszuführen, da ein Tomcat Server benötigt wird, welcher auf vCenter normalerweise vorhanden ist.

Zunächst muss auf dem Server eine Umgebungsvariable definiert werden. Systemeigenschaften > Erweitert > Umgebungsvariablen > Systemvariablen > Neu

UnterName wird „CATALINA_HOME“ eingetragen. Der Wert entspricht dem Pfad zum Tomcat Verzeichnis. (Default: C:\Program Files\VMware\Infrastructure\tomcat)

Danach kann das Setup gestartet werden.

  • IP Address:  IP des vCenter Servers
  • User Name: Benutzer mit Berechtigung auf vCenter (z.B. mydomain\Administrator)
  • Password
  • FQDN: vollqualifizierter Name des vCenter Servers (vcenter.mydomain.com)
  • HTTPS Port des Tomcat Servers. Wird automatisch ermittelt oder lässt sich im Tomcat Installationsverzeichnis in der Datei server.xml nachschauen.

Nach dem Setup kann man den vSphere Client starten und unter „Manage Plugins“ den Erfolg überprüfen.

Das Plugin wurde bereits aktiviert.

Selektiert man nun im vSphere-Client einen ESX Knoten so erkennt man rechts ein neues Register „Fujitsu Eternus“.

In diesem Fall handelte es sich um eine DX80 (S1). Obwohl diese offiziell nicht unterstützt wird (nur DX80 S2) funktioniert die Anzeige der LUNs dennoch ausgezeichnet. Lediglich die Registrierung der Storage funktioniert bei dieser Serie nicht.

Im Dialog muß die IP des Storage-Controllers angegeben werden, sowie ein Berechtiger Nutzer (z.B. root) und das Passwort.

vSphere5: Priorisierte I/O Pfade

Im Fall eines Pfadverlustes wählt normalerweise das Path-Selection-Plugin (VMW_PSP_MRU) zufällig einen der verbleibenden Pfade als Alternative. Im VMware vSphere Blog erschien kürzlich ein Artikel, der die Methode der Pfad-Priorisierung unter vSphere5 beschreibt und den VMware KB-Artikel etwas erweitert ausführt. Im Blogartikel wird noch die alte Syntax (4.x) der vSphereCLI verwendet, diese funktioniert nicht mehr bei einem ESXi5.0.0. Aus diesem Grund habe ich unten die aktuelle Syntax angegeben, die auch im KB Artikel genannt wird.

Im Kern geht es darum, daß es drei Kategorien für Pfade gibt:

  • ACTIVE
  • ACTIVE_UO  (active, unoptimized)
  • STANDBY

Die Auswahlreihenfolge ist Active > Active_UO > Standby. Gleichwertige Pfade der selben Kategorie werden weiterhin von VMW_PSP_MRU zufällig ausgewählt. Die Defaulteinstellung der Priorität ist bei allen Pfaden „0“ und unterscheidet sich damit nicht vom Verhalten früherer vSphere Versionen.

Wie setzt man die Priorität?

Mittels vSphereCLI können die Einstellungen ausgelesen und neu gesetzt werden. Eine Konfiguration über die GUI ist derzeit nicht möglich.

Achtung! Keine ESXCLI 4.0 Kommandos an einen ESXi 5.0.0 Server absenden!

Die aktuelle Version gibt es bei VMware.

Im folgenden ist [connection] die Verbindungsdaten zum ESXi Server:

--server myserver.domain.com --user root --password mypassword

<vmhba pathname> könnte z.B. so aussehen: vmhba3:C0:T0:L0

# esxcli [connection] storage nmp psp generic pathconfig get -p <vmhba pathname>
# esxcli [connection] storage nmp psp generic pathconfig set -p <vmhba pathname> -c rank=<rank Number>

Alternativ kann der Pfad auch über die NAA-ID (Network Addressing Authority identifier) bestimmt werden.

# esxcli [connection] storage nmp psp generic deviceconfig get --device=<naa.xxx>

Die so eingestellte Priorität des Pfades bleibt auch nach einem Neustart des Hosts erhalten.

 

 

 

 

vSphere5: Multi NIC vMotion

Betrachtet man vSphere Cluster im produktiven Einsatz, so fällt auf daß immer noch sehr wenige davon mit 10 GB Uplinks ausgestattet sind. Und das meist aus gutem Grund, denn die Hardware ist sehr teuer und auch die Infrastruktur zwischen den ESX-Knoten (Switches, Router, etc.) muß 10 Gbit unterstützen. In der Regel kann man mit mehreren 1Gbit Uplinks sehr gut auskommen und es bedarf schon einiger Mühe einen 1 Gbit NIC zu sättigen. Einzig bei vMotion kann es gelegentlich zu Engpässen kommen, weswegen von mir in der Vergangenheit der Management Traffic vom VM-Network logisch getrennt wurde und die Adapter nur wechselseitig als Standby zur Verfügung standen.

Eine wirklich tolle Eigenschaft von vSphere5 ist mir aber bis vor kurzem entgangen: Multi-NIC vMotion. Hierbei wird der Datenverkehr über mehrere physische NICs geleitet. Es bedarf mindestens zweier NICs mit je einer VM-Kernel Portgruppe und ähnelt dem Verfahren zum Aufbau einer iSCSI-Portgruppe. Nur daß sich hier beide vmk Portgruppen im selben IP Subnetz befinden. Diese Funktion ist nicht nur bei mehreren gleichzeitigen vMotion Transaktionen nützlich, sonder auch schon bei einer einzelnen.

Manuelle Einrichtung

Wir brauchen dazu entweder zwei vSwitches mit je einem vmnic und je einer vmkernel Portgruppe, oder wir verwenden einen vSwitch mit zwei vmnics und zwei Portgruppen. Letztere Variante gefällt mir persönlich besser.

  • Einen vSwitch erstellen und diesem zwei NICs zuordnen (Bsp: vmnic1, vmnic2)
  • zwei vmkernel Portgruppen erstellen (Bsp: vMotion1, vMotion2), mit IP Adressen aus dem gleichen Subnetz.
  • Switch failover-order umgehen.
  • vMotion1 mit vmnic1 (active), vmnic2 (standby)
  • vMotion2 mit vmnic2 (active), vmnic1 (standby)

Achtung Bug!: Derzeit existiert noch ein Problem in vSphere5, wenn zwei Kernelports auf dem selben Virtual Standard Switch vorhanden sind. Das Problem wurde ausführlich im Blogartikel von VMtoday beschrieben und ist ab vSphere5 U1 behoben.

Skriptgesteuerte Einrichtung

Bei mehreren Hosts ist eine Automatisierung wichtig. Die manuelle Einrichtung ist nicht nur mühsam, sondern auch fehleranfällig. Im Diskussionsbereich des Artikels zum Thema Multiple-NIC-vMotion auf Yellow-Bricks werden Skripte in unterschiedlichen Skriptsprachen gelistet. Darunter auch vSphereCLI und PowerCLI.

Links

Frankdenneman.nl: Multi-NIC vMotion support in vSphere5
VMtoday: vSphere 5 Networking Bug #2 Affects Management Network Connectivity
Yellow-Bricks: Multiple-NIC vMotion in vSphere 5
VMware Pubs [PDF]: Networking-Guide