{"id":75726,"date":"2020-03-28T07:42:08","date_gmt":"2020-03-28T05:42:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/klaster-iz-dvuh-uzlov-dyavol-v-detalyah"},"modified":"2020-03-28T07:42:08","modified_gmt":"2020-03-28T05:42:08","slug":"klaster-iz-dvuh-uzlov-dyavol-v-detalyah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/klaster-iz-dvuh-uzlov-dyavol-v-detalyah","title":{"rendered":"Klynge med to noder \u2013 detaljerne er afg\u00f8rende","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej, Habr! Jeg pr\u00e6senterer for jer overs\u00e6ttelsen af artiklen \u00abTo Noder \u2014 Dj\u00e6velen er i detaljerne\u00bb<\/a><\/noindex> forfatter Andrew Beekhof.<\/p>\n

Mange mennesker foretr\u00e6kker klynger best\u00e5ende af to noder, fordi de virker konceptuelt mere enkle, og de er ogs\u00e5 33% billigere end deres tre-node s\u00f8skende. Selvom det er muligt at samle en god klynge af to noder, vil det i de fleste tilf\u00e6lde skabe mange uventede problemer p\u00e5 grund af ikke-overvejede scenarier.
\n<\/a><\/noindex>
\nDet f\u00f8rste skridt mod at skabe et system med h\u00f8j tilg\u00e6ngelighed er at finde og fors\u00f8ge at fjerne enkeltpunkter for fejl, ofte forkortet som SPoF<\/i> (single point of failure).<\/p>\n

Det er v\u00e6rd at bem\u00e6rke, at det i ethvert system er umuligt at eliminere alle mulige nedetidsrisici. Dette skyldes i det mindste det faktum, at den typiske l\u00f8sning p\u00e5 risiko er at indf\u00f8re en vis redundans, hvilket f\u00f8rer til \u00f8get kompleksitet i systemet og skabelsen af nye fejlmuligheder. Derfor g\u00e5r vi oprindeligt ind p\u00e5 et kompromis og fokuserer p\u00e5 begivenheder relateret til enkeltpunkter for fejl fremfor k\u00e6der af relaterede og derfor f\u00e6rre sandsynlige begivenheder.<\/p>\n

I betragtning af kompromiserne s\u00f8ger vi ikke kun SPoF, men afvejer ogs\u00e5 risici og konsekvenser, hvilket resulterer i, at hvad der er kritisk, og hvad der ikke er, kan variere for hver implementering.<\/p>\n

Ikke alle har brug for alternative energileverand\u00f8rer med uafh\u00e6ngige str\u00f8mlinjeforbindelser. Selvom paranoiaen betalte sig for i det mindste \u00e9n kunde, da deres overv\u00e5gning opdagede en defekt transformer. Kunden ringede for at advare energiselskabet, indtil den defekte transformer eksploderede.<\/p><\/blockquote>\n

\nEt naturligt udgangspunkt er at have mere end \u00e9n node i systemet. Men f\u00f8r systemet kan flytte tjenesterne til den overlevende node efter et nedbrud, er det generelt n\u00f8dvendigt at sikre, at de flyttede tjenester ikke er aktive et andet sted.<\/p>\n

En to-node klynge har ikke ulemper, hvis begge noder servicerer den samme statiske hjemmeside som f\u00f8lge af en nedbrud. Men alt \u00e6ndrer sig, hvis begge sider uafh\u00e6ngigt h\u00e5ndterer en delt jobk\u00f8 eller giver ukontrolleret skriveadgang til en replikeret database eller et delt filsystem.<\/p>\n

For at forhindre datatab som f\u00f8lge af \u00e9n nodes svigt, stoler vi p\u00e5 noget, der kaldes \u00bbafsp\u00e6rring\u00ab<\/i> (fencing).<\/p>\n

Afsp\u00e6rringsprincip<\/h2>\n

\nI bunden af afsp\u00e6rringsprincippet ligger sp\u00f8rgsm\u00e5let: Kan en konkurrerende node for\u00e5rsage datatab? I tilf\u00e6lde af, at datatab er et sandsynligt scenarie, vil en god l\u00f8sning v\u00e6re at isolere noden fra b\u00e5de indkommende foresp\u00f8rgsler og det permanente lager. Den mest almindelige tilgang til afsp\u00e6rring er at slukke for de defekte noder.<\/p>\n

Der er to kategorier af afsp\u00e6rringsmetoder, som jeg vil kalde direkte<\/i> og indirekte<\/i>, men de kan liges\u00e5vel kaldes aktive<\/i> og passive<\/i>. Direkte metoder involverer handlinger fra de overlevende peer-noder, s\u00e5som interaktion med en IPMI-enhed (Intelligent Platform Management Interface \u2013 interface til fjernoverv\u00e5gning og -styring af serverens fysiske tilstand) eller iLO (styringsmekanisme for servere uden fysisk adgang til dem), mens indirekte metoder er afh\u00e6ngige af den mislykkede node til p\u00e5 en eller anden m\u00e5de at registrere, at den er i en usund tilstand (eller i det mindste forstyrrer de andre medlemmer i deres genopretning) og signalere hardware watchdog<\/a><\/noindex> om n\u00f8dvendigheden af at slukke for den mislykkede node.<\/p>\n

Kvote hj\u00e6lper i tilf\u00e6lde af brug af b\u00e5de direkte og indirekte metoder.<\/p>\n

Direkte afsp\u00e6rring<\/h3>\n

\nI tilf\u00e6ldet med direkte afsp\u00e6rring kan vi bruge kvote til at forhindre afsp\u00e6rringsl\u00e6nge i tilf\u00e6lde af netv\u00e6rkssvigt.<\/p>\n

Ved hj\u00e6lp af konceptet kvote har systemet tilstr\u00e6kkelig information (selv uden forbindelse til sine partnere) til, at noder automatisk kan vide, om de skal igangs\u00e6tte afsp\u00e6rring og\/eller genopretning.<\/p>\n

Uden kvote antager begge sider af netv\u00e6rksopdelingen med rette, at den anden side er d\u00f8d, og vil str\u00e6be efter at afsp\u00e6rre den anden. I v\u00e6rste fald form\u00e5r begge sider at slukke hele klyngen. Et alternativt scenarie er deathmatch, en uendelig cyklus af noder, der genstarter, ikke ser deres peers, genstarter dem og igangs\u00e6tter genopretning, kun for at genstarte, n\u00e5r deres peer f\u00f8lger den samme logik.<\/p>\n

Problemet med afgr\u00e6nsning er, at de mest brugte enheder ofte bliver utilg\u00e6ngelige p\u00e5 grund af de samme fejl, som vi \u00f8nsker at basere genopretningen p\u00e5. De fleste IPMI- og iLO-kort er installeret p\u00e5 de v\u00e6rter, de kontrollerer, og som standard bruger de det samme netv\u00e6rk, hvilket f\u00e5r de m\u00e5lrettede noder til at tro, at de andre noder er offline.<\/p>\n

Desv\u00e6rre bliver egenskaberne ved IPMI- og iLo-enheder sj\u00e6ldent overvejet i k\u00f8bs\u00f8jeblikket.<\/p>\n

Indirect afgr\u00e6nsning<\/h3>\n

\nKvorum er ogs\u00e5 vigtigt for styringen af indirekte afgr\u00e6nsninger; hvis alt g\u00f8res korrekt, kan kvorum give de overlevende mulighed for at antage, at de tabte noder vil g\u00e5 i en sikker tilstand efter en vis periode.<\/p>\n

I denne ops\u00e6tning nulstilles hardware watchdog timeren hvert N-sekund, hvis kvorummet ikke er mistet. Hvis timeren (normalt nogle gange N) udl\u00f8ber, udf\u00f8rer enheden en ukorrekt str\u00f8mafbrydelse (ikke shutdown).<\/p>\n

Denne tilgang er meget effektiv, men uden kvorum til at styre den er der ikke nok information i klyngen. Det er ikke let at skelne mellem netv\u00e6rksafbrydelse og fejl p\u00e5 partnernoden. \u00c5rsagen til, at dette er vigtigt, er, at uden evnen til at skelne mellem de to tilf\u00e6lde er du n\u00f8dt til at v\u00e6lge den samme adf\u00e6rd i begge situationer.<\/p>\n

Problemet med at v\u00e6lge \u00e9n tilstand er, at der ikke findes en handlingsplan, der maksimalt \u00f8ger tilg\u00e6ngeligheden og forhindrer tab af data.<\/p>\n