Yeah, I think you’re looking at a 5 nodes LXD cluster, that gives good DB redundancy.
For storage, unless latency is a major concern of yours, I’d setup one Ceph OSD per drive in those systems, create one or more Ceph pools and give that to LXD for storage.
This should effectively allow you for (slowly) losing up to 3 of the 5 nodes with the DB moving as needed (needs at least two online) and same for the data on Ceph which would have 3 replicas spread on the cluster and be moved as nodes fail.
Note that if you suddenly (exact same time) lose the wrong two nodes, you will be offline until they recover as LXD can re-balance DB roles during clean shutdown (maintenance) but if you somehow kill two out of the three active DB nodes, there’s no more quorum and things will hang until one of them is brought back up.
Similar story with Ceph, you’ll want at least 3 Ceph monitors and I usually also run mgr/mds on the same nodes. Given a small cluster of 5, the easiest would likely be to run mon/mds/mgr on all 5 too. If the cluster gets larger you may want to keep that to just a few of the nodes though.
Ceph can expose both blocks (RBD) or filesystems (FS). LXD supports both but instances can only be backed by RBD. FS is very useful if you need shared data between instances running on different nodes though, so I usually set both up on my clusters.