WebMillers Kft.

WebMillers – WordPress, Hoszting, SEO, Weboldal Sebesség Gyorsítás

WordPress GEO Cluster

MOLNÁR Péter
2016-02-27
Nincs hozzászólás
WordPress GEO Cluster

Egy nem mindennapi kihívás elé állított egy régi kedves ügyfelünk. 2015. májusában kezdtünk együtt dolgozni, először virtuális szerverét migráltuk át a saját szervereinkre, és állítottuk be azon 4 éles weboldalt, valamint egy preview site-ot. Egy Paralells Plesk panelt telepítettünk rá (minden szerverünkhöz egy 10 domain kezelésére alkalmas ingyenes csomag jár), és állítottuk be a teljes hoszting környezetet, ami már önmagában is remek gyakorlat volt, azonban voltak nehézségek, amelyeket meg kellett oldani. Nagyon rossz minőségű PHP kód fut az oldalon, amit próbáltunk optimalizálni, hiszen ciklikusan okozott szerver túlterhelést és ebből fakadó leállást. A tényleges megoldást nem tudtuk megtalálni (valószínűleg újra kellett volna írni a kódot), viszont egy mérésen alapuló öngyógyító mechanizmussal sikerült valamennyire működőképesen tartani.

A CACHE és CDN megoldások bevezetése után már volt pontos statisztikánk arról, hogy honnan jön a legtöbb látogató (persze ugyanez a Google Analytics-ből is elérhető volt). Látható volt, hogy a St. Louis-ban elhelyezett szerver kevés a kiszolgáláshoz, hiszen a látogatók 50% származik az amerikai kontinensről, a maradék 50% viszont európai forgalmat jelentett, és számukra az amerikai szerver informatikai szempontból “messze” volt ahhoz, hogy igazán jó felhasználói élményben legyen részük a weboldal böngészése közben – értsd: lassú volt.

Az első javaslatunk egy nagyobb szerver elhelyezése volt St. Louis-ban, amit hamar abszolváltunk, valamint javasoltunk egy második szerver üzembe helyezést Strassbourg-ban (itt van egy másik szerverközpont, amelyet használunk, ráadásul az európai forgalom 70%-a Franciaországból származott – Strassbourg evidencia volt). Elsőre ez egyszerűnek tűnhet, azonban van néhány probléma, ami megoldásra vár:

  1. Ha egy európai, afrikai, vagy ázsiai felhasználó látogatja meg az oldalt, akkor az európai szerverre kell érkeznie
  2. Ha pedig az amerikai kontinensről érkezik valaki, akkor az amerikai szerverről kell a kéréseket kiszolgálni
  3. A két szerveren a fájlokat teljes mértékben szinkronban kell tartani, hogy kiszolgálás azonos legyen mindkét szerverről
  4. A WordPress alapú weboldal mögött lévő adatbázist is két példányban, szinkronizáltan kell tartani

Valahogy így:

WordPress GEO Cluster

OpenVPNAhhoz, hogy a szinkronizációk biztonságban történjenek, ahhoz először kellett egy biztonságos csatorna, melyet a két szerver közötti OpenVPN kapcsolattal alakítottunk ki, melyet folyamatosan ellenőrzünk, ha pedig bármilyen hiba támad, először szerepet cserélnek, majd értesítést küldenek, ha a kapcsolat valamiért nem jön létre. (Erősebb biztonsági fokozatú OpenVPN szerver kialakítása a Linode szerint).

A MySQL szerver esetén egy “sima” master-master replikációt alakítottunk ki a kétszerver között. Azért nem master-slave megoldást választottunk, mert az írási műveletek egy oldalra történő szervezése jelentős késleltetést szenvedett volna, ha óceánon túli lett volna az írható adatbázis, akármelyik oldalról nézzük. A sima azért volt idézőjelben, mert ez azt jelenti, hogy a két szerver egyszerre MASTER és SLAVE, hiszen előfordulhat, hogy az amerikai oldalon kommentel valaki, amelynek meg kell jelennie az európai szerveren, és az európai szerveren közzétett új bejegyzésnek pedig ugyanúgy kell látszódnia a másik oldalon. (a DigitalOcean-nak van erről egy remek bejegyzése). Menet közben volt egy óriási szívásunk ezzel, hiszen a weboldalon futó biztonsági rendszer többször összeakasztotta a szinkronizációt, ezért az SQL log helyett fájlban tároljuk a biztonsággal kapcsolatos naplókat. Ide még beállítottunk egy figyelést, hogy riasszon a rendszer, ha nincs szinkronban a két adatbázis.

