Строим МНОГОтерминальную систему

Прошу рассказать о нескольких разных методах построения много-терминальных систем.

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

Решение, уже имеющееся на сегодня, меня не слишком радует:

Используется MS SQL Server под W2K, на весьма шустрой тачке.
Клиенты ходят на сервер по VPN (виртуальная частная сеть) через интернет
(выделенный канал 2МБит). На клиентских машинах используется программа-клиент, написанная на Дельфи.
Недостатки существующего решения:
- Имеющийся SQL-сервер очень чувствительно тормозит
- Нерационально написанный клиент забивает канал трафиком так, что 2МБит уже не хватает...
- Слишком дорого каждому клиенту ставить целый компьютер

 Было уже предложено тупое решение - расширить канал до 20МБит,
но мне кажется, что это не улучшит ситуацию, поскольку количество клиентов вскоре должно возрасти до 500-600...

 Какие будут предложения?

1. Поставить какой-нибудь из UNIX-ов как головной сервер.
2. Поставить нормальный сервер БД -- Oracle вполне то, т.к. позволяет реализовать как терминального клиента, так и GUI-шного. Это на головном сервере.
3. На удаленной площадке ставим для клиентов, написанных под терминальный режим какой-нибудь стервачок, обеспечивающий загрузку на бездисковые рабочие станции ОС+ПО. Клиенты -- diskless workstations.
4. Этот же стервачок является единой точкой доступа через VPN в "головную" сеть, на него собираются все клиенты на удаленной площадке.
5. При увеличении числа клиентов ставим на удаленной площадке более серьезный сервер, несущий уже БД и по каналу 2 MB/sec. "гоняем" только "дельту" от двух БД. Это заведомо меньше (при такой постановке задачи, как она есть), нежели гонять все записи по отдельности -- как сейчас.

Минусы такого подхода -- отказ от Delphi и перенос ПО на более прагматическую основу. Это нужно будет все переписать. Возрастают требования к администратору (нужны прямые /dev/hands и /dev/head != /dev/ass) всего этого хозяйства. При написании кода нужно будет учитывать то, что основная обработка должна происходить на сервере БД и только! Т.е. никаких кэширований на стороне клиента быть не может! И никаких шибко сложных обработок. Все -- либо через код ПО на клиенте, либо -- через хранимые процедуры!

Плюсы -- вполне возможно использовать бесплатное программье (ОС и сервер БД), администрирование сильно упрощается -- самая поганая часть клиентская, а здесь все клиенты однотипны и, более того, грузятся однотипной ос с однотипным ПО из одного источника, причем, после старта ОС, она сама вытаскивает с серверка копию ПО и запускает его (ну, как в autoexec.bat'е стартовали проги в свое время). Гарантировано -- юзер ничего не снесет. Более того -- он работает только с тем, что у него стоит на машине. Еще -- инсталляция нового ПО будет проходить для пользователя полностью прозрачно и автономно -- с одного сервера (точнее -- на одном сервере ну, максимум, на двух).

Рабочие станции -- самое дешовое из того, что можно найти на рынке, плюс, сетевая карточка с микросхемой удаленной загрузки. Удешевление за счет отсутствия дисков, дисководов, крутых видеокарточек, CD-ROM'ов... только "мама", проц, "мозги", сетевушка и клава с монитором, ну да -- дохленькая видюшка. Все.

IMHO, сработает...

Сообщение отредактировано: the_Shadow - 04.05.03, 12:53

Если продолжать тему, то (в принципе, это можно уже сейчас попробовать) нужно, IMHO, еще транзакции подкорректировать. Т.е. после того, как мы BEGIN TRANSACTION, мы должны вколотить в пределах одной транзакции как можно больше данных, т.к. :
1. мы в сети и заведомо не получится разрыва соединения. Т.е. ROLLBACK нам не "светит" -- канал-то надежный и проведено будет в БД все, что туда попадет.
2. COMMIT всегда отличался прожорливостью к ресурсам сервера. Его можно делать, скажем, два раза за рабочее время -- в обед и по окончании рабочего для, перед архивацией данных за день. Причем, это я говорю о каждом рабочем месте.
3. работать можно и с данными в буффере.

Далее. Можно в промежуточный сервер воткнуть несколько карточек и развести пользователей по нескольким сегментам ЛВС. Это даст меньшую загруженность магистрали именно на стороне удаленной площадки. На серверах -- врубить балансировку нагрузки на итерфейсах. Т.е. принудительно разделить 2048 (ISDN PRI) между разными субсегментами...

В принципе, как-то vot так...

к столь развернутому ответу могу только добавить, что можно клиентскую часть выполнить в виде server-side скриптов (perl/php/тот же С (cgi), но можно и на Delphi(cgi)), а в качестве базового терминала использовать любой(!) браузер под любой платформой, клиентская часть серьезно упадет в цене, если грузить Linux (по сети или с CD) и заюзать нетскейп или мозилу, или, если формы правда простые, то линкс
а все, что связанно с генерацией SQL скриптов на апдейты баз, проводить тоже на сервере (серверах)
или можно разнести стоимость клиентских машин следующим образом: несколько дешевых лезут телнетом по локаклке на что-то более мощное ("типа_сервер"), запускают там свои проги, колбасят операции, "типа_сервер" собирает транзакции в приличные пакеты и пересылает на SQL-сервак, один из минусов такого подхода: что делать, если упадет "типа_сервер", т.е. все проблемы локального кэша

основной момент: в любом случае придется переписывать клиентские части  ;)

