Keine ahnung ob es "KVM processor pinning" heißt,das sollte es aber sein
D.h. ich habe 4x 2.0GHz exklusiv in dieser VM?
Keine ahnung ob es "KVM processor pinning" heißt,das sollte es aber sein
D.h. ich habe 4x 2.0GHz exklusiv in dieser VM?
Hallo zusammen,
bei den "Root-Servern" wird KVM mit einer Prozessorkernanzahl angegeben:
Meine Frage ist: Sind diese (beim RootServer XL v2) 4 Kerne denn komplett auf mich reserviert (KVM processor pinning) oder sind dies virtuelle Kerne, welche ich mir mit anderen Nutzern teilen muss(KVM virtual processor)?
Vielen Dank
Leider komme ich im Moment wenig zum schreiben, sonst würde ich ne bessere Version nachschieben, aber das sollte in ca. 2 Wochen vorbei sein.
Zu einigen Sachen oben möchte ich trotzdem was schreiben, auch wenn es sicher schon ein paar Tage her sein mag
@Slavit: Bei den KVM Servern: Ja, im Prinzip schon, aber bei wenigen Kernen kann man auch von dieser groben Maßgabe abweichen
Es ist nur folgendes wichtig: Man sollte sich im klaren sein, dass ein Linux-Server jedem Prozess/Thread möglichst gleich viel Rechenzeit geben möchte(sog. Scheduling). Hat man pro Kern also 10 Threads, bekommen alle 10 nur jeweils 1/10 der Rechenzeit. D.h. man hat de facto keinen Performancegewinn gegenüber 5 Threads(zumindest nicht spürbar), welche jeweils 1/5 der Rechenzeit bekommen. Der Vorteil an der einstellbaren Threadanzahl sind die "ganz normalen" vServer von netcup: Da man bis zu 24 Prozessorkerne nutzen kann, kann man auch 24 Kernen Aufgaben zuweisen für maximale Parallelität und kein Kern ist untätig.
Bei deinem KVM Server würde ich eine Threadanzahl zwischen 2 und 6 empfehlen. Weniger macht keinen Sinn, da sonst ein Kern nicht ausgelastet wäre, mehr auch nicht, da sich die nginx Threads sonst dank Linux-Scheduling selbst im Weg sind(zumindest, wenn du nicht grade planst, einen riesigen Internetauftritt zu hosten).
Zu den Werten für die Performance:
pm.max_children = 9
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 200
Die Schalter müssten, wie bereits erwähnt, schon in den Pool-Dateien stecken, wenn nicht schreib sie da einfach rein
Wobei ich über gute und schnelle Konfiguration sowieso noch ein Howto machen würde.
Dieses war dediziert eigentlich nur zur Einrichtung da
Das mit dem Socket war ja dann auch schon geklärt
Wisst ihr wie/ob man hier als Kunde denn was ins Netcup Wiki schreiben kann?
\TIA
Dankeschön
Leider kann ich den Vorschlag mit dem Socket nicht einarbeiten, da ich den Beitrag ned mehr editieren kann
Danke für den Tipp
Sonst noch irgendwas verbesserungswürdiges entdeckt?
5.) SSL
5.1) Voraussetzungen
Es muss bereits ein gültiges SSL-Zertifikat vorhanden sein! Wie man kostenlos an ein SSL-Zertifikat kommt, das immerhin ein Jahr lang gültig ist, erklärt Heise Security sehr schön:
SSL für lau | heise Security
(Natürlich nur bis zu dem Punkt, wo man alle Zertifikate runterlädt; Das Einspielen in den Apache ist für uns natürlich nicht wichtig)
Und wem das ein wenig zu schnell ging, findet hier noch eine etwas ausführlichere Anleitung:
SSL für lau Kostenlose Zertifikate einrichtenLazybone | Lazybone
Ich gehe von folgendem Start-Szenario aus:
Im HOME Ordner eures Benutzers liegen folgende Zertifikatsdateien(hier wieder am beispiel.de):
Die CertificateChain für StartSSL bekommt ihr übrigens unter
Index of /certs , die Datei heißt "sub.class1.server.ca.pem"
Jetzt müssen wir noch einen letzten Schritt durchführen, bevor wir die Zertifikate an die passenden Stellen kopieren können:
Wirmüssen an unser Server-Zertifikat (beispiel.de.crt) noch die sog. Authentifizierungskette(CertificateChain) anhängen, dass auch nachvollzogen werden kann, dass unser Zertifikat von ihr kommt. Das erledigt folgender Befehl und speichert das entstehende Zertifikat als "beispiel.de.chained.crt"
Passt in diesem Befehl die Dateinamen euren einfach an.
Wichtig:
Die Reihenfolge darf nicht vertauscht werden, sonst wirft nginx beim
starten einen Fehler. Sie muss immer folgendem Muster folgen:
Die CertificateChainFile kann verschiedene Endungen besitzen, am Gebräuchlichsten sind ".crt" und ".pem"
Habt ihr diese Datei hergestellt, erstellt folgende Ordner:
Kopiert in "/etc/ssl/certs" folgende Dateien: "beispiel.de.crt", "beispiel.de.chained.crt". "sub.class1.server.ca.pem"
Kopiert in "/etc/ssl/certs" folgende Datei: "beispiel.de.key"
Das wars, jetzt müssen wir nginx nur noch beibringen, diese Zertifikate auch zu verwenden.
5.2) nginx und SSL
Der Beispiel vHost, welcher uns schon bekannt ist, jetzt aber sowohl http-, als auch https-Verbindungen unterstützt:
#vHost Configuration File:
#vHost: beispiel.de, SSL Enabled
server {
listen 80;
listen 443 default ssl; ##HTTPS Access
server_name beispiel.de www.beispiel.de;
ssl_certificate /etc/ssl/certs/beispiel.de.chained.crt; #Public Key incl. CertificateChain
ssl_certificate_key /etc/ssl/private/beispiel.de.key; #Private Key
access_log /var/log/nginx/beispiel.de.access_log;
error_log /var/log/nginx/beispiel.de.error_log;
root /var/www/beispiel.de;
index index.php index.htm index.html;
location ~ .php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/beispiel.de$fastcgi_script_name;
include fastcgi_params;
}
location ~ /\. {
deny all;
}
}
Alles anzeigen
Die Parameter die neu dazukamen, wurden entsprechend Kommentiert.
Um die Änderungen zu Übernehmen, muss nginx neugestartet werden.
5.3) Troubleshooting
Wenn nginx mit folgender Fehlermeldung versagt, wurden die Parameter beim generieren der CertificateChainKeyFile vertauscht, die Datei beispiel.de.chained.crt ist also falsch:
SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed
(SSL: error:0B080074:x509 certificate routines:
X509_check_private_key:key values mismatch)
Bei diesem Schritt muss die Reihenfolge genau eingehalten werden.
6) Testen:
Jetzt können wir die Umgebung testen. Dazu müssen alle installierten und konfigurierten Server gestartet werden.
Dann erstellen wir im Verzeichnis der Website (hier: /var/www/beispiel.de/) die Datei index.php
Und füllen sie mit folgendem Inhalt:
Jetzt müssen wir sie nur noch dem passenden Nutzer zuordnen, sodass nginx auch darauf zugreifen kann:
Dieser Befehl setzt im ganzen Ordner /var/www/beispiel.de die Zugriffsrechte
passend, sodass nginx, der unter www-data läuft darauf zugrifen kann.
Startet jetzt nginx neu.
Jetzt kann man im Browser auf seine Domain gehen(hier Beispiel.de) und bekommt eine PHP-Info Seite angezeigt. Wenn man "https://beispiel.de" besucht, so sollte die Verbindung mit https gesichert sein. Bekommt man eine Warnung, dass das Zertifikat nicht verifiziert werden kann und aus einer unbekannten Quelle stamme, so hat dies eine(oder beide) der beiden Ursachen:
Um das erstere zu Beheben musst du die Schritte oben zum Einbinden wiederholen oder diverse Suchmaschinen/Foren bemühen. Das zweite ist ein anderes Problem: In gängigen Browsern werden nur Zertifikate von großen CA´s akzeptiert. Eigene CA´s / kleine CA´s produzieren eine Sicherheitswarnung. Jedoch kannst du in deinem Betriebssystem das
Zertifikat der CA installieren, dann wird von diesem Rechner der CA ebenfalls vertraut. Auch hierfür konsultierst du am besten eine Suchmaschine/ ein Forum.
Nach einem erfolgreichen Test sollte die Datei in
umgeändert werden, da der phpinfo(); Befehl sehr viel über das installierte PHP System preisgibt.
Wenn ihr die Datei jetzt mit root Rechten geändert habt, müsst ihr nocheinmal obigen "chown befehl" ausführen!
Das wars, ihr habt jetzt ein fertiges und schnelles System, das noch dazu wenig Ressourcen braucht. Glückwunsch!
Ich hoffe, dieses Howto hat ein wenig Licht in die Lage nginx/SSL gebracht und dem ein oder anderen geholfen.
PS: Bestünde Interesse an einem Howto über PHP Beschleuniger?
4.)nginx
Kommen wir nun zum Sahnehäubchen: Dem Webserver nginx, also dem Herzstück unserer LEMP Umgebung.
Installation:
Starten/Stoppen lässt sich nginx wie auch die anderen Serverdienste per init-Skript, es liegt unter /etc/init.d/nginx
Die Konfigurationsdatei von nginx liegt unter /etc/nginx/nginx.conf
Folgende, wichtigste Einstellungen solltet ihr an euer System anpassen:
user www_data; #Unter welchem Nutzer soll nginx laufen? Default & empfohlen: www-data
worker_processes 5; #Wieviele Prozesse darf nginx spawnen? Empfohlen: 12-24, maximal jedoch soviele wie Prozessoren im System verbaut sind.
worker_connections 1024; #Legt fest, wieviele Verbindungen pro Prozess erlaubt sind. Maximale Verbindungen von nginx: worker_processes * worker_connections
access_log /var/log/nginx/access.log; #Speicherort des Globalen Zugriffslogs, sollte in /var/log/nginx liegen
Alles anzeigen
Das war die Serverkonfiguration. Jetzt müssen die sog. Virtual-Hosts konfiguriert werden.
Ein vHost(Virtual-Host) repräsentiert quasi einen virtuellen Webserver, sodass ein nginx Server mehrere Seiten hosten kann.
Weitere infos: Virtual Hosting – Wikipedia
Dafür gibt es zwei ordner:
Sämtliche vHosts werden in "sites-available" erstellt und dann eine Verknüpfung auf sie in "sites-enabled" angelegt.
Zuersteinmal wollen wir den "Default" loswerden, lösche also dazu die Verknüpfung:
Erstellt jetzt eine Datei, die wie eure Domain heißt im Ordner "sites-available" mit folgendem, angepasstem Inhalt:
#vHost Configuration File:
#vHost: beispiel.de
server {
listen 80; ##Der Port, HTTP benötigt Port 80
server_name beispiel.de www.beispiel.de; ##Auf welche Domains soll der vhost "reagieren"
access_log /var/log/nginx/vleupi.de.access_log; ##Logfile für die Zugriffe
error_log /var/log/nginx/vleupi.de.error_log; ##Logfile für die Fehler
root /var/www/beispiel.de; ##Verzeichnis, in welchem die Website gehostet wird
index index.php index.htm index.html; ##Welche dateien zählen als index ?
###PHP Configuration
location ~ .php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/beispiel.de$fastcgi_script_name;
include fastcgi_params;
}
##Sperre zugriff auf versteckte Daten
location ~ /\. {
deny all;
}
}
Alles anzeigen
die Erklärungen zu den Werten sind als Kommentare in der Datei verfasst.
Diese Beispielkonfiguration "/etc/nginx/sites-available/beispiel.de" hostet z.B. die Seite "Beispiel.de" im Verzeichnis "/var/www/beispiel.de".
Um die Konfiguration anzuschalten, muss nun noch eine Verknüpfung im "sites-enabled" Ordner angelegt werden:
Dann muss nginx via init-Skript neugestartet werden.
Das schöne an nginx: Passt seine Konfiguration nich genau/ist stark unsicher, so verweigert er den Start. Startet nginx, habt ihr also alles richtig gemacht.
Wer eine Zugriffsverwaltung ala .htaccess umsetzen möchte, dem sei folgende Seite aus der nginx-Dokumentation ans Herz gelegt, welche das sehr schön erläutert:
HttpAuthBasicModule
[HOWTO] LEMP Stack + SSL - Debian 6.0
0.) Einleitung
0.1) Was ist das überhaupt? Ich kenne nur LAMP
Ein LAMP und LEMP Stack unterscheiden sich schon beim Hinsehen nur durch den 2. Buchstaben: A wird durch E vertauscht, doch was bedeutet das?
LEMP ist das selbe wie LAMP mit dem Unterschied, dass statt Apache (A) nun nginx(sprich: "engine-ex") also (E) verwendet wird.
0.2) Warum nginx?
Apache ist zwar der populärste Webserver, aber als eine Art eierlegende Wollmilchsau auch nicht gerade der performanteste. V.a. bei vServern stößt Apache schon bei kleinen/mittleren Seiten an die RAM-Limits der VM. nginx ist auch ein Webserver, jedoch ist er im Gegensatz zu Apache sehr leichgewichtig, schnell und Performant ausgelegt. Dies ist auch höchstes Ziel bei dessen Entwicklung. Trotzdem bietet nginx kaum Einschränkungen, was die Funktionalität angeht und auch seine Konfiguration ist der von Apache sehr ähnlich und unterscheidet sich nur in geringen Punkten.
0.3) Warum nehmen dann alle Apache, wenn nginx doch angeblich so viel besser ist?
Apache is der de-facto Standard: Sehr einfach zu konfigurieren, multiplattformkompatibel und ist praktisch in jeder Distribution dabei. Nginx ist weniger bekannt und gilt als schwer zu konfigurieren, was jedoch ein weit verbreiteter Irrglaube ist. Doch das wird im weiteren Verlauf offensichtlicher.
1.)Vorbereitungen / Voraussetzungen
1.1) Voraussetzungen:
1.2) Vorbereitungen:
Zuerst müssen wir noch eine sog. Fremdquelle hinzufügen. Leider haben es die aktuelle Version von "php5-fpm" und "nginx" nicht in die Debian-Pakete geschafft.
Daher empfehle ich, sie via Fremdquelle nachzurüsten. Dotdeb - The repository for Debian-based LAMP servers bietet aktuelle Pakete rund um LAMP auf Debian Servern an, unter anderem die von uns benötigten.
Disclaimer: Die Pakete dieser Fremdquelle sind nicht durch Debian.org/Netcup/mich geprüft! Pakete aus Fremdquellen können Schadsoftware enthalten und somit das System beschädigen! Installieren sie Pakete aus Fremdquellen nur, wenn sie diesen Quellen vertrauen. Die Installation erfolgt auf eine Gefahr!
Um dotdeb hinzuzufügen, sind folgende Zeilen an die /etc/apt/sources.list anzuhängen:
#Dotdeb.org LAMP Packages:
deb http://packages.dotdeb.org squeeze all
deb-src http://packages.dotdeb.org squeeze all
Zusätzlich muss noch der Schlüssel importiert werden, mit dem die Pakete der Quelle unterschrieben sind:
Um auf die neuen Pakete zugreifen zu können, müssen wir die Paketlisten neu laden:
Jetzt ist die Paketquelle eingebunden und wir können Software aus ihr installieren.
2.)MYSQL
Den MySQL Server installieren wir mit
Legt bitte während der Installation ein sicheres Passwort fest.
Die Standardkonfiguration ist bereits sehr sicher, da der Server nur auf Anfragen von localhost, also 127.0.0.1:3306 reagiert.
Wer sich mit den Einstellungen trotzdem vertraut machen möchte, kann einen Blick in die /etc/mysql/my.cnf wagen.
Dort kann man Port und weitere Einstellungen ändern.
Das init-Script für den MySQL Server liegt unter /etc/init.d/mysql
Wer seinen Server per GUI verwalten möchte, dem sei die "MySQL Workbench" ans Herz gelegt, diese ermöglicht eine Verwaltung und Zugriff über SSH, daher muss der Server nicht umkonfiguriert werden und steht weiterhin nur localhost zur Verfügung, was u.a. den höchsten Sicherheitsstandard darstellt.
Infos hierzu:MySQL :: MySQL Workbench :: 6.6.4 Standard TCP/IP over SSH Connection
Nutzer und Datenbanken anlegen ist nicht Gegenstand dieser Anleitung, diese Informationen liefert euch die Suchmaschine eures Vertrauens.
3.) PHP
PHP installieren wir via
:~$ sudo apt-get install php5 php5-fpm php-pear php5-common php5-mcrypt php5-mysql php5-cli php5-gd
Auch dieser Dienst bringt Standardmäßig schon gute Einstellungen mit.
Einige Werte möchte man aber doch verändern. Die Einstellungen für das Verhalten des PHP-FPM(FastCgi Process Manager, der Dienst, der PHP hier bereitstellt),
kann man in der Datei /etc/php5/fpm/php-fpm.conf beeinflussen.
Folgende Einstellungen sind sinnvoll:
Und das bedeuten sie: Die ersten beiden Werte geben das Verhalten im Notfall vor: Wenn 15 php prozesse in 1m(inute) mit SIGSEGV/SIGBUS beendet werden(abstürzen), so wird der php5-fastcgi dienst neu gestartet.(Empfohlen)
Die 3. Zeile legt die Zeit fest, wie lange php prozesse auf signale des "Master-Prozesses" warten dürfen.(Optional)
Um den FPM zu starten / stoppen bedienen wir uns dem folgenden init-Skript: /etc/init.d/php5-fpm
Jedoch möchten/müssen viele Admins Werte in der php.ini Datei verändern, um ihre Webanwendungen zu Betreiben.
Die php.ini liegt bei dieser Konfiguration unter /etc/php5/fpm/php.ini.
Es sei jedem angeraten die php.ini abzusichern, da sonst ungesicherte PHP-Skripte eine Schwachstelle bieten können. Eine passende Erklärung findet sich hier:
Die PHP.ini - PHP gegen Angriffe absichern
Es gibt zusätzlich die Möglichkeit, dem FPM anzugeben, wieviel RAM/prozesse er nutzen darf. Dies kann die Performance stark verbessern, sprengt jedoch den Rahmen dieses Howto´s.
Interessierte können sich einmal diese Werte ansehen:
pm.max_children = 9
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 200
Auch im Netz findet sich dazu einiges.