3 Replies Latest reply on Jan 11, 2013 11:11 AM by deesteel

    Minimum hardware requirements for a live deployment


      I've started with the Jive 6 documentation it suggests that you should have 2 web nodes :

      Hardware Requirements


      And it gives the reasoning behind 2 nodes as HA failover and load balancing.

      But it doesn't say anything about whether you should / can run 2 nodes for the other components like search, activity engine, cache, doc conversion.

      Even Deployment Sizing and Capacity Planning shows all the other back end services as being a single server. So why would you bother making the front end resilient if you've got another 4 back end servers that aren't resilient? Your solution is only as safe as it's least reliable component!


      Would there be any reason not to start with only one web node? We're only going to have a few hundred users in the initial deployment.


      What happens if we discover that our users have a particular usage pattern that, for example, results in massive amounts of searching in a huge backlog of data and the search server gets overloaded? Or maybe document conversion with a similar overload. Can we cluster back end nodes somehow?


      Our problem is that this is a completely new deployment providing a new service (that isn't a typical social network) and we will be developing a custom app to deliver it. So far, we don't even know how often or much data will be in the average post. It could be a few KB or a few MB (with attachments) so predicting the load is virtually impossible. But it would be nice to know what we will need to do if we hit a limit.




          • Re: Minimum hardware requirements for a live deployment

            Those links reference versions 3 and 5. We're using 6. And they mostly cover the information I already linked to.


            It still doesn't really explain why it's important to have an HA front end web server with a back end that is not resilient.

            Or why you need multiple web servers to handle the load but only ever need one of each back end server.


            I can't find anything that explains how to cluster the back end nodes. Or if it's even possible.

              • Re: Minimum hardware requirements for a live deployment

                Hi Max,


                I've done the architecture on a Jive 6 on-premise environment. If you think about the services that an on-premise environment has it really breaks down to this:


                • Database
                • Jive httpd and application
                • Cache/Cluster service
                • Document Conversion service
                • Activity Engine service
                • Search Service


                The database server should be part of an HA environment. The Jive application connects to the database and handles the load of your user base, so there should be 2 or more of these servers depending on the number of users, pageviews, etc.


                Clustering service can be made HA, but you need 3 or more boxes if you do so. I decided to have only 1. You can have multiple document conversion nodes, but each acts independently, but in reality you only need 1. The search service is just setup to essentially contain the full-text index and offload processing to that box. I don't believe you can set that up in a cluster, but honestly haven't dived too deeply into it. If the search server goes down, all that happens is you have to spin the service up on another machine, and rebuild the index. You can have multiple activity engine servers and break down their roles to doing either inout, in, or out servicing.


                What I did to make sure there wasn't massive disruption in service should the cache/cluster node, activity engine, or search services go down, or If I need any additional application node from the 3 that I have clustered; was to build a separate box with all the services installed, and have config ready and documented to quickly place that box into the lineup should a failure exist.


                There are many aspects into making this design work, but my constraints were budget related and my customers were internal non-customer facing users. If I were architecting for a customer facing on-premise solution and budget wasn't an issue, I would have done it slightly different.


                Please keep in mind, these are just my opinions and not something that I got from Jive.


                Hope that helps.