Mise à niveau à partir des versions 2009.Q3 et antérieures

L'implémentation de réplication a beaucoup changé entre les versions 2009.Q3 et 2010.Q1. Il reste vivement recommandé de suspendre la réplication vers et depuis un ZFSSA avant de lancer une mise à niveau depuis une version 2009.Q3 ou antérieure. Cela est obligatoire dans tous les clusters utilisant la mise à niveau non simultanée.

Trois modifications importantes sont visibles par l'utilisateur et liées à la mise à niveau vers une version 2010.Q1 ou ultérieure :

• Le protocole réseau utilisé pour la réplication a été amélioré. Les systèmes 2009.Q3 peuvent effectuer des opérations de réplication sur des systèmes exécutant n'importe quelle version (y compris 2010.Q1 et ultérieures). En revanche, les systèmes exécutant une version 2010.Q1 ou ultérieure peuvent uniquement effectuer des opérations de réplication sur cette même version. En pratique, cela signifie que les cibles doivent être mises à niveau avant ou en même temps que leurs sources de réplication pour éviter toute erreur résultant de versions de protocole incompatibles.

• La configuration de l'action de réplication est maintenant enregistrée dans le pool de stockage lui-même, et non dans le système principal. Par conséquent, après une mise à niveau depuis une version 2009.Q3 ou antérieure vers une version 2010.Q1, les administrateurs doivent appliquer les mises à jour différées pour migrer leur configuration de réplication.

• * Jusqu'à ce que les mises à jour soient appliquées, les mises à jour de réplication entrantes pour les répliques existantes échoueront, et les mises à jour de réplication ne seront pas envoyées pour les actions configurées dans les versions 2009.Q3 ou antérieures. De plus, les répliques non migrées qui ne peuvent pas être gérées dans la BUI ou la CLI utiliseront de l'espace sur le pool de stockage.

• * Une fois que ces mises à jour sont appliquées, comme avec toutes les mises à jour différées, l'annulation du logiciel du système produit des résultats indéfinis. Dans l'ancienne version, il faut s'attendre à ce que les données répliquées soient inaccessibles, à ce que la configuration de toutes les actions de réplication soit annulée et que toutes les mises à jour de réplication entrantes soient des mises à jour complètes.

• Les autorisations ont été déplacées de leur champ d'application vers la portée Projets et partages. Toutes les autorisations de réplication configurées dans les versions 2009.Q3 ou antérieures n'existeront plus dans les versions 2010.Q1. Les administrateurs utilisant un contrôle d'accès plus fin pour la réplication doivent déléguer les nouvelles autorisations de réplication aux administrateurs appropriés une fois la mise à niveau effectuée.