Inclust Infrastructure, Community & Expert

Inclust Blog

Újdonságok, fejlesztések, akciók, tech hírek

Bejegyzéseink

levente.eros blogja

A DNS rejtelmei, avagy miért láthatok én mást, mint a többiek?

2012. 06. 09. - 16:27

Tegyük fel, hogy éppen karácsony van és webáruházad látogatottsági rekordokat döntöget, vagy a most élesített blogbejegyzésedet több tízezren szeretnék elolvasni egyszerre. A technika pedig valamiért csődöt mondott és a szolgáltatás nem elérhető. Elég kellemetlen helyzet és nem is mindig biztos, hogy azonnal orvosolható.

Manapság ahhoz vagyunk szokva, hogy a legtöbb dolog azonnal elintézhető. Hirtelen támadt gondolatainkat azonnal érvényre tudjuk juttatni, és ha megváltoztatunk bizonyos dolgokat, azok általában azonnal életbe is lépnek. A DNS működése sajnos nem egészen ilyen és elsőre nehéz lehet megérteni, hogy miért nem. Az alábbiakban segítünk elmagyarázni, hogy mi ennek az oka.

Mi az a DNS?

A DNS (Domain Name System) az emberek által könnyen megjegyezhető domainneveket IP címekké lefordító rendszer. Minden kiszolgáló az Interneten önálló IP címmel rendelkezik.

Például: 87.229.101.201. Az itt található oldalt megnyitva bárki meggyőződhet róla, hogy az adott cím alatt élő szolgáltatás üzemel. Viszont elég furcsán nézne ki, ha az óriásplakátokra ilyen számsorozatokat írnánk, és hazaérve mindenki ezeket próbálná visszaidézni az emlékezetéből, hogy megnyissa az adott cím alatti oldalt. Nem beszélve arról, hogy messze több domainnév létezik a világon, mint ahány IP cím. Erre találták ki megoldásként a domain neveket (pl. inclust.com), amiket a DNS segítségével fordíthatunk le IP címekké. Ez egy elosztott rendszer, aminek tartalma ráadásul minden másodpercben változik, így a világon soha nem létezik egyetlen olyan számítógép sem, ami ismerné a létező összes domain név - IP cím párosítást. A feladatot (név)szerverek milliói, hierarchiába szervezve, együttesen látják el. Egymás között információt cserélnek szükség esetén kérésre vagy meghatározott időközönként automatikusan is.

A helyi névszerver

Minden, az Internetre csatlakoztatott számítógépen be van állítva egy vagy általában több névszerver címe, amelyeket az megkérdezhet, ha egy adott domainhez tartozó kiszolgáló IP címét szeretné megtudni. Ezeknek általában mindenki az internet-szolgáltatója által üzemeltetett névszervereket adja meg, de létezik rá több, publikus megoldás is, ilyen például a Google DNS rendszere.

Ha pl. a böngészőnkkel csatlakozni szeretnénk egy ismeretlen domainnév alatt kiszolgált weboldalra, ahhoz először annak meg kell tudnia a szerver IP címét. Első lépésben az operációs rendszerünk megkérdezi az abban beállított szolgáltatói DNS szerverek valamelyikét. Ha a szolgáltatónk névszervere még nem ismeri az általunk megkérdezett domainhez tartozó címet, nekilát rekurzívan kideríteni azt, hogy aztán továbbadhassa az információt nekünk. Megkérdezi az adott domainről a benne beállított root(gyökér)-névszerverek valamelyikét. Ha az sem ismeri az adott domain nevet (nem fogja, mert nem ez a dolga), akkor is meg tudja mondani, hogy ki a .com domainek kiszolgálója. Ezután, a kapott információ alapján az eredetileg kérdezett névszerver megkérdezi a .com domainek névszerverét a megadott domaint illetően. Ha ő sem ismerné azt, akkor is meg tudja mondani, hogy őbenne melyik kiszolgáló van beállítva felelősnek az adott domaint illetően. Ez a megadott domain autoritatív kiszolgálója. Könnyen látható, hogy a lekérdezések rekurzív folyamata egy információ-átviteli láncot eredményez.

