Summary: This page is about the replication gateway components.
OverviewA replication gateway is used in order to send replication from one space to another space by acting as the delegator of outgoing replication from one space to another, and by receiving incoming replication from a remote gateway and dispatching it to the local space. The gateway is composed from two components that handle this operation, a delegator and a sink. This components are configured in a standard pu.xml and the gateway should be deployed as a single instance processing unit into the service grid of each site configured with the local site relevant properties. Gateway ComponentsGateway DelegatorThe gateway delegator main purpose is to delegate outgoing replication from one site to another, the need for the delegator arise from the common gateway usage topology, which is replicating data between spaces across WAN. In this case, usually each space instance machine cannot open a direct socket to the remote site, therefor it uses the local delegator which is deployed on the local network in order to create a replication connection to the remote site. The machine on which the delegator is deployed, should have access to the remote site over the WAN and the ability to open sockets with the ports for discovery and communication which are configured in the gateway. Because the delegator is an outgoing communication point for replication, it is also used in the Bootstrap process to delegate the bootstrap related communication from the bootstrapped site to the bootstrap source site. The delegator configuration block in the gateway pu.xml looks as follows: <os-gateway:delegator id="delegator" local-gateway-name="NEWYORK" gateway-lookups="gatewayLookups"> <os-gateway:delegations> <os-gateway:delegation target="LONDON"/> <os-gateway:delegation target="HONGKONG"/> </os-gateway:delegations> </os-gateway:delegator> In this example, this is a delegator of New-York's gateway which acts as a delegation point for two targets, London and Hong-Kong. This will be the mediation point for the two replication channels to London and Hong-Kong of each space instance. It is important to understand that the delegator is not in charge of broadcasting each packet to all the targets but it receives the relevant packet from each source channel and delegate it to the correct target according to the channel endpoint. Gateway SinkThe gateway sink main purpose is to handle incoming replication, which is received by a remote gateway delegator from a remote site, and dispatch it into the local space. The sink has a special proxy to the local space that it uses in order to dispatch the replication into the space. The sink is also used the Bootstrap process in both ends, it is used to initiate the bootstrap process and to fill in the local space with the data. It is also used at the bootstrap source site as the communication mediator between the remote sink and the local space which is used as the source for bootstrapping. The sink configuration block in the gateway pu.xml looks as follows: <os-gateway:sink id="sink" local-gateway-name="NEWYORK" gateway-lookups="gatewayLookups" local-space-url="jini://*/*/myNYSpace"> <os-gateway:sources> <os-gateway:source name="LONDON" /> <os-gateway:source name="HONGKONG" /> </os-gateway:sources> </os-gateway:sink> In this example, this is the sink of New-York gateway that is open for incoming replication from London and Hong-Kong and will dispatch this incoming replication to the local space named "myNYSpace". Gateway Lookup MechanismIn the above configuration samples, there is a gateway-lookup attribute, this attribute points to the lookup related configuration parameters. The gateway components needs to locate each other in order to communicate with each other. This lookup is done both across sites and in some cases locally. Additionally the local space needs to locate the gateway delegator it needs to use for delegation, and the gateway sink needs to locate the local space in order to dispatch incoming replication to it. We will split the lookup described here into two catagories:
Local Site LookupThis lookup is done using the locally deployed lookup services which are already used by the service grid components and spaces in order to locate each other. The gateway components register in the local lookup services and therefor can be located by all the local services and components. e.g a space locates the local delegator to the remote target via the local lookup service. Cross Site LookupThis lookup is done using dedicated lookup services that are started by the gateway components upon deployment if needed, this lookup services are used by the gateway components to locate each other across sites (e.g across WAN) and therefore will usually be based on unicast (multicast is also supported if the remote sites support multicast between them). When unicast is used, each gateway needs to be aware to the remote gateways hosting machines and discovery port, and both the discovery and communication ports should be permitted in the firewalls between the sites. The discovery port is the port the embedded lookup service which is started by the gateway will listen for incoming registrations and lookup requests. The communication port is used by the replication in order to receive incoming replication, this is translated to LRMI port the hosting GSC will use. This configuration is specified in each gateway pu.xml in the following manner: <os-gateway:lookups id="gatewayLookups"> <os-gateway:lookup gateway-name="NEWYORK" host="ny-gateway-host-machine" discovery-port="10001" communication-port="7000" /> <os-gateway:lookup gateway-name="LONDON" host="london-gateway-host-machine" discovery-port="10002" communication-port="8000" /> <os-gateway:lookup gateway-name="HONGKONG" host="hk-gateway-host-machine" discovery-port="10003" communication-port="9000" /> </os-gateway:lookups> <!-- The above ports and host names are randomly selected and have no meaning, all sites could designate the same ports as well--> Each os-gateway:lookup entry specifies how the gateway is exposed to the other gateways for communication, each site should contain its own lookup entry in the configuration as well so it will be able to setup a lookup service with the proper ports and setup the proper communication port. The gateway should be deployed on the machine specified in its lookup entry, this should be achieved by having a GigaSpaces Agent running on that machine with a dedicated zone, and configuring the gateway to be deployed to that specific zone (see Configuring the Processing Unit SLA). Once deployed, the gateway will check if the Container it was deployed into is started with the proper ports, if not it will relocate itself to a proper container, and it may instantiate a new container managed by the agent on that machine if needed. The communication port is not mandatory, because this port number is written inside the lookup entry of the relevant replication component which is registered at the lookup service, therefore a remote site learns the other site communication port as part of the discovery process. However, in many cases there is a firewall between the remote gateways and only specific ports are permitted. Specifying the communication port simplifies deployment by making sure the gateway logic of checking whether it is deployed into a GSC with the right ports that is mentioned previously, will validate that the communication port (LRMI) of the hosting GSC matches the configuration, and if not, it will activate the relocation logic described above. If there is no firewall, and all ports are available, there is no need to specify a communication port as any communication port specified by the OS will be ok. Full Gateway Configuration Example FileBelow is an example pu.xml file for the gateway of New-York <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:context="http://www.springframework.org/schema/context" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:os-core="http://www.openspaces.org/schema/core" xmlns:os-events="http://www.openspaces.org/schema/events" xmlns:os-remoting="http://www.openspaces.org/schema/remoting" xmlns:os-sla="http://www.openspaces.org/schema/sla" xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd http://www.openspaces.org/schema/core http://www.openspaces.org/schema/8.0/core/openspaces-core.xsd http://www.openspaces.org/schema/events http://www.openspaces.org/schema/8.0/events/openspaces-events.xsd http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/8.0/remoting/openspaces-remoting.xsd http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/8.0/sla/openspaces-sla.xsd http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/8.0/core/gateway/openspaces-gateway.xsd"> <os-gateway:delegator id="delegator" local-gateway-name="NEWYORK" gateway-lookups="gatewayLookups"> <os-gateway:delegation target="LONDON"/> <os-gateway:delegation target="HONGKONG"/> </os-gateway:delegator> <os-gateway:sink id="sink" local-gateway-name="NEWYORK" gateway-lookups="gatewayLookups" local-space-url="jini://*/*/myNYSpace"> <os-gateway:sources> <os-gateway:source name="LONDON" /> <os-gateway:source name="HONGKONG" /> </os-gateway:sources> </os-gateway:sink> <os-gateway:lookups id="gatewayLookups"> <os-gateway:lookup gateway-name="NEWYORK" host="ny-gateway-host-machine" discovery-port="10001" communication-port="7000" /> <os-gateway:lookup gateway-name="LONDON" host="london-gateway-host-machine" discovery-port="10002" communication-port="8000" /> <os-gateway:lookup gateway-name="HONGKONG" host="hk-gateway-host-machine" discovery-port="10003" communication-port="9000" /> </os-gateway:lookups> <!-- The above ports and host names are randomly selected and have no meaning, all sites could designate the same ports as well--> </beans> Indirect Delegation (Delegation via other gateways)Some topologies may require in direct delegation, for example in the above topology, there bandwidth between London and Hong-Kong be very poor or maybe there is no direct connection between this two sites but they should still replicate to each other. This replication can be delegated from London to Hong-Kong via New-york and the other way around as well. This is accomplished by chaining delegators together, in this case the delegator of London to Hong-Kong will be actually connected to the delegator of New-York to Hong-Kong thus delegating the replication communication via New-York. In this case the gateway of London should be configured as follows: <os-gateway:delegator id="delegator" local-gateway-name="LONDON" gateway-lookups="gatewayLookups"> <os-gateway:delegations> <os-gateway:delegation target="NEWYORK"/> <os-gateway:delegation target="HONGKONG" delegate-through="NEWYORK"/> </os-gateway:delegations> </os-gateway:delegator> <os-gateway:sink id="sink" local-gateway-name="LONDON" gateway-lookups="gatewayLookups" local-space-url="jini://*/*/myNYSpace"> <os-gateway:sources> <os-gateway:source name="LONDON" /> <os-gateway:source name="HONGKONG" /> </os-gateway:sources> </os-gateway:sink> <os-gateway:lookups id="gatewayLookups"> <os-gateway:lookup gateway-name="NEWYORK" host="ny-gateway-host-machine" discovery-port="10001" communication-port="7000" /> <os-gateway:lookup gateway-name="LONDON" host="london-gateway-host-machine" discovery-port="10002" communication-port="8000" /> </os-gateway:lookups> <!-- The above ports and host names are randomly selected and have no meaning, all sites could designate the same ports as well--> </beans> In this configuration we have specifies that the delegator to Hong Kong should be routed via New York. This chaining can contain one or more delegators, i.e New York delegator could have been connected to Hong Kong via some other 4th site. The Hong Kong gateway should be configured in the same way. Another important thing to notice is that the lookup entry for Hong Kong is removed in London's gateway since it should never lookup Hong Kong directly. In Direct delegation can be used by a Bootstrap in the same manner, since the gateway sink in the bootstrapping site is using the local delegator in order to locate the bootstrap source site sink and therefor it will go through the same delegation path. NAT ConfigurationWhen having Network Address Translation (NAT) while data transit across different routing devices over the WAN, you should use the NAT mapping configuration with your WAN Gateway. Each site gateway should have a NAT mapping file that maps the remote site local IP to the public IP, therefore each site should have a different mapping file because it should not map its own local IP to the public IP. Additionally, in each site you should place the public IP in the Gateway lookup element of the remote sites Gateway, and the local IP in the lookup element of the local site Gateway, once again, in this case the gateways lookup element in the pu.xml of the Gateways will not be symmetric since the local gateway lookup element should contain the local IP at each site. After the lookup process is done, both Gateways connect directly as usual. SecurityOn Multiple Site topologies, securing grid components and spaces is done as described in GigaSpaces Security page. When using a secured environment it is required to provide security credentials for the Gateway components (Sink & Delegator). Providing the security credentials can be done in two ways:
Providing security credentials on deploymentThe following bean level properties should be set:
Providing security credentials in gateway component's pu.xmlSetting the security credentials is done using the "security" element in the "os-gateway" namespace: <os-gateway:delegator id="delegator" local-gateway-name="USA" gateway-lookups="gatewayLookups"> <os-gateway:delegations> <os-gateway:delegation target="FRANCE" /> </os-gateway:delegations> <os-gateway:security username="${security.username}" password="${security.password}" /> </os-gateway:delegator> <os-gateway:sink id="sink" local-gateway-name="USA" gateway-lookups="gatewayLookups" local-space-url="jini://*/*/usaSpace"> <os-gateway:sources> <os-gateway:source name="FRANCE" /> </os-gateway:sources> <os-gateway:security username="gs" password="1234" /> </os-gateway:sink> It is also possible to set a "com.gigaspaces.security.directory.UserDetails" implementation instead of using the username and password attributes: <bean id="userDetailsBean" class="com.gigaspaces.security.directory.User"> <constructor-arg> <value>${username}</value> </constructor-arg> <constructor-arg> <value>${password}</value> </constructor-arg> </bean> <os-gateway:delegator id="delegator" local-gateway-name="USA" gateway-lookups="gatewayLookups"> <os-gateway:delegations> <os-gateway:delegation target="FRANCE" /> </os-gateway:delegations> <os-gateway:security user-details="userDetailsBean" /> </os-gateway:delegator> <os-gateway:sink id="sink" local-gateway-name="USA" gateway-lookups="gatewayLookups" local-space-url="jini://*/*/usaSpace"> <os-gateway:sources> <os-gateway:source name="FRANCE" /> </os-gateway:sources> <os-gateway:security user-details="userDetailsBean" /> </os-gateway:sink> |
![]() |
GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence |