Transcription de la webdiffusion
Sander Puerto : Bonjour à tous, et merci de vous joindre à nous aujourd’hui. Je m’appelle Sander Puerto. Je suis responsable marketing produit senior chez DataCore, et je serai votre modérateur aujourd’hui. Nous sommes ravis de vous accueillir à cette webconférence, au cours de laquelle vous découvrirez comment RSD a réussi à multiplier par trois les performances de ses sauvegardes et à rendre son système ERP ultra-rapide.
Avant de commencer notre présentation, nous allons rapidement aborder quelques points d’ordre pratique. Passons en revue l’ordre du jour. Nous allons donc commencer par les présentations. Nous aborderons ensuite le problème. Puis nous parlerons de la solution, du déroulement et des résultats obtenus par RSD. Enfin, vers la fin, nous évoquerons brièvement ce qu’est le software-defined storage et pourquoi vous devriez au moins l’évaluer ou y réfléchir — et nous verrons quels sont nos prochains événements à venir. Nous aurons également une session de questions-réponses ouverte à la fin si vous avez des questions supplémentaires. Sachez également que nous offrons une carte-cadeau Amazon d’une valeur de 200 $. Nous tirerons au sort un gagnant à la fin de cette webémission ; je vous recommande donc vivement de rester jusqu’à la fin afin de savoir si vous êtes l’heureux gagnant.
Aujourd’hui, notre table ronde réunit Alan Kerr, architecte solutions senior chez StablePath; Jim Barnes, directeur informatique chez RSD; et bien sûr, moi-même. Je tiens également à vous signaler qu’au fur et à mesure de cette présentation, vous trouverez une section « Téléchargements » ou « Pièces jointes » où vous pourrez télécharger l’étude de cas consacrée à RSD ainsi que les diapositives du webinaire que nous allons passer en revue.
Au fur et à mesure que nous passerons en revue les diapositives, n’hésitez pas à poser vos questions. Jim ou Alan se feront un plaisir d’y répondre dans la mesure où elles concernent leur parcours de réussite spécifique. De plus, une fois la webconférence terminée, vous recevrez un e-mail de BrightTALK contenant un lien vers la version à la demande qui vous permettra de revoir l’enregistrement, si vous le souhaitez. Passons maintenant rapidement à la présentation de RSD. Pour cela, j’aimerais donner la parole à Jim… Jim, tu es là ?
Jim Barnes : Je suis là.
Sander : Jim, pourrais-tu nous parler un peu de RSD ?
Jim : Oui, je m’appelle Jim. Je travaille chez RSD depuis environ 17 ans. Nous sommes un grossiste spécialisé dans la réfrigération et le chauffage, la ventilation et la climatisation (CVC) présent dans plus de 10 États, et nous disposons de 79 sites répartis dans les 10 États de l’Ouest, y compris l’Alaska. Cette entreprise existe depuis 112 ans ; elle a débuté comme fabricant de pianos avant de se tourner vers la réfrigération dans les années 30. Oui, nous nous développons, nous grandissons. Nous nous sommes implantés dans le Colorado il y a quelques années à peine. Grâce aux technologies dont nous disposons, nous avons pu nous développer sur différents marchés et ainsi de suite. Nous sommes une entreprise familiale. Je crois d’ailleurs que le propriétaire actuel représente la quatrième génération. Je suis ravi que vous soyez là pour écouter notre histoire.
Sander : Tout à fait, merci. Excellent. C’est un sacré changement, passer du monde du piano à celui du chauffage, de la ventilation et de la climatisation. C’est vraiment impressionnant. Excellent. Passons maintenant la parole à Alan Kerr pour qu’il nous en dise plus sur StablePath. Alan ?
Alan Kerr : Oui, nous sommes donc une entreprise axée sur l’ingénierie. Nous sommes spécialisés dans les infrastructures hautement performantes et résilientes. Le fondateur de l’entreprise – un ancien directeur informatique – l’a créée vers l’an 2000. Nous mettons en place des infrastructures hautement performantes et résilientes pour des entreprises de toutes tailles, mais ce sont généralement les entreprises de taille moyenne qui occupent la majeure partie de notre temps. Notre siège social est situé en Californie, mais nous intervenons dans tout le pays pour toute entité qui en a besoin. Cela inclut les entreprises, les administrations publiques, les associations caritatives, etc.
Sander : Parfait. Votre siège social se trouve donc en Californie. Avez-vous d'autres antennes ?
Alan : Non, essentiellement parce que les ingénieurs sont toujours en déplacement. Même si le siège se trouve en Californie, ils interviennent toujours sur les sites des clients. Cela peut être n’importe où dans le pays. Nous n’avons donc pas de centres d’activité spécifiques.
Sander : Parfait. Merci, Alan. Maintenant que nous savons exactement qui sont nos intervenants aujourd’hui, nous allons rapidement passer à l’histoire de la genèse de tout cela, à la manière dont ils ont pu trouver la solution la mieux adaptée à leur situation spécifique, et découvrir précisément ce qu’ils ont pu obtenir dès le moment où ils ont déployé cette solution dans leur environnement.
Pour commencer, si j’ai bien compris, le problème était triple, n’est-ce pas ? Il y avait d’une part un problème de performances insuffisantes pour le projet à venir. Vous aviez également besoin d’une certaine flexibilité pour pouvoir mener ce projet à bien. Parallèlement, votre système ERP nécessitait une redondance. Jim, pourriez-vous nous en dire un peu plus à ce sujet, puisque vous avez participé à la recherche de solutions à ces problèmes ? Racontez-nous un peu plus en détail ce qui s’est passé à cette époque.
Jim : Oui, il y a environ 8 ou 9 ans, nous souhaitions vraiment nous lancer dans l’univers virtuel. Compte tenu de la configuration de notre infrastructure de stockage, nous disposions d’un Compellent. Nous avions également un système EMC et utilisions à l’époque une solution de stockage EqualLogic. Le Compellent servait de solution de stockage d’entreprise pour notre système ERP et Exchange. Ce stockage, aussi limité fût-il, nous permettait certes de faire fonctionner notre système ERP et Exchange, mais pour nous développer et commencer à exploiter un environnement virtuel, nous avions vraiment besoin d’augmenter notre capacité de stockage.
Nous avons constaté que nous faisions tourner une grande partie de notre stockage de base sur l’EqualLogic, qui est vraiment lent. Parmi les autres problèmes rencontrés, il y avait le fait que les Compellents disposaient de deux contrôleurs, mais d’un seul espace de stockage en arrière-plan. Ainsi, si cet espace de stockage tombait en panne ou si… nous avons même connu des situations où la défaillance d’un des contrôleurs bloquait l’autre. Cela mettait donc parfois notre stockage de niveau 1 hors ligne.
Nous avons donc commencé à chercher une solution qui nous apporterait la vitesse dont nous avions besoin, le volume de stockage nécessaire à notre environnement ESX, ainsi que la redondance souhaitée : de sorte qu’une panne sur un seul appareil de stockage n’affecterait en rien la production. Alan est donc venu nous présenter l’offre de DataCore. Il nous a fallu un peu de temps pour saisir le principe et en comprendre le fonctionnement, mais une fois que nous avons entamé la migration, la transition s’est avérée très simple. Cela nous a apporté une grande flexibilité. Nous avons ainsi pu disposer de deux appliances de stockage distinctes, configurées en miroir. Même en cas de panne d’une appliance DataCore, le système continuerait de fonctionner normalement.
Cela nous a également permis de passer à l’environnement ESX et de stocker les machines virtuelles sur le système de stockage. Le serveur ESX se connectait en effet par fibre optique aux deux appliances, aux deux baies de stockage, mais pour l’environnement ESX, cela ne représentait qu’une seule appliance. Il était donc sans conséquence de mettre une appliance hors tension. L’autre continuait automatiquement, sans le moindre accroc, à fonctionner et à assurer la continuité de notre environnement. Cela nous a donc apporté une grande flexibilité, par exemple pour effectuer des mises à jour sur les serveurs DataCore.
Cela nous a également permis d’intégrer n’importe quel type de stockage en arrière-plan et de le mettre à disposition, puisqu’il s’agit simplement d’un appareil basé sur une application. On peut en effet lui attribuer n’importe quel type de stockage, et il le gère de la même manière. Grâce à la mise en cache et à toutes les opérations gérées par le serveur DataCore, cela a également accéléré les stockages plus lents. À l’époque, nous utilisions des disques rotatifs, et le système gérait un cache qui donnait l’impression qu’ils étaient bien plus rapides qu’ils ne l’étaient en réalité.
Alan : J’allais justement ajouter quelque chose à ce sujet. J’ai travaillé avec le prédécesseur de Jim sur la mise en œuvre initiale de DataCore, et ils sortaient d’une solution EMC — ils utilisaient EMC depuis un certain temps déjà. Disons simplement que, d’une manière générale, ce n’était pas une expérience très réjouissante. À chaque fois qu’il y avait un problème, ils rencontraient support . Ils avaient des problèmes de disponibilité. Il y avait de nombreux problèmes de ce genre.
À l’époque, lors de la mise en place des premiers nœuds DataCore, leur stockage était très cloisonné. Certaines données se trouvaient sur EMC, d’autres sur Compellent, d’autres encore sur EqualLogic. Non seulement il fallait gérer ces trois ensembles de données distincts, mais il n’existait aucun moyen de transférer les données entre ces différentes plateformes de stockage. En gros, ils devaient arrêter le système et tout copier manuellement. Cela entraînait donc en soi des temps d’arrêt lorsqu’on décidait, par exemple, de transférer des données d’EMC vers Compellent. C’était donc l’autre raison — ou plutôt l’autre problème — qu’ils cherchaient à résoudre. Comment sortir d’un modèle cloisonné où le stockage et les interfaces sont dispersés un peu partout ?
Sander : Oui, parfait. On va donner un peu plus de détails à nos auditeurs sur cette histoire. Et puis, à l’époque, dans le cadre de ce projet, vous essayiez de vous éloigner des serveurs cycliques pour créer quelque chose de plus compact et de le ramener au niveau des hyperviseurs, c’est bien ça ? Donc, ces trois silos de stockage distincts ne constituaient pas les options les plus adaptées à ce que vous cherchiez à faire. C’est bien ça ?
Jim : Oui. La capacité de stockage nécessaire pour faire fonctionner un environnement virtuel est bien supérieure à ce que nous aurions pu nous permettre sur une solution comme Compellent, car on y ajoute… on pouvait s’en sortir avec beaucoup moins. Avec DataCore, on peut utiliser un stockage moins coûteux tout en conservant la redondance et en disposant de la capacité de stockage nécessaire pour faire fonctionner un environnement virtuel. Lorsque l’on exploite 100 serveurs, cela nécessite beaucoup d’espace de stockage. Avec Compellent, le coût associé aurait dépassé ce que l’entreprise aurait réellement souhaité payer.
Sander : À cette époque, aviez-vous déjà mis en place des sauvegardes Veeam?
Jim : Non, c'était bien plus tard. C'était après notre passage à… après avoir virtualisé notre environnement.
Sander : Passons maintenant à la partie « solution », où je sais qu’Alan a participé à ces discussions. Alors, Alan, raconte-nous un peu comment tu voyais les choses quand ils sont venus te voir pour te dire : « Voilà ce que nous essayons de faire, et voici ce que nous voulons réaliser avec un budget de X ». Quelles étaient tes réflexions à ce moment-là ?
Alan : C'était probablement l'inverse. Je les ai vus se débattre et je leur ai fait remarquer que ça ne devait pas forcément se passer ainsi. Au fil du temps… Je veux dire, au début, il y avait… Pour être honnête, il y avait du scepticisme, car EMC est un grand nom. Compellent est une valeur sûre. C’est une marque reconnue. DataCore n’était pas comme ça à l’époque. On a vraiment adopté une approche « c’est à l’usage qu’on voit si ça marche », en commençant modestement. Je crois que ça représentait environ 8 téraoctets en miroir.
Au départ, il s'agissait d'une petite installation que nous avions mise en place. Elle a tellement bien fonctionné que nous y avons migré le système ERP de production, mais nous n'en avions pas parlé au patron. Le système tournait déjà dessus, et il est finalement arrivé et a dit : « D'accord, très bien, tout a l'air en ordre. » « On peut passer au système ERP. » Et on lui a fait remarquer — c’est en fait Jim et moi qui avons effectué la migration — : « Oh, ça fonctionne déjà dessus depuis un jour ou deux. » Il a simplement répondu « très bien » et est reparti.
Il s’agissait donc avant tout pour eux d’analyser leur quotidien, de discuter avec certains de leurs administrateurs et de cerner les problèmes auxquels ils étaient confrontés en matière de disponibilité, support et de performances, puis de mettre au point, disons, une solution modulaire pour commencer. À partir de là, cela a tout simplement évolué pour devenir la manière dont RSD gère désormais le stockage.
Sander : En ce qui concerne le matériel, qu'as-tu choisi à l'époque ?
Alan : Au départ, l’installation comprenait des serveurs Hewlett-Packard avec des baies MSA en arrière-plan. Tout était… les baies MSA n’avaient pas de contrôleurs. En gros, il s’agissait d’un stockage de type JBOD. C’était lors de la mise en service initiale. Ça a fonctionné pendant… sept ans ? Donc la configuration initiale a probablement fonctionné pendant 7 ans. Nous n’avons connu aucune panne pendant cette période. Puis, au cours de la dernière année et demie environ…
Jim : Oui, il y a environ un an.
Alan : Oui, il y a environ un an, nous sommes passés à des serveurs Lenovo et à une solution de stockage Violin en arrière-plan, qui est un ancien flash .
Sander : Tu veux dire que le HP a tenu aussi longtemps ?
Alan : En fait, il est toujours en cours de production.
Sander : Waouh, ça, c'est ce qu'on appelle de la fiabilité.
Jim : Oui, nous avons transféré notre environnement de production, celui que nous utilisions lorsque nous sommes passés à ce matériel, vers… Bon, revenons un peu en arrière, parce que nous avons… nous avons parlé de ce que nous avons ici dans notre environnement de production, mais nous avons également, à Peoria, en Arizona, deux serveurs DataCore, et nous répliquons toutes nos données d’ici vers Peoria. Et cela se fait en temps réel.
Au fur et à mesure qu’un e-mail ou une facture est rédigé(e), ces données sont immédiatement transférées vers notre site de reprise après sinistre. Nous en avons en fait deux là-bas qui fonctionnent en miroir l’un de l’autre. Nous avons donc deux serveurs ici en production qui fonctionnent en miroir l’un de l’autre, et deux autres à Peoria qui fonctionnent également en miroir l’un de l’autre. Nous avons simplement utilisé le matériel que nous utilisions en production et l’avons transféré là-bas, et cela fonctionne à merveille.
Alan : Donc, l’installation initiale comptait deux nœuds du côté production, à savoir les nœuds HP dont nous venons de parler. Du côté distant, il y avait d’anciens équipements Dell qui avaient été mis hors service du côté production et transférés là-bas. Nous avons donc constaté que si nous procédions à des mises à niveau ou à des opérations similaires du côté distant, la reprise après sinistre s’interrompait évidemment dans ces cas-là. Nous avons donc décidé, lors de la mise en place des nœuds côté production, de récupérer ce matériel qui, de toute évidence, assurait encore l’ensemble du service jusqu’au moment où nous l’avons remplacé, et de l’affecter au côté reprise après sinistre. Désormais, lorsque nous effectuons des mises à jour d’un côté ou de l’autre, nous ne mettons pas l’environnement hors service. L’environnement reste opérationnel 24 heures sur 24, 7 jours sur 7, que nous effectuions de la maintenance ou toute autre opération, pour ainsi dire.
Jim : L’autre élément qui, selon moi, a facilité ma vie en tant qu’administrateur de ce système, c’est que nous pouvons… vous savez, comme pour n’importe quel logiciel, comme pour n’importe quel type de serveur, les serveurs doivent être mis à jour. Ceux-ci fonctionnent sous Windows ; nous utilisons donc Windows Server 2016, sur lequel tourne DataCore. Nous devons effectuer les mises à jour Windows, comme nous le savons tous. Nous devons également effectuer les mises à jour de DataCore. Nous pouvons réaliser ces mises à jour, et c’est d’ailleurs ce que nous faisons au cours de la journée. Nous mettons l’un des serveurs hors ligne, arrêtons le service DataCore, et l’environnement serveur ne s’en rend absolument pas compte. L’environnement ESX n’en a pas le moindre soupçon. Quant à notre système ERP, rien ne se rend compte que nous avons mis l’un de ces nœuds hors ligne lorsque nous procédons ainsi. Nous effectuons ces opérations pendant la journée : nous installons nos mises à jour Windows, nos mises à jour DataCore, puis nous remettons les serveurs en ligne. La synchronisation s’effectue, et tout fonctionne à nouveau comme si de rien n’était. Cela réduit considérablement le temps que votre personnel doit passer au bureau après les heures de travail et les heures supplémentaires. C’est donc un autre avantage concret pour mon équipe : nous n’avons plus à travailler aussi tard le soir.
Sander : C'est une bonne chose, non ? Un énorme avantage.
Alan : Je veux dire, ça fait bientôt 9 ans que notre système de stockage de production fonctionne sans interruption.
Jim : Oui, depuis que nous avons ces baies de stockage, je n’ai jamais subi de perte… ou plutôt, les deux nœuds ne sont jamais tombés en panne en même temps. Du coup, il y a toujours un nœud de stockage disponible à un moment ou à un autre.
Sander : Parfait. Vous disposez donc actuellement de deux copies en production, et vous en avez également deux en reprise après sinistre. C'est bien ça ? Vous disposez donc de quatre copies de vos données ?
Jim : Exact.
Sander : En plus des sauvegardes ?
Jim : Oui, et on utilise aussi Veeam pour effectuer des sauvegardes sur disque, puis on transfère ces données du disque vers des bandes.
Alan : Nous disposons donc de données en continu.
Jim : Et puis nous avons la protection continue des données, qui fonctionne sur DataCore. La protection continue des données vous permet, faute d’un meilleur terme, d’effectuer des retours en arrière. Elle vous offre une période donnée — donc, tout dépend de la capacité de stockage que vous y consacrez. Elle vous permettra de disposer d’une période allant d’un jour à cinq jours, ou de la durée que vous lui attribuez, pendant laquelle vous pouvez sélectionner un moment précis, revenir en arrière et créer un snapshot et une copie de ce volume à partir de ce moment précis, puis de le restaurer à partir de là. Par exemple, en cas d’attaque par ransomware — lorsque vos données sont chiffrées —, vous pouvez revenir à un état antérieur à l’attaque, et vos données sont alors à nouveau accessibles.
Alan : Comme ça, on ne finit pas comme Baltimore.
Sander : C'est parfait. J'ai ici une question du public. La question est la suivante : « À quelle distance se trouve votre site de reprise après sinistre de votre site de production ? »
Jim : Ça fait environ 350 à 400 miles. C'est la distance entre Peoria, en Arizona, et Lake Forest.
Sander : Quel type de connexion avez-vous entre les deux sites ?
Jim : Pour l'instant, nous utilisons une liaison MPLS de 50 mégaoctets, et nous réutilisons les Steelheads de Riverbed pour la déduplication.
Alan : Et nous envisageons également de changer cela.
Jim : Oui, je m’apprête justement à étudier une autre façon de procéder. Nous envisageons de mettre en place une connexion de couche 2 entre les sites, en augmentant la bande passante à 200 Mo, puis d’y installer un Riverbed Steelhead plus puissant pour gagner en débit.
Alan : Cela nous permettra, à l'avenir, de faire tourner des machines virtuelles de part et d'autre à tout moment, selon nos besoins.
Jim : Oui, on pourrait en fait continuer à faire tourner des environnements de production sur notre site de reprise après sinistre. Ça nous offre donc cette véritable…
Sander : On se retrouve donc désormais dans un environnement multisite à haute disponibilité.
Alan : Oui, c'est vers ça qu'on se dirige ; l'idée, c'est que peu importe le côté sur lequel une machine virtuelle est en train de tourner.
Sander : Parfait. Autre chose : en ce qui concerne la bande passante dont vous disposez et les données qui changent quotidiennement pour que cette réplication puisse avoir lieu, comment cela se passe-t-il ?
Jim : Oui, comme je l’ai dit, ça se passe en temps réel. Dans DataCore, il y a d’ailleurs un petit indicateur qui montre : « Bon, on vous envoie tant de données, et voici le temps de latence que vous avez. » En général, la latence ne dépasse jamais 2 ou 3 secondes. Le seul moment où vous allez constater un décalage, c’est lorsque vous lancez une nouvelle réplication, ou par exemple lorsque vous mettez un nœud hors service pour y effectuer des mises à jour : vous remarquerez alors que vous pouvez observer la vitesse à laquelle la réplication reprend et le volume de données concerné. C’est donc à ces moments-là que vous le remarquerez, mais en temps normal, vous pouvez consulter cet indicateur et il n’y a jamais de décalage.
Alan : On a justement eu cette discussion ce matin, alors qu’on étudiait la mise en place de la connexion de couche 2 et qu’on essayait de déterminer le volume de bande passante utilisé. Le volume… Je veux dire, au cours des quatre dernières semaines, le volume de données que le système de stockage a transmis, ou a tenté de transmettre, via la ligne de 50 mégas, dépassait à peine les 20 téraoctets. Grâce aux appliances de déduplication et à quelques modifications apportées du côté de DataCore pour optimiser la déduplication, nous avons économisé environ 18,5 téraoctets sur cette ligne. Nous n’avons donc transmis que 1,4 téraoctet au cours des quatre dernières semaines. Grâce au taux de déduplication que nous obtenons et à l’efficacité avec laquelle DataCore permet cette déduplication, c’est ce qui nous procure cette sensation de temps réel sur les… vous savez, c’est pourquoi il n’y a jamais aucun décalage sur aucun des volumes.
Sander : J’ai une autre question à vous poser à ce sujet. On constate ici beaucoup de redondance entre la haute disponibilité sur site, les solutions de reprise après sinistre, la protection continue des données (CDP) et les sauvegardes allégées. Jim, pourriez-vous peut-être nous expliquer pourquoi il est si crucial pour votre entreprise, pour votre organisation, de disposer de plusieurs copies de vos données ? En quoi cela profite-t-il à votre modèle économique ?
Jim : Ce qu’on sait, c’est qu’il existe de nombreuses façons différentes pour que vos données vous lâchent. Il n’y a pas qu’une seule solution pour la sauvegarde et la restauration. Vous disposez de nombreuses options différentes. Comme je l’ai dit, si vous êtes victime d’un rançongiciel, vous aurez intérêt à utiliser la protection continue des données (CDP) pour revenir à un état antérieur. Si vos données sont corrompues, vous pouvez utiliser la sauvegarde Veeam pour les restaurer — à condition que le délai de restauration ne soit pas critique.
L’autre point, c’est qu’en cas de catastrophe réelle, les données que vous avez ici, au siège de votre entreprise, vont… il faut partir du principe qu’elles seront perdues. Et pour certaines choses, vous devrez peut-être remonter jusqu’aux bandes. Si vous envisagez l’archivage, vous devez gérer des données financières ou similaires, pour lesquelles vous avez besoin de récupérer des informations datant de sept ans et que vous ne stockez d’aucune autre manière. Vous devrez alors vous rabattre sur les bandes. C’est pourquoi il est important de disposer de ce que j’appelle une architecture à trois niveaux. Je pense que ce modèle est utilisé pour… vous souhaitez conserver la copie originale. Vous souhaitez la stocker sur disque, et vous souhaitez la stocker sur bande. Avec DataCore, vous disposez d’une quatrième option : la protection continue des données (CDP), qui permet la restauration. C’est une fonctionnalité qui sera utilisée pour une restauration à court terme, car vous ne pourrez pas récupérer l’intégralité d’une semaine ni d’un mois. Vous pourrez récupérer des données sur quelques jours, voire une semaine.
Chaque situation de restauration est unique, et vous devez être prêt à y faire face. Vous devez vous préparer à toutes ces situations afin de restaurer vos données de la manière la plus efficace possible. La restauration à partir d’une bande prendra une éternité, alors qu’avec la solution de sauvegarde Veeam, la technologie CDP ou les snapshot(vous pouvez également créer snapshots cet outil), c’est tout autre chose. Ainsi, avant de lancer un projet ou d’effectuer une mise à niveau, vous pouvez snapshot créer un snapshot . Si quelque chose ne se passe pas comme prévu, il vous suffit de revenir en arrière à partir de cet snapshot, et vous retrouvez la situation initiale. Chaque scénario présente ses propres défis, et il est absolument indispensable de disposer de ces différentes méthodes de sauvegarde et de restauration.
Alan : J’ai d’ailleurs dû aborder cette question lorsque nous avons parlé pour la première fois de DataCore, de la mise en miroir, de l’ajout du CDP et de certaines de ces autres fonctionnalités. En réalité, si je les mets en miroir, je prends à nouveau la même quantité d’espace. Si j’utilise la CDP, j’occupe désormais un pourcentage supplémentaire d’espace. La question qui se posait donc avant que cela ne soit mis en place — et c’était encore une fois avant que Jim ne prenne la relève — était la suivante : pourquoi ai-je besoin de toutes ces copies de mes données ? Ma réponse à l’époque était que c’est la seule chose que la compagnie d’assurance ne peut pas vous rendre. Elle peut vous fournir davantage de logiciels et de matériel. Elle peut vous fournir un autre bâtiment. Elle peut vous fournir des serveurs. Elle peut vous donner l’argent nécessaire pour conclure un contrat pour une nouvelle ligne de communication. Mais la seule chose qu’elle ne peut pas vous donner, ce sont vos données. Soit vous les avez, soit vous ne les avez pas.
La politique à partir de là est la suivante : tout ce qui se trouve dans cet environnement est mis en miroir. Nous en disposons au moins d’une autre copie physique au sein de l’environnement. Ensuite, il faut déterminer si ces données sont gérées par un CDP, si elles sont archivées sur bande ou si elles font l’objet d’une sauvegarde. Quelle est l’importance de ces données ? Mais le minimum requis est qu’elles soient mises en miroir.
Jim : Oui, je me souviens justement d’un cas. Ça s’est passé il y a environ 5 ou 6 ans. Nous avions l’un de nos volumes Exchange. En fait, nous gérons environ 5 bases de données différentes pour notre Exchange, et l’une de ces bases de données — une seule — a été corrompue. Une fois que nous avons identifié le problème, nous avons pu effectuer une restauration sur ce volume de base de données uniquement, car nous les avions séparés dans DataCore : chaque base de données dispose de son propre volume. Nous avons pu restaurer snapshot et snapshot créer un snapshot , puis reconnecter la base de données à Exchange avant même d’en disposer d’une copie complète, et nous avons pu remettre cette base de données en ligne pendant qu’elle était en cours de réécriture vers la copie complète.
Une fois snapshot créé, il doit évidemment passer par un processus pour devenir une base de données active à part entière, et non pas simplement un snapshot. Nous avons pu associer snapshot serveur Exchange avant même que ce processus ne soit terminé, puis laisser le processus s'exécuter en arrière-plan. Nous avons ainsi pu récupérer la base de données dès que nous avons constaté qu'elle était corrompue — et que nous devions effectuer une restauration en moins de 5 minutes.
Alan : De plus, nous avons constaté que nous n’avions perdu aucune donnée en procédant ainsi. Entre le moment où nous avons pris la décision de revenir en arrière — c’est-à-dire de restaurer la version précédente et de supprimer la version corrompue — et la fin de l’opération, je pense que cela a pris environ 5 minutes.
Sander : Donc, si je comprends bien, vous n’avez pas eu besoin d’utiliser votre sauvegarde Veeam ; vous avez plutôt utilisé la technologie CDP de DataCore ?
Jim : Oui, pour ça, on a utilisé DataCore CDP, parce qu’on savait que — encore une fois — si on avait dû revenir à un autre produit, on aurait perdu des données à ce moment-là, puisqu’on aurait dû revenir à l’état de la veille au soir. Tous les e-mails reçus ce matin-là, avant la corruption, auraient été perdus.
Alan : Oui, Veeam n'offrait pas une granularité suffisante.
Jim : Oui, ça nous ramène à la même question : pourquoi disposer de toutes ces solutions de sauvegarde différentes ? Eh bien, chacune présente ses propres avantages, et la technologie CDP nous a permis de déterminer à quel moment la corruption avait commencé, de revenir à un état antérieur à cet incident, et ce, sans perdre aucun des e-mails reçus ce matin, avant que la corruption ne se produise.
Sander : Excellent. J’adore ça. C’est vraiment impressionnant, car la plupart des centres de données — ou plutôt, la plupart des administrateurs informatiques — auraient immédiatement dû recourir à la sauvegarde de ce matin-là, et comme vous l’avez dit, ils auraient perdu plusieurs heures de données. C’est donc formidable d’entendre cela. Une autre chose rapidement : vous aviez évoqué l’histoire d’un électricien qui avait commis une erreur lors d’un recâblage. Pouvez-vous nous en dire un peu plus sur la façon dont cela s’est passé et nous dire si DataCore vous a permis de rester opérationnel ou non ?
Jim : Oui, dans cette situation, nous avions un électricien sur place qui s’occupait du câblage. On l’appelle « Sparky » maintenant. En fait, il était en train d’ajouter des prises électriques, et il a fait sauter environ la moitié des disjoncteurs de notre centre de données. Cela a mis hors service une partie assez importante du système. Grâce à la façon dont nous avons séparé les DataCores dans le centre de données — évidemment sur des disjoncteurs différents et dans des zones distinctes du centre —, nous avons pu… Je crois que l’un d’entre eux est tombé en panne, mais l’autre est resté opérationnel. Ainsi, en ce qui concerne ces données — nous n’avons jamais connu de situation —, pour revenir à ce que je disais, nous n’avons jamais connu de situation où les deux serveurs DataCore se sont retrouvés hors service en même temps. Nous avons donc pu rétablir l’alimentation et le remettre en service. Une fois remis sous tension, il s’est resynchronisé avec le DataCore qui était resté opérationnel, sans aucune perte de données ni aucune conséquence durable.
Sander : C'est génial. Maintenant, si vous aviez subi une interruption de service pendant 5 ou 6 heures, quelles en auraient été les conséquences pour votre entreprise ? Comment cela aurait-il affecté votre activité ?
Jim : Eh bien oui, je pense que si les agences ne peuvent pas passer de commandes ni aider les clients, cela a toujours un coût financier — et pas seulement financier. Tu sais, c’est aussi une question de confiance avec tes clients. Quand ils viennent dans une agence, ils veulent être sûrs de pouvoir obtenir ce dont ils ont besoin. Il y a donc une question de confiance : il faut que tout fonctionne correctement et qu’on soit en mesure d’aider ses clients.
Sander : Parfait. Je vous remercie pour toutes ces précisions. J'ai une autre question du public concernant le processus de migration. On me demande dans quelle mesure la migration de l'ancien système de stockage vers DataCore s'est avérée difficile ?
Jim : Le processus à suivre lorsque vous migrez des données depuis n’importe quel système de stockage vers DataCore consiste essentiellement à mettre ce stockage à la disposition de DataCore, puis à passer en mode « passthrough ». Cela vous permet de transférer ces données vers DataCore pendant cette opération ; les données transitent effectivement par DataCore, mais elles restent sur le système de stockage d’origine. Ensuite, vous les répliquez sur un autre serveur, puis vous effectuez la bascule de l’ancien système de stockage vers le système répliqué, un peu comme lorsque l’on arrête un serveur pour en démarrer un autre — il s’agit d’une réplique de celui-ci. Puis vous les répliquez à nouveau vers la deuxième copie. Nous avons en fait effectué la migration sans interruption : les systèmes n’ont jamais été hors service pendant la migration. Nous n’avons jamais eu à arrêter quoi que ce soit pour effectuer cette migration. Tout s’est donc déroulé alors que nos systèmes étaient en service.
Alan : Tout ça s'est passé pendant la journée.
Jim : Tout ça se passe pendant la journée.
Sander : Waouh, c’est vraiment impressionnant. C’est incroyable toutes ces histoires que nos clients nous racontent sans cesse. Elles sont tout simplement impressionnantes. Et vous entendre parler de tout cela me rappelle les avantages concrets : au-delà de la technologie, ce sont les avantages que nous sommes en mesure d’apporter à nos utilisateurs finaux, non seulement pour améliorer le fonctionnement de leur entreprise, mais aussi pour vous faciliter la tâche. Merci donc pour tous ces retours.
Passons à la diapositive suivante. Si Alan pouvait — ou si vous deux pouviez — nous en dire un peu plus sur chacun de ces points, ce serait rapide. Vous disposez désormais d’une plateforme unique qui prend en charge tous vos services de données, alors qu’auparavant, vous aviez plusieurs silos. Et vous obtenez ces performances malgré une distance de 400 miles entre les sites. Parlez-nous un peu plus en détail de ces performances pour votre ERP. En quoi se sont-elles améliorées ?
Alan : L’un des changements intervenus au fil du temps est que le système ERP fonctionnait auparavant sur son propre serveur dédié, tandis que le stockage était géré par DataCore. Avant cela, il reposait sur les solutions EMC et Compellent dont nous avons parlé. L’un de nos objectifs était de nous assurer que la base de données sous-jacente au système ERP soit une base de données Progress. Nous voulions garantir que, si nous migrions cette base vers une machine virtuelle, elle fonctionnerait correctement.
À un moment donné, la décision a été prise : RSD a fait appel directement à Progress pour qu’ils viennent effectuer un test comparatif. Les résultats — et j’ai d’ailleurs déjà vécu cela avec un autre client qui utilisait Progress dans le même environnement — ont suscité dans les deux cas la même réaction : « Comment avez-vous obtenu ces chiffres ? Parce que nous ne voyons jamais de chiffres comme ceux-là. » « Que faites-vous pour obtenir une telle rapidité ? » Cela a donc été en quelque sorte le feu vert pour aller de l’avant et faire passer le système d’un serveur physique dédié (bare metal) à la virtualisation, pour aboutir à la configuration actuelle.
Sander : Alan, de qui venait ce commentaire ? Du fournisseur du logiciel ?
Alan : Oui, le fournisseur de bases de données, qui était Progress. Ils se demandaient comment nous parvenions à atteindre de tels chiffres, car lorsqu’ils examinent ce genre de choses ailleurs, ils n’ont jamais vu de chiffres pareils auparavant. J’ai d’ailleurs entendu ce commentaire de la part d’un autre client qui avait effectué le même test directement avec Progress. Nous n’étions pas impliqués dans ce test. C’était eux qui effectuaient les tests qu’ils réalisent habituellement, notamment des tests de charge.
Sander : Tu te souviens peut-être des chiffres, par hasard ?
Alan : Non, ça remonte à plusieurs années maintenant.
Sander : Ça remonte à un bon moment. Parfait. Jim, on a un peu parlé de Veeam. Peut-on approfondir un peu ce sujet ? Si j’ai bien compris, vous n’utilisiez pas Veeam au départ, mais vous l’avez acquis par la suite. Sur quel type de support effectuiez-vous vos sauvegardes ?
Jim : Oui, quand on a commencé à utiliser Veeam, on se servait d’un stockage peu coûteux et on y effectuait simplement les sauvegardes. Au cours de ce processus de mise à niveau, on a décidé d’utiliser — on disposait de matériel supplémentaire issu de notre infrastructure de production lors de la mise à niveau — un serveur en plus et un peu de stockage. Nous avons décidé d’essayer d’utiliser DataCore pour effectuer les sauvegardes Veeam sur une plateforme DataCore, au lieu d’utiliser, si je me souviens bien, un stockage JBOD, le Synology. Une fois que j’ai fait appel à la personne qui s’occupe des sauvegardes Veeam pour moi — elle connaissait très bien les chiffres et a analysé le temps nécessaire pour effectuer les sauvegardes sur le stockage Synology —, dès que nous avons commencé à les effectuer sur DataCore avec toutes ses fonctionnalités…
Alan : Le principal avantage, c'était la capacité de mise en cache, qui permettait d'ingérer les données beaucoup plus rapidement. Je crois que la vitesse avait triplé quand on a examiné la question.
Jim : Ouais, c'est ce qu'on a fait. Il a dit que les sauvegardes étaient environ trois fois plus rapides sur ce serveur que sur le Synology.
Alan : Et il avait toutes les données. Il nous a présenté le tout sous forme de graphique, car il travaillait là-dessus et avait effectué différents types de sauvegardes Veeam à partir de plusieurs machines. Il a en quelque sorte dressé un large panorama des différentes méthodes utilisées pour les sauvegardes de production, et le résultat était nettement plus rapide. La décision finale a donc été de simplement laisser le tout sur ce nœud DataCore distinct.
Le matériel provient de l'époque où nous avons expédié, disons, l'ancien équipement de production vers le site de reprise après sinistre. Nous n'avons pas expédié toutes les baies, mais nous n'avions pas besoin d'autant d'espace sur le site de reprise après sinistre. Nous avons donc en quelque sorte récupéré cet équipement et l'avons placé derrière ce nœud, essentiellement pour en faire une cible de sauvegarde. Quant aux licences, nous les avons simplement étendues un peu et avons intégré cet équipement en tant que nœud.
Aujourd’hui, la gestion des licences est assez simple, car tout dépend uniquement de l’espace dont on dispose. C’est tout. C’est la seule question à se poser. Ainsi, lorsque nous atteignons un seuil élevé — c’est-à-dire un seuil fixé en interne qui indique que nous avons besoin de plus d’espace —, nous passons simplement commande pour obtenir davantage de licences.
Sander : D’un point de vue matériel, faut-il acheter un autre boîtier ? Comment ça marche ?
Alan : Du côté de la production, toutes les données traitées par Violin font l’objet d’une déduplication. Nous devons donc toujours acquérir des licences DataCore à mesure que nous ajoutons des ressources, mais en arrière-plan, comme les données sont dédupliquées, la croissance est extrêmement lente. Nous ne prévoyons donc pas de changements avant longtemps, du moins de ce côté-là. Donc, si nous devons ajouter quelque chose, ce sera uniquement DataCore, c’est-à-dire les licences logicielles. En ce qui concerne la sauvegarde, je ne pense pas que nous ayons besoin de plus, mais si c’était le cas, nous achèterions simplement une autre baie de type JBOD et nous la brancherions à l’arrière — c’est probablement ainsi que nous procéderions.
Jim : Oui, si vous manquez d’espace de stockage, et qu’il s’agit d’un système traditionnel à disques rotatifs, vous devez évidemment ajouter du matériel. L’avantage avec DataCore, c’est que vous pouvez ajouter… vous pouvez faire fonctionner… nous utilisons des D2700. Vous pouvez ajouter une baie de stockage différente, et DataCore ne se soucie pas de savoir de quel type il s’agit. Il suffit de le lui présenter, et il s’en charge. Peu importe donc que vous utilisiez un système de stockage HP ou EqualLogic. Vous pouvez y associer un Compellent. Vous pouvez y associer un EMC. Vous pouvez y associer tout ce que vous voulez. Il le gérera de la même manière. Grâce à sa fonctionnalité de mise en cache, même s’il s’agit d’un stockage lent, il va l’accélérer.
Alan : Il y a toutefois une chose à noter quand on compare l’environnement de production actuel à l’ancien. Ce qu’il faut retenir, c’est qu’on ne s’en tire pas vraiment à bon compte, n’est-ce pas ? Le nouvel environnement de production, équipé exclusivement de SSDs nettement plus vite que l’ancien, car l’un de nos administrateurs a fait remarquer que tout était « ultra-réactif ». Or, c’est quelqu’un qui ne fait pas ce genre de commentaires à la légère.
Le DataCore donne de bons résultats lorsqu’on l’utilise avec du matériel de bonne qualité, et s’il est associé à du matériel haut de gamme, il est tout simplement excellent. L’environnement actuel dont ils disposent – comme je l’ai dit, nous ne prévoyons pas de l’étendre avant un certain temps, tout simplement parce que nous disposons déjà de performances amplement suffisantes et d’un espace de stockage suffisant. Si nous devions l’étendre, ce serait uniquement pour des raisons d’espace. Ce n’est certainement pas une question de performances. Nous pourrions le charger bien, bien plus qu’il ne l’est aujourd’hui.
Sander : Donc, si je comprends bien, selon le cas d'utilisation, il faut investir dans le matériel adapté pour répondre à ces besoins, c'est ça ?
Alan : Exactement. Par exemple, si l’on prend le volet « sauvegarde » dont nous parlons, il s’agit évidemment de matériel bien moins performant que le reste, mais grâce au logiciel DataCore, il s’avère très performant, d’autant plus qu’il est spécialement conçu à cet effet et que le RAID et tous les autres composants sont intégrés de manière à ne servir qu’aux sauvegardes. Cela fonctionne donc très bien dans cet environnement et s’avère rentable.
Côté production, on y a intégré des éléments sans doute plus performants. Cela signifie qu’on n’aura pratiquement jamais à discuter des performances pour se demander pourquoi quelque chose est lent. C’était en gros ce qu’on souhaitait éviter : que la seule question qui se pose soit « avons-nous assez d’espace ? ». Et c’est ainsi que le système a été conçu.
Sander : Parfait. En ce qui concerne votre connexion Internet au cours de ces neuf dernières années, quelle connexion utilisez-vous ?
Jim : Chez DataCore, on a toujours utilisé Fibre Channel. Oui, on fonctionne en 8 gig.
Sander : Entre DataCore et votre hôte ESX, quel type de connexion utilisez-vous ?
Jim : C'est aussi des fibres.
Sander : Parfait. Donc oui, vous disposez clairement d'une infrastructure solide qui vous offre tout le débit dont vous avez besoin.
Alan : Eh bien, l’une des raisons pour lesquelles nous avons opté pour la fibre optique, c’est que nous ne serions plus jamais obligés de nous demander pourquoi un système fonctionne ou ne fonctionne pas, car Fibre Channel fonctionne Fibre Channel .
Sander : En tout cas, pour ma part, c'est ce que je préférerais toujours, mais on constate que iSCSI tout aussi bien, n'est-ce pas ? Encore une fois, tout dépend du type de…
Alan : Dans l’environnement DataCore, nous avons mis en place iSCSI à partir de certains volumes, comme par exemple les postes de travail des administrateurs. Nous y transférons des fichiers et ce genre de choses. Nous le faisons donc de temps à autre, mais d’un point de vue de la production – si l’on parle uniquement de connectivité de production –, dans cet environnement, tout fonctionne Fibre Channel. Nous utilisons iSCSI nous avons besoin d’un peu d’espace supplémentaire de manière temporaire. Historiquement, cela servait également à certaines tâches administratives que nous effectuions pour fournir de l’espace aux administrateurs.
Sander : J'ai une question à ce sujet, et peut-être qu'Alan pourra y répondre. Sur quelle plateforme d'exploitation DataCore fonctionne-t-il ? S'agit-il de Linux, de Windows ou d'un système propriétaire ?
Alan : Il fonctionne sous Windows, et la raison en est que c’est le seul noyau temps réel disponible — du moins, disponible dans le commerce. Linux ne dispose pas d’un noyau temps réel, c’est pourquoi nous ne l’utilisons pas aujourd’hui. Cela pourrait changer à l’avenir, lorsque ce type de noyau sera disponible. De plus, si vous disposez d’un serveur Windows, il n’existe aucun périphérique de stockage au monde avec lequel il ne fonctionnerait pas. Vous bénéficiez donc d’une flexibilité totale quant aux composants que vous souhaitez y associer. Nous disposons désormais de cette option, que nous pouvons envisager lorsque nous cherchons à étendre ou à modifier n’importe quel aspect matériel du système.
Sander : Merci pour cette réponse. Passons rapidement à la diapositive suivante pour aborder les résultats — je vais juste vous en faire un bref résumé. Vous avez ainsi pu bénéficier de cette flexibilité pour continuer à utiliser certaines des solutions de stockage les plus récentes sur le site de reprise après sinistre, réaliser tout ce que vous souhaitiez sur votre site de production, disposer de toute la redondance nécessaire et optimiser la rentabilité de votre investissement dans les baies de stockage. Dans l’ensemble, il semble que nous ayons pu répondre à tous vos besoins. Souhaitez-vous ajouter quelque chose, Alan ?
Alan : Non. Je pense qu’à un moment donné, nous avons répondu à des besoins dont on ne savait même pas au départ s’ils étaient réalisables. Par exemple, la restauration des données sans aucune perte. Avant même que nous activions le CDP, on partait du principe que, en cas de corruption, il y aurait forcément des pertes, car il fallait remonter à un autre moment dans le temps, que ce soit snapshot un snapshot une restauration à partir d’une bande snapshot tout autre mécanisme issu de la sauvegarde de la veille. Beaucoup de ces éléments sont désormais devenus des exigences qui n’existaient pas au départ.
Sander : Parfait. Il y a ici une question concernant Veeam. Jim, tu pourrais peut-être y répondre ? Je connais la réponse, mais je te laisse t'en charger. Il nous reste 8 minutes, donc si tu pouvais prendre quelques secondes pour y répondre… La question est la suivante : « Sur quoi as-tu fondé ta décision d'opter pour Veeam plutôt que pour d'autres solutions ? »
Jim : Je crois qu’avant, nous utilisions… En fait, nous utilisons deux solutions distinctes… Nous utilisions aussi Backup Exec. Nous avions en réalité un environnement mixte, mais une fois que nous sommes passés au virtuel — une fois que notre environnement est devenu virtuel à 99 % —, la flexibilité de Veeam et certaines de ses fonctionnalités… Par exemple, nous utilisons également Veeam pour répliquer des machines virtuelles à Peoria. Ainsi, tout en utilisant DataCore pour transférer les données vers Peoria, nous utilisons également Veeam pour répliquer l’intégralité de la machine virtuelle à Peoria, ce qui nous permet de la disposer dans un environnement virtuel sur un serveur ESX, prête à être mise sous tension, mais restant pour l’instant en état d’arrêt. Veeam nous offre donc cette possibilité de disposer de ces serveurs. Certes, ce n’est pas en temps réel comme avec DataCore, mais pour les serveurs dont les données ne changent pas beaucoup — comme les serveurs d’impression et ce genre de choses —, nous utilisons cette solution. Nous nous en servons.
Le serveur est là, prêt à être mis sous tension. C’est d’ailleurs l’une des fonctionnalités que nous apprécions particulièrement. Et il est également très performant en matière de déduplication. Cela permet donc de réduire considérablement l’espace de stockage nécessaire aux sauvegardes. Mais oui, c’est un excellent produit pour nous. Nous trouvons qu’il est bien meilleur que Backup Exec, que nous utilisions auparavant.
Sander : Super. Merci pour cette réponse, Jim. On dirait que c'est un excellent duo : Jim s'occupe de la machine virtuelle et DataCore gère les téraoctets de données. Ils se complètent donc parfaitement.
Jim : Bien sûr, bien sûr. Ouais.
Sander : Très bien, parfait. Je vais rapidement aborder — vous savez, juste pour approfondir un peu plus ce software-defined storage . Concrètement, ce que nous faisons, c’est créer une couche d’intelligence qui vous permet d’activer tous ces services de données dont votre matériel traditionnel ne dispose probablement pas de manière native. Ainsi, non seulement vous disposez désormais de tous ces services de données, mais ceux-ci s’appliquent à n’importe quel stockage physique sous-jacent à DataCore. Vous pouvez désormais gérer l’ensemble de votre stockage à partir d’un tableau de bord unique. Cela concerne non seulement la gestion et les services, mais aussi la possibilité de regrouper toutes vos baies.
Comme vous l’avez entendu dans le récit de Jim, nous créons plusieurs copies redondantes — qu’il s’agisse de 2 ou de 3 copies, que vous souhaitiez disposer d’un plan de reprise après sinistre sur un site physique ou dans le cloud— et nous prenons en charge toutes ces options. Nous vous offrons cette flexibilité, et ce sont des fonctionnalités qui ont fait leurs preuves. Jim a évoqué la CDP et quelques autres solutions. C’est donc sans aucun doute un sujet que j’encourage tout le monde ici à évaluer.
Nous sommes présents sur le marché depuis maintenant 20 ans et comptons plus de 10 000 clients à travers le monde. Nos clients nous restent fidèles, avec un taux de renouvellement de 95 %. Si vous souhaitez venir découvrir la Floride ensoleillée, sachez que notre siège social se trouve à Fort Lauderdale. Nous serions ravis d’échanger avec toute personne susceptible de tirer profit de nos services. Nous adorons aider nos clients. C’est notre métier, et c’est pourquoi nous avons remporté cinq fois le prix du produit de stockage de l’année. Si vous souhaitez obtenir plus d’informations, n’hésitez pas à nous envoyer un e-mail à l’adresse info@datacore.com.
En fait, laissez-moi vous expliquer rapidement ce point. Nous pensons que le stockage a la capacité d’évoluer, n’est-ce pas ? Eh bien, software-defined storage cette évolution et vous offre la flexibilité nécessaire pour faire évoluer votre environnement à partir de différents emplacements, selon différents deployment et différentes architectures, tout en continuant à utiliser le même logiciel, à savoir celui de DataCore.
Je vous rappelle que vous avez la possibilité de télécharger ces présentations ; vous pourrez ainsi consulter ces diapositives et voir si cela peut vous aider dès maintenant dans votre situation actuelle. Voici quelques citations de Jim. Je tiens à vous remercier tous les deux — Jim et Alan — d’être ici aujourd’hui. J’apprécie beaucoup toutes vos contributions.
Bon, passons maintenant à la désignation du gagnant. Il nous reste encore 3 minutes, et nous allons désigner un gagnant. Donnez-moi juste quelques secondes. Voyons qui est l'heureux gagnant d'une carte cadeau Amazon d'une valeur de 200 $. C'est Railene Schubert qui remporte ce prix. Vous recevrez un e-mail contenant toutes les informations nécessaires pour télécharger cette carte cadeau. Toutes mes félicitations à vous.
Encore une fois, si ces témoignages vous plaisent, je vous encourage à continuer à participer à tous ces webinaires. Le prochain aura lieu le 26 mai à 14 h. Nous recevrons notre partenaire de Tri Delta. Nous parlerons du YMCA de Long Island et découvrirons son histoire. Elle sera très probablement très différente de celle de Jim, mais vous devez absolument être présents si vous voulez voir exactement ce que DataCore apporte à ces organisations.
C'est encore une fois Sander, de DataCore, qui vous parle. N'oubliez pas que vous pouvez télécharger à la fois la présentation et l'étude de cas. Il vous suffit de vous rendre dans la section « Pièces jointes » pour les télécharger. Merci de votre attention. À la prochaine, et bonne journée.