Lehet, hogy már végbement a kérdezz-felelek folyamat és valahol el lett tárolva az akkor kapott választ.

Olyan ez, mint amikor leírtuk valakinek a telefonszámát a noteszünkbe, mielőtt a mobiltelefonok elterjedtek volna. Ekkor, ha tőlünk megkérdezik az adott illető telefonszámát, akkor nem járunk utána újból, ha nem megmondjuk azt a számot, amit mi már ismerünk.

A felelős névszerver

A szolgáltatónk által üzemeltetett névszervereken kívül léteznek speciális névszerverek is, amelyeket autoritatív névszervereknek nevezünk. Ezekből minden domainhez létezik legalább egy darab, de általában több is. Az ide letárolt beállítások adják meg, hogy az adott domain milyen IP címre mutat. Például az inclust.com esetében ez az ns01.inclust.com és az ns02.inclust.com névre hallgat. Ha az inclust.com IP címe valami miatt megváltozna, akkor ezekben a szerverekben kell frissíteni a hozzá tartozó bejegyzéseket. Az átállás esetén azonban időre van szükség ahhoz, hogy az új információ mindenhol elterjedhessen és kérdés esetén a világon mindenki ugyanazt a választ kapja vissza, hiszen a végfelhasználók és a felelős névszerverek között szerepelhetnek olyan kiszolgálók, amikben a korábban letárolt információ még a régi beállítást tartalmazza és emiatt elavult lehet.

 

A kisvárosi szabó telefonszáma az adott város havonta megjelenő, helyi reklámújságjában szerepel. Ha egyszer megszereztem az adott lapot, tudom a szabóság aktuális telefonszámát. De ha másnap valamiért lecserélik azt, akkor addig nem fogom tudni az új számot, amíg nem jutok hozzá a helyi újság friss változatához, amiben már a megváltozott elérhetőség szerepel. Addig amíg csak a régi lappal rendelkezem, rossz számon fogom keresni őket.

 

Mikor lehet még probléma?

Nem ritka eset, hogy egy kiszolgáló IP címe változik. Akár a rajta futó szolgáltatást költöztették át máshova, akár maga a szerver kapott új címet, az oda mutató DNS rekordokat frissíteni kell. A fent leírtak alapján látható, hogy az új beállítások nem mindig lépnek életbe azonnal, sőt, néha akár 24 óra is eltelhet. Ez az idő az adott rekordhoz tartozó TTL (Time to Live) érték beállításától függ. Ez az érték szabályozza, hogy az adott beállítást mennyi időre jegyezheti meg és tekintheti érvényesnek az a kiszolgáló, amelyik az adott információt megszerezte.

A noteszkönyves hasonlatot folytatva: akkor járunk el praktikusan, ha minden noteszkönyv bejegyzéshez beírjuk az adott időpontot, amikor megtudtuk az illető telefonszámát. Ha mostanában tudtuk meg, akkor nagy eséllyel az a jó szám és megmondjak annak, aki kérdezte. De ha már túl régi a bejegyzés dátuma, akkor nem tekintjük érvényesnek, ha nem újból utánajárunk, hogy biztosan jó választ adjunk.

A legnagyobb baj akkor történhet, amikor egy nagy látogatottságú weboldal kiszolgálása áll le a DNS rekordok hirtelen megváltozása miatt. Ilyen eset például regisztrátorváltáskor fordulhat elő. Ha az éppen üzemelő weboldal domainjéhez beállított névszerverek hirtelen megváltoznak és az újakban nem szerepelnek a helyes beállítások, a domainhez tartozó IP címet már az új névszerverektől lekérdező felhasználók nem kapnak választ és így nem képesek eljutni az adott domain alatti tartalmakat kiszolgáló szerverig.

A bejegyzés a Smashing Magazine ötletadó cikke nyomán született.

Ajánlott irodalom: Részletes magyar nyelvű leírás a DNS működéséről

Drupal teljesítménytuning

2012. 04. 06. - 09:59

A Drupal üzemeltetése magában sem könnyű feladat. Fokozottan erőforráspazarló rendszer, alapjáraton is sok memóriát eszik, a rengeteg lekérdezést pedig a rengeteg optimalizálás ellenére is megérzi a rendszer. A különböző forrásokból származó (akár beta verziós) plusz modulok feltelepítésével pedig tovább romlik a helyzet. Több különböző weboldal közös tárhelyen történő üzemeltetésekor pedig egyszerre akár 100 weboldal is egy egybefüggő szerverparkon kerül kiszolgálásra. Ezek között - népszerűsége miatt - a Drupal bizony szép számban előfordulhat.

 

Webadmin névre keresztelt, saját fejlesztésű adminisztrációs felületünk, pénzügyi rendszerünk, valamint hivatalos weboldalunk is Drupal alapokon nyugszik. Ezeknek és a különböző ügyfelek által üzemeltetett hasonló oldalaknak hála az elmúlt évek során egyre több tapasztalatot gyűjtöttünk ezek üzemeltetésében is. Az alábbiakban röviden összefoglaljuk a sebességnövelés főbb lehetőségeit. Ezek a technikák éppúgy hasznosak lehetnek kisebb méretű weboldalak esetén, mint összetett adatbázissal rendelkező multi-site rendszereknél. A motor többrétegűsége és az azt kiszolgáló rendszerek sokfélesége miatt azonban az optimalizálás szerteágazó feladat lehet. Ha valakinek ez a célja, az egyes témák mindegyikében egyenként el lehet merülni és igény esetén egy-egy területen komolyabb finomhangolási módszereket bevetni.

 

Biztos, ami biztos

Legyen kikapcsolva az összes olyan modul, ami az oldal működéséhez nem szükséges feltétlenül. Ebbe beletartoznak a fejlesztést segítő kiegészítők is, mint a Toolbar és az Update manager. A Beállítások->Teljesítmény menüpont alatt mindenképp érdemes bekapcsolni a cachelést anonymous felhasználók részére engedélyező funkciót. Ugyanitt állítható be a gyorstárak minimum is maximum élettartama is. Ennek beállításakor azt érdemes figyelembe venni, hogy milyen gyakran frissül az oldalak tartalma. Ellenőrizd, hogy a képek nem túl nagy méretűek, a beépülő Javascript modulokból (jQuery és társai) pedig mindenhol a minimalizált verziót használod, hogy ezzel is kíméld az adatforgalomtól a szervert és a klienseket egyaránt.

A Cachelés a barátod

A teljesítményt fokozó kiegészítők közül érdemes feltenni az Alternative PHP Cache, a Boost és az Aggregate cache modulokat. Ezek használatával legalább 1 nagyságrendnyi gyorsulást értünk el az oldalaknál: A valós időben generált dinamikus tartalmaink kb. 5-10x, a többnyire statikus tartalommal rendelkező oldalaink 15-20x gyorsabb idő alatt töltődnek be. Ezt főleg a Boost modul használatának köszönhetjük. Az "aggregate cache" funkció főleg akkor segít, ha a böngészőnek sok kliensoldali tartalom letöltésével kell megküzdenie. Ilyenkor a CSS és JS fileok összetömörítve, egy-egy pakkban utaznak a böngészőig és így kevesebb sávszélességet foglalnak.

 

Ami a háttérben van

