Pålitlig serverpoolning

Reliable Server Pooling ( RSerPool ) är ett datorprotokollramverk för hantering av och åtkomst till flera, samordnade ( poolade ) servrar . RSerPool är en IETF- standard, som har utvecklats av IETF RSerPool Working Group och dokumenterad i RFC 5351, RFC 5352, RFC 5353, RFC 5354, RFC 5355 och RFC 5356.

Introduktion

I terminologin för RSerPool betecknas en server som ett poolelement (PE). I sin Pool identifieras den av sin Pool Element Identifier (PE ID), ett 32-bitars nummer. PE-ID:t väljs slumpmässigt vid en PE:s registrering till dess pool. Uppsättningen av alla pooler betecknas som Handlespace. I äldre litteratur kan det betecknas som Namnutrymme. Denna valör har tagits bort för att undvika förväxling med Domain Name System (DNS). Varje pool i ett handtagsutrymme identifieras av ett unikt Pool Handle (PH), som representeras av en godtycklig byte-vektor. Vanligtvis är detta ett ASCII- eller Unicode-namn på poolen, t.ex. "DownloadPool" eller "WebServerPool".

Varje handtagsutrymme har en viss omfattning (t.ex. en organisation eller ett företag), betecknat som Operation Scope. Det är uttryckligen inte ett mål för RSerPool att hantera det globala Internets pooler inom ett enda handtagsutrymme. På grund av lokaliseringen av Operation Scopes är det möjligt att hålla handtagsutrymmet "platt". Det vill säga att PH:er inte har någon hierarki i motsats till domännamnssystemet med dess topp- och underdomäner. Denna begränsning resulterar i en betydande förenkling av hanteringen av hanteringsutrymmet.

Inom ett operationsomfång hanteras hanteringsutrymmet av redundanta poolregistratorer (PR), även betecknade som ENRP-servrar eller namnservrar (NS). PR måste vara överflödiga för att undvika att en PR blir en Single Point of Failure ( SPoF). Varje PR i ett operationsomfång identifieras av dess Registrar ID (PR ID), som är ett 32-bitars slumptal. Det är inte nödvändigt att säkerställa unika PR-ID:n. En PR innehåller en komplett kopia av operationskopets handtagsutrymme. PR:er för ett operationsomfång synkroniserar sin syn på handtagsutrymmet med hjälp av Endpoint Handlespace Redundancy Protocol ( ENRP). Äldre versioner av detta protokoll använder termen Endpoint Namespace Redundancy Protocol; detta namn har ersatts för att undvika förväxling med DNS , men förkortningen har behållits. På grund av hanteringsutrymmessynkronisering av ENRP är PR av en operationsomfattning funktionellt lika. Det vill säga, om någon av PR:erna misslyckas, kan varandras PR sömlöst ersätta den.

Genom att använda ASAP (Aggregate Server Access Protocol) kan en PE lägga till sig själv i en pool eller ta bort den från genom att begära en registrering eller avregistrering från en godtycklig PR av operationens omfattning. Vid framgångsrik registrering blir den PR som valts för registrering PE:s Hem-PR (PR-H). En PR-H informerar inte bara de andra PR om verksamhetens omfattning om registrering eller avregistrering av sina PE:er, den övervakar också tillgängligheten av sina PE:er genom ASAP Keep-Alive-meddelanden. Ett keep-alive-meddelande från en PR-H måste bekräftas av PE inom ett visst tidsintervall. Om PE inte svarar inom en viss timeout, antas den vara död och omedelbart avlägsnad från handtagsutrymmet. Vidare förväntas en PE att omregistrera sig regelbundet. Vid en omregistrering är det även möjligt för PE att ändra sin lista över transportadresser eller sin policyinformation.

