Utiliser la réplication de bloc synchrone distante sur Oracle Cloud Infrastructure
Fournissez une tolérance aux pannes pour les volumes par blocs à l'aide de la réplication synchrone distante par blocs.
Les défis typiques pour de nombreuses entreprises sont les suivants : les applications exécutées au-dessus d'une base de données, les applications accédant aux périphériques de traitement par blocs sous-jacents et l'absence de retards dans les services.
Prenez les sociétés de traitement des paiements, par exemple. Comme un retard dans le traitement des paiements affecte négativement la réputation et la marque aux yeux de leurs clients, ils doivent disposer d'une technologie haute disponibilité pour fournir une véritable tolérance aux pannes (c'est-à-dire zéro interruption de service en cas de défaillance d'un seul composant).
Architecture
Cette architecture met en oeuvre un périphérique de traitement par blocs hautement disponible sur Oracle Cloud Infrastructure (OCI), totalement tolérant à une défaillance au niveau de l'application d'affaires. Utilisez cette architecture pour les applications sensibles aux performances qui nécessitent une continuité en même temps.
Cette architecture fournira aux utilisateurs un périphérique de traitement par blocs iSCSI à entité unique. Cet appareil sera toujours disponible, indépendamment des défaillances d'un seul composant. Tout autre composant d'architecture sera masqué pour les utilisateurs. L'architecture est entièrement automatisée en cas de panne ou de permutation. Le seul effet que les utilisateurs remarqueront en cas de panne ou de permutation sera la dégradation des performances du périphérique iSCSI d'environ 50% pendant une ou deux secondes.
L'implémentation d'un périphérique de traitement par blocs unique et toujours disponible nécessite les opérations suivantes.
- Trois instances de calcul, machines virtuelles ou sans système d'exploitation (BM). Ces derniers peuvent être préférables car ils ont des performances stables.
- Deux réseaux en nuage virtuels : un public, un privé.
- Deux volumes par blocs de votre appareil cible toujours disponible.
- (Recommandé) Avoir les volumes par blocs d'au moins 10 UPV. Vous pouvez envisager un niveau d'E/S par seconde encore plus élevé, en fonction de l'agressivité de votre débit d'E/S et de la distance entre les hôtes en miroir (et les volumes par blocs).
Par conséquent, le coût de mise en oeuvre d'un périphérique de traitement par blocs toujours disponible est trois fois supérieur au coût de l'instance de calcul, plus deux fois supérieur au coût du périphérique lui-même.
Le diagramme suivant illustre cette architecture de référence.
à distance-synchrone-block-replication-diagramme-oracle.zip
L'architecture comprend les composants suivants :
- Dispositif de bloc répliqué distribué
Distributed Replicated Block Device (DRBD) est un pilote de noyau Linux qui gère la connexion réseau entre deux périphériques de traitement par blocs sur des instances Linux distantes et réplique les opérations d'E/S de l'instance source vers l'instance de destination.
- Pacemaker
Pacemaker est un gestionnaire de ressources de cluster open-source à haute disponibilité, couramment utilisé dans les environnements Linux. Il garantit que les applications, les services ou les ressources s'exécutent en continu avec un temps d'arrêt minimal en détectant les défaillances et en redémarrant ou en déplaçant automatiquement les services sur d'autres noeuds d'un cluster.
- Corosync
Corosync est un logiciel open source qui étend Pacemaker avec la sémantique de la restauration dans le cas du cerveau divisé.
- Initiateur et cible iSCSI
iSCSI est un composant logiciel client et serveur qui fournit un périphérique SCSI sur un réseau.
Recommandations
- VCN
Lorsque vous créez un VCN, déterminez le nombre de blocs CIDR requis et la taille de chaque bloc en fonction du nombre de ressources que vous prévoyez d'attacher aux sous-réseaux du VCN. Utilisez des blocs CIDR qui se trouvent dans l'espace d'adresses IP privées standard.
Sélectionnez les blocs CIDR qui ne chevauchent aucun autre réseau (dans Oracle Cloud Infrastructure, votre centre de données sur place ou un autre fournisseur de nuage) auquel vous voulez configurer des connexions privées.
Après avoir créé un VCN, vous pouvez modifier, ajouter et supprimer ses blocs CIDR.
Lorsque vous concevez les sous-réseaux, tenez compte de vos exigences en matière de flux de trafic et de sécurité. Attachez toutes les ressources d'un niveau ou d'un rôle spécifique au même sous-réseau, qui peut servir de limite de sécurité.
- Protection d'infrastructure en nuage
Cloner et personnaliser les recettes par défaut fournies par Oracle pour créer des recettes de détecteur et de répondant personnalisées. Ces recettes vous permettent de spécifier quel type de violations de sécurité génèrent un avertissement et quelles actions sont autorisées pour elles. Par exemple, vous pouvez détecter des seaux de stockage d'objets dont la visibilité est réglée à Public.
Appliquez le service de protection d'infrastructure en nuage au niveau de la location pour couvrir la portée la plus large et réduire le fardeau administratif lié à la maintenance de plusieurs configurations.
Vous pouvez également utiliser la fonction de liste gérée pour appliquer certaines configurations aux détecteurs.
- Zones de sécurité
Pour les ressources qui nécessitent une sécurité maximale, Oracle recommande d'utiliser des zones de sécurité. Une zone de sécurité est un compartiment associé à une recette de politiques de sécurité définie par Oracle et basée sur les meilleures pratiques. Par exemple, les ressources d'une zone de sécurité ne doivent pas être accessibles par l'Internet public et elles doivent être chiffrées à l'aide de clés gérées par le client. Lors de la création et de la mise à jour de ressources dans une zone de sécurité, Oracle Cloud Infrastructure valide les opérations en fonction des politiques de la recette de zone de sécurité et refuse les opérations qui violent l'une des politiques.
- Groupes de sécurité de réseau
Vous pouvez utiliser des groupes de sécurité de réseau pour définir un jeu de règles de trafic entrant et sortant qui s'appliquent à des cartes vNIC spécifiques. Nous vous recommandons d'utiliser des groupes plutôt que des listes de sécurité, car ils vous permettent de séparer l'architecture de sous-réseau du VCN des exigences de sécurité de votre application.
- Bande passante de l'équilibreur de charge
Lors de la création de l'équilibreur de charge, vous pouvez sélectionner une forme prédéfinie qui fournit une bande passante fixe, ou spécifier une forme personnalisée (flexible) dans laquelle vous définissez une plage de bande passante et laissez le service ajuster la bande passante automatiquement en fonction des modèles de trafic. Avec l'une ou l'autre approche, vous pouvez modifier la forme en tout temps après avoir créé l'équilibreur de charge.
Points à considérer
Tenez compte des points suivants lors du déploiement de cette architecture de référence.
- Performance
Vous devez planifier deux fois N d'E/S par seconde nominales sur votre appareil toujours disponible afin de fournir N E/S par seconde à vos utilisateurs. Cela est dû au fait que la moitié des performances sont consacrées à la mise en miroir en temps réel.
- Sécurité
Nous recommandons fortement d'isoler les détails de mise en œuvre en divisant la solution aux réseaux publics et privés.
- Disponibilité
Nous recommandons de mettre en œuvre un appareil toujours disponible, car iSCSI pour cette technologie est indépendant du système d'exploitation, afin que les utilisateurs puissent profiter d'une véritable tolérance aux pannes, qu'ils exécutent Linux ou Windows sur leurs machines.
Tous les composants logiciels de la solution sont accessibles au public en tant que produits open source. En particulier, le pilote DRBD fait partie intégrante du noyau vanilla Linux et est disponible dans toute distribution Linux.