AWS News KW 33

In der letzten Woche war der AWS Summit in New York. Auf dem Event wurden viele Neuerungen bekannt gegeben und daher ist diese Woche mehr zu berichten als die beiden vorangegangenen Wochen.

AWS Macie

Mit AWS Macie hat Amazon einen sehr interessanten neuen Service gestartet. Macie kann dabei helfen unberechtigten Zugang zu vertraulichen S3 Daten zu erkennen und zu verhindern.

AWS Macie analysiert und klassifiziert in S3 gespeicherte Daten. Mit Hilfe von Maschine Learning Algorithmen werden die Zugriffe auf diese Daten analysiert, so das bei Anomalien im Zugriffsverhalten Alarm geschlagen werden kann.

Weitere Informationen zu AWS Macie hier.

AWS Migration Hub

Für die Migration von Services in die Cloud können die Dienste AWS Application Discovery Service, AWS Server Migration Service und AWS Database Migration Service den Nutzer unterstützen.

Mit AWS Migration Hub steht ab sofort eine einheitliche Oberfläche für diese Tools sowie Migrationstools von Partnern bereit.  Für die Nutzung von AWS Migration Hub fallen keine Zusätzlichen Kosten an. Es muss lediglich die Nutzung der verwendeten Services bezahlt werden.AWS-Migration_hub_Dashboard.png

Weitere Informationen zu AWS Migration Hub hier.

Neue Regeln für AWS Config

Mit Hilfe von AWS Config werden alle Resourcekonfigurationen überwacht. Neben weiteren Funktionen bietet AWS Config die Möglichkeit Änderungen an Konfigurationen historisch zu betrachten. Mit AWS Config Rules können Resourcen auf die Einhaltung definierter Regeln überprüft werden. Neben eigenen Regeln existieren auch „gemanagte“ Regeln. Ab sofort stehen zwei neue Regeln für S3 bereit.

s3-bucket-public-write-prohibited: Markiert alle Buckets die globale öffentliche Schreibrechte aktiviert wurden.

s3-bucket-public-read-prohibited: Markiert alle Buckets die für jeden lesbar sind.

Weitere Informationen zu managed AWS Config Rules hier.

AWS CloudTrail automatisch aktiviert für alle AWS Nutzer

Mit AWS CloudTrail können alle Aktivitäten eines Accounts bis zu 7 Tage in der Vergangenheit betrachtet und analysiert werden.

Ab sofort ist der Dienst für alle Nutzer verfügbar und per default aktiviert.

Weitere Informationen zu AWS CloudTrail hier.

AWS CloudHSM Update

AWS CloudHSM bietet hardware-based Key Management in der Cloud. Mit dem Update wurde die Verwendung an vielen Punkten vereinfacht. Die wichtigsten Punkten sind der Wechsel zum Pay as you Go Model und der Übergang zu einen fully managed Service.

Weitere Informationen zu AWS CloudHSM hier.

AWS Glue

Glue ist ein fully managed extract transform load (ETL) Service. Glue ist serverless, so das sich der Anwender nicht um die Skalierung kümmern muss und Kosten nur dann entstehen wenn der ETL Job wirklich läuft.

Weitere Informationen zu AWS Glue hier.

Encryption at Rest für EFS

Amazon Elastic File System (Amazon EFS) stellt einen einfachen, skalierbaren Dateispeicher für Amazon EC2-Instanzen in der AWS Cloud bereit.

Mit Encryption at Rest können jetzt Daten vollkommen transparent und mit minimalen Auswirkungen auf die Performance verschlüsselt werden. Der Schlüssel kann entweder von Amazon erzeugt werden oder er wird vom Anwender bereitgestellt.

Weitere Informationen zu EFS hier.

VPC Endpoints für Amazon DynamoDB

Um aus einem VPC heraus den managed Service Amazon DynamoDB nutzen zu können, war es bisher notwendig den Umweg über das Internet zu wählen. Mit Blick auf Security Belange sowie Performance ist dieser Weg nicht optimal.

