Есть ли место ГРИДам среди суперкомпьютеров? - Страница 2 - Есть ли место ГРИДам среди суперкомпьютеров? - Страница 2 - Форум

#11 · 04.12.2022, 17:28

Цитата: hoarfrost от 04.12.2022, 17:28
Пункт № 2. А кому их надо строить?

Упомянув о важности результатов СК, перейдём к более приземлённой проблеме - к наличию заказов на них. Или, наоборот - отсутствию. И вот тут вспомним, что в последние лет 10-15 очень сильно выросли облачные провайдеры, дата-центры и услуги которых очень сильно приблизились к тому, что ещё недавно можно было получить только на суперкомпьютерах. Дело дошло уже до GPU-расчётов в облаках! Да, самые передовые суперкомпьютеры - ушли от этой точки вперёд, но опыт, который есть у производителей суперкомпьютеров, уверен, может быть полезен для строительства облачных машин. И масштабы-то там, не маленькие! Надо бороться за их заказы.

При попытке получить заказы от облачных провайдеров, можно столкнутся с жёсткой ценовой конкуренцией со стороны других производителей. Но вот конкретно сейчас, кстати, с этим-то может быть и проще. Но есть и другой рынок, где стоимость непосредственно железа, как бы это странно для многих не казалось - почти не важна. Это то, что иногда называют "Enterprise market" или "Корпоративный сегмент". Поясню в чём дело.

Когда дело доходит то каких-то критично важных iT-сервисов, без которых работа компании остановится или от которых могут зависеть десятки миллионов рублей в день, то большие компании, как правило, очень резко перестают хотеть делать что-либо сами и всеми силами стремятся купить решение под ключ. А в таких решениях основная стоимость приходится не на железо, а на лицензирование использование самого решения, а также на техническую поддержку. В качестве примера такого решения приведу программно-аппаратный комплекс Oracle Exadata в варианте X9M-2. Как пример он удобен и тем, что часто используется и тем, что базовые цены находятся в общем доступе. При закупках цены будут отличаться. Но чтобы они отличались существенно, объёмы закупок должны быть просто неимоверными (думаю что эдак "стойками в год").

Итак, обратимся к цифрам, чтобы всё стало яснее.

Exadata Full Rack - это стойка в которую входят:

(db nodes) 8 серверов размера 1U с мощными процессорами и большим объёмом RAM;

(storage cells) 14 серверов размера 2U c 12 HDD и 8 NVMe Flash-карт в каждом и уже менее мощными CPU;

Коммутаторы InfiniBand или 100 GbE для соединения всех этих серверов вместе, коммутаторы для подключания этой стойки в сеть организации;

ИБП, всякие внутренние розетки и, собственно, сама стойка.

Сервера, что интересно, серверами не называются. Они называются предельно чётко и ясно - узлами (nodes), внутренняя сеть - интерконнект, а программное обеспечение уже самого Oracle, которые позволяет использовать Exadata в кластерном режиме - Grid Infrastructure. И это неспроста, потому что это и есть самый натуральный кластер. Причём интерконнект в нём высокоскоростной не для рекламы, а потому что реально нужен, в определённый момент мы наращивали число db nodes для того, чтобы увеличить суммарную пропускную способность портов IB, после чего время скажем так "обработки данных" упало на часика 2-3 из часов 8-10-12.

А теперь к ценам. Половина стойки (Half Rack) стоит ~ $1 100 000. Но для того, чтобы на всё этом железе работало ещё и программное обеспечение (его там целый стэк) то как минимум, надо взять лицензии на использование так называемого storage server software - по $10 000 на каждый HDD. В случае Half Rack это (7 серверов) *(12 HDD/сервер)* $10000/HDD = $840000. Также, необходимо иметь лицензии на использование непосредственно самой СУБД Oracle Database. Они бывают "процессорные" и "пользовательские". Поскольку в случае аналитических систем посчитать число пользователй либо невозможно, либо придётся записывать всю компанию, то приходится брать CPU-шные. А это ... от $47500 на каждое ядро в случае x86. В этой половинке (Half Rack) Exadata это ядра в db nodes или: 4 сервера (db node) * 2 процессора/сервер * 32 ядра/процессор = 256 ядер. Итого от $12 160 000. Поскольку систем на Oracle (но не обязательно на Exadata) в любой крупной организации очень много, то чтобы не платить насколько много за CPU-лицензии, крупные компании договариваются о покупке специальной безлимитной лицензии. Поэтому вот эти $12 миллионов мы не учитываем (но в голове держим, ещё пригодится).

