Versionshinweise

2. Änderungen an dieser Version

2.1. Neue Funktionen

• Ermöglichung der Erkennung und Benachrichtigung doppelter IP-Adressen zwischen der iNode-TAN-Schnittstelle/den TAN-Diensten und den IP-Adressen für Instanzen und Geräte südlich des iNode.
• Erweiterung der „Sicherheitsrichtlinie“, um es Benutzern zu ermöglichen, Firewallregeln zwischen dem Dienst und dem Gerät und zwischen dem Gerät und dem Dienst innerhalb eines TAN-Netzwerks festzulegen.
• Support für Virtual Edge in den Amazon Web Services (AWS).

2.2. Verbesserungen

• Erweiterung der Konfiguration des Zeitservers, um es Benutzern zu ermöglichen, einen FQDN eines NTP-Servers festzulegen und in dem iNode einen Zeitserver einzurichten.
• Verbesserungen, um es Administratoren von Organisationen zu ermöglichen, für alle Benutzer in einer Organisation Multi-Faktor-Authentifizierung zu nutzen.
• Zahlreiche Verbesserungen an dem Design der Orchestrator-Benutzeroberfläche.

2.3. Behebungen von Fehlern

Dies sind einige der bedeutenden Fehler, die behoben werden konnten:

1. MAC-Adresse der WAN-Schnittstelle ändert sich beim Neustart des iNode.
2. In seltenen Fällen wurden Anwendungsprotokolle in dem iNode nicht geteilt. Dies führte zu einem Überfüllen des Dateisystems.
3. „User-Agent“ ist in der Tunnel-Anfrage auf „Standard“ eingestellt.

3. Voraussetzungen

3.1. Cloud-Anforderungen

Die folgenden Cloud-Plattformen werden unterstützt:

• Amazon AWS
• Microsoft Azure
• VMware vSphere v6.x
• Google Cloud

3.1.1. Computing-Anforderungen des Virtual iNode

2 vCPU, 2 GB RAM, 10 GB HDD, öffentliche IP-Adresse

3.2. Hardware-Anforderungen

• Die folgenden Hardware-Plattformen werden für Edge iNode unterstützt:
  • ADLINK MXE-211
    • Für die Unterstützung mobiler Breitbandnetzwerke ist das mobile Breitbandmodul SIMCom SIM7100A erforderlich
  • Advantech UNO 2484G
  • Dell Edge Gateway 5000 (Modell: LBEE5ZZ1EN)
  • Dell PowerEdge R240
  • Lanner LEC-7230M-J11A
  • Lanner NCA-1510D
  • Für die Unterstützung mobiler Breitbandnetzwerke ist AT&T oder Verizon micro SIM erforderlich
  • Lanner NCA-1510A
  • Supermicro SYS-E50-9AP

4. Probleme

4.1. Beschränkungen

