← Uz sākumu

HA clusteri

2005. gada 17. jūnijā, 32 komentāri

Es saprotu, ka Latvijā nav daudzi, kuriem nepieciešams High Availability klāsteris. Un lielākā daļa no tiem, kam tas ir vajadzīgs, izmanto komerciālus risinājumus par desmitiem tūkstošiem latu un vairāk. Mani, savukārt, interesē vienkārša high availability sistēma.

Dotajā brīdī izskatu divus variantus. Viens ir linux-ha, bet otrs - rūteris + n datori, kuriem failoveru nodrošina pats rūteris (mainot tīkla konfigurāciju, palaižot klienta skriptus uz sleiva, u.t.t.).

Kādas rekomendācijas? :)

Tu atbildi augstāk redzamajam komentāram. Atcelt

Gravatar asdf

2005. gada 17. jūnijā, plkst. 15:07

  1. utt. nevis u.t.t
  2. Nekāds HA nesanāk, jo jebkurā brīdī var noplīst rūteris.

Gravatar watt

2005. gada 17. jūnijā, plkst. 15:10

vispirms mēģini definēt, cik 9 tev availability vajag. 99.999 vai vairāk, vai mazāk?

Gravatar ZeaLot

2005. gada 17. jūnijā, plkst. 15:14

hmm... Vai es pareizi sapratu, ka tam linux-ha.org vahaga atsevishkji organizeet storage repliceeshanos? Ja taa, tad veel clusteris varbuut der http://www.mosix.org/. Es praktiskajaa darbaa Linux kursaa shito clusteri uzliku. Aatri un vienkaarshi uzlikaas uz Slackas. Protams, noorganizeet maajas tiiklam bridge uz shitaada clustera bija jautraakaa shii pasaakuma dalja, kas aiznjeema atlikusho vakaru :)

Gravatar laacz

2005. gada 17. jūnijā, plkst. 15:15

watt: Jo tuvāks simtam, jo labāk, protams. Ideālā vajag 100%, bet tas ir nereāli. Ar 99,999 pietiek.

Gravatar laacz

2005. gada 17. jūnijā, plkst. 15:15

asdf: Nu, lielāks HA, nekā viens serveris :)

Gravatar watt

2005. gada 17. jūnijā, plkst. 15:16

tas protams ir domāts procentos. 99.999% availability, kas nozīmē, ka downtime ir pieļaujams ~5 minūtes gadā.

Gravatar Livingston

2005. gada 17. jūnijā, plkst. 15:21

Nedomāju, ka praktiski var nodrošināt 99.999% pa lēto. Ja ziniet, kur Latvijā to ir panākuši un kādiem līdzekļiem - dodiet ziņu :)

Gravatar Runcis

2005. gada 17. jūnijā, plkst. 15:27

Manuprāt, tas ir atkarīgs kādus servisus tu gribi piedāvāt. Domāju, ka risinājumi atsķirsies gadījumā ja tev jānodrošina Web serviss vai arī, piemēram, video plūsma :)

Gravatar watt

2005. gada 17. jūnijā, plkst. 15:27

Livingston, ir divi veidi kā kaut ko panākt - ar naudu, un ar galvu.

ja parēķina, kādus failover pasākumus var paspēt veikt 5 minūtēs, un attiecīgi plāno, tad jau var tos uptim procentus dabūt.

Gravatar Lupus

2005. gada 17. jūnijā, plkst. 15:29

Interesantāk būtu pajautāt kāda profila un noslodzes risinājumam. Lai vai kā - šādi risinājumi na haļavu nenāk un pats no esošajiem dzelžiem tādu diez vai savāksi.

Pie 99.999 pats klāsteris un tā konfigurēšana jau ir tikai puse no problēmas. Klāt jāliek:

  • Strāvas apgāde - kā tiks nodrošināta patstāvīga energoapgāde
  • Interneta pieslēgums - kāda mērķauditorija. Cik pieslēgumi. Kas notiek ja nomirst tīklakarte? Kas notiek ja nomirst LIX?
  • Programmatūras atjaunošana. Kā uzlikt patchu? Ar cik taisnām rokām tiek uzturētas un lietotas datubāzes?

Gravatar Lupus

2005. gada 17. jūnijā, plkst. 15:30

Watt - cibai cik procentu uptaims? ;)

Gravatar watt

2005. gada 17. jūnijā, plkst. 15:31

starp citu, ļoti interesanta ideja id DB master-master replikācija. t.i., uz abiem serveriem (A<->B) ir nokonfigurēts ka viens no otra replicējas.

triks šeit ir ka kamēr viens (A) dara visu darbu, uz otru netiek nosūtīti nekādi lietotāju pieprasījumi, t.i., replikācija B->A it kā notiek, bet tai nav nekas jādara, jo nav pieprasījumu serverim B kurus sobstvenno replicēt.

Tad, vienā mirklī Web softam norāda, ka visi pieprasījumi būs jāsūta otram db serverim B, un serveris A ir jāatstāj mierā. (Ir jāņem vērā replikācijas 'lags', un pieprasījumi jāatļauj tikai kad B ir pilnībā nosinhronizējies ar A. to gan ir vielgāk pateikt nekā izdarīt:)

uz pirmā servera (A) viss aktīvais darbs apstājas, un vairs nenotiek nekādi pieprasījumi. savukārt uz otro serveri sāk pienākt pieprasījumi, un tas sāk darīt aktīvu darbu, un pirmais serveris sāk darīt replikācijas darbu (B->A)..

Gravatar Livingston

2005. gada 17. jūnijā, plkst. 15:33

watt, par ko mēs runājam? Uz 2 kastēm 99.999% laika noturēt atvērtu notepad ? Easy! Noturēt gadu gaita pārbaudītu aplikāciju, ko netaisās modernizēt, ko nepapildina ar jauniem moduļiem, mazs datu apjoms utt. ... Jā, kadēļ gan nē ...

Un kādus failover pasākumus var veikt 5 minūtēs? Garantēt drošu DB apstādināšanu uz vienas kastes un pacelšanu uz otras ? Nu nu ...

Gravatar watt

2005. gada 17. jūnijā, plkst. 15:33

Lupus, ap 98%

Un ja nomirst tīkla karte notiek tieši tas pats kas ja būtu nomirusi visa kaste. Nav vairs kompji tik dārgi, lai ceptos par vienu tīkla karti.

Gravatar laacz

2005. gada 17. jūnijā, plkst. 15:38

watt: Tas ir visnotaļ tricky (master-master replikācijas). Var ieberzties, ja rokas ir kaut mazdrustiņ līkas :) Bet "lētās" clusterošanas gadījumā, ja to visu pareizi nokonfigurē, tad ģeld :) Tiesa, Tevis minētā problēma ar replikācijas "iebremzi" pastāv.

Gravatar N.R.

2005. gada 17. jūnijā, plkst. 15:42

RouterOS routeris ar failover

Gravatar watt

2005. gada 17. jūnijā, plkst. 15:45

laacz, replikācija vispār ir tricky :) lj ir viena tabula kas visu laiku čakarēja replikāciju (search rezultāti, visu laiku taisīja kautkādus replication konfliktus). man liekas es viņu īstenībā izslēdzu no replikācijas, jo tie vienalga nav dati ko vajadzētu back-upot.

Gravatar Livingston

2005. gada 17. jūnijā, plkst. 15:47

Pēc 5 minūtēm nosprāgs serveris A, davai ka fiksi sinhronizējies serveri B un pārņem vadību! ha ha :D


<blabla>Tad, vienā mirklī Web softam norāda, ka visi pieprasījumi būs jāsūta otram db serverim B, un serveris A ir jāatstāj mierā. (Ir jāņem vērā replikācijas 'lags', un pieprasījumi jāatļauj tikai kad B ir pilnībā nosinhronizējies ar A. to gan ir vielgāk pateikt nekā izdarīt:) </blabla>

Gravatar watt

2005. gada 17. jūnijā, plkst. 15:49

Livingston, datu bāzu serveri nemēdz sprāgt nost.

Gravatar Livingston

2005. gada 17. jūnijā, plkst. 15:53

un sievietes nemēdz būt neglītas

Gravatar koko

2005. gada 17. jūnijā, plkst. 15:54

Ņa - visi var nomirt... Lai arī cik dīvaini tas neliktos, pat es varu nomirt... So - kāpēc gan nevar nosprāgt DBVS? Ēlementāri :D

Gravatar shiazo

2005. gada 17. jūnijā, plkst. 16:13

koko, tad reska repliceejies, jo tu vari nomirt!

17. trolejbusa draudzīgais kolektiivs

Gravatar watt

2005. gada 17. jūnijā, plkst. 16:14

koko, neesi muļķis. varēt var, bet nedrīkst. jo tad tā nav DB un serveris, bet sūds kautkāds.

DB downtime ir paredzama tikai lai veiktu dzelžu apgreidus un liktu patčus. Ja tev nomirst master DB serveris (ar dzelžu problēmu), tad visdrīzāk tur notiks atjaunošanās no backupiem un binary log pārspēlēšana, utt utjp, un tur vairs no 99.999% availability pat nesmird. (Es runāju par write serveriem, kuriem ir kritiski saglabāt ienākošo datu un izmaiņu plūsmu, jo read only/statisku datu servēšana ir triviāla problēma, ko varam arī neapskatīt ;)

Es neesmu tuvu pazīstams ar t.s. enterprise risinājumiem, tipa shared diski, bet par tiem var izstāstīt kāds kas ir zinošs :)

Gravatar Livingston

2005. gada 17. jūnijā, plkst. 16:19

HA watt izpratnē:

Uzrakstam iekšējās kartības noteikumus, kuros aizliedzam serveriem nobeigties. DB serveriem aizliedzam nobeigties uz visstingrāko!

Sākot ar to momentu visas uzņēmuma IS būs pieejamas 99.9999999999999999% laika.

Gravatar c++

2005. gada 17. jūnijā, plkst. 17:21

ja domaa GPL'ed, ir taads keepalived, ar ko var uzbuuveet gan HA webserverus un arii redundant routers, es tos izmantoju daudzaas vietaas, jo jebkuraa gadijumaa, routeris ir shauraa vieta tradicionaali buuveetaa IP tiiklaa.

redundant routers ir tam risinaajums, tas darbojas taa, ka ir master routers un vairaaki slaves, kas cheko masteru, ja masters vairs nerespondee, tad kaads no sleiviem ienjem taa vietu, prioritaates var noraadiit.

man darbaa pashaas buutiskaakajaas vietaas staav ir masters ar diviem vergiem, bet divu gadu laikaa, tikai vienu reizi ir notikusi taada kjibele, ka slave ir paarnjeemis masteru(ja neskaita manis pasha veiktos rebootus). Tas viss ir labi, bet lieta ar jau izveidotaam tcp seisijaam(piem. ssh) nespeej paardziivot routeru mainju ;)

var paluukoties te: http://www.keepalived.org/ http://www.linux-ha.org/

arii 2.6 kernelii ir jau iekshaa shaadi taadi HA risinaajumi :)

Gravatar hvz

2005. gada 17. jūnijā, plkst. 18:35

internetbankām labs up-time ir 95% :)

Gravatar hehe

2005. gada 18. jūnijā, plkst. 09:58

Labs buus tikai taads risinaajums, kursh ir izstraadaats zinot tavas konkreetaas prasiibas. Universiaalie HA "risinaajumi" der tikai liidz kautkaadam briidim. Piemeeram datu centri ir labi universaali HA risinaajumi liidz noteiktam liimenim. Bet HA kas attiecas jau konkreeti uz tavu aplikaaciju/produktu ir jaaizstraadaa njemot veeraa kautkaadas konkreetas parsiibas... Veel mani fascinee juusu spozhaas idejas par HA caur DB replikaaciju. Dabuusiet juus kaadu konkreetu LOADu un juusu jaukais risinaajums aizies atpuusties :)

Gravatar Maita

2005. gada 18. jūnijā, plkst. 10:06

Ja par ieteikumiem: OpenBSD CARP.

Gravatar Kirils

2005. gada 18. jūnijā, plkst. 17:56

latvijaa par 99.99% uptime var nesapnjot, skatoties uz to cik stabils ir muusu LIX.

ak, protams --- kaapeec gan neutaisiit aironet p2mp savienojumus ieliekot pa nodei ml, latnet, telia un ltk tiiklos. :))

Gravatar Bao

2005. gada 18. jūnijā, plkst. 18:20

heartbeat + DRBD

Īsumā: hearbeat nodrošina takeover funkcijas ar papildus IP adreses palīdzību. DRBD nodrošina diska iekārtas replikāciju reālā laikā. Monitorējam un replicējamies caur gigabit crosskabeli. Sliktums - nevaram dalīt slodzi starp viņiem - viens stāv dīkā. Labums - nevajag nekādu gudru tīkla aparatūru, visi dati vienmēr sasinhronizēti, izmantojot žurnālējošu fs ātri paceļas, nav atkarīgs no izmantotajām aplikācijām. Nu apmēram tā.

Gravatar Fedja

2005. gada 20. jūnijā, plkst. 20:40

Par šo tēmu interesanta lasāmviela ir no Microsoft dzīlēm noklīdis dokuments, kurā aprakstīta Hotmail.com pārņemšana un mēģinājums (neveiksmīgs :) visu to pārcelt un Windows platformu.

Links interesentiem: http://www.securityoffice.net/mssecrets/hotmail.html#_Toc491601822

Gravatar rupucis007

2005. gada 21. jūnijā, plkst. 22:03

Tīri informācijai - man darbā ir uzstādīta komerciāla HA sistēma - uptime plānots uz 99.95%, bet prektiski to ir grūti sasniegt - iemesls ir tas, ka "uberkūlais" //failover// risinājums paasti nogļuko un nograuj abus serverus. Var jau protams mēģināt sekot tam krāmam līdzi, bet ar mazākām pūlēm labākus rezultātus pie tā paša //uptime// dod politika "ja tas strādā, tad labāk to neaiztiec!" :)