I've tried to look up the protocol and therefore any specific hardware choices relevant to ZFS send/receive for replication, but can't find details beyond a statement that ZFS uses a "serialised" data stream (which implies its own protocol not SMB/NFS/whatever).
I've got to set up a new FreeNAS backup server, to do "antisocial hours" replication of an existing FreeNAS server. The protocol and structure of send/receive could be important to choosing the hardware and networking links. The spec for the existing (main) server and network is below.
For example, if send/receive runs single threaded then a CPU with fast single-thread performance matters more than core count. There might be modern instructions it can take advantage of for speed. Perhaps it would run best with a dedicated network link rather than sharing a general link. Perhaps there are specific cache considerations (if it's a sync vs. async protocol or has other features where caching can help or other caching is useless). Probably RAM requirements differ for a pure backup server, but if so I'm not clear which way (up or down) or how much is sensible.
There might also be useful network stack/OS/ZFS/HDD driver tuning since ZFS send/rcv is quite a specialised task.
I suspect that the hardware and config for a pure backup server might have slightly different emphasis and needs compared to a "normal" primary server, but I can't find any info specific to protocol used and hardware selection for a backup server. My question is more about the send/receive protocol and its demands, than a direct question of what hardware to get, so I'm posting it under "general".
It would really be useful to get more detail about the protocol and nature of work and caching as relevant to ZFS send/receive, and anything else relevant to hardware selection for ZFS send/receive on FreeNAS, to help me decide any hardware choices that are relevant.
Server/network spec:
I've got to set up a new FreeNAS backup server, to do "antisocial hours" replication of an existing FreeNAS server. The protocol and structure of send/receive could be important to choosing the hardware and networking links. The spec for the existing (main) server and network is below.
For example, if send/receive runs single threaded then a CPU with fast single-thread performance matters more than core count. There might be modern instructions it can take advantage of for speed. Perhaps it would run best with a dedicated network link rather than sharing a general link. Perhaps there are specific cache considerations (if it's a sync vs. async protocol or has other features where caching can help or other caching is useless). Probably RAM requirements differ for a pure backup server, but if so I'm not clear which way (up or down) or how much is sensible.
There might also be useful network stack/OS/ZFS/HDD driver tuning since ZFS send/rcv is quite a specialised task.
I suspect that the hardware and config for a pure backup server might have slightly different emphasis and needs compared to a "normal" primary server, but I can't find any info specific to protocol used and hardware selection for a backup server. My question is more about the send/receive protocol and its demands, than a direct question of what hardware to get, so I'm posting it under "general".
It would really be useful to get more detail about the protocol and nature of work and caching as relevant to ZFS send/receive, and anything else relevant to hardware selection for ZFS send/receive on FreeNAS, to help me decide any hardware choices that are relevant.
Server/network spec:
- Supermicro X10SRi-F, Xeon E5-1620 v3 (3.5 GHz single-thread for SMB), 96GB 2133 RDIMM, Chelsio T420 10G PCIe NICs (1 port used, 1 spare), Intel P3700 NVMe ZIL, Samsung 512GB NMVe L2ARC. Storage is 36GB raw capacity (SATA/SAS mix, 9211-8i HBA) configured as mirrored vdevs, the pool is about 50% used, split about half each between SMB file shares and an iSCSI ZVOL for ESXi. There are no local VMs or plugins running right now, purely file serving. The replication server will go on the same LAN for now, eventually moving to a remote FTTC link but not for about a year. A dedicated direct 10G link between the two is also possible while they are in the same building. Reduced responsiveness/bandwidth at 3am while sending is acceptable. The backup server might do other tasks during daytime but that's not relevant as I can factor in their HW needs myself (if needed).
Last edited:
