In my previous article Windows 2016 and Storage Spaces as a Veeam backup repository I talked about the advantages that Veeam Backup & Replication can bring when combined with Windows Server 2016 and the new ReFS 3.1 filesytem. Several people have asked already about some practical examples about how to design a solution using these technologies, so I thought it was time to give you one storage design.
Veeam introduced specific support for vSAN back in mid-2014 as part of Veeam Backup & Replication v7.0 Update 4. More than support I should say integration, because the software is capable of leveraging the specific architecture of vSphere vSAN to improve the backups executed against this platform.
Veeam Backup & Replication 9.5 has just been released in its GA (General availability) version yesterday, which means that every customer can download the new version and upgrade their own installation. While you download the software, let’s have a look at the What’s New document. There are as usual some really interesting things!
As Microsoft Windows 2016 is now finally generally available, people are starting to seriously looking at its features, and no doubt S2D together with the new ReFS 3.1 is one of the hot topics. I’ve first of all updated my lab with the final version of Windows 2016 in order to have my cluster in a “stable” state, than I started to focus on the different topics related to Windows 2016 and its usage as a Veeam repository. And I started to ask How can we leverage ReFS BlockCloning and Storage Spaces to make Windows 2016 the best solution for Veeam repositories? What about Storage Spaces Direct?”.
In the previous posts I’ve started to show you some of the possible uses of Ansible, in particular some example for managing Windows machines. As I’ve explained in the first post about Ansible, the software can login into any Windows machine using both local or domain users. In the latter case, Kerberos has to be configured […]
After I configured my Ansible server to manage my windows machines in the previous article, one of the first tasks I planned to automate was patching. Patching is one of those extremely boring but needed activities, and in any environment, even with a small amount of server, automated patching may be a savior. As long as proper data protection is in place, like a daily backup of the involved virtual machines, we can safely plan automatic updates, and if anything goes wrong, we just need to revert the virtual machine to the previous state.
As I’m studying Ansible, one of my goal is to manage my several Windows machines with it. I know it sounds strange as Ansible was first designed to deal with Linux systems, but this powerful configuration management platform supports Windows since version 1.7, and is completely agentless: it relies on SSH for linux/unix machines, and Windows Remote Management (WinRM) for Windows machines. Through WinRM, Ansible can connect to Windows machines ard run PowerShell scripts. The idea of using Powershell as the main code to execute tasks in Windows systems, together with the agentless approach, made me be even more curious in learning more about the Windows support.
As many guys working in IT, I have my own lab. I usually prefer to use my own lab as the degree of freedom I can experience cannot be compared with a corporate lab. It often happens that some specific configurations (one for all, my vCloud Director environment) are better looking in my own lab than any other place, and so I also use my lab to show those technologies to partners and customers. This is easy when I’m at home, but I may be in an hotel room, in a conference room at the customer’s site, or another different place, and in many of these situations it may happen (and it happened enough times to justify this little project) that the connections to my lab are blocked by a firewall or another device. I have two ways to connect to my lab: an RDP to a jumpbox machine, published on a different port that the usual TCP/3389, and an ipsec vpn concentrator. In one case, none of them was possible at a customer, so we ended up with a colleague of mine tethering from his phone. I decided it was time to develop a better solution that was able to work in almost any situation. And my solution involves the always amazing SSH.