Redundante Infrastruktur

Das wichtigste Konzept der Ausfallsicherheit von IT-Systemen ist und bleibt die Redundanz. Sämtliche Hardwarekomponenten sind mehrfach vorhanden, um defekte Teile sofort überbrücken zu können. Dazu wird zunächst eine leistungsfähige Enterprise Plattform benötigt, die ausreichende Hardwareressourcen zur Verfügung stellt, um einzelne Ausfälle ohne Einbußen bei der Performance kompensieren zu können. Eine redundante Infrastruktur ist jedoch deutlich mehr als nur ein Ersatzteillager. Redundanz bedeutet in der IT, dass defekte Komponenten ohne Betriebsunterbrechung automatisch überbrückt werden. Dazu muss nicht nur die Hardware redundant ausgelegt sein, sondern auch alle Daten und laufenden Prozesse müssen dupliziert werden. Ein angenehmer Nebeneffekt der Redundanz besteht darin, dass sämtliche Daten auch zwischen den Datensicherungen mehrfach vorhanden sind. Somit sind im Ernstfall auch neue Kundendaten, die seit der letzten Sicherung gespeichert wurden, nicht verloren. Natürlich ist die alte Regel, dass redundante Datenträger kein Backup ersetzen, weiterhin uneingeschränkt richtig. Aber redundante Datenträger können so manches Rollback ersparen, das immer mit Datenverlusten verbunden ist. Magento verfügt zwar über eine sehr gute Rollback-Funktion – aber nutzen möchte man sie doch lieber nicht!

Cloudhosting ist den Alternativen überlegen

Über welche Alternativen müssen wir hier überhaupt sprechen? Sicher nicht über den selbst betriebenen Server. Dieser Weg kommt allenfalls für große Unternehmen mit eigenem Rechenzentrum in Betracht. Für die Mehrzahl der Shopbetreiber kommt jedoch der interne Serverbetrieb ohnehin nicht infrage, weswegen die einzige wirkliche Alternative in der Anmietung eines realen Servers statt eines virtuellen Servers besteht. Das Rechnen in der Cloud kann in diesem Vergleich auf zahlreiche Vorteile verweisen. Hardwareressourcen unserer Enterprise Plattform können jederzeit bedarfsgerecht zugewiesen werden, außerdem garantieren wir in unserem Paket VMWare Gold eine extrem hohe Verfügbarkeit von 99,99 Prozent, die durch die Redundanz der Plattform ermöglicht wird. Der Unterschied zwischen 99,9 Prozent und 99,99 Prozent Verfügbarkeit ist übrigens keine reine Zahlenspielerei, an der nur Nerds ihren Spaß haben. Dieser Unterschied bedeutet knapp acht Stunden weniger Ausfallzeit pro Jahr – wie viele Kundenkontakte sind das bei Ihnen? Diesen zahlreichen Vorteilen steht als einzige Einschränkung gegenüber, dass das managed Cloudhosting keinen Root Zugriff erlaubt. Für Softwareentwickler kann das ein Problem sein, aber kaum für einen Shopbetreiber. Dafür werden Sicherheitsupdates im Betriebssystem automatisch eingespielt.

Einige Worte zur Datensicherheit

Nicht zuletzt durch eine indifferente Berichterstattung der Medien wird allein schon der Begriff „Cloud“ oft mit Datenschutzproblemen assoziiert. Bei genauerem Hinsehen wird schnell klar, dass die meisten der bekannt gewordenen Probleme nicht technischer Natur sind. Problematisch ist eher, dass viele große Anbieter amerikanischem Recht unterliegen und daher den US-Behörden Hintereingänge öffnen müssen. Aus technischer Sicht bieten professionelle Rechenzentren zweifelsohne einen besseren Schutz gegen externe Angriffe, als ein normales Unternehmen selbst gewährleisten könnte. Mit Cloud oder Nicht-Cloud hat das Ganze wenig zu tun, sondern nur mit können und wollen!

The post Vorteile einer Cloudumgebung für Magento appeared first on LCube - Professional Hosting Blog.

