Szabad Szoftver Konferencia

Ma volt a Free Software Foundation Hungary Alapítvány által szervezett Szabad Szoftver Konferencia és Kiállítás 2009. Úgy látszik, mostanában főleg konferenciabeszámolókat írok, de nagy a termés, érdemes ellátogatni ezekre, nyomon követni a trendeket. A mostani konferenciáról is a meglátogatott előadásokról fogok írni, címszavakban az érdekességekről. A konferencia oldaláról letölthető egy közel kétszáz oldalas kiadvány is.

Dr. Szentiványi Gábor A felhőkön túl című előadásából kiderült, hogy az előadó kicsit szkeptikus a felhők jelenlegi felhasználását illetően. A semmibe vezető hídhoz hasonlította a jelenlegi állapotot. Számolni kell a vendor lock-innel, a kisebb versenyzők a "nagyokat" (Amazon, Google) követve próbálnak felemelkedni, nincs kiforrott, all-in-one üzleti modell. Érdemes figyelni, merre tartanak, de merészség teljes lendülettel beszállni.

Trencséni Márton: Skálázható elosztott rendszerek

A kulcs-érték alapú adatbázisokról, MapReduce-ról, CouchDB-ről már írtam egy előző posztban.
Keyspace
Az előadó cége (Scalien) által BSD alatt fejlesztett kulcs-érték adatbázis. A NoSQL irányvonal megtestesítője, mely azon adatbázisok gyűjtő neve, melyek használatához nem szükséges SQL. C/C++-ban íródott, BerkleyDB-n alapul, de a következő verzióban ezt szeretnék kiváltani. Alapvetően konzisztenciát tart, de minden műveletnek van egy un. dirty párja, mely könnyen párhuzamosítható, de sérülhet a konzisztencia. Szóba került még a Paxos és a Vector Clock algoritmusok is.
Shared nothing architektúra
Az SN egy olyan elosztott architektúra, ahol nincs verseny egy közös erőforrásért, mint pl. egy központi adatbázis. Most a webes fejlesztéseknél, valamint a felhők világában különösen fontos, hiszen nagyon jól skálázható, újabb alacsony költségű gépek beállításával növelhető a teljesítmény, és nincs szűk keresztmetszet, illetve olyan meghibásodási pont, mely a teljes rendszert megbénítaná (single point of failure). Ezt a Google is bebizonyította, az ilyen típusú adattárolást shardingnak hívja, aminek lényege, hogy az adatokat valamilyen osztályozás szerint külön tárolja (horizontális partícionálás), ezáltal egyszerre kisebb adatmennyiségen kell dolgozni.
Eventual consistency
Olyan konzisztencia modell (elosztott rendszerek esetén használatos, van-e ellentmondás a tárolt adatok között), melynek használatával lehetséges, hogyha egy adatot módosítunk, majd visszaolvasunk, nem a módosított értéket kapjuk. Ez úgy lehetséges, hogy a konzisztenciát feláldozzuk a teljesítmény oltárán, azaz nem blokkoljuk a módosítást addig, míg az szét nem terjed a replikátumokon. Pl. egy közösségi oldal képfeltöltésénél elfogadható, de banki rendszernél ne használjuk. Hátránya, hogy amikor inkonzisztencia lép fel, nem kezelhető automatikusan, hanem az alkalmazást kell rá felkészíteni, ami vagy feloldja, vagy a felhasználóra bízza a konfliktus feloldását.
Distributed lock manager
A megosztott erőforráshoz való hozzáféréseket vezérli.
Memcached
Nagy teljesítményű, elosztott, memóriában helyet foglaló cache rendszer, mely nagyszerűen tehermentesítheti az adatbázist. Legnagyobb felhasználója pl. a Facebook, ahol a tartalom 95%-a cache-ből jön.
Redis
A Memcachedhez hasonló, memóriában tartott kulcs-érték adatbázis, azzal a különbséggel, hogy az adatokat bizonyos időközönként képes aszinkron módon lemezre menteni, valamint szövegen kívül halmazokat és listákat is kezel, valamint képes replikációra.
MemcacheDB
Bár nevében hasonlít a Memcachedre, és másra asszociálnánk, nem egy cache, hanem egy BerkleyDB-t használó perzisztens megoldás, mely API szinten nagyon hasonlít a Memcachedre, és C-ben lett megírva.
Google stack
Google File System (GFS), Chubby distributed lock manager, BigTable adatbázis kezelő és a MapReduce.
Hypertable
Nyílt forráskódú adatbázis a BigTable hasonlatosságára, C++-ban.
Dynamo
Az Amazon kulcs-érték adatbázisa.
Dynomite
Dynamo klón, nyílt forráskóddal, Erlangban megvalósítva.
Apache Hadoop
A Yahoo! által használt nyílt forráskódú, Javaban fejlesztett szoftverek gyűjtőprojektje a megbízható, skálázható, elosztott rendszerek fejlesztéséhez. Része a HBase, mely egy nyílt forrású BigTable klón.
PNUTS
A Yahoo! által használt elosztott adatbázis, mely nem nyílt.
Cassandra
Facebook mögött lévő adatbázis, Javaban.
Project Voldemort
LinkedIn mögött lévő kulcs-érték adatbázis, Javaban.
MongoDB
Nyílt forráskódú, dokumentum-orientált adatbázis, C++-ban.
Tokyo Cabinet
Egy újabb kulcs-érték adatbázis, C-ben.
Neo4j
Beágyazható, lemezre perzisztáló, tranzakcionált gráf alapú adatbázis.
Eucalyptus
Amazon API kompatibilitást ígérő nyílt forráskódú megoldás.
Hail
Célja nyelv- és platformfüggetlen, felhő építését lehetővé tévő, nyílt forráskódú infrastruktúra szolgáltatások kifejlesztése.
Deltacloud
Egységes REST API a különböző felhők (cloud) kezelésére, megszabadulva ezzel a vendor lock-intől. Jelenleg támogatott felhők: EC2, RHEV-M, RackSpace; VMWare ESX.

