вопрос про выбор толстого сервера SQL для 8.0

[vovanrulez]

итак. сейчас база весит 36гб. скорость роста - до 50гб в год. 100юзеров.  скоро будет 120. сервер приложений живет отдельно. база живет на двухголовом ксеоне с 4гб оперативки. одноканальный аппаратный scsi raid1. 2 стопки по 2 винта 72gb. памяти больше не влазит и веники некуда больше втыкать железяки хватило на 1.5 года

выживает все только при перманентной реиндексации, дефрагментации, обновлении статистики индексов самых зверских таблиц. вообще выключено распараллеливание запросов. когда бухгалтерия наваливается на систему, то анализ счета за 5 минут - это не долго
средняя очередь к венику в такие моменты - 100-200.
короче уже месяца 3 система живет на честном слове. а клиент хочет не обрезать базу лет за пять

сеть не при чем. трафик на гигабитных портах до2-3мб/сек.

Ы! когда пытался поднять сервер - читал какие запросы 1с делает к скл. если кратко - обнять и плакатЪ

кроме скл на сервере никто не живет.

для скл планируется купить 4-х головый сервак на двухядерных оптеронах. бюджет - 20-40k$. лучше ближе к 20

вопросы:
0. может для субд нахрен надо 4 проца и лучше взять двухголовый с кучей памяти?
1. есть ли 64 битная версия мс скл?
2. что лучше брать: один четырехканальный рейд контроллер или 2 двухканальных?
3. по факту сейчас читается раз в 5 больше чем пишется (4мб/сек записи против 26мб/с по чтению). поэтому 4 стопки рейд 5 по 4 винта будет в самый раз?
4. я правильно понимаю, что такую железяку надо брать брендовую в рэк исполнении?
5. я правильно понимаю, что лучше каждую стопку винтов в рэйд5 вешать на отдельный канал?
6. винда нормально будет работать с 32гб памяти? или это изврат и больше 16 лучше не целиться?
7. может все таки двухядерные ксеоны? или итаниумы при условии существовании 64 битного скл?
8. я правильно понимаю, что надо целиться на 64 битную версию винды? тока уверенности в ее стабильности как-то маловато...
9. кластер серверов скл для повышения производительности и v8 вещи несовместимые?
10. пока что не видно необходимости поднимать взрослую внешнюю дисковую системы. или я не туда смотрю?

типа заранее спасибо за любые мысли по теме и все такое.

[gs]

0. В принципе вполне может подойти двухголовый двуядерник. Но с такими перспективами роста лучше всего четыре двуядерника. Например Newisys4300 и 4хOpteron875. Памяти гигов 8 минимум, лучше 16.
1. Есть, но пока сыровато. Вполне хватит Win2003EE с включенным PAE и AWE.
2. Лучше - внешнюю файберную дисковую. Но в бюджет навряд ли влезет. Посчитаем. Четырехканальный контроллер собственно тут не нужен - вопрос числа винтов по большому счету, а не каналов. Наша основная боевая машина - LSI MegaRAID320-2X.
3. Я бы предложил винтов штук 30, но посмотрим бюджет. Да и на PCI контроллере столько винтов уже не рекомендуется.
4. Не обязательно брэндовую. Поверьте, мы хорошо сервера делаем. Рэковую - конечно. Иначе потребное число винтов не влезет.
5. Неважно.
6. Нормально, но не стоит так упирать на память - 16ГБ будет вполне достаточно.
7. Двуядерных ксеонов пока нет. Есть оптероны - проверено, мин нет. Итаник - Вам геммороя мало?
8. Опять же, в принципе софт есть, но искать геморрой на такого калибра системе не стоит. После выхода первого сервис пака к 64 - вполне можно будет перелезть
9. Нет. MS кластер вообще не дает повышения производительности - только надежность. А решения типа Oracle RAC имхо 1С не поддерживает. Да и цена будет далека от бюджети.
10. Вопорос поднимать стоит. Внешняя дисковая: 1. легко масштабируется (а рост базы у Вас зверский), 2. поддерживает много винтов (а это важно), 3. надежнее на порядок.

[gs]

