Réalité ou mythe : recourir au même fournisseur de solutions de stockage pour garantir une haute disponibilité

Je tiens à vous remercier de vous joindre à nous aujourd’hui pour ce webinaire intitulé « Réalité ou mythe : recourir à un seul fournisseur de stockage pour garantir une haute disponibilité », présenté par DataCore. Notre intervenant du jour est Steve, directeur de l’architecture des solutions chez DataCore.

Steve Hunsaker : Merci Whitney, nous apprécions tout ce que tu as fait pour nous. Nous attendions ce moment avec impatience et sommes ravis de discuter avec [eux] pendant les 45 prochaines minutes de ce « Réalité ou fiction ». Je vais d’ailleurs tout de suite lever le voile : bien sûr, c’est de la fiction. [Rires] Je me souviens très bien de cette fois où j’étais dans mon centre de données, adossé à un mur, en train d’observer toute mon infrastructure, tous mes équipements, et je me suis dit : « Bon, j’ai des commutateurs redondants et des routeurs redondants, et pourtant mes données ne sont pas redondantes, et ce n’est pas très bon. » C’est donc de la fiction, et j’espère, dans le peu de temps dont nous disposons, vous expliquer pourquoi c’est le cas, ce que fait DataCore, comment nous y parvenons, ainsi que certaines de nos fonctionnalités et capacités. J’ai – j’ai évidemment une présentation PowerPoint, que je vais devoir faire. [Rires] Mais j’ai un tableau blanc derrière moi, ainsi qu’une caméra qui va basculer pour que nous puissions en quelque sorte dessiner cela ensemble sur le tableau blanc. N’hésitez pas à me faire part de vos questions ; j’y répondrai en temps réel. Sachez également que vous pouvez toujours m’envoyer un e-mail à l’adresse Steve.Hunsaker@datacore.com

Très bien. Je vais me lancer sans plus attendre. Partant du principe que je n’ai pas besoin de faire des comparaisons à périmètre constant, j’ai pensé qu’il valait mieux commencer par nos deployment , puis aborder tout ce dont nous sommes capables, la flexibilité qu’offre notre produit, ce que nous faisons et qui nous sommes ; tout cela se précisera au fur et à mesure de notre présentation.

Vous disposez sans doute tous de baies de stockage, et comme vous le savez, celles-ci peuvent être de type Fibre Channel, ISCSI ou NFS. SANsymphony un produit de stockage en blocs; nous devons donc nous concentrer principalement sur les technologies Fibre Channel et ISCSI. En partant de la gauche, nous avons un modèle de stockage traditionnel où vous disposez généralement d’une baie de stockage au sein de votre centre de données, et la plupart – je dirais dans 99 % des cas – des baies de stockage exigent évidemment que vous achetiez exactement la même marque et le même modèle pour transférer vos données vers un autre site. C’est pourquoi ce webinaire s’intitule « Réalité ou fiction », car ce que nous vous proposons, c’est de vous affranchir de cette contrainte. Bon, cela peut sembler un peu démodé, et ça l’est, car nous le faisons depuis 21 ans. Mais à mesure que nous passerons en revue ces deployment , je pense que vous verrez comment nous avons évolué, comment le secteur a évolué, et cela n’a fait que renforcer notre capacité à offrir des fonctionnalités et des capacités tout à fait uniques au secteur.

Ensuite, il y a la « convergence », qui me permet de prendre un stockage local pour en faire un SAN de classe entreprise et d’offrir des interfaces Fibre Channel ou ISCSI ; puis il y a l’« hyperconvergence », ce mot à la mode ces derniers temps – vous en avez sans doute tous marre de l’entendre –, mais c’est en réalité l’histoire qui se répète : les applications reviennent vers le stockage local. Et puis il y a la convergence hybride, que nous essayons de proposer comme une nouvelle approche : non seulement les applications peuvent revenir et le stockage être géré sur le même hôte que tous les autres invités, mais vous pouvez également disposer d’autres serveurs physiques, sous forme de Linux, d’Oracle, d’Unix ou d’autres systèmes – peut-être un cluster Hyper-V, ou encore VMware autre VMware auquel nous pouvons également fournir des disques. J’y reviendrai plus en détail un peu plus tard. Mais voilà quelques deployment à prendre en compte à mesure que nous mettons cela en œuvre.

