Nu, Proxmox nepoiužívám, ale podobné konfigurace mám v provozu, kde je linux (dle stáří instalace CentOS5/6/7) dva uzly v HA clusteru a nad tím virtuály buď v KVM nebo kontejnery, dneska už LXC. Takže je někde řešen sdílený disk pomocí DRBD, někde jsou sdílené SAS/FC disková pole a teď po novu testujeme replikaci lokálních disků pomocí GlusterFS (jako náhrada za DRBD).
Tak to vezmu pozpátku...
Quorum disk - musí to být blkové zařízení, takže nelze NFS/Samba/Gluster, ale jen případně to iSCSI. Jeslti je nutný záleží jak máš řešen fencing. Pokud bude použito například externího APC Powerswitche (nebo dvou, pokud používáš duální napájení), který serializuje přístup a nedovolí, aby oba uzly se mohly vypnout naráz, tak ho nepotřebuješ. Pokud chceš vypínání řešit přes IPMI, DRAC a podobné, tak si musíš silně vyhrát s tím, aby nemohlo dojít k současnému vypnutí obou strojů vzájemě (několikrát jsem v praxi už zažil), takže toto řeší quorum disk, když se správně načasují akce, aby bylo deterministické vypínání. Jiná metoda je, že fence agentům vnutíš timetouty tak (pokud to podporují), aby v rámci určité naděje nemohl být příkaz k vypnutí poslán naráz. Pokud chceš používat IP tie breaker, tak qourum disk potřebuješ také (pokud daný uzel ztratí IP spojení s defualt bránou, tak se ma zastavit a předat vše na druhý uzel, u novějších verzí clusteru s pacemakerem to řeší checking objekty a quorum disk nepotřebuješ a ani není podporován).
Quorum disk mám použit všude, kde o něco jde, ale tam je použito i rozumné duální diskové pole, z kterého ty virtuály jedou (takže ztráta spojení s quorum diskem i znamená, že uzel přišel o diskové pole a má jít k zemi).
Live migraci nemusíš dělat přes ten vyhrazený kabel, pokud se má migrovat jen mezi těma dvěma uzly, tak stejnou spojkou jak pro DRBD.
DRBD šlape relativně OK, ale nepočítej s tím, že bude rychlejší přes ten bond s balance-rr. To bude pravděpodobně pomalejší, jak když použiješ active backup nebo 802.3ad. Bohužel. Vyvolává to víc problémů, jak užitku. Pokud třeba vezmu dva 10 Gbps porty a udělám bond balance-rr, tak tím spojem nedostanu při migraci virtuálů víc, jak cca 4 Gbps, pokud to jede v 802.3ad, kde to jde fakticky jen jendou linkou, tak to jede 9 Gbps. u DRBD i GluterFS replikace je to stejné. Takže pokud chceš větší replikační rychlost, tak buď 10 Gbps ethernet nebo dneska se z pár šupů dají koupit Infiniband karty, takové dvě dovuportové IB karty s duálníma 20 Gbps porty a propojovací 3 metry metalické CX4 kabely dohromady možná pod 7 kKč na ebay.uk a máš 20 Gbps linku. Navíc mající hardwarové RDMA, které dneska už umí i DRBD8.4 použít (transport typ SDP tomu říkají), taktéž KVM umí migraci přes RDMA a trvá pák desítky milisekund nebo po novu i mikrosynchronizace, takže podpora fault tolerant systémů. Přes infiniband funguje i normální TCP/IP (přes IPoIB modul), takže i cluster komunikace jde takto poslat. Nové Infiniband karty jsou už 40/56 Gbps na QSFP, většina výrobců ti dodá rovnou se serverem, stojí cca jak 10 Gbps ethernet (drahé jsou IB karty softwarověvě přepinatelné jako 40 Gbps IB nebo Ethernet). Nicméně infiniband svět, zvláště point-point propojení, je svět pro otrlé. :-(
Neděllal bych z toho RAID10. Udělal bych normálně 3 ks RAID1 polí, měl nad nima 3 DRBD disky a každé to pole syncoval zvlášt. Pokud nad tím chceš pustit hromadu virtuálů, bude to tak rychlejší na IO, jak když to slepíš dohromady na RAID10. Váýhoda i je, když ti nějaký ten DRBD disk padne, tak aspoň něco pojede. SATA nemám, mám to všude na SAS 15 krpm diskách, ale to s tím RAID10 kontra RAID1 bude stejné pro oba.
Navíc, pokud to uděláš jako dva drbd disky, tka budeš mít mezi servery dvě TCP/IP spojení otevřená, když si dobře zvolíš TCP porty a uděláš ten bond jako 802.3ad s L4 politikou, tka dosáhneš, že každý drbd disk ti pojede sync přes jeden Gbps port v tom bondu (a při zdechnutí daného propoje pojedeš tím dalším).
