Utilisation de la réplication synchrone distante de blocs sur Oracle Cloud Infrastructure
Fournissez la tolérance de panne des volumes de blocs à l'aide de la réplication synchrone distante de blocs.
Les défis typiques de nombreuses entreprises sont les suivants : les applications s'exécutant sur une base de données, les applications accédant aux périphériques en mode bloc sous-jacents et les besoins de l'entreprise en termes de délais de service nuls.
Prenons par exemple les sociétés de traitement des paiements. Comme un retard dans le traitement des paiements a un impact négatif sur la réputation et la marque aux yeux de leurs clients, ils doivent disposer d'une technologie de 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 implémente un périphérique en mode bloc hautement disponible sur Oracle Cloud Infrastructure (OCI), entièrement tolérant une défaillance au niveau de l'application métier. Utilisez cette architecture pour les applications sensibles aux performances qui nécessitent une continuité en même temps.
Cette architecture fournit un périphérique en mode bloc iSCSI à une seule entité aux utilisateurs. Ce périphérique sera toujours disponible, indépendamment des pannes à composant unique. Les autres composants d'architecture sont masqués 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 une 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 en mode bloc unique et toujours disponible nécessite les opérations suivantes.
- Trois instances de calcul, des machines virtuelles ou Bare Metal. Ces derniers peuvent être préférables car ils présentent des performances stables.
- Deux réseaux cloud virtuels : un réseau public et un réseau privé.
- Deux volumes de blocs de l'appareil cible toujours disponible.
- (Recommandé) Avoir les volumes de blocs au moins 10 VPU. Vous pouvez envisager un niveau d'IOPS encore plus élevé, en fonction de l'agressivité de votre débit d'E/S et de la distance entre les hôtes mis en miroir (et les volumes de blocs).
Par conséquent, le coût de l'implémentation d'un périphérique en mode bloc toujours disponible est trois fois plus élevé que celui de l'instance de calcul et deux fois plus élevé que celui du périphérique lui-même.
Le schéma suivant illustre cette architecture de référence.
remote-synchronous-block-replication-diagram-oracle.zip
L'architecture comprend les composants suivants :
- Périphérique de blocs répliqué distribué
Le périphérique de blocs répliqué distribué (DRBD) est un pilote de noyau Linux qui maintient la connexion réseau entre deux périphériques de 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 à haute disponibilité open source, couramment utilisé dans les environnements Linux. Il garantit que les applications, services ou ressources s'exécutent en continu avec un temps d'arrêt minimal en détectant les pannes 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 sémantique de 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 à des sous-réseaux dans le VCN. Utilisez des blocs CIDR qui se trouvent dans l'espace d'adresse IP privée standard.
Sélectionnez les blocs CIDR qui ne chevauchent aucun autre réseau (dans Oracle Cloud Infrastructure, votre centre de données sur site ou un autre fournisseur cloud) auquel vous avez l'intention de 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 du flux de trafic et des exigences 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é.
- Cloud Guard
Cloner et personnaliser les recettes par défaut fournies par Oracle afin de créer des recettes de détecteur et de répondeur personnalisées. Ces recettes vous permettent de spécifier le type de violation de sécurité qui génère un avertissement et les actions autorisées à y être exécutées. Par exemple, vous pouvez détecter les buckets Object Storage dont la visibilité est définie sur Public.
Appliquez Cloud Guard au niveau de la location pour couvrir la portée la plus large et réduire la charge administrative liée à la maintenance de plusieurs configurations.
Vous pouvez également utiliser la fonction Liste gérée pour appliquer certaines configurations aux détecteurs.
- Security Zones
Pour les ressources nécessitant une sécurité maximale, Oracle vous recommande d'utiliser des zones de sécurité. Une zone de sécurité est un compartiment associé à une recette de stratégies de sécurité définie par Oracle qui repose sur les meilleures pratiques. Par exemple, les ressources d'une zone de sécurité ne doivent pas être accessibles à partir du réseau Internet public et doivent être cryptées à l'aide de clés gérées par le client. Lorsque vous créez et mettez à jour des ressources dans une zone de sécurité, Oracle Cloud Infrastructure valide les opérations par rapport aux stratégies de la recette de zone de sécurité et refuse les opérations qui enfreignent l'une des stratégies.
- Groupes de sécurité réseau
Vous pouvez utiliser des groupes de sécurité réseau pour définir un ensemble de règles entrantes et sortantes qui s'appliquent à des cartes d'interface réseau virtuelles spécifiques. Nous vous recommandons d'utiliser des groupes de sécurité réseau plutôt que des listes de sécurité, car ces derniers vous permettent de séparer l'architecture de sous-réseau du VCN des exigences de sécurité de votre application.
- Bande passante d'é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 indiquer une forme personnalisée (flexible) dans laquelle vous définissez une plage de bande passante et laisser le service redimensionner automatiquement la bande passante en fonction des modèles de trafic. Dans l'une ou l'autre approche, vous pouvez modifier la forme à tout moment après avoir créé l'équilibreur de charge.
Points à prendre en compte
Tenez compte des points suivants lors du déploiement de cette architecture de référence.
- Performances
Vous devez planifier deux fois N d'IOPS nominaux sur votre appareil toujours disponible afin de fournir N IOPS à 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 vous recommandons vivement d'isoler les détails d'implémentation en divisant la solution en réseaux publics et privés.
- Disponibilité
Nous vous recommandons d'implémenter un périphérique toujours disponible car iSCSI pour cette technologie est indépendant du système d'exploitation, afin que les utilisateurs puissent bénéficier 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 est un composant intégral du noyau vanilla Linux et est disponible dans n'importe quelle distribution Linux.