mirror of
https://github.com/deuxfleurs-org/garage.git
synced 2026-07-26 07:58:14 +00:00
chore: a large number of typo corrections in markdown files
This commit is contained in:
Gwen Lg
@@ -51,4 +51,4 @@ We are currently building this SDK for [Python](@/documentation/build/python.md#
|
||||
|
||||
More information:
|
||||
- [In the reference manual](@/documentation/reference-manual/admin-api.md)
|
||||
- [Full specifiction](https://garagehq.deuxfleurs.fr/api/garage-admin-v0.html)
|
||||
- [Full specification](https://garagehq.deuxfleurs.fr/api/garage-admin-v0.html)
|
||||
|
||||
@@ -5,13 +5,13 @@ weight = 99
|
||||
|
||||
## S3
|
||||
|
||||
If you are developping a new application, you may want to use Garage to store your user's media.
|
||||
If you are developing a new application, you may want to use Garage to store your user's media.
|
||||
|
||||
The S3 API that Garage uses is a standard REST API, so as long as you can make HTTP requests,
|
||||
you can query it. You can check the [S3 REST API Reference](https://docs.aws.amazon.com/AmazonS3/latest/API/API_Operations_Amazon_Simple_Storage_Service.html) from Amazon to learn more.
|
||||
|
||||
Developping your own wrapper around the REST API is time consuming and complicated.
|
||||
Instead, there are some libraries already avalaible.
|
||||
Developing your own wrapper around the REST API is time consuming and complicated.
|
||||
Instead, there are some libraries already available.
|
||||
|
||||
Some of them are maintained by Amazon, some by Minio, others by the community.
|
||||
|
||||
|
||||
@@ -23,7 +23,7 @@ To configure S3-compatible software to interact with Garage,
|
||||
you will need the following parameters:
|
||||
|
||||
- An **API endpoint**: this corresponds to the HTTP or HTTPS address
|
||||
used to contact the Garage server. When runing Garage locally this will usually
|
||||
used to contact the Garage server. When running Garage locally this will usually
|
||||
be `http://127.0.0.1:3900`. In a real-world setting, you would usually have a reverse-proxy
|
||||
that adds TLS support and makes your Garage server available under a public hostname
|
||||
such as `https://garage.example.com`.
|
||||
|
||||
@@ -54,7 +54,7 @@ garage bucket allow nextcloud --read --write --key nextcloud-key
|
||||
|
||||
Now edit your Nextcloud configuration file to enable object storage.
|
||||
On my installation, the config. file is located at the following path: `/var/www/nextcloud/config/config.php`.
|
||||
We will add a new root key to the `$CONFIG` dictionnary named `objectstore`:
|
||||
We will add a new root key to the `$CONFIG` dictionary named `objectstore`:
|
||||
|
||||
```php
|
||||
<?php
|
||||
@@ -413,7 +413,7 @@ mc mirror --newer-than "3h" ./public/system/ garage/mastodon-data
|
||||
|
||||
## Matrix
|
||||
|
||||
Matrix is a chat communication protocol. Its main stable server implementation, [Synapse](https://matrix-org.github.io/synapse/latest/), provides a module to store media on a S3 backend. Additionally, a server independent media store supporting S3 has been developped by the community, it has been made possible thanks to how the matrix API has been designed and will work with implementations like Conduit, Dendrite, etc.
|
||||
Matrix is a chat communication protocol. Its main stable server implementation, [Synapse](https://matrix-org.github.io/synapse/latest/), provides a module to store media on a S3 backend. Additionally, a server independent media store supporting S3 has been developed by the community, it has been made possible thanks to how the matrix API has been designed and will work with implementations like Conduit, Dendrite, etc.
|
||||
|
||||
### synapse-s3-storage-provider (synapse only)
|
||||
|
||||
@@ -450,7 +450,7 @@ media_storage_providers:
|
||||
|
||||
Note that uploaded media will also be stored locally and this behavior can not be deactivated, it is even required for
|
||||
some operations like resizing images.
|
||||
In fact, your local filesysem is considered as a cache but without any automated way to garbage collect it.
|
||||
In fact, your local filesystem is considered as a cache but without any automated way to garbage collect it.
|
||||
|
||||
We can build our garbage collector with `s3_media_upload`, a tool provided with the module.
|
||||
If you installed the module with the command provided before, you should be able to bring it in your path:
|
||||
@@ -646,7 +646,7 @@ s3:
|
||||
b2-eu-cen: # Don't change this key, it is hardcoded
|
||||
key: <keyID>
|
||||
secret: <keySecret>
|
||||
endpoint: garage:3900 # publically accessible endpoint of your garage instance
|
||||
endpoint: garage:3900 # publicly accessible endpoint of your garage instance
|
||||
region: garage
|
||||
bucket: <yourbucketName>
|
||||
use_path_style: true
|
||||
@@ -730,7 +730,7 @@ Pleroma have an internal migration tool that can encounter some fatal error
|
||||
|
||||
So, use [your best tool](https://garagehq.deuxfleurs.fr/documentation/connect/cli/) to sync `/var/lib/pleroma/uploads/` in your S3.
|
||||
|
||||
Then, to avoid some non existant problem (just in case of), run this command
|
||||
Then, to avoid some non existent problem (just in case of), run this command
|
||||
|
||||
```bash
|
||||
while true
|
||||
|
||||
@@ -41,7 +41,7 @@ Some commands:
|
||||
# list buckets
|
||||
mc ls garage/
|
||||
|
||||
# list objets in a bucket
|
||||
# list objects in a bucket
|
||||
mc ls garage/my_files
|
||||
|
||||
# copy from your filesystem to garage
|
||||
@@ -218,7 +218,7 @@ Within Cyberduck, a
|
||||
available within the `Preferences -> Profiles` section. This can enabled and
|
||||
then connections to Garage may be configured.
|
||||
|
||||
### Instuctions for the CLI
|
||||
### Instructions for the CLI
|
||||
|
||||
To configure duck (Cyberduck's CLI tool), start by creating its folder hierarchy:
|
||||
|
||||
|
||||
@@ -201,11 +201,9 @@ on the binary cache, the client will download the result from the cache instead
|
||||
|
||||
### Channels
|
||||
|
||||
Channels additionnaly serve Nix definitions, ie. a `.nix` file referencing
|
||||
Channels additionally serve Nix definitions, ie. a `.nix` file referencing
|
||||
all the derivations you want to serve.
|
||||
|
||||
## Gitlab
|
||||
|
||||
*External link:* [Gitlab Documentation > Object storage](https://docs.gitlab.com/ee/administration/object_storage.html)
|
||||
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ have published Ansible roles. We list them and compare them below.
|
||||
| **Runtime** | Systemd | Docker | Systemd |
|
||||
| **Target OS** | Any Linux | Any Linux | Any Linux |
|
||||
| **Architecture** | amd64, arm64, i686 | amd64, arm64 | arm64, arm, 386, amd64 |
|
||||
| **Additional software** | None | Traefik | Ngnix and Keepalived (optional) |
|
||||
| **Additional software** | None | Traefik | Nginx and Keepalived (optional) |
|
||||
| **Automatic node connection** | ❌ | ✅ | ✅ |
|
||||
| **Layout management** | ❌ | ✅ | ✅ |
|
||||
| **Manage buckets & keys** | ❌ | ✅ (basic) | ✅ |
|
||||
|
||||
@@ -33,7 +33,7 @@ by adding encryption at different levels.
|
||||
|
||||
We would be very curious to know your needs and thougs about ideas such as
|
||||
encryption practices and things like key management, as we want Garage to be a
|
||||
serious base platform for the developpment of secure, encrypted applications.
|
||||
serious base platform for the development of secure, encrypted applications.
|
||||
Do not hesitate to come talk to us if you have any thoughts or questions on the
|
||||
subject.
|
||||
|
||||
@@ -59,7 +59,7 @@ For standard S3 API requests, Garage does not encrypt data at rest by itself.
|
||||
For the most generic at rest encryption of data, we recommend setting up your
|
||||
storage partitions on encrypted LUKS devices.
|
||||
|
||||
If you are developping your own client software that makes use of S3 storage,
|
||||
If you are developing your own client software that makes use of S3 storage,
|
||||
we recommend implementing data encryption directly on the client side and never
|
||||
transmitting plaintext data to Garage. This makes it easy to use an external
|
||||
untrusted storage provider if necessary.
|
||||
@@ -108,14 +108,14 @@ Protects against the following threats:
|
||||
|
||||
- Stolen HDD
|
||||
|
||||
Crucially, does not protect againt malicious sysadmins or remote attackers that
|
||||
Crucially, does not protect against malicious sysadmins or remote attackers that
|
||||
might gain access to your servers.
|
||||
|
||||
Methods include full-disk encryption with tools such as LUKS.
|
||||
|
||||
## Encrypting data on the client side
|
||||
|
||||
Protects againt the following threats:
|
||||
Protects against the following threats:
|
||||
|
||||
- A honest-but-curious administrator
|
||||
- A malicious administrator that tries to corrupt your data
|
||||
|
||||
@@ -9,7 +9,7 @@ There are three methods to expose buckets as website:
|
||||
|
||||
1. using the PutBucketWebsite S3 API call, which is allowed for access keys that have the owner permission bit set
|
||||
|
||||
2. from the Garage CLI, by an adminstrator of the cluster
|
||||
2. from the Garage CLI, by an administrator of the cluster
|
||||
|
||||
3. using the Garage administration API
|
||||
|
||||
|
||||
@@ -25,7 +25,7 @@ sudo apt-get install build-essential
|
||||
The primary location for Garage's source code is the
|
||||
[Forgejo repository](https://git.deuxfleurs.fr/Deuxfleurs/garage),
|
||||
which contains all of the released versions as well as the code
|
||||
for the developpement of the next version.
|
||||
for the development of the next version.
|
||||
|
||||
Clone the repository and enter it as follows:
|
||||
|
||||
@@ -41,7 +41,7 @@ git tag # List available tags
|
||||
git checkout v0.8.0 # Change v0.8.0 with the version you wish to build
|
||||
```
|
||||
|
||||
Otherwise you will be building a developpement build from the `main` branch
|
||||
Otherwise you will be building a development build from the `main` branch
|
||||
that includes all of the changes to be released in the next version.
|
||||
Be careful that such a build might be unstable or contain bugs,
|
||||
and could be incompatible with nodes that run stable versions of Garage.
|
||||
|
||||
@@ -47,7 +47,7 @@ All possible configuration values can be found with:
|
||||
helm show values ./garage
|
||||
```
|
||||
|
||||
This is an example `values.overrride.yaml` for deploying in a microk8s cluster with a https s3 api ingress route:
|
||||
This is an example `values.override.yaml` for deploying in a microk8s cluster with a https s3 api ingress route:
|
||||
|
||||
```yaml
|
||||
garage:
|
||||
|
||||
@@ -272,7 +272,7 @@ Add the following configuration section [to compress response](https://doc.traef
|
||||
|
||||
### Add caching response
|
||||
|
||||
Traefik's caching middleware is only available on [entreprise version](https://doc.traefik.io/traefik-enterprise/middlewares/http-cache/), however the freely-available [Souin plugin](https://github.com/darkweak/souin#tr%C3%A6fik-container) can also do the job. (section to be completed)
|
||||
Traefik's caching middleware is only available on [enterprise version](https://doc.traefik.io/traefik-enterprise/middlewares/http-cache/), however the freely-available [Souin plugin](https://github.com/darkweak/souin#tr%C3%A6fik-container) can also do the job. (section to be completed)
|
||||
|
||||
### Complete example
|
||||
|
||||
|
||||
@@ -38,7 +38,7 @@ WantedBy=multi-user.target
|
||||
id is dynamically allocated by systemd (set with `DynamicUser=true`). It cannot
|
||||
access (read or write) home folders (`/home`, `/root` and `/run/user`), the
|
||||
rest of the filesystem can only be read but not written, only the path seen as
|
||||
`/var/lib/garage` is writable as seen by the service. Additionnaly, the process
|
||||
`/var/lib/garage` is writable as seen by the service. Additionally, the process
|
||||
can not gain new privileges over time.
|
||||
|
||||
For this to work correctly, your `garage.toml` must be set with
|
||||
|
||||
@@ -10,7 +10,7 @@ perspective. It will allow you to understand if Garage is a good fit for
|
||||
you, how to better use it, how to contribute to it, what can Garage could
|
||||
and could not do, etc.
|
||||
|
||||
- **[Goals and use cases](@/documentation/design/goals.md):** This page explains why Garage was concieved and what practical use cases it targets.
|
||||
- **[Goals and use cases](@/documentation/design/goals.md):** This page explains why Garage was conceived and what practical use cases it targets.
|
||||
|
||||
- **[Related work](@/documentation/design/related-work.md):** This pages presents the theoretical background on which Garage is built, and describes other software storage solutions and why they didn't work for us.
|
||||
|
||||
@@ -31,5 +31,3 @@ We love to talk and hear about Garage, that's why we keep a log here:
|
||||
- [(en, 2021-04-28) Distributed object storage is centralised](https://git.deuxfleurs.fr/Deuxfleurs/garage/src/commit/b1f60579a13d3c5eba7f74b1775c84639ea9b51a/doc/talks/2021-04-28_spirals-team/talk.pdf)
|
||||
|
||||
- [(fr, 2020-12-02) Garage : jouer dans la cour des grands quand on est un hébergeur associatif](https://git.deuxfleurs.fr/Deuxfleurs/garage/src/commit/b1f60579a13d3c5eba7f74b1775c84639ea9b51a/doc/talks/2020-12-02_wide-team/talk.pdf)
|
||||
|
||||
|
||||
|
||||
@@ -15,14 +15,14 @@ The more a user request will require intra-cluster requests to complete, the mor
|
||||
This is especially true for sequential requests: requests that must wait the result of another request to be sent.
|
||||
We designed Garage without consensus algorithms (eg. Paxos or Raft) to minimize the number of sequential and parallel requests.
|
||||
|
||||
This serie of benchmarks quantifies the impact of this design choice.
|
||||
This series of benchmarks quantifies the impact of this design choice.
|
||||
|
||||
### On a simple simulated network
|
||||
|
||||
We start with a controlled environment, all the instances are running on the same (powerful enough) machine.
|
||||
|
||||
To control the network latency, we simulate the network with [mknet](https://git.deuxfleurs.fr/trinity-1686a/mknet) (a tool we developped, based on `tc` and the linux network stack).
|
||||
To mesure S3 endpoints latency, we use our own tool [s3lat](https://git.deuxfleurs.fr/quentin/s3lat/) to observe only the intra-cluster latency and not some contention on the nodes (CPU, RAM, disk I/O, network bandwidth, etc.).
|
||||
To control the network latency, we simulate the network with [mknet](https://git.deuxfleurs.fr/trinity-1686a/mknet) (a tool we developed, based on `tc` and the linux network stack).
|
||||
To measure S3 endpoints latency, we use our own tool [s3lat](https://git.deuxfleurs.fr/quentin/s3lat/) to observe only the intra-cluster latency and not some contention on the nodes (CPU, RAM, disk I/O, network bandwidth, etc.).
|
||||
Compared to other benchmark tools, S3Lat sends only one (small) request at the same time and measures its latency.
|
||||
We selected 5 standard endpoints that are often in the critical path: ListBuckets, ListObjects, GetObject, PutObject and RemoveObject.
|
||||
|
||||
@@ -32,7 +32,7 @@ In this first benchmark, we consider 5 instances that are located in a different
|
||||
|
||||
Compared to garage, minio latency drastically increases on 3 endpoints: GetObject, PutObject, RemoveObject.
|
||||
|
||||
We suppose that these requests on minio make transactions over Raft, involving 4 sequential requests: 1) sending the message to the leader, 2) having the leader dispatch it to the other nodes, 3) waiting for the confirmation of followers and finally 4) commiting it. With our current configuration, one Raft transaction will take around 400 ms. GetObject seems to correlate to 1 transaction while PutObject and RemoveObject seems to correlate to 2 or 3. Reviewing minio code would be required to confirm this hypothesis.
|
||||
We suppose that these requests on minio make transactions over Raft, involving 4 sequential requests: 1) sending the message to the leader, 2) having the leader dispatch it to the other nodes, 3) waiting for the confirmation of followers and finally 4) committing it. With our current configuration, one Raft transaction will take around 400 ms. GetObject seems to correlate to 1 transaction while PutObject and RemoveObject seems to correlate to 2 or 3. Reviewing minio code would be required to confirm this hypothesis.
|
||||
|
||||
Conversely, garage uses an architecture similar to DynamoDB and never require global cluster coordination to answer a request.
|
||||
Instead, garage can always contact the right node in charge of the requested data, and can answer in as low as one request in the case of GetObject and PutObject. We also observed that Garage latency, while often lower to minio, is more dispersed: garage is still in beta and has not received any performance optimization yet.
|
||||
@@ -50,7 +50,7 @@ We plot a similar graph as before:
|
||||
|
||||
This new graph is very similar to the one before, neither minio or garage seems to benefit from this new topology, but they also do not suffer from it.
|
||||
|
||||
Considering garage, this is expected: nodes in the same DC are put in the same zone, and then data are spread on different zones for data resiliency and availaibility.
|
||||
Considering garage, this is expected: nodes in the same DC are put in the same zone, and then data are spread on different zones for data resiliency and availability.
|
||||
Then, in the default mode, requesting data requires to query at least 2 zones to be sure that we have the most up to date information.
|
||||
These requests will involve at least one inter-DC communication.
|
||||
In other words, we prioritize data availability and synchronization over raw performances.
|
||||
|
||||
@@ -94,7 +94,7 @@ delete a tombstone, the following condition has to be met:
|
||||
|
||||
- All nodes responsible for storing this entry are aware of the existence of
|
||||
the tombstone, i.e. they cannot hold another version of the entry that is
|
||||
superseeded by the tombstone. This ensures that deleting the tombstone is
|
||||
superseded by the tombstone. This ensures that deleting the tombstone is
|
||||
safe and that no deleted value will come back in the system.
|
||||
|
||||
Garage uses atomic database operations (such as compare-and-swap and
|
||||
@@ -141,4 +141,3 @@ rebalance of data, this would have led to the disk utilization to explode
|
||||
during the rebalancing, only to shrink again after 24 hours. The 10-minute
|
||||
delay is a compromise that gives good security while not having this problem of
|
||||
disk space explosion on rebalance.
|
||||
|
||||
|
||||
@@ -37,7 +37,7 @@ However, Amazon S3 source code is not open but alternatives were proposed.
|
||||
We identified Minio, Pithos, Swift and Ceph.
|
||||
Minio/Ceph enforces a total order, so properties similar to a (relaxed) filesystem.
|
||||
Swift and Pithos are probably the most similar to AWS S3 with their consistent hashing ring.
|
||||
However Pithos is not maintained anymore. More precisely the company that published Pithos version 1 has developped a second version 2 but has not open sourced it.
|
||||
However Pithos is not maintained anymore. More precisely the company that published Pithos version 1 has developed a second version 2 but has not open sourced it.
|
||||
Some tests conducted by the [ACIDES project](https://acides.org/) have shown that Openstack Swift consumes way more resources (CPU+RAM) that we can afford. Furthermore, people developing Swift have not designed their software for geo-distribution.
|
||||
|
||||
There were many attempts in research too. I am only thinking to [LBFS](https://pdos.csail.mit.edu/papers/lbfs:sosp01/lbfs.pdf) that was used as a basis for Seafile. But none of them have been effectively implemented yet.
|
||||
@@ -63,7 +63,7 @@ Due to its industry oriented design, Ceph is also far from being *Simple* to ope
|
||||
In a certain way, Ceph and MinIO are closer together than they are from Garage or OpenStack Swift.
|
||||
|
||||
**[Pithos](https://github.com/exoscale/pithos):**
|
||||
Pithos has been abandonned and should probably not used yet, in the following we explain why we did not pick their design.
|
||||
Pithos has been abandoned and should probably not used yet, in the following we explain why we did not pick their design.
|
||||
Pithos was relying as a S3 proxy in front of Cassandra (and was working with Scylla DB too).
|
||||
From its designers' mouth, storing data in Cassandra has shown its limitations justifying the project abandonment.
|
||||
They built a closed-source version 2 that does not store blobs in the database (only metadata) but did not communicate further on it.
|
||||
|
||||
@@ -23,7 +23,7 @@ This logic is defined in `nix/build_index.nix`.
|
||||
For each commit, we first pass the code to a formatter (rustfmt) and a linter (clippy).
|
||||
Then we try to build it in debug mode and run both unit tests and our integration tests.
|
||||
|
||||
Additionnaly, when releasing, our integration tests are run on the release build for amd64 and i686.
|
||||
Additionally, when releasing, our integration tests are run on the release build for amd64 and i686.
|
||||
|
||||
## Generated Artifacts
|
||||
|
||||
@@ -32,7 +32,7 @@ We generate the following binary artifacts for now:
|
||||
- **os**: linux
|
||||
- **format**: static binary, docker container
|
||||
|
||||
Additionnaly we also build two web pages and one JSON document:
|
||||
Additionally we also build two web pages and one JSON document:
|
||||
- the documentation (this website)
|
||||
- [the release page](https://garagehq.deuxfleurs.fr/_releases.html)
|
||||
- [the release list in JSON format](https://garagehq.deuxfleurs.fr/_releases.json)
|
||||
@@ -67,7 +67,7 @@ nix copy --to 's3://nix?endpoint=garage.deuxfleurs.fr®ion=garage&secret-key=/
|
||||
The previous command will only send the built package and not its dependencies.
|
||||
In the case of our CI pipeline, we want to cache all intermediate build steps
|
||||
as well. This can be done using this quite involved command (here as an example
|
||||
for the `pkgs.amd64.relase` package):
|
||||
for the `pkgs.amd64.release` package):
|
||||
|
||||
```bash
|
||||
nix copy -j8 \
|
||||
@@ -174,5 +174,3 @@ drone sign --save Deuxfleurs/garage
|
||||
```
|
||||
|
||||
Looking at the file, you will see that most of the commands are `nix-shell` and `nix-build` commands with various parameters.
|
||||
|
||||
|
||||
|
||||
@@ -242,7 +242,7 @@ dc3 Tags Partitions Capacity Usable capacity
|
||||
TOTAL 256 (256 unique) 2.0 GB 1000.0 MB (50.0%)
|
||||
```
|
||||
|
||||
As we can see, the node that was moved to `dc3` (node4) is only used at 25% (approximatively),
|
||||
As we can see, the node that was moved to `dc3` (node4) is only used at 25% (approximately),
|
||||
whereas the node that was already in `dc3` (node3) is used at 75%.
|
||||
|
||||
This can be explained by the following:
|
||||
@@ -260,7 +260,7 @@ This can be explained by the following:
|
||||
data can be removed to be moved to node1.
|
||||
|
||||
- Garage will move data in equal proportions from all possible sources, in this
|
||||
case it means that it will tranfer 25% of the entire data set from node3 to
|
||||
case it means that it will transfer 25% of the entire data set from node3 to
|
||||
node1 and another 25% from node4 to node1.
|
||||
|
||||
This explains why node3 ends with 75% utilization (100% from before minus 25%
|
||||
|
||||
@@ -40,7 +40,7 @@ First of all, Garage divides the set of all possible block hashes
|
||||
in a fixed number of slices (currently 1024), and assigns
|
||||
to each slice a primary storage location among the specified data directories.
|
||||
The number of slices having their primary location in each data directory
|
||||
is proportionnal to the capacity specified in the config file.
|
||||
is proportional to the capacity specified in the config file.
|
||||
|
||||
When Garage receives a block to write, it will always write it in the primary
|
||||
directory of the slice that contains its hash.
|
||||
|
||||
@@ -56,7 +56,7 @@ From a high level perspective, a major upgrade looks like this:
|
||||
10. Enable API access (reverse step 1)
|
||||
11. Monitor your cluster while load comes back, check that all your applications are happy with this new version
|
||||
|
||||
### Major upgarades with minimal downtime
|
||||
### Major upgrades with minimal downtime
|
||||
|
||||
There is only one operation that has to be coordinated cluster-wide: the switch of one version of the internal RPC protocol to the next.
|
||||
This means that an upgrade with very limited downtime can simply be performed from one major version to the next by restarting all nodes
|
||||
|
||||
@@ -372,7 +372,7 @@ Performance characteristics of the different DB engines are as follows:
|
||||
not recommended.
|
||||
|
||||
- Keys in LMDB are limited to 511 bytes. This limit translates to limits on
|
||||
object keys in S3 and sort keys in K2V that are limted to 479 bytes.
|
||||
object keys in S3 and sort keys in K2V that are limited to 479 bytes.
|
||||
|
||||
- **Sqlite:** Garage supports Sqlite as an alternative storage backend for
|
||||
metadata, which does not have the issues listed above for LMDB. Sqlite is
|
||||
@@ -396,7 +396,7 @@ garage convert-db -a <input db engine> -i <input db path> \
|
||||
```
|
||||
|
||||
Make sure to specify the full database path as presented in the table above
|
||||
(third colummn), and not just the path to the metadata directory.
|
||||
(third column), and not just the path to the metadata directory.
|
||||
|
||||
#### `metadata_fsync` {#metadata_fsync}
|
||||
|
||||
@@ -554,7 +554,7 @@ awaits for one of the `block_max_concurrent_reads` slots to be available
|
||||
slot, it reads the entire block file to RAM and frees the slot as soon as the
|
||||
block file is finished reading. Only after the slot is released will the
|
||||
block's data start being transferred over the network. If the request fails to
|
||||
acquire a reading slot wihtin 15 seconds, it fails with a timeout error.
|
||||
acquire a reading slot within 15 seconds, it fails with a timeout error.
|
||||
Timeout events can be monitored through the `block_read_semaphore_timeouts`
|
||||
metric in Prometheus: a non-zero number of such events indicates an I/O
|
||||
bottleneck on HDD read speed.
|
||||
@@ -617,11 +617,11 @@ storing the secret as the `GARAGE_RPC_SECRET_FILE` environment variable.
|
||||
|
||||
#### `rpc_bind_addr` {#rpc_bind_addr}
|
||||
|
||||
The address and port on which to bind for inter-cluster communcations
|
||||
(reffered to as RPC for remote procedure calls).
|
||||
The address and port on which to bind for inter-cluster communications
|
||||
(referred to as RPC for remote procedure calls).
|
||||
The port specified here should be the same one that other nodes will used to contact
|
||||
the node, even in the case of a NAT: the NAT should be configured to forward the external
|
||||
port number to the same internal port nubmer. This means that if you have several nodes running
|
||||
port number to the same internal port number. This means that if you have several nodes running
|
||||
behind a NAT, they should each use a different RPC port number.
|
||||
|
||||
#### `rpc_bind_outgoing` (since `v0.9.2`) {#rpc_bind_outgoing}
|
||||
@@ -784,14 +784,14 @@ manually.
|
||||
#### `api_bind_addr` {#s3_api_bind_addr}
|
||||
|
||||
The IP and port on which to bind for accepting S3 API calls.
|
||||
This endpoint does not suport TLS: a reverse proxy should be used to provide it.
|
||||
This endpoint does not support TLS: a reverse proxy should be used to provide it.
|
||||
|
||||
Alternatively, since `v0.8.5`, a path can be used to create a unix socket with 0222 mode.
|
||||
|
||||
#### `s3_region` {#s3_region}
|
||||
|
||||
Garage will accept S3 API calls that are targetted to the S3 region defined here.
|
||||
API calls targetted to other regions will fail with a AuthorizationHeaderMalformed error
|
||||
Garage will accept S3 API calls that are targeted to the S3 region defined here.
|
||||
API calls targeted to other regions will fail with a AuthorizationHeaderMalformed error
|
||||
message that redirects the client to the correct region.
|
||||
|
||||
#### `root_domain` {#s3_root_domain}
|
||||
@@ -799,7 +799,7 @@ message that redirects the client to the correct region.
|
||||
The optional suffix to access bucket using vhost-style in addition to path-style request.
|
||||
Note path-style requests are always enabled, whether or not vhost-style is configured.
|
||||
Configuring vhost-style S3 required a wildcard DNS entry, and possibly a wildcard TLS certificate,
|
||||
but might be required by softwares not supporting path-style requests.
|
||||
but might be required by software not supporting path-style requests.
|
||||
|
||||
If `root_domain` is `s3.garage.eu`, a bucket called `my-bucket` can be interacted with
|
||||
using the hostname `my-bucket.s3.garage.eu`.
|
||||
@@ -815,7 +815,7 @@ behaviour of this module.
|
||||
|
||||
The IP and port on which to bind for accepting HTTP requests to buckets configured
|
||||
for website access.
|
||||
This endpoint does not suport TLS: a reverse proxy should be used to provide it.
|
||||
This endpoint does not support TLS: a reverse proxy should be used to provide it.
|
||||
|
||||
Alternatively, since `v0.8.5`, a path can be used to create a unix socket with 0222 mode.
|
||||
|
||||
@@ -888,7 +888,7 @@ You can use any random string for this value. We recommend generating a random t
|
||||
|
||||
If this is set to `true`, accessing the metrics endpoint will always require
|
||||
an access token. Valid tokens include the `metrics_token` if it is set,
|
||||
and admin API token defined dynamicaly in Garage which have
|
||||
and admin API token defined dynamically in Garage which have
|
||||
the `Metrics` endpoint in their scope.
|
||||
|
||||
#### `trace_sink` {#admin_trace_sink}
|
||||
|
||||
@@ -46,7 +46,7 @@ to select the replication mode best suited to your use case (hint: in most cases
|
||||
|
||||
### Compression and deduplication
|
||||
|
||||
All data stored in Garage is deduplicated, and optionnally compressed using
|
||||
All data stored in Garage is deduplicated, and optionally compressed using
|
||||
Zstd. Objects uploaded to Garage are chunked in blocks of constant sizes (see
|
||||
[`block_size`](@/documentation/reference-manual/configuration.md#block_size)),
|
||||
and the hashes of individual blocks are used to dispatch them to storage nodes
|
||||
@@ -84,13 +84,13 @@ exposing the same content under different domain names.
|
||||
|
||||
Garage also supports bucket aliases which are local to a single user:
|
||||
this allows different users to have different buckets with the same name, thus avoiding naming collisions.
|
||||
This can be helpfull for instance if you want to write an application that creates per-user buckets with always the same name.
|
||||
This can be helpful for instance if you want to write an application that creates per-user buckets with always the same name.
|
||||
|
||||
This feature is totally invisible to S3 clients and does not break compatibility with AWS.
|
||||
|
||||
### Cluster administration API
|
||||
|
||||
Garage provides a fully-fledged REST API to administer your cluster programatically.
|
||||
Garage provides a fully-fledged REST API to administer your cluster programmatically.
|
||||
Functionality included in the admin API include: setting up and monitoring
|
||||
cluster nodes, managing access credentials, and managing storage buckets and bucket aliases.
|
||||
A full reference of the administration API is available [here](@/documentation/reference-manual/admin-api.md).
|
||||
@@ -100,7 +100,7 @@ A full reference of the administration API is available [here](@/documentation/r
|
||||
Garage makes some internal metrics available in the Prometheus data format,
|
||||
which allows you to build interactive dashboards to visualize the load and internal state of your storage cluster.
|
||||
|
||||
For developpers and performance-savvy administrators,
|
||||
For developers and performance-savvy administrators,
|
||||
Garage also supports exporting traces of what it does internally in OpenTelemetry format.
|
||||
This allows to monitor the time spent at various steps of the processing of requests,
|
||||
in order to detect potential performance bottlenecks.
|
||||
|
||||
@@ -19,7 +19,7 @@ The specification of the K2V API can be found
|
||||
[here](https://git.deuxfleurs.fr/Deuxfleurs/garage/src/commit/f8be15c37db857e177d543de7be863692628d567/doc/drafts/k2v-spec.md).
|
||||
This document also includes a high-level overview of K2V's design.
|
||||
|
||||
The K2V API uses AWSv4 signatures for authentification, same as the S3 API.
|
||||
The K2V API uses AWSv4 signatures for authentication, same as the S3 API.
|
||||
The AWS region used for signature calculation is always the same as the one
|
||||
defined for the S3 API in the config file.
|
||||
|
||||
@@ -55,4 +55,3 @@ cargo build --features cli --bin k2v-cli
|
||||
The CLI utility is self-documented, run `k2v-cli --help` to learn how to use
|
||||
it. There is also a short README.md in the `src/k2v-client` folder with some
|
||||
instructions.
|
||||
|
||||
|
||||
@@ -45,7 +45,7 @@ we suppose that OpenIO supports presigned URLs.
|
||||
All endpoints that are missing on Garage will return a 501 Not Implemented.
|
||||
Some `x-amz-` headers are not implemented.
|
||||
|
||||
### Core endoints
|
||||
### Core endpoints
|
||||
|
||||
| Endpoint | Garage | [Openstack Swift](https://docs.openstack.org/swift/latest/s3_compat.html) | [Ceph Object Gateway](https://docs.ceph.com/en/latest/radosgw/s3/) | [Riak CS](https://docs.riak.com/riak/cs/2.1.1/references/apis/storage/s3/index.html) | [OpenIO](https://docs.openio.io/latest/source/arch-design/s3_compliancy.html) |
|
||||
|------------------------------|----------------------------------|-----------------|---------------|---------|-----|
|
||||
@@ -135,12 +135,12 @@ If you need this feature, please [share your use case in our dedicated issue](ht
|
||||
**PutBucketLifecycleConfiguration:** The only actions supported are
|
||||
`AbortIncompleteMultipartUpload` and `Expiration` (without the
|
||||
`ExpiredObjectDeleteMarker` field). All other operations are dependent on
|
||||
either bucket versionning or storage classes which Garage currently does not
|
||||
either bucket versioning or storage classes which Garage currently does not
|
||||
implement. The deprecated `Prefix` member directly in the the `Rule`
|
||||
structure/XML tag is not supported, specified prefixes must be inside the
|
||||
`Filter` structure/XML tag.
|
||||
|
||||
**GetBucketVersioning:** Stub implementation which always returns "versionning not enabled", since Garage does not yet support bucket versionning.
|
||||
**GetBucketVersioning:** Stub implementation which always returns "versioning not enabled", since Garage does not yet support bucket versioning.
|
||||
|
||||
### Replication endpoints
|
||||
|
||||
@@ -155,7 +155,7 @@ Please open an issue if you have a use case for replication.
|
||||
*Note: Ceph documentation briefly says that Ceph supports
|
||||
[replication through the S3 API](https://docs.ceph.com/en/latest/radosgw/multisite-sync-policy/#s3-replication-api)
|
||||
but with some limitations.
|
||||
Additionaly, replication endpoints are not documented in the S3 compatibility page so I don't know what kind of support we can expect.*
|
||||
Additionally, replication endpoints are not documented in the S3 compatibility page so I don't know what kind of support we can expect.*
|
||||
|
||||
### Locking objects
|
||||
|
||||
@@ -197,7 +197,7 @@ Please open an issue if you have a use case.
|
||||
|
||||
### Vendor specific endpoints
|
||||
|
||||
<details><summary>Display Amazon specifc endpoints</summary>
|
||||
<details><summary>Display Amazon specific endpoints</summary>
|
||||
|
||||
|
||||
| Endpoint | Garage | [Openstack Swift](https://docs.openstack.org/swift/latest/s3_compat.html) | [Ceph Object Gateway](https://docs.ceph.com/en/latest/radosgw/s3/) | [Riak CS](https://docs.riak.com/riak/cs/2.1.1/references/apis/storage/s3/index.html) | [OpenIO](https://docs.openio.io/latest/source/arch-design/s3_compliancy.html) |
|
||||
@@ -234,4 +234,3 @@ Please open an issue if you have a use case.
|
||||
| [SelectObjectContent](https://docs.aws.amazon.com/AmazonS3/latest/API/API_SelectObjectContent.html) | ❌ Missing | ❌| ❌| ❌| ❌|
|
||||
|
||||
</details>
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@ title = "S3 compatibility target"
|
||||
weight = 5
|
||||
+++
|
||||
|
||||
If there is a specific S3 functionnality you have a need for, feel free to open
|
||||
If there is a specific S3 functionality you have a need for, feel free to open
|
||||
a PR to put the corresponding endpoints higher in the list. Please explain
|
||||
your motivations for doing so in the PR message.
|
||||
|
||||
|
||||
@@ -68,7 +68,7 @@ Workflow for DELETE:
|
||||
1. Check write permission (LDAP)
|
||||
2. Get current version (or versions) in object table
|
||||
3. Do the deletion of those versions NOT IN A BACKGROUND JOB THIS TIME
|
||||
4. Return succes to the user if we were able to delete blocks from the blocks table and entries from the object table
|
||||
4. Return success to the user if we were able to delete blocks from the blocks table and entries from the object table
|
||||
|
||||
To delete a version:
|
||||
|
||||
@@ -92,7 +92,7 @@ Known issue: if someone is reading from a version that we want to delete and the
|
||||
- file path = /meta/(first 3 hex digits of hash)/(rest of hash)
|
||||
- map block hash -> set of version UUIDs where it is referenced
|
||||
|
||||
Usefull metadata:
|
||||
Useful metadata:
|
||||
|
||||
- list of versions that reference this block in the Casandra table, so that we can do GC by checking in Cassandra that the lines still exist
|
||||
- list of other nodes that we know have acknowledged a write of this block, useful in the rebalancing algorithm
|
||||
|
||||
@@ -49,12 +49,12 @@ The ring construction that selects `n_token` random positions for each nodes giv
|
||||
is not well-balanced: the space between the tokens varies a lot, and some partitions are thus bigger than others.
|
||||
This problem was demonstrated in the original Dynamo DB paper.
|
||||
|
||||
To solve this, we want to apply a better second method for partitionning our dataset:
|
||||
To solve this, we want to apply a better second method for partitioning our dataset:
|
||||
|
||||
1. fix an initially large number of partitions (say 1024) with evenly-spaced delimiters,
|
||||
|
||||
2. attribute each partition randomly to a node, with a probability
|
||||
proportionnal to its capacity (which `n_tokens` represented in the first
|
||||
proportional to its capacity (which `n_tokens` represented in the first
|
||||
method)
|
||||
|
||||
For now we continue using the multi-DC ring walking described above.
|
||||
@@ -66,7 +66,7 @@ I have studied two ways to do the attribution of partitions to nodes, in a way t
|
||||
|
||||
MagLev provided significantly better balancing, as it guarantees that the exact
|
||||
same number of partitions is attributed to all nodes that have the same
|
||||
capacity (and that this number is proportionnal to the node's capacity, except
|
||||
capacity (and that this number is proportional to the node's capacity, except
|
||||
for large values), however in both cases:
|
||||
|
||||
- the distribution is still bad, because we use the naive multi-DC ring walking
|
||||
|
||||
@@ -19,7 +19,7 @@ The migration steps are as follows:
|
||||
2. Disable API and web access. Garage does not support disabling
|
||||
these endpoints but you can change the port number or stop your reverse
|
||||
proxy for instance.
|
||||
3. Check once again that your cluster is healty. Run again `garage repair --all-nodes --yes tables` which is quick.
|
||||
3. Check once again that your cluster is healthy. Run again `garage repair --all-nodes --yes tables` which is quick.
|
||||
Also check your queues are empty, run `garage stats` to query them.
|
||||
4. Turn off Garage v0.6
|
||||
5. Backup the metadata folder of all your nodes: `cd /var/lib/garage ; tar -acf meta-v0.6.tar.zst meta/`
|
||||
|
||||
@@ -28,11 +28,11 @@ We should try to test in least invasive ways, i.e. minimize the impact of the te
|
||||
- Not making `garage` a shared library (launch using `execve`, it's perfectly fine)
|
||||
|
||||
Instead, we should focus on building a clean outer interface for the `garage` binary,
|
||||
for example loading configuration using environnement variables instead of the configuration file if that's helpfull for writing the tests.
|
||||
for example loading configuration using environment variables instead of the configuration file if that's helpful for writing the tests.
|
||||
|
||||
There are two reasons for this:
|
||||
|
||||
- Keep the soure code clean and focused
|
||||
- Keep the source code clean and focused
|
||||
- Test something that is as close as possible as the true garage that will actually be running
|
||||
|
||||
Reminder: rules of simplicity, concerning changes to Garage's source code.
|
||||
@@ -71,5 +71,3 @@ Interesting blog posts on the blog of the Sled database:
|
||||
Misc:
|
||||
- [mutagen](https://github.com/llogiq/mutagen) - mutation testing is a way to assert our test quality by mutating the code and see if the mutation makes the tests fail
|
||||
- [fuzzing](https://rust-fuzz.github.io/book/) - cargo supports fuzzing, it could be a way to test our software reliability in presence of garbage data.
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user