Tweet demo – Infrastruttura

INFRASTRUTTURA

Il cluster su cui è stata realizzata inizialmente la demo è un cluster HDP 2.4.2, istanziato sulla piattaforma cloud Microsoft Azure (in modalità IaaS). Il sistema operativo dei nodi è una distribuzione Linux CentOS 7.2 e i server sono collegati da una singola Virtual Network, ma posizionati in Availability Group differenti a seconda del ruolo.

Questa configurazione, insieme all’alta affidabilità intrinseca di HDFS e YARN, consente di gestire facilmente i downtime relativi a fault delle singole macchine virtuali, o a fermi (schedulati o improvvisi) dovuti a finestre di maintenance sull’architettura cloud.

Per quanto concerne la disponibilità della demo, questa è al momento funzionante solo per la sandbox Hortonworks. Il team Hadoop di Ecube sta lavorando per abilitarne l’utilizzo anche su cluster Hortonworks distribuiti.

ARCHITETTURA HDP

Il cluster è composto dalle seguenti Virtual Machine:

  • 1 manager node – D2v2
  • 2 master node – D3v2
  • 3 slave node – D11v2
  • 3 utility node – D1v2
  • 1 edge node – D11v2

È stato scelto di utilizzare istanze di utility dedicate (su cui eseguire ZooKeeper e il JournalNode di HDFS) per aumentare la stabilità del cluster considerato l’alto utilizzo di tool basati su ZooKeeper, come Apache Kafka o Apache HBase.

Architettura HDP
Architettura HDP

La configurazione utilizzata per Solr è quella distribuita in modalità SolrCloud, con un’istanza sul server master02 e le altre sugli slave. In questo modo è possibile configurare l’accesso alla UI di Solr dalla rete pubblica esclusivamente sul master02 (che quindi funge anche da nodo gateway), negando l’accesso alle altre istanze utilizzando il firewall integrato della piattaforma Microsoft Azure.

Gli altri component dell’architettura Hortonworks Data Platform sono distribuiti in modalità standard, con i DataNode e i NodeManager sugli slave e i due master con i medesimi componenti (fatta eccezione per Solr). In questo modo è possibile gestire la ridondanza sfruttando l’alta affidabilità di HDFS, YARN e utilizzando ZooKeeper per connettersi a HiveServer2.

Per la demo è stato deciso di utilizzare un’unica istanza di Kafka; sebbene questa scelta possa rappresentare un problema in un contesto di produzione (in qualità di SPoF), per l’obbiettivo preposto non rappresenta un impedimento. Infine è stato scelto di utilizzare il nodo edge sia come gateway che come ingestion. In uno scenario reale, generalmente si consiglia l’adozione di almeno due nodi gateway e due nodi ingestion.

ARCHITETTURA HDF

Hortonworks DataFlow è distribuito in modalità cluster sugli stessi nodi su cui è in esecuzione la Hortonworks Data Platform. Mentre in uno scenario reale sarebbe meglio dedicare nodi specifici a NiFi, per gli obiettivi della demo questa scelta risulta funzionale, in quanto il carico di lavoro sugli slave è molto limitato. I worker NiFi, di conseguenza, sono stati installati sui nodi slave del cluster HDP, mentre il manager è stato installato sul nodo su cui è in esecuzione Ambari.

Per abilitare l’alta affidabilità della soluzione, senza replicare il flusso dei dati, il primo processor è stato configurato per essere eseguito solo sul nodo primario HDF e per essere un producer di Kafka. A questo punto, un nuovo flow, in esecuzione su tutti gli slave, legge i messaggi da Kafka. In questo modo il carico di lavoro è distribuito tra tutti i nodi. Il medesimo risultato sarebbe stato ottenuto impiegando istanze differenti di NiFi e utilizzando i remote process group, ma questa soluzione consente di implementare un minor numero di nodi e oltretutto garantirebbe, in caso di necessità, l’utilizzo di altri tool (es: Spark Streaming) per leggere e processare i messaggi direttamente da Kafka.

