Cluster/Backup - Rasmus

From Teknologisk videncenter
Jump to: navigation, search

Her er en lille omskrivning af det info vi har fået, på backup og clustering området.

Clustering

"A computer cluster is a group of linked computers, working together closely so that in many respects they form a single computer"[1]
Meningen med Clusters er at dele den samme service ud på flere maskiner så man opnår bedre drift sikkerhed. lustering er med til at bringe 3 vigtige ting ind i en service:

  • Højere tilgængelighed/Avalability
  • Større pålidelighed/Reliability
  • større skalerbarhed/Scalability

Så en cluster løsning bidrager til five-nines(99,999) som man jo altid tilstræber når man designer IT løsninger

http://en.wikipedia.org/wiki/Cluster_(computing)

Cluster Models

  • Shared Device Model
    • bruger DLM til at styre filadgangen til samme filsystem, så flere noder ikke skriver til de samme filer på samme tid.
  • Shared Nothing Model
    • NLB er en share nothing model da alt data ligger lokalt på hver node
    • Server Cluster er også shared nothing da det kun er en node der har adgang til de "Fælles" diske af gangen. Idet den aktive node falder over på den anden node overtager den så disken.

Windows NLB

Med Windows NLB sammen sætter man flere noder i et cluster og lader dem alle dele en fælles IP, denne ip er så tilgangen til clusteret og noderne finder selv ud af hvilken node der skal servicere hver client forespørgsel.
NLB cluster på w2k3 understøtter op til 32 noder.

NLB kan fungere på 4 forskellige måder, en kompination af en eller 2 NICs og unicast eller multicast mode. Det anbefales at man bruger unicast med 2 NICs, men har man kun et NIC anbefales Multicast.

  • En NIC
    • Unicast
    • Multicast
  • To NIC
    • Unicast
    • Multicast
2 noder med 2 netkort i unicast mode

Windows Server Clustering

Server Clustering består af op til 8 noder i Windows 2k3 Enterprise Edition. Og består for det meste i en aktiv-standby model, hvor den ene node kører servicen, og den anden bare står og venter til den første node går ned. Dette tilføjer mere til tilgængeligheden og ikke noget til skalerbarheden.
Det kan dog godt lade sig gøre at få en aktiv-aktiv ved at have 2 services hvor node A er den aktive på service 1 og node B på service 2.

Linux Clustering

Storage

Opbevaring af data, hvad end det er på en lokal disk eller i SAN eller NAS.

SAN

Et SAN er måden hvorpå man tilføjer ekstra diske til en server uden de er placering localt i maskinen. Her kunne der være tale om disk arrays eller bånd stationer. I modsætning til lokale diske kan flere SAN diske fra forskellige servere være placeret i samme rack, enten i samme rum som serverne eller i en anden bygning. Det karakteristiske ved SAN er at det arbejder på blok niveau hvor SAN diskene bliver mountet på serverne der skal bruge dem og her optræder som en almindelig disk, OS'et kan smide det filsystem det lyster. I modsætning til et NAS der opererer på fil niveau(SMB/CIFS).

http://en.wikipedia.org/wiki/Storage_area_network

NAS

I modsætning til SAN er NAS hovedsageligt brugt til fil baseret data opbevaring[2]. Hvor man overfører en fil til sit NAS drev via abstrations laget(NFS/CIFS/FTP) og hvordan NAS boksen så håndterer filen er man ligeglad med. Fordelen ved NAS er at man ikke behøver have en maskine til at gøre det, men kan lave noget HW der fortolker data på nogle diske(RAID måske) til diverse fildeling protokoller man bruger og på den måde har HW der er skrædersyet til de opgaver den har. Og ikke skal kunne en masse andre ting også, som en alm. server.

http://en.wikipedia.org/wiki/Network_attached_storage

iSCSI

iSCSI er internet/IP versionen af Small Computer System Interface. SCSI er den bus samt protokol disk kontrolleren bruger til at snakke til diskene med. SCSI diske koster lidt mere end almindelige ATA diske da de har noget mere logik bygget på diskene, som bl.a. sørger for at man kan skrive og læse fra flere diske på (næsten) samme tid. Da bus kablingen er flyttet over på en hvilket som helst medie der kan bære IP, består iSCSI mere af kommunikations protokollen end bus systemet fra SCSI.

