100% часу роботи веб-програми

Сьогодні ми отримали цікаву «вимогу» від клієнта.

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

Однак з питань мережі я просто не можу зрозуміти, як змусити її працювати.

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

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

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

Ідеї?

ОНОВЛЕННЯ

Я сьогодні мав дискусію з клієнтом, і вони уточнили це питання.

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

Ось зручна діаграма Вікіпедії про пошук дев'яти:

Цікаво, що лише 3 з 20 найкращих веб-сайтів змогли досягти міфічних 5 дев'яток або 99,999% часу роботи в 2007 році. Це Yahoo, AOL та Comcast. У перші 4 місяці 2008 року деякі з найпопулярніших соціальних мереж навіть не наблизилися до цього.

З діаграми повинно бути видно, наскільки смішним є досягнення 100% безперервного часу ...

Попросіть їх визначити 100% і як це буде вимірюватися протягом якого періоду часу. Вони, ймовірно, означають близько 100%, наскільки вони можуть собі дозволити. Дайте їм калькуляцію.

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

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

Я б попросив клієнта визначити, що буде з точки зору впливу / витрат на бізнес, якщо сайт запуститься за таких обставин:

• У найпотужніші години х годин
• У їх найменш зайняті години по х годин

А також як вони це вимірять.

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

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

Однак це означає, що ви, мабуть, володієте механікою масштабування / розповсюдження самої програми. Частина мереж потребує залучення зайвих посилань на різні Інтернет-провайдери, отримання розподілу ASN та IP, а також отримання ширини BGP та реального механізму маршрутизації, щоб простір IP-адреси міг пересуватися між провайдерами, якщо це необхідно.

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

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

Почніть з загальнодоступного IP на балансирі навантаження повністю з мережі та побудуйте принаймні дві з них, щоб одна могла перейти на іншу. Така програма, як Heatbeart, може допомогти з автоматичним відмовою від них.

Лак відомий в першу чергу як рішення кешування, але він також робить дуже пристойне врівноваження навантаження. Можливо, це буде вдалим вибором для врівноваження навантаження. Він може бути налаштований таким чином, щоб 1 до n місць, необов'язково згрупованих у директори, які завантажуватимуть баланс як випадковим чином, так і круговим. Лак можна зробити досить розумним, щоб перевірити стан здоров'я кожного заднього кінця і скинути нездорові задні кінці з петлі, поки він не повернеться в Інтернет. Бакенди не повинні бути в одній мережі.

Мені сьогодні подобається еластичні IP-адреси в Amazon EC2, тому я, мабуть, будую свої балансири навантаження в EC2 в різних регіонах або принаймні в різних зонах наявності в тому ж регіоні. Це дасть вам можливість вручну (не дай бог) відкрутити новий балансир навантаження, якщо вам доведеться перенести існуючий IP-запис A в новий ящик.

Лак не може припинити SSL, тому, якщо це питання, ви можете замість цього поглянути на щось на зразок Nginx.

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

Ось з чого я би почав, якби в мене було це завдання, і, безперечно, вдосконалював би його, продовжуючи.

Однак, як заявляє @ErikA, це Інтернет, і завжди там будуть частини мережі, які не знаходяться під вашим контролем. Ви хочете переконатися, що законні стосунки вас стосуються лише речей, які є під вашим контролем.

Немає проблем - незначно переглянуті формулювання контракту:

... гарантія тривалості роботи 100% (округлена до нуля десяткових знаків).

Якщо Facebook і Amazon не можуть цього зробити, то ви не можете. Це так просто.

Щоб додати відповідь oconnore від Hacker News