L’une des choses que je pense – et c’est une de mes phrases fétiches – c’est que, en réalité, DataCore est au stockage ce que VMware aux serveurs. Je me souviens très bien avoir été inquiet, nerveux, voire hésitant, à l’idée de passer d’un serveur physique à un serveur virtuel. Cela peut sembler dater d’il y a 15 ans, mais honnêtement, il a fallu un peu plus de temps au secteur et à vous-mêmes pour reconnaître que le stockage pouvait lui aussi être virtualisé. Je voudrais donc vous présenter certains des avantages que la virtualisation des serveurs m’a apportés, et l’une des raisons pour lesquelles je ne reviendrais jamais en arrière. Nous ne reviendrions probablement jamais en arrière. Nous apprécions tous le fait de pouvoir déployer virtuellement un serveur qui offre mobilité, redondance et haute disponibilité ; tous ces avantages sont de véritables atouts qui nous facilitent grandement la vie, et nous ne voudrions pas qu’il en soit autrement.

Et je constate que la même chose se produit avec le stockage. Je ne voudrais vraiment pas qu’il en soit autrement. Ce sont exactement ces mêmes raisons qui me pousseraient à virtualiser mon stockage. Cela permet de déplacer ces disques virtuels, plutôt que des machines virtuelles, mais désormais, les disques virtuels peuvent être remplacés et déplacés pendant que le stockage sous-jacent est remplacé, mis à niveau ou complété, et il y a toutes sortes de… vous savez, l’idée, c’est qu’il faut toujours augmenter la capacité, les données ne cessent de croître, il y aura toujours un meilleur stockage, un stockage plus rapide, le secteur cherchera toujours à repousser les limites de performance et nous avons tendance à utiliser des termes marketing comme « éviter la dépendance vis-à-vis d’un fournisseur », ce qui nous permet d’être plus flexibles, de gérer le stockage sous-jacent tout en vous garantissant la disponibilité — à 99,999 % ou 99,9999 % — de votre stockage, même lorsque celui-ci est en maintenance ou en cours de remplacement, grâce à ce que nous apportons.

Voilà donc, en quelques mots, et c'est probablement la dernière diapositive sur laquelle nous allons nous attarder longuement, mais je voudrais vous expliquer la structure de cette diapositive en partant du bas pour remonter vers le haut. De cette façon – et je vais ensuite dessiner exactement la même chose au tableau blanc – vous pourrez voir, à travers des images, si vous voulez, des schémas illustrant comment cela fonctionne. Notre produit s'appelle donc DataCore SANsymphony. Nous sommes une entreprise exclusivement axée sur les logiciels. Nous proposons certes une appliance, mais nous sommes avant tout une société de logiciels, et le nom de ce logiciel est SANsymphony. SANsymphony permet SANsymphony d’orchestrer différentes baies de stockage, qu’elles soient ou non NVMe et si je suis un bon présentateur, je vais sortir mon petit marqueur – qu’il s’agisse NVMe Fibre Channel, ISCSI, NVMe SAS, NVMe SATA NVMe du cloud; prenons le temps de les passer en revue un par un.

Je peux intégrer NVMe d’un serveur, un LUN Fibre Channel provenant d’une autre baie, ou un nombre illimité de LUN Fibre Channel, un ISCSI , un disque de type SAS ou SATA à l’intérieur du boîtier, ou encore un JBOD connecté, ainsi qu’un dispositif cloud , et je peux exploiter tous ces protocoles de stockage pour les regrouper au sein d’un seul pool agrégé. Et c’est un concept intéressant en soi. Si, par exemple, je dispose de cinq téraoctets de NVMe, d’un LUN Fibre Channel de cinq téraoctets, d’un ISCSI de cinq téraoctets et d’un bac SAS-JBOD de cinq téraoctets, cela signifie que je peux créer un pool unique de 20 téraoctets à partir de chacun de ces quatre éléments constitutifs. Ensuite, au sein de ce pool, je peux commencer à exploiter les caractéristiques et fonctionnalités présentées au fur et à mesure que nous progressons dans cette diapositive ou cette illustration. Je peux alors classer automatiquement les blocs de stockage au sein de ce pool par niveaux, en promouvant ou en rétrogradant ce que nous appelons des « petites unités d’allocation de stockage » vers le haut ou vers le bas de la hiérarchie des niveaux, comme indiqué en [rouge]. Nous utilisons donc un algorithme basé sur la fréquence de lecture pour effectuer ces promotions et rétrogradations le long de cette hiérarchie.

