• Articles
• admin

pe 9 iulie 2019, se va încheia suportul pentru SQL Server 2008 și 2008 R2. Asta înseamnă sfârșitul actualizărilor regulate de securitate. Cu toate acestea, dacă mutați acele instanțe SQL Server în Azure sau Azure Stack (mă voi referi pur și simplu la ambele ca Azure pentru restul ghidului), Microsoft vă va oferi trei ani de actualizări de securitate extinse fără costuri suplimentare. Dacă rulați în prezent SQL Server 2008/2008 R2 și nu puteți actualiza la o versiune ulterioară a SQL Server înainte de termenul limită din 9 iulie, veți dori să profitați de această ofertă, mai degrabă decât să riscați să vă confruntați cu o viitoare vulnerabilitate de securitate. O instanță unpatched de SQL Server ar putea duce la pierderea de date, nefuncționare sau o încălcare devastatoare a datelor.

una dintre provocările cu care vă veți confrunta atunci când rulați SQL Server 2008/2008 R2 în Azure este asigurarea disponibilității ridicate. Pe premise se poate executa o instanță SQL Server Failover Cluster (FCI) pentru disponibilitate ridicată, sau, eventual, se execută SQL Server într-o mașină virtuală și se bazează pe VMware HA sau un cluster Hyper-V pentru disponibilitate. Când treceți la Azure, niciuna dintre aceste opțiuni nu este disponibilă. Downtime în Azure este o posibilitate foarte reală pe care trebuie să ia măsuri pentru a atenua.

pentru a atenua posibilitatea de nefuncționare și pentru a se califica pentru Azure 99.95% sau 99.99% SLA, trebuie să pârghie Sios DataKeeper. DataKeeper depășește lipsa de stocare partajată a Azure și vă permite să construiți un SQL Server FCI în Azure care utilizează stocarea atașată local pe fiecare instanță. Sios DataKeeper nu numai că acceptă SQL Server 2008 R2 și Windows Server 2008 R2 așa cum este documentat în acest ghid, acceptă orice versiune de Windows Server, din 2008 R2 până în Windows Server 2019 și orice versiune de SQL Server de la SQL Server 2008 până la SQL Server 2019.

acest ghid va parcurge procesul de creare a unei instanțe de cluster SQL Server 2008 R2 cu două noduri (FCI) în Azure, care rulează pe Windows Server 2008 R2. Deși Sios DataKeeper acceptă și clustere care acoperă zone sau regiuni de disponibilitate, acest ghid presupune că fiecare nod se află în aceeași regiune Azure, dar domenii de eroare diferite. Sios DataKeeper va fi utilizat în locul stocării partajate necesare în mod normal pentru a crea un SQL Server 2008 R2 FCI.

Pre-rechizite

Active Directory
acest ghid presupune că aveți un domeniu Active Directory existent. Puteți gestiona propriile controlere de domeniu sau puteți utiliza Serviciile de domeniu Azure Active Directory. Pentru acest tutorial ne vom conecta la un domeniu numit contoso.local. Desigur, vă veți conecta la propriul domeniu atunci când urmați acest tutorial.

deschideți porturile Firewall
– SQL Server:1433 pentru instanța implicită
– Load Balancer sănătate Probe: 59999
– DataKeeper: aceste reguli firewall sunt adăugate la Windows gazdă firewall bazat automat în timpul instalării. Pentru detalii despre porturile deschise, consultați documentația SIOS.
– rețineți, dacă aveți o securitate bazată pe rețea care blochează porturile dintre nodurile clusterului, va trebui să țineți cont și de aceste porturi acolo.

cont de serviciu DataKeeper
creați un cont de domeniu. Vom specifica acest cont atunci când vom instala DataKeeper. Acest cont va trebui să fie adăugat la grupul administratori locali pe fiecare nod al clusterului.

creați prima instanță SQL Server în Azure

acest ghid va pârghie SQL Server 2008r2sp3 pe Windows Server 2008R2 imagine care este publicat în Azure Marketplace.

când furnizați prima instanță, va trebui să creați un nou set de disponibilitate. În timpul acestui proces, asigurați-vă că creșteți numărul de domenii de eroare la 3. Acest lucru permite ca cele două noduri de cluster și martorul partajat de fișiere să locuiască fiecare în propriul domeniu de eroare.

dacă nu aveți deja configurată o rețea virtuală, permiteți expertului de creare să creeze una nouă pentru dvs.

odată ce instanța este creată, accesați configurațiile IP și faceți adresa IP privată statică. Acest lucru este necesar pentru Sios DataKeeper și este cea mai bună practică pentru instanțele grupate.

asigurați-vă că rețeaua dvs. virtuală este configurată pentru a seta serverul DNS să fie un controler local de anunțuri Windows pentru a vă asigura că veți putea să vă alăturați domeniului într-un pas ulterior.

după ce mașinile virtuale sunt furnizate, adăugați cel puțin două discuri suplimentare la fiecare instanță. Premium sau ultra SSD sunt recomandate. Dezactivați cache-ul pe discurile utilizate pentru fișierele jurnal SQL. Activați cache-ul numai în citire pe discul utilizat pentru fișierele de date SQL. Consultați Ghidul de performanță pentru SQL Server în Azure Virtual Machines pentru informații suplimentare despre cele mai bune practici de stocare.

Creați a 2-a instanță SQL Server în Azure

urmați aceiași pași ca mai sus, cu excepția asigurați-vă că plasați această instanță în aceeași rețea virtuală și set de disponibilitate pe care l-ați creat cu instanța 1.

creați o instanță de partajare de fișiere Witness (FSW)

pentru ca Windows Server Failover Cluster (WSFC) să funcționeze optim, trebuie să creați o altă instanță Windows Server și să o plasați în același set de disponibilitate ca instanțele SQL Server. Plasându-l în același set de disponibilitate, vă asigurați că fiecare nod de cluster și FSW se află în domenii de eroare diferite, asigurându-vă că clusterul dvs. rămâne on-line în cazul în care un întreg domeniu de eroare se dezactivează. Această instanță nu necesită SQL Server, poate fi un Server Windows simplu, deoarece tot ce trebuie să faceți este să găzduiți o partajare simplă de fișiere.

această instanță va găzdui martorul de partajare a fișierelor cerut de WSFC. Această instanță nu trebuie să aibă aceeași dimensiune și nici nu necesită atașarea unor discuri suplimentare. Este doar scopul este de a găzdui o partajare de fișiere simplu. De fapt, poate fi folosit în alte scopuri. În mediul meu de laborator FSW meu este, de asemenea, controlerul meu de domeniu.

dezinstalați SQL Server 2008 R2

fiecare dintre cele două instanțe SQL Server furnizate au deja SQL Server 2008 R2 instalat pe ele. Cu toate acestea, acestea sunt instalate ca instanțe SQL Server independente, nu instanțe grupate. SQL Server trebuie dezinstalat din fiecare dintre aceste instanțe înainte de a putea instala instanța cluster. Cel mai simplu mod de a face acest lucru este să rulați configurarea SQL așa cum se arată mai jos.

când executați configurarea.exe / Action-RunDiscovery veți vedea tot ce este preinstalat

setup.exe /Action=RunDiscovery

rularea de configurare.exe / Action = Dezinstalare / caracteristici = SQL, ca, RS, este, instrumente / INSTANCENAME = MSSQLSERVER începe procesul de dezinstalare

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

rularea de configurare.exe / Action-RunDiscovery confirmă Dezinstalarea finalizată

setup.exe /Action-RunDiscovery

rulați din nou acest proces de dezinstalare în a 2-a instanță.

adăugați instanțe la domeniul

toate aceste trei instanțe vor trebui adăugate la un domeniu Windows. După cum sa menționat în secțiunea Cerințe preliminare, trebuie să aveți acces pentru a vă alătura unui Windows Active Directory existent. În cazul nostru, ne alăturăm unui domeniu numit contoso.local.

Adăugați caracteristica Windows Failover Clustering

caracteristica Failover Clustering trebuie să fie adăugate la cele două instanțe SQL Server

Add-WindowsFeature Failover-Clustering

instalați Convenience Rollup Update pentru Windows Server 2008 R2 SP1

există o actualizare critică ( kb2854082) care este necesară pentru a configura o instanță Windows Server 2008 R2 în Azure. Această actualizare și multe altele sunt incluse în Convenience Rollup Update pentru Windows Server 2008 R2 SP1. Instalați această actualizare pe fiecare dintre cele două instanțe SQL Server.

formatați stocarea

discurile suplimentare care au fost atașate atunci când au fost furnizate cele două instanțe SQL Server trebuie formatate. Faceți următoarele pentru fiecare volum pe fiecare instanță.

cele mai bune practici Microsoft spune următoarele …

” NTFS dimensiunea unității de alocare: Când formatați discul de date, este recomandat să utilizați o dimensiune a unității de alocare de 64 KB pentru fișiere de date și jurnal, precum și TempDB.”

rulați validarea clusterului

rulați validarea clusterului pentru a vă asigura că totul este pregătit pentru a fi pus în cluster.

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

raportul dvs. va conține avertismente despre stocare și rețea. Puteți ignora aceste avertismente, deoarece știm că nu există discuri partajate și există doar o singură conexiune de rețea între servere. De asemenea, este posibil să primiți un avertisment cu privire la ordinea de legare a rețelei, care poate fi, de asemenea, ignorată. Dacă întâmpinați erori, trebuie să le abordați înainte de a continua.

eroare la încercarea de a rula validarea clusterului?

am întâlnit această eroare în câteva ocazii și încă încerc să rezolv în ce condiții se întâmplă acest lucru. Ocazional, veți găsi că test-cluster nu reușește să ruleze așa cum este descris în post pe forum.

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

dacă vi se întâmplă acest lucru, am găsit următoarea remediere recomandată în postarea forumului funcționează pentru mine.

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

în timp ce această remediere vă va permite să rulați test-cluster de la Powershell, am constatat că rularea validare prin GUI aruncă încă o eroare, chiar și cu această remediere. Am o interogare în Microsoft pentru a vedea dacă au o soluție, dar pentru moment, dacă aveți nevoie pentru a rula cluster validare va trebui să utilizați Test-Cluster în Powershell.

crearea clusterului

cele mai bune practici pentru crearea unui cluster în Azure ar fi utilizarea Powershell pentru a crea un cluster, specificând o adresă IP statică. Powershell ne permite să specificăm o adresă IP statică, în timp ce metoda GUI nu. Din păcate, implementarea DHCP de către Azure nu funcționează bine cu WSFC, deci dacă utilizați metoda GUI, veți încheia cu o adresă IP duplicată ca adresă IP a clusterului care va trebui să fie fixată înainte ca clusterul să fie utilizabil.

cu toate acestea, ceea ce am găsit este că comanda tipică powershell New-Cluster cu comanda-StaticAddress nu funcționează. Pentru a evita problema adresei IP duplicate, trebuie să recurgem la cluster.exe utility și executați următoarea comandă.

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

adăugați Martorul de partajare a fișierelor

în continuare trebuie să adăugăm Martorul de partajare a fișierelor. Pe serverul 3rd am furnizat ca FSW, creați un folder și partajați-l așa cum se arată mai jos. Va trebui să acordați permisiunile de citire/scriere a obiectului de nume de Cluster (CNO) atât la nivel de partajare, cât și la nivel de securitate, așa cum se arată mai jos.