Elég sok szó esett a kulcs-érték alapú adatbázisokról, itt található egy rövid összehasonlítás. Személyes véleményem, hogy még nagyon nagy kavar van, nem árt kicsit várni, míg kitisztul a kép.

Szántó Iván: A KVM helye a virtualizáció világában

Egy korábbi posztban, és a Tumblr-en is írtam már a virtualizációról, és ez az előadás is erről szólt. Szó esett a CPU virtualizációról, ahol érdemes ismerni az x86-os architektúrában alkalmazott gyűrűk (ring) fogalmát. A gyűrűk bevezetése a biztonságot nyújtják. 0. gyűrű a kernelé, és korlátlanul hozzáférhet a CPU-hoz, memóriához és egyéb erőforrásokhoz, az 1. és 2. a meghajtó programoké, és a 3. az alkalmazásoké. A supervisor mód jelzi egy taskról, hogy hozzáférhet a védett erőforrásokhoz. A hypervisor a CPU-k hardveres virtualizáció támogatásával jelent meg. Segítségével a vendég operációs rendszerek 0. gyűrűben végrehajtható utasításokat futtathatnak. A CPU virtualizáció három formája a full virtualizáció, a paravirtualizáció, valamint a virtualizáció hardveres támogatással. Az első esetben a virtualizált operációs rendszer hívásait egy szoftver fordítja át. Ekkor az operációs rendszert nem kell módosítani. Paravirtualizáció esetén az operációs rendszert megváltoztatják, így ez a megoldás csak nyílt forráskódú operációs rendszereknél jöhet szóba, viszont kétségkívül gyorsabb, mint a szoftveres megoldás. A harmadik eset az előző kettő előnyeit ötvözi. A virtualizáció lehet host/guest alapú, amikor is egy operációs rendszeren felhasználói programként fut a virtualizációs megoldás, és abban a virtuális operációs rendszer, valamint lehet hypervisor/os alapú, mikor alul nem egy operációs rendszer, hanem egy hypervisor üzemel. Ebben az esetben azonban ki kell jelölni egy elsődleges operációs rendszert, mely direkt hozzáférést kap az erőforrásokhoz.

A memóriavirtualizáció során a virtuális operációs rendszer lapjait le kell képezni a virtuális gép lapjaira (page tables), és azt tovább le kell képezni a fizikai memória lapjaira (shadow tables). Az IO eszközök virtualizációja történhet full virtualizációval, paravirtualizált operációs rendszerrel, paravirtualizált driverrel, vagy pass-through driverrel (direkt hozzáférés).

A KVM, melynek neve is mutatja, kernelen alapuló virtualizáció, fő ötlete, hogyha a Linux kernelben úgyis meg van valósítva az ütemezés, erőforrás kezelést, stb., akkor azt továbbra is oldja meg a kernel, és csak a többi problémával foglalkozzon a virtualizáltságot biztosító szoftver. A QEMU-n alapul, mely egy nyílt forráskódú processzor emulátor. Elhangzott egy olyan trükk is, hogy azonos operációs rendszerek futtatásakor sok azonos memóriaterület lehet, ezt nem tárolja többször, hanem összeolvasztja (Kernel Sam Page Merging), és amennyiben az egyik virtuális gép mégis módosítani akarja, különválasztja (COW - copy on write). Említésre került a SPICE (Simple Protocol for Independent Computing Environments) is, mely egy virtualizációra optimalizált távoli adatátvitelt biztosító protokoll, melynek tulajdonságai az akár 30 fps-es video és Flash átvitel, kétirányú audio és video átvitel, valamint egy trükk, mely megvizsgálja a távoli és lokális gép videokártyáját, és a gyorsabbon renderel. A KVM kezelhető grafikus eszközzel (virt-manager) és parancssori eszközzel (virsh) is. A libguestfs is jó ötlet, a virtuális gép diskje a virtuális gép elindítása nélkül írható/olvasható. Menedzsment eszköz a Redhat RHEV-M is.