Et c’est justement pour ça que, vous savez, traditionnellement, on n’aurait jamais, au grand jamais, songé à associer
un disque de NVMe à un disque SATA à 5 400 tr/min, mais avec nous, c’est possible, grâce à cette hiérarchisation automatique en temps réel. Nous le faisons en temps réel, ce n’est pas selon un calendrier ni rien de ce genre. Mais voici le point essentiel, et permettez-moi de rester concentré sur la réponse théorique au titre de notre discussion d’aujourd’hui. Peu importe ce dont vous disposez, je peux mettre en miroir ce pool de manière synchrone, en utilisant ce que nous appelons un disque virtuel. Je crée donc un disque virtuel au-dessus de ce pool, et maintenant, si j’ai – je ne suis pas très fan de citer des noms de fournisseurs, mais si je dispose d’un ou de plusieurs LUN Fibre Channel, ou encore ISCSI , et que je les ai tous regroupés, même avec des disques internes, cela représente un pool que je peux désormais répliquer vers un autre pool composé, peut-être, d’un stockage entièrement différent. Et c’est là tout l’intérêt, la réponse et la raison pour laquelle nous affirmons que le titre est une pure fiction.

Il y a donc de nombreuses fonctionnalités ; je ne vais pas m’attarder là-dessus, mais sachez simplement que nous disposons de fonctionnalités vraiment intéressantes. Ensuite, lorsque nous aborderons les méthodes d’accès, je pourrai prendre ces disques virtuels et les exposer via Fibre Channel, ISCSI, NFS SMB, ce qui permettra à tous nos hôtes externes d’utiliser le stockage que nous mettons à leur disposition. Je vais donc effacer mes schémas, revenir en arrière de quelques diapositives et passer à nouveau en revue les deployment , pour m’assurer que nous comprenons bien où nous allons. Je vais donc commencer par l’extrême droite et revenir sur la solution hybride. Ce que nous voulons dire, maintenant que vous comprenez peut-être un peu mieux ce que nous faisons, c’est que DataCore peut non seulement résider en tant qu’appareil virtuel sur, disons, unhypervisor VMware , en intégrant tous les LUN Fibre Channel et tous les ISCSI provenant du stockage existant dans vos environnements, mais qu’il est également capable d’utiliser tous les disques locaux, le JBOD connecté à ce serveur, de regrouper tout ce stockage en un pool, puis de fournir ce stockage au cluster ESX sur lequel je me trouve, ainsi qu’aux machines virtuelles hébergées sur ce même serveur. Je suis également capable, en parallèle, de présenter unSMB Fibre Channel ouSMB à des hôtes externes. Voilà donc votre approche hybride.

Bon, je vais maintenant me diriger vers le tableau blanc pour m’assurer que… j’ai bien réglé la caméra ici… et commencer à vous dessiner quelques schémas, tout en vous expliquant comment nous mettons en œuvre ce miroir synchrone. Vous devriez pouvoir voir ce schéma ici, sur mon tableau blanc. Alors, c’est parti. J’ai donc une baie, qui utilise la technologie Fibre Channel ; gardez à l’esprit qu’elle peut contenir tout un ensemble de LUN. J’ai une autre baie, qui peut être ISCSI, et je peux disposer de NVMe locaux, ainsi que d’un JBOD connecté à celle-ci, ce qui représente les différents types de stockage dont je peux disposer dans mon environnement. J’ai un hôte, que nous appellerons – appelons-le simplement DataCore pour l’instant. Je ne veux pas entrer trop dans les détails ici, mais il pourrait s’agir d’un hôte ESX hébergeant une machine virtuelle, ou simplement d’un nœud à part entière dans une configuration plus traditionnelle. Mais l’essentiel, c’est que je peux prendre chacun de ces éléments, les regrouper en pool et, comme je l’ai dit, les mettre en miroir sur un autre système.

