Seite wählen

NETWAYS Blog

Bacula Web Gui Bacula-Web

von | Sep 18, 2012 | , ,

Seit einiger Zeit ist eine neue Version der Web Gui „Bacula-Web“ für Bacula erschienen.
Bacula-Web ist ein Open Source Tool, welches ein Teil des Bacula Projectes ist.
Mit dieser Oberfläche ist es zwar nicht möglich Jobs zu steuern, aber man kann sich dafür
viele Informationen über Jobs, Volumes und Pools übersichtlich anzeigen lassen.

Die Installation und Konfiguration ist schnell durchgeführt, was ein Ausprobieren
sehr einfach macht.
Für die Installation benötigt man lediglich einen Webserver mit PHP Modulen
(Howto) und eine laufende Bacula Director Datenbank egal ob MySQL, postgreSQL oder SQLite.
Leider bin ich heute auf einen Fehler gestoßen, der mit der neusten Version 5.2.10 und
postgreSQL auftritt. Der Bug ist bekannt und ich hoffe, dass dieser schnell behoben wird.

Trotzdem lohnt sich das Ausprobieren auf jeden Fall.

Martin Schuster
Martin Schuster
Senior Systems Engineer
Martin gehört zu den Urgesteinen bei NETWAYS. Wenn keiner mehr weiss, warum irgendwas so ist, wie es ist, dann wird Martin gefragt. Er hat es dann eigentlich immer mal schon vor Jahren gesehen und kann Abhilfe schaffen :). Vorher war er bei 100world als Systems Engineer angestellt. Während er früher Nürnbergs Partykönig war, ist er nun stolzer Papa und verbringt seine Freizeit damit das Haus zu renovieren oder zieht einfach um und fängt von vorne an.
Lies mehr von Martin und triff unser Team

Postgresql: Neues vom Elefant

von | Mai 10, 2012 | ,

Postgresql bereichert die Welt von OpenSource Datenbanken schon seit langem, führte allerdings bisher eher ein Schattendasein und überließ MySQL das Feld – Allerdings völlig zu unrecht. Postgresql orientiert sich mehr am SQL Standard und fördert deutlich stärker die Kompatibilität mit anderen Systemen. Das ganze System fühlt sich auch mehr nach „echter“ Datenbank an, z.B. durch Namespaces, Sequenzen, Partitionierung oder die interne Verwaltung. Durch stärkere Kontrolle der Datenhaltung gewinnt man viel Performance und Transparenz bei der Entwicklung von Software oder den Betrieb von Plattformen auf Basis von Postgresql. Mir haben ein paar Sachen besonders gut gefallen die ich gerne Vorstellen würden:

Table Inheritance

Postgresql unterstützt Vererbungen. Damit ist es Möglich Objektrelationen aus der Softwareentwicklung auf die Datenbank zu übertragen ohne sich verbiegen zu müssen. Die Vererbung kann auch zur Partitionierung benutzt werden da die Attributwerte des ganzen Datensatz in den jeweiligen Tabellen landen.

create sequence universal_seq;
CREATE TABLE Base(
  oid INT8 PRIMARY KEY DEFAULT nextval('universal_seq'),
  name varchar(100) NOT NULL CHECK (name <> '')
);
CREATE TABLE asset(
  vendor VARCHAR(100),
  assetid uuid NOT NULL DEFAULT uuid_generate_v4()
) inherits (base);
create table server(
  description varchar(255),
  ipaddress cidr
) inherits(asset);

Arrays

Will man ein paar Werte in einem Feld abspeichern und nicht gleich eine abhängige Relation durch Fremdschlüssel anlegen eigenen sich simple Arrays. Die Arrays werden in der Datenbank als native Datentypen behandelt.

create table rezepte(
  id SERIAL,
  titel varchar(100),
  tags VARCHAR(100)[]
);
insert into rezepte(titel, tags) VALUES('Spinatauflauf', '{"spinat", "vegetarisch", "feta"}');
insert into rezepte(titel, tags) VALUES('Spaghetti bolognese', '{"tomaten", "hackfleisch"}');
insert into rezepte(titel, tags) VALUES('Spanakopita', '{"spinat", "vegetarisch", "feta"}');
insert into rezepte(titel, tags) VALUES('Gyros', '{"tzatziki", "knoblauch"}');
select * from rezepte WHERE 'spinat'=ANY(tags);

HSTORES

Hier prallen eigentlich zwei Welten aufeinander: Relationale Datenbanken und NOSQL. HSTORES ist ein Datentyp welcher ein Dictionary enthält. Interessant ist auch hier das es sich um einen ‚internen‘ Typ handelt der speziell indiziert werden kann.

