N1: управление большими системами

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

Обычное явление в наших информационных системах — «зоопарк». Иногда об этом сообщают с сожалением — «ну что же тут поделаешь, раз так сложилось». Иногда — с гордостью: «мы что угодно и с чем угодно умеем соединить». Причина возникновения такого зоопарка, как правило проста — бизнес требует применения тех или иных прикладных систем, которые тянут за собой конкретные решения. Например, для системы управления персоналом требовался дисковый массив EMC, подключенных к серверам Sun; банковская система, которая внедрялась другим интегратором, работает на серверах HP с массивами от Compaq, а документооборот на базе Lotus Notes потребовал оборудования IBM. Когда пришла мода на intranet, то к одной системе подключили Web-сервер на MS IIS, к другой — на Linux, а к третьей — на Solaris. Кроме того, разные части сети строились в разное время, где-то на Cisco, где-то на Nortel, где-то на 3Com.

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

Получив такое задание системный администратор получает сильнейшую головную боль и ему остается только мечтать о получении адекватного инструмента управления зоопарком: «Что, если бы можно было все виртуализировать и управлять не коробками, а ресурсами? Еще лучше было бы автоматизировать все настолько, чтобы требовалось только назначать каждому приложению необходимый объем ресурсов, а система сама бы их находила и распределяла.»

N1 — стратегия

Впервые компания Sun Microsystems заявила о стратегии N1 осенью 2002 года. Тогда это вызвало бурные дискуссии, главным вопросом которых было: «Это очередной маркетинговый ход или реальная стратегия?» Компания нарисовала привлекательную картину построения и эксплуатации вычислительных центров, на основе технологий виртуализации ресурсов, управлении системными и прикладными сервисами и автоматизации самого процесса управления путем применения политик. Спустя год сформировалась вполне реальная стратегия и тактика внедрения, подкрепленная набором конкретных продуктов.

Стратегия развития N1 состоит из трех этапов:

• управление инфраструктурой;
• управление прикладными сервисами;
• автоматизация управления.

Управление инфраструктурой

Управление инфраструктурой основывается на концепции виртуализации системных ресурсов и создания «пулов» ресурсов. Известно, что массу времени отнимают рутинные процедуры подключения, перекоммутации, конфигурирования, запуска оборудования и системных сервисов. Каждый администратор стремится минимизировать эти действия путем автоматизации, стандартизации, унификации платформ но не всегда это удается. Разработчики N1 поставили перед собой задачу сделать так, чтобы все оборудование физически устанавливалось и подключалось лишь однажды, а все дальнейшие операции по изменению архитектуры, перекоммутации и переконфигурированию проводились программно.

Научившись программно управлять параметрами оборудования и архитектурой системы, можно поставить перед собой следующую задачу — создание промежуточного системного слоя, позволяющего перейти к виртуальному представлению ресурсов путем сведения всего многообразия конкретных ресурсов к обобщенным. В таком случае их можно было характеризовать унифицированными измеримыми параметрами, позволяющими перейти от конкретных «Pentium/4, 2 Ггц» или «UltraSCSI-III, 73 Гбайт» к обобщенным единицам измерения вычислительной мощности, емкости и производительности дисковых подсистем. Разумеется, не все можно унифицировать. Например, очевидно, что имеются существенные различия в использовании ресурсов между вычислительными узлами с вертикальной масштабируемостью (большие SMP машины) и горизонтальной масштабируемостью (одно-двух процессорные серверы и серверы-»лезвия») — это будут различные типы ресурсов.

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

Управление прикладными сервисами

Система с виртуализированными ресурсами готова к тому, чтобы разместить на ней прикладные сервисы — современные архитектуры прикладных систем имеют достаточно выраженную модульную, многоуровневую структуру, в которой присутствуют следующие уровни (рис. 1):

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

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

