Порекомендуйте апгрейд

[Евгений К]

Доброе время суток!
Сейчас используется 1С 8.2 УПП, размер БД под MS SQL 2008 ~ 60 ГБ, количество вводимых документов ~ 2 000 в день, рост БД ~ 28 Гб/год, порядка 70 пользователей одновременно работающих в 1С
Серверное оборудование:
Сервер приложения (1шт)
Xeon E5503 x 2
16 Гб ОЗУ

Сервер SQL (1 шт):
Xeon E5420 x 2
16 Гб ОЗУ
Adaptec RAID 51645
12 x 75 Гб HDD SAS 10k RAID 10
1 x 75 Гб HDD SAS 10k Hot Spare

Резервное копирование осуществляется на NAS 6 Тб средствами MS SQL

Связка работает нормально — проблема с транзакциями возникает только при запуске групповых обработок и т.п. ресурсоёмких операциях.
В ближайшее время планируется внедрение позаказной схемы работы + будет задействовано производство. Объем вводимых документов увеличится раза в 2-3. Количество пользователей в системе до 100 человек.
Порекомендуйте пожалуйста апгрейды для серверов, которые необходимо сделать, чтобы после внедрения и ближайшие пару-тройку лет не возникало проблем с производительностью.

[Stranger03]

Связка работает нормально — проблема с транзакциями возникает только при запуске групповых обработок и т.п. ресурсоёмких операциях.

Пользователи как я понимаю работают по сети? Было бы интересно взглянуть на счетчики на сервере баз данных в момент загруженных операциях.

[Stranger03]

В ближайшее время планируется внедрение позаказной схемы работы + будет задействовано производство. Объем вводимых документов увеличится раза в 2-3. Количество пользователей в системе до 100 человек.

Еще несколько вопросов:
1. Пользователи сетевые или терминалки?
2. Максимальное время простоя в случае сбоя?

[DeadMazay]

не плохо было бы поглядеть на результаты perfmon с обоих серверов
как в текущем режиме, так и в режиме максимальной нагрузки

[Евгений К]

1) Сетевых пользователей 45 и терминальных 15 - примерно такое соотношение.
2) Максимальное время простоя в случае сбоя не более 2 часов

Счетчики производительности на сервере баз данных выставлю для сбора статистики.

[Stranger03]

2) Максимальное время простоя в случае сбоя не более 2 часов

Тут два варианта:
1. делать небольшой кластерок из пары серверов + внешняя СХД. Преимущество - вы можете спокойно ехать в отпуск и не боятся, что вас с пляжа Египта попросят приехать в офис в течении 2-х часов.
2. брать либо хороший ЗИП, либо ЗИП + пару одинаковых серверов. Чтобы если что, можно было в течении нескольких часов возобновить работу на одном из них.

[Евгений К]

А какие характеристики для серверов и внешней СХД? Нужно оценить объем затрат.

[Stranger03]

А какие характеристики для серверов и внешней СХД? Нужно оценить объем затрат.

Характеристики серверов и СХД сильно зависят от ваших счетчиков, которые вы соберете. Как собирать есть на форуме в разделе FAQ. Сейчас можно только ткнуть пальцем в небо, ориентируясь на текущие сервера.
P.S. ребята вам посчитают сегодня. С вас счетчики.

[Asmohata]

Пусть меня запинают хозяева форума, - не удержусь от комментария (уж больно конфигурация на используемую нами похожа).

"Построить небольшой кластерок", - разумеется, наилучшее в плане отказоустойчивости решение. Хотя и не позволяет (на задачах уровня свыше 50 пользователей) обходиться только одним админом (регулярно посещающем Египет). При этом:

- кластер (M$-SQL) не увеличит производительность;
- минимальная "внешняя СХД" для кластера (будет несколько производительней используемого RAID10 12xSAS 10k) обойдется минимум в 12-15 k$...

И не пытаясь спорить с местными профессионалами, осмелюсь предложить такой вариант, обеспечивающий запас именно на 2-4 года для указанного кол-ва пользователей:

- если есть техническая возможность, - доп. RAM в SQL (относительно недорого, а лишней не будет);

- базу (mdf-файлы) положить на RAID10 4xSSD i710 100GB (серверные, обойдутся в сумму порядка 3,5k$) а журнал(ы) транзакций, - на SAS-"остаток" (RAID10 8xSAS 10k). Теоретически, это позволит восстановить базу из бекапа+журнал если вдруг что-то случиться с SSD;

- развернуть еще один "сервер приложения 1С", - в штатном "1С кластере" с первым. В обычных условиях это обеспечит (вместе с апгрейдом SQL) необходимый запас производительности. Конфигурацию этого сервера можно (нужно) подобрать такой, что его можно будет использовать как резервный SQL.

Запасной контроллер (Для резервного SQL) можно будет взять недорогой, - к примеру Adaptec 2405 (RAID10 поддерживает, а без BBU некоторое время можно обойтись) и корпус типа Supermicro 836E16 (RAID10 из 4xSAS 10k оставшихся от апгрейда SQL под систему). В случае аварии основного SQL в него просто переставляются 4+8 дисков.
Кстати, - нужно учесть, что Adaptec 51645 (точнее, - встроенный в него SAS-экспандер) не поддерживает работу с большинством SAS2 бэкплейнов. С SC836E16 -точно не работает.

Кластер, конечно, лучше, но, в 2-3 раза дороже... Ведь вопрос, - сколько последних введенных документов допустимо "в случае чего" ввести заново, - не был озвучен.

[gs]

Резервирование БД можно сделать и средствами SQL (database mirroring, log shipping). Правда тогда нужен второй сервер с адекватной дисковой - т.е. халявы не будет.

[Stranger03]

Пусть меня запинают хозяева форума, - не удержусь от комментария (уж больно конфигурация на используемую нами похожа).

Попробую попинать. Если внимательно почитаете мои сообщения, то топикстартеру было предложено два варианта. Причем без каких-то конкретных спецификаций, кои по идее могут родиться после просмотра счетчиков на текущей конфиуграции. Если про кластерок все вроде понятно, дороже конечно, но при 50+ пользователях затраты могут быть оправданы. То про отдельные сервера я бы не стал делать репликацию базы на второй "дохлый" сервер. ИМХО если делать так, то желательно иметь примерно одинаковые конструкции. И еще момент, из практики. Один наш заказчик в конфигурации с репликацией базы при сбое основного сервера получил неконсистентную базу на резервном сервере. Восстанавливали доступ к данным 3-и дня. Часть данных все равно была потеряна.
P.S. к чему я это говорю. Любой вариант возможен, но не отменяет проверенные бекапы.

[Inna]

Евгений К,

отправила варианты по организации кластера БД (с внешней СХД IBM 3524) и приложений. Также в качестве сервера БД предлагаем рассмотреть вариант сервера с внут. диск. подсистемой на базе контроллера ADAPTEC с технологией MAX IQ (поддерживающей кэш на чтение на SSD диске). Конечно, это единая точка отказа, но с точки зрения производительности вариант тоже неплохой: внутренняя дисковая подсистема при количестве дисков около 12ти шт. может быть сравнима по производительности в внешней СХД с таким же колвом дисков.

Также в почте счетчики, которые стоит посмотреть, чтобы уточнить требования по процессорам и ОЗУ (посчитала самые ходовые в наст. момент варианты).