> Здравствуйте,
> необходимо мониторить 3К узлов (3 параметра мониторинга с кажого узла).
> Есть ли необходимость держать заббикс-сервер на одной вирт. машине, а СУБД на
> второй? если ли необходимость в использовании заббикс-прокси?
> Или достаточно иметь одну машину, например с8 ядрами и 32гигами памяти с
> ссд-дисками?
> P.S. узлы разнесены географически, связь нестабильная.

У меня cacti прекрасно справляются с 15K метриками на 2 ядрах и 4ГБ ОЗУ.

> Здравствуйте,
> необходимо мониторить 3К узлов (3 параметра мониторинга с кажого узла).

[Про NVPS-ы и выбор сервера, вроде, где-то на wiki Zb было. Я документацию не читаю, поэтому напишу своё:]

Если их снимать раз в минуту, то 3k*3/60 = 150 NVPS. В принципе, это немного...

Если снимать раз в 15 минут, то 3k*3/60/15 => 10 NVPS.  Это вообще "ничего" почти что.

Если - раз в 6 сек. (считать удобнее|-), то 3k*3/6 => 1500 NVPS.

Это примерно, как мои Zb - нужно много памяти и шпинделей на сервере БД.  У меня БД "локально" на одной машине с Zb и апачем.  LA5 "в среднем" в районе 3.6 на одном сервере (много "external" скриптов) и 1.2 на другом (snmp в основном). Т.к. LA включает дисковую нагрузку, процессорная, видимо, во вполне допустимых [нижних] пределах [для тех серверных xeon-ов~].

У меня серверы упираются в диски -- при обновлении сервера заказывал начальству "больше шпинделей". Добавление ОЗУ (=системного дискового кеша) тож помогло. Тюнинг PostgreSQL и таращение в графики само-мониторинга -- "забесплатно" и беспрестанно (и, в моём случае, на достаточно любительском уровне: прикинуть к носу, а чего б покрутить -- попробовать параметр-другой, выбрать лучший результат -- забыть на год-другой; почитать слайды про тюнинг Pg -- решить, что у меня-то всё по-другому, пройти мимо; ипт).

Прошлый раз хвастался метриками в апреле 2013-го:
    http://www.opennet.ru/openforum/vsluhforumID13/848.html#1
//Пойду, наверное, обновлю Доску Само-почёта.

> Есть ли необходимость держать заббикс-сервер на одной вирт. машине, а СУБД на

СУБД в виртуалке обычно как раз _не_ рекомендуют.

Для 10 NVPS вообще без разницы: одна виртуалка на всё и забыть. Для 150 NVPS - наверное, тоже (но у меня опыта с Zb/Pg в вирт.нет никакого - чисто умозрительно), но по мне, так физ.сервер -- было б спокойнее. На 400-700-1000+ NVPS, как мне кажется, виртуализация будет пятой ногой -- лишней ненадёжностью и проедателем ресурсов впустую. (Хотя, допускаю, может, какая "профессиональная" "промышленная" виртуализация и даст какой-нибудь выигрыш в районе дать/поменять забиксу ещё ОЗУ и шпинтелей и не будет [заметно] тормозить при этом. Прямого опыта у меня тут нет.)

> второй? если ли необходимость в использовании заббикс-прокси?

Zb-прокси это вынос сбора ближе к части "целей". При этом _триггеры_ считаются и их собранные данные инсёртятся в "большую" базу на _центральном_ сервере.  То есть графики за периоды, когда связи с "в туда" не было, со временем появятся на основном сервере, но _некоторые_ триггеры могут срабатывать ("чувствительность к nodata"~) из-за перерыва в связи с прокси, а не проблемах с самими целями.

Ну, ещё трафик опроса не гонять через "длинные концы" -- какие-то из айтемов м.б., наверное, м.б. чувствительны к плохой/далёкой/пропадающей связи с целью.  Лишние SMS по куче триггеров, когда "там просто" притормозил интернет (бывает и с прокси, и с отказом какого-то общего  локальныого сервиса (свич "в центре", БД одна на всех, авторизация итп)), -- проблема (особенно, когда их вываливается 100 или 300 или 500 и они "доходят" до людей в течение часа-двух.  особенно :/ ночью).

> Или достаточно иметь одну машину, например с8 ядрами и 32гигами памяти с
> ссд-дисками?

ssd хорошо и быстро, но zb постоянно утюжит диски -- про когда он "протрёт" ssd (слышал, когда-то это было проблемой) я ничего сказать не могу.

> P.S. узлы разнесены географически, связь нестабильная.