Hai quen entre nós (tsefovodov) que non lles gusta o "extremo profesional"?
É improbable; se non, non estaríamos dando voltas con este produto extremadamente interesante e divertido.
Moitos usuarios de Ceph atoparon un caso de uso menos común (ou quizais incluso moi raro) pero ás veces útil: conectar Ceph a través de iSCSI ou FC. Por que? Por exemplo, servir unha imaxe de Ceph a un servidor que aínda non está virtualizado. Windows Ou Solaris. Ou un virtualizado, pero usando un hipervisor que non admite Ceph (e, como sabemos, hai moitos deses). Por exemplo? Ben, por exemplo, HyperV ou ESXi, que se usan activamente. E se xorde a tarefa de servir unha imaxe de Ceph a unha máquina invitada, convértese nun reto moi interesante.
Entón, dado:
- un clúster Ceph xa en execución
- unha imaxe xa existente que debe ser servida a través de iSCSI
- Nome da piscina a miña piscina, nome da imaxe miña imaxe
Comezar?
En primeiro lugar, cando falamos de FC ou iSCSI, temos entidades como o iniciador e o destino. O destino é en realidade un servidor, o iniciador é un cliente. A nosa tarefa é enviar a imaxe Ceph ao iniciador cun mínimo esforzo. Isto significa que debemos ampliar o obxectivo. Pero onde, en que ordenador?
Afortunadamente, nun clúster Ceph, temos polo menos un compoñente cun enderezo IP fixo e un dos compoñentes Ceph máis importantes configurado nel: o monitor. En consecuencia, configuramos un destino iSCSI no monitor (e un iniciador, polo menos para fins de proba). Fixen isto en CentOS, pero a solución funcionará tamén para calquera outra distribución: só tes que instalar os paquetes do xeito que sexa aceptable para a túa distribución.
# yum -y install iscsi-initiator-utils targetcli
Cal é o propósito dos paquetes instalados?
- targetcli — unha utilidade para xestionar o núcleo integrado Linux Destino SCSI
- iscsi-initiator-utils — un paquete con utilidades usadas para a xestión, de novo integrado no núcleo Linux Iniciador iSCSI
Para enviar unha imaxe a través de iSCSI ao iniciador, hai dúas opcións para o desenvolvemento de eventos: usar o backend do espazo de usuario do destino ou conectar a imaxe como un dispositivo de bloque visible para o sistema operativo e exportala a través de iSCSI. Imos polo segundo camiño: o backend do espazo de usuario aínda está nun estado "experimental" e non está lixeiramente preparado para o seu uso produtivo. Ademais, hai trampas con ela, sobre as que podes falar moito e (oh horror!) discutir.
Se empregamos calquera distribución estable cun ciclo de soporte moi longo, entón o noso núcleo é unha versión moi antiga. Por exemplo, en CentOS7 é 3.10.*, en CentOSA versión 8 é a 4.19. Pero interésanos o kernel 5.3 (e probablemente o 5.4) ou posterior. Por que? Porque, por defecto, as imaxes de Ceph teñen activadas un conxunto de opcións que son incompatibles cos kernels máis antigos. Isto significa que estamos activando un repositorio cun kernel novo para a nosa distribución (por exemplo, para CentOS (Este é elrepo), instala o novo kernel e reinicia o sistema para que funcione co novo kernel:
- Conéctese ao monitor seleccionado para o experimento
- Conectamos os repositorios de elrepo segundo as instrucións:
- Instale o núcleo: yum -y —enablerepo=elrepo-kernel install kernel-ml
- Reinicie o servidor co monitor (temos tres monitores, non?)
Conectando a imaxe como un dispositivo de bloque
# rbd map mypool/myimage
/dev/rbd0
Só queda configurar o destino. Neste exemplo, configurarei o destino no chamado. Modo de demostración: sen autenticación, visible e accesible para todos. Nun ambiente de produción, é probable que queiras configurar a autenticación, pero iso está un pouco fóra do alcance do exercicio de hoxe só por diversión.
Cree un backend chamado disk1 asociado co ficheiro /dev/rbd/mypool/myimage. O ficheiro especificado é unha ligazón simbólica creada automaticamente polo daemon udev a /dev/rbd0. Usamos unha ligazón simbólica porque o nome do dispositivo rbd pode cambiar dependendo da orde en que as imaxes Ceph estean conectadas ao host.
Crea un backend:
# targetcli /backstores/block create disk1 /dev/rbd/mypool/myimage
Crear un destino iSCSI:
# targetcli /iscsi create iqn.2020-01.demo.ceph:mypool
Conectamos o backend como un LUN ao destino:
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/luns create /backstores/block/disk1
Imos configurar o destino para o modo de demostración:
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set
> attribute demo_mode_write_protect=0
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set
> attribute generate_node_acls=1
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set
> attribute cache_dynamic_acls=1
Garda a configuración:
# targetcli saveconfig
Comprobación da presenza do obxectivo:
# iscsiadm -m discovery -t st -p 127.0.0.1:3260
127.0.0.1:3260,1 iqn.2020-01.demo.ceph:mypool
Conectamos o obxectivo:
# iscsiadm -m node --login
Logging in to [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] (multiple)
Login to [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] successful.
Se fixo todo correctamente, aparecerá un novo disco no servidor, que parece un dispositivo SCSI, pero en realidade é unha imaxe de Ceph, á que se accede a través dun destino iSCSI. Para evitar problemas de arranque, é mellor eliminar o disco conectado e o destino detectado do iniciador local:
# iscsiadm -m node --logout
# iscsiadm -m discoverydb -o delete -t st -p 127.0.0.1:3260
Só resta persistir a configuración para que a imaxe se conecte automaticamente e, tras a conexión, se estratifique o obxectivo. O lanzamento dun obxectivo consta de dous pasos: conectar o RBD e lanzar o obxectivo.
Primeiro, imos configurar a conexión automática das imaxes RBD ao host. Isto faise engadindo as seguintes liñas ao ficheiro /etc/ceph/rbdmap:
# cat /etc/ceph/rbdmap
# RbdDevice Parameters
mypool/myimage id=admin
# systemctl enable rbdmap
Restaurar a configuración de destino é un pouco máis complicado: necesitamos escribir unha unidade para systemd que restaure a configuración:
# cat /usr/lib/systemd/system/scsi-target.service
[Unit]
Description=Start iSCSI target
Despois=rede-en-liña.destinación rbdmap.servizo
Antes=remote-fs-pre.target
Desexos=rede-en-liña.destinación pre-servicios-remotos.destinación
[Servizo]
Tipo=unha soa vez
RemainAfterExit = si
ExecStart=/bin/targetcli restoreconfig
[Instalar]
WantedBy = multi-usuario.target
# systemload daemon-reload
# systemctl activar scsi-target
A proba final é reiniciar de novo o noso monitor (agora é un obxectivo iSCSI). Cómpre ter en conta que se non limparamos a base de datos do iniciador co comando iscsiadm -n discoverydb -o eliminar... podería acabar cun servidor que non carga ou tarda moito tempo en cargarse.
Que queda?
Configure o iniciador no servidor onde queremos enviar o destino.
Como garantir a tolerancia a fallos do noso obxectivo?
Do mesmo xeito, podes configurar destinos noutros monitores e configurar rutas múltiples (VMware entenderá isto e mesmo funcionará, pero Hyper-V non, xa que require bloqueos SCSI). Dado que o cliente Ceph no kernel non usa caché, isto é perfectamente factible. Outra opción é crear un recurso de clúster a partir de tres compoñentes: un dedicado enderezos IP target e os servizos rbdmap e scsi-target, e xestionar este recurso mediante ferramentas de agrupamento en clústeres (quen dixo pacemaker?)
No canto dunha palabra final
Como está claro, este artigo é un pouco unha broma, pero nel tentei considerar "rápido e con exemplos" varios temas bastante populares ao mesmo tempo - o destino iSCSI, que pode non exportar necesariamente imaxes Ceph - pero, por exemplo, exportar volumes LVM, os conceptos básicos de traballar cun iniciador iSCSI (como escanear un destino, como conectarse a un destino, desconectar, eliminar unha entrada de destino da base de datos), escribir a súa propia unidade para systemd e algúns outros
Espero que aínda que non repitas este experimento completo, polo menos algo deste artigo che sexa útil.
Fonte: www.habr.com
