6 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 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. 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 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.
6.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.
6.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.
6.1.2 Iniciadores iSCSI #
Esta seção apresenta informações resumidas sobre os iniciadores iSCSI usados nas plataformas Linux, Microsoft Windows e VMware.
6.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.
6.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.
6.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.
6.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.
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.
6.3 Considerações de implantação #
Uma configuração mínima do SUSE Enterprise Storage 7 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 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 (costuma ser mais do que 10), com cada um executando normalmente de 10 a 12 OSDs (Object Storage Daemons – Daemons de Armazenamento de Objetos), com pelo menos 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ódulotarget_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.
6.4 Instalação e configuração #
Esta seção descreve as etapas para instalar e configurar um iSCSI Gateway no SUSE Enterprise Storage.
6.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 5.4.3.5, “Implantando Gateways iSCSI”.
6.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 testvol6.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.
As imagens RBD com as seguintes propriedades não podem ser exportadas por meio do iSCSI:
imagens com o recurso de
registro em diáriohabilitadoimagens com uma
unidade de distribuiçãomenor do que 4096 bytes
Como root, insira o container do
Gateway iSCSI:
root # cephadm enter --name CONTAINER_NAME
Como root, inicie a interface de
linha de comando do Gateway iSCSI:
root # 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-targetsgwcli >/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/gatewaysgwcli >/iscsi-target...tvol/gateways> create iscsi1 192.168.124.104gwcli >/iscsi-target...tvol/gateways> create iscsi2 192.168.124.105
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 /disksgwcli >/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/disksgwcli >/iscsi-target...testvol/disks> add iscsi-images/testvol
Você pode usar ferramentas de nível mais baixo, como
targetcli, para consultar a configuração local, mas sem
a modificar.
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 6.4.4, “Autenticação e controle de acesso” para obter mais informações sobre autenticação e controle de acesso.
6.4.4 Autenticação e controle de acesso #
A autenticação iSCSI é flexível e inclui muitas possibilidades de autenticação.
6.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/hostsgwcli >/iscsi-target...testvol/hosts> auth disable_acl
6.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/hostsgwcli >/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/testvol6.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:e6ca28cc9f20gwcli >/iscsi-target...:e6ca28cc9f20> auth username=common12 password=pass12345678
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.
6.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-targetsgwcli >/iscsi-targets> discovery_auth username=du123456 password=dp1234567890
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 nochap6.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.
Exceto se indicado de outra forma, não é recomendável mudar a configuração padrão desses parâmetros.
6.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:testvolgwcli >/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.
6.4.5.2 Visualizando configurações de disco #
Você pode ver o valor dessas configurações usando o comando
info:
gwcli >/> cd /disks/rbd/testvolgwcli >/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
1habilita 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.
DicaA recomendação é definir
backstore_emulate_prcomo0se 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çãotarget_core_rbdforce-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.
6.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.
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
Ao usar o tcmu-runner, o recurso
exclusive-lock deve estar habilitado na imagem RBD
exportada.