Einführung

Dass Backups (vor allem im geschäftlichen Umfeld) elementar wichtig sind, ist sicherlich unumstritten. Wer ESX Server in sein Unternehmen einführt, sollte seine bisherige Backupstrategie jedoch neu überdenken. Für den ESX Server von VMware existieren derzeit drei Backupvarianten, die in den folgenden Abschnitten beleuchtet werden und ihre eigenen Vor- und Nachteile mit sich bringen.

Klassisches Backup

Vor allem viele kleinere Unternehmen setzen bei der Sicherung ihrer virtuellen Maschinen noch auf die Backupstrategie, die bei klassischen (physikalischen) Servern zum Einsatz kommt.

So wird auf jeder virtuellen Maschine ein Agent installiert, über den ein zentraler Backupserver Zugriff auf die Maschine bekommt und Daten sichern kann. Der Vorteil besteht darin, dass diese Methode ausgereift ist und sich Administratoren mit dieser Technik auskennen. Zudem können einzelne Dateien oder auch nur Bestandteile einer Datei (z.B. eine einzelne E-Mail oder ein einzelner Datensatz aus einer Datenbank) problemlos wiederhergestellt werden.

Der Nachteil dieser Variante besteht jedoch darin, dass die virtuellen Maschinen selbst nicht gesichert werden können. So ist im Fall einer fehlerhaften virtuellen Maschine der entsprechende Server neu aufzusetzen und einzurichten. Erst dann können die gesicherten Daten wieder zurückgespielt werden – ein zeitaufwändiges Verfahren. Hinzu kommt, dass die Last auf dem ESX Server bei mehreren gleichzeitigen Backups drastisch ansteigen und somit die Leistungsfähigkeit aller Systeme auf dem jeweiligen ESX Server beeinträchtigen kann.

VMware Consolidated Backup

Einen Schritt weiter geht das VMware Consolidated Backup. Es handelt sich dabei nicht um eine eigenständige Backuplösung, sondern um eine Sammlung aus Kommandozeilentools. VMware Consolidated Backup kann dabei wahlweise auf einem physikalischen Server oder als virtuelle Maschine genutzt werden. Die Sicherung erfolgt in den folgenden Schritten:

• VMware Consolidated Backup erstellt einen Snapshot der virtuellen Maschine.
• Dieser Snapshot wird eingebunden und für die eigentliche Sicherungssoftware bereitgestellt.
• Die Sicherungssoftware kann nun den Snapshot der virtuellen Maschine und/oder einzelne Daten der virtuellen Maschine sichern.
• VMware Consolidated Backup hängt den Snapshot aus und löscht ihn.

Damit VMware Consolidated Backup konsistente Snapshots erstellen kann, wird die jeweilige virtuelle Maschine entweder kurz angehalten oder es wird der Volume Shadow Copy Service bei Windows Servern genutzt.

Der Einsatz des VMware Consolidated Backup hat folgende Vorteile:

• es muss nur ein Backupagent installiert werden,
• es können komplette virtuelle Maschinen und/oder nur einzelne Daten gesichert werden und
• virtuelle Maschinen können im Notfall komplett wiederhergestellt werden.

Das Verfahren hat jedoch auch ein paar Nachteile:

• Die Wiederherstellung ist umständlich, da man sich manuell um das Einspielen der virtuellen Maschinen oder Dateien kümmern muss.
• Es ist ein Zugriff auf die ESX Service-Konsole erforderlich.
• Es wird ein hohe Daten- und eventuell auch Netzwerklast erzeugt (unperformant).

Derzeit ist VMware Consolidated Backup noch Teil von vSphere. In der kommenden Version soll das Produkt jedoch aufgegeben werden, da inzwischen weitaus bessere Lösungen für die Sicherung der virtuellen Maschinen existieren. Diese Lösungen greifen auf das vStorage API zurück und erhalten neben Zugriff auf die virtuellen Maschinen auch zahlreiche Informationen über die virtuellen Maschinen selbst.

Backup über das vStorage API

Neben den beiden bereits vorgestellten Sicherungsvarianten existieren noch Backuplösungen, die auf das bereits angesprochene vStorage API zugreifen. Die einfachste Variante hierbei ist, den ESX Server zunächst einen Snapshot der virtuellen Maschinen erstellen zu lassen und diesen Snapshot danach zu sichern (Vollbackup). Allerdings hat diese Variante gegenüber der Sicherung über das VMware Consolidated Backup nur den Vorteil, dass fehlerhafte Server einfach zurückgespielt werden können.

