Компьютер из сети

Павел Анни

Начиная с далекого 1987 года компания Sun повторяет свою мантру: "Сеть - это компьютер". Тогда и сетей-то никаких не было, если посмотреть с нынешней технологической высоты. А вот ведь - случилось! Незаметно так случилось, что сегодня компьютер без сети уже ничем, кроме игрушки, служить не может. Хоть к базе данных, хоть к Яндексу, хоть к почтовому серверу доступ иметь надо, иначе что это за жизнь?

Сделать сеть такой же, как компьютер - эту задачу поставили перед собой разработчики в Sun Microsystems на ближайшие 5-7 лет. Такой же управляемой, такой же масштабируемой, такой же цельной, как компьютер. И даже лучше.

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

Возрастание сложности

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

При этом нельзя сказать, что эта нагрузка ложится на оборудование - исследования показывают, что в среднем вычислительные системы загружены на 10-15 процентов. Нагрузка в основном ложится на людей.

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

Новое слово - N1

Разработчики в Sun Microsystems решили при подходе к этим проблемам опираться на тот опыт и технологический задел, который был накоплен при разработке больших серверов и операционной среды Solaris. В самом деле, в этих системах уже решены вопросы динамического управления ресурсами, защиты от сбоев, контроля доступа, мониторинга и диагностики. Имея такой запас технологий, компания наметила для себя пути дальнейших исследований, разработок и инвестиций. Эта стратегия была названа N1 (Network-1) и объявлена осенью 2002 года, а уже в феврале нынешнего, 2003 года появились первые продукты в этом направлении.

Идеи N1

От коробок - к сервисам. Имея за плечами опыт эксплуатации больших комплексов в сотни машин, разработчики технологий N1 стремятся по возможности свести управление самими серверами, дисковыми массивами и сетевым оборудованием к рутинным процедурам, поддающимся автоматизации. Именно этот шаг, от искусства к промышленной технологии, должен дать возможность управлять вычислительным центром не с точки зрения систем, а с точки зрения прикладных сервисов, которые он предоставляет. Именно этот шаг можно считать началом эпохи индустриализации в информационных системах. Вспомните, индустриализация в промышленном производстве началась тогда, когда стало возможным четко разделить производственный процесс на отдельные этапы и механизировать их. Продолжая аналогию, можно говорить об информационном конвейере, когда потребитель видит только конечный продукт: информационный сервис, а вся технология создания этого продукта автоматизирована и скрыта от него. Главная цель, которую ставят перед собой разработчики в Sun - переход от управления каждой системой в отдельности к управлению информационными сервисами. Управление же оборудованием информационных систем должно быть автоматизировано и переложено с плеч системного администратора на "управляющую шину вычислительного комплекса".

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

Виртуализация системных ресурсов. Один из лучших способов управления сложными системами - повышение уровня абстракции, укрупнение компонентов. В применении к вычислительным комплексам можно говорить о виртуализации ресурсов: вычислительных, сетевых, систем хранения. По существу, если информационный сервис разработан "правильно", то он не привязан к каким-то определенным конфигурациям, адресам, именам, архитектурам. В таком случае у нас появляется возможность говорить не о том, что для выполнения данного сервиса требуется 8-процессорный сервер с операционной системой такой-то версии, а определенное количество виртуальных вычислительных ресурсов. Точно так же происходит и виртуализация систем хранения данных: мы уже не говорим о том, что нужно подключить 12 дисков по 36 ГБ и организовать на них RAID 1+0, а определяем необходимое пространство в гигабайтах и требуемый уровень производительности и защищенности.

Структура приложений. Как работают приложения сегодня? Обычной практикой является политика "каждому приложению - свой набор серверов". Так спокойнее: разные модули не будут конфликтовать между собой, не будут конкурировать за ресурсы. В результате - серверы загружены по принципу "то густо, то пусто", не давая достаточной производительности и эффективности использования. Что, если "разобрать" приложения на уровни, и отсортировать их по принципу: базы данных к базам данных, серверы приложений к серверам приложений. Имея виртуализированную вычислительную среду, администратор сети может выделять ресурсы из общего пула в зависимости от потребностей приложений: "столько-то единиц производительности сервера баз данных".

Управление согласно политике. Когда ресурсы виртуализированы, приложения не привязаны к конкретному серверу, а рутинное управление переложено на "Системную Шину N1", администратор может заняться заданием политик использования сервисов с тем, чтобы перейти от ручного распределения ресурсов к автоматизированному. В результате возможно будет реализовать систему, где, в зависимости от приоритетов приложений выделяются и освобождаются необходимые вычислительные ресурсы, гарантируется необходимая производительность для критических приложений, но при этом не выделяются излишние ресурсы "про запас". В результате средняя загрузка (эффективность использования) серверов поднимается до уровня 60-80% (цель, поставленная разработчиками N1), при сохранении требуемого времени отклика, производительности и надежности.

Логика развития

Главная особенность объявленной стратегии N1 - то, что большинство технологий уже много лет используются в больших серверах Sun Microsystems. Фактически, разработчики распространяют основные идеи и наработки с уровня серверов на уровень всей системы. Эти технологии включают в себя: массовое многопроцессорное масштабирование, управление ресурсами, динамическую реконфигурацию, конфигурирование, мониторинг и диагностику компонентов, обеспечение высокой готовности и многое другое.

Массовое масштабирование

История развития многопроцессорных систем в Sun Microsystems насчитывает около 15 лет. За эти годы совершенствовалась архитектура центральной шины (впоследствии ставшей коммутатором), процессоров, технологий управления кэш-памятью и оперативной памятью. Параллельно с развитией аппаратной части совершенствовалась операционная система Solaris, включающая поддержку все большего числа процессоров в симметричной архитектуре (сегодня это число доведено до 128), многопотоковую архитектуру, планировщик процессов, поддержку процессов реального времени.

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

Примером такого планировщика, предназначенного для управления пакетными заданиями в вычислительных сетях, является система Sun Grid Engine. Этот пакет позволяет ставить задания в очередь на выполнение, задавать приоритеты, и выполнять эти задания на машинах, включенных в сеть, в зависимости от их загруженности. Коммерческий вариант этого ПО, Sun Grid Engine Enterprise Edition, имеет возможность задания политик использования ресурсов, в соответствии с которыми узлы сети "рассчитываются" между собой: дают свободные ресурсы взаймы, чтобы потом получить их, когда будет потребность.

Управление ресурсами

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

Динамические домены. Эта технология была впервые реализована в 1997 году в сервере Sun Enterprise 10000. С того момента было поставлено свыше 5000 таких серверов, и в большинстве случаев одим из решающих факторов выбора для клиентов была возможность разделения машины на независимые системные домены и возможность динамически, без остановки приложений на них, "двигать" границы доменов, передавая процессоры, память, каналы ввода/вывода от одного домена другому. Такая технология дала возможность перераспределять ресурсы системы в зависимости от нагрузки: в конце квартала больше ресурсов отдавать системе подготовки отчетов, а в период внедрения новой версии ПО организовывать отдельный домен для обучения пользователей. Динамические домены оказались настолько востребованными, что были реализованы в следующем поколении серверов даже на уровне моделей среднего класса (Sun Fire 3800-6800).

Контейнеры Solaris. Помимо доменов, есть инструмент более "тонкого" управления ресурсами: контейнеры Solaris. Эта технология дает возможность администратору выделять отдельным приложениям вполне определенное количество процессорного времени, каналов ввода/вывода, оперативной памяти. Контейнеры, с одной стороны, не имеют такой степени изолированности, как домены (это не отдельные образы операционной системы), но с другой стороны, позволяют изменять вычислительные ресурсы приложения не ступенями по 4 процессора (системная плата Uniboard), а гораздо более плавно.

Процессорные группы. Наконец, самым простым способом управления ресурсами является возможность привязки процессов (задач) к процессорным группам. Такая возможность Solaris позволяет гарантировать определенное количество вычислительных ресурсов отдельным приложениям и может быть полезным, когда есть необходимость к определенному сроку выполнить какую-то задачу (расчет, моделирование и т.п.).

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

Динамическая реконфигурация

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

Другой, не менее важный случай: на системной плате вышел из строя банк памяти. Разумеется, сервер это диагностирует, даст команду на перезагрузку, произведет изолирование сбойного блока и продолжит работу с оставшимися ресурсами. Но что делать, когда системный администратор получит со склада блок памяти для замены? Останавливать приложения, базу данных, сервер? Незачем! Плата выводится из активной работы (с нее снимаются процессы, очищается память), вынимается из работающей системы, в ней производится замена банка памяти, и администратор снова вставляет плату в сервер. Сервер опознает плату и подключает к системе. Приложение снова может ее задействовать. Ни минуты простоя!

Подобные потребности имеются и в сети N1: шина должна иметь возможность опознавать оборудование (серверы, дисковые массивы, сетевые коммутаторы), имеющееся в сети, и подключать его к набору доступных вычислительных ресурсов. Разумеется, без остановки, без перезагрузки, без перерывов в обслуживании. Тогда при необходимости любое расширение системы для повышения мощности, увеличения емкости хранения, будет происходить "на ходу", без рутинных административных процедур.

Высокая готовность

Серверы ненадежны, диски ломаются, приложения сбоят. Не так важно, что компоненты иногда выходят из строя, важно, что правильно спроектированная система должна быть устойчивой к подобным сбоям, не допускать простоев приложений в подобных ситуациях. Sun сделал много значительных шагов в этом направлении: внутренняя диагностика, анализ состояния, база знаний по возможным сбоям, Sun Cluster, дублированные интерфейсы дисков и локальных сетей. Недавно в этим системным средствам добавились и средства обеспечения готовности на уровне приложений: Sun ONE Application Server Enterprise Edition с технологией Clustra. Все это позволяет добиться того, что любые сбои оборудования будут "прозрачны" для пользователя.

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

Системы для людей

Ночные смены, выходные, проведенные на работе, авральные вызовы, постоянно пищащий пейджер у сисадмина - уже не люди эксплуатируют системы, а системы эксплуатируют людей. Пора что-то менять. Sun отвечает: N1 - системы для людей.

Банковские технологии, #3, 1 марта 2003

Старт русской версии StarOffice 6.0 от Sun Microsystems

Ирина Орехова

26 февраля 2003г. Компания Sun Microsystems объявила о выпуске русской версии многоплатформенного офисного пакета StarOffice 6.0. На презентации выступили Сергей Тарасов, глава представительства Sun Microsystems в СНГ, и председатель совета директоров группы компаний "АйТи" Тагир Яппаров. StarOffice 6.0 основан на XML-формате. Пакет является офисным компонентом платформы Sun ONE для веб-сервисов. По словам Тагира Яппарова, сотрудничество двух компаний не ограничится разовой локализацией офисного пакета.

Банковские технологии, #3, 1 марта 2003