Interxion, Ceph und Sommerspecial

Die ersten heißen Tage sind vorüber und die Ferien haben in fast allen Bundesländern begonnen. Für uns nähert sich damit so langsam die etwas ruhigere Jahreszeit in der wir uns intensiv mit eigenen Projekten beschäftigen können.

Dieses Jahr steht, wie bereits im Jahresausblick 2015 angekündigt, der Ausbau unserer Infrastruktur bei Interxion sowie der Aufbau unseres Ceph Clusters an.

Interxion: Neue Racks und Brandabschnitte

Bereits in der letzten Woche haben wir unseren Account Manager von Interxion im Düsseldorfer Datacenter besucht um die am 01.07. eröffneten Flächen zu besichtigen. Die neu erschlossenen Flächen wurden nach aktuellen Standards in Sachen Kühlung und Brandbekämpfung gebaut, sind daher extrem effizient und erfüllen unsere Anforderungen zu 100%.

Da wir große Fans von Redundanz und Ausfallsicherheit sind mieten wir für unsere Racks keinen privaten Raum (Cage) um diese zentral unterzubringen, sondern verteilen die Racks und Server über mehrere Brandabschnitte und vernetzen diese anschließend mit 10G. Dies hat den Vorteil, dass bei größeren Problemen im Datacenter nur ein kleiner Teil unserer Infrastruktur betroffen ist, gleichzeitig können wir so die Datensicherheit der Backups und des geplanten Ceph Clusters weiter erhöhen.

Selbstheilung + High-Performance = Ceph

In den letzten Wochen und Monaten haben wir sehr viel Erfahrung mit Ceph sammeln können, unter anderem durch das von Mike gebaute Testlab aus “Alt-Hardware”. Die Server sind mittlerweile über 7 Jahre alt und bieten sich aufgrund der “natürlichen” Fehlerrate als ideale Kandidaten für unser Testlab an, so vergeht kaum ein Tag an dem nicht irgendetwas defekt ist oder getauscht werden muss. – Perfekte Bedingungen um Ceph unter schwersten Bedingungen zu testen.

Zugegeben Performance Tests sind aufgrund der alten Hardware und der 1G Verkabelung nicht sinnvoll, aber darum geht es bei den Tests auch nicht. Vielmehr interessiert uns was passiert, wenn zB plötzlich der Strom, Festplatten, Controller oder Teile des Netzwerks ausfallen.

Ceph begeistert uns dabei jeden Tag aufs Neue und hat bisher jeden Fehler zuverlässig erkannt und automatisch gefixt, selbst harte Eingriffe in den Betrieb und den Verlust von 2/3 des Clusters fängt Ceph ohne Probleme ab. Solche Verluste würde ein traditionelles RAID-Array nur unter ganz bestimmten Voraussetzungen überleben, in den meisten Fällen wäre eine aufwendige Rekonstruktion oder aber die Wiederherstellung aus den Backups angesagt.

In den kommenden Wochen werden wir einen ausführlicheren Bericht zu Ceph veröffentlichen, alle Erkenntnisse hier unterzubringen würde einfach den Rahmen sprengen. 🙂

Sommerspecial: Neukunden Rabatte im Juli

Dieses Jahr vergeben wir keinen statischen PromoCode sondern koppeln den PromoCode an die Temperatur in unserem Büro, d.h. wenn wir schwitzen könnt ihr kräftig sparen. Die Kombination des Rabattes aus der PromoAktion und dem Abschluß eines 6 bzw. 12 Monatsvertrags ist möglich. 😉

Den tagesaktuellen PromoCode findet Ihr links hinter der roten “Lasche”, den dazugehörigen Wetterbericht auf wetter.com.

 

 


2015 – Das Jahr der neuen Features!

Platz für Innovation: Unser neues HQ

