Сколько сетевых издержек (и проблем с блокировкой файлов) можно ожидать для 25-50 пользователей в ERP DB Visual FoxPro 9 через SMB/CIFS?
Альтернативное название вопроса: Как я могу перевести "Это программное обеспечение дает мне мерзость" в бизнес-кейс для высшего руководства, чтобы не покупать его?
Я являюсь ИТ-отделом небольшой компании, которая несколько лет непрерывно росла. Мы начали с QuickBooks, перешли на другую учетную систему и теперь на рынке для ERP-систем среднего рынка, которые немного более всеобъемлющие и настраиваемые. В настоящее время мы оцениваем ERP-систему, написанную на Visual FoxPro 9, и у меня плохое предчувствие, но я не могу точно определить, почему это так.
Он состоит из нескольких модулей, модуль бэк-офиса и веб-модуль, которые нас интересуют. Модуль бэк-офиса содержит обычные функции заказа / выполнения / доставки / учета ERP. Веб-модуль управляется той же базой данных FoxPro через указание IIS на компонент.NET, открывающий базу данных с другого компьютера по пути UNC. Я тоже об этом не знаю, но пока это отдельная тема.
Я обеспокоен тем, что система "установлена", выполнив следующие действия:
1. Create a top-level folder on a server.
2. share that folder with appropriate users and groups as \\server\erp
3. unzip the .exe and dlls and \data folder in the shared folder
4. map \\server\erp to a drive on client computers
5. create a shortcut to the \\server\data\erp.exe on client desktops.
6. double click on shortcut! You’re ERPing! (after some other minimal setup)
.Exe использует доступ к файлам в подкаталоге \\server\data для заполнения форм и т. Д., Как обычно.
Я обеспокоен тем, что одновременные пользователи (25 или более), имеющие доступ к одному.exe, который обращается к файлам через сетевую файловую систему (cifs) для выполнения функций базы данных, кажутся... подозрительными. Любая другая система, которую я видел, использует отдельный механизм базы данных, либо доморощенный (что достаточно плохо), либо что-то вроде SQL Server, Oracle, даже PostGreSQL или heck, даже MySQL для обработки доступа к данным, но этот просто один файл.exe в общей папке, запускаемый непосредственно из этой общей папки на рабочем столе каждого клиента. Кажется, что это неэффективно или, по крайней мере, не элегантно, и что это вызовет много избыточного сетевого трафика..Exe имеет размер около 10 МБ и находится на сервере, открывает файлы.dbf, находящиеся в соседнем каталоге \ data. Продавец спрашивал, есть ли у нас гигабитная сеть (у нас), и это казалось ему очень важным... теперь я понимаю, почему он спрашивал.
У меня нет глубоких знаний в области разработки, но мне кажется, что у вас должна быть отдельная база данных, которая взаимодействует с клиентами через именованный канал или сокет TCP/IP, или, по крайней мере, какой-то двоичный сетевой протокол, если ничего больше. Использование совместного использования netBIOS (вы вводите пути UNC в базу данных в качестве свойств) просто кажется неправильным, потому что вы не столкнетесь с проблемами блокировки файлов, если, например, два пользователя захотят открыть одного и того же клиента в A/R? Я просто слишком осторожен? Это действительно стандартная практика, как говорит продавец? У меня нет большого опыта в таких крупных системах учета, как эта. В нашем текущем пакете используется модель клиент-сервер с обработчиком файлов БД, и затем пользователи, запускающие программное обеспечение на своих компьютерах, общаются с ним по сети. Я ошибаюсь, если думаю, что что-то более продвинутое будет иметь подобный интерфейс?
3 ответа
То, что вы описали, безусловно, даст мне повод для беспокойства по нескольким причинам:
Тот факт, что представитель настаивал на гигабитных сетях для такого маленького приложения. Может оказаться, что это не окажет никакого практического влияния на вашу сеть, но это заставит меня серьезно задуматься о дизайне приложения. Система ERP на 50 пользователей не должна беспокоить линию 10 Мбит, не говоря уже о гигабитной.
Для меня последствия для безопасности процесса установки могут помешать работе. Это система, которая хранит информацию о клиентах (и, вероятно, о клиентских платежах). Пользователи будут запускать exe-файл из кратчайшего пути, а это значит, что на его рабочих станциях будет запущено 25-50 экземпляров этого exe-файла, работающих под учетными данными пользователя. Эти процессы имеют прямой доступ к файлам общей базы данных и записывают их в один и тот же общий ресурс. Это означает, что каждый пользователь должен иметь прямой доступ на чтение / запись ко всей базе данных. Это ужасно с технической точки зрения и с точки зрения соответствия требованиям безопасности.
Лично я бы пробежал милю из этого приложения в одиночку. Я уверен, что люди с большим опытом в области соответствия (или с FoxPro) могут комментировать дальше.
Был там, сделал это.
Я признаю, что VFP9 выглядит немного устаревшим, но это проверенная технология.
Хотите верьте, хотите нет: VFP9 очень надежен в такой конфигурации. Это совсем не похоже на msaccess. Сначала у меня тоже были сомнения по этому поводу, но на практике проблем вообще не было.
Дополнительный бонус: Вы можете даже делать простые резервные копии файлов базы данных, если у пользователя нет открытого приложения, что хорошо, если у вас нет круглосуточного магазина.
Но вам нужна быстрая (не менее 100 Мб) локальная сеть между клиентами и серверами. (И ради бога, поместите сетевую карту 1G на сервер.) Локальный EXE-файл или на сервере не имеет большого значения, либо он будет работать нормально.
Как уже говорили другие: для не локальных пользователей вам нужна настройка WTS. Рекомендуется делать это на отдельной машине, а не на самом сервере VFP9. (Конечно, с Hyper-V или VMWare обе машины могут быть виртуальными машинами на одном физическом боксе.)
Обратите внимание, что пользователям WTS может потребоваться достаточное количество оперативной памяти на пользователя. Это немного зависит от эффективности запросов к БД и потребностей приложения.
Из того, что я видел, рабочие наборы от 100 до 200 МБ вполне нормальны для приложений vfp9, из которых около половины будут закреплены в физической памяти. По моему опыту, от 20 до 30 пользователей на сервере WTS с 4 ГБ ОЗУ выполнимо, если им больше не нужно работать в сеансе WTS. В зависимости от ваших потребностей ваш пробег может варьироваться.
У меня большой опыт работы с пакетом ERP для Visual FoxPro 9, который работает более или менее одинаково - общий доступ к файлам на сервере, несколько клиентов с локальными EXE-файлами и файлы поддержки для доступа к общему ресурсу SMB. Набор данных для каждой компании в ERP - это сотни файлов DBF.
С точки зрения производительности мы не видим никаких проблем - у нас много клиентов, использующих 30 или более клиентов на довольно стандартном сервере Windows, которые обращаются к файлам DBF, которые могут иметь миллионы строк и более 1 ГБ. Если индексирование и блокировка правильно осуществлены ERP, тогда все эти цифры в порядке.
Да, существуют проблемы с безопасностью, когда общий файловый ресурс содержит файлы DBF. Я предполагаю, что это зависит от типа клиента, которому наша ERP продает, но через 15 лет и с тысячами сайтов число, которое я лично знаю, мы потеряли из-за этой установки, может составить около 20 или около того. Также возможно обойти эту проблему, используя Terminal Services.
Вы абсолютно правы также и в том, что для удаленного запуска вам потребуется использовать службы терминалов, возможно, через VPN.
Кроме того, если вы в конечном итоге используете рассматриваемую ERP и у вас есть машины с Windows 7 и Server 2008, убедитесь, что они установлены на SP1, поскольку в SMB была ошибка, которая приводила к повреждению файлов индекса.