Transcription de la webdiffusion
Danielle : Bonjour et bon après-midi à tous. Merci beaucoup de vous joindre à nous aujourd’hui. Je m’appelle Danielle Brown. Je suis responsable marketing chez DataCore Software, et je serai votre modératrice. Nous sommes ravis de vous accueillir à notre webinaire d’aujourd’hui, intitulé « Comment intégrer des systèmes hyperconvergés à des réseaux SAN existants ». Mais avant de commencer la présentation, j’aimerais passer en revue quelques points d’ordre pratique.
Cette présentation est enregistrée et sera disponible à la demande. À l’issue de ce webinaire, vous recevrez un e-mail de BrightTALK contenant un lien pour la visionner à la demande. Enfin, n’hésitez pas à poser vos questions tout au long de la présentation ; nous y répondrons également à la fin. Sur ce, j’aimerais lancer la présentation et vous présenter notre intervenant d’aujourd’hui, Augie Gonzalez, directeur du marketing produit chez DataCore Software, qui est également présent parmi nous. Augie ?
Augie : Merci, Danielle. Je voudrais donc passer en revue plusieurs points qui, je pense, vous tiennent particulièrement à cœur. Le premier consiste à essayer de comprendre et à vous donner quelques conseils pour déterminer si les systèmes hyperconvergés vous conviennent. Je pense que, dans certains cas, les gens considèrent que c’est une évidence. Ce que j’aimerais faire, c’est décrire certaines des conditions limites et des éléments à prendre en compte dans ce domaine. Où l’hyperconvergence trouve-t-elle vraiment sa place ? Car il existe en effet des cas qui sortent de la norme.
Je voudrais également aborder certaines considérations particulières si vos applications ont tendance à être gourmandes en E/S. En effet, les applications à usage général fonctionnent très bien, mais celles qui sollicitent fortement les E/S nécessitent un peu plus de planification, voire des choix différents. Pour illustrer cela, nous allons passer en revue l’une de nos études de cas concernant un client du secteur des services d’urgence, plus précisément un centre d’appel d’urgence (911). Je pense que cela permettra de consolider certains des concepts dont nous parlons ici ; nous poursuivrons ensuite avec quelques informations supplémentaires sur la manière de tirer parti des ressources déjà présentes dans votre infrastructure, pour lesquelles vous avez déjà dépensé beaucoup d’argent et dont vous souhaitez tirer le meilleur parti.
Et nous conclurons cette discussion par quelques étapes concrètes et des conseils pour faciliter votre transition depuis le SAN à trois niveaux que vous utilisez peut-être aujourd’hui vers un environnement hyperconvergé. Maintenant, si l’on se penche sur une comparaison de base, tant les SAN à trois niveaux – ce que l’on pourrait qualifier de stockage externe, à gauche, où les serveurs sont connectés via un réseau iSCSI Fibre Channel à une baie – que les systèmes hyperconvergés, où les serveurs exécutant des applications fonctionnent en cluster, visent tous le même objectif : à savoir fournir un stockage partagé à plusieurs applications afin qu’elles puissent bénéficier de ce pool commun de capacité et, dans certains cas, permettre des opérations telles que la migration en direct d’applications et de machines virtuelles, y compris le transfert de conteneurs d’un serveur physique à un autre, sans interruption.
Sur ces schémas, vous verrez que j’utilise un rectangle bleu turquoise pour indiquer où le logiciel intervient. Ainsi, à gauche, il figure sur la baie en tant que contrôleur frontal. Dans le cas d’une solution hyperconvergée, qui utilise le stockage interne des serveurs, il s’agirait d’un logiciel qui tournerait soit sur une machine virtuelle, soit directement sur hypervisor.
DataCore propose les deux solutions ; nous n’avons donc pas de préférence particulière qui nous obligerait à orienter nos clients dans un sens ou dans l’autre. Je vais toutefois vous présenter quelques-unes des raisons pour lesquelles nous pourrions recommander l’une plutôt que l’autre. Il existe des différences très nettes selon ce que vous cherchez à réaliser. Dans le cas d’un SAN centralisé, la priorité est de décharger les serveurs et de concentrer la capacité de stockage dans une zone unique, facile à gérer, puis de fournir un accès réseau à celle-ci via une connexion iSCSI Fibre Channel.
Il est également intéressant de séparer les responsabilités, par exemple, de l’administrateur de stockage qui a la charge de ces ressources centrales. Comparez cela à un système hyperconvergé. Ce que nous essayons de faire ici, c’est de partir du principe que tous ces serveurs disposent d’une capacité excédentaire en termes de puissance de calcul, d’E/S et, éventuellement, de stockage. Mettons donc toutes ces ressources en commun afin d’en tirer pleinement parti et, dans la mesure du possible, de garantir que les applications puissent accéder au disque local sans avoir à traverser le réseau.
Parallèlement, nous disposons d'une méthode potentiellement plus efficace pour renforcer l'isolation des comptes alternatifs en répartissant le stockage sur un plus grand nombre de nœuds. Cela implique toutefois un compromis : nous combinons également les rôles. Ainsi, d'un point de vue administratif, la personne chargée de la gestion des serveurs doit également prendre en charge la gestion du stockage.
Et j’aborderai certains de ces facteurs sociopolitiques dans un instant. Voici un aperçu de cette vision. Donc, si vous redessinez ce SAN central pour qu’il ressemble à peu près à ça, en mettant simplement l’accent sur le fait que le stockage à gauche est entièrement concentré — c’est un pool centralisé —, il peut être composé de plusieurs baies ou périphériques de stockage. Mais d’une manière ou d’une autre, il y a quelque chose qui les englobe et qui leur donne l’apparence d’un pool central. Quant aux éléments de calcul sur lesquels l’application s’exécute, ils se connectent simplement à ce pool via la structure de réseau utilisée.
C’est donc ce que nous entendons par une séparation claire des rôles. Dans le second cas, ce n’est pas clair, car chacun de ces nœuds a la capacité à la fois de fournir des ressources en termes de capacité et, en même temps, de consommer de la capacité de stockage et de la bande passante réseau, ainsi que des cycles de calcul. Vous devez donc vous demander si vous n’êtes pas en train de vous positionner en tant que fournisseur de stockage – disons que vous vous trouvez sur le nœud de gauche ici – et que vous fournissez de la capacité à vos voisins situés à droite.
Si l’on ne prend pas de précautions particulières, on risque en fait de réduire, sans s’en rendre compte, la qualité du service que l’on offre à ses voisins. Tout simplement parce que vous vous occupez en quelque sorte de votre serveur autonome et que vous ne vous rendez pas compte de l’effet domino que cela a sur les utilisateurs voisins. C’est un point très important. Dans l’autre cas, vous y pensez constamment : c’est comme si votre travail consistait à fournir de l’espace de stockage à un public plus large et que vous vouliez vous assurer que rien ne vienne entraver cela. C’est un peu plus difficile à réaliser lorsque vous utilisez des systèmes hyperconvergés.
La philosophie générale ici consiste donc parfois à surdimensionner les ressources, simplement pour disposer d’une marge de manœuvre supplémentaire et en tirer un peu plus de flexibilité. Du point de vue des réseaux sociaux, ce sont là quelques-uns des éléments qui guident en quelque sorte l’orientation des personnes en charge de ce domaine, et c’est assez curieux car j’observe souvent ce phénomène : je discute avec des clients des deux côtés de la barrière, voire au sein d’une même entreprise, qui occupent des rôles différents.
La plupart des administrateurs de stockage avec lesquels j’ai discuté – et dont beaucoup d’entre vous font peut-être partie du public aujourd’hui – ont une mentalité du genre : « Je suis un spécialiste des opérations spéciales, je dois m’assurer de contrôler toute cette capacité et mon objectif est d’offrir le plus haut niveau de service à mes utilisateurs en centralisant ces ressources et en veillant à ce qu’il n’y ait jamais de panne, et que le temps de réponse et le débit soient conformes aux attentes de chacun. »
Et je dois alimenter ce SAN central selon les besoins pour m’assurer de pouvoir renouveler le matériel afin qu’il soit le plus moderne et le plus performant possible, et pour éviter tout ce qui pourrait laisser présager une panne susceptible d’avoir un effet catastrophique sur tous mes clients. En réalité, le spécialiste de l’hyperconvergence est généralement quelqu’un qui s’occupe déjà de l’administration de la virtualisation : que vous soyez administrateur vSphere, Hyper-V ou KDM, vous gérez généralement cet éventail plus large d’exigences ; vous vous occupez donc de la puissance de calcul et de l’équilibrage de charge entre les différents serveurs.
L’accent est beaucoup plus mis sur les applications. Et vous gérez cela principalement du point de vue de l’hôte plutôt que du côté du stockage. Il est également essentiel que vous soyez bien habitué à l’auto-provisionnement, c’est-à-dire à vous attribuer de la capacité et à puiser dans ce pool. Vous voyez donc qu’il s’agit de deux façons différentes d’envisager les choses. Et pour quelqu’un qui effectue cette transition, quel que soit le côté d’où il vient, cela peut nécessiter un petit effort de réorientation mentale.
Vous avez également des préférences différentes en matière de fournisseurs, selon que vous abordez la question sous l’angle d’un SAN centralisé ou sous celui des serveurs. Ainsi, les entreprises avec lesquelles vous travaillez et auprès desquelles vous achetez du matériel peuvent être très différentes, ce qui peut se refléter dans vos critères de sélection. L’hyperconvergence exerce un attrait et un charme considérables. C’est le cas depuis, je dirais, environ trois ans maintenant. La première chose qui saute aux yeux, c’est que l’hyperconvergence, ne serait-ce que d’un point de vue visuel, quand on voit tous les éléments regroupés, semble très, très simple. Elle ne concerne en réalité qu’un seul type de matériel : les serveurs.
Je n'ai donc pas affaire à trois éléments distincts : la partie calcul, le stockage et le réseau ont tous été combinés et regroupés dans cette offre unique. Je pense que cela est souvent présenté comme étant moins cher, ou « moins onéreux » – je suppose que c'est le terme approprié –, car on considère que les services standard peuvent utiliser du matériel moins coûteux que les grandes baies de stockage propriétaires, qui comportent beaucoup d'autres composants métalliques et autres éléments.
Et puis… quand on regarde certains des schémas présentés ici et là, on pourrait en conclure que les solutions hyperconvergées doivent forcément être plus rapides. En effet, elles ne subissent pas les délais liés au transit sur un réseau pour accéder au stockage, puisque celui-ci est local, sur la machine même. Nous allons donc examiner tout cela de plus près. Et il y a une petite mise en garde que je tiens à vous faire tout au long de cette présentation. Bon nombre des produits hyperconvergés que l’on voit sur le marché, bien qu’ils soient commercialisés auprès des grandes entreprises pour des applications de grande envergure, ont en réalité été conçus pour des scénarios relativement modestes et à usage général.
Ils fonctionnent très bien avec des charges légères, surtout lorsque les tâches peuvent être facilement réparties, notamment dans le cas d’une application distribuée où l’on peut se dire : « Bon, je peux soit exécuter deux instances sur deux nœuds, soit quatre instances sur quatre nœuds, et je peux gérer ça de cette manière. » C’est avec les applications monolithiques que les choses se compliquent un peu. Beaucoup de systèmes de gestion des données, par exemple, sont très lourds, sollicitent énormément les E/S, et leur architecture est de nature linéaire : ils ne peuvent pas être répartis sur plusieurs nœuds. C’est là que les choses se compliquent et que vous risquez de rencontrer des problèmes en essayant de les intégrer.
C'est donc une décision immédiate que vous devez prendre lors de votre analyse, lorsque vous évaluez les différentes solutions possibles pour résoudre votre problème. Nous constatons notamment que, bien que le matériel soit tout à fait capable de répondre à des exigences de performances très élevées, la pile logicielle mise en place pour y répondre devient en réalité un goulot d’étranglement. Il s’agit donc d’un goulot d’étranglement côté serveur qui entraîne ce ralentissement des performances auquel on ne s’attendrait pas en examinant le schéma du réseau.
Et comme les systèmes hyperconvergés sont conçus pour être faciles à utiliser, vous constaterez souvent qu’il est impossible d’intervenir pour ajuster les paramètres. En gros, on se contente des paramètres par défaut et on travaille avec ça. Cela peut conduire à ce que nous appelons, dans le secteur du temps réel, un « comportement non déterministe ». On observe certaines variations en raison de la manière dont le système tente de mettre en place une sorte de partage du temps. Il y a là une préoccupation très importante que nous avons découverte au cours des dernières années, pendant lesquelles nous avons travaillé sur ce sujet et observé d’autres offres : parmi tous les cœurs que l’on voit sur ces serveurs, un seul serveur – en réalité un seul cœur – est utilisé pour gérer les E/S.
Et cela peut être la principale cause de ce ralentissement. Comme je l’ai déjà dit, l’un des risques à prendre en compte est que, sans vous en rendre compte, vous puissiez provoquer cette concurrence pour les ressources en surchargeant un ou deux des nœuds de votre ensemble, qui en compte cinq. Et ce sont justement ces nœuds-là dont tout le monde tire sa capacité.
Et cela n’est pas très évident. Surtout si l’on a l’habitude de travailler uniquement du point de vue du serveur. Maintenant, que pouvons-nous faire à ce sujet ? Eh bien, l’architecture mise en place par DataCore pour les systèmes hyperconvergés est très, très simple et offre des performances très élevées. En effet, la catégorie d’applications pour laquelle on nous a demandé de concevoir ces systèmes exige une latence minimale, c’est-à-dire une réponse ultra-rapide, ainsi qu’un rapport qualité-prix très attractif ; c’est-à-dire le prix que vous payez par IOP.
Et en effet, certains de ces systèmes ont été soumis à des tests approfondis par le Storage Performance Council afin d’évaluer leurs performances par rapport à d’autres équipements. Dans l’exemple que je vous présente ici, il s’agissait d’un système très basique, mais qui s’est révélé extrêmement performant en termes de capacités. Ce petit système à deux nœuds a établi le record mondial d’E/S hyperconvergées sur le test SPC-1 IOPs ; il s’agit de charges de travail de type transactionnel particulièrement exigeantes, typiques des environnements OLTP.
Et les IOP sont parfois un peu trop mis en avant. En réalité, ce qui intéresse la plupart des gens, c’est la quantité de travail utile que l’on peut accomplir, et ce, à un certain prix. Ces deux critères, notamment en termes de latence, sont donc essentiels pour ces chiffres. Non seulement la solution hyperconvergée présentée ici était la plus rapide, mais elle offrait également le temps de réponse le plus court, inférieur à la milliseconde. Il s’agissait de 220 microsecondes, avec un IOP de 10 centres SPC. C’est ce que nous appelons une rentabilité inégalée.
Il s’agit d’une norme du secteur. Vous verrez : si vous vous rendez sur le site web de SPC, vous constaterez que plusieurs des plus grands et des plus performants fournisseurs de solutions de stockage ont publié leurs travaux, et vous pourrez voir comment DataCore se positionne à leurs côtés, même avec ces configurations très économiques. Je tiens toutefois à préciser que, comme le montre l’image que je viens de vous présenter, DataCore ne commercialise que des logiciels ; nous travaillons donc en partenariat avec des fournisseurs de matériel, qu’il s’agisse de Lenovo ou de Dell. Vous choisissez le fournisseur de serveurs et nous nous chargeons de tout assembler ; notre partenaire agréé se charge alors de vous proposer une solution clé en main.
Et dans de nombreux cas, nous tirons pleinement parti du matériel dont vous disposez déjà ; c’est là tout l’intérêt : vous avez déjà dépensé beaucoup d’argent pour cet équipement, alors autant l’utiliser. L’une de nos forces, et ce qui nous distingue, c’est notre capacité à exploiter tous les cœurs de ces serveurs et à gérer les E/S en parallèle, là où d’autres se contentent de les limiter à un seul thread.
Nous proposons d’autres webinaires où nous abordons brièvement l’E/S parallèle. Vous pourrez ainsi constater comment cette technologie vous permet d’accomplir davantage de travail en moins de temps, tout en réduisant le nombre de machines nécessaires. Ce sont là des caractéristiques essentielles et des atouts distinctifs de l’offre DataCore. Passons maintenant à un exemple concret. Je voudrais m’appuyer sur une étude de cas réalisée auprès d’une société de central d’appel d’urgence 911. Il s’agit d’un service. Il s’agit d’une agence gouvernementale de l’Oregon. Heureusement, nous connaissons tous assez bien ce service et nous n’avons pas à appeler le 911 régulièrement. Mais vous pouvez imaginer à quel point il est vital de passer un appel et de s’assurer que ces systèmes transmettent rapidement les informations, afin que les opérateurs et les premiers intervenants disposent tous des informations les plus récentes.
Donc, si… Je vais vous fournir un lien dans la diapositive suivante, je crois, qui vous donnera un peu plus de détails à ce sujet. Mais le problème, c’est que ce centre d’appel constatait que ses requêtes et ses entrées vers son serveur SQL Back-end, qui constitue la pièce maîtresse de son environnement, ne recevaient tout simplement pas de réponse assez rapide pour lui permettre de respecter les accords de niveau de service qu’il avait définis afin d’apporter une réponse suffisamment rapide aux personnes se trouvant à l’autre bout de la ligne.
Et ils subissaient des latences très élevées. Ils utilisaient des périphériques de stockage classiques, installés sur une plate-forme surélevée. Ils avaient également des objectifs très précis en matière de disponibilité et de perte de données. Comme vous pouvez le constater ici, ils n’arrivaient pas à les atteindre. Ils n’y parvenaient pas et se trouvaient clairement confrontés à un problème ; lorsqu’ils ont examiné la question d’un point de vue financier, en cherchant comment résoudre ces problèmes, ils se sont rendu compte que toutes les alternatives qui leur étaient proposées, qu’il s’agisse d’une solution hyperconvergée ou de l’ajout simultané de plusieurs baies de stockage, nécessitaient d’importantes mises à niveau en profondeur et des investissements considérables.
Et cela ne pouvait tout simplement pas se justifier. Ils ont donc analysé cette conclusion et ont finalement choisi DataCore pour répondre à leurs besoins. Voici un petit schéma, juste pour vous donner une idée du déroulement des opérations, comme vous pouvez vous y attendre. Je regardais justement hier soir l’une de ces émissions, intitulée « 911 ». Je ne sais pas, je ne la recommande pas forcément. Mais elle donne une idée de ce qui se passe en coulisses. Et ce qui… Une partie du problème ici, c’est que tant le texte saisi concernant ce qui se passe sur le lieu de l’urgence que les enregistrements audio – toutes ces informations doivent être transmises, et une connaissance de la situation doit être fournie aux premiers intervenants, qu’il s’agisse des forces de l’ordre ou des pompiers ; tous ces intervenants doivent être informés très rapidement, la plupart de leurs SLA étant fixés à 90 secondes.
Ils doivent traiter toutes ces informations, les transmettre à une personne capable d’intervenir pour sauver des vies ou, dans certains cas, pour empêcher un agent des forces de l’ordre de s’approcher d’une personne susceptible de représenter une menace pour lui. Et il se peut qu’ils n’en aient pas conscience. Pour y parvenir, il faut évidemment des performances optimales en termes de latence, plutôt qu’en termes de débit, car même si ce dernier est un critère intéressant, ce n’est pas le plus important dans ce contexte.
Une fois le système hyperconvergé DataCore mis en place, ces latences, qui dépassaient les 200 millisecondes au niveau du fonctionnement de leur serveur SQL, ont disparu. Je crois que c’est le nom de ce monsieur qui a évoqué ce point : elles ont tout simplement disparu, à tel point que les opérateurs, lorsque cela s’est produit, après la mise en place de cette nouvelle fonctionnalité, ont déclaré en substance : « On dirait que quelqu’un a actionné un interrupteur et que tout est devenu ultra-rapide. » Et ce résultat a été obtenu grâce à cette transition vers un système hyperconvergé DataCore. L’autre effet notable est qu’ils rencontraient des difficultés pour mettre en place leur site de reprise après sinistre. Ainsi, si leur site principal, d’où ils traitent ces appels, subissait une panne ou nécessitait des travaux de maintenance importants, ils devaient se rendre sur un autre site, ce qui pouvait entraîner plusieurs minutes d’indisponibilité pendant lesquelles les appels au 911 restaient pratiquement sans réponse.
Personne ne s'en rend compte. Après avoir mis en place un cluster étendu avec DataCore entre ces deux sites, distants d'environ deux miles, les opérateurs n'ont même pas remarqué que le service avait été basculé vers le site de reprise après sinistre, puis rétabli sur le site principal, pendant les périodes de maintenance. La transition s'est faite de manière tout aussi fluide. Cela vous donne, je pense, une idée de la rapidité avec laquelle DataCore traite ces requêtes d'E/S.
Mais cette solution était également importante et réalisable, car elle s’avérait finalement moins coûteuse. En conclusion de cette migration, ils ont constaté qu’ils avaient réduit leur infrastructure de plus de 60 % en adoptant ce système hyperconvergé ; ils avaient réduit le nombre d’hôtes physiques nécessaires à son fonctionnement, car ils avaient regroupé l’ensemble de ces fonctions sur un nombre réduit de serveurs assurant une double fonction, et ils ont également réalisé d’importantes économies sur leur licence de serveur SQL, car ils disposaient de moins d’instances de celui-ci.
Ce n’est pas quelque chose auquel on pense spontanément lorsqu’on met en place ce type de solution, mais il s’agit d’un avantage financier important lié à une implémentation réussie de l’hyperconvergence. Une partie de ce dont ils parleront, et dont parlent plusieurs clients de l’hyperconvergence lors d’une deuxième phase de discussion, ne concerne pas seulement les performances, la faible latence et la haute disponibilité, mais aussi les fonctionnalités qu’ils peuvent exploiter pour améliorer leurs procédures de restauration et réduire au minimum les opérations de sauvegarde et de restauration sous Windows ; des opérations qui, normalement, auraient nécessité des produits de sauvegarde distincts, ce qui leur aurait causé un certain retard et une certaine incertitude.
Nous proposons notamment des solutions telles que la protection continue des données (CDP), qui a aidé bon nombre d’entre eux à lutter contre les ransomwares. Ce n’est pas négligeable de nos jours. Cela fait beaucoup parler de lui dans les médias. La CDP est, en substance, un moyen qui enregistre, un peu comme un magnétoscope numérique, le flux d’opérations d’entrée-sortie (E/S) vers les volumes critiques et qui permet de remonter dans le temps jusqu’à un moment antérieur à l’attaque par ransomware et de restaurer les données à partir de là.
Vous pouvez donc dire à ces personnes qui piratent votre système : « Désolé, elles n’ont aucune importance. » Car nous pouvons nous en remettre complètement. Cela étant dit, parlons un peu de la configuration dans son ensemble. L’une des choses que vous êtes tout à fait capable de faire avec le système hyperconvergé de DataCore, c’est d’évoluer en fonction de vos besoins. Vous pouvez facilement commencer avec un système, qui à l’origine pouvait être aussi modeste que deux nœuds, puis le faire évoluer sur place, non seulement en ajoutant des systèmes similaires, mais aussi en exploitant les serveurs que vous avez déjà dans votre salle de serveurs et en les réaffectant à ce rôle. Ils n’ont donc pas besoin d’être identiques.
Et c’est une règle que beaucoup d’autres concurrents sur ce marché vous imposent : ils vous obligent à disposer de machines dans chacun de ces nœuds, ce qui vous lie les mains. Le deuxième élément sur lequel je souhaite attirer votre attention est que certains de ces nœuds peuvent être axés sur le stockage – c’est-à-dire qu’ils fournissent une grande capacité – tandis que d’autres peuvent être exclusivement dédiés au calcul. Vous pouvez bien sûr combiner ces éléments comme bon vous semble, et de mon point de vue concernant les licences et la tarification, vous constaterez que le nombre de nœuds n’a en réalité aucune importance, puisque tout est basé sur la capacité.
Si l’on examine la manière dont le logiciel DataCore est déployé, on constate qu’elle est assez inhabituelle, ce qui constitue un autre élément qui nous distingue. Ainsi, dans les schémas que je vous présente, partout où vous voyez ces deux flèches bleu turquoise à l’horizontale, cela correspond à une instance du logiciel DataCore en cours d’exécution. Ainsi, bon nombre de nos clients qui, par le passé, exploitaient des SAN centralisés, les ont utilisés pour mettre en commun et virtualiser des baies de stockage provenant de fournisseurs tiers, qu’il s’agisse de Dell, EMC, Hitachi, IBM ou d’autres encore.
Et nous intervenons en amont en tant que couche de mise en cache et de haute disponibilité, qui regroupe ces ressources collectives et donne l’impression qu’elles proviennent potentiellement du même fabricant. Ce même logiciel peut également être déployé, et les mêmes licences peuvent être utilisées lorsque ces périphériques de stockage arrivent en fin de vie et que vous les remplacez par un stockage à connexion directe ; il y a du stockage local sur les serveurs où DataCore est exécuté, et c’est la deuxième image que vous voyez ici, à partir de la gauche.
Vous pouvez donc immédiatement constater qu’il s’agit là de votre premier niveau de consolidation. Et à un certain moment, si vous procédez étape par étape, vous aboutissez à un scénario d’hyperconvergence, où tout s’intègre parfaitement et de manière ordonnée au sein même des serveurs, avec les applications, le stockage et l’ensemble des réseaux combinés. Je parlerai de la quatrième image dans un instant, mais il s’agit d’un hybride de ces deux scénarios. Je vais laisser planer un peu de mystère à ce sujet.
Si vous travaillez directement sur un système hyperconvergé, vous vous demandez sans doute comment tout cela fonctionne, notamment en matière de provisionnement. Si vous êtes administrateur vSphere, cela vous paraîtra très, très familier. Nous tirons parti d’une fonctionnalité appelée VVOL. Les VVOL vous permettent essentiellement de consulter le catalogue des ressources disponibles que vous pouvez provisionner, qu’il s’agisse de stockage très haute performance, de stockage de milieu de gamme ou de stockage secondaire pour les archives volumineuses. Il vous suffit de sélectionner et de spécifier ces ressources au moment de la création de vos machines virtuelles, comme vous le feriez pour n’importe quel magasin de données, et DataCore répond à ces exigences en fonction des types de disques et de la qualité de service que vous avez demandés.
Ainsi, une fois le système mis en place, vous n’avez pas besoin de vous soucier de la « magie » que DataCore opère en coulisses ; cela ressemble tout simplement à vos opérations habituelles de provisionnement et de configuration des machines virtuelles vSphere, à l’ajout de disques, etc. Et tout cela relève d’un stockage basé sur des politiques. On utilise parfois des termes tels que « or », « argent » et « bronze » pour désigner les différents niveaux de service et les exigences de disponibilité.
Si vous venez de l'univers Microsoft Hyper-V et que vous êtes un adepte de Microsoft System Center Virtual Machine Manager, le principe est le même. Vous utiliserez l'interface de provisionnement qui vous est familière pour créer ces machines virtuelles, et vous verrez ces pools de stockage à votre disposition, que vous pourrez exploiter et associer à votre machine virtuelle.
L'idée générale est donc de vous épargner les subtilités de la gestion du stockage afin que vous puissiez simplement répondre aux besoins de capacité que vous souhaitez, ainsi qu'aux exigences de disponibilité et de performances que vos utilisateurs vous demandent de respecter. Dans la pratique, nous constatons que ce même logiciel est utilisé de multiples façons. Cette illustration vous donne donc un aperçu de la diversité des cas d’utilisation auxquels vous pourriez être confronté. Au centre, nous avons ce qui était auparavant un SAN à trois niveaux, où DataCore est utilisé pour regrouper ces baies hétérogènes.
Dans le coin supérieur gauche, on voit un cas où cette même pile logicielle a été configurée sous forme de cluster hyperconvergé pour les applications de niveau 1 qui exigent les meilleures performances et la latence la plus faible, mais qui sont en principe isolées du rest système. Notez ici que, sur les sites de reprise après sinistre (DR), ce même logiciel peut être utilisé pour normaliser ou standardiser la manière dont s’établissent les connexions entre le site principal et le site de reprise après sinistre, ou entre le site principal et les bureaux distants et succursales.
Et tout cela peut être géré de manière centralisée. En effet, le caractère propre à ces sites – ce qui était autrefois une simple succursale peut se transformer en site de reprise après sinistre – permet de simplement déployer et reconfigurer le système, de sorte que l’élément en haut à droite finisse, au fil du temps, par ressembler davantage à celui situé en dessous, à mesure que la définition et les exigences de cette succursale se sont amplifiées. Et tout cela s’est fait sans aucune refonte complète.
En fait, nous commençons simplement à configurer des ressources supplémentaires et à lui permettre d’y accéder, ce qui modifie son rôle. Il en va de même si vous essayez de mettre en place une reprise après sinistre vers le Cloud. Imaginons que vous souhaitiez transférer une copie depuis votre infrastructure sur site vers Azure ou AWS ; dans ce cas, vous disposeriez, par exemple, d’un ou de plusieurs systèmes hyperconvergés sur site, qui effectueraient une réplication vers des instances du logiciel DataCore hébergées dans ce Cloud public.
On aurait vraiment l’impression d’être dans un centre de colocation ou dans une simple succursale. Il n’y a en réalité aucune différence, si ce n’est la manière dont cette capacité est gérée. Je tiens à souligner ici plusieurs avantages. En fin de compte, lorsque les utilisateurs évaluent notre produit, quelques critères permettent de distinguer ce qui le différencie et ce qui le rend exceptionnel. Cela concerne généralement la réactivité du système et le rapport qualité-prix, mais aussi la flexibilité. Ainsi, plutôt que de vous imposer des contraintes en vous disant que votre solution hyperconvergée doit nécessairement ressembler à ceci parce que c’est ainsi qu’elle a été définie, nous vous donnons la possibilité de l’adapter, d’y apporter des modifications, afin qu’elle s’intègre à ce que vous avez déjà en place et que vous puissiez tirer parti de ces ressources, plutôt que de les abandonner simplement parce que l’architecture vous y oblige.
Voici donc la transition que je recommanderais à chacun d’entre vous, en particulier si vous venez d’un SAN à trois niveaux. C’est assez simple et cela repose sur vos propres ressources. Dans un premier temps, vous vous dites : « Bon, si je veux prendre le contrôle de la diversité dont je dispose, la première chose à faire est d’installer le logiciel DataCore entre mon hôte actuel et mes serveurs physiques ou bare metal, ce qui nous permettra de mettre en commun ces baies. Lorsque nous estimons que ces baies ont dépassé leur valeur financière et que nous les remplaçons par du stockage interne, le fonctionnement reste le même. Les performances peuvent même, dans certains cas, dépasser celles indiquées dans le graphique de gauche, car certaines de ces baies sont en effet un peu vieillissantes, si je puis m’exprimer ainsi.
Et ils ne sont tout simplement pas capables d’offrir les performances que permettent les disques SSD et flash, notamment flash NBME, lorsqu’ils sont directement intégrés à ces serveurs. Dans un deuxième temps de cette transition, on commence alors à se faire une idée de ce qui se passe lorsque ces serveurs assument une double fonction. Ils ne se contentent pas d’assurer le stockage, mais gèrent à la fois le stockage et la charge de travail informatique des applications.
Voilà donc le troisième chiffre. À ce stade, vous pourriez vous dire : « Tiens, j’aimerais configurer quelques nœuds de cette manière. Voyons comment cela fonctionne. Suis-je capable de garantir la qualité de service qui m’est demandée ? Suis-je à l’aise avec cette façon d’exploiter l’environnement ? » Et si c’est le cas, tant mieux. Vous en êtes là, et vous appliquez ensuite ce même comportement au rest vos nœuds. Vous constaterez peut-être aussi que vous avez quelques cas particuliers. Vous avez peut-être des machines « bare metal » qui ne feront jamais partie de votre infrastructure hyperconvergée. Tout simplement parce que personne ne prendra le temps de virtualiser cette application et de l’intégrer à un cluster.
Et vous pourrez alimenter et exploiter la capacité de manière plus appropriée en utilisant une solution hybride de ce type. Concrètement, je prends mon système hyperconvergé, qui se contente normalement de répondre aux besoins du cluster privé et d’établir des connexions Fibre Channel ou I-Scuzzy vers ces hôtes externes, qui sont strictement des consommateurs de capacité. Ils ne contribuent pas au pool de stockage.
Et eux aussi bénéficient des avantages en termes de performances, de disponibilité et de faible coût. C’est pourquoi je vous invite à consulter les diapositives. Prenez rendez-vous live demo nous pour une live demo . Le lien que je vous fournis ici vous permet d’en faire la demande : l’un de nos conseillers en solutions se mettra en relation avec vous et vous guidera tout au long du processus afin que vous puissiez constater à quel point c’est simple et comment cela s’applique à votre environnement et aux règles de gouvernance auxquelles vous êtes soumis. Nous répondrons ensuite à vos questions.
Danielle : Je vois qu'on a quelques questions ici, Augie. La première serait : quel est le prix de ton logiciel ?
Augie : D’accord. Oui. La tarification du logiciel est très simple. Elle est basée sur la consommation, c’est-à-dire sur la capacité que vous gérez ; autrement dit, la capacité que vous gérez et celle dont nous disposons pour alimenter le système hyperconvergé ou le SAN à trois niveaux, c’est la même chose. Et nous proposons trois modèles. En gros, l’un d’entre eux est le modèle haut de gamme « Top Run Premium », qui intègre toutes les fonctionnalités pour offrir les meilleures performances, ce que j’appelle en quelque sorte le « premier choix ».
Je propose également un modèle « premium ». Et puis il y a le modèle « économique », qui est vraiment destiné au stockage secondaire à grande échelle. N'hésitez pas à consulter l'un de nos fournisseurs de solutions à valeur ajoutée pour obtenir une offre complète.
Danielle : Super, merci. Et pour finir, avant de conclure, j'aimerais savoir si je peux utiliser votre logiciel dans le Cloud?
Augie : Oui, j’ai brièvement abordé ce sujet. Je ne me suis pas trop attardé dessus. Ce que nous observons de plus en plus, c’est une combinaison, en réalité undeployment Cloud hybridedeployment DataCore, où l’on commence par se concentrer principalement sur la gestion des activités sur site, et plutôt que de mettre en place un site distant ailleurs nécessitant des infrastructures physiques, vous utilisez Cloud , notamment Cloud public, pour créer cette deuxième ou cette troisième copie des données et disposer ainsi d’un plan de secours en cas de sinistre majeur, voire pour éviter les conséquences d’un tel sinistre.
Le logiciel, donc, c'est exactement le même package. Il suffit de l'installer sur une instance, sur une machine virtuelle ou sur plusieurs machines virtuelles, que ce soit sur AWS, Google Cloud ou n'importe quelle autre plateforme.
Danielle : Bon, je crois que nous… Je vois que nous recevons encore quelques questions. Si quelqu’un a d’autres questions, n’hésitez pas à nous envoyer un e-mail – vous trouverez toutes les informations nécessaires sur notre site web. Vous pourrez ainsi contacter un architecte de solutions qui se fera un plaisir de répondre à vos questions de manière plus personnalisée.
Sur ce, j’aimerais conclure en vous précisant, avant que vous ne partiez, que nous tiendrons absolument à vous fournir une version PDF de cette présentation, que vous retrouverez dans l’e-mail contenant le lien vers la rediffusion. BrightTALK vous enverra également un e-mail. Enfin, sachez que nous cherchons constamment à nous améliorer. N’oubliez donc pas de consulter ce webinaire avant de partir. Sur ce, passez une excellente journée à tous. Merci beaucoup.