Главная

Наши проекты

При первом запуске сайта отображается всплывающее окно приветствия, в котором можно выбрать свой город. Также регион можно сменить, щелкнув по установленному на данный момент городу в верхнем левом углу страницы сайта. Город можно выбрать из предложенного списка или используя поле «Введите свой город».

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

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

Эта прогнозируемая проблемы, поэтому поставщики решений разработали специальные программные решения по управлению IT ресурсами. Их функции включают анализ использования имеющихся мощностей и инструменты прогнозирования возможных проблем

Эта прогнозируемая проблемы, поэтому поставщики решений разработали специальные программные решения по управлению IT ресурсами, их функции включают анализ использования имеющихся мощностей и инструменты прогнозирования возможных проблем.

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

Вы можете арендовать платформенные лицензии двух типов: пользовательские и серверные. Доступны редакции КОРП и ПРОФ.

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

Вместе с арендой пользовательской лицензии вы также получаете доступ к одной из конфигураций 1С — это прикладные решения для разных задач: бухгалтерского учета, финансового менеджмента, управления производством. Вы можете без ограничений и лишних ежемесячных доплат использовать до пяти любых конфигураций.

Примеры конфигураций 1С:

1С:Управление нашей фирмой;
1С:Зарплата и Управление персоналом;
1С:Бухгалтерия;
1С:Управление торговлей;
1С:Комплексная автоматизация;
1С:Розница;
1С:ERP Управление предприятием.

SIEM-система – это система управления событиями ИБ. Она предназначена для анализа информации, поступающей из других источников - DLP, IDS, антивирусов, железа (Fortinet, маршрутизаторов и т.д.) и дальнейшего выявления отклонения от норм по определенным критериям. Для полного обеспечения ИБ компании одной SIEM-системы не достаточно.

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

SIEM нужна для сбора и анализа информации из большого количества источников, что вручную сделать не всегда возможно. Кроме того, на основании накопленных статистических данных, SIEM-система может устанавливать взаимосвязь между несколькими безобидными по отдельности событиями, если вместе они угрожают ИБ компании. Также она может предоставить доказательную базу для внутреннего или судебного расследования, при возникновении подобных инцидентов.

Есть несколько категорий потребителей, однозначно нуждающихся в установке этой системы: 1. Предприятия с большой (более 1000 машин) или географически разветвленной инфраструктурой. 2. Банки и другие финансовые организации. 3. Организации, уже пострадавшие в результате произошедшего нарушения ИБ.

1. Большая (более 1000 машин) или географически разветвленная инфраструктура.
2. Уже действующие системы ИБ - от антивирусов до DLP, IDS, IDM и т.д Чем больше таких систем, тем лучше.
3. Деньги.
4. Время. На установку и настройку системы потребуется от полугода (в зависимости от размера организации), период окупаемости еще продолжительнее, а первые заметные результаты вы получите через 5-6 месяцев работы системы в штатном режиме.

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

Нет. SIEM-система предназначена для сбора и анализа информации и накопления статистики. Она может предупредить о возможной угрозе, зафиксировать произошедший инцидент и предоставить доказательства для внутреннего или судебного разбирательства.

SIEM-системы всех ведущих вендоров работают с источниками, которые отправляют события как SYSLOG. Если же новый источник – какая-то специфическая программа, то, как правило, для нее можно написать обработчик событий или коннектор (но это потребует дополнительных трудозатрат либо дополнительных денежных затрат).

Конкретный список зависит от выбранного DLP-решения, но обычно это как минимум электронная почта, веб-трафик, интернет-пейджеры и/или USB-устройства и принтеры. Стоит обращать внимание на конкретный перечень каналов, например, многие разработчики под интернет-пейджерами могут подразумевать не ICQ, Mail.Ru Агент и Skype, а практически не распространенные в России и СНГ сервисы AIM, Yahoo! Messenger и Google Talk.

