nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From alopresto <...@git.apache.org>
Subject [GitHub] nifi pull request #491: NIFI-1960: Update admin guide regarding documentatio...
Date Fri, 03 Jun 2016 18:09:33 GMT
Github user alopresto commented on a diff in the pull request:

    https://github.com/apache/nifi/pull/491#discussion_r65751497
  
    --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
    @@ -485,98 +485,137 @@ It is preferable to request upstream/downstream systems to switch
to https://cwi
     Clustering Configuration
     ------------------------
     
    -This section provides a quick overview of NiFi Clustering and instructions on how to
set up a basic cluster. In the future, we hope to provide supplemental documentation that
covers the NiFi Cluster Architecture in depth.
    -
    -The design of NiFi clustering is a simple master/slave model where there is a master
and one or more slaves.
    -While the model is that of master and slave, if the master dies, the slaves are all instructed
to continue operating
    -as they were to ensure the dataflow remains live. The absence of the master simply means
new slaves cannot join the
    -cluster and cluster flow changes cannot occur until the master is restored. In NiFi clustering,
we call the master
    -the NiFi Cluster Manager (NCM), and the slaves are called Nodes. See a full description
of each in the Terminology section below.
    +This section provides a quick overview of NiFi Clustering and instructions on how to
set up a basic cluster.
    +In the future, we hope to provide supplemental documentation that covers the NiFi Cluster
Architecture in depth.
    +
    +NiFi employs a Zero-Master Clustering paradigm. Each of the nodes in the cluster performs
the same tasks on
    +the data but each operates on a different set of data. One of the nodes is automatically
elected (via Apache
    +ZooKeeper) as the Cluster Coordinator. All nodes in the cluster will then send heartbeat/status
information
    +to this node, and this node is responsible for disconnecting nodes that do not report
any heartbeat status
    +for some amount of time. Additionally, when a new node elects to join the cluster, the
new node must first
    +connect to the currently-elected Cluster Coordinator in order to obtain the most up-to-date
flow. If the Cluster
    +Coordinator determines that the node is allowed to join (based on its configured Firewall
file), the current
    --- End diff --
    
    Where is the Firewall file? Is this a Zookeeper thing or a new NiFi thing?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message