Elegendő, ha csak 1 lemez kiesését bírja ki a rendszer. HA nincs, de 3-4 backup van mindenről és van még néhány szerver, ahová végszükség esetén át tudok relatíve gyorsan költözni.
Fura felhasználóid vannak, ha a teljesítmény különbséget észreveszik (pláne könyvelés munka alatt ami nagyon alacsony IO igényű monoton adatbevitel...), de azt nem bánják, ha egy 16 órás műszaknyi adatot újra fel kell vinniük, mert backup-ból visszaállsz diszk hiba miatt. Komolyra fordítva, semmiképp se 1 lemez hibatűrésed legyen production szerveren. Pláne, ha olyan is történik rajta, mint pl. számlázás, ami megy a NAV-ba élőben, ugyanis az pláne extra szívás újra csinálni.
Kereshetem a legnagyobb teljesítményt, mivel 2 TB-nál több tárterületre nincs szükségem.
Most nem kell 2 TB-nál több, vagy 5 év múlva nem kell majd 2 TB-nál több? Ugyanis - gondolom - ez egy új szerver, 5 év garival, diszkek 5 év garival, így nyilván minimum ennyire tervezik a használatát. Innetől nem a mostra kell a kapacitást tervezni, hanem a várható bővüléssel legalább 2-3 évre (ha nem is 5-re). Nehéz eladni 1 év múlva, hogy újabb 1-2 millió kell SSD-re, mert elinfláltad a kezdeti befektetést IOPS-re (amit valójában senki sem érez ilyen meló mellett...).
A Firebird szerverek 1-1 Windows Server alatt futnak, NTFS-en. Tehát csak NTFS és exr4 van a VM-eken.
Ha egy VM-nek egy fő feladata van, ahhoz válaszd a blokkméretet, ne az FS-hez. A Firebird 1, 2, 4, 8, 16 kB-os lapméretet enged (az újabbak talán 32k-t is), szerintem azt nézd meg, milyenek a meglévő DB-k és ahhoz válassz volblocksize értéket ezen VM-ekhez (legalábbis a Firebird DB-t tartalmazó vdiszk-hez).
17-en könyvelnek, mint állat (néhányan napi 16 órában!).
1 html gurunak hiszi magát, ő csinál néha érdekes dolgokat.
A többi csak átlagos irodai munkát végez...
Ez nagyjából zéró terhelés lesz a valóságban úgy a CPU-n mint a diszk IO-n. A legnagyobb IO terhelést a sok futó Windows szerver háttérfolyamatai fogják csinálni meg a terminál szerver user kiszolgálása... Kis túlzással mindezt rátennéd egy 8 HDD-ből álló RAID 10 kötetre, és a felhasználók nem éreznék a különbséget könyvelés és klasszik irodai munka során az NVMe-s optimalizált csillagrombolóhoz képest...
Érdemes lenne a szükséges Windows licencek számát is megvizsgálni. Lehet-e funkciókat összevonni egy Windows szerverre. Felesleges erőforrás pocsékolás 0% VM-en belüli user/hasznos terheléssel ennyi fizetős VM-et futtatni. Ráadásul a VM-ben futó Windows-ra is a host-ban lévő magszámra kell licenc, tehát egy 2x14 magos CPU-s host esetén minden egyes VM-ben futó Windows szervernek 28 magos licenc kell majd attól függetlenül, mennyi vCPU-t kap a VM. Ez nem kevés pénz. Meg mindre ugye végpontvédelem szerver verzióban, stb...
Le tudnád írni az általad javasolt fio parancsot a teszteléshez?
Sajna nem. Meg szerintem ilyen leírható nem is létezik. A fio (és a többi hasonló disk beckmark) nagyon jó az alapszámok megismerésére, az orbitális hibák kiszűrésére, de pontos, működés közben válható eredményt csak annyi beletett munkaval ad (vagy úgy sem), mint amennyi munka az igazi rendszer feltelepíteni és kipróbálni.
Csak tanácsot tudok hozzá adni: ne kérj tőle kötelező szinkron írást, mert a Proxmox/ZFS sem fog ilyent kérni alap beállítás mellett (nem is kell, UPS-sel ellátott szerver mellett a ZFS is bőven biztosítva van véletlen megállás esetére), és jelentősen rosszabb számokat fogsz látni, ami a valós működéssel nem lesz partiban. IOdepth ne 1 legyen, mert nem életszerű, ráadásul az NVMe pont abban erős, hogy jól kezeli a párhuzamos terhelést. A VM-ekben ZFS mellett simán bekapcslhatod a "writeback" diszk cache beállítást, az sokkal jobb írási eredményt fog adni pláne Windows alatt.