SQL Server Always On Availability Groups är Microsofts senaste teknik för att tillgodose behoven för hög tillgänglighet och katastrofåterställning hos organisationer som använder SQL Server. En stor fördel med AlwaysOn är möjligheten att adressera både HA och DR i en implementering. Vi upplevde följande viktiga fördelar med AlwaysOn:
Vi kan gruppera relaterade databaser som en del av en enskild tillgänglighetsgrupp och ha dem failover tillsammans om detta skulle behövas. Detta är särskilt användbart för program som är beroende av mer än en databas, som Microsoft Office SharePoint, Microsoft Lync och Sage.
Jämfört med SQL Server Failover Cluster Instances, finner vi att lagring som en enda felpunkt har eliminerats sedan varje instans som utgör en replik tilldelas ett eget lager.
Med AlwaysOn är det möjligt att konfigurera HA och DR samtidigt. Detta uppnås genom att skapa ett Windows Failover-kluster på flera platser som grunden för din AlwaysOn-konfiguration. Att utföra ett rollbyte när du använder AlwaysOn är betydligt enklare än att göra det när du använder Transaction Log Shipping.
Datorobjekt
Active Directory (AD) är ett stort ämne och vi kommer inte att fördjupa oss i detaljerna i den här artikeln. Som du kan gissa är Active Directory Microsofts katalogtjänst. I termer av datanätverk är en katalogtjänst en anläggning som låter oss registrera, identifiera och hantera alla objekt inom ett nätverk centralt. Poster i katalogtjänsterna mappar namnen på nätverksenheter till motsvarande IP-adresser och andra egenskaper i katalogen. De vanligaste objekten i en katalogtjänst (och i Microsofts AD) är användare och datorer. Precis som varje användare på domänen kan registreras och hanteras från Active Directory, kan varje dator på domänen också hanteras från Active Directory. Precis som varje användare förväntas ha ett unikt konto i Active Directory, så har varje dator det.
I Active Directory mappas inte alla datorobjekt till en fysisk dator. Ett datorobjekt kan representera en fysisk dator (arbetsstation eller server) men kan också representera något som fungerar som en dator, till exempel det representativa namnet för ett Windows-kluster eller det virtuella namnet för en klustertjänst (roll). Sådana representationer är också unika i Active Directory precis som vanliga datornamn.
CNO:er och VNO:er i WSFC
När du installerar ett Windows Failover-kluster skapar installationsprogrammet en enhet i Active Directory som kallas ett Computer Name Object (CNO). Denna CNO är den primära enheten som skapas i Active Directory för klustret och representerar "Servernamnet" för hela klustret. Därefter kommer andra objekt som kallas Virtuella namnobjekt skapas av CNO när de utför sådana aktiviteter som att skapa klusterroller, tillgänglighetsgrupper, eller Tillgänglighetsgrupplyssnare . Dessa CNO:er och VNO:er har IP-adresser kopplade till dem. Du kan ange dessa adresser när du installerar klustret eller skapar en ny klusterroll eller en lyssnare. För varje kluster, roll och lyssnare du skapar behöver du ett unikt datornamn och en unik IP-adress. Fig. 1 visar steget under vilket du anger klusternamnsobjektet och dess IP-adress när du konfigurerar ett kluster.
Namnen du använder när du konfigurerar ett kluster är helt godtyckliga. De behöver bara vara unika. Det rekommenderas dock att följa din organisations namnkonventioner för vanliga datorer när du skapar CNO:er eller VNO:er – detta hjälper till att hålla hanteringen enklare. Det är också vettigt att använda ett specifikt block med IP-adresser som täcker alla adresseringsbehov för hela ditt kluster – CNO:n och alla VNO:er (roller) du tänker skapa.
Fig. 1 Namn på adressmapping i ett kluster
Nyckeldomänbehörigheter
DBA eller systemadministratör som utför en klusterinstallation måste ha behörighet att Skapa datorobjekt i Active Directory-domänen. I sin tur, efter att ha skapat datornamnsobjektet, måste domänadministratören ge följande behörigheter till datornamnsobjektet så att roller (som resulterar i virtuella namnobjekt) framgångsrikt kan skapas i klustret:
Skapa datorobjekt
Läs alla egenskaper
Utan dessa behörigheter kommer du sannolikt att få felmeddelanden som liknar det nedan när du försöker skapa en roll (i fallet med AlwaysOn FCI ) eller en lyssnare (i fallet AlwaysOn AG ):
Fel under installationen av MS SQL Server Cluster:
Klusternätverksnamnresurs 'SQL Network Name (EUK-SCCM-01)' kunde inte skapa sitt associerade datorobjekt i domänen 'domainname.com' av följande anledning:Det gick inte att skapa datorkonto.
Texten för den associerade felkoden är:Åtkomst nekad.
Det här felmeddelandet observeras i Event Viewer eftersom SQL Server inte skulle vara tillgänglig för närvarande. Du kommer också att kunna se detta om du navigerar till SQL-felloggfilerna i LOG-mappen som finns i SQL Servers installationskatalog. Nyckelfrasen är "Åtkomst nekas ”.
Övriga krav
Jag bör nämna konceptet med en domänkontrollant. En domänkontrollant, eller mer exakt, en uppsättning domänkontrollanter tillhandahåller nyckeltjänster för Active Directory som att registrera objekt och autentisera användare och datorer. För att framgångsrikt kunna konfigurera ett kluster eller en AlwaysOn Listener måste en domänkontrollant vara tillgänglig från den dator där du utför konfigurationen. Detta innebär att kommunikation från datorn till domänkontrollanten måste öppnas på en rad TCP- och UDP-portar. Microsoft dokumenterar detta mycket detaljerat i den här artikeln . Detta kan vara givet i de flesta fall, men när du felsöker anslutningsproblem hjälper det att veta vad som faktiskt behövs.
I en tidigare artikel , jag nämnde också att det är nödvändigt att ge behörigheter till CNO för ett kluster när du konfigurerar ett fildelningskvorum.
Fig. 2 behörigheter för en fildelning
En anteckning om namnupplösning
Att vara datorobjekt, CNO:er och VNO:er är beroende av Domain Name Service för att lösa namnet som anges när du installerar klustret, skapar en roll eller skapar en AlwaysOn Listener. Vanligtvis ges klienter dessa datornamn för att upprätta en anslutning till klustret. Med andra ord är IP-adressen transparent för dem, vilket gör klientkonfigurationen enkel och abstraherar failovers från slutanvändarna.
Fig. 3 AG Listener-egenskaper för lyssnare med två IP-adresser
I en tidigare artikel nämnde jag ett fall där detta scenario kan orsaka problem. I vårt multi-site kluster hade vi en lyssnare för vår AlwaysOn Availability Group. Den här avlyssnaren konfigurerades för att lösa till två IP-adresser. Detta är nödvändigt för ett multi-site kluster som spänner över flera undernät. I en sådan konfiguration kommer namnservern att returnera båda IP-adresserna som är mappade till lyssnaren när en nslookup utfärdas kontrollera (se fig. 4). Men när du ansluter kan du bara komma åt en av dessa IP-adresser åt gången. Cluster Manager kommer att visa den andra IP-adressen som Offline (se fig. 5).
Fig. 4 AG Listener-egenskaper för lyssnare med två IP-adresser
Fig. 5 egenskaper för klusterroll med två IP-adresser i separata undernät
Detta är normalt. Om det finns en failover till den alternativa platsen, börjar DNS-servern lösa den alternativa IP-adressen efter några minuter. Innebörden av detta är att kundernas kommunikation med den alternativa platsen måste vara möjlig. Fig. 6 och Fig. 7 belyser detta ytterligare.
Fig. 6 Kommunikationsväg med primär replika i Dakar
Låt oss ta en ordentlig titt på vägen som paketen kommer att passera från klientdatorerna till klustret. När den primära repliken är i Dakar, löses lyssnarnamnet SQL-SVR-LNR till IP-adressen 192.168.1.20 och WFCS i sin tur riktar begäran till servern 192.168.1.22 (observera att denna server också har sin egen datornamn). I händelse av en failover till Nairobi har vi kommunikationsvägen som går genom 192.168.2.20 och sedan till 192.168.2.22. Innebörden är att för en sömlös kundupplevelse måste alla klienter i alla datacenter ha kommunikation tillåten på alla inblandade brandväggar som använder port 1433.
Fig. 7 Kommunikationsväg med primär replika i Nairobi
Slutsats
Medan Windows Failover Clustering, Active Directory och Domain Name Service kan ligga utanför rollen som databasadministratör, lönar det sig att ha en grundläggande förståelse för hur dessa tekniker fungerar för att kunna bygga och felsöka AlwaysOn Failover-klusterinstanser och AlwaysOn-tillgänglighetsgrupper. Vissa organisationer har en strikt åtskillnad av uppgifter mellan systemadministratörer och databasadministratörer, men där så inte är fallet måste databasadministratören kunna linda huvudet kring dessa Windows-koncept för att lyckas som DBA.
Referenser
Översikt över AlwaysOn-tillgänglighetsgrupper
Windows-failover-klustring med SQL Server
Tjänsteöversikt och nätverksportkrav för Windows
Administrera datorobjekt