Bereits in 2014 haben wir den Grundstein für weiteres Wachstum und innovative Ideen geschaffen. Begonnen haben wir das Jahr mit der Suche nach einem neuen Standort für unser HQ im Großraum Düsseldorf, neben vielen interessanten Standorten wurde uns die erste Etage im “Meisterhaus” eines alten Farbikgeländes in Erkrath angeboten. Die “häusliche Atmosphere”, der Ausblick ins Grüne, der Steg runter zur Düssel und die perfekte Lage zwischen beiden Datacentern sorgen auch in hektischen Zeiten für Motivation und Ruhe im Team, die Entscheidung viel uns daher nicht schwer.

(Weitere Infos und Bilder folgen in Kürze.)

Um euch auch in Zukunft die schnellsten und besten Dienstleistungen bieten zu können haben wir im Spätsommer ein weiteres Datacenter erschlossen, Interxion.

Verstärkung des r::S Teams

Besonders gefreut haben wir uns Simon Wodrich und Mike Schürmann für unser Team gewinnen zu können. Simon ist leidenschaftlicher PHP-Programmierer, spricht jede API fließend und kennt keine unlösbaren Probleme. Mike ist der KVM-Experte im Team und kümmert sich daher um den weiteren Ausbau und das Monitoring unserer neuen virtuellen Infrastruktur. Seine Fähigkeiten als “Server-Notarzt” haben wir bisher zum Glück nicht gebraucht. 😉

Magento-Cluster: 1500 gleichzeitige Besucher

Bereits vor knapp 2 Wochen haben wir über unser Traffic-stärkstes Projekt berichtet. – Die offizielle Einführung der neuen Magento Cluster ist für Q2 geplant, solltest du bereits jetzt Bedarf an einer High-Performance Lösung haben schreib uns eine eMail.

Tarifanpassung: Cloud-Server

Aufgrund der großen Nachfrage im letzten Jahr haben wir unsere Cloud-Server Tarife überarbeitet. Gen3 unserer Plattform nutzt ab sofort ein SSD-gecachtes Storage-System mit wahnsinnigen Lese- / Schreibraten von 1.200 MB/s und zig 1000 IOPS pro Sekunde, stellt euch doppelt so viel Arbeitsspeicher und mehr Speicherplatz zur Verfügung. Gerade Datenbank gestützte Anwendungen freuen sich sehr über die neuen Eckdaten und bedanken sich mit einem immensen Performance-Boost bei fast allen Workloads. – Die neuen Cloud Server stehen ab sofort zur Verfügung.

Basis innovativer Ideen: KVM Virtualisierung

Aufgrund unserer Erfahrungen der letzten Jahre sind wir weder vom Support noch von der Performance geschlossener Virtualisisierungs- und Storage Plattformen wie VMware und NetApp begeistert. Daher haben wir uns bereits letztes Jahr diverse Virtualisierungsplattformen angesehen und nach einer langen Testphase für die KVM Virtualisierung entschieden. KVM ist OpenSource und fest im Linux-Kernel verankert. – Migrationsphase läuft bereits, freie Kapazitäten vergeben wir ASAP 🙂

Selbstheilung + High-Performance = Ceph

Ceph ist ein nahtlos skalierbares Storage-System das sich zudem selber heilen kann. Im Gegensatz zu einem traditionellen RAID-Systemen verteilt Ceph die Daten per 10G Netzwerk auf beliebig viele Server die dem Ceph-Cluster angehören, wird der Speicherplatz knapp müssen nur weitere Server hinzugefügt werden. Eine aufwändige und fehleranfällige RAID- oder Daten-Migration ist nicht erforderlich denn Ceph kümmert sich automatisch, auch beim Ausfall von Ceph-Nodes oder Festplatten, im Hintergrund um eine optimale Verteilung der Daten im Cluster. So ist sichergestellt,  dass immer die gewünschte Anzahl an Replika im Netzwerk vorhanden ist und eure Daten sicher gespeichert sind. – Ceph ist relativ neu und komplex daher geht ein Teil des Teams Anfang Februar erst einmal auf eine Schulung, die Einführung von Ceph ist für Q2 und Q3 geplant.