Ab sofort ist es möglich einen Endpoint für ein VPC zu definieren, so das Ressourcen innerhalb des VPC DynamoDB ohne Umweg über das Internet nutzen können.

Weitere Informationen zu VPC Endpoints für Amazon DynamoDB hier.

SES Dedicated IP Pool

Die meisten Benutzer von Amazon Simple Email Service (SES) werden das shared IP Konzept beim versenden Ihrer E-Mails nutzen. Übersteigt das Mailaufkommen einen bestimmten Wert, lohnt sich der Einsatz einer dedizierten IP. Die Verwaltung mehrere dedizierter IP´s wird durch die Dedicated IP Pool´s vereinfacht.

Weitere Informationen zu Dedicated IP Pool´s hier.

 

 

Veröffentlicht unter Cloud & Infrastructure | Verschlagwortet mit , , , , , | Kommentar hinterlassen

Die OC DevOps Community startet durch

DevOps intensiviert die Schaffung einer Kultur und die Etablierung von Prinzipien zur kontinuierlichen Verbesserung der ganzheitlichen Leistung. Es umfasst viele Praktiken angefangen von CI/CD, Konfigurationsmanagement, Compliance-Einbindung und Infrastructure-as-Code über die Optimierung des Arbeitsflusses bis hin zur Fokussierung auf einen effizienten ROI.

Dabei experimentieren Teams in kurzen Feedbackzyklen, unterstützt durch einen hoch performanten Auslieferungsstrang zur Verbesserung des Endprodukts. Eine weitere Besonderheit ist die Kontinuität, mit der nachhaltig der Fortschritt beibehalten wird.

Devops-toolchain

Phasen einer DevOps Toolchain (By Kharnagy – Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=51215412)

Um solch eine Transformation in Unternehmen zu forcieren, muss ein entsprechendes Mindset entwickelt und ein zugeschnittenes Toolset aufgebaut werden. So muss auch das Umdenken von getrennten Aufgabenbereichen hin zu Teams mit gemeinsamen Produktzielen stattfinden.

Die methodischen Ansätze sowie die Toollandschaft sind enorm und entwickeln sich rasch voran. Hierfür sind das Verständnis in der Breite und die Expertise in der Tiefe von essenzieller Bedeutung. Um unsere Kunden bei der DevOps Transformation zu unterstützen und zeitgleich die Kompetenz kontinuierlich zu verbessern, haben wir die OC DevOps Community gegründet, in dem Kollegen aus allen Niederlassungen in regelmäßigen Abständen sich austauschen und gemeinsam neues Wissen erarbeiten.

Sie können uns direkt unter der Mailadresse devops@opitz-consulting.com kontaktieren oder über unsere Website http://www.opitz-consulting.com den Kontakt herstellen.

Wir freuen uns auf die Zusammenarbeit!

Die OC DevOps Community

Veröffentlicht unter Cloud & Infrastructure, Strategy & Methods | Verschlagwortet mit , , , | Kommentar hinterlassen

AWS News KW 32

Genau wie letzte Woche gibt es diese Woche nur eine wichtige Meldung von AWS, die ist dafür aber um so interessanter.

AWS SAM Local

Vor einen Jahr veröffentlichte Amazon das Serverless Application Model (SAM) um Entwicklern das Deployment von Serverless Anwendungen per Cloudformation zu erleichtern.

aws_sam_introduction-1024x286

SAM local erlaubt es nun die entsprechenden Templates vor dem deployment lokal zu testen. Besonders spannend ist dabei die Möglichkeit Lambda Funktionen ebenfalls lokal aufzurufen und damit zu testen und zu debuggen. Werden von den Lambda Funktionen lediglich AWS Services angesprochen, die ebenfalls lokal gestartet werden können z.B. DynamoDB ist für das Testen nichmal eine Internetverbindung notwendig.

