Endast feltoleranta och pålitliga servrar. Konfigurera en extern datamatris. Installerar Oracle RAC

Andrey Biryukov

Utöka klustret till Windows baserad Server 2003

Failover-kluster är utbredda i medium till medium stora företag... Men för många administratörer väcker implementeringen och underhållet av klustersystem fortfarande många frågor. Tänk på genomförandet failover-kluster baserad på Windows Server 2003.

Komma igång

En av de nödvändiga förutsättningarna för att en stor organisations nätverk ska fungera stabilt är feltolerans. Även ett litet misslyckande kan leda till mycket obehagliga konsekvenser.

Så, till exempel, under en omstart av e-postservern på höjden av arbetsdagen, kommer företagets anställda att få felmeddelanden och, som regel, ringa företagets tekniska supporttjänst, vilket bidrar till systemadministratörernas arbete.

Detta är särskilt obehagligt när ledningen informerar om att post eller någon annan tjänst inte är tillgänglig. Du kan undvika dessa problem genom att använda failover-kluster.

Ett serverkluster är en grupp oberoende noder som interagerar som ett system. De använder gemensam bas klusterdata som möjliggör återställning i händelse av något nodfel.

Dessa lösningar kan vara både hårdvara och mjukvara. Valet beror på storleken på din organisation, affärskritiska applikationer och naturligtvis den budget som avsatts för IT-infrastrukturen.

I min artikel kommer jag att överväga en mjukvaruimplementering av ett tvånodskluster baserat på Microsofts tjänster Klustringstjänst. Denna lösning är mest lämplig för medelstora organisationer med en liten IT-budget.

Först och främst kommer jag att ställa ett problem till lösningen som denna artikel kommer att ägnas åt.

Vi har två servrar med identisk hårdvara. Identitetskrav är valfritt, men det är önskvärt att kraften hos servrarna är liknande.

Du måste kombinera dem till ett failover-kluster. Som ett exempel på att konfigurera en motståndskraftig resurs kommer jag att konfigurera fildelningstjänsten.

Vi kommer att prata mer om typerna av klustrade resurser lite senare.

Om upplagor och licenser

Innan vi börjar beskrivningen av processen för att installera och konfigurera klustret måste vi bestämma oss för utgåvorna operativ system ska användas och även överväga licensfrågor.

När du bygger ett kluster, kom ihåg att de vanligaste Windows utgåva Server 2003 Standard stöder inte klustring.

Därför bör du använda Windows Server 2003 Enterprise Edition när du bygger ett feltolerant system.

Enterprise-utgåvan ska förresten även användas när man bygger kluster för Microsoft Exchange och Microsoft SQL Server 2000. Annars kommer du inte att kunna klustra post och databaser.

När det gäller licensfrågor måste du köpa en serveroperativsystemlicens för varje klusternod. Plus Client Access Licenses (CALs) i samma mängd som för en enskild server.

Låt mig förklara med ett exempel. Om du har 250 användare i din organisation och distribuerar ett kluster med två noder, måste du köpa två Windows Server 2003-serverlicenser och 250 CAL:er.

Antalet noder i klustret påverkar alltså inte antalet CAL:er.

Nya koncept

För att bättre förstå begreppet klustring kommer vi att titta på några grundläggande begrepp.

Ett failover-kluster består vanligtvis av fyra noder som delar en diskresurs för kommunikation. Denna resurs kallas också en kvorumenhet.

Helst bör denna kvorumenhet vara en separat hårdvarulagring med sin egen feltolerans (RAID 1, RAID 5-diskar) som ansluter till alla klusternoder.

Liknande lösningar finns tillgängliga från IBM, EMC och andra leverantörer.

Men i fallet med begränsad finansiell kapacitet företag, för att skapa en kvorumenhet kan du använda en disk på en delad SCSI-buss ansluten till alla klusternoder.

Ett kluster innehåller två olika typer av nätverk: ett privat nätverk, som används för att upprätthålla anslutningar mellan klusternoder, och ett nätverk allmänt bruk(lokalt nätverk) som används av klienter i ett kluster för att ansluta till tjänster i det klustret. Båda dessa nätverk kan dela ett nätverkskort och en fysisk anslutning, men det är bättre att hålla dem åtskilda.

Eftersom kopplingen mellan klusternoder är en potentiell felpunkt måste den alltid vara redundant.

Om två nätverksgränssnitt används, om ett av dem misslyckas, kommer administratören att kunna göra det särskilda insatser växla till att använda den andra. Dessutom ökar användningen av två gränssnitt hastigheten på datautbytet och ökar i slutändan hastigheten för hela klustret som helhet.

Nästa viktiga koncept för klustring är grupper.

Grupper är block för failover. Varje grupp innehåller en eller flera resurser. Om någon av resurserna inom en grupp misslyckas, kommer hela gruppen att misslyckas tillsammans enligt policyn för frånkoppling av failover som definierats för den gruppen.

En grupp kan bara tillhöra en nod åt gången. Om någon resurs inom en grupp misslyckas måste den flyttas till en alternativ nod tillsammans med alla andra resurser i denna grupp.

När orsaken till felet i källnoden är löst, överförs hela gruppen tillbaka till den ursprungliga noden i enlighet med återställningspolicyn för den gruppen.

Resurser är allt

Nästa koncept är resurser - logiska eller fysiska element som kan kopplas eller kopplas bort från nätverket.

V Windows-system Server 2003 Enterprise Edition innehåller flera olika resurstyper:

• Fysisk disk;
• DHCP;
• VINNER;
• Utskriftshanterare;
• Fildelning;
• Internetprotokolladress;
• Lokalt kvorum;
• Majoritetsnoduppsättning;
• Nätverksnamn;
• Generisk applikation;
• Generiskt skript;
• Generisk tjänst.

Några ord om varje typ av resurs.

Den fysiska disken används för kvorumresursen. Krävs för alla servrar i klustret.

DHCP och WINS används som en klusterresurs för att tillhandahålla feltolerans för dessa tjänster.

Print Spooler låter dig klustera utskriftstjänster.

Resurstypen File Share låter dig hantera delade filsystem på tre olika sätt:

• Standard fildelning när endast mappen är synlig högsta nivån representeras av det delade namnet.
• Med delade undermappar när toppnivåmappen och var och en av dess omedelbara undermappar exponeras för delad åtkomst med olika namn.
• Dfs (Distributed File System) autonom rot. Du kan dock inte använda en Cluster Server File Share som en del av en failover Dfs-rot.

Internetprotokolladressen och nätverksnamnet används för att skapa en virtuell server som tillåter klienter att använda samma namn för att komma åt klustret även efter övergången till att inaktivera failover.

Resursen Local Quorum används för att hantera systemdisken på klustrets lokala nod.

Majority Node Set används för att hantera konfigurationen av klusterdata, som kan placeras i klustrets minne eller utanför denna enhet. Används för att stämma av data mellan geografiskt spridda enheter.

Resurstypen Generic Application låter dig hantera vanliga applikationer i klustret som inte känner igen deras närvaro i klustret.

Generiskt skript - Hantera operativsystemskript som en klustrad resurs.

Generisk tjänst – låter dig hantera Windows Server 2003-tjänster som klusterresurser.

Vikten av planering

Stabil klusterdrift kräver planering i förväg vilka applikationer som ska köras och att välja exakt vilka applikationer du kan leva utan och vilka applikationer som ska stödjas under alla omständigheter.

Först måste du bestämma antalet grupper eller virtuella servrar.

Applikationer och resurser som är i samma grupp kommer att överföras efter avstängning till en server. Det vill säga att du måste bestämma vilka applikationer som är beroende av varandra och de måste fungera tillsammans.

Innan du börjar distribuera ett kluster måste du därför lista alla applikationer i din miljö, tydligt definiera vilka av dem som får misslyckas och vilka som kräver en failover.

Observera att en resurs inte kan sträcka sig över grupper, så om flera applikationer är beroende av en resurs måste de finnas i samma grupp eller i samma virtuell server då kommer samma principer för avstängning och återställning att användas.

Jag kommer att ge ett litet exempel på att bygga ett beroendeträd för en filresurs.

Uppenbarligen beror denna resurs på den fysiska disken, eftersom det är huvudresursen som används av alla noder i klustret. Vidare är nätverksnamnet Nätverksnamn viktigt för de delade resurserna. Men i sin tur kan nätverksnamnet inte användas utan IP-adressen.

Således får vi följande beroenden: File Share-resursen beror uttryckligen på den fysiska disken och nätverksnamnet och implicit på IP-adressen.

Om du glömmer att ange något beroende kommer du att få ett felmeddelande under installationen av resursen.

Avslutningsvis planeringsämnet vill jag påminna dig om att var och en av klusternoderna måste ha tillräcklig kraft och inte överbelastas med ytterligare, icke-klustrade applikationer, eftersom om resursmastern efter bytet visade sig vara mindre kraftfull server, kommer detta definitivt att påverka applikationernas prestanda och eventuellt leda till krascher.

Installation

Efter att ha diskuterat detaljerna för implementeringen av Microsoft Cluster Service, låt oss fortsätta direkt till implementeringen.

Installera först och främst Windows Server 2003 Enterprise Edition på var och en av noderna.

Själva installationsprocessen är standard och det är ingen idé att beskriva den i artikeln. Det enda som är värt att nämna är IP-adressering. Det är nödvändigt att omedelbart ställa in fasta adresser så att det senare inte blir några anslutningsproblem.

Efter lyckad installation måste du ge namn till var och en av klusternoderna. För enkelhetens skull, låt oss kalla noderna Node1 och Node2.

I nästa fönster måste du ange namnet på domänen där noderna finns, samt namnet på klustret (se fig. 1).

Om kontrollen av alla objekt lyckades, måste du i nästa fönster ange IP-adressen för klustret.

Då måste du specificera konto under vilken klustret kommer att lanseras. Det kan vara ett befintligt eller nytt konto. Till den givna användaren rättigheter kommer att beviljas lokal administratör på alla klusternoder.

Slutligen, gå vidare till sista sidan, som visar data för bekräftelse. Här kan du ange en kvorumenhet, som visas i fig. 3.

Genom att klicka på "Nästa" startar processen med att installera klustret, som liknar den redan beskrivna analysen av konfigurationen.

Efter lyckad installation bör administrationsfönstret för det nya klustret vi skapade öppnas för vidare arbete.

Arbeta med buggar

När du installerar ett kluster kan du uppleva olika problem... Jag kommer att beskriva lösningen på några av dem. Vanligtvis identifieras de flesta problem under analysfasen av klusterkonfigurationen. I fig. 4 visar hur detta kan se ut.

Som du kan se avslöjade analysen två fel, eller snarare problem. Eftersom fältet Task Completed är grönt kan du fortsätta med installationen, men det är bäst att lösa problemen först.

Så vad hittades i processen för att analysera systemet:

• Ingen kvorumenhet hittades. Som diskuterats tidigare är det en SCSI-disk som används av alla noder i klustret. Om du får ett sådant meddelande, kontrollera att servrarna är korrekt anslutna till SCSI-bussen. Kontrollera även tillgänglighet denna disk i avsnittet "Administrativa verktyg -> Datorhantering -> Diskhantering».
• Endast en nätverksadapter hittades på servern. Majoritet industriella servrar har två nätverkskort, så detta är ett ganska sällsynt fel. Men om det visas är det nödvändigt att kontrollera prestandan för den andra adaptern. Om du bara vill använda ett gränssnitt, använd beskrivningen från avsnittet "Lägga till noder".

Ett annat fel som dyker upp under analysen är den dynamiska tilldelningen av IP-adresser till nätverksadaptrar. Som jag nämnde, under installationsprocessen måste du tilldela statiska adresser nätverkskort.

För att identifiera mer komplexa misstag du kan använda knappen "Visa logg" för att se den detaljerade händelseloggen.

Lägger till noder

Nu måste du lägga till noden i klustret. Men låt oss först göra några ytterligare inställningar. I konsolen för klusteradministration, välj "Klusterkonfiguration" och sedan "Nätverk" (se fig. 5).

Varje klusternod har två nätverksgränssnitt, varav ett är anslutet till lokalt nätverk(LAN), och den andra används för kommunikation mellan klusternoder (Heartbeat).

Öppna fliken Egenskaper för vart och ett av dessa nätverksgränssnitt ett i taget.

För LAN i egenskaperna måste du ange "Endast klientåtkomst (endast offentligt)", och för Heartbeat, välj "Endast intern klusterkommunikation (privat nätverk)".

Så nu kommer vårt LAN-gränssnitt endast att användas för extern kommunikation, och Heartbeat - endast för utbyte av information mellan klusternoderna. Detta gör att du kan öka hastigheten på systemet som helhet.

Glöm bara inte att också avgränsa segmenten med nätverkslager... Det vill säga, segmentet som innehåller Heartbeat-anslutningar måste anslutas till en separat switch eller hubb (inte till densamma fysiskt nätverk som LAN!) av säkerhets- och tillförlitlighetsskäl.

V I detta fall att använda en hubb kan till och med vara att föredra, eftersom den inte innehåller en cache med MAC-adresser, och Heartbeat-nätverket i detta fall används endast för att kontrollera tillgängligheten av noder och välja en ny i händelse av fel.

Om du bara vill använda ett gränssnitt, ange sedan intern och klientåtkomst i egenskaperna LAN och Heartbeat. I det här fallet kommer både LAN och Heartbeat att innehålla ett fysiskt gränssnitt.

Så vi har optimerat inställningarna för nätverksgränssnitten för klusternoden och nu går vi vidare till nästa steg - att lägga till den andra noden. För att göra detta, på den andra servern, kör också "Administrativa verktyg -> Cluster Administrator".

Först nu väljer vi "Lägg till noder till kluster" och anger namnet på klustret.

I nästa steg skriver vi namnet på servern som ska användas i klustret.

Sedan startar analysen av konfigurationen. Om analysen slutförs utan allvarliga fel, anger vi i nästa steg kontot som användes när klustret skapades. Därefter installeras klustertjänsterna på den andra servern. Se det erhållna resultatet i fig. 6.

Detta är i själva verket själva processen för att installera klustrets ändar. Om du behöver lägga till fler noder räcker det att göra ovanstående operationer för att lägga till en server.

