• Articles
• admin

9. juli 2019 avsluttes støtte FOR SQL Server 2008 Og 2008 R2. Det betyr slutten på vanlige sikkerhetsoppdateringer. Men hvis DU flytter DISSE SQL Server-forekomstene Til Azure Eller Azure Stack (jeg vil bare referere til Begge Som Azure for resten av veiledningen), Vil Microsoft gi deg tre års Utvidede Sikkerhetsoppdateringer uten ekstra kostnad. HVIS DU kjører SQL Server 2008/2008 R2 og du ikke kan oppdatere til en senere versjon AV SQL Server før fristen 9. juli, vil du dra nytte av dette tilbudet i stedet for å kjøre risikoen for å møte et fremtidig sikkerhetsproblem. En ikke oppdatert FOREKOMST AV SQL Server kan føre til tap av data, nedetid eller et ødeleggende datainnbrudd.

en av utfordringene du vil møte når DU kjører SQL Server 2008/2008 R2 I Azure, er å sikre høy tilgjengelighet. På stedet kan du kjøre EN FOREKOMST AV SQL Server Failover Cluster (FCI) for høy tilgjengelighet, eller kanskje du kjører SQL Server i en virtuell maskin og er avhengig Av VMware HA eller En Hyper-V-klynge for tilgjengelighet. Når Du flytter Til Azure, er ingen av disse alternativene tilgjengelige. Nedetid I Azure er en veldig reell mulighet for at du må ta skritt for å redusere.

for å redusere muligheten for nedetid og kvalifisere For Azures 99,95% eller 99.99% SLA, du ma utnytte SIOS DataKeeper. DataKeeper overvinner Azures mangel på delt lagring og lar deg bygge EN SQL Server FCI I Azure som utnytter lokalt tilkoblet lagring på hver forekomst. SIOS DataKeeper støtter IKKE BARE SQL Server 2008 R2 Og Windows Server 2008 R2 som dokumentert i denne veiledningen, den støtter alle versjoner Av Windows Server, fra 2008 R2 Til Windows Server 2019 og alle versjoner AV SQL Server fra SQL Server 2008 til SQL Server 2019.

denne veiledningen vil gå gjennom prosessen med å opprette EN to-node SQL Server 2008 R2 Failover Cluster Instance (Fci) I Azure, som kjører På Windows Server 2008 R2. SELV OM SIOS DataKeeper også støtter klynger som spenner Over Tilgjengelighetssoner eller Områder, antar denne veiledningen at hver node ligger i Samme Azure-Region, men forskjellige Feildomener. SIOS DataKeeper vil bli brukt i stedet for den delte lagringen som normalt kreves for å opprette EN SQL Server 2008 R2 FCI.

Forutsetninger

Active Directory
denne veiledningen forutsetter at Du har et Eksisterende Active Directory-Domene. Du kan administrere Dine Egne Domenekontrollere eller bruke Azure Active Directory Domain Services. For denne opplæringen vil vi koble til et domene som heter contoso.lokalt. Selvfølgelig vil du koble til ditt eget domene når du følger denne opplæringen.

Åpne Brannmurporter
– SQL Server:1433 For Standardforekomst
– Belastningsfordeling Helseprobe: 59999
– DataKeeper: disse brannmurreglene legges automatisk til I windows-vertsbasert brannmur under installasjonen. For detaljer om hvilke porter som åpnes, se SIOS-dokumentasjonen.
– Husk at hvis du har nettverksbasert sikkerhet på plass som blokkerer porter mellom klyngenodene, må du også ta hensyn til disse portene der.

DataKeeper-Tjenestekonto
Opprett En Domenekonto. Vi vil spesifisere denne kontoen når Vi installerer DataKeeper. Denne kontoen må legges Til Den Lokale Administratorgruppen på hver node i klyngen.

Opprett den første SQL Server-Forekomsten I Azure

denne veiledningen vil utnytte SQL Server 2008R2SP3 På Windows Server 2008R2-bildet som er publisert I Azure Marketplace.

Når du klargjør den første forekomsten, må du opprette et Nytt Tilgjengelighetssett. Under denne prosessen må du sørge for å øke antall Feildomener til 3. Dette gjør at de to klyngenodene og fildelingsvitnet hver kan ligge i sitt Eget Feildomene.

hvis du ikke allerede har konfigurert et virtuelt nettverk, kan du la veiviseren for oppretting opprette et nytt for deg.

