Ir para o conteúdoIr para navegação de página: página anterior [tecla de acesso p]/próxima página [tecla de acesso n]
documentation.suse.com / Documentação do SUSE Enterprise Storage 7.1 / Guia de Implantação / Implantando o cluster do Ceph / Implantação de serviços adicionais
Aplica-se a SUSE Enterprise Storage 7.1

9 Implantação de serviços adicionais

9.1 Instalação do gateway iSCSI

iSCSI é um protocolo SAN (Storage Area Network) que permite aos clientes (denominados iniciadores) enviar comandos SCSI para dispositivos de armazenamento SCSI (destinos) em servidores remotos. O SUSE Enterprise Storage 7.1 inclui um recurso que abre o gerenciamento de armazenamento do Ceph para clientes heterogêneos, como Microsoft Windows* e VMware* vSphere, por meio do protocolo iSCSI. O acesso de múltiplos caminhos do iSCSI fornece disponibilidade e escalabilidade para esses clientes, e o protocolo iSCSI padronizado também proporciona uma camada adicional de isolamento de segurança entre os clientes e o cluster do SUSE Enterprise Storage 7.1. O recurso de configuração é denominado ceph-iscsi. Ao usar o ceph-iscsi, os administradores de armazenamento do Ceph podem definir volumes replicados, aprovisionados dinamicamente e altamente disponíveis com suporte a instantâneos apenas leitura, clones de leitura-gravação e redimensionamento automático com Dispositivo de Blocos RADOS (RBD, RADOS Block Device) do Ceph. Em seguida, os administradores podem exportar os volumes por um host de gateway ceph-iscsi único ou por vários hosts de gateway com suporte a failover de múltiplos caminhos. Os hosts do Linux, Microsoft Windows e VMware podem se conectar aos volumes pelo protocolo iSCSI, que os torna disponíveis como qualquer outro dispositivo de blocos SCSI. Isso significa que os clientes do SUSE Enterprise Storage 7.1 podem executar com eficácia um subsistema completo de infraestrutura de armazenamento de blocos no Ceph, que fornece todos os recursos e benefícios de uma SAN convencional, permitindo um crescimento futuro.

Este capítulo apresenta informações detalhadas sobre como configurar uma infraestrutura de cluster do Ceph juntamente com um iSCSI Gateway para que os hosts de clientes possam usar os dados armazenados remotamente como dispositivos de armazenamento local por meio do protocolo iSCSI.

9.1.1 Armazenamento em blocos iSCSI

iSCSI é uma implementação do comando SCSI (Small Computer System Interface) definido pelo Protocolo IP, especificado na RFC 3720. O iSCSI é implementado como um serviço em que o cliente (iniciador) comunica-se com o servidor (destino) por meio de uma sessão na porta TCP 3260. O endereço IP e a porta do destino iSCSI são chamados de portal iSCSI, em que um destino pode ser exposto por meio de um ou mais portais. A combinação de um destino e de um ou mais portais é denominada grupo de portais de destino (TPG, Target Portal Group).

O protocolo da camada de link de dados subjacente ao iSCSI costuma ser a Ethernet. Mais especificamente, as infraestruturas modernas do iSCSI usam 10 GigE Ethernet, ou redes mais rápidas, para alcançar o throughput ideal. A conectividade 10 Gigabit Ethernet entre o iSCSI Gateway e o cluster de back end do Ceph é altamente recomendada.

9.1.1.1 Destino iSCSI do kernel do Linux

Originalmente, o destino iSCSI do kernel do Linux era chamado de LIO, referente a linux-iscsi.org, o domínio original e o site do projeto na Web. Por algum tempo, nada menos do que quatro implementações de destino iSCSI concorrentes estavam disponíveis para a plataforma Linux, mas o LIO acabou prevalecendo como único destino iSCSI de referência. O código de kernel de linha principal do LIO usa o nome simples, porém um pouco ambíguo, "destino", para diferenciar entre "núcleo de destino" e uma variedade de módulos de destino de front end e back end.

Seguramente, o módulo de front end mais usado é o iSCSI. No entanto, o LIO também suporta FC (Fibre Channel), FCoE (Fibre Channel over Ethernet) e vários outros protocolos de front end. Neste momento, apenas o protocolo iSCSI é suportado pelo SUSE Enterprise Storage.