Architettura HDF
Architettura HDF

AMBARI SERVICE

Per installare e provare la demo, è stato creato un servizio di Ambari che può essere scaricato direttamente dal repository GitHub di Ecube.

Il servizio presuppone l’utilizzo di una Sandbox Hortonworks 2.4, con alcuni servizi già installati e avviati (Kafka, Solr e HDF).

Il servizio è stato scritto seguendo la documentazione di Apache Ambari, ed è organizzato secondo la seguente struttura:

  • tweetsdemo-service
    • xml
    • configuration
      • tweet-env.xml
      • user-env.xml
    • package
      • scripts
        • banana_default.json
        • kiwi_default.json
        • master.py
        • params.py
        • setup_nifi.sh
        • setup_twitter.sh
        • status_params.py
        • stop_twitter.sh
        • twitterAll_confgsets.tgz
        • twitter_dashboard_v5.xml
        • twitterMap_configsets.tgz

METAINFO.XML

Questa è la definizione del servizio. Definisce gli script che sono utilizzati per avviare e fermare il componente dall’interfaccia di Ambari e dichiara i servizi gestiti da Ambari stesso che sono necessari per l’esecuzione della demo, così come i package che devono essere installati sul sistema operativo. Se questi pacchetti non sono già disponibili nell’ambiente, durante la procedura di installazione del servizio verranno automaticamente scaricati utilizzando le utility di sistema operativo (yum, zypper, apt…).

CONFIGURATION DIRECTORY

In questa directory ci sono i file di ambiente che verranno compilati con le configurazioni fatte sull’interfaccia di Ambari. Il file user-env è un file in cui è specificata la directory di installazione del servizio (default in /opt) e la directory in cui verrà scritto il file PID. Il file tweet-env verrà compilato con i parametri necessari per accedere alle API di Twitter.

PACKAGE / SCRIPTS DIRECTORY

In questa directory sono presenti gli script necessari all’esecuzione del servizio. Il file principale è master.py, che è il file richiamato nella sezione “commandScript” del file metainfo.xml.

Lo script master.py necessita della dichiarazione di almeno cinque funzioni:

  • install
  • configure
  • start
  • stop
  • status

La procedura di installazione è quella utilizzata dallo script per creare la directory di installazione, così come specificata nel file user-env, e per copiare al suo interno gli script necessari. Vengono inoltre create le directory su HDFS e la configurazione di Solr, con le relative collection e le UI per Kiwi e Banana (utilizzando i file tgz e JSON presenti nella directory stessa).

La funzione configure è utilizzata per sovrascrivere i file d’ambiente, in base alle configurazioni che l’utente ha effettuato su Ambari.

La procedura di start per prima cosa installa il pacchetto pyton “requests”, utilizzando l’utility python-pip (se questa libreria non è già installata), dopodiché esegue due script bash: il primo è lo script setup_nifi.sh, che verifica su HDF se il process group chiamato “twitter_dashboard” è presente. Se esiste, esce con exit code 0. Se il process group non esiste, lo script lo crea importando il template NiFi e istanziandolo. Inoltre salva l’ID del process group nel file PID. Infine avvia l’intero process group.

La funzione status legge l’ID del process group dal file PID e si connette alle API NiFi per verificare il numero di processor in esecuzione nel process group. Se il numero è inferiore a 26 (numero complessivo di elementi), la procedura scatena un’eccezione di tipo ComponentIsNotRunning() e Ambari imposterà il servizio come “Stopped” (è necessario che tutti i processor siano in esecuzione affinché la demo funzioni correttamente).

Infine, la funzione di stop, si connette alle API NiFi e ferma i processor all’interno del process group, sempre riferendosi ad esso tramite l’ID letto dal PID file. Inoltre, la procedura cancella il PID file, in questo modo vengono eliminati tutti i riferimenti al process group, fino a quando un utente non riavvia la demo direttamente da Ambari.

Add a Comment

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *