Questa pagina è stata tradotta dall'API Cloud Translation.

Configura un cluster SQL Server su Linux con gruppi di disponibilità sempre attivi e Pacemaker

Questo tutorial descrive come eseguire il deployment di un sistema di database Microsoft SQL Server su Linux utilizzando un gruppo di disponibilità sempre attivo (AOAG) e Pacemaker come soluzione ad alta disponibilità e ripristino di emergenza (RE). Ai fini di questo documento, un disastro è un evento in cui un database principale non funziona o non è disponibile.

Un database principale può avere esito negativo quando la regione in cui è posizionato non funziona o diventa inaccessibile. Anche se una regione è disponibile e funziona normalmente, un database principale può non funzionare a causa di un errore di sistema. In questi casi, il ripristino di emergenza è il processo con cui i client hanno a disposizione un database secondario per continuare a elaborarlo.

Questo tutorial è destinato ad architetti di database, amministratori e ingegneri di database.

Obiettivi

Esegui il deployment di SQL Server su Linux
Crea un gruppo di disponibilità sempre attivo per l'alta disponibilità e il ripristino di emergenza
Installa e configura Pacemaker per gestire il failover del cluster SQL Server
Configura un bilanciatore del carico per instradare il traffico al gruppo di disponibilità con SQL Server
Configura una recinzione STONITH (Shoot The Other Node In The Head) per garantire l'integrità dell'HA
Esegui un test di failover per assicurarti che il cluster SQL Server funzioni come previsto

Costi

Questo tutorial utilizza componenti fatturabili di Google Cloud, tra cui:

Utilizza il Calcolatore prezzi per generare una stima dei costi in base all'utilizzo previsto.

Prima di iniziare

Per questo tutorial, hai bisogno di un progetto Google Cloud. Puoi creare un o seleziona un progetto già creato:

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector
Make sure that billing is enabled for your Google Cloud project.
Assicurati che l'API NetApp Cloud Volumes sia abilitata per il tuo progetto Google Cloud.
In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

Prepara il progetto e la rete

prepara il tuo progetto Google Cloud e il VPC per il deployment di SQL Server Per i gruppi di disponibilità sempre attivi:

Nella console Google Cloud, apri Cloud Shell facendo clic Attiva Cloud Shell .

Vai alla console Google Cloud
Imposta l'ID progetto predefinito:
```
gcloud config set project PROJECT_ID
```
Sostituisci PROJECT_ID con l'ID del tuo progetto Google Cloud.
Imposta la regione predefinita:
```
gcloud config set compute/region REGION
```
Sostituisci REGION con l'ID della regione in cui vuoi eseguire il deployment.
Imposta la zona predefinita:
```
gcloud config set compute/zone ZONE
```
Sostituisci ZONE con l'ID della zona in cui vuoi eseguire il deployment. Deve essere una zona valida nella regione specificata nel passaggio precedente.

Crea VM Linux

Per ottenere l'alta disponibilità e il quorum per il cluster SQL Server, esegui il deployment di tre macchine virtuali (VM) Linux per ospitare il cluster SQL Server.

Inizializza le seguenti variabili:
```
PD_SIZE=30
MACHINE_TYPE=n2-standard-8
```

Crea le VM Linux:

gcloud compute instances create node-1 \
--project=PROJECT_ID \
--zone REGION-a \
--machine-type $MACHINE_TYPE \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-1,image=projects/ubuntu-os-cloud/global/images/ubuntu-2004-focal-v20240426,mode=rw,size=$PD_SIZE,type=projects/PROJECT_ID/zones/ZONE/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

gcloud compute instances create node-2 \
--project=PROJECT_ID \
--zone REGION-b \
--machine-type $MACHINE_TYPE \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-2,image=projects/ubuntu-os-cloud/global/images/ubuntu-2004-focal-v20240426,mode=rw,size=$PD_SIZE,type=projects/PROJECT_ID/zones/ZONE/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

gcloud compute instances create node-3 \
--project=PROJECT_ID \
--zone REGION-c \
--machine-type $MACHINE_TYPE \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-3,image=projects/ubuntu-os-cloud/global/images/ubuntu-2004-focal-v20240426,mode=rw,size=$PD_SIZE,type=projects/PROJECT_ID/zones/ZONE/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

Sostituisci la subnet SUBNET_NAME con il nome della subnet VPC.

Aggiorna il file hosts su node-1, node-2 e node-3:

Nota: per l'utilizzo in produzione, la risoluzione del dominio deve essere gestita da un server DNS (Domain Name System) dedicato.
1. Connettiti a ciascuna delle tue VM tramite SSH. Per saperne di più, consulta la documentazione di Connect to Linux VM.
2. Apri il file hosts per la modifica.
```
sudo vi /etc/hosts
```
3. Trova l'indirizzo IP interno per ogni VM Linux e aggiungi le voci host in fondo al file.
  
  Vai a Compute Engine
```
NODE1_INTERNAL_IP node-1
NODE2_INTERNAL_IP node-2
NODE3_INTERNAL_IP node-3
```
  Sostituisci NODE1_INTERNAL_IP, NODE2_INTERNAL_IP e NODE3_INTERNAL_IP con l'indirizzo IP interno di ogni VM Linux.
Controlla la comunicazione tra le VM. Tutte le VM che fanno parte del gruppo di disponibilità Sempre attiva devono essere in grado di comunicare con altre VM:
1. Torna a ogni VM Linux, esegui i comandi da ogni VM e verifica che tutte le VM possano comunicare tra loro.
```
ping -c 4 node-1
ping -c 4 node-2
ping -c 4 node-3
```

Installa e configura SQL Server

Scarica, installa e configura il motore SQL Server sulle tre VM Linux che parteciperanno al gruppo di disponibilità sempre attivo.

Accedi tramite SSH a node-1, node-2 e node-3 ed esegui questi passaggi:

Importa le chiavi del repository pubblico.

wget -qO- https://packages.microsoft.com/keys/microsoft.asc \
| sudo tee /etc/apt/trusted.gpg.d/microsoft.asc

Registra il repository Ubuntu SQL Server.

sudo add-apt-repository \
"$(wget -qO- https://packages.microsoft.com/config/ubuntu/20.04/mssql-server-2019.list)"

Aggiorna i file di indice dei pacchetti e installa SQL Server.
```
sudo apt-get update
sudo apt-get install -y mssql-server
```

Configura SQL Server:
1. Esegui lo strumento mssql-conf.
```
sudo /opt/mssql/bin/mssql-conf setup
```
2. Scegli la versione Developer per la versione SQL Server e accetta il contratto di licenza.
  
  La versione per sviluppatori include tutte le funzionalità aziendali, ma puoi utilizzarla solo per ambienti non di produzione. Sono disponibili ulteriori informazioni sulle versioni di SQL Server e sulle licenze Microsoft.
  
  Nota: per ogni istanza VM è richiesta una licenza SQL Server. Se utilizzi server di applicazioni Microsoft, la mobilità delle licenze tramite Software Assurance ti aiuta a eseguire la transizione a Google Cloud. Per ulteriori informazioni, consulta Utilizzare la mobilità delle licenze con le applicazioni di server Microsoft. Se non utilizzi una licenza di tua proprietà e devi acquistarne una tramite Google (PAYG), segui i passaggi descritti in Aggiungere una licenza SQL Server a un disco di avvio per assicurarti di acquistare una licenza per ogni istanza VM.
3. Specifica una password per l'account SA.
4. Verifica che il servizio mssql-server sia in esecuzione.
```
systemctl status mssql-server --no-pager
```
Se hai attivato un firewall sulle tue VM, apri il firewall per SQL Server:
1. Controlla se Uncomplicated Firewall è installato e abilitato eseguendo il seguente comando.
```
sudo ufw status
```
2. Se lo stato è attivo, esegui i seguenti comandi per aprire le porte.
```
sudo ufw allow 1433
sudo ufw allow 5022
sudo ufw reload
```
  Nota: se utilizzi altre porte per SQL Server o per l'endpoint del gruppo di disponibilità, modifica di conseguenza le regole del firewall.

Connettiti a SQL Server

A questo punto, SQL Server è installato. Per connetterti a questo VPC, crea una macchina Windows nello stesso VPC, installa SQL Server Management Studio (SSMS) per connetterti all'istanza SQL Server appena creata sulle tue VM:

Crea una VM Windows:

Torna a Cloud Shell ed esegui questo comando.

gcloud compute instances create node4 \
--project=PROJECT_ID \
--zone ZONE \
--subnet SUBNET_NAME \
--machine-type=n2-standard-4 \
--create-disk=auto-delete=yes,boot=yes,device-name=node4,image=projects/windows-cloud/global/images/windows-server-2022-dc-v20240415,mode=rw,size=50,type=projects/p3rf-sqlserver/zones/ZONE/diskTypes/pd-balanced

Connettiti alla VM Windows su node-4 utilizzando Remote Desktop:
Aggiorna il file hosts su node-4:
1. Apri blocco note in modalità amministratore.
2. Fai clic su File > Apri e apri il file hosts.
```
c:\Windows\System32\drivers\etc\hosts
```
3. Aggiungi le voci host in fondo al file.
```
NODE1_INTERNAL_IP node-1
NODE2_INTERNAL_IP node-2
NODE3_INTERNAL_IP node-3
```
  Sostituisci NODE1_INTERNAL_IP, NODE2_INTERNAL_IP e NODE3_INTERNAL_IP con il rispettivo indirizzo IP interno di ogni VM.
4. Salva ed esci.
Verifica la connettività con le VM Linux:
1. Connettiti alla VM Windows su node-4
2. Fai clic sul pulsante Start e inserisci PowerShell nella barra di ricerca.
3. Fai clic per aprire l'app Windows PowerShell ISE.
4. Testa la connettività eseguendo i seguenti comandi.
```
ping node-1
ping node-2
ping node-3
```
Installa Microsoft SQL Server Management Studio (SSMS) seguendo questa procedura:
1. Connettiti alla VM Windows su node-4 utilizzando Remote Desktop.
2. Nella sessione RDP, riduci a icona tutte le finestre e avvia l'app Windows PowerShell ISE.
3. Al prompt di PowerShell, scaricare ed eseguire il programma di installazione SSMS.
```
Start-BitsTransfer `
-Source "https://aka.ms/ssmsfullsetup" `
-Destination "$env:Temp\ssms-setup.exe"
& $env:Temp\ssms-setup.exe
```
4. Nel programma di installazione SSMS, fai clic su Installa.
5. Accetta la richiesta per consentire l'applicazione delle modifiche.
6. Al termine dell'installazione, fai clic su Riavvia per riavviare la macchina remota. La sessione RDP viene chiusa.
Connettiti all'istanza SQL Server sul nodo-1:
1. Torna a node-4 VM utilizzando RDP.
2. Apri SSMS e connettiti a node-1 utilizzando i seguenti parametri.
```
Server name: node-1
Authentication: SQL Server Authentication
Login: sa
```
  Per ulteriori informazioni, consulta la sezione sulla connessione a un'istanza SQL Server utilizzando la documentazione di SQL Server Management Studio.
3. Inserisci la password per l'account SA creato durante l'installazione.
4. Seleziona Certificato server di attendibilità.
5. Fai clic su Connetti.

Attiva il gruppo di disponibilità Always On

Su Linux, devi creare un gruppo di disponibilità prima di poterlo aggiungere come risorsa per la gestione da parte di Pacemaker:

Abilita la funzionalità del gruppo di disponibilità sempre attivo per ogni istanza SQL Server che fa parte del gruppo di disponibilità. Esegui questi comandi su node-1, node-2 e node-3:

Nota: riavvia il servizio mssql-server per rendere effettive le modifiche.
```
sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1
sudo systemctl restart mssql-server
```
Connettiti all'istanza che è l'host principale nel gruppo di disponibilità utilizzando SSMS:

Suggerimento: ti consigliamo di scegliere node-1 come host principale.
1. Apri una nuova finestra di query.
2. Esegui il seguente snippet di codice per creare una chiave di crittografia, un certificato e una chiave privata.
  
  Suggerimento: scegli password complesse per la chiave di crittografia e la chiave privata. Ricorda queste password perché le userai in un secondo momento.
  Nota: la password deve essere lunga almeno 8 caratteri e contenere caratteri di tre dei seguenti quattro insiemi: lettere maiuscole, lettere minuscole, cifre di base 10 e simboli.
```
USE MASTER;

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'ENCRYPTION_KEY_PASSWORD';
CREATE CERTIFICATE my_ag_certificate WITH SUBJECT = 'my_ag_cert';
BACKUP CERTIFICATE my_ag_certificate
TO FILE = '/var/opt/mssql/data/my_ag_certificate.cer'
WITH PRIVATE KEY (
    FILE = '/var/opt/mssql/data/my_ag_certificate.pvk',
    ENCRYPTION BY PASSWORD = 'PRIVATE_KEY_PASSWORD'
);
```
  Sostituisci ENCRYPTION_KEY_PASSWORD e PRIVATE_KEY_PASSWORD con le password della chiave di crittografia e della chiave privata.

Trasferisci i file del certificato e della chiave

I file dei certificati e delle chiavi creati nei passaggi precedenti devono essere spostati nei nodi secondari di SQL Server. Esistono diversi metodi per spostare i file del certificato e della chiave nei nodi secondari su node-2 e node-3.

Per altre opzioni di trasferimento, consulta l'articolo Trasferire file su VM Linux

Trasferisci i file del certificato e della chiave utilizzando Cloud Storage

Crea un ambiente Cloud Storage per trasferire i file dai nodi cluster principali a quelli secondari.

Crea un bucket Cloud Storage:
1. Torna a Cloud Shell ed esegui questo comando:
```
gcloud storage buckets create gs://BUCKET_NAME \
--project=PROJECT_ID \
--location=REGION \
--public-access-prevention
```
  Sostituisci BUCKET_NAME con il nome del bucket da creare. Sostituisci PROJECT_ID con l'ID del tuo progetto Google Cloud e REGION con l'ID della regione in cui vuoi eseguire il deployment del bucket.
Per ulteriori informazioni, vedi Creare bucket.
Torna a SSh su node-1, node-2 e node-3 per inizializzare Google Cloud CLI:
1. Esegui questo comando per inizializzare Google Cloud CLI.
```
gcloud init
```
2. Scegli option [1] per utilizzare l'account di servizio preinstallato.
3. Inserisci il nome del progetto.
4. Inserisci n nella domanda per impostare la regione e la zona predefinite.
Torna a node-1 per copiare i file in Cloud Storage:
1. Carica i due file appena creati in Cloud Storage eseguendo i seguenti comandi.
```
sudo gcloud storage cp /var/opt/mssql/data/my_ag_certificate.cer gs://BUCKET_NAME/
sudo gcloud storage cp /var/opt/mssql/data/my_ag_certificate.pvk gs://BUCKET_NAME/
```
  Sostituisci BUCKET_NAME con il nome del bucket creato.
Torna a node-2 e node-3 per copiare i file da Cloud Storage:
1. Scarica i due file da Cloud Storage su node-2.
```
sudo gcloud storage cp gs://BUCKET_NAME/my_ag_certificate.cer /var/opt/mssql/data/
sudo gcloud storage cp gs://BUCKET_NAME/my_ag_certificate.pvk /var/opt/mssql/data/
```
  Sostituisci BUCKET_NAME con il nome del bucket creato.
2. Cambia la proprietà dei file su node-2 e node-3 eseguendo il comando in una shell root.
```
chown mssql:mssql /var/opt/mssql/data/my_ag_certificate.*
chmod 660 /var/opt/mssql/data/my_ag_certificate.*
```
  Suggerimento: ricordati di uscire dalla shell root dopo aver eseguito i comandi.

Configurare l'endpoint di mirroring del database

In questa sezione creerai l'endpoint del database utilizzando una chiave di crittografia e un certificato condivisi da ciascun nodo nel cluster SQL Server per garantire una replica sicura dei dati.

Torna alla VM Windows su node-4 per creare gli endpoint di mirroring del database:
1. Connettiti ai database SQL Server su node-1, node-2 e node-3 utilizzando SSMS. Segui i passaggi da Connessione a SQL Server utilizzando node-1, node-2 e node-3 come nome del server e le rispettive password che hai impostato per l'account SA.
2. Crea il certificato sulle VM secondarie node-2 e node-3 dai file copiati. Utilizza le password che hai fornito quando hai creato il certificato e la chiave sul nodo principale.
```
USE MASTER;

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'ENCRYPTION_KEY_PASSWORD';
CREATE CERTIFICATE my_ag_certificate
FROM FILE = '/var/opt/mssql/data/my_ag_certificate.cer'
WITH PRIVATE KEY (
    FILE = '/var/opt/mssql/data/my_ag_certificate.pvk',
    DECRYPTION BY PASSWORD = 'PRIVATE_KEY_PASSWORD'
);
```
  Sostituisci ENCRYPTION_KEY_PASSWORD e PRIVATE_KEY_PASSWORD con le password per la chiave di crittografia e la chiave privata.
3. Torna a SSMS per creare endpoint di mirroring del database eseguendo il comando T-SQL per node-1, node-2 e node-3.
  
  Suggerimento: la porta di ascolto predefinita è 5022, ma puoi utilizzare qualsiasi altra porta disponibile.