Предположим, что системный администратор, имея пулы ресурсов, хочет разместить на них некоторое количество приложений. Тогда, взяв Приложение 1, он анализирует его компоненты и описывает требующиеся ему ресурсы и политики: Приложение 1 требует: M единиц вычислительных ресурсов с вертикальной масштабируемостью (как правило для СУБД или аналитики); N единиц вычислительных ресурсов с горизонтальной масштабируемостью (для уровня приложений или уровня доступа — Web-серверы и порталы); S Гбайт дискового пространства с уровнем производительности L и уровнем защищенности (готовности) P; K единиц сетевой пропускной способности. Общий уровень готовности приложения должен составлять B.

Сформулировав эти требования, системный администратор передает их «шине управления N1». Шина анализирует доступные ресурсы и резервирует их в соответствии с заданными политиками и требованиями. После определения необходимых аппаратных ресурсов шина производит размещение компонентов Приложения 1 на зарезервированном оборудовании и задает режимы их использования. Так, например, будут заданы предельно допустимые уровни загрузки процессорной мощности, определены режимы и приоритеты перехода на резервные мощности в случае сбоя.

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

Автоматизация управления

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

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

N1 — продукты и решения

На сегодняшний день в N1 реализованы средства управления инфраструктурой, включающие: средства виртуализации и управления системами хранения данных, средства управления ресурсами больших SMP-серверов, средства управления группировками серверов. Совсем недавно появился продукт, позволяющий говорить о начале перехода ко второй фазе реализации — управлению прикладными сервисами.

Системы хранения данных

Еще недавно системный администратор для того, чтобы работать с дисками, был вынужден пользоваться заклинаниями типа «newfs -b 4096 /dev/rdsk/c0t3d0s6» (и так для каждой новой файловой системы на каждом разделе диска). Рост объемов данных и необходимость упрощения администрирования привели к появлению менеджеров томов, позволяющих лишь однажды вспомнить о физических дисках и разделах при создании логического тома и впоследствии работать уже на более высоком уровне абстракции. Следующим шагом к упрощению жизни администратора стало появление технологий виртуализации в дисковых массивах, которая позволила избавиться даже от этого первого шага.

Для того, чтобы получить настоящую виртуализацию систем хранения, не хватает одного — централизованного управления. Для управления гетерогенной сетью хранения данных имеется продукт N1 Data Platform, который позволяет сформировать «промежуточный слой» между сетью серверов и сетью данных. Этот продукт представляет собой коммутатор потоков данных между серверной частью вычислительного центра и сетью хранения данных. Коммутатор имеет до 32 портов протокола Fibre Channel и до 16 процессоров данных. Помимо коммутации система выполняет функции менеджера томов, разгружая от этой задачи процессоры подключенных хостов. Таким образом, мы получаем консолидированный менеджер томов, позволяющий объединить все ресурсы хранения в единый виртуализированный пул.

N1 Data Platform также выполняет функции управления ресурсами хранения, обеспечивая учет использования и управление производительностью за счет организации томов (задание уровней RAID и т.п.). В устройстве предприняты специальные меры по обеспечению защиты данных и изоляции друг от друга томов, используемых различными приложениями. Устройство имеет встроенную функцию создания моментальных копий в сети хранения данных, что также помогает разгружать центральные процессоры серверов.

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

Управление SMP-серверами

Разработчики из Sun Microsystems — активные приверженцы архитектуры симметричной многопроцессорной обработки, которые компания выпускает с 1990 года. В середине 90-х годов высказывались серьезные сомнения в целесообразности развития этой архитектуры — многие аналитики и производители вынесли приговор «не больше 10-12 процессоров в SMP-системе, после этого наступает деградация». Однако в Sun продолжается разработка и внедрение 64-процессорных серверов и совершенствование ОС Solaris для лучшей масштабируемости, что, в результате, позволило сделать первые шаги в сторону лучшей управляемости ресурсами, заложившими основу N1.

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

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

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

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