Weitere Informationen zu AWS SAM Local hier.

Veröffentlicht unter Cloud & Infrastructure | Verschlagwortet mit , , | Kommentar hinterlassen

High Availability und Big Data – Simples Einrichten einer hochverfügbaren HDFS Umgebung

 

Hochverfügbarkeit ist ein unterschätztes und leider häufig vernachlässigtes Thema. Auch eine Big-Data-Distribution, in der per se eine Datenreplikation auf einzelne DataNodes eingeschaltet ist, sollte hier miteinbezogen und hochverfügbar konfiguriert werden. Es reicht nicht aus, nur die Replikation der DataNodes zu benutzen, sondern die High-Availability-Funktion kann zusätzlich aktiviert werden. Denn sollte der zentrale NameNode ausfallen, ist ein Zugriff auf die im Hadoop Distributed File System (HDFS) zugrunde liegenden Daten nicht mehr möglich. Nicht alle Services können aktuell mit Hochverfügbarkeit konfiguriert werden, aber für einen Großteil ist dies durchaus möglich. So auch für die extrem wichtige Komponente HDFS.

 

Anhand einer Beispielkonfiguration in einem Cloudera Cluster Stack werden die Aufgaben von NameNode, Standby NameNode oder Secondary NameNode verdeutlicht und es wird mit wenigen Mausklicks eine High-Availability-Konfiguration für den HDFS Service ausgerollt. Der mitinstallierte Secondary NameNode bietet keine Hochverfügbarkeit. Dieser wird als eine Art Unterstützer („Helper“) angesehen, der sich um zeitliche Checkpoints der Metadaten kümmert und für das Verknüpfen von „editlogs“ mit dem „fsimage“ verantwortlich ist. Dies ermöglicht einen schnelleren Restart des NameNodes.

 

Der NameNode, der die Metadaten des HDFS Clusters hält, wird durch einen zusätzlichen Standby NameNode abgesichert. Es ist dann nicht möglich, einen Secondary NameNode zu benutzen. Andere Aufgaben des NameNodes sind es, die Replikationen bzw. Kopien der Dateien zu überwachen. Sollte eine Kopie beschädigt werden, sorgt dieser für eine erneute Replikation auf den einzelnen DataNodes. In Hadoop Version 2 ist der „Singlepoint of Failure“ des NameNodes nicht mehr vorhanden wie in Version 1. Im „Worst Case“-Scenario übernimmt der Standby NameNode die primäre Aufgabe des ausgefallenen NameNodes.

In diesem Active/Passiv-Szenario wird schnell und automatisch über einen vorher definierten Service mit minimaler Downtime umgeschaltet.

Erreicht wird dies durch den Hochverfügbarkeitsdienst Zookeeper, der Ausfälle registriert und entsprechende Maßnahmen ergreift. Dabei wird anhand von zwei Wegen unterschieden, ob dieser über das „Quorum Journal“-basierte System oder per „Shared NFS Storage“ eingerichtet wird. Cloudera nutzt standardmäßig ersteres. Hierdurch bleibt der NameNode und Standby NameNode durch eine separate Gruppe von JournalNodes synchronisiert.

 

Anmerkung:

Im Cloudera Manager werden jegliche Konfigurationen über das grafische Interface konfiguriert. Direkt auf dem Server befindliche manuelle Konfigurationsanpassungen werden ignoriert und gegebenenfalls zurückgerollt.

 

Konfiguration High Availability Cloudera am Beispiel einer 5.11-Installation.

 

  1. HDFS Service über den Cloudera Manager auswählen

    step1-hdfs

  2. Aus dem Menüpunkt Action –> Enable High Availibility auswählen

    step2-hdfs

  3. Nameservice benennen –> namerservice1

    step3-hdfs

  4. Rollen zuordnen

    step4-hdfs

  5. Änderungen überprüfen und gegebenenfalls überschreiben

    step5-hdfs

  6. Ausführen

    step6-hdfs

  7. Gratulation

    step7-hdfs