Nem mindegy, hogy milyen teljesítményű az oldal mögött az a rendszer, ahonnan az adatok valójában nyerjük. Felülről lefele ásva először érdemes utánamenni, nincsenek-e lassú, egyedi SQL lekérdezések a kódban, amik akadályozzák az oldalak gyors betöltődését. Ehhez a legelterjedtebb (mára ipari standarddá vált) MySQL adatbáziskezelő esetében a mysql_slow_query.log és az EXPLAIN utasítás adhat a legkönnyebben segítséget. Érdemes megfontolni, hogy MyISAM vagy InnoDB motort használjuk-e az adatok tárolására. Mindegyiknek vannak előnyei és hátrányai egyaránt. Aki pedig valamilyen másmilyen (Postgres, vagy valamilyen NoSQL) adatbáziskezelőt használ, remélhetőleg tudja, miért teszi azt. Legvégül, a háttértár teljesítménye is döntő tényező lehet. Alapvetés, hogy a kiszolgált oldalt tároló filerendszer, a működéséhez szükséges adatbázis és a futás során készülő log fileok mind-mind külön helyen legyenek tárolva. Ha ezeket a területeket egy időben egy helyről írja és olvassa a rendszer, az elég nagy overheader generálhat. Válasszuk ezeket külön, ha még nem tettük. Lényeges adatok tárolására valamilyen RAID megoldás használata manapság már magától értetődő. A legjobban skálázható megoldás azonban valamilyen elosztott rendszer használata. Erről a témáról és felhőszolgáltatásunkról a jövőben is rendszeresen jelentetünk meg írásokat itt, a blogunkon. Reméljük használható segítséget tudtunk nyújtani. Örömmel vesszük bárki tapasztalatait a témában!

E-mail routing, avagy mi lesz az e-mail sorsa miután én elküldtem?

2012. 01. 24. - 14:57

Gyakran felmerülő kérdés az e-mailek továbbításának kezelése és ennek technikai megvalósítása. Amikor az MX típusú DNS rekord szóba kerül, sokan egyből felhúzzák a szemöldöküket, pedig alapvetően nem egy nagy ördöngösség ez, csupán a DNS alapjaival kell tisztában lenni hozzá.

Kliens oldalról nézve a levelek fogadására és küldésére egymástól különböző protokollok szolgálnak az interneten. A bejövő levelek fogadása többnyire a POP3 és az IMAP protokollok igénybevételével történik, a küldésre viszont egy másik, az SMTP (Simple Mail Transfer Protocol) van használatban. A két protokollcsalád teljesen függetlenül működik egymástól.

Az MX rekord

A DNS rekordok közül az MX típusú(ak) felel(nek) a levelek továbbításának irányításáért. Tegyük fel, hogy a felhasználó@domain.hu levelet szeretne küldeni a support@inclust.com címre. A felhasználó optimális esetben a saját internetszolgáltatója SMTP szerverén keresztül küldi el a levelet. A SPAM-ek kiszűrése miatt a szolgáltatók a hálózatukon kívüli forrásból általában nem szokták engedélyni a levélküldést a saját SMTP szervereiken keresztül. A szolgáltató szervere DNS lekérdezés után eljut az inclust.com DNS kiszolgálójáig, ahol megérdeklődi, milyen címre mutat az MX rekord. Válaszul megkapja az inclust.com domainhez zónájában beállított MX paramétert: mx01.inclust.com és mx02.inclust.com. Mostmár tudja, milyen címre kell kapcsolódnia, hogy kézbesíthesse a levelet, így felveszi a kapcsolatot az mx01.inclust.com alatti SMTP szerverre és jelzi, hogy e-mailt küldene a support@inclust.com címre. Ha a megadott felhasználó létezik az adott szerveren, akkor a levelet sikeresen kézbesíti.

Egy egyszerű parancssori eszköz az nslookup, aminek segítségével a DNS lekérdezést magunk is elvégezhetjük. Az inclust.com domain MX rekordjait például így kérdezhetjük le:

$ nslookup
> set type=mx
> inclust.com
inclust.com MX preference = 1, mail exchanger = mx01.inclust.com
inclust.com MX preference = 20, mail exchanger = mx02.inclust.com

