[ClusterLabs] iSCSITarget problems with just add an iqn

Strahil Nikolov hunter86_bg at yahoo.com
Thu Apr 9 01:20:31 EDT 2020


On April 8, 2020 10:24:30 PM GMT+03:00, Stefan K <shadow_7 at gmx.net> wrote:
>> Yeah,  because there  is no such logic in the scripts.
>can this somehow be implemented?
>
>> Also when using multipath - your clients  should not realize that a
>restart has occured.
>thats true, but lsat time it doesn't work, and I've absolutly no glue
>why it fails last time.

How did it fail ?
Have you checked your client's iscsid  conf ?
When using multipath , the no-op timeout should be reduced from 120s  to (15-20)s.
What did the tests show prior  implementation on prod ?


Best Regards,
Strahil Nikolov
>I can't play with this parameter, because its a production machine
>
>
>On Monday, April 6, 2020 1:16:42 PM CEST Strahil Nikolov wrote:
>> On April 6, 2020 11:53:22 AM GMT+03:00, Stefan K <shadow_7 at gmx.net>
>wrote:
>> >> Note: When changing parameters  the cluster will restart the
>> >resources, so keep that in mind.
>> >and thats the problem, targetcli supports changees on the fly.. and
>> >pacemaker restart all resources instead of only who was changed
>> >
>> >
>> >
>> >On Saturday, April 4, 2020 7:51:49 AM CEST Strahil Nikolov wrote:
>> >> On April 3, 2020 1:09:15 PM GMT+03:00, Stefan K <shadow_7 at gmx.net>
>> >wrote:
>> >> >Sorry I mean I changed/add a iqn to the allowed_initiators
>> >> >
>> >> >
>> >> >
>> >> >On Friday, April 3, 2020 10:52:06 AM CEST Stefan K wrote:
>> >> >> Hello,
>> >> >>
>> >> >> ok first the versions:
>> >> >> corosync: 2.4.2
>> >> >> pacemaker: 1.1.16
>> >> >> OS: Debian 9.4
>> >> >>
>> >> >> How I add an IQN:
>> >> >> crm conf edit iscsi-server
>> >> >> and then I add the iqn
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Thursday, April 2, 2020 7:29:46 PM CEST Strahil Nikolov
>wrote:
>> >> >> > On April 2, 2020 3:39:07 PM GMT+03:00, Stefan K
>> ><shadow_7 at gmx.net>
>> >> >wrote:
>> >> >> > >Hello,
>> >> >> > >
>> >> >> > >yesterday I wanted to ust add an iqn in my setup, it works
>> >2times
>> >> >> > >before, but yesterday it fails and I don't know why (I
>attached
>> >> >the log
>> >> >> > >and config)..
>> >> >> > >
>> >> >> > >I use targetcli to configure iSCSI, with targetcli its
>possible
>> >to
>> >> >add
>> >> >> > >an IQN on the fly.. pacemaker/ the iSCSITarget ressource
>> >don'tuse
>> >> >that,
>> >> >> > >is it possible to change the script? Is it possible in
>> >pacemaker
>> >> >that I
>> >> >> > >just get the changes and forward it to the iSCSIITarget?
>> >> >> > >
>> >> >> > >And last question, why stop/start pacemaker all ressouces
>and
>> >not
>> >> >just
>> >> >> > >the ressource which was changed?
>> >> >> > >
>> >> >> > >thanks in advanced
>> >> >> > >
>> >> >> > >.....................
>> >> >> > >config:
>> >> >> > >crm conf sh
>> >> >> > >node 1: zfs-serv3 \
>> >> >> > >        attributes
>> >> >> > >node 2: zfs-serv4 \
>> >> >> > >        attributes
>> >> >> > >primitive ha-ip IPaddr2 \
>> >> >> > >        params ip=192.168.2.10 cidr_netmask=24 nic=bond0 \
>> >> >> > >        op start interval=0s timeout=20s \
>> >> >> > >        op stop interval=0s timeout=20s \
>> >> >> > >        op monitor interval=10s timeout=20s \
>> >> >> > >        meta target-role=Started
>> >> >> > >primitive iscsi-lun00 iSCSILogicalUnit \
>> >> >> > >params implementation=lio-t
>> >> >> >
>> >>
>>
>>>>target_iqn="iqn.2003-01.org.linux-iscsi.vm-storage.x8664:sn.cf6fa665ec23"
>> >> >> > >lun=0 lio_iblock=0 scsi_sn=8a12f029
>> >> >> > >path="/dev/zvol/vm_storage/zfs-vol1" \
>> >> >> > >        meta
>> >> >> > >primitive iscsi-lun01 iSCSILogicalUnit \
>> >> >> > >params implementation=lio-t
>> >> >> >
>> >>
>>
>>>>target_iqn="iqn.2003-01.org.linux-iscsi.vm-storage.x8664:sn.cf6fa665ec23"
>> >> >> > >lun=1 lio_iblock=1 scsi_sn=f0e7a755
>> >> >> > >path="/dev/zvol/vm_storage/zfs-vol2" \
>> >> >> > >        meta
>> >> >> > >primitive iscsi-lun02 iSCSILogicalUnit \
>> >> >> > >params implementation=lio-t
>> >> >> >
>> >>
>>
>>>>target_iqn="iqn.2003-01.org.linux-iscsi.vm-storage.x8664:sn.cf6fa665ec23"
>> >> >> > >lun=2 lio_iblock=2 scsi_sn=6b45cc5f
>> >> >> > >path="/dev/zvol/vm_storage/zfs-vol3" \
>> >> >> > >        meta
>> >> >> > >primitive iscsi-server iSCSITarget \
>> >> >> > >params implementation=lio-t
>> >> >> >
>> >>iqn="iqn.2003-01.org.linux-iscsi.vm-storage.x8664:sn.cf6fa665ec23"
>> >> >> > >portals="192.168.2.10:3260"
>> >> >> >
>>allowed_initiators="iqn.1998-01.com.vmware:brainslug9-75488e35
>> >> >> > >iqn.1998-01.com.vmware:brainslug8-05897f0c
>> >> >> > >iqn.1998-01.com.vmware:brainslug7-592b0e73
>> >> >> > >iqn.1998-01.com.vmware:brainslug10-5564c329
>> >> >> > >iqn.1998-01.com.vmware:brainslug11-0214ef48
>> >> >> > >iqn.1998-01.com.vmware:brainslug12-5d9f42e9"
>> >> >> > >primitive resIPMI-zfs3 stonith:external/ipmi \
>> >> >> > >params hostname=zfs-serv3 ipaddr=172.16.105.16
>userid=stonith
>> >> >> > >passwd=stonith_321 interface=lan priv=OPERATOR
>> >pcmk_delay_max=20 \
>> >> >> > >        op monitor interval=60s \
>> >> >> > >        meta
>> >> >> > >primitive resIPMI-zfs4 stonith:external/ipmi \
>> >> >> > >params hostname=zfs-serv4 ipaddr=172.16.105.17
>userid=stonith
>> >> >> > >passwd=stonith_321 interface=lan priv=OPERATOR
>> >pcmk_delay_max=20 \
>> >> >> > >        op monitor interval=60s \
>> >> >> > >        meta
>> >> >> > >primitive vm_storage ZFS \
>> >> >> > >        params pool=vm_storage importargs="-d
>> >/dev/disk/by-vdev/"
>> >> >\
>> >> >> > >        op monitor interval=5s timeout=30s \
>> >> >> > >        op start interval=0s timeout=90 \
>> >> >> > >        op stop interval=0s timeout=90 \
>> >> >> > >        meta target-role=Started
>> >> >> > >location location-resIPMI-zfs3-zfs-serv3--INFINITY
>resIPMI-zfs3
>> >> >-inf:
>> >> >> > >zfs-serv3
>> >> >> > >location location-resIPMI-zfs4-zfs-serv4--INFINITY
>resIPMI-zfs4
>> >> >-inf:
>> >> >> > >zfs-serv4
>> >> >> > >colocation
>pcs_rsc_colocation_set_ha-ip_vm_storage_iscsi-server
>> >> >inf:
>> >> >> > >ha-ip vm_storage iscsi-server iscsi-lun00 iscsi-lun01
>> >iscsi-lun02
>> >> >> > >order pcs_rsc_order_set_iscsi-server_vm_storage_ha-ip
>> >iscsi-server
>> >> >> > >iscsi-lun00 iscsi-lun01 iscsi-lun02 ha-ip
>> >> >> > >property cib-bootstrap-options: \
>> >> >> > >        have-watchdog=false \
>> >> >> > >        dc-version=1.1.16-94ff4df \
>> >> >> > >        cluster-infrastructure=corosync \
>> >> >> > >        cluster-name=zfs-vmstorage \
>> >> >> > >        no-quorum-policy=stop \
>> >> >> > >        stonith-enabled=true \
>> >> >> > >        last-lrm-refresh=1585662940
>> >> >> > >rsc_defaults rsc_defaults-options: \
>> >> >> > >        resource-stickiness=100
>> >> >> >
>> >> >> > Yes, you can add a new initiator live.
>> >> >> >
>> >> >> > How did you add it (what command and it's  options)  ?
>> >> >> >
>> >> >> > What is your OS (Distro,version)  and corosync/pacemaker
>> >versions ?
>> >> >> >
>> >> >> >
>> >> >> > Best Regards,
>> >> >> > Strahil Nikolov
>> >> >>
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> Manage your subscription:
>> >> >> https://lists.clusterlabs.org/mailman/listinfo/users
>> >> >>
>> >> >> ClusterLabs home: https://www.clusterlabs.org/
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> >_______________________________________________
>> >> >Manage your subscription:
>> >> >https://lists.clusterlabs.org/mailman/listinfo/users
>> >> >
>> >> >ClusterLabs home: https://www.clusterlabs.org/
>> >>
>> >> What happens when you run:
>> >> crm resource param  iscsi-server set
>> >allowed_initiators="old_initiators new initiator"
>> >> crm resource param iscsi-lun00 set
>allowed_initiators="old_initiators
>> >new initiator"
>> >> crm resource param iscsi-lun01 set
>allowed_initiators="old_initiators
>> >new initiator"
>> >>
>> >> If you add initiator to the iscsi-server resource only - the
>> >initiator will successfully login but won't have  a lun .
>> >> Adding it to a specific lun - then that initiator will see the lun
>on
>> >the next session.
>> >>
>> >> Note: When changing parameters  the cluster will restart the
>> >resources, so keep that in mind.
>> >>
>> >> Best Regards,
>> >> Strahil Nikolov
>>
>> Yeah,  because there  is no such logic in the scripts.
>>
>> Also when using multipath - your clients  should not realize that a
>restart has occured.
>>
>> I haven't tried  playing with sysfs , but you can change 'op monitor
>on-fail=ignore' for  server and luns and then play  with sysfs.
>> If monitor action fails - nothing will happen, so no disruption  for
>the  clients.
>>
>> Don't forget to update 'on-fail=restart' or whatever you want.
>>
>> Best Regards,
>> Strahil Nikolov



More information about the Users mailing list