Послал на мыло варианты:
1. Минимальный 2хOpteron275/8GB/LSI320-2X + BBU/14 HDD 15k/SC933S2-R760.
2. Посильнее Newisys4300, 4xOpteron875/16GB + SCSI JBOD (SC933S2-R760) с 14 винтами.
3. Два вышеуказанных сервера, но с внешней дисковой Infortrend с 16 или 32 винтами. Хотел бы Hitachi или IBM, но бюджет.

[vovanrulez]

2. Лучше - внешнюю файберную дисковую. Но в бюджет навряд ли влезет. Посчитаем. Четырехканальный контроллер собственно тут не нужен - вопрос числа винтов по большому счету, а не каналов. Наша основная боевая машина - LSI MegaRAID320-2X.

я почему-то всегда думал, что при одновременном чтении с 8 винтов большАя вероятность упереться в ширину канала u320 (2 стопки рейд 5 из 4 винтов каждая). но на практике пока не удавалось померять такие системы

3. Я бы предложил винтов штук 30, но посмотрим бюджет. Да и на PCI контроллере столько винтов уже не рекомендуется.

если делать штук 30, то можно сложить стопок 6 из 5х72гб. но не хочется упереться в контроллер при такой ораве. может все таки лучше 4 канала?

да и 2 контроллера все-таки спокойней: один загнулся - перекинули винты на второй - подняли базу - работаем пока везут контроллер. а так контроллер загнулся - и ФСЕ. тушим свет и готовим цистерну вазелина.

однозначный выбор 2х2 мешают сделать слухи о возможных глюках при таком зоопарке. правда, не совсем понятно откуда глюки могут возникнуть.

6. Нормально, но не стоит так упирать на память - 16ГБ будет вполне достаточно.

квартал прожили с 2 гб. потом воткнули еще 2. прожили полгода и -ЖОПА. теперь подперли всем чем тока можно и система кое как живет. не хотелось бы опять упереться в количество памяти. имхо - лучше купить сразу зведомо больше чем надо, чем потом кусать локти "почему покупали 1гб палочки а не 2гб и почему в мамку влазит всего 24гб????"

понятно, что скл 32bit всю эту кучу памяти будет юзать чисто под буферы.

10. Вопорос поднимать стоит. Внешняя дисковая: 1. легко масштабируется (а рост базы у Вас зверский), 2. поддерживает много винтов (а это важно), 3. надежнее на порядок.

ок. учтем следующее: failover кластер скл поднимать все равно смысла нет, т.к. кластер серверов приложений 1c v8 не поднимешь. масштабирование 4 канального рейда упрется в шину системной платы. с внешней дисковой все упрется опять же в ту же шину, через которую будет fiber канал подключен. кластер то мы не поднимем!

[gs]

В шину Вы очень вряд ли упретесь. Диски под такой нагрузкой тормозят очень сильно.

Лучше посмотрите на FC дисковую. В бюджет она пролезает. Потом сможете еще подкинуть ящик дисков - по мере роста базы. Со скази вариантом это будет труднее, если вообще возможно.

С двумя PCI контроллерами номер может не выйти - адресация скази шины, кабели и т.п. А вот внешняя дисковая - уже с двумя контроллерами. И ничего перетыкать не надо - сами разберутся, даже не заметите ничего.


По памяти смотрите сами, но по моему скромному мнению больше 16ГБ просто смысла нет. Если упретесь, то скорее всего в процы и дисковую.

В шину ничего не упрется - самое большее, что я видел - 60МБ/с линейного чтения при чисто OLAP задаче на четырехпроцессорном оптероне. При OLTP нагрузке главный тормоз - винты.

Насчет кластера помозговать надо. При наличии внешней дисковой ничто не мешает воткнуть второй сервер попроще и назначить его пассивной нодой кластера базы данных. Или в его качестве использовать сервер приложений. А вот насчет кластеризации сервера приложений подумаем, почему бы нет собственно?

[gs]

Да, и еще. На мой взляд не стоит так упирать на мощь сервера СУБД. Скорее всего упретесь в сервер приложений. Так может быть лучше взять два длуядерных двухпроцессорника и внешнюю дисковую и сделать кластер? На одной ноде будет СУБД, на второй одинэска. И в бюджет впишетесь.