create table attributes(uid SERIAL, dict HSTORE);
create table attributes(uid SERIAL, dict HSTORE);
insert into attributes(dict) VALUES('"f"=>"Eduart", "l"=>"Zimmermann"');
CREATE INDEX attr_dict_lastname
ON attributes
((attributes.dict -> 'l'));
select dict -> 'f' as firstname from attributes where dict -> 'l' = 'Zimmermann';

Zugegeben, es ist nicht wirklich alles neu aber es lohnt sich ein Blick über den See. Wer ungebunden ist und die Möglichkeit besitzt sich auf ein System festzulegen, kriegt mit Postgresql gleich eine komplette Fabrik zum Werkzeugkasten hinzu.

Marius Hein
Marius Hein
Head of IT Service Management
Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert und viele Jahre in der Softwareentwicklung gearbeitet. Mittlerweile ist er Herr über die interne IT und als Leiter von ITSM zuständig für die technische Schnittmenge der Abteilungen der NETWAYS Gruppe. Wenn er nicht gerade IPv6 IPSec Tunnel bohrt, sitzt er daheim am Schlagzeug und treibt seine Nachbarn in den Wahnsinn.
Lies mehr von Marius und triff unser Team

Auf die Größe kommt es an

von | Apr 4, 2012 | , ,

Immer wieder ist es notwendig auf einem bestehenden Setup das „Partitionslayout“ zu ändern. Zum Beispiel sind die zu Beginn eines Projekt definierten Volumes falsch dimensioniert oder ein Service benötigt mehr bzw. weniger Platz wie angedacht.
Mit LVM und ext3/ext4 ist das auch meist kein Problem. Beim Verkleinern würde man zuerst das Dateisystem ’shrinken'(verkleinern) und anschließend das Logical Volume entsprechend anpassen. Das Vergrößern geht online und noch einfacher. Zuerst das LV auf die Größe vergrößern und anschließend das Dateisystem wachsen lassen.
lvresize -l+10G /dev/lv/volume; resize2fs /dev/lv/volume;
Allerdings unterstützen das nicht alle Dateisysteme. Zum Beispiel kann man mit XFS zwar das Dateisystem vergrößern, allerdings nicht verkleinern. Zumindest nicht ohne größeren Aufwand. In der Regel weiß man im Voraus, welche Daten bzw. Services auf diesen Dateisystemen abgelegt werden. Möchte man z.B. die Datenpartition von MongoDB in einem Replica-Set verkleinern, fährt man den Daemon herunter, verkleinert das Volume, formatiert das Volume mit XFS neu und anschließend startet man den MongoDB-Daemon ohne Daten wieder. Für den Datenabgleich sorgt dann MongoDB selbst. Cool, oder? 🙂 Ähnliche Möglichkeiten besitzt auch PostgreSQL mit pgpool2 und Online-Recovery.
Zum Thema MongoDB gibt es auf der kommenden Open Source Data Center Conference ebenfalls spannende Vorträge!

Sebastian Saemann
Sebastian Saemann
CEO Managed Services
Sebastian kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord aufzustellen.
Lies mehr von Sebastian und triff unser Team

Postgresql-Replikation mit pgpool-II

von | Sep 27, 2011 | , ,

In Bezug auf Bernds Blogpost mit seinem Hinweis auf die gute Weiterentwicklung der Replikationsfunktionen in Postgresql stelle ich heute eine sehr komfortable und robuste Art der PGSQL-Replikation vor. Postgresql verfügt ab der Version 9.0 über eine Streaming-Replikation mit Hot-Stand-by. Eine Streaming-Replikation ist im Prinzip das gleiche Verfahren wie bei einem MySQL Master-Slave Setup mit Row-Based Replikation. Das WAL (Write-Ahead-Log) wird hier vom Read-only Slave Server abgerufen und ausgeführt. Im Falle eines Ausfalls des Masters besteht die Möglichkeit darauf zu reagieren und vom Read-Only- in Read-Write-Mode zu wechseln und somit den Slave zum Master zu propagieren.
Die third-party Software pgpool2 ist in der Lage diesen Failover zu steuern bzw. zu veranlassen. Pgpool2 ist eine Middleware die zwischen dem PGSQL-Client und Servern fungiert und bietet folgende Funktionen:

  • Connection-Pooling,

Verbindungen zu den PGSQL-Servern werden persistent erzeugt und werden wiederverwendet.

  • Replication,

DML-Statements können dupliziert werden und an die dahinter liegenden Postgres Server verteilt. Eine Streaming-Replikation wäre hierbei nicht notwendig.

  • Load-Balancing,

Client-Anfragen werden verteilt auf die Nodes, die sich im Pool befinden. In einer Streaming-Replikation besteht außerdem die Möglichkeit DML-Statements nur an den Master zu senden und SELECTS an die Slaves.

  • Limiting Exceeding Connections,

bei erreichen der maximalen Anzahl von Datenbankverbindungen gibt Postgres einen Fehler zurück. pgpool2 kann diese Verbindungen in eine Queue ablegen und abarbeiten.

  • Parallel Query

