Пенсионный фонд остался удовлетворен результатами эксперимента по переносу части своих сервисов с платформы IBM на платформу, использующую отечественные процессоры и ОС «Эльбрус». Главное преимущество последней — дешевизна. В 2017г. в ПФР планируется закупка 10 российских серверов и миграция на них сервисов информирования застрахованных лиц.
Эксперимент с миграцией данных с IBM на «Эльбрус»
Как стало известно CNews, Пенсионный фонд России (ПФР) провел апробацию технических решений по размещению сервисов информирования застрахованных лиц и баз данных на отечественной программно-аппаратной платформе «Эльбрус». В ходе эксперимента данные с серверов IBM iSeries под управлением СУБД IBM DB2 были перенесены на серверы, использующие процессоры и ОС «Эльбрус», под управлением СУБД PostgerSQL и с применением web-сервера Apache и сервера приложений Tomcat.
Недостатки «Эльбруса»
В ходе сравнительного тестирования быстродействия выполнения операций на действующей и экспериментальной системах в ПФР было выявлено значительное отставание скорости на платформе «Эльбрус» по сравнению с IBM (см. таблицу). Однако в фонде остались удовлетворены такими результатами, и намерены в начале 2017 г. докупить порядка 10 серверов на «Эльбрусах» (два тестовых сервера в ПФР уже есть).
Сравнение стоимости «Эльбрус» и IBM
Как рассказал CNews исполняющий обязанности директора Межрегионального информационного центра (МИЦ) ПФР Константин Янкин, покупка этого «железа» обойдется фонду примерно в p10 млн. В то же время действующая система на IBM стоит околоp130 млн, не считая прикладного ПО. С учетом того, что она на данный момент в значительной степени недозагружена, перенос с нее сервисов информирования застрахованных лиц и передача ее под другие нужды фонда представляются экономически целесообразными.
Перспективы миграции
По словам Янкина, рассматриваемые серверные мощности IBM будут задействованы для автоматизированной системы фонда нового поколения АИС ПФР-2, которая в них остро нуждается, так как в ближайшие два года ведомству необходимо поддерживать и старую, и новую АИС.
Перенос сервисов может состояться в июне 2017 г. Кроме того, в ПФР сейчас рассматривают перспективы использования СХД на 4-ядерных процессорах «Эльбрус». Выпуск линейки этих СХД в августе 2016 г. анонсировала входящая в «Ростех» «Объединенная приборостроительная корпорация».
Технические подробности тестирования
В тестировании принимали участие два сервера на платформе «Эльбрус» с четырьмя 4-ядерными процессорами с тактовой частотой 750 МГц, 96 ГБ оперативной памяти стандарта ЕСС DDR3 1066 MHz, шестью жесткими дисками Toshiba DT01ACA300 емкостью 3 ТБ каждый.
Тестирование быстродействия выполнения операций для платформы Эльбрус в сравнении с быстродействием аналогичных операций для серверов IBM iSeries
| Операция | Средний коэффициент отставания скорости выполнения на iSeries и на «Эльбрус» | Комментарий |
|---|---|---|
| Простые операции чтения данных | от 2,0 до 20,0 | Простые операторы SQL, не требующие выполнения действий с индексами, операторами соединения таблиц, вычислений и др, сложных действий, не включающие WHERE |
| Простые операции с фильтрацией | от 4,0 до 34,0 | Простые операторы SQL, не требующие выполнения действий с индексами, операторами соединения таблиц, вычислений и др, сложных действий, включающие простые условия WHERE |
| Сложные операции с использованием первичных ключей | от 5,0 до 30,0 | Усложненные операторы SQL с использованием индексов, построенных по первичным ключам |
| Сложные операции с использованием индексов | от 7,0 до 60,0 | Сложные операторы SQL с использованием индексов по различным полям и их комбинациям, с операторами соединения таблиц |
| Построение индексов | от 5,0 до 15,0 | Процедуры построения индексов для больших таблиц, в т,ч, для первичных ключей, и для сложных индексов (включающих различные таблицы), |
В качестве одной из главных вероятных причин сравнительно медленного функционирования выполнения действий с СУБД на платформе «Эльбрус» в ПФР указывают значительную оптимизация платформы IBM под СУБД DB2, которая глубоко интегрирована с операционной системой. Другая причина — специализированные возможности ввода-вывода платформы IBM по сравнению с неспециализированной подсистемой ввода-вывода платформы «Эльбрус». Также в фонде обращают внимание на недостаток оперативной памяти, что приводит к необходимости выполнения частых операций ввода-вывода (чтения с жестких дисков), на отсутствие специализированной СХД и на низкую тактовую частоту процессоров «Эльбрус».
Какие сервисы переводят на «Эльбрусы»
Объектом технического эксперимента ПФР является деятельность подразделений фонда по информированию застрахованных лиц о состоянии их индивидуальных лицевых счетов в системе ПФР. Как следует из документов вышеупомянутого тендера, в целом это информирование производится путем передачи застрахованному лицу извещения о состоянии его индивидуального лицевого счета различными способами: лично, в бумажном виде по почте, через единый портал государственных и муниципальных услуг (ЕПГУ), через трансферагентов, с которыми заключены соответствующие соглашения.
Информирование производится по личному запросу застрахованного лица, в зависимости от способа обращения — в письменном или электронном виде.
Организационная подоплека
Описываемые экспериментальные работы прошли в рамках исполнения контракта ПФР, заключенного в феврале 2016 г. по итогам открытого конкурса. При стартовой цене лота в p20 млн договор был заключен с ООО «Лантана текнолоджи» на сумму p19,72 млн. Конкуренцию на тендере ему пыталось составить ООО «Капс интеграция», запросившее за свои услуги p19,87 млн.
При этом в ПФР указывают, что поставщиком программно-аппаратной платформы «Эльбрус» и консультантом при выполнении тестирования выступило ООО «Эльбрус-2000». По базам данных ЕГРЮЛ и «Контур.Фокус», эта структура через своих бывших учредителей связана с соразработчиками процессоров «Эльбрус» — компанией МЦСТ и Институтом электронных управляющих машин им. И.С. Брука.
В МЦСТ на вопросы CNews об участии в проекте на момент выхода публикации не ответили.
Работы осуществлялись с 12 февраля 2016 г. по 25 июля 2016 г. на базе тестового стенда МИЦ ПФР на Сущевском валу в Москве. В основной их части была подготовлена программно-аппаратная платформа на базе процессоров «Эльбрус», разработана процедуры переноса сервисов и необходимых данных, осуществлен мониторинг функционирования сервисов информирования застрахованных лиц, разработано ПО для актуализации данных.
Комментарии
del
Табличка грустноватая.
ПО под БД IBM оптимизировано. Если провести оптимизацию под Postresql, то результаты будут не такие плачевные.
Увы. В реляционных СУБД есть три места, которые на 99% отвечают за производительность приложения:
-- подсистема планирования, переводящая запросы на реляционном языке, например SQL, в последовательность ACID операций над некоторой совокупностью элементарных баз данных "ключ-значение" различного типа (hash, B+ tree, ...);
-- подсистема, переводящая запросы типа CREATE/ALTER TABLE в выбор типа и создание совокупности этих самых простых баз данных "ключ-значение";
-- подсистема, которая обеспечивает работу всех этих элементарных баз данных "ключ-значение".
Две первые подсистемы с вычислительной точки зрения настолько сложны, что их использование согласно мнению одного из лидеров на рынке реляционных СУБД -- Oracle -- оправдано только тогда, когда приложение активно использует запросы CREATE/ALTER TABLE в рамках естественного бизнеспроцесса. Если же схема данных меняется только при апгрейде прикладного ПО, например, при изменении бизнеспроцесса, но не в самом процессе его функционирования, то использование реляционной концепции в подавляющем большинстве случаев является неэффективным. Тот же оракл предлагает для таких дел "в ручном режиме" формировать схему из простых баз типа "ключ-значение" с различными методами доступа, основываясь на конкретном бизнеспроцессе и разрабатывать пользовательский интерфейс уже над ними. Производительность приложений в этом случае возрастает реально на порядки. У подхода один недостаток -- в разы более высокая стоимость разработки и сопровождения. Но, тем не менее, альтернативы нет и пока не предвидится.
Не увы. Вот, например, что делают наши из ИСП РАН: http://llvm.org/devmtg/2016-09/slides/Melnik-PostgreSQLLLVM.pdf
Наши пишут презентации по-русски ... Шутка.
Не увы -- это всего лишь в несколько раз. В лучшем случае. Postgres в любом случае остается между приложением и данными в виде RDBMS. Причем она сама, как и любая реляционнная СУБД, не являющаяся частью ОС, в отличие от того, что имеет место в операционках IBM, по определению находится на прикладном уровне. То, что постргрес и оракл используют файлы, отображаемые на память, ничего в этом отношении не меняет -- эти возможности используются только для работы с файлами хешей и деревьеви не используются планировщиком и транслятором, которые и валят производительность.
Отказ же от RDBMS дает выигрыш в производительности, исчисляемый порядками. Начиная от 2-х в случае самых простых схем, и выше для более сложных, свойственных реальным приложениям. Большей частью это происходит за счет выбрасывания транслятора с SQL и планировщика элементарных запросов типа get-put-del к тем базам, что лежат в самом низу и непоследственно опираются на системные вызовы к ФС. Ключевое элемент в существенном повышении производительности -- полный отказ от реляционных принципов хранения данных, т.е. SQL и способ мышления, основанный на нем фтопку.
Плата за это -- более высокая стоимость разработки и сопровождения за счет увеличения сроков разработки и необходимости привлечь к разработке людей более высокой квалификации, чем это имеет место в случае использования RDBMS и SQL. В принципе, для системы, срок жизни которой исчисляется поколениями, это вообще не вопрос.
А других вариантов то и нет -- либо все будет тормозить в трясине RDBMS, либо будет нормально так летать на уровне, чуть более высоком, чем системный интерфейс.
Для ярых фанатов хранилищ типа key-value: https://www.postgresql.org/docs/9.1/static/hstore.html
Это с версии 9.1, а с 9.5 есть ещё JSON и JSONB: https://www.postgresql.org/docs/9.5/static/datatype-json.html
Это же просто лысый хеш. Ни курсоров, ни транзакций. Собственные правила сравнения ключей, мультибайтные символы и строки, MSB/LSB, IEEE-754 в качестве ключа -- ???
Подход изначально выбран порочный. вместо перехода на PostgreSQL надо было переходить сразу на Cassandra. Проблем с масштабируемостью, как сейчас, не было бы вообще. Были бы вопросы по журналированию транзакций, да. Кстати, этот кус в DB2 отработан на пять с плюсом, в том числе, в смысле быстродействия.
Что касается оптимизации системы, то даже Oracle может ходить к файлам мимо операционной системы, не говоря уж о DB2, куда там пионерам из PostgreSQL...
Мимо операционной системы к файлам пройти никак невозможно -- для доступа к ним есть только один интерфейс и он является частью ОС.
Это если ОС перехватит обращение к "аппаратным" прерываниям, но судя по написанному Внерозниковым в DB2 как раз мимо ОС всё идёт.
DB/2 это обычное платформенно-независимое приложение, которое может быть установлено в системе или не установлено. Если у Вас есть желание, Вы можете зарегистрироваться на IBM Develloper Connection, попросить их прислать Вам DVD с софтом для разработчика, или скачать самостоятельно себе версию и покрутить. Нет там никаких каналов доступа к дискам мимо ОС. Если ОС предоставляет особый уровень доступа к DAS-устройству, специально заточенный под DB/2, та его будет использовать и все на этом. Но это только на их собственных операционках и все равно только через них.
А как насчет Oracle raw devices? Не знаю есть ли подобное в DB2.
RAW это не мимо ОС, а мимо файловой системы ;)
Есть, но это все равно в рамках ОС, а не мимо нее.
Oracle raw devices не более, чем специализированная файловая система, специально заточенная под работу с B-крест деревьями и хешами. Специализированные возможности управления отображением файлов в память, сбросом буферов и прочее. У них как бы "свой" дистрибутив линукса, для которого пишут драйвера и файловые системы, заточенные под их СУБД. То же самое и у IBM, правда те не понтуются, как ораклы, а тихо пишут в рамках редхата драйвера да файловые системы аналогичного назначения. Поскольку у них есть более, чем полувековой опыт в этом деле, то и результат сильно круче.
Понятно, то-есть речи про аналоги INT 21 нет, как и про замену стандартных дров для накопителей.
Тогда уж Int 13, он БИОСовский, а int 21 - ДОСовский
Не знаю , как у других - у UDB есть понятие DMS - в которое входит и файловое хранилище(т.е. без файловой системы никак), так и прямое использование дискового пространства(т.е. диск используется в обход файловой системы, достаточно, что OC видит его на уровне HDD)
Не болтайте ерундой. NoSQL решения хороши до тех пор, пока данные добавляются/удаляются и атомарно выбираются. А попробуйте выполнить хотя бы средний SQL-запросик на них.
Под любой RDBMS лежат non-sql базы данных, типа хешей и деревьев. Любой SQL-запрос представляет собой в конечном итоге последовательность запросов к этим хешам и деревьям для получения первичных ключей, по которым выбираются данные из других хешей или деревьев, которые выдаются на выход. Вопрос в том, будете ли Вы для доступа к этим низкоуровневым базам использовать высокоуровневый SQL-интерфейс, либо самостоятельно будете выполнять все необходимые действия, предварительно самостоятельно создав эти хеши и деревья и собрав их в схему с помощью Вами написанного кода.
Это не я придумал -- это Оракл. В их руководствах написано, что если схема данных в процессе функционирования приложения не меняется, то использование SQL нецелесообразно. Термин такой есть -- Constant Data Base. Это такие базы данных, когда схема доступа меняется только при апгрейде приложения, например, в результате изменения законодательства, а не в процессе штатного функционирования. Так вот для таких систем использование RDBMS и SQL -- либо глупость, либо вредительство.
Ссылочку хоть на одно руководство с таким утверждением можно привести ? Дока на обсуждаемую базу находится здесь http://docs.oracle.com/database/121/nav/portal_booklist.htm
Кроме этой базы у компании Oracle есть еще несколько других баз.
Прямую ссылку на компактный источник не приведу. Зимой 2003-2004 я посещал четырехмесячные курсы ораклов по архитектуре информационных систем для преподавателей. Учились по толстым переводным книгам в переплете из пружинок и некачественно отксеренными картинками на английском. Но преподы были что надо. В книгах была и теория, и примеры, и курсовые задания и даже тренажеры выходных тестов. Детально и на очень низком уровне рассматривались внутренности SQL-ориентированных баз данных, организация хешей, деревьев, низкоуровневые методы доступа, основанные только на get-put-del и курсорах, в каких случаях следует использовать sql, а в каких non-sql с примерами неудачных и удачных решений.
Да, в руководстве по Berkeley DB на этот счет есть немного.
Первый блин комом, но в целом процесс пошёл и его уже не остановить вот так просто. Нужно только как китайцы поступить, т.е. не удваивать количество ядер в процессоре, а сразу забабахать проц для серверов ядер на 100-1000.
Это вопрос не количества ядер, а шины между ними и между ними и памятью.
Странно сравнивать узко-специализированную System I и Эльбрусовский сервер общего назначения. Естественно, допиленное даже не напильником, а алмазной шлифовкой под конкретную задачу будет в разы обгонять универсальную технику. Оговорка про "специализированные возможности ввода-вывода" может подразумевать что угодно. При умном кэшировании некоторые запросы будут обходиться вообще без доступа к жёсткому диску или делать 1-2 таких операции вместо сотни, а тут разница может быть на порядки. Кстати, это не гарантирует такую же скорость реальной работы - бывает и так, что система затачивается перед тестами под конкретные тестовые задачи, а добавь в запросы пару-другую уровней вложенности или поменяй ключи индексации на другие, которые не влезут в кэш и результат может оказаться совсем другим.
В общем, хорошая новость. За IBM десятилетия опыта и миллионы человеко-часов разработки, они делают крутые вещи на которые способен мало кто на рынке и при этом Эльбрус проиграл всё же не в сухую. Для первой попытки результат вполне впечатляющий. И то, что с эльбрусом решили работать дальше, означает что он будет развиваться.
Эльбрус не проиграл, а выиграл :). Т.к. AS/4000 это IBM(железо), OS/400 Это IBM(операционная среда с текстовой консолью), DB/400 это IBM (sql стервер).
Т.е. программно-аппаратный комплекс от одного производителя. К слову о ПФР - в конце 90 начале 00 и клиентская часть была OS/2 от IBM.
Эльбрус это только процессор :) - всё остальное от сторонних производителей. Т.е. солянка.
Чтобы уравнять шансы - эльбрусу придётся создать железо самим, написать свою операционку и это не ядро Торвальда должно быть.
И не взять постгресс - а написать свою систему распределенных запросов.
Тем паче для понятия - под ПТК СПУ (это софт ПФР ) написан свой исполняемый модуль для винды, а новый софт тестировали в связке apache+postgre - заведомо неравные условия :).
Всё это хорошо конечно , ПФР раскошелится на много серверов эльбрус, но .. у ПФР проблема в том, что очень много софта написано в не единой информационной среде. Поэтому штаты раздуты запредельно. А смена 1 комплекса проблемы не решит :\.
> OS/400 Это IBM (операционная среда с текстовой консолью),
Графический интерфейс на терминалах IBM 8514 (1024x768) был во времена выхода IBM DOS 4.0x, а может и раньше -- я просто одновременно увидел и то и другое. Этот IBM DOS 4.0x, кстати, имел наряду с командной строкой и графическую оболочку. К этому времени был выпущен и утвержден документ, регламентирующий CUA вплоть до клавиатурных шоткатов, который и был реализован на этих терминалах. А текстовая консоль -- без нее в принципе невозможно. Это единственный полноценный интерфейс с операционной системой.
> DB/400 это IBM (sql стервер).
DB/2
В ПФР нет грф консоли - только 80x25 именно на as/400.
DB/2 - это UDB под OS/2 почившей в бозе после выпуска Авроры
В смысле, ИС ПФР представляет собой консольное приложение? Ну так это естественно -- нет там ничего такого, что требовало бы графического интерфейса. Это же на САПР, в конце концов. Тем не менее, OS/400 имеет отличный графический интерфейс на X-терминалах.
приложение не консольное, а вот сервер - консольный.
Имеешь в виду DOS Shell?
Так так это скорей был Нортон командер, только не в текстовом, а графическом режиме. Визуальная разница - только в шрифтах
Да, DOS shell. Насчет нортон-коммандера вы наверное смеетесь -- дос-шелл полностью и строго поддерживал CUA интерфейс в том самом виде, в котором он существует и ныне. А двухпанельный файловый менеджер -- это стандарт де-факто, придуманный задолго до nc.exe. Мало того, дос-шелл был на порядок более функционален, позволял нормально запускать несколько программ и их переключать, в то время как nc.exe не мог ни одну програму запустить корректно -- у него в обвязке вызова INT 21:4Bh была
ошибкафича с возвратом памяти, что приводило к его краху, если программа, которая запускалась, использовала интерфейс к XMS или EMS -- дос-экстендер ей выделял блок памяти, в котором еще оставался не проигранный до конца кусок оверлея nc.exe. Это так доставало, что приходилось программы запускать из мультиэдита. Надо отметить, vc.exe в этом отношении вел себя более аккуратно.Меня как то DOS shell не впечатлил, пользовался DOS-Навигатором. Удобнейший шелл, нет только мультизадачности (но то ограничения ДОС).
Когда они отдали его исходники, принимал некоторое участие в его дальнейшей свободной разработке. Даже в хелпе упомянут среди авторов, правда в русской локали сделали не совсем правильный обратный перевод фамилии, но то мелочи.
Прекрасная оболочка.
Не странно если они выполняют одну и ту же задачу. Оценка вида производительность/цена вполне допустима.
Разговоры о том что Эльбрус только процессор делает и с ПО пока проблемы и тп. не более чем оправдания.
Другое дело, что надо принять как данность: мы в этой сфере отстаем. Принять и делать все для того что бы догнать потенциального соперника. Например, покупать отечественную технику не смотря на ее недостатки.
ИМХО это правильно.
Имхо, речь идет о принципильном переносе на неподконтрольные пиндосам типы желеща и по. Во избежании, так сказать.
не улыбайте меня.
Коммуникационное железо CISCO,3COM, КСПД ТЛФ - NEC, Внутренняя система на AD, Весь софт под windowZ, Программных комплексов не менее 5-6. Да .. тот комплекс один из базисных - который менять хотят. НО! его смена - это очень долгий процесс, т.к. он очень навороченный в плане всяческих юридических ньюансов. Так что вполне вероятно, что просто сохранят софт, просто "Эльбрусы" оставят как вторичный сервер хранения :) .... для показухи(галочки)
p.s. упороть всю систему достаточно легко выпустив обновление для виндоуза вшив в него диструкцию, которая сработает к примеру ровно через 100 дней с момента установки. Кстати диструкцию можно сделать перманентно частичной, т.е. удалять пользовательские файлы выборочно .. 10-15% и системные 1-2%.
Как думаете быстро найдётся причина :)? А сколько времени будет стоять ПФР? А пенсионеры и работодатели будут довольны отмазкой:- по тех причинам ваша пенсия не перечислена на ваш пенс счёт?
p.s.s. На самом деле я очень рад что Эльбрус выходит на госструктуру. Это очень важно!!!! Просто реалии и наболевшее :)
Диструкция - это что?
Инструкция или деструкция?
К табличке надо подключить данные о цене вопроса из основного текста и оно станет веселее, проблем с э-э и площадями у нас нет.
Почему грустноватая? Система вообще-то13 раз дешевле.
А так, вообще странное сравнение.
Для указанных операций бОльшее значение имеет скорость работы дисковой подсистемы, чем ЦП.
Да и не описано конкретно, что и как сравнивалось.
Да и не знаю, как сейчас, но раньше, сталкиваясь с софтом от программистов ПФ, крайне сложно было оставаться о них высокого мнения, скорее наоборот.
Так что еще вопрос, удалось ли им грамотно, объективно и независимо сравнить системы.
Я надеюсь, они наши пенсии не будут хранить на десктопных жестких дисках, которые были в тесте. А то как-то страшноватенько.
нет никаких данных о конфигурации IBM-системы, а без них сравнение гроша ломаного не стОит.
правильное замечание. Статья с попыткой дискредитировать "Эльбрус".
один прокол тут всё же есть - "она на данный момент в значительной степени недозагружена,"
кто делал сайзинг и эвейлебилити?
Косвенно указано что на больших голубых оперативы существенно больше и поэтому на эльбрусах были частые свопы.
Вроде писали, что Эльбрусы работают с DDR2? Винчестеры опять же.
Ну теоретически, если система правильно построена, при отставании в 10 раз достаточно установить в 10 раз больше серверов и всё будет работать как раньше.
:-)
Отчего бы и нет? Вводят данные в одном сервере, потом реплицируют на кучу тех, что делают отчёты.
Мне вот ещё интересно - пробовали ли оптимизацию постгресовского кода делать, под Эльбрусовскую архитектуру?
сравнивать db2 с PostgerSQL
это что то
Страницы