Чи достатньо хороший DNS Round-Robin DNS для навантаження врівноваження статичного вмісту?

У нас є набір спільного, статичного вмісту, який ми розміщуємо між нашими веб-сайтами на веб-сайті http://sstatic.net . На жаль, наразі цей вміст взагалі не збалансований - він подається з одного сервера. Якщо на цьому сервері є проблеми, усі сайти, які покладаються на нього, фактично закриваються, оскільки спільні ресурси є важливими бібліотеками та зображеннями спільного JavaScript.

Ми розглядаємо способи завантаження балансу статичного вмісту на цьому сервері, щоб уникнути залежності одного сервера.

Я усвідомлюю, що DNS-круїн - це в кращому випадку рішення низького рівня (дехто може сказати навіть гетто ), але я не можу не задатися питанням - чи круглий DNS DNS - «досить гарне» рішення для базового балансування навантаження статичного вмісту ?

Про це є деяке обговорення в тегах [dns] [збалансування навантаження] , і я прочитав кілька чудових дописів на цю тему.

Мені відомо про загальні недоліки врівноваження навантаження DNS за допомогою декількох записів на круговій обробці A:

• зазвичай немає серцебиття або виявлення несправностей із записами DNS, тому якщо даний сервер під час обертання знижується, його запис A потрібно видалити вручну з записів DNS
• час жити (TTL) повинен обов'язково встановлюватися досить низьким, щоб це взагалі працювало, оскільки записи DNS кешуються агресивно в усьому Інтернеті
• клієнтські комп’ютери відповідають за те, що є кілька записів A і вибирають правильну

Але чи достатньо хороший DNS з круглим роботом як стартер, а краще нічого, "поки ми досліджуємо та впроваджуємо кращі альтернативи", форма балансування навантаження для нашого статичного вмісту? Або DNS кругової в значній мірі не приносять користі при будь-яких обставинах?

Джефф, я не згоден, балансування навантаження не передбачає надмірності, насправді навпаки. Чим більше серверів у вас, тим більше шансів на те, що в даний момент ви отримаєте збій. Ось чому резервування є обов'язковим при виконанні балансування навантаження, але, на жаль, існує маса рішень, які забезпечують балансування навантаження, не проводячи жодної перевірки стану здоров'я, що призводить до менш надійної послуги.

DNS-круглий робін відмінно збільшує пропускну здатність, розподіляючи навантаження по декількох точках (потенційно географічно розподілений). Але це не забезпечує відмову. Спочатку ви повинні описати, який тип відмови ви намагаєтеся покрити. Помилка сервера повинна бути усунена локально, використовуючи стандартний механізм поглинання IP-адрес (VRRP, CARP, ...). Відмова комутатора покривається стійкими посиланнями на сервері до двох комутаторів. Невдача посилання WAN може бути покрита налаштуванням багатопосилань між вами та вашим провайдером, використовуючи протокол маршрутизації або рішення layer2 (наприклад: PPP з кількома посиланнями). Помилка сайту повинна покриватися BGP: ваші IP-адреси реплікуються на кількох сайтах, і ви оголошуєте їх у мережі лише там, де вони доступні.

З вашого запитання виходить, що вам потрібно лише надати рішення про відмову сервера, що є найпростішим рішенням, оскільки воно не передбачає жодної апаратури, ані контракту з будь-яким провайдером. Вам просто потрібно встановити відповідне програмне забезпечення на своєму сервері, і це, безумовно, найдешевше і надійне рішення.

Ви запитували "що робити, якщо гастрокси машина не виходить з ладу?". Це ж. Усі люди, яких я знаю, які використовують хапрокси для врівноваження навантаження та підвищеної доступності, мають дві машини і на них працюють або ucarp, keepalived, або серцебиття, щоб гарантувати, що одна з них завжди доступна.

Сподіваючись, що це допомагає!

