Заметки по поводу Tuxedo System

В номерах 1 и 2 "СУБД" за 1996 год напечатана интересная и информационно насыщенная статья Г.М. Ладыженского "Tuxedo System: разработка систем клиент-сервер". Статья дает читателям представление о концепциях и возможностях мониторов транзакций на примере наиболее известного из них - Tuxedo System. Глеб Михайлович, без сомнений, является одним из ведущих специалистов по мониторам транзакций в России, и его статья в целом заслуживает высокой оценки. В качестве СУБД, на которые ссылается автор, говоря о функциональных возможностях Tuxedo, во многих местах упоминается Oracle, что, видимо, не случайно, ибо по своим сетевым возможностям Oracle безусловно опережает своих конкурентов на рынке. К сожалению, именно в этих фрагментах статьи содержится ряд неточностей и спорных утверждений, возможно, вызванных недостаточно полной информированностью автора о последних версиях программных продуктов Oracle. Данные замечания может быть не стоили бы подробного обсуждения в журнале, если бы в одном из разделов статьи (касающемся "экономии на лицензиях") не содержалась просто неверная информация, вводящая читателей в заблуждение. Именно последний факт явился основным побуждающим мотивом для написания данных заметок, и хочется надеяться, что они окажутся полезными для более полного понимания соотношения функциональных возможностей, предоставляемых самой СУБД Oracle, и тех, которые привносит в систему использование монитора транзакций.

Режимы взаимодействия клиента и сервера

Одним из декларируемых преимуществ монитора транзакций является возможность асинхронного взаимодействия клиента с сервером: когда говорится об этом, то явно или неявно подразумевается, что сама СУБД такого режима не обеспечивает. Рассмотрим, как обстоит дело в действительности в случае использования Oracle.

Возможность асинхронного взаимодействия клиента и сервера в мониторе транзакций достигается за счет промежуточного звена между ними - менеджера транзакций (TM - Transaction Manager). При этом клиент фактически взаимодействует с TM в синхронном режиме вызова функций. Что касается взаимодействия TM с сервером БД, то возможность их асинхронной связи в принципе предусмотрена стандартом XA-интерфейса, но лишь в качестве опции. Поэтому на деле она реализована далеко не во всех СУБД (если реализована вообще), в частности, Oracle не поддерживает асинхронного режима взаимодействия сервера с TM. Таким образом, все средства асинхронной связи в мониторе транзакций базируются полностью на функциональности самого TM, она же, что, кстати, хорошо видно из статьи, весьма ограничена.

В то же время сама СУБД Oracle предоставляет возможность определять задания (с помощью пакета DBMS_JOB), которые не только выполняются асинхронно, но и пользователь может управлять их очередностью, временем выполнения, периодичностью и т. д.

Во всяком случае, возможность асинхронного взаимодействия клиента и сервера едва ли может рассматриваться как расширение функциональности системы, привносимое монитором транзакций.

Управление транзакциями

Основной принципиальной концепцией мониторов транзакций является организация взаимодействия на уровне отдельных транзакций, а не сессий. Однако сама по себе эта концепция мало что говорит пользователю, если не обсуждать, каковы ее преимущества и недостатки (а и те и другие безусловно имеются). В этом плане ряд положений статьи Г.М. Ладыженского представляются спорными. В частности, не совсем понятны ссылки на расширенные возможности шифрования информации, предоставляемые Tuxedo. Скорее всего, к сожалению, справедливо замечание о проблематичности сертификации ФАПСИ внутренних алгоритмов шифрования, предоставляемых Oracle (не по причине их технического несоответствия предъявляемым требованиям, а из-за сложности совмещения требований по процедуре сертификации с коммерческой тайной фирмы), но совершенно несправедливы утверждения о "закрытости" канала SQL*Net. Последний, в сущности, представляет собой развитый сетевой протокол прикладного уровня, который в настоящее время полностью открыт. Имея в руках его интерфейс, разработчики приложений могут не только использовать широчайшие возможности SQL*Net (например независимость от транспортных протоколов, возможность совершенно прозрачной работы в гетерогенных сетях) для взаимодействия любых приложений, но и применять собственные алгоритмы шифрования.

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

