Ważone okrągłe runy przez TTL - możliwe?

Obecnie używam okrągłego robota DNS do równoważenia obciążenia, co działa świetnie. Rekordy wyglądają tak (mam TTL 120 sekund)

;; ANSWER SECTION:
orion.2x.to.        116 IN  A   80.237.201.41
orion.2x.to.        116 IN  A   87.230.54.12
orion.2x.to.        116 IN  A   87.230.100.10
orion.2x.to.        116 IN  A   87.230.51.65

Dowiedziałem się, że nie każdy dostawca usług internetowych / urządzenie traktuje taką odpowiedź w ten sam sposób. Na przykład niektóre serwery DNS losowo zmieniają adresy lub zawsze je zmieniają. Niektóre tylko propagują pierwszy wpis, inne próbują ustalić, który z nich jest najlepszy (regionalnie blisko), patrząc na adres IP.

Jednak jeśli baza użytkowników jest wystarczająco duża (rozłożona na wielu dostawców usług internetowych itp.), Całkiem dobrze się równoważy. Rozbieżności między najwyższym a najniższym obciążeniem serwera prawie nie przekraczają 15%.

Jednak teraz mam problem z tym, że wprowadzam do systemów więcej serwerów i że nie wszystkie mają takie same możliwości.

Obecnie mam tylko serwery 1 Gb / s, ale chcę pracować również z serwerami 100 Mb / s, a także 10 Gb / s.

Chcę więc przedstawić serwer o przepustowości 10 Gb / s i wadze 100, serwer 1 Gb / s o wadze 10 i serwer o przepustowości 100 Mb / s o wadze 1.

Wcześniej dwukrotnie dodawałem serwery, aby zwiększyć do nich ruch (co działało dobrze - przepustowość prawie się podwoiła). Ale dodanie serwera DNS 10 Gb / s 100 razy jest trochę śmieszne.

Pomyślałem więc o użyciu TTL.

Jeśli podam serwerowi A 240 sekund TTL, a serwerowi B tylko 120 sekund (co jest w przybliżeniu minimum do użycia w przypadku rundy okrągłej, ponieważ wiele serwerów DNS ustawionych na 120, jeśli określono niższy TTL (tak słyszałem)). Myślę, że coś takiego powinno wystąpić w idealnym scenariuszu:

First 120 seconds
50% of requests get server A -> keep it for 240 seconds.
50% of requests get server B -> keep it for 120 seconds

Second 120 seconds
50% of requests still  have server A cached -> keep it for another 120 seconds.
25% of requests get server A -> keep it for 240 seconds
25% of requests get server B -> keep it for 120 seconds

Third 120 seconds
25% will get server A (from the 50% of Server A that now expired) -> cache 240 sec
25% will get server B  (from the 50% of Server A  that now expired) -> cache 120 sec
25% will have server A cached for another 120 seconds
12.5% will get server B (from the 25% of server B that now expired) -> cache 120sec
12.5% will get server A (from the 25% of server B that now expired) -> cache 240 sec

Fourth 120 seconds
25% will have server A cached -> cache for another 120 secs
12.5% will get server A (from the 25% of b that now expired) -> cache 240 secs
12.5% will get server B (from the 25% of b that now expired) -> cache 120 secs
12.5% will get server A (from the 25% of a that now expired) -> cache 240 secs
12.5% will get server B (from the 25% of a that now expired) -> cache 120 secs
6.25% will get server A (from the 12.5% of b that now expired) -> cache 240 secs
6.25% will get server B (from the 12.5% of b that now expired) -> cache 120 secs
12.5% will have server A cached -> cache another 120 secs
... I think I lost something at this point, but I think you get the idea...

Jak widać, to dość skomplikowane do przewidzenia i na pewno nie zadziała tak w praktyce. Ale to zdecydowanie powinno mieć wpływ na dystrybucję!

