company_banner

Тихая революция: внедрение x86-архитектуры вместо RISC-машин для процессинга банка



    — Смета была 200 миллионов рублей, а стала 650 миллионов! Вы обалдели?

    По слухам, именно так начался этот проект на совете директоров банка. Курсовая разница по одной из поставок серверов составляла 450 миллионов рублей. Естественно, хотелось как-то уменьшить эти затраты.

    Долгое время считалось, что архитектура x86 «из коробки» не предназначена для серьёзных вычислений. Самые серьёзные в мире вычисления (по нагрузке и требованиям к надёжности) — это банковское ядро, процессинг. Там не закончить считать вовремя 2–3 операционных дня подряд означает просто закрытие банка (и проблемы с банковской системой страны) из-за возникающего разрыва, который догнать уже невозможно.

    Один банк из ТОП-10 ещё пару лет назад планировал докупить себе машин P-серии, известных своей надёжностью, масштабируемостью и производительностью. Про x86 там даже не думали, пока не настал кризис. Но кризис настал. Одна машина за 5–7 миллионов долларов (а нужна даже не одна и не две) — это немного перебор. Поэтому руководство решило тщательно изучить вопрос замены RISC на x86.

    Ниже — сравнение двух подобных конфигураций (они не совсем одинаковые): P-серия с RISC-процессорами с ядрами на 4 ГГЦ из расчёта одно RISC-ядро на два ядра x86 2.7 ГГЦ. Всё это мы смонтировали в машзале дата-центра банка, загнали туда реальную базу, показывающую несколько банковских дней за прошлый год (у них есть специально заготовленная среда для тестов, полностью симулирующая реальность и полноценную нагрузку от транзакций, банкоматов, запросов и т. п.), и выяснили, что x86 подходит и стоит в разы дешевле.



    В правом углу ринга


    RISC-машины хороши своей способностью делать вычисления быстро и надёжно. До появления кластеров, как описано ниже, других альтернатив в банковском ядре не было — не получалось масштабироваться. Кроме того, RISC-машины лишены традиционного недостатка x86 при высокой нагрузке — у них не падает производительность при долгой постоянной нагрузке выше 70–80%. Но, учитывая редкость решений, цена соответствует. Плюс банки всегда берут расширенный сервис на поставку частей, а это сравнимо со стоимостью самой машины на 3 года (30% от стоимости закупки за год). Ещё одна особенность — апгрейд методом выкидывания старой железки. Например, P-серия трёхлетней давности сейчас часто списывается просто в тестовые среды, потому что боевого применения в системах ядра ей нет — надо закупать новые машины постоянно. Естественно, производители всячески мотивируют на «апгрейд покупкой» — тем и живут. Частый способ — повысить стоимость расширенной поддержки для машин старше 3 лет.

    Вот график поставки таких машин по миру:



    А вот соотношение стоимости покупки к операционным затратам:



    В левом углу ринга


    У HPE нашлось подходящее архитектурное решение Superdome — классическая реализация архитектуры ccNUMA на базе системного коммутатора «процессорных шин» с возможностью свободного расширения при добавлении ядер. До этой архитектуры фактически x86-кластеры так или иначе быстро упирались в свои пределы увеличения мощности из-за больших издержек на перетаскивание данных между ядрами.

    По масштабируемости — это х86 блейды, соединённые между собой:



    ОС — RED HAT + Oracle. Стоимость — в разы ниже, чем для RISC-архитектуры, поскольку все детали крупносерийные и широко распространены по рынку. Плюс лицензии выходят дешевле. Стоит добавить, что цена сервиса тоже существенно привлекательнее, поскольку и архитектура куда менее «шаманистая».

    Немного гикпорна:


    BL920s Gen9 Server Blade Memory Subsystem


    BL920s Gen9 Server Blade I/O Subsystem

    Наша тестовая сборка: Integrity Superdome X, 8 x Intel Xeon E7-2890 v2, (15c / 2.8 GHz / 37.5 M / 155 W), ОЗУ
    2048 GB (64 x 32 GB PC3-14900 DDR3 ECC registered Load Reduced DIMMs), Linux Red Hat 7.1, Oracle 11.2.0.4 с данными на Oracle ASM, порты 1 GbE: 4 x 1G SFP RJ45; 10GbE: 4 x 10G SFP+; 16 Gb FC: 8 x 16Gb SFP+. С ней СХД HDS VSP G1000, не менее 40K IOPS, для нагрузки, ориентированной на запись, 16 LUN по 2TB каждый, два порта по 8Gb.

    Вот схема тестового стенда (часть названий замазана, это всё же банк):





    Короткое резюме


    x86-кластер явно может то же самое, что «тяжёлые» RISC-машины. С некоторыми особенностями, но может. Выигрыш — уменьшение итоговой стоимости владения на порядок. Ради этого стоит поковыряться и разобраться.

    Да, чтобы переехать на x86, надо будет мигрировать с ОС AIX (это UNIX-подобная проприетарная операционная система) на Linux, скорее всего, в сборке RED HAT. И с одного Oracle на другой Oracle. Если для бизнеса вроде розницы это реальная сложность, то банковские коллеги восприняли всё прагматично и спокойно. И пояснили, что работа с ядром банка — это всё равно постоянная миграция с одних машин и систем на другие каждый год, и процесс не прекращается. Так что они ради той кучи денег, которую даст внедрение x86, готовы и не на такое. И с AIX на Linux они уже переходили, небольшой опыт есть. И некоторым их наследуемым подсистемам уже по 10 лет — в банке это настоящее окаменелое legacy, которое нужно поддерживать.

    И поддерживают, не впервой.

    Что касается нашей тестовой машины, то она пользуется дичайшим спросом. Из этого ТОП-10 банка она уже переехала в другой, где идёт похожая программа тестов. Следом — ещё один банк из десятки, а потом очередь из нескольких банков первой тридцатки. До ближайшей зимы вряд ли освободится, но ещё одна тестовая сборка есть у HPE, с ней вроде поспокойнее.

    Ссылки:


    • На CNEWS умными длинными словами
    • Документы на Супердом: архитектура и спека Integrity Superdome X.
    • Полезная ссылка — Server Performance Benchmarks — для просмотра результатов тестов и отчётов по ним для всех моделей серверов HPE. Просто выберите Superdome X и смотрите на рекордные результаты.
    • Моя почта — YShvydchenko@croc.ru.

    Да, решение — банк систему внедряет.
    КРОК
    IT-компания

    Comments 105

      +1
      А объясните чайнику — банки вроде не вчера появились — неужто у них объём вычислений растёт быстрее Мура? Что за 10 последних лет, что за полвека? Вот 20-30 лет назад как они справлялись?
        +7
        Объем транзакций растет, растет количество оборудования, регулярно добавляются новые клиентские сервисы. Масштабируемость, кстати, нифига не линейная. Т.е. если банк, у которого количество терминального оборудования (банкоматы, киоски, POS-терминалы) пять лет назад составляло 1000 единиц, в этом году увеличил его до 5000 единиц, то вычмощности ему надо увеличивать не в 5 раз, а, грубо говоря, в 15 раз. И так далее.
        Что касается RISC vs x86, ну, тут никаких чудес нет. Просто давно не секрет, что в стоимости больших черных коробок с надписью IBM ***Series и им подобных прячется очень-очень неплохая маржа производителя :) Дело же не в архитектуре, а в покупательной способности участников рынка, на который она ориентирована.
          0
          А, да, теперь же по карточкам в любом супермаркете… не_подумал-не_связал, что это на те же ВЦ выходит
          (кстати, ну зачем эту аббревиатуру «ЦОД» ввели, когда было же вполне достаточное для этого понятие «ВЦ» (вычислительный центр)
        +14
        > выяснили, что x86 подходит и стоит в разы дешевле

        шёл 2016 год…
          0
          Я, конечно, далек от этой сферы, но ведь x86 уже двадцать лет как используют под капотом RISC ядро, потому ничего удивительного в возможности замены не вижу :/
            +1
            Дело, видимо, не в системе команд как таковой, а в том, что аппаратная часть по-разному работает в разных сценариях. Например, вплоть до пентиумов интеловские процессоры очень долго обрабатывали прерывания (относительно других архитектур) и это ограничивало спектр применения. Ну и так далее.
              0
              Ну собственно RISC ядро в Pentium Pro и появилось.
            0
            т.е. расчеты не в реальном времени, а раз в сутки происходят?
              0
              Наверное речь про реальные зачеты по-межбанку, а не внутредневная операционка
                0
                Да. Это наиболее ресурсоемкая задача.
                  +1
                  Основная нагрузка, конечно же, идет на ночные операции — перенос данных из операционных баз на data warehouse, формирование выписок, клиринговые операции, начисление процентов и т.д.
                  +7
                  В левом углу ринга — 120 ядер Xeon 2.8Ghz, 2Tb RAM, а в правом какие характеристики?
                    +4
                    IBM P-серия 64 ядра Р7 2 Tb RAM.
                  • UFO just landed and posted this here
                      +1
                      Возможно речь идёт о насыщении https://www.reddit.com/r/vmware/comments/425j0d/cpu_saturated_workload/
                      • UFO just landed and posted this here
                          0
                          Без гипервизора тоже наблюдал лично в 2009 году.
                          На сервер СУБД (8 ядер Intel Xeon, 16Гб ОЗУ, Win2003, MS SQL2005) около 40 минут подряд валилась нагрузка, и машина «залипла» почти намертво.
                          Решилось заменой на Оптероны от AMD (8 ядер, 12 Гб ОЗУ, Win2003, MS SQL 2005).
                          Потом, ради эксперимента, «залипавшую» машинку грузили на тестовом стенде — она так же точно залипала.
                            0
                            Мне кажется, это не особенность архитектуры x86. Это больше похоже на включение троттлинга в процессоре.
                        +1
                        Это особенность x86 архитектуры а не CPU.
                        При большой нагрузке (в unix-like осях, когда load average поднимается до 20-40 и более) производительность x86 начинает резко падать, практически эспоненциально, в то время, как на risk-архитектуре хоть и замедляется, но не сильно.
                        Скажем load average 60 в linux на x86 — это жестокий фриз, когда между набором даже простейшей команды типа «echo» и ее выполнением проходят десятки секунд, если не минуты, то с точно таким же load average на solaris запущенный на sparc t2000 — система оставалась отзывчивой, пользователи даже не сразу замечали, что что-то вообще не так.

                        > если бы на домашних тачках такое происходило, наверняка бы трубили об этом.
                        Ну, те, кто сталкивался — трубят. :)

                        > Или фильм ты пережимаешь, у тебя estimated 1:00
                        Пережатие фильма это один поток, он создаст load average = 1. Речь идет о случае, когда количество задач в очереди гораздо больше, чем успевает обрабатывать процессор.
                          0
                          Ни разу с таким не сталкивался, в том числе и в гипервизоре запуская математические просчеты на 4 ВМ (по 2 ядра) загружающих полностью сервер с 4 ядрами на сутки-другие, и на ноутбуке запуская рендеринг графики на неделю и умудряясь при этом играть в COD выставив для рендеринга приоритет поменьше, можно конкретные примеры или ссылки на описание проблемы, не понимаю о чем речь.

                          Пережатие фильма это один поток, он создаст load average = 1. Речь идет о случае, когда количество задач в очереди гораздо больше, чем успевает обрабатывать процессор.


                          обычно пережатие фильма эти минимум два потока (аудио, видео) а для HT и того больше благо пережатие прекрасно масштабируется, разве нет? ну и в довесок еще огромное количество потоков ОС, хотя собственно какая разница, сколько потоков если существует планировщик задача которого правильно предоставлять процессорное время всем задачам.

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


                                Тем не менее идет обработка множеством ядер, в чем загвоздка? Почему нельзя приоретизировать некоторые транзакции которые требуют оперативной обработки и например выполнять их, на 8-ми из 64-х ядер?
                                  0
                                  > Тем не менее идет обработка множеством ядер, в чем загвоздка?
                                  Количество запросов заметно превышает количество потоков? Выстраивается огромная очередь и процессор тратит больше тактов на переключение контекстов, чем на саму работу?

                                  Для сравнения берем примерно 2010-11 год, когда спарки еще не слишком сильно отставали от интела:
                                  — Xeon Nehalem (55xx) — максимально число ядер 4, максимальное число потоков на ядро 2 (тот самый HT), итого 8 потоков на сокет. Максимум сокетов в одной системе — 2(4?).
                                  — IBM Power7 — ядер 8, 4 потока на ядро, итого 32 потока на сокет. Максимум до 32 сокетов в одной системе — IBM Power 795.
                                  — Sparc T3 — ядер 16, 8 потоков на ядро, итого 128 потоков на сокет. Максимум до 4 сокетов в одной системе — SPARC T3-4.

                                  > Почему нельзя приоретизировать некоторые транзакции которые требуют оперативной обработки и например выполнять их, на 8-ми из 64-х ядер?
                                  Для базы данных все все запросы одинаковы, скорее всего у нее просто нет средств приоретизации по каким-то формальным признакам.
                                    0
                                    Количество запросов заметно превышает количество потоков? Выстраивается огромная очередь и процессор тратит больше тактов на переключение контекстов, чем на саму работу?

                                    Т.е. на тот год (2010-2011) все банально упиралось в количество ядер
                                    8*4*32=1024 ядра на Power7
                                    16*8*4=512 ядер на Т3
                                    8*20=160 на HP980+8*E7-8870
                                    получается что в лучшем случае каждому ядру приходилось обсчитывать в 3 раза больше информации чем ядру Т3 и проблема была в том что разнести базу на два сервера нельзя, а больше ядер уже не впихнешь на тот момент? Тогда проблема мне ясна, спасибо за разъяснение:)

                                    Еще вопрос, я ни разу не силен в спарках, правильно понимаю что говоря Sparc T3 с 16 ядрами, 8 потоками на ядро и 4 сокетами подразумевается шкафчик? и в сравнении удельной вычислительной мощи на юнит он получается сравним с тем же DL980 от НР который занимает юнитов 10 от силы?
                                      0
                                      > Т.е. на тот год (2010-2011) все банально упиралось в количество ядер
                                      Потоков, а не ядер.
                                      Это на x86 привычно, что одно ядро — 2 потока, на других архитектурах их было разное значение, например на спарках — заметно больше.

                                      > Еще вопрос, я ни разу не силен в спарках, правильно понимаю что говоря Sparc T3 с 16 ядрами, 8 потоками на ядро и 4 сокетами подразумевается шкафчик?

                                      Погугли бы? Всего 4U.
                                      image
                          +8
                          Автор упорно нигде не произносит IBM, но почему-то спалился на AIX. Может еще и на названии банка спалится? Плата ведь идет не за RISC-архитектуру — их как грязи сейчас везде, а за отработанные решения известного производителя. Если банку по силам сгородить свой собственный велосипед (или купить чей-то сторонний) из x86, linux и т.п. — флаг в руки.
                            +1
                            Да все же просто, пока был старый курс всех устраивали решения от IBM, но времена поменялись и банки, посчитав разницу в цене, уходят в x86, что не удивительно.
                              0
                              Альфа или Сбер. Есть небольшой шанс что это Открытие но навряд ли.
                                0
                                Ставлю на ВТБ24. 5-10$ млн для Сбера не деньги. А в Альфе не используется процессинг от OpenWAY. http://blog.chirkov.net/2013/05/02/klienty-openway/
                                  0
                                  А причём тут OpenWay? ВТБ, ВТБ24, Открытие- тоже не OW.

                                  OW в Сбере вот точно.
                                    0
                                    Обратите внимание на слайды — OW, Netserver, кроме этого по ссылке на CNEWS можно найти упоминание об OpenWay. Значит с ВТБ24 я мимо. Список подозреваемых банков сужается.
                                      0
                                      Промахнулся, она не в топ-10.
                              +4
                              … у них не падает производительность при долгой постоянной нагрузке выше 70–80%

                              … потому что боевого применения в системах ядра ей нет

                              … пределы увеличения мощности из-за больших издержек на перетаскивание данных между ядрами

                              … поскольку и архитектура куда менее «шаманистая»

                              что это вообще значит?
                                0
                                В 2011 году скорее всего был HP Superdome на процессорах Itanium, а это другая архитектура и условия. Они закономерно проигрывали IBM + AIX.
                                Никто и не говорит, что идентичные конфигурации (одинаковое количество памяти и ядер) IBM p-series и HP SDX результаты. Речь идет о соотношении цена/качество, можно добиться сопоставимых и даже лучших результатов за существенно меньшую стоимость.
                                0
                                А чего oracle exadata смотреть не стали?
                                  0
                                  Смотрели, но под другие задачи. У oracle exadata есть ограничения по возможности работать с продуктами не Oracle.
                                  +3
                                  А в правом углу ринга???
                                    +4
                                    Автор,

                                    а залицензировать Oracle 120 ядер x86 сильно дешевле 60-и паверных ядер?
                                      +2
                                      Одинаково, у х86 коэфициент 0.5, у Power 1. Собственно в Oracle же не дураки маркетингом занимаются, как только ядро х86 догонит ядро Power у него тоже коэф. станет 1 :)
                                        0
                                        Стоимость лицензирования одинаковая. Коэффициент на ядро для HP SDX – 0,5, для IBM Power – 1. Учитывая двухкратное количество ядер для HP SDX, получается то на то.
                                        +8
                                        Имел несторожность поучаствовать в банковском проекте в 2011 где в качестве основного сервера базы данных был HP Superdom, HP Unix, Oracle.
                                        Удовольствие неописуемое, когда на закрытии дня (а иногда это надо делать в разгар уже следующего открытого дня) десятки длинных отчетов просто забивали CPU на 100% (это не блокировки БД) и дальше все прочие короткие транзакции от онлайн-пользователей вставали в очередь (таких было около 4000, активных сессий одномоментно около 100). Рядом была инсталляция где на риск-процессорах и солярисе от фуджитсу-сименс работала еще более нагруженная система такой же конфигурации и никаких проблем такого рода не было. Т.е. при наличии длинных транзакций в сессиях, короткие транзакции успешно проходили. Выяснилась закономерность — как только количество транзакций превышало количество ядер, то система начинала страшно тупить. В отличие от риск и соляриса не было квантования времени между сессиями и дальше начинался массовое зависание.и вся эта конструкция умирала по CPU. Закончилось все приобретением сервера от IBM на AIX, а эта конструкция на HP SuperDom стала тестовой средой банка, т.к. нарастить количество ядер в той версии уже было невозможно. Так что оно может быть и экономия, но мой личный опыт показывает, что тогда надо покупать с большим запасом по сравнению с конфигурациями на RISC.
                                          +5
                                          я далёкий от реалий такого стека человек, поэтому мне непонятно почему весь этот конгломерат технологий сводят к разнице в архитектуре процессоров, как так получается? действительно ли risc/x86 определяет все важные показатели
                                            +1
                                            В отличии от x86 ширпотреба при проектировании новых процессоров sparc часть инструкций ответственных за шифрование и sql реализована прямо в железе процессора, что сильно дороже и не нужно к примеру геймерам. Потому и работает быстрее, плюс почитайте историю самого Оракла — они исторически не на x86 разрабатывались, работали и оптимизировались по производительности.
                                              0
                                              про тестирование и оптимизацию понятно,
                                              про инструкции непонятно — что, поэтому планирование обработки транзакций не такое удачное?
                                                +4
                                                Прошу прощения заранее за, может быть, некорректный вопрос. Не подскажите, что за sql инструкции в железе в sparc реализованы?
                                            0
                                            В 2011-м не существовало Superdome X, о котором в статье. HP-UX на архитектуру x86 не портирован и вряд ли будет.
                                              0
                                              Осторожный вопрос — а каким образом архитектура процессора связана с планированием задач, которым по идее должна заниматься ОС? Ну т.е. может быть проблема на самом деле была в HP Unix, а не в х86?
                                                0
                                                Цена контекст свича, в которую входят как минимум следующие факторы: interrupt latency, аппаратная поддержка HT/SMP/NUMA, особенности MMU, доступность управления кэш памятью и ее архитектура, цена обработки исключений, реализации атомарных операций на разных архитектурах существенно отличаются.

                                                OS конечно тоже накладывает дополнительные ограничения например может не использовать большие страницы изза чего больше поток мета информации для поддержки многозадачности и как следстви более долгое переключение между задачами или в случае худшей чем O(1) возможности масштабирования подсистем упираться в это на определенных задачах, неправильно управлять ресурсами, что ведет к низкой эффективности использования их ПО.
                                              0
                                              По тексту статьи выходит, что как бы х86 они за рубли покупают, в отличие от долларовых АРМов?
                                                0
                                                И то и другое покупается за доллары, только разница в цене существенная.
                                                +1
                                                Подождите-ка. Как это железо может быть крупносерийным, если фабрики и чипсеты XNC2 — это местное решение на своих ASIC?
                                                  0
                                                  Речь идет нет только о чипсетах, это частный случай. Кроме чипсетов, используется большое количество типовых комплектующих, например процессоры Intel. А в мире HP SDX, как и другие большие сервера, не штучный продукт.
                                                  +4
                                                  Бред (не статья, а предубеждение). x86 по определению мощнее любой другой архитектуры.
                                                  1: x86 — это уже очень давно RISC, просто с программной вшитой прослойкой трансляции команд новых.
                                                  2: «производительность уменьшается при долгой нагрузке» — это где и это как вообще? может если у человека своп используется разве, других перспектив для реализации данного утверждения не вижу
                                                  3: 5Ghz RISC и 2 по 2.5 GHz x86 — вы меня извините, но это несравнимые величины. 1Ghz x86 — это намного больше операция чем любой 1GHz любого RISC (тот же ARM в мобильных). Поэтому странно слышать о замене 5GHz RISC на столько же гигагерц ARM.

                                                  Может дело в корявости ПО\программистов просто?
                                                    +6
                                                    Простите за вопрос, а вы хорошо знаете предмет?
                                                    После слов про мощность x86 > RISC, а также после сравнение ARM и RISC от IBM я сильно в этом засомневался.
                                                      0
                                                      доказывать не хочу, но знаю неплохо.
                                                      в последнем предложении опечатался, про замену, имел ввиду конечно же на x86. @Поэтому странно слышать о замене 5GHz RISC на столько же гигагерц X86.@

                                                      и да, опять утверждаю, что x86 намного более производителен (я не о тактах, а о производительности), чем любой ARM\MIPS
                                                        +1
                                                        Производительность в чём измеряете?
                                                          +2
                                                          и да, опять утверждаю, что x86 намного более производителен (я не о тактах, а о производительности), чем любой ARM\MIPS

                                                          Тут я даже спорить не стану, все верно. Только в статье IBM Power, а вы про ARM. Это более чем не одно и то же.
                                                            +1
                                                            Как вы измеряете производительность на каких задачах?
                                                            На каких алгоритмах?
                                                            Сколько по вашему у X86 регистров?
                                                            А у RISC/MISC (ARM/PPC/MIPS/Z/68K/SPARC/ALPHA/PARISC) и на что это влияет?
                                                            С какими архитектурами из этих вы знакомы как эксперт? Чем SMP отличается от NUMA? Как на них устроены/реализованы ALU? Cache? MMU? Data reader Data Writer? Атомарные операции? Какие доступны возможности управления этим (cache, mmu, data reader/writer)? Какие операции могут быть условны? И как это влияет на производительность?
                                                            Сколько тактов выполняются операции LD/ST, сравнения, условных переходов? Какие возможности SIMD? Какие на них C/C++ ABI? Как ABI влияет на производительность?
                                                          +1
                                                          Предлагаю загуглить какие еще, кроме ARM, существуют RISC-процессоры, и какие из них ставит в свои машины IBM. Сразу уменьшится пафосность первого предложения и п.3
                                                            0
                                                            Давайте составим ряд: 1GHz Xeon, 1GHz Opteron, 1GHz Xeon Phi, 1GHz Maxwell (RISC). Как будем ранжировать? 1GHz — это частота чего?
                                                            +2
                                                            позиция оракла, официальная, которую они нам рекомендовали:

                                                            sparc (серверы Sun) + solaris + Database 12c или на худой legacy случай 11g
                                                            или
                                                            x86 (серверы Exalogic) + OEL (UEK + RedHat) + Database 12c или на худой legacy случай 11g

                                                            всё остальное Оракл прямым текстом не рекомендует и фактически отказывается сопровождать при проблемах с производительностью.
                                                            AIX при проблемах производительности они кстати тоже нехотя поддерживают, не рекомендуют, и ни какой сверх производительности не гарантируют.

                                                            несколько вопросов к авторам:

                                                            Почему был выбран огород из официально не рекомендованных версий дистрибутивов ОС и железа на которых не гарантируется максимальная производительность?

                                                            Почему не был применён официально рекомендованный Ораклом InfiniBand?
                                                            Зачем был выбран медленный Fiber Channel в свете предыдущего вопроса?

                                                            В вашей инсталляции Database на голом железе без виртуализации?

                                                            Что в вашей схеме делают 1 Гигабитные сетевые подключения? Почему не 10G?

                                                              0
                                                              Гигабиты там встроенны, а фразу «10GbE: 4 x 10G SFP+» вы не заметили?
                                                                +1
                                                                Если внимательно изучить схему, то видно что платформа возможно этими 10 гигабитными портами и подключается к основному коммутатору, но дальше идёт чистый гигабит по схеме, вот этот момент и настораживает, особенно в резрезе связи с аналитическим сервером, это бутылочное горлышко для любой аналитики, которая при своей работе существенно нагружает канал к серверу БД, особенно если отчёты смотрят тысячи пользователей. Даже если запросы однотипные, лежат в кеше и оттуда же сервером БД и отдаются.
                                                                +1
                                                                А Оракел после покупки Сана хоть что-то кроме своих железок рекомендует?
                                                                  0
                                                                  А есть ли экономический смысл тратить время на фанатичную оптимизацию под десяток платформ, если есть одна и её можно сделать не просто хорошо, а идеально, вопрос в качестве.
                                                                  0
                                                                  Еще бы, как же иначе, ведь они продают это железо. Странно, если бы они его не предлагали всем подряд.
                                                                  С каких пор FC стал медленным? Много вы знаете внедрений IB в качестве транспорта систем хранения данных?
                                                                    0
                                                                    Ну как сказать, давайте сравним 4 гигабита на канал и 40 гигабит на канал…
                                                                    Рекомендую (но не рекламирую !) вам изучить архитектуру полношкафного решения exalogic в котором IB основной транспорт между диском, серверами БД и приложений.
                                                                      +1
                                                                      Массмаркет не поддерживает IB для хранилок в большинстве своем.
                                                                        +2
                                                                        в статье нашел упоминание про 16Gb FC. 16Gb можно более чем сравнивать с 40Гбит.
                                                                        А еще я вам один секрет скажу, сейчас никто (почти) не покупает даже 16Gb FC (хотя уже вышел 32Gb), потому что пропускная способность канала значит не так много, когда транспорт построен грамотно. Так как для всех подключений стораджа к серверам используется multipathing, то это минимум 2, а обычно 4 линка, то есть 32Gb.
                                                                        Я знаю ооочень маленькое количество массивов, которые способны выдать такой поток данных и не умереть. Это High-end массивы, которые обычно подключаются гораздо бОльшим числом линков.
                                                                        Так что все эти 40Gb — далеко не показатель.
                                                                          0
                                                                          … только реальная, а не маркетинговая, характеристика, которая отделяет top mid-range от Hi-End массивов — это возможность подключения по FICON.
                                                                            0
                                                                            я поклонник мнения, что Hi-end массивы отделяются от midrange надежностью, внутренней архитектурой. Но в сообщении выше top of mid-range я тоже отнес к категории Hi-end.
                                                                            Ficon почти мертв и скоро совсем не останется таких массивов=)
                                                                              0
                                                                              «FICON почти мертв»… а еще «FС почти мертв», и «HDD почти мертв»… вспоминая из своей молодости — «панк не мертв, он всегда так пахнет».

                                                                              со всем уважением к вашему мнению, hi-end СХД — это то, что может работать с мейнфреймами, в таком случае кроме всех признаков (архитектура кэшей, матричная коммутация контроллеров, и пр.) явно выделяется ровно один признак — либо файкон есть, либо его нет.

                                                                              например, Huawei OceanStor 18000 V3 — есть и матричная коммутация контроллеров, и инфинибэнд, и впечатляющие IOPs, и прочая прочая — но он не Hi-End.
                                                                              тогда как, например — HDS G1000, он же HPE XP7 — IOPs заявлено в 4 раза меньше, чем у хуавей, но — есть FICON — и это уже Hi-End.
                                                                              тот же HDS G800 — топ мидренжа
                                                                                0
                                                                                Это давний холивар, мнения по этому вопросу у каждого свое. Ваше мнение довольно распространенное, хотя его поклонников становится все меньше.
                                                                                Я просто не вижу смысла выделять целый класс устройств по одному, такому незначительному признаку. Завтра какой-нибудь Huawei возьмет и добавит к своей младшей линейке поддержку FICON (ну еще пару лет потратит на сертификацию), не будем же мы S2600T называть Hi-end?
                                                                                в последнее время, если смотреть на вендоров, то Hi-end оборудование часто выделяется только за счет своей цены=) Например, NetApp FAS8080 ничем архитектурно не отличается от 8020, а они называют его Hi-end.
                                                                                Это уже вопрос больше религии, чем реальное разделение.

                                                                                Все вышенаписанное — не более чем мои размышления. Точку зрения не навязываю, это просто мое воззрение на сегодняшний рынок СХД.
                                                                      0
                                                                      Позиция Oracle легко объяснима, Oracle — производитель программных продуктов в первую очередь рекомендует Oracle — производителя оборудования (серверов и СХД).

                                                                      Что касается поддержки. То, что выпишите, не совсем верно — продукты Oracle официально работают и поддерживаются на множестве платформ (Linuх, AIX и т.д.), и при правильном выборе конфигурации никаких проблем с производительностью у вас не будет, а Oracle будет осуществлять полную техническую поддержку. Все остальное — это стратегия продаж: наше ПО лучше всего работает и поддерживается на нашем оборудовании.

                                                                      Отказ разбираться с проблемами производительности — это достаточно стандартный случай, если вы используете мультивендорное решение. Производитель ПО будет пенять в сторону производителя железа, и наоборот.

                                                                      Почему был выбран огород из официально не рекомендованных версий дистрибутивов ОС и железа на которых не гарантируется максимальная производительность?
                                                                      С чего вы взяли? Полностью сертифицированная и согласованная с HP конфигурация. SDX + ОС RHEL
                                                                      Выдержка из документации HP:

                                                                      HPE BL920s Gen8 Server Blades
                                                                      • Red Hat Enterprise Linux (RHEL)
                                                                      • SUSE Linux Enterprise Server (SLES)
                                                                      • Microsoft Windows Server 2012 R2 Standard and Datacenter (including Microsoft
                                                                      SQL Server 2014)
                                                                      • VMware vSphere 5.5 U2 and 6.0
                                                                      NOTE: Please be advised there are currently no WBEM providers for VMware
                                                                      running on Superdome X meaning IRS cannot report OS message traffic.

                                                                      Почему не был применён официально рекомендованный Ораклом InfiniBand?
                                                                      Применен где? Для подключения к SAN? В инфраструктуре заказчика не используется InfiniBand.
                                                                      Зачем покупать и устанавливать специальные коммутаторы InfiniBand, подключать их к имеющемуся SAN.
                                                                      Кроме того Oracle рекомендует использовать InfiniBand для определённого класса решений – облачной инфраструктуры.

                                                                      Зачем был выбран медленный Fiber Channel в свете предыдущего вопроса?
                                                                      Есть существующая инфраструктура, она реализована на FC. Достаточность скорости FC в реальных задачах — вопрос дискуссионный. Очень редко можно увидеть на 100% загруженный SAN.

                                                                      В вашей инсталляции Database на голом железе без виртуализации?
                                                                      Да

                                                                      Что в вашей схеме делают 1 Гигабитные сетевые подключения? Почему не 10G?
                                                                      Потому что у заказчика есть реальная сетевая инфраструктура, в которой пока активно не используется 10G. Была задача сравнить две платформы в существующем окружении.
                                                                      0
                                                                      Эмэсэйка под супердомом, конечно, порадовала :D
                                                                        0
                                                                        Она только для ОС. На самих лезвиях нет мест под диски.
                                                                        +1
                                                                        Из моего опыта архитектура процессора, можно сказать, вообще не влияет на общую производительность. Гораздо важнее параметрвы конфигурации дискового хранилища и роутеров для связи с этим хранилищем.
                                                                        Так что статья не раскрывает полную картину.
                                                                          +1
                                                                          Я думаю, окончательные выводы можно будет делать по результатам реальной эксплуатации. x86 номинально обеспечивает гораздо лучшую производительность/стоимость, но в реальности, так как и сам Linux, и Linux в комплексе с железкой, на которой он стоит – это сборная солянка, то гораздо выше шансы напороться на хитрую несовместимость компонентов внутри системы. А потом начинается перекидывание ответственности. Но можно ли за 450 лямов решить эти проблемы? Наверное, можно.

                                                                          И совсем другое дело, что известная корпорация, подразумеваемая в статье, сейчас делает всё, чтобы подорвать доверие к себе разработчиков, ликвидируя или распродавая один ключевой технологический компонент за другим.
                                                                            +2
                                                                            Я немного далек от банковской сферы, но зачем закупать такие зверские железки, а не накупить кучи обычных серваков, там по 2-4 процессора и считать в каком-нить hadoop-е, если не нужно прям сейчас это посчитать. При том как я понимаю тут нужно в основом считать, а это как раз параллелится отлично, и разница очень небольшая между процессорами последних лет 5ти. Мне не до конца ясна проблема банковкого процессина из статьи, поэтому и спрашиваю. Кажется, что не нужно такой сильно связанности между процессорами.
                                                                              +1
                                                                              Это связано с природой данных и профилем нагрузки, а также с устоявшимися методами их обработки. Hadoop предназначен для решения совсем других задач, нежели отказоустойчивая онлайн репликация боевых баз в базу для хранилища, расчёта агрегатов, и онлайн аналитика для BI. Не стоит путать технологии и архитектуру для распределённых вычислений и работы с большими объёмами не структурированных данных с архитектурой для обработки больших объёмов структурированных транзакционных и партицированных массивов данных.
                                                                              0
                                                                              А почему использовали E7-2890 v2 и DDR3 вместо E7-8890 v3 и DDR4?
                                                                              Сомнительная экономия: Жертва 20% производительности ради 2% денег?
                                                                              Или я что-то не внимательно прочитал?

                                                                              И ещё один вопрос:
                                                                              Чем предложенная конфигурация лучше, чем обычные решения 4 * E7 с самым стандатным соединением по Infiniband EDR?
                                                                              Это гораздо дешевле, чем предложенное в данной статье. Массштабируется в разы крупнее при практически той же пропускной способности. А уменьшение гемороя в настройке/поддержке/апгрейдах, рискну предложить, на порядок меньше будет.
                                                                                0
                                                                                А почему использовали E7-2890 v2 и DDR3 вместо E7-8890 v3 и DDR4?
                                                                                Сомнительная экономия: Жертва 20% производительности ради 2% денег?

                                                                                В данном случае нельзя судить о такой экономии. Такова конфигурация демо-оборудования, которое можно было заказать осенью 2015г.
                                                                                По результатам тестирования заказчик, естественно, может заказать E7 v3 и DDR4.

                                                                                Чем предложенная конфигурация лучше, чем обычные решения 4 * E7 с самым стандатным соединением по Infiniband EDR?

                                                                                Абсолютно другие задачи. Решения Infiniband EDR предназначены для организации облачной инфраструктуры, повышения его сетевой производительности.
                                                                                Можно соединить по Infiniband 4 сервера на процессорах E7, установить на каждый ОС и распределить между ними задачи или запустить несколько приложений, но нельзя собрать один большой 120 ядерный сервер для работы с большой БД. По настройке/поддержке сложно сказать что-то, т.к. пока нет опыта по эксплуатации Infiniband EDR от Oracle, система не так давно анонсирована.
                                                                                0
                                                                                А что тестировали в такой сборке, имея на бэк-енде MSA2040?)
                                                                                  0
                                                                                  Если вопрос ко мне, то у нас back-end на дешёвой супермикре по infiniband, а не HP по FC ни разу.) VMware + Oracle трудятся под наши задачи великолепно. Чего там тестировать? Тысячи раз протестированный ширпотреб. Запустил и работает...)
                                                                                    0
                                                                                    MSA — только для загрузки ОС.
                                                                                      0
                                                                                      MSA2040 используется для операционной системы. Данные для тестирования находились на Hi-end массиве, подключенному по FC.
                                                                                      0
                                                                                      Во всём этом меня страшно смущает, что вы «non-x86» используете для описания дорогущих мейнфреймов.

                                                                                      А IRL есть ещё сервера на армах, и чем дальше, тем их больше. И они тоже x86, но совсем не мейнфреймы.
                                                                                        +1
                                                                                        Так и pSeries не мейнфреймы.
                                                                                        0
                                                                                        «Кроме того, RISC-машины лишены традиционного недостатка x86 при высокой нагрузке — у них не падает производительность при долгой постоянной нагрузке выше 70–80%» — поясните этот бред, пожалуйста?
                                                                                            0
                                                                                            Это выглядит странно в контексте того, что подавляющее большинство суперкомпьютеров работает на х86 в виде Xeon'ов, Xeon'ов Phi и (изредка) Opteron'ов.
                                                                                              0
                                                                                              Это не выглядит странно, сильно разные сценарии.
                                                                                                0
                                                                                                В чём различия?
                                                                                                  0
                                                                                                  Откройте мою статью шестилетней давности https://habrahabr.ru/post/90677/ и ответте на вопрос, почему апач перестал отвечать на запросы, когда loadavg выросла больше 50.
                                                                                                    0
                                                                                                    Погода на Марсе — такая же причина, как и архитектура процессора 17-летней давности. Никакой аргументации в пользу вашей гипотезы я не увидел в статье.

                                                                                                    По поводу высокой постоянной нагрузки — в бытность свою тестировщиком системы биллинга сотовой связи (работала на HP PA-RISC), мы логи выводили в job для spool'ера принтера — чтоб не «вешать» старое железо. У этого самого spooler'а был низкий приоритет процесса.

                                                                                                    Про различия в типе нагрузки вы так же не ответили на вопрос.
                                                                                                      0
                                                                                                      Я не даю готовых ответов, я предлагаю вам изучить вопрос самостоятельно.
                                                                                                        0
                                                                                                        Претензия к вам была в недостаточной, на мой взгляд, обоснованности утверждения о том, что х86 «тупит» при постоянных высоких нагрузках. Не более, не менее.
                                                                                                          0
                                                                                                          Ну, я привожу факты, то, что может проверить любой человек на собственном пц — создать заметно бОльшее количество запросов, чем успевает обрабатывать система и посмотреть к какому эффекту это приводит.
                                                                                                          Если интересно, то надо дальше самими искать. Всяческие сравнения делались и пятнадцать, и пять лет назад, графики поведения высоконагруженных систем публиковались, хотя сейчас найти с ходу неудалось.
                                                                                                          Впринципе, достаточно посмотреть по годам топ бенчмарка olap-систем. Еще даже лет семь назад там никаким x86 не пахло, даже в виде очень многопроцессорных систем.
                                                                                                            0
                                                                                                            Страшная тайна в том, что разработчики «топовых» СУБД (oracle, ibm, hp) так же занимаются (занимались) разработкой risc — процессоров.
                                                                                                              0
                                                                                                              Тайны в этом никакой нет. И про количество потоков на ядро я выше писал.
                                                                                          0
                                                                                          А вы с Хуавэй KunLun 9016/9032, случайно, не сталкивались?
                                                                                          Как там построено связь между процессорами?
                                                                                          Под те же задачи, что и BL920e, он подходит?

                                                                                          Only users with full accounts can post comments. Log in, please.