Envoi de données à un serveur

Editer en ligne

L'API permet aux clients d'application d'envoyer des données ou des objets nommés et leurs données associées à l'espace de stockage du serveur IBM® Storage Protect .

Astuce: Vous pouvez sauvegarder ou archiver des données. Effectuez toutes les opérations d'envoi d'une transaction.

Modèle de transaction

Toutes les données envoyées au stockage IBM Storage Protect lors d'une opération de sauvegarde ou d'archivage le sont dans le cadre d'une transaction. Un modèle de transaction fournit un degré d'intégrité des données élevé mais il impose certaines restrictions qu'un client d'application doit prendre en considération.

Démarrer une transaction par un appel à dsmBeginTxn ou terminer une transaction par un appel à dsmEndTxn. Une seule transaction correspond à une action atomique. Les données envoyées dans le cadre d'une transaction sont validées dans le système à la fin de la transaction ou sont annulées si la transaction est interrompue.

Les transactions peuvent être constituées d'envois à objet unique ou d'envois à objets multiples. Pour améliorer vos performances système en diminuant le temps système, envoyez des objets de taille inférieure lors d'une transaction à plusieurs objets. Le client de l'application détermine si les transactions uniques ou les transactions multiples sont appropriées.

Envoyez tous les objets figurant dans une transaction à objets multiples vers la même destination de copie. Si vous devez envoyer un objet vers une destination différente de celle de l'objet précédent, arrêtez la transaction en cours, puis démarrez une nouvelle transaction. Au cours de la nouvelle transaction, vous pouvez envoyer l'objet vers la nouvelle destination de copie.

Note : Les objets qui ne contiennent pas de données binaires ( sizeEstimate=0 ) ne font pas l'objet d'une vérification de la cohérence de la destination de la copie.

IBM Storage Protect limite le nombre d'objets qui peuvent être envoyés dans une transaction à objets multiples. Pour connaître cette limite, appelez dsmQuerySessInfo et examinez le champ maxObjPerTxn champ. Cette zone affiche la valeur de l'option TXNGroupmax définie sur votre serveur.

L'application client doit faire le suivi des objets envoyés au cours d'une transaction pour effectuer le traitement du processus de relance ou le traitement des erreurs si la transaction est interrompue. Une transaction peut être interrompue à n'importe quel moment par le serveur ou le client. L'application client doit être abilitée à gérer les interruptions des transactions qui n'ont pas été lancées par elle.

Agrégation de fichiers

Les serveurs IBM Storage Protect utilisent une fonction appelée agrégation de fichiers. Grâce à cette fonction, tous les objets envoyés au cours d'une seule transaction sont stockés dans le même emplacement, permettant ainsi d'améliorer la performance et d'économiser de l'espace. Vous pouvez poursuivre l'interrogation et la restauration des objets séparément.

Pour utiliser cette fonction, tous les objets figurant dans une transaction doivent être dotés du même nom d'espace fichier. Si ce nom est modifié au cours d'une transaction, le serveur arrête l'exécution de l'objet agrégé existant et lance un nouvel objet.

Transfert de données hors réseau local

L'API peut tirer parti du transfert de données hors réseau local si l'option dsmSetUp pour le traitement multitâche est ACTIF. L'API renvoie l'existence d'une destination sans réseau local dans la structure de réponse suivante Query Mgmt Class structure de réponse archDetailCG ou le champ backupDetailCG champ bLanFreeDest.

Vous pouvez exécuter des opérations hors réseau local sur les plateformes prises en charge par l'agent de stockage. La plateforme Macintosh est exclue.

Des informations hors réseau local sont disponibles dans les structures de résultat ci-dessous. La structure de sortie (dsmEndGetDataExOut_t) pour dsmEndGetData comprend le champ, totalLFBytesRecv. Il s'agit du nombre total d'octets hors réseau local reçus. La structure de sortie (dsmEndSendObjExOut_t) pour dsmEndSendObjEx comprend le champ, totalLFBytesSent. Il s'agit du nombre total d'octets hors réseau local qui ont été envoyés.

Opérations d'écriture simultanée

Vous pouvez configurer les pools de stockage du serveur IBM Storage Protect pour qu'ils écrivent simultanément dans un pool de stockage primaire et dans un ou plusieurs pools de stockage de copie au cours d'une sauvegarde ou d'une archive. Utilisez cette configuration pour créer plusieurs copies de l'objet.

Si une opération d'écriture simultanée échoue, le code de retour de la fonction dsmEndTxn peut être DSM_RC_ABORT_STGPOOL_COPY_CONT_NO, ce qui indique que l'écriture dans l'un des pools de stockage de copies a échoué et que l'option de pool de stockage IBM Storage Protect COPYCONTINUE était définie sur NO. L'application se termine et le problème doit être résolu par l'administrateur du serveur IBM Storage Protect .

Pour plus d'informations sur la configuration des opérations d'écriture simultanée, voir la documentation du serveur IBM Storage Protect .

Amélioration des performances de l'API

Vous pouvez utiliser les options client tcpbuffsize et tcpnodelay, ainsi que le paramètre de l'API DataBlk pour améliorer les performances de l'API.

Le tableau 1 décrit les actions que vous pouvez entreprendre pour améliorer les performances de l'API.

Tableau 1. Options de sauvegarde-archivage et paramètre de l'API améliorant les performances
Options client de sauvegarde-archivage	Description
tcpbuffsize	Indique la taille de la mémoire tampon TCP. La valeur par défaut est 31 Ko. Pour améliorer les performances, définissez cette valeur sur 32 Ko.
tcpnodelay	Indique si des mémoires tampon de taille inférieure doivent être envoyées au serveur plutôt que de les mettre en attente. Pour améliorer les performances, définissez cette option sur yes pour toutes les plateformes. Cette option n'est valable que pour Windows et AIX®.
Paramètre de l'API	Description
DataBlk	Ce paramètre est utilisé avec l'appel de fonction dsmSendData pour déterminer la taille de la mémoire tampon de l'application. Pour obtenir des résultats optimaux, définissez le paramètre comme un multiple de la valeur tcpbuffsize spécifiée à l'aide de tcpbuffsize moins 4 octets. Par exemple, définissez une valeur de 28 pour ce paramètre lorsque la valeur de tcpbuffsize est définie sur 32 Ko.

Chaque appel de dsmSendData est synchrone et ne renvoie pas de données tant que les données transférées vers l'API dans dataBlkPtr ne sont pas vidées sur le réseau. L'API ajoute un supplément de 4 octets à chaque mémoire tampon de transaction placée sur le réseau.

Par exemple, si la taille de mémoire tampon de transaction est de 32 Ko et la taille de la mémoire tampon DataBlk de l'application est de 31 Ko, alors chaque mémoire tampon DataBlk de l'application tient dans une mémoire tampon de communications et peut être vidée immédiatement. Cependant, si la mémoire tampon DataBlk de l'application est de 32 Ko exactement, et dans la mesure où l'API ajoute 4 octets par mémoire tampon de transaction, deux vidages sont requis : un de 32 Ko et un de 4 octets. De plus, si vous définissez l'option tcpnodelay sur no, le vidage des 4 octets peut prendre jusqu'à 200 millisecondes.