SQL Server och SMB-stöd

Från och med SQL Server 2008 R2 har vi ju officiellt stöd för SMB, dvs att låta databasernas data- och logfiler vara adresserade med UNC-sökvägar. T ex:

CREATE DATABASE TestSMB
ON PRIMARY
(
	NAME = 'TestSMB_PRIMARY',
	FILENAME = '\FILESERVERDatabasesTestSM_PRIMARY.mdf',
	SIZE = 100MB,
	FILEGROWTH = 100MB
)
LOG ON
(
	NAME = 'TestSMB_LOG',
	FILENAME = '\FILESERVERDatabasesTestSM_LOG.ldf',
	SIZE = 100MB,
	FILEGROWTH = 100MB
)

UNC-sökvägen måste vara angiven i i korrekt format, dvs \SERVERNAMESHARENAME, och det får inte vara en loopback-sökväg, dvs \LOCALHOST eller \127.0.0.1. Man får heller inte basera sökvägen på administrativa utdelningar, dvs c$, d$ osv, ej heller uppmappade enheter eller övriga UNC-format som \?x:.

Om du har ett Windows Fail-Over Cluster så får inte SQL Server resursen och File Server resursen dela nod. Rekommendationen är att separera SQL Server resursen och File Server resursen på olika Windows Cluster.

Kör du SQL Server 2012 så har du lite olika fördelar beroende på version av Windows Server.

Windows Server 2008, SMB2 protocol version 2.0:

• Bättre prestanda än äldre SMB versioner.
• Bättre stabilitet eftersom protokollet kan hantera smärre, temporära nätverksavbrott

Windows Server 2008 R2, SMB2 protocol version 2.1:

• Stöd för större MTU (Maximum Transmit Unit) vilket underlättar större dataöverföringar som säkerhetskopiering med mera.
• Rejält förbättrad prestanda, speciellt i OLTP scenarion.

Windows Server 2012, SMB2 protocol version 3.0:

• Stöd för transparent failover på fildelningar vilket innebär ingen nertid eller administrativ hantering vid File Server kluster
• Stöd för IO över flera nätverkskort, och förbättrad tolerans vid nätverkskortsfel.
• Stöd för nätverkskort med RDMA (Remote Direct Memory Access)

Det du också behöver ha i åtanke är att tjänstekonton behöver FULL CONTROL både på den utdelade resursen såväl som i filsystemet. Du måste också se till att kontot som används vid installation av SQL Servern har FULL CONTROL om nätverkssökvägar ska anges under installationsfasen. Installationskontot ska även tilldelas SeSecurityPrivilige rättigheten i den lokala säkerhetspolicyn på filservern.

Kända problem är att om du detachar en nätverksansluten databas så kan du få problem med behörigheter i databasen när du återansluter den, samt att SQL Server Failover Cluster Diagnostics Log inte kommer kunna skrivas till nätverksenheten eftersom SQL Server Resource DLL inte har läs- och skricvbehörigheter på fildelningen.