Övervakning och operationshantering av MongoDB 4.0 med ClusterControl

Medan MongoDB har ägnat nästan ett decennium åt att uppnå mognad (första release februari 2009), är tekniken lite av ett mysterium för dem som har erfarenhet av konventionella relationsdatabasmiljöer (RDBMS). Att integrera NoSQL i en befintlig miljö utan fördjupad kunskap kan vara utmanande. Det är inte ovanligt att se MongoDB köra längs MySQL eller en annan RDBMS-databas.

Erfarenheten av RDBMS kan hjälpa dig att förstå några av processerna, men du behöver veta hur du översätter din expertis till NoSQL-världen. Att hantera produktionsmiljöer innefattar steg som driftsättning, övervakning av drifttid och prestanda, underhåll av systemsäkerhet, hantering av HA, säkerhetskopior och så vidare. Både RDBMS och NoSQL är genomförbara alternativ, men det finns specifika kritiska skillnader mellan de två som användare måste tänka på när de implementerar eller hanterar MongoDB. Tekniken förändras snabbt och vi måste anpassa oss snabbt.

När MongoDB plötsligt är ditt ansvar garanterar hanteringsverktyg att MongoDB-databaserna du hanterar är stabila och säkra. Genom att använda fördefinierade processer och automatisering kan du inte bara spara tid utan också skydda dig mot vanliga misstag. En hanteringsplattform som systematiskt tar itu med alla olika aspekter av databasens livscykel kommer att vara mer robust än att lappa ihop ett antal punktlösningar.

Hjärtat i ClusterControl är dess automatiseringsfunktion som låter dig automatisera de databasuppgifter du måste utföra regelbundet, som att distribuera nya databaser, lägga till och skala nya noder, hantera säkerhetskopior, hög tillgänglighet och failover, topologiändringar, uppgraderingar och mer. ClusterControl tillhandahåller programmerad säkerhet och behåller integriteten hos din databasinfrastruktur. Dessutom, med ClusterControl är MongoDB-användare inte längre föremål för leverantörslåsning; något som ifrågasattes av många nyligen. Du kan distribuera och importera en mängd olika MongoDB-versioner och leverantörer från en enda konsol gratis. Användare av MongoDB måste ofta använda en blandning av verktyg och egentillverkade skript för att uppfylla sina krav, och det är bra att veta att du kan hitta dem kombinerade i en produkt.

I den här artikeln kommer vi att visa dig hur du distribuerar och hanterar MongoDB 4.0 på ett automatiserat sätt. Här hittar du hur du gör:

• ClusterControl-installation
• MongoDB-distributionsprocess
  • Distribuera ett nytt kluster
  • Importera befintligt kluster
• Skala MongoDB
  • Läs skalning (replikuppsättning)
  • Skriv skalning (sharding)
• Säker MongoDB
• Övervakning och trend
• Säkerhetskopiering och återställning

ClusterControl-installation

För att börja med ClusterControl behöver du en dedikerad virtuell maskin eller värd. Kraven på virtuella datorer och system som stöds beskrivs här. Den virtuella basen kan börja från 2 GB, 2 kärnor och diskutrymme 20 GB lagringsutrymme, antingen on-prem eller i molnet.

Installationen är väl beskriven i dokumentationen men i grunden handlar det om att ladda ner installationsskriptet som leder dig genom guiden. Guidens skript ställer in den interna databasen, installerar nödvändiga paket, förråd och gör andra nödvändiga justeringar. För internetlåsmiljöer kan du använda offlineinstallationsprocessen.

ClusterControl kräver SSH-åtkomst till databasvärdarna, och övervakningen kan vara agentbaserad eller agentlös. Ledningen är agentlös.

Konfigurera lösenordslös SSH till alla målnoder (ClusterControl och alla databasvärdar) innebär att följande kommandon körs på ClusterControl-servern:

$ ssh-keygen -t rsa # press enter on all prompts
$ ssh-copy-id -i ~/.ssh/id_rsa [ClusterControl IP address]
$ ssh-copy-id -i ~/.ssh/id_rsa [Database nodes IP address] # repeat this to all target database nodes

MongoDB-distribution och skalning

Distribuera ett nytt MongoDB 4.0-kluster

När vi väl går in i ClusterControl-gränssnittet är det första vi ska göra att distribuera ett nytt kluster eller importera ett befintligt. Den nya versionen 1.7.1 introducerar stöd för version 4.0. Du kan nu distribuera/importera och hantera MongoDB v4.0 med stöd för SSL-anslutningar.

Välj alternativet "Deploy Database Cluster" och följ instruktionerna som visas.

