ISCSI e Jumbo Frame

Abilitare o non abilitare i Jumbo Frame su una infrastruttura ISCSI?

Molte volte mi sono imbattuto in questo quesito, all’inzio ero molto scettico pensando a quanti attori  sono coinvolti ….e anche adesso lo sono, soprattutto quando devi mettere mano a una infrastruttura esistente e non hai switch dedicati al backend di comunicazione dei nostri hosts con lo storage.
Questo articolo di VMware riassume la mia opinione:
   
ISCSI e Jumbo Frame

Copy file to VMware Datastore using Powercli

https://kb.vmware.com/s/article/2001041

#Mi collego all’Host ESXi dove devo copiare la ISO
Connect-ViServer <hostname>
#Visualizzo l’elenco dei datastore
Get-Datastore
#Seleziono il datastore che mi interessa
$datastore = Get-Datastore “<nome del datastore>”
#Eseguo il mount del PSDrive sotto ds:
New-PSDrive -Location $datastore -Name ds -PSProvider VimDatastore -Root “”
#Lancio la copia
Copy-DatastoreItem -Item c:……Windows2016.iso -Destinatiom ds:ISO

Copy file to VMware Datastore using Powercli

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

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
SWAP e UBUNTU