| 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 | |
| 10 | ******** |
| 11 | Ceph RBD |
| 12 | ******** |
| 13 | |
| 14 | When using the integrated Ceph cluster provided with Atmosphere, no additional |
| 15 | configuration is needed for Cinder. The deployment process automatically |
| 16 | configures Cinder to use Ceph as the backend, simplifying setup and integration. |
| 17 | |
| 18 | *************** |
| 19 | Dell PowerStore |
| 20 | *************** |
| 21 | |
| 22 | In order to be able to use Dell PowerStore, you'll need to make sure that you |
| 23 | setup the hosts inside of your storage array. You'll also need to make sure |
| 24 | that they are not inside a host group or otherwise individual attachments will |
| 25 | not work. |
| 26 | |
| 27 | You can enable the native PowerStore driver for Cinder with the following |
| 28 | configuration inside your Ansible inventory: |
| 29 | |
| 30 | .. code-block:: yaml |
| 31 | |
| 32 | cinder_helm_values: |
| 33 | storage: powerstore |
| 34 | dependencies: |
| 35 | static: |
| 36 | api: |
| 37 | jobs: |
| 38 | - cinder-db-sync |
| 39 | - cinder-ks-user |
| 40 | - cinder-ks-endpoints |
| 41 | - cinder-rabbit-init |
| 42 | scheduler: |
| 43 | jobs: |
| 44 | - cinder-db-sync |
| 45 | - cinder-ks-user |
| 46 | - cinder-ks-endpoints |
| 47 | - cinder-rabbit-init |
| 48 | volume: |
| 49 | jobs: |
| 50 | - cinder-db-sync |
| 51 | - cinder-ks-user |
| 52 | - cinder-ks-endpoints |
| 53 | - cinder-rabbit-init |
| 54 | volume_usage_audit: |
| 55 | jobs: |
| 56 | - cinder-db-sync |
| 57 | - cinder-ks-user |
| 58 | - cinder-ks-endpoints |
| 59 | - cinder-rabbit-init |
| 60 | conf: |
| 61 | cinder: |
| 62 | DEFAULT: |
| 63 | enabled_backends: powerstore |
| 64 | default_volume_type: powerstore |
| 65 | backends: |
| 66 | rbd1: null |
| 67 | powerstore: |
| 68 | volume_backend_name: powerstore |
| 69 | volume_driver: cinder.volume.drivers.dell_emc.powerstore.driver.PowerStoreDriver |
| 70 | san_ip: <FILL IN> |
| 71 | san_login: <FILL IN> |
| 72 | san_password: <FILL IN> |
| 73 | storage_protocol: <FILL IN> # FC or iSCSI |
| 74 | manifests: |
| 75 | deployment_backup: true |
| 76 | job_backup_storage_init: true |
| 77 | job_storage_init: false |
| 78 | |
| 79 | nova_helm_values: |
| 80 | conf: |
| 81 | enable_iscsi: true |
| 82 | |
| 83 | .. admonition:: About ``conf.enable_iscsi`` |
| 84 | :class: info |
| 85 | |
| 86 | The ``enable_iscsi`` setting is required to allow the Nova instances to |
| 87 | expose volumes by making the `/dev` devices available to the containers, |
| 88 | not necessarily to use iSCSI as the storage protocol. In this case, the |
| 89 | PowerStore driver will use the storage protocol specified inside Cinder, |
| 90 | |
| 91 | ******** |
| 92 | StorPool |
| 93 | ******** |
| 94 | |
| 95 | Using StorPool as a storage backend requires additional configuration to ensure |
| 96 | proper integration. These adjustments include network settings and file system mounts. |
| 97 | |
| 98 | Configure Cinder to use StorPool by implementing the following settings: |
| 99 | |
| 100 | .. code-block:: yaml |
| 101 | |
| 102 | cinder_helm_values: |
| 103 | storage: storpool |
| 104 | pod: |
| 105 | useHostNetwork: |
| 106 | volume: true |
| 107 | mounts: |
| 108 | cinder_volume: |
| 109 | volumeMounts: |
| 110 | - name: etc-storpool-conf |
| 111 | mountPath: /etc/storpool.conf |
| 112 | readOnly: true |
| 113 | - name: etc-storpool-conf-d |
| 114 | mountPath: /etc/storpool.conf.d |
| 115 | readOnly: true |
| 116 | volumes: |
| 117 | - name: etc-storpool-conf |
| 118 | hostPath: |
| 119 | type: File |
| 120 | path: /etc/storpool.conf |
| 121 | - name: etc-storpool-conf-d |
| 122 | hostPath: |
| 123 | type: Directory |
| 124 | path: /etc/storpool.conf.d |
| 125 | dependencies: |
| 126 | static: |
| 127 | api: |
| 128 | jobs: |
| 129 | - cinder-db-sync |
| 130 | - cinder-ks-user |
| 131 | - cinder-ks-endpoints |
| 132 | - cinder-rabbit-init |
| 133 | scheduler: |
| 134 | jobs: |
| 135 | - cinder-db-sync |
| 136 | - cinder-ks-user |
| 137 | - cinder-ks-endpoints |
| 138 | - cinder-rabbit-init |
| 139 | volume: |
| 140 | jobs: |
| 141 | - cinder-db-sync |
| 142 | - cinder-ks-user |
| 143 | - cinder-ks-endpoints |
| 144 | - cinder-rabbit-init |
| 145 | volume_usage_audit: |
| 146 | jobs: |
| 147 | - cinder-db-sync |
| 148 | - cinder-ks-user |
| 149 | - cinder-ks-endpoints |
| 150 | - cinder-rabbit-init |
| 151 | conf: |
| 152 | cinder: |
| 153 | DEFAULT: |
| 154 | enabled_backends: hybrid-2ssd |
| 155 | default_volume_type: hybrid-2ssd |
| 156 | backends: |
| 157 | rbd1: null |
| 158 | hybrid-2ssd: |
| 159 | volume_backend_name: hybrid-2ssd |
| 160 | volume_driver: cinder.volume.drivers.storpool.StorPoolDriver |
| 161 | storpool_template: hybrid-2ssd |
| 162 | report_discard_supported: true |
| 163 | manifests: |
| 164 | deployment_backup: false |
| 165 | job_backup_storage_init: false |
| 166 | job_storage_init: false |
| 167 | |
| 168 | nova_helm_values: |
| 169 | conf: |
| 170 | enable_iscsi: true |
| 171 | |
| 172 | .. admonition:: About ``conf.enable_iscsi`` |
| 173 | :class: info |
| 174 | |
| 175 | The ``enable_iscsi`` setting is required to allow the Nova instances to |
| 176 | expose volumes by making the `/dev` devices available to the containers, |
| 177 | not necessarily to use iSCSI as the storage protocol. In this case, the |
| 178 | StorPool devices will be exposed as block devices to the containers. |