Sätta upp resurser

Nu behöver du koppla ihop resurserna som kommer att användas i vårt kluster.

Som nämndes i början av den här artikeln kommer vi att ställa in resurser för fildelningstjänsten.

För att göra detta kommer vi först att skapa ny grupp på den virtuella servern HEM.

Innan du skapar en grupp måste du bestämma var den befinner sig. Du kan naturligtvis lägga resurser i huvudgruppen Clusters, men det är bättre att omedelbart gruppera dem efter deras syfte. Detta är desto mer så eftersom inaktiverande failover-policyer hanteras på gruppnivå.

Därför måste du göra följande för att skapa vår resurs av typen File Share:

• skapa en grupp som kommer att innehålla de nödvändiga resurserna;
• skapa en resurs av typen Physical Disk;
• skapa en resurs av typen IP-adress;
• skapa resurs av typen Nätverk Namn;
• skapa en resurs av typen File Share.

Låt oss börja med att skapa en klustergrupp.

För att göra detta, i klusteradministratörskonsolen, klicka på mappen Aktiva grupper för servern som kommer att vara värd för fildelningsresursen och välj Grupp på menyn Ny. Fönstret New Group Wizard kommer att visas (se figur 7).

I nästa fönster måste du ange de föredragna ägarna till de föredragna ägarna. Flera noder kan anges här, beroende på deras preferenser.

Till exempel är det ganska logiskt att ange de mest kraftfulla och minst belastade klusternoderna i början av listan.

I vårt fall måste du välja en nod och klicka på "Lägg till", lägg sedan till Nod 2 på samma sätt. Efter att ha klickat på knappen "Slutför" kommer gruppen att skapas.

Men märk att hon är med nu autonom stat eftersom det inte finns några aktiva resurser kopplade till det.

Nu är det dags att skapa en resurs av typen Physical Disk. För att göra detta, högerklicka på den nyskapade gruppen och välj "Resurs".

Fyll i fälten Namn och Beskrivning och välj Fysisk disk från rullgardinsmenyn Resurstyp.

I nästa steg, ange möjliga ägare till de möjliga ägarna. Här måste du ange de maskiner som kan innehålla denna resurs (Node1, Node2).

I nästa steg anger vi parametrarna för disken (Disk Parameters). Listrutan visar alla resurser av typen fysisk disk som kan hanteras av klustertjänsten.

Uppmärksamhet bör ägnas åt det faktum att denna tjänst bara kan hantera grundläggande diskar men inte dynamiska, och alla partitioner på den här disken som används av klustertjänsten måste formateras som NTFS.

När du har angett enheten klickar du på knappen "Slutför" för att skapa den här resursen.

På tredje plats i listan måste vi skapa en resurs av typen IP-adress.

I analogi med föregående avsnitt, välj objektet "Resurser" i vår grupp, sedan - "Ny". Vi anger typen av resurs - IP-adress, sedan - de möjliga ägarna.

I nästa fönster, beroenden, bör den fysiska diskresurs som vi redan har skapat visas. Men du behöver inte välja det, eftersom det i det här fallet inte finns något beroende.

På nästa sida måste du ange inställningarna för IP-adressen. Klicka sedan på "Slutför".

Låt oss skapa en resurs av typen Nätverksnamn. För att göra detta måste du återigen göra alla de åtgärder som vi utförde tidigare för andra typer av resurser.

Men i avsnittet Beroenden måste du nu ange beroendet av IP-adressresursen.

Låt oss gå vidare till det sista steget i att skapa en klustrad filresurs.

Låt oss upprepa samma steg, men när du anger beroenden måste du välja alla tre objekten i listan.

I avsnittet Avancerat kan du ange om de delade underkatalogresurserna ska döljas.

Den delade resursen har skapats.

Observera att fildelningen som standard har skrivskyddad behörighet. Du kan ändra den här inställningen i fönstret Fildelningsparametrar.

Så vi fick en failover-resurs i klustret och ökade därmed tillgängligheten av filresurser med hjälp av Microsoft-kluster.

Kluster i virtuell verklighet

Den senaste tiden mer och mer bred användning skaffa virtuella maskiner.

Bland annat är virtuella maskiner extremt bekväma för utveckling och testning. olika system, utbildning och demonstration.

Dessa egenskaper är särskilt användbara när man arbetar med klustersystem, eftersom en fullfjädrad hårdvaruimplementering kräver vissa, ofta betydande, finansiella kostnader. Och med ett virtuellt kluster kan du testa ditt system eller förbereda dig för ett certifieringsprov utan extra kostnad.

Till exempel, för att distribuera ett tvånodskluster baserat på VMware, behövde jag en arbetsstation med 1 GB random access minne... Och inga externa SCSI-enheter, brusiga servrar eller annan hårdvara.

Så, om du är intresserad av implementeringen av kluster baserade på virtuella VMware-maskiner, då rekommenderar jag att du hänvisar till artikeln.

Slutsats

Så vi distribuerade ett failover-kluster med två noder och satte upp filresursen.

En av de vanligaste användningsområdena för Microsoft Cluster Services är klustring e-postservrar MS Exchange.

I nästa artikel kommer jag att titta närmare på processen för att installera och konfigurera ett motståndskraftigt e-postmeddelande Microsoft system Utbyta.

1. Russell C. Microsoft Windows Server 2003. Administratörsguide.
2. Berezhnoy A. Vi bygger en nätverksinfrastruktur baserad på VMware Server. // Systemadministratör, nr 3, 2007 - s. 14-18.
3. En artikel om att distribuera ett kluster på VMware - http://www.rootpermissions.net/Files/MS_Windows_2003_Cluster_on_VMware_GFX_3.rar.

I kontakt med

Hej alla idag, jag ska berätta för er hur man ställer in ett Hyper-V failover-kluster i Windows Server 2012 R2. Låt mig påminna dig om att vi redan har övervägt samma sak för Hyper-V i Windows Server 2012 R2.

Redan på planeringsstadiet av den framtida virtuella infrastrukturen bör man tänka på att säkerställa hög tillgänglighet dina virtuella maskiner. Även om en tillfällig otillgänglighet för en av servrarna fortfarande kan vara acceptabel i en normal situation, kommer en betydande del av infrastrukturen att vara otillgänglig om Hyper-V-värden slutar. I detta sammanhang ökar administrationens komplexitet dramatiskt - det är nästan omöjligt att stoppa eller starta om en värd under kontorstid, och i händelse av ett hårdvarufel eller mjukvarufel kommer vi att få en nödsituation på företagsnivå.

Allt detta kan på allvar dämpa entusiasmen för fördelarna med virtualisering, men det finns en utväg och den ligger i att skapa ett kluster med hög tillgänglighet. Vi har redan nämnt att begreppet "feltålig" inte är helt korrekt och därför används i dag alltmer en annan egenskap, som mer korrekt återspeglar sakernas tillstånd - "högt tillgänglig".

