Friday, March 8, 2019

Series 9 - Build SSAS 2019 on a quad-node Windows 2019 cluster

In my previous series of failover clusters, I wrote about building SQL Server 2017 on Windows 2012/2016  Hyper-V virtual machines, with Windows iSCSI or StarWind virtual SAN as shared storage. It is the year of 2019 now and our cluster series need a face lift. With recent release of Windows Server 2019 and SQL Server 2019 CTP, I'm experimenting with these bleeding edge technologies and logging an update in the series. It is a single post with all-in-one contents since a large portion of it are duplicate of past posts. I'll try to avoid redundant steps but focus on new feature/interfaces or something worth an emphasis.

I'm using the same hardware as described in Series 1. Software includes Windows Server 2019 Datacenter Eval. and SQL Server 2019 CTP 2.3. Let's first lay down a chart that contains critical info for the environment we're building. In the following table, all nodes specs are listed for reference. 


Server  Name
P or V
Public NIC
Heartbeat NIC
iSCSI NIC
Purpose
Drives
HPV-HOST
HP
PL 360
IP: 192.168.1.123
For vEthernet
N/A
DC
C:\ 136 GB (OS)
SM: 255.255.255.0
DNS
D:\ 136 GB (Node 1)
DG: 192.168.1.1
Hyper-V host
E:\ 136 GB (Node 2)
DNS: 71.243.0.12
iSCSI target
F:\ 136 GB (Node 3)
DNS: 71.250.0.12

G:\256 GB (Node 4)
DNS: 192.168.1.123

    - USB
PARADISE
CLUSTER
DNS
192.168.1.136
N/A
N/A
Windows cluster name

PARADISE
SQLFCI
DNS
192.168.1.137
N/A
N/A
SQL Server FCI cluster name

MSDTC
DNS
192.168.1.138
N/A
N/A
Distributed Transaction

FCIVM01
Vm
IP: 192.168.1.144
IP: 10.10.10.44
IP: 8.8.8.4
SQL 2019
C:\ 40 GB
SM: 255.255.255.0
SM: 255.0.0.0
SM: 255.0.0.0
SSIS/SSRS
DG: 192.168.1.1
DG: N/A
DG: N/A
MDS/DQS
DNS: 192.168.1.123
DNS: N/A
DNS: N/A
SSAS
FCIVM02
Vm
IP: 192.168.1.145
IP: 10.10.10.45
IP: 8.8.8.5
SQL 2019
C:\ 50 GB
SM: 255.255.255.0
SM: 255.0.0.0
SM: 255.0.0.0
SSIS/SSRS
DG: 192.168.1.1
DG: N/A
DG: N/A
MDS/DQS
DNS: 192.168.1.123
DNS: N/A
DNS: N/A
SSAS
FCIVM03
Vm
IP: 192.168.1.146
IP: 10.10.10.46
IP: 8.8.8.6
SQL 2019
C:\ 50 GB
SM: 255.255.255.0
SM: 255.0.0.0
SM: 255.0.0.0
SSIS/SSRS
DG: 192.168.1.1
DG: N/A
DG: N/A
MDS/DQS
DNS: 192.168.1.123
DNS: N/A
DNS: N/A
SSAS
FCIVM04
Vm
IP: 192.168.1.147
IP: 10.10.10.47
IP: 8.8.8.7
SQL 2019
C:\ 50 GB
SM: 255.255.255.0
SM: 255.0.0.0
SM: 255.0.0.0
SSIS/SSRS
DG: 192.168.1.1
DG: N/A
DG: N/A
MDS/DQS
DNS: 192.168.1.123
DNS: N/A
DNS: N/A
SSAS


Part 1 - Hyper-V host and virtual machines


Download and install Windows 2019 with GUI. There's not much difference in the installation phase compared to Windows 2016 or 2012. Be sure to set up networking per the chart (top row). In Server Manager add roles and features: Domain controller, DNS server, Hyper-V and iSCSI target server. 



In Hyper-V Manager, the only thing to configure is virtual switch. Create three virtual switches for external, internal and private respectively. You can see in the following screenshot, my physical QLogic Gig bit ethernet card has been mapped to an external virtual switch. I also created a private Heartbeat virtual switch and an internal iSCSI virtual switch. Here is a summary of three types of virtual switches:

External - Allows host to talk to Internet as well as cluster nodes. A default gateway and subnet mask are must.
Internal - Allow talks among cluster nodes and between cluster nodes and Hyper-V host. No talk to Internet. Only a subnet mask is needed.
Private - Only allow talks among cluster nodes. No talks to host or to Internet. Only a subnet mask is needed.




For virtual machine setting, we also want to add three virtual NICs: public for application connection, private for heartbeat communication and iSCSI to talk to storage target server. Also make sure 2 CPUs, 4 GB of RAM and 40 GB of disk space is allocated for each vm. Then mount Windows 2019 ISO image to start installation. In Series 7 I wrote about how to use sysprep to clone a Hyper-V virtual machine. Here I'm going to follow suite to create four VMs as shown below, using FCIVM01 as template then cloning FCIVM02, FCIVM03, and FCIVM04


Part 2 - Configure iSCSI shared storageSince we have added iSCSI target on the host server now we can start creating virtual disks that nodes can share. The steps are pretty much the same as Windows 2017 described in Series 8. 

Part 3 - Install Windows 2019 failover cluster

Building Windows cluster was outlined as in Series 3, albeit we're using Windows 2019 instead of 2016, and running on four nodes instead of three. In order to get a all-green validation report which i prefer, we need to manually run Windows updates on all nodes to make sure they're consistent. This may require rebooting VMs a few times. It may also require to manually put shared offline disks online.


With cluster name and IP address it is pretty quick to set up a cluster. Once done we can create a fake role to test failover. Right click on Roles in FCM then choose "Create Empty Role". A new role is now added. You can right click on it to move to Best possible node or to a node of your choice. 


Part 4 - Install SQL/SSAS 2019 on Windows cluster 2019



On March 1st Microsoft released SQL Server 2019 CTP 2.3. Follow this link to download the 180-day trial: 
https://www.microsoft.com/en-us/evalcenter/evaluate-sql-server-2019-ctp The downloaded primer executable is about 4 MB. Double click it to launch a real window in which you can choose "Basic" to install SQL Server with default, "Custom" to review/change each detailed installation windows, or "Download media" to just download ISO or CAB file without installation.

We choose the last option to download the .iso image file (about 1.35 GB). On FCIVM01, mount the iso file to DVD drive. Click on setup.exe. When SQL Server Installation Center (SSIC) is opened, choose "New SQL Server failover cluster installation" on the right side. Accept license terms.Note the cluster verification step generated a warning. I strongly suggest revisiting the cluster validation report and fix underlying issues. If it's because of  a missing Windows Defender Antivirus definition update you probably can get away with it. Trivial inconsistency like this likely won't cause cluster installation to fail. So we ignore the warning and move on. On Feature Selection page, select all but Machine Learning Services, R, Python, and PolyBase. They tend to bug out causing installation failures. Keep in mind if SQL Server installation failed it will be nasty to clean up the mess. It will require uninstalling SQL server and/or probably destroying the whole cluster as SQL Service resource has been retained in it.Fill in SQL Server virtual network name (VNN).

We choose all cluster disks to install SQL Server. Note disk 4 is quorum so it's not available.


We have already created a DNS record for the VNN. Just type in its IP address. Notice the network was automatically detected and it matches our NIC assignment.


Based on least privilege principle we used dedicated AD user accounts for services. Notice startup types are Manual as it will be controlled by cluster service. 




Configure tempdb directories. Ignore the warning about large log file. 


In SSAS configuration choose Tabular Mode. Use default paths.


The last page is a summary before actual installation kicks off. 



Finally the installation finished. Check to see that SQL Server service now is under cluster role.

Now we need to install DBA tool SQL Server Management Studio 18.0 (preview 7) from the URL below:



Once SSMS is installed open a query windows and you can run at least five different T-SQL statements to retrieve the current cluster node info.


On FCIVM02, 03, 04 repeat installation of SQL Server by clicking on "Add node to a SQL Server failover cluster" in SSIC. Follow the installation steps detailed in Series 4. It's much quicker than installing the initial node. You just need to type in passwords for the service accounts. You can mount the ISO file on all nodes at the same time and do installations in parallel to save time. The end result - a SQL 2019 cluster is built with four nodes. The classic way of checking cluster is to use FCM (Failover Cluster Manager). 


In Windows 2019 a web GUI tool WAC (Windows Admin Center).has been introduced. The funny thing about it is only Google Chrome can open the URL. Microsoft IE or Edge is not supported. You can hit either URLs to access WAC - https://localhost or https://FCIVM01


You pretty much are able to do everything you normally do with FCM (except for creating cluster) in WAC. Plus it integrates other facets in Windows admin including Server Manager, Computer Manager, etc. In the following screenshots I demoed failover SQL Server service from node 4 to node 1.


I can also click on node 3 to delve into its detailed status and specs.


Part 5 - Build, deploy, maintain SSAS 2019 Tabular model on Windows cluster 2019


Now let's restore a copy for sample Data Warehouse backup from Github. Follow the link below to download AdventureWorksDW2017.bak:


To restore the backup, login in PARADISESQLFCI from SSMS and run database restore. Next we need to build a Tabular Model project using SQL Data Tools (SSDT). From the link below choose most recent release to download.


Launch SSDT-Setup-ENU.exe, check all options. Take default to proceed with installation.


Upon completion of SSDT installation, start the tutorial by creating a SSAS solution/project following the link down below:


The tutorial contains detailed tasks we're not covering here. When the Tabular model is built from SSDT we will deploy it to SSAS cluster. Alternatively you can download the sample Tabular model backup from Github and restore to SSAS server. Choose "adventure-works-tabular-model-1200-full-database-backup.zip" from here: 

https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks-analysis-services

There is a 5.5 MB backup file "Adventure Works Internet Sales Database.abf" inside the downloaded zip file. Unzip it and restore from Analysis server. You can do this through either SSMS GUI or XMLA script. 

Finally let's test querying Tabular model while performing a failover of the cluster. In SSMS open up an MDX query window, run the following command:

select 
{[DimProduct].[ModelName].[Model Name]} on columns,
{[DimProduct].[StartDate].[StartDate]} on rows
from [Adventure Works Internet Sales Model];

Move the SQL Server role to another node. Press F5 to run the same query. During seconds of connection interruption, the query may throw an error. But once the role failover completes and resource gets back online again, the query runs successfully and returns four rows of start dates.