Citrix ADC

Référence DataStream

Cette référence décrit les protocoles MySQL et TDS, les versions de la base de données, les méthodes d’authentification et les jeux de caractères pris en charge par la fonctionnalité DataStream. Il décrit également comment Citrix ADC traite les demandes de transaction et les requêtes spéciales qui modifient l’état d’une connexion.

Vous pouvez également configurer l’appliance Citrix ADC pour générer des messages de journal d’audit pour la fonctionnalité DataStream.

Versions de base de données, protocoles et méthodes d’authentification prises en charge

  Base de données MySQL Base de données MS SQL
Versions de base de données Base de données MySQL versions 4.1, 5.0, 5.1, 5.4, 5.5, 5.6 Versions de base de données MS SQL 2000, 2000SP1, 2005, 2008, 2008R2, 2012, 2014 (prise en charge de l’authentification Kerberos)
Protocoles Protocole MySQL version 10. Pour plus d’informations sur le protocole MySQL, voir Protocole client/serveur MySQL Protocole TDS (Tabular Data Stream) version 7.1 et supérieure. Pour plus d’informations sur le protocole TDS, voir Protocole de flux de données tabulaire
Méthodes d’authentification L’authentification native MySQL est prise en charge. L’authentification SQL Server et l’authentification Windows (Kerberos/NTLM) sont prises en charge.

Jeux de caractères

La fonctionnalité DataStream prend en charge uniquement le jeu de caractères UTF-8.

Le jeu de caractères utilisé par le client lors de l’envoi d’une requête peut être différent du jeu de caractères utilisé dans les réponses du serveur de base de données. Bien que le paramètre charset soit défini lors de l’établissement de la connexion, il peut être modifié à tout moment en envoyant une requête SQL. Le jeu de caractères est associé à une connexion et, par conséquent, les requêtes sur les connexions avec un jeu de caractères ne peuvent pas être multiplexées sur une connexion avec un jeu de caractères différent.

L’appliance Citrix ADC analyse les requêtes envoyées par le client et les réponses envoyées par le serveur de base de données.

Le jeu de caractères associé à une connexion peut être modifié après la poignée de main initiale en utilisant les deux requêtes suivantes :

SET NAMES <charset> COLLATION <collation>

SET CHARACTER SET <charset>

Transactions

Dans MySQL, les transactions sont identifiées à l’aide du paramètre de connexion AUTOCOMMIT ou des requêtes BEGIN:COMMIT. Le paramètre AUTOCOMMIT peut être défini pendant la poignée de main initiale ou après l’établissement de la connexion à l’aide de la requête SET AUTOCOMMIT.

L’appliance Citrix ADC analyse explicitement chaque requête pour déterminer le début et la fin d’une transaction.

Dans le protocole MySQL, la réponse contient deux indicateurs pour indiquer si la connexion est une transaction : les indicateurs TRANSACTION et AUTOCOMMIT.

Si la connexion est une transaction, l’indicateur TRANSACTION est défini. Ou, si le mode AutoCommit est OFF, l’indicateur AUTOCOMMIT n’est pas défini. L’appliance ADC analyse la réponse et si l’indicateur TRANSACTION est défini ou si l’indicateur AUTOCOMMIT n’est pas défini, il ne procède pas au multiplexage de connexion. Lorsque ces conditions ne sont plus remplies, l’appliance ADC commence le multiplexage de connexion.

Remarque

Les transactions sont également prises en charge pour MS SQL.

Requêtes spéciales

Il existe des requêtes spéciales, telles que SET et PREPARE, qui modifient l’état de la connexion et peuvent interrompre la commutation de demande. Par conséquent, ces requêtes doivent être traitées différemment.

Lors de la réception d’une demande avec des requêtes spéciales, l’appliance Citrix ADC envoie une réponse OK au client et stocke également la demande dans la connexion.

Lorsqu’une requête non spéciale, telle que INSERT et SELECT, est reçue avec une requête stockée, l’appliance Citrix ADC recherche d’abord la connexion côté serveur sur laquelle la requête stockée a déjà été envoyée au serveur de base de données. Si aucune connexion de ce type n’existe, l’appliance ADC crée une connexion et envoie d’abord la requête stockée, puis envoie la requête avec la requête non spéciale.

Dans les requêtes spéciales SET, USE db et INIT_DB, l’appliance modifie un champ de la connexion côté serveur correspondant à la requête spéciale. Cette modification entraîne une meilleure réutilisation de la connexion côté serveur.

Seules 16 requêtes sont stockées dans chaque connexion.

Voici une liste des requêtes spéciales pour lesquelles le dispositif ADC a un comportement modifié.

  • Requête SET

    Les requêtes SQL SET définissent les variables associées à la connexion. Ces requêtes sont également utilisées pour définir des variables globales, mais à l’heure actuelle, l’appliance ADC n’est pas en mesure de faire la différence entre les variables locales et globales. Pour cette requête, l’appliance ADC utilise le mécanisme ‘store and forward’.

  • Requête USE <db>

    À l’aide de cette requête, l’utilisateur peut modifier la base de données associée à une connexion. Dans ce cas, l’appliance ADC analyse la valeur <db> envoyée et modifie un champ dans la connexion côté serveur pour refléter la nouvelle base de données à utiliser.

  • INIT_DB, commande

    À l’aide de cette requête, l’utilisateur peut modifier la base de données associée à une connexion. Dans ce cas, l’appliance ADC analyse la valeur <init_db> envoyée et modifie un champ dans la connexion côté serveur pour refléter la nouvelle base de données à utiliser.

  • COM_PREPARE

    L’appliance ADC arrête l’activation de la demande lors de la réception de cette commande.

  • Requête PREPARE

    Cette requête est utilisée pour créer des instructions préparées qui sont associées à une connexion. Pour cette requête, l’appliance ADC utilise le mécanisme ‘store and forward’.

Prise en charge des messages du journal d’audit

Vous pouvez maintenant configurer l’appliance Citrix ADC pour générer des messages de journal d’audit pour la fonctionnalité DataStream. Les messages du journal d’audit sont générés lorsque des connexions côté client et côté serveur sont établies, fermées ou supprimées. Les catégories de messages que vous pouvez enregistrer et afficher sont ERREUR et INFO. Les messages d’erreur pour les connexions côté client commencent par « CS » et les messages d’erreur pour les connexions côté serveur commencent par « SS ». Des informations supplémentaires sont fournies si nécessaire. Par exemple, les messages de journalisation pour les connexions fermées (CS_CONN_CLOSED) incluent uniquement l’ID de connexion. Toutefois, les messages de journal pour les connexions établies (CS_CONN_ESTD) incluent des informations telles que le nom d’utilisateur, le nom de la base de données et l’adresse IP du client en plus de l’ID de connexion.

Référence DataStream