Questo sito utilizza cookie di profilazione (propri e di terze parti) per ottimizzare la tua esperienza online e per inviarti pubblicità in linea con le tue preferenze. Continuando a utilizzare questo sito senza modificare le tue preferenze acconsenti all’uso dei cookie. Se vuoi saperne di più o negare il consenso a tutti o ad alcuni cookie clicca qui>
The website that you are visiting also provides Arabian language. Do you wish to switch language version?
يوفر موقع الويب الذي تزوره المحتوى باللغة العربية أيضًا. هل ترغب في تبديل إصدار اللغة؟
The website that you are visiting also provides Russia language Do you wish to switch language version?
Данный сайт есть в английской версии. Желаете ли Вы перейти на английскую версию?
Based on the previous analysis, the cause for the failure is the wrong sequences to start and stop the node and private LUN. The following workaround methods can be adopted:
1. startup sequence: Start HA, and then run the varyonvg command to manually activate the volume which the LUN belongs to.
2. Stop sequence: Run the varyonvg command to manually deactivate the volume which the LUN belongs to, and then stop the HA.
If no private LUN is configured, during the cluster startup process, the node that is started first sends a reservation command and then a LOGOUT command to clear the reservation. The other node repeats the commands later.
However, if the first started node does not clear its reservation after the reservation takes effect, the other node fails to be started up.
During the cluster startup process, the LOGOUT command is employed to clear the reservation, and the command stops the whole session. As for a private LUN, it shares the same session with the shared disk in the same primary node, namely, they are two connections of the same session. Therefore, if a private LUN is active, the LOGOUT command cannot stop the whole session of the cluster, and then the reservation fails to be cleared and the second node cannot be started up.
|The start and stop sequences must be correct.|