Elastic implementeren op virtuele Azure-machines

Virtuele Azure-machines (VM's) bieden Azure-gebruikers een flexibele manier om hun nieuwe en bestaande Elastic workloads in de cloudinfrastructuur te implementeren. Deze implementatieoptie is het meest geschikt voor teams die de meeste controle over de infrastructuur nodig hebben om te voldoen aan architecturale of nalevingsbeperkingen, zoals teams waarvan de workloads moeten worden geïmplementeerd binnen hun Azure tenant.

Zoals u weet, gebruikt de startup retailer waar u voor werkt momenteel Elastic on-premises om verkooptransacties te beheren. Ze willen migreren naar Azure VM's om de toegankelijkheid van gegevens voor externe werknemers en andere afdelingen te verbeteren en tegelijkertijd de belasting van het onderhouden van de infrastructuur te verminderen.

Hier vindt u informatie over de stappen voor het implementeren van een Elastic-workload op Azure-VM’s. Koppelingen naar de richtlijnen waarnaar in deze les wordt verwezen, vindt u in de sectie Meer informatie van de samenvatting.

Kies het model voor implementatieverantwoordelijkheid

Voor een implementatie in uw eigen Azure-abonnement op infrastructuur die u beheert, maakt u Azure Linux-VM's en installeert u Elasticsearch, Kibana en eventuele vereiste gegevensinnamecomponenten met behulp van ondersteunde Elastic-pakketten. U beheert updates voor gastbesturingssysteem en toepassingen, netwerken, certificaten, toegangsbeheer, capaciteit, back-ups en herstel. Azure beheert de onderliggende fysieke infrastructuur.

Gebruik het beleid voor Elastic Support Matrix en versie om een ondersteund besturingssysteem en een onderhouden Elastic-release te kiezen. Gebruik voor een nieuwe installatie overeenkomende Elastic Stack-versies volgens de richtlijnen voor de installatiecompatibiliteit. Een standaardinstelling van de UI is geen beleid voor releaseondersteuning.

Voor door Elastic beheerde infrastructuur kunt u Elastic Cloud (Elasticsearch) overwegen: Azure Native ISV Service. Cloud Hosted biedt beheerde Elasticsearch en Kibana met Azure integratie en facturering.

Zie de richtlijnen voor Azure Native-hostinggrenzen en het verbinden van Logstash met Elastic Cloud.

Vergelijk het alternatief voor beheerde services

Het volgende overzicht is optioneel. U hoeft de beheerde service niet aan te schaffen om de VM-oefening te voltooien. Voer de volgende stappen uit om het alternatief voor beheerde services te vergelijken:

1. Controleer de huidige vereisten voor beheerde services, waaronder toegang op abonnementsniveau als Eigenaar/Bijdrager en geschiktheid voor Marketplace-aankopen. Los eventuele tenanttoestemmingsvereisten op; de maker van de implementatie hoeft niet per se een tenantbeheerder te zijn. Neem niet aan dat Azure-proeftegoed deze aankoop financiert.
2. Volg de instructies in Een Elastic-toepassing maken. Kies Cloud Hosted voor deze vergelijkingstool, vervolgens het abonnement/de resourcegroep, de ondersteunde regio en het juiste plan. Bekijk de werkelijke prijzen en factureringsvoorwaarden voordat u Controleren + maken en Maken.
3. Open de deployment via de integratie en controleer Elasticsearch/Kibana-toegang. De integratieresource aan de klantzijde is geen set Elasticsearch-VM's in uw tenant. Logstash blijft een afzonderlijk geconfigureerde afzender.
4. Als privétoegang is vereist, volgt u de richtlijnen voor Elastic Azure Private Link, waaronder het privé-eindpunt, DNS en het verbindingsbeleid aan de Elastic-zijde. Een privé-eindpunt wijzigt de connectiviteit, niet het eigendom of de locatie van de onderliggende service. Eenmalige aanmelding via de Elastic Cloud-console meldt je niet aan via het privé-Kibana-eindpunt voor Cloud Hosted; gebruik ondersteunde stackverificatie of een afzonderlijk geconfigureerde id-provider, zoals beschreven in die handleiding.
5. Voordat u opschoont, inventariseert u alle implementaties in de Elastic-organisatie en controleert u aan welk Azure-abonnement de kosten worden doorbelast. Verwijder Azure gemaakte resources via Azure en volg de richtlijnen voor het verwijderen van resources van Elastic. Verwijder alleen de bedoelde labuitrolacties; verwijder nooit niet-gerelateerde uitrolacties om kosten voor een gedeelde organisatie te voorkomen. Volg de resourcegroepbeperkingen van Elastic: verwijder de resourcegroep van de eerste implementatie niet zolang andere implementaties eraan worden gefactureerd.
6. Inspecteer afzonderlijk het Marketplace SaaS-abonnement en de contractvoorwaarden. Als dit een dedicated lab-SaaS-abonnement is, annuleert u het met behulp van de toepasselijke SaaS-levenscyclusprocedure. Als u één resourcegroep of zelfs de laatste implementatie verwijdert, betekent dit niet dat het commerciële abonnement is geannuleerd.

Provisioneren en installeren

Maak de VM's, permanente opslag en netwerkbesturingselementen in een toegewezen resourcegroep. Configureer beheerderstoegang en expliciete uitgaande toegang voor pakketinstallatie. Volg op Ubuntu de Elasticsearch Debian-gids en vervolgens de Kibana Debian-gids. Configureer de optionele Logstash afzonderlijk.

Azure CLI en Azure PowerShell kunnen het inrichten van Azure resources automatiseren; installatie en configuratie van Elastic software moeten ook worden geïmplementeerd. Het inrichten van een Azure VM op zichzelf maakt nog geen werkend Elasticsearch-cluster.

De oefening maakt gebruik van een bewust kleine configuratie van vier VM's: drie Elasticsearch-knooppunten en één Kibana-host, elk met 2 vCPU's, 8 GiB RAM en permanente beheerde opslag. Het levert vaste pakketversies, een privéadresplan, expliciete NSG-regels en een afzonderlijk browsercertificaat. Dit maakt de leerprocedure concreet; het vormt geen aanbeveling voor dimensionering in productie van die afmetingen.

Grootte wijzigen en de implementatie robuust maken

Gebruik Rally in een afzonderlijke testomgeving om representatieve workloads te beoordelen. Houd rekening met Elasticsearch-heap, niet-heapgeheugen, bestandssysteemcache, opslagcapaciteit/IOPS en marge voor storingen. Geef de voorkeur aan de standaard automatische heap-grootte, tenzij u een goed onderbouwde reden hebt om deze te overschrijven.

Drie datanodes die ook mastergeschikt zijn, zijn een redelijk beginpunt voor kleine clusters. Voor gewone indexen moet u ervoor zorgen dat er ten minste één toegewezen replica is en dat clients meer dan één knooppunt of een geschikt eindpunt met gelijke taakverdeling kunnen bereiken. Drie dergelijke master-geschikte knooppunten kunnen een stemmeerderheid behouden nadat één knooppunt is uitgevallen. Alleen het aantal knooppunten garandeert geen tolerantie op beschikbaarheidszoneniveau en vervangt snapshots niet. Zie de richtlijnen voor resilience van kleine clusters en knooppuntrollen.

Gebruik voor de beschikbaarheid van Kibana in productie meerdere exemplaren met de juiste load balancing en consistente configuratie.

Logstash is optioneel. Zet deze in wanneer het ingestieontwerp de invoer-, filter-, routerings- of buffermogelijkheden nodig heeft. Voor productiebeschikbaarheid is meer dan het installeren van twee exemplaren vereist: invoer configureren voor taakverdeling of failover, geschikte permanente wachtrijen, uitvoerverificatie en TLS. Volg de richtlijnen voor de Logstash-implementatie en -schaalaanpassing. Permanente wachtrijen zijn lokaal voor elke instantie; beschrijf geen paar instanties als een gerepliceerde gedeelde wachtrij.

Identiteiten en versleutelde verbindingen configureren

Elasticsearch biedt een vooraf gedefinieerde elastic superuser. Andere ingebouwde gebruikers hebben specifieke service- of bewakingsdoeleinden; u kiest hun namen niet. Gebruik de huidige Kibana-registratie om de verbinding van Kibana met Elasticsearch te configureren. Maak identiteiten of API-sleutels met een passend bereik voor toepassingen, gegevensinname en menselijke toegang. Met name logstash_system is een bewakingsidentiteit, geen pijplijnuitvoeridentiteit.

Zie de richtlijnen voor ingebouwde gebruikers, automatische beveiligingsconfiguratie en de uitzonderingen, Kibana HTTPS en Logstash-beveiliging.

Bepaal of dit model geschikt is voor de retailer

Gebruik zelfbeheerde VM's als door de klant beheerde gastbesturingssystemen en infrastructuur vereisten zijn en het team deze kan beheren. Als u de VM's naar Azure verplaatst, neemt u het beheer van fysieke hardware weg, maar niet de verantwoordelijkheid voor het gastbesturingssysteem, elastische upgrades, momentopnamen, certificaten of capaciteit. Als het verminderen van deze operationele verantwoordelijkheden de sterkere vereiste is, evalueer dan in plaats daarvan Elastic Cloud. In beide gevallen bereidt en verifieert u een afzonderlijk plan voor gegevensmigratie voordat u de bestaande workload van de detailhandelaar verplaatst.