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 <[email protected]> Authored: Tue Feb 24 07:54:07 2015 +0000 Committer: Aled Sage <[email protected]> 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