Nachdem für HDFS High Availability eingeschaltet ist, müssen noch Hue und Hive entsprechend des Dokumentationslinks angepasst werden.

Durch einen Test, bei dem der NameNode im laufenden Betrieb hart ausgeschaltet wird, wird überprüft, ob der  Zookeeper sich um den automatischen Failover kümmert, in dem der Standby NameNode zum aktiven NameNode gemacht wird.

step8-hdfs-failover

Nach simuliertem Systemausfall von Namenode und einer kurzen Downtime werden die Rollen automatisch getauscht und HDFS stellt den Dateizugriff sicher.

step8-hdfs-failover2

 

Es gilt zu beachten, dass jeder einzelne Dienst hochverfügbar konfiguriert und getestet wird.

 

Weiterführende Konfiguration von Hochverfügbarkeit kann der offiziellen Cloudera Dokumentation entnommen werden.

 

Links:

https://www.cloudera.com/documentation/enterprise/5-11-x/topics/cdh_hag_hdfs_ha_enabling.html

https://www.cloudera.com/documentation/enterprise/5-11-x/topics/cdh_hag_hdfs_ha_cdh_components_config.html#topic_2_6

 

Kontakt:

Simon Hahn
simon.hahn@opitz-consulting.de

 

Veröffentlicht unter Analytics & BigData, Uncategorized | Verschlagwortet mit , , , , | Kommentar hinterlassen

Wie Ansible bei der Installation einer Big-Data-Distribution helfen kann? – Vorbereitungstasks einer Cloudera Installation

Ansible hat sich in den letzten Jahren zu einem einsteigerfreundlichen und wichtigen Tool der Automatisierung entwickelt. Durch die Einfachheit können tägliche, sich wiederholende Arbeiten simpel automatisiert werden. Durch die zunehmende Digitalisierung rückt auch Big Data immer mehr in den Vordergrund. Das Datenwachstum nimmt exponentiell zu. Traditionelle Datenbanklösungen reichen oft nicht mehr aus und neuere „Open Source“-Technologien drängen in den Markt. Big-Data-Distributionen vereinen diese verschiedenen Technologien und Services und stellen diese dem Kunden in einer übersichtlichen Administrationsoberfläche zur Verfügung.

Dieser Blogeintrag handelt von einer Installation eines Big Data Clusters mit Hilfe von Ansible, welches das Grundgerüst darstellt. Playbooks werden zur Vorbereitung einer manuellen Cluster-Installation via Cloudera Manager auf die Nodes ausgerollt. Es stellt sicher, dass die Nodes im Verbund mit gleichem OS, Packages, Parametern usw. aufgebaut werden. Weiterführende Informationen gibt es zum Beispiel im DOAG Artikel – : http://www.opitz-consulting.com/fileadmin/user_upload/Collaterals/Artikel/red-stack-magazin-2016-05_Warum-Ansible-fuer-DevOps-eine-gute-Wahl-ist_Simon-Hahn_sicher.pdf

In einem Cloudera Cluster übernimmt jeder Node unterschiedliche Rollen.

Unterteilt wird in NameNode, StandbyNode, DataNode, EdgeNode, Cloudera-ManagerNode (Siehe Abbildung).

grafik_bd_showcluster

NN: Der NameNode ist die zentrale Master-Komponente und verwaltet die Metadaten für alle gespeicherten Daten auf allen DataNodesDazu unterhält er eine Liste mit den aktuellen Speicherorten der Blöcke von Verzeichnissen und Dateien sowie ein Journal-File mit den aktuellen Dateioperationen. Auf Basis dieser beiden Dateien kann er Anfragen nach Dateien jederzeit beantworten, speichert aber selbst keine Daten.

SN: Der StandbyNode übernimmt die Aufgabe des NameNode im Falle eines Ausfalls.