Я не розумію, в чому проблема. Клієнт хоче, щоб ви планували катастрофи, і вони не орієнтовані на математику, тому запитувати 100% ймовірність звучить розумно. Як схильні інженери, інженер запам’ятав свій перший день роботи та статтю 101, не враховуючи, що клієнт може цього не зробити. Коли вони говорять про це, вони не замислюються про ядерну зиму, вони думають про те, щоб Фред скидав свою каву на офісний сервер, вийшов з ладу диск або пройшов Інтернет-провайдер. Крім того, ви можете досягти цього. З географічно чіткими, незалежними серверами самонагляду, у вас просто не буде простоїв. Оскільки 3 сервери працюють з незалежною (1) трьома 9 надійністю, з хорошими режимами відмови, очікуваний час простою - менше секунди на рік (2). Навіть якщо це станеться все відразу, ви все ще знаходитесь в межах розумної угоди про угод для веб-зв’язків, а тому простоїв практично не існує. Клієнту все ж доводиться стикатися зі сценаріями досудного дня, але Годзілла виключений, у нього буде служба, яка "завжди" працює.

(1) Сервер в Лос-Анджелесі достатньо незалежний від сервера в Бостоні, але так, я розумію, що є певне перехрестя, пов’язане з ядерною війною, китайські хакери, що розбивають електромережу тощо. Я не думаю, що ваш клієнт буде засмучений це.

(2) Невдача DNS може додати кілька секунд. Ви все ще перебуваєте в сценарії, коли клієнту доводиться повторювати запит один раз на рік, який, знову ж таки, знаходиться в межах розумної угоди про домовленість, і зазвичай не вважається таким же чином, як "час простою". У програмі, яка автоматично перенаправляє на доступний вузол після відмови, це може бути непомітно.

Вас просять про щось неможливе.

Перегляньте тут інші відповіді, сядьте зі своїм клієнтом та поясніть ЧОМУ це неможливо та оцініть їх відповідь.

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

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

ISP на моїй останній роботі зробив це. У нас був вибір "звичайної" лінії DSL з 99,9% тривалості тривалості 40 доларів на місяць, або зв'язаного тріо T1s при 99,99% тривалості до 1100 доларів на місяць. Бували часті перебої в 10+ годин на місяць, що призводило до тривалості їхнього робочого часу значно нижче $ 40 / місяць DSL, але нам було повернено лише близько 15 доларів або близько того, тому що на цьому ставка за годину * годин закінчилася. Вони розібралися, як бандити з угоди.

Якщо ви виставляєте 450 000 доларів США на місяць за 100% часу роботи, а ви досягаєте лише 99,999%, вам потрібно буде повернути їм 324 долари. Я готовий зробити ставку на інфраструктурні витрати, щоб досягти 99,999%, це близько 45 000 доларів на місяць, передбачаючи повністю розподілені кольори, багаторазові підсилення першого рівня, обладнання для приналежності тощо.

Якщо фахівці сумніваються, чи 99,999 відсотків доступності [коли-небудь] є практичною або фінансово вигідною можливістю , то 99,9999% доступність ще менше можлива або практична. Не кажучи вже на 100%.

Ви не досягнете цілі 100% доступності протягом тривалого періоду часу. Ви можете піти з цим на тиждень чи рік, але тоді щось станеться, і ви будете нести відповідальність. Результат може варіюватися від пошкодженої репутації (ви пообіцяли, що ви не поставили) до банкрутства від договірних штрафів.

Є два типи людей, які вимагають 100% часу роботи:

1. Люди, які абсолютно не знають про комп’ютери, комп'ютерні системи чи Інтернет. *
2. Ті, хто навмисно роблять собі дупу, або перевіряють вашу здатність сказати «Ні» (Google «Тест на апельсиновий сік»), або намагаються отримати якусь контрактну угоду про укладання договору за угодою SLA, щоб пізніше виплатити вам.

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

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

Я б спілкувався з клієнтом, щоб встановити з ними, що саме означає 100% часу роботи. Можливо, вони насправді не бачать різниці між 99% тривалості та 100% тривалості тривалості. Для більшості людей (тобто не адміністраторів сервера) ці два числа однакові.

100% часу роботи?

Ось що вам потрібно:

Кілька (і надлишкових) DNS-серверів, що вказують на декілька сайтів у всьому світі, з належними домовленими довідками з кожним провайдером.

Переконайтесь, що сервери DNS налаштовані належним чином, а TTL розпізнається ефективно.

