Monday, September 28, 2009

Bycast y sera aussi

Bycast (www.bycast.com), l'une des belles offres CAS du marché, sera présent à SNW Phoenix et c'est à remarquer tant la société est souvent absente de ce type de manifestation mais procède depuis quelques mois à une campagne de visibilité technologique plus importante. Invitée en Janvier dernier au stream Cloud du SNIA Symposium, Bycast s'est depuis impliquée fortement avec David Slik, son architecte technologique et co-fondateur, dans les travaux Cloud de la SNIA notamment le TWG, le CDMI (Cloud Data Management Interface) et la future Initiative Cloud Storage (bientôt accessible sur www.snia.org/forums/csi ). Si vous ne connaissez pas Bycast, faites-le vite, la solution est vraiment très bonne et David, un vrai talent.
Share:

Thursday, September 24, 2009

Avere sera à Phoenix pour SNW

Avere Systems (www.averesys.com) sera sponsor gold à SNW Phoenix en Octobre. La société vient de lever 15M$ pour soutenir son développement. Ce sera l'occasion pour la startup de dévoiler ses produits et pour son CEO, Ronald Bianchini, ancien patron de Spinnaker Networks acquis par NetApp début 2004 pour 300M$, d'évoquer le tiering SSD, HDD voire Cloud au coeur de son offre. L'idée d'Avere Systems est de proposer un modèle évolutif pour le monde NAS sans avoir besoin d'ajouter des noeuds capacitifs mais plutôt des frontaux de traitements. Enfin une solution semble-t-il massivement évolutive (en traitement à capacité constante) disponible commercialement. Ca ressemble à d'autres idées sur le marché comme Nimble Storage ou au noeud IQ Accelerator d'Isilon. ... pour la partie fichier. On en rediscutera... car d'autres s'annoncent déjà.
Share:

Monday, September 21, 2009

Craig Harmer nous rejoint, fantastique !!

Lors de la prochaine conférence SNW en Octobre à Phoenix, Craig Harmer, un des rares derniers dinosaures Veritas ayant participé à la première vraie aventure avec Tolerant Software qui est devenu Veritas Software, fera parti de notre stream de tutoriaux sur les systèmes de fichiers. Distinguished engineer chez Veritas et aujourd'hui chez Symantec, il couvrira, après ma session, la partie système de fichiers orientés objets, un sujet et une personne à ne pas manquer. Vraiment un super bon sur le sujet, un vrai expert et un des pères de VxFS, allez disons-le, parmi les meilleurs systèmes de fichiers de l'histoire surtout si nous le remettons à l'époque de sa sortie, en 90-91, et toutes les innovations associées comme le snapshot, la défragmentation et la modification (agrandissement ou réduction) de taille du file system à chaud.

Le stream File Systems & File Management se résume aux sessions suivantes:
  • The File System Evolution par Christian Bandulet, Princpal Engineer, Sun
  • Find and Select the Right File Storage for your Applications par Philippe Nicolas, CTO, KerStor,
  • Object-based File Systems: an Overview par Craig Harmer, Distinguished Engineer, Symantec et
  • Global Namespace for Summer par Matthew Geddes, CIFS Engineer, Nimble Storage.
Venez tôt, la salle va être pleine.
Share:

Saturday, September 19, 2009

Le Marché Soft et NAS

IDC (www.idc.com) vient de publier sa traditionnelle revue de l'état du marché du stockage et notamment pour la partie Soft et NAS. Pour la partie NAS, c'est le moyen gamme - entre 15000 et 50000$ - qui progresse et tire le marché avec 20,7% de croissance mais le marché global du disque réseau, iSCSI intégré, recule de 15,3% à 3,2Mds$. Globalement, le segment du NAS a reculé de 6,8% avec EMC toujours dominateur avec 38,7% et NetApp second avec 26,1. A eux 2, il font donc près de 65% !!
Côté soft, les ventes reculent de près de 10% par rapport à la même période il y 12 mois à 2,8Mds$. NetApp progesse bien avec un push de ses solutions de réplication, et la protection globalement se porte bien aussi avec une progression de 3%, même si elle n'a plus rien à voir avec celle que nous connaissions. Les segmentations des analystes sont vraiment pénibles. EMC est bien sûr #1 avec 638M$ et 22,4% de parts de marché (PDM), Symantec #2 avec 524M$ et 18,5% de PDM, IBM #3 avec 328%, près de la moitié d'EMC, et 11,5% de PDM, NetApp #4 avec 241M$ et 8,5% de PDM, moins de la moitié de Symantec, et CA résiste avec 116M$ et 4,1% de PDM.
Share:

Thursday, September 17, 2009

Retour sur la SNIA SDC

Très bon cru encore pour cette conférence Développeur SNIA. Les 2 compères ou plutôt prêcheurs SUN Jeff Bonwick et Bill Moore nous ont offert encore 3 heures de ZFS et des ses fonctionnalités avancées. Sinon plusieurs sessions Microsoft, Symantec ou NetApp; Le keynote de Garth Gibson, CTO de Panasas, fut assez décevant et le gag fut l'intervention de Benjamin Tso, CTO de La Linux Foundation, qui a présenté ext4 qui aura enfin une allocation par extent, on avait ça chez SGI en 93 avec efs. Vraiment, on attendait mieux et puis on a déjà XFS, ZFS et quelques autres ça va non ? Une table-ronde Cloud attendue et de bonne facture avec notamment le CEO de BackBlaze qui est resté avec son CTO pour présenter leur POD. Ils ont bati des unités élémentaires 4U de 67To qui ne leur coûtent que 7867$ arrivant ainsi à presque le coût du To pour un disque consumer, le tout agrégé dans des racks et hosté chez 265 Main à SF. Un truc vraiment impressionnant à 5$/système/mois mais sans limite de capacité. A part ça, j'ai noté l'annonce SNIA à propos de NDMP et bien sûr l'initiative Cloud Storage Initiative (CSI) en avant-première ici, qui va être lancée à SNW en octobre prochain. C'est aussi le début de la revue publique pour CDMI (Cloud Data Mangement Interface) et la spécification est disponible ici. Et puis c'est toujours étonnant de voir quelques français rôder là-bas... comme nos amis d'Active-Circle.
Share:

Monday, September 14, 2009

Haystack chez Facebook

De passage dans la vallée, je me suis dit que c'était le bon moment pour couvrir ce sujet. Une remarque en passant qui va surprendre mais qui montre bien que l'identité Internet est la plus importante car la plus universelle. Nous associons tous la couleur bleue à FaceBook comme son site le propose associé à toutes les communications et supports marketing mais les logos du HQ à Palo Alto (anciens locaux d'Agilent) sont rouges. Mystère...
C'est officiel depuis quelques mois, FaceBook (www.facebook.com) fait évoluer son infrastructure pour la partie stockage photo et CDN associé et swappe les solutions NetApp et Akamai/Limelight coûteuses pour un système à base d'Haystack. FaceBook est le site #6 sur Internet employant 500 personnes dont 200 à l'engineering et 25 en infrastructure, c'est aussi l'un des premiers sites MySQL dans le monde (plus de 800 serveurs memcached pour plus de 28To de RAM !!), plus de 10 000 serveurs en exploitation et 6 000 bases de données en production. Ouha, ça pose la société...
FaceBook n'a absolument pas besoin de produits coûteux, mais de services logiciels intelligents autour de composants standards, pas chers et offrant en final une très bonne qualité de service c'est-à-dire de la performance constante qui ne se dégrade pas avec le volume de données ou d'utilisateurs.  Le driver est financier et lié à la performance du service, la société avance un gain de 50% en matériel donc en $ et pour le même budget, on peut donc faire 2 fois l'activité précédente. Chez FaceBook, une des métrics utilisée est le TCpP ou Total Cost per Photo. C'est radical et immédiat même si les efforts ont été importants car le développement est au petit oignon comme souvent. La configuration faisait même appel à des montages NFS, à des supers configurations NetApp mais la qualité du service ne suivait pas. On comprend le changement quand on sait qu'il faut stocker des milliards de photos, les servir dans des temps records opérant une quantité de meta-data gigantesque ralentissant le système et offrant une qualité de service globale insuffisante !! Historiquement, FaceBook avait opté pour une batterie de CDN mais l'approche est coûteuse et ne fait que décaler le problème qui devient visible plus tard avec les volumes incroyables et le nombre de requêtes. Encore une fois, les besoins sont au-delà des offres existantes et les utilisateurs sont contraints de bâtir leur propore solution. FaceBook stocke essentiellement 2 types de photos, celles liées au profile et celles liées aux dépôts utilisateurs (différentes des profiles). Pour chaque photo soumise, FaceBook génére 4 photos de taille différente. Les statistiques sont encore hallucinantes:
  • 220 000 000 de photos uploadées chaque semaine soit 25To supplémentaire sur la même période ou disons plus de 3To par jour !!
  • en forte charge, 550 000 images sont servies par seconde !!
  • 15 Milliards de photos sont actuellement stockées soit 60 000 000 000 images (x4) !!
  • plus de 200 000 000 d'utilisateurs !!
Voici quelques détails sur cette solution. Haystack est conçu autour de systèmes standards 2U embarquant 2 quad-core, 16 à 32Go de RAM, 256 à 512Mo de cache NVRAM et 12 disques SATA de 1To en RAID 6 offrant 10To en XFS. L'architecture est multi-niveaux bien sûr avec des serveurs http, des serveurs de cache (cachr) des serveurs de stockage photo, l'object store Haystack et le système de fichiers. Ces unités sont utilisables avec plusieurs niveaux d'encapsulation: object store Haystack posés sur des fichiers présents sur 1 seul système de fichier data par noeud. La surcouche évite les approches posées directement sur des systèmes de fichiers bloc ou à base d'extents engendrant trop de traffic, trop d'indirection et trop de meta-data. Ce type d'utilisation ne nécessite pas non plus d'être Posix compliant et on retrouve de plus en plus d'implémentations Fuse (File system in USEr mode). C'est marrant, comme la convergence d'idées est forte sur certains concepts, preuve que des conclusions identiques ont été trouvées comme l'unification ou agrégation de serveurs de stockage en DAS, la seule philosophie vraiment massivement évolutive, et ce que j'appelle le FiF (Files in Files), ces idées sont présentes dans nombre de solutions (suivez mon regard) avec la notion ici de bucket de 10Go qui stocke les photos elles-mêmes (la data) associé à 1Mo de meta-data pour chaque Go stocké avec la contrainte ou nécessité (cela dépend du côté où l'on se place) de maintenir en mémoire ces meta-data. La qualité de service provient aussi des éléments Cachr en frontal des unités de stockage à base d'Haystack. La volonté de s'affranchir si possible de coûteux CDN a été également une forte priorité, FaceBook s'appuyant sur 2 data-centers, un côté Ouest et un côte Est des Etats-Unis.

Pas d'inquiétude non plus concernant Hadoop, il reste utilisé pour la collecte massive de logs et les statistiques associés, j'y reviendrais avec le Memcached dans quelques semaines.
Share:

Thursday, September 10, 2009

Google dévoile GFS version 2

10 ans, le bel âge pour un lifting. Google (www.google.com | NASD:GOOG) a décidé de changer l'infrastructure de ses services et notamment celle de son stockage. Caffeine est le nom de code du projet qui couvre l'infrastructure de Search. Celle-ci doit s'appuyer sur la seconde génération de GFS - Google File System - utilisée en interne et propre à Google puisque celui-ci n'est pas disponible pour le monde extérieur quelque soit le mode et la version. Un très bon papier avait été publié par les Labs Google en 2003 à ce sujet et souvenez-vous, j'avais déjà couvert GFS en 2006 par un article assez détaillé. C'est aussi une technologie, les systèmes de fichiers distribués, que je couvre dans le tutorial SNIA Massively Scalable File Storage que je présenterai une nouvelle fois à la conférence SNW Europe fin Octobre à Francfort.
Lors de la genèse de GFS, Google a opté pour des choix apparaissant aujourd'hui stupide mais si on se remet dans le contexte, ces choix trouvent leur sens. Les objectifs de GFS étaient clairs, le besoin de faible latence n'était pas prioritaire mais que la volonté d'adresser les besoins de forte évolutivité, de forte abstraction matérielle et de disponibilité importante étaient au coeur du design. Malgré ces choix, GFS a largement contribué au succès de Google comme élément d'infrastructure supportant les applications maison au-delà des prévisions. Au départ, il a été désigné pour ne supporter que les applications de type batch comme le crawl web ou l'indexation, les applications Gmail et YouTube, développées ou acquises durant les 10 dernières années étant plus orientées temps-réel. GFS s'est montré moins "à l'aise" avec ce type de traitement même si le comportement d'une vidéo servi par YouTube est séquentiel en mode stream. GFS est une architecture à 3 niveaux avec le maître - master - dans le jargon Google, présent en un seul exemplaire, les serveurs secondaires - chunkservers - qui correspondent au serveurs de stockage contrôlés par le maître et répondent aux requêtes des clients, en nombre important. Une souche GFS est donc présente sur ces 3 composants de l'architecture pouvant à priori évoluer indépendemment, sauf le maître, unique. Le second choix fut l'éclatement des écritures avec un pas de 64Mo - le chunksize ou stripe unit - par chunkserver garantissant une bande passante importante, donc un débit global interessant, et une relative indépendance vis-à-vis du maître puisque moins de dialogue était nécessaire. Le but initial de GFS était de stocker les données du crawl web et de l'indexation donc en terme Google plutôt de gros fichiers mais pas adapté à Gmail par exemple. L'intégrité des données étant l'un des axes de design de GFS, le failover ou reprise de l'unique master était manuelle et pouvait engendre jusqu'à 1h d'arrêt réduit aujourd'hui à 10 secondes en mode automatique, ce qui est encore trop long car l'arrêt doit être invisible pour les applications et les utilisateurs. La performance de GFS est liée à la taille mémoire du master qui limite le nombre de fichiers traités pour les 3 types de Meta-Data qu'il stocke: nom de fichiers et chunk handle, correspondance fichiers vers chunks et donc chunkservers et l'adresse des réplicas des chunks. L'évolution de la volumétrie et du nombre de fichiers a été telle que les masters, sur des clusters différents, sont devenus des "trucs" énormes et fragiles. Le paradoxe est saisissant, pourquoi alors un seul master dans l'architecture qui représente un point de défaillance unique, que le bon sens ferait éviter à tout prix ? Ce seul master est aussi un goulot d'étranglement regroupant toutes les requêtes clients et contrôlant tous les serveurs secondaires. Les configurations Google ont évolué d'une cellule (= 1 GFS) par Data Center à plusieurs cellules (= n GFS) avec la possibilité d'asservir un chunkserver à plusieurs masters de GFS différents donc des espaces de stockage différents controlés par l'application ou par un jeu statique d'espace de nommage. GFSv2 introduit le concept de masters distribués, adressant immédiatement la disponibilité et la performance, avec un mode supportant des centaines de maîtres pouvant chacun supporter 100 millions de fichiers. Le boulot de synchronisation et de recouvrement doit être une sacrée galère... Le chunksize est de 64Mo avec GFS et de 1Mo avec la version 2. Comme indiqué ci-dessus, cette valeur correspond à la quantité de données ou segment d'un fichier affecté à 1 serveur de donné (chunkserver). Il demeure incroyable que Google ait pensé et décidé très tôt de partir sur un tel design avec un seul master tellement la lacune est énorme. Cette décision a quand même eu quelques impacts avec plusieurs arrêts de Gmail dont certains sont imputés à GFS et de son unique master. Il fallait réagir. On remarquera que Google aurait pu retenir Hadoop et contribuer à son évolution, mais cela aurait pu être le symbole d'une défaite technologique. Par contre, Il est incroyable que Microsoft centré sur la guerre des moteurs de recherche se ralit à l'Open Source avec Bing qui s'appuit sur Hadoop suite au rachat de PowerSet. Je couvrirai Hadoop dans les prochains jours.
En résumé:
  • GFS (1 master en mode failover, chunksize = 64Mo, philosophie: bande passante et intégrité de données)
  • GFSv2 (N masters distribués en disponibilité constante, chunksize = 1Mo, philosophie: plus temps-réel, plus réactif, totale intégrité de données et maintien des avantages de la v1)
Share:

Tuesday, September 08, 2009

Le retour du SRM ?

Rien à voir avec le SRM de VMware - Site Recovery Manager - mais bien avec les environnements de stockage et leur gestion, mais il existe un lien, nous y reviendrons. Cette utilisation du terme dans un autre contexte confirme bien la "disparation" ou le laisser vivre de ces solutions par le marché, au départ très prometteuses. Le Gartner a publié son dernier Magic Quadrant à propose des SRM (Storage Resource Manager) combinant les SAN Manager et les SRM tels que nous les comprenions au départ par leur couverture logique de l'environnement. Le SRM trouve son sens dans une conjoncture difficile et des volumes de stockage en forte croissance. Le SRM offrait la possibilité de comprendre son environnement au sens utilisation, d'éliminer les doublons de fichiers, de libérer de l'espace, de surveiller et bloquer les accès, d'imposer des quotas et de retarder les investissements... Le SRM n'avait pas décollé tout seul, le secteur pensait que le moteur pouvait être utilisé dans l'ILM mais ce dernier n'a jamais confirmait aussi ses promesses: le lien applicatif et business pour aligner l'outil informatique sur les besoins de l'activité de l'entreprise. Dans la course à l'efficacité et l'optimisation du stockage, le SRM trouve parfaitement sa place. Je me souviens de la présentation désastreuse d'Enrique Salem, CEO de Symantec, lors du dernier SNW à Orlando en Avril dernier, il est sacrément mauvais sur scène, qui martelait le message "Arrêter d'acheter du stockage !!". Il doit être bon ailleurs, c'est sûr... Avec les projets de Virtualisation Serveur, le SRM redevient utile puisque tout est masqué et finalement assez compliqué en dessous. On comprend la nécessité de retenir des solutions visant l'optimisation des environnements et pas seulement leur administration. Le SRM, historiquement segmenté en 2 groupes: physique et logique, retrouve un semblant d'utilité, ce qui laisse présager de rapprochements entre acteurs. Le groupe physique est couvert par les SAN Manager donc plutôt lié à l'infrastructure des réseaux de stockage, la topologie, l'inventaire des unités, le zoning, les LUN... et le second groupe, la partie logique, plutôt sur les compréhension des environnements utilisant les ressources physiques comme les taux d'occupation, les migrations de données, la création de règles de déplacement de fichiers inactifs par exemple. Le SRM a évolué de solutions plutôt lourdes à base d'agent à des solutions légères et fonctionnellement plus complètes. Mais le SRM, longtemps perçu comme un "Nice to have" avec des projets longs à implémenter, semble peut-être retrouver une certaine adhésion des utilisateurs. Je n'y crois pas, ce sont les vendeurs qui estiment utiles de telles solutions dans les environnements virtualisés, reste maintenant à les compléter pour tenir compte des fichiers de fichiers, l'adhésion utilisateurs viendra ensuite poussée par les fournisseurs.
Le Gartner révéle quelques chiffres pertinents. Le marché du SRM en 2008 représente un montant de 725M$ en progression de 7,25% et devrait décliner. C'est donc un vrai segment pour un tel montant mais il devrait tomber à 711M$ en 2013 donc finalement assez stable, plutôt conservateur donc solide sur 5 ans. Les leaders sont:
  1. EMC avec 464M$ soit 64% de parts de marché (PDM) affichant 23M$ de baisse par rapport à 2007.
  2. IBM avec 95M$ soit 13% de PDM gagnant 14M$ par rapport à 2007.
  3. HP avec 59M$ soit 8% de PDM progressant de 23M$ depuis 2007.
  4. NetApp avec 32M$ soit 4% de PDM en progrès de 27M$ vis-à-vis de 2007.
  5. Symantec avec 23M$ soit 3% de PDM gagnant aussi 1.7M$ depuis 2007.
  6. CA avec 11M$ soit 1% de PDM.
Ces 6 acteurs représentent 684M$ soit environ 95% du marché. Tous les autres acteurs, insignifiants, se partagent donc 41M$ soit 5%. Misère. Un groupe se distingue par la complétude de sa solution: CA, EMC, HDS, HP, IBM, NetApp et Symantec, HDS reste une surprise ici et le second groupe plutôt isolé et niche avec les SAN Manager où seul Brocade se fait remarquer avec Akorri, NTP et Northern Parklife. On peut venir coupler les acteurs de DPRM (Data Protection Resource Manager) avec Aptare, Agite, Bocada, ServerGraph (Rocket), Arkivio (Rocket), Tek-Tools et WysDM (EMC). Parmi les produits historiques et actuels, citons les acteurs suivants:
  • AppIQ s'est rapidement affirmé comme la rolls du secteur se faisant remarquer par HP qui l'a absorbé en 2005 pour devenir l'offre HP Storage Essentials.
  • Arkivio sauvée de la déroute par Rocket Software qui a repris les actifs logiciels de l'éditeur de Mountain View et qui continue à proposer la gamme. Rocket possède aussi ServerGraph, spécialiste du DPRM (Data Protection Resource Management).
  • Astrum éditeur américain acquis par EMC en 2003 pour la partie SRM logique voulant bâtir une vraie gamme SMB avec le SAN Manager acquis chez Prisa Networks quelques mois avant.
  • BMC avait lancé au début des années 2000 une initiative ACMS (Application-Centric Storage Management) qui a pris l'eau très rapidement, l'éditeur rendant les armes et vendant même Patrol Storage Manager à EMC en 2003.
  • CA martelait son offre BrightStor Storage Resource Manager qui avait le bon goût de supporter l'environnement Mainframe, ce qui l'a aidé à remporter des gros deals notamment chez nous.
  • CreekPath éditeur américain repris lui par Opsware lui-même absorbé par HP.
  • Crosswalk lui aussi américain est parti doucement sans faire de bruit. Il y avait 2 produits intéressants: iGrid, une solution NAS scale-out et ce fameux Storage Manager. On se souvient l'ancien CEO et fondateur de McData, Jack McDonnell, avait fondé aussi Crosswalk.
  • Data Global éditeur Allemand, à regarder.
  • EMC a fait une razzia avec Astrum et Prisa complétant son offre Entreprise ControlCenter.
  • HDS a très vite compris l'intérêt de contrôler l'infrastructure et sorti son offre HiCommand Storage Services Manager qui câche HP Storage Essential. HDS vient même de signer un accord avec Aptare.
  • HighGround a fait les frais de l'ambition de SUN en 2001.
  • IBM a aussi voulu une offre SRM forte avec la large gamme Tivoli qui a reçu les apports de TrelliSoft, acquis en 2002.
  • Monosphere avait tenté une approche SRM plutôt orienté provisioning et capacitif mais la niche s'est révélée trop petite, l'éditeur a été absorbé par Quest.
  • Northern Parklife se débat toujours.
  • NTP Software qui s'efforce de résister avec ses solutions orientées SRM logique pour Windows.
  • Onaro, éditeur Israélien, est passé chez NetApp début 2008 pour environ 100M$ et remplace ainsi Symantec CommandCentral, un bon produit qui n'arrive pas à percer.
  • Prisa Networks éditeur américain d'un SAN Manager acquis par EMC en 2002 pour 20M$.
  • Quest Software confirme son intérêt pour le secteur avec la disponibilité du produit Quest Storage Horizon acquis de Monosphere début 2009.
  • SANavigator, au départ une solution d'inventaire SAN, acquis successivement par McData puis par Brocade.
  • Storability acquis par StorageTek puis par SUN et maintenant par Oracle, et qui va finir à la poubelle.
  • StorScape, émanation d'Hermes SoftLab et Eurologic, est revenu dans le giron de nos amis Slovénes. L'expertise est restée mais le produit a disparu.
  • SUN s'est toujours cherché sur cette partie et ces acquisitions ont toujours été des succès. Highground était la tentative de positionnement sur le SRM, elle est restée une expérience... puis est arrivé STK avec Storability mais toujours pas de grande révolution et adoption du marché.
  • TeraCloud a été intégrée à Estorian.
  • TrelliSoft a été acquis par IBM.
  • Veritas SANPoint Control a disparu pour laisser la place à CommandCentral Storage qui couple le physique et le logique,  issu de l'acquisition de NTP Storage Reporter en 2002. L'adoption du marché demeure faible.
  • WQuinn, éditeur américain est passé successivement chez Precise puis chez Veritas et naturellement chez Symantec.  On ne le trouve plus au catalogue.
Quelques absents et notamment Dell, les utilisateurs ne s'y trompent pas, Dell demeure un fournisseur d'un composant de l'infrastructure mais pas de la logique associée. Tous les acteurs sont Américains à quelques exceptions près comme Onaro, Data Global ou Northern Parklife sans évoquer StorScape. Il reste donc surtout EMC, IBM, HP, NetApp, Symantec et CA, le reste des acteurs est anecdotique.
Le retour du SRM est quand même surprenant, le marché attend le support complet des environnements de virtualisation serveur qui va servir de différentiateur entre les offres...
Share:

Monday, September 07, 2009

La SNIA SDC dans quelques jours

SDC Banner 2009
La SNIA SDC (Storage Developper Conference) se déroulera du 14 au 17 Septembre à Santa Clara avec une nouvelle fois un super programme. Parmi les intervenants mon pôte Dhruba Borthakur pour couvrir la partie Hadoop, lui-même responsable Hadoop chez Facebook et ancien Yahoo et Veritas et Garth Gibson, un des pères du RAID et CTO/Co-founder de Panasas pour dévoiler une vision Cloud et File Systems, ça sent le truc parallèle... On retrouvera Sun avec Jeff Bonwick et Bill Moore qui feront la même présentation que l'année dernière pour pousser ZFS mais devraient aussi couvrir les nouveautés, NFSv4.1 sera largement couvert notamment pNFS, CDMI (Cloud Data Management Interface), XAM, CIFS/SMB v2.1, Samba, SSD, iSCSI ou le Green. Une vraie bonne semaine, j'y reviendrai avec plusieurs posts sur place.
Share:

Saturday, September 05, 2009

Quelques thèmes de plus

A la demande de plusieurs lecteurs suite au sondage, j'étends la couverture de ce blog au Cloud Computing et surtout au Cloud Storage et le modèle SaaS associé. J'avais drafté et écris un certain nombre de posts envisageant un nouveau blog spécifique au Cloud Storage mais multiplier les blogs impliquerait une trop grande dispersion du contenu. Je suis donc votre avis et vous trouverez donc dans les prochaines semaines certains posts liés au Cloud parmi d'autres plus traditionnels. 2 autres sujets ont retenus votre attention, l'accès distant avec le WAFS ou l'accélèration/l'optimisation WAN et bien sûr l'Open Source, incontournable. Ca tombe bien. Merci de vos remarques et commentaires.
Share:

Friday, September 04, 2009

Tuesday, September 01, 2009

Bataille de SPEC

Isilon (www.isilon.com | NASD:ISLN) et Exanet (www.exanet.com) se livrent une bataille à coup d'annonces de résultats de bench et notamment la récente publication liés à SPECsfs. L'entreprise de Seattle avance une performance de 46635 IOPS pour 1,91 ms de temps réponse moyen pour son système IQ5400S, la barre des 46000 IOPS est ainsi battue. La configuration comporte 10 noeuds IQ5400S pour 54To sous OneFS. D'après le constructeur, c'est la première publication de résultats SPECsfs2008 à ce niveau de performance. Et là commence la polémique puisqu'Exanet a annoncé 119550 IOPS pour 2,07 ms pour une configuration 8 noeuds ExaStore et une capacité d'environ 65To. Pour vous faire une idée, simple, rendez-vous sur www.spec.org/sfs2008/results/sfs2008nfs.html. Reste quelques points de conventions, l'annonce d'Isilon prend en compte l'aspect Scale-out ce que n'est pas vraiment la philosophie Exanet. La seconde différence est le nombre de disques plus faible pour arriver à ce niveau. Pour finir, la configuration Isilon offre une bonne linéarité et le nombre de noeuds maximum est de 144 noeuds donnant une projection de 650000 IOPS soit plus 5 fois le résultat Exanet. Mais où va-t-on, il s'agit de mesurer la performance absolue, le temps de réponse et de mettre le prix public en face pour obtenir le ratio, faites-vous votre idée car les 2 solutions fonctionnent parfaitement.
Share: