Переход с мейнфреймов в Azure
В качестве альтернативной платформы для выполнения приложений, традиционно работающих на мейнфреймах, Azure предлагает гипермасштабируемые ресурсы для вычислений и хранения в среде с высоким уровнем доступности. Вы получите все возможности и гибкость современной облачной платформы без затрат, связанных с использованием среды мейнфрейма.
Эта статья содержит технические рекомендации по переходу с мейнфреймов в Azure.
MIPS и виртуальные ЦП
Не существует универсальной формулы, позволяющей определить необходимое количество виртуальных ЦП для запуска рабочих нагрузок мейнфреймов. Но в качестве базовой метрики один миллион команд в секунду (MIPS) часто сопоставляется с виртуальными ЦП в Azure. MIPS измеряет общую вычислительную мощность мейнфрейма путем сравнения с постоянным значением числа циклов в секунду для определенного компьютера.
Небольшой организации будет достаточно не более 500 MIPS, а крупные организации обычно используют более 5000 MIPS. При цене в 1000 долл. США за единицу MIPS крупная организации расходует ежегодно около 5 миллионов долл. США на развертывание инфраструктуры мощностью 5000 MIPS. Оценка ежегодных затрат на типичное развертывание Azure такого масштаба составляет примерно одну десятую от стоимости инфраструктуры MIPS.
Точное сопоставление MIPS с виртуальными ЦП в Azure зависит от типа виртуальных процессоров и характера выполняемой рабочей нагрузки. Тесты производительности дают неплохую основу для оценки количества и типа необходимых виртуальных ЦП. Недавний тест HPE zRef дал следующие результаты:
288 MIPS на одно ядро Intel, выполняемое на серверах HP Proliant для онлайн-заданий (CICS).
170 MIPS на одно ядро Intel для пакетных заданий COBOL.
В этом руководстве используется оценка в 200 MIPS на один виртуальный ЦП для обработки в сети и 100 MIPS на один виртуальный ЦП для пакетной обработки.
Примечание.
Эти оценки могут измениться, как только новая серия виртуальных машин станет доступна в Azure.
Высокий уровень доступности и отработка отказа
Системы мейнфреймов часто предлагают доступность на уровне пяти девяток (99,999 %) при использовании взаимозависимости мейнфреймов и Parallel Sysplex. Но системным операторам все равно придется запланировать время простоя для обслуживания и начальной загрузки программ (IPL). Фактический уровень доступности будет на уровне двух или трех девяток, что вполне сравнимо с мощными серверами на основе Intel.
Для сравнения: Azure предлагает соглашения об уровне обслуживания на основе обязательства (SLA), где по умолчанию гарантируются несколько девяток для уровня доступности с оптимизацией для локальной или географической репликации служб.
Azure дополнительно повышает уровень доступности за счет репликации данных из нескольких устройств хранения локально или в другой географический регион. В случае сбоя на платформе Azure вычислительные ресурсы смогут обратиться к реплицированным данных на локальном или региональном уровне.
Если используются ресурсы Azure PaaS (платформа как услуга), например База данных SQL Azure или база данных Azure Cosmos, Azure автоматически выполняет отработку отказа. При использовании инфраструктуры IaaS Azure отработка отказа зависит от определенных системных функций, например SQL Server Always On, экземпляров отказоустойчивого кластера и групп доступности.
Масштабируемость
Для мейнфреймов обычно используется вертикальное увеличение масштаба, для облачных сред — горизонтальное увеличение масштаба. Для мейнфреймов горизонтальное масштабирование реализуется с помощью раздела обеспечения взаимодействия (CF), но высокая стоимость оборудования и хранилища делает горизонтальное масштабирование мейнфреймов невыгодным.
Кроме того, раздел обеспечения взаимодействия предлагает тесно связанные вычислительные ресурсы, а функции горизонтального масштабирования Azure используют слабую связь. Облако можно масштабировать для точного соответствия пользовательским спецификациям, предоставляя нужный объем вычислительной мощности, хранилища и служб с оплатой по мере использования.
Резервное копирование и восстановление
Клиенты мейнфреймов обычно поддерживают сайты аварийного восстановления или привлекают независимых поставщиков мейнфреймов для аварийных ситуаций. Синхронизация с сайтом аварийного восстановления обычно осуществляется через копирование данных в автономном режиме. Оба варианта приводят к большим затратам.
Раздел обеспечения взаимодействия мэйнфреймов позволяет также создать автоматическую геоизбыточность. Этот подход является дорогостоящим и обычно применяется только для критически важных систем. Напротив, Azure предлагает простые и выгодные возможности резервного копирования, восстановления и избыточности на локальном или региональном уровнях, а также географическую избыточность.
Хранилище
Для хорошего понимания работы мейнфреймов важно различать несколько близких по значению терминов. Например, центральное хранилище, реальная память, реальное хранилище и основное хранилище обычно обозначают хранилище, подключенное напрямую к процессору мейнфрейма.
Оборудование мейнфреймов включает процессоры и многие другие устройства, например запоминающие устройства с прямым доступом (DASD), накопители на магнитной ленте и несколько видов пользовательских консолей. Магнитные ленты и DASD используются для системных функций и пользовательских программ.
Для мейнфреймов используются следующие типы физического хранилища:
- Центральное хранилище. Расположено прямо в процессоре мейнфрейма. Также это хранилище называют процессорным или реальным хранилищем.
- Дополнительное хранилище. Хранилища такого типа располагаются отдельно от мейнфрейма, и к ним относятся хранилища на DASD. Также их называют хранилищами страниц.
В облаке предлагается несколько гибких и масштабируемых вариантов, при этом оплачивать вы будете только те, которые используются. В службе хранилища Azure предоставляется хранилище с высокой масштабируемостью для объектов данных, служба файловой системы для облака, надежное хранилище сообщений, а также хранилище NoSQL. Для виртуальных машин управляемые и неуправляемые диски предоставляют постоянное и безопасное дисковое хранилище.
Разработка и тестирование мейнфреймов
Важной причиной для переноса приложений с мейнфреймов будет изменение процесса разработки приложений. Организациям нужно, чтобы среда разработки стала более гибкой и быстрее реагировала на потребности бизнеса.
Мейнфреймы обычно имеют отдельные логические разделы (LPAR) для разработки и тестирования, например логический раздел для контроля качества и промежуточный логический раздел. Решения разработки для мейнфреймов содержат компиляторы (COBOL, PL/I, Assembler) и редакторы. Самым распространенным решением является ISPF (Interactive System Productivity Facility — средство для производительности интерактивной системы) для операционной системы z/OS, которая работает на мейнфреймах IBM. Также широко применяются RPF (ROSCOE Programming Facility — программное средство ROSCOE) и средства Computer Associates, такие как CA Librarian и CA-Panvalet.
Компиляторы и среды эмуляции доступны для 32-разрядных платформ, поэтому разработка и тестирование обычно становятся первыми рабочими нагрузками, переносимыми с мейнфреймов в Azure. Доступность и широкое распространение средств DevOps в Azure ускоряют процесс миграции сред разработки и тестирования.
Когда решения будут разработаны и протестированы в Azure, для развертывания на мейнфрейме потребуется скопировать код на мейнфрейм и скомпилировать его.