MongoDB
 sql >> Database >  >> NoSQL >> MongoDB

Distribuzione e configurazione di frammenti MongoDB con Ansible

I sistemi di database funzionano meglio quando è presente un carico di lavoro distribuito tra un numero di istanze in esecuzione o piuttosto i dati sono classificati in modo semplice. MongoDB utilizza lo sharding in modo tale che i dati in un determinato database siano raggruppati in base a una chiave. Lo sharding migliora il ridimensionamento orizzontale che di conseguenza si traduce in prestazioni migliori e maggiore affidabilità. In generale, MongoDB offre il ridimensionamento orizzontale e verticale rispetto a SQL DBMS, ad esempio MySQL, che promuove solo il ridimensionamento verticale.

MongoDB ha un modello di coerenza più ampio in base al quale un documento in una raccolta può avere una chiave aggiuntiva che sarebbe assente da altri documenti nella stessa raccolta.

Sharding

Lo sharding consiste sostanzialmente nel partizionare i dati in blocchi separati e quindi definire un intervallo di blocchi in diversi server shard. Per raggruppare i dati viene utilizzata una chiave shard, che è spesso un campo presente in tutti i documenti del database da dividere. Lo sharding funziona di pari passo con la replica per accelerare il throughput di lettura garantendo un carico di lavoro distribuito tra più server anziché dipendere da un singolo server. Inoltre, la replica garantisce la disponibilità di copie dei dati scritti.

Diciamo che abbiamo 120 documenti in una raccolta, questi dati possono essere frammentati in modo tale da avere 3 set di repliche e ognuno ha 40 documenti come illustrato nella configurazione di seguito. Se due client inviano richieste, uno per recuperare un documento che si trova nell'indice 35 e l'altro il cui indice è a 92, la richiesta viene ricevuta dal router di query (un processo mongos) che a sua volta contatta il nodo di configurazione che conserva un record di come sono distribuiti gli intervalli di blocchi tra i frammenti. Quando viene trovata l'identità del documento specificata, viene recuperata dallo shard associato. Ad esempio sopra, il documento del primo client verrà recuperato dallo shard A e per il client B, il documento verrà recuperato dallo shard C. In generale ci sarà un carico di lavoro distribuito definito come ridimensionamento orizzontale.

Per gli shard specificati, se la dimensione di una raccolta in uno shard supera chunk_size, la raccolta verrà suddivisa e bilanciata automaticamente tra gli shard utilizzando la chiave shard definita. Nella configurazione della distribuzione, per l'esempio seguente avremo bisogno di 3 set di repliche ciascuno con un primario e alcuni secondari. I nodi primari fungono anche da server di partizionamento orizzontale.

La configurazione minima consigliata per una distribuzione di produzione MongoDB sarà di almeno tre server shard, ciascuno con un set di repliche. Per prestazioni ottimali, i server mongos vengono distribuiti su server separati mentre i nodi di configurazione sono integrati con gli shard.

Distribuzione di frammenti MongoDB con Ansible

La configurazione separata di frammenti e set di repliche di un cluster è un'impresa ingombrante, quindi risolviamo strumenti semplici come Ansible per ottenere i risultati richiesti con molta facilità. I playbook vengono utilizzati per scrivere le configurazioni e le attività richieste che il software Ansible eseguirà.

Il processo sistematico del playbook dovrebbe essere:

  1. Installa i pacchetti base di mongo (nessun server, pymongo e interfaccia a riga di comando)
  2. Installa il server mongodb. Segui questa guida per iniziare.
  3. Imposta le istanze mongod e i corrispondenti set di repliche.
  4. Configura e configura i server di configurazione
  5. Configura e imposta il servizio di routing Mongos.
  6. Aggiungi gli shard al tuo cluster.

Il playbook di primo livello dovrebbe assomigliare a questo

- name: install mongo base packages include: mongod.yml
  tags: - mongod

- name: configure config server
  include: configServer.yml
  when: inventory_hostname in groups['mongoc-servers'] 
  tags:
  - cs

- name: configure mongos server
  include: configMongos.yml
  when: inventory_hostname in groups['mongos-server'] tags:
  - mongos

- name: add shards
  include: addShards.yml
  when: inventory_hostname in groups['mongos-servers'] 
  tags:
  - mongos
  - shards

