Dynamic discovery happens after the static nodes are added, and the static nodes being available is crucial for the cluster to work.
On Sat, Aug 2, 2014 at 11:04 AM, Nirmal Fernando <[email protected]> wrote: > Hi Azeez, > > Thanks for the replies. Sorry, if I misunderstood the Hazelcast > TcpIpJoiner, but I did following test on Hazelcast tcp/ip [1] and it seems > each node discovers every other dynamically [2]. My Hazelcast.xml file is > [3]. Does my test case incorrect? Appreciate your thoughts. > > [1] > > public static void main(String[] args) { > System.setProperty("hazelcast.config", > "src/main/resources/hazelcast.xml"); > // Build Hazelcast cluster > System.out.println("Starting instance 1"); > HazelcastInstance h1 = Hazelcast.newHazelcastInstance(); > System.out.println("Starting instance 2"); > HazelcastInstance h2 = Hazelcast.newHazelcastInstance(); > > IMap<String, String> map1 = h1.getMap("map"); > map1.put("nirmal", "fernando"); > > IMap<String, String> map2 = h2.getMap("map"); > System.out.println("from h2: " + map2.get("nirmal")); > map2.set("nirmal", "fdo"); > System.out.println("from h1: " + map1.get("nirm")); > > HazelcastInstance h3 = Hazelcast.newHazelcastInstance(); > System.out.println(h1.getCluster().getMembers().size()); > System.out.println(h2.getCluster().getMembers().size()); > System.out.println(h3.getCluster().getMembers().size()); > System.exit(0); > } > > [2] > > ..... > > Members [3] { > Member [127.0.0.1]:5701 this > Member [127.0.0.1]:5702 > Member [127.0.0.1]:5703 > } > > Aug 2, 2014 10:59:17 AM com.hazelcast.cluster.ClusterService > INFO: [127.0.0.1]:5703 [dev] > > Members [3] { > Member [127.0.0.1]:5701 > Member [127.0.0.1]:5702 > Member [127.0.0.1]:5703 this > } > > Aug 2, 2014 10:59:17 AM com.hazelcast.cluster.ClusterService > INFO: [127.0.0.1]:5702 [dev] > > Members [3] { > Member [127.0.0.1]:5701 > Member [127.0.0.1]:5702 this > Member [127.0.0.1]:5703 > } > > Aug 2, 2014 10:59:17 AM com.hazelcast.partition.PartitionService > INFO: [127.0.0.1]:5701 [dev] Re-partitioning cluster data... Migration > queue size: 90 > Aug 2, 2014 10:59:19 AM com.hazelcast.core.LifecycleService > INFO: [127.0.0.1]:5703 [dev] Address[127.0.0.1]:5703 is STARTED > 3 > 3 > 3 > > [3] > > <hazelcast xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://www.hazelcast.com/schema/config > http://www.hazelcast.com/schema/config/hazelcast-config-3.2.xsd"; > xmlns="http://www.hazelcast.com/schema/config";> > <network> > <join> > <tcp-ip enabled="true"> > <member>127.0.0.1</member> > </tcp-ip> > </join> > </network> > > </hazelcast> > > > > > On Sat, Aug 2, 2014 at 10:25 AM, Afkham Azeez <[email protected]> wrote: > >> Anyway, there is a catch here. The membership scheme uses TCP/IP >> underneath, and adds the members it sees as static members. But when all >> the members each node added fails, that node has to be restarted. So, when >> the cluster if formed, node 1 will not have any WK members; node 2 will >> have 1 WK member, node 3 will have 2 and so on. So if node 1 fails, node 2 >> also fails, if nodes 1 & 2 fail, node 3 also fails. >> >> >> On Sat, Aug 2, 2014 at 10:10 AM, Nirmal Fernando <[email protected]> wrote: >> >>> Hi All, >>> >>> In a Cloud environment, it's not ideal to mark one or more WKA members >>> since it brings lot of challenges such as; >>> >>> 1. Keeping WKA members up and running always >>> 2. If they got destroyed spin up replacement WKA members and respawn the >>> whole cluster. >>> etc. >>> >>> These could possibly lead to lot of instability to the cluster and in >>> turn affect the sole purpose of clustering. >>> >>> According to [1] and also to the Hazelcast book, Hazelcast has a >>> solution to this problem for AWS EC2. Here I quote [1]. >>> >>> >>> >>> >>> >>> *Hazelcast either uses Multicast or TCP/IP for discovery, but EC2 does >>> not support multicast. To configure discovery using TCP/IP, you need the IP >>> addresses upfront and this is not always possible. To solve this problem, >>> Hazelcast supports EC2 auto discovery which is a layer on top ofTCP/IP >>> discovery. EC2 auto discovery uses AWS API to get the IP addresses of >>> possible Hazelcast nodes and feeds those IP addresses to TCP/IP discovery. >>> This way the discovery process becomes dynamic and it eliminates a need for >>> knowing the IP addresses upfront. To limit theIP addresses only to >>> Hazelcast related nodes, EC2 discovery supports filtering based on security >>> group and/or tags.* >>> >>> Current idea is to use tags to specify the cluster domain and need to >>> research more and come up with a design. Further, we could leverage >>> Hazelcast's partition groups to support HA across Availability zones. >>> >>> Also, if this is only for EC2, that would not be much useful. But >>> Hazelcast seems to have an extension point to support other Clouds via >>> JClouds. >>> >>> >>> >>> >>> *In case you are using a different cloud provider than Amazon EC2, you >>> can still make use of Hazelcast. What you can do it to use the programmatic >>> api toconfigure a tcp-ip cluster and the well known members need to be >>> retrieved fromyour cloud provider (e.g. using jclouds).* >>> >>> In addition to this, at [1] Hazelcast describes some best practices to >>> use in AWS EC2 Cloud. And I think we could leverage these in many of the >>> real world deployments. >>> >>> I hope it's feasible to port this support to Carbon Clustering and I'd >>> like to work on it. Let me know your thoughts. >>> >>> [1] http://hazelcast.com/resources/amazon-ec2-deployment-guide/ >>> >>> -- >>> >>> Thanks & regards, >>> Nirmal >>> >>> Senior Software Engineer- Platform Technologies Team, WSO2 Inc. >>> Mobile: +94715779733 >>> Blog: http://nirmalfdo.blogspot.com/ >>> >>> >>> >> >> >> -- >> *Afkham Azeez* >> Director of Architecture; WSO2, Inc.; http://wso2.com >> Member; Apache Software Foundation; http://www.apache.org/ >> * <http://www.apache.org/>* >> *email: **[email protected]* <[email protected]> >> * cell: +94 77 3320919 <%2B94%2077%203320919> blog: * >> *http://blog.afkham.org* <http://blog.afkham.org> >> *twitter: **http://twitter.com/afkham_azeez* >> <http://twitter.com/afkham_azeez> >> * linked-in: **http://lk.linkedin.com/in/afkhamazeez >> <http://lk.linkedin.com/in/afkhamazeez>* >> >> *Lean . Enterprise . Middleware* >> > > > > -- > > Thanks & regards, > Nirmal > > Senior Software Engineer- Platform Technologies Team, WSO2 Inc. > Mobile: +94715779733 > Blog: http://nirmalfdo.blogspot.com/ > > > -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * <http://www.apache.org/>* *email: **[email protected]* <[email protected]> * cell: +94 77 3320919 blog: **http://blog.afkham.org* <http://blog.afkham.org> *twitter: **http://twitter.com/afkham_azeez* <http://twitter.com/afkham_azeez> * linked-in: **http://lk.linkedin.com/in/afkhamazeez <http://lk.linkedin.com/in/afkhamazeez>* *Lean . Enterprise . Middleware*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
