Урожай, урожайність та масштабовані системи терпимості: Підсумок

У цій статті подано короткий зміст статті «Урожай, урожайність та масштабовані системи толерантності», опубліковану Еріком Брюером та Амандо Фоксом у 1999 році.

У статті розглядаються компроміси між послідовністю та доступністю (CAP) для великих систем. Дуже легко вказати на CAP і стверджувати, що жодна система не може мати узгодженості та доступності.

Але, є і підводка. CAP було неправильно зрозуміле різними способами. Як пояснює Кода Хейл у своєму чудовому дописі в блозі "Ви не можете пожертвувати толерантністю до розділів":

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

Стаття зосереджена на збільшенні доступності великомасштабних систем шляхом відмовостійкості, стримування та ізоляції:

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

Дві метрики, урожай та урожай можна узагальнити наступним чином:

  • Урожай : дані у відповідь / загальні дані

    Наприклад: Якщо один із вузлів не працює в кластері з 100 вузлів, урожай становить 99% протягом тривалості несправності.

  • Прибутковість : запити, виконані з успіхом / загальна кількість запитів

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

У статті стверджується, що існують певні системи, які вимагають досконалих відповідей на запити кожного разу. Крім того, існують системи, які іноді можуть терпіти недосконалі відповіді.

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

Торгівля врожаєм на урожай - ймовірнісна доступність

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

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

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

Для збільшення врожайності пропонуються дві стратегії:

  1. Випадковий розподіл даних по вузлах

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

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

  2. Тиражування найважливіших даних

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

    Це також покращує урожай.

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

Розкладання додатків та ортогональні механізми

Друга стратегія фокусується на перевагах ортогонального проектування системи.

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

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

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

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

Метою даної роботи було мотивування досліджень у галузі проектування відмовостійких та високодоступних великомасштабних систем.

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

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

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