Bon, voyons un peu comment développer ces deux nœuds : j’ai donc maintenant DataCore 1, avec l’ensemble de son stockage, et DataCore 2, avec l’ensemble de son stockage. Peu importe – ils n’ont pas besoin d’être identiques – rappelez-vous qu’il s’agit d’un scénario fictif – et je peux alors utiliser des chemins de mise en miroir qui, espérons-le, sont redondants ; ces chemins de mise en miroir peuvent être soit en Fibre Channel, soit ISCSI. J’en dessine deux, car ils peuvent bien sûr être redondants ; c’est d’ailleurs ce que nous souhaitons pour vous. Il peut y en avoir davantage ; ils peuvent être reliés via un commutateur, un commutateur Fibre Channel ou un commutateur Ethernet, ou bien être connectés directement de nœud à nœud. Alors, que sont ces nœuds ? Ces nœuds sont n’importe quel serveur x86. Donc, en réalité, ce que nous disons, c’est que vous installez – vous choisissez un serveur Lenovo, Super Micro, Dell, HP, etc., selon votre préférence – et vous installez DataCore sur ce nœud ; nous disposons alors de deux contrôleurs de stockage qui agrègent l’ensemble du stockage sous-jacent et sont capables d’effectuer une mise en miroir.

Voilà donc les chemins d’accès. Nous allons maintenant créer ce qu’on appelle un disque virtuel, et je vais vous le montrer dans notre interface graphique dans un instant. Nous disposons désormais d’un disque virtuel reconnu par ces deux nœuds. En d’autres termes, nous avons séparé les deux contrôleurs de stockage. Ce chemin de mise en miroir peut donc s’étendre sur une certaine distance, et nous souhaitons que la latence sur ces chemins soit inférieure à cinq millisecondes. Mais l’essentiel, c’est que mes données sont désormais réparties, et que je dispose d’une véritable haute disponibilité (HA) – en mode actif-actif, du site B vers le site A, ou peu importe, et oui, nous avons bien des clients qui ont ces deux sites dans le même rack, dans la même armoire, dans la même pièce, mais nous avons aussi des clients où ils se trouvent dans des pièces différentes, ou dans des bâtiments différents sur le campus. Ou dans des villes différentes. Nous avons réparti les données, et nous disposons d’une véritable haute disponibilité. Donc, un miroir synchrone, c’est en réalité, si vous voulez, un RAID 1. Et c’est un véritable miroir. Ainsi, quoi qu’il arrive à ce disque, les données sont écrites des deux côtés. Rappelez-vous que j’ai dit que ce disque peut être mis à disposition via Fibre Channel, ISCSI, etc.

Eh bien, si j’ai un cluster DSX auquel j’ai attribué ce stockage, il apparaîtra dans ESX en tant que magasin de données. Et ce magasin de données, lorsqu’on y écrit, utilisera les trois modes NPIO (round-robin, « most-recently-used » ou chemin fixe) et décidera du chemin à emprunter. Mais ESX voit parfaitement tous les chemins que je lui ai fournis pour ce magasin de données. Ainsi, dans un environnement en bon état de fonctionnement, lorsque tous les chemins sont présents et que tout est en mode actif-actif, le chemin de droite peut devenir indisponible – l’un d’entre eux, disons par exemple celui situé à gauche de DataCore 1. C’est là que nous entrons dans les détails et que nous abordons un aspect un peu technique concernant la manière dont nous gérons le miroir synchrone. Ce chemin de droite est reçu en mémoire vive (RAM). C’est un point essentiel, car certains de nos produits concurrents utilisent un disque ou une forme de stockage sur disque pour mettre en cache leurs droits d’accès et leurs lectures. Nous utilisons la mémoire vive (RAM) pour mettre en cache les droits d’accès et les lectures. Ces données sont ensuite transmises via le miroir – l’un des chemins de miroir – et sont reçues de l’autre côté en mémoire vive (RAM) ; nous envoyons alors un accusé de réception SCSI conforme à la norme ANSI T-10 et renvoyons cet [AK] dans le sens inverse via le – retour [inaudible 0:20:10] du chemin de miroir, vers la machine virtuelle ESX située à droite.

