We are in the process of migrating this forum. A new space will be available soon. We are sorry for the inconvenience.

Classic Volume/High Speed Volume - technische Fragen


uisge
08.12.16, 17:32
Zitat Zitat von jayR
IPv6 habe ich nicht getestet, in der Übersicht waren nur IPv4 Adressen sichtbar. Aber das muss nichts heißen, bei den Cloud 2016 VPS Angeboten wurde im Interface lange IPv6 nicht angezeigt, war aber verfügbar.

Wenn du ein paar Cent übrig hast starte einfach mal eine Instanz und schau mal was ifconfig sagt, dann weißt du genau bescheid..
Ja, das werde ich dann wohl tun :-)

Schade mit den High-Speed-Volumes, das. Sehe ich auch so.

Nun ja, danke nochmals

jayR
08.12.16, 16:30
Nein, leider lassen sich High-Speed-Volumens nicht an mehrere Server anbinden, zumindest habe ich bei der Einrichtung der Testumgebung keine Option gefunden, weswegen ich dann die Tests mit ein paar "normalen" vServern vorgenommen habe. Der gemeinsame Netzwerkspeicher wurde von einem Windows Server bereitgestellt.

Das ist übrigens total Schade, bestellbarer HA - Netzwerkspeicher wäre einfach super.

IPv6 habe ich nicht getestet, in der Übersicht waren nur IPv4 Adressen sichtbar. Aber das muss nichts heißen, bei den Cloud 2016 VPS Angeboten wurde im Interface lange IPv6 nicht angezeigt, war aber verfügbar.

Wenn du ein paar Cent übrig hast starte einfach mal eine Instanz und schau mal was ifconfig sagt, dann weißt du genau bescheid..

uisge
07.12.16, 18:40
Zunächst einmal: herzlichen Dank für deinen ausführlichen Bericht. Sehr interessant. Sehr hilfreich.

Ich plane, von meinen dedizierten OVH-Servern, die sich größtenteils langweilen, da überdimensioniert, auf Public Cloud Server umzusteigen. Eine meiner Fragen hast Du bereits indirekt beantwortet: man kann ein High Speed Volume an mehrere Server anbinden. Die Performance interessiert mich hier weniger, da es mir eher um Backup-Bereich ginge.

Eine letzte Frage hätte ich noch an Nutzer der Public Cloud. Gibt es dort mittlerweile IPv6? [1] Ein Fehlen ist für mich der Show Stopper schlechthin.

[1] Ich weiß, es ist günstig mal kurz eine PC zu testen, aber Fragen geht schneller :-)

Schon einmal besten Dank im Voraus.

jayR
07.12.16, 18:03
Erfahrungen
Der Beitrag ist etwas her und ich hab mir inzwischen eine Testumgebung zusammen gebastelt. Hier die Ergebnisse.

Da die Blackfriday Angebote nicht mit der Public Cloud vereinbar waren - was wirklich sehr Schade ist, mal schauen was ich jetzt mit den nutzlosen zusätzlichen vServern mache - musste eine andere Lösung her.

Hierbei diente ein Windows Server mit aktivierter NFS Freigabe des webroots und der Konfigurationsdateien für nginx sowie php7-fpm inkl conf.d bzw. pool.d Verzeichnisse.
Als Vergleich diente ein weiterer vServer mit der gleichen Konfiguration, allerdings waren alle Daten lokal gespeichert.

Über verschiedene Anwendungen hinweg (CMS, Forensoftware, Bildergalerie) habe ich die PHP Laufzeiten, TTFB und Übertragungsraten von 1 MB, 10 MB und 100 MB (gemessen von einem weiterem Server im OVH Netzwerk) großen Dateien getestet. Nginx durfte nichts cachen.

Erster Test: NFS gegen Lokale Platte
Das Ergebnis war eindeutig:

Ohne NFS war TTFB um bis zu 50% kürzer, die PHP Laufzeiten waren im Mittel 30% schneller. Bei mehreren Anfragen auf die gleiche Datei machten sich dann aber die Linux internen Cachingmaßnahmen bemerkbar.
Die Übertragungsraten der größeren Dateien waren fast ähnlich, der Datendurchsatz von NFS ist sehr gut.

Insgesamt habe ich das auch so erwartet, war aber mit dem Ergebnis natürlich unzufrieden.

Erste Optimierung: filechacesd
Daher habe ich filecachesd eingerichtet. filechacesd ist ein Tool, welches Dateien von einem Netzwerkshare lokal speichert. Die Test sahen sehr vielversprechend aus, allerdings erzeigte filechacesd irgendwann 100% CPU Last, immer dann wenn der Chance fast voll war und eigentlich mit den Aufräumungarbeiten (Cache leeren) begonnen werden wollte.

Ein größere Cache hätte eventuell geholfen. Aber ich wollte bewusst nur 20% Cache Größe des NFS bereitstellen. Hat man mehrere größere Internetseiten mit Bildern und Videos kommt man schnell auf mehrere 100 GB, da reichen die 200/400 GB einer EG-15 nicht mehr aus. Also fällt filecachesd trotz vielversprechender Performance und simpler Konfiguration raus.

