Creating of Windows domain has always been a rock on which admins split. There are ones who will vouch for GUI. The others are more prone to PowerShell use. What do I think? Well, PowerShell is a flexible and universal tool, unlike GUI. So, no wonder this article is dedicated to creating and configuring a domain on Windows Server 2016 via PowerShell exclusively. I want to establish whether it will be helpful in the automation of this whole process.
IT infrastructure security is a number one priority, whether it be bare-metal or virtual infrastructure. The matter of safety in a Hyper-V environment, in particular, is one of those things that require attention first and foremost. However, whereas the fundamental aspects of covering the question of protection are widely known, there are always tiny details nobody really pays any attention to. Even experienced IT administrators tend to pass them by.
Windows Admin Center (WAC) is a locally-deployed, browser-based management tool that provides you with the full control over your Windows Server environment. The nice thing is, it does not push you to Azure or any other cloud, so it works for you even if you do not feel that enthusiastic about public cloud.
Finally, I got the hands-on experience with StarWind NVMe-oF Initiator. I read that StarWind did a lot of work to bring NVMe-oF to Windows (it’s basically the first solution of its kind), so it’s quite interesting for me to see how their initiator works! In today’s post, I measure the performance of NVMe drive presented over Linux SPDK NVMe-oF Target while talking to it over StarWind NVMe-oF Initiator.
While some OS-s built on Linux kernel support NVMe-oF, Windows just does not. No worries, there are some ways to bring this protocol to a Windows environment! In this article, I investigate whether presenting an NVMe drive over RDMA with Linux SPDK NVMe-oF Target + Chelsio NVMe-oF Initiator provides you the perfomance that vendors of flash list in their datasheets.
Re-investigating performance of SQL Server Availability Groups on Storage Spaces. Why You Should Always Enable Read-Only Routing
In this post, I am going to take a closer look at the impact of read-only routing on SQL Server Availability Groups performance.
I measured SQL Server Availability Groups (AG) performance before. And, a guy from Reddit recommended enabling read-only routing to achieve higher performance.
Considering how often I see NVMe-related titles over the Internet, I consider NVMe-oF to be still a hot topic. That’s why I decided to pitch in 🙂
Setting up a failover cluster is a thing that admins must do. To build such cluster, you need to configure shared storage. And, there are a lot of ways to do that. Today, I’d like to discuss how to build a Windows Failover Cluster using a virtual SAN solution (StarWind Virtual SAN) as a shared storage provider.
Can SQL Server Failover Cluster Instance run on S2D twice as fast as SQL Server Availability Groups on Storage Spaces? Summary
Since I’m done with measuring SQL Server Basic Availability Groups (BAG) on Storage Spaces and SQL Server Failover Cluster Instances (FCI) on Storage Spaces Direct (S2D) performance, I can write the most interesting part in this series: performance comparison.
Can SQL Server Failover Cluster Instances run on S2D twice as fast as SQL Server Availability Groups on Storage Spaces? Part 2: Studying FCI performance
It is the second part of my research on SQL Server Availability Groups (AG) and SQL Server Failover Cluster Instances (FCI) performance. Before, I measured SQL Server AG performance on Storage Spaces. Today, I study the performance of SQL Server FCI on S2D, trying to prove that this thing can run 2 times faster than SQL Server AG on Storage Spaces.
Subscribe to my posts
- Deploying a Windows Server 2019 S2D Cluster using Azure Resource Manager Templates
- Creating a function in Windows PowerShell and saving it as module.
- Creating bulk user accounts in AD via PowerShell
- Combining Hyper-V and DC role on the same server: Why is this a bad idea
- Creating a Domain on Windows Server 2016 via PowerShell