/ Forside / Teknologi / Operativsystemer / Linux / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Linux
#NavnPoint
o.v.n. 11177
peque 7911
dk 4814
e.c 2359
Uranus 1334
emesen 1334
stone47 1307
linuxrules 1214
Octon 1100
10  BjarneD 875
live backup af webserver
Fra : Keld Jørn Simonsen


Dato : 03-01-06 23:24

Hej!

Jeg har en webserver og en live backup, som jeg kører
en gang i døgnet via rsync ssh.

Er der en god måde at sætte det op, så, hvis den ene
maskine går ned eller bliver utilgængelig, at den anden maskine
automatisk tager over? Maskinerne står to forskellige steder.

Jeg havde tænkt noget med to A RR for den samme adresse, men
så bliver det vel tilfældigt om den ene eller den anden
maskine bliver valgt. Det ønsker jeg ikke, Jeg ønsker at den ene
maskine - masteren - altid har førsteprioritet, den anden er jo ikke
fuldt opdateret.

Hilsen
keld

 
 
Alex Holst (04-01-2006)
Kommentar
Fra : Alex Holst


Dato : 04-01-06 02:53

Keld Jørn Simonsen wrote:
> Jeg har en webserver og en live backup, som jeg kører
> en gang i døgnet via rsync ssh.
>
> Er der en god måde at sætte det op, så, hvis den ene
> maskine går ned eller bliver utilgængelig, at den anden maskine
> automatisk tager over? Maskinerne står to forskellige steder.

En lignende diskussion har lige været oppe i denne gruppe eller i
dk.edb.sikkerhed, men nu kan jeg sørme ikke finde tråden igen.

Der findes ikke nogen simpel måde at gøre hvad du ønsker. Du har selv
nævnt problemet med to A records.

En DNS entry der kun peger på master og automatisk eller manuelt skiftes
til slave serveren når masteren er nede vil blive forsinket af DNS TTL
og alle mulige dns caches rundt omkring i verdenen.

Så vidt jeg ved kan du ikke løse problemet uden at blande begge dine
ISPer, og med hvad dertil hører af BGP og venner, ind i sagen.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org

OSS/FAQ for dk.edb.sikkerhed: http://sikkerhed-faq.dk

Peter Mogensen (04-01-2006)
Kommentar
Fra : Peter Mogensen


Dato : 04-01-06 12:41

Alex Holst wrote:
> Så vidt jeg ved kan du ikke løse problemet uden at blande begge dine
> ISPer, og med hvad dertil hører af BGP og venner, ind i sagen.

Hvad med at sætte begge maskiner bag en router, der NAT'er til
master-maskinen, holder øje med om master er oppe og skifter til slave,
hvis den ikke er?
Selvfølgelig kan routeren så gå ned, men hvis man er bange for det,
skulle den vel være lettere at udskifte med en standby.

Peter

Keld Jørn Simonsen (04-01-2006)
Kommentar
Fra : Keld Jørn Simonsen


Dato : 04-01-06 15:43

Den Wed, 04 Jan 2006 12:41:25 +0100. skrev Peter Mogensen:

> Alex Holst wrote:
>> Så vidt jeg ved kan du ikke løse problemet uden at blande begge dine
>> ISPer, og med hvad dertil hører af BGP og venner, ind i sagen.
>
> Hvad med at sætte begge maskiner bag en router, der NAT'er til
> master-maskinen, holder øje med om master er oppe og skifter til slave,
> hvis den ikke er?
> Selvfølgelig kan routeren så gå ned, men hvis man er bange for det,
> skulle den vel være lettere at udskifte med en standby.

Joeh, men de to maskiner står fysisk to forskellige steder, og de
kører forskellige operativsystemer. Så det tror jeg ikke er aktuelt.
Jeg kunne selvfølgelig sætte en tredje maskine op samme sted som
masteren og så lave det der foreslås. Hmm.

Jeg tænkte på noget ala MX records, og det kan jeg naturligvis bruge for
posten.

Det mest oplagte er vel at have DNS indgange med lav TTL, og så
skifte over når/hvis problemet opstår.