För att använda tjänsten för en pool måste en klient – ​​kallad Poolanvändare (PU) i RSerPool-terminologi – först begära upplösningen av poolens PH till en lista över PE-identiteter vid en godtycklig PR av operationsomfånget. Denna urvalsprocedur betecknas som Handle Resolution. För det fall att den begärda poolen finns, kommer PR att välja en lista med PE-identiteter enligt poolens policy för urval av poolmedlemmar, även betecknad som Poolpolicy.

Möjliga poolpolicyer är t.ex. ett slumpmässigt urval (slumpmässigt) eller den minst belastade PE (minst använda). Även om det i det första fallet inte är nödvändigt att ha någon urvalsinformation (PE väljs slumpmässigt), är det nödvändigt att upprätthålla uppdaterad belastningsinformation i det andra fallet att välja den minst belastade PE. Genom att använda en lämplig urvalspolicy är det t.ex. möjligt att fördela förfrågningsbelastningen lika på poolens PE:er.

Efter att ha mottagit en lista med PE-identiteter från en PR, kommer en PU att skriva PE-informationen i sin lokala cache. Denna cache betecknas som PU-side cache. Ur sin cache kommer PU:n att välja exakt en PE — återigen med hjälp av poolens urvalspolicy — och upprätta en anslutning till den med hjälp av programmets protokoll, t.ex. HTTP över SCTP eller TCP i händelse av en webbserver. Med denna anslutning används tjänsten som servern tillhandahåller. För det fall att upprättandet av anslutningen misslyckas eller anslutningen avbryts under tjänsteanvändning, kan en ny PE väljas genom att upprepa den beskrivna valproceduren. Om informationen i PU-sidans cache inte är föråldrad, kan en PE-identitet väljas direkt från cachen, vilket hoppar över ansträngningen att be en PR om handtagsupplösning. Efter att ha återupprättat en anslutning med en ny PE måste tillståndet för applikationssessionen återinstanseras på den nya PE. Den procedur som krävs för att återuppta sessionen betecknas som Failover Procedur och är naturligtvis applikationsspecifik. För en FTP- nedladdning till exempel kan failover-proceduren innebära att berätta för den nya FTP-servern filnamnet och den senast mottagna datapositionen. Därmed kommer FTP-servern att kunna återuppta nedladdningssessionen. Eftersom failover-proceduren är mycket applikationsberoende, är den inte en del av RSerPool själv, även om RSerPool ger långtgående stöd för implementering av godtyckliga failover-scheman genom dess Session Layer-mekanismer.

För att göra det möjligt för RSerPool-komponenter att konfigurera automatiskt kan PR:are meddela sig själva via UDP over IP multicast . Dessa tillkännagivanden kan tas emot av PE, PU:er och andra PR, vilket gör att de kan lära sig listan över PR:er som för närvarande är tillgängliga i operationsomfånget. Fördelen med att använda IP-multicast istället för broadcast är att denna mekanism även fungerar över routrar (t.ex. LAN som är sammankopplade via ett VPN ) och meddelandena kommer - för t.ex. ett switchat Ethernet - endast att höras och bearbetas av stationer faktiskt intresserad av denna information. För det fall att IP multicast inte är tillgänglig är det givetvis möjligt att statiskt konfigurera PR-adresser.

Genomföranden

Följande implementeringar är kända:

Standarddokument

RFC:er

  • RFC 3237 - Krav för pålitlig serverpoolning
  • RFC 5351 - En översikt över pålitliga serverpoolningsprotokoll
  • RFC 5352 - Aggregate Server Access Protocol (ASAP)
  • RFC 5353 - Endpoint Handlespace Redundancy Protocol (ENRP)
  • RFC 5354 - Parametrar för Aggregate Server Access Protocol (ASAP) och ENRP (Endpoint Handlespace Redundancy Protocol)
  • RFC 5355 - Hot introducerades av Reliable Server Pooling (RSerPool) och krav på säkerhet som svar på hot
  • RFC 5356 - Tillförlitliga serverpoolningspolicyer
  • RFC 5525 - Pålitlig Server Pooling MIB Module Definition

Arbetsgruppsutkast

Andra utkast

externa länkar