Всех приветствую.
Помогите определиться, как лучше сделать в плане производительности.
Есть сервер (2 проца Xeon E5420, 16Gb RAM, SATA RAID). На нём VMware ESXi. Планируется установить виртуальную машину с Windows Server 2008 Standard. Будет выполнять роль контроллера домена, файлового сервера и сервера 1С.
Базы 4 штуки (две Бухгалтерии и две ЗУП).
Пользователей Бухгалтерии ~ 10-15 на каждую базу, ЗУП ~ 5-10 на каждую базу.
Вариант 1. Поставить на ту же виртуалку сервер баз данных (PostgreSQL под Windows) и выделить ему почти всю оперативку
Вариант 2. Поставить вторую виртуалку на тот же сервер. На неё Linux и PostgreSQL. Оперативку делить между ними.
Другие варианты пока не рассматриваются. MS SQL - дорого. Windows и PostgreSQL на другом сервере тоже не подходит, так как придётся покупать вторую лицензию на Windows.

любую СУБД не рекомендую ставить на виртуалку....

по этому любой твой вариант будет приводить к трудно диакностируемым тормозам

Азанафея там вообще виртуалка?

(0) Если такое плохое настроение- я бы РАЗНЕС на твоем месте.

1) увеличь память, раз баз 4штуки
2) SATA поменяй на SAS
3) на этом серваке держи базу и сервер приложений, тут же можно будет поднять терминал
4) а в качестве фалового сервера и контролера домено выдели другой сервак - попроще.

ссдишный винт еще поставь, его пробрось в виртуалку с бд на esxi, помимо PostgreSQL можно еще дб2 попробывать

Зачем виртуалка?

поигрались с виртуалками, при переходе с виртуалки на физ сервер - выигрыш в производительности в 4,5 раза
самое странное - при увеличении количества виртуальных серверов больше 2-х - адение производительности больше чем  в 2 раза. Правда вирталка HyperV

+(7) виртальных процессоров на сервере

виртуалка очень удобна админам, но при этом всем остальным от неё один геморрой...

Экономнее будут память расходоваться.

2(1) какая разница, если база будет лежать на ДС-ке. И она будет одинаково доступен как виртуалке так и хосту?

а, ну у него САТА РЕЙД... это детство.

На этом сервере есть ещё одна виртуалка, на которой прокси и внутренний сайт.
Получается, что если совсем отказываться от виртаулизации, надо добывать ещё два сервера железных.

(13) на виртуалке оставляй, АД, файло помойку, вебы и т.д.

под скуль/посгрей + 1с нужна физическая железка

(14) +1

т.е. 1С тоже лучше выгнать с виртуалки?
Не очень хочется ставить сервер 1С на Linux. Также как не хочется покупать ещё одну винду под этот сервер.

(7) потомц что узкое место системы - жесткие диски которые как правило тоже виртуалят...

Сервер 1С воткните в какой-нибудь комп с Sandy Bridge с большим кэшем  и 16 гигами оперативки. И поднимите RAM под темпы гигов на 10.

а мы вынесли sql на старое железо с раид10 на scsi, а терминалки и сервер предприятия в хиперви держим.

(19)+ по мониторам смотрим, а нагрузка на sql мизерная, в основном парится серв.предприятия по процессорам, ну и терминалка конечно

Я продолжаю непонимать, зачем виртуалка?

Ничто не мешает поднять сервер 1С на Win7

(13) Ничто не мешает вам сделать один сервер с нормально установленной виндой. На нем скуль, сервер 1с, ваш прокси и внутренний сайт.

Почему вы думаете что если от сервера отхапаете ресурсы для виртуальной машины на которой прокси и внутренний сайт, то 1с-ке будет непременно лучше, чем ежели бы это всё было вместе с 1с-ой под одной виндой?

(23) может быть, ТС планирует потом легко и непринужденно мигрировать на другой сервер?

(24) вопрос в том, что с нуля ему будет сложно там развернуть заново прокси и внутренний сайт? а с виртуалки развернуть легче?

Прокси и внутренний сайт на Linux. Переносить их на Win совершенно не хочется. Кроме того где-то читал статью, что очень рекомендуется держать сервер предприятия и сервер баз данных на разных серверах.
Получается, что лучше отказаться от виртуалки, добавить контроллер и диски SAS, поставить на сервер Windows. Туда же и сервер 1с, и сервер БД, и контроллер домена и файл сервер. А всё линуксовое вынести на другой

(26) определенно так лучше. чем сервер 1с и СУБД вешать на виртуалку.

А про статьи не переживайте. Это всё зависит от нагрузки на сервер. Я думаю вам пока одного сервера хватит с лихвой.

виртуалки это же модно. че вы все, зачем, да зачем.

(0) есть ведь и более простые способы насолить заказчику, нежели использовать виртуалку

Буквально месяц назад собирал базу БП по частям после ахрененно настроенного обмена с УТ в итоге 25 000 одинаковых групп номенклатуры, в каждой из которых от 2 до 12 одинаковой позиции. Запросил у Московских колег виртуальный сервак ибо обработка поиска и замены значений уж больно долго работала. Дали мне такой виртуальный сервак примерно такой же конфигурации только памяти в 2 раза больше было. Запускаю обработку и ожидаю. Банальный подсчет показывает что что то не так, идет не так как надо. Типовой замер производительности показывает большую нагрузку на дисковую подсистему. Звоню админам и оказывается что там помимо меня еще 5 машин под разные задачи используются. Витоге пришлось отказаться от этого чуда ибо  машинка слабее в 3 раза но с SAS-ким винтом отработала в 2 раза быстрее. Итог следующий, разместить то можно но вот нужно ли....

(9) хорошо сказал

(0) мс скл станет значительно привлекательнее в ваших глазах, когда увидите как будет тормозить постгри. ну а по сути разносить надо конечно. один проц туда, один сюда.

2(32) так ведь не работает мс скл на линуксе, хоть ты тресни.

А разве на Windows установленную в виртуалке не нужно лицензии?

(0) Из личного опыта, MSSQL правда. Основной момент для базы данных при работе с 1с - темп дб. 1с его использует очень активно. Так что грамотно разделяй рейд. Основной момент для связки сервер бд-сервер приложений - больше памяти серверу приложений. Сервак бд как-нить справится(все-таки грамотно написан), а вот сервер приложений при нехватке ресурсов может начать выдавать всякие интересности.

(35)[Сервак бд как-нить справится]
редкостное заблуждение

да в вообще в (35) бред написан никак не коррелирует с действительностью

вдребезги

(36) Долгие дни в профайлере убеждают:)Правильно разнеси логи и файлы данных, разнеси темп дб, ограничь аппетиты сервака бд, правильно разнеси процессоры, поиграй с параллелизмом составления планов запроса, следи за индексами - все будет в порядке. Насчет темп дб - у нас стоят три системы, работающие с MSSQL - 1c юзает её активней всех.  
(37) У всех разная действительность.