1. Bei einem Neustart des iNode kann es ungefähr 5 Minuten in Anspruch nehmen, bis sich der iNode-Status im Orchestrator nach dem Neustart zu „Erreichbar“ ändert.
2. Bei der ersten Verbindung von iNodes mit dem Orchestrator müssen beide iNodes den Status „Erreichbar“ aufweisen.
3. Bei der Ausführung von Virtual iNode in Microsoft Azure kann das Hochladen der VHD-Datei je nach Ihrer Netzwerkverbindung viel Zeit in Anspruch nehmen.
4. Wenn mehrere Edge-iNode-Netzwerke mit einem Virtual-iNode-Netzwerk verbunden sind, ist ein Datenverkehr zwischen Remote-Netzwerken nicht möglich, falls eines der Edge-iNode-Netzwerke ein repräsentatives Netzwerk nutzt.
5. Falls ein repräsentatives Netzwerk genutzt wird und es einen kontinuierlichen Datenverkehr zwischen dem Edge-iNode- und einem Virtual-iNode-Netzwerk gibt, wird der kontinuierliche Datenverkehr nach dem Neustart eines der beiden iNode-Netzwerke wiederhergestellt.
6. Wenn mehrere Edge-iNode-Netzwerke mit einem Virtual-iNode-Netzwerk verbunden sind, muss das Remote-Virtual-iNode-Netzwerk als Standardziel festgelegt werden, um Datenverkehr zwischen Remote-Netzwerken zu ermöglichen.
7. Falls ein Remote-Netzwerk als Standardziel festgelegt ist und es einen kontinuierlichen Datenverkehr von einem lokalen Netzwerk ins Internet gibt, führt die Änderung auf das WAN-Netzwerk als Standardziel zu Unterbrechungen des Datenverkehrs, außer der kontinuierliche Datenverkehr wird wiederhergestellt.
8. Eine SkySpark-Lizenz ist erforderlich, um einen Dateinamen mit der Dateierweiterung „.props“ zu ermöglichen.
9. Falls ein Proxy-Server auf einem Virtual iNode konfiguriert ist, schlägt die Verbindung zwischen dem Virtual-iNode-Netzwerk und einem Edge-iNode-Netzwerk fehl, außer auf dem Proxy-Server ist die Funktion „Portweiterleitung“ aktiviert.
10. Falls für ein iNode von dem Orchestrator der eigenständige Modus aktiviert ist, muss sich das iNode mindestens eine Minute in dem Status „ERREICHBAR“ befinden, damit die Änderung abgeschlossen werden kann.
11. Falls die öffentliche IP-Adresse des iNode geändert wird, wird die Verbindung zu dem Remote-Netzwerk, falls zutreffend, automatisch getrennt und wiederhergestellt.
12. Die maximale Größe der heruntergeladenen Dienstprotokolle beträgt 10 MB.
13. Falls ein Remote-Netzwerk als Standardziel festgelegt ist, müssen Sie die öffentlichen DNS-Server als die DNS-Server für Ihre Dienste konfigurieren.
14. Wenn Sie eine statische IP-Adresse für die iNode-Ethernet-Uplink-Schnittstelle, allerdings keinen Nameserver konfigurieren, kann sich der Status des iNode bei der Nutzung einer iNode-CLI zu „Nicht erreichbar“ ändern, bis Sie einen Nameserver konfigurieren.
15. Ein repräsentatives Netzwerk kann nicht konfiguriert werden, um eine statische Route für Remote-Netzwerke zu unterstützen, außer es liegt ein Konflikt vor.
16. Für eine Bearbeitung eines Secret muss der Dienst neugestartet werden.
17. Eine Adresszuweisung kann nur während des Hinzufügens des Netzwerks und nicht zu einem späteren Zeitpunkt durch Bearbeitung des Netzwerks eingerichtet werden.
18. Falls ein WAN-Netzwerk als Standardziel festgelegt ist und es einen ausgehenden Datenverkehr von dem lokalen Netzwerk ins Internet oder in ein LAN gibt, finden benutzerdefinierte Sicherheitsrichtlinien für das lokale Netzwerk keine Anwendung.
19. Bei der Hardware-Überwachung werden der Status der Stromversorgung und die Temperatur nicht berücksichtigt.
20. Bei der Konfiguration der Zeitzoneneinstellungen für den Container muss der Application Packager sicherstellen, dass die Pakete „tzdata“ und „date“ installiert sind, damit das Container-Image ausgeführt werden kann.
21. Fügen Sie bei der Konfiguration der Zeitzoneneinstellungen für den Container den Kerndiensten den Bezeichner "_iotium_core_service=true“ hinzu, um sicherstellen, dass für diese nicht andere Zeitzoneneinstellungen gelten. Dienste ohne den Bezeichner "_iotium_core_service=true“ werden neu gestartet und mit der konfigurierten Container-Zeitzone angezeigt.
22. Bei der Konfiguration eines Proxy-Servers für Virtual Edge über GCP ist die IP-Adresse identisch mit der auf der iNode-Detailseite der Orchestrator-Benutzeroberfläche angezeigten öffentliche IP-Adresse.

4.2. Bekannte Probleme

