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 dos que estiveron implicados no funcionamento de Ceph atopáronse cunha non moi frecuente (ou máis ben moi pouco frecuente) pero ás veces demandada: conectar Ceph a través de iSCSI ou FC. Para qué? Ben, por exemplo, envíe unha imaxe de Ceph a un servidor Windows ou Solaris que aínda non foi virtualizado por algún motivo. Ou un virtualizado, pero usando un hipervisor que non pode facer Ceph - e, como sabemos, hai moitos deles. 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 convidada, isto convértese nunha tarefa moi emocionante.
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 cuxo enderezo IP está fixado e no que se configura un dos compoñentes máis importantes de Ceph, e ese compoñente é o monitor. En consecuencia, instalamos un destino iSCSI no monitor (e un iniciador ao mesmo tempo, polo menos para probas). Fixen isto en CentOS, pero a solución tamén é adecuada para calquera outra distribución: só precisa instalar os paquetes da forma que sexa aceptable na súa distribución.
# yum -y install iscsi-initiator-utils targetcli
Cal é o propósito dos paquetes instalados?
- targetcli — unha utilidade para xestionar o destino SCSI integrado no núcleo de Linux
- iscsi-initiator-utils — un paquete con utilidades utilizadas para xestionar o iniciador iSCSI integrado no núcleo de Linux
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 usamos incluso unha distribución algo estable cun ciclo de soporte longo, entón o núcleo que temos é unha versión antiga e antiga. Por exemplo, en CentOS7 é 3.10.*, en CentOS8 é 4.19. E estamos interesados nun núcleo de polo menos 5.3 (ou mellor dito 5.4) e máis recente. Por que? Porque por defecto as imaxes Ceph teñen un conxunto de opcións activadas que non son compatibles con núcleos máis antigos. Isto significa que conectamos un repositorio cun novo kernel para a nosa distribución (por exemplo, para CentOS isto é elrepo), instalamos o novo kernel e reiniciamos o sistema para traballar 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
After=network-online.target rbdmap.service
Before=remote-fs-pre.target
Wants=network-online.target remote-fs-pre.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/targetcli restoreconfig
[Install]
WantedBy=multi-user.target
# systemctl daemon-reload
# systemctl enable 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?
De igual xeito, pode configurar obxectivos noutros monitores e configurar rutas múltiples (vmware entenderá isto e mesmo funcionará, Hyper-V non o entenderá: require bloqueos SCSI). Dado que o cliente Ceph do núcleo non usa caché, isto é bastante viable. Ou outra opción é crear un recurso de clúster de tres compoñentes: un enderezo IP de destino dedicado e servizos rbdmap e scsi-target, e xestionar este recurso mediante ferramentas de agrupación (quen dixo marcapasos?)
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