[vovanrulez]

В шину Вы очень вряд ли упретесь. Диски под такой нагрузкой тормозят очень сильно.

ок. убедили что хватит 2 каналов если без FC дисковой

Лучше посмотрите на FC дисковую. В бюджет она пролезает. Потом сможете еще подкинуть ящик дисков - по мере роста базы. Со скази вариантом это будет труднее, если вообще возможно.

ситуация такова, что надо сразу сложить тачку, которую не придется потом запланированное время модернизировать. мишн импоссибл

По памяти смотрите сами, но по моему скромному мнению больше 16ГБ просто смысла нет. Если упретесь, то скорее всего в процы и дисковую.

щас мы уперты в 4гб оперативки после года работы. в результате - захлебываются винты. поэтому есть основания предположить, что реально упереться в 16гб за 5 лет.

Насчет кластера помозговать надо. При наличии внешней дисковой ничто не мешает воткнуть второй сервер попроще и назначить его пассивной нодой кластера базы данных.Или в его качестве использовать сервер приложений. А вот насчет кластеризации сервера приложений подумаем, почему бы нет собственно?

1с официально заявила, что сервер 1с v8 не умеет работать в кластере. только взвести серверы на двух тачках и в случае смерти сервера приложений переткнуть хасп в другую тачку, прописать на нем базу, оббежать 120 юзеров и поправить у них имя сервера 1с. жуть.


в общем с FC дисковой действительно можно сделать более живучую систему. при условии что сама FC дисковая не умрет

и если честно, то я загну все пальцы, чтобы оказаться в отпуске в тот момент, когда (тьфу-тьфу три раза) умрет главная 4 головая нода и на 2 головый сервак с 4 гигами упадет радость ворочать такой кучищей инфы. тетки сожрутЪ с потрохами заживо.


теперь конкретика. базовый вариант - №2.
вопросы:
1. ddr400 на такой мамке - бешеная экзотика? и 4 процевых мамок с 24/32 слотами памяти нет в природе? не пинайте плиз. я реально не в курсе.
2. вместо 16х1гб интереснее видеть 8х2гб. чтобы был маневр на будущее
3. 14 винтов - не в дугу. надо - 16. чтобы сложить 4 кучки по 4 винта.
4. 15к - вкуснятина. но на 36гб винтах может не получиться уместить такую базу. 5лет*50гб*1.5 = 375гб. потому что одна стопка стопудоф идет под журнал транзакций. и остается только три стопки общей массой 324гб. хотя за 5 лет или ишак сдохнет или султан. а 15к 72гб ценник увеличат прилично.

в общем с учетом этих пожеланий - цены в студию/мыло.
спасибо!

[vovanrulez]

Да, и еще. На мой взляд не стоит так упирать на мощь сервера СУБД. Скорее всего упретесь в сервер приложений. Так может быть лучше взять два длуядерных двухпроцессорника и внешнюю дисковую и сделать кластер? На одной ноде будет СУБД, на второй одинэска. И в бюджет впишетесь.

сейчас сервер приложений почти всегда - спит. максимум что я видел - 30%cpu. а так - 5-10%. причем виндовище там 2000. поэтому HT выключен. такая нагрузка потому что на его стороне мы код не выполняем. потому что мы бы максимум чего добились - разгрузили клиентов. а это не актуально. у заказчика толстые клиенты и весь код колбасится на их стороне. скл от этого - ни тепло ни холодно.

если вдруг появится еще человек 100-200 юзерофЪ, то вот тогда он будет напрягаться. а скл тогда просто жопа настанет но скорее марсиане прилетят и построят на земле коммунизм.

[vovanrulez]

hot spare при таком количестве дисков кажется очень необходимым. как думаете?

[a_shats]

Сервер приложений 1С8 - да, не работает на кластере. А вот MSSQL с кластером работает прекрасно Равно как и файловая шара в случае dbf базы.
Потому - давайте все ж рассмотрим и такой вариант.
Что касается нагрузки на сервер приложений - она практически на 100% зависит от того, как написана конфигурация. А по традиции конфиги пишутся с упором в клиента

[vovanrulez]

А вот MSSQL с кластером работает прекрасно