Da dies eien sehr allgemeine Aussage ist, klärte der zuständige Mitarbeiter erstmal mit dem Kunden ab, wie sich das Geschwinigkeitsproblem äussert.

Trotz Varnish Cache, Memcached, APC kam es zu gelegentlichen hängern, die teilweise sogar die Datenbank lahm legten.

Bei einem Magento Hosting kommt es auf das Zusammenspiel aller Komponenten an

Die Analyse ergab, dass das Problem regelmäßig auftrat. Nach einiger Zeit kam es zu einem Stillstand des MySQL Servers da dieser mit Anfragen auf die Tabelle category_catalog_flat_store so beschäftigt war, dass er keine anderen Anfragen beantworten konnte. Die Laufzeiten für die Abfrage steigerte sich von 1,5 Sekunden auf teilweise über 100 Sekunden.

Der Varnish Cache hat zwar einiges puffern können jedoch ist auch der Cache irgendwann abgelaufen. In dem Fall wird dann die Seite neu berechnet. Wenn die Trägheit z.B. durch ein aufwändiges Menü erzeugt wird, muss das Menü für alle Benutzer, die in dem Augenblick online sind, neu berechnet werden. So kann es auf einen Schlag zu 20, 30 oder mehr aufwenigen Abfragen kommen. Wenn diese Abfragen dann lange dauern potenziert sich das Problem. Während der DB Server damit beschäftigt ist, laufen neu Abfragen auf, die dann in der Queue landen. So läuft innerhalb von wenigen Sekunden die Datenbank voll, bis nichts mehr geht.

Es wurden dann falsche Indexfelder in der category_catalog_store_flat Tabelle sowie der core_url_rewrites ausgemacht, die Abfragezeiten von mehreren Sekunden erzeugten. Nach dem Zurücksetzen der Indexfelder war die Laufzeit wieder bei wenigen Millisekunden.

Der Kunde bemerkte zwar die Verbesserung bemängelte jedoch weiterhin eine Trägheit, die zwar nicht mehr so schlimm war aber trotzdem nicht in Ordnung.

Oftmals befinden sich im Magento Store mehrere Fehler

Nachdem das Laufzeitverhalten mit NewRelic weiter analysiert wurde konnten am Quellcode und ind er Datenbank keine Probleme gefunden werden.

Das finden mehrere Fehler macht die Analyse immer sehr schwierig. Man hat einen Fehler gefunden und kommt nicht zum erwünschten Ziel. Es erfordert dann viel Erfahrung um trotzdem Fehler für Fehler zu finden.

Nachdem als zusätzliche Fehlerquelle der Memcached identifiziert wurde, und dieser neu gestartet wurde war das Problem jedoch behoben. Magento hat offensichtlich etwas im Memcached abgelegt was zu langen Laufzeuten geführt hat.

The post Magento Hosting ist sehr langsam appeared first on LCube - Professional Hosting Blog.

Der Geschwindigkeitsvorteil kann je nach verwendeten Backend ein vielfaches betragen da Webseiten nicht bei jedem Abruf berechnet sondern statisch ausgeliefert werden.

Gerade im Bereich von Magento Hosting und Shop Hosting wird er sehr häufig eingesetzt.

Ich möchte hier einmal zeigen, wie man den Cache in einer Plesk Umgebung installiert.

Er wird als Daemon installiert und zwischen Webserver und Benutzer gehängt. Seiten werden entweder aus dem Cache geladen oder vom Webserver (Backend Server) abgerufen.

Um den Varnish im Plesk einzubinden sind einige Schritte erforderlich.

1. Installation des Varnish Caches
2. Erstellen einer custom Konfiguration im Plesk (CentOS: /usr/local/psa/admin/conf/templates/custom)

Installation des Varnish Caches für das Magento Hosting

Der Varnish Cache ist auf einem RH/CentOS sehr einfach installiert:

rpm --nosignature -i https://repo.varnish-cache.org/redhat/varnish-3.0.el6.rpm
yum install varnish

Dadurch wird der Varnish in der Version 3 installiert.

Vorsicht: Sofern andere Respoitory Varnish zur Verfügung stellen sollte mit yum priorities eine Reihenfolge festgelegt werden.

/etc/varnish/default.vcl:

backend default {
 .host = "127.0.0.1";
 .port = "7080";
}

/etc/sysconfig/varnish:

# Configuration file for varnish
 #
 # /etc/init.d/varnish expects the variable $DAEMON_OPTS to be set from this
 # shell script fragment.
 #

 # Maximum number of open files (for ulimit -n)
 NFILES=131072

 # Locked shared memory (for ulimit -l)
 # Default log size is 82MB + header
 MEMLOCK=82000

 # Maximum size of corefile (for ulimit -c). Default in Fedora is 0
 # DAEMON_COREFILE_LIMIT="unlimited"
 # Set this to 1 to make init script reload try to switch vcl without restart.
 # To make this work, you need to set the following variables
 # explicit: VARNISH_VCL_CONF, VARNISH_ADMIN_LISTEN_ADDRESS,
 # VARNISH_ADMIN_LISTEN_PORT, VARNISH_SECRET_FILE, or in short,
 # use Alternative 3, Advanced configuration, below
 RELOAD_VCL=1

 #
 # See varnishd(1) for more information.
 #
 # # Main configuration file. You probably want to change it :)
 VARNISH_VCL_CONF=/etc/varnish/default.vcl

 #
 # # Default address and port to bind to
 # # Blank address means all IPv4 and IPv6 interfaces, otherwise specify
 # # a host name, an IPv4 dotted quad, or an IPv6 address in brackets.
 #VARNISH_LISTEN_ADDRESS=127.0.0.1
 VARNISH_LISTEN_PORT=6081

 #
 # # Telnet admin interface listen address and port
 VARNISH_ADMIN_LISTEN_ADDRESS=127.0.0.1
 VARNISH_ADMIN_LISTEN_PORT=6082

 #
 # # Shared secret file for admin interface
 VARNISH_SECRET_FILE=/etc/varnish/secret

 #
 # # The minimum number of worker threads to start
 VARNISH_MIN_THREADS=100

 #
 # # The Maximum number of worker threads to start
 VARNISH_MAX_THREADS=2500

 #
 # # Idle timeout for worker threads
 VARNISH_THREAD_TIMEOUT=120

 #
 # # Cache file location
 VARNISH_STORAGE_FILE=/var/lib/varnish/varnish_storage.bin

 #
 # # Cache file size: in bytes, optionally using k / M / G / T suffix,
 # # or in percentage of available disk space using the % suffix.
 VARNISH_STORAGE_SIZE=10G

 #
 # # Backend storage specification
 #VARNISH_STORAGE="file,${VARNISH_STORAGE_FILE},${VARNISH_STORAGE_SIZE}"
 VARNISH_STORAGE="malloc,2G"

 #
 # # Default TTL used when the backend does not specify one
 VARNISH_TTL=600

 #
 # # DAEMON_OPTS is used by the init script.  If you add or remove options, make
 # # sure you update this section, too.
 DAEMON_OPTS="-a ${VARNISH_LISTEN_ADDRESS}:${VARNISH_LISTEN_PORT} \
 -f ${VARNISH_VCL_CONF} \
 -T ${VARNISH_ADMIN_LISTEN_ADDRESS}:${VARNISH_ADMIN_LISTEN_PORT} \
 -t ${VARNISH_TTL} \
 -w ${VARNISH_MIN_THREADS},${VARNISH_MAX_THREADS},${VARNISH_THREAD_TIMEOUT} \
 -u varnish -g varnish \
 -S ${VARNISH_SECRET_FILE} \
 -s ${VARNISH_STORAGE} \
 -p session_linger=50 \
 -p cli_buffer=10000 \
 -p sess_workspace=262144"

Erstellen einer custom Konfiguration für Plesk

Damit der Webserver von Plesk die Daten vom Varnish abruft und nicht direkt vom Webserver ist eine Konfigurationserweiterung notwendig.

Plesk ist standardmäßig so konfiguriert, dass eingehende Verbindungen vom NGinx Reverseproxy entgegen genommen werden.

Nginx liefert lokale Dateien ggf. direkt aus und übergibt weiter Anfragen an den Apache Server, welcher i.d.R. auf Port 7080 horcht. Hier klinken wir uns ein und schieben dem System den Varnish Cache unter.

Im Ordner custom können eigene Konfigurationen abgelegt werden, die Plesk statt der eigenen verwendet.

Kopieren Sie die default/nginx.php aus dem default in den custom Ordner.

Bearbeiten Sie die Datei custom/nginx.php und fügen oben (Zeile 3) zwischen den beiden PHP Zeilen den upstream backend_varnish ein:

<?php echo AUTOGENERATED_CONFIGS; ?>

upstream backend_varnish {
 server 127.0.0.1:6081;
 server [lokale ip adresse]:7080 backup;
}

<?php /** @var Template_VariableAccessor $VAR */ ?>

[lokale ip adresse] ersetzen Sie bitte durch die Adresse, über die Ihre Webseite erreichbar ist.

Der Upstream Server dient nun als Deklaration, woher der NGinx seine Daten bekommen soll, sobald er als proxy_pass den Namen des Upstreams übergeben bekommen hat.

Sollte der Varnish Cache mal nicht Online sein, verwendet NGinx den Apache Server da dieser als Backup Verbindung hinterlegt ist.

Kopieren Sie die default/domain/service/proxy.php Datei in den custom/domain/service Ordner.

Bearbeiten Sie diese nun wie folgt (custom/domain/service/proxy.php):

<?php
/**
 * @var Template_VariableAccessor $VAR
 * @var array $OPT
 */
?>
<?php if ($OPT['ssl']) { ?>
        proxy_pass https://<?php echo $OPT['ipAddress']->proxyEscapedAddress . ':' . $OPT['backendPort'] ?>;
<?php } else {
        if (file_exists("/etc/varnish/".$VAR->domain->asciiName.".enable")) {
?>
            proxy_pass http://backend_varnish;
<?php
        } else {
?>
        proxy_pass http://<?php echo $OPT['ipAddress']->proxyEscapedAddress . ':' . $OPT['backendPort'] ?>;
<?php
        }
?>
<?php } ?>
        proxy_set_header Host             $host;
        proxy_set_header X-Real-IP        $remote_addr;
        proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
<?php if (!$VAR->domain->physicalHosting->proxySettings['nginxTransparentMode'] && !$VAR->domain->physicalHosting->proxySettings['nginxServeStatic']): ?>
        proxy_set_header X-Accel-Internal /internal-nginx-static-location;
<?php endif ?>
        access_log off;

An der file_exists Funktion läßt sich gut sehen, dass das Script erst prüft, ob eine Datei im /etc/varnish ordner liegt, die als Namen den Domainnamen gefolgt von .enable hat (z.B. lcube-webhosting.de.enable). Ist dies der Fall wird der Varnish aktiviert. Wenn nicht, werden die Dateien normal vom Webserver abgerufen. Auf diese Weise kann der Varnish durch setzen einer Datei aktiviert oder deaktiviert werden.

Nach dem setzen oder löschen der enable Datei muss

/usr/local/psa/admin/bin/httpdmng --reconfigure-all

ausgeführt werden.

Ggf. muss ein Addon installiert werden. Für Magento kommt z.B. Turpentine in Frage.

Nicht für jede Anwendung ist der Varnish Cache geeignet. Wenn viele Dynamische Daten abgerufen werden und die Aktualität der Daten von entscheidender Bedeutung ist (z.B. bei Warenkörbe sowie beim SVN Hosting oder Git Hosting) sollte man entsprechende URLs in die Ausnahmen eintragen bzw. auf Varnish verzichten.

The post Magento Hosting mit Plesk 11.5, Apache, Nginx und Varnish Cache appeared first on LCube - Professional Hosting Blog.