\u00c8 necessario un monitoraggio aggiuntivo del failover; abbiamo 12 shard PostgreSQL, quindi dobbiamo monitorare 12 cluster. Aumentando il numero di shard, non dimentichiamo di aggiornare il failover.<\/li>\n<\/ul>\nUn failover personalizzato sembra molto complesso e richiede manutenzione non banale. Con un solo cluster PostgreSQL, sarebbe l'opzione pi\u00f9 semplice, ma non \u00e8 scalabile, quindi non \u00e8 adatta a noi.<\/p>\n
Repmgr<\/h3>\n Replication Manager per cluster PostgreSQL, che gestisce il funzionamento del cluster PostgreSQL. Tuttavia, non dispone di failover automatico \u201cdi serie\u201d, quindi sar\u00e0 necessario scrivere un proprio \u201cwrapper\u201d sopra la soluzione esistente. Quindi, potrebbe risultare anche pi\u00f9 complesso rispetto a script scritti da zero, motivo per cui non abbiamo nemmeno provato Repmgr.<\/p>\n
AWS RDS<\/h3>\n Supporta tutto il necessario per noi, \u00e8 in grado di fare backup e gestisce un pool di connessioni. Ha uno switch automatico: alla morte del master, la replica diventa il nuovo master, e AWS cambia il record DNS al nuovo master, mentre le repliche possono trovarsi in diverse AZ.<\/p>\n
Tra i lati negativi si pu\u00f2 citare l'assenza di impostazioni dettagliate. Ad esempio, impostazioni dettagliate: sulle nostre istanze ci sono limitazioni per le connessioni TCP, cosa che purtroppo non possiamo fare in RDS:<\/p>\n
net.ipv4.tcp_keepalive_time=10\nnet.ipv4.tcp_keepalive_intvl=1\nnet.ipv4.tcp_keepalive_probes=5\nnet.ipv4.tcp_retries2=3\n<\/code><\/pre>\nInoltre, il prezzo di AWS RDS \u00e8 quasi il doppio del prezzo normale delle istanze, che \u00e8 stata la principale causa del rifiuto di questa soluzione.<\/p>\n
Patroni<\/h3>\n \u00c8 un template in Python per gestire PostgreSQL con una buona documentazione, failover automatico e codice sorgente su GitHub.<\/p>\n
Vantaggi di Patroni:<\/p>\n
\nOgni parametro di configurazione \u00e8 dettagliato, rendendo chiaro come funziona ogni parte.<\/li>\n Il failover automatico funziona out-of-the-box.<\/li>\n Scritto in Python, e poich\u00e9 anche noi scriviamo molto in Python, sar\u00e0 pi\u00f9 facile risolvere problemi e, forse, anche aiutare lo sviluppo del progetto.<\/li>\n Gestisce completamente PostgreSQL, permette di modificare la configurazione su tutti i nodi del cluster e, se \u00e8 necessario riavviare il cluster per applicare la nuova configurazione, questo pu\u00f2 essere fatto ancora con Patroni.<\/li>\n<\/ul>\nContro:<\/p>\n
\nDalla documentazione non \u00e8 chiaro come lavorare correttamente con PgBouncer. Sebbene non sia facile definire questo un difetto, perch\u00e9 il compito di Patroni \u00e8 gestire PostgreSQL, mentre gestire come avvengono le connessioni a Patroni \u00e8 gi\u00e0 un nostro problema.<\/li>\n Ci sono pochi esempi di implementazione di Patroni su larga scala, mentre ci sono molti esempi di implementazione da zero.<\/li>\n<\/ul>\nIn definitiva, per creare un cluster ad alta disponibilit\u00e0 abbiamo scelto proprio Patroni.<\/p>\n
Il processo di implementazione di Patroni.<\/h2>\n Prima di Patroni avevamo 12 shard di PostgreSQL in una configurazione con un master e una replica con replica asincrona. I server delle applicazioni si collegavano ai database tramite un Network Load Balancer, dietro al quale c'erano due istanze con PgBouncer, e dietro di essi si trovavano tutti i server PostgreSQL.
Per implementare Patroni, abbiamo dovuto scegliere uno storage distribuito per la configurazione del cluster. Patroni funziona con sistemi distribuiti di storage della configurazione, come etcd, Zookeeper e Consul. Abbiamo infatti un cluster Consul completamente operativo in produzione, che lavora in sinergia con Vault e non lo utilizziamo in altro modo. \u00c8 un'ottima occasione per iniziare a usare Consul come previsto.<\/p>\n
Come funziona Patroni con Consul<\/h3>\n Abbiamo un cluster Consul composto da tre nodi e un cluster Patroni, costituito da un leader e da repliche (in Patroni, il master \u00e8 chiamato leader del cluster e gli slave sono repliche). Ogni istanza del cluster Patroni invia continuamente a Consul informazioni sullo stato del cluster. Pertanto, da Consul \u00e8 sempre possibile conoscere la configurazione attuale del cluster Patroni e chi \u00e8 il leader in quel momento.<\/p>\n
Per connettere Patroni a Consul, \u00e8 sufficiente consultare la documentazione ufficiale, che specifica che \u00e8 necessario indicare l'host nel formato http o https a seconda di come lavoriamo con Consul, e lo schema di connessione, opzionalmente:<\/p>\n
host: l'host:port per il punto finale di Consul, nel formato: http(s):\/\/host:port\nschema: (opzionale) http o https, predefinito a http<\/code><\/pre>\nSembra semplice, ma qui iniziano le insidie. Con Consul lavoriamo tramite una connessione sicura https e la nostra configurazione di connessione sar\u00e0 simile a questa:<\/p>\n
consul:\n host: https:\/\/server.production.consul:8080 \n verify: true\n cacert: {{ consul_cacert }}\n cert: {{ consul_cert }}\n key: {{ consul_key }}<\/code><\/pre>\nMa cos\u00ec non funziona. All'avvio, Patroni non riesce a connettersi a Consul perch\u00e9 continua a tentare di utilizzare http.<\/p>\n
Comprendere il problema \u00e8 stato possibile grazie al codice sorgente di Patroni. \u00c8 un bene che sia scritto in Python. Risulta che il parametro host non venga elaborato e il protocollo debba essere specificato in scheme. Ecco come appare un blocco di configurazione funzionante per l'uso con Consul:<\/p>\n
consul:\n host: server.production.consul:8080\n scheme: https\n verify: true\n cacert: {{ consul_cacert }}\n cert: {{ consul_cert }}\n key: {{ consul_key }}<\/code><\/pre>\nConsul-template<\/h3>\n Quindi, abbiamo scelto un archivio per la configurazione. Ora \u00e8 necessario capire come PgBouncer cambier\u00e0 la sua configurazione al cambiamento del leader nel cluster di Patroni. Nella documentazione non c'\u00e8 una risposta a questa domanda, poich\u00e9 in generale non viene descritta l'interazione con PgBouncer.<\/p>\n
Nella ricerca di una soluzione, abbiamo trovato un articolo (purtroppo non ricordo il titolo) che affermava che Consul-template fosse molto utile nell'integrazione tra PgBouncer e Patroni. Questo ci ha spinto ad esplorare il funzionamento di Consul-template.<\/p>\n
Si \u00e8 scoperto che il Consul-template monitora continuamente la configurazione del cluster PostgreSQL su Consul. Quando cambia il leader, aggiorna la configurazione di PgBouncer e invia il comando per il suo riavvio.<\/p>\n
Un grande vantaggio del template \u00e8 che \u00e8 memorizzato come codice, quindi quando si aggiunge un nuovo shard, \u00e8 sufficiente effettuare un nuovo commit e aggiornare automaticamente il template, mantenendo il principio dell'infrastruttura come codice.<\/p>\n
Nuova architettura con Patroni<\/h3>\n Di conseguenza, abbiamo ottenuto questo schema di lavoro:
Tutti i server dell'applicazione si collegano al bilanciatore \u2192 dietro di esso ci sono due istanze di PgBouncer \u2192 in ogni istanza \u00e8 in esecuzione Consul-template, che monitora lo stato di ogni cluster Patroni e verifica la validit\u00e0 della configurazione di PgBouncer, che indirizza le richieste al leader attuale di ogni cluster.<\/p>\n
Test manuale<\/h3>\n Prima di passare alla produzione, abbiamo eseguito questo schema in un piccolo ambiente di test e abbiamo verificato il funzionamento del passaggio automatico. Abbiamo aperto la bacheca, spostato un adesivo e in quel momento 'abbiamo ucciso' il leader del cluster. In AWS, per fare questo, \u00e8 sufficiente spegnere l'istanza tramite la console.<\/p>\n
L'adesivo tornava indietro per 10-20 secondi e poi iniziava a muoversi normalmente. Questo significa che il cluster Patroni ha funzionato correttamente: ha cambiato leader, ha inviato informazioni a Consul, e il template Consul ha subito acquisito queste informazioni, aggiornando la configurazione di PgBouncer e inviando il comando di reload.<\/p>\n
Come sopravvivere a carichi elevati e mantenere un downtime minimo?<\/h2>\n Tutto funziona alla grande! Ma sorgono nuove domande: come funzioner\u00e0 sotto carico elevato? Come distribuire tutto in produzione in modo rapido e sicuro?<\/p>\n
Per rispondere alla prima domanda, ci aiuta un ambiente di test in cui eseguiamo test di carico. \u00c8 completamente identico alla produzione per architettura e dispone di dati di test generati, che hanno un volume approssimativamente uguale alla produzione. Decidiamo semplicemente di 'uccidere' uno dei master PostgreSQL durante il test e vedere cosa succede. Ma prima \u00e8 importante verificare il rollout automatico, poich\u00e9 in questo ambiente abbiamo diversi shard PostgreSQL, quindi avremo un ottimo test degli script di configurazione prima della produzione.<\/p>\n
Entrambi i compiti sembrano ambiziosi, ma abbiamo PostgreSQL 9.6. Forse aggiorniamo subito alla 11.2?<\/p>\n
Ci proponiamo di farlo in 2 fasi: prima aggiornare la versione a 11.2, poi avviare Patroni.<\/p>\n
Aggiornamento di PostgreSQL<\/h3>\n Per un aggiornamento rapido della versione di PostgreSQL \u00e8 necessario utilizzare l\u2019opzione -k<\/b>, che crea hard link sul disco ed elimina la necessit\u00e0 di copiare i tuoi dati. Su database da 300-400 GB, l'aggiornamento richiede 1 secondo.<\/p>\n
Abbiamo molti shard, quindi l'aggiornamento deve essere fatto in modo automatico. A tal fine, abbiamo scritto un playbook Ansible che esegue l'intero processo di aggiornamento per noi:<\/p>\n
\/usr\/lib\/postgresql\/11\/bin\/pg_upgrade \n<b>--link <\/b>\n--old-datadir='' --new-datadir='' \n --old-bindir='' --new-bindir='' \n --old-options=' -c config_file=' \n --new-options=' -c config_file='<\/code><\/pre>\n\u00c8 importante notare che prima di avviare l'aggiornamento, \u00e8 necessario eseguirlo con il parametro —check<\/b>, per essere certi della possibilit\u00e0 di aggiornamento. Inoltre, il nostro script fa il cambio delle configurazioni durante l'aggiornamento. Il nostro script \u00e8 stato eseguito in 30 secondi, un ottimo risultato.<\/p>\nAvvio di Patroni<\/h3>\n
Per risolvere il secondo problema, basta dare un'occhiata alla configurazione di Patroni. Nel repository ufficiale c'\u00e8 un esempio di configurazione con initdb, che si occupa di inizializzare un nuovo database al primo avvio di Patroni. Ma poich\u00e9 abbiamo gi\u00e0 un database pronto, abbiamo semplicemente rimosso questa sezione dalla configurazione.<\/p>\n
Quando abbiamo iniziato a installare Patroni su un cluster PostgreSQL esistente e ad avviarlo, ci siamo imbattuti in un nuovo problema: entrambi i server si avviavano come leader. Patroni non conosce lo stato precedente del cluster e cerca di avviare entrambi i server come due cluster separati con lo stesso nome. Per risolvere questo problema, \u00e8 necessario eliminare la directory dei dati sul server secondario:<\/p>\n
rm -rf \/var\/lib\/postgresql\/<\/code><\/pre>\nQuesto deve essere fatto solo sul server secondario!<\/b><\/p>\n
Quando si connette una replica pulita, Patroni esegue il basebackup del leader e lo ripristina sulla replica, quindi recupera lo stato attuale attraverso i log WAL.<\/p>\n
Un'altra difficolt\u00e0 che abbiamo incontrato \u00e8 che tutti i cluster PostgreSQL sono chiamati main per impostazione predefinita. Quando ogni cluster non sa nulla dell'altro, va bene. Ma quando si desidera utilizzare Patroni, tutti i cluster devono avere un nome unico. La soluzione \u00e8 cambiare il nome del cluster nella configurazione di PostgreSQL.<\/p>\n
Test di carico<\/h3>\n Abbiamo avviato un test che simula l'attivit\u00e0 degli utenti sui server. Quando il carico ha raggiunto la nostra media giornaliera, abbiamo ripetuto esattamente lo stesso test, disattivando un'istanza con leader PostgreSQL. Il failover automatico ha funzionato come previsto: Patroni ha cambiato leader, Consul-template ha aggiornato la configurazione di PgBouncer e ha inviato il comando per il reload. Dai nostri grafici in Grafana si vedeva che c'erano ritardi di 20-30 secondi e un piccolo numero di errori dai server, legati alla connessione al database. Questa \u00e8 una situazione normale, tali valori sono accettabili per il nostro failover e sono sicuramente migliori di un downtime del servizio.<\/p>\n
Output di Patroni in produzione<\/h2>\n Alla fine, abbiamo ottenuto il seguente piano:<\/p>\n
\nDeployment di Consul-template sui server PgBouncer e avvio;<\/li>\n Aggiornamenti di PostgreSQL alla versione 11.2;<\/li>\n Cambio del nome del cluster;<\/li>\n Avvio del cluster Patroni.<\/li>\n<\/ul>\nIn questo modo, il nostro schema consente di eseguire il primo punto praticamente in qualsiasi momento, possiamo rimuovere ogni PgBouncer a turno e procedere con il deployment e l'avvio di consul-template. E cos\u00ec abbiamo fatto.<\/p>\n
Per una rapida implementazione, abbiamo utilizzato Ansible, poich\u00e9 avevamo gi\u00e0 testato tutti i playbook in un ambiente di test, e il tempo di esecuzione dell'intero scenario variava da 1,5 a 2 minuti per ogni shard. Avevamo la possibilit\u00e0 di rilasciarli uno dopo l'altro per ogni shard senza interrompere il nostro servizio, ma avremmo dovuto spegnere brevemente ciascun PostgreSQL. In tal caso, gli utenti i cui dati erano su quel shard non sarebbero stati in grado di lavorare correttamente in quel momento, il che \u00e8 inaccettabile per noi.<\/p>\n
La soluzione a questa situazione \u00e8 stata una manutenzione programmata, che si tiene ogni 3 mesi. Questo \u00e8 un intervallo per lavori pianificati, durante il quale spegniamo completamente il nostro servizio e aggiorniamo le istanze dei database. Una settimana prima della prossima finestra, abbiamo deciso di aspettare e prepararci ulteriormente. Durante il periodo di attesa, abbiamo preso ulteriori precauzioni: per ogni shard PostgreSQL abbiamo attivato una replica di backup in caso di guasti, per mantenere i dati pi\u00f9 recenti, e abbiamo aggiunto una nuova istanza per ciascuno shard, che diventer\u00e0 la nuova replica nel cluster Patroni, evitando cos\u00ec di eseguire il comando per eliminare i dati. Tutto ci\u00f2 ha contribuito a ridurre al minimo il rischio di errore.
Abbiamo riavviato il nostro servizio, tutto ha funzionato come previsto, gli utenti hanno continuato a lavorare, ma nei grafici abbiamo notato un carico anomalo sui server Consul.
Perch\u00e9 non abbiamo visto questo nell'ambiente di test? Questo problema illustra chiaramente la necessit\u00e0 di seguire il principio di Infrastructure as code e di migliorare tutta l'infrastruttura, partendo dagli ambienti di test fino alla produzione. Altrimenti, \u00e8 molto facile imbattersi in un problema come quello che abbiamo avuto. Cosa \u00e8 successo? Consul \u00e8 stato inizialmente implementato in produzione e poi negli ambienti di test; alla fine, la versione di Consul negli ambienti di test era superiore a quella in produzione. Proprio in uno degli aggiornamenti \u00e8 stata risolta una perdita di CPU durante l'uso di consul-template. Pertanto, abbiamo semplicemente aggiornato Consul, risolvendo cos\u00ec il problema.<\/p>\n
Riavviare il cluster Patroni<\/h3>\n Tuttavia, abbiamo riscontrato un nuovo problema di cui non sospettavamo nemmeno. Durante l'aggiornamento di Consul, rimuoviamo semplicemente il nodo Consul dal cluster con il comando consul leave \u2192 Patroni si collega a un altro server Consul \u2192 tutto funziona. Ma quando siamo arrivati all'ultimo nodo del cluster Consul e abbiamo inviato il comando consul leave, tutti i cluster Patroni si sono semplicemente riavviati e nei log abbiamo visto il seguente errore:<\/p>\n
ERRORE: get_cluster\nTraccia (chiamata più recente in alto):\n...\nRetryFailedError: 'Scadenza di ripetizione superata'\nERRORE: Errore nella comunicazione con DCS\n<b>LOG: il sistema del database è stato chiuso<\/b><\/code><\/pre>\nIl cluster Patroni non \u00e8 riuscito a ottenere informazioni sul proprio cluster ed \u00e8 stato riavviato.<\/p>\n
Per cercare una soluzione, ci siamo rivolti agli autori di Patroni tramite issue su GitHub. Hanno suggerito di migliorare i nostri file di configurazione:<\/p>\n
consul:\n consul.checks: []\nbootstrap:\n dcs:\n retry_timeout: 8<\/code><\/pre>\nSiamo riusciti a riprodurre il problema in un ambiente di test e abbiamo testato questi parametri, ma, sfortunatamente, non hanno funzionato.<\/p>\n
Il problema rimane irrisolto. Prevediamo di provare le seguenti opzioni per risolverlo:<\/p>\n
\nUtilizzare il Consul-agent su ogni istanza del cluster Patroni;<\/li>\n Correggere il problema nel codice.<\/li>\n<\/ul>\nCi \u00e8 chiaro il luogo di provenienza dell'errore: probabilmente, il problema \u00e8 nell'uso del timeout predefinito, che non viene sovrascritto dal file di configurazione. Quando si rimuove l'ultimo server Consul dal cluster, si verifica un blocco dell'intero cluster Consul, che dura pi\u00f9 di un secondo, impedendo cos\u00ec a Patroni di ottenere lo stato del cluster e costringendo il riavvio completo dell'intero cluster.<\/p>\n
Fortunatamente, non abbiamo riscontrato ulteriori errori.<\/p>\n
Sintesi dell'utilizzo di Patroni<\/h2>\n Dopo il successo del lancio di Patroni, abbiamo aggiunto un'ulteriore replica in ogni cluster. Ora, in ogni cluster esiste una sorta di quorum: un leader e due repliche, per una maggiore sicurezza in caso di split-brain durante il failover.
In produzione, Patroni \u00e8 attivo da oltre tre mesi. Durante questo periodo, ci ha gi\u00e0 salvati. Recentemente, in AWS, il leader di uno dei cluster \u00e8 andato offline, il failover automatico ha funzionato e gli utenti hanno potuto continuare a lavorare. Patroni ha svolto il suo compito principale.<\/p>\n
Un breve riepilogo dell'utilizzo di Patroni:<\/b><\/p>\n\nComodit\u00e0 nel cambiare la configurazione. \u00c8 sufficiente modificare la configurazione su un'istanza e questa si propagher\u00e0 a tutto il cluster. Se \u00e8 necessario un riavvio per applicare la nuova configurazione, Patroni lo segnaler\u00e0. Patroni pu\u00f2 riavviare l'intero cluster con un solo comando, il che \u00e8 molto comodo.<\/li>\n Il failover automatico funziona e ci ha gi\u00e0 salvati.<\/li>\n Aggiornamento di PostgreSQL senza downtime per l'applicazione. \u00c8 necessario aggiornare prima le repliche alla nuova versione, poi cambiare il leader nel cluster Patroni e aggiornare il vecchio leader. Durante questo procedimento, avviene il necessario test del failover automatico.<\/li>\n<\/ul>\nFonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0412 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u043a\u0430\u043a \u043c\u044b \u043f\u043e\u0434\u043e\u0448\u043b\u0438 \u043a \u0432\u043e\u043f\u0440\u043e\u0441\u0443 \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438 PostgreSQL, \u043f\u043e\u0447\u0435\u043c\u0443 \u044d\u0442\u043e \u0441\u0442\u0430\u043b\u043e \u0434\u043b\u044f \u043d\u0430\u0441 \u0432\u0430\u0436\u043d\u043e \u0438 \u0447\u0442\u043e \u0432 \u0438\u0442\u043e\u0433\u0435 \u043f\u043e\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c. \u0423 \u043d\u0430\u0441 \u0432\u044b\u0441\u043e\u043a\u043e\u043d\u0430\u0433\u0440\u0443\u0436\u0435\u043d\u043d\u044b\u0439 \u0441\u0435\u0440\u0432\u0438\u0441: 2,5 \u043c\u043b\u043d \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u043f\u043e \u0432\u0441\u0435\u043c\u0443 \u043c\u0438\u0440\u0443, 50\u041a+ \u0430\u043a\u0442\u0438\u0432\u043d\u044b\u0445 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u043a\u0430\u0436\u0434\u044b\u0439 \u0434\u0435\u043d\u044c. \u0421\u0435\u0440\u0432\u0435\u0440\u0430 \u043d\u0430\u0445\u043e\u0434\u044f\u0442\u0441\u044f \u0432 Amazone \u0432 \u043e\u0434\u043d\u043e\u043c \u0440\u0435\u0433\u0438\u043e\u043d\u0435 \u0418\u0440\u043b\u0430\u043d\u0434\u0438\u0438: \u0432 \u0440\u0430\u0431\u043e\u0442\u0435 \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u043e 100+ \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0445 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432, \u0438\u0437 \u043d\u0438\u0445 \u043f\u043e\u0447\u0442\u0438 50 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26749,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35706","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Cluster](\"\/wp-content\/uploads\/2019\/06\/443f85815b0560fade7db5b639942935.png\")
![\"Cluster](\"\/wp-content\/uploads\/2019\/06\/674dd77de4c8b48a946c9f64c0b2fdd1.png\")
<\/p>\n![\"Cluster](\"\/wp-content\/uploads\/2019\/06\/dabcb7f6006520c4fec85fb925e8975e.png\")
<\/p>\n![\"Cluster](\"\/wp-content\/uploads\/2019\/06\/2c1f1e7d9f7be4fdeb43858520d55e36.png\")
<\/p>\n![\"Cluster](\"\/wp-content\/uploads\/2019\/06\/8e5350d2466311593e11add30d5b1bdc.png\")
<\/p>\n![\"Cluster](\"\/wp-content\/uploads\/2019\/06\/3234594b363904424fdce64c9d77fca5.png\")
<\/p>\n![\"Cluster](\"\/wp-content\/uploads\/2019\/06\/6cf92996a127bb6637ab81dc45fdd60a.png\")
<\/p>\n![\"Cluster](\"\/wp-content\/uploads\/2019\/06\/bf9a9eff675a26039e3f76b16c6cd713.png\")
<\/p>\n![\"Cluster](\"\/wp-content\/uploads\/2019\/06\/d670fe373b774f1b52bfd8a8c3b53a21.png\")
<\/p>\n![\"Cluster](\"\/wp-content\/uploads\/2019\/06\/29e5c5f50dbfebfe5665fa0aeb009728.png\")
<\/p>\n![\"Cluster](\"\/wp-content\/uploads\/2019\/06\/af0eef9ac235706c0aac62d2e1ee179d.png\")
<\/p>\n![\"Cluster](\"\/wp-content\/uploads\/2019\/06\/3bb4c0495fea274b04edd2e99b59eacb.png\")
<\/p>\n