Montag, 27. Februar 2012

System Center Virtual Machine Manager 2012/ Citrix XenServer 6.0


In vielen Datacentern werden heutzutagBostone, aus verschiedensten Gründen, Hypervisor von unterschiedlichen Herstellern wie Microsoft, Citrix und VMware eingesetzt. So schön es auch ist, an dieser Stelle flexible zu sein, so ist der Administrative Aufwand micht zu unterschätzen.

Wie häufig habe ich schon fluchende Infrstruktur-Admins erlebt, die das vCenter öffneten und dann festellten, dass die VM auf einem Xen- oder Hyper-V-Server gehostet wird. 

System Center Virtual Machine Manager 2012 zentralisiert die Verwaltung der hetrogenen Hypervisor Landschaft. 

Deshalb möchte ich die Native XenServer Integration in SCVMM 2012 näher beleuchten.


Fabric 

 















XenServer


Die Kommunikation erfolgt zwischen SCVMM und XenServer direkt .
Das XenCenter ist nicht weiter notwendig.


Systemanforderungen pro Server:

- Citrix XenServer 6.0
- XenServer Integration Suite Supplemental Pack

- Es muss ein DHCP-Server im Management XenServer Netz vorhanden sein, um die Anfragen der Transfer-VM entgegenzunehmen. Das hat nichts mit dem SCVMM zu tun, sondern ist eine XenServer Voraussetzung für das Importieren von VMs.

Hinweis: Citrix XenServer 5.6 wird nur in der SCVMM 2012 BETA untersützt. In der RTM lediglich nur XenServer 6.0 (Codename "Boston").

Setup Integration SCVMM Suite Supplemental Pack:

Einfachste, man installiert das SCVMM Supplemental Pack direkt mit dem XenServer Installation. Für vohandene XenServer Installationen gibt es mehrere Möglichkeit:

1. Direktes Downloaden des SCVMM Supplemental Packs mittels CLI
2. Manuelles Downloaden des SCVMM Supplemental Packs und anschließend Mounten und ausführen

    #XenServer CLI
 
# mkdir /tmp/scvmm
# cd /tmp
# wget http://download.citrix.com.edgesuite.net/akdlm/6099/XenServer-6.0.0-integration-suite.iso?__gda__=1320396644_06339d11d5b2b65949177179797d0f26&__dlmgda__=1320482744_80eab9f2a919a8e79371f651aa8cd6db&fileExt=.iso
# mount -o loop /tmp/XenServer-6.0.0-integration-suite.iso /tmp/scvmm 


Anschliessend erfolgt die Installation der erforderlichen Komponenten:

# cd /tmp/scvmm
# cd xs#xenserver-integration-suite
# ./install.sh
# cd ../xs#xenserver-transfer-vm
# ./install.sh
# cd /

Wurde die Installation des Supplemental Packs erfolgreich abgeschlossen, gilt es noch aufzuräumen:

# umount /tmp/scvmm
# rmdir /tmp/scvmm
# rm /tmp/ XenServer-6.0.0-integration-suite.iso

Für GUI Freunde oder CLI Feinde ;-)
1. Manuelles Downloaden des SCVMM Supplemental Packs
2. ISO File extrahieren mit z.B. mit WinRAR
3. Zugriff auf den XenServer mittels WinSCP (http://winscp.net/eng/download.php)
4. Temp-Ordner "scvmm" unter /tmp/<scvmm> erstellen
5. SCVMM Supplemental Pack nach /tmp/<scvmm> kopieren
6. XenServer CLI # cd /tmp/<scvmm>
7. Mit "ls" Inhalt auflisten
8. install.sh starten
9. Nach erfolgreicher SCVMM Supplemental Pack Setup Temp-Ordner löschen
    10. Fertig!



Citrix XenServer Integration in SCVMM "Ausführendes Zugriffskonto"   

     Sofern das SCVMM Supplemental Pack wie oben beschrieben installier wurde, können wir uns dem nächsten Schritt widmen. Für den Zugriff auf den XenServer, muss allerdings noch ein “Run As Account” angelegt werden. Dies kann entweder direkt im jeweiligen Wizard, oder vorgängig angelegt werden: Einstellungen "Workspace" /Sicherheit/ " AUsführende Konten (Run As Account eng.) oder das entsprechende Ribbon.




 Citrix XenServer Integration in SCVMM "Fabric Management"
     Nun binden wir den XenServer in den SCVMM ein.









Warum wird der DNS so überbewertet? :-) 
Damit wir der XenServer auch mit den Host-Namen ansprochen/ auflösen werden kann, wäre ein entsprechender DNS Record empfehlenswert. Dieser muss dann auch Identisch dem Host-Namen des XenServers gleichen. Ansonten gibt ein Zertikatskonflikt und der XenServer lässt sich nicht einbinden.





 
Remote Console
      Nach der Integration lassen sich Host und Virtual Machines bereits managen. Allerdings kann zu diesem Zeitpunkt noch keine Remote Console Verbindung aufgebaut werden. Beim Aufbau der Verbindung wird die Meldung “Connecting to this Xen virtual machine requires an ActiveX control that is not installed. Would you like to install the Xen ActiveX control now?” angezeigt. Wird dies bestätigt, wird das benötigte PlugIn vom XenServer geladen. Dies erfolgt mittels folgender URL: http//xenserver.domain/VNCControl.msi, zum Beispiel http://MyXenServer/VNCControl.msi.
    Wichtig, die URL ist case sensitive und die Namensauflösung muss funktionieren.