O módulo de back end de destino usado com mais frequência é aquele capaz de simplesmente reexportar qualquer dispositivo de blocos disponível no host de destino. Esse módulo é denominado iblock. No entanto, o LIO também tem um módulo de back end específico do RBD que suporta acesso paralelizado de E/S de múltiplos caminhos às imagens RBD.

9.1.1.2 Iniciadores iSCSI

Esta seção apresenta informações resumidas sobre os iniciadores iSCSI usados nas plataformas Linux, Microsoft Windows e VMware.

9.1.1.2.1 Linux

O iniciador padrão para a plataforma Linux é open-iscsi. O open-iscsi inicia um daemon, iscsid, que o usuário pode utilizar para descobrir destinos iSCSI em qualquer portal especificado, efetuar login em destinos e mapear volumes iSCSI. O iscsid comunica-se com a camada intermediária do SCSI para criar dispositivos de blocos no kernel, e que depois o kernel poderá tratar como qualquer outro dispositivo de blocos SCSI no sistema. É possível implantar o iniciador open-iscsi em conjunto com o recurso Device Mapper Multipath (dm-multipath) para oferecer um dispositivo de blocos iSCSI altamente disponível.

9.1.1.2.2 Microsoft Windows e Hyper-V

O iniciador iSCSI padrão para o sistema operacional Microsoft Windows é o Microsoft iSCSI. O serviço iSCSI pode ser configurado por meio de uma GUI (Graphical User Interface – Interface Gráfica do Usuário) e suporta E/S de múltiplos caminhos para alta disponibilidade.

9.1.1.2.3 VMware

O iniciador iSCSI padrão para o VMware vSphere e o ESX é o do software VMware ESX: vmkiscsi. Quando habilitado, ele pode ser configurado pelo cliente do vSphere ou pelo comando vmkiscsi-tool. Em seguida, você pode formatar volumes de armazenamento conectados por meio do adaptador de armazenamento iSCSI do vSphere com VMFS e usá-los como qualquer outro dispositivo de armazenamento da VM. O iniciador do VMware também suporta E/S de múltiplos caminhos para alta disponibilidade.

9.1.2 Informações gerais sobre ceph-iscsi

O ceph-iscsi combina os benefícios dos Dispositivos de Blocos RADOS com a versatilidade universal do iSCSI. Ao executar o ceph-iscsi em um host de destino iSCSI (conhecido como iSCSI Gateway), qualquer aplicativo que tenha que usar armazenamento de blocos poderá se beneficiar do Ceph, mesmo que ele não reconheça nenhum protocolo de cliente do Ceph. Em vez disso, os usuários podem utilizar o iSCSI ou qualquer outro protocolo de front end de destino para se conectar a um destino LIO, o que converte todas as operações de E/S de destino em armazenamento RBD.

Cluster do Ceph com único iSCSI Gateway
Figura 9.1: Cluster do Ceph com único iSCSI Gateway

O ceph-iscsi apresenta alta disponibilidade inerente e suporta operações de múltiplos caminhos. Portanto, os hosts downstream do iniciador podem usar vários iSCSI Gateways para alta disponibilidade e escalabilidade. Durante a comunicação com uma configuração do iSCSI com mais de um gateway, os iniciadores podem equilibrar a carga das solicitações iSCSI entre vários gateways. Em caso de falha no gateway, estado temporariamente inacessível ou desabilitado para manutenção, a E/S continuará por meio de outro gateway de forma visível.

Cluster do Ceph com vários gateways iSCSI
Figura 9.2: Cluster do Ceph com vários gateways iSCSI

9.1.3 Considerações de implantação

Uma configuração mínima do SUSE Enterprise Storage 7.1 com ceph-iscsi consiste nos seguintes componentes:

  • Um cluster de armazenamento do Ceph. O cluster do Ceph consiste em um mínimo de quatro servidores físicos que hospedam, pelo menos, oito OSDs (Object Storage Daemons – Daemons de Armazenamento de Objetos) cada. Nesse tipo de configuração, três nós OSD também são dobrados como host do monitor (MON).

  • Um servidor de destino iSCSI que executa o destino iSCSI do LIO, configurado por meio do ceph-iscsi.

  • Um host do iniciador iSCSI, executando o open-iscsi (Linux), o Iniciador Microsoft iSCSI (Microsoft Windows) ou qualquer outra implementação de iniciador iSCSI compatível.