Nous assurons donc une réplication parfaite des droits des deux côtés selon ce mode « actif-actif ». En cas de sinistre, quoi qu’il arrive, quel que soit le composant à gauche — laissez-moi sortir mon stylo rouge —, quel que soit le sinistre et quel que soit le composant qui tombe en panne, ESX considère ces chemins comme inactifs, ou peut-être pas — peut-être que les chemins fonctionnent correctement, peut-être que le problème vient du stockage sous-jacent ; l’important, c’est que vous disposiez d’un autre côté actif avec cette mise en miroir synchrone ou cette véritable disponibilité RAID 1 de l’autre côté. Donc oui, il faut disposer d’un stockage ici et d’un stockage là. Si vous avez besoin de 100 téraoctets de capacité, il vous faut 100 téraoctets ici et 100 téraoctets là. C’est ainsi que nous parvenons à ce scénario fictif où il n’est pas nécessaire que le même fournisseur de stockage soit présent des deux côtés.

Je vais changer de caméra pour vous montrer maintenant notre interface graphique. Très bien. Je vais basculer vers notre interface graphique à laquelle je me suis connecté via un bureau à distance, et sur cet écran, vous voyez mes trois serveurs DataCore. J’ai un groupe de serveurs intitulé « Demo Lab », qui contient trois moteurs DataCore, ou serveurs. Nous support 64 serveurs au sein d’une même unité organisationnelle ou d’un même groupe de serveurs. Voici le SAN 1 ; j’ai pris la liberté de créer mon propre environnement de démonstration ici, je vous prie donc de bien vouloir en tenir compte. Mais à l’intérieur, je dispose de disques physiques de toutes sortes, et ce que j’essaie de démontrer, c’est que je peux avoir – par exemple – un LUN Fibre Channel, un ISCSI , ou encore des disques internes au serveur. Ces disques physiques peuvent être utilisés pour créer des pools, ce qui constitue la prochaine étape. J’ai donc ces disques physiques, et je vous montre les pools auxquels ils sont déjà affectés ; j’ai ici mes pools : le « Disk Pool 1 », le « CDP », et ces pools sont constitués de ces disques physiques.

Bon, je me suis lancé, et je vais aller un peu plus loin avec vous et [faire] ça – j’apprécie notre flexibilité et notre puissance, et je veux vous montrer que j’ai en effet un élément de pool de disques qui est en réalité un LUN « Nimble » en miroir, ou – et un LUN 3PAR. Nous avons donc la possibilité de mettre des LUN en miroir, et cette paire de disques physiques en miroir représente un disque à part entière au sein du pool de disques, ce qui est incroyablement résilient et fantastique. J’ai un pool de disques, puis j’ai des disques de pool virtuel, où j’ai, dans ce cas précis, j’en ai un appelé ESXi que j’ai créé, et comme vous pouvez le voir sur cet écran, il dispose d’un certain nombre de chemins qui sont soit actifs, soit connectés, et il vous indique qui sont les initiateurs et les cibles, ce qui soulève le point suivant : DataCore SANsymphony, ce serveur que j’ai dessiné derrière moi, le serveur dont nous avons parlé, est à la fois un initiateur et une cible simultanés. Ainsi, j’initie des opérations vers les systèmes back-end et je mets leur stockage à disposition, puis je deviens une cible pour les initiateurs du secteur, tels qu’ESX, Hyper-V, etc., et je peux leur fournir du stockage.

