Comments 19
Интересно сколько всего бывает инсталяций этого железа в описанной конфигурации. Все интересно, но звучит как что-то очень специализированное
Упомянутые кластерные конфигурации применяются там, где нужна высочайшая доступность сервисов, в освновном конечно в банковской сфере, в страховых компаниях, ритейл, резервирование авиабилетов, но бывают инсталляции и для правительственных нужд, промышленных компаний. Решение отличается высочайшей зрелостью, технологии Parallel Sysplex уже практически четверть века и мало какое кластерное решение может похвастаться таким сроком жизни и развития.
Если говорить о конкретных заказчиках, то можно отметить ФРС США, Banco do Brasil S.A, некоторые китайские и европейские банки, американские электрические компании.
По российским заказчикам дать информацию не могу по соображениям коммерческой тайны, прошу прощения.
Если говорить о конкретных заказчиках, то можно отметить ФРС США, Banco do Brasil S.A, некоторые китайские и европейские банки, американские электрические компании.
По российским заказчикам дать информацию не могу по соображениям коммерческой тайны, прошу прощения.
В РАО ЕЭС России такое есть и в Сбере, вроде.
ПО «банковская платежная система» случаем не компании Montran?
Выполнялись ли в этой конфигурации нагрузочные тесты с непрерывной подачей платежных документов?
Выполнялись ли в этой конфигурации нагрузочные тесты с непрерывной подачей платежных документов?
В тесте использовалось синхронное или асинхронное взаимодействие? Интересно посмотреть на временные характеристики не обработки сообщений, а транзакций. Обработка сообщений слишком абстрактная мера, да и время в десятки секунд не позволяют делать какой-либо вывод. Почему 50 и 70 км, это максимальное растояние? Это в пределах одного города, слишком мало для построения катострофоустойчивой системы. Будет Active-Active кластер работать на расстоянии 100-120 км? Или например 500 км(расстояние от Москвы до Нижнего Новгорода).
У нас не было возможности протестировать на большем расстоянии. По данным нашей интерполяции на 100 км работать будет, но конечно результаты реального теста были бы нагляднее. Для расстояний 500 — 1000 — далее везде требуется асинхронная репликация.
Все платежи считываются из входной очереди и проходят по «конвейеру», но часть платежей (несрочные) могут накапливаться и реально обрабатываются несколько раз в сутки на фазе два (взаимозачет), а часть платежей должны быть обработаны как можно быстрее (срочные), при этом заказчиком задан жесткий SLA на максимальное время обработки таких платежей. Да собственно это все описано в статье.
Все платежи считываются из входной очереди и проходят по «конвейеру», но часть платежей (несрочные) могут накапливаться и реально обрабатываются несколько раз в сутки на фазе два (взаимозачет), а часть платежей должны быть обработаны как можно быстрее (срочные), при этом заказчиком задан жесткий SLA на максимальное время обработки таких платежей. Да собственно это все описано в статье.
Как вы тестировали разные расстояния? У вас что 4 центра с мейнфреймами?
>> Обмен данными между CF и подключенными системами организуется по принципу «память-память» (похоже на DMA), при этом процессоры, на которых работают приложения, не задействуются.
Угу, потому что самих процессоров доступных для приложения стало меньше, так часть занята обслуживанием CF.
Угу, потому что самих процессоров доступных для приложения стало меньше, так часть занята обслуживанием CF.
Так, то есть мы имеем 3 фазы. 1я и 3я не требуют кластера и могут выполняться асинхронно. Синхронная 2я фаза увеличивает время в 2 раза даже на расстоянии 0. И весь выигрыш мы получаем только из за того, что время обработки 1й и 3й фазы в пять раз выше критической 2й. И их(1 и 3) можно накопить для обработки позже. Если бы рассматривали «карточный процессинг» то результаты были бы гораздо плачевнее, так как там нет отложенных и асинхронных транзакций.
Все фазы запускаются сообщениями из очереди, но есть довольно жесткие SLA, заданные заказчиком. Помимо несрочных платежей, которые могут накапливаться система обрабатывает и срочные платежи. Срочный платеж поэтому и называется срочным, что обязан пройти за N минут, от этого зависит доступная ликвидность и издержки участников платежной системы. Именно для решения таких задач, предполагающих жесткий SLA, часто заданный законодательно и требуются мейнфреймы, зачастую это — единственный способ его обеспечить.
Фаза 2 не является критической, в том смысле что она выполняется несколько раз в сутки и ее при необходимости можно повторить, это — одна транзакция. Однако мы тестировали восстановление после сбоев и на этой фазе и при падении любого компонента системы (WAS, MQ, DB2) платежи продолжали обрабатываться.
Мне не понятно, почему вы сделали вывод, что при обработке карточек все было бы плачевнее, срочные платежи системой обрабатываются на кластере с расстоянием 70 км. в среднем всего на 7,6% медленнее.
Мне не понятно, почему вы сделали вывод, что при обработке карточек все было бы плачевнее, срочные платежи системой обрабатываются на кластере с расстоянием 70 км. в среднем всего на 7,6% медленнее.
Слово «критическая» не совсем подходит, ок. Просто скажите мне, почему в второй фазе при соединении кластера время растет в 2 раза, в отличии от других фаз?
Мы описали это в статье: «Многосторонний взаимозачет выполняется в один поток (т.е. он в принципе не масштабируется, так написано приложение). Время его проведения в кластерном режиме увеличивается из-за необходимости пересылки блокировок DB2 в CF при выполнении массовых операций DML.»
Именно! Несмотря на то, что у нас 2 копии базы, мы не хотим чтобы записи менялись одновременно на 2х сайтах. И один сайт думал что у Васи 100 руб, а другой 200. Это не особенность приложения. Это бизнес задача (требование). Будь хоть 100 узлов, работать будет как бы один, минус блокировки других узлов. В вашей табличке указано среднее время с учетом удвоения мощности и наличия фаз не требующих блокировок. И так как фазы не требующие блокировок в 6 раз более ресурсоёмкие, то и снижения среднего времени вы получаете за счет них. При этом я уверен что среднее время в пределах одного узла растет.
Если бы вы тестировали скажем снятие денег в банкомате, то это была бы чистая фаза 2 без примесей, сплошные блокировки. И время только бы росло. У вас слишком удачный тест пример. Если ваш аналитик анализировал характеристики нагрузки и понял, что кластер ускорит (или не сильно замедлит) — это хорошо, молодцы. Если вы просто строили систему disaster recovery и вдруг обнаружили, что времена хорошие — это совсем другое.
Следует писать не о времени обработки, а о поведении системы в случае выхода из строя одного узла. Zero down time? Как изменится среднее время? Растут ли очереди? Кстати, тогда вы поймете, что нельзя нагружать 2 узла как равные. Иначе при выходе из строя одного узла, второй упадет очень скоро так как ресурсы очереди не бесконечны.
Если бы вы тестировали скажем снятие денег в банкомате, то это была бы чистая фаза 2 без примесей, сплошные блокировки. И время только бы росло. У вас слишком удачный тест пример. Если ваш аналитик анализировал характеристики нагрузки и понял, что кластер ускорит (или не сильно замедлит) — это хорошо, молодцы. Если вы просто строили систему disaster recovery и вдруг обнаружили, что времена хорошие — это совсем другое.
Следует писать не о времени обработки, а о поведении системы в случае выхода из строя одного узла. Zero down time? Как изменится среднее время? Растут ли очереди? Кстати, тогда вы поймете, что нельзя нагружать 2 узла как равные. Иначе при выходе из строя одного узла, второй упадет очень скоро так как ресурсы очереди не бесконечны.
На новом мейнфрейме z13 более 140 ядер, часть из них вполне можно зарезервировать под что угодно, но если и этого мало, то CF можно развернуть на отдельном небольшом мейнфрейме, например zEnterprise BC12.
В данном случае использовалось несколько виртуальных разделов, LPAR, между которыми осуществлялось соединение через кабели нужной длины. При реальном внедрении все верно, создается несколько центров обработки данных, в которые устанавливаются мейнфреймы и арендуются или строятся собственные линии связи с резервированием.
Мейнфрейм можно сравнить с железной дорогой. Да, нужно строить насыпь и прокладывать рельсы, организовывать станции и вокзалы, но зато поезд может за раз перевести грузов гораздо больше, чем вереница автомобилей, а главное — дешевле, причем эксплуатировать решения на мейнфреймах можно десятилетиями.
Мейнфрейм можно сравнить с железной дорогой. Да, нужно строить насыпь и прокладывать рельсы, организовывать станции и вокзалы, но зато поезд может за раз перевести грузов гораздо больше, чем вереница автомобилей, а главное — дешевле, причем эксплуатировать решения на мейнфреймах можно десятилетиями.
Sign up to leave a comment.
Производительный отказоустойчивый географически разнесенный кластер, работающий по схеме Active-Active на мейнфрейме IBM zEnterprise EC 12