```
CREATE ENDPOINT [my_ag_endpoint]
    AS TCP (LISTENER_PORT = 5022)
    FOR DATABASE_MIRRORING (
        ROLE = ALL,
        AUTHENTICATION = CERTIFICATE my_ag_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
    );

ALTER ENDPOINT [my_ag_endpoint] STATE = STARTED;
```

Creare e configurare il gruppo di disponibilità Sempre attivo

A questo punto, crea il gruppo di disponibilità AlwaysOn di SQL Server utilizzando SQL Server Management Studio e utilizza gli endpoint creati in precedenza per la replica.

Torna alla VM Windows e apri SSMS:
1. Connettiti al motore del database SQL Server su node-1 e apri una nuova finestra di query.

Crea un database ed eseguine il backup in preparazione per la replica:

USE MASTER;

CREATE DATABASE [bookshelf];
ALTER DATABASE [bookshelf] SET RECOVERY FULL;
BACKUP DATABASE [bookshelf]
TO DISK = N'/var/opt/mssql/data/bookshelf.bak';

Crea il gruppo di disponibilità AlwaysOn:

Esegui il seguente comando T-SQL in SSMS su node-1, node-2 e node-3. In questo modo, gli endpoint saranno abilitati e SQL Server su ogni nodo sarà pronto per la replica dei dati.

IF (SELECT state FROM sys.endpoints WHERE name = N'my_ag_endpoint') <> 0
BEGIN
    ALTER ENDPOINT [my_ag_endpoint] STATE = STARTED
END
GO

IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name='AlwaysOn_health')
BEGIN
    ALTER EVENT SESSION [AlwaysOn_health] ON SERVER WITH (STARTUP_STATE=ON);
END
IF NOT EXISTS(SELECT * FROM sys.dm_xe_sessions WHERE name='AlwaysOn_health')
BEGIN
    ALTER EVENT SESSION [AlwaysOn_health] ON SERVER STATE=START;
END
GO

Esegui questo comando T-SQL su node-1 per creare l'AOAG.

USE [master]
GO

CREATE AVAILABILITY GROUP [aoag1]
WITH (
    AUTOMATED_BACKUP_PREFERENCE = SECONDARY,
    DB_FAILOVER = OFF,
    DTC_SUPPORT = NONE,
    CLUSTER_TYPE = EXTERNAL,
    REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0
)
FOR DATABASE [bookshelf]
REPLICA ON N'node-1' WITH (
    ENDPOINT_URL = N'TCP://node-1:5022', FAILOVER_MODE = EXTERNAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)),
    N'node-2' WITH (ENDPOINT_URL = N'TCP://node-2:5022', FAILOVER_MODE = EXTERNAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)),
    N'node-3' WITH (ENDPOINT_URL = N'TCP://node-3:5022', FAILOVER_MODE = EXTERNAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)
);
GO

Esegui il seguente comando T-SQL su node-2 e node-3 per ogni istanza SQL Server per partecipare al nuovo gruppo di disponibilità.

