- Schnappschüsse (Backup)
- Rückverfolgung
- Neue Funktionen für Thin Clients
- Cluster-Betriebsmodus "Schreibgeschützt"
- Ausführen von benutzerdefiniertem Code in der Sandbox
- Transparente Datenverschlüsselung: Drehung des Hauptschlüssels
- Tools zum Unterbrechen von Benutzeraufgaben und -anforderungen
- Plattformseitiges Caching (.NET)
- Verbinden von Clientknoten mit Serverknoten über NAT
Schnappschüsse (Backup)
In Ignite 2.9.0 wurde es möglich, eine Sicherungskopie aller auf der Festplatte gespeicherten Caches (dh Caches, die im Ignite Native Persistence- Modus ausgeführt werden ) aus dem gesamten Cluster zu erstellen . Snapshots können online in einem aktiven Cluster mit einer Benutzerlast erstellt werden. Dadurch wird eine vollständig konsistente Kopie aller Clusterdaten erstellt.
Sie können ein Backup auf eine der folgenden Arten erstellen:
- Verwenden eines Befehlszeilen-Dienstprogramms control.sh :
control.sh --snapshot create <snapshot name>; - JMX-Operation :
MBean group="Snapshot", name=SnapshotMXBeanImpl, createSnapshot(<snapshot name>); - die API über Java :
Ignite.snapshot().createSnapshot("<snapshot name>").
Wo
<snapshot name>ist der eindeutige Name des Schnappschusses?
Nach Abschluss der Snapshot-Erstellung im Verzeichnis
work/snapshots/<snapshot name>(mit Standardeinstellungen) jedes Knotens wird die Struktur des Dateispeichers dieses Knotens zum Zeitpunkt des Snapshot-Starts neu erstellt. Die generierte Dateistruktur kann in Zukunft zum Wiederherstellen von einer Sicherungskopie verwendet werden, indem Dateien durch Knotendaten durch Dateien aus dem Snapshot-Verzeichnis ersetzt werden.
Weitere Informationen zum Arbeiten mit Schnappschüssen finden Sie in der offiziellen Dokumentation .
Rückverfolgung
Das Ignite-Überwachungssystem wird weiter verbessert, und eine der wesentlichen Neuerungen in Version 2.9 ist das Tracing-Subsystem. Mit der Ablaufverfolgung können Sie Informationen abrufen, die sowohl für das Debuggen in der Entwicklungsphase als auch für die Analyse von Vorfällen nützlich sind. Mithilfe der Ablaufverfolgung wurde es möglich, verteilte Informationen auf niedriger Ebene über den Fortschritt verschiedener Aufgaben im Cluster zu sammeln und diese Informationen zur Diagnose von Leistungsproblemen zu verwenden. Eine Ablaufverfolgung, die den Pfad einer Aufgabe im System zeigt, wird in Form eines Baums gebildet, von dem jede nächste Ebene detailliertere Informationen als die vorherige enthält.
In Ignite 2.9.0 umfasst die Ablaufverfolgung die folgenden internen Komponenten:
- Erkennungsnachrichten;
- Kommunikationsnachrichten
- Austauschprozess;
- Transaktionen.
Um Traces anzuzeigen, müssen sie in ein externes System exportiert werden. Für diese Zwecke verwendet Ignite die OpenCensus-Bibliothek, die standardmäßig mehrere Exporteure für verschiedene Systeme bereitstellt (z. B. in Zipkin).
Sie können die Menge der exportierten Informationen begrenzen, indem Sie eine oder mehrere der oben genannten Komponenten als Umfang und die Abtastfrequenz festlegen (Einstellungen können zur Laufzeit geändert werden).
Weitere Informationen zur Rückverfolgung finden Sie in der offiziellen Dokumentation .
Neue Funktionen für Thin Clients
Die Java- und .NET-Thin Clients verfügen jetzt über Ignite-Funktionen, die zuvor nur im Thick Client verfügbar waren.
Die Fähigkeit zu verwenden:
- cluster API & cluster group API ( .NET java):
- ;
- ;
- , ;
- ;
- compute API ( .NET java):
- . , p2p class loader , class-path ( );
- Service Grid ( java):
- Ignite. compute API, , .
Darüber hinaus hat der .NET Thin Client die Funktion zur automatischen Serverknotenerkennung erhalten, die in Verbindung mit der Partitionserkennungsfunktion aktiviert wird. Bei Verwendung der "Partitionserkennung" stellt der Client eine Verbindung nicht mit einem Serverknoten, sondern mit mehreren gleichzeitig her, um nach Möglichkeit eine Anforderung an den Knoten zu senden, der der Hauptknoten für die Daten in dieser Anforderung ist. Gleichzeitig ermöglicht die automatische Erkennung von Clusterknoten, dass nicht alle Adressen von Clusterknoten in der Clientkonfiguration aufgelistet werden. Es reicht aus, dass der Client über die in der Konfiguration aufgeführten Adressen eine Verbindung zu mindestens einem Live-Host herstellen kann. Der Client erhält die Adressen der verbleibenden Knoten vom Cluster.
Weitere Informationen zur Verwendung der neuen Funktionen finden Sie in den entsprechenden Unterabschnitten der Dokumentation zu Java Thin Client und .NET Thin Client .
Cluster-Betriebsmodus "Schreibgeschützt"
Vor Release 2.9.0 hatte Ignite nur zwei Status des Clusters: Der Cluster konnte entweder inaktiv (Knoten wurden in einer Topologie gesammelt, Aktionen mit Caches wurden jedoch verboten) oder aktiv (Aktionen waren zulässig). In Version 2.9.0 wurde ein neuer Clusterstatus hinzugefügt - "schreibgeschützt". Dies ist nützlich, um einige Wartungsarbeiten durchzuführen (z. B. Überprüfung der Datenintegrität).
Weitere Informationen zu den Status des Clusters finden Sie in der offiziellen Dokumentation .
Ausführen von benutzerdefiniertem Code in der Sandbox
Ignite kann benutzerdefinierten Code (z. B. Rechenaufgaben, Ereignis-Listener, verschiedene Filter) auf Serverknoten ausführen. Dieser Code wurde mit den gleichen Rechten wie der Ignite-Systemcode ausgeführt und die gesamte Java-API stand ihm ohne Einschränkungen zur Verfügung. Potenziell unsicherer Code kann die Leistung des Clusters beeinträchtigen (z. B. Ignite-Datendateien löschen, JVM beenden usw.).
In Version 2.9.0 wurde es möglich, solchen Code in der "Sandbox" mit den Rechten auszuführen, die explizit dem Zugriffssubjekt zugewiesen wurden, der die Ausführung dieses Codes angefordert hatte (z. B. dem Clientknoten). Die einem Accessor zugewiesenen Rechte sind eine Sammlung von Klassenobjekten
java.security.Permission, die von Java überprüft werden, bevor eine Aktion ausgeführt wird.
Damit Ignite Sandbox funktioniert, müssen zwei Komponenten installiert und aktiviert sein:
- Java-Sicherheitsmanager. Verantwortlich für die Autorisierung von Themen beim Aufrufen von System-Java-Bibliotheken. Standardmäßig deaktiviert;
- Sicherheitsprozessor zünden. Verantwortlich für die Authentifizierung von Zugriffsthemen. "Out of the Box" mit Ignite wird nicht mitgeliefert, erfordert eine unabhängige Implementierung und Verbindung über ein Plugin.
Weitere Informationen zu Ignite Sandbox finden Sie in der offiziellen Dokumentation .
Transparente Datenverschlüsselung: Drehung des Hauptschlüssels
Die transparente Datenverschlüsselung (TDE) ist eine Funktion, mit der Sie keine Daten im Klartext auf der Festplatte speichern können. Das Verschlüsseln von Daten auf einer Festplatte mit einem DBMS ist beispielsweise für die Zertifizierung der PCI DSS-Datensicherheit erforderlich. In Apache Ignite wurde die grundlegende TDE-Funktionalität (Phase 1) in Version 2.7 implementiert. In der aktuellen Version wurde die zweite Phase von TDE implementiert - die Drehung des Hauptschlüssels (die auf der Festplatte gespeicherten Cache-Schlüssel werden mit dem Hauptschlüssel verschlüsselt). Die dritte Phase von TDE (Cache Key Rotation) wird in der nächsten Version implementiert.
Weitere Informationen zur Rotation des Hauptschlüssels finden Sie in der offiziellen Dokumentation .
Tools zum Unterbrechen von Benutzeraufgaben und -anforderungen
Frühere Versionen von Ignite verfügten nicht über einen konsistenten Mechanismus zum Unterbrechen von Benutzeraufgaben und -anforderungen durch den Administrator. Benutzer hatten die Möglichkeit, ihre Aufgaben und Anforderungen abzubrechen. Für Administratoren standen separate, in keiner Weise miteinander korrelierte Tools zur Verfügung (z. B. war es möglich, Transaktionen nach Liste, Filter, über JMX oder das Dienstprogramm control.sh abzubrechen und eine SQL-Abfrage mit einem SQL-Befehl zu "töten"
KILL QUERY). In der aktuellen Version kann der Administrator unterbrechen
- verschiedene Arten von Abfragen (SQL, Scan, fortlaufend),
- Transaktionen,
- Rechenaufgaben,
- Dienste entzünden,
Verwenden einer einheitlichen Schnittstelle.
Alle diese Arten von Aufgaben und Anforderungen können mit einer der folgenden Methoden unterbrochen werden:
- das Dienstprogramm control.sh;
- über JMX;
- SQL-Befehl.
Weitere Informationen zum Unterbrechen von Benutzeraufgaben und -anforderungen finden Sie in der offiziellen Dokumentation .
Plattformseitiges Caching (.NET)
Ignite.NET bietet die Möglichkeit, eine zusätzliche Caching-Ebene auf der .NET-Seite zu verwenden. Die Daten im .NET-Speicher in dieser Schicht werden in einer deserialisierten Form gespeichert, sodass Sie die bereits zwischengespeicherten Daten ohne zusätzliche JNI-Aufrufe und Deserialisierung lesen können. Dies erhöht die Geschwindigkeit von nicht-transaktionalen Lesevorgängen erheblich.
Weitere Informationen zum plattformseitigen Caching finden Sie in der offiziellen Dokumentation .
Verbinden von Clientknoten mit Serverknoten über NAT
In Ignite 2.9.0 wurde ein Netzwerkinteraktionsmodus angezeigt, in dem Verbindungen zwischen dem "fetten" Client und dem Server nur auf der Clientseite initiiert werden (der Server initiiert keine Verbindungen zum Client, fordert den Client jedoch auf, über den bereits eingerichteten Client eine Verbindung herzustellen, wenn eine direkte Interaktion mit dem Client erforderlich ist Client-Verbindungen zu anderen Servern). Diese Betriebsart ermöglicht die Verwendung von Clusterkonfigurationen, in denen sich NAT zwischen dem Client- und dem Serverknoten befindet (z. B. wenn Clients in einer virtuellen Umgebung ausgeführt werden).
Ausführlichere Informationen zum Verbinden von Clientknoten über NAT finden Sie in der offiziellen Dokumentation .
Fazit
Dies sind die wichtigsten Änderungen in der Version Apache Ignite 2.9.0. Die Liste der Änderungen ist jedoch nicht auf diese beschränkt. Wie üblich haben wir viele Fehler behoben und viele andere nützliche Verbesserungen vorgenommen. Eine vollständige Liste der Änderungen finden Sie in den Versionshinweisen .