Lohnenswert wird die Verwendung der vStorage API erst dann, wenn die Backuplösung das so genannte Change Block Tracking verwendet. Hierbei werden nur Datenblöcke gesichert, die sich seit einem bestimmten Zeitpunkt verändert haben.
Dadurch können inkrementelle und differentielle Datensicherungen realisiert, der Datenverkehr verringert und die Performance erhöht werden.

Das Change Block Tracking ist zudem Grundlage für Backuplösungen, die Near Continous Data Protection umsetzen. Hierbei werden veränderte Daten in kurzen Abständen gesichert. Im Vergleich zu Echtzeit-Backuplösungen hat diese Technik eine höhere Performance. Im schlimmsten Fall hat man jedoch auch eine etwas niedrigere Aktualität der Daten.

Die Vorteile der auf Change Block Tracking basierenden Sicherungen sind folgende:

• Die Sicherung ist effizient.
• Es wird nur ein geringerer Datenverkehr erzeugt.
• Komplette virtuelle Maschinen werden gesichert.
• Die Wiederherstellung kompletter Maschinen ist einfach.

Allerdings ergibt sich bei dieser Backupvariante folgendes Problem: häufig müssen nur einzelne Dateien wiederhergestellt werden. Die Backuplösung muss also auf die Dateien in der Sicherung zugreifen und diese in das jeweilige Zielsystem übertragen können. Hierzu wird die entsprechende virtuelle Maschine meist in einem isolierten Netzwerksegment gestartet und die Daten werden dann von der Backuplösung auf das Zielsystem übertragen. Diese Vorgehensweise beherrschen jedoch alle gängigen Backuplösungen.

Schwieriger gestaltet es sich, wenn nur einzelne Bestandteile einer Datei (wie z.B. eine einzelne E-Mail oder ein Datensatz einer Datenbank) wiederhergestellt werden müssen. Hier ist es noch erforderlich, die entsprechende Sicherung manuell
einzubinden, die Daten selber ausfindig zu machen und auf das Zielsystem zu übertragen.

Für bestimmte Systeme könnte also durchaus der kombinierte Einsatz einer klassischen Backuplösung (die entsprechende Möglichkeiten für z.B. den E-Mail- oder Datenbank-Server bereitstellt) mit einer auf der vStorage API basierenden Backuplösung sinnvoll sein (sofern letztere nicht das angesprochene Problem löst).

Backup Lösungen

Für klassische Backups existieren verschiedenste Backup-Lösungen. Bekannt sind hier zum Beispiel CA ARCserve Backup, Symantec Backup Exec oder Acronis ABR. Zudem gibt es viele kostenlose Tools, wie z.B. Microsofts Robocopy für Windows oder rsnapshot für Linux. Im Windows-Bereich werden diese kostenlosen Tools allerdings selten eingesetzt, während z.B. rsnapshot in Linux-Umgebungen recht häufig zum Einsatz kommt.

Beim Einsatz des VMware Consolidated Backup können die meisten dieser klassischen Backup-Lösungen weiterhin eingesetzt werden.

Sobald es an die Sicherung der virtuellen Maschinen über das vStorage API geht, setzen Unternehmen bevorzugt auf eine der von VMware unterstützte Backuplösungen.

Quellen

• VMware – VMware vStorage-APIs: Zentrale Backups virtueller Maschinen
• VMware – VMware: Automatisierung von Daten-Backup und -Recovery für Hochverfügbarkeit
• WindowsPro – Vergleich: Backup-Strategien für VMware ESX

Bei der Anwendung kann zwischen drei Modi gewählt werden:

• Automatische Deaktivierung des zweiten Prozessorkerns, wenn die Leistung nicht benötigt wird
• Dauerhaft nur einen Prozessorkern nutzen
• Dauerhaft beide Prozessorkerne nutzen

Ich habe mich für die automatische Deaktivierung des zweiten Prozessorkerns entschieden. Es muss beachtet werden, dass das Gerät gerootet und mit einem entsprechenden Kernel ausgestattet sein muss, der dieses Feature unterstützt. Ich verwende derzeit den Siyah Kernel, wobei das Programm mit dem stabilen Siyah Kernel 2.1.1 nicht funktioniert. Ich habe mir jedoch nun den Siyah Kernel 2.2 Beta 15 geflashed und das Tool kann damit genutzt werden.

