SQL Server Clustering - en introduktion #1
Förord
Om din högt belastade server råkar ut för ett fel i moderbord, hur länge kommer det vara? En timme, fyra timmar, en dag eller kanske ännu längre? Hur mycket kommer det att kosta ditt företag i form av färre försäljningar och sämre produktivitet? Och det kanske för dig viktigaste av allt, hur påverkar det din stressnivå?
Att vara en SQL Server DBA kan vara både krävande och stressigt, speciellt då ditt företags framgång beror på din SQL Servers uptime. Medan vi som DBA har en viss kontroll över din SQL Servers Uptime, så har vi dock inte full kontroll. Om ett moderbord på en Server falerar, så finns det inte så mycket du kan göra åt det annat än att vara förberedd.
En Introduktion till SQL Server Clustering #1
av Brad M. McGehee
Som du kanske redan vet, så finns det ett sätt att förbättra din SQL Servers uptime, och det är genom att koppla ihop SQL Servers. Om du har gjort det, och en SQL Server inom clustret fallerar, så kommer en annan Server inom clustret att ta över. Detta reducerar uppehållet till minuter istället för ibland fler timmar.
Syftet med den här artikeln är att introducera dig till SQL Server Clustering, tillsammans med dess för- och nackdelar. Om du överväger ett SQL Server Cluster för att hjälpa dig reducera eventuella uppehåll i systemet vid fallering, så är den här artikeln en bra hjälp på vägen.
Vad är Clustering?
Clustering kan bäst beskrivas som en teknologi, som automatiskt låter en fysisk Server ta över arbetet och ansvaret från en annan fysisk Servern, ifall den senare fallerar. Det uppenbara syftet bakom det här är att – förutbestämt att all hård- och mjukvara på en dator någon gång fallerar – försäkra användare som kör arbetskrävande applikationer att det bara blir ett kort uppehåll – om något alls – ifall ett sånt fel skulle ske. Uppehåll kan bli väldigt dyrt, och det är upp till oss DBAs att reducera eventuella uppehåll så mycket som möjligt. Mer specifikt innebär Clustering en grupp av två eller flera Servrar (ofta refererade som ”noder”) som arbetar gemensamt och som båda två representerar sig som en enda virtuell Server i ett nätverk. Med andra ord, när en klient ansluter till clustrade Servrar, så tror den att den ansluter till en enda Server och inte till flera stycken. När en av noderna fallerar, så överförs allt ansvar till en annan Server i det clustrade nätverket. Användaren lär märke ytterst lite – om något alls – av det som sker före, under och efter ett fel.
Microsoft lade till Clustering redskapet då de för flera år sedan introducerade Microsoft NT 4.0 Server Enterprise Edition. Själva Clustering redskapen kallades då MSCS (Microsoft Clustering Server). Medan många modiga människor använde mjukvaran i sin produktion så försökte jag att undvika det så mycket som möjligt, eftersom det inte var så pålitligt som Microsoft ville få dig att tro. Ungefär samtidigt lanserades också SQL Server 6.5 Enterprise Edition, som också hade möjligheten att Clustras. Det var ett mycket osofistikerat försök att clustra SQL Server det var sällan man använde det i verkligheten.
Senare, då SQL Server 7.0 gick att få tag på, så hade det skett stora förbättringar inom SQL Server Clustering. Men det var inte bra nog på långa vägar, då Windows NT 4.0 Server Enterprise MSCS fortfarande användes i grunden, och det var helt enkelt inte bra nog för att behålla lättåtkomliga Servrar.
Som tur var så blev Microsofts andra Clustering försök, det som nu är Microsoft Clustering Server, i Windows 2000 Advanced Server och i Windows 2000 Datacenter Server mycket bättre. Trots att jag inte kan påstå att det är perfekt, så är jag nu åtminstone villig till att clustra högt belastade SQL Servrar. Cluster Server fungerar förvisso bra då du vill clustra SQL Server 6.5, men det fungerar ännu bättre då du vill clustra SQL Server 2000, eftersom den senare har en mer utvecklad support för Clustering.
En annan viktig aspekt som man ofta missar då man använder Clustering, är att det inte är ett komplett backup system för dina applikationer. Clustering är bara en del av en större strategi till att försäkra ett minimalt uppehåll och 100 % återskapning.
En av de huvudsakliga fördelarna som Clustering ger är förmågan att få en server återhämta sig från fallerade hård- (bortsett från de delade hårddiskarna) och mjukvara (som t ex fallerade tjänster eller en Server låsning). Den är inte designad till att skydda data, att skydda en delad hårddisk array från att fallera, att motverka attacker från hackers, att skydda mot nätverkshaveri eller att skydda din SQL Server mot andra möjliga haverier, så som strömavbrott eller andra handlingar från Gud.
Clustering är som sagt bara en del av en större strategi som behövs för att reducera en applikations uppehåll. Du behöver också införskaffa en gemensam hårddisk array som stöder redundans (mer om det sen), spela in backup på band, ställa Servern bakom en brandvägg, försäkra dig om att dina nätverksanslutningar har redundans, använda batteribackup samt lokalisera din Server under en säker avdelning. Dessa är bara en del av de åtgärder du kan genomföra. Så tro inte att det bara är Clustering du måste genomföra för att skapa en lättåtkomlig Server. Det är bara en del av det hela.
Vilka typer av Clustering finns det?
När du har bestämt dig för att clustra en SQL Server, så får du ett val i konfigurationen mellan något som kallas för Active/Active eller Active/Passive cluster. Var och en av dem har sina för- och nackdelar. Låt oss titta på dem, från en två-noders SQL Server cluster miljö. Med ett Active/Active SQL Server cluster menas att SQL Server kör från båda noderna i ett tvåvägs cluster. Varje kopia av SQL Server körs självständigt och användarna ser två stycken olika SQL Servrar. Om en Server i clustret går ner, så kommer den fallerade kopian av SQL Server gå över till den kvarstående Servern. Det innebär att båda instanserna av SQL Server kommer att köras från en fysisk Server, istället för från två separata.
Att ha två instanser körandes på en enda fysisk Server kan, som du kanske förstår, påverka Serverns prestanda. Speciellt om inte Servrarna har nog med plats för det.
Ett Active/Passive SQL Server cluster refererar till ett SQL Server cluster där endast en instans av SQL Server körs, och från endast en av de fysiska Servrarna. Den andra fysiska Servern gör ingenting, annat än väntar på att få ta över från den primära Servern ifall denne skulle fallera.
Från ett prestanda perspektiv, så är den senare det bättre förslaget. Å andra sidan så utnyttjas inte all hårdvara som finns att tillgå, vilket kan göra det här alternativen dyrt.
Personligen så föredrar jag Active/Passive alternativet, då det är enklare att sätta upp och administrera, och allt som allt så kommer den att tjäna in mer prestanda. Så till vida att du har en bra budget, så bör du använda det här förslaget.
Två- eller fyranods clustering?
SQL Server kan bli clustrad med två noder (då du använder Windows 2000 Advanced Server) eller med fler än två noder (då du använder Windows 2000 Datacenter Server). Eftersom jag inte själv har någon erfarenhet av tre- eller fyranods clustering, så tänker jag inte heller ta upp det ämnet här. Men för det mesta så kan du använda tre- eller fyranods clustering precis så som jag har visat att du använder tvånods clustering.
Hur fungerar Clustering?
Clustering är en väldigt komplicerad teknologi, så här tänker jag fokusera mig på den Stora Bilden. I ett tvånods cluster så refereras den ena SQL Servern som den primära noden och den andra som den sekundära noden. I en miljö med Active/Passive cluster så körs SQL Server på den primära noden, och om den skulle fallera så tar den sekundära noden över. När du bygger upp ett tvånods cluster med hjälp av Windows 2000 Advanced Server och Microsoft Cluster Server, så måste varje nod vara ansluten till en delad hårddisk array med SCSI kablar eller genom fiberkanaler.
Vanligtvis så är denna delade hårddisk array en separat enhet som inrymmer en RAID 5 eller RAID 10 hårddisk array. Alla gemensamma data i clustret måste sparas i den här hårddisk arrayen, annars finns det ingen möjlighet för den andra noden att komma åt datan då ett fel skulle inträffa. Som jag nämnde tidigare så skyddar inte Clustering hårddisk arrayen eller den data som lagras i den. Därför är det viktigt att du väljer en gemensam hårddisk array som är väldigt pålitlig och som inkluderar feltolerans.
Förutom att båda Servrarna ska vara anslutna till en gemensam hårddisk array, så måste också de båda noderna i ett cluster anslutas till varandra via ett privat nätverk. Det privata nätverket hjälper noderna att hålla koll på statusen hos varandra. Om t ex den primära noden fallerar, så känner den sekundära noden av det automatiskt, och kan på så sätt initiera ett övertagande.
Så hur vet klienterna som ansluter till en SQL Server när ett fel har inträffat i clustret? Det är det som är det smarta när det gäller Microsoft Cluster Server. Det som i allmänhet sker i ett SQL Server cluster är att SQL Server blir tilldelat ett virtuellt namn och en virtuell TCP/IP-adress. Detta namn och denna adress är gemensamt för båda noderna i ett cluster.
Vanligtvis så ansluter en klient till SQL Server med det virtuella namnet och den virtuella adressen, och så vitt klienten vet så finns det bara en fysisk Server. Om SQL Server körs på den primära noden i ett SQL Server cluster, så är det den primära noden som svarar på klientens anrop. Men om den primära noden skulle fallera, och den sekundära noden tar över ansvaret, så ligger samma virtuella namn och IP-adress kvar i clustret. Det är bara det att det blir en annan fysisk Server som svarar på klientens anrop.
Då ett fel inträffar och en annan Server tar över ansvaret från den primära Servern, så kan det ta flera minuter (hur lång tid beror på antalet och storleken på databaserna i SQL Server, samt hur aktiva dem är) innan övertagandet är klart. Under den tiden så kan inte klienterna komma åt SQL Server, vilket innebär ett kort uppehåll.
Hur klientens mjukvara reagerar på uppehållet beror helt på mjukvaran. Vissa mjukvaror väntar bara ut uppehållet för att sedan fortsätta som om ingenting hänt. Andra kan visa ett meddelande om att anslutningen avbrutits. Och en del mjukvara vet inte vad det ska göra, så klienten kanske behöver stänga ner och ladda om klienten, för att kunna ansluta tillbaka till SQL Server.
Som en viktig del av testprocessen då du vill implementera ett SQL Server Cluster, är att se hur mjukvaran hos klienten som ansluter till SQL Server reagerar på uppehållen som kan bli vid ett fel. På så sätt kan du informera användarna vad de kan förvänta sig, och hur de ska reagera då någonting liknande kanske sker.
Då ett fel inträffar så kan det vara bra om du försöker finna orsaken till felet, för att på så sätt kunna ta till nödvändiga åtgärder för att lösa det. När det väl sedan är åtgärdat, så är nästa steg att flytta tillbaka SQL Server från den sekundära noden till den primära. Du kan schemalägga detta åtagande när som helst, men du bör kanske göra det då det inte finns lika många användare anslutna.
0 Kommentarer