Author Archives: Ralph Mönchmeyer

VMware und Athlon Dual Core Prozessor – Tipp 2

Posted on by

VMware und Athlon Dual Core Prozessoren – Teil 2: CPU-Frequenz unter Linux explizit setzen

Einführung
Im letzten Beitrag
“VMware und Athlon Dual Core Prozessoren – Teil 1”
hatte ich dargestellt, dass auf Doppelcore-Prozessoren einer virtuellen Maschine möglichst nur ein Prozessor-Core zugeordnet werden sollte. Für ein optimales Setup ist dies allerdings noch nicht ausreichend.

So musste ich auf meiner Maschine (Athlon X2 4800, Host Opensuse 10.2, Gast Win XP) leider erleben, dass die Bestimmung der CPU-Frequenz, die VMware beim Starten der virtuellen Maschine vornimmt, keine konstanten Ergebnisse lieferte. Dies galt und gilt auch dann, wenn der virtuellen Maschine nur ein (virtueller) Prozessor zugewiesen wurde. Auch das im VMware Workstation Forum beschworene Abschalten von CPU Throttling und Energiesparoptionen auf Linux-Ebene (Stichwort KPowersave unter KDE) wie auch auf BIOS-Ebene änderten daran leider nichts.

Die im Gastsystem gemeldeten Frequenzwerte der CPU wichen z.T. erheblich von der realen Frequenz der CPU-Cores ab. Ist die Abweichung nach oben (zu hoch geschätzte Freq.) zu groß, kommt es in der Regel zu einem instabilen Verhalten der virtuellen Maschine. Äußere Anzeichen sind etwa ein ruckeliger Cursor, zu schnelle oder ruckartige Buchstabengenerierung etc..

Als Beispiel eine Messreihe, die ich auf meinem Athlon X2 4800 System erhalten habe (Hostsystem Opensuse 10.2, Gastsystem Win XP, VMware WS 6.0):

host: 2.4 GHz -> guest: 2.41 GHz
host: 2.4 GHz -> guest: 2.41 GHz
host: 2.4 GHz -> guest: 2.75 GHz
host: 2.4 GHz -> guest: 2.75 GHz
host: 2.4 GHz -> guest: 3.05 GHz
host: 2.4 GHz -> guest: 2.44 GHz
host: 2.4 GHz -> guest: 2.41 GHz
host: 2.4 GHz -> guest: 3.05 GHz
host: 2.4 GHz -> guest: 2.75 GHz
host: 2.4 GHz -> guest: 2.41 GHz
host: 2.4 GHz -> guest: 2.41 GHz

Genauere Werte mit mehreren Nachkomma-Stellen entnimmt man übrigens dem VMware-Logfile (Dieses findet man für jede virtuelle Maschine in dem Verzeichnis , in dem man die Maschine (besser ihr *.vmx – Konfigurationsfile) angelegt hat. Im aktuellen Log-File suche man nach Einträgen der Art

Aug 15 10:23:20.346: vmx| VMMon_GetkHzEstimate: Calculated 2753892 kHz

bzw. in der guest section des Log-Files
——————————-
Aug 15 10:23:20.850: vmx| KHZEstimate 2753892
Aug 15 10:23:20.850: vmx| MHZEstimate 2754
Aug 15 10:23:20.850: vmx| NumVCPUs 1
Aug 15 10:23:20.850: vmx| KHZEstimate 2753892
Aug 15 10:23:20.850: vmx| MHZEstimate 2754
Aug 15 10:23:20.850: vmx| NumVCPUs 1

Potentielle Fehlerursache
Leider habe ich von VMware keinen konkreten Hinweis darauf erhalten, warum die Frequenzbestimmung nicht zu konstanten Werten führt. Ich vermute aber, dass auch dieses Problem speziell bei Prozessoren auftritt, deren Cores nicht von einer zentralen Einheit aus getaktet werden. Wenn während der Frequenzbestimmung das Hostsystem die VMware-Tasks einem anderen Core zuweist und die Frequenzbestimmung Taktzyklen abfragt, dann kann es in einem solchen Fall natürlich zu fehlerhaften Werten kommen. Aber das ist wie gesagt ein wenig Spekulation ….

Eingrenzung der realen CPU-Frequenz unter Linux
Es wäre zu einfach von einer idealen Frequenz auszugehen. Bei einem Athlon X2 4800 wären dies 2400.000 MHz. In der Realität weicht die tatsächliche Frequenz jedoch immer ein wenig von der idealen Frequenz der Baureihe ab. Folgende Schritte führen zu einer genaueren Frequenzbestimmung mit Hilfe des VMware Log-Files):
1. Mehrere Starts der virtuellen Maschine und Auswahl des Frequenzwertes, der der idealen Frequenz am nächsten kommt und i.d.R. am häufigsten in einer Messreihe auftritt.
2. Bindung der VMware-Prozesse an einen CPU Core vor der Frequenzmessung
r
Hierzu verwendet man das Kommando “taskset”. Also z.B. “taskset -c 0 vmware”. Danach überprüft man die CPU Affinität des gestarteten Prozesses mit “taskset -p pid” (pid ist die Process ID des gestarteten vmware-Prozesses. Bzgl. der Bitmatrix für die CPUs siehe die “manpage” zu “taskset”).

