Momentan muss ich für einen Kunden einen ausfallsicheren performanten Micrsoft SQL-Server zusammenstellen, aufbauen und dann auch später administrieren. Alleine die Hardware-Planung hat eine Menge Nerven und Zeit gekostet, so tief wollte ich in die Materie gar nicht einsteigen aber wenn man alles richtig machen will muss man manchmal auch tiefer gehen.

Der Kunde hat momentan zwei alte Windows Server 2003 x86 auf denen Datenbanken laufen, durch das ständige Wachsen ist das bestehende System langsam an seine Grenzen gekommen. Bzgl. Micrsoft SQL-Server gibt es eine Menge “Best-Practice-Witepaper” für sowas, ich haben (unfreiwillig) einige davon gelesen um das Thema besser zu verstehen.
Mit einem Partner von mir wollte ich das zusammen machen dieser schwört auf die SAN’s von NetApp, also dachte ich mir ok probieren wir es bevor wir das Zeug gleich kaufen. NetApp war so net mir eine FAS2020 eine Woche zum testen zu überlassen. Ich habe mit IOMeter (Test’s liefen nur 60 Sekunden mit den selben Einstellungen) die maximale Performance der Geräte gemessen und war über das Ergebniss überrascht, aber seht selbst:

Wie Ihr seht schmeichelt dies der NetApp FAS2020 nicht wirklich! Ich habe auch öfter mit einem NetApp-Techniker telefoniert aber keiner konnte sich erklären warum die Werte so gering waren. Lt. einer Aussage eines Vertrieblers sollte diese 13.000 IOPs schaffen, er wollte mir aber nicht sagen wie diese Werte geschafft worden sind bzw. konnte es nicht.

Kürzlich habe ich mit einem Bekannten gesprochen der setzt nur HP ein und hat mir das ganze mal etwas näher gebracht und vorgerechnet, wenn man davon ausgeht das eine 15k 3,5″ SAS 300GB alleine 200 IOPs schafft und diese mal 12 nimmt kommt man auf eine Wert von 2400 IOPs dann muss man noch etwas vom Raid usw. abziehen dann hast dann den wirklichen Wert. Mehr Platten (Spindeln) mehr Power ganz einfach. Er zeigt mir ein Merkblatt einer HP-SAN die schaffte ca. 19.000 IOPs aber nur mit 96 SAS Platten im Backround!

Diese Werte sind auch ohne Gewähr und ich übernehme dafür keine Garantie. Könnte auch an einer falschen Konfiguration liegen, aber das ist bis jetzt nicht geklärt.

Hier ist auch noch ein Link zu einer VMWare Communitie die sich mit dem Thema auch beschäftigt und jeder seine Ergebnisse postet:
VMware Communitie

Würde mich freuen, wenn ihr euere Werte hiermal postet evtl. vielleicht sogar von eurer FAS 2020.

Also für das ist die FAS2020 von NetApp für mich nicht die richtige SAN um den Kunden und auch mich zufrieden zu stellen.

Ich habe eine virtuelle Maschine die auf einem ESX 3.5 läuft, in dieser virtuellen Maschine läuft ein IIS7 mit Windows Server 2008.
Nachdem ich ein Website mit einem SSL-Zertifikat ausgestattet habe, habe ich den Server neugestartet und dann ging nix mehr!

Die VMWare-Tools liefen nicht mehr und auch etliche Dienste starten nicht mehr und ließen sich auch nicht nachträglich starten. Mehrere Neustarts änderten dies nicht, erst dachte ich es war ein Windows Update das mir den Server zerstörte dem war aber nicht so. Da ich auch dies ausschliessen wollte, erstellte ich eine neue virtuelle Maschine und auch hier nachdem einspielen des SSL-Zertifikats verweigerte dieser seine Arbeit.

Ihr müsst in der Registry folgendes eintragen, neustarten und dann funktioniert der Server wieder:
1. Open Registry Editor
2. Navigate to HKLM\System\CurrentControlSet\Services\HTTP and create the following Multi-string value: DependOnService
3. Double click the new DependOnService value that you created
4. Enter CRYPTSVC in the Value Data field and click OK
5. After you have made this change, you will need to reboot the server.

Quellen:
VMWare-Communtiy
Microsoft

Wie immer auf eigene Gefahr und immer schön Backup machen…

Folgende Fehlermeldung bekomme ich beim hinzufügen eines ESX zu einem HA:

Der HA-Agent hat einen Fehler : cmd addnode failed for primary node: Internal AAM Error – agent could not start.: Unbekannter HA-Fehler Fehler

Die Lösung des Problemes bei mir war:
Die DNS-Einstellungen in dem ESX zu kontrollieren und zu testen und auch den entsprechenden DNS-Server mit Forward-Einträgen und Reverse-Einträgen für die ESX’n zu versehen, diese haben bei mir gefehlt und anscheinend benötigt der vServer eine funktionierende DNS-Umgebung um auf die ESX’n zugreifen zu können.

Nachdem konnte ich den ESX-Server für das HA neukonfigurieren lassen, dadurch startet dann auch der vmware-aam Dienst ohne Probleme.
Zur weiteren Fehlersuche kann ich euch nur raten die Logs am ESX unter /var/log/vmware zu prüfen.

