Déployer Elastic sur des machines virtuelles Azure

Les machines virtuelles Azure fournissent aux utilisateurs Azure un moyen flexible de déployer leurs charges de travail Elastic nouvelles et existantes dans l’infrastructure cloud. Cette option de déploiement est optimale pour les équipes qui ont besoin du plus de contrôle sur l’infrastructure pour répondre aux contraintes architecturales ou de conformité, telles que les équipes dont les charges de travail doivent être déployées dans leur locataire Azure.

Rappelez-vous que la jeune entreprise de vente au détail pour laquelle vous travaillez actuellement utilise Elastic sur site pour gérer les transactions de vente. Ils souhaitent migrer vers les machines virtuelles Azure afin d'améliorer l'accessibilité des données pour les travailleurs distants et d'autres services tout en réduisant le fardeau de la maintenance de l'infrastructure.

Ici, vous découvrez les étapes de déploiement d’une charge de travail Elastic sur des machines virtuelles Azure. Les liens vers les instructions référencées dans cette unité se trouvent dans la section Plus d’informations du résumé.

Choisir le modèle de responsabilité de déploiement

Pour un déploiement dans votre propre abonnement Azure sur l’infrastructure que vous contrôlez, créez des machines virtuelles Linux Azure et installez Elasticsearch, Kibana et tous les composants d’ingestion requis à l’aide de packages Elastic pris en charge. Vous gérez les mises à jour du système d’exploitation invité et des applications, la mise en réseau, les certificats, le contrôle d’accès, la gestion de la capacité, les sauvegardes et la restauration. Azure gère l’infrastructure physique sous-jacente.

Utilisez la matrice de support Elastic et la stratégie de version pour choisir un système d’exploitation pris en charge et une version Elastic maintenue. Pour une nouvelle installation, utilisez les versions correspondantes d’Elastic Stack en suivant les instructions de compatibilité de l’installation. Une valeur par défaut de l’interface utilisateur ne constitue pas une stratégie de prise en charge des versions.

Pour l’infrastructure gérée par Elastic, envisagez Elastic Cloud (Elasticsearch) - Azure Native ISV Service. Cloud Hosted fournit Elasticsearch et Kibana managés avec intégration à Azure et facturation.

Consultez les instructions sur les limites d’hébergement Azure Native et la connexion de Logstash à Elastic Cloud.

Comparer l’alternative de service géré

La vue d’ensemble suivante est facultative. Vous n’avez pas besoin d’acheter le service managé pour effectuer l’exercice de la machine virtuelle. Pour comparer l’alternative de service managé, procédez comme suit :

1. Vérifiez les conditions préalables actuelles au service managé, notamment l’accès propriétaire/contributeur au niveau de l’abonnement et l’éligibilité à l’achat sur Marketplace. Gérez les exigences de consentement du locataire ; le créateur de déploiement n’a pas systématiquement besoin d’être administrateur du locataire. Ne partez pas du principe que les crédits d’essai Azure financent cet achat.
2. Suivez les instructions de l’article « Créer une application Elastic ». Choisissez Cloud Hosted pour cette comparaison, puis l’abonnement/le groupe de ressources, la région prise en charge et le plan approprié. Consultez les tarifs réels et les conditions de facturation avant de sélectionner Vérifier + créer, puis Créer.
3. Ouvrez le déploiement via l’intégration et vérifiez l’accès Elasticsearch/Kibana. La ressource d’intégration côté client n’est pas un ensemble de machines virtuelles Elasticsearch dans votre tenant. Logstash reste un expéditeur configuré séparément.
4. Si l’accès privé est requis, suivez les instructions d’Elastic Azure Private Link, notamment le point de terminaison privé, le DNS et la stratégie de connexion côté Elastic. Un point de terminaison privé modifie la connectivité, pas la propriété ou l’emplacement du service sous-jacent. Pour Cloud Hosted, le SSO de la console Elastic Cloud ne vous connecte pas via le point de terminaison Kibana privé ; utilisez l’authentification de pile prise en charge ou un fournisseur d’identité configuré séparément, comme décrit dans ce guide.
5. Avant le nettoyage, inventorie toutes les déploiements de l’organisation Elastic et vérifiez quel abonnement Azure reçoit leur facture. Supprimez les ressources créées par Azure via Azure et suivez les instructions de suppression des ressources Elastic. Supprimez uniquement les déploiements de travaux pratiques concernés. Ne supprimez jamais des déploiements sans rapport avec ces travaux pour interrompre la facturation d’une organisation partagée. Respectez les restrictions d’Elastic concernant les groupes de ressources : ne supprimez pas le groupe de ressources du premier déploiement tant que d’autres déploiements continuent d’être facturés sur celui-ci.
6. Examinez séparément l’abonnement SaaS du Marketplace et ses conditions contractuelles. S’il s’agissait d’un abonnement SaaS de laboratoire dédié, annulez-le à l’aide de la procédure de cycle de vie SaaS applicable. La suppression d’un groupe de ressources, ou même le dernier déploiement, n’établit pas que l’abonnement commercial a été annulé.

