Principen för deras funktion är baserad på distributionen av förfrågningar genom en eller flera ingångsnoder, som omdirigerar dem för bearbetning till de återstående datornoderna. Det initiala målet för ett sådant kluster är prestanda, men de använder ofta också tekniker för att förbättra tillförlitligheten. Sådana strukturer kallas serverfarmar. Programvaran kan vara antingen kommersiell (OpenVMS, MOSIX, Platform LSF HPC, Solaris Cluster, Moab Cluster Suite, Maui Cluster Scheduler) eller gratis (OpenMosix, Sun Grid Engine, Linux Virtual Server).
Kluster används för beräkningsändamål, särskilt inom vetenskaplig forskning. För datorkluster är viktiga indikatorer hög processorprestanda i flyttalsoperationer (flops) och låg latens hos det anslutande nätverket, och mindre signifikanta är hastigheten för I/O-operationer, vilket är viktigare för databaser och webbtjänster. Datorkluster gör det möjligt att minska beräkningstiden jämfört med en enskild dator genom att dela upp uppgiften i parallellt exekverande grenar som utbyter data över ett sammankopplat nätverk. En av de typiska konfigurationerna är en uppsättning datorer som är sammansatta av allmänt tillgängliga komponenter, med operativsystemet Linux installerat på dem, och nätverk Ethernet, Myrinet, InfiniBand eller andra relativt billiga nätverk. Ett sådant system brukar kallas ett Beowulf-kluster. Högpresterande kluster är speciellt identifierade (betecknas med den engelska förkortningen HPC-kluster - Högpresterande datorkluster). Lista över de mest kraftfulla högpresterande datorerna (kan också betecknas med den engelska förkortningen HPC) finns på världsrankingen TOP500. Ryssland har en klassificering av de mest kraftfulla datorerna i OSS.
Sådana system betraktas vanligtvis inte som kluster, men deras principer liknar till stor del klusterteknologi. De kallas också rutsystem. Huvudskillnaden är den låga tillgängligheten för varje nod, det vill säga omöjligheten att garantera dess drift vid en given tidpunkt (noder är anslutna och frånkopplade under drift), därför måste uppgiften delas upp i ett antal processer oberoende av varje nod. andra. Ett sådant system, till skillnad från kluster, är inte som en enda dator, utan fungerar som ett förenklat sätt att distribuera beräkningar. Instabiliteten i konfigurationen, i detta fall, kompenseras av ett stort antal noder.
Klustersystem intar en värdig plats i listan över de snabbaste, samtidigt som de överträffar superdatorerna i pris. Från och med juli 2008 är SGI Altix ICE 8200-klustret (Chippewa Falls, Wisconsin, USA) på 7:e plats i TOP500-klassificeringen.
Relativt billigt alternativ superdatorer representeras av kluster baserade på Beowulf-konceptet, som är byggda från vanliga billiga datorer baserade på fri programvara. Ett praktiskt exempel på ett sådant system är Stone Soupercomputer vid Oak Ridge National Laboratory (Tennessee, USA, 1997).
Det största klustret som ägs av en privatperson (av 1000 processorer) byggdes av John Koza.
Historien om skapande av kluster är oupplösligt kopplad till den tidiga utvecklingen på området datornätverk. En av anledningarna till uppkomsten av höghastighetskommunikation mellan datorer var hoppet om att slå samman datorresurser. I början av 1970-talet etablerade TCP/IP-utvecklingsteamet och Xerox PARC-laboratoriet nätverksstandarder. Operativsystemet Hydra för PDP-11-datorer som producerats av DEC dök också upp klustret som skapades på denna grundval av namnet C.mpp (Pittsburgh, Pennsylvania, USA, 1971). Det var dock inte förrän runt 1983 som mekanismer skapades för att göra det enkelt att distribuera uppgifter och filer över ett nätverk, mestadels från SunOS (ett BSD-baserat operativsystem från Sun Microsystems).
Det första kommersiella projektet i klustret var ARCNet, skapat av Datapoint 1977. Det blev inte lönsamt, och därför utvecklades klusterbygget inte förrän 1984, då DEC byggde sitt VAXcluster baserat på operativsystem VAX/VMS. ARCNet och VAXcluster designades inte bara för gemensam beräkning, utan också delning filsystem och kringutrustning, med hänsyn till att datas integritet och otvetydighet upprätthålls. VAXCluster (nu kallat VMSCluster) är en integrerad komponent i operativsystemet OpenVMS som använder DEC Alpha och Itanium-processorer.
Två andra tidiga klusterprodukter som fick erkännande inkluderar Tandem Hymalaya (1994, klass ) och IBM S/390 Parallel Sysplex (1994).
Historien om att skapa kluster från vanliga persondatorer har mycket att göra med Parallel Virtual Machine-projektet. 1989 detta programvara att kombinera datorer till en virtuell superdator, öppnade det för möjligheten att omedelbart skapa kluster. Som ett resultat överträffade den totala prestandan för alla billiga kluster skapade vid den tiden summan av kapaciteten hos "seriösa" kommersiella system.
Skapandet av kluster baserade på billiga persondatorer anslutna till ett dataöverföringsnätverk fortsatte 1993 av American Aerospace Agency NASA, sedan 1995 utvecklades Beowulf-kluster, speciellt designade utifrån denna princip. Framgången för sådana system har stimulerat utvecklingen
Blue Gene /L och SGI Altix familjer.Windows Compute Cluster Server (CCS) 2003 anses vara den grundläggande programvaran för att organisera datoranvändning i klustersystem. allmänna egenskaper och sammansättningen av tjänster som körs på klusternoder.
Avslutningsvis detta avsnitt, tillhandahåller regler för att arbeta med konsolen för att starta och hantera CCS-jobb. Beskriver detaljerna om hur CCS-schemaläggaren fungerar vid exekvering av sekvenser av jobb i ett kluster.
I historien om utvecklingen av datorprocessorarkitektur kan två stora stadier särskiljas:
Således har tillvägagångssättet baserad på SMP (Symmetrical MultiProcessing), som utvecklades när man byggde högpresterande servrar där flera processorer delar systemresurser, och först och främst RAM (se figur 1.1), flyttats "ned" till nivån för kärnor inuti processorn.
Ris. 1.1.
På vägen mot flerkärniga processorer var den första tekniken som dök upp Hyper-Threading, som först användes 2002 i Intel Pentium 4-processorer:
I denna teknik delar två virtuella processorer på alla resurserna hos en fysisk processor, nämligen cacher, en exekveringspipeline och separata exekveringsenheter. Dessutom, om en virtuell processor är upptagen delad resurs, sedan väntar den andra på sin frigivning. Således kan en processor med Hyper-Threading jämföras med ett multitasking-operativsystem som förser varje process som körs i den med sin egen virtuella dator med en komplett uppsättning verktyg och planerar ordning och tid för dessa processer på fysisk hårdvara. Endast i fallet med Hyper-Threading sker allt detta på en mycket lägre hårdvarunivå. Två instruktionsströmmar tillåter dock att processorns exekveringsenheter laddas mer effektivt. Den verkliga ökningen av processorprestanda från användningen av Hyper-Threading-teknik uppskattas från 10 till 20 procent.
En fullfjädrad dual-core processor (se fig. 1.3) visar en prestandaökning på 80 till 100 procent på vissa uppgifter.
Sålunda, dual-core och, i allmänhet, flerkärnig processor, kan betraktas som ett miniatyr SMP-system, där det inte finns något behov av att använda komplexa och dyra multiprocessor-moderkort.
Dessutom kan varje kärna (som i t.ex. Intel-processor Pentium Extreme Edition 840) stöder Hyper-Threading-teknik, och därför kan denna typ av dual-core processor köra fyra programtrådar samtidigt.
I början av 2007 introducerade Intel en 80-kärnig enkelchipsprocessor kallad Teraflops Research Chip (http://www.intel.com/research/platform/terascale/teraflops.htm). Denna processor kan uppnå 1,01 teraflops prestanda med en lägsta kärnklockhastighet på 3,16 GHz och en spänning på 0,95 V. Den totala energiförbrukning chip är bara 62 watt.
Enligt Intels prognoser kommer kommersiella versioner av processorer med ett stort antal kärnor att dyka upp under de kommande 5 åren, och 2010 kommer en fjärdedel av alla servrar som levereras att ha teraflops. prestanda.
Klunga- är lokal (belägen geografiskt på ett ställe) datorsystem, bestående av många oberoende datorer och ett nätverk som ansluter dem. Dessutom är klustret ett lokalt system eftersom det hanteras inom en separat administrativ domän som ett enda datorsystem.
Datornoder som den består av är standarddatorer för allmänna ändamål (personliga) som används inom en mängd olika områden och för en mängd olika tillämpningar. En beräkningsnod kan innehålla antingen en mikroprocessor eller flera, och bildar, i det senare fallet, en symmetrisk (SMP) konfiguration.
Nätverkskomponenten i klustret kan antingen vara vanlig lokala nätverk, eller byggas på grundval av speciella nätverkstekniker, ger ultrasnabb dataöverföring mellan klusternoder. Klusternätverket är utformat för att integrera klusternoder och är vanligtvis skilt från det externa nätverk genom vilket användarna kommer åt klustret.
Klusterprogramvara består av två komponenter:
Utvecklingsverktyg inkluderar kompilatorer för språk, bibliotek för olika ändamål, verktyg för prestandamätning, såväl som debuggers, som tillsammans låter dig bygga parallella applikationer.
Programvara för resurshantering inkluderar verktyg för installation, administration och schemaläggning av arbetsflöden.
Även om det finns många programmeringsmodeller för parallell bearbetning, är den för närvarande dominerande metoden meddelandeöverföringsmodellen, implementerad i form av MPI-standarden (Message Passing Interface). MPI är ett bibliotek med funktioner som kan användas i program skrivna i C eller Fortran för att skicka meddelanden mellan parallella processer och även styra dessa processer.
Alternativ till detta tillvägagångssätt är språk baserade på det så kallade "globala partitionerade adressutrymmet" (GPAS), vars typiska representanter är språken HPF (High Performance Fortran) och UPC (Unified Parallel C).
Några tankar om när det är vettigt att använda högtillgänglighetskluster för att skydda applikationer.
En av huvuduppgifterna när man driver ett IT-system i någon verksamhet är att säkerställa kontinuiteten i den tillhandahållna tjänsten. Men väldigt ofta har både ingenjörer och IT-chefer ingen klar förståelse för vad "kontinuitet" specifikt betyder i deras verksamhet. Enligt författarens åsikt beror detta på tvetydigheten och vagheten i själva begreppet kontinuitet, varför det inte alltid är möjligt att tydligt säga vilken samplingsperiod som anses vara kontinuerlig och vilket intervall som kommer att vara otillgänglighetsperioden. Situationen förvärras av den mångfald av teknologier som är utformade för att i slutändan lösa ett gemensamt problem, men på olika sätt.
Vilken teknik bör väljas i varje specifikt fall för att lösa de tilldelade problemen inom den tillgängliga budgeten? I den här artikeln kommer vi att titta närmare på ett av de mest populära tillvägagångssätten för att skydda applikationer, nämligen att introducera hård- och mjukvaruredundans, dvs bygga ett kluster med hög tillgänglighet. Denna uppgift, trots den uppenbara enkelheten i implementeringen, är faktiskt mycket svår att finjustera och använda. Förutom att beskriva välkända konfigurationer kommer vi att försöka visa vilka andra funktioner – som inte används särskilt ofta – som finns i sådana lösningar, hur olika implementeringar av kluster är uppbyggda. Dessutom skulle vi ofta vilja att kunden, efter att ha övervägt alla fördelar med klusterupplägget, ändå skulle ha dess nackdelar i åtanke och därför överväga hela utbudet av möjliga lösningar.
Enligt olika uppskattningar är 55-60 % av ansökningarna kritiska för ett företags verksamhet – det betyder att frånvaron av tjänsten som dessa applikationer tillhandahåller kommer att allvarligt påverka företagets ekonomiska välbefinnande. I detta avseende blir begreppet tillgänglighet en grundläggande aspekt i driften av ett datacenter. Låt oss ta en titt på var applikationstillgänglighetshot kommer ifrån.
Dataförstöring. Ett av de största problemen är tillgängligheten av tjänsten. Det enklaste sättet skydd - ta ofta "snapshots" av data för att när som helst kunna återgå till en fullständig kopia.
Maskinvarufel. Tillverkare av hårdvarusystem (servrar, disklagring) producerar lösningar med redundanta komponenter - processorkort, systemkontroller, strömförsörjning etc. Men i vissa fall kan ett hårdvarufel leda till att applikationen inte är tillgänglig.
Applikationsfel. Ett programmeringsfel i en applikation som redan har testats och satts i produktion kan uppstå i ett fall i tiotals eller till och med hundratusentals, men om en sådan incident inträffar leder det till en direkt förlust av vinst för organisationen, eftersom transaktionen bearbetningen stannar, och metoden för att eliminera felet är inte uppenbar och tar tid.
Mänskligt fel. Enkelt exempel: en administratör gör ändringar i en inställning konfigurationsfiler till exempel DNS. När den testar ändringarna fungerar DNS-tjänsten, men tjänsten som använder DNS, t.ex. e-post, börjar uppleva problem som inte omedelbart identifieras.
Schemalagt underhåll. Systemunderhåll - att byta ut komponenter, installera servicepack, starta om - är den främsta orsaken till otillgänglighet. Gartner uppskattar att 80 % av tiden ett system är otillgängligt beror på planerade driftstopp.
Vanliga problem på datorsidan.Även om en organisation gör allt för att skydda sig mot lokala problem, garanterar detta inte tillgängligheten av tjänsten om hela sidan av någon anledning inte är tillgänglig. Detta måste också beaktas vid planering av systemet.
Beroende på hur kritisk uppgiften är kan följande mekanismer användas för att återställa datorsystemets funktionalitet.
Säkerhetskopiering data till band eller diskmedia. Detta är den grundläggande tillgänglighetsnivån - den enklaste, billigaste, men också den långsammaste.
Lokal spegling. Ger datatillgänglighet i realtid, data skyddas från förstörelse.
Lokal klustring. När dataskyddet väl är på plats är nästa steg för att säkerställa applikationstillgänglighet lokal klustring, det vill säga skapa redundans i både hårdvara och mjukvara.
Fjärrreplikering. Här förutsätts att datorsajterna distribueras för att skapa en kopia av datan i distribuerade datacenter.
Fjärrklustring. Eftersom tillgången på data på olika platser säkerställs, är det också möjligt att upprätthålla tillgängligheten för tjänsten från olika platser genom att organisera applikationsåtkomst till dessa data.
Vi kommer inte att uppehålla oss här vid beskrivningen av alla dessa metoder, eftersom varje punkt mycket väl kan bli ämnet för en separat artikel. Tanken är transparent - ju mer redundans vi introducerar, desto högre kostnad för lösningen, men desto bättre skyddas applikationerna. För var och en av ovanstående metoder finns det en arsenal av lösningar från olika tillverkare, men med en standarduppsättning av möjligheter. För lösningsdesignern är det mycket viktigt att ha alla dessa tekniker i åtanke, eftersom endast deras kompetenta kombination kommer att leda till en heltäckande lösning på problemet som kunden ställer.
Enligt författarens åsikt är Symantecs tillvägagångssätt mycket framgångsrikt för att förstå strategin för tjänståterställning (Fig. 1). Det finns två nyckelpunkter här - punkten där systemet återställs (återställningspunktsobjektiv, RPO), och den tid som krävs för att återställa tjänsten (återställningstidsmål, RTO).
Valet av ett särskilt verktyg beror på de specifika kraven för en kritisk applikation eller databas.
För de mest kritiska systemen bör RTO och RPO inte överstiga 1 timme. Dessutom är återställning från band inte automatiserad, administratören måste hela tiden komma ihåg om han har återställt allt ordentligt och startat det.
Dessutom, som redan nämnts, räcker det inte med ett verktyg när man planerar ett tillgänglighetssystem. Till exempel är det knappast meningsfullt att bara använda ett replikeringssystem. Även om viktiga data finns på en avlägsen plats måste applikationer startas i lämplig ordning manuellt. Således replikering utan automatisk start applikationer kan ses som en form av dyr backup.
Om du behöver tillhandahålla RTO och RTS mätt i minuter, det vill säga uppgiften kräver att minimera driftstopp (både planerade och oplanerade), så är den enda rätta lösningen ett kluster med hög tillgänglighet. Den här artikeln diskuterar just sådana system.
På grund av det faktum att begreppet "datorkluster" har varit överbelastat under en tid på grund av deras stora mångfald, låt oss först säga lite om vilka typer av kluster som finns.
I sin enklaste form är ett kluster ett system av datorer som arbetar tillsammans för att gemensamt lösa problem. Detta är inte en klient-server-bearbetningsmodell, där applikationen kan separeras logiskt så att klienter kan dirigera förfrågningar till olika servrar. Tanken med ett kluster är att slå samman datorresurserna för relaterade noder för att skapa redundanta resurser som ger större delad datorkraft, hög tillgänglighet och skalbarhet. Således behandlar kluster inte bara klientförfrågningar till servrar, utan använder samtidigt många datorer som representerar dem som enhetligt system och därigenom ge betydligt större beräkningsmöjligheter.
Ett kluster av datorer måste vara ett självorganiserande system - arbete som utförs på en av noderna måste koordineras med arbete på andra noder. Detta leder till komplexiteten i konfigurationsanslutningar, svåra kommunikationer mellan klusternoder och behovet av att lösa problemet med att komma åt data i ett gemensamt filsystem. Det finns också driftsproblem förknippade med att driva ett potentiellt stort antal datorer som en enda resurs.
Kluster kan finnas i olika former. De vanligaste typerna av kluster inkluderar högpresterande datorsystem (HPC) och system med hög tillgänglighet (HA).
Högpresterande datorkluster använder parallella beräkningsmetoder som använder så mycket processorkraft som möjligt för att lösa ett givet problem. Det finns många exempel på sådana lösningar inom scientific computing, där många lågkostnadsprocessorer används parallellt för att utföra ett stort antal operationer.
Ämnet för den här artikeln är dock system med hög tillgänglighet. Därför, när vi talar om kluster, kommer vi att ha i åtanke just sådana system.
Vanligtvis, när man bygger högtillgänglighetskluster, används redundans för att skapa en pålitlig miljö, det vill säga ett datorsystem skapas där fel på en eller flera komponenter (hårdvara, mjukvara eller nätverk) inte har en betydande inverkan på tillgängligheten av applikationen eller systemet i allmänhet.
I det enklaste fallet är det två identiskt konfigurerade servrar med tillgång till ett delat datalagringssystem (Fig. 2). Under normal drift körs applikationsprogramvara på ett system medan ett andra system väntar på att applikationer ska köras när det första systemet misslyckas. När ett fel upptäcks växlar det andra systemet över motsvarande resurser (filsystem, nätverksadresser etc.). Denna process kallas vanligtvis för failover. Det andra systemet ersätter helt det misslyckade och användaren behöver inte veta att hans applikationer körs på olika fysiska maskiner. Detta är den vanligaste asymmetriska konfigurationen med två noder, där en server är aktiv, den andra är passiv, det vill säga den är i standby-läge ifall den huvudsakliga skulle misslyckas. I praktiken är detta det system som fungerar i de flesta företag.
Frågan måste dock ställas: hur acceptabelt är det att ha en extra uppsättning utrustning som i huvudsak är i reserv och som inte används för det mesta? Problemet med lossad utrustning löses genom att ändra klusterschemat och allokera resurser i det.
Förutom den asymmetriska klusterstrukturen med två noder som nämns ovan, finns det möjliga alternativ som kan ha olika namn från olika klustermjukvarutillverkare, men deras kärna är densamma.
Symmetriskt kluster
Det symmetriska klustret är också gjort på två noder, men på var och en av dem finns en aktiv applikation igång (Fig. 3). Klustermjukvara säkerställer korrekt automatisk övergång av en applikation från server till server om en av noderna misslyckas. I det här fallet är det mer effektivt att ladda hårdvaran, men om ett fel inträffar körs hela systemets applikationer på en server, vilket kan få oönskade prestandakonsekvenser. Dessutom måste du överväga om det är möjligt att köra flera applikationer på samma server.
N+1-konfiguration
Denna konfiguration innehåller redan mer än två noder, och bland dem finns det en dedikerad backup-en (Fig. 4). Med andra ord, för varje N som körs servrar finns det en i hot standby. I händelse av ett fel kommer applikationen från den problematiska noden att "flytta" till en dedikerad ledig nod. I framtiden kommer klusteradministratören att kunna ersätta den misslyckade noden och ange den som en backup.
N+1-variationen är en mindre flexibel N till 1-konfiguration där backupnoden alltid förblir konstant för alla arbetarnoder. Om den aktiva servern misslyckas, växlar tjänsten till backup-servern och systemet förblir utan backup tills den misslyckade noden aktiveras.
Av alla klusterkonfigurationer är N+1 förmodligen den mest effektiva när det gäller komplexitet och utrustningseffektivitet. Tabellen nedan 1 bekräftar denna bedömning.
N till N-konfiguration
Detta är den mest effektiva konfigurationen när det gäller användningsnivån för datorresurser (fig. 5). Alla servrar i den fungerar, var och en av dem kör applikationer som ingår i klustersystemet. Om ett fel inträffar på en av noderna, flyttas applikationer från den i enlighet med fastställda policyer till de återstående servrarna.
När du designar ett sådant system är det nödvändigt att ta hänsyn till applikationernas kompatibilitet, deras anslutningar när du "flyttar" från nod till nod, serverbelastning, genomströmning nätverk och mycket mer. Denna konfiguration är den mest komplexa att designa och använda, men den ger mest valuta för pengarna när du använder klusterredundans.
Utvärdera klusterkonfigurationer
I tabell 1 sammanfattar vad som har sagts ovan om de olika klusterkonfigurationerna. Betyget ges på en fyragradig skala (4 är högsta poäng, 1 är lägst).
Från bordet 1 kan man se att det klassiska asymmetriska systemet är det enklaste vad gäller design och funktion. Och om kunden kan driva den självständigt, skulle det vara korrekt att överföra resten till externt underhåll.
Som avslutning på samtalet om konfigurationer skulle jag vilja säga några ord om kriterierna enligt vilka klusterkärnan automatiskt kan ge ett kommando för att "flytta" en applikation från nod till nod. Den överväldigande majoriteten av administratörer definierar bara ett kriterium i konfigurationsfilerna - otillgängligheten av någon komponent i noden, det vill säga ett hårdvaru- eller mjukvarufel.
Samtidigt ger modern klusterprogramvara möjligheten att lastbalansera. Om belastningen på en av noderna når ett kritiskt värde, med en korrekt konfigurerad policy, kommer applikationen på den att stängas av korrekt och starta på en annan nod där den aktuella belastningen tillåter detta. Dessutom kan serverlastkontrollverktyg vara antingen statiska - applikationen själv anger i klusterkonfigurationsfilen hur många resurser den behöver - eller dynamiska, när lastbalanseraren är integrerad med ett externt verktyg (till exempel Precise), som beräknar nuvarande systembelastning.
Nu, för att förstå hur kluster fungerar i specifika implementeringar, låt oss överväga huvudkomponenterna i alla högtillgänglighetssystem.
Som alla komplexa komplex består ett kluster, oavsett dess specifika implementering, av hårdvaru- och mjukvarukomponenter.
När det gäller hårdvaran som klustret är monterat på, är huvudkomponenten här en internodanslutning eller intern klustersammankoppling, vilket ger fysisk och logisk anslutning mellan servrar. I praktiken är detta ett internt Ethernet-nätverk med dubbla anslutningar. Dess syfte är, för det första, överföring av paket som bekräftar systemets integritet (det så kallade hjärtslag), och för det andra, med en viss design eller ett schema som uppstod efter att ett fel inträffade, utbyte av informationstrafik mellan noder avsedda för överföring utanför. Andra komponenter är uppenbara: noder som kör ett OS med klusterprogramvara, disklagring som klusternoder har tillgång till. Och slutligen, delat nätverk, genom vilken klustret interagerar med omvärlden.
Programvarukomponenter ger kontroll över driften av klusterapplikationen. Först och främst är det ett vanligt operativsystem (inte nödvändigtvis en vanlig version). Kärnan i klustret - klusterprogramvara - körs i miljön för detta operativsystem. De applikationer som är klustrade, det vill säga kan migrera från nod till nod, styrs – startas, stoppas, testas – av små skript, så kallade agenter. Det finns standardagenter för de flesta uppgifter, men i designstadiet är det absolut nödvändigt att kontrollera med hjälp av kompatibilitetsmatrisen om det finns agenter för specifika applikationer.
Det finns många implementeringar av klusterkonfigurationerna som beskrivs ovan på mjukvarumarknaden. Nästan alla de största server- och mjukvarutillverkarna - till exempel Microsoft, HP, IBM, Sun, Symantec - erbjuder sina produkter inom detta område. Microtest har erfarenhet av att arbeta med Sun Cluster Server (SC)-lösningar från Sun Microsystems (www.sun.com) och Veritas Cluster Server (VCS) från Symantec (www.symantec.com). Ur en administratörs synvinkel är dessa produkter väldigt lika i funktionalitet - de ger samma inställningar och reaktioner på händelser. Men sett till deras interna organisation är det helt andra produkter.
SC utvecklades av Sun för sitt eget Solaris OS och körs därför endast på det operativsystemet (både SPARC och x86). Som ett resultat är SC under installationen djupt integrerad med operativsystemet och blir en del av det, en del av Solaris-kärnan.
VCS är en multiplattformsprodukt, fungerar med nästan alla för närvarande populära operativsystem - AIX, HP-UX, Solaris, Windows, Linux, och är ett tillägg - en applikation som styr driften av andra applikationer som är föremål för klustring .
Vi kommer att titta på den interna implementeringen av dessa två system - SC och VCS. Men låt oss återigen betona att trots skillnaden i terminologi och helt olika interna struktur, är huvudkomponenterna i båda systemen som administratören interagerar med i huvudsak desamma.
Sun Cluster Server Programvarukomponenter
SC-kärnan (fig. 6) är Solaris 10 (eller 9) OS med ett inbyggt skal som ger hög tillgänglighetsfunktionalitet (kärnan är markerad i grönt). Nästa är de globala komponenterna (ljusgröna), som tillhandahåller sina tjänster från klusterkärnan. Och slutligen, högst upp finns anpassade komponenter.
HA-ramverket är en komponent som utökar Solaris-kärnan för att tillhandahålla klustrade tjänster. Ramverksuppgiften börjar med att initiera koden som startar noden till klusterläge. Ramverkets huvuduppgifter är inter-nodinteraktion, förvaltning av klusterstaten och medlemskap i den.
Kommunikationsmodulen mellan noder sänder hjärtslagande meddelanden mellan noder. Dessa är korta meddelanden som bekräftar svaret från en närliggande nod. Kommunikation mellan data och applikationer hanteras också av HA-ramverket som en del av kommunikationen mellan noderna. Dessutom hanterar ramverket integriteten för klusterkonfigurationen och utför återställnings- och uppdateringsuppgifter vid behov. Integriteten upprätthålls genom kvorumanordningen; omkonfigurering utförs vid behov. En kvorumenhet är en ytterligare mekanism för att verifiera integriteten hos klusternoder genom små delar av det delade filsystemet. I senaste versionen Med SC 3.2-klustret blev det möjligt att tilldela en kvorumenhet utanför klustersystemet, d.v.s. använda en extra server på Solaris-plattformen, tillgänglig via TCP/IP. Misslyckade klustermedlemmar tas bort från konfigurationen. Ett element som åter tas i drift ingår automatiskt i konfigurationen.
De globala komponenternas funktioner härleds från HA-ramverket. Dessa inkluderar:
Användarkomponenter hanterar klustermiljön på översta nivån i applikationsgränssnittet. Det går att administrera via GUI, och via kommandoraden. Moduler som övervakar applikationer och startar och stoppar dem kallas agenter. Det finns ett bibliotek med färdiga agenter för standardapplikationer; Den här listan växer för varje release.
Veritas Cluster Server Software Components
Ett VCS-kluster med två noder visas schematiskt i fig. 7. Kommunikation mellan noder i VCS är baserad på två protokoll - LLT och GAB. VCS använder ett internt nätverk för att upprätthålla klusterintegritet.
LLT (Low Latency Transport) är ett protokoll utvecklat av Veritas som fungerar ovanpå Ethernet som en högpresterande ersättning för IP-stacken och som används av noder i all intern kommunikation. Den erforderliga redundansen i kommunikationer mellan noder kräver minst två helt oberoende interna nätverk. Detta är nödvändigt för att VSC ska kunna skilja mellan ett nätverksfel och ett systemfel.
LLT-protokollet utför två huvudfunktioner: trafikdistribution och att skicka hjärtslag. LLT distribuerar (balanserar) kommunikation mellan noderna mellan alla tillgängliga interna länkar. Denna design säkerställer att all intern trafik fördelas slumpmässigt över interna nätverk (det kan vara maximalt åtta), vilket förbättrar prestanda och feltolerans. Om en länk misslyckas kommer data att omdirigeras till de återstående andra. Dessutom är LLT ansvarig för att skicka hjärtslagstrafik genom nätverket, som används av GAB.
GAB (Group Membership Services/Atomic Broadcast) är det andra protokollet som används av VCS för intern kommunikation. Han, liksom LLT, ansvarar för två uppgifter. Den första är medlemskapet av noder i klustret. GAB tar emot hjärtslag från varje nod via LLT. Om systemet inte får ett svar från en nod under en längre tid, markerar det dess tillstånd som NED - fungerar inte.
Den andra funktionen hos GAB är att säkerställa tillförlitlig kommunikation mellan kluster. GAB tillhandahåller garanterad leverans av sändningar och punkt-till-punkt-meddelanden mellan alla noder.
Kontrollkomponenten i VCS är VCS-motorn, eller HAD (High Availability-demon), som körs på varje system. Hon ansvarar för:
HAD använder agenter för att övervaka och hantera resurser. Information om resursernas tillstånd samlas in från agenter på lokala system och sänds till alla klustermedlemmar. Varje nods HAD tar emot information från andra noder och uppdaterar sin egen bild av hela systemet. HAD fungerar som en replikerad tillståndsmaskin RSM, dvs kärnan på varje nod har en bild av resurstillståndet som är helt synkroniserad med alla andra noder.
VSC-klustret hanteras antingen via Java-konsolen eller via webben.
Vilket är bättre
Vi har redan diskuterat frågan om när det är bättre att använda vilket kluster. Låt oss återigen betona att SC-produkten skrevs av Sun för sitt eget operativsystem och är djupt integrerad med den. VCS är en multiplattformsprodukt och därför mer flexibel. I tabell 2 jämför några av funktionerna hos dessa två lösningar.
Avslutningsvis skulle jag vilja ge ytterligare ett argument för att använda SC i Solaris-miljön. Genom att använda både utrustning och mjukvara från en enda tillverkare - Sun Microsystems, får kunden en "single window"-tjänst för hela lösningen. Trots att leverantörer nu skapar gemensamma kompetenscentra, kommer tiden det tar att skicka förfrågningar mellan mjukvaru- och hårdvarutillverkare att minska reaktionshastigheten på en incident, vilket inte alltid passar användaren av systemet.
Vi tittade på hur ett kluster med hög tillgänglighet är byggt och fungerar inom en plats. Denna arkitektur kan endast skydda mot lokala problem inom en enda nod och de data som är associerade med den. I händelse av problem som påverkar hela webbplatsen, vare sig det är tekniskt, naturligt eller på annat sätt, kommer hela systemet att vara otillgängligt. Idag dyker det upp allt mer uppgifter, vars kritiska karaktär kräver migrering av tjänster inte bara inom webbplatsen utan även mellan geografiskt spridda datacenter. När man utformar sådana lösningar måste nya faktorer beaktas - avståndet mellan platser, kanalkapacitet, etc. Vilken replikering bör föredras - synkron eller asynkron, värdbaserad eller array-baserad, vilka protokoll ska användas? Framgången för projektet kan bero på lösningen av dessa frågor.
Datareplikering från huvudplatsen till säkerhetskopieringsplatsen utförs oftast med ett av de populära paketen: Veritas Volume Replicator, EMC SRDF, Hitachi TrueCopy, Sun StorageTek Availability Suite.
Om det finns ett hårdvarufel eller problem med applikationen eller databasen kommer klusterprogramvaran först att försöka överföra applikationstjänsten till en annan nod på huvudsidan. Om huvudplatsen av någon anledning är otillgänglig för omvärlden, migrerar alla tjänster, inklusive DNS, till säkerhetskopieringsplatsen, där det, tack vare replikering, redan finns data. Därmed återupptas tjänsten för användarna.
Nackdelen med detta tillvägagångssätt är den enorma kostnaden för att distribuera en extra "het" webbplats med utrustning och nätverksinfrastruktur. Fördelen med ett fullständigt skydd kan dock uppväga dessa extra kostnader. Om den centrala noden inte kan tillhandahålla service under en längre tid kan detta leda till stora förluster och till och med verksamhetens död.
Enligt en studie utförd av Symantec testar endast 28 % av företagen sin katastrofåterställningsplan. Tyvärr hade de flesta kunder som författaren var tvungen att prata med om denna fråga inte alls en sådan plan. Orsakerna till att testning inte utförs är brist på tid för administratörer, ovilja att göra det på ett "live" system och brist på testutrustning.
För testning kan du använda simulatorn som ingår i VSC-paketet. Användare som väljer VCS som sin klustringsprogramvara kan testa sin installation med hjälp av Cluster Server Simulator, som låter dem testa sin applikationsmigreringsstrategi mellan noder på en PC.
Uppgiften att tillhandahålla en tjänst med hög nivå tillgänglighet är mycket dyrt både när det gäller kostnaden för utrustning och mjukvara, och när det gäller kostnaden för ytterligare underhåll och teknisk support system. Trots teorins skenbara enkelhet och okomplicerade installation visar sig klustersystemet, när det studeras på djupet, vara en komplex och dyr lösning. I den här artikeln betraktades den tekniska sidan av systemets drift endast i allmänna termer, men en separat artikel kunde skrivas om enskilda frågor av klustrets drift, till exempel för att fastställa medlemskap i det.
Kluster byggs vanligtvis för affärskritiska uppgifter, där en enhet av driftstopp resulterar i stora förluster, till exempel för faktureringssystem. Följande regel kan rekommenderas för att avgöra var det är rimligt att använda kluster: där stilleståndstiden för en tjänst inte bör överstiga en och en halv timme är ett kluster en lämplig lösning. I andra fall kan du överväga billigare alternativ.
Kluster (grupp av datorer)
Principen för deras funktion är baserad på distributionen av förfrågningar genom en eller flera ingångsnoder, som omdirigerar dem för bearbetning till de återstående datornoderna. Det initiala målet för ett sådant kluster är prestanda, men de använder ofta också tekniker för att förbättra tillförlitligheten. Sådana strukturer kallas serverfarmar. Programvaran kan vara antingen kommersiell (OpenVMS, MOSIX, Platform LSF HPC, Solaris Cluster, Moab Cluster Suite, Maui Cluster Scheduler) eller gratis (OpenMosix, Sun Grid Engine, Linux Virtual Server).
Kluster används för beräkningsändamål, särskilt inom vetenskaplig forskning. För datorkluster är viktiga indikatorer hög processorprestanda i flyttalsoperationer (flops) och låg latens hos det anslutande nätverket, och mindre signifikanta är hastigheten för I/O-operationer, vilket är viktigare för databaser och webbtjänster. Datorkluster gör det möjligt att minska beräkningstiden jämfört med en enskild dator genom att dela upp uppgiften i parallellt exekverande grenar som utbyter data över ett sammankopplat nätverk. En typisk konfiguration är en samling datorer som är sammansatta av allmänt tillgängliga komponenter, som kör operativsystemet Linux och anslutna via Ethernet, Myrinet, InfiniBand eller andra relativt billiga nätverk. Ett sådant system brukar kallas ett Beowulf-kluster. Högpresterande kluster är speciellt identifierade (betecknas med den engelska förkortningen HPC-kluster - Högpresterande datorkluster). Lista över de mest kraftfulla högpresterande datorerna (kan också betecknas med den engelska förkortningen HPC) finns på världsrankingen TOP500. Ryssland har en klassificering av de mest kraftfulla datorerna i OSS.
Sådana system betraktas vanligtvis inte som kluster, men deras principer liknar till stor del klusterteknologi. De kallas också rutsystem. Huvudskillnaden är den låga tillgängligheten för varje nod, det vill säga omöjligheten att garantera dess drift vid en given tidpunkt (noder är anslutna och frånkopplade under drift), därför måste uppgiften delas upp i ett antal processer oberoende av varje nod. andra. Ett sådant system, till skillnad från kluster, är inte som en enda dator, utan fungerar som ett förenklat sätt att distribuera beräkningar. Instabiliteten i konfigurationen, i detta fall, kompenseras av ett stort antal noder.
Klustersystem intar en värdig plats i listan över de snabbaste, samtidigt som de överträffar superdatorerna i pris. Från och med juli 2008 är SGI Altix ICE 8200-klustret (Chippewa Falls, Wisconsin, USA) på 7:e plats i TOP500-klassificeringen.
Ett relativt billigt alternativ till superdatorer är kluster baserade på Beowulf-konceptet, som är byggda av vanliga billiga datorer baserade på fri programvara. Ett praktiskt exempel på ett sådant system är Stone Soupercomputer (Oak Ridge, Tennessee, USA).
Det största privatägda klustret (1000 processorer) byggdes av John Koza.
Historien om skapande av kluster är oupplösligt kopplad till den tidiga utvecklingen inom området datornätverk. En av anledningarna till uppkomsten av höghastighetskommunikation mellan datorer var hoppet om att slå samman datorresurser. I början av 1970-talet. Utvecklingsgruppen för TCP/IP-protokoll och Xerox PARC-laboratoriet etablerade nätverksstandarder. Operativsystemet Hydra dök också upp för PDP-11-datorer tillverkade av DEC, klustret som skapades på denna grund fick namnet C.mpp (Pittsburgh, Pennsylvania, USA). Det var dock inte förrän runt 1999 som mekanismer skapades för att göra det enkelt att distribuera uppgifter och filer över ett nätverk, mestadels från SunOS (ett BSD-baserat operativsystem från Sun Microsystems).
Det första kommersiella klusterprojektet var ARCNet, skapat av Datapoint i staden. Det blev inte lönsamt, och därför utvecklades inte byggandet av kluster förrän DEC byggde sitt VAXcluster baserat på operativsystemet VAX/VMS. ARCNet och VAXcluster designades inte bara för gemensam beräkning, utan också för att dela filsystemet och kringutrustning, med hänsyn till att data integritet och otvetydighet bibehålls. VAXCluster (nu kallat VMSCluster) är en integrerad komponent i OpenVMS-operativsystemet som använder Alpha- och Itanium-processorer.
Två andra tidiga klusterprodukter som fick erkännande inkluderar Tandem Hymalaya (HA-klass) och IBM S/390 Parallel Sysplex (1994).
Historien om att skapa kluster från vanliga persondatorer har mycket att göra med Parallel Virtual Machine-projektet. Denna programvara för att ansluta datorer till en virtuell superdator öppnade upp möjligheten att omedelbart skapa kluster. Som ett resultat överträffade den totala prestandan för alla billiga kluster skapade vid den tiden summan av kapaciteten hos "seriösa" kommersiella system.
Skapandet av kluster baserade på billiga persondatorer anslutna till ett dataöverföringsnätverk fortsatte i staden av American Aerospace Agency (NASA), sedan utvecklades Beowulf-kluster, speciellt designade utifrån denna princip, i staden. Framgången för sådana system sporrade utvecklingen av nätnätverk, som har funnits sedan UNIX skapades.
Ett allmänt använt verktyg för att organisera kommunikation mellan servrar är MPI-biblioteket, som stöder språk och Fortran. Den används till exempel i vädermodelleringsprogrammet MM5.
Operativsystemet Solaris tillhandahåller programvaran Solaris Cluster, som ger hög tillgänglighet och tillgänglighet för servrar som kör Solaris. Det finns en implementering för OpenSolaris med öppen källkod kallad OpenSolaris HA-kluster.
Flera program är populära bland GNU/Linux-användare:
Klustermekanismer är planerade att byggas in i DragonFly BSD-kärnan, som splittrades 2003 från FreeBSD 4.8. Långsiktiga planer inkluderar också att förvandla det till enhetlig operativsystemmiljö.
Microsoft producerar ett HA-kluster för Windows-operativsystemet. Det finns en åsikt att den skapades baserat på Digital Equipment Corporation-teknologi, stöder upp till 16 (sedan 2010) noder i ett kluster, samt drift i ett SAN (Storage Area Network). En uppsättning API-gränssnitt används för att stödja distribuerade applikationer. Det finns förberedelser för att arbeta med program som inte tillåter arbete i ett kluster.
Windows Compute Cluster Server 2003 (CCS), som släpptes i juni 2006, är designad för avancerade applikationer som kräver klusterberäkning. Publikationen är designad för distribution på många datorer som är sammansatta i ett kluster för att uppnå kraften hos en superdator. Varje kluster på Windows Compute Cluster Server består av en eller flera mastermaskiner som distribuerar uppgifter och flera slavmaskiner som utför huvudarbetet. I november 2008 introducerades Windows HPC Server 2008, designad för att ersätta Windows Compute Cluster Server 2003.
