Как настроить OpenSplice DDS на 100000 узлов?

Question

Какой правильный подход использовать для настройки OpenSplice DDS для поддержки 100000 или более узлов?

Могу ли я использовать иерархическую схему именования для имен разделов, так что "headquarters.city.location_guid_xxx" не позволит пакетам покинуть местоположение, а "company.city*" позволит выровнять образцы по городу и т. Д.? Или все узлы будут знать обо всех этих разделах на тот случай, если они захотят опубликовать их?

Службы долговечности выберут мастера, когда он придет. Если одна служба долговечности работает на Raspberry Pi в удаленном месте, работающем по каналу 3G, что может помешать ей стать хозяином "штаба" и выйти из строя?

Я экспериментирую с настройками долговечности на удаленном узле, чтобы я использовал location_guid_xxx, но для облачного сервера "штаб-квартира" я использую штаб-квартиру

На удаленном клиенте я мог бы сделать это:

<Merge scope="Headquarters" type="Ignore"/>
<Merge scope="location_guid_xxx" type="Merge"/>

таким образом, местоположение не будет главным для юниверса, но может ли служба долговечности в этом местоположении быть главной для этого местоположения?

Если у меня 100000 местоположений, значит ли это, что все они должны быть перечислены в "Области слияния" в файле ospl.xml, расположенном в штаб-квартире? Я думаю, что одно это может ограничить размер сети, с которой я могу справиться.

Я предполагаю, что этот продукт будет обрабатывать сценарий Интернета вещей такого рода. Кто-нибудь еще пробовал это?

Answer 1

Учитывая масштаб вашей системы, я думаю, что вы должны серьезно рассмотреть вопрос об использовании Vortex-Cloud (см. Эти слайды http://slidesha.re/1qMVPrq). Vortex Cloud позволит вам лучше масштабировать вашу систему, а также работать с NAT/Firewall. Кроме того, вы сможете использовать TCP/IP для связи от вашего Raspberry Pi с экземпляром облака, что позволит избежать любых проблем, связанных с NAT / межсетевыми экранами.

Прежде чем перейти к вашему вопросу о долговечности, я хотел бы отметить еще кое-что. Если вы попытаетесь построить плоскую систему с узлами 100K, вы сгенерируете совсем немного информации для обнаружения. Помимо генерирования некоторого трафика, это будет занимать память ваших конечных приложений. Если вместо этого вы используете Vortex-Cloud, мы разыгрываем трюки, чтобы ограничить информацию об обнаружении. Например, если у вас есть считывающее устройство для записи данных, соответствующее 100 КБ, при использовании Vortex-Cloud средство записи данных будет соответствовать только в конечной точке и, таким образом, сократит информацию об обнаружении в 100 К раз!!!

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

НТН.

A +