När vi väljer MongoDB måste vi ange Användare, Nyckel eller Lösenord och port för att ansluta med SSH till våra servrar. Vi behöver också namnet på vårt nya kluster och om vi vill att ClusterControl ska installera motsvarande programvara och konfigurationer åt oss.

Efter att ha ställt in SSH-åtkomstinformationen måste vi ange uppgifterna för att komma åt vår databas. Vi kan också specificera vilket arkiv som ska användas. Lagringskonfiguration är en viktig aspekt för databasservrar och kluster. Du kan ha tre typer av arkivet när du distribuerar databasserver/kluster med ClusterControl:

• Använd Vendor Repository
  Tillhandahåll programvara genom att ställa in och använda databasleverantörens föredragna programvarulager. ClusterControl kommer att installera den senaste versionen av det som tillhandahålls av databasleverantörens arkiv.
• Konfigurera inte leverantörsförråd
  Tillhandahåll programvara genom att använda det redan existerande programvaruförrådet som redan är inställt på noderna. Användaren måste ställa in programvaruförrådet manuellt på varje databasnod och ClusterControl kommer att använda detta förvaret för distribution. Detta är bra om databasnoderna körs utan internetanslutningar.
• Använd speglade arkiv (Skapa nytt arkiv)
  Skapa och spegla den nuvarande databasleverantörens arkiv och distribuera sedan med det lokala speglade arkivet. Detta låter dig "frysa" de aktuella versionerna av programpaketen.

I nästa steg måste vi lägga till våra servrar i klustret som vi ska skapa. När vi lägger till våra servrar kan vi ange IP eller värdnamn. För det senare måste vi ha en DNS-server eller ha lagt till våra MongoDB-servrar till den lokala upplösningsfilen (/etc/hosts) i vår ClusterControl, så att den kan lösa motsvarande namn som du vill lägga till. För vårt exempel kommer vi att distribuera ett ReplicaSet med tre servrar, en primär och två sekundärer. Det är möjligt att distribuera endast 2 MongoDB-noder (utan arbiter). Förbehållet med detta tillvägagångssätt är ingen automatisk failover, eftersom en 2-nodsinställning är sårbar för delad hjärna. Om den primära noden går ner krävs manuell failover för att göra den andra servern som primär. Automatisk failover fungerar bra med 3 noder och mer. Det rekommenderas att en replikuppsättning har ett udda antal röstberättigade medlemmar. Feltolerans för en replikuppsättning är antalet medlemmar som kan bli otillgängliga och fortfarande lämna tillräckligt många medlemmar i uppsättningen för att välja en primär. Feltoleransen för tre medlemmar är en, för fem är det två osv.

På samma sida kan du välja mellan olika MongoDB-versioner:

När allt är klart, tryck på distribuera-knappen. Du kan övervaka statusen för skapandet av vårt nya kluster från ClusterControl-aktivitetsmonitorn. När uppgiften är klar kan vi se vårt kluster på huvudskärmen för ClusterControl och i topologivyn.

Som vi kan se på bilden, när vi väl har skapat vårt kluster, kan vi utföra flera uppgifter på det, som att konvertera replikuppsättningar till shard eller lägga till noder till klustret.

Importera ett nytt kluster

Vi har också möjlighet att hantera ett befintligt kluster genom att importera det till ClusterControl. Sådan miljö kan skapas med ClusterControl eller andra metoder som dockningsinstallation.

Först måste vi ange SSH-åtkomstuppgifterna till våra servrar. Sedan anger vi åtkomstuppgifterna till vår databas, serverdatakatalogen och versionen. Vi lägger till noderna efter IP eller värdnamn, på samma sätt som när vi distribuerar, och trycker på Importera. När uppgiften är klar är vi redo att hantera vårt kluster från ClusterControl.

Skala MongoDB

En av hörnstenarna i MongoDB är att den är byggd med hög tillgänglighet och skalning i åtanke. Skalning kan göras antingen vertikalt genom att lägga till fler resurser till servern eller horisontellt med fler noder. Horisontell skalning är vad MongoDB är bra på, och det är inte mycket mer än att sprida arbetsbördan till flera maskiner. I själva verket använder vi flera billiga råvaruhårdvaruboxar istället för att uppgradera till en dyrare högpresterande server. MongoDB erbjuder både läs- och skrivskalning, och vi kommer att avslöja skillnaderna mellan dessa två strategier åt dig. Huruvida du ska välja läs- eller skrivskalning beror helt på din applikations arbetsbelastning:om din applikation tenderar att läsa oftare än den skriver data kommer du förmodligen att vilja använda lässkalningsmöjligheterna i MongoDB.

