| |
laacz tagad
klausās:
Radio NABA
Autora domas ne vienmēr sakrīt ar autora domām. © spectatorIr pagājuši 24 gadi un 3 mēneši un 23 dienas kopš mana mūža laimīgākās dienas
Papildus 3355 maniem pļurkšķiem ir sapļurkstēti 33189 sveši pļurkšķi.
ICQ: #58279153 (very rarely)
MSN:
E-mail:
Mazās pustizlās ikoniņas aiz linkiem (ne visiem) arī šo to nozīmē.
|
|
<br />
<br />
<br />
2005 17. jūnijs piektdiena
 14:56 |
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? :) |
| asdf (#31588) |
15:07 @ 2005. gada 17. jūnijs, piektdiena
|
new 1) utt. nevis u.t.t
2) Nekāds HA nesanāk, jo jebkurā brīdī var noplīst rūteris.
|
| watt (#31589) |
15:10 @ 2005. gada 17. jūnijs, piektdiena
|
new vispirms mēģini definēt, cik 9 tev availability vajag. 99.999 vai vairāk, vai mazāk?
|
| ZeaLot (#31591) |
15:14 @ 2005. gada 17. jūnijs, piektdiena
|
new 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 :)
|
| laacz (#31592) |
15:15 @ 2005. gada 17. jūnijs, piektdiena
|
new watt: Jo tuvāks simtam, jo labāk, protams. Ideālā vajag 100%, bet tas ir nereāli. Ar 99,999 pietiek.
|
| laacz (#31593) |
15:15 @ 2005. gada 17. jūnijs, piektdiena
|
new asdf: Nu, lielāks HA, nekā viens serveris :)
|
| watt (#31594) |
15:16 @ 2005. gada 17. jūnijs, piektdiena
|
new tas protams ir domāts procentos. 99.999% availability, kas nozīmē, ka downtime ir pieļaujams ~5 minūtes gadā.
|
| Livingston (#31595) |
15:21 @ 2005. gada 17. jūnijs, piektdiena
|
new 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 :)
|
| Runcis (#31596) |
15:27 @ 2005. gada 17. jūnijs, piektdiena
|
new 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 :)
|
| watt (#31597) |
15:27 @ 2005. gada 17. jūnijs, piektdiena
|
new 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.
|
| Lupus (#31598) |
15:29 @ 2005. gada 17. jūnijs, piektdiena
|
new 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?
|
| Lupus (#31599) |
15:30 @ 2005. gada 17. jūnijs, piektdiena
|
new Watt - cibai cik procentu uptaims? ;)
|
| watt (#31600) |
15:31 @ 2005. gada 17. jūnijs, piektdiena
|
new 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)..
|
| Livingston (#31601) |
15:33 @ 2005. gada 17. jūnijs, piektdiena
|
new 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 ...
|
| watt (#31602) |
15:33 @ 2005. gada 17. jūnijs, piektdiena
|
new 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.
|
| laacz (#31603) |
15:38 @ 2005. gada 17. jūnijs, piektdiena
|
new 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.
|
| N.R. (#31604) |
15:42 @ 2005. gada 17. jūnijs, piektdiena
|
new RouterOS routeris ar failover
|
| watt (#31605) |
15:45 @ 2005. gada 17. jūnijs, piektdiena
|
new 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.
|
| Livingston (#31606) |
15:47 @ 2005. gada 17. jūnijs, piektdiena
|
new 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>
|
| watt (#31607) |
15:49 @ 2005. gada 17. jūnijs, piektdiena
|
new Livingston, datu bāzu serveri nemēdz sprāgt nost.
|
| Livingston (#31608) |
15:53 @ 2005. gada 17. jūnijs, piektdiena
|
new un sievietes nemēdz būt neglītas
|
| koko (#31609) |
15:54 @ 2005. gada 17. jūnijs, piektdiena
|
new Ņ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
|
| shiazo (#31611) |
16:13 @ 2005. gada 17. jūnijs, piektdiena
|
new koko, tad reska repliceejies, jo tu vari nomirt!
**17. trolejbusa draudzīgais kolektiivs**
|
| watt (#31612) |
16:14 @ 2005. gada 17. jūnijs, piektdiena
|
new 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 :)
|
| Livingston (#31613) |
16:19 @ 2005. gada 17. jūnijs, piektdiena
|
new 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.
|
| c++ (#31614) |
17:21 @ 2005. gada 17. jūnijs, piektdiena
|
new 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 :)
|
| hvz (#31616) |
18:35 @ 2005. gada 17. jūnijs, piektdiena
|
new internetbankām labs up-time ir 95% :)
|
| hehe (#31618) |
09:58 @ 2005. gada 18. jūnijs, sestdiena
|
new 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 :)
|
| Maita (#31619) |
10:06 @ 2005. gada 18. jūnijs, sestdiena
|
new Ja par ieteikumiem: OpenBSD CARP.
|
| Kirils (#31620) |
17:56 @ 2005. gada 18. jūnijs, sestdiena
|
new 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. :))
|
| Bao (#31623) |
18:20 @ 2005. gada 18. jūnijs, sestdiena
|
new 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ā.
|
| Fedja (#31739) |
20:40 @ 2005. gada 20. jūnijs, pirmdiena
|
new 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
|
| rupucis007 (#31809) |
22:03 @ 2005. gada 21. jūnijs, otrdiena
|
new 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!" :)
|
Mazliet komentāru kultūras, jeb laacziquette
- Ja tu gribi pateikt tikai ':)', tad saki to sev un pie spoguļa. Pašam prieks un es esmu mierīgs.
- Neaizraujies ar enteriem savā komentārā. Pavisam nav obligāti likt divus vai trīs enterus pēc katras uzrakstātās rindiņas.
- Offtopiks (komentāri ne pa tēmu) nav no gaidītākajām lietām.
- Galu galā, ja tev ir verbāla caureja, ej uz delfiem vai arī taisi pats savu lapu.
- Pirms spiest pogu, padomā. Varbūt tu vēl neesi visu pateicis? Lai nebūtu pēc tam vēl 26 pēc kārtas esošu komentāru jāraksta.
- Vēlies runāt ar kādu cilvēku, uzraksti viņam vēstuli. Ir daži izņēmumi. Agressor, tu neesi izņēmums.
- Un, galu galā, paturu tiesības jebkuru sev neimponējošu komentāru izmēzt.
- Par izņēmumu kādā no šiem punktiem, vai arī visos noteikumos var kļūt, uzrakstot iesniegumu un iedodot man to rokā. Iesnieguma vēlamais apjoms - 0.7 laba viskija.
- Gan jau kaut ko vēl izdomāšu.
|
lv