Wie stark sich die automatische Deaktivierung des zweiten Kerns auf die Akkulaufzeit auswirkt, kann ich jetzt noch nicht sagen, da ich das Tool erst eben gerade installiert habe.

Zunächst lädst du dir mein CheckROM RevolutionHD 2.0.0 Paket herunter, das alle benötigten Dateien und eine Kurzanleitung für erfahrenere “Flasher” beinhaltet. Entpacke das Paket und gehe dann wie folgt vor.

Schritt 1: Backup erstellen

Erstelle ein Backup deiner gesamten Daten (Apps, Kontakte, Kalender, Musik, Bilder, Videos, etc pp). Ich habe das Samsung Galaxy S2 erst seit kurzem und nutze die Cloud-Dienste von Google, sodass ich mir hier keinen Kopf machen musste und einfach loslegen konnte.

Schritt 2: Gerät resetten

Mache einen Reset auf den Ursprungszustand inklusive Formatierung des USB-Speichers. Dazu gehst du zunächst in die App Einstellungen, wählst dort den Punkt Datenschutz gefolgt von Auf Werkszustand zurücksetzen. Im nächsten Dialog aktivierst du den Punkt USB-Speicher formatieren und bestätigst mit Telefon zurücksetzen. Das Smartphone wird nun neustarten und die Aktion durchführen. Danach startet das Gerät nochmal neu und du musst dich einmal durch die Grundeinrichtung kämpfen.

Schritt 3: Aufspielen der Firmware

Jetzt muss die Samsung Stock Firmware XXKI4 geflashed werden. Was diese kryptische Bezeichnung bedeutet, kannst du in diesem Artikel bei Handy FAQ nachlesen. Zum Flashen der Firmware musst du in den Download-Modus starten. Schalte dazu das Smartphone komplett aus und öffne dann den Download-Modus, indem du die drei Tasten Lautstärke leiser, Home und Power solange gedrückt hältst, bis sich eine Warnung mit gelbem Dreieck und Ausrufezeichen meldet. Jetzt musst du Lautstärke lauter drücken, um in den Download-Modus zu gelangen. Auf dem Computer öffnest du die Anwendung Odin aus dem Ordner 01_Odin. Hier bindest du die nötigen Dateien aus dem Ordner 02_Firmware ein. Die Dateien müssen wie folgt eingebunden werden:

• PIT: u1_02_20110310_emmc_EXT4.pit
• PDA: PDA_GT-I9100-XEO-I9100XXKI4
• PHONE: Phone_GT-I9100-XEO-I9100XXKI4.tar
• CSC: CSC_GT-I9100-XEO-I9100XXKI4

Sobald du das Smartphone per USB Kabel angeschlossen hast, sollte das Ganze sollte so aussehen:

Oben links wird dir gelb hinterlegt der USB Port angezeigt, über den das Samsung Galaxy S2 mit deinem Computer verbunden ist. Nochmal prüfen, ob alles fest sitzt und dann auf Start klicken. Das Flashen der Firmware dauert nun circa 3 Minuten. Auf keinen Fall Odin schließen, den PC ausmachen oder das USB Kabel ziehen, bis das Gerät wieder gestartet ist. Wenn alles glatt lief, sollte dir Odin oben links ein grün hinterlegtes Pass! anzeigen.

Schritt 4: Root Kernel flashen

Nachdem du das Gerät wieder grundlegend eingerichtet hast, kannst du es gleich wieder ausschalten und erneut den Download-Modus starten. Schließe das geöffnete Odin Fenster und öffne die Anwendung erneut. Dort bindest du nun die Datei CF-Root-SGS2_XX_XEO_KI4-v4.4-CWM4.tar aus dem Ordner 03_CF Root unter PDA ein und verbindest das Smartphone wieder per USB mit dem Computer. Das Ganze sieht dann so aus:

Nochmal schauen, ob alles fest sitzt, Start klicken und den Neustart abwarten. Jetzt hast du ein Smartphone mit root Zugriff (vergleichbar mit Administrator Rechten unter Windows).

Schritt 5: Daten auf das Smartphone kopieren