după crearea partajării, executați Expertul Configurare cvorum Cluster pe unul dintre nodurile clusterului și urmați pașii ilustrați mai jos.

instalați DataKeeper

instalați DataKeeper pe fiecare dintre cele două noduri de cluster SQL Server așa cum se arată mai jos.

aici vom specifica contul de domeniu pe care l-am adăugat fiecărui grup local de administratori de domeniu.

configurați DataKeeper

odată ce DataKeeper este instalat pe fiecare dintre cele două noduri de cluster, sunteți gata să configurați DataKeeper.

notă – cea mai frecventă eroare întâlnită în pașii următori este legată de securitate, cel mai adesea de grupurile de securitate Azure preexistente care blochează porturile necesare. Vă rugăm să consultați documentația SIOS pentru a vă asigura că serverele pot comunica prin porturile necesare.

mai întâi trebuie să vă conectați la fiecare dintre cele două noduri.

dacă totul este configurat corect, ar trebui să vedeți următoarele în raportul de prezentare generală a serverului.

apoi, creați un nou loc de muncă și urmați pașii ilustrați mai jos

alegeți DA aici pentru a înregistra resursa de volum DataKeeper în spațiul de stocare disponibil

Finalizați pașii de mai sus pentru fiecare dintre volume. După ce ați terminat, ar trebui să vedeți următoarele în interfața de utilizare WSFC.

acum sunteți gata să instalați SQL Server în cluster.

notă – în acest moment volumul replicat este accesibil numai pe nodul care găzduiește în prezent spațiul de stocare disponibil. Acest lucru este de așteptat, așa că nu vă faceți griji!

Instalați SQL Server pe primul nod

dacă doriți să script instalarea, am inclus exemplul de mai jos a unei instalări cluster scriptat de SQL Server 2008 R2 în primul nod de cluster. Scriptul pentru a adăuga un nod la cluster existent se găsește mai jos în ghid.

desigur ajusta pentru mediul dumneavoastră.

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

dacă preferați să utilizați GUI, urmați împreună cu capturile de ecran de mai jos.

pe primul nod, executați configurarea SQL Server.

alegeți noua instalare SQL Server Failover Cluster și urmați pașii așa cum este ilustrat.

alegeți numai opțiunile de care aveți nevoie.

vă rugăm să rețineți, acest document presupune că utilizați instanța implicită de SQL Server. Dacă utilizați o instanță numită, trebuie să vă asigurați că blocați portul pe care îl ascultă și să îl utilizați mai târziu atunci când configurați echilibratorul de încărcare. De asemenea, va trebui să creați o regulă de echilibrare a încărcării pentru serviciul SQL Server Browser (UDP 1434) pentru a vă conecta la o instanță numită. Niciuna dintre aceste două cerințe nu este acoperită în acest ghid, dar dacă aveți nevoie de o instanță numită, aceasta va funcționa dacă faceți acești doi pași suplimentari.

aici va trebui să specificați o adresă IP neutilizată

accesați fila directoare de date și mutați fișierele de date și jurnal. La sfârșitul acestui ghid vorbim despre relocarea tempdb la un volum DataKeeper non-oglindit pentru performanțe optime. Deocamdată, păstrați-l pe unul dintre discurile grupate.

Instalați SQL Server pe al doilea nod

mai jos este un exemplu de comandă puteți rula pentru a adăuga un nod suplimentar SQL Server 2008 R2 într-un cluster existent.

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

dacă preferați să utilizați GUI, urmați împreună cu următoarele capturi de ecran.

rulați din nou configurarea SQL Server pe al doilea nod și alegeți Adăugare nod la un cluster SQL Server Failover.

Congratulations, ești aproape gata! Cu toate acestea, din cauza lipsei de suport Azure pentru ARP gratuit, va trebui să configurăm un Echilibrator de sarcină intern (ILB) pentru a ajuta la redirecționarea clientului, așa cum se arată în pașii următori.

