Коли серверу теж потрібна евакуація: дата-центри під ударами

Ми звикли думати про дата-центр як про одне з найбезпечніших місць для інформації.

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

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

Фізичний майданчик може просто стати недоступним.

Останні атаки на українські дата-центри та телекомунікаційну інфраструктуру це дуже добре продемонстрували.

І якщо раніше географічне резервування для багатьох підприємств було чимось із категорії «було б непогано», сьогодні це вже питання нормальної організації ІТ-інфраструктури.

Дата-центри теж стали цілями

Лише протягом другої половини вересня в повідомленнях про атаки фігурувала ціла низка дата-центрів, хостингових майданчиків та операторів.

Після атак 23 вересня проблеми з доступом до інтернету відчули близько 100 тисяч домогосподарств Києва та області.

Але домашній інтернет — лише видима частина проблеми.

За одним дата-центром можуть стояти сотні корпоративних систем: бухгалтерія, ERP, CRM, інтернет-магазини, склади, виробництво, логістика, документообіг, пошта, телефонія та десятки інших сервісів.

Тому атака на цифрову інфраструктуру може мати значно ширший економічний ефект, ніж здається на перший погляд.

Скільки коштує година без сервера?

Збиток від подібних подій неправильно рахувати лише в серверах, дисках та мережевому обладнанні.

Припустимо, підприємство втратило доступ до ERP на один робочий день.

Менеджери не бачать замовлень.

Склад не може нормально оформлювати відвантаження.

Бухгалтерія не проводить документи.

Виробництво не отримує необхідної інформації.

Інтернет-магазин приймає замовлення, але вони не потрапляють у внутрішню систему.

Працівники є. Зарплата нараховується. Клієнти телефонують. Машини чекають. А підприємство фактично стоїть.

Тому справжня ціна аварії складається не тільки з вартості обладнання.

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

Міжнародна статистика добре показує порядок цифр. За даними Uptime Institute, серед організацій, які пережили значні збої ІТ-інфраструктури, 57% оцінювали вартість останнього такого інциденту більш ніж у $100 000, а приблизно кожен п'ятий — більш ніж у $1 млн.

І це звичайна статистика аварій.

В українських умовах до класичних причин простою додався ще один фактор — війна.

Два сервери поруч — це не дві незалежні копії

Можна купити дуже хороші сервери.

Поставити RAID.

Зробити кластер.

Додати другий комутатор.

Підвести два канали зв'язку.

Встановити UPS і дизель-генератор.

І все зробити технічно правильно.

Але якщо production, резервний сервер і backup знаходяться в одному приміщенні, вони все одно мають одну спільну географічну точку відмови.

У мирний час це могло бути прийнятним ризиком.

У воєнний — вже ні.

Більше того, сьогодні варто думати не тільки про різні будівлі.

Різні дата-центри одного міста — це географічне резервування лише до певної міри.

Для справді критичної інформації відстань між копіями повинна вимірюватися вже не кварталами.

Частина інформації повинна зберігатися за кордоном

Це не означає, що українському бізнесу потрібно масово вивозити всю ІТ-інфраструктуру з України.

У багатьох випадках основні сервери цілком логічно залишати тут: це швидкість доступу, контроль, існуюча інфраструктура та економіка.

Але критична інформація не повинна існувати тільки в Україні.

Хоча б одна повноцінна резервна копія найважливіших даних повинна знаходитися за кордоном.

А ще краще — мати декілька територіально незалежних точок.

Наприклад:

Основна система — Україна

↓

Оперативна репліка — інший майданчик

↓

Backup — інший регіон України

↓

Backup — Німеччина

↓

Ще одна незалежна копія — окреме сховище

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

Не складайте всі яйця в один... RAID

Старе правило резервного копіювання 3-2-1 нікуди не поділося:

3 копії даних;

2 різні системи або типи зберігання;

1 копія — географічно віддалена.

Але в українських реаліях для критичних даних я б сьогодні дивився навіть ширше.

Копій може бути більше трьох.

Вони можуть знаходитися у різних дата-центрах, різних містах і різних країнах.

Причому бажано не складати абсолютно все в одного провайдера.

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

Є ще одна пастка: реплікація — це не резервна копія

Припустимо, у нас є PostgreSQL в Україні, який у реальному часі реплікується на сервер у Німеччині.

Чудово.

Якщо перший сервер стане недоступним, другий можна використати для продовження роботи.

Але є проблема.

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

Ми отримаємо дві географічно рознесені копії однієї проблеми :)

Тому нормальна схема — це не:

Production + Replica.

А:

Production + Replica + Snapshots + Versioned Backup + Off-site Backup.

Різні механізми захищають від різних проблем.

І ще: backup повинен уміти відновлюватися

Є прекрасне відчуття спокою, яке дає зелений напис:

Backup completed successfully.

Але сам по собі він ще нічого не гарантує.

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

Тому процедура повинна виглядати приблизно так:

створили backup → перевірили → відновили на тестовому сервері → запустили систему → перевірили дані.

І робити це потрібно не після аварії.

Після аварії вже пізно читати інструкцію.

Що зробили ми в K2 ERP

Після останніх подій ми також переглянули розміщення власної інфраструктури.

Критичну частину систем K2 ERP ми перенесли до Німеччини.

Частина інфраструктури залишається в Україні, а резервні копії та дані розподіляються між різними майданчиками.

Для нас принцип досить простий:

відмова одного сервера не повинна зупиняти систему;

недоступність одного дата-центру не повинна означати втрату інформації;

проблема в одному регіоні не повинна перетворюватися на катастрофу для всієї інфраструктури.

Фактично сьогодні ми повинні проектувати ІТ-системи, виходячи з припущення, що будь-який окремий фізичний майданчик одного дня може стати недоступним.

І система повинна це пережити.

Найдорожчий backup — той, якого немає

Додатковий сервер коштує грошей.

Місце в дата-центрі коштує грошей.

Трафік, диски, хмарне сховище і адміністрування також коштують грошей.

Через це резервування дуже легко відкласти:

«Зробимо трохи пізніше».

А потім настає той самий день, для якого воно було потрібне.

Обладнання можна купити знову.

Операційну систему можна встановити за декілька годин.

ERP можна розгорнути заново.

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

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

цінна інформація повинна знаходитися одночасно в декількох незалежних географічних точках.

Частина — в Україні.

Частина — за кордоном.

І хоча б одна копія — достатньо ізольована від основної системи.

Бо хороший план відновлення — це не той, у якому написано, що робити після катастрофи.

Хороший план — це коли після втрати одного майданчика катастрофи для бізнесу не відбувається.

TradeMaster в соціальних мережах

З приводу розміщення новин пишіть на press@trademaster.com.ua