Сообщение отредактировано: bin - 04.05.03, 19:21

Аааааа.... Ну, и согласен с тобой и не согласен. Обосную.
Конечно же, так можно сделать! И, к стати, именно lynx будет отлично справляться с работой.... НО!

В любом случае к серверу БД добавляется еще и Apache (ну, про IIS умолчим из скромности ;D, про остальных -- типа Netscape, NSCA -- даже не будем поминать. Не стоит тревожить мертвецов...). Туда же "брякнется" обработка SQL-транзакций, там же будет хранение самой БД, и... Короче, нагрузка возрастет, а скорость на терминалах резко (поверь -- опробировано) упадет...

Дело в том, что (если мне не изменяет моя шлюха-память), то в Oracle есть спец. средства для построения именно таких многотерминальных систем. Т.е. там есть:
- SQL*Forms -- построение форм (чтоб с curses/ncurses не мучиться, хотя, конечно, и можно, но сроки разработки возрастут -- и меню и формы и отчеты -- все придется ваять "врукопашную" -- сколько кофе выпить надо будет и сколько народа напрячь!).
- Далее -- там же -- SQL*Menu -- создание меню.
- SQL*Report -- отчеты.
И, самое главное, -- SQL*C и SQL*Net. Первое -- препроцессор С, который переделывает все, что наработано в пакетах выше в более-менее аккуратный код на С (с запросами, формами, меню, отчетами, короче, всей фигней). SQL*Net -- уровень абстрактного представления именно сети для данного ПО.

Таким образом, "нарисовав" прообраз софта, его можно оттестировать используя средства самого Оракла -- интерпретируя. Или, в оконцовке, "собрать" все это в кучу в виде компакнтого кода на С. Работает очень шустро... И, к стати, все -- в терминальном режиме.

Правда, можно и на X11 графику "прикрутить", но она здесь и близко не нужна.

Если у кого-то бродят мысли по поводу "Terminal Edition", то лучше от них сразу отказаться, т.к. "поверх" тормозавра от M$, еще и слой этого д....ма накладывается -- т.н. косметика для "типа_терминальных_устройств". Бред это. Лучше уж в таком случае использовать то, что от Бога было заточено под работу с терминалами, а не выдавать желаемое за действительное. Хотя, может, оно где-то (как-то, у кого-то) и работает, но я это в работе не видел. Хотя, "отзывы" -- слышал... Пересказывать не буду. ;D И не просите... ;D

Сообщение отредактировано: the_Shadow - 05.05.03, 03:45

Ладно... Подумав, продолжаем.

Ну, собственно, чего мы тут про Oracle да про Oracle...

Есть и альтернативный вариант, но только более трудоемкий в реализации. Хотя, и более "бесплатный" и, к стати, более быстродействующий.

Ингридиенты -- те же. Только БД меняем на любую другую -- от PostgreSQL до SAP DB.
К стати, в последней сам сейчас разбираюсь. MySQL не проходит -- он не для того создавался по определению.

Клиентская часть пишется на C или Pascal (в принципе, в Linux, в пакете девелопера есть даже прекомпилятор Pascal -> C). Я прошу прощения, что пишу именно про С, но как под UNIX с Паскалем -- БМП...

Но в этом случае нам придется:
- делать интерфейс "врукопашную", используя библиотеки curses/ncurses. Т.е. на базе этой либы создаем функции отрисовки/заполнения именно своих форм/меню, а только потом это дело собираем как из кубиков в свой проект.
- работу с SQL в данном случае целесообразней всего строить на базе Embedded SQL, который есть в составе любой уважающей себя базы данных. Прекомпиляторы SQL->C, как правило, там есть так же. Т.е. отрабатываем взаимодествие с БД на SQL (все операции прогоняем через интерпретатор команд соотв. БД -- они есть везде), проверяем работу скамих SQL-скриптов. Далее просто "перегоняем" эти скрипты в код, для увеличения скорости работы самого софта. Но никто не отменял именно хранимые процедуры и обработку транзакций, основанные на тех же принципах, что прописаны выше.
- отчеты. В данном случае это -- больное место... Придется делать их "врукопашную". Т.е. каждый отчет делать в виде одного модуля и отдельно тестировать. Это -- реально больное место -- поверьте... Особенно, если их -- много. И в конце работ заказчик пламенно возжелает добавить еще десяточек...