Wiem, że ważony okrągły robin istnieje i jest po prostu kontrolowany przez serwer root. Po prostu przełącza rekordy DNS podczas odpowiedzi i zwraca rekordy DNS z ustawionym prawdopodobieństwem, które odpowiada ważeniu. Mój serwer DNS nie obsługuje tego, a moje wymagania nie są tak precyzyjne. Jeśli nie waży idealnie, to jest w porządku, ale powinien iść we właściwym kierunku.

Myślę, że użycie pola TTL może być bardziej eleganckim i łatwiejszym rozwiązaniem - i nie wymaga serwera DNS, który kontroluje to dynamicznie, co oszczędza zasoby - co moim zdaniem jest sednem równoważenia obciążenia DNS w porównaniu do równoważenia obciążenia sprzętowego.

Moje pytanie brzmi teraz: czy są jakieś najlepsze praktyki / metody / reguły kciuka do ważenia dystrybucji robin okrągłych przy użyciu atrybutu TTL rekordów DNS?

Edytować:

System jest systemem serwera proxy do przodu. Ilość przepustowości (nie żądań) przekracza to, co może obsłużyć pojedynczy serwer z Ethernetem. Potrzebuję rozwiązania równoważącego, które rozdziela przepustowość na kilka serwerów. Czy są jakieś alternatywne metody niż używanie DNS? Oczywiście mogę użyć modułu równoważenia obciążenia z kanałem światłowodowym itp., Ale koszty są absurdalne, a także zwiększa tylko szerokość wąskiego gardła i go nie eliminuje. Jedyne, co mogę wymyślić, to adresy IP anycast (czy to anycast czy multicast?), Ale nie mam środków, aby skonfigurować taki system.

Po pierwsze, całkowicie zgadzam się z @Alnitak, że DNS nie jest przeznaczony do tego rodzaju rzeczy, a najlepszą praktyką jest nie (ab) używanie DNS jako modułu równoważenia obciążenia biednego człowieka.

Moje pytanie brzmi teraz ... czy są jakieś najlepsze szczegóły / metody / reguły kciuka do wagi za pomocą okrągłej dystrybucji robin przy użyciu atrybutu TTL rekordów DNS?

Aby odpowiedzieć na założenie pytania, podejście zastosowane do wykonania ważonego robota okrągłego bazix przy użyciu DNS to:

• Dostosuj względne występowanie rekordów w autorytatywnych odpowiedziach DNS. To Server Aznaczy, jeśli ma mieć 1/3 ruchu i Server Bma 2/3, to 1/3 autorytatywnych odpowiedzi DNS na serwery proxy DNS będzie zawierać tylko A adres IP, a 2/3 Badresu IP tylko odpowiedzi . (Jeśli 2 lub więcej serwerów ma tę samą „wagę”, można je połączyć w jedną odpowiedź).
• Utrzymuj niski poziom TTL DNS, aby stosunkowo niezrównoważone obciążenie zostało wyrównane stosunkowo szybko. Ponieważ serwery proxy niższego rzędu mają za sobą bardzo nieparzystą liczbę klientów, należy często przetasować rekordy.

Usługa DNS Route 53 firmy Amazon korzysta z tej metody .

Ilość przepustowości (nie żądań) przekracza to, co może obsłużyć pojedynczy serwer z siecią Ethernet. Potrzebuję rozwiązania równoważącego, które rozdziela przepustowość na kilka serwerów.

Dobrze. Tak więc, jak rozumiem, masz coś w rodzaju „taniego” pobierania / dystrybucji wideo / usługi pobierania dużych plików, w której całkowita przepływność usługi przekracza 1 GBit.

Bez znajomości dokładnej specyfiki usługi i układu serwera trudno jest być precyzyjnym. Ale stosowanym rozwiązaniem w tym przypadku jest:

• Runda DNS do dwóch lub więcej instancji modułu równoważenia obciążenia na poziomie TCP / IP lub HTTP.
• Każda instancja modułu równoważenia obciążenia jest wysoce dostępna (2 identyczne moduły równoważenia obciążenia współpracują przy utrzymywaniu zawsze jednego adresu IP).
• Każda instancja modułu równoważenia obciążenia za pomocą ważonego okrągłego robina lub ważonej losowej obsługi połączeń z serwerami zaplecza.