Nachdem das Samsung Galaxy S2 wieder gestartet ist, kopierst du die Datei New_XXKI4_CheckROM_RevolutionHD_V2.0.0.zip aus dem Ordner 04_CheckROM RevolutionHD und die Datei Siyah-v2.1.1-CWM.zip aus dem Ordner 05_Siyah Kernel direkt vom Computer per USB  in das Hauptverzeichnis deines Geräts.

Schritt 6: CheckROM RevolutionHD und Siyah Kernel flashen

Nachdem die Dateien kopiert sind, kannst du das USB Kabel entfernen und öffnest die App CWM, wählst dort unter Reboot den Punkt ClockWorkMod und bestätigst die Abfrage mit Reboot. Das Gerät fährt herunter und startet dann die berühmte ClockWorkMod. In der ClockWorkMod kannst du mit den Lautstärketasten (hoch und runter), der Home-Taste (meistens bestätigen), der Power Taste (meistens bestätigen) und eventuell dem Zurück Softbutton (zurück) navigieren. Die Belegung ist von Version zu Version unterschiedlich, schau einfach mal nach, was klappt

Wähle im Hauptmenü den Punkt install zip from sdcard gefolgt von choose zip from sdcard. Wähle dort zunächst die Datei New_XXKI4_CheckROM_RevolutionHD_V2.0.0.zip und bestätige die Abfrage mit Yes. Jetzt wird die CheckROM Revolution HD auf dein Samsung Galaxy S2 gespielt.

Das Ganze wäre nun schon lauffähig, ich kann aber noch die Installation des Siyah Kernels empfehlen. Dieser Kernel beschleunigt euer Smartphone dank Optimierungen ein wenig und verbraucht meiner subjektiven Empfindung nach nicht so viel Akkuleistung im Standby. Verfahre mit der Datei Siyah-v2.1.1-CWM.zip genauso wie mit der Datei des CheckROM Revolution HD.

Nun kannst du das Gerät aus dem Hauptmenü heraus neustarten und solltest die CheckROM RevolutionHD vorfinden. Optisch hat sich zunächst kaum/nichts geändert. Schau dir aber am Besten gleich einmal die App Deluxe Settings an, mit der du viele Systemeinstellungen ändern sowie den Lockscreen gehörig aufpimpen kannst. Mit der App KitchenPro hingegen können erfahrenere Benutzer auf einfache Art und Weise andere Bootanimationen, Modems (quasi das BIOS des Smartphones), Themes, Widgets, Apps, Kernels, Midifikationen und andere Dinge installieren.

Bei Fragen, Erfolgsmeldungen oder sonstigen Belangen dürft ihr gerne die Kommentarfunktion benutzen

Gerät auf Originalzustand bringen

Wer das Gerät wieder auf den Originalzustand bringen möchte, z.B. weil man wieder per Kies aktualisieren möchte oder das Gerät einschicken muss, findet übrigens bei Atomhamster eine gute Anleitung dazu.

Theorie

Bevor es an die Einrichtung des Greylistings geht, noch ein wenig Theorie zu dem Thema. Das Greylisting basiert auf der Annahme, dass die meisten Spamserver nur einmal innerhalb einer bestimmten Zeit versuchen, dir eine Spammail unterzujubeln. Schickt dir nun jemand erstmalig eine E-Mail, wird diese zunächst abgelehnt und es wird eine Kombination aus Absender, Empfänger und Uhrzeit abgespeichert. Wird innerhalb einer bestimmten Zeit noch einmal versucht, eine Mail desselben Absenders zuzustellen, wird die E-Mail durchgelassen und der Absender wird in die Liste nicht mehr zu blockierender Absender aufgenommen.

Der Absender bekommt von dem Ganzen nichts mit, da der Standard für Mailserver festschreibt, dass diese mehrfach versuchen müssen, die E-Mail zuzustellen, bevor der Absender eine Fehlermeldung bekommt und die E-Mail nicht mehr zugestellt wird.

Natürlich gibt es auch einen winzigen Nachteil: es kann etwas länger dauern, bis die E-Mail eines bisher unbekannten Absenders bei dir eintrifft. Sollte dies mal zum Problem werden, unterstützden die meisten Greylisting-Lösungen jedoch auch Whitelistst, in die Absender eingetragen werden, auf die das Greylisting nicht angewendet werden soll.

Installation