Лирическое отступление. Здесь важно заметить, что для ускорения разработки придется собирать "команду". Т.е. такая разработка водиночку просто не делается за разумные сроки... И нужна будет четкая синхронизация работ.

Так. Как грузить все это безобразие на клиента... Протоколы bootp и tftp нам помогут, хотя, более уродливый вариант -- dhcp то же имеет право на жизнь. Суть в том, что diskless WS при включении будет в широковещательном режиме (при наличии м.схемы удаленной загрузки) пытаться определить кто ей сможет дать адрес TCP/IP и откуда она сможет загрузить ядро (собственно, для загрузки ядра именно tftp -- по определению Trivial File Transfer Protocol и разрабатывался). Самое противное во всем этом -- дикая нагрузка на сеть в момент начала рабочего дня. Т.е. толпа народа врубает свои "тачки" и каждая начинает "орать" в сетку... Поэтому, и стоит разводить юзеров по разным подсегментам, иначе, они до обеда грузиться будут...

Сегменты можно сотворить на базе нескольких карточек в сервере на удаленной площадке (и это, к стати, лучшее решение) или на базе шустренького коммутатора Ethernet, up-linkованного на "промежуточный" сервер... Или как-то эти два решения скомбинировать... Надо смотреть по месту.

Ладно, ежели еще чего в голову постучится -- отпишу.

Цитата vot, 04.05.03, 14:45:18

Решение, уже имеющееся на сегодня, меня не слишком радует:

Используется MS SQL Server под W2K, на весьма шустрой тачке.
Клиенты ходят на сервер по VPN (виртуальная частная сеть) через интернет
(выделенный канал 2МБит). На клиентских машинах используется программа-клиент, написанная на Дельфи.
Недостатки существующего решения:
- Имеющийся SQL-сервер очень чувствительно тормозит
- Нерационально написанный клиент забивает канал трафиком так, что 2МБит уже не хватает...
- Слишком дорого каждому клиенту ставить целый компьютер

 Было уже предложено тупое решение - расширить канал до 20МБит,
но мне кажется, что это не улучшит ситуацию, поскольку количество клиентов вскоре должно возрасти до 500-600...

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

Как выяснилось - все еще хуже ))
Половина клиентов работают не с SQL, а (не поверите - с базой на MS Access с доступом через ODBC
Программа-Клиент оказалась из-за этого достаточно толстой,
а кроме того, в ней же реализованы и все алгоритмы обработки данных,
т.е. база используется всего лишь как хранилище данных, не более того

Клиентская программа обрабатывает каждое вводимое поле и проверяет его валидность с помощью запросов к базе. Например, вводится код заказчика - программа ищет в базе введенный код, и выдает на экран все реквизиты заказчика.

Требование технологии - база должна быть единой для обеих удаленных друг от друга площадок.
Насколько эффективен будет механизм репликации баз, если основную базу продублировать на сервере второй (удаленной ) площадки?
Не получится ли так, что мы заведем одного и того же нового заказчика с двух площадок одновременно? И тем самым раздвоим записи?

Мммммм... По первой части -- честно говоря, я не думал что все... Вот так вот... ПЛОХО... На Delphi связываться с M$ Access... Мдааааа... Не всех дураков война унесла...  :-/ Тогда о чем мы тут? Любое решение, удешевляющее и ускоряющее работу будет принято на "ура" и, самое главное, оплачено.

А по репликациям все-таки стоит поразмыслить по-подробнее... Скажем, так (я беру абстрактный случай). Т.е. репликацию, IMHO, стоит отрабатывать отдельно и на основании реальных требований заказчика. Скажем, это -- опердень банка. Клиент приходит открывать счет, так? Может ли он появиться в двух филиалах одновременно? Вряд ли. А вот операции с его счетом могут производиться из нескольких точек. Причем, дебетование/кредитование его счета будет производиться на основании текущего состояния счета... Т.е. возможна ситуация, когда приход должен быть, но он не совершон, а расход и надо бы, но в данный момент денег нет.... Думать, однако, надобно... Курить по этому поводу...

IMHO, стоит начать с минимума -- второй сервер -- только для сетевых нужд, а БД держать одну. А дальше смотреть по спецификации и по результатам работы. Как бы не пришлось на время репликации блокировать базы (записи), а это уже не есть гуд... Дело в том, что при хороших объемах мы получим хорошие тормоза на месте (т.е. сразу же)...

2 vot. А глянуть на спецификацию можно? Если по e-mail?

Сообщение отредактировано: the_Shadow - 06.05.03, 18:00