Estimation et réduction de l'impact de la reprise
Lors de la reprise et du rétablissement, il existe un intervalle durant lequel l'accès au stockage ne peut pas être fourni aux clients. La durée de cet intervalle varie en fonction de la configuration. Les effets exacts sur les clients dépendent des protocoles qu'ils utilisent pour accéder aux données. La compréhension et la limitation de ces effets peut faire la différence entre un déploiement de cluster réussi et une panne dommageable survenant au pire moment possible.
Les clients NFS (toutes versions confondues) cachent généralement les interruptions de service aux applications logicielles, ce qui entraîne le retard des opérations d'E/S durant l'indisponibilité d'un serveur. NFSv2 et NFSv3 sont des protocoles sans état dont la récupération est quasiment instantanée durant la restauration du service. NFSv4.0 et NFSv4.1 intègrent une période de grâce du client au démarrage, durant laquelle aucune opération d'E/S ne peut généralement être réalisée. La durée de cette période de grâce peut être réglée sur les appareils Oracle ZFS Storage Appliance. Si vous la réduisez, l'impact apparent de la reprise et/ou du rétablissement est réduit. Pour les interruptions de service planifiées, l'appareil fournit une récupération sans période de grâce pour les clients NFSv4.0 et NFSv4.1, ce qui évite le délai de la période de grâce. Pour plus d'informations sur la récupération sans période de grâce, reportez-vous à la description de la propriété de période de grâce dans la section Propriétés du service NFS.
Figure 9 Propriété de la période de grâce NFS
Le comportement iSCSI durant les interruptions de service dépend de l'initiateur, mais les initiateurs récupèrent automatiquement si le service est restauré dans un délai d'attente spécifique au client. Pour plus d'informations, consultez la documentation de votre initiateur. La cible iSCSI peut généralement fournir le service dès la fin de la reprise, sans délai supplémentaire.
SMB, FTP et HTTP/WebDAV sont des protocoles orientés connexion. Etant donné que les états de la session associés à ces services ne peuvent pas être transférés avec le stockage sous-jacent et la connectivité réseau, tous les clients qui utilisent ces protocoles sont déconnectés durant une reprise ou un rétablissement et doivent se reconnecter à l'issue de l'opération.
Même si plusieurs facteurs ont une incidence sur le temps de reprise et le temps de rétablissement, dans la plupart des configurations, ces délais sont dominés par le temps requis pour importer les ressources de l'ensemble de disques. La durée d'importation type de chaque plage d'ensemble de disques est de l'ordre de 15 à 20 secondes (linéaires dans le nombre d'ensembles de disques). Un ensemble de disques consiste en une demie étagère de disques, à condition que les baies de disque de cette demie-étagère de disques aient été remplies et allouées à un pool de stockage. Les disques non alloués et les baies vides n'ont pas d'incidence sur le temps de reprise. Les paramètres réglables ou éventuellement modifiés par les administrateurs n'ont aucune incidence sur le temps requis pour importer les ressources de l'ensemble de disques. Par conséquent, effectuez l'une des actions suivantes si vous planifiez un déploiement clusterisé :
-
Limiter le stockage installé afin que les clients puissent tolérer les temps de reprise liés
-
définir des valeurs de délai d'attente côté client supérieures au délai maximal de reprise attendu
Notez que, même si l'importation de l'ensemble de disques représente la majeure partie du temps de reprise, il ne s'agit pas du seul facteur. Lors de l'importation du pool, tous les enregistrements du journal d'intention doivent être rediffusés et chaque partage et LUN doit être partagé via les services appropriés. La durée nécessaire à l'exécution de ces activités pour un seul partage ou LUN est très courte (de l'ordre du dixième de seconde). Mais en présence d'un très grand nombre de partages, le délai de reprise peut être bien plus long. En gardant un nombre de partages relativement bas (quelques centaines ou moins), ces temps peuvent être considérablement raccourcis.
La durée de rétablissement est généralement plus longue que le temps de reprise pour n'importe quelle configuration. Cela tient au fait que le rétablissement se fait en deux étapes : d'abord, l'appareil source exporte toutes les ressources dont vous n'êtes pas le propriétaire attitré, puis l'appareil cible effectue la procédure de reprise standard uniquement sur les ressources qui lui ont été attribuées. Il faudra donc plus de temps pour effectuer le rétablissement à partir du contrôleur A vers le contrôleur B qu'il n'en faudra pour que le contrôleur A effectue la reprise à partir du contrôleur B en cas de panne. Ce temps de rétablissement supplémentaire dépend beaucoup moins du nombre d'ensembles de disques en cours d'exportation que du délai de reprise. Par conséquent, le fait de maintenir un petit nombre de partages et de LUN affecte davantage le rétablissement que la reprise. Gardez également à l'esprit que le rétablissement est toujours amorcé par un administrateur. Par conséquent, plus l'interruption du service qu'il entraîne dure et plus celle-ci pourra être planifiée afin de limiter au maximum l'interruption des activités.
Remarque - Les durées estimées citées dans cette section peuvent varier d'une version logicielle/de microprogramme à l'autre. Il est important de tester l'opération de reprise et ses conséquences exactes sur les applications client avant de déployer une configuration clusterisée dans un environnement de production.
Rubriques connexes