Wie ich bereits in der Einleitung geschrieben habe, ist die Einrichtung des Greylistings sehr einfach. Zunächst muss das Paket postgrey installiert werden:

aptitude install postgrey

Danach muss nurnoch folgender Eintrag zu den smtpd_recipient_restrictions in der Datei /etc/postfix/main.cf hinzugefügt

check_policy_service inet:127.0.0.1:10023

und Postfix neugestartet werden:

/etc/init.d/postfix restart

Danach sollte das Greylisting greifen.

Gewöhnliche Tipptrainer wie z.B. TIPP10 basieren auf dem Prinzip, einfach immer wieder bestimmte Tastatureingaben zu wiederholen, sodass sich hier schnell die Motivationslosigkeit einstellt und meistens auch der dauerhafte Lernerfolg auf der Strecke bleibt.

Tippen360 verfolgt einen wissenschaftlich Ansatz, bei dem Tastenpositionen über verschiedene Sinneseindrücke langfristig im Gehirn abgespeichert werden sollen. Weiterhin werden zwischendurch immer wieder Sequenzen zur progressiven Muskelentspannung durchgeführt. Didaktisch ist diese Methode sehr gut, denn so werden alle Lerntypen gleichermaßen angesprochen und die progressive Muskelentspannung steigert die Konzentrations- und Aufnahmefähigkeit.

Das Programm verspricht, das 10-Finger-Schreiben bereits in 4 bis 6 Stunden zu erlernen. Natürlich ist man nach dieser kurzen Zeit noch kein 10-Finger-Profi, aber mit kontinuierlichem Training wird sich die Geschwindigkeit im Laufe der Zeit immer weiter steigern.

Da das Programm mit Adobe AIR entwickelt wurde, kann es unter Linux, Mac OS und Windows genutzt werden.

Gewinnspiel

Wie bereits erwähnt, habe ich die Möglichkeit, fünf Lizenzen von Tippen360 zu verlosen. Hierzu müsst ihr lediglich kommentieren, wie es bei euch mit dem 10-Finger-Schreiben aussieht und was ihr ggf. bisher für Software verwendet habt, um das 10-Finger-Schreiben zu lernen.

Beim Kommentieren müsst ihr eine gültige E-Mail Adresse angeben. Bei ungültigen E-Mail-Adressen wird ein anderer Gewinner gezogen. Mehrfaches Kommentrieren ist zwar nett, steigert jedoch nicht die Gewinnchancen Die Verlosung endet mit Ablauf des 30. September 2011.

Nach der Verlosung werde ich die Gewinner anschreiben und nach ihren Kontaktdaten fragen. Marco wird euch dann die Software zukommen lassen.

Die Lösung für das Problem ist, dass man Tomcat einfach ebenso wie dem Apache Webserver VirtualHosts beibringt. Hierzu öffnet man die Datei <Tomcat>/conf/server.xml und legt hinter dem standardmäßig einzigen Host-Element die gewünschten Hostnames/Domains an. Die Syntax hierfür lautet:

<Host name="Domain" appBase="webapps/Domain"/>

Domain wird hierbei logischerweise durch die gewünschte Domain ersetzt. Der zweite Domain-Eintrag könnte zwar auch anders benannt werden, so ist die Zuordnung jedoch einfacher. In unserem Fall sollte eine Anwendung im Intranet über den Hostname projektliste erreichbar gemacht werden. Die Konfiguration dafür sieht so aus:

<Host name="projektliste" appBase="webapps/projektliste"/>

Damit der VirtualHost auch ansprechbar ist, muss der Domainname natürlich per DNS auflösbar sein. Statt die Anwendung nun wie gewohnt in Form der Datei projektliste.war direkt im webapps-Ordner zu deployen, wird die Datei in ROOT.war umbenannt und in den Ordner <Tomcat>/webapps/projektliste verschoben.

Damit ist die Anwendung nun über http://projektliste:8080 ohne Anhängen des Anwendungsnamens erreichbar. Doch damit ist das Ziel noch nicht ganz erreicht. Wer nur Tomcat einsetzt und nicht auf den Apache Webserver angewiesen ist, könnte Tomcat nun einfach über den Port 80 laufen lassen und alles ist Paletti. Wir brauchen jedoch auch den Apache Webserver auf der Maschine.

