LinkedInTwitterFacebook

4 bonnes raisons de passer à TSM 7.1 rapidement

Tivoli Storage Manager 7.1 a été annoncé le 29 octobre 2013 et est disponible au téléchargement depuis le 13 décembre 2013.

De nombreuses nouveautés ont été apportées au niveau du serveur TSM 7.1. Elles répondent aux exigences de plus en plus fortes en capacité de traitement et aussi aux nouveaux besoins des organisations informatiques.

TSM 7.1 : Performances accrues

Des améliorations de performance significative ont été apportées par la version TSM 7.1 ainsi que le dernier niveau de TSM 6.3 (6.3.4.2). Ces améliorations portent sur le processus de déduplication serveur ainsi que les processus associés (réclamation, expiration, déréférencement).

Le graphique ci-dessous est relativement parlant. Il concerne une architecture TSM équipée de disques "entrée de gamme" pour laquelle on peut observer que les process en question se déroulent 7 fois plus rapidement !

Vous utilisez la déduplication TSM ? Nous vous invitons vivement à migrer sans plus attendre.

Performances

Réplication des nodes

TSM 7.1 étend les capacités de reprise disponibles depuis la version 6.3 et apporte une nouvelle dimension à la fonction de bascule rapide offerte en cas de plan de secours.

Cette fonction repose sur la mise en œuvre des fonctions de réplication de "node" régulières permettant de répliquer tout ou partie des données des clients TSM d’un site A (source) vers un serveur TSM d’un site B (secours).

Le schéma qui suit illustre les grandes étapes de déroulement de cette nouvelle fonction :

 Réplication des nodes

Avant qu’un sinistre survienne sur le site A et le serveur TSM « A » correspondant:

1 - Le serveur A envoie les informations de connexion "failover" au client, qui stocke ces informations localement
2 - Le serveur A réplique les données du node et les metadatas vers le serveur B secondaire

Suite à une panne majeure sur le site A (situation de "Failover"):

3 - Le serveur A devient indisponible
4 - En se basant sur les informations de connexion et les politiques de failover serveur, le client TSM est automatiquement redirigé vers le serveur B pour les opérations de restauration

Lorsque le site A redevient disponible (situation de "Failback"):

5 - Le serveur A redevient disponible, les opérations client sont dirigées de nouveau vers le serveur A

Interface graphique : TSM Operation Center 7.1 (OC)

TSM 7.1 dispose d'une toute nouvelle interface graphique beaucoup plus moderne et intuitive.
Pour plus d'informations vous pouvez consulter l'article que nous avons déjà consacré au sujet.

Cliquez pour accéder à l'article consacré à TSM OC 7.1
Cliquez pour accéder à l'article consacré à TSM OC 7.1

 

TSM for Virtual Environment 7.1 : Restauration instantanée d'une VM complète

Grâce à un simple client TSM il est possibile d'effectuer des sauvegardes et des restaurations de type "FULL VM" de vos  environnements virtuels VMware. L'agent optionnel TSM for Virtual Environmement apporte en plus la possibilité d'effectuer des sauvegardes incrémentales allant jusqu'au niveau bloc via la fonction de Changed Block Tracking (CBT).

Dans sa version 7.1, cet agent dispose d'une nouvelle interface graphique et offre à présent l'accès et la restauration instantanée d'une VM complète.

Les principes de fonctionnement de cette nouvelle fonction sont les suivants :

  • le serveur TSM se comporte comme un « datastore » virtuel pour permettre « l’Instant Access » aux VMs
  • cette fonction est déclenchée par l’interface graphique du « plugin » Data Protection pour VMware
  • les VMs sont disponibles immédiatement dans vSphere
  • fonctionne de manière transparente à l’utilisateur, comme si la VM était dans le Datastore
  • l’utilisateur peut accéder à la machine pour des vérifications ou des opérations de restauration
  • des transactions d’écriture peuvent être réalisées immédiatement
  • en complément, un utilisateur peut initialiser une restauration vers vSphere selon le déroulement suivant :

       1 - Identification des disques virtuels de la VM et exposition de ces disques comme cibles iSCSI

       2 - L’utilisateur peut accéder à la machine pour vérifier une sauvegarde

      • les opérations de lecture sont dirigées vers le serveur TSM “virtual datastore”
      • les opérations d’écritures sont mises en cache (non-persistantes)

       3 - L’utilisateur peut, en option, spécifier la restauration (Recovery) vers le datastore vSphere:

      • initialisation de VMware Storage vMotion
      • les opérations d’écriture sont en cache et persistantes

Cette nouvelle fonction apporte un réel bénéfice pour la restauration rapide de VMs complètes et la capacité de test rapide d’une VM restaurée.

TSM for VE 7.1

 Vous souhaitez obtenir plus d'informations sur TSM 7.1.1, tester ou mettre en place cette solution ? Contactez-nous