Danach starte man die virtuelle Maschine. In der Prozessübersicht findet man dann weitere VMware Prozesse – u.a. den Prozess “vmware-vmx”. Auch hier überprüfe man die CPU Affinität. Der Prozess sollte dem gleichen CPU-Core zugeordnet sein wie der primäre “vmware”-Prozess. Die dann in der virtuellen Maschine ausgegebenen, geschätzten CPU-Frequenzen (siehe das VMware Log-File!) stimmten bei mir mit dem Wert überein, den die Auswertung einer Meßreihe wie unter 1) beschrieben ergeben hatte.

An dieser Stelle könnte man zu Recht fragen, warum man nicht einfach den Frequenzwert nimmt, den das Linux-System unter /proc/cpuinfo anbietet. (In meinem Fall tauchen da exakt 2400.000 Mhz auf.) Hierauf habe ich nur die Antwort, dass nach meiner Erfahrung die Abweichungen der Uhrzeiten im virtuellen System von der realen Host-Zeit geringer bleiben, wenn man den Frequenz-Wert verwendet, der nach den oben beschrieben Methoden ermittelt wird. (Dies unter der Voraussetzung, dass man in den VMware-Tools die Synchronization der Host und Guest-Zeit nichtaktiviert hat.)

Dauerhaftes Festlegen der CPU-Frequenz für die virtuelle Maschine
Um die CPU-Frequenz als dauerhafte Vorgabe für virtuelle Maschinen festzulegen, muß man das zentrale Konfigurationsfile für VMware bearbeiten. Unter Linux findet man dieses File bei einer Standardinstallation unter /etc/vmware/config. Dieses File ergänzt man um Einträge folgender Art:

host.cpukHz = 2412359
host.noTSC = TRUE
ptsc.noTSC = TRUE

Der angegebene cpukHz-Wert muss natürlich durch den ersetzt werden, den wir durch die obigen Schritte ermittelt haben.
Der erste Eintrag legt die (maximale) CPU Taktfrequenz fest. Die nächsten Zeilen bewirken, dass die Uhrzeit trotz evtl. variierendem Time Stamp Counter (TSC) den richtigen Wert behält. Dies ist wichtig, wenn man Stromspareigenschaften des Systems aktiviert, die zu einem CPU Throttling führen.

Hinweis 1: Ich empfehle, trotz der noTSC-Optionen im config-File Stromsparfunktionen während der Laufzeit von VMware über geeignete Tools des Hostsystems abzuschalten. Wirklich negative Erfahrungen habe ich zwar auch bei aktiviertem CPU-Powersave uind entspr. Frequenzthrottling nicht gesammelt, aber hier folge ich dem Ratschlag der VMware Gurus.

Hinweis 2: In der so konfigurierten Maschine ist eine fixe Zuordnung der VMware-Prozesse zu genau einer CPU (bzw. CPU-Core) nicht erforderlich.

Meine Erfahrungen zur Lastverteilung mit der Workstation 6 unter Opensuse 10.2 ist nach der Vorgabe einer virtuellen CPU und der Vorgabe einer exakten CPU-Frequenz außerordentlich positiv. Auch komplexe Aufgaben unter WIN XP (Adobe Flash, Photoshop, Dreamweaver, …. ) sind auf einem AMD X2 4800 Prozessor problemlos unter VMware mit einer (virtuellen) CPU ausführbar. Beobachtet man das System genau, so gewinnt man den Eindruck, dass VMware Overhead (z.B. Vorbereiten von Extends der virtuellen Platte und zugehörige Dateioperationen im Linux-File-System; Netzwerkoperationen) bei Bedarf trotzdem durch den zweiten Prozessor-Core erledigt wird.