actualizați adresa IP a clusterului SQL

pentru ca ILB să funcționeze corect, trebuie să rulați executați următoarea comandă de la unul dintre nodurile clusterului. Acesta SQL Cluster IP permite adresa IP SQL Cluster pentru a răspunde la sonda de sănătate ILB în timp ce setarea, de asemenea, masca de subrețea la 255.255.255.255 pentru a evita conflictele de adrese IP cu sonda de sănătate.

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

notă – nu știu dacă este o întâmplare, dar ocazional am rulat această comandă și se pare că rulează, dar nu finalizează lucrarea și trebuie să o rulez din nou. Modul în care pot spune dacă a funcționat este uitându-mă la masca de subrețea a resursei IP SQL Server, dacă nu este 255.255.255.255, atunci știți că nu a funcționat cu succes. Acesta poate fi simplu o problemă de reîmprospătare GUI, astfel încât să puteți încerca, de asemenea, repornirea GUI cluster pentru a verifica masca de subrețea a fost actualizat.

după ce rulează cu succes, luați resursa offline și aduceți-o înapoi online pentru ca modificările să aibă efect.

creați Echilibratorul de sarcină

ultimul pas este crearea echilibratorului de sarcină. În acest caz, presupunem că executați instanța implicită a SQL Server, ascultând pe portul 1433.

adresa IP privată pe care o definiți atunci când creați echilibratorul de încărcare va fi exact aceeași adresă pe care o utilizează SQL Server FCI.

adăugați doar cele două instanțe SQL Server la piscina backend. Nu adăugați FSW la piscina backend.

în această regulă de echilibrare a încărcării trebuie să activați IP-ul plutitor

validați Cluster-ul

înainte de a continua, executați validarea cluster-ului încă o dată. Raportul de validare a clusterului ar trebui să returneze aceleași avertismente de rețea și stocare pe care le-a făcut prima dată când l-ați rulat. Presupunând că nu există erori sau avertismente noi, clusterul dvs. este configurat corect.

editare sqlserv.fișier de configurare exe

în director C:\Program fișiere (x86)\Microsoft SQL Server\100\Tools\Binn am creat un sqlps.exe.fișier de configurare și sqlservr.exe.config cu următoarele linii în fișierul de configurare:

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

aceste fișiere, în mod implicit, nu vor exista și pot fi create. Dacă acest fișier(E) există deja pentru instalarea dvs., <supportedRuntime version=”v2.0.50727″/> linia pur și simplu trebuie să fie plasat cu <startup>…</startup> sub-secțiune a <configurare>…</configurare> secțiune. Acest lucru trebuie făcut pe ambele servere.

testați Clusterul

cel mai simplu test este să deschideți SQL Server Management Studio pe nodul pasiv și să vă conectați la cluster. Dacă sunteți în stare să vă conectați, felicitări, ați făcut totul corect! Dacă nu vă puteți conecta, nu vă temeți, nu ați fi prima persoană care face o greșeală. Am scris un articol de blog pentru a ajuta la depanarea problemei. Gestionarea clusterului este exact aceeași cu gestionarea unui cluster de stocare partajat tradițional. Totul este controlat prin Failover Cluster Manager.

opțional – relocați Tempdb

pentru performanțe optime, ar fi recomandabil să mutați tempdb pe SSD-ul local, care nu este reprodus. Cu toate acestea, SQL Server 2008 R2 necesită tempdb să fie pe un disc pus în cluster. SIOS are o soluție numită resursă de volum non-oglindită care abordează această problemă. Ar fi recomandabil să creați o resursă de volum fără oglindă a unității SSD locale și să mutați tempdb acolo. Cu toate acestea, unitatea SSD locală nu este persistentă, deci trebuie să aveți grijă să vă asigurați că folderul deține tempdb și permisiunile din acel folder sunt recreate de fiecare dată când serverul repornește.