brooklyn-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From henev...@apache.org
Subject [3/5] incubator-brooklyn git commit: docs: extract high-availability to its own page
Date Mon, 02 Mar 2015 16:15:05 GMT
docs: extract high-availability to its own page

- Previously, it was a sub-section of the “persistence” page

Project: http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/commit/9debe451
Tree: http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/tree/9debe451
Diff: http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/diff/9debe451

Branch: refs/heads/master
Commit: 9debe451fa0e2f8ed05114c93d27adcf32f2d498
Parents: 7cb66d8
Author: Aled Sage <aled.sage@gmail.com>
Authored: Tue Feb 24 07:54:07 2015 +0000
Committer: Aled Sage <aled.sage@gmail.com>
Committed: Tue Feb 24 07:54:07 2015 +0000

----------------------------------------------------------------------
 docs/guide/ops/high-availability.md | 46 ++++++++++++++++++++++++++++++++
 docs/guide/ops/index.md             |  1 +
 docs/guide/ops/persistence/index.md | 46 --------------------------------
 3 files changed, 47 insertions(+), 46 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/9debe451/docs/guide/ops/high-availability.md
----------------------------------------------------------------------
diff --git a/docs/guide/ops/high-availability.md b/docs/guide/ops/high-availability.md
new file mode 100644
index 0000000..2a2e512
--- /dev/null
+++ b/docs/guide/ops/high-availability.md
@@ -0,0 +1,46 @@
+---
+title: High Availability
+layout: website-normal
+---
+
+Brooklyn will automatically run in HA mode if multiple Brooklyn instances are started
+pointing at the same persistence store.  One Brooklyn node (e.g. the first one started)
+is elected as HA master:  all *write operations* against Brooklyn entities, such as creating
+an application or invoking an effector, should be directed to the master.
+
+Once one node is running as `MASTER`, other nodes start in either `STANDBY` or `HOT_STANDBY`
mode:
+
+* In `STANDBY` mode, a Brooklyn instance will monitor the master and will be a candidate
+  to become `MASTER` should the master fail. Standby nodes do *not* attempt to rebind
+  until they are elected master, so the state of existing entities is not available at
+  the standby node.  However a standby server consumes very little resource until it is
+  promoted.
+  
+* In `HOT_STANDBY` mode, a Brooklyn instance will read and make available the live state
of
+  entities.  Thus a hot-standby node is available as a read-only copy.
+  As with the standby node, if a hot-standby node detects that the master fails,
+  it will be a candidate for promotion to master.
+
+To explicitly specify what HA mode a node should be in, the following CLI options are available
+for the parameter `--highAvailability`:
+
+* `disabled`: management node works in isolation; it will not cooperate with any other standby/master
nodes in management plane
+* `auto`: will look for other management nodes, and will allocate itself as standby or master
based on other nodes' states
+* `master`: will startup as master; if there is already a master then fails immediately
+* `standby`: will start up as lukewarm standby; if there is not already a master then fails
immediately
+* `hot_standby`: will start up as hot standby; if there is not already a master then fails
immediately
+
+The REST API offers live detection and control of the HA mode,
+including setting priority to control which nodes will be promoted on master failure:
+
+* `/server/ha/state`: Returns the HA state of a management node (GET),
+  or changes the state (POST)
+* `/server/ha/states`: Returns the HA states and detail for all nodes in a management plane
+* `/server/ha/priority`: Returns the HA node priority for MASTER failover (GET),
+  or sets that priority (POST)
+
+Note that when POSTing to a non-master server it is necessary to pass a `Brooklyn-Allow-Non-Master-Access:
true` header.
+For example, the following cURL command could be used to change the state of a `STANDBY`
node on `localhost:8082` to `HOT_STANDBY`:
+
+    curl -v -X POST -d mode=HOT_STANDBY -H "Brooklyn-Allow-Non-Master-Access: true" http://localhost:8082/v1/server/ha/state
+

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/9debe451/docs/guide/ops/index.md
----------------------------------------------------------------------
diff --git a/docs/guide/ops/index.md b/docs/guide/ops/index.md
index 3e6305a..6cfcb49 100644
--- a/docs/guide/ops/index.md
+++ b/docs/guide/ops/index.md
@@ -7,6 +7,7 @@ children:
 - brooklyn_properties.md
 - locations/
 - persistence/