Für meine Diskussion mit VMware siehe:
http://communities.vmware.com/message/724123#724123

Lokale Suchmaschine für Websites I

Posted on by

Einführung
Bei der Erstellung von Websites – auch kleineren Umfangs – kommt von Kunden immer häufiger die Anforderung eine kleine Suchmaschine zu integrieren, die zu einem oder einigen wenigen Suchbegriffen die relevanten Seiten der Website findet.

Da dies eine Standardaufgabe ist, hofft man als Entwickler, im Internet nicht nur fertige und freie OpenSource Suchmaschinen sondern auch Hinweise darauf zu finden, wie man einen solchen Service evtl. selbst programmiert. Interessanterweise liefert eine Internetrecherche im nichtkommerziellen Bereich gar nicht so viele passende Treffer. Fast verschwindend ist die Anzahl brauchbarer Anleitungen zum Eigenbau mittels PHP. Der oft zu findende Hinweis, man möge doch bitte die Volltextindizierung von MySQL benutzen, nützt einem ohne entsprechendes Hintergrundswissen zunächst auch nicht so viel.

Eine an und für sich gelungene Einführung von Daniel Solin
http://www.onlamp.com/pub/a/php/2002/10/24/simplesearchengine.html?page=1

leidet darunter, dass sich die Ausführungen auf eine Beispielmaschine beschränken, die genau einen Suchbegriff zulässt.

Da wir selbst in einem unserer letzten Aufträge eine Suchmaschine implementieren mussten, möchten wir mit einigen Tipps und Programmhinweisen die Diskussion von Daniel Solin erweitern und ergänzen.

Zielsetzung ist dabei Folgendes:

1. Eine kurze Diskussion einer möglichen Strategie zur Bestimmung der “Relevanz” einer getroffenen Seite. Eine solche Diskussion fehlt im Artikel von Solin; die Relevanz einer getroffenen Seite wird aber immer wichtiger, wenn bei der Suche mehr als ein Suchbegriff verwendet wird.
2. Eine Darstellung des Programmablaufs zur Erstellung der Datenbank.
3. Eine Darstellung des Programmablaufs für den Suchvorgang selbst, wenn genau ein Suchbegriff eingesetzt wird.
4. Erweiterung der Suche auf mehrere Suchbegriffe, wobei die Begriffe in exakter Schreibweise gefunden werden sollen.
5. Erweiterung des Programmablaufs für eine unscharfe Suche.

Wir werden diese Punkte in einzelnen Blog-Artikeln aufgreifen und hoffen, damit dem einen oder anderen Webseiten-Entwickler, der den Einsatz von PHP nicht scheut, eine Hilfestellung zu leisten.

Installation von MediaWiki beim Provider 1&1

Posted on by

Einführung
Will man die Opensource Software “MediaWiki” beim Provider 1&1 installieren, so gibt es einige kleinere Hürden zu überwinden. Voraussetzung für die aktuellen MediaWiki-Versionen ist in jedem Fall ein Webhosting-Paket, das eine MySQL-Datenbank (am besten MySQL 5) und einen PHP5-Interpreter beinhaltet. Die Standardeinstellungen bzgl. des nutzbaren Speichers für PHP-Prozesse sind bei 1&1 ausreichend (40 MB; gefordert sind 32MB).