CM: Cloudera Manager stellt die Oberfläche zur Installation, Verwaltung und Administration des Clusters.

EN: Der EdgeNode gilt als Interface zwischen äußerem Netzwerk und internem Cluster. Auf ihm werden oftmals Datenintegrationstools wie Scoop und andere Applikationstools installiert.

DN: DataNodes sind die Slave-Komponenten der Architektur, die lediglich für die Datenspeicherung zuständig sind. Sie sind „einfach“ gestrickte Elemente, über die die Skalierung des Clusters erreicht wird.

O|M|P = Cloudera Manager benötigt eine Oracle oder MySQL oder Postgres.

Der Clusterunterbau läuft auf dem javabasierten, verteilten Dateisystem Hadoop, bzw. HDFS. Über dieses werden die Daten blockweise in einzelnen DataNodes gespeichert.

 

Ansible 2.1.0 als Hilfe

In meinem Git verwaltetem Ansible Cloudera Projekt werden die einzelnen Nodes in der „hosts“-Datei von Ansible definiert.

hosts:
[cloudera_manager]
cloudera-cm

[cloudera_edgenodes]
cloudera-en

[cloudera_namenodes]
cloudera-nn
cloudera-sn

[cloudera_nodes]
cloudera-dn1
cloudera-dn2
cloudera-dn3
cloudera-dn4

In den einzelnen „yml“-Dateien (cloudera-cm.yml) im „host_vars“-Verzeichnis werden explizit spezielle Parameter gesetzt.

Beispiel: cloudera-cm.yml

# SYSTEM Parameter
hostname: cloudera-cm
ip_address_public: 192.168.56.70
domain: localdomain
common_root_password: XXXXX

# Kernelparameter
kernelparameter:
– { name: ‚vm.swappiness‘, value: ’10‘ }

# MYSQL Parameter for cloudera_cm
# https://github.com/geerlingguy/ansible-role-mysql
overwrite_global_mycnf: yes
mysql_user_home: /root
mysql_user_name: root
mysql_user_password: nicht_wichtig J
mysql_root_password_update: yes
mysql_enabled_on_startup: yes
mysql_port: „3306“
mysql_bind_address: ‚0.0.0.0‘
mysql_datadir: /var/lib/mysql

# RECOMMENDED CLOUDERA MANAGER MYSQL PARAMETER
mysql_transaction_isolation: READ-COMMITTED
mysql_key_buffer_size: 32M
mysql_max_allowed_packet: 32M
mysql_thread_stack: 256k
mysql_thread_cache_size: 64
mysql_query_cache_limit: 8M
mysql_query_cache_size: 64M
mysql_query_cache_type: 1
mysql_max_connections: 550
mysql_binlog_format: mixed
mysql_read_buffer_size: 2M
mysql_read_rnd_buffer_size: 16M
mysql_sort_buffer_size: 8M
mysql_join_buffer_size: 8M
mysql_innodb_file_per_table: 1
mysql_innodb_flush_log_at_trx_commit: 2
mysql_innodb_log_buffer_size: 64M
mysql_innodb_buffer_pool_size: 4G           # angepasst auf 4 GB, da VM nur 8GB hat
mysql_innodb_thread_concurrency: 8
mysql_innodb_flush_method: O_DIRECT
mysql_innodb_log_file_size: 512M
mysql_sql_mode: STRICT_ALL_TABLES

mysql_databases:
– name: amon
encoding: utf8
– name: rman
encoding: utf8
– name: metastore
encoding: utf8
– name: sentry
encoding: utf8
– name: nav
encoding: utf8
– name: navms
encoding: utf8
– name: cmf
encoding: utf8
– name: oozie
encoding: utf8
– name: hue
encoding: utf8
– name: hive
encoding: utf8

