Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OCPBUGS-10640-12: 4.12 Added clarification point to disk partition BM… #73362

Closed
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 17 additions & 14 deletions modules/installation-user-infra-machines-advanced.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -67,31 +67,34 @@ The `--copy-network` option only copies networking configuration found under `/e
[id="installation-user-infra-machines-advanced_disk_{context}"]
== Disk partitioning

// This content is not modularized, so any updates to this "Disk partitioning" section should be checked against the module created for vSphere UPI parity in the module file named `installation-disk-partitioning.adoc` for consistency until such time as this large assembly can be modularized.
The disk partitions are created on {product-title} cluster nodes during the {op-system-first} installation. Each {op-system} node of a particular architecture uses the same partition layout, unless the default partitioning configuration is overridden.

The disk partitions are created on {product-title} cluster nodes during the {op-system-first} installation. Each {op-system} node of a particular architecture uses the same partition layout, unless the default partitioning configuration is overridden. During the {op-system} installation, the size of the root file system is increased to use the remaining available space on the target device.
During the {op-system} installation, the size of the root file system is increased to use the remaining available space on the target device.
dfitzmau marked this conversation as resolved.
Show resolved Hide resolved

There are two cases where you might want to override the default partitioning when installing {op-system} on an {product-title} cluster node:

* Creating separate partitions: For greenfield installations on an empty
disk, you might want to add separate storage to a partition. This is
officially supported for mounting `/var` or a subdirectory of `/var`, such as `/var/lib/etcd`, on a separate partition, but not both.
+
[IMPORTANT]
====
For disk sizes larger than 100GB, and especially disk sizes larger than 1TB, create a separate `/var` partition. See "Creating a separate `/var` partition" and this link:https://access.redhat.com/solutions/5587281[Red Hat Knowledgebase article] for more information.
The use of a custom partition scheme on your node could result in {product-title} not monitoring or alerting on some node partitions. If you are overriding the default partitioning, see link:https://access.redhat.com/articles/4766521[Understanding OpenShift File System Monitoring (eviction conditions)] for more information about how {product-title} monitors your host file systems.
====
+

{product-title} monitors the following two filesystem identifiers:

* `nodefs`, which is the filesystem that contains `/var/lib/kubelet`
* `imagefs`, which is the filesystem that contains `/var/lib/containers`

For the default partition scheme, `nodefs` and `imagefs` monitor the same root filesystem, `/`.

If you want to override the default partitioning when installing {op-system} on an {product-title} cluster node, you must create separate partitions.

[IMPORTANT]
====
Kubernetes supports only two file system partitions. If you add more than one partition to the original configuration, Kubernetes cannot monitor all of them.
For disk sizes larger than 100GB, and especially disk sizes larger than 1TB, create a separate `/var` partition. See "Creating a separate `/var` partition" and this link:https://access.redhat.com/solutions/5587281[Red Hat Knowledgebase article] for more information.
====

* Retaining existing partitions: For a brownfield installation where you are reinstalling {product-title} on an existing node and want to retain data partitions installed from your previous operating system, there are both boot arguments and options to `coreos-installer` that allow you to retain existing data partitions.
You might want to add a separate storage partition for your containers and container images. For example, by mounting `/var/lib/containers` in a separate partition, the kubelet separately monitor `/var/lib/containers` as the `imagefs` directory and the root file system as the `nodefs` directory.

[WARNING]
[IMPORTANT]
====
The use of custom partitions could result in those partitions not being monitored by {product-title} or alerted on. If you are overriding the default partitioning, see link:https://access.redhat.com/articles/4766521[Understanding OpenShift File System Monitoring (eviction conditions)] for more information about how {product-title} monitors your host file systems.
If you resized your disk size to host a larger file system, consider creating a separate `/var/lib/containers` partition. This is important for a disk formatted to `xfs`, where a high number of allocation groups might cause CPU time issues.
====

[id="installation-user-infra-machines-advanced_vardisk_{context}"]
Expand Down