Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Protokollerweiterungen - Architektur
Um die Erweiterbarkeit auf Datenverkehrsebene zu erreichen, wird die Verkehrsverarbeitung auf einer NetScaler-Appliance als Pipeline aus separaten Verarbeitungsmodulen bereitgestellt. Der Verkehr fließt durch sie, während er ihn vom Eingang bis zum Ausgang verarbeitet. Diese Module in der Pipeline folgen einem Shared-Nothing-Modell. Die Nachrichtenübergabe wird verwendet, um die Verkehrsdaten von einem Modul in der Pipeline zum nächsten Modul zu senden.
Bestimmte Punkte in der Datenverkehrsverarbeitungspipeline sind erweiterbar, sodass Sie Code hinzufügen können, um das NetScaler-Verhalten anzupassen.
Standardmäßig umgeht der Verkehr ein programmierbares Modul, zu dem Sie keinen Code hinzufügen.
Verhaltensweisen
Die programmierbaren Schnittstellen zur Anpassung der Verkehrssteuerung werden als Verhalten bezeichnet. Verhalten ist im Grunde eine Formalisierung gängiger programmierbarer Muster, die auf einer NetScaler-Appliance verfügbar sind. Die Verhaltensweisen bestehen aus einem vordefinierten Satz von Event-Callback-Funktionen. Sie können ein Verhalten implementieren, indem Sie Callback-Funktionen bereitstellen, die dem Verhalten entsprechen.
Das Verhalten des TCP-Clients besteht beispielsweise aus einer Callback-Funktion (on_data), die TCP-Client-Datenstream-Ereignisse verarbeitet. Um Message Based Load Balancing (MBLB) für ein TCP-basiertes Protokoll zu implementieren, können Sie Code für diese Callback-Funktion hinzufügen, um den TCP-Datenstrom vom Client zu verarbeiten und den Byte-Stream in Protokollnachrichten zu analysieren.
Kontext:
Die Callback-Funktionen in einem Verhalten werden mit einem Kontext aufgerufen, bei dem es sich um den Status des Verarbeitungsmoduls handelt. Der Kontext ist die Instanz des Verarbeitungsmoduls. Beispielsweise werden die TCP-Clientverhaltens-Callbacks mit unterschiedlichen Kontexten für verschiedene Client-TCP-Verbindungen aufgerufen.
Nutzlast:
Zusätzlich zum Kontext können die Verhaltensrückrufe andere Argumente haben. Normalerweise wird der Rest der Argumente als Nutzlast übergeben, was die Sammlung aller Argumente ist.
Die Instanzen des programmierbaren Verarbeitungsmoduls können also als eine Kombination aus Instanzstatus und Ereignisrückruffunktionen angesehen werden, dh dem Kontext plus Verhalten. Und der Verkehr fließt durch die Pipeline als Ereignisnutzlast.
Informationen zu NetScaler API-Erweiterungen finden Sie unter Referenz zur NetScaler-Erweiterung.
Das folgende Code-Snippet zeigt eine benutzerdefinierte Funktion zum Behandeln von TCP-Clientdatenstromereignissen. Der Kontext und die Payload werden per NetScaler-Code an die Funktion übergeben. Dieser Code leitet einfach die bei jedem Aufruf empfangenen TCP-Daten an den nächsten Verarbeitungsmodulkontext in der Pipeline weiter. In diesem Fall ist das nächste Modul der Load Balancing (LB) -Kontext, bei dem es sich um ein natives NetScaler Modul handelt.
function client.on_data(ctxt, payload)
ns.send(ctxt.output, "DATA", {data = payload.data})
end