ALTER AVAILABILITY GROUP [aoag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
GO

ALTER AVAILABILITY GROUP [aoag1] GRANT CREATE ANY DATABASE;
GO

Hai creato un nuovo database denominato libreria e lo hai aggiunto a un nuovo gruppo di disponibilità denominato aoag1 nell'istanza SQL Server in esecuzione su node-1. Node-2 e node-3 sono stati aggiunti al gruppo di disponibilità e i dati nel database bookShell verranno replicati in modo sincrono nelle istanze SQL Server in tutti e tre i nodi.

Installa e configura Pacemaker

Pacemaker è un software di gestione delle risorse ad alta disponibilità open source, utilizzato con il motore cluster Corosync. In questa sezione installi e configuri Pacemaker su ciascuna delle tue VM.

Crea un accesso SQL Server per il gestore del cluster pacemaker

In questa sezione creerai un nuovo account SQL Server che Pacemaker potrà utilizzare per accedere a ogni istanza SQL Server e gestire il gruppo di disponibilità.

Esegui il seguente comando T-SQL su node-1, node-2 e node-3:
```
USE [master];

CREATE LOGIN [pacemaker] with PASSWORD= N'PACEMAKER_LOGIN_PASSWORD';
GO
```
Sostituisci PACEMAKER_LOGIN_PASSWORD con una password per l'account del pacemaker.

Esegui il comando T-SQL per concedere le autorizzazioni di accesso del pacemaker al gruppo di disponibilità:

GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::[aoag1] TO [pacemaker];
GRANT VIEW SERVER STATE TO [pacemaker];
GO

Torna a SSH su node-1, node-2 e node-3 per eseguire i comandi per salvare le credenziali di accesso a Pacemaker nella cartella dei secret di SQL Server:

echo 'pacemaker' >> ~/pacemaker-passwd
echo 'PACEMAKER_LOGIN_PASSWORD' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd

Sostituisci PACEMAKER_LOGIN_PASSWORD con la password dell'account del pacemaker.

Installa Pacemaker

Successivamente, installa Pacemaker e configura un account di accesso su tutte le VM Linux per la gestione delle risorse.

Apri le porte del firewall per il pacemaker:
1. Verifica che Uncomplicated Firewall sia installato e abilitato eseguendo questo comando su node-1, node-2 e node-3.
```
sudo ufw status
```
2. Se il protocollo ufw è abilitato, apri le porte del firewall su node-1, node-2 e node-3.
```
sudo ufw allow 2224/tcp
sudo ufw allow 3121/tcp
sudo ufw allow 5405/udp
sudo ufw allow 21064/tcp
sudo ufw allow 1433/tcp
sudo ufw allow 5022/tcp
sudo ufw reload
```
  Nota: se utilizzi altre porte per SQL Server o per l'endpoint del tuo gruppo di disponibilità, modifica le regole firewall di conseguenza

Installa Pacemaker su node-1, node-2 e node-3:

sudo apt-get install -y pacemaker pacemaker-cli-utils crmsh resource-agents  fence-agents corosync python3-azure pcs

Imposta una nuova password per l'utente hacluster su node-1, node-2 e node-3:

Nota: imposta la stessa password su tutti e tre i nodi. Questa password sarà necessaria per il resto della configurazione.
```
sudo passwd hacluster
```

Configurare Corosync

Ora configurerai Corosync per gestire l'appartenenza al cluster e la messaggistica all'interno del cluster.

Crea una chiave di autenticazione per Corosync su node-1:
```
sudo corosync-keygen
```

Modifica il file di configurazione di Corosync:

Torna a node-1 e modifica il file corosync.conf.
```
sudo vi /etc/corosync/corosync.conf
```

Aggiorna le sezioni evidenziate. Dopo la modifica, il file dovrebbe avere il seguente aspetto.

# Please read the corosync.conf.5 manual page
totem {
    version: 2

    # Corosync itself works without a cluster name, but DLM needs one.
    # The cluster name is also written into the VG metadata of newly
    # created shared LVM volume groups, if lvmlockd uses DLM locking.
    cluster_name: my_agcluster

    # crypto_cipher and crypto_hash: Used for mutual node authentication.
    # If you choose to enable this, then do remember to create a shared
    # secret with "corosync-keygen".
    # enabling crypto_cipher, requires also enabling of crypto_hash.
    # crypto works only with knet transport
    transport: udpu
    crypto_cipher: none
    crypto_hash: none
}

logging {
    # Log the source file and line where messages are being
    # generated. When in doubt, leave off. Potentially useful for
    # debugging.
    fileline: off
    # Log to standard error. When in doubt, set to yes. Useful when
    # running in the foreground (when invoking "corosync -f")
    to_stderr: yes
    # Log to a log file. When set to "no", the "logfile" option
    # must not be set.
    to_logfile: yes
    logfile: /var/log/corosync/corosync.log
    # Log to the system log daemon. When in doubt, set to yes.
    to_syslog: yes
    # Log debug messages (very verbose). When in doubt, leave off.
    debug: off
    # Log messages with time stamps. When in doubt, set to hires (or on)
    #timestamp: hires
    logger_subsys {
        subsys: QUORUM
        debug: off
    }
}
quorum {
    # Enable and configure quorum subsystem (default: off)
    # see also corosync.conf.5 and votequorum.5
    provider: corosync_votequorum
}
nodelist {
    # Change/uncomment/add node sections to match cluster configuration

    node {
        # Hostname of the node
        name: node-1
        # Cluster membership node identifier
        nodeid: 1
        # Address of first link
        ring0_addr: NODE1_INTERNAL_IP
        # When knet transport is used it's possible to define up to 8 links
        #ring1_addr: 192.168.1.1
    }
    node {
        name: node-2
        nodeid: 2
        ring0_addr: NODE2_INTERNAL_IP
    }
    node {
        name: node-3
        nodeid: 3
        ring0_addr: NODE3_INTERNAL_IP
    }
    # ...
}

Sostituisci NODE1_INTERNAL_IP, NODE2_INTERNAL_IP e NODE3_INTERNAL_IP con gli indirizzi IP interni di ciascun nodo.

Trasferisci i file di configurazione con Cloud Storage

Carica la chiave di autenticazione e i file di configurazione di corosync generati da node-1 nel tuo bucket Cloud Storage:
```
sudo gcloud storage cp /etc/corosync/authkey gs://BUCKET_NAME/
sudo gcloud storage cp  /etc/corosync/corosync.conf gs://BUCKET_NAME/
```
Sostituisci BUCKET_NAME con il nome del bucket creato in precedenza.
Scarica i file Authkey e config in node-2 e node-3:
```
sudo gcloud storage cp gs://BUCKET_NAME/authkey /etc/corosync/
sudo gcloud storage cp gs://BUCKET_NAME/corosync.conf /etc/corosync/
```
Sostituisci BUCKET_NAME con il nome del bucket in cui sono stati trasferiti i file di configurazione di Corosync.

Aggiorna le autorizzazioni dei file su node-2 e node-3:

sudo chmod 400 /etc/corosync/authkey
sudo chmod 400 /etc/corosync/corosync.conf

riavvia e verifica la comunicazione del cluster

Riavvia i servizi Pacemaker e Corosync su node-1, node-2 e node-3:
```
sudo systemctl restart pacemaker corosync
```
Verifica lo stato del cluster eseguendo il comando su node-1:
```
sudo crm status
```
Dovresti vedere tutti e tre i nodi online.

Configura il cluster

Successivamente, configurerai il cluster Pacemaker creando una nuova risorsa per il gruppo di disponibilità Always On di SQL Server.

Esegui il seguente comando su node-1 per impostare le proprietà del cluster:

sudo crm configure property stonith-enabled=false
sudo crm configure property cluster-recheck-interval=2min
sudo crm configure property start-failure-is-fatal=true

Per ulteriori informazioni, vedi Opzioni cluster.

Autorizza i nodi del cluster eseguendo il comando su node-1. Usa la password impostata in precedenza per l'account hacluster:
```
sudo pcs cluster auth -u hacluster
```
Dovresti vedere che tutti e tre i nodi sono autorizzati.
Installa l'agente di risorse SQL Server per l'integrazione con Pacemaker su node-1, node-2 e node-3:
```
sudo apt-get install mssql-server-ha
```
Torna a node-1 e crea una risorsa gruppo di disponibilità nel cluster:
1. Esegui Cluster Resource Manager.
```
sudo crm
```
2. Digita configure per accedere al menu di configurazione.
3. Inserisci la seguente configurazione.
```
primitive aoag1-cluster \
ocf:mssql:ag \
params ag_name="aoag1" \
meta failure-timeout=60s \
op start timeout=60s \
op stop timeout=60s \
op promote timeout=60s \
op demote timeout=10s \
op monitor timeout=60s interval=10s \
op monitor timeout=60s on-fail=demote interval=11s role="Master" \
op monitor timeout=60s interval=12s role="Slave" \
op notify timeout=60s
ms ms-ag1 aoag1-cluster \
meta master-max="1" master-node-max="1" clone-max="3" \
clone-node-max="1" notify="true"
```
4. Digita commit per eseguire il commit delle modifiche.
  
  Nota: riceverai un avviso che ti informa che non è stata configurata alcuna regola di recinzione. Ignora questo messaggio: verrà impostata una regola di recinzione in un passaggio successivo.
5. Digita exit per uscire da Cluster Resource Manager.
6. Verifica la configurazione.
```
sudo crm status
```
  Dovresti vedere che node-1 è stato promosso a nodo primario. Node-2 e node-3 devono essere impostati come nodi secondari.

Configura il bilanciatore del carico e il listener del gruppo di disponibilità

In questa sezione creerai un indirizzo IP virtuale e una risorsa per il controllo di integrità nel cluster utilizzando un bilanciatore del carico TCP passthrough interno che instrada il traffico al gruppo di disponibilità.

Torna a Cloud Shell e prenota un indirizzo IP statico che utilizzerai come IP del cluster:

gcloud compute addresses create aoag1-cluster \
--region REGION \
--subnet SUBNET_NAME
CLUSTER_ADDRESS=$(gcloud compute addresses describe aoag1-cluster \
--region $(gcloud config get-value compute/region) \
--format=value\(address\)) && \
echo "Cluster IP address: $CLUSTER_ADDRESS"

Sostituisci REGION e SUBNET_NAME con la regione e la sottorete in cui sono implementate le VM Linux.

Crea gruppi di istanze non gestite per ciascuno dei tuoi nodi del cluster e assegnali al gruppo di istanze appena creato. Esegui questi comandi in Cloud Shell:

gcloud compute instance-groups unmanaged create node-1-uig \
--zone=REGION-a
gcloud compute instance-groups unmanaged add-instances node-1-uig \
--zone=REGION-a \
--instances=node-1

gcloud compute instance-groups unmanaged create node-2-uig \
--zone=REGION-b
gcloud compute instance-groups unmanaged add-instances node-2-uig \
--zone=REGION-b \
--instances=node-2

gcloud compute instance-groups unmanaged create node-3-uig \
--zone=REGION-c
gcloud compute instance-groups unmanaged add-instances node-3-uig \
--zone=REGION-c \
--instances=node-3

Sostituisci REGION con la regione in cui è stato eseguito il deployment delle VM Linux.

Crea un controllo di integrità TCP. I bilanciatori del carico utilizzano i controlli di integrità per determinare quali istanze di backend rispondono correttamente al traffico.
```
gcloud compute health-checks create tcp aoag1-healthcheck \
--port=HEALTH_CHECK_PORT --proxy-header=NONE \
--check-interval=10 --timeout=10 --unhealthy-threshold=2 \
--healthy-threshold=2
```
Scegli e sostituisci HEALTH_CHECK_PORT con il valore di una porta libera e nell'intervallo privato 49152-65535. Ad esempio, 60000.

Per ulteriori informazioni, consulta la panoramica dei controlli di integrità.

Aggiungi i tag di rete ai nodi del cluster. Il tag di rete viene utilizzato dalla regola firewall per il controllo di integrità:

gcloud compute instances add-tags node-1 \
--tags NETWORK_TAG_NAME \
--zone REGION-a
gcloud compute instances add-tags node-2 \
--tags NETWORK_TAG_NAME \
--zone REGION-b
gcloud compute instances add-tags node-3 \
--tags NETWORK_TAG_NAME \
--zone REGION-c

Sostituisci NETWORK_TAG_NAME con un nome per il tag di rete.

Crea una regola firewall per consentire ai controlli di integrità di raggiungere i nodi del cluster in base al nome del tag:

gcloud compute firewall-rules create mssql-aoag1-fw-rule \
--network VPC_NAME \
--action ALLOW \
--direction INGRESS \
--source-ranges 35.191.0.0/16,130.211.0.0/22 \
--target-tags NETWORK_TAG_NAME \
--rules tcp:HEALTH_CHECK_PORT

Per saperne di più, consulta Regole firewall per i controlli di integrità.

Crea il servizio di backend del bilanciatore del carico:

gcloud compute backend-services create aoag1-backend \
--load-balancing-scheme internal \
--health-checks aoag1-healthcheck \
--no-connection-drain-on-failover \
--drop-traffic-if-unhealthy \
--failover-ratio 1.0 \
--region REGION \
--global-health-checks

Aggiungi i tre gruppi di istanze non gestiti al servizio di backend:

gcloud compute backend-services add-backend aoag1-backend \
--instance-group node-1-uig \
--instance-group-zone REGION-a \
--region REGION

gcloud compute backend-services add-backend aoag1-backend \
--instance-group node-2-uig \
--instance-group-zone REGION-b \
--failover \
--region REGION

gcloud compute backend-services add-backend aoag1-backend \
--instance-group node-3-uig \
--instance-group-zone REGION-c \
--failover \
--region REGION

Definisci una regola di inoltro per il bilanciatore del carico. Una regola di forwarding specifica il protocollo e le porte su cui il bilanciatore del carico accetta il traffico:
```
gcloud compute forwarding-rules create aoag1-fwd-rule \
--load-balancing-scheme internal \
--address CLUSTER_ADDRESS \
--subnet SUBNET_NAME \
--region REGION \
--backend-service aoag1-backend \
--ports ALL
```
Sostituisci CLUSTER_ADDRESS con l'indirizzo IP prenotato in precedenza.

Suggerimento: se vuoi che il cluster sia accessibile ai client in qualsiasi regione della rete VPC o di una rete connessa, devi includere --allow-global-access nella definizione della regola di forwarding.

Per ulteriori informazioni, vedi Regole di forwarding
Per completare la configurazione e verificare se il bilanciatore del carico di rete è configurato correttamente, installa e configura HAProxy tcp listener su node-1, node-2 e node-3:
1. Installa HAProxy.
```
sudo apt-get install haproxy
```
2. Scegli Y per completare l'installazione.
3. Modifica il file haproxy.cfg.
```
sudo vi /etc/haproxy/haproxy.cfg
```
4. Nella sezione Impostazioni predefinite di haproxy.cfg file, cambia la modalità in tcp.
5. Aggiungi la seguente sezione alla fine del file haproxy.cfg
```
#---------------------------------------------------------------
# Set up health check listener for SQL Server Availability Group
#---------------------------------------------------------------
listen healthcheck
bind *:HEALTH_CHECK_PORT
```
  Sostituisci HEALTH_CHECK_PORT con la porta per il controllo di integrità selezionata in precedenza. Ad esempio, 6000.
6. Avvia il servizio per confermare che sia configurato correttamente:
```
sudo systemctl start haproxy.service
sudo systemctl enable haproxy.service
sudo systemctl restart haproxy.service
```
7. Vai alla pagina Bilanciamento del carico e fai clic sul bilanciatore del carico. Osserva i tre gruppi di istanze non gestite, che ora dovrebbero essere segnalati come integri.
  
  Vai a Bilanciamento del carico
  - In alternativa, puoi eseguire il seguente comando in Cloud Shell per visualizzare lo stato del servizio di backend.
```
gcloud compute backend-services get-health aoag1-backend \
--region REGION
```
    Sostituisci REGION con la regione in cui è stato eseguito il deployment delle VM Linux.
8. Quando tutti e tre i gruppi di istanze non gestite risultano integri, vai al passaggio successivo.
  
  Nota: se il gruppo di istanze non gestite non risulta integro, potrebbe essere necessario riavviare haproxy.service dal nodo in questione.
```
sudo systemctl restart haproxy.service
```
Crea la risorsa di controllo di integrità in Pacemaker:
1. Accedi tramite SSH a node-1 e crea una risorsa per il controllo di integrità per il servizio HAProxy nel tuo cluster di pacemaker:
```
sudo pcs resource create aoag1-healthcheck \
service:haproxy \
op monitor interval=10s timeout=20s
```
2. Verifica che la risorsa di integrità sia stata avviata sul nodo principale node-1:
```
sudo crm status
```
3. Se la risorsa di controllo di integrità non è avviata sul nodo principale, spostala con i seguenti comandi:
```
sudo pcs resource move aoag1-healthcheck node-1
sudo pcs resource clear aoag1-healthcheck
```
  Vedrai che il controllo di integrità per il bilanciatore del carico sarà integro solo per node-1.
  
  Vai a Bilanciamento del carico
Crea una risorsa indirizzo IP virtuale nel cluster Pacemaker:
1. Torna a SSH su node-1 e trova il nome dell'interfaccia di rete del tuo nodo. Ti servirà nel passaggio successivo.
```
ip -c link
```
2. Crea la risorsa indirizzo IP virtuale.
```
sudo pcs resource create aoag1-vip ocf:heartbeat:IPaddr2 \
ip="CLUSTER_ADDRESS" nic=NIC_NAME cidr_netmask=32 \
op monitor interval=3600s timeout=60s
```
  Sostituisci NIC_NAME con il nome dell'interfaccia di rete del passaggio precedente e CLUSTER_ADDRESS con l'indirizzo IP riservato.
3. Verifica che la risorsa indirizzo IP virtuale sia avviata sull'host principale.
```
sudo crm status
```
4. Se la risorsa indirizzo IP virtuale non è avviata sul nodo principale, spostala con i seguenti comandi.
```
sudo pcs resource move aoag1-vip node-1
```
5. Raggruppa le risorse del controllo di integrità e degli indirizzi IP virtuali.
```
sudo pcs resource group add aoag1-group \
aoag1-healthcheck aoag1-vip
```
6. Crea una limitazione che localizzi il nuovo gruppo nello stesso nodo del gruppo principale.
```
sudo pcs constraint colocation add master aoag1-group with master ms-ag1 score=INFINITY
```

Crea un listener per il gruppo di disponibilità SQL Server

Le connessioni a SQL Server con gruppi di disponibilità devono utilizzare un nome listener del gruppo di disponibilità anziché il nome server. In caso di failover, il listener reindirizzerà automaticamente le connessioni al nuovo nodo primario nel cluster.

Torna a SSMS e connettiti al database node-1.

Esegui questa query:

ALTER AVAILABILITY GROUP aoag1
ADD LISTENER 'aoag1-listener' (
    WITH IP (('CLUSTER_ADDRESS','255.255.255.0')), PORT=1433
);
GO

Sostituisci CLUSTER_ADDRESS con l'indirizzo IP riservato.

Configurare una recinzione STONITH

STONITH è una strategia di scherma per mantenere l'integrità dei nodi in un cluster ad alta disponibilità. Il servizio STONITH funziona a livello di nodo e protegge il cluster dai nodi che non rispondono o in uno stato sconosciuto. Consigliamo il dispositivo di scherma fence_gce specializzato per Compute Engine su Google Cloud.

Configurare dispositivi di recinzione

Controlla se l'agente recinto virtuale fence_gce per Compute Engine è installato su node1:
```
sudo pcs stonith list | grep fence_gce
```
Per ulteriori informazioni, vedi:
- Agente di recinto per Google Compute Engine.
- Per visualizzare i parametri associati all'esecuzione dell'agente.
```
sudo pcs stonith describe fence_gce
```

In node-1, crea le risorse di tipo di recinzione fence_gce per ciascuno dei nodi partecipanti:

sudo pcs stonith create node-1-fence fence_gce \
plug=node-1 \
zone=REGION-a \
project=PROJECT_ID \
pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
op monitor interval="300s" timeout="120s" \
op start interval="0" timeout="60s"

sudo pcs stonith create node-2-fence fence_gce \
plug=node-2 \
zone=REGION-b \
project=PROJECT_ID \
pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
op monitor interval="300s" timeout="120s" \
op start interval="0" timeout="60s"

sudo pcs stonith create node-3-fence fence_gce \
plug=node-3 \
zone=REGION-c \
project=PROJECT_ID \
pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
op monitor interval="300s" timeout="120s" \
op start interval="0" timeout="60s"

Sostituisci REGION con la regione in cui viene eseguito il deployment delle VM Linux e sostituisci PROJECT_ID con il tuo ID progetto.

Puoi verificare lo stato degli agenti di recinzione eseguendo il comando status:

sudo fence_gce -o status -n node-1 --zone=REGION-a
sudo fence_gce -o status -n node-2 --zone=REGION-b
sudo fence_gce -o status -n node-3 --zone=REGION-c

Crea vincoli di posizione per i dispositivi di recinzione per assicurarti che vengano eseguiti solo nelle istanze previste:

sudo pcs constraint location node-1-fence avoids node-1
sudo pcs constraint location node-2-fence avoids node-2
sudo pcs constraint location node-3-fence avoids node-3

Attiva la fencing nel cluster di pacemaker e imposta il relativo timeout:

sudo pcs -f stonith_cfg property set stonith-enabled=true
sudo pcs property set stonith-timeout="300s"

Controlla lo stato del cluster:
```
sudo crm status
```

Prova i dispositivi di recinzione

Dopo la configurazione dei dispositivi di recinzione, ti consigliamo di testarli seguendo questi passaggi.

Interrompi il recinto su node-2:
1. Connettiti a node-1 ed esegui il seguente comando per testare il dispositivo di recinzione associato a node-2 dal tuo cluster.
```
fence_gce -o off -n node-2 --zone=REGION-b
```
2. Controlla lo stato del cluster.
```
sudo crm status
```
3. Vedrai anche che node-2 è disattivato in Compute Engine.
  
  Vai a Compute Engine
Riavvia il recinto su node-2:
1. Torna a node-1 e riavvia nuovamente l'istanza eseguendo questo comando.
```
fence_gce -o on -n node-2 --zone=REGION-b
```
2. Controlla lo stato del cluster in Pacemaker e Compute Engine. Dopo un breve lasso di tempo, vedrai che node-2 è di nuovo online.
```
sudo crm status
```

Configurare Corosync per il riavvio ritardato

Per evitare problemi di temporizzazione e garantire un ordine corretto delle operazioni eseguite in caso di un'azione di recinzione, ti consigliamo di ritardare il riavvio del servizio Corosync per 60 secondi.

Per ulteriori informazioni, consulta l'articolo della knowledge base di Red Hat.

Crea un file drop-in systemd che imposta un ritardo dell'avvio del servizio Corosync su node-1, node-2 e node-3:
1. Apri il file corosync.service per la modifica.
```
sudo systemctl edit corosync.service
```
2. Aggiungi le seguenti righe, salva il file ed esci dall'editor.
```
[Service]
ExecStartPre=/bin/sleep 60
```
3. Ricarica il gestore dei servizi e controlla se la configurazione viene presa in considerazione.
```
sudo systemctl daemon-reload
systemctl status corosync.service --no-pager
```
  Se vedi la sezione Drop-in, significa che le impostazioni nel file drop-in sono state prese in considerazione correttamente

Testa failover

Ora puoi verificare se il failover funziona come previsto.

Connettiti alla VM Windows su node-4 tramite Desktop remoto:
Apri una sessione PowerShell:

Esegui questo script:

while ($True){
  $Conn = New-Object System.Data.SqlClient.SqlConnection
  $Conn.ConnectionString = "Server=CLUSTER_ADDRESS;User ID=sa;Password=SA_PASSWORD;Initial Catalog=master"
  $Conn.Open()

  $Cmd = New-Object System.Data.SqlClient.SqlCommand
  $Cmd.Connection = $Conn
  $Cmd.CommandText = "SELECT @@SERVERNAME"

  $Adapter = New-Object System.Data.SqlClient.SqlDataAdapter $Cmd
  $Data = New-Object System.Data.DataSet
  $Adapter.Fill($Data) | Out-Null
  $Data.Tables[0] + (Get-Date -Format "MM/dd/yyyy HH:mm:ss")

  Start-Sleep -Seconds 2
}

Sostituisci CLUSTER_ADDRESS con l'indirizzo IP del listener e SA_PASSWORD con la password dell'account SA su SQL Server.

Ogni 2 secondi, lo script si connette a SQL Server utilizzando il valore listener di gruppo o listener DNN, ed esegue una query sul nome del server.

Lascia in esecuzione lo script.

Torna a SSH su node-1 ed esegui i comandi per attivare un failover su node-2:

sudo pcs resource move ms-ag1 node-2 --master
sudo pcs resource move aoag1-group  node-2
sudo pcs resource move aoag1-vip node-2

Torna alla sessione PowerShell il giorno node-4:
1. Osserva l'output dello script in esecuzione e nota che il nome del server passa da node-1 a node-2 a seguito del failover.

Torna a node-1 e avvia un failback a node-1:

sudo pcs resource move ms-ag1 node-1 --master
sudo pcs resource move aoag1-group  node-1
sudo pcs resource move aoag1-vip node-1

Torna a Powershell su node-4 e interrompi lo script premendo Ctrl+C.

Esegui la pulizia

Al termine del tutorial, puoi eseguire la pulizia delle risorse che hai creato in modo smetti di usare la quota e ti vengono addebitati dei costi. Le sezioni seguenti descrivono come eliminare o disattivare queste risorse.

Elimina il progetto

Il modo più semplice per eliminare la fatturazione creato per il tutorial.

Per eliminare il progetto:

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività descritte in questo documento, quando lo elimini elimini anche tutto il lavoro svolto nel progetto.
Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un appspot.com URL, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, il riuso dei progetti può aiutarti a non superare i limiti di quota.

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.