Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Aplica-se a SUSE Enterprise Storage 5

10 Instalação do iSCSI Gateway

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 inclui uma interface 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 de isolamento de segurança entre os clientes e o cluster do SUSE Enterprise Storage. O recurso de configuração é denominado lrbd. Ao usar o lrbd, 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 RBD (RADOS Block Device – Dispositivo de Blocos RADOS) do Ceph. Em seguida, os administradores podem exportar os volumes por um gateway lrbd ú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 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.

10.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 de 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 TPG (Target Portal Group – Grupo de Portais de Destino).

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

10.1.1 Destino iSCSI do kernel do Linux

Originalmente, o destino iSCSI do kernel do Linux era chamado de LIO para linux-iscsi.org, o domínio original e o site do projeto. 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.

10.1.2 Iniciadores iSCSI

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

10.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.

10.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.

10.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.

10.2 Informações gerais sobre lrbd

O lrbd combina os benefícios dos Dispositivos de Blocos RADOS com a versatilidade universal do iSCSI. Ao executar o lrbd em um host de destino iSCSI (conhecido como gateway lrbd), qualquer aplicativo que tenha que usar armazenamento em 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 10.1: Cluster do Ceph com único iSCSI Gateway

O lrbd 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 iSCSI Gateways
Figura 10.2: Cluster do Ceph com vários iSCSI Gateways

10.3 Considerações de implantação

Uma configuração mínima do SUSE Enterprise Storage com lrbd 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 lrbd.

  • 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 com lrbd 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 lrbd. 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.

10.4 Instalação e configuração

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

10.4.1 Implantar o iSCSI Gateway em um cluster do Ceph

É possível implantar o iSCSI Gateway durante o processo de implantação do cluster do Ceph ou adicioná-lo a um cluster existente usando o DeepSea.

Para incluir o iSCSI Gateway durante o processo de implantação do cluster, consulte a Seção 4.5.1.2, “Atribuição de função”.

Para adicionar o iSCSI Gateway a um cluster existente, consulte o Seção 1.2, “Adicionando novas funções aos nós”.

10.4.2 Criar 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, execute:

root # rbd --pool iscsi create --size=102400 testvol

O comando acima cria um volume RBD no formato padrão 2.

Nota
Nota

A partir do SUSE Enterprise Storage 3, o formato padrão do volume é 2, e o formato 1 foi descontinuado. No entanto, você ainda pode criar volumes no formato 1 descontinuado com a opção --image-format 1.

10.4.3 Exportar imagens RBD por meio do iSCSI

Para exportar imagens RBD por meio do iSCSI, use o utilitário lrbd. O lrbd permite criar, revisar e modificar a configuração de destino iSCSI, que usa o formato JSON.

Dica
Dica: Importar mudanças para o openATTIC

Quaisquer mudanças feitas na configuração do iSCSI Gateway com o comando lrbd não ficam visíveis no DeepSea e no openATTIC. Para importar as mudanças manuais, você precisa exportar a configuração do iSCSI Gateway para um arquivo:

root@minion > lrbd -o /tmp/lrbd.conf

Em seguida, copie-a no master Salt para que o DeepSea e o openATTIC possam vê-la:

root@minion > scp /tmp/lrbd.conf ses5master:/srv/salt/ceph/igw/cache/lrbd.conf

Por fim, edite o /srv/pillar/ceph/stack/global.yml e defina:

igw_config: default-ui

Para editar a configuração, use lrbd -e ou lrbd --edit. Esse comando invocará o editor padrão, conforme definido pela variável de ambiente EDITOR. Você pode anular esse comportamento definindo a opção -E, além da -e.

Veja a seguir um exemplo de configuração para

  • dois hosts do iSCSI Gateway chamados iscsi1.example.com e iscsi2.example.com,

  • definindo um único destino iSCSI com o IQN (iSCSI Qualified Name – Nome Qualificado iSCSI) iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol,

  • com uma única LU (Logical Unit – Unidade Lógica) iSCSI,

  • com base em uma imagem RBD denominada testvol no pool RADOS rbd

  • e exportando o destino por meio de dois portais chamados "east" e "west":