+- high-availability.md
 - catalog/
 - logging.md
 ---

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/9debe451/docs/guide/ops/persistence/index.md
----------------------------------------------------------------------
diff --git a/docs/guide/ops/persistence/index.md b/docs/guide/ops/persistence/index.md
index cbb3112..26696aa 100644
--- a/docs/guide/ops/persistence/index.md
+++ b/docs/guide/ops/persistence/index.md
@@ -6,7 +6,6 @@ children:
 - { section: File-based Persistence }
 - { section: Object Store Persistence }
 - { section: Rebinding to State }
-- { section: High Availability }
 - { section: Writing Persistable Code }
 ---
 
@@ -202,51 +201,6 @@ instance. After fixing the entities, locations and/or policies, the Brooklyn
ins
 new persisted state can be copied and used to fix the production instance.
 
 
-High Availability
------------------
-
-Brooklyn will automatically run in HA mode if multiple Brooklyn instances are started
-pointing at the same persistence store.  One Brooklyn node (e.g. the first one started)
-is elected as HA master:  all *write operations* against Brooklyn entities, such as creating
-an application or invoking an effector, should be directed to the master.
-
-Once one node is running as `MASTER`, other nodes start in either `STANDBY` or `HOT_STANDBY`
mode:
-
-* In `STANDBY` mode, a Brooklyn instance will monitor the master and will be a candidate
-  to become `MASTER` should the master fail. Standby nodes do *not* attempt to rebind
-  until they are elected master, so the state of existing entities is not available at
-  the standby node.  However a standby server consumes very little resource until it is
-  promoted.
-  
-* In `HOT_STANDBY` mode, a Brooklyn instance will read and make available the live state
of
-  entities.  Thus a hot-standby node is available as a read-only copy.
-  As with the standby node, if a hot-standby node detects that the master fails,
-  it will be a candidate for promotion to master.
-
-To explicitly specify what HA mode a node should be in, the following CLI options are available
-for the parameter `--highAvailability`:
-
-* `disabled`: management node works in isolation; it will not cooperate with any other standby/master
nodes in management plane
-* `auto`: will look for other management nodes, and will allocate itself as standby or master
based on other nodes' states
-* `master`: will startup as master; if there is already a master then fails immediately
-* `standby`: will start up as lukewarm standby; if there is not already a master then fails
immediately
-* `hot_standby`: will start up as hot standby; if there is not already a master then fails
immediately
-
-The REST API offers live detection and control of the HA mode,
-including setting priority to control which nodes will be promoted on master failure:
-
-* `/server/ha/state`: Returns the HA state of a management node (GET),
-  or changes the state (POST)
-* `/server/ha/states`: Returns the HA states and detail for all nodes in a management plane
-* `/server/ha/priority`: Returns the HA node priority for MASTER failover (GET),
-  or sets that priority (POST)
-
-Note that when POSTing to a non-master server it is necessary to pass a `Brooklyn-Allow-Non-Master-Access:
true` header.
-For example, the following cURL command could be used to change the state of a `STANDBY`
node on `localhost:8082` to `HOT_STANDBY`:
-
-    curl -v -X POST -d mode=HOT_STANDBY -H "Brooklyn-Allow-Non-Master-Access: true" http://localhost:8082/v1/server/ha/state
-
-
 Writing Persistable Code
 ------------------------
 The most common problem on rebind is that custom entity code has not been written in a way


Mime
View raw message