Журнал событий можно посмотреть в любом режиме работы. Проблемы могут возникнуть, когда потребуется проанализировать активность сотрудников (в том числе отправленные за пределы сети файлы и письма), ведь не все DLP-решения имеют возможность архивировать (создавать теневую копию) перехваченной информации.

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

Пожалуй, стоит назвать режим полуавтоматическим, ведь часто сотрудникам требуется переслать конфиденциальную информацию за пределы организации, что может требовать участия офицера безопасности для санкционирования такого действия. Но в целом при грамотной первоначальной настройке можно минимизировать трудозатраты на обслуживание DLP.

«Пассивный» и «активный». В «пассивном» режиме DLP не блокирует передачу информации, даже если обнаруживает нарушения политик безопасности. В таком варианте трафик на DLP переправляется с помощью маршрутизатора или специальных агентов-перехватчиков, устанавливаемых на почтовых и прокси-серверах. В «активном» режиме DLP ставится в разрыв и может блокировать утечки, принимая решения в реальном времени. Стоит отметить, многие DLP-системы технически не могут работать в «активном» режиме, что существенно сужает их применимость для реальных задач.

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

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

Мы предлагаем в аренду не администрируемые сервера. В техническую поддержку входят следующие обязанности: • решение проблем доступности сети; • решение аппаратных проблем с оборудованием в дата-центре, в том числе и предлагаемых серверов; • максимально развернутые ответы и советы клиентам по способам устранения возникающих проблем; • сбор и анализ проблем и незамедлительное принятие решений по их устранению.

Подключение к серверу происходит по выделенному «белому» IP-адресу. В зависимости от операционной системы, подключение к серверу происходит различными способами, например, для систем Linux подключение осуществляется через безопасную оболочку SSH. Для операционных систем Windows подключение осуществляется через Удалённый рабочий стол (RDP).

К вопросу об экономии и эффективности использования ресурсов. Размещение оборудования в ЦОД существенно экономит энергопотребление, нет привязки к железу Вам не придется приобретать контроллеры домена, выделенные почтовые и прочие сервера что позволит сэкономить серьезные деньги.

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

Основные три :
1. Публичные. У всех или большинства пользователей есть доступ к общей части функционала, но данные конкретной фирмы будут доступны только ее сотрудникам.
2. Приват. Софт полностью изолирован, способен меняться под текущие задачи.
3. Гибрид. Сочетает в себе два предыдущих варианта.

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

3 основных части ERP системы: Платформа. Это база с минимальными возможностями, среда, в которой будут работать надстроенные элементы. Менять что-либо в ней может только создатель и его команда. Контроль над деньгами. Здесь хранится база данных, учитываются методы хранения и обработки массивов, лежат инструменты для интерпретации, ПО для работы с этим. Модули. Это компоненты, которые будут подключаться по желанию пользователей. Каждый из них имеет свой функционал и существует независимо от остальных.

Создать собственный продукт. Если писать все полностью самостоятельно, есть риск получить неработоспособный материал с множеством ошибок, которые во время функционирования создадут большие проблемы. Купить готовую платформу. Если сделать правильный выбор и заказать до настройку, то получится типовое ПО, но отлично работающее с вашими задачами. Здесь придется просить о постоянной или регулярной поддержке разработчика. Заказать разработку профессионалами. Это дороже, но есть вероятность получить результат, который будет полностью подстроен под желания и потребности бизнеса. Стоит учесть, что только 20% от всех созданных отечественных разработок нашли применение в компаниях. Есть риск получить не самый качественный продукт по очень высокой цене.

Аббревиатура ERP — это enterprise resource planning дословно переводится, как планирование ресурсов. В теории подобная программа становится своеобразной стратегией предприятия, внутри которой будет учитываться управление определенными направлениями: финансами – ведется налоговый и бухгалтерский учет, планируется бюджет; трудовыми кадрами; активами; взаимодействиями с партнерами, ведением подробной истории операций с клиентами.

Основной источник возникновения ошибок - это этап первоначальных настроек базы данных, в частности, работа с настройками Учетной политики. Это может быть просто техническая ошибка выбора способа учета, или несоответствие выбранного способа специфике вашей организации.

Несколько признаков, которые сигнализируют о том, что пора: сотрудникам приходится тратить много времени на рутинные и простые задачи, которые легко автоматизировать; сложно получить оперативную информацию, чтобы принять срочные решения; слишком много разрозненных продуктов и программ, которые не получается объединить в одну, модули и таблицы не переносятся из одного ПО в другое; нет объективных и своевременных данных об остатках на складах, движении финансов, товаров; нельзя изучать и анализировать отчеты вне офиса, только с конкретного компьютера на рабочем месте; бухгалтерские документы готовятся очень долго; все продажи и вообще общение с клиентами невозможно усложнено; отделам тяжело взаимодействовать между собой; если IT-отдел есть, то функционирует с большим трудом; нет подходящего уровня контроля за действиями персонала.

Из-за дублирования позиций справочник номенклатуры разрастается до огромных размеров? Это приводит к сложности при поиске номенклатурной позиции – при перемещении со склада, списании, реализации. Да и при большом количестве номенклатур отследить дубли не так-то просто, сотрудник может не знать - это одна и та же номенклатура или нет. Отсюда могут быть и неправильные остатки материалов в программе.

Облачный сервис выбирайте среди российских партнеров, с 2017 года законодательство строго смотрит на хранение данных российских граждан на иностранных «облаках». За нарушение и несоблюдение обработки и хранения персональных данных граждан РФ грозят большие штрафы.

В крупном бизнесе, при длительном использовании серверов, к примеру от 2 лет, содержать свои серверы и обслуживающий персонал дешевле Если брать микробизнес с командой до 15 человек на старте бизнеса, здесь выгоднее облачные хранилища, не нужно создавать серверное помещение, тянуть провода. Это похоже на ситуацию с жильем или арендой офиса.

Главное возражение против облачных технологий в целом — «я это не контролирую». На самом деле современные облачные сервисы надежнее собственных хранилищ, ведь даже простая фотография в облаке фактически обретает вечность — она никуда не пропадет, пока вы ее не удалите. Что говорить о серьезных системах, предназначенных для хранения и обработки коммерческой информации.

«Я в облаке!» - могли бы сказать сотрудники Вашей компании, когда к ним пришли с обыском. Облачный сервер невозможно «унести» или разбить. Поэтому даже в экстремальных ситуациях проверки, ограбления, обыска, пожара и так далее работоспособность не будет нарушена. Пара капель корвалола и можно трудиться.

В облачных хранилищах процедура бэкапа платная, потому Вы сами выбираете, как часто делать автоматические резервные копии данных. Вы сами определяете график, и все данные в облаке будут копироваться автоматически в заданные промежутки времени.

Для облачного сервера не актуальна проблема поломки комплектующих. В центрах хранения и обработки данных (ЦОД), где разворачивается виртуальная инфраструктура, запланировано многоуровневое резервирование вычислительных ресурсов. Сбои могут быть, но они не несут фатальных проблем, характерных для физических серверов. Неполадки устраняются на порядок быстрее, чем при эксплуатации локального сервера благодаря резервированию и специализированному персоналу.

Есть два способа работы с 1С.

Первый способ — аренда лицензий 1С в составе разных продуктов: облачной платформы, выделенных серверов, облака на базе VMware или размещения оборудования.

Что входит в услугу:

платформенные лицензии 1С на рабочие места и подключение к серверу приложений;
право использования типовых конфигураций 1С;
доступ к установочным файлам 1С, обновлениям, активация файлов нашими специалистами.

Здесь мы не устанавливаем программы и не проводим настройки. По сути это IaaS — инфраструктура как сервис.

Второй способ — работа с готовой 1С-платформой. Вы получаете доступ к полностью настроенному приложению 1С на облачной инфраструктуре, а также его обслуживанию. Это PaaS — платформа как сервис. В рамках этого варианты вы можете использовать собственные лицензии 1С или арендовать.

Основные преимущества СХД «Яхонт-УВМ Э124»:
— установка до 124 жестких дисков
— до 1 736 Тб дискового пространства на сервер
— потоковая скорость записи информации до 10 Гбайт/с
— интерфейсы Ethernet, RDMA/RoCE, Infiniband
— собственные технологии снижения вибрации и охлаждения
— полное соответствие требованиям законодательства РФ)

Краткий справочник по классам СОРМ:

СОРМ 1 (№268-ФЗ) Голосовая связь, IP-телефония.

СОРМ 2 (№83-ФЗ в редакции 139) ШПД, GPRS.

СОРМ 3 (№538-ФЗ, №573-ФЗ) IRPD, логирование сессии в тексте, хранение до 36 месяцев информации об абонентах, сессиях соединений, CDR.

№374-ФЗ (Закон Яровой), №86-ФЗ, №445-ФЗ Расширенные требования к СОРМ-3: добавляется хранение голосового контента и контента передачи данных.

«Енисей» имеет существенные доработки в плане функционала по сравнению с CouchDB. К ним относятся новая модель безопасности, функции аудита, способы хранения на диске бинарных данных, новые встроенные функции построения выборок и манипуляций с данными, поддержка языка Elixir в проектных документах, поддержка LDAP, режим «грязной» записи, поддержка дополнительного протокола доступа и др.

«Енисей» поддерживает два2 типа программных интерфейсов:

HTTP REST API с доступом к полностью всему функционалу СУБД. Интерфейс содержит несколько десятков методов, относящихся как к работе с данными, так и к администрированию сервера.
Erlang Distribution Protocol. Данный интерфейс позволяет выполнять производительную низкоуровневую интеграцию с прикладными системами, реализованными на языках Erlang/Elixir и на Java.

Запросы документов по Id и получение результатов представлений не требуют предварительного ручного создания индексов. Использование функции _find (Mango-запросы), как правило, заставляет добавлять индексы для ее оптимизации. Есть возможность создавать индексы по произвольным полям и группам полей. Кроме того, «Енисей» позволяет получать время выполнения запросов и пояснения к обработке запросов для их отладки и целенаправленной оптимизации.

Поддержка мультимастер-репликаций является одним из наиболее интересных свойств «Енисея», отличающих его от других СУБД. Режим «Мультимастер» обеспечивается как при работе с одним сервером «Енисея», так и в кластере, а также при объединении нескольких кластеров. НТо есть, независимо от того, с каким из связанных кластеров работает клиент и с каким конкретно сервером внутри кластера, он может выполнять любые операции по выборке и изменению данных, а обеспечение консистентности данных при этом берет на себя СУБД.

«Мультимастер» реализован на базе технологии MVCC. При любом изменении какого-либо документа указывается предыдущая ревизия документа, которая известная клиенту и, на базе которой он выполняет данное изменение. При обработке запросов и репликаций данных «Енисей» выстраивает цепочки изменений и может решить, какая из ревизий документа является актуальной.

SQL не поддерживается. «Енисей» — это NoSQL- система, в которой все функции манипуляции с данными описываются на одном из поддерживаемых языков программирования. То есть используются не специализированные языки работы с данными, а именно языки программирования широкого назначения.

Все функции работы с данными собираются в так называемых проектных документах. Это тоже документы, лежащие в БД, но в них содержится не информационный контент, а код функций. Для проектных документов так же действуют механизмы репликации, как и для обычных документов.

Предусмотрены функции нескольких типов: — валидаторы изменений, MapReduce- агрегации данных, обработчики произвольных пользовательских запросов, преобразователи выходных документов. Суммарно, все эти функции обеспечивают практически весь спектр потребностей по работе с данными, который может быть реализован на SQL.

