A few months ago we decided to change the configuration of some of our virtualization servers that were using Hyper-V replica to create replicas that could be used in case of a disaster. We used to replicate such machines so we could restore them quickly in case of issues or even start them on the destination host, if needed.

I will deal with the reasons why we decided to switch technology, from Hyper-V replica to Windows Storage Replica, in a different, bigger post but one thing we noticed quite soon during our first migrations was that sometimes our replicated volumes were apparently hanging in a WaitingForDestination status. As the name implies, it seemed that such status should mean that the source volume cannot contact the destination one so the replica is suspended.

We tried to diagnose the issue for a few time. We were sure that it wasn’t an issue with communications between the two machines because the connection from source to destination was clearly available plus some machines also had volumes replicated onto each other, that is Server 1 was replicating volume X to Server 2 and Server 2 was replicating volume Z to Server 1; and in such cases the replication was suspended one way, say from Server 1 to Server 2, but not suspended and working fine from Server 2 to Server 1. Clearly that was not a connection issue.

At first we thought that server would eventually re-establish a working connection to the destination, after trying to connect from time to time but we noticed that in one case the source suspended replication for 3 days without (self-)healing. Which was somewhat odd since during the same period of time the inverse operation had been working fine. No issues during the same period of time when the other replica was waiting for the destination while that other replica task was also displaying a Failed status on the destination instead of the usual ContinuouslyReplicating.

Clearly the replica was stuck and I noticed that there are a very few pages on the Internet dealing with this status and the same situation. In a couple of cases someone suggested to restart the replica service which is an option but not a very handy one since to restart the service we needed to shutdown ALL of the virtual machines hosted on that server.

Let me be clear here because I see this one rarely mentioned in blog posts and even in the documentation: restarting replica service will crash your services because the source volume, not the destination, will be briefly dismounted. So before you restart the service on source server, stop any service or application that is using your volume.

When we tried to shutdown the VMs that were running on that host and actually restarting the storage replica service, replication started right away without issues so it was clear that something was wrong with the storage replica service. Some users reported that they solved a WaitingForDestination status by issuing a

Get-SRGroup | Sync-SRGroup

command, which is supposed to [...]

La prima scelta che è stato necessario prendere mentre progettavamo il design di Skynet era ovviamente il framework o i framework da usare per lo sviluppo. Le soluzioni sono moltissime e sicuramente ognuno ha delle ragioni specifiche per pensare a questa o quella soluzione in modo da semplificare il lavoro ed ottenere magari una piattaforma aperta che possa includere altre tecnologie o soluzioni. Un esempio tipico è quello di partire da un progetto opensource o magari disegnare un frontend basato su WordPress e sviluppare estensioni e moduli per integrare le funzionalità che servono. Con tutte le tecnologie che esistono, non c’è un modo giusto o sbagliato ma semplicemente una preferenza in base ad alcune valutazioni che si fanno internamente e che dipendono anche dall’esperienza che il team ha acquisito nonché dall’integrazione che è possibile o meno con altre tecnologie che magari sono già presenti in azienda e che si vogliono riutilizzare o estendere.

I requisiti di Skynet

Come sempre, si parte da quelli che sono i requisiti del progetto. Il design di Skynet deve avere alcune caratteristiche che derivano dalla nostra esperienza nell’uso di decine o anche centinaia di tecnologie tra orchestration, pannelli di controllo, sistemi di gestione e così via.

Multipiattaforma

La tecnologia di cui avevamo bisogno doveva essere multipiattaforma in modo da consentire la gestione e soprattutto l’automazione dei sistemi più diffusi e quindi Windows e Linux. L’uso di un framework multipiattaforma doveva consentire anche il riutilizzo massiccio del codice che prevedevamo di scrivere per le decine di componenti che comporranno Skynet.

C’è inoltre da fare una ulteriore divisione all’interno del codice, prevedendo codice applicativo, che sarà indirizzato alle componenti principali, e un layer di interazione con i sistemi da gestire con i quali non sempre la scelta migliore è quella di usare un software ma spesso è più pratico affidarsi alle tecnologie di scripting. Inoltre, un layer di scripting consente – se messo in sicurezza – di prevedere anche un modo veloce per far evolvere singole funzionalità senza costringere al deployment dell’intero software.

Prevalentemente asincrono e durevole

