NetBackup™ Snapshot Manager Guide d'installation et de mise à niveau

Échec de la connexion de l'agent Snapshot Manager au serveur Snapshot Manager si l'hôte d'agent est redémarré brusquement

Ce problème peut se produire si l'hôte sur lequel l'agent Snapshot Manager est installé est arrêté brusquement. Même après le redémarrage de l'hôte, l'agent ne parvient pas à établir une connexion avec le serveur Snapshot Manager et passe dans un état hors ligne.

Le fichier journal de l'agent contient l'erreur suivante :

Flexsnap-agent-onhost[4972] mainthread flexsnap.connectors.rabbitmq: error - channel 1 closed unexpectedly: (405) resource_locked - cannot obtain exclusive access to locked queue ' flexsnap-agent.a1f2ac945cd844e393c9876f347bd817' in vhost '/'

Ce problème se produit car la connexion RabbitMQ entre l'agent et le serveur Snapshot Manager ne se ferme pas, même en cas d'arrêt brusque de l'hôte d'agent. Le serveur Snapshot Manager ne peut pas détecter l'indisponibilité de l'agent tant que l'hôte d'agent n'a pas été interrogé. La connexion RabbitMQ reste ouverte jusqu'au prochain cycle d'interrogation. Si l'hôte d'agent redémarre avant le déclenchement de la prochaine interrogation, l'agent essaye d'établir une nouvelle connexion avec le serveur Snapshot Manager. Cependant, étant donné que la connexion RabbitMQ précédente existe déjà, la nouvelle tentative de connexion échoue avec une erreur de ressource verrouillée.

En raison de cet échec de connexion, l'agent est mis hors ligne et entraîne l'échec de toutes les opérations de restauration et de snapshot effectuées sur l'hôte.

Solution de contournement :

Redémarrez le service Veritas Snapshot Manager Agent sur l'hôte d'agent.

L'enregistrement de l'agent Snapshot Manager sur des hôtes Windows peut expirer ou échouer

Pour protéger des applications sous Windows, vous devez installer et enregistrer l'agent Snapshot Manager sur l'hôte Windows. L'enregistrement de l'agent peut parfois dépasser le délai habituel et expirer ou échouer.

Solution de contournement :

Pour résoudre ce problème, procédez comme suit :

Pour en savoir plus, reportez-vous aux sections suivantes :

Se reporter à Enregistrement de l'agent basé sur Windows.

Se reporter à Redémarrage de Snapshot Manager.

Reprise après incident lors de la perte du package de reprise après incident ou de la phrase de passe

Ce problème peut se produire en cas de perte du package DR ou de la phrase de passe.

Dans le cas d'une sauvegarde de catalogue, 2 packages de sauvegarde sont créés :

Le package DR contient les certificats UUID NetBackup et la base de données de catalogue comprend l'UUID. Lorsque vous procédez à une reprise après incident à l'aide du package DR, puis à la récupération de catalogue, le certificat UUID et l'UUID sont restaurés. Cela permet à NetBackup de communiquer avec Snapshot Manager, car l'UUID reste inchangé.

Cependant, l'opération de reprise après incident ne peut pas être réalisée en cas de perte du package DR ou de la phrase de passe. Vous ne pouvez récupérer le catalogue sans le package DR qu'après la réinstallation de NetBackup. Dans ce cas, un nouvel UUID est créé pour NetBackup et Snapshot Manager ne le reconnaît pas. Le mappage un-à-un de NetBackup et Snapshot Manager est perdu.

Solution de contournement :

Pour résoudre ce problème, vous devez mettre à jour le nouvel UUID NBU et le numéro de version une fois le serveur principal NetBackup créé.

Après avoir obtenu l'UUID NBU et le numéro de version, exécutez la commande suivante sur l'hôte Snapshot Manager pour mettre à jour le mappage :

/cloudpoint/scripts/cp_update_nbuuid.sh -i <NBU UUID> -v <Version Number>

Le travail de snapshot aboutit, mais le travail de sauvegarde échoue avec l'erreur « Le certificat Snapshot Manager n'est pas valide ou n'existe pas. (9866) » lorsque le paramètre ECA_CRL_CHECK est désactivé sur le serveur principal.

Si le paramètre ECA_CRL_CHECK est configuré sur le serveur principal et désactivé, la même valeur doit être définie dans le fichier bp.conf de l'installation de Snapshot Manager.