Damit die Anwendung nun via http://projektliste (ohne Angabe des Port 8080) über den Apache Webserver erreichbar wird, habe ich folgenden VirtualHost im Apache Webserver eingetragen (Minimalkonfiguration):

<VirtualHost *:80>
	ServerName projektliste
	ProxyRequests Off
	ProxyPreserveHost on
	ProxyPass / http://projektliste:8080/
</VirtualHost>

Jetzt ist die Anwendung per http://projektliste erreichbar. Ich hoffe, dass diese Anleitung dem ein oder anderen hilft, ich bin an diesem Problem fast verzweifelt

Da die Domain www.techspread.de meine Hauptdomain sein soll, habe ich die Datei /etc/apache2/sites-available/default mit folgender Konfiguration angelegt:

<VirtualHost _default_:80>
	RewriteEngine On
	RewriteRule .* http://www.techspread.de
</VirtualHost>

Danach muss der VirtualHost noch aktiv geschaltet werden:

a2ensite default
/etc/init.d/apache2 reload

Damit werden Besucher, die eine ungültige Subdomain ansurfen, direkt auf diese Webseite umgeleitet. Natürlich könnte man auch eine Platzhalter-Seite einrichten.

Zunächst legst du den Benutzer srcds an, wechselst zu diesem Benutzer und öffnest dessen Heimatverzeichnis:

useradd -m -s /bin/bash srcds
su - srcds
cd

Dann lädst dir dir das HLDS-Updatetool herunter, machst es ausführbar und startest es. Die EULA muss dabei mit yes bestätigt werden:

wget http://storefront.steampowered.com/download/hldsupdatetool.bin
chmod u+x hldsupdatetool.bin
./hldsupdatetool.bin

Unter Ubuntu 64-Bit trat bei mir der Fehler No such file or directory auf, was durch Installation des Pakets lib32gcc1 gelöst werden konnte:

aptitude install lib32gcc1

Danach können auch schon die Dateien für Counter-Strike Source heruntergeladen werden, was je nach Internetanbindung eine ganze Weile dauern kann:

./steam -command update -game "Counter-Strike Source" -dir .

Nachdem alle Dateien heruntergeladen sind, kann auch schon der Server gestartet werden. Hierzu muss in den Ordner orangebox gewechselt und der folgende Befehl ausgeführt werden:

cd orangebox
./srcds_run -game cstrike +map <Karte> -maxplayers <Anzahl> -autoupdate

Der Platzhalter <Karte> musst hierbei durch die initial zu startende Karte (z.B. de_dust) ersetzen werden (diese muss natürlich installiert sein). Der Parameter <maxplayers> legt hingegen fest, wieviele Spieler maximal an einem Spiel teilnehmen können.

Allerdings wird der Server gleich wieder gestoppt, sobald du dich abmeldest. Manuell kannst du den Server mit der Terminal-Emulation screen starten, sodass dieser auch weiterläuft, auch wenn du dich abmeldest.

Ich hab aber auch gleich mal ein Startscript parat, mit dem der Counter-Strike Source Server automatisch mit dem System gestartet werden kann:

#! /bin/bash

# Einstellungen
USERNAME=srcds
DIRECTORY=/home/srcds/orangebox
COMMAND="-console -game cstrike +map de_dust -maxplayers 8 -autoupdate"

# Ab hier nichts mehr ändern
case $1 in
        start)
                su - $USERNAME -c "cd $DIRECTORY; screen -AmdS srcds ./srcds_run $COMMAND"
                ;;
        stop)
                su - $USERNAME -c "screen -r srcds -X quit"
                ;;
        restart)
                $0 stop
                $0 start
                ;;
        *)
                echo "Usage: /etc/init.d/srcds {start|stop|restart}"
                ;;
esac

Dieses Script kopierst du nach /etc/init.d/srcds. Danach muss das Script ausführbar gemacht und in den Systemstart eingebunden werden:

chmod u+x /etc/init.d/srcds
update-rc.d srcds defaults

Die Einstellungen solltest du natürlich an deine eigenen Bedürfnisse anpassen. Ab sofort wird der Counter-Strike Source Server automatisch zusammen mit dem Betriebssystem gestartet und gestoppt. Um den Server jetzt manuell zu starten gibst du ein:

/etc/init.d/srcds start

Könnt ihr mir noch irgendwelche Plugins für den Server empfehlen? Ich werde wohl auf jeden Fall das Mani Admin Plugin installieren. Ansonsten stecke ich auch nicht so tief in der Materie, deshalb sind mir keine weiteren Plugins bekannt, die ich noch brauchen könnte.