Benny Amorsen (05-01-2006)
Kommentar
Fra : Benny Amorsen


Dato : 05-01-06 10:12

>>>>> "KJS" == Keld Jørn Simonsen <keld@dkuug.dk> writes:

KJS> Det mest oplagte er vel at have DNS indgange med lav TTL, og så
KJS> skifte over når/hvis problemet opstår.

Det virker bare ikke i praksis. Der er rigtigt mange rekursive
DNS-servere, som er konfigureret til at sætte TTL til f.eks. 3 uger
hvis den er mindre end f.eks. 24 timer.

Hvorfor nogle skulle vælge at miskonfigurere deres servere så groft
kan man kun gisne om; de bedste forsøg på forklaringer har været at
folk er bange for at deres servere bliver overbelastet hvis der
benyttes lave TTL'er. Jeg har endnu aldrig set en seriøst belastet
rekursiv DNS-server, hvor belastningen ikke skyldtes fejlkonfigurerede
klienter (og så hjælper det ikke at lege med TTL).


/Benny


Kim Emax (04-01-2006)
Kommentar
Fra : Kim Emax


Dato : 04-01-06 14:26

Alex Holst wrote:

> En DNS entry der kun peger på master og automatisk eller manuelt skiftes
> til slave serveren når masteren er nede vil blive forsinket af DNS TTL
> og alle mulige dns caches rundt omkring i verdenen.