В «Енисее», как и в CouchDB, нет такого понятия, как внешние ключи, и не имеется функционала для какой-либо специфической поддержки этих внешних ключей. Однако это, конечно, не мешает использованию в качестве значения атрибутов документов любых идентификаторов (строковых, числовых, или составных) из других баз, или даже из внешних СУБД. ЛА любой атрибут документа может быть использован в качестве ключа или значения представлений, плюс по любому атрибуту или их группе может быть построен индекс в «Енисее» для оптимизации доступа. Если требуется более сильная зависимость от внешних сущностей, то это должно реализовываться на прикладном уровне.

Это напрямую зависит от проекта, сайзинг вне контекста вряд ли возможен. Утилизация ресурсов со стороны СУБД — это прежде всего результат выполнения запросов при операциях над данными. Не имея представления о требованиях со стороны решения, нельзя дать адекватный ответ на такой вопрос. На ряде инсталляций достаточно и сервера с двумя2 ядрами и 2 ГБ памяти. Оптимальным вариантом для достижения «Енисеем» высоких скоростей записи и выборок данных в высоконагруженных решениях мы считаем сервер с 32 ядрами и 32 ГБ RAM.

Принципы масштабирования полностью соответствуют тому, как работает CouchDB. Кластер может состоять из произвольного количества узлов, поддерживается шардирование, репликации и партиционирование БД. Состав кластера может произвольно меняться в процессе работы. Каждая Б Д в кластере может иметь свои персональные настройки по числу шардов и реплик.

«Енисей» не имеет коллекций, схемы данных и схемы связей между коллекциями, как это реализовано в MongoDB, т. То есть нет и намека на реляционную структуру данных, как в MongoDB. БД в «Енисее» — это просто линейный список документов. Документ в «Енисее» — это самодостаточная сущность, не требующая внешних связей. Поэтому можно сказать, что в «Енисее» нет языковой модели как таковой. Построение выборок в" Енисее" подразумевает использование принципиально другого подхода, чем в MongoDB, — представлений, которые реализуют технику Map-Reduce.

В «Енисее» имеется поддержка типа запроса — Mango Query (видимо, под собственной языковой моделью подразумевается именно эта возможность). Его синтаксис напоминает MongoDB, но прямой совместимости нет

Дисковые операции с данными в «Енисее» реализованы по принципу «Append-only», поэтому нет деградации скорости добавления данных или получения результатов выборок с увеличением размера БД. «Енисей» эксплуатировался на базах с десятками миллиардов документов, объем данных при этом достигал десятков терабайт. Такой режим, по сути, ничем не отличался от работы с базами малого объема и не требовал увеличения процессорных ресурсов, или памяти. Только диски должны быть большими. Нет технических ограничений по размерам документов, числу документов в БД, байтовому размеру БД, числу БД на одном сервере или кластере.

Прежде всего, в том, что это разные решения для разных задач. «„Енисей“ —» — это документо-ориентированная СУБД, в которой реализованы специфические механики для обработки и хранения документов. S3 — key-value объектное хранилище, в котором, при желании можно хранить и документы. В «Енисей» можно хранить и бинарные данные, как объекты с метадатой, что удобно в дополнение к основному функционалу. Построить на базе S3 распределенную инфраструктуру хранения и обработки документов в теории можно, но не будет эффективно.

«Енисей» не поддерживает транзакции. Гарантируется только то, что успешно отправленный документ будет сохранен в БД полностью. При сохранении и после него могут возникнуть конфликты, которые тоже являются неотъемлемым свойством MVCC, позволяющим исключить блокировки документов или операций с БД.

«Енисей» поддерживает 4 языка «„из коробки“». Это JavaScript, CoffeScript, Erlang, Elixir. Использование этих языков описано в документации. Кроме того, в интернете можно найти готовые драйверы (для CouchDB) для поддержки и некоторых других языков, их тоже возможно подключить к «Енисею».

Да, с помощью API-эндпоинта _find возможно построение произвольных запросов данных, для оптимизации которых используются индексы. «Енисей» позволяет создавать индексы по любым полям и группам полей. Кроме того, выполняется автоматическая индексация ключей, получаемых на выходе этапа Map- представлений и индексация всех документов по Id, т.к. выборка документа по Id —- наиболее частая операция с БД в реальных проектах.

