[jbossdeveloper] Ticket Monster session replication

Rafael Benevides benevides at redhat.com
Tue Mar 3 10:32:48 EST 2015


Awesome tip.

Thanks Vineet. I'll start to evaluate all possible solutions today!

On 3/3/15 10:30, Vineet Reynolds Pereira wrote:
>
> ----- Original Message -----
>> From: "Rafael Benevides" <benevides at redhat.com>
>> To: "Vineet Reynolds Pereira" <vpereira at redhat.com>
>> Cc: jbossdeveloper at lists.jboss.org
>> Sent: Tuesday, March 3, 2015 1:44:39 AM
>> Subject: Re: Ticket Monster session replication
>>
>> Cool,
>>
>> At this moment I'm preparing the docker images to them update it to be
>> orchestrated through Kubernetes.
>>
>> I'm using 4 images for the demo:
>>
>> - DB: Postgres
>> - Webserver: Apache + modcluster
>> - Widlfy domain
>> - n wildfly servers
>>
>> I'm facing some issues with the DB internal ip change (when db container
>> is restarted) but I believe that Kubernetes services can solve this.
> A DNS based service discovery helps here. Check out SkyDock (https://github.com/crosbymichael/skydock) and Consul (https://www.consul.io/).
>
> There is also an ambassador pattern for this use case, but it does not solve the problem if you link the client to the ambassador; it is there just to prevent restarting the client when the client to the service (db in this case) goes down. The pattern is documented @ https://docs.docker.com/articles/ambassador_pattern_linking/
>
>> I'll keep you informed
>>
>> On 3/2/15 05:04, Vineet Reynolds Pereira wrote:
>>> ----- Original Message -----
>>>> From: "Rafael Benevides" <benevides at redhat.com>
>>>> To: "Vineet Reynolds Pereira" <vpereira at redhat.com>
>>>> Cc: jbossdeveloper at lists.jboss.org
>>>> Sent: Friday, February 27, 2015 9:26:59 PM
>>>> Subject: Re: Ticket Monster session replication
>>>>
>>>> " I am working on demonstrating scaling of TicketMonster using a
>>>> Kubernetes+WildFly+(MySQL/Postgres)+HAProxy"
>>>>
>>>> Me too :)
>>>>
>>>> Let's chat about this when you have a chance.
>>> Anytime will do. Let's use IRC or Google Hangouts.
>>>
>>> For the record, I've gotten a sample clustering app to work on a WildFly
>>> cluster running on Kubernetes, using the help of this article:
>>> http://mluksa.blogspot.in/2015/01/deploying-wildfly-cluster-on-openshift_7.html
>>>
>>> I dont intend to use OpenShift yet, because of one outstanding issue
>>> involving Kubernetes - autoregistering changes in the cluster with an
>>> upstream loadbalancer. You wouldn't run into this issue with OpenShift and
>>> other cloud platforms like GCE that use Kubernetes, since the load
>>> balancers on such platforms would be informed of changes to the cluster.
>>> But with Kubernetes alone, this becomes an issue, since you need to hand
>>> rig code to add or remove IP routes to Docker instances from the upstream
>>> load balancer.
>>>
>>> There are a few ways to solve this:
>>>
>>> * For a very small and static cluster configuration, manually register the
>>> IP addresses of the cluster with HAProxy or nginx. This approach obviously
>>> doesn't scale since it is manual for the most part.
>>> * Automate the registration and discovery process for the load balancer. To
>>> do this, use etcd (the distributed key-value store in k8s) to store
>>> changes to the infrastructure. Read them in the upstream load balancer;
>>> assuming nginx, you can use nginx in conjunction with confd. As an
>>> example, refer:
>>> http://brianketelsen.com/2014/02/25/using-nginx-confd-and-docker-for-zero-downtime-web-updates/
>>> * Or look at something more sophisticated like vulcand. vulcand is not
>>> considered production-ready by most people. But that looks to be the
>>> future. As an example refer:
>>> http://www.recorditblog.com/post/how-to-create-a-web-scale-infrastructure-based-on-docker-coreos-vulcand-and-mesos-and-why-object-storage-becomes-the-de-facto-data-repository/
>>>
>>> I'm evaluating points 2 and 3 wrt TicketMonster. I may eventually look at
>>> Ceph (as an object storage platform) in the context of vulcand, but that
>>> is not a priority for me at the moment.
>>>
>>>> On 2/27/15 10:54, Vineet Reynolds Pereira wrote:
>>>>> Hi Rafael,
>>>>>
>>>>>       I believe it should be, when you use MySQL or PostgreSQL as the
>>>>>       database. Avoid H2 (the default DB) since each DB instance would not
>>>>>       be shared across EAP instances. I'll verify whether the proposed
>>>>>       config works flawlessly over the weekend, as I am working on
>>>>>       demonstrating scaling of TicketMonster using a
>>>>>       Kubernetes+WildFly+(MySQL/Postgres)+HAProxy.
>>>>>
>>>>> Vineet
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Rafael Benevides" <benevides at redhat.com>
>>>>>> To: "Vineet Reynolds Pereira" <vpereira at redhat.com>,
>>>>>> jbossdeveloper at lists.jboss.org
>>>>>> Sent: Friday, February 27, 2015 8:16:29 PM
>>>>>> Subject: Ticket Monster session replication
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I'm preparing a presentation demo using Ticket Monster and I'd like to
>>>>>> demonstrate a  failover cluster.
>>>>>>
>>>>>> Is TM capable of session replication ? I mean: Did someone already
>>>>>> tested if enabling it through <distributable /> element would be
>>>>>> sufficient for TM without any other source code modification ?
>>>>>>
>>>>>> --
>>>>>>
>>>>>> *Rafael Benevides | Senior Software Engineer*
>>>>>> JBoss Developer
>>>>>> M: +1-919-592-6255
>>>>>>
>>>>>> Red Hat
>>>>>>
>>>>>> Better technology. Faster innovation. Powered by community
>>>>>> collaboration.
>>>>>> See how it works at www.redhat.com <http://www.redhat.com/>
>>>>>>
>>>>>> LinkedIn <http://www.linkedin.com/company/3258288> Youtube
>>>>>> <https://www.youtube.com/redhatlatam>
>>>>>>
>>



More information about the jbossdeveloper mailing list