Ich möchte meine Instanz von einer Mikroinstanz zu einer kleinen Instanz verschieben, aber wenn ich versuche, ein neues AMI basierend auf meinem Mikroinstanz-AMI zu starten, wird mir nur die Option für 64-Bit-Instanzen angezeigt.
Mein erstes AMI basiert auf einem Ubuntu 10.04-Image.
Ist es nicht möglich, zwischen einer 64-Bit- und einer 32-Bit-Instanz zu wechseln?
Wäre es möglich, mithilfe eines Load Balancers eine 32-Bit-Instanz und eine 64-Bit-Instanz zusammenarbeiten zu lassen?
Ich habe eine Website/Webanwendung, auf die ich riesige Datenmengen hochladen werde. Ich werde mit 65 Gigabyte an Bildern beginnen und dann auf über 100 Gigabyte an Bildern aufstocken.
Ich bin nicht sicher, welcher Instanztyp dafür am besten geeignet wäre. Ich wollte einen Load Balancer und eine automatische Skalierung verwenden, um die Anzahl der Instanzen bei hoher Last zu erhöhen.
Wird beim Verwenden eines Lastenausgleichs eine der AMI-Instanzen zum primären Image und fungieren die übrigen als Klone davon?
Antwort1
Sie können Images nur auf derselben Architektur (32 Bit oder 64 Bit) starten, auf der sie erstellt wurden. Mikroinstanzen können entweder 32 Bit oder 64 Bit sein, aber wenn Sie beim Erstellen ein 64-Bit-Image verwendet haben, sind Sie darauf beschränkt. Sie können eine „große“ Instanz anstelle einer „kleinen“ verwenden, wenn Ihr Budget dies zulässt.
Es ist Ihnen durchaus möglich, einen Lastenausgleich für verschiedene Instanztypen durchzuführen (entweder mithilfe des ELB von Amazon oder einer anderen Instanz, z. B. mit HAProxy, Squid, Varnish usw.).
Ich schätze, Ihr größtes Problem ist, wo Sie diese Datenmenge speichern möchten. Wenn Sie vorhaben, mehrere Instanzen zu haben, die denselben Inhalt bereitstellen (und auf die hochgeladen wird), benötigen SieGeteiltes Lager. Sie können etwas wie GlusterFS verwenden, um die Daten zwischen Ihren Instanzen zu teilen, oder Sie können einen „Speicherserver“ haben, den Ihre Webinstanzen per NFS mounten.
Die automatische Skalierung funktioniert so, dass Sie ein „Startimage“ festlegen, das die AMI-ID Ihres „Master“-Images ist. Dieses Image wird dann als Reaktion auf Auslöser (z. B. zu hohe Last) gestartet. Es ist wichtig, darüber nachzudenken, was dies konzeptionell bedeutet – es bedeutet, dass jede gestartete Instanz auf dem Originalimage basiert und keine neuen Daten oder aktualisierten Konfigurationen usw. enthält.
Zusammenfassend lässt sich also sagen: Wenn Sie mehr als einen Webserver verwenden, benötigen Sie eine Art gemeinsam genutzten Speicher. Oft handelt es sich dabei um Datenbanken (vielleicht über den RDS-Dienst von Amazon), aber es klingt, als müssten Sie große „Dateien“ speichern und keine Daten, sodass Sie verteilten Speicher oder einen Speicherserver benötigen.
Antwort2
Entsprechend derAmazon EC2-Instanzbeschreibungsseite, die Micro-Instanzen sind in 32 und 64 Bit verfügbar, während die Small-Instanztypen nur in 32 Bit verfügbar sind . Aus diesem Grund konnten Sie Ihr erstes 64-Bit-AMI nicht auf dem Small-Instanztyp starten.
- Aktualisieren: AWS hat inzwischen64-Bit-Allgegenwart, d.h. jeder Instanztyp kann mit 64-Bit-Images verwendet werden, was in der Taterleichtert Ihnen die vertikale Skalierung (auf größere und kleinere Instanzen), ohne dass Sie parallele (32- und 64-Bit-) AMIs verwalten müssen(sehenEC2-Updates: Neue mittlere Instanz, 64-Bit-Ubiquity, SSH-Clientfür Details).
Zu Ihren Load Balancer-Problemen: Dies hängt stark von Ihrem Nutzungsmuster ab – sowohl 32- als auch 64-Bit-Instanztypen können problemlos hinter einem Load Balancer zusammenarbeiten. Ich würde jedoch empfehlen, bei einem Instanztyp zu bleiben. Generell denke ich, dass die Hauptsorge für Sie bei I/O und Speicher liegen sollte, wenn Sie nur Uploads und keine Bildverarbeitung oder ähnliches durchführen. Ich würde vorschlagen, es einfach auszuprobieren, das für Ihre Web-App erforderliche Minimal-Setup zu verwenden und einige Belastungstests mit beiden Instanztypen durchzuführen.