In diesem Abschnitt werden unsere Best Practices zusammengefasst und unsere Empfehlungen für die Verwendung von OPDK mit der AWS-Cloud gegeben.
Cassandra wird als Backend und Datenspeicher für fast alle Richtlinien verwendet und ist ein wichtiger Bestandteil der Apigee Edge-Laufzeitumgebung. In diesem Dokument geht es um die Optimierung von Cassandra für die AWS-Umgebung.
Speicher- und E/A-Anforderungen
Die meisten Cassandra-E/A-Vorgänge sind sequenziell, aber es gibt Fälle, in denen zufällige E/A-Vorgänge erforderlich sind. Ein Beispiel ist das Lesen von sortierten Stringtabellen während Lesevorgängen. SSD ist der empfohlene Speichermechanismus für Cassandra, da er extrem niedrige Antwortzeiten für zufällige Lesevorgänge bietet und gleichzeitig genügend sequenzielle Schreibleistung für Komprimierungsvorgänge bereitstellt. Auch die Replikation wird hier berücksichtigt.
Viele Instanzen in AWS EC2 verfügen über lokalen Speicher, bei dem die Festplatte physisch mit der Hardware verbunden ist, auf der die EC2-Instanz gehostet wird. Apigee empfiehlt, sowohl SSD- als auch Instanzspeicher zu verwenden, wenn Cassandra in der Produktion ausgeführt wird. Wenn Sie einen Instanztyp mit mehr als einer SSD verwenden, können Sie RAID0 verwenden, um mehr Durchsatz und Speicherkapazität zu erhalten.
Netzwerkanforderungen
Cassandra verwendet das Gossip-Protokoll für den Informationsaustausch mit anderen Knoten zur Netzwerktopologie. Die Verwendung von Gossip sowie die verteilte Natur von Cassandra, das mit mehreren Knoten für Lese- und Schreibvorgänge kommuniziert, führen zu einer großen Datenübertragung über das Netzwerk. Apigee empfiehlt die Verwendung eines Instanztyps mit einer Netzwerkbandbreite von mindestens 1 Gbit/s und mehr als 1 Gbit/s für Produktionssysteme.
Verwenden Sie eine VPC mit einem CIDR von /16. Da Subnetze in AWS nicht mehr als eine AZ umfassen können, empfiehlt Apigee Folgendes:
- Erstellen Sie ein Subnetz pro Verfügbarkeitszone (Availability Zone, AZ).
- Verwenden Sie drei private Subnetze für Ihre Apigee-Installation mit einem Cassandra-Knoten in jeder AZ. Die drei Subnetze sollten genügend CIDR-Blöcke haben, um die horizontale Erweiterung des Cassandra-Clusters zu ermöglichen.
- Konfigurieren Sie drei öffentliche Subnetze mit dediziertem NAT für Cassandra, damit es für Softwaredownloads und Sicherheitsupdates mit dem Internet kommunizieren kann.
Im Gegensatz zu herkömmlichen Master-Slave-Architekturen hat Cassandra eine masterlose Architektur, in der alle Knoten eine identische Rolle spielen. Es gibt also keinen Single Point of Failure. Sie sollten Ihre Cassandra-Knoten auf mehrere AZs verteilen, um Hochverfügbarkeit zu ermöglichen. Wenn Sie Knoten auf mehrere AZs verteilen, können Sie die Verfügbarkeit und Betriebszeit im Katastrophenfall aufrechterhalten.
Instanzfamilie auswählen
Bei den CPU-Anforderungen für Cassandra ist es hilfreich, zu beachten, dass einfügungsintensive Arbeitslasten in Cassandra CPU-gebunden sind, bevor sie E/A-gebunden werden. Mit anderen Worten: Alle Schreibvorgänge werden in das Commit-Log geschrieben, aber Cassandra ist so effizient beim Schreiben, dass die CPU zum begrenzenden Faktor wird. Cassandra ist hochgradig nebenläufig und verwendet so viele CPU-Kerne wie verfügbar.
Apigee empfiehlt die Verwendung einer Instanzfamilie, die ein ausgewogenes Verhältnis von CPU und Arbeitsspeicher bietet. Insbesondere empfehlen wir die Verwendung von Instanzen der C5-Familie, sofern diese in Ihrer AWS-Region verfügbar sind, und von C3 als Fallback-Option. In einigen Fällen ist 4xlarge die optimale Instanz in beiden Familien, die das beste Preis-Leistungs-Verhältnis bietet.
Apigee empfiehlt außerdem, für Cassandra-Instanzen eine Standardmandantenfähigkeit zu verwenden. Wenn Sie auf mehr als eine Instanz pro AZ skalieren, werden höchstwahrscheinlich alle Ihre Cassandra-Instanzen auf derselben zugrunde liegenden Hardware platziert, wenn Sie die Mandantenfähigkeit auf „Dediziert“ festlegen. Wenn die Hardware ausfällt, verlieren Sie wahrscheinlich alle Ihre Instanzen in dieser AZ.
Zusammenfassung der Empfehlungen
In der folgenden Tabelle sind die Apigee-Empfehlungen für die Verwendung von AWS mit Apigee Edge for Private Cloud zusammengefasst:
| Instanzfamilie | C5d (bevorzugt) oder C3 |
| Instanztyp | C(x).4xlarge |
| Instanzspeicher | SSD (lokaler Speicher) mit RAID0 |
| Mandantentyp | Standardeinstellung |
| Knotenplatzierung | 1 Cassandra-Knoten pro AZ |
| VPC und Subnetz | 1 Subnetz pro AZ und eine VPC pro Region |
Weitere Informationen finden Sie unter Amazon-Instanztypen.