Nach dem updaten des ESX-Servers von VMWare konnte ich keine Verbindung mehr per VI-Client, Web oder Infrastructure herstellen. Nach mehrmaligen Neustart des ESX-Servers und auch nach nochmaligem Updaten des Servers war immer noch keine Besserung in Sicht.
Per SSH konnte ich mich noch verbinden, dann habe ich überprüft welche Dienste am Server laufen und welche nicht, hab die laufenden neugestartet und die die nicht gestartet waren habe ich gestartet.
Nachdem ich den Dienst „saslauthd“ gestartet hatte konnte ich mich per VI-Client verbinden und die virtuellen Maschinen starten.

Befehl dazu:

/etc/init.d/saslauthd start

Der Dienst ist anscheinend für alle Anmeldung zuständig, nachdem start des Dienstes konnte
ich auch wieder auf die SAN über den ESX zugreifen.

Folgendes: Wenn man nen ESX updateded muss man ggf. alle VM herunterfahren und den ESX auch neustarten und dann wieder alle VMs starten.

Ich habe jetzt schon eine Zeit gesucht nach etwas fertigem hab aber nix gefunden, dabei bin ich über folgenden Befehl gestolpert:

vmware-vim-cmd vmsvc/power.shutdown “VMID”

Dieser Befehl fährt eine VM herunter, sofern die VMWare-Tools installiert sind.
Gut weiter, folgender Befehl gibt alle VMs auf den ESX aus mit der entsprechenden VMID:

vmware-vim-cmd vmsvc/getallvms

Leider gibt er hier ziemlich viel aus und da ich nicht so Script bewandert bin um die gesamte Ausgabe zu beschränken lasse ich einfach eine Schleife laufen bei der er alles ausprobiert. Ich bekomme zwar Meldungen zurück das es einige VMs nicht gibt, was klar ist, aber im Grunde tut das Script was es machen soll. Es fährt alle VMs herunter oder auch wieder hoch.

Weiterlesen »

Folgendes Beispiel:

Ihr habt zwei ESX VMWare Server und wollt eine virtuelle Maschine von einem zum Anderen kopieren und Ihr besitzt keinen VMWare Infrastructure. Also Ihr habt alle Dateien der virtuellen Maschine von einem ESX zum Anderen kopiert, aber wie bekommt man jetzt die virtuelle Maschine im VMWare Infrastructure Client angezeigt? Über einen Befehl auf der ESX-Verwaltungskonsole oder direkt am Server z.B. über Putty wenn Ihr einen Windows-Client habt.

Vorgehensweise:

1. Schaltet die virtuelle Maschine aus
2. Kopiert die Daten von einem ESX zum Anderen
   Ich mach das mit dem Befehl “SCP”
3. Führt folgenden Befehl aus
   vmware-cmd -s register /vmfs/volumes/datastore2/Windows_7_Beta/Windows_7_Beta.vmx
   Den Pfad müsst Ihr natürlich an eure Bedürfnisse anpassen
4. Startet den VMWare Infrastructure Client
   nun sollte euere virtuelle Maschine im Client auftauchen

Link zu TecChannel

Ja, dann werde ich demnächst gleich mal meine ESXi-Server einer Updatekur unterziehen. Werde das ganze auch wieder händisch vornehmen, da die ESXi-Server-Landschaft die ich betreue noch übersichtlich ist. Außerdem mag ich es wenn ich etwas selber machen kann ohne Tools zu verwenden!

1. SSH für ESXi-Server freischalten wenn es nicht schon freigeschaltet ist.
   Dafür gibt es im Internet Anleitungen, Google hilft hier weiter.
2. Version herausfinden und Update downloaden
   1. Mit VMWare Infrastructure Client zum ESXi-Server verbinden und Version ablesen
      
   2. Auf die VMWare Patch Seite gehen und das entsprechende Update herunterladen.
      Wenn Ihr nicht sicher seit, könnt ihr auch das erste nehmen das ist immer ein vollständiges Update das alle früheren und aktuellen Updates enthält.
      Achtung: Bei dem Patch steht immer dabei ob ein Reboot oder ähnliches gemacht werden muss wenn dem so ist müsst Ihr beim Updaten aufpassen weil am Schluß der Server den Reboot von alleine macht. Hierbei werden dann auch alle virtuellen Maschinen heruntergefahren außer Ihr habt zwei Server die im Failover laufen!
3. Update per SSH, WinSCP, FTP auf den ESXi-Server laden
4. Zum ESXi-Server verbinden
   1. Entweder von Windows über Putty
   2. Bei Linux einfach über ssh
5. Update entpacken
   Kommt auf die Dateiendung der Datei an welchen Befehl Ihr dafür verwenden müsst.
   Bei .zip einfach unzip versuchen dann wird es in einen Unterordner in dem Ordner wo Ihr euch befindet entpackt
6. In den Ordner wechseln in dem jetzt das Update liegt mit z.B. ” cd ESX350-200810201-UG”
7. Update Befehl eingeben 
   1. Mit automatischen Reboot: # esxupdate update
   2. Ohne automatischen Reboot: # esxupdate update –noreboot
8. Wenn alles ohne Probleme durchgelaufen ist und Ihr euch wieder mit dem VMWare Infrastructure Client verbunden habt sollte bei der Gesamtübersicht die aktuelle Version stehen.

Alles wie immer ohne Übernahme irgendwelcher Haftung für Fehler.