Zweite Optimierung: NGINX/ OPCache
Das Hauptproblem von NFS ist nicht der Durchsatz sondern die Zugriffsdauer. Große Dateien über 1 MB müssen nicht optimiert werden, es geht hier hauptsächlich um html, css, js sowie kleine png/jpgs die zum design der Seite gehören. Die müssen so schnell wie möglich an den Client. Da ich ohnehin den NGINX verwende, kann ich auch die sehr guten und detailliert konfigurierbaren Caching-Mechanismen nutzen. Gesagt getan, NGINX darf sich alles schnappen und lokal vorhalten.

Natürlich muss man gut abwägen, wie lange man die Daten cacht, sonst wundert sich der Webdesigener warum der heringefrickelte CSS Patch nicht funktioniert. Aber das ist eine ganz andere Geschichte.

Bleibt noch das Sorgenkind PHP. Denn die höheren Zugriffszeiten machen sich insbesondere bei vielen includes bemerkbar. Es kann durchaus sein, dass für eine Seite dutzende PHP Dateien angefragt werden müssen. Selbst das Systeminterne Caching kommt da oft nicht mit, vor allem weil die Daten oft nur sehr kurz zwischengespeichert werden.

Allerdings liefert PHP ab Version 5.5 OPcache mit, welches aber standardmäßig deaktiviert ist. OPCache liest das PHP Script und alle includes ein und kompiliert das Script. Diese kompilierten Scripte werden dann in einem Cache abgelegt. Damit profitiert man sogar in zweifacher Hinsicht: Die höheren NFS Zugriffszeiten werden umgangen und PHP wird noch mal spürbar schneller.

Allerdings muss man mit der Konfiguration vorsichtig sein, "mal eben schnell was im Script anpassen" klappt unter Umständen nicht mehr. (Sollte im Produktiveinsatz eh Tabu sein, wir wissen aber alle: Sowas kommt vor...)

Zweiter Test: NFS (optimiert) gegen Lokale Platte
Nun tritt die Lösung NFS+ NGINX-Caching + PHP Opcahe gegen den normalen Webserver an und wie zu erwarten: Die optimierte Variante wischt mit dem normalem Webserver den Boden auf:

TTFB war minimal besser, PHP legt richtig zu: Manche Seiten steigerten sich von 1,67s execution time auf 0,86 Bei anderen Seiten waren ordentliche 40-80% drin.

Inzwischen habe ich das caching von nginx wieder deaktiviert und cloudflare vorgeschaltet. Der PHP Opcache muss alle 120s den Cache erneuern. So können Änderungen schnell durchgeführt werden und der Performance Verlust hält sich in Grenzen. Testumgebungen können auch auf dem gleichem System laufen, man kann in der Konfiguration vom OPCache Verzeichnisse ausschließen.

So kann direkt auf den Live Servern entwickelt werden, man sparrt sich zusätzliche Tests in der Liveumgebung. (Natürlich mit einer kopierten Version der Orginalseite!) Zudem kann man beliebig weitere Webserver hinzufügen, IP bzw. DNS Loadbalancing sei Dank. Die Kofnigurationsdateien und das webroot liegen ja auf einem NFS. Mit einem kleinem bash script sind neue Server extrem schnell eingerichtet (apt-get hier und da, symlink auf die config files).

Ich danke an der Stelle OVH für die wirklich günstigen vServer die dazu einladen, sich privat weiterzubilden. Die gewonnen Erfahrungen werde ich mit in die Firma nehmen, bei der man überlegt, ob man bei einem Hoster der neuerdings einem amerikanischem Unternehmen gehört wirklich bleiben möchte.

jayR
02.10.16, 22:27
Hallo zusammen!

Mir die Public Cloud Angebote eigentlich sehr fair, aber bevor ich mich zu weiteren Schritten entscheide, hab ich noch ein paar Fragen:

Kann ich das High-Speed Volume auch an mehrere Server anbinden?
Wenn ja wie schaut es generell mit der Performance aus?
Steckt da VMware Virtual SAN hinter, welches Protokoll wird verwendet?

Um die Frage zu konkretisieren:

nginx und php-fpm sollen auf unterschiedlichen Servern laufen, das Szenario sähe dann so aus:
1x nginx mit memcahe sowie 2x php-fpm.
Auf allen drei Servern müssen natürlich die gleichen Daten liegen. Ich würde gerne auf das synchronisieren verzichten und die Webseiten nur auf dem High Speed Volume speichern. In einer Testumgebung habe ich aber die Erfahrung gemacht, dass bei der Kombination PHP und NFS zu starken Performanceeinbrüchen kommt. Bei einem vSAN angebundenen System mach ich mir weniger Gedanken als über NFS angebundener Storage. Haben die Hosts der public cloud eine dedizierte Anbindung an den Storage? Wäre ja blöd wenn webtraffic, php-fpm traffic, mysql und Storage über eine NIC läuft.

Die endgültige Version sieht dann in etwa so aus:
Loadbalancer IP (Rechenzentrumsübergreifend)
->
2-n niginx webserver (EG-7)
->
2-n php-fpm server (HG-7)
->
Loadbalancer IP (Rechenzentrumsübergreifend)
->
4-n Galera Cluster + Memchache (SP-30)

Das ganze an zwei Standorten, wobei je 2 Galera Server in einem RZ stehen sollen. Unter hoher Last sollen dann n Server zugeschaltet werden.

Ich freue mich auf Antworten (ist nicht dringend, es geistert nur eine Idee in meinem Kopf herum, deren technische Umsetzung ich gerne prüfen möchte)