Business Postfächer: SmarterMail

Aufgrund immer größeren Bedarfs an Mailspace und sicherer Kommunikation haben wir einen weiteren Kundenwunsch des letzten Jahres mit auf unsere 2DO-Liste gesetzt. Postfächer auf SmarterMail Basis bieten euch wesentlich mehr als reine Mail-Funktionen, ein Jabber-Server basierend auf dem XMPP-Protokoll, Zero-Hour Spam- und Virenfilter und ein sehr übersichtliches Webinterface sind ebenso selbstverständlich wie die Anbindung externer Geräte basierend auf iOS, Android oder Windows Mobile.

Wir sind dabei die letzten Dienste einzurichten, die Bereitstellung der neuen Business Postfächer wird daher noch in Q1 starten.

Die Einführung der Reseller-Angebote für Webentwickler und Agenturen steht ebenfalls, aber noch ohne Termin, auf unserer 2DO-Liste.

Wir freuen uns auf ein richtig spannendes Jahr mit euch. Wie immer werden wir unser Bestes geben euch das schnellste Hosting und großartigen Support zu präsentieren.


Magento Datenbank Optimierung – Teil 3

Im ersten und zweiten Teil der Reihe „Magento Datenbank Optimierung“ haben wir uns die Log-Funktionen genauer angesehen. Dieses Mal wollen wir die Datenbank von allen unnötigen Einträgen befreien.

Als direkte Auswirkung der Optimierung sehen wir mehr freien Speicherplatz auf der Festplatte und einen reduzierten Bedarf an Arbeitsspeicher.

Das Problem der großen Tabellen

Eine optimale MySQL-Konfiguration sieht vor möglichst viele Abfragen aus dem sehr schnellen Arbeitsspeicher zu bearbeiten. Große Tabellen verhindern dies und zwingen den MySQL-Server temporäre Tabellen auf der vergleichsweisem „langsamen“ Festplatte abzulegen.

Besonders gut bemerkbar macht sich dieser Performanceverlust bei der core_session Tabelle wenn diese, aufgrund vieler Besucher und / oder falsch eingestellter Session Lebensdauer, sehr groß geworden ist. Die Tabelle wird bei jedem Seitenaufruf nach alten Sessions gescannt, kann der Server diese nicht aus dem Arbeitsspeicher bedienen muss auf die „langsame“ Festplatte zurückgegriffen werden. Die Abfragedauer steigt dadurch von wenigen Millisekunden auf mehrere Sekunden was die Auslieferung der Website ebenfalls um diese Zeit verzögert. – Die Seitenladezeit des Magento Shops steigt (meistens) ohne erkennbare Anzeichen wie steigende Besucherzahlen oder CPU-Auslastung immens an.

Die Leerung der Session-Tabelle ist im Query nicht berücksichtigt da dies die Warenkörbe der Besucher leeren würde, dennoch empfehlen wir die Tabelle ab einer Größe von 50 – 100 MB zu leeren.

Unnötigen Ballast entfernen

Backup nicht vergessen! 🙂

Die folgenden Tabellen können und sollten regelmäßig geleert (nicht gelöscht!!!) werden damit die Performance Eures Magento Shops nicht negativ beeinträchtig wird: aw_core_logger, catalog_compare_item, catalogindex_aggregation, catalogindex_aggregation_tag, catalogindex_aggregation_to_tag, dataflow_batch_export, dataflow_batch_import, index_event, log_customer, log_quote, log_summary, log_summary_type, log_url, log_url_info, log_visitor, log_visitor_info, log_visitor_online, report_event, report_viewed_product_index, report_compared_product_index’.

Markiert dazu in phpMyAdmin die o.g. Tabellen und wählt anschließend unten im Dropdown den Befehl „Leeren“ aus.

