Estimation et réduction de l'impact de la reprise

Il existe un intervalle entre la reprise et le rétablissement 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 du/des protocole(s) 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 intègre 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 de la gamme Oracle ZFS Storage Appliance (voir l'illustration). 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 Oracle ZFS Storage Appliance fournit une récupération sans grâce pour les clients NFSv4, 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 propriété de période de grâce dans la section des propriétés NFS.

Figure 2-28  Période de grâce de cluster

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 utilisant 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 son proche parent, le temps de rétablissement), dans la plupart des configurations, ces délais sont dominés par le temps requis pour importer la/les ressource(s) 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). N'oubliez pas qu'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'ayant pas d'incidence sur le temps requis pour importer les ressources de l'ensemble de disques, les administrateurs planifiant des déploiements clusterisés doivent réaliser l'une des opérations suivantes :

• limiter le stockage installé afin que les clients puissent tolérer les temps de reprise liés ou

• 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 le(s) service(s) 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 de la tête A vers la tête B qu'il n'en faudra pour que la tête A effectue la reprise à partir de la tête 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 se rapportent à la version logicielle/du microprogramme 2009.04.10,1-0. Les autres versions peuvent se comporter différemment et les performances réelles peuvent varier. Il est important de tester la reprise et ses conséquences exactes sur les applications client avant de déployer un appareil clusterisé dans un environnement de production.