För att skapa ett fullfjädrat feltolerant system krävs att man eliminerar eventuella felpunkter, vilket i de flesta fall kräver seriösa ekonomiska investeringar. Samtidigt tillåter de flesta situationer vissa felpunkter, om det är billigare att eliminera konsekvenserna av deras misslyckande än att investera i infrastruktur. Du kan till exempel välja bort dyr, feltolerant lagring till förmån för två billiga servrar med tillräckligt många hinkar, varav en är konfigurerad för kall reserv, i händelse av fel på den första servern, ordnar vi helt enkelt om diskarna och sätter på den andra.

I den här artikeln kommer vi att överväga den enklaste konfigurationen av ett failover-kluster som består av två noder (noder) SRV12R2-NODE1 och SRV12R2-NODE2, som var och en kör Windows Server 2012 R2. En förutsättning för dessa servrar är användningen av processorer från samma tillverkare, endast Intel eller endast AMD, annars kommer migreringen av virtuella maskiner mellan noder inte att vara möjlig. Varje nod måste vara ansluten till två nätverk: ett företags-LAN och ett SAN.

Den andra förutsättningen för att skapa ett kluster är närvaron av en utplacerad Active Directory, i vårt diagram representeras den av domänkontrollanten SRV12R2-DC1.

Lagringen är gjord med iSCSI-teknik och kan implementeras på vilken lämplig plattform som helst, i detta fall är det en annan server på Windows Server 2012 R2 - SRV12R2-STOR. Lagerservern kan anslutas till företagsnätverket och vara medlem i domänen, men detta krävs inte. SAN-bandbredden måste vara minst 1 Gbps.

Nästa steg är att lägga till komponenten Failover-klustring.

På sidan för att konfigurera virtuella switchar väljer du nätverksadaptern som är ansluten till företagsnätverket.

Migrera virtuella maskiner sluta.

Lämna resten av parametrarna oförändrade. Att installera Hyper-V-rollen kräver en omstart, varefter vi konfigurerar den andra noden på samma sätt.

Låt oss sedan gå till lagringsservern, hur man konfigurerar iSCSI-lagring till Windows baserad Vi pratade om Server 2012 i den här artikeln, men detta är inte grundläggande, du kan använda vilken iSCSI-målserver som helst. För att klustret ska fungera korrekt måste vi skapa minst två virtuella diskar: en kvorumvittnesdisk och en disk för att lagra virtuella maskiner. Diskvittnet är en tjänstresurs för klustret, inom ramen för denna artikel kommer vi inte att beröra dess roll och funktionsmekanism, för det räcker att välja minsta storlek, i vårt fall 1GB.

Skapa nytt mål iSCSI och ge åtkomst till det för två initiatorer, som kommer att vara klusternoderna.

Och matcha de skapade virtuella diskarna till detta mål.

Efter att ha konfigurerat lagringen, låt oss gå tillbaka till en av noderna och ansluta diskarna från lagringen. Kom ihåg att om lagringsservern också är ansluten till det lokala nätverket, när du ansluter till iSCSI-målet, ange för åtkomst lagringsnätverk.

Vi initierar och formaterar de anslutna diskarna.

Sedan går vi till den andra noden och ansluter också skivorna, du behöver inte längre formatera dem, vi tilldelar dem bara samma bokstäver och volymetiketter. Detta är valfritt, men det är tillrådligt att göra för enhetligheten i inställningarna, när identiska diskar på alla noder har samma beteckningar, blir det förvirrande och det är mycket svårare att göra ett misstag.

Då öppnar vi Hyper-V Manager och gå vidare till att konfigurera virtuella switchar. Deras namn på båda noderna ska matcha exakt.

Vi är nu redo att skapa ett kluster. Låt oss köra snap-in Failover Cluster Manager och välj åtgärd Kontrollera konfigurationen.

I guidens inställningar, lägg till noderna vi konfigurerade och välj exekveringen av alla tester.

Kontroller tar avsevärt lång tid, om några fel uppstår måste de korrigeras och kontrollen upprepas.

Om inga betydande fel hittas avslutas guiden och den kommer att erbjuda dig att skapa ett kluster på de valda noderna.

Men om kontrollen genererade varningar råder vi dig att studera rapporten och ta reda på vad denna varning påverkar och vad som behöver göras för att eliminera den. I vårt fall varnade guiden oss för frånvaron av redundans i klusternätverksanslutningarna, som standard använder klustret inte iSCSI-nätverk, vilket är lätt att fixa senare.

När du skapar ett kluster skapas ett virtuellt objekt för det, som har nätverksnamn och adress. Vi anger dem i den öppnade Klusterguide.

Inga fler frågor kommer att följa och guiden kommer att informera oss om att klustret har skapats samtidigt som den utfärdar en varning om frånvaron av en vittnesskiva.

Stäng guiden och expandera trädet till vänster till nivån Lagring - Diskar, v tillgängliga åtgärder till höger väljer vi Lägg till skiva och ange vilka enheter som ska anslutas i fönstret som öppnas, i vårt fall finns det två av dem.

Högerklicka sedan på klusterobjektet i trädet till vänster och välj Ytterligare steg - Konfigurera kvoruminställningar på ett kluster.

Låt oss nu konfigurera lagringsdisken, allt är mycket lättare med den, högerklicka bara på disken och specificera: Lägg till i Cluster Shared Stores.

För att skivan ska kunna användas av flera klustermedlemmar samtidigt, a CSVFS- ett klusterfilsystem implementerat ovanpå NTFS, som först dök upp i Windows Server 2008 R2 och låter dig använda funktioner som Live (Live) migrering, dvs. överföring av en virtuell maskin mellan klusternoder utan att avbryta dess drift.

Delade arkiv blir tillgängliga på alla klusternoder på platsen C: \ ClusterStorage \ VolymN... Observera att dessa inte bara är mappar på systemdisk och fästpunkter delade volymer klunga.

När vi är klara med diskarna, låt oss gå till nätverksinställningarna, för detta går vi till avsnittet Nätverk... För ett nätverk som är anslutet till företagsnätverket, ange och Tillåt klienter att ansluta via detta nätverk... För SAN, låt oss bara gå Tillåt klustret att använda detta nätverk vilket ger den nödvändiga redundansen för nätverksanslutningar.

Detta slutför klusterinställningen. För att arbeta med klustrade virtuella maskiner, använd Failover Cluster Manager, men inte Hyper-V Manager, som är utformad för att hantera virtuella maskiner lokalt.

För att skapa en virtuell maskin gå till avsnittet Roller från högerklicksmenyn, välj Virtuella maskiner - Skapa en virtuell maskin, samma sak kan göras genom panelen Handlingar till höger.

Först och främst väljer du den värd som den virtuella maskinen ska skapas på. Varje virtuell maskin körs på en specifik klusternod och migrerar till andra noder när dess nod stannar eller misslyckas.

Efter att ha valt en nod öppnas standardguiden för skapande av virtuella maskiner, att arbeta med den är inte svårt, så vi kommer bara att fokusera på de viktiga punkterna. Som platsen för den virtuella maskinen nödvändigtvis ange en av de delade volymerna för kluster C: \ ClusterStorage \ VolymN.

Den bör också ligga här virtuellt hårt disk kan du också använda befintliga virtuellt hårt diskar, efter att ha kopierat dem tidigare till den delade lagringen.

