Likely,
I will use 128 GB data center SSD for every dedicated server for installation/boot sector and I will use EXT4 format for proxmox base.
For VMs, I will use every disk on EXT4 format(for VMs). (
https://prnt.sc/S9E7IdSxzCIz ,
https://prnt.sc/QQGXL2cg8aKT)
I will use TrueNAS for backup. RAID 5 or 10 should be and Proxmox Backup Manager will manage schedule.
Btw, If I reinstall proxmox, can I use VMs on the disk without losing data? How should I do it?
Probably, I will use CEPH with 10G network cards and with 15-20 servers for each clusters.
If you have those data center SSDs left over, it's a good way of putting them to some use, load on them should be very light.
Note that Proxmox does seem to support a ZFS stripe set for boot, it's just that I've never tried that, beause my first hardware target are actually NUCs, which only have a single NVMe drive, which I therefore had to partition.
But testing the functionality and effectiveness of a redundant ZFS boot is easy, if you use a "virtual infra" to do your failure scenario testing, which is much faster to do that way than on real hardware.
I've done all my higher level erasure code failure testing for Ceph using virtual hardware, because I just didn't have sufficient hardware available for QA testing.
Don't format any storage you plan to use with Cepth, Ceph will eat those disks whole and write its own on-disk data structures for storage.
What you use inside the VMs is entirely up to you and the OS you run there. Whatever is simplest is best and I guess with thousands of VMs you'll want an automated setup anyway. And you'll want a good plan on how you allocated and monitor storage inside those VMs, to ensure you're not overcommitting without good proactive monitoring. Few systems, applications and users deal nicely with what happens if storage you believe is there is in fact not.
But do make sure that you have discard or trim support within that OS and for the virtual disks you create, leave some physical spare area and use eager discard eagerly to keep your NVMe storage fast and healthy.
Proxmox doesn't do OVA exports or similar, but it is very good at backups. You alway have a backup, so the following is only for being faster.
A good hypervisor won't touch storage on re-installs. Best I've seen there was Xcp-ng, which would just pick up whatever was left there from before and across releases. With oVirt/RHV there is a very smart management engine that uses a database, so even if no data is destroyed on a HCI re-installation, without a backup of the management egine it's not much use. And it's been rather bad on full generational updates...
With Proxmox, I have not tried yet. But perhaps now I will. But if I do, I'll make sure to do that on a virtual farm (and with snapshots of the not-yet-desctructed state) first, because it's too much loss and work otherwise.
But generally I just try to avoid doing a full global re-install of Proxmox or any other Hypervisor (oVirt/RHV mostly) but go node-by-node. I move my VMs away from whatever I want to re-install and then just move them back afterwards. If it's a full generational (or platform) switch without backward compatibility (did happen elsewhere), I've worked with OVA exports and imports, which worked there.
While Proxmox doesn't do OVA, the disk images are really just QCOW and those are easy to handle.
I've transported quite a few VMs from VWare and VirtualBox to oVirt/RHV and again quite a few of those to Proxmox.
Far too manual for my taste, but of you have really massive volumes, you can write tools to automate that.
Remember, Proxmox is mostly just an API on top of commodity Linux technology so Ceph is Cepth, with or without Proxmox, ZFS, LVM and file systems are just holding standard QCOW files representing VM disks for use with KVM/QEMU.