Ich habe versucht, alle Teile zusammenzutragen, um einen lastausgeglichenen Cluster aus drei Servern (zwei für Webknoten und einen für MySQL) als LAMP-Stack auf EC2 einzurichten. Dies dient nur dazu, Leistungstests für eine Anwendung durchzuführen, und ich muss die entsprechenden Informationen sammeln, damit ich den dafür benötigten Zeitaufwand abschätzen kann. Ich habe mich gefragt, ob mir jemand die Lücken zu Folgendem ausfüllen könnte:
Was genau ist eine Recheneinheit? Ich brauche drei gespiegelte Instanzen von RightScales AWS CentOS, zwei als Webknoten und eine mit einer Datenbank. Brauche ich dann drei kleine Instanzen?
Wenn ich Apache als Webserver verwende, ist dann mod_proxy die beste Möglichkeit, den Lastenausgleich auf Amazons EC2 durchzuführen? Ich sehe, dass Amazon einen Lastenausgleich hat, der so konfiguriert werden kann, dass er mit Amazon CloudWatch zusammenarbeitet, um Messdaten bereitzustellen. Ist das die bessere Lösung?
Für das Anwendungs-Caching möchte ich Memcache verwenden. Gibt es damit Probleme auf Amazons EC2? Ich denke an Siege (http://www.joedog.org/index/siege-faq), um meinen Stresstest durchzuführen. Bietet Amazon bereits etwas für den Stresstest an oder wäre dies ein geeignetes Tool?
Wie viel Zeit wird jemand wie ich, der keine Erfahrung mit der Nutzung dieses Dienstes hat, abgesehen von der Installation unserer Anwendung auf beiden Webknoten, hier einplanen? Ich bin hauptsächlich mit der Bereitstellung von Anwendungen auf Serverinstanzen vertraut und habe einige Erfahrung mit Serverkonfigurationen und Leistungsoptimierung, aber ich bin von Beruf Programmierer. Ich denke, 30 Stunden für die Einrichtung und dann wahrscheinlich noch einmal 15-20 Stunden für das Testen. Klingt das im Rahmen?
Antwort1
Wie bereits erwähnt, handelt es sich bei einer Recheneinheit in etwa um einen älteren Serverprozessor mit 1,0–1,2 GHz. Außerdem sollten Sie Amazons Elastic Load Balancing in Betracht ziehen.
Für einen einfachen, lastausgeglichenen LAMP-Stack sollten Sie mit einem kleinen Instanztyp beginnen und sich von dort aus basierend auf Ihren Tests und Benchmarks nach oben arbeiten.
Memcached funktioniert auf EC2 einwandfrei, Sie müssen jedoch die volatile Natur von EC2 berücksichtigen (Instanzen können manchmal ohne Warnung ausfallen).
Wenn Sie bei Null anfangen und kein Konfigurationsmanagement haben (Sie haben nichts erwähnt, also nehme ich an, dass es keins gibt, aber ich mag Chef), werden Sie wahrscheinlich etwa 2 Arbeitswochen brauchen. Überschätzen Sie immer, da die Arbeit mit EC2 ... schwierig sein kann.
Ich empfehle außerdem die Verwendung der EC2-API-Tools (noch besser ist eine Bibliothek für Ihre bevorzugte Programmiersprache), damit Sie Ihre Instanzen programmgesteuert steuern können.
Antwort2
Zum Rest kann ich nichts sagen, aber Folgendes kann ich Ihnen sagen:
Antwort3
Wenn Sie die Maschinen nur für kurze Zeit laufen lassen möchten, können Sie wahrscheinlich vieles vereinfachen und auf die Verwendung des elastischen Blockspeichers von Amazon verzichten. Das bedeutet, dass Ihre Dateien beim Herunterfahren oder Absturz nicht erhalten bleiben. Wenn Sie Ihre Instanzen nicht herunterfahren, ist es unwahrscheinlich, dass sie abstürzen oder Sie Ihre Daten verlieren. In der Produktion sollten Sie dies nicht tun, aber zum Testen sollte es kein Problem sein.
Für einen Load Balancer verwenden Sie einfach AmazonsElastischer Lastenausgleich. Verwenden Sie Amazon, wenn Sie in Ihrer Produktionsumgebung einen Hardware-Load Balancer verwenden möchten. Wenn Sie in der Produktion einen Software-Load Balancer verwenden möchten, verwenden Sie denselben auf dem EC2.
Zum Testen führe ich gerne Low-Level-HTTP-Tests durch mithttperf. Für Tests auf Anwendungsebene verwende ich gerne JMeter. Normalerweise mache ich die Tests jedoch andersherum. Ich führe JMeter auf EC2 aus und lasse diese Testlast auf meinem Nicht-EC2-Rechenzentrum laufen. Auf diese Weise führe ich einen vollständigen End-to-End-Test durch. Ich vermute jedoch, dass Sie Ihren Test durchführen, weil Sie lokal nicht über die zusätzliche Hardware verfügen, um ein simuliertes Produktions-Setup auszuführen.