mysql_users:
– name: amon
host: „%“
password: XXXXX
priv: „amon.*:ALL“
– name: rman
host: „%“
password: XXXXX
priv: „rman.*:ALL“
– name: metastore
host: „%“
password: metastore
priv: „metastore.*:ALL“
– name: sentry
host: „%“
password: XXXXX
priv: „sentry.*:ALL“
– name: nav
host: „%“
password: nav
priv: „nav.*:ALL“
– name: navms
host: „%“
password: XXXXX
priv: „navms.*:ALL“
– name: cmf
host: „%“
password: cmf
priv: „cmf.*:ALL“
– name: oozie
host: „%“
password: oozie
priv: „oozie.*:ALL“
– name: hue
host: „%“
password: XXXXX
priv: „hue.*:ALL
– name: hive
host: „%“
password: XXXXX
priv: „hive.*:ALL“

Beispiel: cloudera-dn1.yml
# SYSTEM Parameter
hostname: cloudera-dn1
ip_address_public: 192.168.56.61
domain: localdomain
common_root_password: xxxxxxx

kernelparameter:
– { name:  ‚vm.swappiness‘, value: ’10‘ }

Mit weiteren Rollen, wie „cloudera_manager“, „cloudera_manager_agent“ und „cloudera_prereqs“, die zuvor erstellt wurden, wird angegeben, was und welche Parameter auf dem jeweiligen Linux Host installiert werden.

Als Betriebssystem dient Centos 7.1, das zuvor für jeden Host installiert wurde. Weiterführende Anpassungen werden nun per Ansible Playbook deployed, welches jede oben genannte Rolle auf den Servern ausführt. Als grundlegende Datenbank für den Cloudera Manager wurde per frei erhältlichem „ansible-role-mysql“ eine MySQL-Datenbank auf den Cloudera Manager Host (CM) mit entsprechenden Benutzern ausgerollt und installiert. Diese wird für die manuelle Installation des Cloudera Clusters benötigt.

Weitere Rollen sind nur teilweise aufgelistet. Sie beinhalten grundlegende Schritte wie Installation von Paketen, Grundvoraussetzungen für eine optimierte Installation.

Siehe Link: https://www.cloudera.com/documentation/enterprise/release-notes/topics/rn_consolidated_pcm.html

Beispiel: cloudera_manager.yml

# cloudera_manager and cloudera_manager_agent installation via ansible

# dnsmasq
– name: Install dnsmasq
yum: pkg=dnsmasq state=present
tags: packages
ignore_errors: yes

# dnsmaq einschalten
– name: Ensure dnsmasq is enabled on boot.
service: „name=dnsmasq.service state=started enabled=yes“
register: dnsmasq_service_configuration
tags: dnsmasq_service_configuration

# copy dnsmasq.conf
– name: copy template dnsmasq.conf
template: src=dnsmasq.conf.j2 dest=/etc/dnsmasq.conf  mode=0644 owner=root group=root
tags: copy_dnsmasq_config

– name: add cloudera-cdh5 Repo
yum_repository:
name: cloudera-cdh5
description: Packages for Cloudera’s Distribution for Hadoop, Version 5, on RedHat or CentOS 7 x86_64
baseurl: https://archive.cloudera.com/cdh5/redhat/7/x86_64/cdh/5/
gpgkey: https://archive.cloudera.com/cdh5/redhat/7/x86_64/cdh/RPM-GPG-KEY-cloudera
gpgcheck: yes

– name: add cloudera-manager Repo for RedHat 7
yum_repository:
name: cloudera-manager
description: Packages for Cloudera’s Distribution for Hadoop, Version 5, on RedHat or CentOS 7 x86_64
baseurl: https://archive.cloudera.com/cm5/redhat/7/x86_64/cm/5/
gpgkey: https://archive.cloudera.com/cm5/redhat/7/x86_64/cm/RPM-GPG-KEY-cloudera
gpgcheck: yes
tags: cloudera_installation
when: ansible_os_family == „RedHat“ and ansible_distribution_major_version == „7“

