Skip to content
This repository has been archived by the owner on Jan 16, 2025. It is now read-only.

Question: why the requirement num_servers == num_addrs? #31

Open
epol opened this issue Sep 12, 2018 · 2 comments
Open

Question: why the requirement num_servers == num_addrs? #31

epol opened this issue Sep 12, 2018 · 2 comments

Comments

@epol
Copy link
Contributor

epol commented Sep 12, 2018

When running storhaug setup it's checked that the number of server in the pool is equal to the number of public addresses available.

Why this limitation? What would be the problems of having less (for example just 1) or more IPs than server?

I can think of this use cases:

  • just 1 public IP: just the one used by clients to connect to the cluster without any form of round robin
  • in a 3 nodes cluster 6 IPs: in this way ctdb assures that the IPs are equally split in case of failure (3 nodes -> 2 IPs each, 2 nodes -> 3 IPs each, 1 node -> 6 IPs on it)
  • scaling the number of nodes without changing the number of public IPs
@tkriviradev
Copy link

You can still do that, no problem.

I have configuration with 2 CTDB floating IP's gluster replica set 3 and 1 arbiter
Which is total of only two usable IP addresses.

Also with NFS 4.1 you can have pNFS accessing your data from more then one path.
and if you have only one IP you are limiting yourself to what you can with NFS 3.
If you want such solutions you have to go for peacemaker.

@epol
Copy link
Contributor Author

epol commented Sep 13, 2018

It doesn't look like a limitation of CTDB (see their wiki page about public IP addresses, so I don't see how peacemaker would solve the problem (if there is any).

I'm not sure if pNFS can't work with just one public IP (couldn't it use the other "private" IPs of the nodes?), in any case I think that the case "just one IP" may be interesting for situations where pNFS is not available (NFS 3 or NFS 4.x without pNFS, for example when using ESX) and one wants to use storhaug just to ensure high availability (I think issue #29 may be correlated).

In short, I'm just trying to understand if there is any deep reason for having that condition or if it just a common case and, maybe, other particular cases may be supported in future (and more mature) releases.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants