November 20, 2009

Quel est le bon dimensionnement ?

Il m’arrive souvent de devoir justifier un dimensionnement des capacités de stockage
que je propose lors de projet. Cela fait évidemment du sens.

La question qui revient sans cesse : mais comment avez-vous fait pour calculer la capacité

utile que je vais pourvoir stocker ?

 

Je me fais donc ici l’écho de mes expériences et des réponses que je donne à chaque fois,

surtout sur ce qu’il ne faut pas faire.

 

Car, le dimensionnement est le fruit d’une étude qui est propre à chaque projet, et ce
blog ne se veut absolument pas comme meilleure pratique NetApp.

Le seul outil qui prévaut pour les dimensionnements projet est SYNERGY. Outil qui est utilisé
par tous les consultants NetApp et partenaires certifiés.

 

Je tiens à préciser que le dimensionnement d’un système NetApp doit aussi tenir compte des
performances demandées. SYNERGY intègre également les outils adéquats pour effectuer
ce travail.

 

Avant de donner plus de détails, il y a un point qui me tient à cœur : qu’est ce que le stockage
utile ?

La seule définition qui me semble convenir, est que le stockage utile représente la quantité
d’informations qu’il aura été possible d’enregistrer sur un espace défini.

La mesure logique se fait donc à postériori, car les hypothèses à priori, sont tellement fonction
de paramètres incontrôlables, qu’il est impossible d’être précis.

Si j’y ajoute les technologies telles la déduplication, la compression (ONTAP 8), le provisionnement fin, le clonage fin, le vol autogrow, le snapshot autodelete (comme indiquer dans une analyse IDC), et autres, je ne fais que compliquer la mesure.

 

Bref, je vais donc faire abstraction de ces technologies, pour donner quelques guides à un dimensionnement en capacité utile à la vue du système de stockage. Ce stockage utile représente soit le plus gros espace de stockage NAS envisageable, soit la plus grosse LUN (ou RAW device) qu’il soit possible de créer.

 

Certaines règles n’ont plus cours depuis longtemps :

-   Il faut que l’agrégat ne soit pas rempli à plus de 85%

-   Il faut un snapshot d’agrégat d’au-moins 5%

-   Il faut un snapshot reserve d’au-moins 20%

-   Il faut un fractionnal reserve de 100%

-   Un RAID Group de disques FC/SAS ne doit pas dépasser 16 disques

 

Je vais préférer utiliser les règles suivantes :

-   Remplissage maximum d’un agrégat à 95% si un upgrade majeur est à envisager

-   Pas de réserve de snapshots spécifiques, sauf si une étude de rétention par application est
menée, ce qui est généralement le cas sur les projets que nous traitons

-   Pas de réserve de snapshot sur les agrégats sauf en cas de Metro Cluster (dans ce cas
cela permet une resynchronisation incrémentale en cas de bascule)

-   Pas de fractionnal reserve, même avec des LUN

-   Un RAID group défini au cas par cas suivant la capacité à obtenir, la taille des disques,
le nombre de disques

 

Il s’agit de règles de bon sens, qui évoluent avec le temps, avec les façons de faire, avec la technologie.

Par exemple, Windows 2008 propose maintenant la diminution à chaud des espaces NTFS.

Cette fonction très intéressante dans l’optimisation de son espace de stockage doit être maîtrisée pour
être bien utilisée. Aussi, dois-je la prendre en compte.

Autre exemple, le NTFS de Windows 2003 propose le hole punching, permettant de libérer les blocs
non utilisé. Est-ce que je peux utiliser cette technologie pour faire un dimensionnement
100% en mode provisionnement fin ?

 

Je le répète, la seule règle qui prévaut est celle qui est établi avec le seul outil certifié conforme : SYNERGY.

Une collaboration étroite entre consultants et clients est la règle de bonne conduite qui permet de
coller le mieux à la demande.

 

Alors bon dimensionnement.

 

Pour les FAS Bl@ggers: JFM

 

November 09, 2009

Oracle, NFS: mais pour quelles performances ?

Voilà un vaste sujet qui peut faire couler beaucoup d’encre !

Nous savons tous que NFS comme socle de transport pour Oracle apporte de nombreux avantages pour la gestion et la sécurisation des données. C’est pourquoi Oracle a jugé utile d’intégrer son propre client « Direct NFS » dans la dernière mouture du moteur de base, Oracle 11g.

Je ne vais donc pas revenir dessus. Néanmoins si cela est de votre intérêt premier je vous invite à revoir le nouveau document sur NetApp et Oracle, ainsi SnapManager Oracle 3.0, outil unique de valeur ajoutée.

 

J’aimerais mettre en exergue un point que nous devons souvent démystifier : les performances de Oracle sur NFS. Est-ce que NFS est plus rapide que Fibre Channel, par exemple ?

 

Et bien voici une étude très sérieuse sur ce sujet, que nous devons pour sa synthèse à notre meilleur expert en la matière, Nicolas Dajon.

Situons tout d’abord le périmètre de l’étude: il s’agit d’analyser les performances d’une base Oracle 11gR1 sur RedHat Enterprise Linux 5 U1.

 

Objet des tests :

o   Comparaison de protocoles sur un environnement Oracle 11g R1 sur RedHat Enterprise Linux 5 U1

o   Montrer le gain de performances entre les versions DataOntap 7.2.4 et 7.3

 

Conditions des tests :

o   Protocoles : NFS inclus dans le noyau Linux (kNFS), Oracle 11g Direct NFS (DNFS), iSCSI et FCP

o   Base OLTP (120 users / schéma de prise de commandes – 884GB)

o   Les métriques :

§  OETs (Order Entry Transactions) par minute

§  I/Os mixtes : 65% de lectures / 35% d’écritures

o   La charge est configurée pour saturer les hosts Linux pour le protocole kNFS
(pas la CPU mais les 128 slots RPC)

o   Charge constante et équivalente pour les autres protocoles

o   Aucune saturation du stockage lors des tests 

-   Serveur base de données

o   IBM 3650 , 2 Quad Core CPUs @ 3GHz, 18GB RAM

-   NetApp

o   NetApp FAS3070C

o   6 tiroirs de 144GB 15K RPM FC drives

 

Et voici les résultats :

 

Oet724 

Une conclusion simple s’impose: DNFS avec Oracle 11g : performances équivalentes à FCP avec la facilité de NFS.

 

Oetcpu724

 

Certes NFS consomme plus de CPU que Fibre Channel, mais tellement peu que cela ne vaut certainement la peine de considérer cette option.

 

Si maintenant nous comparons ONTAP 7.2.4 et ONTAP 7.3 nous pouvons voir un gain significatif :

 

Oet72473 
 
 

Et les ratios de consommation CPU restent équivalents :

 

Oetcpu724X73 

En synthèse :

¡  Tous les protocoles testés produisent des résultats très satisfaisants

  NFS -  48300 OETs par minute en DOT 7.3

  FCP - 68500 OETs par minute en DOT 7.3

  DNFS - 67300 OETs par minute en DOT 7.3

¡  Performances accrues avec DataOntap 7.3

  Augmentation du nombre de transactions (OETs)

  Diminution de la latence I/O 

 

ONTAP 7.3 propose donc une évolution très intéressante des performances, notamment
pour les systèmes quadri-cœurs.

Sa version 7.3.2 quasi GD devrait pouvoir faire bénéficier à nos clients les plus exigeants
de ses améliorations tant attendues.

 

Alors est-ce que le mythe entretenu des performances NFS doit continuer à exister ?

Je vous laisse juge.

 

Pour les FAS Bl@ggers: JFM

October 19, 2009

Et si ma réplication pouvait me garantir mon temps de reprise ?

La mise en place de plans de reprise ou de plans de continuité d’activité est désormais monnaie courante chez tous nos clients. Les problématiques de RPO, RTO sont bien évidemment abordées, avec une demande croissante pour des valeurs proches de 0.

Néanmoins, un paramètre fondamental me semble manquer dans les discussions : la consistance.

 

Construire une infrastructure proposant un RPO de 0 implique certainement la mise en place d’un mode de réplication synchrone. Mais comme chacun le sait, ce mode ne sécurise pas les données sur le site de secours lorsqu’une erreur est commise sur le site primaire. L’erreur se propage.

Si je prends l’exemple d’un arrêt électrique brutal, alors les données sur le site de secours ne présentent aucune consistance applicative, et le mode de redémarrage proposé aux services de secours n’est ni plus ni moins qu’un mode que je vais caractérisé de mode « panique » qui nécessite une vérification d’intégrité.

Cette opération peut prendre longtemps, sans qu’il soit possible d’en prévoir la durée.

Alors même si la donnée est synchrone, garantissant un RPO de 0, le temps de redémarrage n’en demeure pas moins incontrôlé, avec un RTO variable.

 

Alors ne vaut-il pas mieux avoir un RPO plus grand, mais être capable de garantir le temps de reprise des services applicatifs ?

 

C’est ce que propose NetApp avec son mode asynchrone si prisé, en plus de la réplication synchrone.

SnapMirrorest d’ailleurs reconnu par le marché pour ses qualités.

Je vous conseille cette analyse de IDC :

 

Idcreplication

 

Avoir le choix est important dans la conception des architectures, afin que chacun puisse implémenter une solution qui colle à ses besoins.

SnapMirror propose un fonctionnement basé sur les fameux snapshots de NetApp, ce qui permet un processus unique de réplication en mode blocs de disques incrémental bi-directionnel.

Une réplication asynchrone, à la NetApp, n’est pas un simple décalage dans le temps entre site primaire et site secondaire, mais vraiment un moyen unique de garantir le redémarrage.

 

Le processus de réplication asynchrone, qui peut avoir lieu jusque toutes les minutes se déroule en plusieurs phases :

-   Sur le site primaire, un snapshot est généré. Il est bien évident que les moyens de gestion de la consistance en local sont mis en œuvre, grâce notamment à des nos outils SnapDrive et SnapManager.

-   Une fois le snapshot généré, le delta de blocs de disques, issus de la comparaison avec la phase précédente est transmis, recréant ainsi, sur le stockage secondaire, une image parfaitement stable.

En cas de reprise sur ce site de secours, il n’est pas nécessaire de s’inquiéter de l’état des données, ni de lancer des processus de vérification d’intégrité : les données sont consistantes de par construction.

Le redémarrage des serveurs et des applications est prédictif assurant un RTO proche de 0.

 

J’ajoute à cela le fait que SnapMirror propose en standard :

-   La compression des données à la volée,

-   Le support de la déduplication, ce qui permet de ne transmettre que les blocs modifiés unitairement,

-   Le contrôle dynamique de la bande passante,

-   Un retour arrière incrémental, sauf en cas de dégât complet sur le site primaire nécessitant une resynchronisation
complète,

-   Une intégration avec les familles d’outil SnapManager.

 

Que de temps gagné, surtout à un moment où chaque minute gagnée est génératrice d’économies !

 

Le choix est entre vos mains.

 

Bonnes réplications.

 

Pour les FAS Bl@ggers: JFM

 

September 30, 2009

Cache de données : NetApp aurait il raison ?

Je n’en sais rien et c’est l’avenir qui nous le dira, mais lorsque j’ai vu cet article je n’ai pu m’empêcher de le penser.

La Startup Dataram vient d’annoncer une « appliance », qui se met dans le SAN entre les serveurs et la baie de stockage pour « cacher » les données de celle-ci afin d’améliorer les performances du stockage (une sorte de WAFS pour le SAN).

NetApp est aujourd’hui le seul acteur du marché du stockage à mettre en avant ce type de technologies et à en expliquer les bénéfices. Vous remarquerez que les points de vue convergent : “Melillo has also tested EMC Clariion arrays with SSDs, and found it a way to increase performance. "But you have to assign the application to the drive," he said. "With Dataram, you can run all traffic through the appliance, or filter specific applications.””. C’est exactement l’un des avantages des modules PAM et PAM II (zéro administration) !

 

D’après cet article, le boitier de la société Dataram e été testé avec succès sur des baies EMC² et HP : “Scott Hansen, sales manager for enterprise solutions for the VAR, said it has been testing the appliance with EMC Clariion and HP EVA arrays, and has seen a huge performance improvement, especially with the EVA, which is an older architecture.”.

Cette technologie est donc vraiment intéressante (je ne vous dirais vraiment pas le contraire), mais dans la forme qui nous est présentée ici, elle souffre malgré tout, je trouve,  de quelques handicaps :

  • Comme tout élément introduit dans le SAN sur le chemin de données (In-Band) , la question se pose de la disponibilité (assurée semble t-il, mais ?)
  • Comme toujours dans les environnements SAN, quid des matrices de compatibilité, à quelle matrice se référer ? cette solution est elle validée par les fournisseurs de stockage ? qui assure le support ?
  • Si vous souhaitez en plus virtualiser votre stockage SAN (ce qui est une tendance lourde), il faudra dans nombre de cas rajouter d’autres boîtiers (devant ? derrière l’appliance Dataram ?) quid de la "scalabilité" ?
  • Cette fonction est dans certains cas et selon les informations produits déjà assurée par des boitiers de virtualisation. Est-ce aussi, plus efficace ?
  • Que fait-on avec le plus gros de la volumétrie dans les Data Center : les données non structurées accédées généralement en NAS ?
  • Quid de iSCSI ou de FCoE ? 

Cette technologie intéressante est dors-et-déjà disponible chez NetApp, elle s’appelle V-Series (plus PAM II) et elle lève tous les handicaps soulevés ci-dessus :

  • Haute disponibilité mesurée supérieure 99,999%,
  • Virtualisation SAN, mais aussi iSCSI et NAS intégrée
  • Matrice de compatibilité et suport ? NetApp !
  • Gains de performance spectaculaire par l’utilisation de modules PAM II

Vous souhaitez augmenter les performances de vos anciennes baies tout en virtualisant ? pourquoi pas un V-Series.

pour les FAS Bl@ggers: BP

September 29, 2009

Le cumul n’est pas à la mode en politique, mais il doit le devenir dans les Data Center !

Oracle met en avant, avec l’annonce de la deuxième release de la version 11g des économies plus que substantielles avec entre autres, une réduction des coûts de stockage d’un facteur 12 !

Pour obtenir de tels gains, il faut envisager trois éléments fondamentaux:

  • En tout premier lieu, consolider l’ensemble des serveurs de bases de données sur une architecture RAC,
  • Ensuite, consolider les différents ilots de stockage en utilisant ASM,
  • Enfin, mettre en œuvre la compression au niveau de la base de données.

Oracle est il maintenant devenu un concurrent de NetApp, parce que la nouvelle version d’ASM, avec ACFS apporte des fonctionnalités de Snapshots, ou bien parce que Oracle prétend diviser l’espace de stockage par 12 ?

ABSOLUMENT PAS !

En premier lieu, Oracle et NetApp ont le même objectif : apporter à nos clients des solutions qui permettent de diminuer le coût des infrastructures, d’améliorer l’efficacité du Data Center et plus spécifiquement (en ce qui nous concerne) du stockage. Dans ce domaine, les technologies d’Oracle et de NetApp ne sont absolument pas concurrentes, mais totalement complémentaires.

il faut CUMULER !

Il faut cumuler :

  • Provisionnement fin (NetApp),
  • Clones virtuels (NetApp) pour les environnements de test, développement, qualification, …
  • Eventuellement la déduplication (NetApp)
  • Compression (Oracle)

Et tout cela sur une plate-forme de stockage consolidée par ASM (Oracle) sur un système de stockage multi-protocoles (NetApp vous offre le choix d’utiliser ASM, quelque soit le protocole de stockage en réseau : FCP, iSCSI et même NFS) . Attention ici, si vous voulez vraiment être efficace, laissez la baie NetApp gérer la sécurité (RAID-6), parce que sinon, vous allez doubler (two-way redundancy) ou tripler (three-way redundancy) la volumétrie, ce qui, vous en conviendrez, n’est pas très efficace.

 

En second lieu, quid de la fameuse fonctionnalité de Snapshots ?

Une des grosses nouveautés d’ASM 11gR2 est le tout nouveau système de fichiers ACFS (ASM Cluster File System), permettant de confier à Oracle, le stockage non seulement des bases de données mais aussi de tout autre type de données !

Certes, ACFS offre la fonctionnalité de Snapshots, mais :

  • ACFS n'héberge pas les fichiers des bases de données (voir graphique ci-dessous)
  • En utilisant la technologie Copy On Write (« ACFS snapshot utilizes a Copy-On-Write (COW) technology … Up to 63 snapshot views are supported with this release).

image

Là encore: il faut CUMULER !

Il faut cumuler :

  • Snapshots des bases de données sans impact sur les performances (NetApp)
  • Snapshots des fichiers hébergés par ACFS, tels que les binaires Oracle, les binaires applicatifs, les fichiers de type LOB ou dérivés (Oracle)
  • Snapshots des autres environnements hébergés par la baie, tels que la messagerie Exchange ou Lotus, le service de fichiers (NetApp)

Et tant qu’à consolider, consolidons les environnements Oracle (et pas seulement) en utilisant les meilleures des technologies à disposition:

  • Tous les environnements de production et pré-production consolidées avec RAC
  • Les environnements de test, de développement, d'intégration, etc ... dans des machines virtuelles (et pourquoi pas Oracle VM)

 

Pour les FAS Bl@ggers: BP

Ai-je besoin d'un SAN pour mon infrastructure virtualisée ?

Je me fais l’écho ici de mon expérience de projets autour des technologies de virtualisation.
Je vais aborder un sujet qui m’est cher, à savoir le dimensionnement lié aux performances.  

Il n’est pas rare que les demandes autour des projets de virtualisation serveurs aboutissent
à la mise en œuvre d’une infrastructure SAN Fibre Channel.
Si vous demandez : « pourquoi un SAN ? »
Je parie que la réponse sera :  « parce que nous avons besoin de performance !»  

Mais ce SAN est-il réellement obligatoire ?

Je ne le pense pas, et je propose de regarder ensemble pourquoi, pour une très vaste majorité de projets, ce n’est pas nécessaire.  

Pourquoi consolider des serveurs ?
Parce qu’en, les serveurs sont fortement sous-utilisés.
Et bien il en est de même pour les performances en entrées / sorties vers le stockage.  
Ai-je besoin d'un SAN pour mon infrastructure virtualisée ?

Prenons un exemple simple.
Si je considère 100 machines physiques avec 4 disques internes, ce qui représentent une bonne image
d’un parc client « moyen ».

Si j’utilise les hypothèses suivantes :

  • Disques à 10 krpm, soit 100 IOPS au maximum par axe
  • Disques en RAID 5, soit 3 disques utiles par serveur
  • Disques utilisés à 20%, soit 20 IOPS par disques.  

Une équation simple me conduit à dire que : 100 * 3 * 20 = 6000 IOPS sont générées.
En multipliant le nombre d’IOs par 8Ko, taille moyenne des entrées/sorties constaté, nous obtenons
le chiffre de … 46,8 MegaOctets par seconde, soit moins de la moitié de ce qu’est capable de gérer un simple réseau GbE.

Ce que je peux constater sur les projets que j’ai pu voir, est que pour couvrir un spectre
de 20 à plus de 200 VMs, le SAN Fibre Channel n’est pas nécessaire.  

Alors la bonne nouvelle est, il me semble, que le client, pour une fois, a le choix de son mode de transport
de données.  

Pour les FAS Bl@ggers, JFM

September 21, 2009

De la consistance des machines virtuelles sous VMware

NetApp prône depuis ses débuts la mise en place la prise de snapshotsTM réguliers afin de mettre en place des politiques de sécurisation des données plus simples et plus efficaces. Avec la possibilité de faire jusque 255 snapshots par volume et plus de 100,000 par système, SANS que cela ne dégrade les performances, il y a de quoi se demander pourquoi ne pas le faire.

