Сетевые вычислительные центры

Почему опять ВЦ?

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

Кадры решают все

Уследить за тем, кто и как устанавливает и эксплуатирует серверы в сети, где есть хотя бы 300-400 рабочих мест, без специальных усилий невозможно. Надеяться на то, что каждый из файловых серверов в отделах и группах будет поддерживать специалист с сертификатом MCSE, совершенно не приходится. Поэтому рано или поздно крупные организации объединяют поддержку информационных систем не только организационно, но и физически, организуя (или возрождая) настоящий вычислительный центр. В таких условиях становится гораздо выгоднее обеспечить серьезной и интересной работой нескольких высококлассных специалистов, чем содержать огромный штат "начинающих администраторов" на рутинных задачах.

Опись, протокол...

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

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

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

Защита от всего

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

Данные. Единое хранилище данных, набор дисковых массивов, взаимно дублирующих друг друга, горячее резервирование дисков, моментальные снимки данных - это "быстрая" защита. Эти меры распространяются на самые важные данные, доступ к которым нельзя потерять ни на минуту.

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

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

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

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

Что значит - сетевые?

О "возвращении вычислительных центров" говорят уже не первый год. Откуда же появилось определение "сетевые" и что оно означает? Чем сетевой вычислительный центр отличается от "обычного" (как тут не вспомнить рекламу?) и чем сетевой вычислительный центр отличается от простого Web-сайта в Сети? Отметим два важнейших свойства - универсальность и непрерывность.

Универсальность

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

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

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

И здесь, однако, не обошлось без проблем. Войны между производителями браузеров привели к тому, что каждый из них начал создавать свои "стандарты" и расширения, стремясь привлечь пользователей и разработчиков на свою сторону. В результате стали появляться Web-приложения и сайты с надписями "Работает только под Microsoft Internet Explorer". По-настоящему универсальное сетевое приложение должно быть доступно пользователю независимо от типа браузера (ведь недалеко то время, когда заметная часть пользователей будет работать с сетевыми приложениями через Palm или Sony PlayStation).

Непрерывность

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

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

Так возникла идея соединения надежности традиционного вычислительного центра и универсальности сетевого доступа к приложениям. Какие новые требования предъявляет Сеть к надежности и готовности вычислительного центра?

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

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

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

Универсальность и непрерывность - это основополагающие требования при разработке архитектуры и решений для сетевых вычислительных центров. Некоторые стратегии и технологии, используемые компанией Sun Microsystems (http://www.sun.ru), изложены ниже.

Архитектура

Функциональные уровни

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

Сетевая природа добавила к трехуровневой архитектуре:

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

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

Кластеризация

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

Динамические домены

С развитием динамических системных доменов (CS6400 в 1994 году, Enterprise 10000 - в 1997-м, линия Sun Fire в 2001 году) стало возможным более полно задействовать ресурсы больших серверов. Если раньше средняя загрузка UNIX-серверов составляла 25-30% и проектировщики вынуждены были оставлять значительный запас в расчете на пиковые нагрузки, то наличие динамических доменов позволяет более полно загружать вычислительные мощности, "передавая" системные платы из одного домена в другой в случае возрастания нагрузки в каком-либо из приложений.

Solaris Resource Manager

Внутри отдельного домена ресурсы перераспределяются более "тонким" образом с помощью программного пакета Solaris Resource Manager. Этот пакет позволяет выделять доли процессорной мощности, виртуальной памяти, каналов ввода-вывода как отдельным приложениям, так и отдельным пользователям или группам пользователей.

Мониторинг и управление

Работа вычислительного центра невозможна без контроля за использованием ресурсов, анализа загрузки, планирования развития системы. Вычислительные центры, построенные на базе серверов Sun Microsystems, работают под управлением программного пакета Sun Management Center. Этот продукт позволяет централизовать мониторинг всех компонентов вычислительного центра (от серверов до маршрутизаторов и баз данных), обеспечить сигнализацию об ошибках и предупреждение критических ситуаций. Специальная база знаний, накопленная в процессе эксплуатации многих подобных серверов, позволяет предсказывать возможные сбои по сочетанию нескольких факторов (например, "загрузка процессоров в течение 40 минут превышает 90% И длина очереди к диску превышает 8 запросов").

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

Серверы приложений

Необходимо сказать несколько слов о программной части сетевых вычислительных центров (хотя это тема для отдельной статьи). Термин "серверы приложений" за последние 5-10 лет претерпел значительные изменения. Еще несколько лет назад так называли системы, построенные на базе мониторов транзакций (Tuxedo, Encina). Они были достаточно сложны в проектировании и разработке (для Tuxedo коды необходимо было писать на языке C, пользуясь его библиотеками), но результат оправдывал вложенные средства - системы получались сверхпроизводительными и надежными. На сегодняшний день к требованиям производительности и надежности добавились требования скорости разработки и модификации систем, а также переносимости между платформами. Естественным выбором для построения современных серверов приложений стал язык Java и компонентная модель Java Beans.

Современные серверы приложений (iPlanet, Oracle, BEA Weblogic и другие) представляют собой среду для исполнения компонентных приложений, написанных в соответствии с моделью Java Beans. Сервер приложений полностью берет на себя вопросы управления очередями запросов, балансом загрузки, миграцией между узлами и т.п. Кроме того, использование компонентной модели позволяет достаточно легко "собирать" новые приложения из имеющихся блоков. Использование языка Java гарантирует переносимость как серверной, так и клиентской части между платформами, а также работу приложений через стандартный Web-браузер.

Свой собственный провайдер

Рассмотренные технологии могут применяться не только для построения службы аренды приложений (ASP, Application Service Providing). Подавляющее большинство вычислительных центров в ближайшее время не будет открывать всем желающим доступ к своим ресурсам через Интернет. Но подходы и технологии, а самое главное, требования, используемые при построении сетевых вычислительных центров, вполне применимы и для информационных систем, использующих интранет-технологии. Сегодня одна из интересных моделей взаимодействия отдела автоматизации со своими пользователями - это модель внутреннего сервис-провайдера для своей организации. Такой подход позволяет максимально ясно определить взаимные обязанности и ответственность и значительно повышает общую надежность функционирования информационной системы. Однако это вновь тема для отдельной статьи.

С автором статьи можно связаться по электронной почте: Pavel.Anni@sun.com