You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@brooklyn.apache.org by he...@apache.org on 2015/03/02 17:15:05 UTC
[3/5] incubator-brooklyn git commit: docs: extract high-availability
to its own page
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 <al...@gmail.com>
Authored: Tue Feb 24 07:54:07 2015 +0000
Committer: Aled Sage <al...@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