{
    "auth": [
        {
            "target": "iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol",
            "authentication": "none"
        }
    ],
    "targets": [
        {
            "target": "iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol",
            "hosts": [
                {
                    "host": "iscsi1.example.com",
                    "portal": "east"
                },
                {
                    "host": "iscsi2.example.com",
                    "portal": "west"
                }
            ]
        }
    ],
    "portals": [
        {
            "name": "east",
            "addresses": [
                "192.168.124.104"
            ]
        },
        {
            "name": "west",
            "addresses": [
                "192.168.124.105"
            ]
        }
    ],
    "pools": [
        {
            "pool": "rbd",
            "gateways": [
                {
                    "target": "iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol",
                    "tpg": [
                        {
                            "image": "testvol"
                        }
                    ]
                }
            ]
        }
    ]
    }

Sempre que você fizer referência a um nome de host na configuração, observe que ele deverá corresponder à saída do comando uname -n do iSCSI Gateway.

O JSON editado é armazenado nos atributos estendidos (xattrs) de um único objeto RADOS por pool. Esse objeto está disponível aos hosts do gateway em que o JSON foi editado e também a todos os hosts do gateway conectados ao mesmo cluster do Ceph. Nenhuma informação de configuração é armazenada localmente no gateway lrbd.

Para ativar a configuração, armazene-a no cluster do Ceph e execute uma das seguintes opções (como root):

  • Execute o comando lrbd (sem opções adicionais) na linha de comando,

ou

  • Reinicie o serviço lrbd com service lrbd restart.

O "serviço” lrbd não opera nenhum daemon em segundo plano. Em vez disso, ele simplesmente invoca o comando lrbd. Esse tipo de serviço é conhecido como "monoestável".

Você também deve habilitar o lrbd para configuração automática na inicialização do sistema. Para fazer isso, execute o comando systemctl enable lrbd.

A configuração acima reflete uma definição simples de único gateway. A configuração do lrbd pode ser muito mais complexa e eficiente. O pacote RPM lrbd vem com um conjunto completo de exemplos de configuração, que você pode consultar acessando o conteúdo do diretório /usr/share/doc/packages/lrbd/samples após a instalação. Os exemplos também estão disponíveis em https://github.com/SUSE/lrbd/tree/master/samples.

10.4.4 Configurações opcionais

As configurações a seguir podem ser úteis em alguns ambientes. Para imagens, existem os atributos uuid, lun, retries, sleep e retry_errors. Os dois primeiros, uuid e lun, permitem codificar “uuid” ou “lun” para determinada imagem. Você pode especificar um deles para uma imagem. retries, sleep e retry_errors afetam as tentativas de mapear uma imagem RBD.

"pools": [
    {
        "pool": "rbd",
        "gateways": [
        {
        "host": "igw1",
        "tpg": [
                    {
                        "image": "archive",
                        "uuid": "12345678-abcd-9012-efab-345678901234",
                        "lun": "2",
                        "retries": "3",
                        "sleep": "4",
                        "retry_errors": [ 95 ],
                        [...]
                    }
                ]
            }
        ]
    }
]

10.4.5 Configurações avançadas

É possível configurar o lrbd com parâmetros avançados, que depois são passados para o destino de E/S do LIO. Os parâmetros são divididos em componentes de armazenamento iSCSI e de backup que, em seguida, podem ser especificados nas seções "targets” e "tpg", respectivamente, da configuração lrbd.

Atenção
Atenção

Não é recomendável mudar a configuração padrão desses parâmetros.

"targets": [
    {
        [...]
        "tpg_default_cmdsn_depth": "64",
        "tpg_default_erl": "0",
        "tpg_login_timeout": "10",
        "tpg_netif_timeout": "2",
        "tpg_prod_mode_write_protect": "0",
    }
]

Veja a seguir uma descrição das opções:

tpg_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.

tpg_default_erl

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

tpg_login_timeout

Valor de tempo de espera de login em segundos.

tpg_netif_timeout

Tempo de espera de falha da NIC em segundos.

tpg_prod_mode_write_protect

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

