Cette section résume nos bonnes pratiques et fournit nos recommandations pour l'utilisation d'OPDK avec le cloud AWS.
Cassandra est utilisé comme backend et datastore pour presque toutes les règles et constitue un élément essentiel de l'environnement d'exécution d'Apigee Edge. Ce document porte sur l'optimisation de Casssandra pour l'environnement AWS.
Exigences liées au stockage et aux E/S
La plupart des E/S Cassandra sont séquentielles, mais dans certains cas, vous avez besoin d'E/S aléatoires. La lecture de tables de chaînes triées lors d'opérations de lecture en est un bon exemple. Le SSD est le mécanisme de stockage recommandé pour Cassandra, car il fournit des temps de réponse de très faible latence pour les opérations de lecture aléatoires tout en offrant des performances d'écriture séquentielle suffisantes pour les opérations de compactage. La réplication est également prise en compte ici.
Dans AWS EC2, de nombreuses instances sont fournies avec un stockage local dans lequel le disque dur est physiquement connecté au matériel sur lequel l'instance EC2 est hébergée. Apigee recommande d'exploiter à la fois les disques SSD et les magasins d'instances lors de l'exécution de Cassandra en production. Si vous utilisez un type d'instance avec plusieurs disques SSD, vous pouvez utiliser le type RAID0 pour obtenir plus de débit et de capacité de stockage.
Configuration réseau requise
Cassandra utilise le protocole Gossip pour échanger des informations sur la topologie du réseau avec d'autres nœuds. L'utilisation de Gossip et la nature distribuée de Cassandra, qui implique de communiquer avec plusieurs nœuds pour les opérations de lecture et d'écriture, entraînent un grand nombre de transferts de données via le réseau. Apigee recommande d'utiliser un type d'instance avec une bande passante réseau d'au moins 1 Gbit/s et plus de 1 Gbit/s pour les systèmes de production.
Utilisez un VPC avec un CIDR de /16. Étant donné que les sous-réseaux d'AWS ne peuvent pas couvrir plus de 1 zone géographique, Apigee recommande les mesures suivantes:
- Créer un sous-réseau par zone de disponibilité (AZ)
- Utilisez trois sous-réseaux privés pour votre installation Apigee, avec un nœud Cassandra dans chaque zone de zone. Les trois sous-réseaux doivent comporter suffisamment de blocs CIDR pour permettre l'expansion horizontale du cluster Cassandra.
- Configurez trois sous-réseaux publics avec une NAT dédiée pour que Cassandra puisse communiquer avec Internet lors du téléchargement de logiciels et des mises à jour de sécurité.
Contrairement aux anciennes architectures maître-esclave, Cassandra dispose d'une architecture sans maître dans laquelle tous les nœuds jouent un rôle identique. Il n'y a donc pas de point de défaillance unique. Envisagez de répartir vos nœuds Cassandra sur plusieurs zones de disponibilité pour permettre la haute disponibilité. En répartissant les nœuds sur plusieurs zones de couverture, vous pouvez toujours maintenir la disponibilité et le temps d'activité en cas de sinistre.
Choisir une famille d'instances
En ce qui concerne les exigences du processeur Cassandra, il est utile de noter que les charges de travail lourdes en insertion sont liées au processeur dans Cassandra avant d'être liées aux E/S. En d'autres termes, toutes les opérations d'écriture sont consignées dans le journal des commits, mais Cassandra est si efficace que le processeur en devient le facteur limitant. Cassandra propose un grand nombre de connexions simultanées et utilise autant de cœurs de processeur que possible.
Apigee recommande d'utiliser une famille d'instances, qui dispose d'un équilibre entre le processeur et la mémoire. Plus précisément, nous vous recommandons d'utiliser des instances de la famille C5 si elles sont disponibles dans votre région AWS et des instances C3 comme option de secours. Dans certains cas, 4xgrand est l'instance optimale dans les deux familles qui offre le meilleur rapport prix/performances.
Apigee recommande également d'utiliser une location par défaut pour les instances Cassandra. Lorsque vous passez à plusieurs instances par zone de disponibilité, toutes vos instances Cassandra seront probablement placées sur le même matériel sous-jacent si vous définissez la location comme dédiée. Ainsi, en cas de défaillance matérielle, vous perdrez probablement toutes vos instances dans cette zone de disponibilité.
Récapitulatif des recommandations
Le tableau suivant récapitule les recommandations Apigee pour l'utilisation d'AWS avec Apigee Edge pour le cloud privé:
| Famille d'instances | C5d (recommandé) ou C3 |
| Type d'instance | C(x).4xlarge |
| Magasin d'instances | SSD (stockage local) avec RAID0 |
| Type de location | par défaut |
| Emplacement du nœud | 1 nœud Cassandra par zone de disponibilité |
| VPC et sous-réseau | Un sous-réseau par zone AZ et un VPC par région |
Pour en savoir plus, consultez la page Types d'instances Amazon.