In der Praxis…
…kann der SQL-Server schon bei 3,6Gb Datenbankgröße den Dienst verweigern

In der Theorie…
…sollte die Anwendersoftware vorher eine Warnung ausgeben

In der Praxis…
…liegt der Schwellenwert für die Warnung bei 3,8Gb

In der Theorie…
…sollte die Fehlermeldung lauten: “Die Datenbank ist zu groß”

In der Praxis…
…lautet sie: “Die Datenbank ist defekt, spielen Sie eine Sicherung ein”

In der Theorie…
…Kann man sich an die Hotline wenden und das Problem in 10min beheben

In der Praxis…
…hat es zwei Stunden gedauert

In der Theorie…
…sollte der Einsatz nur 15 Minuten dauern

In der Praxis…
…waren es 3 Stunden

In der Theorie…
…liegen Theorie und Praxis weit auseinander

In der Praxis…
…kann ich das nur bestätigen.

Wucherzins

gesehen auf http://www.wohnlicht.com

Im Auslieferungszustand braucht die App auf einem iPhone 3G je nach Verbindungsgeschwindigkeit bis zu 20 Sekunden zum starten. Jeder Admin sagt: Ist doch akzeptabel für einen online Zugriff, schließlich muss alles erst übertragen werden. Leider sieht das der Benutzer anders: 20 Sekunden sind zu lang um während eines Telefonates “mal eben” einen Termin zu finden. Natürlich kann man darüber streiten, aber ich kann die Beschwerden der Benutzer verstehen. Für “mal eben” 20 Sekunden zu lang.

Mit einigen einfachen Optimierungen lässt sich die Startzeit jedoch verkürzen. Die App braucht umso länger, je mehr Einträge aktualisiert werden müssen. Deswegen sollte man entweder den Ticker oder den Eingang automatisch aktualisieren lassen. Wird beides aktiviert, werden Daten redundant geladen und die App braucht länger. Wen ohnehin nur der Eingang interessiert kann den Ticker abschalten. Zudem empfiehlt es sich die Anzahl der zu aktualisierenden Einträge zu reduzieren. Bei deaktiviertem Ticker und 5 automatisch geladenen Mails verkürzt sich die Startseit auf ca 8 Sekunden. Entfernt man in der Konfiguration noch den zusätzlichen Port 81 kann man weitere 2 Sekunden einsparen.

So sind in meinen Augen 6 Sekunden Startzeit etwas alltagstauglicher als die anfänglichen 20 Sekunden, aber immer noch micht genug Kommentare mit weiteren Tipps sind herzlich willkommen!

[UPDATE1]
Weitere, von dem Problem betroffene Applikationen:

• Microsoft SQL Server
• Symantec pcAnywhere
• Symantec Antivirus
• Adobe Acrobat Reader

Die msvcp71.dll ist auch auf der VMWare Tools CD (Windows.iso, wird gemountet wenn man die Tools installiert) unter folgendem Pfad zu finden:

<cdrom drive>\program files\VMware\VMware Tools\

[/UPDATE1]

[UPDATE2]

Laut http://communities.vmware.com/message/1363520#1363520 gibt es eine Möglichkeit dieses Problem zu umgehen. Ich muss gestehen, diese Möglichkeit ist nicht schön, aber vielleicht nützlich:

chjones behauptet u.a. die msvcp71.dll wurde nicht angefasst wenn man folgendes beachtet:

• die automatische Aktualisierung der Tools aktivieren
• VMs NICHT mit VMotion auf einen vSphere 4 Host migrieren
• VMs herunterfahren und auf einem vSphere 4 Host neu booten

BTW, VMWare hat diesen Bug erkannt. Er soll in vSphere 4 Update 1 behoben werden. U1 erscheint voraussichtlich erst im November 09. Anscheinend sollte man genau wie bei M$ bis zum ersten ServicePack warten

[/UPDATE2]

Das Problem kann behoben werden, indem man die zusätzlichen Festplatten im Diskmanager wieder ‘online’ schaltet und die VM neu startet. Der Bug wurde mir gerade von VMWare bestätigt – es wird an einer Lösung gearbeitet!

Die Ursache ist anscheinend der Austausch des virtuellen Festplattencontrollers. Windows sieht diese Festplatten als “neu” an und bindet sie nicht automatisch wieder ins System ein.

Um USB-Geräte in VM’s zu nutzen, die auf einem ESX oder ESXi laufen, muss man ein wenig in die Trickkiste greifen und diese über das Netzwerk freigeben. Dazu kann man entweder recht teure Hardware (AnywhereUSB) oder recht günstige Stoftware (KernelPro USB-Over-Ethernet) nutzen. Beides ist getestet und läuft erstaunlich stabil und robust, nur diesmal nicht.

Und zwar kommen USBoE und das Yosemite Backup, das Dell als OEM liefert nicht miteinander klar. Sobald der Yosemite-Backup Agent auf dem besagten Rechner läuft, kann USBoE nicht mehr auf den USB-Bus zugreifen und die freigegebenen USB-Geräte sind in den VM’s nicht mehr ansprechbar. Beide Programme nutzen unterschiedliche Netzwerkports und haben eigentlich nichts miteinander zu tun. Wie kann das sein?!