Et tout cela tient à la nature même des ports de serveur. J’ai donc essayé de mettre en place une sorte de « bonne pratique » ici, dans mon propre laboratoire, où je dispose de deux chemins d’accès front-end et de deux chemins d’accès miroir. Et comme je vous l’ai dit, je triche un peu, car je ne dispose pas de tout cet espace de stockage en back-end chez moi. [Rires] Mais vous auriez deux chemins d’accès back-end si vous disposiez d’un stockage back-end.

Donc, pour être tout à fait franc et vous montrer comment cela fonctionne, ce sont tous ISCSI; je les affiche donc via 229.1, 91.1, et laissez-moi vous montrer d’où je lis ces données, pour que vous puissiez voir : voici l’adresse IP et l’IQN dont nous parlons. Je vais effacer cela et remettre mon pointeur sur la flèche ; nous avons désormais deux chemins d’accès frontaux, deux miroirs, et tout cela passe par ISCSI. Si je vous montrais du côté de l’adaptateur physique, vous verriez que j’ai en fait… et j’aime bien faire ça parce que je suis un peu obsessionnel-compulsif, mais j’ai mis… Microsoft n’a toujours pas trouvé le moyen d’afficher l’adresse IP dans l’une des colonnes ici, et si quelqu’un sait comment faire ça, qu’il me le dise. Mais je les nomme simplement avec leur adresse IP et leur nom, afin de pouvoir tous les suivre. En effet, j’ai quoi, six… six [surnoms] qui sont tous basés sur l’IP et que j’ai nommés d’après leurs rôles et leurs fonctionnalités. Voilà donc un aperçu de la structure technique qui permet à tout cela de fonctionner, et de la manière dont nous y parvenons.

Ainsi, ces ports de mise en miroir ne font que transférer ces droits spécifiques à DataCore via ce canal vers le ou les autres nœuds DataCore afin d’assurer cette configuration RAID 1, cette approche de mise en miroir synchrone, de sorte que si l’un d’entre eux venait à tomber en panne, les données resteraient tout de même disponibles. Sur un disque virtuel, je dispose alors d’un grand nombre de fonctionnalités, comme nous vous l’avons montré dans le tableau où, en réalité, la majeure partie de mon ensemble de fonctionnalités se trouve ici, avec le disque virtuel. Je peux donc créer d’autres disques virtuels – les séparer et les désactiver, ce qui est en fait possible, car il s’agit d’une paire en miroir : cela me permet de les séparer ou de les dissocier pour en faire deux entités distinctes. Je peux remplacer le stockage, le déplacer, configurer un profil de stockage, et dans le secteur, nous aimons utiliser des termes comme « épingler » » : je souhaite « épingler » ce disque sur un SSD, ou peut-être l’inverse ; je sais que ce disque ne sera en réalité jamais consulté, je souhaite donc l’épingler vers les niveaux d’archivage inférieurs.

Je peux activer le CDP, qui est une fonctionnalité fantastique, qui me permet de disposer d’un journal et de revenir à une seconde précise, et, sur une période donnée, en fonction d’autres éléments de votre infrastructure, je ne peux pas simplement, vous savez, vous dire exactement combien de jours cela prendra pour vous, mais disons que c’est 14 jours : vous avez la possibilité de revenir à une seconde précise, exactement comme lors d’une restauration à partir du journal des transactions. C’est exactement le même principe : nous disposons d’un journal qui consigne toutes les opérations. Je peux utiliser snapshots et prendre un snapshot ce stockage ; je peux le répliquer pendant qu’il est mis en miroir, puis le répliquer de manière asynchrone vers un emplacement distant. Peut-être Azure, Google, AWS ou le garage de Monsieur Frost, je ne sais pas. Mais le fait est que nous pouvons le répliquer pendant qu’il est mis en miroir vers un troisième emplacement et vous offrir ainsi une certaine capacité de reprise après sinistre.

Je peux les regrouper et les distribuer à différents hôtes, et je vais vous le montrer tout de suite. Donc, ce disque virtuel ESX contient certaines informations et je vais les mettre en évidence ici un instant. Vous verrez qu’il est à jour, il est vert – laissez-moi prendre mon surligneur – j’ai un statut « vert – à jour » sur le SAN 1, j’ai une mention « à jour » en vert sur le SAN 2, et j’ai également une mention « à jour » sur le SAN 3. Vous constatez que l’accès à l’hôte est désactivé, car lorsque nous mettons en place une configuration en miroir à trois voies – ce qui s’adresse à tous ceux d’entre vous qui gèrent des environnements critiques et qui ont besoin d’une disponibilité de sept ou huit neuf, sans blague –, nous pouvons réaliser un RAID à trois voies sur ces différents pools de stockage, et ainsi garantir une très haute disponibilité de vos données. Mais nous ne mettons pas les trois en mode actif-actif ; nous optons pour un mode actif-actif-passif. Ainsi, si l’un d’entre eux venait à tomber en panne, le troisième prendrait le relais en mode actif. Laissez-moi effacer mes schémas et passer au point suivant que je souhaitais vous montrer.

Bon, ici, dans l’onglet « Paramètres », je veux juste insister sur ce point, car il s’agit de l’ID de mon périphérique SCSI, mon NAA, et vous verrez qu’AF29 correspond à mes quatre derniers caractères. Laissez-moi me connecter à ma machine ESX pour vous montrer comment ça s’affiche, et vous prouver que je n’invente rien, en vous guidant pas à pas. Si j’arrive à me souvenir de mon mot de passe. Oh non. Et vous verrez que je dispose de plusieurs périphériques de stockage – tant que nous y sommes, souvenez-vous que je vous avais dit que nous avions ISCSI tous ces chemins d’accès, laissez-moi sortir mon marqueur – voici tous les ports frontaux ; la raison pour laquelle nous en avons six, c’est que j’ai deux ports frontaux provenant de chacun des trois hôtes DataCore ; donc, encore une fois, avec cette configuration en miroir à trois voies, ESX les voit tous [connectés], il est capable d’utiliser quatre de ces six ports, ou même les six – DataCore ne négocie tout simplement pas l’accès aux hôtes, mais les six sont bien là [qui passent] ; j’ai donc mis en place une redondance complète, et c’est ainsi que ISCSI configuré. Ensuite, au niveau du stockage lui-même, vous verrez que le numéro NAA est AF29, exactement comme celui que je vous ai montré sur la console DataCore : AF29.

Voilà donc comment nous gérons les disques physiques : pour résumer brièvement, les disques physiques – qu’il s’agisse de disques Fibre Channel, ISCSI, à connexion directe ou internes – deviennent des disques physiques dans notre environnement. Nous sommes ensuite en mesure de combiner ces disques physiques à volonté pour créer des pools. Une fois le pool créé, je peux y créer des disques virtuels et bénéficier d’une multitude de fonctionnalités au sein de ces disques virtuels. Je suis connecté via les ports du serveur, via Fibre Channel ou ISCSI mes miroirs, mon front-end et mon back-end ; ma configuration est entièrement redondante et robuste, et je la réplique ensuite vers d’autres nœuds au sein de ce groupe de serveurs.

[Permettez-moi] de revenir à ma présentation PowerPoint, puis de résumer très rapidement : nous affirmons que vous ne devriez pas être lié à un seul fournisseur et que, en cette année 2019, vous devriez vous sentir libre d’utiliser différentes solutions de stockage. L’un des principaux arguments de vente et des points à prendre en compte : nous avons eu un client qui utilisait exclusivement le même fournisseur de stockage. Ce dernier a procédé à une mise à jour du firmware ; le client a appliqué cette mise à jour, ce qui a provoqué la panne de toutes ses baies, car la mise à jour a échoué. Par conséquent, si vos données sont critiques et doivent être hautement disponibles, il est en réalité judicieux de disposer de plusieurs solutions de stockage dans votre environnement, afin d’éviter de tout mettre hors service lorsque ce genre de scénario se produit.

