I tested AWS clustering in the last couple of days, and it is working without any code changes. Just need to provide the AWS connection parameters etc. in the clustering section. However, it won't work with ELB because we have to change the ELB component to read the proper AWS security group name from the loadbalancer.conf, and we also need to path the HazelcastGroupManagementAgent in the kernel. However, on AWS deployments, we should be using the AWS ELB, IMO.
Azeez 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 3320919blog: **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
