1 asdf @ 15:07 (2005. gada 17. jūnijs)

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

2 watt @ 15:10 (2005. gada 17. jūnijs)

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

3 ZeaLot @ 15:14 (2005. gada 17. jūnijs)

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

4 laacz @ 15:15 (2005. gada 17. jūnijs)

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

5 laacz @ 15:15 (2005. gada 17. jūnijs)

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

6 watt @ 15:16 (2005. gada 17. jūnijs)

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

7 Livingston @ 15:21 (2005. gada 17. jūnijs)

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

8 Runcis @ 15:27 (2005. gada 17. jūnijs)

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

9 watt @ 15:27 (2005. gada 17. jūnijs)

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.

10 Lupus @ 15:29 (2005. gada 17. jūnijs)

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?

11 Lupus @ 15:30 (2005. gada 17. jūnijs)

Watt — cibai cik procentu uptaims? ;)

12 watt @ 15:31 (2005. gada 17. jūnijs)

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

13 Livingston @ 15:33 (2005. gada 17. jūnijs)

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 …

14 watt @ 15:33 (2005. gada 17. jūnijs)

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.

15 laacz @ 15:38 (2005. gada 17. jūnijs)

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.

16 N.R. @ 15:42 (2005. gada 17. jūnijs)

RouterOS routeris ar failover

17 watt @ 15:45 (2005. gada 17. jūnijs)

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.

18 Livingston @ 15:47 (2005. gada 17. jūnijs)

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>

19 watt @ 15:49 (2005. gada 17. jūnijs)

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

20 Livingston @ 15:53 (2005. gada 17. jūnijs)

un sievietes nemēdz būt neglītas

21 koko @ 15:54 (2005. gada 17. jūnijs)

Ņ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

22 shiazo @ 16:13 (2005. gada 17. jūnijs)

koko, tad reska repliceejies, jo tu vari nomirt!

17. trolejbusa draudzīgais kolektiivs

23 watt @ 16:14 (2005. gada 17. jūnijs)

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

24 Livingston @ 16:19 (2005. gada 17. jūnijs)

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.

25 c++ @ 17:21 (2005. gada 17. jūnijs)

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

26 hvz @ 18:35 (2005. gada 17. jūnijs)

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

27 hehe @ 09:58 (2005. gada 18. jūnijs)

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

28 Maita @ 10:06 (2005. gada 18. jūnijs)

Ja par ieteikumiem: OpenBSD CARP.

29 Kirils @ 17:56 (2005. gada 18. jūnijs)

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

30 Bao @ 18:20 (2005. gada 18. jūnijs)

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

31 Fedja @ 20:40 (2005. gada 20. jūnijs)

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/…

32 rupucis007 @ 22:03 (2005. gada 21. jūnijs)

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