[pgyafi]

Idézet: adam.k - Dátum: 2007. ápr. 19., csütörtök - 15:50

Termeszetszeruleg szamitok arra, hogy amennyiben a hosting ceg elhasal, akkor nem layer2-ben kell nekem gondoskodnom a redundanciarol, erre az esetre van a DNS, amiben atirom a nevekhez tartozo ip cimet a masik szolgaltatonal levo gepre.

A két szolgáltatónál lévõ gép egymás tükrei?  Hogyan oldod/oldottad meg?

[pgyafi]

Idézet: Jahno - Dátum: 2007. ápr. 19., csütörtök - 16:45

Mármint 1 gép, két kártyával, de két szolgáltatónál?

Azt írta, 1 gép 1 szolgáltatónál 2 kártyával megy saját switchébe.

[Nagyika]

Idézet: pgyafi - Dátum: 2007. ápr. 19., csütörtök - 19:59

A két szolgáltatónál lévõ gép egymás tükrei?  Hogyan oldod/oldottad meg?

Ezen én is sokat gondolkodtam, hogyan lehetne minnél megbízhatóbbá tenni a szolgáltatást.
Hagyományos failover clusteres megoldás ahogy számolgattam elég drágára jönne ki( két gép, közös disk alrendszer, az is redundánsan és már repkednek is a milliók), valamint szolgáltató hiba esetén ugyanúgy meg lennék lõve.
Szegény ember vizzel fõz alapon, most az alábbi megoldást tesztelgetem:
2 független gép két szolgáltatónál, levelek és webtartalom közös hálózati filerendszeren master/slave módban, mysql és ldap adatbázis pedig replikációval megoldva. Dns ttl- jó kicsire levéve, így gond esetén viszonylag hamar át lehetne váltani.
Sajnos ennek is számos hátulütõje van, csak pár dolog ami hirtelen eszembejut és még kisérletezésre vár:
- mivel nincs dedikált heartbeat lan a két gép között kapcsolat szakadás esetén nem lehet tudni, hogy csak a vonal döglött, vagy a másik gép és gond lehet ha mindketten azt hiszik magukról, hogy most õk a masterek
- kérdéses még a filrendszer és a  tõle független adatbázis replikációkkal mennyire lesznek hiba esetén konzisztensek az adatok.

Esetleg valakinek valami jó módszere, ötlete?

Szerkesztette: Nagyika 2007. 04. 19. 19:34 -kor

[adam.k]

Idézet: charlie - Dátum: 2007. ápr. 19., csütörtök - 15:59

oszt mire a dns szerverek atveszik a frissitett cimeket mivan?

Erre valo a kis TTL.  Igaz ugyan, hogy a TTL alacsonyan tartasa normal uzemben emeli a DNS szerverek terheleset, de nem desktop pc kaliberu gepeknel, hanem szervereknel ez nem problema.  Cserebe az atallaskor hamar terjed az uj informacio.

[adam.k]

Idézet: Jahno - Dátum: 2007. ápr. 19., csütörtök - 16:45

Mármint 1 gép, két kártyával, de két szolgáltatónál? Itthon nem tudom miképpen lehet kivitelezni, de a lentebb írt DNS-ek miatt nem hinném, hogy nem szoptál még be. Másrészt kicsiben szolgáltatva sincs akkora kiesés a hostingban, hogy megérje +1 vonalat "csak úgy" fenntarrtani. Van néha tervszerû karbantartás, az úgyis éjjel, rendesen megoldva, amikor meg fél órát állt az elõttünk lévõ router, akkor mire beléptem volna a gépre, hogy áthegesszem, arra mûködött újra rendesen a helyén.

Nem.  Vagy nem teljesen vilagosan irtam, vagy gyorsan olvastad.  2 gep, az egyikben ket halokartya, amely kartyak ugyanoda mennek.  Ami leirtam, mitol ved.

En nem hostingot szolgaltatok, hanem tartalmat.  Ha sok gipszjakab weboldala lenne a gepeken, akkor nem annyira erdekelne az SLA, eleg lenne occsoert adni, es kesz, mindig lenne sok ugyfel, nehany elmenne ha gaz van, a tobbseget nem zavarna.  De a ceg tevekenysege a netes megjelenesre alapszik, ezert fontos, hogy egy adott koltseghataron belul minden elkepzelheto legyen meg a redundancia erdekeben.  Es lassuk be, ez nem sok.  +1 halokartya es drot: a tobbi koltseghez kepest lenyegeben nulla, +1 gep: 250e, +1 hosting: 30e, +1 switch: 200e a switch tapellatasa es ip cime gratisz, mert annyi gepunk van a hostingban, hogy belefer.

