Fun with iSCSI - Using iSNS
sniffus
20 Posts
February 2, 2018, 4:51 pmQuote from sniffus on February 2, 2018, 4:51 pmGood <time_o'_day>
Who would like to save some typing? I DO, I DO !!
iSNS discovery will let all the iSCSI services to talk to each other thru this beautifully simple little directory.
We just need to know where to set it up in PetaSAN, normally in iscsid.conf you add these two lines.
isns.address = <iSNS server IP address>
isns.port = <iSNS server port>
What is the equivalent in PetaSAN's .py scripts?
You could even add the service to PetaSAN also.
http://linux-iscsi.org/wiki/Internet_Storage_Name_Service
M.
Good <time_o'_day>
Who would like to save some typing? I DO, I DO !!
iSNS discovery will let all the iSCSI services to talk to each other thru this beautifully simple little directory.
We just need to know where to set it up in PetaSAN, normally in iscsid.conf you add these two lines.
isns.address = <iSNS server IP address>
isns.port = <iSNS server port>
What is the equivalent in PetaSAN's .py scripts?
You could even add the service to PetaSAN also.
http://linux-iscsi.org/wiki/Internet_Storage_Name_Service
M.
admin
2,930 Posts
February 2, 2018, 8:39 pmQuote from admin on February 2, 2018, 8:39 pmThis could be possible. Note that in PetaSAN, no node owns any targets itself and paths for the same target can move from node to node due to node failure. Our current design is to store configuration in either Ceph or in Consul https://www.consul.io/ which is a modern cloud scale service discovery and configuration platform.
For critical data such as iSCSI info it is saved in Ceph as metada on each rbd image. The reason we chose this is that in case of a worst case scenario where all layers above Ceph are down, a user can start iSCSI disks using simple scripts.
If you want to use iSNS, maybe you could write a script to list all Ceph rbd images, read their metada and get all the iSCSI info such as target name, ips and feed them to iSNS server ?
This could be possible. Note that in PetaSAN, no node owns any targets itself and paths for the same target can move from node to node due to node failure. Our current design is to store configuration in either Ceph or in Consul https://www.consul.io/ which is a modern cloud scale service discovery and configuration platform.
For critical data such as iSCSI info it is saved in Ceph as metada on each rbd image. The reason we chose this is that in case of a worst case scenario where all layers above Ceph are down, a user can start iSCSI disks using simple scripts.
If you want to use iSNS, maybe you could write a script to list all Ceph rbd images, read their metada and get all the iSCSI info such as target name, ips and feed them to iSNS server ?
Last edited on February 2, 2018, 8:45 pm by admin · #2
sniffus
20 Posts
February 5, 2018, 2:54 pmQuote from sniffus on February 5, 2018, 2:54 pmGood morning,
iSNS would register the targets which each have their IP that follow them onto each host as PetaSAN deems necessary so that shouldn't be an issue. Worst case, as you move services around you can unregister and register again, it's the point of using iSNS.
Just seems to be a great add on to your product, simplifies things for the end user. I would think. (remember I see things in a Windows world, I haven't tried iSNS under linux yet.)
M.
Good morning,
iSNS would register the targets which each have their IP that follow them onto each host as PetaSAN deems necessary so that shouldn't be an issue. Worst case, as you move services around you can unregister and register again, it's the point of using iSNS.
Just seems to be a great add on to your product, simplifies things for the end user. I would think. (remember I see things in a Windows world, I haven't tried iSNS under linux yet.)
M.
Fun with iSCSI - Using iSNS
sniffus
20 Posts
Quote from sniffus on February 2, 2018, 4:51 pmGood <time_o'_day>
Who would like to save some typing? I DO, I DO !!
iSNS discovery will let all the iSCSI services to talk to each other thru this beautifully simple little directory.
We just need to know where to set it up in PetaSAN, normally in iscsid.conf you add these two lines.
isns.address = <iSNS server IP address> isns.port = <iSNS server port>What is the equivalent in PetaSAN's .py scripts? You could even add the service to PetaSAN also. http://linux-iscsi.org/wiki/Internet_Storage_Name_Service M.
Good <time_o'_day>
Who would like to save some typing? I DO, I DO !!
iSNS discovery will let all the iSCSI services to talk to each other thru this beautifully simple little directory.
We just need to know where to set it up in PetaSAN, normally in iscsid.conf you add these two lines.
isns.address = <iSNS server IP address>
isns.port = <iSNS server port>
What is the equivalent in PetaSAN's .py scripts?
You could even add the service to PetaSAN also.
http://linux-iscsi.org/wiki/Internet_Storage_Name_Service
M.
admin
2,930 Posts
Quote from admin on February 2, 2018, 8:39 pmThis could be possible. Note that in PetaSAN, no node owns any targets itself and paths for the same target can move from node to node due to node failure. Our current design is to store configuration in either Ceph or in Consul https://www.consul.io/ which is a modern cloud scale service discovery and configuration platform.
For critical data such as iSCSI info it is saved in Ceph as metada on each rbd image. The reason we chose this is that in case of a worst case scenario where all layers above Ceph are down, a user can start iSCSI disks using simple scripts.
If you want to use iSNS, maybe you could write a script to list all Ceph rbd images, read their metada and get all the iSCSI info such as target name, ips and feed them to iSNS server ?
This could be possible. Note that in PetaSAN, no node owns any targets itself and paths for the same target can move from node to node due to node failure. Our current design is to store configuration in either Ceph or in Consul https://www.consul.io/ which is a modern cloud scale service discovery and configuration platform.
For critical data such as iSCSI info it is saved in Ceph as metada on each rbd image. The reason we chose this is that in case of a worst case scenario where all layers above Ceph are down, a user can start iSCSI disks using simple scripts.
If you want to use iSNS, maybe you could write a script to list all Ceph rbd images, read their metada and get all the iSCSI info such as target name, ips and feed them to iSNS server ?
sniffus
20 Posts
Quote from sniffus on February 5, 2018, 2:54 pmGood morning,
iSNS would register the targets which each have their IP that follow them onto each host as PetaSAN deems necessary so that shouldn't be an issue. Worst case, as you move services around you can unregister and register again, it's the point of using iSNS.
Just seems to be a great add on to your product, simplifies things for the end user. I would think. (remember I see things in a Windows world, I haven't tried iSNS under linux yet.)
M.
Good morning,
iSNS would register the targets which each have their IP that follow them onto each host as PetaSAN deems necessary so that shouldn't be an issue. Worst case, as you move services around you can unregister and register again, it's the point of using iSNS.
Just seems to be a great add on to your product, simplifies things for the end user. I would think. (remember I see things in a Windows world, I haven't tried iSNS under linux yet.)
M.