Når forekomsten er opprettet, gå INN I IP-konfigurasjonene og gjør Den Private IP-adressen statisk. Dette kreves FOR SIOS DataKeeper og er beste praksis for grupperte forekomster.

Kontroller at det virtuelle nettverket er konfigurert til å angi AT DNS-serveren skal være en lokal windows AD-kontroller for å sikre at du kan bli med i domenet i et senere trinn.

når de virtuelle maskinene er klargjort, legger du til minst to ekstra disker i hver forekomst. Premium ELLER Ultra SSD anbefales. Deaktiver caching på diskene som brukes FOR SQL-loggfilene. Aktiver skrivebeskyttet bufring på disken som brukes FOR SQL-datafilene. Se Ytelsesretningslinjer FOR SQL Server I Azure Virtual Machines for mer informasjon om beste praksis for lagring.

Opprett DEN 2. SQL Server-Forekomsten I Azure

Følg de samme trinnene som ovenfor, bortsett fra at du må plassere denne forekomsten i samme virtuelle nettverk Og Tilgjengelighetssett som du opprettet med 1. forekomst.

Opprett En Fsw-Forekomst (File Share Witness)

For At Windows Server Failover-Klyngen (WSFC) skal fungere optimalt, må du opprette en Annen Windows Server-forekomst og plassere den i Samme Tilgjengelighetssett som SQL Server-forekomstene. Ved å plassere den i Samme Tilgjengelighetssett sikrer du at hver klyngenode og FSW ligger i forskjellige Feildomener, slik at klyngen forblir på linje hvis et helt Feildomene går av linje. Dette tilfeller krever IKKE SQL Server, kan det være en enkel Windows Server som alt den trenger å gjøre er vert for en enkel fildeling.

denne forekomsten vil være vert for fildelingsvitnet som kreves AV WSFC. Denne forekomsten trenger ikke å være av samme størrelse, og det krever heller ingen ekstra disker som skal festes. Det eneste formålet er å være vert for en enkel fildeling. Det kan faktisk brukes til andre formål. I mitt laboratoriemiljø ER MIN FSW også min domenekontroller.

Avinstaller SQL Server 2008 R2

HVER AV DE to SQL Server-forekomstene som er klargjort, har ALLEREDE SQL Server 2008 R2 installert på dem. De er imidlertid installert som frittstående SQL Server-forekomster, ikke grupperte forekomster. SQL Server må avinstalleres fra hver av disse forekomstene før vi kan installere cluster-forekomsten. Den enkleste måten å gjøre det på er å kjøre SQL-Oppsettet som vist nedenfor.

når du kjører oppsett.exe / Action-RunDiscovery du vil se alt som er forhåndsinstallert

setup.exe /Action=RunDiscovery

Kjører oppsett.exe / Action=Avinstaller /FEATURES=SQL,AS,RS,IS,Tools /INSTANCENAME = MSSQLSERVER starter avinstalleringsprosessen

setup.exe /Action=Uninstall /FEATURES=SQL,AS,RS,IS,Tools /INSTANCENAME=MSSQLSERVER

Kjører oppsett.exe / Action-RunDiscovery bekrefter avinstallasjonen fullført

setup.exe /Action-RunDiscovery

Kjør denne avinstalleringsprosessen på nytt i 2. instans.

Legg til forekomster I Domenet

Alle tre av disse forekomstene må legges til Et Windows-Domene. Som nevnt i Delen Forutsetninger, må du ha tilgang til å bli med i en eksisterende Windows Active Directory. I vårt tilfelle blir vi med i et domene som heter contoso.lokalt.

Legg Til Windows Failover Clustering Feature

Failover Clustering-Funksjonen må legges til DE to SQL Server-forekomstene

Add-WindowsFeature Failover-Clustering

Samleoppdatering For Windows Server 2008 R2 SP1

det er en kritisk oppdatering (kb2854082)som kreves for å konfigurere En Forekomst Av Windows Server 2008 R2 I Azure. Denne oppdateringen og mange flere er inkludert i Samleoppdateringen Praktisk For Windows Server 2008 R2 SP1. Installer denne oppdateringen på hver AV DE TO SQL Server-forekomstene.

Format Lagring

flere disker som ble koblet da DE to SQL Server-forekomstene ble klargjort må formateres. Gjør følgende for hvert volum på hver forekomst.

Microsoft best practices sier følgende…

» NTFS-tildelingsenhetsstørrelse: Når du formaterer datadisken, anbefales det at du bruker en 64 KB tildelingsenhet størrelse for data og loggfiler Samt TempDB.»

Kjør Klyngevalidering

Kjør klyngevalidering for å sikre at alt er klart for gruppering.

Import-Module FailoverClustersTest-Cluster -Node "SQL1", "SQL2"

rapporten inneholder ADVARSLER om Lagring og Nettverk. Du kan ignorere disse advarslene som vi vet det er ingen delte disker og bare en enkelt nettverkstilkobling eksisterer mellom serverne. Du kan også motta en advarsel om nettverksbindingsordre som også kan ignoreres. Hvis DET oppstår FEIL, må du adressere DEM før du fortsetter.

Feil ved å prøve å kjøre Klyngevalidering?

jeg har oppdaget denne feilen ved noen anledninger, og jeg prøver fortsatt å sortere ut under hvilke forhold dette skjer. Av og til vil du finne at test-klyngen ikke klarer å kjøre som beskrevet i forumposten.

Test-ClusterUnable to Validate a Cluster Configuration. The operation has failed. The action validate a configuration did not completeThere is an error in XML document (5, 73). Attempt by methodMicrosoft.Xml.Serialzation.GeneratedAssembly.XmlSerialzationReaderClusterPrep.Config.Read4_As...Bolean) to access methodMS.Internal.ServerClusters.Validation.TestAssemblyCollection.Add(MS.Internal.ServerClusters.V....Failed

hvis dette skjer med deg, har jeg funnet følgende løsning anbefalt i forumposten fungerer for meg.

Inside C:\Windows\System32\WindowsPowerShell\v1.0 make a copy of powershell_ise.exe.config file (make a copy inside C:\Windows\System32\WindowsPowerShell\v1.0)- rename it to powershell.exe.configOpen it with notepad- delete current config line and paste:<?xml version="1.0" encoding="utf-8" ?><configuration> <system.xml.serialization> <xmlSerializer useLegacySerializerGeneration="true"/> </system.xml.serialization></configuration>- save and run test-cluster

mens denne løsningen vil tillate deg å kjøre test-cluster Fra Powershell, har jeg funnet ut at kjører Validere GJENNOM GUI fortsatt kaster en feil, selv med denne løsningen. Jeg har en spørring I Microsoft for Å se om De har en løsning, men for nå hvis du trenger å kjøre klyngevalidering, må Du kanskje bruke Test-Cluster I Powershell.

Opprett Klyngen

Beste praksis for å opprette en klynge I Azure ville være å bruke Powershell til å opprette en klynge, og angi en statisk IP-adresse. Powershell tillater oss å angi En Statisk IP-Adresse, MENS GUI-metoden ikke gjør det. Dessverre Fungerer Azures implementering AV DHCP ikke bra med WSFC, så hvis DU bruker GUI-metoden, vil du ende opp med en duplikat IP-adresse som Cluster IP-Adressen som må løses før klyngen er brukbar.

men det jeg har funnet er at den typiske New-Cluster powershell-kommandoen med-StaticAddress-kommandoen ikke virker. For å unngå problemet med den dupliserte IP-adressen, må vi ty til klyngen.exe verktøyet og kjøre følgende kommando.

cluster /cluster:cluster1 /create /nodes:"sql1 sql2" /ipaddress:10.0.0.100/255.255.255.0

Legg Til Fildelingsvitnet

Neste må vi legge Til Fildelingsvitnet. På 3. server vi klargjort SOM FSW, opprett en mappe og del den som vist nedenfor. Du må gi cluster Name Object (Cno) lese – /skrivetillatelser på Både Delings-og Sikkerhetsnivåene som vist nedenfor.

når delingen er opprettet, kjører Du Veiviseren Konfigurer Klyngekvorum på en av klyngenodene og følger trinnene som er vist nedenfor.

Installer DataKeeper

Installer DataKeeper på hver AV DE TO SQL Server-klyngenodene som vist nedenfor.

Det er her Vi vil spesifisere Domenekontoen vi la til i hver av de lokale Domeneadministratorgruppene.

Konfigurer DataKeeper

Når DataKeeper er installert på hver av de to klyngenodene, er Du klar til å konfigurere DataKeeper.

MERK-den vanligste feilen som oppstår i de følgende trinnene, er sikkerhetsrelatert, oftest ved at Eksisterende Azure-sikkerhetsgrupper blokkerer nødvendige porter. Vennligst se SIOS-dokumentasjonen for å sikre at serverne kan kommunisere over de nødvendige portene.

først må du koble til hver av de to nodene.

hvis alt er riktig konfigurert, bør du da se følgende i Serveroversiktsrapporten.

deretter oppretter Du En Ny Jobb og følger trinnene som er illustrert nedenfor

Velg Ja her for å registrere Ressursen DataKeeper Volum I Tilgjengelig Lagring

Fullfør trinnene ovenfor for hvert av volumene. Når DU er ferdig, bør du se følgende I WSFC UI.

DU er nå klar til å installere SQL Server i klyngen.

MERK – på dette tidspunktet er det replikerte volumet bare tilgjengelig på noden som for øyeblikket er vert For Tilgjengelig Lagringsplass. Det er forventet, så ikke bekymre deg!

Installer SQL Server på den første noden

hvis du vil skript installasjonen, har jeg tatt med eksemplet nedenfor av en skriptklyngeinstallasjon AV SQL Server 2008 R2 i den første noden i klyngen. Skriptet for å legge til en node i eksisterende klynge er funnet lenger ned i guiden.

selvfølgelig justere for miljøet.

c:\SQLServerFull\setup.exe /q /ACTION=InstallFailoverCluster /FEATURES=SQL /INSTANCENAME="MSSQLSERVER" /INSTANCEDIR="C:\Program Files\Microsoft SQL Server" /INSTALLSHAREDDIR="C:\Program Files\Microsoft SQL Server" /SQLSVCACCOUNT="contoso\admin" /SQLSVCPASSWORD="xxxxxxxxx" /AGTSVCACCOUNT="contoso\admin" /AGTSVCPASSWORD="xxxxxxxxx" /SQLDOMAINGROUP="contoso\SQLAdmins" /AGTDOMAINGROUP="contoso\SQLAdmins" /SQLCOLLATION="SQL_Latin1_General_CP1_CI_AS" /FAILOVERCLUSTERGROUP="SQL Server 2008 R2 Group" /FAILOVERCLUSTERDISKS="DataKeeper Volume E" "DataKeeper Volume F" /FAILOVERCLUSTERIPADDRESSES="IPv4;10.0.0.101;Cluster Network 1;255.255.255.0" /FAILOVERCLUSTERNETWORKNAME="SQL2008Cluster" /SQLSYSADMINACCOUNTS="contoso\admin" /SQLUSERDBLOGDIR="E:\MSSQL10.MSSQLSERVER\MSSQL\Log" /SQLTEMPDBLOGDIR="F:\MSSQL10.MSSQLSERVER\MSSQL\Log" /INSTALLSQLDATADIR="F:\MSSQL10.MSSQLSERVER\MSSQLSERVER" /IAcceptSQLServerLicenseTerms

hvis du foretrekker Å bruke GUI, bare følg med skjermbildene nedenfor.

kjør SQL Server-oppsettet på DEN første noden.

Velg Ny SQL Server Failover Cluster Installasjon og følg trinnene som illustrert.

Velg bare alternativene du trenger.

vær oppmerksom på at dette dokumentet antar At Du bruker Standardforekomsten AV SQL Server. Hvis Du bruker En Navngitt Forekomst, må du sørge for at du låser ned porten som den lytter på, og bruker den porten senere når du konfigurerer lastbalanseren. Du må også opprette en belastningsfordelingsregel FOR SQL Server Browser Service (UDP 1434) for å koble til En Navngitt Forekomst. Ingen av disse to kravene er dekket i denne veiledningen, men hvis du trenger En Navngitt Forekomst, vil det fungere hvis du gjør disse to ekstra trinnene.

Her må du angi en ubrukt IP-adresse

Gå til Kategorien Datakataloger og flytt data og loggfiler. På slutten av denne veiledningen snakker vi om å flytte tempdb til et Ikke-speilet DataKeeper-Volum for optimal ytelse. For nå, bare hold den på en av de klyngede diskene.

Installer SQL Server på den andre noden

Nedenfor Er et eksempel på kommandoen du kan kjøre for å legge til EN EKSTRA SQL Server 2008 r2-node i en eksisterende klynge.

c:\SQLServerFull\setup.exe /q /ACTION=AddNode /INSTANCENAME="MSSQLSERVER" /SQLSVCACCOUNT="contoso\admin" /SQLSVCPASSWORD="xxxxxxxxx" /AGTSVCACCOUNT="contoso\admin" /AGTSVCPASSWORD="xxxxxxxx" /IAcceptSQLServerLicenseTerms

hvis du foretrekker Å bruke GUI, følg med følgende skjermbilder.

Kjør SQL Server-oppsettet på nytt på den andre noden, og velg Legg til node i EN SQL Server Failover-Klynge.

Congratulations, du er nesten ferdig! På Grunn Av Azures manglende støtte FOR gratuitous ARP, må Vi imidlertid konfigurere En Intern Belastningsfordeling (ILB) for å hjelpe med klientomadressering som vist i følgende trinn.

Oppdater SQL-Klyngen IP-Adresse

FOR AT ILB skal fungere riktig, må du kjøre kjør følgende kommando fra en av klyngenodene. DET SQL Cluster IP gjør AT SQL Cluster IP-adressen til å svare PÅ ILB helse probe mens også sette nettverksmasken til 255.255.255.255 for å unngå IP-adresse konflikter med helse probe.

cluster res <IPResourceName> /priv enabledhcp=0 address=<ILBIP> probeport=59999 subnetmask=255.255.255.255

MERK – jeg vet ikke om det er en fluke, men noen ganger har jeg kjørt denne kommandoen, og det ser ut som det går – men det fullfører ikke jobben, og jeg må kjøre den igjen. Måten jeg kan fortelle om det fungerte, er ved å se På Nettverksmasken til SQL Server IP-Ressursen, hvis den ikke er 255.255.255.255, vet du at den ikke kjørte vellykket. Det kan enkelt være ET GUI-oppdateringsproblem, så du kan også prøve å starte cluster GUI for å bekrefte at nettverksmasken ble oppdatert.

når den kjører, tar du ressursen frakoblet og kobler den til igjen for at endringene skal tre i kraft.

Opprett Lastbalanseren

det siste trinnet er å opprette lastbalanseren. I dette tilfellet antar vi at Du kjører Standard Forekomst AV SQL Server, lytter på port 1433.

Den Private IP-Adressen du definerer når du Oppretter belastningsfordeling, er nøyaktig samme adresse SOM SQL Server FCI bruker.

Legg til bare DE to SQL Server-forekomstene i backend-utvalget. Ikke legg TIL FSW til backend-bassenget.

i denne lastbalanseringsregelen må Du aktivere Flytende IP

Valider Klyngen

før du fortsetter, kan du kjøre klyngevalidering en gang til. Klyngevalideringsrapporten skal returnere de samme nettverks-og lagringsadvarslene som den gjorde første gang du kjørte den. Forutsatt at det ikke er noen nye feil eller advarsler, er klyngen riktig konfigurert.

Rediger sqlserv.exe Config Fil

i katalogen C:\Program Filer (x86)\Microsoft SQL Server \ 100 \ Tools \ Binn vi opprettet en sqlps.exe.config file og sqlservr.exe.config med følgende linjer i config-filen:

<configuration> <startup> <supportedRuntime version="v2.0.50727"/> </startup></configuration>

disse filene, som standard, vil ikke eksistere og kan opprettes. Hvis denne filen(e) allerede finnes for installasjonen, må <supportedRuntime version= «v2. 0.50727» />-linjen bare plasseres med<oppstart>…</oppstart > – delen av<konfigurasjon>…< / konfigurasjon > – delen. Dette bør gjøres på begge serverne.

Test Klyngen

den enkleste testen er å åpne SQL Server Management Studio på den passive noden og koble til klyngen. Hvis du er i stand til å koble til, gratulerer, gjorde du alt riktig! Hvis du ikke kan koble ikke frykt, ville du ikke være den første personen til å gjøre en feil. Jeg skrev en blogg artikkel for å feilsøke problemet. Administrere klyngen er nøyaktig det samme som å administrere en tradisjonell delt lagringsklynge. Alt styres gjennom Failover Cluster Manager.

Valgfritt-Flytt Tempdb

for optimal ytelse vil det være tilrådelig å flytte tempdb til den lokale, ikke-replikerte SSD-EN. SQL Server 2008 R2 krever imidlertid tempdb å være på en gruppert disk. SIOS har en løsning kalt En Ikke-Speilet Volumressurs som løser dette problemet. Det ville være tilrådelig å lage en ikke-speilet volumressurs av den lokale SSD-stasjonen og flytte tempdb der. Den lokale SSD-stasjonen er imidlertid ikke vedvarende, så du må passe på at mappen som holder tempdb og tillatelsene på den mappen, gjenopprettes hver gang serveren starter på nytt.