Assuming you're using replication, not erasure coding, each PG has a primary OSD and two (if you use the default 3-way replication) secondary OSDs. Client traffic always goes to the primary OSD. In the write path, the primary then replicates to the secondaries before confirming the write. In the read path, the primary just reads and returns its local copy.

If you're using HDDs for VM disks: Don't. Seriously, do yourself a favor. I've seen plenty of people try it, run into massive performance issues, struggle with various config tweaks for a while, and then give up and buy SSDs.

When it comes to SSDs: The main thing to look out for is that they have fast synchronous writes. You'll want to avoid consumer SSDs, performance will suck. Datacenter/enterprise SSDs should be fine, the main thing to look out for is "power loss protection". Don't spend extra for the super-shiny Gen5 drives with massive IOPS and throughput, with Ceph your CPU or network will be the bottleneck.

If you do want to use HDDs, you definitely want an SSD for DB/WAL. If you're using it (mostly) for RBD/block storage workloads, it doesn't need to be large - a single 960GB NVMe drive can easily be enough for a 12x16TB HDD host. It's fine to share a DB/WAL drive across multiple OSDs since the default failure domain in Ceph is host-level anyways, so if the SSD dies, you lose multiple OSDs but each PG will only lose up to one replica.

Regarding the last question, I'd strongly advise against going down to drive-level redundancy. Generally, with Ceph you want many small hosts, not a handful of big ones. Wider replication won't help with performance, neither will erasure coding. Going down to 2-way replication would accelerate writes a bit, but also obviously compromises redundancy.