я не отметаю вариант с failover кластером. но без взрослой дисковой копилки лучше уж настраивать tr.log shipping. но нету даже щас сервера, который нормально вытянет такую нагрузку. поэтому сначала надо определиться стоит ли разоряться на дисковую копилку.

НО если честно, то меня терзают смутные сомнения, что не стоит внешнюю копилку брать по следующим причинам:
1. по месту. даже с прицелом на 5 лет почти хватает 16 винтов по 36гб. т.е. хватит двух каналов и контроллера на мамке. при этом можно еще засунуть 8 винтов. кроме того, можно часть винтоф поменять потом на 140гб.
2. failover кластер. допустим поднимаем кластер скл. при этом у нас нет кластера копилок. имхо с равной вероятностью загнется что правильный сервак, что копилка. поправьте если я не прав: кластер скл стоит поднимать тока если есть хотя бы двойное резервирование копилок. потерь данных у нас не будет в любом случае благодаря бэкапам, а простой по любому будет. значит по этому критерию копилку внешнюю тоже - фтопку.
3. резервные ноды скл. сейчас в скл наблюдается большая загрузка процессоров + не хватает памяти. в результате - все упирается в веники. а база - растет. понятно, что в случае Ч выбора не останется и придется всю базу сложить или на сервер приложений, или на старый скл, но взрослая внешняя копилка даст только сокращение простоя на несколько часов. а несколько часов простоя не стоят таких денех.
4. режим работы системы всего лишь 12/6. поэтому каждый день имеется минимум 12 часов для офлайн обслуживания системы.
5. скорость. поправьте мои выкладки, если я не прав. 2гбита/сек это 250мбайт/сек. а два канала u320 - 640мбайт/сек. получается надо как минимум 3 FC канала на один сервер, чтобы шина не стала узким местом.

в общем хотелось бы узнать цены следующих вариантов:
1. основной. 4 двухядерных проца, 8х2гб dimm, свободных слотов памяти не менее 8, LSI Logic MegaRAID SCSI 320-4X, корзины для scsi с не менее 6-ю гнездами на канал.

2. альтернативный. 4 двухядерных проца, 8х2гб dimm, свободных слотов памяти не менее 8, самый простой SATA raid5. + внешняя FC копилка с корзиной на 16 винтов и возможностью повесить еще одну на 16, 3 FC канала (чтобы подключить к копилке новый скл сервер, старый скл сервер и сервер приложений).

желательно по каждому варианту вариации на тему веников:
- 36гб 15к
- 72гб 15к
- 72гб 10к

[gs]

1. С большой базой вопрос не в размере винтов, а в их количестве. А с количеством в скази джибод варианте будет швах.
2. Сервер может вылететь не только по железу, но и по софту. Дисковая же с дублированными контроллерами - вещь исключительно надежная. В ней если что и ломается, она начинает визжать, матюгаться в логи, но ПРОДОЛЖАЕТ РАБОТАТЬ! Я помню только один случай, когда реально накрылся такого типа аппарат - когда в здание попала молния.
3. Нагрузка на винты была, есть и будет только увеличиваться. Обьем памяти помогает только до каких-то пределов, особенно в 1С. В скази варианте вы упираетесь, в файберном же можно будет потом еще ящик пристегнуть.
4. Зачем париться с геморроями по ночам, если можно этого не делать?
5. Не парьтесь по поводу шин. Если хотите теории, то она такая. Один 15к винт способен выдать макс 500иопс. При среднем размере блока (как показывает практика) в 4-8кБ максимум, что могут выдать 16 дисков - 64МБ/с. И это при чудовищной нагрузке!!!

[gs]

Проверьте мыло.

[gs]

И еще. Я конечно посчитал варианты с кучей скази дисков, но сильно сомневаюсь в долгой и счастливой жизни такого извращения...
Поверьте, Вы не первый с такими задачами. Предлагаемый мной вариант на файбере - самое толковое решение задачи. Никто из клиентов еще не пожалел, пересев на внешнюю дисковую.

[vovanrulez]

ну можно считать что убедили с внешней дисковой системой

спасибо большое за ценную дискуссию!

почту посмотрел. начальство заказчика в процессе принятия решения.