Як балансування навантаження, це гетто, але більш-менш ефективно. Якщо у вас був один сервер, який перепадав від навантаження, і хочете поширити його на кілька серверів, це може бути вагомою причиною зробити це хоча б тимчасово.

Існує низка обгрунтованих заперечень щодо кругоспроможного DNS як навантаження "балансування", і я б не рекомендував робити це для іншого, крім як короткочасної допомоги в діапазоні.

Але ви кажете, що ваша основна мотивація - уникнути залежності від одного сервера. Без автоматизованого способу зняття мертвих серверів з обертання це не дуже цінно як спосіб запобігання простоїв. (Завдяки автоматизованому способу витягування серверів з обертання та короткого TTL, це стає відмовою від гетто. Вручну це навіть не так.)

Якщо один з двох ваших сервісів з круглими роботами опуститься, то 50% ваших клієнтів отримають збій. Це краще, ніж 100% збій лише з одним сервером, але майже будь-яке інше рішення, яке зробило справжню відмову, було б краще за це.

Якщо ймовірність виходу з ладу одного сервера становить N, для двох серверів ваша ймовірність становить 2N. Без автоматизованого, швидкого відмови, ця схема збільшує ймовірність того, що у деяких ваших користувачів виникне збій.

Якщо ви плануєте зняти мертвий сервер з обертання вручну, ви обмежені швидкістю, з якою ви можете це зробити, і DNS TTL. Що робити, якщо сервер гине о 4 ранку? Найкраща частина справжньої аварії - спати протягом ночі. Ви вже використовуєте HAProxy , тому вам слід ознайомитися з ним. Я настійно пропоную використовувати його, оскільки HAProxy розроблений саме для цієї ситуації.

Круглий DNS - це не те, що люди думають, що це. Як автор серверного програмного забезпечення DNS (а саме BIND ), ми отримуємо користувачів, які задаються питанням, чому їх круглень перестає працювати, як було заплановано. Вони не розуміють, що навіть при TTL 0 секунд, буде кешовано деяку кількість кешування, оскільки деякі кеші приділяють мінімальний час (часто 30-300 секунд), незважаючи ні на що.

Крім того, хоча ваші AUTH-сервери можуть робити кругообіг, немає жодної гарантії, ті, про кого ви дбаєте, - кеші, з якими говорять ваші користувачі. Коротше кажучи, кругла робота не гарантує замовлення з точки зору клієнта, лише те, що надають ваші аут-сервери в кеш.

Якщо ви хочете реальної відмови, DNS - це лише один крок. Перерахувати більше однієї IP-адреси для двох різних кластерів не погано, але я б застосував іншу технологію (наприклад, простий anycast), щоб зробити балансування фактичного навантаження. Я особисто зневажаю апаратне обладнання для балансування навантаження, яке маніпулює з DNS, оскільки зазвичай це неправильно. І не забувайте, що DNSSEC приходить, тому якщо ви щось вирішите в цій області, запитайте у продавця, що станеться під час підписання вашої зони.

Я вже говорив про це кілька разів, і я повторю це ще раз - якщо стійкість - це проблема, то прийоми DNS - це не відповідь .

Найкращі системи HA дозволять вашим клієнтам продовжувати використовувати таку саму IP-адресу для кожного запиту. Це єдиний спосіб гарантувати, що клієнти навіть не помічають несправності.

Отже, основне правило полягає в тому, що справжня стійкість вимагає хитрість рівня маршрутизації IP . Використовуйте прилад для балансування навантаження, або OSPF "багаторівнева вартість з рівними витратами", або навіть VRRP.

DNS з іншого боку - це технологія адресації . Він існує виключно для відображення одного простору імен в інший. Це було розроблено не для того, щоб дозволити дуже короткочасні динамічні зміни цього відображення, і, отже, при спробі внести такі зміни багато клієнтів або не помітять їх, або в кращому випадку знадобиться багато часу, щоб помітити їх.