http://en.wikipedia.org/wiki/SCSI
http://en.wikipedia.org/wiki/ISCSI

Backup

NTFS har som de fleste filsystemer en archive bit på hver fil. Archive bitten er en attribut ligesom creation date og modified date der findes på alle filer. Når filsystemet ændrer på en fil vil archive bitten automatisk ændres til 1 og man ved så at data i filen er blevet ændret siden sidste backup.
Denne bit findes på langt de fleste filsystemer.

http://technet.microsoft.com/en-us/library/cc784306.aspx

Backup typer

Full

Også kalder Normal backup på Windows Server 2003.
En Full backup tager en komplet kopi af alle filer og sætter archive bitten på alle filer til 0.
Denne backup type tager lang tid da alt data skal kopieres over på backup mediet.

Copy

Copy laver som navnet siger bare en kopi af alle valgte filer, og ændrer ikke archive bittet.
Alt efter hvor mange filer man vælger kan dette tage betydelig tid.

Daily

Daily backup kigget ikke på archive bittet på filerne, men er mere interesseret i hvornår ændrings datoen for filen er. Har du fx. 2 filer hvor den ene har en ændrings dato ældre end et døgn og den anden har en inden for det sidste døgn vil en Daily backup kun tage en backup af den sidste fil. Ved en Daily backup bliver archive bittet ikke sat til 0.

Differential

Differential backup laver en backup af alle filer hvor archive bittet er sat til 1, men sætter den ikke til 0.
En Differential backup tager backup af alle ændrede filer siden sidste Full eller Incremental backup, idet den ikke sætter archive bitten til 0 hvis en Differential backup fylde mere end dagen før, men man behøver så heller ikke gemme tidligere Differential backups.

Incremental

Incremental backup tager en backup af alle filer hvor archive bittet er sat til 1, og markerer filerne som sikkerhedskopieret, ved at sætte archive bit til 0.
Incremental backup kopierer kun filer der er blevet ændret siden sidste Full og Incremental backup, dette betyder at hver backup kun fylder det samme som de seneste ændrede filer. Men skal man restore fra incremental backup skal man bruge dem alle siden sidste Full backup.

Backup Skema

Når man skal implementere backup er det vigtig at planlægge hvilke filer der skal laves en sikkerhedskopi af og hvor ofte dette skal ske.
Hos de fleste virksomheder er systemerne ikke udsat for så meget belastning i weekenderne og når folk får fri hen på eftermiddagen, så på disse tidspunkter ville det jo være optimalt at tage en backup.

Så hvis man vil planlægge en backup cyklus på en uge ville den se ud noget ala det her:

  • Fredag efter fyraften: Full backup, dette har den hele weekenden til da alt skal kopieres.
  • Mandag efter fyraften: Differential, dette tager ikke så lang tid da den kun skal kopiere ændrede filer siden weekenden.
  • Tirsdag efter fyraften: Differential, dette vil tage lidt længere tid da alle ændringer siden weekenden skal kopieres. men der kan spares plads da den Differential backup fra dagen før kan slettes, men mindre man vil have historikken med.
  • Onsdag efter fyraften: Incremental, vil tage noget tid da alle ændringer fra efter weekenden skal med.
  • Torsdag efter fyraften: Differential, dette tager ikke så lang tid da den kun skal kopiere ændrede filer siden om onsdagen.

Backup skema

Dette betyder at hvis systemet bryder sammen om fredagen skal man kun bruge backup fra fredag, onsdag og torsdagen. Men kan stadig restore filer fra alle ugens dage.

Test projekt

Jeg vil prøve at lave en simpel eksempel uden brug af for meget cluster SW vil jeg prøve at lave 2 noder med en IIS på hver. Roden af siden skal så ligge i en lokal folder på hver maskine og den folder skal så replikeres med DFS. Hvis backend til siden bliver hold på ren tekst fil niveau, så ville de 2 maskiner altid have samme version af siden. For at illustrere dette vil jeg lave en simpel tagwall system i asp.net.
Loadsharing på maskinerne skal ske via cisco NAT, som beskrevet her

