das Böse aus dem Erdgeschoss

Die Leiden des kleinen Admins

4a von 11 jenseits von GsdF

morgen ist also „Wartungsfenster“ … die Vorboten stehen mitten im Zimmer und der Stressfaktor geht hoch.

Seit gestern haben wir nun die VMs in den Fingern die RawLUN mappings haben. Daraus ergibt sich eine Erweiterung des normalen Konzeptes:

  • VM Gastsystem stoppen
  • VM im alten VC deregistrieren
  • VM im neuen VC registrieren
  • die rawLUN mapping löschen
  • VM neu konfigurieren (VM Hardwareversion von 3 auf 4, Netzumbau)
  • VM starten
  • VMWare-Tools updaten
  • VM stoppen
  • Migration mit Verschiebung des Plattenplatzes bei nicht laufender VM (vmdk-Dateien also die Systemplatten der VM)
  • Anbinden der rawLUN vom alten Speicher
  • VM starten
  • Downtime 1 normalerweise  30-60 Minuten abhängig von Umgebung und Größe der Systemplatten
  • Anbinden der rawLUN vom neuen Speicher während die VM läuft.
  • Spiegelmöglichkeiten der Gastbetriebssysteme nutzend von alt auf neu die Daten kopieren
  • VM stoppen
  • die rawLUN mapping zum alten Speicher löschen
  • VM starten
  • Downtime 2 normalerweise weniger als 3 Minuten

wie zu erwarten war etwas umständlicher und diese VMs bedurften also etwas mehr Handarbeiten…<to be continued>

Advertisements

Freitag, 17.04.2009 15:33 Posted by | Allgemein | , | Hinterlasse einen Kommentar

3 von 11 storageVMotion

Ein neues Feature in ESX 3.5.4 und dazu gedacht um eine VM im laufenden Betrieb zwischen 2 Plattenspeichern hin und her zu schieben. Für unsere Migration eigentlich genau was wir brauchen.

Der Tag war gesäumt von Vorbereitungen für die erste abendliche Session. Wir arbeiten bei produktiven VMs ohne rawLUN nach einem einfachen Konzept:

  • VM Gastsystem stoppen
  • VM im alten VC deregistrieren
  • VM im neuen VC registrieren
  • VM neu konfigurieren (VM Hardwareversion von 3 auf 4, Netzumbau)
  • VM starten
  • VMWare-Tools updaten
  • VM (WIN) oder Netzwerk (Linux) neustarten
  • (Anm.: downtime normalerweise max. 10-15 Minuten)
  • storageVMotion am Abend bei laufender VM

Aber wir haben eben immer noch nach dem VMware 2.5 Schema jede Platte >50GB als rawLUN angelegt. Außerdem haben wir noch einige andere VM’s die einen Cluster beherbergen, also eine rawLUN als shared Storage benutzen. Diese haben bislang einen zweiten SCSI-Adapter im shared Modus und je eine rawLUN Mapping auf die gleiche Platte/LUN. Dazu mehr später …<to by continued>

Donnerstag, 16.04.2009 20:47 Posted by | Horrorwoche, VM | | Hinterlasse einen Kommentar

2 von 11 oder auf du und du mit dem IPStor CLI

Die Nachfrage nach LUNs des IPStor (SAN Virtualisierer auf RHEL 5.1 Basis) stieg an diesem Tag von 6 (Startposition) auf nunmehr ~70 (Stand alte Umgebung) an.

Die GUI des IPStore ist schön zum spielen und für einen Operator, aber ein wahrer Admin noch dazu in eine Bash, nutzt nur ein CLI. *harharhar*

Wobei ich anmerken muss, dass der CLI des IPStor keine Abfrage nach der VID (also die Zahl mit der der IPStor intern die LUNs zählt, die er anlegt) als einzelnen Subbefehl bereit stellt. Er vergibt diese natürlich beim Anlegen und im Antworttext steht die auch irgendwo, aber später kommt man nicht wirklich einfach an diese ran, benötigt diese allerdings um viele der CLI Aktionen zu machen. Darunter auch die LUN einem Server zuweisen.

Ergebnis war nach mehreren Stunden einige Bashscripte (Anm.: so bald ich die Freigabe habe veröffentliche ich die) zum Löschen, Anlegen, Zuweisen und Wegnehmen von LUNs aus dem IPStor oder respektive dessen Clients.

Was ich sagen muss, so komplex das Thema auch sein mag, ich bin froh dass ich mich durchgesetzt habe und kein DataCore genommen habe. Auf einer RHEL Konsole ist der RHCE eben doch beheimatet. 😀

Großes Lob an die Entwickler der Firma FalconStor, nice work.

Die Kollegen haben während dessen, das VC gepimpt (Zusatztools von VMWare und M$ eingespielt) und die ersten produktiven Systeme migriert. Schon nahm das Unheil seinen Lauf, wir verlohren urplötzlich die Verbindung zu VMs bzw. zu einzelnen ConsoleOS der ESX Server. Schuld waren die 10 GBit NICs onboard (Broadcom 57711E) die mit den angeschlossenen Ciscos(3020) oder mit dem VMWare Treiber nicht arbeiten wollten….<to be continued>

Mittwoch, 15.04.2009 19:58 Posted by | FalconStor IPStor, Horrorwoche, VM | , , | 2 Kommentare

1 von 11

Ja, es war eine lange und harte „Woche“.

Ich konnte zwar twittern, aber zum bloggen blieb leider keine Zeit.

Darum möchte ich so einiges nun noch nach bloggen.

Warum kam es eigentlich dazu, dass ist schlecht zum anonymisieren, aber last es mich so umschreiben: Wir sind zu viert oder besser waren es . Nun hab ich da ja meine Affaire die zwei von uns eigentlich so ziemlich voll auslasten würde. Der Rest vom Team hat uns bislang den Rücken freigehalten in dem sie den täglichen Adminkram erledigt haben. Nun aber hat man beiden einen neuen Job angeboten und wir die sowieso schon zu viel zu tun haben/hatten, arbeiten nun statt 150% nun eher 300%. Ja, wir haben ein wenig Geld mehr, aber im Verhältnis zur dreifachen  Arbeit bei weitem nicht angemessen.

Also nach dem wir nun also um 50% gesund geschrumpft wurden, war es eigentlich genau die richtige Zeit um endlich mal die neue Hardware mit Produktions-VMs zu befüllen. Sprich wir ziehen um, neue Hardware (Blades, VM ESX 3.5.4), eine SAN – Virtualisierung erstmals bei uns im Einsatz und somit auch neu, und um es auch wirklich spannend zu machen, haben wir auch einen neuen Plattenturm.

Jedem Admin dreht sich da der Magen um, so ging es uns auch, einige andere Begebenheiten brachten uns in die Not, dieses Unterfangen nun doch in Angriff zu nehmen.

Als Netz für den Notfall und weitere helfende Hand haben wir uns einen VMWare Profi geholt. (Anm. ohne ihm wäre alles noch so viel schlimmer gekommen)

Am ersten Tag war noch der Frust der Versetzungen und der Ärger mit dem Deployment (Altiris auf W2k3 Basis) im Vordergrund des Geschehens, sowie seitens der SAN Virtuallisierung erste LUNs zu präsentieren. Mehr als den Aufbau des VC-Servers und der ersten Testmigrationen war dann nicht mehr machbar. … <to be continued>

Dienstag, 14.04.2009 19:32 Posted by | Horrorwoche, VM | | Hinterlasse einen Kommentar

0 von 11

Es war das Osterwochenende, ich hatte meinen verlängerten Adminarm (Latop mit UMTS) mit zu hause, wo er die kommenden Tage auch verweilen sollte.

Warum ich mir das Wochenende so frei willig versaut habe, dass ist leicht erzählt:

Ich brauchte am Dienstag 8 ESX Server fertig installiert und betriebsbereit. Da mein Kollege auch nicht zum Deployen kam und die Software auch nicht wirklich einfach zu durchschauen ist, habe ich mich eben geopfert. Ja ein weiters mal und wieder völlig umsonst.

Jedenfalls ein Kickstart file war schnell gefunden aber sehr schwer an unsere Umstände und das Deployment selbst anzupassen. Nach 45 Stunden intensivsten try-and-error hatte ich letztlich doch kein generisches ks.cfg für Alle, sondern für jeden ESX eine individuale Kopie angelegt und 2 Stunden später auch alle ESX betankt und überprüft.

Dabei vielen mir schon erste NICs auf, deren Link down war, bei Blades geht es nicht wirklich, ein Netzwerkkabel zu ziehen. Aber das konnte ich ohne Netzadmin und von zuhause nicht klären.

Naja von Ostern hatte ich also nur den Montag und sonst nix. Ich fuhr also nicht gerade froh über die neue Umgebung am Dienstag noch im Dunkeln gen Büro… <to be continued>

Sonntag, 12.04.2009 19:25 Posted by | Horrorwoche, VM | | Hinterlasse einen Kommentar