Значит так. Есть определенная фирма, оказывающая услуги, в которой я тружусь начальником отдела ИТ два года, . Специфика фирмы такова, что корпоративная информационная система должна работать в реальном режиме времени и выдавать информацию 24 часа в сутки 7 дней в неделю.
Количество пользователей в фирмы на данный момент порядка 700, раскиданных по почти 30 филиалам нашей необъятной страны. Есть филиалы со 150 пользователями, есть и всего с десятком.
Количество документов в рабочий день порядка 12-15 тысяч. Специфика бизнеса такова, что 3-4 вида документов дают порядка 70-80% объема. Очень объемный справочник контрагентов (порядка полумиллиона).
Силами отдела ИТ в 2005 году была написана собственная разработка на 8ке, т.к. 7ка к тому времени даже на гораздо меньших объемах стала загибаться. Конфигурация не тяжелая, по крайней мере до УПП ей явно далеко.
С 1 января 2006 г конфигурация была успешно запущена и работает по сей день. Сейчас кол-во документов в базе порядка 4,5 миллионов, размер базы порядка 20 Гиг.
Основной проблемой эксплуатации базы всегда был обмен данными (практически нетронутый встроенный УРБД), т.к. , повторюсь, объем данных велик, а оперативность высока (практически в течение часа-двух нужно чтобы данные введенные в филиале, находящемся в одной ветви УРБД видел филиал из другой ветви). При малейших «затыках» с обменом он начинал идти гораздо медленнее требуемого часа-двух, что нарушало бизнес-процессы компании.
Исходя из этого было принято решение о «стягивании» всех пользователей в 2-3 базы, которые будут располагаться на мощном серверном оборудовании. Фирма понесла значительные затраты на покупку и содержание широкополосных каналов И-нет с каждым своим филиалом. Т.к. стоит отъехать от Москвы или Питера на 100 верст, как стоимость устойчивого(!) канала в 1 Мбит/с растет совершенно не пропорционально здравому смыслу.
В результате мы смогли в одной базу нарастить количество пользователей до 270-280, а в другой до 180-185. Но в дальнейшем (видимо из-за роста объемов транзакций (читай – документов), видимо – так как других причин я не вижу) мы были вынуждены откатиться назад и сейчас в этих базах работает соответственно 180-190 и 150-160 человек, при добавлении большего количества пользователей (а 70% из них «колотят» документы) начинаются бешенные транзакции, а если еще и обмен при это начинается, то …
Все попытки как-то оптимизировать базу (как 1С , так и СКЛ) вобщем-то ни к чему не привели. В базе 1С перенесли проведение всех документов на сервер, отказались от автоматической очистки движений документа при проведении, оптимизировали код, запретили пользователям запускать больше 2х сессий, вынесли «крутые» упр.отчеты в отдельную базу на отдельный сервак, вобщем делали наверное все что вычитали по проблеме в И-нете. Движок 1С 8.0.17. На 8.1 честно говоря переходить пока страшновато.
На СКЛ-базе: индексировали, шринковали, убивали лог, ставили базу в Simple, убивали tempdb, переносили лог на отдельный диск, убивали саму базу и выгружали из мастера заново . Никаких радикальных облегчений это не дало.
О железе:
Речь поведу о самой мощной нашей площадке, где «сидят» на данный момент 180-190 пользователей, а было время «сидело» и 280.
- СКЛ-сервер НР Proliant 385 (4 процессора AMD Opteron 2000, 8 Гиг памяти), дисковая коробка HP StorageWorks MSA1000 Smart Array SAN в массиве Raid 0. ОС Windows 2003 (64-bit), SQL 2005. Установка Windows Server 2000 и SQL 2000 дало тока еще большие тормоза.
Дальше на всех серверах стоит по 2 процессора AMD Opteron 2000, 4 гига памяти, ОС Windows Server 2003
- сервер приложений HP Proliant 145;
- восемь терминальных серверов (Citrix MetaFrame Presentation Server 4.0 Enterprise Edition), все пользователи работают только через терминалки;
- сервер, где крутятся обмены HP Proliant 145
Между серваками, ессно, 1Гбит/с.
Словом, стоимость оборудования порядка 100 тысяч долларов Snus1 - 23.04.2007 - 11:02 Тесты показывают, что затыкается в основном дисковая подсистема (не только на этом филиале, в любом другом на любом другом железе тоже).
К чему я все это написал. В планах фирмы рост количества пользователей в течение года до 1000-1200 человек. Мое начальство справедливо (как мне кажется) считает, что 100 тысяч долларов на серверное оборудование на 200 пользователей – это сильно круто.
Исходя из этого совершенно непонятно что делать дальше: при дальнейшем росте кол-ва филиалов и информации обмен просто не будет успевать за потребностями бизнеса. Больше 200 пользователей в одну базу тоже не получается «посадить».
Получается, что мы, сборище далеко не глупых (как я надеюсь) людей, не первый год работающих в ИТ сфере, находимся в некоторой растерянности: оставаться на 1С ? Трогаться на другую платформу ? Какую ?
Где выход ? Еще дальше наращивать железо ? Начальство говорит – все, хватит, денег не дадим.
Писать свой обмен ? С полгода работы пары программистов убью на это. А гарантия что будет быстрее ? Нету. Да и очень удобно, когда все пользователи, что называется «под рукой», а не серверный зоопарк по всей России.
Писать «тонкого» клиента на веб-интерфейсе с занесением данных прямо в СКЛ-базу (тогда на фиг мне 1С ? )? С год работы одного программиста убьем, а гарантия есть что будет быстрее ? Кто-то делал что-то подобное ? Т.е. часть пользователей под 1С, а часть на каком-либо другом интерфейсе с доступом к этой же базе.
Или может мы что-то неправильно делаем ? Может глаз замылился ? Может есть какой-то мега-секрет, какая-то волшебная «птичка», которую мы пропустили ?
Или на самом деле $500 на юзера в серверном оборудовании – это нормально? Может мы многого хотим ?
Особенно меня интересуют ответы людей, имеющий РЕАЛЬНЫЙ (не мифологический, не уровня «от одной бабки слышал», я тоже много чего слышал), именно реальный опыт внедрения, а (самое главное !) длительной (больше года !) эксплуатации каких-либо решений на 8ке на количестве пользователей в одной базе от 200 (минимум 50% активных !) с территориально распределенной структурой при бешеном документообороте, т.е. пользователь должен вводить в день не 1-2 документа, а сотню хотя бы.