La migration des systèmes informatiques n'est pas une tâche facile. Mais la difficulté particulière est la situation où vous devez non seulement passer de l'ancien fer au nouveau, mais passer à un nouveau système d'exploitation sur les équipements existants, et sans migrer les données productives. Un de ces mouvements a duré environ un an, dont la plupart ont nécessité une préparation.
Le client dispose de deux sites dans différentes villes et chacun a deux systèmes de stockage de données connectés. Les informations d'un système de stockage utilisant les outils de réplication intégrés sont envoyées au second. La gestion est effectuée à l'aide d'un système de sauvegarde externe. Dans une ville, deux systèmes NetApp 3250 sont installés, dans l'autre - le NetApp 6220 principal et le NetApp 3250 de sauvegarde. Le client prévoit d'étendre ce complexe à l'avenir, d'ajouter des disques et de mettre à niveau les contrôleurs.
Fig. 1 Schéma d'interaction des systèmes de stockage et IBSEt le principal problème est lié à cela - la fin du support. Pour le système d'exploitation Data ONTAP 8.2 à 7 modes installé sur le système de stockage, il n'y a eu aucune mise à jour majeure depuis quelques années et la publication des corrections d'erreurs critiques s'arrêtera en 2021. Les lecteurs et contrôleurs plus récents ne sont pas compatibles avec le système d'exploitation hérité.
La solution est la transition vers le système de cluster ONTAP 9.1 en tant que dernier système pris en charge pour ces contrôleurs de stockage. Ses principaux avantages sont:
- Mise à l'échelle horizontale en se combinant en un seul cluster à tolérance de panne, ce qui vous permettra de créer un système unique basé sur un stockage productif et SRK.
- Équilibrage de la charge entre les contrôleurs, les disques, ainsi que le déplacement des données à l'intérieur du système de stockage sans interrompre le service et arrêter l'accès aux applications.
- Maintenance du matériel et des logiciels des systèmes de stockage de données sans interruption de leur travail et interruption de service.
- La possibilité de créer des configurations de cluster hétérogènes, y compris des contrôleurs et des disques de différents types, y compris des systèmes de stockage tiers, sous réserve de l'utilisation de licences pour la virtualisation de leur capacité de disque.
- Possibilité d'utiliser SSD comme couche de cache pour les agrégats.
- Fonctionnement optimisé des mécanismes de Data Compaction (compression et déduplication).
Il existe 3 options pour migrer du mode 7 vers le mode cluster:
- Migration avec réplication de données à l'aide de l'outil de transition Netapp 7 modes (7MTT) et de la transition basée sur la copie (CBT). Pour cela, un deuxième système de stockage avec un espace disque plus petit et une réplication progressive basée sur SnapMirror est requis. Pour chaque service, la commutation est coordonnée et effectuée à un moment donné.
Chez l'un de nos clients, nous avons déjà effectué cette procédure sur le cluster métro. En raison du grand nombre de volumes, de LUN (> 400) et de la longue coordination des détails, des temps d'arrêt, etc. la migration a pris environ 3 mois, hors formation. - Migrez sans déplacer les données à l'aide de l'outil de transition Netapp 7 modes (7MTT) et de la transition sans copie (CFT). Pour ce faire, vous avez besoin d'un deuxième système de stockage avec un nombre minimum de disques qui, après une préparation préalable, basculera le sous-système de disques productifs. Pour tous les services, un temps d'arrêt important est convenu.
- Migration avec copie des données à l'aide des outils hôtes. Il s'agit du chemin de migration traditionnel entre les systèmes de stockage de tous les fabricants.
Étant donné que les systèmes de stockage existants étaient toujours pris en charge par le fournisseur et que les performances des contrôleurs dans un avenir proche étaient suffisantes, le budget pour l'achat de nouveaux contrôleurs n'a pas été alloué. À cet égard, il a été décidé de migrer les contrôleurs en mode cluster à l'aide de 7MTT CFT. L'une des principales exigences était l'absence d'interruptions notables dans le fonctionnement des systèmes de stockage: la plupart des systèmes devraient fonctionner correctement en semaine. Par conséquent, le travail principal sur la migration sur un système de stockage productif était prévu pour le week-end.
La phase de préparation a commencé par la collecte d'informations dans le système de stockage et la réalisation de contrôles préliminaires. Le logiciel NetApp 7MTT spécialisé génère une liste d'alertes qui peuvent interférer avec la migration ou ne pas la terminer. Par exemple, pour l'un des systèmes, cette liste comprenait plus de 200 éléments. Il était nécessaire de mettre à jour tous les systèmes vers les dernières versions prises en charge du système d'exploitation, de mettre à jour le micrologiciel des contrôleurs, des étagères à disques et des disques eux-mêmes. De plus, le nouveau système d'exploitation a une logique de fonctionnement différente, nécessitant des adresses IP et des connexions supplémentaires entre les systèmes de stockage.
Le facteur d'arrêt a été découvert assez rapidement - le client a utilisé une technologie basée non pas sur la réplication de volume entière, mais sur la réplication qtree (une sous-section à laquelle des restrictions d'accès, de volume, etc. s'appliquent). Et il est impossible de migrer de telles relations SnapVault vers le nouveau système d'exploitation. . Par conséquent, avant de commencer le travail, il serait nécessaire de supprimer complètement toutes les copies de réplication. Pour garantir que le client après le déplacement ne soit pas laissé sans sauvegardes, une sauvegarde basée sur la réplication de volume entière a été démarrée avant la migration. À l'aide de SnapMirror, de nouvelles sauvegardes ont été créées à côté des anciennes et un journal des modifications a été accumulé en quatre semaines. Et si sur l'un des sites il y avait suffisamment d'espace pour cela, alors sur le deuxième espace était limité, il fallait faire progressivement des copies d'un des volumes. Après quatre semaines, les anciennes relations ont été supprimées et de nouvelles ont été créées. Un processus assez long et échelonné, qui a pris environ 1,5 mois dans le cas d'un site et plus de 3 dans le second. De plus, je tiens à noter que la procédure d'arrêt de la relation Snapvault s'accompagne de la suppression du qtree cible et que sa vitesse d'exécution dépend fortement du nombre de fichiers et dans une moindre mesure de sa taille. Par exemple, qtree avec 4 millions de fichiers et une taille de 500 Go a été supprimé en 24 heures.
Ce faisant, diverses difficultés sont apparues. La bureaucratisation des processus de modification des systèmes clients a augmenté les conditions de coordination du travail. Heureusement, nous avons réussi à convenir de résoudre directement les problèmes techniques, en ne discutant à un niveau supérieur que les problèmes «idéologiques» importants, tels que convenir d'un plan de travail et choisir des dates spécifiques pour la migration.
Des difficultés ont été causées par l'utilisation d'un stockage temporaire. Sous la direction de 7MTT, nous avons configuré les deux systèmes de stockage selon les exigences et les pré-contrôles. Ensuite, ils ont éteint l'ancien stockage et connecté les étagères à disques au nouveau. J'ai tout vérifié à nouveau. Du point de vue du logiciel NetApp, le processus de migration est terminé et tout le monde se disperse
derrière le champagne . Mais l'étape suivante consistait à tout renvoyer aux anciens contrôleurs clients. Le fait est qu'une telle transition - des nouveaux contrôleurs aux anciens - n'est pas officiellement prise en charge. Après être revenu en arrière, le système d'exploitation a commencé à verser des erreurs et à se plaindre de problèmes avec le cluster. Après la recherche, j'ai pu découvrir que le problème est dû au fait que le cluster est soudainement passé en mode commuté et ne voulait pas revenir en mode sans commutateur. Il a fallu beaucoup de temps pour corriger l'erreur. Les problèmes de lancement de cluster ont été résolus en ne connectant pas les câbles menant au réseau de combat au démarrage, le réseau intra-cluster a été levé sur un câble, puis le second a été ajouté. Soit dit en passant, il faut se rappeler que sur les anciens contrôleurs et les anciennes versions du système d'exploitation, le réseau intra-cluster ne peut être augmenté que sur certains ports d'une gamme limitée d'adaptateurs, par exemple, sur le FAS3250, il s'agit de e1a et e2a (le client devait acheter des cartes Ethernet 10 Go).
Ils ont accordé du temps supplémentaire pour travailler sur le deuxième site, espérant éviter au moins certains des problèmes, mais cela n'a pas aidé - le système d'exploitation s'est comporté de manière imprévisible. Le graphique a été déplacé deux fois. Dans le premier cas, lorsque nous travaillions avec le FAS3250, il n'était pas possible de migrer les systèmes de combat fonctionnant 24h / 24 et 7j / 7 en raison d'une erreur dans les paramètres récemment modifiés de l'infrastructure réseau du client (bien que lors du test de la migration une semaine avant le début des travaux, tout s'est déroulé). vMotion a copié des machines virtuelles à une vitesse inférieure à 1 Mbps sur un système de stockage distant.
Lors de la migration, le client a partiellement modifié l'architecture. Les volumes qui ont été distribués à leur infrastructure VMware vSphere étaient précédemment émis via Ethernet NFS. Le client les a refaits et ils sont passés à Fibre Channel. Au cours du processus de migration, il s'est avéré que le LUN a complètement changé son ID et, en conséquence, VMware a vu de nouveaux LUN qui lui étaient adressés avec d'anciennes données et a refusé de les connecter de manière permanente. En conséquence, grâce à l'aide de spécialistes VMware, il a été possible de connecter ces LUN via la console sur une base continue, indiquant qu'il s'agit d'un instantané des anciennes banques de données. Ensuite, j'ai dû redémarrer les hôtes VMware. En conséquence, ils ont réussi à voir les machines virtuelles et à augmenter l'infrastructure virtuelle. Et si le client continuait à utiliser NFS, un tel problème ne se serait pas posé - l'adresse IP et le nom DNS sont restés les mêmes qu'auparavant.
Le plan de travail directement les jours de migration:
Vendredi: travailler avec les systèmes de stockage et IBS
- Ils ont interrompu toutes les relations entre SnapVault et SnapMirror, changé de stockage temporaire et vérifié que les systèmes étaient prêts pour la migration. Nous avons commencé les procédures de migration du stockage vers 7MTT à l'aide de la méthode de transition sans copie. Reconnexion des régiments de disques de combat au contrôleur temporaire.
- Migration vers 7MTT, migration du volume racine des contrôleurs de remplacement vers les étagères de disque du système de stockage du SRK. Nous avons installé de nouveaux adaptateurs Ethernet, lancé le système de stockage SRK, effacé la configuration et téléchargé l'image du système d'exploitation sur le réseau à partir du serveur HTTP. Nous avons installé de nouvelles versions du firmware et du système d'exploitation (à ce stade, il y avait des problèmes inexpliqués avec le téléchargement de l'image sur le réseau. Au final, elle a été téléchargée directement depuis l'ordinateur portable).
- Nous avons remplacé les contrôleurs du cluster par des anciens et connecté les étagères des disques de bataille au système de stockage à l'aide de la procédure de mise à niveau en déplaçant le stockage. Nous avons restauré le cluster, reconfiguré les interfaces réseau (j'ai dû résoudre des problèmes liés au mauvais fonctionnement du cluster) et installé les clés de licence.
Samedi: travail avec le stockage principal
- Nous avons connecté des étagères de disque temporaires à un stockage temporaire et l'avons à nouveau installé.
- Les machines virtuelles importantes ont migré vers le stockage vers un centre de données distant à l'aide de VMware vMotion.
- Les principaux systèmes de stockage ont été migrés vers 7MTT en utilisant la méthode CFT. Ils ont désactivé le stockage de combat principal, connecté ses étagères de disque au contrôleur et converti les métadonnées du système d'exploitation en 7MTT. Le volume racine des contrôleurs de swap a migré vers les étagères de disque du système de stockage SRK.
- Nous avons installé de nouveaux adaptateurs Ethernet et lancé le stockage de combat dans une configuration sans disque, effacé les paramètres, puis téléchargé sur le réseau depuis le serveur HTTP. Installé de nouvelles versions de firmware et OS. Nous avons remplacé les contrôleurs du cluster, connecté les étagères des disques de combat au système de stockage à l'aide de la procédure de mise à niveau en déplaçant le stockage.
- Restaurer le cluster, reconfigurer les interfaces réseau (bricolage avec le cluster fonctionnant incorrectement en raison des interfaces réseau de combat connectées). Clés de licence installées.
- Nous avons restauré les connexions de stockage aux serveurs VMware, modifié le zonage dans le réseau SAN, configuré le mappage des LUN, déplacé les volumes vers un SVM distinct pour travailler avec l'accès FC. LUN connecté à ESXi. Étant donné que l'ID de LUN a changé, les banques de données n'apparaissaient pas en mode automatique, j'ai dû redémarrer systématiquement les serveurs ESXi et connecter les LUN avec des commandes via esxcli.
- Interfaces de combat reconfigurées, serveurs CIFS renommés et accès retrouvé aux balles CIFS et aux exportations NFS.
Dimanche: résolution de problèmes et configuration du logiciel IBS
- Les machines virtuelles ont migré du système de stockage vers le système de stockage de combat.
- Nous avons résolu le problème d'accès au dossier en mode enregistrement à partir de l'hôte Linux. Nous avons déployé la dernière version du logiciel de surveillance Netapp onCommand Unified Manager 7.3 et y avons connecté les deux systèmes de stockage.
- Nous avons analysé les données sur la charge actuelle des unités à l'aide du logiciel Unified Manager, en utilisant le SSD, nous avons connecté la couche de mise en cache aux unités de disque existantes (Flash / Storage Pool).
- Ils ont désactivé le système de stockage alternatif, créé des liens de cluster (Peering de cluster, Peering SVM) afin que la réplication puisse être utilisée. Nous avons créé de nouvelles relations SnapMirror entre le stockage principal et le stockage SRK en fonction des volumes existants (qui étaient utilisés dans les relations en mode SnapMirror 7) avec resynchronisation des données modifiées, puis converti les relations SnapMirror en relations SnapVault (SnapMirror XDP).
- Nous avons connecté les deux systèmes de stockage au logiciel Commvault SRC en mode NetApp Open Replication en utilisant le support technique de Commvault, cela ne fonctionnait pas différemment, bien que nous ayons tout fait conformément aux instructions. Configuration de l'envoi des journaux Autosupport à partir du stockage de combat et des systèmes de stockage du SRK.
Lundi: broyage
- Vérification du fonctionnement des principaux systèmes de stockage productifs et de stockage du système de stockage. Résolution d'éventuels problèmes et dysfonctionnements.
- Déconnexion et démontage des équipements temporaires.
La migration elle-même n'a pris que deux jours. Le déménagement a réussi, toutes les données clients sont saines et sauves. Le système de gestion des sauvegardes et l'intégration avec le logiciel SRK existant ont également été préservés. Si vous avez déjà utilisé le bundle Commvault avec OnCommand Unified Manager, puis après être passé en mode cluster, il a été décidé de l'abandonner en faveur de Netapp Open Replication pour connecter Commvault directement aux contrôleurs de stockage.
Les principales recommandations que je peux donner en fonction des résultats de cette migration: passer du mode 7 au mode cluster avec remplacement des contrôleurs. Si vous prévoyez toujours de passer aux deuxièmes contrôleurs, comme dans le cas décrit ci-dessus, vous devez prévoir suffisamment de temps pour résoudre divers problèmes qui se poseront nécessairement lors du retour aux anciens contrôleurs. L'utilisation de la migration sans déplacer les données à l'aide de 7MTT CFT est une procédure totalement sûre, si les professionnels lui font confiance.
Guides utiles utilisés lors de cette migration:
Dmitry Kostryukov, Ingénieur principal de conception des systèmes de stockage
Centre de conception de complexes informatiques "Jet Infosystems"