Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrate alba proxy-osd functionality #268

Open
domsj opened this issue Nov 9, 2016 · 3 comments
Open

Integrate alba proxy-osd functionality #268

domsj opened this issue Nov 9, 2016 · 3 comments

Comments

@domsj
Copy link
Contributor

domsj commented Nov 9, 2016

Currently a 'local' backend can be used as an osd inside a global backend.
This is done by giving registering the abm config of the local backend in the global backend.
Proxies & maintenance of the global backend talk directly with the osds of the local backend - which has both advantages & disadvantages.

As of the next alba release (1.0.1) it will be possible to add a set of proxies (that all expose the same backend) as on osd to a global backend - introduced in openvstorage/alba#440.

alba add-osd --endpoint tcp://host1:port1 --endpoint rdma://host2:port2 --prefix pre --preset preset --config ... --node-id ...

alba update-osd --endpoint ...

host can be a either an ip or a hostname to be dns resolved - which may point to multiple ip adresses (on which you should then have a proxy for this backend running on the same port).

A proxy/maintenance process will keep an affinity mapping for namespaces to resolved endpoints, to be able to effectively leverage caching inside the proxies.
This however also means it is not recommended to use a dynamic IP for the proxies. We might unknowingly end up on another proxy, do an inconsistent read (without first invalidating caches) and get a wrong result.
(Now that I think of it: we can remove this restriction if required by giving the proxies another identity than just their IP - if this is required please file a feature request.)

@khenderick
Copy link
Contributor

I would assume that in this case, the proxy would run on the ovs cluster of the "local backend" and thus means that the "global backend" should only be able to reach the "local backend"'s proxy (single ip & port) instead of possibly tons of individual ASDs?

@domsj
Copy link
Contributor Author

domsj commented Nov 9, 2016

indeed, the local asds don't have to be accessible for global proxies/maintenance

@wimpers wimpers added this to the Fargo RC2 milestone Nov 10, 2016
@wimpers wimpers modified the milestones: Gilbert, Fargo RC2 Nov 28, 2016
@wimpers
Copy link

wimpers commented Nov 28, 2016

After discussion with stakeholders moved to Gilbert as we don't have any customers which need it for FArgo.

@wimpers wimpers modified the milestones: Roadmap, Gilbert Feb 20, 2017
@JeffreyDevloo JeffreyDevloo modified the milestones: Backlog, Icebox Nov 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants