Конструктивные и технологические особенности

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

Система управления (администрирования) сервером основана на использовании внутрисерверных локальных сетей, узлами которых являются специальные элементы - процессоры поддержки FSP (Flexible Support Processors) [2.25]. В некоторых моделях они называются контроллерами каркасов CC (Cage Control). FCP построен на основе микропроцессора Power PC и подключен, с одной стороны - к внутренней сети сервера, а с другой - обеспечивает интерфейс SSI (subsystem interface) c управляемым модулем сервера. Интерфейс SSI определяется типом модуля и может состоять из нескольких последовательных интерфейсов и отдельных управляющих линий. Различные компоненты сервера содержат FCP, обеспечивая требуемую полноту контроля и управления сервером.

Структура системы управления сервером приведена на рис. 2.34. В системе используются две внутренние сети Ethernet, подключенные к основному и альтернативному элементам поддержки SE (Support Element). Оба элемента SE устанавливаются в шкафу Z, и активен всегда только один из них. Каждый SE реализован на ноутбуке ThinkPad и имеет два сетевых адаптера Ethernet или Token Ring для подключения к внутренним сетям. Возможно переключение SE с одной внутренней сети на другую. Процедуры управления сервером выполняются путем передачи из SE в FSP сообщений с командами для различных модулей сервера. FSP шаг за шагом выполняет требуемые операции с подключенным к нему модулем и формирует сообщение в SE с результатами выполнения команды.

Рис. 2.34. Система управления сервером

Элементы поддержки в свою очередь соединены с одной или несколькими внешними сетями Ethernet или Token Ring для подключения к консолям управления HMC (Hardware Management Consoles). Возможно удаленное подключение HMC. Консоль представляет собой рабочую станцию на основе ПЭВМ с операционной средой OS/2 и коммуникационным сервером, в которой исполняются приложения HMCA (HMC application), удаленного управления системами и др. Управление сервером обычно осуществляется через HMC путем передачи команд в элементы SE, в то же время при необходимости управление сервером может выполняться из любого SE. Одна консоль HMC может управлять до 100 SE, и каждый элемент SE может получать команды от 32 HMC.

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

HMC и SE обеспечивают выполнение следующих функций:

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

Изменения, связанные с восстановлением и конфигурированием, могут выполняться различными способами:

• фоновое (concurrent) восстановление или конфигурирование в рабочем состоянии системы без начальной загрузки IPL или сброса POR (Power-on Reset);
• изменения без IPL, POR, но с отключением каналов и изменением CHPID с последующим подключением;
• более сложные изменения, требующие IPL без POR для отдельных LPAR и запущенных в них операционных систем;
• выполнение POR для всей системы на относительно короткое время с последующим выполнением IPL для всех LPAR.
• ремонт или изменения, требующие отключения питания всей системы.

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

Процессоры серверов zSeries допускают конфигурирование загрузкой управляющих милликодов LIC-CC (LIC-Configuration Control). Каждый из процессоров, находящихся в MCM, может выполнять функции следующих типов процессоров.

• Центральный процессор CP (central processor) реализует систему команд z/Architecture и ESA/390. Он может быть отнесен к разделу LPAR и работать с операционными системами z/VM, z/OS, Linux, TPF и др. Совокупность всех CP сервера образуют CP pool, который может быть временно или постоянно расширен за счет настройки других PU.
• Процессор межсистемного взаимодействия ICF (Internal Coupling Facility) предназначен для реализации системного ПО Coupling Facility Control Code (CFCC), используемого при организации межсистемного обмена. ICF может быть включен только в LPAR, выделенный для реализации таких функций.
• Процессор Java приложений zSeries zAAP (zSeries Applications Assist Processor) ориентирован на эффективное исполнение Java-приложений под управлением IBM Java Virtual Machine (JVM).
• Сервисный процессор SAP (System Assist Processor) используется для управления операциями ввода-вывода путем исполнения милликодов канальной подсистемы. Один из SAP выделен в качестве Master SAP для реализации обменов между CEC, размещенными в модулях book, и элементом SE.
• Процессор поддержки LINUX IFL (Integrated Facility for Linux) оптимизирован для реализации операционной среды LINUX и ее приложений.

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

• Реконфигурация CUoD (Capacity Upgrade on Demand) выполняется путем добавления процессоров (загрузка милликодов), памяти и каналов ввода-вывода. Такой тип реконфигурации не ограничен по времени действия и выполняется сервисной службой IBM.
• Реконфигурация CIU (Customer Initiated Upgrade) позволяет увеличить количество процессоров и объем памяти по инициативе пользователя. Выполняется путем Web-запроса через IBM Resource Link в соответствии с предварительно оформленным контрактом и с использованием CUoD процедур.
• Реконфигурация On/Off CoD (On/Off Capacity on Demand) позволяет подключить дополнительные процессоры на любое заданное время и выполняется по CIU запросу при наличии соответствующего контракта. Такой вид реконфигурации может использоваться для преодоления пиковых нагрузок сервера.

Неплановая реконфигурация CBU (Capacity BackUp) предназначена для временного подключения процессоров CP в случае потери производительности вследствие аварийных ситуаций и не может быть использована для преодоления пиковых нагрузок сервера. Автоматическая реконфигурация CBU возможна при наличии резервных PU и разрешается после заключения контракта и загрузки в сервер специального кода.