Med ClusterControl är det ett enkelt steg att lägga till fler servrar till klustret. Du kan göra det från GUI eller CLI. För mer avancerade användare kan du använda ClusterControl Developer Studio och skriva ett resursbasvillkor för att expandera ditt kluster horisontellt.

Skärning

MongoDB-klippningslösningen liknar befintliga skärningsramverk för andra större databaslösningar. Den använder sig av en typisk lookup-lösning, där shardingen definieras i en shard-nyckel och intervallen lagras i en konfigurationsdatabas. MongoDB arbetar med tre komponenter för att hitta rätt shard för din data. En typisk fragmenterad MongoDB-miljö ser ut så här:

Den första komponenten som används är shard-routern som kallas mongos. Alla läs- och skrivoperationer måste skickas till shard-routern, vilket gör att alla shards fungerar som en enda databas för klientapplikationen. Shard-routern dirigerar frågorna till lämpliga shards genom att konsultera Configserver.

Shard hantering är verkligen lätt i MongoDB. Du kan lägga till och ta bort shards online och MongoDB shard-routern kommer automatiskt att anpassa sig till vad du säger åt den. Om du vill veta mer på djupet om hur man bäst hanterar skärvor, läs vårt blogginlägg om hantering av MongoDB-skärvor.

Säker MongoDB

MongoDB kommer med väldigt lite säkerhet direkt:till exempel är autentisering inaktiverad som standard. Med andra ord:som standard har vem som helst roträttigheter över vilken databas som helst. En av ändringarna som MongoDB tillämpade för att minska riskerna var att ändra sin standardbindning till 127.0.0.1. Detta förhindrar att det binds till den externa IP-adressen, men naturligtvis kommer detta att återställas av de flesta som installerar det. ClusterControl tar bort mänskliga fel och ger tillgång till en uppsättning säkerhetsfunktioner för att automatiskt skydda dina databaser från hack och andra hot. Vi har tidigare publicerat en kort video med säkerhetstips.

Den nya versionen av ClusterControl erbjuder SSL-stöd för MongoDB-anslutningar. Aktivering av SSL lägger till ytterligare en säkerhetsnivå för kommunikation mellan applikationerna (inklusive ClusterControl) och databasen. MongoDB-klienter öppnar krypterade anslutningar till databasservrarna och verifierar identiteten för dessa servrar innan känslig information överförs.

För att aktivera SSL-anslutning måste du använda den senaste s9s-klienten. Du kan installera den med

wget http://repo.severalnines.com/s9s-tools/install-s9s-tools.sh
chmod 755 install-s9s-tools.sh
./install-s9s-tools.sh

Eller följ andra möjliga installationsmetoder som beskrivs här.

När du har installerat s9s-verktyg (min version 1.7-93.1) kan du använda flaggan --enable-ssl för att aktivera SSL-anslutning.

Exempel nedan:

[[email protected] ~]# s9s cluster --cluster-id=3 --enable-ssl --log
This is an RPC V2 job (a job created through RPC V2).
The job owner is 'admin'.
Accessing '/.runtime/jobs/jobExecutor' to execute...
Access ok.
Stopping the cluster
node1:27017: Node is already stopped by the user.
node2:27017: Node is already stopped by the user.
node3:27017: Node is already stopped by the user.
Checking/generating (expire 1000 days) server and CA certificate.
node1:27017: setting up SSL as required way of connection.
Using certificate 'mongodb/cluster_3/server'
node1:27017: installed /etc/ssl/mongodb/cluster_3/server.crt, /etc/ssl/mongodb/cluster_3/server.key and /etc/ssl/mongodb/cluster_3/server_ca.crt
node1:27017: Deploying client certificate 'mongodb/cluster_3/client'
Writing file 'node1:/etc/mongod.conf'.
node1:27017: /etc/mongod.conf [mongod] set: ssl_cert, ssl_key and ssl_ca values.
node2:27017: setting up SSL as required way of connection.
Using certificate 'mongodb/cluster_3/server'
node2:27017: installed /etc/ssl/mongodb/cluster_3/server.crt, /etc/ssl/mongodb/cluster_3/server.key and /etc/ssl/mongodb/cluster_3/server_ca.crt
node2:27017: Deploying client certificate 'mongodb/cluster_3/client'
Writing file 'node2:/etc/mongod.conf'.
node2:27017: /etc/mongod.conf [mongod] set: ssl_cert, ssl_key and ssl_ca values.
node3:27017: setting up SSL as required way of connection.
Using certificate 'mongodb/cluster_3/server'
node3:27017: installed /etc/ssl/mongodb/cluster_3/server.crt, /etc/ssl/mongodb/cluster_3/server.key and /etc/ssl/mongodb/cluster_3/server_ca.crt
node3:27017: Deploying client certificate 'mongodb/cluster_3/client'
Writing file 'node3:/etc/mongod.conf'.
node3:27017: /etc/mongod.conf [mongod] set: ssl_cert, ssl_key and ssl_ca values.
Starting the cluster
node3:27017: Doing some preparation for starting the node.
node3:27017: Disable transparent huge page and its defrag according to mongo suggestions.
node3:27017: Checking file permissions and ownership.
node3:27017: Starting mongod MongoDb server with command:
ulimit -u 32000 -n 32000 &&  runuser -s /bin/bash mongod '-c mongod -f /etc/mongod.conf'
node3:27017: Verifing that 'mongod' process is started.
SSL setup done.

