Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 3 subscribers
  • Views 4954 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Link-aggregation on HA interface

gartoffel
Hi guys

While reading through the board, I discovered several posts stating that a LAG interface can be used as HA heartbeat and sync. Because I kind of like redundancy I went straight into merging my dedicated HA port (eth4) with the unused eth5, forming lag2 as a default 802.3ad LAG.


Both units are active and synced:



Port eth4 is the current sync interface for my failover setup:



Now I converted the HA interface in lag group #3 and a warning appears:



After clicking OK nothing happens yet, so I add eth5 to the LAG:



Now both units reboot automatically and after that I can't access neither one of them anymore. On both displays the following message appears:  
HA DEACTIVATED

Node 0 ERROR



As there are some of you who apparently managed to use a LAG interface as HA sync, I'd really like to know what I'm doing wrong.

Cheers,
Manuel


This thread was automatically locked due to age.
Parents
  • 0
    First, a recommendation.  The 'Backup interface' should be selected; I've only used the Internal interface.  This is not a backup for the sync traffic; it's a backup for the heartbeat if the sync interface goes down.  Normally, the heartbeat also goes via the sync interface.

    Well, you obviously have a lot of knowledge that I don't, but I have spent some time tilting at windmills with Astaro HA. [;)] I haven't tried to do this, but it seems like it should be possible.  My guess is that you would have needed to deactivate HA first.  That would have caused the Slave to do a 'Factory Reset'.  In that situation, I think you could create a LAG on the Master and then activate HA with with the LAG.

    Did that do the trick?

    Cheers - Bob
  • 0 in reply to BAlfson
    Hi Bob

    Thanks for your input and sorry for letting you wait that long.

    My guess is that you would have needed to deactivate HA first.  That would have caused the Slave to do a 'Factory Reset'.  In that situation, I think you could create a LAG on the Master and then activate HA with with the LAG.

    Did that do the trick?

    Good thinking and thanks for the tip!
    I fear, that the Slave would not have automatically detected and switched to the LAG and therefore, manual intervention would have been necessary. One of the reasons why I'm obstaining this solution for now.

    The 'Backup interface' should be selected; I've only used the Internal interface.  This is not a backup for the sync traffic; it's a backup for the heartbeat if the sync interface goes down.  Normally, the heartbeat also goes via the sync interface.

    Well, looking at our setup I guess that you are right. As we don't have a clustered HA setup, traffic on the main HA interface will be negligible (only sync and heartbeat, no load-balancing of CPU time). And as you stated correctly, there is still the option with the backup interface to prevent a split-brain. That's the second reason to avoid the LAG.

    Third, I kind of like the idea of replacing a defective ASG by booting up a factory reset unit, connecting eth3 and let the magic happen.

    So thanks for your advice. It's always good to hear someone speaking from experience.

    Cheers and have a good one,
    Manuel
Reply
  • 0 in reply to BAlfson
    Hi Bob

    Thanks for your input and sorry for letting you wait that long.

    My guess is that you would have needed to deactivate HA first.  That would have caused the Slave to do a 'Factory Reset'.  In that situation, I think you could create a LAG on the Master and then activate HA with with the LAG.

    Did that do the trick?

    Good thinking and thanks for the tip!
    I fear, that the Slave would not have automatically detected and switched to the LAG and therefore, manual intervention would have been necessary. One of the reasons why I'm obstaining this solution for now.

    The 'Backup interface' should be selected; I've only used the Internal interface.  This is not a backup for the sync traffic; it's a backup for the heartbeat if the sync interface goes down.  Normally, the heartbeat also goes via the sync interface.

    Well, looking at our setup I guess that you are right. As we don't have a clustered HA setup, traffic on the main HA interface will be negligible (only sync and heartbeat, no load-balancing of CPU time). And as you stated correctly, there is still the option with the backup interface to prevent a split-brain. That's the second reason to avoid the LAG.

    Third, I kind of like the idea of replacing a defective ASG by booting up a factory reset unit, connecting eth3 and let the magic happen.

    So thanks for your advice. It's always good to hear someone speaking from experience.

    Cheers and have a good one,
    Manuel
Children
No Data