Risolvere gli errori del servizio SBD nei cluster RHEL Pacemaker

Si applica a: ✔️ macchine virtuali Linux

Questo articolo illustra scenari comuni in cui il servizio STONITH Block Device (SBD) non viene avviato in un cluster Red Hat Enterprise Server (RHEL) Pacemaker e fornisce indicazioni per identificare e risolvere questo problema.

Funzionamento di SBD

Il dispositivo SBD richiede almeno una macchina virtuale (VM) aggiunta che funga da server di destinazione iSCSI (Internet Small Computer System Interface) e fornisce un dispositivo SBD. Questi server di destinazione iSCSI possono anche essere condivisi con altri cluster Pacemaker. Il vantaggio dell'uso di un dispositivo SBD consiste nel fatto che se già si usano dispositivi SBD in locale, tali dispositivi non richiedono alcuna modifica alla modalità di utilizzo del cluster Pacemaker.

Per configurare un cluster Di Azure Pacemaker con il meccanismo di isolamento SBD, usare una delle due opzioni seguenti:

• SBD con un server di destinazione iSCSI

• SBD con un disco condiviso di Azure

Sintomi

Il dispositivo SBD non è accessibile nei nodi del cluster. In questo caso, il daemon SBD non viene avviato e impedisce l'avvio del cluster Pacemaker.

Per ottenere i dettagli del server SBD, usare i metodi seguenti nei nodi del cluster:

• Controllare i log nel file /var/log/messages .
• Controllare l'output del iscsiadm discovery comando.
• Controllare lo stato del servizio iSCSI che indica gli indirizzi IP del server SBD.

Scenario 1: Il servizio SBD non viene avviato a causa di errori del servizio iSCSI

I servizi iSCSI usano iSCSI Qualified Name (IQN) per la comunicazione tra i nodi iniziatori e di destinazione. Se i servizi iSCSI hanno esito negativo, i dischi SBD diventano inaccessibili, causando l'avvio del servizio SBD e l'esecuzione del servizio Pacemaker nei nodi del cluster.

Gli esempi seguenti illustrano come diagnosticare gli errori del servizio SBD e Pacemaker:

1. Controllare lo stato del cluster Pacemaker:

   sudo pcs status
   

   Se il cluster Pacemaker non viene eseguito, verrà visualizzato l'output del comando simile al testo seguente:

   Error: error running crm_mon, is pacemaker running?
     error: Could not connect to launcher: Connection refused
     crm_mon: Connection to cluster failed: Connection refused
   

2. Controllare lo stato del servizio Corosync:

   sudo systemctl status corosync
   

   Se il servizio Corosync è in esecuzione, verrà visualizzato l'output del comando simile al testo seguente:

   ● corosync.service - Corosync Cluster Engine
        Loaded: loaded (/usr/lib/systemd/system/corosync.service; enabled; preset: disabled)
        Active: active (running) since Thu 2024-08-01 11:22:28 UTC; 1min 22s ago
          Docs: man:corosync
                man:corosync.conf
                man:corosync_overview
      Main PID: 12793 (corosync)
         Tasks: 9 (limit: 48956)
        Memory: 113.9M
           CPU: 401ms
        CGroup: /system.slice/corosync.service
                └─12793 /usr/sbin/corosync -f
   
   Aug 01 11:22:43 node1 corosync[12793]:   [KNET  ] link: Resetting MTU for link 0 because host 2 joined
   Aug 01 11:22:43 node1 corosync[12793]:   [KNET  ] host: host: 2 (passive) best link: 0 (pri: 1)
   Aug 01 11:22:43 node1 corosync[12793]:   [KNET  ] pmtud: PMTUD link change for host: 2 link: 0 from 469 to 1397
   Aug 01 11:22:43 node1 corosync[12793]:   [KNET  ] pmtud: Global data MTU changed to: 1397
   Aug 01 11:22:45 node1 corosync[12793]:   [QUORUM] Sync members[2]: 1 2
   Aug 01 11:22:45 node1 corosync[12793]:   [QUORUM] Sync joined[1]: 2
   Aug 01 11:22:45 node1 corosync[12793]:   [TOTEM ] A new membership (1.3e) was formed. Members joined: 2
   Aug 01 11:22:45 node1 corosync[12793]:   [QUORUM] This node is within the primary component and will provide service.
   Aug 01 11:22:45 node1 corosync[12793]:   [QUORUM] Members[2]: 1 2
   Aug 01 11:22:45 node1 corosync[12793]:   [MAIN  ] Completed service synchronization, ready to provide service.
   