När du har skapat den virtuella maskinen, gå till den alternativ och i paragraf Processorer - Kompatibilitet markera rutan Överför till en fysisk dator med en annan processorversion, kommer detta att tillåta migrering mellan noder med olika modeller processorer en tillverkare... Migrera från Intel till AMD eller vice versa omöjlig.

Gå sedan till Nätverksadapter - hårdvaruacceleration och se till att de valda alternativen stöds nätverkskort alla klusternoder, eller stäng av dem.

Glöm inte att anpassa automatiska åtgärder när du startar och stänger av en nod, med ett stort antal virtuella maskiner, glöm inte att ställa in en startfördröjning för att undvika överdriven belastning på systemet.

Avslutade med Parametrar gå till Egenskaper virtuell maskin och ange de föredragna värdarna för ägarna av denna roll i fallande ordning och prioritet, migreras maskinerna med högre prioritet först.

På ett bokmärke Failover ställ in antalet tillåtna fel för en virtuell maskin per tidsenhet, kom ihåg att ett fel inte bara betraktas som ett fel hos en värd, utan också en förlust av den virtuella maskinens hjärtfrekvens, till exempel dess frysning. Vid tidpunkten för installation och tester är det vettigt att ange större värden.

Konfigurera också Återställer placering, låter det här alternativet dig överföra virtuella maskiner tillbaka till den mest föredragna ägaren när den återställs till normal drift. Att undvika överdrivna belastningar använd alternativet för fördröjd återställning.

Detta slutför konfigurationen av den virtuella maskinen, vi kan börja och arbeta med den.

Nu är det dags att testa migreringen, för att göra detta högerklickar du på maskinen och väljer Flytta - Direktmigrering - Välj Nod... Den virtuella maskinen bör flytta till den valda noden utan att stängas av.

Hur sker migrering i en arbetsmiljö? Låt oss säga att vi måste stänga av eller starta om den första noden där den virtuella maskinen för närvarande körs. Efter att ha fått kommandot för att stänga av, initierar noden överföringen av virtuella maskiner:

Avstängningen avbryts tills alla virtuella maskiner har överförts.

När noden är igång kommer klustret, om platsåterställning är aktiverat, att vända processen och överföra den virtuella maskinen tillbaka till sin föredragna ägare.

Vad händer om värden som är värd för de virtuella maskinerna kraschar eller startar om? Alla virtuella maskiner kommer också att krascha, men kommer omedelbart att startas om på friska noder enligt listan över föredragna ägare.

Som vi redan har sagt är termen "feltolerant", som har slagit rot i den inhemska tekniska litteraturen, felaktig och det skulle vara mer korrekt att översätta det som "med failover", eller använda begreppet "hög tillgänglighet" , vilket återspeglar sakernas tillstånd mest korrekt.

Hyper-V-kluster ger inte feltolerans virtuella maskiner, gör ett nodfel att alla maskiner på den misslyckas, men det håller dina tjänster högt tillgängliga genom att automatiskt återställa dem och säkerställa minsta möjliga driftstopp. Det gör det också mycket enklare att administrera virtuell infrastruktur genom att du kan flytta virtuella maskiner mellan noder utan att avbryta deras arbete.

Huvudsyftet med artikeln är att visa hur man distribuerar ett failover-kluster. MS SQL Server 2012... Materialet är skrivet och kommer att vara intressant för nybörjare. Erfarna gurus och alla som redan är bekanta med det här problemet kommer sannolikt inte att hitta något nytt och användbart för sig själva personligen.

Utmaningen vi står inför är att tillhandahålla smidig drift och hög tillgänglighet för databasen i en klient-/serverdistribution.

Steg 1 - Förberedelser

Grundläggande krav för hårdvara och mjukvara:

• Närvaron av minst 2 noder (fysisk / virtuell), lagring
• MS Windows Server, MS SQL Server
• Lagring
  1. Tillgänglig iSCSI-enhet för databaser
  2. Tillgänglig iSCSI-enhet för MSDTC
  3. Quorum skiva

Testbänk:

• Windows Server 2012R2 med AD DS, DNS, DHCP-roller (WS2012R2AD)
• ISCSI-lagring *
• 2xWindows Server 2012R2 (för WS2012R2C1 och WS2012R2C2 kluster)
• Windows Server 2012R2 med en upphöjd 1C-servertjänst (WS2012R2AC)

* som ett alternativ kan du använda Repository-rollen på Windows Server 2012R2, mjukvarulösning från StarWind eller riktig iSCSI-nätverksenhet

Tekniskt sett kan du klara dig med 3 servrar genom att kombinera alla nödvändiga roller på domänkontrollanten, men detta rekommenderas inte i fält.

Först lägger vi till WS2012R2C1 och WS2012R2C2 till serverdomänen på var och en av dem, installerar rollen Failover Clustering
När du har installerat rollen startar du snapin-modulen Failover Cluster Manager och går till New Cluster Wizard där vi konfigurerar vårt failover-kluster: skapa kvorum ( delad resurs) och MSDTC (iSCSI).

Steg 2 - Installation av MS SQL Server

För att installera behöver vi installationsdistribution MS SQL Server. Låt oss starta installationsguiden och välj alternativet för att installera en ny klusterinstans:

Vi läser noggrant och accepterar licensavtalet:

Vi får tillgängliga uppdateringar:

Vi klarar konfigurationskontrollen (vi hoppar över Warning MSCS):

Vi väljer alternativet för det avsedda syftet med installationen:

Vi väljer de komponenter som vi behöver (det finns tillräckligt med grundläggande för uppgiften):

Ytterligare en kontroll av installationskonfigurationen:

Kontrollera tillgängligt utrymme:

Välj disken för platsen för klusterdatabaserna:

Konfiguration av klusternätverksgränssnitt (det rekommenderas att ange adressen manuellt):

Vi anger administratörens data (du kan skapa en separat användare för MSSQL):

Ett av de viktiga stegen är att det är extremt problematiskt att ändra valet av sorteringsordning (Sortering) efter installationen:

Autentiseringsparametrar på servern (i vårt fall valdes det blandade alternativet, även om det är säkrare att endast använda domänautentisering):

Val av kataloger för lagring av vanliga klusterfiler (i versioner av MS SQL Server 2012 och äldre kan TempDB lagras på varje nod och inte tas ut till den delade lagringen):

Ett par kontroller till:

Slutligen fortsätter vi med installationen (processen kan ta lång tid):

Konfigurationen och installationen av basnoden är klar, vilket indikeras av den "gröna" rapporten

Steg 3 - lägga till en andra nod till MSSQL-klustret

Därefter måste du lägga till en andra nod till klustret, eftersom utan det finns det ingen anledning att prata om feltolerans.
Att ställa in och installera är mycket enklare. På den andra servern (VM), kör installationsguiden för MS SQL Server:

• Vi klarar startprovet
• Ange licensnyckeln:
• Vi läser och accepterar licensavtalet:
• Vi får uppdateringar:
• Vi klarar testerna för att uppfylla kraven för att installera noden (MSCS-varning - hoppa över):

Välj vilket kluster du vill lägga till noden till:

Granska och acceptera nätverksinställningar klusterinstans:

Vi anger användaren och lösenordet (samma som i det första steget):

Återigen tester och installationsprocess:

När vi är klara bör vi få följande bild:

Grattis, installationen är klar.

Steg 4 - funktionskontroll

Låt oss se till att allt fungerar som det ska. För att göra detta, gå till snapin-modulen Failover Cluster Manager:

För tillfället använder vi den andra noden (WS2012R2C2) i händelse av fel, den kommer att byta till den första noden (WS2012R2C1).
Låt oss försöka ansluta direkt till MSSQL-serverklustret, för detta behöver vi vilken dator som helst i domännätverket med Management Studio MSSQL installerat. Vid start anger vi namnet på vårt kluster och användaren (eller lämnar domänauktorisering).

Den här artikeln visar dig hur du bygger ett Server 2012 tvånods failover-kluster. Jag kommer först att lista obligatoriska villkor och ge en översikt över hårdvarumiljön, nätverket och lagringsinställningarna. Sedan kommer det att detaljera hur man utökar Server 2012 med funktioner. failover-klustring och använd Failover Cluster Manager för att ställa in ett kluster med två noder

Det finns så många innovationer i Windows Server 2012 att det är svårt att hålla reda på dem alla. Några av de viktigaste byggstenarna i en ny IT-infrastruktur relaterar till förbättringar av failover-klustring. Failover Clustering har sitt ursprung som en teknik för skydd kritiska applikationer, nödvändigt för produktionsverksamhet som Microsoft SQL Server och Microsoft Exchange. Men därefter utvecklades Failover Clustering till en hög tillgänglighetsplattform för ett antal tjänster och Windows-applikationer... Failover Clustering är en del av grunden för Dynamic Datacenter och teknologier som Live Migration. Server 2012 och förbättringarna av det nya Server Message Block (SMB) 3.0-protokollet har utökat omfattningen av Failover Clustering för att tillhandahålla kontinuerligt tillgängliga filresurser från allmän tillgång... För en översikt av Failover Clustering-funktionaliteten i Server 2012, se artikeln "Vad är nytt i Windows Server 2012 Failover Clustering" i samma nummer av tidningen.

Förutsättningar för Failover Clustering

Att bygga ett Server 2012 tvånods failover-kluster kräver två datorer som kör Server 2012 Datacenter eller Standard. Det kan vara fysiska datorer eller virtuella maskiner. Kluster med virtuella värdar kan byggas med hjälp av Microsoft Hyper-V eller VMware vSphere. Den här artikeln använder två fysiska servrar, men stegen för att konfigurera klustret för fysiska och virtuella värdar är desamma. Huvudfunktionär att noderna måste konfigureras likadant så att standby-noden kan hantera arbetsbelastningen i händelse av en failover eller live-migrering. Komponenterna som används i test Server 2012 failover-klustret visas i figuren.

Server 2012 Failover Cluster kräver iSCSI, Serially Attached SCSI eller Fibre Channel SAN delad lagring. Vårt exempel använder ett iSCSI SAN. Tänk på följande funktioner för denna typ av lagring.

• Varje server måste ha minst tre nätverksadaptrar: en för att ansluta iSCSI-lagring, en för att kommunicera med klusternoden och en för att kommunicera med externt nätverk... Om du tänker använda klustret för livemigrering är det användbart att ha en fjärde nätverksadapter. Livemigrering kan dock göras externt också. nätverksanslutning– det kommer bara att gå långsammare. Om servrarna används för Hyper-V-baserad virtualisering och serverkonsolidering, då ytterligare nätverkskort för att överföra nätverkstrafik av virtuella maskiner.
• Snabba nätverk kommer alltid att fungera bättre, så hastigheten på iSCSI-länken bör vara minst 1 GHz.
• iSCSI-målet måste överensstämma med iSCSI-3-specifikationen, särskilt för att ge bestående redundans. Detta är ett obligatoriskt krav för levande migration. Nästan alla lagringsleverantörer har iSCSI 3-kompatibel hårdvara. Om du behöver konfigurera ett kluster i en lågkostnadslabbmiljö, se till att iSCSI-målmjukvaran uppfyller iSCSI 3-kraven och beständiga säkerhetskopieringskrav. Äldre versioner av Openfiler stöder inte denna standard, till skillnad från den nyare versionen av Openfiler med Advanced iSCSI Target Plugin (http://www.openfiler.com/products/advanced-iscsi-plugin). StarWind Softwares StarWind iSCSI SAN Free Edition (http://www.starwindsoftware.com/starwind-free) är dessutom helt kompatibel med Hyper-V och live-migrering. Vissa Microsoft versioner Windows Server kan också fungera som ett iSCSI-mål som är kompatibelt med standarderna iSCSI 3. Server 2012 inkluderar ett iSCSI-mål. Windows Storage Server 2008 R2 stöder iSCSI-målprogramvara. Du kan också ladda ner Microsoft iSCSI Software Target 3.3 (http://www.microsoft.com/en-us/download/details.aspx?id=19867) som fungerar med Windows Server 2008 R2.

För mer information om hur du konfigurerar iSCSI-lagring för ett failover-kluster, se sidofältet "Sample iSCSI Storage Configuration". För mer information om Failover Clustering-krav, se artikeln "Failover Clustering Hardware Requirements and Storage Options" (http://technet.microsoft.com/en-us/library/jj612869.aspx).

Lägga till failover-klustringsfunktioner

Det första steget för att skapa ett Server 2012 tvånods failover-kluster är att lägga till failover-klusterkomponenten med Server Manager. Serverhanteraren öppnas automatiskt när du loggar in på Server 2012. För att lägga till en failover-klusterkomponent, välj Lokal server och scrolla ned till avsnittet ROLLER OCH FUNKTIONER. I listrutan TASKS väljer du Lägg till roller och funktioner, som figur 1 visar. Detta startar guiden Lägg till roller och funktioner.

Den första sidan efter start av guiden öppnar välkomstsidan Före du börjar... Klicka på Nästa för att gå till sidan Välj installationstyp, som frågar om du vill installera funktionen lokalt eller i tjänsten Remote Desktop. För det här exemplet väljer du alternativet Rollbaserad eller funktionsbaserad installation och klickar på Nästa.

På sidan Välj destinationsserver väljer du den server på vilken klusterfunktionen för failover ska installeras. I mitt fall är detta en lokal server som heter WS2012-N1. Med din lokala server vald klickar du på Nästa för att fortsätta till sidan Välj serverroller. I det här exemplet är serverrollen inte installerad, så klicka på Nästa. Eller så kan du klicka på länken Funktioner i menyn till vänster.

På sidan Välj funktioner rullar du nedåt i listan med funktioner till Failover-kluster. Klicka i rutan framför Failover Clustering och du kommer att se en dialogruta som listar de olika komponenterna som kommer att installeras som en del av den komponenten. Som figur 2 visar kommer guiden som standard att installera Failover Cluster Management Tools och Windows PowerShell Failover Cluster Module. Klicka på knappen Lägg till funktioner för att återgå till sidan för val av funktioner. Klicka på Nästa.

Sidan Bekräfta installationsval visar failover-klusterfunktionen tillsammans med hanteringsverktyg och en PowerShell-modul. Från denna sida kan du gå tillbaka och göra eventuella ändringar. När du klickar på knappen Installera börjar den faktiska installationen av komponenterna. När installationen är klar slutförs guiden och klusterfunktionen för failover visas i avsnittet ROLLER OCH FUNKTIONER i Serverhanteraren. Denna process måste utföras på båda noderna.

Failover-klustervalidering

Efter att ha lagt till failover-klusterfunktionen är nästa steg att validera inställningarna för miljön där klustret skapades. Här kan du använda guiden Validera inställningar i Failover Cluster Manager. Den här guiden verifierar hårdvaru- och mjukvaruinställningarna för alla noder i klustret och rapporterar eventuella problem som kan förhindra klusterorganisation.

För att öppna Failover Cluster Manager, välj alternativet Failover Cluster Manager på menyn Verktyg i Server Manager. I hanteringsområdet klickar du på länken Validera konfiguration, som figur 3 visar, för att starta guiden Validera konfiguration.

Figur 3: Starta guiden Kontrollera konfiguration

Först visas guidens välkomstsida. Klicka på Nästa för att fortsätta till servervals- eller klustersidan. På den här sidan anger du namnen på noderna i klustret som du vill testa. Jag har specificerat WS2012-N1 och WS2012-N2. Klicka på Nästa för att visa sidan Testalternativ där du kan välja specifika testsviter eller köra alla tester. Åtminstone för första gången rekommenderar jag att du kör alla tester. Klicka på Nästa för att gå till en bekräftelsesida som visar de pågående testerna. Klicka på Nästa för att påbörja klustertestprocessen. Under testningen kontrolleras versionen av operativsystemet, nätverksinställningar och lagring av alla klusternoder. En sammanfattning av resultaten visas efter att testet är klart.

Om valideringstesterna körs framgångsrikt kan du skapa ett kluster. Figur 4 visar sammanfattningsskärmen för ett framgångsrikt testat kluster. Om fel upptäcks under valideringen kommer rapporten att markeras med en gul triangel (varningar) eller ett rött X för allvarliga fel. Varningarna bör läsas, men du kan ignorera dem. Allvarliga fel måste korrigeras innan klustret skapas.

Detta kommer att starta guiden för att skapa kluster, som börjar med välkomstsidan. Klicka på Nästa för att gå till sidan Välj servrar, som visas i figur 6. På den här sidan anger du namnen på alla noder i klustret och klickar sedan på Nästa.

På Åtkomstsida Punkt för administrering av klustret, du måste ange klusternamnet och IP-adressen, som måste vara unik på nätverket. I figur 7 kan du se att mitt klusternamn är WS2012-CL01 och min IP-adress är 192.168.100.200. När du använder Server 2012 kan kluster-IP tilldelas via DHCP, men jag föredrar en statiskt tilldelad IP för mina servrar.

När du har angett namn och IP-adress klickar du på Nästa för att se bekräftelsesidan (Figur 8). På den här sidan kan du kontrollera inställningarna som gjordes när du skapade klustret. Om det behövs kan du gå tillbaka och göra ändringar.

Efter att ha klickat på knappen Nästa på bekräftelsesidan, bildas ett kluster på alla valda noder. Förloppssidan visar stegen i guiden i processen att skapa ett nytt kluster. När den är klar visar guiden en sammanfattningssida med inställningarna för det nya klustret.

New Cluster Wizard väljer automatiskt lagring för kvorumet, men ofta väljer den fel kvorumenhet som administratören vill ha. För att kontrollera vilken disk som används för kvorum, öppna Failover Cluster Manager och expandera klustret. Öppna sedan lagringsnoden och klicka på noden Diskar. Diskarna som är tillgängliga i klustret kommer att visas i panelen Diskar. Disken som guiden valde för klustrets kvorum kommer att listas i Disksektion Vittne i kvorum.

I det här exemplet användes Cluster Disk 4 för kvorumet. Dess storlek är 520 MB, något mer än minimivärdet för ett kvorum på 512 MB. Om du vill använda en annan disk för klustrets kvorum kan du ändra klusterinställningarna genom att högerklicka på klusternamnet i Failover Cluster Manager, välja Fler åtgärder och Konfigurera klusterkvoruminställningar. Detta visar guiden Välj kvorumkonfiguration, som du kan använda för att ändra inställningarna för klustrets kvorum.

Konfigurera delade klustervolymer och virtuella maskinroller

Båda noderna i mitt kluster har Hyper-V-rollen eftersom klustret är för virtuella datorer med HA som tillhandahåller direktmigrering. För att förenkla direktmigrering är nästa steg att konfigurera CSV (Cluster Shared Volumes). Till skillnad från Server 2008 R2 är Cluster Shared Volumes aktiverade som standard i Server 2012. Du måste dock fortfarande ange vilken lagring som ska användas för klusterdelade volymer. För att aktivera CSV på en tillgänglig disk expanderar du lagringsnoden och väljer noden Diskar. Välj sedan klusterdisken som du vill använda som CSV och klicka på länken Lägg till i kluster delade volymer i fönstret Åtgärder i Failover Cluster Manager (Figur 9). Fältet Tilldelad till på denna klusterskiva ändras från tillgänglig lagring till klusterdelad volym, som figur 9 visar.

Under denna tid konfigurerar Failover Cluster Manager klusterdisklagringen för CSV, och lägger specifikt till en monteringspunkt till systemdisken. I det här exemplet ingår Cluster Shared Volumes på både Cluster Disk 1 och Cluster Disk 3 med följande monteringspunkter tillagda:

* C: ClusterStorageVolume1 * C: ClusterStorageVolume2

På detta stadium byggde ett server 2012-kluster med två noder och inkluderade delade klustervolymer. Du kan sedan installera klustrade applikationer eller lägga till roller i klustret. I det här fallet skapades klustret för virtualisering, så vi lägger till rollen som virtuell maskin till klustret.

Tillägga ny roll, välj klusternamnet i navigationsfönstret Failover Cluster Manager och klicka på länken Konfigurera roller i fönstret Åtgärder för att starta guiden för hög tillgänglighet. Klicka på Nästa på välkomstsidan för att gå till sidan Välj roll. Bläddra igenom listan med roller tills du ser rollen som den virtuella maskinen, som visas i figur 10. Välj en roll och klicka på Nästa.

Sidan Välj virtuell maskin listar alla virtuella datorer på alla noder i klustret, som visas i figur 11. Rulla ned och välj de virtuella datorer som du vill ge hög tillgänglighet. Klicka på knappen Nästa. När du har bekräftat ditt val klickar du på Nästa för att lägga till rollerna för den virtuella maskinen till Failover Cluster Manager.

Exempel för konfigurering av iSCSI Storage

För feltoleranta Windows-kluster Server 2012 kräver delad lagring, som kan vara iSCSI, Serially Attached SCSI eller Fibre Channel SAN. Detta failover-kluster använder ett kanal-SAN.

Först skapades tre LUN på iSCSI SAN. Ett LUN skapades för klustrets kvorumdisk (520 MB). En annan LUN är designad för 10 virtuella maskiner och är 375 GB stor. Den tredje LUN är tillägnad en liten virtuell testmaskin. Alla tre LUN är i NTFS-format.

Efter att LUN skapades konfigurerades iSCSI Initiator på båda Servernoder 2012. För att lägga till iSCSI-mål valdes iSCSI Initiator från menyn Verktyg i Serverhanteraren. På fliken Discovery klickade jag på knappen Discover Portal. Detta tar upp dialogrutan Discover Portal, där IP-adressen (192.168.0.1) och iSCSI-porten (3260) för SAN har angetts.

Sedan gick jag till fliken Mål och klickade på knappen Anslut. I dialogrutan Connect To Target angav jag målet iSCSI SAN-namnet. Den erhölls från SAN-fastigheter. Namnet beror på SAN-leverantören, domännamnet och de skapade LUN:erna. Förutom målnamnet ställer jag in läget Lägg till den här anslutningen till listan över favoritmål.

Efter att ha slutfört iSCSI-konfigurationen, dök dessa LUNs upp på fliken Targets i iSCSI Initiator. För att automatiskt återansluta LUN:erna när Server 2012 startar, såg jag till att de är listade under fliken Favoritmål, som visas i figur A.

Figur A. Konfigurera iSCSI-initiatorn

Slutligen brevmappades LUN:er med hjälp av Microsoft Management Console (MMC) Disk Management snapin. Jag valde Q för kvorumdisken och W för disken som används för virtuella klustermaskiner och delade volymer (CSV). Vid utnämning bokstavsbeteckningar du måste först tilldela dem till en nod. Sedan måste du överföra diskarna till offlineläge och gör liknande tilldelningar på den andra noden. Resultaten av för en nod visas i figur B. När klustret skapas visas diskarna som tillgänglig lagring.

Informationsteknologier utvecklas snabbt, om tidigare virtualisering och kluster var stora organisationers lott, blir dessa tekniker idag tillgängliga även för små företag. Virtualisering låter dig spara avsevärt på hårdvaruresurser, men ställer samtidigt mycket allvarligare krav på feltolerans, därför bör du, även på planeringsstadiet, vidta nödvändiga åtgärder för att säkerställa det. En sådan åtgärd är att skapa ett failover-kluster.

Till att börja med termen felsäker inte helt tillämplig på klusterlösningar, den uppkom som ett resultat av en felaktig översättning av termen failover-kluster... Korrekt översättning - med failover, även om idag en annan term används alltmer - hög tillgänglighet, vilket enligt vår mening mest korrekt återspeglar sakens väsen.

För att förstå varför klustret inte är feltolerant, låt oss titta närmare på dess struktur och driftschema. Låt oss genast klargöra att kluster inte bara används för att ge feltolerans, klusterscheman används också för lastbalansering eller tillväxt beräkningskraft... Däremot inom av detta material vi kommer att prata specifikt om högt tillgängliga kluster.

Det klassiska klusterschemat innehåller minst två noder och delad lagring ansluten via flera nätverksanslutningar.

För det första är det klustrets servicenät för signalöverföring hjärtslag, enligt vilket klustret övervakar tillståndet för dess noder (visas i rött på diagrammet), lagringsnätverk (SAN, blå), i billiga lösningar är detta oftast iSCSI via ett separat Ethernet-nätverk, men det kan också vara FibreChanell eller annan teknik. För att betjäna klienter är klustret anslutet till det befintliga lokala nätverket.

Enligt arbetsschemat kan noderna fungera i läget aktiv passiv eller aktiv-aktiv... I det första fallet betjänas alla klientförfrågningar av en av noderna, den andra noden kommer i drift endast när den första misslyckas. Det andra alternativet tillhandahåller bearbetning av klientförfrågningar av båda noderna, samtidigt som det också är möjligt att balansera belastningen och öka beräkningsresurserna genom att lägga till nya klusternoder. Om en av noderna misslyckas, behandlas klientförfrågningar av de återstående noderna.

En viktig punkt är att varje klientförfrågan betjänas av endast en av klusternoderna, och om den misslyckas kommer de anslutna klienterna att få ett överbelastningsskydd, men de kan omedelbart byta till de återstående tillgängliga noderna. Det är därför ett sådant schema inte är feltolerant, ett nodfel orsakar ett överbelastningsskydd, men klienten kan alltid ansluta till en annan fungerande nod, som implementerar bara serviceschemat med hög tillgänglighet.

Den uppmärksamma läsaren bör vara uppmärksam på förekomsten av en felpunkt i diagrammet ovan - en butik. För hög tillgänglighet måste lagring också vara feltolerant eller mycket tillgänglig. Detta kan implementeras både genom att köpa speciella hårdvarumodeller och av mjukvara, inklusive på basis av programvara med öppen källkod.

Om iSCSI används som lagring kan klusternätverket och SAN kombineras. Men samtidigt har vi fortfarande en punkt av misslyckande - nätverket, därför, i kritiska system, bör minst två nätverk användas för att komma åt SAN. Förutom att öka tillförlitligheten låter detta tillvägagångssätt dig öka genomströmningen, vilket också är viktigt.

Det är omöjligt att inte nämna om mjukvarulösningar, så att du kan skapa ett failover-kluster på endast två noder, med virtuell lagring som ett SAN. Till exempel StarWind Virtual SAN, som skapar virtuell iSCSI-lagring baserat på lokala enheter var och en av noderna. Detta gör att du kan minska kostnaderna för att skapa och placera feltolerant lagring, men samtidigt ökar kravet på nätverksprestanda mellan klusternoderna, eftersom när du skriver till disk synkroniseras alla ändringar omedelbart mellan noderna.

När du har skapat ett kluster kommer det att visas i Network Neighborhood som en annan värd med sitt eget namn och IP-adress. Sedan måste vi distribuera högt tillgängliga roller på det. Dessa kan vara filservrar, SQL eller Exchange, samt andra applikationer som stöder klustring. Varje failover-klusterroll visas också på nätverket som en separat värd för klienter att komma åt. Samtidigt har klienten ingen aning om vilken nod som uppfyller hans begäran, i händelse av fel, till exempel på grund av fel på en av noderna, behöver han bara upprepa begäran till tjänsten.

För närvarande används kluster i allt större utsträckning för virtualiseringssystem; i det här fallet distribueras virtuella maskiner manuellt av administratören mellan noderna, med hänsyn till deras datorresurser. För varje virtuell maskin indikeras de tillgängliga noderna i fallande prioritetsordning. Detta förhindrar resurskrävande virtuella maskiner från att träffa svaga värdar. Om en av klusternoderna stängs av korrekt, överförs alla virtuella maskiner som körs på den till andra noder med hjälp av live-migreringsmekanismer utan att stoppa arbetet eller pausas.

Om en nod misslyckas kommer alla virtuella maskiner som körs på den att startas om på andra noder, enligt inställd prioritet.

För att undvika överdriven belastning på lagring och lagringsnätverket kan du ställa in en återställningsfördröjning i inställningarna för virtuella maskiner, så att kritiska virtuella maskiner kan startas om omedelbart, mindre sådana efter ett tag.

I våra nästa artiklar kommer vi att titta på en praktisk implementering av ett Hyper-V-baserat failover-kluster.

• Taggar:

Vänligen aktivera JavaScript för att se