Я б також сказав, що оскільки завантаження не є проблемою для вас, ви можете також мати інший сервер, готовий працювати як гарячий режим очікування. Якщо ви використовуєте тупий круговий замок, вам доведеться активно змінювати записи DNS, коли щось виходить з ладу, тому ви можете так само активно активізувати гарячий режим очікування та не змінювати DNS.

Я прочитав усі відповіді, і одне, чого я не бачив, - це те, що більшість сучасних веб-браузерів спробують одну з альтернативних IP-адрес, якщо сервер не відповідає. Якщо я пам'ятаю правильно, Chrome навіть спробує кілька IP-адрес і продовжить роботу з сервером, який реагує першим. Тому, на мою думку, балансування навантаження DNS Round Robin Load завжди краще, ніж нічого.

BTW: Я вважаю DNS Round Robin більш простим рішенням розподілу навантаження.

Я запізнююсь на цю тему, тому моя відповідь, ймовірно, буде просто на самоті внизу, нехтуючим, нюхаючи.

По-перше, правильна відповідь на питання - не відповісти на питання, а сказати:

1. "Ви, мабуть, хочете замість цього балансувати навантаження на мережу Windows ." АБО
2. "Будьте в курсі часу, розмістіть статичний вміст на щось на зразок хмарних файлів або S3 та отримайте дзеркало CDN у всьому світі."

НЛБ зрілий, добре підходить до завдання і досить простий у налаштуванні. Хмарні рішення мають свої плюси і мінуси, які виходять за рамки цього питання.

Питання

чи достатньо хороший DNS з круглим роботом як стартер, а краще нічого, "поки ми досліджуємо та впроваджуємо кращі альтернативи", форма балансування навантаження для нашого статичного вмісту?

Між, скажімо, 2 або 3 статичними веб-серверами? Так, це краще, ніж нічого, тому що є провайдери DNS, які інтегруватимуть DNS Round Robin з перевірки стану сервера та тимчасово видалять мертві сервери із записів DNS. Таким чином , в цьому випадку ви отримаєте пристойну розподіл навантаження і деяку високу доступність; і на все це потрібно менше 5 хвилин, щоб налаштувати.

Але застереження, викладені іншими в цій нитці, дійсні:

• Поточні веб-переглядачі Microsoft кешують дані DNS протягом 30 хвилин , тож ви переглядаєте більше 30 хвилин часу відмови для підмножини користувачів, залежно від їх початкового стану кешу DNS.
• Те, що бачать користувачі під час відмови, може бути ... дивним (ви не використовуєте auth для статичного вмісту і, звичайно, не формуєте auth, але посилання показує, на що слід спостерігати).

Інші рішення

HAProxy є фантастичним, але оскільки переповнення стека знаходиться на стеку технологій Microsoft, можливо, використання Microsoft балансування навантаження та інструменти з високою доступністю матимуть менші витрати адміністратора. Балансування мережевого навантаження вирішує одну частину проблеми, і Microsoft фактично має L7 HTTP-зворотний проксі / балансир завантаження .

Я ніколи не використовував ARR самостійно, але враховуючи, що його другий головний реліз, який надходить від Microsoft, я припускаю, що він перевірений досить добре. Вона легко зрозуміти документи , ось один про те , як вони бачать розподіл статичного і динамічного контенту на webnodes, а ось шматок про те , як використовувати ARR з NLB для досягнення як розподіл навантаження і високу доступність.

Примітно, що багато хто з учасників допомагає внести неінформаційну інформацію про DNS Round Robin як механізм розподілу навантаження та стійкості. Це зазвичай працює, але вам потрібно зрозуміти, як це працює, і уникати помилок, спричинених усією дезінформацією.

1) TTL для записів DNS, що використовується для Round Robin, повинен бути коротким - але НЕ ЗЕРО. Наявність TTL на нулі розбиває основний спосіб забезпечення стійкості.

