Страница 8 из 10
Масштабируемость технологической платформы целесообразно применять при рассмотрении современных ERP-систем, имеющих трех-или многоуровневую архитектуру. Число пользователей, которые могут одновременно работать в ERP-системе, безусловно, зависит от программно-аппаратной платформы: конфигурации серверов, общей конфигурации сети, используемых ОС и СУБД, средств промежуточного слоя и т. д. Внутренними факторами, определяющими максимальное число одновременно работающих пользователей, будут размеры базы данных и особенности бизнес-процессов предприятия.
Рассмотрим классификацию ERP-систем через свойства технологической архитектуры [19].
Рис. 1.5. Технологическая архитектура легкой ERP-системы
Легкая ERP-система способна использовать только один сервер баз данных и только один сервер приложений. Технологическая архитектура такой системы представлена на рис. 1.5. Все запросы пользователей, поступающие с рабочих станций, обрабатываются сервером приложений, который взаимодействует с сервером баз данных.
Из ERP-систем этого класса на российском рынке наиболее известны «Управление производственным предприятием» на платформе «1С: Предприятие 8.0» и Microsoft Dynamics NAV.
ERP-система такой архитектуры в реальных условиях эксплуатации способна поддерживать одновременную работу до 100 пользователей. По мере приближения к этому пределу увеличение числа процессоров в серверах и их мощности не обеспечивает соответствующего прироста числа пользователей. Возникает эффект насыщения: каждое последующее увеличение числа пользователей требует намного большего прироста ресурсов.
Организация и использование комплекса запускаемых параллельно легких ERP-систем, каждая из которых работает со своей группой пользователей, возможны, если предприятие состоит из нескольких юридических лиц или территориально удаленных подразделений (рис. 1.6). Однако использование комплекса ERP-систем целесообразно только тогда, когда выполняются следующие условия:
• не требуется доступ к актуальным данным всех объектов в режиме online;
• все периферийные подразделения занимаются однотипной деятельностью и используют единые стандарты учета для информации, передаваемой в центральный офис;
• на периферийных объектах используется не вся функциональность ERP-системы, а только отдельные функциональные модули (не должно возникать ситуации, когда каждая система работает независимо и теряется возможность управления предприятием как единой целостной системой).
Средняя ERP-система использует только один сервер баз данных и произвольное число серверов приложений. Известный пример такой системы – Microsoft Dynamics AX. Два варианта технологической архитектуры систем управления, построенных на основе средней ERP-системы с использованием трех серверов приложений, представлены на рис. 1.7, 1.8.
Рис. 1.6. Технологическая архитектура комплекса из трех легких ERP-систем
Рис. 1.7. Архитектура системы управления на основе средней ERP-системы с централизованной библиотекой приложений
Рис. 1.8. Архитектура системы управления на основе средней ERP-системы, где каждый сервер приложений работает с собственной библиотекой приложений
Вариант архитектуры средней системы (рис. 1.7) реализован в Microsoft Dynamics AX. В обоих вариантах с одним сервером базы данных работают несколько серверов приложений, а различие между ними состоит в организации библиотеки приложений, содержащей актуальные версии всех приложений ERP-системы. В системе с централизованной библиотекой приложений эта библиотека выделена из состава серверов приложений, и все серверы используют единую библиотеку. Во втором случае каждый сервер приложений использует собственную библиотеку приложений. Такая архитектура предполагает наличие в системе развитых средств обмена настройками и программными объектами между библиотеками приложений. Первый вариант требует меньших затрат при эксплуатации, однако второй обеспечивает большую масштабируемость системы.
Возможность одновременного подключения нескольких серверов приложений существенно усложняет технологическую платформу средней ERP-системы. Одна из основных проблем состоит в том, что серверы приложений кэшируют объекты базы данных. В случае изменения каких-то данных в кэше одного из серверов необходимо сразу исключить измененные объекты из кэш-памяти других серверов.
Усложнение технологической платформы средних систем по сравнению с легкими сопровождается и более развитой функциональностью. Это обусловлено тем, что бизнес-процессы средней корпорации сложнее и соответственно требуют развитой бизнес-логики системы и поддержки большего числа одновременно работающих пользователей.
При росте количества рабочих мест можно организовать и использовать комплексы на основе средней ERP-системы (рис. 1.9). Но следует учитывать, что увеличение числа одновременно работающих пользователей за счет наращивания ресурсов имеет свой предел, обусловленный лежащими в основе системы архитектурными решениями. При его достижении дальнейшее увеличение числа серверов приложений, повышение мощности процессоров, объема памяти, пропускной способности каналов ведут к очень незначительным улучшениям.
Тяжелая ERP-система – система, использующая произвольное число серверов баз данных и обеспечивающая работу произвольного числа серверов приложений с каждым сервером баз данных. Наиболее распространенный пример тяжелой системы – mySAP Business Suite. Два варианта технологической архитектуры тяжелой ERP-системы в составе четырех серверов приложений и четырех серверов баз данных представлены на рис. 1.10, 1.11.
Для работы с несколькими независимыми серверами баз данных тяжелая система должна иметь внутри себя описание структуры баз, расположенных на каждом сервере, чтобы строить запросы к ним, исходя из необходимости обработки конкретных данных. Иными словами, тяжелая система по определению включает в себя как один из компонентов систему управления распределенной базой данных, для работы которой используются серверы СУБД (рис. 1.10, 1.11).
Рис. 1.9. Архитектура комплекса из одной средней ERP-системы с централизованной библиотекой приложений и двух легких
Рис. 1.10. Архитектура тяжелой ERP-системы с выделенной распределенной библиотекой приложений
Рассматриваемые варианты технологической архитектуры различаются способом организации библиотеки приложений. В варианте, представленном на рис. 1.10, для библиотеки выделяются отдельные серверы, каждый из которых может использоваться несколькими серверами приложений, что обеспечивает сокращение затрат на сопровождение системы из большого числа серверов приложений, объединенных в компактные группы.
В варианте, приведенном на рис. 1.11, каждый сервер приложений работает с собственной библиотекой, обеспечиваются независимость серверов приложений и высокая масштабируемость системы. Этот вариант реализован в mySAP Business Suite.
Наличие внутренней встроенной СУБД значительно усложняет ERP-систему, однако обеспечивает ее масштабирование до десятков тысяч одновременно работающих пользователей. Для больших корпораций, состоящих из десятков, а иногда и сотен территориально удаленных предприятий, использование тяжелой системы иногда оказывается единственной возможностью обеспечить эффективное управление. Однако преимущества, получаемые при использовании тяжелой системы, имеют оборотную сторону в виде высоких затрат на ее приобретение, внедрение и сопровождение, а также на оплату трафика, образующегося при работе с территориально удаленными серверами.