Onderwerp: GlusterFS/Realtime mirroring

Beste WHT'ers,

Ik ben al een tijd bezig om een goede/stabiele manier te vinden om data van twee servers realtime te mirroren.

Het gaat om een mail/apache omgeving. Beide servers staan in een verschillend datacenter. Er is een 100mbit VLAN tussen deze servers. De ping tussen beide servers is gemiddeld 1.5 ms.

Nu heb ik een aantal mogelijkheden uitgezocht en geprobeerd. De meest leuke en voorkomende oplossingen waren GlusterFS en DRBD.

Ik heb gekozen voor de GlusterFS oplossing.
GlusterFS is juist geconfigureerd, de apache (/var/www) en mail (/var/vmail) directories zijn gemount op beide servers. Alles werkt prima.

Maar... op een ding na, de performance bij sommige websites.
We hebben een PHP/MySQL content management systeem draaien die gebruik maakt van het Codeigniter framework (wellicht bekend voor de PHP freaks onder ons).

Wanneer ik het CMS in mijn browser laadt, duurt het laden 0.5 seconden gemiddeld. Haal ik het CMS uit de GlusterFS omgeving dan is de laadtijd gemiddeld 0.005.

Daarnaast hebben we ook een (test) OsCommerce webshop draaien die wel snel laadt.

Nu was eigenlijk mijn vraag; wat is hier aan te doen en waardoor komt het? Wellicht een gigabit verbinding tussen beide servers? Maar lost dat het ook daadwerkelijk op?

Hebben meerdere mensen hier een soortgelijke omgeving draaien in combinatie met een PHP framework?

Ik ben erg benieuwd naar jullie reacties. Alvast bedankt en een fijn weekend.

Groeten,
Bart

Heb je 't PHP process als een gestraced? Daarmee kan je verder komen!

Mijn ervaring met NFS is dat heel veel stat() calls (file_exists() in PHP) dodelijk zijn. Ik kan me voorstellen dat dat hier ook 't geval is!

Hoe mount je gluster? via nfs of via hun eigen adapter?
Hun eigen adapter is vele malen sneller en beter namelijk.

@Eflicta: d'r zijn wellicht stat en file_exist calls aanwezig. Hoe kan ik het PHP proces het beste traceren?

@cyberbootje: ik mount het via de GlusterFS adapter: /usr/sbin/glusterfs -f /etc/glusterfs/glusterfs.vol /var/vmail/

't makkelijkste, wat ik altijd doe:

sleep(10); in je php mikken, pagina openen en dan in de shell: ps faux | grep php

met 't PID (ff gokken welke je moet hebben ): strace -p <PID>

Maar dit is afhankelijk van je setup. Hierboven werkt alleen voor CGI. Gebruik je mod_php, moet je 'n apache process stracen

Elk netwerk filesystem heeft last van de stat() call latency, of het nu NFS is of iets anders, een stat call kan niet worden gecached en moet altijd over het netwerk.

Als voorbeeld, wordpress doet zonder WP Supercache ruim 900 stat call, waar Magento er 9000 doet!

Een stat call duurt iets in de orde van 80ns, maar je moet ook je netwerk latency er bij berekenen. Zo kan je ineens 400ms kwijt zijn aan alleen maar vragen: Bestaat deze file?

PHP is wat dat betreft gewoon een drama, als je een strace los laat en ziet wat require_once en include_once doen, daar wordt je echt droevig van. Het is jammer dat PHP zo groot gebruikt is, want zonder iets als APC (met stat cache aan!) wil het vaak gewoon voor geen meter schalen.

@Eflicta ik maak geen gebruik van de CGI mod. Ik merk wel dat er veel GlusterFS processen ontstaan wanneer ik een 'grote' php website bezoek.

@Wido: bedankt voor je antwoord. Ik heb APC (met stat cache) enabled in het PHP Framework. Het resultaat is een heel stuk beter. In plaats van een 0.5 sec parsetime, nu 0.0591 sec. We komen er wel....

Maar... misschien is het toch verstandiger om beide servers in hetzelfde datacenter te hangen. Dan is het netwerk latency ook een stuk beter. Toch?

Natuurlijk zal hoogstwaarschijnlijk de netwerk latency kleiner zijn op het moment dat je apparatuur dichter bij elkaar zet.

Wat ik me echter afvraag, is dat altijd realistisch?
Ik kan me namelijk prima voorstellen dat je bijvoorbeeld met klanten hebt afgesproken dat apparatuur geografisch gescheiden staat. Nu is 2 racks verschil natuurlijk ook een geografische scheiding (wel een beetje relatief natuurlijk ).

Wat ik me afvraag, zou het niet mogelijk zijn om een soort van cache lokaal op te bouwen zolang bestanden enkel gelezen worden?
Als een soort van geheugenbuffer tussen de GlusterFS en de files die worden opgevraagd.
Bijvoorbeeld, je zou een file hebben die een paar miljoen keer wordt opgevraagd per dag, als je die nu lokaal zou kunnen cachen in het intern geheugen, of op een HD, tot het moment dat GlusterFS een write krijgt erop via de 'replicatie' of er lokaal een write op binnenkomt, heb je een systeem wat waarschijnlijk veel sneller kan reageren op de standaard stat() verzoeken.

Bestaat iets als wat ik bovenstaand omschrijf eigenlijk? - Ik heb er tot nu toe nog niet echt onderzoek naar gedaan, maar zie dergelijke techniek toch wel als een oplossing om de functionaliteit van GlusterFS te kunnen combineren met de snelheid van een lokale HD/SSD .

Oorspronkelijk geplaatst door Icheb

Natuurlijk zal hoogstwaarschijnlijk de netwerk latency kleiner zijn op het moment dat je apparatuur dichter bij elkaar zet.

Wat ik me echter afvraag, is dat altijd realistisch?
Ik kan me namelijk prima voorstellen dat je bijvoorbeeld met klanten hebt afgesproken dat apparatuur geografisch gescheiden staat. Nu is 2 racks verschil natuurlijk ook een geografische scheiding (wel een beetje relatief natuurlijk ).

Wat ik me afvraag, zou het niet mogelijk zijn om een soort van cache lokaal op te bouwen zolang bestanden enkel gelezen worden?
Als een soort van geheugenbuffer tussen de GlusterFS en de files die worden opgevraagd.
Bijvoorbeeld, je zou een file hebben die een paar miljoen keer wordt opgevraagd per dag, als je die nu lokaal zou kunnen cachen in het intern geheugen, of op een HD, tot het moment dat GlusterFS een write krijgt erop via de 'replicatie' of er lokaal een write op binnenkomt, heb je een systeem wat waarschijnlijk veel sneller kan reageren op de standaard stat() verzoeken.

Bestaat iets als wat ik bovenstaand omschrijf eigenlijk? - Ik heb er tot nu toe nog niet echt onderzoek naar gedaan, maar zie dergelijke techniek toch wel als een oplossing om de functionaliteit van GlusterFS te kunnen combineren met de snelheid van een lokale HD/SSD .

Je hebt hiervoor diverse Translators/Plugins, zie:
http://www.gluster.com/community/doc...hp/Translators

En met name:

http://www.gluster.com/community/doc...mance/io-cache