Az AMQP-val kapcsolatban gyakran feltett kérdésekben a szemantikáját az e-mail működéséhez hasonlítják. Függvényhívást intézel az AMQP implementációhoz, és amikor visszatér, garantált, hogy az AMQP üzenet, mint egy e-mail üzenet, eljutott a címzetthez, akárki is legyen az. Az AMQP-t felhasználók szempontjából milyen teljesítményi méréseket akarnak majd a rendszeren megvalósítani, és milyen eredményeket várnak ezektől a mérésektől?
Mivel a teljesítmény nagyon fontos számunkra, már most beszélhetünk szabványokról az üzenetküldési API-k körül. Így tudjuk, hogy ezek az API-k hogyan illeszkednek az alkalmazásokhoz, de szerintünk a teljesítmény egy hatalmas ösztönző lesz. Ezért indítottuk a projektet. Így kitűztünk egy célt, a másodpercenkénti egymillió üzenetet. Akár elérjük ezt a termék megjelenéséig, akár nem, nagyon jól haladunk a méretezhetőségi szintekkel, melyek ötször nagyobbak, mint az iparág bármely más implementációja esetén.
Egy ilyen szorosan összekapcsolt szoftverkészlet esetén, ahol az üzenetküldési köztesréteg a rendszermag felett helyezkedik el, amit pedig megpróbálunk virtualizálni, a hypervisor illetve más virtualizációs technológiák közbeékelése hogyan befolyásolja az egész szoftverkészletre vonatkozó mérést?
Ezt szeretem a Red Hattel kapcsolatban. A sok teljesítménnyel kapcsolatos fejlesztés után a megoldás egy része grid (masszív parallel architektúra) lesz, és az üzenetküldési sorokkal kapcsolatos fejlesztés szintén az üzenetküldésen alapul majd. Most ezek virtualizált környezetekbe illesztésével foglalkozunk. Tehát folyamatban van egy projektünk, ami az AMQP-t használja annak érdekében, hogy a virtualizált környezetünk számára összehangolt rendszer jöjjön létre. Ez nagyjából egy létező virtualizált környezetet és a körülötte lévő eszközöket jelenti, melyek az eltérő rendszereken futó munkaterheléseket próbálják kezelni, és abból, ahogy az eseményeket kezeljük, illetve monitorozzuk.
Tehát valójában maga az AMQP rendszer használatát tervezzük az esemény-alapú szállításmenedzsment-rendszer szolgáltatásához az automatizálási platform számára. Tehát az érdeklődésünk az üzenetküldés iránt legalább annyira irányult arra, hogy egy vonzó üzenetküldési terméket hozzunk létre, mint arra, hogy a rendszermenedzsment következő generációja esetén is használjuk azt.
Tehát ez azt jelenti, hogy a Red Hat Enterprise Linux következő generációja magában foglalja majd az üzenetküldést, vagy továbbra is külön termék lesz?
Jelenleg egy hozzáadott előfizetésen gondolkodunk, ami szorosan integrálja a valósidejűséggel és az AMQP-vel kapcsolatos fejlesztési munkákat.
Egy másik terület, amiről a nagy informatikai ügyfelek kérdeznek, az energiahatékonyság. Amikor nagyon alacsony latencia követelményekkel rendelkező rendszerről beszélsz, a másik oldalon egy olyan nyomás is jelentkezik, hogy a rendszermagban bizonyos dolgokat hosszabb alvási periódusra kényszeríts. Hogyan oldod meg ezt a konfliktust és hogyan kezeled mondjuk a nagy pénzügyi ügyfelek problémáját, akik egy “zöld” adatközpontot akarnak, de emellett gyorsan akarnak reagálni a következő nagy tőzsdepiaci eseményre?
Az energiakezeléssel kapcsolatban a technológiának ebben a fázisában már vannak, ha nem is egymással szemben álló, de szilárd technológia-készletek, és célok, melyek egymást keresztezik. Az elején sokszor fejtörést okozott az energiakezeléssel kapcsolatos fejlesztés, ami a Linux rendszermag által nyújtott előnyöket élvezi, ugyanakkor hatékony és összeegyeztett időzítőkkel rendelkezik. Tehát szerintem ezen nehézségek nagyrészén már túljutottunk az AMD és az Intel segítségével, de gyakran volt rá példa, hogy le kellett állítani az energiakezelést, ha konzisztens időzítőket akartunk.
Tehát valamiféle energiakezeléssel kapcsolatos innovációként tekintek a jelenleg zajló fejlesztésre, ahol a chipkészlet-gyártók közvetlenül részt vesznek a Linux rendszermag natív támogatással kapcsolatos fejlesztéseiben, továbbá valamilyen szinten próbálják a virtualizációt is bevonni a kihasználtság megfelelő kezelése érdekében. Így elkezdhetjük a szerverek virtualizálását. Most már a legjobban illeszkedő algoritmusokat tudjuk létrehozni, tehát nem szükséges, hogy a rendszer nagy energia-igénnyel rendelkezzen. Tehát ahelyett, hogy a rendszert áramtalanítjuk a ciklusok között, és ahelyett, hogy tudnunk kellene mikor van csúcsigény a teljesítményre, végre tudjuk hajtani az algoritmusok tömörítését azért, hogy igény szerint a megfelelő rendszerre mozgassuk át a terheléseket úgy, hogy a teljesítmény valójában nem csökken, és emellett a gridben további rendszereket állíthatunk le, vonhatunk ki az áramellátás alól. Leginkább a virtualizáció nyújtja ezt, mivel lehetővé teszi, hogy az alkalmazást leválaszthassuk a hardverről.
A Red Hat egy új ajánlata egy olyan alkalmazási modell, ahol egy meglévő Red Hat Enterprise Linux jogosultságunkat virtuális gépen az Amazon EC2 “felhőben” használhatjuk. Milyen ügyfelek érdeklődnek ezen megoldás iránt? Illetve jelenleg még csak a Red Hat irányítja, és még nem vagytok biztosak benne, hogy milyen ügyfeleknek kell ez?
Ha a mi szemszögünkből nézzük, akkor mi az Amazon informatikai osztályával dolgozunk együtt napi szinten, így szoros a kapcsolatunk a vállalattal. Nagyon elkötelezettek a nyílt forráskód iránt. Szerintem valójában piacvezetők és Linux igény szerinti szolgáltatásokat nyújtanak az ügyfeleknek. Mi csak elérhetővé szeretnénk tenni a teljes támogatási rendszert és ISV modellt azon ügyfeleknek, akik ezt igénylik.
Az induló vállalatok általában webhosztolásra használják. A meglévő vállalatok, melyek kötegelt feldolgozással is foglalkoznak, ahol nem kritikus, hogy melyik időszeletben futnak le a folyamatok, ki tudják helyezni a feldolgozást. Amikor a számokat és a költségmutatókat nézzük, láthatjuk, hogy ez valóban egy olyan modell, amivel mindenki nyer: az Amazon, a Red Hat és az ügyfelek is.
Mire számíthatunk még a Red Hat ajánlatai kapcsán? Kövessük figyelemmel a Fedorát, vagy hol tudunk információkat megtudni?
Minden fejlesztés nyilvánosan zajlik. Szerintem ebben egyediek vagyunk, és a média illetve az ügyfeleink már jóval korábban fognak tudni a következő Red Hat technológiáról, még a termékesítés előtt. Így a Fedora 8, mely nemrég jelent meg, és az első négy napon 54000-en töltötték le, egy élénk fejlesztői közösség a technológia következő generációja körül, legyen az KVM vagy beágyzott eszközök, esetleg hálózati-kezelő bővítések. Tehát a Fedora egy olyan hely, ahol az operációs rendszer fejlődését nyomon lehet követni.
A következő Red Hat Enterprise Linuxban láthatjuk majd a KVM-alapú virtualizációs infrastruktúrát?
Erről még nem döntöttünk, leginkább a Fedorára és a RHEL5-re koncentrálunk, még nem hoztunk a RHEL6-tal kapcsolatos döntéseket.
Köszönöm az interjút.
Én köszönöm.