Практика - критерий истины

М. Г.

Игорь Новиков — руководитель группы разработки и сопровождения ПО «Агрисовгаз»

Наше предприятие «Агрисовгаз» уже достигло того уровня развития, когда для эффективного управления им необходимо иметь собственную единую информационную систему. Естественно, у нас возникла проблема выбора — какие аппаратную платформу и ПО использовать при построении Host-систем или серверов БД и приложений в системах клиент — сервер. Возможно, наш опыт в решении этой проблемы покажется кому-то интересным.

Мэйнфреймы

Думается, можно не рассматривать класс компьютерных систем, которые многие называют мэйнфреймами (например, IBM S/390). Достоинства этих машин общеизвестны, впрочем, как и основной их недостаток — высокая цена. На покупку замечательных серверов этого уровня может решиться только руководитель очень крупного предприятия. Хотя надо признать, что для подобных предприятий или тех, кто предоставляет услуги по хранению и обработке информации, такие серверы могут стать оптимальным выбором именно по экономическим показателям (стоимости владения).

Intel +Linux(FreeBSD)

Сейчас снова начался рост популярности Unix, и в первую очередь Linux. На мой взгляд, это вызвано разочарованием в Windows и в какой-то мере является ответом на агрессивную маркетинговую политику Microsoft. Потенциально Unix-системы на Intel представляются мне более подходящими ОС для серверов, чем Windows, хотя бы потому, что они, как и любая другая Unix-система, для того и проектировались. Активное продвижение этих систем на рынок многими компьютерными компаниями — не только дань моде, но и оценка их жизнеспособности. Последнее косвенно подтверждается еще и тем, что IBM вводит Linux на всю линейку своих продуктов (включая мэйнфреймы и AS/400), имея собственную ОС AIX. Так как мой личный опыт работы с такими системами минимален, скажу только, что почтовый сервер на бесплатной FreeBSD у нас на предприятии работает безупречно.

Intel+Novell NetWare

При создании корпоративной информационной системы платформой может служить и связка Intel +Novell NetWare, однако необходимо помнить, что традиционно NetWare позиционировалась как средство для организации файловых серверов и редко использовалась в качестве ОС сервера БД (чаще всего совместно с СУБД Btrieve), а еще реже — для сервера приложений. При построении файловых серверов на Intel-платформе эта ОС вне конкуренции. Она намного быстрее и стабильнее Windows, менее требовательна к аппаратной части и более удобна в администрировании.

В последнее время фирма Novell попыталась сделать NetWare более популярной для разработки на ее основе серверов БД и даже включила в поставку СУБД Oracle, но пока ощутимых сдвигов в этом направлении, видимо, не достигла.

Что касается серверов приложений, то здесь немалую роль играет возможность управления заданиями, работающими в системе одновременно, причем как со стороны самого задания, так и со стороны администратора. Эта область пока не является сильной стороной NetWare, что также делает ее менее привлекательной для организации серверов приложений, ориентированных на большие нагрузки.

Кроме того, не очень радужная картина складывается с программированием под NetWare — число опытных разработчиков ПО для этой ОС не так велико, поэтому могут возникнуть проблемы с набором персонала и получением квалифицированной помощи.

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

Intel + Windows NT/2000

Самой разрекламированной платформой является связка Intel + Windows NT/2000 — по количеству рекламных проспектов и роликов эта платформа занимает твердое первое место. Однако и здесь тоже не все однозначно. Конечно, из-за повсеместного распространения и относительно невысокой стоимости в настоящий момент она не может идти ни в какое сравнение с другими платформами по числу разработчиков ПО. Это в свою очередь приводит к тому, что большинство программ пишется сейчас только для Windows либо портируется на него. Да и цена такого продукта меньше, чем написанного для любой иной платформы. Но, к сожалению, судя по собственному опыту, могу сказать, что, несмотря на все свои достоинства, у этой платформы множество недостатков, и основной из них — низкая надежность системы.

Так, если с NetWare у нас случаются неполадки всего один раз за несколько месяцев и львиная доля их приходится на аппаратные сбои, то серверы под NT требуют к себе значительно большего внимания. Самое неприятное в этих сбоях то, что происходят они иногда по абсолютно непонятной причине. Для серверной платформы такая непредсказуемость очень опасна, так как нельзя выстроить линию поведения персонала, которая по возможности снижала бы риск непредвиденной остановки системы. Второй неприятностью является крайняя «прожорливость» операционной системы. Для нормальной работы NT в качестве файл-сервера (а в этом режиме ресурсов нужно намного меньше, чем при работе сервера приложений) необходимо иметь по крайней мере 64 Мбайт памяти, даже если суммарный объем всех разделяемых данных не превышает этой величины. Хочется спросить: а как же тогда у нас в институте ЕС-1045 поддерживала одновременную работу 35 студентов под управлением СВМ и при этом была укомплектована 4-Мбайт памятью?

Еще более неприглядную картину можно наблюдать, если поставить на Windows какую-нибудь СУБД (допустим, Oracle) плюс связанный с ней сервер обработки. Оказывается, что нормально функционирует эта машина только тогда, когда оперативная память у нее начинается с 512 Мбайт. Ко всему прочему, значительно возрастает и количество сбоев. Причем это не только мои частные выводы. У нас были случаи, когда на наш запрос сделать конфигурацию «1С», позволяющую работать в режиме клиент — сервер (с использованием MS SQL Server), мы получали от фирм-интеграторов совет отказаться от такого варианта и перейти в режим разделения файлов, что будет более надежным и быстрым решением. При собственной разработке серверного ПО из-за этих проблем приходится выносить серверы БД и приложений на разные компьютеры, т. е. увеличивать финансовые и временны'е затраты.

Специального рассмотрения заслуживает вопрос и о поддержке многопользовательской работы на сервере приложений. Обычно для каждого вновь подключающегося пользователя на сервере запускается отдельное задание, которое должно обрабатываться одновременно с остальными. Как правило, все идет более или менее нормально, пока количество заданий не превышает двух десятков, а дальше начинается резкий спад производительности и к тому же возникает большая зависимость заданий друг от друга. На мой взгляд, сервер не должен позволять некорректно работающему заданию влиять на все прочие.

Событие, когда одно «зависшее» приложение приводит к полному краху системы, — к сожалению, не редкость. Не очень хорошо обстоят дела и с управлением заданиями, работающими в системе, что неприемлемо для крупных серверов приложений. При большом числе таких заданий администратор должен иметь возможность как-то влиять на их функционирование, т.е. выделять ресурсы, назначать приоритеты, временно приостанавливать выполнение и т.д. Однако пока еще эта возможность не реализована, хотя первые попытки уже делаются в рамках проекта Windows 2000.

Причиной всех перечисленных выше проблем является, по моему мнению, изначальная ориентация Windows на рынок персональных компьютеров и небольших локальных сетей. Только этим можно объяснить тот факт, что функции прорисовки окон входят в системный код и выполняются с теми же приоритетами, что и остальные системные функции. Но не отвечающий на запросы пользователей сервер, который «зависает» из-за «зависшего» окошка, согласитесь, не очень-то хорош — по крайней мере это не сервер для критических приложений. А к критическим приложениям на крупном предприятии можно отнести практически все ПО, отвечающее за управление производством или финансовыми потоками.

AS/400 и другие спецсерверы

Одним из вариантов платформы для построения корпоративной информационной системы являются также специализированные серверы. К ним можно отнести, например, Unix-серверы, созданные не на Intel-платформе (скажем, HP 9000 Enterprise Server от Hewlett-Packard и Sun Enterprise Server от Sun Microsystems), или систему AS/400 от IBM. Все они в принципе разрабатывались как серверы, и некоторые моменты реализации многозадачности и управления в них решены схожим образом, поэтому, сравнивая организацию серверов приложений на какой-то из этих платформ и на платформе Intel+Windows, можно частично распространить результаты и на остальные платформы. На нашем предприятии Unix-системы используются только в качестве рабочих станций для проектирования, а вот AS/400 — как сервер приложений, поэтому далее будем исходить из опыта работы именно с этой системой и прежде всего поговорим о том, что вызывает нарекания. Главный ее недостаток, по сравнению с Intel+Windows, многие связывают с более высокой ценой ПО и большими начальными издержками на приобретение оборудования. Да и выбор доступного ПО, говорят, невелик. К тому же, как отмечается, необходимо иметь в штате квалифицированного сотрудника, хорошо разбирающегося в такой сложной системе (естественно, с соответствующей зарплатой). У нас система AS/400 работает уже около трех лет, и мне представляется, что эти замечания не совсем корректны.

