Há alguém entre nós (os cephistas) que não gosta de 'extremos profissionais'?
Dificilmente — caso contrário, não estaríamos nos envolvendo com este produto extremamente interessante e divertido.
Muitos daqueles que trabalharam com Ceph encontraram um caso que não é muito comum (na verdade, é bastante raro), mas às vezes solicitado — conectar Ceph via iSCSI ou FC. Por quê? Bem, por exemplo, para fornecer uma imagem do Ceph para um servidor Windows ou Solaris ainda não virtualizado. Ou para um virtualizado, mas através de um hypervisor que não suporta Ceph — e sabemos que existem muitos deles. Por exemplo? Bem, por exemplo, HyperV ou ESXi, que são amplamente utilizados. E se surgir a necessidade de fornecer uma imagem do Ceph para uma máquina virtual, isso se transforma em uma tarefa bastante interessante.
Então, temos:
- um cluster Ceph já funcionando
- uma imagem já existente que deve ser fornecida via iSCSI
- Nome do pool mypool, nome da imagem myimage
Vamos começar?
Antes de mais nada, quando falamos sobre FC ou iSCSI, aparecem entidades como iniciador (initiator) e alvo (target). O target é, na verdade, um servidor, o initiator — um cliente. Nossa tarefa é fornecer a imagem do Ceph para o iniciador com o mínimo de esforço possível. Portanto, precisamos configurar o target. Mas onde, em qual computador?
Felizmente, no cluster Ceph, temos pelo menos um componente cujo endereço IP é fixo e no qual está configurado um dos componentes mais importantes do Ceph, e esse componente é o monitor. Assim, no monitor, instalamos iSCSI target (e initiator também, pelo menos para testes). Eu fiz isso no CentOS, mas para qualquer outra distribuição a solução também é válida — basta instalar os pacotes da maneira que for aceitável para sua distribuição.
# yum -y install iscsi-initiator-utils targetcli
Qual é o propósito dos pacotes instalados?
- targetcli — utilitário de gerenciamento do SCSI target embutido no kernel Linux
- iscsi-initiator-utils — pacote com utilitários usados para gerenciar também o initiator iSCSI embutido no kernel Linux
Para fornecer uma imagem via iSCSI para o iniciador, há duas possibilidades — usar um backend de target em userspace ou conectar a imagem como um dispositivo de bloco visível para o sistema operacional e exportá-la via iSCSI. Nós vamos seguir o segundo caminho — o backend em userspace ainda está em estado "experimental" e não está totalmente pronto para uso produtivo. Além disso, ele possui armadilhas sobre as quais se pode falar muito e (ai, meu Deus!) debater.
Se estivermos usando uma distribuição estável com um longo ciclo de suporte, o kernel será de uma versão bem antiga. Por exemplo, no CentOS7 é 3.10.*, no CentOS8 é 4.19. E nos interessa um kernel de pelo menos 5.3 (ou mais provavelmente 5.4) ou mais recente. Por que? Porque, por padrão, as imagens no Ceph possuem um conjunto de opções habilitado, que não é compatível com kernels antigos. Isso significa que devemos conectar um repositório com um kernel novo para nossa distribuição (por exemplo, para CentOS é o elrepo), instalar o novo kernel e reiniciar o sistema para trabalhar com ele:
- Conectamo-nos ao monitor escolhido para o experimento
- Conectamos os repositórios elrepo seguindo as instruções —
- Instalamos o kernel: yum -y --enablerepo=elrepo-kernel install kernel-ml
- Reiniciamos o servidor com o monitor (temos três monitores, certo?)
Conectamos a imagem como um dispositivo de bloco
# rbd map mypool/myimage
/dev/rbd0
Só falta configurar o target. Neste exemplo, configurarei o target no chamado modo demo — sem autenticação, visível e acessível a todos. Em um ambiente produtivo, você provavelmente vai querer configurar a autenticação — mas isso está um pouco fora do escopo do exercício de hoje apenas por diversão.
Criamos um backend chamado disk1 mapeado para o arquivo /dev/rbd/mypool/myimage. O arquivo especificado é um link simbólico automaticamente criado pelo daemon udev para /dev/rbd0. Usamos especificamente o link simbólico, pois o nome do dispositivo rbd pode mudar devido à ordem de conexão das imagens Ceph ao host.
Criamos o backend:
# targetcli /backstores/block create disk1 /dev/rbd/mypool/myimage
Criamos o target iSCSI:
# targetcli /iscsi criar iqn.2020-01.demo.ceph:mypool
Conectamos o backend como LUN ao target:
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/luns create /backstores/block/disk1
Configuramos o target para o modo demo:
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set
> atributo demo_mode_write_protect=0
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set
> atributo generate_node_acls=1
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set
> atributo cache_dynamic_acls=1
Salvamos a configuração:
# targetcli saveconfig
Verificamos a existência do target:
# iscsiadm -m discovery -t st -p 127.0.0.1:3260
127.0.0.1:3260,1 iqn.2020-01.demo.ceph:mypool
Conectamos ao target:
# iscsiadm -m node --login
Entrando em [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] (múltiplos)
Login em [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] bem-sucedido.
Se você fez tudo corretamente, um novo disco aparecerá no servidor, que se apresenta como um dispositivo SCSI, mas na verdade é uma imagem de Ceph, acessível através de um alvo iSCSI. Para evitar problemas na inicialização, é melhor remover o disco conectado e o alvo detectado do iniciador local:
# iscsiadm -m node --logout
# iscsiadm -m discoverydb -o delete -t st -p 127.0.0.1:3260
Agora, tudo o que resta é persistir a configuração para que a imagem se conecte automaticamente e, após a conexão, o alvo seja iniciado. O início do alvo consiste em duas etapas — a conexão do RBD e, propriamente dito, a inicialização do alvo.
Primeiro, vamos configurar a conexão automática das imagens RBD ao host. Isso é feito adicionando linhas ao arquivo /etc/ceph/rbdmap:
# gato /etc/ceph/rbdmap
# RbdDevice Parameters
mypool/myimage id=admin
# systemctl enable rbdmap
A recuperação da configuração do alvo é um pouco mais complicada — precisamos escrever uma unidade para o systemd, que restaurará a configuração:
# cat /usr/lib/systemd/system/scsi-target.service
[Unit]
Descrição=Iniciar alvo iSCSI
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
O teste final — reiniciamos nosso monitor (que agora também é o alvo iSCSI). É importante notar que, se não tivéssemos limpado o banco de dados do iniciador com o comando iscsiadm -n discoverydb -o delete … poderíamos ter um servidor que não inicializa ou que leva muito tempo para inicializar.
O que resta?
Configurar o iniciador no servidor onde queremos fornecer o alvo.
Como garantir a alta disponibilidade do nosso alvo?
Pode-se configurar alvos semelhantes em outros monitores e configurar multipath (o VMware entenderá isso e funcionará, o Hyper-V não entenderá — lá são necessárias bloqueios SCSI). Uma vez que o cliente Ceph não utiliza cache no núcleo, isso é bastante viável. Outra opção é criar um recurso de cluster a partir de três componentes — um alvo dedicado e os serviços rbdmap e scsi-target, e gerenciar esse recurso através das ferramentas de clusterização (quem disse pacemaker?) endereços IP Como é evidente, este artigo é um pouco de brincadeira — mas tentei "rapidamente e com exemplos" abordar simultaneamente vários tópicos bastante populares — o alvo iSCSI, que pode não exportar necessariamente imagens Ceph — mas, por exemplo, exportar volumes LVM, os fundamentos do trabalho com o iniciador iSCSI (como escanear o alvo, como conectar ao alvo, desconectar, remover a entrada do alvo do banco de dados), escrever sua própria unidade para o systemd e alguns outros.
Em vez de epílogo
Espero que você tenha achado útil.
Espero que, mesmo que você não repita todo esse experimento na sua totalidade, ao menos algo deste artigo seja útil para você.
Fonte: habr.com
