Hi,
we think that we fixed all known issues in the drbd-9.2 branch. (With the
exception of the RDMA transport, which still has known issues)
This time it comes with a new feature: Support for network namespaces
That means that a drbd path (the part of a drbd connection that has IP
addresses), will live in the network namespace, from which it was created.
You might ask, what is this good for?
This is very useful when it is used with Kubernetes. Up to now Piraeus
Data-Store could only use the host networking namespace. Not the networking
namespace that is available to the containers. In various managed Kubernetes
environments this "host networking" might be constrained, shielded from
the internet, etc...
With that new feature, Piraeus Data-Store can place the DRBD traffic into the
other network. I would call it the "overlay network" (though I am not sure if
Kubernetes people use that expression).
A short reminder, the other advantages of drbd-9.2 over 9.1 are:
* lower latency for mirrored write requests
* lower contention between application IO and resync IO
* much better resync performance on thinly provisioned backends
* support for network namespaces
* a RDMA transport (still has known issues)
Please help test this pre-release.
9.2.0-rc.7 (api:genl2/proto:110-121/transport:18)
--------
* support for network namespaces
* multiple fixes to the merge-discards-during-resync functionality
* fix reference counting in AL with drbd-8.4 peers
* stricter limit for the set of characters allowed in resource names
* merge changes from the drbd 9.1.9 release
https://pkg.linbit.com//downloads/drbd/9/drbd-9.2.0-rc.7.tar.gz
https://github.com/LINBIT/drbd/commit/61c4a219d2bba3241c60ea6d69bab70e93d1de84
_______________________________________________
drbd-announce mailing list
drbd-announce@lists.linbit.com
https://lists.linbit.com/mailman/listinfo/drbd-announce
we think that we fixed all known issues in the drbd-9.2 branch. (With the
exception of the RDMA transport, which still has known issues)
This time it comes with a new feature: Support for network namespaces
That means that a drbd path (the part of a drbd connection that has IP
addresses), will live in the network namespace, from which it was created.
You might ask, what is this good for?
This is very useful when it is used with Kubernetes. Up to now Piraeus
Data-Store could only use the host networking namespace. Not the networking
namespace that is available to the containers. In various managed Kubernetes
environments this "host networking" might be constrained, shielded from
the internet, etc...
With that new feature, Piraeus Data-Store can place the DRBD traffic into the
other network. I would call it the "overlay network" (though I am not sure if
Kubernetes people use that expression).
A short reminder, the other advantages of drbd-9.2 over 9.1 are:
* lower latency for mirrored write requests
* lower contention between application IO and resync IO
* much better resync performance on thinly provisioned backends
* support for network namespaces
* a RDMA transport (still has known issues)
Please help test this pre-release.
9.2.0-rc.7 (api:genl2/proto:110-121/transport:18)
--------
* support for network namespaces
* multiple fixes to the merge-discards-during-resync functionality
* fix reference counting in AL with drbd-8.4 peers
* stricter limit for the set of characters allowed in resource names
* merge changes from the drbd 9.1.9 release
https://pkg.linbit.com//downloads/drbd/9/drbd-9.2.0-rc.7.tar.gz
https://github.com/LINBIT/drbd/commit/61c4a219d2bba3241c60ea6d69bab70e93d1de84
_______________________________________________
drbd-announce mailing list
drbd-announce@lists.linbit.com
https://lists.linbit.com/mailman/listinfo/drbd-announce