"pools": [
    {
        "pool": "rbd",
        "gateways": [
        {
        "host": "igw1",
        "tpg": [
                    {
                        "image": "archive",
                        "backstore_block_size": "512",
                        "backstore_emulate_3pc": "1",
                        "backstore_emulate_caw": "1",
                        "backstore_emulate_dpo": "0",
                        "backstore_emulate_fua_read": "0",
                        "backstore_emulate_fua_write": "1",
                        "backstore_emulate_model_alias": "0",
                        "backstore_emulate_rest_reord": "0",
                        "backstore_emulate_tas": "1",
                        "backstore_emulate_tpu": "0",
                        "backstore_emulate_tpws": "0",
                        "backstore_emulate_ua_intlck_ctrl": "0",
                        "backstore_emulate_write_cache": "0",
                        "backstore_enforce_pr_isids": "1",
                        "backstore_fabric_max_sectors": "8192",
                        "backstore_hw_block_size": "512",
                        "backstore_hw_max_sectors": "8192",
                        "backstore_hw_pi_prot_type": "0",
                        "backstore_hw_queue_depth": "128",
                        "backstore_is_nonrot": "1",
                        "backstore_max_unmap_block_desc_count": "1",
                        "backstore_max_unmap_lba_count": "8192",
                        "backstore_max_write_same_len": "65535",
                        "backstore_optimal_sectors": "8192",
                        "backstore_pi_prot_format": "0",
                        "backstore_pi_prot_type": "0",
                        "backstore_queue_depth": "128",
                        "backstore_unmap_granularity": "8192",
                        "backstore_unmap_granularity_alignment": "4194304"
                    }
                ]
            }
        ]
    }
]

Veja a seguir uma descrição das opções:

backstore_block_size

Tamanho do bloco do dispositivo subjacente.

backstore_emulate_3pc

Se definida como 1, habilita Third Party Copy (Cópia de Terceiros).

backstore_emulate_caw

Se definida como 1, habilita Compare (Comparar) e Write (Gravar).

backstore_emulate_dpo

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

backstore_emulate_fua_read

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

backstore_emulate_fua_write

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

backstore_emulate_model_alias

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

backstore_emulate_rest_reord

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

backstore_emulate_tas

Se definida como 1, habilita o Task Aborted Status (Status Interrompido da Tarefa).

backstore_emulate_tpu

Se definida como 1, habilita Thin Provisioning Unmap (Anulação do Mapeamento de Aprovisionamento Dinâmico).

backstore_emulate_tpws

Se definida como 1, habilita Thin Provisioning Write Same (Mesma Gravação de Aprovisionamento Dinâmico).

backstore_emulate_ua_intlck_ctrl

Se definida como 1, habilita Unit Attention Interlock (Interbloqueio de Atenção de Unidade).

backstore_emulate_write_cache

Se definida como 1, ativa o recurso Write Cache Enable (Habilitação de Gravação de Cache).

backstore_enforce_pr_isids

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

backstore_fabric_max_sectors

Número máximo de setores que a malha pode transferir de uma vez.

backstore_hw_block_size

Tamanho do bloco de hardware em bytes.

backstore_hw_max_sectors

Número máximo de setores que o hardware pode transferir de uma vez.

backstore_hw_pi_prot_type

Se for diferente de zero, a proteção DIF será habilitada no hardware subjacente.

backstore_hw_queue_depth

Profundidade da fila de hardware.

backstore_is_nonrot

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

backstore_max_unmap_block_desc_count

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

backstore_max_unmap_lba_count:

Número máximo de LBAs para UNMAP.

backstore_max_write_same_len

Tamanho máximo para WRITE_SAME.

backstore_optimal_sectors

Tamanho da solicitação ideal em setores.

backstore_pi_prot_format

Formato da proteção DIF.

backstore_pi_prot_type

Tipo de proteção DIF.

backstore_queue_depth

Profundidade da fila.

backstore_unmap_granularity

Granularidade de UNMAP.

backstore_unmap_granularity_alignment

Alinhamento da granularidade de UNMAP.

Para destinos, os atributos tpg permitem o ajuste dos parâmetros de kernel. Use com cuidado.