Wir folgen mit der nachfolgenden Beschreibung in Teilen einem Blog-Artikel von Johan Cyprich
(http://www.cyprich.com/2007/08/17/installing-mediawiki-on-11/#),
auf den wir als grundlegende Lektüre verweisen. Zur generellen Einführung in MediaWiki und dessen Installation ist (trotz einiger Schwächen) vielleicht das Buch “MediaWiki Administrators’ Tutorial Guide” von M. Rahman, PACKT Publishing, 2007, geeignet.

Es sind vor allem folgende drei Punkte, die bei der Installation im Rahmen eines 1&1 Webhosting-Pakets zu beachten sind:

  • Während der Installation von MediaWiki muss das Installationsprogramm lokale Einstellungen in ein bestimmtes Verzeichnis “config” schreiben. Hierzu muß die Schreibberechtigung für das Verzeichnis gesetzt sein. Zudem muss im Zuge der Installation eine Datei “/config/index.php” gefunden werden, was ohne weitere Maßnahmen misslingt.
  • Normalerweise wird das PHP5 – Modul des Web-Servers bei 1&1 nur dann gezogen, wenn die entsprechende PHP-Datei die Endung .php5 aufweist. Dies kann und sollte man für die Wiki-Seiten ändern.
  • Die Zugangsdaten zur Datenbank sollten zur Sicherheit in einem für Benutzer nicht zugänglichen Verzeichnis außerhalb der Wurzelverzeichnisse der angebotenen Websites hinterlegt und zur Laufzeit in die PHP-Skripts eingebunden werden. (Hier unterscheidet sich unser Vorgehen übrigens von der Beschreibung von Cyprich.)

——————————————————————————–

Schritt 1: Anlegen oder Auswahl der Datenbank
MediaWiki kann seine Tabellen in einer bereits vorhandenen Datenbank anlegen. Zur Unterscheidung von Tabellen anderer Applikationen kann man während der Installation einen Prefix für die Tabellennamen definieren. Hat man mehrere Datenbanken zur Verfügung, so lohnt es sich ggf. allein aus Platzgründen, für MediaWiki eine separate Bank zu reservieren. Das Erstellen von Backups vereinfacht sich dann zudem.

Die Anlage einer spezifischen Datenbank erfolgt nach dem Kundenlogin bei 1&1 über die Auswahl des Punktes “MySQL-Datenbank” unter der Leiste “Homepage/Anwendungen”. Das aufgehende Fenster gibt eine Übersicht über bereits angelegte Banken und bietet zudem die Möglichkeit, eine neue Bank zu initialisieren. Die Dialoge sind leicht verständlich. Wir gehen hier nicht weiter darauf ein. Als Version der Bank wähle man trotz der Warnhinweise MySQL 5. Nach der Anlage der Datenbank erhält man die Informationen zum Datenbankserver, zum Datenbanknamen, zum Datenbanknutzer und zum Passwort durch Anklicken des entsprechenden Buttons “Bearbeiten” in der Übersicht zu den vorhandenen Datenbanken.

Schritt 2: Anlegen einer PHP-Include Datei mit den Zugangsdaten für die Datenbank
Dieser Schritt ist wie Schritt 10 optional; wir raten aber dazu, ihn aus Sicherheitsgründen auszuführen.
Bei 1&1 bekommt man pro Vertrag typischerweise einen einzigen zusammenhängenden Verzeichniszweig für seine Dateien auf einem Server zugewiesen. Das Wurzelverzeichnis dieser Ordnerstruktur sollte man typischerweise nicht als Wurzelverzeichnis seiner Website oder seiner Websites definiert haben. Vielmehr weist man die Webdomainen definierten Verzeichnissen unterhalb der Wurzel der eigenen Verzeichnisstruktur zu.

Hat man etwa 2 Domainen “mydomain.de”
und “mydomain.com” reserviert, so wird man typischerweise Verzeichnisse “/de” und “/com” definieren, unter denen man die Index- und sonstigen Webdateien der jeweiligen Site platziert. (Die Zuordnung der Domaine zum jeweiligen Verzeichnis erfolgt bei 1&1 unter dem Punkt “Domainverwaltung”). Dieses Vorgehen hat den Vorteil, dass man außerhalb der Verzeichnisse für die Inhalte der Webdomainen weitere Verzeichnisse definieren kann, die für Besucher der Websites nicht direkt sichtbar oder zugänglich sind. Damit kann man insbesondere beim Einsatz von PHP oder PERL die Sicherheit etwas verbessern; man kann etwa sensible Dateien in genau solchen nicht sichtbaren Verzeichnissen unterbringen und diese zusätzlich durch “.htaccess”-Dateien weiter gegen unbefugte Zugriffe absichern.

Wie man seine MediaWiki-Seiten in der zugänglichen Verzeichnisstruktur aufhängt, ist ein wenig Geschmackssache. Sinnvoll ist ggf. die Definition einer Subdomaine. Wir gehen nachfolgend davon aus, dass die (Installations-) Dateien für MediaWiki in einem speziellen Verzeichnis – das also als lokale Wurzel für den Wiki-Bereich fungieren soll – abgelegt wurden. In unserem Beispiel etwa im Verzeichnis: “/de/mywiki”.

Nun definiert man mit Hilfe eines FTP-Tools auf oberster Ebene der eigenen Verzeichnisstruktur ein Verzeichnis mit beispielsweise dem Namen “mywiki_include” (Pfad: /mywiki_include) und legt darunter eine PHP-Datei – beispielsweise “db_access.php” – mit folgendem Inhalt an:

<?
$wgDBserver = “dbxxxx.1und1.de”;
$wgDBname = “dbxxxxxxxxx”;
$wgDBuser = “dboxxxxxxxxx”;
$wgDBpassword = “xxxxxxxxx”;
?>

Man ersetze dabei die xxx-Platzhalter durch die eigenen Access-Daten für die in Schritt 1 gewählte Datenbank.

Das Verzeichnis “mywiki_include” kann man danach noch mit einer “.htaccess-Datei” schützen. Wir gehen hier nicht weiter auf den “.htaccess”-Mechanismus ein, verweisen aber auf die Möglichkeit, einen solchen Schutz bei 1&1 unter der Rubrik “Zugänge” über den Punkt “Geschützte Verzeichnisse” zu aktivieren. Man legt dabei zunächst eine Zugangskennung fest und ordnet diese und ein zugehöriges Passwort dann dem zu schützenden Verzeichnis (hier “mywiki_include”) zu.

Schritt 3: Kopieren der MediaWiki-Installationsdateien in das Verzeichnis für den Wiki-Bereich
Die aktuellen MediaWiki-Dateien holt man sich (als tar-Archiv) am besten von folgender Website: http://www.mediawiki.org/wiki/Download/de.
Die Dateien kopiert man dann in unserem Beispiel in das Verzeichnis “/de/mywiki”.

Schritt 4: Erzeugen einer htaccess-Datei zur Änderung des Dateityps für PHP5
Das Wurzelverzeichnis zum Wiki (hier: /de/mywiki) ergänze man um eine Datei “.htaccess” oder erweitere eine evtl. bereits vorhandene .htaccess-Datei) mit folgendem Inhalt:
AddType x-mapp-php5 .php
Nun werden auch Dateien mit der Endung .php (soweit sie aus diesem Verzeichnis stammen) durch den PHP 5 Interpreter verarbeitet.

