Обсуждение:Верхнеуровневая архитектура: различия между версиями
Nachinka (обсуждение | вклад) |
|||
| Строка 31: | Строка 31: | ||
--[[Участник:Андрей Чусов|Андрей Чусов]] ([[Обсуждение участника:Андрей Чусов|обсуждение]]) 18:35, 7 июля 2015 (UTC) | --[[Участник:Андрей Чусов|Андрей Чусов]] ([[Обсуждение участника:Андрей Чусов|обсуждение]]) 18:35, 7 июля 2015 (UTC) | ||
В плане доверия к системе со стороны пользователя есть. | |||
--[[Участник:Nachinka|Nachinka]] ([[Обсуждение участника:Nachinka|обсуждение]]) 09:26, 8 июля 2015 (UTC) | |||
=== По СУБД === | === По СУБД === | ||
| Строка 39: | Строка 42: | ||
--[[Участник:Андрей Чусов|Андрей Чусов]] ([[Обсуждение участника:Андрей Чусов|обсуждение]]) 18:35, 7 июля 2015 (UTC) | --[[Участник:Андрей Чусов|Андрей Чусов]] ([[Обсуждение участника:Андрей Чусов|обсуждение]]) 18:35, 7 июля 2015 (UTC) | ||
Второй БД - это пользовательские данные - проекты, результаты расчётов. Может БД, может файловая структура. Модный облачный подход и мобильность пользователя. | |||
--[[Участник:Nachinka|Nachinka]] ([[Обсуждение участника:Nachinka|обсуждение]]) 09:26, 8 июля 2015 (UTC) | |||
=== Use-case === | === Use-case === | ||
| Строка 64: | Строка 70: | ||
--[[Участник:Андрей Чусов|Андрей Чусов]] ([[Обсуждение участника:Андрей Чусов|обсуждение]]) 08:40, 8 июля 2015 (UTC) | --[[Участник:Андрей Чусов|Андрей Чусов]] ([[Обсуждение участника:Андрей Чусов|обсуждение]]) 08:40, 8 июля 2015 (UTC) | ||
Так мы, вроде, под конец обсуждения в итоге пришли к двойному контролю нагрузки. А может даже и три уровня надо продумать. Первый в системе управления. Второй общий для конкретной Предметной области. И третий для отдельного вычислительного узла. | |||
--[[Участник:Nachinka|Nachinka]] ([[Обсуждение участника:Nachinka|обсуждение]]) 09:26, 8 июля 2015 (UTC) | |||
== Вариант структуры с доски | |||
[[Файл:Top structure 2 draft.png]] | |||
Версия 19:26, 8 июля 2015
Версия 1
Создал юз-кейс для централизованного варианта (когда все данные проходят через управляющую подсистему. Схему залил целиком ту, что мы нарисовали (с модификациями для читабельности). Ниже мои мысли по этой схеме.
По HTTPS.
Пользователь должен проходить аутентификацию и авторизацию на сервере - вводить логин/пароль. Процедуру авторизации/аутентификации придется все-равно писать самостоятельно. Предполагалось использовать следующий протокол.
Регистрация:
- Пользователь задает логин
- Пользователь задает ключ аутентификации (либо вычисляет его как хеш от пароля).
- Пользователь, используя известный открытый ключ сервера, шифрует логин/ключ и передает их серверу, сервер их сохраняет.
Аутентификация:
- Клиент генерирует случайную байтовую последовательность Невозможно разобрать выражение (MathML с запасными SVG или PNG (рекомендуется для современных браузеров и инструментов повышения доступности): Недопустимый ответ («Math extension cannot connect to Restbase.») от сервера «https://wikimedia.org/api/rest_v1/»:): CRAND .
- Клиент вычисляет шифр Невозможно разобрать выражение (MathML с запасными SVG или PNG (рекомендуется для современных браузеров и инструментов повышения доступности): Недопустимый ответ («Math extension cannot connect to Restbase.») от сервера «https://wikimedia.org/api/rest_v1/»:): CENC_1=E_{K_A}(CRAND) .
- Клиент в открытом виде посылает Невозможно разобрать выражение (MathML с запасными SVG или PNG (рекомендуется для современных браузеров и инструментов повышения доступности): Недопустимый ответ («Math extension cannot connect to Restbase.») от сервера «https://wikimedia.org/api/rest_v1/»:): CRAND и свой логин на сервер.
- Сервер, после получения запроса с Невозможно разобрать выражение (MathML с запасными SVG или PNG (рекомендуется для современных браузеров и инструментов повышения доступности): Недопустимый ответ («Math extension cannot connect to Restbase.») от сервера «https://wikimedia.org/api/rest_v1/»:): CRAND и логином от клиента, вычисляет Невозможно разобрать выражение (MathML с запасными SVG или PNG (рекомендуется для современных браузеров и инструментов повышения доступности): Недопустимый ответ («Math extension cannot connect to Restbase.») от сервера «https://wikimedia.org/api/rest_v1/»:): SENC_1=E_{K_A}(CRAND) .
- Сервер генерирует случайное Невозможно разобрать выражение (MathML с запасными SVG или PNG (рекомендуется для современных браузеров и инструментов повышения доступности): Недопустимый ответ («Math extension cannot connect to Restbase.») от сервера «https://wikimedia.org/api/rest_v1/»:): SRAND
- Сервер вычисляет Невозможно разобрать выражение (MathML с запасными SVG или PNG (рекомендуется для современных браузеров и инструментов повышения доступности): Недопустимый ответ («Math extension cannot connect to Restbase.») от сервера «https://wikimedia.org/api/rest_v1/»:): SENC_2=E_{K_A}(SRAND) .
- Сервер посылает Невозможно разобрать выражение (MathML с запасными SVG или PNG (рекомендуется для современных браузеров и инструментов повышения доступности): Недопустимый ответ («Math extension cannot connect to Restbase.») от сервера «https://wikimedia.org/api/rest_v1/»:): SRAND и Невозможно разобрать выражение (MathML с запасными SVG или PNG (рекомендуется для современных браузеров и инструментов повышения доступности): Недопустимый ответ («Math extension cannot connect to Restbase.») от сервера «https://wikimedia.org/api/rest_v1/»:): SENC_1 клиенту по открытому каналу.
- Клиент сравнивает Невозможно разобрать выражение (MathML с запасными SVG или PNG (рекомендуется для современных браузеров и инструментов повышения доступности): Недопустимый ответ («Math extension cannot connect to Restbase.») от сервера «https://wikimedia.org/api/rest_v1/»:): CENC_1 и полученный Невозможно разобрать выражение (MathML с запасными SVG или PNG (рекомендуется для современных браузеров и инструментов повышения доступности): Недопустимый ответ («Math extension cannot connect to Restbase.») от сервера «https://wikimedia.org/api/rest_v1/»:): SENC_1 , и, если имеется равенство, аутентификация сервера пройдена.
- Клиент вычисляет Невозможно разобрать выражение (MathML с запасными SVG или PNG (рекомендуется для современных браузеров и инструментов повышения доступности): Недопустимый ответ («Math extension cannot connect to Restbase.») от сервера «https://wikimedia.org/api/rest_v1/»:): CENC_2=E_{K_A}(SRAND) .
- Клиент посылает Невозможно разобрать выражение (MathML с запасными SVG или PNG (рекомендуется для современных браузеров и инструментов повышения доступности): Недопустимый ответ («Math extension cannot connect to Restbase.») от сервера «https://wikimedia.org/api/rest_v1/»:): CENC_2 в открытом виде на сервер.
- Сервер проверяет равенство и Невозможно разобрать выражение (MathML с запасными SVG или PNG (рекомендуется для современных браузеров и инструментов повышения доступности): Недопустимый ответ («Math extension cannot connect to Restbase.») от сервера «https://wikimedia.org/api/rest_v1/»:): SENC_2 и, если равенство истинно, аутентификация клиента пройдена.
При таком протоколе мы проводим аутентификацию и клиента, и сервера за раз. Алгоритмы шифрования при аутентификации используются симметричные, следовательно имеется большая производительность, по сравнению с асимметричными шифрами SSL. Единственное место, где возможно проведение атаки "человек-в-середине" и подмена сервера - регистрация, а именно не подтверждается подлинность открытого ключа сервера.
Имеет ли смысл использовать SSL и HTTPS?
--Андрей Чусов (обсуждение) 18:35, 7 июля 2015 (UTC)
В плане доверия к системе со стороны пользователя есть. --Nachinka (обсуждение) 09:26, 8 июля 2015 (UTC)
По СУБД
Готовым (и поставляемым) продуктом будет сервер со всеми сервисными подсистемами. Таким образом мы будет поставлять и СУБД - MariaDB. Вопрос с лицензированием - не придется ли открывать код?
Еще раз: назначение СУБД2 - бэкапы? Кто будет удалять ненужные проекты, если они хранятся на сервере?
--Андрей Чусов (обсуждение) 18:35, 7 июля 2015 (UTC)
Второй БД - это пользовательские данные - проекты, результаты расчётов. Может БД, может файловая структура. Модный облачный подход и мобильность пользователя. --Nachinka (обсуждение) 09:26, 8 июля 2015 (UTC)
Use-case
Часть юз-кейса с назначением физических параметров модели выглядит немного избыточной. Предлагаю:
- Пользователь обращается к управляющей подсистеме с запросом на ассоциацию данных из СУБД1 с компонентами геометрической модели для выбранной предметной области.
- Управляющая система считывает идентификаторы данных с СУБД2 и ассоциирует их с компонентами модели
- Управляющая подсистема делегирует запрос подсистеме предметной области.
- Подсистема предметной области считывает данные из СУБД напрямую по адресу, предоставленному управляющей подсистемой.
- Подсистема предметной области задает ассоциацию данных с компонентами геометрической модели.
--Андрей Чусов (обсуждение) 18:35, 7 июля 2015 (UTC)
По балансировке нагрузки
В старой схеме
использовалось две системы балансировки нагрузки - глобальная - работающая как подсистема управляющей, и локальные, входящие в конкретную предметную область.
В такой схеме подразумевалось следующее: Подсистема предметной области включает в себя Невозможно разобрать выражение (MathML с запасными SVG или PNG (рекомендуется для современных браузеров и инструментов повышения доступности): Недопустимый ответ («Math extension cannot connect to Restbase.») от сервера «https://wikimedia.org/api/rest_v1/»:): N распределенных ЭВМ, каждая из которых имеет Невозможно разобрать выражение (MathML с запасными SVG или PNG (рекомендуется для современных браузеров и инструментов повышения доступности): Недопустимый ответ («Math extension cannot connect to Restbase.») от сервера «https://wikimedia.org/api/rest_v1/»:): M=\left\{m_1,\cdots, m_N\right\} параллельных вычислителей: CPU и, если допускается использование GPU, то GPU. Соответственно, для предметной области D, задается "глобальная" балансировка нагрузка между элементами , в соответствии со значениями элементов .
Далее задается "локальная балансировка нагрузки" для одной ЭВМ Невозможно разобрать выражение (MathML с запасными SVG или PNG (рекомендуется для современных браузеров и инструментов повышения доступности): Недопустимый ответ («Math extension cannot connect to Restbase.») от сервера «https://wikimedia.org/api/rest_v1/»:): m_i .
Если мы исключим глобальную балансировку нагрузки из управляющей подсистемы, задача по реализации балансировке и управлению распределенными вычислителями предметной области ляжет на разработчика предметной области, хотя если использовать реализацию в виде разделяемого списка, заданного для каждой из предметных областей, мы не привязываемся к конкретным предметным знаниям (для нас параметры модельного эксперимента - просто данные с размером), но избавляем возможного потребителя, реализующего предметную область, от лишней работы и затрат.
--Андрей Чусов (обсуждение) 08:40, 8 июля 2015 (UTC)
Так мы, вроде, под конец обсуждения в итоге пришли к двойному контролю нагрузки. А может даже и три уровня надо продумать. Первый в системе управления. Второй общий для конкретной Предметной области. И третий для отдельного вычислительного узла. --Nachinka (обсуждение) 09:26, 8 июля 2015 (UTC)