2) DNS RR поширюється, але не врівноважує навантаження, він поширює його, оскільки на великій клієнтській базі вони, як правило, запитують DNS-сервер самостійно, і таким чином закінчуються різними записами DNS першого вибору. Ці різні перші варіанти означають, що клієнтів обслуговують різні сервери, а навантаження розподіляється. Але все залежить від того, який пристрій виконує запит DNS і як довго він тримає результат. Поширеним прикладом є те, що всі клієнти, що стоять за корпоративним проксі-сервером (який виконує для них DNS-запит), в кінцевому підсумку орієнтуються на один сервер Навантаження розподілена - але вона не збалансована рівномірно.

3) DNS RR забезпечує стійкість до тих пір, поки клієнтське програмне забезпечення його належним чином реалізує (і TTL, і тривалість уваги користувачів не надто короткі). Це відбувається тому, що кругла версія DNS забезпечує впорядкований список IP-адрес сервера, і клієнтське програмне забезпечення повинно намагатися зв’язатися з кожним з них по черзі, поки не знайде сервер, який приймає з'єднання.

Отже, якщо сервер першого вибору відсутній, тоді клієнт TCP / IP закінчується, і якщо термін дії TTL чи уваги не закінчився, клієнтське програмне забезпечення робить ще одну спробу підключення до другого запису в списку - і так далі до Термін дії TTL закінчується, або він потрапляє до кінця списку (або користувач відступає від огиди).

Довгий список зламаних серверів (ваша вина) та великі межі спроб підключення TCP / IP (неправильна конфігурація клієнта) може скласти довгий період, перш ніж Клієнт дійсно знайде працюючий сервер. Занадто короткий TTL означає, що він ніколи не дістає свою роботу до кінця списку, а натомість видає новий запит DNS і отримує новий список (сподіваємось, в іншому порядку).

Іноді Клієнт не пощастить, і новий список все ще починається зі зламаних серверів. Щоб надати системі найкращі шанси забезпечити стійкість клієнта, ви повинні переконатися, що TTL довший, ніж типовий проміжок уваги, і щоб клієнт потрапив до нижньої частини списку.

Після того, як клієнт знайшов працюючий сервер, він повинен запам'ятати його, і коли йому потрібно встановити наступне з'єднання, він не повинен повторювати пошук (якщо термін TTL не закінчився). Більш довгий TTL зменшує частоту, з якою користувачі відчувають затримку, поки клієнт шукає працюючий сервер - надаючи кращий досвід.

4) DNS TTL стає своїм, коли ви хочете вручну змінити записи DNS (наприклад, видалити довгостроковий зламаний сервер), тоді короткий TTL дозволяє цій зміні швидко поширюватися (як тільки ви зробите це зробити), так врахуйте баланс між тим, як триватиме час, перш ніж дізнатися про проблему, і внесіть цю зміну вручну - і тим, що нормальним клієнтам доведеться лише новий пошук робочого сервера, коли термін TTL закінчиться.

DNS круглий робот має дві видатні особливості, що робить його економічно вигідним у широкому діапазоні сценаріїв - по-перше, його безкоштовно, а по-друге, він майже такий же географічно розсіяний, як і клієнтська база.

Він не вводить нову "одиницю відмови", яку роблять усі інші "розумні" системи. Немає додаткових компонентів, які могли б мати спільний та одночасний збій протягом усього навантаження взаємопов'язаних елементів.

"Розумні" системи чудові та вводять чудові механізми для координації та забезпечення безперебійного балансування та відмови від механізму, але в кінцевому підсумку саме ті методи, які вони використовують для забезпечення безперешкодного досвіду, - це їхня ахіллесова п'ята - додаткова складна річ, яка може піти не так, і коли це стане, забезпечить безперебійний досвід відмов системи в цілому.

Так ТАК, кругла робота DNS, безумовно, "достатньо хороша" для вашого першого кроку за межі одного сервера, в якому розміщений весь ваш статичний вміст в одному місці.