Provisionnement et installation

Créez les machines virtuelles, le stockage persistant et les contrôles réseau dans un groupe de ressources dédié. Établissez la connectivité de l’administrateur et l’accès sortant explicite pour l’installation du package. Sur Ubuntu, suivez le guide Elasticsearch Debian, puis le guide Kibana Debian. Configurez Logstash séparément, si nécessaire.

Azure CLI et Azure PowerShell peuvent automatiser l’approvisionnement des ressources Azure ; l’installation et la configuration du logiciel Elastic doivent également être implémentées. L'approvisionnement d'une machine virtuelle Azure seul ne crée pas de cluster Elasticsearch opérationnel.

L’exercice utilise une configuration délibérément de quatre machines virtuelles : trois nœuds Elasticsearch et un hôte Kibana, chacun avec 2 processeurs virtuels, 8 Gio de RAM et un stockage managé persistant. Il fournit des versions de package fixes, un plan d’adresses privée, des règles de groupe de sécurité réseau explicites et un certificat de navigateur distinct. Cela rend la procédure d’apprentissage concrète ; cela ne fait pas de ces tailles une recommandation de dimensionnement de production.

Dimensionner et rendre le déploiement résilient

Utilisez Rally dans un environnement de test distinct pour évaluer les charges de travail représentatives. Tenez compte du heap Elasticsearch, de la mémoire hors heap, du cache du système de fichiers, de la capacité de stockage/IOPS et de la marge pour les pannes. Privilégiez le dimensionnement automatique du tas par défaut, sauf si des mesures justifient de le modifier.

Trois nœuds de données qui sont également éligibles au maître sont un point de départ raisonnable de petit cluster. Pour les index ordinaires, assurez-vous qu’il existe au moins un réplica alloué et que les clients peuvent atteindre plusieurs nœuds ou un point de terminaison à charge équilibré approprié. Trois de ces nœuds éligibles maître peuvent conserver une majorité de vote après l’échec d’un nœud. Le nombre de nœuds seul ne garantit pas la résilience entre zones de disponibilité et ne remplace pas les instantanés. Consultez les instructions sur la résilience des petits clusters et les rôles de nœud.

Pour la disponibilité de Kibana en production, utilisez plusieurs instances avec l’équilibrage de charge approprié et une configuration cohérente.

Logstash est facultatif. Déployez Logstash lorsque l’architecture d’ingestion nécessite ses fonctionnalités d’entrée, de filtrage, de routage ou de mise en mémoire tampon. La disponibilité de production nécessite plus que l’installation de deux copies : il faut configurer les entrées pour l’équilibrage de charge ou le basculement, les files d’attente persistantes appropriées, l’authentification de sortie et TLS. Suivez les instructions de déploiement et de mise à l’échelle de Logstash. Les files d’attente persistantes sont locales à chaque instance ; ne décrivez pas une paire d’instances comme une file d’attente partagée répliquée.

Configurer des identités et des connexions chiffrées

Elasticsearch fournit un superutilisateur prédéfini elastic . D’autres utilisateurs intégrés ont des objectifs spécifiques de service ou de surveillance ; vous ne choisissez pas leur nom. Utilisez le jeton d’enrôlement actuel de Kibana pour configurer la connexion de Kibana à Elasticsearch. Créez des identités ou des clés API dont la portée est adaptée pour les applications, l’ingestion et l’accès humain. En particulier, logstash_system il s’agit d’une identité de surveillance, et non d’une identité de sortie de pipeline.

Consultez les conseils relatifs aux utilisateurs intégrés, à la configuration automatique de la sécurité et à ses exceptions, à Kibana HTTPS et à la sécurité Logstash.

Déterminez si ce modèle convient au détaillant

Utilisez des machines virtuelles autogérées si les systèmes d’exploitation invités et l’infrastructure doivent être contrôlés par le client, et si l’équipe est en mesure de les exploiter. Le déplacement des machines virtuelles vers Azure supprime la gestion matérielle physique, et non la responsabilité du système d’exploitation invité, des mises à niveau d’Elastic, des instantanés, des certificats ou de la capacité. Si la réduction de ces responsabilités opérationnelles est le critère principal, évaluez plutôt Elastic Cloud. Dans les deux cas, préparez et vérifiez un plan de migration de données distinct avant de déplacer la charge de travail existante du détaillant.