А теперь самое интересное. Отложив в сторону лицензию на Database получаем $1 100 000 за железку и $840 000 за "лицензии на HDD" (на самом деле на софт, работающий на стороне storage cell-ов, поэтому лицензируемый по HDD). Но это только начало. Когда вы покупаете подобную систему, то вам надо купить и её техподдержку. У её производителя. За ~ 22% в год. И за hardware и за software. Техподдержка железа, конечно, обеспечивает, бесплатную замену компонентов, но в реальности ломается что-то редко и реальную стоимость этого обслуживания может не учитывать - она на уровне нескольких процентов от стоимости железа. И в итоге, лет за 5-6, в течение которых, компоненты системы будут работать в ней до списания или вывода из-под лицензирования (чтобы перенести лицензии на более новое железо), к первоначальному ценнику в ~ $1 940 000 добавится ещё $2 134 000.

Итого, в течении 5 лет из $4 074 000, непосредственно за железо компания отдаст $1 100 000, а всё остальное ($2974000) - по сути, лицензионные платежи, без которых вы просто не сможете легально использовать систему. Плюс, держим в уме, ту самую Unlimited-лицензию. И вот тут для наших производителей, при условии правильного взаимодействия с разработчиками ПО, открывается широчайшее окно вне зависимости от того, какое железо они будут производить - с x86, Эльбрусом, RISC-V, ARM, ... . Даже если наш производитель будет делать сервер с CPU x86 и производителю компонентов будет уходить 100% от стоимости сервера (что очень сильно не так), производителю системы в целом может уходить 75% от итоговой стомости системы (на масштабах 5 лет) и она будет вполне конкуретноспособна. В масштабах страны - это колоссальные средства, которые могут поднять индустрию, отфильтровывая плохие решения и оставляя хорошие.

Более того, это процесс уже идёт. Посмотрим, что будет дальше.

Итого, если мы возвращаемся к вопросу в заголовке пункта "А кому их надо строить" (т.е. "для кого?") - то ответ простой: один из целевых (и, подозреваю, что очень немалых) рынков - это кластерные системы для аналитических хранилищ данных (но не только они!) крупных организаций и облачных провайдеров. Возможно, что это не полный список. Но это то, что я хотел "подсветить".

Совершенно логично мы подходим к следующему вопросу - а что будет если сервера (как базовые блоки любой вычислительной системы) будут не на EPYC или Xeon, а на Эльбрус-ах например?

Продолжение следует...

Пункт № 2. А кому их надо строить?

Упомянув о важности результатов СК, перейдём к более приземлённой проблеме - к наличию заказов на них. Или, наоборот - отсутствию. И вот тут вспомним, что в последние лет 10-15 очень сильно выросли облачные провайдеры, дата-центры и услуги которых очень сильно приблизились к тому, что ещё недавно можно было получить только на суперкомпьютерах. Дело дошло уже до GPU-расчётов в облаках! Да, самые передовые суперкомпьютеры - ушли от этой точки вперёд, но опыт, который есть у производителей суперкомпьютеров, уверен, может быть полезен для строительства облачных машин. И масштабы-то там, не маленькие! Надо бороться за их заказы.

При попытке получить заказы от облачных провайдеров, можно столкнутся с жёсткой ценовой конкуренцией со стороны других производителей. Но вот конкретно сейчас, кстати, с этим-то может быть и проще. Но есть и другой рынок, где стоимость непосредственно железа, как бы это странно для многих не казалось - почти не важна. Это то, что иногда называют "Enterprise market" или "Корпоративный сегмент". Поясню в чём дело.