Uma configuração de produção recomendada do SUSE Enterprise Storage 7.1 com ceph-iscsi consiste em:

  • Um cluster de armazenamento do Ceph. Um cluster de produção do Ceph consiste em qualquer número de nós OSD (normalmente, mais do que 10), cada um costuma executar de 10 a 12 daemons de armazenamento de objetos (OSDs, Object Storage Daemons), com um mínimo de três hosts MON dedicados.

  • Vários servidores de destino iSCSI que executam o destino iSCSI do LIO, configurados por meio do ceph-iscsi. Para failover e equilíbrio de carga do iSCSI, esses servidores devem executar um kernel com suporte ao módulo target_core_rbd. Os pacotes de atualização estão disponíveis no canal de manutenção do SUSE Linux Enterprise Server.

  • Qualquer número de hosts do iniciador iSCSI, executando o open-iscsi (Linux), o Iniciador Microsoft iSCSI (Microsoft Windows) ou qualquer outra implementação de iniciador iSCSI compatível.

9.1.4 Instalação e configuração

Esta seção descreve as etapas para instalar e configurar um iSCSI Gateway no SUSE Enterprise Storage.

9.1.4.1 Implantar o gateway iSCSI em um cluster do Ceph

A implantação do Gateway iSCSI do Ceph segue o mesmo procedimento da implantação de outros serviços do Ceph: por meio do cephadm. Para ver mais detalhes, consulte a Seção 8.3.5, “Implantando Gateways iSCSI”.

9.1.4.2 Criando imagens RBD

As imagens RBD são criadas no armazenamento do Ceph e, em seguida, exportadas para o iSCSI. É recomendável usar um pool RADOS dedicado para essa finalidade. Você pode criar um volume de qualquer host capaz de se conectar com seu cluster de armazenamento usando o utilitário de linha de comando rbd do Ceph. Para isso, o cliente deve ter pelo menos um arquivo de configuração mínima ceph.conf e as credenciais apropriadas de autenticação no CephX.

Para criar um novo volume para exportação subsequente por meio do iSCSI, use o comando rbd create, especificando o tamanho do volume em megabytes. Por exemplo, para criar um volume de 100 GB chamado testvol no pool denominado iscsi-images, execute:

cephuser@adm > rbd --pool iscsi-images create --size=102400 testvol

9.1.4.3 Exportando imagens RBD por meio do iSCSI

Para exportar imagens RBD por meio do iSCSI, você pode usar a interface da Web Ceph Dashboard ou o utilitário gwcli do ceph-iscsi. Nesta seção, vamos nos concentrar apenas no gwcli, demonstrando como criar um destino iSCSI que exporta uma imagem RBD usando a linha de comando.

Nota
Nota

As imagens RBD com as seguintes propriedades não podem ser exportadas por meio do iSCSI:

  • imagens com o recurso de registro em diário habilitado

  • imagens com uma unidade de distribuição menor do que 4096 bytes

Como root, insira o container do Gateway iSCSI:

# cephadm enter --name CONTAINER_NAME

Como root, inicie a interface de linha de comando do Gateway iSCSI:

# gwcli

Vá para iscsi-targets e crie um destino com o nome iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol:

gwcli >  /> cd /iscsi-targets
gwcli >  /iscsi-targets> create iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol

Crie os gateways iSCSI especificando o nome e o endereço ip deles:

gwcli >  /iscsi-targets> cd iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/gateways
gwcli >  /iscsi-target...tvol/gateways> create iscsi1 192.168.124.104
gwcli >  /iscsi-target...tvol/gateways> create iscsi2 192.168.124.105
Dica
Dica

Use o comando help para mostrar a lista de comandos disponíveis no nó da configuração atual.

Adicione a imagem RBD com o nome testvol no pool iscsi-images:

gwcli >  /iscsi-target...tvol/gateways> cd /disks
gwcli >  /disks> attach iscsi-images/testvol

Mapeie a imagem RBD para o destino:

gwcli >  /disks> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/disks
gwcli >  /iscsi-target...testvol/disks> add iscsi-images/testvol
Nota
Nota

Você pode usar ferramentas de nível mais baixo, como targetcli, para consultar a configuração local, mas sem a modificar.

Dica
Dica

Você pode usar o comando ls para revisar a configuração. Alguns nós da configuração também suportam o comando info, que podem ser usados para exibir informações mais detalhadas.