Mais il ne faut pas oublier dans ce scénario, que si une donnée est sécurisée, ce n’est que pour qu’elle puisse être restituée. Cette démarche est extrêmement similaire à la mise en place d’une procédure de sauvegarde, à savoir que si la donnée sauvegardée n’est pas vérifiée alors il y a très peu de chances de pouvoir la restituer dans un temps déterminé, voir de la restituer tout simplement.

Je parle ici de consistance, et je vous en donne la définition.
La consistance est déterminée par un état connu et stable depuis lequel il est possible de redémarrer de façon déterministe. Cela s’applique à  un système de fichiers, une base de données, ou tout autre entité applicative. 

Dans les environnements virtualisés, la sauvegarde des machines virtuelles (VM) est un vrai projet d’architecture. Je pars du principe qu’une VM ne peut être stoppée, même pour effectuer cette opération de sécurisation. La génération du point de consistance est donc une opération à maîtriser.

Par défaut, une prise d’image à la volée détermine un état dit « crash consistent ». Il équivaut à un arrêt électrique brutal.  de travailler sur un RTO défini.    

Pour pallier à ce problème, VMware propose depuis la version de son ESX 3.5 update2, un point d’ancrage VSS.

Cette technique de prise d’images instantanées, définie par Microsoft, permet de générer des points de consistance à toute entité capable de la traiter. Des applications comme NTFS sous Windows 2003, Exchange, SQL, et Oracle 11i supportent ce mode, et sur réception d’un ordre VSS, l’application met en place ses mécanismes de création d’états stables. Pour que cela soit orchestré depuis VMware, il faut que les VMware Tools soient installés.
Ainsi, lorsqu'un snapshot ESX est demandé, les applications listées ci-dessus, et hébergées dans des VMs, bénéficient de la génération d’un état consistant, qui permet une restitution rapide.

Pour les autres, nous revenons à l’état « crash consistent » défini plus haut.  


SnapManager for Virtual Infrastructure (SMVI) utilise ces mécanismes pour coupler consistance applicative et snapshots
NetApp. Ainsi, combiné avec SnapRestore, les plates-formes NetApp sont les seules à proposer, QUELQUE SOIT le protocole, une mécanique de sauvegarde ET de restauration instantanées pour les environnements virtualisés.  
 

Je ne saurais que trop vous engager à lire ce post sur les services Cloud de Amazon :
http://aws.amazon.com/ec2/faqs/#Will_I_be_able_to_access_my_snapshots_using_the_regular_Amazon_S3_APIs  
  « Q: Do volumes need to be un-mounted in order to take a snapshot? Does the snapshot need to complete before the volume can be used again? No, snapshots can be done in real time while the volume is attached and in use.”    

Ainsi que notre guide des meilleures pratiques le TR-3428.  
 

En résumé :
  • La consistance VMware est assurée par le snapshot VMware piloté par SMVI
  • La consistance de l’OS de la VM est de type crash consistent
  • La consistance applicative est assurée par les composants VSS si celui-ci est disponible  

Alors à vos snapshots ! 
 

Pour les FAS Bl@ggers : JFM  

September 17, 2009

La chasse au gaspi Energétique !

Hier, en parcourant les nouvelles du monde de l’IT, je suis tombé sur un article intitulé « Les data centers pourraient moins consommer ».

La vision de NetApp sur ce sujet est clairement décrite dans l’article « Strategy for Data Center Power Efficiency ». Vous trouverez aussi des détails très intéressants  dans cet article, tel que l’utilisation de l’air extérieur, le réaménagement des allées en catégories froides et chaudes avec une gestion allée par allée de la température.

La mise en œuvre de ces principes permet aux Data Centers de NetApp d’obtenir d‘ores et déjà un PUE de 1,35 et d’être reconnue comme une des entreprises les plus innovantes dans ce domaine. 

Mais même sans tous ces aménagements, relativement simples à mettre en œuvre dans le design et la construction de nouveaux centres, n’y a-t-il pas moyen de faire quelque chose pour les salles existantes ?

Le doublement de la consommation énergétique estimée d’ici à 2011 est certes du à  la montée en puissance des microprocesseurs, comme il est précisé dans cet article, mais surtout à la croissance « sans fin » des données non structurées, comme le précise IDC, qui estime la croissance annuelle à plus de 90% par an jusqu’en 2012 !

