Reliable Server Pooling
Ovaj članak je siroče zato što nema ili vrlo malo ima drugih članaka koji linkuju ovamo. |
Reliable Server Pooling (RSerPool) jeste okvirni protokol za održavanje i pristup server pool_a, kao i za pristup klijenata prema serverima (pool). RSerPOOL je trenutno pod standardizacijom IETF RSerPool radne grupe IETF RSerPool Working Group.
Opis
urediU terminologiji RSerPOOL, server je određen kao Pool Element (PE). U tom pool_u označen je pomoću svog (PE ID), 32-bitni broj. IE ID je odabran na osnovu PE registracije pool_a. Skup svih pool_ova je označeno kao Handlespace (radni prostor). U starijoj literaturi može biti označeno kao Namespace. Ta izmjena je izvršena iz razloga da se izbjegne zabuna sa Domain Name System. Svaki pool u handlespace_u je indentificiran jedinstvenim Pool Handle (PH), koji je predstavljen arbitrarnim byte vector_om. Obično je to neki ASCII ili unicode name pool_a. npr. "DOWNLOADPOOL" ili "WEBSERVERPOOL".
Svaki radni prostor (handlespace) ima određen obim, označen kao operation scope (bosanski: operacioni obim). Nije cilj RSerPool_a da održava globalni internetov fond, sa jednim radnim prostorom. S obzirom na mjesto operation scope_a, moguće je držati radni prostor "tankim". PH nemaju hierarhijsku strukturu za razliku od DNS sa top-level i sub-domain_ama. To čini značajna pojednostavljenja održavanja radnog prostora (handlespace-a).
Unutar jednog operacionog obima radni prostor je održavan preko Pool Registrara (PR), također označenih kao ENRP server ili Name Servers (NS). Pool Registrari ne smiju postati jedina tačka greške. Svaki PR odgovarajućeg operacionog obima je identificiran sa PR ID, sto je 32bitni broj. Nije potrebno da budu jedinstveni. Pr sadrži kompletnu kopiju operacionog obima radnog prostora. PS sinhronizuju svoj pogled na radni prostor koristeći "Završnu tačku protokola odstranjivanja suvišnih informacija" (eng. Endpoint Namespace Redundancy Protocol). Ime je također promijenjeno da ne dođe do zablude sa DNS. Zahvaljujući sinhronizaciji radnog prostora ENRP_a, PR jednog operacionog obima su funkcionalno identični. Sto znači, da ako jedan od PR ne uspije, svaki drugi PR ga jednostavno zamjenjuje.
Koristeći Aggregate Server Access Protocol (ASAP), a PE može sebe dodati jednom pool_u ili ukloniti se od datog. Pri tom zahtijeva registraciju ili deregistraciju, PR zahtjeva registraciju ili deregistraciju od arbitrarnog PR iz operation scope_a. U slučaju uspješne registracije, PR odabran za registraciju postaje PE_ov PR-H. PR-H ne samo da obavještava ostale PR, već i nadgleda dostupnost PE_ova preko ASAP Keep-Alive poruka. Keep-Alive poruke od PR-H se moraju prihvatiti od strane PE u određenom vremenskom intervalu. Ako PE ne uspije da odgovori u određenom vremenskom periodu, smatra se mrtvim i istog trenutka biva uklonjen sa handlespace_a. Od PE se očekuje da se re-registrira redovno. Pri registraciji, također je moguće za PE da promijeni listu transport adresses_a ili policy informacija.
Da bi se korisitila usluga jednog pool_a, zvanokg PU u RSerPool terminologiji - prvo se mora zahtjevati rezolucija pool_ovog PH ka listi od PE identifikacija pri jednom arbitrarnom PR od operation scope_a. Ta odabrana procedura se naziva Handle Resolution. U slučaju da potraženi pool postoji, PR će odabrati listu PE identifikacija odgovarajući pool_ovim Pool Member Sleection Policy, pojednostavljeno označen kao Pool Policy.
Moguće pool policies_e su nasumično odabrani (Random) ili se koristi najmanje opterečeni PE. U zadnjem slučaju nije potreban bilo kakav odabir informacija (PE su odabrani nasumično) potrebno je da se najnovije informacije učitavaju u drugom slučaju odabira zadnjeg učitanog PE. Koristeći odgovarajuću strategiju odabira informacija, moguće je da se ostatak ravnomjerno raspodijeliti zahtjeve učitavanja na pool_ove PE.
Nakon prijema liste od PE indentifikacija od jedong PR, jedan PU će napisati PE informacije u svoj local cache (lokalni spremnik). Taj cache je označen kao PU-side Cache. Van svog cache_a, PU će odabrati tačno na PE - ponovo koristeći pool selection policy - i uspostavljajući vezu s njim koristeći protokol npr. HTTP preko SCTP ili TCP u slučaju web servera. Koristeći tu vezu, koristi se servis nuđen od servera. U slučaju da uspostavljanje veze ne uspijeva ili da veza biva prekinuta tokom upotrebe usluge, novi PE se može odabrati ponavljanjem opisane odabirne procedure. Ako informacije u PU-side cache_u nije zastario, PE identitet se može direktno odabrati iz cache_a, preskakanjem potrebe za upit PR da sredi rezoluciju... Nakon ponovnog uspostavljanja veze sa novim PE, stanje aplikacije se mora ponovo uspostaviti na novim PE. Procedura potrebna za to se označava kao Failover Procedure (bosanski: Postupak odustajanja) i zavisna je od aplikacije. npr. za FTP download, postupak odustajanja mogao bi značiti da se novom FTP serveru treba reċi ime datoteke i zadnju primljenu poziciju datoteke. Prilikom toga, FTP server će također biti u stanju da uspostavi nastavak downloada. Pošto je procedura odustajanja jako zavisna od korištene aplikacije, nije dio RSerPool_a! Kroz RSerPool se nudi daleko zahvatajuća podrška za sprovođenje arbitrarnih šema odustajanja preko njihovih Session Layer mehanizama.
Da bi se omogućilo RSerPool komponentama da se automatski podese, PRs mogu najaviti sami sebe putem UDP preko IP višesmjernog emitovanja (multicast_a). Te najave se mogu primiti preko PE_a, PU_a i drugih PR_a, koji dozvoljavaju njima da uvide listu PR_a trenutno dostupnih u operation scope_u (operacionom obimu). Prednost korištenja IP multicast_a umjesto broadcast_a je u tome što će ovaj mehanizam raditi preko routera. npr. LAN_ov koji je unutar povezan putem virtualne privatne mreže VPN a. Najave će također, u slučaju npr. switched Ethernet_a samo biti uvažene i izvedene od stanica koje su zainteresovane za tu informaciju. U slučaju da IP multicast nije dostupan, moguće je i da se statički podese PR adrese.
Radna primjena
urediNaredne radne primjene su poznate:
- RSPLIB Project by the University of Duisburg-Essen (is also reference implementation of the IETF RSerPool WG)
- Motorola
- Cisco
- Münster University of Applied Sciences
Standardni dokumenti
urediRFC
uredi- RFC 3237 - Uslovi za pouzdano udruživanje servera (eng. Requirements for Reliable Server Pooling)
- RFC 5351 - Pregled protokola pouzdanog udruživanja servera
- RFC 5352 - Protokol zbirnog pristupa poslužitelju tj. serveru (eng. Aggregate Server Access Protocol - ASAP)
- RFC 5353 - Završna tačka protokola odstranjivanja suvišnih informacija (eng. Endpoint Handlespace Redundancy Protocol - ENRP)
- RFC 5354 - Parametri za Protokol zbirnog pristupa poslužitelju (ASAP) i Završne tačke protokola odstranjivanja suvišnih informacija (ENRP)
- RFC 5355 - Prijetnje izazvane pouzdanim udruživanjem servera (RSerPool) i zahtjeva prilikom odgovora na prijetnje
- RFC 5356 - Polisa kod pouzdanog udruživanja servera
- RFC 5525 - Definicija modula kod pouzdanog udruživanja servera (MIB)