Андрей Губенков, технический специалист System z, IBM Россия и СНГ

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

Уникальность решений

Бытует мнение, что наиболее правильный подход при построении крупных ЦОД на базе мэйнфреймов, особенно класса hi-end, – реализация универсальных, «коробочных» решений. Использовать мэйнфрейм для таких целей – все равно что отдать скрипку Страдивари для обучения в начальных классах музыкальной школы.

Все крупные ЦОД, построенные на мэйнфреймах, уникальны, они создаются под конкретных заказчиков и конкретный круг задач. В целом все такие ЦОД можно разделить на две большие группы: ЦОД, которые решают специализированные задачи, и ЦОД, предназначенные для массового обслуживания. К первой группе относятся дата-центры, где мэйнфреймы используются для развертывания специализированных систем, например банковских, систем бронирования, ERP и т. п. Для таких задач мэйнфреймы используются в силу того, что они способны обеспечить очень стабильную и высоконадежную вычислительную среду. В ЦОД второй группы мэйнфреймы применяются для консолидации тех или иных нагрузок. Например, для консолидации серверов, когда в качестве гипервизора используется операционная система z/VM, а в качестве гостевой системы – Linux. Такое решение позволяет развертывать сотни образов Linux на одной физической машине. Подобные структуры хорошо подходят для организации облачных вычислений.

Цена вопроса

Кто-то спросит: а разве нельзя построить близкую по классу обслуживания инфраструктуру на кластере х86? И разве не может Linux с тем же успехом работать на «персоналках»? Конечно, это возможно. Но вложить в такое решение придется никак не меньше средств, чем в мэйнфрейм. Да, мэйнфрейм требует изначально больших затрат, как и всякая техника класса hi-end. Но в долгосрочной перспективе затраты на ЦОД, построенный на любой другой платформе для тех же задач и с аналогичными параметрами, будут не ниже, а возможно, даже выше, чем затраты на ЦОД, работающий на мэйнфреймах.

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

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

Масштабируемость

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

Процессорная книга в составе мэйнфрейма enterprise-класса содержит так называемый Multi Chip Module (MCM) – большую интегральную микросхему, на которой находятся процессорные микросхемы, а также память, элементы диагностики, управления питанием и охлаждением. В каждой процессорной микросхеме имеется определенное количество процессорных ядер, доступных для работы на мэйнфрейме. Каждое ядро может иметь свое функциональное назначение: CP – универсальный процессор, Linux-процессор, процессор ввода-вывода, информационный сопроцессор, Java-сопроцессор и т. д. Поскольку все ядра имеют одну и ту же физическую основу, их функциональные роли задаются на уровне микрокода и опять-таки на уровне микрокода могут быть переназначены в зависимости от текущих потребностей заказчика.

Сегодня оба варианта масштабирования – и путем микрокодирования, и путем добавления процессорных книг – как правило, осуществляются без остановки работы системы.

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

Катастрофоустойчивость

Еще одно заблуждение возникло, когда на рынке были представлены кластерные решения на мэйнфреймах. Эти кластерные системы преподносились как одновременно решающие задачи и обеспечения высокой доступности (High Availability), и катастрофоустойчивости (Disaster Recovery). Многие поняли это буквально. Действительно, расстояние, на которое можно разнести мэйнфреймы, может достигать 100 км и более. Но не надо забывать про каналы связи. Нагрузка на сеть, которая связывает узлы кластера, такова, что справиться с ней можно только при длине кабелей не более 10, в редких случаях до 20 км.

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

Уменьшить стоимость катастрофоустойчивого решения позволяет предложение IBM Capacity Backup Upgrade (CBU). На резервной машине активируются минимальные ресурсы, но в случае катастрофы в течение 90 дней ее можно использовать в той же конфигурации, что и основную машину. Причем без изменения платы за лицензии на программное обеспечение от IBM. В целях тестирования плана аварийного восстановления эту опцию можно включать на десять дней до десяти раз. Предложение CBU может заключаться на срок от одного до пяти лет с возможностью продления. На Западе такая возможность активно и успешно используется.

Жизненный цикл

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

Как правило, сначала объявляются модели enterprise-класса. Примерно через год выходит модель бизнес-класса. От enterprise-класса она отличается меньшим количеством ресурсов и внутренних шин. В машинах enterprise-класса используется гибридное охлаждение, в решениях бизнес-класса – обычно только воздушное.

После того как очередная модель снимается с продажи, у заказчиков в течение года есть возможность модернизировать ее с помощью микрокода. У IBM есть такое правило: модели до поколения N–2 могут быть модернизированы до поколения N с сохранением серийного номера, учета амортизации и пр. Среди заказчиков распространена практика – шаг через поколение. Это обеспечивает приемлемое время работы одного мэйнфрейма и позволяет сохранять преемственность в части операционных систем.

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

Сегодня IBM предлагает модели zEnterprise EC12 и zEnterprise ВC12 (enterprise и бизнес-класса соответственно). Их предшественниками были zEnterprise z196 (enterprise-класс) и zEnterprise 114 (бизнес-класс) и IBM System z10 (enterprise- и бизнес-класс). Таким образом, в enterprise-классе возможна модернизация IBM zEnterprise 196 до zEC12 и IBM System z10 Enterprise Class до zEC12.

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

Следите за нашими новостями в Телеграм-канале Connect


Поделиться:



Следите за нашими новостями в
Телеграм-канале Connect

Спецпроект

Медицинские задачи для ИИ

Подробнее
Спецпроект

Цифровой Росатом

Подробнее


Подпишитесь
на нашу рассылку