for /f %a in ('dir /b *.csv') do for /f "tokens=*" %b in (%a) do echo %b,%a >> all.csv
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:
New VMware’s per-CPU Pricing Model
In the start of February 2020 VMware has annunced an important update her per-CPU pricing model.
We can summarize it all in this image:
This change start on April 2, 2020.
All information in this link
How to Check if OS windows has restarted in the last month
Get-EventLog -LogName System -After $(Get-Date).AddMonths(-1) | Where { 6009,6005,6006 -contains $_.EventID}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
Update PowerCLI on Powershell
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
Powershell command per recuperare una secret da Azure KeyVault
Connect-AzAccount -TenantId <ID tenant>
(Get-AzKeyVaultSecret -vaultName “Name” -name “utente”).SecretValueText
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:
- Dipendere da quanti utenti stanno eseguendo procedure di importazione DB nella vostra region.
- Se utilizzare, come spero, i servizi Firewall inclusi sugli azure sql server non avrete necessità di abilitare l’accesso da indirizzi IP “sconosciuti”
- 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