Weblabor

A közelmúltban szűntek meg az Extra.hu utolsó szerverei és ezzel már nem titok a titok: eláruljuk, hogyan működött.

Adattárolás

Amikor megörököltük az Extrát, az adatok fele Promise Vtrak M500 típusú „buta” dobozokon, a másik fele pedig egy HP EVA 6000 SAN egységen lakott. Mivel a 4 db Promise doboz fájlrendszere, berendezését tekintve nem volt tökéletes, sürgős volt az EVÁ-ra való átköltözés. Az Extra folyamatos terhelése és a fájlrendszer lassúsága miatt a költöztető szkript több hónapig futott mire már csak néhány ezer, javarészt régi, nem használt felhasználó maradt a dobozokon. Ekkor azonban közbeszólt a sors: megsérült a fájlrendszer. Hiába kísérleteztünk az adatok visszaállításával, a JFS fájlrendszeren egy a fejlesztők számára ismert hibából kifolyólag a szuperblokk eltűnt, az adatok pedig elvesztek.

Mind az EVA, mind a Promise dobozok előtt fibre chanelen (FC) rákötött gépek osztották ki NFS-en a tárhelyeket.

Mentés

Az Extrán már akkor is volt mentés, amikor megkaptuk, ezt a szoftvert írtuk újra úgy, hogy párhuzamosan tudjon futni. Ezzel lehetővé vált az SQL szerverekről a napi, a tárhelyekről a heti adatmentés. Nagy újdonság volt az is, hogy a mentéseket FTP-n keresztül elérhetővé tettük, így a felhasználók szükség esetén gyorsan hozzájuthattak.

Adatbázisszerverek

Mivel nem találtunk általános megoldást az adatbázisszerverek redundanciájára, minden felhasználó az SQL szolgáltatás aktiválásakor fölkerül valamelyik szerverre. Mivel az SQL szerverek lelki világukat tekintve nem voltak túl bonyolult lények, hardverhiba esetén üzembe állítottunk egy másik szervert, és arra költöztettük át, vagy állítottuk vissza mentésből az adatokat.

Az adatbázisoknál gyakoriak voltak az olyan problémák, amikor egy felhasználó elfelejtett indexeket rakni egy-egy táblára, vagy megpróbált full table scannel végigmenni egy több százezer rekordot tartalmazó táblán. Ennek következtében egy terheltebb oldalnál nagyon gyorsan betelt az SQL szerverek maximális kapcsolatainak száma és utána már senki nem tudott kapcsolódni. Néhány kirívó esetben a szerveren elfogyott a memória, és betelt a swap is, így újra kellett indítani a gépet. Hogy ennek elejét vegyük, korlátoztuk az egy felhasználó által maximálisan nyitható kapcsolatok számát 100-ra. Ezzel a probléma gyakorlatilag megszűnt.

Frontendek

A webkiszolgálást Apache szerverek végezték modulos PHP-val forgatva. Ezek NFS-en keresztül látták a felhasználók webtárhelyeit. Eleinte még kezdőbetű szerint voltak csoportosítva, azonban egy általunk végzett fejlesztés következtében tudtuk véletlenszerűsíteni a helykiosztást. A biztonságért és a szolgáltatás panel beszúrásáért két Apache modul volt felelős, amit később részben átírtunk.

Load balance megoldások

A beérkező forgalmat eleinte egy több oldalt is kiszolgáló Cisco CSM irányította 4 proxy-szerverre bérelt szolgáltatás keretében. A proxy-szerverek akkor váltak szükségtelenné, amikor a frontendeket átalakítottuk olyanra, hogy saját maguk is el tudják dönteni egy oldalról, hogy blokkolva lett-e.

Egyik syn flood támadás alkalmával egy másik, a CSM-en lakó oldal is elérhetetlenné vált, ezért röviddel ezután építettünk két LVS szervert, ezzel függetlenítve magunkat a CSM-től.

Mit tanultunk ebből?

Amikor a DotRoll tárhelyet építettük, eleve szempont volt az, hogy ne használjunk hálózati fájlrendszert. Ugyan ritkán fordult elő, de az NFS képes volt az egész, redundánsan megépített rendszert elrántani magával. Éppen ezért az Extránál épített SQL hostokhoz hasonlóan egyéni kiszolgálókra koncentráltunk.

A másik igen fontos szempont az volt, hogy felépítéséből adódóan sosem működött megfelelően a kvótázás, és a PHP-ban rendszeresen megjelenő open_basedir bypass miatt folyamatosan frissíteni kellett, hogy ne nyíljon lehetősége bárkinek a másik könyvtárába belenézni. A DotRoll tárhely szolgáltatás kiépítésénél sokat kísérleteztünk azon, hogy lehetne a virtuális felhasználókat valódi felhasználókká tenni. Írtunk többek között egy komplett dinamikus konfigurációs modult az MPM ITK-hoz, de végül úgy döntöttünk, hogy valamilyen FastCGI variánst fogunk használni. Ez megoldja a szeparációs és kvótaproblémákat is.

A FastCGI-jal egyébként egy érdekes lehetőség nyílt meg előttünk, ami elsőre kissé meredeknek tűnt, ám a gyakorlati teszt során fényesen szerepelt, és ezért megmaradt. Minden felhasználónak szimuláltunk egy majdnem teljes Linuxot, amibe chroot-tal bezártuk. Ez nem csak a belépésére igaz, hanem a PHP futtatására is. Innentől kezdve igazából nem kellett félni az open_basedir bypasstől, mert minden felhasználó csak a saját környezetét látja – mindezt virtualizáció nélkül. Innen már csak egy lépés volt az SSH hozzáférés biztosítása, majd később a jelenleg tesztelés alatt levő felhasználónkénti Memcached.