5 Forts de nombreuses années d’expérience auprès de clients du monde entier et de tous secteurs, nos ingénieurs solutions Scality savent maximiser la protection et la disponibilité des données pour l’IT. Nous avons constaté qu’une architecture étendue multisite offre aux clients une disponibilité exceptionnelle, mais plusieurs facteurs clés de votre réseau doivent être pris en compte avant le déploiement. Autrement dit, nous voulons aider nos clients à optimiser leur réseau pour que le déploiement de Scality RING soit un jeu d’enfant. Alors, comment améliorer votre réseau pour qu’il soit en parfait état et prêt pour une architecture étendue ? Lisez la suite. Déploiements Scality RING étendus multisites : définir les objectifs de RPO et de RTO Une restauration rapide et une protection des données sans impact sur les performances ni la disponibilité des applications Pour la plupart des organisations, le modèle de déploiement privilégié de Scality RING est ce qu’on appelle une architecture étendue (stretched) : tous les nœuds d’un cluster sont répartis uniformément sur différents sites physiques (des zones de disponibilité, dans le jargon du cloud). Les architectures étendues sur deux ou trois sites sont courantes chez Scality. Cette approche de la protection des données garantit qu’un site entier — plus un autre serveur ou groupe de disques — peut tomber en panne tout en conservant un accès complet en lecture-écriture, avec un objectif de point de reprise (RPO) et un objectif de temps de reprise (RTO) nuls. Pourquoi est-ce important ? Cela signifie que même si un site est hors service ou inaccessible à cause d’une coupure de courant ou de problèmes réseau (ou de quelque chose de plus grave), vous restez protégé contre une autre panne sans impact sur la disponibilité des applications. Une protection maximale avec une restauration plus rapide et zéro perte de données Pour protéger et sécuriser les données sur plusieurs sites, RING est configuré en cluster étendu entièrement synchrone : l’écriture n’est confirmée à l’application qu’une fois les données entièrement inscrites sur un support persistant. Ce type de répartition des données sur plusieurs sites, associé aux capacités de protection de Scality, permet aux clients d’atteindre une durabilité des données de 14 neuf. C’est l’une des raisons pour lesquelles les organisations les plus exigeantes et les plus pilotées par la donnée confient leurs données critiques à Scality. Simplifier l’exploitation en cas de panne grâce aux architectures étendues synchrones Une autre façon de protéger les données sur plusieurs sites est la réplication asynchrone : deux RING indépendants se répliquent mutuellement tout ou partie des données. On y recourt lorsque la distance entre les sites est trop grande, ou le réseau trop lent, pour un RING étendu. Si cette approche a l’avantage d’autoriser de plus grandes distances entre datacenters, les organisations préfèrent généralement la protection synchrone d’un RING étendu, car elle simplifie l’exploitation en cas de panne. Outre un RTO potentiellement plus long et plus complexe, la réplication asynchrone implique toujours un RPO : une partie des données les plus récentes ne sera pas protégée sur le second site. Cela peut ne pas convenir aux besoins de protection de certaines organisations ou applications. Selon des facteurs comme le taux de modification des données de l’application et la bande passante ou la latence du réseau entre les sites, le RPO peut devenir trop important pour être toléré. Asynchrone et synchrone Réplication asynchrone entre RING Les données sont écrites dans RING et protégées sur tous les serveurs L’écriture est confirmée à l’application une fois les données inscrites sur un support persistant sur tous les serveurs Les données sont répliquées de façon asynchrone vers le RING cible Fonctionnement synchrone dans un RING étendu Les données sont écrites dans RING et protégées sur tous les sites L’écriture est confirmée à l’application une fois les données inscrites sur un support persistant sur tous les serveurs de tous les sites Réplication asynchrone ou fonctionnement synchrone En résumé, une architecture étendue synchrone avec des objectifs de RPO et de RTO clairs peut nettement améliorer l’impact métier. Les métiers peuvent définir ces objectifs avec l’IT, car ils sont généralement étroitement liés aux accords de niveau de service (SLA) entre l’application et ses utilisateurs, qu’il s’agisse de clients internes ou externes. Autres avantages d’un RING étendu : protection renforcée et efficacité accrue Un RING étendu présente d’autres avantages au-delà du RPO et du RTO. Par exemple, de nombreux clients utilisent Scality comme cible de sauvegarde. En envoyant les données vers un RING étendu, la sauvegarde est de fait immédiatement protégée contre la perte d’un site, ce qui peut éviter d’avoir à la copier vers un autre emplacement. Autre avantage d’un RING étendu : c’est une façon efficace de stocker et de protéger les données, ce qui compte à grande échelle. Certains de nos clients disposent d’enregistrements vidéo qui atteignent plusieurs dizaines de pétaoctets, impossibles à reproduire. Ces données précieuses doivent être protégées, mais le matériel nécessaire peut coûter extrêmement cher. Scality RING réduit ce coût au minimum. Économies : un RING étendu sur 3 sites réduit considérablement le surcoût matériel par rapport à une réplication sur 2 sites La protection de gros volumes de données sur un RING étendu sur trois sites représente généralement un surcoût d’environ 75 %. En comparaison, si ces données étaient répliquées entre deux RING, le surcoût serait de 100 % pour la copie supplémentaire, plus 33 % par site pour la protection locale. Par surcoût, nous entendons ici la quantité de matériel de stockage supplémentaire à provisionner pour garantir la protection des données en cas de double panne, y compris la perte d’un site. Conseil d’expert : identifiez et résolvez les problèmes réseau existants avant de déployer un RING étendu Dans environ un tiers des mises en œuvre d’architectures étendues, nous constatons des problèmes réseau à résoudre avant de déployer RING. Ces problèmes — de quelques erreurs de configuration mineures à du matériel obsolète — existent déjà dans le réseau du client et sont mis au jour au début de la mise en œuvre de RING. Pour éviter les retards et tirer immédiatement toute la valeur de RING, il est important de préparer votre réseau. Pour un déploiement optimal, nous recherchons généralement une bande passante d’au moins 10 Gb/s et une latence <5 ms sur le réseau étendu (WAN), même si cela peut varier selon la charge de travail et les attentes de performances du client. Comme indiqué plus haut, des problèmes peuvent survenir dans de nombreuses zones du réseau. Voici les problèmes les plus courants à surveiller et à corriger : Corriger la perte de paquets : on parle de perte de paquets lorsqu’un paquet réseau n’atteint pas sa destination, généralement pour éviter la saturation du réseau ou maximiser l’efficacité, et elle peut avoir de nombreuses causes. La mise en forme du trafic (traffic shaping), comme la limitation de débit ou de connexions, peut interférer involontairement avec le trafic RING. Quand des paquets sont abandonnés, l’émetteur réessaie après un délai d’attente — ce qui peut augmenter la latence, et le paquet renvoyé consomme de la bande passante supplémentaire, réduisant d’autant la bande passante disponible pour les autres applications ou le reste du trafic. Optimiser le routage : le chemin emprunté par les paquets sur le réseau est important pour un cluster de stockage distribué comme RING. Comme pour tout trafic réseau, il faut s’assurer qu’il emprunte la route la plus rapide sur les liens les plus adaptés. Nous avons vu au Royaume-Uni un cas où les paquets destinés à un datacenter situé à 20 kilomètres parcouraient plus de 300 kilomètres vers le nord de l’Angleterre, puis 300 kilomètres pour revenir sur la côte sud. Cette distance rallongée entraînait une latence supérieure à ce que l’application pouvait supporter, avec des temps de réponse extrêmement lents. À retenir : concevez l’architecture réseau pour que les données puissent emprunter la route la plus rapide ! Éviter la saturation des liens : suivez ces recommandations pour éviter la saturation des liens, qui peut se manifester de plusieurs façons : Corriger les problèmes de routage sous-jacents : comme indiqué plus haut, un réseau qui achemine le trafic par des liens n’offrant pas assez de bande passante peut rapidement saturer le chemin et dégrader les performances de RING. Il suffit pour y remédier de corriger les problèmes de routage sous-jacents. Évaluer les pics d’utilisation et déterminer la bonne bande passante : les liens physiques sont souvent partagés avec d’autres applications, ce qui peut provoquer des comportements inattendus sur RING. Les pics d’utilisation ne sont pas toujours pris en compte lors de l’évaluation de la capacité disponible de l’ISL, avec des liens qui saturent à certaines heures ou lors de l’exécution de certains processus. Une politique de qualité de service (QoS) bien conçue peut atténuer ces situations, ou le provisionnement durable de bande passante supplémentaire réglera le problème. Dans le cadre d’une mise en œuvre de RING, de la bande passante supplémentaire est parfois nécessaire et promise par les métiers. Mais nous avons vu des retards dans sa mise en place, qui peuvent ensuite retarder le déploiement complet de RING. Prendre en compte chaque maillon de la chaîne : nous avons même vu des clients subir des temps de réponse lents pour l’utilisateur final parce que les connexions aux postes de travail n’étaient qu’à 1 Gb/s ; ils n’ont pu atteindre les performances attendues qu’après leur mise à niveau. Revoir les règles des systèmes de détection d’intrusion (IDS) : un RING étendu est un cluster de stockage distribué qui utilise donc beaucoup de connexions. Chaque objet ou fichier lu ou écrit par une application se compose d’au moins 12 fragments de données en back-end. Le nombre de connexions nécessaires entre toutes les ressources RING peut donc être important. Ces 12 fragments sont indispensables pour atteindre jusqu’à 14 neuf de durabilité, mais du point de vue d’un IDS, toutes ces connexions peuvent ressembler à une attaque réseau — ce qui peut conduire l’IDS à restreindre une partie du trafic. Il faut configurer correctement les règles IDS pour que les composants RING accèdent aux connexions dont ils ont besoin. Surveiller les problèmes de connexion des câbles : ah, la bête noire des administrateurs réseau ! Certains de nos clients aux exigences de performances élevées disposent de réseaux très rapides et ultra-fiables. Récemment pourtant, l’un d’eux a constaté une dégradation des performances sur l’un de ses liens. Rien n’avait changé dans cette partie du réseau, qui fonctionnait bien depuis longtemps : ce routeur (câble et port compris) n’a donc pas été examiné en premier. Quelques erreurs sont apparues sur le lien, mais la panne était intermittente et le problème n’a pas été identifié tout de suite — un lien instable (« flapping ») typique. Avec le temps, à mesure que le câble se dégage du port, le problème finit par se révéler pleinement : il peut alors être identifié et facilement corrigé. Utiliser un équilibreur de charge avec contrôle de santé : les mises en œuvre S3 de RING nécessitent un équilibreur de charge externe. Il permet d’exploiter toutes les performances de RING en répartissant le trafic sur plusieurs endpoints et en offrant un accès aux données parallèle et évolutif. Nous recommandons toujours un équilibreur de charge doté d’une fonction de contrôle de santé. Pourquoi ? Si un endpoint est hors service — sans contrôle de santé, les données continueront d’y être envoyées. L’application attendra une réponse jusqu’à l’expiration du délai, puis réessaiera en espérant tomber sur un endpoint fonctionnel. Cela se répétera et dégradera les performances front-end de l’application jusqu’au retrait de l’endpoint défaillant. Les équilibreurs de charge matériels peuvent aussi avoir des limites de débit, à prendre en compte lors du dimensionnement. Bonnes pratiques pour mettre en place une architecture étendue L’équipe avant-vente de Scality travaille généralement en étroite collaboration avec l’équipe IT de votre organisation pour comprendre vos besoins vis-à-vis de Scality RING. En fonction de vos exigences applicatives et de performances, elle formule des recommandations sur les exigences réseau. Dans certains cas, l’utilisation de RING peut révéler des défauts cachés de longue date dans le réseau, dont vous n’aviez pas conscience, comme des erreurs de routage ou du matériel obsolète (voir plus haut). Mieux vaut impliquer l’équipe réseau très tôt. Elle comprend ainsi pleinement la charge supplémentaire que RING fera peser sur le réseau, notamment en termes de bande passante. Cela laisse aussi le temps d’une éventuelle refonte, reconfiguration ou d’un investissement dans de nouveaux équipements ou liens. Les meilleurs projets de mise en œuvre sont ceux où toutes les parties prenantes IT, y compris l’équipe réseau du client, sont impliquées et communiquent régulièrement. Autres bonnes pratiques recommandées : Mettez en place des politiques de qualité de service réseau capables de prioriser le trafic RING, ou utilisez des VLAN dédiés à bande passante définie pour isoler le trafic RING et lui garantir un niveau de performances adapté. Mettez à jour les logiciels et firmwares des équipements réseau, pour plus de stabilité et de meilleures performances. Vérifiez bien qu’ils sont correctement configurés. Surveillez et analysez régulièrement le réseau pour identifier et traiter les causes sous-jacentes de latence, comme la perte de paquets ou la congestion. Comme le dit l’un de nos ingénieurs de mise en œuvre : « surveillez, surveillez, surveillez ; placez des sondes partout, surveillez chaque port et tracez-en les courbes ». Envisagez un service d’analyse réseau assuré par un tiers avant le dimensionnement de RING, afin d’obtenir une vision indépendante du réseau et de déceler et corriger les éventuels problèmes. Corriger les problèmes réseau peut aussi apporter d’autres bénéfices, comme libérer du débit ou renforcer la résilience. La gestion des réseaux est complexe et chronophage, mais elle est indispensable. Réussir avec Scality RING Scality RING aide les organisations de toutes tailles à atteindre une évolutivité et une sécurité inégalées, avec des performances de premier plan à un coût compétitif. C’est la solution de stockage de votre architecture de données cloud intelligente et flexible. Mais pour tirer le meilleur parti du déploiement, il faut avoir pris le temps de poser les bonnes fondations. Chez Scality, nous aidons nos clients à rentabiliser au maximum leur investissement en veillant à ce qu’ils aient posé les bases de leur réussite.
