If you're running 2 nodes with a replication factor of 1, and one node
fails, then half of the queries you make to Cassandra (reads and
writes) will fail, and half will succeed.
If you're running 2 nodes with a replication factor of 2, and one node
fails, then all queries you make to Cassandra will fail ("full cluster
failure").
If you're running 3 nodes with a replication factor of 3, and one node
fails, the Cassandra cluster continues to operate successfully.
I highly recommend having an understanding of Cassandra replication
[1] and consistency [2] if you are venturing towards running OAE in
production.
Thanks,
Branden
[1] http://www.datastax.com/docs/1.0/cluster_architecture/replication
[2] http://www.datastax.com/docs/1.0/dml/data_consistency#tunable-consistency
On Fri, Nov 22, 2013 at 5:56 AM, Kabelo Letsoalo
<kab...@opencollab.co.za> wrote:
> Thanks Branden.
>
> This question is in the context of a 2-node setup.
>
> Does full cluster failure mean the one node left will continue operating
> without replication or cassandra as a whole will fail (along with the
> healthy node)?
>
> Thanks alot!
>
>
> On 22 November 2013 12:38, Branden Visser <mrvis...@gmail.com> wrote:
>>
>> Hi Kabelo, glad you got it up and running! You should add all
>> available cassandra nodes to the list of cassandra hosts. This avoids
>> a single point of failure.
>>
>> In general, it's recommended that your smallest setup be 3 cassandra
>> nodes and a "replication factor" of 3. This allows for one node to
>> fail and still retain availability. Any setup smaller than this will
>> result in a full cluster failure if one node goes down.
>>
>> Cheers,
>> Branden
>>
>> On Fri, Nov 22, 2013 at 5:18 AM, Kabelo Letsoalo
>> <kab...@opencollab.co.za> wrote:
>> > Hello.
>> >
>> > The Hilary cluster setup is a breeze. nicely done.
>> >
>> > I'm unsure about config.cassandra in Hilary/config.js. I setup a
>> > cassandra
>> > node on another server and run it in a cluster with the cassandra node
>> > running on the same server as the application server/Hilary.
>> >
>> > Even with the cassandra cluster and its replication setup done, do I
>> > still
>> > need to add the remote server (server not running on same server as
>> > Hilary)
>> > to the config.cassandra.hosts list?
>> >
>> > Thanks for the help!
>> >
>> >
>> > On 15 November 2013 14:18, Branden Visser <mrvis...@gmail.com> wrote:
>> >>
>> >> Hi Kabelo,
>> >>
>> >> We don't have formal detailed documentation on this, however there are
>> >> bootcamp slides available which give a high-level overview of a
>> >> clustered application setup [1].
>> >>
>> >> For all components other than Hilary, I would recommend becoming
>> >> familiar with their own clustering abilities and reference their
>> >> documentation for setup.
>> >>
>> >> For Hilary, it's important to note the "specialization" of Hilary
>> >> nodes into one or more of the following roles:
>> >>
>> >> 1. Application Request Handler
>> >> 2. Activity Processor
>> >> 3. Search Indexer
>> >> 4. Preview Processor
>> >>
>> >> For #1, you'll see that Nginx proxies web requests to the application
>> >> nodes. You simply need to configure Nginx appropriately to use all
>> >> your application request handler nodes into the backend pools in
>> >> Nginx. Every Hilary node will always be prepared to handle web
>> >> requests after startup.
>> >>
>> >> For #2-4, they receive their requests through RabbitMQ messages, so as
>> >> long as they are configured to talk to RabbitMQ (config.mq in
>> >> config.js), they are capable of being distributed and handling these
>> >> tasks. Therefore, in order to deploy a specialized node, you simply
>> >> need to configure its RabbitMQ connection (*all* Hilary nodes should
>> >> have this configured any way), and enable / disable the type of work
>> >> you would like that node to handle in config.js:
>> >>
>> >> 2. Set "config.search.processIndexJobs" to true to indicate the node
>> >> should subscribe to search indexing tasks
>> >> 3. Set "config.activity.processActivityJobs" to true to indicate the
>> >> node should subscribe to activity routing tasks and to aggregate
>> >> activity
>> >> 4. Set "config.previews.enabled" to true to indicate the node should
>> >> subscribe to preview processing tasks
>> >>
>> >> Note that our puppet scripts for deploying and configuring Hilary
>> >> clusters are available [2]. Feel free to look into those to get
>> >> specific configuration templates for setting up an OAE cluster.
>> >>
>> >> Hope that helps,
>> >> Branden
>> >>
>> >> [1] http://www.slideshare.net/nicolaasmatthijs/apereo-oae-bootcamp
>> >> (Slide
>> >> #18)
>> >> [2] https://github.com/oaeproject/puppet-hilary
>> >>
>> >> On Fri, Nov 15, 2013 at 6:19 AM, Kabelo Letsoalo
>> >> <kab...@opencollab.co.za> wrote:
>> >> > Hi all. where can I find documentation for OAE 2.0.0 cluster setup
>> >> > and/or
>> >> > running multiple instances?
>> >> >
>> >> > ________________________________
>> >> > See OpenCollab email disclaimer at
>> >> > http://www.opencollab.co.za/email-disclaimer
>> >> > _______________________________________________
>> >> > oae-dev mailing list
>> >> > oae-dev@collab.sakaiproject.org
>> >> > http://collab.sakaiproject.org/mailman/listinfo/oae-dev
>> >> >
>> >
>> >
>> >
>> > ________________________________
>> > See OpenCollab email disclaimer at
>> > http://www.opencollab.co.za/email-disclaimer
>
>
>
> ________________________________
> See OpenCollab email disclaimer at
> http://www.opencollab.co.za/email-disclaimer
_______________________________________________
oae-dev mailing list
oae-dev@collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/oae-dev
