Un système de fichiers réseau distribué évolutif est adapté aux tâches gourmandes en données, comme le traitement d'images et la diffusion en continu de médias. Lorsqu'il est utilisé dans des environnements de calcul hautes performances (HPC), GlusterFS fournit un accès hautes performances aux jeux de données volumineux, en particulier aux fichiers immuables.
Architecture
Cette architecture de référence contient les composants d'infrastructure requis pour un système de fichiers réseau distribué. Il contient trois instances Bare Metal, qui représentent le minimum requis pour configurer la haute disponibilité pour GlusterFS.
Dans une configuration à trois serveurs, au moins deux serveurs doivent être en ligne pour permettre les opérations d'écriture sur le cluster. Les données sont répliquées sur tous les noeuds, comme illustré dans le diagramme.
Description de l'illustration glusterfs-oci.png
glusterfs-oci-oracle.zip
- Région
Une région Oracle Cloud Infrastructure est une zone géographique localisée qui contient des centres de données, appelés domaines de disponibilité. Les régions sont indépendantes d'autres régions et de grandes distances peuvent les séparer (dans les pays voire les continents).
- Domaine de disponibilité
Les domaines de disponibilité sont des centres de données autonomes et indépendants au sein d'une région. Les ressources physiques de chaque domaine de disponibilité sont isolées des ressources des autres domaines de disponibilité, ce qui assure la tolérance de pannes. Les domaines de disponibilité ne partagent ni infrastructure telle que l'alimentation ou le refroidissem*nt, ni réseau interne. Par conséquent, il est improbable qu'un problème affecte les autres domaines de disponibilité de la région.
- Domaine de pannes
Un domaine de pannes est un regroupement de matériel et d'infrastructures au sein d'un domaine de disponibilité. Chaque domaine de disponibilité comporte trois domaines de pannes avec une alimentation et un matériel indépendants. Lorsque vous distribuez des ressources entre plusieurs domaines de pannes, vos applications peuvent tolérer les pannes de serveur physique, la maintenance du système et les pannes d'alimentation au sein d'un domaine de pannes.
- Réseau et sous-réseaux cloud virtuels
Un VCN est un réseau personnalisable et défini par logiciel que vous configurez dans une région Oracle Cloud Infrastructure. Comme les réseaux cloud virtuels traditionnels, vous bénéficiez d'un contrôle total sur votre environnement réseau. Un VCN peut comporter plusieurs blocs CIDR qui ne se chevauchent pas et que vous pouvez modifier après avoir créé le VCN. Vous pouvez segmenter un VCN en sous-réseaux, qui peuvent être ciblés vers une région ou un domaine de disponibilité. Chaque sous-réseau se compose d'une plage contiguë d'adresses qui ne chevauchent pas les autres sous-réseaux du VCN. Vous pouvez modifier la taille d'un sous-réseau après sa création. Un sous-réseau peut être public ou privé.
Cette architecture utilise deux sous-réseaux : un sous-réseau public pour créer la DMZ et héberger le serveur de bastion, et un sous-réseau privé pour héberger les noeuds GlusterFS.
- Groupe de sécurité réseau
Les groupes de sécurité réseau agissent en tant que pare-feu virtuels pour vos ressources cloud. Avec le modèle de sécurité Zero Trust d'Oracle Cloud Infrastructure, tout le trafic est refusé et vous pouvez contrôler le trafic réseau au sein d'un VCN. Un groupe de sécurité réseau se compose d'un ensemble de règles de sécurité entrantes et sortantes qui s'appliquent uniquement à un ensemble spécifié de cartes d'interface réseau virtuelles dans un seul VCN.
- Liste de sécurité
Pour chaque sous-réseau, vous pouvez créer des règles de sécurité qui indiquent la source, la destination et le type de trafic qui doivent être autorisés en entrée et en sortie du sous-réseau.
- Noeuds GFS
Voici les en-têtes GlusterFS, avec 1 To de stockage de blocs attaché à chaque instance.
- /gfs-data
Dans l'architecture de référence, le client monte le volume GlusterFS au point de montage
/gfs-data, via lequel votre application accède au système de fichiers. Plusieurs serveurs peuvent accéder aux noeuds de tête en parallèle. - Bastion
L'hôte de base est une instance de calcul qui sert de point d'entrée sécurisé et contrôlé vers la topologie en dehors du cloud. Le bastion est généralement provisionné dans une zone démilitarisée (DMZ). Il permet de protéger les ressources sensibles en les plaçant dans des réseaux privés inaccessibles directement depuis l'extérieur du cloud. La topologie possède un seul point d'entrée connu que vous pouvez surveiller et auditer régulièrement. Ainsi, vous pouvez éviter d'exposer les composants les plus sensibles de la topologie sans compromettre l'accès à ces composants.
Recommandations
Vos besoins peuvent être différents de ceux de l'architecture décrite ici. Utilisez les recommandations suivantes comme point de départ.
- Architecture GlusterFS
Cette architecture utilise des volumes GlusterFS répliqués ; les données sont répliquées sur tous les noeuds. Cette configuration offre la plus grande disponibilité des données, mais utilise également la plus grande quantité d'espace. Comme indiqué dans le diagramme d'architecture, lorsque
File1est créé, il est répliqué sur les noeuds.GlusterFS prend en charge les architectures suivantes. Sélectionnez une architecture adaptée à vos besoins :
- Volumes distribués
Cette architecture est la configuration GlusterFS par défaut et permet d'obtenir une taille de volume et une évolutivité maximales. Il n'y a pas de redondance des données. Par conséquent, si une brique du volume échoue, elle entraîne la perte complète des données.
- Volumes répliqués
Cette architecture est particulièrement utilisée lorsque la haute disponibilité est essentielle. Les problèmes de perte de données dus à des défaillances de briques sont évités en répliquant des données sur plusieurs briques. Cette architecture de référence utilise la configuration des volumes répliqués.
- Volumes répliqués distribués
Cette architecture est une combinaison de volumes distribués et répliqués qui permet d'obtenir des volumes de plus grande taille qu'un volume répliqué et une disponibilité supérieure à un volume distribué. Dans cette configuration, les données sont répliquées sur un sous-ensemble du nombre total de briques. Le nombre de briques doit être un multiple du nombre de répliques. Par exemple, quatre briques de 1 To chacune vous donneront un espace distribué de 2 To avec une réplication double.
- Volumes entrelacés
Cette architecture est utilisée pour les fichiers volumineux qui seront divisés en petit* morceaux et chaque bloc est stocké en brique. La charge est répartie entre les briques et le fichier peut être extrait plus rapidement, mais aucune redondance de données n'est disponible.
- Volumes distribués entrelacés
Cette architecture est utilisée pour les fichiers volumineux avec une distribution sur plus de briques. Le compromis avec cette configuration est que si vous souhaitez augmenter la taille du volume, vous devez ajouter des briques en multiples du nombre de bandes.
- Volumes distribués
- Formes de calcul
Cette architecture utilise une forme Bare Metal (BM.Standard2.52) pour tous les noeuds GlusterFS. Ces instances de calcul Bare Metal disposent de deux cartes d'interface réseau physiques capables de propager le trafic sur 25 Gbits/s chacune. La deuxième carte d'interface réseau physique est dédiée au trafic GlusterFS.
- Mode "block storage"
Cette architecture utilise 1 To de stockage de blocs. Nous vous recommandons de configurer un gestionnaire de volumes logiques (LVM) pour que le volume augmente si vous avez besoin d'espace supplémentaire. Chaque volume de blocs est configuré pour utiliser des performances équilibrées et fournit des E/S par seconde 35K et 480 Mo/s de débit.
- Réseau cloud virtuel
Lorsque vous créez un VCN, déterminez le nombre de blocs CIDR requis et la taille de chaque bloc en fonction du nombre de ressources que vous prévoyez d'attacher aux sous-réseaux du VCN. Utilisez des blocs CIDR compris dans l'espace d'adresse IP privée standard.
Sélectionnez des blocs CIDR qui ne chevauchent aucun autre réseau (dans Oracle Cloud Infrastructure, votre centre de données on-premise ou un autre fournisseur cloud) auquel vous souhaitez configurer des connexions privées.
Après avoir créé un VCN, vous pouvez modifier, ajouter et supprimer ses blocs CIDR.
Lorsque vous concevez les sous-réseaux, tenez compte de vos exigences en matière de flux de trafic et de sécurité. Associez toutes les ressources d'un niveau ou d'un rôle spécifique au même sous-réseau, ce qui peut servir de limite de sécurité.
- Groupes de sécurité réseau
Vous pouvez utiliser des groupes de sécurité réseau pour définir un ensemble de règles entrantes et sortantes qui s'appliquent à des cartes d'interface réseau virtuelles spécifiques. Nous vous recommandons d'utiliser des groupes de sécurité réseau plutôt que des listes de sécurité, car les groupes de sécurité réseau vous permettent de séparer l'architecture de sous-réseau du VCN des exigences de sécurité de votre application. Dans l'architecture de référence, toutes les communications réseau sont contrôlées par le biais de groupes de sécurité réseau.
- Liste de sécurité
Utilisez des listes de sécurité pour définir des règles entrantes et sortantes qui s'appliquent à l'ensemble du sous-réseau.
Remarques
- Performances
Pour obtenir les meilleures performances, utilisez des cartes d'interface réseau dédiées pour communiquer de l'application à vos utilisateurs et aux têtes de réseau GlusterFS. Utilisez la carte d'interface réseau principale pour la communication entre votre application et les utilisateurs. Utilisez la carte d'interface réseau secondaire pour communiquer avec les en-têtes GlusterFS. Vous pouvez également modifier les performances de volume pour le stockage par blocs afin d'augmenter ou de réduire les IOPS et le débit de votre disque.
- Disponibilité
Les domaines de pannes offrent la meilleure résilience au sein d'un domaine de disponibilité. Si vous avez besoin d'une disponibilité supérieure, envisagez d'utiliser plusieurs domaines de disponibilité ou plusieurs régions. Pour les charges de travail stratégiques, envisagez d'utiliser des volumes GlusterFS répartis par bandes.
- Coût
Le coût de votre déploiement GlusterFS dépend de vos exigences en matière de performances et de disponibilité du disque :
- Vous pouvez choisir l'une des options de performances suivantes : performances élevées, performances équilibrées et faible coût.
- Pour une plus grande disponibilité, vous avez besoin d'un plus grand nombre de noeuds et de volumes GlusterFS.
déploiement
Le code requis pour déployer cette architecture de référence est disponible dans GitHub. Vous pouvez extraire le code dans Oracle Cloud Infrastructure Resource Manager en un seul clic, créer la pile et la déployer. Vous pouvez également télécharger le code à partir de GitHub sur votre ordinateur, le personnaliser et déployer l'architecture à l'aide de la CLI Terraform.
- Déployer à l'aide d'Oracle Cloud Infrastructure Resource Manager :
- Cliquez sur .
Si vous n'êtes pas déjà connecté, entrez les informations d'identification de la location et de l'utilisateur.
- Consulter et accepter les conditions générales.
- Sélectionnez la région de déploiement de la pile.
- Suivez les invites affichées à l'écran et les instructions pour créer la pile.
- Après avoir créé la pile, cliquez sur Actions Terraform et sélectionnez Plan.
- Attendez que le travail soit terminé et vérifiez le plan.
Pour apporter des modifications, revenez à la page Détails de la pile, cliquez sur Modifier la pile et apportez les modifications requises. Exécutez ensuite à nouveau l'action Plan.
- Si aucune autre modification n'est nécessaire, revenez à la page Détails de la pile, cliquez sur Actions Terraform et sélectionnez Appliquer.
- Cliquez sur .
- Déployer avec l'interface de ligne de commande Terraform :
- Accédez à GitHub.
- Clonez ou téléchargez le référentiel sur votre ordinateur local.
- Suivez les instructions du document
README.
Voir plus
- Structure des meilleures pratiques pour Oracle Cloud Infrastructure
- Documentation Oracle Cloud Infrastructure
- Documentation GlusterFS
Journal des modifications
Ce journal répertorie les modifications importantes :
| 5 novembre 2021 |
|
| Juin 17, 2021 | Mise à jour de la section Déployer pour inclure le déploiement automatique. |