– name: add cloudera-manager Repo for RedHat 6
yum_repository:
name: cloudera-manager
description: Packages for Cloudera’s Distribution for Hadoop, Version 5, on RedHat or CentOS 7 x86_64
baseurl: https://archive.cloudera.com/cm5/redhat/6/x86_64/cm/5/
gpgkey: https://archive.cloudera.com/cm5/redhat/6/x86_64/cm/RPM-GPG-KEY-cloudera
gpgcheck: yes
tags: cloudera_installation
when: ansible_os_family == „RedHat“ and ansible_distribution_major_version == „6“

– name: add cloudera-manager Repo for Redhat 5
yum_repository:
name: cloudera-manager
description: Packages for Cloudera’s Distribution for Hadoop, Version 5, on RedHat or CentOS 7 x86_64
baseurl: https://archive.cloudera.com/cm5/redhat/5/x86_64/cm/5/
gpgkey: https://archive.cloudera.com/cm5/redhat/5/x86_64/cm/RPM-GPG-KEY-cloudera
gpgcheck: yes
tags: cloudera_installation
when: ansible_os_family == „RedHat“ and ansible_distribution_major_version == „5“

# Install Cloudera Manager Server
– name: Install cloudera-manager-daemons
yum: pkg=cloudera-manager-daemons state=present
tags: cloudera_installation
ignore_errors: yes

– name: Install cloudera-manager-server
yum: pkg=cloudera-manager-server state=present
tags: cloudera_installation
ignore_errors: yes

– name: Overwriting db.properties
template: src=db.properties.j2 dest=/etc/cloudera-scm-server/db.properties owner=cloudera-scm group=cloudera-scm mode=0644
ignore_errors: yes
tags: copy_templates

# test
– name: Ensure Cloudera is started and enabled on boot.
service: „name=cloudera-scm-server state=stopped enabled=yes“
register: cloudera_service_configuration
tags: cloudera_service_configuration

– name: Ensure Cloudera is started and enabled on boot.
service: „name=cloudera-scm-server state=started enabled=yes“
register: cloudera_service_configuration
tags: cloudera_service_configuration

Sobald die einzelnen DataNodes per „Ansible Playbook“ vorbereitet und ausgerollt wurden, wird automatisch der „Cloudera Manager Server Service“ und der „Cloudera Manager Agent Service“ auf den entsprechenden Nodes gestartet und die manuelle grafische Installation der Cloudera Distribution kann per Browser beginnen.

Software Installation

Basierend auf möglichst gleich vorkonfigurierten Systemen, wird über den Cloudera Manager die weitere Clustereinrichtung getätigt. Durch Starten des „cloudera-scm-servers“ kann über die Weboberfläche der Cluster konfiguriert werden. Standardport ist 7180.

http://cloudera-cm:7180

 

Clusterkonfiguration

Step 1 – Auswahl der zu installierenden Dienste

1_clustereinrichtung

Auswahl der Pakete, die entsprechend installiert werden müssen.

 

Step 2 – Rollenzuweisungen

2_clustereinrichtung_rollenzuweisung

3_clustereinrichtung_rollenzuweisung

4_clustereinrichtung_rollenzuweisung

 

Step 3 – Datenbank-Setup

MySQL-Zugangsdaten werden hier manuell eingetragen. Diese stimmen mit den Ansible MySQL-Passwörtern überein.

dbsetup

Step 4 – Clusteränderungen

Gegebenenfalls anpassen.

Step 5 – Cluster-Konfigurationsausführung

10_clustereinrichtung_aenderungen

Step 6 – Cloudera wurde erfolgreich installiert

11_clustereinrichtung_aenderungen

Step 7 – Übersicht der Cloudera Standardseite

13_cloudera_run_ohne_Fehler_da_dns_unterdrueckt

Links für Oracle DBAs

 

Kontakt:

Simon Hahn

simon.hahn@opitz-consulting.com

 