Donc, c’est de la fiction. Et nous disposons de ces deployment : il n’y a vraiment aucun deployment que nous ne puissions mettre en œuvre. Je peux utiliser un disque local, des baies externes, les déployer de haut en bas, de gauche à droite, de côté à côté… peu importe. Nous incarnons la virtualisation du stockage à son plus haut niveau, et nous en avons tiré une leçon claire : nous ne reviendrions jamais à des serveurs physiques. Et, honnêtement, je ne reviendrai jamais à une baie de stockage physique. Nous disposons d’avantages dont nous sommes conscients, tant pour les serveurs que pour les utilisateurs ; nous proposons une gamme complète de fonctionnalités de classe entreprise ; nous avons expliqué les protocoles de stockage de A à Z, depuis la base jusqu’aux utilisateurs finaux ; il n’y a pas d’agents spéciaux ni rien de ce genre à installer sur les hôtes [bare metal] ou les hyperviseurs, car nous fournissons un disque en blocs SCSI conforme aux normes de l’industrie.

Et pour finir, peut-être, le haut de cette diapositive montre une illustration typique d’une baie, où j’ai deux contrôleurs, et ces deux contrôleurs se trouvent dans le même châssis en tôle. Et bien sûr, comme l’explique cette zone rouge ici, je ne peux pas séparer ces contrôleurs. Il faudrait que je sois complètement fou pour essayer de les séparer. Et pourtant, ces contrôleurs de stockage se qualifient eux-mêmes de « HA ». Je ne sais pas si je les qualifierais ainsi. Je parlerais plutôt de « tolérance aux pannes », car il y a bien deux contrôleurs. Mais ces deux contrôleurs utilisent le même fond de panier de disques partagé ; votre point de défaillance unique se situe donc au niveau des disques. Certes, ils peuvent être configurés en RAID, mais ils restent tous regroupés au même endroit. Donc, si vous voulez exactement le contraire, c’est-à-dire séparer complètement ces contrôleurs géographiquement et les placer au minimum dans des pièces différentes, DataCore est la solution qu’il vous faut.

Et bien sûr, vous savez, c’est assez stimulant et – ça donne à réfléchir – et ça offre une grande flexibilité : à mesure que de nouvelles solutions de stockage apparaissent, si j’ai besoin de plus de capacité, je peux brancher des périphériques sur un serveur, je peux mettre de côté un JBOD, aller chercher une autre baie… Nous ne contrôlons pas, ne vous demandons pas et ne vous dictons pas comment procéder – ni quel stockage acheter, mais comprenez bien que nous vous fournissons ce logiciel qui vous permet de prendre ces décisions commerciales et de réaliser des économies substantielles sur l’achat de solutions de stockage dépourvues de logiciel, car soyons réalistes : la plupart des baies de stockage de notre secteur ne fabriquent même pas le matériel de stockage – ce sont simplement des éditeurs de logiciels, tout comme nous, qui ont associé leur logiciel au matériel sur lequel ils s’appuient. Ils ne proposent peut-être que quelques services de stockage ; examinez donc la flexibilité offerte et, bien sûr, lorsque vous disposez d’une haute disponibilité (HA) sur deux sites différents, vous n’avez pas de point de défaillance unique ; vous bénéficiez d’un RAID 1 où, si je perds un côté, tout n’est pas perdu, car je peux toujours accéder aux données sur l’autre côté.

Nous arrivons à la fin de cette session. Je m’avance peut-être un peu, mais je tiens à vous remercier de votre présence, et j’aimerais demander à Whitney si… Je n’ai vu aucune question s’afficher. Whitney, as-tu vu des questions de la part de notre public ?

Whitney : Nous avons effectivement reçu quelques questions concernant la manière de vous contacter, le suivi et les informations relatives à DataCore ; je m'en suis donc occupée dans la rubrique « Questions ». Mais y a-t-il des questions spécifiques d'ordre technique auxquelles je ne peux pas répondre ? Non.

Hunsaker : D’accord. Bon, je vous invite, que vous soyez encore en ligne ou que vous regardiez cette vidéo plus tard, à n’hésiter pas à me contacter. Mon adresse e-mail est Steve.Hunsaker@datacore.com. Je suis toujours ravi d’échanger, de discuter et de trouver des approches créatives pour aborder le stockage, notamment la manière dont vous le gérez dans votre environnement, et d’apprendre les uns des autres.