aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAlex Auvolat <alex@adnab.me>2022-03-17 17:21:17 +0100
committerAlex Auvolat <alex@adnab.me>2022-03-17 17:21:17 +0100
commit6c978fff810b8a1661871beabb9521fef2d929d3 (patch)
tree22bf05b3358f64114345c03c8966d63874f9c165
parent0529f3c34dee78f54dbd3a384120f9b3bacb9501 (diff)
downloadgarage-feature/improve-doc.tar.gz
garage-feature/improve-doc.zip
Talk a bit about capacity balancing between regionsfeature/improve-doc
-rw-r--r--doc/book/cookbook/real-world.md29
1 files changed, 18 insertions, 11 deletions
diff --git a/doc/book/cookbook/real-world.md b/doc/book/cookbook/real-world.md
index 1178ded5..ee94697c 100644
--- a/doc/book/cookbook/real-world.md
+++ b/doc/book/cookbook/real-world.md
@@ -23,7 +23,7 @@ To run a real-world deployment, make sure the following conditions are met:
- Ideally, each machine should have a SSD available in addition to the HDD you are dedicating
to Garage. This will allow for faster access to metadata and has the potential
- to drastically reduce Garage's response times.
+ to significantly reduce Garage's response times.
- This guide will assume you are using Docker containers to deploy Garage on each node.
Garage can also be run independently, for instance as a [Systemd service](@/documentation/cookbook/systemd.md).
@@ -35,12 +35,19 @@ For our example, we will suppose the following infrastructure with IPv6 connecti
| Location | Name | IP Address | Disk Space |
|----------|---------|------------|------------|
-| Paris | Mercury | fc00:1::1 | 1 To |
-| Paris | Venus | fc00:1::2 | 2 To |
-| London | Earth | fc00:B::1 | 2 To |
-| Brussels | Mars | fc00:F::1 | 1.5 To |
-
-
+| Paris | Mercury | fc00:1::1 | 1 TB |
+| Paris | Venus | fc00:1::2 | 2 TB |
+| London | Earth | fc00:B::1 | 2 TB |
+| Brussels | Mars | fc00:F::1 | 1.5 TB |
+
+Note that Garage will **always** store the three copies of your data on nodes at different
+locations. This means that in the case of this small example, the available capacity
+of the cluster is in fact only 1.5 TB, because nodes in Brussels can't store more than that.
+This also means that nodes in Paris and London will be under-utilized.
+To make better use of the available hardware, you should ensure that the capacity
+available in the different locations of your cluster is roughly the same.
+For instance, here, the Mercury node could be moved to Brussels; this would allow the cluster
+to store 2 TB of data in total.
## Get a Docker image
@@ -208,10 +215,10 @@ For our example, we will suppose we have the following infrastructure
| Location | Name | Disk Space | `Capacity` | `Identifier` | `Zone` |
|----------|---------|------------|------------|--------------|--------------|
-| Paris | Mercury | 1 To | `10` | `563e` | `par1` |
-| Paris | Venus | 2 To | `20` | `86f0` | `par1` |
-| London | Earth | 2 To | `20` | `6814` | `lon1` |
-| Brussels | Mars | 1.5 To | `15` | `212f` | `bru1` |
+| Paris | Mercury | 1 TB | `10` | `563e` | `par1` |
+| Paris | Venus | 2 TB | `20` | `86f0` | `par1` |
+| London | Earth | 2 TB | `20` | `6814` | `lon1` |
+| Brussels | Mars | 1.5 TB | `15` | `212f` | `bru1` |
#### Node identifiers