Veröffentlicht unter Analytics & BigData, Cloud & Infrastructure | Verschlagwortet mit , , , , | Kommentar hinterlassen

AWS News KW 31

Auch bei Amazon hat die Feriensaison begonnen. In der letzten Woche waren die News sehr überschaubar.

Amazon Connect und Amazon Lex Integration

Amazon Connect ist ein cloud basiertes Self-Service Contact Center, das es jedem Unternehmen ermöglicht, seinen Kunden einen besseren Service zu geringeren Kosten bereitzustellen.

Amazon Lex ist ist ein Service zur Erstellung von Konversationsschnittstellen für Sprache und Text. Amazon Lex nutzt dabei die selben Deep Learning Methoden die auch Alexa verwendet.

Durch die Kombination beider Services ist es möglich auf mehr Wünsche der Kunden automatisch zu reagieren. Beide Seiten profitieren gleichermaßen. Als Kunde kann ich mein Anliegen schneller klären, da ich nicht auf einen freien Mitarbeiter warten muss. Als Anbieter profitiere ich zum einen durch geringere Kosten und andererseits durch eine größere Kundenzufriedenheit.

Weitere Informationen zu Connect hier und zu Lex hier

Veröffentlicht unter Cloud & Infrastructure | Verschlagwortet mit , , | 1 Kommentar

AWS News KW 30

CloudFormation StackSets für Multi Account und Region Provision

CloudFormation ist Amazons Infrastructure as Code Framework. Ähnlich wie Puppet wird der Endzustand des gewünschten Systems (Stacks) beschrieben.

Ein Nachteil von CloudFormation war bisher, dass ein Stack nicht in mehreren Regions oder für mehrere Accounts komfortabel deployt werden konnte. Vielmehr musste der Stack für alle Kombinationen separat deployt werden.

Mit StackSets wurde jetzt eine Möglichkeit geschaffen, Multi Account und Multi Region Deplyoments mit wenigen Klicks zu konfigurieren und auszuführen. Dabei wird der Stack sequentiell in den konfigurierten Regions deployt. Die Reihenfolge kann dabei festgelegt werden. Innerhalb der Region wird gleichzeitig in den konfigurierten Accounts deployt. Der Grad der Parallelität kann ebenfalls konfiguriert werden.

Weitere Informationen zu CloudFormation StackSets hier.

GPU Powered Streaming Instanzen für AppStream 2.0

Amazon AppStream 2.0 ist ein Service von Amazon. Er bietet die Möglichkeit Windows Applikationen in einem Browser zu verwenden. Dafür wird der Remote Desktop zum Browser gestreamt.

Für grafikintensive Anwendungen stehen ab sofort die G2 Instanztypen zur Verfügung. Sie sind für Anwendungen ausgelegt die CUDA, DirectX oder OpenGL für das Rendering nutzen.

Für High-End und High-Performance Anwendungen, die entweder NVIDIA Api´s oder viel Speicher benötigen können auch die eben erst eingeführten G3 Instanztypen verwendet werden.

Die Preise für die einzelnen Instanzen beginnen bei 0,50 $/h für G2 Instanzen oder 2,05 $/h für G3 basierte Instanzen.

High-Resolution Custom Metrics und Alarme für Amazon CloudWatch

CloudWatch, Amazons zentraler Monitoring Service zeichnet per Default Metriken im 5 Minuten Intervall auf. Bei Bedarf kann dieser Wert mit Hilfe des sogenannten Detailed Monitoring auf 1 Minute verkürzt werden.

Um bestimmte Ereignisse zu erkennen reicht oft ein 1 Minuten Intervall nicht aus. Daher ist es ab sofort möglich eigene Metriken per High-Resolution Metrics jede Sekunde zu erfassen und Alarme alle 10 Sekunden auszuwerten.

Weitere Informationen zu Custom Metrics hier.

 

Veröffentlicht unter Cloud & Infrastructure | Verschlagwortet mit , | Kommentar hinterlassen