Condividi tramite


Distribuire un cluster MongoDB in servizio Azure Kubernetes (servizio Azure Kubernetes)

Questo articolo illustra le informazioni sui prerequisiti per la distribuzione di un cluster MongoDB in servizio Azure Kubernetes (servizio Azure Kubernetes). Offre anche una panoramica della strategia di distribuzione.

Importante

Il software open source è citato nella documentazione e negli esempi di Azure Kubernetes. Il software distribuito viene escluso dai contratti di servizio del servizio Azure Kubernetes, dalla garanzia limitata e supporto tecnico di Azure. Quando si usa la tecnologia open source insieme al servizio Azure Kubernetes, consultare le opzioni di supporto disponibili dalle rispettive community e dai gestori di progetti per sviluppare un piano.

Microsoft si assume la responsabilità di creare i pacchetti open source distribuiti nel servizio Azure Kubernetes. Tale responsabilità include la proprietà completa del processo di compilazione, analisi, firma, convalida e hotfix, oltre al controllo sui file binari nelle immagini del contenitore. Per altre informazioni, vedere Gestione delle vulnerabilità per il servizio Azure Kubernetes (AKS) e Copertura del supporto del servizio Azure Kubernetes (AKS).

Che cos'è MongoDB?

MongoDB è un sistema di gestione di database NoSQL diffuso progettato per gestire grandi volumi di dati non strutturati. A differenza dei database relazionali tradizionali che usano tabelle e righe, MongoDB usa un approccio flessibile e orientato ai documenti.

Nota

MongoDB Community Edition non è un software open source. È concesso in licenza con la Server Side Public License con "codice sorgente disponibile".

Cluster partizionato mongoDB

Un cluster partizionato mongoDB gestisce set di dati di grandi dimensioni e velocità effettiva elevata distribuendo i dati tra più server o partizioni. Questa architettura consente il ridimensionamento orizzontale, essenziale per le applicazioni con esigenze crescenti di dati e prestazioni.

Ecco una suddivisione dei relativi componenti chiave e del relativo funzionamento:

  • Partizioni: singole istanze di MongoDB denominate partizioni contengono subset di dati. Ogni partizione è un set di repliche o un gruppo di istanze di MongoDB che replicano i dati tra loro. I set di repliche garantiscono disponibilità elevata e tolleranza di errore.
  • Server di configurazione: i server che archiviano i metadati e le impostazioni di configurazione per il cluster partizionato sono denominati server di configurazione. Consentono di tenere traccia delle informazioni di distribuzione e routing dei dati del cluster. Un cluster dispone in genere di tre server di configurazione per garantire la ridondanza.
  • Istanze di Mongos: Mongos è un servizio di routing che indirizza le richieste client alla partizione appropriata. Funge da intermediario tra il client e le partizioni. Un'istanza di Mongos gestisce il routing delle query e aggrega i risultati delle partizioni.
  • Chiave di partizione: quando i dati vengono distribuiti tra partizioni, si basa su una chiave di partizione, ovvero un singolo campo indicizzato o più campi nei documenti. La chiave di partizione determina il modo in cui i dati vengono partizionati tra le partizioni. Una chiave di partizione ben scelta consente di garantire anche la distribuzione dei dati e l'esecuzione di query efficienti.
  • Distribuzione dei dati: i dati vengono distribuiti tra partizioni in base alla chiave di partizione. Questa distribuzione consente di bilanciare il carico e gestire in modo efficace set di dati di grandi dimensioni. MongoDB usa una strategia di partizionamento orizzontale basata su intervalli o basata su hash, a seconda della chiave di partizione.
  • Disponibilità elevata: ogni partizione è un set di repliche, il che significa che replica i dati in più nodi. Questa configurazione garantisce che i dati rimangano disponibili anche se uno o più nodi hanno esito negativo.

Operatore Percona per MongoDB

L'operatore Percona per MongoDB è uno strumento open source sviluppato da Percona . Automatizza la distribuzione, la gestione e il ridimensionamento dei cluster MongoDB all'interno degli ambienti Kubernetes. Semplifica le operazioni gestendo attività come il provisioning, il ridimensionamento, il backup e il ripristino. La gestione di tutte queste attività consente di garantire disponibilità elevata e prestazioni dei cluster MongoDB.

L'operatore usa le definizioni di risorse personalizzate (CRD) di Kubernetes per gestire in modo dichiarativo le configurazioni di MongoDB e per gestire failover, monitoraggio e avvisi. Il risultato è una riduzione del sovraccarico amministrativo e delle procedure di gestione coerenti. L'operatore Percona migliora l'efficienza e l'affidabilità delle distribuzioni MongoDB, in particolare nelle applicazioni native del cloud. È ideale per scenari di sviluppo, test e produzione.

Diagramma che mostra come l'operatore Percona è correlato a un cluster MongoDB.

Panoramica della soluzione MongoDB

L'obiettivo della soluzione proposta è:

  • Assicurarsi che il cluster MongoDB possa gestire in modo efficace set di dati di grandi dimensioni e operazioni a velocità effettiva elevata.
  • Mantenere la disponibilità elevata e la tolleranza di errore.

La soluzione raggiunge questo obiettivo usando set di repliche, regole anti-affinità e allocazione delle risorse appropriata.

Strategia di distribuzione

La strategia di distribuzione mongoDB è costituita dai componenti seguenti:

  • Un cluster partizionato per consentire la distribuzione dei dati tra più partizioni, migliorando la scalabilità e le prestazioni.
  • I server di configurazione gestiti da un set di repliche a tre membri consentono di garantire la tolleranza di errore e la disponibilità elevata. Le regole anti-affinità distribuiscono questi server tra domini di errore.
  • Tre istanze di Mongos distribuite tra zone di disponibilità ed esposte internamente all'interno del cluster. Forniscono il bilanciamento del carico e la resilienza per instradare le richieste client.

Collaboratori

Microsoft gestisce questo articolo. I collaboratori seguenti l'hanno originariamente scritto:

  • Ketan Chawda | Senior Customer Engineer
  • Kharadi nave | Customer Experience Engineer
  • Nelly Kiboi | Tecnico del servizio
  • Saverio Proto | Principal Customer Experience Engineer
  • Don High | Ingegnere Principale del Cliente
  • LaBrina Loving | Ingegnere del servizio principale
  • Ken Kilty | Responsabile TPM
  • Russell de Pina | Responsabile TPM
  • Colin Mixon | Product Manager
  • Erin Schaffer | Sviluppatore di contenuti 2
  • Carol Smith | Sviluppatore di contenuti senior

Passaggio successivo