Der Hintergrund alle Systeme zuerst in virtuellen Maschinen abzubilden ist hauptsächlich die Möglichkeit, in wenigen Sekunden Snapshots anzufertigen und bei Bedarf wiederherzustellen. Man friert sozusagen das Komplettsystem – alte Server und neue Server – vor jeder Daten- und Programmmigration ein und kann, falls etwas schief geht, einen konsistenten Zustand wiederherstellen.

Ein Hot-Convert mit dem VMWare Converter eines Windows 2000 Domain Controllers birgt jedoch laut VMWare einige Risiken, wie zum Beispiel diese hier. Obwohl es in den meißten Fällen gut geht, haben wir uns für die Cold-Convert Boot CD entschieden. Diese Boot-CD ist Teil des VMware vCenter Converter Enterprise, der im vCenter Server integriert ist und leider nicht kostenlos zum Download verfügbar ist. Die Boot-CD startet eine Windows PE Umgebung in welcehr der normale P2V-Converter, alle im Rechner verfügbaren Festplatten konviertiert.

Die Migration selber dauerte ca. 80 Minuten für 90GB an Daten. Dank aller Vorsichtsmaßnahmen (Cold Convert usw.) startete der alte Server in der VM tadellos. Alle Programme und Datenbanken funktionierten… bis wir einen Client-PC eingeschaltet haben.

Sie konnten nicht angemeldet werden.
Überprüfen Sie Benutzernamen und Domain und geben Sie das Kennwort ein….

Kein einziger Client-PC konnte sich an der Domäne anmelden – das Eventlog am Server meldete das Computerkonto HOSTNAME$ versuche sich mit einem abgelaufenen Computerkennwort anzumelden. WTF?! Um mittlerweile 21Uhr haben wir den Entschluss gefasst, das trotz diverser Rettungsmaßnahmen die VM unbrauchbar war und wir die alte, physikalische Kiste wieder angeschmissen haben.

Es drängte sich die Frage auf, was schief gegangen ist. Nach näherer Analyse des Servers, musste ich feststellen, dass im Server zwei RAID1 – Laufwerke vorhanden waren. BEIDE Laufwerke hatten jeweils eine aktive Partition mit einem Windows Ordner… Warum?

Es stellte sich heraus, dass die Festplattenkapazität in dem Server vor einigen Jahren zur Neige ging und größere Platten eingebaut wurden. Alle Partitionen wurden dem alten, kleinen RAID1 auf ein neues, größeres RAID1 geklont und das neue RAID1 wurde im BIOS als erstes Boot-Device eingetragen. Das alte RAID wurde jedoch nie aufgelößt und dümpelte in dem Server vor sich hin. Und genau das wurde uns bei der P2V-Migration zum Verhängnis. Da keiner daran gedacht hatte, dass mehrere bootbare Partitionen vorliegen, habe ich bei der P2V-Migration den Punkt “Alle Festplatten konvertieren und Größen beibehalten” gewählt. Gesagt, getan. Der Converter fand zwei aktive Partitionen vor und stand wahrscheinlich vor der Entscheidung welche er als Systempartition bevorzugt. Er bediente sich der erst-besten: Das alte, kleine RAID hatte die LUN0:0 und das neue, Produktivsystem die LUN0:1. Fälschlicher Weise wurde nun ide LUN0:0 als Systempartition erkannt, für die VM mit Treibern vorbereitet und gestartet.

Plötzlich wurde uns klar, das wir nach der ersten Konvertierung mehrere Stunden an einem ca. 2 Jahre alten System herumgedoktort haben und uns wunderten warum die Clients sich nicht anmelden. Keinem war aufgefallen, dass es garnicht das aktuelle System war. *FAILED* Das Resultat waren über fünf Stunden verlorene Arbeit, eine steile Lernkurve und am nächsten Tag eine erneute Spätschicht

Also vorsicht bei der der P2V-Migration von Multi-Boot-Systemen, deren Boot-Reihenfolge im BIOS eingestellt wird. Die Cold-Convert CD bereitet lediglich die niedrigste LUN mit einem Systemverzeichnis für die virtuelle Maschine vor. Die Bootreihenfolge lässt sich, analog zum echten BIOS, auch im virtuellen BIOS einstellen, jedoch fehlen in den anderen Partitionen die notwendigen Treiber für die VM (zumindest bei Win2k).

Geplant war ‘mal eben’ nach allgemeinem Feierabend das Update einzuspielen. Die Hoffnung auf einen frühen eigenen Feierabend habe ich jedoch schnell verworfen, denn die Readme’s zu diesem Update versprachen nichts gutes:

[...] the upgrade is one way only; it is not possible to return to prior
generation after starting this upgrade procedure.

[...] recommended to perform firmware
download as an off-line maintenance event.

Um genau zu sein, ist dieses Cross-Generation-Update (Version 6.xx.xx.x auf 7.xx.xx.x) eine 30Minuten lange Prozedur ohne Rückkehr. – Ja 30 Minuten, so lange dauert das Update, wenn es denn klappt. Für so eine Mammut-Aufgabe gibt es von Dell ein spezielles Cross-Generation-Update-Utility, welches ausschließlich für diese eine Aufgabe konzipiert wurde. Eigentlich sollten es vier simple Schritte sein, die zum Erfolg führen:

1. Alle I/O’s beenden (oder auch shutdown * now )
2. Firmware mittels speziellem Spezialtool updaten
3. Alles wieder hochfahren
4. Feierabend

Klingt ja nicht dramatisch, wäre nicht um ca. 23:30Uhr das Cross-Generation-Update-Utility bei ca. 95% Fortschritt mit der Meldung “Fehler” abgebrochen. Nun kann man sich das so vorstellen, alsob man in einer Einbahnstraße ohne Wendemöglichkeit und kaputtem Rückwärtsgang feststeckt. Versuche, das Update erneut anzustoßen scheiterten sofort und die iSCSI-Targets der MD3000i waren offline. Da alle I/O’s gestoppt werden mussten, waren auch alle DNS-Server und Router offline – somit KEIN INTERNET, keine Möglichkeit nach Lösungen zu Suchen, Handbücher einzusehen oder Google zu befragen. Die einzige mögliche Rettung war die Dell Hotline, die um diese Uhrzeit in den USA endete.

Promt hatte ich einen Support Techniker – nennen wir ihn Mr. D – an der Leitung, der über die Situation doch leicht verwundert schien. Mr. D ging erstmal davon aus, dass ich etwas falsch gemacht hatte. Ich hatte nicht das spezielle Spezieltool benutzt, die I/O’s nicht gestoppt oder ähnliches. Nach ca 30 Minuten Troubleshooting gingen ihm und mir dann doch die Ideen aus, was zur Folge hatte, dass meine leichte Nervosität sich in ein ausgeprägtes Unwohlsein steigerte.

Auf der Dell Website fand Mr. D. jedoch folgenden, gloreichen Hinweis (leider in keiner Readme zu finden):

NOTICE: In non-English versions of the MD Firmware Cross Generation Upgrade Utility, it has been observed that the firmware may fail to activate after the download. While pending activation, the RAID Controller Modules will continue to operate at the previous firmware version. To activate the firmware, the following smCLI command must be used: SMcli [IP of Controller A] [IP of Controller B] -c “activate storageArray firmware;” where [IP of Controller A] and [IP of Controller B] are replaced with the actual IP addresses of the RAID Controller Modules.

Nun musste Mr. D nur noch herausfinden was SMcli ist und wie man es einsetzt. Das Storage Manager Command-Line-Interface ist eine Executable, die im “client”-Unterordner des Modular Disk Storage Managers (MDSM) versteckt ist. Über diese Executable kann man in der Eingabeaufforderung Befehle direkt an das Storage-Array schicken und unter anderem auch erweiterte Konfigurationen durchführen.

Nun ist der Befehl SMcli [IP of Controller A] [IP of Controller B] -c “activate storageArray firmware;” purer Nervenkitzel. Noch mal zu Erinnerung: Alles ist offline, man kommt nicht mehr an die Daten des Unternehmens und man hat kein Internet zur Verfügung. Ich starte voller Hoffnung und Erwartung den SMcli Befehl und bekomme die Ausgabe: Executing Script

Nicht mehr und nicht weniger. Nur Executing Skript. Kein Status. Keine Sanduhr. Nichts. Diese Ungewissheit, was gerade passiert oder ob überhaupt etwas passiert ist nervenzerreisend. Dazu kommt noch die enorme Festplattenaktivität auf der MD3000i während diesen Vorgangs (Remember: Firmware Update!!!). Die ersten fünft Minuten waren noch Okay, aber danach stieg mein Puls proportional zu den vergangenen Minuten. Auch Mr. D konnte keine Auskunft geben, wie lange dieser Vorgang dauert oder ob er abgestürtz ist. Trotzdem hat mir dringend davon abgeraten auch nur auf die Idee zu kommen diesen Vorgang abzubrechen.

Gefühlte drei Stunden (ca. 20 Minuten in Echtzeit ) später, nachdem ich mich geistlich schon von dem Storage verabschiedet und die Bandsicherung schon aus dem Tresor geholt hatte geschah das Unmögliche: Es erschein das Wort “Success” in der Eingabeaufforderung und teilte mir mit, dass alles wieder in Ordnung war. Btw: Mr D., thanks for your help

Nun frage ich mich, liebes Dell-Team, warum kann man in so einem spieziellen Spiezial Cross-Firmware-Update-Tool, das nur für diese eine und einzige Aufgabe geschaffen wurde, nicht auch noch diesen SMcli-Befehl integrieren? Okay, ich weiß, das ist zu viel verlangt, aber dann lasst diesen Befehl in einer Meldung aufpoppen oder schreibt ihn doch einfach in die Readme!!! Das hätte mir echt einiges an Nerven erspart. In diesem Sinne

Never change a running System