| Mohammed Naser | 90128aa | 2024-04-29 13:21:58 -0400 | [diff] [blame] | 1 | #################### |
| 2 | Cinder Configuration |
| 3 | #################### |
| 4 | |
| 5 | Cinder, the block storage service for OpenStack, can be configured to use a |
| 6 | variety of storage backends. This section guides you through setting up Cinder |
| 7 | with different backend technologies, each of which might require specific |
| 8 | configuration steps. |
| 9 | |
| Michiel Piscaer | f7d95c5 | 2024-06-14 16:27:38 +0200 | [diff] [blame] | 10 | Cinder can be configured with multiple backends which would all be configured |
| 11 | inside of ``cinder_helm_values.conf.backends``. The documentation below explains |
| 12 | how to configure a specific backend, but you can add multiple backends by |
| 13 | adding additional entries to the ``cinder_helm_values.conf.backends`` dictionary. |
| 14 | |
| Mohammed Naser | 90128aa | 2024-04-29 13:21:58 -0400 | [diff] [blame] | 15 | ******** |
| 16 | Ceph RBD |
| 17 | ******** |
| 18 | |
| 19 | When using the integrated Ceph cluster provided with Atmosphere, no additional |
| 20 | configuration is needed for Cinder. The deployment process automatically |
| 21 | configures Cinder to use Ceph as the backend, simplifying setup and integration. |
| 22 | |
| 23 | *************** |
| 24 | Dell PowerStore |
| 25 | *************** |
| 26 | |
| 27 | In order to be able to use Dell PowerStore, you'll need to make sure that you |
| 28 | setup the hosts inside of your storage array. You'll also need to make sure |
| 29 | that they are not inside a host group or otherwise individual attachments will |
| 30 | not work. |
| 31 | |
| 32 | You can enable the native PowerStore driver for Cinder with the following |
| 33 | configuration inside your Ansible inventory: |
| 34 | |
| 35 | .. code-block:: yaml |
| 36 | |
| 37 | cinder_helm_values: |
| 38 | storage: powerstore |
| 39 | dependencies: |
| 40 | static: |
| 41 | api: |
| 42 | jobs: |
| 43 | - cinder-db-sync |
| 44 | - cinder-ks-user |
| 45 | - cinder-ks-endpoints |
| 46 | - cinder-rabbit-init |
| 47 | scheduler: |
| 48 | jobs: |
| 49 | - cinder-db-sync |
| 50 | - cinder-ks-user |
| 51 | - cinder-ks-endpoints |
| 52 | - cinder-rabbit-init |
| 53 | volume: |
| 54 | jobs: |
| 55 | - cinder-db-sync |
| 56 | - cinder-ks-user |
| 57 | - cinder-ks-endpoints |
| 58 | - cinder-rabbit-init |
| 59 | volume_usage_audit: |
| 60 | jobs: |
| 61 | - cinder-db-sync |
| 62 | - cinder-ks-user |
| 63 | - cinder-ks-endpoints |
| 64 | - cinder-rabbit-init |
| 65 | conf: |
| 66 | cinder: |
| 67 | DEFAULT: |
| 68 | enabled_backends: powerstore |
| 69 | default_volume_type: powerstore |
| 70 | backends: |
| 71 | rbd1: null |
| 72 | powerstore: |
| 73 | volume_backend_name: powerstore |
| 74 | volume_driver: cinder.volume.drivers.dell_emc.powerstore.driver.PowerStoreDriver |
| 75 | san_ip: <FILL IN> |
| 76 | san_login: <FILL IN> |
| 77 | san_password: <FILL IN> |
| 78 | storage_protocol: <FILL IN> # FC or iSCSI |
| 79 | manifests: |
| 80 | deployment_backup: true |
| 81 | job_backup_storage_init: true |
| 82 | job_storage_init: false |
| 83 | |
| 84 | nova_helm_values: |
| 85 | conf: |
| 86 | enable_iscsi: true |
| 87 | |
| 88 | .. admonition:: About ``conf.enable_iscsi`` |
| 89 | :class: info |
| 90 | |
| 91 | The ``enable_iscsi`` setting is required to allow the Nova instances to |
| 92 | expose volumes by making the `/dev` devices available to the containers, |
| 93 | not necessarily to use iSCSI as the storage protocol. In this case, the |
| 94 | PowerStore driver will use the storage protocol specified inside Cinder, |
| 95 | |
| Michiel Piscaer | f7d95c5 | 2024-06-14 16:27:38 +0200 | [diff] [blame] | 96 | ************ |
| 97 | Pure Storage |
| 98 | ************ |
| 99 | |
| 100 | Pure maintains a native Cinder driver that can be used to integrate with the |
| 101 | Pure Storage FlashArray. To enable the Pure Storage driver for Cinder, you need |
| 102 | to provide the necessary configuration settings in your Ansible inventory. |
| 103 | |
| 104 | In order to use Pure Storage, you'll need to have the following information |
| 105 | available: |
| 106 | |
| 107 | Volume Driver (``volume_driver``) |
| 108 | Use ``cinder.volume.drivers.pure.PureISCSIDriver`` for iSCSI, |
| 109 | ``cinder.volume.drivers.pure.PureFCDriver`` for Fibre Channel or |
| 110 | ``cinder.volume.drivers.pure.PureNVMEDriver`` for NVME connectivity. |
| 111 | |
| 112 | If using the NVME driver, specify the ``pure_nvme_transport`` value, which the |
| 113 | supported values are ``roce`` or ``tcp``. |
| 114 | |
| 115 | Pure API Endpoint (``san_ip``) |
| 116 | The IP address of the Pure Storage array’s management interface or a domain name |
| 117 | that resolves to that IP address. |
| 118 | |
| 119 | Pure API Token (``pure_api_token``) |
| 120 | A token generated by the Pure Storage array that allows the Cinder driver to |
| 121 | authenticate with the array. |
| 122 | |
| 123 | You can use any other configuration settings that are specific to your needs |
| 124 | by referencing the `Cinder Pure Storage documentation <https://docs.openstack.org/cinder/latest/configuration/block-storage/drivers/pure-storage-driver.html>`_. |
| 125 | |
| 126 | .. code-block:: yaml |
| 127 | |
| 128 | cinder_helm_values: |
| 129 | storage: pure |
| 130 | pod: |
| 131 | useHostNetwork: |
| 132 | volume: true |
| 133 | backup: true |
| 134 | security_context: |
| 135 | cinder_volume: |
| 136 | container: |
| 137 | cinder_volume: |
| 138 | readOnlyRootFilesystem: true |
| 139 | privileged: true |
| 140 | cinder_backup: |
| 141 | container: |
| 142 | cinder_backup: |
| 143 | privileged: true |
| 144 | dependencies: |
| 145 | static: |
| 146 | api: |
| 147 | jobs: |
| 148 | - cinder-db-sync |
| 149 | - cinder-ks-user |
| 150 | - cinder-ks-endpoints |
| 151 | - cinder-rabbit-init |
| 152 | backup: |
| 153 | jobs: |
| 154 | - cinder-db-sync |
| 155 | - cinder-ks-user |
| 156 | - cinder-ks-endpoints |
| 157 | - cinder-rabbit-init |
| 158 | scheduler: |
| 159 | jobs: |
| 160 | - cinder-db-sync |
| 161 | - cinder-ks-user |
| 162 | - cinder-ks-endpoints |
| 163 | - cinder-rabbit-init |
| 164 | volume: |
| 165 | jobs: |
| 166 | - cinder-db-sync |
| 167 | - cinder-ks-user |
| 168 | - cinder-ks-endpoints |
| 169 | - cinder-rabbit-init |
| 170 | volume_usage_audit: |
| 171 | jobs: |
| 172 | - cinder-db-sync |
| 173 | - cinder-ks-user |
| 174 | - cinder-ks-endpoints |
| 175 | - cinder-rabbit-init |
| 176 | conf: |
| 177 | enable_iscsi: true |
| 178 | cinder: |
| 179 | DEFAULT: |
| 180 | default_volume_type: purestorage |
| 181 | enabled_backends: purestorage |
| 182 | backends: |
| 183 | rbd1: null |
| 184 | purestorage: |
| 185 | volume_backend_name: purestorage |
| 186 | volume_driver: <FILL IN> |
| 187 | san_ip: <FILL IN> |
| 188 | pure_api_token: <FILL IN> |
| 189 | # pure_nvme_transport: |
| 190 | use_multipath_for_image_xfer: true |
| 191 | pure_eradicate_on_delete: true |
| 192 | manifests: |
| 193 | deployment_backup: false |
| 194 | job_backup_storage_init: false |
| 195 | job_storage_init: false |
| 196 | |
| 197 | nova_helm_values: |
| 198 | conf: |
| 199 | enable_iscsi: true |
| 200 | |
| 201 | .. admonition:: About ``conf.enable_iscsi`` |
| 202 | :class: info |
| 203 | |
| 204 | The ``enable_iscsi`` setting is required to allow the Nova instances to |
| 205 | expose volumes by making the `/dev` devices available to the containers, |
| 206 | not necessarily to use iSCSI as the storage protocol. In this case, the |
| 207 | Cinder instances will use the volume driver specified in ``volume_driver``. |
| 208 | |
| Mohammed Naser | 90128aa | 2024-04-29 13:21:58 -0400 | [diff] [blame] | 209 | ******** |
| 210 | StorPool |
| 211 | ******** |
| 212 | |
| 213 | Using StorPool as a storage backend requires additional configuration to ensure |
| 214 | proper integration. These adjustments include network settings and file system mounts. |
| 215 | |
| 216 | Configure Cinder to use StorPool by implementing the following settings: |
| 217 | |
| 218 | .. code-block:: yaml |
| 219 | |
| 220 | cinder_helm_values: |
| 221 | storage: storpool |
| 222 | pod: |
| 223 | useHostNetwork: |
| 224 | volume: true |
| 225 | mounts: |
| 226 | cinder_volume: |
| 227 | volumeMounts: |
| 228 | - name: etc-storpool-conf |
| 229 | mountPath: /etc/storpool.conf |
| 230 | readOnly: true |
| 231 | - name: etc-storpool-conf-d |
| 232 | mountPath: /etc/storpool.conf.d |
| 233 | readOnly: true |
| 234 | volumes: |
| 235 | - name: etc-storpool-conf |
| 236 | hostPath: |
| 237 | type: File |
| 238 | path: /etc/storpool.conf |
| 239 | - name: etc-storpool-conf-d |
| 240 | hostPath: |
| 241 | type: Directory |
| 242 | path: /etc/storpool.conf.d |
| 243 | dependencies: |
| 244 | static: |
| 245 | api: |
| 246 | jobs: |
| 247 | - cinder-db-sync |
| 248 | - cinder-ks-user |
| 249 | - cinder-ks-endpoints |
| 250 | - cinder-rabbit-init |
| 251 | scheduler: |
| 252 | jobs: |
| 253 | - cinder-db-sync |
| 254 | - cinder-ks-user |
| 255 | - cinder-ks-endpoints |
| 256 | - cinder-rabbit-init |
| 257 | volume: |
| 258 | jobs: |
| 259 | - cinder-db-sync |
| 260 | - cinder-ks-user |
| 261 | - cinder-ks-endpoints |
| 262 | - cinder-rabbit-init |
| 263 | volume_usage_audit: |
| 264 | jobs: |
| 265 | - cinder-db-sync |
| 266 | - cinder-ks-user |
| 267 | - cinder-ks-endpoints |
| 268 | - cinder-rabbit-init |
| 269 | conf: |
| 270 | cinder: |
| 271 | DEFAULT: |
| 272 | enabled_backends: hybrid-2ssd |
| 273 | default_volume_type: hybrid-2ssd |
| 274 | backends: |
| 275 | rbd1: null |
| 276 | hybrid-2ssd: |
| 277 | volume_backend_name: hybrid-2ssd |
| 278 | volume_driver: cinder.volume.drivers.storpool.StorPoolDriver |
| 279 | storpool_template: hybrid-2ssd |
| 280 | report_discard_supported: true |
| 281 | manifests: |
| 282 | deployment_backup: false |
| 283 | job_backup_storage_init: false |
| 284 | job_storage_init: false |
| 285 | |
| 286 | nova_helm_values: |
| 287 | conf: |
| 288 | enable_iscsi: true |
| 289 | |
| 290 | .. admonition:: About ``conf.enable_iscsi`` |
| 291 | :class: info |
| 292 | |
| 293 | The ``enable_iscsi`` setting is required to allow the Nova instances to |
| 294 | expose volumes by making the `/dev` devices available to the containers, |
| 295 | not necessarily to use iSCSI as the storage protocol. In this case, the |
| 296 | StorPool devices will be exposed as block devices to the containers. |