Ad MS SQL. Dovolil bych si pár maličkostí:
- failover cluster na MS SQL je teoreticky pro aplikaci zcela transparentní, protože se schovává za virtuální IP/jméno a služba clusteru si to už na nižší úrovni někam směřuje; aplikaci je buřt, co se s jeho dotazy děje, důležitý je, jestli na korektně položenej dotaz dostane korektní data.

- rozložení dat jedné tabulky do více souborů aneb partitioning - smysl to má dle mého názoru spíš pro odlití archivních dat pryč, aby pracovní datové soubory nebyly příliš velké. Partitioning kvůli paralelizaci budiž, ale to by musel být sakra HW... no ten ostatně máte Takže klidně, ale viz dále - pravidla pro filegroupu a počet jader:

- spíš než partitioning bych uvažoval o větším množství souborů ve filegroupách a konkrétní tabulky (např. subjekty) bych nasměřoval do jedné filegroupy s odpovídajícím počtem souborů (počet jader>n & počet aktivních disků v poli>n), takže např. na 4jádrovým stroji s RAID5 bych udělal filegroupu FG_SUBJEKTY s třemi soubory; recreatnul subjekty CREATE lcs.subjekty ON FG_SUBJEKTY [...]

- v triggerech pokud možno nevolat ad-hoc dotazy, i když parametrizované, ale uložené procedury (cachují se pro ně execution plany a je to rychlejší, nežere to paměť)


Na hraní je toho dost...
Pošlu ti zejtra jeden dotázek, docela by mě zajímala statistika waitů nad vaší DB