Queries können paralell über mehrere Datenbankserver hinweg ausgeführt werden, um ein Ergebnis schneller ausliefern zu können.

Für die Hot-Standby-Lösung muss der Replikationsmodus von pgpool2 deaktiviert werden. pgpool2 steuert nur die Verbindungen auf die Server, sucht sich seinen Master und kümmert sich um den Failover. Hierfür sind einige kleine Skripte notwendig. Ein weiteres sehr nützliches Feature ist die Überwachung des Slave-Lags. Ist der Slave-Lag höher als der eingestellte Schwellwert schwenkt pgpool2 die Verbindungen von diesem Slave weg bis dieser wieder aufgeholt hat. Auch sehr hilfreich ist das Online-Recovery das eigentlich durch Postgres zur Verfügung gestellt wird. Mit pgpool2 kann man dieses jedoch bequem starten und einen inkonsistenten Slave  von seinem Master im Produktivbetrieb ohne Downtime, Snapshots oder gelockten Tabellen wiederherstellen.
Die Steuerung von pgpool2 erfolgt über die i.d.R. mit installierten CLI-Tools. Zum Beispiel kann man mit pcp_recovery_node das Online-Recovery durchführen oder mit pcp_attach_node bzw. pcp_detach_node Hosts aus dem Pool entfernen bzw. hinzufügen.
Der Blogpost soll nur einen kurzen Überblick über Features und Möglichkeiten darstellen – vollständige Informationen findet man in den sehr guten Dokumentationen von pgpool2 und Postgresql.

Sebastian Saemann
Sebastian Saemann
CEO Managed Services
Sebastian kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord aufzustellen.
Lies mehr von Sebastian und triff unser Team

OSDC-Ticker: PostregSQL Replikation & Distributed File Systems

von | Jun 24, 2010 | , ,

Michael Renner informiert in seinem Vortrag über den aktuellen Status bei PostgeSQL und über verschiedene Replikationsmechanismen für PostgreSQL. Dabei stellt er sowohl die Historie mit Trigger basierter Replikation bzw. Logshipping, als auch die aktuellen Möglichkeiten der Live Migration, die fest im Daemon verankert ist. Verfügbar ist diese Funktionalität ab Version 9.0 des Datenbanksystems.
Einer der letzten Vorträge des gestrigen Tages von Fabrizio Manfred befasste sich mit verschiedenen Distributed File Systems, die als Open Source verfügbar sind. Er beginnt mit OpenAFS, einer Implementierung des Andrew Filesystems von IBM. Nach seiner Erfahrung lassen sich damit 40-50 MB/s erreichen. Es eignet sich gut für wesentlich mehr Reads als Writes und viele Clients. Als zweites stellt er GlusterFS vor, das auch bei sehr großen Datenmengen annähernd linear skaliert. Viele Features, die sich auch gut kombinieren lassen, machen es zu einem sehr flexiblen Werkzeug. Es eignet sich gut für große Datenmengen, Zugriff mit verschiedenen Protokollen und als Ersatz für teure SANs. Nachteil sind die geringen Security Einstellungen und schlechte Performance, wenn viele Aktionen auf ein und dem selben File stattfinden.
Ein weiteres Beispiel ist HDFS (Hadoop FS), das vom Google Filesystem und Mapreduce inspiriert ist. Die Namenodes verwalten die Metainformationen, während die Datanodes die eigentlichen Daten bereitstellen. Es bietet RW Replication und auch Re-Balancing und eignet sich sehr gut für Task- und Content-Distribution, dafür ist es kein Standard Filesystem und nicht Posix kompatibel. Das letzte Beispiel ist ceph, das einen ähnlichen Aufbau wie HDFS hat. Ein großer Vorteil ist, dass ceph Daten automatisch je nach Zugriffshäufigkeit neu umvorteilen kann. Für Fabrizio ist ceph damit das interessanteste DFS. Einziger Nachteil ist das relativ junge Alter, da es noch nicht so viel Erfahrung damit gibt.
Am Ende des Vortrags stellte er verschiedene Real-World Szenarien im Detail inkl. genauer Architektur vor, die auf OpenAFS, GlusterFS oder Hadoop basieren. Einige interessante Lessons learned aus diesen Projekten, die man schon am Anfang bedenken sollte: Bei 10PT Speicher fallen jeden Tag im Durchschnitt 22 Festplatten aus. Auch dafür sollte man vorbereitet sein und alleine diese Daten inkl. aller weiteren Änderungen müssen im Netz repliziert werden. Eine spätere Migration kann schon alleine deswegen aufwendig werden, weil das umkopieren von 1PB mit aktuellen Netzanbindungen bis zu 2 Jahre dauern kann.

Trainings

Web Services

Events