Управление серверными группировками

Работа с большим количеством сетевых Unix-систем в Sun была налажена давно — уместно вспомнить, что компания начинала с разработок сетевых рабочих станций, которые поставлялись и запускались десятками и сотнями. Для таких массовых установок и были разработаны технологии JumpStart и Solaris Flash, позволяющие производить массовую установку и конфигурирование рабочих станций. С появлением blade-серверов ситуация стала критической — теперь только в одну стандартную стойку можно поместить до 160 самостоятельных серверов. Очевидно, что без специальных средств управления такими серверными фермами их эксплуатация не представляется возможной. Именно поэтому сейчас эти системы поставляются в комплекте с программным обеспечением N1 Provisioning Server.

Этот пакет позволяет системному администратору проектировать серверную ферму методами, очень похожими на рисование диаграмм в продукте Visio. Администратор проектирует архитектуру комплекса, подбирает необходимые компоненты (Web-серверы, межсетевые экраны, балансировщики загрузки, почтовые серверы) и соединяет их между собой. Отличие состоит в том, что N1 Provisioning Server обладает возможностью анализировать имеющееся в наличии оборудование и производить программную перекоммутацию, установку и конфигурирование системного программного обеспечения. В результате получается то, что можно было бы назвать мечтой администратора, который только чертит проект, а всю рутинную работу выполняет Provisioning Server.

В схему могут вноситься изменения: добавление серверов, изменение конфигураций, замена моделей и т.п. В этом случае администратор просто загружает сохраненную схему комплекса, производит требуемые изменения и дает команду на переконфигурирование. Схема жизненного цикла системы на основе N1 Provisioning Server представлена на рис. 3.

N1 Provisioning Server изнутри

Архитектура системы на базе N1 Provisioning Server включает несколько уровней (рис. 4).

Уровень ресурсов включает в себя установленное и готовое к использованию серверное оборудование и системы хранения данных. Уровень связей — сетевая инфраструктура (как локальная сеть, так и сеть хранения), позволяющая организовывать виртуальные сети и имеющая возможности программной коммутации. Уровень управления отвечает за создание логических схем серверных комплексов и включает визуальное средство проектирования (Рис. 3) и языки логического описания создаваемых архитектур: Farm Markup Language (FML), Monitoring Markup Language (MML) и Wiring Markup Language (WML), основанные на XML. Ядром этого уровеня (и всего пакета N1 Provisioning Server) является программный инструментарий Infrastructure Director, обеспечивающее управление использованием ресурсов, виртуализацию и мониторинг, систему безопасности и верификацию схем соединений.

Развитием этой подсистемы будет ее интеграция со средствами управления ресурсами больших SMP-серверов и создание N1 Datacenter Provisioning Server.

Управление прикладными сервисами

В 2003 году в арсенале программных средств, входящих в состав N1, появилось средство управления прикладными сервисами N1 CenterRun.

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

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

Первым этапом работы с пакетом является сбор информации о приложениях (рисунок). Администратор указывает сервер, на котором размещена эталонная версия приложения, и параметры этого приложения. Следует отметить, что приложения, с которыми работает N1 CenterRun, должны быть построены по объектной модели (J2EE, COM/COM+, .NET) и работать в рамках одного из существующих серверов приложений (Sun Java System, BEA WebLogic, IBM WebSphere, Microsoft COM+).

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

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

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

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

Информация о приложениях хранится в виде метаданных в формате XML, что позволяет администратору расширять систему за счет добавления своих типов метаданных, скриптов и вызовов Java-процедур.

На сегодняшний день система поддерживает платформы Solaris 8 и 9, Windows 2000, RedHat 7.2, 7.3, Advanced Server 2.1 и AIX 4.3.3, 5.1, 5.2. n

Павел Анни (Pavel.Anni@sun.com ) — сотрудник московского представительства компании Sun Microsystems.