ClusterControl kommer att utföra alla nödvändiga steg inklusive att skapa certifiering på alla klusternoder. Sådana certifikat kan underhållas senare på fliken Nyckelhantering.

Övervakning

När du arbetar med databassystem bör du kunna övervaka dem. Det gör att du kan identifiera trender, planera för uppgraderingar eller förbättringar eller reagera effektivt på eventuella problem eller fel som kan uppstå.

Den nya ClusterControl 1.7.1 lägger till högupplöst övervakning för MongoDB-baserad. Den använder Prometheus som datalager med PromQL frågespråk. Listan över instrumentpaneler inkluderar MongoDB Server, MongoDB ReplicaSet, System Overview och Cluster Overview Dashboards. ClusterControl installerar Prometheus-agenter, konfigurerar mätvärden och upprätthåller åtkomst till Prometheus exportörers konfiguration via dess GUI, så att du bättre kan hantera parameterkonfiguration som samlarflaggor för exportörerna (Prometheus). Vi beskrev i detalj vad som kan övervakas nyligen i artikeln How to Monitor MongoDB with Prometheus &ClusterControl.

Larmning

Som databasoperatör måste vi informeras när något kritiskt inträffar i vår databas. De tre huvudsakliga metoderna i ClusterControl för att få en varning inkluderar:

• e-postmeddelanden
• integrationer
• rådgivare

Du kan ställa in e-postmeddelanden på användarnivå. Gå till Inställningar> E-postmeddelanden. Där du kan välja mellan kritik och typ av varning som ska skickas.

Nästa metod är att använda integrationstjänster. Detta för att skicka den specifika kategorin av evenemang till den andra tjänsten som ServiceNow-biljetter, Slack, PagerDuty etc. så att du kan skapa avancerade aviseringsmetoder och integrationer inom din organisation.

Den sista är att involvera sofistikerad mätetalanalys i Advisorsektionen, där du kan bygga intelligenta kontroller och triggers. Ett exempel här kan vara en förutsägelse av diskutrymmesanvändning eller klusterskalning genom att lägga till noder när arbetsbelastningen når förinställd nivå.

Säkerhetskopiering och återställning

Nu när du har din MongoDB replicaSet igång och har din övervakning på plats, är det dags för nästa steg:se till att du har en säkerhetskopia av dina data.

ClusterControl tillhandahåller ett gränssnitt för MongoDB backuphantering med stöd för schemaläggning och kreativa rapporter. Det ger dig två alternativ för säkerhetskopieringsmetoder.

• Mongodump
• Mongodb konsekvent säkerhetskopiering

Mongodump dumpar all data i binärt JSON-format (BSON) till den angivna platsen. Mongorestore kan senare använda BSON-filerna för att återställa din databas. ClusterControl MongoDB konsekvent säkerhetskopiering inkluderar transaktionerna från oploggen som kördes när säkerhetskopieringen gjordes.

En bra säkerhetskopieringsstrategi är en kritisk del av alla databashanteringssystem. ClusterControl erbjuder många alternativ för säkerhetskopiering och återställning/återställning.

ClusterControl-säkerhetskopiering kan konfigureras; du kan välja att behålla din säkerhetskopia under vilken tidsperiod som helst eller att aldrig ta bort säkerhetskopior. AES256-kryptering används för att säkra dina säkerhetskopior mot oseriösa element. För snabb återställning kan säkerhetskopior återställas direkt till säkerhetskopieringsklustret - ClusterControl hanterar hela återställningsprocessen från lansering till klusteråterställning, och tar bort felbenägna manuella steg från processen.