Troubleshooting

    Bei Problemen bei der Integration des XenServer sollte zunächst die Namensauflösung kontrolliert werden. Wichtig ist auch, dass das XenServer Zertifikat gültig ist und eingegebenen Computernamen entspricht. Das Zertifikat kann direkt im Wizard mit “View Certificate” aufgerufen werden.

    Bestehen noch immer Probleme kann die Verbindung zwischen VMM Server XenServer Host auch mittels WinRM geprüft werden. Dazu muss einfach in einer Command Prompt folgender Befehl eingegeben werden:

   winrm enum http://schemas.citrix.com/wbem/wscim/1/cim-schema/2/Xen_HostComputerSystem -r:https://MyXenServer:5989 -encoding:utf-8 -a:basic -u:"root" -p:"MyPassword" -skipcacheck -skipcncheck
   
    Bei der Ausgabe sollte darauf geachtet werden, dass das “CN” und “ElementName” Feld übereinstimmen. Genau dieser Wert muss zudem     als  Computer Name bei VMM als Citrix XenServer Hosts angegeben werden.


Download

System Center Virtual Machine Manager 2012 (Release Candidate) kann direkt beim Hersteller heruntergeladen werden.
Nützliche Links:
 

 
 

Samstag, 25. Februar 2012

Exchange Server 2007/2010 Fast Shutdown Script für den DC


-------------------------------</Script Start>-----------------------------


@ECHO OFF
@TITLE Reboot Exchange 2007 on DC script
@COLOR 1F
SETLOCAL

ECHO  ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
ECHO  º                                                                            º
ECHO  º                       Script by Tayfun Tastan                              º
ECHO  º                    Updated on January, 2008                            º
ECHO  º                  *******************************                           º
ECHO  º                                                                            º
ECHO  º      This script will will reboot Exchange Server 2007 when installed      º
ECHO  º                       on a Domain Controller.                              º
ECHO  º                                                                            º
ECHO  º                        All Rights Reserved.                                º
ECHO  º                                                                            º
ECHO  ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
ECHO.

ECHO.
ECHO 1. Shut Down the server (shutdown /s).
ECHO 2. Reboot the server (shutdown /r).
ECHO 3. Abort shutdown (shutdown /a).
ECHO 0. Do nothing.
ECHO.
CHOICE /C 1230

IF ERRORLEVEL 4 GOTO END
IF ERRORLEVEL 3 GOTO ABORT
IF ERRORLEVEL 2 GOTO REBOOT
IF ERRORLEVEL 1 GOTO SHUTDOWN
IF ERRORLEVEL 0 GOTO END
GOTO END

:ABORT
shutdown /a
GOTO END

:REBOOT
SET PARAMETERS=/r /c "Stopper - Rebooting server"
GOTO STOPSERVICES

:SHUTDOWN
SET PARAMETERS=/s /c "Stopper - Shutting down the server"
GOTO STOPSERVICES


:STOPSERVICES
ECHO ON
REM - While we are waiting for the main Exchange services to stop,
REM - Some peripheral services will be closed in the background.

start /min net stop Microsoft.Exchange.Pop3Service /yes
start /min net stop Microsoft.Exchange.Imap4Service /yes

:STOPSERVICES (only for E2K3)
:start /min net stop NntpSvc /yes
:start /min net stop SMTPSVC /yes
:start /min net stop MSExchangeMGMT /yes
:start /min net stop RESvc /yes


REM - Stop Exchange main services before shutdown to avoid timing conflicts.

net stop MSExchangeIS /yes
net stop MSExchangeADTopology /yes