3. Controllare lo stato del servizio Pacemaker:

   sudo systemctl status pacemaker
   

   Il servizio SBD è necessario per l'avvio del servizio Pacemaker. Se il servizio Pacemaker non viene avviato a causa di errori di dipendenza, verrà visualizzato l'output del comando simile al testo seguente:

   ○ pacemaker.service - Pacemaker High Availability Cluster Manager
        Loaded: loaded (/usr/lib/systemd/system/pacemaker.service; enabled; preset: disabled)
        Active: inactive (dead) since Thu 2024-08-01 11:22:22 UTC; 2min 9s ago
          Docs: man:pacemakerd
   https://clusterlabs.org/pacemaker/doc/
   Aug 01 11:24:28 node1 systemd[1]: Dependency failed for Pacemaker High Availability Cluster Manager.
   Aug 01 11:24:28 node1 systemd[1]: pacemaker.service: Job pacemaker.service/start failed with result 'dependency'.
   

4. Elencare l'albero dei servizi di dipendenza del servizio Pacemaker:

   sudo systemctl list-dependencies pacemaker
   

   Se il servizio Pacemaker non ha il servizio SBD come dipendenza, verrà visualizzato l'output del comando simile al testo seguente:

   pacemaker.service
   ● ├─corosync.service
   ● ├─dbus-broker.service
   × ├─sbd.service
   ● ├─system.slice
   ● ├─resource-agents-deps.target
   ● └─sysinit.target
   

5. Controllare lo stato del servizio SBD:

   sudo systemctl status sbd
   

   Se l'esecuzione del servizio SBD non riesce, verrà visualizzato l'output del comando simile al testo seguente:

   × sbd.service - Shared-storage based fencing daemon
        Loaded: loaded (/usr/lib/systemd/system/sbd.service; enabled; preset: disabled)
       Drop-In: /etc/systemd/system/sbd.service.d
                └─sbd_delay_start.conf
        Active: failed (Result: exit-code) since Thu 2024-08-01 11:24:28 UTC; 1min 56s ago
      Duration: 55min 34.369s
          Docs: man:sbd(8)
       Process: 12794 ExecStart=/usr/sbin/sbd $SBD_OPTS -p /run/sbd.pid watch (code=exited, status=1/FAILURE)
           CPU: 46ms
   
   Aug 01 11:22:27 node1 systemd[1]: Starting Shared-storage based fencing daemon...
   Aug 01 11:22:27 node1 sbd[12794]:  warning: open_any_device: Failed to open /dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779. Trying any other config>
   Aug 01 11:24:28 node1 sbd[12794]:    error: open_any_device: No devices were available at start-up within 120 seconds.
   Aug 01 11:24:28 node1 systemd[1]: sbd.service: Control process exited, code=exited, status=1/FAILURE
   Aug 01 11:24:28 node1 systemd[1]: sbd.service: Failed with result 'exit-code'.
   Aug 01 11:24:28 node1 systemd[1]: Failed to start Shared-storage based fencing daemon.
   

Soluzione: assicurarsi che i servizi iscsid e iscsi siano abilitati ed in esecuzione

Per risolvere il problema, seguire questa procedura:

1. Assicurarsi di configurare la configurazione corretta come descritto in RHEL - Configurare Pacemaker in Red Hat Enterprise Linux in Azure

2. Abilitare entrambi iscsid i servizi e iscsi :

   sudo systemctl enable iscsi
   

   sudo systemctl enable iscsid
   

3. Verificare lo stato dei iscsid servizi e iscsi :

   sudo systemctl status iscsi 
   

   sudo systemctl status iscsid
   

   Se i servizi sono abilitati ed eseguiti, verrà visualizzato l'output del comando simile al testo seguente:

   ● iscsi.service - Login and scanning of iSCSI devices
        Loaded: loaded (/usr/lib/systemd/system/iscsi.service; enabled; preset: enabled)
        Active: active (exited) since Thu 2024-08-01 10:28:36 UTC; 1h 0min ago
          Docs: man:iscsiadm(8)
                man:iscsid(8)
       Process: 11174 ExecStart=/usr/sbin/iscsiadm -m node --loginall=automatic (code=exited, status=24)
      Main PID: 11174 (code=exited, status=24)
           CPU: 33ms
   
   Aug 01 10:28:36 nfs-0 systemd[1]: Starting Login and scanning of iSCSI devices...
   Aug 01 10:28:36 nfs-0 iscsiadm[1823]: Logging in to [iface: default, target: iqn.2006-04.nfs.local:nfs, portal: 10.0.0.17,3260]
   Aug 01 10:28:36 nfs-0 iscsiadm[1823]: Logging in to [iface: default, target: iqn.2006-04.nfs.local:nfs, portal: 10.0.0.18,3260]
   Aug 01 10:28:36 nfs-0 iscsiadm[1823]: Logging in to [iface: default, target: iqn.2006-04.nfs.local:nfs, portal: 10.0.0.19,3260]
   Aug 01 10:28:36 nfs-0 systemd[1]: Started Login and scanning of iSCSI devices.
   

Scenario 2: Il servizio SBD non viene avviato a causa di problemi di configurazione sbd

L'avvio del servizio SBD non riesce a causa dei problemi seguenti:

• Configurazioni SBD mancanti.
• Configurazioni SBD non corrette, ad esempio nomi di dispositivi SBD non corretti o errori di sintassi.

Soluzione: verificare che la configurazione SBD corretta esista

1. Verificare che la configurazione SBD esista:

   sudo pcs stonith config sbd
   

   Se la configurazione SBD esiste, verrà visualizzato l'output del comando simile al testo seguente:

   Resource: sbd (class=stonith type=fence_sbd)
     Attributes: sbd-instance_attributes
       devices=/dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779,/dev/disk/by-id/scsi-36001405cbac988092e448059d25d1a4a,/dev/disk/by-
           id/scsi-36001405a29a443e4a6e4ceeae822e5eb
     Operations:
       monitor: sbd-monitor-interval-600
         interval=600
         timeout=15
   

2. Convalidare e verificare che il file di configurazione SBD /etc/sysconfig/sbd disponga dei parametri consigliati seguenti e dei dispositivi SBD corretti:

   SBD_PACEMAKER=yes
   SBD_STARTMODE=always
   SBD_DELAY_START=no
   SBD_WATCHDOG_DEV=/dev/watchdog
   SBD_WATCHDOG_TIMEOUT=5
   SBD_TIMEOUT_ACTION=flush,reboot
   SBD_MOVE_TO_ROOT_CGROUP=auto
   SBD_OPTS=
   SBD_DEVICE="/dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d77;/dev/disk/by-id/scsi-36001405cbac988092e448059d25d1a4a;/dev/disk/by-id/scsi-36001405a29a443e4a6e4ceeae822e5eb”
   

Scenario 3: i dispositivi iSCSI non sono disponibili nei nodi del cluster

Per verificare se i dispositivi iSCSI sono disponibili nei nodi del cluster, eseguire il comando o lsblk seguentelsscsi. Se i dispositivi iSCSI non sono disponibili, i dischi SBD non verranno visualizzati nell'output del comando.

sudo lsscsi

[0:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sda
[1:0:1:0]    disk    Msft     Virtual Disk     1.0   /dev/sdb
[5:0:0:0]    cd/dvd  Msft     Virtual CD/ROM   1.0   /dev/sr0

sudo lsblk

NAME              MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda                 8:0    0   64G  0 disk
├─sda1              8:1    0  200M  0 part /boot/efi
├─sda2              8:2    0  500M  0 part /boot
├─sda3              8:3    0    1M  0 part
└─sda4              8:4    0 63.3G  0 part
  ├─rootvg-tmplv  253:0    0    2G  0 lvm  /tmp
  ├─rootvg-usrlv  253:1    0   10G  0 lvm  /usr
  ├─rootvg-homelv 253:2    0    1G  0 lvm  /home
  ├─rootvg-varlv  253:3    0    8G  0 lvm  /var
  └─rootvg-rootlv 253:4    0    2G  0 lvm  /
sdb                 8:16   0   16G  0 disk
└─sdb1              8:17   0   16G  0 part /mnt
sr0                11:0    1  628K  0 rom

Soluzione: abilitare l'accesso automatico ai server di destinazione iSCSI

1. Convalidare i nomi degli iniziatori in tutti i nodi del cluster:

   sudo  cat /etc/iscsi/initiatorname.iscsi
   

   InitiatorName=iqn.2006-04.nfs-0.local:nfs-0
   

   sudo  cat /etc/iscsi/initiatorname.iscsi
   

   InitiatorName=iqn.2006-04.nfs-1.local:nfs-1
   

2. Elencare tutti i dispositivi SBD nel file di configurazione SBD.

   sudo grep SBD_DEVICE /etc/sysconfig/sbd
   

   # SBD_DEVICE specifies the devices to use for exchanging sbd messages
   SBD_DEVICE="/dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779;/dev/disk/by-id/scsi-36001405cbac988092e448059d25d1a4a;/dev/disk/by-id/scsi-36001405a29a443e4a6e4ceeae822e5eb"
   

3. Controllare se i dispositivi SBD sono in esecuzione e accessibili. Se i servizi SBD non sono in esecuzione e accessibili, verrà visualizzato il messaggio "sbd failed; controllare i log." messaggio di errore.

   sudo  /usr/sbin/sbd -d /dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779 list
   

   == disk /dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779 unreadable!
   sbd failed; please check the logs.
   

   sudo /usr/sbin/sbd -d /dev/disk/by-id/scsi-36001405cbac988092e448059d25d1a4a list
   

   == disk /dev/disk/by-id/scsi-36001405cbac988092e448059d25d1a4a unreadable!
   sbd failed; please check the logs.
   

   sudo /usr/sbin/sbd -d /dev/disk/by-id/scsi-36001405a29a443e4a6e4ceeae822e5eb list
   

   == disk /dev/disk/by-id/scsi-36001405a29a443e4a6e4ceeae822e5eb unreadable!
   sbd failed; please check the logs.
   

4. Abilitare l'accesso automatico ai server di destinazione iSCSI.

   1. Eseguire un'individuazione iscsiadm in un nodo del cluster:

      sudo iscsiadm -m discovery
      

      L'output del comando mostra gli indirizzi IP di tutti i server di destinazione iSCSI e la porta predefinita 3260:

      10.0.0.17:3260 via sendtargets
      10.0.0.18:3260 via sendtargets
      10.0.0.19:3260 via sendtargets
      

   2. Individuazione del server di destinazione iSCSI in un determinato indirizzo IP:

      sudo iscsiadm -m discovery --type=st --portal=10.0.0.17:3260
      

      L'output del comando mostra un nome di destinazione, iqn.2006-04.nfs.local:nfsad esempio :

      10.0.0.17:3260,1 iqn.2006-04.dbnw1.local:dbnw1
      10.0.0.17:3260,1 iqn.2006-04.ascsnw1.local:ascsnw1
      10.0.0.17:3260,1 iqn.2006-04.nfs.local:nfs
      

   3. Accedere al dispositivo iSCSI:

      sudo iscsiadm -m node -T iqn.2006-04.nfs.local:nfs --login --portal=10.0.0.17:3260
      

      Logging in to [iface: default, target: iqn.2006-04.nfs.local:nfs, portal: 10.0.0.17,3260]
      Login to [iface: default, target: iqn.2006-04.nfs.local:nfs, portal: 10.0.0.17,3260] successful.
      

   4. Abilitare l'accesso automatico al dispositivo iSCSI:

      sudo iscsiadm -m node -p 10.0.0.17:3260 -T iqn.2006-04.nfs.local:nfs --op=update --name=node.startup --value=automatic
      

   5. Verificare se il dispositivo iSCSI è disponibile:

      sudo lsscsi
      

      [0:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sda
      [1:0:1:0]    disk    Msft     Virtual Disk     1.0   /dev/sdb
      [5:0:0:0]    cd/dvd  Msft     Virtual CD/ROM   1.0   /dev/sr0
      [6:0:0:0]    disk    LIO-ORG  sbdnfs           4.0   /dev/sdc
      

   6. Ripetere il passaggio b-f per assicurarsi che altri dispositivi iSCSI siano disponibili.

   7. Ripetere il passaggio a-f in un altro nodo del cluster per assicurarsi che tutti i dispositivi iSCSI in un altro nodo del cluster siano disponibili.

Quando i dispositivi iSCSI sono disponibili, l'output del lsscsi comando o lsblk dovrebbe visualizzare i dischi SBD.

sudo lsscsi

[0:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sda
[1:0:1:0]    disk    Msft     Virtual Disk     1.0   /dev/sdb
[5:0:0:0]    cd/dvd  Msft     Virtual CD/ROM   1.0   /dev/sr0
[6:0:0:0]    disk    LIO-ORG  sbdnfs           4.0   /dev/sdc
[7:0:0:0]    disk    LIO-ORG  sbdnfs           4.0   /dev/sdd
[8:0:0:0]    disk    LIO-ORG  sbdnfs           4.0   /dev/sde

sudo lsblk

NAME              MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda                 8:0    0   64G  0 disk
├─sda1              8:1    0  200M  0 part /boot/efi
├─sda2              8:2    0  500M  0 part /boot
├─sda3              8:3    0    1M  0 part
└─sda4              8:4    0 63.3G  0 part
    ├─rootvg-tmplv  253:0    0    2G  0 lvm  /tmp
    ├─rootvg-usrlv  253:1    0   10G  0 lvm  /usr
    ├─rootvg-homelv 253:2    0    1G  0 lvm  /home
    ├─rootvg-varlv  253:3    0    8G  0 lvm  /var
    └─rootvg-rootlv 253:4    0    2G  0 lvm  /
sdb                 8:16   0   16G  0 disk
└─sdb1              8:17   0   16G  0 part /mnt
sdc                 8:32   0   50M  0 disk
sdd                 8:48   0   50M  0 disk
sde                 8:64   0   50M  0 disk
sr0                11:0    1  628K  0 rom

Scenario 4: il nodo non riesce a ricongiuscrirsi al cluster dopo essere stato delimitato

Se lo slot SBD non è in uno stato pulito, il nodo non riuscirà a completare nuovamente il cluster dopo essere stato delimitato. Ciò causa che il dispositivo SBD è in stato di errore e un altro nodo è in sospeso.

Per convalidare lo stato dello slot SBD, eseguire i comandi seguenti:

sudo lsscsi

[0:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sda
[1:0:1:0]    disk    Msft     Virtual Disk     1.0   /dev/sdb
[5:0:0:0]    cd/dvd  Msft     Virtual CD/ROM   1.0   /dev/sr0
[6:0:0:0]    disk    LIO-ORG  sbdnfs           4.0   /dev/sdc
[7:0:0:0]    disk    LIO-ORG  sbdnfs           4.0   /dev/sdd
[8:0:0:0]    disk    LIO-ORG  sbdnfs           4.0   /dev/sde

sudo sbd -d /dev/sdc list

0       node1   clear
1       node2   reset   node1

sudo sbd -d /dev/sdd list

0       node1   clear
1       node2   reset   node1

sudo  sbd -d /dev/sde list

0       node1   clear
1       node2   reset   node1

Risoluzione: cancellare lo slot SBD

1. Verificare se il SBD_STARTMODE parametro è impostato su always o clean nel file di configurazione SBD /etc/sysconfig/sbd:

   sudo grep -i SBD_STARTMODE  /etc/sysconfig/sbd
   

   SBD_STARTMODE=clean
   

   Il SBD_STARTMODE parametro determina se un nodo si rielabora o meno. Se è impostato su always, anche se il nodo è stato delimitato in precedenza, rielabora il cluster. Se è impostato su clean, il nodo rielabora il cluster dopo la cancellazione dello slot SBD. Si tratta di un comportamento previsto. Rileva un messaggio di tipo di isolamento nello slot SBD per il nodo e non consente al nodo di ricongiunrsi al cluster a meno che lo slot SBD non venga cancellato manualmente.

2. Cancellare lo slot SBD nel nodo precedentemente delimitato e non è stato in grado di rientrare nel cluster:

   sudo sbd -d <SBD_DEVICE> message LOCAL clear
   

   Se si conosce il nome del nodo, è possibile cancellare lo slot SBD usando il comando seguente:

   sudo sbd -d <DEVICE_NAME> message <NODENAME> clear
   

   Note

   Sostituire <SBD_DEVICE>e<DEVICE_NAME> <NODENAME> di conseguenza.

   Ad esempio, il comando potrebbe essere il seguente:

   sudo sbd -d /dev/sdc message node2 clear
   

3. Dopo aver cancellato lo slot SBD, avviare il servizio cluster.

   Se il servizio cluster non riesce di nuovo, eseguire i comandi seguenti per risolvere il problema:

   sudo iscsiadm -m node -u
   

   sudo iscsiadm -m node -l
   

Scenario 5: Il servizio SBD non viene avviato dopo l'aggiunta di un nuovo dispositivo SBD

Dopo aver aggiunto un nuovo dispositivo SBD nel cluster, vengono visualizzati i sintomi seguenti:

• Quando si controlla lo stato del servizio SBD eseguendo il sudo systemctl status sbd comando , viene visualizzato il messaggio di errore "sbd failed; Controllare i log e "Non è stato possibile avviare sbd.service: operazione rifiutata".

• Quando si invia un messaggio di test a un nodo dai dispositivi SBD eseguendo il comando seguente, viene visualizzato anche lo stesso messaggio di errore:

  sudo sbd -d  /dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779 message node1 test
  

  sbd failed; please check the logs.
  

  Nel file /var/log/messages sono disponibili anche i log seguenti:

  Mar  2 06:58:06 node1 sbd[11105]: /dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779:    error: slot_msg: slot_msg(): No recipient / cmd specified.
  Mar  2 06:58:06 node1 sbd[11104]: warning: messenger: Process 11105 failed to deliver!
  

• Quando si esegue il sbd -d list comando, viene visualizzato un output vuoto. Per altre informazioni, vedere Elenco di dispositivi SBD che mostra l'output vuoto.

Soluzione: riavviare il cluster Pacemaker

Quando si usa SBD come dispositivo di isolamento e lo si abilita per un cluster Pacemaker, i servizi devono essere gestiti sotto il controllo del cluster. Pertanto, non è possibile avviarlo/arrestarlo manualmente. Dopo aver aggiunto un nuovo dispositivo SBD nel cluster Pacemaker, è necessario riavviare il cluster Pacemaker per rendere effettivo il dispositivo SBD sotto il controllo del cluster.

1. Arrestare e riavviare i servizi cluster in tutti i nodi del cluster.

   sudo pcs cluster stop --all
   

   sudo pcs cluster start --all
   

2. Controllare se il servizio SBD viene avviato correttamente.

   sudo systemctl status sbd.service 
   

   ● sbd.service - Shared-storage based fencing daemon
      Loaded: loaded (/usr/lib/systemd/system/sbd.service; enabled; vendor preset: disabled)
      Active: active (running)
   

Quando il servizio SBD è in esecuzione, il sbd -d list comando non visualizzerà un output vuoto:

sudo sbd -d /dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779 list

0   node1   clear   
1   node2   clear   

Passaggi successivi

Se il problema non viene risolto, raccogliere i log di sistema dai sistemi Red Hat, generare un report sos e quindi contattare il supporto tecnico. Per altre informazioni, vedere Che cos'è un report sos e come crearne uno in Red Hat Enterprise Linux?.

Dichiarazione di non responsabilità sulle informazioni di terze parti

I prodotti di terzi citati in questo articolo sono prodotti da società indipendenti da Microsoft. Microsoft non rilascia alcuna garanzia implicita o esplicita relativa alle prestazioni o all'affidabilità di tali prodotti

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.