1. Wenn das Uplink-Netzwerk von Edge iNode über eine mobile Breitbandverbindung verbunden ist und Sie die IP-Adresse der Ethernet-Schnittstelle des iNode-Netzwerks 2 (eth1) ändern möchten, darf es sich dabei nicht um dasselbe Subnet des Uplink-Netzwerks handeln.
2. Falls in den letzten 24 Stunden kein Dienstprotokoll erstellt wurde, werden in dem Fenster „Dienstprotokolle“ im Orchestrator keine Protokolle angezeigt, selbst wenn zu einem früheren Zeitpunkt Protokolle erstellt wurden.
3. Wenn Sie einen ausgeführten Dienst bearbeiten und dessen Image ändern, wird bis zu dem Neustart des Dienstes nach dem Hinzufügen des neuen Image in iNode für den Dienst eine Fehlermeldung angezeigt.
4. Falls Sie versuchen, sich Dienstprotokolle anzeigen zu lassen oder herunterzuladen, kann die Fehlermeldung „504 Gateway Time-out“ angezeigt werden, falls mehrere Dienste regelmäßig Protokolle erstellen und die Verbindung des iNode-Uplink-Netzwerks schwach ist. Dies ist ein üblicherweise nur vorübergehendes Problem, versuchen Sie es einfach zu einem späteren Zeitpunkt erneut.
5. Wenn Sie die iNode-CLI nutzen und einen Nameserver konfigurieren, nutzt iNode diesen Nameserver zusätzlich zu den von dem DHCP-Server bereitgestellten Nameservers, falls zutreffend.
6. Schaubilder mit Metriken zeigen nicht immer an, wenn die Verbindung eines iNode für einen Moment unterbrochen wird.
7. Bei Schaubildern mit Metriken und dem Datenverkehrsaufkommen von Schnittstellen auf der iNode-Detailseite kann es nach der Bereitstellung des iNode einige Minuten dauern, bis diese angezeigt werden.
8. Wenn ein Edge-iNode-Netzwerk ein repräsentatives Netzwerk nutzt, wird der Datenverkehr von einem gerouteten Segment hinter dem Virtual iNode nicht zu dem Edge-iNode-Netzwerk geleitet.
9. Wenn ein Edge-iNode-Netzwerk ein repräsentatives Netzwerk nutzt, wird der Datenverkehr von dem Virtual-iNode-Netzwerk nicht zu einem gerouteten Segment hinter dem Edge-iNode-Netzwerk geleitet.
10. Remote-Netzwerke ermöglichende, statische Routen können nicht genutzt werden, falls ein repräsentatives Netzwerk konfiguriert wird.
11. Die Anmeldung in der ioTium-CLI läuft nach dem Ablauf einer inaktiven Sitzung ab. In der ioTium-CLI wird die Fehlermeldung 401 angezeigt, sofern sich der Benutzer nicht erneut über die ioTium-CLI im Orchestrator anmeldet.
12. Wenn Sie ein Netzwerk bearbeiten oder eine benutzerdefinierte Sicherheitsrichtlinie mithilfe der ioTium-CLI zu einem Netzwerk hinzufügen, werden bestehende statische Routen entfernt.
13. Wenn Sie ein Netzwerk mit mehreren Diensten neu starten, kann es je nach Ihrer Edge-iNode-Hardware einige Minuten dauern, bis die Dienste wieder in Betrieb genommen werden.
14. Wenn in einem iNode-Cluster alle Kandidaten in der Masterauswahl dieselbe Priorität aufweisen, wird der Kandidat mit der höchsten IP-Adresse möglicherweise nicht immer als die Master-IP-Adresse ausgewählt.
15. Wenn in einem iNode-Cluster der NTP-Kerndienst als Singleton ausgeführt wird, werden die auf den Back-up-iNodes ausgeführten Dienste nicht mit dem NTP-Dienst synchronisiert.
16. Die Liste mit den konfigurierten Zeitservern, die derzeit mit dem iNode-Server synchronisiert werden, steht im Orchestrator für iNodes mit Debian-Distribution nicht zur Verfügung.
17. Bei einem iNode-Cluster mit einem als Singleton ausgeführten Dienst, der sich aufgrund eines Fehlers in dem Status „UNBEKANNT“ befindet, ist die Meldung von dem Container im Orchestrator nicht verfügbar.
18. Wenn Sie ein dynamisches Edge-iNode-Netzwerk erstellen, müssen Sie das Netzwerk bearbeiten, um dieses mit einem Remote-Netzwerk zu verbinden.

5. Archiv

Klicken Sie hier, um sich Versionshinweise zu früheren Versionen anzeigen zu lassen.