Transcription de la webdiffusion
Je pense que le public trouvera cela très d'actualité. C'est généralement le cas… en tout cas, c'est certain ici, dans le sud de la Floride. À cette période de l’année, nous commençons à nous préoccuper davantage de la météo. Même si je pense que beaucoup d’entre vous ont déjà séjourné plus au nord d’ici ou dans des régions de l’hémisphère nord, la météo semble occuper une place un peu plus importante dans nos préoccupations. Les conseils qui suivent ont donc pour but de vous aider à maintenir vos plans de continuité d’activité en vous adaptant à ces événements inévitables, mais imprévisibles, qui ne manqueront pas de bouleverser votre quotidien.
Cela exige que nous procédions à une auto-évaluation véritablement objective des risques, en particulier ceux qui ont des effets en cascade, car ceux-ci ont tendance à avoir une grande influence sur la capacité à renforcer vos mesures de protection. Bon nombre d'entre eux ont des conséquences tout à fait évitables.
Notre objectif aujourd’hui est donc de partager avec vous certaines de nos expériences acquises au cours de ces deux dernières décennies dans ce domaine, et de vous présenter quelques choix tactiques que vous pouvez faire pour faire face aux bouleversements récurrents qui se profilent à l’horizon.
Je voudrais donc commencer par vous proposer un petit test. Ce test vise essentiellement à déterminer dans quelle mesure votre stratégie de continuité d'activité et de reprise après sinistre serait compromise si vous deviez, au cours de l'année à venir environ, procéder à un changement important.
La configuration de vos systèmes de stockage, les fournisseurs (c'est-à-dire les fabricants) ou encore la topologie — par exemple, si vous envisagez de passer d'un SAN classique à trois niveaux à un système hyperconvergé. Il convient donc de replacer cela dans le contexte de votre stratégie actuelle en matière de continuité d'activité et de reprise après sinistre, tout en tenant compte de l'impact que les conditions météorologiques pourraient avoir sur les choix que vous faites.
Le temps, en particulier, a changé assez régulièrement et en a surpris plus d’un parmi nous. Je pense que même les météorologues ont un peu de mal à comprendre ce qui se passe ici. Mais il est tout à fait vrai — quelles que soient les causes que l’on puisse y voir — que l’intensité et la fréquence de ces changements climatiques sont devenues bien plus marquées.
Et des régions où, à une certaine époque, on se disait : « Waouh, on est vraiment… on ne voit jamais ce genre de tempêtes bizarres ni de phénomènes étranges », subissent soudainement des dégâts considérables : ouragans, inondations, tornades et autres catastrophes naturelles.
Cela met donc le sujet au premier plan, et c'est justement l'une de ces choses-là, mais mis à part — vraiment mis à part — les cas de force majeure et tout ce qui nous préoccupe par ailleurs, je souhaite vraiment me concentrer sur des problèmes plus banals et davantage liés à nos propres actions, que vous devriez prendre en considération.
Bon, j’imagine que certains d’entre vous sont déjà à la recherche de nouveau matériel. Vous m’avez poussé à procéder à une mise à jour matérielle de vos serveurs et de vos systèmes de stockage, et à mesure que vous examinez les possibilités qui s’offrent à vous, certaines choses attirent votre attention. C’est ce qu’on appelle le « syndrome de l’objet brillant ».
C'est à ce moment-là que l'on se rend compte à quel point une toute nouvelle fonctionnalité peut être séduisante. Je voudrais maintenant aborder cette question sous l'angle suivant : si vous opériez ce changement, si vous adoptiez ce nouvel outil, quel serait son impact sur votre approche de la continuité d'activité et quelles difficultés, en particulier, cette transition vous poserait-elle ?
Ce sont là les points précis dont nous souhaitons parler, surtout si, dans un an, vous faites le point sur vous-même, que vous repensez à ce que vous avez fait et que vous vous dites : « Waouh, ai-je pris de bonnes décisions ? » Avez-vous pris de bonnes décisions à l’époque ou aviez-vous manqué de recul ? C’est précisément à cela que nous voulons vous préparer, afin que vous puissiez anticiper certaines de ces situations et que vous puissiez réellement être satisfait de ces décisions dans un an.
Pourquoi s'en soucier, d'ailleurs ? Parce que ces changements ont tendance à être très perturbateurs. Certaines des mesures de modernisation et d'évolution que vous pourriez mettre en œuvre peuvent avoir des conséquences imprévues, et ces conséquences sont souvent étroitement liées à la manière dont vous répliquez actuellement vos données vers votre site de reprise après sinistre. Cela peut concerner la manière dont vous effectuez snapshots vos sauvegardes, ou encore la façon dont vous procédez au basculement d'un site à l'autre.
Donc, sur cette illustration, nous montrons le centre de données principal utilisant une forme de réplication synchrone, par exemple, vers le site de reprise après sinistre. Comment aborderiez-vous cela aujourd’hui ? En quoi cela serait-il différent si vous deviez remplacer certains des équipements chargés de cette réplication ? Et en quoi cela modifierait-il la manière dont vous procéderiez à la bascule et à la restauration de votre site principal ?
En effet, ces procédures sont profondément ancrées dans vos plans de continuité d’activité et de reprise après sinistre (BCDR), et elles peuvent être fortement perturbées par les choix que vous ferez à l’avenir. Notre objectif est donc avant tout de vous éviter de vous retrouver dans une situation où vous vous diriez : « Oh là là, je ne l’avais pas vu venir. J’avais pris une décision à la légère qui semblait isolée et qui me paraissait être le bon choix sur le moment, mais je n’avais pas pris en compte ses répercussions en aval. » Nous souhaitons donc vous mettre en bonne position pour y faire face et vous permettre de bien comprendre tous ces aspects.
Pour notre premier sondage, je voudrais simplement avoir une idée rapide. Combien d'outils différents votre organisation utilise-t-elle actuellement pour protéger les données critiques sur un site de reprise après sinistre ?
Cela nous permettra de déterminer si vous n’avez peut-être même pas de site de reprise après sinistre, si vous en gérez un ou deux, voire quelques-uns seulement, ou si vous devez gérer plusieurs sites différents afin de disposer d’une copie supplémentaire de certaines parties de vos données critiques ailleurs, d’où vous pourrez les restaurer si un incident venait à affecter le centre de données principal.
Bon, je vais jeter un œil aux résultats qui arrivent. La première chose que je remarque, c’est qu’il y a un… ça commence tout juste à s’afficher. Je vais attendre un instant. Je ferai un deuxième sondage un peu plus tard, qui est également lié à ce sujet ; cela m’aidera en quelque sorte à cadrer la rest la discussion, pour que je sache dans quelle direction l’orienter.
Donc, pour l'instant, nous constatons qu'environ un tiers d'entre vous ne dispose même pas d'un site de reprise après sinistre. Waouh, c'est en soi un peu surprenant, mais il faut comprendre que, d'un point de vue budgétaire, cela peut être hors de votre portée pour le moment. Nous espérons donc vous donner quelques idées pour remédier à cela.
Environ un tiers d'entre vous déclare n'utiliser qu'un seul outil. Environ 28 % indiquent utiliser un seul outil. À l'heure actuelle, environ 14 % déclarent utiliser deux outils et, chose surprenante, un quart d'entre vous en utilise plusieurs.
Du coup, vous avez fort à faire pour essayer de comprendre comment coordonner ces différents éléments de votre plan de reprise après sinistre, car ils fonctionnent en quelque sorte en vase clos les uns par rapport aux autres. Mais il existe une bonne solution pour vous aider à y voir plus clair.
Bon, continuons. La première chose que je tiens à souligner à ce sujet, c’est que pour certains d’entre vous, peut-être, la raison pour laquelle vous fonctionnez ainsi, c’est que vous utilisez des fonctionnalités intégrées, par exemple, à votre SAN. Votre baie de stockage en réseau. Ce périphérique, ce contrôleur de stockage intelligent, vous fournit une partie de la protection des données et des services de réplication.
Ainsi, si certains d'entre vous ont répondu « deux » ou « plusieurs », c'est peut-être parce que vous disposiez de deux modèles de stockage au sein de votre SAN. Et chacun d'entre eux utilise une technique de réplication différente. En fin de compte, ils cherchent tous à copier les données vers le site de reprise après sinistre, mais ils utilisent peut-être des protocoles différents ou des mécanismes propriétaires spécifiques pour y parvenir.
Cela pose donc en soi certaines difficultés. Deuxièmement, comme elles se trouvent dans le tableau, ces capacités sont isolées et ne peuvent pas être partagées. Il faut donc déterminer explicitement quelles données placer à un emplacement et lesquelles à un autre ; au fil du temps, à mesure que la valeur de ces données évolue, il peut s’avérer nécessaire de réajuster légèrement ces choix.
Dans cette optique, ce que DataCore va principalement vous proposer dans ce cas, c’est un moyen de consolider ces services de protection des données. Il y a donc une certaine uniformité entre eux. Au lieu de s’appuyer sur les capacités d’une baie spécifique ou d’un périphérique de stockage particulier, par exemple, nous élevons en quelque sorte le niveau auquel ces fonctions s’exercent. Ainsi, tous les systèmes de stockage que vous intégrez à votre infrastructure, qu’il s’agisse de ceux d’aujourd’hui ou de demain, bénéficieront de la même procédure opérationnelle.
Vous pouvez mettre en œuvre une stratégie de BCDR à l’échelle de l’infrastructure sans vous soucier d’une marque ou d’un modèle en particulier. C’est là l’essentiel de ce que nous souhaitons développer. Et pour y parvenir, nous nous appuyons sur un ensemble continu de mesures de protection. Il s’agit en effet d’un ensemble de fonctionnalités couvrant l’ensemble des stratégies que vous allez mettre en œuvre pour protéger vos informations.
Dans les cas extrêmes ou lorsque les données sont critiques, un RPO et un RTO nuls sont requis, ce qui implique une mise en miroir synchrone. Cette mise en miroir synchrone peut s'effectuer à l'échelle locale, c'est-à-dire à quelques pieds l'une de l'autre, là où se trouvent deux copies. Mais, le plus souvent dans ces contextes, il s'agit plutôt de mettre en place des clusters étendus et des clusters métropolitains, et je vais vous en montrer quelques illustrations. Une autre composante de cette fonctionnalité est la capacité à basculer automatiquement vers cette autre copie en cas de défaillance du serveur principal.
Ainsi, ceux-ci fonctionnent selon ce qu’on appelle une configuration « actif-actif » : il n’y a donc jamais aucune interruption dans l’accès aux données, ni aucune perte de données, même en cas de panne totale de la moitié de votre infrastructure de stockage.
Il est également question de la résilience à trois niveaux, lorsque l'on souhaite aller encore un peu plus loin. Et puis il y a un deuxième ensemble que j'ai classé dans cette catégorie et qui concerne les défaillances régionales : il s'agit d'une zone métropolitaine entière susceptible d'être touchée par des tremblements de terre, des inondations et d'autres dangers encore plus graves.
Et c’est là advanced site recovery des mesures telles que la réplication asynchrone et advanced site recovery , qui permettent d’éloigner considérablement votre deuxième copie et de pouvoir la restaurer rapidement. Et puis, il y a certains… et, d’ailleurs, dans ce cas, vous… en gros, il y a des compromis à faire. Ces compromis consistent à privilégier une image cohérente en cas de panne, plutôt qu’un RPO ou un RTO nul. Vous aurez potentiellement des éléments à restaurer et le fonctionnement connaîtra quelques ratés.
Et puis il y a d’autres mesures, comme la protection continue des données (CDP) et snapshots, qui vous permettent en gros de disposer d’un point dans le temps, un point bien précis. La CDP est peut-être un concept nouveau pour certains d’entre vous. C’est une façon de créer une sorte d’enregistreur vidéo numérique (DVR) pour toutes les données critiques d’entrée-sortie, que vous pouvez rembobiner dans le temps.
Imaginons donc que vous ayez été victime d’une attaque de type ransomware. Vous pourriez en effet remonter le temps jusqu’au moment où l’attaque s’est produite et restaurer l’état de vos données tel qu’il était avant leur chiffrement. Vous pourriez ainsi, en quelque sorte, faire un pied de nez à ceux qui tentent de vous extorquer de l’argent. Ce sont donc des fonctionnalités intéressantes à explorer.
Cela signifie que je peux, ou que vous pouvez, maintenir le même processus de BCDR tout en procédant à la mise à jour du matériel. Nous savons que la mise à jour du matériel et, dans certains cas, du micrologiciel et de tout le reste, peut constituer une situation assez instable, malgré toutes les bonnes pratiques.
En résumé, ce que nous voulons dire ici, c’est que nous avons mis au point, au fil des ans, des mécanismes qui vous permettent de retirer l’ancien équipement, de le remplacer par du neuf — en termes de configuration de stockage — et de le faire en coulisses, pendant une journée de travail, aux heures normales d’exploitation, sans avoir à interrompre le service. Et tout cela est possible, même si vous optez pour un autre fabricant ou un modèle de produit différent, qui serait incompatible avec le précédent.
Ainsi, la migration des données de l'ancien système vers le nouveau s'effectue en arrière-plan, sans interruption. Vous pouvez effectuer cette opération aussi souvent ou aussi rarement que votre organisation l'exige, mais l'essentiel est que vos procédures opérationnelles restent inchangées, même si vous choisissez un autre emplacement pour stocker vos données. Voilà donc la fin de cette animation.
C'est vrai aussi, alors… certains d'entre nous se disent : « Bon, d'accord, mais je ne gère pas de réseaux SAN, ou plutôt… les réseaux SAN font en quelque sorte partie de ce que j'ai géré jusqu'à présent, mais je commence à m'intéresser à des solutions comme les systèmes hyperconvergés, et je me demande en quoi cela pourrait m'aider dans ce contexte, si je décidais de passer à ce type de solution ? »
L’un des atouts majeurs de l’approche de DataCore réside, là encore, dans le fait qu’en faisant évoluer le niveau auquel ces services de protection des données sont mis en œuvre, la topologie n’a plus d’importance. Ainsi, chez plusieurs de nos clients, on constate qu’ils font leurs premiers pas vers l’HCI en déployant une solution hyperconvergée sur leur site de reprise après sinistre, voire à l’autre extrémité de leurs clusters métropolitains. D’un côté, ils ont donc mis en place un environnement avec des baies SAN externes classiques. De l’autre, ils répliquent ces données vers une nouvelle infrastructure, composée uniquement de serveurs de base dotés d’un stockage interne et sur lesquels tourne le logiciel DataCore ; cette infrastructure héberge également les machines virtuelles qui bénéficieront du basculement.
D'un point de vue visuel, d'un point de vue optique, c'est un changement très radical, mais sur le plan opérationnel, ils semblent identiques. Les mêmes techniques de basculement et de reprise s'appliquent, comme si nous avions des systèmes identiques aux deux extrémités.
Il y a toutefois certains éléments spécifiques à éviter. Je les appellerai ici les « interdits », mais cela revient en substance à dire : « Compte tenu de ce que vous savez désormais, vous devriez, à tout prix, éviter de vous appuyer sur une baie matérielle pour la protection de vos données. » Car cela vous enfermera dans certains schémas qui entraîneront des bouleversements en aval.
En somme, cela nuit fondamentalement à l’utilité du système — chaque fois que vous agissez ainsi, vous en compromettez l’utilité et vous ne pouvez pas franchir la limite de l’environnement, et par « limite de l’environnement », j’entends le matériel physique sur lequel il s’exécute. De plus, vous risquez de réduire prématurément la durée de vie de ce matériel, car lorsque de nouveaux équipements sont mis en place et qu’ils n’utilisent pas la même technique de réplication, vous finissez par devoir faire un choix ou vous retrouver dans une situation où vous vous dites : « Oh, je dois utiliser deux ou trois méthodes différentes pour y parvenir », ce qui n’est pas gérable à long terme.
La deuxième erreur à éviter est de choisir une stratégie de reprise après sinistre (DR) spécifique à sa topologie. C’est soit dire : « Bon, je procède toujours ainsi et je m’attends à disposer systématiquement d’un SAN en arrière-plan. » Soit : « Je m’attends à ce que ce soit strictement hyperconvergé. » Ces deux approches peuvent, comme on dit, s’avérer tout aussi peu visionnaires. Elles ne vous permettent pas de séparer clairement le rôle du stockage de celui du calcul, et vous risquez d’être affecté par de nombreuses variables en termes de qualité de service. L’essence même de notre message est donc de vous libérer de ces contraintes.
Je voudrais citer un bon exemple d’un client qui a adopté cette approche et qui l’a mise en œuvre très tôt. Cela fait plus de neuf ans qu’il applique cette méthode. Il s’agit du Maimonides Medical Center. Cet établissement assure la prise en charge des patients en soins intensifs dans la région de New York et n’est évidemment pas en mesure de se permettre le moindre temps d’arrêt, qu’il soit prévu ou imprévu.
En fait, ils ont procédé à une refonte complète : à un moment donné, ils exploitaient un centre de données dont l’ensemble des installations se trouvait sur un seul site au sein de l’hôpital. Ils ont ensuite décidé de le scinder en deux sites en configuration « actif-actif », l’un situé à l’hôpital principal et l’autre dans les locaux du MIS, à quelques pâtés de maisons de là.
Et tout au long de cette période, ils ont maintenu deux copies actives, c'est-à-dire des données stockées à deux endroits différents, comme nous l'avons expliqué, de sorte que chaque fois qu'une opération de maintenance était effectuée ou qu'un problème survenait sur l'un des sites, les autres prenaient le relais de manière transparente. Ils fonctionnent ainsi sans aucun temps d'arrêt lié au stockage depuis près d'une décennie. Cela fait peut-être déjà une décennie.
Et il s’agit d’une configuration de taille considérable, d’un pétaoctet. Une vaste communauté de cliniciens, de personnel médical et de médecins s’appuie sur ce système et utilise une grande variété d’applications. En gros, ils affirment que c’est ainsi qu’ils gèrent leurs activités. Voici quelques exemples illustrés. Je pense que si vous êtes plutôt du côté technique, notamment en matière de réseaux, vous apprécierez la deuxième image.
Ceci concerne un client qui utilise différentes générations d’équipements Dell. Sur le site principal (site Ouest), il utilise Compellent, tandis que son cluster métropolitain repose sur EqualLogic. Or, comme ces deux systèmes ne peuvent normalement pas communiquer entre eux — et c’est effectivement le cas —, aucun des deux ne dispose des mêmes fonctionnalités. DataCore permet donc de rationaliser leur utilisation et de standardiser les outils utilisés pour effectuer les copies entre ces systèmes, quel que soit le matériel sous-jacent.
Ils ont simplement fait ce choix et, lorsque le prochain 3par – ou tout autre élément qu’ils souhaiteraient intégrer ici – entrera en jeu, qu’ils optent pour HP ou qu’ils préfèrent rester dans la famille Dell, ce sont là des choix qu’ils pourront faire à tout moment, car cela n’a pas d’incidence sur leur procédure. Il s’agit simplement de l’endroit où les données sont stockées en fin de compte et d’où elles sont récupérées.
Cela vous donne également une idée un peu plus précise de certains des chemins redondants que vous devriez mettre en place. Ainsi, si vous craignez l’existence d’un point de défaillance unique, que ce soit au niveau de la structure du câblage (liaisons entre sites et liaisons vers les commutateurs), vous devez élaborer une stratégie bien pensée. Et cela fait partie des bonnes pratiques que nos partenaires agréés peuvent vous proposer.
Voici une autre configuration. Elle concerne également le secteur de la santé, où l’on a tendance à se montrer beaucoup plus vigilant en matière de protection des données. Dans ce cas précis, cet hôpital, ou centre médical, gère trois sites. Les deux sites situés à Manhattan, à droite, constituent les principaux centres de traitement des données. Ils disposent également d’un site de secours, situé à Secaucus, dans le New Jersey.
C'était un choix très important de leur part, car lorsque la supertempête Sandy a frappé la région, inondant Manhattan et provoquant d'énormes coupures d'électricité, sans parler de tout ce qui se passait d'autre ici, ces sites ont pu, comme on le voit à droite, basculer vers un site situé en hauteur, le centre de colocation de Secaucus, qui était resté au sec — bien à l'abri des inondations, heureusement.
Bon, pour nous, les plaisanciers, ce n'est pas une bonne chose, mais pour les centres de données, c'est sans aucun doute une situation très favorable, qui leur a permis de poursuivre leurs activités. Cela a permis de maintenir le fonctionnement de leurs services de données critiques. Évidemment, ils ont dû réorganiser toute une série d'autres éléments pour y parvenir, mais d'un point de vue informatique, ils étaient bien protégés.
Et une fois le fonctionnement rétabli dans ces installations de Manhattan, ils pourraient tout simplement actionner un interrupteur et, en fait, revenir à cette configuration. Ainsi, dans ce cas précis, les deux s'appuient sur un site commun, ils font tous les deux la même chose. Ils effectuent à la fois une mise en miroir synchrone vers ce site et entretiennent une relation réciproque.
Dans certains cas — et je constate d’ailleurs que c’est de plus en plus souvent le cas —, j’observe qu’un troisième exemplaire est nécessaire. Et la raison pour laquelle ce troisième exemplaire est nécessaire est intéressante. Il y a deux façons d’envisager cela — et je parle ici spécifiquement d’un troisième exemplaire situé à proximité — qui est également synchronisé en miroir.
Donc, dans ce cas précis, ce que vous essayez de faire, c’est que lorsque vous en perdez un — sur cette image, j’ai les nœuds ouest, celui du milieu à l’est et la troisième copie sur le nœud nord —, certains se trouvent dans un environnement de campus, au sein de la même zone métropolitaine. Lorsque nous devons mettre l’un de ces systèmes hors service pendant un certain temps — pour une maintenance préventive, une mise à niveau ou toute autre raison —, voici ce qui a tendance à se produire : si vous ne disposez que de deux de ces systèmes, selon leur dimensionnement, vous pourriez constater que si le nœud ouest dépendait uniquement du nœud est pour prendre le relais, ce dernier risquerait d’être un peu ralenti s’il n’était pas suffisamment dimensionné pour gérer la charge supplémentaire.
Et à ce stade, vous vous retrouvez en fait avec cette seule unité qui est… vous êtes en quelque sorte un peu plus vulnérables, car si ce nœud venait à tomber en panne, dans le cadre d’une défaillance en cascade, cela constituerait également une perte. Ainsi, afin de maintenir un environnement hautement disponible, même après avoir mis hors service l’un de ces nœuds, vous avez eu recours à cette résilience à trois niveaux.
Et cela vous apporte en quelque sorte cette tranquillité d’esprit qui vous permet de vous dire : « Oui, je peux m’en accommoder. Je suis prêt à effectuer l’entretien préventif plus fréquemment, sachant que je suis toujours soutenu par les deux autres nœuds, et je sais que mes utilisateurs ne remarqueront rien — nous ne subirons aucune perte de performances pendant que j’effectue cette bascule. » C’est vraiment une excellente approche pour que tout se passe comme prévu.
Je tenais également à vous montrer quelques images illustrant ce qui se passe en coulisses, du point de vue de la console d'administration. C'est la perspective dont on bénéficie lorsqu'on est aux commandes de l'ensemble du système.
À partir de là, nous gérons la réplication en cours et sommes en mesure de déterminer quels systèmes ont pu être mis hors service pour des raisons de maintenance. Nous pouvons analyser les performances observées de manière indépendante des appareils, des fournisseurs et de la topologie.
Nous avons une vision à 360 degrés de notre stratégie de protection des données, sans avoir à nous préoccuper des subtilités propres à chacun de ces modèles ou de ces marques. C’est là l’aspect vraiment important de tout cela. Nous l’avons compris une fois pour toutes, et nous continuons à appliquer cette même technique en toutes circonstances, même lorsque la situation évolue.
Concrètement, cela se traduit ainsi : à mesure que vous développez votre propre infrastructure et que vous commencez à sortir de ce qui pouvait être des « silos » présentant des topologies différentes, vous mettez en place une approche uniforme pour normaliser ces pratiques de BCDR, malgré la diversité des éléments qui composent ces différents « compartiments ».
Au centre de cette image, je voudrais attirer votre attention sur ce qui pourrait correspondre, par exemple, à votre système d’enregistrement, où s’exécutent vos principales applications de niveau 1. Il peut s’agir de grands SAN externes classiques desservant à la fois des machines physiques et des machines virtualisées. Et de plus en plus souvent, j’ai également observé l’utilisation de conteneurs dans le cadre des efforts de développement ; ceux-ci constituent tous des clients à part entière qui consomment de l’espace de stockage provenant de ces zones de stockage externes.
Dans ce cas précis, DataCore constitue la couche d'uniformisation, c'est-à-dire la couche de virtualisation du stockage, qui regroupe ces baies de stockage externes et les présente sous la forme d'une vue d'ensemble du chemin d'accès.
D'un côté, vous avez peut-être également sélectionné une infrastructure de postes de travail virtuels (VDI, pour « Virtual Desktop Infrastructure »), par exemple, afin de tester le fonctionnement de ces clusters hyperconvergés. Et même si vous avez fait ce choix, nous continuons d'utiliser le même logiciel DataCore pour faciliter la mise en œuvre de notre stratégie de BCDR.
Il en va de même pour notre stockage secondaire: ce que vous voyez sur le site de reprise après sinistre, dans les bureaux distants et les succursales, c’est une fonctionnalité logicielle similaire, voire identique, mais avec des topologies légèrement différentes. Les ROBO, quant à eux, s’apparentent davantage à un cluster hyperconvergé ; dans ce cas précis, le site de reprise après sinistre devait être un peu plus puissant. Cela ressemble davantage à une infrastructure convergée, où il existe toujours une séparation entre le « tuyau » externe sur lequel les utilisateurs stockent leurs données et le stockage des fournisseurs situé en dessous, mais nous ne comptons pas sur de grandes baies pour y parvenir.
Nous avons déjà, en gros, mis en place le stockage local et mutualisé ces ressources, ou simplement des baies externes, mais nous n’avons plus besoin de contrôleurs intelligents à ce niveau, car cette fonction est désormais prise en charge par les capacités de DataCore, comme je vais vous le montrer plus tard à l’aide d’un graphique.
En substance, ce que nous faisons, c’est dire que le logiciel vous offre le choix d’une indépendance vis-à-vis de la topologie, ainsi que différentes façons de mettre cela en œuvre, et celles-ci peuvent évoluer au fil du temps. Vous avez peut-être commencé à gauche de ce schéma, où vous regroupez et virtualisez les baies de stockage, puis vous réduisez progressivement ce système à mesure que ces baies sont retirées ou que leur durée de vie utile arrive à son terme. Vous les remplacez alors par du stockage interne à ces serveurs, des serveurs x86, qui font office de contrôleurs de stockage.
Puis, lors de la troisième phase de votre transition, vous pourrez effectivement déployer les machines virtuelles et les charges de travail directement sur ces mêmes serveurs. Vous devrez peut-être les renforcer à ce stade, mais vous pourrez certainement passer en douceur de la gauche à la droite, tout en poursuivant votre objectif de réduction de la complexité de votre infrastructure et en conservant les mêmes pratiques.
Et puis, plus tard, tu reviendras peut-être sur ta décision en te disant : « Waouh, ce n'était pas une si bonne idée que ça. En fait, je voulais séparer mon hébergement de mon espace de stockage et créer en quelque sorte une solution hybride. »
Pour vous permettre d’y parvenir, nous proposons essentiellement trois éditions de notre logiciel. Il y a l’édition « Enterprise », qui est la plus complète et offre le plus grand nombre de fonctionnalités ; puis nous avons une édition de milieu de gamme, l’édition « ST » ; ainsi qu’une édition ciblant les opportunités de stockage secondaire à grande échelle que vous avez dans la communauté voisine, comme les grands serveurs de fichiers, ce genre de choses, où vous ne voudrez pas dépenser le même prix par téraoctet que pour vos charges de travail les plus critiques. Donc, n’importe laquelle de ces licences peut fonctionner ; ce sont toutes des licences logicielles que vous exécutez sur un serveur x86 et elles sont toutes compatibles avec n’importe laquelle de ces topologies.
Voici un aperçu de l’architecture globale. Jusqu’à présent, nous nous sommes concentrés, dans cette discussion, sur la partie relative aux services de protection des données. Des éléments tels que la mise en miroir synchrone, la réplication, snapshots la protection continue des données (CDP), mais il existe un certain nombre d’autres services que l’on est en droit d’attendre et dont on a besoin de la part d’une infrastructure de stockage, qu’il s’agisse de provisionnement, de création de graphiques et d’alertes, ou encore de la compréhension, d’un point de vue analytique, de vos futurs besoins en capacité, et peut-être d’ajustements de votre qualité de service.
Tous ces éléments font donc partie intégrante de ce qu’offre la pile logicielle, et peu importe la manière dont vous y accédez. Que ce soit via fibre channel iSCSI quel que soit le protocole de stockage que vous utilisez en arrière-plan. Il peut s’agir NVMe vos besoins de vitesse et de faible latence, et vous allez connecter certaines de cesflash NVMe directement sur ces serveurs DataCore. Vous pouvez également utiliser des disques à connexion directe, voire disposer d’une partie de cette capacité dans le cloud. Peu importe votre choix : il s’agit simplement d’attribuer à ces différents nœuds des responsabilités spécifiques en fonction des charges de travail que vous leur confiez.
Dans cette optique, j’aimerais lancer un deuxième sondage. Maintenant que vous avez une idée plus précise de ce que nous cherchons à mettre en évidence, j’aimerais vraiment savoir lequel des changements suivants, si vous deviez vous prononcer dès maintenant, concernant votre infrastructure de stockage de données, perturberait le plus votre stratégie de continuité des activités et de reprise après sinistre (BCDR).
Si (A) si on vous annonçait soudainement : « Au cours des six prochains mois, nous avons décidé — nous sommes convaincus — de migrer notre site de reprise après sinistre vers le cloud. Et pour ceux d’entre vous qui ne disposaient pas encore d’un site de reprise après sinistre, nous allons en mettre un en place dans le cloud », quel impact cela aurait-il pour vous ?
Ou peut-être envisagez-vous d’ajouter une flash à votre SAN existant ? Évaluez dans quelle mesure les techniques que vous utilisez pour la réplication changeraient radicalement à la suite de cela. Je ne parle pas d’un point de vue conceptuel, mais bien concrètement. Comment votre plan de BCDR (reprise après sinistre et continuité des activités) évoluerait-il ? Et si vous deviez soudainement basculer vers un système hyperconvergé, voire le faire fonctionner en parallèle de votre stockage actuel, cela fonctionnerait-il très, très différemment ? Je suppose que oui, c’est pourquoi j’aimerais avoir votre avis à ce sujet.
Alors, Carlos, je ne vois pas les résultats du deuxième sondage. Je ne sais pas si tu les vois, toi.
Carlos Nieves : Je les vois, Augie. À l'heure actuelle, environ 68 % des votants ont choisi l'option « Migrer votre environnement DR vers le cloud ». Environ 10 % ont opté pour « Ajouter uneflash à votre SAN existant ». Et le rest un système hyperconvergé en complément ou en remplacement de votre solution de stockage actuelle ».
Augie Gonzalez: Bon, ce que je voudrais que vous fassiez — une fois que nous aurons terminé ici aujourd’hui —, c’est en quelque sorte de réfléchir par vous-mêmes : le fait que je doive prendre cette mesure, quelle en est la portée ? Quelles répercussions cela a-t-il sur les procédures, la formation et les audits que je dois mener dans le cadre de mon plan de continuité des activités et de reprise après sinistre (BCDR), et comment puis-je éviter que cela n’entraîne un changement aussi catastrophique dans la manière dont je mets en œuvre mes mesures de sécurité ? Merci pour ces contributions, au fait.
DataCore est donc là pour vous aider. L’entreprise vous accompagne sur plusieurs fronts. Aujourd’hui, dans le cadre de ce webcast, nous nous concentrons principalement sur la continuité d’activité et la reprise après sinistre, mais en réalité, chaque fois que vous envisagez d’étendre ou de renouveler votre infrastructure de stockage, cela peut être l’occasion idéale de repenser votre approche en matière de sauvegarde de vos données sur un autre support.
Nous sommes également étroitement associés à des organisations qui mènent actuellement un effort de consolidation, dans le cadre duquel elles s’efforcent de réduire la diversité des équipements, de mutualiser ces ressources et de les gérer de manière uniforme. Nous pouvons donc vous aider dans ce domaine, mais aussi au niveau de la périphérie, que vous gériez des bureaux distants ou des succursales, en complément du centre de données principal, et que vous cherchiez à établir un accord réciproque entre les sites de reprise après sinistre (DR), en utilisant soit le centre de données principal comme site de reprise, soit ces installations ROBO.
Ou bien, au niveau de la périphérie, vous devez renvoyer une partie de ces données. Les techniques utilisées sont les mêmes, nous pouvons donc vous apporter une aide précieuse dans ce domaine. Plus précisément, en ce qui vous concerne à titre individuel, il existe plusieurs tâches pour lesquelles nous pouvons vous aider.
Ainsi, si votre mission consiste à garantir la continuité opérationnelle, nous pouvons vous aider à y parvenir, même à mesure que le matériel vieillit et que de nouveaux équipements prennent le relais. Je pense que c’est sans doute la priorité absolue, et l’un des outils que nous proposons à cet effet est la capacité à migrer les données en arrière-plan : ainsi, lorsque ces équipements sont remplacés, nous pouvons effectuer cette transition, retirer l’ancien matériel, transférer les informations vers le nouveau, et personne n’aura à se rendre compte que vous avez procédé à cette opération.
Au point même que ce matériel soit apparu à un autre endroit que celui prévu : non seulement le fournisseur et le modèle ont changé, mais le lieu lui-même a également changé. Et tout cela en contournant les points de défaillance et les pannes ; ainsi, votre scénario peut très bien prévoir des pannes graves, par exemple dans un bâtiment du campus, mais les systèmes continuent bien sûr de fonctionner.
Il y a également des avantages indirects, notamment la possibilité de mutualiser les capacités entre des appareils qui, autrement, seraient considérés comme isolés. Ainsi, plutôt que de dire : « Bon, j’ai cet îlot de stockage et j’ai pris des décisions précises quant aux applications que j’utilise dessus », je peux en réalité regrouper et agréger les ressources à ma disposition, aussi variées soient-elles, et les considérer comme un pool de ressources dans lequel je peux puiser en fonction des pics et des variations de ma consommation.
Enfin, il y a la capacité à authentifier réellement les utilisateurs. Il s'agit de déterminer qui mérite un service hautement prioritaire, qui nous cherchons à empêcher de devenir des utilisateurs malveillants, et qui bénéficie d'un service intermédiaire. Tous ces éléments font partie des capacités d'intelligence dont il est question ici.
S'il y a une chose que je tiens à vous dire — ou plutôt à vous rappeler —, c'est de ne pas laisser ces dépendances cachées compromettre votre plan de continuité des activités et de reprise après sinistre (BCDR). Qu'il s'agisse de l'emplacement, de la topologie ou des fournisseurs, gardez un œil dessus. Surveillez bien l'impact que tout changement à ce niveau pourrait avoir sur vous.
Et, de notre point de vue, d’après les retours que nous avons reçus de nos clients. Parmi ceux-ci, on peut citer, par exemple, la ville de Carmel, qui a publié une excellente webconférence. Elle utilise DataCore depuis 2010. Cela fait donc quoi ? Neuf ans ? Et, pendant toute cette période, elle n’a connu aucun temps d’arrêt, malgré les nombreux changements qui ont évidemment eu lieu entre-temps.
Considérez-nous donc comme un éditeur de logiciels indépendant, le seul à pouvoir préserver votre stratégie BCDR soigneusement élaborée, tout en vous permettant de moderniser vos systèmes et de générer des économies pour votre entreprise, puisque vous n’avez pas à vous débarrasser d’éléments qui auraient été soudainement supprimés et remplacés.
Et si vous souhaitiez partager rapidement certaines de ces informations avec certains de vos collègues qui ne seraient peut-être pas disposés à suivre une webconférence pendant les 45 minutes environ que dure celle-ci, je vous conseille de leur donner un aperçu rapide de ces mesures.
Vous y trouverez plusieurs ressources, mais il y a notamment des vidéos d'environ deux minutes qui vous donneront une idée précise de ce dont nous parlons et illustreront ce que nous entendons par ces « dépendances en cascade » ; je vous encourage donc vivement à les regarder.
Sur ce, je pense que nous allons passer en revue nos questions pour voir ce que nous avons là. Laisse-moi m'en charger, Carlose, excuse-moi.
La première question est donc : « Est-ce que ça fonctionne bien avec Office 365 ? » C'est une question intéressante. Office 365 est un logiciel hébergé, et il existe donc déjà une infrastructure en arrière-plan qui s'en charge.
Dans ce cas, vous devriez compter sur le fournisseur SaaS, ce qui, en général, échappe un peu à votre contrôle si vous utilisez la version hébergée. Si, par contre, vous utilisez Office en local sur vos propres serveurs, cela vous serait alors très utile.
Voici la deuxième question : « Y a-t-il des exigences particulières en matière de stockage pour utiliser votre logiciel ? » Je l'interprète ainsi : « Y a-t-il des problèmes de compatibilité spécifiques dont nous devrions tenir compte et qui pourraient nous empêcher de le faire ? » Et non, le logiciel est conçu pour communiquer avec n'importe quel périphérique de stockage standard utilisant les protocoles courants, qu'il s'agisse de SAS, de SATA ou de NVMe. Il les prend tous en charge de manière native ; la plupart de ces protocoles reposent en fait sur le protocole SCSI utilisé pour la transmission des données.
Nous utilisons un serveur, cet espace de stockage et les méthodes traditionnelles pour établir cette connexion. Le système est entièrement compatible, nous n'avons donc pas besoin de remplir des conditions particulières pour cela.
Il y a une autre question ici : « Comment fixez-vous le prix du logiciel ? » J’ai déjà donné un petit indice à ce sujet. Cela dépend essentiellement de la capacité. Il s’agit de la quantité de capacité pour laquelle DataCore assume la responsabilité. Quelle est la capacité utilisable sur laquelle nous pouvons compter ? C’est sur cette base que nous facturons un prix au téraoctet.
Plus le volume que vous nous confiez est important, plus le prix au téraoctet est bas. Quant aux trois éditions que je vous ai présentées tout à l'heure, EN, ST et LS, elles définissent simplement un ensemble de fonctionnalités. Dans certains cas, toutes les fonctionnalités sont intégrées ; dans d'autres, l'ensemble de fonctionnalités est plus adapté aux besoins des entreprises de taille moyenne et aux cas où les performances ne sont pas un facteur déterminant : c'est le cas de l'édition LS. Voilà, c'est tout.
Je ne vois pas d'autres questions. Il nous reste encore quelques minutes, si vous le souhaitez, puis je passerai la parole à Carlos.