Déployer Elasticsearch et Kibana
Elasticsearch est un moteur de recherche open source de niveau entreprise. Accessible via une API étendue, Elasticsearch peut alimenter des recherches rapides qui prennent en charge vos applications de découverte de données. Il peut mettre à l'échelle des milliers de serveurs et accueillir des pétabytes de données. Sa grande capacité découle directement de son architecture élaborée et distribuée.
Les cas d'utilisation les plus courants pour Elasticsearch sont l'analyse à l'aide d'extractions de données super-fast à partir de sources de données structurées et non structurées, et la recherche en texte intégral alimentée par un langage de requête étendu et une compilation automatique.
Architecture
Cette architecture de référence présente un déploiement en cluster d'Elasticsearch et de Kibana.

Description de l'illustration elk-oci.png
Cette architecture comporte les composants suivants :
- Domaines 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 permet de tolérer les pannes. Les domaines de disponibilité ne partagent pas d'infrastructure comme l'alimentation ou le refroidissement, ou le réseau de domaine de disponibilité interne. Il est donc peu probable qu'un échec dans un domaine de disponibilité affecte les autres domaines de disponibilité de la région.
- Domaines d'erreur
Un domaine de panne est un regroupement de matériel et d'infrastructure au sein d'un domaine de disponibilité. Chaque domaine de disponibilité dispose de trois domaines de pannes dotés d'une alimentation et d'un matériel indépendants. Lorsque vous distribuez des ressources dans plusieurs domaines de pannes, vos applications peuvent tolérer la panne du serveur physique, la maintenance du système et les pannes d'alimentation dans un domaine de panne.
- Bastion host
L'hôte bastion est une instance de calcul qui sert de point d'entrée sécurisé et contrôlé vers la topologie depuis l'extérieur du nuage. L'hôte du bastion est généralement provisionné dans une zone démilitarisée (DMZ). Il vous permet de protéger les ressources sensibles en les plaçant dans des réseaux privés auxquels vous ne pouvez pas accéder directement depuis l'extérieur du cloud. La topologie dispose d'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 leur accès.
- Balanceur de charge
L'équilibreur de charge équilibre les opérations d'index vers les noeuds de données et l'accès Kibana aux noeuds maître. Il utilise deux processus d'écoute, l'un pour Kibana et l'autre pour l'accès aux données d'index, à l'aide de back-ends de noeud maître et de back-ends de noeud de données. L'équilibreur de charge se trouve dans un sous-réseau public avec une adresse IP publique.
- Noeuds maîtres
Les noeuds maîtres effectuent des tâches de gestion de cluster, telles que la création d'index et le rééquilibrage des shards. Ils ne stockent pas de données. Trois noeuds maîtres (recommandés pour les clusters plus grands) sont déployés sur trois domaines d'erreur afin d'assurer une haute disponibilité.
- Noeuds de données
Trois noeuds de données sont déployés sur trois domaines de pannes pour une haute disponibilité. Nous recommandons des instances Compute optimisées en mémoire car Elasticsearch dépend de la quantité de mémoire disponible. Chaque noeud de données est configuré avec un stockage de blocs GiB 200. En plus des machines virtuelles, Oracle Cloud Infrastructure propose des instances Bare Metal puissantes qui sont connectées dans des clusters à une infrastructure réseau 25 Gb sans versubscription. Cette configuration garantit une faible latence et un débit élevé, ce qui assure des charges de travail distribuées de haute performance.
- Kibana
Comme les noeuds maître, Kibana a des besoins relativement légers en ressources. La plupart des calculs sont poussés vers Elasticsearch. Dans ce déploiement, Kibana s'exécute sur les noeuds maître.
Recommandations
Vos exigences peuvent différer de l'architecture décrite ici. Utilisez les recommandations suivantes comme point de départ.
- VCN
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 à des sous-réseaux dans VCN. Utilisez les blocs CIDR qui se trouvent dans l'espace d'adresse IP privé standard.
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 besoins en matière de flux de trafic et de sécurité. Attachez toutes les ressources d'un niveau ou d'un rôle spécifique au même sous-réseau, qui peut servir de limite de sécurité.
Utilisez des sous-réseaux régionaux.
- Groupes de sécurité réseau
Vous pouvez utiliser NSG pour définir un ensemble de règles entrantes et sortantes qui s'appliquent à des VNIC spécifiques. Nous vous recommandons d'utiliser des NSG plutôt que des listes de sécurité, car les NSG vous permettent de séparer l'architecture de sous-réseau de 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 des NSG.
- Mode "block storage"
Cette architecture utilise 200 Go de stockage de blocs. Nous vous recommandons de configurer un gestionnaire de volumes logique (LVM) pour permettre au volume de croître si vous avez besoin de plus d'espace. Chaque volume de bloc est configuré pour utiliser des performances équilibrées et fournit 35K IOPS et 480 MBps de débit.
- Formes de calcul
Cette architecture utilise une forme de machine virtuelle (VM.Standard2.24) pour tous les noeuds de données. Ces instances de calcul peuvent propager le trafic à 25 Gbps et fournir une RAM de 320 Go.
Remarques
- Performances
Elasticsearch dépend de la quantité de mémoire disponible. Pour obtenir les meilleures performances, utilisez des formes de calcul qui vous fournissent une bonne quantité de mémoire. Vous pouvez utiliser des formes de métal nu, où vous pouvez obtenir jusqu'à 768 Go de RAM.
- Disponibilité
Les domaines de pannes offrent la meilleure résilience dans un domaine de disponibilité. Si vous avez besoin d'une disponibilité accrue, envisagez d'utiliser plusieurs domaines de disponibilité ou plusieurs régions pour votre déploiement.
- Evolutivité
Bien que vous puissiez mettre à l'échelle les noeuds maître et de données à l'intérieur et à l'extérieur manuellement, nous vous recommandons d'utiliser le redimensionnement automatique pour minimiser les risques de famine des services pour les ressources sous des charges élevées. Une stratégie de redimensionnement automatique doit tenir compte à la fois des noeuds maître et de données.
- Coût
Le coût de votre déploiement Elasticsearch dépend de vos exigences en matière de mémoire et de disponibilité. Les formes de calcul que vous choisissez ont un impact plus élevé sur les coûts associés à cette architecture.
Déployer
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 le déployer. Vous pouvez également télécharger le code à partir de GitHub vers votre ordinateur, personnaliser le code 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 location et d'utilisateur.
- Vérifiez et acceptez les conditions générales.
- Sélectionnez la région dans laquelle déployer la pile.
- Suivez les invites à 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 examinez 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 à l'aide de la CLI Terraform :
- Accédez à GitHub.
- Téléchargez ou clonez le code sur votre ordinateur local.
- Suivez les instructions de
cluster/single-ad/README.md
.
Journal des modifications
Ce journal répertorie uniquement les modifications importantes :
9 décembre 2020 | Instructions supplémentaires pour le déploiement de l'architecture à l'aide d'Oracle Cloud Infrastructure Resource Manager. |
29 mai 2021 | Ajout du bouton Déployer vers Oracle Cloud. |
Juin 21, 2021 | Lien du bouton Déployer vers Oracle Cloud mis à jour. |