В качестве последнего замечания отметим, что Oracle SQL*Net не совсем правильно идентифицировать как протокол типа "точка-точка" в чистом виде. Особенно заметно это будет в новой (третьей) версии SQL*Net (в настоящее время - на сентябрь 1996 г. - находящейся в стадии бета-тестирования), которая будет поддерживать такие функции, как "мультиплексирование" сессий, взаимодействие на уровне асинхронных сообщений, т. е. то, что до сих пор считалось прерогативой мониторов транзакций.

Баланс загрузки

То, что написано в статье Г.М. Ладыженского о балансе загрузки и маршрутизации запросов в мониторах транзакций, безусловно верно. Вопрос опять-таки в том, справедливо ли рассматривать эти возможности как расширения функциональности СУБД. Дело в том, что современные СУБД (и Oracle, в первую очередь) позволяют реализовать практически все те же функции собственными средствами. Если говорить конкретно про Oracle, то помимо абсолютно прозрачного для приложений алгоритма двухфазного завершения транзакций в распределенных БД (лежащего в основе мониторов транзакций) эта СУБД дает возможность также организовать многочисленные варианты тиражирования данных, что укладывается в концепции мониторов транзакций с большим трудом.

Динамическое распределение загрузки

Пример, приведенный Г.М. Ладыженским в данном разделе своей статьи, иллюстративен, но не очень удачен. Дело в том, что использовать автоматическое распределение загрузки в случае Oracle Parallel Server в принципе можно, но едва ли стоит. Причиной этого является то, что для эффективной работы Параллельного Сервера в режиме OLTP (а именно на этот режим ориентированы мониторы транзакций) требуется аккуратное распределение пользователей между узлами кластера, дабы минимизировать т.н. блокировки параллельного кэша (связанные с синхронизацией различных буферов в памяти узлов кластера, в которых отображаются одни и те же данные БД). Распределение это осуществляется на основе анализа активности пользователей (характера приложений, интенсивности доступа к различным данным в БД и пр.), что явно не может быть выполнено автоматически. Нужно отметить, что данная проблема носит принципиальный характер, а не является следствием технического несовершенства реализации, поэтому к использованию мониторов транзакций для динамического распределения загрузки в кластерах следует подходить с большой осторожностью.

Другое дело, если дублируются не только буферы (как в Параллельном Сервере), но и сама БД: например, два сервера работают в режиме синхронного тиражирования друг друга. В такой конфигурации динамическая балансировка загрузки вполне оправдана и может дать немалый эффект в повышении производительности системы. Однако и в данном случае есть альтернативы применению мониторов транзакций. Oracle начиная с SQL*Net версии 2.3 предоставляет возможность сконфигурировать процессы-"слушатели" сети, функционирующие на серверах таким образом, чтобы они не только обслуживали разные БД, но и динамически балансировали нагрузку между ними на основе данных о загрузке процессов-диспетчеров, связанных с этими базами. Поскольку информация о загрузке поступает "из первых рук", то правильная сбалансированность нагрузки обеспечивается и в том случае, когда часть пользователей обращается к серверам, используя другие средства. Отличие от мониторов транзакций лишь в том, что распределение нагрузки осуществляется на уровне сессий, а не отдельных транзакций, но и это может оказаться более эффективным подходом в режиме синхронного тиражирования БД. Можно отметить также, что в рамках работы с конкретной БД распределение загрузки выполняется автоматически на уровне отдельных SQL-предложений уже самой СУБД Oracle с помощью механизма многонитевых разделяемых серверных процессов.

Возвращаясь к кластерам и Параллельному Серверу Oracle, можно отметить, что этот продукт осуществляет динамическое распределение нагрузки между узлами кластера, но не при обработке коротких транзакций (т. е. в режиме OLTP), а при распараллеливании выполнения "длинных" запросов (Parallel Query), характерных для систем поддержки принятия решений (DSS).

Мультиплексирование запросов к БД

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

