Глобальне питання налаштування доступності

Я є власником і керую візуальним веб-сайтомoptimizer.com /. Додаток пропонує фрагмент коду, який мої клієнти вставляють на свої веб-сайти для відстеження певних показників. Оскільки фрагмент коду - це зовнішній JavaScript (у верхній частині коду сайту), перш ніж показати веб-сайт клієнта, веб-переглядач відвідувача зв’язується з нашим сервером додатків. У випадку, якщо наш сервер додатків не працює, браузер намагатиметься встановити з'єднання перед тим, як він вичерпається (як правило, 60 секунд). Як ви можете собі уявити, ми не можемо дозволити собі запускати сервер додатків за будь-якого сценарію, оскільки це негативно вплине на досвід роботи не лише відвідувачів нашого веб-сайту, але й відвідувачів веб-сайтів наших клієнтів!

Зараз ми використовуємо механізм відмови DNS з одним резервним сервером, розташованим в іншому центрі обробки даних (фактично на іншому континенті). Тобто ми відстежуємо наш сервер додатків з 3-х окремих місць, і як тільки він виявляється вниз, ми змінюємо запис, щоб вказувати на резервну копію IP-адреси сервера. Це добре працює для більшості браузерів (оскільки наш TTL - 2 хвилини), але IE кешує DNS протягом 30 хвилин, що може бути вбивцею угоди. Дивіться це нещодавнє повідомлення нашого vizualeveoptimizer.com/split-testing-blog/maximum-theoretical-downtime-for-a-website-30-minutes/

Отже, які налаштування ми можемо використати, щоб забезпечити майже миттєвий відмову у випадку, якщо центр обробки даних зазнає великих відмов? Я читаю тут www.tenereillo.com/GSLBPageOfShame.htm що наявність декількох записів A - це рішення, але ми не можемо дозволити собі синхронізацію сеансу (поки що). Іншою стратегією, яку ми вивчаємо, є наявність двох записів A, одна вказує на сервер додатків, а друга - на зворотний проксі (розташований в іншому центрі обробки даних), який вирішує основний сервер додатків, якщо він працює, і резервний сервер, якщо він працює. Чи вважаєте ви цю стратегію розумною?

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

Довідка: я прочитав цю тему, яка була корисною serverfault.com/questions/69870/multiple-data-centers-and-http-traffic-dns-round-robin-is-the-only-way-to-assure

Ваша ситуація досить схожа на нашу. Ми хочемо розділити дані-центри та відмовити тип мережевого рівня.

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

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

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

Найкраща практика BGP Multihomed / Multi-location та найкращий спосіб підвищити стійкість? це питання, які я задавав щодо подібних питань.

Сторінка сорому GSLB породжує деякі важливі моменти, ось чому я особисто ніколи не бажав би обирати GSLB, щоб виконувати завдання маршрутизації BGP.

Ви також повинні переглянути інші моменти відмови у вашій мережі. Переконайтеся, що всі сервери мають 2 NIC (підключені до двох окремих комутаторів), 2 блоку живлення та що ваша послуга складається з декількох серверів, що надходять із резервних серверів, як надлишкові пари або кластери, збалансовані за завантаженням.

В основному, DNS "балансування навантаження" через декілька записів A - це просто "розподіл навантаження", оскільки DNS-сервер не має поняття, скільки навантаження на кожному сервері. Це дешево (безкоштовно).

Служба GSLB має певну концепцію завантаження серверів та їх доступності та забезпечує більшу стійкість до відмов, але все ще наштовхується на проблеми, пов’язані з кешуванням і прив'язкою dns. Це менш дешево, але трохи краще.

ІМХО - єдиний спосіб по-справжньому гарантувати хороший робочий час, маршрутизована мережа BGP, підтримувана міцною інфраструктурою. Ви можете заощадити гроші, використовуючи маршрутизатори замість маршрутизаторів Cisco / Juniper / тощо, але в кінці дня вам потрібно дуже обережно керувати цими серверами. Це аж ніяк не дешевий варіант, або щось, що слід здійснити легковажно, але це дуже корисне рішення і приносить вас в Інтернет як постачальник, а не просто споживач.

Гаразд, це запитували деякий час тому, але я вперше бачу це зараз.

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

Ти повинен:

1. Розмістіть свій файл Javascript у хорошій, професійній мережі доставки вмісту, тобто придбайте високодоступне обслуговування HTTP (S) Javascript у того, хто вже має цей досвід.
2. Програмуйте Javascript так, щоб він був хорошим, коли ваш сервер додатків не реагує швидко, то кінцевий користувач бачить звичайну немодифіковану сторінку.

Робити щось інше - це безвідповідально, насправді. Я припускаю, що у вас це вже є.

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

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

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

Надіслати групи A до ip 1 і групи B до ip 2, навіть якщо вони були на одному сервері, дозволить вам розділити групи тестування. Група А та група В походять з різних географічних регіонів. Щоб бути справедливим, наступного дня / тижня / місяця ви перегортаєте групи, щоб переконатися, що ви допускаєте географічні відмінності. Просто бути суворим у своїй методиці.

Служба geodns / failover dns на веб-сайті http://edgedirector.com може це зробити

розкриття інформації: я пов’язаний із вищенаведеним посиланням, натрапивши сюди, вивчаючи статтю щодо застосування дурних днт-трюків для тестування на спліт.