Модернизация корпоративной сети
Менеджер информационной системы одной из крупнейших московских торговых фирм рассказывает о трудностях, с которыми он столкнулся, стараясь оптимизировать задачу выбора ПО и технических средств при модернизации сети своей фирмы
Борис Славин - не новичок в информационных технологиях. Осенью прошлого года он принимал участие в проекте локализации Windows 95 и Office 95, знаком с работой корпоративной сети дублинского филиала Microsoft в Ирландии, внимательно отслеживает современные тенденции развития компьютерного мира. С этого года он возглавил информационные службы фирмы "Партия", и ему пришлось решать проблему модернизации информационной системы этой торговой компании. Задача эта оказалась весьма сложной. Изобилие программных продуктов на рынке ставит любого администратора сети в положение буриданова осла, а компьютерные издания, публикующие в основном статьи, посвященные готовым разработкам или внедренным системам, практически не затрагивают наиболее трудный этап перехода к новым технологиям - этап выбора программного обеспечения и технических средств при смене архитектуры корпоративной сети. Борису пришлось "продираться" самому. И сегодня, когда ему удалось осуществить выбор и составить техническое задание на предстоящий проект, он делится своими впечатлениями в надежде, что поднятые проблемы будут интересны и другим администраторам корпоративных сетей (а их, по результатам обработки присланных в редакцию анкет, только среди наших подписчиков более двух тысяч).
ЧТО ИМЕЕТСЯ СЕГОДНЯ
Сегодняшняя корпоративная сеть фирмы "Партия" включает в себя сеть центрального офиса (около ста рабочих станций), локальные сети магазинов, которых в настоящее время восемь (в каждом по 12 - 16 рабочих станций), а также сети на складах, в сервисных центрах и малом офисе. Как основа информационного обеспечения используется СУБД Raima Data Manager и программа торгового и складского учета - собственная разработка отдела программного обеспечения фирмы. Существующая программа, первая версия которой была выпущена три года назад, вполне подходит для информационного обеспечения фирмы типа офис - склад - магазин с единой локальной сетью и центральным сервером. База данных имеет распределенный характер, она установлена на всех удаленных площадках (магазинах, складах). Информация, введенная в базу данных в магазинах при выписке и на складах при отпуске товара, раз в день в виде отдельных файлов передается по модему в центральный офис и загружается в центральную БД. Аналогичным образом магазины ежедневно получают информацию из офиса о состоянии складов и прайс-лист.
Так выглядит главный офис торговой
компании "Партия"
Несмотря на наличие достаточно развитой информационной системы, необходимо учитывать и возможности развития ее в будущем. Понятно, что с ростом числа магазинов, складов и самой БД информационные потоки начнут превышать ресурсы программы, работа замедлится, появится много рутинных операций. Прежде всего возникнут проблемы с загрузкой данных, полученных с площадок, поскольку БД не поддерживает согласование распределенных данных и тиражирование транзакций. Кроме того, существующая БД не может использовать дополнительные ресурсы по быстродействию и памяти современных производительных серверов, а увеличение темпов роста объема БД приведет к уменьшению периода архивирования данных, доступ к которым в результате усложнится. Ясно, что время жизни данных в активной базе будет сокращаться по мере роста компании и увеличения объема передаваемой информации. Кроме того, поскольку невозможно при большом числе удаленных площадок организовать работу БД в онлайновом режиме, возникнут коллизии при резервировании и выписке товаров с разных площадок одного склада.
Помимо проблем с БД остаются проблемы и с поддержкой работоспособности распределенных локальных сетей, с ростом числа которых вероятность сбоев также возрастает. Так как на площадках выписка товаров автоматизирована, остановка работы сети приводит и к остановке работы магазина или склада, что, без сомнения, является более нежелательным, чем просто сбой в передаче информации.
Что принималось в расчет
При модернизации сетевого хозяйства очевидна необходимость типизировать системные блоки, сетевые карты и принтеры, чтобы легко и быстро можно было устранить неполадки, предусмотреть возможность работы с резервным сервером, ввести дублирующие каналы связи, наладить профилактические работы и т. п. Однако с выбором СУБД и общего направления модернизации сети дело обстоит сложнее.
Единственное, что сразу не вызывало сомнений, - это необходимость модернизации описанной выше информационной структуры на базе клиент-серверной технологии. По крайней мере, это позволит использовать ресурсы современных серверов и даст возможность повышать производительность работы с БД и в будущем. Круг СУБД масштаба предприятия, рассматриваемых в качестве основы построения новой БД, был сразу ограничен системами класса Oracle, Sybase, Informix, MS SQL Server, Ingres и т. п.
Первое, что предложила одна из фирм-интеграторов в качестве модернизации информационной системы фирмы "Партия", - это СУБД Oracle и сеть на основе центрального Unix-сервера. Согласно этому проекту все магазины и склады объединяются в единую сеть с помощью выделенных телефонных линий и работают в терминальном режиме при наличии одного мощного сервера в центральном офисе.
У такого решения есть ряд положительных сторон. Во-первых, режим реального времени позволяет полностью решить проблему коллизий транзакций, поскольку данные хранятся на одном сервере. Во-вторых, централизованный вариант достаточно проработан: большое количество банков, крупных государственных учреждений и служб уже используют централизованную систему. Кроме того, в нашей стране достаточно широк круг специалистов, разбирающихся в Oracle и Unix, что немаловажно при выборе новой системы (необходимо организовать обучение персонала и привлечение дополнительных специалистов для разработки ПО).
Однако в случае распределенной торговой сети централизованная система имеет один недостаток. Выделенные линии (даже при наличии резервных коммутируемых каналов) не обеспечивают абсолютной надежности: в течение месяца возможны сбои продолжительностью от 0,5 до 1 часа (помимо мелких сбоев), а иногда, хотя и редко, нормальная связь может отсутствовать день или два (особенно в весеннюю погоду, когда подтапливает колодцы). Наличие таких сбоев, ведущих к остановке выписки товара со склада, недопустимо для торгового процесса. В силу того, что большая часть товаров продается именно с магазинного склада, необходимость жесткой привязки к центральному серверу не может оправдать даже небольшого простоя магазина. Как объяснить клиенту, что он не может купить магнитофон, имеющийся в магазине, только из-за того, что нет связи с центральным офисом? Такая "автоматизация" лишит фирму всех покупателей.
Вообще выбор архитектуры сетевой БД должен в первую очередь зависеть от целей использования базы данных. Нельзя заранее сказать, что лучше - централизованная или распределенная система (жесткая или гибкая), спорить о преимуществах можно лишь относительно того процесса, который автоматизируется. При модернизации информационной системы торговой фирмы, имеющей распределенную сеть магазинов и складов, СУБД должна быть распределенной. Гибкость структуры распределенной БД наиболее актуальна в российских условиях, когда средства связи не идеальны, а ввод новых магазинов или складов опережает прокладку коммуникаций.
Однако самым сложным моментом при обсуждении путей модернизации является выбор программного обеспечения. Универсального ответа на вопрос, какая СУБД лучше всех, не существует. Можно находить множество и недостатков, и достоинств в реализации тех или иных операционных модулей СУБД различных фирм. Самый точный ответ может быть получен только при разработке специалистами одинаковой квалификации одной и той же базы данных для разных СУБД, что, конечно же, нереально.
Поскольку практически все СУБД (типа Oracle, Informix, Sybase) позволяют нормально организовать работу распределенных баз данных с репликацией, обработкой транзакций и т. п., основными критериями при выборе СУБД становятся стоимость всего проекта (с учетом имеющегося и предполагаемого оборудования и дополнительного программного обеспечения), выполнимость его в разумные сроки и возможность привлечения дополнительных разработчиков с опытом работы. Личные пристрастия и советы друзей должны играть последнюю роль.
При разработке конкретного плана модернизации с учетом замены техники в магазинах и офисе, затрат на обучение и программное обеспечение суммарная стоимость различных проектов может различаться в несколько раз. Самое сложное в процессе подготовки вариантов модернизации состоит в реальной оценке затрат. Как правило, на стадии предпроектной проработки фирмы, выступающие в качестве системных интеграторов, неохотно помогают провести предварительные стоимостные оценки нестандартных проектов (по принципу "выбери меня - а потом уж и подсчитаем").
Выбор сделан
Наиболее подробно фирмой "Партия" рассматривались варианты, основанные на операционных системах Unix (на площадках - Novell либо SCO Unix) или NT Server. В качестве СУБД при этом предполагалось использовать либо Oracle 7.0, либо Sybase SQL Server 11 (на площадках - Sybase SQL Anywhere 5.0), либо Microsoft SQL Server 6.0. Понятно, что возможных наборов, отвечающих поставленным задачам, существует гораздо больше. Однако всегда следует помнить о том, что число вариантов не должно стать таким, чтобы предпроектная стадия затянулась на месяцы.
Стоимость проекта в гораздо большей степени определяется затратами на оборудование, разработку и обучение, чем стоимостью самого ПО. Так, выбор операционной системы влияет на выбор соответствующих серверов (платформу - Intel или RISC, размер оперативной памяти и т. п.), выбор клиентской части связан с требованиями к рабочим станциям, процесс тиражирования данных - с коммуникациями и т. д.
Самый дешевый вариант - основанный полностью на ПО от Microsoft (цены Microsoft известны всем). Но при этом нужно учитывать, что найти команду разработчиков, имеющих достаточный опыт работы с MS SQL Server в крупной корпоративной сети, в нашей стране нелегко. Самым же дорогим следует считать вариант с Oracle. Несмотря на обилие разработчиков и проектировщиков, распределенная сеть на базе Oracle c репликацией данных по обычным коммутируемым каналам, видимо, не является у нас хорошо проработанным вариантом - отсюда и высокая стоимость разработки.
После длительных дискуссий и "примерок" был выбран вариант на основе NT Server и Sybase SQL Server, предложенный компанией "Весть". Во-первых, потому, что сервер репликаций Sybase менее требователен к каналам связи для передачи данных, даже с использованием обычной электронной почты. Ориентация на обычные коммутируемые линии не является самоцелью (хотя и удешевляет проект), в процессе модернизации предполагается использовать выделенные линии, радиомосты и одновременно учитывать возможность работы при плохой связи. Во-вторых, вариант NT + Sybase является промежуточным и всегда можно усилить проект, перейдя на Unix, либо существенно снизить затраты, перейдя на MS SQL. Кроме того, - и это, пожалуй, самое главное, - компания "Весть", выступившая в качестве системного интегратора, предложила совместную разработку новой программы торгового и складского учета с участием собственных программистов (имеющих опыт и наработки в области клиент-серверной технологии) и программистов фирмы "Партия" (зарекомендовавших себя в моделировании реальных торговых процессов). Это, с одной стороны, удешевляет стоимость проекта, а с другой - повышает ответственность интегратора за обучение "не своих" разработчиков и за техническое сопровождение поставляемого ПО.
Уменьшению стоимости проекта без снижения надежности всей системы будет способствовать использование Sybase SQL Anywhere 5.0 на площадках, а также выбор в качестве операционной системы NT, наличие которой позволяет использовать PC-серверы не только на площадках, но и в центральном офисе. При необходимости можно перейти от многопроцессорного сервера к RISC-платформе фирмы Digital, а в будущем - фирмы Hewlett-Packard или других. Конкретизация конфигурации центрального сервера была отложена до того времени, когда будет возможно проводить стендовые испытания новой программы торгового и складского учета и реально определить запросы программы к производительности оборудования.
Итоги
Итак, основные принципы при модернизации корпоративной информационной БД, по мнению автора, заключаются в следующем.
- Архитектура БД должна соответствовать реальному информационному процессу, а не наоборот.
- Выбор ПО (среди категорий, соответствующих масштабам фирмы) должен обуславливаться не его свойствами, а стоимостными и временными затратами на весь проект.
- Каждая составляющая проекта должна удовлетворять запросам и возможностям сегодняшнего дня и в то же время быть способной к развитию в будущем (быть масштабируемой).
- Этапы проведения работ по модернизации необходимо распределять так, чтобы иметь возможность относительно безболезненно скорректировать проект, а основные траты должны быть сделаны после того, как успешное выполнение проекта практически гарантировано.
В заключение стоит отметить, что огромную роль в принятии решения играет еще и человеческий фактор. Помимо стандартных требований к проекту возникает необходимость учитывать пожелания руководства, менталитет собственных специалистов и т. п.
Возможно, в процессе реализации проекта обнаружатся новые сложности. Понятно, что критерий истинности - практика, она-то и позволит определить, насколько гипотетические решения, заложенные на предпроектной стадии, соответствуют полученным результатам.
Борис Славин
