Превращение Web в неотъемлемую часть инфраструктуры предприятия привело к ряду фундаментальных изменений в характеристиках ИТ-инфраструктуры.

Приложения, рассчитанные на использование в Web, хотя и многообещающи, но требуют тщательного планирования инфраструктуры

Ведущие исследовательские организации мира в течение последних десятилетий тщательно изучали вопросы гипертекстовой организации документов, связывания их друг с другом и организации универсального доступа к ресурсам. В какой-то момент разработчики, едва ли понимая, что творят, выпустили из бутылки джинна World Wide Web. Они думали, что получили в руки небольшое удобное средство для обмена информацией между университетами и лабораториями, возможно, представляющее некоторую ценность и для военных. Но кто мог всерьез допустить возникновение в гиперпространстве гигантского универсального магазина или быстрое развитие базовой информационной инфраструктуры, превратившейся в движущую силу современного предприятия? Дело обернулось таким образом, что требуемый от приложений уровень доступности, масштабируемости, безопасности и максимальной нагрузки сильно повысился, так как приложения оказались на службе у гораздо более широкой аудитории, к тому же имеющей непредсказуемые запросы.

Web заставляет предприятия переходить от базовой архитектуры и инфраструктуры к фундаментальной трехуровневой архитектуре с ее основными составляющими: набором служб, обеспечивающих доступ к Web, промежуточного звена, содержащего логику приложения, и самого удаленного от пользователя звена — серверов БД. Помимо функциональности, традиционной для всех транзакционных приложений масштаба предприятия, от такой архитектуры требуется еще умение справляться с динамическим увеличением ресурсов. Кроме того, как никогда раньше остро стоит вопрос надежности.

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

Web-службы будущего

Web-серверы, несмотря на пристальное внимание к ним со стороны всей ИТ-индустрии, редко становятся узким местом Web-служб предприятия. По мнению компании Giga Information Group, критичность остальных элементов (кэш-серверов, средств обеспечения информационной безопасности и системы управления IP-трафиком) значительно выше. Так, буквально на глазах выросла архитектурная значимость кеширования (буферизации). Среди принято различать две главные категории: чисто программные реализации, рассчитанные на стандартные платформы, и специализированные программно-аппаратные решения со своим ПО и специальной файловой системой. В целом более высокой производительности следует ожидать от специализированных установок. В 2000 году мы наверняка увидим больше работающего ПО для обновления кэша и для рассылки страниц, больше нового ПО как для высокопроизводительных, так и для дешевых кэш-систем, а также множество объявлений об услугах по объединению кэш-систем со службами Internet. Уже сегодня существует соглашение между компаниями Exodus Communications и Inktomi о применении созданного Inktomi ПО для кэширования внутри систем Exodus.

Базовая Web-инфраструктура

Другим важным для поставщиков ПО управления Web-ресурсами элементом является управление информационным наполнением узла, позволяющее распределять его между множеством серверов. Чтобы предотвратить попадание запроса на сервер с устаревшим содержимым, применяется репликация данных в сочетании с балансировкой загрузки (последняя позволяет направить запрос на наиболее подходящий сервер). Появилась новая волна поставщиков «Web-переключающих технологий», с помощью которых балансировка загрузки реализуется на уровне маршрутизаторов и переключателей, а не отрабатывается специальным ПО на сервере или выделенной программно-аппаратной установке. Некоторые продукты, вроде переключающего ПО компании ArrowPoint Communications, в состоянии самостоятельно обнаруживать буферизуемое содержимое и направлять его в кэш, а небуферизуемое содержимое направлять прямо на Web-сервер в обход кэша.

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

Логика промежуточного звена

За последнее время появилось много разновидностей средств разработки Web-приложений. Продумывая критерии для их выбора, руководители должны сосредоточиться на том, чтобы дать своим разработчикам сразу целую палитру решений. Если за этой палитрой будет стоять одна общая архитектура (например, JavaBeans / Enterprise JavaBeans, COM или CORBA), то упростится интеграция приложений и переход с одного инструментария на другой (если, конечно, такая необходимость возникнет).

Сейчас в большинстве случаев заказчики выполняют интеграцию приложений собственными силами, однако неуклонно растет популярность интегрированных инфраструктур приложений наподобие WebSphere Application Server Enterprise Edition корпорации IBM или Netscape Application Server — системы, предлагаемой союзом Sun и Netscape. В таких решениях имеется ряд функций, которые трудно запрограммировать самостоятельно, например — обработка сбоев (возможность переключить транзакцию на другой сервер в случае отказа одного), управление состоянием транзакции (задание маршрута для транзакции) и др.

Ресурсы баз данных

Бывает непросто определить местонахождение данных, необходимых для электронной коммерции. В общем случае система электронной коммерции использует данные из нескольких источников, в числе которых Web-сервер, внешний брокер запросов к объектам (ORB), специализированные «резидентные» РСУБД (memory-resident databases) и традиционные централизованные (back-end) базы. Сегодня практически любая сколь-нибудь значимая прикладная система в конечном счете базируется на использовании централизованной БД, причем в больших системах электронной коммерции такие БД все еще располагаются на Unix-серверах и мэйнфреймах. Подавляющее большинство транзакционных систем имеют выход на БД в составе унаследованных с прошлых времен корпоративных приложений на мэйнфреймах.

Интересна наметившаяся тенденция использования «резидентных» СУБД, в которых БД целиком хранится в оперативной памяти компьютера в течение всего периода работы с ней, дисковая же память привлекается только для ведения системного журнала. Все чаще в коммерческих приложениях применяется схема обращения к БД, при которой не используются транзакционные запросы к централизованным БД. Такая схема оправданна тогда, когда нужен быстрый доступ к данным, а проходить весь путь до централизованной БД нет необходимости. В этих случаях разработчики размещают большие объемы данных (например, каталоги товаров) в оперативной памяти системы, что ускоряет выполнение запросов в 100 — 1000 раз. Данная схема может применяться для хранения информации о сеансе и состоянии транзакции, для подготовки выборки информации из файлов пользователя в приложениях, обеспечивающих организацию перекрестных продаж или подготовку специальных предложений, для организации клубов покупателей определенных видов товаров, для записи действий пользователя в системный журнал. Некоторые из таких данных хранятся недолго, а некоторые требуют постоянного хранения и внимания. К примеру, информация о состоянии транзакции собирается в процессе жизненного цикла транзакции. Если система внезапно отказывает, то информация о пользовательской транзакции должна будет поступить на другой сервер, который продолжит работу выбывшего из строя устройства.

Технология в центре

В 1998 году мы были свидетелями значительных перемен в технологии серверов в связи с появлением симметричных многопроцессорных Unix-систем с улучшенной масштабируемостью и второго поколения систем с неоднородной памятью. Корпорация Microsoft выбрала окольный путь, так что всего несколько поставщиков предложили серверы с восемью или более процессорами Intel Pentium Pro для Windows NT. Появившиеся в 1999 году четырехпроцессорные серверы на базе Pentium Xeon II продемонстрировали производительность гораздо более высокую, чем ожидалось, так что спрос на более мощные серверы временно спал, однако задержка поставок восьмипроцессорных серверов подхлестнула его вновь. Ко времени, когда Windows 2000 Advanced Server и Windows 2000 Datacenter Server смогут доказать свою стабильность, NT будет в состоянии работать на 32-процессорных машинах.

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

В мире операционных систем продолжается противостояние Unix и NT. В области высокопроизводительных и высоконадежных систем Unix сохранет свое лидерство. Изменения коснулись абсолютного уровня производительности и зрелости NT. Компания Giga провела широкий анализ надежности систем NT. Результаты, оказавшиеся лучше, чем ожидалось, все же свидетельствуют о неготовности этой ОС для использования во многих корпоративных приложениях, например, в качестве операционной платформы для сервера очень больших баз данных. Раз в месяц, а то и чаще значительное число систем подвергалось сбоям, а число зафиксированных случаев потери данных превышало порог, с которым можно было смириться. Что касается уровня производительности, то и Unix, и NT почти удвоили его за 1999 год, однако производительность Unix остается в три-четыре раза выше. В начале 2000 года обе системы продолжили наращивание своих возможностей: началась поставка Windows 2000, NT стала более активно поддерживаться восьмипроцессорными платформами на базе Intel, а границы масштабируемости Unix расширились еще дальше.

Мэйнфреймы снова признаны надежными рабочими лошадками для промышленных систем. Объем поставок мэйнфреймов не снижается благодаря относительно стабильной категории старых клиентов, вычислительные потребности которых растут темпами, еще пять лет назад казавшимися фантастикой и самим клиентам, и вендорам. Поставщики мэйнфреймов отказываются уходить в историю, постоянно улучшая производительность, снижая стоимость, повышая совместимость с Internet-средами и пр. В экологической системе Сети у мэйнфреймов есть своя прочная ниша, поскольку значительную часть данных предприятия хранят на них.

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

В области систем хранения данных к новым тенденциям можно отнести рождение сети хранения данных (storage area network, SAN), технологии оптических каналов и начало формирования истинно неоднородных сред хранения, а также появление управляющего инструментария для хранения в NT. Благодаря постоянному снижению цен многие развитые возможности по организации хранения становятся теперь доступны не только в качестве высокопроизводительных решений отдельных производителей, но и на NT.

Архитектурные планы

Превращение Web в неотъемлемую часть инфраструктуры предприятия привело к ряду фундаментальных изменений в характеристиках ИТ-инфраструктуры. Те, кто отвечает за ИТ-архитектуру, должны заботиться о встраивании новых элементов, таких как кэширование, управление IP-трафиком, балансировка загрузки или репликация информационного наполнения. Появление нового отдельного архитектурного слоя — служб Web — отразилось на разбиении на составляющие всего приложения и заставило ИТ-архитекторов и разработчиков задуматься о решении новых для них проблем: планирования загрузки отдельных компонентов и размещения по ним различных ИТ-процессов. Другим камнем преткновения стало применение традиционных методов планирования доступных мощностей (capacity planning) в среде Web, так как традиционные модели роста, резервирования и аварийного использования ресурсов в ней не работают.

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

Ричард Фичера — вице-президент Giga Information Group. К нему можно обратиться по электронной почте: rfichera@gigaweb.com