Windows Vista та Windows 7 реалізують підтримку клієнтів для круглої роботи по-різному, оскільки вони підтримували вибір IPv6 адреси на IPv4. ( RFC 3484 )

Отже, якщо у вас є значна кількість користувачів Vista, Windows 7 та Windows 2008, ви, швидше за все, виявите поведінку, що не відповідає плануваному мисленню, у вашому рівноважному рішенні навантаження на ersatz.

Я завжди використовував Round-Robin DNS, з довгим TTL, як балансир навантаження. Це дуже добре працює для HTTP / HTTPS-послуг із браузерами .

Я дійсно наголошую на браузерах, оскільки більшість браузерів реалізує якесь «повторення іншої IP-адреси», але я не знаю, як би інші бібліотеки або програмне забезпечення обробляли рішення з кількома IP-адресами.

Коли браузер не отримає відповіді з одного сервера, він автоматично зателефонує до наступного IP-адреси, а потім дотримується його (до тих пір, поки він не знищиться ..., а потім спробує ще один).

Ще в 2007 році я зробив наступний тест:

• додайте iframe на моєму веб-сайті, вказуючи на один запис у Round-Robin, наприклад http://roundrobin.test:10080/ping.php
• сторінку обслуговували 3 розетки PHP, прослуховуючи IP-адреси 3 різних, все на порт 10080 (я не міг собі дозволити тестування на порт 80, оскільки мій веб-сайт працює на ньому)
• один сокет (скажімо, A ) був там, щоб перевірити, чи може браузер підключитися до порту 10080 (оскільки багато компаній дозволяють лише стандартні порти)
• інші дві розетки (скажімо, B і C ) можуть бути включені або відключені під час руху.

Я дав їй пробігти одну годину, мав багато даних. Результати полягали у тому, що для 99,5% звернень у сокет A я потрапив або на сокет B, або на C (я, звичайно, не відключив обидва ці можливості). Браузерами були: iPhone, Chrome, Opera, MSIE 6/7/8, BlackBerry, Firefox 3 / 3.5 ... Тож навіть невідповідні браузери справлялися з цим правильно!

До сьогоднішнього дня я ніколи не тестував його знову, але, можливо, я встановлю новий тест одного дня або випущу код на github, щоб інші могли його перевірити.

Важлива примітка: навіть якщо вона працює більшу частину часу, це не усуває факту, що деякі запити не вдасться. Я також використовую його для запитів POST, оскільки моя програма поверне повідомлення про помилку, якщо воно не працює, так що користувач може знову надіслати дані, і, швидше за все, браузер буде використовувати інший IP-адресу в цьому випадку, і збереження буде працювати . А для статичного вмісту він працює справді чудово.

Тож якщо ви працюєте з браузерами, використовуйте DNS Round-Robin DNS або для статичного, або для динамічного вмісту, ви будете здебільшого добре. Сервери також можуть знижуватися в середині транзакції, і навіть з найкращим балансиром навантаження ви не можете впоратися з такою справою. Для динамічного контенту вам потрібно зробити сеанси / базу даних / файли синхронними, інакше ви не зможете впоратися з цим (але це також справедливо з реальним балансиром навантаження).

Додаткова примітка: ви можете перевірити поведінку на власному IP-адресі, використовуючи iptables. Наприклад, перед правилом брандмауера для HTTP-трафіку додайте:

iptables -A INPUT -p tcp --dport 80 --source 12.34.56.78 -j REJECT

(де 12.34.56.78, очевидно, ваш IP)

Не використовуйте DROP, оскільки він залишає порт відфільтрованим , і ваш браузер буде чекати до часу очікування. Тож тепер ви можете ввімкнути або відключити один чи інший сервер. Найбільш очевидний тест - відключити сервер A, завантажити сторінку, потім увімкнути сервер A та відключити сервер B. Коли ви знову завантажите сторінку, ви побачите трохи почекати від браузера, потім він завантажиться з сервера Знову. У Chrome ви можете підтвердити IP-адресу сервера, переглянувши запит на мережевій панелі. На Generalвкладці Headersви побачите підроблений заголовок з назвою Remote Address:. Це IP, звідки ви отримали відповідь.