Попробуем разобраться с первым тезисом о дороговизне. Сейчас можно купить AS/400, которой будет достаточно для одновременной работы 20—25 человек с большими базами данных, за 40—50 тыс. долл. Что мы получим за эти деньги? Во-первых, очень надежный специализированный сервер. Во-вторых, внушительный набор программного обеспечения. Кроме непосредственно компьютера со всеми серверными опционами типа RAID пятого уровня, SCSI HDD, специальных высокоскоростных каналов ввода-вывода, сетевого оборудования, внутренних и внешних UPS, средств мониторинга неисправностей, устройства резервирования (ленточного накопителя) и т. д.

Набор ПО может отличаться по составу в зависимости от серии системы, но в нем обязательно присутствуют следующие компоненты:

• собственно OS/400 (весьма стабильная и удобная система);
• СУБД DB2 Universal Database (полнофункциональная СУБД, одна из самых быстрых и стабильных в мире);
• TCP/IP серверы: telnet, ftp, http, mail и т. д.

В случае разработки собственного ПО придется потратить еще около 10—15 тыс. долл. на приобретение средств разработки и утилит. В результате этой грубой прикидки мы получаем первоначальные затраты в пределах 50—65 тыс. долл.

Посчитаем теперь, во сколько обойдется организация подобной системы на Intel+Windows. Для одновременной работы 20—25 человек с БД объемом до 3 Гбайт нам понадобится компьютер примерно такой конфигурации:

• два быстрых процессора (лучше последние Xeon);
• минимум 512-Мбайт ОЗУ (хотя не уверен, что этого хватит);
• RAID пятого уровня, причем с большой кэш-памятью и RISC-процессорами для разгрузки центральных процессоров;
• от трех до пяти SCSI HDD;
• большой корпус с дублирующими блоками питания и блоком для горячей замены дисков.

Мы приобрели себе подобный компьютер за 13 тыс. долл., причем собирали его сами и комплектующие покупали по отдельности. Фирменный компьютер такой же конфигурации, например от Hewlett-Packard, продается по цене от 20 тыс. долл. без учета стоимости гарантийного обслуживания.

Кроме «железа» необходимо еще и ПО. Если предприятие старается быть цивилизованным, то ПО для информационной системы оно должно покупать легально. Для построения сервера понадобится по крайней мере три вещи:

• Windows NT/2000 Server 25 User Lic (4 тыс. долл.);
• СУБД, например SQL Server или Oracle 25 User (3—9 тыс. долл.);
• средства разработки (2 тыс. долл.).

Суммарная стоимость составит 29—40 тыс. долл. что, конечно, меньше, чем для AS/400, но в принципе это уже соизмеримые величины.

Далее надо учесть, что качество компонентов производимых для рынка ПК в общем ниже, чем качество комплектующих для специализированных серверов, а значит, при использовании Intel-платформы будет больше незапланированных затрат, связанных с заменой оборудования. На основе собственного опыта могу сказать, что за три года мы не сталкивались с отказами на AS/400, а практически для каждого из Intel-серверов нам пришлось менять жесткий диск и оперативную память.

С тезисом о малом количестве ПО, подходящего для платформы AS/400, можно, пожалуй, и согласиться — действительно, выбор не так широк, но зато каждое из приложений корректно работает, и я не слышал, чтобы кто-нибудь жаловался на то, что не смог запустить купленный продукт.

Опасения же по поводу излишней сложности администрирования оказались совершенно напрасными. Администрировать AS/400 довольно легко по одной простой причине — она не нуждается в постоянном внимании. Если система вышла на штатный режим эксплуатации, можно вообще забыть о ее существовании. В течение трех лет, пока у нас работала AS/400, был лишь единственный случай, когда администратору пришлось восстанавливать работоспособность системы, и то, как позднее выяснилось, из-за собственной ошибки в настройке конфигурации. Более того, поскольку DB2 Universal Database встроена в операционную систему, одного человека вполне достаточно для администрирования и сервера, и СУБД. А например, для Oracle на Windows NT обычно берут двух специалистов. Функции администратора AS/400 заключаются главным образом в своевременном архивировании данных и установке PTF и новых релизов OS/400.

Основным же достоинством AS/400 несомненно является ее надежность: за три года эксплуатации — ни одного аппаратного сбоя и всего один день простоя, вызванный ошибкой администратора. И что особенно в ней подкупает, это ее способность сохранять данные даже в нештатных ситуациях и богатые возможности восстановления в случае их гипотетической потери. У нас был период, когда чуть ли не ежедневно на короткое время отключалось питание или происходили перепады напряжения. Однако ни разу все эти «катаклизмы» не привели к потере данных. Правда, заниматься восстановлением данных в БД по журналам нам иногда приходилось, но не из-за того, что эти данные испортились, — просто мы их сначала удаляли, а через несколько дней оказывалось, что они нужны. Вообще система журналирования БД в AS/400 в совокупности с архивированием позволяют в большинстве случаев надеяться на то, что данные удастся восстановить практически после любых сбоев и до любого нужного состояния.

Не менее важно в AS/400 с точки зрения построения больших информационных систем является то, что она изначально проектировалась именно для этих целей, и все, что делается для нее, — делается из расчета применения в многопользовательских и многозадачных средах. Например, здесь приняты все меры для того, чтобы некорректно работающее приложение одного пользователя не могло как-то навредить приложению другого, что не очень получилось у разработчиков Windows. Хорошо продуманы вопросы безопасности и защиты от несанкционированного использования чужих данных при многопользовательской работе, чего также не хватает в Windows. И наконец, предусмотрены все необходимые функции по управлению заданиями в системе, что весьма существенно при большом числе одновременно работающих заданий. Это особенно характерно для корпоративных информационных систем. Администратор может в любой момент времени приостановить малозначащее, но трудоемкое задание для того, чтобы предоставить высвобождающиеся ресурсы более значительному, и при этом время, потраченное на выполнение задания, не теряется, так как потом его можно будет продолжить с того же места.

* * *

А теперь подведем итоги. Так какую же платформу выбрать в качестве основы для построения информационной системы предприятия? На мой взгляд, руководствоваться нужно прежде всего экономической целесообразностью — именно с этой целью и строят информационные системы. Только за критерий экономической эффективности надо принять не пресловутый показатель «производительность/стоимость» или «количество транзакций в секунду/стоимость», а формулу вроде следующей: ЭФ — З — Ш, где ЭФ — экономический эффект от внедрения системы за время эксплуатации, З — затраты на внедрение и поддержку в процессе эксплуатации, Ш — деньги, потраченные на восстановление данных из-за неисправностей и неполученные или потраченные в связи с простоем (например, штрафы в налоговую инспекцию).

Если взять среднее или крупное предприятие, где система будет использоваться в течение 5—10 лет, то выгоднее всего купить специализированный сервер, да еще и подписать договор на обслуживание — на всякий случай — и не экономить при покупке. Для подтверждения этого приведу следующие выкладки: за последние три года система AS/400 простаивала один день (хотя и его можно не считать), а сервер на Windows-платформе — в среднем около 15 дней в году (ошибок аппаратуры и ПО было примерно поровну). Приблизительно такие же показатели и у NetWare. То есть на протяжении трех лет около 45 дней серверы были недоступны.

Представляете, к каким финансовым потерям это может привести, если, допустим, период простоя сервера, на котором хранится финансовая информация, совпадет со временем сдачи данных в налоговую инспекцию и ПФ. Плюс деньги, недополученные за время простоя, например из-за срыва выполнения пары контрактов. Прибавьте к этому затраты на восстановление данных после сбоев и ремонт оборудования, а также зарплату еще одного администратора — он может понадобиться, если на Windows придется ставить СУБД типа Oracle.

Мы все это подсчитали и решили строить свою систему на AS/400. И как показывает практика, выбор оказался верным.

ОБ АВТОРЕ

Игорь Новиков — руководитель группы разработки и сопровождения ПО «Агрисовгаз», е-mail: novikov@agrisovgaz.ru