Це легко. SLA Amazon EC2 чітко зазначає:

"Щорічний відсоток часу" обчислюється, віднімаючи від 100% відсоток 5-хвилинних періодів протягом року обслуговування, в якому Amazon EC2 знаходився в штаті "Регіон недоступний".

http://aws.amazon.com/ec2-sla/

Просто встановіть, що "час безперебійного користування" має бути відносно всього пакета послуг, ви можете фактично зберігати свою роботу 100% часу, і у вас не повинно виникнути проблем.

Крім того, варто зазначити, що вся суть угоди про домовленості угод полягає в тому, щоб визначити, які ваші зобов’язання і що відбувається, якщо ви не можете їх виконати. Не має значення, чи клієнт вимагає 3 або 5 або дев'ять мільйонів - питання полягає в тому, що вони отримують, коли / якщо ви не можете їх доставити. Очевидна відповідь - забезпечити позицію на 100% в режимі тривалості 5-разової ціни, яку ви хочете стягнути, а потім вони отримують 4-разове повернення коштів, якщо ви пропустите цю ціль. Ви можете забити!

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

Саме так працює GTM у F5 Big IP - DNS TTL за замовчуванням встановлюється на 30 секунд, і якщо одному з членів кластера потрібно взяти на себе посаду, DNS оновлюється і новий IP приймається практично негайно. Максимум 30 секунд відключення, але це крайній випадок, середній показник - 15 секунд.

Ви знаєте, що це неможливо.

Без сумніву, клієнт зосереджений на тому, щоб бачити "100%", тому найкраще, що ви можете зробити, це обіцяти 100%, за винятком [всіх розумних причин, які не є вашою виною].

Хоча я сумніваюся, що на 100% це можливо, ви можете розглянути Azure (або щось із подібним SLA) як можливість. Що продовжується:

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

Це говорило навіть за відмови від різниці між 99,999 та 100 кордонами щодо божевілля.

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

Чесно кажучи, 100% є абсолютно божевільним, принаймні колись у плані хакерської атаки. Ваша найкраща ставка - зробити те, що роблять Google та Amazon, у вас є георозподілене хостингове рішення, де ви маєте свій веб-сайт та БД реплікувати на декілька серверів у різних географічних місцях. Це гарантуватиме це в будь-чому, крім великої катастрофи, наприклад, перерізання магістральної мережі в Інтернет (яка трапляється час від часу) або щось майже апокаліптичне.

Я б поставив застереження про такі випадки (DDOS, різання магістральних мереж через Інтернет, апокаліптичний теракт або велика війна тощо).

Крім цього, дивіться у хмарні сервіси Amazon S3 або Rackspace. По суті, налаштування хмари не лише запропонує надмірність у кожному місці, але й масштабованість та георозподіл трафіку, а також можливість перенаправлення навколо невдалих георегіонів. Хоча я розумію, що георозподіл коштує більше грошей.

Я просто хотів би додати ще один голос у «він може (теоретично) бути зроблено» партії.

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

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

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

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

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

Іноді великі веб-компанії вимірюють доступність або надійність, використовуючи такі показники:

1. відсоток запитів, на які відповіли успішно, без помилки на сервері (HTTP 500s).
2. відсоток запитів, на які відповіді нижче певної цільової затримки .
3. відхилені запити повинні враховуватися вашими статистичними даними (див. нижче).

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

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

Відсоток відхилених запитів також слід враховувати ваші статистичні дані. Його можна враховувати в тому ж відрі, що й помилки на стороні сервера. Якщо є проблеми з мережею або з іншою інфраструктурою, такою як DNS або балансири навантаження, ви можете використовувати просту математику, щоб оцінити, скільки запитів ви втратили . Якщо ви очікували X запитів на цей день тижня, але у вас X-1000, ви, ймовірно, відмовились від 1000 запитів. Розподіліть свій трафік на графіки запитів на хвилину (або секунду). Якщо з’являються прогалини, ви запитували запити. Використовуйте основну геометрію, щоб виміряти площу цих прогалин, яка дає вам загальну кількість відхилених запитів.

Обговоріть цю методологію зі своїм замовником та поясніть його переваги. Встановіть базову лінію , вимірюючи їх поточну доступність. Їм стане зрозуміло, що на 100% неможлива мета.

Тоді ви можете підписати контракт на основі поліпшень на базовій лінії. Скажімо, якщо вони зараз мають 95% доступності, ви можете пообіцяти покращити ситуацію в десятки разів , досягнувши 98,5%.

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

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

Хоча дехто зазначав тут, що 100% божевільний або неможливий , вони якось пропустили реальну точку. Вони стверджували, що причиною цього є той факт, що навіть найкращі компанії / послуги не можуть цього досягти.

Ну, це набагато простіше цього. Це математично неможливо .

Все має ймовірність. Можливий одночасний землетрус у всіх місцях, де ви зберігаєте ваші сервери, знищуючи їх. На жаль, це смішно невелика ймовірність, але це не 0. Усі, хто ви, Інтернет-провайдери, могли зіткнутися з одночасною терористичною / кібератакою. Знову ж таки, не дуже ймовірно, але теж не нуль. Що б ви не надали, ви можете отримати ненульовий сценарій вірогідності, який знижує всю послугу. Тому що це також не може бути на 100%.

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

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

Я не думаю, що клієнт насправді вимагає 100% часу роботи або навіть 99,999% часу роботи. Якщо ви подивитеся на те, що вони описують, вони говорять про те, щоб вибрати, де вони зупинилися, якщо метеор виймає їхній центр обробки даних на місці.

Якщо вимога зовнішні люди навіть не помічають, наскільки драстичним це має бути? Чи допустимо, щоб зробити запит Ajax повторним і показувати спінер протягом 30 секунд кінцевому користувачеві?

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

мої 2 копійки. Я відповідав за дуже популярний веб-сайт компанії «Фортуна-5», яка знімала рекламу для супер-чаші. Мені доводилося стикатися з величезними скачками в трафіку, і спосіб вирішити це - використовувати такий сервіс, як Akamai. Я не працюю в Akamai, але я вважаю їхню послугу надзвичайно хорошою. У них є власна, розумніша DNS-система, яка знає, що працює з певним вузлом / хостом, або знаходиться під великим навантаженням, або вниз, і відповідно може маршрутизувати трафік.

Акуратним у їхній службі було те, що мені не довелося робити нічого дуже складного для того, щоб копіювати вміст на серверах в моєму власному центрі обробки даних до їх центру обробки даних. Крім того, я знаю, працюючи з ними, вони активно використовували HTTP-сервери Apache.

Хоча на 100% не працює час, ви можете розглянути такі варіанти розповсюдження вмісту по всьому світу. Як я зрозумів речі, Akamai також мав можливість локалізувати значення трафіку, якщо я був у штаті Мічиган, я отримав вміст із сервера Мічиган / Чикаго, і якщо я був у Каліфорнії, я нібито отримав вміст із сервера, що базується в Каліфорнії.

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

Для сайтів, що розміщуються із зовнішньої сторони, найближчим часом до 100% часу роботи буде розміщення вашого веб-сайту в App Engine Google та використання його великої сховища даних реплікації (HRD) , яка автоматично реплікує ваші дані у щонайменше трьох центрах обробки даних у режимі реального часу. Аналогічно, передні сервери App Engine автоматично масштабують / копіюють для вас.

Однак, навіть з усіма ресурсами Google та найдосконалішою платформою у світі, гарантія безперебійного користування додатком App Engine складає лише "99,95% часу в будь-якому календарному місяці".

Простий і прямий: Anycast

http://en.wikipedia.org/wiki/Anycast

Це те, що використовує cloudflare, google та будь-яка інша велика компанія для надмірної, низької затримки, переходу на континентальний провал / балансування.

Але також майте на увазі, що не можна мати 100% часу роботи, і що витрати з 99,999% на 99,9999% значно більші.