[adam.k]

Idézet: Nagyika - Dátum: 2007. ápr. 19., csütörtök - 19:34

- mivel nincs dedikált heartbeat lan a két gép között kapcsolat szakadás esetén nem lehet tudni, hogy csak a vonal döglött, vagy a másik gép és gond lehet ha mindketten azt hiszik magukról, hogy most õk a masterek
- kérdéses még a filrendszer és a  tõle független adatbázis replikációkkal mennyire lesznek hiba esetén konzisztensek az adatok.

Esetleg valakinek valami jó módszere, ötlete?

Tegyuk fel ertelmesen a kerdest.  Mit erdemes tukrozni?

- statikus adatokat
rsync
- adatbazis adatokat
replikacio
- demon beallitasokat
sql-bol generalodik

Tegyuk fel maskepp a kerdest.  Mennyi energiat erdemes befektetni ugy, hogy meg a varhato eredmeny tobb legyen, azaz megerje?

Termeszetesen a tervezeskor felmerult nem internet feletti, dedikalt halozaton torteno hatterrendszer (hiszen a hostingos cegeknel nem kovetelmeny, hogy toluk vegyel halozati hozzaferest), valamint az egyik helyszinen levo storage, stbstb de ezek a mi celjainkhoz tul sokba kerulnek.  Van szerencsem olyan halozatban is dolgozni, ahol a redundanciara hasznalt eszkozok budapesten belul vannak szetszorva, mpls halozaton, es ahhoz kepest, amennyibe kerult (kerul) nem annyival jobb, mint az olcsobb megoldasok.

A felvetett ket kerdesre: ket gep csak ket modon tudja eldonteni, hogy ki a hibas, es ki nem.  Vagy egy interconnect linkkel, amely minden ismertebb cluster megoldasnak esszenciaja.  Vagy harmadik geppel.

Szinten volt szerencsem tervezni es uzemeltetni olyan halozatot, amely halozati (azaz nem szerverekbol allo reszet) kellett redundansra csinalni.  Remelem ide tartozik, ha nagy vonalakban leirom, hogy ehhez adott volt ket optika (kulon szolgaltatotol), egy olyan hosting ceg (nevet inkabb nem irok) amely netet nem is ad, csak a garantalt helysegeket es a garantalt aramot, es olyan halozati eszkozok amelyek kepesek az aktiv-aktiv failoverre.  Konfiguralas utan a kozponti halozati eszkozbol kitepve a tapkabelt a halozaton levo gepek nem vettek eszre semmit, meg egy icmp csomag sem veszett el.  Termeszetesen (visszaterve a hozzaszolas elejere) ez sem a jelenlegi kategoria amiben dolgozom, azaz itt ismet k..va sokba kerult az implementacio, a fenntartas, ellenben hozta is az eredmenyt a halozat.

[Jahno]

Idézet: pgyafi - Dátum: 2007. ápr. 19., csütörtök - 20:01

Azt írta, 1 gép 1 szolgáltatónál 2 kártyával megy saját switchébe.

Aztán ez vagy nagyon értelmes, vagy olyan trükköt tud az arc, amit mi nem

[adam.k]

Idézet: Jahno - Dátum: 2007. ápr. 19., csütörtök - 20:12

Aztán ez vagy nagyon értelmes, vagy olyan trükköt tud az arc, amit mi nem :-)

az "arc" :) leirta, hogy etherchannel.  ezt egyreszt a szolgaltatotol nem tudtam kinyerni, mert ok nem hajlandoak.  masreszt mielott ez a konfiguracio uzembe kerult, sokszor szivattam meg magam a kovetkezokkel:

- ifconfig eth0 down, istenem, osszekevertem az ssh ablakokat...
- valamelyik szomszed szerelte a gepet, es a hostingos srac addig rugdosta/huzta az utp-t amig elment a link (nyilvan nem szandekosan)
- fustolt mar el halokartyam ugy, hogy a gep maga meg ment rendesen