Когда дело доходит то каких-то критично важных iT-сервисов, без которых работа компании остановится или от которых могут зависеть десятки миллионов рублей в день, то большие компании, как правило, очень резко перестают хотеть делать что-либо сами и всеми силами стремятся купить решение под ключ. А в таких решениях основная стоимость приходится не на железо, а на лицензирование использование самого решения, а также на техническую поддержку. В качестве примера такого решения приведу программно-аппаратный комплекс Oracle Exadata в варианте X9M-2. Как пример он удобен и тем, что часто используется и тем, что базовые цены находятся в общем доступе. При закупках цены будут отличаться. Но чтобы они отличались существенно, объёмы закупок должны быть просто неимоверными (думаю что эдак "стойками в год").

Итак, обратимся к цифрам, чтобы всё стало яснее.

Exadata Full Rack - это стойка в которую входят:

(db nodes) 8 серверов размера 1U с мощными процессорами и большим объёмом RAM;
(storage cells) 14 серверов размера 2U c 12 HDD и 8 NVMe Flash-карт в каждом и уже менее мощными CPU;
Коммутаторы InfiniBand или 100 GbE для соединения всех этих серверов вместе, коммутаторы для подключания этой стойки в сеть организации;
ИБП, всякие внутренние розетки и, собственно, сама стойка.

Сервера, что интересно, серверами не называются. Они называются предельно чётко и ясно - узлами (nodes), внутренняя сеть - интерконнект, а программное обеспечение уже самого Oracle, которые позволяет использовать Exadata в кластерном режиме - Grid Infrastructure. И это неспроста, потому что это и есть самый натуральный кластер. Причём интерконнект в нём высокоскоростной не для рекламы, а потому что реально нужен, в определённый момент мы наращивали число db nodes для того, чтобы увеличить суммарную пропускную способность портов IB, после чего время скажем так "обработки данных" упало на часика 2-3 из часов 8-10-12.

А теперь к ценам. Половина стойки (Half Rack) стоит ~ $1 100 000. Но для того, чтобы на всё этом железе работало ещё и программное обеспечение (его там целый стэк) то как минимум, надо взять лицензии на использование так называемого storage server software - по $10 000 на каждый HDD. В случае Half Rack это (7 серверов) *(12 HDD/сервер)* $10000/HDD = $840000. Также, необходимо иметь лицензии на использование непосредственно самой СУБД Oracle Database. Они бывают "процессорные" и "пользовательские". Поскольку в случае аналитических систем посчитать число пользователй либо невозможно, либо придётся записывать всю компанию, то приходится брать CPU-шные. А это ... от $47500 на каждое ядро в случае x86. В этой половинке (Half Rack) Exadata это ядра в db nodes или: 4 сервера (db node) * 2 процессора/сервер * 32 ядра/процессор = 256 ядер. Итого от $12 160 000. Поскольку систем на Oracle (но не обязательно на Exadata) в любой крупной организации очень много, то чтобы не платить насколько много за CPU-лицензии, крупные компании договариваются о покупке специальной безлимитной лицензии. Поэтому вот эти $12 миллионов мы не учитываем (но в голове держим, ещё пригодится).

А теперь самое интересное. Отложив в сторону лицензию на Database получаем $1 100 000 за железку и $840 000 за "лицензии на HDD" (на самом деле на софт, работающий на стороне storage cell-ов, поэтому лицензируемый по HDD). Но это только начало. Когда вы покупаете подобную систему, то вам надо купить и её техподдержку. У её производителя. За ~ 22% в год. И за hardware и за software. Техподдержка железа, конечно, обеспечивает, бесплатную замену компонентов, но в реальности ломается что-то редко и реальную стоимость этого обслуживания может не учитывать - она на уровне нескольких процентов от стоимости железа. И в итоге, лет за 5-6, в течение которых, компоненты системы будут работать в ней до списания или вывода из-под лицензирования (чтобы перенести лицензии на более новое железо), к первоначальному ценнику в ~ $1 940 000 добавится ещё $2 134 000.

Итого, в течении 5 лет из $4 074 000, непосредственно за железо компания отдаст $1 100 000, а всё остальное ($2974000) - по сути, лицензионные платежи, без которых вы просто не сможете легально использовать систему. Плюс, держим в уме, ту самую Unlimited-лицензию. И вот тут для наших производителей, при условии правильного взаимодействия с разработчиками ПО, открывается широчайшее окно вне зависимости от того, какое железо они будут производить - с x86, Эльбрусом, RISC-V, ARM, ... . Даже если наш производитель будет делать сервер с CPU x86 и производителю компонентов будет уходить 100% от стоимости сервера (что очень сильно не так), производителю системы в целом может уходить 75% от итоговой стомости системы (на масштабах 5 лет) и она будет вполне конкуретноспособна. В масштабах страны - это колоссальные средства, которые могут поднять индустрию, отфильтровывая плохие решения и оставляя хорошие.

