« Отговор #5 -: Aug 07, 2013, 23:43 »
Това нещо не става с прости сметки, нещата никога не са прости. На първо време как ще дефинираш "натоварване", CPU load? Утилизация на паметта? Bandwidth? I/O натоварване? После за какво натоварване говорим, някаква средна стойност? Worst case?
За да може да се правят някакви много груби сметки, трябва да имаш идея какви услуги ще работят и съответните услуги какви ресурси и как евентуално ги използват. Въпросните услуги обикновено имат някакви конфигуруеми лимити и можеш да смяташ евентуално средното натоварване (за което няма как да минеш без "пробите", демек инсталираш някакъв софтуер от сорта на ganglia или zabbix и следиш как протичат нещата във времето). Оттам можеш грубо да сметнеш и worst case сценария, макар че нещата не винаги скалират линейно и за това трябва да знаеш добре как работи софтуера. Според мен много точни сметки няма как да си направиш, но можеш да направиш консервативни предвиждания с известен резерв. Ако не искаш компромиси с качеството на услугите съответно ги правиш спрямо worst case-а.
Когато нямаш идея какъв workload ще търкаляш, разбира се е трудно да се правят предвиждания.
Също така, дори и да имаш някаква груба сметка, нещата може да са доста tricky, особено с виртуализацията. В общи линии, утилизацията на паметта е най-лесно контролируемото и най-предсказуемото нещо, същевременно за жалост е и рядко bottleneck-а в цялата работа, най-малкото защото паметта е евтина и особено ако работиш с java приложения, където heap size-а лесно се контролира, нещата стават прости.
Също директно можеш да алокираш VCPU-та, което е колкото хубаво, толкова и гадно когато виртуалните машини не търкалят CPU-интензивни приложения.
Индиректно донякъде можеш да контролираш I/O и мрежовото натоварване като ползваш различни мрежови интерфейси и/или различни блокови устройства, само че тук нещата загрубяват доста. Примерно споделянето на едно и също дисково устройство прави нещата неконтролируеми, без значение дали и на какви дялове се намират и дали се ползва LVM, особено с механични дискове (със SSD теоретично би могло да се направи някакъв load-balancing с weight при I/O-то, вероятно има такива експерименти, но това би трябвало да важи само за четенето, при писането има хардуерен wear-leveling и съответно недетерминирано време). Дори и на различни дискови устройства обаче, bottleneck-а може да е общата шина, която споделят.
Съответно с мрежовите ресурси е същото - няма как да си абсолютно сигурен че едната виртуална машина ще използва примерно точно 30% от честотната лента на интерфейса, можеш разбира се да заделяш различни интерфейси, но това не е особено feasible по разбираеми причини, а и гранулярността така е доста груба.
Та...предлагам на първо време да идентифицираш workload-а, да си направиш замервания за някакъв период, без значение с какъв софтуер, дали ще е с красиви графики като ganglia или пък нещо грозно като sar. След това за да хванеш worst case-овете или се опитай да направиш сметките с презюмпциите за линейно нарастване на утилизацията на ресурсите с броя на клиентите и съответно там лимита на максималния брой клиенти (което може да е доста лоша идея), или си направи stress test-ове с подходящ софтуер (което пък е трудно да се направи коректно). Така ще знаеш ако ще deploy-ваш нови виртуални машини със сходен workload горе-долу докъде опират възможностите. Ако не е сходен...ами внимателно, на стъпки, със замервания, с тестове. И накрая като си правиш финалните сметки винаги си оставяш един хубав резерв.
Всичко това има смисъл само ако предоставяш някакви услуги и всичко това има значение. Ако просто си експериментираш и си играеш, тогава не си заслужава усилията, в крайна сметка няма голямо значение и метода проба-грешка върши работа.