A válaszból láthatjuk, hogy az inclust.com-hoz helyesen több MX rekord is be van állítva. A rekordok a zónában számokkal priorizálva (1 és 20) szerepelnek. Az alacsonyabb szám nagyobb prioritást jelent. Ha a legalacsonyabb prioritású szerver nem válaszol, akkor az SMTP a sorrendben eggyel magasabbal próbálkozik, hogy továbbíthassa a levelet, és így tovább. Ha ugyanakkora prioritású kiszolgálóból több akadna, akkor a kiszolgáló a terhelés elosztása miatt véletlen módon kerül kiválasztásra.

Végezetül egy hasznos link egy domain levelezésének kezeléséhez kapcsolódó technikai beállítások lekérdezésére: www.mxtoolbox.com

Szolgáltatás-migráció a gyakorlatban

2011. 10. 31. - 17:08

A napokban megkeresett minket egy új ügyfél azzal, hogy szeretnék áthozni a hoszting szolgáltatásaikat hozzánk, mert elégedetlenek a jelenlegi szolgáltatójukkal. Az átállás első körben érintette a weboldal, a hozzá tartozó adatbázisok és az e-mail fiókok mozgatását. Egyúttal át szerették volna mozgatni az összes bejegyzett domainjüket is regisztrátorváltással, hogy bármilyen, az oldalakkal kapcsolatos teendőt egy helyen, közös felületen intézhessenek el. A migráció folyamatáról készült ez a cikk, hogy segítségül szolgáljon a jövőben azoknak, akik hasonló lépésre szánták el magukat. A szolgáltatóváltás folyamatáról vázlatosán egyszer már írtunk korábban. Most kibontjuk és részletesebben is foglalkozunk a folyamat egyes lépéseivel.

Webadmin regisztráció

A szolgáltatások áthozatala előtt regisztrálni kell az Inclust Webadmin rendszerébe. Ezt a http://webadmin.inclust.com/order oldalon tehetjük meg. Itt válasszuk a domain regisztrációt, majd hogy új ügyfelek vagyunk. Ezt követően adjuk meg az áthozni kívánt domaint, majd a foglaltság ellenőrzés után eldönthetjük, hogy "Maradjon a domain a jelenlegi regisztrátornál, csak szolgáltatást rendelek meg" vagy "Átregisztrálás". Előbbi esetben a DNS kiszolgálást továbbra is a régi szolgáltató végzi csak a tárhely lesz fizikailag nálunk, és majd át kell irányítani az Inclust szervereire a DNS-t,  utóbbi esetben pedig a DNS és a tárhely menedzselése is a Webadminban fog történni. A folyamat befejezése és a szükséges dokumentumok feltöltése után hozzáférést kapunk a Webadmin rendszerhez. Bejelentkezés után látható a domain és a hozzá tartozó szolgáltatások.

A weboldal tartalmának mozgatása

A teljes weboldal áthelyezéséhez szükség van az összes fájl, valamint dinamikus tartalmak esetén a háttéradatbázis átmozgatására is. Ha van megfelelő hozzáférésünk a régi szolgáltatónál, célszerű egyetlen, tömörített állományt készíteni a teljes fájlrendszerről. Ilyenkor a teljes oldal egy elemként mozgatható és nem kell az összes fájlt egyenként le- és feltölteni FTP-n keresztül, ami sok bonyolult könyvtárstruktúra esetén elég hosszadalmas lehet. Átmozgatás után természetesen ki kell tömöríteni a fájlt, hogy visszanyerjük a tartalmak eredeti szerkezetét. A fájlok áthelyezése után problémák merülhetnek fel az eltérő elérési útvonal kapcsán: Az új környezetben szinte biztosan máshol helyezkedik el az a könyvtár, ahol adataink helyet foglalnak, emiatt a kódban szereplő abszolút hivatkozások (pl. /home/httpd/oldalam.hu/config.php) nem működnek. Ezekről általában részletes hibaüzenet tájékoztat, így javításuk viszonylag egyszerű. Relatív hivatkozásokat használva (pl. ./config.php) ez a típusú a hiba megszüntethető

