In diesem Abschnitt werden unsere Best Practices zusammengefasst und Empfehlungen für die Verwendung von OPDK mit AWS Cloud gegeben.
Cassandra wird als Back-End 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 Casssandra 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 Sie zufällige E/A-Vorgänge benötigen. Ein Beispiel hierfür ist das Lesen von sortierten Stringtabellen bei Lesevorgängen. SSD ist der empfohlene Speichermechanismus für Cassandra, da es Antwortzeiten mit extrem niedriger Latenz für zufällige Lesevorgänge bietet und gleichzeitig genügend sequenzielle Schreibleistung für Verdichtungsvorgänge bietet. Auch die Replikation wird hier berücksichtigt.
Viele Instanzen in AWS EC2 verfügen über einen lokalen Speicher, in dem die Festplatte physisch mit der Hardware verbunden ist, auf der die EC2-Instanz gehostet wird. Apigee empfiehlt, beim Ausführen von Cassandra in der Produktion sowohl SSD- als auch Instanzspeicher zu nutzen. Wenn Sie einen Instanztyp mit mehr als 1 SSD verwenden, können Sie RAID0 verwenden, um mehr Durchsatz und Speicherkapazität zu erhalten.
Netzwerkanforderungen
Cassandra verwendet das Gossip-Protokoll, um Informationen über die Netzwerktopologie mit anderen Knoten auszutauschen. Die Verwendung von Gossip zusammen mit der verteilten Natur von Cassandra, bei der für Lese- und Schreibvorgänge mit mehreren Knoten kommuniziert wird, führt zu einer großen Datenübertragung über das Netzwerk. Apigee empfiehlt die Verwendung des 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 sich nicht über 1 AZ erstrecken können, empfiehlt Apigee Folgendes:
- 1 Subnetz pro Verfügbarkeitszone (AZ) erstellen
- Verwenden Sie drei private Subnetze für Ihre Apigee-Installation mit einem Cassandra-Knoten in jedem 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 dedizierter NAT für Cassandra, um für Softwaredownloads und Sicherheitsupdates mit dem Internet zu kommunizieren.
Im Gegensatz zu Legacy-Master-Slave-Architekturen hat Cassandra eine Architektur ohne Master, bei der alle Knoten eine identische Rolle spielen, sodass es keinen Single Point of Failure gibt. Ziehen Sie in Betracht, Ihre Cassandra-Knoten auf mehrere AZs zu verteilen, um eine Hochverfügbarkeit zu ermöglichen. Durch die Verteilung von Knoten auf Verfügbarkeitszonen können Sie die Verfügbarkeit und Betriebszeit im Notfall aufrechterhalten.
Instanzfamilie auswählen
Bei der Betrachtung der Cassandra-CPU-Anforderungen sollte beachtet werden, dass Einfüge-intensive Arbeitslasten in Cassandra CPU-gebunden sind, bevor sie IO-gebunden werden. Mit anderen Worten: Alle Schreibvorgänge werden in das Commit-Log geschrieben, aber Cassandra ist beim Schreiben so effizient, dass die CPU zum begrenzenden Faktor wird. Cassandra wird stark gleichzeitig ausgeführt und verwendet so viele CPU-Kerne wie verfügbar.
Apigee empfiehlt die Verwendung einer Instanzfamilie, die ein Gleichgewicht aus CPU und Arbeitsspeicher aufweist. Wir empfehlen insbesondere die Verwendung von Instanzen der C5-Familie, falls diese in Ihrer AWS-Region verfügbar sind, und 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 die Verwendung einer Standardmandantenfähigkeit für Cassandra-Instanzen. 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 als dediziert festlegen. Wenn also Hardware ausfällt, gehen wahrscheinlich alle Instanzen in dieser Zone verloren.
Zusammenfassung der Empfehlungen
In der folgenden Tabelle sind die Apigee-Empfehlungen für die Verwendung von AWS mit Apigee Edge für 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.