Et dans ce domaine, la meilleure des réponses repose, sans conteste, sur une efficacité du stockage exemplaire.

Nos solutions permettent concrètement de réaliser des économies énergétiques immédiates, dans vos Data Centers actuels.

Un exemple parmi d’autres ? Celui de CISCO qui a diminué de 67% les consommations d’espace et d’énergie en utilisant au mieux nos technologies !

Pour les FAS Bl@ggers, BP.

September 10, 2009

NetApp au MTC (Microsoft Technology Center) de Paris

Le lancement du nouveau MTC de Paris a été l’opportunité pour NetApp de resserrer son partenariat avec Microsoft, via la mise en place d’une nouvelle baie NetApp.

Les données de production interne du MTC de Paris (fichiers et VMs, hors benchmarks) étaient déjà hébergées sur une première baie NetApp depuis 2008. Ceci permis au MTC de bénéficier des avantages du Storage Efficiency de NetApp en environnement Hyper-V. Résultat : 50% de gain d’espace en activant deduplication et thin provisioning NetApp.  Exactement ce que prédit le programme NetApp Guarantee !

La seconde baie NetApp récemment installée, bénéficie des dernières avancées de NetApp (cartes d’accélération de performance PAM, connexion 10 Gigabit Ethernet). Elle est destinée à la réalisation de benchmarks pour Hyper-V, SharePoint, SQL Server, Exchange en environnement SAN FC ou iSCSI.

Si vous désirez mieux comprendre, cadrer, voire prototyper les gains conjugués des technologies Microsoft et NetApp, une visite au MTC s’impose !

Sinon, “stay tuned“ comme on dit aux US  - restez branchés - sur ce blog car Microsoft et NetApp vont chacun faire des annonces importantes à la fin du mois ; mais nous n’en dirons pas plus pour le moment... Nous aurons bien entendu la joie de vous commenter ces informations prochainement sur ce blog.

Pour les FAS Bl@ggers : CVA avec Jérôme F.

September 09, 2009

NetApp, numero 1 de la replication logicielle

Cela fait déjà plusieurs années que je le prédisais (par exemple ci-dessous en juin 2008): NetApp va finir par dépasser le numéro un sur le marché mondial de la réplication logicielle.

replication

C’est chose faite au trimestre dernier. :)

D’après la dernière étude de marché d’IDC présentée dans cette annonce, NetApp est en effet passé en tête sur le segment de marché « Replication Software », l’un des huit sous-segments du marché « Storage Software » comptant pour 1/5 du total, à la fois sur le dernier trimestre et sur l’année 2009, avec une croissance de 20% par rapport au trimestre précédent.

Pourquoi ?

Parce que les solutions NetApp de réplication (SnapMirror pour le PRA, SnapVault pour la sauvegarde incrémentale sur disque, et MetroCluster pour la haute disponibilité et la continuité de l’activité) sont extrêmement pertinentes, tant du point de vue technique qu’économique.
Chacune de ces solutions fonctionne quel que soit le protocole ou le mode d’accès (NAS ou SAN) utilisé.
Chacune de ces solutions bénéficie des fonctionnalités avancées de gestion de données de NetApp (comme l’allocation virtuelle ou la déduplication, qui permettent – entre autres - de réduire la bande passante nécessaire à la réplication inter-sites).

Seconde information à retenir de cette annonce d’IDC : NetApp continue de gagner des parts de marché malgré le contexte actuel. On remarque en effet dans cette étude que le marché des logiciels de stockage, tous segments confondus a baissé de 9.8% au deuxième trimestre 2009 par rapport à l’année précédente, et que NetApp est le seul fournisseur à avoir eu une croissance positive (+0.8%) ; tous les autres acteurs majeurs sont en nette baisse (de -11.2 à -18.2%).

Clairement, le marché comprend que les solutions de stockage et de gestion de données de NetApp apportent de la valeur, particulièrement dans les périodes où il est indispensable de faire des économies !

Pour les FAS Bl@ggers : CVA

© NetApp, Inc.  |  "Safe Harbor" Statement  |  Privacy Policy