Сеть в малом офисе на основе Linux

Артур Емагулов,
научный сотрудник Международного центра по информатике и электронике (ИнтерЭВМ)

artur@arat.ru

Об использовании платформы Linux в тех или иных задачах уже написано достаточно много. Дабы не повторяться и не заниматься простым перечислением документированных и недокументированных возможностей новых версий программ и ядра, а с другой стороны, не превращать статью в очередное руководство по "тюнингу" ОС с помощью программистских ухищрений, начнем с постановки задачи.

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

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

Исходя из этих требований, из условно-бесплатных продуктов необходимо рассматривать
целевые дистрибутивы Linux, позиционируемые поставщиками как готовые решения
take&use ("возьми и пользуйся"). В нашей стране из таких Linux-решений можно
назвать Red Hat (http://www.redhat.com),
ASPLinux (http://www.asplinux.ru) и SuSE
(http://www.suse.com).

Управление сетью

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

Рис. 1. Типовая схема сети малого предприятия.

Как организовать такую среду? Конфигурацию серверов необходимо вынести и хранить отдельно от системы выполнения (рис. 2). Такой подход совместно с резервированием данных позволит обезопасить данные конфигурации и настройки от сбоев в системе и решит проблему обновления системы и масштабирования. Поскольку информационные системы, как правило, имеют иерархическую структуру и о них можно говорить в терминах объектов, то логично и данные конфигурации хранить в аналогичном виде. Это означает, что реляционная база данных для решения данного вопроса не подойдет.

Рис. 2. Вынесение конфигурации из системы.

Большую работу в этом направлении провели производители серверного ПО, такие как Novell и Microsoft, создав технологические продукты (NDS у Novell и ActiveDirectory у Microsoft) на основе серверов каталогов, которые, в свою очередь, основаны на протоколе LDAP. Что касается дистрибутивов Linux, то в них имеется GPL-аналог NDS и ActiveDirectory — OpenLDAP. Идея состоит в том, что каждый объект в информационном пространстве имеет свое представление в объектной базе данных с соответствующими атрибутами и уровнями доступа. Объектом может быть любое сетевое устройство, пользователь сети, база данных или сервис. Объекты могут группироваться и обладать правами по отношению друг к другу. При этом все манипуляции с объектами в идеале должны проводиться с их объектным представлением внутри каталога. Но это в идеале, а в действительности возникает принципиальная проблема правильности отображения, т. е. возможна ситуация, когда реальные свойства объекта и свойства его отображения не соответствуют друг другу. Иными словами, проблема заключается в том, что любое санкционированное изменение свойств реального объекта должно отражаться в его объектном представлении. Чтобы решить эту проблему, необходим механизм синхронизации.

Задача синхронизации пользователей сети в Linux решается с помощью модулей аутентификации для подсистемы PAM (Pluggable Authentication Modules). На сегодня существуют модули синхронизации в LDAP-каталоге, т. е. можно управлять пользователями сети, используя описанную выше технологию. Для управления сетевыми ресурсами (серверами, сетевыми устройствами и сервисами) таких возможностей, увы, пока нет (по крайней мере на нынешнем этапе развития Linux), нет их и в решениях поставщиков дистрибутивов. Вся конфигурация сервисов и служб в Linux хранится, как и много лет назад, в файлах конфигурации, причем формат этих файлов свой у каждого сервиса. Удаленное управление такими службами либо возможно за счет организации доступа к файлам конфигурации и перезапуску сервисов, либо реализовано внутри самих сервисов, что опять-таки приводит к "разношерстным" протоколам управления и команд и соответственно к потенциальным угрозам безопасности системы.

Так как проблема управления сетевыми устройствами существует с тех пор, как эти устройства появились, вопрос уже был однажды решен — с созданием протокола управления сетью SNMP (Simple Network Management Protocol). Концептуально он схож с LDAP — каждый объект здесь представлен в виде дерева. В Linux также имеется реализация данного протокола, но в дистрибутивах он присутствует в базовой конфигурации, и для его настройки необходимо приложить немало усилий. К тому же удобных некоммерческих средств работы с этим протоколом нет. Таким образом, можно констатировать наличие потенциально очень широких возможностей применения данного протокола, но готового отлаженного решения не существует.

Комплексное управление сложной или иерархической гетерогенной сетью со множеством активных узлов требует совместного использования описанных протоколов. Почему совместного? Дело в том, что SNMP — не только протокол управления, это и очень удобное средство мониторинга событий, так как в нем реализованы механизмы оповещения (об этом речь пойдет ниже). К тому же проблема синхронизации данных в LDAP с реальными данными сетевых устройств в принципе решается при помощи SNMP. Можно сказать, что при таком подходе LDAP будет описывать то, что должно быть, и то, что задумано в управлении сетью, а SNMP — отражать непосредственную реализацию задуманного.

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

Мониторинг

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

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

В Linux стандартный механизм журналирования позволяет организовать вынос журнала из системы и централизованное его ведение. Сетевые устройства ряда производителей, в частности, Cisco, также позволяют вести удаленное журналирование событий в syslog, таким образом, и здесь можно говорить о единообразии средств мониторинга и соответственно о простоте организации централизованного сбора информации о событиях. В устройствах, в которых подобный механизм не реализован, в большинстве случаев можно организовать его посредством SNMP-traps (с использованием модели событий SNMP). Модель событий SNMP позволяет, в дополнение к обычной фиксации события в журнале, определить свои правила реакции на событие. В Linux по умолчанию все события SNMP записываются в системный журнал. Так как реализация SNMP в активных сетевых устройствах — это на сегодняшний день стандарт де-факто, такая возможность имеется практически во всех сетевых устройствах.

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

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

Восстановление и самоуправление

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

Можно предположить, что различие данных в LDAP и SNMP может служить таким критерием. Но этот вопрос требует более серьезного изучения.

***

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