mtbf, mttf

Страшные аббревиатуры, которые я привел в заголовке, обозначают:

MTBF - Mean time between failures, MTTF - mean time to failure.

Рассчитать их можно, используя формулы из Sun Blueprints, High Availability Fundamentals 

MTBF  = T/R

где

T = Общее время теста

R = Количество ошибок

MTTF можно рассчитать как:

MTTF  = T/N

T = Общее время теста

N = Число тестируемых образцов

И наконец доступность определяется как:
Avaiability = MTBF / ( MTBF + MTTF)

После прочтения  Blueprints  я сразу же решил найти эти характеристики для оборудования Oracle/Sun. И...не смог. Данные о MTBF  есть только на компоненты, а не на систему в целом. Это выглядит достаточно странно, потому что таким образом нет измеряемой разницы между Enterprise решением и простой машинкой на Intel Xeon. Понятно, что разница между системой, которая продолжает работать при отказе процессорной платы (hi-end Sun продолжают работать при отказе одной процессорной платы, позволяют ее менять без остановки системы) и той, что сразу останавливает, должна быть. Иначе не понятно, за что такие деньги.  Но этой информации я не нашел.

Я даже позвонил в московское представительство Oracle/Sun чтобы попытаться получить эти данные. Но ..также не смог получить эти данные. Если они у Вас есть  - буду вам благодарен. Может в Oracle их  потеряли после покупки Sun'а  ? :)))


Хорошо, пойдем дальше. Ниже приводится таблица с пересчетом процентов доступности во время простоя в года. 

Внимание, вопрос как же рассчитать нам availability системы для нашей Oracle Database ?

Ну конечно же взять характеристики нашего hardware + oracle software +нашего приложения. С hardware мы разобрались - данных нет. C Oracle Database Server  - картина та же самая -данных нет.

Нам остается только проводить  эксперимент с нашим приложением. Если у нас есть Standby, то можно аварийно завершить наш production, затем data guard broker активирует  Standby а наше приложение автоматически переключиться  на Standby.  Хочу опустить, сколько всего нужно сделать, чтобы это заработало, но думаю, что пройдет не менее 10 минут, пока приложение восстановит свое обычное кол-во транзакций в минуту.
Интересные данные о времени восстановления приводили коллеги (Александр Алехин) из МегаФон-Москва, при тестировании RAC:

common RAC (2 active): 2 минуты
active + passive: 4 минуты
active + standby (active_instance=1): 5 минут

Если исходить из приведенных мной данных, то RAC позволит вам остаться на уровне 3-х девяток после запятой, если использовать все узлы в активном состоянии. Другие комбинации приближают нас к  Standby - т.е. к  2-м девяткам. Хотя на практике для вашей БД и приложения
Standby может переключаться очень быстро,  что время от времени утверждали слушатели наших семинаров.

Но мы рассматривали вариант простоя  из-за аварии. Однако, если вы посмотрите любые материалы по MAA (скажем этот), обнаружите, что кроме аварий есть еще и планируемые простои - на обновление версии СУБД. В документации есть хорошая подборка всех методов.

Наверно существенная часть простоев  - на обновление версии СУБД. Горячие головы утверждают, что при помощи Rolling upgrade, используя промежуточную logical Standby можно добиться времени простоя в 2 минуты.

Конечно у нас есть еще и простой на время обновления нашего приложения, уменьшить время которого призван механизм Edition-Based Redefinition.

Выводы:
 -  если очень - очень сильно упереться, то при помощи RAC можно получить систему с доступностью 3 девятки после запятой. Скорее всего, чтобы выдержать эту цифру, при этом потребуется не обновлять приложение. При этом надежность 'железа' не будет играть ключевой роли. 

- если упереться, но чуть поменьше, то с помощью standby можно достичь 2-х девяток после запятой. Но приложению лучше знать про FAN и уметь восстанавливать контекст транзакции.

- ну и наконец, если следовать теории, что быстро поднятое не считается упавшим, с помощью HA кластера вполне реально достичь 1-ой девятки после запятой. (сам HA конечно очень быстро все переключает, но не позволит делать обновления БД).

- при покупке железа стоит задуматься о готовности вашего приложения к обновлениям. Да, железо поможет избежать незапланированных простоев, но запланированные сведут все ваши финансовые усилия на нет. Т.е. лучше соблюдать баланс между усилиями с разных сторон.

В заключение, еще раз хочу обратить внимание, что следует измерять время простоя не до  поднятие ip адреса, не когда прошел первый ping или tnsping, а когда ваше приложение начало работать с требуемым у вас service level agreement (SLA). А значит у Вас должен быть этот самый SLA...