4

If there are one server and one switch, if the switch dies, service on the server down.

So there are normally two switches, and the server should be connected to the two switches, therefore there should be two NICs on the server.

But even if the server has two NICs connected to two switches, because the IP differs, if the NIC with the IP on which service is listening fails, the service will down too.

So here comes bonding. with bonding, two NIC shares one IP, and two NIC will connect to two switches, so if one switch dies, another switch will serve and if one NIC dies another NIC will still work.

Am I understand right?

Sato
  • 449
  • 2
  • 9
  • 17
  • Yes, but two switches should be stacked in one logical switch, to organize right bonding. – Alexander Tolkachev Mar 22 '17 at 08:22
  • @Sato Bonding or LAG (link aggregation group) has many modes and standards​. I see that you don't understand bonding and that you don't know what you want. Before all read about bonding at Wikipedia https://en.m.wikipedia.org/wiki/Link_aggregation – Mikhail Khirgiy Mar 23 '17 at 18:35
  • @AlexanderT Stacked (by software) switches often will not work all when one of them will be powered off. It isn't good idea to organize LAG with different physical switches which aggregated to one software stacked switch. – Mikhail Khirgiy Mar 23 '17 at 18:45
  • 3
    Totally agree with Mikhail. BTW, her is the comparison on how such similar technologies works in different methods. https://www.starwindsoftware.com/blog/lacp-vs-mpio-on-windows-platform-which-one-is-better-in-terms-of-redundancy-and-speed-in-this-case-2 – Stuka Mar 24 '17 at 16:57

2 Answers2

1

Kind of. Bonding actually gives you a virtual interface with one IP, so "the IP differs" situation you are referring to is a nonsense. Bonding can work either in a failover mode or in LACP mode. In LACP mode flows are usually balanced over all available physical interfaces, with some specific limitations (for example some vendors may balance only the flows destined to different MACs), while in failover mode one interface is a backup one, and it's just standing by. LACP mode basically can work inside one switch, so if you want to use LACP mode with two switches, providing real high availability, chosen switches should support it - it's called cross-switch LACP (some vendors like Cisco do, but it's not a basic set of functionality).

Tero Kilkanen
  • 36,796
  • 3
  • 41
  • 63
drookie
  • 8,625
  • 1
  • 19
  • 29
-1

You mix things up.

First, there is nothing against a service on multiple IP and the user being smart enough to use one that works.

Second, bonding is not based on IP - bonding works on the ethernet level. A bonded connection shares one mac address. It basically IS one connection. As such, they do not really share one IP - they are one ethernet channel. THis is "more fundamental" - bonding works on the underlying technology.

Third, bonding does not work cross switch. Or: if it works like that, then basically it requires the switch to know how to handle this (stacked switches may have this capability). Which means you can say goodbye to most lower cost switches for bonding and uptime. Not sure about some higher end, but I am not knowledgeable of any one that can handle bonding distributed over multiple chasses. Not THE specialist, though - but I also generally move to 10G before using bonding. Cisco, I hear, has this capability (Cross Switch LACP).

Generally bonding is used to create more bandwidth TRANSPARENTLY for applications not written with this in mind. Protocols that are built for high throughput and uptime may not need bonding - for example ISCSI handle this with MPIO (MultiPath IO) where it actually connects to a server via multiple IP addresses, distributing load and handling uptime this way. Microsoft does the same now with file shares in the later servers, allowing multiple IP addresses to be used to handle multiple parallel streams of data for more bandwidth (SMB 3 MultiChannel). No need for bonding here, all handled on protocol and library level.

Tero Kilkanen
  • 36,796
  • 3
  • 41
  • 63
TomTom
  • 51,649
  • 7
  • 54
  • 136