Як ви обчислюєте складну угоду про рівень обслуговування (SLA) для хмарних сервісів?

Хмарні сервіси , розміщені на Amazon Web Services , Azure , Google і більшість інших опублікувати S е р в L Evel A пиловій , або угода про рівень обслуговування для окремих послуг , які вони надають. Потім архітектори, інженери платформ та розробники несуть відповідальність за їх об'єднання для створення архітектури, яка забезпечує хостинг для програми.

Якщо взяти окремо, ці послуги зазвичай пропонують щось у діапазоні від трьох до чотирьох дев'яти років:

• Менеджер трафіку Azure: 99,99% або "чотири дев'ятки".
• SQL Azure: 99,99% або "чотири дев'ятки".
• Служба додатків Azure: 99,95% або "три дев'ять п'ять".

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

Доступність серійного з'єднання

У цьому прикладі є три можливих режими відмови:

• SQL Azure не працює
• Служба додатків не працює
• Обидва вниз

Тому загальна доступність цієї "системи" повинна бути нижчою 99,95%. Моє обґрунтування думати це так, якщо домовленості про домовленість для обох служб були:

Послуга буде доступна 23 години з 24

Потім:

• Служба додатків може бути від 01:00 до 0200
• База даних між 0500 та 0600

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

Послідовна та паралельна доступність

У цій архітектурі існує велика кількість режимів відмов, але головним чином:

• Сервер SQL в RegionA не працює
• Сервер SQL в RegionB не працює
• Сервіс додатків у RegionA не працює
• Служба додатків у RegionB не працює
• Менеджер трафіку не працює
• Поєднання вище

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

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

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

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

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

Для вашого першого випадку ймовірність того, що служба App (A) та Sql Service (B) одночасно знижується, є результатом їх ймовірності:

P(A)*P(B) = 0.0005 * 0.0005 = 0,00000025

Ймовірність того, що хтось із них вниз, - це сума їх ймовірності:

P(A)+P(B) = 0.001

Коли дві події є незалежними, то формула, яка враховує ймовірність того, що вони будуть знищені, є:

P(A,B) = P(A) + P(B) - P(A)*P(B) = 0.001 - 0,00000025 = 0,00099975

Таким чином, загальний рівень угод про рівень обслуговування (SLA) був би 1 - 0,00099975 = 0,99900025у відсотках99.900025 %

Спрощення є продуктом першої ймовірності: 0.9995 * 0.9995 = 0,99900025.

Застосовується для вашого відключення на 1 год / 24 години (4,166666% на день), це дає (десяткові знаки скорочуються):

0.0416 + 0.0416 - (0.0416 * 0.0416) = 0,081597222

Тож вірогідність бути в порядку 1 - 0.0816 = 0.9184у відсотках:91,84%

24 * 0.0816 = 1.95 h

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

Маючи це на увазі, ви можете помітити доступність кожного з них, 95,84%і 0,958333333 * 0,958333333 = 0,918402778це наше 91.84%зверху (вибачте за повний десятковий знак, але вони потрібні для демонстрації)

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

У нас є вірогідність менеджера трафіку ОК P(T) = 0.9999і кожна програма + пара БД з імовірністю ОК P(G) = 0,99900025від

Скільки регіону ми граємо роль, оскільки ми маємо застосувати добуток відмови лише для того, щоб отримати ймовірність, що обидві області знижуються як один і той же час:
0,00099975 * 0,00099975 = 0,0000009995000625це означає загальну наявність принаймні одного регіону99,049375 %

Тепер у нас є загальна доступність регіонів, продукт із менеджером трафіку дає нам загальну доступність системи:

0.9999 * 0,9999990004999375 = 0,99989900059988750625

Загальна доступність є 99.989900 %

Інше джерело як пояснення доступне в документах Azure (посилання люб’язно надана Радж Рао )

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

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

Так

99,95% * 99,95% = 99,9%

Розрахунок його паралельно є трохи більш складним , як ми робимо необхідність враховувати , що відсоток ип доступність буде:

Розрахунок проводиться так:

1. Помножте ООН наявність двох регіонів разом.

   0,1% * 0,1% = 0,0001%

2. Перетворіть це на наявність

   100% - 0,0001% = 99,9999%

3. Помножте доступність диспетчера трафіку на доступність двох регіонів.

   99,99% * 99,9999% = 99,9899%

4. Результатом є доступність всієї системи.

   99,9899% близько 99,99%

Я закінчив використовувати Excel для виконання обчислень, ось значення:

... і формули ...