:net stop Microsoft.Exchange.EdgeSyncSvc /yes
:net stop Microsoft.Exchange.AntispamUpdateSvc/yes
:net stop MSExchangeFDS /yes
:net stop Microsoft.Exchange.ServiceHost/yes
:net stop MSExchangeMailSubmission /yes
:net stop MSExchangeMailboxAssistants /yes
:net stop Microsoft.Exchange.Cluster.ReplayService /yes
:net stop Microsoft.Exchange.Search.ExSearch /yes
:net stop Mad /yes
:net stop MSExchangeTransport /yes
:net stop MSExchangeTransportLogSearch /yes
:net stop Microsoft.Exchange.Monitoring /yes



REM - Well, why not stop other services in the background just for fun?
REM - Stopping IISADMIN will stop other dependant services like W3SVC, and HTTPFilter (SSL).
start /min net stop IISADMIN /yes
start /min net stop msftesql-Exchange /yes
start /min net stop Spooler /yes

REM - Now it's time to reboot or shutdown the server.
shutdown %PARAMETERS% /t 10

REM To abort, type:
REM shutdown /a
:END


-------------------------------</Script End>-----------------------------


Natürlich gibt es keine Haftung und auch kein Support für diesen Code - Die Nutzung  ist auf eigene Gefahr!!!

Donnerstag, 23. Februar 2012

Microsoft System Center 2012 Roadshow


Eines der größten Produktlaunches in diesem Jahr Microsoft System Center 2012 steht unmittelbar vor der Tür. 

Wer mich gerne einmal Live erleben möchte, ist an der bundesweiten Microsoft System Center 2012 Roadshow herzlichst eingeladen. In einer Live Demo, werde ich, die neue Produktfamilie System Center 2012 näher beleuchten. 

Freue mich auf Euch!


Microsoft System Center 2012 Roadshow


Dienstag, 13. Dezember 2011

Cross-Site Silent Redirection in Exchange 2010 SP2

Mit dem SP2 für Exchange 2010 wurde das Cross-Site Silent Redirection verbessert. Nunmehr geschieht das Redirection auf das Postfach automatisch und bedarf keinen manuellen klick auf die Redirection URL.


Weitere Informationen:
Exchange Team Blog

Montag, 5. Dezember 2011

Hochverfügbarkeit - TOP 10 Irrtümer

Es gibt leider noch sehr viel Missverständnisse zum Thema Hochverfügbarkeit. Aus diesem Anlass hier die TOP 10 Irrtümer:

 

1. Hochverfügbarkeit ist nicht 99,5 Prozent
7 x 24-Stunden-Dauerbetrieb erlaubt bei einer Verfügbarkeit von 99,5 Prozent eine durchschnittliche Ausfallzeit von über 43 Stunden pro Jahr. Für unternehmenskritische Aufgaben ist dies zu wenig. Hier muss ein Verfügbarkeitsniveau von mindestens 99,99 Prozent – mit einer durchschnittlichen Ausfallzeit von etwa 52 Minuten pro Jahr - erreicht werden.

2. Hochverfügbarkeit ist nicht Disaster Recovery
Disaster Recovery ist Katastrophenschutz für die IT: Unternehmen schützen damit ihre Systeme vor Bränden, Erdbeben, Flugzeugabstürzen oder Anschlägen, beispielsweise indem sie Rechenzentren räumlich getrennt platzieren. Hochverfügbarkeit sorgt dagegen für den Schutz der IT bei Betriebsstörungen; beide Aspekte sind in einem Sicherheitskonzept berücksichtigen.

3. Hochverfügbarkeit ist nicht Stand-By
Bei redundanten Systemen sind durch Umschalten und Übergabe der Prozesse Ausfallzeiten technisch unvermeidlich. Die Konsistenz von Daten und Transaktionen muss daher separat sichergestellt werden. Auch wenn es dafür Softwarelösungen gibt, ist auf diese Weise eine Verfügbarkeit von höchstens 99,5 bis 99,9 Prozent erreichbar, was einer max. ungeplanten Downtime von 8,7 bis 43 Stunden pro Jahr entspricht.
 
4. Hochverfügbarkeit ist nicht RAID
Mit RAID-Systemen werden Datenspeicher vor Ausfällen geschützt. Hochverfügbarkeit sorgt dagegen für einen ausfallsicheren Betrieb der Server. In kritischen Umgebungen muss daher immer beides implementiert sein.

5. Hochverfügbarkeit ist nicht Backup
Backup-Lösungen sichern wichtige Unternehmensdaten vor Verlusten, sind für einen professionellen IT-Betrieb unverzichtbar und müssen für alle, nicht nur für hoch verfügbare Systeme erstellt werden.

