Utiliser OKE pour améliorer la localisation des données pour l'activité Cassandra et Spark

Présentation

Apache Cassandra est une base de données distribuée, sans maître, où chaque noeud possède des intervalles de jetons. Apache Spark est un moteur de calcul réparti qui peut utiliser le connecteur Spark–Cassandra pour lire des répliques Cassandra. Dans Kubernetes, les pods sont programmés sans savoir où résident les données, de sorte que la localisation des données n'est pas garantie.

Ce tutoriel montre comment OKE peut améliorer la localité avec les primitives Kubernetes : StatefulSets (identité stable pour Cassandra), les étiquettes de noeud et l'affinité/anti-affinité pour colocaliser les exécuteurs Spark avec les pods Cassandra. Les lectures sont donc servies à partir du même noeud (idéal) ou, dans le pire des cas, d'un saut vers la réplique colocalisée.

Objectifs

Conditions requises

  1. Cliquez ci-dessous pour ouvrir la pile dans la console OCI :

    Déployer vers Oracle Cloud

  2. Suivez le flux guidé pour :

  1. Une fois la pile terminée, vous obtiendrez l'adresse IP de l'hôte bastion dans la section de sortie.

    Sortie de pile

Tâche 2 : Se connecter à l'hôte bastion et vérifier le déploiement

Le provisionnement initial de l'infrastructure est terminé en environ 15 minutes, mais la configuration complète (au moyen de cloud-init sur l'hôte bastion) prend environ 20 minutes de plus pour installer Helm, déployer Cassandra et Spark, et exécuter la tâche de lecture.

  1. Pour surveiller le processus, utilisez SSH dans l'hôte bastion :

    ssh -i <path-to-private-key> opc@<bastion_public_ip>

  2. Exécutez la commande ci-dessous pour surveiller la progression du script cloudinit.

    tail -f /var/log/oke-automation.log

  3. La pile est terminée lorsque vous voyez les 3 valeurs Cassandra de départ en cours de lecture et le message Cloud-init complete.

    Cloud-Init complet

Note : Ce que le script cloudinit a fait est :

  1. À partir de la machine virtuelle bastion, vérifiez les noeuds existants :

    kubectl get nodes

  2. confirmation des étiquettes de localité; Attendez-vous à deux noeuds avec spark-locality=true et data-locality=enabled.

    kubectl get nodes --show-labels | grep -E 'spark-locality|data-locality'

  3. Vérifier le placement Cassandra :

    kubectl -n k8ssandra-operator get pods -l app.kubernetes.io/name=cassandra -o wide

  4. Vérifier le positionnement de Spark :

    kubectl -n spark get pods -o wide

  5. Consultez les journaux de tâche de lecture Spark. Vous devriez voir les 3 enregistrements de testks.users et une exécution réussie.

    kubectl -n spark logs job/spark-read-cassandra --tail=20

Conseil : L'appariement des valeurs NODE aux pods Cassandra et Spark confirme la colocalisation et les conditions idéales pour la localité. Pour obtenir des résultats plus concluants du journal de flux, insérez des rangées supplémentaires dans testks.users à l'aide de cqlsh. Les jeux de données plus volumineux généreront plus de trafic de lecture, ce qui facilitera l'observation des effets localisés et non localisés.

Vous trouverez ci-dessous un exemple de sortie pour les commandes ci-dessus :

vérification des noeuds

Tâche 3 : Observer les effets de réseau à l'aide des journaux de flux de VCN

Utilisez les journaux de flux de VCN pour comprendre où le trafic Cassandra circule lors des lectures Spark. L'automatisation actuelle utilise Flannel (VXLAN), ce qui affecte ce que les journaux de flux peuvent voir.

Ce qui change avec le CNI

  1. Activer les journaux de flux dans le sous-réseau de travail.

    Dans la console OCI, activez les journaux de flux pour le sous-réseau de travail OKE. Réexécutez (ou attendez) la tâche de lecture Spark pour générer du trafic.

  2. Journaux de flux d'interrogation (choisissez le chemin correspondant à votre grappe)

Si vous utilisez cette automatisation (Canal/VXLAN) : Utilisez une interrogation avancée similaire à :

   search "<your-flow-log-OCID>"
   | where data.protocolName = 'UDP'
   | where data.destinationPort = <vxlan-port>

Remplacez par l'OCID réel de la ressource de journal de flux et par le port utilisé par votre superposition (dans cet exercice : 14789, voir l'image ci-dessous).

Trafic UDP

Si votre cluster utilise NPN :

Remarque : Les journaux de flux peuvent prendre quelques minutes pour ingérer de nouvelles entrées.

Considérations clés

Fournissez des liens vers des ressources supplémentaires. Cette section est facultative. Supprimez-la si nécessaire.

Remerciements

Ressources d'apprentissage supplémentaires

Explorez d'autres laboratoires sur le site docs.oracle.com/learn ou accédez à plus de contenu d'apprentissage gratuit sur le canal Oracle Learning YouTube. De plus, visitez education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour obtenir la documentation sur le produit, visitez Oracle Help Center.