diff options
| author | Scott Konzem <konzems@gmail.com> | 2015-06-05 11:35:17 -0400 |
|---|---|---|
| committer | Scott Konzem <konzems@gmail.com> | 2015-06-05 11:35:17 -0400 |
| commit | a4e70adc69cdcafe328666420f941c995c233173 (patch) | |
| tree | df74f6639a4cbaea6a24d1567cbdf5f7673cd555 | |
| parent | f21879b3d766d7c89983e429f3ee068bf73854d5 (diff) | |
Fix misspellings in documentation
| -rw-r--r-- | high-availability.md | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/high-availability.md b/high-availability.md index 909903a2..f8d88e6b 100644 --- a/high-availability.md +++ b/high-availability.md @@ -4,7 +4,7 @@ This document serves as a proposal for high availability of the scheduler and co ## Design Options For complete reference see [this](https://www.ibm.com/developerworks/community/blogs/RohitShetty/entry/high_availability_cold_warm_hot?lang=en) -1. Hot Standby: In this scenario, data and state are shared between the two components such that an immediate failure in one component causes the the standby deamon to take over exactly where the failed component had left off. This would be an ideal solution for kubernetes, however it poses a series of challenges in the case of controllers where component-state is cached locally and not persisted in a transactional way to a storage facility. This would also introduce additional load on the apiserver, which is not desireable. As a result, we are **NOT** planning on this approach at this time. +1. Hot Standby: In this scenario, data and state are shared between the two components such that an immediate failure in one component causes the the standby deamon to take over exactly where the failed component had left off. This would be an ideal solution for kubernetes, however it poses a series of challenges in the case of controllers where component-state is cached locally and not persisted in a transactional way to a storage facility. This would also introduce additional load on the apiserver, which is not desirable. As a result, we are **NOT** planning on this approach at this time. 2. **Warm Standby**: In this scenario there is only one active component acting as the master and additional components running but not providing service or responding to requests. Data and state are not shared between the active and standby components. When a failure occurs, the standby component that becomes the master must determine the current state of the system before resuming functionality. This is the apprach that this proposal will leverage. |