Reliable Server Pooling

Izvor: Wikipedija
Reliable Server Pooling
Reliable Server Pooling
 Ovaj članak ili dio članka sadrži mnoštvo nepotrebnih anglizama i struktura koje postoje u engleskom jeziku, a ne postoje u hrvatskom jeziku.
Slobodno pomozite to prevesti i ispraviti vodeći računa o stilu i pravopisu. Izvornik se možda nalazi na popisu drugih jezika.
Reliable Server Pooling
Reliable Server Pooling
 Ovaj članak ili dio članka, djelomično ili uopće nije preveden s engleskog jezika. (Rasprava)
Pomozite u prijevodu vodeći računa o stilu i pravopisu. Izvornik se možda nalazi na popisu drugih jezika.
Reliable Server Pooling
Reliable Server Pooling
 Ovaj članak ili odjeljak nije wikipediziran. (Rasprava)
Tekst članka treba preurediti u wikitekst. Potom uklonite ovaj predložak.
Reliable Server Pooling
Reliable Server Pooling
 Ovaj članak nema wikipoveznica ili ih ima premalo.
Članak treba dopuniti dodavanjem wikipoveznica na druge pojmove.

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.

Opis[uredi | uredi kôd]

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 s 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, s 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 s 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đer označenog kao ENRP server ili Name Servers (NS). PRs ne smiju postati jedina točka greške. Svaki PR odgovarajućeg operation scope_a je identificiran s PR ID, sto je 32bitni broj. Nije potrebno da budu jedinstveni. Pr sadrži kompletnu kopiju operation scope handlespace_a. PS sinkronizuju svoj pogled na handlespace koristeći Endpoint Namespace Redundancy Protocol. Ime je također promijenjeno da nebi došlo do zablude s 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. zahtijevajuć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 s handlespace_a. Od PE se očekuje da se re-registrira regularno. 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 zahtijevati 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 toč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 s 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 značiti da se novim FTP serveru treba reci ime datoteke i zadnju primljenu poziciju datoteke. Prilikom toga, FTP server će također 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 također, u slučaju npr. switched Ethernet_a samo biti uvažene i izvedene od stanica koje su zainteresirane za tu informaciju.

U slučaju da IP multicast nije dostupan, moguće je i da se statički podese PR aderesse.

Implementacija[uredi | uredi kôd]

Naredne Implementacije su poznate:

Standardni dokumenti[uredi | uredi kôd]

RFC-i[uredi | uredi kôd]

  • 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
  • RFC 5525 - Reliable Server Pooling MIB Module Definition

I-D-i[uredi | uredi kôd]

Vanjske poveznice[uredi | uredi kôd]

Dobavljeno iz "https://hr.wikipedia.org/w/index.php?title=Reliable_Server_Pooling&oldid=6771472"