cpanel-phpmyadmin-truncate

Alternativ könnt ihr folgendes Query direkt auf der MySQL-CLI oder mit Hilfe von phpMyAdmin über den Reiter „SQL“ abfeuern. – Achtet unbedingt auf die richtige Datenbank Auswahl und die korrekten Tabellennamen im SQL-Query!

TRUNCATE 'aw_core_logger';
TRUNCATE 'catalog_compare_item';
TRUNCATE 'catalogindex_aggregation';
TRUNCATE 'catalogindex_aggregation_tag';
TRUNCATE 'catalogindex_aggregation_to_tag';
TRUNCATE 'dataflow_batch_export';
TRUNCATE 'dataflow_batch_import';
TRUNCATE 'index_event';
TRUNCATE 'log_customer';
TRUNCATE 'log_quote';
TRUNCATE 'log_summary';
TRUNCATE 'log_summary_type';
TRUNCATE 'log_url';
TRUNCATE 'log_url_info';
TRUNCATE 'log_visitor';
TRUNCATE 'log_visitor_info';
TRUNCATE 'log_visitor_online';
TRUNCATE 'report_event';
TRUNCATE 'report_viewed_product_index';
TRUNCATE 'report_compared_product_index';

Die SQL-Befehle entfernen nicht mehr benötigte Daten aus den Tabellen und sorgen somit für eine rasante Ladezeit. Andere Prozesse, wie die Erstellung eines Backups, werden durch die kleinere Datenbank ebenfalls positiv beeinflusst, so verbrauchen die meisten Vorgänge wesentlich weniger Zeit und Ressourcen (Stichwort: Timeout). 🙂


Magento Datenbank Optimierung – Teil 2

Nachdem wir in der letzten Woche (Magento Datenbank Optimierung – Teil 1) die Grundlagen für einen schnellen Magento-Shop geschaffen haben zeigen wir Euch heute weitere Möglichkeiten der Optimierung.

In einem aktuellen Projekt (ca. 50.000 Besuchern, 700.000 Seitenaufrufen und knapp 1000 Checkouts pro Tag) konnten wir durch Deaktivierung der Log-Funktionen 1 – 1,5 CPU-Kerne auf dem Datenbankserver einsparen. 

Die Änderungen aus Teil 1 sorgen für eine aufgeräumte Datenbank, allerdings loggt Magento nach wie vor jeden Zugriff in den entsprechenden Tabellen und löscht diese nach einigen Tagen wieder. Beide Vorgänge verbrauchen CPU-Ressourcen die wir sinnvoller einsetzen können, daher deaktivieren wir die Log-Funktionen heute komplett.

Deaktivierung über das Backend – Lösung mit Hindernis

Magento bietet Out-of-the-Box einige Möglichkeiten die Log-Funktionen zu deaktivieren. Am einfachsten ist es das Magento Backend zu benutzen:

System -> Konfiguration -> Erweitert -> Modulausgaben

Hier setzt Ihr Mage_Log auf Deaktivieren.

Die Deaktivierung über das Backend hat einen entscheidenden Nachteil: Es werden alle internen Log-Funktionen deaktiviert, somit funktionieren die Entwickler- und Extension-Logs auch nicht mehr.

MySQL Storage Engine BLACKHOLE – Das schwarze Datenloch!

Technisch etwas anspruchsvoller aber eleganter ist die Änderung der MySQL Storage Engine der Log-Tabellen auf BLACKHOLE. BLACKHOLE ist wie der Name schon sagt ein schwarzes Loch, allerdings nur in digitaler Form und wird daher “nur” Euren Daten gefährlich.

ALTER TABLE log_url ENGINE = BLACKHOLE;
ALTER TABLE log_url_info ENGINE = BLACKHOLE;
ALTER TABLE log_visitor ENGINE = BLACKHOLE;
ALTER TABLE log_visitor_info ENGINE = BLACKHOLE;

