Я бы заложил внешний файберный сундук под базы и все сервера одной платформы скорее всего с 4 сокетными матерями. Когда проект дозреет, скорее всего железячники тоже выкатят что-нидь вкусное, там все одно придется смету перетряхивать и метнуться например на дуальную платформу, только процы кол-вом ядер поболе втиснуть, может к тому времени ssd дорастут по цена/производительность/надежность до удобоваримых величин и внешний сторадж может и не потребуется.

А так лучше всего написать эмулятор и на площадке у интегратора погонять на реальном железе, думаю если договориться и пообещать купить приглянувшийся конфиг, вполне можно решить более точно, а не "плюс-минус лапоть".

DestroyIvan_PisarevskyЯ бы заложил внешний файберный сундук под базы... может к тому времени ssd дорастут по цена/производительность/надежность до удобоваримых величин и внешний сторадж может и не потребуется.

При таких объемах (10Гб в год) это из пушки по воробьям, куда дешевле съесть это кэшем из оперативки. Да и в сервак сейчас можно втиснуть с десятка полтора SAS дисков (в IBM x3650 M3, например).Во вводных фигурирует фаиловер кластер для серверов БД, как бы со внешним стораджем это проще и правильней. Я так понял проблема не "потянет-не потянет", а "как бы правильно сверстать смету, чтоб потом локти не кусать". Да, производительность нынешних вставных рэйд контроллеров впечатляет, да можно напихать дохрена дисков в корзину (полтора десятка САС шпинделей в 2 юнита запросто), да 10 гиг в год оно потянет... но если по какой-то причине ложится сервер и надо переключаться на стэндбай, когда есть внешняя дисковая полка, в которой конструктивно отсутствуют единые точки отказа, оно таки спокойней.
А если проектные 10 гиг в код окажутся профанацией и реальный рост составит 100? добил диски в полку прямо на горячую и поехали, смигрировать с внутреннего массива несколько хлопотней и затратней (а место в корзине имеет нехорошую привычку заканчиваться в самый неподходящий момент).

TREYНужно грамотно продумать структуру базы, чтобы архивные данные не тянулись в таких объемах. В моем случае архивными будут считаться те, которым более 2 месяцев. К более старым, если не будет проблем, может доступ вообще никогда не понадобится.. а может и понадобится. Но сохранять их нужно 100 %. Не знаю как сделать лучше. Архивную базу бить на куски по месяцах, или делать 1-ну большую архивную?.., а в поточной держать инфу за 2 месяца... Куски в крайняк можно потом перекинуть куда то не разбивая целой базы..Я бы делал 2 БД, оперативную и архивную подпитываемую репликатором.
TREYКак лучше сделать, как считаете?Коллега, вы всерьез полагаете, что видя три строчки вводной информации в форуме можно дать однозначный ответ? :)
Пока что был простой совет, заложить железо так, чтоб потянуло гарантировано и даже при внедрении где-то ужаться (начальство это любит), а вот расширять бюджет по ходу очень муторно (начальство это не любит). :)