You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.)
The text was updated successfully, but these errors were encountered:
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?
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.)
The text was updated successfully, but these errors were encountered: