Яка хороша стратегія підтримувати мій сайт в Інтернеті, коли S3 не працює в режимі офлайн?

Яка хороша стратегія підтримувати мій сайт в Інтернеті, коли S3 не працює в режимі офлайн?

Якщо S3 US East 1 переходить в автономний режим, то як я можу налаштувати / структурувати свою програму, щоб запобігти тому, щоб не брати весь сайт в офлайн?

Які найкращі стратегії для диверсифікації в подібній ситуації?

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

^{джерело: https://aws.amazon.com/blogs/aws/new-cross-region-replication-for-amazon-s3/}

Практика зберігання вашої інфраструктури в Інтернеті шляхом переходу на інший регіон є складною, але S3 є порівняно невеликим і простим компонентом. У Netflix є чудова стаття про їхній досвід роботи з Хаосом Горілла.

Це стосується також деградації послуг, як, наприклад, збільшення затримки. Не лише тоді, коли послуга, від якої ви залежите, є повністю автономною. Netflix також має статтю з цього приводу: модернізація хаосу .

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

1. Усуньте окремі точки відмови
2. Механізм переходу з кінцевої точки на іншу
3. Спосіб виявлення збоїв

Усуньте окремі точки відмови

У випадку з S3 точка №1 розглядається, як вказував Євгеній, через міжрегіональну реплікацію S3 .

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

Механізм переходу з кінцевої точки на іншу

Для S3 це означає, що в разі відмови ви хочете, щоб програма перестала читати і писати з / у відро A і використовувати замість цього відро B.

Як цього досягти, наскільки я знаю, зараз залежить від вас. Деякі інші сервіси AWS пропонують цілком прозорі збої, але я не знаю такого для S3.

Існують різні способи досягнення цього. Одним із прикладів є використання проксі-сервера, який спрямовуватиме трафік до відповідного пакета. Під час відключення ви б оновлювали / змінювали проксі-сервер, щоб перенаправляти трафік до відра, на який відключення не впливає. Іншим прикладом може бути зробити конфігурацію програми динамічною та зберегти її у сховищі ключових значень. Якщо програма читає KV-магазин для оновлених властивостей досить часто, ви можете переключитися з місця, з якого ви читаєте, і на яке (наприклад, Spring Cloud має підтримку слухача "EnvironmentChange").

Спосіб виявлення збоїв

Що ж, це легко, я думаю. Просто налаштуйте цикл запису + читання та оповіщення, як тільки щось не підходить :)

Заключні записки

• Якщо ваша заявка пише у відро, вам доведеться подумати про те, що буде в разі відмови. Чи всі записи потрапили до відрізка призначення (і ви можете сказати)? Чи можете ви дозволити запис у відро призначення, що робить його новим "первинним"? Ретельне планування дозволить уникнути розбитого мозку або втрачених сценаріїв оновлення.
• Залежно від вашої угоди про рівень обслуговування, можливо, ви хочете, щоб точки №2 та №3 були автоматизованими або автоматичними. Для цього потрібні додаткові планування, інструментарій та тестування, але добре складені сценарії завжди реагуватимуть швидше та передбачуванішими способами, ніж людські можливості (невдачі також мають прикрий звик траплятися посеред ночі, коли втручання людини є чимось небезпечним.
• Варто зазначити, що навіть міжрегіональна реплікація не повністю усуває окремі точки відмови. Звичайно, якщо регіон зменшиться, ви перекриєтесь. Але що робити, якщо в США відбудеться відключення AWS? У минулому році Azure зазнала часткового, але глобального відключення, а також у 2014 році.