Azok a clusterezési technológiák és szoftverek, amik uniform szervereket várnak el futtatókörnyezetként, komoly hátrányban vannak azokkal szemben, amelyek képesek a hardware különbségeit (pl memória méret, elérési sebesség, sustainable és random IO, CPU-k száma és sebessége, hálózat, satöbbi) kezelni. Ugyanis az ügyfelek nem szeretnék évekkel vagy akár csak hónapokkal előre megvenni a hardware kapacítást. Pl egyes projectek esetében nem nagyon lehet kitalálni, hogy mekkora kapacításra van szükség. Meg hát nem is tudják, kapnak egy adott összeget egy üzleti évre és legközelebb majd a következő üzleti évben lehet hardware-t vásárolni. Akkor már más lesz a kinálat. Még ha mindig a listán is van a régi szerver tipus, akkor is valószinűleg más hardware fogja akkor megérni, más az akciós, satöbbi.
Például nekem a cassandra, amikor teszteltem nagyon makacsul ragaszkodott ahhoz, hogy egyenlően ossza fel a keyspace-t minden alkalommal, amikor új node-t csatlakoztatok.
Ezt gondoltam csak azért írom ide fel, mert nem olvastam egy könyvben sem eddig, ez amolyan magánvélemény.
Ötlet: Csak példaként egy private cloud-ba érdekes lehetne olyan logikát írni, ami felstartol mégegy mongodb szervert, ha a cluster átlagos terhelése X főlé nő, lekapcsol egyet, ha Y alá csökken, megtart tartalékba Z-t mindig. Nyilván nem csinál ilyet az oVirt, de más rendszerek biztosan igen. Bocsi, hogy megint oVirt lett belőle...
Ez persze a fizikai vasakon futó rendszereken nem segít, nem "silver bullet", de egy egyszerű megoldás lenne a probléma java részére.