Более того, это процесс уже идёт. Посмотрим, что будет дальше.

Итого, если мы возвращаемся к вопросу в заголовке пункта "А кому их надо строить" (т.е. "для кого?") - то ответ простой: один из целевых (и, подозреваю, что очень немалых) рынков - это кластерные системы для аналитических хранилищ данных (но не только они!) крупных организаций и облачных провайдеров. Возможно, что это не полный список. Но это то, что я хотел "подсветить".

Совершенно логично мы подходим к следующему вопросу - а что будет если сервера (как базовые блоки любой вычислительной системы) будут не на EPYC или Xeon, а на Эльбрус-ах например?

Продолжение следует...

AlexA и Шмяка отреагировали на эту запись.

#12 · 04.12.2022, 18:18

Цитата: AlexA от 04.12.2022, 17:17

Хм, все сегодня нами сегодня написанное уже перекопипастили на Пикабу ?

Ага

#13 · 04.12.2022, 19:14

Цитата: hoarfrost от 04.12.2022, 19:14
Пункт № 3. Эльбрус.

В декабре 2021 года в iT-рунете хорошенько протрезвонились новости вида "Серверы на базе «Эльбрус» не прошли тесты Сбербанка, но не всё потеряно". Думаю, пришло время добавить "от себя".

Сначала напомню, что в однажды нам удалось подключить к RakeSearch несколько серверов на Эльбрусах. И сейчас их в нашем проекте нет прежде всего потому, что тот поиск закончился, а новое приложение есть только под Windows.

А теперь к производительности и к тому, как её воспринимают. Если сравнить однопоточную производительность Эльбруса и современных серверных или дектопных процессоров, то она конечно ниже. Чтобы понять к чему это приводит... или не приводит вспомним немного о том, что представляют из себя большие системы корпоративного сектора.

Большую их часть (если не почти все) можно приписать к одному из двух видов: транзакционные и аналитические. Например, когда вы оплачиваете покупку в магазине платёжной картой, то в информационных системах магазина и банка появляется по несколько записей, связанных с ней. Это транзакционные системы. А вот когда после закрытия очередного операционного дня данные по всем покупкам за день сначала попадают в аналитическое хранилище, а потом обрабатываются, то это выполняют уже аналитические системы.

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

Аппаратный слой Систем хранилищ данных (они же - DWH) - это всегда многоядерная система из десятков, сотен или даже тысяч ядер, а сама обработка (даже отдельных крупных запросов) идёт в параллельном режиме и в большинстве процессов важна валовая производительность ядер. Если поток на Эльбрусе будет работать в 4 раза медленее, но самих ядер будет в 4 раза больше, то мы получим примерно тоже самое время обработки данных.

В транзакционных системах, на первый взгляд, ситуация принципиально другая..., но ведь на такие системы, всё время, каждую секунду падают десятки, а то и сотни запросов в секунду, если не тысячи. (Если 150 миллионов человек будут делать по 1 покупке в день, то это уже 1736 транзакций в секунду). Поэтому, предполагаю (вот здесь - я уже именно предполагаю), что даже в транзакционных системах обычной ситуацией является одновременная работа процессов от нескольких транзакций на одном ядре. Ну а коли так, то и здесь мы приходим к той же ситуации, что и в аналитических системах - меньшая производительность ядра? Хорошо! Берём больше ядер.

И, если для полноты картины, мы сравним, для примера, характеристики Эльбрус-16C и Xeon Platinum 8380 (из последнего поколения Xeon Scalable), то что мы увидим:

16 ядер против 40;