Az adatbázis áthelyezése

Ebben az esetben a régi szolgáltató nem biztosított külső elérést az adatbázisok tartalmához, így ezt nekünk kellett megoldani. Egy phpMyAdmin felmásolása után az adatbázisba belépve kiexportáltuk az adatokat egy sqldump fájlba, majd az Inclust phpMyAdmin felületén az adatbázisok létrehozása után betöltöttem azokat. Fontos, hogy a korábbi kódban meg kell keresnünk az adatbázishoz való csatlakozást és át kell állítani az inclust szervereire (sqlserver.inclust.com) és a felhasználónév, jelszót is be kell állítani.

E-mail fiókok

A postafiókok létrehozásához fel kell venni a használni kívánt e-mailcímeket, melyek adatait (felhasználónév, teljes név) a régi szolgáltató rendszeréből nyerjük ki. A régi jelszavak megszerzésére a legtöbb esetben nincsen lehetőség, mivel a legtöbb rendszer kódolt formában tárolja ezeket, nem véletlenül: ha normál szövegként lennének lementve, az potenciális biztonsági hiányosság lenne, mivel bárki, aki hozzáfér az adatbázishoz, könnyen kiolvashatná a jelszavakat.

DNS rekordok átállítása

Az adatok áthelyezése után a DNS rekordok az új szolgáltató szerverére való átállítása következik. A DNS rendszer technológiájából kifolyólag a rekordok teljes frissülése akár egy napig is eltarthat. Ez függ az adott domainhez tartozó TTL (Time-To-Live) értéktől. Célszerű a rekordok átállítása előtt ezt lecsökkenteni, majd a folyamat lezárultával visszaállítani a magasabb értékre. Az átállási folyamat ideje alatt fennállhat olyan eset, amikor egy adott kliens még a régi szervert látja, de egy másik hálózaton lévő másik kliens pedig már az új szerveren lévő tartalmat, ugyanaz alatt a domain név alatt. Ilyenkor a régi oldalon lévő változtatások nem látszanak az új rendszeren, emiatt célszerű az átállítás ideje alatt a tartalmat változatlanul hagyni. A weboldalakat lekérő kliensek másik kiszolgálóra történő átirányításához a domainhez tartozó A rekordokat kell átállítani, jelen esetben az Inclust NameServer címére: 87.229.101.201. Ezt el kell végezni magához a domainhez tartozó bejegyzésen, illetve az összes hozzátartozó olyan subdomainen, amely valamilyen tartalmat szolgál ki. Például: www.qsp.hu vagy aldomain.qsp.hu.

A domain név áthozatala

A domain teljes áthozatalára, vagyis regisztrátorváltásra, akkor van szükség, ha minden szolgáltatásra az új szolgáltatónál szeretnénk előfizetni. Ez célszerű döntés, hiszen bármilyen fennakadás esetén az új szolgáltató egy személyben tud cselekedni és nem léphet fel kommunikációs probléma a 3 (2 szolgáltató + 1 megrendelő) fél között. A .hu domainek átregisztrálása az új domain igényléséhez hasonló folyamat. A regisztrátorváltáshoz szükség van egy megfelelően kitöltött és aláírt domain-igénylő lapra, valamint magánszemély esetén egy állampolgársági nyilatkozatra vagy cég esetén aláírási címpéldányra. Figyelni kell rá, hogy a regisztrátorváltás megkezdése előtt az új regisztrátornál lévő DNS bejegyzések már érvényben legyenek, különben a domain új regisztrátorhoz való átkerülése után, ha vannak hiányzó bejegyzések, a feloldás nem úgy fog működni, mint előzőleg és elérhetetlenné válhatnak bizonyos szolgáltatások.