По установке. Любой проект с использованием магистрального оборудования прорабатывается индивидуально. Это не массмаркет.
Зарубежные решения не поставляют решения с отечественной криптографией. А на отечественном рынке, это пока единственное решение работающее на таких скоростях.
В смартфонах используется не технология eSIM IoT/M2M, а другая технология – eSIM Consumer. Одновременно на 1 eSIM может быть «активным» (зарегистрированным в мобильной сети) только 1 абонентский профиль. Вы можете переключать профили, по собственному желанию, но связь будет работать только через «активный»....
Оформить Договор на оказание услуг связи и получить чипы можно, расценки на сайте https://moskva.mts.ru/business/internet-veshhey-iot-m2m/uslugi/esim-iot.
Обратитесь пожалуйста к вашему персональному менеджеру в МТС или напишите сюда esim_iot@mts.ru
загрузка профиля любым способом, кроме описанного в стандартах GSMA (при производстве чипа или через оператора) является отклонением от стандарта и не является eSIM IoT/M2M.
Да, список оборудования верный и конечно же список не ограничивается перечисленным оборудованием. Важно обращать внимание ещё на прошивки модулей связи, т.к. прошивки для РФ и Европы могут различаться у производителей.
См. ответ выше. Технически, на работу с разными операторами связи ограничений нет. Тут важно, что бы другие операторы связи у себя запустили eSIM IoT/M2M и выполнили подключение своих платформ SM-DP к SM-SR МТС.
Убедились лично, что поддерживается много модулей SIMCOM и Quectel, так же Telit и Cinterion.
Список модулей есть. Позже опубликуем на нашем сайте единый список. Если кратко, то eSIM поддерживают большое количество модулей 2/3/4G и NB-IoT. Ниже в статье есть ссылки на дистрибьютеров модулей и производителей, с кем проводилось взаимное тестирование, можно у них запросить проверенные модели.
Да, можно приобрести. Для приобретения eSIM IoT/B2B обратитесь к своему персональному менеджеру в МТС или оставьте заявку тут: https://moskva.mts.ru/business/anketa?t=esim_iot&d=152
Здравствуйте! МТС поддерживает заключение договора на оказание услуг связи и «продажу» eSIM-чипов на всей территории РФ. Услуги связи с eSIM-чипа могут работать по всему миру (согласно тарифу).
Про других операторов не скажем - пусть лучше каждый скажет за себя самостоятельно.
Технология безопасна. Криптографическая защита по стандартам GSMA.
У оператора есть ключи доступа у «перепрограммированию» (управлению) eSIM-чипа. Управлять eSIM-чипом IoT/M2M может только оператор связи и никто другой.
Для приобретения eSIM IoT/B2B обратитесь к своему персональному менеджеру в МТС или оставьте заявку тут: https://moskva.mts.ru/business/anketa?t=esim_iot&d=152
Здравствуйте! Стандарт eSIM IoT/M2M не накладывает технологических ограничений и технически оборудование может производиться и тестироваться в 77 регионе с оператором (М), а далее продаваться и эксплуатироваться в 78 регионе с оператором (Б). Для этого на eSIM-чип потребуется загрузить цифровой абонентский профиль (SAIP) оператора (Б) из 78 региона. С точки зрения технологии eSIM IoT/M2M загрузка профиля другого оператора на eSIM-чип возможна и является обычной штатной процедурой, описанной в спецификациях GSMA. Для выполнения такой загрузки есть несколько условий по стандартам GSMA, которые обязательно должны быть выполнены: первое и основное - другой оператор связи (Б) должен поддерживать технологию eSIM M2M. На сколько нам известно, только МТС заявлял о запуске eSIM IoT/M2M в РФ.
Спасибо за комментарий. Данная статья не связана с микроэлектроникой, в мире множество аббревиатур со схожим написанием и всегда важен контекст их использования.
В нашем случае SOC – это сокращение из мира информационной безопасности, введенный одними из первых корпорацией MITRE — en.wikipedia.org/wiki/Mitre_Corporation» и en.wikipedia.org/wiki/Security_operations_center
«Но если говорить о классическом RAFT — то там сложное управление списком пиров исключительно из-за того, что при пограничных ситуациях неаккуратное добавление нового пира может привести к форку: скажем пройдет выбор лидера с неполной историей»
Как нам кажется, Вы ссылаетесь на раздел «6 Cluster membership changes» вот этого описания протокола raft.github.io/raft.pdf. Мы не зря в самом первом ответе писали про таймауты и квант времени: в данной статье в качестве значения electionTimeout используются миллисекунды, а конфигурация узлов описана примерно так «нужно остановить все узлы, поправить конфигурацию и запустить, и лучше не делать это вручную, так как если запуститься в процессе конфигурации запуститься процедура выбора лидера (интервал которой напомним предполагается от 10-500 мс), то есть вероятность, что случится что-то страшное». Очевидно здесь предполагается, что время, необходимое для конфигурации кластера сопоставимо либо намного больше значения electionTimeout, действительно в этом случае возможен выбор лидера когда кластер находится в каком-то промежуточном состоянии. Мы же значение electionTimeout установили более 10 секунд (на порядки больше чем в статье!), а добавление единичного узла у нас выглядит так – одновременно всем узлам рассылается команда, которая: останавливает таймер election, добавляет новый узел в список узлов, запускает таймер election. Время выполнения этой команды – примерно миллисекунды, ну либо десятки миллисекунд. То есть в нашем случае, время конфигурации кластера на несколько порядков(!) меньше значения electionTimeout, и вероятность инициации выбора лидера в процессе конфигурации стремится к нулю. Само собой мы многократно проверяли данный механизм и на стенде, и на «бою», то есть мониторили состояние кластера в течение всего процесса голосования пользователями на мобильных устройствах, и его корректная работоспособность полностью подтвердилась.
«В рамках RAFT ситуация с форками никак не решается — потому как в RAFT ветвлений не должно происходить в принципе»
Даже если обратиться к «классическому» алгоритму, это не совсем так, в том же документе выше вполне ясно описана процедура разрешения конфликтов в журнале (форков\ветвлений, назвать можно как угодно) «If an existing entry conflicts with a new one (same index but different terms), delete the existing entry and all that follow it (§5.3)» Само собой в рамках тестов нашей реализации мы не раз «соединяли» в один кластер множество узлов у которых журналы отличались начиная с определенного элемента или даже полностью. Вполне ожидаемо, лидер всегда выбирался из большинства узлов с одинаковым журналом, и успешно реплицировал его меньшинству, замещая их версии, соблюдая тем самым наше основное требование – у всех участников единая копия журнала, а возникновение кратковременных «форков» для нас не является критичным (кстати, такая известная «открытая» блокчейн-сеть как «Bitcoin» допускает «форки» и ситуация с ними никак не решается, позволяя тем самым успешно проводить такие атаки, как например «Double-spending», но тем не менее она все-таки «подходит»).
В любом случае спасибо за интересную дискуссию и предоставленную информацию, мы ее обязательно учтем.
«И что мешает злоумышленнику запустить 10 пиров для лидеров? 100 пиров? 1000?”
Вы описываете атаку “51%”, когда злоумышленник получает контроль над большей частью ресурсов распределенной системы, и абсолютной защиты от этой атаки нет в принципе, ей подвержены все открытые сети.
“А учитывая IPv6 это будет физически одна машина, но с несколькими адресами”.
Все не так просто: один пир – это один уникальный IPv6 адрес, принадлежащий диапазону адресов мобильного оператора, иначе мы запрещаем подключение к кластеру, то есть один пир – одна SIM-карта и одно мобильное устройство. Но еще раз, атака 51% — это лишь вопрос наличия достаточных ресурсов, а не особенность математической модели, данной атаке подвержены все открытые сети, абсолютной защиты от нее не существует.
“Проблема в том, что кто угодно в любой момент может провести перевыбор лидера и стать этим лидером”
Даже если следовать классической версии алгоритма, это не совсем так, лидером может стать только участник имеющий версию журнала, наиболее актуальную для большинства участников. Но если алгоритм несколько расширить, например тем образом, о которым мы писали выше или как-то по другому, то выбирать в себя в лидеры просто так по желанию уже не получится.
“В такой схеме даже простой сбой сети может привести к форку, не говоря уже о злонамеренных атаках”
Не совсем понятно о чем идет речь, “split-brain” или что-то еще? Если приведете конкретный кейс, с техническими деталями – будем признательны.
“Если мат.модель позволяет атаку — значит сеть уязвима. Усложнить жизнь злоумышленника — да, можно. Но не защититься от атак полностью”
Полностью согласны, более того, не существует абсолютно идеальной мат. модели, и соответственно абсолютно неуязвимой для атак сети. Успешная атака на любую существующую открытую сеть – вопрос приложенных усилий и средств, поэтому их защита строится на принципе, когда затрачиваемые ресурсы не окупаются полученной выгодой от атаки, что очевидно делает саму атаку бессмысленной.
На самом деле мы сейчас проводим некоторые исследования с целью расширения протокола RAFTдля защиты от “византийских” атак, и мы не одни движемся в этом направлении – поиск по ключевому слову “BFT Raft” выдает несколько достаточно интересных научных статей.
«А подскажите какие-нибудь материалы по теме распределённого реестра на мобильных устройствах?»
Мы подобных материалов найти не смогли, так что будем рады любой информации.
«Это открывает множество возможностей по использованию данной технологии на IoT-устройствах…
Можете привести несколько конкретных примеров?»
В качестве примера могут подходить любые задачи, требующие обмена информацией между распределенными узлами сети. Например, если подключить все автомобили в единую сеть, то можно строить единую карту дорожной обстановки основываясь на камерах/сенсоров участников сети. При этом, поскольку такая карта нужна локально (для участников движения, находящихся по близости) то передавать ее в центр обработки данных и потом скачивать обратно – не эффективно. Удобнее создавать ее с помощью локальных кластеров. А саму карту можно использовать, например, как еще один канал получения информации о дорогах для самодвижущихся автомобилей. Кстати, это вполне реальная задача, которую пытается решать Intel в своем подразделении Mobileye.
1. RAFT работает, пока все пиры соблюдают протокол. Злоумышленник может перехватить генерацию и как минимум фильтровать поступающие данные.
Да, действительно такая проблема есть – если злоумышленник будет выбран лидером, он может фильтровать часть или все запросы на добавление в журнал от других участников. Исключить эту проблему полностью нельзя, но можно радикально минимизировать, ведь нам никто не запрещает всегда строго следовать протоколу RAFT, поэтому мы можем например каждые 10 минут принудительно инициировать выбор нового лидера, а в процессе выбора разрешить голосовать за кандидата, только если он не был выбран лидером в 10 последних голосованиях. Таким образом, если злоумышленник и окажется лидером, то на непродолжительный период времени, и случаться это будет редко.
2.RAFT подразумевает, что перечень пиров фиксирован и известен заранее всем пирам. Управление перечнем пиров происходит через управление конфигурацией сети. Динамическое добавление/удаление пиров может привести к появлению форков.
Как у нас реализовано добавление в кластер – чтобы новому участнику подключиться к кластеру нужно знать адрес хотя-бы одного действующего участника кластера, подключившись к нему, новичок сообщает свой адрес и получает список адресов всех активных участников, далее он повторяет данный шаг для всего только что полученного списка участников (причем на каждом шаге список может дополняться), до тех пор пока в списке не останется ни одного участника, с которым не было обмена адресами (все это происходит параллельно). Таким образом весь кластер достаточно быстро “узнает” адрес нового участника, а новый участник “узнает” адреса всех активных участников кластера. Как мы “выкидываем” из кластера “offline” участников – кроме адреса участника, мы также храним дату\время последней успешной коммуникации с ним, и если коммуникации не было слишком долго, мы с некоторый периодичностью начинаем отправлять ему PING-запросы, и если коммуникации не было совсем очень долго – просто удаляем такого участника из списка. Таким образом, если в качестве кванта времени для RAFT считать интервал между Heartbeat-ми (а у нас это секунды), то условие, что перечень пиров фиксирован и известен заранее всем пирам – вполне себе выполняется.
Можно чуть подробнее про кейс который о котором вы спрашиваете?
Попробуем чуть подробнее описать валидацию сообщений. Каждая запись в журнале имеет открытый ключ участника, который эту запись добавил, контрольную сумму записи, и цифровую подпись, сгенерированную закрытым ключом для [запись + контрольная сумма предыдущей записи этого участника]. То есть у нас получается не цепочка блоков, а цепочки записей каждого из участников. Тогда добавление записи в журнал выглядит примерно так: участник определяет контрольную сумму которую добавил именно он сам, формирует цифровую подпись, отправляет запись и подпись лидеру, лидер валидирует цифровую подпись, добавляет в свой локальный журнал, и рассылает ее фоловерам, каждый фоловер также валидирует цифровую подпись и добавляет к себе в журнал. Если подпись оказывается невалидной – запись просто обрезается до нулевого размера. Таким образом – добавить запись от имени другого участника только узнав его закрытый ключ
«Более того, мне объяснили, что в оплату за проц в машине сразу зааложена оплата лицензии винды на ней. И, если я, условно говоря, нарежу, в рамках своих лимитов, две машины, одну с виндой, другую с centos, то цена за проц будет одинаковой, хотя в линуксовой машине за виндовую лицензию как бы платить незачем.»
У нас в стоимость виртуального процессора не включена оплата лицензии Windows. Она взимается отдельно только для тех виртуальных машин, для которых требуется Windows. Если вам нужно две машины, одна с Windows, а другая с Centos, то машина c Windows будет чуть дороже, чем с Centos. Всегда можно самостоятельно сделать расчеты виртуальной инфраструктуры в калькуляторе на сайте cloud.mts.ru/services/elastic, чтобы убедиться в этом.
«все, что «облачное», продается только после оформления договора (или допника к существущему договору), с прописыванием в договоре оплачиваемых ресурсов. Еще раз: облако от Vmware, но оплата идет, по сути, как за VPS, а не как за облако (per-use оплата? Увы, не увидите — платите за квту ресурсов, которую заказали).»
У нас есть возможность оплаты ресурсов по факту использования — не за квоту. В течение месяца можете свободно использовать ресурсы столько времени, сколько вам надо, можете самостоятельно за минуты создавать новые виртуальные машины – масштабирование на лету, к менеджеру в этом случае обращаться не требуется, платите только за фактическое время использования ресурсов. Оплата за квоту тоже остается, так как ряд клиентов запрашивает именно такой способ тарификации. Поэтому окончательный выбор за вами.
Здравствуйте!
Информация открыта. Ссылка на СКЗИ https://systempb.ru/catalog/produkty/kvazar-100/
сертификат https://systempb.ru/documets/%D0%A1%D0%B5%D1%80%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%82%20%D1%81%D0%BE%D0%BE%D1%82%D0%B2%D0%B5%D1%82%D1%81%D1%82%D0%B2%D0%B8%D1%8F%20%D0%A4%D0%A1%D0%91%20%D0%A0%D0%BE%D1%81%D1%81%D0%B8%D0%B8%20%D0%A1%D0%A4_124-4128%20%D0%BE%D1%82%2002.09.2021.pdf
и вот даташит https://dropmefiles.com/dIgui
По установке. Любой проект с использованием магистрального оборудования прорабатывается индивидуально. Это не массмаркет.
Зарубежные решения не поставляют решения с отечественной криптографией. А на отечественном рынке, это пока единственное решение работающее на таких скоростях.
В смартфонах используется не технология eSIM IoT/M2M, а другая технология – eSIM Consumer. Одновременно на 1 eSIM может быть «активным» (зарегистрированным в мобильной сети) только 1 абонентский профиль. Вы можете переключать профили, по собственному желанию, но связь будет работать только через «активный»....
Оформить Договор на оказание услуг связи и получить чипы можно, расценки на сайте https://moskva.mts.ru/business/internet-veshhey-iot-m2m/uslugi/esim-iot.
Обратитесь пожалуйста к вашему персональному менеджеру в МТС или напишите сюда esim_iot@mts.ru
загрузка профиля любым способом, кроме описанного в стандартах GSMA (при производстве чипа или через оператора) является отклонением от стандарта и не является eSIM IoT/M2M.
Да, список оборудования верный и конечно же список не ограничивается перечисленным оборудованием. Важно обращать внимание ещё на прошивки модулей связи, т.к. прошивки для РФ и Европы могут различаться у производителей.
См. ответ выше. Технически, на работу с разными операторами связи ограничений нет. Тут важно, что бы другие операторы связи у себя запустили eSIM IoT/M2M и выполнили подключение своих платформ SM-DP к SM-SR МТС.
Убедились лично, что поддерживается много модулей SIMCOM и Quectel, так же Telit и Cinterion.
Список модулей есть. Позже опубликуем на нашем сайте единый список. Если кратко, то eSIM поддерживают большое количество модулей 2/3/4G и NB-IoT. Ниже в статье есть ссылки на дистрибьютеров модулей и производителей, с кем проводилось взаимное тестирование, можно у них запросить проверенные модели.
Да, можно приобрести. Для приобретения eSIM IoT/B2B обратитесь к своему персональному менеджеру в МТС или оставьте заявку тут: https://moskva.mts.ru/business/anketa?t=esim_iot&d=152
Здравствуйте! МТС поддерживает заключение договора на оказание услуг связи и «продажу» eSIM-чипов на всей территории РФ. Услуги связи с eSIM-чипа могут работать по всему миру (согласно тарифу).
Про других операторов не скажем - пусть лучше каждый скажет за себя самостоятельно.
Технология безопасна. Криптографическая защита по стандартам GSMA.
У оператора есть ключи доступа у «перепрограммированию» (управлению) eSIM-чипа. Управлять eSIM-чипом IoT/M2M может только оператор связи и никто другой.
Для приобретения eSIM IoT/B2B обратитесь к своему персональному менеджеру в МТС или оставьте заявку тут: https://moskva.mts.ru/business/anketa?t=esim_iot&d=152
Здравствуйте! Стандарт eSIM IoT/M2M не накладывает технологических ограничений и технически оборудование может производиться и тестироваться в 77 регионе с оператором (М), а далее продаваться и эксплуатироваться в 78 регионе с оператором (Б). Для этого на eSIM-чип потребуется загрузить цифровой абонентский профиль (SAIP) оператора (Б) из 78 региона. С точки зрения технологии eSIM IoT/M2M загрузка профиля другого оператора на eSIM-чип возможна и является обычной штатной процедурой, описанной в спецификациях GSMA. Для выполнения такой загрузки есть несколько условий по стандартам GSMA, которые обязательно должны быть выполнены: первое и основное - другой оператор связи (Б) должен поддерживать технологию eSIM M2M. На сколько нам известно, только МТС заявлял о запуске eSIM IoT/M2M в РФ.
В нашем случае SOC – это сокращение из мира информационной безопасности, введенный одними из первых корпорацией MITRE — en.wikipedia.org/wiki/Mitre_Corporation» и en.wikipedia.org/wiki/Security_operations_center
Как нам кажется, Вы ссылаетесь на раздел «6 Cluster membership changes» вот этого описания протокола raft.github.io/raft.pdf. Мы не зря в самом первом ответе писали про таймауты и квант времени: в данной статье в качестве значения electionTimeout используются миллисекунды, а конфигурация узлов описана примерно так «нужно остановить все узлы, поправить конфигурацию и запустить, и лучше не делать это вручную, так как если запуститься в процессе конфигурации запуститься процедура выбора лидера (интервал которой напомним предполагается от 10-500 мс), то есть вероятность, что случится что-то страшное». Очевидно здесь предполагается, что время, необходимое для конфигурации кластера сопоставимо либо намного больше значения electionTimeout, действительно в этом случае возможен выбор лидера когда кластер находится в каком-то промежуточном состоянии. Мы же значение electionTimeout установили более 10 секунд (на порядки больше чем в статье!), а добавление единичного узла у нас выглядит так – одновременно всем узлам рассылается команда, которая: останавливает таймер election, добавляет новый узел в список узлов, запускает таймер election. Время выполнения этой команды – примерно миллисекунды, ну либо десятки миллисекунд. То есть в нашем случае, время конфигурации кластера на несколько порядков(!) меньше значения electionTimeout, и вероятность инициации выбора лидера в процессе конфигурации стремится к нулю. Само собой мы многократно проверяли данный механизм и на стенде, и на «бою», то есть мониторили состояние кластера в течение всего процесса голосования пользователями на мобильных устройствах, и его корректная работоспособность полностью подтвердилась.
«В рамках RAFT ситуация с форками никак не решается — потому как в RAFT ветвлений не должно происходить в принципе»
Даже если обратиться к «классическому» алгоритму, это не совсем так, в том же документе выше вполне ясно описана процедура разрешения конфликтов в журнале (форков\ветвлений, назвать можно как угодно) «If an existing entry conflicts with a new one (same index but different terms), delete the existing entry and all that follow it (§5.3)» Само собой в рамках тестов нашей реализации мы не раз «соединяли» в один кластер множество узлов у которых журналы отличались начиная с определенного элемента или даже полностью. Вполне ожидаемо, лидер всегда выбирался из большинства узлов с одинаковым журналом, и успешно реплицировал его меньшинству, замещая их версии, соблюдая тем самым наше основное требование – у всех участников единая копия журнала, а возникновение кратковременных «форков» для нас не является критичным (кстати, такая известная «открытая» блокчейн-сеть как «Bitcoin» допускает «форки» и ситуация с ними никак не решается, позволяя тем самым успешно проводить такие атаки, как например «Double-spending», но тем не менее она все-таки «подходит»).
В любом случае спасибо за интересную дискуссию и предоставленную информацию, мы ее обязательно учтем.
Вы описываете атаку “51%”, когда злоумышленник получает контроль над большей частью ресурсов распределенной системы, и абсолютной защиты от этой атаки нет в принципе, ей подвержены все открытые сети.
“А учитывая IPv6 это будет физически одна машина, но с несколькими адресами”.
Все не так просто: один пир – это один уникальный IPv6 адрес, принадлежащий диапазону адресов мобильного оператора, иначе мы запрещаем подключение к кластеру, то есть один пир – одна SIM-карта и одно мобильное устройство. Но еще раз, атака 51% — это лишь вопрос наличия достаточных ресурсов, а не особенность математической модели, данной атаке подвержены все открытые сети, абсолютной защиты от нее не существует.
“Проблема в том, что кто угодно в любой момент может провести перевыбор лидера и стать этим лидером”
Даже если следовать классической версии алгоритма, это не совсем так, лидером может стать только участник имеющий версию журнала, наиболее актуальную для большинства участников. Но если алгоритм несколько расширить, например тем образом, о которым мы писали выше или как-то по другому, то выбирать в себя в лидеры просто так по желанию уже не получится.
“В такой схеме даже простой сбой сети может привести к форку, не говоря уже о злонамеренных атаках”
Не совсем понятно о чем идет речь, “split-brain” или что-то еще? Если приведете конкретный кейс, с техническими деталями – будем признательны.
“Если мат.модель позволяет атаку — значит сеть уязвима. Усложнить жизнь злоумышленника — да, можно. Но не защититься от атак полностью”
Полностью согласны, более того, не существует абсолютно идеальной мат. модели, и соответственно абсолютно неуязвимой для атак сети. Успешная атака на любую существующую открытую сеть – вопрос приложенных усилий и средств, поэтому их защита строится на принципе, когда затрачиваемые ресурсы не окупаются полученной выгодой от атаки, что очевидно делает саму атаку бессмысленной.
На самом деле мы сейчас проводим некоторые исследования с целью расширения протокола RAFTдля защиты от “византийских” атак, и мы не одни движемся в этом направлении – поиск по ключевому слову “BFT Raft” выдает несколько достаточно интересных научных статей.
Мы подобных материалов найти не смогли, так что будем рады любой информации.
«Это открывает множество возможностей по использованию данной технологии на IoT-устройствах…
Можете привести несколько конкретных примеров?»
В качестве примера могут подходить любые задачи, требующие обмена информацией между распределенными узлами сети. Например, если подключить все автомобили в единую сеть, то можно строить единую карту дорожной обстановки основываясь на камерах/сенсоров участников сети. При этом, поскольку такая карта нужна локально (для участников движения, находящихся по близости) то передавать ее в центр обработки данных и потом скачивать обратно – не эффективно. Удобнее создавать ее с помощью локальных кластеров. А саму карту можно использовать, например, как еще один канал получения информации о дорогах для самодвижущихся автомобилей. Кстати, это вполне реальная задача, которую пытается решать Intel в своем подразделении Mobileye.
Да, действительно такая проблема есть – если злоумышленник будет выбран лидером, он может фильтровать часть или все запросы на добавление в журнал от других участников. Исключить эту проблему полностью нельзя, но можно радикально минимизировать, ведь нам никто не запрещает всегда строго следовать протоколу RAFT, поэтому мы можем например каждые 10 минут принудительно инициировать выбор нового лидера, а в процессе выбора разрешить голосовать за кандидата, только если он не был выбран лидером в 10 последних голосованиях. Таким образом, если злоумышленник и окажется лидером, то на непродолжительный период времени, и случаться это будет редко.
2.RAFT подразумевает, что перечень пиров фиксирован и известен заранее всем пирам. Управление перечнем пиров происходит через управление конфигурацией сети. Динамическое добавление/удаление пиров может привести к появлению форков.
Как у нас реализовано добавление в кластер – чтобы новому участнику подключиться к кластеру нужно знать адрес хотя-бы одного действующего участника кластера, подключившись к нему, новичок сообщает свой адрес и получает список адресов всех активных участников, далее он повторяет данный шаг для всего только что полученного списка участников (причем на каждом шаге список может дополняться), до тех пор пока в списке не останется ни одного участника, с которым не было обмена адресами (все это происходит параллельно). Таким образом весь кластер достаточно быстро “узнает” адрес нового участника, а новый участник “узнает” адреса всех активных участников кластера. Как мы “выкидываем” из кластера “offline” участников – кроме адреса участника, мы также храним дату\время последней успешной коммуникации с ним, и если коммуникации не было слишком долго, мы с некоторый периодичностью начинаем отправлять ему PING-запросы, и если коммуникации не было совсем очень долго – просто удаляем такого участника из списка. Таким образом, если в качестве кванта времени для RAFT считать интервал между Heartbeat-ми (а у нас это секунды), то условие, что перечень пиров фиксирован и известен заранее всем пирам – вполне себе выполняется.
Попробуем чуть подробнее описать валидацию сообщений. Каждая запись в журнале имеет открытый ключ участника, который эту запись добавил, контрольную сумму записи, и цифровую подпись, сгенерированную закрытым ключом для [запись + контрольная сумма предыдущей записи этого участника]. То есть у нас получается не цепочка блоков, а цепочки записей каждого из участников. Тогда добавление записи в журнал выглядит примерно так: участник определяет контрольную сумму которую добавил именно он сам, формирует цифровую подпись, отправляет запись и подпись лидеру, лидер валидирует цифровую подпись, добавляет в свой локальный журнал, и рассылает ее фоловерам, каждый фоловер также валидирует цифровую подпись и добавляет к себе в журнал. Если подпись оказывается невалидной – запись просто обрезается до нулевого размера. Таким образом – добавить запись от имени другого участника только узнав его закрытый ключ
У нас в стоимость виртуального процессора не включена оплата лицензии Windows. Она взимается отдельно только для тех виртуальных машин, для которых требуется Windows. Если вам нужно две машины, одна с Windows, а другая с Centos, то машина c Windows будет чуть дороже, чем с Centos. Всегда можно самостоятельно сделать расчеты виртуальной инфраструктуры в калькуляторе на сайте cloud.mts.ru/services/elastic, чтобы убедиться в этом.
У нас есть возможность оплаты ресурсов по факту использования — не за квоту. В течение месяца можете свободно использовать ресурсы столько времени, сколько вам надо, можете самостоятельно за минуты создавать новые виртуальные машины – масштабирование на лету, к менеджеру в этом случае обращаться не требуется, платите только за фактическое время использования ресурсов. Оплата за квоту тоже остается, так как ряд клиентов запрашивает именно такой способ тарификации. Поэтому окончательный выбор за вами.