Блокировки являются инструментом для реализации транзакций. Транзакции в «Енисее» не поддерживаются, и блокировок в традиционном их понимании тоже нет.

Однако, в качестве одной из дополнительных функций «Енисея», по сравнению с CouchDB, является реализация «системы параллельного обслуживания заявок», которая позволяет подключить к БД несколько клиентов, выполняющих роль обработчиков заявок (документов в терминологии СУБД). Данный функционал реализован как раз с помощью так называемых блокировок, которые обеспечивают то, что документы будут равномерно распределены между обработчиками.

При построении представлений используется любой из поддерживаемых «Енисеем» языков программирования. Это означает, что выражения и конструкции могут быть произвольной сложности и размера.

В API-эндпоинте _find, в котором используется декларативный синтаксис выборки данных, могут применяться десятки поддерживаемых операторов, т. е. получаемые конструкции по факту тоже могут быть достаточно сложными, н. Но относятся они к одному документу. Невозможно задать параметры выборки так, чтобы принимались в расчет несколько документов, или отношения между документами.

Между отдельными серверами или кластерами «Енисея» настраиваются задания на репликацию данных. Все задания являются односторонними. Поэтому для двунаправленной репликации следует создать два отдельных задания.
Репликации бывают:

однократными и непрерывными;
безусловными и селективными.

При этом селективные репликации можно организовать с помощью указания параметров фильтрации документов, на основе функций-фильтров, а также с помощью Map-функций представлений.
Гибкость в организации репликаций позволяет строить распределенные базы без полного дублирования данных, а с гибким роутингом потоков изменений..

При выполнении записи документа в кластере в параметрах запроса указывается replica-factor, который определяет, на скольких серверах должны быть сохранены данные перед отправкой ответа клиенту. Аналогично replica-factor присутствует и в запросах на чтение. С помощью данных параметров достигается гарантированная видимая консистентность данных в кластере с точки зрения клиента, причем происходит это в режиме «Мультимастера».
Отдельно в «Енисее» существует механизм репликации данных между кластерами. Это не то же самое, что репликация внутри кластера. Эта операция выполняется без привязки к клиентским запросам, в фоновом режиме. Поэтому, если система состоит из двух отдельных кластеров с репликацией между ними, то добиться синхронной репликации данных из клиентского запроса в оба кластера действительно не получится. Если требуется, чтобы данные синхронно реплицировались в несколько дата-центров (то есть необходимо обеспечить устойчивость к отказам дата-центра полностью), то система должна строиться, например, так: в кластер включаются сервера сразу из нескольких дата-центров. Тогда с помощью параметра replica-factor можно обеспечить сохранение данных во всех дата-центрах перед ответом клиенту. И, соответственно, если такая запись не удалась, из-за недоступности одного из дата-центров, то клиент получит на свой запрос ошибку.

В «Енисее» split-brain невозможен, так как при работе с данными не используются алгоритмы консенсуса. Все сервера в кластере «Енисея» полностью равноправны в плане функциональности и управления данными. Запрос на получение или обновление данных обрабатывается одним из серверов кластера, который выступает «„организатором“» именно для этого запроса.
Вместо работы с консенсусом, в «Енисее» действует подход MVCC, — то есть обновление данных на любом узле с последующей синхронизацией изменений на основе номеров ревизий.
Для разрешения конфликтов в «Енисее» предусмотрено два2 подхода:

автоматическое разрешение, когда алгоритмически одна из конфликтующих ревизий считается «„победителем“» одинаково на всех серверах;
выдача конфликтующих ревизий в прикладную систему для принятия решения вне «Енисея».

Наличие конфликтов никак не мешает последующему обновлению данных и не приводит к каким-либо блокировкам.

В нашем каталоге представлены последние линейки спецтехники, систем Закажите консультацию по любому товару у наших специалистов или соберите свой заказ прямо на сайте. Мы подготовим для вас индивидуальное коммерческое предложение и вышлем персональный блок бонусов и скидок.