x/tatu
Code Issues Proposed changes

Alternative Bastion redundancy using DNS load-balancing.

Browse Source
This commit is contained in:
Pino de Candia 2017-10-10 17:20:00 -05:00 committed by GitHub
parent 12e4d61620
commit afe0db49c4
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/source/architecture.rst
View File

@ -61,7 +61,7 @@ Bastion
The coordinator restarts bastions that fail (reside on failing hosts). The check is only done periodically (on the order of a few minutes). In the future, the bastion should offer a meaningful health check and a fast-failure detection and recovery.
Depending on the size of the project (number of Users and instances, amount of data to transfer over SSH) it may be useful for the Bastion (with a single public IP) to be composed of multiple virtual bastions. This requires sticky load-balancing (á la Maglev [3]) to work properly, otherwise upstream routing changes would break SSH connections. For now, each bastion is implemented as a single VM or container.
Depending on the size of the project (number of Users and instances, amount of data to transfer over SSH) it may be useful for the Bastion (with a single public IP) to be composed of multiple virtual bastions. This requires sticky load-balancing (á la Maglev [3]) to work properly, otherwise upstream routing changes would break SSH connections. Alternatively, use multiple public IPs per project and use DNS load-balancing to route your SSH connection. For now, each bastion is implemented as a single VM or container.
References
----------