Article on other languages:
- Reliable_Server_Pooling
- Reliable_Server_Pooling
- Reliable_Server_Pooling
- Reliable_Server_Pooling
- Reliable_server_Pooling
- Reliable_server_pooling
- 可信服务器池
 |
del.icio.us |
 |
Digg |
 |
Furl |
 |
|
 |
Rojo |
| Add to OnlyWire |
Reliable Server Pooling (RSerPool) je okvirni protokol za održavanje i pristup server pool_a. I također za pristup klijenata prema serverima (pool). RSerPOOL je trenutno pod standardizacijom IETF RSerPOOL radne grupe IETF RSerPool Working Group.
Sadržaj |
opis
U 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. 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 handlesapace_u je indentificiran jedinstvenim Pool Handle (PH), koji je predstavljen aritrary byte vector_om. Obično je to neki ASCII ili unicode name pool_a. npr. "DOWNLOADPOOL" ili "WEBSERVERPOOL".
Svaki handlespace ima određen scope, označen kao operation scope. Nije cilj RSerPool_a da održava globalni internetov pool, sa jednim handlespace_om. S obzirom na poziciju operation scopes_a, moguće je držati handlespace "tankim". PH nemaju hirarhijsku strukturu za razliku od DNS sa top-level i sub-domain_ama.To čini značajna pojednostavljenja održavanja handlespace_a.
Unutar jednog operation scope_a, handlespace je održavan preko Pool Registrars (PR),takođe označenog kao ENRP server ili Name Servers (NS). PRs ne smiju postati jedina tačka greške. Svaki PR odgovarajućeg operation scope_a je identificiran sa PR ID, sto je 32bitni broj. Nije potrebno da budu jedinstveni. Pr sadrži kompletnu kopiju operation scope handlespace_a. PS sinhronizuju svoj pogled na handlespace koristeći Endpoint Namespace Redundancy Protocol. Ime je također promijenjeno da nebi došlo do zablude sa DNS. Zahvaljujući handlespace sinkronizaciji ENRP_a, PR jednog operation scope_a 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. zahtjevajući registraciju ili deregistraciju, PR zahtjva registraciju ili deregistraciju od aritrary 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 odredjenom vremenu, smatra se mrtvim i istog trenutka biva uklonjen sa handlespace_a. Od PE se očekuje da se re-registrira regularno. Pri registraciji, takođe 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 arbitrary_ovim 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 npr. odabri Random ili zadnje ucitanog PE.U zadnjem slučaju nije potrebno da se ima selekcija informacija, potrebno je da se up-to-date informacija učita u drugom slučaju odabira zadnje- učitanog PE. Koristeći odgovarajuću policy, moguće je npr. da se ostatak ravnomjerno dijeli zahtjev učitavanja na pool_ove PE's.
Nakon prijema liste od PE indentifikacija od jedong PR, jedan PU će napistati PE informacije u svoj local cache. 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 konekciju s njim koristeći protokol npr. HTTP preko SCTP ili TCP u slučaju web servera. Koristeći tu konekciju, servis nuđen od servera se koristi. U slucaju da uspostavljenje konekcije ne uspjeva ili da konekcija biva prekinuta upotrebe usluge, novi PE se može odabrati ponavljanjem opisane selekcije procedure. Ako informacije u PU-side cache_u nije out-dated, PE identity se može direktno odabrati iz cache_a, preskakanjem potrebu za upit PR da sredi rezoluciju... Nakon ponovnog uspostavljanja konekcije sa novim PE, stanje aplikacije se mora ponovo uspostaviti na novim PE. Porcedura potrebna za to se označava kao Failover Procedure, i zavisna je od aplikacije. npr. za FTP download, failover procedure mogla bi znaciti da se novim FTP serveru treba reci ime datoteke i zadnju primljenu poziciju datoteke. Prilikom toga, FTP server će takodjer biti u stanju da uspostavi nastavak downloada. Pošto je failover procedure jako zavisna od korištene aplikacije, nije dio RSerPool_a! Kroz RSerPool se nudi daleko zahvatajuća podrška za implementaciju arbitrary failover schemes preko njihovih Session Layer mechanisms.
Da bi se omogućilo RSerPool komponentima da se automatski podese, PRs mogu najaviti sami sebe putem UDP preko IP 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 opreration scope_u. Prednost korištenja IP multicast_a umjesto broadcast_a je u tome što će ovaj mehanizam i raditi preko rutera. npr. LAN_ov unutar povezani putem VPN_a. Najave će takodjer, u slučaju npr. switched Ethernet_a samo biti uvazene 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 aderesse.
implementacija
Naredne Implementacije 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
rfc's
- RFC 3237 - Requirements for Reliable Server Pooling
- RFC 5351 - An Overview of Reliable Server Pooling Protocols
- RFC 5352 - Aggregate Server Access Protocol (ASAP)
- RFC 5353 - Endpoint Handlespace Redundancy Protocol (ENRP)
- RFC 5354 - Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters
- RFC 5355 - Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats
- RFC 5356 - Reliable Server Pooling Policies
