ECE est une solution d’orchestration de clusters Elasticsearch de manière centralisée. Cette solution permet de provisionner, gérer et monitorer Elasticsearch et Kibana depuis une seule console.
Une solution permettant de gérer des clusters issue de Cloud privé et/ou privé.
ECE Produit
ECE Training Fondamentaux
ECE Support
ECE Documentation
En général, l’utilisation de machines hôtes haut de gamme et un approvisionnement substantiel en ressources CPU et disque aideront Elastic Cloud Enterprise (ECE) à bien fonctionner, mais il y a certains aspects de l’architecture ECE que vous pouvez prendre en considération si vous voulez planifier votre installation en conséquence.
Le coordinateur et les directeurs ont besoin d’un stockage SSD rapide pour gérer correctement leurs services de gestion d’ECE. Pour les petits déploiements, vous pouvez colocaliser les services de gestion ECE avec les proxies et les allocataires sur le même hôte, ce qui signifie que vous devez utiliser un stockage SSD rapide pour l’ensemble de votre déploiement. Dans la prochaine leçon, vous verrez comment certains services de gestion ECE peuvent être séparés, au cas où le stockage SSD seul n’est pas possible.
Les alloueurs ont besoin de machines hôtes qui fournissent 128 à 256 Go de RAM pour héberger vos clusters Elasticsearch et vos instances Kibana. Avec une telle quantité de RAM, vous aurez besoin de moins d’hôtes et vos frais de gestion seront également moins élevés. Sur la base de l’expérience acquise avec l’offre d’hébergement Elastic Cloud, Elastic recommande les configurations suivantes pour les charges de travail de recherche et de journalisation :
Pour les charges de travail de recherche, vous devrez prendre en charge les opérations de fusion et de réindexation dans le temps ainsi que le tri externe rapide lorsque les données sont trop volumineuses pour être stockées en mémoire d’un seul coup
Pour atteindre ces objectifs, vous devez utiliser des disques SSD à haute performance et un rapport RAM/stockage de 1:16, voire 1:8
Pour l’enregistrement des charges de travail, des périodes de conservation des données plus longues nécessitent plus de stockage et un petit sous-ensemble de données, généralement le plus récent, est activement lu
Vous avez généralement besoin de beaucoup plus de stockage que la mémoire vive, de sorte que vous pouvez passer à un rapport RAM/stockage de 1:48 à 1:96
Vous pouvez également passer des SSD aux supports tournants tels que les disques de serveur haute performance pour avoir une solution plus rentable
Quelle que soit votre charge de travail prévue, vous devez éviter les pratiques suivantes pour obtenir de meilleures performances de votre déploiement Elastic Cloud Enterprise :
Ne pas sous-dimensionner les ressources CPU, en particulier dans les environnements à plusieurs tenant
Certains de vos utilisateurs peuvent avoir besoin de ressources CPU importantes
Ne pas surprovisionner les conteneurs pour les charges de travail mixtes en supposant que les demandes n’auront pas besoin de toutes leurs ressources en permanence
Les nœuds de recherche élastique fonctionnent en arrière-plan, même si vous n’exécutez pas activement de requêtes
Par exemple, le surapprovisionnement peut avoir un impact sur les fusions d’arrière-plan pour les charges de travail basées sur la recherche et les opérations de lecture/écriture pour les charges de travail d’enregistrement.
Vous devez toujours suivre les directives ci-dessous pour obtenir une bonne base de référence pour votre environnement de production :
Utilisez trois zones de haute disponibilité, que vous apprendrez plus en détail dans la prochaine leçon
Répartis sur les trois zones de disponibilité, trois coureurs qui occupent les fonctions de directeur et de coordinateur
Répartissez sur les trois zones de disponibilité autant de coureurs qui tiennent le rôle d’allocataire que nécessaire pour garantir la charge de travail que vous prévoyez d’exécuter
Suffisamment de runners qui tiennent le rôle de proxy pour traiter le volume de demandes des utilisateurs, ou au moins un par zone de disponibilité pour une haute disponibilité.
Vous pouvez suivre les directives ci-dessous pour configurer votre équilibreur de charge :
Utilisez le mode HTTP pour les ports 9200 et 9243 (trafic HTTP vers les clusters) ainsi que pour les ports 12400 et 12443 (trafic de la console d’administration).
Utilisez le mode TCP pour les ports 9300 et 9343 (transport du trafic client vers les clusters) et n’oubliez pas d’activer la prise en charge du protocole proxy dans l’équilibreur de charge.
Il est important de s’assurer que tous les équilibreurs de charge ou les proxies envoient le trafic HTTP aux déploiements hébergés sur ECE par le biais de HTTP/1.1.
Configurer les load balancers pour supprimer les en-têtes X-ForwardedFor entrants et les remplacer par l’IP source du client.
Elastic Cloud Enterprise résout les noms d’hôtes virtuels Elasticsearch par le biais du service externe ip.es.io, qui est fourni par Elastic et qui suit la RFC1918. Le service résout les noms d’hôtes virtuels de la forme clusterid.proxyaddress.ip.es.io. Par exemple, https://1503ef45b9d446a19b127f4e476cc68c.172.31.18.161.ip.es.io:9243 se résout à l’adresse proxy qui a été spécifiée lors de l’installation, qui est 172.31.18.161 dans cet exemple. Ensuite, la demande du client est envoyée au proxy qui extrait l’ID du cluster du nom d’hôte virtuel du cluster, qui est 1503ef45b9d446a19b127f4e476cc68c dans cet exemple. Enfin, le proxy utilise sa table de routage interne pour acheminer la demande vers le bon allocateur.
Vous devez configurer votre propre enregistrement DNS joker si vous ne souhaitez pas utiliser le service ip.es.io pour votre environnement de production. Votre enregistrement DNS joker devrait se résoudre à l’hôte proxy ou à un équilibreur de charge si vous avez plusieurs proxys derrière un équilibreur de charge. Vous pouvez créer à la fois une entrée DNS joker pour vos points terminaux et un certificat TLS/SSL joker afin de pouvoir créer plusieurs clusters sans avoir besoin de modifications DNS ou TLS/SSL supplémentaires. Il vous suffit de configurer votre DNS pour qu’il pointe vers vos équilibreurs de charge et d’y installer vos certificats, de sorte que la communication avec le cluster soit sécurisée.
3.Les équilibreurs de charge ou les proxies qui envoient du trafic HTTP aux déploiements hébergés sur votre nuage élastique