Отже, якщо вам потрібно перейти в режим обслуговування на одному сервері, просто відключіть трафік HTTP / HTTPS одним iptables REJECTправилом, всі запити будуть спрямовані на інші сервери (з одним маленьким зачеканням, що майже не помітно для користувачів).

Я не думаю, що це досить гарне рішення, тому що скажімо, у вас зараз два сервери, і ви обходите Robin, використовуючи DNS для IP-адреси кожного сервера. Коли один сервер виходить з ладу, DNS-сервери не знають, що він знизився і надалі буде обслуговувати цю IP-адресу в рамках процесу RR. Тоді 50% вашої аудиторії отримає зламаний сайт, у якому відсутні JavaScript або зображення.

Можливо, простіше вказати на загальну IP-адресу, яку обробляє Windows NLB, що представляє два сервери позаду. Якщо ви не використовуєте сервер Linux для свого статичного вмісту, якщо я пам’ятаю, що десь читав?

Балансування навантаження на круговій обробці працює лише тоді, коли ви також керуєте зоною DNS, щоб ви могли своєчасно змінити список серверів і вчасно надіслати його майстрам зони.

Як вже згадувалося в одній з інших відповідей, приховане зло круглого робота - це кешування DNS, яке може статися в будь-якому місці між вашими серверами та клієнтом, що повністю заперечує невелику перевагу цього рішення. Навіть якщо DNS TTL встановлений на дуже низьке значення, ви мало керуєте тим, як довго кеш DNS або навіть клієнтський DNS-кеш буде підтримувати активну теперішню IP-адресу.

Це поліпшення порівняно із SPOF напевно, але лише незначне. Я хотів би поглянути на те, хто коли-небудь розміщує ваш сервер, і побачити, що вони можуть запропонувати, у багатьох є якась основна послуга балансування навантаження, яку вони можуть надати.

Ви також можете мати один сервер зі статичним вмістом, дубльованим у S3, і перейти на S3 CNAME, коли ваш основний знизиться. Ви закінчитеся з тією ж затримкою, але без кількох витрат на сервер.

Це дійсно залежить від того, про що ви говорите, і скільки серверів ви обертаєтеся. Колись у мене був сайт, який працював на декількох серверах, і я використовував DNS-круглий робот на цьому через, головним чином, свого часу початківця, і це справді не було великою проблемою. Це не було великим питанням, оскільки воно не зазнало краху. Це була по-справжньому дурна не складна система, тому вона підтримувала і мала досить постійний рівень трафіку. Якби він зазнав аварії від руху, це було протягом дня, і я можу легко подбати про це. Я б сказав, що ваш статичний вміст визначається як простий, щоб не викликати збоїв самостійно.

Поза відмов обладнання тощо, наскільки стабільним був ваш сервер? Наскільки "spikey" ваш трафік на цьому вмісті? Якщо припустити Apache або щось подібне та відносно рівний трафік, він не збирається сильно катастрофізувати, і я б сказав, що круглий робін "досить хороший".

Я впевнений, що я проголосую, тому що я не проповідую 100% рішення НА, але це не те, про що ви просили. Це зводиться до того, що ви готові прийняти як рішення проти витрачених зусиль.

Якщо ви використовували RR DNS для балансування навантаження, було б добре, але ви цього не зробите. Ви використовуєте його для ввімкнення резервного сервера, в цьому випадку це непогано.

Як говорилося в попередньому дописі, вам потрібно щось виявити серцебиття і перестати бити його, поки воно не повернеться.

Хороша новина - серцебиття доступне дуже дешево, або в комутаторах, або в Windows.

