Transcription de la webdiffusion
M. Chadwell : Bonjour à tous. Bonjour, bon après-midi, où que vous soyez. Je tiens à remercier tout le monde d’avoir rejoint les « DataCore Storage Success Stories ». Aujourd’hui, nous sommes ravis de mettre à l’honneur Architectural Nexus. Nous allons voir comment cette entreprise parvient à garantir des performances applicatives élevées, dans le respect des délais et du budget. Il s’agit du premier épisode de cette série, merci donc à tous d’être présents. Je me réjouis de vous présenter l’un de nos clients et l’un de nos partenaires, car nous avons une histoire unique et très intéressante à vous raconter aujourd’hui.
Cet exposé est en quelque sorte dédié à d’autres personnes qui pourraient être confrontées à certains défis dans leur environnement. J’ai donc hâte d’approfondir un peu plus le sujet aujourd’hui avec mon panel. Je vais vous présenter notre partenaire et notre client, puis vous en dire un peu plus sur DataCore et sur la manière dont notre solution a pu contribuer à cette transformation. Nous allons revenir en détail sur les défis auxquels notre client, Architectural Nexus, a été confronté, ainsi que sur la solution mise en œuvre, le déroulement du projet et les résultats obtenus.
Nous y reviendrons dans un instant afin que vous puissiez prendre connaissance de l’ordre du jour d’aujourd’hui. Sur ce, je vais vous présenter un peu plus en détail certains des intervenants présents ici et vous en dire un peu plus sur leurs entreprises respectives. Je m’appelle Michael Chadwell. Je suis responsable des canaux de distribution ici aux États-Unis et je suis ravi d’être accompagné de Kent Hanson, directeur informatique chez Architectural Nexus. Steve Hunsaker, ici chez DataCore, est notre directeur de l’ingénierie des systèmes. Et Jonathan Kendrick, d’USI, qui est notre partenaire du mois et qui nous aide à gérer ce compte et à permettre à Kent de surmonter quelques défis.
Je voudrais simplement rappeler quelques règles pratiques à l’attention de tous les participants à cette visioconférence. La séance d’aujourd’hui prendra la forme d’une table ronde. Je tiens à ce que chacun se sente libre de poser quelques questions dans la fenêtre de discussion. Vous la verrez à droite de votre écran. La présentation d’aujourd’hui est enregistrée et sera disponible à la demande ; vous recevrez un e-mail de BrightTALK à l’issue du webinaire.
Veuillez également noter que la présentation d’aujourd’hui comporte quelques documents joints que vous pouvez emporter avec vous. Il s'agit d'un livre blanc décrivant ce cas d'utilisation de manière un peu plus détaillée. Sur ce, je vais donc commencer la présentation. Je voudrais vous présenter Kent Hanson, qui fait partie de notre table ronde. Kent, pourriez-vous nous en dire un peu plus sur votre rôle, ainsi que sur Architectural Nexus et l'entreprise elle-même ?
M. Hanson : Bien sûr. Bonjour à tous. Je m’appelle Kent Hanson. Je suis directeur informatique chez Architectural Nexus, comme cela a été mentionné. Nous sommes un cabinet d’architecture basé à Salt Lake City. Nous disposons également d’un bureau à Sacramento. Notre entreprise a été fondée en 1985. Depuis quelque temps, nous nous concentrons particulièrement sur la construction durable et le défi de la construction durable. Ainsi, pour joindre le geste à la parole, nous avons construit notre propre bureau à Sacramento, qui a été le premier bâtiment à obtenir la certification « Living ».
Et cela signifie, si vous ne savez pas ce qu’est la certification « Living Certified », que nous ne donnons rien à la ville et que nous ne prenons rien à la ville. Nous produisons toute notre énergie nous-mêmes. Nous récupérons notre propre eau de pluie et la filtrons pour tous les usages du bâtiment. Nous ne rejetons rien vers la ville, que ce soit des eaux usées ou quoi que ce soit d’autre. Tout est composté sur place. C’est donc un véritable « bâtiment vivant » et nous produisons 125 % de l’énergie que nous consommons. Cela nous a amenés à aider d’autres clients à développer et à mettre en œuvre leur propre modèle énergétique afin de réduire la consommation d’énergie nécessaire au fonctionnement d’un bâtiment, si vous voulez. Nous aidons des entreprises partout aux États-Unis. Voilà donc ce que nous faisons.
Notre défi consistait donc non seulement à construire un bâtiment certifié « Living Building », mais aussi à pouvoir y travailler et mener à bien notre activité, qui fait appel à des processus très complexes et nécessite une grande puissance de calcul. Sur ce, je vous redonne la parole.
M. Chadwell : Oui, oui, tout à fait. J’ai hâte d’approfondir ce sujet. Beaucoup d’entre vous qui participez à cette conférence téléphonique travaillez vous-mêmes dans des cabinets d’architecture ou dans des environnements où l’utilisation des données est très intensive. Nous allons donc laisser Kent nous en dire un peu plus à ce sujet dans une minute. Je voudrais maintenant donner la parole à notre partenaire présent lors de cette conférence téléphonique, qui travaille en étroite collaboration avec Architectural Nexus. Jonathan, si vous voulez bien. Présentez-vous, parlez-nous un peu plus d’Universal Systems et peut-être aussi de ce qui vous enthousiasme particulièrement aujourd’hui ?
M. Kendrick : Merci beaucoup. Je m’appelle Jonathan Kendrick et je suis directeur du développement commercial chez Universal Systems Incorporated, ou USI. Nous sommes spécialisés dans la fabrication et l’assemblage en OEM pour divers clients ; nous les aidons parfois à développer leur marque, mais nous disposons également de notre propre marque, la gamme Universal. À cet égard, nous ne nous considérons pas simplement comme un fabricant : nous souhaitons proposer des solutions et aider nos clients à résoudre les problèmes auxquels ils pourraient être confrontés, tout en les accompagnant dans la conception d’une architecture adaptée à leur environnement.
C’est là que l’histoire reprend, lorsque Kent et moi-même nous sommes lancés dans l’aventure DataCore et avons commencé à l’utiliser dans son environnement. Je m’en voudrais de ne pas préciser qu’en tant que fabricant OEM, nous avons eu l’occasion de découvrir de nombreuses solutions de stockage différentes, des solutions prêtes à l’emploi, des boîtiers. Nous avons passé au crible de nombreuses solutions et, au final, ce sont les fonctionnalités et la possibilité d’intégrer DataCore dans n’importe quel environnement pour créer des solutions évolutives, tant au niveau matériel que logiciel, et répondre aux besoins des clients qui ont fait pencher la balance. C’est sans hésitation que nous avons décidé de nous associer à DataCore il y a environ huit ans. Nous avons donc mis en place de nombreuses architectures autour de cette solution de stockage et développé des fonctionnalités intégrées avec ce produit.
M. Chadwell : Génial. Oui, merci pour ça, Jonathan. Je reçois déjà des questions dans le chat et je suis ravi d’annoncer que Jonathan, d’USI, nous aide à promouvoir et à organiser une réunion du groupe d’utilisateurs DataCore à Salt Lake au début du mois prochain, le 7 février. Je suis vraiment ravi de t’avoir parmi nous. Je suis ravi que toi et Kent puissiez discuter de la façon dont nous avons vraiment accompli quelque chose d’assez incroyable chez Architectural Nexus. Avant d’entrer un peu plus dans les détails, je voudrais simplement vous présenter Steve Hunsaker, notre expert maison en matière de stockage défini par logiciel ici chez DataCore.
Steve, tu veux présenter brièvement notre équipe à tout le monde, puis on approfondira un peu plus la discussion avec Kent ?
M. Hunsaker : Tout à fait. Merci à tous d’être venus. Je m’appelle Steve Hunsaker, je suis directeur de l’architecture des solutions pour les Amériques et je suis ravi de vous en dire plus sur DataCore et notre produit. Pour faire simple, cela fait 21 ans que nous fournissons au monde entier des logiciels permettant aux clients d’utiliser leur propre matériel. Dans ce cas précis, USI leur a fourni un boîtier Supermicro. Comme nous faisons cela depuis 21 ans, nous estimons être la référence en la matière.
Nous avons été les pionniers de la technologie qui a finalement conduit, à partir de ce que nous appelions à l’origine « l’architecture pilotée par logiciel », à la catégorie dans laquelle le secteur a décidé de nous classer, à savoir software-defined storage. Nous sommes présents dans le monde entier. Nous comptons de nombreux clients ravis. Je pense que le taux de renouvellement de 95 % parle de lui-même. Nous disposons d’une formidable base de clients, satisfaits non seulement de ce que nous leur apportons en termes de performances et de coûts, mais également désireux de renouveler leur contrat et de conserver la licence perpétuelle que nous proposons. Notre siège social est situé à Fort Lauderdale, en Floride.
En fait, c’est exactement là où j’en suis en ce moment : je rencontre toutes sortes de personnes pleines d’énergie et de passion, et j’ai vraiment le sentiment que nous sommes l’un des rares fabricants au monde à pouvoir nager en eaux bleues, à innover véritablement sur le marché et à proposer des solutions sociales comme celles que nous développons pour Kent. Je tiens simplement à remercier Kent. Je travaille avec lui depuis quelques années. C’est quelqu’un de formidable, et j’ai hâte d’assister à cette présentation.
M. Chadwell : Merci à vous tous. Voilà qui conclut la table ronde d’aujourd’hui. Comme Steve l’a souligné, nous sommes reconnaissants de pouvoir compter sur un partenaire local tel qu’USI. C’est pourquoi nous sommes une entreprise axée à 100 % sur le réseau de distribution. Nous considérons notre solution comme une couche de stockage intelligente pouvant être utilisée dans divers secteurs d’activité. Et nous nous associons aux meilleurs partenaires de distribution possibles, ceux qui disposent d’une expertise régionale et d’une connaissance approfondie du marché pour travailler en étroite collaboration avec leurs clients, identifier les évolutions et jouer véritablement le rôle de leader d’opinion et de conseiller de confiance, à l’image de ce que vous pouvez constater ici chez Architectural Nexus.
Bon, entrons un peu plus dans les détails, d’accord ? Parlons de cette réussite en matière de stockage. D’accord. Parlons du problème et entrons directement dans le vif du sujet. Alors Kent, je pense que ça serait utile que tu nous en dises un peu plus sur le défi auquel tu as été confronté. Je sais que tu as dit avoir commencé… c’était, si je me souviens bien, à la fin des années 80. Avec l’explosion des données, quel impact cela a-t-il eu sur toi, sur ton entreprise, et qu’est-ce qui a vraiment motivé cette collaboration pour relever ce défi ?
M. Hunsaker : À l’époque où j’ai commencé à travailler pour ce qui est aujourd’hui Architectural Nexus, je crois que l’ensemble de notre sauvegarde sur bande représentait 35 gigaoctets. C’était déjà une quantité considérable de données à l’époque. Aujourd’hui, un seul projet dépasse largement ce volume grâce à la quantité de données générées lors de sa réalisation. Au fur et à mesure de notre croissance, nous en sommes arrivés à un point où notre réseau comptait de nombreux « îlots de données », dont la gestion devenait de plus en plus difficile. Il est alors apparu évident que nous devions adopter une solution SAN. Nous avons donc commencé à étudier différents produits. Je me souviens que j’achète du matériel à Jonathan depuis… depuis combien de temps déjà, Jonathan ? Probablement seize ans maintenant ?
M. Kendrick : Ouais, ouais.
M. Hunsaker : Ça fait donc longtemps. Je me souviens avoir demandé à Jonathan : un jour, on en parlait justement, et je lui ai dit : « Oui, on va acheter un SAN. » Il m’a répondu : « Eh bien, tu devrais vraiment te pencher sur DataCore. » C’était il y a environ huit ans maintenant. À l’époque, je ne comprenais pas vraiment ce qu’était le concept de « software-defined ». Nous avons donc opté pour l’un des concurrents de DataCore pour notre source de données principale.
Nous avons finalement opté pour le SAN et l’avons utilisé pendant environ un an, mais au moment même où nous achetions ce SAN, nous nous sommes retrouvés dans une situation où nous avions quatre bureaux différents – en fait, il y en avait probablement cinq à l’époque – et nous avions besoin que les utilisateurs puissent travailler simultanément sur le même projet et ouvrir des fichiers. Nous avons donc commencé à chercher comment y parvenir. C'est à peu près à cette époque qu'Autodesk a annoncé qu'il était possible d'utiliser Revit, un logiciel de gestion des informations du bâtiment, sur Citrix. Nous avons donc commencé à nous intéresser à Citrix.
Nous avions donc notre autre SAN en service, sur lequel VMware , puis nous avons commencé à nous orienter vers Citrix. Nous avions déjà dépensé beaucoup d’argent pour cet ordinateur. Il était coûteux et fonctionnait bien, mais nous nous trouvions désormais dans une situation où nous avions besoin que ces équipes travaillent sur ces projets et où nous devions disposer de ce que j’appellerais une « équipe virtuelle », si vous voulez. Nous avions des collaborateurs à Sacramento qui travaillaient sur des projets à Salt Lake, et inversement ; différents dessinateurs se relayaient selon des horaires variés et disposaient ainsi de temps libre.
Bon, comment faire pour qu’ils puissent travailler depuis Sacramento ? Comment les faire participer au projet à Salt Lake, à la rédaction des documents et tout le reste ? Citrix s’est donc imposé comme la solution évidente. En nous penchant sur Citrix et sur ses exigences, nous avons réalisé que nous avions besoin d’un stockage rapide. Nous sommes donc allés acheter, en gros, un ensemble de disques durs tournant à 15 000 tr/min. Je crois nous en avons acheté six ou huit lors de notre premier achat. Et cela fonctionnait très bien pour un ou deux utilisateurs. On pouvait même aller jusqu’à une dizaine d’utilisateurs sans que personne ne se plaigne, mais dès qu’on a commencé à pousser le système au-delà de cette limite, les gémissements se faisaient entendre jusqu’au-delà des frontières de l’État.
C'était vraiment dommage que ça ait ralenti aussi vite. Je me suis retrouvé à nouveau à discuter avec Jonathan de nouveau matériel, et il a remis DataCore sur le tapis. Je me suis dit : « Bon, et Jonathan, il faut lui rendre justice, on va juste faire un projet pilote. Qu'est-ce que ça peut faire ? D'accord. » Il est venu, a mené son projet pilote, et les plaintes se sont en quelque sorte tues. Le problème a disparu et nous avons pu ajouter davantage d’utilisateurs au SAN.
En gros, il s’agissait d’installer un logiciel sur du matériel que nous avions déjà acheté ; c’était du matériel de classe entreprise, mais ce n’était pas un SAN. Or, en rachetant DataCore et en l’installant par-dessus, cela s’est soudainement transformé en SAN, et à l’époque, je ne me rendais pas compte à quel point c’était puissant. À mesure que nous nous développions, de plus en plus de gens me demandaient : « Hé, je peux avoir un ordinateur de bureau par-ci ? Et par-là ? »
Un jour, je ne sais plus exactement quand c'était, j'ai commencé à remarquer que les IOPS de notre SAN atteignaient régulièrement 55 000 IOPS. Puis, un jour, à ma grande surprise, nous avons enregistré 372 000 IOPS sur notre SAN. Sur ce petit SAN, qui était presque un simple accessoire, cela m'a vraiment époustouflé. En parallèle, le volume de données explosait sur notre Compellent et nous devions commencer à l’étendre. Je bouge, je passe d’un sujet à l’autre. Si vous avez besoin que je revienne en arrière, pas de problème.
M. Chadwell : Non, non, non, tout va bien.
M. Hunsaker : Ce qui est étrange, c’est que nous avons dû mettre à niveau les données sur notre autre SAN. Je m’excuse. Nous avions besoin d’augmenter sa capacité de stockage, car nous étions à court de téraoctets. J’ai donc appelé notre revendeur et je lui ai dit : « Donnez-moi un devis pour passer de disques de 2 téraoctets à des disques de 4 téraoctets. » Et quand j’ai reçu le devis, j’ai failli tomber de ma chaise, car le montant était supérieur à ce que j’avais payé pour DataCore et pour les disques durs de mon SAN DataCore. En fait, le devis indiquait un prix quatre fois supérieur au tarif habituel d’un disque dur. Je les ai rappelés et je leur ai dit : « Je pense qu’il y a une erreur », mais ils m’ont répondu : « Non, ce sont… vous devez comprendre, ce sont des disques durs de catégorie A, tout juste sortis d’usine, et vous obtenez la crème de la crème. »
Eh bien, si j’obtiens la crème de la crème, pourquoi tombent-ils en panne deux fois plus souvent que mon SAN DataCore ? Pour chaque disque que je perdais sur DataCore, j’en perdais deux sur mon autre SAN et je devais les remplacer. Et nous les sollicitions davantage. La situation a donc continué à s’aggraver, alors j’ai dit : « Vous savez quoi ? Nous allons mettre ce projet en attente pour l’instant. » Nous allons mettre les données de côté et les stocker dans une autre zone.
Nous avons lancé un processus d’archivage pour cela. Puis le moment est venu… Il n’y a pas si longtemps, on m’a annoncé que notre SAN, celui de notre concurrent, arrivait en fin de vie et qu’il allait passer en support je devais support pratiquement remplacer tout le matériel.
M. Chadwell : Arrêtons-nous là, Kent. Je voudrais juste faire un petit récapitulatif de ce que j’ai entendu et avoir également l’avis de Steve sur certains de ces points. Je trouve cette histoire vraiment intéressante, car vous avez expliqué qu’à mesure que votre entreprise se développait, la collaboration était devenue un enjeu essentiel. Pour permettre à vos collaborateurs de télécharger des fichiers et de travailler sur des projets dans différentes villes et à travers le monde, ces fichiers devenaient de plus en plus volumineux, ce qui représentait une charge importante — et c’est essentiellement à vous et à votre équipe qu’il incombait de les produire.
Et après avoir mis en place DataCore, sous la houlette d’USI, vos équipes, et plus particulièrement votre architecte — dont tout le monde sait qu’il ne s’agit en aucun cas d’un simple employé parmi d’autres —. Avant, on passait notre temps à attendre que les fichiers se téléchargent, s’ouvrent ou s’enregistrent ; eh bien, désormais, tout à coup, ils peuvent collaborer plus rapidement, vous pouvez…
M. Hunsaker : Permettez-moi d’aborder ce sujet un instant, car c’est un point intéressant. À une certaine époque, nous ouvrions des fichiers AutoCAD, vous savez, des fichiers d’un, deux ou trois mégaoctets, et on pouvait les ouvrir, travailler dessus, les enregistrer, etc. Aujourd’hui, avec Revit, comme tout est intégré et peut être converti en modèles 3D et tout ça, nous ouvrons désormais des fichiers de 300 à 500 mégaoctets. Il n’est pas rare d’atteindre les 600 mégaoctets.
Quand on clique pour ouvrir ce fichier, eh bien, il peut y avoir jusqu’à six ou huit personnes qui ouvrent ce fichier de 600 ou 500 mégaoctets. Ça représente un volume considérable de données qui transitent et sortent soudainement du disque dur. Bien plus que les un ou deux mégaoctets qui sortaient auparavant. C’est donc devenu un véritable problème. Un va-et-vient incessant entre précipitation et attente. C’était…
M. Chadwell : J'allais justement passer la parole à Steve. Steve, quel est l'impact de cette solution en termes de densité, ou pourquoi une telle architecture permet-elle au logiciel de bien gérer cela ?
M. Hunsaker : Je pense que cela nous ramène à l’argument de départ que j’essayais de mettre en avant, à savoir que notre logiciel est à licence perpétuelle. Vous en êtes propriétaire pour toujours. Pour le dire simplement, quand on regarde Kent et son rachat de Compellent, on achète — soyons honnêtes, les gars. Les baies de stockage que l’on peut acheter sur le marché, on paie en réalité pour leur logiciel et non pour leur matériel.
Même s’ils essayaient en réalité de faire payer à Kent le prix de leur matériel. Mais le fait est qu’ils utilisent tous du matériel standard. Ils ne fabriquent probablement aucun de ces composants. Ils se contentent d’afficher un prix sur leur baie, avec leur logiciel, et c’est ainsi qu’ils gagnent de l’argent. Dans ce cas précis, comme DataCore a été véritablement conçu dans un souci de flexibilité maximale, le SAN DataCore peut tout simplement intégrer ou regrouper n’importe quel stockage Fibre Channel, iSCSI à connexion directe au sein d’un seul pool.
Peu importe donc que vous utilisiez un système de stockage à connexion directe ou une baie Compellent, XYZ ou ABC. Vous pouvez ainsi faire évoluer votre infrastructure en tirant parti de l'environnement dont vous disposez, augmenter la capacité à l'aide de disques standard comme l'a indiqué Kent, évoluer très efficacement, et pour répondre à votre question…
M. Hanson : Vous ne perdez rien en termes de performances.
M. Hunsaker : C'est exact. Et je pense qu'il est important pour toi, Kent, de mettre en avant cette tendance à la hausse du taux de consolidation.
M. Hanson : J’allais justement dire que c’est moi qui décide désormais que nous sommes entièrement passés à DataCore. C’est moi qui décide quand mon matériel arrive en fin de vie. Pas quelqu’un d’autre. Vous voyez ce que je veux dire ? Je peux acheter autant de disques durs que je veux et les utiliser aussi longtemps que je le souhaite, et DataCore s’en moque. Je peux les appeler pour obtenir de l’aide concernant leur logiciel sur des disques durs vieux de 10 ans, et ils continueront à m’aider. Ce n’est pas parce que le fabricant du SAN me dit : « Hé, vous êtes en fin de vie, vous n’êtes plus support Vous comprenez ce que j’essaie de dire ?
M. Chadwell : Oh, tout à fait. Jonathan, je te poserais même la question : en quoi cela aide-t-il ton entreprise, n'est-ce pas ? En tant que revendeur et conseiller en comptes stratégiques, en quoi cette histoire t'aide-t-elle ?
M. Kendrick : Eh bien, pour être honnête, cela peut aussi nuire à mon activité, car si je peux revendre le logiciel à plusieurs reprises, cela génère davantage de chiffre d’affaires. C’est une source de revenus complètement différente que nous n’exploitons pas, car nous ne facturons pas nos clients. Pour être franc avec vous, nous gagnerions probablement beaucoup plus d’argent si nous vendions n’importe quelle autre marque que DataCore, du point de vue du revendeur. Mais nous n’offririons pas à nos clients la meilleure solution. Nous ne les aiderions pas à gérer leur budget et nous ne leur proposerions pas une solution entièrement évolutive dont ils auraient le contrôle.
M. Chadwell : Oui, et en instaurant cette relation de confiance, comme celle que vous avez avec Kent, comme il l’a dit, c’est lui qui décide quand il est prêt à renouveler son matériel. Vous savez qu’il reviendra vers vous, n’est-ce pas ?
M. Kendrick : C'est vrai. Nous nous chargeons donc de la maintenance et nous apportons notre aide sur le plan matériel, mais comme DataCore propose une licence perpétuelle, je ne lui revends pas le logiciel. Le fait de regrouper le logiciel et le matériel dans une seule offre lui permet, à chaque fois qu’il renouvelle son matériel, de profiter encore et encore de ces avantages et de réduire son coût total de possession. Kent, dans votre cas, vous avez probablement déjà renouvelé votre matériel. Est-ce la deuxième fois ou s’agit-il de la troisième ?
M. Hanson : Je pense que oui, en effet. Quand nous nous sommes lancés dans ce projet, nous atteignions 385 000 IOPS — pour être précis, c’était plutôt 370 000 IOPS, mais nous utilisions des disques tournant à 15 000 tr/min. À l’heure actuelle, notre premier niveau — et c’est un tout autre sujet dont nous pourrions parler, à savoir les fonctionnalités clés et ce que nous avons réellement apporté en utilisant DataCore —, notre premier niveau est désormais le FSC. Tout, chaque écriture et chaque lecture, si ce n’est pas mis en cache en RAM, passe directement par le FSB. Nous avons décidé, lorsque cela s’est produit et que cela n’entraînait aucun coût supplémentaire, d’acheter un disque SSD. Je suppose que cela représentait le coût de l’opération ; nous nous sommes assurés de disposer de la licence nécessaire auprès de DataCore et nous l’avons installé. C’est assez simple à mettre en place.
M. Chadwell : Et si je peux ajouter quelque chose à cela, vous avez mentionné que nous y avions intégré des SSD, mais ce n’est pas uniquement pour le stockage. Quelle que soit la technologie qui apparaisse, même celle qui n’a pas encore été inventée, tant qu’elle s’insère dans un emplacement PSI Express, nous avons la possibilité de faire évoluer ce boîtier sans le démonter. Ce n’est pas un boîtier fermé que l’on range dans un placard pour l’oublier. Nous pouvons l’améliorer en permanence à mesure que le secteur propose des composants plus rapides.
M. Hanson : Parlons-en donc, car notre prochaine étape – puisque nous disposons déjà de SSD – c’est NVMe Je me demande NVMe quand et où, à quel moment précis, nous allons passer à cette technologie. Donc, comme je le disais, quelqu’un vient nous voir et nous dit : « Bon, j’ai besoin d’ouvrir ce fichier de 500 mégaoctets. » Chez nos concurrents, une grande partie de ces données proviendrait directement du disque – un disque rapide, certes – mais l’ouverture du fichier prendrait tout de même beaucoup de temps. Lorsque vous ouvrez ce premier fichier, DataCore – et corrigez-moi si je me trompe, Steve, je ne veux pas donner de fausses informations –, DataCore met alors ce fichier en cache dans la mémoire vive (RAM).
Je crois que la taille du cache sur le SAN de la concurrence était de 8 Go, ou quelque chose comme ça. Ce n’était pas énorme. La taille du cache sur mon DataCore est de 64 gigaoctets. C’est parce qu’il s’agit d’une solution logicielle. C’est moi qui choisis sa taille. Donc, quand un premier utilisateur arrive, il ouvre le fichier. S’il s’agit d’un fichier récemment utilisé, il sera récupéré depuis le RAID SSD et chargé dans le cache. Lorsque l’utilisateur suivant arrive et que ce fichier se trouve toujours dans le cache, il est directement extrait de la RAM. J’ai pu constater, de manière régulière, que notre serveur de production transférait 3 Go, ou plutôt 2,4 Go de données, sur notre réseau 10 G vers notre environnement Citrix pour que les utilisateurs puissent les ouvrir.
Donc, en matière de solutions « software-defined », le niveau de granularité et de contrôle dont vous disposez dépasse de loin ce qu’offrent ces solutions prêtes à l’emploi. Pour en revenir à notre concurrent — et n’hésitez pas à m’interrompre à tout moment —, nous nous sommes retrouvés dans une situation où nous avions acheté… je crois que c’était 26 téraoctets ou 24 téraoctets de données. Eh bien, nous étions loin d’atteindre ce volume, alors je les ai appelés et je leur ai dit : « Hé, qu’est-ce qui se passe ? »
Ils m’ont regardé et m’ont dit : « Pour que vous puissiez migrer vos données du niveau 1 vers le niveau 3, nous devons effectuer un instantané quotidien, le stocker snapshot lancer la migration des données pendant la nuit. » Le fait que cela occupe de l’espace de stockage dont j’avais besoin pour mes données de production m’a poussé à demander une mise à niveau de notre disque dur. Ainsi, pour pouvoir tirer davantage de capacité de stockage de notre SAN, j’ai dû supprimer certains de ces snapshots.
Bon, commençons par voir ce que DataCore a à offrir. Vous savez quoi ? Je n’ai pas besoin d’un snapshot mettre en place la hiérarchisation. Le système s’en charge en temps réel, au fur et à mesure que l’on lit et écrit des données. Et à mesure que les anciens blocs sont de moins en moins sollicités et utilisés, le système les déplace automatiquement vers des disques plus lents et moins coûteux. Cependant, si je souhaite snapshot , je peux écrire un script dans DataCore qui créera snapshot volumes quand je le souhaite et les stockera sur différents volumes si je le souhaite. Je ne perds donc pas la possibilité de snapshot je ne perds pas non plus d’espace de stockage grâce à la hiérarchisation automatique de mes données.
Cela a donc constitué un atout pour nous lorsque nous avons commencé à comparer sérieusement les deux solutions. Nous avons ensuite réalisé que DataCore proposait une fonctionnalité appelée « protection continue des données » : grâce à celle-ci, je peux, par exemple sur mon SAN DataCore, revenir à n’importe quel moment au cours des deux dernières semaines pour restaurer un volume et extraire les données qu’il contient à tout moment.
M. Chadwell : Quelqu’un m’a signalé que le son s’était coupé, mais j’entends tout le monde. Ah d’accord. Le son est revenu. Très bien. Je voulais m’assurer que nous n’avions pas perdu le son. Je ne voulais pas t’interrompre, Kent. Puisque c’est arrivé, Steve, voudrais-tu peut-être développer un peu plus ce dont parle Kent, notamment le transfert des différents niveaux de stockage et de mise en cache vers la mémoire vive, et ce que cela implique ? Je sais que Kent vient de l’évoquer brièvement, mais tu pourrais peut-être nous en dire un peu plus sur ce qui se passe en coulisses.
M. Hunsaker : Bien sûr. SANsymphony est le nom de notre produit, n’utilise pas de disque pour la mise en cache, ce qui, je pense, nous rend assez uniques dans ce domaine. En effet, nous utilisons la mémoire vive pour mettre en cache les opérations de lecture et d’écriture. Bien sûr, il faut ensuite extraire ces données de la mémoire volatile et les écrire sur le disque. C’est donc ce dont parlait Kent : ces niveaux de stockage.
En effet, nous pouvons regrouper des disques aux performances variées au sein d'un même pool, ce qui va en quelque sorte à l'encontre des pratiques traditionnelles. Vous pouvez désormais créer votre propre structure de niveaux, du plus rapide au plus lent. Et lorsque nous procédons à la décompression puis à l'écriture sur disque, nous écrivons d'abord sur le niveau 1, et notre hiérarchisation automatique s'effectue en temps réel.
Ce n'est pas une tâche de gestion des niveaux ni un calendrier qui détermine quand et comment ces blocs de stockage sont déplacés, qu'ils soient promus ou rétrogradés au sein de la hiérarchie des niveaux. Alors, Kent, explique-nous comment tu gères la classification automatique par niveau ?
M. Hanson : Pour notre part, nous disposons de trois niveaux de stockage. Comme vous le savez sans doute, DataCore permet d’aller jusqu’à 15 niveaux. Lorsque je dis que c’est vous qui décidez quand vos disques deviennent obsolètes, cela signifie que vous disposez de 15 niveaux à votre disposition. Alors, en quelques mots, qu’est-ce que la hiérarchisation automatique ? La hiérarchisation automatique consiste à opérer au niveau de l’octet et à répartir vos disques virtuels sur différents types de supports.
Par exemple, le premier niveau pour nous, ce sont les SSD. Et je crois que nous avons huit disques SSD. Ensuite, nous passons au niveau suivant, qui correspond aux disques tournant à 10 000 tr/min. Nous disposons de plusieurs téraoctets de ce type de disques. Ensuite, lorsque les données deviennent trop anciennes et sont déplacées vers un niveau inférieur, elles sont transférées vers des disques SATA tournant à 7 200 tr/min. Nous exploitons donc trois niveaux de stockage. Si l’on considère la mémoire vive (RAM) comme un niveau à part entière, je ne sais pas si c’est nécessairement le cas, mais nous allons simplement dire pour l’instant que nous exploitons trois niveaux de stockage.
Il faut comprendre que, disons, si vous avez un fichier volumineux ou, je ne sais pas, peut-être une base de données Exchange très volumineuse ou quelque chose de ce genre, cette base de données Exchange pourrait en théorie passer de notre disque SSD à notre disque à 10 000 tr/min, puis même descendre jusqu’à notre disque à 7 200 tr/min, selon les blocs ou les octets qui sont continuellement écrits et lus. Ainsi, le système stocke les données qui sont continuellement sollicitées et les déplace automatiquement vers le support de stockage le plus rapide dont vous disposez. C’est ce qu’on appelle le niveau 1.
Et c’est vous qui définissez cela. Imaginons que demain, je vienne vous voir et que je vous dise : « Salut, Jonathan, j’ai besoin d’un ensemble de NVME », et qu’on les connecte ? Eh bien, je vais les connecter en tant que « stats attached » ou selon la méthode de mon choix, puis je précise : « Voilà mon nouveau niveau 1 ». DataCore réorganise alors toutes mes données pour que je dispose d’un niveau 1, d’un niveau 2, d’un niveau 3, puis d’un niveau 4 sur mes disques à 7 200 tr/min. Cela répond-il à votre question ? Est-ce bien ce que vous cherchiez ?
M. Hunsaker : Oui, je trouve cela très pertinent. Et je vous demanderais d’aller peut-être encore un peu plus loin en vous plaçant du point de vue des utilisateurs, des architectes – ou, en fin de compte, de ce que l’on pourrait appeler vos clients – et des projets. En quoi cela améliore-t-il leur quotidien du point de vue de l’application ? Qu’est-ce que cela signifie pour eux ?
M. Hanson : Imaginons que nous ayons un projet et que ces personnes travaillent sur un projet où elles créent des fichiers visuels, notamment des fichiers de modèles Revit volumineux. Les données de ce répertoire de projet sont automatiquement stockées de manière hiérarchique sur ces trois niveaux. Cependant, lorsqu’elles accèdent à ce fichier Revit et l’ouvrent, le chargement s’effectue. S’il s’agit d’un fichier qui a été ouvert au cours des derniers jours, nous n’allons pas rester là à attendre que ce fichier soit ouvert six fois à partir du disque, qui est peut-être lent. Il est chargé dans le cache RAM et, dès que la personne suivante vient y accéder, il est transmis par le réseau aussi vite que la technologie informatique le permet pour qu’elle puisse y accéder.
M. Hunsaker : Très bien. Juste une petite question rapide. Ils se demandaient simplement quelle était la configuration du serveur qui hébergeait les métriques avec DataCore ?
M. Hanson : Quelle était la configuration du serveur ? Quels étaient les indicateurs de performance pour DataCore ? En d'autres termes, vous souhaitez connaître la puissance du processeur, la mémoire vive et tout ça ?
M. Hunsaker : Citrix, la configuration Citrix, Kent.
M. Hanson : Ah oui, la configuration Citrix était un E5, et ils tournent à 3,3 gigahertz. Je ne connais pas le modèle exact.
M. Chadwell : Je crois que c'étaient les 2670, deux E5 2670, il y en avait deux dans chacun.
M. Hanson : Oui, et nous avions entre 512 gigs de RAM et 768 gigs de RAM par serveur.
M. Hunsaker : Et puis, Kent, nous avons également une autre question adressée à la partie adverse : quelle était la configuration DataCore des serveurs ?
M. Hanson : Les serveurs DataCore sont constitués de serveurs Supermicro, mais je ne me souviens plus des références exactes. Ce sont des processeurs à 2,6 gigahertz, de la série E5. Ils disposent de 10 disques, ce qui nous permet d’avoir un SAN actif. En réalité, nous exploitons deux SAN et, soit dit en passant, leur coût d’exploitation est inférieur à ce qu’il nous en aurait coûté de remplacer et de mettre à niveau le SAN d’un concurrent. L’exploitation de ces deux SAN nous revient moins cher que cette opération. Et ils fonctionnent en mode actif-actif.
En pleine journée, je peux désactiver un SAN sans que personne ne s’en aperçoive, grâce au fonctionnement de DataCore. Mais sur ces deux nœuds — j’appelle ainsi les nœuds qui exécutent le logiciel DataCore proprement dit —, nous avons deux disques en miroir qui démarrent le serveur principal DataCore, puis huit disques SSD de 2,5 pouces également en miroir, ce qui constitue mon niveau 1. Il y a ensuite une connexion SAP vers un [J Bod], et ces deux serveurs sont reliés à deux J Bods distincts équipés de disques de 2,5 pouces. De là, la connexion se poursuit vers une autre connexion SAP vers le J Bod équipé de disques de 3,5 pouces.
M. Chadwell : Si je peux me permettre de le souligner, Kent, je sais que nous avons procédé à quelques extensions, deux ou trois au total, au cours desquelles nous avons ajouté des étagères, installé différentes baies, déplacé votre niveau 1, déplacé les disques durs, les avons remplacés, et cela fait six ans que vous faites cela. Et si je peux me permettre de poser une question – cela pourrait être risqué car je ne connais pas la réponse exacte –, avez-vous déjà eu une panne ?
M. Hanson : Pas avec DataCore.
M. Chadwell : Voilà, c'est exactement ce que j'espérais que vous alliez dire.
M. Hanson : Oui, pas avec DataCore. Pour la maintenance et tout ça, avec DataCore, on choisit : « Je m’occupe de ça », que ce soit à gauche ou à droite, ou bien on peut avoir jusqu’à… c’est quoi déjà, Steve ? 16 nœuds ou quelque chose comme ça, et on peut aussi étendre le système horizontalement, mais nous n’en exploitons que deux.
M. Hunsaker : Oui.
M. Hanson : Elles sont très puissantes.
M. Chadwell : Sur Scuzzy ou par Fibre Channel ? On nous a posé une question.
M. Hanson : Nous utilisons le Fibre Channel. Nous utilisons le Fibre Channel. Donc, pour être tout à fait honnête, nous utilisons les deux. La liaison entre les deux serveurs, qui assure la mise en miroir, est de 10 gig [ice scuzzy]. Et puis, nous avons une connexion Fibre Channel vers les serveurs VMR.
M. Kendrick : Tu sais, Kent, je voudrais juste te rappeler une anecdote. Je ne sais pas si tu t'en souviens ou non. C'était il y a quatre ou cinq ans : tu m'avais appelé en pleine journée juste pour me dire que tu passais en revue tes journaux DataCore et que tu avais constaté que certains utilisateurs avaient atteint jusqu'à 325 000 IOPS, sans que personne ne t'appelle, sans que personne ne se plaigne, sans que le système ne ralentisse. Personne n'avait même remarqué que vous étiez confrontés à une telle tempête.
M. Hanson : Exactement. Exactement. Oui, je m’en souviens. Pour être tout à fait honnête, 325 000 IOPS, ce n’était pas un chiffre habituel au quotidien. On atteignait parfois des pics élevés, mais celui-là était exceptionnellement haut. En temps normal, il n’était pas rare d’atteindre entre 25 000 et 55 000 IOPS, selon l’activité du moment.
M. Chadwell : Diriez-vous que c’est juste ? J’adore entendre ce genre d’histoires, mais quand je pense à un tel cas de figure, vous parlez d’une amélioration des performances, ce qui, d’une part, vous permet de dormir sur vos deux oreilles, d’autre part, aide votre entreprise à se développer, n’est-ce pas ? Et vous pouvez ainsi prendre en charge davantage de projets à mesure que vous recrutez de nouveaux architectes et que vous continuez à construire ces « bâtiments vivants ». En substance, cela vous apporte la stabilité nécessaire pour atteindre ce niveau de performance. La haute disponibilité, n’est-ce pas ? C’est-à-dire garantir la continuité des activités. Jonathan vient de souligner que cela fait environ six ans qu’il n’y a eu aucune panne ni interruption de service depuis que DataCore fonctionne en arrière-plan. Et en termes de rentabilité…
M. Hanson : Le fait est que cela fait six ans que nous fonctionnons sans aucune panne avec du matériel standard. Pour répondre à vos questions, je tiens à préciser que le SAN concurrent dont j’ai parlé ou auquel j’ai fait allusion ne fait plus partie de notre infrastructure — techniquement, il figure toujours dans nos données, mais il est hors service. Nous ne l’utilisons même plus.
Nous avons entièrement adopté DataCore. Le retour sur investissement et le coût total de possession sont bien inférieurs, et à mon avis, c’est une meilleure solution. La seule chose que nous prévoyons de faire à l’avenir, c’est de migrer vers DataCore. Cette année, nous allons nous pencher sur la réplication asynchrone afin de dupliquer les données hors de notre réseau, pour que tout le monde comprenne bien. Nous disposons d’un réseau VGP et d’un énorme générateur.
Même en cas de coupure de courant, nous restons opérationnels. Nous avons subi plusieurs coupures de courant, mais nous sommes toujours en ligne. Nous disposons du VGP. Deux fournisseurs d’accès Internet différents nous assurent cette connectivité ; notre prochaine étape consiste donc à créer notre propre cloud à répliquer nos données à l’aide de DataCore vers nos sites distants. Pour nous, DataCore va donc occuper une place de plus en plus importante dans notre environnement de production et nous allons nous y fier de plus en plus.
Si vous prenez le temps de réfléchir à la notion de « software-defined », que se passe-t-il lorsque vous souhaitez transférer vos données vers Microsoft Azure ou mettre en place un SAN sur Amazon ? Eh bien, si vous disposez d’une infrastructure « software-defined », cela ouvre des possibilités, et vous pourriez peut-être en discuter un peu avec Steve. Je crois que c’est désormais pris en charge, n’est-ce pas, Steve, d’exécuter ce logiciel dans ces environnements ?
M. Hunsaker : Exactement. En effet, notre logiciel est tout simplement un logiciel qui s'installe sur un serveur Windows ; peu importe où se trouve ce serveur Windows, que ce soit dans votre garage ou chez un cloud .
M. Hanson : Vous créez votre propre SAN virtuel, et Microsoft considère alors que vous êtes un cloud Amazon, j’imagine. Donc, si vous souhaitez vous familiariser avec différents SAN, je vous conseillerais de faire appel à différents concurrents, mais si vous recherchez une solution unique, je parierais sur DataCore.
M. Chadwell : Nous avons reçu quelques questions. Je pense que nous avons plutôt bien réussi à présenter le sujet jusqu’à présent. Si certains d’entre vous ont des questions, n’hésitez pas à les poser dans le chat. L’une des questions porte sur l’expérience acquise avec l’utilisation de grands baies de stockage, telles que les EMC VNX, en combinaison avec DataCore ?
M. Hanson : Non, pas directement, mais je dirais que, grâce au cache et à l’algorithme, cela permettrait d’accélérer le processus. Un collaborateur de DataCore m’a d’ailleurs confié qu’un de leurs concurrents souhaitait utiliser DataCore comme solution « actif-actif », car il ne pouvait pas mettre en place une configuration de ce type. Il ne pouvait fonctionner qu’en mode « actif-passif ». Mais en ajoutant DataCore en amont, il était possible de passer en mode « actif-actif ». Je n’ai donc personnellement aucune expérience avec EMC ou VNX, mais je pense effectivement que cela fonctionnerait plus rapidement.
M. Kendrick : Nous avons effectivement de l’expérience dans ce domaine et vous pouvez tout à fait, vous pouvez utiliser un système EMC ou Unity, ou n’importe quelle autre solution de stockage de votre choix. Je ne vais pas vous gâcher la surprise, mais je sais que l’un des plus gros clients de DataCore – ce n’est pas un client avec lequel j’ai travaillé personnellement – utilise EMC, n’est-ce pas ?
M. Chadwell : C'est exact. Oui. Je ne savais pas si vous souhaitiez ajouter quelque chose à ce sujet, Steve, ou si cela vous convenait tel quel ? Avez-vous quelque chose à ajouter avant que je passe à la question suivante ?
M. Hanson : Non, c'est simple. Tout ce qui utilise Fibre Channel, iSCSI ou des tâches dirigées peut fonctionner derrière DataCore ; nous continuons à fournir nos fonctionnalités, et les produits sous-jacents continuent à offrir leurs meilleures fonctionnalités. Tout va bien. Vous êtes toujours là ?
M. Kendrick : Et pour pouvoir faire fonctionner le système au cas où le premier site tomberait en panne ; nous allons d’ailleurs utiliser du matériel standard et monter une solution sur une « super microbox », ce qui nous permettra d’économiser le coût d’achat d’un troisième EMC.
M. Chadwell : Nous sommes submergés de questions. Auriez-vous des conseils à donner sur la meilleure façon d'entretenir correctement l'espace de stockage afin d'éviter toute catastrophe ?
M. Hanson : Qui voulez-vous… ?
M. Hunsaker : Je vais intervenir ici. Je suis ravi de répondre à cette question. Si cela ne vous dérange pas, je vais essayer de répondre à autant de questions que possible d’un seul coup, car je vois qu’elles affluent. Le logiciel DataCore réside sur un serveur Windows ; vous pouvez donc le gérer comme vous le souhaitez avec Windows Update. Nous disposons d’un excellent support qui vous explique en détail les modifications apportées à Windows par les [hotpicks] de Microsoft et vous indique si vous devez ou non vous en préoccuper. En d’autres termes, il vous aide à déterminer dans quelle mesure vous devez rester à la pointe de la technologie.
Je pense que Kent a soulevé un point important concernant la possibilité de tester et de mettre à jour, qu’il s’agisse d’un pilote, d’un micrologiciel ou d’un autre élément, et peut-être que Kent pourrait y faire allusion. Mais le fait de pouvoir gérer cela sur l’un des deux côtés est très rassurant et donne confiance, sachant que l’on ne risque pas de mettre hors service l’ensemble du SAN, car les données sont stockées à deux emplacements distincts. Je répondrais donc sans hésiter qu’il est tout à fait possible de gérer les pilotes, les micrologiciels et les mises à jour Windows. DataCore publie des packs de mise à jour pour ses produits plusieurs fois par an. Nous apportons donc évidemment des améliorations et lançons même de nouvelles fonctionnalités.
Et puis j'ai vu une question sur les licences. Je m'en charge volontiers. Ça te va, Michael, si je me lance directement dans les réponses ?
M. Chadwell : Ouais, ouais.
M. Hunsaker : Au lieu de prendre le temps de rebondir.
M. Chadwell : Les gens demandent s'ils pourront en obtenir une copie par la suite ; eh bien oui, vous pourrez la télécharger. Continuez.
M. Hunsaker : Bien sûr. Nous facturons donc en téraoctets de capacité utilisable. Ainsi, si vous souhaitez utiliser 50 téraoctets, nous vous proposerons un devis pour 100, car nous répliquons ces 50 sur un autre serveur, ce qui fait un total de 100. En quoi DataCore se distingue-t-il de Datrium ? Datrium est très différent, dans la mesure où ils fournissent un pilote qui met du stockage à la disposition de DM Ware. Nous sommes en mesure de le faire – et je ne pense pas que Datrium en soit capable – : je peux prendre un périphérique Fibre Channel, un périphérique iSCSI et un périphérique de stockage à connexion directe, puis les regrouper tous ensemble. Et comme nous l’avons déjà décrit, nous pouvons ensuite les classer automatiquement par niveau.
Nous lisons, écrivons et mettons en cache dans la mémoire vive ; nous sommes alors capables non seulement de répondre à certaines autres questions qui ont été évoquées — notamment grâce à l’hyperconvergence, que nous définissons comme le fait de fournir du stockage à l’hôte même sur lequel je me trouve —, mais aussi, tout en faisant cela, de mettre ce disque à la disposition d’un environnement externe en même temps, ce que Datrium n’est, je crois, pas en mesure de faire.
Voyons voir.
M. Chadwell : DataCore fonctionne-t-il sur n'importe quel matériel, ou y en a-t-il certains sur lesquels il ne fonctionne pas ?
M. Hunsaker : J'ai vu ça. Oui. Nous fonctionnons donc très bien avec n’importe quel serveur x86. Qu’il s’agisse de Lenovo, Supermicro, HP ou Dell, nous disposons de quelques documents qui indiquent ce qui ne fonctionne pas. C’est probablement une bonne façon de procéder : plutôt que de simplement publier une liste de tout ce qui fonctionne, il est plus facile de repérer les exceptions. Je serai ravi de vous fournir tous les environnements de test dont vous pourriez avoir besoin. Nous proposons une version d’essai du logiciel valable 30 jours et entièrement fonctionnelle.
Nous proposons effectivement des remises aux associations à but non lucratif. Notre site web présente des architectures de référence conçues pour la plupart des fabricants de matériel serveur. Notre solution fonctionne sous Windows Server ; par conséquent, pour fonctionner sous VMware Linux, elle devrait être déployée sous forme de machine virtuelle.
[Ken] Le « provisioning » est en fait une technologie que nous avons inventée et pour laquelle nous détenons un brevet ; donc oui, nous support le « provisioning » support et proposons cette fonctionnalité. En d’autres termes, nos disques virtuels peuvent avoir une capacité supérieure à celle du support physique sous-jacent. Ai-je oublié quelque chose d’autre ? Oui, Kent.
M. Hanson : Puis-je juste ajouter que DataCore – et c’est là que j’ai vraiment adhéré à leur philosophie –, n’est pas un nouveau venu dans le domaine du stockage. Je crois, et corrigez-moi si je me trompe, que tout a commencé à la NASA il y a des années ? Ils ont démarré à la NASA. Je crois que l’ingénieur a commencé à la NASA et a développé le projet à partir de là. Je veux dire, ça existe depuis longtemps.
M. Hunsaker : C'est exact.
M. Hanson : On lui fait vraiment, vraiment confiance.
M. Hunsaker : Michael, y a-t-il des questions auxquelles tu aimerais que je revienne et que j'aurais oubliées ?
M. Chadwell : Oui, tout le monde en recevra un exemplaire. Nos atouts par rapport à nos principaux concurrents. Je vais m’attarder un peu là-dessus. Je pense que vous avez en quelque sorte entendu aujourd’hui que, comme nous sommes une solution purement logicielle, nous pouvons fonctionner sur n’importe quel matériel. Idéalement, cela vous permettra de réaliser des économies. Nous allons certainement vous aider dans ce domaine. L’aspect efficacité dont Kent vient de parler. Des performances accrues, mais surtout – et quelqu’un a posé une question sur les secteurs d’activité où nous réussissons – pratiquement tous les environnements à forte intensité de données.
En particulier tout ce qui est critique, à haute disponibilité ou lié à la continuité d’activité. Quand je pense aux secteurs d’activité, je pense aux hôpitaux, puisque plus de 2 000 établissements s’appuient sur DataCore pour garantir que leurs données soient toujours disponibles et opérationnelles. Lorsque l’ouragan Sandy a frappé, le centre de données d’un de nos hôpitaux a été inondé. Cet établissement se trouve à New York et, heureusement, il disposait d’une architecture active-active : son autre centre de données, situé de l’autre côté de l’Hudson, était pleinement opérationnel.
Cet hôpital continuait d'admettre des patients ; le personnel pouvait réaliser les IRM et gérer toutes les autres interventions chirurgicales, ainsi que les problèmes et complications liés à la tempête. Alors que d'autres établissements étaient à l'arrêt. C'est un phénomène que l'on observe très souvent.
Demandez un devis. N’hésitez pas à nous contacter — je crois que nos coordonnées figurent quelque part ici. Nous ne manquerons pas de vous les envoyer. Elles se trouvent juste ici, sur cette dernière diapositive : info@datacore.com. N’hésitez pas à envoyer un message à n’importe lequel d’entre nous participant à cette webconférence. Pour ma part, mon adresse e-mail est michael.chadwell@datacore.com.
Je voulais aussi aborder… c'était quoi, cette dernière question déjà ? Y a-t-il autre chose que j'aurais dû mentionner là-dessus, Steve ?
M. Hunsaker : Non, je veux dire qu’il y a quelques questions auxquelles nous pourrions probablement répondre. Je ne sais pas si nous savons qui les a posées, mais il y a encore beaucoup de questions auxquelles nous n’avons pas répondu, les amis, et j’apprécie votre contribution. Mon adresse e-mail est steve.hunsaker@datacore.com.
M. Chadwell : Oui, et comme je l’ai mentionné, c’est en quelque sorte le début d’une série web. Alors n’hésitez pas à nous rejoindre pour le prochain épisode. Le 26 février, nous accueillerons un autre client qui vous expliquera comment il utilise DataCore avec un autre de nos partenaires, plus implanté dans le centre du pays, en collaboration avec le cabinet de conseil Customer First Basis. Nous avons hâte de vous retrouver également à cette occasion. Et nous répondrons à toutes les questions supplémentaires posées ici. Vous recevrez une copie de la présentation d’aujourd’hui.
Kent, je ne saurais trop te remercier d’avoir rejoint notre table ronde et d’avoir échangé avec nous aujourd’hui. Jonathan, c’est toujours un plaisir de t’accueillir et j’apprécie tout le travail que tu as accompli à nos côtés au fil des ans. Et Steve, tu nous aides vraiment à asseoir notre expertise dans le domaine du stockage défini par logiciel. Je ne saurais donc pas assez remercier les intervenants pour leur participation aujourd’hui. Et merci à vous tous de nous avoir rejoints virtuellement. J’ai hâte de poursuivre notre collaboration avec vous et de rester en contact. N’hésitez pas à consulter les pièces jointes et les liens disponibles dans le webcast. N’hésitez pas à télécharger certains de ces documents. Pour ceux d’entre vous qui souhaitent obtenir des ressources supplémentaires, nous mettons à votre disposition l’étude de cas ainsi que quelques autres documents plus techniques. Sur ce, je constate que l’heure est venue. Je tiens à vous remercier et à vous souhaiter à tous une excellente rest semaine. À toi, Carlos.
Carlos : J'aimerais vous annoncer le gagnant de la carte-cadeau Amazon d'une valeur de 200 $. Le gagnant est [John Casella], de Pulte Group. Nous vous contacterons prochainement. Encore une fois, merci à tous d'être venus. Passez une excellente journée.
M. Chadwell : Merci à tous.
M. Hunsaker : Génial. Merci à tous.