Производительный отказоустойчивый географически разнесенный кластер, работающий по схеме Active-Active на мейнфрейме IBM zEnterprise EC 12

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

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

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

    Проблемы при построении географически разнесенного кластера, работающего по схеме Active-Active



    Условно проблемы при построении любого кластера Active-Active можно разделить на проблемы кластеризации прикладного приложения и проблемы кластеризации СУБД/подсистемы очередей сообщений. Например, для тестируемого нами приложения существовало требование строгого соблюдения порядка исполнения платежей от одного участника. Понятно, что обеспечение выполнения данного требования в кластерном режиме Active-Active привело к необходимости внесения существенных изменений в архитектуру приложения. Проблема усугублялась тем, что помимо производительности в режиме Active-Active, было необходимо обеспечить высокую доступность стандартными средствами программного обеспечения промежуточно слоя или операционной системы. Подробности того, как мы добились поставленных целей, достойны отдельной статьи.

    Современные подходы к кластеризации СУБД обычно базируются на архитектуре shared disk. Основной задачей при таком подходе является обеспечение синхронизируемого доступа к разделяемым данным. Детали реализации сильно зависят от конкретной СУБД, но наиболее популярным является подход, основанный на обмене сообщениями между узлами кластера. Такое решение является чисто программным, прием и отправка сообщений требует прерывания работы приложений (обращения к сетевому стеку операционной системы), так же при активном доступе к разделяемым данным накладные расходы могу стать существенными, что особенно проявляется в случае увеличения расстояния между активными узлами. Как правило, коэффициент масштабируемости таких решений не превышает ¾ (кластер из четырех узлов, каждый из которых имеет производительность N, обеспечивает суммарную производительность ¾ N).

    В случае удаленности друг от друга узлов кластера существенное влияние на производительность и допустимое время восстановления (RTO) решения оказывает расстояние. Как известно, скорость света в оптике составляет примерно 200 000 км/с, что соответствует задержке в 10 мкс на каждый километр оптоволокна.

    Подход, применяемый в мейнфреймах IBM



    В мейнфреймах IBM для кластеризации СУБД DB2 и менеджеров очередей WebSphere MQ применяется иной подход, не основанный на программном обмене сообщениями между узлами кластера. Решение называется Parallel Sysplex и позволяет объединять в кластер до 32 логических разделов (LPAR), работающих на одном или нескольких мейнфреймах под управлением операционной системы z/OS. Если учесть, что новый мейнфрейм z13 может иметь на борту более 140 процессоров, то максимальная достижимая производительность кластера не может не впечатлять.

    Основой Parallel Sysplex является технология Coupling Facility, представляющая собой выделенные логические разделы (LPAR), использующие процессоры, которые могут выполнять специальное кластерное программное обеспечение – Coupling Facility Control Code (CFCC). Coupling Facility в своей памяти хранит структуры общих данных, совместно используемые узлами кластера Parallel Sysplex. Обмен данными между CF и подключенными системами организуется по принципу «память-память» (похоже на DMA), при этом процессоры, на которых работают приложения, не задействуются.

    Для обеспечения высокой доступности структур CF используются механизмы синхронной и асинхронной репликации данных между ними средствами операционной системы z/OS и СУБД DB2.

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

    Нагрузочное тестирование кластера



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

    В качестве стенда для проведения испытаний использовался один физический сервер zEnterprise EC 12. На данном сервере было развёрнуто два логических раздела (LPAR) MVC1 и MVC2, каждый из которых работал под управлением операционной системы z/OS 2.1 и содержал по 5 процессоров общего назначения (CP) и 5 специализированных процессоров zIIP, предназначенных для исполнения кода СУБД DB2 и работы Java-приложений. Данные логические разделы были объединены в кластер с использованием механизма Parallel Sysplex.

    Для работы механизма Coupling Facility использовались выделенные логические разделы (LPAR) CF1 и CF2, содержащие по 2 процессора ICF. Расстояние между CF1 и CF2 по каналам связи по сценарию тестирования дискретно менялось, находясь в пределах от 0 до 70 км.

    Подключение MVC1 к CF1 осуществлялось посредством виртуальных каналов типа ICP, в то время как для доступа к CF2 использовались физические каналы типа Infiniband. Подключение MVC2 к CF1 и CF2 осуществлялось аналогично: посредством ICP каналов к CF2 и с помощью Infiniband к CF1.

    Для хранения данных использовался дисковый массив IBM DS 8870, в котором были созданы два набора дисков и настроена синхронная репликация данных между ними с помощью технологии Metro Mirror. Расстояние между наборами дисков по каналам связи по сценарию тестирования дискретно менялось, находясь в пределах от 0 до 70 км. Необходимое расстояние между компонентами стенда обеспечивалось путем применения специализированных устройств DWDM (ADVA) и оптоволоконных кабелей необходимой длины.

    Каждый из логических разделов MVC1 и MVC2 подключался к дисковым массивам с помощью двух каналов FICON, имеющих пропускную способность 8 GB/s.

    Детальная схема стенда (в варианте с расстоянием между узлами кластера 50 км.) представлена на рисунке.



    В качестве тестового приложения на узлах кластера была развернута банковская платежная система, использующая для своей работы следующее программное обеспечение IBM: СУБД DB2 z/OS, менеджеры очередей сообщений WebSphere MQ, сервер приложений WebSphere Application Server for z/OS.

    Работы по настройке тестового стенда и установке платежной системы заняли примерно три недели.

    Отдельно следует рассказать о принципе работы приложения и профиле нагрузки. Все обрабатываемые платежи можно разделить на два типа: срочные и несрочные. Срочные платежи проводятся сразу же после их считывания из входной очереди. В процессе же обработки несрочных платежей можно выделить три последовательные фазы. Первая фаза – фаза приема – платежи считываются из входной очереди системы и регистрируются в базе данных. Вторая фаза – фаза многостороннего взаимозачета – запускается по таймеру несколько раз в сутки и выполняется строго в однопоточном режиме. На данной фазе осуществляется проводка всех принятых до этого несрочных платежей, при этом учитываются взаимные обязательства участников системы (если Петя переводит 500 рублей Васе и 300 рублей Свете, а Вася – 300 рублей Свете, то есть смысл сразу увеличить значение счета Светы на 600 рублей, а Васи – на 200 рублей, чем выполнять реальные проводки). Третья фаза – фаза рассылки уведомлений – запускается автоматически после завершения второй фазы. На данной фазе осуществляется формирование и рассылка информационных сообщений (квитанций) для всех участвующих в многостороннем взаимозачете счетов. Каждая фаза представляет собой одну или нескольких глобальных транзакций, представляющих собой сложную последовательность действий, выполняемых менеджерами очередей WebSphere MQ и СУБД DB2. Каждая глобальная транзакция завершается двухфазной фиксацией (commit), т.к. в ней участвуют несколько ресурсов (очередь – база данных – очередь).

    Важной особенностью платежной системы является способность проводить срочные платежи на фоне многостороннего взаимозачета.
    Профиль нагрузки при проведении испытаний повторял профиль нагрузки реально работающей системы. На вход подавалось 2 млн. несрочных платежей, объединенных в пакеты по 500/1000/5000 платежей, каждому пакету соответствовало одно электронное сообщение. Данные пакеты подавались на вход системы с интервалом 4 мс между поступлением каждого следующего сообщения. Параллельно подавалось около 16 тыс. срочных платежей, каждому из которых соответствовало свое электронное сообщение. Данные электронные сообщения подавались с интервалом 10 мс. между поступлением каждого следующего сообщения.

    Результаты нагрузочного тестирования



    При проведении нагрузочного тестирования расстояние по каналам связи между наборами дисков, а также между логическими разделами CF дискретно менялось, находясь в пределах от 0 до 70 км. При выполнении тестов были зафиксированы следующие результаты:



    Интересно сравнить первые две строчки, показывающие масштабируемость системы. Видно, что время выполнения первой фазы при использовании кластера из двух узлов сокращается в 1.4 раза («нелинейность» масштабирования первой фазы объясняется особенностями реализации требования по соблюдению порядка платежей от одного участника), а время выполнения третьей фазы – практически в 2 раза. Многосторонний взаимозачет выполняется в один поток. Время его проведения в кластерном режиме увеличивается из-за необходимости пересылки блокировок DB2 в CF при выполнении массовых операций DML.

    При включении механизма репликации данных на дисках (Metro Mirror) время выполнения каждой фазы увеличивается незначительно, на 3 – 4%. При дальнейшем росте расстояния по каналам связи между дисками и между логическими разделами CF время выполнения каждой фазы растет более интенсивно.

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



    Максимальное время обработки платежа выросло на 40%, при этом среднее изменилось всего на 7.6%. При этом утилизация процессорного ресурса изменяется незначительно за счет увеличения времени доступа к структурам CF.

    Выводы



    В статье мы рассмотрели проблемы, возникающие при построении географически распределенного кластера, работающего в режиме Active-Active, и выяснили каким путем можно их избежать, построив кластер на основе мейнфреймов IBM. Утверждения о высокой масштабируемости решений на основе кластера Parallel Sysplex продемонстрированы результатами нагрузочного тестирования. При этом мы проверили поведение системы при различном расстоянии между узлами кластера: 0, 20, 50 и 70 км.

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

    Если тема построения географически разнесенного кластера мейнфреймов вызовет интерес у хабражителей, то в следующей заметке мы подробно расскажем о проведенных испытаниях высокой доступности системы и полученных результатах. Если вам интересны другие вопросы, касающиеся мейнфреймов, или вы хотите просто поспорить, то добро пожаловать в комментарии. Так же будет полезно, если кто-нибудь поделится своим опытом построения отказоустойчивых решений.
    IBM 83,75
    Компания
    Поделиться публикацией
    Комментарии 19
    • 0
      Интересно сколько всего бывает инсталяций этого железа в описанной конфигурации. Все интересно, но звучит как что-то очень специализированное
      • 0
        Упомянутые кластерные конфигурации применяются там, где нужна высочайшая доступность сервисов, в освновном конечно в банковской сфере, в страховых компаниях, ритейл, резервирование авиабилетов, но бывают инсталляции и для правительственных нужд, промышленных компаний. Решение отличается высочайшей зрелостью, технологии Parallel Sysplex уже практически четверть века и мало какое кластерное решение может похвастаться таким сроком жизни и развития.

        Если говорить о конкретных заказчиках, то можно отметить ФРС США, Banco do Brasil S.A, некоторые китайские и европейские банки, американские электрические компании.

        По российским заказчикам дать информацию не могу по соображениям коммерческой тайны, прошу прощения.
      • 0
        В РАО ЕЭС России такое есть и в Сбере, вроде.
        • +1
          вот и вся коммерческая тайна
          • +1
            В Сбере разве не пешки?
          • 0
            ПО «банковская платежная система» случаем не компании Montran?

            Выполнялись ли в этой конфигурации нагрузочные тесты с непрерывной подачей платежных документов?
            • 0
              Нет, тестируемая платежная система была не от компании Montran.

              Что касается самого теста, 4 мс. паузы практически не влияли на загрузку ресурсов машины, которая была близка к 100% на нулевом расстоянии. Для мейнфреймовских процессоров эксплуатация в режиме 100% загрузки не является проблемой.
            • 0
              В тесте использовалось синхронное или асинхронное взаимодействие? Интересно посмотреть на временные характеристики не обработки сообщений, а транзакций. Обработка сообщений слишком абстрактная мера, да и время в десятки секунд не позволяют делать какой-либо вывод. Почему 50 и 70 км, это максимальное растояние? Это в пределах одного города, слишком мало для построения катострофоустойчивой системы. Будет Active-Active кластер работать на расстоянии 100-120 км? Или например 500 км(расстояние от Москвы до Нижнего Новгорода).
              • 0
                У нас не было возможности протестировать на большем расстоянии. По данным нашей интерполяции на 100 км работать будет, но конечно результаты реального теста были бы нагляднее. Для расстояний 500 — 1000 — далее везде требуется асинхронная репликация.

                Все платежи считываются из входной очереди и проходят по «конвейеру», но часть платежей (несрочные) могут накапливаться и реально обрабатываются несколько раз в сутки на фазе два (взаимозачет), а часть платежей должны быть обработаны как можно быстрее (срочные), при этом заказчиком задан жесткий SLA на максимальное время обработки таких платежей. Да собственно это все описано в статье.
              • 0
                Как вы тестировали разные расстояния? У вас что 4 центра с мейнфреймами?
                • 0
                  >> Обмен данными между CF и подключенными системами организуется по принципу «память-память» (похоже на DMA), при этом процессоры, на которых работают приложения, не задействуются.

                  Угу, потому что самих процессоров доступных для приложения стало меньше, так часть занята обслуживанием CF.
                  • 0
                    Так, то есть мы имеем 3 фазы. 1я и 3я не требуют кластера и могут выполняться асинхронно. Синхронная 2я фаза увеличивает время в 2 раза даже на расстоянии 0. И весь выигрыш мы получаем только из за того, что время обработки 1й и 3й фазы в пять раз выше критической 2й. И их(1 и 3) можно накопить для обработки позже. Если бы рассматривали «карточный процессинг» то результаты были бы гораздо плачевнее, так как там нет отложенных и асинхронных транзакций.
                    • 0
                      Все фазы запускаются сообщениями из очереди, но есть довольно жесткие SLA, заданные заказчиком. Помимо несрочных платежей, которые могут накапливаться система обрабатывает и срочные платежи. Срочный платеж поэтому и называется срочным, что обязан пройти за N минут, от этого зависит доступная ликвидность и издержки участников платежной системы. Именно для решения таких задач, предполагающих жесткий SLA, часто заданный законодательно и требуются мейнфреймы, зачастую это — единственный способ его обеспечить.
                      • 0
                        Фаза 2 не является критической, в том смысле что она выполняется несколько раз в сутки и ее при необходимости можно повторить, это — одна транзакция. Однако мы тестировали восстановление после сбоев и на этой фазе и при падении любого компонента системы (WAS, MQ, DB2) платежи продолжали обрабатываться.

                        Мне не понятно, почему вы сделали вывод, что при обработке карточек все было бы плачевнее, срочные платежи системой обрабатываются на кластере с расстоянием 70 км. в среднем всего на 7,6% медленнее.
                        • 0
                          Слово «критическая» не совсем подходит, ок. Просто скажите мне, почему в второй фазе при соединении кластера время растет в 2 раза, в отличии от других фаз?
                          • 0
                            Мы описали это в статье: «Многосторонний взаимозачет выполняется в один поток (т.е. он в принципе не масштабируется, так написано приложение). Время его проведения в кластерном режиме увеличивается из-за необходимости пересылки блокировок DB2 в CF при выполнении массовых операций DML.»
                            • 0
                              Именно! Несмотря на то, что у нас 2 копии базы, мы не хотим чтобы записи менялись одновременно на 2х сайтах. И один сайт думал что у Васи 100 руб, а другой 200. Это не особенность приложения. Это бизнес задача (требование). Будь хоть 100 узлов, работать будет как бы один, минус блокировки других узлов. В вашей табличке указано среднее время с учетом удвоения мощности и наличия фаз не требующих блокировок. И так как фазы не требующие блокировок в 6 раз более ресурсоёмкие, то и снижения среднего времени вы получаете за счет них. При этом я уверен что среднее время в пределах одного узла растет.

                              Если бы вы тестировали скажем снятие денег в банкомате, то это была бы чистая фаза 2 без примесей, сплошные блокировки. И время только бы росло. У вас слишком удачный тест пример. Если ваш аналитик анализировал характеристики нагрузки и понял, что кластер ускорит (или не сильно замедлит) — это хорошо, молодцы. Если вы просто строили систему disaster recovery и вдруг обнаружили, что времена хорошие — это совсем другое.

                              Следует писать не о времени обработки, а о поведении системы в случае выхода из строя одного узла. Zero down time? Как изменится среднее время? Растут ли очереди? Кстати, тогда вы поймете, что нельзя нагружать 2 узла как равные. Иначе при выходе из строя одного узла, второй упадет очень скоро так как ресурсы очереди не бесконечны.
                      • 0
                        На новом мейнфрейме z13 более 140 ядер, часть из них вполне можно зарезервировать под что угодно, но если и этого мало, то CF можно развернуть на отдельном небольшом мейнфрейме, например zEnterprise BC12.
                      • 0
                        В данном случае использовалось несколько виртуальных разделов, LPAR, между которыми осуществлялось соединение через кабели нужной длины. При реальном внедрении все верно, создается несколько центров обработки данных, в которые устанавливаются мейнфреймы и арендуются или строятся собственные линии связи с резервированием.

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

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

                      Самое читаемое