6. Hochverfügbarkeit ist nicht USV
Keine USV kann Server-Abstürze verhindern oder abfangen. Für Hochverfügbarkeit ist der Betrieb einer USV daher zwar eine Voraussetzung, aber keineswegs ausreichend.

7. Hochverfügbarkeit ist nicht ein zweites Netzteil
Netzteile sind störungsanfällig, deshalb verbessert ein zweites Netzteil die Verfügbarkeit eines Servers. Doch damit lassen sich nicht andere Hardware-Fehler, etwa in der CPU oder im RAM, abfangen. In fehlertoleranten Servern sind alle wichtigen Komponenten, auch CPU und RAM, doppelt vorhanden. Auf diese Weise lässt sich Hochverfügbarkeit realisieren.  

8. Hochverfügbarkeit ist nicht Virtualisierung
Die Verfügbarkeit wird durch die Virtualisierung von Servern sogar verschlechtert, weil hier ein einziger defekter physischer Server eine ganze virtuelle Server-Gruppe lahm legt. Für jedes System müssen dann mehr oder weniger aufwändige Maßnahmen zur Wiederherstellung des Betriebs vorgenommen werden. Auch wenn diese Maßnahmen mit Software-Unterstützung automatisch ablaufen, so muss dafür stets eine gewisse Zeitspanne einkalkuliert werden. Daher müssen gerade virtuelle Server mit unternehmenskritischen Applikationen auf einer hoch verfügbaren Hardware-Plattform betrieben werden, beispielsweise fehlertoleranten Systemen.

9. Hochverfügbarkeit ist nicht teuer
Natürlich kostet eine IT-Lösung mehr, wenn sie hoch verfügbar ist - schließlich muss Hochverfügbarkeit durch einen zusätzlichen technischen Aufwand hergestellt werden. Diese Kosten müssen jedoch im Verhältnis zum möglicherweise entstehenden Schaden gesehen werden. Eine einzige Stunde Server-Ausfall kann heute mehr kosten als eine komplette Hochverfügbarkeitslösung. Mittlerweile ist Hochverfügbarkeit aber auch für kleinere und mittlere Unternehmen erschwinglich. Fehlertolerante Server kosten unterm Strich sogar weniger als Cluster-Lösungen, weil sie keine zusätzlichen Kosten für Software-Anpassung, zusätzliche Lizenzen oder eine aufwändige Administration verursachen. Lösungen wie Stratus Avance können handelsübliche x86-Server per Software zu einer hoch verfügbaren Plattform verbinden.

10. Hochverfügbarkeit ist nicht Continuous Availability
Für einige Anwendungen ist selbst echte Hochverfügbarkeit nicht mehr ausreichend, beispielsweise in der Kraftwerkssteuerung, für Notfallsysteme in Krankenhäusern oder in der Produktionssteuerung. Hier muss eine Verfügbarkeit von 99,999 oder sogar bis zu 99,9999 Prozent ("Six Nine") erreicht werden, was eine durchschnittliche Ausfallzeit von etwa 5 Minuten beziehungsweise einer halben Minute pro Jahr gewährleistet. Diese Werte sind auch von Cluster-Systemen nicht erreichbar; Anwender kommen hier nicht an fehlertoleranten Systemen vorbei.
Echte Hochverfügbarkeit ist erst ab einem Verfügbarkeitsniveau von mindestens 99,99 Prozent gegeben. Hier beträgt die durchschnittliche Ausfallzeit höchstens 52 Minuten pro Jahr. Fehlertolerante Server, die komplett redundant aufgebaut sind, erreichen auf Basis von Standard-Technologien eine Verfügbarkeit von mehr als 99,999 Prozent. Da sie dem Anwender als "Black-Box" gegenübertreten, lassen sie sich außerdem wesentlich leichter implementieren und administrieren als leistungsmäßig vergleichbare Cluster-Systeme.
"Der Begriff Hochverfügbarkeit wurde in den letzten Jahren aufgeweicht, weil viele Anbieter Hochverfügbarkeit einfach entsprechend der Möglichkeiten ihrer eigenen Systeme definieren", erklärt Timo Brüggemann, Director Business Development EMEA bei Stratus in Eschborn. "Viele Unternehmen glauben daher fälschlicherweise, dass sie hoch verfügbare Server einsetzen, während sie tatsächlich bei Störungen mit nicht unerheblichen Ausfallzeiten rechnen müssen. Im Ernstfall kann sich das als sehr teurer Irrtum erweisen.

Weitere Links:
http://de.wikipedia.org/wiki/Hochverf%C3%BCgbarkeit