I would expect that for benchmarking a three machine cluster, you could probably get away with only having one (other) machine driving the benchmarking load.
Someone did contribute a YCSB backend for FoundationDB. However, YCSB isn’t a great benchmarking tool for transactional databases, and particularly not for FoundationDB. In a transaction, the first operation done pays a cost of fetching and calculating a read version, which is frequently a 1-2ms operation. A transaction can then do any number of reads within 5 seconds, with a point read typically taking ~0.3ms. YCSB does one read or one write per transaction, so it ends up turning into a benchmark of getting read versions instead of reads or writes to the database. See How to scale foundation db reads - #4 by alexmiller for a deep analysis of this sort of workload.
So YCSB will give you an idea of how a YCSB-like workload would run on FDB, but not anything that cleanly extrapolates to what your application would do with FDB. If you’d still like to run YCSB, then our friends at PingCAP very generously included FDB in their go port of YCSB also ANN: benchmark FoundationDB with Go YCSB . There are benchmarks that you can find that were meant to be better tests of transactional databases: YCSB+T, TCSB, or TPC-C, but I’m not aware of a FDB backend for any of them.
We’ve previously encouraged folk to use the same workload generating tools that we use for performance tests internally. You can find some examples of doing so in Why doesn't my cluster performance scale when I double the number of machines? - #12 by alexmiller and searching for “multitest” gives other threads as well.