Projekt diagram med HW loadsharing

DFS er blevet sat op med replikering som i eksemplet her. Så er der blevet smit en IIS på begge noder og dette lille script for at teste principet i det.
Så når du opretter et board på den ene server bliver den "flade" tekst fil replikeret til den anden server og begge servere kan rette og servicere filen. 

<%@ Page language="c#" %>
<%@ Import Namespace="System.IO" %>
<html>
<Head>
  <script language="CS" runat="server">
    string filename;
    string debug;
    void Page_Load() 
    {
	filename = DateTime.Now.ToShortDateString().Replace("-", "")+DateTime.Now.ToLongTimeString().Replace(":", "")+DateTime.Now.Millisecond.ToString().PadLeft(3, '0')+".htm";
	if(Request.QueryString["parrent"] != "" && Request.QueryString["parrent"] != null)
	{
		if(Request.QueryString["parrent"] == "main")
		{
			TextWriter tw = new StreamWriter("d:\\ReplicaFolder\\wwwroot\\"+filename);
      			tw.WriteLine("<html><head><title>Child</title></head><body><form action=\"/\" method=\"get\"><input type=\"hidden\" name=\"parrent\" value=\""+filename+"\" /><br>Reply to post:<table><tr><td>Name:</td><td><input type=\"text\" name=\"name\" /></td></tr><tr><td>Message:</td><td><textarea rows=\"5\" cols=\"30\" name=\"msg\"></textarea></td></table><input type=\"submit\" value=\"Submit\" /></form><br><hr>"+Request.QueryString["name"]+" skrev:<br>"+Request.QueryString["msg"]+"<hr><!--posts--><a href=\"/\">Til index</a></body></html>");
      			tw.Close();
		}
		else
		{
			StreamReader reader = new StreamReader("d:\\ReplicaFolder\\wwwroot\\"+Request.QueryString["parrent"]);
			string line = reader.ReadToEnd();
			reader.Close();
			line = line.Replace("<!--posts-->", "<br>"+Request.QueryString["name"]+" skrev:<br>"+Request.QueryString["msg"]+"<hr><!--posts-->");
			debug = line;
			TextWriter tw = new StreamWriter("d:\\ReplicaFolder\\wwwroot\\"+Request.QueryString["parrent"]);
      			tw.WriteLine(line);
      			tw.Close();
		}
	}
    }
  </script>
</Head>

<body>
<form action="/" method="get">
<input type="hidden" name="parrent" value="main" /><br>
<table>
<tr>
<td>Name:</td><td><input type="text" name="name" /></td>
</tr><tr>
<td>Message:</td><td><textarea rows="5" cols="30" name="msg">
</textarea></td></table>
<input type="submit" value="Submit" />
</form>
<%
if(Request.QueryString["parrent"] != "" && Request.QueryString["parrent"] != null && Request.QueryString["parrent"] != "main")
{
%>
<a href="<%=Request.QueryString["parrent"]%>">Gå til dit post</a>
<%
}
else
{
%>
<a href="<%=filename%>">Gå til din post (Hvis du har lavet en)</a>
<%
}
%>
<hr>
<%
string [] fileEntries = Directory.GetFiles(@"d:\ReplicaFolder\wwwroot\");
foreach(string fileName in fileEntries)
{
debug = "Fundet filer";
if(fileName.IndexOf(".htm") >=0)
{
%>
<a href="<%=Path.GetFileName(fileName)%>"><%=Path.GetFileName(fileName)%><%if(filename==Path.GetFileName(fileName)|| Request.QueryString["parrent"]==Path.GetFileName(fileName)){%>(Dette er dit indlæg)<%}%></a><br>
<%
}
}

%>
<!--<hr>
Debug info:<%=debug%>-->
</body>
</html>
Retrieved from "http://mars.merhot.dk/w/index.php?title=Cluster/Backup_-_Rasmus&oldid=5924"