After the SFD5 presentation my colleague Christiaan wrote a blog about the newly announced features of PernixData FVP.
Christiaan mainly talked about the possibility to use RAM for caching.
Today I was invited for a PernixPro webinar and we talked a little more about the compression of the replication traffic. Mainly about CPU cost of compressing (only 1 to 2 percent). The smart thing is that they only compress the replication traffic and not decompress on the replica host, because FVP doesn’t use this data on the replica host, normally.
Satyam talked about latency as well, it was a bit hard to explain without a whiteboard so I hope I understood it correctly.
Storage performance is mostly about latency, not throughput so let’s dive into that. A write to a local flash device takes a certain amount of time. Let’s call that time X for now. If you add replication then you have to wait for the data to be transferred over the LAN. Since the data in sent over the network some latency is added. Quite a lot actually. Let’s call this latency T. On top of network latency there is also the time the replica system needs to write the data to the flash. Let’s assume all flash devices in the cluster are identical.
That means writing the replica takes the same amount as we need to write the data on the primary machine. So we’ll call this time as well.
Then the replica machine has to respond with an acknowledge which has to travel back over the same network. Let’s call the time this takes A.
Now total latency can calculated like this: T + X + A.
To reduce this latency PernixData introduces compression on replication traffic. When you compress the data before sending it you add a little latency because the CPU needs to do some calculations. Let’s call this time C.
After the data is compressed we need to send less data over the network so the transport latency is reduced.
We will call this time Tc. When the data arrives at the replica machine it is not decompressed.
Instead, it is written to flash in its compressed form. This means the time the replica system needs to write the data to flash is actually shorter than the time the source system needed to write to local flash.
We’ll call this time Xc. Of course we still need the time to acknowledge the write (A).
So actual latency for the replica can be calculated as follows: C + Tc + Xc + A.
Still with me? Now let’s think a moment about what this could mean. The replica system needs to spend less time writing the replica to the flash device than the source system. This could offset the time needed to compress the data and then transport it. So the time needed to compress + transport + write the replica data could actually be shorter than the time needed to write the replica data on the primary machine. Yes, that means PernixData just invented time travel and can now write replica’s to remote systems without increasing the write latency experienced by the virtual machines.
They showed several scenarios where customers did not need to upgrade their network to 10Gbe, off course upgrading it to 10Gbe is always better. But no longer necessary when using a replica host, so this is a good opportunity to try out PernixData FVP without any direct investments.
If you are interested in PernixData FVP and you would like to see FVP in action don’t hesitate to contact me.
