El despliegue de Cinder que se describe en esta sección es aplicable a configuraciones de Juno que ejecuten Oracle Solaris 11.3 SRU 2 o versiones posteriores.
En versiones anteriores de OpenStack sin compatibilidad con SAN, había que configurar el servicio de volúmenes de Cinder para que se ejecutara en el host de destino si se usaba el controlador iSCSI de ZFS.
Con la compatibilidad de redes de área de almacenamiento (SAN) en Cinder, puede usar SSH para configurar varios backends de hosts de almacenamiento y definir el tipo de volumen de estos hosts para determinar cómo se los usa. En este tipo de despliegues, tanto el paquete de Cinder como todos los servicios de Cinder se instalan solo en el host iniciador, que normalmente es el host que también funciona como nodo de cálculo.
No es necesario instalar el paquete de OpenStack en los hosts de destino remotos. Estos hosts simplemente proporcionan los discos LUN al host iniciador basado en COMSTAR.
El despliegue correcto de sistemas remotos para almacenamiento tiene los siguientes requisitos:
Configuración del archivo /etc/cinder/cinder.conf.
Otorgamiento del perfil de derechos adecuado al usuario designado.
Instalación manual de paquetes adicionales.
En las siguientes secciones se describen estos requisitos en detalle.
Después de instalar el paquete de Cinder en el host iniciador, edite la sección [DEFAULT] del archivo /etc/cinder/cinder.conf.
Consulte el siguiente ejemplo como guía para comprender las definiciones del archivo de configuración.
[DEFAULT] my_ip = localhost osapi_volume_workers = 1 auth_strategy = keystone #num_volume_device_scan_tries = 6 os-volume-api-version = 2 scheduler_driver=cinder.scheduler.filter_scheduler.FilterScheduler enabled_backends=zfsdriver-1, zfsdriver-2, zfsdriver-3, zfsdriver-4, zfsdriver-5 [zfsdriver-1] volume_group=zvolumes-1 volume_driver=cinder.volume.drivers.solaris.zfs.ZFSVolumeDriver volume_backend_name=ZFS_LOCAL zfs_volume_base = rpool/cinder san_is_local = True debug=true verbose=true [zfsdriver-2] volume_group=zvolumes-2 volume_driver=cinder.volume.drivers.solaris.zfs.ZFSISCSIDriver volume_backend_name=ZFS_REMOTE zfs_volume_base = rpool/cinder san_ip = 10.134.13.38 san_login = jdoe san_password = password debug=true verbose=true [zfsdriver-3] volume_group=zvolumes-3 volume_driver=cinder.volume.drivers.solaris.zfs.ZFSFCDriver volume_backend_name=ZFS_REMOTE_FC zfs_volume_base = rpool/fc san_ip = 10.134.13.38 san_login = jdoe san_password = password debug=true verbose=true [zfsdriver-4] volume_group=zvolumes-4 volume_driver=cinder.volume.drivers.solaris.zfs.ZFSISCSIDriver volume_backend_name=ZFS_REMOTE zfs_volume_base = rpool/cinder/zq san_ip = 10.134.13.38 san_login = jdoe san_password = password debug=true verbose=true [zfsdriver-5] volume_group=zvolumes-5 volume_driver=cinder.volume.drivers.solaris.zfs.ZFSISCSIDriver volume_backend_name=ZFS_REMOTE zfs_volume_base = rpool/zq san_ip = 10.134.63.182 san_login = jdoe san_password = password debug=true verbose=true
Muestra los hosts de backend activados. En este ejemplo, hay 5 hosts de backend definidos.
Los hosts de backend usan 3 controladores ZFS (ZFSVolumeDriver, ZFSISCSIDriver y ZFSFCDriver) en 3 hosts. De estos hosts, uno es local (localhost) y los otros son remotos (10.134.13.38 y 10.134.63.182).
Define un tipo de volumen con el nombre especificado. Los siguientes comandos de ejemplo realizan estas acciones, respectivamente:
# cinder type-create type-remote # cinder type-key type-remote set volume_backend_name=ZFS_REMOTE # cinder create --display-name t1 --volume-type type-remote
En el ejemplo anterior, cada comando realiza las siguientes acciones:
Crea un nuevo tipo de volumen.
Asigna el nombre de backend al nuevo tipo de volumen.
Crea un nuevo volumen según el nuevo tipo de volumen.
Una vez que se ejecuta el último comando, se crea el nuevo volumen t1 en uno de los backends con el nombre ZFS_REMOTE según las reglas de filtros.
Especifica el juego de datos base para los nuevos volúmenes de ZFS en cada backend de volumen.
Como todos los controladores de ZFS se basan en el controlador de SAN, debe configurar los parámetros san_*.
Los comandos se ejecutan en un host de backend, ya sea de manera local o remota con SSH. De esta manera, para cada backend, debe configurar el parámetro san_is_local = True o el parámetro san_ip*, pero no ambos.
Parámetros opcionales para depuración. Puede omitir la configuración de estos parámetros.
Después de haber configurado Cinder correctamente, al mostrar estos servicios se despliega el estado de cada servicio.
# cinder service-list +------------+--------------+------+---------+-------+--------------------+----------+ | Binary | Host | Zone | Status | State | Updated_at | Disabled | | | | | | | | Reason | +------------+--------------+------+---------+-------+--------------------+----------+ | cinder- | | | | | 2015-10-13 | | | backup | host-2 | nova | enabled | up | T19:22:45.000000 | None | | | | | | | | | | cinder- | | | | | 2015-10-13 | | | scheduler | host-2 | nova | enabled | up | T19:22:43.000000 | None | | | | | | | | | | cinder- | | | | | 2015-10-13 | | | volume | host-2 | nova | enabled | down | T18:31:41.000000 | None | | | | | | | | | | cinder- | host-2 | | | | 2015-10-13 | | | volume | @zfsdriver-1 | nova | enabled | up | T19:22:46.000000 | None | | | | | | | | | | cinder- | host-2 | | | | 2015-10-13 | | | volume | @zfsdriver-2 | nova | enabled | up | T19:22:47.000000 | None | | | | | | | | | | cinder- | host-2 | | | | 2015-10-13 | | | volume | @zfsdriver-3 | nova | enabled | up | T19:22:48.000000 | None | | | | | | | | | | cinder- | host-2 | | | | 2015-10-13 | | | volume | @zfsdriver-4 | nova | enabled | up | T19:22:47.000000 | None | | | | | | | | | | cinder- | host-2 | | | | 2015-10-13 | | | volume | @zfsdriver-5 | nova | enabled | up | T19:22:48.000000 | None | | | | | | | | | | cinder- | host-2 | | | | 2015-10-13 | | | volume | @zfsdriver-6 | nova | enabled | down | T18:32:55.000000 | None | +------------+--------------+------+---------+-------+--------------------+----------+
Para permitir que el usuario definido mediante san_login use los destinos remotos, se le debe otorgar el perfil de derechos adecuado. En el siguiente ejemplo, se muestra cómo crear el perfil de derechos para el usuario.
# useradd -s /usr/bin/pfbash -m jdoe # passwd jdoe password # profiles -p "Cinder Storage management" profiles:Cinder Storage management> set desc="Cinder Storage management on target host" profiles:Cinder Storage management> add profiles="File System Management" profiles:Cinder Storage management> add auths="solaris.smf.modify.stmf" profiles:Cinder Storage management> add cmd=/usr/sbin/itadm profiles:Cinder Storage management:itadm> set euid=0 profiles:Cinder Storage management:itadm> end profiles:Cinder Storage management> add cmd=/usr/sbin/stmfadm profiles:Cinder Storage management:stmfadm> set euid=0 profiles:Cinder Storage management:stmfadm> end profiles:Cinder Storage management> add cmd=/usr/sbin/zfs profiles:Cinder Storage management:zfs> set priv=sys_config,sys_mount profiles:Cinder Storage management:zfs> end profiles:Cinder Storage management> exit # usermod -P "Cinder Storage management" jdoe
Para obtener más información sobre perfiles y derechos, consulte Protección de los usuarios y los procesos en Oracle Solaris 11.3.
Para activar un host remoto como destino, siga estos pasos en el host remoto:
Instale el paquete group/feature/storage-server en el host remoto.
# pkg install storage-server
Active los siguientes servicios en el host:
svc:/system/stmf:default
svc:/network/iscsi/target:default
Por ejemplo:
remote-host# svcadm enable stmf remote-host# svcadm enable -r svc:/network/iscsi/target:default
Inicialice y configure la lista de control de acceso (ACL) para el zfs_volume_base definido.
Por ejemplo, supongamos que tiene la definición zfs_volume_base=rpool/fc en el archivo de configuración. A continuación, debe ejecutar los siguientes comandos:
# chmod A+user:cinder:add_subdirectory:allow /rpool/fc # zfs allow cinder clone,create,destroy,mount,snapshot rpool/fc