GlusterFSA következő feladat a fájlok szinkronizálásának megoldása volt – ami elsőre egyszerűbbnek tűnt, mint ahogy gondoltuk. Evidens választásnak tűnt egy GlusterFS, amellyel FUSE / INODE alapon (tehát nem időzített szinkronizálás történik, hanem ahogy változik valami, egyből elérhető a többi tag számára is) – azonban a nagy távolság miatt elképesztően lassú volt a szinkronizálás, és még az olvasási műveletek is lassúak lettek volna. Szomorúan elvetettük, majd keresni kezdtünk. Az első alternatíva a hangzatos nevű InterPlanetary File System (IPFS) volt, de ez még annyira béta volt, hogy inkább elvetettük. Ezt követően jött az SSHFS amely a kettős tömörítés miatt volt lassú, bár már nem volt annyira rossz, mint gondoltuk, de még mindig nem az ideális volt. Az utolsó mentsvár a LSYNCD volt – azonban ez csak egyirányú szinkronizálást hajt végre – és ezzel nagyjából elfogytak a használható INODE megoldások.

Végül azt vállaltuk, hogy percenként beidőzítve futtatunk egy UNISON szinkronizálást – mert ezt követően már csak a GIT alapú szinkronizálást tudtunk volna használni (ez is időzítendő, de sokkal több bajt okozhat egy konfliktus, ráadásul megszakítja a szinkronizálást is), vagy pedig BitTorrent Sync-et, amit pedig azért nem alkalmaztunk, mert nem akartuk kiengedni a tartalom legkisebb szeletét sem a publikus netre. Az UNISON-t elég egyszerű beállítani, ez hamar megvolt, majd megfuttatuk az első szinkronizálásokat. TÖKÉLETES VOLT! 1 perc alatt nem végzett a 40GB-nyi adattal, amit szinkronizálni kellett volna (lévén 1 perc nem volt elég a másoláshoz / szinkronizációhoz), de több körben, beavatkozás nélkül, simán vette az akadályokat. Nem akadt össze, ha mégis, akkor kijavította magát, szépen működött, működik jelenleg is.

NS ONEAz utolsó lépés a GEO DNS kialakítása volt, amely az egyik legfontosabb pontja az egésznek, ugyanis ez végzi a terhelés elosztást. Ha standard, nem Plesk alapú megoldást használtunk volna, akkor simán beépíthető lett volna az alapértelmezett BIND9 csomagba ez a fajta bővítés, de e helyett inkább egy külső szolgáltatóhoz fordultunk, az NS ONE-hoz. Itt egészen egyszerűen megadható, hogy mely kontinensről érkező látogató, milyen címet is kapjon, ráadásul monitoringgal is rendelkezik az oldal, amivel könnyedén figyelhetjük szervereink státuszát. Mindez havi 40$-ért nem is rossz megoldás a mellett, hogy már a regisztráció pillanatáról értékes támogatást kaptunk a szolgáltatótól annak ellenére, hogy az INGYENES StartUp csomagot használjuk jelenleg.

Az átállást vagy háromszor próbáltuk el, jelenleg monitorozzuk a rendszert teljes mértékben, és tudjuk, hogy a megfelelő tervezésnek köszönhetően megszűnnek a leállások, és a hibák, és pontosan tudni fogjuk, hogyha baj van, melyik komponenssel van a probléma.

Kategória : Megoldások Referenciák
Megosztás

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük

Ez a weboldal az Akismet szolgáltatását használja a spam kiszűrésére. Tudjunk meg többet arról, hogyan dolgozzák fel a hozzászólásunk adatait..