Prenons l'exemple d'une sauvegarde à partir d'un snapshot où le certificat externe utilisé pour la configuration de NetBackup est révoqué. Dans ce cas, si ECA_CRL_CHECK est défini sur DISABLE sur le serveur principal, définissez la même valeur dans le fichier bp.conf de l'installation Snapshot Manager. Si vous ne suivez pas cette procédure, l'opération de snapshot aboutira, mais l'opération de sauvegarde échouera avec l'erreur de certificat.

Se reporter à Configuration de la sécurité pour Azure Stack .

Snapshot Manager ne parvient pas à établir de connexion à l'aide de l'instance de cloud Windows sans agent

Erreur 1 : <Instance_name>: network connection timed out.

Cas 1 : message du journal du serveur Snapshot Manager :

WARNING - Cannot connect to the remote host. SMB Connection timeout
 <IP address> <user>

…

flexsnap.OperationFailed: Could not connect to the remote server 
<IP address>

Solution de contournement :

Pour résoudre ce problème, procédez comme suit :

Cas 2 : message de journal Snapshot Manager :

WARNING - Cannot connect to the remote host. WMI Connection 
timeout <IP address> <user>

…

flexsnap.OperationFailed: Could not connect to the remote 
server <IP address>

Solution de contournement :

Pour résoudre ce problème, procédez comme suit :

Cas 3 : message de journal Snapshot Manager :

Exception while opening SMB connection, [Errno Connection error 
(<IP address>:445)] [Errno 113] No route to host.

Solution de contournement : vérifiez que l'instance de cloud est en cours d'exécution ou que son état n'est pas incohérent.

Cas 4 : message de journal Snapshot Manager :

Error when closing dcom connection: 'Thread-xxxx'"

Où xxxx correspond au nombre de threads.

Solution de contournement :

Pour résoudre ce problème, procédez comme suit :

Erreur 2 : <Instance_name>: Could not connect to the virtual machine.

Message de journal Snapshot Manager :

Error: Cannot connect to the remote host. <IP address> Access denied. 

Solution de contournement :

Pour résoudre ce problème, procédez comme suit :

Les opérations de cloud Snapshot Manager échouent sur un système RHEL si un pare-feu est désactivé

Les opérations Snapshot Manager échouent pour tous les plug-ins cloud pris en charge sur un système RHEL si un pare-feu est désactivé sur ce système alors que les services Snapshot Manager sont en cours d'exécution. Ce problème de configuration réseau empêche Snapshot Manager d'accéder aux terminaux clients d'API REST du fournisseur cloud.

Solution de contournement :

Le travail de sauvegarde à partir d'un snapshot et le travail d'indexation échouent avec les erreurs

Jun 10, 2021 2:17:48 PM - Error mqclient (pid=1054) SSL
Connection failed with string, broker:<hostname>
Jun 10, 2021 2:17:48 PM - Error mqclient (pid=1054) Failed SSL
handshake, broker:<hostname>
Jun 10, 2021 2:19:16 PM - Error nbcs (pid=29079) Invalid
operation for asset: <asset_id>
Jun 10, 2021 2:19:16 PM - Error nbcs (pid=29079) Acknowledgement
not received for datamover <datamover_id>

et/ou

Jun 10, 2021 3:06:13 PM - Critical bpbrm (pid=32373) from client
<asset_id>: FTL - Cannot retrieve the exported snapshot details
for the disk with UUID:<disk_asset_id>
Jun 10, 2021 3:06:13 PM - Info bptm (pid=32582) waited for full
buffer 1 times, delayed 220 times
Jun 10, 2021 3:06:13 PM - Critical bpbrm (pid=32373) from client
<asset_id>: FTL - cleanup() failed, status 6

Ce problème peut se produire lorsque l'accès entrant à Snapshot Manager sur les ports 5671 et 443 est bloqué au niveau du pare-feu du système d'exploitation (firewalld). La communication entre le conteneur du datamover (utilisé pour les travaux de sauvegarde à partir d'un snapshot et les travaux d'indexation) et Snapshot Manager est donc bloquée. Le conteneur du système de déplacement de données ne peut donc pas démarrer la sauvegarde ou l'indexation.

Solution de contournement :

Configurez les règles du pare-feu du système d'exploitation de façon à autoriser la connexion entrante sur les ports 5671 et 443.

La connexion sans agent échoue pour une machine virtuelle avec un message d'erreur.

La connexion sans agent échoue pour une machine virtuelle avec le message d'erreur suivant lorsque l'authentification par clé SSH d'une machine virtuelle est remplacée par une authentification par mot de passe via le portail :

User does not have the required privileges to establish an agentless connection

Ce problème se produit lorsque les autorisations ne sont pas correctement définies pour l'utilisateur dans le fichier sudoers, comme indiqué dans le message d'erreur ci-dessus.

Solution de contournement :

Résolvez le problème de fichier sudoers pour l'utilisateur en fournissant les autorisations requises pour exécuter les opérations sudo sans mot de passe.

La fonction Snapshot Manager échoue lorsque Snapshot Manager est déployé dans un sous-réseau privé (sans Internet)

Ce problème se produit lorsque Snapshot Manager est déployé dans un réseau privé dans lequel le pare-feu est activé ou l'adresse IP publique est désactivée. L'équipe en charge de la sécurité des informations du client n'accorde pas à la machine virtuelle un accès complet à Internet.

Solution de contournement :

Activez les ports à partir de la ligne de commande du pare-feu à l'aide des commandes suivantes :

firewall-cmd --add-port=22/tcp

firewall-cmd --add-port=5671/tcp

firewall-cmd --add-port=443/tcp

La restauration d'un bien à partir d'une copie de sauvegarde échoue

Dans certains cas, une réinitialisation intermittente de la connexion se produit dans le conteneur Docker. La charge utile TCP envoyée par le serveur est alors supérieure à ce qu'indique la fenêtre du client. Le conteneur Docker supprime parfois le paquet SYN+ACK du nouveau protocole de connexion TCP. Pour autoriser ces paquets, utilisez l'option nf_conntrack_tcp_be_liberal.

Si nf_conntrack_tcp_be_liberal = 1, les paquets suivants sont autorisés :

Si nf_conntrack_tcp_be_liberal = 0, ils sont également considérés comme non valides et rejetés.

Solution de contournement :

Pour résoudre le problème de la restauration à partir de la copie de sauvegarde, définissez l'option nf_conntrack_tcp_be_liberal = 1 sur le nœud sur lequel s'exécute le conteneur du datamover.

Utilisez la commande suivante pour définir la valeur de nf_conntrack_tcp_be_liberal :

sysctl -w net.netfilter.nf_conntrack_tcp_be_liberal=1

Certains pods de l'extension Kubernetes sont passés à l'état Terminé.

Solution de contournement :

Désactivez l'extension Kubernetes.

Supprimez le pod d'écoute à l'aide de la commande suivante :

#kubectl delete pod flexnsap-listener-xxxxx -n <namespace>

Activez l'extension Kubernetes.

L'utilisateur ne peut pas personnaliser un plan de protection cloud

Solution de contournement :

Créez un plan de protection avec la configuration souhaitée et attribuez-le au bien.

Le conteneur Podman ne démarre pas ou les conteneurs ne sont pas opérationnels après un redémarrage

Sur la plate-forme RHEL 8.x, le message d'erreur suivant s'affiche après le redémarrage d'un conteneur ou d'un ordinateur :

# podman restart flexsnap-coordinator 47ca97002e53de808cb8d0526ae033d4b317d5386ce085a8bce4cd434264afdf:
 "2022-02-05T04:53:42.265084989+00:00 Feb 05 04:53:42 flexsnap-coordinator flexsnap-coordinator[7] 
agent_container_health_check flexsnap.container_manager: INFO - Response: b'{""cause"":""that name is already in use"",""message"":
""error creating container storage: the container name \\""flexsnap-agent.15bd0aea11164f7ba29e944115001d69\\"" is already in use by 
\\""30f031d586b1ab524511601aad521014380752fb127a9440de86a81b327b6777\\"". You have to remove that container to be able to reuse that
 name.: that name is already in use"",""response"":500}\n'"

Solution de contournement :

Sous l'emplacement /var/lib/cni/networks/flexsnap-network/ sur le système de fichiers, recherchez un fichier contenant une entrée d'adresse IP mappée avec le conteneur qui n'a pas pu démarrer.

[ec2-user@ip-172-31-44-163 ~]$ ls -latr /var/lib/cni/networks/flexsnap-network/ total 16 -rwxr-x---. 1 root root 0 Jan 22 12:30 lock drwxr-xr-x. 4 root root 44 Jan 22 12:30 .. -rw-r--r--. 1 root root 70 Feb 4 14:47 10.89.0.150 -rw-r--r--. 1 root root 70 Feb 4 14:47 10.89.0.151 -rw-r--r--. 1 root root 70 Feb 4 14:47 10.89.0.152 -rw-r--r--. 1 root root 11 Feb 7 11:09 last_reserved_ip.0 drwxr-xr-x. 2 root root 101 Feb 7 11:13 . [ec2-user@ip-172-31-44-163 ~]$

Dans le répertoire ci-dessus, supprimez le fichier d'adresse IP dupliqué et effectuez les opérations suivantes :

Arrêtez le conteneur : #podman stop <container_name>

Démarrez le conteneur : #podman start <container_name>

Après le démarrage des services de démarrage/d'arrêt, les conteneurs Snapshot Manager, RabbitMQ et MongoDB sont toujours à l'état de démarrage

Les conteneurs flexsnap-mongodb et flexsnap-rabbitmq ne sont pas passés à l'état de fonctionnement. L'état du conteneur flexsnap-mongodb est le suivant :

[ec2-user@ip-172-31-23-60 log]$ sudo podman container inspect --format='{{json .Config.Healthcheck}}'
flexsnap-mongodb {"Test":["CMD-SHELL","echo 'db.runCommand({ping: 1}).ok' 
| mongo --ssl --sslCAFile /cloudpoint/keys/cacert.pem 
--sslPEMKeyFile /cloudpoint/keys/mongodb.pem flexsnap-mongodb:27017/zenbrain --quiet"],
"Interval":60,"Timeout":30000000000,"Retries":3} [ec2-user@ip-172-31-23-60 log]$ sudo podman container inspect --format='
{{json .State.Healthcheck}}' flexsnap-mongodb {"Status":"starting","FailingStreak":0,"Log":null} [ec2-user@ip-172-31-23-60 log]$

Solution de contournement :

Exécutez la commande #podman suivante depuis l'interface de ligne de commande :

[ec2-user@ip-172-31-23-60 log]$ sudo podman healthcheck run flexsnap-mongodb

[ec2-user@ip-172-31-23-60 log]$ sudo podman ps -a

CONTAINER ID  IMAGE                          COMMAND  CREATED      STATUS                  PORTS                      NAMES

fe8cf001032b  localhost/veritas/

  flexsnap-fluentd:10.0.0.0.9817         2 days ago    Up 45 hours ago      0.0.0.0:24224->24224/tcp  flexsnap-fluentd

2c00500c1ac6  localhost/veritas/

  flexsnap-mongodb:10.0.0.0.9817         2 days ago    Up 45 hours ago (healthy)                      flexsnap-mongodb

7ab3e248024a  localhost/veritas/

  flexsnap-rabbitmq:10.0.0.0.9817        2 days ago    Up 45 hours ago (starting)                     flexsnap-rabbitmq

[ec2-user@ip-172-31-23-60 log]$ sudo podman healthcheck run flexsnap-rabbitmq

[ec2-user@ip-172-31-23-60 log]$ sudo podman ps -a

CONTAINER ID  IMAGE                           COMMAND  CREATED       STATUS                   PORTS                   NAMES

fe8cf001032b  localhost/veritas/

  flexsnap-fluentd:10.0.0.0.9817        2 days ago    Up 45 hours ago          0.0.0.0:24224->24224/tcp  flexsnap-fluentd

2c00500c1ac6  localhost/veritas/

  flexsnap-mongodb:10.0.0.0.9817        2 days ago    Up 45 hours ago (healthy)                          flexsnap-mongodb

7ab3e248024a  localhost/veritas/

  flexsnap-rabbitmq:10.0.0.0.9817       2 days ago    Up 45 hours ago (healthy)                          flexsnap-rabbitmq

 [ec2-user@ip-172-31-23-60 log]$ sudo podman container inspect --format='{{json .State.Healthcheck}}' flexsnap-mongodb

{"Status":"healthy","FailingStreak":0,"Log":

[{"Start":"2022-02-14T07:32:13.051150432Z","End":"2022-02-14T07:32:13.444636429Z","ExitCode":0,"Output":""}]}

[ec2-user@ip-172-31-23-60 log]$ sudo podman container inspect --format='{{json .State.Healthcheck}}' flexsnap-rabbitmq

{"Status":"healthy","FailingStreak":0,"Log":

[{"Start":"2022-02-14T07:32:46.537804403Z","End":"2022-02-14T07:32:47.293695744Z","ExitCode":0,"Output":""}]}

[ec2-user@ip-172-31-23-60 log]$

La génération du certificat échoue lors de l'enregistrement de Snapshot Manager auprès de NetBackup

À partir de la version 9.1.2 de Snapshot Manager, la génération de certificats NetBackup est synchronisée avec l'enregistrement dans l'API de registre de Snapshot Manager. Cela signifie que l'échec de la génération d'un certificat entraînera l'échec de l'enregistrement de Snapshot Manager auprès de NetBackup (ajout ou modification de l'entrée Snapshot Manager à partir de l'interface utilisateur Web). Ces certificats sont utilisés pour le datamover qui est lancé pour des opérations telles que la sauvegarde à partir d'un snapshot, la restauration à partir d'une sauvegarde, l'indexation (basée sur VxMS), etc. Si la génération du certificat échoue, ces travaux ne peuvent pas être exécutés. Snapshot Manager sur des machines virtuelles cloud ne peut donc pas se connecter à NetBackup sur des machines virtuelles de laboratoire, ce qui signifie que l'enregistrement échouera et que Snapshot Manager ne pourra pas être ajouté à NetBackup.

Solution de contournement :

Pour ajouter Snapshot Manager dans ce type de situation, vous devez ignorer la génération du certificat sur Snapshot Manager en ajoutant l'entrée suivante dans le fichier /cloudpoint/flexsnap.conf :

[client_registration] skip_certificate_generation = yes

Le délai d'expiration par défaut de 6 heures ne permet pas la restauration d'une base de données de plus de 300 Go

Solution de contournement :

La valeur du paramètre de délai d'expiration configurable peut être définie de façon à permettre la restauration d'une base de données plus volumineuse. La valeur du délai peut être spécifiée dans le fichier /etc/flexsnap.conf du conteneur flexsnap-coordinator. Il n'est pas nécessaire de redémarrer le conteneur de coordination. La valeur du délai d'expiration sera récupérée lors du prochain travail de restauration de la base de données.

L'utilisateur doit spécifier le délai d'expiration en secondes comme suit :

docker exec -it flexsnap-coordinator bash root@flexsnap-coordinator:/# cat /etc/flexsnap.conf [global] target = flexsnap-rabbitmq grt_timeout = 39600

La connexion sans agent et la restauration granulaire sur l'hôte restauré échouent lorsque 50 étiquettes sont associées à la machine virtuelle restaurée à partir d'une sauvegarde

Solution de contournement :

(Pour AWS) Si une machine virtuelle Windows restaurée à partir d'une sauvegarde comporte 50 étiquettes, et si aucune étiquette de plate-forme n'existe, vous pouvez supprimer n'importe quelle étiquette non requise et ajouter l'étiquette Platform: windows.

Pour certaines versions de GKE, des problèmes de pod en échec se produisent au niveau de l'espace de noms

Les pods ci-dessous échouent dans l'espace de noms et affichent l'état d'échec NodeAffinity :

$ kubectl get pods -n <cp_extension_namespace>

NAME                                        READY     STATUS       RESTARTS     AGE
flexsnap-datamover-
2fc2967943ba4ded8ef653318107f49c-664tm        0/1     Terminating    0          4d14h
flexsnap-fluentd-collector-c88f8449c-5jkqh    0/1     NodeAffinity   0          3d15h
flexsnap-fluentd-collector-c88f8449c-ph8mx    0/1     NodeAffinity   0          39h
flexsnap-fluentd-collector-c88f8449c-rqw7w    1/1     Running        0          10h
flexsnap-fluentd-collector-c88f8449c-sswzr    0/1     NodeAffinity   0          5d18h
flexsnap-fluentd-ftlnv                        1/1     Running        3 (10h ago)10h
flexsnap-listener-84c66dd4b8-6l4zj            1/1     Running        0          10h
flexsnap-listener-84c66dd4b8-ls4nb            0/1     NodeAffinity   0          17h
flexsnap-listener-84c66dd4b8-x84q8            0/1     NodeAffinity   0          3d15h
flexsnap-listener-84c66dd4b8-z7d5m            0/1     NodeAffinity   0          5d18h
flexsnap-operator-6b7dd6c56c-cf4pc            1/1     Running        0          10h
flexsnap-operator-6b7dd6c56c-qjsbs            0/1     NodeAffinity   0          5d18h
flexsnap-operator-6b7dd6c56c-xcsgj            0/1     NodeAffinity   0          3d15h
flexsnap-operator-6b7dd6c56c-z86tc            0/1     NodeAffinity   0          39h

Cependant, ces échecs n'affectent pas le fonctionnement de l'extension Kubernetes Snapshot Manager.

Solution de contournement :

Nettoyez manuellement les pods en échec à l'aide de la commande suivante :

kubectl get pods -n <cp_extension_namespace> | grep NodeAffinity | awk '{print $1}' | xargs kubectl delete pod -n <cp_extension_namespace>

Les informations du plug-in sont dupliquées si des tentatives précédentes d'enregistrement de Snapshot Manager ont échoué

Ce problème se produit uniquement lorsque Snapshot Manager a été déployé à l'aide du mécanisme de déploiement du marketplace. Lorsque les informations de plug-in sont ajoutées avant l'enregistrement, des informations de plug-in sont créées en double dans le fichier CloudPoint_plugin.conf.

Solution de contournement :

Supprimez manuellement les informations de plug-in en double dans le fichier CloudPoint_plugin.conf.

Dans l'exemple suivant, l'entrée en double pour la configuration du plug-in GCP est visible (en gras) dans le fichier CloudPoint_plugin.conf :

{
    "CPServer1": [
      {
        "Plugin_ID": "test",
        "Plugin_Type": "aws",
        "Config_ID": "aws.8dda1bf5-5ead-4d05-912a-71bdc13f55c4",
        "Plugin_Category": "Cloud",
        "Disabled": false
      }
    ]
  },
  {
    "CPServer2": [
      {
        "Plugin_ID": "gcp.2080179d-c149-498a-bf1f-4c9d9a76d4dd",
        "Plugin_Type": "gcp",
        "Config_ID": "gcp.2080179d-c149-498a-bf1f-4c9d9a76d4dd",
        "Plugin_Category": "Cloud",
        "Disabled": false
      },
      {
        "Plugin_ID": "gcp.2080179d-c149-498a-bf1f-4c9d9a76d4dd",
        "Plugin_Type": "gcp",
        "Config_ID": "gcp.2080179d-c149-498a-bf1f-4c9d9a76d4dd",
        "Plugin_Category": "Cloud",
        "Disabled": false
      }
    ]
  }

Les informations du plug-in sont dupliquées si le Snapshot Manager cloné est ajouté à NetBackup

Cela se produit uniquement lorsque le Snapshot Manager cloné est ajouté à NetBackup lors de la migration de Snapshot Manager vers une machine virtuelle RHEL 8.6. Le clonage de Snapshot Manager utilise le volume Snapshot Manager existant pour créer un nouveau Snapshot Manager, ce qui entraîne la création d'un doublon d'entrée dans le fichier CloudPoint_plugin.conf.

Solution de contournement :

Modifiez et supprimez manuellement les informations de plug-in en double dans le fichier CloudPoint_plugin.conf.

Dans l'exemple suivant, l'entrée en double pour la configuration du plug-in Azure est visible (en gras) dans le fichier CloudPoint_plugin.conf :

{
    "CPServer1": [
      {
        "Plugin_ID": "config10",
        "Plugin_Type": "azure",
        "Config_ID": "azure.327ec7fc-7a2d-4e94-90a4-02769a2ba521",
        "Plugin_Category": "Cloud",
        "Disabled": false
      }
    ]
  },
  {
    "CPServer2": [
      {
        "Plugin_ID": "azure.327ec7fc-7a2d-4e94-90a4-02769a2ba521",
        "Plugin_Type": "azure",
        "Config_ID": "azure.327ec7fc-7a2d-4e94-90a4-02769a2ba521",
        "Plugin_Category": "Cloud",
        "Disabled": false
      },
       {
    "cpserver101.yogesh.joshi2-dns-zone": [
      {
        "Plugin_ID": "azure.327ec7fc-7a2d-4e94-90a4-02769a2ba521",
        "Plugin_Type": "azure",
        "Config_ID": "azure.327ec7fc-7a2d-4e94-90a4-02769a2ba521",
        "Plugin_Category": "Cloud",
        "Disabled": false
      },
      {
        "Plugin_ID": "AZURE_PLUGIN",
        "Plugin_Type": "azure",
        "Config_ID": "azure.4400a00a-8d2b-4985-854a-74f48cd4567e",
        "Plugin_Category": "Cloud",
        "Disabled": false
      }
    ]
  }
 ]
}