Azure SQL server – Database copy

Alla fine del 2019 ho postato nel Blog alcune indicazioni come effettaure un allineamento di un Azure SQL DB da un ambiente di Sviluppo a un ambiente di Produzione, a quel tempo (si sembra passato molto tempo..) avevo utilizzato il bpac.

In questi giorni ho dovuto eseguire la stessa attività su un’altro cliente (DB di Produzione  su DB di Dev su azure SQL server differenti  anche in sottoscrizioni Azure differenti) in questo caso ho provato un comando T-SQL. 
Il comando è:
CREATE DATABASE <nome del DB nella Destinazione> AS COPY <nome Azure SQL server> .<nome del DB sorgente>
Nel dettaglio sono necessarie alcune attività propedeutiche di annotazione e permessi:
– Sul server di destinazione la presenza di una security con Username e Password uguali al DB owner del DB sorgente. (con permessi sull’Azure SQL di destinazione di DBmanager e loginmanager)
– Memorizzare le security del DB di destinazione che andremo a rimuovere 
– Avere un Sql Server Management Studio (SSMS) installato su un client che può accedere ad entrambi gli Azure SQL Server (Ricordarsi di abilitare l’accesso sul firewall dell’Azure SQL server)
Se abbiamo fatto tutte le attività propedeutiche procediamo:
– Accesiamo via SSMS all’ Azure SQL server di destinazione con l’utente comune ai due Server SQL.
– Lanciamo il comando T-SQL:
CREATE DATABASE <nome del DB nella Destinazione> AS COPY <nome Azure SQL server> .<nome del DB sorgente>
  attenzione:
  •  ricordiamoci che il nome dell’Azure SQL server necessita solamente dell’hostname e se abbiamo caratteri particola nel nome (come un meno) di includerlo in “”. Es. “server-sql-azure-01”.<nome DB>
  • conviene, caso di una sostituzione di un DB esistente sulla destinazione, copiarno con un nome differente es <nome DB>NEW e poi procedere in un secondo momento con la rimozione del vecchio DB e la rinomina del nuovo.
al termine avremo il nuovo DB
– Modifichiamo l’owner del DB 
ALTER AUTHORIZATION ON DATABASE::<nome DB> to <nuovo Owner>;

– Rimuoviamo eventuali permessi dell’infrastruttura sorgente.
– Assegniamo al DB i permessi degli utenti (che se abbiamo fatto le azioni propedeutiche ci siamo segnati, oppure se siamo stati furbi possiamo recuperarli dal DB che non abbiamo ancora cancellato)
– Rinominiamo il DB con il nome definitivo
– Cancelliamo la login che avevamo creato  per procedere alla copia (ovviamente solo dal server di destinazione)
Attenzione !!! Ricordiamoci  se presente un backup ( NON MI DITE CHE NON FATE I BACKUP DEI DB …) di andare ad assegnare la policy  che preferite. 
Questo è tutto!!!
Riferimenti Microsoft 
Azure SQL server – Database copy

Connessione SSH nodi del cluster AKS (Azure Kubernetes Services)

###Attenzione per eseguire queste operazione dovete aver già dimestichezza con i comandi KUBECTL###

Per prima cosa devo generare la mia coppia di chiavi (Pubblica e Privata).
Utilizzando il mio Windows System Linux (WLS) con Ubuntu genero le chiavi:

ssh-keygen -m PEM -t rsa -b 4096 -C “azureuser”

Dove azureuser è l’utente standard presente sui nodi AKS, e quindi mi server come promemoria.

Adesso ho la coppia di chiavi nella mia directory /home/localadmin/.ssh/, devo scaricarli sul pc le chiavi create

I prossimi passaggi sono quelli di caricare la chiave sul pubblica sul nodo/i a cui voglio collegarmi e utilizzare la mia chiave privata per la connessione ssh utilizzando un container ponte.

Bene adesso  mi devo collegare via Powershell alla  tenant e alla subscription dove è deployato il mio cluster AKS

Connect-AzAccount -Tenant  <ID del Tenant>

az account set –subscription “<Nome della subscription>

$CLUSTER_RESOURCE_GROUP=$(az aks show –resource-group <resource group del AKS> –name <nome dell’AKS> –query nodeResourceGroup -o tsv)
az vm list –resource-group $CLUSTER_RESOURCE_GROUP -o table

Verrà visualizzato l’elenco delle su cui caricare la chiave pubblica.

az vm user update –resource-group $CLUSTER_RESOURCE_GROUP –name <nome del nodo> –username azureuser –ssh-key-value C:tempQTYK8id_rsa.pub

il valore –ssh-key-value è dove abbiamo posizionato localmente la chiave pubblica da caricare sul nodo

Installo il container ponte 

kubectl run –generator=run-pod/v1 -it –rm aks-ssh –image=debian

Mi troverò già dentro al container ponte, a questo punto aprire una nuova powershell, effettuare la procedura di logon (Az Connect ecc..)
Copio la chiave privata sul container ponte (che si chiamerà aks-ssh)

kubectl cp .id_rsa aks-ssh:/root/id_rsa 

Una volta copiata la chiave possiamo tornare alla sessione di powershell in cui siamo già loggati al container aks-ssh
Modificare i permessi al file id_rsa

chmod 06000 /root/id_rsa 

Installare il client SSH nel container.

apt-get update && apt-get install openssh-client -y

Possiamo finalmente loggarci al nostro host AKS per fare le attività richieste (di solito troubleshooting)

ssh -i /root/id_rsa azureuser@<ip del nodo>


Alcune considerazioni:
– Se usciamo dal container ponte AKS-SSH per rientrarci

 kubectl exec -it aks-ssh bash

Se vogliamo vedere se il nostro pod AKS-SSH è presente

kubectl get pod

– L’indirizzo IP del nodo lo posso recuperare dal portale azure

Connessione SSH nodi del cluster AKS (Azure Kubernetes Services)

Allineamento Azure SQL DB

Lavorando con i servizi Azure SQL Server/Azure SQL DB e ambienti di DEV/QTY/PRD può capitare la necessità di allineare i dati e le struttura dei DB.

Ho provato due scenari di ripristino da un file BACPAC:

  • Portale Azure 
  • SqlPackage.exe
Per la mia esperienza consiglio l’utilizzo di SqlPackage.exe il motivo principale è che in questa maniera non dovrete:
  1. Dipendere da quanti utenti stanno eseguendo procedure di importazione DB nella vostra region.
  2. Se utilizzare, come spero, i servizi Firewall inclusi sugli azure sql server non avrete necessità di abilitare l’accesso da indirizzi IP “sconosciuti”
  3. Non avrete limiti di dimensione del DB che volete importare.
Come funziona l’importazione da Portale Azure? Qui la guida ufficiale
Prima di procedere è necessario prendere in considerazione questi aspetti:
  • Viene messa a disposizione una “Machine” (tutto automatico e trasparente per il sistemista) con al massimo 405GB. Ma per completare l’importazione sarà necessario 3 volte la dimensione del BACPAC che dovete importare. Quindi se la matematica non è un opinione la dimensione massima del file dovrà essere 150GB 
  • Può capitarvi un errore simile:
        è necessario abilitare sul firewall del Azure SQL Server di destinazione l’IP evidenziato 
  • Può succedere che per caricare un DB di dimensioni ridotte siano necessarie delle ore. Tenete conto che il processo di creazione dipende da quante richieste di importazione nella region sono state effettuate (non solo da voi ma da tutto il mondo), perchè la richiesta viene accodata e poi quando è il vostro turno (ma non è dato di sapere) verrà processata. Come indicato in questo link ufficiale. Se dopo 4 giorni non è stata processata la tua richiesta di import viene cancellata 
Per avviare l’importazione è necessario:
– Caricare il file bacpac su un container su Azure Storage Account 
– Accedere via portale all’azure SQL Server e selezionare la voce:

– Configurare i vari parametri 
– Lanciare l’importazione
Per monitorarla è possibile farlo Import/Export History 
Se vi collegate con SSMS al Azure SQL Server vedrete che il DB viene creato immediatamente, appena parte il job di importazione, ma poi il job rimane in pending e le tabelle e i dati non vengono popolati… il tutto rimane in attesa del proprio turno di importazione 
Come funziona l’importazione da SqlPackage.exe? Qui la guida ufficiale
Avete la necessità di:
  • Scaricare il SqlPackage  e installarlo 
  • Abilitare una VM  per l’accesso all’azure Sql Server (sempre il discorso del Firewall), ma in teoria una VM di Management dovreste già averla..
– Da powershell dovete utilizzare il seguente comando:
.SqlPackage.exe /a:Import /sf:<percorso-del-bcapac> /tsn:<Azure SQL Server> /tdn:<Nome del DB> /tu:<Account> /tp:<Password> /p:DatabaseEdition=<Standard/basic ecc> /p:DatabaseServiceObjective=<es. S2>
Il comando se il DB non esiste lo crea …
Al termine di entrambi i processi ricordatevi di:
– Eliminare le credenziali sql non necessarie
– Dare i permessi alle credenziali sql necessarie
-Sistemare i backup 
Allineamento Azure SQL DB

Modifica delle Firewall Rule su Azure SQL Server

ATTENZIONE:
“The PowerShell Azure Resource Manager module is still supported by Azure SQL Database, but all development is now for the Az.Sql module”

Per cui la prima cosa da fare è iniziare ad abbandonare Powershell Azure Resource Manager…. poi:

– Login al tenant dove sono allocati gli Azure SQL Server 

Login-AzAccount -Tenant <ID>

– Esportare le regole in CSV per poi creare i comandi in maniera rapida editando il file XLS 

Get-AzSqlServer | Get-AzSqlServerFirewallRule | Select-Object -Property ResourceGroupName,ServerName,StartIpAddress,EndIpAddress,FirewallRuleName | Export-Csv -Path C:tempAzureSQLServerFirewall.csv -NoTypeInformation

– Modificare le regole 

Rimuovere una regola 

Remove-AzSqlServerFirewallRule -ResourceGroupName <Name> -ServerName <Azure SQL Server> -FirewallRuleName <RuleName>

Aggiungere una regola 


New-AzSqlServerFirewallRule -ResourceGroupName <Name> -ServerName <Azure SQL Server> -FirewallRuleName <Rule Name> -StartIpAddress <IP> -EndIpAddress <IP>

Modifica delle Firewall Rule su Azure SQL Server

Migrare su Azure un SQL DB – From SQL Server to Azure SQL Server

Test utilizzando bacpac direttamente da SQL Studio, errore:
La creazione del bacpac fallisce, il motivo sembra essere la presenza degli utenti di dominio nelle security. Error SQL71627 SQL Server bacpac migrate to Azure SQL Server. “
Provo con il tool Data migration Assitant. Operazione completata con successo (non ha importato le utenze collegate ad AD)
*Attenzione sull’Azure Sql server il database di destinazione deve essere già presente.
  1. Si seleziona il sorgente
  2. Si seleziona il destinatario (Su azure)

  1. SI seleziona quali oggetti importare
  1. Si applica sull’Azure SQL DB  destinatario lo script di creazione
  2. Si seleziona le tabelle da importare
  1. Si da l’avvio all’importazione
 e si verifica l’esito:

Migrare su Azure un SQL DB – From SQL Server to Azure SQL Server