Schritt 5: Umbenennen und Ersetzen des “config”-Verzeichnisses
Man bennene nun (per FTP-Tool) das “config”-Verzeichnis (/de/mediawiki/config) um in “configure”. Danach erzeuge man ein neues Verzeichnis “config” (/de/mywiki/config) und erteile (per FTP) einen temporären Schreibzugriff auf dieses Verzeichnis (z.B. die UNIX-Rechtekombination “757” ).

Schritt 6: Starten der Installation
Man rufe im Browser seiner Wahl (z.B. Firefox) die Seite “index.php” oder die Seite “index.php5” im Wiki-Verzeichnis auf.
Das sollte etwa so aussehen: “http://www.mydomain.de/mywiki/index.php5”. Auf der dann im Browser angezeigten Seite klickt man den Punkt “set_up wiki” an.
Bei der nachfolgenden Fehlermeldung ersetzt man in der angezeigten Adresszeile des Browsers “config” durch “configure” und drückt die Enter-Taste, um die geänderte
Adresse
“http://www.mydomain.de/mywiki/configure/index.php”
aufzurufen.

Schritt 7: Ausfüllen des MediaWiki-Installationsformulars
Wir nehmen an, dass im oberen Bereich der nun angezeigten Seite keine Fehlermeldungen erscheinen. Man sollte danach alle erforderlichen Angaben im Formular ausfüllen – im Besonderen auch die Angaben zum Datenbankaccess. (Wir werden die entsprechenden Zeilen später in der zugehörigen PHP-Datei identifizieren und ersetzen).

Schritt 8: Verschieben der Datei LocalSettings.php
Nach der Abschlußmeldung zur Installation verschiebe man (per FTP) die Datei “LocalSettings.php” vom “config”-Ordner in das Hauptverzeichnis des Wiki-Bereichs. In unserem Fall also von “/de/mywiki/config/LocalSettings.php” nach “/de/mywiki/LocalSettings.php”. Danach ist das WIki bereits lauffähig und man kann einen ersten Blick darauf werfen, indem man im Browser “http://www.mydoman.de/mywiki” als Adresse angibt.

Schritt 9: Entfernen der in Schritt 5 vergebenen Schreibberechtigung auf dem Verzeichnis “config”
Bitte setzen Sie die Zugangsberechtigungen auf dem Verzeichnis “config” wieder auf die Standardwerte (keine Schreibberechtigung).

Schritt 10: Ersetzen der Datenbank-Zugangsdaten in der Datei “LocalSettings.php”
Die eben in Schritt 8 verschobene Datei “LocalSettings.php” lädt man sich per FTP auf den lokalen Rechner zuhause, macht sich zur Sicherheit eine Kopie davon, und editiert dann die Datei. Man identifiziere die Einträge zum Datenbankzugang der Form

$wgDBserver = “dbxxxx.1und1.de”;
$wgDBname = “dbxxxxxxxxx”;
$wgDBuser = “dboxxxxxxxxx”;
$wgDBpassword = “xxxxxxxxx”;

Man lösche diese 4 Zeilen (!!!!!! nicht aber die Zeile mit dem Inhalt $wgDBtype = “mysql”;) und ersetze Sie durch eine Include-Anweisung (require_once) mit einer relativen Pfadangabe zur Datei “db_access.php” aus Schritt 2. In unserem Beispiel sähe die Zeile dann so aus:

require_once( “../../mywiki_include/db_access.php”);

Die so modifizierte Datei “LocalSettings.php” speichert man nun und lädt sie per FTP auf den Webserver bei 1&1 in das Verzeichnis “/de/mywiki/” (Überschreiben der vorhandenen Datei – letztere ggf. vorab zur Sicherheit umbenennen und als Sicherheitskopie ablegen).

Abschließend sollte man im Browser erneut in das nun fertig installierte Wiki gelangen können. Nun kann man sich entspannt den erforderlichen Administrationsaufgaben widmen oder die ersten Wiki-Seiten anlegen.

OX5 – Login Problem mit Konqueror – Nachtrag 1

Posted on by

Wie man der Kommunikation zu den Konqueror-Bugs

http://bugs.kde.org/show_bug.cgi?id=150070 und http://bugs.kde.org/show_bug.cgi?id=149957

entnehmen kann, gibt es seit ein paar (Entwicklungs-) Versionen wohl tatsächlich Schwierigkeiten bei der Interpretation von HTTP Header Direktiven. Es handelt sich dann also nicht um ein OX5 spezifisches Problem des Browsers Konqueror.

Die KDE-Entwickler arbeiten anscheinend daran – das ist beruhigend, obwohl man sich natürlich fragt, wie denn die Tests aussehen, wenn in einen so wichtigen Bereich eines Browsers eingegriffen wurde. Auf der anderen Seite führt aber auch nicht jeder Benutzer mit so hoher Frequenz wie ich ein Update der KDE Umgebung durch.

Betrachten wir das Ganze also mal als Test, wie denn die Opensource Gemeinde mit so einem Problemchen umgeht. Ich bin jedenfalls gespannt, ob und in welcher der nächsten Versionen der von SUSE publizierten KDE rpms dieser Fehler behoben sein wird.

Ergänzung:
Mir ist bei der Analyse des HTTP-Datenverkehrs zwischen OX-Server und Browser (mittels Wireshark) aufgefallen, dass die OX-Leute für den Redirect im Login-Prozess eine “REFRESH”-Direktive im HTTP-Header benutzen. Das ist insofern bemerkenswert, als dies kein HTTP 1.1-Standard ist, wenngleich diese Direktive von Firefox, IE und Opera unterstützt wird. Bis zur Version 3.5.7-64.1 wohl eben auch von Konqueror. Nur danach halt leider nicht mehr!

Eine Lehre, die sich an diesem Beispiel erneut bestätigt, ist die Folgende:

Gerade beim produktiven Einsatz von Opensource muss jedes Update des Desktops vor dem Produktiv-Einsatz gründlich auf die Funktionstüchtigkeit der Standard-Arbeitsabläufe hin getestet werden. Es wird keineswegs alles besser, wenn ein neues (Zwischen-) Release auf den Markt kommt.    