С чисто технической точки зрения, мониторы транзакций действительно можно рассматривать как программные мультиплексоры запросов к БД (кстати, как уже упоминалось, Oracle вскоре позволит реализовывать подобное мультиплексирование собственными средствами SQL*Net). Однако отсюда отнюдь не следует, что можно сэкономить на покупке лицензии на сервер БД, указав меньшее число одновременно работающих пользователей, чем их есть на самом деле. Собственно, если ставить перед собой цель "обмануть" Oracle, то для этого не обязательно привлекать столь сложные технические средства: технический контроль за соблюдением лицензионной конфигурации фактически находится в руках системного администратора. С юридической же точки зрения, указанная "экономия" недопустима. Чтобы у читателя не оставалось сомнений в этом, процитирую определение из документа "Global License Terms" корпорации Oracle: "Одновременные пользователи/Одновременные соединения: максимальное число устройств ввода, имеющих доступ к Программам в любой выделенный момент времени. В случае использования мультиплексных программных или аппаратных средств это число должно быть определено на входе мультиплексора". Насколько известно автору, аналогичные условия применяют при лицензировании и другие производители СУБД.

Так нужны ли мониторы транзакций?

Если у читателя сложилось ощущение, что автор данных заметок (или даже, упаси Бог, корпорация Oracle) является противником мониторов транзакций, то это совершенно не верно. Все вышесказанное служит лишь одной цели: побудить читателей (а главное - потенциальных пользователей) осторожно подходить к оценкам тех или иных программных продуктов, внимательно изучая все аспекты их возможного применения. Что касается мониторов транзакций и Tuxedo, в частности, то этот программный продукт, как и любой другой, обладает своими достоинствами и недостатками. В ряде случаев применение мониторов транзакций действительно дает заметный эффект. По-видимому, оно может быть оправдано, если в системе используется существенно гетерогенная среда хранения данных (различные РСУБД наряду с нереляционными системами), хотя и в этой ситуации возможны альтернативные решения, применяющие различные шлюзы.

Еще одно несомненное достоинство мониторов транзакций в том, что они позволяют увеличивать производительность системы за счет экономии сетевого трафика (неслучайно почти все TPC-тесты выполняются с использованием Tuxedo).

Действительно, поддержка сессий требует передачи большого количества служебных пакетов по сети, что оказывается ненужным при работе в терминах отдельных транзакций. С другой стороны, и здесь необходимо рассматривать альтернативные решения. Например, если ваша проблема - ненадежная и медленная линия связи между клиентом и сервером, то хорошим решением может быть использование программного продукта Oracle Mobile Agents, который помимо минимизации потока данных, передаваемых по линии (сессия не создается, данные компрессируются), обеспечивает корректную работу системы в случае временных срывов связи.

Очевидный недостаток мониторов транзакций в том, что интерфейс приложения с сервером должен разрабатываться на C или C++. Хотя это, как справедливо замечает Г.М. Ладыженский, вовсе не исключает возможности использования различных систем разработки приложений, поддерживающих возможность вызова C-функций (а некоторые из них - например Oracle Developer/2000 - поддерживают и собственные интерфейсы с Tuxedo), доля "ручного" программирования все же существенно возрастает.

Заключение

Автор еще раз подчеркивает, что его задачей было отнюдь не "отругать" хорошую и интересную статью Г.М. Ладыженского, а лишь дополнить и уточнить ряд ее положений, указав при этом на одну существенную ошибку. Другой задачей являлось, не оспаривая техническую сторону статьи, подискутировать относительно излишне категоричных - по мнению автора - оценок, содержащихся в ней. К таковым оценкам автор относит и содержащиеся в заключении утверждения о "явной устарелости" и "непригодности для корпоративных распределенных информационных систем" подхода клиент-сервер, применяемого в СУБД. Это утверждение можно было бы поддержать, если бы современные СУБД, как и 10 лет назад, представляли собой лишь "исполнителей" SQL-запросов, что сейчас очень далеко от истины. Можно отметить также, что концепция мониторов транзакций заметно старше, чем клиент-сервер и даже РСУБД (например история МТ CICS насчитывает уже почти 30 лет), и основным побуждающим мотивом ее появления была потребность распределять загрузку при доступе большого количества пользователей к БД. Остается констатировать, что именно эта задача сейчас эффективнее всего решается серверами ведущих РСУБД.

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