A kerdes leginkabb attol fugg szerintem hogy mennyi virtual host geped van vagy lesz varhatoan a 2 storage-hoz, illetve mennyire fix-ek a vm-ek avagy mekkora a valtozas , hogy kell uj, modositani kell meglevo alatt tarhelyet stb.
Mert nagyob geppark, gyakran valtozo vm-ek eseten erdemes ugy kezelni a kerdest hogy van iscsi storage-od es arrol lun-okkal ajanlasz ki vm-eknek tarhelyet siman. Aminel vm-et ha kell at lehet at lehet migralni masik host gepre, olyan vm-eknel ahol meg kell a fokozottabb redundancia ott tehetsz 2 (vagy tobb) vm-et a feladatra es vm-eken belul csinalsz clustert.
Ha kevesebb geprol van szo, ritkan valtozik akkor lehet ertelme esetleg szenvedni multipath-al, plusz raid-el vm-ekbol vagy hasonlokkal.
Amugy a 2 otletedet nezve:
1, multipath-nak minimalis overhead-je van, igazabol meg nyerhetsz is vele teljesitmenyt ha tobb gigabites link kozott el akarod osztani az iscsi forgalmat, de ezt ha jol tudom ahogy irtad is nem kezeli libvirt (bar lehet ujabban mar igen, voltak ra tervek). Ha viszont azt nem konfigbol veszi hanem te takolod ala kezzel akkor azzal csak szenvedni fogsz migracio, host elinditas/leallitas es hasonloknal. En azt mondom ha tamogatja libvirt teljes ertekuen akkor ok, egyebkent inkabb ne hasznalj multipath-t a host gepen.
2, ha migralgatast akarsz akkor felejtsd el inkabb az ilyet, hogy 1 nagy tarhelyen clvm alol vm tarhelyek.
A host/guest aloli raid1 iscsi folottnek se vagyok hive, tobbszorosen terheled a halozatot es a gepeket.
Akkor mar inkabb 2 storage koze direkt link drbd-vel es cluster ip-vel, kozos ip-n keresztul csatolod fel iscsi lun-okat, link redundanciaert meg inkabb valami bondingot host es storage gepekre.