VMware – bei anracon täglich im Einsatz

Posted on by

VMware – bei anracon unter Linux und Windows im produktiven Einsatz

Dies ist zwar ein Linux-Blog. Dennoch kommt in unserer Firma auch Windows zum Einsatz. Entscheidende Gründe hierfür sind:

  • Die weite Verbreitung von Windows bei unseren Kunden (im Besonderen bei Konzernkunden).
    Es wäre zu zeitaufwändig, Projektdokumente zwischen Openoffice und den MS Produkten hin- und her (!) zu transformieren. Dies funktioniert im professionellen Umfeld nur mit erheblichem Aufwand, der einem leider nicht bezahlt wird. (In eine Richtung – z.B. von Openoffice zu MS Office – arbeitet man allerdings deutlich aufwandsärmer. Beim Anlegen neuer Dokumente verwenden wir diese Richtung sehr oft. Leider tritt aber sehr viel häufiger der Fall ein, dass ein Dokument dauerhaft gepflegt werden muss. Dann arbeiten wir, wo immer erforderlich, direkt mit den MS-Produkten.)
  • WEB-Entwicklung: Wir setzen die Produkte von Adobe/Macromedia ein.
    Diese sind rein für MS Windows entwickelt worden. Man kann Flash und Dreamweaver 8 zwar unter Crossover Office (Wine) zum Laufen bringen. An einigen Details, die für den produktiven Einsatz zumindest störend sind, gibt es dann aber doch immer wieder Schwierigkeiten. Zudem ist die Performance unter Crossover Office wenig berauschend. Web-Entwicklungstools sind unter Linux zwar im Aufbau; ihre Leistungsfähigkeit und ihr Umfang scheinen uns aber noch nicht mit den Eigenschaften der Adobe/Macromedia-Produkte vergleichbar.

Es galt und gilt daher, bei aller Bevorzugung von Linux einen ausgewogenen Einsatz von Windows zu realisieren. Der Kompromiss bei anracon sieht wie folgt aus:

  • Serverbetrieb: Alle für den täglichen Betrieb benötigten Serverkomponenten (Groupware, LDAP, CUPS, Samba, MySQL, Postgres, Dateiserver, Apache etc.) laufen komplett auf dedizierten Linux-Systemen.
  • Clientbetrieb: PCs für Webentwicklung sind Windows-Rechner mit VMware oder Linux-Rechner mit VMware.

Ob wir auf einem Client-PC Windows oder Linux als Primärsystem (im VMware Chargon: “Host-System”) einsetzen, machen wir (nach vielen Tests) heute rein von der HW-Konfiguration abhängig:

  • Auf neueren Maschinen mit Doppelcoreprozessor (z.B. Athlon X2, ab Baureihe 4000+) und ausreichendem Speicher (> 2GByte) verwenden wir als Host-System Linux. Hier gibt es bei dedizierter Zuordnung von VMware und des Gastsystems (noch XP) keinerlei Probleme mit der Performance der benötigten Applikationen. Die komplette Web Premium Suite CS3 läuft heute auf einem System mit einem Athlon X2 4800 anstandslos.
  • Auf älteren Maschinen mit Einzelprozessor und geringerem Hauptspeicher ist dagegen MS Windows das Hauptsystem. Linux-Applikationen bieten wir hier im Rahmen einer maßgeschneiderten Linuxinstallation auf einer virtuellen VMware-Maschine an. Dies ist insbesondere bei plattformübergreifenden Tests sehr angenehm.

Wir haben mit dieser Vorgehensweise seit ca. sehr positive Erfahrungen gemacht und können den Einsatz von VMware sehr empfehlen.

Wir wollen an dieser Stelle nicht unerwähnt lassen, dass VMware natürlich auch unschätzbare Dienste leistet, wenn es gilt, neue Betriebssysteme, Applikationen, Netzwerkkonfigurationen und Firewall-Einstellungen vor dem Produktiveinsatz zu testen.

In einem kommenden Beitrag befassen wir uns näher mit der VMware-Istallation auf Systemen mit inzwischen betagteren Athlon X2 Prozessor. Hier gibt es Besonderheiten bzgl. der problematischen Synchronisation der CPU Cores zu beachten.