Du kan jo have slaven stående på samme net, og lade den overtage IP
adressen på masteren, hvis den er nede. Det er en hurtig og smertefri
process (som dog bliver anderledes forvirret, hvis masteren skulle finde
på at vågne igen og gøre krav på sin IP

--
Kim Emax

Peter Mogensen (04-01-2006)
Kommentar
Fra : Peter Mogensen


Dato : 04-01-06 14:45

Kim Emax wrote:
> Du kan jo have slaven stående på samme net, og lade den overtage IP
> adressen på masteren, hvis den er nede. Det er en hurtig og smertefri
> process (som dog bliver anderledes forvirret, hvis masteren skulle finde
> på at vågne igen og gøre krav på sin IP
>

Eller hvis masteren ikke går helt ned, men stadig kræver sit IP, dog
uden at ville køre HTTP eller TCP.

Peter

Kim Emax (04-01-2006)
Kommentar
Fra : Kim Emax


Dato : 04-01-06 20:10

Peter Mogensen wrote:

> Eller hvis masteren ikke går helt ned, men stadig kræver sit IP, dog
> uden at ville køre HTTP eller TCP.

så kan man jo selv give den en ny eller i værste fald smide eth0|1

--
Kim Emax

Kristian Vilmann (04-01-2006)
Kommentar
Fra : Kristian Vilmann


Dato : 04-01-06 19:35

Kim Emax wrote:
> Alex Holst wrote:
>
>> En DNS entry der kun peger på master og automatisk eller manuelt
>> skiftes til slave serveren når masteren er nede vil blive forsinket af
>> DNS TTL og alle mulige dns caches rundt omkring i verdenen.
>
>
> Du kan jo have slaven stående på samme net, og lade den overtage IP
> adressen på masteren, hvis den er nede. Det er en hurtig og smertefri
> process (som dog bliver anderledes forvirret, hvis masteren skulle finde
> på at vågne igen og gøre krav på sin IP

Det kan håndteres ved at lægge webserveren under heartbeat-kontrol.

/k

Keld Jørn Simonsen (04-01-2006)
Kommentar
Fra : Keld Jørn Simonsen


Dato : 04-01-06 15:53

Den Wed, 04 Jan 2006 02:53:00 +0100. skrev Alex Holst:

> En DNS entry der kun peger på master og automatisk eller manuelt skiftes
> til slave serveren når masteren er nede vil blive forsinket af DNS TTL
> og alle mulige dns caches rundt omkring i verdenen.

Er det ikke kun TTL den er afhængig af? Hvis TTL er overskredet må man
jo ikke bruge cachen, men skal spørge en autoritativ DNS igen.

Keld

Christian Laursen (04-01-2006)
Kommentar
Fra : Christian Laursen


Dato : 04-01-06 16:11

Keld Jørn Simonsen <keld@dkuug.dk> writes:

> Den Wed, 04 Jan 2006 02:53:00 +0100. skrev Alex Holst:
>
>> En DNS entry der kun peger på master og automatisk eller manuelt skiftes
>> til slave serveren når masteren er nede vil blive forsinket af DNS TTL
>> og alle mulige dns caches rundt omkring i verdenen.
>
> Er det ikke kun TTL den er afhængig af? Hvis TTL er overskredet må man
> jo ikke bruge cachen, men skal spørge en autoritativ DNS igen.

Der findes et væld af applikationer, der selv cacher DNS og er fløjtende
ligeglade med TTL. SVJH er det meget populært i fx. webbrowsere.

--
Christian Laursen

Kent Friis (04-01-2006)
Kommentar
Fra : Kent Friis


Dato : 04-01-06 18:33

Den Wed, 04 Jan 2006 16:10:50 +0100 skrev Christian Laursen:
> Keld Jørn Simonsen <keld@dkuug.dk> writes:
>
>> Den Wed, 04 Jan 2006 02:53:00 +0100. skrev Alex Holst:
>>
>>> En DNS entry der kun peger på master og automatisk eller manuelt skiftes
>>> til slave serveren når masteren er nede vil blive forsinket af DNS TTL
>>> og alle mulige dns caches rundt omkring i verdenen.
>>
>> Er det ikke kun TTL den er afhængig af? Hvis TTL er overskredet må man
>> jo ikke bruge cachen, men skal spørge en autoritativ DNS igen.
>
> Der findes et væld af applikationer, der selv cacher DNS og er fløjtende
> ligeglade med TTL. SVJH er det meget populært i fx. webbrowsere.

Der er også ISP'er der sætter en minimum TTL, så deres DNS-servere
ikke står og spørger konstant bare fordi en eller anden knold der ikke
kan finde ud af at DNS har sat den til 1 sekund. Og når de så er
igang, kan de jo sagtens sætte den til minimum 24 timer, det er jo
kun deres egne kunder der opdager noget, og der giver man bare
webserver'ens DNS skylden.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

Niels Callesøe (04-01-2006)
Kommentar
Fra : Niels Callesøe


Dato : 04-01-06 08:35

Keld Jørn Simonsen wrote:

> Jeg havde tænkt noget med to A RR for den samme adresse, men
> så bliver det vel tilfældigt om den ene eller den anden
> maskine bliver valgt. Det ønsker jeg ikke, Jeg ønsker at den ene
> maskine - masteren - altid har førsteprioritet, den anden er jo ikke
> fuldt opdateret.

Den tråd Alex tænker på, er faktisk kun nogle dage gammel, her i
gruppen. Den hedder "Forespørgsler fra andert end default gateway?".

Du kan lede tilbage efter den, eller du kan gå direkte til mit svar:
Message-ID: <Xns973D30ABC2Ck5j6h4jk3@62.243.74.163>

--
Niels Callesøe - dk pfy
pfy[at]nntp.dk - http://www.t29.dk/~nica/disclaimer.php

Helt kort: Nej, det kan du ikke.

Anders Larsson \(fje~ (08-01-2006)
Kommentar
Fra : Anders Larsson \(fje~


Dato : 08-01-06 10:37

Bla. ZoneEdit tilbyder denne service - 10$ årligt (og ja - de har en DK
godkendt DNS)

Man angiver server IP'er, responses og den fjerner/skifter selv serveren fra
DNS'en hvis den fejler. Evnt. kan man angive en anden server hvis ingen af
de "normale" reagerer, til f.eks. at oplyse at servicen midlertidigt er ude
af drift.

http://www.zoneedit.com/doc/faq.html#faq47

Deres DNS services fungerer ganske fortrinligt

--
MVH Anders (8900)
Det er fordi det er nemmere at læse - vi læser jo ikke nedefra og op.
Hvorfor skal man skrive svaret under det man svarer ?
..



Søg
Reklame
Statistik
Spørgsmål : 177559
Tips : 31968
Nyheder : 719565
Indlæg : 6408938
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste