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 

RSSPlugCleanupRSSEngine@(lb_netqueue_bal) PSOD

Stamattina abbiamo trovato un host ESXi 6.7u1 in questo stato, da KB 58874 dobbiamo procedere con l'aggiornamento alla 6.7u2 oppure abbiamo come possibile soluzione temporanea applicare il seguente comando su tutte schede di rete:


esxcli network nic queue loadbalancer set --rsslb=false -n vmnicX

SWAP e UBUNTU

Mi sono chiesto varie volte se è necessario abilitare lo swap (File, partizione o LV) su sistemi Virtuali con 8+ GB di RAM.
Rimane il fatto che UBUNTU in questo LINK dettaglia in maniera interessante il tutto dando alcune indicazioni di quanto allocare per lo SWAP.

Supponiamo di avere un sistema con 8GB di RAM allocata, in questo caso viene consigliato di allocare 3GB di spazio disco per lo SWAP.

Nel mio caso che sono un fan dell'LVM procediamo con la creazione di un Logical Volume per lo SWAP.

Primo aspetto devo verificare se nel mio VG (Volume Group) siano presenti i 3 GB di spazio non allocato:

$ sudo vgdisplay

se abbiamo spazio a dispozione creaiamo il nostro Logical volume

$ sudo lvcreate -L 3G -n <LV Name> <VG Name dove ho lo spazio>
  

abilitiamo il nuovo swap

$ sudo mkswap /dev/<VG NAME>/<LV NAME> 

ricordiamoci di inserire la entry nell'fstab utilizzando lo UUID recuperabile con il comando BLKID

 vi /etc/fstab
UUID=<UUID NUMBER DEL LV>   swap     swap    defaults     0 0

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:\temp\AzureSQLServerFirewall.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>

Kubernetes Log Pod

Per vedere i log di un POD

kubectl logs <POD> -n <NameSpace> -c <Container>

Per eseguire un tail dei log di un POD

kubectl logs --follow <POD> -n <NameSpace> -c <Container>

Upgrade AKS

Nei prossimi giorni ....Upgrade AKS

https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster

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)

3. SI seleziona quali oggetti importare

4. Si applica sull'Azure SQL DB  destinatario lo script di creazione
5. Si seleziona le tabelle da importare

6. Si da l'avvio all'importazione

 e si verifica l'esito:

vCPU:pCPU ratio

From official doc VMware:

      the following vCPU:pCPU ratios can be considered a good starting point for a design:

o1:1 to 3:1 is not typically an issue

oWith 3:1 to 5:1, you might begin to see performance degradation

o6:1 or greater is often going to cause a significant problem for VM performance

I have found this script in VMware Community Site:

Foreach($esx in Get-VMHost){

    $vCPU = Get-VM -Location $esx | Measure-Object -Property NumCpu -Sum | select -ExpandProperty Sum

    $esx | Select Name,@{N='pCPU';E={$_.NumCpu}},

        @{N='vCPU';E={$vCPU}},

        @{N='Ratio';E={[math]::Round($vCPU/$_.NumCpu,1)}}

}

Output is:

Name            pCPU vCPU Ratio

----            ---- ---- -----

phesx01.pre.lab   16   26   1.6

PowerCli show Schedule Task on vCenter

(Get-View ScheduledTaskManager).ScheduledTask | %{(Get-View $_).Info} | Select Name,NextRunTime