Alternative PHP Cache

Zunächst habe ich den Alternative PHP Cache (APC) installiert. Da PHP eine interpretierte Sprache ist, muss ein PHP-Script vor der Ausführung erst kompiliert werden. APC cached das Kompilat, sodass beim nächsten Aufruf des Scripts das Kompilieren entfällt. Unter Ubuntu installiert und aktiviert man APC ganz einfach wie folgt:

aptitude install php-apc
/etc/init.d/apache2 restart

Nach dem Neustart des Webservers ist APC automatisch aktiviert – es ist keine weitere Konfiguration erforderlich (es sei denn, man will noch das letzte Quäntchen heraus holen).

memcached

Als nächstes habe ich memcached installiert. Mit memcached können Daten im Arbeitsspeicher gehalten werden. Zwar gibt es das entsprechende PHP-Modul für memcached in den Paketquellen von Ubuntu, aber aus unerklärlichen Gründen konnte das benötigte Plugin FlexiCache für WordPress nichts mit der PHP-Erweiterung aus den Paketquellen anfangen. Also habe ich das Modul wie folgt manuell installiert. Im gleichen Abwasch werden noch der memcached-Server sowie die SQLite-Unterstützung für PHP installiert (mehr dazu gleich):

aptitude install php-pear php5-dev memcached php5-sqlite
pear install memcache
echo "extension=memcache.so" >> /etc/php/apache2/php.ini
/etc/init.d/apache2 restart

Nachdem alle benötigten Pakete installiert wurden, muss das Plugin FlexiCache für WordPress installiert werden. Nach der Aktivierung des Plugins sind kleinere Einstellungen zu machen, wobei die Grundeinstellungen bereits sehr gut sind.

In den Main Options von FlexiCache aktiviert ihr zunächst einmal den Cache, stellt als Storage Engine memcached ein und erhöht ggf. noch die Ablaufzeit des Caches:

Des Weiteren habe ich den Standalone Mode von FlexiCache aktiviert. Hierbei werden Anfragen über eine entsprechende Umleitung direkt an FlexiCache gerichtet. Sollte ein gültiger Cache-Eintrag vorhanden sein, wird dieser direkt ausgeliefert, ohne das eine Zeile WordPress-Code ausgeführt wird. Sollte kein passender Cache-Eintrag vorhanden sein, übergibt FlexiCache die weitere Behandlung an WordPress und cached die Seite dann natürlich.

Die entsprechende Modifikation für eure .htaccess-Datei kann bequem über den Punkt Standalone Mode aktiviert werden, sofern die Datei über entsprechende Zugriffsrechte verfügt. Ansonsten werden euch die Anpassungen auch angezeigt und müssen per Hand in die .htaccess-Datei eingefügt werden.

Die vorhin installierte SQLite-Unterstützung für PHP wird übrigens automatisch von FlexiCache für interne Zwecke verwendet. Es erleichtert FlexiCache, veraltete Cache-Einträge zu identifizieren und diese dann zu löschen. Solltet ihr keine SQLite-Unterstützung installiert haben, wird sich dies aber laut Dokumentation des Plugins nicht negativ auf die Ladezeit auswirken.

.htaccess raus, VirtualHost rein

Über die vielfach verwendete .htaccess-Datei kann bequem das Verhalten des Webservers beeinflusst werden: Umleitungen einrichten, HTTP-Header versenden, Authentifizierung einrichten – alles kein Problem. Der Nachteil ist jedoch, dass die Datei bei jeder einzelnen Anfrage vom Webserver ausgewertet wird. Sollte also zum Beispiel eine Seite drei JavaScripts, zwei CSS-Dateien und fünf bilder einbinden, seit ihr im Besten fall mit 11 Anfragen dabei und somit muss die .htaccess-Datei 11x ausgewertet werden.

Besser ist es, die Inhalte aus der .htaccess-Datei direkt in die Konfiguration des Webservers zu übernehmen. Dort wird die Konfiguration einmal beim Start des Webservers eingelesen und muss nicht mehr erneut ausgewertet werden.

Die VirtualHost-Konfiguration für diese Domain habe ich dazu wie folgt angepasst:

<VirtualHost *:80>
	<Directory /var/www/www.techspread.de>
		// hier die Inhalte aus der .htaccess-Datei
	</Directory>
</VirtualHost>

Natürlich handelt es sich hierbei nicht um die komplette Konfiguration des VirtualHosts, sondern nur um die Inhalte, die nötig sind, um das Übertragen der .htaccess-Einträge in die Konfiguration zu beschreiben. Der Verzeichnispfad muss absolut angegeben werden und entspricht dem Speicherort auf dem Server.

GravatarCache einrichten

Die meisten Blogs verwenden Gravatare, um vor allem die Kommentare etwas persönlicher zu gestaltet. Der Nachteil besteht darin, dass die Gravatar-Server nicht unbedingt sie schnellsten sind. Deshalb habe ich den GravatarCache von Sergej eingerichtet.

Google Web Fonts auf den eigenen Webserver packen

Zwar war die Webseite nach diesen Anpassungen schon sehr schnell, ein Blick auf die Ladezeiten mit Firebug zeigte jedoch, dass die meiste Ladezeit damit verbracht wird, die vom Theme verwendeten Google Web Fonts herunterzuladen. GoogleCDN hin oder her, die Ladezeiten stimmten einfach nicht. Deshalb habe ich die Fonts einfach auf meinen eigenen Server gepackt und das Stylesheet entsprechend angepasst.

Hierzu muss zunächst im Stylesheet der entsprechende @import für die Google Web Fonts gesucht werden. Die angegebene URL wird dann einfach im Browser geöffnet. Bei mir war diese URL eingetragen: http://fonts.googleapis.com/css?family=Droid+Sans:regular,bold|Droid+Serif:regular,italic,bold,bolditalic&subset=latin

Das @import habe ich dann durch die entsprechende Ausgabe ersetzt. Der Abschnitt enthält diverse URLs, über welche die Google Web Fonts referenziert werden. Einfach die URLs aufrufen, .woff-Dateien herunterladen und auf dem eigenen Server ablegen. Danach müssen die URLs noch an den eigenen Server angepasst werden und fertig.

Weitere Optimierungen

Neben den vorgestellten Optimierungen können noch diverse Tricks umgesetzt werden. So sollte man sich zum Beispiel einmal den Apache Caching Guide durchlesen. Dass die Anzahl der installierten Plugins die WordPress-Performace beeinträchtigt und die Datenbank gepflegt werden sollte, muss ich wohl nicht großartig erwähnen.

#! /bin/bash

# Korrekte Parameteranzahl überprüfen
if [ $# -ne 4 ];
then
	echo "Usage: wordpress-cleanup <Database> <Table-Prefix> <Username> <Password>"
	exit 0
fi

# Variablen deklarieren
DATABASE=$1
WPPREFIX=$2
USERNAME=$3
PASSWORD=$4

# MySQL-Queries ausführen
mysql -u$USERNAME -p$PASSWORD $DATABASE <<EOF

	# Revisionen und automatische Speicherungen löschen
	DELETE FROM ${WPPREFIX}posts WHERE post_type=’revision’;

	# Automatisch angelegte Entwürfe löschen
	DELETE FROM ${WPPREFIX}posts WHERE post_type=’auto-draft’;

	# Als Spam markierte Kommentare löschen
	DELETE FROM ${WPPREFIX}comments WHERE comment_approved=’spam’;

	# Kommentare aus dem Papierkorb löschen
	DELETE FROM ${WPPREFIX}comments WHERE comment_approved=’trash’;

	# Nicht genehmigte Kommentare löschen
	DELETE FROM ${WPPREFIX}comments WHERE comment_approved=’0′;

EOF

# Tabellen auslesen
TABLES=`mysql -u$USERNAME -p$PASSWORD $DATABASE -se ‘SHOW TABLES’`

# Tabellen durchgehen
for TABLE in $TABLES;
do

	# Tabellen optimieren
	mysql -u$USERNAME -p$PASSWORD $DATABASE -e "OPTIMIZE TABLE $TABLE" > /dev/null

	# Tabellen reparieren
	mysql -u$USERNAME -p$PASSWORD $DATABASE -e "REPAIR TABLE $TABLE" > /dev/null

done

Wenn ihr noch weitere Optimierungen für die WordPress-Datenbank habt, werde ich die entsprechenden Vorschläge prüfen und ggf. in das Script einpflegen.