Estamos executando um servidor CentOS 7 com sucesso há alguns meses com dois destinos iSCSI, todos configurados usando targetcli . Estes são montados a partir de uma caixa do Windows 7 usando o MS iSCSI Initiator. Funcionou muito bem. Cerca de um mês atrás, adicionei outro alvo para ser montado em uma segunda máquina. Parece que eu esqueci que preciso executar saveconfig . Na semana passada, começamos a avaliar o TigerStore, um servidor de metadados. Isso é instalado em uma terceira máquina com o Windows 7. Eu configurei um quarto alvo na caixa CentOS para fins de teste com o TigerStore (que também usa o iniciador do Windows para montar o alvo que ele serve). Mais uma vez, esqueci que preciso de saveconfig .
Temos usado todos os quatro alvos sem problemas. Eu estava usando na sexta à noite, na verdade. No entanto, quando cheguei nesta manhã, os alvos na primeira máquina, que foram montados há meses, estavam aparecendo com apenas uma letra de unidade e, quando clicados, me deram um erro de permissão. Eu chequei a máquina Windows 2, a mesma coisa com o seu alvo iSCSI montado. O servidor TigerStore ainda estava conectado ao seu destino e funcionando bem.
Reiniciou todas as três máquinas Windows, o mesmo problema com as permissões. Agora é onde eu realmente estraguei tudo: reiniciei o servidor CentOS, e duas das configurações de destino estão aparecendo sem LUNs (estes são os dois para os quais eu não rodei o saveconfig). Porque ... A localização dos dispositivos mudou. Um par foi /dev/sdb1 e /dev/sdb2 , e o outro foi /dev/sdc1 e /dev/sdc2 , antes da reinicialização. Agora, esses são diferentes, com /dev/sdc sendo minha unidade de sistema, o que anteriormente era /dev/sdb agora é /dev/sda e /dev/sdc agora é /dev/sdb . Assim, todos os mapeamentos são uma bagunça.
Então, eu acho que tenho uma pergunta de duas partes aqui:
1) Posso criar novas LUNs em targetcli para apontar para os novos locais de dispositivo de bloco, para que os mapeamentos funcionem corretamente - SEM - alterar os dados do usuário nas metas?
2) Posso forçar o sistema a usar as mesmas atribuições de localização /dev/sd* na inicialização toda vez?
Ok, três perguntas:
3) Se eu não posso fazer # 2, o que eu deveria estar fazendo de forma diferente para garantir que isso não aconteça novamente. Para referência, aqui está a saída de um targetcli ls :
o- / ..................................................................... [...]
o- backstores .......................................................... [...]
| o- block .............................................. [Storage Objects: 2]
| | o- block1 ..................... [/dev/sdb1 (0 bytes) write-thru activated]
| | | o- alua ............................................... [ALUA Groups: 1]
| | | o- default_tg_pt_gp ................... [ALUA state: Active/optimized]
| | o- block3 ..................... [/dev/sdb2 (0 bytes) write-thru activated]
| | o- alua ............................................... [ALUA Groups: 1]
| | o- default_tg_pt_gp ................... [ALUA state: Active/optimized]
| o- fileio ............................................. [Storage Objects: 0]
| o- pscsi .............................................. [Storage Objects: 0]
| o- ramdisk ............................................ [Storage Objects: 0]
o- iscsi ........................................................ [Targets: 4]
| o- iqn.2018-03.com.grd.t3 ............................ [TPGs: 1]
| | o- tpg1 .............................................. [gen-acls, no-auth]
| | o- acls ...................................................... [ACLs: 0]
| | o- luns ...................................................... [LUNs: 1]
| | | o- lun0 ................ [block/block3 (/dev/sdb2) (default_tg_pt_gp)]
| | o- portals ................................................ [Portals: 1]
| | o- 10.0.0.1:3260 ................................................ [OK]
| o- iqn.2018-03.com.grd:t1 ............................ [TPGs: 1]
| | o- tpg1 .............................................. [gen-acls, no-auth]
| | o- acls ...................................................... [ACLs: 0]
| | o- luns ...................................................... [LUNs: 1]
| | | o- lun0 ................ [block/block1 (/dev/sdb1) (default_tg_pt_gp)]
| | o- portals ................................................ [Portals: 1]
| | o- 10.0.0.1:3260 ................................................ [OK]
| o- iqn.2018-03.com.grd:t2 ............................ [TPGs: 1]
| | o- tpg1 .............................................. [gen-acls, no-auth]
| | o- acls ...................................................... [ACLs: 0]
| | o- luns ...................................................... [LUNs: 0]
| | o- portals ................................................ [Portals: 1]
| | o- 10.0.0.1:3260 ................................................ [OK]
| o- iqn.2018-04.com.grd:t3 ............................ [TPGs: 1]
| o- tpg1 .............................................. [gen-acls, no-auth]
| o- acls ...................................................... [ACLs: 0]
| o- luns ...................................................... [LUNs: 0]
| o- portals ................................................ [Portals: 1]
| o- 10.0.0.1:3260 ................................................ [OK]
o- loopback ..................................................... [Targets: 0]
o- srpt ......................................................... [Targets: 0]
Obrigado!
A solução para isso foi excluir os blocos e as colunas de back-ups (deixando os destinos no lugar). Eu então reconstruí os blocos em targetcli para apontar para os locais / dev / sd * corretos.
A partir de agora, estamos migrando tudo isso usando / dev / disk / by-partuuid para mapear os backstores para bloquear dispositivos, o que deve resolver o problema de persistência.
Tags iscsi block-device targetcli