Mátó Péter: Adatbiztonság és üzembiztonság mindenkinek? Egy frappáns válasz: uDS

A uDS projekt lényege röviden összefoglalható: a belső winchester és egy USB pendrive RAID-1-be kötése, titkosítással. Mire is jó ez? Ha azt akarjuk, hogy ne kelljen manuálisan menteni az adatainkat, ezzel megoldható, hogy pl. a home könyvtárunk módosítása automatikusan, titkosítottan a pendrive-ra is átkerüljön. Ezzel meg van oldva a backup, és másik gépre átvíve azonnal szinkronizációs megoldás is. Az előadás a felmerült problémákról, és megoldásukról szólt, mint pl. a pendrive lassú sebessége (aszinkron írással kiküszöbölhető), valamint a pendrive különösen érzékeny a sok írásra (terítési algoritmus).

Höltzl Péter: Központosított napló gyűjtés, classifikáció és előfeldolgozás syslog-ng OSE és más szabad eszközökkel

Ez az előadás a syslog-ng-ről szól. Pont úgy működik, ahogy azt az ember egy naplózó rendszertől elvárja. Vannak források (source), amin bejön a napló (fájl, legacy syslog UDP - borzasztó formátum, kerüljük, TLS (Transport Layer Security) - SSL elődje, titkosított, stb.), valamint vannak célok, ahova kiírja azokat (destination). Definiálhatók filterek, melyek szűrik a napló bejegyzéseket. Mindkettő nevesített, és a log path köti össze őket. Probléma ugye a különböző formátumok kezelése. Erre template-eket lehet definiálni, melyek a naplót formázzák kiíráskor, valamint parser-eket, amik a bejövő naplókat elemzik. Ekkor un. makrók jönnek létre, melyeket használni lehet. Ezt elérési útban is meg lehet adni, így megoldható vele az archiválás is (havonta másik könyvtárba tesszük). Erre jól jöhet a logrotate is, ami már nem nevezgeti át az állományokat. Érdemes figyelni, hogy a napló állományba a szerver időpecsétje kerüljön, nehogy a kliens óra eltérése miatt ne lehessen az naplókat összefésülni. A napló bejegyzéseket át is lehet írni (rewrite). Támogatja a napló bejegyzések klasszifikációját is minta adatbázis alapján, valamint szó esett az artificial ignorance-ról, ahol nem a rossz dolgok vannak mintaként az adatbázisban, amire a rendszer riaszt, hanem a normális eseményeknek és minden attól eltérő kivizsgálásra kerül. A klasszifikáció nem regexp alapján történik, mivel az lassú, és on-the-fly történik, és nem batch jelleggel. Konkurrencia: Logcheck, Rsyslog. Lásd még RFC 5424 (The Syslog Protocol), RFC 3164 (The BSD syslog Protocol).

Czakó Krisztián: Virtualizáció & HA cluster: szeparált, egyszerű és biztos működik

Az előadás első része a XEN-ről szólt, mely egy hypervisor alapú virtualizáció, mely a hardveres támogatást is ki tudja használni. Képes a live migrációra, mikor menet közben, egy kis döccenővel tudunk átállni az egyik gépen futó virtuális gépről a másikra. (Úgy működik, hogy egyre kisebb differenciákat visz át, és a legutolsónál van a pillanatnyi leállás.) Le lehet állítani, majd újraindítani a hypervisort úgy, hogy a virtuális gépeket nem kell leállítani, gyakorlatilag a leállásból azok semmit nem vesznek észre (suspend/resume). Hasznos eszköz lehet az OpenQRM GPL alatt, mellyel több virtualizációs megoldást is lehet menedzselni. High availability a tervezett és nem tervezett rendszer leállások minimalizálása, a fault tolerance esetén a rendszer hiba esetén is működik tovább, anélkül, hogy ezt a felhasználó észrevenné. A Linux-HA projekt alakult a Linux alatti HA megvalósítások implementálására, melynek fő terméke a Heartbeat. Jelenleg azonban a honlapja átirányít a Pacemaker honlapjára, mely egy cluster infrastruktúra, mely képes OpenAIS és Heartbeat felett is működni. A cluster működhet SAN felett (AOE, iSCSI, FiberChannel), páratlan számú node-dal, hiszen itt a lényeg a többségi cluster, és DRBD felett, mely tulajdonképpen egy szoftveres RAID 1 megoldás TCP/IP felett, de csak két node-ot támogat. Az előadás konklúziója, hogy a XEN Heartbeat támogatása igen erős, kész scriptek vannak, így aki pl. egy Apache HA-t már kialakított Heartbeattel, annak nem lesz különösebben bonyolult ugyanezt virtuális gépekkel megoldania.

Ígérem, a következő poszt teljesen Javas lesz.