Message-ID: <19980107095225.30185.qmail@colossus.dom.de>
From: schleife@colossus.dom.de
Subject: Re: relocator
To: linux-ger@Infodrom.North.DE
Date: Wed, 7 Jan 1998 10:52:25 +0100 (CET)
In-Reply-To: <19980106224800.35580@drawbridge.in-berlin.de> from "Wolfgang Jung" at Jan 6, 98 10:48:00 pm
Wolfgang Jung
> From owner-linux-ger@finlandia.Infodrom.North.DE Tue Jan 6 23:56:57 1998
> Return-Path: <owner-linux-ger@finlandia.Infodrom.North.DE>
> From: Wolfgang Jung <woju@drawbridge.in-berlin.de>
> To: Arnold.Melm@home.ivm.de
> Cc: aj@dungeon.inka.de, efraim@deadend.argh.org, linuxger@infodrom.north.de
> Subject: Re: relocator
> References: <19980105202729.37603@dungeon.inka.de> <199801061516.QAA00680@Biene.Honig.net>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: 8bit
> X-Mailer: Mutt 0.88
> In-Reply-To: <199801061516.QAA00680@Biene.Honig.net>; from Arnold.Melm@bonn.netsurf.de on Tue, Jan 06, 1998 at 04:16:43PM +0100
> Sender: owner-linux-ger@Infodrom.North.DE
> X-Loop: linux-ger@Infodrom.North.DE
> Precedence: bulk
>
[...]
>
> das ist aber wie gesagt unabhaengig davon, ob Du auf einen HOST
> mehr als eine IP bekommen kannst.
> Es ist in jedem Fall wichtig sicherzustellen, dass ein fragender
> client immer EINE echte IP bekommt.
>
> Wie man das zZ realisiert muss man sich wohl in den derzeitigen BIND
> Sourcen ansehen muessen ;( es sei denn einer kann das kurz darstellen
>
[...]
ich seh nicht das problem. folgender auszug mag
weiterhelfen:
RFC 1794 - DNS Support for Load Balancing
[...]
Through a few IETF DNS Working Group sessions (Chaired by Rob Austein of Epilogue), it was collectively agreed upon that a number of criteria must be met:
[...]
C) Multiple addresses should be sent out. <--------------------- !
[...]
(C) would cover the possibility of a host's address being advertised as optimal, yet the machine crashed during the period within the TTL of the RR. The second-most
preferable address would be advertised second, the third-most preferable third, and so on. This would allow a reasonable stab at recovery during machine failures.
[...]
wenn man schon denselben content auf einem webserver unter verschiedenen
ip adressen hostet, wieso sollte man diese redundanz nicht auch gleichzeitig
dazu benutzen, die ausfall-sicherheit zu erhoehen.
ich sehe ein viel groesseres anderes problem, das der realisierung eines
relocators, was immer es nun zu diesem zeitpunkt sein mag, im wege steht:
bind/named ist in seiner jetzigen form nicht auf erweiterungen dieser art ausgelegt.
wie ich hoffentlich richtig sehe, waere es ein erheblicher eingriff in die struktur
des programmes, wollte man zusaetzliche "intelligenz" die antworten bei jeder nachfrage
anhand der clientadresse sortieren lassen.
ausserdem ist immer noch nicht klar, welche ausmasse die datenbank haette, die einer
derartigen clientabhaengigen sortierung der RRs zugrunde laege.
vielleicht koennte man routingprotokolle dazu missbrauchen. leider weiss ich zuwenig darueber... *grins*
ist es nicht so, dass alle autonomen router im internet saemtliche routen kennen?
ich weiss nur, dass man ungefaehr 64 mb ram braucht, damit so ein router alle diese
informationen gleichzeitig im speicher halten kann. weiss da jemand genaueres?
urls, wo ich informationen dazu finden kann? die sourcen von gated sind so gross. *zitter*
gruss
nicolai schleifer
schleife@dom.de