2.00 ГГц (в модели 1891ВМ03A против 2.30 ГГц (базовая, при нагрузке на все ядра, фактическая до неё и опустится);

Тепловыделение в 130 Ватт против 270 Ватт;

Из чего следует, что поставив в один сервер 4 CPU Эльбрус-16C, мы может быть получим производительность сопоставимую с сервером на топовых Xeon-ах. Конечно, сравнивать только частоту - не особо правильно, не обладая информацией об эффективности её использования процессором. Но некоторая информация-то у нас есть, как раз от экспериментов в RakeSearch, в рамках которых на Эльбрусах запускались расчёты, по сути, максимально для него неудобные. И если уж там мы получили примерно одинаковую эффективность, то в других приложениях мы можем получить и нечто ещё более хорошее.

Отсюда очень простой вывод: Производителям и такие сервера и вычислительные системы на их базе надо делать, сотрудничать при этом, с компаниями, которые будут предлагать на них основе системы под ключ и на основе этого, первоначального потока средств, может быть даже с некоторой переплатой (которая всё равно несущественна в случае критически важных систем) - развивать производство.

И эти системы могут быть одним из продуктов суперкомпьютерной отрасли, которые уйдут в отрасль финансов, телекоммуникаций, торговли и т.д.

Конец.

Пункт № 3. Эльбрус.

В декабре 2021 года в iT-рунете хорошенько протрезвонились новости вида "Серверы на базе «Эльбрус» не прошли тесты Сбербанка, но не всё потеряно". Думаю, пришло время добавить "от себя".

Сначала напомню, что в однажды нам удалось подключить к RakeSearch несколько серверов на Эльбрусах. И сейчас их в нашем проекте нет прежде всего потому, что тот поиск закончился, а новое приложение есть только под Windows.

А теперь к производительности и к тому, как её воспринимают. Если сравнить однопоточную производительность Эльбруса и современных серверных или дектопных процессоров, то она конечно ниже. Чтобы понять к чему это приводит... или не приводит вспомним немного о том, что представляют из себя большие системы корпоративного сектора.

Большую их часть (если не почти все) можно приписать к одному из двух видов: транзакционные и аналитические. Например, когда вы оплачиваете покупку в магазине платёжной картой, то в информационных системах магазина и банка появляется по несколько записей, связанных с ней. Это транзакционные системы. А вот когда после закрытия очередного операционного дня данные по всем покупкам за день сначала попадают в аналитическое хранилище, а потом обрабатываются, то это выполняют уже аналитические системы.

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

Аппаратный слой Систем хранилищ данных (они же - DWH) - это всегда многоядерная система из десятков, сотен или даже тысяч ядер, а сама обработка (даже отдельных крупных запросов) идёт в параллельном режиме и в большинстве процессов важна валовая производительность ядер. Если поток на Эльбрусе будет работать в 4 раза медленее, но самих ядер будет в 4 раза больше, то мы получим примерно тоже самое время обработки данных.

В транзакционных системах, на первый взгляд, ситуация принципиально другая..., но ведь на такие системы, всё время, каждую секунду падают десятки, а то и сотни запросов в секунду, если не тысячи. (Если 150 миллионов человек будут делать по 1 покупке в день, то это уже 1736 транзакций в секунду). Поэтому, предполагаю (вот здесь - я уже именно предполагаю), что даже в транзакционных системах обычной ситуацией является одновременная работа процессов от нескольких транзакций на одном ядре. Ну а коли так, то и здесь мы приходим к той же ситуации, что и в аналитических системах - меньшая производительность ядра? Хорошо! Берём больше ядер.

И, если для полноты картины, мы сравним, для примера, характеристики Эльбрус-16C и Xeon Platinum 8380 (из последнего поколения Xeon Scalable), то что мы увидим:

16 ядер против 40;
2.00 ГГц (в модели 1891ВМ03A против 2.30 ГГц (базовая, при нагрузке на все ядра, фактическая до неё и опустится);
Тепловыделение в 130 Ватт против 270 Ватт;

Из чего следует, что поставив в один сервер 4 CPU Эльбрус-16C, мы может быть получим производительность сопоставимую с сервером на топовых Xeon-ах. Конечно, сравнивать только частоту - не особо правильно, не обладая информацией об эффективности её использования процессором. Но некоторая информация-то у нас есть, как раз от экспериментов в RakeSearch, в рамках которых на Эльбрусах запускались расчёты, по сути, максимально для него неудобные. И если уж там мы получили примерно одинаковую эффективность, то в других приложениях мы можем получить и нечто ещё более хорошее.

Отсюда очень простой вывод: Производителям и такие сервера и вычислительные системы на их базе надо делать, сотрудничать при этом, с компаниями, которые будут предлагать на них основе системы под ключ и на основе этого, первоначального потока средств, может быть даже с некоторой переплатой (которая всё равно несущественна в случае критически важных систем) - развивать производство.

И эти системы могут быть одним из продуктов суперкомпьютерной отрасли, которые уйдут в отрасль финансов, телекоммуникаций, торговли и т.д.

Конец.

V0d01ey и Шмяка отреагировали на эту запись.

#14 · 04.12.2022, 19:14

Цитата: SETI_Home_v8 от 04.12.2022, 18:18

Цитата: AlexA от 04.12.2022, 17:17

Хм, все сегодня нами сегодня написанное уже перекопипастили на Пикабу

Ага

А ссылку-то на BOINC.Ru поставили?

#15 · 04.12.2022, 19:18

Цитата: hoarfrost от 04.12.2022, 19:14

Цитата: SETI_Home_v8 от 04.12.2022, 18:18

Цитата: AlexA от 04.12.2022, 17:17

Хм, все сегодня нами сегодня написанное уже перекопипастили на Пикабу

Ага

А ссылку-то на BOINC.Ru поставили?

да

#16 · 04.12.2022, 19:20

Цитата: hoarfrost от 04.12.2022, 19:14

Цитата: SETI_Home_v8 от 04.12.2022, 18:18

Цитата: AlexA от 04.12.2022, 17:17

Хм, все сегодня нами сегодня написанное уже перекопипастили на Пикабу

Ага

А ссылку-то на BOINC.Ru поставили?

Есть там всё.
А написал ты реально много и по делу. Чувствую - наболело.

#17 · 04.12.2022, 19:52

Уже в рамках обычного обсуждения, отмечу, что показательно было и то, что когда называли компоненты которые надо научиться делать самим, то среди них были и CPU, конечно, и RAM и материнские платы и сеть и ещё что-то... но ни разу не вспомнили про то, на чём надо данные хранить. Про HDD, SSD, оптические диски, ленты и пр.пр.пр. А вообще-то без этого, всё остальное теряет смысл. И эти технологии тоже надо развивать. Очень хорошо, что делаем storage-ы. Надо учиться делать HDD. Хоть какие-то! А если, к примеру, сможем сделать надёжные HDD с другой конструкцией позиционирования головок, увеличив их число, то может быть и рынок в каком-то сегменте захватим. Окончательно списывать HDD ещё чуток рановато.

#18 · 04.12.2022, 19:58

Ещё немного про Гриды из ПК. Возможно, что стоит чётко и ясно донести до публики, в каких областях РВ можно точно применять. Например, как я понимаю, едва ли не весь виртуальный скрининг можно переносить с кластеров на проекты РВ. Правда, могут быть проблемы с лицензированием ПО для докинга... но если это так, то вот тут уже вопрос к нашей СК-отрасли - а где наше?

Шмяка отреагировал на эту запись.

#19 · 04.12.2022, 20:28

Цитата: hoarfrost от 04.12.2022, 19:58

Правда, могут быть проблемы с лицензированием ПО для докинга... но если это так, то вот тут уже вопрос к нашей СК-отрасли - а где наше?

Один из вариантов решения лицензионной проблемы нашли в USPEX-е. Несколько сложнее в вычислительном плане (шифрование и пр.) но вполне решаемо.

#20 · 04.12.2022, 21:05

Цитата: AlexA от 04.12.2022, 20:28

Цитата: hoarfrost от 04.12.2022, 19:58

Правда, могут быть проблемы с лицензированием ПО для докинга... но если это так, то вот тут уже вопрос к нашей СК-отрасли - а где наше?

Один из вариантов решения лицензионной проблемы нашли в USPEX-е. Несколько сложнее в вычислительном плане (шифрование и пр.) но вполне решаемо.

Ну это "так себе вариант". И в любом случае своё ПО вот для таких задач, точно должно в наличии. И мне кажется что оно-таки должно где-то быть. Может быть даже я о нём просто не знаю, потому что не занимался этой задачей.