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

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

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 :)

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

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

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

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 :)

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 :)

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.

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?

Watt - cibai cik procentu uptaims? ;)

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)..

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 ...

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.

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.

RouterOS routeris ar failover

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.

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>

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

un sievietes nemēdz būt neglītas

Ņ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

koko, tad reska repliceejies, jo tu vari nomirt!

17. trolejbusa draudzīgais kolektiivs

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 :)

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.

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 :)

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

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 :)

Ja par ieteikumiem: OpenBSD CARP.

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. :))

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ā.

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

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!" :)