Há entre nós (tsefovodov) que não gosta do “extremo profissional”?
É improvável - caso contrário não estaríamos nos deparando com este produto extremamente interessante e engraçado.
Muitos daqueles que estiveram envolvidos na operação do Ceph se depararam com um caso não muito frequente (ou melhor, muito raro), mas às vezes em demanda - conectar o Ceph via iSCSI ou FC. Para que? Bem, por exemplo, envie uma imagem do Ceph para um servidor Windows ou Solaris que ainda não foi virtualizado por algum motivo. Ou virtualizado, mas usando um hipervisor que não consegue fazer o Ceph - e, como sabemos, são muitos. Por exemplo? Bem, por exemplo, HyperV ou ESXi, que são usados ativamente. E se surgir a tarefa de servir uma imagem do Ceph para uma máquina convidada, isso se tornará uma tarefa muito interessante.
Então, dado:
- um cluster do Ceph já em execução
- uma imagem já existente que deve ser veiculada via iSCSI
- Nome do pool minha piscina, nome da imagem minha imagem
Começar?
Em primeiro lugar, quando falamos de FC ou iSCSI, temos entidades como iniciador e alvo. O destino é na verdade um servidor, o iniciador é um cliente. Nossa tarefa é enviar a imagem do Ceph ao iniciador com o mínimo de esforço. Isso significa que devemos expandir a meta. Mas onde, em que computador?
Felizmente, em um 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, instalamos um alvo iSCSI no monitor (e um iniciador ao mesmo tempo, pelo menos para testes). Fiz isso no CentOS, mas a solução também é adequada para qualquer outra distribuição - basta instalar os pacotes da forma que for aceitável na sua distribuição.
# yum -y install iscsi-initiator-utils targetcli
Qual é a finalidade dos pacotes instalados?
- targetcli — um utilitário para gerenciar o destino SCSI integrado ao kernel Linux
- iscsi-Initator-utils — um pacote com utilitários usados para gerenciar o iniciador iSCSI integrado ao kernel do Linux
Para enviar uma imagem via iSCSI ao iniciador, existem duas opções para o desenvolvimento de eventos - usar o backend do espaço do usuário do destino ou conectar a imagem como um dispositivo de bloco visível para o sistema operacional e exportá-la via iSCSI. Iremos pelo segundo caminho - o back-end do espaço do usuário ainda está em um estado “experimental” e um pouco não está pronto para uso produtivo. Além disso, há armadilhas sobre as quais você pode falar muito e (que horror!) discutir.
Se usarmos até mesmo uma distribuição um tanto estável com um longo ciclo de suporte, então o kernel que temos é uma versão muito antiga. Por exemplo, no CentOS7 é 3.10.*, no CentOS8 é 4.19. E estamos interessados em um kernel de pelo menos 5.3 (ou melhor, 5.4) e mais recente. Por que? Porque, por padrão, as imagens do Ceph têm um conjunto de opções habilitadas que não são compatíveis com kernels mais antigos. Isso significa que conectamos um repositório com um novo kernel para nossa distribuição (por exemplo, para CentOS é elrepo), instalamos o novo kernel e reinicializamos o sistema para funcionar com o novo kernel:
- Conecte-se ao monitor selecionado para o experimento
- Conectamos repositórios elrepo de acordo com as instruções -
- Instale o kernel: yum -y —enablerepo=elrepo-kernel install kernel-ml
- Reinicie o servidor com o monitor (temos três monitores, certo?)
Conectando a imagem como um dispositivo de bloco
# rbd map mypool/myimage
/dev/rbd0
Resta apenas configurar o alvo. Neste exemplo, configurarei o alvo no chamado. modo de demonstração - sem autenticação, visível e acessível a todos. Em um ambiente de produção, você provavelmente desejará configurar a autenticação - mas isso está um pouco fora do escopo do exercício de hoje, apenas por diversão.
Crie um backend chamado disk1 associado ao arquivo /dev/rbd/mypool/myimage. O arquivo especificado é um link simbólico criado automaticamente pelo daemon udev para /dev/rbd0. Usamos um link simbólico porque o nome do dispositivo rbd pode mudar dependendo da ordem em que as imagens Ceph estão conectadas ao host.
Crie um back-end:
# targetcli /backstores/block create disk1 /dev/rbd/mypool/myimage
Crie um destino iSCSI:
# targetcli /iscsi create iqn.2020-01.demo.ceph:mypool
Conectamos o back-end como um LUN ao destino:
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/luns create /backstores/block/disk1
Vamos configurar o alvo para o modo de demonstração:
# 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
Salve a configuração:
# targetcli saveconfig
Verificando a presença do alvo:
# 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 alvo:
# 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 você fez tudo corretamente, um novo disco aparecerá no servidor, que se parece com um dispositivo SCSI, mas na verdade é uma imagem do Ceph, acessada por meio de um destino iSCSI. Para evitar problemas de 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
Resta persistir a configuração para que a imagem seja conectada automaticamente e, após a conexão, o alvo seja estratificado. O lançamento de um alvo consiste em duas etapas: conectar o RBD e realmente lançar o alvo.
Primeiro, vamos configurar a conexão automática das imagens RBD ao host. Isso é feito adicionando as seguintes linhas ao arquivo /etc/ceph/rbdmap:
# cat /etc/ceph/rbdmap
# RbdDevice Parameters
mypool/myimage id=admin
# systemctl enable rbdmap
Restaurar a configuração de destino é um pouco mais complicado - precisamos escrever uma unidade para o systemd que irá restaurar a configuração:
# 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
O teste final é reiniciar nosso monitor novamente (agora é um alvo iSCSI). Deve-se notar que se não tivéssemos limpado o banco de dados do iniciador com o comando iscsiadm -n descobertadb -o excluir ... você pode acabar com um servidor que não carrega ou demora muito para carregar.
O que resta?
Configure o iniciador no servidor para onde queremos enviar o alvo.
Como garantir a tolerância a falhas do nosso alvo?
Da mesma forma, você pode configurar destinos em outros monitores e configurar o multipath (o VMware entenderá isso e até funcionará, o Hyper-V não entenderá - requer bloqueios SCSI). Como o cliente Ceph do kernel não usa cache, isso é bastante viável. Ou outra opção é criar um recurso de cluster de três componentes - um endereço IP de destino dedicado e serviços rbdmap e scsi-target, e gerenciar esse recurso por meio de ferramentas de cluster (quem disse pacemaker?)
em vez de um epílogo
Como está claro, este artigo é uma piada - mas nele tentei “rapidamente e com exemplos” considerar vários tópicos bastante populares ao mesmo tempo - alvo iSCSI, que pode não necessariamente exportar imagens Ceph - mas por exemplo, exportar volumes LVM, o básico para trabalhar com um iniciador iSCSI (como verificar um destino, como conectar-se a um destino, desconectar, excluir uma entrada de destino do banco de dados), escrever sua própria unidade para systemd e alguns outros
Espero que mesmo que você não repita todo esse experimento por completo, pelo menos algo deste artigo seja útil para você.
Fonte: habr.com