24. marts 2003 - 21:57Der er
33 kommentarer og 1 løsning
Rerouting af socket-connections mellem servere i cluster
Jeg arbejder pt. på et clusteret server-system, som ret naturligt består af en master-server og et antal slave-servere. Broen mellem master/slave er endnu ikke realiseret men foretrækkes laved med RMI. Klienterne connecter til master-serveren via Socket-ServerSocket.
Spørgsmålet ligger så i: hvordan kan jeg, når master-serveren modtager en klient med ServerSocket.accept() reroute/redirecte (kald det hvad du vil) denne forbindelse til en anden slave-server, som sandsynligvis kører på en anden fysisk maskine?
Normalt bruger man cluster betegnelsen om et system af ligeværdige servere.
Og den traditionelle måde at implementere det på (lige fra J2EE app-server cluster til OpenVMS cluster) er at clusteret har et navn om man connecter til cluster-navnet og får så den server med mindst load. Og hvis det er en god cluster-løsning så bliver man automatisk flyttet til en anden server, hvis den man er forbundet til fejler.
Det er en multiplayer spilleserver jeg udvikler, som skal kunne håndtere flre tusinde klienter, lidt for mange til alle at kunne køre på samme maskine. Når en klient logger på er det serveren der bestemmer hvilken slave-server klienten skal sendes videre til, f.eks. ud fra hvor der er andre klienter (i en abstrakt verden). Grundet nogle runtime administrationsfunktioner er der nødt til at være en master-server som indeholder bla. en cache med fælles data.
En verden er opdelt i flere rum, som køre på forskellige servere, bestemt manuelt. Serveren husker f.eks. hvilket rum klienten var i sidst denne disconnectede og derved skal "smide" klienten ind i samme rum ved næste connct. Pt. ved de forskellige servere ikke hvilke rum der kører på de andre servere, så hvis ikke en master-server som tager imod klienterne er løsningen, hvordan kan man så gøre?
Må jeg have lov til at nævne et af e slemme ord: EJB !
En entity bean kan cache administrations data på alle servere.
Et "rum" kan være ensession bean som kun deployes på et cluster member. Så sørger app-serveren selv for at requests til den EJB ryger til den rigtige server.
Jeg troede du tænkte noget i retningen af at selve socket-serveren skulle benytte EJB'er som backend... men jeg kunne da godt have fortalt lidt før at vi snakkede Flash :)
Og så kom jeg sandlig også til accaptere dit svar, ville ellers have ventet lige lidt, nåh men jeg har da i hvert fald fået klarhed over at man ikke automatisk kan redirecte en forbindelse. Er det sådan noget smart man har lavet her på eksperten, at den selv accepterer svar random ? :)
Kan du uddybe hvad du mener. Tænker du på at masteren skal holde på alle connections og blot sende data videre til en slave? Vil det ikke medføre et pokkers til load på masteren?
Den gemmer ikke mange data, så RAM forbruget må være beskedent.
Den beregner ikke på data, så CPU forbruget må være beskedent.
Net-kortet får lov at bestille noget. Men net-kort i X Mbit er betydeligt billigere end X Mbit internet-forbindelser, så jeg regner med at det også går.
Men det kræver noget snedigt multi-threaded programmering at få det til at køre smooth.
[men det gør din applikation nok under alle omstændigheder]
10000 sockets vil være en hård belastning. Og jeg vil bl.a. tror at du skal have tweaket operativ-systemet lidt for at understøtte så mange samtidige sockets.
Jeg kan godt se at clustrede master-servere ville være en god løsning men også mere kompliceret for lille mig, der samtidig skal have tid til at lave selve spil-delen :)
ALt tager jo tid at lave, men hvis du vælger standard løsninger, så skal du jo ikke lave så meget.
load balancing med DNS round robin kræver ikke noget.
J2EE app-server clustering for admin data kræver ikke ret meget.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