Давно про інші ОС, але я припускаю, що він також є.

Я пропоную вам призначити додаткову IP-адресу для кожного з ваших серверів (крім статичного IP-адреси, який ви використовуєте, скажімо, для ssh), і перенесіть його в пул DNS. А потім ви використовуєте якесь програмне забезпечення для перемикання цих IP-адрес у випадку відмови сервера. Наприклад, серцебиття або CARP можуть це зробити, але є й інші рішення.

Це має перевагу в тому, що для клієнтів вашої послуги нічого не повинно змінюватись у налаштуваннях, і вам не доведеться турбуватися про кешування DNS або TTL, але ви все одно можете скористатись "балансуванням навантаження" навколо DNS. .

Це, ймовірно, зробить цю роботу, особливо якщо у вас на статичних полях може бути кілька IP-адрес. мають один IP-сервер "обслуговувати статичний контент" та один IP-адрес "керувати машиною". Якщо поле знизиться, ви можете використовувати існуюче рішення HA або вручну втручатись, щоб підняти IP від ​​несправної машини або на одному з інших "членів кластера", або на абсолютно новій машині (залежно від того, наскільки швидко це було б щоб почати це працювати).

Однак таке рішення матиме деякі невеликі питання. Збалансування навантаження не буде десь близьким до ідеального, і якщо ви покладаєтесь на ручне втручання, у деяких відвідувачів може виникнути перебої.

Апаратний балансир завантаження, ймовірно, може зробити кращу роботу як для розподілу навантаження, так і для надання «часу роботи кластеру», ніж волонтер DNS. Що стосується зворотного боку, це один (або два), оскільки в ідеалі у вас є LB в кластері HA) обладнання, яке потребує покупки, потужності та охолодження та (можливо) деякий час для ознайомлення (якщо ви ще цього не зробили) мають виділені балансири навантаження).

Щоб коротко відповісти на цей питання ( по круговій DNS досить хороший в якості стартера, краще , ніж нічого "в той час як ми досліджуємо і реалізувати кращі альтернативи» форма балансування навантаження для нашого статичного контенту?), Я б сказав , що це краще , ніж нічого, але вам обов'язково слід продовжувати дослідження інших форм збалансування навантаження.

Коли я досліджував балансування завантаження Windows, кілька років тому я побачив документ, який зазначав, що веб-ферма Майкрософт налаштована як декілька груп, що збалансують навантаження, з круглим DNS між ними. Оскільки у кожного простору імен можна реагувати на кілька серверів DNS, і оскільки балансування навантаження Microsoft самозцілюється, це забезпечує як надмірність, так і балансування навантаження.

Знизу: вам потрібно щонайменше 4 сервери (2 сервери х 2 групи).

Відповідаючи на коментар Джеффа щодо відповіді Шофа, чи є спосіб переключення DNS в обмін між серверами HAProxy?

Він має дуже незначне використання, достатньо, щоб вас обминути, поки ви поставите реальне рішення. Як ви кажете, TTL повинні бути встановлені досить низькими. Це, однак, має побічну вигоду, як витягнути з DNS проблемну машину, хоча вона має проблеми. Скажімо, у вас є SvrA, SvrB і SvrC, які передають ваш вміст, і SvrA знижується. Ви витягнете його з DNS, і через короткий проміжок часу, визначений вашим низьким TTL, роздільники з'ясують інший сервер (SvrB або SvrC), який працює. Ви повертаєте SvrA онлайн і повертаєте її назад у DNS. Короткий час простою для деяких людей, жоден для інших. Не великий, але працездатний. Чим більше статичних серверів ви вкладете в суміш, тим менше шансів на те, що ви будете мати більшість груп користувачів.

Ви точно не отримаєте справжнього збалансованого розподілу, яке забезпечить реальне рішення щодо збалансування навантаження завдяки топології Інтернету. Я б все ще спостерігав за навантаженням на всі задіяні сервери.