It is with great pleasure I introduce Open vStorage 2.1. Yes, we went straight from version 1.6 to 2.1. We just had so much interesting features to add that we just couldn’t call it 2.0.
It is important to know that Open vStorage now comes in 2 flavors: a free, unrestricted version and a free, restricted community version which includes our own new Open vStorage backend and allows to run Open vStorage as hyperconverged solution. At the moment both versions only feature community support. The unrestricted version is open-source and allows to add almost any S3 compatible backend (Ceph, Swift, Cloudian, …). The community version is the restricted version of our future paying product which includes support. A paying Open vStorage version will be released in June. In case you want to run Open vStorage hyperconverged out of the box, you will need to have the Open vStorage Backend which is highly optimized to be used with Open vStorage.
So what is new in 2.1 compared to 1.6:
- Run Open vStorage as hyperconverged solution: you can now use local SATA disks inside the host as (cold) storage backend for data coming out of the write cache. Open vStorage is now hyperconverged and supports hot-swap disks. For our free community edition you can go upto 4 hosts, 16 disks and 49 vDisks. Currently only a limited set of RAID controllers are supported (LSI). In case you want to use Open vStorage in combination with the Seagate Kinetic drives, the Open vStorage Backend will also be required (future version).
- Flexible cache layout: the Open vStorage setup is now more flexible and allows to identify multiple SSDs as read cache device. During the setup you can also indicate which device you want to select as write cache. When you create a vPool this will be taken into account when presenting default values.
- Improved supportability: you now have the option to send heartbeats to our datacenter and if necessary open a VPN connection so we can offer remote help. There is also an option to download all logs straight from the GUI with a single mouse click.
- New metadata server: when a volume was moved from one host to another, you typically had a few seconds up to a minute of downtime as the metadata had to be rebuilt on the new host. We now have a metadata server topology which supports a master/slave concept. In case the volume is moved and the master server is no longer accessible you can contact the slave metadata server. This means that the downtime will be only a few milliseconds. (Some more info https://www.youtube.com/watch?v=Yy2EhJkFr04)
- Performance improvements: we now allow more outstanding data in the write cache before the data ingest coming from the VM will be limited.
In case you have questions, feel free to create a post in the Support Forum.