Por padrão, a autenticação ACL está habilitada, portanto, esse destino ainda não está acessível. Consulte a Seção 9.1.4.4, “Autenticação e controle de acesso” para obter mais informações sobre autenticação e controle de acesso.

9.1.4.4 Autenticação e controle de acesso

A autenticação iSCSI é flexível e inclui muitas possibilidades de autenticação.

9.1.4.4.1 Desabilitando a autenticação ACL

Nenhuma Autenticação significa que qualquer iniciador poderá acessar qualquer LUN no destino correspondente. Você pode habilitar Nenhuma Autenticação desabilitando a autenticação ACL:

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hosts
gwcli >  /iscsi-target...testvol/hosts> auth disable_acl
9.1.4.4.2 Usando a autenticação ACL

Ao usar a autenticação ACL com base no nome do iniciador, apenas os iniciadores definidos têm permissão para se conectar. Faça o seguinte para definir um iniciador:

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hosts
gwcli >  /iscsi-target...testvol/hosts> create iqn.1996-04.de.suse:01:e6ca28cc9f20

Os iniciadores definidos poderão se conectar, mas apenas terão acesso às imagens RBD que foram explicitamente adicionadas aos iniciadores:

gwcli >  /iscsi-target...:e6ca28cc9f20> disk add rbd/testvol
9.1.4.4.3 Habilitando a autenticação CHAP

Além da ACL, você pode habilitar a autenticação CHAP especificando um nome de usuário e uma senha para cada iniciador:

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hosts/iqn.1996-04.de.suse:01:e6ca28cc9f20
gwcli >  /iscsi-target...:e6ca28cc9f20> auth username=common12 password=pass12345678
Nota
Nota

Os nomes de usuário devem ter entre 8 e 64 caracteres e podem incluir caracteres alfanuméricos, ., @, -, _ ou :.

As senhas devem ter entre 12 e 16 caracteres e podem incluir caracteres alfanuméricos, @, -, _ ou /.

Se preferir, você também poderá habilitar a autenticação CHAP mútua especificando os parâmetros mutual_username e mutual_password no comando auth.

9.1.4.4.4 Configurando descoberta e autenticação mútua

A autenticação Discovery é independente dos métodos de autenticação anteriores. Ela requer credenciais para navegação, é opcional e pode ser configurada por:

gwcli >  /> cd /iscsi-targets
gwcli >  /iscsi-targets> discovery_auth username=du123456 password=dp1234567890
Nota
Nota

Os nomes de usuário devem ter entre 8 e 64 caracteres e podem incluir apenas letras, ., @, -, _ ou :.

As senhas devem ter entre 12 e 16 caracteres e podem incluir apenas letras, @, -, _ ou /.

Você também pode especificar os parâmetros mutual_username e mutual_password no comando discovery_auth.

Use o seguinte comando para desabilitar a autenticação Discovery:

gwcli >  /iscsi-targets> discovery_auth nochap

9.1.4.5 Definindo configurações avançadas

É possível configurar o ceph-iscsi com parâmetros avançados, que depois são passados para o destino de E/S do LIO. Os parâmetros são divididos nos parâmetros target e disk.

Atenção
Atenção

Exceto se indicado de outra forma, não é recomendável mudar a configuração padrão desses parâmetros.

9.1.4.5.1 Visualizando configurações de destino

Você pode ver o valor dessas configurações usando o comando info:

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol
gwcli >  /iscsi-target...i.SYSTEM-ARCH:testvol> info

E mudar uma configuração usando o comando reconfigure:

gwcli >  /iscsi-target...i.SYSTEM-ARCH:testvol> reconfigure login_timeout 20

As configurações de target disponíveis são:

default_cmdsn_depth

Profundidade padrão do CmdSN (Command Sequence Number – Número de Sequência do Comando). Limita a quantidade de solicitações pendentes que um iniciador iSCSI pode ter em qualquer momento.

default_erl

Nível de recuperação de erro padrão.

login_timeout

Valor de tempo de espera de login em segundos.

netif_timeout

Tempo de espera de falha da NIC em segundos.

prod_mode_write_protect

Se definida como 1, impede gravações em LUNs.

9.1.4.5.2 Visualizando configurações de disco

Você pode ver o valor dessas configurações usando o comando info:

gwcli >  /> cd /disks/rbd/testvol
gwcli >  /disks/rbd/testvol> info