Un sistema di gestione e di orchestrazione come quello che stiamo progettando deve necessariamente prevedere la possibilità di comunicare con diversi moduli che possano trovarsi non solo su sistemi diversi ma addirittura in datacenter diversi e distribuiti geograficamente e persino interagire con sistemi esterni alla nostra infrastruttura. Per la loro stessa natura queste interazioni non possono essere considerate come affidabili o parte di una rete costantemente connessa ma si deve dare per scontato che che questi sistemi possano essere saltuariamente disconnessi, ad esempio a causa di un temporaneo errore di rete, o incapaci di completare le azioni richieste al primo tentativo magari per un sovraccarico dei sistemi coinvolti o un altro problema saltuario.

Per questa ragione il framework che è stato scelto deve avere una forte impronta asincrona e non può essere basato su workflow che si aspettano di completare le operazioni in pochi secondi e senza una logica di retry/fail. Questo significa anche che i workflow che vengono eseguiti devono poter gestire questi possibili errori [...]

Microsoft is investing a lot into its new Server Manager though Redmond is not encouraging that parallelism and often says that Windows Admin Center is not a 1-to-1 replacement for Server Manager. That is true because Server Manager and its underlying technology has a deeper connection with the operating system and it can be considered a platform while Winows Admin Center can be considered a very sophisticated shell that mostly works through WMI/Powershell connections.

However, Windows Admin Center is gaining a lot of traction and it’s quickly gaining support because its Web UI allows to embed important tasks into simple to access and to use widgets called tools and access them through a simple browser. Productivity is enhanced especially when used with the Core version of Windows operating systems and I’m not surprised that Microsoft is experiencing a growth in adoption for the Core SKUs because of it.

Why containerizing Windows Admin Center ?

So the first question would be: why would someone want to containerize Windows Admin Center ? First, a containerized WAC would be very easy to deploy on multiple systems in a very straightforward way. Furthermore, multiple copies of WAC, possibly in use by different teams, could be deployed and used thanks to the isolation provided by containers and their flexibility. Containers could be also useful to mitigate any security issue that could arise even if Windows Admin Center showed no security vulnerabilities as far as I know. Finally, by using Hyper-V isolation multiple instances of WAC could be isolated and provided to multiple tenants.

Prepare the environment

To deploy WAC into a container we will use Windows Server 2019. We must first enable containers support by selecting and adding the feature in Roles&Features section of Server Manager:

Then we must install Docker as per Microsoft Docs :

Install-Module -Name DockerMsftProvider -Repository PSGallery -Force

and then

Install-Package -Name docker -ProviderName DockerMsftProvider

and finally restore Windows Server 2019 to complete installation

Restart-Computer -Force

When server restarts we can pull the Windows Server 2019 Core image that we will use to run Windows Admin Center. Note that WAC doesn’t need IIS because it will self-host so downloading the base OS image will be enough

docker pull mcr.microsoft.com/windows/servercore:ltsc2019

After downloading the image we are now ready to spin our new container and install Windows Admin Center.

Create the WAC container

We have a choice to make before creating the container for WAC and that is the port we want to expose WAC onto. That would be the port we connect to in order to use WAC. To make our life easier now, we will expose this port to the host but more sophisticated deployments might be appropriate depending on what you’re trying to achieve. We need to decide that first because we will then need this information when installing Windows Admin Center. We will make it available on port 8443.

docker run -it -p 8443:8443 mcr.microsoft.com/windows/servercore:ltsc2019 cmd.exe

If everything goes well you will have CMD prompt ready after starting the container. Now we need to copy the installation files into the container. You probably downloaded [...]

We had a weird problem when moving a WordPress website for a customer: after DUMPing it out of MySQL, we noted that the wp_options table had a problem, namely the table had no primary key and no index on the option_name field. We noted that because the WordPress website, once moved, looked akward and wrong, missing some key pieces and it also seemed to use settings that were old. The reason was that, with primary key missing, lots of duplicate records were stored inside the table and I’m pretty sure it was not what the website was meant to do. Field option_id was set to 0 in most cases when it should have been an auto-incremented integer plus it seemed that the website was not updating settings, rather it was storing a new copy of them each time.

The akward look was probably due to WordPress not being able to load-up the most recent settings but the weird thing was that it was working like a charm on its existing server. However, we noticed that the source server was running MySQL 5.1 while the destination was instead running MySQL 5.7. MySQL is that weird beast where everything can happen but anyway that 5.1 version was really really old. I would expect such things not to happen in an enterprise world (never had such problems with SQL Server) but…

