Getting an error when trying to add iscsi service to a node, also an explanation on fencing?
helios
11 Posts
February 27, 2021, 9:52 pmQuote from helios on February 27, 2021, 9:52 pmThis is the error I receive
"SCSI Error : iSCSI requires interface eth3,eth4, please add missing interface or rename existing node interfaces using the node console menu."
I'm just wondering where in the console I would find this I tried changing the
/opt/petasan/config/services_interfaces.json - making sure eth3 and eth4 were in the file
/opt/petasan/config/cluster_info.json - setting is_iscsi to true
/opt/petasan/config/node_info.json - making sure it said true
I'm just wondering if someone could point me in the right path to do this i've tried rebooting the node afterwards(this is a vm cluster to get familiar with petasan)
I'm also Looking for a more detailed explanation on fencing , and some of the most common reasons why you would turn it off?
Thanks!
This is the error I receive
"SCSI Error : iSCSI requires interface eth3,eth4, please add missing interface or rename existing node interfaces using the node console menu."
I'm just wondering where in the console I would find this I tried changing the
/opt/petasan/config/services_interfaces.json - making sure eth3 and eth4 were in the file
/opt/petasan/config/cluster_info.json - setting is_iscsi to true
/opt/petasan/config/node_info.json - making sure it said true
I'm just wondering if someone could point me in the right path to do this i've tried rebooting the node afterwards(this is a vm cluster to get familiar with petasan)
I'm also Looking for a more detailed explanation on fencing , and some of the most common reasons why you would turn it off?
Thanks!
admin
2,930 Posts
February 28, 2021, 2:16 pmQuote from admin on February 28, 2021, 2:16 pmOnly the management and backend interface settings are stored in config files. The interface settings for iSCSI and other services are stored in Consul and can be modified at runtime from the ui in the setting pages.
the error you get means you specified eth3 and eth4 in the iSCSI service settings but the node you are trying to add iSCSI role does not have such interfaces. You can either change the iSCSI settings (but this could effect other node if present, or add such interfaces to the node. The node console menu is the blue menu you get from the console display of the node, there is menu to rename interface names on the local node, this may help in some cases to rename/re-order the local interface names of the node to match the interface names stored in the settings, this is useful when you have different hardware which may cause the interface names to be different across the nodes.
Fencing is a feature in clustering failover used to "kill"/shutdown another node before acquiring its resources, such as ips and disk access, this is to make sure the original node no longer has access to such resources. It should be left on, but during maintenance it is possible for example to restart services on a node for maintenance and not have the possibility of node being killed.
Only the management and backend interface settings are stored in config files. The interface settings for iSCSI and other services are stored in Consul and can be modified at runtime from the ui in the setting pages.
the error you get means you specified eth3 and eth4 in the iSCSI service settings but the node you are trying to add iSCSI role does not have such interfaces. You can either change the iSCSI settings (but this could effect other node if present, or add such interfaces to the node. The node console menu is the blue menu you get from the console display of the node, there is menu to rename interface names on the local node, this may help in some cases to rename/re-order the local interface names of the node to match the interface names stored in the settings, this is useful when you have different hardware which may cause the interface names to be different across the nodes.
Fencing is a feature in clustering failover used to "kill"/shutdown another node before acquiring its resources, such as ips and disk access, this is to make sure the original node no longer has access to such resources. It should be left on, but during maintenance it is possible for example to restart services on a node for maintenance and not have the possibility of node being killed.
helios
11 Posts
February 28, 2021, 3:47 pmQuote from helios on February 28, 2021, 3:47 pmThanks so much for the reply that helps, i'll give that a try now. I had one other question i'm looking to create custom rules down the line ec & rep in the GUI where you would paste your rule could you provide me with the proper syntax for each for doing it through there? I beleive the proper syntax in the command line (just using rep as an example)
ceph osd crush rule create-replicated {name} {root} {failure-domain-type} [{class}]
Please correct me if i'm wrong there, and if I posted say "ceph osd crush rule create-replicated test default host" in the rule box
would it apply properly? and if so what's the proper syntax for ec rules?
Thanks!
Thanks so much for the reply that helps, i'll give that a try now. I had one other question i'm looking to create custom rules down the line ec & rep in the GUI where you would paste your rule could you provide me with the proper syntax for each for doing it through there? I beleive the proper syntax in the command line (just using rep as an example)
ceph osd crush rule create-replicated {name} {root} {failure-domain-type} [{class}]
Please correct me if i'm wrong there, and if I posted say "ceph osd crush rule create-replicated test default host" in the rule box
would it apply properly? and if so what's the proper syntax for ec rules?
Thanks!
admin
2,930 Posts
February 28, 2021, 4:11 pmQuote from admin on February 28, 2021, 4:11 pmwe have ready made rule templates for you to create new rules in the add rule ui page, they cover most common cases. you can customize them if needed.
we have ready made rule templates for you to create new rules in the add rule ui page, they cover most common cases. you can customize them if needed.
Last edited on February 28, 2021, 4:12 pm by admin · #4
Getting an error when trying to add iscsi service to a node, also an explanation on fencing?
helios
11 Posts
Quote from helios on February 27, 2021, 9:52 pmThis is the error I receive
"SCSI Error : iSCSI requires interface eth3,eth4, please add missing interface or rename existing node interfaces using the node console menu."
I'm just wondering where in the console I would find this I tried changing the
/opt/petasan/config/services_interfaces.json - making sure eth3 and eth4 were in the file
/opt/petasan/config/cluster_info.json - setting is_iscsi to true
/opt/petasan/config/node_info.json - making sure it said true
I'm just wondering if someone could point me in the right path to do this i've tried rebooting the node afterwards(this is a vm cluster to get familiar with petasan)
I'm also Looking for a more detailed explanation on fencing , and some of the most common reasons why you would turn it off?
Thanks!
This is the error I receive
"SCSI Error : iSCSI requires interface eth3,eth4, please add missing interface or rename existing node interfaces using the node console menu."
I'm just wondering where in the console I would find this I tried changing the
/opt/petasan/config/services_interfaces.json - making sure eth3 and eth4 were in the file
/opt/petasan/config/cluster_info.json - setting is_iscsi to true
/opt/petasan/config/node_info.json - making sure it said true
I'm just wondering if someone could point me in the right path to do this i've tried rebooting the node afterwards(this is a vm cluster to get familiar with petasan)
I'm also Looking for a more detailed explanation on fencing , and some of the most common reasons why you would turn it off?
Thanks!
admin
2,930 Posts
Quote from admin on February 28, 2021, 2:16 pmOnly the management and backend interface settings are stored in config files. The interface settings for iSCSI and other services are stored in Consul and can be modified at runtime from the ui in the setting pages.
the error you get means you specified eth3 and eth4 in the iSCSI service settings but the node you are trying to add iSCSI role does not have such interfaces. You can either change the iSCSI settings (but this could effect other node if present, or add such interfaces to the node. The node console menu is the blue menu you get from the console display of the node, there is menu to rename interface names on the local node, this may help in some cases to rename/re-order the local interface names of the node to match the interface names stored in the settings, this is useful when you have different hardware which may cause the interface names to be different across the nodes.
Fencing is a feature in clustering failover used to "kill"/shutdown another node before acquiring its resources, such as ips and disk access, this is to make sure the original node no longer has access to such resources. It should be left on, but during maintenance it is possible for example to restart services on a node for maintenance and not have the possibility of node being killed.
Only the management and backend interface settings are stored in config files. The interface settings for iSCSI and other services are stored in Consul and can be modified at runtime from the ui in the setting pages.
the error you get means you specified eth3 and eth4 in the iSCSI service settings but the node you are trying to add iSCSI role does not have such interfaces. You can either change the iSCSI settings (but this could effect other node if present, or add such interfaces to the node. The node console menu is the blue menu you get from the console display of the node, there is menu to rename interface names on the local node, this may help in some cases to rename/re-order the local interface names of the node to match the interface names stored in the settings, this is useful when you have different hardware which may cause the interface names to be different across the nodes.
Fencing is a feature in clustering failover used to "kill"/shutdown another node before acquiring its resources, such as ips and disk access, this is to make sure the original node no longer has access to such resources. It should be left on, but during maintenance it is possible for example to restart services on a node for maintenance and not have the possibility of node being killed.
helios
11 Posts
Quote from helios on February 28, 2021, 3:47 pmThanks so much for the reply that helps, i'll give that a try now. I had one other question i'm looking to create custom rules down the line ec & rep in the GUI where you would paste your rule could you provide me with the proper syntax for each for doing it through there? I beleive the proper syntax in the command line (just using rep as an example)
ceph osd crush rule create-replicated {name} {root} {failure-domain-type} [{class}] Please correct me if i'm wrong there, and if I posted say "ceph osd crush rule create-replicated test default host" in the rule box would it apply properly? and if so what's the proper syntax for ec rules? Thanks!
Thanks so much for the reply that helps, i'll give that a try now. I had one other question i'm looking to create custom rules down the line ec & rep in the GUI where you would paste your rule could you provide me with the proper syntax for each for doing it through there? I beleive the proper syntax in the command line (just using rep as an example)
ceph osd crush rule create-replicated {name} {root} {failure-domain-type} [{class}] Please correct me if i'm wrong there, and if I posted say "ceph osd crush rule create-replicated test default host" in the rule box would it apply properly? and if so what's the proper syntax for ec rules? Thanks!
admin
2,930 Posts
Quote from admin on February 28, 2021, 4:11 pmwe have ready made rule templates for you to create new rules in the add rule ui page, they cover most common cases. you can customize them if needed.
we have ready made rule templates for you to create new rules in the add rule ui page, they cover most common cases. you can customize them if needed.