Tego rodzaju konfigurację można zbudować za pomocą oprogramowania typu open source lub za pomocą specjalnie zaprojektowanych urządzeń wielu dostawców. Równoważenie obciążenia tag tutaj jest to świetny punkt wyjścia, czy można zatrudnić adminów, którzy zrobili to wcześniej skonsultować się dla Ciebie ...

Moje pytanie brzmi teraz ... czy są jakieś najlepsze szczegóły / metody / reguły kciuka do wagi za pomocą okrągłej dystrybucji robin przy użyciu atrybutu TTL rekordów DNS?

Tak, najlepszą praktyką jest nie rób tego !!

Prosze powtarzaj za mną

• DNS nie służy do równoważenia obciążenia
• DNS nie zapewnia odporności
• DNS nie zapewnia funkcji przełączania awaryjnego

DNS służy do mapowania nazwy na jeden lub więcej adresów IP . Wszelkie kolejne wyważenia, które otrzymujesz, są wynikiem szczęścia, a nie projektu.

Spójrz na PowerDNS . Pozwala stworzyć niestandardowy backend rurowy. Zmodyfikowałem przykładowy backend DNS z równoważeniem obciążenia napisany w perlu, aby używał modułu Al Algorytm :: ConsistentHash :: Ketama. To pozwala mi ustawić dowolne wagi w taki sposób:

my $ketamahe = Algorithm::ConsistentHash::Ketama->new();

# Configure servers and weights
$ketamahe->add_bucket("192.168.1.2", 50);
$ketamahe->add_bucket("192.168.1.25", 50);

I kolejny:

# multi-colo hash
my $ketamamc = Algorithm::ConsistentHash::Ketama->new();

# Configure servers and weights
$ketamamc->add_bucket("192.168.1.2", 33);
$ketamamc->add_bucket("192.168.1.25", 33);
$ketamamc->add_bucket("192.168.2.2", 17);
$ketamamc->add_bucket("192.168.2.2", 17);

Dodałem nazwę z mojej żądanej domeny najwyższego poziomu do subdomanu, który nazywam gslb lub Global Server Load Balancing. Stamtąd wywołuję ten niestandardowy serwer DNS i wysyłam rekordy A według moich pożądanych wag.

Działa jak mistrz. Hash ketama ma przyjemną właściwość minimalnego zakłócenia istniejącej konfiguracji podczas dodawania serwerów lub dostosowywania wag.

Polecam lekturę Alternatywne serwery DNS, autor: Jan-Piet Mens. Ma tam wiele dobrych pomysłów, a także przykładowy kod.

Poleciłbym również porzucić modulację TTL. Zbliżasz się już daleko, a dodanie kolejnej kludge na górze bardzo utrudni rozwiązywanie problemów i dokumentacji.

Możesz użyć PowerDNS do wykonania ważonego okrągłego robina, chociaż rozkład obciążenia w tak niezrównoważony sposób (100: 1?) Może stać się bardzo interesujący, przynajmniej dzięki algorytmom zastosowanym w moim rozwiązaniu, w którym każdy wpis RR ma przypisaną wagę , od 1 do 100, a wartość losowa służy do dołączania lub wykluczania rekordów.

Oto artykuł, który napisałem o używaniu zaplecza MySQL w PowerDNS do ważenia RR DNS: http://www.mccartney.ie/wordpress/2008/08/wrr-dns-with-powerdns/

RIPienaar ma również kilka przykładów opartych na Ruby (przy użyciu backendu potoku PowerDNS): http://code.google.com/p/ruby-pdns/wiki/RecipeWeightedRoundRobin

Aby poradzić sobie z tego rodzaju konfiguracją, musisz spojrzeć na rozwiązanie równoważenia obciążenia. Przeczytaj Linux Virtual Server i HAProxy . Dodatkową zaletą jest to, że serwery są automatycznie usuwane z puli, jeśli ulegną awarii, a efekty są znacznie łatwiejsze do zrozumienia. Ważenie to po prostu ustawienie, które należy dostosować.