Мой клиент производит медицинское устройство, которое проводит различные измерения заданного образца и записывает результаты в базу данных. Объем генерируемых данных относительно невелик.
В текущей конфигурации каждое устройство имеет свой собственный компьютер, и этот компьютер запускает экземпляр сервера базы данных. Устройства не объединены в сеть.
Клиент хочет модифицировать устройство таким образом, чтобы около пятидесяти из них можно было подключить к локальной сети.
Устройства используют различные расходные материалы, которые имеют номер партии и после использования не могут быть использованы повторно. Эти номера партий записываются в базу данных при измерении образца. Это требование примечательно, поскольку в текущей конфигурации устройство не имеет возможности узнать, использовался ли расходный материал другим устройством. В предлагаемой сетевой конфигурации ожидается, что каждое устройство будет иметь немедленный доступ к информации о расходных материалах, используемых другими устройствами.
Устройства также должны отслеживать количество различных химикатов, используемых в процессе тестирования. Каждая бутылка химиката имеет номер партии и штрих-код. Когда бутылка вставляется в машину, машина считывает базу данных, чтобы определить, сколько жидкости было потреблено из бутылки. Существует ожидание, что бутылка с номером партии может быть вставлена в любую машину, и машина сможет точно оценить количество жидкости в бутылке.
Клиент хочет получить рекомендацию о том, какую из двух архитектур следует использовать:
1.) Каждое устройство будет записывать данные в свою собственную локальную базу данных, как оно это делает сейчас. Программное обеспечение для синхронизации будет установлено на каждом устройстве, и синхронизация будет выполняться в режиме реального времени. Каждое устройство будет периодически транслировать тактовый сигнал (предлагались интервалы от 1 до 5 минут), и этот тактовый сигнал будет содержать контрольную сумму CRC. Каждое устройство в сети будет прослушивать тактовые сигналы. Устройство инициирует синхронизацию, если CRC тактового сигнала отличается от его собственного. Программное обеспечение для синхронизации будет внешним и независимым от программного обеспечения, которое запускает тесты. Поэтому теоретически возможно, но маловероятно, что устройство будет работать, пока оно отключено от сети или пока программное обеспечение синхронизации не запущено.
2.) Сервер базы данных на каждом устройстве будет удален, и вместо него будет использоваться сервер базы данных.
Клиент обеспокоен тем, что если используется сервер базы данных, все устройства в сети станут непригодными для использования в случае отказа сервера. Эффективно ли использование топологии одноранговых узлов снижает этот риск? Другими словами, если один одноранговый узел в сети выходит из строя, для всех остальных одноранговых узлов все остается как обычно? Существуют ли какие-либо опасности или преимущества для целостности данных, связанные с любым из подходов?
Редактировать в ответ на ответы от iag и MikeyB:
Я понимаю, что мой вопрос оставляет место для двусмысленности, поэтому повторю его еще раз, надеюсь, сформулированный более осмысленно.
В клиент-серверной среде отказ сервера является катастрофическим, поскольку если сервер выходит из строя, все клиенты отключаются. Учитывая эту особенность конструкции, почему некоторые критически важные информационные, инвентарные, финансовые и медицинские системы реализуют архитектуру клиент-сервер, а не одноранговую?
Обратите внимание, я НЕ спрашиваю: «Как мне снизить риск отказа сервера?» Я спрашиваю: «Является ли одноранговая архитектура эффективным способом снижения риска отказа сервера?» Почему или почему нет? Влияет ли топология сети на дизайн приложения? Вносит ли одноранговая архитектура возможность повреждения данных или неоднозначных результатов?
Является ли следующий пример реалистичным примером того, что может произойти в топологии одноранговой сети?
DeviceA, DeviceB и DeviceC — это компьютеры в одноранговой сети, которые совместно используют общего агента, называемого агентом R. Всякий раз, когда одноранговому устройству необходимо проверить, сколько R доступно, оно синхронизируется с другими одноранговыми устройствами и вычисляет доступность. Однажды около 13:00 лаборант вставляет бутылку R в DeviceB. DeviceB немедленно синхронизируется с DeviceC и подтверждает, что DeviceC никогда не потреблял R из этой бутылки. Однако DeviceA не отвечает на пинги с полудня. Может ли DeviceB надежно вычислить количество R, доступное в бутылке?
Я инженер-программист и буду писать приложение, которое позволит этим устройствам обмениваться данными по сети. Честно говоря, у меня есть мнение по вопросу, который я задаю, однако мой клиент не доверяет моему опыту. Я хочу узнать опыт моих коллег, поэтому и пишу здесь. Я не хочу вкладывать слова в чьи-либо уста, поэтому я стараюсь не быть максимально общим и все же объяснить проблему.
решение1
Архитектура однорангового программного обеспечения может быть эффективным и отказоустойчивым способом распространения информации между узлами, если в базовой сети уже имеется избыточность.
Архитектура peer-to-peer также может защитить вас от потери данных, если несколько узлов хранят данные. В типичных системах peer-to-peer узлы хранят данные из-за своих собственных интересов. То, что вам нужно, отличается, поскольку вы хотите, чтобы они хранили данные из-за соблюдения политики, а не индивидуальных интересов.
Каждый узел, хранящий все, что он когда-либо видел, прост, пока объем данных ограничен. Но хранение всего может быть непрактичным из-за дискового пространства (или в некоторых сценариях из-за юридических требований). Тогда нужно быть осторожным с тем, что удалять, а что сохранять. Это одна из главных ловушек.
Но все это не решает проблему целостности и согласованности данных. Если вы просто перейдете на архитектуру peer-to-peer, не задумываясь о корректности данных, то надежность системы в этом отношении снизится. Просто появится гораздо больше мест для внедрения коррупции.
Чтобы реализовать такое решение, вам необходимо выяснить, как проверить целостность фрагмента данных.
С фрагментом данных, который может быть обновлен только одним конкретным узлом в системе, проще всего иметь дело. Но вам все равно придется задать вопрос о том, какое поведение системы является приемлемым, если этот узел начнет вести себя неправильно. Криптографической подписи каждого обновления недостаточно, если он может ошибочно отправить подписанное обновление, чтобы удалить все, что он ранее записал, или отправить несколько подписанных обновлений, которые не согласны с новым значением данных. Простой подход снова заключается в том, чтобы хранить все и требовать ручного вмешательства, если появятся конфликтующие обновления. Но если вам когда-либо понадобится какое-либо автоматизированное решение, принимаемое на основе данных, то этого недостаточно.
Если только один узел может обновить данные, но у вас есть строгое требование, чтобы все остальные согласились с тем, какое обновление он выполнил, то проблема становится немного сложнее.
Решение этой проблемы пока не является чрезвычайно сложным и дает хорошее представление о методах, используемых для решения подобных проблем целостности данных.
- Обновление узла подписывает обновленные данные и распространяет их через одноранговую сеть.
- Получающие узлы подписывают первую полученную версию и отправляют ее обратно обновляющему узлу.
- Как только обновляющий узел получает подписи от более чем 2/3 всех узлов (включая его самого), он снова распространяет данные по одноранговой сети, собирая подписи.
- Каждый узел, который получит эту версию, подтвержденную подписями от 2/3, продолжит повторную передачу (с экспоненциальной задержкой) всем узлам, которые еще не подтвердили, что они постоянно сохранили окончательную версию данных.
Узел, которому изначально разрешено отправлять обновление, может выйти из строя таким образом, что данные больше никогда не будут обновляться. Но пока он отправляет согласованное обновление, оно будет сохраняться согласованно по всей одноранговой сети.
Может показаться, что большое количество подписей, необходимых для каждого фрагмента данных, потребует много места для хранения. К счастью, этого можно избежать с помощью метода, известного как пороговые подписи.
Но если вы хотите заменить базу данных, недостаточно, чтобы один узел мог обновить часть данных. У вас есть несколько узлов, которым разрешено обновлять одну и ту же часть данных, но вам нужно, чтобы вся сеть согласилась, кто был первым. Вот тут-то и вступает в дело византийское соглашение.
Решения для этого на порядок сложнее, чем то, что я описал выше. Но я могу упомянуть несколько ключевых результатов, о которых нужно знать.
Вам нужно выбрать между двумя моделями отказа. Вы можете предположить, что отказавший узел просто прекращает связь и никогда не отправляет ни одного поврежденного сообщения. Эта модель требует меньше оборудования, но для того, чтобы вывести систему из строя, достаточно одного перевернутого бита.
В качестве альтернативы вы можете выбрать модель византийских отказов, которая позволяет узлу, вышедшему из строя, делать все, что угодно, и система все равно выживет. Чтобы выдержать tотказы в этой модели, вам нужно 3t+1всего узлов. Другими словами, чтобы выдержать один отказавший узел, вам нужно четыре узла. Если у вас всего 10 узлов, можно выдержать отказ 3 узлов.
Вам также придется выбирать между синхронной и асинхронной моделью связи. Синхронная связь означает, что вы делаете предположения о времени связи. Если пакеты достигают пункта назначения дольше, чем предполагалось, система выходит из строя. Более того, если узел выходит из строя, вам придется ждать максимально допустимую задержку, прежде чем система сможет продолжить работу.
Асинхронные модели усложняют разработку программного обеспечения, но у них есть некоторые явные преимущества. Вам не нужно ждать тайм-аутов, вместо этого вам нужно просто подождать, пока вы не услышите более 2/3 узлов, прежде чем вы сможете продолжить, это может быть намного быстрее, чем синхронная модель, где вам нужен большой тайм-аут.
Другим недостатком асинхронной модели является то, что она должна быть рандомизирована. Время выполнения алгоритма становится стохастической переменной без предела для худшего случая. Существует теоретическая возможность, что обновление займет бесконечное время, но можно показать, что вероятность этого равна нулю. И на самом деле можно показать, что среднее число циклов связи является постоянным. Для меня это выглядит гораздо выгоднее по сравнению с синхронной моделью, которая может выйти из строя в случае задержки связи.
Как вы можете себе представить, создание такой системы правильно — непростая задача. Для ее реализации требуются специальные усилия по разработке. Более того, ошибка в программном обеспечении все еще может вывести систему из строя. Если выйдет из строя менее трети узлов, система выживет. Но если в программном обеспечении есть ошибка, вы вполне можете установить это ошибочное программное обеспечение на более чем одну треть узлов.
решение2
Я вижу здесь много возможных проблем.
Во-первых, вам на рассмотрение были предоставлены два непродуманных решения, которые трудно реализовать в представленном виде и неустойчивы к ошибкам.
Во-вторых, вы, похоже, запутались в том, как строить службы данных. Это более тревожно.
Я не уверен, какова ваша ситуация с взаимодействием с описанной средой, но я бы рекомендовал ничего не делать и лучше определить требования и разработать лучший план по их достижению, чем случайные машины, на которых запущено множество баз данных без резервных копий (рабочих или иных).
Если вас беспокоит инвентарь лаборатории, естьмногопрограммного обеспечения, которое решает эту проблему. Если вы работаете с фирменной странностью поставщика, установите его требования к окружающей среде, найдите способ получить доступ к этим данным и сохранить их с некоторой степенью уверенности. Уверяю вас, что это уже было сделано раньше.
Ничего из этого не произойдет, если вы будете задавать неопределенные вопросы исключительно на этом форуме. Если вы чувствуете, что не в своей тарелке, вам следует получить несколько часов времени консультанта, который вам поможет.
решение3
В данной среде представляется существенным, чтобы был единый источник информации для данных. Это правда? Мы не можем сказать.
Всегда будут моменты неудач — нужно проектировать с учетом того, что приемлемо.
Вам нужно придумать ограничения для вашей системы. Должен ли быть один источник данных? Может ли устройство использовать инвентарь в автономном режиме? Может ли быть допущен отказ одного сервера? Может ли система выдержать работу в режиме только для чтения в течение короткого времени?
Как только у вас появятся эти ограничения, вы обнаружите, чтокакпроектирования системы возникает из-за ограничений.