25. april 2003 - 12:03Der er
27 kommentarer og 1 løsning
Brugen af corba i en clusteret server
Jeg er så småt ved at være færdig med udviklingen af et clusteret system. En master-server indeholder et register over bla. alle slave-serverne, som principielt kan clustres i uendelig mange instanser.
En af master-serverens vigtigste opgaver er at styre load-balanceringen i systemet. En ting jeg dog ikke bryder mig om er, at en master-server som administrerer hele systemet, er en klar SPOF (single point of failure). Derfor ville jeg at fjerne master-serveren og blot lade en slave-server indtage rollen som master, og hvis den går ned træder en anden slave-server ind i master-rollen.
Pt. et kommunikationen serverne imellem realiseret vha. RMI, hvilket giver et problem jeg godt vil undgå. Hvis man skal kalde en metode på en anden server, er man nødt til at kende ip-adressen til det register, hvor server-objektet er bundet, da man kun kan binde i lokale registre.
Spørgsmålet er så, kan dette undgås med CORBA? Kan man kalde en server udelukkende ved det i ORBen bundende navn? F.eks. hvis den der har master-rollen altid hedder "master", kan jeg så i CORBA kalde objektet med navnet "master" uden at skulle kende ip-adressen?
Denne side indeholder artikler med forskellige perspektiver på Identity & Access Management i private og offentlige organisationer. Artiklerne behandler aktuelle IAM-emner og leveres af producenter, rådgivere og implementeringspartnere.
Ja, jeg er sikker på at man ikke i RMI kan binde til et remote registry, SUN skriver det selv, kan bare ikke huske hvor jeg så det. Når man skal slå et objekt i RMI er man nødt til at angive adressen også: //host:port/name og det er DET jeg ikke kan lide. Angiver man ikke en adressen søger den kun på local host. Kan CORBA slå objekter op på andre fysiske maskiner uden at skulle angive den præcise adress og kun navnet?
Jeg kender ikke noget særligt til den ORB java bruger og har ikke kigget på en clusterable JNDI server. Men så vidt jeg ved har alle applikationer der vil slå objekter op eller binde en ORB kørende?
Grunden til at jeg troede RMI registry kunne køre remote er følgende fra API doc på java.rmi.Naming:
The Naming class provides methods for storing and obtaining references to remote objects in a remote object registry. Each method of the Naming class takes as one of its arguments a name that is a java.lang.String in URL format (without the scheme component) of the form:
//host:port/name
where host is the host (remote or local) where the registry is located, port is the port number on which the registry accepts calls, and where name is a simple string uninterpreted by the registry. Both host and port are optional. If host is omitted, the host defaults to the local host. If port is omitted, then the port defaults to 1099, the "well-known" port that RMI's registry, rmiregistry, uses.
Hvis du vil bruge RMI til (ofcoz) remote invokationer, har du nok lidt af et problem med standard stubbene som RMI genererer, da jeg mener at disse indholder IP-adren på server-objektet. Kig på JavaGroups eller JINI til at løse dine clustering mht. master/slave problemtik (multicast). For at lave klienterne crash-resistant, skal du nok enten lave rigtigt meget house-keeping på klient-siden såfremt en server går ned skal du finde en anden server og slå denne op via Naming.lookup, eller lave dine egne stubbe, som f.eks. J2EE servere typisk gør (on-the-fly)
Nej selvfølgeligt ikke for på compile tidspunkt kendes ip'en jo ikke. Desuden virker RMI så hut jeg visker således at man via lookup for en stub tilbage hvori ip'en på serveren samt port hvortil stubben skal forbinde er blevet sat på den aktuelle instans..
Problemet er jo det samme. Da den stub som klienten har loadet indeholder ip'en på serveren og denne server går ned er man jo nødt til at finde en ny "server" i clustered som man kan benytte istedet. Dette er der ikke lavet noget for i std. stubbe.. Derfor skal man lave cluster-aware stubbe til at løse problemet.
Ja clustering er noget man selv må realisere, RMI er et middel. Jeg har læst lidt om JNDI, som skulle give mulighed for at slå remote-objekter op uden at kende deres placering i netværket, så det er nok det jeg skal have kigget nærmere på :)
njah.. Jeg er nu ikke sikker på at JNDI vil hjælpe dig der som standard. Normalt skal man vha. Properties sætte ens InitialContextFactory op i JNDI, samt hvilken server der er endpoint. Mange j2ee serveren laver en remote version af et initialcontext, som kører lokalt, men looker objekterne op på en anden maskine. JNDI kan bruges istedet for Naming.lookup (RMI) vha. en RMI impl. af initialcontext. Du er nok nødt til at lave dig egen impl. af en context, som spørger clustered hvilken server(e) den kan tilgå. Så kan du vist det skal være helt porno lave dine stubbe til at udføre load-balancing fordelt over flere servere (hvis IP'er sættes i dine stubbe)
Nu er der ikke nogen standard for at konfigurere InitialContext, men f.eks. JBoss clustering så undlader man at angive nogen URL og så detecter den selv JNDI clusteret via MultiCast.
Citat fra docs:
Cluster-wide JNDI You can connect to and use the cluster-wide JNDI tree simple by leaving the provider URL undefined. JBoss will use IP multicast to discover clustered JNDI.
Ja, det er noget i den stil jeg er interesseret i, hvor en slave-server f.eks. bare "råber ud i rummet" på en master-server, som så svarer uden at vide hvilken ip-adresse den kører på.
<quote arne_v> Nu er der ikke nogen standard for at konfigurere InitialContext.. </quote arne_v> Jo - Hashtable t = new Hashtable(); t.put(Context.INITIAL_CONTEXT_FACTORY, "net.sf.MyInitialContext"); osv... Context c = new InitialContext(t);
InitialContext interfacet er naturligvis 100% standard, fordi det er en del af J2SE.
Men de properties der konfiguerer InitialContext er forskellige fra implementation til implementation. Attribut værdierne er altid forskellige og der kan være forskel på attribut navnene pgså. Og clustering er en af de ting som jeg formoder er meget forskellig mellem implementationerne.
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.
