Néha felmerült, hogy milyen jó lenne tudni egy-egy webszervernél, hogy péládul egy PHP oldal kiszolgálása során mennyi időt emészt fel a szkriptek feldolgozása és mennyit a webszerver futása. Erre a problémára lehet többek közt megoldás a New Relic szolgáltatása, mely egész tetszetős és részletes grafikonokkal, táblázatokkal segíti az informálódást.
Pár héttel ezelőtt írtam a MySQL replikációról, majd most úgy tűnik egy PowerDNS alapokon nyugvó DNS kiszolgálóhoz szükség is van rá némi kiegészítéssel.
Ami miatt úgy tűnik használni kell, az a PowerDNS supermaster/superslave funkciójának egy hiányossága.
Időről időre előkerülő téma a MySQL replikáció kérdése, hogy milyen jó is lehet az ha tudunk olyat csinálni. Jól jöhet például egy PowerDNS szervernél, ha nem az AXFR protokollt felhasználva akarunk master-slave architektúrát kialakítani, de hasznos lehet még akkor is, ha magas rendelkezésreállást, live biztonsági mentést (itt a mentés talán kicsit sántíthat is bizonyos értelemben), vagy épp csak a fejlesztéshez folyamatosan éles adatokat szeretnénk használni többlet munka (kézi szinkronizálás) és az éles adatbázis veszélyeztetése nélkül. Ezen gondolatok eredményeképp született az alábbi kis leírás (Ubuntu linuxra), hogy hogyan is kell egy oda-vissza master-slave architectúrát kialakítani, amelynek segítségével a két adatbázis kiszolgáló valamelyikén végzett módosítás azonnal megtörténik a másikon is.
Ahogy azt már két előző bejegyzésben is említettem elkezdtem VPS szolgáltatásokat tesztelni. Az egyik ilyen az Alvotech VPS a másik pedig a HP Cloud volt, most pedig következzen az Amazon Elastic Cloud Compuite (EC2) szolgáltatása.
Fontosnak tartom megjegyezni, hogy egyáltalán nem célom teljes részletességében bemutatni a szolgáltatást, helyette inkább egy "első blikkre" jellegű képet próbálok vázolni, ami valamelyest megkönnyítheti a kezdeti ismerkedést és az esetleges vásárlási döntés meghozatalát.
Ahogy már egy előbbi bejegyzésben is írtam elkezdtem VPS szolgáltatásokat tesztelni. A most következőkben is erről lesz szó, azonban itt már nem vServer alapú izolációs megoldást, hanem egy manapság egyre divatosabbnak számító felhőt (Cloud Computing) vizsgáltam. Egész konkrétan a HP Private Beta Cloud szolgáltatását.
A szolgáltatáshoz hozzáférést egyéni elbírálásos alapon lehetett szerezni, ahol többek közt azt is meg kellett adni, hogy mire szeretném használni a szolgáltatást. Az igénylésemet késő délután adtam le, majd másnap délelőtt már az elfogadásról szóló e-mail várt a postafiókomban. Sajnos egy kollégám már nem volt ennyire szerencsés, őt csak több hét és egy telefonos elbeszélgetés után hagyták jóvá.
Az utóbbi időben többször és több dolog kapcsán is felmerül, hogy ideje lenne beszerezni egy komolyabb sávszélességgel rendelkező szervert, vagy egy túlnyomórészt hasonló képességekkel bíró, de olcsóbb virtuális szervert (VPS). Ennek kapcsán kezdtünk vizsgálódni mik érhetőek el jelenleg a piacon. Így jutottam el az Alvotech nevű német céghez is, aminek volt szerencsém tesztelni az Amszterdami szerverükön futtatott VPS szolgáltatását, egész pontosan egy vServer L csomagot.
Az utóbbi időben egyre növekvő játékos számnak köszönhetően egyre
Már egy ideje foglalkoztat a gondolat, hogy a home.halacs.hu szerveremen lévő email szolgáltatáshoz érdmes lenne beállítani egy tartalék levelező szervert, ami az elsődleges gép elérhetetlensége esetén is tudná fogadni és átmenetileg tárolni a leveleket.
Figyelembe véve a kiszolgáló minimális e-mail forgalmát (szűk baráti kör), a dolog gyakorlati jelentőssége nem túl nagy (különösen az smtp-k "próbálkozós" működését ismerve), mégis a megvalósítás mellett döntöttem. Talán elsősorban kíváncsiságból.