Nigel, The advantage of using a cluster is that whenever you change something in the UI, it will be changed on all nodes, and you also get a central view of the metrics/stats across all nodes. If you use standalone nodes you would have to go to each node and make the same changes.
It sounds like you are probably doing automatic deployments of a flow that you setup else where and aren't planning to ever modify the production nodes so maybe the above is a non-issue for you. The rolling deployment scenario depends on whether you are updating the flow, or just code. For example, if you are just updating code then you should be able to do a rolling deployment in a cluster, but if you are updating the flow then I don't think it will work because the a node will come up with the new flow and attempt to join the cluster, and the cluster won't accept it because the flow is different. Hope that helps. -Bryan On Fri, Dec 9, 2016 at 9:33 AM, Caton, Nigel <[email protected]> wrote: > Are there any views of the pros/cons of running a native NiFi cluster > versus a cluster of standalone NiFi nodes (managed by puppet/chef etc to > ensure they are configured consistently) fronted by software load > balancer(s). It is assumed the entry point to the graph will be an http > listener. > > Thoughts that spring to mind are it may be simpler to achieve canary and > rolling deployments of graph/processor changes with a set of standalone > NiFi instances behind a load balancer. > > Many Thanks, > > Nigel > > CGI IT UK Limited. A CGI Group Inc. Company > Registered Office: 250 Brook Drive, Green Park, Reading RG2 6UA, United > Kingdom. Registered in England & Wales - Number 947968 > >
