Existem entre nós (cefovodov) aqueles que não gostam de "extremo profissional"?
É improvável - caso contrário, não daríamos cambalhotas com este produto extremamente interessante e engraçado.
Muitos dos que estavam envolvidos na exploração do Ceph encontraram um que não fosse muito frequente (mas bastante pouco frequente), mas às vezes exigia um caso - para conectar o Ceph via iSCSI ou FC. Porque Bem, por exemplo, envie uma imagem do Ceph para um servidor Windows ou Solaris ainda não virtualizado. Ou virtualizado, mas através de um hipervisor que a Ceph não sabe fazer e, como sabemos, existem o suficiente. Por exemplo? Bem, por exemplo, HyperV ou ESXi, que são usados ativamente. E se surgir a tarefa de enviar a imagem do Ceph para a máquina convidada, isso se tornará uma tarefa muito interessante.
Então, dado:
- já está executando o cluster Ceph
- uma imagem existente que deve ser enviada via iSCSI
- Nome da piscina mypool , nome da imagem myimage
Estamos começando
Antes de tudo, quando falamos sobre FC ou iSCSI, obtemos entidades como um iniciador e um destino. O destino é realmente um servidor, o iniciador é um cliente. Nossa tarefa é enviar a imagem Ceph ao iniciador com o mínimo de trabalho. Então, temos que implantar o alvo. Mas onde, em qual computador?
Felizmente, no cluster Ceph, temos pelo menos um componente cujo endereço IP é fixo e no qual um dos componentes mais importantes do Ceph está configurado, e esse componente é um monitor. Assim, no monitor, definimos o alvo iSCSI (e o iniciador ao mesmo tempo, pelo menos para testes). Fiz isso no CentOS, mas para qualquer outra distribuição a solução também é adequada - basta colocar os pacotes da maneira que for aceitável na sua distribuição.
# yum -y install iscsi-initiator-utils targetcliQual é o objetivo dos pacotes instalados?
- targetcli - Utilitário de gerenciamento de destino SCSI Linux para kernel Linux
- iscsi-initor-utils - um pacote com utilitários usados para controlar o iniciador iSCSI integrado ao kernel do Linux novamente
Para enviar uma imagem via iSCSI para o iniciador, existem duas opções para o desenvolvimento de eventos - use o back-end do espaço do usuário do destino ou conecte a imagem como um dispositivo de bloco visível ao sistema operacional e exporte-o via iSCSI. Iremos pela segunda maneira - o back-end do espaço do usuário ainda está em um estado "experimental" e não está pronto para uso produtivo. Além disso, existem armadilhas com as quais você pode falar muito e (oh, horror!) Discutir.
Se usarmos pelo menos alguma distribuição estável com um longo ciclo de suporte, teremos o núcleo de uma versão antiga-antiga. Por exemplo, no CentOS7 é 3.10. *, No CentOS8 é 4.19. E estamos interessados em um núcleo de pelo menos 5,3 (mas em vez de 5,4) e um mais novo. Porque Porque, por padrão, as imagens no Ceph têm um conjunto de opções anexado que não é compatível com os kernels antigos. Portanto, conectamos o repositório a um novo kernel para nossa distribuição (por exemplo, para o CentOS é elrepo), instalamos um novo kernel e reinicializamos o sistema para trabalhar com o novo kernel:
- Conecte-se ao monitor selecionado para o experimento
- Conectamos repositórios elrepo de acordo com as instruções - elrepo.org/tiki/tiki-index.php
- Instale o kernel: yum -y --enablerepo = elrepo-kernel install kernel-ml
- Reiniciamos o servidor com o monitor (afinal, temos três monitores, certo?)
Conecte a imagem como um dispositivo de bloco
# rbd map mypool/myimage
/dev/rbd0Resta apenas configurar o destino. Neste exemplo, configurarei o destino no chamado modo de demonstração - sem autenticação, visível e acessível a todos. Em um ambiente produtivo, você provavelmente desejará configurar a autenticação - mas isso é um pouco fora do escopo do exercício apenas por diversão de hoje.
Crie um back-end com o nome disk1 mapeado para o arquivo / dev / rbd / mypool / myimage. O arquivo especificado é um link simbólico para / dev / rbd0 criado automaticamente pelo daemon udev. Utilizamos um link simbólico porque o nome do dispositivo rbd pode mudar devido à ordem em que as imagens Ceph estão conectadas ao host.
Crie um back-end:
# targetcli /backstores/block create disk1 /dev/rbd/mypool/myimageCrie um destino iSCSI:
# targetcli /iscsi create iqn.2020-01.demo.ceph:mypoolConecte o back-end como LUN ao destino:
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/luns create /backstores/block/disk1Ajustamos 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=1Salve a configuração:
# targetcli saveconfigVerifique a disponibilidade do destino:
# iscsiadm -m discovery -t st -p 127.0.0.1:3260
127.0.0.1:3260,1 iqn.2020-01.demo.ceph:mypoolNós 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, cujo acesso é feito através do destino iSCSI. Para evitar problemas de inicialização, é melhor remover a unidade mapeada e o destino detectado do iniciador local:
# iscsiadm -m node --logout
# iscsiadm -m discoverydb -o delete -t st -p 127.0.0.1:3260Tudo o que resta é manter a configuração para que a imagem se conecte automaticamente e, após a conexão, o destino seja estratificado. O lançamento de um destino consiste em duas etapas - conectar o RBD e realmente iniciar o destino.
Primeiro, configure a conexão automática de imagens RBD ao host. Isso é feito adicionando linhas ao arquivo / etc / ceph / rbdmap:
# cat /etc/ceph/rbdmap
# RbdDevice Parameters
mypool/myimage id=admin
# systemctl enable rbdmapRestaurar a configuração de um destino é um pouco mais complicado - precisamos escrever a unidade para systemd, o que 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-targetTeste final - mais uma vez reiniciamos nosso monitor (agora é um destino iSCSI). Deve-se notar que, se não tivéssemos limpado a base do iniciador com o comando
iscsiadm -n discoverydb -o delete ... poderíamos ter um servidor que não estava carregando ou estava carregando por um longo tempo.
O que resta?
Configure o iniciador no servidor para o qual queremos enviar o destino.
Como garantir a resiliência do nosso alvo?
Da mesma forma, você pode configurar destinos em outros monitores e organizar caminhos múltiplos (o vmware entenderá isso e até funcionará, o Hyper-V não entenderá - são necessários bloqueios SCSI). Como o cliente Ceph do kernel não usa armazenamento em cache, isso é bastante funcional. Ou outra opção é criar um recurso de cluster de três componentes - um endereço IP de destino dedicado e os serviços rbdmap e scsi-target, além de gerenciar esse recurso por meio de ferramentas de cluster (quem disse o pacemaker?)
Em vez de um posfácio
Como você sabe, este artigo é uma pequena piada - mas tentei "de forma rápida e com exemplos" considerar vários tópicos bastante populares ao mesmo tempo - destino iSCSI, que pode não necessariamente exportar imagens Ceph - mas, por exemplo, exportar volumes LVM, o básico de trabalhar com o iniciador iSCSI ( como digitalizar um destino, como conectar-se a um destino, desconectar, excluir um registro de destino do banco de dados), escrever sua própria unidade para systemd e outros
Espero que, mesmo que você não repita todo o experimento por completo, pelo menos algo deste artigo seja útil para você.