E mudar uma configuração usando o comando reconfigure:

gwcli >  /disks/rbd/testvol> reconfigure rbd/testvol emulate_pr 0

As configurações de disk disponíveis são:

block_size

Tamanho do bloco do dispositivo subjacente.

emulate_3pc

Se definida como 1, habilita Cópia de Terceiros.

emulate_caw

Se definida como 1, habilita Comparar e Gravar.

emulate_dpo

Se definida como 1, ativa o recurso Disable Page Out (Desabilitar Saída de Página).

emulate_fua_read

Se definida como 1 habilita a leitura de Force Unit Access (Forçar Acesso de Unidade).

emulate_fua_write

Se definida como 1, habilita a gravação de Force Unit Access (Forçar Acesso de Unidade).

emulate_model_alias

Se definida como 1, usa o nome do dispositivo de back end para o álias do modelo.

emulate_pr

Se definida como 0, o suporte para Reservas SCSI, incluindo Reservas de Grupo Persistentes, será desabilitado. Enquanto estiver desabilitado, o iSCSI Gateway do SES pode ignorar o estado de reserva, resultando em melhor latência de solicitação.

Dica
Dica

A recomendação é definir backstore_emulate_pr como 0 se os iniciadores iSCSI não exigirem suporte para Reserva SCSI.

emulate_rest_reord

Se definida como 0, o Modificador de Algoritmo de Fila terá Reordenação Restrita.

emulate_tas

Se definida como 1, habilita o Status Interrompido da Tarefa.

emulate_tpu

Se definida como 1, habilita a Anulação do Mapeamento de Aprovisionamento Dinâmico.

emulate_tpws

Se definida como 1, habilita a Mesma Gravação de Aprovisionamento Dinâmico.

emulate_ua_intlck_ctrl

Se definida como 1, habilita o Interbloqueio de Atenção de Unidade.

emulate_write_cache

Se definida como 1, ativa a Habilitação de Gravação de Cache.

enforce_pr_isids

Se definida como 1, assegura o uso obrigatório de ISIDs de reserva persistentes.

is_nonrot

Se definida como 1, o backstore será um dispositivo não rotacional.

max_unmap_block_desc_count

Número máximo de descritores de blocos para UNMAP.

max_unmap_lba_count:

Número máximo de LBAs para UNMAP.

max_write_same_len

Tamanho máximo para WRITE_SAME.

optimal_sectors

Tamanho da solicitação ideal em setores.

pi_prot_type

Tipo de proteção DIF.

queue_depth

Profundidade da fila.

unmap_granularity

Granularidade de UNMAP.

unmap_granularity_alignment

Alinhamento da granularidade de UNMAP.

force_pr_aptpl

Quando habilitada, o LIO sempre gravará o estado de reserva persistente no armazenamento persistente, mesmo que o cliente não o tenha solicitado usando aptpl=1. Isso não tem efeito com o back end do RBD do kernel para LIO, ele sempre mantém o estado de reserva persistente. O ideal é que a opção target_core_rbd force-o como “1” e emita um erro se alguém tentar desabilitá-lo pela configuração.

unmap_zeroes_data

Afeta se o LIO divulgará ou não o LBPRZ para os iniciadores SCSI, indicando que os zeros serão lidos novamente de uma região seguindo UNMAP ou WRITE SAME com um bit de anulação de mapeamento.

9.1.5 Exportando imagens de dispositivo de blocos RADOS por meio do tcmu-runner

O ceph-iscsi suporta os dois backstores rbd (com base no kernel) e user:rbd (tcmu-runner), tornando todo o gerenciamento transparente e independente do backstore.

Atenção
Atenção: Prévia de tecnologia

Atualmente, as implantações do iSCSI Gateway com base no tcmu-runner estão na versão Technology Preview.

Diferentemente das implantações do iSCSI Gateway baseadas em kernel, os iSCSI Gateways com base em tcmu-runner não oferecem suporte a E/S de múltiplos caminhos ou Reservas Persistentes SCSI.

Para exportar a imagem do Dispositivo de Blocos RADOS usando o tcmu-runner, tudo o que você precisar fazer é especificar o backstore user:rbd ao anexar o disco:

gwcli >  /disks> attach rbd/testvol backstore=user:rbd
Nota
Nota

Ao usar o tcmu-runner, o recurso exclusive-lock deve estar habilitado na imagem RBD exportada.