Possiamo salvare il file sopra come mongodbCluster.yml.

Multiplenines Diventa un DBA MongoDB - Portare MongoDB in produzioneScopri cosa devi sapere per distribuire, monitorare, gestire e ridimensionare MongoDBScarica gratuitamente

Un semplice file mongodb.yml sarà simile a:

---
- hosts: ansible-test
  remote_user: root
  become: yes
  tasks:
  - name: Import the public key used by the package management system
    apt_key: keyserver=hkp://keyserver.ubuntu.com:80 id=7F0CEB10 state=present
  - name: Add MongoDB repository
    apt_repository: repo='deb <a class="vglnk" href="https://downloads-distro.mongodb.org/repo/ubuntu-upstart" rel="nofollow"><span>http</span><span>://</span><span>downloads</span><span>-</span><span>distro</span><span>.</span><span>mongodb</span><span>.</span><span>org</span><span>/</span><span>repo</span><span>/</span><span>ubuntu</span><span>-</span><span>upstart</span></a> dist 10gen' state=present
  - name: install mongodb
    apt: pkg=mongodb-org state=latest update_cache=yes
    notify:
    - start mongodb
  handlers:
    - name: start mongodb
      service: name=mongod state=started

Ai parametri generali richiesti nella distribuzione di un set di repliche, abbiamo bisogno di questi due altri per aggiungere gli shard.

  • frammento: per impostazione predefinita è null, questa è una stringa di connessione shard che dovrebbe essere in un formato di /host:port. Ad esempio replica0/siteurl1.com:27017
  • stato: per impostazione predefinita è presente il valore che indica che lo shard dovrebbe essere presente, altrimenti è possibile impostarlo come assente.

Dopo aver distribuito un set di repliche come spiegato in questo blog, puoi procedere con l'aggiunta degli shard.

# add a replicaset shard named replica0 with a member running on port 27017 on mongodb0.example.net
- mongodb_shard:
    login_user: admin
    login_password: root
    shard: "replica0/mongodb1.example.net:27017"
    state: present

# add a standalone mongod shard running on port 27018 of mongodb2.example.net
- mongodb_shard:
    login_user: admin
    login_password: root
    shard: "mongodb2.example.net:27018"
    state: present

# Single node shard running on localhost
- name: Ensure shard replica0 exists
  mongodb_shard:
    login_user: admin
    login_password: root
    shard: "replica0/localhost:3001"
    state: present

# Single node shard running on localhost
- name: Ensure shard replica0 exists
  mongodb_shard:
    login_user: admin
    login_password: root
    shard: "replica0/localhost:3002"
    state: present

Dopo aver impostato tutte queste configurazioni eseguiamo il playbook con il comando

ansible-playbook -i hosts mongodbCluster.yml

Una volta completato il playbook, possiamo accedere a qualsiasi server mongos ed emettere il comando sh.status(). Se l'output è simile al seguente, gli shard sono stati distribuiti. Inoltre puoi vedere la chiave mongodb_shard se è stata valutata con successo.

mongos> sh.status()
    --- Sharding Status --- 
      sharding version: { "_id" : 1, "version" : 3 }
      shards:
        {  "_id" : "shardA",  "host" : "locahhost1/web2:2017,locahhost3:2017" }
        {  "_id" : "shardB",  "host" : "locahhost3/web2:2018,locahhost3:2019" }
{  "_id" : "shardC",  "host" : "locahhost3/web2:2019,locahhost3:2019" }

    databases:
        {  "_id" : "admin",  "partitioned" : false,  "primary" : "config" }

Per rimuovere uno shard chiamato replica0

- mongodb_shard:
    login_user: admin
    login_password: root
    shard: replica0
    state: absent

Conclusione

Ansible ha svolto un ruolo importante nel semplificare il processo di distribuzione poiché abbiamo solo bisogno di definire le attività che devono essere eseguite. Immagina, ad esempio, di avere 40 membri del set di repliche e di dover aggiungere frammenti a ciascuno. Andare per la strada normale ti richiederà anni ed è soggetto a molti errori umani. Con ansible devi semplicemente definire queste attività in un semplice file chiamato playbook e ansible si occuperà delle attività quando il file viene eseguito.