Today Microsoft has announced that there is a new way to buy Azure SQL DB. If DTUs aren’t making sense to you, you’ll be happy to know that you can now simply select how many vCores you want for your SQL DB workload. Now this will still require that you have an understanding on your workload to use this new vCore based way to buy Azure SQL DB, but Cores are a concept that is easy for people to talk about and wrap their heads around. Now this new model is only in preview at the moment, but I’m guessing that it’ll be around for a while in preview, then it’ll go GA as this new model makes sense.
Personally, I see people moving to this new model instead of the DTU model as the vCores model is just easier for people to figure out, and explain around the office. Also, there’s no math to convert what you have today into DTUs.
Another nice benefit of using vCores for SQL DB is that if you have SA, you can use your existing SQL Server licenses to get a discount on your SQL DB pricing. Now, this does require that you keep your software assurance current on these licenses, so that may end up eating at least some of your savings. A lot more math will need to be done to see how this works out.
As you can see from the screenshot from the portal, you can select the number of cores that you want for your use case and the maximum size of the database for your use case. vCores give many customers a much more scalable solution then they had used just DTUs. You should see the new vCores in the Azure portal shortly (I can’t see them in my normal portal yet) and they’ll be available in all regions as they roll out.
The big question for people will be what makes the most sense? And that answer is going to be vCores.
The other big question that I see if how many vCores do I need for X DTUs? That answer will be a little greyer. It’s going to take some trial and error when moving back to find the sweet spot between vCores and DTUs so that you have enough resources without paying more than you need. The nice thing about the cloud is that you can ramp up and down quickly and easily depending on what you see as your applications response time. For most customers, I’d recommend starting with a larger number of vCores and if performance in the portal (or SCCM if you have it) is low for that database then ramp down and see how it responds.
On top of the new vCore based solutions that Microsoft announced today, you also have your managed instance option available. The managed instance option can only be sized based on the new vCore solution as you have no option for the number of DTUs that will be supported. Managed instances are the solution that Microsoft provides that’s between IaaS instances in VMs and SQL DB where Microsoft hosts the databases for you, and you can do most everything that you can on-prem or in IaaS, but in a PaaS model. Realistically the only way this option was have made a lot of sense was with the vCore option that Microsoft is announcing today.
Overall I think this vCore option is going to make a lot of sense, and realistically should have been where Microsoft started from instead of DTUs.
If you are looking to move into SQL DB, DCAC can help you get there. Using either the DTU model or the vCore model.
If you’ve tried using Universal Groups in Active Directory to access your SQL Servers, you may notice that the users who are members of these groups can’t access the SQL Server Instance. The reason for this has more to do with active directory than with SQL Server. Normal groups in Active Directory are cached so authentication requests can return groups that the user is a member of as part of the Windows Token. Universal groups, however, aren’t included in the Windows Token as the Universal groups that the user might be a member of might not be in the same domain that the request is handled by.
The internals of why Universal Groups don’t work requires a decent understanding of the internals of Windows Authentication Tokens and Windows Security. But needless to say, all that you need to know is that Universal Groups don’t work with SQL Server.
Because the Universal Groups aren’t in the authentication token when the SQL Server goes to see if the user has access, the token says that the user doesn’t. The fix for this is quite easy, use a different Windows Domain Group type than Universal Groups.
I’m thrilled to announce that we’ll be hosting a pre-con at SQL Grillen this June in Lingen, Germany titled “Designing Azure Infrastructure for Data Platform Projects” which you can see on the events schedule page. The abstract for the session is:
In this daylong session, we’ll review all the various infrastructure components that make up the Microsoft Azure platform. When it comes to moving SQL Server systems into the Azure platform having a solid understanding of the Azure infrastructure will make migrations successful and making support solutions much easier.
Designing your Azure infrastructure properly from the beginning is extremely important. An improperly designed and configured infrastructure will provide performance problems, manageability problems, and can be difficult to resolve without downtime.
As Azure scales around the world many more companies, no matter where they are located, will begin moving services from on-premises data centers into the Azure Cloud, and a solid foundation is the key to successful migrations.
With four new regions announced in Europe, bringing the total of European regions up to 12, more and more companies will be looking at the cloud for the hosting needs. Seating for this day-long session is limited, so you’ll want to register right away to ensure you get a seat at the session.
VMware recently announced they’re vExpert list for 2018 and I’m proud to say that both Joey and myself were on the VMware list for 2018. The VMware vExpert program is designed to recognize those in the VMware community who help out with the VMware community at large. While the vExpert list looks rather large, it’s a big world and there’s a lot of people working around the world helping VMware users to setup various VMware products. I know that both Joey and myself and thrilled to have been awarded this award for 2018.
Having VMs in Azure which are members of your on-premises domain is a pretty important part of your Cloud implementation. There’s a couple of ways to do this, but I’ll be covering what we at DCAC think is the best option. In basic terms, you’ll set up a VPN from the Azure vNet to your on-premises network. From there you’ll want to add domain controllers to Azure which are members of the on-premises domain (not just another domain with the same name). Then change your vNet to use those DCs as your DNS servers, reboot your other VMs, and you’ll be able to add the other VMs to your Active Directory domain. Here are some details:
The first step is to put some domain controllers in Azure. To do this, you’ll need a site to site VPN between Azure and your on-premises environment. If you have multiple on-premises sites, then you’ll want to create a VPN between Azure and all your on-premises environments. If your A zure environment is hosted in multiple regions, then you’ll want to create a mesh network when each on-premises site in VPNed into all of your vNets. You’ll probably also want your vNets VPNed to each other (Peering of your networks between sites may be an option as well depending on how you’ve set things up). If you have an extremely large number of users at your site, then Express Route might be something worth looking into instead of a site to site VPN.
Once the Site to Site VPN (or Express Route) then you can focus on putting some domain controllers in Azure. Each site within your Azure environment should have at least 2 DCs, and they should be created within an Availability Set, or an Availability Zone (depending on what your standard is going to be for setting these up). You can now set the vNet to use the office DCs as DNS Servers. Once that’s done, reboot the Azure VMs that you want to make domain controllers and promote them to DCs. When making them DCs, you’ll probably want them to be a fairly large VM size so that the promotion process doesn’t take that long. You can resize them later. Once the VMs in Azure have been created as DCs, you’ll want to make those VMs have static IP addresses (whatever IPs they have are fine). Make a note of these IPs as you’ll need to enter them in a second.
Once the DCs are setup go into the vNet configuration and set the DNS servers for the vNet and change the vNet to use the new Azure DCs as your DNS Servers (you wrote these down at the end of the prior paragraph). Then reboot any VMs that you’ve created already in the vNet.
At this point all the VMs that you have already created before now can be added to the domain without issue just like any other machine in your environment.
A lot of the examples you’ll see for MAXDOP on the web assume a large server with multiple physical sockets and multiple NUMA nodes. But if you have a smaller server, like a lot of us do these days, what should you set the MAXDOP to?
The basic rules still apply, that you should set the MAXDOP to 1/2 of the size of your NUMA node. Just because you’re running a smaller server doesn’t mean that you don’t have NUMA configured, it just means that you have a single NUMA node. So for example if you have a server with one socket and six cores, then your MAXDOP should probably be set to 3; since three is 1/2 the size of the server.
Now there’s a lot of it-depends that goes with this, but this gives you a starting point. You might need to decrease MAXDOP to 2 and see how this affects the server.
Keep in mind that making changes to MAXDOP during the business day isn’t recommended as making changes to MAXDOP will flush the plan cache and cause all the queries to be recompiled.
The short answer here is no. The threat detection features that you see in Azure are not available in the on-premises product. This includes VMs running SQL Server instances in Azure. The only way to get the SQL Server threat detection features that Azure offers is going to be to use the SQL DB feature in Azure.
I ran into an interesting issue last week. I had VMs in the US West region of Azure which was unable to talk to the MySQL database service (PaaS) also in US West. The problem is turned out was due to a new feature that needed some adjusting to make work (there’s already a bug open to get this fixed).
The issue was that I couldn’t log into the MySQL PaaS service using VMs in my vNet. The error that I was getting was that I couldn’t access the PaaS service using VMs within a vNet.
The underlying issue was that the configuration of the Subnet within the vNet had the Microsoft.Sql service endpoint configured for that subnet. Once that was removed from the Subnet I was able to connect from the VMs to the MySQL for SQL Databases Service.
Microsoft is thankfully already aware of this problem. If you are using any combination of the PaaS services SQL Server, MySQL, Postgres and you want to use the Microsoft.Sql service Endpoints; for now, you need to put any virtual machines connecting to them of different subnets. Those subnets can be within the same vNet; they just need to be within different subnets within your vNet configuration.
In my case, my servers are only using MySQL and nothing within the subnet is trying to connect to SQL DB or SQL DW, so removing the Service End Point was the easiest solution. Once I did this, I was able to access my web servers again without issue.
Yep. This is actually by design; and is because listeners can be tricky little fellas. When using a SQL Server Availability Group Listener, you can see any databases on the server that is hosting the Availability Group Listener. The reason for this is because each SQL Server Availability Group Listener merely is a connection to the instance that’s hosting that Availability Group.
You can think of Availability Group Listeners kind of like a DNS entry. Whatever server the listener is pointed at that’s the server that all users can connect too. If for example, you had a server configuration with two Availability Groups and two Availability Group Listeners; if those two listeners are hosted on the same node of the Availability Groups and a user connects to one of the listeners, then the user would be able to access any of the databases (assuming they have access to all of them).
This is by design, and everything is working exactly as it should be.
This same rule applies to databases which aren’t protected by the availability group. If you have multiple databases protected by an Availability Group, and several databases hosted on the active server which aren’t members of the availability group and a user connects to the Availability Group listener, they’ll be able to see all the databases on the server. This also means that as the Availability Group Listener is moved from replica to replica databases will come and go as the Availability Group is moved.
Hopefully, this explains why you might be seeing things you aren’t expecting.
The GDPR or General Data Protection Regulation as its actually known is a European law that will be taken effect in May 2018. There’s a lot of misconceptions out there that need to be talked about, especially by non-EU websites.
Before we get started, let me state that I’m not a lawyer, and I don’t even play one on TV. Everything that I’m talking about should be verified with an actual lawyer.
The fines for violations of the GDPR are pretty steep. 20 million Euros or 4% of your companies revenue, whichever is HIGHER. Beyond this websites could be blocked from being accessed within the EU. In other words, this law is severe, and it doesn’t apply to just companies that operate in the EU.
One of the bigger misconceptions is that the GDPR is related to sales. It isn’t. The GDPR relates to personal data of the people that view your website whether they buy anything or not. This includes your comments, feedback, collecting emails, newsletter subscribers, etc.
Most people are using WordPress for their websites. As of late January 2018, there’s minimal plugins available. And the ones who are there have minimal installs. Jetpack, which is one of the biggest plugins available is working on GDPR compliance. They aren’t there yet, but they are working on it.
The biggest thing with the GDPR (as far as I’m concerned) is how to deliver the users request to be deleted. For DCAC the only place we have to worry about this is with comments. Our vendors (Mail chimp and Microsoft’s O365) both have or are working on GDPR compliance and will have something put together in time.
Another piece of the GDPR is that users from the EU need to be able to request an export of their data from your systems. For DCAC this is pretty simple, we just need to be able to export comments and what event data we collected. Our email sending doesn’t contain anything other than what newsletters the user received from us (and we can get this from Office 365). No matter how you export the data you need to be able to export the data and deliver it to the user that requests it. The user also needs a way to download their data. Today WordPress doesn’t have a solution for this, but hopefully, it will by the time the law kicks in.
The scary part of the GDPR is telling people if the website is breached, and you have 72 hours from when you discover the breach. There’s no real definition of user, so the assumption is that commenters, notification form submitters, etc. At least this is our assumption. Our hope, of course, is that a breach doesn’t happen, but we have to prepare for the worse.
It isn’t scary, but there’s a lot
As you can see there’s a lot to this GDPR stuff that needs to be worried about. Done correctly you can lean on vendors like WordPress’s JetPack plugin, Microsoft’s Dynamics 365 (part of the Office 365 suite) and Mail Chimp.
Hopefully, this has demystified the GDPR a little bit and made it a little less scary.