Hlavní navigace

TIPC: alternativní protokol pro komunikaci v rámci clusteru

Michal Filka

Transparent Inter Process Communication (TIPC) protokol byl navržen pro efektivní komunikaci v rámci clusteru. Původně byl vytvořen pro telekomunikační aplikace, kde je potřeba zajistit především spolehlivou a bezproblémovou výměnu dat. Nyní je protokol vyvíjen pod GNU GPL. Co umí? Jak pracuje?

TIPC byl vyvinut původně ve společnosti Ericsson pro použití v telekomunikačních aplikacích. Nyní je uvolněn a vyvíjen pod GPL licencí. Na vývoji se nadále podílí zejména společnosti Ericsson, WindRiver. Motivací při návrhu protokolu bylo zajistit prostředky pro transparentní komunikaci nodů v rámci clusteru. Dalšími požadavky byla spolehlivost komunikace a efektivita.

Předpoklady, ze kterých se vycházelo při návrhu protokolu, byly: komunikace na krátkou vzdálenost – tím se rozumí bez hopu, kdy dva uzly spolu budou typicky komunikovat přímo bez prostřednictví routeru apd. – a použití krátkých zpráv, požadavek na vysokou spolehlivost spojení a další.

V linuxu je implementace TIPC přítomna od verze 2.6.16.

K čemu slouží?

Jak bylo řečeno, TIPC byl vyvinut pro nasazení v telekomunikačních aplikacích. Současné telefonní ústředny totiž čím dál tím více používají pro vnitřní komunikaci paketové sítě (mluvíme o ústřednách pro klasické telefony, ne VoIP apod.). Současná telefonní ústředna je komplexní systém sestávající z mnoha modulů, které se starají mimo jiné o přenos signalizace (protokol/infor­mace, podle kterých se sestavuje a řídí hovor), vlastní přenos hlasu, ale i další doplňkové služby. Odhlédneme-li od přenosu hlasu, jsou přenášené informace často relativně malé, ale je nesmírně důležité, aby jejich doručování bylo spolehlivé, rychlé a do jisté míry pravidelné. Nejmarkantnější je situace zřejmě u signalizace, kdy např. při použití signalizačního protokolu SS7 je efektivní délka přenášených dat nejčastěji mezi 3 až 5 B. Účelem těchto zpráv je detekovat stav spojení mezi dvěma komunikujícími stanicemi, jsou tedy nesmírně důležité pro vlastní funkčnost systému (nepracuje-li signalizace, netelefonuje se). Tyto zprávy se ale periodicky opakují s intervaly v řádech nejvýše desítek milisekund. Při požadavku na současné propojení tisíce a více linek se již jedná a velké nároky na kvalitu použitého řešení (pro představu obvyklý požadavek je na spolehlivost systému jako celku na 99.999%). Tolik k úvodnímu seznámení s prostředím, ve kterém se budeme pohybovat.

Proč ne TCP, SCTP?

K předchozí představě o použitém systému zbývá dodat, že typicky jsou použité moduly redundantní a jejich zapojení v systému (clusteru) se dynamicky mění během času. Nechceme-li tyto dynamicky se měnící konfigurace a z toho plynoucí změny ve spojení mezi moduly řešit na aplikační úrovni, je nutné využít prostředky (služby operačního systému, síťové protokoly, …), které tuto práci udělají za nás (např. zajistí pro aplikaci lokační transparentnost – nerozlišitelnost, zda komunikuje s procesem na lokálním nebo vzdáleném modulu -v terminologii clusteru označován jako nod-, popř. na kterém vzdáleném modulu se proces nachází) a tím zbaví danou aplikaci nutnosti starat se o technické detaily komunikace s konkrétním typem modulu (např. udržování synchronních informací u redundantních modulů, transparentní přesměrování provozu při selhání modulu, apod.). Tato a další specifika jsou příčinou toho, že protokoly, jako je např. TCP, nejsou zcela efektivní.

Pro TCP hovoří jeho velké rozšíření a všeobecně dobré povědomí o jeho vlastnostech. Nicméně pro nasazení v rámci clusteru se nejeví jako vhodný. Zejména proto, že nepodporuje nativní multicast (z principu – jedná se o protokol s tzv. spojovanou komunikací). Dále je při použití TCP nutné rozlišovat komunikaci „opouštějící“ nod a probíhající v rámci nodu. Existují sice různé nadstavby – jako například CORBA -, ty ale zavádějí další režii, která dále poznamenává efektivitu a rychlost komunikace. V případě TCP je navic samotné navázání spojení spojeno s velkou režií. Ve výše popsaném telekomunikačním prostředí pak toto je významným zpomalujícím prvkem, jelikož díky dynamicky se měnícím konfiguracím a z principu práce systému (v tomto případě telefonní ústředna) budou spojení navazována často. Navíc je TCP nejméně efektivní právě pro přenos relativně krátkých zpráv, které jsou do jisté míry pro dané prostředí typické.

SCTP je chápáno jako vhodnější protokol než TCP, nicméně některé z popsaných nevýhod se stále vyskytují.

Obecně je možné říci, že protokoly TCP, SCTP jsou nevhodné kvůli tomu, že se jedná o tzv. obecně použitelné protokoly, které se snaží řešit všechny potenciální problémy. Oproti tomu TIPC je úzce specializovaným protokolem, díky čemuž dosahuje na krátkých zprávách (< 1.5 kB) o 35–80 % lepší výkon než TCP/IP. Na větších zprávách je výkon srovnatelný, při větších zprávách (> 4kB) již je TCP výkonější.

Charakteristika TIPC