"targets": [
{
    "host": "igw1",
    "target": "iqn.2003-01.org.linux-iscsi.generic.x86:sn.abcdefghijk",
    "tpg_default_cmdsn_depth": "64",
    "tpg_default_erl": "0",
    "tpg_login_timeout": "10",
    "tpg_netif_timeout": "2",
    "tpg_prod_mode_write_protect": "0",
    "tpg_t10_pi": "0"
}
Dica
Dica

Se um site precisa de LUNs atribuídos estaticamente, atribua números a cada LUN.

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

Desde a versão 5, o SUSE Enterprise Storage fornece um back end RBD de espaço de usuário para tcmu-runner (consulte man 8 tcmu-runner para obter detalhes).

Atenção
Atenção: Technology Preview

Atualmente, as implantações do iSCSI Gateway com base no tcmu-runner estão na versão Technology Preview. Consulte o Capítulo 10, Instalação do iSCSI Gateway para obter instruções sobre a implantação do iSCSI Gateway baseada em kernel com o lrbd.

Diferentemente das implantações do iSCSI Gateway lrbd 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.

Atualmente, como o DeepSea e o openATTIC não suportam implantações por tcmu-runner, você precisa gerenciar a instalação, a implantação e o monitoramento manualmente.

10.5.1 Instalação

No nó do iSCSI Gateway, instale o pacote tcmu-runner-handler-rbd da mídia do SUSE Enterprise Storage 5 juntamente com as dependências de pacote libtcmu1 e tcmu-runner. Instale o pacote targetcli-fb para fins de configuração. Observe que o pacote targetcli-fb não é compatível a versão “não fb” do pacote targetcli.

Confirme se o serviço tcmu-runner systemd está em execução:

root # systemctl enable tcmu-runner
tcmu-gw:~ # systemctl status tcmu-runner
● tcmu-runner.service - LIO Userspace-passthrough daemon
  Loaded: loaded (/usr/lib/systemd/system/tcmu-runner.service; static; vendor
  preset: disabled)
    Active: active (running) since ...

10.5.2 Configuração e implantação

Crie uma imagem de Dispositivo de Blocos RADOS no cluster do Ceph existente. No exemplo a seguir, usaremos uma imagem de 10 G chamada “tcmu-lu” localizada no pool “rbd”.

Após a criação da imagem de Dispositivo de Blocos RADOS, execute targetcli e verifique se o gerenciador RBD tcmu-runner (plug-in) está disponível:

root # targetcli
targetcli shell version 2.1.fb46
Copyright 2011-2013 by Datera, Inc and others.
For help on commands, type 'help'.

/> ls
o- / ................................... [...]
  o- backstores ........................ [...]
...
  | o- user:rbd ......... [Storage Objects: 0]

Crie uma entrada de configuração de backstore para a imagem RBD:

/> cd backstores/user:rbd
/backstores/user:rbd> create tcmu-lu 10G /rbd/tcmu-lu
Created user-backed storage object tcmu-lu size 10737418240.

Crie uma entrada de configuração de transporte iSCSI. No exemplo a seguir, o IQN de destino "iqn.2003-01.org.linux-iscsi.tcmu-gw.x8664:sn.cb3d2a3a” é automaticamente gerado pelo targetcli para ser usado como identificador exclusivo de destino iSCSI:

/backstores/user:rbd> cd /iscsi
/iscsi> create
Created target iqn.2003-01.org.linux-iscsi.tcmu-gw.x8664:sn.cb3d2a3a.
Created TPG 1.
Global pref auto_add_default_portal=true
Created default portal listening on all IPs (0.0.0.0), port 3260.

Crie uma entrada ACL para o(s) iniciador(es) iSCSI que você deseja conectar ao destino. No exemplo a seguir, o IQN do iniciador "iqn.1998-01.com.vmware:esxi-872c4888” é usado:

/iscsi> cd
iqn.2003-01.org.linux-iscsi.tcmu-gw.x8664:sn.cb3d2a3a/tpg1/acls/
/iscsi/iqn.20...a3a/tpg1/acls> create iqn.1998-01.com.vmware:esxi-872c4888

Por fim, vincule a configuração de backstore do RBD criada anteriormente ao destino iSCSI:

/iscsi/iqn.20...a3a/tpg1/acls> cd ../luns
/iscsi/iqn.20...a3a/tpg1/luns> create /backstores/user:rbd/tcmu-lu
Created LUN 0.
Created LUN 0->0 mapping in node ACL iqn.1998-01.com.vmware:esxi-872c4888

Saia do shell para gravar a configuração existente:

/iscsi/iqn.20...a3a/tpg1/luns> exit
Global pref auto_save_on_exit=true
Last 10 configs saved in /etc/target/backup.
Configuration saved to /etc/target/saveconfig.json

10.5.3 Uso

Em seu nó do iniciador iSCSI (cliente), conecte-se ao destino iSCSI recém-provisionado usando o IQN e o nome de host configurados anteriormente.

Imprimir esta página