Ein etwas flapsiges Definitionspaar, das den Kern der Sache aber gut trifft, ist
- transparent: kann man nicht sehen, ist aber da
- virtuell: kann man sehen, ist aber nicht da.
Das passt für virtuelle Bilder in der geometrischen Optik (und die dort verwendeten transparenten Scheiben und Linsen auch) wie auch für die IT-Begriffe, die sich mit diesen Worten verbinden.
Ein virtueller Web-Server war das, was man sich in den 90ern leisten konnte: eine (eigene)Miet-Maschine war viel zu teuer für die meissten Anwendungen.
So ein Server ist „virtuell“ - also real nicht vorhanden sondern nur dargestellt durch eine Kombination von Hard- und Software - genau so, wie virtueller Speicher es eben ist. So einen virtuellen Arbeitsspeicher kann man „sehen“ - also wie Arbeitsspeicher benutzen - obwohl er gar nicht da ist; seine Existenz wird durch Kombination von Prozessor, MMU, Festplatte und Software simuliert.
So ein virtueller Arbeisspeicher hat Vorteile: gross und billig, und Nachteile: langsam wie ne Schildkröte.
Virtuelle Server sind genauso simuliert, verhalten sich wie separate Maschinen obwohl mehrere sich eine reale Maschine teilen. Die Virtualisierungstechnik ist in den letzten 15 Jahren massiv vorangekommen und wird langsam Mainstream: ich kenne viele, die auf ihren Desktops virtuelle Maschinen laufen lassen um auch andere als das präferierte Betriebssystem verwenden zu können.
Nur bei den Servern eines Berliner Webhosters den wir hier aus Gründen der Höflichkeit nicht nennen wollen, ist kein Fortschritt angekommen.
Mietet man da eine virtuelle Maschine, dann bekommt man für kleines Geld einen root-Zugang zu einer VM-Instanz, die sogar über ganz vernünftige Speicher- und Prozessorleistung verfügt. So weit, so schön. Das Dateisystem nennt sich - wie bei anderen auch - /dev/vzfs und wird auf der / eingehängt, alles normal.
Sieht man sich dann die Prozessliste an, dann fallen nfs-Daemonen auf: root 4 2 0 Okt02 ? 00:00:00 [rpciod/2340629/] … root 22 2 0 Okt02 ? 00:00:00 [rpciod/2340629/] root 23 2 0 Okt02 ? 00:00:00 [rpciod/2340629/] root 24 2 0 Okt02 ? 00:00:00 [nfsiod/2340629] viele noch dazu.
Da ich kein NFS in meiner Instanz installiert habe müssen die zum darunterliegenden Host-Betriebssystem gehören.
Und dass die virtuelle Festplatte tatsächlich per NFS bereitgestellt wird, merkt man vor allem daran dass SO EIN SCHEISS KOMPLETT KACK IST FÜR mysql ODER Apache2!
So. Das musste jetzt raus. Die Apache2-Config sagt:
¶
The accept serialization lock file MUST BE STORED ON A LOCAL DISK.¶
¶
Mutex file:${APACHE_LOCK_DIR} default
Das meinen die Autoren ernst! Wenn man die für Mutex-Zwecke verwendeten Files auf ein NFS legt, dann GEHT DAS NICHT!
Aber sowas ficht in Moabit keinen an - so ein Kack wird trotzdem verkooft, die meissten Kunden merken es ja nicht. Was daran liegen kann, dass der Durchschnittskunde gar nicht die Kenntnisse hat, das so weit zu debuggen, dass ein Mutex-Fehler als Ursache für „geht manchmal, dann immer seltener und dann muss man halt mal den Apache neustarten“ auzumachen ist.
Statt dessen treiben solche Leute dann vermutlich in irgendwelchen Foren die Autoren von brauchbaren Web-Apps in den Wahnsinn mit Fragen wie „warum kommt da laufend ,database has gone away‘ im log?“. Ganz einfach: weil auch mysql grantelt, wenn man einem Prozess vorlügt, dass ein File geschrieben wurde, das aber erst irgendwann nächste Woche vom NFS tatsächlich mal irgendwohin geschrieben wird.
Nun könnte man sagen, dass es schlechtes Software-Design ist, wenn ein Mysql oder ein Apache annimmt, dass File-Operationen atomisch sind und sich daher für Mutex-Funktionen eignen. Das mag ja sein. Aber das ist eben shcon seit 20 Jahren so gelöst und funktioniert auch über all da, wo das Dateisystem eben nicht die vom NFS bekannten Nachteile virtueller Dateisystem hat.
tl;dr? Kurzfassung: OwnCloud auf virtuellen Servern aus Moabit: kannste voll vergessen. Geh zu einem Hoster, der fürs gleiche Geld zwar weniger Plattenplatz anbietet, dafür aber per iSCSI oder sonst irgendwie so, dass Apache und mysql klarkommen. Dann klappts auch mit der OwnCloud