SUSE Enterprise Storage sur serveurs HPE Apollo 4200 et Apollo

Transcription

SUSE Enterprise Storage sur serveurs HPE Apollo 4200 et Apollo
SUSE Enterprise Storage sur
serveurs HPE Apollo 4200 et
Apollo 4500
Utiliser les serveurs HPE à densité optimisée comme
modules matériels avec SUSE Enterprise Storage
Livre blanc technique
Livre blanc technique
Table des matières
Résumé pour décideurs ......................................................................................................................................................................................................................................................................................................... 3
Présentation générale.............................................................................................................................................................................................................................................................................................................. 4
Problème des entreprises .............................................................................................................................................................................................................................................................................................. 4
Défis de l'évolutivité ............................................................................................................................................................................................................................................................................................................ 4
Pourquoi SUSE Enterprise Storage ? .................................................................................................................................................................................................................................................................. 4
SUSE Enterprise Storage – Cas d'usage ........................................................................................................................................................................................................................................................... 5
Présentation générale de la solution.......................................................................................................................................................................................................................................................................... 6
Stockage d'objets – Principes de base ............................................................................................................................................................................................................................................................... 6
Architecture de SUSE Enterprise Storage avec Ceph .......................................................................................................................................................................................................................... 6
Solution .................................................................................................................................................................................................................................................................................................................................................7
Architecture de la solution ............................................................................................................................................................................................................................................................................................ 7
Valeur ajoutée par la solution HPE ....................................................................................................................................................................................................................................................................... 9
Valeur ajoutée par la solution SUSE..................................................................................................................................................................................................................................................................... 9
Serveurs .........................................................................................................................................................................................................................................................................................................................................9
Conseils de configuration ..................................................................................................................................................................................................................................................................................................12
Recommandations générales pour la configuration...........................................................................................................................................................................................................................12
Journalisation sur unités SSD ..................................................................................................................................................................................................................................................................................12
Sélection des éléments matériels.........................................................................................................................................................................................................................................................................13
Sélection des disques .....................................................................................................................................................................................................................................................................................................13
Nomenclature (BOM) ............................................................................................................................................................................................................................................................................................................15
SUSE Enterprise Storage 3 Deployment for HPE DL Series .............................................................................................................................................................................................................18
Configuration matérielle ...............................................................................................................................................................................................................................................................................................18
Instructions détaillées ...........................................................................................................................................................................................................................................................................................................19
Planification et prérequis.............................................................................................................................................................................................................................................................................................19
Réseau ..........................................................................................................................................................................................................................................................................................................................................19
Déploiement du système d'exploitation ........................................................................................................................................................................................................................................................20
Déploiement de SUSE Enterprise Storage ..................................................................................................................................................................................................................................................21
Validation du cluster SUSE Enterprise Storage ......................................................................................................................................................................................................................................23
Résumé...............................................................................................................................................................................................................................................................................................................................................23
Glossaire ............................................................................................................................................................................................................................................................................................................................................24
Pour plus de détails.................................................................................................................................................................................................................................................................................................................24
Livre blanc technique
Page 3
Résumé pour décideurs
Les architectures de stockage traditionnelles sont mises à rude épreuve par l'augmentation exponentielle des volumes de données,
résultat de l’expansion des big data et des données non structurées et de la prolifération des terminaux mobiles. Des architectures de
stockage émergentes (par exemple, le stockage des objets) peuvent aider les entreprises à faire face à ces tendances en mettant à leur
disposition des solutions de stockage peu coûteuses qui répondent efficacement à la croissance des besoins en capacité tout en offrant des
contrats de niveau de service (SLA) adaptés aux exigences opérationnelles et aux demandes de leurs clients.
Les sous-systèmes de stockage les plus performants sont conçus pour répondre aux besoins en stockage et aux temps de latence
critiques des données transactionnelles. Néanmoins, ils ne représentent pas toujours la solution optimale pour les données non structurées
et le stockage de sauvegarde ou d'archivage. Pour répondre à ces situations, de nombreuses qualités sont requises, dont fiabilité
exceptionnelle, potentiel scale-out considérable et réduction des coûts.
Les solutions de stockage d'objets sont conçues pour être déployées sur des serveurs standard, ce qui leur permet de proposer des coûts
d’infrastructure plus bas et une évolutivité supérieure à celle des sous-systèmes de stockage de fichiers sur serveurs. Les serveurs HPE Apollo
4000 constituent des modules de capacité de stockage complets et peu coûteux pour les solutions de ce type.
Avec les solutions open source, il est nécessaire de se préoccuper du support technique et de définir une vision capable d’égaler ou de
dépasser les capacités et les fonctionnalités disponibles avec l'infrastructure de stockage traditionnel existante. SUSE Enterprise Storage
permet de répondre à ces deux besoins grâce à un support technique performant et à son leadership dans la communauté Ceph. Avec SUSE
Enterprise Storage, les clients peuvent déployer et exploiter en toute confiance leurs clusters de stockage pour sauvegarder leurs
activités en cloud et leurs applications à travers une interface de stockage d'objets.
L'association du matériel HPE et de SUSE Enterprise Storage permet de définir une solution open source de stockage d'objets qui présente
les caractéristiques suivantes :
• Inclut une solution logicielle qui permet d'évoluer d’un péta-octet à plus de 100 péta-octets de données
• Réduit les dépenses d’investissement initial et le TCO par giga-octet
• Déploie un seul cluster de stockage défini par logiciel (SDS) pour le stockage d'objets et pour le stockage de blocs avec performances
basses à moyennes
• Utilise des solutions open source, ce qui permet de réduire les préoccupations en matière de provisionnement captif
• Propose un meilleur TCO d'exploitation et de maintenance du matériel que les serveurs en marque blanche
• Peut être configuré pour compléter le stockage d'objets par un stockage de blocs à performances réduites et à faible coût
Le matériel HPE vous donne la possibilité de choisir les modules de configuration les mieux adaptés à vos besoins. Les serveurs HPE Apollo 4510
Gen9, Apollo 4530 Gen9 et Apollo 4200 sont les mieux adaptés à ces objectifs. Ils permettent de trouver le juste équilibre entre
performances, coût au giga-octet, taille des modules de la solution et taille du domaine réseau impacté par les incidents.
Public ciblé
Responsables des technologies (CTO) et architectes IT qui recherchent une solution de stockage capable de gérer la croissance rapide des
données non structurées, du cloud et du e stockage des archives tout en maîtrisant les coûts d’infrastructure et de licences. Ce Livre blanc
s'adresse à des utilisateurs qui connaissent les défis liés à l’administration des datacenters et les meilleures pratiques de configuration et de
déploiement des datacenters – en particulier dans le domaine des systèmes de stockage. Il suppose également que le lecteur réalise à la fois
les défis et les avantages que peuvent lui apporter les solutions open source.
Livre blanc technique
Page 4
Présentation générale
Problème des entreprises
Les entreprises sont constamment à la recherche de solutions plus efficaces et moins coûteuses en réponse à des besoins de stockage de
données qui augmentent de façon exponentielle. Ces dernières années, la capacité de stockage nécessaire pour répondre aux exigences de
conservation des données a considérablement augmenté. Le coût au giga-octet et la facilité d'accès aux données sont des facteurs importants
au moment de choisir une solution capable d'évoluer rapidement et à moindre coût sur un certain nombre d'années pendant lesquelles
les capacités et les exigences de conservation des données vont sans doute augmenter en continu.
Les entreprises qui essaient de faire face à l'augmentation inexorable des volumes de données à l’aide de solutions de stockage traditionnelles
(fichiers/blocs) constatent que la complexité d'administration et d’exploitation de ces solutions a fortement augmenté, tout comme les coûts de
leurs infrastructures de stockage. Sur le long terme, l'hébergement du stockage dans un cloud public risque de ne pas répondre aux exigences
de coût ou de contrôle des données. En matière de performances et de contrôle, les équipements sur site continuent à offrir des avantages réels.
L'évolution massive des infrastructures traditionnelles sont est une opération coûteuse, et elles incluent des possibilités de performances qui ne
sont pas nécessaires pour les données « chaudes » ou « froides ». Le stockage d’objets sur une infrastructure standard est optimisé pour ce
cas d’usage, et représente un complément idéal pour une infrastructure existante. Le transfert des données archivées vers Ceph (plate-forme
open source qui stocke les données sur un seul cluster d'ordinateurs distribués) peut réduire le coût global du stockage tout en libérant les
capacités existantes pour les applications qui exigent les capacités d'une infrastructure traditionnelle.
Défis de l'évolutivité
Le stockage des données non structurées à grande échelle se heure à un certain nombre de difficultés :
Coût
• En général, les données non structurées et les données archivées sont écrites une seule fois ou/et deviennent stagnante au fil du temps.
Ces données stagnantes occupent un espace précieux dans les unités de stockage de blocs et de fichiers.
• Le stockage sur bandes est un excellent choix pour bénéficier du coût par Go le plus bas, mais il présente des temps de latence
extrêmement élevés. Les données non structurées et les données archivées peuvent être ignorées pendant de longues périodes, mais
elles doivent être disponibles en quelques secondes.
Évolutivité
• Les supports de données non structurées peuvent accumuler des milliards d’objets et plusieurs péta-octets de données. Les limites des
systèmes de fichiers en matière de nombre et de taille des fichiers et les limites du stockage de blocs en matière de taille des blocs
présentés présentent des défis significatifs pour les déploiements.
• En outre, les méthodes de stockage sous forme de blocs et de fichiers se traduisent par une accumulation considérable de métadonnées
et par un système dont le volume empêche de respecter les contrats de niveau de service (SLA).
Disponibilité et gérabilité
• Dans la plupart des entreprises, le stockage est en train de passer d'un déploiement de taille réduite et sur un seul site à des
configurations scale-out et éclatées géographiquement. Face à cette croissance effrénée une autre difficulté apparaît : comment assurer la
disponibilité et la sécurité de toutes les données ?
• Certaines solutions de stockage difficiles à administrer et à contrôler à grande échelle. La gestion des silos et les limitations des interfaces
rendent plus difficile le déploiement d'un nouveau système de stockage sur une infrastructure existante.
Pourquoi SUSE Enterprise Storage ?
• La possibilité de se limiter à des serveurs standard garantit le coût le plus bas possible pour un système de stockage sur disques, et avec des
modules que vous connaissez déjà.
• SUSE Enterprise Storage offre tous les avantages de Ceph, avec un réseau de support technique disponible et efficace.
• Ce système a été conçu pour une évolution illimitée, ou au moins de 1 péta-octet à bien au-delà d’une centaine de péta-octets de données.
• Un espace de noms non hiérarchisé (flat) et les métadonnées associées à chaque objet garantissent que très peu d’espace est gaspillé en
surcharge/overhead et que l’interface peut évoluer efficacement jusqu'à permettre l'accès à plusieurs milliards d’objets.
• Il suffit de configurer un cluster SUSE Enterprise Storage pour répondre simultanément à des besoins de stockage très différents.
• SUSE Enterprise Storage a été conçu pour être déployé, accessible et administré de n’importe quel emplacement.
Livre blanc technique
Page 5
SUSE Enterprise Storage – Cas d'usage
Stockage en cloud OpenStack
SUSE Enterprise Storage s’intègre parfaitement dans un cluster OpenStack®. En général, le système utilise un stockage de blocs derrière
OpenStack Cinder et un stockage d’objet Ceph au lieu de Swift. Ceph peut assurer le double rôle de stockage éphémère sur machine virtuelle
pour OpenStack Nova et le stockage des images pour OpenStack Glance. Pour la sécurité, OpenStack Keystone peut être configuré pour
fournir une authentification au cluster Ceph. Dans cette configuration, Ceph peut toujours être utilisé comme stockage de blocs et/ou
d'objets pour les applications non OpenStack.
Référentiel de contenus
Pour les entreprises qui ne peuvent pas (ou ne souhaitent pas) utiliser un référentiel de contenus à hébergement public tel que Box, Dropbox ou
Google Drive, SUSE Enterprise Storage est une option privée à faible coût. Le gisement d’objets Ceph peut être configuré pour répondre aux
besoins de bande passante et de latence de l’entreprise. Les interfaces REST S3 et Swift peuvent être utilisées pour accéder aux données.
Comme elles sont très répandues, cela signifie que la plupart des outils existants peuvent être utilisés et que les nouveaux outils n'exigent
pas de travail de développement significatif.
Serveur d'origine de distribution de contenus
Les réseaux de distribution de contenu (CDN) peuvent être privés ou publics. Les entreprises qui hébergent un CDN privé peuvent contrôler
les serveurs d’origine et les serveurs de périphérie. Les entreprises qui font appel à un CDN doivent utiliser les serveurs de périphérie du
fournisseur de contenus, mais elles ont la possibilité d’utiliser un serveur d’origine privé. Dans les deux cas, les interfaces de gestion d’objets
de SUSE Enterprise Storage constituent une excellente solution d'origine. SUSE Enterprise Storage garantit un TCO inférieur aux solutions
de stockage d'objet non open source ou aux serveurs d'origine d'un fournisseur de contenus.
Archives de vidéos
Avec le développement de la vidéosurveillance dans le secteur commercial, gouvernemental et privé, les besoins en stockage multiprotocole
à faible coût sont en plein essor. Là encore, la combinaison des serveurs HPE et de SUSE Enterprise Storage permet de définir une plateforme qui est une cible idéale pour ces flux de données, et dont les différentes interfaces (iSCSI, S3, Swift) supportent la plupart des
applications. La possibilité de définir un niveau de cache en mode write-back (écriture différée) permet également de gérer les flux associant
hautes performances et court terme et dont un pourcentage limité de requêtes sollicitent effectivement l’archive à long terme.
Cibles de sauvegarde
La plupart des applications de sauvegarde modernes proposent des mécanismes avec cibles sur disques multiples. Ces applications
bénéficient de la technologie de stockage distribué proposée par SUSE Enterprise Storage pour assurer les sauvegardes sur disques.
Les avantages de cette architecture sont nombreux : sauvegardes hautes performance, restaurations rapides sans chargement de bandes et
intégration dans la stratégie multiniveau utilisée par la plupart des clients. Le modèle économique des serveurs HPE qui exécutent SUSE
Enterprise Storage garantit un TCO plus favorable que l'utilisation d'un système de stockage traditionnel.
Livre blanc technique
Page 6
Présentation générale de la solution
Stockage d'objets – Principes de base
Le stockage d’objets permet de stocker des objets de taille arbitraire et de les gérer à l'aide d'un espace de noms non hiérarchisé dans lequel
chaque objet est identifié par ses propres métadonnées. Cette architecture très simple permet aux logiciels de gérer des volumes considérables
d’objets. Les API de la passerelle de stockage d'objets ajoutent une couche au-dessus des objets – les « containers » de Swift ou les
« buckets » de S3 – pour les organiser en groupes.
L'accès au stockage se fait via une interface RESTful qui assure une meilleure indépendance des clients et qui soulage les serveurs de
la charge de suivi des états. En général, le protocole HTTP est utilisé comme mécanisme de transport pour connecter les applications
aux données, ce qui permet de connecter tous les types de terminaux au gisement d’objets via le réseau.
Architecture de SUSE Enterprise Storage avec Ceph
Un « cluster SUSE Enterprise Storage » est une architecture de stockage défini par logiciel (SDS) qui est construite à partir de Ceph et qui
occupe une couche au-dessus de plusieurs serveurs standard. Cette solution permet de disposer d'une vue fédérée du stockage dans l'ensemble
du cluster dans laquelle chaque serveur est associé à du stockage de blocs et à des systèmes de fichiers. Cette approche a l’avantage de tirer
parti de l'environnement existant et de matériel standard tout en offrant la taille et les performances nécessaires à la solution globale. Pour plus
de détails sur Ceph : SUSE Enterprise Storage.
Rôles du cluster SUSE Enterprise Storage
Le cluster SUSE Enterprise Storage traité dans cet exemple de configuration de référence assure trois rôles principaux :
• Hôte OSD – Serveur Ceph qui stocke les données des objets. Chaque hôte OSD exécute plusieurs instances du processus (daemon) Ceph
OSD. Chaque processus interagit avec un disque OSD (Object Storage Disk). dans les clusters de production, il existe un mappage 1:1 entre
le daemon OSD et le volume logique. Le système de fichiers utilisé par défaut sur chaque volume logique est XFS, mais Btrfs est également
supporté.
• Moniteur (MON) – Gère les mappes d'état du cluster : mappe des moniteurs, mappe des disques OSD, mappe Placement Group et mappe
CRUSH. Ceph gère un historique (ou « epoch ») des changements d’état des moniteurs Ceph, des daemons Ceph OSD et des Placement
Groups (PG). Les moniteurs sont chargés de superviser le quorum et de tenir à jour les enregistrements d'état du cluster.
• Passerelle RADOS (RGW) – Interface de stockage d'objets, passerelle RESTful entre les applications et les clusters de stockage Ceph.
La passerelle RADOS supporte deux interfaces : S3 et Swift. Ces interfaces supportent la plupart des leurs API respectives (cf.
implémentations Amazon et OpenStack Swift).
Sécurité des données
SUSE Enterprise Storage supporte la réplication des données et le codage d'effacement (erasure coding). Le codage d'effacement encode les
données mathématiquement en plusieurs « chunks » qui peuvent ensuite reconstruits à partir des données partielles de l’objet original.
Ce mécanisme se traduit par une utilisation d’espace plus efficace que la réplication sur des objets plus larges, mais elle ajoute de la latence et du
temps de traitement. La surcharge ne permet pas une utilisation d’espace efficace pour les petits objets, et les blocs SUSE Enterprise Storage
exigent un niveau de cache répliqué pour l’utiliser. Autrement dit, le codage d'effacement est recommandé pour améliorer l'efficacité de
capacité, alors que la réplication est plus appropriée pour le stockage de blocs de plus faible capacité et pour les objets de petite taille.
Stockage des données sur le matériel
Un des principaux facteurs de différenciation entre différents systèmes de stockage d’objets est la méthode utilisée pour déterminer le
placement des données sur le matériel. SUSE Enterprise Storage calcule l'emplacement des données à l’aide d’un algorithme déterministe appelé
CRUSH. Pour ces calculs, CRUSH utilise un ensemble de règles configurables et des Placement Groups (PG). Les Placement Groups
indiquent aux données leurs cibles de stockage, et ils sont structurés de telle sorte que les données résistent aux incidents matériels.
Livre blanc technique
Page 7
Solution
Architecture de la solution
Serveur HPE Apollo 4500
Ce schéma général inclut des connexions avec l’infrastructure située en dehors de la configuration de référence utilisée comme exemple.
Chaque châssis Apollo 4530 (4U) contient trois nœuds de traitement, 12 disques durs et trois unités SSD pour la journalisation. Avec des
ratios traitement/stockage élevés et un système de journalisation sur unités SSD, ces nœuds sont un bon choix si l'on recherche des
performances réduites et/ou un stockage en blocs éphémère. À comparer avec le châssis Apollo 4510, qui contient un seul nœud de traitement
et jusqu'à 68 disques durs (avec co-location de la journalisation). Cette configuration permet d’obtenir une densité maximale pour les données,
et ces nœuds sont d'excellents hôtes pour un stockage en blocs. Chaque Apollo 4530 peut être considéré comme module de stockage de
blocs, et chaque Apollo 4510 peut être considéré comme module de stockage d’objets.
Le lien externe du tracé en bleu (10 GbE Data Net) relie le cluster aux machines clientes et à l'équilibrage de charge. Notez que les Apollo
4530 sont munis d'une connexion avec chaque nœud de traitement. Le tracé en orange (10 GbE Cluster Net) transporte uniquement le
trafic qui a lieu entre les nœuds du cluster. Le tracé en violet (1 GbE Mgmt. Net) tracé en violet dispose d'une liaison montante/uplink vers le
réseau d'administration. Chaque nœud de traitement du châssis Apollo 4530 partage un seul port de gestion de l'iLO 1.
Figure 1 – Configuration de référence avec serveurs Apollo 4500
Serveur HPE Apollo 4200
Les serveurs Apollo 4500 sont optimisés pour des tâches à densité optimisée, mais ils pourraient ne pas être adaptés à certains besoins des
datacenters (un rack de 1200 mm pourrait être trop grand, l'entreprise a standardisé sur serveurs 2U, etc.). Certaines entreprises envisagent
1
iLO (Integrated Lights-Out) est le contrôleur BMC de HPE. iLO inclut une API REST très fiable.
Livre blanc technique
Page 8
d’utiliser la même plate-forme pour des cas d’usage à plusieurs racks. Dans les déploiements de ce type, le serveur Apollo 4200 sera sans doute
mieux adapté. La standardisation sur serveurs 2U a également pour effet de définir de plus petits blocs pour le domaine impacté par les
incidents et pour l’expansion de capacité. Certains cas d’usage ne sont pas assez importants pour justifier une infrastructure dans laquelle
60+ unités de stockage passent en mode hors ligne chaque fois qu’un serveur tombe en panne. La solution obtenue ne présente pas une
densité par rack aussi élevée. Toutefois, les modules sont globalement plus petits et les hôtes OSD de l’architecture de référence résultante
ont une empreinte totale de 12U au lieu de 24U. Dans ce cas, le serveur Apollo 4200 sert de module pour le stockage de blocs et pour le
stockage d'objets (avec SUSE Enterprise Storage), et la seule différenciation se situe au niveau de la configuration de la cage arrière de l'unité de
stockage.
Avec l’architecture de référence Apollo 4200 + SUSE Enterprise Storage, les hôtes de stockage d'objets disposent de 28 disques durs : 24 à
l’avant, et quatre dans une cage arrière LFF, le tout dans un châssis 2U. Par contraste, le serveur Apollo 4510 dispose de 68 disques durs
dans un châssis 4U (34 disques par 2U). Les hôtes de stockage de blocs disposent également de 24 disques durs à l’avant, mais ils
assurent la journalisation sur quatre unités SSD installées dans la cage arrière, soit un ratio de 6:1 entre les disques durs et les SSD.
Ce châssis 2U contient un nœud de traitement et 24 disques durs, soit deux nœuds de traitement par 4U. Le serveur Apollo 4530 héberge
trois nœuds de traitement (12 disques durs chacun) dans un châssis 4U. Le stockage de blocs SUSE Enterprise Storage bénéficie du ratio
traitement/disques plus élevé du serveur Apollo 4530.
La configuration réseau est identique à l’exemple de configuration avec serveurs Apollo 4500 (Figure 1).
Figure 2 – Configuration de référence avec serveurs Apollo 4200
Livre blanc technique
Page 9
Valeur ajoutée par la solution HPE
Les clusters qui reposent sur une architecture de serveurs en marque blanche conviennent aux déploiements de plus petite envergure
mais quand les besoins augmentent, la complexité et le coût les rendent moins efficaces que le matériel proposé aux entreprises par des
spécialistes tels que HPE. En outre, avec les solutions en marque blanche, le département IT doit standardiser et intégrer les plates-formes et
les modules supportés, et la gestion du support technique devient plus complexe. En l'absence d’outils standardisés pour gérer le matériel à tous
ses stades d'évolution, le département IT doit définir ses propres solutions pour l’automatisation et la gestion de sa plate-forme. Par ailleurs,
les caractéristiques défavorables des plates-formes génériques (dont consommation d’énergie plus importante et occupation inefficace de
l’espace) limitent les capacités d'évolution et augmentent les coûts au fil du temps.
Résultat ? Un personnel IT qui doit travailler davantage et une entreprise qui doit augmenter ses dépenses pour supporter la diversité et la
complexité de son infrastructure matérielle en marque blanche. La réduction de coût initiale ne débouche pas sur le TCO le plus faible ni sur une
solution dont la maintenance est plus simple...
En faisant appel aux solutions matérielles et logicielles HPE, vous bénéficiez de nombreux avantages, en particulier :
• Outils de gestion de plate-forme prêts à s'adapter aux besoins des datacenters
• Serveurs et formats optimisés pour les différents cas d'usage des entreprises
• Plates-formes matérielles dont les éléments ont été validés ensemble
• Infrastructure internationale et experte pour le support technique du matériel
Cryptage des disques
En plus des avantages ci-dessus, toutes les configurations Apollo 4000 incluent une carte HPE Smart Array qui assure le cryptage Secure
Encryption selon besoin. Ce cryptage est certifié FIPS-2, et des tests indiquent qu'il n’affecte pas les IOPS des disques durs en cas de baisse des
performances et qu'il est transparent pour le système d’exploitation. Autrement dit, il est possible d'utiliser toute unité supportée par le serveur,
ce qui permet de disposer d'une souplesse de choix coût/performances beaucoup plus grande qu'avec le cryptage direct sur les unités de
stockage. La gestion des clés est simple et peut être assurée en local ou via un système dédié.
Valeur ajoutée par la solution SUSE
Fournisseur depuis 20+ ans de solutions open source stratégiques, SUSE a pour mission de proposer à ses clients des solutions performantes et
accompagnées d'un support technique efficace. SUSE Enterprise Storage ne fait pas exception. En matière de technologies de stockage, SUSE
innove depuis de nombreuses années. La société applique son expertise et son expérience pour mettre Ceph à la portée de tous les clients.
Pour garantir la stabilité des solutions SUSE, il est nécessaire d'associer la distribution Linux la plus fiable Linux à la distribution Ceph la plus
performante du marché : SUSE Enterprise Storage.
Avec SUSE Enterprise Storage, les clients disposent d'un build Ceph très efficace qu'ils peuvent compléter avec les modules fonctionnels
proposés par SUSE, en particulier : Support iSCSI, cryptage des données at-rest et (en option) mécanismes d'installation. Rassurés par un
réseau international de spécialistes en support technique, les clients ont la garantie que SUSE Enterprise Storage est la meilleure solution
pour stocker leurs données – aujourd'hui comme demain.
Serveurs
Cette section présente une partie des raisons et des avantages qui justifient le choix des serveurs standard cités dans la section « Conseils
de configuration » (voir ci-après). Les décisions nécessaires au dimensionnement des différents éléments du cluster (traitement, mémoire,
stockage, topologie du réseau) sont présentées dans la section « Conseils de configuration » (voir ci-après)..
ProLiant DL360 Gen9
• Densité d'espace rack : 1U
• Sa capacité d'évolution (mémoire et puissance de traitement) lui permet d'assurer les rôles de connexion et de moniteur
• Plate-forme d'administration à faible coût et faible encombrement
Livre blanc technique
Page 10
Serveur HPE Apollo 4500
Améliorations du serveur Apollo 4500 par rapport au serveur SL4540 Gen8 :
• Châssis HP 4U au lieu de 4,3U
• Huit slots 4 PCIe et un module d'administration iLO FlexibleLOM (au lieu d'une seule mezzanine x8 PCIe)
• Meilleures performances du Socket R (par rapport au Socket B des serveurs Gen8)
• En option, un contrôleur série H ou P associé aux deux disques de démarrage permettent une plus grande souplesse de contrôleur et de
câblage pour les unités de stockage
• Le support de M.2 améliore la densité de stockage
• BROC Gen9 assure le RAID matériel avec cache en écriture 'protégé par batterie) et pilote open source
• Utilise des alimentations électriques à format standardisé
HPE Apollo 4500 – Principales caractéristiques
HPE Apollo 4510 Gen9
HPE Apollo 4530 Gen9
Densité maximum pour le stockage d’objets
Meilleur ratio traitement/disques pour le stockage de blocs
Coût le plus faible par Go de stockage
Le domaine réseau impacté par les incidents est plus réduit
Souplesse du câblage et du contrôleur de stockage
Augmentation de la connectivité pour maximiser la bande passante
Optimisé pour réduction des Opex et du TCO
Optimisé pour réduction des Opex et du TCO
Alimentation électrique et refroidissement à encombrement réduit
Encombrement réduit (partage de l'alimentation électrique et du refroidissement)
Figure 3 – Face avant (en haut) et face arrière (en bas) du HPE Apollo 4530 Gen9
Livre blanc technique
Serveur HPE Apollo 4200
• Conserve le format standard 2U tout en améliorant considérablement la densité de stockage
– 24 + 4 LFF ou 48 + 2 SFF max
– Idéal pour les datacenters en co-location dans lesquels l’espace est limité
• Compatible avec les racks 1075 mm
• Unités à chargement avant/arrière
• Jusqu'à sept slots PCIe, y compris x16
– Possibilité d'augmenter le débit des objets Ceph en augmentant la connectivité et/ou en ajoutant des contrôleurs
– Peut très facilement être réaffecté comme module de base dans d'autres cas d'usage (entreprise/datacenter)
• Cage arrière avec slots SFF + deux cartes PCI pour une plus grande souplesse ou cage arrière LFF pour augmenter la capacité
• Le support de M.2 améliore la densité de stockage
• L'investissement initial inférieur par rapport à Apollo 4500 réduit les coûts Capex
Figure 4 – HPE Apollo 4200 avec disques durs LFF, tiroir fermé
Figure 5 – HPE Apollo 4200 avec disques durs SFF, tiroir ouvert
Page 11
Livre blanc technique
Page 12
Conseils de configuration
Cette section explique comment créer un cluster SUSE Enterprise Storage adapté à vos besoins spécifiques. Pour la construction d’un
cluster, la stratégie de base est la suivante : tout en tenant compte de la capacité souhaitée et de vos charges de travail habituelles, vous
devez identifier les points de ralentissement susceptibles d'impacter le cas d’usage envisagé et déterminer la taille du domaine réseau
impacté par les incidents.
Figure 6 – Face arrière de HPE Apollo 4200 avec deux slots SFF et (en option) expansion pour deux cartes PCI
Après avoir sélectionné le matériel, il est conseillé de consulter ce guide : SUSE Enterprise Storage Deployment & Administration Guide pour
suivre les instructions relatives à l’installation des logiciels.
Recommandations générales pour la configuration
• Dans un pool donné, l'élément le plus lent devient le maillon faible pour les performances. En général, les hôtes OSD doivent être affectés
de la même quantité, du même type et de la même configuration de stockage. Certains facteurs peuvent inciter à ignorer cette orientation
(par exemple, pools limités à des unités ou à des hôtes spécifiques ou qualité de la fédération plus importante que les performances des
pools), mais c’est généralement un bon principe de conception.
• La taille de cluster minimum recommandée est d'au moins six nœuds de traitement. Les nœuds supplémentaires offrent plus d’espace
pour l'évolution des données non structurées, ils aident à répartir la charge par nœud pendant les opérations et ils réduisent les risques de
ralentissement de chaque module. Lors de l’examen de vos différents scénarios de transformation, vous devez tenir compte de la capacité
de chaque nœud par rapport à la bande passante disponible. Les nœuds à densité plus élevée fonctionnent mieux dans les grands
clusters ou les clusters rapides, alors que les nœuds moins denses doivent être réservés aux clusters de taille réduite.
• S'il vous semble que la taille de cluster minimum recommandée est trop importante, demandez-vous alors si SUSE Enterprise Storage est
la solution la mieux adaptée à vos besoins spécifiques. Les petites zones de stockage qui ne risquent pas d'atteindre les volumes des
données non structurées peuvent rester dans le stockage de fichiers et de blocs traditionnel, ou être traitées via une interface de gestion
d’objets qui point sur une cible de stockage en mode fichiers.
• Les clusters SUSE Enterprise Storage peuvent évoluer jusqu'à plusieurs centaines de péta-octets : vous pouvez donc ajouter des capacités
de stockage en fonction des besoins identifiés. Cependant, chaque fois que vous ajoutez des éléments matériels, vous devez tenir compte
de l'agrandissement du domaine réseau impacté par les incidents. La conception du nouvel environnement doit tenir compte du fait que
certains éléments risquent de connaître des incidents suite à l'évolution des différents systèmes.
Journalisation sur unités SSD
Si vos données exigent une importante bande passante pour les opérations d'écriture ou de PUT, il est conseillé d'utiliser une ou plusieurs
unités SSD pour la journalisation des données.
Principaux avantages
• En séparant les données de journalisation – qui sont hautement séquentielles – et les données des objets, qui sont réparties dans la partition
de données sous forme d'objets RADOS dans leur Placement Group respectif –, vous pouvez réduire considérablement les temps de recherche
des disques durs. Cela signifie également que toute la bande passante du disque dur va aux E/S des données, ce qui a pour effet de doubler la
bande passante consommée par les écritures et les PUT.
• En utilisant des unités SSD pour la journalisation, le stockage reste relativement dense car plusieurs journaux peuvent être enregistrés sur
la même unité (à bande passante plus élevée) sans subir de pénalités pour les temps de recherche des disques.
Principaux inconvénients
• Dans cette configuration, chaque unité SSD est plus coûteuse qu'un disque dur (qui pourrait être installé dans un slot standard).
Les journaux sur SSD réduisent la capacité maximale de stockage des objets sur le nœud.
• Si vous connectez l'unité de journalisation à plusieurs OSD et que vous travaillez avec XFS – le système de fichiers utilisé par défaut par
l'outil ceph-deploy –, la perte de cette unité de journalisation entraîne la perte de tous les OSD connectés. Si vous avez prévu un nombre
suffisant de réplique et d'OSD, ce risque n'est pas très important pour la durabilité des données, mais il est conseillé d'en tenir compte lors de
la définition de l'architecture du nouvel environnement.
• Les OSD ne peut pas être échangés à chaud avec des unités de données ou de journalisation.
Livre blanc technique
Page 13
• Pour utiliser efficacement les unités SSD, des opérations supplémentaires de planification et de configuration doivent être envisagées
• (en effet, les E/S des petits objets profitent beaucoup moins des unités SSD que les gros objets).
Configuration – Recommandations générales
• En matière de bande passante, quatre disques durs pour une unité SSD (4:1) est le ratio recommandé pour le stockage de blocs. Il est
possible d'améliorer la densité de capacité en augmentant ce ratio (en ajoutant des disques durs), mais cette configuration augmente
également le nombre d'OSD affectés en cas de panne d'une des unités SSD.
• Si vous déployez un ratio disques durs/unités SSD de journalisation élevé, les unités SSD risquent de créer un point de ralentissement ;
vous devez donc trouver un juste équilibre entre le nombre d'unités SSD et les performances maximales des disques durs. Un ratio
supérieur à huit disques durs pour une unité SSD (8:1) est généralement inférieur à une solution de co-location des unités SSD de
journalisation avec les données.
• Même si les performances en écriture des applications n’est pas un facteur critique, il peut être judicieux d’ajouter une unité SSD de
journalisation simplement pour reconstruire/rééquilibrer les améliorations apportées à la bande passante.
• Les journaux n'exigent pas une capacité très élevée, mais la durée de vie des unités SSD peut être prolongée avec les procédés
d'uniformisation d'usure. L'espace de journalisation réservé par SUSE Enterprise Storage doit être de 10-20 secondes d’écritures pour
l’OSD auquel le journal est lié.
• Il n'est pas conseillé de configurer des unités SSD en RAID 1 (en dehors des nœuds des moniteurs). Avec l'uniformisation d'usure, il est
probable que les unités SSD seront mises à niveau à peu près au même moment. Le doublement des SSD par nœud a également pour effet
de réduire la densité de stockage et d'augmenter le prix par Go. En cas d'évolution massive, il est conseillé de prévoir une défaillance des
unités de stockage et d'élaborer un plan qui permettra de surmonter ou de contourner cette défaillance.
• La fonctionnalité de codage d'effacement est très souple : elle permet de choisir entre l'efficacité du stockage et la durabilité des données.
Dans la plupart des cas, la somme des données et des chunks de codage doit être inférieure ou égale au nombre d’hôtes OSD, afin
qu’aucune défaillance d’hôte n'entraîne la perte de plusieurs chunks.
• En limitant les nœuds de cluster à une seule fonction, vous simplifiez les besoins en CPU et en mémoire, à la fois pour le fonctionnement
normal et pour la gestion des incidents.
• En augmentant la RAM d'un hôte OSD, vous pouvez booster les performances des opérations GET sur des E/S plus réduites grâce à la
mise en cache des fichiers système.
Sélection des éléments matériels
Le guide SUSE Enterprise Storage Deployment and Administration Guide spécifie les recommandations minimum pour le matériel. Cette
section traite des configurations de référence et des cas d’usage des clients.
Sélection des disques
Choisissez le nombre de disques nécessaires pour respecter les contrats de niveau de service (SLA) : Il peut s'agir simplement du nombre de
disques nécessaires pour répondre aux besoins en capacité, mais il est possible que le nouvel environnement exige plusieurs disques pour
des raisons de performances ou d'homogénéité du cluster.
Les exigences du stockage d’objets étant essentiellement déterminées par la capacité, vous devez prévoir la quantité de stockage brut qui
est nécessaire pour répondre aux besoins de capacité utilisable et de durabilité des données. Le nombre de répliques et le ratio
données/chunks de codage d’effacement sont les facteurs les plus importants pour déterminer la capacité de stockage utilisable. Vous
devez tenir compte d'autres pertes de capacité utilisable, par exemple : journaux en co-location avec les données OSD, surcharge XFS/Btrfs
et secteurs réservés des volumes logiques. Règle de base pour la réplication sur trois voies : ratio de 1:3,2 entre la capacité de stockage
utilisable et la capacité brute.
Autres considérations importantes sur les performances des disques :
• Le nombre de répliques ou de chunks de codage d'effacement configuré multiplie les opérations d'écriture sur les unités de stockage pour
chaque PUT d'objet.
• Les performances maximales en écriture sur des disques durs sans journaux dédiés est d'environ 50 % en raison des écritures effectuées
dans les journaux et des partitions de données copiées sur la même unité de stockage.
• Sur un nœud/serveur HPE Apollo 4510 Gen9 entièrement équipé en disques et disposant d'un seul port 10 GbE, le point de
ralentissement de la bande passante se situe au niveau du port et non du contrôleur ou du disque.
• Avec les objets de plus petite taille, le point de ralentissement est généralement la capacité en opérations/seconde de la passerelle des
objets (avant les disques ou le réseau). Dans certains cas, le point de ralentissement peut être la capacité à exécuter les opérations
nécessaires aux objets.
Livre blanc technique
Page 14
Configuration des disques
Si le cache en écriture du contrôleur des baies est disponible, il est recommandé de configurer les disques en RAID 0 et d'activer ce cache
pour améliorer les performances en écriture des petits objets.
Sur un nœud/serveur HPE Apollo 4510 Gen9 entièrement équipé en disques (68 unités), un pourcentage important de cycles de CPU doit
être réservé à ces 68 OSD sur un nœud de traitement unique. La configuration en RAID 0 des volumes de deux unités – soit 34 OSD au total –
risque de réduire la capacité d’utilisation des CPU. La configuration de plusieurs unités dans une baie en RAID peut réduire le coût CPU du
stockage des données froides, réduire l’efficacité du stockage et améliorer la fiabilité. Ce type de configuration peut également augmenter la
marge des CPU pour la gestion des erreurs ou pour augmenter les ressources disponibles (à condition que la conception du cluster prévoie
l'utilisation de ces ressources CPU complémentaires pour des tâches extérieures au cluster).
Sélection d'une infrastructure de réseau
Vous devez tenir compte de la largeur de bande de stockage souhaitée (cf. calcul précédent), de la surcharge imposée par le trafic de réplication
et de la configuration du réseau de la passerelle des objets (nombre de ports/bande passante totale). Les détails relatifs à la segmentation du
trafic, la configuration de l’équilibrage de charge, la configuration des VLAN ou autres configurations/meilleures pratiques de connectivité
varient en fonction des spécificités du cas d'usage considéré et débordent du cadre du présent document.
• Les choix de configuration généralement utilisés pour le trafic de données s'appuient sur des liaisons 10 GbE associées à LACP.
Ces liaisons assurent la résilience nécessaire si elles portent sur plusieurs commutateurs et si leur bande passante est agrégée.
• Les solutions de redondance réseau (configurations actives/passives, commutation redondante) ne sont pas recommandées, dans la
mesure où les configurations scale-out bénéficient d'une fiabilité importante par suite de la redondance des nœuds de disques et de
traitement et de la configuration appropriée du domaine réseau impacté par les incidents. Pour définir le mode de distribution des
répliques, examinez la mappe CRUSH dans la configuration du réseau (à l'endroit où sont regroupés les commutateurs et les
interconnexions des racks).
• Un réseau avec cluster isole le trafic des réplications du réseau des données et définit un autre domaine impacté par les incidents.
Le trafic des réplications est important, car le système exécute plusieurs écritures pour chaque E/S. Il est recommandé d'associer toutes
les liaisons 10 GbE à LACP et de segmenter le trafic public et le trafic back-end à l'aide de réseaux VLAN
• Il est recommandé de réserver un réseau 1 GbE distinct pour l'administration (celle-ci supportant une autre classe et un autre objet de trafic
que les E/S du cluster).
Correspondance entre les passerelles d'objets et le trafic
Commencez par sélectionner une taille d'objet standard et une structure d'E/S, puis comparez-les aux résultats de l'échantillon de la
configuration de référence. Les limites des passerelles d'objets étant dépendantes du trafic des objets, le réglage précis exige des tests et
une validation avec des charges représentatives du cas d’usage envisagé. Voici quelques considérations qui vous permettront de déterminer
le nombre de passerelles d’objets à sélectionner pour votre cluster :
• Le traitement des opérations des passerelles d'objets ont tendance à limiter les transferts des petits objets. La mise en cache du système
de fichiers pour les opérations GET a le plus gros impact sur les performances avec ces petites tailles.
• Pour les objets plus gros et pour les tailles de cluster, à bande passante du réseau passerelle est généralement le facteur limitant pour les
performances.
• Au-delà d'une certaine taille d'environnement, l'équilibrage de charge s'impose pour réduire les temps de latence et améliorer les IOPS et
la bande passante. Vous devez envisager au moins trois passerelles d'objets derrière l'architecture d’équilibrage de charge.
• Les données très froides et certains environnements à nombre de clients limité pourraient se contenter d'une seule passerelle, mais deux
est le minimum recommandé pour se protéger contre les points de défaillance unique (SPOF).
Le processus des moniteurs ayant des besoins en ressources relativement faibles, les moniteurs peuvent tourner sur le même matériel que la
passerelle des objets. Les exigences de performances et du domaine réseau impacté par les incidents imposent que l'hôte du moniteur ne
soit pas nécessairement une passerelle d’objets et vice versa.
Nombre de moniteurs
Une installation de production doit compter au moins trois moniteurs. Bien qu’il soit possible de fonctionner avec un seul moniteur, cette
configuration n’est pas recommandée pour un déploiement en entreprise, dans la mesure où un plus grand nombre de moniteurs est
important pour le quorum et la redondance. SI vous gérez plusieurs sites, il est conseillé d'augmenter le nombre de moniteurs de manière à
maintenir un quorum si un site tombe en panne.
Utilisez des serveurs physiques plutôt que des machines virtuelles, de manière à disposer de matériel granulaire en cas d'incident. Pour les
moniteurs, il est conseillé d'utiliser des unités SSD en miroir en raison du nombre élevé d’appels fsync reçus par ces nœuds.
Livre blanc technique
Page 15
Nomenclature (BOM)
Cette section présente les numéros de référence des éléments de serveurs prévus dans l'architecture de référence (RA) et utilisés
comme modules avec SUSE Enterprise Storage. Ces informations permettent de faire la démonstration des « Conseils de configuration »
présentés par ailleurs dans ce document et elles constituent un point de départ pratique pour le dimensionnement d’une preuve de concept
ou d'un déploiement. En raison de l’accent mis sur les serveurs standard dans cette architecture de référence, nous ne présentons pas de
nomenclature complète pour l’ensemble de la solution.
Les éléments sélectionnés pour les besoins opérationnels et pour la connectivité inter-rack et/ou entre différents sites, les services et le
support technique peuvent varier considérablement avec chaque déploiement et sont des sujets complexes à part entière. N'hésitez pas à
contacter votre commercial HPE pour discuter de votre projet et créer un cluster SUSE Enterprise Storage adapté à vos besoins spécifiques.
x3 HPE Apollo 4530 Gen9
Qté
Réf.
Description
9
786595-B23
HPE ProLiant XL450 Gen9 Configure-to-order Server Node for Apollo 4530 Chassis
9
783934-L21
Intel® Xeon® E5-2670v3 (2.3 GHz/12-core/30 MB/120 W) FIO Processor Kit
72
726719-B21
HPE 16 GB (1 x 16 GB) Dual Rank x4 DDR4-2133 CAS-15-15-15 Registered Memory Kit
27
797303-B21
HPE 480 GB 6G SATA Value Endurance LFF 3.5-in LP Enterprise Value 3yr Warranty Solid
State Drive
108
805334-B21
HPE 8 TB 6G SATA 7.2 k rpm LFF (3.5-inch) Low Profile Midline 512e 1yr Warranty Hard Drive
18
655708-B21
HPE 500 GB 6G SATA 7.2 k rpm SFF (2.5-inch) SC Midline 1yr Warranty Hard Drive
9
665243-B21
HPE Ethernet 10 Gb 2-port 560FLR-SFP+ Adapter
9
808965-B21
HPE Apollo 4500 Mini SAS P440 Cable Kit
9
761878-B21
HPE H244br FIO Smart HBA
9
726821-B21
HPE Smart Array P440/4G Controller
3
727258-B21
HPE 96w Megacell Batt Cntrl Bd
3
799581-B23
HPE Apollo 4530 Gen9 CTO Chassis
12
720479-B21
HPE 800 W Flex Slot Platinum Plus Hot Plug Power Supply Kit
3
681254-B21
HPE 4.3U Server Rail Kit
9
512485-B21
HPE iLO Advanced including 1yr 24x7 Technical Support and Updates Single Server License
Livre blanc technique
Page 16
x3 HPE Apollo 4510 Gen9
Qté
Réf.
Description
3
786593-B21
HPE ProLiant XL450 Gen9 Configure-to-order Server Node for Apollo 4510 Chassis
3
783936-L21
Intel Xeon E5-2690 v3 (2.6 GHz/12-core/30 MB/135 W) FIO Processor
3
783936-B21
Intel Xeon E5-2690v3 (2.6 GHz/12-core/30 MB/135 W) Processor
48
726722-B21
HPE 32 GB (1 x 32 GB) Dual Rank x4 DDR4-2133 CAS-15-15-15 Registered Memory Kit
204
805334-B21
HPE 8 TB 6G SATA 7.2 k rpm LFF (3.5-inch) Low Profile Midline 512e 1yr Warranty Hard Drive
6
655708-B21
HPE 500 GB 6G SATA 7.2 k rpm SFF (2.5-inch) SC Midline 1yr Warranty Hard Drive
6
777262-B21
HPE 120 GB 6G SATA Read Intensive M.2 2280 3yr Warranty Solid State Drive
6
665243-B21
HPE Ethernet 10 Gb 2-port 560FLR-SFP+ Adapter
3
808967-B21
HPE Apollo 4500 Mini SAS Dual P440 Cable Kit
3
761878-B21
HPE H244br FIO Smart HBA
3
726897-B21
HPE Smart Array P840/4G Controller
3
727258-B21
HPE 96 w Megacell Batt Cntrl Bd
3
799581-B21
HPE Apollo 4510 Gen9 CTO Chassis
3
799377-B21
HPE Apollo 4510 8HDD Rear Cage Kit
6
720620-B21
HPE 1400 W Flex Slot Platinum Plus Hot Plug Power Supply Kit
3
681254-B21
HPE 4.3U Server Rail Kit
3
512485-B21
HPE iLO Advanced including 1yr 24x7 Technical Support and Updates Single Server License
Livre blanc technique
Page 17
x6 Apollo 4200
Cette nomenclature répertorie les éléments nécessaires pour trois serveurs de stockage de blocs et trois serveurs de stockage d'objets.
La configuration est aussi cohérente que possible entre les deux types de serveurs. Différence essentielle entre les deux types de serveurs :
le stockage de blocs utilise des unités SSD dans les slots arrière pour disposer d'une meilleure bande passante. Par ailleurs, les équipements
supportant M.2 sont utilisés pour maximiser la densité de stockage des OSD de SUSE Enterprise Storage.
Qté
Réf.
Description
6
808027-B21
HPE Apollo 4200 Gen9 24LFF CTO Server
6
803314-L21
HPE Apollo 4200 Gen9 Intel Xeon E5-2680 v3 (2.5 GHz/12-core/30 MB/120 W) FIO Processor Kit
6
803314-B21
HPE Apollo 4200 Gen9 E5-2680 v3 Kit
72
728629-B21
HPE 32 GB (1 x 32 GB) Dual Rank x4 DDR4-2133 CAS-15-15-15 Registered Memory Kit
6
777894-B21
HPE Dual 120 GB Value Endurance Solid State M.2 Enablement Kit
6
806563-B21
HPE Apollo 4200 Gen9 LFF Rear HDD Cage Kit
156
797269-B21
HPE 6 TB 6G SATA 7.2 k rpm LFF (3.5-inch) Low Profile Midline 1yr Warranty Hard Drive
12
665243-B21
HPE Ethernet 10 Gb 2-port 560FLR-SFP+ Adapter
12
720479-B21
HPE 800 W Flex Slot Platinum Hot Plug Power Supply Kit
6
822731-B21
HPE 2U Shelf-Mount Adjustable Rail Kit
6
813546-B21
HPE SAS Controller Mode for Rear Storage
12
797303-B21
HPE 480 GB 6G SATA Value Endurance LFF 3.5-in LPC Enterprise Value 3yr Warranty Solid State Drive
6
512485-B21
HPE iLO Advanced including 1yr 24x7 Technical Support and Updates Single Server License
x3 serveurs HPE ProLiant DL360 Gen9
Qté
Réf.
Description
3
755259-B21
Serveur HPE DL360p Gen9 (4-LFF / CTO)
3
764097-L21
HPE DL360 Gen9 Intel Xeon E5-2630L v3 FIO Processor Kit
6
726719-B21
HPE 16 GB (1 x 16 GB) Dual Rank x4 DDR4-2133 CAS-15-15-15 Kit
3
749976-B21
HPE H240ar 12 Gb 2-ports Int FIO Smart Host Bus Adapter
3
665243-B21
HPE Ethernet 10 Gb 2-port 560FLR-SFP+ Adapter
6
652745-B21
HPE 500 GB 6G SAS 7.2 k rpm SFF (2.5-inch) SC Midline
6
720478-B21
HPE 500 W Flex Slot Platinum Hot Plug Power Supply Kit
3
789388-B21
HPE 1U LFF Gen9 Easy Install Rail Kit
3
512485-B21
HPE iLO Advanced including 1yr 24x7 Technical Support and Updates Single Server License
Livre blanc technique
Page 18
SUSE Enterprise Storage 3 Deployment for HPE DL Series
Configuration matérielle
La section qui suit présente un exemple de configuration utilisée pour des tests. Les spécifications du matériel listé sont largement
supérieures aux recommandations du document de présentation de l'architecture.
x4 nœuds OSD
DL380 G9
x2 E2660 v3
128 Go de RAM
Unité Value SSD 2200 Go dans la baie arrière
Vous devez configurer cette unité en premier
Configuration en RAID 1 en appliquant toues les valeurs par défaut
Unité SSD 250 Go à écriture Intensive dans une baie 3,5"
RAID 0 individuel
90 % de cache à écriture différée, tous les autres paramètres à leur valeur par défaut
Configurée comme unités logiques 2 et 3
x10 disques SAS 6 To 7200 trs/min
RAID 0 individuel
90 % de cache à écriture différée, tous les autres paramètres à leur valeur par défaut
x2 Intel 530SFP+
x3 nœuds de supervision, x1 nœud d'administration
DL360 Gen9
x2 E5-2690 v3
64 Go
x2 SSD
x1 Intel 530SFP+ dual port 10 GbE
x2 HPE FlexFabric 5700-40XG-2QSFP+ switches
Livre blanc technique
Page 19
Instructions détaillées
Planification et prérequis
Préparez la plage d’adresses IP à utiliser. Créez un seul sous-réseau de stockage auquel les nœuds, les passerelles et les clients se connecteront.
Dans de nombreux cas, cela implique l’utilisation d’une plage d’adresses IP plus étendue que le standard /24. Dans ce cas, le trafic de stockage
peut quand même être acheminé, mais cette configuration est généralement déconseillée pour garantir des temps de latence plus faibles.
Configurez les enregistrements DNS A pour les nœuds des OSD et les nœuds des moniteurs (Mon).
Déterminez les sous-réseaux et les VLAN nécessaires et configurez les ports des commutateurs en conséquence. Pour plus de détails :
SUSE Enterprise Storage Architecture Overview with Recommendations.
Subscription Management Tool (SMT)– Ce service propose un miroir local des référentiels SUSE, ce qui permet le rapide des logiciels et
des mises à jour. Pour plus de détails : Subscription Management Tool (SMT) for SUSE Linux Enterprise 11 SP3.
Les nœuds de même type doivent être configurés de manière identique. Avec les contrôleurs RAID, cette directive est très importante, car
elle simplifie considérablement la configuration des unités de stockage.
Réseau
Câblez et configurez les commutateurs des différents nœuds. En effectuant une configuration correcte des commutateurs dès le début du
déploiement, vous éviterez les problèmes réseau par la suite. Opérations de configuration essentielles : créer la topologie l’IRF (empilement) et les
groupes LACP, activer les trames jumbo. Chaque groupe d’agrégation doit être affecté d'un numéro unique, défini à l’avance. Il est également
conseillé de désactiver le Spanning Tree Protocol (STP) sur les ports utilisés pour le stockage.
Pour configurer l'environnement IRF : HPE FlexFabric 5700 Switch Series IRF Configuration Guide.
Pour configurer le groupe LACP du commutateur 1/port 1 et du commutateur 2/port 1 et activer le support des trames jumbo, exécutez les
commandes suivantes :
Vue système
Interface Bridge-aggregation 1
Link-aggregation mode dynamic
quit
Interface 10 GbE 1/0/1
port link-aggregation group 1
jumboframe enable 9100
stp disable
Interface 10 GbE 2/0/1
port link-aggregation group 1
jumboframe enable 9100
stp disable
quit
save
Répétez ces étapes pour chaque groupe d’agrégation requis.
Créez au moins un VLAN pour les communications entre clusters. Dans cet exemple, nous utilisons 3001 VLAN pour le trafic des clusters.
Vue système
VLAN 1
name ceph-cluster
Description du vlan pour communication back-end du cluster ceph
quit
Livre blanc technique
Page 20
save
Assigner les VLAN aux ports. La configuration ci-dessous suppose un seul VLAN connecté par ports (valeur par défaut).
Vue système
interface bridge-aggregation 1
port link-type hybrid
port hybrid vlan 1 untagged
port hybrid vlan 3001 tagged
quit
save
Déploiement du système d'exploitation
La deuxième grande étape consiste à installer le système d’exploitation. La configuration de référence inclut deux unités SSD, dix disques
durs SAS 6 To near-line et plusieurs unités SSD en RAID 1 pour le système d’exploitation. Les nœuds qui ont le même rôle doivent être
affectés de la même configuration.
Lors du déploiement du système d’exploitation, veillez à utiliser uniquement la première unité de stockage (par exemple, RAID 1 pour les
unités SSD 200 Go).
• Pendant l’installation, procédez à une configuration de base du réseau : nom d’hôte, nom de domaine et adresse IP.
• Installation minimale avec référentiel SUSE Enterprise Storage sélectionné.
• Désélectionnez x-windows et Gnome.
Lorsque l’installation terminée, il est conseillé de réécrire le fichier /etc/udev/rules.d/70-persistent-network-rules de manière à disposer de ports
à configuration identique sur chaque nœud. Après avoir modifié ce fichier, vous devez redémarrer chaque nœud et restaurer les configurations
finales du réseau.
Vérifiez la connectivité, puis exécutez zypper pour vérifier qu'il n'existe aucune autre mise à jour.
Le tableau ci-dessous indique les adresses IP utilisées pour cette opération (ces adresses IP doivent être adaptées au déploiement réel).
Nœud
IP de front-end (VLAN 1)
IP de back-end (VLAN 3001)
sesadmin
192.168.124.90
192.168.100.90
monnode1
192.168.124.91
192.168.100.91
monnode2
192.168.124.92
192.168.100.92
monnode3
192.168.124.93
192.168.100.93
osdnode1
192.168.124.101
192.168.100.101
osdnode2
192.168.124.102
192.168.100.102
osdnode3
192.168.124.103
192.168.100.103
osdnode4
192.168.124.104
192.168.100.104
Livre blanc technique
Page 21
Déploiement de SUSE Enterprise Storage
La troisième grande étape consiste à déployer Ceph en suivant la description qui figure dans la documentation SUSE Ceph Object Gateway.
Sur sesadmin, procédez comme suit :
Configurez NTP :
yast <Entrée>-> Network Services-> NTP Configuration -> [Démarrer le daemon NTP]
Maintenant et au démarrage-> Add-> Server-> (votre serveur NTP par défaut)-> OK->
OK-> Quit
Configurez le fichier sudoers :
visudo
Ajoutez le code suivant à la fin du fichier :
ceph ALL = (root) NOPASSWD:ALL
Sur chaque nœud, créez l’utilisateur cephadm et spécifiez le mot de passe :
useradd -m cephadm && passwd cephadm
Générez et distribuez la ssh-key pour l’utilisateur cephadm : Sur sesadmin :
su – cephadm
ssh-keygen
ssh-copy-id cephadm@osdnode1
Répétez pour chaque nœud.
Copiez /etc/sudoers sur chaque nœud :
sudo scp /etc/sudoers root@osdnode1:/etc/sudoers
Répétez pour chaque nœud.
Installez NTP sur chaque nœud :
sudo zypper in ntp yast2-ntp-client
Répétez pour chaque nœud.
Copiez /etc/sudoers sur chaque nœud :
sudo scp /etc/ntp.conf root@osdnode1:/etc/ntp.conf
Répétez pour chaque nœud.
Sur chaque nœud :
sudo systemctl enable ntpd
sudo systemctl start ntpd
Installez ceph sur tous les nœuds :
sudo zypper in ceph
Installez ceph-deploy sur les nœuds d’administration :
sudo zypper in ceph-deploy
Désactivez IPv6 :
Modifiez le fichier /etc/sysctl.conf et ajoutez ces lignes en fin de fichier :
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
Livre blanc technique
Page 22
net.ipv6.conf.lo.disable_ipv6 = 1
Copiez /etc/sysctl.conf sur tous les nœuds et redémarrez-les :
sudo scp –p /etc/sysctl.conf root@osdnode1:/etc/sysctl.conf
Répétez pour chaque nœud.
Exécutez ceph-deploy installation sur tous les nœuds :
ceph-deploy install sesadmin osdnode1 osdnode2 osdnode3 osdnode4 monnode1 monnode2
monnode3
Déployez les nœuds des moniteurs (Mon) :
ceph-deploy new monnode1 monnode2 monnode3
Modifiez ceph.conf en fonction des réseaux : La section [global] doit contenir les valeurs suivantes :
public network = 192.168.124.0/24
cluster network = 192.168.100.0/24
Vérifiez que le pare-feu est désactivé sur tous les nœuds :
sudo /sbin/SuSEfirewall2 status
Répétez pour chaque nœud.
Créez le service de supervision (mon) initial :
ceph-deploy mon create-initial
Préparez les nœuds OSD en exécutant la commande ceph-deploy osd create. Le premier équipement (par exemple, sdd) est le lecteur de
données, le dernier (sdb) est l'unité de journalisation.
ceph-deploy osd prepare osdnode{1..4}:sd{d..h}:sdb
ceph-deploy osd prepare osdnode{1-4}:sd{i..m}:sdc
ceph-deploy osd activate osdnode{1..4}:sd{d..h}1:sdb
ceph-deploy osd activate osdnode{1..4}:sd{i..m}1:sdc
Déployez le ou les nœuds d’administration :
ceph-deploy admin sesadmin
Installez romana sur les nœuds d’administration :
Au niveau cephadm :
ceph-deploy admin monnode1 monnode2 monnode2
Au niveau root :
zypper in romana
calamari-ctl initialize
su - cephadm
ceph-deploy calamari --master sesadmin connect osdnode1 osdnode2 osdnode3 osdnode4
monnode1 monnode2 monnode3
Pour accéder à l’interface de romana, pointez un navigateur sur http://sesadmin.
Livre blanc technique
Page 23
Validation du cluster SUSE Enterprise Storage
Lorsque la configuration de base du cluster SUSE Enterprise Storage est terminée, vous devez effectuer une série d'opérations pour vérifier
que le cluster fonctionne comme prévu.
À partir du nœud d’administration :
ceph status
ceph osd pool create test 4096
rados bench –p test 300 write --no-cleanup
rados bench –p test 300 seq
Lorsque la validation est terminée, retirez le pool de test.
ceph osd pool delete test test –yes-i-really-really-mean-it
Pour plus de détails sur SUSE Enterprise Storage, visitez ces pages.
Résumé
Face à l'augmentation spectaculaire des volumes de données non structurées et de données de sauvegarde/archivage, les solutions de
stockage traditionnelles sont incapables d'évoluer ou de gérer et servir efficacement ces données. Pour les données non structurées, les
performances SAN et NAS sont souvent moins intéressantes que leur coût par Go. La gestion du stockage et des sites est souvent complexe,
et garantir la fiabilité des systèmes des clients devient difficile, voire impossible.
SUSE Enterprise Storage sur matériel HPE fait appel à des technologies de stockage d'objets et à des serveurs standard pour proposer des qualités
de coût modéré, fiabilité, flexibilité et gestion centralisée que recherchent les entreprises pour le stockage de plusieurs péta-octets de données
non structurées. Les serveurs standard proposés par HPE permettent de construire une infrastructure matérielle de cluster fiable, facile à
administrer et à supporter. SUSE Enterprise Storage fournit le même ensemble de qualités côté logiciels. L'association de ce matériel et de ces
logiciels définit une solution dont le TCO est inférieur à celui du stockage traditionnel, et qui peut être conçue puis étendue en réponse à des
besoins présents et futurs en matière de données non structurées.
Cette solution apporte les avantages de contrôle et de coût des solutions open source aux entreprises qui sont prêtes à en tirer parti.
Les caractéristiques et les fonctionnalités de stockage de ce type de solution (et au prix open source) permettent d'obtenir un TCO
incomparable. Enfin, cette solution évite le provisionnement captif pour les logiciels du cluster.
Ce Livre blanc montre que les serveurs HPE Apollo 4200 et Apollo 4500 s'imposent comme socle matériel pour une solution SUSE Enterprise
Storage adaptée aux besoins de stockage présents et futurs des entreprises. Avec ce matériel, votre entreprise peut créer une solution fiable et
prête à évoluer avec vos besoins, bénéficier d'un TCO très favorable en associant une solution de stockage défini par logiciel et des serveurs
standard et tirer parti des nombreux atouts de l’open source dans vos opérations.
Livre blanc technique
Glossaire
• Données froides, chaudes ou tièdes – Dans le domaine de la gestion des données, la « température » fait référence à la fréquence et
aux performances de l'accès aux données stockées. Les données froides étant rarement consultées, elles peuvent être stockées dans le
niveau/tier de stockage le moins performant. Lorsque la température de stockage augmente, les besoins en bande passante et en
performances instantanées (latence, IOPS) augmentent également.
• CRUSH – Controlled Replication Under Scalable Hashing. Dans un cluster SUSE Enterprise Storage, CRUSH utilise des règles et des
Placement Groups pour calculer de façon déterministe l’emplacement de stockage des objets.
• Domaine réseau impacté par les incidents – Domaine de la solution qui est impact lorsqu’un service ou un équipement matériel
important subit un incident.
• Stockage fédéré – Ensemble de ressources de stockage autonomes (avec gestion centralisée) qui définit les règles de stockage, de
gestion et de mouvement des données à travers le cluster. Plusieurs systèmes de stockage sont combinés et gérés comme s'il s'agissait
d'un cluster de stockage unique.
• Stockage d'objets – Modèle de stockage à grande échelle implémenté avec un espace de noms non hiérarchisé. Ce type de
stockage travaille au niveau des objets et non des systèmes de fichiers ou des blocs de disques. Des métadonnées sont associées à chaque
objet pour préciser son contexte. Généralement accessible par une API REST. Par ailleurs un sous-ensemble de solution SDS.
• Placement Group (PG) – Mappage d’objets sur les OSD. Les pools contiennent un certain nombre de groupes PG, et plusieurs groupes
PG peuvent être mappés sur chaque OSD.
• Pool – Partition logique (compréhensible pour un utilisateur humain) définie pour le stockage des objets. Les pools définissent la
propriété des objets et les conditions d'accès aux objets, le nombre de répliques de l’objet, le nombre de Placement Groups et les règles
CRUSH à utiliser.
• RADOS – Gisement d’objets distribué, autonome et fiable. Il s'agit des logiciels de SUSE Enterprise Storage qui stockent
les données de l’utilisateur.
• REST – REpresentational State Transfer est une architecture client-serveur en couches sans état, qui peut être mise en cache et qui
présente une interface uniforme. Dans SUSE Enterprise Storage, les API REST sont déployées au-dessus de HTTP. Si une API obéit aux
principes REST, elle est dite « RESTful ».
• SDS, stockage défini par logiciel – Modèle de gestion de stockage indépendant du matériel. Inclut généralement des politiques pour les
utilisateurs et peut inclure des fonctionnalités avancées telles que réplication, déduplication, instantanés et sauvegardes.
Pour plus de détails...
Densité élevée, efficacité, maintenabilité et flexibilité : la gamme de serveurs HPE Apollo 4000 est la solution parfaite pour les besoins de
stockage scale-out. Pour plus de détails sur les serveurs à densité optimisée, visitez ces pages.
SUSE Enterprise Storage repose sur Ceph, et une documentation très complète est disponible sur son site Web (ce Livre blanc s’en est
largement inspiré). Pour plus de détails : SUSE Enterprise Storage.
Pour plus de détails :
hpe.com/servers/apollo
Abonnez-vous sur
© Copyright 2016 Hewlett Packard Enterprise Development LP. Les informations contenues dans le présent document peuvent être modifiées à
tout moment et sans préavis. Les seules garanties applicables aux produits et aux services Hewlett Packard Enterprise sont stipulées dans les
déclarations de garantie explicites qui accompagnent ces produits ou ces services. Aucune information du présent document ne saurait être
considérée comme constituant une garantie complémentaire. Hewlett Packard Enterprise décline toute responsabilité quant aux éventuelles
erreurs ou omissions techniques ou rédactionnelles qui pourraient être constatées dans le présent document.
Aux États-Unis et dans d'autres pays, le logo OpenStack en forme de « O carré » est une marque/une marque déposée ou une marque de
service/une marque de service déposée reconnue comme appartenant à la OpenStack Foundation. Dans le présent document, ce nom est utilisé
avec l'autorisation de la OpenStack Foundation. HPE n'a aucune affiliation avec la OpenStack Foundation ou avec la communauté de l'OpenStack
Foundation, et nous ne sommes ni cautionnés ni sponsorisés par ces entités. Aux États-Unis et/ou dans d’autres pays, les noms « Pivotal » et
« Cloud Foundry » sont des marques et/ou des marques déposées reconnues comme appartenant à la société Pivotal Software, Inc. Le nom
« Google » est une marque déposée reconnue comme appartenant à la société Google Inc. Aux États-Unis et dans d'autres pays, le nom
« Linux » est une marque déposée reconnue comme appartenant à M. Linus Torvalds. Aux États-Unis et dans d'autres pays, les noms « Intel »
et « Intel Xeon » sont des marques reconnues comme appartenant à la société Intel Corporation.
4AA6-6494FRE, juillet 2016

Documents pareils