This is an automated email from the ASF dual-hosted git repository.
weichiu pushed a commit to branch HDDS-9225-website-v2
in repository https://gitbox.apache.org/repos/asf/ozone-site.git
The following commit(s) were added to refs/heads/HDDS-9225-website-v2 by this
push:
new 3e7c44064 HDDS-14181. [Website v2] [Docs] [Core Concepts] Ozone
Manager (#213)
3e7c44064 is described below
commit 3e7c4406441e894648f599ce6b0358b22c0788c6
Author: Bolin Lin <[email protected]>
AuthorDate: Tue Jan 13 02:16:39 2026 -0500
HDDS-14181. [Website v2] [Docs] [Core Concepts] Ozone Manager (#213)
Co-authored-by: Wei-Chiu Chuang <[email protected]>
---
.../01-architecture/02-ozone-manager.md | 99 +++++++++++++++++++++
.../{02-s3-gateway.md => 03-s3-gateway.md} | 0
.../01-architecture/OzoneManager-ReadPath.png | Bin 0 -> 81030 bytes
.../01-architecture/OzoneManager-WritePath.png | Bin 0 -> 96696 bytes
.../01-architecture/OzoneManager.png | Bin 0 -> 13327 bytes
5 files changed, 99 insertions(+)
diff --git a/docs/03-core-concepts/01-architecture/02-ozone-manager.md
b/docs/03-core-concepts/01-architecture/02-ozone-manager.md
new file mode 100644
index 000000000..9169a8e99
--- /dev/null
+++ b/docs/03-core-concepts/01-architecture/02-ozone-manager.md
@@ -0,0 +1,99 @@
+---
+sidebar_label: Ozone Manager
+---
+
+# Ozone Manager
+
+
+
+Ozone Manager (OM) is the namespace manager for Ozone.
+
+This means that when you want to write some data, you ask Ozone Manager for a
block and Ozone Manager gives you a block and remembers that information. When
you want to read that file back, you need to find the address of the block and
the Ozone Manager returns it to you.
+
+Ozone Manager also allows users to organize keys under a volume and bucket.
Volumes and buckets are part of the namespace and managed by Ozone Manager.
+
+Each Ozone volume is the root of an independent namespace under OM. This is
very different from HDFS which provides a single rooted file system.
+
+Ozone's namespace is a collection of volumes or is a forest instead of a
single rooted tree as in HDFS. This property makes it easy to deploy multiple
OMs for scaling(pending future development).
+
+## Ozone Manager Metadata
+
+OM maintains a list of volumes, buckets, and keys. For each user, it maintains
a list of volumes. For each volume, the list of buckets and for each bucket the
list of keys.
+
+Ozone Manager will use [Apache Ratis](https://ratis.apache.org/) (A Raft
protocol implementation) to replicate Ozone Manager state. <!-- TODO: Link to
OM HA page when created --> This will ensure High Availability for Ozone
Manager.
+
+## Ozone Manager and Storage Container Manager
+
+<!-- TODO: Link to SCM page when created --> The relationship between Ozone
Manager and Storage Container Manager (SCM) is best understood if we trace what
happens during a key write and key read.
+
+### Key Write
+
+
+
+- To write a key to Ozone, a client tells Ozone Manager that it would like to
write a key into a bucket that lives inside a specific volume. Once Ozone
Manager determines that you are allowed to write a key to the specified bucket,
OM needs to allocate a block for the client to write data.
+
+- To allocate a block, Ozone Manager sends a request to Storage Container
Manager (SCM); <!-- TODO: Link to Datanodes page when created --> SCM is the
manager of data nodes. SCM picks three data nodes into which client can write
data. SCM allocates the block and returns the block ID to Ozone Manager.
+
+- Ozone Manager records this block information in its metadata and returns the
block and a <!-- TODO: Link to block token/security page when created --> block
token (a security permission to write data to the block) to the client.
+
+- The client uses the block token to prove that it is allowed to write data to
the block and writes data to the data node.
+
+- Once the write is complete on the data node, the client will update the
block information on Ozone Manager.
+
+### Key Reads
+
+
+
+- Key reads are simpler, the client requests the block list from the Ozone
Manager
+- Ozone Manager will return the block list and block tokens which allows the
client to read the data from data nodes.
+- Client connects to the data node and presents the block token and reads the
data from the data node.
+
+## Main Components of the Ozone Manager
+
+For a detailed view of Ozone Manager this section gives a quick overview about
the provided network services and the stored persisted data.
+
+### Network Services Provided by Ozone Manager
+
+Ozone provides a network service for the client and for administration
commands. The main service calls:
+
+- Key, Bucket, Volume / CRUD
+- Multipart upload (Initiate, Complete…)
+ - Supports upload of huge files in multiple steps
+- FS related calls (optimized for hierarchical queries instead of a flat
ObjectStore namespace)
+ - GetFileStatus, CreateDirectory, CreateFile, LookupFile
+- ACL related
+ - Managing ACLs if [Native
ACLs](/docs/core-concepts/security/acls/native-acls) are used instead of
[Ranger ACLs](/docs/core-concepts/security/acls/ranger-acls)
+- <!-- TODO: Link to delegation token/security page when created -->
Delegation token (Get / Renew / Cancel)
+ - For security
+- Admin APIs
+ - Get S3 secret
+ - ServiceList (used for service discovery)
+ - <!-- TODO: Link to Recon page when created --> DBUpdates (used by Recon
downloads snapshots)
+
+### Persisted State
+
+The following data is persisted in Ozone Manager side in a specific RocksDB
directory:
+
+- Volume / Bucket / Key tables
+ - This is the main responsibility of OM
+ - Key metadata contains the block id (which includes container id) to find
the data
+- OpenKey table
+ - for keys which are created, but not yet committed
+- Delegation token table
+ - for security
+- PrefixInfo table
+ - specific index table to store directory level ACL and to provide better
performance for hierarchical queries
+- S3 secret table
+ - For S3 secret management
+- Multipart info table
+ - Inflight uploads should be tracked
+- Deleted table
+ - To track the blocks which should be deleted from the Datanodes
+
+## Notable Configurations
+
+| Key | Default | Description |
+|-----|---------|-------------|
+| `ozone.om.address` | 0.0.0.0:9862 | RPC address of the OM. Required by the
client. |
+| `ozone.om.http-address` | 0.0.0.0:9874 | Default port of the HTTP server. |
+| `ozone.metadata.dirs` | none | Directory to store persisted data (RocksDB). |
diff --git a/docs/03-core-concepts/01-architecture/02-s3-gateway.md
b/docs/03-core-concepts/01-architecture/03-s3-gateway.md
similarity index 100%
rename from docs/03-core-concepts/01-architecture/02-s3-gateway.md
rename to docs/03-core-concepts/01-architecture/03-s3-gateway.md
diff --git a/docs/03-core-concepts/01-architecture/OzoneManager-ReadPath.png
b/docs/03-core-concepts/01-architecture/OzoneManager-ReadPath.png
new file mode 100644
index 000000000..5e68f6fc1
Binary files /dev/null and
b/docs/03-core-concepts/01-architecture/OzoneManager-ReadPath.png differ
diff --git a/docs/03-core-concepts/01-architecture/OzoneManager-WritePath.png
b/docs/03-core-concepts/01-architecture/OzoneManager-WritePath.png
new file mode 100644
index 000000000..924b61c31
Binary files /dev/null and
b/docs/03-core-concepts/01-architecture/OzoneManager-WritePath.png differ
diff --git a/docs/03-core-concepts/01-architecture/OzoneManager.png
b/docs/03-core-concepts/01-architecture/OzoneManager.png
new file mode 100644
index 000000000..f71bfacc4
Binary files /dev/null and
b/docs/03-core-concepts/01-architecture/OzoneManager.png differ
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]