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