|
| 1 | +// Module included in the following assemblies: |
| 2 | +// |
| 3 | +// * installing/installing_bare_metal/upi/installing-bare-metal.adoc |
| 4 | +// * installing/installing_bare_metal/upi/installing-restricted-networks-bare-metal.adoc |
| 5 | +// * installing/installing_bare_metal/upi/installing-bare-metal-network-customizations.adoc |
| 6 | +// * installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc |
| 7 | + |
| 8 | +ifeval::["{context}" == "installing-with-agent-based-installer"] |
| 9 | +:agent: |
| 10 | +endif::[] |
| 11 | +ifeval::["{context}" == "installing-restricted-networks-bare-metal"] |
| 12 | +:restricted: |
| 13 | +endif::[] |
| 14 | + |
| 15 | +:_mod-docs-content-type: PROCEDURE |
| 16 | +[id="installation-user-infra-machines-advanced-disk_{context}"] |
| 17 | += Disk partitioning |
| 18 | + |
| 19 | +ifndef::agent[] |
| 20 | +[role="_abstract"] |
| 21 | +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 you override the default partitioning configuration. During the {op-system} installation, the size of the root file system is increased to use any remaining available space on the target device. |
| 22 | +
|
| 23 | +[IMPORTANT] |
| 24 | +==== |
| 25 | +The use of a custom partition scheme on your node might result in {product-title} not monitoring or alerting on some node partitions. For more information on monitoring host file systems when using custom partitioning, see link:https://access.redhat.com/articles/4766521[Understanding OpenShift File System Monitoring (eviction conditions)]. |
| 26 | +==== |
| 27 | +
|
| 28 | +{product-title} monitors the following two filesystem identifiers: |
| 29 | +
|
| 30 | +* `nodefs`, which is the filesystem that contains `/var/lib/kubelet`. |
| 31 | +* `imagefs`, which is the filesystem that contains `/var/lib/containers`. |
| 32 | +
|
| 33 | +For the default partition scheme, `nodefs` and `imagefs` monitor the same root filesystem, `/`. |
| 34 | +
|
| 35 | +To override the default partitioning when installing {op-system} on an {product-title} cluster node, you must create separate partitions. Consider a situation where you 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 monitors `/var/lib/containers` as the `imagefs` directory and the root file system as the `nodefs` directory. |
| 36 | +
|
| 37 | +[IMPORTANT] |
| 38 | +==== |
| 39 | +If you have resized your disk size to host a larger file system, consider creating a separate `/var/lib/containers` partition. Consider resizing a disk that has an `xfs` format to reduce CPU time issues caused by a high number of allocation groups. |
| 40 | +==== |
| 41 | +endif::agent[] |
| 42 | +ifdef::agent[] |
| 43 | +[role="_abstract"] |
| 44 | +In general, you must use the default disk partitioning that is created during the {op-system} installation. However, there are cases where you might want to create a separate partition for a directory that you expect to grow. |
| 45 | +endif::agent[] |
| 46 | +
|
| 47 | +{product-title} supports the addition of a single partition to attach storage to either the `/var` directory or a subdirectory of `/var`. For example: |
| 48 | +
|
| 49 | +* `/var/lib/containers`: Holds container-related content that can grow |
| 50 | +as more images and containers are added to a system. |
| 51 | +* `/var/lib/etcd`: Holds data that you might want to keep separate for purposes such as performance optimization of etcd storage. |
| 52 | +* `/var`: Holds data that you might want to keep separate for purposes such as auditing. |
| 53 | ++ |
| 54 | +[IMPORTANT] |
| 55 | +==== |
| 56 | +For disk sizes larger than 100GB, and especially larger than 1TB, create a separate `/var` partition. |
| 57 | +==== |
| 58 | +
|
| 59 | +Storing the contents of a `/var` directory separately makes it easier to grow storage for those areas as needed and reinstall {product-title} at a later date so to keep that data intact. This method eliminates the need to re-pull containers or copy large log files during system updates. |
| 60 | +
|
| 61 | +The use of a separate partition for the `/var` directory or a subdirectory of `/var` also prevents data growth in the partitioned directory from filling up the root file system. |
| 62 | +
|
| 63 | +The following procedure sets up a separate `/var` partition by adding a machine config manifest that is wrapped into the Ignition config file for a node type during the preparation phase of an installation. |
| 64 | +
|
| 65 | +ifdef::agent[] |
| 66 | +.Prerequisites |
| 67 | +* You have created an `openshift` subdirectory within your installation directory. |
| 68 | +endif::agent[] |
| 69 | +
|
| 70 | +.Procedure |
| 71 | +
|
| 72 | +ifndef::agent[] |
| 73 | +. On your installation host, change to the directory that contains the {product-title} installation program and generate the Kubernetes manifests for the cluster: |
| 74 | ++ |
| 75 | +[source,terminal] |
| 76 | +---- |
| 77 | +$ openshift-install create manifests --dir <installation_directory> |
| 78 | +---- |
| 79 | +endif::agent[] |
| 80 | +
|
| 81 | +. Create a Butane config that configures the additional partition. For example, name the file `$HOME/clusterconfig/98-var-partition.bu`, change the disk device name to the name of the storage device on the `worker` systems, and set the storage size as appropriate. This example places the `/var` directory on a separate partition: |
| 82 | ++ |
| 83 | +[source,yaml,subs="attributes+"] |
| 84 | +---- |
| 85 | +variant: openshift |
| 86 | +version: {product-version}.0 |
| 87 | +metadata: |
| 88 | + labels: |
| 89 | + machineconfiguration.openshift.io/role: worker |
| 90 | + name: 98-var-partition |
| 91 | +storage: |
| 92 | + disks: |
| 93 | + - device: /dev/disk/by-id/<device_name> |
| 94 | + partitions: |
| 95 | + - label: var |
| 96 | + start_mib: <partition_start_offset> |
| 97 | + size_mib: <partition_size> |
| 98 | + number: 5 |
| 99 | + filesystems: |
| 100 | + - device: /dev/disk/by-partlabel/var |
| 101 | + path: /var |
| 102 | + format: xfs |
| 103 | + mount_options: [defaults, prjquota] |
| 104 | + with_mount_unit: true |
| 105 | +---- |
| 106 | ++ |
| 107 | +where: |
| 108 | ++ |
| 109 | +`<device_name>`:: Specifies the storage device name of the disk that you want to partition. |
| 110 | +`<partition_start_offset>`:: Specifies the minimum offset value for the boot disk. For best performance, specify a minimum offset value of 25000 mebibytes. The root file system is automatically resized to fill all available space up to the specified offset. If no offset value is specified, or if the specified value is smaller than the recommended minimum, the resulting root file system will be too small, and future reinstalls of {op-system} might overwrite the beginning of the data partition. |
| 111 | +`<partition_size>`:: Specifies the size of the data partition in mebibytes. |
| 112 | +`mount_options`:: The `prjquota` mount option must be enabled for filesystems used for container storage. |
| 113 | ++ |
| 114 | +[NOTE] |
| 115 | +==== |
| 116 | +When creating a separate `/var` partition, you cannot use different instance types for compute nodes, if the different instance types do not have the same device name. |
| 117 | +==== |
| 118 | +
|
| 119 | +. Create a manifest from the Butane config and save it to the `clusterconfig/openshift` directory. For example, run the following command: |
| 120 | ++ |
| 121 | +[source,terminal] |
| 122 | +---- |
| 123 | +$ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml |
| 124 | +---- |
| 125 | +
|
| 126 | +ifndef::agent[] |
| 127 | +. Create the Ignition config files by running the following command: |
| 128 | ++ |
| 129 | +[source,terminal] |
| 130 | +---- |
| 131 | +$ openshift-install create ignition-configs --dir <installation_directory> |
| 132 | +---- |
| 133 | +* `<installation_directory>`: Specify the name installation directory. |
| 134 | ++ |
| 135 | +Ignition config files are created for the bootstrap, control plane, and compute nodes in the installation directory: |
| 136 | ++ |
| 137 | +---- |
| 138 | +. |
| 139 | +├── auth |
| 140 | +│ ├── kubeadmin-password |
| 141 | +│ └── kubeconfig |
| 142 | +├── bootstrap.ign |
| 143 | +├── master.ign |
| 144 | +├── metadata.json |
| 145 | +└── worker.ign |
| 146 | +---- |
| 147 | ++ |
| 148 | +The files in the `<installation_directory>/manifest` and `<installation_directory>/openshift` directories are wrapped into the Ignition config files, including the file that contains the `98-var-partition` custom `MachineConfig` object. |
| 149 | +
|
| 150 | +. Optional: You can apply the custom disk partitioning by referencing the Ignition config files during the {op-system} installations. |
| 151 | +endif::agent[] |
| 152 | +
|
| 153 | +ifeval::["{context}" == "installing-with-agent-based-installer"] |
| 154 | +:!agent: |
| 155 | +endif::[] |
| 156 | +ifeval::["{context}" == "installing-restricted-networks-bare-metal"] |
| 157 | +:!restricted: |
| 158 | +endif::[] |
0 commit comments