Doposud byly zmíněny pouze úvahy a motivace vedoucí k návrhu protokolu TIPC. Zde jsou uvedeny jeho vlastnosti, které bývají nejčastěji zmiňovány. Protokol TIPC podporuje:

  • Spolehlivé a nespolehlivé nespojované komunikační mody (SOCK_RDM a SOCK_DGRAM).
  • Spolehlivé na spojení orientované komunikační mody (SOCK_SEQPACKET a SOCK_STREAM).
  • Spolehlivé a nespolehlivé všesměrové vysílání přes celý cluster.
  • Funkční adresovací schéma, jež umožňuje adresování přes primární/sekundární klíč a skupinové adresování.
  • Možnost adaptace na různá média a protokoly v závislosti na síťové infrastruktuře a bezpečnostních požadavcích: Ethernet, RapidIO, ATM/AAL5, TCP, SCTP, UDP atd. Typicky se ale předpokládá nasazení nad protokoly Levelu 2.
  • Topologická služba pomáhající aplikacím znát funkční a fyzické adresy v clusteru.
  • Provoz TIPC je předpokládán v rámci zabezpečené sítě, proto TIPC neobsahuje žádnou podporu pro zabezpečení přenášených dat.
  • Rychlá detekce selhání linky (spojení mezi nody).

Shrnutí

Protokol TIPC byl navržen pro spolehlivou komunikaci v rámci clusteru. Zde byl diskutován v souvislosti s oblastí telekomunikací, pro kterou byl původně navržen. Jeho vlastnosti ale nabízí jistě daleko širší uplatnění. Mezi klíčové vlastnosti patří plná lokační transparentnost v rámci clusteru, podpora spolehlivého spojení, atd.

Na závěr teoretického povídání nezbývá než přidat odkaz na poněkud konkrétnější výsledky. Zajímavé srovnání výkonnosti TIPC a TCP na různých datech je možné nalézt na adrese www.strlen.de/tip­c. V pokračování už bude naznačeno trochu více o architektuře a principech tohoto protokolu.

Zdroje

[1] Dokumentace open source implementace TIPC
[2] Benchmark

Našli jste v článku chybu?

24. 8. 2007 10:44

Dobry den,

Myslim, ze je trochu chyba a skoda, ze ste hned v nadpise/clanku neuviedli, ze sa jedna o dualnu licenciu BSD a GPL. Na strankach projektu je to jasne napisane a root.cz nie je iba o propagacii GNU. ;-)

Inak nie je mi celkom jasne naco protokol (architektura?) potrebuje nejake licencovanie. Ale priznam sa, ze clanok som este (poriadne) necital. Kazdopadne vdaka zan.

Martin





18. 7. 2007 8:44

Clanek nebyl psan jako odborny, ale pro sirokou verejnost. Jsou zde tedy zjednoduseni oproti skutecnosti. Bylo potreba najit snadny priklad popisujici podminky, ve kterych se pohybujeme a pokud mozno bez implementacnich zavislosti. I uvedeny priklad vystihuje urcite specificke podminky prostredi, o kterem se bavime, a o to slo.

Cili rad upravym nepresnosti, kterych jsem se vuci vam dopustil. Pojem "signalizacni protokol SS7" neni spravne. Spravne se jedna o protokolovy stack, ktery o…

Měšec.cz: Air Bank zruší TOP3 garanci a zdražuje kurzy

Air Bank zruší TOP3 garanci a zdražuje kurzy

Vitalia.cz: Mondelez stahuje rizikovou čokoládu Milka

Mondelez stahuje rizikovou čokoládu Milka

DigiZone.cz: Test Philips 24PFS5231 s Bluetooth repro

Test Philips 24PFS5231 s Bluetooth repro

Podnikatel.cz: Přehledná titulka, průvodci, responzivita

Přehledná titulka, průvodci, responzivita

Lupa.cz: Proč firmy málo chrání data? Chovají se logicky

Proč firmy málo chrání data? Chovají se logicky

Vitalia.cz: Láska na vozíku: Přitažliví jsme pro tzv. pečovatelky

Láska na vozíku: Přitažliví jsme pro tzv. pečovatelky

120na80.cz: Pánové, pečujte o svoje přirození a prostatu

Pánové, pečujte o svoje přirození a prostatu

Vitalia.cz: Pamlsková vyhláška bude platit jen na základkách

Pamlsková vyhláška bude platit jen na základkách

Podnikatel.cz: EET: Totálně nezvládli metodologii projektu

EET: Totálně nezvládli metodologii projektu

Root.cz: Certifikáty zadarmo jsou horší než za peníze?

Certifikáty zadarmo jsou horší než za peníze?

Vitalia.cz: „Připluly“ z Německa a možná obsahují jed

„Připluly“ z Německa a možná obsahují jed

Podnikatel.cz: Snížení DPH na 15 % se netýká všech

Snížení DPH na 15 % se netýká všech

Podnikatel.cz: K EET. Štamgast už peníze na stole nenechá

K EET. Štamgast už peníze na stole nenechá

Lupa.cz: Co se dá měřit přes Internet věcí

Co se dá měřit přes Internet věcí

Vitalia.cz: Jsou čajové sáčky toxické?

Jsou čajové sáčky toxické?

Lupa.cz: Teletext je „internetem hipsterů“

Teletext je „internetem hipsterů“

Lupa.cz: Propustili je z Avastu, už po nich sahá ESET

Propustili je z Avastu, už po nich sahá ESET

Vitalia.cz: Jmenuje se Janina a žije bez cukru

Jmenuje se Janina a žije bez cukru

Podnikatel.cz: 1. den EET? Problémy s pokladnami

1. den EET? Problémy s pokladnami

Podnikatel.cz: Udávání kvůli EET začalo

Udávání kvůli EET začalo