ezek, valamint a miatt, hogy a managelheto switchbol en magam latom az osszes egy helyen hostolt szerver allapotat (lenyegeben layer1-tol kezdve, felteve, hogy a switch elerheto) ez egy olyan befektetes volt, ami megerte (es ha egyszer gigas uplinket kap a switch, akkor a 2x100 = 200 full duplex halozattal rendelkezo szervernel lesz is ertelme a 2x100 mbitnek, amig 100 az up addig ugye nincs).

[pgyafi]

Idézet: adam.k - Dátum: 2007. ápr. 19., csütörtök - 19:52

Erre valo a kis TTL.  Igaz ugyan, hogy a TTL alacsonyan tartasa normal uzemben emeli a DNS szerverek terheleset, de nem desktop pc kaliberu gepeknel, hanem szervereknel ez nem problema.  Cserebe az atallaskor hamar terjed az uj informacio.

Hát igen. Ekkor jön képbe tonlány barátunk a saját cachelésével és máris ttl ide vagy oda,  õk bizony sacc/kb csak min 12-16 óra múlva frissítenek, ha nem jóval késõbb. Utána jön a zenész társaság (cselló) azok aztán meg 2 nap múlva is rossz adatokat adnak vissza...
(Úgy általában a többi ismeretebb szolgáltatónál nem szokott gond lenni ebbõl)

[adam.k]

Idézet: pgyafi - Dátum: 2007. ápr. 19., csütörtök - 20:35

(Úgy általában a többi ismeretebb szolgáltatónál nem szokott gond lenni ebbõl)

Ez viszont olyan parameter, ami ellen nem nagyon tudsz tenni, nem latom, hogy ez miert kepezne itt a parbeszed reszet, hisz ahogy Te is irod: mindenki masnal ervenyesulni fog a modositas.

[Jahno]

Idézet: pgyafi - Dátum: 2007. ápr. 19., csütörtök - 21:35

Utána jön a zenész társaság (cselló) azok aztán meg 2 nap múlva is rossz adatokat adnak vissza...
(Úgy általában a többi ismeretebb szolgáltatónál nem szokott gond lenni ebbõl)

Azért Axeleronál elõfordulnak hónapos kavarások is, de ugyanúgy lehet szopni a kisebb cégeknél összerakott mindenféle egyéb local szerverekkel. Nomost ha valaki viszont ennyire nagyon rendelkezésre áll, akkor ilyenekre számítania kell, szóval ez a DNS-es átállogatás nagyon nem játszhat.

Ja, ma jött fax, valami webes marketinges tájékkoztatásról, miszerint aki webes megjelenésével szerzi a júzereit, annak garantáltan megnövelik a bevételét, meg a látogatottságot, meg mindent, csak 90-120 perc az ingyenes okítás. Erõsen gondolkozom rajt, hogy benyögöm a paramétert, hogy pont annál a cégnél mennyien reggelnek naponta, meg ilyenek, aztán hajrá  :Р :Р :Ð

[adam.k]

Idézet: Jahno - Dátum: 2007. ápr. 19., csütörtök - 20:55

Nomost ha valaki viszont ennyire nagyon rendelkezésre áll, akkor ilyenekre számítania kell, szóval ez a DNS-es átállogatás nagyon nem játszhat

Van egy RFC, amiben (legalabbis ha jol emlekszem) szerepel, hogy en, a zona tulaja miben tudom befolyasolni azon cache-eket akik az en zonambol adatot kerdeznek le.  Ez is TTL, csak egy masik :) ez is le van veve.

Tehat elvileg (_elvileg_) hiaba vannak az olyan szolgaltatok, mint a TO, aki nagy, eros es legyozhetetlen, mint a szovjetunio, ha rfc szerint mukodik, akkor sem cache-eli be az en dns-emtol kapott valaszokat.  Tehat a DNS-re alapozott atallas mukodik.

A gyakorlat ennek neha termeszetesen ellent mond, de szerencsere nem jellemzo.  Amikor megis, akkor szerencsere mar van vip ugyfelszolgalat, ahol nem a 'kerem, inditsa ujra' nenik ulnek, hanem valoban mernokok, akik ertenek a dolgokhoz.

[charlie]

Idézet: adam.k - Dátum: 2007. ápr. 19., csütörtök - 21:41

Ez viszont olyan parameter, ami ellen nem nagyon tudsz tenni, nem latom, hogy ez miert kepezne itt a parbeszed reszet, hisz ahogy Te is irod: mindenki masnal ervenyesulni fog a modositas.

azert mo.-n elegge nagy szamban neteznek userek axelero meg csello mogul...

[Nagyika]

Bocsánat az offért, de tudnátok mondani pár nagykert, ahol márkás szervereket lehet kapni?
Fõleg HP és IBM érdekelne.

Köszi

[Jahno]

Idézet: Nagyika - Dátum: 2007. máj. 4., péntek - 10:09

Bocsánat az offért, de tudnátok mondani pár nagykert, ahol márkás szervereket lehet kapni?
Fõleg HP és IBM érdekelne.

Dell-t kb. a Humansofttól, HP-t meg HPshop.hu-tól. Aztán ha drágák, akkor esetleg írsz egy mailt, mert ezeket egy átlag sarki kisker is be bírja szerezni, néha egész jó áron. Kéréds milyen kell, meg miféle.

[Ladis]

Idézet: charlie - Dátum: 2007. ápr. 20., péntek - 6:09

azert mo.-n elegge nagy szamban neteznek userek axelero meg csello mogul...

éppen ezért elég nagy számban szidják is... néhol nincs is más lehetõség!

[rendszergazda]

Épp helyet keresek egy újabb szerverem számára, így ismét megpróbáltam a GTS-Datanet-et, hátha van már hely náluk. Sajnos jelenleg sem a Budapest, Váci úti gépteremben, sem a Budaörs, Ipartelep utcai szerverfarmon nincs szabad hely, de telefonon azt mondták, hogy márciusban már elkészül a budaörsi gépterem bõvítése, és akkor már tudnak ismét gépeket fogadni - sajnos a budapesti gépterem esetleges bõvítésérõl semmi bíztatót nem tudtak mondani De a jó hír, hogy néhány hét múlva már lehet ismét gépeket betenni a budaörsi hostingba.

[rendszergazda]

Invitel-nek van datacenter-e az Ilka utcában, felhívtam õket hogy mibe kerülne ha szeretnék oda egy szervert betolni és miket nyújtanak, a 10e + 10e pénz az még elfogadható is lenne, ami meglepett hogy kérdezgetve a sávszlélességeket azt mondták, hogy 20 gépet tesznek egy 100Mb uplinkû switch-re. Direkt rákérdeztem hogy nem 100Mb-es porot adnak egy switch-rõl 20 darabot, aminek aztán gigás uplinkje van, de azt mondták hogy nem, 20 gépet tesznek rá 100Mb uplinkre. Meg hogy ha jól emlékszem az összegre havi 17e plusz pénzért adnak garantált 10Mb-et ha akarom. Ez viszont így eléggé lutri, hogy ki a másik 19 szerver azon a switch-en amire az én vasamat rákötik... Van errõl valakinek tapasztalata? Tehát valóban 100Mb-es uplinken osztozik 20 szerver, vagy csak nem tudta az Invitel-es sales-es emberke miket is beszél?!

Deninet-rõl van valakinek tapasztalata? Klíma/táp/internet menyire stabil? Bix felé 30Gb elégnek tünik, küldöld mennyire gyors, korlátozva van a külföldi sávszélesség? Operátorok mennyire segítõkészek, felveszik éjjel is a telefont ha pl. egy reset gombot kellene nyomkodni?

[adam.k]

Idézet: rendszergazda - Dátum: 2008. febr. 22., péntek - 13:50

20 gépet tesznek rá 100Mb uplinkre.

Minden altalam ismert helyen a 100mb kapcsolat azt jelenti, hogy olyan switchportot kapsz aztan kesz.  Ugy jutsz ki az uplinken ahogy birsz.  Akar giga akar nem.

Nem is latom, hogy ez miert problema.  Itt mindenki azt hiszi, hogy az elete jobb lesz ha nem 20 ember van egy switchen, hanem 10?  Semennyit nem szamit, a szuk keresztmetszet ugysem ott lesz.

Egyszerre egymillioan nezik a weben? Na es akkor mi van.  Annak sem ez a szuk keresztmetszete.  Tobb geped van es kozottuk faj a 100mb?  Ekkor amugy is sajat switchet szokas letenni.

[Jahno]

Idézet: rendszergazda - Dátum: 2008. febr. 22., péntek - 13:50

Deninet-rõl van valakinek tapasztalata?

Deninetet mindig ilyen kici occó sufnicégnek tartottam. Aztán mondjatok valami jobbat, ha valaki tud, mert sok infó nincs, hogy saját infrastruktúra, vagy a helyet is bérlik valakitõl.