The problem

So the first problem we had to solve was re-enabling primary key for field option_id and its indices but we couldn’t add a primary key on that field since thousands of record were using the same key (zero) so we had to find a way to update them with a unique value. The best solution would be to have consecutive integers though that wouldn’t ensure that we are restoring the right order. But I’m afraid there’s no real way to be sure about that. However, when enumerating records one might assume that the table scan would populate results from the oldest to the newest. Not sure about this but we might try.

So we basically developed a stored procedure that would scan that table and update each record to set a new option_id. One of the key problems with this is that you need to perform only an update at a time because you cannot use any relevant key to uniquely get the record given that option_id is zero. Other fields might be the same for multiple records so for example if we try to select records based on option_name we might have multiple records update with the same option_id and we wouldn’t solve our problems.

We might just hope that we’re lucky enough so that scanning for zero keys and updating just a single record would just update in the same order. Anyway, the key to change the table design is to have different keys, it is not strictly necessary to have the same order though quirks might happen if we don’t do that. The real important thing is to ensure we won’t [...]

Come service provider VaiSulWeb ha sempre gestito al proprio interno un numero di tecnologie molto elevato e ci siamo sempre avvalsi di tanti strumenti, a volte più semplici da integrare, altre volte meno. C’è una tendenza molto diffusa oggi nel delegare ai cloud provider ipermassivi come Microsoft Azure o Amazon AWS la gestione di tante tecnologie, soprattutto quelle più complesse e principalmente da parte dei provider più piccoli. A VaiSulWeb abbiamo sempre gestito le nostre infrastrutture proprietarie e non prevediamo di cambiare questa visione che per noi è strategica tuttavia è cambiato lo scenario anche rispetto a pochissimi mesi fa e se prima veniva considerata probabile una crescita incontrastata dei provider cloud ipermassivi, oggi si ritiene che un approccio ibrido sia quello che verrà scelto dalla maggior parte delle aziende.

VaiSulWeb ha sempre integrato molti strumenti diversi ma la complessità di questi nuovi scenari, nei quali si fondono insieme gestione on-premise e la partnership con molte aziende diverse anche nell’ambito di confini della singola applicazione (si pensi ad esempio ai servizi di AI o cognitivi integrati in applicazioni ospitate all’interno di altre infrastrutture) rende necessaria la creazione di strumenti che non solo consetano di gestire questa complessità ma che rendano possibile anche una personalizzazione di tali strumenti per allinearli con gli obiettivi aziendali. L’ingresso nel mercato dei servizi di aziende che avevano operato nella produzione di software, come Microsoft, ha infatti reso necessario lo sviluppo di strumenti indipendenti che non risentano degli obiettivi – a questo punto spesso conflittuali – tra i service provider come VaiSulWeb e quelli che sono i produttori dei software che abbiamo usato per fornire i nostri servizi ai clienti, ora trasformatisi anch’essi in fornitori di servizi e che, come tali, perseguono i propri obiettivi.

Se fino ad ora VaiSulWeb, come molti altri provider, ha operato spesso integrando le piattaforme di diversi produttori di software, la trasformazione di questi produttori in fornitori di servizi spesso comporta anche un differente approccio verso lo sviluppo di tali software e le loro possibilità di integrazione, con l’obiettivo (legittimo) di favorire i servizi del produttore stesso ma con l’effetto a catena di ridurre la qualità e la semplicità dell’integrazione di tali software in ambienti di service provider diversi. Diventa quindi strategico lo sviluppo di uno strumento completamente indipendente che consenta l’integrazione, l’orchestration, la gestione, il monitoraggio e la personalizzazione di molteplici tecnologie anche per garantire ai nostri clienti la sicurezza di una infrastruttura completamente indipendente e resistente ad eventuali mutamenti di condizioni da parte di fornitori che per buona parte sono oggi anche competitor.

La nuova piattaforma di VaiSulWeb

Per tutte queste ragioni abbiamo deciso quindi di investire nello sviluppo di una piattaforma tecnologica completamente indipendente e abbiamo deciso di procedere ad  uno sviluppo aperto, condividendo le nostre riflessioni, le nostre scelte tecnologiche e spunti che possano magari essere interessanti per altre realtà. Questa sezione di The Server-Side Technology seguirà quindi questo processo. Ad oggi non prevediamo di rilasciare l’intera piattaforma come open-source ma di rendere disponibili singoli elementi che abbiano un potenziale uso [...]