Das oben gezeigte Query müsst Ihr direkt auf der MySQL-CLI oder mit Hilfe von phpMyAdmin über den Reiter “SQL” abfeuern. – Achtet unbedingt auf die richtige Datenbank Auswahl und die korrekten Tabellennamen im SQL-Query!!!

Sobald das SQL-Query ausgeführt wurde sind die Log-Tabellen leer und sämtliche neu zu schreibende Log-Daten werden sofort verworfen.

Die BLACKHOLE-Lösung hat einen entscheidenden Vorteil gegenüber der Backend-Lösung da aus Magento-Sicht nach wie vor alle Log-Funktionen aktiv sind. Die Entwickler- und Extension-Logs könnt Ihr nutzen, an die Log-Tabellen gesendete Daten werden allerdings nicht verarbeitet und verschwinden direkt in unserem schwarzen Loch. Ganz ohne die CPU oder unsere Speichermedien zu belasten! 😀

In der nächsten Folge (Magento Datenbank Optimierung – Teil 3) zeigen wir Euch zwei kleine aber sehr wirkungsvolle SQL-Querys zur Optimierung der Magento Datenbank.


Magento Datenbank Optimierung – Teil 1

Immer wieder werden wir, in Beratungsgesprächen zu unserem Magento Hosting und der täglichen Arbeit im Support, nach der optimalen Konfiguration eines Magento-Shops gefragt.

Unser Wissen möchten wir gerne weitergeben, deshalb findet Ihr ab heute in der Kategorieliste rechts den Punkt Performance. In unregelmäßigen Abständen werden wir hier kurze Beiträge mit leistungssteigernden Maßnahmen vorstellen.

Starten werden wir heute mit einem der häufigsten Gründe für einen langsamen Magento-Shop und Backup-Probleme, die immer größer werdenden Log-Tabellen.

Nach der Installation loggt Magento jeden Zugriff auf eine beliebige Seite in der Datenbank. Die Daten können später dazu genutzt werden Statistiken oder andere Auswertungen zu erstellen, in der Regel werden diese Daten allerdings nie benötigt da externe Dienste wie Google Analytics zum Einsatz kommen.

Der Cronjob – ohne ihn geht nichts

Grundlegend für die fehlerfreie Funktion von Magento ist die Einrichtung des Cronjobs. Die Aufgabe eines Cronjobs ist es in regelmäßigen Abständen bestimmte Aufgaben zu erledigen, welche das im Detail sind könnt Ihr im Magento Wiki nachsehen. Neben den Standardaufgaben wie Newsletterversand, Index- und Sitemaperstellung führt das Script auch diverse Wartungsarbeiten aus. Wie Ihr einen Cronjob einrichtet erfahrt Ihr im Kundencenter.

Auf die richtigen Einstellungen kommt es an!

Nachdem der Cronjob eingerichtet wurde müssen wir noch einige Einstellungen im Magento Backend vornehmen. Das Menü zur Konfiguration der Log-Bereinigung findet Ihr unter:

System > Konfiguration > Erweitert > System > Log Bereinigung

Da der Vorgang je nach Datenmenge sehr viele Ressourcen beanspruchen kann sollte die Bereinigung in der Nacht erfolgen. Die Anzahl der Tage kann beliebig konfiguriert werden. – Je kürzer desto besser! 🙂

Magento Log Bereinigung

Einstellungen der Log-Bereinigung in Magento

Sobald der Cronjob eingerichtet und die Einstellungen vorgenommen wurden ist alles korrekt konfiguriert, in der folgenden Nacht startet der Job pünktlich seine Arbeit und räumt Eure Magento Datenbank gründlich auf.

In der nächsten Folge (Magento Datenbank Optimierung – Teil 2) erklären wir die komplette Deaktivierung der Log-Funktion und zeigen euch wie ihr die Datenbank weiter aufräumen könnt.