Про фетиші - єдиної точки відмови, about netapp
У практиці побудови високодоступних систем, перш за все IT, існує поняття "єдиної точки відмови" (SPOF, Single Point Of Failure). Будь-яка система високої доступності даних прагне не мати в своїй архітектурі вузла, лінії зв'язку або об'єкта, відмова якого може вивести з ладу всю систему, або викликати недоступність даних.
Все це так. Однак я звернув увагу, що останнім часом, особливо в IT-шної середовищі виникло своєрідне "фетішірованіе" ось цього от "відсутності єдиної точки відмови". Широко поширилася думка, що "відсутність єдиної точки відмови" це синонім "добре" і "система правильна", а її присутність - "погано" і "система неправильна". І на цьому дослідження питання архітектурної правильності закінчується. Однак, як і в будь-якому іншому справі, суть, насправді, лежить трохи глибше.
Справа в тому, що "відсутність єдиної точки відмови" це "інструмент" для досягнення високої доступності, але не "мета". "No SPOF" це один із засобів досягнення доступності, але не сама доступність як така, засіб, одне з, а не мета, часто необхідне, але не достатня умова.
Що ж, в такому разі, насправді визначає придатність рішення?
Мені видається, що це задоволення вимог по RPO / RTO для даної конкретної бізнес-завдання.
Терміни RPO / RTO добре відомі фахівцям в області захисту даних і резервного копіювання. RPO, Return Point Objective - це "точка доступності даних", в разі їх втрати. RTO, Return Time Objective - це час, який неоьходімо системі для відновлення своєї роботи, і відновлення обслуговування.
Припустимо, ви втратили дані, відновили їх з резервної копії за станом на 21 годину минулої доби. Відновлення бази зайняло 40 хвилин. Якщо у вас працює база даних, то вам ще треба актуалізувати її стан з archive logs, накат зміни, записані з 21:00 по сучасність. Припустимо, це зайняло 15 хвилин. Разом, RTO, в вашому випадку - 55 хвилин.
Погано це чи добре? Неможливо відповісти з точки зору IT. Відповідь має дати бізнес, якому ви служите. Для якогось завдання навіть 10 хвилин простою це багато. Якась цілком готова почекати пару годин, а якісь завдання цілком можуть і добу постояти, нічого страшного не трапиться. Падіння біржі NYSE може бути чревате панікою в масштабах глобальної економіки. Падіння мережі обслуговування банкоматів великого банку, який за 10 хвилин періоду простою міг би обробити десятки тисяч звернень "фізиків", це ще не паніка, але все ще дуже неприємно. А хостинг домашніх сторінок цілком може і добу полежати з повідомленням "Вибачте, ведуться роботи", в кращому випадку виплативши клієнтам неустойку за добу простою.
Зрозуміло, бізнес буде вимагати нульового RPO / RTO, це завжди так, вони завжди це вимагають. ) Однак слід пам'ятати, що все коштує грошей, і кожне поліпшення ситуації з часом недоступності коштує грошей, причому часто росте по експоненті, кожне наступне поліпшення цих параметрів обійдеться бізнесу все дорожче і дорожче.
Тому, як правило, бізнес і IT зазвичай приходять до якогось компромісу. Компроміс цей, як правило, сегментований за завданнями. Але в кінцевому рахунку бізнес і IT, спільно виробляють якісь вимоги по RPO / RTO.
І система, яка виконує ці вимоги, система, яка задовольняє цим вимогам бізнесу, за прімелемие для бізнесу гроші - це хороша система. Система, яка не задовольняє їм - погана.
Зверніть увагу, що в моєму опреденіі "поганий" і "хорошою" системи я не використовував поняття "відсутності єдиної точки відмови" зовсім.
Чи може бути хорошою, тобто задовольняти вимогам бізнесу по RPO / RTO, система з наявністю "єдиної точки відмови"? Так запросто. Якщо період відновлення працездатності системи укладається в задані рамки - та хай хоч греблю гати там буде точок відмови. Особливо, якщо ліквідація в рішенні всіх "єдиних точок відмови" економічно недоцільна, тому що надмірно дорога для розв'язуваної бізнесом завдання.
Пам'ятайте, що надійність, це комплексний параметр, що залежить від безлічі факторів і багатьох учасників. Створення наднадійного стораджа для зберігання даних не зробить сверхнадежной вашу IT-систему, якщо до цього наднадійні, кластерному, без єдиної точки відмови, і по FC Dual Fabric підключені ненадійні сервера, без кластеризації і з вичерпаним сервісним контрактом, які виконують власне бізнес-додаток і бізнес -функцію. Пам'ятайте, що як і у випадку морської ескадри, швидкість якої визначається швидкістю самого повільного в ній корабля, надійність IT-системи визначається надійністю найслабшого в ній ланки. а аж ніяк не найнадійнішого.
У надійності немає "чарівної кулі", як немає і абсолютної надійності. І наявність або відсутність "єдиної точки відмови" у вашій частині IT-системи може ніяк не відбиватися на надійності бізнес-системи в цілому. Завжди слід дивитися глибше, і задаватися метою, чи виконуються вимоги по RPO / RTO, необхідні бізнесу, і скільки це коштує. І чи можна за ті ж гроші, або дешевше, знайти рішення, що покращує цей показник, і яким чином.
А не просто фетишували на один з безлічі інструментів для досягнення цієї мети.